JP2017508228A - ロバスト・センサ・ネットワークのための分散規則エンジン - Google Patents

Abstract

物理的な侵入検出／警報を管理するためのネットワーク化されたシステムはサーバ・デバイスの上段を含み、プロセッサ・デバイス及びこのプロセッサ・デバイスに通信するメモリと、上段サーバに通信するゲートウェイの中央段と、デバイスの下レベル段であって、ノード関数を提供するためにルーチンを実行するアプリケーション層を含む少なくとも幾つかの関数ノードを有する完全な関数ノードを含む下レベル段と、及びデバイスの下段を管理するデバイスとを含み、このデバイスはプログラム・マネージャを例示化し、これは状態機械を実行して少なくとも幾つかの関数ノードの各々におけるアプリケーション層を制御する。【選択図】 図４

Description

優先権の主張
本出願はアメリカ合衆国法典第３５巻特許法第１１９（ｅ）の下に、米国仮特許出願第６１／９７３，９６２号として、２０１４年４月２日に出願した発明の名称“Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ”、米国仮特許出願第６１／９４６，０５４号として、２０１４年２月２８日に出願した発明の名称“Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ”、米国実用特許出願第１４／４６４，０７０号として、２０１４年８月２０日に出願した表題“Ｄｉｓｒｉｂｕｔｅｄ Ｒｕｌｅｓ Ｅｎｇｉｎｅ ｆｏｒ Ｒｏｂｕｓｔ ＳｅｎｓｏｒＮｅｔｗｏｒｋｓ”に基づく優先権を主張しており、それらの内容の全体が参照により本明細書に組み込まれている。

背景
この説明は、商業的又は居住施設に据え付けられた保安、侵入及び警報システムのために使われるようなセンサ・ネットワークの作動に関する。

企業や住宅所有者は、その者らの施設における警報状態を検出するため及びその状態を監視ステーション又はその保安システムの認可ユーザへ信号を送るために保安システムを持つことが一般的である。保安システムはしばしば侵入検出パネルを含んでおり、これは様々なセンサへ電気的に又は無線で接続されている。これらのセンサ形式は一般的には動作検出器、カメラ、及び近接センサ（ドア又は窓が開放されたか否かを判断するのに用いられる）を含む。一般的に、このようなシステムは、監視される特定の状態が変化したか又は安全ではなくなったことを示す非常に単純な信号（電気的に開閉）をそれらのセンサの一つ以上から受信する。

政府機関、会社、学術機関等は、認証情報を従業員、契約者、学生等に交付して、建物及び施設、屋内及び屋外への出入りを管理する。故意に又は意図せずにの何れかで保安システムを回避して出入りしようとする個々人は、特定して突き止めることが困難である。

多くのデバイスは、処理又はデバイスを制御して監視する処理規則のための下位構成要素として規則エンジンを使用する。規則の実行は、監視デバイスが内部値及び処理を更新したときに出力を生成しないことがあり、又は規則の実行は、規則が点火した（実行された）ことの指標である場合がある。下位構成要素として、規則及びデータ更新版は規則エンジンへ送られ、規則は点火するか点火しないかの何れかである。代表的なシステムにおいては、他の構成要素は規則エンジンの出力を評価して、採る措置を判定し、その措置は例えば結果を送らねばならないか又は付加的な処理が必要か又は規則が他の規則に連鎖しているか又は一般的に規則の点火からの出力を如何に経路付けるかを検知するなどである。

概要
データ収集システムの詳細は、データを収集する複数のセンサのネットワーク並びにイベントとイベントの位置を監視するセンサ・データから判定するシステムを含む。指標への接続は、有線及び動力ネットワーク又は無線とすることができる。検出センサは、火災及び煙及び有毒ガス又は化学検出器、警報ボックス、オーディオ検出器、構造変化検出器、人数カウンター、及び動作センサの一部又は全てを含む。これらの検出器／センサは、位置データ並びに生のセンサ・データを報告する。
［請求項が確定されたとき、代理人によって仕上げられる］
一つ以上の利点は、上述の態様の一つ以上から提供されるであろう。

同様は、データ入力及び規則は規則エンジンを更新し、この規則エンジンを制御する単独源から代表的に到来し、かくしてシステムの残りと相互作用する。これらの一般的な実施形態は、相当に付加的なソフトウェアを必要として、適切に実行するように構成されており、規則、データ及び措置を経路付ける。その複雑さに起因して、そのようなシステムのための適切な構成を管理して維持することは非常に困難である。付加的な関数により複雑な規則を強化することは、規則エンジンのタイムリーな実行に干渉する付加的な関数の実行時間及び安定性に起因して問題を含んでいる。複雑な制御システムにおいては、規則エンジンからの決定及び措置を送ることは労力の大部分である。

本発明の一つ以上の実施形態の詳細は添付の図面及び以下の説明に記載されている。本発明の他の特徴、目的、及び利点は、説明及び図面か、並びに特許請求の範囲から明らかである。

図１は代表的なネットワーク化された保安システムの概略図である。 図２は一般的なアプリケーション層マネージャのブロック図である。 図３はアプリケーション層における例示的処理を図示するブロック図である。 図４はアプリケーション層マネージャにおける例示的な状態遷移の図である。 図５は分散型規則エンジン全体に亘る処理を描くフローチャートである。 図６は分散型規則エンジン全体に亘る処理を描くフローチャートである。 図７は分散型規則エンジン全体に亘る処理を描くフローチャートである。 図８は例示的なネットワーク化された保安システムの構成要素のブロック図である。

ここに説明されたものはネットワーク関数の例であり、これは保安／侵入及び警報システムを含む様々な状況に用いられ得るが、これに限定されるものではない。例示的保安システムは、侵入検出パネルを含むことがあり、これは様々なセンサへ電気的に又は無線で接続されている。これらのセンサ形式は、動検出器、カメラ、及び近接センサ（例えば、ドア又は窓が開放されたか否かを判断するのに用いられる）を含み得る。一般的に、このようなシステムは、監視される特定の状態が変化したか又は安全ではなくなったことを示す非常に単純な信号（電気的に開閉）をそれらのセンサの一つ以上から受信する。

例えば、一般的侵入システムは建物における入口ドアを監視するために構成することができる。ドアが閉止しているとき、近接センサは磁気接触を検知して電気的閉回路を生成する。ドアが開放されているとき、近接センサは回路を開放して、警報状態が起こった（例えば、入口ドアが開放された）ことを示す信号をパネルへ送る。

データ収集システムは、幾つかのアプリケーション、例えば家庭用安全監視においてより一般的になっている。データ収集システムは無線センサ・ネットワーク及び無線デバイスを採用し、かつ、遠隔サーバに基づく監視及び報告生成を含み得る。以下に詳細に説明するように、無線センサ・ネットワークは、コンピュータ・デバイスの間の有線及び無線リンクの組み合わせを一般的に用いており、無線リンクは通常は最低レベルでの（例えば、エンドノード・デバイスからハブ／ゲートウェイへの）接続のために用いられている。例示的なネットワークでは、ネットワークのエッジ（無線接続された）段は、特定の機能でリソース制約されたデバイスからなる。これらデバイスは、小から中程度の処理能力及びメモリを有することがあり、バッテリで駆動されることがあるので、スリープ・モードにそれらの多くの時間を費やすことにより、それらがエネルギ節約することが必要である。一般的なモデルは、エンドノードがハブ及びスポーク形式アーキテクチュアでペアレント・ノードと直接に通信する単一の無線ネットワークを一般に各エッジ・デバイスが形成するようなもとなる。ペアレント・ノードは、例えば、ゲートウェイにおけるアクセス・ポイント又はサブコーデネータであることがあり、そのゲートウェイは、アクセス・ポイント又は他のサブコーディネータに接続している。

ここで図１を参照すると、無線センサ・ネットワーク（Wireless Sensor Network：WSN）のための例示的な（グローバル）分散型ネットワーク１０トポロジーが示されている。図１において、分散型ネットワーク１０は一組の段又は階層的なレベル１２ａ−１２ｃへ論理的に分割されている。ネットワークの上段又は階層的なレベル１２ａは、配置サーバ及び／又は仮想サーバ１４であり、インターネット・プロトコルのような充分に確立されたネットワーキング技術を用いて一緒にネットワーク化された「クラウド・コンピューティング」パラダイムを実行させているか、又はインターネットを全く使わないか又は一部を用いるプライベート・ネットワークとすることができる。それらのサーバ１４で作動するアプリケーションは、様々なプロトコル、例えばウェブ・インターネット・ネットワークXML/SOAP、RESTfulウェブ・サービスと、他のアプリケーション層技術、例えばHTTP及びATOMを用いて通信する。

分散型ネットワーク１０には第２の論理的分割段又は階層的レベル１２ｂを含み、ここでは中段を称し、これは個々の建築物又は構造物の内側の都合の良い位置に位置したゲートウェイ１６に関係している。これらゲートウェイ１６は上段におけるサーバ１４と通信し、これは、これらのサーバが独立型専用サーバ及び／又はウェブ・プログラミング技法を用いるクラウド・アプリケーションを実行しているクラウド・ベースのサーバであるか否かに関わらない。中央段ゲートウェイ１６はローカル・アリア・ネットワーク１７ａ（例えば、イーサネット（登録商標）又は８０２.１１）及びセルラー・ネットワーク・インターフェース１７ｂと共に示されている。

分散型ネットワーク・トポロジーは複数のデバイスの下段（エッジ層）１２ｃセットも含み、これは完全に関数的なセンサ・ノード１８（例えば、センサ・ノードであり、これは無線デバイスを含み、例えば受信機又は少なくとも送信機であり、これは図１においては、「Ｆ」で示されている）及び制限された無線センサ・ノード又はセンサ・エンドノード２０（図１には「Ｃ」で示されている）を含む。幾かの実施形態において、有線センサ（図示せず）は、分散型ネットワーク１０の態様に含めることができる。

ここで用いられる制限付きコンピュータ２０は、実質的に少ない持続性及び揮発性メモリを有するデバイス、他のコンピュータ・デバイス、検出システムにおけるセンサである。制限付きデバイスの現在の例は、およそ１メガバイト未満のフラッシュ／持続的メモリ、及び１０−２０キロバイト未満のＲＡＭ／揮発性メモリを有するものである。これらの制限付きデバイス２０は、このように構成されており、一般にコスト／物理的構成の考慮事項に起因している。

一般的ネットワークにおいては、ネットワークのエッジ（無線接続されている）段は、特定の関数を有する非常にリソース制限付きデバイスからなる。これらのデバイスには小から中程度の処理能力及びメモリを有し、しばしばバッテリで駆動されるので、多くの時間をスリープ・モードに費やすことによって、それらがエネルギ節約をすることを必要とする。一般的モデルである一つは、エンドノードが、ハブ・アンド・スポーク形式アーキテクチュアにおけるそのペアレント・ノードと直接に通信する単一の無線ネットワークを一般に各エッジ・デバイス形成するようなものとなる。ペアレント・ノードは、例えばゲートウェイにおけるアクセス・ポイント又はサブコーディネータとすることができ、ゲートウェイは同様にアクセス・ポイント又は他のサブコーディネータに接続されている。

各々のゲートウェイは、アクセス・ポイント（完全な関数的ノード又は「F」ノード）を備えており、これはそのアクセス・ポイントに取り付けられており、無線ネットワークにおける他のノードに対する無線接続ポイントを与える。図１に示されたリンク（線で描かれており、番号付けされていない）は、複数のデバイスの間の直接（単独のホップ・ネットワーク層）接続を示す。形式ネットワーキング層（図１に示される３段の各々において関数する）は、一連のこれら直接リンクと一緒にルーティング・デバイスを用い、メッセージ（断片又は非断片）を一つのデバイスから他のデバイスへネットワーク上で送信する。

WSN１０は、アプリケーション層への状態マシン・アプローチを実行して、下段デバイス１８及び２０において実行される。このようなアプローチの特定の実行の例を以下に説明する。状態マシンにおける状態は、調整中に実行される関数のセットからなり、これらの関数は、マネージャー・プログラムによって特定の下段デバイスの状態マシンにおいて状態を変えることにより、個別に削除されるか、又は置き換えられるか、加えることができる。

WSN状態関数ベースのアプリケーション層は、エッジ・デバイス操作システム（図示しないが、例えば上述の仮出願に開示されている）を用い、これはデバイスを再起動させることなく（所謂「動的プログラミング」）、個々の関数のローディング及び実行のために（デバイスの起動の後に）可能とさせる。他の実施例において、エッジ・デバイスは、他のオペレーティングシステムを用い、このようなシステムは、好ましくはエッジ・デバイスの再起動をすることなく、個々の関数のローディング及び実行させることを可能にする。

ここで図２を参照すると、アプリケーション層マネージャ３０の実施形態が図示されている。アプリケーション層マネージャ３０は、このアプリケーション層マネージャ３０が、更新されるデバイス、例えばデバイス１８，２０（図１の下段１２ｃ）における特定のアプリケーション・ソリューション又は「ビジネス」論理詳細に依存しないという意味で包括的である。アプリケーション層マネージャ３０は、例えば、ノードで、例えば、デバイス１ ８，２０における関数から関数への「パス−オフ」（現在作動している関数の変化）を取り扱う。これらのパス−オフは、ノード又はデバイス１８において実行されている実際の状態関数により要求される。

アプリケーション層マネージャ３０は、状態関数のための中央デスクリプタとして働く遷移テーブル（図４）を用いて、このような「パス−オフ」（現在作動している関数の変化）を達成する。アプリケーション層マネージャ３０への入力は、インターフェース３２を介してネットワーク層から解析されたメッセージを含む。アプリケーション層マネージャ３０は、割り込みインターフェース３４からのプロセッサ周辺機器割り込みを介する入力に基づく割り込み及びポーリングと、インターフェース３６を介するポーリングされたセンサ／周辺機器入力を含む。

アプリケーション層マネージャ３０は、構成、記憶されたデータ、及び／又はプレシピテイト・メッセージ生成における変化を指示する規則３８へ入力を充分に適用するように特徴付けることに関する。アプリケーション層マネージャ３０は、規則３８及び構成マネージャ４０並びにメッセージ・ジェネレータ／パーサーを有する。アプリケーション層マネージャ３０は、図示のように、入力に基づくネットワーク・メッセージ及びセンサ／プロセッサ周辺機器、局所的データ記憶４４（遷移テーブル用）及びリスト、構成管理関数、規則セット及びとレポート生成能力を使用する。

エッジ・アプリケーション・アーキテクチュア
図３を参照すると、図３を参照して、アプリケーション・モジュール・セット５０はエッジ・デバイス１８及び２０（図１）のためのアプリケーション層５０を含むことが示される。アプリケーション・モジュール・セット５０は、アプリケーション層マネージャ（図４）によって管理された層５２と、アプリケーション層マネージャによって管理されない層５４とを含む。この実施形態においては、アプリケーション層マネージャは、他のモジュールにおいてコードの変更を必要とすることなくアプリケーション層コード内の変化を適用するために、ＷＳＮ（例えば、無線ウェブ・モジュールなど、図示されないもの）のエッジに使われたモジュールをこれらの他のファームウェアから分離、即ち隔絶した。更に、図示のように、動作ＩＳＲ及び動作フィルタのリアルタイム処理は、アプリケーション層マネージャにより取り扱われず、一方、レポート・ジェネレータ及び心拍ジェネレータがアプリケーション層マネージャによって取り扱われる。

図３の例において描かれたアプリケーション・モジュール・セット５０は、アプリケーション層、例えば、スタック５６と通信状態にある動作レポート・ジェネレータ５３ａ及び心拍ジェネレータ５３ｂによって管理される関数を含む。アプリケーション層５２への変更は、これら他の隔絶されたモジュールの詳細の全てを完全に理解する必要とすることなく、アプリケーション層５２の働きの詳細の理解をなすことにより可能である。これは個々人の異なるグループとして望ましく及び／又はシステムはそれぞれのモジュールのコーディング及び保守を課されることがある。また、アプリケーション層５２は、全アプリケーション層の更新を必要とすることなく、アプリケーション層の部分（例えば、個々のビジネス規則、レポート、フィルタ、及び他の関数）の更新を支持するように部分をアップグレードすることを支持する一般的方法で構成されている。

図３は更にアプリケーション・モジュール・セットで実行される様々な処理の中の状態図を描いており、また下記の遷移テーブルとの相互作用を有する。

ここで図４を参照すると、例示的な状況が示されており、これはアプリケーション層マネージャ５０（Ａｐｐ＿Ｍｇｒ（））に関係しており、ここには２つの状態（関数Ａ，Ｂ，及びＣを有する状態１と、関数Ｄ及びＥを有する状態２）がある。遷移テーブルは、状態遷移を制御する。

図示の遷移テーブルは、機械と他の入力との現在の状態に基づいて、どのような状態（又は非決定性有限オートマトンの場合における複数の状態）有限半オートマトン又は有限状態機械が移行するかを示す。状態テーブルは基本的に真理値表であり、ここでは入力の幾つかが現在の状態であり、出力が他の出力と共に次の状態を含む。状態テーブルは状態機械を指定する幾つかの方式の一つであり、他の方式が状態図及び特性方程式である。

状態１は正常状態であり、入力点“Ｆｕｎｃ Ａ”を有する。通常は、状態１は“Ｆｕｎｃ Ａ”を実行し、これは“Ｆｕｎｃ Ｂ”を要請し、これは“Ｆｕｎｃ Ｃ”の実行を要請する。この例においては、条件が生じる（実際の条件は実装時固有事項であり、その詳細は何が続くかを理解する必要がない）。この状況下では、“Ｆｕｎｃ Ｂ”が、“Ｆｕｎｃ Ｃ”ではなく“Ｆｕｎｃ Ｄ”の実行を要請するときに、状態１が状態２に移行する条件が生じる。状態２は、一つのサイクル（Ｄ−Ｅ−出口［ｅｘｉｔ］）のみ又は多くのサイクル（Ｄ−Ｅ−Ｄ−Ｅ−…−出口［ｅｘｉｔ］）のために存在し得る。しかしながら、この例において出口が起きるとき、これは、何れの関数も呼び出すことなく、そのようにする。次いでデフォルトによって、それが入力点関数であることから、ＡｐｐＭｇｒのアイドル関数がＦｕｎｃ Ａを実行させる。

図５を参照すると、動作センサにおける「一般的」アプリケーション６０は動作センサの生データを割り込みルーチンにより取り扱い、適切には「動作イベント」６２のとき、その動作センサは動作フィルタの直接呼び出しを中断し、この動作フィルタはそれ自体の状態及び宣言を維持する。動作イベントは動作レポート・ジェネレータにより（おそらくは非決定的待ち時間のビットの後）取り扱かわれ６４、その動作レポート・ジェネレータは無線プログラム・スタックを呼び出してレポートをスタックの退出列へ置く。動作レポート・ジェネレータは、必要とあれば、ＳＣＫが受け取られるまで、ＡＣＫメッセージのために待機して６６、メッセージを再送する。心拍メッセージは周期的に生成されて６８、無線スタック退出メッセージ列へ置き、ＡＣＫが待機する。（心拍メッセージは配達失敗の後には再度送信されることはないが、新たな心拍メッセージは、先行する送信の結果が無線スタックから得られるまで、送信されない。）
ここで図６を参照すると、アプリケーション層は、アプリケーション層の異なる部分を一緒に規定及び結び付けることによりモジュール方式の要請を満足するように構成されており、全体的アプリケーション処理を中断することなく、個々の部分が無線リンク上で更新可能である。アプリケーション層は、「対象」を作成し７２、これはアプリケーション層「機械」のための基本的構築ブロックである。作成された対象は関数ポインターの配列を使用する。各々の関数ポインターは、「キーパー」、例えば、対応する関数の特定の状態の保持として働く。作成された対象は、特別なマネージャ関数（アプリケーション層マネージャ３０又は「ＡｐｐＭｇｒ」）も含み、これは何れの関数が機械内で実行されているか（即ち、何れの配列インデックス値が有効であるか）を追跡する７４。

状態遷移は、このインデックス値を変更する７６（又はＡｐｐＭｇｒへインデックス値を変えるように要求する）ことにより、関数制御を次の適切な関数へ移行させる現在の関数によって達成される。ＡｐｐＭｇｒは、このＡｐｐＭｇｒ及び個々の状態が対応する関数をサーバ又はゲートウェイなどの外部ホストから送信されたその関数の新しいバージョンと置き換えることにより変化させるのではなく、個々の状態関数内に駐在する「ハードワイヤード」ビジネス論理で一般的である。許可された状態遷移に変更をなすこと（新たな遷移を加えるか又は古い遷移を消去するかの何れか）は、状態を共有する関数を状態変化を実行する新たな関数に置き換えることにより達成される。

幾つかの実施例において、ＡｐｐＭｇｒは現在の状態関数のための現在のインデックスを実際に変化させるように構成７８されており、一方、他の実施例においては、ＡｐｐＭｇｒ（）を媒介として用いることなく、古い関数は新たな関数を直接に起動させる８０。ＡｐｐＭｇｒ（）は、許可された遷移のマッピング８２を有し、このマッピングの違反についてチェックする８４（即ち、所定の関数が他の関数へ制御を渡そうとすると、そのようにすることが許可されない状態遷移を生じる）。ＡｐｐＭｇｒ（）は、変化と例外を引き起こすことを禁止する。ＡｐｐＭｇｒ（）におけるこの関数性は、誤った状態変化が関数により要請されるとき、ＡｐｐＭｇｒ（）によりエラー・メッセージが生成される８６ので、状態機械挙動への変更が有効であり、かつ、状態機械挙動が実際に起こることを確かめるのに役立つ。さもなければ、個々の状態は、対応する関数をその関数の新しいバージョンに置き換えることによって変化する８８。

例示的アプリケーション
ｐ＿ＡｐｐＦｕｎｃ［ｉ］は、ｉ^ｔｈアプリケーション関数へのポインターとする。Ｎ＿ｉはＡｐｐＭｇｒ（）により維持された「現在のインデックス」とする。Ｎ＿ｉはグローバル変数であり、その値を一つからＡｐｐＭｇｒ（）を通じて次まで保持するものとする。

ＡｐｐＭｇｒはルート関数であり、例えばエッジ・デバイスにおいて実行されるオペレーティング・システムにおけるスケジューラにより実行される。ＡｐｐＭｇｒは、完全に数ミリ秒ごとに実行される。ＡｐｐＭｇｒ（）が実行されるたびに、ＡｐｐＭｇｒ関数がｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｉ］により指し示された関数を実行する。或る実施形態においては、状態機械は一組の配列として実装することができ、一方、更に複雑な実装例においては、状態機械は、状態機械における状態の不確定数を許容するリンクされたリストを通じてリンクされた一組の関数として実装される。

幾つかの状態については、一つのみの関数呼び出しが必要とされることもある。即ち、ｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｉ］が一旦実行されると、次いでＮ＿ｉが異なる値に変化し、これがＡｐｐＭｇｒ（）の次の呼び出しにおけるものとなるようにＮ＿ｋだとすれば、異なる状態が入力される（即ち、ｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｋ］が実行される）。他の状態のために、対応する関数がＮ＿ｉが変化する前に何度も実行される。単独実行関数の例は、レポートを送ることである。マルチ実行関数の例は、センサ・デバイスから生データに従って働くセンサ・フィルタの動作である。

様々な関数ｐ＿ＡｐｐＦｕｎｃ［ｉ］は、ＡｐｐＭｇｒ（）が状態変化をなす要請をせねばならないとき、決定するのみならず、これらの関数がどの一つ又は複数の新たな関数（例えば、Ｎ＿ｉのどの一つ又は複数の新たな値）からＡｐｐＭｇｒ（）を選ばねばならないかを示し、このようにＡｐｐＭｇｒ（）は適切に包括的に構成され、ひいては状態の間の遷移の記述を含むビジネス論理が、ｐ＿ＡｐｐＦｕｎｃ［］関数に包含される。

同時措置
二つのｐ＿ＡｐｐＦｕｎｃ［］関数は異なるタスクを同時になす必要があり、例えば二つのセンサからのデータを同時にフィルタリングする（例えば、スイッチを跳ね返らないようにして、加速度計からの動作データをフィルタリングする。ＡｐｐＭｇｒを与える一つの一般的アプローチは、二つの状態関数を一回に実行して（両方を実行して、各々をＡｐｐＭｇｒに通す）。他のアプローチ値は、ＡｐｐＭｇｒを単純に保ち、単にコードを備えているアプリケーション状態を互いに呼び出すようにし、ひいては互いに呼び出す。即ち、ｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｉ］は、ｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｉ］の実行の終了の際にｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｋ］の実行を要請し、その逆もまた同じである。

実際には、二つのａｐｐ関数は、タイムシェアリングのためのＡｐｐＭｇｒ計画を伴うことなく計画時間とＡｐｐＭｇｒの注意とを分割する。

ｐ＿ＡｐｐＦｕｎｃ［］の様々なバージョンは、ゲートウェイ及びクラウド における実行可能コード貯蔵所において保持され、及びこのような関数の各々はＩＤ番号を有することができ、これは関数の一つのバージョンを他のものから識別するのに用いられるができる（及び多くの場合に世代における差異又は関数のバージョンは小さいが、重要であることがあり、まさしく右番号が重要である）。所定の関数の中に、異なる関数又は状態への要請された変化はコード・バージョンに関して非常に明確になり、従って、状態変化（関数変化）を要求する関数により使用されるパラメータが実は新たな関数のＩＤ数であることは論理的である。

バージョンを管理する単純な方法は、Ａｐｐ Ｌａｙｅｒ状態関数にそれら自身のファイル形式を与えることである。ファイル形式は、例えばフラッシュ・メモリにおけるファイル・インデックスにおけるフィールドの一つとして維持されて、起動の間のＡｐｐＭｇｒ（）の初期化処理がフラッシュ・メモリにおけるその形式のファイルについて検索し、０から最大値，ｉ＿ｍａｘまであるインデックスｉにより、関数ポインタの配列を生成する。

この初期化の間ＡｐｐＭｇｒ（）は、各々の値ｉを関数、ｐ＿ＡｐｐＦｕｎｃ［ｉ］ 及びその関数の対応する関数ＩＤへマップし、各々の機能ＩＤ、対応するインデックス値ｉ、及び許可された状態遷移（現在の関数から到達可能な関数のためのＩＤｓ）を示すテーブルを生成する。

例えば、現在の関数、例えばｐ＿ＡｐｐＦｕｎｃ［Ｎ＿ｉ］と共にその関数ＩＤ、例えば０ｘ３１Ｃ７の操作の過程の間、関数はＡｐｐＭｇｒ（）へ復帰することがあり、戻り値は０ｘ３９６Ｂである。この戻り値は関数ＩＤ“０ｘ３９６Ｂ”を有する関数ｐ＿ＡｐｐＦｕｎｃ［］を実行する要請である。ＡｐｐＭｇｒ（）は状態テーブルを用い、関数ＩＤ“０ｘ３９６Ｂ”を有するｐ＿ＡｐｐＦｕｎｃ［］を実行する要請が遷移であって、これは関数ＩＤ０ｘ３１Ｃ７を可能とするものであるか否かを判定し、そうであるならば、ｉの何れかの値が関数０ｘ３９６Ｂに対応する。それが有効な要請であるならば、ＡｐｐＭｇｒ（）はＮ＿ｉを関数ＩＤ“０ｘ３９６Ｂに対応するｉの新たな値に等しく設定し、ＡｐｐＭｇｒ（）の次の実行に際して、新たな関数ＩＤ”０ｘ３９６Ｂ“が実行される。

ＡｐｐＭｇｒ（）の初期化及び状態テーブルの生成の間、単純なグラフ解析アルゴリズムが作動して、各々の状態が到達可能（状態は孤立していない）であることを確実として、全ての状態が単独の状態機械の部分（即ち、状態の二つのより小さくて全く分離したセットがない）であることを確認する。状態テーブル確認は、状態の遷移が存在しない関数への遷移を必要とすることができないことも必要とする。

ＡｐｐＭｇｒ（）は常にステム状態（アイドル状態）を有し、これはインデックスＮ＿ｉが未定義のときに実行される関数ＩＤ０ｘ０００１を有する。状態機械の初期化は、第２の状態（状態を初期化）これはそれ自身の一般的な関数と共に関数ＩＤ０ｘ００００においてなされる。関数の何れかが変化するとき（新たな単数又は複数の関数の無線ダウンロードにより）はいつでも、ＡｐｐＭｇｒ（）は再現関数０ｘ００００になり、次いで状態関数０ｘ０００１へ遷移する。これは完全な関数セットにおけるユーザ供給関数の唯一の一つのみが入力状態として認識される更なる前提条件である。これは、自動的に０ｘ００００１によって呼び出される状態である。ユーザ供給された関数におけるその点から、それらの戻り値の一部として状態変化を要請する。

図３に戻って、上述の状態図及びテーブルにおいては、上述の例示的アプリケーションのために状態遷移行が追加されたテーブルが示される。

上述の例は、概念の説明のために単純である。

しかし、より複雑なアプリケーション・セットを使うこともできる。例えば、２つの「状態」がノードにあるとする−連続的ループ内の関数Ａ，Ｂ，及びＣの恒久的実行に対応する第１の状態が及び他の恒久ループにおいて関数Ｄ及びＥの恒久的実行に対応している第２の状態。第１の状態（通常状態）関数Ａ（「入力関数」）は、関数Ｂを実行させるＡｐｐＭｇｒ（）を終了及び実行させるために実行される。関数Ｂが終了すると、これは関数Ｃを要請し、これは次に関数Ａを要請する。関数Ａが入力関数であり、ループＡ−Ｂ−Ｃ−Ａ．．．は閉ループ、関数Ｄ及びＥは通常は実行されない。しかしながら、特殊な条件下で関数Ｂは、それが出るとき、関数ＣよりもむしろＣを要請すると仮定する。関数Ｄ及びＥが次いでそれらの一つが第１のループにおける関数を要請するまで、ループ（Ｄ＿Ｅ＿Ｄ＿Ｅ．．．）内で実行される。この方式においては、複数の関数又は関数の複数のセットは状態に対応し、各状態において作動する関数は状態遷移を管理する。

関数が新たな関数を要請されずに出るとき、ＡｐｐＭｇｒアイドルは単純に入力点関数を再び実行する。非常に単純なノードを有する或る場合において、ここにはＮＯ入力関数があり、ここではアイドル関数がイベント初期化関数が実行されるまで単にそれ自身を実行する。

図４へ戻って参照すると、仮定的（包括的）状況には二つの状態（（関数Ａ，Ｂ，及びＣを有する状態１と、関数Ｄ及びＥを有する状態２）がある。状態１は通常状態であり、入力点、関数Ａを有する。特殊な環境下では関数Ｂが関数Ｃよりもむしろ関数の実行を要請するとき、状態１は状態２へ遷移する。状態２は一つのサイクル（Ｄ−Ｅ−出口）のみ又は多数の（Ｄ−Ｅ−Ｄ−Ｅ−．．．−出口）のために存在しているが、この例において出口が起こるとき、これはどんな関数も呼び出すことなくそのようになる。次いでデフォルトによって、ＡｐｐＭｇｒのアイドル関数は関数Ａを実行し、というのはこれが入力点関数であるためである。

ノードは、任意の適宜な形式のコンピュータ・デバイス、例えば、メインフレーム・ワークステーション、パーソナル・コンピュータ、サーバ、携帯型コンピュータ・デバイス、又は指令を実行して、ネットワークに接続して、ネットワークを通じてデータパケットを転送することができる任意の他の形式のインテリジェント・デバイスを用いることにより実施し得る。これらのノードは任意の適宜なコンピュータ・プログラムを実行することができ、ネットワークにおける使用のためにデータパケットを生成し、受信し、及び送信する。

ロバスト・グローバル・オートメーション・ネットワークのための分散型規則エンジン 幾つかのデバイス（例えばゲートウェイ）のためには、上述のアプリケーション層柔軟性は独立したソフトウェア・エージェント又は規則実施モジュール（入力された状況をチェックして、それに応じて反応する独立して実行関数）の形式の使用から特に規則エンジンの使用に由来する。例えば上述の仮出願で論じられているルーティング／規則メッセージ発信を参照。

他のデバイス（例えば比較的制約されたエンドノード）のためにアプリケーション層巧妙さが、プログラマブル状態機械方法から生じ（単に一つの実装例として）、このプログラマブル状態機械方法は動的にロードされた「ルート関数」の新たな要素を有し、その「ルート関数」は特定の規則（代表的には各々のルート関数のための一つの規則）を具体化し、システムのために確立された関数優先性に応じてエンド・デバイスのオペレーティングシステムにより実行される。これらの機能は小さなメッセージ（即ち、デバイスの全ての実行コード・ベースの完全な修正再表示を含んでいないメッセージ）におけるエンド・デバイスへ送信することができ、インストールされて迅速に実行できる。従って、結果的なエッジ・アーキテクチュアは頻繁なアップデートを支持することができる。

