Patent Description:
Automation and alarm systems (such as home automation systems, fire alarm systems, and security systems) typically include one or more gateway entities (e.g., alarm panels) that receive information from various sensors distributed through a structured area. In response to particular types of input signals, the sensors or the gateway entity sometimes trigger an action by an output device. For example, a typical fire alarm system includes one or more sensors (e.g., smoke detectors or manually-actuated pull stations, etc.) and output devices (e.g., strobes, sirens, public announcement systems, etc.) operably connected to a gateway entity.

Conventionally, the gateway entity monitors electrical signals associated with each of the sensors for variations that may represent the occurrence of an alarm condition. For example, a variation in a particular electrical signal could represent the detection of smoke by a smoke detector in a corresponding area, or "zone," of a structure in which the smoke detector is located. In response, the gateway entity triggers an alarm mode. The gateway entity responds to such a condition by initiating certain predefined actions, such as activating one or more of the output devices within the monitored structure and/or notifying an external monitoring company.

The gateway entity has limited processing resources, and accordingly can become overwhelmed or slowed if tasked to process data from many sensors. As more sensors are added to the zones monitored by the gateway entity, the demands on the processing resources of the gateway entity grow. In environments with many sensors, this increased demand sometimes requires that additional and/or more powerful gateway entities are deployed, which results in increased cost, complexity, and maintenance requirements.

Furthermore, under some conditions the performance of a particular processing task exceeds the capabilities of the gateway entity. For example, some types of detectors monitor a window for the sound of glass breaking, and forward an audio file containing an anomalous sound to the gateway entity. If the anomalous sound is subtle, or is on the threshold of being classified as the sound of glass breaking, the gateway entity may not have the processing capabilities to accurately or efficiently analyze the sound.

To address some of these problems, existing gateway entities can be upgraded to provide additional processing resources. This solution imposes an additional burden of purchasing and installing the additional processing resources. Moreover, the amount of processing power installed in the gateway entity is typically calibrated to a worst-case processing scenario (i.e., a situation in which processing resources are stressed to a maximum degree). During normal operation, those processing resources might not be required and hence remain unused.

<CIT> is directed to methods and systems for content processing which include arrangements which involve using radio base station equipment to perform image recognition processing for connected devices. <CIT> is directed to a cloud gateway for coupling an industrial system to a cloud platform, wherein the cloud gateway is suitable for industrial automation information and control systems.

This disclosure addresses these and other issues with conventional alarm and automation systems. Some of the processing tasks performed by the system are performed at the sensor level, instead of at the level of the gateway entity. Other processing tasks, which exceed the capabilities of the gateway entity, are sent to a networked processing device (e.g., a processing device in the cloud), or another third-party device. Thus, a hierarchy of processing capabilities is provided, with the sensors forming a lower level, the gateway entity forming an intermediate level, and the cloud/third party processing devices forming a higher level.

By processing some of the data at the sensor level, the gateway entity's processing resources are conserved. Accordingly, the processing resources of the gateway entity (which has more processing resources, compared to the sensors) can be reserved for performing more complex analyses.

Additionally, by moving some of the processing from the gateway entity to the cloud or a third party location, still more complex algorithms can be carried out. Moreover, if a device at a higher level of the hierarchy determines that more information is needed to process received data, the higher-level device requests or is provided with additional information from other devices (e.g., other sensors in the vicinity of the sensor that initially reported an anomaly). This additional information allows for a more holistic analysis and/or response to an emergency situation.

The location at which the processing tasks are handled are established according to configuration settings that define filters, rules, thresholds, processing logic, or other criteria for each device. The configuration settings determine if a processing task is performed at a particular device in the hierarchy, and define when processing tasks should be forwarded for initial or further consideration by another device.

Different algorithms can be employed at different levels of the hierarchy. Thus, relatively simple data processing is performed at the sensor level, while more complicated algorithms are used at higher levels of the hierarchy. Furthermore, different algorithms can be used by devices at the same level of the hierarchy (e.g., different sensors at the sensor level can employ different detection algorithms). Therefore, similar devices deployed in different contexts (e.g., smoke detectors deployed at different locations) employ custom algorithms suited to the device's particular context.

New configuration settings are pushed throughout the architecture (e.g., from the cloud or a third party to the gateway entity, and from the gateway entity to the sensor, or directly from the cloud or a third party to the sensor). Thus, devices are dynamically customized and improved after they are deployed.

In a first embodiment, there is provided a method as set out in claim <NUM>. Optional features are set out in claims <NUM> to <NUM>. In a second embodiment, there is provided an apparatus as set out in claim <NUM>. Optional features are set out in claim <NUM>.

These and other embodiments are described in more detail below.

By way of example, specific exemplary embodiments of the disclosed system and method will now be described, with reference to the accompanying drawings, in which:.

This disclosure relates to a system architecture for automation and alarm systems, for which a hierarchy of processing capabilities is defined. Unlike conventional systems in which all of the processing is handled by a gateway entity, the exemplary system architecture moves processing tasks within the hierarchy in order to conserve resources, perform load balancing, and assign processing tasks to the devices that are best-suited to performing them.

<FIG> depicts an example of such a system architecture <NUM>. The system architecture <NUM> of <FIG> is intended to be illustrative only, and one of ordinary skill in the art will recognize that the embodiments described below may be employed in a system architecture having more, fewer, and/or different components than the system architecture <NUM> of <FIG>.

The system architecture <NUM> includes a monitored zone <NUM>. The monitored zone <NUM> represents a logical grouping of monitored devices, and may or may not correspond to a physical location defined by physical boundaries (e.g., a room or a building). The monitored zone <NUM> represents, for example, some or all of a residential home, a business, a school, an airport, etc..

The exemplary monitored zone <NUM> includes a number of sensors (sensor <NUM> and sensor <NUM>). Sensors include devices that measure or detect a physical property, such as temperature, pressure, the presence of light or smoke, or the position of a switch. A sensor translates the physical property into an electrical signal (e.g., using a transducer). Examples of sensors include environmental sensors (e.g., temperature sensors, pressure sensors, humidity sensors, light level sensors, etc.), status sensors (e.g., door and window switches, smoke detectors, movement detectors, valve status detectors, level indicators, flow level indicators, etc.), health sensors (e.g., heart rate sensors, blood flow sensors, sugar level sensors, body temperature sensors, etc.), location sensors (e.g., GPS transmitters or other location-based sensors placed on people, animals, property, etc.), as well as general- or multi-purpose sensors (e.g., microphones, cameras, manual pull switches, etc.).

The exemplary monitored zone <NUM> also includes an output device <NUM>. Output devices include devices that provide an output signal, such as a sound, light, vibration, or an instruction to take an action, in response to a condition. The condition that causes the output device to provide the output signal may be, for example, the detection of a particular output from a sensor (e.g., the signal from the sensor falling below, or rising above, a predefined threshold value, or the detection of a predefined pattern in the sensor data), or a trigger message sent to the output device by another device.

Examples of output devices include notification devices such as speakers, strobe lights, a motor that induces vibration in a mobile device, etc. Some types of notification devices are configured to provide an output perceptible by a human (e.g., a notification device that provides a visual, aural, haptic, or other human-perceptible output), while other types are configured to provide an output perceptible by a machine (e.g., a silent alarm that transmits a notification of a security incident to a server at a security company, or a fire call box that sends an alert to a fire department).

Other examples of output devices include devices that control other devices or objects. Examples of such output devices include devices that open or close a door, turn a light on or off, adjust a heating, ventilating, or air conditioning (HVAC) device, etc..

A gateway entity <NUM> monitors and controls the sensors <NUM>, <NUM> and the output device <NUM> of the monitored zone <NUM>. Gateway entities include devices that manage or oversee the devices of a monitored zone <NUM>, and which optionally communicate with devices outside of the monitored zone <NUM>. A single gateway entity <NUM> may include one or more devices. The exemplary gateway entity <NUM> processes input data received from the sensors <NUM>, <NUM> determines whether the sensor data indicates that an action should be taken, such as raising an alarm, and triggers the output device <NUM>. Examples of gateway entities <NUM> include dedicated control panels and local computing devices (such as personal computers or local servers).

The gateway entity <NUM> can be deployed in the monitored zone <NUM>, located near the monitored zone <NUM>, or located remotely from, while remaining communicatively connected to, the monitored zone <NUM>.

The embodiment of <FIG> includes a single monitored zone <NUM> controlled by a single gateway entity <NUM>. In other embodiments, each of multiple monitored zones may be controlled by distinct gateway entities, or the monitored zones may be collectively monitored by a single gateway entity.

The sensors <NUM>, <NUM> and the output device <NUM> are in communication with and operatively connected to the gateway entity <NUM>. The connection may be a wireless connection (e.g., through Wi-Fi or a low-power short-range radio communication technology) or a hard-wired connection (e.g., through copper or fiber optic communications cabling, or through a power line network).

The gateway entity <NUM> communicates with remote entities through a network <NUM>. A network <NUM> is a collection of two or more nodes and links between the nodes that allow communicated information to be passed between the nodes. A network <NUM> may be wired or wireless. Examples of a network <NUM> include computer networks (such as the Internet, a local area network, or a metropolitan area network), and telephone networks (such as landline telephone exchanges and wireless telecommunications networks).

A monitoring/reporting facility <NUM> receives information from the gateway entity <NUM> through the network <NUM>. A monitoring/reporting facility <NUM> is an entity that receives information about the status of sensors and/or monitored zones in the architecture <NUM>. The monitoring/reporting facility <NUM> can take an action in response to the information, such as logging the information for future use, aggregating the information with other information to generate a report, acknowledging emergencies, and dispatching first responders to the monitored zone <NUM>. Examples of monitoring/reporting facilities <NUM> include security companies, fire departments, doctors' offices and hospitals, and data storage centers.

An external zone <NUM> is also reachable via the network <NUM>. The external zone <NUM>, which is distinct from the monitored zone <NUM>, includes a sensor <NUM> and an output device <NUM>. In the example of <FIG>, the external zone <NUM> is indirectly reachable from the gateway entity <NUM> through the network <NUM>; however, in other embodiments the devices of the external zone <NUM> may be directly connected to the gateway entity <NUM> without the need to rely on an external network <NUM>.

A user <NUM> also communicates with entities in the architecture <NUM> via the network <NUM>. In the exemplary architecture shown in <FIG>, the user <NUM> is a subscriber to the monitoring/reporting facility <NUM>, which provides the user <NUM> with security oversight, emergency services, and reports about the status of the monitored zone <NUM>. In other embodiments, the user <NUM> may not be a subscriber to the monitoring/reporting facility, and the user's gateway entity <NUM> may have access to a more limited subset of entities in the architecture <NUM>.

The user <NUM> wears, carries, or otherwise interacts with a mobile sensor <NUM>. A mobile sensor <NUM> is a sensor that is configured to be moved from one location to another, and which typically includes an integrated, rechargeable power supply and a wireless (or decouplable wired) communication device. Examples of mobile sensors <NUM> include health devices (e.g., heart rate monitors, pedometers, blood-sugar monitors, etc.), wearable devices (e.g., smart watches and pendants), and location-services devices (e.g., global positioning system devices).

The user <NUM> also carries a mobile device <NUM>, such as a mobile phone or tablet. Using the mobile device <NUM>, the user <NUM> can monitor the status of the monitored zone <NUM> and/or devices in the monitored zone <NUM> and obtain reports from the monitoring/reporting facility <NUM>, among other actions. In some situations, the mobile device <NUM> may function as a gateway entity <NUM> by controlling or monitoring the mobile sensor <NUM> and/or the devices in the monitored zone <NUM>.

The devices of the system architecture <NUM>, including the gateway entity <NUM>, the mobile device <NUM>, sensors <NUM>, <NUM>, <NUM>, and <NUM>, output devices <NUM> and <NUM>, and monitoring/reporting facility <NUM> each includes some amount of processing power. A cloud- or third-party-processing device <NUM> augments the processing capabilities of the other devices in the architecture <NUM>. A cloud- or third-party-processing device is a device that is accessible to the gateway entity <NUM> through the network <NUM> and that provides additional processing capabilities that can be called upon by the gateway entity <NUM> or another device in the system architecture <NUM> in order to perform processing tasks. The could- or third-party-processing device <NUM> may be, but is not necessarily, operated by the same entity that operates the monitoring/reporting facility <NUM>.

According to the invention, the devices of the system architecture <NUM> are organized into a hierarchy for purposes of processing sensor data, updating a system status, and triggering output devices (among other possibilities). <FIG> depicts an example of a hierarchy <NUM> of devices in the system architecture <NUM>.

At a lower level <NUM> of the hierarchy <NUM>, sensors and output devices are grouped together. Sensors and output devices typically possess limited processing capabilities and limited power, and hence are poorly-suited to complex processing tasks. Nonetheless, such devices can be relied upon to perform relatively simple processing tasks.

Moreover, these devices are typically deployed in a specific context and/or are called upon to monitor a very particular type of input. For example, a glass break sensor is a type of sensor that employs a microphone to record sound (e.g., in the vicinity of a window), which is then analyzed in order to detect a predetermined pattern or signal indicative of the sound of breaking glass. Even if the glass break sensor has only limited processing capabilities, those capabilities can be employed to detect relatively simple glass-break patterns, thus reducing the need to process all the sound data from the glass break sensor at the gateway entity <NUM>.

If a device at the lower level <NUM> of the hierarchy <NUM> is unable to process some input data (or is not configured to do so), the device forwards the data to a device at the intermediate level <NUM> of the hierarchy <NUM>. The intermediate level <NUM> includes gateway entities, such as control panels, local computing devices, and (in some situations) mobile devices such as cell phones and tablets. Such devices typically have improved processing and power capabilities as compared to devices at the lower level <NUM>, which makes them well-suited to most processing tasks. Devices at the intermediate level <NUM> can perform more general-purpose analyses (as opposed to the special-purpose analyses performed at the lower level <NUM>) and/or perform more complex analyses as compared to the lower level <NUM>.

Devices at the intermediate level <NUM> may occasionally become overwhelmed in the presence of many data processing requests, or may encounter a processing task that is beyond its capabilities. In this case, processing tasks may be pushed up the hierarchy to the higher level <NUM>. At the higher level <NUM>, cloud- and third-party-processing devices perform complex tasks on behalf of the system.

It is noted that the connection between the lower level <NUM> (a sensor) and the intermediate level <NUM> (the gateway entity) will generally be well-defined and have a predictable number of "hops. " This allows real-time or near-real-time processing of sensor data by the gateway entity, because the path between the sensor and gateway entity is predictable and quality of service can be managed. On the other hand, reliability can decrease when moving data between the intermediate level <NUM> and the higher level <NUM>, because (e.g.) data may move over an external network for which quality of service cannot be guaranteed. Accordingly, some critical processes may preferably be handled at the lower level <NUM> or the intermediate level <NUM>, with less-critical processes (e.g., non-time-sensitive data analytics, etc.) handled at the higher level <NUM>.

Devices at different levels of the hierarchy <NUM> (and possibly different devices at the same level of the hierarchy <NUM>) include different logic for processing the same data. For example, a smoke detector at the lower level <NUM> and a gateway entity at the intermediate level <NUM> may both have logic for analyzing smoke detector data to determine if there is a fire in the monitored zone. However, the gateway entity's logic may be more sophisticated than the smoke detector's logic. Thus, the smoke detector and the gateway entity may process the same data and come to different conclusions. This capability may be advantageously leveraged to provide a targeted and sophisticated analysis of the data. If a device at a lower level of the hierarchy processes data and determines that it nearly, but does not quite, indicate the presence of an alarm condition (i.e., the results of the processing do not exceed an alarm threshold but do approach the threshold within a predefined tolerance), then the lower level device forwards the data to another device in the architecture that has a more sophisticated or different processing capability.

Moreover, different devices at the same level of the hierarchy <NUM> may have different logic for processing data. Accordingly, different devices can be made to employ location-dependent or context-sensitive processing logic. For example, a smoke detector deployed in a kitchen may be provided with logic for eliminating false alarms due to cooking, while a smoke detector deployed in a front hallway may omit this logic.

The logic deployed on a device can be dependent on the hardware configuration of the device. For example, a sensor having new or improved hardware may deploy more complex or specialized processing logic as compared to an older or simpler sensor. In addition to providing location- or context-sensitive processing, this capability allows a device at one level in the hierarchy <NUM> to forward data to another, more specialized device (possible via a gateway entity) when presented with data that can be better handled by the specialized device.

In addition to improved processing, another advantage of the hierarchy <NUM> is that improved configuration settings can be developed at the upper levels of the hierarchy <NUM> (e.g., the intermediate level <NUM> and the higher level <NUM>) and pushed down to lower levels of the hierarchy <NUM>. For example, if a sensor at the lower level <NUM> determines that input data nearly, but does not quite, rise to the level of an alarm condition, the sensor may forward the input data to a device at the intermediate level <NUM> for further processing. If the device at the intermediate level <NUM> determines that the data should have triggered an alarm condition, the device at the intermediate level <NUM> may review the configuration of the device at the lower level <NUM> to determine if one or more configuration settings should be changed so that the lower level device can better analyze input data in the future. For example, the device at the intermediate level might lower the alarm threshold of the lower level device, or might alter the algorithm employed by the lower level device based on the algorithm used by the intermediate level device or another device in the architecture <NUM>.

The structures of exemplary devices in the hierarchy, particularly an exemplary sensor <NUM> and an exemplary gateway entity <NUM>, are now described with reference to <FIG> and <FIG>.

The sensor <NUM> depicted in <FIG> includes a detector <NUM>. Detectors include devices that measure or identify a phenomenon and provide an output in response to the presence of the phenomenon, the absence of the phenomenon, or a change in the phenomenon. Examples of detectors include light or image sensors, microphones, thermometers/thermocouples, barometers, etc..

The output of the detector <NUM> is processed by a processor <NUM>. Processors <NUM> include devices that execute instructions and/or perform mathematical, logical, control, or input/output operations. The processor <NUM> of the sensor <NUM> may be a specialized processor having limited processing capabilities and designed to run in low-power environments. For example, the processor <NUM> of the sensor <NUM> may implement the Reduced Instruction Set Computing (RISC) or Acorn RISC Machine (ARM) architecture. Examples of processors <NUM> include the Atom™ family of processors from Intel Corporation of Santa Clara, California, the A4 family of processors from Apple, Inc. of Cupertino, California, the Snapdragon™ family of processors from Qualcomm Technologies, Inc. of San Diego California, and the Cortex® family of processors from ARM Holdings, PLC of Cambridge, England. The processor <NUM> may also be a custom processor.

The sensor <NUM> includes a power interface <NUM> for supplying electrical power to the components of the sensor <NUM>. The power interface <NUM> may be a connection to an external power source, such as a hard-wired connection to a house's or business' power supply. Alternatively or in addition, the power interface <NUM> may include an interface to a rechargeable or non-rechargeable battery, or a capacitor.

The exemplary sensor <NUM> engages in wireless and wired communication. Accordingly, the sensor <NUM> includes a communication interface <NUM> for managing communication between the sensor <NUM> and other entities in the architecture <NUM>. The communication interface <NUM> accepts incoming transmissions of information from the other entities in the architecture <NUM>, manages the transmission of information from the sensor <NUM> to the other entities, and provides quality control for data transmissions, among other communication-related functionality. The sensor <NUM> may connect to the network <NUM> through the communication interface <NUM>.

The communication interface <NUM> wirelessly communicates with the other entities of the architecture <NUM> using a radio transmitter/receiver <NUM>. The radio transmitter/receiver <NUM> modulates and demodulates electromagnetic signals carried wirelessly through a medium, such as the air or water, or through no medium (such as in space). In exemplary embodiments, the radio transmitter/receiver <NUM> of the sensor <NUM> may be a specialized radio transmitter/receiver that communicates over a relatively short range using relatively low power. Examples of lower-power radio transmitter/receivers <NUM> include devices communicating through short-wavelength ultra-high frequency (UHF) radio waves. Exemplary low-power radio transmitter receivers <NUM> may implement a communication protocol such as a ZigBee protocol from the ZigBee Alliance, the Bluetooth® Low Energy (BLE) protocol of the Bluetooth Special Interest Group, the Z-Wave protocol of the Z-Wave Alliance, the IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) protocol developed by the Internet Engineering Task Force (IETF), or a near field communications (NFC) protocol.

Alternatively or in addition, the sensor <NUM> could engage in wireless communication using other transmission/reception technologies, such as free-space optical, sonic, or electromagnetic induction.

The exemplary communication interface <NUM> also connects to a network interface <NUM> for interfacing with a wired communications network. The network interface <NUM> may be, for example, a network interface controller (NIC) for establishing a wired connection to a computer network such as the Internet, a fiber optic interface for connecting to a fiber optic network, a cable interface for connecting to a cable television network, a telephone jack for connecting to a telephone network, or a power-line interface for connecting to a power-line communications network.

Optionally, the sensor <NUM> may include an output device <NUM>. For example, a smoke detector may include a sensor for detecting the presence of smoke, and one or more output devices (e.g., a siren and a strobe light) that are triggered based on the output of the sensor.

The sensor <NUM> includes a memory <NUM> for holding data, instructions, and other information for use by the other components of the sensor. In exemplary embodiments, the memory <NUM> of the sensor <NUM> may be a specialized memory that includes relatively limited storage and/or uses relatively low power. The memory <NUM> may be solid-state storage media such as flash memory and/or random access memory (RAM). Examples of memory <NUM> include Secure Digital™ (SD) memory from the SD Association. The memory <NUM> may also be a custom memory.

The memory <NUM> includes a data buffer <NUM> for temporarily storing data from the detector <NUM> until the data can be processed by the processor <NUM> or transmitted using the communication interface <NUM>. The data buffer <NUM> may be, for example, a circular buffer. Data in the data buffer <NUM> may be processed on a first-in-first-out (FIFO) basis, a last-in-first-out (LIFO) basis, based on an importance of individual data units in the buffer, or based on a custom processing order. The data buffer <NUM> may be located at a fixed location in the memory <NUM>.

In addition to the data buffer <NUM>, the memory <NUM> includes a network buffer <NUM> for storing information transmitted or received via the communication interface <NUM>. The processor <NUM> assembles data for transmission by the communication interface <NUM>, and stores the data units in the network buffer <NUM>. The communication interface <NUM> regularly retrieves pending data from the network buffer <NUM> and transmits it towards its destination. Upon receiving data from another device of the architecture <NUM>, the communication interface <NUM> places the data in the network buffer <NUM>. The processor <NUM> regularly retrieves pending data from the network buffer and processes the data according to instructions stored in the memory <NUM> or hard-coded into the processor <NUM>. In order to distinguish between received data and data to be transmitted, the network buffer <NUM> may be subdivided into an "in" buffer and an "out" buffer. The network buffer <NUM> may be located at a fixed location in the memory <NUM>.

The memory <NUM> furthermore stores a configuration <NUM> including rules <NUM>, filters <NUM>, processing logic <NUM>, and configuration parameters <NUM>. A configuration <NUM> is a description of hardware and/or software present on a device. Rules <NUM> describe one or more actions that occur in response to one or more conditions. Filters <NUM> are logic that is run on input and/or processed data in order to determine a next action to take with the data (such as processing the data locally, saving the data in a log, or forwarding the data to another device for processing). Processing logic <NUM> provides instructions and/or parameters that operate on input data (or, in some examples, no input data) to generate new output data, transform the input data into new data, or take an action with respect to the input data or some other data. Processing logic <NUM> may be applied to the data generated by the detector <NUM> in order to take an action, such as raising an alarm, changing a security or monitoring state of the architecture <NUM>, operating an output device, etc. Configuration parameters <NUM> include values for settings that describe how the hardware and/or software of the configured device operates. The configuration <NUM>, rules <NUM>, filters <NUM>, processing logic <NUM>, and configuration parameters <NUM> are described in more detail in connection with <FIG>, below.

The sensor <NUM> depicted in <FIG> primarily communicates with the gateway entity <NUM>, which may be similar to the sensor <NUM> in terms of the types of components used. However, because there are fewer constraints on the gateway entity <NUM> in terms of size, location, and power consumption, the gateway entity <NUM> may have more and/or more powerful components than the sensor <NUM>. Typically, the gateway entity <NUM> is a panel or computing device located in or near the monitored zone <NUM>. In some situations, a user's mobile device <NUM> may function as a mobile gateway entity for some purposes (e.g., for processing data from the mobile sensor <NUM>). <FIG> is a block diagram depicting the structure of an exemplary gateway entity <NUM>.

The gateway entity <NUM> includes a processor <NUM>. The processor <NUM> of the gateway entity <NUM> may be one of the aforementioned processors <NUM> described in conjunction with the sensor <NUM>, above. In some embodiments, the processor <NUM> of the gateway entity <NUM> may be a Central Processing Unit (CPU) having one or more processing cores, one or more coprocessors, and/or on-chip cache.

In some embodiments, the processor <NUM> of the gateway entity <NUM> may be a specialized processor having improved processing capabilities as compared to the processor <NUM> of the sensor <NUM> and, as a result, may exhibit increased power consumption and/or heat generation as compared to the processor <NUM> of the sensor <NUM>. For example, the processor <NUM> of the gateway entity <NUM> may implement the Complex Instruction Set Computing (CISC) architecture. Examples of processors <NUM> include the Celeron®, Pentium®, and Core™ families of processors from Intel Corporation of Santa Clara, California, and the Accelerated Processing Unit (APU) and Central Processing Unit (CPU) processors from Advanced Micro Devices (AMD), Inc. of Sunnyvale, California.

The gateway entity <NUM> further includes a power interface <NUM>. The power interface <NUM> may connect directly to the power distribution system or power grid at the location in which the gateway entity <NUM> is deployed. The power interface <NUM> may include an interface for accepting alternating current (AC), direct current (DC), or both. The power interface <NUM> may include a converter for converting AC to DC, or vice versa. The power interface <NUM> may include a battery back-up in order to run the gateway entity <NUM> during power outages.

The gateway entity <NUM> includes a communication interface <NUM>, radio <NUM>, and network interface <NUM> similar to the respective components of the sensor <NUM>. The gateway entity <NUM> may be expected to communicate with more devices than the sensor <NUM>, and accordingly may be provided with more or more complex communication interfaces <NUM>, radios <NUM>, and network interfaces <NUM> than the sensor <NUM>. The gateway entity <NUM> may be assigned to a particular monitored zone <NUM>, and accordingly may maintain communication with each of the devices in the monitored zone <NUM> through the communication interface <NUM>. The gateway entity <NUM> may also connect to the network <NUM> through the communication interface <NUM>.

The gateway entity <NUM> includes a memory <NUM>. The memory <NUM> of the gateway entity <NUM> may be similar to the memory <NUM> of the sensor <NUM>, but typically exhibits greater storage space and/or improved performance (such as improved read/write times, improved seek times, and/or improved data redundancy or information backup capabilities). Examples of memory <NUM> suitable for use at the gateway entity <NUM> include random access memory (RAM), a hard disk drive (HDD), or a solid state drive (SSD), among other possibilities, or a combination of the same or different types of information storage devices.

The memory <NUM> provides a network buffer <NUM> similar to the network buffer <NUM> of the sensor <NUM>. The memory <NUM> also includes a storage area for sensor data <NUM>, which includes sensor data from each of the sensors in the monitored zone <NUM> overseen by the gateway entity <NUM> (e.g., first sensor data <NUM>, second sensor data, etc.). The sensor data <NUM> may be stored on a separate partition of the memory <NUM> as compared to other elements stored in the memory <NUM>.

The memory <NUM> of the gateway entity <NUM> also stores a configuration <NUM>, rules <NUM>, filters <NUM>, processing logic <NUM>, and gateway entity configuration parameters <NUM>. These elements may be similar in structure to the respective elements of the sensor <NUM>, although they may differ in content (e.g., different conditions and actions in the rules <NUM>, different ways to filter the data in the filters <NUM>, different instructions in the processing logic <NUM>, different values in the configuration parameters <NUM>, etc.).

As noted above, the gateway entity <NUM> forwards some data to a cloud- or third-party processing device <NUM> for further processing. The cloud- or third-party-processing device <NUM> has a structure similar to that of the gateway entity <NUM>. For the sake of avoiding redundancy, the structure of the cloud- or third-party-processing device <NUM> is not shown separately. The cloud- or third-party-processing device <NUM> may be deployed in a manner that allows qualitatively and quantitatively improved components, as compared to the gateway entity <NUM>. For example, the memory of the cloud- or third-party-processing device <NUM> may include several hard disk drives (HDDs) or solid state drives (SDDs), among other storage possibilities. The memory of the cloud- or third-party-processing device <NUM> may be arranged into a redundant array of independent disks (RAID) configuration for reliability and improved performance.

Moreover, the processor the cloud- or third-party-processing device <NUM> may be qualitatively or quantitatively more powerful than the processor <NUM> of the gateway entity <NUM>. For example, multiple processors <NUM> may be provided in the cloud- or third-party-processing device <NUM>, which may include more processing cores than the processor <NUM> of the gateway entity <NUM>. Furthermore, the processor(s) <NUM> of the cloud- or third-party-processing device <NUM> may be of a different, more powerful type than the processor <NUM> of the gateway entity <NUM>. For example, the cloud- or third-party-processing device <NUM> may employ a more powerful central processing unit (CPU) than the gateway entity <NUM>, or may employ more or better coprocessors than the CPU of the gateway entity <NUM>, or may employ a graphical processing unit (GPU) that is more powerful than the CPU of the gateway entity <NUM>.

As shown in <FIG>, the sensor <NUM>, gateway entity <NUM>, and cloud- or third-party-processing device <NUM> may interact with each other, and with other elements of the architecture <NUM>, in order to process sensor data. <FIG> is a system context diagram showing how, in an exemplary embodiment, entities of the system architecture <NUM> interact with each other according to an architecture management process <NUM>. The architecture management process <NUM> encompasses all of the steps or actions performed by the architecture <NUM> in order to process sensor data and manage the entities of the architecture <NUM>. The architecture management process <NUM> includes actions described in more detail in the flow charts of <FIG>.

The sensor <NUM> of the monitored zone <NUM> (also referred to herein as the "primary" sensor) generates input data for the architecture management process <NUM> using the detector <NUM>. Other devices, besides the sensor <NUM> of the monitored zone <NUM>, may also serve as a primary sensor in some embodiments. For example, the user's mobile sensor <NUM> may also locally process data, send status changes or unprocessed data to the architecture management process <NUM>, and receive configuration updates from the architecture management process <NUM>.

The input data is stored in the sensor's data buffer <NUM> until it can be processed by the processor <NUM>. The processor <NUM> retrieves the data from the data buffer <NUM> and makes an initial determination, based on a filter <NUM>, to either process the data locally or forward the data to another device in the architecture <NUM> for processing.

If the data is processed locally and results in a change in status of the architecture <NUM> (e.g., an alarm condition is indicated), the sensor <NUM> generates, as an output to the architecture management process <NUM>, a status change message. A status change message describes a change in the security or monitoring state of the architecture <NUM>. A status change message may indicate that the state should be escalated (e.g., "change from a no-alarm condition to an alarm condition," or "increment the security level from <NUM> to <NUM>," where level <NUM> indicates a higher state of vigilance than security level <NUM>). Alternatively, a status change message may indicate that the state should be de-escalated (e.g., "cancel an alarm condition" or "decrement the security level from <NUM> to <NUM>"). Still further, a status change message may set the state without reference to a previous state (e.g. "set the security level to <NUM>").

In some embodiments, the status change message includes characteristics of the sensor <NUM>, such as data from the sensor <NUM>, information about the configuration of the sensor <NUM> (e.g., details about the firmware, software, hardware, etc.), a model identification of the sensor <NUM>, the type of the sensor <NUM> (e.g., smoke detector, glass break sensor, etc.), or maintenance information (e.g., measurements of the resistance across various points in the circuitry of the sensor <NUM>, measurements of a battery level or network connectivity of the sensor <NUM>, power consumption of the sensor <NUM>, etc.).

If the data is processed locally and does not result in a change in the status of the architecture <NUM>, then no status change message is generated. Alternatively or in addition, a status change message reiterating the current state of the architecture <NUM> may be generated (e.g., at regular predefined intervals, or in response to a specific request from a sending device to process data at a receiving device).

If the processor <NUM> determines that the data cannot or should not be processed locally, then the sensor <NUM> generates, as an output to the architecture management process <NUM>, a message including the unprocessed data for processing by another device in the architecture <NUM>. Unprocessed data includes data (e.g., data generated by the sensor <NUM>) that is designated by the architecture management process <NUM> for processing by a device different than the device on which the unprocessed data presently resides.

Unprocessed data may include data that is partially processed by the device on which the unprocessed data presently resides. For example, the sensor <NUM> may perform partial processing of the data, and forward some or all of the raw data, along with processing results, to the architecture management process <NUM> as unprocessed data. In other embodiments, the unprocessed data may be completely processed by the sensor <NUM>, but may nonetheless be forwarded to another device for more consideration.

In some embodiments, the primary sensor (or the secondary sensor, described in more detail below), registers data with the detector <NUM> that is used for sound and speech recognition. For example, the detector <NUM> may receive speech data as an input and either locally process the speech data with the processor <NUM>, or forward the speech data to the architecture management process <NUM> as unprocessed data. The speech data may be used for voice recognition and/or authentication to the architecture <NUM>. For example, the speech data may be used to authenticate the user <NUM> when the user <NUM> enters the monitored zone <NUM>. If the user fails to authenticate, the primary sensor may send a status update to trigger an alarm condition indicating an unauthorized user's presence in the monitored zone <NUM>.

The sensor <NUM> receives, as output of the architecture management process <NUM>, configuration updates. Configuration updates include messages describing a change in the configuration <NUM> of the device to which they are addressed. For example, configuration updates may update rules <NUM>, filters <NUM>, processing logic <NUM>, and/or configuration parameters <NUM> of the affected device.

Configuration updates may be manually pushed to the sensor <NUM> by another entity in the architecture <NUM> (e.g., by the user <NUM> or the monitoring/reporting facility <NUM>). For example, a user <NUM> might wish to change the detection thresholds on one or more sensors in order to make them more sensitive; alternatively, a programmer at the monitoring/reporting facility <NUM> might develop a more advanced detection algorithm, and might wish to deploy the detection algorithm on selected sensors.

Configuration updates can also be automatically pushed to the sensor <NUM> by another entity in the architecture <NUM> as new configurations are developed. For example, if the sensor <NUM> processes data and decides not to trigger an alarm, but the architecture management process <NUM> determines that an alarm should have been triggered, the architecture management process <NUM> may automatically send a configuration update to the sensor <NUM> to lower the sensor's detection thresholds. Alternatively, if the architecture management process <NUM> determines that an alarm should not have been triggered by the sensor <NUM> (but was triggered), the architecture management process <NUM> may automatically send a configuration update to the sensor <NUM> to raise the sensor's threshold. In another example, the architecture management process <NUM> may determine that a sensor's configuration is out-of-date and that a more up-to-date configuration exists on another nearby sensor. The architecture management process <NUM> may send a configuration update to the out-of-date sensor based on the configuration of the up-to-date sensor.

Notably, the sensor may be delivered with features that are activated dynamically based on the context in which the sensor <NUM> operates (e.g., based on which other devices are accessible to the sensor <NUM>). For example, a sensor <NUM> that is not connected to other devices signals its state based on events detected by the sensor <NUM>. A sensor <NUM> that is connected to a gateway entity <NUM> receives data from other sensors accessible to the gateway entity <NUM> and reacts to the data holistically. A sensor <NUM> connected to the cloud-or-third-party processing device <NUM> through the gateway entity <NUM> reacts based on data history analytics provided by the cloud-or-third-party processing device <NUM> and the state of the other sensors connected to the gateway entity <NUM>.

The status changes and/or unprocessed data described above may result in a change in the security or monitoring state of the architecture <NUM>, or may cause a predefined action to be carried out. Such a change may be communicated to an output device <NUM> through a trigger message provided as an output of the architecture management process <NUM>. A trigger message is a message to an output device informing the output device of a change in the state of the architecture <NUM>, or instructing the output device to take an action (or both). For example, a trigger message may inform the output device that the architecture <NUM> is in an alarm configuration, and internal rules of the output device may provide a particular type of notification in response. Alternatively or in addition, the trigger message may instruct the output device to perform a task (such as sounding an alarm or changing a temperature setting in the monitored zone <NUM>).

Configuration updates may also be sent to the output device <NUM> as an output of the architecture management process <NUM>. The configuration updates may change configuration settings of the output device <NUM>.

The architecture management process <NUM> interacts with sensors and output devices distinct from the sensor <NUM> and output device <NUM> of the monitored zone <NUM>. For example, if the unprocessed data forwarded by the sensor <NUM> of the monitored zone <NUM> is insufficient to trigger an alarm condition or a change in the state of the architecture <NUM>, but the architecture management process <NUM> determines that further consideration of the data is required, the architecture management process <NUM> sends a request for supplemental data to a sensor <NUM> in the external zone <NUM>. Such a sensor is referred to herein as a secondary sensor.

The secondary sensor receives, as an output of the architecture management process <NUM>, requests for supplemental data. In response to the requests, the secondary sensor provides, as an input to the architecture management process <NUM>, data from the secondary sensor's own detector <NUM> or from the secondary sensor's data buffer <NUM>.

The secondary sensor that provides supplemental data to the architecture management process <NUM> need not necessarily be located in the external zone <NUM>. The secondary sensor could be another sensor in the monitored zone <NUM>, distinct from the primary sensor (e.g., the sensor <NUM>). The secondary sensor may also be the mobile sensor <NUM> of the user <NUM>.

The data from the secondary sensor is considered in conjunction with the unprocessed data provided by the primary sensor. When the combined data is evaluated holistically, a different determination can be made regarding whether to change the state of the architecture or trigger follow-up actions. For example, if the primary sensor data indicates that smoke may be present in a room (but perhaps does not rise to the threshold to generate an alarm), a nearby temperature sensor such as a thermometer in a thermostat may be consulted to determine if the temperature in the room is abnormal. If so, an alarm may be triggered.

The supplemental data from the secondary sensor may also be used to screen out false positives from the primary sensor. For example, if a glass break sensor detects a sound that seems to be a glass break, but a secondary sensor (e.g., a weather sensor) indicates that a thunderstorm is moving through the area, then supplemental data from the secondary sensor may be considered in determining whether to send an alarm or change the status or monitoring state of the architecture <NUM>. In some embodiments, the gateway entity <NUM> may require corroboration of a positive result from a primary sensor, if the secondary sensor data indicates a risk that the result is a false positive.

Moreover, data from secondary sensors may be used to improve the detection capabilities of primary sensors. For example, if a primary glass break sensor records a sound that could be the sound of a window breaking, but the sound is distorted by extraneous noise, data from a secondary sensor (such as the microphone on a nearby video camera) could be used to filter out the extraneous noise and provide a clearer signal.

Still further, the additional information from the secondary sensor may be used to trigger additional actions. For example, if a smoke detector detects the presence of a fire in a house, and a motion sensor reports that a person is moving in the house, the resulting fire alarm may be escalated to a higher response level, and the presence of a person in the house may be reported to the responding fire department. In another example, the sensitivity or threshold for a particular outcome may be changed based on the additional information: in the above example, the presence of a person in the house as reported by the motion detector might cause the system to become less conservative in triggering a fire alarm under questionable or unclear circumstances.

The architecture management process <NUM> can leverage the processing capabilities of the secondary sensor. Because each device of the architecture <NUM> can be operated in a different configuration, each device may have customized logic or different thresholds that may be better suited to processing certain kinds of data. For example, a window-break sensor in a kitchen may have relatively simple detection logic programmed with a relatively high threshold for an alarm condition, in order to screen out false positives caused when a user <NUM> drops a glass or plate in the kitchen. A window-break sensor in a front hallway, on the other hand, may have specialized detection logic that has been recently customized with an advanced algorithm for detecting window breaks. If the sensor in the kitchen registers a noise that could represent a burglar breaking the kitchen window, but the sensor (and/or the gateway entity associated with the sensor) is unable to definitively classify the noise as such, then the architecture management process <NUM> may forward the kitchen sensor's unprocessed data to the front hallway sensor for specialized processing.

Accordingly, the architecture management process <NUM> provides, as an output to the secondary sensor <NUM>, unprocessed data from other sensors. The secondary sensor <NUM> processes the data based on its own configuration <NUM>, and determines whether to generate a status change as an input to the architecture management process <NUM>.

Like the output device <NUM> of the monitored zone <NUM>, data from the primary sensor and/or the secondary sensor is used to trigger output devices <NUM> in the external zone <NUM>. These output devices <NUM> may also receive configuration updates in the same manner as the output device <NUM> of the monitored zone <NUM>. Accordingly, the architecture management process <NUM> provides, as an output to the output device <NUM> of the external zone <NUM>, triggers and configuration updates. For example, assume that the monitored zone <NUM> represents a first apartment in an apartment building, and the external zone <NUM> represents a second apartment, located near the first apartment in the building. If data from the sensor <NUM> in the monitored zone <NUM> indicates the presence of a fire or burglar in the first apartment, an output device <NUM> (e.g., siren) may be triggered in the second apartment.

The monitoring/reporting facility <NUM> monitors the state of the devices and zones of the architecture <NUM> for conditions that require further action (such as dispatching emergency services or contacting the user <NUM>). Accordingly, the monitoring/reporting facility <NUM> is provided with, as an output of the architecture management process <NUM>, status changes indicative of any change in the security or monitoring state of the architecture <NUM>.

The monitoring/reporting facility <NUM> can serve (along with the cloud- or third-party processing device <NUM>) as a point of contact with the architecture for purposes of pushing centrally-developed configuration changes to the devices of the architecture <NUM>. Accordingly, the monitoring/reporting facility may provide configuration updates as an input to the architecture management process <NUM>.

The cloud- or third-party processing device <NUM> provides additional processing capabilities for the architecture <NUM>. In order to use these additional processing capabilities, the architecture management process <NUM> sends, as an output, unprocessed data to be processed at the cloud- or third-party processing device <NUM>. If the cloud- or third-party processing device <NUM> determines that supplemental data from additional sensors is required, the cloud- or third-party processing device <NUM> transmits, as an input to the architecture management process <NUM>, a request for supplemental data.

The cloud- or third-party processing device <NUM> processes the received data and makes a determination (e.g., to change the security or monitoring state of the architecture <NUM>) based on the data. Accordingly, the cloud- or third-party processing device <NUM> may transmit, as an input to the architecture management process <NUM>, a status change message describing how to change the state of the architecture <NUM>. The cloud- or third-party processing device <NUM> may also transmit "null" status messages, indicating that the security or monitoring state of the architecture <NUM> does not need to be changed in response to the data.

In some embodiments, the cloud- or third-party processing device <NUM> determines that the configuration of one or more devices in the architecture <NUM> should be updated. Accordingly, the cloud- or third-party processing device transmits, as an input to the architecture management process <NUM>, a configuration update to be applied at one or more devices accessible to the architecture management process <NUM>.

The cloud- or third-party-processing device <NUM> also serves as a point of contact for a user <NUM> located outside of the communications range of the gateway <NUM>, who wishes to receive reports regarding the status of devices in the monitored zone <NUM>. For this purpose, the user <NUM> submits, via the user's mobile device <NUM>, a request for a status report. The request is sent as an input to the architecture management process <NUM>. The cloud- or third-party processing device <NUM> receives, as an output of the architecture management process <NUM>, a request for the status of a device or zone.

In response, the cloud- or third-party processing device <NUM> generates requests for information to be forwarded to, for example, the gateway entity <NUM> associated with the device or zone, and provides these requests as an input to the architecture management process <NUM>. The gateway <NUM>, or another device, processes these requests and the cloud- or third-party processing device <NUM> receives, as an output of the architecture management process <NUM>, status reports describing the status of the device or zone. The cloud- or third-party processing device <NUM> provides, as an input to the architecture management process <NUM>, a status report derived from information in the configuration <NUM> of the relevant device, or of multiple devices in a zone, or from multiple zones. The report is forwarded to the user device <NUM> that submitted the original request.

Each of the devices of the architecture <NUM> interacts, directly or indirectly, with the gateway entity <NUM>, which functions as a central hub or facilitator. Among other functions, the gateway entity <NUM>: processes data from the sensors in the architecture <NUM>; forwards unprocessed data to other devices that are better-suited to process the data; transmits status changes to the monitoring/reporting facility <NUM>; requests supplemental data from secondary sensors; triggers output devices; receives configuration updates from the architecture management process <NUM>; applies configuration updates on the gateway entity <NUM> and/or forwards configuration updates to devices communicatively coupled to the gateway entity <NUM>; and processes status report requests from user mobile devices <NUM> and cloud- or third-party processing devices <NUM>. In some embodiments, the gateway entity <NUM> may expose one or more Application Program Interfaces (APIs) to the other devices in the architecture <NUM> for these purposes.

The architecture management process <NUM> accepts the inputs from the various devices as shown in <FIG>, and processes the inputs to generate outputs. As part of the architecture management process <NUM>, a number of different data structures may be employed. Exemplary data structures suitable for use with embodiments of the invention are described below with reference to <FIG>.

<FIG> shows an exemplary configuration update <NUM> that is used to update the configuration <NUM> of one or more devices in the architecture <NUM>.

The configuration update <NUM> includes a header <NUM> that identifies, among other things, the destination for the configuration update <NUM>. In some embodiments, the header <NUM> identifies specific devices on which the configuration update <NUM> should be deployed. Alternatively or in addition, the header <NUM> may identify a class of devices on which the configuration update <NUM> should be deployed (e.g., all smoke detectors).

In some embodiments, the header <NUM> also includes other information, such as a timestamp, a priority, and a checksum. The timestamp identifies the time at which the configuration update <NUM> was sent, which may be used to order configuration updates arriving in succession. In some cases, two configuration updates may conflict with each other, thus requiring that one configuration update override the other. The timestamp can be used to determine which configuration update was sent first (under the assumption that the latter configuration update was meant to override the former). If a first configuration update was transmitted before a second configuration update, then in some embodiments the later (second) configuration update is applied and overrides the first configuration update, regardless of the order in which the configuration updates are received at the device to be configured.

In some embodiments, a priority value is used to determine which configuration update should override other configuration updates. For example, if a first configuration update is received having a high priority and is applied at a configured device, the configured device may decide not to apply a subsequent conflicting configuration update having a lower priority.

A checksum in the header <NUM> is used to verify that the configuration update <NUM> was received correctly and not garbled in transmission. The checksum is applied at the transmitting device by calculating a checksum value over the payload of the configuration update <NUM>, using any of a number of well-known checksum algorithms. The calculated checksum is added to the header <NUM>. Upon receipt of the configuration update <NUM>, a checksum value is calculated over the payload of the configuration update <NUM>, and is compared to the checksum in the header <NUM>. If the two checksums match, then the configuration update <NUM> is determined to have been received successfully. If the two checksums do not match, then the receiving device determines that an error occurred in transmission or reception, and requests that the configuration update <NUM> be re-transmitted.

The different elements in the configuration update <NUM> may be separated by a designated character (such as an End of Line character, or a comma, or any other suitable character). When the configuration update <NUM> is parsed by the receiving device, the receiving device may separate the different elements based on the designated characters, and may modify the corresponding elements of the configuration <NUM> of the configured device. Alternatively or in addition, the different elements in the configuration update <NUM> may be provided at predefined locations in the configuration update, or may have a predefined size, or may have a variable size that is reported in the header <NUM>. Upon receiving the configuration update <NUM>, the receiving device may separate the elements of the configuration update based on their position in the message and/or size.

Although the configuration update <NUM> is shown with updated rules <NUM>, filters <NUM>, processing logic <NUM>, and configuration parameters <NUM>, some of these items may be omitted from the configuration update <NUM>. For example, if only the rules <NUM> (or a portion of a rule <NUM>) are updated in a given configuration update <NUM>, then the remaining items are omitted from the configuration update. The header <NUM> indicates which elements are updated in a given configuration update <NUM>.

Moreover, the exemplary configuration update <NUM> is shown with sensor configuration parameters <NUM>. However, the configuration update <NUM> may include configuration parameters specific to the device on which the configuration update <NUM> is to be deployed. For example, if the configuration update <NUM> is destined for a gateway entity <NUM>, then the configuration update may include gateway configuration parameters <NUM>.

An example of a rule <NUM> suitable for use in a configuration <NUM> or configuration update <NUM> is shown in <FIG>. The rule <NUM> attempts to match a set of conditions <NUM>, as defined in the rule <NUM>, to conditions in the architecture <NUM>. When the set of conditions <NUM> is met, then one or more actions <NUM> are triggered.

A condition is a predefined set of states, statuses, or value for parameters that a device attempts to match against states, statuses, or parameters in the architecture <NUM>. Examples of conditions <NUM> include matching a state of the architecture or a device to a predefined value or value range (e.g., the current security level is <NUM>, <NUM>, or <NUM>; the smoke detector is in an "alarm" mode). Multiple states may be matched in a single condition (e.g., two smoke detectors separated from each other by more than a predefined distance are in an "alarm" mode; a glass break sensor is tripped and a motion detector detects motion in the room). One or more of the conditions <NUM> may be time-based (e.g., the current time is <NUM>:<NUM> AM; the current time is between <NUM>:<NUM> PM and <NUM>:<NUM> AM).

The set of conditions <NUM> may be an empty set (i.e., no conditions), in which case the action <NUM> is carried out immediately upon receiving the rule <NUM>, and subsequently discarded. Alternatively, custom logic may be applied to define how to carry out rules having no associated conditions <NUM>.

Some or all of the conditions <NUM> may be specified using logical operators such as AND, OR, XOR, NOT, etc. For example, the rule <NUM> may specify that the first condition <NUM> and the second condition <NUM> must both be met for the action <NUM> to be triggered. Alternatively, the rule <NUM> might specify that either the first condition <NUM> or the second condition <NUM> must be met to trigger the action <NUM>.

When the set of conditions <NUM> is matched to a current status of the architecture <NUM> or device(s), the action <NUM> specified in the rule is carried out. An action <NUM> is a set of one or more instructions or tasks to be carried out by the device on which the rule <NUM> is triggered. Examples of actions <NUM> include performing a task locally (e.g., trigger an integrated notification device; process additional data) and forwarding instructions to other devices (e.g., send a status update to the gateway <NUM>, escalating the security level of the architecture <NUM>; trigger the dishwasher to start running).

A rule <NUM> can specify a number of times that the rule is to be carried out. This may be done, for example, by specifying a maximum number of applications as one of the conditions <NUM>, and tracking the number of times that the rule <NUM> has caused the action <NUM> to be triggered. Upon reaching the maximum number of applications, the rule <NUM> is discarded.

In addition to rules <NUM>, the configuration update <NUM> specifies filters <NUM>. Two examples of filters <NUM> are shown in <FIG> depicts an exemplary processing determination filter <NUM>, which is a pre-processing filter applied to data present on a local device to determine if the data should initially be processed locally, or forwarded to a different location in the architecture <NUM> for processing. <FIG> depicts an exemplary escalation filter <NUM>, which is a post-processing filter applied after data is processed locally in order to determine if the data should be further processed by other devices in the architecture <NUM>.

As shown in <FIG>, the processing determination filter <NUM> includes evaluation logic <NUM>. The evaluation logic <NUM> accepts input data and/or contextual information about the data (e.g., the type of sensor(s) that generated the data, the location at which the sensor(s) were deployed, any initial processing that has been done on the data, etc.) and evaluates the data to determine whether the data should be processed locally.

The exemplary evaluation logic <NUM> evaluates the input data and/or contextual information against one or more thresholds <NUM> to determine whether the data should be processed locally. A threshold <NUM> represents a magnitude or intensity that must be met or exceeded in order for a given result to occur. In the example of the evaluation logic, the thresholds <NUM> represent dividing lines which cause certain predefined actions to be performed depending on whether a measured parameter falls on one side or the other of the threshold <NUM>.

In the exemplary processing determination filter <NUM>, the data is compared against a complexity threshold <NUM>. A complexity threshold <NUM> represents a maximum complexity that the local device is capable of tolerating in data while still being capable of efficiently processing the data. In the exemplary embodiment, the evaluation logic <NUM> analyzes the data and the contextual information about the data, and assigns a complexity score to the data. The complexity score may be calculated by considering the type of sensor the data originated from, the amount of the data, whether the data values are stable or variable, whether the data is clear or noisy, whether the data includes any immediately recognizable patterns, etc..

If the complexity score meets or exceeds the complexity threshold <NUM>, then the evaluation logic <NUM> determines that the data is too complex for processing at the local device. If the complexity score is below the complexity threshold <NUM>, then the evaluation logic <NUM> determines that the local device is capable of processing the data.

The evaluation logic <NUM> also uses a load threshold <NUM> to perform load balancing. Load balancing refers to the distribution of tasks, jobs, or other work among multiple computing resources. In the exemplary embodiment, the evaluation logic <NUM> compares a load on the local processor(s) (e.g., a percentage of local processing resources currently being utilized, a number and/or complexity of jobs currently being processed, etc.) to the load threshold <NUM>. If the current load meets or exceeds the load threshold <NUM> then the evaluation logic <NUM> may determine that the processing task under consideration should be processed elsewhere. If the current load is below the load threshold <NUM>, then the evaluation logic <NUM> may determine that the processing task should be performed locally.

The evaluation logic <NUM> can be programmed with a list of accessible devices having computing resources available for use, and an indication of the types of processing tasks the devices specialize in. If the evaluation logic <NUM> determines that a processing task should be forwarded to another device in the architecture, the evaluation logic <NUM> may consult the list to select an appropriate destination device.

The devices in the list can be associated with a priority indicating the order in which processing tasks should be sent to the listed devices. For example, among devices specializing in a particular type of data (e.g., smoke detector data), the devices can be ranked in order of priority. The next processing task received for that particular type of data may be sent to the highest-priority device in the list. A query may be sent to the highest priority device to determine whether the highest priority device is capable of performing a new processing task. If the highest priority device responds by acknowledging its willingness to perform the task, the data may be sent to the highest priority device for processing. If the highest priority device responds by rejecting the processing request, the local device may proceed to the next-highest priority device in the list. This process may be repeated until an appropriate device is selected.

Devices in the list may exchange messages (e.g., through the gateway entity <NUM>) in order to change their priority ranking on other devices. For example, if a given device is assigned a large number of processing tasks and its processing load approaches to within a predefined tolerance of the device's load threshold <NUM>, the overloaded device may send a message to the gateway entity <NUM> requesting that the overloaded device's priority be lowered in the evaluation logic <NUM> of other devices in the architecture <NUM>. Accordingly, other devices will be less likely to send processing tasks to the overloaded device. When the overloaded device's processing load drops to a predefined level (or after a predetermined amount of time), the device's priority may be raised.

A local device may also change a remote device's priority in the local device's evaluation logic <NUM> as the local device assigns tasks to the remote device. For example, if a gateway entity <NUM> sends a processing job to a first sensor <NUM>, the gateway entity <NUM> may lower the priority of the first sensor so that the next task is sent to a second sensor <NUM>. Thus, the gateway entity <NUM> can distribute tasks more uniformly.

The list may also include a default device located at the next-highest level of the hierarchy <NUM> (as compared to the local device that is currently preparing to re-assign the processing task) to which tasks may be forwarded if no other device is identified. For example, the default device at the intermediate level <NUM> of the hierarchy <NUM> can be the gateway <NUM>, and the default device at the higher level <NUM> of the hierarchy <NUM> can be the cloud- or third-party processing device <NUM>.

In addition to determining whether the data should be processed locally or remotely, the processing determination filter <NUM> also applies a reporting ruleset <NUM> to any received data to determine whether the data should be logged in a local memory, forwarded to other specified devices in the architecture <NUM>, or processed and discarded. The reporting ruleset <NUM> matches conditions <NUM> such as a type of data, an interval of time at which data should be recorded, recognized patterns in the data, etc. against the input data (potentially after the data is processed by the evaluation logic <NUM>). If the conditions <NUM> match the data, the reporting ruleset <NUM> applies an action <NUM> such as storing the data in a local memory (e.g., the memory <NUM> of the sensor <NUM>, or the memory <NUM> of the gateway entity <NUM>) or forwarding the data to a device specified in the action <NUM>.

If the processing determination filter <NUM> determines that the data should be processed locally, the data is processed according to the processing logic <NUM> of the local device. After processing by the processing logic <NUM>, the device applies an escalation filter <NUM>, as shown in <FIG>, to determine if the data should also be escalated to another device for further processing.

The escalation filter <NUM> is applied if the processing logic <NUM> decides to take any action, decides to take a specific action (such as raising an alarm), decides to take no action, or any combination of possibilities.

The escalation filter <NUM> has evaluation logic <NUM> that determines whether processed data should be escalated by being further processed at another device. The evaluation logic <NUM> decides to escalate the data for further processing if the processing logic <NUM> is unable to process the data. For example, if the data is voice data that includes commands, and the processing logic <NUM> is unable to identify the commands in the voice data with a high degree of confidence, the evaluation logic <NUM> may escalate the data for further processing at a higher level of the hierarchy <NUM>.

The evaluation logic <NUM> consults a threshold <NUM>, such as an escalation threshold <NUM>, in order to determine if the data should be escalated. In one exemplary embodiment, the escalation threshold <NUM> applies when the processing logic <NUM> determines not to take an action, but was within a predefined tolerance of taking the action (suggesting that the determination may be a false negative). Alternatively or in addition, the escalation threshold <NUM> applies when the processing logic <NUM> determines to take an action, but was within a predefined tolerance of not taking the action (suggesting that the determination result may be a false positive). The escalation threshold <NUM> is a value or range of values defining these tolerances.

For example, the processing logic <NUM> may trigger an alarm at an output device <NUM> if the value v of sensor data from a sensor rises above a predefined alarm threshold a. The escalation threshold may be set to a value e. If the sensor data value v rises above a, the processing logic <NUM> will trigger the alarm. If the sensor data value v is at or below the value a - e, then the processing logic <NUM> will determine that no alarm should be triggered, and the escalation filter <NUM> will not escalate the data for further processing by another device. If the sensor data is in a range {a-e < v < a}, then the processing logic <NUM> will not trigger the alarm, but the escalation filter <NUM> will forward the data to another device for further processing.

The escalation threshold <NUM> is modified by security level modifiers <NUM>. The security level modifiers <NUM> represent a value or values used to raise or lower the escalation threshold <NUM>, depending on the current security level or state of the architecture <NUM> (or one or more zones <NUM> in the architecture <NUM>). As the security level or state changes, the security level modifiers <NUM> modifies the escalation threshold <NUM> to make the evaluation logic <NUM> more or less prone to escalating the data. For example, if the security level is elevated, the evaluation logic <NUM> may be made more likely to escalate the data for further processing. If the security level is relatively low, the evaluation logic <NUM> may be made less likely to escalate the data.

In a further embodiment, the evaluation logic <NUM> applies pattern recognition and escalates the data if a particular pattern is identified in the data, regardless of whether the processing logic <NUM> decided to take an action in response to the data.

The evaluation logic <NUM> of the escalation filter <NUM> selects a device to which the data should be forwarded in a manner similar to the way that the evaluation logic <NUM> of the processing determination filter <NUM> selects a device to which the data should be forwarded. The criteria for the evaluation logic <NUM> may also be different than the criteria for the evaluation logic <NUM>.

Either or both of the processing determination filter <NUM> and the escalation filter <NUM> may decide to escalate processing of the data to another device based on whether the data requires a critical decision (e.g., a real-time or near-real-time decision). In order to determine whether to process data requiring a critical decision locally or remotely, the respective filters may estimate a processing time for each prospective processing device, which includes the time to process the data and the time to transmit the data to and from the processing device. The filters may also calculate a connection reliability (e.g., based on connection speed, connection uptime, and momentary available bandwidth). If the filters determine that a critical decision can be made by one device but not another, then the filters may select the appropriate device to process the data. If either device is capable of processing critical data, then the escalation decision may be made based on other factors, as described above.

The post-processing logic <NUM> is applied following processing of the data by the processing logic <NUM>. An example of processing logic <NUM> is shown in <FIG>.

The processing logic <NUM> includes evaluation logic <NUM>. The evaluation logic <NUM> accepts input data, such as data from a detector <NUM> of a sensor <NUM>, or aggregated data from multiple sensors, and processes the data to transform the data into new output data, modify existing data, or perform an action. The processed data is compared to a threshold <NUM>, such as a triggering threshold <NUM>. The triggering threshold <NUM> defines a value that, if the value of the input data rises above or falls below, causes an action to be performed. The evaluation logic <NUM> also applies pattern matching to the data to determine whether to take the action.

The input data and/or processed data is also compared to a triggering ruleset <NUM>. The triggering ruleset <NUM> defines rules <NUM> in which the conditions <NUM> relate to the data being processed. For example, one rule of the triggering ruleset <NUM> may indicate that, if the data includes a pattern indicative of a person returning home, an output device <NUM> such as a light should be turned on. Another rule of the triggering ruleset <NUM> may relate to sending a status update or notification to another device, such as the user's mobile device <NUM>, the cloud- or third-party processing device <NUM>, or the monitoring/reporting facility <NUM>.

The rules of the triggering ruleset <NUM> can be location-dependent (e.g., by including location information as one of the conditions <NUM>). For example, if the rule is a rule that is triggered by a fire alarm and triggers an action <NUM> of turning on a sprinkler system, one of the conditions of the rule may be that the sprinklers should not be triggered until absolutely necessary if the output device (sprinkler) is in a computer lab or server room.

Turning now to the configuration parameters <NUM>, <NUM>, exemplary parameters for gateway entity <NUM> and the sensor <NUM> are depicted in <FIG>, respectively.

<FIG> depicts configuration parameters <NUM> for deployment on a gateway entity <NUM>. The configuration parameters <NUM> specifies a list of connected devices <NUM>. The list of connected devices <NUM> includes an identifier for each device that is (or should be) communicatively coupled to the gateway entity <NUM>, as well an indication of the type of each device. The identifier may be an address of the device (e.g., an IPv6 address). The list of connected devices <NUM> includes devices that the gateway entity <NUM> is responsible for overseeing (e.g., the sensors <NUM>, <NUM> and output device <NUM> of the monitored zone <NUM>), as well as other devices with which the gateway entity <NUM> is capable of communicating (e.g., the cloud- or third-party processing device <NUM> and the monitoring/reporting facility <NUM>).

The configuration parameters <NUM> includes a list of device conditions <NUM> representing the status of the devices in the list of connected devices <NUM>. The status of the devices reflects any, or a combination, of communication status (e.g., communicatively connected to the gateway entity <NUM> and/or the network <NUM>), device maintenance status (e.g., a battery level of the device, whether the device is scheduled for maintenance, whether the device is reporting abnormal data, etc.), a configuration status of each device (e.g., a list of the configuration ID(s) <NUM> for each device) and other statuses.

The list of device conditions <NUM> includes the condition of the gateway entity <NUM> itself, as well as a condition <NUM> for each sensor and a condition <NUM> for each output device overseen by the gateway entity <NUM>. The status conditions may be reported by each device in response to a query from the gateway entity <NUM>, at regular intervals, or may be updated by the gateway entity <NUM> (e.g., in response to not receiving a reply or an expected update from the device).

The configuration parameters <NUM> include expected value ranges <NUM> for the configured device. The expected value ranges represent a range of values for one or more operational parameters or characteristics of the configured device which indicate normal operation of the device. If the device generates an operational parameter or exhibits a characteristic outside of the expected value ranges <NUM>, this may indicate a malfunction of the configured device requiring maintenance. The configuration parameters may, accordingly, include a maintenance ruleset with a set of rules <NUM> to be applied when one or more operational parameters or characteristics falls outside of the expected value ranges <NUM>. The maintenance ruleset <NUM> may specify actions, such as performing diagnostic tests, reporting a malfunction to the monitoring/reporting facility <NUM> or the user <NUM>, or performing maintenance operations (such as rebooting the device, using alternative hardware or software if available, or restoring the device to a last-known-good configuration).

The configuration parameters <NUM> also include a security ruleset <NUM> including rules <NUM> that specify actions to be taken in the event that an alarm condition is raised or the security level <NUM> of the architecture <NUM> changes.

The security level <NUM> represents a level of vigilance or a monitoring state of the architecture <NUM> or a portion of the architecture <NUM>. The security level <NUM> may be specified as a quantitative value (e.g., level <NUM>, level <NUM>, etc.), or may be specified as a set of "modes. " Examples of "modes" are shown in Table <NUM> below:.

The security ruleset <NUM> includes default actions to be taken whenever the security level <NUM> is in a particular status. For example, if the security level <NUM> is set to the "emergency" mode, the security ruleset <NUM> may cause requests for data to be repeatedly sent to a relevant sensor.

The configuration parameters <NUM> deployed on the device may be customized to the device, to the location in which the device is deployed, and/or based on other considerations. In order to identify which configuration is present on which device (which may be used, for example, to determine whether a particular device is well-suited to processing certain kinds of data), the configuration parameters <NUM> may be associated with one or more configuration ID(s) <NUM>. The configuration ID(s) <NUM> may be, for example, a checksum, and identification string, or a series of flags uniquely identifying a part or all of a set of configuration parameters <NUM>.

The configuration parameters <NUM> also include default configuration settings <NUM>. The default configuration settings <NUM> are settings for some or all of the configuration parameters <NUM> that are applied in certain conditions, such as when the device is started or restarted, or when a configuration parameter <NUM> is corrupted or otherwise rendered unusable. As configuration updates <NUM> are received, the default configuration settings <NUM> may optionally be updated with the new configuration settings contained in the update <NUM>.

As shown in <FIG>, the configuration parameters <NUM> for deployment on a sensor <NUM> are similar to the gateway entity configuration parameters <NUM>. Because the sensor <NUM> is not typically responsible for overseeing other devices in the architecture <NUM>, some of the elements from the gateway entity configuration parameters <NUM> may be eliminated in the sensor configuration parameters <NUM>.

The rules <NUM>, filters <NUM>, processing logic <NUM>, and configuration parameters <NUM>, <NUM> are applied by devices in the architecture to process input data from one or more sensors <NUM>. Methods performed by the devices in the architecture <NUM> will next be described with reference to <FIG>.

<FIG> is a data flow diagram showing a flow of data through the architecture <NUM>. For clarity of discussion, <FIG> focuses primarily on the above-described data processing and configuration updating aspects of the architecture management process <NUM>. Other processes, such as the reporting mechanisms discussed above, are omitted from the data flow diagram.

Initially, the primary sensor <NUM> generates sensor data and performs a filtration process <NUM> to determine whether to process the sensor data locally (at the primary sensor <NUM>) or forward the sensor data to the gateway entity <NUM>. The filtration process <NUM> is depicted in detail in <FIG>.

If the primary sensor <NUM> determines that the sensor data should be processed locally, a local processing step <NUM> processes the data. The local processing step <NUM> is depicted in detail in <FIG>.

At the local processing step <NUM>, there are several possible outcomes. One possible outcome is that the processed data does not trigger any actions. If the processed data does not trigger an action and an escalation filter <NUM> does not indicate that the data should be escalated for further processing, no action is taken and the data flow begins again using new data generated by the primary sensor <NUM>. If the escalation filter <NUM> does indicate that the data should be escalated for further processing, then the sensor data is forwarded to the gateway entity <NUM>.

Another possible outcome is that the local processing <NUM> does trigger a follow-up action, such as a status change or an action performed by an output device. In these situations, the local processing step <NUM> generates a status update and forwards it to the gateway entity <NUM>, and/or generates a trigger and forwards it to a primary output device <NUM>.

If the local processing step <NUM> causes a status update to be sent to the gateway entity <NUM>, the gateway entity <NUM> processes the change in status (e.g., by changing the security level <NUM> and applying any applicable rules from the security ruleset <NUM>). This may involve triggering one or more output devices, such as the primary output device <NUM> and/or the secondary output device <NUM>.

If the filtration step <NUM> or the local processing step <NUM> performed by the primary sensor <NUM> cause sensor data to be sent to the gateway entity <NUM> for further processing, the gateway entity <NUM> applies a filtration process <NUM> to determine whether the gateway entity <NUM> should process the sensor data locally (or through a secondary sensor <NUM> that is reachable by the gateway entity <NUM>). If so, the gateway entity performs a local processing step <NUM> on the sensor data.

At the local processing step <NUM> performed by the gateway entity <NUM>, there are several possible outcomes. One possible outcome is that the processed data does not trigger any actions. If the processed data does not trigger an action and an escalation filter <NUM> does not indicate that the data should be escalated for further processing, no action is taken and the data flow may begin again using new data generated by the primary sensor <NUM>. If the escalation filter <NUM> does indicate that the data should be escalated for further processing, then the sensor data is forwarded to the cloud- or third-party-processing device <NUM>.

Another possible outcome is that the local processing <NUM> does trigger a follow-up action, such as a status change or an action performed by an output device. In these situations, the local processing step <NUM> generates a status update and forwards it to the reporting/monitoring facility <NUM>, changes the security level <NUM> at the gateway entity <NUM> (if necessary), and triggers any applicable rules from the security ruleset <NUM>. For example, the local processing step generates a trigger and forward it to a primary output device <NUM>. If the security ruleset <NUM> indicates that a secondary output device <NUM> should be triggered, then the local processing step <NUM> forwards a trigger to the secondary output device <NUM> as well.

Yet another possible outcome is that the gateway entity <NUM> determines, either initially or as the data is processed, that the data should be forwarded to a secondary sensor <NUM> that is well-suited to processing the sensor data. For example, the secondary sensor <NUM> may be deployed with a specialized configuration <NUM> that is particularly well suited to processing the type of data received from the sensor <NUM>. Accordingly, the local processing step <NUM> of the gateway entity <NUM> may forward the sensor data to the secondary sensor <NUM> for processing, and may receive a status update in response.

Alternatively or in addition, the local processing step <NUM> may determine that supplemental data is needed in order to process the sensor data. The local processing step <NUM> therefore sends a request to the secondary sensor <NUM>, and receive sensor data from the secondary sensor <NUM> in response.

The filtration step <NUM> and/or the local processing step <NUM> performed by the gateway entity <NUM> may cause sensor data to be forwarded to the cloud- or third-party processor <NUM> for further processing. The cloud- or third-party processor <NUM> applies a local filtration step <NUM> (not shown) and a processing step <NUM> to the data. Similar to the local processing step <NUM> performed by the gateway entity <NUM>, the cloud- or third-party processor <NUM> may determine that additional data is needed from a secondary sensor <NUM>.

If the local processing step <NUM> performed by the cloud- or third-party processor <NUM> generates a status update and/or any triggers for output devices <NUM>, <NUM>, the status update and trigger(s) are sent to the gateway entity <NUM> to be acted upon accordingly.

The gateway entity <NUM> and/or the cloud- or third-party processor <NUM> may generate, as a part of their respective local processing steps <NUM>, a configuration update that changes the way that one of the sensors <NUM>, <NUM> or the gateway entity <NUM> processes future sensor data. Configuration updates may also be generated by other entities, such as the monitoring/reporting facility <NUM>. The configuration updates may be pushed to the gateway entity <NUM> for distribution to the affected devices. Alternatively or in addition, if the entity generating the configuration update is able to communicate directly with a device, the entity may push the configuration update directly to the device. For example, in <FIG> the local processing step <NUM> of the cloud- or third-party processor <NUM> and the monitoring/reporting facility <NUM> are both shown pushing a configuration update to the secondary sensor <NUM>.

Furthermore, although not depicted in <FIG>, the user <NUM> may generate a configuration update <NUM> to modify the settings on one or more of the user's devices. The configuration update <NUM> may be forwarded to the cloud- or third-party processing device <NUM> (e.g., using the user's mobile device <NUM>). The cloud- or third-party processing device <NUM> may validate the configuration update <NUM> to verify that the user <NUM> is authorized to make the changes in the configuration update <NUM>. If the cloud- or third-party processing device <NUM> determines that the user <NUM> is authorized, the cloud- or third-party processing device <NUM> may forward the configuration update <NUM> to the gateway entity <NUM> for deployment on relevant devices.

Moreover, although <FIG> shows the sensor <NUM> forwarding data to the gateway entity <NUM> for analysis, the sensor <NUM> may also forward data directly to the cloud- or third-party processing device <NUM>.

<FIG> shows the filtration step <NUM> of <FIG> in more detail. The filtration step <NUM> begins at step <NUM>, where the local device receives input data. For example, if the local device is the primary sensor <NUM>, the input data is retrieved from the data buffer <NUM>. If the local device is the gateway entity <NUM>, the input data is transmitted from the primary sensor <NUM> and retrieved from the sensor data buffer <NUM>. If the local device is the cloud- or third-party processor <NUM>, the input data is transmitted from the gateway entity <NUM>.

At step <NUM>, the local device may optionally aggregate the data. If the processor of the local device determines that the data can or should be processed in conjunction with other data, then the processor aggregates the input data with the other data. For example, the primary sensor <NUM> may wait until a predetermined amount of data has been gathered from the detector <NUM>, and may aggregate the predetermined amount of data together. The gateway entity <NUM> and/or the cloud- or third-party processor <NUM> may gather together data from multiple sensors of the same type, and process the gathered data as a group. For example, the aggregated data may be retrieved from the sensor data buffer <NUM> of the gateway entity <NUM> or the cloud- or third-party processor <NUM>.

The decision as to whether to aggregate the data may depend on the type of data and/or the current security level <NUM>. For example, if the data is high-priority data, or the architecture <NUM> is currently in an alarm state, then data may be processed as it arrives without waiting for additional data.

At step <NUM>, the local device applies any relevant device filters to the input data, such as a processing determination filter <NUM>. Processing logic in the device filter(s) indicates whether the data should be logged and/or whether the data should be processed locally. Accordingly, at step <NUM>, the processor of the local device determines whether the filter(s) indicate that the data should be logged locally. If the determination at step <NUM> is yes, then processing proceeds to step <NUM> and the data is stored in the memory of the local device. The data may be stored for a predetermined amount of time, or until the data is deleted.

Alternatively or in addition, the filter(s) applied at step <NUM> may indicate that the data should be logged, but at a remote device. Accordingly, at step <NUM> the data may be forwarded to the remote device for logging.

After the data is either logged, or a determination is made that the data does not need to be logged, processing proceeds to step <NUM> and the processor determines if the filter(s) applied at step <NUM> indicate that the data should be processed locally. If not, then processing proceeds to step <NUM> and the data is forwarded to the next destination. For example, the primary sensor <NUM> may send the data up one level in the hierarchy <NUM>, to the gateway entity <NUM>. The gateway entity <NUM> may send the data up one level in the hierarchy <NUM>, to the cloud- or third-party processor <NUM>. Alternatively, the gateway entity <NUM> may send the data down one level in the hierarchy <NUM>, to a secondary sensor <NUM> that is capable of processing data of the type generated by the primary sensor <NUM>.

Processing then proceeds to step <NUM>, where control is returned from the filtration process <NUM> to the local device.

If the determination at step <NUM> is "YES" (i.e., the local device should process the data), then processing proceeds to step <NUM>, and the data is processed by the local device. Step <NUM> is shown in more detail in <FIG>.

The local processing step <NUM> begins at step <NUM>, by retrieving the input data. For example, the input data may be retrieved from the data buffer <NUM> or <NUM>, or may be forwarded by the filtration step <NUM>.

Processing then proceeds to step <NUM>, where the local device's processing logic <NUM> is accessed. The evaluation logic <NUM> is retrieved from the processing logic and applied to the input data. Optionally, if the evaluation logic <NUM> determines that supplemental data is needed, the evaluation logic <NUM> may request the supplemental data from a secondary sensor <NUM> at step <NUM>. The evaluation logic <NUM> may indicate, as part of the request, conditions for the supplemental data (such as a time frame for data requested, a type of data requested, etc.).

After the evaluation logic <NUM> is applied, processing proceeds to step <NUM> and the local device determines if the processed data exceeds the triggering threshold <NUM>. If so, then a status update is generated in step <NUM>. The status update is sent to the appropriate device(s) in the architecture <NUM>. For example, if the local device is the primary sensor <NUM> or the cloud- or third-party processor <NUM>, the status update is sent to the gateway entity <NUM>. If the local device is the gateway entity <NUM>, the status update is sent to the monitoring/reporting facility <NUM> and/or pushed to any relevant devices (e.g., the primary sensor <NUM>, the output device <NUM>, etc.) in communication with the gateway entity.

Processing then proceeds to step <NUM>, and the triggering ruleset <NUM> is evaluated to determine whether to trigger any output devices. If the determination at step <NUM> is that one or more output devices should be triggered, then trigger messages are generated and forwarded to the appropriate devices.

Processing then proceeds to step <NUM>, where the local device determines whether any configurations <NUM> for devices in the architecture <NUM> should be modified. For example, if the local device is the gateway <NUM>, then the gateway evaluates whether the primary sensor <NUM> failed to detect an emergency condition (false negative) or detected a condition and sent a status update, but should not have (false positive).

If so, then at step <NUM> the gateway updates any relevant part of the configuration <NUM> of the primary sensor <NUM> (e.g., by altering thresholds, pushing more sophisticated processing logic <NUM> to the sensor, etc.) in order to improve the sensor's ability to recognize the condition in the future. Alternatively or in addition, the gateway <NUM> may retrieve a configuration <NUM> from another entity in the architecture <NUM> and push the configuration <NUM> to the primary sensor <NUM> in an update <NUM>. For example, the gateway <NUM> may identify that a more up-to-date configuration <NUM> is available on a secondary sensor <NUM>, and may retrieve the configuration <NUM> and push it to the primary sensor <NUM> in a configuration update <NUM>.

If the local device is the cloud- or third-party processor <NUM>, then the local device makes a similar determination at step <NUM> with respect to the primary sensor <NUM>, but also applies the same process to evaluating the gateway entity <NUM>. If the cloud- or third-party processor <NUM> determines that the configuration <NUM> of the primary sensor <NUM>, the gateway entity <NUM>, or both should be updated, then the cloud- or third-party processor <NUM> may push a configuration update to any affected device at step <NUM>.

Processing then proceeds to step <NUM>, where control is returned from the processing step <NUM> to the local device.

Returning to step <NUM>, it is possible that the processed data did not exceed the triggering threshold <NUM>. In this case, processing proceeds to step <NUM>, and the local device applies an escalation filter <NUM> to determine whether the data should nonetheless be forwarded to the next device in the hierarchy <NUM> for further processing. If it is determined, at step <NUM>, that the processed data exceeds the escalation threshold <NUM>, then the data is forwarded to the next device at step <NUM>. If the determination at step <NUM> is "NO" (i.e., the data does not exceed the escalation threshold <NUM>), then processing proceeds to step <NUM> and control is returned from the processing step <NUM> to the local device.

The filtration step <NUM> and the processing step <NUM> may be used by any device in the architecture <NUM>. <FIG> and <FIG> give an example of how the steps may be called in the course of operation of the primary sensor <NUM> and the gateway entity <NUM>, respectively.

<FIG> depicts an exemplary operating procedure <NUM> suitable for use by the primary sensor <NUM> (and any other sensors in the architecture <NUM>). The procedure begins at step <NUM>, where the sensor is initialized. This may involve, for example, performing system startup checks, loading the default configuration settings <NUM> from memory, setting any relevant parameters in the configuration <NUM> based on the default configuration settings <NUM>, initializing the buffers <NUM>, <NUM>, establishing communication with the gateway entity <NUM> through the communication interface <NUM>, and applying relevant maintenance rules from the maintenance ruleset <NUM>.

Processing then proceeds to step <NUM>, where the sensor <NUM> checks the network buffer <NUM> for new messages. If the sensor <NUM> determines, at step <NUM>, that the network buffer <NUM> includes a new configuration update <NUM>, then processing proceeds to step <NUM> and the next configuration message is retrieved from the network buffer <NUM> for further processing.

At step <NUM>, the retrieved configuration update <NUM> is parsed to separate the respective elements (e.g., the rules <NUM>, filters <NUM>, processing logic <NUM>, and configuration parameters <NUM>) of the configuration update. For example, if the elements are separated by a designated character, the sensor <NUM> reads the configuration update <NUM> until the designated character is reached, and identifies the read data with the appropriate element of the configuration update <NUM>. Alternatively, the header <NUM> may specify where to find the respective elements of the configuration update <NUM>.

At step <NUM>, each of the respective elements are evaluated to determine how to update the sensor's configuration <NUM>. For example, the sensor determines if the element of the configuration update <NUM> is a new configuration element, or is a new version of an existing configuration element already deployed on the sensor <NUM>. If no corresponding configuration element exists (e.g., the configuration element is a new rule to be added to the triggering ruleset <NUM>), then the configuration element is added to the configuration <NUM>. If a corresponding configuration element does exist (e.g., the configuration element is a new version of an existing rule in the triggering ruleset <NUM>), then the new configuration element overwrites the old configuration element.

Processing then returns to step <NUM>, where the network buffer <NUM> is checked for additional configuration update messages.

If the determination at step <NUM> is "NO" (i.e., no new configuration update messages are present in the network buffer <NUM>), processing proceeds to step <NUM> and the next batch of data is retrieved from the data buffer <NUM>. The filtration process <NUM> is applied to the retrieved data, which may result in the data being forwarded to another device for processing, or processing the data locally at the sensor <NUM>.

When control returns to the operating procedure <NUM> (at step <NUM>), the operating procedure reverts to step <NUM> and checks the network buffer <NUM> for additional configuration update messages.

Some or all of the steps of the operating procedure <NUM> may be performed in parallel, if the processor <NUM> of the sensor <NUM> supports parallel processing. For example, <FIG> separates the steps used to update the sensor's configuration <NUM> from the steps used to process the sensor data. The configuration update steps are performed in a first thread <NUM>, and the sensor data processing steps are performed in a second thread <NUM>. If steps of the operating procedure <NUM> are to be performed in parallel, then the initialization step <NUM> may include creating new threads for each parallel set of procedures.

<FIG> depicts a corresponding operating procedure <NUM> suitable for performance by a gateway entity <NUM>. The procedure <NUM> begins at step <NUM>, when the gateway <NUM> is initialized. This may involve, for example, performing system startup checks, loading the default configuration settings <NUM> from memory, setting any relevant parameters in the configuration <NUM> based on the default configuration settings <NUM>, initializing the data buffers <NUM>, <NUM>, establishing communication with devices in the connected device list <NUM>, and applying relevant maintenance rules from the maintenance ruleset <NUM>.

Processing then proceeds to step <NUM>, where the network buffer <NUM> is checked to determine if there are any pending messages for evaluation. Because the gateway entity <NUM> handles many different types of messages, the messages are be classified at steps <NUM>, <NUM>, <NUM>, and <NUM>. The different types of messages are handled in order of priority (e.g., messages having status updates, which could include an alarm condition, may be processed before messages having new sensor data for processing).

At step <NUM>, the gateway entity <NUM> determines if there is a status update message pending. If so, processing proceeds to step <NUM> and the status update is processed. If the security level <NUM> is changed by the status update, the gateway entity <NUM> may update the security level <NUM>. Processing then proceeds to step <NUM>, and the security ruleset <NUM> is evaluated/executed. Once the status update message is addressed, processing then returns to step <NUM> and the network buffer <NUM> is checked for additional messages.

At step <NUM>, the gateway entity <NUM> determines if there is a new trigger message pending. If so, processing proceeds to step <NUM> and the gateway entity forwards the trigger message to affected output devices. Processing then returns to step <NUM> and the network buffer <NUM> is checked for additional messages.

At step <NUM>, the gateway entity <NUM> determines if there is new sensor data to be processed. If so, processing proceeds to step <NUM> and the gateway entity's filtration method is performed. After the sensor data is processed and control is returned to the operating procedure <NUM> at step <NUM>, processing returns to step <NUM> and the network buffer <NUM> is checked for additional messages.

At step <NUM>, the gateway entity <NUM> determines if there are any configuration messages pending. If so, processing proceeds to step <NUM> and the next configuration update <NUM> is retrieved from the network buffer <NUM>. The configuration update <NUM> is parsed at step <NUM> in a manner similar to the one previously described with respect to step <NUM> in <FIG>.

At step <NUM>, the gateway entity <NUM> consults the header <NUM> of the configuration update <NUM> to determine which device(s) are affected by the configuration update. If the gateway entity <NUM> determines that the configuration update <NUM> is directed to other devices in the architecture <NUM>, then the gateway entity forwards the configuration update <NUM> to those other devices at step <NUM>. Processing then returns to step <NUM> and the network buffer <NUM> is checked for additional messages.

If the gateway entity <NUM> determines at step <NUM> that the configuration update <NUM> affects at least the gateway entity <NUM>, then processing may proceed to step <NUM> and the gateway entity <NUM> updates its configuration <NUM>. Step <NUM> may proceed in a similar manner to step <NUM>, previously described in connection with <FIG>. Processing then returns to step <NUM> and the network buffer <NUM> is checked for additional messages.

If, at step <NUM>, the gateway entity <NUM> determines that the configuration update <NUM> affects both the gateway entity <NUM> and at least one other device, then both of steps <NUM> and <NUM> are performed. Processing then returns to step <NUM>.

Some or all of the steps of the operating procedure <NUM> may be performed in parallel. <FIG> depicts an exemplary embodiment in which the status updates are processed in a first thread, trigger messages are processed in a second thread, sensor data is processed in a third thread, and status updates are processed in a fourth thread. If steps of the operating procedure <NUM> are to be performed in parallel, then the initialization step <NUM> may include creating new threads for each parallel set of procedures.

The exemplary procedures described in <FIG> may form part of the architecture management process <NUM>. These procedures may be supplemented with additional procedures as needed or applicable.

Using the above described embodiments, processing jobs in the architecture <NUM> may be performed at lower levels of the hierarchy <NUM> when possible, saving processing resources at the gateway entity <NUM>. Moreover, complex processing tasks may be performed at higher levels of the hierarchy <NUM>, allowing more complicated data analysis to be performed. Different processing logic <NUM> may be performed on different devices in the architecture <NUM>, allowing specialized processing to occur. Moreover, improvements may be developed at any level of the hierarchy <NUM> and pushed to other devices in real-time. The improvements may be dynamically generated in response to real-world processing results, allowing the processing logic <NUM> to be fine-tuned as processing occurs.

Furthermore, references to "one embodiment" are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.

Claim 1:
A method in a system architecture (<NUM>) including a primary sensor (<NUM>, <NUM>) at a lower level (<NUM>), a gateway entity (<NUM>) at an intermediate level (<NUM>), and a device (<NUM>) at a higher level (<NUM>) of a hierarchy (<NUM>) of processing capabilities, the method comprising:
receiving, at the gateway entity (<NUM>) comprising a processor (<NUM>), input data from the primary sensor (<NUM>, <NUM>) communicatively coupled to the gateway entity (<NUM>), wherein the primary sensor (<NUM>, <NUM>) includes a processor to process the input data and forward the input data to the gateway entity responsive to determining that the results of the processing do not exceed an alarm threshold, but do approach the alarm threshold within a predefined tolerance;
determining, by the processor (<NUM>) of the gateway entity (<NUM>) and based on processing capabilities of the gateway entity (<NUM>), whether to process the input data locally at the gateway entity (<NUM>) or to forward the input data to the device (<NUM>) communicatively coupled to the gateway entity (<NUM>), wherein the device (<NUM>) includes processing logic for processing the input data that is different from processing logic applied by the gateway entity (<NUM>), and wherein the processing capabilities of the gateway entity (<NUM>) are different from those of the processor of the primary sensor (<NUM>, <NUM>), such that they may come to different conclusions;
if the processor (<NUM>) determines that the input data should be processed locally at the gateway entity (<NUM>), the processor (<NUM>) processes the input data and generates an action to be taken in response to the input data and forwards the action to an output device (<NUM>, <NUM>) communicatively coupled to the gateway entity (<NUM>), wherein if the gateway entity determines that the input data should have triggered an alarm condition, the gateway entity determines that a configuration setting of the primary sensor should be changed, generates a configuration update that is configured to change the configuration setting, and forwards the configuration update to the primary sensor; and
if the processor (<NUM>) determines that the input data should not be processed locally at the gateway entity (<NUM>), the gateway entity (<NUM>) forwards the input data to the device (<NUM>), receives an action to be taken in response to the input data from the device (<NUM>), and forwards the action to the output device (<NUM>, <NUM>).