Phoenix Rising BBS/phoenixrising.zip/phoenixrising/cellular/patent-1.txt

INI File | 1995-01-06 | 83KB | 1,422 lines

[ONLINE PATENT INFORMATION PROVIDED BY PHOENIX RISING COMMUNICATIONS]

PATN  Patent Bibliographic Information


WKU     Patent Number:                           05345595
SRC     Series Code:                             7
APN     Application Number:                      9755128
APT     Application Type:                        1
ART     Art Unit:                         261
APD     Application Filing Date:                 19921112
TTL     Title of Invention:                      Apparatus and method for
                                                 detecting fraudulent
                                                 telecommunication activity
ISD     Issue Date:                              19940906
NCL     Number of Claims:                        14
ECL     Exemplary Claim Number:                         1
EXP     Primary Examiner:                        Urban; Edward F.
NDR     Number of Drawings Sheets:               46
NFG     Number of Figures:                       36

INVT  Inventor Information
NAM     Inventor Name:                           Johnson; Eric A.
CTY     Inventor City:                           Longmont
STA     Inventor State:                          CO

INVT  Inventor Information
NAM     Inventor Name:                           Liss; Michael D.
CTY     Inventor City:                           Nederland
STA     Inventor State:                          CO

INVT  Inventor Information
NAM     Inventor Name:                           Jensen; Flemming B.
CTY     Inventor City:                           Sandy
STA     Inventor State:                          UT

ASSG  Assignee Information
NAM     Assignee Name:                           Coral Systems, Inc.
CTY     Assignee City:                           Longmont
STA     Assignee State:                          CO
COD     Assignee Type Code:                      02

CLAS  Classification
OCL     Original U.S. Classification:                          455 331
XCL     Cross Reference Classification:                        455 531
XCL     Cross Reference Classification:                        455 677
XCL     Cross Reference Classification:                        379 60
EDF     International Classification Edition Field:            5
ICL     International Classification:                          H04Q  700
FSC     Field of Search Class:                                 455
FSS     Field of Search Subclass:     33.1;34.1;34.2;56.1;67.1;67.7;53.1
FSC     Field of Search Class:                                 379
FSS     Field of Search Subclass:                       58;59;145;60

UREF  U.S. Patent Reference
PNO     Patent Number:                                  4182934
ISD     Issue Date:                                     19800100
NAM     Patentee Name:                                  Keys et al.
OCL     Original U.S. Classification:                          179  7

UREF  U.S. Patent Reference
PNO     Patent Number:                                  4893330
ISD     Issue Date:                                     19900100
NAM     Patentee Name:                                  Franco
OCL     Original U.S. Classification:                          379 91

UREF  U.S. Patent Reference
PNO     Patent Number:                                  4953198
ISD     Issue Date:                                     19900800
NAM     Patentee Name:                                  Daly et al.
OCL     Original U.S. Classification:                          455 34.2

UREF  U.S. Patent Reference
PNO     Patent Number:                                  4955049
ISD     Issue Date:                                     19900900
NAM     Patentee Name:                                  Ghisler
OCL     Original U.S. Classification:                          379 58

UREF  U.S. Patent Reference
PNO     Patent Number:                                  5091942
ISD     Issue Date:                                     19920200
NAM     Patentee Name:                                  Dent
OCL     Original U.S. Classification:                          380 46

UREF  U.S. Patent Reference
PNO     Patent Number:                                  5109408
ISD     Issue Date:                                     19920400
NAM     Patentee Name:                                  Greenspan et al.
OCL     Original U.S. Classification:                          379197

UREF  U.S. Patent Reference
PNO     Patent Number:                                  5144649
ISD     Issue Date:                                     19920900
NAM     Patentee Name:                                  Zicker et al.
OCL     Original U.S. Classification:                          379 59

OREF  Other Reference

Subscriber Computing, Inc. news release entitled "Subscriber Computing,
Inc. Unveils Advanced Version of FraudWatch.TM.", Mar. 1, 1993, Irvine,
Calif., 3 pages (no author given).

Cellular Technical Services Company (CTS) product literature on the
Clonerwatch.TM. product, (no author, relevant pages, date or place of
publication given).

EDS Personal Communications Corp. News Release, "EDS Personal
Communications Corporation Announces Comprehensive Fraud Solutions and
Capabilities", Mar. 2, 1993, Waltham, Mass., 3 pages (no author given).

EDS Personal Communications Corp., News Release entitled, "EDS Personal
Communications Corporation Tackles Fraud with New `Strategic Partnership`
Plan." Waltham, Mass., 4 pages (no author or date of publication given).

"Telemate Fraud Software Ready", Jul. 13, 1992. Communications Week p. 24.

"Hacon System Self-Activates Computer Fraud & Security Bulletin", Nov.
1992, Elsevier Advanced Technology Publications.

Lewyn, Mark, "Phone Sleuths Are Cutting Off The Hackers . . . ", Jul. 13,
1992, Business Week.

LREP  Legal Information
FRM     Legal Firm:                              Sheridan Ross & McIntosh

ABST  Abstract

An apparatus for detecting potentially fraudulent telecommunication
activity, comprising a digital computer; interface, operatively connected
to the digital computer, for receiving a call information record for each
call involving a particular subscriber; comparator operating within the
digital computer, for comparing a parameter of the particular subscriber's
current usage with a subscriber-specific pattern of the particular
subscriber's historical usage; and an output for outputting an indication
of a potentially fraudulent call based upon a result of the comparison
performed by the comparator.

BSUM  Brief Summary

                        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.

     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.

     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 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, 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 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
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.

     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 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 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
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
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 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.

     These and other features of the present invention will become evident
from the detailed description set forth hereafter with reference to the
accompanying drawings.

DRWD  Drawing Description

                       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. 1A is a diagram illustrating a typical cellular telecommunications
network.

     FIG. 1B is a block diagram of a telecommunications fraud detection system
according to one embodiment of the present invention.

     FIG. 2 is a block diagram showing the components of a Common Call Format
(CCF) record according to one embodiment of the present invention.

     FIGS. 3A-3L are flowcharts of the Event Manager procedure.

     FIGS. 4A-4L 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.

DETD  Detail Description

                   DETAILED DESCRIPTION OF THE INVENTION

     A detailed description of an apparatus and method for detecting
potentially fraudulent telecommunications activity, is set forth below with
reference to the figures.

     A diagram illustrating a typical cellular telecommunications network is
illustrated in FIG. 1A. 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. 1A, 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.

     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.

     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). 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 is a three-digit area code, nxx is a three-digit
prefix which identifies the serving switch, and xxxx is a four-digit
suffix which identifies the individual subscriber or physical line number.
The combination of the npa and nxx components form a number which
identifies 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. For 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 identifying 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 single home MSC
corresponding to 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 originates a cellular call from a region other than his or her home
MSC region is referred to as a "roamer." Because only the subscriber's
home MSC maintains a database of that subscriber's identity and status, a
MSC handling a roamer call is unable to verify whether or not the
subscriber MIN and MSN received for a call are valid. Accordingly, for
each roamer call handled 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.

     FIG. 1B 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 event manager 113, the alert manager 115, 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 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).

     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
format--a CCF record is passed 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 both with past subscriber-specific usage information
and with certain predetermined conditions to determine whether this
particular CCF 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 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. 1B, a more detailed description of the fraud detection
system 107 is provided as follows. A cellular telephone 103 communicates
with a MSC 101 to place 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. The MSC 101 creates a separate CDR record for
each call that it handles, whether cellular originated or cellular
terminated. Each individual MSC 101 is connected to a fraud detection
system 107 which receives CDR records as input from the MSC. The CDR input
read directly from the MSC 101 into the fraud detection system 107
corresponds to calls handled by that MSC for its home subscribers. CDR
records not involving the MSC's home subscribers are sent to a clearing
house to generate roamer tapes to be sent 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.

     Additionally, the fraud detection system 107 receives input from a roamer
tape 109 by means of a magnetic tape reader (not shown) in a format
referred to as the CIBER format. The combination of the home MSC 101 input
and the roamer tape 109 input represents all of the call activity for a
MSC's home subscribers, regardless of the geographic region in which the
calls were originated or terminated.

     The call information input, whether from the roamer tape 109 or from the
home MSC 101, 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.

     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. 2 illustrates one embodiment of the present invention wherein the
CCF Record 201 comprises sixteen 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 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 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 field 213 holds a value of "0" if 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 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 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 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.

     Referring again to FIG. 1B, 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. 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 the present CCF record both with past
subscriber-specific usage information and with certain predetermined
conditions to determine whether this particular CCF record should trigger
an "event."

     Referring to FIG. 3A, the services indicated by steps S303 through S309
are referred to as "call event" checks. In the call event checks the CCF
record is compared to a set of predetermined conditions to determine
whether or not an event should be generated for this CCF 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.

     The services indicated by steps S311 through S321 are referred to as
"pattern event" checks. In the pattern event checks the CCF record is used
to update a plurality of previously compiled subscriber-specific usage
patterns which define a particular subscriber's typical usage. Each CCF
record received by the event manager is used to update and maintain an
individual usage pattern for the particular subscriber to which the CCF
record pertains. In pattern event checks, the event manager will generate
an event when the present CCF 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. 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 six subtypes: 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. 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 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:
##EQU1##
where m.sub.n 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, u.sub.2, .
. . , u.sub.n are a series of values to be averaged. For example, assume a
series of values over day 21 to day 25 where u.sub.21 =16, u.sub.22 =9,
u.sub.23 =12, u.sub.24 =8, and u.sub.25 =15. To calculate a five-day
moving average on the 25th day, m.sub.25, n is equal to 25, d is equal to
5, and k takes the successive values 21, 22, 23, 24, and 25. Therefore:
##EQU2##
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
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 S321.
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
termination, (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.

     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 S329, 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 flows to step S337 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, "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 the
called number field 215 of the CCF Record 201 and its related country code
as arguments.

     First, at step S339, 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 S351, and the Check Suspect Country Code service is completed.

     If the present call was cellular originated as determined from the call
type field 211, the service, at step S341, 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 database by the
fraud detection system 107. If no country code on the list is matched the
service flows to step S351 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 database has been flagged as
"suspect." If a specified field 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 S345. Otherwise, if the specified database field
is not marked "TRUE," then the 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 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 S347, 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 S347 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 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 S367 which marks the
completion of the credit limit check.

     If a credit limit entry is found for this particular subscriber for the
present month, the service flows to step S357 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
usage total exceeds the predetermined usage limit set by the
telecommunications service provider 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 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.

     Lastly, the service flows to step S367, where the 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 the check on the basis of cumulative call duration in units of time,
as an alternative, the credit limit check 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 time units rather than money units to perform the credit limit
check 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 made using that same subscriber ID. 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
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 S369. After retrieving the first call
stored in the calls database at step S371, the check simultaneous calls
service, at step S373, 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 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.

     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 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 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, 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 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 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 field 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 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 S383 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 S391 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 S395,
performs a Geographic Dispersion Check, a flow chart for which is shown in FIG.
3F.  Referring to FIG. 3F, at step S401, 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 S423 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 S407 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 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: Apr. 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 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 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 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 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) plus the geographic dispersion adjustment
time; 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 minus the geographic dispersion adjustment time and the
termination time of the retrieved 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 to step S423 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 S419 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 S419 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 S421--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 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 S403 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 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
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 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 S433, 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 particular to this call in the events database
for this particular subscriber ID.

     Next, the service flows to step S439 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, "duration."

     Next, at step S441, the service sends the event context data structure
previously built at step S439 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 S443, where the call duration pattern
check is completed and the next check in 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 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.

     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 highest
number of calls placed within a given time period. The Check Call
Thresholds service S315 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 S445 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 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 S453, 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 S455, 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 S457, 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, 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 previously calculated
five-day and ten-day call velocity moving averages as arguments.

     First, at step S461, 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 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 S463, 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 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 S467, the service tests whether the 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 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 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 S471 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 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.

     Once all of the event manager checks have been performed, the event
manager procedure is complete for the particular CCF record under consideration
as indicated by step S323 in FIG. 3A. If a new event was not generated for
the present CCF record, the fraud detection system procedure is complete
for that CCF record. Accordingly, the fraud detection system 107 waits for
the next CCF record to be input into the switch interface 111.

     However, if one or more events were generated for the 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 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 particular subscriber ID for
which an alert-state was generated is suspected of being used
fraudulently. It should be noted that a single CCF record may generate
multiple events, each of which is individually analyzed by the alert
manager 115. Accordingly, the alert manager procedure, described below,
may be performed multiple times for a single CCF 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 ten different analysis
services. The ten different analysis services, represented by flowcharts
in FIGS. 4B-4K, 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 S480
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 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 S478, 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.

     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 S532 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 S536 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.

     Next, at step S540, the service sends the alert generated at step S536 to
the Evaluate Subscriber Condition service S522, described below.

     Lastly, the service flows to step S542 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 S482, 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 S488 where the
Analyze Credit Limit Event service...

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The text unfortunately terminates at this point (in this copy).  We will
attempt to obtain more complete text and graphics on this and other cellular
related patents.

Watch for additional information of this nature on Phoenix Rising Online.



(N)ext, (P)revious, or (R)ead this message?