WO2015028916A1 - Système, procédé et dispositif d'authentification dépendant du contexte - Google Patents

Système, procédé et dispositif d'authentification dépendant du contexte Download PDF

Info

Publication number
WO2015028916A1
WO2015028916A1 PCT/IB2014/063959 IB2014063959W WO2015028916A1 WO 2015028916 A1 WO2015028916 A1 WO 2015028916A1 IB 2014063959 W IB2014063959 W IB 2014063959W WO 2015028916 A1 WO2015028916 A1 WO 2015028916A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
authentication
information
transaction
user device
Prior art date
Application number
PCT/IB2014/063959
Other languages
English (en)
Inventor
Deepak Chandra DUTT
Anil Buntwal SOMAYAJI
Original Assignee
Zighra Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/337,939 external-priority patent/US9619852B2/en
Application filed by Zighra Inc. filed Critical Zighra Inc.
Publication of WO2015028916A1 publication Critical patent/WO2015028916A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0487—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
    • G06F3/0488—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures
    • G06F3/04883—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures for inputting data by handwriting, e.g. gesture or text
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the present disclosure relates to a system, method and device for context- dependent authentication.
  • Authentication is an integral aspect of many different systems, for example, social media networks, email systems, payment systems, mobile commerce systems and so on.
  • An object of the present invention is to provide a method for authenticating a user using a user device connected to a communications network, the method comprising an implicit phase, wherein said implicit phase comprises performing at least one task within a workflow, said at least one task necessary to move forward within said workflow; storing information associated with said performing of at least one task; comparing said stored information with a stored user profile; and determining whether said authentication of said user is successful or unsuccessful based on said comparing.
  • a method for authenticating a user using a user device comprises recording information associated with a plurality of characteristics, further wherein said plurality of characteristics comprise one or more kinetic motions performed as part of one or more tasks, comparing information associated with the performance of the one or more kinetic motions to that stored within a user profile corresponding to the user; and determining whether said authentication of said user is successful or unsuccessful based on said comparing.
  • a method for identifying a user from among a plurality of users sharing a user device comprises recording information associated with a plurality of characteristics; further wherein said plurality of characteristics comprise one or more kinetic motions performed by the plurality of users as part of one or more tasks; comparing information associated with the performance of the one or more kinetic motions to that stored within a plurality of user profiles, each of the plurality of user profiles corresponding to one of the plurality of users; and identifying which of the plurality of users are using the device based on said comparing.
  • FIG. 1 illustrates a network communications system in which implemented is a fraud prevention system for transactions, in accordance with an embodiment
  • FIG. 2 is flow chart of one example of a method of authenticating a transaction in the fraud prevention system based on location criteria
  • FIG. 3A is a block diagram of an example of one variety of an authentication device
  • FIG. 3B is block diagram of an example of one variety of a user device
  • FIG. 3C shows one embodiment of a multi -layered authentication system.
  • FIGs. 3CA and 3CB show an embodiment of an interface for performing tasks for implicit authentication.
  • FIG. 3D shows one embodiment of a task-based multiple-level authentication process.
  • FIG. 3E shows one embodiment of a combined implicit-explicit authentication workflow.
  • FIG. 4A is a messaging flow diagram for one embodiment of authentication of a transaction in the network communications system for a case when authentication of a transaction succeeds;
  • FIG. 4B is a messaging flow diagram for one embodiment for authentication of a transaction in the network communications system for a case when authentication of a transaction originally fails;
  • FIG. 4C is another messaging flow diagram for one embodiment of authentication of a transaction in the network communications system for a case when authentication of a transaction originally fails;
  • FIG. 5 is a block diagram of an example of user device suitable for use with the fraud prevention system
  • FIG. 6A is a messaging flow diagram for one embodiment of authentication of a transaction in the network communications system in a push system for a case when verification of fraudulence of a transaction shows fraudulence
  • FIG. 6B is a messaging flow diagram for one embodiment of authentication of a transaction in the network communications system in a push system for a case when verification of fraudulence of a transaction shows no fraudulence
  • FIG. 7 represents a flow diagram of one implementation of the fraud detection unit method
  • FIG. 8 represents a flow diagram of another implementation of the fraud detection unit method
  • the present invention provides a context-dependent authentication system and method including a financial fraud detection and resolution management system, method, system, and device which analyze a variety of dynamic user-specific characteristics to authenticate a user to perform operations such as authorizing financial transactions, logging into a social media website or hosted webmail service.
  • User context is information that can be used to characterize the user.
  • User context includes a variety of aspects specific to the user, such as locational aspects, social aspects, physical aspects, psychological aspects and so on.
  • the network communications system may include communications service provider sites, banking institution sites, fraud reporting centers, LANs (Local Area Networks), transaction sites, and wireless user devices coupled to a network. Only two communications service provider sites, two banking institution sites, two fraud reporting centers, two LANs, two transaction sites, and two wireless user devices are shown for illustrative purposes.
  • the network communications system has one or more communications service provider sites, one or more banking institution sites, one or more fraud reporting centers, one or more LANs, one or more transaction sites, and one or more wireless user devices.
  • one or more of the banking institution sites includes a fraud reporting/detection center or a fraud reporting/detection unit.
  • Each banking institution site includes a fraud prevention system having a transaction server, an authentication device and a call agent.
  • Each fraud reporting center includes a database and a fraud reporting unit.
  • the fraud reporting unit comprises a fraud detection server.
  • Each LAN includes a plurality of user device and an access point.
  • Each communications service provider site has a location information server.
  • Each transaction site includes a server.
  • the network allows communications between the wireless user devices, the transaction servers, the authentication devices, and the call agents at the fraud prevention systems, the location information servers at the communications service provider sites, the user devices and access points at the LANs, the servers at the transaction sites, and the fraud reporting units of the fraud detection centers to communicate with each other through wired and wireless communications.
  • the network includes a combination of one or more cellular networks and one or more wired telephony networks and the Internet, for example.
  • FIG. 1 The system demonstrated above in FIG. 1 can be generalized for use in other cases.
  • one or more service provider sites such as, for example, social media sites or hosted email sites, could be used in place of the one or more banking institution sites.
  • one or more of the components of FIG. 1 are co-located with each other.
  • the one or more transaction sites are co-located with the one or more service provider sites and the one or more fraud reporting centers.
  • the one or more transaction sites are co-located with the one or more service provider sites.
  • the user devices are used to perform a variety of different functions.
  • the user devices are used to access a user's social media account such as a FacebookTM or TwitterTM account.
  • the user devices are used to access a user's webmail account.
  • the user devices have one or more mobile applications installed on them which enable the performance of these one or more different functions.
  • the user devices are used to perform financial transactions, such as online banking transactions, credit card and debit card, ATM, PoS (Point-of-Sale), eCommerce, and remote access transactions for example.
  • financial transactions such as online banking transactions, credit card and debit card, ATM, PoS (Point-of-Sale), eCommerce, and remote access transactions for example.
  • Such transactions are carried out by the servers at the transaction sites of FIG. 1. More generally, the transactions include transactions requiring security such as transactions for commerce and payments, for example.
  • a user device may be any device capable of network access. This device may be either wired or wireless.
  • the device may include a personal computer, tablet, mobile device, mobile phone, television, music player, personal organizer, or any similar electronic network enabled device.
  • the user device may be wearable technology including, but not limited to, jewelry (e.g., earrings, bracelets, bands, necklaces), piercings (e.g., subcutaneous or not, in essentially any part of the body), watches, glasses, hats, clothing (e.g., male and female underwear, pants, dresses, shirts, sweater, jacket), shoes, socks - essentially anything that is placed on or in a person can potentially include electronics and network enablement.
  • the user device may include an interface for accepting credit card payment or debit payments at a business for example.
  • a user using one of the user devices or wireless user devices may initiate a transaction, and the transaction is initiated through one of the fraud prevention systems. More particularly, context-dependent systems such as the fraud prevention and authentication systems detailed below make use of user specific information to determine the context of a user so as to authenticate a user. User specific information includes one or more identifiable characteristics of the user.
  • User specific information includes, but is not limited to, location of the user relative to the server (e.g., GPS on mobile devices may be utilized to extract location data), user behavioral analytics of mobile device (e.g., keystroke frequency, application tendency, call history), biometric analytics (e.g., voice verification, fingerprint verification, retina verification), device contextual checks, network intelligence (e.g., detection of call forwarding, phone type, post-paid/pre-paid, landline, VOIP, spoofing, SIM swaps, VPN, proxy), and information extracted from crowdsourced information (e.g., scouring social media feeds such as Foursquare® or Twitter® to search for locational information or general commentary, complaints, peer-to-peer interactions).
  • crowdsourced information e.g., scouring social media feeds such as Foursquare® or Twitter® to search for locational information or general commentary, complaints, peer-to-peer interactions.
  • Each of the previously mentioned characteristics may be used in any combination thereof to combine information in order to generate a higher probability of confirming the identity of the user at the point of transaction.
  • location based information may be used with behavioral monitoring to raise a flag that user has not been in a certain store for the last 12 months yet wishes to purchase from this specific location.
  • These characteristics are used at the authentication stage in a process utilizing dynamic weights assigned to each of the user specific characteristics to determine whether the sum weighted score meets the threshold required in order to achieve valid authentication and process the financial transaction.
  • a user's location may be extracted from user's mobile GPS, user's IP address, carrier API, cellular triangulations, social network data mining, CCTV surveillance, satellite monitoring, among other location based identifiers.
  • location analysis may be multi-faceted and implemented as follows: retrieving first location of transaction (e.g., merchant), retrieving second location of User's mobile, retrieving third location of user's tweet (via Twitter® API) based on time/age, retrieving forth location of user's Facebook® status update based on time/age, retrieving fifth location of user's Foursquare® checking based on time/age, retrieving sixth location of users on CCTV and other real-time public databases, retrieving other location sources from mining the web and social media sites.
  • location analysis may be multi-faceted and implemented as follows: retrieving first location of transaction (e.g., merchant), retrieving second location of User's mobile, retrieving third location of user's tweet (via Twitter® API) based on time/age, retrieving forth location of user's Facebook® status update based on time/age, retrieving fifth location of user's Foursquare® checking based on time/age, retrieving sixth location of users on CCTV and other real-time public databases, retrieving other location sources from mining the web and social media sites.
  • the user specific information used is the first location information of the user device provided by the user device and second location information of another user device provided by the location information server of a respective one of the communications service providers that provides communication capabilities to the user.
  • the other user device is the user's mobile phone or any other portable device carried by the user for example.
  • Authentication of the transaction relies on a correlation between the first and second location to validate the transaction.
  • transactions are carried out via the server at one at one of the transaction sites.
  • the user device is located at the transaction site as the case may be in an ATM or credit/debit card payment system.
  • the first and second devices can be the same device.
  • the means for payment and the mobile device may be one and the same.
  • a mobile device may be configured with credit card authorization. This may be accomplished by any means including "mobile wallet" technology where a mobile device has one or more payments means (including credit cards embedded) which is utilized with the first device location.
  • applications and operations performed using Near-Field Communication (NFC) may be considered as having the first device and second device in the same device.
  • the first device and second device may be considered mobile browser based commerce operated from the mobile device of the user.
  • SIM based credit may be used on a user's mobile device for commerce.
  • Peer-to-Peer transactions may be enabled over the user's device.
  • the first and second devices are different devices. As mentioned previously, this is where the authenticating device and the user device exist in two discrete devices, for example a merchant credit card module and a user's mobile phone, or a retina scanner and a user's eye.
  • the user may be referred to as an entity and therefore may refer to the customer or the merchant.
  • user specific information to determine user context such as location analysis can be used in various other applications as well. For example, if a user wishes to login to a social media website or a hosted webmail service using a first device, the location of a second device can be checked to see if there is a correlation between the location of the first device and the second device using the techniques outlined above. Similarly, other user specific information can also be checked. Authenti cation
  • the authentication stage is where all the user specific information is evaluated to determine whether further verification is required, or whether an operation can proceed to further processing.
  • the authentication stage is where all the user specific information is evaluated to determine whether further verification is required, or the transaction may proceed to processing.
  • the authentication stage may vary depending on application in terms of complexity and the number of factors taken into consideration.
  • Authentication may be provided such that the characteristics used for verification may be implemented at the authentication stage in order to produce a higher degree of security taking into account more information; or conversely, for simplicity, the additional characteristics may be left for verification if the initial characteristics do not meet the specified threshold.
  • location may be used as the sole initial characteristic required for authentication.
  • FIG. 2 shown is a flow chart of a method of authenticating a transaction in the fraud prevention system of FIG. 1.
  • the method is implemented by the authentication device at any one of the banking institution sites.
  • step 201 in response to receiving a request for authenticating a transaction involving a first device at a first location; and second information on the location of a second device associated with the transaction is obtained.
  • the request includes the first location information, and at step 202 a level of correlation between the first location and the second location is determined.
  • the location information includes an IP address, latitude and longitude coordinates or a postal or ZIP code, for example.
  • the transaction is authenticated based on the level of correlation between the first location and the second location.
  • the correlation must be within a defined threshold representative of the accurate distance of a mobile phone to a credit card. This threshold will vary depending on application.
  • step 205 If the authentication is valid at step 204, the authentication is continued at step 205 by requesting credentials from the user and processing the transaction downstream. If the user device is a mobile phone step 205 involves a call to the user device requesting user identification information and a PIN (Personal Identification Number), password, or unconstrained finger swipe for example. If the user device is a debit/credit card device at a merchant for example, the credential involve user and account information, together with an unconstrained finger swipe/PIN/password and allowing/blocking/flagging the transaction for example.
  • PIN Personal Identification Number
  • the request received at step 201 includes a phone number or a unique identifier of an entity corresponding to the user device or other device, such as a mobile phone or home phone for example, or an identifier of the user. If the authentication fails at step 204, in one embodiment, at step 206 a call between the call agent and the entity is established using the phone number or secure 2-way messaging. In some implementations, at step 206 the authentication device sends a call request to the call agent and the call agent sets up a call with the user device or other user device for further verification.
  • the verification can use rich push notifications, an automated phone, two-way SMS (Short Message Service) messaging, voice biometric requests, or mobile phone based ' Secure Elements', such as SIM (Subscriber Identity Module) cards, SD (Storage Device) cards, or chip based cards for example.
  • SMS Short Message Service
  • SD Storage Device
  • the second location includes information obtained from the location information server at a respective one of the communications service provider sites responsible for providing communications to the second device requesting the transaction.
  • user devices periodically registers their positions and/or changes therein with respective fraud prevention systems, and location information is obtained by retrieving relevant information from the databases at the fraud prevention systems.
  • the authentication involves having the authentication device send information to the user device confirming the authentication.
  • GPS on the user device may provide location based information constantly, or at a specified interval.
  • retina scanners implementing biometrics at a location may scan the user's physical eye to authenticate identity and associate a user with a location.
  • the user device is measured relative to other device in close proximity, whether the other device is the authentication device or a third party device interacting with the system.
  • the request received at step 201 includes one or more first more characteristics associated with the user device other than the second location information.
  • the flowchart shown in FIG. 2 is applicable in use cases other than financial transactions as well. For example, if a user wishes to authenticate himself/herself while logging into a social media website, steps 201 to 206 can also be performed.
  • Authentication may comprise the analysis of multiple characteristics to verify the identity of the individual and enable fraud detection.
  • Each of the characteristics has a dynamic weighting such, based on circumstance such that the weighting may change in the calculation with respect to pre-defined rules. Therefore, one characteristic may have a high weighting (e.g., location obtained from IP), however, if this characteristic is in disagreement with other characteristics which are analyzed, the threshold level required for passing valid authentication may not be allowed without further scrutiny in the verification stage.
  • these additional characteristics include the velocity of the user device, a characteristic of environment in which the user device is in, the gait of the user, the keying speed of keys being typed in the user device, biometrics, behavioral analytics, for example.
  • this could also include, for example, one or more kinetic motions typically performed in routine tasks involving the user device. For example, if the user device is, for example Google® Glass® then a relevant kinetic motion could be that of picking up a Google® Glass® device.
  • the data related to the performance of these kinetic motions is compared to a user profile for the user to be authenticated.
  • the user profile is built in the following way: For a specific user, the performance of the one or more kinetic motions for a specific user can be observed over, for example, a training period. A model of the performance of the one or more motions can be established beforehand, and the observed past performance of these motions during the training period for the specific user is used to adjust the model parameters for that user. In a further embodiment, one or more learning algorithms are used to adjust the model parameters.
  • the likelihood that the user performing these tasks is the specific user can be evaluated by comparison of input data related to performance of the one or more kinetic motions which form part of the routine tasks against the user profile.
  • An output comprising, for example, a score indicating the likelihood that the input data was produced by the specific user in question, is returned as a result of this evaluation. If this score is below a threshold because, for example, the performance of the one or more kinetic motions did not fall within certain bounds, then the authentication fails.
  • the one or more learning algorithms are used to learn how the user performs a task so as to distinguish between the user and an impostor.
  • the one or more learning algorithms comprise comparing the user's performance of the task with impostor or attacker attempts to imitate the user's performance of the task.
  • a plurality of attacker/impostor models, each having one or more corresponding characteristics, is created to enable the comparison. Examples of such attacker/impostor models have been developed in the context of email system authentication in Li, Yiru et al "Securing email archives through user modeling.” Computer Security Applications Conference, 21st Annual. IEEE, 2005; and Li, Yiru.
  • At least one of these models are then used to set thresholds, and make sure that said thresholds for a user are not so large as to allow malicious attacks.
  • at least one of the attacker models are based upon empirically-derived observations of the ability of one or more people other than the user to imitate the user's actions.
  • at least one of the models are based on one or more estimates of the capabilities of hypothetical impostors. These estimates can be obtained via, for example, simulations.
  • the one or more kinetic motions fall within the class of dynamic biometrics or behavioral biometrics, which are based upon invariants in an individual's behavior. Generally this behavior is consistent because of subconscious factors affecting how human bodies operate. Some behavioral biometrics are involuntary, such as, for example, heartbeats and brain activity. Others, such as the one or more kinetic motions described above, are voluntary. Dynamic biometrics differ from static biometrics which are based upon invariants in an individual's physical characteristics. Examples of static biometrics are, for example, fingerprints.
  • Behavioral biometrics have certain advantages over static biometrics. For example, using the one or more kinetic motions which are part of performing routine tasks has advantages. Firstly, since users tend to develop subconscious "muscle memory" to perform the one or more kinetic motions, a specific user is likely to perform the one or more kinetic motions consistently in a unique manner. Since the performance of the one or more kinetic motions has subconscious elements, this makes it difficult for an impostor to imitate the specific user.
  • biometrics such as making a user perform one or more kinetic motions for authentication is advantageous compared to, for example, using only biometric identifiers that persist when the user has either been killed or is seriously injured by an impostor.
  • Liveness detection such as checking for blinking in an image while doing facial recognition, are, in practice, insignificant barriers to determined attackers because these sensors can also be defeated using means known to those of skill in the art such as described in http://www.androidpolice.com/2012/08/03/android-jelly-beans-face-unlock- liveness-check-circumvented-with-simple-photo-editing/.
  • static biometrics can often be mimicked by impostors using relatively simple techniques known to those of skill in the art, for example, a picture of a person's face to fool a facial recognition sensor; or a latex finger to subvert a fingerprint scanner.
  • This mimicry is fundamentally hard to stop because the primary sensor used is, essentially, a camera, and there are many ways of fooling cameras, and there are many ways of obtaining a copy of the original person's biometric data, for example, gathering fingerprints left elsewhere on a device.
  • Examples of the one or more kinetic motions include picking up a user device, swiping on the screen of a smartphone, pulling a user device out of a user pocket, waving a smart card within the user device near a near field communications (NFC) reader, writing with a smart pen, lifting a smart watch to read the time, eye-tracking movements, eye- winking movements, jaw movement when a user speaks, and shaking a device.
  • NFC near field communications
  • the information obtained from the performance of the one or more kinetic motions are correlated with contextual information such as that obtained from non-kinetic sensors and other sources to provide more information to make accurate authentication decisions.
  • This contextual information could also include involuntary dynamic biometrics. For example, a user might perform a kinetic motion differently when they are tired compared to when they are fresh. So, instead of returning a negative result, one step might be to find out the time before making an authentication decision.
  • Other examples of contextual information include calendars of events, applications accessed, weather conditions based on environmental sensors on the device and location.
  • contextual information includes information obtained as a result of processing data obtained from other sensors. For example, based on velocity and acceleration readings from sensors on the device and a calendar of events, it is determined that the user is on a train, car, bus or plane. Then this information can be correlated with the one or more kinetic motions to make accurate authentication decisions. Other examples of such determinations include determining:
  • the position of the user that is, is the user sitting down, standing up or lying down? If the user is talking on their phone using a headset.
  • contextual information includes information obtained from processing involuntary dynamic biometric readings.
  • involuntary dynamic biometric readings include:
  • Heartbeats based on, for example, readings obtained from a heartbeat sensor on the device, or in a system such as that described in "Analysis of human electrocardiogram for biometric recognition" by Y. Wang, F. Agrafiooti, D. Hatzinakos, and K. N. Plataniotis in EURASIP journal on Advances in Signal Processing, 2008: 19, 2008.
  • one or more trust levels are set.
  • said trust levels are set based on one or more trust zones.
  • said setting of trust levels and trust zones are based on the characteristics including the contextual information specified above. For example, a user denotes the user's home as a high trust zone. Since high trust zones are assigned high trust level, a high trust level is assigned to the user's home. Based on one or more characteristics and obtained contextual information, for example, IP address of a Wi-Fi connection, whether the device is used to connect to trusted Bluetooth devices, and GPS readings, the device can detect that it is at the user's home and is therefore in a high trust zone.
  • the stringency of the requirements for authentication depend on the level of trust. For example, in a high trust zone, the device requires less stringent authentication compared to a low trust zone. Continuing the example above, if the user is at home and the device detects it is at the user's home which is a high-trust zone, then the user need only employ a less stringent form of authentication compared to a low-trust zone, for example, a cafe.
  • the assignment of trust levels is dependent on crowdsourced information.
  • users assign different trust levels to different zones based on their personal experiences.
  • each trust zone is assigned a trust level based on, for example, the mean trust level assigned to the trust zone.
  • the mean trust level is conditioned on one or more variables, including, for example, time of day, network used and user behavior.
  • An example based on conditioning on time of day is as follows: Based on the time that the device is present in the zone, different trust levels are assigned. As an example, a busy coffee shop may be a great venue for impostors who are looking to observe a user entering an identifier on a device and then steal the device. Thus if the device is in the coffee shop during a busy period, the device will have more stringent authentication requirements to guard against such attacks.
  • the anomalous performance is reported. In one embodiment, this is reported to, for example, a remote server. In another embodiment this is reported to, for example, the transaction authentication unit. Data associated with the anomalous performance such as the nature of the anomaly, time, and other information about the state of the device, such as the application that was running, and the device's location is stored.
  • these reported anomalies are then correlated with the other contextual information to determine an appropriate response.
  • the user has a specific policy to deal with these reported anomalies.
  • this policy includes one or more appropriate responses to the reporting of these anomalies. Examples of appropriate responses include sending an email, sending a push notification to another device, changing the security state of the device, which could include disabling certain applications or locking the device.
  • the device can only be unlocked by the server.
  • a respective second characteristic associated with the user device is obtained.
  • a respective level of correlation between the first characteristic and the respective second characteristic is determined.
  • the transaction is authenticated based on the respective level of correlation between each of the first characteristic and the respective second characteristic. More specifically, in some implementations the authentication fails if any one or more correlation is below a respective threshold value. However, it is to be clearly understood that other implementations are possible. For example, in some implementations the authentication fails if any N or more correlations are below respective threshold values, where N is an integer with N > 1.
  • the authentication fails if any M or more correlations are below respective threshold values, where M is an integer with M > 2, or if anyone or more of a subset of the correlations are below respective threshold values. It is contemplated that further subsequent characteristics may be implemented in the comparison analysis, and analysis is not limited to two characteristics.
  • a pre-set weighting is given to each characteristic in a database.
  • Said database is utilized for each authentication where unless a set of programmed weighted factors are assigned to each user specific characteristic are applied into the database. For example, if location by GPS specifies a certain address, however the location via IP specifies a different address, the location authentication may reduce in weighing as different sources are in disagreement. However if there is an additional verification for location using fingerprint scanning at a credit card terminal, this may be enough to outweigh the previous ambiguity of location based on IP and GPS. This set of exhaustive combinations is held within a data-base and the rules of such may be adjusted as required.
  • step 205 is not required for authentication for such transactions.
  • Multi-characteristic authentication is not just limited to financial transactions. Multi-characteristic authentication can be applied in any situation where authentication is required, such as, for example, logging into a user device, logging into one or more mobile apps installed within a user device, entering a social media website or entering a hosted webmail service.
  • the device can automatically switch profiles and, potentially, security and other configuration states. For example, if a child uses the device, the email and calendar applications are disabled, but enabled when the authorized parent picks up the device. By using the one or more kinetic motions, this enables user switching to occur automatically without any explicit input from the user.
  • FIG. 3A A block diagram of an example of the implementation of the authentication device of FIG. 1 is shown in FIG. 3A.
  • the authentication device has a communications interface and an authentication system having an authentication unit and a call activation authentication unit.
  • the communications interface provides the authentication device with the capability of communicating with other devices for purposes of receiving requests for authenticating transactions, obtaining location information from location information servers, confirming authentication, and requesting calls through a third party for verification; a call agent, for example.
  • the authentication unit obtains second location information defining a second location of another user device associated with the transaction.
  • the authentication unit also determines a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location.
  • the authentication unit makes a request to the call activation unit for a call to be established between the third party (e.g., call agent) and the first or second device so that failure of authentication can be reported and to resolve the problem, if possible.
  • the third party e.g., call
  • each of the communications interface and the authentication system and its authentication unit and call activation unit can be implemented using any suitable combination of software, hardware, and firmware.
  • FIG. 3B shown is block diagram of a user device of FIG. 1.
  • the user device has a number of features well suited for use in a wireless user device such as a mobile phone for example, and it is to be clearly understood that some of the features described below are optional.
  • the user device has a graphical user interface, a transaction authentication information unit or more generally, an operation authentication unit, a communication interface, a GPS (Global Positioning System) unit, an environment unit, a key login speed unit, a gyroscope, and an accelerometer.
  • the user device could also include other sensors, such as pressure sensors to detect force on the touch screen of a smartphone or tablet.
  • the communications interface allows the user device to communicate with other devices and servers in a network communications system.
  • the GPS unit provides position and velocity information for use in the authentication process.
  • the environment unit may provide information on environmental conditions such as temperature and wind speed and/or velocity, for example.
  • the key login speed unit monitors the speed at which login information is keyed in.
  • the transaction authentication unit communicates with the GPS unit to receive location and/or speed information on the user device.
  • the transaction authentication unit communicates with the environment unit to receive information on environmental conditions at the location of the user device.
  • the transaction authentication unit communicates with the key login speed unit to receive information on the speed of key logins in order to differentiate between manual and automated logins.
  • the transaction authentication unit communicates with the gyroscope and the accelerometer to receive information for determining gaiting of the user and acceleration of the user/device.
  • the transaction authentication unit also communicates with other sensors that are on the user device of FIG. 3B.
  • the transaction authentication unit also communicates with the graphical user interface to provide a GUI (Graphical User Interface) for displaying information relevant to the authentication process and for user input of information required for input by the user.
  • GUI Graphic User Interface
  • the authentication systems are implemented within the user device using, for example, the transaction authentication information unit of FIG. 3B or more generally the operation authentication unit, as previously explained.
  • the authentication systems are implemented using a cloud-based service.
  • An example of such an implementation is an app running on the user device together with one or more components of the user device, and one or more other components shown in FIG. 1, such as the fraud reporting center.
  • the transaction authentication unit or more generally the operation authentication client, forwards the information obtained from the sensors to the one or more other components shown in FIG. 1, such as the fraud reporting center.
  • the one or more other components shown in FIG. 1 are collectively known as the authentication server.
  • the authentication server takes as input the data from the transaction authentication unit and the specific user the transaction authentication unit is attempting to authenticate, and returns as output a score indicating the likelihood that the input data was produced by the specific user in question.
  • the authentication server communicates with an authentication engine.
  • the authentication engine is implemented within one of the one or more components of FIG. 1 or implemented in a distributed fashion over the one or more components of FIG. 1.
  • the user model or user profile is stored within, for example, a persistent storage system. Such a persistent store is located, for example, in a database such as that within the fraud reporting center of FIG. 1.
  • the authentication engine retrieves the user profile from storage, and uses this information to compute the likelihood that the user performing the tasks is the specific user.
  • the authentication engine is implemented within the user device.
  • the user profile is stored within the user device as well.
  • the accelerometer and gyroscope time series represent the motion of the phone in 3-dimensional space while the swipe is being performed across the screen.
  • This time series data is then used by the authentication engine to construct a set of features to be stored in the user profile in order to represent a swipe. Then, when the user performs a swipe in the future, the data from the swipe is used as an input, and compared by the authentication engine against the stored set of features in the user profile to compute a likelihood score.
  • the anomalous performance is reported to, for example, the authentication server.
  • Data associated with the anomalous performance such as the nature of the anomaly, time, and other information about the state of the device, say the application that was running and the device's location is stored in, for example, a database such as that located in the fraud reporting center of FIG. 1.
  • these reported anomalies are then correlated with the other contextual information to determine an appropriate response.
  • Such a correlation can be performed by, for example, the authentication engine.
  • implementation of one or more appropriate responses in line with a user specific policy to deal with these reported anomalies is performed by the authentication server. Examples of such appropriate responses have been discussed previously.
  • the implementation of such a multiple user authentication system as described previously is performed by the transaction authentication unit on the user device together with the authentication server. In another embodiment, the implementation of the multiple user authentication system is performed by transaction authentication unit on the user device.
  • each of the graphical user interface, the transaction authentication unit, the communications interface, the GPS unit, the environment unit and the key login speed unit can be implemented using any suitable combination of suitable software, hardware, and firmware.
  • the authentication device described in FIG. 3A and the user device described in FIG. 3B are applicable to a variety of use cases and not just limited to financial transactions.
  • the transaction authentication unit or more generally the operation authentication unit can be adapted for use in a variety of use cases, including, for example, logging into a social media website or hosted webmail service.
  • the functionality contained within the operation authentication unit is used to control access to the user device itself.
  • the operation authentication unit communicates with one or more mobile applications installed on the user device to control access to the user device itself.
  • the operation authentication unit is used to control access to the one or more mobile applications installed on the user device.
  • the multi-characteristic authentication described above is implemented in a multi-layered fashion.
  • An example is shown in FIG. 3C.
  • the multi-layered implementation can be used in a variety of use cases where authentication is required. This could include, for example, controlling access to the user device itself or controlling access to one or more mobile applications installed on the user device.
  • Layer 3C-01 is the telephony or more broadly the telecommunications layer.
  • This layer encompasses processing of the telephony aspects of the user-specific information associated with the user device of FIG. 1 for authentication.
  • the telephony aspects encompass, for example, telephony-based user specific information used to identify location, such as, for example, the characteristics of the telecommunications network serving the user device. This includes, for example, network topology and changes to network topology, such as, for example, changes in locations of cell towers.
  • such information is supplied by, for example, one or more of the communications service provider sites, and specifically by the one or more location information servers within the communications service provider sites, as previously explained.
  • the processing of the telecommunications- related information explained above to perform proximity correlation are also included within layer 3C-01.
  • VoIP Voice over IP
  • Layer 3C-02 is the social layer. This layer encompasses processing of the user-specific information related to the user's social interactions for authentication. In one embodiment, this information includes, for example, information related to social media interactions, such as interaction with social media websites such as Facebook®, Twitter®, Pinterest®, Foursquare® and Google Plus®. In one embodiment, this layer includes scouring of this information to obtain merchant store locations as well.
  • advanced data mining and analytics information used to identify suspicious merchants and suspicious transactions are also part of this social layer.
  • extraction of information from crowdsourced user knowledge obtained by, for example, scouring social media feeds such as Foursquare® or Twitter® to search for locational information or general commentary, complaints, peer-to- peer interactions are also part of this social layer.
  • Layer 3C-03 is the invisible layer. This comprises processing of user-specific information related to the user device for authentication.
  • the invisible layer is implemented in hardware.
  • a user device has one or more external authentication devices such as "smart" screen protectors; or smart screens with embedded invisible sensors, or other sensors attached to the device.
  • these one or more external authentication devices are coupled to one or more of the components of the user device as shown in FIG. 3B such as, for example, the graphical user interface, the transaction authentication unit, the communication interface, the GPS unit, the environment unit, the key login speed unit, the gyroscope and accelerometer.
  • add-on devices could be used to extract information, such as, for example, biometric information such as gait information, fingerprint information, gesture-based information such as touchscreen swipes and so on.
  • biometric information such as gait information
  • fingerprint information such as fingerprint information
  • gesture-based information such as touchscreen swipes and so on.
  • An example of such a smart screen with embedded sensors is provided in US Patent Application Publication No. 2013/0181949 to Setlak et al, filed January 17, 2013. Based on the information obtained by such sensors, user recognition can be performed.
  • the invisible layer is implemented in software.
  • the functionalities of the components of the user device of FIG. 3B have previously been explained, in particular the functioning of the transaction authentication unit/operation authentication unit.
  • one or more applications are installed on the device to work together with the components of the user device of FIG. 3B in order to assist the transaction authentication unit/operation authentication unit in performing identifications. These applications perform operations such as, for example, recording gestures made on the user interface.
  • An example of such an application is the Behavio Gesture Lock further detailed at https://plav.goorie om/store/apps/details?i
  • the invisible layer is implemented using a combination of hardware and software.
  • the invisible layer is implemented within the user device using, for example, the transaction authentication information unit of FIG. 3B or more generally the operation authentication unit, as previously explained.
  • the invisible layer is implemented as a cloud-based service by the user device in conjunction with one or more components of the system shown in FIG. 1, such as, for example, the fraud reporting center and the fraud prevention system.
  • Model stable observables Within the framework of anomaly detection, it is easier to learn normal behavior if the space of possible behaviors is small. In the context of smartphones this requirement is challenging as smartphone sensors may produce a deluge of data. Further, the output of these sensors can be highly variable: for example, they vary widely depending upon the task the user is performing: navigation while driving, a tilt- controlled game, or email. In machine learning, the "curse of dimensionality" says that as the complexity of data increases, the more data is required in order to learn a model. For implicit authentication quick learning of models of user behavior and quick detection of anomalies are important.
  • Effective implicit authentication systems will filter or process their data such that they detect anomalies in "stable observables" - characteristics of the data which remain invariant, unique and act predictably over time.
  • Known consistent phenomena which will generally produce consistent data for modeling purposes should be used.
  • task-based biometrics Another example of behavioral biometrics is task-based biometrics, where the performance of one or more tasks is observed and modeled for authentication purposes. As explained previously, such tasks would comprise one or more kinetic motions. As explained previously, task-based biometrics leverage the muscle memory users build up doing a common task. The more habitual the activity, the more likely it will be to characterize normal behavior, and consequently, the easier it will be to detect anomalies. This makes the task harder to imitate thus making it more resistant to mimicry attacks, thus meeting requirement (4). By having a learning or training phase which employs lightweight online learning algorithms, a task-based biometric system can meet requirement (1) above. By choosing an appropriate task, requirement (2) can be met, and the pitfalls of using continuous systems can be avoided.
  • a task-based multiple-level authentication process is implemented. This process comprises at least one main level and a backup level.
  • the at least one main level comprises one or more implicit authentication steps, while the backup level comprises one or more explicit authentication steps.
  • the implicit authentication steps comprise observing one or more user habits and/or behaviors to authenticate identity. This includes specific methods of performing one or more tasks such as standard user interactions which are necessary to move forward in a workflow. These tasks include, for example, gestures such as swiping, pinching, dragging, sliding a button on the interface of the user device, combinations of such gestures, and so on. These tasks have to be performed as part of the workflow, but the user may not necessarily realize that these tasks are used for authentication. Authentication is implicitly obtained by observing user performance of such tasks.
  • the tasks could also be routine tasks involving the device, where these tasks involve one or more gestures or more broadly, kinetic motions.
  • the task may involve picking up the device, or the gait of the user, the keying speed of keys being typed in the user device and behavioral analytics.
  • the one or more kinetic motions are correlated with contextual information such as that obtained from non-kinetic sensors and other sources to provide more information to make accurate authentication decisions. The results of these correlations are also used.
  • other examples of contextual information include information obtained as a result of processing data obtained from other sensors, and information obtained from processing biometric readings.
  • the tasks are performed on a special interface on, for example, a mobile device presented to the user.
  • An example of such an interface is shown in FIGs. 3CA and 3CB.
  • user device 3CA-01 displays full-size content screen 3CA-02.
  • Content screen 3CA-02 must be dismissed so that the user can move to the next content screen. To do so, the user must press or hold on content screen 3CA-02 and then move the content screen 3CA-02 off in any two-dimensional direction with a swipe or drag action.
  • FIG. 3CB content screen 3CA-02 is reduced and appears within a floating overlay, and background 3CB-01 is visible.
  • background 3CB-01 is a different color from content screen 3CA-02.
  • Content screen 3CA-02 is now an animated object which follows the motion of the user finger. In one embodiment, if the user stops holding the content screen 3CA-02 then it returns to its previous size. The user must then swipe reduced content window 3CA-02 off in any direction so as to reveal the next screen. In one embodiment, a partial swipe in any direction is enough to reveal the next screen
  • the tasks are chosen dependent upon the degree of constrainedness of such tasks. It is important that the tasks chosen for implicit authentication be:
  • the degree of constrainedness can be calculated for each task. Only those tasks where the degree of constrainedness falls within a certain range are used.
  • FIG. 3D shows one embodiment of a task-based multiple-level authentication process with one main level and a backup level.
  • the multiple-level authentication process comprises a setup phase 3D-01, where the user's habits are learnt.
  • the learning is implemented by, for example, prompting the user into performing the tasks which will be used in implicit authentication.
  • the layer records the performance of these tasks, and these records are then used to "seed" or build a user profile when the user needs to actually be authenticated.
  • one or more learning algorithms are used to learn how the user performs a task so as to be able to distinguish between the user and an impostor.
  • the one or more learning algorithms comprise comparing the user's performance of the task with impostor or attacker attempts to imitate the user's performance of the task.
  • a plurality of attacker/impostor models, each having one or more corresponding characteristics, is created to enable the comparison. Examples of such attacker/impostor models have been developed in the context of email system authentication in Li, Yiru et al "Securing email archives through user modeling.” Computer Security Applications Conference, 21st Annual. IEEE, 2005; and Li, Yiru.
  • At least one of these models are then used to set thresholds, and make sure that said thresholds for a user are not so large as to allow malicious attacks.
  • at least one of the attacker models are based upon empirically-derived observations of the ability of one or more people other than the user to imitate the user's actions.
  • at least one of the models are based on one or more estimates of the capabilities of hypothetical impostors. These estimates can be obtained via, for example, simulations.
  • Steps 3D-02 to step 3D-05 comprise the main level, which are performed every time the user needs to be authenticated.
  • steps 3D-03 and 3D-05 involve performing a first and second task, which in this case is a swipe gesture, to dismiss the screens presented in steps 3D-02 and step 3D-04.
  • a swipe gesture to dismiss the screens presented in steps 3D-02 and step 3D-04.
  • the information on the performance of these tasks are obtained using, for example, one or more of the hardware or software based techniques which are part of the invisible layer.
  • the information of the user's performance of these tasks are stored within steps 3D-03 and 3D-05.
  • step 3D-06 the stored user's performance information is compared against the stored user profile. If there is a correlation between the user profile and the performance of these steps, then authentication is complete in step 3D-12. If there is no correlation, then the backup level is entered in 3D-07.
  • Step 3D-07 comprises one or more explicit authentication steps, such as, for example, prompting the user to enter one or more explicit identifiers to authenticate the user, such as Personal Identification Numbers (PINs), passwords, credit card numbers, addresses, telephone numbers or email addresses.
  • PINs Personal Identification Numbers
  • step 3D-08 if there is successful explicit authentication, the stored information concerning the user's performance of steps 3D-03 and 3D-05 is used for further training and building of the stored user profile in step 3D-09, and authentication is complete in step 3D-12. If the explicit authentication is unsuccessful, then the stored information concerning the user's performance of steps 3D-03 and 3D-05 is discarded in 3D-10.
  • step 3D-11 verification may need to be performed. Examples of verification to be performed in step 3D- 10 are detailed in the section below titled "Authentication Fails - Verification Required.”
  • the process detailed in FIG. 3D is implemented within the user device by, for example, the transaction authentication information unit/operating authentication unit and one or more of the sensors shown in FIG. 3B; or by an app running on the user device together with the transaction authentication information unit/operating authentication unit and one or more of the sensors shown in FIG. 3B.
  • the process detailed in FIG. 3D is implemented as a cloud-based service using an app running on the user device together with one or more components of the user device, and one or more other components shown in FIG. 1, such as the fraud reporting center.
  • the one or more other components shown in FIG. 1 are collectively known as the authentication server.
  • the transaction authentication unit or more generally the operation authentication unit will communicate with other servers such as, for example, the fraud reporting unit of FIG. 1 to determine if, for example the user device has been stolen. If the device has been stolen, then in one embodiment the operation authentication unit moves sensitive data away from the user device, to a secure location such as, for example, a cloud-based storage system. Optionally, one or more apps running on the user device may be deleted.
  • the task-based multiple level authentication process is used to control access to one or more apps, then depending on the level of security required for each app, the requirements for implicit authentication are tightened or loosened. For example, if the app is a payment- or financial app, then naturally the security requirements are much higher, and the requirements for implicit authentication are made more difficult. This may include, for example, performing more tasks. For lower security apps, the requirements for implicit authentication may be made easier.
  • the invisible layer comprising implicit authentication, and explicit authentication are combined and incorporated into a typical authentication workflow.
  • FIG. 3E shows a series of steps for one embodiment of such a combined implicit- explicit authentication workflow.
  • the user enters a credit card number by, for example, using the touch screen.
  • the user performs a task which in this case is a swipe gesture to confirm the entry.
  • the user enters a billing address associated with the credit card.
  • the user performs a swipe gesture to confirm the billing address.
  • step 3E-05 and 3E-06 the user enters an email address and telephone number respectively.
  • step 3E-07 the user performs a swipe gesture to confirm entry of the information in steps 3E-05 and 3E-06.
  • Steps 3E-01, 3E-03, 3E-05 and 3E-06 are "explicit authentication” steps.
  • One or more of the remaining steps are designated as “implicit authentication” steps, wherein information provided by these one or more steps are used to authenticate the user.
  • designation of steps of a workflow as implicit authentication is dependent upon the degree of constrainedness of the task perfomed within such a step as explained before.
  • the degree of constrainedness can be calculated for each tasks within a workflow such as that of FIG. 3E. Then only those tasks where the degree of constrainedness falls within a certain range are designated as implicit authentication steps.
  • steps 3E-02, 3E-04 and 3E-07 comprise the user performing the task of making swipe gestures.
  • the information from one or more of these swipe gestures are obtained using, for example, one or more of the hardware or software based techniques which are part of the invisible layer.
  • the data obtained from performing task 3E-02 and 3E-07 are used to compute a score.
  • data obtained from performing only task 3E-04 is used for authentication purposes.
  • data obtained from tasks 3E-02, 3E-04 and 3E-07 are used.
  • the interaction-by-interaction selection is performed in a deterministic manner. For example, a sequence of combinations, such as 1-3-5-4-2-6-7 is used. Then, in the first interaction, only data from step 3E-02 corresponding to combination 1 is used for authentication. In the second interaction, only data from step 3E-07 corresponding to combination 3 is used for authentication. In the third interaction, data from steps 3E-02 and 3E-07 corresponding to combination 5 is used for authentication.
  • the interaction-by-interaction selection is performed pseudo-randomly. For example, based on the output of a random number generator, one of these combinations is chosen. For example, if combination 1 is chosen, then only data from performing step 3E-02 is used for authentication.
  • the data surrounding the user's performance of such tasks is obtained. Authentication is performed based on correlation of such historical data to the obtained data.
  • the data from each of the steps is weighted and used to compute a score. This computed score is then compared to historical scores to assist in authenticating the user.
  • the historical data obtained from performing one or more such implicit authentication steps are combined with the data obtained from the explicit authentication steps to determine an accurate profile of the user, that is, training is performed. For example, every time that the user successfully executes the workflow of FIG. 3E, the data from steps 3E-02, 3E-04 and 3E-07 is stored and used for future authentication.
  • the stringency of the requirements for authentication depend on the level of trust.
  • information from the telephony layer 3C-01 and social layer 3C-02 and other contextual information is used to determine the trust level corresponding to a trust zone.
  • trust can also be determined using crowdsourcing techniques.
  • the stringency of the requirements is inversely related to the level of trust. For example, referring to the workflow of FIG. 3E, in one embodiment, if the user is in a high trust zone, then less of the steps of FIG. 3E are used for authentication compared to the situation when a user is in a medium trust or low trust zone.
  • the interaction-by-interaction selection as described previously is performed using a weighted algorithm.
  • the weighting is inversely proportional to the number of steps in the combination. Therefore, a single step combination is more likely to be chosen than a 2-step combination, which in turn is more likely to be chosen than a 3-step combination.
  • the weighting is directly proportional to the number of steps in the combination. Therefore, a single step combination is less likely to be chosen than a 2-step combination, which in turn is less likely to be chosen than a 3 -step combination.
  • the information obtained from each layer of FIG. 3C is weighted differently in order to perform authentication.
  • FIG. 4A A further embodiment of valid authentication is demonstrated in FIG. 4A.
  • FIG. 4A shown is a messaging flow diagram for an example of authentication of a transaction in the network communications system of FIG. 1 for a case when authentication of a transaction is deemed valid.
  • a transaction between a transaction server and a server at a transaction site initiated by a user at a first user device is established.
  • User specific information utilizing various characteristics is analyzed.
  • one of the primary characteristics analyzed is location.
  • the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server.
  • the information includes, among other information, the first location information on the user device, together with a phone number of the user, for example.
  • the information includes additional characteristic information related to the first user device.
  • the transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N > 1.
  • the location information server of the communications service provider that provides communications services to the second user device provides a response containing the second location information.
  • the authentication device is provided with an identification of the communications service provider that provides communications services to the second user device and the query is sent only to one location information server.
  • the fraud prevention system includes a fraud prevention unit, a database, as well as authentication device, third party interface (e.g., call agent), and transaction server.
  • the authentication server Responsive to receiving the second location information, performs location authentication by determining a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location. For example, in one implementation the authentication is valid if the distance between the first and second locations is less than 50 km; otherwise, it fails.
  • a verification request is sent to the second user device in response to the location authentication requesting user credentials.
  • the user credentials include a PIN (Personal Identification Number), implicit information, or biometric information, for example.
  • Responsive to receiving the authentication request the user credentials are entered and a reply containing the user credentials is transmitted to the authentication device. The user credentials are authenticated and the authentication device transmits a message to the second user device indicating that the authentication has been verified.
  • the authentication is done locally on the first or second device and not transmitted; only the authentication success/failure information is transmitted.
  • the signaling process is similar to that of FIG. 4A up to the point where location authentication is performed.
  • the correlation between the first and second locations is not sufficiently high and results in a failed authentication during the location authentication step.
  • the fraud detection server within the fraud reporting unit of the fraud reporting center sends a response to the user device with information on the failed authentication.
  • the fraud detection server sends a response to the user device with information on the failed authentication.
  • verification may be implemented to verify the identity of the individual.
  • verification includes a person to person interaction to identify an individual.
  • verification includes utilizing one or more user based characteristics not initially used for authentication.
  • this example implements a person to person verification by means of a call agent.
  • the fraud detection server sends a request to a call agent for establishing a call between the call agent and the first user device.
  • the call agent picks up the call and sends a response to the fraud detection server indicating that the call has been picked up.
  • the fraud detection server also sends a request to the first user device for the call.
  • the first user device picks up the call.
  • the request contains information necessary for the first user device to establish the call with the call agent, communicates with the call agent, and the call is established.
  • a user at the first user device and the call agent can communicate with each other to perform authentication. In one embodiment, if either the task-based multiple-level authentication process of FIG. 3D or the process of FIG. 3E fails, then person to person verification by means of a call agent as explained above takes place.
  • multi-party third party verification may occur. For example, in a family setting, if the husband has the mobile device but the wife is using the credit card at a separate location, the third party agent may verify the authorization with both parties with consent of the cardholder. In one embodiment, if either the task-based multiple- level authentication process of FIG. 3D or the process of FIG. 3E fails, then similar multiparty third party verification occurs.
  • the user at the first user device may be required to provide additional authentication information so that the transaction can be allowed.
  • the additional authentication may include any of the user specific characteristics listed previously. Additionally, the information may include any one or more of the user's mother's maiden name, the user's birth date, and the name of the user's preferred pet, for example. If the user cannot provide the correct additional authentication information the transaction is refused. In one embodiment, if either the task-based multiple-level authentication process of FIG. 3D or the process of FIG. 3E fails, then the user is prompted to provide additional authentication information.
  • the request for a call is initiated by the fraud detection server by sending requests to both the call agent and the first user device.
  • the fraud detection server informs the call agent that a call is to be established between the call agent and the second user device, and the call agent initiates the call by sending a request to the second user device.
  • the task-based multiple-level authentication process of FIG. 3D or the process of FIG. 3E fails, then this process occurs.
  • the first user device at which a transaction is initiated may be a mobile phone, a personal computer, or a debit/credit card reader for example.
  • the call may be established with the user's user call device such as a mobile phone, home phone, VOIP phone, for example.
  • a transaction with the transaction server may be initiated by the user device through one or more servers.
  • a user may be at a PC (Personal Computer) and making a purchase and payment on the Internet.
  • the servers might be controlled by merchants for example or by entities that offer Internet payment services, such as PayPal® for example.
  • the transaction may be conducted between a server and the transaction server.
  • the user device communicates with the server and the server relays location information on the first user device to the transaction server.
  • a similar process occurs if either the task-based multiple-level authentication process of FIG. 3D or the process of FIG. 3E fails.
  • FIG. 4C shown is another messaging flow diagram for authentication of a transaction in the network communications system of FIG. 1 for a case when authentication of a transaction originally fails.
  • the messaging flow diagram of FIG. 4C is similar to that of FIG. 4B except that in this case upon a failed authentication, a call is established between a second user device and the call agent instead of between the first user device and the call agent.
  • a similar process occurs if either the task-based multiple-level authentication process of FIG. 3D or the process of FIG. 3E fails.
  • the second user device may be a bank's landline phone system, a lending instruction's VOIP service, or an investment firm agent's mobile phone.
  • the fraud detection server in response to the failed authentication the fraud detection server sends a response to the server with information on the failed authentication.
  • the fraud detection server also sends a request to the call agent for establishing a call between the call agent and the second user device.
  • the call agent picks up the call and sends a response to the fraud detection server indicating that the call has been picked up.
  • the fraud detection server also sends a request to the second user device for the call.
  • the second user device picks up the call.
  • the request contains information necessary for the second user device to establish the call with the call agent.
  • the second user device communicates with the call agent and the call is established.
  • the user at the second user device and the call agent can communicate with each other to perform authentication.
  • the user at the second user device may be required to provide additional authentication information so that the transaction can be allowed, as described above with reference to FIG. 4B.
  • the task-based multiple-level authentication process of FIG. 3D or the process of FIG. 3E fails, then a similar process occurs.
  • An additional embodiment to the invention includes the utilization of the one or more user specific characteristics to notify users of the system that certain merchants and/or specific goods or services may be suspect given previous transaction history. In this way, the system may implement a preventative fraud protection scheme. In some embodiments, the aggregation of user based transaction related data history is used as one of the specific characteristics.
  • An additional fraud prevention mechanism which uses a notification system can also be implemented by confirming transactions with client/user when they are underway. More particularly, the mechanism involves a method of verifying whether a transaction being conducted over a communications network is fraudulent. The transaction has associated with it transaction information and a user device for fraudulence verification.
  • the method involves comparing the transaction information with other information in a database to determine whether a transaction is potentially fraudulent.
  • a request is sent to a user device requesting user credentials and confirmation information on whether the transaction is fraudulent or not.
  • a determination of whether the user credentials allow access to the transaction is made and the transaction is authenticated using the confirmation information only if the user credentials allow access to the transaction.
  • the user may flag the transaction utilizing various degrees of concern.
  • the user may flag the current transaction as "concerned” which lets the transaction through but flags the transaction for a follow up check at a later time.
  • the user may flag the current transaction as "suspected fraud” where a third party (e.g., a call agent) is contacted to initiate further verification.
  • the user may flag the current transaction as "definitely fraud” where the transaction is blocked from proceeding and third party authorities are notified.
  • the notifications with respect to a specific merchant or vendor are stored in a database where each of the previous flags assigned per transaction at the merchant by users of the system are saved.
  • the database will send a summary of the previous transaction flagging history to the user currently processing a transaction such that the user may take this information into account prior to proceeding with the processing of the transaction.
  • the threshold for calculating the tolerance for suspicious activity changes with volume of transactions.
  • the threshold may be set manually by the system administrator or dynamically but process given input from various data inputs (e.g., transaction information).
  • FIG. 5 shown is a block diagram of another user device suitable for use with the fraud prevention system of FIG. 1.
  • the user device is similar to the user device of FIG. 3B except that it includes a fraud confirming unit.
  • the functionality of each of the graphical user interface, the transaction authentication unit or more generally the operation authentication unit as previously discussed, the communications interface, the GPS unit, the environment unit, the key login speed unit, the gyroscope, the accelerometer, and the fraud confirming unit can be implemented using any suitable combination of software, hardware, and firmware.
  • the transaction authentication unit or more generally the operation authentication unit communicates with the fraud confirming unit to collectively provide a mechanism for responding to requests for verification that has been recently carried out, and on-going transactions are indeed non-fraudulent transactions and for flagging fraudulent transactions.
  • FIG. 6A is a messaging flow diagram for authentication of a transaction in the network communications system of FIG. 1 in a push system for a case when verification of fraudulence of a transaction shows fraudulence.
  • a transaction is underway between a server at a transaction site and an authentication, and the authentication device sends a VERIFY message to a fraud reporting unit containing information regarding the transaction.
  • the fraud reporting unit may be located at a fraud reporting center that contains a database, such as the fraud reporting centers of FIG. 1.
  • the information contained in the VERIFY message includes information suitable for identifying a fraudulent user, such as a fraudulent merchant for example.
  • the information may include but is not limited to any one or more of the location of the user device requesting the transaction, identification of the user device, identification of the user of the user device, the number of transactions of a particular merchant, user, or other entity, which have been identified as fraudulent and/or the number of transactions of a particular merchant, user, or other entity, which have been identified as potentially fraudulent, and any user specific information.
  • the fraud reporting unit verifies its database to determine whether the received information matches any entry in the database that would confirm that the transaction is potentially fraudulent.
  • the database might contain an entry for a particular merchant called "BadBuy" for example, with the entry indicating five fraudulent transactions in the last three days. As such, in some implementations any transaction from this merchant would be identified a potentially fraudulent.
  • the fraud reporting unit replies to the authentication device with a REPLY message indicating whether the transaction is potentially fraudulent or not.
  • the authentication device verifies whether the message indicates a potentially fraudulent transaction or not, and in this case the transaction is potentially fraudulent.
  • the authentication device sends a VERIFICATION message to the user device indicating that a potentially fraudulent transaction is underway and requesting user credentials and confirmation of whether the transaction is indeed fraudulent or not.
  • the user provides input of the credentials and in this case the user confirms that the transaction is indeed fraudulent by sending a REPLY message to the authentication device.
  • the REPLY message contains information confirming that the transaction is fraudulent together with the user credentials.
  • the authentication device verifies that the user credentials are correct and determines that the transaction is fraudulent based on the information contained in the REPLY message.
  • the authentication device then sends a notification message to a call agent containing information related to the transaction.
  • the information includes any one or more of the location of the user device requesting the transaction, identification of the user device, identification of the user of the user device, and any user, merchant, or other entity's or transaction specific information.
  • the call agent looks up which fraud reporting units are to be notified and relays the received NOTIFICATION message to the fraud reporting units.
  • this may lead to a block being applied on the user's card or transactions so that further transactions are not allowed, until the issue is resolved.
  • the fraud reporting units Responsive to receiving the NOTIFICATION messages, the fraud reporting units update their respective databases with the information contained in the NOTIFICATION messages. The fraud reporting unit that receives the VERIFY message also looks up its database to identify other user devices that should be notified for potentially fraudulent transactions.
  • the fraud detection unit may look through transactions in its database which have occurred in the last sixty days together with on-going transactions and identify transactions from a particular user device.
  • the fraud detection unit may look in its database for transactions which have occurred in the last sixty days, together with on-going transactions, and identify potentially fraudulent transactions involving a specific amount from a particular merchant.
  • the fraud reporting unit then sends a NOTIFICATION REQUEST containing call information for calling other user devices associated with the identified potentially fraudulent transactions, together with information on the potentially fraudulent transactions. Responsive to receiving the NOTIFICATION REQUEST, the call agent sends NOTIFCATION to the other user call devices.
  • the notification may be in any format for which can be received on a user device.
  • the notification is in the form of a rich push notifications including, but not limited to, an email, an SMS, instant message, VOIP call, or a phone call, and other medium of electronic messaging.
  • each notification includes information for identifying a respective transaction and allowing the user to determine whether the transaction is indeed fraudulent.
  • the fraud detection unit monitors various aspects of the transaction and takes into circumstances into the weighted decision. Analysis includes clustering merchants and transactions by their characteristics (e.g., location, type of business, ownership, item purchased) and comparing those clusters with clusters of individuals making the purchase (e.g., gender, age, purchase history, known interests). These multidimensional cluster comparisons are performed to estimate the a-priori probability of a given transaction.
  • Further characteristics may be populated for the fraud detection unit including mining for online consumer complaints on transactions and merchants, mining location and update time information from web posts and social media sites, and analyzing mobile user flagged transactions. This type of information is analyzed and adapted to the database to provide better analysis and notifications without involving third parties and direct user interaction requiring responses.
  • the database also takes into consideration authentication history. This includes the number of failed authentications for a particular device.
  • the device may be for a merchant or a customer.
  • the authentication success rate may be utilized as an indicator of whether a particular device is suspicious of illegitimate conduct based on the number of failed authentication attempts and secondly how contemporaneously the failed authentication occurred.
  • FIG. 7 An example of the system implementation can be seen in FIG. 7.
  • the user authenticates with the system implicitly (701) using for example, the multi-characteristic authentication system demonstrated above or the multi-layered authentication system described previously, at which point the fraud detection unit retrieves any relevant and related user specific information related to the specific merchant. Said information may be flagged within the system, or as mentioned previously, information may include consumer complaints in forums and social media sites(702), for example.
  • This information is analyzed to verify whether the information in aggregate meets a pre-determined threshold to alter behavior or require a notification to be sent to the user before the transaction, at the point of sale (703), or post-transaction.
  • the transaction is flagged (704) and a third party may be involved for further verification (705).
  • Said system provides a fraud detection system and fraud resolution management (post transaction) for consumers (706) or users of the system.
  • the characteristics analyzed will be with respect to coffee shops or other merchants with coffee shop like characteristics. Therefore the analytics by the fraud detection unit are targeted to the specific transaction and allow for a more accurate notification given to the user.
  • the user must enter the proper credentials before confirmation of whether a transaction is fraudulent is accepted.
  • the confirmation is accepted without the need for credentials.
  • FIG. 6B shown is a messaging flow diagram for authentication of a transaction in the network communications system of FIG. 1 in a push system for a case when verification of fraudulence of a transaction shows no fraudulence.
  • a transaction is underway between a server at a transaction site and an authentication device.
  • the authentication device sends a VERIFY message to a fraud reporting unit containing information regarding the transaction.
  • the information contained in the VERIFY message includes information suitable for identifying a fraudulent user.
  • the fraud reporting unit verifies its database to determine whether the received information matches any entry in the database that would confirm that the transaction is potentially fraudulent.
  • the fraud reporting unit replies to the authentication device with a REPLY message indicating whether the transaction is potentially fraudulent or not.
  • the authentication device verifies whether the message indicates a potentially fraudulent transaction or not, and in this case the transaction is not fraudulent.
  • the authentication device sends a VERIFICATION message to a user device associated with the transaction indicating that a transaction is underway and that the transaction does not appear to be fraudulent. Nonetheless, the VERIFICATION message is used for requesting user credentials and confirmation of whether the transaction is indeed fraudulent or not.
  • the user provides input of the credentials and in this case the user confirms that the transaction is not fraudulent by sending a REPLY message to the authentication device.
  • the REPLY message contains information confirming that the transaction is not fraudulent together with the user credentials.
  • the authentication device verifies that the user credentials are correct and determines that the transaction is not fraudulent based on the information contained in the REPLY message. During verification the authentication unit determines that the transaction is not fraudulent and the transaction process continues.
  • the transaction in some instances the transaction is being performed in real-time and the transaction cannot continue unless the user confirms that the transaction is not fraudulent. In other instances, the transaction is being initiated by a third party such as a merchant entering credit card information for a related purchase for example, and the transaction is put on hold until the user has had a chance to confirm whether the transaction is fraudulent or not. In some implementations, when a transaction has been identified as having no potential threat of fraudulence by the fraud reporting unit the transaction continues without any further verification with the user at the user device.
  • FIG. 6A and FIG. 6B in some implementations if the user credentials are incorrect, the user is asked to re-enter the credentials until the correct credentials are entered or until a maximum number of attempts is reached. When the maximum number of attempts is reached the authentication device contacts a third party to establish a call with the user's user call device.
  • the third party may be any third party required to verify the identity of the user conducting the transaction.
  • the third party is a call agent.
  • the third party may be any party required from merchants, banks, consumers, and others in the ecosystem required to identify the user.
  • the messaging between the user device and the authentication device can be implemented using any suitable protocol. This may include mobile platform such as those used in Apple® iOS, Google® Android, BlackBerry®, Microsoft Windows Phone 8®, and other smartphones.
  • the fraud confirming unit, the transaction authentication information unit, and the graphical user interface can be can be used to present the user with a request for confirmation of whether a transaction is fraudulent by presenting the user with an interface for entering the credentials and also with selectable buttons for confirming whether or not the transaction is fraudulent.
  • a number of mechanisms used for performing authentication have been described. In some embodiments, these mechanisms are used together to provide secure transactions. For example, in some embodiments, a transaction associated with a user is initiated at a server at a transaction site.
  • a first authentication step is conducted based on a correlation between the location of the server and the location of a user device associated with the user. If the authentication succeeds then there is no need for verification with the user through the user device. However, if the authentication fails then verification is made via a push notification, a phone call, or 2-way SMS, for example, requesting user input at the user device.
  • authentication is also made using other characteristics such as speed, acceleration, and key login in speed for example.
  • communications are made with a detection unit so that it can retrieve information from the database to identify whether the transaction is potentially fraudulent.
  • a verification message is sent to a user device associated with the user, where the user is prompted to enter user credentials and validate the transaction, reject/decline the transaction, and/or flag the transaction as fraudulent or non-fraudulent. If the transaction is flagged fraudulent, an entry is made into the database of the appropriate fraud prevention system. As mentioned previously, in some embodiments, this flagged information is verified by analyzing social media analytics such as web forums, posts, social media sites, and other private/public databases to determine reliability.
  • the database in the fraud prevention system is used to look at historical transactions of all users to check for potential fraud, and then appropriate users are notified/alerted of potential fraudulent transactions on their account, via rich push notifications, email, phone, or SMS for example.
  • FIG. 8 An example of the implementation of the fraud detection system and resolution management system can be seen in FIG. 8.
  • a third party payment gateway is integrated with the system to enable credit processing.
  • the payment gateway may be part of the fraud verification and resolution management system.
  • the user logins in (1) to the system (payment gateway) using a mobile device as their device (la) and registers with the system server (Fraud Detection Unit).
  • the user sets their preferences regarding notifications and financial security with the system server (2).
  • a notification is sent to the Fraud Detection Unit utilizing an application programming interface (4).
  • the flag is stored on the payment gateway database (4a) prior to the flag being pushed to the fraud detection unit (4b).
  • the fraud detection unit receiving the flag from the payment gateway, pushes the flag to the user via rich push notifications (5).
  • the user device receives the notification (6) and the transaction information is downloaded or viewed on the user device (7).
  • the user may input a secondary password to authenticate (8), and the corresponding user selected action (e.g., allow/prevent/flag) is pushed to the fraud detection unit.
  • This response is sent from the Fraud Detection Unit to the payment gateway (10a) and recorded in the database within the payment gateway (10b).
  • a rich push notification may be sent to a user device after checking database information for various transaction information related to one or more devices.
  • Rich push notifications include, but not limited to, an email, an SMS, instant message, VOIP call, or a phone call (automated or conventional), and other medium of electronic messaging.
  • these alerts may be used to alert a first user device of a suspicious second user device when a first user device enters the proximity of the second user device. This may include a customer walking into a merchant's store where the customer receives an instant message on their mobile device informing the customer that the current merchant store has a transaction history including a high rate of invalid authentication.
  • a merchant may be alerted of a potential customer having a high level of invalid authentication with respect to a specific credit card.
  • the alert is proximity based by a pre-determined threshold when the first user device meets the threshold relative to a second user device.
  • the alert is given once the transaction history in the database reaches a pre-determined threshold. For example, if the number of invalid authentications for a merchant device totals 10 per month, an alert is sent to a number of user devices on the system which frequently conduct transactions at the company, utilizing the merchant device.
  • Any algorithm, software, or method disclosed herein can be embodied in software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well-known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.).
  • ASIC application specific integrated circuit
  • PLD programmable logic device
  • FPLD field programmable logic device
  • machine-readable instructions represented in any flowchart depicted herein can be implemented manually as opposed to automatically by a controller, processor, or similar computing device or machine.
  • specific algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé d'authentification d'un utilisateur à l'aide d'un dispositif d'utilisateur connecté à un réseau de communication, le procédé comprenant une phase implicite, ladite phase implicite consistant à réaliser au moins une tâche dans un flux de travaux, ladite ou lesdites tâches étant nécessaires pour avancer dans ledit flux de travaux ; à stocker des informations associées à ladite réalisation d'au moins une tâche ; à comparer lesdites informations stockées à un profil d'utilisateur stocké ; et à déterminer si ladite authentification dudit utilisateur est réussie ou non réussie sur la base de ladite comparaison.
PCT/IB2014/063959 2013-08-26 2014-08-18 Système, procédé et dispositif d'authentification dépendant du contexte WO2015028916A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201361869972P 2013-08-26 2013-08-26
US61/869,972 2013-08-26
US201461978635P 2014-04-11 2014-04-11
US61/978,635 2014-04-11
US14/337,939 2014-07-22
US14/337,939 US9619852B2 (en) 2012-04-17 2014-07-22 Context-dependent authentication system, method and device

Publications (1)

Publication Number Publication Date
WO2015028916A1 true WO2015028916A1 (fr) 2015-03-05

Family

ID=52585666

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2014/063959 WO2015028916A1 (fr) 2013-08-26 2014-08-18 Système, procédé et dispositif d'authentification dépendant du contexte

Country Status (1)

Country Link
WO (1) WO2015028916A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017040867A1 (fr) * 2015-09-01 2017-03-09 Quantum Interface, Llc. Appareils, systèmes et procédés pour construire des identifiants uniques
WO2017153859A1 (fr) * 2016-03-07 2017-09-14 International Business Machines Corporation Blocage de transactions frauduleuses dans un dispositif nfc
US9858403B2 (en) 2016-02-02 2018-01-02 Qualcomm Incorporated Liveness determination based on sensor signals
US10740751B1 (en) * 2016-12-20 2020-08-11 Wells Fargo Bank, N.A. Secure transactions in social media channels
US10740758B2 (en) 2012-04-17 2020-08-11 Zighra Inc. Context-dependent authentication system, method and device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5544321A (en) * 1993-12-03 1996-08-06 Xerox Corporation System for granting ownership of device by user based on requested level of ownership, present state of the device, and the context of the device
US20100100439A1 (en) * 2008-06-12 2010-04-22 Dawn Jutla Multi-platform system apparatus for interoperable, multimedia-accessible and convertible structured and unstructured wikis, wiki user networks, and other user-generated content repositories
US20100248706A1 (en) * 2009-03-31 2010-09-30 Miodrag Potkonjak Autonomous, non-interactive, context-based services for cellular phone
US20130104187A1 (en) * 2011-10-18 2013-04-25 Klaus Helmut Weidner Context-dependent authentication
US20130275355A1 (en) * 2008-06-12 2013-10-17 Tom Miltonberger Fraud detection and analysis

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5544321A (en) * 1993-12-03 1996-08-06 Xerox Corporation System for granting ownership of device by user based on requested level of ownership, present state of the device, and the context of the device
US20100100439A1 (en) * 2008-06-12 2010-04-22 Dawn Jutla Multi-platform system apparatus for interoperable, multimedia-accessible and convertible structured and unstructured wikis, wiki user networks, and other user-generated content repositories
US20130275355A1 (en) * 2008-06-12 2013-10-17 Tom Miltonberger Fraud detection and analysis
US20100248706A1 (en) * 2009-03-31 2010-09-30 Miodrag Potkonjak Autonomous, non-interactive, context-based services for cellular phone
US20130104187A1 (en) * 2011-10-18 2013-04-25 Klaus Helmut Weidner Context-dependent authentication

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10740758B2 (en) 2012-04-17 2020-08-11 Zighra Inc. Context-dependent authentication system, method and device
WO2017040867A1 (fr) * 2015-09-01 2017-03-09 Quantum Interface, Llc. Appareils, systèmes et procédés pour construire des identifiants uniques
US10263967B2 (en) 2015-09-01 2019-04-16 Quantum Interface, Llc Apparatuses, systems and methods for constructing unique identifiers
US9858403B2 (en) 2016-02-02 2018-01-02 Qualcomm Incorporated Liveness determination based on sensor signals
WO2017153859A1 (fr) * 2016-03-07 2017-09-14 International Business Machines Corporation Blocage de transactions frauduleuses dans un dispositif nfc
US11080706B2 (en) 2016-03-07 2021-08-03 International Business Machines Corporation Blocking fraudulent transactions in an NFC device
US10740751B1 (en) * 2016-12-20 2020-08-11 Wells Fargo Bank, N.A. Secure transactions in social media channels
US11610198B1 (en) 2016-12-20 2023-03-21 Wells Fargo Bank, N.A. Secure transactions in social media channels

Similar Documents

Publication Publication Date Title
US11699155B2 (en) Context-dependent authentication system, method and device
US20230410116A1 (en) Context-dependent authentication system, method and device
US11847653B2 (en) Fraud detection system, method, and device
US11947651B2 (en) Biometric identification platform
US10896248B2 (en) Systems and methods for authenticating user identity based on user defined image data
US10395018B2 (en) System, method, and device of detecting identity of a user and authenticating a user
KR102577208B1 (ko) 스피치 및/또는 입술 움직임 분석을 포함하는 인증 기술
US10440019B2 (en) Method, computer program, and system for identifying multiple users based on their behavior
US20180082304A1 (en) System for user identification and authentication
US11171951B2 (en) Device interface output based on biometric input orientation and captured proximate data
KR20180016235A (ko) 스피치 및/또는 입술 움직임 분석을 포함하는 인증 기술
US20190052661A1 (en) Systems and methods for preventing fraud
US12056975B1 (en) System and method for secure pair and unpair processing using a dynamic level of assurance (LOA) score
WO2015028916A1 (fr) Système, procédé et dispositif d'authentification dépendant du contexte
CA2910929C (fr) Systemes et methodes d'authentification de l'identite utilisateur fondee sur des donnees images definies par l'utilisateur
Al Abdulwahid Federated authentication using the cloud (Cloud Aura)
Bhateja et al. A comparative study of multimodal biometric authentication system: a review
Kroeger et al. Laws of Authentication.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14839092

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14839092

Country of ref document: EP

Kind code of ref document: A1