JP2019518265A - System and method for identifying a user using graphical barcodes and payment card authorization readings - Google Patents

Abstract

Provide a method for authenticating an online transaction or login process. The method is receiving image data of a visual graphical barcode from a user device, wherein the visual graphical barcode is configured to be displayed on a non-authenticated device for conducting online transactions. Analyzing the image data to obtain a transaction verification identifier (ID), comparing the transaction verification ID to a pre-stored verification ID, pre-stored a set of first collected data from the user device Comparing with a set of second collected data, and (1) matching a transaction verification ID with a pre-stored verification ID, and (2) a set of first collected data with pre-stored And determining whether to approve or reject the online transaction based on the agreement with the second collected data.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application is related to US Provisional Patent Application No. 62 / 314,900, filed March 29, 2016, and October 2016, the entire contents of which are incorporated herein by reference. Claim priority to US Provisional Patent Application No. 62 / 413,886 filed on 27th.

  Credit card theft plays a major role in fraudulent transactions. Both physical card theft and skimming of data on the card to create clones allow fraudsters to impersonate another for financial transactions.

  Such frauds are particularly troublesome in situations involving large financial transactions. In particular, users can make financial transactions online and fairly anonymously. In many cases, users can register themselves without verification and use basic credit card information to conduct financial transactions. The use of stolen credit cards or stolen credit card data can not be detected in conventional online transactions.

  On the other hand, as the Internet is widely used, attempts to steal from people have increased. Phishing is an illegal attempt to gain personal or confidential information by fraud and can be done by providing a fake web page that looks like a real web page. In order to prevent leakage of personal or confidential information, the user wants to know if the web page is hosted by a trusted entity.

  Accordingly, there is a need to authenticate user identification, service provider identification, and / or card identification during financial transactions involving payment cards. Systems and methods are provided for identifying a user using payment card authorization reading data. Graphical authentication indicia or one-time quick response (QR) codes may be utilized to establish a connection associated with a particular transaction (eg, a financial transaction) between a user and a service provider. A card reader can also be used during the transaction. The card reader may be able to read and distinguish magnetic information on the card. Data from the card may be copied and replicated, but the magnetic properties of the physical payment card may be unique. The card reader may be able to record the swipe characteristics of the card that may be used to distinguish the user. For example, different users may swipe the card through the card reader in different ways. Even with the same user, some variation in swipe characteristics can be expected each time a swipe is performed. Location information about the user device or card reader can be collected and compared during authentication reading. This comparison may allow verification of the user identity and may reduce the likelihood of the card identity being stolen during a transaction. Additional levels of security can be achieved by utilizing graphical authentication indicia or visual graphical barcodes (e.g., quick response (QR) codes). Graphical authentication indicia or visual graphical barcodes may provide an additional authentication layer. The graphical authentication indicia or visual graphical barcode may include anti-replay functionality to prevent replay attacks. For example, one-time QR codes or visual graphical barcodes become unique transactions in order to authenticate service providers, enable mutual authentication between users and service providers, or to enhance additional security levels for user authentication. It may be related. The QR code or visual graphical barcode may act as a token that is resistant to replay attacks. The visual graphical barcodes used with the user authentication information may also allow the user to conduct transactions via the non-authenticated device using the authenticated user device.

  One aspect of the present invention is directed to systems and methods for authenticating users, payment cards, transactions, and servers. The authentication system may allow the user to conduct highly secure transactions via non-authentication devices. One-time QR codes or visual graphical barcodes can be displayed to the user on the non-authentication device. The QR code or visual graphical barcode may be associated with a unique transaction provided by the service provider. The user can use the authenticated user device to scan the QR code or visual graphical barcode displayed on the non-authentication device. The authenticated user device can transmit the QR code or the visual graphical barcode to the authentication system. The authentication system can verify the QR code or visual graphical barcode to verify the identity of the service provider, user device, and / or user. The transaction may be completed by the user swiping the payment card on the card reader connected to the user device or the non-authentication device, whereby the authentication read data, card data, and location data to verify the user identity. Are collected and transmitted to the authentication system. In some cases, nonce data is captured during scanning of visual graphical barcodes or in the process of trading and may be used to prevent replay attacks.

  In one aspect, a method is provided for authenticating an online transaction. The method is receiving image data of a visual graphical barcode from a user device, wherein the visual graphical barcode is configured to be displayed on a non-authenticated device for conducting online transactions. Analyzing the image data using one or more processors to obtain a transaction verification identifier (ID), comparing the transaction verification ID with the prestored verification ID using one or more processors Comparing a set of first collected data from the device with a prestored set of second collected data using one or more processors, and (1) a transaction verification ID and a prestored verification Approving an online transaction based on a match of the ID and (2) a match of the first set of collected data and the second set of collected data prestored Or reject comprises determining using one or more processors.

  In a related but separate aspect, a system is provided for authenticating an online transaction. The system includes a server in communication with a user device and a third party server providing an online transaction, the server including identification information for the third party server, a prestored user device identifier, a first stored set of first (I) a memory for storing collected data, and a set of software instructions, and receiving visual graphical barcode image data from a user device, the visual graphical barcode being displayed on the non-authentication device Configured to receive, analyze the image data to obtain a transaction verification identifier (ID), compare the transaction verification ID to a pre-stored verification ID, submitted by the user device 1 Comparing the set of second collected data to the prestored set of first collected data, and 1) approve the online transaction based on the match between the transaction verification ID and the pre-stored verification ID, and (2) the match between the pre-stored set of first collected data and the set of second collected data And (ii) one or more processors configured to execute a set of software instructions to determine whether to reject or to reject.

  In some embodiments, a pre-stored verification ID is generated in response to a request to perform a secure authentication step during an online transaction, wherein the secure authentication step is an online transaction by the user using a non-authentication device. It is performed when the process is performed and the non-authenticated device has an unknown security level. In some embodiments, a pre-stored verification ID is associated with a third party identification to provide an online transaction or login process.

  In some embodiments, the visual graphical barcode is a one-time barcode that is uniquely associated with the transaction. In some embodiments, the method further comprises receiving a user device identifier with the image data. In some embodiments, the method further includes receiving the nonce data along with the image data to detect a replay attack. In some embodiments, when the transaction verification ID matches the pre-stored verification ID, a set of first collected data from the user device is provided.

  In some embodiments, the set of first collected data from the user device is provided by the user device or a card reader operably coupled to the user device. In some cases, the first set of collected data from the user device includes card reading, which is provided by swiping the card through a card reader. In some cases, the first set of collected data from the user device is (i) the card's magnetic fingerprint, (ii) the card's swipe characteristics, (iii) the location information for the card reader, or (vi) the user It includes at least one of location information about the device. In some instances, the swipe characteristics include the speed, direction, angle, timing or pressure of the swipe as the card is swiped through the card reader. In some instances, location information regarding the card reader or user device is provided using the card reader or one or more sensors on the user device, and the location information is a card as the card is swiped through the card reader. At least one orientation or spatial position of the reader or user device.

  The various aspects of the invention described herein may be applied to any of the specific applications described below. The invention may be applied to any computing device, web service, software application, and / or security system that requires user authentication and / or service provider authentication for transactions. The invention can be implemented on one or more computing devices using hardware or a combination of hardware or software.

  Additional aspects and advantages of the present disclosure will become readily apparent to those skilled in the art from the following detailed description, which is merely illustrative of the present disclosure as an illustration of the best mode contemplated for carrying out the present disclosure. Are illustrated and described. As will be realized, the present disclosure is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the present disclosure. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature and not restrictive.

Incorporation by Reference All publications, patents, and patent applications mentioned in this specification are specifically and individually indicated so that each publication, patent or patent application may be incorporated by reference. It is incorporated herein by reference to the same extent.

BRIEF DESCRIPTION OF THE DRAWINGS The novel features of the invention are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present invention can be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings.

Fig. 6 shows an example of a card reader attached to a user device according to an embodiment of the present invention. Fig. 7 shows an additional example of a card reader attached to a user device according to an embodiment of the present invention. Fig. 6 illustrates an example of a card reader in communication with a user device, according to an embodiment of the present invention. FIG. 1 shows a schematic view of a card reader according to an embodiment of the present invention. Fig. 6 shows an example of a payment card with corresponding magnetic stripes according to an embodiment of the invention. FIG. 7 illustrates an example of using magnetic fingerprint data from a payment card to identify a user, according to one embodiment of the present invention. 5 illustrates an example of various swipe characteristics of a payment card, according to an embodiment of the present invention. FIG. 10 illustrates an example of using the swipe feature of a payment card to identify a user, according to one embodiment of the present invention. FIG. 5 illustrates an example of data stored for various transactions and that may be used to identify users and / or fraudulent transactions, according to one embodiment of the present invention. FIG. 7 illustrates an example of how location data may change over time, according to one embodiment of the present invention. FIG. 7 illustrates an example of using location data to identify a user, according to one embodiment of the present invention. 8 illustrates an additional example of data stored for various transactions and that may be used to identify users and / or fraudulent transactions, according to one embodiment of the present invention. FIG. 7 illustrates an example of a user device that may be used to scan a QR code displayed on another device, according to an embodiment of the present invention. FIG. 10 illustrates an example of using a QR code to identify a user or verify a service provider, according to one embodiment of the present invention. 8 illustrates an exemplary network layout that includes one or more authentication systems, according to some embodiments. FIG. 7 shows a schematic block diagram of an exemplary system and method for authenticating a user and a card within a transaction, according to some embodiments. 1 provides an overview of an exemplary method according to the present system for mutual authentication. FIG. 10 illustrates a schematic block diagram of an exemplary system and method for authenticating a user and / or payment card in connection with a transaction, according to some embodiments. 1 shows an overview of an exemplary method according to the present system for authenticating a user and a card. FIG. 1 illustrates a schematic block diagram of an exemplary system and method for enabling a user to securely conduct transactions using a non-authenticated device, according to some embodiments. 7 shows an example of a user equipment according to an embodiment of the present invention. An example of collecting nonce data is shown. FIG. 6 illustrates a schematic block diagram of an exemplary system and process for enabling a user to securely conduct transactions using a non-authenticated device, according to some embodiments.

  While preferred embodiments of the present invention have been illustrated and described herein, it will be apparent to those skilled in the art that such embodiments are given by way of example only. Many modifications, variations, and substitutions will now occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention.

  The present invention provides a system and method for identifying a user using payment card authorization read data and a QR code or visual graphical barcode. The various aspects of the invention described herein may be applied to any of the specific applications described below. The invention may be applied as a stand-alone card reader system or as a component of integrated financial transaction or fraud detection software. It should be understood that the various aspects of the invention may be appreciated individually, collectively or in combination with one another.

  The transaction may be conducted online, in which case the user may often be anonymous. For example, users can often register themselves without verification or with minimal personalization information. Users often provide financial information, such as payment card information, remotely. Even if the user swipes the card directly in the card reader, it is possible that the user is using stolen or skimmed credit card data. The systems and methods provided herein utilize information derived from card swipes to verify user identification. For example, the card's magnetic fingerprint is card specific and can be read using a card reader. This may allow the card to be distinguished from skimmed cards in which data may be replicated but magnetic stripe properties may not be replicated. Likewise, the swipe characteristics of the card can be read and can be unique to an individual user. Even if the same physical card is used, various users can be distinguished from one another by the swipe characteristics of the users. Even with the same user, some very slight variation of swipe characteristics can be expected between swipes. If the card swipe is completely identical, it may indicate that the previous swipe data has been recorded and has been somehow replayed as a subsequent swipe. Location information from the user device or card reader can be collected during card swipes. For example, it can be expected that the orientation of the user device and / or the card reader may have some variation between card swipes. If the position information such as the orientation is completely the same, the previous swipe data may be recorded to indicate that it has been replayed as a subsequent swipe.

  In addition, the graphical authentication indicia (eg, quick response (QR) code) described herein can be used to further enhance the security level of the user verification process. For example, each transaction may be associated with a one-time unique QR code or graphical authentication indicia. If multiple transactions have the same QR code or graphical authentication indicia, it may indicate a replay attack. In another example, the QR code or graphical authentication indicia described herein can be used for mutual authentication, whereby the identity of the service provider can be verified prior to user verification. Furthermore, the QR code or graphical authentication indicia described herein may allow the user to conduct transactions via non-authenticated devices with unknown security levels. In addition, the QR code or graphical authentication indicia described herein can simplify the login process without requiring the user to manually type in login credentials.

  A card reader may communicate with the user device to identify the user and / or authorize the transaction. The user device may enable the user to conduct an online transaction. The card reader can accept payment card swipes, and the card reader, user device, or another external device may have data from the payment card to verify user identification and / or to allow transactions to pass. Can be assessed by If certain conditions are detected, alerts can be given to various parties as needed.

  FIG. 1 shows an example of a card reader attached to a user device according to an embodiment of the present invention. Card reader 100 may be physically connected to user device 104. The card reader may be configured to receive the payment card 102 and read the magnetic stripe 103 of the payment card.

  The card reader 100 may be configured to read the magnetic stripe 103 of the payment card 102. The card reader can accept payment cards to read the magnetic stripe. The card reader may be configured to accept a payment card swipe movement. In some embodiments, the card reader may include a groove or channel for swiping the payment card. The groove or channel may be deep enough to receive the magnetic stripe portion of the payment card. Payment card swipes can include substantially parallel movement between the payment card and the card reader. The groove or channel may have an open end that can allow the payment card to swipe through completely without requiring any relative orthogonal movement between the payment card and the card reader. Alternatively, one or more closed ends may be provided which may limit the length or the end of the swipe movement.

  The card reader may include a sensing unit that may be able to detect the magnetic stripe of the payment card. In some embodiments, the sensing unit may include a magnetic head capable of reading magnetic properties from the magnetic stripe of the payment card. The sensing unit can produce a signal indicative of the information collected about the magnetic stripe. Such signals may include data encoded in stripes and / or magnetic fingerprint data of stripes. The sensing unit may be in the groove, in the housing of the card reader, or on the outer surface of the card reader.

  The data encoded in the stripe may include information regarding the payment card, information regarding the user of the payment card, or information regarding an account (e.g., a financial account) associated with the payment card. For payment card information, type of credit carrier (eg Visa, Mastercard, American Express, Discover etc.), payment card number, payment card expiration date, payment card security code (eg printed on the back of the card) Code). Information regarding the user of the payment card may be the user's name, user's mailing address, user's phone number, user's e-mail address, user's birthday, user's gender, user's social security number, etc. It may contain any other personal information. Information regarding the financial account associated with the payment card may be the account number, the institution (eg, bank, store, entity, or financial institution) associated with the account, information such as balance information, credit or payment limit information, or other information related to the account. It may contain any information.

  Magnetic fingerprint data may relate to data regarding the magnetic composition of the card's magnetic stripe. The magnetic fingerprint data may include information regarding residual noise characteristic information regarding the magnetic media of the stripe. Magnetic stripes may include magnetic transitions (eg, from north to south and from south to north). Individual magnetic particles may be provided on the magnetic stripe. There may be inherent variations and orientations of these magnetic particles that may appear in the magnetic properties of the stripes. These magnetic properties may form magnetic fingerprints that may be substantially unique per magnetic stripe.

  A sensing unit, such as a magnetic head, can read the magnetic properties of the magnetic stripe. The sensing unit may be able to sense magnetic transitions and associated noise. The sensing unit can generate an analog signal indicative of the read magnetic data. The analog signal may be converted to a digital signal and / or stored in a digital medium. The signal may indicate variations in the magnetic properties of the magnetic stripe. The signal may include an indication of magnetic transition. The signal may also include an indication of magnetic particle fluctuations, such as particle orientation. Substantially different signals may be generated for each magnetic stripe. Thus, the sensing unit may be sensitive enough to uniquely identify a magnetic stripe as compared to other magnetic stripes.

  The sensing unit may include a groove or slot through which the payment card can slide through. The magnetic head may be on one side or on both sides of the groove or slot. The magnetic stripe on the payment card so that the magnetic head can have a standardized position on the sensing unit to read the magnetic stripe when the card is fully inserted and / or swiped into the groove. The position may be standardized. The magnetic head may be able to read the magnetic stripe when the card is simply placed in the groove or when the card is swiped through the groove. The card may need to be swiped in a particular direction, or it may be readable if swiped in either direction.

  In other embodiments, a sensing unit can be provided on the side of the card reader, such as the outer surface of the card reader. The card can pass through the side and / or the sensing unit. The card may be held on the side and / or sensing unit or may be swipe on the side and / or sensing unit. A guide may or may not be provided which may help to limit the swipe path or indicate where to hold the payment card.

  Payment card 102 may be any type of device that may include magnetic components that may be used to identify the device. The payment card may be a credit card, debit card, gift card, bank card, discount card, membership card, or any other type of card. The payment card can be tied to the user account. A user account may or may not include information about the user or any other information about the user or user account described elsewhere in this specification. The user account may be a user's financial account, which may include information regarding the user's credit and / or debit.

  In some instances, a payment card may include a substrate. For example, the substrate may be a plastic substrate. The user's name may optionally be shown (eg, printed) on the payment card. The financial carrier's name and / or logo may be shown (eg, printed) on the payment card. A payment card number may be shown (eg, printed) on the payment card. The payment card may or may not have a photo of the associated user. The payment card may or may not have an electronic chip. The payment card may or may not have a standardized size. In some instances, the dimensions of the payment card may be approximately 85.60 × 53.98 mm (3.370 × 2.125 inches). Alternatively, the payment card may have various sizes. The sensing unit may be able to read a payment card of standardized size. The sensing unit may be able to read payment cards of various sizes.

  The payment card may include a magnetic component. The magnetic components can be printed on the substrate or stacked in layers on the substrate. The magnetic component can be embedded in the substrate. The magnetic component may be a magnetic stripe. The magnetic stripe can be located on one side of the payment card. The magnetic strip may extend along a predetermined length of the card. The magnetic stripe can extend along the entire length of the card, or at least 99%, 97%, 95%, 90%, 85%, 80%, 70%, 60%, or more than 50% of the card length. It can extend along. The magnetic stripe may include magnetic particles that may have varying orientations. Although magnetic stripes are described throughout, such descriptions may be applicable to magnetic components having any other form factor.

  User device 104 may be an electronic device capable of forming a connection with a card reader. A mechanical connection may or may not be formed between the user device and the card reader. An electrical connection may or may not be made between the user device and the card reader. A communication connection may be formed between the user device and the card reader. The user device may be a mobile device (e.g. smart phone, tablet, pager, personal digital assistant (PDA)), computer (e.g. laptop computer, desktop computer, server or any other type of device). Optionally, the user device may be handheld, the user device may be a cash register at a store or other store, the cash register may be used during a transaction (such as a financial transaction) at the store or other store The user device may be a network device capable of connecting to a network such as a local area network (LAN), a wide area network (WAN) such as the Internet, a telecommunications network, a data network, or any other type of network.

  A user device may include a memory storage unit that may include non-transitory computer readable media including code, logic, or instructions for performing one or more steps. The user device may include one or more processors capable of performing one or more steps according to, for example, a non-transitory computer readable medium. The user device may include a display that displays a graphical user interface. The user device may be able to accept input by the user interaction device. Examples of such user interaction devices may include keyboards, buttons, mice, touch screens, touch pads, joysticks, trackballs, cameras, microphones, motion sensors, thermal sensors, inertial sensors, or any other type of user interaction device . The user device may be able to operate one or more software applications. One or more applications may or may not relate to the operation of the card reader.

  User device 104 may include an imaging device, such as a camera. The camera may be configured to capture graphical authentication indicia. Further details regarding the functionality of the imaging device and graphical authentication indicia are discussed below.

  The card reader may connect to the user device in any manner. The card reader may be mechanically connected to the user device. The card reader may be a dongle that may be connected to the user device. The card reader is one or more of user devices such as a microphone port, USB port, charging port for user device, thunderbolt port, HDMI (registered trademark) port, Firewire port, memory card slot, VGA reader, external SATA port, Ethernet port, etc. Can be plugged into the existing port of the or any other connection port or jack of the user equipment. The card reader may be attachable to the user device and / or removable from the user device.

  In some cases, a card reader may be powered by the user device. For example, power may be provided via a port. Alternatively, the card reader may have its own local power supply without being powered by the user device. The card reader may transmit data to the user device. In some cases, data of an authentication read by the card reader may be sent to the user device. The card reader may or may not receive data from the user device. Communication with the card reader may be sent via the port. Both electronic and mechanical connections may be formed between the card reader and the user device.

  In some embodiments, the card reader may be of portable size so as to be easily carried and connected to the user device. The card reader may have an overall smaller size than the user device. For example, the ratio of the largest dimension of the card reader (eg, length, width, height, diagonal or diameter) to the largest dimension of the user device (eg, length, width, height, diagonal or diameter) is 1:50, 1:30, 1:20, 1:15, 1:10, 1: 9, 1: 8, 1: 7, 1: 6, 1: 5, 1: 4, 1: 3, 1: 2, 1: It may be 1.5, 1: 1.1, 1: 1, 1.5: 1, or 2: 1 or less. Alternatively, this ratio may be greater than any of the listed values, or may fall within the range between any two of the listed values. Similarly, the volume ratio of the card reader to the volume of the user device is 1:50, 1:30, 1:20, 1:15, 1:10, 1: 9, 1: 8, 1: 7, 1: 6 , 1: 5, 1: 4, 1: 3, 1: 2, 1: 1.5, 1: 1.1, 1: 1, 1.5: 1, or 2: 1 or less. Alternatively, this ratio may be greater than any of the listed values, or may fall within the range between any two of the listed values. The weight ratio of the card reader to the weight of the user device is 1:50, 1:30, 1:20, 1:15, 1:10, 1: 9, 1: 8, 1: 7, 1: 6, It may be less than 1: 5, 1: 4, 1: 3, 1: 2, 1: 1.5, 1: 1.1, 1: 1, 1.5: 1, or 2: 1. Alternatively, this ratio may be greater than any of the listed values, or may fall within the range between any two of the listed values.

The card reader can be a handheld item. The card reader may be able to fit in the user's hand or palm. The card reader has a maximum dimension of 30 cm, 25 cm, 20 cm, 15 cm, 12 cm, 10 cm, 9 cm, 8 cm, 7 cm, 6 cm, 5 cm, 4 cm, 3 cm, 2 cm, or 1 cm or less (e.g. length, width, height, diagonal, Or diameter). Alternatively, the card reader may have a largest dimension greater than any of the listed values, or may have a largest dimension included in the range between any two of the listed values. Card ^{reader, 100cm 3, 75cm 3, 50cm} 3, 30cm 3, 25cm 3, 20cm 3, 15cm 3, 12cm 3, 10cm 3, 9cm 3, 8cm 3, 7cm 3, 6cm 3, 5cm 3, 4cm 3, 3cm ^It may have a volume of ³ , 2 cm ³ , or 1 cm ³ or less. Alternatively, the card reader may have a volume greater than any of the listed values, or may have a volume included in the range between any two of the listed values. The card reader includes 500 g, 300 g, 200 g, 150 g, 100 g, 80 g, 70 g, 60 g, 50 g, 30 g, 30 g, 20 g, 20 g, 15 g, 10 g, 7 g, 5 g, 3 g, 2 g, 1 g, 0.5 g, 0.1 g. It can have a weight of 1 g or less. Alternatively, the card reader may have a weight greater than any of the listed values, or may have a weight included in the range between any two of the listed values.

  The card reader may be used to swipe the card reader to identify the card being passed and / or the user associated with the card. In some instances, this identification may include verifying the identification claimed by the card and / or the user. In other examples, this identification may include determining the identification of cards and / or users without past claims based on historical data. The card can be swiped through the card reader for identification. The identification may be performed for any purpose that may or may not include facilitating the transaction. In some instances, identification may be performed to allow user access to information or locations. Rather than simply entering a payment card number or other payment card information on the user display of the user device, the card may be read by a card reader. Relevant information can be read from the card by the card reader and used to make an identification. The card reader may be in communication with a user device that may facilitate identification. The user device can receive card information from the card reader and help facilitate the identification process. This may be done online or may have online components. Card readers may provide an additional level of security as compared to manually entering card information. When the card is read by the card reader, an authentication reading of the card can optionally be performed. Authentication reading can result in obtaining the magnetic fingerprint and / or swipe characteristics of the card. The authentication reading may also result in obtaining location information (eg, orientation, spatial location, and / or any corresponding motion information) regarding the card reader and / or the user device. This information may be useful in identifying cards and / or users, as described in more detail elsewhere herein.

  Card readers may be used to facilitate transactions. In some instances, a card can be swiped through the card reader when a financial transaction is taking place. Rather than simply entering a payment card number or other payment card information on the user display of the user device, the card may be read by a card reader. Relevant information can be read from the card by the card reader and used to make financial transactions. The card reader may be in communication with a user device that may facilitate the transaction. The user device can receive card information from the card reader and help facilitate the transaction. The transaction can be an online transaction. The transaction can be a direct transaction with an online component (e.g., verification of card information, account information, or user information). Card readers may provide an additional level of security as compared to manually entering card information. When the card is read by the card reader, an authentication reading of the card can optionally be performed. Authentication reading can result in obtaining the magnetic fingerprint and / or swipe characteristics of the card. This information may be useful in authenticating a card, a user, and / or a transaction, as described in more detail elsewhere herein. Based on the authentication reading, the transaction may be authorized to complete, may be suspended, or may cause an additional verification process to occur.

  As shown in FIG. 1, the card reader 100 can be directly inserted into the user device 104. The card reader may form a rigid connection with the user device. When inserted, the card reader may not be movable relative to the user device. The card reader may be plugged into one or more ports of the user device. The card reader may be plugged into any side of the user device (e.g. upper, lower, right, left, back or front). The card reader may extend or protrude from the user device. The card reader may extend from the card reader in a direction substantially coplanar with the front and / or back of the user device. The card reader may or may not extend substantially beyond the front and / or back of the user device (e.g. 75%, 100%, 125%, 150%, 200% of the thickness of the user device). It may have a thickness of 250%, or 300% or less). The card reader may include an extension member that may connect the sensing unit of the card reader to the user device. In some cases, the card reader may have a form factor that may form a substantially continuous surface from the user device. For example, the front surface of the card reader may be aligned with the front surface of the user device to substantially form a continuous surface, and / or the back surface of the card reader may be aligned with the back surface of the user device to substantially form a continuous surface As such, the card reader can be configured.

  The card reader may be configured to receive the payment card 102. The card reader can read the magnetic component 103 of the payment card. The card reader can be configured to prevent interference between payment card swipe and the user device when attached to the user device. The payment card may be swiped at an angle approximately parallel to the side of the user device to which the card reader is attached. The card reader can be configured to receive payment cards on the side of the card reader that faces the other side of the card reader connected to the user device.

  FIG. 2 shows an additional example of a card reader attached to a user device, according to an embodiment of the present invention. Card reader 200 may be connected to user device 204 by flexible tether 206. The card reader may be configured to read the payment card 202.

  Flexible tether 206 may be plugged directly into user device 204. Thus, a flexible connection can be made between the card reader 200 and the user device. When inserted, the card reader may be movable relative to the user device. The flexible tether may be plugged into one or more ports of the user device. The flexible tether may be inserted into any side of the user device (e.g., upper, lower, right, left, back or front). The flexible tether may extend or protrude from the user device. The flexible tether may include metal fibers, optical fibers, or wires that may enable communication between the card reader and the user device. The flexible tether may include a cover or insulating surface that can protect the interior of the flexible tether. Flexible tethers may be useful for powering a card reader from a user device. Flexible tethers may be useful for providing information from a card reader to a user device, such as information regarding the authentication of a payment card. The flexible tether may be completely flexible so that the flexible tether may be deployed based on gravity and / or positioning of the tether's end point (eg, connection to a card reader or connection to a user device). In use, the flexible tether may have a particular shape, and the flexible tether may not be able to keep its shape naturally. Flexible tethers can be semi-rigid or can have rigid components. The flexible tether may be able to maintain position or shape after the user bends the flexible tether into the desired shape.

  The card reader may be configured to receive payment card 202. The card reader can read the magnetic components of the payment card. The card reader can be configured to prevent interference between payment card swipe and the user device when attached to the user device. The flexible tether may allow the orientation and / or positioning of the card reader to be changed. The card reader may be placed at a convenient location for swiping payment cards. The card reader can be configured to receive payment cards on the side of the card reader that faces the other side of the card reader that connects to the flexible tether.

  FIG. 3 illustrates an example of a card reader in communication with a user device, in accordance with one embodiment of the present invention. Card reader 300 may communicate with user device 304 over wireless connection 306. The card reader may be configured to read payment card 302. The wireless connection may allow the card reader to be physically removed from the user device.

  A wireless connection 306 may be formed between the card reader 300 and the user device 304. The wireless connection may be a direct wireless connection such as Bluetooth (registered trademark), infrared, Zigbee, near field communication, ultraband, WiFi, optical communication, and the like. A wireless connection can be provided, which can be short range wireless communication (eg, reaching at least several centimeters, tens of centimeters, meters, tens of meters). The wireless connection may be an indirect wireless connection such as 3G, 4G, LTE, GSM (registered trademark), WiMax and the like. A wireless connection may traverse the telecommunications network. Wireless communication may allow long distance wireless communication and / or may not be dependent on the relative position between the user device and the card reader. Wireless communication may traverse one or more intermediary devices or relay stations. The card reader and / or the user device may be configured to enable direct communication, indirect communication, or both. The card reader and / or the user device may be able to switch between different communication types.

  Wireless communication may include bi-directional wireless communication between the card reader and the user device. Data can flow from the card reader to the user device and / or can flow from the user device to the card reader. For example, information regarding authentication reading of a payment card by a card reader may be transmitted from the card reader to the user device. The user device may comprise a communication unit and / or the card reader may comprise a communication unit capable of enabling wireless communication between two devices. The communication unit may optionally include an antenna. In some embodiments, components or dongles that may enable wireless communication between the user device and the card reader may be plugged into the user device. The component or dongle may include a communication unit that may communicate with the communication unit of the card reader.

  In some embodiments, a card reader may have a local onboard power unit. Alternatively or additionally, the user device may wirelessly power the card reader. Non-radiative or radiative radio feeding may be provided. For example, non-radiative wireless or near field wireless feeds can be performed over short distances by using magnetic fields (eg inductive charging). Radiation wireless or far-field wireless feeding may be performed using power beaming, such as a beam of electromagnetic radiation such as a microwave or laser beam.

  The card reader may be configured to receive payment card 302. The card reader can read the magnetic components of the payment card. The card reader may be configured to prevent interference between payment card swipe and the user device when communicating with the user device. Wireless communication between the user device and the card reader may allow for repositioning of the card reader. The card reader can be placed at a convenient location for swiping payment cards. The card reader may need to stay within the predetermined proximity of the user device. For example, in the card reader, the card reader is 1 cm, 5 cm, 10 cm, 20 cm, 30 cm, 50 cm, 1 m, 1.5 m, 2 m, 5 m, 5 m, 10 m, 20 m, 30 m, 50 m, 100 m, 200 m, 400 m, or It can communicate wirelessly with the user device as long as it is within 800 m. When the card reader is at a distance from the user device that exceeds any of the values described herein, the card reader can communicate wirelessly with the user device. In some instances, an alert or alert may be provided when the card reader leaves the predetermined proximity of the user device or when the communication signal between the card reader and the user device weakens below a predetermined threshold.

  FIG. 4 shows a schematic view of a card reader according to an embodiment of the present invention. The card reader 400 can have a magnetic sensor 402. Data collected by the magnetic sensor may be transmitted to an analog to digital converter (ADC) 404. The ADC may send the converted data to the processing unit 408. The processing unit may optionally include an encryption subsystem 409. Data may be stored in memory unit 410. Data may optionally be provided to communication unit 412.

  Card reader 400 may have any form factor, such as those described elsewhere herein. The card reader may be configured to communicate with the user device. The card reader can be portable. The card reader may include a housing that can enclose one or more of the components described herein. The housing may enclose the magnetic sensor, the ADC, the processing unit, the memory unit, and / or the communication unit. Alternatively, one or more of the units may be exposed or may be provided on the exterior of the housing. In some instances, the card reader may include a slot or slot configured to receive payment cards. A magnetic sensor 402 can be provided in the groove or slot. A magnetic sensor may optionally be exposed in the groove or slot to read the magnetic component of the payment card. In alternative embodiments, the card reader need not have grooves or slots, but may have exposed magnetic sensors that can be used to read the magnetic components of the payment card. For example, a magnetic sensor can be swipe on the magnetic stripe of the payment card.

  As described above, the magnetic sensor 402 may be able to detect the magnetic composition of the card's magnetic stripe. The magnetic composition may include information regarding residual noise characteristic information regarding the magnetic media of the stripe. Magnetic sensors may detect magnetic transitions (eg, from north to south and from south to north). The magnetic sensor may be able to detect the intrinsic variation and orientation of the magnetic particles that may appear in the magnetic properties of the stripe. The magnetic sensor can detect magnetic characteristics of the magnetic stripe that can form a magnetic fingerprint that can be substantially unique per magnetic stripe.

  The magnetic sensor may include a read head for reading the magnetic media. Magnetic trigger circuitry may receive information from pulses on the read head and logic elements. The signal from the read head may optionally pass through a preamplifier that may amplify the output from the read head.

  The data collected by the magnetic sensor may be transmitted as an analog signal. The analog signal may be conveyed to the ADC 404. The ADC may convert an analog signal to a digital signal.

  Processing unit 408 may receive the digital signal. The processing unit may include one or more processors that may perform one or more steps individually or collectively. The processing unit may store digital information in the memory unit 410. A memory unit may include one or more memory components. The processing unit may generate magnetic fingerprints based on the digital data. The processing unit may optionally include an encryption subsystem 409. The encryption subsystem may encrypt the magnetic fingerprints. Magnetic fingerprints can be encrypted using an encryption key. The encryption key may be stored in memory. The magnetic fingerprints may be stored in a memory unit. An encrypted or unencrypted version of the magnetic fingerprint may be stored in the memory unit. A memory unit may optionally be used to store an identifier for the card reader. The identifier for the card reader may be unique to the card reader.

  Memory unit 410 may include volatile memory and / or non-volatile memory. The memory can be protected by a tamperproof mechanism. The processing unit and / or the memory unit may be implemented using a microcontroller. The microcontroller may be a secure microcontroller that may be tamper resistant.

  The processing unit can send and receive information to and from the communication unit 412. The communication unit may include an input / output (I / O) interface. The communication unit may enable the card reader to communicate with one or more external devices such as a user device. The communication unit may enable wired and / or wireless communication between the card reader and an external device.

  Location information regarding the user device and / or the card reader may be collected. In some embodiments, the location information may include the orientation of the user device and / or the card reader. The orientation may be given with respect to a static frame of reference such as the environment. The orientation may be given relative to the direction of gravity and / or the poles. The orientation may be determined using one or more inertial sensors on the card reader and / or the user device. Examples of inertial sensors may include, but are not limited to, accelerometers, gyroscopes, magnetometers, or any combination thereof. In some cases, a tip can be provided that can integrate one or more inertial sensors. One or more of the inertial sensors may include a piezoelectric component. Inertial sensors may detect orientation using gravity, magnetic fields, and / or moments of inertia. Sensors and / or chips can be provided within the housing of the card reader and / or the user device. The orientation of the user device and / or the card reader may be determined about one, two or three axes. The axes may be orthogonal to one another. The axes may correspond to the pitch, roll and yaw axes of the user device and / or the card reader. A single inertial sensor may be able to simultaneously detect the orientation to any or all of the axes, or multiple inertial sensors may be provided, each corresponding to one axis.

  The orientation of the user device and / or card reader can be determined to a high degree of accuracy and / or precision. In some cases, the orientation of the user device and / or card reader is approximately 10 degrees, 5 degrees, 3 degrees, 2 degrees, 1 degree, 0.1 degrees, 0.01 degrees, 0.001 degrees, 0.001 degrees, 0.0001 The degree can be obtained up to the range of 0.00001 degree or less. The orientation may be determined for each of the axes, such as the yaw, pitch and roll axes, respectively, of the user device and / or the card reader.

Any description herein of orientation information may include static orientation information and / or dynamic orientation information. For example, any reference to orientation information may include orientation motion information such as angular velocity and / or angular acceleration. Angular motion information may be determined about one, two or three axes. The axes may be orthogonal to one another. The axes may correspond to the pitch, roll and yaw axes of the user device and / or the card reader. A single inertial sensor may be able to simultaneously detect directional motion on any or all of the axes, or multiple inertial sensors may be provided, each corresponding to one axis. The angular velocity of the user device and / or the card reader can be determined to a high degree of accuracy and / or precision. In some instances, the angular velocity of the user device and / or the card reader may be approximately 10 degrees / s, 5 degrees / s, 3 degrees / s, 2 degrees / s, 1 degree / s, 0.1 degrees / s, 0 It is possible to obtain the range of 0.01 degree / s, 0.001 degree / s, 0.0001 degree / s, 0.00001 degree / s, 0.000001 degree / s or less. The angular acceleration of the user device and / or the card reader can be determined to a high degree of accuracy and / or precision. In some instances, user equipment and / or the angular acceleration of the card reader about 10 ° ^{/ s} 2, 5 ° ^{/ s} 2, 3 times ^{/ s} 2, 2 ° ^{/ s} 2, 1 time ^/ s 2, 0. It is calculated to the range of 1 degree / s ² , 0.01 degree / s ² , 0.001 degree / s ² , 0.0001 degree / s ² , 0.00001 degree / s ² , 0.000001 degree / s ² or less be able to. Orientation motion can be determined for each of the user equipment and / or card reader's axes, such as the yaw, pitch, and roll axes, respectively.

  The location information may or may not include spatial location information for the user device and / or the card reader. For example, coordinates regarding the spatial position of the user device and / or the card reader can be determined. Spatial locations may be given with respect to a static frame of reference such as the environment. The direction of gravity and / or the poles can be used as a reference in a static frame of reference. Spatial position may be determined using one or more inertial sensors, global positioning system (GPS) systems, vision sensors, reference sensors, or any combination thereof. Examples of inertial sensors may include, but are not limited to, accelerometers, gyroscopes, magnetometers, or any combination thereof. In some cases, a tip can be provided that can integrate one or more inertial sensors. One or more of the inertial sensors may include piezoelectric components. Inertial sensors may detect orientation using gravity, magnetic fields, and / or moments of inertia. Sensors and / or chips can be provided within the housing of the card reader and / or the user device. The spatial position of the user device and / or the card reader may be determined along one, two or three axes. The axes may be orthogonal to one another. The axes may correspond to the pitch, roll and yaw axes of the user device and / or the card reader. A single inertial sensor or other type of sensor may be able to simultaneously detect the spatial position for any or all of the axes, or multiple sensors may be provided, each corresponding to one axis.

  The spatial position of the user device and / or the card reader can be determined to a high degree of accuracy and / or precision. In some cases, the spatial position of the user device and / or the card reader may be approximately 20 cm, 10 cm, 5 cm, 3 cm, 2 cm, 1 cm, 1 mm, 0.1 mm, 0.01 mm, 0.01 mm, 0.001 mm, 0.0001 mm, 0.. The range can be obtained up to 00001 mm or less. The spatial position may be determined along each of the axes, such as the yaw, pitch and roll axes, respectively, of the user device and / or the card reader.

Any description herein of spatial position information may include static spatial position information and / or dynamic spatial position information. For example, any reference to spatial position information may include spatial motion information such as linear velocity and / or linear acceleration. Spatial motion information may be determined along one, two or three axes. The axes may be orthogonal to one another. The axes may correspond to the pitch, roll and yaw axes of the user device and / or the card reader. The sensors may be able to simultaneously detect an orientation movement on any or all of the axes, or a plurality of sensors may be provided, each corresponding to one axis. The linear velocity of the user device and / or card reader can be determined to a high degree of accuracy and / or precision. In some instances, the linear velocity of the user device and / or card reader may be approximately 20 cm / s, 10 cm / s, 5 cm / s, 3 cm / s, 2 cm / s, 1 cm / s, 1 mm / s, 0.1 mm / s. It can obtain to the range of s, 0.01 mm / s, 0.001 mm / s, 0.0001 mm / s, 0.00001 mm / s, 0.000001 mm / s, 0.0000001 mm / s or less. The linear acceleration of the user device and / or the card reader can be determined to a high degree of accuracy and / or precision. In some instances, user equipment and / or from about 20 cm ^/ s ² linear acceleration of the card ^{reader, 10cm / s 2, 5cm /} s 2, 3cm / s 2, 2cm / s 2, 1cm / s 2, 1mm / ^{s 2, 0.1mm / s 2,} 0.01mm / s 2, 0.001mm / s 2, 0.0001mm / s 2, 0.00001mm / s 2, 0.000001mm / s 2, 0.0000001mm / s It can be calculated to the range of ² or less. Spatial motion can be determined for each of the user equipment and / or the card reader, such as the yaw, pitch and roll axes, respectively.

  The position information may include considering orientation only, spatial position only, or both orientation and spatial position (which may include static and / or dynamic information). Sensors that can assist in the detection of position information can be provided only on the user device, only on the card reader, or on both the user device and the card reader. In some instances, if a rigid connection is formed between the user device and the card reader, sensors on the user device can assist in detection of card reader position information and / or sensors on the card reader Can help detect the position information of the user device. In some instances, only the location of the user device may be considered, only the location of the card reader may be considered, or the locations of both the user device and the card reader may be considered.

  Location information may be collected at the time of authentication reading. Location information may be collected when the payment card is swiped. Location information may be in a single instance (eg, start of swipe, half of swipe, end of swipe), in multiple instances (eg, every few minutes, every few seconds, every few milliseconds), or over a time range (eg, For example, it can be collected during the entire swipe event. The timing of collecting location information can be determined to a high degree of accuracy and / or precision. In some cases, the timing information may be approximately 1 minute, 30 seconds, 10 seconds, 3 seconds, 2 seconds, 1 second, 0.1 seconds, 0.01 seconds, 0.001 seconds, 0.001 seconds, 0.0001 seconds, 0. It can be determined to the range of 00001 seconds and 0.000001 seconds or less. In some instances, where position information is collected at multiple points in time (eg, over a range of times), a position profile may be created and / or stored. For example, the position of the user device and / or card reader at the first time t1, the position of the user device and / or card reader at the second time t2, the position of the user device and / or card reader at the third time t3, etc. It can be stored as one or more sets of data. For example, one set of position data is [0.00000, (0.00000, 0.00000, 0.00000), 0.00001, (0.00120, 0.00054, -0.03012), 0.00002, (0.00278, 0.00106, -0.05045), 0.00003, (0.00415, 0.00198, -0.08398),. . . And time values may be position data (angular orientation data about the pitch, yaw, and roll axes, or spatial translational data relative to the pitch, yaw, or roll axes). Can be given near Location information and / or associated timing may be stored as part of the authentication reading or may be stored separately.

  As explained above, if the exact position data (e.g. a position profile collected at a single point in time or across multiple points in time) is repeated for another swipe, the position data may be highly accurate and / or accurate, among others Such repetition may be considered suspicious when collected to sex. Similarly, even if the user device and / or card reader is nearly stationary, the card swipe is likely to cause some vibration or slight movement that can be detected by the sensitive sensor, so If the position profile does not have any position change over time during the duration, that may also be suspicious or be the basis for further investigation.

  FIG. 5 shows an example of a payment card 500a, 500b, 500c with corresponding magnetic stripes 502a, 502b, 502c according to one embodiment of the invention.

  In some embodiments, the magnetic stripe of the payment card may be provided according to one or more international or national standards. Data can be recorded in tracks on the magnetic stripe. In some cases, a magnetic stripe may be provided by the typical format of Track 2 of the International Standards Organization (ISO) 7811 card. In alternative embodiments, the track 1 or track 3 standard may be used. In some instances, track 2 (eg, having 75 bpi) may be preferred by having a lower density than track 1 or track 3. A track may optionally have multiple sections, such as LZ, SS, PAN, ES, LRC, TZ, etc. A wide variety of formats may be utilized in the systems and methods described herein.

  The magnetic stripes may have a standardized arrangement on the card. The magnetic stripe may include magnetic media deposited or layered on the substrate of the card. The magnetic stripe can be attached to the card using an adhesive. The magnetic stripe can be read using a card reader.

  Magnetic stripes may include magnetic transitions (eg, from north to south and from south to north). This transition can be detected and the pattern of the transition can be useful to encode information. Magnetic stripes can be made of individual magnetic particles. There may be inherent variations and orientations of these magnetic particles that may appear in the magnetic properties of the stripes. These magnetic properties may form magnetic fingerprints that may be substantially unique per magnetic stripe. Each magnetic stripe of each magnetic card can have a different distribution of magnetic particles and correspondingly different magnetic properties. Thus, different magnetic fingerprints can be generated for each magnetic stripe. This may allow the magnetic stripes to be distinguished from one another.

  Data may be encoded in the magnetic stripe. An individual can read and / or replicate data encoded in the magnetic stripe, but may not accurately copy the distribution of magnetic particles in the magnetic stripe. Thus, if the fraudster attempts to clone the payment card by copying the data encoded in the first card onto the second card, the fraudster will use the magnetic fingerprint of the first card. It still can not be replicated in the second card. The first magnetic stripe in the first card can have unique magnetic properties based on the distribution of individual magnetic particles, which properties can be easily replicated in the second magnetic stripe of the second card I can not do it. Thus, even if the data encoded in the card is replicated, the magnetic fingerprints of each card based on physical magnetic particles can not be replicated.

  Thus, individual cards can be identified and / or distinguished from other cards based on magnetic fingerprints.

  FIG. 6 illustrates an example of using magnetic fingerprint data from a payment card to identify a user, according to one embodiment of the present invention. Magnetic fingerprints may be collected from the payment card (602). Magnetic fingerprints may be stored along with historical magnetic fingerprint data 604. The magnetic fingerprint may be transferred to magnetic fingerprint analyzer 610 for comparison 606 with one or more magnetic fingerprints collected in the past. The identification of the card based on the comparison can be evaluated (608). Optionally, an indication of the likelihood of fraud may be provided.

  Magnetic fingerprints may be collected for payment cards (602). Magnetic fingerprints can be collected using a card reader. For example, the payment card can be swiped through the card reader. The card reader can read one or more magnetic properties of the magnetic stripe of the payment card. The card reader may generate a magnetic fingerprint for the payment card. The magnetic fingerprint may be substantially unique to the payment card. The magnetic fingerprint may optionally be communicated to a device external to the card reader, such as a user device. In other embodiments, the card reader may communicate information regarding the magnetic properties read when the payment card is swiped through the card reader to a device external to the card reader such as a user device. A device external to the card reader may generate a magnetic fingerprint of the payment card based on the received magnetic property data. If the external device generates a magnetic fingerprint, the magnetic fingerprint may or may not be sent back to the card reader.

  Once the magnetic fingerprint is generated, the magnetic fingerprint may be stored along with the historical magnetic fingerprint data 604. Historical magnetic fingerprint data may be stored in one or more memory units. The historical magnetic fingerprint data can be stored in memory on the card reader's board, in memory on the board of the device external to the card reader (e.g., a user device or any separate device of the type described above). It can be stored or distributed across multiple devices (eg, peer-to-peer between card reader and external devices, cloud computing based infrastructure). In some embodiments, magnetic fingerprint data may be generated on the board of the card reader, stored on the card reader, the board of the external device, or distributed across multiple devices. In other embodiments, magnetic fingerprint data may be generated on the board of the external device, stored on the board of the external device or card reader, or distributed across multiple devices. One or more memory units may include a database. As described in FIG. 15, in some embodiments, magnetic fingerprint data may be stored in one or more databases connected to the server. A single copy of historical magnetic fingerprint data can be stored, or multiple copies can be stored. Multiple copies may be stored in different memory units. For example, multiple copies may be stored on different devices (e.g., a first copy on a card reader board, a second copy on an external device board).

  The historical magnetic fingerprint data may include magnetic fingerprint data collected by the card reader. The historical magnetic fingerprint data may include magnetic fingerprint data that belongs to the same payment card. For example, if the current magnetic fingerprint is collected for a first card, the historical magnetic fingerprint data may include magnetic fingerprints collected for the same card. The historical magnetic fingerprint data may include all fingerprint data for the same card collected using the same card reader. Historical magnetic fingerprint data may or may not include "registration" fingerprint data. In some embodiments, a user can register a payment card by performing an initial authentication read of the card. The magnetic fingerprints generated by the initial authentication reading may be stored as registration fingerprint data. Alternatively, registration fingerprint data is not specifically created. Various magnetic fingerprints from all card swipes for payment cards can be stored. Alternatively, only registration fingerprints may be stored. Alternatively, only the most recent magnetic fingerprint for a particular card may be stored. In some instances, only the most recent X magnetic fingerprints for a particular card may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6, 7, 8. , 9, 10 or more.

  In some embodiments, the historical magnetic fingerprint data may include magnetic fingerprint data collected by the card reader belonging to any payment card being read by the card reader. For example, the user may have multiple payment cards that may be swiped through the card reader. The historical magnetic fingerprint data may include magnetic fingerprint data belonging to various payment cards which may include what may be considered the same payment card. For example, if the current magnetic fingerprint is collected for a first card, the historical magnetic fingerprint data may include magnetic fingerprints collected for the same first card as well as other cards. The historical magnetic fingerprint data may include all fingerprint data for one or more cards collected using the same card reader. Historical magnetic fingerprint data may or may not include "registration" fingerprint data. In some embodiments, a user can register a payment card by performing an initial authentication read of the card. The magnetic fingerprint generated by the initial authentication reading may be stored as registration fingerprint data. Such registration may be performed for multiple cards. In some instances, each card may need to be registered with the card reader the first time a card is swiped. Alternatively, registration fingerprint data is not specifically created. Various magnetic fingerprints from all card swipes for any or all of the payment cards swiped through the card reader may be stored. Alternatively, only registered fingerprints may be stored per payment card. Alternatively, only the most recent magnetic fingerprint for each payment card may be stored. In some instances, only the most recent X magnetic fingerprints per payment card may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6, 7, 8. , 9, 10 or more.

  As discussed above, historical data may relate to data collected using a particular card reader. Alternatively, data from multiple card readers may be shared and / or aggregated. Historical data may include data from multiple card readers. The historical data may include magnetic fingerprints of payment cards collected by a plurality of card readers. The historical data may include the same card swiped on multiple card readers. The historical data may include different cards swiped through multiple card readers. The historical data may include data regarding payment cards read by a plurality of card readers. The historical data may include data regarding a plurality of payment cards read by a plurality of card readers. The historical data may include data regarding payment cards being swiped through all users or multiple card readers that may be providing information to the database of historical magnetic fingerprint data. An external device, such as, for example, a server or any other device described elsewhere herein, may receive magnetic fingerprint data from one or more card readers and store historical magnetic fingerprint data.

  After collecting the magnetic fingerprints, the magnetic fingerprints can be transferred to the magnetic fingerprint analyzer 610. The magnetic fingerprint analyzer may be configured to compare collected data to one or more magnetic fingerprints collected in the past (606), and to access card identification (608) based on the comparison. Step 606 may include comparing the magnetic fingerprint to historical magnetic fingerprint data. Magnetic fingerprints can be compared to magnetic fingerprints that come from the same card. For example, if a magnetic fingerprint is collected, additional information may be collected during the authentication read, which may include data encoded in the magnetic stripe. This additional information may include the payment card number and / or identification information regarding the payment card, such as the carrier. Additional information may be used to identify payment cards that are considered to be the same. For example, if the additional information indicates that the card is Visa # 1234 5678 1234 5678, the magnetic fingerprint of the card may be compared to other magnetic fingerprints belonging to Visa # 1234 5678 1234 5678. If the collected magnetic fingerprint matches a previously stored magnetic fingerprint, it may be verified that the card is the same physical card swiped in the past and identified as Visa # 1234 5678 1234 5678. If the collected magnetic fingerprint does not match the previously stored magnetic fingerprint, there may be an indication that the card currently being swiped may not be Visa # 1234 5678 1234 5678.

  The magnetic fingerprints may be compared to any or all previously collected fingerprints that are presumed to belong to the same card. For example, if a registration fingerprint is provided, the magnetic fingerprint can be compared to the registration fingerprint. The magnetic fingerprint may be compared to the registration fingerprint without being compared to any other fingerprint, may be compared to the registration fingerprint and the other fingerprint, or may be compared to the registration fingerprint It can be compared to other fingerprints without In some instances, magnetic fingerprints may be compared to the fingerprints collected most recently. The magnetic fingerprints are a predetermined number of fingerprints collected most recently, eg, two fingerprints collected most recently, three fingerprints collected most recently, four fingerprints collected most recently, most recently collected The five fingerprints may be compared, as well as any number of fingerprints collected most recently.

  The magnetic fingerprints can be compared to magnetic fingerprints coming from any card having information stored as historical magnetic fingerprint data. If magnetic fingerprints are collected, additional information may be collected during an authentication read, which may include data encoded in the magnetic stripe. As discussed above, this additional information may include payment card number and / or identification information regarding the payment card, such as the carrier. Additional information may be used to identify payment cards that are considered to be the same. For example, if the card indicates Visa # 1234 5678 1234 5678 and additional information indicates that the card's magnetic fingerprint is Visa # 1234 5678 1234 5678 as well as any other magnetic finger belonging to any other card which may have stored historical data. It can be compared to the print. If the collected magnetic fingerprint matches a previously stored magnetic fingerprint, the collected magnetic fingerprint is cross checked with additional information to swipe the card in the past and identify as Visa # 1234 5678 1234 5678 It can be verified that it is the same physical card.

  The magnetic fingerprints may be compared to any or all of the previously collected fingerprints that were previously swiped and considered to belong to any of the cards stored in the historical data. For example, if registration fingerprints are provided for various cards, the magnetic fingerprints may be compared to the registration fingerprints of the various cards. The magnetic fingerprint may be compared to the registration fingerprint without being compared to any other fingerprint, may be compared to the registration fingerprint and the other fingerprint, or may be compared to the registration fingerprint It can be compared to other fingerprints without In some instances, the magnetic fingerprints may be compared to the most recently collected fingerprints for each of the payment cards. The magnetic fingerprints are a predetermined number of fingerprints collected most recently, eg, two fingerprints collected most recently, three fingerprints collected most recently, four fingerprints collected most recently, most recently collected The five fingerprints may be compared, as well as any number of fingerprints collected most recently.

  The identification of the card based on the comparison can be evaluated (608). The identification may include authenticating the payment card based on the card information as being the actual card that the payment card claims to be. For example, the card may be claimed as Visa # 1234 5678 1234 5678. For the same additional information, it is currently swiped if the acquired magnetic fingerprint does not match the previously stored magnetic fingerprint, or if the same magnetic fingerprint does not match the additional information previously stored There may be an indication that the cards you are playing may not be the same. For example, if the magnetic fingerprints do not match and there is a past magnetic fingerprint for Visa # 1234 5678 1234 5678, then the current payment card may not be Visa # 1234 5678 1234 5678.

  Similarly, the magnetic fingerprint can be compared to multiple fingerprints in the historical data and may be found to match the magnetic fingerprint of the second card. If the second card is Visa # 1234 5678 1234 5678, then the current payment card may be verified as Visa # 1234 5678 1234 5678. If the second card is Mastercard # 4321 9876 4321 9876 and the current card should be Visa # 1234 5678 1234 5678 based on the additional card information, there may be a mismatch. There may be an indication that the current card may not be Visa # 1234 5678 1234 5678.

  Additional information may or may not be considered when comparing magnetic fingerprints. In some cases, additional information may be used to identify the card. For example, magnetic fingerprints can be collected and compared to various magnetic fingerprints in historical data. This fingerprint may or may not include a registration fingerprint. The card may then be identified as a card that matches the fingerprint to be collected. For example, if the fingerprint to be collected matches the second fingerprint and it is determined that the second fingerprint belongs to the card of Visa # 1234 5678 1234 5678, the card currently being swiped is Visa # 1234 5678 1234 5678 may be identified. Additional information about the card, such as identification card information, may or may not be simultaneously collected and compared.

  Optionally, an indication of the likelihood of fraud can be provided. For example, the data on the card is encoded such that the card identifies as a particular card (eg Visa # 1234 5678 1234 5678), and a magnetic fingerprint is collected in the past of a self-identifying card (eg Visa # 1234 5678 1234 5678) If it does not match one or more magnetic fingerprints, the possibility of fraud may be provided. The probability of fraud may be a binary indicator (eg fraud alert, no fraud) or may be provided as a risk value (eg numerical value such as percentage or grade value such as a grade by letters). For example, a fraud grade of 9 may give a higher probability of fraud than a fraud grade of 2.

  In some embodiments, to be considered a match (eg, a 100% match), the collected magnetic fingerprints may need to be completely identical to the previously stored magnetic fingerprints. Alternatively, there may be some tolerance on how closely the magnetic fingerprints match. If the match level is above a predetermined threshold, those magnetic fingerprints may be considered as a match. For example, if the fingerprints match more than 70%, 75%, 80%, 85%, 90%, 95%, 97%, 99%, 99.9%, 99.99%, then the fingerprints match It can be considered.

  In some embodiments, the magnetic fingerprint of the card may change over time. For example, the magnetic stripe may be slightly demagnetized. Scratches and other wear can affect the magnetic stripe. Such natural adjustment to the magnetic stripe can affect the magnetic fingerprint. In some instances, when the magnetic stripe is routinely used, the tolerance on how closely the magnetic fingerprints match may allow for some natural aging of the magnetic fingerprint. However, if catastrophic changes occur, such changes may be out of tolerance and may be flagged as potentially different cards.

  The comparison of magnetic fingerprints may be to the original registration fingerprint. The threshold may allow for some variation from the original swipe, but may not allow the card to deviate too far from the original swipe. In another example, the comparison of magnetic fingerprints may be to a single immediate or multiple immediate fingerprints. The threshold may allow for some changes to past swipes, and may be more amenable to progress over time. For example, magnetic fingerprints can gradually change from swipe to swipe over time, and in contrast to more recent fingerprints, can deviate more significantly from the original registration fingerprint over time. In some instances, multiple thresholds may be provided. For example, comparing the magnetic fingerprint with the original registration fingerprint (eg, requiring a match of at least 80%) may provide a lower threshold while comparing the magnetic fingerprint with a recent fingerprint (eg, A higher threshold may be provided if it requires at least 99% match with the immediate fingerprint). The magnetic fingerprint may be compared to the average of one or more previous fingerprints. In some cases, the magnetic fingerprints can be compared to the average of all past fingerprints.

  As discussed above, fraudulent indications may provide indications about fraud risk levels. The fraud risk level may optionally depend on the magnetic fingerprint match level. For example, if the magnetic fingerprint is a 100% match, the fraud risk level may be zero or very low. If the magnetic fingerprint is a 70% match, the fraud risk level may be moderate; if the magnetic fingerprint is a 40% match, the fraud risk level may be high. The fraud risk level may be inversely proportional to how high the fingerprint match is. Higher matches may correlate to lower fraud risk, and lower matches may correlate to higher fraud risk.

  In some embodiments, one or more individuals may be alerted when the risk of fraud is detected. For example, a user swiping a card may or may not be notified that his card has been flagged with some risk of fraud. The entity the user is trying to trade may or may not be notified of the risk of fraud. For example, if the user is trying to purchase an item from an e-commerce site, the e-commerce site may be informed that the transaction is flagged with some risk of fraud. The transaction itself may or may not be allowed to proceed. In some cases, the transaction can be suspended if there is any risk of fraud. Alternatively, if there is some risk of fraud, but it is determined that it is low, one or more parties may be informed about the risk of some fraud while the transaction may continue and / or further examinations Can be done. If the risk of fraud is above a threshold level (e.g. reaching a moderate or high risk of fraud), the transaction may be suspended.

  In some instances, the threshold for stopping the transaction may depend on the value of the transaction or other characteristics of the transaction. For example, for high value transactions, the threshold for stopping the transaction may be lower than for low value transactions. For example, if the transaction is for a large amount of money, even a low risk of fraud may cause the transaction to stop, while a smaller amount may require a higher risk of fraud to stop the transaction. Alternatively, the threshold for stopping the transaction may be the same for all transactions.

  FIG. 7 shows an example of various swipe characteristics of a payment card, according to one embodiment of the present invention. The payment cards 702a, 702b may be read by the card reader 700a, 700b. The payment card can have magnetic stripes 703a, 703b that can be read by a card reader.

  As described above, payment cards 702a, 702b may have magnetic stripes 703a, 703b that may be read by card reader 700a, 700b. The card reader may read the magnetic stripe as the payment card is swipe by the card reader or swipe through the card reader. The card reader may collect information from the magnetic stripe during swipes. For example, the information may include identification information about the card (e.g., carrier, card number, user's name, etc.). Payment card authorization reading may be performed while the swipe is taking place. Authentication reading may include collecting payment card magnetic fingerprints and / or payment card swipe characteristics. The swipe characteristics of the payment card may be determined based on the data collected by the card reader. The swipe characteristics of the payment card may be determined based on data collected using the magnetic head of the card reader.

  Examples of swipe characteristics may include swipe speed, swipe direction, swipe angle (eg, swipe path), swipe timing, and / or swipe pressure. Different users may tend to swipe cards in different ways. For example, a first user may tend to swipe the card very quickly, while a second user may swipe the card more slowly. In another example, a first user may tend to swipe the card from left to right while a second user may tend to swipe from right to left. Such swipe characteristics may be useful in identifying a user swiping a card. For example, if card A belongs to user A constantly and quickly swiping from left to right, and the individual slowly swipes from right to left to make a transaction using card A, the individual may not be user A It may be possible to identify sex.

  The card reader may be able to detect the speed of the swipe. For example, the user may swipe the card at various speeds. For example, as shown in scenario A, the card 702a may be moving quickly as indicated by the two arrows, while in scenario B the card 702b may move more slowly as indicated by the single arrow. There is a possibility. The card reader is a few tens of meters per second, a few meters per second, a meter per second, a few centimeters per second, a few centimeters per second, a few millimeters per second, a few millimeters per second It may be possible to distinguish between card swipe speeds up to a few tenths of a millimeter per second, or a few micrometers per second. For example, if the card reader can distinguish card swipe speeds up to a few centimeters per second, then the card reader may swipe the card at 5 cm / s when the first user and 7 cm / s when the second user moves the card. You can distinguish when you can swipe with. The card reader can optionally measure the actual swipe speed of the card. The swipe speed is several tens of meters per second, several meters per second, one meter per second, several tens centimeters per second, several centimeters per second, several millimeters per second, a sufficient number per second It can be as accurate as millimeters, a few tenths of a second per second, or even a few micrometers per second. For example, a card swipe of 10.27 cm / s may be measured if the accuracy is of the order of a few millimeters per second.

  The card reader may be able to detect the direction of the swipe. For example, the user may swipe in various directions. For example, if the card reader includes a groove running horizontally, the user may swipe left to right or right to left. If the card reader includes grooves running vertically, the user may swipe from top to bottom or from bottom to top. Regardless of whether the card reader has a groove or any other area for reading the magnetic stripe of the card, the user may move the card in a first direction or in a second direction substantially opposite to the first direction. You can swipe. The card reader may be able to detect the direction in which the card is swiped.

  The card reader may be able to detect the angle of the swipe (e.g. swipe path). For example, the card may be inclined to the card reader or parallel to the card reader. For example, as shown in scenario A, the card 702a may be angled such that the leading edge of the swipe moves away from the card reader while the trailing edge of the swipe moves toward the card reader. Scenario B illustrates a situation where the card 702b may be beveled such that the leading edge forms an angle towards the card reader while the trailing edge can form an angle away from the card reader. In some scenarios, the card may be parallel to the card reader such that the leading and trailing edges make the same angle with the card reader. The card reader may be able to detect the angle or position of the swipe of the card relative to the card reader up to multiple degrees, a single degree, a few tenths, a few hundredths or a few thousandths of degrees . For example, the card is about 45 degrees, 40 degrees, 35 degrees, 30 degrees, 25 degrees, 20 degrees, 15 degrees, 10 degrees, 5 degrees, 4 degrees, 3 degrees, 2 degrees, 1 degree, 0.degree. 5 degrees, 0.1 degrees, or more than 0 degrees, less than or equal to it. The angle of the payment card relative to the card reader may remain the same throughout the swipe, or may be random throughout the swipe. Optionally, the angle at each point in the swipe can be measured.

  The swipe path of the card can be measured. The swipe path may include curvature, angle, and / or distance as to how the card is swiped to the card reader. For example, as shown in scenario A, the swipe path may be curved so that the interior of the curve points towards the card reader 700a. Scenario B shows a swipe path where the inside of the curve is bent away from the card reader 700b. In some cases, the swipe path may be straight without any bending. The curvature of the path can be measured. The change in curvature value on the swipe path can be measured. Any details of the swipe path itself, such as the position and / or orientation of the payment card relative to the card reader at any time of the swipe, may be detected and / or recorded by the card reader.

  The position of the card relative to the card reader can be detected. For example, some users may push the card deep into the groove when swiping the card, so the magnetic stripe of the card is as deep as possible into the groove. Other users may not push as far in there, so there may be some space between the card and the deepest part of the groove. This space can affect the placement of the magnetic stripe relative to the magnetic sensor. In some cases, lateral movement of the magnetic stripe relative to the magnetic sensor over time (for example, depending on how deep the card is in the groove, the lateral direction is perpendicular to the main direction of the swipe ) Can be sought.

  The card reader may be able to detect swipe timing. The swipe timing may be related to the total time it takes to swipe the card. The timing of the swipe may be related to the speed of the swipe. The swipe timing may also relate to the timing of each component of the swipe path. The position / orientation of the card can be sampled continuously. In some instances, card position / orientation may be sampled at regular or irregular time intervals. The time interval is every 10 seconds, every 5 seconds, every 3 seconds, every 2 seconds, every 1 second, every 0.8 seconds, every 0.5 seconds, every 0.3 seconds, every 0.2 seconds, 0.1 Every second, every 0.08 seconds, every 0.05 seconds, every 0.03 seconds, every 0.01 seconds, every 0.008 seconds, every 0.005 seconds, every 0.003 seconds, or 0.001 seconds It may be on the order of each or less. Such sampling frequency may be higher or lower than or equal to any of the values described. The sampling frequency may be preset or variable. The user may be able to determine the sampling frequency in advance. The sampling frequency can be varied based on the magnetic stripe being detected based on the characteristics of the magnetic stripe.

  The card reader may be able to detect swipe pressure. For example, the card reader may be able to detect if the magnetic stripe is heavily rubbed with the card reader's magnetic sensor or if it is more weakly pressed against the magnetic sensor. In some cases, a gap may be provided between the card and the magnetic sensor. In some instances, the size of the gap may be measured and / or distinguished by a card reader.

  A card reader can be used to detect one, two, three or more swipe characteristics. When considering multiple swipe characteristics in combination, one or more of the swipe characteristics can be weighted equal or unequal. For example, even if the same user swipes, some swipe characteristics may vary more than other swipe characteristics. This swipe specification can have a lower weight than swipe characteristics that tend to have less variation. In some cases, a comparison threshold may be provided. A swipe characteristic with high variability may have a lower threshold than a swipe characteristic with low variability. Thus, a set of user swipe characteristics can be analyzed.

  Thus, users may be identified and / or distinguished from other users based on swipe characteristics. Such identification and / or distinction may be irrelevant to whether the card being swiped is identified as a particular card or approved as a particular card. Regardless of whether the card itself is flagged because of fraud, the user can be identified based on swipe characteristics. In some instances, the card may be identified as the original card, but possibly the user may be flagged based on swipe characteristics as not being an authorized user.

  FIG. 8 illustrates an example of using a payment card swipe feature to identify a user, according to one embodiment of the present invention. A set of one or more swipe characteristics may be collected from the payment card (802). The swipe characteristics may be stored with historical swipe characteristics data 804. The swipe characteristics may be transferred to the swipe analyzer 810 for comparison 806 with one or more sets of swipe characteristics collected in the past. The identity of the user based on the comparison may be evaluated (808). Optionally, an indication of the likelihood of fraud may be provided.

  One set of swipe characteristics may be collected for payment card 802. Swipe characteristics may be collected using a card reader. For example, a payment card can be swiped through the card reader. The card reader can read one or more magnetic properties of the magnetic stripe of the payment card. The card reader may generate a set of swipe characteristics for the payment card from that particular swipe. The swipe characteristic may be substantially specific to the user or may be used as a metric to distinguish the user from other users who may have different swipe characteristics. The swipe feature may optionally be communicated to a device external to the card reader, such as a user device. In other embodiments, the card reader may communicate information regarding the swipe read as the payment card swipes through the card reader to a device external to the card reader such as a user device. A device external to the card reader may generate a payment card swipe characteristic for the swipe based on the received data. If the external device generates a swipe feature, the swipe feature may or may not be sent back to the card reader.

  Once a set of swipe characteristics is generated, the swipe characteristics may be stored along with historical swipe characteristic data 804. Historical swipe characteristic data may be stored in one or more memory units. Historical swipe characteristic data can be stored in memory on the board of the card reader and stored in memory on the board of a device external to the card reader (e.g. a user device or any separate device of the type described above) Or distributed across multiple devices (eg, peer-to-peer between a card reader and an external device, cloud computing based infrastructure). In some embodiments, swipe property data may be generated on the board of the card reader, stored on the card reader, board of the external device, or distributed across multiple devices. In other embodiments, swipe property data may be generated on the board of the external device, stored on the board of the external device or card reader, or distributed across multiple devices. One or more memory units may include a database. In some embodiments, swipe characteristics may be stored in a database connected to the swipe analyzer. A single copy of historical swipe characteristic data can be stored, or multiple copies can be stored. Multiple copies may be stored in different memory units. For example, multiple copies may be stored on different devices (e.g., a first copy on a card reader board, a second copy on an external device board).

  The historical swipe characteristic data may include swipe characteristic data collected by the card reader. The historical swipe characteristic data may include swipe characteristic data that belongs to the same user. For example, if a current set of swipe characteristics is collected for a first user, the historical swipe characteristics data may include swipe characteristics collected for the same user. Historical swipe characteristic data may include all swipe characteristic data for the same user (and / or the same card) collected using the same card reader. Historical swipe characteristic data may or may not include "registration" swipe characteristic data. In some embodiments, a user can register a payment card by performing an initial authentication read of the card. The set of swipe characteristics generated by the initial authentication reading may be stored as registration swipe characteristic data. Alternatively, no registered swipe characteristic data is created. Various swipe characteristics derived from all card swipes for the user (and / or the same payment card) may be stored. Alternatively, only registered swipe characteristics may be stored. Alternatively, only the closest set of swipe characteristics for a particular user (and / or the user's card) may be stored. In some instances, only the last X swipe characteristics for a particular user (and / or card) may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 or more.

  In some embodiments, historical swipe characteristic data may include swipe characteristic data collected by a card reader belonging to any user (and / or any payment card) that has interacted with the card reader. For example, multiple users may be swiping the payment card through the card reader. The historical swipe characteristic data may include swipe characteristic data belonging to different users (and / or payment cards of the same user or different users) that may include persons identified as the same user. For example, if a current set of swipe characteristics is collected for a first card, historical swipe characteristics data may include multiple sets of swipe characteristics collected for the same user as well as other users. Historical swipe characteristic data may include all swipe characteristics for one or more users collected using the same card reader. Historical swipe characteristic data may or may not include "registration" swipe characteristic data. In some embodiments, a user can register a payment card by performing an initial authentication read of the card. The set of swipe characteristics generated by the initial authentication reading may be stored as registration swipe characteristic data for the user or for the user's card. Such registration may be performed for multiple cards and / or multiple users. In some instances, each card may need to be registered with the card reader the first time a card is swiped. Alternatively, no registered swipe characteristic data is created. Various sets of swipe characteristics derived from all card swipes for any or all of the payment cards swiped through the card reader may be stored. Alternatively, only registered swipe characteristics may be stored per payment card or per user. Alternatively, only the last set of swipe characteristics per payment card or per user may be stored. In some instances, only the most recent X sets of swipes per payment card or per user may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6. 7, 8, 9, 10 or more.

  As discussed above, historical data may relate to data collected using a particular card reader. Alternatively, data from multiple card readers may be shared and / or aggregated. Historical data may include data from multiple card readers. The historical data may include payment card swipe characteristics collected by multiple card readers. The historical data may include the same card swiped on multiple card readers. Historical data may include the same user swiping cards on multiple card readers. Historical data may include various cards swiped through multiple card readers. Historical data may include various users swiping cards through multiple card readers. Historical data may include data regarding payment cards read by a user or multiple card readers. The historical data may include data regarding a plurality of payment cards read by a plurality of users or a plurality of card readers. The historical data may include data regarding payment cards being swiped through all users or multiple card readers that may be providing information to the historical swipe characteristic data database. An external device, such as a server or any other device described elsewhere herein, may receive swipe characteristic data from one or more card readers and store historical swipe characteristic data.

  After collecting a set of swipe characteristics, the swipe characteristics can be transferred to the swipe analyzer 810. The swipe analyzer may be configured to compare 806 the collected data to one or more sets of swipe characteristics collected in the past. Step 806 may include comparing the set of swipe characteristics to historical swipe characteristic data. One set of swipe characteristics may be compared to multiple sets of swipe characteristics that come from the same user (or for the same card user). For example, if a set of swipe characteristics is collected, additional information may be collected during an authentication read that may include data encoded in the magnetic stripe. This additional information may include the payment card number and / or identification information regarding the payment card, such as the carrier. This additional information may include identification information such as the user's name or other identifier, or may be used to access an account where the user's name or other identifier may be accessed. The additional information may be used to identify who is believed to be the same user. For example, if the additional information indicates that the user is John Doe, one set of swipe characteristics of the card can be compared to other sets of swipe characteristics belonging to John Doe. This swipe property can be compared to the swipe property for all cards of John Doe, or the swipe property for just the same John Doe card that is being swiped. If the collected swipe properties match the swipe properties stored in the past, it may be verified that the user may be the same user as identified in the past as John Doe. There may be an indication that the current user swiping the card is not John Doe if the collected swipe properties do not match previously stored swipe properties.

  One set of swipe characteristics may be compared to any or all of the previously collected sets of swipe characteristics estimated to belong to the same user. This comparison can be narrowed more clearly to the user's same card, or can be applied to any card or all cards of the same user. For example, if a set of registered swipe characteristics is provided, the set of collected swipe characteristics can be compared to the set of registered swipe characteristics. The swipe characteristics collected may be compared to the registered swipe characteristics without being compared to any other swipe characteristics, compared to the registered swipe characteristics and other swipe characteristics, or with the registered swipe characteristics. It can be compared to other swipe characteristics without being compared. In some instances, swipe characteristics may be compared to the most recently collected swipe characteristics. The swipe feature is a predetermined number of swipe features collected most recently, such as 2 sets of swipe features collected most recently, 3 sets of swipe features collected most recently, 4 sets of swipe features collected most recently, It may be compared to the 5 sets of swipe characteristics collected, and similarly for any number of fingerprints collected most recently.

  The swipe characteristics may be compared to swipe characteristics that may come from any user whose information is stored in historical swipe characteristic data. If a set of swipe characteristics is collected, additional information may be collected during the authentication read, which may include data encoded in the magnetic stripe. As discussed above, the additional information may include identification information that may be used to identify the user. The additional information may be used to identify who is believed to be the same user. For example, if additional information indicates that the user is John Doe or additional information is used to find that the user is John Doe, the card swipe characteristic may have John Doe as well as the stored historical data. It may be compared to other swipe characteristics belonging to any other user. If the swipe property collected matches the swipe property stored in the past, then the user is swipe the card in the past and is the same user identified as John Doe by cross-checking the collected swipe property with additional information Can be verified.

  One set of swipe characteristics is compared to any or all of the previously collected sets of swipe characteristics that are presumed to belong to any of the users who swipe cards in the past and have stored data in historical data. It can be done. For example, if swipe characteristics are provided for different users, the swipe characteristics may be compared to registered swipe characteristics of different users. The swipe characteristics may be compared to the registered swipe characteristics without being compared to any other swipe characteristics, to the registered swipe characteristics and to other swipe characteristics, or to the registered swipe characteristics It can be compared to other swipe characteristics without having to. In some instances, the swipe characteristics may be compared to the most recently collected swipe characteristics for the user or for each of the user's payment cards. The swipe feature is a predetermined number of swipe features collected most recently, such as 2 sets of swipe features collected most recently, 3 sets of swipe features collected most recently, 4 sets of swipe features collected most recently, It may be compared to the five sets of swipe characteristics collected, and similarly for any number of sets of swipe characteristics collected most recently.

  The identity of the user based on the comparison may be evaluated (808). The identification may include authenticating the user based on the card information as being an actual user. For example, a card may belong to John Doe. For the same additional information, if the set of swipe characteristics collected does not match multiple sets of swipe characteristics stored in the past, or for the same set of swipe characteristics, additional information matches the additional information stored in the past If not, there may be an indication that the card currently being swiped may not belong to the same user. For example, if the swipe characteristics do not match and there is a set of past swipe characteristics for John Doe, then the current user attempting the swipe may not be John Doe. Similarly, the swipe characteristics may be compared to multiple sets of swipe characteristics in the historical data and may be found to match the second user's set of swipe characteristics. If the second user is John Doe, then the current user may be verified to be John Doe. There may be a mismatch if it is assumed that the second user is Mary Smith and the current user of the swipe card is John Doe. There may be an indication that the current user is not John Doe.

  Additional information may or may not be considered when comparing sets of swipe characteristics. In some cases, additional information may be used to identify the user. For example, swipe characteristics can be collected and compared to various sets of swipe characteristics in historical data. The swipe feature may or may not include a set of registered swipe features. The user may be identified as a user that matches the collected swipe characteristics. The card may be identified as belonging to the same user as the user of the card with collected matching swipe characteristics. For example, if it is determined that the set of collected swipe properties matches the set of second swipe properties and the set of second swipe properties is determined to belong to John Doe, then the card currently being swiped is John. It may be identified as being swiped by Doe. Additional information about the card, such as identification card information, may or may not be simultaneously collected and compared.

  Optionally, an indication of the likelihood of fraud can be provided. For example, the data on the card is encoded as the card identifies as a particular user of the card (eg John Doe) and the swipe characteristics are collected in the past of the same user (eg John Doe) or the user of the self-identifying card 1 If it does not match one or more swipe characteristics, the possibility of fraud may be provided. The probability of fraud may be a binary indicator (eg fraud alert, no fraud) or may be provided as a risk value (eg numerical value such as percentage or grade value such as a grade by letters). For example, a fraud grade of 9 may give a higher probability of fraud than a fraud grade of 2.

  In some embodiments, to be considered a match (e.g., a 100% match), the swipe properties collected may need to be completely identical to one or more sets of swipe properties stored in the past. In some cases, a perfect 100% match may be suspicious. For example, it is likely that there will be some slight variation each time the user swipes the card. The probability that an individual swipes a card with exactly the same swipe characteristics is physically very low. Having exactly the same characteristics may be an indicator of a kind of replay attack.

  Alternatively, there may be some tolerance on how closely the swipe characteristics match. If the match level is above a predetermined threshold, their swipe characteristics may be considered as a match. For example, if the swipe properties match more than 70%, 75%, 80%, 85%, 90%, 95%, 97%, 99%, 99.9%, 99.99%, their swipe properties are identical It can be considered. In some instances a matching "sweet spot" may be provided, where the sweet spot may have swipe characteristics above a certain threshold but below a perfect match that may be considered suspicious. For example, to construct a proper match, the swipe characteristics may be less than about 100%, 99.999%, 99.99%, 99.9%, 99%, 98%, 97%, 95%, or 90%. obtain. To construct a match, the swipe property may have a value greater than any of the lower values described herein and at the same time less than any of the higher values described herein. For example, to meet matching requirements, the swipe property may be less than 99.99% while having an overall value greater than 80% (e.g., multiple swipe property weights or a single swipe property value).

  In some embodiments, the swipe characteristics of the user's card may change over time. For example, the user may adjust his swipe naturally. In some cases, such adjustments may be in response to the user's aging or physical conditions of the user. The user may develop a fixed physical habit over time. These changes can affect the swipe characteristics. In some instances, tolerances as to how closely the swipe characteristics match may allow for some natural aging of the swipe characteristics. In fact, some degree of change may be expected, and it seems suspicious that no change will occur. However, if catastrophic changes occur, such changes may be out of tolerance and may be flagged as potentially different users. For example, if the user has a past that swipes from left to right, then it may be suspicious if the user swipes suddenly from right to left. Or if multiple swipe characteristics change significantly at one time, the changes may indicate different users.

  The comparison of swipe characteristics may be to a set of original registered swipe characteristics. The threshold may allow for some variation from the original swipe, but may not admit that the swipe deviates too much from the original swipe. In another example, the comparison of swipe characteristics may be to a single immediate or multiple immediate swipe. The threshold may allow for some changes to past swipes, and may be more amenable to progress over time. For example, the swipe characteristics may change gradually with time as the swipe changes, and in contrast to the more recent swipe characteristics, may deviate more significantly from the set of original registration swipe characteristics over time . In some instances, multiple thresholds may be provided. For example, a lower threshold may be provided when comparing swipe properties to a set of original registered swipe properties (eg requiring a match of at least 60%) while a set of recently acquired swipe properties may be provided. A higher threshold may be provided if compared to (e.g. requiring a match of at least 85% with the immediate fingerprint). The swipe characteristic may be compared to the average of one or more previous sets of swipe characteristics. In some instances, the swipe characteristics may be compared to the average of all past sets of swipe characteristics.

  In some instances, the expected level of variation may depend on historical swipe characteristic data, as some variation of the user's swipe characteristics is expected over time. Larger amounts of historical swipe characterization data may result in more accurate predictions of variability. For example, user A may have a low degree of variability in swipe speed over time, no variability in the swipe direction, and moderate degree of variability in the shape of the swipe path. User B may have a high degree of variability in swipe speed over time, low variability in the swipe direction, and low variability in the shape of the swipe path. Such variability can be taken into account when determining whether the swipe characteristics match. For example, if a higher degree of variability is indicated for a particular property, that property can be less weighted or have a lower threshold for matching. In some instances, both the minimum and maximum endpoints of the threshold may be lowered if greater degrees of variability are expected, or only one of the endpoints (minimum or maximum) may be lowered. Optionally, both the minimum and maximum endpoints of the threshold can be raised if a smaller degree of variation is expected, or only one of the endpoints (minimum or maximum) can be raised. In some instances, if there is not much historical data, then the variability can be considered high or low. In some instances, historical data of multiple users can be compared to determine what the predetermined level of variation for a particular swipe characteristic is. For example, if it can be determined from a collection of users that user A tends to be relatively new and that the variation in speed and direction tends to be low while the variation in pressure tends to be high, then to make assumptions specific to user A Such an assumption can be made for user A until sufficient historical data is collected for user A. In alternative embodiments, no user specific assumptions are made. In some cases, the average of multiple users can be used to reveal the prospect of variability.

  As discussed above, fraudulent indications may provide indications about fraud risk levels. The fraud risk level may optionally be dependent on the match level of the swipe characteristics. For example, if the comparison of swipe characteristics is included within the sweet spot range, the fraud risk level may be low. If the comparison of swipe characteristics is outside the sweet spot range, the fraud risk level may increase. Different layers or degrees of sweet spots may be provided which may be correlated to different fraud risk levels. The innermost layer of sweet spots may have the lowest fraud risk level, and the respective graded outer layers of sweet spots may have higher fraud risk levels.

  In some embodiments, one or more individuals may be alerted when the risk of fraud is detected. For example, a user swiping a card may or may not be notified that his swipe has been flagged with some risk of fraud. The entity the user is trying to trade may or may not be notified of the risk of fraud. For example, if the user is trying to purchase an item from an e-commerce site, the e-commerce site may be informed that the transaction is flagged with some risk of fraud. The transaction itself may or may not be allowed to proceed. In some cases, the transaction can be suspended if there is any risk of fraud. Alternatively, if there is some risk of fraud, but it is determined that it is low, one or more parties may be informed about the risk of some fraud while the transaction may continue and / or further examinations Can be done. If the risk of fraud is above a threshold level (e.g. reaching a moderate or high risk of fraud), the transaction may be suspended.

  In some instances, the threshold for stopping the transaction may depend on the value of the transaction or other characteristics of the transaction. For example, for high value transactions, the threshold for stopping the transaction may be lower than for low value transactions. For example, if the transaction is for a large amount of money, even a low risk of fraud may cause the transaction to stop, while a smaller amount may require a higher risk of fraud to stop the transaction. Alternatively, the threshold for stopping the transaction may be the same for all transactions.

  Magnetic fingerprint and / or swipe characteristics may be collected from an authentication reading of a card using a card reader. Both sets of data may be collected or a single set of data may be collected. Magnetic fingerprints and / or swipe characteristics may be used individually or in combination for identification. The magnetic fingerprint and / or swipe properties may be used individually or in combination in authenticating the card and / or the user. Magnetic fingerprints and / or swipe properties may be used individually or in combination in approving a transaction. Magnetic fingerprint and / or swipe characteristics may be used alone or in combination to detect fraud.

  In some embodiments, if both magnetic fingerprint and swipe characteristics are analyzed, both data may be collected from a single authentication read of the card (eg, a single swipe of the card). Both magnetic fingerprint and swipe characteristics can be evaluated simultaneously. In some other embodiments, the magnetic fingerprint may be evaluated first to identify and / or authenticate the card. The swipe feature may then be used to identify and / or authenticate the user. If the magnetic fingerprint phase detects a payment card problem, the process may or may not continue with the swipe phase. Alternatively, a set of swipe characteristics may be initially evaluated to identify and / or authenticate the user. Magnetic fingerprints may then be used to identify and / or authenticate the card. If the swipe feature stage detects a payment card user problem, the process may or may not continue with the magnetic fingerprint stage.

  FIG. 10 shows an example of an apparatus 1000a, 1000b in which location information may be collected, according to an embodiment of the present invention.

  As discussed above, these devices may be user devices, card readers, or both. The position of the device can change over time. In some instances, the orientation and / or spatial position of the device may change over time. Tables 1 to 3 below show a sample of device location information that can be collected and these are given as examples only and not by way of limitation. Any combination of orientation and spatial location information, static and dynamic information, and / or information gathering at a single point in time or multiple points in time may be provided.

  One or more sensors can be provided that can assist in the collection of location information about the device. As shown in scenario A, the device 1000a (eg, user device and / or card reader) may be provided at a first position while in scenario B the device 1000b (eg, user device and / or card reader) is at a first position And a second position different from For example, the devices may be in different orientations over time. For example, with respect to a static frame of reference (eg, indicated by x, y, and z axes), the device is indicated by various orientations (eg, a, b, and c in scenario A and a 'in x). , B 'and c' axes). The angle between these axes can change over time. As discussed above, position information (eg, angle information and spatial position information) can be determined to a high degree of accuracy and / or precision. The orientation of the device can be evaluated over one, two or three axes. The spatial position of the device can be evaluated along one, two or three axes.

  Authentication readings can be taken at various times. The user may swipe the card at various times. It is possible that devices (e.g. user devices or card readers) may have similar positions between different swipes, but the devices are completely identical, especially if the position is measured to a high degree of accuracy and / or precision. The possibility of having a position is very low. At least some minor variations in device orientation and / or spatial position may be expected between swipes. Thus, if the positions taken in different swipes are completely identical, among other things with a high degree of accuracy and / or precision, it is possible that a replay attack is taking place. For example, a fraudster may have recorded a payment card swipe containing location information in the past and may have replayed a payment card past swipe. In one example, the orientation of the device may be read as [12.56736 degrees, -5.23957 degrees, and 0.31984 degrees] during the first swipe. If it is read during the second swipe that the device orientation is exactly the same [12.56736 degrees, -5.23957 degrees, and 0.31984 degrees], such a match is extremely unlikely and may indicate a replay attack. is there. The same is true if the spatial position is identical between swipes to a high degree of accuracy. In particular, if the device (e.g. a user device and / or a card reader) is a mobile device or a portable device, the location information is likely to change. Even though the device is on a surface during the swipe, the swipe itself is likely to cause some vibration or movement to the device.

  Optionally, the position of the device relative to time can be evaluated. For example, if the first position is recorded at a first time and the second position is recorded at a second time, the change in position associated with the change in time can be evaluated. For example, the difference between the second position and the first position (for example, the second position minus the first position) may be the difference between the second time and the first time (for example, the second time minus the first time) The rate of change can be assessed by dividing by 求 め る). A warning may be issued if the device is faster than it can reasonably cross the position. For example, if it is determined that the device is in California during the first swipe and is determined to be in New York during the second swipe after 5 minutes, then that device is given its location. It may be determined that it is not possible to cross in time, and an indication of possible fraud may be provided. As explained above, such reading may be performed based on sensors on the user device and / or the card reader.

  Thus, the transaction and / or the authentication reading of the transaction may be evaluated for the likelihood of tampering or fraud. If the location information does not indicate an increase in the likelihood of fraud, the identity of the user may be verified and / or the transaction may be authorized.

  FIG. 11 shows an example of using location data to identify a user, according to one embodiment of the present invention. A set of location data may be collected from the payment card (1102). The swipe characteristics may be stored with historical position data 1104. The position data may be compared 1106 to one or more sets of position data collected in the past. The identity of the user based on the comparison may be evaluated (1108). Optionally, an indication of the likelihood of fraud may be provided.

  A set of position data may be collected during an authentication read (e.g., a card swipe) (1102). Position data may be collected using a card reader and / or one or more sensors on the user device. For example, a payment card can be swiped through the card reader. The card reader can read one or more magnetic properties of the magnetic stripe of the payment card. The card reader and / or the user device may generate a set of position information for that particular swipe. The position data may include the orientation and / or spatial position of the card reader and / or user device at a single point in time or over multiple points in time. Location information may be substantially unique to the swipe. Sensor data from the card reader and / or the user device may optionally be communicated to devices external to the card reader such as the user device and / or to devices external to the user device. The sensor data may be interpreted on the card reader and / or the board of the user device to generate a set of position data. Alternatively, devices external to the card reader and / or devices external to the user device may generate position data based on the received sensor data. If the external device generates position data, the position data may or may not be sent back to the card reader and / or the user device.

  Once a set of position data is generated, the position data may be stored along with the historical position data 1104. Historical position data may be stored in one or more memory units. The historical position data may be stored in a memory on the card reader and / or the board of the user device, the card reader and / or an external device of the user device (e.g. a separate device of the user device or any of the above types Can be stored in memory on the board) or distributed across multiple devices (eg, peer-to-peer between a card reader and / or user devices and external devices, cloud computing based infrastructure). In some embodiments, position data may be generated on the board of the card reader, stored on the board of the card reader, user device, external device, or distributed across multiple devices. In other embodiments, position data may be generated on the board of the external device and may be stored on the board of the external device, card reader, and / or user device or distributed across multiple devices. One or more memory units may include a database. A single copy of historical position data can be stored, or multiple copies can be stored. Multiple copies may be stored in different memory units. For example, multiple copies may be stored on different devices (e.g., a first copy on a card reader or board of a user device, a second copy on a board of an external device).

  The historical position data may include position data collected using one or more position sensors of the card reader or user device. The historical position data may include position data that belongs to the same user and / or is related to the same card. For example, if a current set of position data is collected for a first user, the historical position data may include position data collected for the same user. Historical position data may include all position data for the same user (and / or the same card) collected using the same card reader. Historical position data may or may not include "registration" position data. In some embodiments, a user can register a payment card by performing an initial authentication read of the card. The set of position information generated by the initial authentication reading may be stored as registered position data. Alternatively, registration position data is not specifically created. Various location information from all card swipes for the user (and / or the same payment card) may be stored. Alternatively, only registered position data may be stored. Alternatively, only the closest set of location data for a particular user (and / or the user's card) may be stored. In some instances, only the most recent X sets of location data for a particular user (and / or card) may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 or more.

  In some embodiments, the historical location data may be location data collected by a card reader (or user device) belonging to any user (and / or any payment card) that has interacted with the card reader (or user device) May be included. For example, multiple users may be swiping the payment card through the card reader. The historical location data may include location data belonging to different users (and / or payment cards of the same user or different users) that may include persons identified as the same user. For example, if a current set of position data is collected for a first card, historical position data may include multiple sets of position data collected for the same user as well as other users. Historical position data may include all position data for one or more users collected using the same card reader. Historical position data may or may not include "registration" position data. In some embodiments, a user can register a payment card by performing an initial authentication read of the card. A set of position data generated by the initial authentication reading may be stored as registered position data for the user or for the user's card. Such registration may be performed for multiple cards and / or multiple users. In some instances, each card may need to be registered with the card reader the first time a card is swiped. Alternatively, registration position data is not specifically created. Various sets of positional data from all card swipes for any or all of the payment cards swiped through the card reader may be stored. Alternatively, only registered position data may be stored for each payment card or for each user. Alternatively, only the latest set of location data for each payment card or for each user may be stored. In some instances, only the most recent X sets of location data per payment card or per user may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6. 7, 8, 9, 10 or more.

  As discussed above, historical data may relate to data collected using a particular card reader (or user device). Alternatively, data from multiple card readers (or user devices) may be shared and / or aggregated. Historical data may include data from multiple card readers or user devices. The historical data may include payment card location data collected by multiple card readers or user devices. The historical data may include the same card swiped on multiple card readers. Historical data may include the same user swiping cards on multiple card readers. Historical data may include various cards swiped through multiple card readers. Historical data may include various users swiping cards through multiple card readers. Historical data may include data regarding payment cards read by a user or multiple card readers. The historical data may include data regarding a plurality of payment cards read by a plurality of users or a plurality of card readers. The historical data may include data regarding payment cards being swiped through all users or multiple card readers that may be providing information to the historical location data database. An external device, such as, for example, a server or any other device described elsewhere herein, may receive location data from one or more card readers and / or user devices and store historical location data.

  Once a set of position data has been collected, the position data may be transferred to position analyzer 1110 for comparison 1106 with one or more sets of position data collected in the past. Such comparison may include comparing a set of position data to historical position data. One set of location data may be compared to multiple sets of location data coming from the same user (or for the same card user). For example, if a set of position data is collected, additional information may be collected during an authentication read, which may include data to be encoded in the magnetic stripe and / or swipe characteristics. This additional information may include the payment card number and / or identification information regarding the payment card, such as the carrier. This additional information may include identification information such as the user's name or other identifier, or may be used to access an account where the user's name or other identifier may be accessed. The additional information may be used to identify who is believed to be the same user. For example, if the additional information indicates that the user is John Doe, one set of positional data of the card can be compared to other sets of positional data belonging to John Doe. This location data may be compared to the location data for all John Doe cards, or to only the same John Doe cards that are being swiped. If the location data collected matches the location data stored in the past exactly as well, there is some suspicion that the user may be the same user as previously identified as John Doe It can occur. It is extremely unlikely that a perfect match will occur naturally, and may indicate a replay attack.

  One set of position data may be compared to any or all of the previously collected sets of position data estimated to belong to the same user. This comparison can be narrowed more clearly to the user's same card, or can be applied to any card or all cards of the same user. For example, if a set of registered position data is provided, the collected set of position data can be compared to the set of registered position data. The collected position data may be compared with the registered position data without being compared with any other position data, may be compared with the registered position data and the other position data, or with the registered position data. It can be compared with other position data without being compared. In some instances, position data may be compared to the most recently collected position data. The position data may be a predetermined number of position data collected most recently, eg, two sets of position data collected most recently, three sets of position data collected most recently, four sets of position data collected most recently, It may be compared to the five sets of position data collected, and similarly may be compared for any number of position data collected most recently.

  The position data may be compared to position data that may have come from any user whose information is stored in historical position data. If a set of position data is collected, additional information may be collected during the authentication read, which may include data encoded in the magnetic stripe and / or swipe characteristics. As discussed above, the additional information may include identification information that may be used to identify the user. The additional information may be used to identify who is believed to be the same user. For example, if additional information indicates that the user is John Doe or additional information is used to find that the user is John Doe, the card's location data may have stored John Doe as well as historical data. May be compared to other location data belonging to any other user. If the collected location data matches the location data stored in the past in exactly the same way, such a match can be suspected of replay attacks.

  One set of location data is compared to any or all of the multiple sets of location data collected in the past that are presumed to belong to any of the users who swipe the card in the past and stored the data in historical data. It can be done. For example, if location data is provided for different users, the location data may be compared to registered location data of different users. Position data may be compared to registered position data without being compared to any other position data, may be compared to registered position data and other position data, or may be compared to registered position data It can be compared with other position data without any problem. In some instances, location data may be compared to the most recently collected location data for the user or for each of the user's payment cards. The position data may be a predetermined number of position data collected most recently, eg, two sets of position data collected most recently, three sets of position data collected most recently, four sets of position data collected most recently, The five sets of position data collected may be compared, and the same may be made for any number of sets of position data collected most recently.

  The identity of the user based on the comparison may be evaluated (1108). The identification may include authenticating the user based on the card information as being an actual user. For example, a card may belong to John Doe. If, for the same additional information, a warning is issued when a set of collected position data is compared with multiple sets of position data stored in the past (e.g. when the match is too much the same), the card currently being swiped There may be an indication that they may not belong to the same user. For example, if the location data matches exactly the same, and there is a set of past location data for John Doe, then the current user attempting the swipe may not be John Doe.

  Optionally, an indication of the likelihood of fraud can be provided. For example, the data on the card is encoded such that the card identifies as a particular user of the card (eg John Doe), and the position data is from position data derived from the same user (John Doe) or a swipe of the self-identifying card If they match exactly the same, the possibility of fraud may be provided. The probability of fraud may be a binary indicator (eg fraud alert, no fraud) or may be provided as a risk value (eg numerical value such as percentage or grade value such as a grade by letters). For example, a fraud grade of 9 may give a higher probability of fraud than a fraud grade of 2.

  To be considered the exact same match (e.g. 100% match), the collected location data may be completely identical to one or more sets of location data stored in the past. A perfect 100% match may be suspicious. For example, it is likely that there will be some slight variation each time the user swipes the card. The probability that an individual swipes the card at exactly the same position (e.g. orientation and / or spatial position) is physically very low. Having exactly the same characteristics may be an indicator of a kind of replay attack.

  In some embodiments, one or more individuals may be alerted when the risk of fraud is detected. For example, a user swiping a card may or may not be notified that his swipe has been flagged with some risk of fraud. The entity the user is trying to trade may or may not be notified of the risk of fraud. For example, if the user is trying to purchase an item from an e-commerce site, the e-commerce site may be informed that the transaction is flagged with some risk of fraud. The transaction itself may or may not be allowed to proceed. In some cases, the transaction can be suspended if there is any risk of fraud. Alternatively, if there is some risk of fraud, but it is determined that it is low, one or more parties may be informed about the risk of some fraud while the transaction may continue and / or further examinations Can be done. If the risk of fraud is above a threshold level (e.g. reaching a moderate or high risk of fraud), the transaction may be suspended.

  In some instances, the threshold for stopping the transaction may depend on the value of the transaction or other characteristics of the transaction. For example, for high value transactions, the threshold for stopping the transaction may be lower than for low value transactions. For example, if the transaction is for a large amount of money, even a low risk of fraud may cause the transaction to stop, while a smaller amount may require a higher risk of fraud to stop the transaction. Alternatively, the threshold for stopping the transaction may be the same for all transactions.

  As mentioned earlier, in some situations, users may conduct secure transactions or access confidential information from unauthenticated devices (eg, conduct online transactions from publicly shared PC desktops or access bank account information) ) May be necessary. Because certified devices may have unknown security levels, visual graphical barcodes such as QR codes may be used to establish secure communication between the user and the service provider. As described with respect to FIGS. 13-23, the QR code can also provide an additional level of security.

  FIG. 13 shows an example of a user device 204 according to an embodiment of the present invention. User device 204 may be used to scan a visual graphical barcode, such as a QR code, displayed on another device 1301. User device 204 and device 1301 may be separate devices.

  A user device may be, for example, one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. In some embodiments, an imaging device configured to capture visual graphical elements, such as barcodes (eg, one dimensional or two dimensional), text, pictures, sequences thereof, etc., displayed on the device 1301 in some embodiments An apparatus 1303 may be included. The imaging device may include hardware and / or software elements. In some embodiments, the imaging device may be a camera operatively coupled to the user device. In some alternative embodiments, the imaging device may be located external to the user device, such as on the card reader 200, and the image data of the graphical element may be user device by means of communication as described elsewhere herein. Can be transmitted to The imaging device may be controlled by an application / software configured to scan visual graphical code. In some embodiments, a camera may be configured to scan a QR code. In some embodiments, software and / or applications may be configured to activate a camera on a user device to scan code. In other embodiments, the camera may be controlled by a processor originally embedded in the user device.

  User device 204 may be a computing device capable of executing software or applications provided by one or more authentication systems. In some embodiments, software is used for the user to scan graphical authentication indicia, such as QR codes, displayed on another device, and transmit the authentication data between the user device and the authentication system during an authentication session And / or the application may allow. The software and / or application may have been registered with the authentication system by the user. Optionally, no software and / or applications need to be registered with the authentication system, only user devices may be registered with the authentication system. In some embodiments, such as a card reader to collect authentication data (eg, swipe characteristic data, magnetic fingerprint data, location data, etc.) during an authentication session and encrypt the data prior to transmission to the authentication server, etc. Software and / or applications may be configured to control external devices. In some instances, the application may allow the user to set up security levels for some or all transactions that require authentication. For example, the user may be permitted to set a high security level for financial transactions above a predetermined threshold amount and a low security level for financial transactions below the predetermined threshold amount.

  The user device may include, among others, a desktop computer, laptop or notebook computer, mobile device (eg, smart phone, cell phone, personal digital assistant (PDA), tablet), or wearable device (eg, smart watch). The user device may also include any other media content player, such as a set top box, a television set, a video game system, or any electronic device capable of providing or rendering data. A user device may include known computing components, such as one or more processors and one or more memory devices that store software instructions and data executed by the processors. The user device may optionally be portable. The user device may be handheld. The user device may be a cash register in a store or other store. The cash register may be used during a transaction (such as a financial transaction) at a store or other store. The user device may be a network device capable of connecting to a network such as a local area network (LAN), a wide area network (WAN) such as the Internet, a telecommunication network, a data network, or any other type of network.

  Device 1301 may be a non-authenticated device whose security level may be unknown. In some embodiments, a user may use the device 1301 to access sensitive information or conduct transactions that require an authentication session provided by a service provider. Types of transactions that may be certified include web-based financial transactions, counter-sale financial transactions, security transactions, or identification transactions. The transaction may include a login process to access the information. The authentication session may be hosted by a server (eg, server 1401 of FIG. 14) on one or more interactive web pages and may be accessed by one or more users. Device 1301 may be a publicly shared device whose identity and security are not known to the authentication system. Device 1301 may include a display device configured to display visual graphical code (eg, QR code) to a user. In some embodiments, the QR code may be displayed by an interface such as a web page or any suitable software. The device 1301 may need to authenticate or verify a user to perform a session or transaction that utilizes a display device to complete a transaction performed on a server (ie, a service provider), such as a computer (eg, a laptop It can be a top computer or desktop computer), a mobile device (e.g. a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a vending machine etc. The display device may optionally be portable. The display device may be handheld.

  In some embodiments, the visual graphical code displayed on the device 1301 and scanned by the imaging device 1303 may be a QR code. A QR code is a two-dimensional bar code that uses dark and bright modules arranged in a square to encode data for being optically captured and read by a machine. The elements of the barcode may define the version, format, position, alignment, timing, etc. to enable reading and decoding of the barcode. The remainder of the barcode can encode various types of information in any type of appropriate format, such as binary or alphanumeric, and the QR code can be based on any of several standards . The QR code may have various symbol sizes as long as it can be scanned from an appropriate distance by the imaging device. The QR code may be of any image format (eg, EPS or SVG vector graph, PNG, GIF, or JPEG raster graphics format). In some embodiments, the QR code conforms to a known standard that can be read by a standard QR reader. The information encoded by the QR code may consist of four standardized types ("modes") of data (numeric, alphanumeric, byte / binary, kanji) or by a supported extension It may consist of virtually any kind of data. In other embodiments, the QR code may be proprietary and such QR code may only be read by an authenticated application provided by an authentication system implemented on the user device. In some cases, only an authentication system or an authenticated application can encrypt / decrypt the QR code.

  FIG. 14 illustrates an example of using a QR code to identify a user or verify a service provider, according to one embodiment of the present invention. The server 1401 can submit the QR code request to the authentication system 1403. The term server as used herein may generally refer to a multi-user computer that provides services (eg, online transactions, database access, file transfers, remote access) or resources (eg, file space) over a network connection. The server 1401 may be provided or managed by a service provider. In some cases, the server may be provided or managed by a third party entity associated with the provider of the device. One or more servers 1401 may or may not be registered with the authentication system. In some embodiments, the server may include a web server, an enterprise server, or any other type of computer server, and the request (eg, data) from a computing device (eg, a user device or a publicly shared device) It can be computer programmed to accept HTTP (or other protocols that may initiate transmission) and to provide the requested data to the computing device. In addition, the server may be a free-to-air (FTA), cable, satellite or other broadcast facility, and other broadcast facilities for delivering data. The server can also be a server in a data network (eg, a cloud computing network).

  A QR code request may be initiated when a new transaction or authentication session is required or initiated. For example, if the user 1417 accesses a web page portal provided by the service provider 1415 to conduct a transaction (eg, a financial transaction), the service provider can request the authentication system 1403 for a QR code. The authentication may generate a QR code associated with the request after verifying the identity of the service provider. The service provider can give the user a QR code. Thereafter, the QR code may be scanned by the user and transmitted to the authentication system. The authentication system may analyze the QR code to identify the user and / or to verify the service provider. Additional authentication information may be requested from the user as described later herein, and the user and service provider may complete the transaction by direct communication once the authentication session is complete.

  In some embodiments, service provider 1415 may manage one or more servers 1401 to provide various services, such as financial transactions, to users. When a user accesses a web page portal (provided by a service provider) to conduct a transaction, the server 1401 can send a request to obtain a QR code to the authentication system 1403. This request may include the service provider's identification and the session ID. In some embodiments, the request may further include a desired security level for a particular transaction. For example, different transactions may have different security requirements. As described later in this specification, high security level requirements may activate more factors to be verified to verify the user identity. In some embodiments, the service provider may have been previously registered with the authentication system 1403, and the identity of the service provider may be stored in a database accessible to the authentication system. The user can access the web page portal using, for example, the device 1301 of FIG. In some cases, the authentication system 1403 may determine if the QR code request came from a trusted source / entity. Having determined that the request came from a trusted source / entity, the authentication system 1403 may respond to the request by sending a unique QR code back to the server 1401. The server 1401 can include the QR code on the web page portal so that the QR code can be displayed to the user.

  Next, specific details of the generation of the QR code will be described. Referring to FIG. 14, when the authentication system 1403 receives a QR code request from the server 1401, the code generator 1405 in the authentication system 1403 may generate a unique code with a verification ID and a locator. In some embodiments, the code may be a QR code in which the verification ID is encrypted. Generating a QR code is at least three steps: (1) generating a unique verification ID, (2) encrypting the verification ID into an encrypted message, and (3) encoding the message. It may include generating a one-time QR code. The verification ID may be transaction specific. In some embodiments, the verification ID may be associated with the server identification, session ID, and timestamp by any suitable cryptographic technique, such that the verification ID is a key to retrieve the code, server identification, session ID, etc. It can be used as In some instances, the timestamp may be in the yyyyMMddHHmmss format or an appropriate format if specified in the request. The server identification may be known only to the authentication system. The verification ID may be used to identify the authentication (QR code) request in a unique manner. The verification ID or the associated QR code may expire or time out after a certain period of time or if they are verified. Once the code is generated, a locator may be returned to server 1401. The verification ID may be of any type and data type. Various methods may be used to encrypt the verification ID. For example, symmetric keys may be used for encryption and decryption. These keys can consist of sentences or sequences of meaningless characters, and encryption is bitwise exclusive to the data chunks that make up the QR code (eg, original data, structural data, and Reed Solomon data) It is done by performing a sum operation.

  The QR code can be generated by selecting several random locations in the data and randomly changing the bytes at those locations. The Reed Solomon algorithm corrects the incorrectly decoded code word to form a correct message. The QR code may have any suitable storage capacity as long as it is sufficient to be uniquely tied to a transaction. Any suitable visual graphical code may be used to represent a unique verification ID, such as one-dimensional or two-dimensional code or images.

  The QR code may be stored in a database accessible to the authentication system 1403 and may be retrieved by a unique verification ID. In some embodiments, the locator allows a user using the browser to access visual graphical code provided by the web server from the authentication system, a URL (Unified Resource Locator) to an IP (Internet Protocol) address May be a link associated with a code such as a) or any other form of link. In another embodiment, the QR code may be sent directly to the server 1401. The session ID may be returned to the service provider along with the QR code or locator so that the service provider can link the code to a specific request.

  The server 1401 may or may not store a copy of the code. In some embodiments, the graphical image code is stored in the database of the authentication system whereas the server may store only the locator, so the invention described herein reduces the load on the server with respect to memory. . Once the QR code or locator is received, the server 1401 can send the QR code or locator to a display device 1409 configured to display a web page portal.

  As mentioned earlier, in some embodiments the display device may not be registered with the authentication system. In some instances, display device 1409 of FIG. 14 may correspond to device 1301 of FIG. For example, the display device may be a publicly shared device with an unknown security level. The code display device may be configured to be able to display an image such as a QR code. In some embodiments, the display device may prompt the user to scan the QR code with a message on the screen.

  The user may be prompted to use the imaging device 1411 to scan the QR code displayed on the display device 1409. In some examples, the imaging device 1411 of FIG. 14 may correspond to the imaging device 1303 of FIG. In some embodiments, an imaging device may be located on the user device and configured to capture an image of the QR code. In some alternative embodiments, the imaging device may be located on an external device such as a card reader coupled to the user device. In those alternative embodiments, the captured visual graphical code may be transmitted to the user device by the communication means described hereinbefore. The imaging device may be controlled by an application / software to scan visual graphical code.

  The captured visual graphical code may be transmitted from a user device (e.g., user device 204) to a QR code analyzer 1407 in an authentication system for analysis. In some embodiments, the QR code may be transmitted to the code analyzer by an application or software. The application or software may be provided by the authentication system 1403 and executed on the user device. In some instances, QR code image data may be sent directly to the QR code analyzer. In another example, an application or software may process the captured code (eg, decrypt the code or decode the decrypted data) and send it to the QR Code Analyzer to analyze the processed information. In some embodiments, the identification of the user device or the identifier of the user device may be transmitted along with the code or processed information as a data packet to the authentication system 1403. The user device may be an authenticated device. The identification of the user device may be a unique user device ID (eg, IMEI code, serial number, etc.) that may co-exist with the user device or may be generated by the authentication system and may be associated with the user device upon registration of the user device with the authentication system. It may include the user device ID. The identification data of the user device may be stored in a database accessible by the authentication system.

  The QR code analyzer 1407 can receive the code from the user device, decrypt the QR code and / or decode the decrypted data. In some embodiments, the QR Code Analyzer verifies the captured QR Code, based on the verification ID encrypted in the code that the captured QR Code relates to the request from the authorized service provider Can be verified. Optionally, the QR code analyzer may provide the user with an identification of a verified service provider to prevent phishing attacks. For example, if the verification ID collected does not match any record of the verification ID generated by the authentication system, there may be a potential phishing attack. Another example is the possibility of a replay attack if the verification ID has expired (e.g. has been shown to have been verified multiple times) or it contains a timestamp earlier than the timestamp in the stored copy. There is a possibility. In this case, fraud alerts can be sent to the user device, and further transactions may or may not be stopped by the authentication system. In other embodiments, the QR Code Analyzer may analyze the collected data packets to identify the user device or user. The user device may be registered as an authenticated device in the authentication system by an application or software provided by the authentication system. The identity of the authenticated user device may be received by the QR code analyzer along with the QR code. Thereafter, the QR Code Analyzer may store the identity of the user device associated with the verification ID for further user authentication to complete the transaction or comparison with the stored user identity.

  Position data, magnetic fingerprints, and / or swipe characteristics may be collected from authentication reading of the card using a card reader. Position data, magnetic fingerprints, and / or swipe characteristics may be used individually or in combination for identification. Position data, magnetic fingerprints, and / or swipe characteristics may be used individually or in combination in authenticating the card and / or the user. Position data, magnetic fingerprints, and / or swipe characteristics may be used individually or in combination in approving a transaction. Position data, magnetic fingerprints, and / or swipe characteristics may be used alone or in combination to detect fraud.

  In some embodiments, where position data, magnetic fingerprints, and swipe characteristics are analyzed, data for all may be collected from a single authentication read of the card (eg, a single swipe of the card). Position data, magnetic fingerprints, and swipe characteristics can all be evaluated simultaneously. In some other embodiments, position data, magnetic fingerprints, and / or swipe characteristics may be evaluated sequentially or in various orders.

  FIG. 9 illustrates an example of data 900 that may be stored for various transactions and used to identify a user and / or fraudulent transaction, according to one embodiment of the present invention. A transaction may or may not include the exchange of money and / or goods or services. Transactions may include donations. The transaction may include any situation where the user may swipe the payment card. Payment card swipes can occur regardless of whether money is transferred. For example, a user can swipe cards in his library to borrow a book. The transaction may include verifying the user's card and / or the user's identity. Transactions can be relevant whenever payment card authorization reading can be performed.

  The data may be historical data collected from one or more transactions. Historical data may be stored all together in a single memory unit or may be distributed across multiple memory units. Data distributed across multiple memory units may or may not be simultaneously accessible or linked. Historical data may include data collected for a single payment card or for multiple payment cards. Data from multiple cards may all be stored together or may be stored separately from one another. Historical data may include data pertaining to a single user or from multiple users. All data from multiple users may be stored together or may be stored separately from one another. Historical data may include data collected from a single card reader or from multiple card readers. The data from multiple card readers may all be stored together or may be stored separately from one another. In some cases, a single card reader may be provided to a single user. Alternatively, when swiping cards, multiple users may use a single card reader, or one user may use multiple card readers.

  The data stored may include information such as transaction ID, data from an authentication read, and / or any additional information from the card. For example, TID1, TID2, TID3, TID4, etc., the transaction ID may be a unique identifier that identifies a particular transaction. As discussed above, the transaction may be any time that the user causes the user to perform an authentication read on his card. The transactions offered in the historical data may or may not be flagged as problematic and / or whether any transfer of money, goods or services is permitted to proceed towards completion. It can be stored independently. In some embodiments, the transaction ID may be equivalent to the verification ID if the QR code is used for authentication as described above.

  The data stored may include authentication data. An authentication read may be performed when the card is sensed by the sensing unit of the card reader. For example, a magnetic head can read the magnetic stripe of the payment card. A payment card can be swiped through the card reader to perform an authentication reading. The authentication reading may include the magnetic fingerprint of the card and / or one or more swipe characteristics when the card is swiped. In some instances, both the magnetic fingerprint and the set of one or more swipe characteristics may be collected. Magnetic fingerprints and / or swipe characteristics can be used individually or in combination to identify and / or authenticate payment cards or users. Magnetic fingerprints and / or swipe characteristics can be used individually or in combination to detect when the risk of fraudulent transactions increases.

  Magnetic fingerprints may be unique to payment cards. Card data can be copied and / or cloned onto another card, but due to the inherent variation of the magnetic particles, an exact copy of the magnetic fingerprint can not be formed. The magnetic fingerprint may be raw data collected from the magnetic head of the card reader. Magnetic fingerprints may be generated based on the raw data collected from the card reader's magnetic head. For example, a magnetic fingerprint may be an alphanumeric string generated based on collected magnetic data. The magnetic fingerprint may be a hash of the data collected. For example, MFP1, MFP2, MFP3, etc., magnetic fingerprint data may be stored to identify a particular magnetic fingerprint of the card.

  The swipe feature may include information on how the payment card was read by the card reader. The swipe feature may include information regarding the physical placement or movement of the payment card relative to the card reader. The swipe characteristics may include information such as the position, angular orientation, linear velocity, angular velocity, linear acceleration, and / or angular velocity of the translational motion of the payment card relative to the card reader. Any of these pieces of information may be collected over a period of time and / or at multiple points in time. For example, payment cards can be swipe through the card reader or next to the card reader. The set of swipe characteristics may include a single swipe characteristic of the plurality of swipe characteristics.

  Data representing a set of swipe characteristics can be denoted as SC1, SC2, SC3, and so on. However, swipe properties may be stored in any manner. For example, each swipe characteristic in the set may be stored separately. The swipe characteristics may be stored as raw data collected from the card reader's magnetic head. The swipe characteristics may be generated based on raw data collected from the card reader's magnetic head. For example, the swipe characteristic may be an alphanumeric string generated based on the collected magnetic data. The swipe property may be a hash of the data collected. In some instances, multiple swipe characteristics in the same set may be stored together. The swipe characteristics may be stored as aggregated raw data collected from the card reader's magnetic head. Based on the raw data collected from the card reader's magnetic head, swipe characteristics from a single set can be generated as a single stored data. For example, the set of swipe characteristics may be an alphanumeric string generated based on the collected magnetic data. The set of multiple swipe characteristics may be a single hash of the data collected.

  In some embodiments, other information about the card may be collected when an authentication read is performed. For example, data to be encoded on a payment card can be read. Such data may include information that may be useful in identifying a card, an account associated with the card, and / or a user associated with the card. The user associated with the card may be the owner of the card and / or an authorized user of an account tied to the card. Such data may include, but is not limited to, card carrier, card number, expiration date, security code, card age, related account age, user name, user contact information (eg, address, phone number, electronic) Email address), the user's birthday or age, the user's gender, the user's social security number, the user's account number, the balance in the account, or anything else described herein including information about past transactions May contain card related information. The additional information, shown as CD1, CD2, CD3, etc., may represent a single type of information or multiple types of information. For example, multiple sets of data may be associated with a transaction.

  Historical data may be analyzed to identify the card and / or the user or to authenticate the card and / or the user. As shown, the first few trades may not issue a warning at all. For example, since all three sets of data are changing, the magnetic fingerprint, swipe characteristics, and card information may all indicate that different cards are being swipe for TID1, TID2, and TID3.

  The fourth transaction TID4 may also not issue a warning at all. For example, both TID1 and TID4 may have matching magnetic fingerprints, swipe characteristics, and card data (MFP1, SC1, and CD1). Therefore, the same user may be swiping the same card for both TID1 and TID4. As discussed above, any match of the magnetic fingerprint and / or swipe characteristics indicated by the same representation (eg, the same MFP 1 for TID1 and TID4) may include some built-in tolerance. Thus, although the same swipe profile representation SC1 may be used for both TID1 and TID4, there may be some variation of the swipe profile within the acceptable range as described above.

  The fifth transaction TID5 may issue a warning. For example, the card data of TID5 may be CD2, which indicates that the card would be the same card used in TID2. Card data may be data encoded on the card. However, there is a possibility that the magnetic fingerprints do not match (it is MFP 5 in TID 5 and MFP 2 in TID 2). A magnetic fingerprint mismatch may indicate that the magnetic stripes for both transactions are not the same physical magnetic stripe, even though the encoded data is the same. This may be an indicator of a cloned card. Furthermore, the swipe characteristics may not match (SC5 for TID5 and SC2 for TID2). This can indicate that TID5 and TID2 have different users swiping cards. Thus, a possible scenario is that the second user copied data from the card of the first user to create a second card, and the second user attempted to pass as the card of the first user. It is.

  The same problem may occur in the seventh transaction TID7. The card data of TID7 may be CD3, which indicates that the card would be the same card used in TID3. Here too, there is a possibility that the magnetic fingerprints will not match (it is MFP 7 in TID 7 and MFP 3 in TID 3). Furthermore, there is a possibility that the swipe characteristics do not match (it is SC7 for TID7 and SC3 for TID3). This may indicate that for TID7 and TID3, different users are swiping different cards.

  The sixth transaction TID6 may also issue a warning. For example, the card data of TID6 may be CD1, which indicates that the card would be the same card used in TID1 and / or TID4. Card data may be data encoded on the card. The magnetic fingerprints can match (TID1, TID4, and TID6 are MFP1). A magnetic fingerprint match may indicate that the magnetic stripes for both transactions are the same physical magnetic stripe. Therefore, the same physical card may be used in both transactions. This may be an indicator that the card is not a cloned card. However, there is a possibility that the swipe characteristics do not match (SC6 for TID6, SC1 for TID1 and TID4). This may indicate that different users are swiping cards with TID6 and earlier transactions TID1 and TID4. Thus, a possible scenario is that the second user is using the first user's card. It is possible that the second user is using the card of the first user without the permission of the first user (ie the second user has stolen the card of the first user). In another possible scenario, the swipe characteristics may be considered discordant if the swipe characteristics are too the same (e.g. some variation is expected between swipes). Thus, if the magnetic fingerprints match and the swipe characteristics are too similar (or exactly the same), it may be the possibility that some sort of replay attack may be taking place. For example, past swipes may have been recorded, including magnetic fingerprints and swipe characteristics, and past recorded swipes may be re-executed as if they were being performed in real time. Taking into account the swipe characteristics can advantageously detect this situation.

  Other scenarios are also possible. For example, the same card data may be provided across multiple transactions. While swipe characteristics across transactions may match, the magnetic fingerprint may change. This may indicate that the same user is swiping past card clones or copies. Such swipes can issue a warning if the user is making a copy of his card.

  FIG. 12 shows an example of data 1200 stored for various transactions and that may be used to identify users and / or fraudulent transactions, according to one embodiment of the present invention. The transaction may be conducted as described earlier elsewhere herein.

  The data may be historical data collected from one or more transactions. Historical data may be stored all together in a single memory unit or may be distributed across multiple memory units. Data distributed across multiple memory units may or may not be simultaneously accessible or linked. Historical data may include data collected for a single payment card or for multiple payment cards. Data from multiple cards may all be stored together or may be stored separately from one another. Historical data may include data pertaining to a single user or from multiple users. All data from multiple users may be stored together or may be stored separately from one another. Historical data may include data collected from a single card reader or from multiple card readers. Historical data may include data collected from a single user device or from multiple user devices. The data from multiple card readers and / or user devices may all be stored together or may be stored separately from one another. In some instances, a single card reader and / or user device may be provided to a single user. Alternatively, when swiping cards, multiple users may use a single card reader and / or user device, or one user may use multiple card readers and / or user devices.

  The data stored may include information such as transaction ID, data from an authentication read, and / or any additional information from the card. The transaction ID may be a unique identifier that identifies a particular transaction, such as, for example, TID1, TID2, TID3. As discussed above, the transaction may be any time that the user causes the user to perform an authentication read on his card. The transactions offered in the historical data may or may not be flagged as problematic and / or whether any transfer of money, goods or services is permitted to proceed towards completion. It can be stored independently.

  The data stored may include authentication data. An authentication read may be performed when the card is sensed by the sensing unit of the card reader. For example, a magnetic head can read the magnetic stripe of the payment card. A payment card can be swiped through the card reader to perform an authentication reading. The authentication reading may include the magnetic fingerprint of the card and / or one or more swipe characteristics when the card is swiped. In some instances, both the magnetic fingerprint and the set of one or more swipe characteristics may be collected. Magnetic fingerprints and / or swipe characteristics can be used individually or in combination to identify and / or authenticate payment cards or users. Magnetic fingerprints and / or swipe characteristics can be used individually or in combination to detect when the risk of fraudulent transactions increases. Optionally, the authentication reading may comprise position data of the user device and / or the card reader, or the position data may be separate from the authentication reading.

  As discussed above, magnetic fingerprints may be unique to payment cards. For example, MFP1, MFP2, MFP3, etc., magnetic fingerprint data may be stored to identify a particular magnetic fingerprint of the card.

  The swipe feature may include information on how the payment card was read by the card reader. Data representing a set of swipe characteristics can be denoted as SC1, SC2, SC3, and so on.

  In some embodiments, other information about the card may be collected when an authentication read is performed. Any type of card data described elsewhere herein may be collected. The additional information, shown as CD1, CD2, CD3, etc., may represent a single type of information or multiple types of information. For example, multiple sets of data may be associated with a transaction.

  Where authentication readings are performed, location data may be collected. The position data may include information regarding the orientation of the card reader and / or the user device, and / or spatial location information regarding the orientation of the card reader and / or the user device. The location information may include data collected at a single point in time or from multiple points in time (eg, at different time intervals or continuously within a time range). Location data information may be stored, one or more sets of data. The position data may be indicated as PD1 or PD2 or the like.

  Historical data may be analyzed to identify the card and / or the user or to authenticate the card and / or the user. As shown, the first two trades may not issue any warning at all. For example, because both sets of data are changing, the magnetic fingerprint, swipe characteristics, card information, and location information may all indicate that different cards are being swiped for TID1, TID2.

  In the third scenario TID3, a warning may be issued. Although a separate swipe has been performed, location data PD2 may indicate that the user device and / or card reader were at the exact same location as the swipe done for the previous transaction TID2. The device may be in the same vicinity as the previous swipe, but as explained above, the orientation and / or spatial position is perfectly matched, especially if the measurement is required to a high degree of accuracy and / or precision The possibility of doing so is extremely low. Thus, in the third scenario, there is some potential for replay attacks.

  In some scenarios, location data may include location information collected at multiple points during the swipe duration. For example, position information may be collected at the beginning of the swipe, at the end of the swipe, and at one or more points in between. A warning may or may not be issued if the location information does not change at all during the swipe duration. In some cases, it is unlikely that the position data will not change at all, especially if the sensor's sensitivity is very high. During the swipe, the user is likely to shake the user device and / or card reader lightly, or the vibration of the card swipe itself may be picked up. Or, if the sensor's sensitivity is low, such swipe may not issue a warning.

  These scenarios are given as examples only. Authentication reading may be used to identify the card and / or the user. For example, magnetic fingerprints may be used to identify the card. The magnetic fingerprint can be compared to one or more magnetic fingerprints stored in the past. In some embodiments, if the magnetic fingerprint matches a previously stored fingerprint, it may be determined that the magnetic fingerprint belongs to the same card. If the card data conflicts with it, it may be an indication that the past card has erased its data and has encoded new data. However, magnetic properties may be used to identify that the card data belongs to the same card erased in the past.

  In another example, swipe characteristics may be used to identify a user and / or a card. The swipe characteristics can be compared to one or more swipe characteristics stored in the past. In some embodiments, if the swipe properties match a set of swipe properties stored in the past, the swipe properties may be determined to belong to the same user. If the card data contradicts it (e.g. indicates that a different user is associated with the card used in different transactions), it is using a card that the user is not authorized to use, or impersonating another It can be an indication of things. However, swipe characteristics may be used to identify when the same user is swiping.

  Optionally, location data can be taken into account when identifying the user and / or the card. The position data may be analyzed on its own and / or compared to one or more sets of position data stored in the past. If the location data matches exactly with a set of location data stored in the past, it may be determined that there is a potential replay attack. This may indicate that the user is not the person he / she claims or that the user is providing counterfeit card information.

  Magnetic fingerprint and swipe characteristics can be combined and analyzed. Analyzing in combination may provide more clarity regarding the possible problems or scenarios that are occurring. For example (1) if both the magnetic fingerprint and swipe characteristics do not match, (2) if the magnetic fingerprint matches but the swipe characteristics do not match, (3) the magnetic fingerprints do not match but the swipe characteristics match Or (4) different scenarios can be presented if both the magnetic fingerprint and swipe characteristics match. The degree of coincidence or coincidence of the magnetic fingerprint and / or swipe characteristics may or may not be considered in the analysis. This can also be considered in combination with the card data. Card data may be used as an indicator or basis for comparison. Alternatively, comparisons can be made across historical data without narrowing down the survey by card data, and card data can be compared to identify possible additional scenarios. In some cases, position data can be analyzed along with magnetic fingerprint and / or swipe property data. Within the analysis, detection of a match or mismatch between sets of position data may or may not be considered. Within the analysis the position profile over time during the swipe may or may not be taken into account.

  These scenarios may be used to identify cards and / or individuals. The card and / or user identity may be authenticated (eg, the card and / or user identity may be verified). Possible fraudulent scenarios can be detected. Some examples of results are not limited to this, but unauthorized users (eg magnetic fingerprints and the like) copying / skimming another user's card and swiping the card skimmed to pass as the original user's card. An unauthorized user replaying pre-recorded data (for example, if the magnetic fingerprints match, too identical (for example, 100% match for all properties)) if both swipe properties do not match Is not considered to be a match, an unauthorized user stealing another user's physical card and trying to pass as the victim user (eg because the magnetic fingerprint matches and the swipe characteristics are too different) I copied or skimmed my card, and I copied it. If the user swiping the card (e.g. if the magnetic fingerprints do not match and the swipe characteristics match), or if both the card and the user are identified / authenticated as they claim (e.g. magnetic) Can include both fingerprint and swipe characteristics).

  FIG. 15 illustrates an exemplary network layout that includes one or more authentication systems, in accordance with some embodiments. In one aspect, the network layout comprises a plurality of user devices 1502, one or more servers 1504, a network 1506, one or more databases 1512, a plurality of non-authentication devices 1514, a plurality of authentication servers 1508, and one or more authentications. System 1510 may be included. Each of the components 1502, 1504, 1508, 1510, and 1514 may be operatively connected to one another via a network 1506 or any type of communication link that allows data transmission from one component to another.

  As discussed earlier herein, user device 1502 may be one or more computing devices configured to perform one or more operations, eg, consistent with the disclosed embodiments. For example, a user device may be a computing device capable of executing software or applications provided by one or more authentication systems 1510. In some embodiments, software for the user to scan the QR code or visual graphical bar code displayed on another device and transmit the authentication data between the user device and the authentication system during the authentication session And / or the application may allow. The software and / or application may have been registered with the authentication system by the user. Optionally, software and / or applications may not need to be registered with the authentication system, rather the user device is registered with the authentication system. As such, the user may or may not be required to log in a user account to the authentication system. In some embodiments, such as a card reader to collect authentication data (eg, swipe characteristic data, magnetic fingerprint data, location data, etc.) during an authentication session and encrypt the data prior to transmission to the authentication server, etc. An application may be configured to control an external device. An authentication session is hosted by the server on one or more interactive web pages and can be accessed by one or more users. In some instances, the application may allow the user to set up security levels for some or all transactions that require authentication. For example, the user may be allowed to set a high security level for financial transactions above a certain threshold or to set a low security level for small transactions. Card data encoded in the magnetic stripe of the card may be collected by the card reader with the same swipe, but the card data may or may not be transmitted to the authentication system. In some embodiments, card data may only be transmitted to the server of the service provider associated with the verification ID to identify a particular transaction.

  As described above, the user device may include an imaging device such as a camera. The camera may be configured to capture a QR code or visual graphical barcode. The user device may be configured to operatively couple to the card reader to collect authentication information and card information.

  In some embodiments, the network layout may include multiple user devices. Each user device may be associated with a user. A user may include any individual or group of individuals using software or applications provided by an authentication system. For example, a user can access a user device or web account using an application programmable interface (API) provided by the authentication system. In some embodiments, multiple users may be associated with a user device. Alternatively, multiple user devices may be associated with one user. The users can be geographically at the same location (e.g., users working at the same office or at the same geographic location). In some instances, some or all of the users and user devices may be at distant geographical locations (eg, different cities, countries, etc.), but that is not a limitation of the present invention.

  The network layout may include multiple nodes. Each user device in the network layout may correspond to a node. If "user device 1502" is followed by a number or letter, it means that "user device 1502" may correspond to a node sharing the same number or letter. For example, as shown in FIG. 15, user device 1502-1 may correspond to node 1 associated with user 1 and user device 1502-2 may correspond to node 2 associated with user 2; 1502-k may correspond to a node k associated with user k, where k may be any integer greater than one.

  A node may be a logically independent entity in a network layout. Thus, multiple nodes in the network layout can represent different entities. For example, each node may be associated with a user, a population of users, or multiple populations of users. For example, in one embodiment, nodes may correspond to individual entities (eg, individuals). In certain embodiments, a node may correspond to multiple entities (e.g., groups of individuals).

  A user may be registered or otherwise associated with an entity that provides services related to one or more operations performed by the disclosed embodiments. For example, a user may be an entity (eg, a company, an organization, an individual, etc.) that provides one or more of an authentication server 1508, a database 1512, and / or an authentication system 1510 for user authentication consistent with the particular embodiments disclosed. Can be a registered user of One user may be associated with one or more cards for various transactions. In some embodiments, the card used in the transaction may be registered with an entity (eg, a business, an organization, an individual, etc.) providing one or more of the servers 1504. The disclosed embodiments are not limited to any particular relationship or arrangement between a user and an entity, person, or server 1504, database 1512, authentication server 1508, and authentication system 1510.

  The user device may be configured to receive input from one or more users. The user may provide input to the user device using an input device, such as a keyboard, a mouse, a touch screen panel, voice recognition and / or dictation software, or any combination of the above. The input may include the user performing various virtual operations during or prior to the authentication session. The input may include, for example, the user selecting a security level for a particular transaction. The input may also include, for example, a user login to an account of the application provided by the authentication system.

  In the embodiment of FIG. 15, a bi-directional data transfer function is provided between the authentication server 1508 and each user device 1502, between the server 1504 and each user device 1502, between the authentication server 1508 and the server 1504, etc. obtain.

  The authentication server may include one or more server computers configured to perform one or more operations consistent with the disclosed embodiments. In one aspect, the server may be implemented as a single computer through which the user device can communicate with other components of the network layout. In some embodiments, a user device may communicate with a server via a network. In other embodiments, an authentication server may communicate with the authentication system or database via a network instead of the user device. In some embodiments, an authentication server may implement the functionality of one or more authentication systems. In some embodiments, an authentication system may be implemented inside and / or outside of the server. For example, the authentication system may be software and / or hardware components contained within or remote from the server. The server may also be a server in a data network (e.g. a cloud computing network).

  In some embodiments, user devices may be directly connected to the authentication server 1508 by a separate link (not shown in FIG. 15). In particular embodiments, an authentication server may be configured to operate as a front end device configured to provide access to one or more authentication systems consistent with the disclosed specific embodiments. In some embodiments, the authentication server utilizes the authentication system to compare input data from the user device to compare and verify authentication data (eg, swipe characteristic data, magnetic fingerprint data, location data, etc.) for authentication purposes. Can be processed. The authentication server may be configured to store user authentication data in a database. The server may also be configured to retrieve, retrieve and analyze authentication data stored in the database.

  In some embodiments, a user device may be connected directly to server 1504 to complete a transaction. In some embodiments, the server may include a web server, an enterprise server, or any other type of computer server, and the request (eg, data) from a computing device (eg, a user device or a publicly shared device) It can be computer programmed to accept HTTP (or other protocols that may initiate transmission) and to provide the requested data to the computing device. In addition, the server may be a free-to-air (FTA), cable, satellite or other broadcast facility, and other broadcast facilities for delivering data. The server can also be a server in a data network (eg, a cloud computing network).

  The server may include known computing components, such as one or more processors and one or more memory devices storing data instructions and software instructions executed by the processors. The server may have one or more processors and at least one memory for storing program instructions. The processor may be a single or multiple microprocessors capable of executing a specific instruction set, a rewritable gate array (FPGA), or a digital signal processor (DSP). Flexible disk, hard disk, CD-ROM (compact disk read only memory), MO (magneto-optical), DVD-ROM (digital versatile disk read only memory), DVD RAM (digital versatile disk random access memory), semiconductor memory etc Computer readable instructions may be stored on a tangible, non-transitory computer readable medium. Alternatively, the method disclosed herein may be implemented by hardware components such as an ASIC, a special purpose computer, a general purpose computer, or a combination of hardware and software. Although FIG. 15 shows the authentication server as a single server, in some embodiments, multiple devices may implement the functionality associated with the authentication server.

  The network may be configured to provide communication between various components of the network layout shown in FIG. In some embodiments, the network may be implemented as one or more networks that connect devices and / or components within the network layout to enable communication therebetween. For example, as recognized by those skilled in the art, the network may be one of the Internet, a wireless network, a wired network, a local area network (LAN), a wide area network (WAN), Bluetooth, near field communication (NFC) or a network layout It may be implemented as any other type of network that provides communication between multiple components. In some embodiments, the network may be implemented using cell and / or pager networks, satellites, licensed radios, or a combination of licensed and unlicensed radios. The network can be wireless, wired, or a combination thereof.

  The authentication system, when executed by one or more processors, generates, upon request from server 1504, a plurality of visual graphical codes (eg, QR codes), each of which is associated with a particular transaction by a verification ID, thereby the code Alternatively, the locator may be implemented as one or more computers storing instructions returned to server 1504. The user can scan the code by the authenticated user device and send the code back to the authentication system. For mutual authentication, the authentication system may provide the service provider with user authentication based on the code or may provide the user with service provider authentication. The authentication system can further analyze authentication reading data (eg, magnetic fingerprint data, swipe characteristic data, position data, etc.) collected from the user device during various authentication sessions, whereby the number of factors examined is It can be determined by a predetermined security level. In some embodiments, the server may be a computer in which the authentication system is implemented.

  However, in some embodiments, at least a portion of the authentication system may be implemented on a separate computer. For example, the user device may send user input to the authentication server, which may connect to other authentication systems over the network.

  The server can access and execute the authentication system to perform one or more processes consistent with the disclosed embodiments. In particular configurations, the authentication system may be software stored in memory accessible by the server (e.g., in remote memory accessible over a communications link such as memory or network local to the server). Thus, in particular aspects, the authentication system may be implemented as one or more computers, as software stored on a memory device accessible by a server, or as a combination thereof. For example, one authentication system may be computer hardware that implements one or more authentication techniques, and another authentication system may be software that performs one or more authentication techniques when executed by a server.

  An authentication system may be used to authenticate a user in a variety of different ways. For example, the authentication system may store and / or execute software that executes an algorithm for authenticating the user based on the QR code or visual graphical code submitted by the user device along with the authentication read data. The authentication system may also store and / or execute software that executes an algorithm for generating visual graphical code (e.g., QR code) having a particular verification ID. The authentication system may further store and / or execute software that executes an algorithm for dynamically determining the security level based on the request from the user and / or the service provider during each authentication session.

  The disclosed embodiments may be configured to implement an authentication system such that various algorithms may be performed to perform one or more authentication techniques. Although multiple authentication systems have been described for performing the above algorithm, it is noted that some or all of the algorithms may be performed using a single authentication system consistent with the disclosed embodiments. It should.

  User equipment 1502, authentication server 1508, service provider server 1504, and authentication system 1510 may be connected or interconnected with one or more databases 1512. The database may be one or more memory devices configured to store data (e.g., QR code, swipe characteristic data, magnetic fingerprint data, user identification, service provider identification, transaction / verification ID, etc.). Additionally, in some embodiments, the database may also be implemented as a computer system having a storage device. In one aspect, a database may be used by components of the network layout to perform one or more operations consistent with the disclosed embodiments. In particular embodiments, one or more databases may be co-located with a server, or co-located with each other on a network. Those skilled in the art will recognize that the disclosed embodiments are not limited to the configuration and / or mechanism of this database.

  The device 1512 may be a non-authenticated device in that the device's identification is not registered in the authentication system and the security level of the device is unknown. In some embodiments, using this device, a user accesses or trades confidential information provided by server 1504. Types of transactions that can be certified include web-based financial transactions, counter-sale financial transactions, security transactions, and identification transactions. A non-authenticated device may be a publicly shared device whose identity and security are not known to the authentication system. As described above, the device may be a display device configured to display visual graphical code (eg, QR code) to the user. Code locators or visual graphical code may be transmitted from server 1504 to the device. In some embodiments, where a locator (eg, a URL) is provided, the QR code may be displayed by an interface such as a web page or any software. The interface is linked to the server by a locator (eg, a URL) to establish communication between the user and the server. In another embodiment, a code that encrypts the verification ID may be conveyed directly to the display device and displayed to the user with or without the interface. A device, such as a laptop (e.g. laptop), requiring the user to authenticate or verify the user to perform a session or transaction that utilizes the display device to complete the transaction performed on the server (i.e. service provider) It can be a computer or desktop computer), a mobile device (e.g. a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a vending machine etc. The display device may optionally be portable. The display device may be handheld.

  In some embodiments, any of the user device, display device, server, database, and / or authentication system can be implemented as a computer system. Additionally, although FIG. 15 shows the network as a "central" point for communication between components of the network layout, the disclosed embodiments are not limited thereto. For example, one or more components of the network layout can be interconnected in various ways, and as will be appreciated by those skilled in the art, in some embodiments they may be directly connected, co-located or separated from one another. good. In addition, although some disclosed embodiments may be implemented on a server, the disclosed embodiments are not limited thereto. For example, in some embodiments, other devices (such as one or more user devices) may perform one or more of the processes and functions consistent with the disclosed embodiments, including the embodiments described with respect to servers and authentication systems. Can be configured.

  Although particular computing devices are illustrated and described for networks, it should be recognized and understood that other computing devices and networks may be utilized without departing from the spirit and scope of the embodiments described herein. In addition, one or more components of the network layout may be interconnected in various ways, as will be recognized by those skilled in the art, and in some embodiments are directly connected, co-located or separated from one another There is a case.

  FIG. 16 illustrates a schematic block diagram of an exemplary system and method for authenticating a user within a transaction, according to some embodiments. Authentication may be multifactor authentication. The authentication may be mutual authentication between the users involved in the transaction and the third party server. At least two different types of factors may be used for authentication. The factors may be selected from the group comprising one-time barcodes, magnetic card swipes, magnetic fingerprints of cards, and position data for user devices or card readers. In some cases, at least one of the factors is used to detect fraud and at least one of the factors is used to verify the user identity. In some cases, at least one of the factors is used to verify the identity of the third party server. In one aspect of the invention, authentication system 1610, server 1606, and user device 1602 can be involved in a mutual authentication process that verifies the authenticity of both the user and the service provider so that secure communications can be performed. In some embodiments, the cards used within a particular transaction are registered with server 1606 (service provider). In some cases, a card may be registered with the authentication system 1610 to function as a token. The server 1606 is provided or managed by a service provider. In some cases, servers may be provided or managed by third party entities. Both the service providing entity and the user may have been registered with the authentication system 1610 in the past. If the user is registered, the authentication system includes information about the user identification, one or more cards associated with the user, one or more historical card data associated with each card (eg, swipe characteristics, magnetic fingerprints, etc.) You can create an account. In some embodiments, the account may also include an identification of the user device associated with the user. The user may or may not be required to log in to the user's account by the application from the user device, the application being provided by the authentication system. In some embodiments, the authentication server maintains additional information such as the QR code submitted by the user device, collected location data, authentication data during an authentication session, and the like.

  At the beginning of the transaction, server 1606 may send a request to authentication system 1610. The request may encode an authenticated service provider identity and a session ID. The request may be initiated when an authentication session is expected. In some cases, the request may also include the desired security level. The authentication system 1610 decrypts the server identification and session ID and generates a visual graphical code (e.g. QR code) uniquely associated with the request. The unique one-time identifier may be a verification ID unique to a QR code that may be used to retrieve and authenticate data. In some embodiments, the QR code may be a single-use identifier that encrypts a unique verification ID.

  The authentication system then sends the code or a link to the code to the server 1606. The service provider then forwards to the device 1604 to display the code or a link to the code. In some embodiments, device 1604 may be a non-authenticated device to an authentication system. In some embodiments, the device acts as an interface (eg, a web browser that allows the user to access his bank account) to allow the user to interact with the service provider to access sensitive information or conduct transactions. .

  The user can use the user device 1602 to scan the code displayed on the unauthenticated device. The user device then sends the scanned code to the code analyzer to decode the service provider's identity. In some embodiments, instead of the raw code, the server identification and session ID may be decrypted by a code analyzer executed on the user device and transmitted to the authentication system. When the code analyzer verifies that the verification ID uniquely matches the specific transaction required by the authorized service provider, the user device uses the visual, audible or tactile indicator that the service provider is authentic Can be shown. In some embodiments, the indicator may be a light emitting diode (LED) located on the card reader, prompting the user to swipe the card. In another embodiment, the indicator may be a message indicating to the user by the user device that the service provider or the transaction has been authenticated.

  In some embodiments, the identification of the user device (eg, a user device identifier) or the identification of the user may also be submitted to the authentication system along with the QR code. The user can then swipe the payment card using the card reader coupled to the user device 1602 and transmit the collected data to the authentication system via communication between the card reader, the user device, and the authentication system .

  The authentication system can then authenticate the user by analyzing the authentication reading of the card including swipe characteristic data, magnetic fingerprint data, and location data. For example, the authentication system can compare a first set of data including authentication reading of the card, such as swipe characteristic data, magnetic fingerprint data, location data, etc., to a pre-stored set of collected data, such as history data. In some embodiments, one or more of the factors for which the process is analyzed can be skipped. Depending on the security level required by the service provider or user, various combinations of factors to be examined may be determined. For example, if a high level of security is desired for a transaction, more factors may be examined for user authentication. As described above, magnetic fingerprint data may be transferred to a magnetic fingerprint analyzer for comparison with one or more magnetic fingerprints collected in the past. In some embodiments, historical magnetic fingerprints may be retrieved from the authentication system based on the user identified by the QR code. The identification of the card based on the comparison can be evaluated, and additional user related information or card information can be evaluated according to the user account. Optionally, an indication of the likelihood of fraud may be provided if the magnetic fingerprint data does not match any historical data. In some embodiments, if no identification of the user is provided, the collected magnetic fingerprint data may be compared to all or part of the historical data store in the database to identify the card and the associated user. . Similarly, swipe characteristic data may be transferred to the swipe data analyzer along with the magnetic fingerprint data for comparison with one or more swipe characteristic data collected in the past. In some embodiments, when card identification is verified by QR code and magnetic fingerprint data, only historical swipe data associated with the identified card need be retrieved. As a result, the identity of the card or user may be verified with additional swipe information, or optionally an indication of the likelihood of fraud may be provided. It should be pointed out that the magnetic fingerprint and / or swipe properties can be used individually or in combination in authenticating the card and / or the user. The authentication process may perform a series of factor checks in any order or simultaneously. Position data may be transmitted to the position analyzer to verify the user identification. As discussed above, sets of identical location data associated with the same card may indicate a replay attack. Thus, an indication of the likelihood of fraud may be provided by comparing the collected position data with stored position data associated with the identified card. Based on all of the above authentication analysis, the authentication system can determine if the user, the card, and the transaction are genuine. An authenticated user identification can be provided to the server 1606 along with the uniquely associated transaction ID, and thus the transaction can be securely completed. In some embodiments, the transaction is performed between the user device 1602 and the server 1606 via a network that bypasses the non-authenticated device. Communication between the user device and the authentication server, the authentication server and the service provider can be protected using various encryption techniques. In order to protect the communication in the network, any combination of server certificates, Secure Socket Layer (SSL), secure protocols such as TLS (Transport Layer Security), and / or Internet Protocol (IP) addresses It can be used.

  An overview of the process according to the present system for mutual authentication is shown in FIG. The process begins with the server requesting the one-time code from the code generator (1702). In some embodiments, this code is a QR code. Upon receiving the request, the code generator generates a one-time QR code that is encoded with a verification ID that includes the identity of the service provider. The server receives a QR code or link that may be used to retrieve the code stored in the authentication server and displays it to the user by the non-authentication device (1704). The user scans the QR code using the user device and transmits the code to the QR code analyzer (1706). The code analyzer decrypts the verification ID and confirms the identity of the service provider (1708). If the service provider is authenticated, the user may be prompted to swipe a card (eg, a magnetic payment card) through a card reader connected to the user device (1710). Card authentication data, including swipe characteristics, magnetic fingerprints, and location data may be transmitted to an authentication system for user authentication (1712). At least one of the card readers is used to identify the card, and the remaining data may be used for user ID verification and fraud detection (1712). Once analyzed, the service provider may receive the authenticated user identity along with the uniquely associated transaction ID to complete the transaction. Step 1710 involves several authentication factors, and it is pointed out that any combination and order of performing the authentication process may be used to authenticate the user as described above. For example, in one embodiment, magnetic fingerprint data may be used to identify a user or a card, and each or a combination of swipe data and position data may be used to verify the identification. In another embodiment, the user identification may be received by the authentication system with the QR code at step 1708, while any combination of the other three factors may be used for verification. As mentioned earlier, various combinations of factors used for authentication may be determined based on the desired security level set by the service provider, user or authentication system.

  In another aspect of the present invention, methods and systems for authenticating a user may be provided. Authentication may be multifactor authentication. At least two different types of factors may be used for authentication. The factors may be selected from the group comprising one-time barcodes, magnetic card swipes, magnetic fingerprints of cards, and position data for user devices or card readers. In some cases, at least one of the factors is used to detect fraud and at least one of the factors is used to verify the user identity. FIG. 18 shows a schematic block diagram of an exemplary system and method for authenticating a user in connection with a transaction, according to some embodiments. Authentication system 1810, server 1806, and user device 1802 may be involved in an authentication process that verifies the authenticity of the user, the transaction card, or both, so that secure transactions can be performed within the system. In some embodiments, the cards used within a particular transaction are registered with server 1806 (service provider). The server 1806 is provided or managed by a service provider. In some cases, servers may be provided or managed by third party entities. Both the service providing entity and the user may have been registered with the authentication system 1810 in the past. If the user is registered, the authentication system includes information about the user identification, one or more cards associated with the user, one or more historical card data associated with each card (eg, swipe characteristics, magnetic fingerprints, etc.) You can create an account. In some embodiments, the account may also include an identification of the user device associated with the user or an identifier of the user device. The user may or may not be required to log in to the user's account by the application from the user device, the application being provided by the authentication system. In some embodiments, the authentication server holds additional information such as the QR code generated by the authentication server, location data submitted by the user device, authentication data during an authentication session, etc.

  At the beginning of the transaction, server 1806 may send a request to a code generator hosted within authentication system 1810. The request may encode an authenticated service provider identity and a session ID. The request may be initiated when an authentication session is expected. In some cases, the request may also include the desired security level. An authentication system 1810 decrypts the server identity and generates a visual graphical code (eg, a QR code) uniquely associated with the request. The one-time identifier may be a verification ID unique to a QR code that may be used to retrieve and authenticate data. In some embodiments, the QR code is intended for single use and can be an identifier that encrypts a unique verification ID.

  The authentication system then sends the code or a link to the code to the server 1806. The service provider then forwards to the device 1804 to display the code or a link to the code. In some embodiments, device 1804 may be a non-authentication device to an authentication system. In some embodiments, the device acts as an interface (eg, a web browser that allows the user to access his bank account) to allow the user to interact with the service provider to access sensitive information or conduct transactions. . The user can use the user device 1802 to scan the code displayed on the unauthenticated device. The user equipment then transmits the scanned code to the code analyzer along with the user / device identification. By logging into the account within the application, more than one user may be authorized to use the same user device. Thus, user identification may be provided to the authentication system along with the QR code. The code analyzer may be configured to retrieve additional stored user information in accordance with the provided user identification, and the identified user information may then be transferred to the service provider.

  The service provider may or may not respond to the preliminary user identification. If there is no negative message from the server, the user is prompted to swipe the payment card using the card reader coupled to the user device 1802, and the collected data is transferred between the card reader, the user device and the authentication system. It may be transmitted to the authentication system via communication. The authentication system can then further authenticate the user and payment card by analyzing the authentication reading of the card including swipe characteristic data, magnetic fingerprint data, and location data. For example, the authentication system can compare a first set of data including authentication reading of the card, such as swipe characteristic data, magnetic fingerprint data, location data, etc., to a pre-stored set of collected data, such as history data. In some embodiments, one or more of the factors for which the process is analyzed can be skipped.

  Depending on the security level required by the service provider or user, various combinations of factors to be examined may be determined. For example, if a high level of security is desired for a transaction, more factors may be examined for user authentication. As described above, magnetic fingerprint data may be transferred to a magnetic fingerprint analyzer for comparison with one or more magnetic fingerprints collected in the past. In some embodiments, historical magnetic fingerprints may be retrieved from the authentication system based on the user identified by the QR code. The identification of the card based on the comparison can be evaluated, and additional user related information or card information can be evaluated according to the user account. Optionally, an indication of the likelihood of fraud may be provided if the magnetic fingerprint data does not match any historical data. In some embodiments, if no identification of the user is provided, the collected magnetic fingerprint data may be compared to all or part of the historical data store in the database to identify the card and the associated user. . Similarly, swipe characteristic data may be transferred to the swipe data analyzer along with the magnetic fingerprint data for comparison with one or more swipe characteristic data collected in the past.

  In some embodiments, when card identification is verified by QR code and magnetic fingerprint data, only historical swipe data associated with the identified card need be retrieved. As a result, the identity of the card or user may be verified with additional swipe information, or optionally an indication of the likelihood of fraud may be provided. It should be pointed out that the magnetic fingerprint and / or swipe properties can be used individually or in combination in authenticating the card and / or the user. The authentication process may perform a series of factor checks in any order or simultaneously. Position data may be transmitted to the position analyzer to verify the user identification. As discussed above, sets of identical location data associated with the same card may indicate a replay attack. Thus, an indication of the likelihood of fraud may be provided by comparing the collected position data with stored position data associated with the identified card.

  Based on all of the above authentication analysis, the authentication system can determine if the user and the card are authentic. An authenticated user identification can be provided to the server along with the uniquely associated transaction ID, and thus the transaction can be securely completed. In some embodiments, the transaction is performed between the user device 1802 and the server 1806 via a network that bypasses non-authenticated devices. Communication between the user device and the authentication server, the authentication server and the service provider can be protected using various encryption techniques. Server certificates, Secure Socket Layer (SSL), and / or any combination of Internet Protocol (IP) addresses can be used to secure communications in the network.

  An overview of the process by the present system for authenticating users and cards is shown in FIG. The process begins with the server requesting the one-time code from the code generator (1902). In some embodiments, this code is a QR code. Upon receiving the request, the code generator generates a one-time QR code that is encoded with a verification ID that includes the identity of the service provider. The server receives the direct QR code or link for retrieving the code stored in the authentication server and displays it to the user by the non-authentication device (1904). The user scans the QR code using the user device and transmits the code to the QR code analyzer along with the user identification or user device identifier (1906). The code analyzer decrypts the verification ID and associates it with the user identification (1908). The user may then be prompted to swipe a card (eg, a magnetic payment card) through a card reader connected to the user device (1910). Card authentication data, including swipe characteristics, magnetic fingerprints, and location data may be transmitted to the authentication system for further user authentication (1912). At least one of the card readers is used to identify the user and the card, and the remaining data can be used for user identification and card identification verification and fraud detection (1912). For example, a pre-stored set of collected data, such as historical data, from a set of collected data derived from a card reading, including at least one of swipe characteristic data, magnetic fingerprint data, and location data to detect fraud. And can be compared. In order to verify the user identification, another set of collected data from card reading can be compared to a set of pre-stored collection data, such as historical data. Once analyzed, the service provider can receive the authenticated user identity along with the uniquely associated transaction ID to complete the transaction. Step 1910 carries several authentication factors and it is pointed out that any combination and order of performing the authentication process may be used to authenticate the user as described above. For example, in one embodiment, magnetic fingerprint data may be used to identify a user, and each or a combination of swipe data and position data may be used to verify the identification. In another embodiment, the user identification may be identified by a QR code, and any combination of the other three factors may be used for verification. As mentioned earlier, the combination of factors used for authentication may be determined based on the desired security level set by the service provider, the user or the authentication system.

  In yet another aspect of the present invention, the methods and systems disclosed herein are used to enable a user to securely conduct transactions via a non-authenticated device without entering credential handling credentials. obtain. FIG. 20 shows a schematic block diagram of an exemplary system and process for enabling a user to securely conduct transactions using a non-authenticated device, according to some embodiments. The authentication system 2010, the server 2006, the user device 2002, and the non-authentication device 2004 can be involved in an authentication process that verifies the authenticity of both the user and the transaction card so that secure transactions can be performed within the system. In some embodiments, the cards used within a particular transaction are registered with server 2006 (service provider). The server 2006 is provided or managed by a service provider. In some cases, servers may be provided or managed by third party entities. Both the service providing entity and the user may have been registered with the authentication system 2010 in the past. If the user is registered, the authentication system includes information about the user identification, one or more cards associated with the user, one or more historical card data associated with each card (eg, swipe characteristics, magnetic fingerprints, etc.) You can create an account. In some embodiments, the account may also include an identification of the user device associated with the user. The user may or may not be required to log in to the user's account by the application from the user device, the application being provided by the authentication system. In some embodiments, the authentication server maintains additional information such as the QR code submitted by the user device, collected location data, authentication data during an authentication session, and the like.

  At the start of the transaction, server 2006 may send a request to a code generator hosted within authentication system 2010. The request may encode the identity of the authenticated service provider and the session ID, and may be initiated when an authentication session is expected. In some cases, the request may also include the desired security level. The authentication system 2010 decrypts the server identification and session ID and generates visual graphical code (e.g. QR code) uniquely associated with the request. The one-time identifier may be a verification ID unique to a QR code that may be used to retrieve and authenticate data. In some embodiments, the QR code may be an identifier intended for single use, and may encrypt a unique verification ID.

  The authentication system then sends the code or a link to the code to the server 2006. The service provider then forwards to the device 2004 to display the code or a link to the code. In some embodiments, device 2004 may be a non-authentication device to an authentication system. In some embodiments, the device acts as an interface (eg, a web browser that allows the user to access his bank account) to allow the user to interact with the service provider to access information or conduct transactions. The user can use the user device 2002 to scan the code displayed on the non-authentication device.

  The user device then transmits the scanned code to the code analyzer to decode the service provider's identity. In some embodiments, instead of the raw code, the server identification and / or session ID may be decrypted by a code analyzer executed on the user device and transmitted to the authentication system. In some embodiments, the identity of the user device or user may also be submitted to the authentication system along with the QR code. A user identity may be provided to the service provider once the code analyzer verifies that the verification ID uniquely matches the particular transaction required by the authenticated service provider.

  Unauthenticated devices may be instructed by the service provider to display all or part of the user identification to the user. The user may not be permitted to take further action (eg, swipe the card) until some or all of the user identification displayed on the device 2004 identified by the user has been processed. The user can submit a confirmation (eg, a button click or an audible command) by the user device or by a non-authentication device. The user can then swipe the payment card with the card reader connected to the non-authentication device 2004 and transmit the collected data to the authentication system via communication between the card reader, the device and the authentication system.

  The authentication system can then authenticate the user by analyzing the authentication reading of the card including swipe characteristic data, magnetic fingerprint data, and location data. For example, the authentication system can compare the authentication reading of the card, including swipe characteristic data, magnetic fingerprint data, and location data, with a pre-stored set of collected data, such as history data.

  In some embodiments, one or more of the factors for which the process is analyzed can be skipped. Depending on the security level required by the service provider or user, various combinations of factors to be examined may be determined. For example, if a high level of security is desired for a transaction, more or all of the factors may be examined for user authentication. As described above, magnetic fingerprint data may be transferred to a magnetic fingerprint analyzer for comparison with one or more magnetic fingerprints collected in the past. In some embodiments, historical magnetic fingerprints may be retrieved from the authentication system based on the identification of the user submitted with the QR code. The identification of the card based on the comparison can be evaluated, and additional user related information or card information can be evaluated according to the user account. Optionally, an indication of the likelihood of fraud may be provided if the magnetic fingerprint data does not match any historical data. In some embodiments, if no identification of the user is provided, the collected magnetic fingerprint data may be compared to all or part of the historical data store in the database to identify the card and the associated user. . Similarly, swipe characteristic data may be transferred to the swipe data analyzer along with the magnetic fingerprint data for comparison with one or more swipe characteristic data collected in the past. In some embodiments, when card identification is verified by QR code and magnetic fingerprint data, only historical swipe data associated with the identified card need be retrieved. As a result, the identity of the card or user may be verified with additional swipe information, or optionally an indication of the likelihood of fraud may be provided. It should be pointed out that the magnetic fingerprint and / or swipe properties can be used individually or in combination in authenticating the card and / or the user. The authentication process may perform a series of factor checks in any order or simultaneously. Position data may be transmitted to the position analyzer to verify the user identification. As discussed above, sets of identical location data associated with the same card may indicate a replay attack. Thus, an indication of the likelihood of fraud may be provided by comparing the collected position data with stored position data associated with the identified card.

  Based on all of the above authentication analysis, the authentication system can determine if the user and the transaction are genuine. An authenticated user identity can be provided to the service provider along with a uniquely associated transaction ID, so that the transaction can be securely completed by the non-authorization device 2004. The transaction may be, for example, bill payment, money transfer, etc., which requires the user to access his account with a non-certified device. Communication between the user device and the authentication server, the authentication server and the service provider can be protected using various encryption techniques. Server certificates, Secure Socket Layer (SSL), and / or any combination of Internet Protocol (IP) addresses can be used to secure communications in the network.

  In some embodiments, visual graphical barcodes or graphical authentication indicia may be used to provide an additional authentication layer. The visual graphical barcode may be scanned by a user device having an imaging device. Visual graphical barcodes can be used in a variety of ways, including the applications described elsewhere herein.

  Visual graphical barcodes may be in any form that can be captured and / or displayed on a device, such as barcodes, text, pictures, sequences thereof, and the like. The visual graphical barcode may be a two dimensional barcode such as PDF417, Aztec, MaxiCode, QR Code, and the like. Visual graphical barcodes include Interleaved 2/5, Industrial 2/5, Code 39, Code 39 Extended, Codabar, Code 11, Code 128, Code 128 Extended, EAN / UCC 128, UPC-E, UPC-A, EAN-8, EAN-13, One-dimensional bar codes such as Code 93, Code 93 Extended, DataBar Omnidirectional (RSS-14), DataBar Truncated (RSS-14 Truncated), DataBar Limited (RSS Limited), DataBar Stacked, DataBar Expanded, DataBar Expanded Stacked, etc. may be used. The barcode can encode various types of information in any type of suitable format, such as binary, alphanumeric, ASCII, etc., and the code can be based on any standard. Visual graphical barcodes can have various storage capacities and arbitrary physical sizes that can encode a fixed amount of data. In some embodiments, visual graphical barcodes may conform to known standards readable by standard barcode readers. In another embodiment, the visual graphical barcode may be proprietary and such visual graphical barcode may only be read by an authenticated application provided by an authentication system implemented on the user device. In some cases, only an authentication system or an authenticated application can encrypt / decrypt visual graphical barcodes.

  The visual graphical barcode may be a one dimensional barcode, a two dimensional barcode, or a three dimensional barcode. Visual graphical barcodes may be one-dimensional barcodes, including, for example, linear patterns such as lines and spaces. Lines and spaces can be black and white. Lines and spaces can be colored. The color may be identifiable by the human eye. Bar code colors may be distinguishable by specialized tools. For example, the barcode may include printed carbon lines detectable using an infrared scanner. Visual graphical barcodes can be two-dimensional barcodes that include various shapes. Visual graphical barcodes may be static or dynamic. Visual graphical barcodes may be changed or updated at certain frequencies. The frequency may be in a wide range such as 100 Hz to 0.001 Hz.

  In one aspect of the invention, a method of authentication or login based on visual graphical barcodes is provided. This method may be resistant to replay attacks. In some embodiments, nonce data may be collected and used as an anti-replay feature. Nonce data may be generated when an imaging device is used to scan a visual graphical barcode. The nonce data may be generated at any stage during the authentication transaction, such as before or after scanning the visual graphical barcode.

  In some embodiments, nonce data may be collected regarding the scanned image of the visual graphical barcode during the first transaction or the status of the imaging device. The nonce data may actually occur only once, and may include one or more sets of singularity values (e.g., nonce factors) that are not naturally repeated. Therefore, repeated nonce data may cause suspicion that a replay attack may be in progress. The nonce data may relate to the internal state of the imaging device, the user device or components of the user device, or may include data that may be collected in connection with a scanned image including visual graphical barcodes or graphical authentication indicia. The nonce data may include image capture information such as metadata related to the imaging device, position information, any other information, and the like. Nonce data may also include information generated while processing an image for context analysis.

  Nonce data may be generated at any stage in the transaction. For example, nonce data indicating the status of the user device and / or environment may be generated after the transfer of the barcode to the server during scanning of the visual graphical barcode at the beginning of the login or authentication process. In another example, nonce data may indicate user behavior, such as contact behavior on a touch screen of the user device.

  Nonce data may be generated while scanning visual graphical code using an imaging device. Nonce data may be generated based on various parameters of the image, including visual graphical code. The parameters may be obtained during preprocessing operations such as automatic adjustment of raw images by an image capture device (e.g. balance correction, gamma correction, demosaicing, despeckle etc). Parameters include physical tokens such as image segmentation, edge detection, corner detection, pattern detection, measurement of image skew angle and rotation, measurement of pixel content and histogram, image scaling, smoothing, morphological filters, etc. And / or may be obtained during an image processing operation to decrypt the token. The manipulation may be applied to the entire image or to the recognized region of interest. Nonce data may be generated based on the state of the imaging device, such as exposure settings, acquisition time, GPS position information, camera type, and the like.

  FIG. 21 shows an example of a user device 2104 according to an embodiment of the present invention. User device 2104 may be used to scan visual graphical barcodes or graphical authentication indicia 2107. Visual graphical barcodes or graphical authentication indicia may be displayed on another device 2101. User device 2104 and device 2101 may be separate devices. In some instances, graphical authentication indicia may be provided on or in the form of physical objects.

  A user device may be, for example, one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. In some embodiments, the user device may include an imaging device 2103 configured to capture visual graphical code such as barcodes (eg, one or two dimensional), text, pictures, sequences thereof, etc. described above. . The imaging device may include hardware and / or software elements. In some embodiments, the imaging device may be a camera operatively coupled to the user device. In some alternative embodiments, the imaging device may be located external to the user device, such as on the card reader 200, and the image data of the graphical element may be user device by means of communication as described elsewhere herein. Can be transmitted to The imaging device may be controlled by an application / software configured to scan visual graphical code. In some embodiments, software and / or applications may be configured to activate a camera on a user device to scan code. In other embodiments, the camera may be controlled by a processor originally embedded in the user device.

  User device 2104 may be a computing device capable of executing software or applications provided by one or more authentication systems. In some embodiments, the software and / or application may allow the user to scan graphical authentication indicia displayed on another device, and transmit authentication data between the user device and the authentication system during an authentication session. May be possible. The software and / or application may have been registered with the authentication system by the user. Optionally, no software and / or applications need to be registered with the authentication system, only user devices may be registered with the authentication system. In some embodiments, such as a card reader to collect authentication data (eg, swipe characteristic data, magnetic fingerprint data, location data, etc.) during an authentication session and encrypt the data prior to transmission to the authentication server, etc. Software and / or applications may be configured to control external devices. In some instances, the application may allow the user to set up security levels for some or all transactions that require authentication. For example, the user may be permitted to set a high security level for financial transactions above a predetermined threshold amount and a low security level for financial transactions below the predetermined threshold amount.

  The user device may include, among others, a desktop computer, laptop or notebook computer, mobile device (eg, smart phone, cell phone, personal digital assistant (PDA), tablet), or wearable device (eg, smart watch). The user device may also include any other media content player, such as a set top box, a television set, a video game system, or any electronic device capable of providing or rendering data. A user device may include known computing components, such as one or more processors and one or more memory devices that store software instructions and data executed by the processors. The user device may optionally be portable. The user device may be handheld. The user device may be a cash register in a store or other store. The cash register may be used during a transaction (such as a financial transaction) at a store or other store. The user device may be a network device capable of connecting to a network such as a local area network (LAN), a wide area network (WAN) such as the Internet, a telecommunication network, a data network, or any other type of network.

  In some embodiments, a picture of visual graphical code 2107 may be obtained and stored on a memory unit of user device 2104 for further image processing and decoding. Alternatively, the imaging device 2103 can scan the visual graphical code in real time without capturing a picture of the barcode. In this embodiment, the imaging device 2103 may continuously acquire an image of the visual graphical code 2107 and store it in memory. Each of these images is later processed until the visual graphical code is correctly deciphered. Once the visual graphical code 207 is deciphered, the imaging device 2103 can stop acquiring images of the visual graphical code.

  In some embodiments, user device 2104 may include one or more sensors. The one or more sensors may be configured to collect data indicating device status, imaging device status, or nonce data generated during the process. The one or more sensors may include, but are not limited to, position sensors (eg, Global Positioning System (GPS) sensors, mobile device transmitters that allow for triangulation of positions), vision sensors (eg, cameras, etc.) , Infrared light or ultraviolet light, image sensor, proximity sensor (eg ultrasonic sensor, lidar, time-of-flight camera), inertial sensor (eg accelerometer, gyroscope, inertial measurement unit (IMU)), altitude sensor , Pressure sensors (eg barometers), voice sensors (eg microphones), time sensors (eg clocks), temperature sensors, sensors capable of detecting memory usage and / or processor usage, or field sensors (eg magnetometers or electromagnetic) Sensors) can be included. Any suitable number and combination of sensors can be used, such as one, two, three, four, five or more sensors. Optionally, data can be received from various types of sensors (e.g., two, three, four, five, more). Different types of sensors measure different types of signals or information (eg position, orientation, velocity, acceleration, proximity, pressure etc) and / or obtain data using different types of measurement techniques Can. For example, the sensors may include any suitable combination of active sensors (eg, sensors that generate and measure energy from their own source) and passive sensors (eg, sensors that detect available energy).

  Any number of sensors can be provided on the board of the user device. The sensors may include different types of sensors or the same type of sensors. The sensors and / or any other components described herein can be contained within the device housing and embedded within the device housing or on the exterior of the device housing. The housing may or may not form a fluid tight (e.g., water tight or air tight) seal that separates the interior of the housing and / or the exterior of the housing.

  In some cases, the user device may include a touch screen 2105. A touch screen may provide an input interface and an output interface between the device and the user. The touch screen may display visual output to the user. Visual output may include graphics, text, icons, videos, and any combination thereof (collectively referred to as "graphics"). In some embodiments, some or all of the visual output may correspond to a user interface object instructing the user to confirm the login process, for example by touching a graphical button on a touch screen. In some cases, the touch location may be recorded. The touch position (e.g., X, Y coordinates) on the touch screen may be used as nonce data.

  Device 2101 may be a non-authenticated device whose security level may be unknown. This device may be the same device 1301 shown in FIG. Device 2101 may include a display device configured to display a visual graphical barcode to a user. In some embodiments, visual graphical barcodes may be displayed by an interface such as a web page or any suitable software. The device 2101 may need to authenticate or verify a user to perform a session or transaction that utilizes a display device to complete a transaction performed on a server (ie, a service provider), such as a computer (eg, a laptop It can be a top computer or desktop computer), a mobile device (e.g. a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a vending machine etc. The display device may optionally be portable. The display device may be handheld.

  In some embodiments, the visual graphical code 2107 displayed on the device may be any type of graphical code as previously described herein. Visual graphical code may be referred to as visual graphical barcodes or graphical authentication indicia. In some instances, visual graphical code may be one-time visual graphical code. Visual graphical code may expire or time out after a certain period of time or when they are verified. Alternatively, visual graphical code may be presented to the user as a physical object. Visual graphical code may be on physical elements held by the user. Physical elements include cards issued or provided by an entity or service provider (ID card, driver's license, payment card, library card, login card etc.), documents (passport, legal documents, medical records etc.) etc. possible. In another example, visual graphical code may be displayed on a display device, which may or may not be a device that provides user access to an account to complete a transaction. Or The display device requires the user to authenticate or verify the user to perform a session or transaction that utilizes the display device to complete the transaction performed on the server (i.e. service provider), e.g. It can be a top computer or desktop computer), a mobile device (e.g. a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a vending machine etc. The display device may optionally be portable. The display device may be handheld.

  As mentioned earlier, nonce data may be used to provide an additional authentication layer. Any description of nonce data may apply to various device measurements, indicators or parameters that may be less likely to repeat. The nonce data can include one or more nonce factors, or can be derived from such nonce factors. The nonce factor may include various types of data collected regarding the state of the user device, the imaging device, and / or the state of the captured image data. The nonce factor may include an action performed by the user, such as a touch on a touch screen. The nonce factor may include data from various sensors of the user device. The nonce factor may include various types of data collected regarding the state of the user device. The nonce factor may be taken at a single point in time, at multiple points in time, or over an interval of time. Each of the nonce factors may be from different points in time or may be from coincident and / or overlapping times. Each of the nonce factors may include data collected from different sensors of the device or different types of sensors. Alternatively, two or more of the nonce factors may be collected from the same sensor or sensors of the same type. In some instances, all of the nonce factors may be collected from the same sensor or sensors of the same type.

  The state of the user device may include environmental information collected by the user device during the authentication process or transaction. Environmental information may include audio information collected by the microphone of the device. Environmental information may include information collected by motion detectors, ultrasonic sensors, lidars, temperature sensors, pressure sensors, or any other type of sensor that may collect environmental information about the device. Environmental information may include detecting the location of the touch or hand of the user holding the device, and collecting any portion of the device or the portion touched or held by the user.

  FIG. 22 shows an example of collecting nonce data. User device 2200 may be used to log in to a user account by an external device (not shown). The user may be prompted to scan the visual graphical barcode displayed on the external device using the user device. Once the user is verified, the user may be authorized to access the associated account by the external device. The user device 2200 may be the same user device 2104 shown in FIG. The user device may include a touch sensitive display screen 2207. In some cases, the user device may further include a microphone 2203 for collecting audio data. The user device may be used to scan visual graphical barcodes. After the visual graphical barcode is scanned by the user device and verified by the authentication server, the user may be prompted to click on the graphical object 2201 on the user touch display screen to continue the process.

  The graphical object 2201 can be a visual representation having any graphical shape. It should be noted that various characteristics of graphical elements, such as colors, shapes, image content, etc. may be used as visual representations. The user may be prompted to click on the graphical object or touch the graphical object to verify the transaction or login activity. For example, a message may be provided to the user to verify whether the user intends to log in to the account by clicking or touching a graphical object (eg, a graphical object in the form of a button). In some cases, the position at which the user touches the graphical object or the XY coordinates of that position may be recorded and used as a nonce factor. It is unlikely that the position at which the user touches the screen is exactly the same each time. In some cases, the XY coordinates may be relative to the touch display screen. The XY coordinates may be for graphical elements such as graphical objects displayed on the screen.

  In some cases, in addition to visual graphical code, an authentication code may be provided to the user. In some situations, the user may be tricked into scanning for fraudulent visual graphical code that has been forged. Thus, it is useful to verify the authenticity of the visual graphical code. An authentication code can be used to verify the authenticity of the visual graphical code. The authentication code may be, for example, an audio code reproduced on an external device. The voice code may be generated by an authentication server. Voice codes may be uniquely associated with visual graphical code. The voice code may be uniquely associated with the device registered in the authentication system. The voice code may be uniquely associated with the user device or user account. The external device for playing back the audio code may be the same device that displays the visual graphical code. The external device may be coupled to a device that displays visual graphical code. The external device may include an audio emitter configured to emit an audio code. The audio code may be reproduced when the visual graphical code is displayed to the user for scanning. The voice code may be collected by the microphone of the user device, the visual graphical code may be scanned by the user device, and both the voice code and the visual graphical code may be transferred to the authentication server for authentication. The authentic server can verify both voice code and visual graphical code. If they do not match, such a mismatch may indicate a forged visual graphical code.

  The authentication code (e.g. voice code) and nonce data may be used in combination or separately. In one example, the voice code can be checked first to identify the authenticity of the visual graphical code, and then the nonce data can be checked to detect any replay attack. Voice codes and nonce data can be used in any order or simultaneously. Using voice code and nonce data can provide the visual graphical code with an extra layer of protection against phishing or replay attacks.

  In yet another aspect of the present invention, the methods and systems disclosed herein are used to enable a user to securely perform transduction via a non-authenticated device without having to enter confidential credentials. It can be done. FIG. 23 illustrates a schematic block diagram of an exemplary system and process for enabling a user to securely conduct a transaction using a non-authenticated device, according to some embodiments. Authentication may be multifactor authentication. In some cases, authentication may be mutual authentication between a user involved in a transaction and a third party server. At least two different types of factors may be used for authentication. The factors may be selected from the group comprising visual graphical barcodes, magnetic card swipes, magnetic fingerprints of the card, position data for the user device or card reader, and nonce data. In some cases, at least one of the factors is used to detect fraud and at least one of the factors is used to verify the user identity. In some instances, at least one of the factors is used to verify the identity of the third party server, such as visual graphical barcodes.

  Within the system, the authentication system 2310, the server 2306, the user device 2302, and the non-authentication device 2304 can be involved in an authentication process that verifies the authenticity of both the user and the transaction card so that secure transactions can be performed. In some embodiments, the card used within a particular transaction is registered with server 2306 (service provider). The server 2306 is provided or managed by a service provider. In some cases, servers may be provided or managed by third party entities. Both the service providing entity and the user may have been registered with the authentication system 2310 in the past. In some embodiments, the authentication server maintains additional information such as visual graphical code submitted by the user device, collected nonce data, authentication data during an authentication session, and the like. The transactions described elsewhere herein may include any activity requiring authentication or verification of a user or user device. A transaction may be, for example, an authentication login process that may allow a user to access accounts or sensitive information using one or more visual graphical barcodes or graphical authentication indicia. Visual graphical barcodes or graphical authentication indicia may have anti-replay functionality.

  At the beginning of the transaction, server 2306 may send a request to a code generator hosted within authentication system 2310. The request may encode the identity of the authenticated service provider and the session ID, and may be initiated when an authentication session is expected. In some cases, the request may also include the desired security level.

  The authentication system 2310 decrypts the server identification and session ID and generates visual graphical code uniquely associated with the request. In some cases, the authentication system may also generate an authentication code, such as a voice code, to verify the visual graphical code. The one-time identifier may be a verification ID unique to visual graphical code that may be used to retrieve and authenticate data. In some embodiments, visual graphical code can be an identifier intended for single use, and can encrypt a unique verification ID.

  The authentication system then sends the code or a link to the code (eg, visual graphical code or voice code) to the server 2306. The service provider then forwards to the device 2304 to display the code or a link to the code. In some embodiments, device 2304 may be a non-authentication device to an authentication system. In some embodiments, the device acts as an interface (eg, a web browser that allows the user to access his bank account) to allow the user to interact with the service provider to access information or conduct transactions. The user can scan the visual graphical code displayed on the non-authenticated device using the user device 2302. In some cases, the user device may also collect voice codes. In further cases, the user device may also be configured to collect nonce data (e.g., state of user device, imaging device, environment, etc.).

  The user device then transmits the scanned visual graphical code to the code analyzer to decode the service provider's identity. In some embodiments, instead of the raw code, the server identification and / or session ID may be decrypted by the visual graphical code analyzer executed on the user device and transmitted to the authentication system. In some embodiments, the identification of the user device or user along with the visual graphical code may also be submitted to the authentication system. Additionally, collected nonce data and / or voice codes may be transmitted to an authentication system to detect replay attacks or phishing attacks.

  A user identity may be provided to the service provider once the code analyzer verifies that the verification ID uniquely matches the particular transaction required by the authenticated service provider. Unauthenticated devices may be instructed by the service provider to display all or part of the user identification to the user. The user may not be authorized to perform further actions (eg, swipe the card) until some or all of the user identification displayed on the device 2304 identified by the user has been processed. The user can submit a confirmation (eg, a button click or an audible command) by the user device or by a non-authentication device.

  The user can then swipe the payment card using the card reader connected to the non-authentication device 2304 and transmit the collected data to the authentication system via communication between the card reader, the device and the authentication system . The authentication system can then authenticate the user by analyzing the authentication reading of the card including swipe characteristic data, magnetic fingerprint data, and location data. For example, the authentication system can compare the authentication reading of the card, including swipe characteristic data, magnetic fingerprint data, and location data, with a pre-stored set of collected data, such as history data.

  In some embodiments, one or more of the factors for which the process is analyzed can be skipped. Depending on the security level required by the service provider or user, various combinations of factors to be examined may be determined. For example, if a high level of security is desired for a transaction, more or all of the factors may be examined for user authentication. As described above, magnetic fingerprint data may be transferred to a magnetic fingerprint analyzer for comparison with one or more magnetic fingerprints collected in the past. In some embodiments, historical magnetic fingerprints may be retrieved from the authentication system based on the identification of the user submitted with the visual graphical code. The identification of the card based on the comparison can be evaluated, and additional user related information or card information can be evaluated according to the user account. Optionally, an indication of the likelihood of fraud may be provided if the magnetic fingerprint data does not match any historical data. In some embodiments, if no identification of the user is provided, the collected magnetic fingerprint data may be compared to all or part of the historical data store in the database to identify the card and the associated user. . Similarly, swipe characteristic data may be transferred to the swipe data analyzer along with the magnetic fingerprint data for comparison with one or more swipe characteristic data collected in the past. In some embodiments, when card identification is verified by visual graphical code and magnetic fingerprint data, only historical swipe data associated with the identified card need be retrieved. As a result, the identity of the card or user may be verified with additional swipe information, or optionally an indication of the likelihood of fraud may be provided. It should be pointed out that the magnetic fingerprint and / or swipe properties can be used individually or in combination in authenticating the card and / or the user. The authentication process may perform a series of factor checks in any order or simultaneously. Position data may be transmitted to the position analyzer to verify the user identification. As discussed above, sets of identical location data associated with the same card may indicate a replay attack. Thus, an indication of the likelihood of fraud may be provided by comparing the collected position data with stored position data associated with the identified card.

  Based on all of the above authentication analysis, the authentication system can determine if the user and the transaction are genuine. An authenticated user identity can be provided to the service provider along with a uniquely associated transaction ID, so that the transaction can be securely completed by the non-authenticated device 2304. The transaction may be, for example, bill payment, money transfer, etc., which requires the user to access his account with a non-certified device. Communication between the user device and the authentication server, the authentication server and the service provider can be protected using various encryption techniques. Server certificates, Secure Socket Layer (SSL), and / or any combination of Internet Protocol (IP) addresses can be used to secure communications in the network.

  While particular implementations have been shown and described, various modifications may be added to those implementations and it is to be understood from the above that what is expected herein. Further, the present invention is not intended to be limited by the specific examples given in the present specification. While the present invention has been described in relation to the above specification, it is not intended that the description and drawings of the preferred embodiments herein be taken in a limiting sense. Further, it should be understood that all aspects of the present invention are not limited to the specific depictions, configurations, or relative proportions set forth herein depending upon various conditions and variables. Various modifications in the form and details of the embodiments herein will be apparent to those skilled in the art. Accordingly, the present invention is considered to include within the scope any such modifications, alterations, and equivalents.

Claims (20)

A method for authenticating an online transaction,
Receiving visual graphical barcode image data from a user device, wherein the visual graphical barcode is configured to be displayed on a non-authenticated device for conducting the on-line transaction;
Analyzing the image data using one or more processors to obtain a transaction verification identifier (ID);
Comparing the transaction verification ID with a pre-stored verification ID using the one or more processors;
Comparing the set of first collected data from the user device to the prestored set of second collected data using the one or more processors; and (1) the transaction verification ID and Approve the online transaction based on the agreement with the pre-article stored verification ID and (2) the agreement between the one set of first collected data and the one set of second collected data stored in advance Determining using the one or more processors whether to reject.   The method according to claim 1, wherein the prestored verification ID is generated in response to a request to perform a secure authentication step during the on-line transaction.   The method according to claim 2, wherein the secure authentication step is performed when a user performs the process of the online transaction using the non-authentication device, the non-authentication device having an unknown security level.   The method of claim 1, wherein the prestored verification ID is associated with the identification of a third party to provide the online transaction.   The method of claim 1, wherein the visual graphical barcode is a one-time barcode uniquely associated with the transaction.   The method of claim 1, further comprising receiving a user device identifier with the image data.   The method of claim 1, further comprising receiving nonce data with the image data to detect a replay attack.   The method according to claim 1, wherein the set of first collected data from the user device is provided by the user device or a card reader operatively coupled to the user device.   9. The method of claim 8, wherein the set of first collected data from the user device comprises card reading, the card reading being provided by swiping a card through the card reader.   The set of first collected data from the user device is (i) a magnetic fingerprint of the card, (ii) swipe characteristics of the card, (iii) location information regarding the card reader, or (vi) the user 10. The method of claim 9, comprising at least one of location information about the device.   11. The method of claim 10, wherein the swipe characteristics include speed, direction, angle, timing or pressure of the swipe as the card is swiped through the card reader.   When the card reader or the position information regarding the user device is provided using the card reader or one or more sensors on the user device, the position information is when the card swipes through the card reader The method according to claim 10, comprising an orientation or spatial position of at least one of the card reader or the user device of.   The method according to claim 1, wherein the set of first collected data from the user device is provided when the transaction verification ID matches the prestored verification ID. A system for authenticating online transactions,
A user device and a server in communication with a third party server providing said online transaction, said server comprising identification information on said third party server, a prestored user device identifier, a prestored set of first collected data And (i) a memory for storing a set of software instructions,
Receiving visual graphical barcode image data from the user device, wherein the visual graphical barcode is configured to be displayed on a non-authentication device;
Analyzing the image data to obtain a transaction verification identifier (ID);
Comparing the transaction verification ID to a pre-stored verification ID;
Comparing a set of second collected data from the user device to the pre-stored set of first collected data, and (1) the transaction verification ID and the pre-stored verification ID And (2) approving or rejecting the online transaction based on a match between: (2) and the match between the prestored set of first collected data and the set of second collected data from the user device And (ii) one or more processors configured to execute the set of software instructions to make a decision.   15. The system of claim 14, wherein the pre-stored verification ID is associated with the identification information for the third party server.   15. The system of claim 14, wherein the visual graphical barcode is a one-time barcode uniquely associated with the transaction.   15. The system of claim 14, further comprising receiving a user device identifier with the image data.   15. The system of claim 14, wherein the set of second collected data is provided by a user device or a card reader operatively coupled to the user device.   19. The system of claim 18, wherein the set of second collected data comprises card reading, the card reading being provided by swiping a card through the card reader.   The set of second collected data may be (i) a magnetic fingerprint of the card, (ii) swipe characteristics of the card, (iii) location information for the card reader, or (vi) location information for the user device. 20. The system of claim 19, comprising at least one of: