JP6089386B2 - 決定方法、決定プログラム及び決定装置 - Google Patents

Description

本件は、決定方法、決定プログラム及び決定装置に関する。

最近、人の動きや周辺環境に応じて、機器動作を動的に変更するシステムが普及しつつある。例えば、人の有無や動き（寝ているか否か）を検知して電源をＯＦＦするテレビや、部屋内に人の存在や動きがなくなったことを検知して動作モードを変更したり、外が涼しくなると窓開けを推奨するエアコン等が出現してきている（特許文献１等参照）。また、複数の機器の動作を、機器制御ルールに則って制御する技術も開発されつつある（例えば、特許文献２参照）。

特開２０１０−１６９３７４号公報 特開２００４−２３６２９６号公報

特許文献２のように機器制御ルールに則った制御を行う場合、機器制御ルールの運用に用いる機器やセンサなど（以下、これらを総称して「デバイス」と呼ぶ）の種別や設置位置等をサーバ等に登録する必要がある。これらのうち、デバイスの設置位置に関しては、ＧＰＳ（Global Positioning System）や無線通信機能などを用いて登録することができる場合もある。しかるに、この場合には、ＧＰＳ等をデバイスに予め搭載しておく必要があるため、従来は手入力によりデバイスの種別や設置位置等を登録するのが一般的であった。

また、機器制御ルールを運用するにあたっては、ルール運用に利用するデバイスとして、適切なデバイス（適切な種別のデバイス及び適切な設置位置にあるデバイス）を決定することが重要である。

そこで本件は上記の課題に鑑みてなされたものであり、制御ルールの運用に用いるデバイスを適切に決定することが可能な決定方法、決定プログラム及び決定装置を提供することを目的とする。

本明細書に記載の決定方法は、複数種類のデバイスと接続されたコンピュータが制御対象のデバイス及び前記制御対象のデバイスの制御条件として用いるデバイスを決定する決定方法であって、前記複数種類のデバイスが出力する該デバイスの動作状態を示す状態データ及び該デバイスが計測した計測データを含むデータを収集し、収集したデータのうち、一のデバイスが出力する状態データが電源ＯＮ状態を示している間又は予め定めた動作状態を示している間に、他のデバイスの計測データが変化を示した場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定する推定工程と、前記制御条件として用いることができる第１の種類のデバイスから収集された状態データ又は計測データが所定の条件を満たしたときに制御対象のデバイスとなりうる第２の種類のデバイスを制御することを定義する制御ルールを前記コンピュータが読み取り可能な格納部から取得する取得工程と、前記複数種類のデバイスの中から、前記第２の種類のデバイスに該当するデバイスを前記制御対象のデバイスとして特定し、特定したデバイスが存在する空間を特定する特定工程と、前記複数種類のデバイスのうち、前記第１の種類のデバイスに該当し、かつ前記特定したデバイスが存在する空間と前記関係にあると前記推定工程で推定された空間に存在するデバイスを、前記制御条件として用いるデバイスとして決定する決定工程と、をコンピュータが実行することを特徴とする決定方法である。

本明細書に記載の決定プログラムは、複数種類のデバイスと接続されたコンピュータに制御対象のデバイス及び前記制御対象のデバイスの制御条件として用いるデバイスを決定させる決定プログラムであって、前記複数種類のデバイスから出力される該デバイスの動作状態を示す状態データ及び該デバイスが計測した計測データを含むデータを収集し、収集したデータのうち、一のデバイスが出力する状態データが電源ＯＮ状態を示している間又は予め定めた動作状態を示している間に、他のデバイスの計測データが変化を示した場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定し、前記制御条件として用いることができる第１の種類のデバイスから収集された状態データ又は計測データが所定の条件を満たしたときに制御対象のデバイスとなりうる第２の種類のデバイスを制御することを定義する制御ルールを前記コンピュータが読み取り可能な格納部から取得し、前記複数種類のデバイスの中から、前記第２の種類のデバイスを前記制御対象のデバイスとして特定し、特定したデバイスが存在する空間を特定し、前記複数種類のデバイスのうち、前記第１の種類のデバイスに該当し、かつ前記特定したデバイスが存在する空間と前記関係にあると推定された空間に存在するデバイスを、前記制御条件として用いるデバイスとして決定する、処理をコンピュータに実行させることを特徴とする決定プログラムである。

本明細書に記載の決定装置は、複数種類のデバイスと接続され、制御対象のデバイス及び前記制御対象のデバイスの制御条件として用いるデバイスを決定する決定装置であって、前記複数種類のデバイスから出力される該デバイスの動作状態を示す状態データ及び該デバイスが計測した計測データを含むデータを収集する収集部と、前記収集部が収集したデータのうち、一のデバイスが出力する状態データが電源ＯＮ状態を示している間又は予め定めた動作状態を示している間に、他のデバイスの計測データが変化を示した場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定する推定部と、前記制御条件として用いることができる第１の種類のデバイスから収集された状態データ又は計測データが所定の条件を満たしたときに制御対象のデバイスとなりうる第２の種類のデバイスを制御することを定義する制御ルールを前記決定装置が読み取り可能な格納部から取得する取得部と、前記複数種類のデバイスの中から、前記第２の種類のデバイスを前記制御対象のデバイスとして特定し、特定したデバイスが存在する空間を特定する特定部と、前記複数種類のデバイスのうち、前記第１の種類のデバイスに該当し、かつ前記特定したデバイスが存在する空間と前記関係にあると前記推定部が推定した空間に存在するデバイスを、前記制御ルールに基づく制御条件として用いるデバイスとして決定する決定部と、を備える。

本明細書に記載の決定方法、決定プログラム及び決定装置は、制御ルールの運用に用いるデバイスを適切に決定することができるという効果を奏する。

図１（ａ）は、第１の実施形態に係る制御ルール運用システムの構成を概略的に示す図であり、図１（ｂ）は、機器制御ルール運用サーバのハードウェア構成を示す図である。 宅内装置及び機器制御ルール運用サーバの機能ブロック図である。 データ収集部の処理を示すフローチャートである。 収集ルールの一例を示す図である。 Ａさん宅の通知データを示す図である。 Ｂさん宅の通知データを示す図である。 デバイス配置推定部の処理を示すフローチャートである。 図８（ａ）は、チェックデバイスリスト（Ａさん宅）を示す図であり、図８（ｂ）は、データリスト（Ａさん宅）を示す図である。 図９（ａ）は、チェックデバイスリスト（Ｂさん宅）を示す図であり、図９（ｂ）は、データリスト（Ｂさん宅）を示す図である。 図１０（ａ）は、デバイス配置ＤＢ（Ａさん宅）を示す図であり、図１０（ｂ）は、デバイス配置ＤＢ（Ｂさん宅）を示す図である。 利用データ分析部の処理を示すフローチャートである。 機器制御ルールの一例を示す図である。 データ値ＤＢの一例を示す図である。 利用データＤＢ（利用データ分析部の処理後）を示す図である。 利用データ提供元探索部の処理を示すフローチャートである。 利用データＤＢ（Ａさん宅）を示す図である。 利用データＤＢ（Ｂさん宅）を示す図である。 確信度ＴＢＬを示す図である。 デバイス配置推定部の処理（デバイス削除処理）を示すフローチャートである。 利用データ提供元探索部の処理（デバイス削除時）を示すフローチャートである。 第２の実施形態に係るデバイス配置推定部の処理を示すフローチャートである。 第２の実施形態で用いる同空間候補リストを示す図である。 第３の実施形態に係るデバイス配置推定部の処理を示すフローチャートである。 図２４（ａ）は、第３の実施形態で用いる追随性−付加確信度対応リストを示す図であり、図２４（ｂ）は、ペア−付加確信度対応リストを示す図である。 図２５（ａ）は、第４の実施形態に係るデバイス配置推定部の処理を示すフローチャートであり、図２５（ｂ）は、第４の実施形態で用いるデバイスリストを示す図である。 第４の実施形態に係る利用データ提供元探索部の処理を示すフローチャートである。 第４の実施形態で用いる新規性−付加確信度対応リストを示す図である。 第５の実施形態に係る利用データ提供元探索部の処理を示すフローチャートである。

《第１の実施形態》
以下、機器制御ルール運用システムの第１の実施形態について、図１〜図２０に基づいて詳細に説明する。

図１（ａ）は、機器制御ルール運用システム１００の構成を概略的に示す図である。この制御ルール運用システム１００は、一般家庭などに設置される複数の宅内装置７０と、データセンタなどに設置される制御用デバイスの決定装置としての機器制御ルール運用サーバ１０と、を備える。これら宅内装置７０と機器制御ルール運用サーバ１０は、ネットワーク８０を介して接続されている。また、機器制御ルール運用サーバ１０はインターネット等を介してＷｅｂサーバと接続されており、当該Ｗｅｂサーバから情報（例えば、アメダスのデータ）を取得することができるようになっている。

