U.S. patent application number 17/149634 was filed with the patent office on 2021-07-15 for fraud detection system, method, and device.
The applicant listed for this patent is Zighra Inc.. Invention is credited to Deepak Chandra Dutt.
Application Number | 20210217020 17/149634 |
Document ID | / |
Family ID | 1000005480234 |
Filed Date | 2021-07-15 |
United States Patent
Application |
20210217020 |
Kind Code |
A1 |
Dutt; Deepak Chandra |
July 15, 2021 |
FRAUD DETECTION SYSTEM, METHOD, AND DEVICE
Abstract
The present invention provides a method of authenticating a
transaction, the method having: responsive to receiving a request
for authenticating a transaction involving a first device and
including first device information defining at least one first
device characteristic of the first device, obtaining second device
information defining at least one second device characteristic of a
second device associated with the transaction; determining a level
of correlation between the first device information and the second
device information; and authenticating the transaction based on the
level of correlation between the first device information and the
second device information, wherein the transaction is authenticated
when the level of correlation between the first device information
and the second device information is above a pre-determined
threshold.
Inventors: |
Dutt; Deepak Chandra;
(Ottawa, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Zighra Inc. |
Ottowa |
|
CA |
|
|
Family ID: |
1000005480234 |
Appl. No.: |
17/149634 |
Filed: |
January 14, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14394574 |
Oct 15, 2014 |
|
|
|
PCT/CA2013/050295 |
Apr 17, 2013 |
|
|
|
17149634 |
|
|
|
|
61625112 |
Apr 17, 2012 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/40145 20130101;
H04L 63/1408 20130101; G06Q 50/265 20130101; H04L 63/0861 20130101;
H04W 12/68 20210101; G06Q 20/4016 20130101; H04L 63/08 20130101;
H04W 12/06 20130101; G06Q 20/202 20130101; G06Q 20/322 20130101;
G06F 2221/2105 20130101; H04W 12/126 20210101; G06Q 20/327
20130101; G06F 21/31 20130101; H04W 12/065 20210101; G06Q 10/00
20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; H04L 29/06 20060101 H04L029/06; H04W 12/06 20060101
H04W012/06; G06Q 10/00 20060101 G06Q010/00; G06Q 20/20 20060101
G06Q020/20; G06Q 20/32 20060101 G06Q020/32; G06Q 50/26 20060101
G06Q050/26; H04W 12/065 20060101 H04W012/065; H04W 12/126 20060101
H04W012/126 |
Claims
1. A method for operating a user computing device, the method
comprising: communicating with one or more components of the user
computing device; determining, by communicating with the one or
more components of the user computing device, multiple identifiable
characteristics of the user, the multiple identifiable
characteristics including a location of the user computing device,
and a biometric data set obtained on the user computing device;
maintaining a database of values that are based on the identifiable
characteristics; and responding to a user of the user computing
device initiating a transaction by (i) making an authentication
determination based at least in part on the values of the database,
and (ii) communicating the authentication determination to a
computing device of another entity for authorization of the
transaction.
2. The method of claim 1, wherein maintaining the database of
values includes applying a weighting to each of the multiple
identifiable characteristics.
3. The method of claim 2, wherein applying the weighting includes
dynamically applying the weighting based on a predetermined set of
rules.
4. The method of claim 2, wherein the weighting is dynamically
applied based on a circumstance of the transaction.
5. The method of claim 1, wherein maintaining the database of
values includes combining values of two or more identifiable
characteristics.
6. The method of claim 1, wherein the authentication determination
includes a score.
7. The method of claim 6, wherein making the authentication
determination includes making a determination that the score meets
a threshold.
8. The method of claim 1, wherein the authentication determination
includes a weighted sum score.
9. The method of claim 1, wherein the authentication determination
includes authentication success/failure information.
10. The method of claim 1, wherein the one or more components of
the user computing device include a Global Positioning System (GPS)
component of the user computing device.
11. The method of claim 10, wherein determining the multiple
identifiable characteristics includes determining a velocity of the
user computing device based on the GPS component.
12. The method of claim 11, wherein the one or more components of
the user computing device include at least one of a gyroscope or
accelerometer, and wherein the multiple identifiable
characteristics include behavioral monitoring information of the
user computing device.
13. The method of claim 12, wherein determining the multiple
identifiable characteristics includes determining a gait of the
user using an output of the gyroscope or accelerometer of the user
computing device.
14. The method of claim 1, wherein the one or more components of
the user computing device include an environmental unit, and
wherein determining the multiple identifiable characteristics
includes determining a characteristic environment of the user using
the environmental unit.
15. The method of claim 14, wherein the environmental unit
determines at least one of a temperature or windspeed of the
characteristic environment.
16. The method of claim 1, wherein the one or more components of
the user computing device include a graphical user interface
(GUI).
17. The method of claim 16, wherein determining the multiple
identifiable characteristics includes determining a keying speed or
keystroke frequency of the user.
18. The method of claim 16, wherein determining the multiple
identifiable characteristics includes determining an application
tendency of the user in operating the user computing device.
19. The method of claim 1, wherein the user computing device is a
mobile computing device, and wherein determining the multiple
identifiable characteristics includes determining a call history of
the user computing device.
20. The method of claim 1, wherein the biometric data set includes
a data set that verifies at least one of a voice, fingerprint or
retina of the user.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 14/394,574, filed Oct. 15, 2014, which is a
U.S. National Stage Entry of PCT/CA2013/050295, filed Apr. 17,
2013, which claims the benefit of U.S. Provisional Application No.
61/625,112, all of which priority applications are hereby
incorporated by reference in their respective entireties.
FIELD OF THE INVENTION
[0002] The present disclosure relates to a system, method and
device for fraud detection in transactions over communications
networks.
BACKGROUND
[0003] Credit card fraud costs banks time, money and has become an
increased problem with cyber-crime, phishing schemes, and other
programs designed to take advantage of fraudulent credit cards or
means for payment.
[0004] Additionally, due to the scale of card fraud, issuing banks
tend to implement quite aggressive strategies in order to combat
the problem. This, however, leads to high false positive rates that
cause extreme inconveniences to cardholders and merchants resulting
in high operational costs (including resolution management) to the
issuer. As an additional consequence, high volumes of false
positives may also prevent the issuer from declining further
transactions, leading to additional losses.
[0005] Existing risk-engine strategies do not have the benefit of
information on user generated information (including online
complaints regarding merchants, hidden charges, billing errors) and
the real-time status of the cardholder, they are not well suited to
cross-border transactions where behavioral and historical patterns
do not fit the norm.
[0006] Moreover, without verification in real time at the point of
sale between the various players in the ecosystem (e.g., banks,
card companies, merchants, consumers), real-time fraud
detection/prevention has been challenging, to enable
effectively.
[0007] Therefore, there is a need for a new solution whereby all
parties to the financial ecosystem may benefit from user generated
information and real time verification.
[0008] This background information is provided to reveal
information believed by the applicant to be of possible relevance
to the present invention. No admission is necessarily intended, nor
should be construed, that any of the preceding information
constitutes prior art against the present invention.
SUMMARY OF THE INVENTION
[0009] An object of the present invention is to provide a fraud
detection system, method, and device. In accordance with an aspect
of the present invention, there is provided a method of
authenticating a transaction, the method having: responsive to
receiving a request for authenticating a transaction involving a
first device and including first device information defining at
least one first device characteristic of the first device,
obtaining second device information defining at least one second
device characteristic of a second device associated with the
transaction; determining a level of correlation between the first
device information and the second device information; and
authenticating the transaction based on the level of correlation
between the first device information and the second device
information, wherein the transaction is authenticated when the
level of correlation between the first device information and the
second device information is above a pre-determined threshold.
[0010] In accordance with another aspect of the present invention,
there is provided an authentication device having: a communications
interface for receiving requests for authenticating transactions
involving a first device, each request comprising a first device
and including first device information defining at least one first
device characteristic of the first device, and obtaining second
device information defining at least one second device
characteristic of a second device associated with the transaction;
an authentication system having a first authentication unit for,
for each request: means for obtaining second device information
defining at least one second device characteristic of a second
device; means for determining a level of correlation between the
first device information and the second device information; and,
means for authenticating the transaction based on the level of
correlation between the first device information and the second
device information, wherein the transaction is authenticated when
the level of correlation between the first device information and
the second device information is above a pre-determined
threshold.
[0011] In accordance with yet another aspect of the present
invention, there is provided a method of fraudulence verification
of a transaction being conducted over a communications network, the
transaction having associated transaction information, the method
having: comparing the transaction information with database
information stored in a database to determine whether a transaction
is potentially fraudulent; sending a request to a second device
associated with the transaction requesting confirmation information
on whether the transaction is fraudulent; and, responsive to
receiving a response with the confirmation information,
authenticating the transaction using the confirmation
information.
[0012] In accordance with yet another aspect of the present
invention, there is provided a method of providing an alert having:
checking database information stored in a database relating to one
of an entity associated with a first device and an entity
associated with a second device; and, sending an alert notice to
the other of an entity associated with a first device and entity
associated with a second device relating to the database
information.
BRIEF DESCRIPTION OF THE FIGURES
[0013] FIG. 1 illustrates a network communications system in which
implemented is a fraud prevention system for transactions, in
accordance with an embodiment;
[0014] FIG. 2 is flow chart of one example of a method of
authenticating a transaction in the fraud prevention system based
on location criteria;
[0015] FIG. 3A is a block diagram of an example of one variety of
an authentication device;
[0016] FIG. 3B is block diagram of an example of one variety of a
user device;
[0017] 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;
[0018] 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;
[0019] 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;
[0020] FIG. 5 is a block diagram of an example of user device
suitable for use with the fraud prevention system;
[0021] 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;
[0022] 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;
[0023] FIG. 7 represents a flow diagram of one implementation of
the fraud detection unit method;
[0024] FIG. 8 represents a flow diagram of another implementation
of the fraud detection unit method;
DETAILED DESCRIPTION OF THE INVENTION
[0025] Unless defined otherwise, all technical and scientific terms
used herein have the same meaning as commonly understood by one of
ordinary skill in the art to which this invention belongs.
[0026] The present invention provides a fraud detection and
resolution management system, method, system, and device which
analyze a variety of dynamic characteristics to authorize financial
transactions.
System Overview
[0027] Referring to FIG. 1, shown is a network communications
system in which implemented is a fraud prevention system for
transactions, in accordance with an embodiment. 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.
[0028] More generally, 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. In some implementations, one or more of the banking
institution sites includes a fraud reporting center. 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. 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.
[0029] The network includes a combination of one or more cellular
networks and one or more wired telephony networks and the Internet,
for example.
User Devices and User Specific Information
[0030] The user devices are used to perform 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. More generally, the transactions include
transactions requiring security such as transactions for commerce
and payments, for example.
[0031] A user device may be any device capable of network access.
This device may be either wired or wireless. In some embodiments,
the device may include a personal computer, tablet, mobile device,
mobile phone, television, music player, personal organizer, or any
similar electronic network enabled device. In some embodiments, 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., underwear male
and female, pants, dresses, shirts, sweater, jacket), shoes,
socks--essentially anything that is placed on or in a person can
potentially include electronics and network enablement. In some
embodiments, the user device may include an interface for accepting
credit card payment or debit payments at a business for
example.
[0032] 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, the fraud prevention system makes use of user
specific information. User specific information includes and
identifiable characteristic 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.RTM. or
Twitter.RTM. to search for locational information or general
commentary, complaints, peer-to-peer interactions).
[0033] 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. For example, 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.
[0034] With respect to the location user specific information, 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.
[0035] In some embodiments, 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.RTM.
API) based on time/age, retrieving forth location of user's
Facebook.RTM. status update based on time/age, retrieving fifth
location of user's Foursquare.RTM. 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. These different characteristics are
combined and put into the dynamic weighting analysis stage where a
dynamic weighting factor is assigned to each user specific
characteristic. The dynamic weighing is received from a dynamic
database assigning values for each factor. It should be noted that
the weights change depending on the user information received from
the user.
[0036] In some embodiments, 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.
In some embodiments, transactions are carried out via the server at
one at one of the transaction sites. Furthermore, in some
implementations, the user device is located at the transaction site
as the case may be in an ATM or credit/debit card payment
system.
[0037] In some embodiments, the first and second devices can be the
same device. Particularly, the means for payment and the mobile
device may be one in the same. In some embodiments, 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. In some embodiments, applications and operations
performed using Near-Field Communication (NFC) may be considered as
having the first device and second device in the same device. In
some embodiments, the first device and second device may be
considered mobile browser based commerce operated from the mobile
device of the user. In some embodiments, it is contemplated that
SIM based credit may be used on a user's mobile device for
commerce. In some embodiments, it is contemplated that Peer-to-Peer
transactions may be enabled over the user's device.
[0038] In other implementations 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.
[0039] The user may be referred to as an entity and therefore may
refer to the customer or the merchant.
Authentication
[0040] 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.
[0041] 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 does not meet the specified threshold.
[0042] In some embodiments, location may be used as the sole
initial characteristic required for authentication. Referring to
FIG. 2, shown is flow chart of a method of authenticating a
transaction in the fraud prevention system of FIG. 1. In some
embodiments, the method is implemented by the authentication device
at any one of the banking institution sites. At step 201, in
response to receiving a request for authenticating a transaction
involving a first device at first location 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. At step 203, 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.
[0043] 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.
[0044] 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.
[0045] With reference to FIG. 1 and FIG. 2, at step 201 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. Alternatively, in
other implementations, 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.
[0046] In some embodiments, the authentication involves having the
authentication device send information to the user device
confirming the authentication. In some embodiments, GPS on the user
device may provide location based information constantly, or at a
specified interval. In some embodiments, retina scanners
implementing biometrics at a location may scan the user's physical
eye to authenticate identity and associate a user with a location.
In some embodiments, 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.
[0047] In some embodiments, the request received at step 201
includes one or more first characteristics associated with the user
device other than the second location information.
Multi-Characteristic Authentication
[0048] 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.
[0049] As mentioned previously, 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. In such embodiments,
at step 201 for each first characteristic a respective second
characteristic associated with the user device is obtained. At step
202 for each first characteristic a respective level of correlation
between the first characteristic and the respective second
characteristic is determined. At step 203 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.gtoreq.1. In other implementations the
authentication fails if any M or more correlations are below
respective threshold values, where M is an integer with M.gtoreq.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.
[0050] With respect to dynamic weighing, the general operations are
implemented as follows. 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.
[0051] In some implementations, some transactions do not need
authentication using credentials and step 205 is not required for
authentication for such transactions.
Authentication and Communication Interface
[0052] Further details of the structure and operation of the
authentication device and the user device will now be described
with reference to FIG. 3A and FIG. 3B.
[0053] 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. For each request received, 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. When authentication fails 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.
[0054] In FIG. 3A, the functionality of 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.
[0055] Referring to 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, a communication interface, a GPS (Global Positioning System)
unit, an environment unit, a key login speed unit, a gyroscope, and
an accelerometer. The user interface provides the user with the
ability to enter and view information and includes a keyboard and
display for example.
[0056] The communications interface allows the user device to
communicate with other devices and servers in a network
communications system. In some embodiments, 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. In addition, 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 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.
[0057] In FIG. 3B, the functionality of 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.
Valid Authentication--No Verification
[0058] Referring to 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.
[0059] In the following example, one of the primary characteristics
analyzed is location. During initiation of the transaction 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. As discussed
above, in some implementations 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.gtoreq.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. In some implementations 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. In some embodiments, 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.
[0060] Responsive to receiving the second location information, the
authentication server 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. In some implementations
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.
[0061] In some embodiments, the authentication is done locally on
the first or second device and not transmitted; only the
authentication success/failure information is transmitted.
[0062] As discussed above, in some implementations for some
transactions there is no need for authentication using user
credentials and in such cases there is no verification of user
credentials when authentication based on location or other
invisible correlation information succeeds.
[0063] In the exemplary scenario of FIG. 4A authentication of the
transaction succeeds and further verification need not be
applied.
Authentication Fails--Verification Required
[0064] A different scenario in which the location authentication
transaction originally fails will now be described with reference
to FIG. 48.
[0065] In FIG. 4B, the signaling process is similar to that of FIG.
4A up to the point where location authentication is performed. In
this case the correlation between the first and second locations is
not sufficiently high and results in a failed authentication during
the location authentication step. In response to the failed
authentication, the fraud detection server sends a response to the
user device with information on the failed authentication.
[0066] At this point verification may be implemented to verify the
identity of the individual. In some embodiments, verification
includes a person to person interaction to identify an individual.
In some embodiments, verification includes utilizing one or more
user based characteristics not initially used for
authentication.
[0067] Continuing in FIG. 4B 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.
[0068] It is contemplated that 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.
[0069] In some embodiments, 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.
[0070] In FIG. 48 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. However, it is to be clearly understood that
implementations are not limited to this particular implementation.
For example, in another implementation 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.
[0071] As discussed above, 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. In the case of
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.
[0072] Furthermore, in some cases a transaction with the
transaction server may be initiated by the user device through one
or more servers. For example, 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.RTM. for
example. In such a case, 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.
[0073] Referring to 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.
[0074] For example, 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.
[0075] More particularly, 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. For example, 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. 48.
Fraud Prevention Communication System Utilizing Aggregate User
Data
[0076] 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.
Flagging Transactions at Point of Sale
[0077] 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.
[0078] 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. In response to
receiving a response with the user credentials and the confirmation
information, 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. Such a mechanism will
now be described in more detail with reference to FIG. 5, FIG. 6A,
and FIG. 6B.
[0079] The user may flag the transaction utilizing various degrees
of concern. In some embodiments, 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.
Alternatively, 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. Additionally, the user
may flag the current transaction as "definitely fraud" where the
transaction is blocked from proceeding and third party authorities
are notified.
[0080] In some embodiments, 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. In this way, when a new user visits
a merchant which has questionable credentials based on the database
analytics within the fraud detection unit, 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.
[0081] In some embodiments, the threshold for calculating the
tolerance for suspicious activity changes with volume of
transactions. Furthermore, the threshold may be set manually by the
system administrator or dynamically but process given input from
various data inputs (e.g., transaction information).
Fraud Prevention System Implementation
[0082] Referring to 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. In FIG. 5, the
functionality of each of the graphical user interface, the
transaction authentication unit, 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.
[0083] The transaction 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.
[0084] Such a mechanism will now be described in more detail with
reference to FIG. 6A, which 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. In this messaging
flow 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.
[0085] The information contained in the VERIFY message includes
information suitable for identifying a fraudulent user, such as a
fraudulent merchant for example. 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.
[0086] 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.
[0087] For example, 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.
[0088] 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.
[0089] In this example, the authentication device then sends a
notification message to a call agent containing information related
to the transaction. For example, 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.
[0090] In some embodiments, 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.
[0091] 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.
[0092] For example, 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. Alternatively, 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 NOTIFICATION to the
other user call devices.
[0093] The notification may be in any format for which can be
received on a user device. In some embodiments, 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. Furthermore, each
notification includes information for identifying a respective
transaction and allowing the user to determine whether the
transaction is indeed fraudulent.
Fraud Detection Unit Analytics
[0094] As mentioned previously, 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.
[0095] 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.
[0096] 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.
Each time a device tries to authenticate with a device for a
transaction, the database is updated to with another entry of data
to populate. In this fashion, 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.
[0097] An example of the system implementation can be seen in FIG.
7. The user authenticates with the system implicitly (701), 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.
[0098] In situations where the threshold is met, 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.
[0099] For example, if the transaction is at a coffee shop, 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.
[0100] In the embodiment of FIG. 6A, the user must enter the proper
credentials before confirmation of whether a transaction is
fraudulent is accepted. However, in other implementations the
confirmation is accepted without the need for credentials.
[0101] Referring to 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. In this
messaging flow 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.
[0102] 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.
[0103] 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.
[0104] 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.
[0105] In FIG. 6A and FIG. 6B, 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.
[0106] In 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.
[0107] The third party may be any third party required to verify
the identity of the user conducting the transaction. In some
embodiments, 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.
[0108] 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.RTM. iOS,
Google.RTM. Android, BlackBerry.RTM., Microsoft Windows Phone
8.RTM., and other smartphones. Alternatively, with reference to
FIG. 5, in some embodiments, the fraud confirming unit, the
transaction authentication information unit, and the graphical user
interface 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.
[0109] 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.
[0110] In some embodiments, 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.
[0111] If further verification is required, authentication is also
made using other characteristics such as speed, acceleration, and
key login in speed for example. Furthermore, communications are
made with a detection unit so that it can retrieve information from
the database to identify whether the transaction is potentially
fraudulent.
[0112] After the above verifications, if it is deemed that the user
needs to be informed, 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.
[0113] As discussed above, 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.
[0114] An example of the implementation of the fraud detection
system and resolution management system can be seen in FIG. 8. In
this example, a third party payment gateway is integrated with the
system to enable credit processing. In some embodiments, the
payment gateway may be part of the fraud verification and
resolution management system.
[0115] The user logins in (1) to the system (payment gateway) using
a mobile device as their device (1 a) and registers with the system
server (Fraud Detection Unit). The user sets their preferences
regarding notifications and financial security with the system
server (2).
[0116] These settings are passed on to the payment gateway
authentication database of the payment gateway (3).
[0117] If a transaction is flagged by the payment gateway, a
notification is sent to the Fraud Detection Unit utilizing an
application programming interface (4). In some embodiments, the
flag is stored on the payment gateway database (4 a) prior to the
flag being pushed to the fraud detection unit (4 b).
[0118] 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).
[0119] 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 (10 a) and recorded in the database within the payment
gateway (10 b).
Providing Alerts
[0120] In some embodiments, 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.
[0121] For example, 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.
[0122] In another example, a merchant may be alerted of a potential
customer having a high level of invalid authentication with respect
to a specific credit card.
[0123] In some embodiments, the alert is proximity based by a
pre-determined threshold when the first user device meets the
threshold relative to a second user device.
[0124] In some embodiments, 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.
[0125] It is obvious that the foregoing embodiments of the
invention are examples and can be varied in many ways. Such present
or future variations are not to be regarded as a departure from the
spirit and scope of the invention, and all such modifications as
would be obvious to one skilled in the art are intended to be
included within the scope of the following claims.
* * * * *