上述の図２は一般的なアプリケーション層をネットワーク・メッセージ及びセンサ／プロセッサ周辺機器に基づく入力、局所的データ記憶及びリスト、構成管理関数、規則セット並びにレポート生成能力と共に図解する。図１において分散型規則エンジンは、個々のノード又はノードの集合における円囲み要素「Ｒ」により示される。図１に示される三段の各々（例えば、クラウド／企業、ゲートウェイ、及びエッジ・デバイス）はアプリケーション層を有する。アプリケーション層への入力は、ネットワーク層及びプロセッサ周辺機器インタラプト及びポールされたセンサ／周辺機器からの説明メッセージを含む。

アプリケーション管理処理は規則を適用する充分な入力を特徴づけ、その規則は構成における変化をデクテイトし、データを記憶し、及び／又は、メッセージ生成を引き起こす。

しかしながら、デバイスの幾つかにおいては、規則エンジンは、個々のノード又はノードの収集における分散型規則エンジン（上述の丸囲み要素「Ｒ」により示される）である。これらの分散型規則エンジンはメッセージの生成に関係しており、そのメッセージは一つのデバイスの出力から他のデバイス（即ち、行動／延期）へ渡されるか、又は規則は入力の値又は幾つかの入力の値又はさもなければ幾つかの入力、他のデータ、ノードの現在の構成に基づいて行動を決定し得る。

ここで図７を参照すると、図１のネットワークにおいて実行される特定の規則は、階層化されるか、下位に置かれるか、分散される。規則は上述した段の最初の一つのアプリケーション層で実行を開始することができ、その実行の結果は図１に述べた三段の異なる一つのアプリケーション層における規則の実行をもたらすか又は引き起こす。

クラウド／企業段１２ａのサーバ１４は、サーバー・アプリケーション層（図示しない）における規則の複製又は修正版を生成９０する。クラウド／企業段１２ａのこれらのサーバ１４は、規則のそれらの複製又は修正バージョンを中段１２ｂにおけるゲートウェイ・デバイス１６に駐留するアプリケーション層（図示せず）の中に配布する。同様に上層段は、エッジ層デバイス１８，２０に実行される規則を配布（また９２において描かれる）することにより、作業をエッジ・アプリケーション層１２ｃに委託する。

受け入れ段においては、ゲートウェイ／エッジ・デバイスは、そのような複製又は修正されたバージョンを実行のために受け取り、そのようなデバイスにおけるアプリケーション層は、インデックスを変更する（又はＡｐｐＭｇｒ（）にインデックスを変化させるように尋ねる）ことにより、関数制御９４を受信した規則へ転送させ、図６について上述したように遷移を確認する。受け入れ段においては、ゲートウェイ／エッジ・デバイスは、そのような規則の複製又は修正バージョンを受け取り、この受け入れ段において規則の複製又は修正バージョンを実行し、レポートの形式における結果が生成されて、規則により判定された段へ復帰する。エッジ層１２ｃのアプリケーション層における規則は、他の層９６ａから分配された規則の行為により削除されることもあれば、一時的に抑制されることもある。

規則は比較的単純な「ｉｆ−ｔｈｅｎ」形式９６を含む様々な論理形式を採ることがあり、以下のように、特定入力を導きレポートを生成する規則が、仮に入力ｘが観察されるのであれば起動される場合を再生する。

「ｘ入力が観察されるならば、次いでローカル・データ入力yを生じて、レポートｚを生成」
更に、或る規則は合成入力を含むことがあり、例えば以下のif-then規則は期間ｘに亘って入力ａ，ｂ，ｃを操作し、行為、例えばレポートの生成を誘発する。

「ａ，ｂ，及びｃが、時間ｘの範囲内で起こり、次いでレポートｙを生成する。」
規則は、第２の規則９７ａ−９７ｅを呼び出す第１の実行規則により同一又は異なるエンジンにおいて連続的に実行されるようにカスケード状にすることもでき、例えば例として、規則１が期間ｘ内に満足されるのであれば、規則１（又は、ＡｐｐＭｇｒ（））は規則２を起動させ、規則２が期間ｘ内に満足されるのであれば、レポートを生成する。

「規則１が期間ｘ内に満足されるならば、次いで規則を起動させ、規則２が期間ｘ内に満足されるのであれば、次いでレポートyを生成。」
規則は形式が単純である場合があるが依然として比較的に複雑な計算を含むことがあり、例えばニューラル・ネットワークからの計算を含む。

「所定の５０入力によるニューラル・ネットワークの出力が閾値ｘを上回るならば、次いでレポートｙを生成。」
分散型規則エンジンは、任意の適宜な形式のコンピュータ・デバイス、例えば、メインフレーム・ワークステーション、パーソナル・コンピュータ、サーバ、携帯型コンピュータ・デバイス、又は指令を実行して、ネットワークに接続して、ネットワークを通じてデータパケットを転送することができる任意の他の形式のインテリジェント・デバイスを用いることにより実施し得る。これらのノードは任意の適宜なコンピュータ・プログラムを実行することができ、ネットワークにおける使用のためにデータパケットを生成し、受信し、及び送信する。

図８は、図１に関して説明したWSNの特徴を有すると共に、ここに説明した様々な関数を有する保安システムの例を示す。図８に示すように、相関関係処理は特定の制限付きノードから入力を受け取る（しかし、これらは完全に関数的なノードとすることもできる）。これらの入力は認証情報及びビデオ情報を含むことがあり、相関関係処理は、相関関係結果を生成することがあり、これはネットワーク上に送信される。コンテクスト管理処理は特定の制限付きノードから入力を受け取り（しかし、これらは完全に関数的なノードとすることもできる）、これは例えば、認証情報、ビデオ及びグルーピング情報であり、コンテクスト処理を実行して結果をネットワーク上に送る。ネットワークは、非常口指標、非常用カメラのみならず、分散規則処理及び規則エンジン／メッセージ発信処理の操作を支持する。レンジ・エクステンダは、例えばゲートウェイと共に使用され、かつ、リアルタイム位置システムは図示のように様々なセンサ（例えば、制限付き形式）から入力を受け取る。サーバはクラウド・コンピューティング構成を介してWSNとインターフェースし、或るネットワークの部分はサブネットとして実行することができる。

センサは、センサの範囲内の領域で何かが検出されたことに加えて、詳細な付加的情報を与え、これは特定のセンサに対する入力の広範囲な解析を実行する必要がある侵入検出パネルを伴うことなく、その指標が何であるかを評価するのに用いることができる。