図１（ｂ）には、機器制御ルール運用サーバ１０のハードウェア構成が示されている。この図１（ｂ）に示すように、機器制御ルール運用サーバ１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、入出力装置９３、及び可搬型記憶媒体用ドライブ９９等を備えている。これら機器制御ルール運用サーバ１０の構成各部は、バス９８に接続されている。機器制御ルール運用サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（制御用デバイスの決定プログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（制御用デバイスの決定プログラム）をＣＰＵ９０が実行することにより、図２の各部の機能が実現される。なお、機器制御ルール運用サーバ１０は、ネットワークインタフェース９７及びネットワーク（インターネットなど）を介して、宅内装置７０やＷｅｂサーバと接続されている。

なお、宅内装置７０も、図１（ｂ）の機器制御ルール運用サーバ１０と同様のハードウェア構成を有しているものとする（ただし、可搬型記憶媒体用ドライブ９９など一部構成は省略されていてもよい）。宅内装置７０においてもＣＰＵがプログラムを実行することにより、図２に示すデータ収集部７２としての機能が実現されている。

図２のデータ収集部７２は、収集ルールデータベース（以下、「データベース」を「ＤＢ」と表記する）７４に基づいて、宅内装置７０に宅内ネットワークなどを介して接続された機器やセンサからデータを収集する。ここで、宅内装置７０に接続される機器には、エアコン、照明、テレビなどの機器が含まれる。また、宅内装置７０に接続されるセンサには、温度センサ、照度センサ、降雨センサなどのセンサが含まれる。収集ルールＤＢ７４には、図４に示すような収集ルールが格納されている。なお、収集ルールの具体的内容については後述する。また、本実施形態では、宅内装置７０に接続された機器及びセンサを纏めて「デバイス」と呼ぶものとする。

図２に戻り、機器制御ルール運用サーバ１０においては、ＣＰＵ９０がプログラムを実行することにより、収集部、推定部、探索部としてのデバイス配置推定部１２、取得部としての利用データ分析部１４、特定部、決定部、信頼度設定部としての利用データ提供元探索部１６、の各機能が実現されている。

デバイス配置推定部１２は、デバイスの動作の変化（例えば電源ＯＮ，ＯＦＦ）後にデバイスから出力された出力データを受信する。また、デバイス配置推定部１２は、受信した出力データに基づいて、デバイスの動作の変化に応じて変化する他のデバイスを抽出し、動作が変化したデバイスと他のデバイスとを同一空間にあると推定してデバイス配置ＤＢ２２に登録する。なお、動作が変化したデバイスと、他のデバイスとを同空間にあると推定するのは、他のデバイスは、動作の変化したデバイスの動作による影響を受けていることから、両デバイスは同一空間内に存在していると考えるのが妥当だからである。例えば、エアコンの動作に応じて室温センサの値が変化する場合には、それらエアコンと室温センサが同一空間に存在していると推定することができる。また、照明の点灯によって照度センサの値が変化する場合には、それら照明と照度センサが同一空間に存在していると推定することができる。

利用データ分析部１４は、機器制御ルールＤＢ２３内で定義されている機器制御ルール（図１２参照）の制御実行条件（ｉｆ）内のデータを抽出する。また、利用データ分析部１４は、制御実行条件（ｉｆ）内のデータとしてありうる値をデータ値ＤＢ２４より抽出し、制御実行条件（ｉｆ）内のデータと対応付けて利用データＤＢ２５に保存し、管理する。

利用データ提供元探索部１６は、機器制御ルールの制御内容（制御対象）（ｔｈｅｎ）において定義されているデバイス種別を抽出し、当該デバイス種別と同一種別のデバイスが存在している空間を特定する。また、利用データ提供元探索部１６は、デバイス配置ＤＢ２２に基づいて、機器制御ルール（図１２参照）の制御実行条件（ｉｆ）内のデータを提供可能なデバイス（制御実行条件（ｉｆ）に含まれるデバイス種別と同一種別のデバイス）を、特定した空間に近い側から探索・抽出する。そして、利用データ提供元探索部１６は、抽出したデバイスを機器制御ルールの運用に用いるデバイスとして決定する。

なお、図２では、機器制御ルール運用サーバ１０のＨＤＤ９６等に格納される各種データベースやテーブルも図示している。各種データベースやテーブルには、図２に示すように、チェックデバイスリスト２０、データリスト２１、デバイス配置ＤＢ２２、機器制御ルールＤＢ２３、データ値ＤＢ２４、利用データＤＢ２５、及び確信度テーブル（以下、「テーブル」を「ＴＢＬ」と表記する）２６が含まれる。

チェックデバイスリスト２０は、図８（ａ）、図９（ａ）に示すように、各宅ごと（宅内装置７０ごと）に作成されるリストであり、例えば電源がＯＮになったデバイスの「デバイス名」と、その日時を示す「ON Time」とが格納される。

データリスト２１は、図８（ｂ）、図９（ｂ）に示すように、各宅ごと（宅内装置７０ごと）に作成されるリストであり、データのプロパティ値（末尾の文字列）に数値を含むデータのみを格納する。

デバイス配置ＤＢ２２は、図１０（ａ）、図１０（ｂ）に示すように、各宅ごと（宅内装置７０ごと）に作成されるデータベースである。このデバイス配置ＤＢ２２には、同一の空間に存在していると推定される複数のデバイスの情報（デバイス名、タイムスタンプ、データの種別、各データ種別の出力しうる値など）が空間毎に纏めて格納される。

機器制御ルールＤＢ２３には、図１２に示すような機器制御ルールが１又は複数格納される。機器制御ルールには、制御実行条件（ｉｆ）と制御内容（ｔｈｅｎ）が関連付けられている。図１２には、空調消費電力削減サービスを提供するためのルールが示されている。図１２のルールの概要は、「冷房時、外気温がエアコン設定温度より低ければ、エアコンを停めて、かつ窓を開けるようにユーザに推奨する/自動的に機器制御する」というものである。

データ値ＤＢ２４は、図１３に示すように、各デバイスの出力データの出力範囲や、各デバイスのありうる状態（以下、これらを「ありうる値」と呼ぶ）を定義するデータベースである。データ値ＤＢ２４には、各デバイスのカタログ値をありうる値として登録しておいてもよいし、デバイスが宅内に設置されるたびにユーザ等がありうる値を手入力してもよい。また、データ値ＤＢ２４では、ありうる値を、メーカ別に登録することとしてもよい。

利用データＤＢ２５は、機器制御ルールごとに、当該ルールの運用に利用するデバイスを揃えるために用いるデータベースである。利用データＤＢ２５は、図１４、図１６、図１７に示すようなデータベースである。具体的には、利用データＤＢ２５には、機器制御ルールの運用に用いる利用データ、利用データのありうる値、利用データを取得するデバイス（利用デバイス）、利用するデータのプロパティ名、及び利用デバイスの確信度が格納される。

確信度ＴＢＬ２６には、図１８に示すように、「空間距離」と「ありうる値」の組み合わせ別に、決定すべき確信度が定義されている。ここで、「確信度」とは、制御内容（制御対象）（ｔｈｅｎ）の制御を行う際に満たすべき制御実施条件（ｉｆ）を満足しているか否かを判断する際に用いるデータ（デバイス）の信頼度を意味する。

次に、上述した宅内装置７０及び機器制御ルール運用サーバ１０の各機能の処理について、詳細に説明する。

（データ収集部７２の処理）
まず、図３のフローチャートに沿って、宅内装置７０のデータ収集部７２の処理について説明する。なお、図３の処理の前提として、制御対象となる機器や、制御ルール内に記述された条件を判定するために必要なデータを提供するセンサなどのデバイスは、宅内装置７０に対して宅内ネットワーク等を介して予め接続されているものとする。なお、デバイスの中には、宅内ネットワークに直接接続できないデバイスもある。このようなデバイスは、ネットワーク接続のためのアダプタを介して、ネットワーク接続するようにしてもよい。

図３の処理では、まず、ステップＳ１０において、データ収集部７２が、宅内のデバイスからデータを収集する。ここで、データ収集部７２は、収集ルールＤＢ７４に格納されているデバイス毎に定義されている収集ルール（図４参照）に基づいて、データを収集するものとする。例えば、センサ（温度センサや照度センサなど）の場合、データ収集部７２は、定期的（１０秒おき）にデータを収集するものとする。また、エアコンや照明であれば、データ収集部７２は、通常、状態変化時（プロパティ名が「Operation Status」でプロパティ値が「ON」又は「OFF」になったとき）に収集する。また、データ収集部７２は、エアコンや照明のプロパティ値が「ON」になった後は、内蔵する温度センサなどの出力データを定期的（１０秒おき）に収集するものとする。なお、ステップＳ１０では、データ収集部７２は、例えば、特開２００２−３３０１３５号公報に開示されているように、宅内ネットワーク上のデバイスの発見及びデバイス種別の判定を経て、各デバイスからデータ収集することができる。

