Note: Descriptions are shown in the official language in which they were submitted.
2~ 7~-X25
WO 95!11576 PCT/US94/11906
1
AN APPP~tATUS AND METHOD FOR CREDIT BASED MANAGEMENT OF
TELECOMMUNICATION ACTIVITY
Background of the Invention
1. Field of the Invention
This invention relates to monitoring telecommunication
systems, and more specifically, to an apparatus and method
for detecting potentially fraudulent telecommunication
system usage. Telecommunication systems include both
,wireless systems (e. g., cellular telephones, satellite
transmission, etc.) and systems utilizing transmission
lines (e. g., common telephone systems). Fraudulent
telecommunication activity is unauthorized usage for which
the telecommunication system owner is not paid for its
services. The invention also relates to credit based
management of telecommunication systems.
2. Description of the Related Art
Because immediate access to information has become a
necessity in virtually all fields of endeavor -- including
business, finance and science -- telecommunication systems
usage, particularly for wireless telecommunication systems,
is increasing at a substantial rate. With the increase in
overall usage, however, the incidence of fraudulent usage
has experienced a corresponding increase. It is estimated,
for example, that fraudulent wireless telecommunication
system usage is responsible for losses to the wireless
telecommunication industry of $600 million each year.
Clearly, a system for detecting and preventing such
fraudulent activity would be highly desirable.
WO 95/11576 PCT/US94/11906
274625
Fraudulent telecommunication activity, which may occur
both in wireless and common telephone systems, has several
different varieties. Among these varieties are cloning
fraud, tumbling fraud, tumbling-clone fraud, calling card
fraud, and subscriber fraud.
Cloning fraud, which occurs in cellular telephone
systems, involves the misappropriation of a valid set of
subscriber identification numbers (ID), programming the ID
into one or more cellular telephones, and then using the
"cloned" cellular telephones to place calls which are
billed to the subscriber whose ID was misappropriated.
Tumbling fraud involves placing cellular telephone
calls using a different randomly generated subscriber ID
for each telephone call placed. Under certain circumstances
no pre-call verification of the ID number is performed
before the call is connected. Therefore, a fraudulent user
may place calls even without possession of a valid
subscriber ID. In this way, for example, 50 fraudulent
calls placed by a single fraudulent user will be billed to
50 different subscriber IDs, most of which will be
unassigned and unbillable, rather than to a single
subscriber as in the case of cloning fraud.
Tumbling-Clone fraud, as the name suggests, is a
hybrid of tumbling fraud and cloning fraud which involves
placing cellular telephone calls using a plurality of
cloned subscriber IDs. For example, a tumbling-clone
cellular telephone may have a sequence of 10 different
cloned subscriber IDs programmed into it. With each
WO 95/11576 217 4 6 2 ~ PCT/US94/11906
3
successive call placed by the fraudulent user, the cellular
telephone would use the cloned subscriber ID next in
sequence to initiate the call. In this way, the fraudulent
calls would equally be dispersed over 10 different
subscriber IDs, consequently making the fraudulent activity
more difficult to detect.
Calling card fraud involves the misappropriation of a
valid calling card number and then using the
misappropriated number to place toll calls which are billed
to an unsuspecting subscriber.
Subscriber fraud, which may occur in either cellular
telephone or common telephone systems, involves fraudulent
usage by an otherwise legitimate subscriber. Typically,
this type of fraud is experienced when a subscriber signs
up for telecommunication services, either cellular or
calling card, and proceeds to use the telecommunication
services with no intent of ever paying for the services
provided. A user practicing subscriber fraud would continue
to use the services without paying until system access was
blocked by the service provider.
Although a number of prior fraud detection and
prevention systems have been suggested, all have proved
inadequate for various reasons. One proposed solution
involves setting a predetermined number as a system-wide
threshold for the number of cellular calls that may be
placed by an individual subscriber in one day; when the
predetermined number is exceeded, the method indicates that
fraud has occurred. The system-wide threshold method,
WO 95/11576 PCT/US94/11906
2 i 7~-6~~
however, has several drawbacks. For example, this method
applies the same threshold to every user. Typically, a
high-volume subscriber such as a stockbroker may regularly
place a large volume of calls each day in the normal course
of business, whereas a low-volume subscriber who maintains
a cellular telephone primarily for emergency usage may only
place a few calls each week. The system-wide threshold
method would be inadequate for each of these users, because
it would generate a false alert for the high-volume
subscriber who happens to legitimately exceed the threshold
on a given day, while, incorrectly, no alert would be
generated for the fraudulent use of the low-volume
subscriber ID, as long as the threshold was not exceeded.
Moreover, the system-wide threshold method is easily
defeated by a fraudulent user who is aware of the
predetermined threshold and takes care to limit the number
of fraudulent calls placed to a number less than the
threshold.
Another method, referred to as "call numbering,'' has
been proposed to detect fraudulent cellular telephone
calls, wherein a predetermined sequence of numbers is
assigned to each cellular telephone unit within the network
and, with each successive call placed, the next number in
sequence is transmitted by the cellular telephone unit to
the service provider station and recorded in the order
received. When the call records are processed, if any call
sequence number occurs more than once, or if the call
sequence numbers are out of order, fraud or malfunction is
WO 95/11576 217 4 6 2 5 pCT~S94/11906
indicated and the cause must be investigated. This method,
however, has the disadvantage, inter alia, of requiring
that the cellular telephone unit be modified to include
additional equipment to generate and transmit the
5 predetermined sequence of numbers. Consequently, the "call
numbering" method is incompatible with the large majority
of existing telecommunication equipment that has not been
modified.
Moreover, the call numbering method is unreliable. It
has been found that the call number sequence may become
disordered through normal legitimate use, by events such as
early termination of the call or power failure, thereby
resulting in false alerts.
Also of concern in telecommunication systems is the
ability to effectively control or limit the risk of non-
payment by a subscriber, whether or not associated with
fraudulent activity, and the encouragement of system usage
by subscribers who are able to pay for the service.
Therefore, a system which reliably and accurately
indicates the possibility of fraudulent telecommunication
activity, but which is flexible enough to permit legitimate
use by a wide variety of subscribers, and which is
compatible with all types of existing telecommunication
equipment is needed.
Summary of the Invention
It is an object of the present invention to provide a
method and apparatus for detecting potentially fraudulent
WO 95/11576 PCT/US94/11906
L ~ ~ 4 E~25
6
telecommunication activity by comparing current usage for
a particular subscriber ID or calling card number with the
particular subscriber's historical pattern of usage. If
current usage for that ID or calling card number indicates
a deviation in the historical pattern of usage by the
subscriber, a potential fraud is indicated.
In one embodiment of the invention, the particular
subscriber's usage is analyzed to determine parameters such
as call duration (the average length in time of a call) ,
call velocity (the number of calls placed within a
specified time period), and call thresholds (the highest
number of calls placed by the subscriber within a specified
time period). One or more of these parameters is then
compared to the particular subscriber's historical pattern
of usage. If there is abnormal usage relative to the
subscriber's historical pattern of usage, a potential fraud
is indicated.
In one embodiment a particular subscriber's usage is
characterized as a plurality of moving averages, each
calculated over a different specified number of days, which
are then compared to each other to determine if a
significant deviation in usage has occurred. When a
significant deviation in usage is detected, a potential
fraud is indicated.
In another embodiment, a significant deviation in
usage is indicated when both of the following two
conditions are satisfied: (1) a moving average calculated
over a shorter number of days is greater than a moving
274625
WO 95/11576 PCT/US94/11906
7
average calculated over a longer number of days; and (2)
the percentage increase between a moving average calculated
on day (t) and the same moving average calculated on the
prior day (t-1) exceeds a predetermined amount.
It is a further object of the present invention to
provide a method and apparatus for detecting potentially
fraudulent telecommunication activity by detecting an
occurrence of overlapping calls. Overlapping calls are two
or more calls which either (1) occur concurrently, or (2)
are placed from different geographic regions and occur
within a sufficiently short time interval such that it
would be improbable that a single subscriber could place
the first call and then travel to the location of the
second call within the given time interval to place the
second call. Because each unique subscriber ID or calling
card number may typically only be used by a single
subscriber from a single location at one time, fraud is
indicated upon occurrence of either or both of these two
conditions.
In one embodiment, the fraud detection apparatus looks
at each call made by a particular subscriber to determine
whether any two calls using the same subscriber ID or
calling card number occurred substantially concurrently.
In another embodiment, the fraud detection apparatus
adjusts each call for geographic dispersion to determine if
two or more calls were placed using the same subscriber ID
or calling card number from different geographic locations
within a sufficiently short time interval such that travel
WO 95/11576
PCT/US94/11906
8
between the two geographic locations within the given time
interval is improbable.
It is a further object of the present invention to
provide a method and apparatus for detecting potentially
fraudulent telecommunication activity by comparing the
particular subscriber s present telecommunication usage
with a predetermined call destination. If the predetermined
subscriber-specific condition is satisfied, fraud is
indicated.
In one embodiment, each number called using a
particular subscriber ID or calling card number is compared
to a predetermined list of numbers suspected of frequently
being called by fraudulent users.
In a further embodiment, each country called using a
particular subscriber ID or calling card number is compared
to a predetermined list of countries suspected of
frequently being called by fraudulent users.
Several of the above-mentioned objects are achieved by
an apparatus comprising a digital computer; interface means
for receiving a call information record for each call
involving a particular subscriber; comparison means for
comparing the particular subscriber s current usage with a
subscriber-specific historical pattern of usage; and output
means for outputting an alert-state to signal a potentially
fraudulent call based upon a result of the comparison
performed by the comparison means.
The present invention also relates to the use of a
pre-call validation request to detect potentially
WO 95/11576 217 4~ ~ 2 ~ pCT/US94/11906
9
fraudulent telecommunication activity and, in particular,
cloning fraud. A pre-call validation request is a message
that is transmitted from a first telecommunication system
to a second telecommunication system or telecommunication
data base when an individual who is a subscriber of the
second system uses a telecommunication device within the
geographic boundaries of the first system. The pre-call
validation request permits the subscriber's
telecommunication service provider to validate the
individual before placing the call or providing other
services to the individual, who is typically referred to as
a "roamer" or "visitor" in the first system.
It has been found that information can be derived from
a pre-call validation request that can be used to detect
potentially fraudulent telecommunication activity and, in
particular, cloning fraud in which the individual
attempting to place a call has misappropriated a valid
subscribers identification numbers and therefore appears to
be a valid subscriber. In this situation, it has been
found that information can be derived from the pre-call
validation request that is inconsistent with the behavior
of the valid subscriber or inconsistent with a single valid
subscriber and therefore indicative of such fraud. For
instance, time information can be derived from a pre-call
validatian request that can be compared with time
information from another pre-call validation request to
determine if the two attempts to place calls occurred at
substantially the same time. If the two attempts did occur
WO 95/11576 PCT/US94/11906
>5
at substantially the same time, a potentially fraudulent
telecommunication is indicated because a single individual
cannot place two calls at substantially the same time, in
most circumstances.
One embodiment of the present invention for using a
pre-call validation request associated with a particular
subscriber to detect potentially fraudulent
telecommunication activity derives time information from
the pre-call validation request and uses this information
l0 to determine when telecommunication activity is occurring
in an improbable time sequence that is inconsistent with
the operation of a telephone or other telecommunication
device by a single user. Generally, this embodiment
includes an interface for receiving a pre-call validation
request associated with a particular subscriber; a detector
for using the pre-call validation request to determine if
telecommunication activity is occurring in an improbable
time sequence that is indicative of potentially fraudulent
telecommunication activity; and an output device for
communicating the occurrence of such activity. One
improbable time sequence that the detector can inspect is
the overlap in the time associated with a pre-call
validation request and the time associated with another
pre-call validation request. Alternatively, the detector
can look for an overlap in the time associated with a pre-
call validation request and the time associated with a call
information record that, in contrast to a pre-call
validation request, is a record associated with a completed
WO 95/11576 2 ~ 7 4 ~ 2 ~ PCT/US94/11906
11
call. In any event, the detector is looking for two
instances of telecommunication activity associated with a
single subscriber identification number that overlap in
time. In another embodiment, the detector uses geographic
information derived from two pre-call validation requests
or a pre-call validation request and a call information
record to identify calls that occur in an improbable time
sequence. More specifically, the detector is looking for
two instances of telecommunication activity that do not
overlap in time but, when the locations associated with
these two instances are taken into account, indicate
potentially fraudulent activity. For example, two pre-call
validation requests, one from Chicago and one from Denver,
may not overlap in time but if the difference in the time
associated with the two requests is notably less than the
typical travel time between Chicago and Denver, then
potentially fraudulent activity is indicated.
Another embodiment of the present invention derives a
switch identification number from a pre-call validation
request and uses this switch identification number to
detect potentially fraudulent telecommunication activity.
The switch identification number is a number associated
with a switch that establishes the connection or link
between the parties to a call, more accurately, the switch
identification number identifies a particular geographic
region, the boundaries of which are established by the FCC.
The subscriber to a telecommunication service provider uses
the one or more switches in the system to make calls.
WO 95/11576 PCT/US94/11906
21 ~ 46Z5
12
However, when the subscriber "roams" outside the system's
service area, other switches associated with another
telecommunication system must be utilized. Generally, this
embodiment includes an interface for receiving a pre-call
validation request associated with a particular subscriber;
a detector for using a switch identification number to
identify potentially fraudulent telecommunication activity;
and an output device for communicating the occurrence of
such activity. In one embodiment, the detector compares the
switch identification number in the pre-call validation
request to a predetermined list of switch identification
numbers suspected of frequently being used by fraudulent
users. In another embodiment, the detector compares the
switch identification number in the pre-call validation
request against a list of switch identification numbers
associated with geographic areas previously utilized by the
subscriber. If the pre-call validation requests indicate
that roaming is occurring in new geographic areas, then a
deviation from the subscriber's normal roaming pattern is
occurring that is indicative of potentially fraudulent
telecommunication activity.
Yet another embodiment of the present invention uses
the pre-call validation requests to determine if the
roaming associated with a subscriber is of an unusually
long duration. Generally, this embodiment includes an
interface for receiving pre-call validation requests
associated with a particular subscriber; a detector for
determining if the requests associated with the subscriber
WO 95/11576 217 4 ~ ~ ~ PCT/US94/11906
13
indicate an unusually long period of roaming indicative of
potentially fraudulent telecommunication activity; and an
output device for communicating the occurrences of such
activity.
Another embodiment of the present invention uses the
velocity of pre-call validation requests, i.e., the number
of pre-call validation requests per unit of time, for a
particular subscriber to detect potentially fraudulent
telecommunication activity. A deviation in the velocity of
pre-call validation requests associated with a subscriber
or an excessive number of pre-call validation requests
associated with the subscriber over a predetermined time
period are indications that potentially fraudulent
telecommunication activity is occurring. Generally, this
embodiment includes an interface for receiving
substantially every pre-call validation request associated
with a particular subscriber; a device for comparing the
velocity of pre-call validation requests associated with
the particular subscriber to a threshold to identify
potentially fraudulent telecommunication activity; and an
output device for communicating the occurrence of such
activity. In one embodiment, the number of pre-call
validation requests associated with a particular subscriber
in the course of an hour is compared to a predetermined
amount to determine whether excessive use indicative of
potentially fraudulent activity is occurring. In another
embodiment, the number of pre-call validation requests
associated with a particular subscriber in the course of a
WO 95/11576 PCT/US94/11906
217~~?5
14
day is compared to a predetermined amount to determine
whether excessive use indicative of potentially fraudulent
activity is occurring. In a further embodiment, the number
of pre-call validation requests associated with a
particular subscriber in the course of a day is compared to
a historical daily maximum for the particular user to
identify excessive use indicative of potentially fraudulent
telecommunication activity. In yet another embodiment, the
number of pre-call validation requests associated with a
particular subscriber in the course of a day is compared to
a moving daily average to determine if the subscriber is
exceeding typical usage.
It is also an object of the present invention to
provide a-method and apparatus to control or limit the risk
of non-payment by a subscriber, whether such non-payment is
associated with fraudulent activity or not. It is a further
object to encourage subscribers that are able to pay to use
the system. One embodiment of the invention includes an
interface for communicating credit information on a
particular subscriber with a credit bureau, which could be
a traditional credit bureau or the carrier. Based upon the
credit information, a credit limit for the subscriber is
established by the apparatus. The interface also receives
call records that are associated with the particular
subscriber and are derived from a telecommunication switch,
i.e., a device for establishing connections between
telecommunication devices. An analysis device is also
provided to compare the subscriber's call usage to a credit
WO 95/11576
217 4 ~~ ? ~ PCT/US94/11906
limit established for the subscriber based upon the credit
information obtained from the credit bureau. If the
subscriber has exceeded their credit limit the apparatus
utilizes an output device to indicate so to an operator or
5 another device. Consequently, the carrier can limit risk
of non-payment on a per subscriber basis and, conversely,
encourage system usage and, as a consequence, revenue on a
per subscriber basis with respect to those subscribers that
are more able or likely to pay for the service.
10 In another embodiment, the apparatus updates the
subscriber's credit limit by obtaining an updated credit
report or score for the subscriber from the credit bureau.
Consequently, the subscriber's credit limit can be lowered
or the subscriber's deposit requirement can be increased if
15 the subscriber is becoming a greater credit risk, thereby
limiting or reducing the risk of non-payment to the
carrier. Conversely, the subscriber's credit limit can be
increased or the deposit requirement decreased if the
subscriber is becoming a lower credit risk, thereby
encouraging the subscriber to further utilize the system.
In yet a further embodiment, the apparatus is capable
of adjusting the predetermined time interval for updating
a subscriber's credit limit. Consequently, the apparatus
attempts to optimize or reduce the costs associated with
obtaining credit reports or scores on subscribers. This is
especially important in systems with large numbers of
subscribers.
15a
In another aspect of the present invention, there is
provided an apparatus for allowing a telecommunication service
provider, who provides a plurality of subscribers with the
ability to contact other subscribers of the telecommunication
service provider and subscribers of a different
telecommunication service provider, to detect potentially
fraudulent telecommunication activity, comprising a digital
computer, interface means, operating within said digital
computer, for receiving a call information record for
substantially each call involving the use of a telecommunication
device associated with a particular subscriber, wherein
association of a telecommunication device with the particular
subscriber can be in the form of a telecommunication device
associated with a fraudulent user that appears to be the
particular subscriber. The interface means include means for
receiving call information records derived from a wireless home
switching center of the telecommunication service provider that
provides the particular subscriber with the ability to
communicate with other telecommunication devices while the
particular subscriber is located in a first geographical region.
The interface means also includes means for receiving call
information records from a wireless roamer switching center of
the same or a different telecommunication service provider that
provides the particular subscriber with the ability to
communicate with other telecommunication devices while the
particular subscriber is located in a second geographical region
that is different than the first geographical region. The
apparatus also comprises analysis means, operating within the
digital computer, for receiving call information records from
the interface means and using the call information records in
analyzing call usage associated with the particular subscriber,
the analysis means applying a set of predetermined rules when
1E3117107.DOC;1 } 15/114821.2
CA 02174625 2003-11-27
15b
analyzing the call usage to identify one of a plurality of
available alert states indicative of a severity of potentially
fraudulent call activity, and, display means, operating with the
digital computer, for displaying an indication of said
potentially fraudulent call activity, wherein the display means
includes displaying at least some of the information generated
during the analysis that identified said potentially fraudulent
call activity so an assessment of potentially fraudulent call
activity can be made, and wherein the information includes
identifying the type of potentially fraudulent telecommunication
activity as at least one of: a velocity event, a duration event,
a velocity threshold event, a suspect number event, a suspect
country event, a credit event, and an overlap calls event.
In another aspect of the present invention, there is
provided an apparatus for allowing a telecommunication service
provider, who provides a plurality of subscribers with the
ability to contact other subscribers of the telecommunication
service provider as well as subscribers of a different
telecommunication service provider, to detect potentially
fraudulent telecommunication activity, comprising a digital
computer, interface means, operating within the digital
computer, for receiving a call information record for a wireless
public switch, wherein the wireless public switch establishes
connections between telecommunication devices, for substantially
each call initiated by the use of a telecommunication device
associated with a particular subscriber, wherein association of
a telecommunication device with the particular subscriber can be
in the form of a telecommunication device associated with the
particular subscriber or a telecommunication device associated
with a fraudulent user that appears to be the particular
subscriber. The apparatus also comprises analysis means,
operating within the digital computer, for receiving call
{E3117107.DOC;1}
CA 02174625 2003-11-27
15c
information records from the interface means and using the call
information records in analyzing the particular subscriber's
call usage, the analysis means applying a set of predetermined
rules when analyzing the call usage to identify one of a
plurality of available alert states indicative of a severity of
potentially fraudulent telecommunication activity, and, display
means, operating with the digital computer, for displaying an
indication of said potentially fraudulent call activity, wherein
the display means includes displaying at least some of the
information generated during the analysis that identified the
potentially fraudulent call activity so an assessment of
potentially fraudulent call activity can be made, and wherein
the information includes identifying the type of potentially
fraudulent telecommunication activity as at least one of: a
velocity event, a duration event, a velocity threshold event, a
suspect number event, a suspect country event, a credit event,
and an overlap calls event.
In yet another aspect of the present invention, there is
provided a method of detecting potentially fraudulent
telecommunication activity, the method comprising accessing call
information associated with a subscriber, computing a first
mufti-day average of call usage associated with the subscriber
from the call information, computing a second mufti-day average
of call usage associated with the subscriber from the call
information, the first and second mufti-day averages being based
on a different number of days, computing a percentage change
between the first and second mufti-day averages, and comparing
the percentage change to a predetermined limit to detect
potentially fraudulent telecommunication activity.
In a further aspect of the present invention, there is
provided a method, comprising communicating with a credit
information source to obtain a credit score associated with a
(E3117107.DOC;1}
CA 02174625 2003-11-27
15d
particular telecommunications subscriber, using the credit score
to establish a credit limit for the particular
telecommunications subscriber, receiving a call information
record for calls involving the particular telecommunications
subscriber, using the call information record to compare call
usage of the particular telecommunications subscriber to the
credit limit, and, generating an indication based on whether the
call usage exceeds the credit limit.
In another aspect of the present invention, there is
provided a computer product disposed on a computer readable
medium, the computer product having instructions for causing a
processor to communicate with a credit information source to
obtain a credit score associated with a particular
telecommunications subscriber, use the credit score to establish
a credit limit for the particular telecommunications subscriber,
receive a call information record for calls involving the
particular telecommunications subscriber, use the call
information record to compare call usage of the particular
telecommunications subscriber to the credit limit, and, generate
an indication based on whether the call usage exceeds the credit
limit.
{E3117107.DOC;1}
WO 95/11576 PCT/US94/11906
2174625
16
These and other features of the present invention will
become evident from the detailed description set forth
hereafter with reference to the accompanying drawings.
Brief Description of Drawings
A more complete understanding of the invention can be
had by referring to the detailed description of the
invention and the drawings in which:
FIG. lA is a diagram illustrating a typical cellular
telecommunications network.
FIG. 1B is a schematic illustration of a cellular
telecommunication network that employs a home location and
visitor location registers in addition to a fraud
management system.
FIG. 1C is a block diagram of a telecommunications
fraud detection system according to one embodiment of the
present invention that includes a credit risk manager.
FIG. 1D is a flowchart that illustrates the operation
of the credit risk manager shown in FIG. 1C.
FIG. lE is a block diagram illustrating pre-call
communications between a fraud detection system in
accordance with the present invention and a remote MSC.
FIG. 2A is a block diagram showing the components of
a Common Call Format (CCF) record according to one
embodiment of the present invention.
FIG. 2B is a block design showing the components of a
Common Pre-call Format (CPF) record according to one
embodiment of the present invention.
WO 95/11576 2 ~ / ~. ~~ 2 5 PCT/US94/11906
17
FIGS. 3A-3U are flowcharts of the Event Manager
procedure.
FIGS. 4A-4T are flowcharts of the Alert Manager
procedure.
FIGS. 5A-5C are flowcharts of the User Interface
procedure.
FIG. 6 is a screen display of the Login Window of the
User Interface in one embodiment of the present invention.
FIG. 7 is a screen display of the Control Window of
the User Interface in one embodiment of the present
invention.
FIG. 8 is a screen display of the Investigate
Subscriber Window of the User Interface in one embodiment
of the present invention.
FIG. 9 is a graph showing call velocity fluctuations
for a typical cloning fraud user.
FIG. 10 is a screen display of the Monitor New SID(s)
Window of the User Interface in one embodiment of the
present invention.
FIG. 11 is a screen display of the Monitor Alerts
Window of the User Interface in one embodiment of the
present invention.
Detailed Description of the Invention
A detailed description of an apparatus and method for
detecting potentially fraudulent roaming telecommunication
activity and performing credit based management of
telecommunications activity, is set forth below with
WO 95/11576 PCT/US94/11906
18
reference to the figures. Although the method and apparatus
will be described particularly with reference to cellular
telephone networks, it will be understood that the
invention is equally applicable in other telecommunication
contexts including, but not limited to, personal
communication service (PCS) networks.
A diagram illustrating a typical cellular
telecommunications network is illustrated in FIG. lA.
Referring to FIG. 1A, each predetermined fixed geographic
region is served by a separate Mobile Switching Center
(MSC). Additionally, each MSC region may comprise one or
more cells, wherein each cell is served by its own base
station connected to the MSC for that region. In FIG. lA,
Region I is served by a first MSC 101 while Region II is
served by a second MSC 102. Region I comprises four cells
each having its own base station 104 connected to the first
MSC 101. Region II comprises three cells each having its
own base station 106 connected to the second MSC 102.
One function of a MSC is to receive and route both
cellular originated calls and cellular terminated calls.
A cellular originated call is one placed by a cellular
telephone located within the MSC serving area to either
another cellular telephone or a physical line telephone.
A cellular terminated call is one received by a cellular
telephone located within the MSC serving area, regardless
if placed by a cellular or physical line telephone.
The MSC which serves the geographic region in which a
subscriber is based is considered a subscriber's "home"
WO 95/11576 217 4 6 2 5 pCT~S94/11906
19
MSC. For example, MSC 101 would be the home MSC for a
subscriber based in Region I. Similarly, MSC 102 would be
the home MSC for a subscriber based in Region II. In
addition to routing calls, each MSC is ultimately
responsible for monitoring its home subscriber's usage.
When a subscriber originates a call, the cellular
telephone 103 communicates via a base station with the
particular MSC serving that geographic region by means of
wireless radiofrequency transmission. The subscriber may
either remain within the particular cell from which the
call was originated or the subscriber may roam across cell
and MSC region boundaries. For example, a cellular call may
be originated by a subscriber in Cell A and the call would
be handled initially by the first MSC 101. However, because
cellular telephones are mobile, the subscriber could travel
from Cell A into Cell B during the course of the call. Upon
crossing from Cell A into Cell B, the call would cease
being handled by the first MSC 101 and may be picked up
mid-call and handled by the second MSC 102.
Multiple MSCs are dispersed throughout the United
States, and much of the world, so that a subscriber may
call from any geographic region served by a MSC. All of
the various MSCs around the world are interconnected by a
global telecommunications network, so that
telecommunications may occur between two cellular
telephones, or between a cellular telephone and a physical
line telephone, even if they are in different geographic
regions.
WO 95/11576 PCT/US94/11906
~ 74625
The function of a MSC is to receive and route both
cellular originated calls and cellular terminated calls.
A cellular originated call is one placed by a cellular
telephone located within the MSC serving area to either
another cellular telephone or a physical line telephone.
A cellular terminated call is one received by a cellular
telephone located within the MSC serving area, regardless
if placed by a cellular or physical line telephone.
Each subscriber's cellular telephone has its own
unique ID corresponding to a set of identification numbers.
The identification numbers comprise two individual
identifiers -- a Mobile Identification Number (MIN), and
(2) a Mobile Serial Number (MSN) also referred to as an
Electronic Serial Number (ESN). The MSN/ESN is a unique
serial number associated with the cellular telephone. The
MIN is a ten-digit number, corresponding to the ten-digit
telephone number used in North America, having the format
npa-nxx-xxxx, where npa corresponds to the first three
digits in the area code in North America, nxx corresponds
to the next three digits which identify the serving switch
in North America, and xxxx corresponds to the last four
digits which identify the individual subscriber or physical
line number. It will be appreciated by one of ordinary
skill in the art that the format of the MIN may change
based upon particular requirements. For example, the MIN
may be modified to include a code which identifies the
country in which the subscriber resides. The combination of
the npa and nxx components form a number which identifies
WO 95/11576 217 4 ~ ? 5 PCT/US94l11906
21
a subscriber's "home" MSC. At the initiation of each call,
the cellular telephone transmits to the MSC its unique
combination of MIN and MSN. At the termination of each
call, whether cellular originated or cellular terminated,
each MSC handling the call creates a separate Call Detail
Record (CDR) which contains several items of information
describing the call and the subscriber. For example, the
CDR contains the following call information items: MIN,
MSN, number called, call duration, call origination date
and time, country called, information identif~.~ing the MSC,
etc. The format of the CDR, however, is not consistent
among the several different providers of cellular telephone
service. At present, for example, at least five different
CDR formats exist.
As mentioned above, each individual subscriber has a
home MSC identified by the combination of the npa and nxx
components of the subscriber's MIN. Unless a cellular
subscriber has previously notified the home MSC of his or
her whereabouts, the subscriber may only receive a cellular
terminated call when that subscriber is within his or her
home MSC region. In most cases, a subscriber may initiate
a cellular originated call, however, from any MSC region
without any special proactive requirements.
A subscriber who engages in telecommunication activity
from a region other than his or her home MSC region is
referred to as a "roamer." For example, a subscriber based
in Region I who originates a call from Region II would be
considered a roaming subscriber in Region II. In current
WO 95/11576 PCT/US94/11906
22
practice, when a roaming subscriber places a call, the
visited MSC incurs charges for the call. These charges are
then billed back to the user's home MSC which, in turn,
bills the user. Because only the subscriber's home MSC
maintains a database of that subscriber's identity and
usage data, a MSC handling a roamer call is unable to
independently detect potentially fraudulent
telecommunication activity. For example, if a subscriber's
ID has been successfully cloned, the visited MSC is unable
to independently determine whether the call is being placed
fraudulently. Therefore, it is desirable to allow a MSC
handling a roamer call to communicate with the home MSC to
validate the particular call.
FIG. 1B depicts a system whereby separate MSCs
communicate to detect potentially fraudulent roaming
telecommunication activity. In the description of FIG. iB,
it is presumed that the MSC for Region I corresponds to a
subscriber's home MSC 101 and the MSC 102 for Region II is
a visited MSC. As illustrated in FIG. 1B, when a roaming
subscriber attempts to place a call in Region II, the
user's cellular telephone communicates with the visited MSC
102. The visited MSC 102, upon determining that the
attempted call is being placed by a roamer, communicates
pre-call information to Visitor Location Register (VLR)
130. VLR 130 uses the pre-call information to contact a
Home Location Register (HLR) 142 associated with the
subscriber's home MSC 101. The subscriber's home HLR 142
acts as an interface to receive information from the VLR
WO 95/11576 PCT/US94/11906
21 ? ~a X25
23
130 and to pass the information on to a Fraud Management
System (FMS) 144 associated with the particular
subscriber's home MSC 101. The FMS 144 may then use the
information to detect potentially fraudulent tele-
communication activity. Substantially the same procedure
occurs when a user roaming outside his or her home region
turns the power to his or her cellular telephone on, or
when a user crosses system or cell boundaries with the
power on, or during an intermittent polling procedure
initiated by the visited MSC 102.
In one embodiment of the present invention, the
HLR/VLR interface is communicates pursuant to an industry
standard, the IS-41 standard. The IS-41 standard defines,
among other things, the format of messages transmitted
across the HLR/VLR interface between two MSCs. This format
will be referred to as the IS-41 format. It should be
appreciated, however, that the present invention is not
limited to an architecture defined by the IS-41 standard
and could be implemented using a different standard,
including a proprietary standard. Additionally, referring
again to FIG. lA, for each roamer call completed by a MSC,
the MSC records CDR information for that call and sends the
information to a clearing house. The clearing house
collects all CDRs pertaining to a particular MSC, creates
a magnetic tape -- a roamer tape -- containing multiple
CDRs, and sends the tape to the appropriate home carrier.
Alternatively, the CDR information can be sent to the home
carrier electronically.
WO 95/11576 PCT/US94/11906
2 ~ 74625
24
FIG. lE illustrates pre-call communications across an
HLR/VLR interface in accordance with one embodiment of the
present invention. As illustrated in FIG. 1E, when a
'roaming' call is initiated, the visited MSC 102 generates
a Registration Notification (REGNOT) message which,
pursuant to the IS-41 standard, is passed to the VLR 130
associated with the visited MSC 102. The VLR 130 forwards
the REGNOT message to the HLR 142 associated with the
user's home MSC 101. In accordance with the IS-41 standard,
the HLR 142 receives the REGNOT and passes it to the fraud
management system 144 associated with the subscriber's home
MSC 101. The fraud management system 144 utilizes portions
of the REGNOT to determine whether the particular
subscriber's current usage is indicative of potentially
fraudulent telecommunication activity. The fraud management
system 144 may then communicate a response to the HLR 142
which indicates whether the particular subscriber's current
usage is indicative of potentially fraudulent
telecommunication activity. This response may then be
transmitted to the visited MSC 102 via the HLR/VLR
interface.
FIG. iC is a block diagram of a telecommunications
fraud detection system according to one embodiment of the
present invention. Initially, a general description of the
fraud detection system 107 is provided as follows.
The fraud detection system 107 of the present
invention, comprising the switch interface 111, the IS-41
interface 112, the event manager 113, the alert manager
217 ~=~25
WO 95/11576 PCT/US94/11906
115, the credit risk manager 131, the credit interface 133,
and the user interface 117, is implemented, in one
embodiment, as software running on a digital computer, for
example, a Sun Microsystems workstation. The digital
5 computer includes memory means for storing computer
programs and data; processing means for running computer
programs and manipulating data; and input/output means for
communicating with a MSC, a system operator, a magnetic
tape drive (not shown), or another computer (not shown).
10 CDR records for both cellular originated and cellular
terminated calls fed into a switch interface 111 both from
the MSC 101 directly and from a roamer tape 109. After the
switch interface 111 translates a CDR record into a format
understandable to the fraud detection system 107 -- the CCF
15 format -- a CCF record is passed to the event manager 113.
Additionally, the IS-41 interface receives pre-call
validation request messages from a VLR associated with a
visitor MSC and translates the messages from the IS-41
format into one format understandable to the fraud
20 detection system 107--the CPF format--and then passes the
CPF record to the event manager 113. The function of the
event manager 113 is to perform a number of checks to
compare the present CCF record or CPF record both with past
subscriber-specific usage information and with certain
25 predetermined conditions to determine whether this
particular CCF record or CPF record should trigger the
event manager 113 to generate an "event." If an event is
generated by the event manager 113 it is logged to a
WO 95/11576 PCT/US94/11906
274625
26
database -- the "events database" -- containing past events
specific to each subscriber and passed to the alert manager
115. Depending on the nature and quantity of past events
for a particular subscriber, a newly received event may
cause the alert manager 115 to generate an "alert" for the
particular subscriber ID in question. Each of the alerts
generated is stored in a database -- the "alerts database"
-- specific to each subscriber. Depending upon a
predetermined set of rules, either a single alert or a
specific combination of alerts may generate an "alert-
state" which is passed to the user interface 117 to signal
the system operator 119 that the particular subscriber ID
for which the alert-state was generated is suspected of
being used fraudulently. Each of the alert-states generated
is stored in a database -- the "alert-states database" --
specific to each subscriber. The system operator 119 may
then investigate a subscriber ID for which an alert-state
was generated by looking at subscriber-specific data, a
graph of the particular subscriber's call velocity for a
given time period, and the history of alerts and events
which eventually triggered the alert-state in question.
Once the system operator "clears" an alert it will no
longer be considered in determining whether an alert-state
should be generated for a particular subscriber ID.
Referring to FIG. 1C, a more detailed description of
the fraud detection system 107 is provided as follows.
When a cellular telephone 103 is located in its "home" MSC,
cellular telephone 103 communicates with a MSC 101 to place
WO 95/11576 PCT/US94/11906
217625
27
a call either to a physical line telephone 105 or to
another cellular telephone. Additionally, the cellular
telephone 103 may receive a call originated by either a
physical line telephone 105 or another cellular telephone.
Upon termination of the call, the MSC 101 creates a
separate CDR record for each call that it handles, whether
cellular originated or cellular terminated. MSC 101 is
connected to a fraud detection system 107 which receives
CDR records as input from MSC 101. The CDR input read
directly from the MSC 101 into the fraud detection system
107 corresponds to calls handled by MSC 101 for its home
subscribers. CDR records not involving MSC101's home
subscribers are sent to a clearing house to generate roamer
tapes to be sent to the appropriate home MSC or are
electronically transmitted to the appropriate home MSC, as
discussed above.
Alternatively, if the fraud detection system 107 was
interconnected to one or more "peer" fraud detection
systems, i.e., a separate system serving a different MSC,
after the switch interface 111 had converted the CDR
records into CCF format, the fraud detection system 107
would send those CCF records corresponding to roamer calls
to the appropriate peer fraud detection system
corresponding to the respective home MSC of each roamer
call.
The fraud detection system 107 may also receive input
from a roamer tape 109 by means of a magnetic tape reader
(not shown). The input may be stored in a format referred
WO 95111576 PCT/US94/11906
c 17=~ E~2
28
to as the CIBER format, or may be stored in other formats.
Additionally, the fraud detection system 107 may receive
input from one or more visited MSCs by means of the HLR/VLR
interface described with reference to FIG. iB and from
other IS-41 or other electronic data sources. The
combination of the home MSC 101 input, the roamer tape 109,
and the HLR/VLR input represents substantially all of the
call activity for a MSC's home subscribers, regardless of
the geographic region in which the calls were originated or
terminated.
Call information input, from the roamer tape 109 and
from the home MSC 101, or from other sources is fed into
the switch interface 111 of the fraud detection system 107.
The function of the switch interface 111 is to translate
the various CIBER and CDR input formats into a consistent
format -- the Common Call Format (CCF). The switch
interface 111 is capable of accepting CDR input in any of
the existing formats, and is easily adaptable to new CDR
formats created in the future. Typically, a CCF record
contains only a subset of the total information contained
in a CDR. This subset of information corresponds to those
information items used during operation of the fraud
detection system 107.
Call information input from the HLR/VLR interface is
fed into the IS-41 interface 112 of the fraud detection
system. The function of the IS-41 interface is to translate
the information from the IS-41 format into a format
understandable by the event manager--the CPF format.
WO 95111576 ~ ~ ? Lr ~ ~ J PCT/US94/11906
29
The credit risk manager 131 allows a carrier to manage
the amount of credit which is extended to a particular
subscriber in the form of available calling time and to
identify credit trends with respect to the particular
subscriber. A credit interface 133 is interposed between
a credit bureau 135 and the credit risk manager 131 to
translate requests to the credit bureau 135 for credit
information into a format understandable to the credit
bureau 135 and to translate credit information from the
credit bureau 135 into an understandable format. The
credit bureau can be any source of credit information. For
example, the credit bureau 135 can be a dedicated credit
bureau, a billing system or the carrier with which the
subscriber is associated. Credit information in the form of
"credit scores" is available from a variety of providers.
A single credit score may comprise a single element, such
as a number representing credit risk, or may be comprised
of a plurality of elements, such as credit risk,
probability of delinquency, and probability of bankruptcy.
After a credit score is obtained, it is stored in a credit
scores database which is maintained by the fraud detection
system.
While the credit interface 133 is shown as being
directly connected to the credit bureau 135, it should be
appreciated that other communication paths are possible.
For example, the credit interface 133 could communicate
with the credit bureau via the mobile switching center 101
or another switching center. With respect to each
WO 95/11576 PCT/US94/11906
~~~ 1~.61'~
subscriber, identification information is initially
provided by the carrier and a record created in a credit
scores database. If known by the telecommunications service
provider or carrier, an initial credit score for the
5 customer is entered in the credit scores database. If the
initial credit score is not known, an initial credit score
may be obtained from the credit bureau and stored in the
credit scores database. Other initial parameters which are
set are the initial credit limit and the time period for
10 credit update.
In operation, the credit risk manager 131 periodically
obtains updated credit scores from a credit bureau for each
subscriber and determines whether the credit risk
associated with each subscriber has changed. If the risk
15 has changed, the credit risk manager may adjust the credit
limit being provided to the subscriber accordingly and/or
initiate other activity, such as causing an alert to be
generated, notifying the telecommunications services
provider or carrier of the change, or adjusting the time
20 period for updating the credit scores of a subscriber.
FIG. 1D illustrates one embodiment of the present
invention wherein the credit risk manager 131 checks each
day (or some other predetermined period) whether the time
period for updating a subscriber's credit scores has
25 elapsed and performs a credit update if the previously
established time period has passed. First, at step S150,
the service tests whether this particular subscriber has an
entry in the credit scores database. If a credit score is
217-625
WO 95/11576 PCT/~JS94/11906
31
not found, an inconsistency in the system has been
encountered; an error is logged to an error handling server
and the service flows to step S180 which marks the
completion of the credit risk check.
If a credit score entry is found for this particular
subscriber, the date of the entry is compared to the
present date at step S152. Next, at step S154, the service
tests whether the time period between the date of the entry
and the present date exceeds a previously established time
period for updating the subscriber's credit score. If the
period has not been exceeded, the service flows to step
5180 which marks the completion of the credit risk check.
If the period has been exceeded, the service flows to step
S156 where a current credit score for the subscriber is
obtained from the credit bureau. Next, at step S158, the
current credit score is added to the credit scores
database.
Next, at Step 160, the current credit score is
compared to the most recent previous credit score entry in
the credit scores database. If the comparison shows a
decrease in the credit risk, the service flows to step S162
where an increase in the credit limit reflecting the
decreased risk is calculated. By increasing the
subscriber's credit limit, the subscriber is encouraged to
make further use of the system, which increases carrier
revenues if an increase does occur while at the same time
limiting or managing the risk associated with the increased
credit limit. If the comparison shows an increase in the
WO 95/11576 PCT/US94/11906
2 i 74625
32
credit risk, the service flows to step 5164 where a
decrease in the credit limit reflecting the increased risk
is calculated. By decreasing the subscriber's credit limit,
the risk of non-payment to the carrier is reduced. If there
is no difference in the current and previous credit scores,
the service flows to step S180 which marks the completion
of the credit risk check. Next, the service flows to step
5166 where the updated credit limit is calculated. Next, at
step S168, the updated credit limit is sent to the event
manager 113, where it is used in the Check Credit Limit
service, as discussed below.
Next, the service flows to step 5170, where the
current credit score is compared to the prior credit score
entries in the credit risk database to determine if a trend
of increasing risk is present. (It should be appreciated
that other credit score trends may be of value, such as
those that indicate the subscriber is a relatively constant
or decreasing credit risk.) If a trend of increasing risk
is present, the service flows to step 5172 where a "credit
risk event" is generated by recording the event type,
"credit risk event," along with specific information
particular to this subscriber in the events database for
this particular subscriber ID.
Next, at step S174, the "event context" data structure
is built with information specific to this event. The event
context data structure contains information including (1)
the event type ("credit risk event"); (2) the subscriber
identification information; (3) the event date and (4) the
WO 95/11576 ~ PCT/US94/11906
33
current alert-state (either normal, yellow, or red
depending on the nature and quantity of alerts outstanding
for this particular subscriber as determined by the alert
manager, discussed below).
Next, at step 5176, the service sends the event
context data structure previously built at step S174 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S180, where the
credit risk check is completed.
The determination of whether the credit risk has
increased or decreased may take a variety of forms. The
determination may involve comparison of a single element of
each credit score, or may involve comparison of some or all
of several elements comprising a credit score. Similarly,
the calculation of an updated credit limit in steps S162
and 5164 may take a variety of forms. By way of
illustration, the updated credit limit may be calculated as
2o a percentage increase upon the previous credit limit, or
the calculation steps may simply generate a number of units
to be added to or subtracted from the previous credit limit
to create the updated credit limit.
Although one embodiment of the above-described credit
risk check performs the check at fixed intervals
established by a predetermined time period, in another
embodiment, the time period between checks may be modified
in response to changes in the credit score. For example,
WO 95/11576 PCT/US94/11906
2174625
34
the time period may be shortened to generate more frequent
checks if the credit risk has increased. Conversely, the
time period may be lengthened if the credit risk has
decreased. Further, if the time period for updating the
credit scores associated with a number of subscribers is
substantially the same, the dates from which the time
period extends so as to spread out the costs associated
with obtaining credit scores.
Additional information relating to the credit status
of the customer may also be used by the credit risk manager
to adjust credit extended to the customer and in evaluating
the credit risk. In another embodiment of the invention,
data concerning the customer's billing and payment history
may be obtained through an interface between a billing and
payment records database and the credit risk manager. This
data may be used in conjunction with, or as a replacement
for, the credit score data used in the embodiment
illustrated in FIG. iC.
Alternatively, in another embodiment of the present
invention, the fraud detection system 107 may receive input
from a telecommunications system other than a cellular
telephone MSC. For example, the fraud detection system may
receive input from a calling card system to detect calling
card fraud merely by modifying the switch interface 111 to
accept the data format specific to the calling card system
used.
FIG. 2A illustrates one embodiment of the present
invention wherein the CCF Record 201 comprises sixteen
WO 95/11576 ,
PCT/US94/11906
separate fields, numbered 203 through 233. The combination
of the npa field 203, the nxx field 205, and the xxxx field
207 comprise the subscriber's ten-digit telephone number,
or MIN, as discussed above. The switch interface 111
5 separates the MIN into three components so that each may be
separately accessed with ease.
The MSN field 209 holds the subscriber Mobile Serial
Number (MSN) which, as discussed above, is transmitted
along with the MIN by the cellular telephone 103 to the MSC
10 101 with each cellular originated call.
The call type field 211 holds a value of °0" if this
call was cellular originated or a value of "1" if this call
was cellular terminated.
The answer status f field 213 holds a value of "0" if
15 this call was not answered by the party called or a value
of "1" if the call was answered.
The called number field 215 holds the number dialed by
the cellular subscriber for this call.
The country code field 217 holds a number
20 corresponding to a unique code for the particular country
called by the cellular subscriber for this call.
The roamer status field 219 holds a "TRUE" state if
the subscriber was a "roamer" when the call was originated,
that is, the subscriber placed the call through a MSC other
25 than his or her home MSC, or a "FALSE" state if the
subscriber placed the call from his or her home MSC.
The sid field 221 holds a switch identifier number
identifying the serving MSC that generated the present CDR
WO 95/11576 PCT/US94/11906
36
record for this call. Because a subscriber may move between
different MSC regions during the course of a single
cellular call, multiple MSCs may handle a single call in
successive fashion as the subscriber roams between MSC
regions. Accordingly, multiple CDR records may be generated
for a single call -- one for each MSC that handled the
call. The sid field 221 identifies the MSC that generated
this particular CDR, even if it was not the MSC on which
the call originated.
The first serving MSC field 223 and the first serving
cell field 225 identify the specific MSC and cell,
respectively, on which the call originated. As discussed
above, both the cell and the MSC which handle a call may
change as the subscriber roams across cell and MSC region
boundaries. Although each MSC which handles a call will
generate a separate CDR having its own switch number in the
sid field 221, the first serving MSC field 223 and the
first serving cell field 225 will remain constant for all
CDR records pertaining to a single call.
The orig time field 227 and the orig date field 229
hold the time and date, respectively, at which the present
call was originated.
The call feature field 231 holds information
indicating whether this call utilized a call feature, such
as call waiting, call forwarding, or three-way calling.
Lastly, the call seconds field 233 holds the duration
of the present call in seconds.
WO 95/11576 217 4 ~~ 2 5 PCT/US94/11906
37
FIG. 2B illustrates one embodiment of the present
invention wherein the CPF record 240 comprises seven
separate fields, numbered 242 through 254. The combination
of the npa field 242, the nxx field 244, and the xxxx field
246 comprise the subscriber's ten-digit telephone number,
or MIN, as discussed above.
The ESN field 248 holds the Electronic Serial Number
(also referred to as Mobile Serial Number) which, as
discussed above, is transmitted along with the MIN by
cellular telephone 103 to the MSC 101 with each cellular
originated call.
The sidbid field 250 holds a number which is
indicative of the switch utilized to place a roaming call.
The pcval-datetime field 252 holds the date and time
at which the present validation request was initiated.
The authorization period field 254 holds an indicator
which determines how frequently the subscriber must re-
register. Possible authorization periods include, without
limitation, every call, once per hour, or once per day.
Referring again to FIG. 1C, once the switch interface
111 has translated the CDR or CIBER format input into a CCF
record, it passes the CCF record to the event manager 113.
Similarly, once the IS-41 interface has translated the IS-
41 format into a CPF record it passes the CPF record to the
event manager. The event manager 113 procedure is
illustrated by a flowchart in FIG. 3A. The function of the
event manager is to perform a number of checks to compare
a present CCF record or CPF record both with past
WO 95/11576 PCT/US94/11906
2 ~ ?~-~~2~ 38
subscriber-specific usage information and with certain
predetermined conditions to detenaine whether this
particular CCF record or CPF record should trigger an
"event."
Referring to FIG. 3A, the services indicated by steps
S303 through S309 and S310 through S316 are referred to as
"call event" checks. In the call event checks a CCF or CPF
record is compared to a set of predetermined conditions to
determine whether or not an event should be generated for
to this CCF or CPF record. Call events are further broken down
into the following event types: number events, country
events, credit events, and overlap events. Additionally,
overlap events have two event subtypes: geographic
dispersion and simultaneous calls on validation requests.
The services indicated by steps S311 through S321 and
318 are referred to as "pattern event" checks. In the
pattern event checks the CCF or CPF record is used to
update a plurality of previously compiled subscriber-
specific usage patterns which define a particular
subscriber's typical usage. Each CCF or CPF record
received by the event manager is used to update and
maintain an individual usage pattern for the particular
subscriber to which the CCF or CPF record pertains. In
pattern event checks, the event manager will generate an
event when the present CCF or CPF record, when used to
update the subscriber-specific usage pattern, causes the
subscriber's usage pattern to indicate a trend of abnormal
usage suggestive of fraudulent telecommunications activity.
274625
WO 95/11576 PCT/US94/11906
39
Pattern events are further broken down into the following
event types: average events and threshold events.
Additionally, average events have the following four
subtypes: velocity, international velocity, duration, and
international duration. Threshold events have the following
seven subtypes: hourly velocity, daily velocity, daily
international velocity, five-day average velocity, five-day
average international velocity, ten-day average velocity,
and ten-day average international velocity.
The event manager procedure initiates at step S300
when the event manager 113 receives a CCF record from the
switch interface 111 or a CPF record from the IS-41
interface. At step S304, the event manager determines
whether the record is a CCF record or a CPF record. If the
record is a CCF record, then steps S301-5321 are completed
by the event manager.
At step S301 the event manager parses the CCF record
to place the CCF component fields into appropriate
variables and data structures to be easily accessible by
the event manager services. It should be noted that due to
delays in creating and forwarding roamer tapes to the
appropriate home MSC, a CCF record being processed by the
fraud detection system on a particular day may actually
correspond to a call placed several days earlier.
Therefore, for each of the steps performed by the fraud
detection system, as discussed below, the CCF record is
analyzed based on the day the call was originated, rather
than on the date on which the CCF record is processed by
WO 95/11576 PCT/US94/11906
217~~25
the fraud detection system. For the sake of convenience,
the date on which a call originated will be referred to as
the "call date," while the date on which the CCF record is
processed by the fraud detection system will be referred to
as "today." The date on which a call originated is
determined by the value held by the orig date field 229 of
the CCF record 201. Additionally, the fraud detection
system maintains a database of all CCF records. received
over the past predetermined number of days so that a
delayed CCF record can be analyzed in connection with other
calls placed on the same day. This database is referred to
as the "calls database."
At step S302 the event manager uses the present CCF
record to update the subscriber-specific usage patterns.
Specifically, the event manager calculates new five-day and
ten-day moving averages for each of the call velocity
pattern, the international call velocity pattern, the call
duration pattern, and the international call duration
pattern. A moving average is a technique used in time-
series analysis to smooth a series or to determine a trend
in a series, calculated by the equation:
a
mn - uk
t=n+1-d
d
where mn is the moving average on day n; k is an index
counter; d is the number of days over which the average is
calculated and u, u2, ..., ua are a series of values to be
averaged. For example, assume a series of values over day
3 0 21 to day 2 5 where u21=16 , u2z=9 , u~=12 , u~=8 , and uu=15 . To
WO 95/11576 ;7 ~ ~ ~ PCT/US94/11906
41
calculate a five-day moving average on the 25th day, mu, n
is equal to 25, d is equal to 5, and k takes the successive
values 21, 22, 23, 24, and 25.
Theref ore
m~ - u21 + u22 + u~ + u~ + u~
5
- 16 + 9 + 12 + 8 + 15
_____________________________
5
- 12 .
Five and ten-day moving averages are calculated for each of
the above-listed four patterns in similar fashion. For
example, the five-day moving average call velocity is
calculated by summing the number of calls originated within
the past five days using a particular subscriber ID and
dividing the total by five. Of course, the ten-day averages
are calculated by summing over ten days and dividing by
ten, rather than five. In order to calculate the ten-day
moving average, the fraud detection system saves CCF
records for each particular subscriber for the past eleven
days.
Although this embodiment of the present invention
characterizes subscriber-specific usage patterns by
utilizing two moving averages calculated over five days and
ten days, respectively, it should be noted that an
alternative embodiment may utilize other types of
characterizing schemes, for example a weighted moving
average. Additionally, even if moving averages are
utilized, a different number of moving averages, for
WO 95/11576 PCT/US94/11906
/~ j ~~~~~ 42
example one, three or more, may be used as deemed
effective. Moreover, the moving averages may be calculated
over a number of days different than five and ten, as
desired.
Next, the event manager runs the CCF record through a
series of call event checks and pattern event checks,
represented by steps S303 through 5321. Although one
embodiment of the present invention arranges these checks
in a specific order as illustrated in FIG. 3A, the checks
are substantially order independent and may proceed in any
convenient order.
In the embodiment of the present invention depicted in
FIG. 3A, the event manager performs the checks in the
following order: (1) check suspect tenaination, (2) check
suspect country code, (3) check credit limit, (4) check
overlap calls, (5) check call duration pattern, (6) check
international call duration pattern, (7) check call
thresholds, (8) check international call thresholds, (9)
check call velocity pattern, and (10) check international
call velocity pattern. Each of these checks will be
described in further detail below with reference to FIGS.
3B-3L.
Referring to FIG. 3B, the Check Suspect Termination
service S303 is responsible for determining whether the
number called by the cellular subscriber is suspected of
being called by other fraudulent cellular telephone users.
This service receives the called number field 215 of the
CCF Record 201 as an argument.
WO 95/11576
217 4 6 2 ~ pCT~S94/11906
43
First, at step S325, the service determines whether
the present call was cellular originated by examining the
call type field 211 of the CCF Record 201. Because this
event check is only relevant for cellular originated calls,
if the present call was not cellular originated the service
flows to step S337, which marks the completion of the Check
Suspect Termination service.
If the present call was cellular originated as
determined from the call type field 211, the service, at
step S327, tests whether the number called, held in the
called number field 215, matches a number on a
predetermined list of numbers set by the telecommunication
service provider and maintained in a database by the fraud
detection system 107. If no number on the list is matched
the service flows to step S337 and this check is completed.
If a matching number is found the service, at step
5329, tests whether the matched number from the database
has been flagged as "suspect." If a specified field in the
database of numbers is marked "TRUE," then the matched
number will be determined to be suspect and the service
will flow to step S331. Otherwise, if the specified
database field is not marked "TRUE, " then the service f lows
to step 5337 and the check is completed.
At step S331, it has been determined that a number
called using the particular subscriber ID for this CCF
Record is a number suspected of being called by other
fraudulent users. Accordingly, the service generates a
"suspect termination event" by recording the event type,
WO 95/11576 ~ ~ ~ ~~ PCT/US94/11906
44
"number event," along with specific information particular
to this call in the events database for this particular
subscriber ID.
Next, at step S333, the "event context" data structure
is built with information specific to this event. The event
context data structure contains information including (1)
the event type ("number event"); (2) the event subtype
(none for this event type); (3) the subscriber ID number
(corresponding to the three MIN fields 203, 205, 207 and
the MSN field 209); (4) the call date (from the orig date
field 229); and (5) the current alert-state (either normal,
yellow, or red depending on the nature and quantity of
alerts outstanding for this particular subscriber as
determined by the alert manger, discussed below).
Next, at step S335, the service sends the event
context data structure previously built at step S333 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S337, where the
suspect termination check is completed and the next check
in the event manager procedure is initiated.
Referring to FIG. 3C, the Check Suspect Country Code
service S305 is responsible for determining whether the
country called by the cellular subscriber, as indicated by
the country code, is suspected of being called by other
fraudulent cellular telephone users. This service receives
217-625
WO 95/11576 PCT/US94/11906
the called number field 215 of the CCF Record 201 and its
related country code as arguments.
First, at step 5339, the service determines whether
the present call was cellular originated by examining the
5 call type field 211 of the CCF Record 201. Because this
event check is only relevant for cellular originated calls,
if the present call was not cellular originated the service
flows to step 5351, and the Check Suspect Country Code
service is completed.
10 If the present call was cellular originated as
determined from the call type field 211, the service, at
step 5341, tests whether the country code called matches a
country code on a predetermined list of numbers set by the
telecommunication service provider and maintained in a
15 database by the fraud detection system 107. If no country
code on the list is matched the service flows to step 5351
and this check is completed.
If a matching country code is found the service, at
step S343, tests whether the matched country code from the
20 database has been flagged as "suspect." If a specified
ffield in the database of country codes is marked "TRUE,"
then the country code will be determined to be suspect and
the service will flow to step 5345. Otherwise, if the
specified database field is not marked "TRUE," then the
25 service flows to step S351 and the check is completed.
At step S345, it has been determined that a country
called using the particular subscriber ID for this CCF
Record is a country suspected of being called by other
WO 95/11576 PCT/US94/11906
46
fraudulent users. Accordingly, the service generates a
"suspect country code event" by recording the event type,
"country event," along with specific information particular
to this call in the events database for this particular
subscriber ID.
Next, at step 5347, the event context data structure
is built with information specific to this event, as
discussed above. The event context data structure for this
service has the event type, "country event," and no event
subtype.
Next, at step S349, the service sends the event
context data structure previously built at step 5347 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S351, where the
suspect country code check is completed and the next check
in the event manager procedure is initiated.
Referring to FIG. 3D, the Check Credit Limit service
S307 is responsible for determining whether a particular
subscriber has exceeded his or her specified usage limit by
maintaining a running cumulative total usage duration for
each subscriber and comparing the running total to a
predetermined value set by the telecommunication service
provider. This service receives the call seconds field 233
from the CCF Record 201 as an argument.
First, at step S353, the service tests whether this
particular subscriber has an entry for the present month in
WO 95/11576 ~ ~ ~ ~ ~~ ~ ~ PCT/US94/11906
47
the credit limit database maintained by the fraud detection
system. If a credit limit entry is not found an
inconsistency in the system has been encountered; an error
is logged to an error handling server and the service flows
to step 5367 which initiates a procedure to check the
subscriber's roaming credit limit.
If a credit limit entry is found for this particular
subscriber for the present month, the service flows to step
5357 where the running monthly usage total for this
particular subscriber is updated by adding the usage for
the present call, represented by the value held in the call
seconds field 233, to the previous monthly usage total for
this particular subscriber.
Next, at step S359, the service tests whether the
newly calculated monthly usage total exceeds the
predetermined usage limit set by the credit risk manager
131 for this particular subscriber. If the usage limit has
not been exceeded, the service flows to step S367 which
marks the completion of the credit limit check.
If the predetermined usage limit has been exceeded,
the service flows to step S361 where a "credit limit event"
is generated by recording the event type, "credit event,"
along with specific information particular to this call in
the events database for this particular subscriber ID.
Next, at step S363, the event context data structure
is built with information specific to this event, as
discussed above. The event context data structure for this
WO 95/11576 PCT/US94/11906
2 i 7~'~25
48
service has the event type, "credit event," and no event
subtype.
Next, at step S365, the service sends the event
context data structure previously built at step S365 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Next, the service flows to the Check Roaming Credit
Limit service, which begins at step S367. The Roaming
Credit Limit check is responsible for determining whether
a particular subscriber has exceeded a specified roaming
usage limit by maintaining a running cumulative total usage
duration for each roaming subscriber and comparing the
running total to a predetermined value set by the
telecommunication service provider. Because of the
similarity between the Roaming Credit Limit check and the
Credit Limit Check, it is felt that no further discussion
of the Roaming Credit Limit check is necessary.
Lastly, the service flows to step S368, where the
Roaming Credit Limit check is completed and the next check
in the event manager procedure is initiated.
Although one embodiment of the above-described credit
limit check performs credit checks on the basis of
cumulative call duration in units of time, as an
alternative, the credit limit checks may be performed on
the basis of cumulative money charges, by multiplying the
particular service provider's rate times the cumulative
call duration. It has been determined, however, that using
WO 95/11576 a ~ ~ PCT/US94/11906
49
time units rather than money units to perform the credit
limit checks provides several advantages, including
enhanced simplicity, flexibility, and accuracy.
Referring to FIGS. 3E-3F, the Check Overlap Calls
service S309 is responsible for determining whether a call
made by a particular subscriber overlaps any other calls or
validation requests by the subscriber ID. Overlapping calls
occur when two or more calls or a call and a validation
request either (1) occur substantially concurrently, or (2)
are placed from different geographic regions and occur
within a sufficiently short time interval such that it
would be improbable that a single subscriber could place
the first call and then travel to the location of the
second call within the given time interval to place the
second call. Because each unique subscriber ID or calling
card number may typically only be used by a single
subscriber from a single location at any one time, fraud is
indicated upon occurrence of either or both of these two
conditions. The Check Overlap Calls service is comprised
of two separate checks: Check Simultaneous Calls and Check
Geographic Dispersion.
Referring to FIG. 3E, the Check Overlap Calls service
first performs the Simultaneous Calls check at step 5369.
After retrieving the first call stored in the calls
database at step S371, the check simultaneous calls
service, at step 5373, tests whether the retrieved call was
placed on the same date as the call presently under
consideration as determined from the orig date field 229 of
WO 95/11576 PCT/US94/11906
~174~?~
the CCF Record 201. If the retrieved call was not placed
on the same date, the retrieved call cannot overlap the
present call and the service flows to step S389 to check
the next call in the calls database, if any.
5 If the retrieved call was placed on the same date as
the present call, the service, at step S375, tests whether
the retrieved call has the same subscriber ID as the
present call, as determined by the three MIN fields 203,
205, 207 and the MSN field 207. If the subscriber IDs do
10 not match, the retrieved call cannot overlap the present
call and the service flows to step S389 to check the next
call in the calls database, if any.
If the subscriber IDs match, the service, at steps
S377 and S379, tests whether the retrieved call used either
15 the three-way call or the call-waiting features,
respectively, as determined from the call feature field 231
of the retrieved call CCF record. Calls utilizing these
call features are presently ignored when checking for
overlap calls because calls that utilize these features,
20 while appearing to overlap, may be legitimate. Accordingly,
when these call features are present the service flows to
step S389 to check the next call in the calls database, if
any.
If neither of these call features were utilized, the
25 service, at step S381, tests whether any portion of the
retrieved call chronologically overlaps the present call.
Overlap is determined by satisfying either of the following
two conditions: (1) the origination time of the present
274625
WO 95/11576 PCT/US94/11906
51
call (as determined from the value held by the orig time
field 227 of the present call CCF record) is
chronologically between the origination time of the
retrieved call (as determined from value held by the orig
time field 227 of the retrieved call CCF record) and the
termination time of the retrieved call (as determined by
adding the value held by the call seconds field 233 of the
retrieved call CCF record to the value held by the orig
time ffield 227 of the retrieved call CCF record); or (2)
the termination time of the present call (as determined by
adding the value held by the call seconds field 233 of the
present call CCF record to the value held by the orig time
field 227 of the present call CCF record) is
chronologically between the origination time of the
retrieved call and the termination time of the retrieved
call. If neither of these two conditions are met, the
retrieved call and the present call do not overlap
chronologically, and the service flows to step S389 to
check the next call in the calls database, if any.
If either of the two conditions are met, however, the
present call and the retrieved call overlap chronologically
and the service flows to step S383 where an "overlap call
event" is generated by recording the event subtype,
"simultaneous calls," along with specific information
particular to this call in the events database for this
particular subscriber ID.
Next, at step S385, the event context data structure
is built with information specific to this event, as
WO 95/11576 PCT/US94/11906
x.174625 52
discussed above. The event context data structure for this
service has the event type, "overlap event," and event
subtype, "simultaneous calls."
Next, at step S387, the service sends the event
context data structure previously built at step S385 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
It should be noted that the service performs steps 5383
through S387 -- that is, another event is generated -- for
each call retrieved from the calls database which overlaps
the present call. Therefore, the single CCF record under
consideration may generate multiple "overlap call" events.
Next, at step S389, the service tests whether any
calls remain in the calls database to be compared for
overlap with the present call. If additional calls remain
in the calls database which have not yet been checked for
overlap with the present call, the service flows to step
S391 where the next call is retrieved from the calls
database and the service returns to step S373 to check for
call overlap. It should be noted that steps S373 through
5391 are performed as many times as the number of calls in
the calls database.
If no more calls remain to be compared, the service,
at step S394 performs a check of the present CCF record
against the validation request database. This procedure is
substantially the same as the check against the calls
database described above, except that a chronological
WO 95/11576 a- ~ PCT/US94/11906
53
overlap is indicated if the validation request was
initiated between the origination time and the termination
- time of the call represented by the present CCF record.
If no more validation requests remain to be compared,
the service, at step 5395, performs a Geographic Dispersion
Check, a flow chart for which is shown in Fig. 3F.
Referring to FIG. 3F, at step 5401, the check Geographic
Dispersion service retrieves the first call stored in the
calls database.
Next, at step S403, the service tests whether the
retrieved call was originated on the same date as the call
presently under consideration as determined from the orig
date field 229 of the CCF Record 201. If the retrieved call
was not placed on the same date, the retrieved call cannot
overlap the present call and the service flows to step 5423
to check the next call in the calls database, if any.
If, however, the retrieved call was placed on the same
date as the present call, the service, at step S405, tests
whether the retrieved call has the same subscriber ID as
the present call, as determined by the three MIN fields
203, 205, 207 and the MSN field 207. If the subscriber IDs
do not match, the retrieved call cannot overlap the present
call and the service flows to step S423 to check the next
call in the calls database, if any.
If the subscriber IDs match, the service, at steps
5407 and S409, tests whether the retrieved call used either
the three-way call or the call-waiting features,
respectively, as determined from the call feature field 231
WO 95/11576 PCT/US94/11906
217~b25
54
of the retrieved call CCF record. Calls utilizing these
call features are presently ignored when checking for
overlap calls because calls that utilize these features,
while appearing to have a geographical dispersion problem,
may be legitimate. Accordingly, when these call features
are present the service flows to step S423 to check the
next call in the calls database, if any.
If neither of these call features were utilized, the
service, at step S411, calculates the mileage between the
location of the present call and the location of the
retrieved call using, for example, the "airline formula."
The airline formula is taught by the following publication,
AT&T Tariff F.C.C., No. 264 (effective date: April 2,
1979), a copy of which is included as Appendix B. The
locations of the retrieved and present calls are determined
from the values held by the sid field 221, the first
serving field 223 and the first serving cell field 225 of
the each of the CCF records for the present and retrieved
calls. Because each MSC has a unique identifying number,
and because the exact geographic location of each MSC is
known, the service can approximate the location of each
call by using the MSC identifier to index a database of MSC
geographic coordinates.
Next, at step S413, the mileage between the location
of the present call and the location of the retrieved call
is transformed into a time value using a predetermined
Miles-Per-Hour (MPH) tuning parameter. The time value
calculated is the geographic dispersion adjustment which
WO 95/11576 ~ ~ ~ PCT/US94/11906
will be applied to the calls under comparison to determine
if call overlap occurred.
Next, at step S415, the service tests whether any
portion of the present call chronologically overlaps the
5 retrieved call when adjusted for geographic dispersion.
Overlap is determined by satisfying either of the following
two conditions: (1) the origination time of the present
call (as determined from the value held by the orig time
field 227 of the present call CCF record) is
10 chronologically between the origination time of the
retrieved call (as determined from value held by the orig
time field 227 of the retrieved call CCF record) minus the
geographic dispersion adjustment time and the termination
time of the retrieved call (as determined by adding the
15 value held by the call seconds field 233 of the retrieved
call CCF record to the value held by the orig time ffield
227 of the retrieved call CCF record) plus the geographic
dispersion adjustment time; or (2) the termination time of
the present call (as determined by adding the value held by
20 the call seconds field 233 of the present call CCF record
to the value held by the orig time field 227 of the present
call CCF record) is chronologically between the origination
time of the retrieved call minus the geographic dispersion
adjustment time and the termination time of the retrieved
25 call plus the geographic dispersion adjustment time. If
neither of these two conditions are met, the retrieved call
and the present call do not overlap chronologically when
adjusted for geographic dispersion, and the service flows
WO 95/11576 PCT/US94/11906
2 i ?~~,25
56
to step 5423 to check the next call in the calls database,
if any.
If either of the two conditions are met, however, the
present call and the retrieved call overlap chronologically
when adjusted for geographic dispersion and the service, at
step S417, generates a "overlap call event" by recording
the event subtype, "geographic dispersion," along with
specific information particular to this call in the events
database for this particular subscriber ID.
Next, the service flows to step 5419 where the event
context data structure is built with information specific
to this event, as discussed above. The event context data
structure for this service has the event type, "overlap
event," and event subtype, "geographic dispersion."
Next, at step S421, the service sends the event
context data structure previously built at step 5419 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
It should be noted that the service performs steps S417
through 5421 -- that is, another event is generated -- for
each call retrieved from the calls database which overlaps
the present call when adjusted for geographic dispersion.
Therefore, the single CCF record under consideration may
generate multiple "overlap call" events.
Next, at step S423, the service tests whether any
calls remain in the calls database to be compared for
geographic dispersion overlap with the present call. If
217~~25
WO 95/11576 PCT/US94/11906
57
additional calls remain in the calls database which have
not yet been checked for geographic dispersion overlap with
the present call, the service flows to step S425 where the
next call is retrieved from the calls database and the
service returns to step 5403 to check for geographic
dispersion call overlap. It should be noted that steps S403
through S425 are performed as many times as the number of
calls in the calls database.
If no more calls remain to be compared, the service,
at step 5426 performs a check of the present CCF record
against the validation request database. This procedure is
substantially the same as the check against the calls
database described above, except that a geographic
dispersion overlap event is indicated if the retrieved CPF
record was initiated at a time which falls chronologically
between the origination time of the present CCF record
minus the geographic dispersion adjustment time and
termination time of the present CCF record plus the
geographic dispersion adjustment time.
If no more validation requests remain to be compared,
the service flows to step S427 where the Overlap Calls
Check is completed and the next check in the event manager
procedure is initiated.
Referring to FIG. 3G, the Check Call Duration Pattern
service S311 is responsible for determining if a particular
subscriber's call duration is increasing at a rate which
makes it suspect for fraudulent activity. The trend being
examined is a five-day moving average increasing over a
WO 95/11576 PCT/US94/11906
2174~J25
58
ten-day moving average for a prolonged period of time.
This trend shows a marked increase in the amount of time a
subscriber is willing to stay on the telephone. The theory
is that users who do not intend to pay for their telephone
services (for example, cloning fraud users) will not be
concerned with the length of their calls. This service
expects the previously calculated five-day and ten-day call
duration moving averages as arguments.
First, at step S429, the service tests whether the
five-day moving average call duration calculated for the
call date is greater than a predetermined minimum amount.
This step ensures that fluctuations in usage for low volume
users do not generate an abnormal number of events. For
example, if a subscriber whose five-day moving average call
duration was 130 seconds on the day before the call date
based on a single call within the past five days, increased
to 195 seconds on the call date based on one additional
call, a 50% increase would be calculated, even though the
actual usage change is represented by one long call. If
the five-day moving average call duration calculated for
the call date is less than the predetermined amount,
therefore, a call duration pattern check would not be
performed and false alerts would be avoided. This would be
the case, continuing with the example, if the predetermined
minimum amount were 200 seconds. Accordingly, the service
flows to step S443 which marks the completion of the check.
If, however, the five-day moving average call duration
is greater than the predetermined minimum amount, the
WO 95/11576 217 4 6 2 5 pCT~S94/11906
59
service, at step S431, tests whether the five-day moving
average call duration for the call date is greater than the
ten-day moving average call duration for the same date. If
it is not greater, the service flows to step S443 which
marks the completion of the check.
If the five-day moving average call duration for the
call date is greater than the ten-day moving average call
duration for the same date, the service, at step 5433,
calculates the percentage increase between the five-day
moving average call duration for the call date and the
five-day moving average call duration for the day before
the call date.
Next, at step S435, the service tests whether the
percentage increase calculated at step S433 is greater than
a predetermined limit. If the predetermined limit is not
exceeded it indicates that the average call duration for
the particular subscriber ID under consideration is not
increasing at an abnormal rate and there is no reason to
suspect fraud on the basis of the call duration trend.
Accordingly, the service flows to step S443 which marks the
completion of the check.
If, however, the percentage increase exceeds the
predetermined limit, it indicates that call duration for
the particular subscriber ID under consideration is
increasing at an abnormal rate. Accordingly, at step S437,
the service generates a "call duration pattern event" by
recording the event type, "average event," and the event
subtype, "duration," along with specific information
WO 95/11576 PCT/US94111906
217~~25
particular to this call in the events database for this
particular subscriber ID.
Next, the service flows to step 5439 where the event
context data structure is built with information specific
5 to this event, as discussed above. The event context data
structure for this service has the event type, "average
event," and event subtype, "duration."
Next, at step S441, the service sends the event
context data structure previously built at step S439 to the
10 alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S443, where the call
duration pattern check is completed and the next check in
15 the event manager procedure is initiated.
As illustrated in FIG. 3H, the service for Check
International Call Duration Pattern is nearly identical to
the service for Check Call Duration Pattern, except the
event manager maintains a separate subscriber-specific
20 pattern for international call duration against which the
CCF record is checked, and the event subtype is
"international duration." Due to the near identity of this
service with the Check Call Duration Pattern service, no
further discussion is necessary.
25 Referring to FIG. 3I, the Check Call Thresholds
service S315 is responsible for determining whether a
particular subscriber has exceeded one or more of his or
her previous high water marks. A high water mark is the
2174625
WO 95/11576 PCT/US94I11906
61
highest number of calls placed within a given time period.
The Check Call Thresholds service 5315 comprises three
separate checks: a one-day high water mark check, a five-
day moving average high water mark check, and a ten-day
moving average high water mark check. The fraud detection
system 107 keeps track of the highest number of calls ever
made by a particular subscriber for each the three
different time periods. With each additional CCF record
processed, the Check Call Thresholds service S315 checks to
see if the addition of the present call to the present
total number of calls placed for each of the three separate
time periods exceeds one of the high water marks for a
particular subscriber. Because the three checks are nearly
identical, with only a difference in the time period to be
used in performing the check, only the daily call threshold
check will be explained in detail.
As shown in FIG. 3I, the Daily Call Threshold Check
5445 is performed first. At step S447 the service tests
whether the present daily call count -- that is, the total
number of calls made for the call date -- exceeds a
predetermined minimum amount. This step ensures that an
excess number of daily threshold events are not generated
for low volume subscribers. For example, it would be
undesirable to generate a daily threshold event for a low
volume subscriber who placed only three calls for the call
date, but whose previous daily high water mark was 2 calls
placed in one day. Accordingly, if the present call count
does not exceed the predetermined minimum amount the
WO 95/11576 PCT/US94/11906
217~~~25
62
service flows to step S459 and the next call threshold
check is initiated.
If, however, the present call count exceeds the
predetermined minimum amount, the service, at step S449,
tests whether the present daily call count exceeds the one-
day high water mark. If the one-day high water mark is not
exceeded, the service flows to step S459 and the next call
threshold check is initiated.
If, however, the one-day high water mark is exceeded
by the present daily call count, the service, at step S451,
resets the one-day high water mark to the present daily
call count, and then, at step 5453, generates a daily call
threshold event by recording the event type, "threshold
event," and the event subtype "1 day velocity," along with
specific information particular to this call in the events
database for this particular subscriber ID.
Next, at step 5455, the event context data structure
is built with information specific to this event, as
discussed above. The event context data structure for this
service has the event type, "threshold event," and event
subtype, "1 day velocity."
Next, at step 5457, the service sends the event
context data structure previously built at step S455 to the
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Next, at step S459, the service initiates the five-day
moving average threshold check. As illustrated in FIG. 3I,
WO 95/11576 ~ ~ PCT/US94/11906
63
both the five-day and ten-day checks are nearly identical
to the daily check, except that the high water marks for
five-day and ten-day periods, respectively, are used, and
the event subtypes are "5 day average velocity" and "10 day
average velocity," respectively. Consequently, no further
discussion of these checks is believed to be necessary.
As illustrated in FIG. 3J, the service for Check
International Call Thresholds is nearly identical to the
service for Check Call Thresholds, except the event manager
maintains a separate subscriber-specific pattern for
international call thresholds against which the CCF record
is checked, and the events subtypes are "1 day
international velocity," "5 day average international
velocity," or "10 day average international velocity," as
appropriate. Due to the near identity of this service with
the Check Call Thresholds service, no further discussion is
believed necessary.
Referring to FIG. 3K, the Check Call Velocity Pattern
service S319 is responsible for determining if a particular
subscriber's call velocity is increasing at a rate which
makes it suspect for fraudulent activity. The trend being
examined is a five-day moving average increasing over a
ten-day moving average for a prolonged period of time.
This trend shows a marked increase in the number of calls
a subscriber is willing to place. The theory is that users
who do not intend to pay for their telephone services (for
example, cloning fraud users) will not be concerned with
the quantity of their calls. This service expects the
WO 95/11576 PCT/US94/11906
21 i 4625
64
previously calculated five-day and ten-day call velocity
moving averages as arguments.
First, at step 5461, the service tests whether the
five-day moving average call velocity calculated for the
call date is greater than a predetermined minimum amount.
This step ensures that fluctuations in usage for low volume
users do not generate an abnormal number of events. For
example, if a subscriber whose five-day moving average call
velocity was 2 calls/day on the day before the call date
l0 increased to 3 calls/day on the call date, a 50% increase
would be calculated, even though the actual usage change is
as insignificant as one call. If the five-day moving
average call velocity calculated for the call date is less
than the predetermined amount, therefore, a call velocity
pattern check would likely generate false alerts and should
not be performed. Accordingly, the service flows to step
S475 which marks the completion of the check.
If, however, the five-day moving average call velocity
is greater than the predetermined minimum amount, the
service, at step 5463, tests whether the five-day moving
average call velocity for the call date is greater than the
ten-day moving average call velocity for the same date. If
it is not greater, the service flows to step S475 which
marks the completion of the check.
If the five-day moving average call velocity for the
call date is greater than the ten-day moving average call
velocity for the same date, the service, at step S465,
calculates the percentage increase between the five-day
2174625
WO 95/11576 PCT/US94/11906
moving average call velocity for the call date and the
five-day moving average call velocity for the day before
the call date.
Next, at step 5467, the service tests whether the
5 percentage increase calculated at step S465 is greater than
a predetermined limit. If the predetermined limit is not
exceeded it indicates that the average call velocity for
the particular subscriber ID under consideration is not
increasing at an abnormal rate and there is no reason to
10 suspect fraud on the basis of the call velocity trend.
Accordingly, the service flows to step S475 which marks the
completion of the check.
If, however, the percentage increase exceeds the
predetermined limit, it indicates that call velocity for
15 the particular subscriber ID under consideration is
increasing at an abnormal rate. Accordingly, at step S469,
the service generates a "call velocity pattern event" by
recording the event type, "average event," and the event
subtype, "velocity," along with specific information
particular to this call in the events database for this
particular subscriber ID.
Next, the service flows to step S471 where the event
context data structure is built with information specific
to this event, as discussed above. The event context data
structure for this service has the event type, "average
event," and event subtype, "velocity."
Next, at step S473, the service sends the event
context data structure previously built at step 5471 to the
WO 95/11576 PCT/US94/11906
~~74~25
66
alert manager 115 to signal the alert manager that a new
event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S475, where the call
velocity pattern check is completed and the next check in
the event manager procedure is initiated.
As illustrated in FIG. 3L, the service for Check
International Call Velocity Pattern is nearly identical to
the service for Check Call Velocity Pattern, except the
event manager maintains a separate subscriber-specific
pattern for international call velocity against which the
CCF record is checked, and the event subtype is
"international velocity." Due to the near identity of this
service with the Check Call Velocity Pattern service, no
further discussion is felt necessary.
Referring again to Fig. 3A, if the system, at step
5304 determines that the record received is a CPF record
then the event manager 113 completes steps S306 through
5318, as discussed below. At step 5306, the event manager
parses the CPF record to place the CPF component fields
into appropriate variables and data structures to be easily
accessible by the event manager services. Further, at step
5308 the event manager 113 uses the present CPF record to
update subscriber-specific roaming usage patterns. More
specifically, the event manager calculates a new one day
moving average threshold, as discussed in greater detail
hereinafter.
WO 95/11576 217 4 6 2 5 pCT~S94/11906
67
Next the event manager runs the CPF record through a
series of event checks represented by steps 5310 through
S318. Although one embodiment of the invention arranges
these checks in a specific order as illustrated in FIG. 3A,
the checks are substantially order independent and may
proceed in any convenient order.
In the embodiment depicted in FIG. 3A, the event
manager 113 performs checks on a CPF record .in the
following order: (1) check suspect market; (2) check
overlapped validation request; (3) check propensity to
roam; (4) check extended roaming; (5) check validation
request thresholds. Each of these checks will be described
in detail with reference to FIGS. 3M through 3U.
Referring to FIG. 3M, the Check Suspect Market service
S310 is responsible for determining whether the pre-call
validation request originated from a geographic region
which is suspected of being frequently used by fraudulent
users of cellular telephones to originate calls. This
services receives the sidbid field 250 of the CPF record
240 as an argument.
First, at step S1100 the service determines whether
the present pre-call validation request originated from a
visited market. If the pre-call validation request did not
originate from a visited market then the service flows to
step S1112 and this check is completed.
If, however, the pre-call validation request did
originate from a visited market, the service passes to step
S1102, which tests whether the number in the sidbid field
WO 95111576 L ~ ~ ~ ~ PCT/US94/11906
68
of the CPF record matches a number on a predetermined list
of sidbid numbers established by the telecommunication
service provider and maintained by the fraud detection
system 107. If no number on the list is matched the service
flows to step S1112 and this check is completed.
If a matching number is found, the service, at step
S1104 tests whether the matched number from the database
has been flagged as "suspect." If the matched number is
determined to be suspect, the service flows to step 51106.
Otherwise the service flows to step 51112 and the check is
complete.
At step S1106, it has been determined that the
geographic region from which the pre-call validation
request originated is one which is associated with a high
probability of fraudulent telecommunication activity.
Accordingly, the service generates a "suspect market" event
by recording the event type "suspect market," along with
specific information particular to this pre-call validation
request in the events database for this particular
subscriber ID.
Next, at step S1108, the "event context" data
structure is built with information specific to this event.
The event context data structure contains information
including (1) the event type ("suspect market event"); (2)
the event subtype (none for this event type); (3) the
subscriber ID number (corresponding to the three MIN fields
242, 244, 246, and the MSN/ESN field 248; (4) the date of
the pre-call validation request (from the pcval-datetime
WO 95/11576 ~ ~ PCT/US94/11906
69
field 252); and (5) the current alert-state (either normal
yellow, or red depending on the nature and quantity of
alerts outstanding for this particular subscriber as
determined by the alert manager, discussed below).
Next, at step S1110, the service sends the event
context data structure previously built at step 51108 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S1112, where the
suspect termination check is completed and the next check
in the event manager procedure is initiated.
Referring to FIGS. 3N-30, the Check Overlap Validation
Request service S312 is responsible for determining whether
a validation request originated by a particular subscriber
overlaps any other validation requests or calls made using
the same subscriber ID. An overlapping validation request
is a validation request that either (1) occurs
substantially concurrently with a previous validation
request or with a call detail record of completed call; or
(2) is placed from different geographic region and occurs
within a sufficiently short time interval of previous
validation requests or a call detail record of a completed
call such that it would be improbable that a single
subscriber could originate the first validation request or
call and then travel to the location of the origination of
the second validation request or call within the given time
interval. Because each unique subscriber ID or calling card
Wp 95/11576 PCT/US94/11906
2 I 74E,25
number may typically only be used by a single subscriber
from a single location at any one time, fraud is indicated
upon occurrence of either or both of these two conditions.
The Check Overlap Validation Request service is comprised
of two separate checks: Check Simultaneous Validation
Requests and Check Geographic Dispersion.
Referring to FIG. 3N, the Check Overlap Validation
Request service checks the present validation request
against existing information in the validation request
database and calls database to determine whether the
validation request is indicative of overlapping
telecommunication activity. The service first checks the
validation request database at steps S1120 through S1138.
After retrieving the first validation request stored in the
validation request database at step 51122, the check
simultaneous validation request service, at step S1124,
tests whether the retrieved validation request was placed
on the same date as the validation request presently under
consideration as determined from the pcval-datetime field
252 of the CPF Record 240. If the retrieved validation
request was not placed on the same date, the retrieved
validation request cannot overlap the present validation
request and the service flows to step WP to check the next
validation request in the validation request database, if
any.
If the retrieved validation request was placed on the
same date as the present validation request, the service,
at step WP, tests whether the retrieved validation request
WO 95/11576 217 4 ~ ~ ~ PCT/US94/11906
71
has the same subscriber ID as the present validation
request, as determined by the three MIN fields 242, 244,
246 and the ESN/MSN field 248. If the subscriber IDs do not
match, the retrieved validation request cannot overlap the
present validation request and the service flows to step
51136 to check the next validation request in the
validation requests database, if any.
If the subscriber IDs match, the service, at step
51129 tests whether the retrieved validation request
chronologically overlaps the present validation request. An
overlap condition is satisfied when the origination time of
the present validation request (as determined from the
value held by the pcval datetime field 252 of the present
validation request CPF record) is within a predetermined
time of the origination time of the retrieved validation
request (as determined from value held by the pcval
datetime field of the retrieved validation request CPF
record). If the retrieved validation request and the
present validation request do not overlap chronologically,
the service flows to step 51136 to check the next
validation request in the validation request database, if
any.
If an overlap conditions exists, however, the service
flows to step 51130 where an "overlap validation request
event" is generated by recording the event subtype,
"simultaneous validation requests" along with specific
information particular to this call in the events database
for this particular subscriber ID.
WO 95/11576 PCT/US94/11906
2174625
72
Next, at step 51132, the event context data structure
is built with information specific to this event, as
discussed above. The event context data structure for this
service has the event type, "overlap event," and event
subtype, "simultaneous validation requests."
Next, at step S1134, the service sends the event
context data structure previously built at step S1132 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
It should be noted that the service performs steps S1130
through S1134 -- that is, another event is generated -- for
each validation request retrieved from the validation
request database which overlaps the present validation
request. Therefore, the single CPF record under
consideration may generate multiple "overlap validation
request" events.
Next, at step S1136, the service tests whether any
pre-call validation requests remain in the pre-call
validation request database to be compared for overlap with
the present pre-call validation request. If additional
validation requests remain in the validation request
database that have not yet been checked for overlap with
the present validation request, the service flows to step
S1138 where the next validation request is retrieved from
the validation request database and the service returns to
step S1124 to check for a validation request overlap
condition. It should be noted that steps S1124 through
WO 95/11576 217 4 6 ? 5 PCT/US94/11906
73
51138 are performed as many times as the number of
validation requests in the validation requests database.
Next, at steps 51140 through S1160, the service checks
the present validation request against the calls database
to determine whether the present validation request
overlaps any other calls made using the same subscriber ID.
This portion of the check is substantially the same as the
check described in FIG. 3E, except that an overlap
condition is satisfied when the origination time of the
present pre-call validation request (as determined from the
value held by the pcval datetime field 252 of the present
validation request CPF record) is chronologically between
the origination time of the retrieved call (as determined
from value held by the orig time field 227 of the retrieved
call CCF record) and the termination time of the retrieved
call (as determined by adding the value held by the
call seconds field 233 of the retrieved call CCF record to
the value held by the orig time field 227 of the retrieved
call CCF record). If the retrieved call and the present
validation request do not overlap chronologically, the
service flows to step 51152 to check the next call in the
calls database, if any. In accordance with the discussion
referencing FIG. 3E, an event is generated for every
overlap condition which is satisfied.
If no more calls remain to be compared then the
service, at step S1154, performs a Geographic Dispersion
check, a flow chart for which is shown in Fig. 30. The
Geographic Dispersion check compares the present validation
WO 95/11576 PCT/US94/11906
~~r~~J
74
request with (1) the validation request database and (2)
the calls database to determine whether it is improbable
that the subscriber could have travelled from the location
from which the retrieved validation request (or call)
originated to the location at which the present validation
request originated in the elapsed time. Referring to FIG.
30, at step S1158, the check Geographic Dispersion service
retrieves the first validation request stored in the
validation request database.
Next, at step S1160, the service tests whether the
retrieved validation request originated on the same date as
the validation request presently under consideration as
determined from the pcval-datetime field 252 of the CPF
Record 240. If the retrieved validation request was not
placed on the same date, the retrieved validation request
cannot overlap the present validation request and the
service flows to step S1176 to check the next record in the
validation request database, if any.
If, however, the retrieved validation request was
originated on the same date as the present validation
request, the service, at step S1162, tests whether the
retrieved validation request has the same subscriber ID as
the present validation request, as determined by the three
MIN fields 242, 244, 246 and tf~e ESN/MSN field 248. If the
subscriber IDs do not match, the retrieved validation
request cannot overlap the present validation request and
the service flows to step 51176 to check the next record in
the validation request database, if any.
WO 95!11576 ? PCT/US94/11906
If the subscriber IDs match, the service, at step S-
1164, calculates the mileage between the location of the
present validation request and the location of the
retrieved validation request using, for example, the
5 "airline formula," as previously discussed. Next, at step
S1166, the mileage between the location of the present
validation request and the location of the retrieved
validation request is transformed into a time value using
a predetermined Miles-Per-Hour (MPH) tuning parameter. The
l0 time value calculated is the geographic dispersion
adjustment which will be applied to the validation requests
and calls under comparison to determine if an overlap
occurred.
Next, at step S1168, the service tests whether the
15 present validation request chronologically overlaps the
retrieved validation request when adjusted for geographic
dispersion. An overlap condition is satisfied when the
origination time of the present validation request (as
determined from the value held by the pcval datetime field
20 252 of the present validation request CPF record) is within
a predetermined time of the origination time of the
retrieved validation request (as determined from value held
by the pcval datetime field of the retrieved validation
request CPF record) adjusted for geographic dispersion.
25 If an overlap condition is satisfied, the service, at
step S1170, generates an "overlap validation request" event
by recording the event subtype, "geographic dispersion,"
along with specific information particular to this
WO 95/11576 PCT/US94/11906
a 1 ?~ 625
76
validation request in the events database for this
particular subscriber ID.
Next, the service flows to step S1172 where the event
context data structure is built with information specific
to this event, as discussed above. The event context data
structure for this service has the event type, "overlap
validation request" event and event subtype, "geographic
dispersion."
Next, at step S1174, the service sends the event
context data structure previously built at step 51172 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
It should be noted that the service performs steps S1170
through S1174 -- that is, another event is generated -- for
each record retrieved from the validation request database
which overlaps the present validation request when adjusted
for geographic dispersion. Therefore, the single CPF record
under consideration may generate multiple "overlap
validation request" events.
Next, at step S1176, the service tests whether any
records remain in the pre-call validation request database
to be compared for geographic dispersion overlap with the
present validation request. If additional records remain
in the validation request database which have not yet been
checked for geographic dispersion overlap with the present
validation request, the service flows to step S1180 where
the next record is retrieved from the validation request
WO 95111576 217 4 1 ~ ~ PCT/US94/11906
77
database and the service returns to step S1160 to check for
geographic dispersioi: overlap. It should be noted that
steps 51160 through S1180 are performed as many times as
the number of records in the validation request database.
Next, the service checks the present validation
request against the calls database for completed calls to
determine whether the present validation request overlaps
any calls made using the same subscriber ID when. adjusted
for geographic dispersion. This portion of the check is
substantially the same as the check described in FIG. 3F,
except that an overlap condition is satisfied when the
origination time of the present validation request (as
determined from the value held by the pcval datetime field
252 of the present validation request CPF record 240) is
chronologically between the origination time of the
retrieved call (as determined from value held by the
orig time field 227 of the retrieved call CCF record) and
the termination time of the retrieved call (as determined
by adding the value held by the call seconds field 233 of
the retrieved call CCF record to the value held by the
orig time field 227 of the retrieved call CCF record)
adjusted for geographic dispersion. If the retrieved call
and the present validation request do not overlap
chronologically, the service checks the next call record in
the calls database, if any. In accordance with the
discussion referencing FIG. 3E, an event is generated for
every overlap condition which is satisfied.
WO 95/11576 PCT/L1S94/11906
21 i 425
78
Next, control passes to the Check Roaming Markets
service 314 illustra~~d in FIG. 3P, which is responsible
for determining whether the present validation request
originated from a geographic region in which the subscriber
does not normally roam. This service receives the sidbid
field 250 of the CPF record 240 as an argument.
First, at step S1202, the service tests whether the
number in the sidbid field 250 of the present CPF record
240 matches a number on a list of numbers identifying the
l0 switches from which the subscriber has originated calls
during a predetermined previous time period. If the sidbid
field 250 of the present validation request matches a
number on the list the service flows to step S1212 and this
check is completed.
If no matching number is found, the service, at step
S1204 saves the sidbid field of the present CPF record to
on the list of numbers identifying switches from which the
subscriber has originated calls within a predetermined time
period.
At step S1206, it has been determined that the
geographic region from which the present pre-call
validation request originated is one from which the
subscriber has not originated a pre-call validation request
within a predetermined time period preceding the present
pre-call validation request. Accordingly, the service
generates a "new roaming market" event by recording the
event type "new roaming market" along with particular
WO 95!11576 PCT/US94/11906
217~rU25
79
information particular to this pre-call validation request
in the events database for this particular subscriber ID.
Next, the service flows to step 51208 where the event
context data structure is built with information specific
to this event, as discussed above. The event context data
structure for this service has the event type, "Roaming
Market."
Next, at step S1210, the service sends the event
context data structure previously built at step S1208 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step 51212, where the
propensity to roam check is completed and the next check in
the event manager procedure is initiated.
Next, control passes to the Check Extended Roaming
service 316 illustrated in FIG. 3Q, which is responsible
for determining whether the present validation request
indicates that a subscriber has been roaming for more than
a predetermined number of days. This service receives the
sidbid field 250 and the pcval-datetime field 252 of the
CPF record 240 as arguments.
First, at step S1222, the service tests whether the
subscriber has an entry in the roaming registrations table
for the current day. The roaming registrations table is a
subscriber-specific listing of the geographic regions in
which each particular subscriber has attempted to originate
a call during a predetermined previous number of days. If
WO 95/11576 ~ ~ PCT/US94/11906
~'1.7~-X25
the subscriber already has an entry in the roaming
registrations table for the day then the service flows to
step S1234 and this check is completed.
If the subscriber does not have an entry on the
5 roaming registrations table for the current day, the
service, at step S1224 updates the roaming registrations
table to reflect the current validation request.
Control is then passed to step 51226, where the
service compares the present validation request with
10 roaming registrations table to determine whether the
particular subscriber s ID has been used to place roaming
calls greater than a predetermined number of days. If the
test does not indicate that the subscriber has not been
roaming for greater than a predetermined number of days,
15 the service flows to step S1234 and this check is
completed.
However, if the test indicates that the particular
subscriber has been roaming for greater than a
predetermined number of days the service generates a
20 "extended roaming limit" event by recording the event type
"extended roaming limit" along with particular information
particular to this pre-call validation request in the
events database for this particular subscriber ID.
Next, the service flows to step 51230 where the event
25 context data structure is built with information specific
to this event, as discussed above. The event context data
structure for this service has the event type, "extended
roaming limit" event and does not have an event subtype.
WO 95/11576 ~ ~ ~ ~ ~~ ~ ~ PCT/US94/11906
81
Next, at step S1232, the service sends the event
context data structure previously built at step 51230 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
Lastly, the service flows to step S1234, where the
extended roaming limit check is completed and the next
check in the event manager procedure is initiated.
Next, control is passed to the Check Validation
Request Thresholds service, which is responsible for
determining whether a particular subscriber's usage has
exceeded one or more predetermined limits. The Check
Validation Request service conducts four tests, represented
in FIGS. 3R through 3U, as follows: (1) Check Hourly
Validation Request Threshold; (2) Check Daily Validation
Request Threshold; (3) Check Daily High Water Mark
Threshold; and (4) Check 1 Day Moving Average Threshold.
A high water mark is the highest number of calls placed
within a given time period. A 1 day moving average is
simply the average number of calls placed per day over the
course of a predetermined number of days.
As shown in FIG. 3R, the Hourly Validation Request
Threshold Check S1240 is performed first. At step S1242
the service tests whether the present hourly validation
request count -- that is, the total number of validation
requests initiated in the present hour -- exceeds a
predetermined minimum amount. If the hourly validation
request count does not exceed a predetermined minimum
WO 95/11576 PCT/US94/11906
r
,~ a ~4.~2~
82
amount, the service flows to step 51250, where the Daily
Validation Request Threshold check is initiated.
If, however, the present call count exceeds the
predetermined minimum amount, the service, at step S1244,
generates an hourly validation request threshold event by
recording the event type, "validation request threshold
event," and the event subtype "hourly velocity," along with
specific information particular to this call in the events
database for this particular subscriber ID.
Next, at step S1246, the event context data structure
is built with information specific to this event, as
discussed above. The event context data structure for this
service has the event type, "validation request threshold
event," and event subtype, "hourly velocity."
Next, at step S1248, the service sends the event
context data structure previously built at step S1246 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
Next, at step S1250, the service initiates the Daily
Validation Request Threshold check. As illustrated in FIG.
3S, the daily check is nearly identical to the hourly
check, except that the relevant time period is one day
rather than one hour. Consequently, no further discussion
of the Daily Validation Request Threshold check is believed
to be necessary.
After the Daily Validation Request Threshold check is
completed, service passes to the Daily High Water Mark
WO 95/11576 217 4 ~ ~ ~ pCT~S94/11906
83
Threshold, illustrated in FIG. 3T, which is responsible for
determining whether the present daily usage exceeds a
previous high water mark established over a predetermined
number of days. The fraud detection system 107 keeps track
of the highest number of validation requests made by a
particular subscriber for each day over a predetermined
previous number of days. A high water mark is the highest
number of validation requests placed on any day within the
given time period.
As shown in FIG. 3T, the Daily High Water Mark Check,
at step S1262 the service tests whether the present daily
validation request count -- that is, the total number of
validation requests initiated on the present date --
exceeds a predetermined minimum amount. This step ensures
that an excess number of daily validation request threshold
events are not generated for low volume subscribers. For
example, it would be undesirable to generate a daily
threshold event for a low volume subscriber who originated
only three validation requests for the present date, but
whose previous daily high water mark was 2 validation
requests placed in one day. Accordingly, if the present
validation request count does not exceed the predetermined
minimum amount the service flows to step S1280 and the One
Day Moving Average validation request threshold check is
initiated.
If, however, the present validation request count
exceeds the predetermined minimum amount, the service, at
step 51264, tests whether the present daily validation
WO 95/11576 PCT/US94/11906
2 ~ 7425
request count exceeds the one-day high water mark. If the
one-day high water mark is not exceeded, the service flows
to step S1280 and the One Day Moving Average threshold
check is initiated.
If, however, the one-day high water mark is exceeded
by the present daily validation request count, the service,
at step 51266, resets the one-day high water mark to the
present daily validation request count, and then, at step
51268, generates a daily validation request threshold event
by recording the event type, "validation request threshold
event," and the event subtype "1 day velocity," along with
specific information particular to this call in the events
database for this particular subscriber ID.
Next, at step 51270, the event context data structure
is built with information specific to this event, as
discussed above. The event context data structure for this
service has the event type, "validation request threshold
event," and event subtype, "1 day velocity."
Next, at step S1272, the service sends the event
2 0 context data structure previous ly bui It at step S 12 7 0 to
the alert manager 115 to signal the alert manager that a
new event has been generated and to provide a reference for
locating the newly generated event in the events database.
Finally, service flows to the One Day Moving Average
Validation Request Threshold check illustrated in FIG. 3U.
This check is substantially similar to the Daily High Water
Mark check, except that the present daily roaming usage is
tested against a moving daily validation request average
WO 95/11576 ~ I 7 4 ~ ~ ~ pCT/US94/11906
calculated over a predetermined number of days. If the
present usage exceeds the average, an event context data
structure having an event type "validation request
threshold event" and subtype "one day moving average" is
5 generated and sent to the alert manager.
Once all of the event manager checks have been
performed, the event manager procedure is complete for the
particular CCF or CPF record. If a new event was not
generated for the present CCF or CPF record, the fraud
10 detection system procedure is complete for that CCF or CPF
record. Accordingly, the fraud detection system 107 waits
for the next CCF or CPF record to be input into the switch
interface 111.
However, if one or more events were generated for the
15 present CCF record, each corresponding event context data
structure is passed to the alert manager 115, the procedure
for which is illustrated by a flowchart in FIG. 4A. The
function of the alert manager 115 is to receive each event
generated by the event manager 113 and "analyze" that
20 event, to determine if an "alert" should be generated.
Depending upon a predetermined set of rules, either a
single alert or a specific combination of alerts may
generate an "alert-state" which is then passed to the user
interface 117 to signal the system operator 119 that the
25 particular subscriber ID for which an alert-state was
generated is suspected of being used fraudulently. It
should be noted that a single CCF or CPF record may
generate multiple events, each of which is individually
WO 95/11576 PCT/US94/11906
217~~25
86
analyzed by the alert manager 115. Accordingly, the alert
manager procedure, described below, may be performed
multiple times for a single CCF or CPF record. More
specifically, the alert manager procedure will be performed
once for each event generated by the event manager 113.
Referring to FIG. 4A, the alert manager procedure
initiates at step S476 where the alert manager receives an
event context data structure for the particular event to be
analyzed by one of the different analysis services. The
different analysis services, represented by flowcharts in
FIGS. 4B-4S will be described in detail with reference to
the appropriate figures.
Next, the alert manager determines the type of event
to be analyzed by examining the event type field in the
event context data structure received from the event
manager. At step S478, if the event type is a suspect
termination event, the alert manager procedure flows to
step S480 where the Analyze Suspect Termination Event
service analyzes the incoming event.
Referring to FIG. 4B, the Analyze Suspect Termination
Event service 5480 generates a new suspect termination
alert for every incoming suspect termination event. Upon
receiving the event context data structure as an argument,
the service generates a "suspect termination" alert at step
S524 by adding a new entry to the alerts database for this
particular subscriber ID. An entry into the alerts
database includes the following information: (1) subscriber
ID (particular subscriber ID for which this alert was
WO 95/11576 ~ PCT/US94/11906
87
generated); (2) alert type ("suspect termination" in this
case); (3) alert date (date that alert was generated); and
(4) call date (date indicated in orig date field 229 for
the CCF record which generated the event being analyzed).
Next, at step S526, the service "associates" the event
under consideration with the newly generated alert. This
is performed by adding a new entry to a database -- the
alert-events database -- containing all previously
generated alerts, and the associated events which triggered
the specific alert, for each particular subscriber. The
purpose of the alert-events database is to provide a system
operator investigating a particular alert with a list of
the specific event, or events, responsible for triggering
the alert under investigation.
Next, at step S528, the service sends the alert
generated at step S524 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step S530 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step 5478, the alert manager procedure flows to step
S482. At this step, if the event type is a suspect country
code event, the procedure flows to step S484 where the
Analyze Suspect Country Code Event service analyzes the
incoming event.
WO 95/11576 PCT/US94/11906
~174~2~
8s
Referring to FIG. 4C, the Analyze Suspect Country Code
Event service S484 is responsible for collecting country
code event information and determining whether a newly
received event should trigger an alert.
Upon receiving the event context data structure as an
argument, the service, at step S532, counts the number of
events presently recorded in the events database which meet
each of the following three conditions: (1) the database
event has the same subscriber ID as the present event; (2)
the database event type is "country event"; and (3) the
date of the database event is the same as the call date.
At step S534, if the number of database events counted
at step 5532 is less than a predetermined limit set by the
telecommunications service provider, the service flows to
step S542 which marks completion of the analysis. If,
however, the number of database events counted exceeds the
predetermined limit, the service flows to step 5536 where
a suspect country code alert is generated by adding a new
entry with alert type "suspect country code" to the alerts
database for this particular subscriber ID. The function
of step S534 is to prevent generating an alert every time
a suspect country code is called. The theory is that not
every user who calls the suspect country a few times is a
fraudulent user.
Next, at step S538, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database for this
particular subscriber ID.
WO 95/11576 217 ~ L~ ? ~ PCT/US94/11906
89
Next, at step 5540, the service sends the alert
generated at step S536 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step 5542 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step 5482, the alert manager procedure flows to step
S486. At this step, if the event type is a credit limit
event, the procedure flows to step 5488 where the Analyze
Credit Limit Event service analyzes the incoming event.
Referring to FIG. 4D, the Analyze Credit Limit Event
service S488 generates a new credit limit alert for every
incoming credit limit event. Upon receiving the event
context data structure as an argument, the service
generates a "credit limit" alert at step 5544 by adding a
new entry with alert type "credit limit" to the alerts
database for this particular subscriber ID.
Next, at step 5546, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next, at step S548, the service sends the alert
generated at step 5544 to the Evaluate Subscriber Condition
service 5522, described below.
Lastly, the service flows to step S550 which marks the
completion of the analysis for the present event and the
WO 95/11576 PCT/US94/11906
~17~~?_
alert manager procedure flows to step 5520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S486, the alert manager procedure flows to step
S490. At this step, if the event type is an overlap call
event, the procedure flows to step S492 where the Analyze
Call Overlap Event service analyzes the incoming event.
Referring to FIG. 4E, the Analyze Roaming Credit Limit
Event service S487 generates a new credit limit alert for
every incoming roaming credit limit event. Upon receiving
the event context data structure as an argument, the
service generates a "roaming credit limit" alert at step
5543 by adding a new entry with alert type "roaming credit
limit" to the alerts database for this particular
subscriber ID.
Next, at step S545, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next at step 5547 the service sends the alert
generated at step 5543 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step S549 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated as discussed below.
WO 95/11576 2 I 7 ~. ~ 2 5 PCT/US94/11906
91
Referring to FIG. 4A, if the event type did not match
at step S489, the alert manager procedure flows to step
5490. At this step, if the event type is an overlap call
event, the procedure flows to step S492 where the Analyze
Call Overlap Event service analyzes the incoming event.
Referring to FIG. 4F, the Analyze Call Overlap Event
service S492 generates a new overlap call alert for each
incoming overlap call event. The alert type will be either
"simultaneous call" or "geographic dispersion" depending
upon the subtype of the incoming event.
Upon receiving the event context data structure as an
argument, the service, at step S552, determines the sub-
type of the incoming event. If the event subtype is
"simultaneous call" the service flows to step S554 where a
variable, alert type, is set to "simultaneous call";
otherwise alert type is set to "geographic dispersion."
In either case, after the alert type has been
determined, the service, at step S558, generates an alert
by adding a new entry with an alert type equal to the value
held in the alert type variable to the alerts database for
this particular subscriber ID.
Next, at step S560, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next, at step S562, the service sends the alert
generated at step S558 to the Evaluate Subscriber Condition
service 5522, described below.
WO 95/11576 PCT/US94/11906
2174625
92
Lastly, the service flows to step 5564 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S490, the alert manager procedure flows to step
S494. At this step, if the event type is a duration event,
the procedure flows to step 5496 where the Analyze Duration
Event service analyzes the incoming event.
Referring to FIG. 4G, the Analyze Duration Event
service S496 is responsible for collecting incoming
duration event information and determining whether a newly
received event should trigger an alert.
Upon receiving the event context data structure as an
argument, the service, at step 5566, determines whether the
call date is the same as today's date -- that is, the date
on which the CCF record is being processed.
If the call date is today, no historical analysis
needs to be performed to determine whether the newly
received event affects the subscriber's condition on days
other than the call date; accordingly, the service flows to
step S568. Otherwise, the service flows to step S590.
At step S568, the service retrieves all past events
from the events database that satisfy each of the following
three conditions: (1) the retrieved event has the same
subscriber ID as the event being analyzed; (2) the
retrieved event is a duration-type event; and (3) the
WO 95!11576 217 4 6 ~ 5 PCT/US94/11906
93
retrieved event has a call date within five days of the
call date of the event being analyzed.
At step S570, the service tests whether the number of
events retrieved at step S568 is equal to three. If the
number of retrieved events is not equal to three, no alert
is generated and the service flows to step S578.
If, however, the number of retrieved events is equal
to three, the service flows to step S572 where an alert is
generated by adding a new entry, with alert type "3 in 5
Duration," to the alerts database for this particular
subscriber ID. A "3 in 5 Duration" alert indicates a
suspect increase in call duration because exactly three
duration-type events have occurred for this particular
subscriber ID within the last five days. Although one
embodiment of the present invention utilizes the particular
values three for the number of events, and five for the
number of days, other values that prove useful may be used
for this step.
At step S574 the service associates the event under
consideration with the newly generated alert by adding a
new entry to the alert-events database.
Next, at step S576, the service sends the alert
generated at step S572 to the Evaluate Subscriber Condition
service S522, described below.
Next, at step 5578, the service accumulates the
percentage increases of the five-day call duration moving
averages to obtain a total increase in the average over the
' past five days for each event retrieved at step S568.
WO 95/11576 ~ ; 7 ~ ~ ~ ~ PCT/US94/11906
94
Next, at step 5580, if the total percentage increase
as calculated at step 5578 is greater than or equal to 100%
-- indicating a suspect increase in call duration because
the five-day moving average call duration has doubled in
the last five days -- the service flows to step S582 and an
alert is generated by adding a new entry, with alert type
"Doubling Duration," to the alerts database for this
particular subscriber ID. If the total percentage increase
is less than 100%, no alert is generated and the service
flows to step S588 which marks its completion.
Assuming an alert was generated, the service, at step
5584, associates the present event with the newly generated
alert by adding a new entry to the alert-events database.
Then, at step S586, the service sends the alert
generated at step S572 to the Evaluate Subscriber Condition
service 5522, described below.
Lastly, the service flows to step 5588 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
If, at step S566, the service determined that the call
date of the event being analyzed was before today's date,
a historical analysis needs to be performed to determine
whether the newly received event affects the subscriber's
condition on days other than the call date. More
specifically, the event being analyzed needs to be applied
to the next f our days ( or up to today' s date ) as wel l as
WO 95/11576
PCT/US94/11906
the call date to determine if the event being considered
has made any changes to the alert status and subscriber
condition for those days. Accordingly, the service flows
from step S566 to step S590, where a place-holding
5 variable, date_index, is initially set to the call date of
the event being analyzed.
As illustrated in FIG. 4G, steps S592 through S608 are
identical to steps 5568 through S586, described above in
detail, so that no further discussion of these steps is
10 necessary. The service performs steps S592 through S6o8
once for each different value of date index. After the
date-index variable is iteratively incremented by one at
step S610, steps 5592 through S608 are repeated up to a
maximum of five iterations as long as the current value of
15 date_index is on or before today's date, as determined at
step S612. It should be noted that either or both a "3 in
5 Duration" alert or a "Doubling Duration" alert may be
generated for each separate value of date index.
Once the date-index loop is complete, the service
20 flows to step 5588 which marks the completion of the
analysis for the present event and the alert manager
procedure flows to step 5520 (see FIG. 4A) to determine
whether the subscriber's condition needs to be evaluated,
as discussed below.
25 Referring to FIG. 4A, if the event type did not match
at step S494, the alert manager procedure flows to step
5498. At this step, if the event type is an international
duration event, the procedure flows to step 5500 where the
WO 95/11576 PCT/US94/11906
2 ~ ,7425
96
Analyze International Duration Event service analyzes the
incoming event.
The Analyze International Duration Event service S500
is responsible for collecting incoming international
duration event information and determining whether a newly
received event should trigger an alert. Because this
service, illustrated in FIG. 4H, is nearly identical to the
Analyze Duration Event Service S496, discussed .above in
detail, except the event database is searched for
l0 international duration events and the possible alert types
are "3 in 5 International Duration" and "Doubling
International Duration," no further discussion of this
service is felt to be necessary.
Referring to FIG. 4A, if the event type did not match
at step S498, the alert manager procedure flows to step
S502. At this step, if the event type is a threshold
event, the procedure flows to step S504 where the Analyze
Threshold Event service analyzes the incoming event.
Referring to FIG. 4I, the Analyze Threshold Event
service S504 generates a threshold alert for each incoming
threshold event. The type of alert generated corresponds
to the type of event being analyzed (daily, five-day moving
average, or ten-day moving average).
Upon receiving the event context data structure as an
argument, the service, at step 5614, determines whether the
call date is the same as today's date -- that is, the date
on which the CCF record is being processed.
WO 95/11576 1 ~ ~ ~ PCT/US94/11906
97
If the call date is today no historical analysis needs
to be performed to determine whether the newly received
event affects the subscriber's condition on days other than
the call date; accordingly, the service flows to step S616.
Otherwise, the service flows to step S636.
At steps 5616 through S624, the service determines the
event type of the event being analyzed and, as appropriate
sets a temporary value-holder variable, alert type, in one
of steps 5618, S622, Or S626, to "Dally Threshold," "5 Day
Average Threshold," or "10 Day Average Threshold,"
respectively.
If the event type was not recognized, an inconsistency
in the system has been encountered, and the service flows
to step S628 where an error is logged to the error handling
server.
Assuming the event type was recognized, and the
alert type variable has been set as appropriate, the
service flows to step S630, where an alert is generated by
adding a new entry, with an alert type equal to the value
held in the alert type variable, to the alerts database for
this particular subscriber ID.
The service flows next to step 5632 where the event
being analyzed is associated with the newly generated alert
by adding a new entry to the alert-events database.
Then, at step 5634, the service sends the alert
generated at step S630 to the Evaluate Subscriber Condition
service S522, described below.
WO 95/11576 PCT/US94/11906
2174625
98
Lastly, the service flows to step S665 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
If, at step S614, the service determined that the call
date of the event being analyzed was before today's date,
a historical analysis needs to be performed to determine
whether the newly received event affects the subscriber's
condition on days other than the call date. More
specifically, the event being analyzed needs to be applied
to the next four days (or up to today's date) as well as
the call date to determine if the event being considered
has made any changes to the alert status and subscriber
condition for those days. Accordingly, the service flows
from step S614 to step S636, where a place-holding
variable, date_index, is initially set to the call date of
the event being analyzed.
As illustrated in FIG. 4I, steps 5638 through S650 are
identical to steps S616 through S628, described above in
detail, so that no further discussion of these steps is
necessary.
After the service has determined the event type, and
set the alert type variable as appropriate at steps S638
through S648, the service flows to step S652 where the
service searches the alerts database for a past alert which
satisfies each of the following three conditions: (1) the
retrieved alert call date is the same as the date held by
WO 95/11576 ~ ~ 5 PCT/US94/11906
99
date index; (2) the retrieved alert has the same subscriber
ID as the event being analyzed; and (3) the retrieved alert
type is the same as the value of the alert type variable,
as determined at steps S638 through S648.
If a matching alert is found during the search at step
5652, it indicates that the appropriate alert has already
been generated for this particular subscriber ID and there
is no need to generate a duplicate alert. Accordingly, the
service flows to step 5662 where the date index variable is
incremented by one.
. If, however, no matching alerts are found during the
alerts database search at step S652, the service flows to
step 5656 where an alert is generated by adding a new entry
with an alert type equal to the value held in the
alert type variable to the alerts database for this
particular subscriber ID.
The service flows next to step S658 where the event
being analyzed is associated with the newly generated alert
by adding a new entry to the alert-events database.
Then, at step 5650, the service sends the alert
generated at step S630 to the Evaluate Subscriber Condition
service 5522, described below.
The service performs steps 5652 through S662 once for
each different value of date index. After the date index
variable is iteratively incremented by one at step 5662,
steps S652 through S662 are repeated up to a maximum of
five iterations as long as the current value of date index
is on or before today's date, as determined at step S664.
WO 95/11576 PCT/US94/11906
2174625
100
It should be noted that a separate threshold alert of the
type held in the alert type variable may be generated for
each separate value of date index.
Once the date_index loop is complete, the service
flows to step S665 which marks the completion of the
analysis for the present event and the alert manager
procedure flows to step 5520 (see FIG. 4A) to determine
whether the subscriber's condition needs to be evaluated,
as discussed below.
l0 Referring to FIG. 4A, if the event type did not match
at step S502, the alert manager procedure flows to step
S506. At this step, if the event type is an international
threshold event, the procedure flows to step S508 where the
Analyze International Event service analyzes the incoming
event.
The Analyze International Threshold Event service S508
generates a threshold event for each incoming international
threshold event. The type of alert generated corresponds
to the type of event being analyzed (daily international,
five-day international moving average, or ten-day
international moving average). Because this service,
illustrated in FIG. 4J, is nearly identical to the Analyze
Threshold Event Service S504, discussed above in detail,
except the event database is searched for international
threshold events and the possible alert types are "Daily
International Threshold," "5 Day International Average
Threshold," and "10 Day International Average Threshold,"
W0 95/11576 2' 7 ~ ~ ~ ~ PCT/US94/11906
101
no further discussion of this service is believed
necessary.
Referring to FIG. 4A, if the event type did not match
at step S506, the alert manager procedure service flows to
step S510. At this step, if the event type is a velocity
event, the procedure flows to step 5512 where the Analyze
Velocity Event service analyzes the incoming event.
Referring to FIG. 4K, the Analyze Velocity Event
service 5512 is responsible for collecting incoming
velocity event information and determining whether a newly
received event should trigger an alert.
Upon receiving the event context data structure as an
argument, the service, at step S666, determines whether the
call date is the same as today's date -- that is, the date
on which the CCF record is being processed.
If the call date is today no historical analysis needs
to be performed to determine whether the newly received
event affects the subscriber's condition on days other than
the call date; accordingly, the service flows to step S668.
Otherwise, the service flows to step S690.
At step S668, the service retrieves all past events
from the events database which satisfy each of the
following three conditions: (1) the retrieved event has
the same subscriber ID as the event being analyzed; (2) the
retrieved event is a velocity-type event; and (3) the
retrieved event has a call date within five days of the
call date of the event being analyzed.
WO 95/11576 PCT/US94/11906
217~~~~2~
102
At step S670, the service tests whether the number of
events retrieved at step S668 is equal to three. If the
number of retrieved events is not equal to three, no alert
is generated and the service flows to step S678.
If, however, the number of retrieved events is equal
to three, the service flows to step S672 where an alert is
generated by adding a new entry with alert type "3 in 5
Velocity" to the alerts database for this particular
subscriber ID. A "3 in 5 Velocity" alert indicates a
suspect increase in call velocity because exactly three
velocity-type events have occurred for this particular
subscriber ID within the last five days. Although one
embodiment of the present invention utilizes the particular
values three for the number of events, and five for the
number of days, other values that prove useful may be used
for this step.
At step 5674 the service associates the event under
consideration with the newly generated alert by adding a
new entry to the alert-events database.
Next, at step 5676, the service sends the alert
generated at step S672 to the Evaluate Subscriber Condition
service S522, described below.
Next, at step S678, the service accumulates the
percentage increases of the five-day call velocity moving
averages to obtain a total increase in the average over the
past five days for each event retrieved at step S668.
Next, at step S680, if the total percentage increase
as calculated at step S678 is greater than or equal to 100%
WO 95/11576 217 4 ~ 2 ~ PCT/US94/11906
103
-- indicating a suspect increase in call velocity because
the five-day moving average call velocity has doubled in
the last five days -- the service flows to step S682 where
an alert is generated by adding a new entry, with alert
type "Doubling Velocity," to the alerts database for this
particular subscriber ID. If the total percentage increase
is less than 100%, no alert is generated and the service
flows to step S688 which marks its completion.
If an alert was generated, the service flows next to
step S684 where the event being analyzed is associated with
the newly generated alert by adding a new entry to the
alert-events database.
Then, at step S686, the service sends the alert
generated at step S672 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step 5688 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
If, at step S666, the service determined that the call
date of the event being analyzed was before today's date,
a historical analysis needs to be performed to determine
whether the newly received event affects the subscriber's
condition on days other than the call date. More
specifically, the event being analyzed needs to be applied
to the next four days (or up to today's date) as well as
the call date to determine if the event being considered
WO 95!11576 PCT/US94/11906
2 ~ i L~~25
104
has made any changes to the alert status and subscriber
condition for those days. Accordingly, the service flows
from step S666 to step S690, where a place-holding
variable, date-index, is initially set to the call date of
the event being analyzed.
As illustrated in FIG. 4F, steps S692 through 5708 are
identical to steps S668 through S686, described above in
detail, so that no further discussion of these steps is
thought necessary. The service performs steps S692 through
S708 once for each different value of date index. After
the date-index variable is iteratively incremented by one
at step S710, steps 5692 through S708 are repeated up to a
maximum of five iterations as long as the current value of
date_index is on or before today~s date, as determined at
step 5712. It should be noted that either or both a "3 in
5 Velocity" alert or a "Doubling Velocity" alert may be
generated for each separate value of date index.
Once the date_index loop is complete, the service
flows to step S688 which marks the completion of the
analysis for the present event and the alert manager
procedure flows to step S520 (see FIG. 4A) to determine
whether the subscriber's condition needs to be evaluated,
as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S510, the alert manager procedure flows to step
S514. At this step, if the event type is an international
velocity event, the procedure flows to step 5518 where the
WO 95/11576 217 4 E~ ~ ~ pCT~S94/11906
105
Analyze International Velocity Event service analyzes the
incoming event.
The Analyze International Velocity Event service S518
is responsible for collecting incoming international
velocity event information and determining whether a newly
received event should trigger an alert. Because this
service, illustrated in FIG. 4L, is nearly identical to the
Analyze Velocity Event Service 5512, discussed .above in
detail, except the event database is searched for
international velocity events and the possible alert types
are "3 in 5 International Velocity" and "Doubling
International Velocity," no further discussion of this
service is believed to be necessary.
Referring to FIG. 4A, if the event type did not match
at step S514, the alert manager procedure flows to step
S515. At this step, if the event type is an credit risk
event, the procedure flows to step S519 where the Analyze
Credit Risk Event service analyzes the incoming event.
Referring to FIG. 4M, the Analyze Credit Risk Event
service 5900 generates a new credit limit alert for every
incoming credit limit event. Upon receiving the event
context data structure as an argument, the service
generates a "credit risk" alert at step 5902 by adding a
new entry with alert type "credit risk" to the alerts
database for this particular subscriber ID.
Next, at step S904, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
WO 95/11576 . ., ,r / PCT/US94/11906
~ ; 7~E~?~
106
Next, at step S906, the service sends the alert
generated at step S902 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step S908 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step 5515 the alert manager procedure flows to step
S521. At this step, if the event type is a roaming credit
risk event, the procedure flows to step 5523 where the
Analyze Roaming Credit Risk Event service analyzes the
incoming event.
Referring to FIG. 4N, the Analyze Roaming Credit Risk
Event service S523 generates a new credit limit alert for
every incoming roaming credit limit event. Upon receiving
the event context data structure as an argument, the
service generates a "roaming credit risk" alert at step
5920 by adding a new entry with alert type "roaming credit
risk" to the alerts database for this particular subscriber
ID.
Next, at step S922, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next, at step S924, the service sends the alert
generated at step S920 to the Evaluate Subscriber Condition
service S522, described below.
WO 95/11576 2 i 7 4 6 2 5 pCT~S94/11906
107
Lastly, the service flows to step S926 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber s condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S521, the alert manager procedure flows to step
S525. At this step, if the event type is a suspect market
event, the procedure flows to step S527 where the Analyze
Suspect Market Event service analyzes the incoming event.
Referring to FIG. 40, the Analyze Roaming Suspect
Market Event service S527 generates a new suspect market
alert for every incoming suspect market event. Upon
receiving the event context data structure as an argument,
the service generates a "suspect market" alert at step S930
by adding a new entry with alert type "suspect market" to
the alerts database for this particular subscriber ID.
Next, at step 5932, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next, at step S934, the service sends the alert
generated at step S930 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step S936 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
WO 95/11576 PCT/US94/11906
2?74625
108
Referring to FIG. 4A, if the event type did not match
at step S525, the alert manager procedure flows to step
S529. At this step, if the event type is a overlap
validation request event, the procedure flows to step S531
where the Analyze Overlap Validation Request Event service
analyzes the incoming event.
Referring to FIG. 4P, the Analyze Overlap Validation
Request Event service S531 generates a new overlap
validation request alert for each incoming overlap
l0 validation request event. The alert type will be either
"simultaneous validation request" or "geographic
dispersion" depending upon the subtype of the incoming
event.
Upon receiving the event context data structure as an
argument, the service, at step S940, determines the sub
type of the incoming event. If the event subtype is
"simultaneous validation request" the service flows to step
S942 where a variable, alert type, is set to "simultaneous
validation request"; otherwise at step S944 alert type is
set to "geographic dispersion:"
In either case, after the alert type has been
determined, the service, at step 5946, generates an alert
by adding a new entry with an alert type equal to the value
held in the alert type variable to the alerts database for
this particular subscriber ID.
Next, at step S948, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
WO 95/11576 ~ ~ ~ ~ ~ 2 5 PCT/US94/11906
109
Next, at step S950, the service sends the alert
generated at step 5946 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step S952 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S529, the alert manager procedure flows to step
S533. At this step, if the event type is a propensity to
roam event, the procedure flows to step 5539 where the
Analyze Suspect Propensity to Roam Event service analyzes
the incoming event.
Referring to FIG. 4Q, the Analyze Roaming Market Event
service 5539 generates a new roaming market alert for every
incoming roaming market event. Upon receiving the event
context data structure as an argument, the service
generates a "roaming market" alert at step 5960 by adding
a new entry with alert type "roaming market" to the alerts
database for this particular subscriber ID.
Next, at step S962, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next, at step S964, the service sends the alert
generated at step S960 to the Evaluate Subscriber Condition
service S522, described below. Service then passes to step
S966 which completes the analysis for the present event.
WO 95/11576 PCT/US94/11906
2' 7~~~~2j
110
Referring to FIG. 4A, if the event type did not match
at step S537, the alert manager procedure flows to step
S541. At this step, if the event type is an extended
roaming event, the procedure flows to step 5551 where the
Analyze Suspect Extended Roaming Event service analyzes the
incoming event.
Referring to FIG. 4R, the Analyze Suspect Extended
Roaming Event service 5551 generates a new extended roaming
alert for every incoming extended roaming event. Upon
receiving the event context data structure as an argument,
the service generates an "extended roaming" alert at step
S970 by adding a new entry with alert type "extended
roaming event" to the alerts database for this particular
subscriber ID.
Next, at step 5972, the service associates the event
under consideration with the newly generated alert by
adding a new entry to the alert-events database.
Next, at step 5974, the service sends the alert
generated at step S970 to the Evaluate Subscriber Condition
service S522, described below:
Lastly, the service flows to step S976 which marks the
completion of the analysis for the present event and the
alert manager procedure flows to step S520 (see FIG. 4A) to
determine whether the subscriber's condition needs to be
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S537, the alert manager procedure flows to step
S541. At this step, if the event type is a validation
WO 95/11576 ~ i 7 4 6 2 5 pCT~S94/11906
111
request threshold event, the procedure flows to step S504
where the Analyze Validation Request Threshold Event
service analyzes the incoming event.
Referring to FIG. 4S, the Analyze Validation Request
Threshold Event service S551 generates a threshold alert
for each incoming threshold event. The type of alert
generated corresponds to the type of event being analyzed
(hourly, daily, daily high water mark, or 1-day moving
average).
Upon receiving the event context data structure as an
argument, the service, at steps S980, through S992,
determines the event type of the event being analyzed and,
as appropriate sets a temporary value-holder variable,
alert type, in one of steps 5982, S986, or S990 or S994, to
"Hourly Threshold," "Daily Threshold," "Daily High Water
Mark Threshold," or "1 Day Moving Average Threshold,"
respectively.
If the event type was not recognized, an inconsistency
in the system has been encountered, and the service flows
to step 5996 where an error is logged to the error handling
server.
Assuming the event type was recognized, and the
alert type variable has been set as appropriate, the
service flows to step S998, where an alert is generated by
adding a new entry, with an alert type equal to the value
held in the alert type variable, to the alerts database for
this particular subscriber ID.
WO 95/11576 PCT/US94/11906
i 74625 112
The service flows next to step 51000 where the event
being analyzed is associated with the newly generated alert
by adding a new entry to the alert-events database.
Then, at step 51002, the service sends the alert
generated at step S998 to the Evaluate Subscriber Condition
service S522, described below.
Lastly, the service flows to step 51004 which marks
the completion of the analysis for the present event and
the alert manager procedure flows to step S520 (see FIG.
4A) to determine whether the subscriber's condition needs
to be evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match
at step S515, the alert manager procedure flows to step
5516. At this step, because the alert manager has failed
to identify a recognizable event type in any of the steps
S478 through S515, an inconsistency in the system has been
encountered and an error is logged to the error handling
server. If, however, the event type matched in one of the
alert manager procedure steps 5478 through S515, and an
analysis was performed as described above, the alert
manager procedure, at step S520, tests whether one or more
new alerts were generated for the particular event being
analyzed. If the present event did not generate any new
alerts, the particular subscriber's condition remains
unchanged and the procedure flows to step S524 which marks
the completion of the alert manager procedure. Accordingly,
the alert manager procedure returns to step 5476 to await
arrival of the next event context data structure.
2174625
WO 95/11576 PCT/US94/11906
113
Turning again to step 5520, if at least one new alert
was generated for the present event, the procedure flows to
step 5522 to evaluate the present subscriber's condition.
Referring to FIG. 4T, the Evaluate Subscriber
Condition service 5522 is responsible for collecting all
past alert information from the alerts database related by
date to the newly generated alert. Using both the past and
present alert information, the service, using an "inference
engine" evaluates a particular subscriber's condition based
on a predetermined set of rules.
Upon receiving as input information that describes the
type and date of the newly generated alert, the service, at
step S716 loads the knowledge base -- that is, the
predetermined set of rules used to decide whether a
particular alert or combination of alerts for a particular
subscriber ID should trigger an alert-state to be generated
-- into the a work space for the service. For one
embodiment of the present invention the predetermined rules
are listed in Table I (see Appendix A). For the embodiment
of the present invention concerned with the use of pre-call
validation requests to detect potentially fraudulent
activity, the rules are substantially similar to those
illustrated in Appendix A.
Next, at step S718, the service retrieves all past
alerts from the alerts database which satisfy each of the
following three conditions: (1) the retrieved alert has
the same subscriber ID as the newly generated alert; (2)
the call date of retrieved alert is the same as the call
WO 95/11576 PCT/US94/11906
21 ?4~ 2
114
date of the newly generated alert; and (3) the retrieved
alert is "uncleared" -- that is, the alert has not been
investigated by a system operator and marked as "cleared"
in the alerts database.
Next, at step S720, for each of the uncleared alerts
retrieved at step S718, a corresponding alert-type is
"volunteered" -- or offered as information -- to the
inference engine. The available alert-types are as follows:
(1) suspect termination, (2) suspect country code, (3)
credit limit, (4) simultaneous call, (5) geographic
dispersion, (6) daily threshold, (7) daily international
threshold, (8) five-day average threshold, (9)
international five-day average threshold, (10) ten-day
average threshold, (11) international ten-day average
threshold, (12) 3-in-5 velocity, (13) doubling velocity,
(14) 3-in-5 international velocity, (15) doubling
international velocity, (16) 3-in-5 duration, (17) doubling
duration, (18) 3-in-5 international duration, (19) doubling
international duration, and (20) credit risk, (21) roaming
credit limit, (22) suspect market, (23) simultaneous
validation request, (24) roaming market, (25) extended
roaming, (26) hourly threshold, (27) daily threshold, (28)
daily high water mark, (29) 1 day moving average.
Next, at step S722, a "hypothesis," or answer, is
suggested to the inference engine. This directs the search
for the current alert-state of the subscriber along a path
associated with the newly generated alert, rather than
allowing the inference engine to search the entire
WO 95/11576 217 4 ~ ? J pCT/US94/11906
115
knowledge base. The hypothesis suggested is that an alert-
state exists that is related to the alert-type of the newly
generated alert.
Next, at step 5724, the service "operates" the
knowledge base -- that is, the inference engine is run
against the volunteered information and the suggested
hypothesis. The inference engine will prove the suggested
hypothesis to be either "true" or "false."
After the inference engine has been run, the service,
at steps 5726 and S728 determines whether a "red" alert
state, a "yellow" alert state, or no alert-state at all was
generated. A "red" alert-state corresponds to the most
severe indication of possible fraudulent telecommunication
activity that the fraud detection system registers. A
"yellow" alert-state similarly indicates the possibility of
fraudulent telecommunications activity, but to a lesser
extent than a red alert-state. If no alert-state was
generated, the subscriber's alert-state is left unchanged
and no additional processing is necessary. Accordingly,
the service flows to step S730 which marks the completion
of the evaluation. If, at step S726, the service
determines that a red alert-state was generated by this run
of the inference engine, the service flows to step 5742
where the subscriber's previous alert-state, -- that is,
before the present alert-state was generated -- is
retrieved from the alert-states database.
Next, at step S744, the service tests whether the
subscriber's previous alert-state was red. If so, there is
WO 95/11576 PCT/US94/11906
'7 / ~j r
2.. < < ~4~.J~.~
116
no need to generate an additional red alert-state, and the
service flows to step 5730 which marks completion of the
evaluation.
If, however, the subscriber's previous alert-state was
other than red, the service, at step S736, tests whether
the subscriber's previous alert-state was yellow. If so,
the service flows to step S748 where an occurrence of a
"system-cleared yellow alert state" is recorded in a
database -- the cleared-alert-states database. If the
subscriber's previous alert-state was normal, step S748 is
skipped and the service flows directly to step S750.
At step S750, the newly generated red alert-state is
recorded in the alert-states database for this particular
subscriber ID.
After notice of the newly generated and recorded red
alert-state is sent to the system operator at step S752,
the service flows to step 5730 which marks the completion
of the evaluation.
If, at step 5728, the service determines that a yellow
alert-state was generated by this run of the inference
engine, the service flows to step S732 where the
subscriber's previous alert-state, -- that is, before the
present alert-state was generated -- is retrieved from the
alert-states database.
Next, at step 5734, the service tests whether the
subscriber's previous alert-state was either yellow or red.
If so, there is no need to generate an additional yellow
WO 95/11576 217 4 6 2 5 pCT/US94I11906
117
alert-state, and the service flows to step S730 which marks
completion of the evaluation.
If, however, the subscriber's previous alert-state was
neither yellow nor red -- i.e., a "normal" alert-state -
the service f lows to step S7 3 6 where the newly generated
yellow alert-state is recorded in the alert-states database
for this particular subscriber ID.
After notice of the newly generated and recorded
yellow alert-state is sent to the system operator at step
S738, the service flows to step 5730 which marks the
completion of the evaluation.
If the Evaluate Subscriber Condition service S522
generates a new alert-state which differs from the
subscriber's present alert-state, the system operator is
notified via the user interface 117. The user interface
117 is a user-friendly Graphical User Interface (GUI) which
communicates and receives several items and types of
information to and from a system operator using words,
sounds, graphs, pictures, icons, pull-down and pop-up
menus, variable-sized windows and the like. The system
operator communicates information back to the user
interface using various input devices such as a keyboard,
mouse, touchscreen, trackball, voice-input, and related
devices. As shown in FIGS. 6, 9, and 11, the information
communicated to the system operator includes information
regarding a subscriber's vital statistics, alert-states,
history of alerts and events, and a graph of call velocity
for a particular subscriber. A system operator can
WO 95/11576 PCT/US94/11906
217L~ 62~
118
selectively choose which item or items of information he or
she wishes to view, and in what portion of the screen and
in what format the information is to be viewed.
Additionally, a system operator may control system
functions of the underlying digital computer on which the
fraud detection system is operating using the user
interface 117.
Initially, referring to FIG. 5A, before the user
interface may be accessed, the system operator must perform
a successful System login, as indicated at step S754. A
typical System Login Window 60, illustrated in FIG. 6,
requires an operator to enter both a login name 61 and a
password 63, and then click the login button 65.
Once a System login has been performed, the system
operator must subsequently login into the Control Window 70
as shown at step S755 in FIG. 5A. Depending on the system
privileges of the particular system operator, which are set
at the time of login to the Control Window 70, the system
operator may have several options, including performing
computer system maintenance and administrative functions
(Provision 71, Admin 72, and Diagnostics 74) in addition to
the Monitor Alerts 77, Investigate Subscriber 78, and
Select Affinity Groups 79 functions.
When the system operator selects Investigate
Subscriber 78 in the Control Window 70 (see FIG. 7) , the
user interface, at step S758, initiates the Investigate
Subscriber Window 80, a flowchart for which is shown in
FIG. 5B. Upon initiation, the Investigate Subscriber
WO 95/11576 217 4 6 2 5 pCT/US94/11906
119
Window 80, at step S764, prompts the system operator to
enter a subscriber ID to be investigated.
As shown in the Investigate Subscriber Window 80 in
FIG. 8, when a subscriber ID is selected from the select
subscriber list 81, the Investigate Subscriber Window 80
displays the particular subscriber's status data, that is,
certain information specific to the subscriber selected.
This information includes the subscriber's name 82a,
address 82b, MIN 82c, MSN 82d, alert states 83a, associated
alerts 83b, associated events 83c, information regarding
usage parameters -- indicated generally at 84, and any
subscriber comments 85 input by the system operator
regarding a particular subscriber ID.
Additionally, a system operator may identify a
subscriber to be investigated by entering a MSN 82c or a
MIN 82d in the Investigate Subscriber Window 80. If a
partial MIN is entered, a select subscriber list displays
a scrolled list of all subscribers having MINs that match
the inputted partial MIN. The system operator may select
one or more of the subscribers identified by the user
interface for investigation.
The system operator has several options under the
Investigate Subscriber Window 80, as indicated by steps
S768 through S784 in FIG. 5B, including the following:
graphing the call velocity of a particular subscriber (see
FIG. 9); marking a selected alert as "cleared"; marking a
selected alert as "uncleared"; allowing the system operator
to enter a textual comment in the alert field for a
WO 95/11576 PCT/US94/11906
217~~?~
120
particular subscriber; and quitting the Investigate
Subscriber Window 80. Several of these options are
represented as buttons at the bottom of the Investigate
Subscriber Window 80 in FIG. 8.
If the system operator clicks the Graphs button 86 in
the Investigate Subscriber Window 80, a graph of call
velocity for the selected subscriber is displayed. A
typical velocity graph for a single subscriber is shown in
FIG. 9. Referring to FIG. 9, the vertical axis represents
number of calls placed and the horizontal axis represents
time, with each number corresponding to a separate day. As
shown in the legend, the solid line indicates the ten-day
moving average call velocity, the dotted line indicates the
five-day moving average velocity, and the dashed line
indicates daily call velocity for the selected subscriber
ID. The usage trends represented by the three lines in
FIG. 9 indicate telecommunications usage typical of a
fraudulent user. For example, at day 58 the five-day moving
average call velocity (138) is greater than the ten-day
moving average call velocity (112) and shows an increase of
almost 28% over the five-day moving average call velocity
at day 57 (108). The usage at day 58, therefore, would be
likely to generate a call velocity event for this
particular subscriber based on the subscriber s pattern of
past usage. Depending upon the occurrence of other events
generated for the same subscriber, as discussed above, an
alert, and consequently an alert-state, may also be
generated for this particular subscriber, thereby
211625
WO 95/11576 PCT/US94/11906
121
indicating the possibility of fraudulent telecommunications
usage.
If the system operator clicks the Clear Alert State
button 87b in the Investigate Subscribers Window 80, the
selected alert-state will be marked as "cleared" in the
alert-states database. Accordingly, all of the underlying
alerts which triggered the selected alert-state will be
marked as "cleared" in the alerts database and will no
longer be considered by the evaluate subscriber condition
to service in generating alert-states for the selected
subscriber.
If the system operator clicks the Unclear Alert State
button 87a in the Investigate Subscribers Window 80, the
clearing operation described above is undone and the
underlying alerts which generated the selected alert-state
once again become available to the evaluate subscriber
condition service in generating alert-states for a
particular subscriber.
If the system operator clicks the Comment button 88 in
the Investigate Subscribers Window 80, the user interface
accepts and saves a textual comment, possibly regarding the
status and results of an investigation performed for the
selected subscriber ID, in the Subscriber Comments field 85
of the Investigate Subscriber Window 80.
Lastly, if the system operator wishes to quit, the
Investigator Subscribers Window 80 is terminated.
When the system operator selects Monitor Alerts 77 in
the Control Window 70 (see FIG. 7), the user interface, at
WO 95/11576 PCT/iJS94/11906
'~ 9 -l , i ~ '~ .-
C r ; t L'
122
step S762, initiates the Monitor Alerts Window 92 (see FIG.
11), a flowchart for which is shown in FIG. 5C. If the
system operator wishes to select a New Affinity Group to be
monitored, the operator selects Affinity Groups Option 79
in the Control Window, displaying Window 90, as shown in
FIG. 10, and the operator selects the appropriate Affinity
Group or Groups corresponding to combinations of npa and
nxx for a geographic region that the system operator wishes
to monitor. The selected Affinity Groups are displayed in
the top-half of the Monitor Alerts Window 92 depicted in
FIG. 11 under the heading Currently monitoring Affinity
Groups 93. The selection of Affinity Groups to be monitored
may be further changed by selecting the Select Affinity
Groups option 79 in the Control Window 70 (see FIG. 7).
Next, at step 5792, the operator has the option to
select the alert-state level to be monitored. At step
S794, the operator selects a new alert-state level (either
yellow 95a or red 95b) to monitor, as shown in the Monitor
Alerts Window 92 in FIG. 11 under the heading Select alert
level 95.
Next, at step S796, the Window displays a scrolled
list of alert-states in the bottom-half of the Monitor
Alerts Window 92, under the heading Realtime Alert States
96, corresponding to the alert-state level selected and the
Affinity Groups selected.
At step S798, if the operator chooses to investigate
a specific alert-state displayed in the scrolled list by
clicking the Investigate button 97 at the bottom of the
WO 95/11576 217 4 ~ ? ~ PCT/US94/11906
123
Monitor Alerts Window 92, the subscriber-specific
information is displayed as shown in FIG. 8. Effectively,
this operation invokes the Investigate Subscriber Window 80
directly from the Monitor Alerts Window 92 for a single
subscriber ID.
Additionally, the system operator may request a report
to be generated and printed at steps S802 and S804 , or
quit from the Monitor Alerts Window 92 at steps .5810 and
S786.
Thus, a fraud detection system is provided which
possesses several features and advantages. Initially, it
should be noted that although the fraud detection system
was described from the perspective of a single CCF or CPF
record processed in serial fashion, in actual operation the
fraud detection system can process multiple CCF or CPF
records in parallel, thereby resulting in increased
through-put and shorter overall processing time.
Second, the present fraud detection system detects
potentially fraudulent activity on a subscriber-specific
basis rather than on a system-wide basis. Because the
present invention operates by detecting, for each
individual subscriber, an abnormal deviation in
telecommunication activity as compared with that particular
subscriber's typical telecommunication activity, an
individualized fraud detection system is provided that
performs with equal success regardless of whether a
subscriber is typically a low, medium or high volume user.
WO 95/11576 PCT/US94/11906
2174625
124
Third, the present fraud detection system is capable
of indicating potentially fraudulent activity by detecting
an abnormal deviation in usage without regard to the type
of fraudulent activity involved, whether it be cloning
fraud, tumbling fraud, tumbling-clone fraud, calling card
fraud, subscriber fraud, stolen cellular telephone fraud,
etc.
Fourth, the present invention provides an apparatus
and method for detecting potentially fraudulent
telecommunications activity based solely on normal usage
parameters such as call duration, call velocity, call
overlap, and the number called. Because the fraud detection
system of the present invention operates merely by
connecting the system to existing network facilities, and
requires no modification of the either the
telecommunications network equipment or the individual
cellular telephones, the present fraud detection system is
compatible with most, if not all, existing
telecommunications systems.
Fifth, the fraud detection system of the present
invention is not limited merely to detecting potentially
fraudulent activity in cellular telecommunications systems.
The present fraud detection system is adaptable to detect
potentially fraudulent usage in other telecommunications
systems that utilize a unique identifier for each
individual subscriber to limit access to the
telecommunications system. In such a system, a legitimate
subscriber, intending to pay for services used, will tend
WO 95/11576 2 ~ 7 4 6 L ~ pCT~S94/11906
125
to use the services more sparingly than a fraudulent user
who has no intention of ever paying for services used.
Once a fraudulent user had misappropriated an otherwise
legitimate subscriber identifier to gain access to the
service-providing system, an abnormal increase or other
deviation in activity for the particular misappropriated
subscriber identifier would tend to result. Therefore, by
detecting an abnormal increase or other abnormal behavior
in the service usage patterns for a particular subscriber
identifier, the present fraud detection system can detect
potentially fraudulent activity based on normal usage
parameters in the telecommunications system to which it is
connected.
One example, inter alia, is a telephone calling card
system, wherein each subscriber has a unique calling card
number which permits a subscriber to place toll calls which
are subsequently billed to the subscriber assigned to the
calling card number used to place the calls. Each use of
the calling card calling card number generates a separate
record containing substantially the same information as a
cellular telephone system CDR record. The switch interface
of the present fraud detection system can be easily
modified to accept call data records in differing formats.
Therefore, upon inputting calling card call data records
into the present fraud detection system, potentially
fraudulent calling card activity would be detected in the
manner described above.
WO 95/11576 PCT/US94/11906
2 i 74E~2~ 126
Sixth, the fraud detection system of the present
invention provides an interactive GUI display system that
allows a system operator to view several items of
information concurrently, such as the history of alerts and
events which led to an alert-state for a particular
subscriber; information specific to each subscriber; and a
graph of call velocity for a particular subscriber. In
this way, the present fraud detection system conveniently
provides the system operator with all the relevant
information that triggered the fraud detection system to
indicate that a particular subscriber ID is potentially
suspected of fraudulent activity.
Further, and among other advantages, because several
of the fraud detection parameters -- such as the maximum
percentage increases in call duration and call velocity
allowed before an event is generated, subscriber-specific
credit limits, and the list of suspect numbers and country
codes -- are easily modified by a system operator, the
present fraud detection system can be readily tailored to
satisfy the unique requirements of any telecommunications
system to which it is attached.
Although the invention has been described in detail,
it should be understood that various changes, substitutions
and alterations can be made herein without departing from
the spirit and scope of the invention as defined by the
appended claims.
214625
WO 95/11576 PCT/US94/11906
127
APPENDIX A
TABLE I: .
RULE . Rule 1
If
red_condition is precisely equal to 1
Then alerts_complete
is confirmed.
RULE . Rule 2
If
there is evidence of eval_country
code_rules
And red_condition is precisely
equal to 1
Then country code_red_condition
is confirmed.
RULE . Rule 3
If
2 there is evidence of eval_credit_limit_rules
0
Aad red_condition is precisely
equal to 1
Then credit_limit_red_condition
is confirmed.
2 RULE . Rule 4
5
If
there is evidence of eval_daily
intl_thresh_n~les
And red_condition is precisely
equal to 1
Then daily intl_thresh_red_condition
3 is confirmed.
0
RULE . Rule 5
If
there is evidence of eval_daily
thresh_rules
3 And red_condition is precisely
5 equal to 1
Then daily thresh red-condition
is confirmed.
RULE . Rule 6
4 If
0
there is evidence of eval_duration_rules
And red_condition is precisely
equal to 1
Then duration red_condition
is confirmed.
45
RULE . Rule 7
If
suspect country code_alert is precisely
equal to 1
And intl_velocity_alert is precisely
equal to 1
5 Then eval_country code_rules
0
is confirmed.
And 1 is assigned to red condition
WO 95/11576 _ PCT/US94/11906
2i7~~2~
128
RULE . Rule 8
If
credit limit_alert is precisely
equal to 1
Then eval_credit_limit_rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 9
If
daily intl_thresh_alert is precisely
equal to 1
And intl_velocity alert is precisely
equal to 1
Then eval-daily intl_thresh rules
is confirmed.
And 1 is assigned to red_condition
RULE . Rule 10
If
daily thresh_alert is precisely
equal to 1
And velocity_alert is precisely
equal to 1
2 Then eval_daily thresh rules
0
is confirmed.
And 1 is assigned to red condition
RULE . Rule 11
2 If
5
duration_alert is precisely equal
to 1
And velocity-alert is precisely
equal to 1
Then eval_duration_rules
is confirmed.
3 And 1 is assigned to red condition
0
RULE . Rule 12
If
five_day iatl_thresh_alert is precisely
equal to 1
3 And intl_velocity_alert is precisely
5 equal to 1
Then eval_five_day intl_thresh_rnles
is confirmed.
And 1 is assigned to red condition
4 RULE . Rule 13
0
If
five_day thresh_alert is precisely
equal to 1
And velocity_alert is precisely
equal to 1
Then eval_five day thresh rules
4 is confirmed.
5
And 1 is assigned to red condition
RULE . Rule 14
If
5 geographic dispersion_alert is precisely
0 equal to 1
Then eval_geographic disp_rules
is confirmed.
And 1 is assigned to red condition
217425
WO 95/11576 PCT/US94111906
129
RULE . Rule 15
If
intl_duration_alert is precisely equal to 1
And intl_velocity-alert is precisely equal to 1
Then eval_intl duration_rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 22
If
intl_velocity_alert is precisely equal to 1
And suspect term_alert is precisely equal to 1
Then eval_intl velocity rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 21
If
intl_velocityalert is precisely equal to 1
2 0 And suspect country code_alert is precisely equal to 1
Then eval_intl velocityrules
is confirmed.
And 1 is assigned to red condition
2 5 RULE . Rule 20
If
intl_velocityalert is precisely equal to i
And daily intl thresh_alert is precisely equal to 1
Then eval_intl_velocityrules
3 0 is confirmed.
And 1 is assigned to red condition
RULE . Rule 19
If
3 5 intl_velocityalert is precisely equal to 1
And five day intl-thresh_alert is precisely equal to 1
Then eval_intl velocityrules
is confirmed.
And 1 is assigned to red_condition
RULE . Rule 18
If
intl_velocityalert is precisely equal to 1
And ten_day intl_thresh_alert is precisely equal to 1
4 5 Then eval-intl velocity rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 17
. 50 If
intl_velocity_alert is precisely equal to 1
And velocity alert is precisely equal to 1
Then eval-intl_velocityrules
is confirmed.
5 5 And 1 is assigned to red condition
WO 95/11576 PCT/US94/11906
? i ~L1~~5
130
RULE . Rule 16
If
intl_velocity_alert is precisely
equal to 1
And intl duration_alert is precisely
equal to 1
Then eval_intl_velocity rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 23
If
simultaneous_call_alert is precisely
equal to 1
Then eval_simultaneous_call_rules
is confirmed.
And 1 is assigned to red_condition
RULE . Rule 25
If
suspect term_alert is precisely
equal to 1
And velocity_alert is precisely
equal to 1
2 0 Then eval-suspect term rules
is confirmed.
Aad 1 is assigned to red condition
RULE . Rule 24
2 5 If
suspect term_alert is precisely equal to 1
And intl velocity_alert is precisely equal to 1
Then eval-suspect term rules
is confirmed.
3 0 And 1 is assigned to red condition
RULE . Rule 26
If
ten day intl thresh alert is precisely equal to 1
3 5 And intl velocity-alert is precisely equal to 1
Then eval_ten_day intl_thresh rules
is confirmed.
And 1 is assigned to red condition
4 0 RULE . Rule 27
If
ten_day thresh_alert is precisely equal to 1
And velocity_alert is precisely equal to 1
Then eval-ten-day thresh-rules
4 5 is confirmed.
And 1 is assigned to red condition
RULE . Rule 33
If
5 0 velocity_alert is precisely equal to 1
And suspect term_alert is precisely equal to 1
Then eval-velocity-rules
is confirmed.
And 1 is assigned to red_condition
WO 95/11576 21 l 4 ~ ~ ~ PCT/US94/11906
131
RULE . Rule 32
If
velocity_alert is precisely equal
to 1
And daily thresh_alert is precisely
equal to 1
Then eval velocity_rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 31
If
velocity_alert is precisely equal
to 1
And five_day thresh_alert is precisely
equal to 1
Then eval velocity_rules
is confirmed.
And 1 is assigned to red condition
RULE . Rule 30
If
velocity-alert is precisely equal
to 1
2 0 And ten_day thresh_alert is precisely
equal to 1
Then eval velocity rules
is confirmed.
And 1 is assigned to red condition
2 5 RULE . Rule 29
If
velocity alert is precisely equal to 1
And iatl_velocity_alert is precisely equal to 1
Then eval velocity_rules
3 0 is confirmed.
And 1 is assigned to red condition
RULE . Rule 28
If
3 5 velocity alert is precisely equal to 1
And duration_alert is precisely equal to 1
Then eval velocity_rules
is confirmed.
And 1 is assigned to red_condition
RULE . Rule 34
If
there is evidence of eval_five_day intl thresh_rules
And red_condition is precisely equal to 1
4 5 Then five_day intl_thresh_red_condition
is confirmed.
RULE . Rule 35
If
5 0 there is evidence of eval_five_day thresh_rules
And red_condition is precisely equal to 1
Then five_day thresh_red_condition
is confirmed.
WO 95/11576 PCT/US94/11906
21 ?a625 -
132
RULE . Rule 36
If
there is evidence of eval_geographic disp_rules
And red_condition is precisely equal to 1
Then geographic disp_red condition
is confirmed.
RULE . Rule 37
If
Set Strategy to ~PWTRUE=FALSE;~PWFALSE=FALSE;~PWNOTKNOWN=
FALSE;~PFACTIONS=FALSE;~PTGAT
Then initialize strategy
is confirmed.
RULE . Rule 38
If
there is evidence of eval_intl_duration_rules
And red_condition is precisely equal to 1
Then intl_duration_red_condition
2 0 is confirmed.
RULE . Rule 39
If
there is evidence of eval_intl_velocity_rules
2 5 And red_condition is precisely equal to 1
Then intl_velocity_red_condition
is confirmed.
RULE . Rule 40
3 0 If
there is evidence of eval simultaneous call rules
And red_condition is precisely
equal to 1
Then simultaneous_call_red_condition
is confirmed.
35
RULE . Rule 41
If
there is evidence of eval_suspect
term_rules
And red_condition is precisely
equal to 1
4 0 Then suspect term_red_condition
is confirmed.
RULE . Rule 42
If
4 5 there is evidence of eval_ten_day intl_thresh_rules
And red_condition is precisely equal to 1
Then ten_day intl thresh_red_condition
is confirmed.
5 0 RULE . Rule 43
If
there is evidence of eval_ten_day thresh rules
And red_condition is precisely equal to 1
Then ten_day thresh_red_condition
5 5 is confirmed.
WO 95/11576 7 ~ PCT/US94/11906
133
RULE . Rule 44
If
there is evidence of eval_velocity_rules
And red condition is precisely equal to 1
Then velocity_red_condition
is confirmed.
RULE . Rule 45
If
alert count is greater than 2
And red condition is precisely equal to 0
Then yellow condition set
is confirmed.
And 1 is assigned to yellow condition
PCT/US94/11906
WO 95/11576 217 4 6 2 5
134
APPENDIX B
DETERMINATION
OF AIRLINE
DISTANCES
1. Lone Distance Messaee Telecommunications Service
To determine
the rate
distance
between any
two MSCs
proceed ss
follows:
a. Obtain the "V" aad "H" coordinates for each MSC.
"V," the vertical coordinate, is
equivalent to longitude; "H," the horizontal coordinate,
is equivalent to latitude.
b. Obtain the difference between the "V" coordinates
o the two MSCs. Obtain the
difference between the "H" coordinates.
Note: The difference is always obtained by subtracting
the smaller
coordinate from the larger coordinate.
c. Divide each of the differences obtained in b. by
three, rounding each quotient to the
nearer integer.
d. Square these two integers and add the two squares.
If the sum of the squares is
greater than 1777, divide the integers obtained
in c. by three and repeat step d.
Repeat this process until the sum of the squares
obtained in d. is less than 1778.
2 5 e. The number of successive divisions by three in
steps c. and d. determines the value
of "N". Multiply the final sum of the two squares
obtained in step d. by the
multiplier specified in the following table for
this value of "N" preceding:
N Multiplier Minimum Rate
3 0 Mileage
1 0.9 _
2 8.1 41
3 72.9 121
4 656.1 361
3 5 5 5,904.9 1,081
6 53,144.1 3,241
f. Obtain square root of product in e. and, with resulting
fraction, round up to next
higher integer. This is the message rate mileage
except that when the mileage so
4 0 obtained is less than the minimum rate mileage
shown in e. preceding, the minimum
rate mileage corresponding to the "N" value is applicable.
Example:
4 5 The message rate distaace is required betweea Detroit, Michigan and
Madison, Wisconsin.
V H
(a) Detroit, Michigan 5536 2828
5 0 Madison, Wisconsin 5887 3796
(b) difference 351 968
(cl) dividing each difference by three and rounding to nearer integer = 117
aad 323
(dl) squaring integers and adding, 117X117 = 13,689
217425
WO 95/11576 PCT/US94/11906
135
323X323 = 104.329
sum of squared integers 118,018
sum of squared integers is greater than 1777, so
divide integers in (cl) by three aad
repeat (dl)
(c2) dividing integers in (ci) by three and rounding
= 39 and 108
(d2) squaring integers and adding, 39X39 = 1,521
108X108 = 11.664
sum of squared integers 13,185
sum of squared integers is greater than 1777, so
divide integers in (c2) by three and
(c3) dividing integers in (c2) by three and rounding
= 13 and 16
(d3) squaring integers and adding, 13X13 = 169
36X36 = 1.296
2 0 sum of squared integers 1,465
This sum of squared integers is less than 1778
and was obtained after three
successive divisions by three, therefore, "N" =
3.
2 5 (e) Multiply final sum of squared integers 1,465
by factor 72.9 (corresponding to "N" = 3) X 72.9
= 106,798.5
(f) Square root of 106,798.5 = 326 and a fraction,
which is rounded up to 327 miles
3 0 (fractional miles being considered full miles).
The 327 miles is larger than the
minimum of 121 rate miles applicable when "N" =
3, so the message rate mileage
is 327 miles.
2. Interexchan~e Distances
35
To determine the rate
distance betwe~ any
two MSCs proceed
as follows:
a. Obtain the "V" and "H" coordinates for each MSC.
b. Obtain the difference between the "V" coordinates
of the two MSCs. Obtain the
4 0 difference between the "H" coordinates.
Note: The Difference is always obtained by subtracting
the smaller
coordinate from the larger coordinate.
4 5 c. Square each difference obtained in b. above.
d. Add the squares of the "V" difference and the "H" difference obtained in c.
above.
e. Divide the sum of the squares obtained in d. above by 10. Round to the next
higher
whole number if any fraction is obtained.
f. Obtain the square root of the result obtained in e. above. This is the rate
distance
5 0 is miles. (Fractional miles being considered as whole miles).
Example:
The rate distance is required between St. Paul, Minnesota and Osceola,
Wisconsin.
V H
WO 95/11576 PCT/US94/11906
217425
136
St. Paul, Minnesota 5776 4498
Osceola, Wisconsin 5677 4477
difference 99 21
squared 9,801 + 441 = 10,242
10.242 - 1,024.2
square root of 1,025 - 32.01 - 33 airline miles
3. Intraexchange Distances
10 To determine the rate distance between any two MSCs proceed as follows:
a. Obtain the "V" and "H" coordinates for each MSC.
b. Obtain the difference between the "V" coordinates of the two MSCs. Obtain
the
difference between the "H" coordinates.
Note: The Difference is always obtained by subtracting the smaller coordinate
from the larger coordinate.
c. Square each difference obtained in b. above.
2 0 d. Add the squares of the "V" difference and the "H" difference obtained
in c. above.
e. Divide the sum of the squares obtained in d. above by 10.
f. Obtaia the square root of the result obtained in e. above.
Express this result with two decimal places. This is the distance in miles.
Fractions
are rounded to the next higher half mile.
Example:
The rate distance is required between two MSCs in the Orange, New Jersey
exchange.
NPA NXX V H
201 675 (East Orange) 5015 1440
3 5 201 736 (West Orange) 5014 1448
difference 1 8
squared 1 64 = 65
4 0 _65 = 6.5
square root of 6.5 - 2.55 - 3 airline miles