例えば、動作検出器は室内を動き回る暖かい体の熱的特徴を分析して、その体は人物のものかペットのものかを判断する。その分析の結果は、検出された体に関する情報を伝達するメッセージ又はデータである。様々なセンサは、このように音、動作、振動、圧力、熱、画像その他を検知して、侵入発見パネルにおいて真の又は確認された警報状態を検出するのに適切な組み合わせとして用いられる。

認識ソフトウェアは、人間である対象物と動物である対象物との区別の判断に用いることができ、更に顔認識ソフトウェアはビデオ・カメラに組み込むことができ、周辺侵入が、認識され認可された個人によるもののであることを確認するために用いられる。そのようなビデオ・カメラは、プロセッサ及びメモリ、並びに認識ソフトウェアからなり、その認識ソフトウェアはカメラによる入力（撮像画像）を処理して、メタデータを生成し、ビデオ・カメラにより撮像された個人の認識又は認識の欠如に関する情報を伝達する。この処理は、これに代えて又はこれに加えて、ビデオ・カメラにより撮像／監視される領域における個人の特徴に関する情報を含むこともできる。従って、状況に依存して、この情報は、周辺侵入の特徴を与えるセンサへの入力における向上された分析を実行する向上された動作検出器及びビデオ・カメラから受信したメタデータ、又は対象物の認識を確立しようとする非常に複雑な処理からもたらされるメタデータとの何れかである。

センサ・デバイスは、より複雑な出力を生成するために複数のセンサを統合することができ、それにより侵入検出パネルはその処理能力を利用して、建物仮想イメージ又は環境の特徴により環境を分析するアルゴリズムを実行し、違反の有効性についての理にかなった決定をなす。

メモリは、侵入検出パネルのプロセッサにより使用されるプログラム指令及びデータを記憶する。このメモリは、ランダム・アクセス・メモリとリード・オンリー・メモリとの適切な組合せとしてもよく、プログラム指令（例えばファームウェア又はオペレーティング・ソフトウェア）並びに構成及びオペレーティング・データに適するホストとしてもよく、また、ファイル・システム又はその他のものとして組織化してもよい。記憶されたプログラム指令は、一人以上のユーザを認証するための一つ以上の認証方法を含み得る。パネルのメモリ内に記憶されたプログラムは、更にソフトウェア構成要素を記憶することがあり、これはネットワーク通信とデータ・ネットワークへの接続の確立とを可能にする。ソフトウェア構成要素は、例えば、インターネット・プロトコル（IP）スタック、並びにインターフェース及びキーパッドを含む様々なインターフェースのためのドライバー構成要素を含み得る。ネットワークに亘る接続及び通信を確立するために適する他のソフトウェア構成要素は、当業者には明らかであろう。

構成データと共にメモリ内に記憶されているプログラム指令は、パネルの全体的な操作を制御し得る。

監視サーバは、一つ以上の処理デバイス（例えば、マイクロプロセッサ）、ネットワーク・インターフェース及びメモリ（全て図示しない）を含む。この監視サーバはラック搭載のカードの形態を物理的に採ることがあり、一つ以上のオペレータ・ターミナル（図示せず）と通信し得る。監視サーバの例は、SURGARD（登録商標） SG-System III Virtual、又は類似のシステムである。

各々の監視サーバのプロセッサは、各々の監視サーバのためのコントローラとして働き、各々のサーバと通信し、各々のサーバの全体的な操作を制御する。

プロセッサは、上述のメモリを含むか若しくはこのメモリと通信することがあり、このメモリは、監視サーバの全体的な操作を制御するプロセッサ実行可能指令を記憶する。適宜なソフトウェアは、各々の監視サーバにアラームを受信させて、適切な行為を起こさせることを可能とする。ソフトウェアは、適宜なインターネット・プロトコル（I P）スタック及びアプリケーション／クライアントを含み得る。

中央監視ステーションの各々の監視サーバは、IPアドレス及び単数又は複数のポートと関係することがあり、それにより、各々の監視サーバはコントロールパネル及び／又はユーザ・デバイスと通信し、警報イベント等を取り扱う。監視サーバ・アドレスは静的であり、ひいては監視サーバの特定の一つを侵入検出パネルへ常に特定し得る。これに代えて、動的アドレスを用いることができ、静的ドメイン名に関係して、ドメインネーム・サービスを通じて決定される。

ネットワーク・インターフェイス・カードはネットワークにインターフェースして、到来する信号を受信し、例えば、イーサネット・ネットワーク・インターフェイス・カード（NIC）の形態を採り得る。サーバは、コンピュータ、シンクライアント、又はその種の他のものとすることができ、これには警報イベントを表す受信データが人間オペレータによる取扱いのために通過される。監視ステーションは、加入者データベースを更に含むか若しくはこれにアクセスすることがあり、その加入者データベースは、データベースエンジンの制御下のデータベースを含む。データベースは、監視ステーションによりサービスされる上述のパネルのようなパネルへの様々な加入者デバイス／処理に対応するデータ入力を包含することがある。

ここに説明した処理の全て又は部分及びそれらの様々な変更例（以下、「処理」として称する）は、少なくとも部分的には、コンピュータ・プログラム製品、即ち、一つ以上の有形の物理的ハードウェア記憶デバイスに有形に具象化されたコンピュータ・プログラムを介して実施することができ、そのハードウェア記憶デバイスは、データ処理装置（例えば、プログラマブル・プロセッサ、コンピュータ、又は複数のコンピュータ）により実行するため、又はそれらの操作を制御するためのコンピュータ及び／又は機械可読記憶デバイスである。コンピュータ・プログラムは任意の形態のプログラミング言語で書くことができ、これはコンパイル型又はインタープリタ型言語を含み、かつ、スタンド・アローン・プログラムとして、又はモジュール、構成要素、サブルーチン、又は計算環境における使用のために適する他のユニットとしてのものを含む任意の形態に展開することができる。コンピュータ・プログラムは、一つのコンピュータ又は複数のコンピュータであって、一つの位置又は複数の位置に亘って分散されてネットワークにより相互接続されてコンピュータにおいて実行されるように展開することができる。

処理を実行することに関連した行為は、較正処理の関数を実行する一つ以上のコンピュータ・プログラムを実行する一つ以上のプログラマブル・プロセッサにより実行することができる。処理の全て又は一部は、専用用途論理回路、例えば、FPGA（フィールド・プログラム可能ゲート・アレイ）及び／又はASIC（特定用途向け集積回路）として実施することができる。

コンピュータ・プログラムの実行のために適するプロセッサは、例として、一般的で専用用途マイクロプロセッサ、及び任意の種類のデジタル・コンピュータの任意の一つ以上のプロセッサを含む。一般に、プロセッサは、指令及びデータを読出し専用記憶領域域又はランダム・アクセス記憶領域又はその両方から受信する。コンピュータ（サーバを含む）の要素は、指令を実行するための一つ以上のプロセッサと、指令及びデータを記憶するための一つ以上の記憶領域デバイスとを含む。一般に、コンピュータはまた、一つ以上の機械可読記憶媒体、例えばデータを記憶するための大容量記憶デバイス（例えば、磁気、光磁気ディスク、又は光学ディスク）からデータを受信するように、又はそれにデータを転送するように、又は両方のために、上述の一つ以上の機械可読記憶媒体を含むか、それに作動的に結合されている。

コンピュータ・プログラム指令及びデータを実施するために適する有形の物理的ハードウェア記憶デバイスは、不揮発性ストレージの全ての形態を含み、例として、半導体記憶領域デバイス、例えば、EPROM、EEPROM、及びフラッシュ記憶領域デバイス；磁気ディスク、例えば、内蔵ハードディスク又はリムーバブル・ディスク；光磁気ディスク; 及びCD-ROM及びDVD-ROMディスクと不揮発性コンピュータ・メモリ、例えば、スタティック及びダイナミックRAMなどのRAM、並びに消去可能なメモリ、例えば、フラッシュメモリを含む。

更に、図面に描かれた論理フローは、望ましい結果を達成するために、図示された特定の順序、又は連続的順序を必要としない。更に、他の行為を設けてもよく、又は説明されたフローから行為を削除してもよく、また、説明されたシステムに対して他の構成要素を追加してもよく、又は取り除いてもよい。同様に、図面に描かれた行為は、異なる実体によって実行されてもよく、又は統合されてもよい。

ここに説明した異なる実施形態の要素は、特に上述していない他の実施形態を形成するために組み合わせ得る。要素は、本明細書に説明した処理、コンピュータ・プログラム、ウェブ・ページ等から、それらの操作に悪影響を与えることなく、省略してもよい。更に、様々な個別の要素は、一つ以上の個々の要素に組み合わせて、本明細書に説明した関数を実行するようにしてもよい。

特にここに説明していない他の実施例も以下の請求項の範囲内にある。

Claims (13)

1. デバイス・ノードであって、
   オペレーティング・システムを実行しているプロセッサと、
   前記プロセッサに通信するメモリとを備え、前記プロセッサは、
   ネットワークにおける第１段から独立したソフトウェア・エージェントを受け取り、このソフトウェア・エージェントは、少なくとも１つの規則を含む動的にロードされた「ルート関数」であり、及び
   ノードのために確立した関数優先順位に従ってエンド・ノードのオペレーティング・システムにより独立したソフトウェア・エージェントに含まれる少なくとも一つの規則を実行するように構成されているデバイス・ノード。
2. 請求項１のデバイスにおいて、ロードされたルート関数は、全ての実行コードの完全な再命令文を包含していないメッセージで、前記ノード上にインストールされる小さなメッセージにおける前記ノードにより受信されるデバイス。
3. 請求項１のデバイスにおいて、前記規則がカスケード状規則であり、このカスケード状規則が複数のノードにおける複数の規則エンジンで実行されるデバイス。
4. 請求項１のデバイスにおいて、メッセージを生成することを更に含み、このメッセージは一つのノードから行動延期を指定する他のノードの入力へ渡されることを更に含むデバイス。
5. 請求項１のデバイスにおいて、前記ノードがネットワークにおけるデバイスの
   複数の段の第１段のためのノードとして構成されると共に、
   前記規則の実行の結果を含むメッセージを生成し、前記段の異なる一つのアプリケーション層における異なる規則の実行をもたらすか若しくは引き起こすことを更に含むデバイス。
6. 請求項１のデバイスにおいて、前記ノードがカスケード状規則を超えるように構成され、第１の実行規則が第２の規則を呼び出すことにより、同一又は異なるエンジンにおいて連続的に実行される二つ以上の規則を有するようにされているデバイス。
7. 請求項１のデバイスにおいて、前記ノードがカスケード状規則を超えるように構成され、前記カスケード規則が第１の実行規則を有し、対象物マネージャが第２の異なる実行可能規則を呼び出すことにより、同一又は異なるエンジンにおいて連続的に実行される二つ以上の規則を有するようにされているデバイス。
8. システムであって、
   ネットワークであり、このネットワークは、
   サーバ段であり、ゲートウェイ・デバイスに駐留するアプリケーション層（図示せず）の中に分配された規則を生成するサーバ段と、
   ゲートウェイ段であり、前記生成された規則を受け取って、関数制御を受け取った規則へ転送するように構成されているゲートウェイと、
   前記ゲートウェイ・デバイスを含むネットワークにより相互接続された複数のノードとを支持し、各々のノードは、
   オペレーティング・システムを実行させているプロセッサと、
   前記プロセッサに通信するメモリとを含み、
   ネットワークにおける第１段から独立したソフトウェア・エージェントを受け取り、このソフトウェア・エージェントは、少なくとも１つの規則を含む動的にロードされた「ルート関数」であり、及び
   ノードのために確立した関数優先順位に従ってエンド・ノードのオペレーティング・システムにより独立したソフトウェア・エージェントに含まれる少なくとも一つの規則を実行するシステム。
9. 請求項８のシステムにおいて、前記規則がカスケード状規則であり、このカスケード状規則が複数のノードにおける複数の規則エンジンで実行されるシステム。
10. 請求項８のシステムにおいて、メッセージを生成することを更に含み、このメッセージは一つのノードから行動延期を指定する他のノードの入力へ渡されるように更に構成されているシステム。
11. 請求項８のシステムにおいて、
    前記規則の実行の結果を含むメッセージを生成し、前記段の異なる一つのアプリケーション層における異なる規則の実行をもたらすか若しくは引き起こすように更に構成されているシステム。
12. 請求項８のシステムにおいて、前記複数のノードの第１のノードが、
    カスケード状規則を実行し、第１の実行規則が第２の規則を呼び出すことにより、前記複数のノードの第１の一つのプロセッサ又は前記複数のノードの第１の一つ及び第２の一つのプロセッサにおいて連続的に実行される二つ以上の規則を有するようにされているシステム。
13. 請求項８のシステムにおいて、前記複数のノードの第１の一つが、
    カスケード状規則を実行し、前記カスケード規則が第１の実行規則を有し、対象物マネージャが第２の異なる実行可能規則を呼び出すことにより、前記複数のノードの第１の一つのプロセッサ又は前記複数のノードの第１の一つ及び第２の一つのプロセッサにおいて連続的に実行される二つ以上の規則を有するように構成されているシステム。

Images