図３に戻り、次のステップＳ１２では、データ収集部７２が、デバイス毎に、前回値と比較する。次いで、ステップＳ１４では、データ収集部７２が、前回値があったか否かを判断する。このステップＳ１４の判断が肯定された場合には、ステップＳ１６に移行する。ステップＳ１６に移行した場合、データ収集部７２は、前回値と同値であったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１０に戻る。一方、ステップＳ１６の判断が否定された場合、すなわち異なる値であった場合には、ステップＳ１８に移行する。

ステップＳ１８に移行すると、データ収集部７２は、新データ（ステップＳ１０で収集したデータ）を通知データ（図５、図６参照）として保存する。その後は、ステップＳ２２に移行する。なお、ステップＳ１４において前回値が無かった場合には、ここでの判断が否定され、ステップＳ２０に移行する。そして、ステップＳ２０では、データ収集部７２が、デバイス名とデータを通知データとして保存し、ステップＳ２２に移行する。

ステップＳ２０を経て、又はステップＳ１８を経てステップＳ２２に移行すると、データ収集部７２は、デバイス配置推定部１２に通知データを通知する。その後は、ステップＳ１０に戻る。

図５、図６には、通知データの一例として、Ａさん宅の通知データと、Ｂさん宅の通知データとが示されている。通知データには、デバイス（エアコンや照明などの機器）の動作状態（ＯＮ、ＯＦＦ）や動作モード、機器に内蔵された温度センサなどの出力データ、デバイス（降雨センサ、温度センサ、照度センサなど）の出力データが含まれる。

なお、図３の処理では、通知データが更新されるたびにデータ収集部７２がデバイス配置推定部１２に通知する場合について説明したが、これに限られるものではない。例えば、データ収集部７２は、所定時間毎に（定期的に）デバイス配置推定部１２に通知データを通知することとしてもよい。

（デバイス配置推定部１２の処理）
次に、機器制御ルール運用サーバ１０のデバイス配置推定部１２による処理について、図７のフローチャートに沿って、その他図面を適宜参照しつつ説明する。なお、以下においては、データ収集部７２からデバイス配置推定部１２に対して、図５において矢印で示すデータが通知されるとともに、当該データの下側のデータが順次通知される場合を例に採り説明する。なお、前提として、図８（ａ）のチェックデバイスリストは空であるものとする。

図７の処理では、まず、ステップＳ３０において、デバイス配置推定部１２が、通知データ（例えば、図５）のデータを１つ受信する。ここでは、デバイス配置推定部１２が、矢印で示す「08/01 18:00:05 照明S OperationStatus ON」を受信する。

次いで、ステップＳ３２では、デバイス配置推定部１２が、受信したデータのプロパティ名が「Operation Status」であり、プロパティ値が「ON」又は「OFF」であるか否かを判断する。ここでの判断が肯定されると、ステップＳ３４に移行する。

ステップＳ３４に移行した場合、デバイス配置推定部１２は、データのプロパティ名が「Operation Status」であり、プロパティ値が「ON」であるか否かを判断する。ここでの判断が肯定されると、ステップＳ３６に移行し、デバイス配置推定部１２が、チェックデバイスリストに対する登録を行う。この場合、デバイス配置推定部１２は、図８（ａ）に示すように、チェックデバイスリストに、デバイス名（照明Ｓ）を登録するとともに、データ（Operation Status ON）の出力日時（08/01 18:00:05）を「On Time」として登録する。その後は、ステップＳ３０に戻る。

ステップＳ３０に戻ると、デバイス配置推定部１２は、図５の次のデータ「08/01 18:00:05 照明S IlluminancePercentage 100」を受信する。次いで、ステップＳ３２では、デバイス配置推定部１２が、受信したデータのプロパティ名が「Operation Status」であり、プロパティ値が「ON」又は「OFF」であるか否かを判断する。ここでは、ステップＳ３２の判断は否定されるので、ステップＳ５２に移行する。

ステップＳ５２に移行すると、デバイス配置推定部１２は、データのプロパティ値に数値が含まれているか否かを判断する。ここでは、データのプロパティ値に数値「１００」が含まれているので、判断は肯定され、ステップＳ５４に移行する。

ステップＳ５４に移行すると、デバイス配置推定部１２は、データリスト２１への登録を行う。この場合、図８（ｂ）において矢印で示すデータが、データリスト２１に登録される。その後は、図７のステップＳ３０に戻る。

ステップＳ３０に戻ると、デバイス配置推定部１２は、次のデータ「08/01 18:00:13 エアコンX OperationStatus ON」を受信する。この場合、ステップＳ３２の判断が肯定されるとともに、ステップＳ３４の判断も肯定される。そして、ステップＳ３６において、デバイス配置推定部１２は、チェックデバイスリストに対する登録を行う。この場合、デバイス配置推定部１２は、図８（ａ）に示すように、チェックデバイスリストに、デバイス名（エアコンＸ）を登録するとともに、データの出力時刻（08/01 18:00:13）を「On Time」として登録する。その後は、ステップＳ３０に戻る。

ステップＳ３０に戻ると、デバイス配置推定部１２は、次のデータ「08/01 18:00:13 エアコンX OperationModeStatus Cooling」を受信する。この場合、ステップＳ３２の判断は否定され、かつ、プロパティ値に数値が含まれていないので、ステップＳ５２の判断も否定され、ステップＳ５６に移行する。

ステップＳ５６では、デバイス配置推定部１２が、データに「Found」が含まれているか否かを判断する。ここでの判断が否定されると、そのままステップＳ３０に戻る。

なお、これ以降、デバイス配置推定部１２が受信するデータは、図５に示すようにプロパティ値に数値を含むデータとなっている。したがって、デバイス配置推定部１２は、ステップＳ３２（否定）、ステップＳ５２（肯定）、ステップＳ５４の繰返しにより、プロパティ値に数値を含むデータをデータリストに繰返し登録する（図８（ｂ））。

その後、上記と同様の処理を繰返し、ステップＳ３０において、デバイス配置推定部１２が、例えば、「エアコンX OperationStatus OFF」のデータを受信したとする。この場合、ステップＳ３２（肯定）及びステップＳ３４（否定）を経て、ステップＳ３８に移行することになる。なお、以下においては、動作状態がＯＦＦとなったデバイス名を「デバイス名（１）」と表記するものとする。

ステップＳ３８に移行すると、デバイス配置推定部１２は、ON Time（チェックデバイスリスト２０の日時）からOFF Time（直近のデータの受信日時）までの間に数値が変化したデバイス名をデータリスト２１から抽出・取得する。例えば、図８（ｂ）のデータリスト２１では、エアコンＸのRoomMeasuredTempの値のみが変化しているので、デバイス名「エアコンＸ」が取得されることになる。なお、以下においては、ステップＳ３８で取得したデバイス名を「デバイス名（２）」と表記するものとする。

次いで、ステップＳ４０に移行すると、デバイス配置推定部１２は、ステップＳ３８で取得したデバイス名（２）の中に、動作状態がＯＦＦであるデバイス名（１）と異なるものがあるか否かを判断する。ここでは、デバイス名（２）とデバイス名（１）とが同一であるので、ステップＳ４０の判断は否定され、ステップＳ４２に移行する。そして、ステップＳ４２に移行すると、デバイス配置推定部１２は、チェックデバイスリスト２０からデバイス名（１）（＝「エアコンＸ」）を削除し、ステップＳ３０に戻る。なお、上記処理では、エアコンＸの動作に対応して変化したデータがエアコンＸに内蔵された温度センサの出力データのみであったため、同一空間内にエアコンＸ以外のデバイスがあることを推定できなかったことになる。

その後、例えば、ステップＳ３０において、デバイス配置推定部１２が、「照明S OperationStatus OFF」のデータを受信すると、ステップＳ３２（肯定）及びステップＳ３４（否定）を経て、ステップＳ３８に移行する。なお、この場合のデバイス名（１）は「照明Ｓ」となる。

そして、ステップＳ３８に移行すると、デバイス配置推定部１２は、デバイス名（２）として、「エアコンＸ」を取得し、ステップＳ４０に移行する。ステップＳ４０では、デバイス名（２）の中に、デバイス名（１）と異なるものがあるか否かを判断するが、ここでは、デバイス名（２）とデバイス名（１）とが異なるので、ステップＳ４０の判断が肯定され、ステップＳ４４に移行する。

ステップＳ４４では、デバイス配置推定部１２が、デバイス名（１）と（２）の全ペア（ここでは１つのペア（エアコンＸと照明Ｓ））が、デバイス配置ＤＢ２２（図１０（ａ）参照）の同一空間に既に存在しているか否かを判断する。ここでの判断が否定された場合、すなわち、図１０（ａ）の「空間名（１）」のデータが存在していなかったような場合には、ステップＳ４８に移行する。そして、ステップＳ４８では、デバイス配置推定部１２が、全ペア（ここでは１つのペア（エアコンＸと照明Ｓ））を同一の空間名（空間名（１））とタイムスタンプを付加してデバイス配置ＤＢ２２に登録する。

次のステップＳ５０では、デバイス配置推定部１２が、ON TimeからOFF Timeの間のデータ値の最小値と最大値をデバイス配置ＤＢ２２に登録する。このステップＳ４８とステップＳ５０の登録が完了したときの状態が、図１０（ａ）に示されている。なお、上記処理によると、照明Ｓの動作に対応して変化したデータがエアコンＸに内蔵された温度センサの出力データであったため、同一空間内に照明ＳとエアコンＸが存在していると推定できたことになる。

以上のように、デバイス配置ＤＢ２２への登録が完了すると、ステップＳ４２に移行し、デバイス配置推定部１２は、チェックデバイスリスト２０からデバイス名（１）＝「照明Ｓ」を削除し、ステップＳ３０に戻る。

なお、ステップＳ４４の判断が肯定された場合、すなわち、デバイス配置ＤＢ２１に既に同一ペアが登録されていた場合には、ステップＳ４６に移行し、デバイス配置推定部１２は、既存のデータのタイムスタンプを更新する。その後は、ステップＳ５０に移行し、デバイス配置推定部１２は、デバイス配置ＤＢ２２のデータ値を更新（変化の最小値と最大値の範囲が、デバイス配置ＤＢ２２に既に登録されているデータ値の最小値と最大値の範囲を超える場合には、超えた範囲を登録）し、ステップＳ４２に移行する。この場合も、デバイス配置推定部１２は、チェックデバイスリスト２０からデバイス名（１）を削除し、ステップＳ３０に戻る。

ところで、図６のＢさん宅の通知データにおいて矢印で示す「08/01 18:00:30 降雨 RainDetectionStatus Found」のようなデータを、デバイス配置推定部１２が受信する場合もある。このような場合には、ステップＳ３２（否定）、ステップＳ５２（否定）を経て、ステップＳ５６に移行する。そして、ステップＳ５６では、デバイス配置推定部１２が、プロパティ値に「Found」を含むか否かの判断を行う。ここでの判断が肯定されると、ステップＳ５８に移行し、デバイス配置推定部１２は、チェックデバイスリスト２０（図９（ａ）参照）に「降雨」が存在しているか否かを判断する。ここでの判断が否定された場合には、ステップＳ６０において、チェックデバイスリスト２０に新たに「降雨」を登録し、ステップＳ３０に戻る。一方、ステップＳ５８の判断が肯定された場合には、ステップＳ６２に移行する。

ステップＳ６２に移行すると、デバイス配置推定部１２は、ON Timeから最新時刻（データ受信日時）までの間に変化したデバイス名をデータリストから取得する。

次いで、ステップＳ６４では、デバイス配置推定部１２が、最新時刻を「ON Time」としてチェックデバイスリスト２０に登録（更新）する。その後は、ステップＳ４０以降の処理が上述したのと同様に実行されることになる。

なお、Ｂさん宅の通知データ（図６参照）では、デバイス名（１）が「エアコンＸ」のときに、デバイス名（２）として「エアコンＸ」、「照明Ｓ」、「湿度Ｂ」が取得される（ステップＳ３８）。このような場合、ステップＳ４０では、デバイス名（２）にデバイス名（１）と異なるものが存在するので、判断が肯定され、ステップＳ４４に移行する。そして、ステップＳ４４では、デバイス配置推定部１２は、デバイス名（１）と（２）の全ペアが同一空間に既に存在しているか否かを判断する。ここでの判断が肯定された場合には、ステップＳ４６において上記と同様の処理を行う。一方、ステップＳ４４の判断が否定された場合には、デバイス配置推定部１２は、全ペア（すなわち、デバイス名（１）、（２）の和集合）をデバイス配置ＤＢ２２に登録する（ステップＳ４８）。また、デバイス配置推定部１２は、デバイス配置ＤＢ２２のデータ値の最小値と最大値を登録する（ステップＳ５０）。このような処理を行うことにより、図１０（ｂ）の空間名（１）に示すように、３種類のデバイスを同一空間内に存在するデバイスとして登録することができる。

以上の処理をデバイス配置推定部１２が実行することで、デバイス配置ＤＢ２２には、同一空間内に存在するデバイスを、適宜、登録・更新することが可能となる。なお、図１０（ｂ）では、Ｂさん宅の１つの空間に、「エアコンＸ」、「照明Ｓ」、「湿度Ｂ」の各デバイスが存在し、これとは異なる空間（この場合、戸外）に「降雨」、「湿度Ａ」の各デバイスが存在していることを示している。

（利用データ分析部１４の処理）
次に、利用データ分析部１４の処理について、図１１のフローチャートに沿って、その他図面を適宜参照しつつ、詳細に説明する。この図１１の処理は、ユーザが機器制御ルールの運用サービスの契約を締結するなどのトリガがあった時点から実行される処理である。

図１１の処理では、まず、ステップＳ７０において、利用データ分析部１４が、機器制御ルールＤＢ２３から機器制御ルールを１つ抽出し（例えば、図１２）、その機器制御ルールで定義されている制御実行条件（ｉｆ）内のデータを抽出する。以下においては、ステップＳ７０において抽出されたデータを、「データ（３）」と表記する。なお、図１２の例では、制御実行条件（ｉｆ）内のデータ（３）として、「エアコン OperationStatus」、「エアコン OperationModeStatus」、「温度（屋外） MeasuredTemp」、「降雨 RainDetectionStatus」が抽出される。

次いで、ステップＳ７２では、利用データ分析部１４が、抽出したデータのありうる値をデータ値ＤＢ（図１３参照）から抽出する。以下においては、ステップＳ７２で抽出されたありうる値を「値（４）」と表記する。

次いで、ステップＳ７４では、利用データ分析部１４が、データ（３）と値（４）を対応付けて利用データＤＢ２５に登録する。このステップＳ７４の登録が完了した後の利用データＤＢ２５の状態が、図１４に示されている。

次いで、ステップＳ７６では、利用データ分析部１４が、利用データ提供元探索部１６に探索通知を行い、ステップＳ７０に戻る。以降、ステップＳ７０〜ステップＳ７６の処理を繰り返すことで、各機器制御ルールに対応する利用データＤＢ２５の登録処理が順次行われることになる。

（利用データ提供元探索部１６の処理(探索通知受信時又は新規デバイス出現時)）
次に、利用データ提供元探索部１６が実行する処理について、図１５のフローチャートに沿って説明する。なお、図１５の処理は、利用データ分析部１４から探索通知を受信したとき、又は宅内装置７０に新規のデバイスが接続されたときに、利用データ提供元探索部１６により実行される処理である。

図１５の処理では、まず、ステップＳ８０において、利用データ提供元探索部１６が、仮利用データＤＢを作成する。ここで、「仮利用データＤＢ」とは、図１４の利用データＤＢ２５を複製したデータベースを意味する。

次いで、ステップＳ８２では、利用データ提供元探索部１６は、機器制御ルール内の制御内容（ｔｈｅｎ）内のデバイス（デバイス種別）を抽出する。ここで抽出されたデバイスを、以下においては「デバイス（５）」と表記する。なお、図１２の機器制御ルールからは、デバイス（５）として「エアコンＸ」と「窓」が抽出される。

次いで、ステップＳ８４では、利用データ提供元探索部１６は、抽出したデバイス種別（デバイス（５））と同一（同一種別）のデバイスが存在している空間を特定する。この場合、例えば、図１０（ａ）のＡさん宅の空間名（１）の空間が特定されたものとする。そして、利用データ提供元探索部１６は、特定された空間と同一建屋内（Ａさん宅内）にあるデバイスをデバイス配置ＤＢ２２（図１０）から抽出する。ここでは、例えば、Ａさん宅内に存在する「エアコンＸ」及び「照明Ｓ」が抽出される。なお、ここで抽出されるデバイスを、以下においては、デバイス（６）と表記するものとする。

次いで、ステップＳ８６では、利用データ提供元探索部１６が、デバイス（６）と仮利用データＤＢのアンド（和集合）を取る。すなわち、仮利用データＤＢに含まれるデバイス（デバイス種別）と同一の種別のデバイスを抽出する。ここでは、「エアコンＸ」が、アンドが取れたデバイスとなる。

次いで、ステップＳ８８では、利用データ提供元探索部１６が、アンドが取れたデバイス（及びこれに対応するデータ）の確信度を決定する。この場合、利用データ提供元探索部１６は、図１８に示す確信度ＴＢＬ２６を参照して、空間距離とありうる値に基づいて、確信度を決定する。ここで、「空間距離」には、図１８に示すように、「同一空間」、「同一建屋内の異なる空間」、「一定距離以内の異なる建屋内」、「Ｗｅｂデータ」などがある。Ａさん宅の例では、「エアコンＸ」及び「照明Ｓ」の空間距離は、ともに「同一空間」となる。また、「ありうる値」は、仮利用データＤＢにおいてありうる値として定義されている値の範囲と、デバイス配置ＤＢ２２のデータ値の範囲とから定まり、「範囲内」、「一部範囲外」、「全て範囲外」のいずれかが選択される。例えば、上述した例において、「ありうる値」が「範囲内」であった場合には、確信度が「５」に決定される。図１６では、「エアコンＸ」に対し、確信度＝「５」が決定された例が示されている。

図１５に戻り、次のステップＳ９０では、利用データ提供元探索部１６が、仮利用データＤＢの利用データに対応する利用デバイスが全て揃ったか否かを判断する。図１６のように全ての利用デバイスが揃っていない場合には、ステップＳ９０の判断は否定され、ステップＳ９２に移行する。

ステップＳ９２に移行すると、利用データ提供元探索部１６は、一定距離以内の他の家（建屋）にデバイスがあるか否かを判断する。なお、利用データ提供元探索部１６は、Ａさん宅やＢさん宅の位置（住所）を、予め分かっているものとする（図１０（ａ）の住所Ａ、図１０（ｂ）の住所Ｂ参照）。そして、利用データ提供元探索部１６は、各宅の距離を地図データなどを用いて算出するものとする。このステップＳ９２の判断が、肯定された場合には、ステップＳ９４に移行し、利用データ提供元探索部１６は、一定距離以内のデバイスを仮利用データＤＢに登録する。そして、利用データ提供元探索部１６は、ステップＳ９６において、登録したデバイスの確信度を、確信度ＴＢＬ２６を参照して決定する。その後は、ステップＳ９０に戻り、利用データ提供元探索部１６は、再度、仮利用データＤＢの利用デバイスが全て揃ったか否かを判断する。ここでの判断が否定された場合には、ステップＳ９２に移行する。

なお、ステップＳ９２の判断が否定された場合には、ステップＳ９８に移行する。ステップＳ９８では、利用データ提供元探索部１６は、Ｗｅｂ上にＡさん宅が含まれる地域の外気温のデータや降雨のデータ（アメダス等のデータ)があるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１００に移行し、利用データ提供元探索部１６は、Ｗｅｂデータを登録する。なお、ステップＳ１００では、利用データ提供元探索部１６は、機器制御ルールの運用に用いるデバイスとして、Ｗｅｂサーバを決定したともいえる。そして、利用データ提供元探索部１６は、ステップＳ１０２において、登録したデータ（Ｗｅｂデータ）の確信度を、確信度ＴＢＬ２６を参照して決定する。その後はステップＳ９０に戻る。

なお、ステップＳ９８の判断が否定された場合には、仮利用データＤＢの全ての利用デバイスが揃わなかったことを意味する。したがって、この場合には、利用データ提供元探索部１６は、ステップＳ１０４において、宅内装置７０に対してサービス提供をすることができない旨の通知を行い、図１５の全処理を終了する。

一方、ステップＳ９０の判断が肯定された場合、すなわち、仮利用データＤＢの全利用デバイスが揃った場合には、ステップＳ１０５に移行する。ステップＳ１０５では、利用データ提供元探索部１６が、仮利用データＤＢと利用データＤＢ２５（元々あった場合）とで各デバイスの確信度を比較し、確信度の高いデバイスを利用するように、利用データＤＢ２５を上書きする。なお、上記では、ステップＳ１０５において、確信度に基づいて利用デバイスの上書きを行う場合について説明したが、これに限られるものではない。例えば、利用データ分析部１４からの探索通知があった場合には、利用データＤＢ２５を全て書き換えるような運用とすることもできる。この場合には、ステップＳ１０５の処理に代えて、利用データＤＢ２５を仮利用データＤＢで置き換える処理を行うこととすればよい。

その後、ステップＳ１０５の処理が終了すると、ステップＳ１０６に移行し、利用データ提供元探索部１６は、サービス提供（機器制御ルールの運用サービスの提供）を開始し、図１５の全処理を終了する。なお、図１６に示すＡさん宅のように、利用データＤＢ２５の全利用デバイスが揃わなかった場合には、サービス提供不可能通知が宅内装置７０に対して出される。一方、図１７に示すＢさん宅のように、利用データＤＢ２５の全利用デバイスが揃った場合には、サービス提供が開始されることになる。

なお、図１５の処理は、機器制御ルールＤＢ２３に含まれる全ての機器制御ルールに対して行われる処理である。

以上のように、図１５の処理を行うことで、機器制御ルールの運用に必要なデバイス（機器、センサ、Ｗｅｂサーバ）を、制御内容（ｔｈｅｎ）に含まれるデバイスが存在する空間に近い側から順に自動で抽出することができる。これにより、機器制御ルールの運用に適切なデバイスを簡易に抽出することが可能である。また、機器制御ルールの運用に必要なデバイスが揃った段階で、各宅のデバイス（エアコンなどの機器）の制御を適切に行うことが可能となる。

（デバイス配置推定部１２の処理(デバイス削除処理)）
次に、図１９に基づいて、デバイス配置推定部１２による、デバイス削除処理について説明する。ここで、デバイス配置ＤＢ２２のある空間に登録されているデバイスであっても、時間の経過に伴ってその空間内には存在しなくなっている場合もある。図１９の処理では、このような既に空間内に存在していないデバイスをデバイス配置ＤＢ２２から削除するための処理である。

図１９の処理では、まず、ステップＳ２０２において、デバイス配置推定部１２が、デバイス配置ＤＢ２２に一定期間を経過したタイムスタンプが有るか否かを判断する。ここでの判断が否定された場合には、所定時間経過後に再度ステップＳ２０２を実行する。一方、ステップＳ２０２の判断が肯定された場合には、ステップＳ２０４に移行する。

ステップＳ２０４に移行すると、デバイス配置推定部１２は、過去の通知データの中から、ステップＳ２０２においてタイムスタンプが一定時間を経過したと判断されたデバイスの最新データを抽出する。

次いで、ステップＳ２０６では、デバイス配置推定部１２が、最新データのタイムスタンプが一定期間経過しているか否かを判断する。ここでの判断が否定された場合には、ステップＳ２０２に戻るが、肯定された場合には、ステップＳ２０８に移行する。

ステップＳ２０８に移行すると、デバイス配置推定部１２は、デバイス配置ＤＢ２２からタイムスタンプが一定時間経過しているデバイスを削除する。なお、削除したデバイスが存在していた空間内にデバイスが１つのみ残るような場合には、デバイス配置推定部１２は、その空間も削除する。

次いで、ステップＳ２１０では、デバイス配置推定部１２が、利用データ提供元探索部１６に削除デバイスを通知する。その後は、ステップＳ２０２に戻り、上述した処理を繰り返す。

以上の処理を行うことで、デバイス配置推定部１２は、既に空間内に存在していない可能性の高いデバイスをデバイス配置ＤＢ２２から削除することが可能である。

（利用データ提供元探索部１６の処理(デバイス削除時)）
次に、利用データ提供元探索部１６が実行するデバイス削除時の処理について、図２０のフローチャートに沿って説明する。なお、図２０の処理は、前述した図１９のステップＳ２１０において、デバイス配置推定部１２から利用データ提供元探索部１６に対して削除デバイスの通知が行われたタイミングで実行される処理である。

なお、図２０の処理では、図１５とほぼ同様の処理が行われるが、図１５のステップＳ８０に代えて、ステップＳ８０’が実行される点、仮利用データＤＢを用いない点、及び図１５のステップＳ１０５が省略されている点が異なる。以下、これらの点を中心に図２０の処理について説明する。

図２０の処理では、まず、ステップＳ８０’において、利用データ提供元探索部１６が、宅内装置７０から削除通知されたデバイスを、利用データＤＢ２５から削除する。

なお、利用データ提供元探索部１６は、ステップＳ８０’において削除されたデバイスに代わるデバイスを利用データＤＢ２５に補填するために、図２０のステップＳ８２以降の処理を実行する。この場合、利用データ提供元探索部１６は、同一建屋内→一定距離以内の異なる建屋内→Ｗｅｂデータ、の順に削除されたデバイスに代わるデバイスを探索する。この探索により、利用データＤＢ２５の全利用デバイスが揃えば、機器制御ルールの運用が開始されることになる（ステップＳ１０６）。一方、探索により全利用デバイスが揃わなければ、サービス提供不可能通知が、宅内装置７０に対して通知される（ステップＳ１０４）。

これにより、デバイス削除時においても、削除されたデバイスの代わりになるデバイスを利用デバイスとして決定することで、機器制御ルールの運用サービスを継続して行うことが可能である。また、デバイス削除により機器制御ルールの運用ができなくなった場合にも、適切にサービス提供不可能通知を行うことができる。

以上、詳細に説明したように、本実施形態によると、デバイス配置推定部１２が、複数種類のデバイスの出力データを受信し（ステップＳ３０）、受信した出力データに基づいて、デバイスのうちの１つ（エアコンや照明などの機器）が所定状態（例えば、電源ＯＮの状態やＦｏｕｎｄの状態など）となっている間に出力データが変化した他のデバイスを抽出し（ステップＳ３８）、所定状態であったデバイスと他のデバイスとが同一空間に存在していると推定する（ステップＳ４４〜Ｓ５０）。そして、利用データ分析部１４は、機器制御ルールから制御内容（制御対象）（ｔｈｅｎ）のデバイス種別を抽出し、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定する。更に利用データ提供元探索部１６は、制御ルールの制御実行条件（ｉｆ）を定義するデバイス種別と同一種別のデバイスを特定された空間に近い側から抽出し、制御ルールの運用に用いるデバイスとして決定する（図１５の処理）。これにより、本実施形態では、人手やＧＰＳなどの機器を用いることなく、同一空間に存在しているデバイスを推定できる。また、推定結果と機器制御ルールとを用い、制御対象のデバイスが存在する空間に近い側から機器制御ルールの運用に用いるデバイス（機器、センサあるいはＷｅｂサーバ）を決定することで、機器制御ルールの運用に用いるデバイスを適切かつ自動で決定することができる。

また、本実施形態では、機器制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、各デバイスが存在している空間と、制御内容（ｔｈｅｎ）のデバイスが存在する空間との乖離度（図１８における空間距離）、及び制御実行条件を定義するために必要なデバイスの機能と機器制御ルールの運用に用いるデバイスの機能との乖離度（図１８のありうる値）に基づいて、各デバイスの出力データの信頼度（確信度）を定める。これにより、確信度の高いデバイスを優先的に利用した機器制御ルールの運用（ステップＳ１０５、Ｓ１０６）が可能となる。

また、本実施形態では、利用データＤＢ２５の全利用デバイスを揃えることができなかった場合に、利用データ提供元探索部１６は、宅内装置７０に対して、機器制御ルールの運用ができない旨の通知を行う。これにより、機器制御ルールの運用ができない場合に、ユーザはそのことを認知することが可能となる。

なお、上記第１の実施形態では、確信度を、図１８に示す「空間距離」と「ありうる値」に基づいて決定することとしたが、これに限られるものではなく、いずれか一方に基づいて決定することとしてもよい。また、上記２つの要素に基づいて確信度を決定する場合に限らず、その他の要素に基づいて確信度を決定することとしてもよい。

なお、上記第１の実施形態では、同一建屋内のデバイスを同時に抽出することとしているが、これに限られるものではない。利用データ提供元探索部１６は、まず同一空間のデバイスを抽出することとし、当該抽出によって全てのデバイスが抽出できなかった場合に、同一建屋内の異なる空間のデバイスを抽出することとしてもよい。

《第２の実施形態》
次に、第２の実施形態について、図２１、図２２に基づいて説明する。図２１は、第２の実施形態に係るデバイス配置推定部１２の処理（第１の実施形態における図７から変更した部分のみ）を示すフローチャートである。図２１の処理では、図７のステップＳ４４〜Ｓ５０の代わりに、ステップＳ１２０〜Ｓ１３４の処理を実行する。

図２１では、図７のステップＳ４０が肯定された場合、すなわち、デバイス名（２）にデバイス名（１）と異なるデバイスが含まれている場合に、ステップＳ１２０が実行される。ステップＳ１２０では、デバイス配置推定部１２が、デバイス名（１）と（２）の各ペアが同空間候補リストに既に存在しているか否かを判断する。ここで、同空間候補リストは、図２２に示すようなリストであり、デバイス名（１）と（２）の組み合わせに対し、ペアとなった回数（ペア回数）を登録するためのリストである。

ステップＳ１２０の判断が否定された場合、すなわち、同空間候補リストにペアが存在していない場合には、ステップＳ１２２において、デバイス配置推定部１２が、デバイス名（１）と（２）のペアを同空間候補リストに登録する。また、デバイス配置推定部１２は、登録したペアのペア回数を１とする。一方、同空間候補リストにペアが既に存在していた場合には、ステップＳ１２０の判断が肯定され、ステップＳ１２４に移行する。

ステップＳ１２４に移行した場合、デバイス配置推定部１２は、デバイス名（１）と（２）のペア回数に１を加算（＋１）する。次いで、ステップＳ１２６では、デバイス名（１）と（２）のペア回数が、デバイス名（２）が含まれる他のペアにおけるペア回数よりも５以上多いか否かを判断する。ここでの判断が否定された場合には、ステップＳ４２（図７）に移行する。一方、ステップＳ１２６の判断が肯定された場合（５以上であった場合）には、ステップＳ１２８に移行する。

ステップＳ１２８では、デバイス配置推定部１２は、デバイス名（２）がデバイス配置ＤＢ２２に既に存在しているか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１３０に移行し、デバイス名（２）が既に存在している空間内に、デバイス名（１）を登録する。その後は、ステップＳ４２（図７）に移行する。一方、ステップＳ１２８の判断が否定されると、デバイス配置推定部１２は、図７のステップＳ４８、Ｓ５０と同様、デバイス配置ＤＢ２２に対し、デバイス名（１）、（２）が存在する新たな空間を登録する（Ｓ１３２、Ｓ１３４）。その後は、ステップＳ４２に移行する。

その他の処理は、第１の実施形態と同様である。

以上説明したように、本第２の実施形態によると、同空間候補リストのペア回数が所定の閾値（上記ではデバイス名（２）が含まれる他のペアのペア回数よりも５以上多い値）を超えた場合に、デバイス配置ＤＢ２２にペアを登録する。これにより、本第２の実施形態では、デバイスが存在する空間を正確に推定することができる。

なお、上記第２の実施形態では、所定の閾値として、デバイス名（２）が含まれる他のペアのペア回数よりも所定数（例えば５）以上多い値を採用した場合について説明したが、これに限られるものではない。所定の閾値としては、所定値（他のペアを考慮しない値）を用いることとしてもよい。

《第３の実施形態》
次に、第３の実施形態について、図２３、図２４に基づいて説明する。図２３は、第３の実施形態に係るデバイス配置推定部１２の処理（第１の実施形態（図７）から変更した部分を太線で示している）を示すフローチャートである。より具体的には、図２３の処理では、図７のステップＳ３８、Ｓ６２の処理の代わりにステップＳ３８’、Ｓ６２’の処理を実行するとともに、ステップＳ５０の処理の後に、ステップＳ１４０、Ｓ１４２の処理を実行する。

ステップＳ３８’（又はステップＳ６２’）では、デバイス配置推定部１２は、ON TimeからOFF Time（又は最新時刻）までの間に変化したデバイス名のみならず、変化開始時刻も取得する。

そして、ステップＳ４０、Ｓ４４〜Ｓ５０を経て、デバイス配置推定部１２により、ペアがデバイス配置ＤＢ２２に登録（又はタイムスタンプの更新）されると、ステップＳ１４０に移行する。

ステップＳ１４０では、デバイス配置推定部１２は、ON Timeから変化開始時刻までの経過時間と、図２４（ａ）に示す追随性−付加確信度対応リストと、を照合して、付加確信度を取得する。この場合、ON Time（デバイス名（１）がチェックデバイスリストに登録された時刻）から、デバイス名（２）が変化するまでの時間が短いほど（デバイス名（１）の動作に対するデバイス名（２）の反応が早いほど）、付加確信度は高くなる。

次いで、ステップＳ１４２では、デバイス配置推定部１２が、デバイス名（１）と（２)のペアと、付加確信度と、を対応付けて図２４（ｂ）に示すペア−付加確信度対応リストに登録する。

その他のデバイス配置推定部１２の処理は、第１の実施形態と同様である。なお、利用データ提供元探索部１６は、確信度を決定する際（図１５のステップＳ８８、Ｓ９６、Ｓ１０２）には、図１８の確信度ＴＢＬ２６で求められた確信度に、ペア−付加確信度対応リストの値を加算するものとする。

ここで、デバイスが電源ＯＮにされた後、出力データの変化が早く現れた他のデバイスは、電源ＯＮとなっているデバイスと同一空間に存在している可能性が高いと考えられる。したがって、本第３の実施形態では、利用データ提供元探索部１６が、ペア−付加確信度対応リストの値を用いて確信度を決定することで、確信度を適切に決定することが可能である。

《第４の実施形態》
次に、第４の実施形態について、図２５〜図２７に基づいて説明する。図２５（ａ）は、第４の実施形態に係るデバイス配置推定部１２の処理（第１の実施形態の図７の処理と並列処理される処理）である。

図２５（ａ）の処理では、まず、ステップＳ１５０において、デバイス配置推定部１２が、宅内ネットワーク内のデバイス探索を行う。このデバイス探索により１つのデバイスを発見した段階で、次のステップＳ１５２に移行する。

次のステップＳ１５２では、デバイス配置推定部１２が、発見したデバイスが、デバイスリスト内にあるか否かを判定する。ここで、デバイスリストは、図２５（ｂ）に示すように、発見したデバイス名と、発見日時が登録されるリストである。このデバイスリストに発見したデバイスがあった場合には、デバイス配置推定部１２は、ステップＳ１５３において、発見日時を更新した後、ステップＳ１５０に戻る。一方、デバイスリストに発見したデバイスが無かった場合には、デバイス配置推定部１２は、デバイスリストに、デバイス名と発見日時を登録する。その後は、ステップＳ１５０に戻り、デバイス１つずつに対して上記処理を繰り返す。

これに対し、利用データ提供元探索部１６では、図２６のような処理を実行する。なお、図２６の処理は、上述した第１の実施形態の図１５の処理のステップＳ８８、Ｓ９６、Ｓ１０２に代えて、ステップＳ８８’、Ｓ９６’、Ｓ１０２’を実行する点が異なっている。

図２６のステップＳ８８’では、利用データ提供元探索部１６は、確信度を決定する際に、確信度ＴＢＬ２６で定まる確信度に、付加確信度を加算する。ここで、付加確信度は、図２７に示す新規性−付加確信度対応リストに基づいて決定される。この新規性−付加確信度対応リストでは、図２５（ｂ）のデバイスリストの発見日時が現在に近いほど（最近発見されたデバイスであるほど）付加確信度は高くなる。したがって、存在していることを確認した時期が近いデバイスほど、高い付加確信度が、確信度ＴＢＬ２６で定まる確信度に加算されることになる。

なお、ステップＳ９６’、Ｓ１０２’においても、利用データ提供元探索部１６は、上記ステップＳ８８’と同様の方法により確信度を決定する。なお、本実施形態では、図２０の処理においても、上記と同様の方法により確信度を決定するものとする。

以上説明したように、本第４の実施形態によると、デバイス探索の結果、デバイスが発見された日時に基づいて、確信度を決定するので、確信度を適切に決定することができる。

《第５の実施形態》
次に、第５の実施形態について、図２８に基づいて説明する。図２８は、第５の実施形態に係る利用データ提供元探索部１６の処理を示すフローチャートである。この図２８の処理では、第１の実施形態の処理（図１５）の処理のステップＳ８４とＳ８６の間に、ステップＳ８５Ａ、８５Ｂの処理を実行する。

ステップＳ８５Ａでは、利用データ提供元探索部１６は、ステップＳ８４において抽出されたデバイス（６）の中に、同一種類のデバイスが複数あるか否かを判断する。ここでの判断が否定された場合、すなわち、デバイス（６）の中に同一種類のデバイスが１つのみ含まれていた場合には、ステップＳ８６に直接移行する。

一方、ステップＳ８５Ａの判断が肯定された場合には、ステップＳ８５Ｂに移行する。ステップＳ８５Ｂでは、利用データ提供元探索部１６は、同一種類の複数のデバイスのうち、データ値の精度が細かいデバイスを選択する。

ここで、「データ値の精度が細かい」とは、例えば、数値の小数点以下の桁数が多いことを意味するものとする。ただし、これに限られるものではなく、最小値と最大値の間の範囲が大きい場合を「データ値の精度が細かい」としてもよい。また、データ値が文字列の場合には、データ値の個数が多い場合を、「データ値の精度が細かい」場合としてもよい。更に、例えば、デバイスメーカの信頼度（株式評価やホームページアクセス数に基づく換算値等）を利用してデータ値の精度が細かいデバイスを選択してもよい。

なお、ステップＳ８６以降の処理では、利用データ提供元探索部１６は、ステップＳ８５Ｂで選択したデバイスをデバイス（６）として、処理を実行する。

以上のように、本第５の実施形態によると、同一種別のデバイスが複数抽出された場合に、データ値の精度が細かいデバイスを選択することとしているので、機器制御ルールの運用を適切に行うことが可能となる。

なお、上記第１〜第５の実施形態は、適宜組み合わせることが可能である。例えば、利用データ提供元探索部１６は、第３の実施形態の付加確信度と、第４の実施形態の付加確信度と、の両方を考慮して確信度を決定するなどしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１） 複数種類のデバイスの出力データを収集する収集工程と、
前記収集工程で収集した出力データに基づいて、前記複数種類のデバイスのうちの１つが所定状態となっている間に出力データが変化した他のデバイスを抽出し、前記所定状態であったデバイスと前記他のデバイスとが同一空間に存在していると推定する推定工程と、
制御対象のデバイス種別と、制御実行条件を定義するデバイス種別とを関連付けた制御ルールを取得する取得工程と、
前記制御ルールから、前記制御対象のデバイス種別を抽出し、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定する特定工程と、
前記制御ルールの制御実行条件を定義するデバイス種別と同一種別のデバイスを前記特定工程で特定された空間に近い側から抽出し、当該抽出したデバイスを前記制御ルールの運用に用いるデバイスとして決定する決定工程と、をコンピュータが実行することを特徴とする制御用デバイスの決定方法。
（付記２） 前記推定工程では、前記抽出した回数が、所定の閾値を超えた場合に、前記所定状態のデバイスと前記他のデバイスとが同一空間に存在していると推定することを特徴とする付記１に記載の制御用デバイスの決定方法。
（付記３） 前記制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、当該各デバイスが存在している空間と前記特定された空間との乖離度、及び前記制御実行条件を定義するために必要なデバイスの機能と前記制御ルールの運用に用いるデバイスの機能との乖離度、の少なくとも一方に基づいて、各デバイスの出力データの信頼度を定める信頼度設定工程を、前記コンピュータが更に実行することを特徴とする付記１又は２に記載の制御用デバイスの決定方法。
（付記４） 前記信頼度設定工程では、前記デバイスが所定状態となった時点から、前記他のデバイスの出力データが変化するまでの時間に基づいて、前記信頼度を定めることを特徴とする付記３に記載の制御用デバイスの決定方法。
（付記５） 前記各デバイスの存在を探索する探索工程を前記コンピュータが更に実行し、
前記信頼度設定工程では、前記探索工程で各デバイスが発見された日時に基づいて、当該各デバイスの信頼度を定めることを特徴とする付記３又は４に記載の制御用デバイスの決定方法。
（付記６） 前記決定工程では、前記制御ルールの運用に用いるデバイスの候補が複数あった場合には、出力データの精度が最も細かいデバイスを前記制御ルールの運用に用いるデバイスとして決定することを特徴とする付記１〜５のいずれかに記載の制御用デバイスの決定方法。
（付記７） 複数種類のデバイスの出力データを収集し、
収集した出力データに基づいて、前記複数種類のデバイスのうちの１つが所定状態になっている間に出力データが変化した他のデバイスを抽出するとともに、前記所定状態であったデバイスと前記他のデバイスとが同一空間に存在していると推定し、
制御対象のデバイス種別と、制御実行条件を定義するデバイス種別とを関連付けた制御ルールを取得し、
前記制御ルールから、前記制御対象のデバイス種別を抽出するとともに、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定し、
前記制御ルールの制御実行条件を定義するデバイス種別と同一種別のデバイスを特定された空間に近い側から抽出し、当該抽出したデバイスを前記制御ルールの運用に用いるデバイスとして決定する、処理をコンピュータに実行させることを特徴とする制御用デバイスの決定プログラム。
（付記８） 前記推定する処理では、前記抽出した回数が、所定の閾値を超えた場合に、前記所定状態のデバイスと前記他のデバイスとが同一空間に存在していると推定することを特徴とする付記７に記載の制御用デバイスの決定プログラム。
（付記９） 前記制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、当該各デバイスが存在している空間と前記特定された空間との乖離度、及び前記制御実行条件を定義するために必要なデバイスの機能と前記制御ルールの運用に用いるデバイスの機能との乖離度、の少なくとも一方に基づいて、各デバイスの出力データの信頼度を定める処理を、前記コンピュータに更に実行させることを特徴とする付記７又は８に記載の制御用デバイスの決定プログラム。
（付記１０） 前記信頼度を定める処理では、前記デバイスが所定状態となった時点から、前記他のデバイスの出力データが変化するまでの時間に基づいて、前記信頼度を定めることを特徴とする付記９に記載の制御用デバイスの決定プログラム。
（付記１１） 前記各デバイスの存在を探索する処理を前記コンピュータが更に実行し、
前記信頼度を定める処理では、前記探索する処理で各デバイスが発見された日時に基づいて、当該各デバイスの信頼度を定めることを特徴とする付記９又は１０に記載の制御用デバイスの決定プログラム。
（付記１２） 前記決定する処理では、前記制御ルールの運用に用いるデバイスの候補が複数あった場合には、出力データの精度が最も細かいデバイスを前記制御ルールの運用に用いるデバイスとして決定することを特徴とする付記７〜１１のいずれかに記載の制御用デバイスの決定プログラム。
（付記１３） 複数種類のデバイスの出力データを収集する収集部と、
前記収集部が収集した出力データに基づいて、前記複数種類のデバイスのうちの１つが所定状態となっている間に出力データが変化した他のデバイスを抽出し、前記所定状態であったデバイスと前記他のデバイスとが同一空間に存在していると推定する推定部と、
制御対象のデバイス種別と、制御実行条件を定義するデバイス種別とを関連付けた制御ルールを取得する取得部と、
前記制御ルールから、前記制御対象のデバイス種別を抽出し、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定する特定部と、
前記制御ルールの制御実行条件を定義するデバイス種別と同一種別のデバイスを前記特定部で特定された空間に近い側から抽出し、当該抽出したデバイスを前記制御ルールの運用に用いるデバイスとして決定する決定部と、を備える制御用デバイスの決定装置。
（付記１４） 前記推定部は、前記抽出した回数が、所定の閾値を超えた場合に、前記所定状態のデバイスと前記他のデバイスとが同一空間に存在していると推定することを特徴とする付記１３に記載の制御用デバイスの決定装置。
（付記１５） 前記制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、当該各デバイスが存在している空間と前記特定された空間との乖離度、及び前記制御実行条件を定義するために必要なデバイスの機能と前記制御ルールの運用に用いるデバイスの機能との乖離度、の少なくとも一方に基づいて、各デバイスの出力データの信頼度を定める信頼度設定部を、更に備える付記１３又は１４に記載の制御用デバイスの決定装置。
（付記１６） 前記信頼度設定部は、前記デバイスが所定状態となった時点から、前記他のデバイスの出力データが変化するまでの時間に基づいて、前記信頼度を定めることを特徴とする付記１５に記載の制御用デバイスの決定装置。
（付記１７） 前記各デバイスの存在を探索する探索部を更に備え、
前記信頼度設定部は、前記探索部で各デバイスが発見された日時に基づいて、当該各デバイスの信頼度を定めることを特徴とする付記１５又は１６に記載の制御用デバイスの決定装置。
（付記１８） 前記決定部は、前記制御ルールの運用に用いるデバイスの候補が複数あった場合には、出力データの精度が最も細かいデバイスを前記制御ルールの運用に用いるデバイスとして決定することを特徴とする付記１３〜１７のいずれかに記載の制御用デバイスの決定装置。

