U.S. patent application number 13/587180 was filed with the patent office on 2012-12-06 for location based authentication system.
This patent application is currently assigned to mConfirm, Ltd.. Invention is credited to Boaz AVIGAD, Tomer EDEN.
Application Number | 20120310836 13/587180 |
Document ID | / |
Family ID | 36950500 |
Filed Date | 2012-12-06 |
United States Patent
Application |
20120310836 |
Kind Code |
A1 |
EDEN; Tomer ; et
al. |
December 6, 2012 |
LOCATION BASED AUTHENTICATION SYSTEM
Abstract
A method for determining a fraud score associated with a
monetary transaction facilitated using a payment card in a store is
disclosed. The method comprises receiving data representative of an
incoming payment transaction; analyzing a location of an owner of
the payment card and a location of the store for determining a
location rating; analyzing a location behavior profile (LBP)
related to the payment card for determining a behavior rating,
wherein the analysis is based in part on the incoming payment
transaction; computing a transaction rating using the location
rating and the behavior rating in combination with a first weight
factor; analyzing historical payment transactions related to the
payment card for determining a card rating; and computing the
fraud-score using the transaction rating and the card rating in
combination with a second weight factor.
Inventors: |
EDEN; Tomer; (Tel Aviv,
IL) ; AVIGAD; Boaz; (Tel Aviv, IL) |
Assignee: |
mConfirm, Ltd.
Tel Aviv
IL
|
Family ID: |
36950500 |
Appl. No.: |
13/587180 |
Filed: |
August 16, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11994977 |
Jan 7, 2008 |
8285639 |
|
|
PCT/IL06/00775 |
Jul 5, 2006 |
|
|
|
13587180 |
|
|
|
|
60702605 |
Jul 27, 2005 |
|
|
|
60695893 |
Jul 5, 2005 |
|
|
|
Current U.S.
Class: |
705/44 ;
705/39 |
Current CPC
Class: |
G06Q 30/06 20130101;
G06Q 20/40 20130101; G06Q 20/04 20130101; G06Q 20/20 20130101; G06Q
40/00 20130101; G06Q 20/403 20130101; G06Q 20/4016 20130101 |
Class at
Publication: |
705/44 ;
705/39 |
International
Class: |
G06Q 20/40 20120101
G06Q020/40; G06Q 20/38 20120101 G06Q020/38 |
Claims
1. A computer-implemented method for determining a fraud score
associated with a monetary transaction facilitated using a payment
card in a store, the method comprising: receiving data
representative of an incoming payment transaction; analyzing a
location of an owner of the payment card and a location of the
store for determining a location rating; analyzing a location
behavior profile (LBP) related to the payment card for determining
a behavior rating, wherein the analysis is based in part on the
incoming payment transaction; computing a transaction rating using
the location rating and the behavior rating in combination with a
first weight factor; analyzing historical payment transactions
related to the payment card for determining a card rating; and
computing the fraud-score using the transaction rating and the card
rating in combination with a second weight factor.
2. The method of claim 1, further comprising: authorizing said
incoming payment transaction if said fraud-score is within a trust
range.
3. The method of claim 1, wherein the data representative of the
incoming payment transaction includes at least one of: details of
said payment card and the location of said store.
4. The method of claim 3, further comprising: determining a
cellular telephone number associated with the payment card; and
determining the location of a cellular telephone identified by the
cellular telephone number so as to infer a geographic location of a
purchaser.
5. The method of claim 2, wherein said location rating indicates
whether at least one: the cellular telephone is located in dose
proximity to the store and the location of the purchaser with
respect to the store.
6. The method of claim 2, wherein said behavioral rating indicates
whether a behavior pattern of said owner of said payment card
deviates from said LBP.
7. The method of claim 2, wherein said behavioral rating indicates
whether a behavior pattern of said store deviates from said
LBP.
8. The method of claim 1, wherein said LBP includes at least
behavior patterns of at least payment cards' owners and stores in
respect to geographical regions and time periods.
9. The method of claim 2, wherein said card rating indicates the
number of previous suspected payment transactions recorded for said
payment card.
10. A non-transitory computer readable medium having stored thereon
instructions for causing a computer to perform the method of claim
1.
11. An authentication system for determining a fraud score
associated with a monetary transaction facilitated using a payment
card in a store, said authentication system comprising: a
transaction processor for processing data representative of an
incoming payment transaction for determining said fraud-score based
on at least a location of an owner of said payment card and a
location of a store; a database for storing incoming payment
transactions and fraud scores computed for incoming payment
transactions; and a display unit for displaying data representative
of processed incoming payment transactions.
12. The authentication system of claim 11, wherein said transaction
processor authorizes said incoming payment transaction if said
fraud-score is in a trust range.
13. The authentication system of claim 12, wherein said
authentication system is connected to a transaction server through
a communication network to receive said data representative of said
incoming payment transaction.
14. The authentication system of claim 12, wherein said
authentication system is further connected to a location based
service (LBS) server to determine a geographic location of the
cellular telephone associated the payment card.
15. The authentication system of claim 12, wherein the transaction
processor is adapted to determine said fraud score by: analyzing
the geographic location of the owner of said payment card and a
location of the store for determining a location rating; analyzing
a location behavior profile (LBP) related to said payment card for
determining a behavior rating; computing a transaction rating using
the location rating and the behavior rating in combination with a
first weight factor; analyzing historical payment transactions
related to said payment card for determining a card rating; and
computing the fraud-score using the transaction rating and the card
rating in combination with a second weight factor.
16. The authentication system of claim 15, wherein the data
representative of the incoming payment transaction includes at
least one of: details of said payment card and said location of
said store.
17. The authentication system of claim 15, wherein said location
rating indicates whether a cellular telephone of an owner of the
payment card is located in dose proximity to said store and the
location of the purchaser with respect to the store.
18. The authentication system of claim 15, wherein said behavioral
rating indicates whether a behavior pattern of said owner of said
payment card deviates from said LBP and whether a behavior pattern
of said store deviates from said LBP.
19. The authentication system of claim 15, wherein said LBP
includes at least behavior patterns of at least payment cards
owners and stores in respect to geographical regions and time
periods.
20. The authentication system of claim 15, wherein said card rating
indicates the number of previous suspected payment transactions
recorded for said payment card.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a divisional of U.S. application Ser.
No. 11/994,977, which is the National Stage of international
Application No. PCT/IL06/00775, filed Jul. 5, 2006. The
International Application claims the benefit of U.S. Provisional
Patent Application No. 60/695,893 filed on Jul. 5, 2005 and U.S.
Provisional Patent Application No. 60/702,605 filed on Jul. 27,
2005. The contents of each of the above-referenced applications are
herein incorporated by reference.
FIELD OF THE INVENTION
[0002] The present invention relates generally to location based
authentication (LBA) systems, and more particularly to the use of
location based authentication in fraud assessment.
BACKGROUND OF THE INVENTION
[0003] In recent years, payments using a credit card instead of
cash payments have become widespread, thus avoiding the dangers of
carrying large amounts of money in the form of cash. However, theft
or forgery of cards is also increasing rapidly and thus suitable
countermeasures to this are extremely important. Many solutions
have been proposed for ensuring against fraudulent use of stolen
and forged credit and cash cards. These solutions include limited
withdrawals, time limits for availability of credit cards,
duplicate encryption, and identification of card owners, to name a
few. Identification is performed by means of PIN codes,
fingerprints, one-time passwords, and so on. Still against the
increasing of card related crime, these traditional security
solutions are insufficient.
[0004] Location based authentication (LBA) systems provide an
improved solution for preventing fraudulent transactions made using
credit or cash cards. Examples of such LBA systems may be found in
WO 02/052879 (also published as US 2004/0073519 and WO 03/058936
(also published as US 2004/0242201), published US patent
application Nos. US 2003/0135470 and US 200510065875 as well as in
U.S. Pat. No. 6,097,938, each of which is incorporated herein by
reference for their useful background descriptions of the state of
the art heretofore. Generally, a LBA system detects fraudulent
transactions by verifying the user's presence at the place of
transaction. Specifically, the LBA system evaluates the
authenticity of a user's requests by retrieving the location of a
transmitting and receiving device, such as a mobile phone, carried
by the user and comparing it with the location of a point of sale
(POS) terminal (or a cash-withdrawal terminal). If the terminal and
mobile phone are located within a calculated and acceptable
distance the transaction is approved. The location of the user is
retrieved from the mobile network while the terminal location is
considered fixed.
[0005] LBA systems provide a higher level of security over
traditional solutions; however, they fail to provide a reliable
means of identifying fraudulent transactions. One of many reasons
for this inability is that fraud identification is based solely on
the geographical distance between the merchant's terminal and the
user's mobile phone. In addition, LBA systems are not designed to
track changes in merchants' locations or in the coverage of a
cellular network. Accordingly, prior art LBA systems typically
generate a large number of false alarms and thus cannot be
considered a reliable solution for the detection of frauds
committed using stolen cards.
[0006] It would be, therefore, advantageous to provide an improved
LBA system that accurately detects fraudulent transactions It would
be further advantageous if the provided system would detect
fraudulent transactions based on behavior patterns of cards holders
and merchants.
SUMMARY OF THE INVENTION
[0007] According to a first aspect of the invention, there is
provided a computer-implemented method for determining a fraud
score associated with a monetary transaction facilitated using a
payment card in a store, the method comprising:
[0008] receiving data representative of an incoming payment
transaction;
[0009] analyzing a location of a cellular telephone of an owner of
said payment card and a location of the store for determining a
location rating;
[0010] analyzing a location behavior profile (LBP) related to said
payment card for determining a behavior rating;
[0011] computing a transaction rating using the location rating and
the behavior rating in combination with a first weight factor;
[0012] analyzing historical payment transactions related to said
payment card for determining a card rating; and
[0013] computing said fraud-score using said transaction rating and
said card rating in combination with a second weight factor.
[0014] According to a second aspect of the invention, there is
provided a method for accurately and adaptively learning the
locations of merchants for the purpose of performing location-based
analysis of payment transactions, the method comprising:
[0015] identifying pairs of payment transactions occurred within a
predefined time interval and submitted by different merchants;
[0016] for each pair of payment transactions,
[0017] computing a transaction velocity;
[0018] computing a merchant location score (MLS) for each merchant
if said transaction velocity is lower than a maximum allowable
velocity; and
[0019] saving the computed MLS of a merchant if its computed MLS is
below a maximum value of MLS.
[0020] According to a third aspect of the invention, there is
provided a method for accurately and adaptively learning in
real-time the locations of merchants for the purpose of performing
precise location-based analysis of payment transactions, said
method comprising:
[0021] receiving a payment transaction submitted by a merchant;
[0022] obtaining the location of said merchant;
[0023] retrieving a plurality of location based services (LBS)
locations of one or more mobile phones associated with a user that
initiates said payment transaction;
[0024] for each of said plurality of LBS locations, increasing a
merchant location score (MLS) of said merchant if said merchant
location matches said at least one of said LBS locations; and
[0025] saving said each, of said plurality LBS locations as a new
location of said merchant if said one of said LBS locations matches
the obtained merchant location.
[0026] According to a fourth aspect of the invention, there is
provided an authentication system for determining a fraud score
associated with a monetary transaction facilitated using a payment
card in a store, said authentication system comprising:
[0027] a transaction processor for processing data representative
of an incoming payment transaction for determining said fraud-score
based on at least the location of a cellular telephone of an, owner
of said payment card and a location of a store;
[0028] a database for storing incoming payment transactions and
fraud scores computed for incoming payment transactions; and
[0029] a display unit for displaying; data representative of
processed incoming payment transactions.
BRIEF DESCRIPTION OF THE DRAWINGS
[0030] In order to understand the invention and to see how it may
be carried out in practice, an embodiment will now be described, by
way of non-limiting example only, with reference to the
accompanying drawings, in which:
[0031] FIG. 1 is a diagram of a network system used to describe the
authentication process preformed in accordance with an embodiment
of the present invention
[0032] FIG. 2 is a block diagram of an authentication server
constructed and operative in accordance with an embodiment of the
present invention
[0033] FIG. 3 is a flowchart describing the method for detecting
fraudulent transactions in accordance with an embodiment of the
present invention
[0034] FIG. 4 is a non-limiting and exemplary flowchart describing
the process for generating a LBP in accordance with an embodiment
of the present invention
[0035] FIG. 5 is a flowchart describing the method for learning the
location of merchant terminals in accordance with one embodiment of
the present invention
[0036] FIG. 6 is a flowchart describing the method for updating and
learning the location of merchant terminals in accordance with
another embodiment of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS
[0037] FIG. 1 shows a non-limiting diagram of a network system 100
used to describe the authentication process preformed in accordance
with an embodiment of the present invention. The network system 100
includes a merchant terminal 110 that communicates with a
transaction server 120 through a communication medium 130. The
transaction server 120 is coupled to an authentication server 140
which processes incoming transactions as will be described in
greater detail below. The connection between the transaction server
120 and the authentication server 140 is established by means of a
local area network (LAN). The authentication server 140 receives
the location of a subscriber's mobile phone 160 through a
location-based-services (LBS) server 150. The LBS server 150
communicates with the authentication server 140 through, for
example, an internee protocol (IP) network 160. The LBS server 150
locates a mobile phone 170 in a cellular network 180 to which the
card holder subscribes. The location provided by the LBS server 150
may be, but not limited to, a cell ID of the cellular network, OPS
coordinates, and the like.
[0038] The authentication process carried out by the network system
100 starts with a subscriber (i.e., a credit card holder making a
purchase) who initiates a purchasing transaction at the merchant's
place of business. Then, the merchant terminal 110 connects with
the transaction server 120 and sends to it the transaction
information. The transaction information includes, but may not
necessarily be limited to, details of the merchant (e.g.,
merchant's ID, type, name, and address), payment card details
(e.g., card number and expiry date), sums to be charged, date of
purchase, and so on. The transaction server 120 sends the
transaction information to the authentication server 140 for
authenticating the transaction. As part of the authentication
process, the authentication server 140 generates a location request
to the LBS server 150 to locate a mobile phone 170 associated with
the card owner. Upon receiving the location of the mobile phone
170, the authentication server 140 performs a series of analyses to
authenticate the transaction. Specifically, the authentication
server 140 produces a fraud-score that indicates to some extent the
reliability of the transaction. Based on the fraud-score, the
transaction server 120 decides whether or not to authorize the
transaction and produce an alert.
[0039] FIG. 2 shows a non-limiting block diagram of the
authentication server 140 constructed and operative in accordance
with one embodiment of the present invention. The authentication
server 140 includes a transaction processor 210, a graphical user
interface (GUI) 220, and a database 230. The transaction processor
210 performs all activities related to the processing and
evaluation of transactions for the purpose of producing the
fraud-score. Specifically, the transaction processor 210 receives a
transaction processing request from the transaction server 120,
sends a request to the LBS server 150 to get the location of a
mobile phone 170 associated with the card owner, and performs a
series of authentication analyses to determine the fraud-score. The
authentication analyses carried by the transaction processor 210
are described in greater detail below with reference to FIG. 3. The
transaction processor 210 includes external interfaces to the
transaction server 120 and the LBS server 150 as well as internal
interfaces to the GUI 220 and the database 230. In one embodiment,
these interfaces are proprietary application programming interfaces
(APIs). The database 230 stores alt the information collected by
the authentication server 140, e.g., transactions and locations
information as well as processed data, e.g., fraud-scores and
generated alerts. The GUI 220 displays data of processed
transactions and alerts. The displayed data can be utilized by a
system operator for taking a decision as to whether a transaction
is fraudulent after the authorization of the transactions.
[0040] FIG. 3 shows a non-limiting flowchart 300 describing a
method for detecting fraudulent transactions in accordance with one
embodiment of the present invention. At S310, authentication server
140 collects transaction information sent from the transaction,
server 120 and saves the data in its database 230. At S312, the
subscriber information, including at least the current location
associated with a credit card that is used to pay for the
transaction or validate the purchaser, is retrieved by sending a
LBS request to the LBS server 150. At S314, merchant information
including at least its current location is retrieved from the
database 230. The geographic location of a merchant is represented
in a format that allows for an easy comparison to the location of a
mobile phone. For example, the merchant location may be stored as a
cell ID of the cellular network, a set of GPS coordinates, and so
on. The position of a merchant is dynamically learnt by the
authentication server 140 using a learning process described in
greater detail below.
[0041] At S320, a location rating that indicates if a subscriber is
located in proximity to the merchant is generated. The location
rating is determined by matching location of the mobile phone 170
associated with the owner of the credit card, as received from the
LES server 150, to the learnt location of the merchant, and
generating a location rating that is, in one embodiment of the
disclosed invention, a function of the distance between the
compared locations. This rating may be generated by normalizing the
resultant distance to 1, where a good rating is 1 and a poor rating
is 0. In one embodiment of the present invention a cellular
analysis is applied if S320 results in a poor rating. This analysis
checks if the reason for the outcome rating is the inability to
detect the location of the mobile phone (e.g., due to the
inactiveness of the phone). Then, it is further checked whether it
is a normal behavior for the subscriber not to activate the mobile
phone on certain days or in certain locations. For example, the
subscriber may shut-off the mobile phone when visiting theaters or
museums. If the inability to detect the phone's location is
determined as a normal behavior, the location rating may be refined
or may be given a lower weight when calculating the final
fraud-score.
[0042] At S322, a behavior rating is generated. This is performed
by detecting deviations from a location behavioral profile (LBP),
which characterizes the behavior pattern of both subscribers and
merchants, and generates a value proportional to the detected
deviations. The resultant value may be normalized to 1, where a
good rating is one and a poor rating is 0. As will be described in
greater detail below, the LBP includes historical information
gathered on each subscriber and merchant with respect to their
geographical locations and time periods (e.g., time of day, day of
week, and so on) in which transactions were recorded. At S324, a
transaction rating is generated. The transaction rating is a
function of the location rating and behavior rating. For example,
the transaction rating may be a weighted average of both the
location rating and behavior rating normalized to 1, where a good
rating is 1 and a poor rating is 0.
[0043] At S330, a card rating is determined that indicates the
number of previous suspected transactions recorded for a specific
card of a subscriber. The card rating is determined by accumulating
the number of all transactions indicated as suspected, for example,
all transactions with a transaction rating below a reconfigurable
threshold. The counted number of transactions may be normalized to
1, where a good rating is 1 and a poor rating is 0. At S340, the
fraud-score is generated using the computed transaction rating and
card rating. The fraud-score is a function of both the transaction
rating and card rating and may be, for example, a weighted average
of both, ratings normalized to 1, where one represents the least
suspicious. At S350, the fraud-score is sent to the transaction
server 120.
[0044] The transaction server 120 authorizes the transaction if the
fraud-score is within a trust range; otherwise, the transaction is
denied. The upper and lower bounds of a fraud-score are
configurable and may be set by a system administrator or
automatically determined, by the authentication server 120. The
computed fraud-score, transaction and card ratings are saved in the
database 230.
[0045] It will be appreciated by a person skilled in the art that
the fraud-score provides a superior advantage over prior art
solutions that produce an indication whether to authorize the
transaction merely based on the locations of the merchant terminal
110 and a mobile phone 170.
[0046] FIG. 4 shows a non-limiting flowchart 400 describing the
process for generating a LBP in accordance with one embodiment of
the present invention. A LBP includes behavior patterns of
merchants and subscribers (either for a specific subscriber or a
group of subscribers) in respect to geographical regions and time
periods. The learning of a behavior pattern is based on statistics
gathered on performed transactions. In a pre-processing operation,
the method gathers details on any transaction performed by a
subscriber or group of subscribers.
[0047] At S410, for each subscriber, the geographical regions in
which the subscriber performs most of the transactions (hereinafter
the "subscriber zones") are identified. Each subscriber zone
defined by a group of merchants (i.e., places of business a
transaction took place at) relatively located in the same distance
region and the number of transactions above a predefined threshold
associated with each such merchant. The distance region is defined
as the maximum distance between each pair of merchants in a
subscriber zone. At S415, the location (e.g. a set of GPS
coordinates) of each identified subscriber zone is added to the LBP
of the respective subscriber zone. At S420, for each, merchant, the
minimal average distance (MAD) between subscribers and their
respective subscriber zones is computed. For example, subscribers
X, Y and Z are respectively related to subscriber zones A, B and C
and the minimal distances from a merchant-1 (i.e., where the
purchases were made) to subscriber zones A, B and C are
respectively 10 km, 15 km, and 2 km. In such a scenario the MAD of
merchant-1 is 91-km. The MAD may be significantly different from
one merchant to another, as the types of businesses are different.
For instant, the MAD computed for a hotel may be higher than the
MAD computed for a local grocery store. At S425, the MAD computed
for each merchant is added to the profile. At S430, for each
merchant the MAD is computed for different profiles of transactions
or cards for instance time periods, amount, type of card etc.,
i.e., using transactions recorded in designated time periods. The
time periods may be, but are not limited to, time of day, day of
week, holidays, sessions, and so on. As a non-limiting example, a
LBP may include MADs computed for a grocery store in two different
time periods: Saturdays and Sundays between 10 AM and 12 PM as well
as Mondays through. Thursdays between 2 PM and 6 PM. At S435, the
MADs computed at S430 are saved together with their respective time
periods in the LBP.
[0048] Other statistics related to transactions performed in
respect to the subscriber zones may be computed and added to the
LBP. These statistics include, but are not limited to, average
amount of purchases where the distance between the merchant and a
subscriber zone is less than a pre-defined distance, e.g., the
distance between a subscriber zone is between 10-15 km, standard
deviation of the MAD between the merchant and a subscriber zone,
and so on. As mentioned above, the LBP is utilized for detecting a
fraudulent transaction by identifying any deviation from data
stored in the MAD.
[0049] FIG. 5 shows a non-limiting flowchart describing a method
for accurately and adaptively learning the locations of merchants
in accordance with an embodiment of the present invention. The
learning process allows precise location-based analysis of payment
transactions to be performed.
[0050] The authentication server 140 holds and constantly updates a
lookup table, in the database 230, of the locations of all possible
merchants 110 in a specific area. At S510, a batch of historical
payment transactions sent from merchants is uploaded to the
authentication server 140. A payment transaction is a request sent
from a merchant terminal 110, to the transaction server 120, for
authorizing the transaction. As mentioned above, all transactions
are recorded by server 120. At S520, all pairs of historical
transactions that occurred within a pre-defined time interval, and
performed by the same card holder are identified. This is performed
in order to determine if transactions of each such pair can be
paired. At S525, the identified pairs of transactions are saved in
a list (hereinafter the "pair list"). At S530, the variables'
maximum acceptable velocity ("Vmax") and maximum merchant location
score ("MLSmax") are set to their initial values, e.g., 80 kph and
100 kph respectively. A merchant whose calculated MLS is above
MLSmax is considered as an `established` location.
[0051] At S535, a pair of transactions is selected from the pair
list. At S540, it is checked if at least one of the merchants who
submitted transactions in the selected pair is considered as an
anchor location. An anchor location is a location, that was
verified and considered accurate, i.e., a location with a
relatively high MLS. If S540 results with an affirmative answer,
execution continues with S545; otherwise, execution ends. If none
of the merchants is considered as an anchor location, then a
process for updating the MLS of each merchant is applied. One
example for such process is described below with reference to FIG.
6. Another process that may be used for updating the MLS is the
method described, herein, where in this case, execution proceeds to
S545 regardless to the results yielded at S540.
[0052] At S545, the distance between the merchants (".DELTA.D") is
computed. At S550, a transaction velocity (Vt) is computed. Vt is
equal to .DELTA.D divided by a time interval .DELTA.T between
transactions in the selected pair. For example, if a pair of
transactions associated with merchants A and B is performed in a
time interval .DELTA.T and the distances between merchants A and B
is .DELTA.D, then Vt is computed as follows:
V t = .DELTA. D .DELTA. T . ##EQU00001##
[0053] At S555, it is checked if V.sub.t is lower than Vmax, and if
so execution continues with S560 where a new value of MLS is
computed for each of the merchants. Specifically, the AILS of the
first and second merchants MLS.sub.A and MLS.sub.B are computed as
follows:
MLS A = MLS A ' + V m ax - V V ma x * MLS B , and ##EQU00002## MLS
B = MLS B ' = V m ax - V V ma x * MLS A . ##EQU00002.2##
[0054] The MLS' is the previous score assigned to each merchant
location. This score may be a default or pre-computed value. At
S565, it is checked if a MLS computed for each merchant is below
the value of MLSmax, and if so execution continues with S570 where
a MLS value or values below MLSmax are saved in their respective
entries in the lookup table. If the operation in S565 results with
a negative answer, then at S575, the coordinates of the anchor
location are saved as the location of a merchant with MLS greater
than MLSmax. The new computed MLS of each such merchant is also
saved.
[0055] Execution proceeds to S580 if the result of S555 yields that
Vmax is higher than Vt. At S580, the location coordinates of the
merchant which is the anchor location are saved as the location of
the second merchant (hereinafter the "remote merchant"). At S535, a
radius for the remote merchant is computed and added to the lookup
table in the respective entry. The radius is computed as
follows:
RadiusD=RadiusC+TDFC;
[0056] where, TDFC is a difference factor that equals to
.DELTA.T*Vmax and RadiusC is the radius of the anchor location. At
S590, a new MLS is calculated for the remote merchant as
follows;
MLSD=.beta.*MLSC
where, MLSC is the score of the merchant considered as the anchor
location and .beta. is a configurable parameter that may vary, for
example, between 0.1-0.2. The new computed MLS is added to the
lookup table. At S595, it is checked if all pairs of transactions
in the pair list were bandied, and if so execution terminates;
otherwise, execution returns to S535.
[0057] FIG. 6 shows a non-limiting flowchart 600 describing a
method for updating and learning the locations of merchant
terminals, in accordance with one embodiment of the present
invention. The method updates and learns new locations in
real-time, i.e., as payment transactions received at the
authentication server 140 from the transaction server 120 actually
take place. Specifically, the method updates the MLS and the status
of each merchant in the lookup table using LBS information
retrieved from the cellular network 180 through the LBS server
150.
[0058] At S610, a subscriber-cellular score (SCS) and a maximum SCS
("SCSmax") are set to their initial values. The SCS provides an
indication if the mobile phone 170 of a user can be indicative of
his location. For example, on the one hand, if a user always
carries his phone then the SCS may be set to a higher value; on the
other hand, if the user rarely carries his phone, the SCS may be
set to a lower value. The SCS may be a function of a number of
prior `on-location` transactions. The SCS and SCSmax are relevant
only if a user has two or more mobile phones. In the case that a
user has only a single phone the SCS and SCSmax are set to 1.
[0059] At S620, a payment transaction sent from a merchant terminal
110 is received at authentication server 140 (through the
transaction server 120). A transaction carries information that
includes, but may not necessarily be limited to, details of the
merchant (e.g., merchant's ID, type, name, and address), payment
card details (e.g., card number and expired date), sums to be
charged, date of purchase, and so on. At S625, the known location
of the merchant that initiates the transaction is obtained from,
the lookup table in database 230. At S630, the authentication
server 140 generates a location request to the LBS server 150 to
locate each of the user (i.e., card holder) mobile phones.
Specifically, first the authentication server 140 gets from
database 230 a list, of phone numbers of the user and send a LBS
request to one or more cellular networks to retrieve the mobile
phones locations (hereinafter the "LBS locations"). All LBS
locations are kept in a LBS locations list. At S635, a single LBS
location is selected from the list. At S640, it is checked if the
chosen LBS location matches the merchant location as retrieved at
S625, and if so execution proceeds to S645 where the incoming
transaction is declared as `on-location` and the MLS of the
merchant is increased; otherwise, execution continues S650. The
transactions declared as `on-location` can be used later for
determining the SCS of the user mobile phone. The new MLS is set
to:
MLS = MLS ' + .lamda. * SCS SCS ma x ##EQU00003##
where MLS' is the previous score assigned to a merchant and .lamda.
is a configurable parameter.
[0060] At S650, is it checked if all LBS locations in the list were
handled; and if so execution continues with S655 where a new
merchant location is added to the lookup table; otherwise,
execution returns to S635. A new location is added only if none of
the user's mobile phones is `on-location`. Specifically, at S655,
each of the LBS locations in the list is added to the lookup table.
For each such location, a set of coordinates as well as the radius
of the LBS location are saved. Furthermore, a MLS is computed and
added to the table. The MLS is computed as follows:
MLS = SCS SCS ma x * .alpha. ##EQU00004##
where the parameter .alpha. is configurable, e.g., a may be set to
a value of 1000. It should be noted that a newly created merchant
location is not necessarily valid, i.e., is an `un-established`
location, in order for the location to be considered as established
and trusted, it needs to be confirmed by the LBS locations of a
configurable number of other card holders e.g., two card
holders.
[0061] At S660, once one or more locations are created, a merging
process takes place to eliminate duplicate newly created locations
covering same areas. Specifically, the merging process compares alt
merchant locations of each merchant and identifies groups of two or
more locations which cover the same area. Once a group is
identified, all, the relevant merchant locations are merged into
one inclusive location. The MLS of the merged location is the sum
of the original locations' scores. In a case where at least one of
the merged locations is an established location, the merged
location is also considered established.
[0062] After executing the real-time learning process, the
transactions coupling process (described above with reference to
FIG. 5), or a cleaning process, can further be performed to ensure
a higher level of accuracy. The cleaning process comprises checks
that all merchant locations are valid and no duplicates exist. The
process checks all the merchant locations' scores and update dates.
If the update date is older than a configurable expiration date the
merchant location is purged. An `un-established` merchant location
can also be purged if its date is older than a configurable
semi-expiation date and its MLS is less than a configurable
semi-expiration score.
[0063] It will be understood that while the invention has been
described with regard to payment using a credit card, actual
payment may be made by other means and the purchaser's credit card
may be used only to authenticate the purchaser. For example, once
it is established that the purchaser's location, as identified by
his cellular telephone for example, is within correct proximity of
the merchant, payment itself can be charged to the purchaser's
cellular telephone bill or to another charging account associated
with the purchaser.
[0064] It will also be understood that the system according to the
invention may be a suitably programmed computer. Likewise, the
invention contemplates a computer program being readable by a
computer for executing the method of the invention. The invention
further contemplates a machine-readable memory tangibly embodying a
program of instructions executable by the machine for executing the
method of the invention.
* * * * *