Automated Fraud Management in Transaction-Based Networks

This invention relates generally to fraud management and, more specifically, to an automated approach for managing fraud in transaction-based networks, such as communication networks and the like.

Fraudulent use of communication networks is a problem of staggering proportions. Using telecommunications networks as an example, costs associated with fraud are estimated at billions of dollars a year and growing. Given the tremendous financial liability, the telecommunications industry continues to seek ways for reducing the occurrence of fraud while at the same time minimizing disruption of service to legitimate subscribers.

Although there are many forms of telecommunications fraud, two of the most prevalent types or categories of fraud in today's networks are theft-of-service fraud and subscription fraud. For example, theft-of-service fraud may involve the illegitimate use of calling cards, cellular phones, or telephone lines (e.g., PBX lines), while subscription fraud may occur when a perpetrator who never intends to pay for a service poses as a new customer. This latter type of fraud has been particularly difficult to detect and prevent because of the lack of any legitimate calling activity in the account that could otherwise be used as a basis for differentiating the fraudulent activity. In either case, losses attributable to these types of fraud are a significant problem.

Many companies boast of superior fraud management in their product offerings; however, the fact remains that a comprehensive fraud management system does not exist which addresses the operational and economic concerns of service providers and customers alike. For example, a common disadvantage of most systems is that detection of fraud occurs after a substantial amount of fraudulent activity has already occurred on an account. Moreover, many fraud prevention measures implemented in today's systems are quite disruptive to the legitimate customer. As a result, customer "churn" may result as customers change service providers in search of a more secure system.

In general, the shortcomings of prior systems are readily apparent in terms of the amount of time that is required to detect and respond to fraud. For example, fraud detection based on customer feedback from monthly bills is not an acceptable approach to either service providers or customers. Automated fraud detection systems based on "thresholding" techniques are also not particularly helpful in managing fraud on a real-time or near real-time basis. For example, thresholding typically involves aggregating traffic over time (e.g., days, weeks, months), establishing profiles for subscribers (e.g., calling patterns), and applying thresholds to identify fraud. These systems are not viewed as being particularly effective because legitimate users can generate usage that exceeds the thresholds and the amount of fraud that can occur prior to detection and prevention is high (see. e.g., U.S. Pat. No. 5,706,338, "Real-Time Communications Fraud Monitoring System" and U.S. Pat. No. 5,627,886, "System and Method for Detecting Fraudulent Network Usage Patterns Using Real-Time Network Monitoring").

Although speed in detecting fraud may be improved by using technologies such as neural networking, statistical analysis, memory-based reasoning, genetic algorithms, and other data mining techniques, improved fraud detection alone does not completely solve the problem. In particular, even though systems incorporating these techniques may receive and process individual call data on a near real-time basis in an attempt to detect fraud, these systems still do not respond to the detected fraud on a real-time or near real-time basis. In one example, a system may generate an alert to an investigator in a network monitoring or operations center. However, the alerts will generally not be examined or acted upon immediately, thereby resulting in a significant amount of latency in responding to the detected fraud. Because of the reactive nature of these systems in responding to detected fraud, a considerable amount of financial loss is still incurred by service providers and customers after the alert is generated. Furthermore, automated prevention based on inaccurate detection will result in the disruption of service to legitimate subscribers.

Fraud losses in a communications network are substantially reduced according to the principles of the invention by automatically generating fraud management recommendations in response to suspected fraud and by deriving the recommendations as a function of selected attributes of the fraudulent activity, legitimate activity, and subscriber background information. More specifically, a programmable rules engine is used to automatically generate recommendations for responding to fraud based on call-by-call scoring so that the recommendations correspond directly to the type and amount of suspected fraudulent activity. By automatically generating more precise fraud responses, fraud management according to the principles of the invention is much more effective in meeting operational, financial, and customer satisfaction requirements as compared to prior arrangements where a case may sit in a queue until a human investigator analyzes it and makes a determination on what action to take. Automated fraud management according to the principles of the invention results in significant cost savings both in terms of reduced fraud losses as well as less resources required for investigating suspected fraud. Moreover, investigation time is reduced thus improving response time to suspected fraud.

