WO2008026210A2

WO2008026210A2 - System and method for security analysis

Info

Publication number: WO2008026210A2
Application number: PCT/IL2007/001068
Authority: WO
Inventors: Arie Moran; Daniel Medicks; David Kupperman; Gil Shavit
Original assignee: Tadsec Advanced Homeland Security Technologies Ltd
Priority date: 2006-08-29
Filing date: 2007-08-28
Publication date: 2008-03-06
Also published as: IL177767A0; WO2008026210A3

Abstract

A system and method for organization of security-related data in order to at least assist in the determination of the relative priority of such data. The system and method preferably assist the human operator to determine the relative priority of such data and more preferably receive feedback from a human operator for adjusting such a priority determination. The data is provided from at least one type of sensor but preferably is provided from a plurality of different types of sensors. Optionally and preferably, data is displayed or otherwise provided to the human operator without reducing the total amount of data available for display and/or for being provided.

Description

SYSTEM AND METHOD FOR SECURITY ANALYSIS

FIELD OF THE INVENTION

The present invention relates to a system and a method for security analysis and management, and in particular, to such a system and method which provide knowledge management and organization of security-related data in order to assist a human operator in analysis of such data.

BACKGROUND OF THE INVENTION Security is important, particularly in the current age of increased terrorism and international criminal activity. However, achieving a secure environment with minimal invasion of privacy and disruption of daily activities is increasingly difficult. More types of data are being collected, using newer types of sensors and/or increased deployment of sensors for collecting such data. Such sensors may be able to collect data with minimum invasion of privacy and disruption of daily activities. Paradoxically, newer security systems which provide large amounts of additional data have the effect of flooding the human operator with information, thereby increasing the difficulty for such operators to determine which data is relevant. Currently available security technologies do not address this particular problem. Some technologies attempt to decrease the amount of data collected, for example by turning on a video camera to collect data only upon detection of motion, such that the event of motion detection with a motion detector causes a second sensor (the video camera) to start data collection (see for example US 4,857,912). Alternatively, other systems may combine two different types of data, as described for example in US 6,396,535, which combines radar speed and data from three video cameras to monitor vehicles. Among the many drawbacks of either of these different types of systems are the ability to be triggered by non-events (ie false alarms) and also their inability to help the human operator to understand whether the data being received is important to consider. Other systems disclosed in the art attempt to analyze the input data automatically, for example by combining data from several sensors (as in US 2005/0258943) or by automated image analysis (see for example US 5,666,157 or US2004/0120581). Combining data from several sensors does not necessarily help the human operator to understand the data; although US 2005/0258943 discloses a method in which different types of data obtained from different sensors are weighted, such weights are artificial and do not relate to the "real life" importance of input data or of the event which caused the data to be input. Automated image analysis is also problematic, since these computerized methods cannot actually understand the importance of the images, but rather can only attempt to match one or more images to patterns. However, the differences between patterns and the inability to precisely describe which patterns are important (given normal variations in human behavior) significantly decrease the utility of such methods. US6070576 attempts to overcome these drawbacks by allowing the operator to select which types of objects in images trigger an alarm, but again suffers from the above problems with variability and with the inability to precisely determine a pattern, or to differentiate between different patterns. US20020099518 attempts to provide a higher level, completely automated analysis which relates to event analysis and knowledge management and so forth, but performed in a completely automatic manner. Security technologies are not limited to video data of course; they can also incorporate many different types of sensors, and may also combine these different types of sensor data. US6028626 describes a method for providing analysis of various types of data, including audio data, accelerometer data and also image analysis of video data, to determine the intent of the actions of various individuals. Combining different types of data does not solve the underlying problems of pattern analysis and pattern matching, and may even exacerbate them, since the use of more than one type of data may increase the variability of patterns based on such data. US6989742 and US2006/0055543 describe the use of motion sensors rather than video cameras, in order to obtain data about the motions of individuals which can then be analyzed to determine the patterns of their motions. Again, these disclosures do not overcome the above described problems.

SUMMARY OF THE INVENTION

There is an unmet need for, and it would be highly useful to have, a system and a method for knowledge management and organization of security-related data in order to assist a human operator in analysis of such data. There is also an unmet need for, and it would be highly useful to have, a system and a method for assisting a human operator to determine the order of priority for reviewing incoming data. There is also an unmet need for, and it would be highly useful to have, a system and a method for assisting a human operator to determine the significance of incoming data and also an appropriate response. There is also an unmet need for, and it would be highly useful to have, a system and a method for determining such priorities substantially without reducing the amount of data being provided to the operator. The present invention overcomes these drawbacks of the background art by providing a system and method for organization of security-related data in order to at least assist in the determination of the relative priority of such data. The system and method preferably assist the human operator to determine the relative priority of such data and more preferably receive feedback from a human operator for adjusting such a priority determination. The data is provided from at least one type of sensor but preferably is provided from a plurality of different types of sensors. Optionally and preferably, data is displayed or otherwise provided to the human operator without reducing the total amount of data available for display and/or for being provided. However, the present invention may optionally be operative with one or more data sensors and/or methods of data collection which do reduce data that is provided.

According to preferred embodiments of the present invention, there is provided a security system, comprising a plurality of sensors for collecting data, an organization engine for organizing the data and a display for displaying data to a human operator according to organization by the organization engine. Preferably, the plurality of sensors comprises a plurality of different types of sensors. Also preferably, the organization engine comprises a history analysis module, for storing at least one pattern of previously organized sensor data. More preferably, the at least one pattern is organized by a human operator.

According to other preferred embodiments of the present invention, there is provided a method for organizing security data, comprising: obtaining data from a plurality of sensors; determining a relative priority for the data according to manual input; and displaying the security data to a human operator according to the determining the relative input.

According to preferred embodiments of the present invention, there are optionally and preferably different user levels. More preferably, the handling procedures for the various patterns are determined by (more senior) security officers, and are most preferably displayed to the human operator. Also most preferably, such a display is context driven, thus guiding the interpretation and reaction process of the human operator even without the physical presence of a more senior security officer.

According to still other preferred embodiments of the present invention, there is provided a method for detecting a non-event, which is a non-occurrence of an expected event. This method provides for detection of one or more anomalies and/or deviations from a known routine, which in turn enables unknown and/or dynamic threats to be handled while still obtaining benefit from recognition of one or more previously understood and/or analyzed events having one or more similar aspects. According to yet other preferred embodiments of the present invention, there is provided a method for interpretation (at least partially manual and/or optionally automated) which is more efficient and relevant by augmenting the capabilities and functions of a human operator. Preferably the method guides an accurate and relevant interpretation by a human, more preferably with at least reduced reliance on personal experience and/or personal tendencies or biases.

The point of view or preconceptions of the human operator are preferably also managed and more preferably challenged through such concept based analysis as provided according to at least some embodiments of the present invention. According to at least some embodiments of the present invention, the system supports and preferably also receives benefits from a continuous learning process as the human operator interacts with the system. As part of this learning process, the system preferably also supports sharing and collaboration, as well as development of knowledge regarding routine or threatening patterns in and around the secured area.

According to some embodiments of the present invention, there is provided a method for organization of security-related data, comprising: a. Receiving data from at least one sensor; and b. at least partially determining a relative priority of the data. Preferably, the relative priority of the data is also determined according to manual input by a human operator. More preferably, the method is performed for assisting the human operator to determine at least one or more of the relative priority of the data, security significance of the data and an appropriate action to be performed. Optionally and preferably, the method further comprises receiving feedback from the human operator for adjusting such the relative priority of the data. Preferably, the data is provided from at least one type of sensor. More preferably, the data is provided from a plurality of different types of sensors. Optionally and preferably, the data is displayed or otherwise provided to the human operator without reducing the total amount of data available for display and/or for being provided.

According to other preferred embodiments of the present invention, there is provided a security system, comprising: a. a plurality of sensors for collecting data; b. an organization engine for organizing the data; and c. a display for displaying data to a human operator according to organization by the organization engine.

Optionally the plurality of sensors comprises a plurality of different types of sensors. Preferably, the organization engine stores at least one pattern of previously organized sensor data. More preferably, the at least one pattern is organized by a human operator.

According to still other preferred embodiments of the present invention, there is provided a method for organizing security data, comprising: a. obtaining data from a plurality of sensors; b. determining a relative priority for the data at least partially according to a policy; and c. displaying the security data to a human operator according to the relative priority.

Preferably the policy comprises a pattern, such that the determining the relative priority comprises comparing the data to the pattern. More preferably, the pattern comprises an event and associated information regarding expected data. Most preferably, the pattern is associated to one or more parameters selected from the group consisting of location in an area to be secured, time of occurrence, alert types, alerting sensor and users. Also most preferably, the one or more parameters are at least partially used for determining the relative priority.

Preferably, the pattern is associated with a description of the pattern for being displayed to the human operator. More preferably, the description comprises one or more of pictures, videos, text, graphical map layers, audio data and linked documents. According to yet other preferred embodiments of the present invention, there is provided a method for recognizing a non-occurrence of an event in an area to be secured, comprising: a. Obtaining data from at least one sensor; and b. Comparing the data to at least one pattern, the at least one pattern including at least one event to determine whether the at least one event has occurred or has not occurred. Preferably, the area to be secured comprises a border separating between two or more areas, a region of interest, an open area, an urban environment and/or an environment characterized by a plurality of man made structures, an area secured by a perimeter block, a building and/or other structure, a plurality of any of the above and a mix of a plurality of areas.

According to still other preferred embodiments of the present invention, there is provided a method for recognizing a deviation from a routine pattern in an area to be secured, the routine pattern including at least one event, the method comprising: a. Obtaining data from at least one sensor; b. Comparing the data to the routine pattern; and c. If the data is different from the routine pattern, issuing an alert.

According to yet other preferred embodiments of the present invention, there is provided a method for determining a security policy for an area to be secured, the area featuring at least one sensor, the method comprising: a. Constructing a language for describing at least one concept for security of the area to be secured; b. Describing at least one pattern in the language, the at least one pattern including data from at least one sensor; and c. Determining at least one policy in the language, the at least one policy comprising the at least one pattern and a response to the at least one pattern.

Preferably the method further comprises: a. Determining at least one data structure for storing sensor data according to the at least one concept. More preferably, the pattern comprises an event and the event comprises sensor data. Optionally, the area to be secured comprises a plurality of zones and wherein the at least one pattern relates to a zone. Preferably, the policy relates to a plurality of zones, with a differential priority given to at least one zone. More preferably, a differential priority is given to each of the plurality of zones.

Optionally, the policy comprises at least one rule for determining a priority to the response. Preferably, the response comprises issuing an alert and a priority of the alert is determined according to the policy. More preferably, the response comprises displaying sensor data to a human operator and a priority of the data display is determined according to the policy. Most preferably, the method further comprises: a. Analyzing data obtained from at least one sensor; and b. Adjusting the policy according to the data from the at least one sensor. Also most preferably, the adjusting the policy comprises: a. Suggesting an adjustment to the policy; and b. Making the adjustment if permitted by a human user.

Optionally the method further comprises: a. Gathering data from a plurality of sensors; b. Analyzing the data to determine a plurality of patterns; and c. Connecting each pattern to a policy.

According to still other preferred embodiments of the present invention, there is provided a method for analyzing data from a plurality of sensors in an area to be secured, comprising: a. Gathering data from the plurality of sensors; b. Characterizing the data according to at least one parameter; c. Analyzing the characterized data to determine a plurality of patterns; and d. Constructing at least one policy according to at least one pattern.

Preferably, the at least one parameter comprises at least one of according to a type of data gathered, a type of sensor, time of gathering the data, space of a sensor providing the data.

More preferably the policy includes a response for each pattern. Most preferably the method further comprises: a. comparing input data from a sensor to the plurality of patterns; and b. selecting a response according to a matching pattern. Also most preferably, the matching pattern matches the input data according to a range of tolerance of deviation from the pattern. Preferably, the method further comprises: a. Executing the response according to a decision by a human operator.

Preferably, the method further comprises: a. Determining a plurality of rules for the policy for selecting a response; b. Comparing the rules to received data by a rules engine; c. Selecting a rule according to the received data; and d. Handling a conflict between the rule and the received data according to a conflict rule.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The materials, methods, and examples provided herein are illustrative only and not intended to be limiting. Implementation of the method and system of the present invention involves performing or completing certain selected tasks or stages manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of preferred embodiments of the method and system of the present invention, several selected stages could be implemented by hardware or by software on any operating system of any firmware or a combination thereof. For example, as hardware, selected stages of the invention could be implemented as a chip or a circuit. As software, selected stages of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In any case, selected stages of the method and system of the invention could be described as being performed by a data processor, such as a computing platform for executing a plurality of instructions. Although the present invention is described with regard to a

"computer" on a "computer network", it should be noted that optionally any device featuring a data processor and/or the ability to execute one or more instructions may be described as a computer, including but not limited to a PC (personal computer), a server, a minicomputer, a cellular telephone, a smart phone, a PDA (personal data assistant), a pager, TV decoder, game console, digital music player, ATM (machine for dispensing cash), POS credit card terminal (point of sale), electronic cash register. Any two or more of such devices in communication with each other, and/or any computer in communication with any other computer, may optionally comprise a "computer network". By "online", it is meant that communication is performed through an electronic communication medium, including but not limited to, telephone voice communication through the PSTN (public switched telephone network), cellular telephones or a combination thereof; exchanging information through Web pages according to HTTP (HyperText Transfer Protocol) or any other protocol for communication with and through mark-up language documents; exchanging messages through e-mail (electronic mail), messaging services such as ICQ™ for example, and any other type of messaging service; any type of communication using a computational device as previously defined; as well as any other type of communication which incorporates an electronic medium for transmission.

The term "display" refers to any device or method for providing data to a human, including but not limited to a cathode ray tube display, a computer monitor of any type, a LCD screen, a LED screen, a plasma screen, a television set, a projector, an alarm (whether audible, visual, vibratory or a combination thereof of any two or more such modes), an audio amplifier, a printer, a vibrating device or any other device for providing touch-related feedback.

BRIEF DESCRIPTION OF THE DRAWINGS The invention is herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in order to provide what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the drawings:

FIG. 1 is a schematic block diagram of an exemplary system according to the present invention;

FIG. 2 is a schematic block diagram describing an exemplary, illustrative flow process for determining the relative priority of data according to the present invention;

FIG. 3 shows a flowchart of an exemplary, illustrative event handling process according to the present invention;

FIGS. 4 A and 4B show flowcharts of exemplary methods according to the present invention for data organization and prioritization; FIG. 5 is a flowchart of an exemplary, illustrative method according to the present invention for determining an event pattern; and

FIG. 6 is a flowchart of an exemplary, illustrative method according to the present invention for constructing or a least adjusting a rules engine for analyzing the received data and for matching the data to one or more event patterns.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is of a system and a method for organization of security-related data in order to at least partially determine the relative priority of such data. The system and method preferably assist the human operator to determine the relative priority of such data and more preferably receive feedback from a human operator for adjusting such a priority determination. Such feedback is more preferably received by displaying one or more prioritized event patterns to the operator, and asking the operator to match current events against these pattern(s). The priority of the event is then more preferably adjusted according to the event-pattern association created. The system and method also optionally assist a human operator to determine the significance of incoming data and also an appropriate response.

Again, such assistance is preferably provided through displaying one or more previously determined event patterns to the operator, who then uses such previously determined pattern(s) to select an appropriate response.

The data is provided from at least one type of sensor but preferably is provided from a plurality of different types of sensors. Optionally and preferably, data is displayed or otherwise provided to the human operator without reducing the total amount of data available for display and/or for being provided.

Optionally and more preferably, the security related data is provided with regard to an area to be secured. The area to be secured may optionally comprise any space, including but not limited to a border separating between two or more areas, a region of interest, an open area, an urban environment and/or an environment characterized by a plurality of man made structures, an area secured by a perimeter block of some type (such as a fence for example), a building and/or other structure, a plurality of any of the above and a mix of a plurality of areas.

According to preferred embodiments of the present invention, a policy is preferably determined by a human in order for data received from the sensors to be interpreted and/or one or more event patterns to be constructed and/or one or more responses to the event patterns to be determined. A policy may optionally be constructed according to at least one pattern. A policy may also optionally be constructed in reference to one or more other policies, such as a general policy with regard to one or more aspects of security for the area to be secured.

According to preferred embodiments of the present invention, the policy is preferably constructed according to a conceptual language. The language preferably features a plurality of concepts relating to security, which more preferably includes user defined language. Each concept in the language is preferably related to an aspect of the system and method of the present invention according to a human understanding or interpretation, as the concepts of the language assist the human operators to understand the information as provided and/or to interact with the system of the present invention. The language is also preferably therefore uniform in the security group (among the security operator(s) and/or officer(s)), thus contributing to improved communication and sharing of information among the system users.

Examples of concepts for which language is preferably provided optionally and preferably include but are not limited to one or more of a type of incoming data, specific incoming data, a type of sensor, a sensor location, a specific sensor, a type of location, a specific location, a type of object, an object location, a specific object, security zones and zone groups, users and user groups, known activity patterns and procedures, activity pattern types/groups (e.g. routine patterns, patterns indicating failure, suspicious and/or emergency patterns), areas and area types and the like, or a combination thereof.

The concepts in the language are preferably constructed in a hierarchical method, such that for example a concept may be sufficiently broad to have one or more narrow concepts included within it. More preferably, a hierarchical tree is used for the construction of the language and also most preferably for enabling a human operator to view and/or understand the relationship between the different concepts in the language.

The language concepts are preferably used for data organization, such that data structures for containing data are preferably constructed and organized according to the language concepts. For example, a data structure or a portion thereof may optionally be associated with a concept such as "vehicle", which could then contain one or more aspects of the security system that are related to a vehicle. More preferably, one or more events (potentially and/or previously occurring) are associated with the concept. With regard to the non-limiting example of "vehicle", the event(s) may optionally include such types of events as legitimate (permitted) vehicles, vehicles which have been previously noted, one or more locations for vehicles and so forth.

A concept in the language may optionally have different meanings depending on the conceptual context in which it appears. Thus, a 'tank' would mean something different when in the Weapons category (ie an Abrams tank) and when it is in the Containers category (ie a water tank for example).

The policy (and more preferably at least one general policy) preferably includes information relating to the determination of a plurality of zones within the area to be secured. More preferably, the zones are prioritized. Alerts are also preferably prioritized, more preferably according to a policy and most preferably according to at least one rule. The prioritization is preferably determined according to one or more a plurality of parameters which may optionally include but are not limited to zone of occurrence of an event, time of occurrence, one or more sensors providing data about the event and the type of alert. These parameters may optionally be combined or used separately to prioritize alerts. For example, alerts may optionally be prioritized according to the zone priority, and/or different priorities may optionally apply for daytime as opposed to night time; a particular type of alert may optionally receive a higher priority; and so forth. A policy may also optionally and preferably include an event pattern.

The event pattern itself preferably has associated information, more preferably including categorized event patterns (routine events, ambiguous/unfamiliar event, failures, emergency events and so forth). Each event pattern is preferably associated to one or more parameters (zone, time, alert types, alerting sensor, users, and so forth) that preferably determine whether the system displays a particular event pattern to the human operator when handling a particular alert.

The event pattern is preferably also associated with a description (for the human operator) of the pattern. The description is optionally and preferably in the form of one or more of pictures, videos, text, graphical map layers, audio data and other linked documents. The event pattern is preferably also associated with one or more response procedures to be performed if an event matches the pattern. The event pattern may optionally have more than one response procedure - for example one for handling the event in a normal context and the other for handling the event when it does not perfectly match the pattern.

According to other preferred embodiments, the system also provides one or more automated routine tasks that involve sensors, operators or both that run at regular hours and/or automatically when a particular event is received. According to still other preferred embodiments, event handling may optionally be performed as follows. When an alert is received the system preferably uses alert parameters to determine which event patterns may be appropriate and displays them to the operator. The match between pattern and alert need not be perfect, so under certain conditions an event pattern is displayed even though it is not a perfect match. Optionally and preferably, a range of tolerance of deviation from the pattern for the input data is included as part of the information related to the pattern. Any discrepancies or irregularities are also preferably noted.

The operator then preferably selects the best matching event pattern and the attached procedure is executed. The operator may also optionally mark manually an anomaly in the pattern compared to the current event and may also optionally (alternatively or additionally) change the priority of an event based on a discrepancy or anomaly.

Event prioritization is therefore preferably performed a plurality of times, including according to one or more rules as described above; according to an overall priority for the event; and if the event represents an anomaly in relation to the pattern, it may be automatically re-prioritized or manually re-prioritized by the operator.

According to yet other preferred embodiments of the present invention, policies may also optionally be updated. Based on the report history, and especially the anomalous reports, and reports associated with unfamiliar events, the security officer (or other qualified human) may optionally modify a current policy, create new patterns, and so forth.

According to still other preferred embodiments of the present invention, a language provided for the system and method of the present invention preferably relates to objects, patterns of events and behavior. Language concepts preferably include concepts related to objects and events. These concepts are then preferably used to build language concepts related to patterns of events and behavior (which relates to one or more actions taken by one or more objects). The principles and operation of the present invention may be better understood with reference to the drawings and the accompanying description.

Referring now to the drawings, Figure 1 is a schematic block diagram of an exemplary system according to the present invention. As shown, a system 100 preferably features a plurality of sensors 102, including but not limited one or more different types of camera. For the purposes of illustration only and without any intention of being limiting, the cameras shown include a PTZ (pan-tilt-zoom) camera 104, which is a standard type of video camera that can zoom in or out, and which is connected to a servo motor or any type of suitable motor and mount to permit panning and tilting. Another exemplary, non-limiting type of camera includes a VMD (video motion detector) camera 106, although strictly such a camera actually features an analysis system with a camera. The analysis system activates collection of video data upon the detection of movement. Optionally or alternatively, video data may be collected through camera 106 regardless of whether movement is sensed. A thermal camera 108 may also optionally be provided, which detects heat energy as opposed light, again as a non-limiting illustrative example. One or more other types of cameras may optionally be provided, additionally or alternatively, without any limitation, as shown by other camera 110. These different cameras may optionally and preferably be connected to a DVR (digital video recorder) 112 for recording video data. Optionally, the cameras may be connected through DVR 112 to a sensor server 114 as shown or alternatively may optionally be connected directly to sensor server 114, which could then optionally and preferably feed video data to DVR 112 and/or to any other type of recording device. It should be noted that "connected" may optionally include any type of wireless or wired connection, and/or any type of computational network as previously described. Also optionally and preferably, system 100 may comprise a plurality of sensor servers 114, shown as sensor server 114 and sensor server 116 for the purposes of illustration only and without any intention of being limiting, as optionally system 100 may comprise any number of sensor servers.

Sensor server 114 is optionally and preferably in communication with sensors 102 other than video cameras, shown as another sensor 118, which could be any type of suitable sensor 102 as is known in the art. Sensor servers

114 and 116 may optionally be implemented according to any suitable configuration, as could easily be determined by one of ordinary skill in the art. Sensor servers 114 and 116 are preferably in communication with a computer network 120 as shown, through any suitable communication technology, which may optionally include any type of wireless or wired connection.

Sensor server 116 optionally and preferably is in communication with a fence sensor 122, for detecting some type of physical activity connected with a fence, including but not limited to, touching the fence, pushing the fence, bending or attempting to bend the fence, cutting or attempting to cut the fence, climbing on the fence and so forth. Sensor server 116 optionally and preferably is also in communication with a geophone sensor 124, for detecting some type of physical activity associated with an area of ground and/or a particular structure, including but not limited to, walking, running, stepping, rolling or otherwise moving while in contact with the ground and/or structure. Without wishing to be limited in any way, geophone sensor 124 detects ground vibrations, and preferably analyzes them in search of meaningful signals or patterns. Depending on the system, the meaningful patterns may be hard-wired into the sensor or optionally taught to the sensor depending on the sensor system specifications (there are various such systems that are known to one of ordinary skill in the art).

In order to support more effective signal analysis, optionally a plurality of geophone sensors 124 may be used in conjunction, for example to calculate the location of the detected activity through triangulation (at least three such geophone sensors 124). Thus, optionally a plurality of such sensors may be used in a geophone field.

A geophone system (one or more geophone sensors 124) can optionally detect (and differentiate between) a man walking/running, a vehicle, digging sounds etc. These systems can be used indoors, for example (and without limitation) to protect the vaults in a bank from external digging, or outdoors, for example (and without limitation) for perimeter defense (optionally and without limitation along a fence), pipeline security and the like.

Sensor server 116 optionally and preferably is in communication with another sensor 126, which could optionally be any type of suitable sensor.

Sensors 102 preferably provide information to sensor server 114 and/or 116, for being provided through computer network 120 to at least one security server 128. Optionally, there is a main security server 128 and a back-up security server 130. Preferably there is at least one, but more preferably a plurality of workstations, shown as workstations 132 and 134. Human operators preferably work through workstations 132 and 134, for viewing information and for entering information about patterns and/or combinations of events and about the relative importance and/or priority of different data. The determination of the priority of data is described in greater detail with regard to the figures below, which is preferably performed before data is viewed "in real time" by the human operators, and optionally also after viewing such data. The determination of the priority of data may optionally be performed by main security server 128 and (optionally additionally or alternatively) back-up security server 130. Other types of analyses may also optionally be performed, also as described in greater detail below.

Also, optionally communication between sensors 102 and computer network 120 may be performed directly (and optionally, alternatively or additionally, the above mentioned analyses), without a particular separate "server", for example through distributed computing, as could easily be implemented by one of ordinary skill in the art.

Figure 2 is a schematic block diagram describing an exemplary, illustrative flow process for determining the relative priority of data according to the present invention. As shown, a process 200 preferably features registration of a policy, in policy registration block 202. Policy registration includes the provision of at least one characteristic for determining a relative priority of received data. For example, the characteristic may optionally relate to the reception of any data from a particular sensor as defined in time and/or space, and preferably both, or alternatively to the reception of specific identified data, or alternatively or additionally to the failure to receive any data and/or specific identified data. Such a characteristic may optionally and preferably feature a combination of data from a plurality of sensors (and/or the failure to receive such data from one or more sensors).

According to preferred embodiments of the present invention, the policy itself preferably includes determination and registration of a plurality of zones, with a differential priority given to at least one zone; more preferably, the plurality of zones have differential priorities set for the plurality of zones. Each zone preferably relates to a different portion of the area to be secured. A zone may optionally relate to a floor in a building for example as well. By differential priority it is meant that an event occurring in a particular zone is preferably given a higher priority than if that event occurred in a different zone. Such a policy determination provides assistance to the human operator through greater ease of analysis of sensor data and also by providing more clear information regarding the "importance" or priority of different events.

According to other preferred embodiments of the present invention, the policy itself optionally and preferably includes a plurality of rules for determining priorities of events. The rules may optionally and preferably relate to the event itself, as described in greater detail below, but more preferably (additionally or alternatively) relate to the zone priority and to one or more temporal factors, such as one or more of the time of day, day of the week, month, season and so forth.

With regard to one or more rules relating to the event itself, non- limiting examples include a rule which relates to the alerting sensor and to the type of alert provided by the sensor. These different rules may optionally be combined or used separately to prioritize events and the alert response to such events.

At event block 204, an event is shown as occurring; the event may optionally comprise a plurality of sub-events or actions. Furthermore, optionally event block 204 may relate to an event which is itself a sub-event for another such event. The context for the event is preferably then assessed by reviewing data from event block 204 and the policy from policy registration block 202, to determine a policy based event context 206. With regard to the data received, each item of received data is preferably compared to an event pattern. One or more event patterns which match such data may then optionally be considered for the context; however, more preferably the policy itself may override a match according to the received data (for example by having a rule that such a matched event pattern may not be considered). A more detailed example of determining an event pattern is provided with regard to Figure 5. Preferably, such assessment is performed automatically by the system, thereby optionally producing a potential context for interpreting the data according to one or more matching patterns.

Optionally and more preferably, the match between the received data and the event pattern does not need to be perfect, as the policy may optionally describe some degree of tolerance for a mismatch. For example, if one part of the event pattern is irregular, such as the arrival of one or more pedestrians in a certain zone at a certain time, the event pattern may optionally indicate that the irregular part is completely optional, or that at least one aspect of the irregular part is optional or flexible (for example with regard to the exact arrival time of the pedestrians, which may optionally be specified with regard to a range). In the case of an event pattern providing an imperfect match, preferably the point(s) at which the pattern does not match the received data are indicated, more preferably with information regarding whether the non-matching part(s) are known to be irregular.

An association between the event and a particular type of responsive action that should be performed by the human operator is preferably then determined at event association block 208. Such an association, preferably by determining that an event fits within a particular pattern, may optionally and preferably be determined manually by the human operator, although alternatively one or more actions may optionally be performed automatically by the present invention (for example, optional automatic data recording). The event itself is preferably handled at policy-based event handling 210, which more preferably provides one or more recommendations for the human operator to follow, optionally with context sensitive data being displayed that is relevant to the pattern. The recommendations may optionally include for example whether to indicate a general alarm and/or dispatch a mobile security unit and/or note the event occurrence in a log book; of course many other responses are possible. The human operator preferably also indicates any discrepancies noted between the actual observed pattern and the predefined pattern in the policy. The additional collected data is preferably then analyzed in policy adaptation 212, to determine whether one or more policies should be updated and/or altered and/or discarded and/or created, based upon the data collected from the event (which may optionally include manual observations by one or more security personnel). One or more reports are preferably also generated which include events detected, any anomalies with regard to such events and also preferably the above described manual observations.

According to preferred embodiments of the present invention, there are optionally and preferably different user levels. More preferably, the handling procedures for the various patterns are determined by (more senior) security officers, and are most preferably displayed to the human operator. Also most preferably, such a display is context driven, thus guiding the interpretation and reaction process of the human operator even without the physical presence of a more senior security officer. The display is therefore preferably determined according to the above process, with participation of manual input from human operators/officers. Furthermore, policy adaptation 212 is preferably determined later by one or more users, more preferably higher level users (such as higher level security officers for example).

For example, the security officer may optionally modify one or more current policies and/or create new patterns according to the report history.

More preferably, one or more anomalous reports are considered in such a modification or creation of a pattern. Optionally and most preferably, reports associated with unfamiliar events are also included for such consideration.

According to preferred embodiments of the present invention, process 200 preferably features a cycle, in which the entire process is preferably repeated at least once, more preferably more than once and most preferably as a cycle that is optionally performed continuously or at least regularly.

According to other preferred embodiments of the present invention, the above cycle preferably relates to a general process, which is a general case for a policy that is connected to a specific event, but also relates to two specific processes as shown. A first process ^"relates to security management for handling the policy, which is shown as being related to the overall cycle, while within the first process, there is handling of a specific event, which preferably only relates to a portion of the first process as shown. More preferably, a policy is not changed in real time, but rather is only applied/followed or not applied/followed.

Figure 3 shows a flowchart of an exemplary, illustrative event handling process according to the present invention. As shown, a process 300 starts with an event 302 and leads to another event 308. Events 302 and 308 are preferably linked (temporally and/or spatially and/or according to any sort of linkage). Events 302 and 308 are preferably analyzed as previously described by system 304 according to the present invention.

System 304 optionally features an organization engine 305 for optionally and preferably performing an event analysis 312 for determining an event context 306 according to a pattern (as previously described) and also optionally according to dynamic data, which may optionally comprise one or more different aspects of the data that do not necessarily fit the pattern, and/or which may optionally comprise the actual data as collected from one or more sensors.

As previously described, optionally and more preferably events 302 and 308 are analyzed in terms of one or more language concepts. Most preferably, a plurality of language concepts are used to describe each such event as part of event analysis 312, optionally and most preferably including language concepts related to one or more objects in each event and also to one or more actions taken by each object in each event. Event context 306 is also preferably provided in terms of one or more language concepts. More preferably, such language concept(s) are also used to organize received data about each of events 302 and 308 such that the received data is preferably placed into at least one data structure according to at least one language concept, as described in greater detail below. The language concepts preferably include concepts related to the system of the present invention, more preferably including one or more of the following types of system elements: Area, which optionally and most preferably includes one or more of Zones, Zone Types, Points of interest;

Time, which optionally and most preferably includes one or more of Special occasions, Named periods (day/night, summer,...), Dates; Sensors, which optionally and most preferably includes one or more of types, user-defined groups, alert types; Patterns, which optionally and most preferably includes one or more of Names, types; Automated Tasks , which optionally and most preferably includes a list of named tasks; and/or Users, which optionally and most preferably includes one or more of Groups, Roles and Named Users. The language also preferably includes one or more user defined concepts, more preferably including concepts related to one or more objects and one or more actions performed by each object. As a non-limiting example, with regard to the concepts related to the objects, such concepts may optionally include but are not limited to one or more of the following exemplary, illustrative categories: Vehicles (optionally including but not limited to Light vehicles such as Motorcycles, Private vehicles; Heavy

Vehicles such as Trucks, Semi-trailers, types of trucks such as a Garbage

Collector's Truck or a Delivery Truck), portable objects (optionally including but not limited to Cameras, Bags, Weapons (such as Knives, Guns, Grenades) and People (optionally including but not limited to System Users

(such as a particular user, a group of users and/or a particular role for a user, such as a security officer or operator for example), a category of external person who is not a system user (such as a visitor, a delivery person, a police officer and so forth), or a specific external person who is not a system user, such as "John Smith" for example.

The concepts are also optionally and preferably context sensitive, such that a certain concept may optionally comprise a plurality of concepts according to context. Some of these different concepts may optionally arise due to the meaning of the actual words used in the language. For example a "tank" could potentially be related to a water tank, a gas tank, an Abrams tank and so forth, such that the concept "tank" could optionally comprise a plurality of different concepts. Other concepts may optionally (additionally or alternatively) feature context sensitive determination in relation to a security based context.

A security officer 310 may also optionally and preferably contribute information and/or data, and/or may alter the contextual analysis for at least a portion of the collected data. According to preferred embodiments, such a contribution is made before or after event handling, for example (and without limitation) according to one or more of : creating and characterizing the event patterns that are of security interest; assigning priorities and handling procedures to these event patterns; performing off-line analysis of the operators' outputs (which are associated events) and/or adding new dynamic data.

The collected data is preferably used for event analysis 312, optionally and preferably as previously described. Event analysis 312 results are then preferably used to at least determine a relative priority of information to provide to a human operator 314, more preferably to assist human operator 314 with analysis and/or interpretation of event 302. Such analysis and/or interpretation preferably allows human operator 314 to select one or more procedures 316 for handling event 302, more preferably according to one or more previously registered policies. Preferably each pattern is connected to a policy. Also such analysis and/or interpretation preferably allows human operator 314 to determine whether one or more exceptions 318 exist.

According to preferred embodiments, part of the information provided to human operator 314 is whether event 308 also fits into a pattern for event 302. In this regard, event 308 could optionally be the absence of data or information as a "non-event". The system is preferably able to provide information regarding whether one or more policies fit both events 302 and 308, or alternatively only one of the two events; preferably each such relevant policy is displayed to human operator 314. According to preferred embodiments of the present invention, the present invention may optionally be operative with one or more data sensors and/or methods of data collection which do reduce data that is provided.

According to other preferred embodiments of the present invention, there are optionally and preferably different user levels. More preferably, the handling procedures for the various patterns are determined by (more senior) security officers, and are most preferably displayed to human operator 314.

Also most preferably, such a display is context driven, thus guiding the interpretation and reaction process of human operator 314 even without the physical presence of a more senior security officer.

Figures 4A and 4B are flowcharts of exemplary methods according to the present invention for data organization and prioritization. Figure 4A relates to setting a policy, preferably "off-line" (ie preferably not in real time as an event is occurring), while Figure 4B relates to handling a specific event in real time as it is occurring.

As shown in Figure 4A, in stage one, data is collected, preferably as previously described. The data is then preferably characterized in stage two, for example according to the type of data gathered (such as the type of sensor for example) and/or such characteristics as the time and/or space in which the data was gathered.

As described above, the space characteristic preferably relates to the zone prioritization for different zones in the area to be secured. The time characteristic preferably relates to any temporal aspect of the obtained data. The type of gathered data preferably also relates to at least one aspect of the actual data obtained by the sensor; for example, for a geophone, if the actual data is above a threshold then it may optionally receive a different characterization because data above that threshold is more likely to result from movement of a person and/or vehicle in the area.

In stage three, the data is preferably analyzed to determine one or more patterns. A pattern is optionally and preferably manually determined in advance of an event by a user, preferably a higher level user (such as a security officer). Each such pattern preferably includes a plurality of layers, including but not limited the following layers: associated system parameters (relevant physical/location based zone(s), relevant time, relevant sensors, relevant sensor alerts/events, color); a "soft" description of the pattern: text, images, video, map layers and so forth, which is "soft" in the sense that it is intended for human comprehension rather than for computer analysis; and/or procedures to be executed when the event matches the pattern (event association).

Because the patterns defined by the security officer are on a high level that cannot be detected by sensors alone, which can only detect basic movement and/or objects, the system of the present invention preferably displays all potentially relevant patterns (as defined by the "hard" parameters - space, time, sensor, and event type) to the operator. The human operator then optionally and preferably matches the real-time information with the displayed patterns and selects the one that best describes the situation, according to the "soft" description of the pattern, as described in greater detail below with regard to Figure 4B.

In stage four, according to preferred embodiments of the present invention, one or more data structures are created according to one or more patterns. These data structures may optionally be matrices, although alternatively any suitable type of data structure may optionally be used. One or more data structures are preferably used in order for the relative priority of data to be stored and/or for storing the collected data, more preferably with the previously obtained one or more collection characteristics. For example, this storage structure may optionally permit such data and meta-data to be stored in an easily accessible form that is relevant to one or more registered policies. A matrix may optionally comprise data according to the following structure: Alert - is part of - Event Report - is part of Event File - is associated with - pattern file. An optional data structure may be provided for an event that does not fit any known pattern. In stage 5, a data structure is preferably linked to a policy, such that the data structure preferably comprises the pattern of the event and also the action or action(s) which are preferably performed by the human operator.

More preferably, such a linkage is performed by a higher level user, such as a higher level security operator for example.

In Figure 4B, an optional, exemplary but preferred method for handling a specific event in "real time" is shown.

In stage one, data is again gathered as previously described for a specific event that is occurring in real time. Such data gathering is optionally and preferably performed continuously, as part of a normal security operation, as previously described. In stage two, data is preferably characterized as described above, for example to determine one or more collection characteristics, including but not limited to when and/or where and/or from which type of sensor and/or specific sensor data is expected. According to optional embodiments of the present invention, the data itself may optionally and preferably be analyzed to additionally or alternatively determine its content, as opposed to one or more collection characteristics as previously discussed. Content analysis may optionally be performed as is known in the art, for example as previously described in the Background section. Alternatively, optionally no content analysis is performed.

In any case, the one or more collection characteristics with the data preferably forms one or more patterns (if performed, the results of content analysis may also optionally be included).

In stage 3, the gathered data is organized into a data structure, also described above.

In stage 4, optionally and preferably one or more data structures are compared to previously obtained data structures. For example, optionally data that has been collected and analyzed may be compared to historical (previously obtained and analyzed) data. Such a comparison may optionally be used to determine whether (and optionally how) more recently collected and analyzed data is similar to, or different from, previously collected data. Additionally or alternatively, such a comparison may optionally be used to consider whether recently and/or historically collected data fits to one or more policies, and if so how well such a fit may be made.

According to preferred embodiments of the present invention, such an embodiment may optionally and preferably be used to give feedback to one or more human operators. For example, preferred embodiments of the present invention may optionally be used to permit a human operator, such as a security officer, to record a security policy into the system. By providing such an officer with a context-sensitive policy-based review and analysis of the event being assessed, the present invention facilitates relevant responses to events based on a correct human interpretation of these events, which may optionally be facilitated by one or more actions by a lower level human security operator. Also, such a comparison optionally and preferably enables the security officer to identify inadequacies of the security policy, thus facilitating policy change and adaptation (continuous learning) as previously described.

In stage 5, optionally and preferably an alert is given to a human operator, more preferably according to a policy. Such an alert preferably also includes one or more policies shown which may fit the pattern of the event according to the compared data structures. For example (and without any intention of being limiting), a system may optionally have 50 policy files, but only those which are most relevant to the data are displayed while the remaining files are filtered out and are preferably not displayed. For example if a policy is specific to a particular physical zone (location), and the event is not occurring in that zone, preferably the policy is not displayed to the human operator. Another example is a temporal filter, in which a policy is only relevant according to a time of occurrence of an event. Alternatively, a policy may not be filtered according to a particular parameter (such as location or time), yet the policy could still be characterized by time or location (as for a likely time or location for something to occur), such that the system could point out that there is a discrepancy with the usual time range for something to occur.

For example, as for the previously described irregular event and/or irregular part of an event, pedestrians may optionally arrive at a certain zone of the area to be secured at a time that may be determined as part of a wide range (for example, from 7am to lpm). If the pedestrians appear at any time in this range, then the filter preferably indicates that at least this part of the event has been fulfilled. However, if the range of time passes and no pedestrians appear, then the lack of pedestrians is preferably indicated as a "non-event occurrence", as the irregular part of the event (or irregular event) was not fulfilled.

Such a data structure comparison could also optionally be used to track and report non-events, as the absence of data could also optionally and preferably be noted. If a non-event is registered many times, the security officer or other higher level user may decide to place the policy in an archive. In order to prevent the absence of data from confounding the results, optionally and preferably each policy is analyzed If data is not received according to the expected pattern, which may optionally include a range of flexibility with regard to one or more characteristics, then preferably the absence of data is noted to the human operator, more preferably according to the relative priority established by one or more registered patterns (for example as previously described as for the collected data).

Optionally the human operator may not view a particular policy for selection if the policy outcome for the system according to the present invention is "do nothing - do not display".

Optionally and preferably, the human operator decides which policy should be selected, as shown with regard to stage six. The alert optionally and preferably facilitates a process of evaluation by providing the operator with a relevant context that includes (but is not limited to): video of the near past of the event, potentially relevant patterns for the event interpretation and dynamic information items (general/specific intelligence alerts, general/specific security officer messages and so forth). The human operator is preferably provided with this information according to a relative priority of data, such that data having a relatively higher priority is preferably given more emphasis and/or displayed first and/or otherwise brought to a higher degree of attention for the human operator.

According to other embodiments of the present invention, the security officer may also optionally be informed if the response of a human operator to a particular event and/or alert is outside of the security policy (for example, if the human operator marks an event as "red — high alert" when the policy calls for "green — low alert"). Such a response may indicate inconsistency of the behavior of the human operator, but may also additionally or alternatively indicate a potential aspect of the security policy which should be considered further.

Such an alert is also more preferably provided or displayed with context sensitive information which is optionally and more preferably determined through manual input from one or more individuals, for example optionally (more senior) security officers through the use of different user levels.

According to still other embodiments of the present invention, the human operator (user) may optionally and preferably interact with the system according to the present invention, such that input provided by the human operator may be used to alter one or more event patterns being displayed for selection or consideration for example. For example, if the human operator states that a video camera is showing a delivery person, the system may then optionally display at least one additional or different event pattern according to this input information, and/or may alter the ranked relevance or priority of at least one displayed event pattern according to this input information.

The human operator can also preferably add information to a report generated by the system of the present invention, more preferably by selecting additional concepts that cannot be collected automatically from the sensor alerts. As above, the example may be of a video camera showing an identified delivery person.

The human operator may also optionally associate an event with a previously non associated area or zone. Figure 5 is a flowchart of an exemplary, illustrative method according to the present invention for determining an event pattern.

In stage 1, one or more zones of the area to be secured are preferably selected for inclusion in a new event pattern, which provides a spatial focus to the pattern, In stage 2, one or more sensors are preferably selected, more preferably according to the expected data to be provided as part of the event pattern.

In stage 3, the expected data from the sensor may optionally be characterized in more detail. Preferably, such characterization includes a tolerance range for one or more deviations or irregularities for any such expected data, more preferably with regard to at least one of a temporal deviation and a level or quality deviation (regarding the data itself), or a combination thereof. Stages 2 and 3 may optionally be repeated at least once

(preferably as necessary to determine the overall pattern). In stage 4, one or more temporal aspects of the pattern are optionally and preferably determined. Temporal aspects optionally and more preferably include one or more of time of day, duration of the period for the pattern, season, month, day of the week, one or more specific dates and so forth, or a combination thereof. However, for some sensors and/or for some expected data, optionally the temporal association is determined to be "any time", such that regardless of a particular time, the sensor data is preferably considered to be part of the event pattern.

Optionally, stages 1-4 may be performed in any order and/or may optionally be performed in a plurality of separate portions in any order. In stage 5, preferably information is provided which enables the system to respond to one or more operator statements. For example, if the human operator makes a statement regarding a type of data being viewed (for example a picture of a person with a camera), then the system preferably responds with information relevant to such a statement in the language of the system, for example by displaying a plurality of images related to the concept "person with a camera" and/or by displaying previous occurrences of this concept.

In stage 6, a description of the pattern is constructed for the human operator. The description is preferably in the form of pictures, videos, text, graphical map layers, audio data and/or other linked documents. This description is preferably provided such that the most useful and/or urgent aspects are emphasized and/or otherwise made clear to the human operator.

In stage 7, optionally and preferably one or more procedures are associated with the event pattern for the appropriate response by the human operator if an event matches the pattern. The event pattern may optionally have more than one associated procedure; for example one associated procedure may optionally be related to handling the event in a normal context, while another associated procedure may optionally be related to handling the event when it does not perfectly match the pattern, as for example with regard to an irregularity in the pattern that is outside of the tolerance range for such an irregularity.

Preferably at least one validation procedure is associated with the event pattern, such that the human operator is requested to input information in order to verify that the selected and/or displayed event pattern is correct for the actual data being obtained. More preferably at least one question is asked of the human operator. Most preferably, the question(s) to be asked and the nature or identity of the data to be input are adjusted by a human user such as a security officer.

Optionally and more preferably, one or more automated tasks are associated with the event pattern. Such automated tasks preferably involve an action to be performed by one or more sensors upon the occurrence of the event, for example to initiate recording of a zone with a video camera. Optionally, an event pattern may optionally be associated with a junction, in which a single response is not specified; instead a plurality of different responses may optionally be specified. The human operator may optionally be required to supply more information, and/or the response may also optionally depend upon information obtained from the one or more automated tasks. Preferably, if a decision is required by a human, then the level of privilege within system for the human making the decision is also specified (for example, a final decision by an officer may optionally be required). In stage 8, the event pattern is then preferably categorized, more preferably according to one of a plurality of categories, including but not limited to routine events, ambiguous/unfamiliar events, failures, emergency events and so forth.

Figure 6 is a flowchart of an exemplary, illustrative method for constructing or a least adjusting a rules engine for analyzing the received data and for matching the data to one or more event patterns. The rules engine may optionally be adjusted from a template, for example according to the description provided herein for the rules engine.

In stage 1, a language is preferably constructed according to which the rules engine operates. The language preferably relates to words for constructing the rules and hence also one or more policies as described above. Context for these words is preferably also included, again with regard to human understanding. The language preferably relates to the plurality of zones, time, sensors and their characteristics, and so forth. The language may optionally characterize one or more of these aspects of the system according to a human designation, such as a "critical camera", which is not an inherent property of the camera but instead is a human designation.

The language also preferably relates to event patterns. Each event pattern preferably receives a name; according to this name, the event pattern may optionally itself become an event. The language also preferably relates to the characterization of alerts and responses to event patterns. The language also preferably relates to designations of humans interacting with the system of the present invention. For example, when sending a message to the head of security, preferably the language enables the designation "head of security" and hence the proper destination of the message (telephone number for example) to be determined without knowing the personal name of the person who is "head of security".

In stage 2, a plurality of rules is preferably determined according to the language. The plurality of rules preferably includes simple rules ("if a sensor provides output above a certain threshold, consider the data for analysis"), which are then used to construct more complex rules. The rules also preferably indicate prioritization for an event and/or event pattern, and/or for specific actions.

In stage 3, the rules of stage 2 are preferably analyzed. If a conflict is noted, then preferably at least one additional rule is added to handle this conflict. The at least one additional rule may optionally relate to a human action or decision, such as "the conflict is settled by the head of security" and/or may (alternatively or additionally) relate to one or more actions to be taken by one or more sensors.

In stage 4, preferably one or more rules are specified for handling conflicts "on the fly" (ie in real time). Such rules may also optionally (additionally or alternatively) be specified as part of a policy. A conflict may optionally be handled by always selecting the most urgent (high priority) result, for example. Additionally or alternatively, weighted rules may optionally be used for determining the outcome according to relative weight. For example, a more relevant or important rule may optionally be marked as such. Weighting may also optionally relate to the severity of one or more consequences (for example, if a plurality of rules may apply then preferably the rule related to the greatest security risk or danger is selected). Weighting may also optionally be used for prioritizing or ranking event patterns in terms of selecting a more relevant event pattern according to the input data. Also additionally or alternatively, the conflict may optionally be handled by selecting the rule with the most matching parameters or details.

Rules may also optionally be determined from learning "on the fly" as conflicts occur and are resolved by human decision making, for future resolution.

In stage 5, one or more responses are preferably specified in the previously determined language. These responses may optionally feature one or more system (for example sensor or other device) actions and/or one or more human actions. Non-limiting examples of responses include rotate the camera, open the gate, turn on the light, create a report, associate the report to an event pattern, send an alert to a human operator. A response may also optionally include a "non response" for example for normal activity, so that the human operator and/or the system do not receive too many reports of essentially normal occurrences or activities. In stage 6, optionally and preferably one or more guidelines for proposing new patterns are provided. Such guidelines preferably are provided for the system, for example to suggest a new response to an existing event pattern and/or a new event pattern, according to learned past events. The system may optionally suggest an adjustment to a policy according to data received from a sensor, for example.

In stage 7, optionally and preferably a plurality of privileges is determined for humans interacting with the system according to the present invention. The plurality of privileges preferably indicates which action(s) and/or changes may optionally be performed by a human interacting with the system. For example, a higher level of privilege may optionally be required to change an event pattern and/or an event pattern response than to receive information about the event pattern. Preferably, if the system suggests an adjustment to a policy, the system makes the adjustment only if permitted by a human user, more preferably a human user with the necessary level of privilege for permitting such an adjustment. While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.

Claims

What is claimed is:

1. A method for organization of security-related data, comprising: a. Receiving data from at least one sensor; and b. at least partially determining a relative priority of the data.

2. The method of claim I₅ wherein the relative priority of the data is also determined according to manual input by a human operator.

3. The method of claim 2, for assisting said human operator to determine at least one or more of the relative priority of the data, security significance of the data and an appropriate action to be performed.

4. The method of any of claims 1-3, further comprising receiving feedback from the human operator for adjusting such the relative priority of the data.

5. The method of any of claims 1-4, wherein the data is provided from at least one type of sensor.

6. The method of claim 5, wherein the data is provided from a plurality of different types of sensors.

7. The method of any of claims 1-6, wherein the data is displayed or otherwise provided to the human operator without reducing the total amount of data available for display and/or for being provided.

8. A security system, comprising: a. a plurality of sensors for collecting data; b. an organization engine for organizing the data; and c. a display for displaying data to a human operator according to organization by the organization engine.

9. The system of claim 8, wherein the plurality of sensors comprises a plurality of different types of sensors.

10. The system of claim 8 or 9, wherein the organization engine stores at least one pattern of previously organized sensor data.

11. The system of claim 10, wherein the at least one pattern is organized by a human operator.

12. A method for organizing security data, comprising: a. obtaining data from a plurality of sensors; b. determining a relative priority for said data at least partially according to a policy; and c. displaying the security data to a human operator according to said relative priority.

13. The method of claim 12, wherein said policy comprises a pattern, such that said determining said relative priority comprises comparing said data to said pattern.

14. The method of claim 13, wherein said pattern comprises an event and associated information regarding expected data.

15. The method of claim 14, wherein said pattern is associated to one or more parameters selected from the group consisting of location in an area to be secured, time of occurrence, alert types, alerting sensor and users.

16. The method of claim 15, wherein said one or more parameters are at least partially used for determining said relative priority.

17. The method of any of claims 13-16, wherein said pattern is associated with a description of said pattern for being displayed to the human operator.

18. The method of claim 17, wherein said description comprises one or more of pictures, videos, text, graphical map layers, audio data and linked documents.

19. A method for recognizing a non- occurrence of an event in an area to be secured, comprising: a. Obtaining data from at least one sensor; and b. Comparing said data to at least one pattern, said at least one pattern including at least one event to determine whether said at least one event has occurred or has not occurred.

20. The method of claim 19, wherein said area to be secured comprises a border separating between two or more areas, a region of interest, an open area, an urban environment and/or an environment characterized by a plurality of man made structures, an area secured by a perimeter block, a building and/or other structure, a plurality of any of the above and a mix of a plurality of areas

21. A method for recognizing a deviation from a routine pattern in an area to be secured, said routine pattern including at least one event, the method comprising: a. Obtaining data from at least one sensor; and b. Comparing said data to the routine pattern; and c. If said data is different from said routine pattern, issuing an alert.

22. A method for determining a security policy for an area to be secured, the area featuring at least one sensor, the method comprising: a. Constructing a language for describing at least one concept for security of the area to be secured; b. Describing at least one pattern in said language, said at least one pattern including data from at least one sensor; and c. Determining at least one policy in said language, said at least one policy comprising said at least one pattern and a response to said at least one pattern.

23. The method of claim 22, further comprising: a. Determining at least one data structure for storing sensor data according to said at least one concept.

24. The method of claims 22 or 23, wherein said pattern comprises an event and said event comprises sensor data.

25. The method of any of claims 22-24, wherein the area to be secured comprises a plurality of zones and wherein said at least one pattern relates to a zone.

26. The method of claim 25, wherein said policy relates to a plurality of zones, with a differential priority given to at least one zone.

27. The method of claim 26, wherein a differential priority is given to each of said plurality of zones.

28. The method of any of claims 22-27, wherein said policy comprises at least one rule for determining a priority to said response.

29. The method of claim 27, wherein said response comprises issuing an alert and a priority of said alert is determined according to said policy.

30. The method of claims 28 or 29, wherein said response comprises displaying sensor data to a human operator and a priority of said data display is determined according to said policy.

31. The method of any of claims 22-30, further comprising: a. Analyzing data obtained from at least one sensor; and b. Adjusting said policy according to said data from said at least one sensor.

32. The method of claim 31, wherein said adjusting said policy comprises: a. Suggesting an adjustment to said policy; and b. Making said adjustment if permitted by a human user.

33. The method of any of claims 22-32, further comprising: a. Gathering data from a plurality of sensors; b. Analyzing said data to determine a plurality of patterns; and c. Connecting each pattern to a policy.

34. A method for analyzing data from a plurality of sensors in an area to be secured, comprising: a. Gathering data from the plurality of sensors; b. Characterizing said data according to at least one parameter; c. Analyzing said characterized data to determine a plurality of patterns; and d. Constructing at least one policy according to at least one pattern.

35. The method of claim 34, wherein said at least one parameter comprises at least one of according to a type of data gathered, a type of sensor, time of gathering said data, space of a sensor providing said data.

36. The method of claims 34 or 35, wherein said policy includes a response for each pattern.

37. The method of claim 36, further comprising: a. comparing input data from a sensor to said plurality of patterns; and b. selecting a response according to a matching pattern.

38. The method of claim 37, wherein said matching pattern matches said input data according to a range of tolerance of deviation from said pattern.

39. The method of claims 37 or 38, further comprising: a. Executing said response according to a decision by a human operator.

40. The method of any of claims 34-39, further comprising: a. Determining a plurality of rules for said policy for selecting a response; b. Comparing said rules to received data by a rules engine; c. Selecting a rule according to said received data; and d. Handling a conflict between said rule and said received data according to a conflict rule.