(57)【要約】 【課題】  煩雑な作業を要求することなく、円滑且つ簡便に、機器間の連携制御を行い得るコントローラを提供する。【解決手段】  監視先機器の状態変数と、これが充足すべき条件と、この条件が充足されたときに実行される制御先機器の制御内容とを含む実行ルールを規定し、状態変数、条件、制御内容を記述した実行ルールをコントローラに設定して、監視先機器と制御先機器間の連携制御を行う。  ルール生成部１０３は、ユーザＩＦ部１０２からの連携制御データに応じて実行ルールを生成する。この実行ルールは実行ルールＤＢ１０６に格納される。状態信号受信部１０７は、機器から状態通知を受信するとこれに応じた状態変数とその値をルール実行部１０５に送る。ルール実行部１０５は、これに整合する実行ルールを実行ルールＤＢ１０６から抽出し、その制御内容をデバイス制御部１０８に送る。【選択図】    図１
2005130423.tif 000002
【特許請求の範囲】
【請求項１】
機器間の連携制御を設定するための入力手段と、前記入力手段から入力された連携制御情報から機器間を連携制御するための実行ルールを生成する実行ルール生成手段と、前記実行ルール生成手段によって生成された実行ルールを記憶する実行ルール記憶手段と、機器から供給された状態情報と前記実行ルール記憶手段に記憶されている実行ルール群とを比較し前記状態情報に適合する実行ルールを抽出する実行ルール抽出手段と、前記実行ルール抽出手段によって抽出された実行ルールに基づいて制御対象機器を制御する機器制御手段とを備え、
前記実行ルール生成手段によって生成される実行ルールは、監視先機器の状態変数と、当該状態変数が充足すべき条件と、前記条件が充足されたときに実行される制御先機器の制御内容を含み、
前記実行ルール抽出手段は、機器から供給された状態情報中の状態変数およびその値と、前記実行ルール記憶手段に記憶されたそれぞれの実行ルールの状態変数およびその条件とを比較し、両者が互いに整合する実行ルールを前記実行ルール記憶手段中の実行ルール群から抽出し、
前記制御手段は、前記実行ルール抽出手段によって抽出された実行ルールに含まれている制御先機器の制御内容に従って、当該制御先機器を制御する、
ことを特徴とするコントローラ。
【請求項２】
請求項１において、
前記機器はホームネットワーク等のローカルエリアネットワークに接続されており、前記実行ルール抽出手段は当該ネットワークを介して前記機器から状態情報を受信し、前記制御手段は当該ネットワークを介して制御信号を送信することにより制御対象機器を制御する、
ことを特徴とするコントローラ。
【請求項３】
請求項２において、
前記実行ルールに含まれる監視先機器の状態変数は、当該状態変数を識別するための情報と、当該監視先機器の種別を識別するための情報と、当該監視先機器の設置場所を識別するための情報を含み、
前記実行ルール抽出手段は、前記機器から受信した状態情報から、状態変数を識別するための情報と、当該機器の種別を識別するための情報と、当該機器の設置場所を識別するための情報と、当該状態変数の値とを含む情報を生成し、生成した情報と前記実行ルール群とを比較して、実行ルールの抽出を実行する、
ことを特徴とするコントローラ。
【請求項４】
請求項２または３において、
前記実行ルールに含まれる制御先機器の制御内容は当該制御先機器の状態変数とその値として規定されており、当該状態変数は、当該状態変数を識別するための情報と、当該監視先機器の種別を識別するための情報と、当該監視先機器の設置場所を識別するための情報を含み、
前記制御手段は、制御内容として含まれている前記監視先機器の種別を識別するための情報と、前記監視先機器の設置場所を識別するための情報から制御対象機器を特定し、且つ、制御内容として含まれている状態変数とその値から、当該制御対象機器の制御内容を確定する、
ことを特徴とするコントローラ。
【請求項５】
請求項１乃至４の何れかにおいて、
前記実行ルールには、当該実行ルールが実行されたときに前記実行ルール記憶手段から当該実行ルールを消去するか否かを設定するためのモード設定情報が含まれており、
前記制御手段は、実行ルールに従う制御を実行した後、当該実行ルールに含まれたモード設定情報を参照し、当該モード設定情報に従って当該実行ルールの消去を行う、
ことを特徴とするコントローラ。
【請求項６】
請求項１乃至４の何れかにおいて、
前記実行ルール生成手段によって生成される実行ルールは、監視先機器の状態変数と、当該状態変数が充足すべき条件と、前記条件が充足されたときに前記実行ルール記憶手段から消去される実行ルールを特定する情報を含む、
ことを特徴とするコントローラ。
【請求項７】
請求項１乃至６の何れかにおいて、
複数の監視先機器に設定された各設定条件が何れも充足されたときに制御先機器の制御動作が実行されるよう連携制御を設定する場合、前記実行ルールは、監視先機器の設定条件毎に準備され、準備されたそれぞれの実行ルールには、監視先機器の状態変数およびその条件と、当該準備された実行ルールを関連付けるための情報が含まれる、
ことを特徴とするコントローラ。
【請求項８】
請求項１乃至７の何れかにおいて、
前記実行ルール記憶手段は、監視先機器の状態変数毎に区分して、前記実行ルール群を記憶する、
ことを特徴とするコントローラ。
【請求項９】
請求項８において、
前記実行ルール記憶手段は、同一の監視先機器の状態変数に対して、当該状態変数が充足すべき条件と、前記条件が充足されたときに実行される制御先機器の制御内容とからなる組を複数組対応付けて記憶できるよう、記憶情報のデータ構造を構成し、前記実行ルール生成手段によって実行ルールが生成されたとき、当該実行ルールから監視先機器の状態変数が充足すべき条件と、前記条件が充足されたときに実行される制御先機器の制御内容とを抽出して組を構成し、この組を、該当する監視先機器の状態変数に対応付けて記憶する、
ことを特徴とするコントローラ。
【請求項１０】
請求項８または９において、
前記実行ルール抽出手段は、機器から供給された状態情報中の状態変数と、前記実行ルール記憶手段に記憶された実行ルール群を区分する前記監視先機器の状態変数とを比較して、両者が互いに整合する前記監視先機器の状態変数を特定し、特定した監視先機器の状態変数に対応付けられた実行ルール群の中から、前記機器から供給された状態情報中の状態変数の値に該当する条件を含む実行ルールを抽出する、
ことを特徴とするコントローラ。
【請求項１１】
請求項８ないし１０の何れかにおいて、
前記実行ルール記憶手段は、前記実行ルールを記憶するとき、前記実行ルール生成手段によって生成された実行ルール中の監視先機器の状態変数に一致する前記状態変数の区分を検索し、検索した当該区分に属する前記条件ー制御内容の組と、記憶対象とされる実行ルールの前記条件および制御内容とを比較して、両者に矛盾がないかを判別し、判別結果に応じて記憶を制御する、
ことを特徴とするコントローラ。
【請求項１２】
請求項８ないし１０の何れかにおいて、
前記実行ルール記憶手段は、既に記憶済みの実行ルール群のうち、前記監視先機器の状態変数の区分に属する前記条件ー制御内容の組を比較して、相互矛盾のある組を検出し、検出結果に応じて既記憶情報を制御する、
ことを特徴とするコントローラ。
【請求項１３】
請求項１１または１２において、
前記実行ルール記憶手段は、前記条件が重複し、且つ、前記制御内容が相違する場合に、両実行ルール間に矛盾があると判別する、
ことを特徴とするコントローラ。
【請求項１４】
少なくとも、上記請求項１ないし１３の何れかに記載の各手段の機能をコンピュータに付与するためのプログラム。
【請求項１５】
少なくとも、上記請求項１ないし１３の何れかに記載の各手段の機能をコンピュータに付与するためのプログラムを格納した記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザからの指令入力に応じて機器を制御するコントローラに関し、特に、複数の家庭内機器を連携制御する際に用いて好適なものである。
【背景技術】
【０００２】
近年、ホームネットワークを介して家庭内機器を制御する、いわゆるネートワーク家電システムが提案され、規格化されている。このシステムは、ホームサーバ等のコントローラをホームネットワークに接続し、このコントローラから制御コマンドを送信することによって、対象機器を制御するものである。ここで、コントローラと家庭内機器との間の通信は、ＥＣＨＯＮＥＴ、ＵＰｎＰ、ＳＣＰ等の通信プロトコルを利用して行われる。また、通信網としては、各家庭内機器に電源を供給する電源供給線等が利用される。すなわち、家庭内機器とコントローラのコンセントを電源ターミナルに接続することにより、家庭内機器とコントローラがホームネットワークに接続される。
【０００３】
なお、かかるネットワークシステムの構成例として、たとえば以下の特許文献１に記載のものが知られている。
【特許文献１】特開平１０−２７６４７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記ホームネットワークシステムでは、たとえば、リビングルームの電動ブラインドが閉じられたらリビングルームの照明機器をＯＮする等、複数の家庭内機器を互いに連携させて制御する場面が想定される。
【０００５】
しかし、ＵＰｎＰ等の既存技術では、この種の連携制御を円滑且つ簡便に行えない。すなわち、既存のＵＰｎＰは、機器制御信号を出力するコントロールポイント（ＣＰ）と、ＣＰによって制御される一つまたは複数のデバイス（ホームネットワークシステムでは家庭内機器）から構成されており、デバイスの制御は、ＣＰが個々のデバイスに制御信号を出力し、その応答をデバイスから受け取ることによって実現される。つまり、ＣＰと個々のデバイスとは１対１の対応になっており、このため、デバイス間の連携制御を行うためには、複数の制御信号を組み合わせて動作させるためのアプリケーションを、ＣＰに対して作成しなければならない。この場合、アプリケーションプログラムを記述するプログラム技術が必要となり、このため、一つの連携制御を設定するために煩雑な作業が必要となる。
【０００６】
また、ＵＰｎＰにおいては、新たなデバイスが追加された場合に、このデバイスからＣＰに対して、自身が有する機能が宣言されることとなるが、この機能を、他のデバイス間の連携制御に含める場合、既存のアプリケーションプログラムを改変または新たに作り直さなければならず、さらに煩雑な作業が必要となる。
【０００７】
そこで、本発明は、それほど煩雑な作業を要求することなく、円滑且つ簡便に、機器間の連携制御を行い得るコントローラを提供することを課題とする。
【課題を解決するための手段】
【０００８】
本発明は、監視先機器の状態変数と、当該状態変数が充足すべき条件と、当該条件が充足されたときに実行される制御先機器の制御内容とを含む実行ルールを規定し、これら状態変数、条件、制御内容を記述した実行ルールをコントローラに設定することにより、監視先機器と制御先機器間の連携制御を行うものである。
【０００９】
各請求項に記載の発明の特徴は以下のとおりである。
【００１０】
請求項１の発明は、コントローラとして発明を把握したものであり、このコントローラは、機器間の連携制御を設定するための入力手段と、前記入力手段から入力された連携制御情報から機器間を連携制御するための実行ルールを生成する実行ルール生成手段と、前記実行ルール生成手段によって生成された実行ルールを実行ルール毎に区分して記憶する実行ルール記憶手段と、機器から供給された状態情報と前記実行ルール記憶手段に記憶されている実行ルール群とを比較し前記状態情報に適合する実行ルールを抽出する実行ルール抽出手段と、前記実行ルール抽出手段によって抽出された実行ルールに基づいて制御対象機器を制御する機器制御手段とを備える。ここで、前記実行ルール生成手段によって生成される実行ルールは、監視先機器の状態変数と、当該状態変数が充足すべき条件と、前記条件が充足されたときに実行される制御先機器の制御内容を含んでいる。そして、前記実行ルール抽出手段は、機器から供給された状態情報中の状態変数およびその値と、前記実行ルール記憶手段に記憶されたそれぞれの実行ルールの状態変数およびその条件とを比較し、両者が互いに整合する実行ルールを前記実行ルール記憶手段中の実行ルール群から抽出し、前記制御手段は、前記実行ルール抽出手段によって抽出された実行ルールに含まれている制御先機器の制御内容に従って、当該制御先機器を制御する。
【００１１】
請求項２の発明は、請求項１に記載のコントローラにおいて、前記機器は、ホームネットワーク等のローカルエリアネットワークに接続されており、前記実行ルール抽出手段は、当該ネットワークを介して前記機器から状態情報を受信し、前記制御手段は当該ネットワークを介して制御信号を送信することにより制御対象機器を制御することを特徴とする。
【００１２】
請求項３の発明は、請求項２に記載のコントローラにおいて、前記実行ルールに含まれる監視先機器の状態変数は、当該状態変数を識別するための情報と、当該監視先機器の種別を識別するための情報と、当該監視先機器の設置場所を識別するための情報を含んでいる。そして、前記実行ルール抽出手段は、前記機器から受信した状態情報から、状態変数を識別するための情報と、当該機器の種別を識別するための情報と、当該機器の設置場所を識別するための情報と、当該状態変数の値とを含む情報を生成し、生成した情報と前記実行ルール群とを比較し、生成した情報に整合する実行ルールを実行ルール記憶手段中の実行ルール群から抽出する。
【００１３】
請求項４の発明は、請求項２または３に記載のコントローラにおいて、前記実行ルールに含まれる制御先機器の制御内容は、当該制御先機器の状態変数とその値として規定されており、当該状態変数は、当該状態変数を識別するための情報と、当該監視先機器の種別を識別するための情報と、当該監視先機器の設置場所を識別するための情報を含む。そして、前記制御手段は、制御内容として含まれている前記監視先機器の種別を識別するための情報と、前記監視先機器の設置場所を識別するための情報から制御対象機器を特定し、且つ、制御内容として含まれている状態変数とその値から、当該制御対象機器の制御内容を確定する。
【００１４】
請求項５の発明は、請求項１乃至４の何れかに記載のコントローラにおいて、前記実行ルールには、当該実行ルールが実行されたときに前記実行ルール記憶手段から当該実行ルールを消去するか否かを設定するためのモード設定情報が含まれている。そして、前記制御手段は、実行ルールに従う制御を実行した後、当該実行ルールに含まれたモード設定情報を参照し、当該モード設定情報に従って当該実行ルールの消去を行う。
【００１５】
請求項６の発明は、請求項１乃至４の何れかに記載のコントローラにおいて、前記実行ルール生成手段によって生成される実行ルールは、監視先機器の状態変数と、当該状態変数が充足すべき条件と、前記条件が充足されたときに前記実行ルール記憶手段から消去される実行ルールを特定する情報を含むことを特徴とする。
【００１６】
請求項７の発明は、請求項１乃至６の何れか記載のコントローラにおいて、複数の監視先機器に設定された各設定条件が何れも充足されたときに制御先機器の制御動作が実行されるよう連携制御を設定する場合、前記実行ルールは、監視先機器の設定条件毎に準備され、準備されたそれぞれの実行ルールには、監視先機器の状態変数およびその条件と、当該準備された実行ルールを関連付けるための情報が含まれることを特徴とする。
【００１７】
請求項８の発明は、請求項１乃至７の何れかに記載のコントローラにおいて、前記実行ルール記憶手段は、監視先機器の状態変数毎に区分して、前記実行ルール群を記憶することを特徴とする。
【００１８】
請求項９の発明は、請求項８に記載のコントローラにおいて、前記実行ルール記憶手段は、同一の監視先機器の状態変数に対して、当該状態変数が充足すべき条件と、前記条件が充足されたときに実行される制御先機器の制御内容とからなる組を複数組対応付けて記憶できるよう、記憶情報のデータ構造を構成し、前記実行ルール生成手段によって実行ルールが生成されたとき、当該実行ルールから監視先機器の状態変数が充足すべき条件と、前記条件が充足されたときに実行される制御先機器の制御内容とを抽出して組を構成し、この組を、該当する監視先機器の状態変数に対応付けて記憶することを特徴とする。
【００１９】
請求項１０の発明は、請求項８または９に記載のコントローラにおいて、前記実行ルール抽出手段は、機器から供給された状態情報中の状態変数と、前記実行ルール記憶手段に記憶された実行ルール群を区分する前記監視先機器の状態変数とを比較して、両者が互いに整合する前記監視先機器の状態変数を特定し、特定した監視先機器の状態変数に対応付けられた実行ルール群の中から、前記機器から供給された状態情報中の状態変数の値に該当する条件を含む実行ルールを抽出することを特徴とする。
【００２０】
請求項１１の発明は、請求項８ないし１０の何れかに記載のコントローラにおいて、前記実行ルール記憶手段は、前記実行ルールを記憶するとき、前記実行ルール生成手段によって生成された実行ルール中の監視先機器の状態変数に一致する前記状態変数の区分を検索し、検索した当該区分に属する前記条件ー制御内容の組と、記憶対象とされる実行ルールの前記条件および制御内容とを比較して、両者に矛盾がないかを判別し、判別結果に応じて記憶を制御することを特徴とする。
【００２１】
請求項１２の発明は、請求項８ないし１０の何れかに記載のコントローラにおいて、前記実行ルール記憶手段は、既に記憶済みの実行ルール群のうち、前記監視先機器の状態変数の区分に属する前記条件ー制御内容の組を比較して、相互矛盾のある組を検出し、検出結果に応じて既記憶情報を制御することを特徴とする。
【００２２】
請求項１３の発明は、請求項１１または１２に記載のコントローラにおいて、前記実行ルール記憶手段は、前記条件が重複し、且つ、前記制御内容が相違する場合に、両実行ルール間に矛盾があると判別することを特徴とする。
【００２３】
請求項１４の発明は、本発明をプログラムとして把握したものであり、少なくとも、上記請求項１ないし１３の何れかに記載の各手段の機能をコンピュータに付与するためのプログラムである。
【００２４】
請求項１５の発明は、本発明を記憶媒体として把握したものであり、少なくとも、上記請求項１ないし１３の何れかに記載の各手段の機能をコンピュータに付与するためのプログラムを格納した記憶媒体である。
【００２５】
なお、本発明は、家庭内機器の連携制御に限らず、他の機器間の連携制御にも適用できるものである。
【００２６】
本発明の特徴ないしその技術的意義および効果は、以下に示す実施の形態の説明により更に明らかとなろう。ただし、以下の実施の形態は、あくまでも、本発明の一つの実施形態であって、本発明ないし各構成要件の用語の意義等は、以下の実施の形態に記載されたものに制限されるものではない。
【発明の効果】
【００２７】
本発明によれば、状態変数、条件、制御内容を記述した実行ルールをコントローラに設定することにより、監視先機器と制御先機器間の連携制御を行うものであるから、別途、複雑なアプリケーションプログラムを生成せずとも、各機器間の連携制御を簡易に設定することができる。
【００２８】
また、新たな機器がネットワークに接続された場合にも、当該機器に関連する以外の既存の実行ルールを改変または書き換える必要はなく、当該新たな機器に関する実行ルールの改変または新規実行ルールの生成のみを行うだけで済む。
【００２９】
また、請求項２ないし４に示すように、監視先機器およびその状態条件と、制御先機器およびその制御状態を、機器の状態変数、機器の種別、機器の設置場所および状態変数の値（条件）として規定することにより、ネットワークに接続された各機器とその状態を円滑且つ適正に特定することができ、連携制御を効率的に行うことができる。特に、監視先機器およびその状態条件と、制御先機器およびその制御状態を、以下の実施の形態にように、共通のデータ単位（イベント）にて管理するようにすれば、監視先機器の状態と実行ルールの照合処理を簡素化でき、連携制御時の処理負担を軽減できる。
【００３０】
さらに、請求項５に記載のように、実行ルールの消去の可否を設定できるようにすれば、定常的に行われる連携制御をその都度再設定する手間を省くことができ、連携制御設定時の手続をより一層簡素化できる。
【００３１】
また、請求項６に記載のように、実行ルール生成手段によって生成される実行ルールが、監視先機器の状態変数と、当該状態変数が充足すべき条件と、前記条件が充足されたときに前記実行ルール記憶手段から消去される実行ルールを特定する情報を含むようにすれば、ルール実行と同様に処理にて実行済みルールを消去することができ、実行済みルールの消去処理の簡素化を図ることができる。
【００３２】
また、請求項７のようにして実行ルールを設定することにより、複数の監視先機器に設定された各設定条件が何れも充足されたときに制御先機器の制御動作が実行されるような連携制御を設定することができる。
【００３３】
また、請求項８または９のように、監視先機器の状態変数毎に区分して実行ルール群を記憶するようにすれば、連携制御時における実行ルールの抽出処理を簡素化することができる。すなわち、請求項１０に示すように、機器から供給された状態情報中の状態変数と、前記実行ルール記憶手段に記憶された実行ルール群を区分する前記監視先機器の状態変数とを比較して、両者が互いに整合する前記監視先機器の状態変数を特定し、特定した監視先機器の状態変数に対応付けられた実行ルール群の中から、前記機器から供給された状態情報中の状態変数の値に該当する条件を含む実行ルールを抽出することにより、実行ルール記憶手段に記憶された全ての実行ルールを全検索せずとも、効率的に、連携制御に必要な実行ルールを抽出することができる。
【００３４】
また、請求項８または９の発明によれば、実行ルール間の相互矛盾を簡易に検出できるとの効果を奏することもできる。すなわち、請求項１１ないし１３に示すように、実行ルール記憶手段に記憶された全ての実行ルールを全検索せずとも、一つの監視先機器の状態変数の区分に属する条件ー制御内容の組を調べるだけで、実行ルール間の相互矛盾を検出することができ、よって、相互矛盾の検出処理を簡素化することができる。
【００３５】
加えて、請求項８または９の発明によれば、以下の実施例４に記載のように、実行ルール群のメンテナンス作業を簡易化できるとの効果をも、同時に、奏することができる。
【００３６】
上記各請求項に記載の発明の効果は、以下に示す実施の形態の説明によって、さらに明らかになろう。
【発明を実施するための最良の形態】
【００３７】
以下、本発明の実施の形態につき図面を参照して説明する。
【実施例１】
【００３８】
図１に実施例１に係るホームネットワークシステムの構成を示す。
【００３９】
本実施例では、コントローラ１００と家庭内機器１ａ〜１ｃ、２ａ〜２ｇ、…がホームネットワークを介して接続されている。ここで、コントローラ１００と家庭内機器１ａ〜１ｃ、２ａ〜２ｇ、…との間の通信は、上記従来例と同様、ＥＣＨＯＮＥＴ、ＵＰｎＰ、ＳＣＰ等の通信プロトコルを利用できる。また、通信網としては、各家庭内機器に電源を供給する電源供給線等を利用できる。
【００４０】
なお、本実施例に係るコントローラ１００は、ハードウェア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩなどで実現できる。また、ソフトウェア的には、メモリにロードされた記録制御機能のあるプログラムなどによって実現できる。図１には、ハードウェアおよびソフトウェアによって実現されるコントローラ１００の機能ブロックが示されている。これらの機能ブロックが、ハードウェアのみ、ソフトウェアのみ、あるいは、これらの組合せ等、いろいろな形態で実現できることは言うまでもない。
【００４１】
図１に示すとおり、コントローラ１００は、通信制御部１０１と、ユーザＩＦ部１０２と、ルール生成部１０３と、デバイスＤＢ１０４と、ルール実行部１０５と、実行ルールＤＢ１０６と、状態信号受信部１０７と、デバイス制御部１０８とから構成されている。
【００４２】
通信制御部１０１は、インターネット等の外部通信網を介したデータ通信を制御する。ここで、通信制御部１０１は、外部から連携制御用データを受信すると、これをルール生成部１０３に出力する。なお、この連携制御用データには、送信元ユーザのユーザＩＤとそのパスワードが付されている。通信制御部１０１は、連携制御データと共に、これらユーザＩＤとパスワードをルール生成部１０３に送る。
【００４３】
ユーザＩＦ部１０３は、連携制御設定用の入力画面、たとえばＧＵＩ（Graphic User Interface）等により構成された入力画面をユーザに提示する。そして、この入力画面を介して入力された連携制御用データをルール生成部１０２に出力する。なお、かかる入力画面には、ユーザＩＤとパスワードの入力を要求する項目が含まれている。したがって、ユーザからは、連携制御データと共に、自己のユーザＩＤとパスワードが同時に入力される。ユーザＩＦ部１０１は、これらユーザＩＤとパスワードを、連携制御データと共に、ルール生成部１０３に送る。
【００４４】
ルール生成部１０３は、ユーザＩＦ部１０３または通信制御部１０１から受信した連携制御データに応じて実行ルール（後述）を生成し、これをルール実行部１０４に出力する。このとき、かかる連携制御の設定権限の是非を、通信制御部１０１またはユーザＩＦ部１０２から受信したユーザＩＤおよびパスワードと、デバイスＤＢに格納されたユーザＩＤおよびパスワードとを比較して検証する。ここで、デバイスＤＢ１０４は、ホームネットワークに接続されている家庭内機器の情報を格納するデータベースである。
【００４５】
図２に、デバイスＤＢ１０４に格納されているデータの構成を示す。デバイスＤＢ１０４には、家庭内機器の名称（デバイス名）と、当該家庭内機器の設置場所（ロケーション）と、当該家庭内機器を利用できるユーザの識別情報（ユーザＩＤ）と、そのパスワードが、デバイス毎に区分して格納されている。なお、デバイスＤＢ１０４には、家庭内機器がホームネットワークに接続される際に、図２に示す当該機器の情報が、自動または手動にて登録される。
【００４６】
ルール生成部１０３は、通信制御部１０１またはユーザＩＦ部１０２から受信した連携制御用データに基づいて実行ルールを生成するに先立ち、制御先機器のユーザＩＤとパスワードをデバイスＤＢ１０４から抽出し、これらが、通信制御部１０１またはユーザＩＦ部１０２から受信したユーザＩＤおよびパスワードに一致するかを検証する。そして、一致するときは、受信した連携制御用データに基づいて実行ルールを生成し、ルール実行部１０５に出力する。他方、一致しないときは、エラー通知を、通信制御部１０１またはユーザＩＦ部１０２に送る。
【００４７】
図１に戻り、ルール実行部１０５は、ルール生成部１０３から受信した実行ルールを実行ルールＤＢ１０６に登録する。また、状態信号受信部１０７から状態データ（イベント）を受信すると、実行ルールＤＢ１０６に登録された実行ルールを参照し、適宜、制御データ（アクション）をデバイス制御部１０８に出力する。なお、イベントとアクションの構成およびルール実行部１０５における処理については、追って詳述する。また、実行ルールＤＢ１０６に登録されるデータの構成についても、追って詳述する。
【００４８】
状態信号受信部１０７は、ホームネットワークを介して家庭内機器１ａ〜１ｃ、２ａ〜２ｇ、…から受信した状態信号（ＥＣＨＯＮＥＴ、ＵＰｎＰ、ＳＣＰ等の通信プロトコルに従うもの）を状態データ（イベント）に変換し、これをルール実行部１０５に出力する。
【００４９】
デバイス制御部１０８は、ルール実行部１０５から受信した制御データ（アクション）を制御信号（ＥＣＨＯＮＥＴ、ＵＰｎＰ、ＳＣＰ等の通信プロトコルに従うもの）に変換し、ホームネットワークを介して、制御対象の家庭内機器に送信する。また、状態信号を送信しない機器（例えば図１の照明機器２ｇ）に対して制御信号を送信した場合には、当該制御動作に応じた状態データ（イベント）の生成を代行し、生成した状態データ（イベント）をルール実行部１０５に送る。なお、制御先機器が状態信号を送信する機器であるか否かの判別は、たとえば、家庭内機器の機能・仕様を記述した管理テーブルを参照することにより行われる。この管理テーブルは、デバイス制御部１０８に内蔵されている形態の他、デバイスＤＢ１０４に併せて登録しておき、これを参照する形態としても良い。
【００５０】
次に、図３を参照して、イベントの構造と、実行ルールの構造について説明する。
【００５１】
図３（ａ）は、イベントの構造を示すものである。ここで、イベントとは、オブジェクト（デバイスの状態：後述）を規定するための最小データ単位であり、オブジェクトを識別するためのイベント節と、オブジェクトの内容を規定するための“Value”から構成されている。
【００５２】
通常、機器間の連携制御を行う場合には、一つの機器（監視先機器）がある状態になったときに、他の機器（制御先機器）の状態を変更する制御形態がとられる。本実施の形態では、監視先機器の状態と制御先機器の状態を、“オブジェクト”という共通の概念で捉え、この概念を“イベント”というデータ単位で表現する。
【００５３】
したがって、監視先機器の状態と制御先機器の状態は、共に、イベントによって表現される。例えば、「リビングルームの温度が２６度になったらリビングルームの冷房をＯＮ」という連携制御を設定する場合、監視先機器を温度計とし、制御先機器をエアコンとすると、温度計の温度状態と、エアコンの駆動状態が共にイベントによって表現される。
【００５４】
なお、イベントは、図３（ａ）に示すように、Name、Device、Location、Valueに区分されている。
【００５５】
このうち、“Name”は、当該機器の状態変数を規定するものである。たとえば、当該機器がエアコンであれば、「冷房」、「暖房」、「除湿」、「送風」等である。また、“Device”は、当該機器の名称を規定するものである。たとえば、エアコン、温度計、ＤＶＤ等である。また、“Location”は、当該機器の設置場所を規定するものである。たとえば、リビングルーム、玄関、子供部屋１、子供部屋２、等である。また、“Value”は、“Name”によって規定された状態変数の内容（値）を規定するものである。たとえば、“Name”が温度であれば「２６度」、また、“Name”が冷房であれば「ＯＮ」等である。
【００５６】
連携制御において、かかるイベントは、監視先機器であれば、当該監視先機器における現時点のオブジェクトの内容を示し、また、制御先機器であれば、当該制御先機器における制御後のオブジェクトの内容を示すこととなる。たとえば、上記のように「リビングルームの温度が２６度になったらリビングルームの冷房をＯＮ」という連携制御を設定する場合、監視先オブジェクトは、Name＝温度、Device＝温度計、Location＝リビングルーム、Value＝２６度以上となり、制御先オブジェクトは、Name＝冷房、Device＝エアコン、Location＝リビングルーム、Value＝ＯＮとなる。
【００５７】
本実施の形態において、かかる連携制御は、図３（ｂ）に示す実行ルールによって規定される。
【００５８】
ここで、一つの実行ルールは、同図に示す如く、イベントと、コンディションと、アクションによって構成される。このうち、イベントには、監視先オブジェクトのイベント節が記述される。また、コンディションには、監視先オブジェクトのValueに基づく判断条件が記述される。さらに、アクションには、制御先オブジェクトのイベントがそのまま記述される。かかる実行ルールは、上記の如く、ルール生成部１０３によって生成される。生成された実行ルールは、逐次、実行ルールＤＢ１０６に登録される。
【００５９】
図４に、実行ルールＤＢ１０６に登録された実行ルールの構成例を示す。
【００６０】
図において、ルールNo.001には、上述した「リビングルームの温度が２６度以上になったらリビングルームの冷房をＯＮ」の実行ルールが登録されている。すなわち、当該実行ルールのイベントには、監視先オブジェクトのイベント節として、Name＝温度、Device＝温度計、Location＝リビングルームが記述されている。また、コンディションには、監視先オブジェクトのValueとして、Value＝２６度以上が記述されている。そして、アクションには、制御先オブジェクトのイベントとして、Name＝冷房、Device＝エアコン、Location＝リビングルーム、Value＝ＯＮが記述されている。
【００６１】
なお、かかる実行ルールを用いて、３つ以上の機器を連携制御することもできる。
【００６２】
同図に示す“Ａ”は、３つの機器を連続的に連携制御するときの実行ルールを例示したものである。すなわち、ルールNo.002の実行ルールとルールNo.003の実行ルールによって、「午後６時になったら、玄関の照明をつけて、リビングルームのブラインドを閉める。」との連携制御が設定されている。
【００６３】
ここで、ルールNo.002の実行ルールには、「午後６時になったら玄関の照明をつける。」との連携制御が設定され、また、ルールNo.003の実行ルールには、「玄関の照明がついたら、リビングルームの電動ブラインドを閉める。」との連携制御が設定されている。したがって、ルールNo.002の実行ルールが実行されると、ルールNo.003の実行ルールが引き続き実行されることになり、これにより、時計と照明機器と電動ブラインドが一連の流れの中で連携制御される。
【００６４】
また、同図に示す“Ｂ”は、２つの機器の状態を条件として、他の機器を連携制御するときの実行ルールを例示したものである。すなわち、ルールNo.010の実行ルールとルールNo.011の実行ルールによって、「リビングルームの電動ブラインドが閉じられ、且つ、リビングルームの人感センサーが人を検出したら、リビングルームの照明をつける。」との連携制御が設定されている。
【００６５】
ここで、ルールNo.010の実行ルールには、通常の連携制御時と同様、監視先オブジェクトのイベントが“イベント”と“コンディション”に記載されるが、アクションには、制御先オブジェクトのイベントに代えて、ジャンプ先実行ルールであるルールNo.011が記述される。これにより、ルールNo.010に記述された監視先機器（リビングルームの電動ブラインド）の“イベント”および“コンディション”と、ルールNo.011に記述された監視先機器（リビングルームの人感センサー）の“イベント”および“コンディション”の両方が同時に充足されたときに、ルールNo.012に記述された監視先機器（リビングルームの照明機器）の“アクション”が実行される。
【００６６】
上記実行ルールは、実行ルール生成部１０３によって生成される。このとき、通信制御部１０１またはユーザＩＦ部１０２からは、上記実行ルールの作成に必要なデータすなわち、監視先機器と制御先機器のオブジェクトを特定するためのデータが、連携制御データとして、ルール生成部１０３に供給される。たとえば、ユーザＩＦ部１０２における入力画面には、これらのデータを取得するための入力項目が含まれている。
【００６７】
次に、上記ホームネットワークシステムにおける連携制御時の動作について、図５のフローチャートを参照して説明する。
【００６８】
ホームネットワークに接続された機器から状態通知（状態信号）を受信すると（Ｓ２０１、Ｓ１０１）、状態信号受信部１０７は、この状態通知をイベントに変換し（Ｓ１０２）、これを、ルール実行部１０５に送る。ルール実行部１０５は、受信したイベントのイベント節と、実行ルールＤＢ１０６に登録されているそれぞれの実行ルールの“イベント”とを比較し、当該イベント節に一致する“イベント”が記述された実行ルールが実行ルールＤＢ１０６中に登録されているかを判別する（Ｓ１０４）。
【００６９】
ここで、該当する実行ルールが実行ルールＤＢ１０４中に登録されていない場合には、Ｓ１０１に戻り、次の状態通知の受信を待つ。他方、該当する実行ルールが登録されている場合には、当該実行ルールのコンディションと状態信号受信部１０７から受信したイベント中のValueとを比較し（Ｓ１０５）、このValueが当該実行ルールのコンディションに適合するかを判別する（Ｓ１０６）。
【００７０】
ここで、Valueがコンディションに適合しない場合には、Ｓ１０１に戻り、次の状態通知の受信を待つ。他方、Valueがコンディションに適合する場合には、当該実行ルールの“アクション”をデバイス制御部１０８に送る。デバイス制御部１０８は、受け取った“アクション”のうち、“Device”と“Location”の規定から制御対象機器を特定すると共に、“Name”と“Value”から当該機器の制御内容を把握する。そして、当該制御内容に応じた制御信号を生成し、これを当該制御先機器に送信する（Ｓ１０７）。
【００７１】
制御対象機器は、制御信号を受信すると（Ｓ２０２）、自己の動作状態を当該制御信号に応じた動作状態に切り替え（Ｓ２０３）、切り換え後の動作状態を示す状態通知（状態信号）を状態信号受信部１０７に送信する（Ｓ２０４）。状態信号受信部１０７は、受け取った状態通知をイベントに変換し、これをルール実行部１０５に送る（Ｓ１０８）。ルール実行部１０５は、受け取ったイベントから実行済みルールを特定し、当該実行済み実行ルールを実行ルールＤＢから消去する（Ｓ１０９）。そして、Ｓ１０１に戻り、次の状態通知の受信を待つ。
【００７２】
なお、Ｓ１０７において、状態通知の送信を行わない機器に対し制御信号が送信された場合、Ｓ２０２〜Ｓ２０４の処理は省略される。このとき、当該制御動作が制御対象機器にて実行されたと仮定して、デバイス制御部１０８によりイベントが生成され、これがルール実行部１０５に送られる。ルール実行部１０５は、かかるイベントに基づいて、上記Ｓ１０８の処理を行う。
【００７３】
以上、本実施の形態によれば、“イベント”、“コンディション”、“アクション”を記述した実行ルールを生成し、これを実行ルールＤＢ１０６に登録するのみで機器間の連携制御を実行することができるから、別途、複雑なアプリケーションプログラムを生成せずとも、各機器間の連携制御を簡易に設定することができる。
【００７４】
また、新たな機器がホームネットワークに接続された場合にも、当該機器に関連する以外の既存の実行ルールを改変または書き換える必要はなく、当該新たな機器に関する実行ルールの改変または新規実行ルールの生成のみを行うだけで済む。
【実施例２】
【００７５】
上記実施例１では、実行済み実行ルールを実行ルールＤＢ１０６から消去するようにしたが、ユーザの設定により、実行ルールの消去を制限するようにしても良い。具体的には、図６に示すように、実行ルールＤＢ１０６に格納されるデータに“設定モード”を含め、制御データの入力時に、ユーザの意思により、実行済み実行ルールの消去の可否を任意に設定できるようにする。なお、同図において、設定モードが“１”のときは実行済み実行ルールの消去が制限される。
【００７６】
この場合、連携制御時の処理フローは、図７のように変更される。すなわち、上記図５の処理フローに比べ、Ｓ１２１が追加され、制御対象機器から状態通知を受け取ったときは（Ｓ１０８）、当該実行済み実行ルールの設定モードが“０”の場合のみ（Ｓ１２１）、当該実行済み実行ルールが実行ルールＤＢ１０６から消去される（Ｓ１０９）。
【００７７】
図６および図７の変更例によれば、定常的に行われる連携制御をその都度再設定する手間を省くことができ、連携制御設定時の手続をより一層簡素化できる。
【実施例３】
【００７８】
上記実施例１では、機器から送信された状態通知からイベントを生成し、このイベントをルール実行部１０５が解釈して実行済みルールを特定し、特定された実行済みルールを消去するようにしたが、たとえば、図８に示すように、実行済みルールを消去するための実行ルール（同図のNo.004の実行ルール）を実行ルールＤＢ１０６に登録しておき、この実行ルールに基づいて実行済みルールを実行ルールＤＢ１０６から削除するようにすることもできる。これによれば、ルール実行部１０５に対し、実行済みルールを特定する処理負担を負わせる必要がなくなり、ルール実行部１０５における処理を簡素化することができる。
【００７９】
なお、図８に示す（Ａ）の場合には、No.002およびNo.003の実行ルールにより、「午後６時になったら、玄関の照明をつけて、リビングルームのブラインドを閉める。」との連携制御が行われ、この連携制御の実行により「リビングルームのブラインドを閉めた。」との状態通知が電動ブラインドから送信されると、この状態通知に応じたイベント、Name＝開閉状態、Device＝電動ブラインド、Location＝リビングルーム、Value＝閉が状態信号受信部１０７からルール実行部１０５に送られる。そして、このイベントに整合するNo.002の実行ルールが実行され、そのアクションとして、No.002〜No.004の実行ルールが実行ルールＤＢ１０６から削除される。
【００８０】
また、上記実施の形態では、コンディションが記述されている実行ルールを例示したが、コンディションの記述を省略した実行ルールを実行ルールＤＢ１０６に登録する連携制御の形態も有り得る。たとえば、監視対象機器の状態変数が変化した（変化の条件は限定せず）ときに制御対象機器に特定（アクション）の動作を実行させる場合、実行ルールには、“イベント”のみが記述され、コンディションはＮＵＬＬとされる。このとき、“イベント”に記述された状態変数に関する状態通知が監視対象機器から送信されると、当該状態変数の値（Value）に拘わらず一律に、当該実行ルールのアクションに記述された制御動作が実行される。
【実施例４】
【００８１】
上記実施例では、連携制御毎に実行ルールを生成し、これを実行ルールＤＢ１０６に個別に登録するようにしたが、これに代えて、図９に示すように、共通する一つのイベントに対して複数種類のコンディションとアクションの組を登録するようにしても良い。この場合、一組のコンディションとアクション（ペア）によって、一つの連携制御が設定される。
【００８２】
たとえば、図９において、ルールNo.001には、Name＝温度、Device＝温度計、Location＝リビングルームのイベントに関する連携制御が、ペア毎に登録されている。このうち、ペアNo.001には、「温度が２６度以上になったら、リビングルームの冷房をＯＮ」のコンディションとアクションが設定されており、また、ペアNo.002には、「温度が２３度以下になったら、リビングルームの冷房をＯＦＦ」のコンディションとアクションが設定されている。
【００８３】
また、同図中、ルールNo.033には、Name＝開閉状態、Device＝電動ブラインド、Location＝リビングルームのイベントに関する連携制御が、ペア毎に登録されている。このうち、ペアNo.001には、「開閉状態が閉になったら、ルールNo.12のペアNo.3のペアと、自身（ルールNo.33のペアNo.1のペア）を消去」のコンディションとアクションが設定されており、また、ペアNo.002には、「開閉状態が閉になったら、ルールNo.36のペアNo.3のペアの制御を実行」のコンディションとアクションが設定されている。
【００８４】
このように、本実施例では、ペア単位で、連携制御が登録される。連携制御の追加および消去、修正はペア毎に行われる。また、一つの制御と他の制御のリンクもペアを用いて行われる。なお、ペアの追加、削除の処理動作については、追って、フローチャートを参照して詳述する。
【００８５】
図１０に、本実施例に係るコントローラ１００の構成例を示す。
【００８６】
コントローラ１００は、上記図１に示すコントローラ１００に比べ、ルール実行部１１０の機能が相違している。すなわち、ルール実行部１１０は、上記図１のルール実行部１０５の機能に加え、さらに、ルール生成部１０３によって生成された実行ルールが、既に実行ルールＤＢ１０６に登録されている実行ルール（ペア）と矛盾するか否かを判定する矛盾判定機能と、矛盾がないときに、ルール生成部１０３から供給された実行ルールからコンディションとアクションを抽出してペアを構成し、これを該当するルールＮｏ．に追加するルール合成機能を有している。
【００８７】
なお、実行ルールＤＢ１０６のデータ構造は、上記図９に示す如く変更される。その他の構成については、上記図１と同じである。
【００８８】
図１１に、実行ルール登録時の処理動作を示す。
【００８９】
ルール生成部１０３によって実行ルールが生成されると（Ｓ３０１）、ルール実行部１１０は、実行ルールＤＢ１０６を参照し（Ｓ３０２）、生成された実行ルールのイベントと同じイベントが既に実行ルールＤＢ１０６中に存在するかを判別する（Ｓ３０３）。ここで、存在しなければ（Ｓ３０３：ＮＯ）、生成された実行ルールを実行ルールＤＢ１０６に新規登録する（Ｓ３０７）。このとき、実行ルールのコンディションとアクションをペアとし、これに、ペアNo.＝001を付して（Ｓ３０９）、実行ルールＤＢ１０６に登録する。
【００９０】
他方、生成された実行ルールのイベントと同じイベントが既に実行ルールＤＢ１０６中に存在する場合（Ｓ３０３：ＹＥＳ）、ルール実行部１１０は、当該イベントに属するペアを順次参照する。たとえば、生成された実行ルールが、Name＝温度、Device＝温度計、Location＝リビングルームである場合、図９に示すルールNo.001に属するペア１、ペア２、…を参照する。そして、生成された実行ルールのアクションのName、Device、Locationが一致するペアを抽出し（Ｓ３０４）、抽出したペアの中に、生成された実行ルールとコンディション（Value）が重複し、且つ、アクション（Value）が相違するペアが存在するかを判定する（Ｓ３０５）。なお、コンディション（Value）が重複するとは、たとえば、「２６度以上」と「２６度以上」のように完全に一致する場合や、「２６度以上」と「２７度以上」、または、「２６度以上」と「２７度以下」のように一部重複する場合のことをいう。
【００９１】
Ｓ３０５における判定がＹＥＳであれば、生成された実行ルールは既登録の実行ルールに矛盾する（制御矛盾の関係にある）とし、エラー表示等のエラー出力処理を行う（Ｓ３０８）。このとき、生成された実行ルールは、実行ルールＤＢ１０６に登録されない。
【００９２】
たとえば、生成された実行ルールが、イベント（Name＝温度、Device＝エアコン、Location＝リビング）、コンディション（Value＝２７度以下）、アクション（Name＝冷房、Device＝エアコン、Location＝リビング、Value＝ＯＦＦ）であれば、図９のルールNo.001のペアNo.001とコンディション（Value＝２６度以上）が重複し、且つ、アクション（Value＝ＯＮ）が相違するから、当該実行ルールは実行ルールＤＢ１０６に登録されない。
【００９３】
Ｓ３０５における判定がＹＥＳであれば、生成された実行ルールのコンディションおよびアクションからペアを構成し、これにペアNo.を付して（Ｓ３０６）、当該イベント（Ｓ３０３にて同一とされたイベント）に属するように、実行ルールＤＢ１０６に登録する。このとき、ルール実行部１１０は、当該イベント（ルールNo.）に属するペアのうち、最終のペアNo.（＝ｋ）に１を加算したペアNo.を当該ペアに付する（Ｓ３０６）。
【００９４】
図１２に、実行ルール削除時の処理動作を示す。
【００９５】
削除処理が開始されると、ルール実行部１１０は、ルールNo.およびペアNo.をもとに削除対象のペアを特定し、当該ペアを実行ルールＤＢ１０６から削除する（Ｓ４０１）。次いで、ルール実行部１１０は、当該削除を実行した結果、当該ペアが属していたルールNo.にペアが残存しなくなったか否かを判別し（Ｓ４０２）、残存している場合には、残存するペアに付されているペアNo.のリナンバリングを行う（Ｓ４０３）。具体的には、途中のペアNo.のペアが削除されたとき、ペアNo.の連続性が保てるように、以後のペアNo.を一つずつ前に詰めるようにリナンバリングを行う。そして、かかる削除およびリナンバリングによって、連携制御におけるリンク状態が不適正になった場合には、リンク状態が適正な状態となるように、対応するペアの記述を修正する（Ｓ４０４）。
【００９６】
たとえば、図９のルールNo.033のペアNo.002において、リンク先ペア（ルールNo.036、ペアNo.003）のペアNoが、ペアNo.003からペアNo.002にリナンバリングされた場合、ルールNo.033のペアNo.002の記述を、「リンク→ルール36／ペア３」から「リンク→ルール36／ペア２」に修正する。また、リンク先ペア（ルールNo.036、ペアNo.003）が削除された場合には、ルールNo.033のペアNo.002の記述を「ＮＵＬＬ」に修正する。
【００９７】
一方、Ｓ４０２にて、当該ルールNo.にペアが残存しなくなったと判別した場合、ルール実行部１１０は、当該ルール自体を実行ルールＤＢ１０６から削除する（Ｓ４０５）。そして、上記と同様、Ｓ４０４にて、リンクの整理を行う。
【００９８】
本実施例によれば、上記実施例１に比べ、連携制御実行時における処理負担を著しく軽減させることができる。
【００９９】
すなわち、上記実施例１においては、実行ルールが無造作且つ個別に登録されているため、実行ルールＤＢ１０６中の実行ルールを全検索して、イベント（機器からの状態通知）に該当する実行ルールを抽出する必要があった。これに対し、本実施例では、イベント毎にペア（コンディションとアクション）が纏められているため、イベント（機器からの状態通知）に一致するイベントの区分（ルールNo.）を検索し、検索したイベントの区分（ルールNo.）に属するペア群から該当するペアを検索するのみでよく、全ての実行ルールを余すところなく検索せずとも、該当する実行ルール（ペア）を効率的に抽出することができる。
【０１００】
また、本実施例のように、イベント毎にペア（コンディションとアクション）が纏められていれば、相互矛盾する実行ルール（ペア）の検出を簡易に行えるとの効果も奏することができる。すなわち、実行ルール間の相互矛盾を、各イベントのペア群についてのみ判定すれば済むようになる。
【０１０１】
なお、本実施例では、上記の如く、実行ルールの登録時に相互矛盾を検出し、矛盾する実行ルール（ペア）の登録を未然に防止するようにしたが、実行ルール（ペア）を一旦登録し、登録後に、相互矛盾するペアを検出し、相互矛盾するペアを排除するようにしても良い。この場合においても、当該イベントに属するペア群に対してのみ、相互矛盾の検出を行えばよいから、上記実施例１のように実行ルールが無造作且つ個別に登録されている場合に比べ、相互矛盾の検出処理を著しく簡素化することができる。なお、この場合においても、相互矛盾の検出方法として、たとえば、上記図１１のＳ３０５の処理方法を用いることができる。
【０１０２】
また、本実施例のように、イベント毎にペア（コンディションとアクション）が纏められていれば、既登録の実行ルールをメンテナンスする際の作業を簡易化できるとの効果を奏することもできる。たとえば、特定のイベントに関する連携制御をメンテナンスする場合、該当するイベントのペア群のみを調べるだけで済み、極めて簡易にメンテナンスを行うことができる。
【０１０３】
このように、本実施例によれば、ルール実行時における処理の簡素化と、相互矛盾する実行ルールの検出処理の簡素化と、ルールメンテナンス時の作業の簡易化を図ることができる。
【０１０４】
なお、上記では、ペアの削除に応じてペアNo.をリナンバリングするようにしたが、リナンバリング処理を行わずに、削除されたペアのペアNo.を、その後に当該イベントに対し登録されるペアに付与するようにしてもよい。このようにすると、リナンバリングによってペア間のリンク状態が不適性になることはなく、よって、上記のようにリンク元ペアの記述を修正する処理を別途行う必要がなくなる。
【０１０５】
なお、かかる場合には、図１３に示すようなルールＤＢ管理テーブルを用いて、ペアNo.の使用状況をルールNo.毎に管理するようにすれば良い。図中、フラグの“１”はペアNo.が使用中であることを示し、また、フラグの“０”はペアが削除されペアNo.が空き状態となったことを示している。かかるルール管理テーブルは、たとえば、実行ルールＤＢ１０６に別途追加するようにすれば良い。
【０１０６】
ただし、この場合にも、当該ルールNo.のペアNo.が全て使用中であれば、上記と同様、最終のペアNo.（＝ｋ）に１を加算したペアNo.を、新たに追加するペアに付与することとなる。また、リンク先ペアが削除された場合には、上記と同様、リンク元ペアの記述をＮＵＬＬに変更する必要がある。そうしないと、リンク元ペアと無関係なペアがリンクされることとなってしまうからである。
【０１０７】
また、上記では、新たに登録しようとするペアと既登録のペアとの間に矛盾が生じた場合に、新たに登録しようとするペアの登録の方を無効にするようにしたが、これに代えて、既登録のペアを削除し、新たに登録しようとするペアの登録を有効とするようにしても良い。
【０１０８】
以上、本発明に係る実施の形態（実施例１〜４）について説明したが、本発明は、かかる実施の形態に限定されるものではなく、他に種々の変更が可能であることは言うまでもない。
【０１０９】
たとえば、上記実施の形態では、ユーザ認証をユーザＩＤとパスワードを用いて行うようにしたが、これに代えて、指紋認証等の認証方法を用いることもできる。
【０１１０】
また、上記実施の形態では、Name、Device、Location、Valueに区分されたイベントを用いて監視先機器の状態変化の監視と連携制御ルールの設定を行うようにしたが、上記イベントのデータ構造は一例であって、上記実施の形態においてイベントとして表現された状態変化情報のデータ構造および連携制御ルールのデータ構造として、他のデータ構造を採用することもできる。
【０１１１】
この他、本発明の実施の形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。
【図面の簡単な説明】
【０１１２】
【図１】実施例１に係るホームネットワークシステムの構成を示す図
【図２】実施例１に係るデバイスＤＢの構成を示す図
【図３】実施例１に係るイベントと実行ルールの構造を示す図
【図４】実施例１に係る実行ルールＤＢの構成を示す図
【図５】実施例１に係る連携制御時の動作を示す図
【図６】実施例２に係る実行ルールＤＢの構成を示す図
【図７】実施例２に係る連携制御時の動作を示す図
【図８】実施例３に係る実行ルールＤＢの構成を示す図
【図９】実施例４に係る実行ルールＤＢの構成を示す図
【図１０】実施例５に係るホームネットワークシステムの構成を示す図
【図１１】実施例５に係る実行ルール登録時の動作を示すフローチャート
【図１２】実施例５に係る実行ルール削除時の動作を示すフローチャート
【図１３】実施例５に係るルールＤＢ管理テーブルの構成を示す図
【符号の説明】
【０１１３】
１００  コントローラ
１０１  通信制御部
１０２  ユーザＩＦ部
１０３  ルール生成部
１０５  ルール実行部
１０６  実行ルールＤＢ
１０７  状態信号受信部
１０８  デバイス制御部
１１０  ルール実行部
【図１】
2005130423.tif 000003
【図２】
2005130423.tif 000004
【図３】
2005130423.tif 000005
【図４】
2005130423.tif 000006
【図５】
2005130423.tif 000007
【図６】
2005130423.tif 000008
【図７】
2005130423.tif 000009
【図８】
2005130423.tif 000010
【図９】
2005130423.tif 000011
【図１０】
2005130423.tif 000012
【図１１】
2005130423.tif 000013
【図１２】
2005130423.tif 000014
【図１３】
2005130423.tif 000015