In one illustrative embodiment for managing telecommunications fraud, an automated fraud management system receives call detail records that have been scored to identify potentially fraudulent calls. Fraud scoring estimates the probability of fraud for each call based on the learned behavior of an individual subscriber and the learned behavior of fraud perpetrators. Importantly, scoring provides an indication of the contribution of various elements of the call detail record to the fraud score for that call. A case analysis is initiated and previously scored call detail records are separated into innocuous and suspicious groups based on fraud scores. Each group is then characterized according to selected variables and scoring for its member calls. These characterizations are combined with subscriber information to generate a set of decision variables. A set of rules is then applied to determine if the current set of decision variables meets definable conditions. When a condition is met, prevention measures associated with that condition are recommended for the account. As one example, recommended prevention measures may be implemented automatically via provisioning functions in the telecommunications network.

According to another aspect of the invention, automated fraud management based on call-by-call scoring facilitates a continuous updating feature. For example, active cases can be re-evaluated as new calls are scored and added to a case. Moreover, a case may be updated as new recommendations are generated.

A more complete understanding of the present invention may be obtained from consideration of the following detailed description of the invention in conjunction with the drawing, with like elements referenced with like reference numerals, in which:

FIG. 1 is a simplified block diagram illustrating one embodiment of the invention for managing fraud in a telecommunications network;

FIG. 2 is an exemplary listing of subscriber information that can be used according to the principles of the invention;

FIG. 3 is a simplified block diagram illustrating how call scoring is implemented according to one embodiment of the invention;

FIG. 4 is a simplified flowchart of the case analysis process according to one illustrative embodiment of the invention;

FIG. 5A is a simplified block diagram illustrating the step of summarizing case detail according to the embodiment shown in FIG. 4;

FIG. 5B is an exemplary listing of scored call variables that can be used according to the principles of the invention;

FIG. 6 is an exemplary listing of decision variables that can be used according to the principles of the invention;

FIG. 7 is a simplified flowchart of the process for generating recommendations for responding to suspected fraudulent activity according to one illustrative embodiment of the invention; and

FIG. 8 is an exemplary listing of prevention measures that can be implemented according to the principles of the invention.

Although the illustrative embodiments described herein are particularly well-suited for managing fraud in a telecommunications network, and shall be described in this exemplary context, those skilled in the art will understand from the teachings herein that the principles of the invention may also be employed in other non-telecommunications transaction-based networks. For example, the principles of the invention may be applied in networks that support on-line credit card transactions, internet-based transactions, and the like. Consequently, references to "calls" and "call detail records" in a telecommunications example could be equated with "transactions" and "transaction records", respectively, in a non-telecommunications example, and so on. Accordingly, the embodiments shown and described herein are only meant to be illustrative and not limiting.

FIG. 1 shows one illustrative embodiment of the invention for managing fraud in a typical telecommunications network. More specifically, system 100 is configured to perform various functions and operations to respond to suspected fraudulent activity in telecommunications network 150. As shown, system 100 comprises call scoring function 120, case analysis function 200, and provisioning function 300. To enable these functions, system 100 stores data including, but not limited to, scored call details 401, stored cases 402, and subscriber account information 403. It will be appreciated that system 100 can be implemented in one illustrative embodiment using computer hardware and software programmed to carry out these functions and operations, each of which is described below in further detail.

As is well known, a telecommunications network such as network 150 generates call detail records for each call processed within the network. According to the principles of the invention, these call detail records are supplied via path 151 to call scoring function 120 within system 100 so that each call can be scored to determine the likelihood of fraud for that particular call. The resultant scored call details are stored as shown in block 401 for later use and are also forwarded to case analysis function 200 for processing. As used herein, the term "case" is meant to represent a potential fraud case that may be developing on a billed account, an originating line/equipment account, a terminating line/equipment account for the call, and the like.

As shown, case analysis function 200 receives scored call details as well as subscriber account information (block 403), examples of which could include the type of account (business, residential), customer's credit rating, customer's credit limit, past billing treatment indicators, date the account was established, and so on. As a result of case analysis, case details are stored as shown in block 402. Additionally, recommendations are automatically generated for responding to suspected fraud on an account. These recommended fraud responses may, for example, include specific prevention measures that correspond to the type and amount of suspected fraudulent activity. As shown in the example of FIG. 1, recommended fraud responses resulting from case analysis function 200 may include responses that can be implemented via provisioning function 300, which is coupled to network 150 via path 152. Well known techniques may be used for provisioning network 150 to respond in a particular way to a particular activity on a call, e.g., block the call, disable call forwarding for this account, and so on.

