CLASSIFICATION OF FALSE ALARMS IN A SECURITY SYSTEM

BACKGROUND OF THE INVENTION

The present invention relates to the field of security systems. In particular, the present invention relates to classification of false alarms in an intrusion security system.

An intrusion security system detects specific events at a building or asset, typically with individual sensors that respond to security or safety breaches. When a sensor is triggered, an alarm signal is sent to a call center where the data is logged and an operator is informed. The operator then either determines that the alarm is a false alarm (i.e., caused by something other than an intruder, fire, flood, or monitored machinery failure), or calls an appropriate agency (such as a guard or the police) to verify and/or resolve the problem. A false alarm occurs when a security system detects alarm status erroneously as a result of events such as user error, environmental triggering of sensors, or equipment failure. A false dispatch occurs when the call center, after being unable to verify the cause of an alarm by calling the premises or a property contact person, notifies a responding authority that visits the premises and finds no evidence of a threat to the premises.

False alarms and false dispatches introduce significant overhead into the security business. In addition, false dispatches compromise the level of security provided to the end user of the security system, since resources that could be dedicated to responding to legitimate alarms must instead be used in responding to the false alarms. However, security companies do not have the ability to automatically diagnose or classify causes of false alarms based on past data of the security system. Rather, false alarm causes are determined either through a manual review of the past data, or by dispatching a service technician to the security system site to determine potential causes of the false alarms. Because both of

these approaches are labor-intensive, false alarms and false dispatches continue to be burdensome for call centers and responding authorities.

BRIEF SUMMARY OF THE INVENTION

The subject invention is directed to classification of false alarm incidents in an intrusion security system. Alarm activity data related to alarm activity in the intrusion security system is parsed into alarm incident data blocks. A false alarm class label is assigned to the analyzed incident based on features extracted from each alarm incident data block. Each false alarm class corresponds to a pre-identified false alarm scenario, characterized by certain values or ranges of values for each feature. The scenarios and their characteristics are stored in a false alarm scenario database.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of a system for diagnosing false alarm causes in intrusion security systems according to the present invention.

FIG. 2 is a flow diagram for a process of diagnosing false alarm causes from security system alarm activity data according to the present invention.

DETAILED DESCRIPTION FIG. 1 is a block diagram of a system 10 for classifying false alarms by cause in intrusion security systems according to the present invention. System 10 includes output device 12, false alarm classification device 14, and security system activity database 16. False alarm classification device 14 includes sequencing module 20 comprising data preprocessing application 22 and incident parsing application 24. False alarm classification device 14 also includes classification report generator 26, alarm incident classification module 28, and false alarm scenario database 30. In one embodiment, false alarm classification device 14 is a microprocessor based device and sequencing module 20, classification report generator 26, and alarm incident classification module 28 are computer programs or applications executed by false alarm classification device 14.

Security system activity database 16 receives information related to security system activity from a site and stores this information on a storage medium such as a hard drive. Security system activity database 16 provides an output to sequencing module 20, which is processed by data preprocessing application 22 and incident parsing application 24.

Sequencing module 20 provides an output to alarm incident classification module 28, which also receives an input from false alarm scenario database 30. False alarm scenario database 30 stores information on a storage medium (such as a hard drive) that is related to false alarm signatures that are data representations of various types of false alarms.

Alarm incident classification module 28 processes information from sequencing module 20 and false alarm scenario database 30 and provides an output to classification report generator 26. Classification report generator 26 provides an output to output device 12. Output device 12 may be any device capable of providing information from classification report generator 26 in a viewable format, such as an electronic display or a printer.

System 10 is used to diagnose or classify false alarm incidents in an intrusion security system. FIG. 2 is a flow diagram for a process of classifying false alarm causes from security system alarm activity data according to the present invention. Security system activity database 16 receives and stores information related to all activity and site information from monitored security system sites, including alarm activity, security system operator activity, account information for security system sites, and security system setup information (step 40).

When data is received from security system sites, some of the data that is stored in security system activity database 16 is unnecessary for classifying false alarm incidents. Data preprocessing application 22 removes all unnecessary data prior to analysis to reduce the computational burden on false alarm classification device 14. In particular, data preprocessing application 22 extracts alarm event information from the raw security system activity data in security system

activity database 16 (step 42). Data preprocessing application 22 accomplishes this by only passing information to incident parsing application 24 that is related to alarm events in active security system accounts, while filtering out information irrelevant to alarm events, such as records related to test security systems, training information, account administration activity, and the like.

The alarm event information that is received by incident parsing application 24 from data preprocessing application 22 is completely unstructured. The alarm event information is a collection of data of different types (e.g., alarm signals, security system operator actions, etc.) for different accounts in the temporal order that the data was received by security system activity database 16. Incident parsing application 24 organizes the alarm event information into alarm incident blocks (step 44). Each alarm incident block is a sequence of events that starts with an event that requires a response by the security system operator (e.g., an alarm signal transmitted by the security system site control panel) and ends with an action or sequence of actions by the security system operator that indicates that the incident has been finalized. Incident parsing application 24 thus finds all beginning and end events (for example, based on event codes associated with each type of event) and assigns all intermediate events (defined by the time received by security system activity database 16) to the same alarm incident block. Incident parsing application 24 also organizes the alarm incident blocks by security system site account so that the alarm incident blocks for a particular account may be analyzed.

