CA2149135C - An apparatus and method for detecting potentially fraudulent telecommunication activity - Google Patents

Abstract

An apparatus for detecting potentially fraudulent telecommunication activity, comprising a digital computer (107); inter-face mans (111), operatively connected to the digital computer (107), for receiving a call information record far each call involv-ing a particular subscriber; comparison means; operating within the digital computer (107), for comparing a parameter of the particular subscriber's current usage with a subscriber-specific pattern of the particular subscriber's historical usage; and output means for outputting an indication of a potentially fraudulent call based upon a result of the comparison performed by the com-parison means.

Description

~. ~: 9 ~. '3 ~V~ 94/11959 P~i°~US93/10757 AN APPARATUS AND METHOD FOR DETECTING POTENTIALLY
FRAUDULENT TELECOMMUNICATION ACTIVITY
Background of the Tnvention 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 v system usage. T~leeommunication systems include both wireless systems (e. g., c~llul.ar 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.

25 2. Description of the Related Art Because immediate acvess to'information has become a necessity in virtually X11 fields of endeavor - including business, finance and science --~ telecommunication systems usage, particularly for wireless telecommunication systems;

is increasing a'~ ~ substantial rate. With the increase in overall usage, however, the incidence of fraudulent usage has experienced a corresponding increase. It is estimated, ~ ~pr example,' that fraudulent wireless tele'communi~ation sys~.em usage is rasp~nsible for lasses to the wireless telecommunication industry of $600 million each year.

Clearly, a system for detecting and preventing such fraudulent-activity would be highly desirable.

1~'raudulent telecommunication activity , which may occur both in wireless and common telephone systems, has VYO 94/ 11959 ~ PCT/L'S93/10757 ~14913~

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 a.s connected. Therefore, a ;
fraudlzlent user may place calls even without possession of a valid subscriber ID. Tn thas 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 i a .
placing cellular telephone calls using a plurality of cloned subscriber IDs: For example, a tumbling-clone cellular telephone may have-a sequence of 20 different dloned subscriber IDs programmed into it. With each successive call placed by the fraudulent user, the cellular teleph~ne would use the cloned subscriber ID next in i WCl 94/1195 ~ .~ 4 a~ _' ~ ,~ PCT/US93/10757 sequence to initiate the call. In this way, the fraudulent calls wotald equally be dispersed over ZO 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 subscribez.

Subscribes 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 telecammunica~ion services, 'either cellular er' .

calling card, amd proceeds o use the. telecommunication 'services with nn intent of ever paying for he services provided. A user pra.atic~ng subscriber fraud ~rauld continue to use the services without paying 'until system access was blocked by the service provider.

Although a number of prior fraud detection and pre~tent:ion systems have been suggested, a1.1 have proved inadequate or various reasons. one proposed solution ! ;involves setting a predetexxmin~d number~'asia sy~stem.~wide thxeshc~ld for the number of cellular calls that may b a placid by an individual - subscriber in ogre day: :when the predetermined number is exceeded, the method 'indicates hat fraud has occurred. The system-wide threshold method, however, has several drawbacks. For,example, this method appla.es the same threshold to every user. Typically; a ,, ,, , r_ Y : ..i~?..
n . 4?' v . !' . S .
. . vn . ~
,, tt........, ....,..,.,.,Y"....
..'.~~ ,S~i!.v.
t n...."..t..,Y,.:.,., . e.... ,.1,,...r.,"n .,.........,...
. ..u .,.
.,s,.. , .....
...,. ,.....
........,........
...,u".., vw, a .,.
v..

~J~ 94/14959 ~ PC:TAUS93/10757 ~~.49~3~

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 weeko 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 zD, as long as the threshold was not exceeded.
Moreover; the system°~ide threshold method is easily defeated by a fraudulent user who is aware ~f the predetermined threshold and takes care to limit the number Z~ of fraudulent calls placed to a number less than the threshold.
Another imethod, referred to ws "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 se~.ence is transmitted by the cellular telephone unit to ;:
the service provider station and recorded in the order received. 6nlhen the call records are processed, if any call sequence number ~ccurs 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, hoc~ever, has the disadvantage, inter alia, of requiring W~ 94111959 PC~'/US93/10757 ~. ~~ ~.. 3 that the cellular telephone unit be modified to include additianal equipment to generate and transmit the predetermined sequence of numbers. Consequently, the "call numbering" method is incompatible with the large majority of existing telecommunication sgyipment that has not been modified.

Moreover, the call numbering method is unreliable. It has been found that the Gall number sequence may become disordered through normal legitimate use, by events such as 20 early termination o~f the call or power failure, thereby resulting in false alerts.

Therefore, a system which reliably and accurately indicates the possibility of fraudulent ~telecomanunication activity, but which is flexible ~nougl~ to permit legitimate 1.5 use by a wide variety of subscriber, and which is compatible with all types of existing telecommunication e~i~ment is needed.

summary ~f the Invention It is an object of the present invention to provide a 20 zne~thod and apparatus for detecting potentially fraudulent i , telecommunication activi~.y by comparing :'cur.rent ~us'age for a particulai subscriber ID'ox calling card number with the particular subscribers historical pattern of usage. Tf current usage for that II7 or calling card number indicates 25 a deviation in the historical pattern of usage by the subscriber, a potential fraud is indicated.

_ :. .. . . . .~ , ,: .,:. . , ~__ , ::: . - . -.::: , ~ ~ .: ~:
: : :: , ~ .~ t ;. , , ,- , , ;. ..,, _. ,, a r .~
s ".
.5 6 ,. .v .
.;.. .., :
..x"... ., . '.:' ,. ;.'n. , .::..:'.. .'':,.:., .,. , ,: ' .,:!. ..,, ,. . , , , .. ..... . . , .. " .. _ ~~~9~.3~ ;
I~V~O 94/11959 PCTlgJS93/10757 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 y 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. Tf there is abnormal usage relative to the subscriber's historical pattern of usage, a potential fraud is indicated.
Tn 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 f 15 are then comparod 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.
Tn 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 i ~ , i i ,, average calculated over a longer number of days; and (2) the percentage increase between a waving 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 inventian to provide a method and apparatus for detecting potentially WaD 94l l g 9S9 ~ ~ ~ ~ ~ ~ ~ P~CI'lLJS93/~H 0757 ~7m 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 emboda.ment~ the fraud detection apparatus looks 25 at each call made by a particular subscriber to determine whether any two calls using tYae game 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 casing the same subscriber ID
or ca~.ling card number from different geographic locations within a suffio.iently short time interval, such that travel . ; , ' between the two geographic locations within the given time interval is improbable.
It is ~ furth~ar 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 W~ 94/11959 ~ ~ ~ ~ ~ , PGT.(US93/10757 with a predetermined call destination. If the predetermined subscriber-specific condition is satisfied, fraud is indicated.
In ane 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 sa:gnal a potentially fraudulent call based upon a result of the comparison performed by the comparison means.
Thess and other features of the present invention will become evident from the detailed descr~.ption set forth ~ ~' hereafter with reference to the accompanying drawings.
Brief Desori,~tion of Drawings ~5 ~, mare complete understanding of the invention can be had by referring to the detailed description of the invention and the drawings in which:

W~ 94/ ~ 1959 214 ~ 13 _g_ FIG, 1A is a diagram illustrating a typical cellular telecommunications network.
FIG. 1B is a block diagram of a telecommunications fraud detection system acc~rding 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 fl~wcharts of the Event Manager procedure.' FIGS. 4A-4L are flowcharts of the Ale~'t Manager procedure:
FIGS. 5A-5C are flowcharts of the User Interface procedure.
~,5 FIG. 6 is a screen displ.ax of the I,ogira 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 o~ the present invention.
FIG. 8 is a screen display of the Invastagate S~xbscriber Window of the User Interface in one embodiment of the present invention. , , ~ ; , FIG. 9 is a graph showing call ~relocity fluctuations f~r a typical cloning fraud user.
~5 FIG. 10 is;a screen display of the Monitor New SID(s) Window of the User' Interface- in ~ne embodiment of the present invention.

..~
PC.'T/U~931~ 0757 i~VV~ 94/ 11959 ~~~~ ~~
_1~_ 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 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. ~.A, each predetermined fixed geographic regican is sexved by a separate Mobile Switching Center (MSC). Additionally, each MSC region may camprise one or more cells, wherein each cell i~ served by its own base station connected to the MSC for that region. In FIG. 1A, Region I is served by a f first MSC 101 while Region II is served by a sec4nd MSC 102. Region I comprises four cells each having its own base station 104 connected to the ffirst MSC 101. Region Il comprises th~~e 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 v particular~MSC serving that geographic region by means of wireless radiofrec~aency 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 examp3.e, a cellular call may be originated by a subscriber in Cell A and the call wv~, ~~ ~~~~.3 W~ 94114959 ~C;f/US93/10757 _11-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 tha 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, ox' between a cellular telephone and a physical line telephone, even if they are in different geographic 3.5 regions .
The function of a MSC is to receive and route both cellular originated calls and cellular terminated calls.
A cellulax 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 cel~.ular 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 M~bile Identification Number (MIN), and (2) a Mobile Serial Number (MSN). The MIN is a ten-digit ~1 Wf7 94/11959 P~i'/U~93/10757 ~1~~137 ;
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 ani~iation of each call;
the cellular telephone transmits to ~.he MSC its unique ~.0 combination of MIN and MSN: For each call, whether cellular originated or cellular terminated, ;,each MSC
handling the call creates a separate Cal1 Detail Record (CDR) which contains several items of information describing the call and the subscriber. For example, the , ~.5 CDR contains the following call information items: MzN, MSN, number called, call duration, call origination date and time, country called, information identifying thd MSC;
etc. The format of the CDR, however, is not consistent among the several' different prov~.ders of cellulir telephone 20 servics. At present, for: example, at least five different CDR formats exist.
As mentioned above, each individual subscriber has a i ~ . ; ; ; I ''' single home MSC corresponding to the npa and nix c~mponents of the subscriber's MIN. Unless a cellular subscriber has 25 previously r~otifi~d the home MSC of hi or her whereabouts, the subscriber may only receive a cellular terminated call when that subscriber is within his or her. home MSC region.
I~ most cases; a: subscriber may initiate a cellular ,~~...:..., ,:.., .,.._ . . ; ; . : - - .: . . , .. . : ;., ., , .,; ,v , : .
: : . :. . ., .
i ~.,'.... ..:~,... .,;..,. .. .";. :.~..~.: : ~ , , ~.. .... . '::
~:,w...~...~~ :~ .~t:~.'. :..;,..~.. v;.~;-. .. -..: ~,~~~; "", '.
,. ~ ..,':, y. ~~;. ~ . ;...:.. ,, , . ... ,. .:.. ,.,:.~,~:..~r:...; ..,.. ., 9~V~ 34/11959 s PCT/~JS93/10757 ~1~9~.3 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'vall CDRs pertaining to a particular MSC, creates a magnetic tape -_ a roamer tape -_ containing multiple CDRs, and sends the gape to the appropriate home carrier.
FIG. 1B ~.s a block diagram of a telecommunications fraud detention 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 x.07 of the present invention, comprising the switch interface 111, the event manager 113, the alert manager x.15, and the user interface x.17, is implemented, in one embcadiment, a5 software running . ., , , on a digital computer, for example, a Sun Microsystems o wQrkstatian. 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 :. " ...,.. :.. ; .:. . ;::- .~; ". ,;_. -,,:. ...:_>. . . ; ,;;,.,. ,;;: , .:
,::. , -, .. ...
. . : , , : . .. ,, ,, , . .. . , :. , . . ,. . .. ..;. , ; .
,.... ,,. .. . .. .., . .. , ,, .. . , .. . .. ........ ; ... : .,. ... ....
:. . , . . . , . . ...

i W~ 91/11959 "' PCI"/US93/10757 ~~4~13~
-14 ~-operator, a magnetic tape drive (nat 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 cahse 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 TD for which the alert-state was generated is suspected of being used fraudulently. Each of WO 941 X959 ~ ~ t~ 9 ~ ~ :~ P~L'Tl~JS93110757 the alert-states generated is stored in a database -- the ''alert-states database°' -- specific to each subscriber.
1'he 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, arid the '::<
history of alerts and events which eventually triggered the alert-state in question. ~nce 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 TD.
Referring to FIG. 1~3, a more detailed description of the fraud detection system 107 is provided as follows. A
cellular telephone 103 communicates with a MSG 101 to place a call either to a physical line telephone 105 or to another cellular 'telephone: Additionally, the cellular telephone 10~ 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.

PCT/L'S93/10757 i~b'~ 94/ 11959 21 ~ ~ ~ ~ ~

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 faraud 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 CABER
format. The combination of the home MSC 101 input and the roamer tape 109 input represents X11 of the call activity ' 15 for a MSC's home subscribers, regardless of the geographic region in which the calls were originated or terminated.
The call inf~rmation ihput; whether from the roamer gape 109 or from the home MSC 101, is feel 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 'I interface 112 is capable of accepting CDR input in any of the existing - formats, and a.s easily adaptable to new CDR
formats crea~.ed 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 21~9~
WO 94/11959 PCTl~lS93110757 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 telecpmmunications 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 2~3 ~ 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 'oloo if the call was answered.

Pt,T/US93/10757 iWCD 94/ 11959 .
_18_ 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 ca21 from his or her home MSC.
The sid field 221 holds a switch identifier number Y' a.dentifying the s~rv,ing MSC that generated the present CDR
record for this call. Because a subscrit~er 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, anultiple CDR rec~rds may be generated for a single call: -- ~ne gor each MSC that handled the call: The sid field 221. identifies the MSC
that generated th~,s particular CDR, even if it was not the MSC on which the call origaraated:
The first serving MSC field 223, and the first serving ~, cell field 225 identify the specific MSC and cell, respec~avely, on which the call originated., As discussed above, both he 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 ~. r .- ,.

.. ,\
W~ 94/11959 ~ ~ ~ ,9 ~ 3 1 PCI'/tJ593/10757 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 prig date field 229 hald 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 FTG. 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 a~ ~~ae evens manager ~s to perform a number c~f 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 5303 through S309 are referred to as "call event" checks.
In the call event checks the CCF record is compared to a set of predetex°mined conda:tions to determine whether or not an event should be generated for this CCF record. Call events are further broken down into the following event typess number events, country events, credit events, and Wt~'94/11959 " ~y .,~ . , PC'~'/iJS93/10757 ~1~913~ -20-overlap events. Additionally, overlap events have two event subtypes: geographic dispersion and simultaneous calls.

The services indicated by steps 5311 through 5321 are referred to as 'pa~.tern event" checks. In the pattern event checks the CCF record is used to update a plurality of previouslycompiled subscriber-specifis usage patterns which define a particular subscribers 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 CGF 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 1'S pattern to indicate a trend of abnormal usage suggestive df fraudulent telecommunications activity. Pattern'event~ are further broken down into the following event types: averag2 events and threshold events. Additionally, average events have the following four subtypes: velocity, international velocity, duration, and international duration. Thresho3d events have the following six subtypes: daily irelocity, daily international velocity, five-day ,average velocity, ~ ;.
~ ' r fire--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 he CCF component fields r .,: x . . ,. ".........
o . . . ,..
z , . . r ~
. , . , . .
. . ,.. ,t , , .. . , ..........,..,.
"-..,- ~ ...
. ..... ;,.-.,.~.,.~-r-,.Rr..., a n ,. .. ,.
,~-.~.rn x~~..
.. ., ..:;..

5....,. . ...
. ,. , . .
,.,r a.';:
. .. . t .
. , . , . .
.. , , , .., ... . : , o . , , ..

~1 ~Jl3~a 13'~ 94/11959 PaCT/US93/10757 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 P~ISC, 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 d te," while the date on which the CCF record is processed by the fraud detection system will 1~ 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 aver the past predetermined number of days so that 2p a delayed CCF record can be analyzed in connection with other calls planed on the same day. This database is referred to as .the ,calls, database. ", , , At step S3~2 the event manager uses the present CCF
record to update the subscriber--specific usage patterns.
25 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 .: . ~ ..-->, P~I'/US93/10757 W~ 94/11959 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:
m~ _ ~ uk k_~y,~, 9 _ 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, uz, ., u~ are a series df values to be averaged. For example, assume a series of values over day 21 to day 25 where uz~=26, uzzg ~ '~z3-22, uz4=8; and uz5=15: .

To, calculate a five-day moving average on the 25th day, mz5, n is equal to 25, d is equal to 5, and k takes the sudcessive values 21, 22, 23, 24, and 25.

Theref ore .

m25 u21 -1- L1~2 + 123 -~- t12~ 'f' ~z5 - 16 + 9 + 12 + 8 + 15 12.

Five and tern-day' moving averages are calculated for each of the above-listed four patterns in similar fashion. Fox example, the five-day. moving average ;call velocity is , ' ~

, calculated by summing the number of Galls 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 den days and 'dividing bytenP rather than five. In order to dalouiate the ten-day moving average, the fraud detection system ,. y ;..
,_- _ ~-e,. -v ~.ta.
a P7~m.
. 'u'l~ r "a , r.
...a::'.K.. ".....,.t...,...,,....m , .,fm:.l u......
' i.. .."<..., .o u...,. , .us . .,...
.., r , t':'.:

w; ~14~~.3~j CVO 94/11959 ~ PCT/US93/10757 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 a~rerages are 20 utilized, a different number of moving averages, for example one, three or more, may be used as deemed effective. Moreo~rer, 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 went checks and pattern event checks, represented by steps S3~3 through 5321. Although one embodiment of the pxesent invention arranges these checks in a specific order as illustrated in FIG. 3A, the checks 2p aye substantially order independent and may proceed in any convenient order.
~ In tae ,embodiment of the present, invention depicted in FIG. 3A, the event manager performs the checks in the following carrier: (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) chick international call thresholds, (9) W~ 94/11959 .. ;
-24°
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-3h.
~ Referring to FIG. 3B, the Check Suspect Termination service 5303 is responsible fax 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 falls;
if the present call was not cellular originated the service flows to step 533?, which masks the completion of the Check Suspect Termixaat~.on service.
If the present call was cellular originated as determined from the call type field 211, the servile, a 20, step S327, tests whether the number called, held in the called number field 23.5; matches a number on a predetermined list of numbers set by the telecommunication ,, ; ~ , , ' ~ f ;
~servfee provider and maintained in a database by the fraud detection system 1074 If no number' on the list is matched the service flows to step S~37 anc3 this check is completed.
I~ 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 specifa.ed field in the r r t.
~f~. . ,\..,:
! ..
'f~.~' . ,.
..
'r t =r s ,:,.' .!.;.,. .. .': . .. ,~.:. .. , .;':'.. . ,.''...,.,..." ., ,.. :. ,....
.: , . ,.'.v.= , ., ....;;. , , ,,..~:. ..:. .:.; .,... ~'~ , .....;' :: .~ ~ _ VV~"~ 94/11959 ~P ~ ~ ~ ~ ~ ~ ~'CT/IJS93/1075i _25_ database of numbers is marked "TRUE," then the matched number will be determined to be suspect and the service will flow to step 5331. Otherwise, if the specified database field is not marked '°TRUE," then the service flows 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, "number event," along with specific information particular to this call in the events database for this particular subscriber ID.
Next, at step 5333, the "event context" data structure is built with information specific to this event. The event context data structure contains ~.nformation including (1) the event type ("number event"}; (2) the event subtype ( none f or th~.s event type ) ; ( 3 ) the subscriber ID number (corresponding to the th~e~ MIN fields 203, 205, 207 and the MSN f ~.eld' Z0~ ) ~ ( 4 } the call date ( from thd orig date field 229); and (5} the current alert-state (either normal, yellow, or r.ed dependa.ng on the na~.ure; ,and quantity of alerts outstanding for this particular subscriber as determined by the alert manger, discussed below}o Next, at step 5335, 'the service sends the event context data structure previously built at step S333to the alert manager 115 to s~.gnal the alert manager that a ne~a WO'~44111959 ~ ~ ~ ~. ~ ~ ~ PCT/US93/10757 v .
_26_ 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 5337, 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 5305 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 2'0l and its related country code as arguments.
First, a~ step 5339, 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 riot cellular originated the service flaws to step 5351, and the Check Suspect Country Gode service is completed.
if the present call was cellular originated as determined from the call type field 211, the service, at step 5341, tests whether tl~e country code called;matches a country code on a predeteranined list of numbers set by the telecommuaaication 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 5351 and this check is completed.

~ '4~~ 94/ ~ 1959 ~ ~ ~ ~ ~ ~ ~ PCT/US93/ 9 0757 -27_ If a matching country code is found the service, at step 5343, 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 5345. Otherwise, if the specified database field is not marked "TRUE,'° then the service flows ~o step 5352 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 countxy suspected of being calledv by other fraudulent users. Accordingly, the service generates a "suspect country code event" by recording tie event type, "country event,'° along with specific information particular 25 to this call in the events database for this particular subscriber ID.
Next, at step 5347, the event context data structure is lbuilt with information specific to this event, as discussed above. The event context data structure for this service has the event type, °'aountry event," and no event subtype.
Next, ,at step S349P 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 i i 25 event has been generated and to provide a reference for ..
locating the newly generated event in the events database.

W~ 94/11959 PC.T/US93/~0757 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 FTG. 3D, the Check Credit Limit service 5307 is responsible for determining whether a particular subscriber has exceeded his or her specified usage limit by maintaining a running cumulative total usage duration far each subscriber and comparing the running total to a predetermined value set by the telecommunication service 1t? provider. 'his 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 far the present month in the credit limit database maintained by the fraud detection system. If ~ credit limit entry is not found an inconsistency ~.n the system has been encountered; ari error is logged to an error handling server and the service flows tc~ step 5367 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 flaws to step S357 where the running monthly usage total for this I. ~ ~ ' ~ I , ~ ,. ~.~ ~ .. , . , C
particular subscriber is updated by adding the usage for the gresent call, represented by the value held in the call seconds field 233, to the previous monthly usage total far this particular subscriber.
Next, at ;step 5359, the service tests whether the newly calculated monthly usage total exceeds the ...:: . ;;.:: .: :~; . ~ :,. .. ..:.- ... .-: .. :~ . .: :: ; . , .:: .. . ; .
. :: , ;. ::.,. . ,.' ., ., ..:.::, ..:. , , . .. .: ~... ..::: .....::... . : ~ ...: . :,. , t. -..
..... ... . . ....

,i i::~';~'.~;''.: ~ ,:'',. ...:.,.. .~ ,;, .. : :'. : : ~ :'v:; ". '., ..':
::; . . ::: ,.v' . ;., ~. ' . ; . , .::: ; . , . . : . . .. .,,'. ' ~O 94/11959 ~ ~ ~ ~ ~ PCf/tJS93/10757 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.
Tf the predetermined usage limit has been exceeded, the service flows to step 6361 whets 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 5363, the event context datarstructure 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 5365, the service sends the event context data structure previously built at step 5365 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 i ~ ' ! ' ~ ~ ' event manager procedure is initiated.
Although one embodiment of the above-described credit z5 limit check per~fox~ms the check ~n 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 '6WQ 94/11959 ~ ~ ~:~ ~.~ ~ 1'CT/U593/1U757 y i~
_3p_ service provider's rate times the cumulative call duration.
Tt 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 t~ FIGS. 3E-3F, the Check Overlap Calls service 5309 is responsible for determining whether a call made by a particular subscriber overlaps any other calls made using that same subscriber LD. 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 i would be improbable that a single subscriber could place the first call and then travel to the location of the 1.5 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. ~'he Check Overlap Calls servi.Ce is comprised of two separate'checkst Check Simultaneous Calls and Check Geographic Dispersion.
' Referring to FIG. 3E, the Check Overlap Calls service first performs the Simultaneous Calls check at step 53~~.
After retrieving the first call stored in the calls database at. step 5371, the check simultaneous calls service, at step S373, tests whether the retrieved call was placed on the same date as the call presently under ~. 5,.:;..:..~..,,.:-.:, ~:~:.~:.',. ,;~,.;. ........ . .:" r. ,,.,;... ., :..,......,. ..,",y :"i;~ , ,~.,~.. ....~-._. ...:. ,..,- ..,.' :,:.~ .;;...., :..,.: :.,:. ~'.
yr, T. ;.. . , ;., . . ,, ': . , ...: ' , . . . ,.. . . ".' ~... . . . . ...
.. . .. ~ . . ~ ,. .. .., .. . .. : 1.. . .. i ~ . ~ . . .~ ... . . .: . .. .
~. . ., ; ; .~ ...: .;. : ... ,. , ' . .'.
r.' n ; .._:~;. ;:..~..-....... . ..... ::.:.....,. , , : -:.::-.: ~~ :;.~: , ., ..' ,-:~. ~.'..'..: ~, ~::i ....,.,,... . ..,:,, ::...:.. . : ':~,..,.
,.;,:;.. ;,.,:. .
.:.:.. . .. .':,,,.,' ,. ,.,. . . :.~,...., .;:'--'..... ' ~\
~ WO 94/i 1959 ~ ~ 4 ~ ~ ~ ,~ PC.'T/US93110757 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 ..
j present call and the service flows to step S389 to check 1 5 the next call in the calls database, if any.
I If the retrieved call was placed on the same date as the present call, the service, at step 5375, tests whether the retrieved call has the same subscriber ID as the present call, as determined by the three 1~IN 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 5389 to check the next call in the calls database, if any.
If the subscriber IDs match, the service, at steps S37? and 5379, tests whether the retrieved call used either the three'-way call r~r 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 agnored when checking for overlap calls because calf that utilize thesefeatures, while appearing to overlap, may be legitimate.
Accordingly, when these call,features are presents the service flows to step 5389 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 ':
2 ~. 4 9' 13 ~ PCT/(JS93/10757 ' 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 recard) is chronologically between the arigination time of the retrieved call (as determined from value held by the orig time field 227 of the retrieved call CCF recard) 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) t 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 5389 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 5383 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.

~~.49~.3p ~~'0 '941 ~ ~ 959 PaCT/US93/~i 0757 _~3_ Next, at step 5385, 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 5387, 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 performssteps S383 through 5387 -- 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 5389, the service tests whether any calls remain in the calls database to be compared for overlap with the present call. If add~.tional calls remain in the calls database which have not yet been checked for overlap with the present call, the service flaws to step 5391 where the next call is retrieved from the calls t database and the serv~.ce returns to-step 5373 toy check for ,, ~ , call overlap: It should be noted that steps S3'73 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 S395, performs a Geographic Dispersion Check, a flow chart for which i:s- shown in Fig. 3F. Referring to ~~.49~35 ~ w:

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 ariginated 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.
2f, however, the retrieved call was placed on the same date as the present call, the service, at step 5405, 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 raot match, 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 the subscriber IDs match, the service, at steps S407 and 5409, tests whether the retrieved call used either ,i~ ,, i the three.~way ,call o,r the call-waiting ;features, respectively, as determined from the call feature field 231 of the retrieved gall CCF record. Calls utilizing these call features are presently ignored when checking for overlap calls because calls that utilize these features, while appe~ri:ng to have a geographical dispersion problem, may be legitimate. Accordingly, when these call, features ~:I~~~~.3 WO 94/i 1959 PCT/~JS93/10757 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 5411, 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 dates April 2, 1979), a copy of wihich 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 geor~raphic location of each MSC is known, the sex-vice can approximate the location of each call by using the MSC identifier to index a database of MSC
geographic coordinate.
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 5415, the service tests whether any portion of the present call chronologically overlaps the retrieved call when adjusted for geographic dispersion:.
.-,,. .~,-.. : -. ..;, :::: .. .. ; , .;..:. ..;, :::: ~: ;:. .. ,.,: ~:; . ;
<
,. ... . . . , . . .... . .. ,. .. . . , . ,.. ... .. , ..
~~ .,,r..~ ,.. . .:,.... ...,.. ,,..:. . ,..:......,.,... . . ......, s,:
.Z.. , . . . ...: .. , ;,.... ... ,_ ,. ,. . " . . . . ,......., . ... .. .
... .. . . .:.. . . . . ..... ,. ,, , .. .. .:. .
. . ...: . , , . .... . .. :. . . , ...,... ", . . .. . _ , .. ... ... ... . .
. -. . ,: , ..
dV~ X4/11959 6 °~ PCTlU~93/10757 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 0~ 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 arig 'time field 227 of the retrieved call CCF record) plus the geographic dispersion adjustment time; or (2) the terminatian 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 Brig time field 22'7 of the present call ~CF record) ~a 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 tame. Tf 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 ~~23 to check ahe 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 i~Vi] 94111959 ~ ~ ~ PCT/~)S93190757 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 zD.
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," end event subtype, d'geographic dispersion:"
Next, at step S42~; the service sends the event ' context data structure previously built at step 519 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 he wants database.
~;5 xt should be noted that the service performs steps S417 through 5421 - that is, ariot~aer event is generated -- for each call retrieved from the calls database which overlaps the present call when adjusted for geographic dispers~.on>
Therefore, the single CCF record under consideration may generate multiplo oaoverlap cal~.'° events.
Next, at step 523, the service tests whether any calls rema~.n in the calls database ; tq be compared- for i '! ' , geographic dispersion overlap with the present call:.- If additional calls romaia~ in the calls database' which have not yet been checked for geographic dispersion overlap with ~~e present ca~~., the service flows'to step.5425 where the next call is reprieved from the cads database and the service returns to step S403 to check for geographic .,, , . ... , .1. ..:. :.,;..~ ,y,",......~. :,-,. ~.. -..y i a dispersion call overlap. It should be noted that steps 5403 through S425 ale performed as many times as the number of calls in tree calls database.
If no more calls remain to be compared, the service flows to step 5427 where the Overlap Calls Check is completed and the next check in the event manager . procedure is initiated.
Referring to FIG. 3G, the Check Cal1 duration Pattern service 5311 is responsible for determining if a particular subscriber's calf 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 utay 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 w~.th 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 i.s greater than a predetermined minimum amount.
This step ensuxes that fluctuations in usage for low volume users do not c~~nerate an abnormal number of events. For example; if a subscriber whose five-day moving average call duration was 130 sec~nds on the day before the call date based on a single call within the past five days, increased 1 ~ 9 .~ 3 ~ PCT/US93/1U75?
W~ 94/1Y959 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 repx-esented by one long call. If the f~.ve-day moving average call duration calculated for the call date is less than the predetermined amount, therefore, a call duration pattery 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 544 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 fc~r the same date. If i't is not greater, the service flaws to step 5443 which marks the completion og the check.
~f the five-day moving average call duration for the call date is greater khan the' ten°day moving average call duration 'for the same date, he service, at step 5433, calculates the percentage increase between the five-day moving average call duration ,for the calf; datg ~n~l ~ the ' ,. ,, . i j five-day moving average call duration for the day before the call date .
Next, 'vat step 5435, the service osts whether the percentage increase caldulated at step S433 is greater than a predetermined limit. Ig the predetermined limit is not e~ceeeled is indicates that the average call duration for W~ 94/11959 ~ ~ ~ ~ ~ 3 ~ P~C;T/US93/10757 the particular subscriber ID under consideration is not j 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,'i and' the event ' subtype, "duration," along with specific information particular to this call iw the events database for this particular subscriber 2D.
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."
' 20 Next, at step S441, the service sends the event context data structure previously built at step S439 to the alert manager 13.5 to signal the alert manager that a new event has been generated and to provfde 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.
:; : .. . ,: . .~.; . ....: : . - , ., ; :- > ,<.: . ; . ., . ;
my ..:~:~.. '. :..-.: . :.'.'-~~':'..:~. .~..:-t... ;.~..~, ~..,,,.,: ;..,....
....:.-, ~ ,:' w,~..~ ,._~ ,~.. ,:. , .._ :, .. ..

,,, ~n, '\
WO~ 94f 11959 z ~ ~ I ~ ~ PCTf US93f 10757 _41_ 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 duratian. ~' Due to the near identity of this service with the Check Call Duration Pattern service, no further discussian is necessary.

Referring to FIG. 3I, the Check Call Thresholds .., service S315 is responsible far 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 orie-clay high water mark check, ~ a f ive-~

day moving average high water mark checks and a en-day moving average high water mark check: The fraud detection system 107 keegs track of the highest number of calls ever made by a particular subscriber for each the three different time periods. Hlith each additional CCF record processed, the Check Call Thresholds service 5315 checaks to ~ ~
, ' i see if the addition of the present calf to 'the present total number of calis placed far each ~f the three separate time periods exceeds one of the high water marks for a particular subscr~.ber. Because the three checks axe nearly identical, with only a difference in the time period to be f .q.
m w:msnx~
..
r f w, o.:g S
', .
.
i~
a r r.
.:;
r r.

.L;'r !, , .,..1 l n a r!
'.

.
.
'~
1v F
:..:, IA
.

:
:
v ...:
~
;'.:, ,,.
, ~;
.~..
..::
.
..
.
, S
v ,.N.
.,..,1., f.
a ., z .
., .
.
>
, , .<
..~1..., ..
.
.....e,.
...
.,.
t....,..
.
.
.:..:,._ ..
~.....""n .':..'..
.....
,...
, .
,...
..
.....:5 .
,.:.~.....
...
.., .
, ,.
......
..
t1...;"
.:..
.
.
.,.
....
.
, ..
, ..
.
....
......

~.~?

dV0 /11959 ~ ~ ~.~ ~ ~ PGl'lUS93/10757 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 5447 the service tests whether the present daily call count -- that is, the total _ number of calls made for the call date -- exceeds a predetermined m~.nimum 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 fdr 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 S45~ and the next'call threshold check is initiated.

7Cf, however, the present call count exceeds the predetermined minimum amount, the service, at step 544, tests whet~rer the present daily call count exceeds the one-day high water mark. If the oreday high water mark is riot exceeded, the service glows to stop 5459 and the next call threshold check is initiated. ~
r If, however, the one~day high water mark is exceeded by the present daily call fount, the service, at step 5451, resets the one-day high water mark to the present daily call count, ~nd'then, at step 5453, generates a daily call ~hxeshold event by recording the event type, 'threshold event, and the event subtype '1 day velocity, ' along with ' W4J 94/~ 1959 ~ ~ 4 9 ~ 3 ~: . PCT/US93/1 X757 specific information particular to this call in the events j; 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 5457, the service sends the event context data structure previously built: at step 5455 to the alert manager 115 to signal the al.ert managex that a new event has been generated and to provide a reference for locating the newly generated event ~n the events database.
Next, at step 5459; the service initiates the five-day moving average threshold check. As illustrated in FIG.'3I, 1.5 both the five-day and ten-day checks a.re nearly identical' to the daily check, except than the high waver marks for five-day and ten-day peripds, respective~.y; are used, and the event ubtypes are "5 day average velocity" and 'e~.0 day average ve~.ocity," respectively: Consequently, r~o further discussion of these checks is believed to. be necessary.
As illustrated in FIG. 3J~ ~h~ service for Check International Call Thresholds is nearly,,identi~al 'cp, the i ;:
service for Check Call ~'hresh~lds,'except the event ~~hager maintains a separate subscriber-specific pattern far i ~5 interr~ati~nal'call thresholds against which the CCF record is checked, and the events subtypes are '~1 day in~ernaticnal velocity," "5 day average international velocity," or "10 day average international velocity," as T :;,..
.' .,'.~" :.,... , ,:, ~~~ .,,:: ,x,.,, ...,' ';.s ',, ...,_ ~ ... \ : ..~ -.
,,r. ,.. -. ~.
rn !.
S
. re ...~~., ~.. .. .,.... . , ,...."r.., . .x..y, : ... , ......,.. .",, ..
,:.. ... . :.... , .. . ..,. . ., . , ...... ,.,.. ..,.. ,.... ... ......:;r , ....,.~.. ........ ." , , ... ...,.~.~ . . _.....,~ ~. ..:;: . ;;; , ~.

~i _. , ~ VV~ 94/11959 2 ~ ~ 9 ~ ~ ~ PCT/U593/10757 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 5319 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 'W 15 previously calculated five-day and ten-day call velocity moving averages as arguments.
First, at step S4E>1., 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 ensure 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 av~rage,,;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 "_ ;.,. , . ,; , ", .., , ; . : . : .
i,...;,_ :...'.' ..'.'.' ,..; .
. ".~...,.. :,..':. ::..~. - ..;,~ ::~~:. -.. ~~.:.~. ..~ , ~:: :~;"~:~.:.
,... ~'.~". ;-.'~~~.~~ ..,.:.: ;,-~.., ..;.~~ , , .:;, ~. ,,. ,, ..
a ~, ., ....." ... , .,., : ; ,....::. . , .. :. . ;.':. .. . ..... .... . . .
....:.. ~ . ,~ .. .. .. ~. . . . .,..~.. . .....
-t - : .. ..,,. . ~. ..~.~.. , _..:, :.: ~ ....~. , :,..:' :: . ,, ~~.:
:"......... . -;r~ , ',.~:: :.. ...,,.. ,.. _ .~~ .....~,.. : ....,.,.,~. , .;,,....;. . .. ;. ,..:: . ..,~.... :. , . ..: ~ ~ .. . , .
.,:~:,...,~a. ,..:~~:,.'. ,..~..~~:.~.... :,..., .. -...-" ,.:...~. . ...,.:;
, ~..:. .. ...,..,. -":....:... ~:....,~.;;~,.~..~.-,.~....,...~..~'. ..:.
,,,.:. , . :...~.:.w....~

WO 94/11959 ~ ~ ~ ~ ~ .~ ~ . , PCf/US93/10757 pattern check would likely generate false alerts and should not be performed. Accordingly, the service flows to step 5475 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 auerage 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 5465, calculates the percentage increase between the five-day moving average call velocity for the call date and the five-day moving average call velocity' fc~r he day before tl~e call date , Next, at step S467, the service tests whether the percentage increase 'calcula.ted at step 8465 is greater than a predetermined limit. 'If the,predetermined limit is nit exceeded it indicates that the average call velocity for the particular subscriber ID under consideration ;,i~~not , ~ , increasing at an abnormal rate and hexc is no reason to suspect fraud on the basis of the call velocity trend:

B5 Accordingly, 'the service flflws to step 5475 which marks the comple~ionof the checko 2f, however, the percentage increase exceeds the predetermined limit, it indicates that call velocity for . ., , . , . . . .. , . n., . t. -- . . Vn..::v . . .. n ... .. ,v r ,. . .....r ..u .. . . . .. . .."_ ,. .....,. . . ... ....<. .
.
,... , . . a 1... '.:. ... .. . . , . . .

. : :: ; . ,. ; ..; , . , , : . , .. , , : ::::: . . .. . . .. , .;.; :. " . .
- , . : ., . , . . . , . .. . . ,: . : ...
... , . ,.. .; . . ,..., .... ...::. .;,.; ...-.,: ., , .,:,;,., ... .. ..
,i r ,.
~6'O 94/~ 1959 PC'~'/US93/1075'7 v 2149~.~~ _4~_ i 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 i 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 5471 where the event context data structure is built with information specific 2~ 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 125 to signal the alert manager that a new event has beea~ generated and to pravide a reference for locating the newly generated event i.n 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. 3Z, 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 a ent subtype is °'internation~l velocity." Due to the near identity of this WD 94/x D959 ~ 14 ~ 13 J PCT/L'S93/10757 -47~
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 5323 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 10? 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 CGF 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 1.5 function of the alert manager 115 is to receive each event generated by the event manager 113 aa~d '°analyze" that event, to determine if an °'alert" should be generated.
Depending upon a 'predetermined set c~f rules, either a single alert or a specific combination of alerts may generate an "alert-state" which is then passed to the user interface 1.17 to signal the system operator 119 that the particular, subscriber ID for-,which; an al,ertastate~ was . ,. . . . ~
generated is suspected of being used fraudulently. It should be noted that a~ jingle 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 P~:T/US93/10757 9~(9 94/11959 manager procedure wall be performed once for each event generated by the event manager 113.
Referring to FIG. 4A, the alert manager procedure initiates at step 5476 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-~kK, 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 5478,, if the event type is a suspect termination event, the alert manager procedure flows to step 5480 where the Analyze Suspect Termination Event service analyzes the incoming event.
Referring to FTG. 4B, the Analyze Suspect Termination Event service 5480 generates a new suspect termination alert for every incoming suspect termination event. Upon receiving the'e~rent context data structure as an argument, the service generates a "suspect termination" alert at step S5~4 by adding a new entry to the alerts database for., this i , ' ' I " i , : ' , ; , particular subscriber LD. An entry into the alerts database includes the following information: (1) subscriber ~5 ID (particu~:ar 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 h .:.~.~. . . ; y:~.y,. :,..~; ' ,_;..::.:' , .. '...~,."' ..~::~!, ,..'.:.' ~,,::.. . ; .....,.., ~,. .'.:, ' . , ..... , .,~~ ,..;.. .,, '' ;':..' ~~'.,....' w.,~... ;.~ :,-.
1 ~.. , , . . . ~. a , . , . . ,.. . ~,. - . . . . ~ . . , , W ~ : , :~...~ ~ .~ ~....,:~.. . ': '.' -.... , . , .. ." . ' ... ~:, . . :. , '.

. . \~
W~ 94/ Y 1959 ~ ~ ~ ~ ~ ~ ~7 PCT/US93I10757 (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 ~.riggering the alert under investigation.
Next, at step S528, the service sends the alert generated at step 5524 to the Evaluate Subscriber Condition service S522, descr~.bed below.
Lastly the se~vace flows to step 5580 which marks the complet~.on 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.
' Referring to Fl!G. 4A, if the event type did not match at step S478, the alert manager proeedure,flows ~o;step ~ , , , S482. At this step, if the event type is a suspect country .: code event, the procedure flows to step 5484 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 ".. .:. : , , .. : .. -.: .. ..::.. . ~..:-. ...:: . :. . .. . .-:~ ::.:. :, , . ~:.w . . ,. .. . ; , ;:
. .. , . : . . . . , . . . . : . .. .. ,. .. . . .. . , .. . .,. ; ::. . : .
:. .. . . . . . . .._ : .
. .. . .. , ; :: .. . . ., : . .. . .." " ,.,, ,. ...:: . ..
.:,..,..,.."..:. , . ::: .::;. ., . .:. , : . . . . : , : : , . ~-:.. :., . .-;. .:: : : ... . .;: , :. .:: . .. . . :_. . ,., : ; , . '.: ..; . .
z .: ; . .. : . , . .:..: : , .. . ., . . ~.: - . ., :. ~.. . ;, . ... .. . ..
. - ., , ; , ,..;.. , . . . . .. .. , ~'O 94/11959 ~ ~ ~ ~ ~ ~ ~ PC;f/U~93/10757 node 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 5532, 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 5542 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 5534 is to prevent generating an alert every time a suspect country code is called. The theory is that not every user whn calls the suspect country a few times is a fraudulent user.
~iext, at step S53S, 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.
. . ,,:.: ~ ;,... ,- . ; . . .; . .:.. :: ,;. ,._. w . ;>:

W~ 94/11959 ~ ~ ~ ~ ~ ~ ~ P~:T/US93/10757 Ne~ct, at step S540, the service sends the alert generated at step S536 to the Evaluate Subscriber Condition service 5522, described below.
is r ~ Lastly, the service flows to step 5542 which marls 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.
Referring to FIG. 4A, if the event type did not match at step 5482, the alert manager procedure flows to step 5486. 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 analyzes the incoming event.
r Referring to FIG. 4D, the Analyze Credit Limit Event service S48~ 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 part~.cular subscriber ID.
Next, at step S546, the service associates the event under consideration with the newly generated alert by i , . i , adding a new entry to the alert-events database.
Next, at step 8548, the service sends the alert i generated at s~'ep 5544 to the Evaluate Subscriber Condition service S522, described below.
Lastly, the service flows to step 5550 which marks the completion of the analysis for the present event and the .:. ., .. .. ... . . .... , , : ~. . . ., ra.: . . . . . , . . ..;. ..,, ..-.~,: ; ;; . , , .,, , .. ". ,., .. ... . . . . . ., .. .:
:.
:, ;., ... .: . '~ <; . : ..;:v ;:_;; ~.,::: ''. '~:~- .. :~,~ ;', ~ . .. . ~ , ~ , .:- : : . ."'-_ , .'. , , . ;;: . .,. . . ,~. , . . ,.:: . :: .:.,. .., : : . ::.. ~ . .,: ;:,, .:.. .. . :. ; ,:.. ,. ;;, :. .:.
.. . .. . .. ..., .. . , , >.., .. . . .. ..

lVOl4l11959 ' ~ 1'C~'/US93/10757 alert manager procedure flows to step 5520 (see FIG. 4A) to determine whether the subscriber's condition needs to be I
evaluated, as discussed below.
Referring to FIG. 4A, if the event type did not match at step S48F, the alert manager procedure flows to step S490. At this step, if the event type is an overlap call event, the pr~cedure flows to step 5492 where the Analyze Call Overlap Event service analyzes the incoming event.
Referring to FIG. 4E, the Analyze Call Overlap Event ~.0 service S492 generates a new overlap call alert for each incoming overlap call event. The alert type willvbe either °'simultaneous call" or "geographic dispersion" depending upon the subtype oaf the incoming event.
Upon receiving the event context data structure as an argument, the service, at step 5552, 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'°a otherwise alert~type is set to "geographic dispersion."
In ei~.her case, after the alert type has been determined, the service, at step S558, generates an alert by adding a n,ew entry with an alert type equal toithe value ,: , . , held in the alert~type variable to the alerts database for this particular subscriber ID.
Next, at step 5560, the service associates the event under consideration with the newly generated alert by adding a new entry to the alert-events database.
".r." .. ~ . . . .-. . . . .. . . . : .. . , . . , ;-. ', ; :,. ,,.. '' ; .. -:. ;; ':
:. , . . . , . , , . , ,. . . , ,_ ; . .,. ~ ...... . ... : .. ,.. . ::. , 4_.'u. ::.....,, n, :.:,: ' ~-...t. :..'.':.; : y;'...' ','.. .',.. ~,..
...,~; ..... .,., ,.. :.,.. ..,.,:". :,: '. _ ."..-. _ ..':.:.; , ~,;..... ~
..: . '.':~:. . .:~..~ . ':':'...'. ~:.~' ',:' . .:..~ :':..::.~ . .

' ~ 14 ~ 13 5 Pcr/vs~~m o~s~
Ve'~ 94/11959 Next, at step S562, the service sends the alert generated at step 5558 to the Evaluate Subscriber Condition service 5522, described below.
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 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 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. 4F, the Analyze duration Event ~.5 service 5496 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 1' needs ~to be performed to determine whether Ithe newly received event affects the subscriber's condition on days other than the call date; accordingly, the service flows to step 5568: Otherwise, the service flows to step S590.
At step 5568, the service retrieves all past events from the events database that satisfy each of the following ..
~1~.9~.3:~
:.;
WO 94/11959 P(.'T/US93/1U7S'7 three conditionsv (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 retrieved event has a call date within five days of the call date of the event being analyzed.
At step 5570, the service tests whether the number of events retrieved ~t step 5568 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, he 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 l5 suspect increase in call duration because exactly three duration-type events have occurred for this particular subscriber 1D within the last five days. Although one embod~.ment of the present invention utilizes the particular values three fox the number of events; and five for the number of days, other values that prove useful maybe used for this step.
j ,~t step S574 the service associates the event under j , , ; ,.
consideration with the newly generated alert by adding a j new entry to the alert-events database.
Next, at step S576, the service sends the alert generated at step 5572 to the Evaluate Subscriber condition service 5522, described below.

PCi'I US93/10757 W~ 94/11959 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.
Next, at step 5580, if the total percentage increase as calculated at step S578 is greater than or equal to 100%
-- indicating a suspect increase in call duration because the five-day moving average call duratian has doubled in the last five days -- the service flows to step 5582.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 0, no alert is generated and the service flows to step 5588 which marks its completion.
assuming an alert was generated, the service, at step 5584, associates the present event with the newly generated a new entry to the alert-events database.
alert by adding I Then, at step 5586, the service sends the alert generated at step 5572 to the Evaluate Subscriber Condition i i service 5522, described below.
Lastly, the service flows to step 5588 which marks the completion of the analysis f,or 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.
If, at step 5566, 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 WO X4/11959 ~ ~ ~ PCT/U593/10757 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 v to the next four days (or up to today°s date) as well as the call date to determine if the event being considered j has made any changes to the alert status and subscriber condition for those days. Accordingly, the service flows from step S566 to step 5590, where a place-holding variable, datewindex, is initially set to the call data of the event being analyzed.
As illustrated in FIG. 4F, steps S592 through 5608 are identical to steps 5568 through 5586, described above in detail, so that no further discussion of these steps is necessary. The service performs steps 5592 through 5608 once for each different value of date index. After the date index variable is iteratively incremented by one at step 5610, steps S592 through 5608 are repeated up to a maximum of five iterations as long as the current value of date zndex ~a on or before today°s date, as determined at step 5612. 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.
..; ! ~~
Onae the date index loop is complete, the service flows to step 5588 which marks the completion of the 2~ analysis for the present event and the alert nidnager procedure flows td step 5520 (see FIG. 4A) to determine whether the subscriber's condition needs to be evaluated, as discussed below.

~e~~~~
WO 94/i 1959 PCf/US93/1~757 Referring to FIG. 4A, if the event type did not match at step 5494, 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 S500 where the Analyze International Duration Event service analyzes the incoming event.
The Analyze International Duration Event service 5500 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. 4G, is nearly identical to the Analyze Duration Event.Serv~.ce 5496, discussed above in detail, except the event database is searched for international duration events and the possible alert types 25 are "3 in 5 International Duration'° and °°Doubling Tnternation~l Duration," no further d3.scussion of this service is felt to be necessary.
Referring to FIG. 4A, if the event type did not match at step 5498, the alert manager procedure flows to step S502. At this step, if the event type is a threshold event, the procedure f~.ows to step 5504 where the Analyze Threshold Event service analyzes the,incom~.ng evea~t.;
~.
Referring to FIG. 4H, the Analyze Threshold Event ., service 5504 generates a threshold alert for each incoming threshold event. The tyge of alert generated corresponds to the type c~f event being analyzed (daily, five-day moving average, or ten-day moving average).

~~ 94/1 X959 ~ PCT/US93/10757 ~~4~~3~

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.
If the call date is today na historical analysis needs to be perfox°aned to determine ~,rhether the newly received event of facts the subscriber ° s condition on days other than the call datea accordingly, the service flows to step 5616.
Otherwise, the service flows to step 5636.
20 At steps 5616 through 5624; 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 S618, 5622, or S626, ~C~ "Daily Threshold,'° "5 Day Average Threshold," or "10 Day Average Threshold,°' respectively:
If the event type saes nit recognized, an inconsistency in the system has been encountered, and the service flows to step 5628 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 5630, where an alert is generated by adding a new entry, with an alert type equal to the value held i:r~ the alert_type variable; to the alerts database for this particular subscriber TD.
The sez~rice flowe 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 S634, the service sends the alert generated at step S630 to the Evaluate Subscriber Condition service 5522, described below.

Lastly, the service flows to step 5665 which marks the completion of the analysis far 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.

If, at step 5614, 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 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 5614 to step 5636, where a place-holding variable, date~index, is initially set to the call date of the event being analyzed.

As illustrated in FIG. 4H, steps 5638 through 5650 are identical to steps S616 through 5628, 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 5648, the service flows to step 5652 where the 1~'O 94/11959 , P~CT/US93/1U757 service se~,r~~~~~ 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 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 5638 through S648.
If a matching alert is found during the search at step S652, 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 ~rariable is incremented by cane.
If, however, no matching alerts are found during the alerts database search at step S652, the service flcaws 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 a~.erts database for 'this particular subscriber ID.
The service flows next to step 5658 where the event being analyzed is'associated with the newly generated alert by addinc~,,a new entry to the alertaevents database, ;
' '' !
Then, at step 5550, the service fends the alert generated at step 5630 to the Evaluate Subscriber Condition service 5522, described below The servzde performs steps S652 through X662 once for each different value of date index. After the date index variable is iterative7:y incremented by one at step 5662, .::1 ~'~O 94/11959 PCTlUS93/10757 steps 5652 through 5662 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 5664.
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 Jtep 566 5 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 belaw.
Referring s FIG. 4A, if the event type did not match at step S502, the alert manager procedure flows to step 5506. At this step, if the event type is an international threshold event, the procedure flows to step 5508 where the Analyse International Event service analyzes the incoming event.
The Analyze International Threshold Event service 5508 generates a threshold event for each incoming international threshold event. The type of alert generated corresponds to the type of event being analyzed (daily,internati,onal, five-day international moving average, or ten-day international moving average). Because this service, ~.llustrated in FTG: 4Iis 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 WO 94111959 PCT/L1S93/I~757 International Threshold, " "5 Day International Average Threshold," and °'10 Day International Average Threshold,"
no further discussion of this service is believed i necessary.
Referring to FIG. 4A, if the event type did not match at step 5506, the alert manager procedure service flows to step 5510. At this step, if the event type is a velocity event, the procedure flows to step X512 where the Analyze Velocity Event service analyzes the incoming event.
Referring to FIG: 4J, the Analyze Velocity Event service 5512 is responsible for collecting, incoming velocity event information and determining tJhether a newly received event should trigger an alext.
upon receiving the evea~t context data structure as an 1 15 argument, ~ the service, at step 5666, detsrm~.nes whethex the call date is the same as today's date -- that ie, the date on which the CCF record is being processed.
If the ca~:l date is today no historical analysis needs to k~e performed to, determine whether the newly received event affects fihe subscriber ° s condition on days other than the call date; accordingly, the service flows to step S66S.
Otherwise, the service flows to step 5690.
At step S66~, the seivice retrieves all past events from the events database which satisfy each' of floe 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 _ ______ . __ ._.._. _. . .... . . ..... _~ . ....... . .-:..__- r..~ ~_ .., i ..,.,~
wt~ jai a ~ 9s9 ~ ~ ~ ~ 13 j P4 rius~~i~ o7s7 _63_ retrieved event has a call date within five days of the call date of the event being analyzed.
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 towtep 5678.
a If, however, the number of retrieved events is equal i to three, the service flaws to step 5672 where an alert is generated by adding a new entry with alert type "3 in 5 20 Velocity" to the alerts database far 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 far this particular subscriber TD within the last five days. Although one 1.5 embodiment of the present invention utilizes the particular values three for the number of events, and five far the number of days, ether values that prove useful may be used far this step.
At step 5674 the service associates the event under 20 consideration with the newly generated alert by adding a A
new entry to the alert-events database.
Next, ~t step S676, the service sends ,the ;alert generated at step 5672 to the Evaluate Subscriber Condition service 5522, described below.
25 Next, at step 5678, 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 fa.ve days far each event retrieved at step S668.

~149~.3~.5 ~ f'' W~ 94!11959 PCT/US93/10757 Next, at step 5680, if the total percentage increase as calculated at step S678 is greater than or equal to 100%
-- 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 5682 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 100x, no alert i~ generated and the service 1.0 flows to step S688 which marks its, completion.
. If an alert Haas 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 5672 to the Evaluate Subscriber Condition service S522, described below.
LastZy,,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. 4Aj to determine urhetk~er the subscrilaer's condition neod~ to be evaluated, as discussed below.
' ~ i , , ' ; , ~ ~; , ~
If, at step S666, the service determined that the call date of the event being;analyz~d was before today's date, a historical anal sis needs to be erformed to determine whether the newly rec~:ived event affects the'subscriber's condition an days other than the call date. More specifically; the event be~.ng analyzed needs to be applied -~ r . .
~~ .t....-..~
r,~: r:' ':a 1..~' ' ... ' ; ... i ' :,~.. " ..v " '. , . ; ~ .:":'. . _:: . ,.,,: ..,.~~.. ... ~
. ...~.. . :...,;
~.t e.
~~.t~...... ,...... .. .~.~ ~.., . ....,...... . .~._ . ...,_.. .,-...".... .
.. ,..n.~... .... . .. . ,. . .. ...... .... . . .... _..........:. ....: :...
.,.. ..r... .. .. , ...

. ,v) _ iVVdi 94/1959 ~ ~ L~ ~ ~ ~,~ PCT/LS93/10757 --65°
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 5666 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 5692 through S708 are identical to steps S668 through S686, described above in ~.0 detail, so that no further discussion of these steps is thought necessary: The service performs steps 5692 through S?08 once for each different value of date index. After the date index variable-is iteratively incremented by ane at step S?10, steps S692 through S708 are repeated up to a maximum of five iteratie~ns as long as the current value of date~index is on or before today's date, as deternnined at step S?12. It should be noted that either ~r both a "3 in 5 Velocity" alert or a "I~aubling ~Jelocity" alert xnay be generated for each separate value of date_index.
Once the date index loop is complete, the service flows to step S688 which marks tine comgl~tion of the analysis for' the present event and, the alert manager i . i procedure flows to stap 5520 (see FIG. 4A) to determine whether the subscriber°s condition needs to ba evaluated, ' 25 as discussed belew:
Referring to FIG. 4A; if the event type did nat match at step S510, the alert manager procedure flows to step 5514: At this step, if the event type is an international.
.., ?:::, ., ... ,..':: . .:,::-. :;:-- w.,, ,,,..:. ; ...~,..... ;
...:1;..;- . .,, ..::. . . ...; .., . .:, .._,... .~ ., : ;. ~ ~.:'.~. . ~
.,:...:. , ,.
tSw".1..,.:.,.......",:.... ~... ::.:...:...,....1 . ...:.:;- ...:..~~. , ._......::. . ~ ..,: ~. ~.,.. . .......:. . .",. :... ..~... ,-... ., .......
. . '., ,..:.., .... . ..

i~~ 94!11959 ~ ~ ~ ~ ~ PCT/tJS93/10757 °66°
velocity event, the procedure flows to step S518 where the 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. Wecause this service, illustrated in FIG. 4K, 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 SIG. 4A; if the went type did not match at step 5514, the alert manager prcacedure 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 5514,. an inconsistency ~.n the system has been 2 0 encountered and an error -is l ogged to the error hand! ing server. If, however, the event type matched in one of the alert manager procedure,steps 5478 through 5514, and an analysis° was performed 'as described above, the alert !?tanager procedure; at step S520; tests whether one or more ~~ new alerts were generated for tha particular event being analyzed. I~ the present event did not generate any new alerts, the paarticular subscriber°s condition remains unchanged arid the procedure flows to seep 5524 which marks .,.
~~.~~'~ 3 i~0 94/ 11959 PCT/US93/ 1 U757 the completion of the alert manager procedure.
Accordingly, the alert manager procedure returns to step S476 to await arrival of the next event context data structure.
Turning again to step 5520, if at least one new alert was generated for the present event, the procedure flows to step S522 to evaluate the present subscriber's condition.
Referring to FIG. 4b, 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 tf~e past and present alert information, the service, using an "inference engine" evaluates a particular subscriber's condition based on a predetermined set of rules.
~.5 Upon receiving as input information that describes the type and date of the newly generated alert, the service, at step S716 loads the know7.edge 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).
Next, at step 5728, the service retrieves all past alerts from the alerts database which satisfy each of the following three conditions (2) the retrieved alert has the same subscriber LD as the newly generated alerts {2) the call date of retrieved alert is the same as the call W~ 94/ 1199 P~.'~'1L1S93/10757 _~8_ 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 5720, 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 nineteen 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, (1?) doubling duration, (18) 3-in-5 international duration, and (19) doubling international duration.
Next, at step 5722, a "hypothesis,°' or answer, is suggested to the inference engine. This directs the search for the ourrent alert-state of ;the subscriber along a,path . , ; ~ , associated with the newly generated alert, rather than allowing the inference engine to search the entire knowledge baseo The hypothesis suggested is that an alert state exists that is related to the alert-type of the newly generated alex°t.
.;, ,. . . . ,:... , , , . .. . . . .; .. . . ., ._ . . :; ;.. .. ,.: ,, ,.;. ,; _, ;:v~... ... ., ~ .... <. . ,.~;.. . ... ,.;
,~. . . . .:- . ~.~ .. :,.. . .., . _ ,... ,-:
v:
:..,..... '.. ;
.;:; : :: . _, . ...:, v ~, .. : v. . : .. :. ,~: . . : . ~. ~ w .. ..: . r ~.
. : ~" -, . . , : :::

~:~4J1~J~
iir0 94/~ x99 PCT/tJS93/10757 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 ~.0 severe indication of possible fraudulent telecommunication activity that the ~fraud detection system register. A
"yellow" alert-state similarly indicates the possibility of fraudulent telecommunications activ~.ty, but to a lesser extent than a red alert-state. If no alert-state was 1S generated, the subscriber's alert-state is left unchanged and no additional. processing is necessary. Accordingly, the service flows to step 5780 which marks the completion of the evaluation. Tf, at step 5726, the service determines that a red alert-state was generated by this run 20 of the inference engine, the service flows to step S742 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 5744, the ser~rice tests whether the 25 subscriber's previous alert°state was red. If so, there is no need to generate an additional red alert-state, and the service .flows to step 5730 which marks completion of the evaluation.
~.. :. ,. . . :: ., ,: ;. ., . ;.... ~.. ~,._ . . ::. ~ ..,. , , , .; . ; : ~, , :. :, ,.... .
yr . . .,: . ' ,,, .; ,~,... ;~,. ;, ~, ', . ' .. . ,:' . '. ~ ,.' ~ :: . ' -'' . .' .
., '.,... ... .~ . .~ ~_..'.~ ..-:.,s. .::., '..'... '.., '' , v.' :'. .. ..
......' °
W0 9d/11959 ~'~i'/U~93/10757 _70_ If, however, the subscriber°s previous alert-state was other than red, the service, at step 5736, tests whether the subscriber's previous alert-state was yellow. If so, the service flows to step S74S 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 S74S is skipped and the service flows directly to step S750.
At step 5750, 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 5752, the service flows to step S73O which marks the completion of the evaluation:
Tf, 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 5732 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 a~:ert-°st~te, and the service flows to step S730 which marks completion of the evaluation.
If, ho~ae~er, the subscriber's previous alert-state was neither yellow nor red °- i.e., a "normal" alert-state --~~ ~~I3~.
W('3 94/11959 PCT/US93/10757 the service flows to step S?36 where the newly generated yellow alert--state is recorded in the alert°states database for this particular subscriber TD.
After notice of the newly generated and recorded yellow alert-state is sent to the system operator at step 5738, the service flows to step S730 which marks the completion of the evaluation>
If the Evaluate Subscriber Condition serviee 5522 generates a new alert-state which differs from the 20 subscriber's present alert-state, the system operator is notified via the user interface 117. The user'interface 117 is a user-friendly Graphical Lls~r Interface (GUI which communicates and receives several items and types of .
information to and from- a eystem operater 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 relat~.d devices. As shown in FIGS. 6, 9, and 11, the infarmation communicated to the system operator includes inforomation regarding a subscriber's vital .statistics,;,ale~t-st,~tes, . . ' " ! '. ~ ' history of alerts and events, and a graph of call velocity for a particular subscriber. A system operator can selectively choose which item or ~aems 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 systam operator may control system .. . ;... ,.._ . ., ; ..; ;;, :, .,. ,;: , .. . . ~.
r 7: : _.. :.. : , : ~ . ,. . . . : . . . ' : : .. . ; . . . .
'. . .. . . ~ . ... .. , . ..:
;. . . ~ ...:,. . ..' . .. .. . ' , ., :.. .. ;:
: .. . . .,... . , ~ . , , : . , . .:.. . :: :., .,," . .. . ' . : .
. . . :: . , : , ~ : . . . : .. ; :. . . . : :: . . . : .: :.. . ...' s . .:' .. :. ,. , :-,: ~ . ; , ...: . , . : . , . ,. ;". . . . . . , ,... . :
. ..a: . : . . . . , : .,". : .
. .. . .. ,. ,.:. ,. ., . . .,; .:,., :.;, .,; , ,' " . . ' . ,.
..~:.. . .... . . .. .. . ,. " . . . . . , . ;,. :

a ,, !~V~ 94/11959 ' ' PGT/US93/10757 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 5754. 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 5755 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, Adman 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 5758, initiates the Investigate Subscriber.Window 80, a flowchart for which is shown in FIG. 5B. 'Upon initiation, the Investigate Subscriber Window 80, at step 5764, prompts the system operator to enter a subscriber ID to be investigated.
As shown in the Investigate Subscriber Window 80 in FTG. 8, when a subscriber zD is selected from the select ,... . . ,... ; :: , ,;. .,, ,,.. .,. _; ; . . :. ,:. , ".. ; " ,,;' : , ,,, :';'; ,. : .. :: , ,.,.. . ,.
S ~ . :.'.'.'.. n ., ... n, . ..,", ' ';a ,;.~,::... , .,....~ , ~:;~ ~ .
..._...., ... ,,.,.".,. ..:~:. '.-. , .'~~.. ~. ,. ,.: ~ -. '. : .' '..' l;.
;, ., . , PCT/L'S93/10757 W~ 94!119S9 , _?3-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 82e, 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 max identify a subscriber to be investigated by entering a MSN 82c or a MIN 82d in the Investigate,SUbscriber Window 80: Tf 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 t interface for investigation.
The system operator has several options under the Investigate Subscriber Window 80, as indicated by steps S768 through 8784 in FIG. 5B, includa.ng the following:
graphing the call velocity of a particular subscriber (see FIG. 9); marking a selected alert as "cleared";imarki,ng a selected alert as '°uncl~ar~d" : allowing the system operator ,to enter a textual comment in the alert field for a particular ubscriber~ and quitting the znv~stigate Subscriber Window 80. Several of these options are represented'as buttons at the bottom of the Tnvestigate Subscriber Window 80 in FIG. 8.
_ ., .... _..; " .-:. , .., ;,, , ,.,. .,.
.. _..

214~~3~
WO 94/11959 PCf/US93/10757 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 far 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 in~3icates 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 (1~.2) and shows an increase of almest 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 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 :, .: -..::. :., ...-.:. ~-: ....__.. .. ,:;:. ..-,:.:., ~: :,:: . ;.. , : :.~
:; .:, . ,.., . , : ,.,, , ......;,."..: ... .... ...,.,.:.:.: ,. ,., ..:.......:~...... :.: . ;......:.
: :. . . . ... .. . ..... .. ...... ...;, .. ..:..,.. . ..
"t .E ~.. ",. ". - : ~.~. . . ..; ~. . ;.. , .: ... . . .. . .. . . . ... , ..,. ~.: r. . ,.. . .. .: . . . ~ , ., .. . . , ...., :. ~ . . ., . . . . , .-; , .

~~.~~.~3~
WC9 9d/11959 PCT/LJ~93/10757 -?5-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 marleed as °'cleared°' in the alerts database and will no longer be considered by the evaluate subscriber condition service in generating alert-states for the selected subscriber.
If the system operator clicks the Unclear Alert State buttpn 8?a 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; po~sibly'regarding the status and results of an investigation performed for the selected subscriber ID, in the Subscriber Comanents field 85 ~0 of the Investigate Subscriber Windota 80.
Lastly, if the system operator wishes to gait, the Investigator Subscribers Window 80 is,terminated. ;, When the system operator selects Monitor Alerts ?7 in the Control Window 70 (see FIG. ?), the user interface, at step S762, initiates the Monitor Alerts Window 92 (see FIG.
11) , a flowchart for ~rhich 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 ~.~,i W~'94111959 ~ ~ ~ ~ ~ P~.'TlUS93/10757 , 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 regian 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. 7j.
Next, at step 5792, the operator has the option to select the alert-state level to be monitored. At step 5794, the operator selects a new al.ert-state level (either yellow 95a or red 95bj 'to monitor, as shown in the Monitor Alerts Window 92 in FIG> 11 under the heading Select alert level 95.
Mext, at step S796, the Window displays a scrolled list of alert-states ~.n the bottom-half of the Monitor Alerts Window 92, under tyre heading Mealtime Alert States 9~~ carresponding to the alert-state level selected and the Affinity Groups selected.
. i , , , ,, At step 5798, if the operatar chooses to investigate a specific alert-sate cl~splayed in the scrolled list by clicking the Investigate button 97 at the bottom of the Monitor Alerts ~lindow 92, the subscriber-specific information is displayed as shown in FIG. 8. hffectively, this operation invokes the Investigate Subscriber Window 80 ., ~.,.
s., .;. , .f .

.., r .v.
d' .
.C .6. .., v , ,. : t .
r .
,r .::
,~ .. ,a ..
.r.:;' , ::' ., i ~..
.x~..-.
. x,.. ;~~
.7.l.",.7,...J... . .,e.....,..,...o ...v... ....,..... .r ... .........
...~.".., . ... ...~ .~ . ,. ,.. ,.n .. . , . n ..1'~~~:. . .. . . .t r3 PCTlUS93l10757 WO 94/g1959 _77_ directly from the Monitor Alerts Window 92 for a single subscriber I~.
Additionally, the system operator may request a report to be generated and printed at steps S802 and 5804 , 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 record processed in serial fashion, in actual operation~.the fraud detection system can process multiple CCF retards in para11e1, 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 cal l activity as compared with that particular subscriber's typical call activity, ~n individualized fraud detection system is provided that performs with squall success " , . ; L , , regardless of whether a subscriber is typically a low, medium or high volume user.
~hird,~~he present fraud detection system is capable of indicating potentially fraudulent activity b~ detecting an abnormal deviation in usage without regard to the type of fraudulent activity involved, whether it be cloning W~ 9d/1 159 PC'flUS93/10757 .-7$-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 noranal usage parameters such as call duration, call velocity, call overlap, arid 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.
~'he 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 ~i ; , telecommunications system. In such a system, a legitimate subscriber; intending to pay for services used, will tend to use the services more sparingly than a fraudulent user wha has no intention caf ever paying for services used.
Once a fraudulent user had misappropriated an otherwise legitimate subscriber identifa.er to gain access to the ':1 ~'O 94/11959 P~f/~JS93/10757 21~9I3_-;
_7g-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 a,Zia, 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 filled to the subscriber assigned to the calling card number used to place' he calls. Each use of ~.5 the calling card calling card number generates a separate record containing substantially the,sam~ information as a cellular telephone system CDR rec~rd. The switch interface of the present 'fraud detection system can be easily modified to accept call data records in differing formats.
~0 Therefore, upon inputting calling card call data records into, the present fraud 'defection system, potentially fraudulent calling card activity world be'detected in, the i , ., i ~, . . . i i: ; i manner described above.
Sa:xth, the fraud detection system: of the present 25 invention provides an interactive GUI'display eystem that allows a system operator to view several items of information concurrently, , such as the history of ~.lerts and events which led to an alert°state for a particular ,~~ ~~_ ~._~. ., ..., .:.: . :. ..-... ; - ;-.
_._ ._ _...~_. _:. ,.:.--.,"'._-,. ..,.,. .--,- . . ,. . .. . ".. ., r -. " .
. .. . . . : . , , i~'O 94/1 1959 ~~.~9v1:3 P~'/LJS93f 10757 -80°
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 S information that triggered the fraud detection system to indicate that a particular subscriber IA is potentially suspected of fraudulent activity.
Further, and among other advantages, because several of the fraud detection parameters -- such as the maximum i 10 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 operators the present fraud detection system can be readily tailored to 15 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 vario~zs changes, substitutions and alterations can be made herein without departing from ~0 the spirit and scope of the invention as defined by the , appended claims.

Wf~ 91/11959 ~ ~ ~ ~ ~ ~ ~ ~ : PCTIUS93/10757 _$i-APPENDIX A
TABLE I:
RULE : Rule 1 If S red_condition is precisely equal to 1 Then alerts complete is confirmed.
RULE : Rule 2 there is evidence of eval countrycode_rules And red condition is precisely .equal to 1 Then country code red condition is confirmed.

RULE : Rule 3 If there is evidence of eval credit limit rules And red condition is precisely equal to 1 Then credit Limit red condition is confirmed.

' 2 Q RULE : Rule 4 there is evidence of eval daily intl thresh_rules And red_candition is precisely equal to 1 Then condition daily intl_thresh red 2 5 _ is confirmed RULE : Rule S

there is evidence of wal daily thresh rules ' p,nd red~condition is precisely equal to l 3 ~ Then daily,~thresh red dondition is confirmed.

RULE : Rule'6 there is evidence of ewal duration rules 3 5 And red condition is precisely equal to 1 Then duration red_condition ; , l . ~ . , ~ ' ' is confirmed:

RULE : Rule 7 ~ a suspect' country,~code alert is precisely equal to I

And intl_velocity~,alert is precisely 'equal to 1 Then eval country~code_rules is confirmed.

And 1' is assigned to red condition WO 94/11959 ~ ~ ~ ~ ~ ~ ~ 1'~I'/U593/10757 RULE : Rule 8 If credit limit alert is precisely equal to 1 Then eval_credit Iimit rules is confirmed.
And 1 is assigned to reducondition RULE : Rule 9 If daily intl_thresh alert is precisely equal to 1 ~ 0 And intl velocity_alert is precisely equal to 1 Then eval daily~intl thresh rules is confirmed.

And 1 is assigned to redrcondition RULE : Rule 10 If daily~thresh-alert is precisely equal to 1 And velocity alert is precisely equal to 1 Then eval daily-thresh_rules is confirmed.

Z 0 And 1 is assigned to red condition RULE ; Rule 11 duration alert is precisely equal to 1 And velociyalert is precisely equal to 1 2 5 Then eval dura~ion_rules is confirmed:

And 1 is assigned to red condition RULE : Rule 12 3 p five,~day intl_thresh_alert is precisely equal tc~ 1 .And intl_velocity alert is precisely equal to Then eval-five dayrintl_thresh rules is confirmed.

And 1 is assigned to red condition 3 5 RULE ; Rule 13 five dayrthresh_alert is precisely equal to 1 And velocity-alert is precisely equal to 1 . . ; Then' evatlfive~day-thresh ryles ,:

, is confirmed.

pnd 1 is assigned to red condition R1.JLE : Rule 14 geographic dispersion alert is precisely equal to 1 4 5 Then eval~eographie lisp rules is confirmed:

And l is assigned to red condition !WO 94/1199 ~ ~ ~ ~ .~ ~ ~ PCT/US93/10757 RULE : Rule 15 intl_duration alert is precisely equal to 1 And intl_velocity alert is precisely equal to 1 ;

Then eval_intl_duration_rules is confirmed.

A.nd 1 is assigned to red_condition RULE : Rele 22 . If ' intl_velocitylalert is precisely equal to 1 -pnd suspeet_term alert is precisely equal to 1 Then eval intl_velocity~rules is confirmed.

And l is assigned to red cond9tion RULE : Rule 21 intl velocity~alert is precisely equal to 1 And suspect_country code_alert, is precisely equal to 1 Then eval intl velocity rules ' t 2 is confirmed.
p pn,d l is assigned to red_condition RULE : Rule 20 intl_velocity alert is precisely equal to 1 2 And daily intl thresh alert is precisely equal to 1 Then eval intl velocity-rules is ~zifirmed~

.And 1 is assigraed to red condition RULE : Rule l9 3 Ii, ~

intl velocity-alert is;precisety equat to 1 And five day intl thresh alert is precisely equal to 1 Then eval intt 'velocity-rules is cotafirrtted.

3 And 1 is assigned to red condition RULE : Rule 18 intl velocity~alert is precisely equal,to 1 , ; ,"
~

,And ten day'~,intl thresh alert is precisely equal to 1 -4 Then eval intl velocity rules is confirmed.

And 1 is assigned to red condition RULE : Rule 17 45 intl velocity~alert is precisely equal to 1 ~lnd velocity alert is precisely equal to 1 den eval intl velocity rules is can~rmed:

And 1 is assigned to red conditi~i~

W~ 94111959 ~ ~ ~ 9 ~ 3 ~ . . . ., P~l1J593110757 , _g4_ RULE : Rule 16 If intl_velocity,~alert is precisely equal to 1 And inthduration,~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 rules eval_simultatxeous_calI

_ 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 Z

Then eval suspect_term_rules is confirmed:

2 0 Ard 1 is assigned to red~conditian RULE : Rule 24 suspect term alert is precisely equal to 1 And intl velocityTalert is precisely equal to 1 Then eval,~suspect term_rules is confirmed.

And 1 is assigned to red condition RULE : Rule 26 If ' 3 0 thresh'alert is precisely equal to 1 daywintl ten _ _ And intl veloGity_alert is precisely equal to 1 Then eval ten_day,~intl thresh~rules is confirmed:

And i is assigned to red condition ;~ 5 RULE : Rule 27 ten day thresh_alert is precisely equal to 1 And velocity,~alert is precisely equal to 1 Then .eval ten day,~thresh rules ~ i ~ ; _ s _ 4 , 0 is confirmed.

And 1 is assigned to red condition RULE : Rule 33 velocity alert is precisely equal to 1 4 term alert is precisely equal to 1 5 And suspect den _ eval velocity rules is confirmed.

And 1 is assigned to red condition . ::. :- :,:._., : : :;,. ~ . .....;,. ~~- . ~.- ; , ;:,. ;:; , :;.- . . .- ;
. . . ,... , .:. .
'~,. . : ,;, " ," ,., , . . ...,.. ,. <. .. : - ,. . . ~ . . . . . . : . . . .
, . . . , . :_ .
., . ., ,. . .. ;,. . ;;; . . : . .. ~ . ~ . - , :. ~ ,., ,, .. ,, , .. ; ., ., 1.......r....,... ,.....'... :.<... . .,..t..."......:'. ., ~.... ... ..
..:...,'::..~,..,. . . .. ....~.... ...:... ..:. .: .,:- ..,..... ,~, ., ~,~ ~4/i 1959 PCT/US93/1075'7 ~~.~.3~
RULE : Rule 32 ' If . velocityalert is precisely equal to 1 .And dailythresh alert is precisely equal to 1 Then eval,welocity rules is confirmed.

.And 1 is assigned to red condition RULE : Rule 3l If velocity~alert is precisely equal to 1 And five day thresh alert is precisely equal to Then eval velocityrules is confirmed:

And 1 is assigned to red~condition 25 RULE : Rule 30 velocity alert is precisely equal to 1 And ten_day thresh alert is precisely equal to 1 Then eval_velocity_rules 2 is confirmed:

And 1 is assigned to red condition RULE : Rule 29 velocity~alert is precisely equal to 1 25 And intl velocity_alert is precisely equal to 1 Then eval velocity rules is confirmed.

And Z is assigned to red condition RULE : Rule 28 3 If velocity alert is precisely equal to 1 And duratiom alert is precisely equal to 1 den velocity rules eval _ is confir~ted.

3 And I is assigned to redwcondition RULE : Rule'34 there is evidence of eval five day intl thresh rules , , ' ~ 'Arid red_condiunit is precisely e~uaI to 1 '~

4 Then five_day intl_thresh_red condition 0 .

is confirmed:

RULE : Rule 35 there is evidence of eval five_day thresh_rules 4 And red condition is precisely equal to 1 Then five day~thresh_red_condition 1S COnfIImed.
.:......... _, ... '.,5 s ...:" _,..-;r. .--r :,;
.......... . ...,...--...,... . ':;.n , t:; ~-. s~; s .....,..... r ......... ..... ,r. , '..:v,. ...... ..... "
..
. . .; .. . ,.. . .1 . ,.

t~C~ 94/11959 ~ ~ ~ ~ ~ ~ ~ PCT/~JS93/10757 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;@PVJFALSE=FALSE;@PWNOTKNOWN=

Z 0 FALSE;@PFACTIUNS=FALSE;@PTGAT

Then initialize_strategy is confirmed.

RULE : Rule 38 If ~5 there is evidence of eval intl duration rules And red condition is precisely equal to 1 Then intl duration_red_condition is confirmed.

RULE : Rule 33 2 0 If ' there is evidence of eval_intl_velocity rules And red_condition fs precisely equal to Z

Then intl velocity~red condition is confirmed. .

2 5 RULE : Rule 40 there is evidence of eval simultaneous call rules And red_condition is precisely equal to 1 Then simultaneous call red_condition 0 is confirmed.

RULE : Rule 41 there is evidence of eval suspect~term_ruies And rod condition is precisely equal to 1 3 5 Then suspect team_red_c~ndition ~

is confirmed.

RULE : Rule 42 ! ' If there is evidence of eval 1en_day inththresh rules 4 0 And red condition is procisoly equal to 1 Then ten day,~in~l thresh_red condition is confirmed:

RULE : Rule 43 45 there is evidonce of eval ten day_thresh rules And red condition is precisely equal to 2 Then ten~day'thresh red condition is confirmed.

~14~13~ . . ..
!W(~ 9~1/i1959 P~GT/US93/10757 _g~_ RULE : Rule 4~

If there is evidence of eval velocity~rules And red_condition is precisely equal to 1 Then velocity~red condition is confirmed.

RULE : Rule ~i5 If alert count is greater than 2 And red condition is precisely equal to 0 Then yellose_condition_set is confirmed.

And 1 is assigned to yellow condition .,, W~ 94/11959 ~ ~ '~ ~ PCTlUS93/10757 .
-gg_ APPENDIX B
DETERMINATION OF AIRLINE DISTANCES
1. Long Distance Messaee Telecommunications Service To determine the rate distance between any two MSCs proceed as follows:
a. Obtain the "V" and "H" coardinates.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.
~.0 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.
e. The number of successive divisions by three in steps c. and d, determines the value of "N". Multiply the final sum of the twa squares obtained in step d. by the multiplier specified in the foIlowiatg table for this value of "N" preceding:
2 0 N hyultiplier Minimum Rate Mileage 1 0,9 2 8.1 41 3 72.9 121 4 &56.1 361 2 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 obtained is less than the minimum rate mileage shovsrrt in e. preceding, the 3 0 minimum rate mileage corresponding to the "N" value is applicable.
Example:
' l, . ~ l The message rate distance is required between Detroit, Michigan and Madison, ~risconsin.
3 5 (a) Detroit, Michigan SS36 2828 Madison, Wisconsin 5887 3796 (b) difference 3S1 968 (c1) dividing each difference by three and rounding to nearer integer = 1I7 and 323 .'''~:, -.:,.,.. '~~'.' ~. .,., " ,. . ,' .. :,.., .'.; ::... ..,' .,~,~
.~~.t.~....~.~ ".. ::,' ~.. ;~.,....~ .,:
.
..,,1 dV0 94/1 I9~9 P~T/LJ~93/10757 _g~_ (dl) squaring integers and adding, 117X117 = 13,689 323X323 = 104.329 sure of squared integers 118,018 sum of squared integers is greater than 1777, so divide integers in (c1) by three and repeat (dl) (c2) dividing integers in (c1) by three and rounding = 39 and 108 (d2) squaring integers and adding, 39X39 = 1,521 108X108 = 11.664 sum of sauared integers 13,185 sum of squared integers is greater than 1777, so divide integers in (c2) by three and repeat (d2) (c3) dividing integers in (c2) by three and rounding = 13 and 16 (d3) squaring integers and adding, 13X13 169 =

36X36 = 1,296 ~,5 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, " = 3.
"N

(e) Multiply final sum of squared integers1,465 9 (eorresponding to "N~ = 3) X 72.9 factor 72 b . = 106,798.5 y 2 ~

(f) Square root of 106,798.5 = 326 and a fraction, which is rounded up to 327 miles (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:
25 2. InterexchanQe Distances 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.
3 0 Note: The Difference is always obtained by subtracting the, smaller ~ ~ , coordinate frotri the larger coordinate.
c. Square each difference obtained in b. above.
d. Add the squares of the "V" differenr.,e and the "H" difference obtained in c. above.
' e. Divide the s>xm of the squares obtained in d. above by 10. Pound to the next 3 ~ higher whole number if any fraction is obtained.
f. Obtain the sqe~are root of the result obtained in e. above. This is the rate distance irt miles. (Fractional miles being considered as whole miles).
Example:
The rate distance is required between St. Paul, Minnesota and Osceola, Wisconsin.

,.,.
~V~ 94/11959 P~C'I'/tJS93110757 2.~49~3~
V H
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 5 3. Intraexchange Distances 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.
~ 0 Note: The Difference is always obtained by subtracting the smaller coordinate from the larger coordinate.
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 squaresv obtained in d. shove by 10.
~5 f. Obtain 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 betwreen two MSfa in the Orange, New Jersey 2 0 exchange.
NPA NXX V H
201 675 (East Orange) 5015 1440 201 736 (West Orange) 5014 1448 difference 1 8 ,, i 2 5 squared 1 64 ~ 65 _65 ~ 6. S
square root of 6.5 - 2.55 - 3 airline miles

Claims (50)

CLAIMS:

1. An apparatus for detecting potentially fraudulent telecommunication activity, comprising:
a digital computer;
interface means, operating within said digital computer, for receiving a call information record for each call involving a particular subscriber;
pattern means, operating within said digital computer, for using a plurality of said call information record for said particular subscriber to identify a subscriber-specific pattern of historical call usage and relative to which deviations from said historical call usage can be detected that may be indicative of fraudulent call activity;
comparison means, operating within said digital computer, for comparing the particular subscriber's current call usage with information relating to said subscriber-specific pattern of historical call usage to identify potentially fraudulent call activity; and output means, operating within said digital computer, for outputting an indication of a potentially fraudulent call activity based upon a result of the comparison performed by said comparison means;
wherein said comparison means compares the particular subscriber's current usage with a combination of at least two of the following of said information relating to said subscriber-specific pattern of historical call usage: a subscriber-specific pattern of historical call duration usage, a subscriber-specific pattern of historical call velocity usage, and a subscriber-specific pattern of historical call velocity usage that includes subscriber-specific call velocity thresholds.

2. A telecommunication fraud detection apparatus according to Claim 1, wherein said information relating to said subscriber-specific pattern of historical call usage includes a subscriber-specific daily call velocity threshold and said comparison means compares the particular subscriber's current daily call velocity usage with said subscriber-specific daily call velocity threshold.

3. A telecommunication fraud detection apparatus according to Claim 1, wherein said information relating to said subscriber-specific pattern of historical call usage includes a subscriber-specific five-day moving average call velocity threshold and said comparison means compares the particular subscriber's current five day moving average call velocity usage with said subscriber-specific five-day moving average call velocity threshold.

4. A telecommunication fraud detection apparatus according to Claim 1, wherein said information relating to said subscriber-specific pattern of historical call usage includes a subscriber-specific ten-day moving average call velocity threshold and said comparison means compares the particular subscriber's current ten day moving average call usage with said subscriber-specific ten-day moving average call velocity threshold.

5. A telecommunication fraud detection apparatus according to Claim 1, wherein said comparison means compares the particular subscriber's current usage with a combination of at least two of the following of said information relating to said subscriber-specific pattern of historical call usage: a subscriber-specific pattern of historical call duration usage, a subscriber-specific pattern of historical call velocity usage, and a subscriber-specific pattern of historical call velocity usage that includes subscriber-specific call velocity thresholds.

6. A telecommunication fraud detection apparatus according to Claim 1, wherein at least one of said current call usage and said information relating to said subscriber-specific pattern of historical call usage includes a moving average, and said comparison means performs a comparison using said moving average.

7. A telecommunication fraud detection apparatus according to Claim 1, wherein at least one of said current call usage and said information relating to said subscriber-specific pattern of historical call usage includes a five-day moving average, and said comparison means performs a comparison using said five-day moving average.

8. A telecommunication fraud detection apparatus according to Claim 1, wherein at least one of said current call usage and said information relating to said subscriber-specific pattern of historical call usage includes a ten-day moving average, and said comparison means performs a comparison using said ten-day moving average.

9. A telecommunication fraud detection apparatus according to Claim 1, wherein at least one of said current call usage and said information relating to said subscriber-specific pattern of historical call usage includes a plurality of moving averages, and said comparison means performs a comparison using said plurality of moving averages.

10. A telecommunication fraud detection apparatus according to Claim 1, wherein said current call usage includes a five-day moving average and said information relating to said subscriber-specific pattern of historical call usage includes a ten-day moving average, and said comparison means performs a comparison using said five-day moving average and said ten-day moving average.

11. A telecommunications fraud detection apparatus according to Claim 1, wherein said output means, in response to information provided by said comparison means that identifies potentially fraudulent call activity, decides whether or not to output an indication of a potentially fraudulent call according to a predetermined set of rules.

12. A telecommunication fraud detection apparatus according to Claim 1, wherein said pattern means further comprises means for characterizing the particular subscriber's current call usage as a first moving average and said subscriber-specific pattern of historical call usage as a second moving average, each calculated over a different specified number of days, wherein said comparison means compares the first moving average to said second moving average to determine if a meaningful increase in usage has occurred.

13. A telecommunication fraud detection apparatus according to Claim 12, wherein said second moving average is calculated over a greater number of day than said first moving average, and wherein said output means outputs an indication of potentially fraudulent call activity, when each of the following two conditions are satisfied: (1) the first moving average is greater than the second moving average; and (2) a percentage increase between the first moving average calculated on day (t) and the first moving average calculated on day (t-1) exceeds a predetermined amount.

14. A telecommunication fraud detection apparatus according to Claim 1, wherein said comparison means comprises means for generating an event E, wherein E is a velocity event, a duration event, a velocity threshold event.

15. A telecommunication fraud detection apparatus according to Claim 1, wherein said comparison means comprises means for generating an alert A, wherein A is a doubling velocity alert indicating that the velocity of calls by said particular subscriber has doubled over a predetermined period, a 3-in-5 velocity alert indicating that three velocity-type events have occurred within a five day period that are associated with said particular subscriber, a doubling duration alert indicating that the duration of calls by said particular subscriber has doubled over a predetermined period, a 3-in-5 duration alert indicating that three duration-type events have occurred within a five day period that are associated with said particular subscriber, a daily velocity threshold alert, a 5-day average velocity threshold alert, a 10-day average velocity threshold alert.

16. An apparatus for detecting potentially fraudulent telecommunication activity, comprising:
a digital computer;
interface means, operating within said digital computer, for receiving a call information record for each call involving a particular subscriber;
analysis means, operating within said digital computer, for analyzing the particular subscriber's call usage, based upon one or more of said call information record, to identify potentially fraudulent call activity, said analysis means generating or processing information in the course of identifying potentially fraudulent call activity; and output means, operating within said digital computer, for outputting an indication of said potentially fraudulent call activity based upon a result of the analysis performed by said analysis means, and for displaying at least some of said information generated during the analysis that identified said potentially fraudulent call activity so an assessment of said potentially fraudulent call activity can be made;
wherein said analysis means includes pattern means for using a plurality of said call information record for said particular subscriber to develop information relating to a subscriber-specific pattern of historical call usage, and means for comparing current call usage of the particular subscriber to said information relating to said subscriber-specific pattern of historical call usage, a result of which can identify potentially fraudulent call activity.

17. A telecommunication fraud detection apparatus according to Claim 16, wherein said information displayed by said output means includes an event E, wherein E is a velocity event, a duration event, a velocity threshold event, a suspect number event, a suspect country event, a credit event, or an overlap calls event.

18. A telecommunication fraud detection apparatus according to Claim 16, wherein said information displayed by said output means includes an alert A, wherein A is a doubling velocity alert indicating that the velocity of calls by said particular subscriber has doubled over a predetermined period, a 3-in-5 velocity alert indicating that three velocity events that are associated with said particular subscriber have occurred within a five day period, a doubling duration alert indicating that the duration of calls by a subscriber has doubled over a predetermined period, a 3-in-5 duration alert indicating that three duration-type events that are associated with said particular subscriber have occurred within a five day period, a daily velocity threshold alert, a 5-day average velocity threshold alert, a 10-day average velocity threshold alert, a suspect number alert, a suspect country alert, a credit alert, or an overlap calls alert.

19. A telecommunication fraud detection apparatus according to Claim 16, wherein said information displayed by said output means includes the particular subscriber's status data.

20. A telecommunication fraud detection apparatus according to Claim 16, wherein said information displayed by said output means includes a graph of the subscriber-specific pattern of usage.

21. A telecommunication fraud detection apparatus according to Claim 16, wherein said information displayed by said output means includes a graph of the particular subscriber's call velocity.

22. An apparatus for detecting potentially fraudulent telecommunication activity, comprising:
a digital computer;
interface means, operating within said digital computer, for receiving a call information record for each call involving a particular subscriber, said call information record derived from a telecommunication switching center that establishes connections between telecommunication devices;
comparison means, operating within said digital computer, for comparing the call destination identified in said call information record involving the particular subscriber with a predetermined call destination identified as suspect and maintained in a database to identify potentially fraudulent call activity; and output means, operating within said digital computer, for outputting an indication of said potentially fraudulent call activity based upon a result of the comparison performed by said comparison means.

23. A telecommunication fraud detection apparatus according to Claim 22, wherein the predetermined call destination comprises a suspect termination number.

24. A telecommunication fraud detection apparatus according to Claim 22, wherein the predetermined call destination comprises a suspect country code.

25. An apparatus for detecting potentially fraudulent telecommunication activity, comprising:
a digital computer;
interface means, operating within said digital computer, for receiving a call information record for each of at least two calls associated with a particular subscriber and derived from a switching center that establishes calls between telecommunication devices;
detection means, operating within said digital computer, for detecting an occurrence of overlapped calls using said call information record for each of said at least two calls, said detection of overlapped calls indicating that calls associated with said particular subscriber were placed in an improbable time sequence that is indicative of potentially fraudulent call activity; and output means, operating within said digital computer, for outputting an indication of overlapped calls based upon a result of the detection performed by said detection means.

26. A telecommunication fraud detection apparatus according to Claim 25, wherein said detection means detects an occurrence of overlapped calls that are substantially simultaneous calls.

27. A telecommunication fraud detection apparatus according to Claim 25, wherein said detection means detects an occurrence of overlapped calls after consideration of geographic dispersion related information derived from said call information record for each of said at least two calls.

28. A telecommunication fraud detection apparatus according to Claim 25, wherein said detection means further comprises adjusting means for adjusting information derived from at least one of said call information record to account for geographic dispersion between locations of said at least two calls.

29. A telecommunication fraud detection apparatus according to Claim 25, wherein said detection means comprises adjusting means for adjusting information derived from at least one of said call information record to account for geographic dispersion using an airline formula that provides an estimate of the distance between the locations at which said at least two calls are initiated.

30. An apparatus for detecting potentially fraudulent telecommunication activity, comprising:
a digital computer;
interface means, operating within said digital computer, for receiving a call information record for each call involving a particular subscriber;
parameter identifying means, operating within said digital computer, for identifying a parameter of the particular subscriber's current call usage based on information extracted from one or more call information records provided by said interface means;
pattern identifying means, operating within said digital computer, for identifying a subscriber-specific pattern of historical call usage based on information extracted from a plurality of said call information records;

analysis means, operating within said digital computer, for analyzing the particular subscriber's current call usage to identify potentially fraudulent call activity, said analyzing means generating data in the course of identifying potentially fraudulent activity and including means for comparing current call usage of the particular subscriber to one or more of the following: information relating to the subscriber-specific pattern of historical call usage identified by said pattern identifying means, a value of a call destination parameter identified in a call information record by said parameter identifying means, or values of a call location parameter identified by said parameter identifying means; and output means, operating within said digital computer, for outputting an indication of a potentially fraudulent call activity based upon a result of the analysis performed by said analysis means, and for displaying at least a portion of said data generated in the course of the analysis that identified said potentially fraudulent activity so an assessment thereof can be made.

31. A method for detecting potentially fraudulent telecommunication activity, comprising the steps of:
receiving a call information record for each call involving a particular subscriber;
identifying a parameter of the particular subscriber's current usage by extracting information from one or more call information records;
developing and maintaining a subscriber-specific historical call usage pattern by cumulatively processing information extracted from a plurality of call information records;
comparing the particular subscriber's current usage to the subscriber-specific historical call pattern to determine a deviation amount therebetween, the deviation amount being indicative of potentially fraudulent activity; and outputting an indication of a potentially fraudulent call when the deviation amount exceeds a predetermined limit.

32. A telecommunication fraud detection apparatus according to Claim 1, wherein said current call usage includes a first average of call usage, said information relating to said subscriber-specific pattern of historical call usage includes a second average of call usage, and said comparison means compares said first average of call usage to said second average of call usage.

33. A telecommunication fraud detection apparatus according to Claim 1, wherein said current call usage includes a first average of call usage over a first period of time, said information relating to said subscriber-specific pattern of historical call usage includes a second average of call usage over a second period of time that is different than said first predetermined period of time, and said comparison means compares said first average of call usage to said second average of call usage.

34. A telecommunication fraud detection apparatus according to Claim 1, wherein said current call usage includes a first average of call usage over a first period of time extending from a first starting point in time, said information relating to said subscriber-specific pattern of historical call usage includes a second average of call usage, said comparison means compares said first average of call usage to said second average of call usage to determine if said first average of call usage exceeds said second average of call usage and, if so, whether said first average exceeds a third average over a second period of time extending from a second starting point in time by a predetermined amount, wherein said first and second periods of time are substantially equal, but said first starting point in time is different than said second starting point in time.

35. A telecommunication fraud detection apparatus according to Claim 1, wherein said information relating to said subscriber-specific pattern of historical call usage includes information relating to a high of call usage, and said comparison means compares the particular subscriber s current call usage to said information relating to a high of call usage.

36. A telecommunication fraud detection apparatus according to Claim 1, wherein said information relating to said subscriber-specific pattern of historical call usage includes a threshold, said current call usage includes an average call usage over a period of time, and said comparison means compares said average call usage to said threshold.

37. A telecommunication fraud detection apparatus according to Claim 1, wherein said information relating to said subscriber-specific pattern of historical call usage includes information relating to a high of call usage, said current call usage includes an average call usage over a period of time, and said comparison means compares said average call usage to said information relating to a high of call usage.

38. A telecommunication fraud detection apparatus according to Claim 16 wherein said information displayed by said output means includes a plurality of graphs, each graph relating to the particular subscriber s call velocity over a particular period of time.

39. A telecommunication fraud detection apparatus according to Claim 16 wherein information displayed by said output means includes information relating to a group of subscribers within a defined geographical region that includes said particular subscriber.

40. An apparatus for detecting potentially fraudulent telecommunication activity, comprising:
a digital computer;
interface means, operating within said digital computer, for receiving a call information record for each call involving a particular subscriber, said call information record derived from a switching center that establishes connections between telecommunication devices;
analysis means, operating within said digital computer, for receiving said call information record from said interface means and using said call information record in analyzing the particular subscriber's call usage to identify potentially fraudulent call activity; and output means, operating within said digital computer, for outputting an indication of said potentially fraudulent call activity;
wherein said analysis means includes pattern means for using a plurality of said call information record for said particular subscriber to develop information relating to a subscriber-specific pattern of historical call usage, and means for comparing current call usage of the particular subscriber to said information relating to said subscriber-specific pattern of historical call usage, a result of which can identify potentially fraudulent call activity.

41. An apparatus, as claimed in Claim 40, wherein:
said analysis means includes pattern means for using a plurality of said call information record for said particular subscriber to develop information relating to a subscriber-specific pattern of historical call usage, and means for comparing current call usage of the particular subscriber to said information relating to said subscriber-specific pattern of historical call usage.

42. A telecommunication fraud detection apparatus according to Claim 41, wherein said current call usage includes a first average of call usage, said information relating to said subscriber-specific pattern of historical call usage includes a second average of call usage, and said comparison means compares said first average of call usage to said second average of call usage.

43. A telecommunication fraud detection apparatus according to Claim 41, wherein said current call usage includes a first average of call usage over a first period of time, said information relating to a subscriber-specific pattern of historical call usage includes a second average of call usage over a second period of time that is different than said first predetermined period of time, and said comparison means compares said first average of call usage to said second average of call usage.

44. A telecommunication fraud detection apparatus according to Claim 41, wherein said current call usage includes a first average of call usage over a first period of time that extends from a first starting point, said information relating to said subscriber-specific pattern of historical call usage includes a second average of call usage, and said comparison means compares said first average of call usage to said second average of call usage to determine if said first average of call usage exceeds said second average of call usage and, if so, whether said first average exceeds a third average of call usage that extends over a second period of time extending from a second starting point by a predetermined amount, wherein said first and second periods of time are substantially equal, but said first starting point in time is different from said second starting point in time.

45. A telecommunication fraud detection apparatus according to Claim 41, wherein said information relating to said subscriber-specific pattern of historical call usage includes information relating to a high of call usage, and said comparison means compares the particular subscriber's current call usage to said information relating to a high of call usage.

46. A telecommunication fraud detection apparatus according to Claim 41, wherein said information relating to said subscriber-specific pattern of historical call usage includes a threshold, said current call usage includes an average call usage over a period of time, and said comparison means compares said average call usage to said threshold.

47. A telecommunication fraud detection apparatus according to Claim 41, wherein said information relating to said subscriber-specific pattern of historical call usage includes information relating to a high of call usage, the current call usage includes an average call usage over a period of time, and said comparison means compares said average call usage to said information relating to a high of call usage.

48. An apparatus, as claimed in Claim 40, wherein:
said analysis means includes means for determining if two or more calls are one of the following: substantially simultaneously overlapped and overlapped after taking into account geographic dispersion.

49. An apparatus, as claimed in Claim 40, wherein:
said analysis means includes means for comparing call destination information from said call information record to a predetermined call destination information.

50. An apparatus, as claimed in Claim 40, wherein:
said analysis means includes means for determining if the particular subscriber has exceeded a credit limit for said particular subscriber.