FIG. 1 further illustrates the iterative and adaptive aspects of the invention with respect to call scoring and case analysis. More specifically, an already active case (e.g., stored in block 402) can be re-evaluated as new calls are scored and added to the case. A case may also be updated as new recommendations are generated as a result of case analysis. For example, call detail records are continually being supplied via path 151 to call scoring function 120. Newly scored calls can then be provided to case analysis function 200 along with previously scored calls stored as shown in block 401. Again, case analysis function 200 analyzes the scored call data in combination with subscriber information (block 403). The table in FIG. 2 shows a listing of some examples of subscriber account information that may be used in case analysis. However, these examples are meant to be illustrative only and not limiting in any way.

Returning to FIG. 1, case analysis function 200 may also retrieve an active case (e.g., previously stored in block 402) for further analysis in view of newly scored calls as well as subscriber information (block 403). New recommendations generated by case analysis function 200 may also be added to the already active case. As shown, provisioning measures (block 300) may be implemented as a result of new recommendations generated by case analysis function 200 or as a result of previously generated recommendations associated with a previously stored case (block 402). In this way, automated fraud management according to the principles of the invention allows for continuous updating.

Referring to FIG. 3, a more detailed description is now provided for call scoring function 120 from FIG. 1. As previously described, call scoring function 120 supplies fraud score information for calls made in telecommunications network 150 so that appropriate recommendations can be generated for responding to suspected fraudulent activity.

More specifically, call scoring function 120 can be implemented as further illustrated in the exemplary embodiment shown in FIG. 3. In general, scoring is based on subscriber behavior analysis wherein a signature (stored in block 1202) representative of a subscriber's calling pattern and a fraud signature (stored in block 1211) representative of a fraudulent calling pattern are used to determine the likelihood of fraud on a particular call. Scored call information is then stored (block 401) for later retrieval and use in the iterative and continuous updating process as well as forwarded for case analysis (200) as will be described below in more detail.

As shown, call detail records are supplied from network 150 to call scoring function 120. A subscriber's signature may be initialized as shown in block 1201 using scored call detail records from calls that have not been confirmed or suspected as fraudulent. Initialization may occur, for example, when a subscriber initially places one or more calls. As further shown in block 1201, stored subscriber signatures from block 1202 can then be updated using newly scored call detail records from subsequent calls that are not confirmed or suspected as fraudulent. As such, a subscriber's signature can adapt to the subscriber's behavior over time.

It should be noted that initialization of a subscriber's signature can also be based on predefined attributes of legitimate calling behavior which may be defined by historical call records and the like. In this way, subscription fraud can be detected more readily because a legitimate subscriber's signature, even at the very early stages of calling activity, can be correlated with the expected (or predicted) behavior of legitimate callers. As such, any immediate fraudulent calling behavior on a new account, for example, will not provide the sole basis for initializing the subscriber signature.

It should also be noted that a subscriber signature may monitor many aspects of a subscriber's calling behavior including, but not limited to: calling rate, day of week timing, hour of day timing, call duration, method of billing, geography, and so on. Consequently, a signature may be derived from information that is typically contained within the call detail records, such as: originating number; terminating number; billed number; start time and date; originating location; carrier selection; call waiting indicators; call forwarding indicators; three-way calling/transfer indicators; operator assistance requests; and network security failure indicators, to name a few. The particular elements to be used for establishing and updating a subscriber signature may depend on the type of network (e.g., wireline, wireless, calling card, non-telecommunications, etc.), the particular scoring method being used, as well as other factors that would be apparent to those skilled in the art.

Generally, each call will be scored depending on how the call compares to the subscriber's signature retrieved from block 1202 and how it compares to a fraud signature retrieved from block 1211. By way of example, fraud signatures can be initialized and updated (block 1210) using scored call detail records from confirmed or suspected fraudulent calls. In a simplified example, a high fraud score is generated if the call details represent a suspicious deviation from known behavior and a low fraud score is generated if the call details represent highly typical behavior for the subscriber account in question. In addition to providing an overall fraud score as output from call scoring function 120, the relative contributions of various elements of the call to the fraud score should also be included, the use of which will be described in more detail below relating to case analysis. For example, contributions of the following elements may be included for subsequent case analysis: day of week; time of day; duration; time between consecutive calls; destination; use of call waiting; use of call forwarding; use of three-way calling; use of operator services; origination point; use of roaming services (wireless only); number of handoffs during call (wireless only); appearance of network security alert; carrier selection; and use of international completion services. Again, this listing is meant to be illustrative only and not limiting in any way.

Because call scoring is carried out on a customer-specific and call-by-call basis, a more precise fraud score can be obtained that is more indicative of the likelihood of fraud while reducing the amount of false alarms (i.e., "false positives"). Furthermore, to accurately perform call scoring on a call-by-call basis, those skilled in the art will recognize that one suitable implementation would be to execute the above-described functions using a real-time processing platform. One such exemplary real-time processing platform is Lucent Technologies' QTM.TM. real-time transaction processing platform, which is described in an article by J. Baulier et al., "Sunrise: A Real-Time Event-Processing Framework", Bell Labs Technical Journal, Nov. 24, 1997, and which is herein incorporated by reference.

It will be apparent to those skilled in the art that many different call scoring techniques may be suitable for implementing the functionality of call scoring function 120 as described above. In particular, call scoring techniques based on statistical analysis, probabilistic scoring, memory-based reasoning, data mining, neural networking, and other methodologies are known and are contemplated for use in conjunction with the illustrative embodiments of the invention described herein. Some examples of these methods and techniques are described in Fawcett et al., "Adaptive Fraud Detection", Data Mining and Knowledge Discovery 1, 291-316 (1997) and U.S. Pat. No. 5,819,226, "Fraud Detection Using Predictive Modeling", issued Oct. 6, 1998, each of which is herein incorporated by reference.

FIG. 4 shows one illustrative embodiment of case analysis function 200 from FIG. 1. As shown in step 201, details associated with a previously scored call are reviewed to determine whether the call warrants the opening of a new fraud case or addition of the call to an existing case. In particular, the fraud score generated by call scoring function 120 for a particular call and other predetermined variables, such as contributions of specific elements to the fraud score, are reviewed to determine whether the call is "interesting" from a fraud perspective. A call may be "interesting" for any number of different reasons including, but not limited to: a fraud score that exceeds a predetermined (e.g., configurable) value; a fraud score that indicates the culmination of a change in score of a prescribed amount over a prescribed number of calls; an indication of an overlap in time with a previous call (i.e., a "collision"); an indication of a change in origination point between two calls that is impossible for one subscriber to make given the time between those calls (i.e., a "velocity violation"); or being a member of an existing case.

If a scored call record is determined to be interesting, a check is made in step 202 to see if there is an existing case on the related account. If no case is found, a new case is created by: 1) retrieving, in step 203, background information on the subscriber account which is stored in the system (see block 403 in FIG. 1); 2) retrieving scored call detail for the account in step 204; and 3) summarizing the scored call detail in step 205. In order to summarize the scored detail in step 205, the call detail records must first be categorized and then each category must be characterized according to predetermined variables. As shown in FIG. 5A, call detail records are first categorized into a plurality of groups or sets, e.g., SET.sub.1, SET.sub.2 through SET.sub.N, which can be classified, for example, as innocuous, suspicious and indeterminate sets. Initial categorization is based on fraud scores, wherein each call detail record is placed into one of the sets based on its fraud score as compared to established values or thresholds defining the categories. Automatic adjustments to this categorization can be made by considering other factors, such as originating location and dialed number to name a few. For example, if a strong majority of call detail records in the innocuous set contain a given highly typical originating location or dialed number, then one possible adjustment is to move all call records having the same attributes in the other sets to the innocuous set. The sets are then characterized by tabulating call summary variables within each set. In particular, a number of call summary variables may be derived for the case and also for individual sets (e.g., innocuous, suspicious, indeterminate) within a case. The table in FIG. 5B shows one exemplary list of call summary variables that may be useful for case analysis. As shown, variables 410 ("FirstAlertAt" and "CaseScore") represent variables that pertain to the entire case. For example, The "FirstAlertAt" would be used to provide a time when the first high scoring call (e.g., suspected fraud) occurs for that case, regardless of the particular category the call is initially placed in. "CaseScore" may be used to provide an overall case score for the case based on the individual call scores within the case, again regardless of particular category within the case.

The remaining variables shown in FIG. 5B are applicable, in this illustrative example, to a particular set within the case, e.g., the innocuous, suspicious, and indeterminate sets. The explanations for each call summary variable are provided in the description field of the table. As shown, the set-dependent call summary variables can be characterized into two types of variables. The first grouping of call summary variables 420, starting with "Number of Calls" through "Hot Number Count", all address a summing type operation in which a count or percentage is maintained for a particular element of the call. Using call summary variable 421 ("Hot Number Count") as an example, this value would represent the total number of calls within a given set in which the called number is a member of a predetermined (and selectable, editable, etc.) "Hot Number" list. Those skilled in the art will readily understand the significance and use of "hot numbers".

The remaining call summary variables 430, starting with "Day Score Dist" through "International Score Dist", all address the contribution distribution of a specific element or elements to the fraud score within that set. For example, call summary variable 431 ("Hour Score Dist") represents how the "hour of the day" in which calls in the set were placed influenced or contributed to the fraud score. It should be noted that the call summary variables listed in the table in FIG. 5B are only meant to be illustrative and not limiting in any way. Other call summary variables may be selected to characterize a set, depending on several factors such as network type, transaction type, and so on.

Referring again to FIG. 4, if an existing case is found in step 202, then the case is subsequently retrieved in step 206 and the summary of the case, e.g., call summary variables from FIG. 5B, are updated with information from the current call. Based on either a newly created summary (steps 203-205) or an updated summary (steps 206-207), the system calculates a set of decision variables as shown in step 208. More specifically, decision variables are used in the determination of whether certain conditions have been met, thereby providing the basis for generating recommendations for responding to suspected fraudulent activity in the network. The table in FIG. 6 shows one exemplary list of decision variables that may be useful for case analysis according to the principles of the invention.

As shown in FIG. 6, decision variable 440 is described as being any of the call summary variables from FIG. 5B or any manipulation of one or more of the call summary variables, such as by ratios, mathematical operations, and so on. For example, any of call summary variables 410, 420, or 430 may individually constitute a decision variable for determining an appropriate recommendation for responding to fraud. Another example of a suitable decision variable could be the combination of two or more of the call summary variables in some predetermined manner, e.g., a ratio of the number of calls in which call forwarding was applied ("CF Count") to the total number of calls in the set ("Number of Calls"). The selection of applicable decision variables may again be dependent on the type of network, type of transactions, as well as other factors determined to be applicable. Additional decision variables 450 can also be used to provide additional information that may be helpful in analyzing fraudulent activity to determine appropriate recommendations. For example, "AccountAge", "PreviousFalseAlarms", "AccountType", "CreditRating", and "AlertCounts", each of which is described in the table shown in FIG. 6, may be used. It should be noted that the decision variables listed in the table in FIG. 6 are only meant to be illustrative and not limiting in any way. Other decision variables will be apparent to those skilled in the art given the particular network type, transaction characteristics, and so on.

Referring again to FIG. 4, the system then generates, in step 209, one or more recommendations for responding to fraud that may be occurring on an account. FIG. 7 shows one exemplary embodiment of the steps involved in generating recommendations according to the principles of the invention.

A brief overview of the terminology will be helpful to understanding the steps shown in FIG. 7. As described herein, a rule is defined as including a "condition" and a list of one or more "measures". A "condition" can be a Boolean expression that supports comparisons among decision variables (defined in FIG. 6) and predetermined values or constants. In one of its simplest forms, the Boolean expression may use standard Boolean operators, such as AND, OR, NOT, as well as precedence. A single "measure" identifies an action (e.g., block services or block market), parameters associated with the action (e.g., call forwarding for the block services example, or Market 25 for the block market example), as well as a flag as to whether the measure should be carried out automatically. Generally, rules can be modified by the system user (e.g., service provider) depending on given fraud management requirements for the network.

Referring to step 2091 in FIG. 6, the system retrieves a list of rules, and processes each rule according to a hierarchy that may be simple, such as first to last, or by some predefined schema. The condition for that rule (e.g., CFcount/numcallsinset>0.25) is then tested using the applicable decision variables (FIG. 6) specified for that condition. This is depicted in step 2092. If the rule's condition is met, a measure associated with the particular rule is then retrieved in step 2093. As shown in step 2094, if there has been no prior rule which calls for the same action (e.g., Block Services) as that identified in the retrieved measure (from step 2093), then the retrieved measure is added to the list of desired measures in step 2095. If the action has already been required by a previous rule, then the measure is ignored. In this way, precedence is established among rules in the case of conflicting directives. The next step is to determine whether there are more measures associated with the rule as shown in step 2096. If so, then steps 2093-2095 are repeated for all measures in the rule. If there are no other measures associated with the particular rule (retrieved in step 2091), then the system checks for other applicable rules in step 2097. If there are additional rules, then the process described above in steps 2091-2096 is repeated. Once there are no more applicable rules, then the system returns to step 210 in FIG. 4.

Referring again to step 2092, if the rule's condition is not met, then the system examines whether there are more rules in step 2097 and, if so, then the process starts all over again with step 2091. If there are no more rules, then the actions associated with step 210 and subsequent steps in FIG. 4 are processed as described below.

As a result of the processing that takes place in the steps illustrated in FIG. 7, one or more recommended measures are automatically generated to respond to suspected fraud. Examples of some actions found in recommended measures are shown in FIG. 8. For example, a recommended measure may be to block all account activity (where the action is "Block Account"), or to block only international dialing (where the action is "Block Dialing" and the associated parameter is "international"), or to block a particular type of service, e.g., call forwarding. It should be noted that this list of recommended actions in FIG. 8 is only meant to be illustrative and not limiting in any way.

It is important to note that the appropriate recommendation can be automatically generated as a function of call-by-call scoring, application of appropriate rules based on the scoring, selection of appropriate call summary variables and decision variables, and so on. As such, the automatically generated recommendations correspond to the call-by-call scoring process such that the recommendations are more precisely targeted to the specific type of fraud that is occurring on the account. For example, most fraud detection and prevention systems are only able to detect the presence of fraud, and only with varying levels of accuracy. Once fraud is detected, these systems typically refer the case for manual investigation. Prevention measures, if they exist at all, are not at all tailored to the type of suspected fraud. By contrast, the fraud management system according to the principles of the invention not only detects fraud but also collects information about the particular characteristics of that fraud. As a result, the recommended fraud responses are tailored to the specific type of fraud that is occurring.

As an example, if case analysis determines that the most significant contribution to a high fraud score is related to the use of call forwarding, then an appropriate recommended fraud response can be to shut down the call forwarding service on that account instead of shutting down all service on that account. In this way, fraud losses can be minimized or eliminated while maintaining service to the legitimate subscriber. Moreover, a recommendation to disable call forwarding may be carried out automatically using provisioning features within the network.

Returning to FIG. 4, the recommendation or recommendations generated in step 209 are compared, in step 210, to recommendations that were previously given for the case. If the recommendations generated from step 209 are not new, then the call analysis process ends for that particular call. If the recommendations are new, then the case is updated with the new recommendations in step 211. If any of the new recommendations are of the type to be carried out automatically as determined in step 212, then appropriate implementation actions can be taken accordingly. For example, recommended actions can be implemented automatically via provisioning function 300 (FIG. 1) in the telecommunications network as previously described.

In sum, the automatic generation of recommendations according to the principles of the invention is predicated on a programmable rules-based engine (e.g., rules can be reprogrammed). Additionally, it is important to remember that the process steps described above in the context of FIGS. 1-8 can all be carried out on a call-by-call basis in the network. Consequently, the rule-based engine is an adaptive system that is used to develop a history of cases, decision criteria and final outcomes on a call-by-call basis in the network. As such, the fraud management system and method according to the principles of the invention provides service providers with a fraud management system which goes well beyond detection that can be customized according to user-defined policies, subscriber behaviors, and the like.

As described herein, the present invention can be embodied in the form of methods and apparatuses for practicing those methods. The invention can also be embodied in the form of program code embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The present invention can also be embodied in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits.

It should also be noted that the foregoing merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples and conditional language recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

The functions of the various elements shown in the drawing may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, a "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor ASP) hardware, read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the drawing are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementor as more specifically understood from the context.

In the claims hereof any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements which performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The invention as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. Applicants thus regard any means which can provide those functionalities as equivalent to those shown herein.