１０ 機器制御ルール運用サーバ（決定装置）
１２ デバイス配置推定部（収集部、推定部、探索部）
１４ 利用データ分析部（取得部）
１６ 利用データ提供元探索部（特定部、決定部、信頼度設定部）

Claims (6)

1. 複数種類のデバイスと接続されたコンピュータが制御対象のデバイス及び前記制御対象のデバイスの制御条件として用いるデバイスを決定する決定方法であって、
   前記複数種類のデバイスが出力する該デバイスの動作状態を示す状態データ及び該デバイスが計測した計測データを含むデータを収集し、収集したデータのうち、一のデバイスが出力する状態データが電源ＯＮ状態を示している間又は予め定めた動作状態を示している間に、他のデバイスの計測データが変化を示した場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定する推定工程と、
   前記制御条件として用いることができる第１の種類のデバイスから収集された状態データ又は計測データが所定の条件を満たしたときに制御対象のデバイスとなりうる第２の種類のデバイスを制御することを定義する制御ルールを前記コンピュータが読み取り可能な格納部から取得する取得工程と、
   前記複数種類のデバイスの中から、前記第２の種類のデバイスに該当するデバイスを前記制御対象のデバイスとして特定し、特定したデバイスが存在する空間を特定する特定工程と、
   前記複数種類のデバイスのうち、前記第１の種類のデバイスに該当し、かつ前記特定したデバイスが存在する空間と前記関係にあると前記推定工程で推定された空間に存在するデバイスを、前記制御条件として用いるデバイスとして決定する決定工程と、
   をコンピュータが実行することを特徴とする決定方法。
2. 前記推定工程では、前記他のデバイスの計測データが変化を示した回数が、所定の閾値を超えた場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定することを特徴とする請求項１に記載の決定方法。
3. 前記決定工程により前記制御条件として用いるデバイスとして決定された各デバイスに対し、当該各デバイスの状態データが電源ＯＮ状態となった時点または予め定めた動作状態となった時点から、前記他のデバイスの計測データが変化するまでの時間に基づいて、当該各デバイスの状態データ又は計測データの信頼度を定める信頼度設定工程を、
   前記コンピュータが更に実行することを特徴とする請求項１又は２に記載の決定方法。
4. 前記各デバイスの状態データ又は計測データを受信したか否かに基づき、前記各デバイスの存在を探索する探索工程を前記コンピュータが更に実行し、
   前記信頼度設定工程では、前記探索工程で各デバイスが発見された日時からの経過時間が短いほど当該各デバイスの信頼度が高いと定めることを特徴とする請求項３に記載の決定方法。
5. 複数種類のデバイスと接続されたコンピュータに制御対象のデバイス及び前記制御対象のデバイスの制御条件として用いるデバイスを決定させる決定プログラムであって、
   前記複数種類のデバイスから出力される該デバイスの動作状態を示す状態データ及び該デバイスが計測した計測データを含むデータを収集し、
   収集したデータのうち、一のデバイスが出力する状態データが電源ＯＮ状態を示している間又は予め定めた動作状態を示している間に、他のデバイスの計測データが変化を示した場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定し、
   前記制御条件として用いることができる第１の種類のデバイスから収集された状態データ又は計測データが所定の条件を満たしたときに制御対象のデバイスとなりうる第２の種類のデバイスを制御することを定義する制御ルールを前記コンピュータが読み取り可能な格納部から取得し、
   前記複数種類のデバイスの中から、前記第２の種類のデバイスを前記制御対象のデバイスとして特定し、特定したデバイスが存在する空間を特定し、
   前記複数種類のデバイスのうち、前記第１の種類のデバイスに該当し、かつ前記特定したデバイスが存在する空間と前記関係にあると推定された空間に存在するデバイスを、前記制御条件として用いるデバイスとして決定する、処理をコンピュータに実行させることを特徴とする決定プログラム。
6. 複数種類のデバイスと接続され、制御対象のデバイス及び前記制御対象のデバイスの制御条件として用いるデバイスを決定する決定装置であって、
   前記複数種類のデバイスから出力される該デバイスの動作状態を示す状態データ及び該デバイスが計測した計測データを含むデータを収集する収集部と、
   前記収集部が収集したデータのうち、一のデバイスが出力する状態データが電源ＯＮ状態を示している間又は予め定めた動作状態を示している間に、他のデバイスの計測データが変化を示した場合に、前記一のデバイスが存在する空間と前記他のデバイスが存在する空間とが互いに影響を及ぼし合う関係にあると推定する推定部と、
   前記制御条件として用いることができる第１の種類のデバイスから収集された状態データ又は計測データが所定の条件を満たしたときに制御対象のデバイスとなりうる第２の種類のデバイスを制御することを定義する制御ルールを前記決定装置が読み取り可能な格納部から取得する取得部と、
   前記複数種類のデバイスの中から、前記第２の種類のデバイスを前記制御対象のデバイスとして特定し、特定したデバイスが存在する空間を特定する特定部と、
   前記複数種類のデバイスのうち、前記第１の種類のデバイスに該当し、かつ前記特定したデバイスが存在する空間と前記関係にあると前記推定部が推定した空間に存在するデバイスを、前記制御ルールに基づく制御条件として用いるデバイスとして決定する決定部と、
   を備える決定装置。
   

Images