The alarm incident blocks may then be classified by the type of event that represents the start of the incident. More specifically, each event is classified at a high level by an event code that is related to the nature of the event. These event codes may represent events at the security system site such as burglary, failure to close at an expected time, failure to open at an expected time, fire, duress, medical emergency, communication failure with the call center, tampering with the control

panel, and administrative events. This high level classification of the alarm incident blocks allows for diagnosis of some alarm events that have a readily discernable cause or are not easily diagnosed from the available data. These alarm events include failure to open at an expected time, fire, duress, medical emergency, communication failure with the call center, tampering with the control panel, and administrative events. For example, duress false alarms are most often produced by erroneously pressing a panic or duress button at the site. As another example, communication failure or tampering with the control panel alarm events typically occur due to an equipment malfunction or weather occurrences for which the cause cannot easily be inferred from the alarm incident block data. :

The remaining alarm incident blocks relating to burglary and failure to close events have several potential causes. These alarm incidents occur pursuant to scenarios that can be described through attributes or variables that are computable from the data available in the alarm incident blocks and the site activity history. These alarm incident blocks are classified or diagnosed by comparing them with false alarm scenarios stored in false alarm scenario database 30 (step 46). A discrete choice model is used for each alarm incident block to estimate the probability that the alarm incident block matches one of the false alarm signatures. In one embodiment, the discrete choice model is a multinomial logit random utility model. In essence, alarm incident classification module 28 employs a pattern matching algorithm to classify each alarm incident block by cause.

The false alarm scenarios defined in false alarm scenario database 30 are most common in burglary and failure to close alarm incidents, are detailed enough to pinpoint a basic cause for the alarm, and can be characterized by attributes that are computable from the security system data. The scenarios for a given customer account also depend on the amount of information in the available data for different types of security system accounts. For example, security system accounts can be set to

transmit or not transmit arming and disarming signals to the call center when a user arms or disarms the security system, respectively. For security system accounts that send arming and disarming signals to the call center, the following scenarios may be included in false alarm scenario database 30:

(1) Exceeded entrance delay: User takes too long to disarm the system after entering an armed site

(2) Movement in armed site before disarming: User enters the armed site and moves around before attempting to disarm the system

(3) Disarming disregarded: User enters armed site and disregards the disarming process completely

(4) Exceeded exit delay: User takes too long to exit after arming the system

(5) Movement in armed site after arming: User arms the system and remains inside the site; other people are left behind in the armed site

(6) Failure to close: User fails to arm the system before expiration of an arming time window after an expected time of closing

(7) Failure to close after disarming: User arms and then disarms the system within the arming time window

(8) Third party failure to close: Third parties (e.g., automatic teller machine attendants, cleaners, etc.) disarm the system but remain inside the site for a longer time than allowed

(9) Environmental or faulty equipment: An alarm is produced by non-human causes

(10) Other: Alarm produced by an unknown cause.

For security system accounts that do not send arming and disarming signals to the call center, the following scenarios may be included in false alarm scenario database 30:

(1 ) User error: User error in arming or disarming

(2) Environmental or faulty equipment: An alarm is produced by non-human causes (3) Other: Alarm produced by an unknown cause.

In the discrete choice modeling framework of alarm incident classification module 28, the scenarios listed above represent a choice set. In order to model this choice set, explanatory variables that characterize the scenarios are selected. The explanatory variables for the false alarm scenarios may be represented as a set {x _n ,n = l,...,N} . For security system accounts that send arming and disarming signals, the following are examples of explanatory variables that are characteristic of each of the scenarios (1)-(10) above:

(a) IntervalArmDisarm: The time interval between the arming and the disarming of the security system prior to the start of an alarm incident

(b) QuickDisarm: The time interval between the start of the alarm incident and the disarming of the system after the start of the alarm incident

(c) RecentArm: The time interval between the arming of the security system immediately prior to the start of the alarm incident and the start of the alarm incident (d) DiffSensors: The total number of different sensors triggered during the alarm incident.

(e) NumSensorsDay. The total number of sensors triggered in the past day at the security system site

(f) StartDoor. The alarm incident starts with a burglary alarm triggered by a door contact

(g) StartNoDoor. The alarm incident starts with a burglary alarm not triggered by a door contact

(h) StartFC: The alarm incident starts with a failure to close alarm (i) SAFIag: "See account" event code - indicates the presence of alarm activity in adjacent security system subsites, the cause of which may be determined from other security system activity for the account (j) APFIag: "Answer at premise" event code - indicates that someone at the site responded to a communication from the call center.

For accounts that do not send arming and disarming signals, the following are example, explanatory variables that are characteristic of each of the scenarios (1 )-(3) above:

(a) DiffSensors: The total number of different sensors triggered during the alarm incident.

(b) NumSensorsDay. The total number of sensors triggered in the past day at the security system site

(c) StartDoor. The alarm incident starts with a burglary alarm triggered by a door contact

(d) StartNoDoor. The alarm incident starts with a burglary alarm not triggered by a door contact

(e) CancelFlag: "Cancel" event code - a user at the security system site canceled the alarm (f) Cancel Interval: The time interval between the beginning of the alarm incident and the cancellation of the alarm

(g) APFIag: "Answer at premise" event code - indicates that someone at the site responded tσa communication from the call center.

With the above variables, the false alarm scenarios in false alarm scenario database 30 are mapped into false alarm signatures. In the false alarm signatures, a value or range of values for each of the variables

is used to characterize each false alarm scenario. The value or range of values for each variable assigned in the false alarm signature is the expected value or range of values for the false alarm type represented by the false alarm scenario. Let J represent the number of false alarm scenarios, wherein the Jth scenario always corresponds to the "other" scenario having an unknown cause, while scenarios 1, 2,..., J-1 correspond to the scenarios with known, pre-defined causes. Thus, a set of J false alarm signatures for the above given set of explanatory variables may be represented as SFA = {x _j = [χ _β , x _J2 ,..., x _jN IJ = 1,..., J} (Equation 1 ).

Each alarm incident block provided by incident parsing application

24 to alarm incident classification module 28 may also be characterized by the same explanatory variables as set forth above. Thus, the values of explanatory variables characterizing the zth alarm incident block is given by

X ₁ = [>,j _{n=1 N} (Equation 2).

Next, each alarm incident block is compared to the false alarm signatures to determine the false alarm signature that most closely matches the alarm incident block. This is accomplished by estimating the likelihood that the alarm incident block matches one of the false alarm signatures. Thus, the probability that alarm incident block x. matches one of the false alarm signatures is given by

P ₁ U) = P(M(X _n X _j )) (Equation 3) where M is the pattern matching method. Thus, the probability that alarm incident block X ₁ matches one of the false alarm signatures is determined by matching patterns in alarm incident block x. with each of the false alarm signatures. In one embodiment, the pattern matching method is a multinomial logit formulation. For this type of formulation, the probability P ₁ U) for / = 1 , 2, ..., J-1 is given by:

*(/>- jff f'* (Equations

and P ₁ (J) is given by:

J-X

W) = 1-∑W) (Equation s) where ,λT = [1,JC _π ,λγ _/29 ...,λγ _W ] is a matrix of the explanatory variables that characterize alarm incident block i and β = [β _nj ] _{n=la w+} i _;y =i _,2 j-i ^are rnodel parameters determined during model calibration. The values of model parameters β are estimated through log-likelihood maximization on a calibration dataset containing manually labeled alarm incident blocks. The log-likelihood function is given by:

/ J-I LL(β) = ∑∑y _g 1Og(P ₁ U)) (Equation 6)

1=1 7=1 where j/y = 1 when alarm incident block i matches false alarm signature j and yi _j = 0 when the alarm incident block i does not match false alarm signature/.

With the estimated model parameters, each new alarm incident block is assigned a false alarm class label corresponding to the highest matching probability as determined from Equations 4 and 5. Thus, for each incident i in the set of J false alarm scenarios (where the Jth scenario corresponds to the "other" scenario having an unknown cause), the false alarm class label assigned to each incident i is given by: C ₁ = argmax{/?(/) : j = l,2,...,J,max _y P ₁ (J) > τ\ (Equation 7) and

C ₁ . = J,max _y P ₁ (j) < T (Equation 8) where T is a threshold probability (e.g., near zero).

When each of the alarm incident blocks for a security system site has been classified, a false alarm classification report is generated (step

48). The false alarm classification report provides a list of all alarm

incidents for the site and the associated probable cause assigned to the alarm incident. This classification report, which may be customized based on specific interests of the recipient, may be provided in the form of an onscreen display of the report, or in the form of a printed report. The false alarm classification report may then be used by call centers to determine high false alarm activity accounts and to implement false alarm reduction solutions. The false alarm classification report may also be used by security system users to become aware of false alarm activity at the security system site and potentially eliminate patterns of behavior that cause the alarm activity.

In summary, the present invention is directed to classifying false alarm events in an intrusion security system. Alarm activity data related to alarm activity in the intrusion security system is parsed into alarm incident data blocks. Characteristics of each alarm incident data block are then compared with like characteristics of stored false alarm signatures. Each stored false alarm signature is representative of a false alarm scenario. A false alarm label is then assigned to each alarm incident data block based on a classification algorithm. When the false alarm events have been classified, they may be organized into a false alarm classification report for the intrusion security system. Call centers and alarm system companies may use this report to determine sites with high false alarm activity and implement false alarm reduction solutions at those sites. In addition, a user of the intrusion security system may use the report to potentially eliminate patterns of behavior that generate false alarm activity.

Although the present invention has been described with reference to examples and preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention.