(57)【特許請求の範囲】
【請求項１】
コンピュータに、
複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、
前記第１のデバイスと前記第２のデバイスと、判定した前記時間とを対応付けたタイミング管理情報を生成し、
前記第１のデバイスからデータを取得すると、前記タイミング管理情報に基づいて、データの取得対象とする前記第２のデバイスを選択し、前記第２のデバイスからデータを取得するタイミングを、前記第１のデバイスからデータを取得してから前記時間が経過した後と決定し、決定したタイミングで前記第２のデバイスからデータを取得する、
処理を実行させるデータ取得プログラム。
【請求項２】
前記判定では、前記第１のデバイスからデータを取得した時刻と前記第２のデバイスから変化後のデータを取得した時刻との時間差に応じた統計量に基づいて、前記時間を判定する、請求項１記載のデータ取得プログラム。
【請求項３】
前記判定では、前記時間差の分散が閾値以下である場合に、前記時間を前記時間差の平均値とする、請求項２記載のデータ取得プログラム。
【請求項４】
前記判定では、前記第１のデバイスが所定の種類のデバイスである場合、前記第１のデバイスからデータを取得すると、複数の他のデバイスにデータの取得要求を送信して前記複数の他のデバイスからデータを取得し、前記第２のデバイスを判定する、請求項１乃至３の何れか１項に記載のデータ取得プログラム。
【請求項５】
前記判定では、前記第１のデバイスから取得されるデータの種別に応じて、前記第１のデバイスからの当該データの取得を、他のデバイスからデータを取得するためのトリガの候補とするか否かを選択する、請求項１乃至４の何れか１項に記載のデータ取得プログラム。
【請求項６】
前記決定では、前記第１のデバイスから取得されるデータの種別に応じて、前記タイミングにおいて前記第２のデバイスからデータを取得するか否かを更に選択する、請求項１乃至４の何れか１項に記載のデータ取得プログラム。
【請求項７】
前記第１のデバイスは、前記コンピュータから要求されなくても、前記コンピュータにデータを送信するデバイスである、請求項１乃至６の何れか１項に記載のデータ取得プログラム。
【請求項８】
複数のデバイスから取得したデータの履歴を記憶する記憶部と、
前記データの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、前記第１のデバイスと前記第２のデバイスと、判定した前記時間とを対応付けたタイミング管理情報を生成し、前記第１のデバイスからデータを取得すると、前記タイミング管理情報に基づいて、データの取得対象とする前記第２のデバイスを選択し、前記第２のデバイスからデータを取得するタイミングを、前記第１のデバイスからデータを取得してから前記時間が経過した後と決定し、決定したタイミングで前記第２のデバイスからデータを取得する演算部と、
を有する情報処理装置。
【請求項９】
コンピュータが、
複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、
前記第１のデバイスと前記第２のデバイスと、判定した前記時間とを対応付けたタイミング管理情報を生成し、
前記第１のデバイスからデータを取得すると、前記タイミング管理情報に基づいて、データの取得対象とする前記第２のデバイスを選択し、前記第２のデバイスからデータを取得するタイミングを、前記第１のデバイスからデータを取得してから前記時間が経過した後と決定し、決定したタイミングで前記第２のデバイスからデータを取得する、
データ取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ取得プログラム、情報処理装置およびデータ取得方法に関する。
【背景技術】
【０００２】
種々のデバイスからデータを取得する情報処理装置が利用されている。例えば、温度、湿度および消費電力量などを計測するセンサなどのデバイスから取得した情報により、施設環境を管理し得る。また、例えば、空調機や照明機器などのデバイスから取得した動作モードの変化などを示す情報により、施設内の設備の動作状況を管理し得る。
【０００３】
例えば、デバイスには、情報処理装置に対してオンデマンドでデータを送信するオンデマンド型のデバイスや、データをプッシュ送信するプッシュ型のデバイスがある。オンデマンド型のデバイスは、データの要求を情報処理装置から受信すると、情報処理装置にデータを送信する。プッシュ型のデバイスは、何らかのタイミング（例えば、周期的なタイミングや自デバイスが検出したデータに一定以上の変化があったタイミングなど）で、データの要求がなくても、情報処理装置へデータを送信する。
【０００４】
例えば、データをプッシュ送信する無線測定装置のデータ送信方法が提案されている。無線測定装置は、測定タイミング周期である第１の周期より長い第２の周期で測定データを外部機器に対して間欠的に送信する。測定データが変動するとき、無線測定装置は、第１の周期より長く第２の周期より短い第３の周期で測定データを外部機器に送信する。
【０００５】
また、節電モードで荷重計本体が測定した荷重データに変化がある場合、荷重計本体が荷重データ受信装置に荷重データを所定の送信間隔で間欠的に送信する技術が提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−３３４４６５号公報
【特許文献２】特開平８−１２７４９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前述のように、情報処理装置は、オンデマンド型のデバイスへデータの要求を送信し、応答としてオンデマンド型のデバイスからデータを取得する。そこで、情報処理装置において、オンデマンド型のデバイスからデータを取得するタイミングが問題となる。
【０００８】
例えば、ある時間範囲内におけるデータの変化が、観測したいデータの変化に比べて小さいにも関わらず、同時間範囲内に複数回のデータ取得を行うのは非効率的である。データ要求／応答の送受信の頻度が多いほど、情報処理装置、デバイスおよびネットワークなどの負荷が高まるおそれがある。
【０００９】
１つの側面では、本発明は、データを効率的に取得できるデータ取得プログラム、情報処理装置およびデータ取得方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様では、データ取得プログラムが提供される。このデータ取得プログラムは、コンピュータに、複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、第１のデバイスと第２のデバイスと、判定した時間とを対応付けたタイミング管理情報を生成し、第１のデバイスからデータを取得すると、タイミング管理情報に基づいて、データの取得対象とする第２のデバイスを選択し、第２のデバイスからデータを取得するタイミングを、第１のデバイスからデータを取得してから当該時間が経過した後と決定し、決定したタイミングで第２のデバイスからデータを取得する処理を実行させる。
【００１１】
また、１つの態様では、情報処理装置が提供される。この情報処理装置は、記憶部と演算部とを有する。記憶部は、複数のデバイスから取得したデータの履歴を記憶する。演算部は、データの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、第１のデバイスと第２のデバイスと、判定した時間とを対応付けたタイミング管理情報を生成し、第１のデバイスからデータを取得すると、タイミング管理情報に基づいて、データの取得対象とする第２のデバイスを選択し、第２のデバイスからデータを取得するタイミングを、第１のデバイスからデータを取得してから当該時間が経過した後と決定し、決定したタイミングで第２のデバイスからデータを取得する。
【００１２】
また、１つの態様では、データ取得方法が提供される。このデータ取得方法では、コンピュータが、複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、第１のデバイスと第２のデバイスと、判定した時間とを対応付けたタイミング管理情報を生成し、第１のデバイスからデータを取得すると、タイミング管理情報に基づいて、データの取得対象とする第２のデバイスを選択し、第２のデバイスからデータを取得するタイミングを、第１のデバイスからデータを取得してから当該時間が経過した後と決定し、決定したタイミングで第２のデバイスからデータを取得する。
【発明の効果】
【００１３】
１つの側面では、データを効率的に取得できる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施の形態の情報処理装置を示す図である。
【図２】第２の実施の形態の情報処理システムを示す図である。
【図３】第２の実施の形態のゲートウェイのハードウェア例を示す図である。
【図４】第２の実施の形態の温度センサのハードウェア例である。
【図５】第２の実施の形態の空調機のハードウェア例である。
【図６】第２の実施の形態のサーバのハードウェア例を示す図である。
【図７】第２の実施の形態のゲートウェイの機能例を示す図である。
【図８】第２の実施の形態の温度センサの機能例を示す図である。
【図９】第２の実施の形態の空調機の機能例を示す図である。
【図１０】第２の実施の形態のパケット例を示す図である。
【図１１】第２の実施の形態の履歴テーブルの例を示す図である。
【図１２】第２の実施の形態の分散値テーブルの例を示す図である。
【図１３】第２の実施の形態のタイミング管理テーブルの例を示す図である。
【図１４】第２の実施の形態の予約テーブルの例を示す図である。
【図１５】第２の実施の形態の準備処理の具体例を示す図である。
【図１６】第２の実施の形態の準備処理例（その１）を示すフローチャートである。
【図１７】第２の実施の形態のオンデマンド型デバイスの処理例を示すフローチャートである。
【図１８】第２の実施の形態の準備処理例（その２）を示すフローチャートである。
【図１９】第２の実施の形態の運用処理例（その１）を示すフローチャートである。
【図２０】第２の実施の形態の運用処理例（その２）を示すフローチャートである。
【図２１】第３の実施の形態のトリガ即時決定制御テーブルの例を示す図である。
【図２２】第３の実施の形態の準備処理例を示すフローチャートである。
【図２３】第３の実施の形態のタイミング管理テーブルの例を示す図である。
【図２４】第４の実施の形態のトリガ決定制御テーブルの例を示す図である。
【図２５】第４の実施の形態の準備処理例を示すフローチャートである。
【図２６】第５の実施の形態のオンデマンド取得制御テーブルの例を示す図である。
【図２７】第５の実施の形態の運用処理例を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。情報処理装置１は、複数のデバイスからデータを取得する。情報処理装置１は、取得したデータに基づいて各デバイスが設置された施設の環境管理や、各デバイスの動作状況の管理などを行う。デバイスは、例えば、温度、湿度または消費電力量などを測定するセンサでもよい。デバイスは、空調機や照明機器などの電気機器でもよい。
【００１６】
情報処理装置１は、ネットワークを介して、第１のデバイス２および第２のデバイス３と接続されている。ネットワークは、無線ネットワークでもよいし、有線ネットワークでもよい。第１のデバイス２は、例えばプッシュ型のデバイスでもよい。第１のデバイス２は、例えばオンデマンド型のデバイスでもよい。第２のデバイス３は、オンデマンド型のデバイスである。情報処理装置１は、オンデマンド型の第２のデバイス３からデータを効率的に取得する機能を提供する。
【００１７】
情報処理装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂは、プログラムを実行するプロセッサであってもよい。「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
【００１８】
記憶部１ａは、複数のデバイスから取得したデータの履歴を記憶する。データの履歴は、デバイスの識別情報とデバイスから取得したデータと取得した時刻とを対応付けた情報である。デバイスから取得されるデータは、例えば、温度、湿度、消費電力量または変更後の動作モードの情報など、デバイスに応じた種々の種別のデータを含み得る。データの履歴は、演算部１ｂにより取得されてもよい。例えば、演算部１ｂは、本番の運用前の準備処理として、複数のデバイスから周期的に（デバイス毎に異なる周期でもよい）取得したデータの履歴を記録してもよい。なお、各デバイスから取得されるデータには、各デバイスの識別情報が含まれる。
【００１９】
例えば、演算部１ｂは、オンデマンド型のデバイス（例えば、第２のデバイス３）からデータを取得する場合、オンデマンド型のデバイスにデータの送信を要求する。そして、オンデマンド型のデバイスからの応答として当該デバイスからのデータを受信することで、オンデマンド型のデバイスからデータを取得する。
【００２０】
データの取得元にプッシュ型のデバイスが含まれる場合、データの履歴は、当該デバイスから任意のタイミングでプッシュ送信されたデータの履歴を含み得る。例えば、第１のデバイス２がプッシュ型のデバイスである場合、第１のデバイス２からのデータ取得は、演算部１ｂから第１のデバイス２に対するデータの要求なしに行われる。すなわち、第１のデバイス２は、情報処理装置１に対してデータをプッシュ送信する。演算部１ｂは、第１のデバイス２からプッシュ送信されたデータを受信することで、第１のデバイス２からデータを取得する。
【００２１】
例えば、記憶部１ａは、第１のデバイス２および第２のデバイス３から取得したデータの履歴を記憶する。より具体的には、履歴の情報は、第１のデバイス２の識別情報と、第１のデバイス２から取得したデータと、取得した時刻とを対応付けた情報を含む。また、履歴の情報は、第２のデバイス３の識別情報と、第２のデバイス３から取得したデータと、取得した時刻とを対応付けた情報を含む。
【００２２】
演算部１ｂは、複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイス２からデータを取得した後に、取得されるデータに変化がある第２のデバイス３と変化までの時間ΔＴとを判定する。例えば、演算部１ｂは、第１のデバイス２からデータを取得した時刻と第２のデバイス３からデータを取得した時刻との時間差に応じた統計量に基づいて、時間ΔＴを判定する。
【００２３】
より具体的には、演算部１ｂは、記憶部１ａに記憶された履歴の情報に基づいて、第１のデバイス２からデータを取得した時刻Ｔ１ａから、時間ΔＴａ内にデータに変化がある第２のデバイス３を判定する。演算部１ｂは、第２のデバイス３について、時刻Ｔ１ｂにおいて取得されるデータに変化があったことを検出する。時間差ΔＴ１＝時刻Ｔ１ｂ−時刻Ｔ１ａであり、ΔＴ１＜ΔＴａである（「時刻Ｔ１ｂ−時刻Ｔ１ａ」の演算は、時刻Ｔ１ｂと時刻Ｔ１ａとの時間差を求める演算である）。演算部１ｂは、第２のデバイス３から取得したデータで示される値が、第２のデバイス３から直前に取得したデータよりも所定値以上変化した場合に、データに変化があったと検出してもよい。すなわち、演算部１ｂは、所定値よりも小さい変化を、変化していないとみなしてもよい。所定値は、例えば、観測対象としたいデータの変化の度合いに応じて予め定められる（直前の値からの変化の割合によって定められてもよい）。
【００２４】
時間ΔＴａは、デバイス間の関係性の判断候補を特定するための時間範囲であり、記憶部１ａに予め格納される。当該時間範囲を設けることで、デバイス間の関係性の判断候補を絞り込める。例えば、時間ΔＴａはシステムの運用サイクルに応じて定めることができる（例えば、各装置の起動や停止にある程度の周期性が認められれば、その周期に応じて定めてもよい）。あるいは、デバイス間の関係性の判断候補の対象外にしたい時間差に応じて時間ΔＴａを決定してもよい。演算部１ｂは、時刻Ｔ１ａから時間ΔＴａよりも長い時間が経過した後のデータの取得イベントについては、時刻Ｔ１ａにおけるデータ取得との関係性の判断の対象外とする。
【００２５】
同様に、演算部１ｂは、第１のデバイス２からデータを取得した時刻Ｔ２ａから、時間ΔＴａ内にデータに変化がある第２のデバイス３を判定する。演算部１ｂは、第２のデバイス３について、時刻Ｔ２ｂにおいて取得されるデータに変化があったことを検出する。時間差ΔＴ２＝時刻Ｔ２ｂ−時刻Ｔ２ａであり、ΔＴ２＜ΔＴａである。
【００２６】
こうして、演算部１ｂは、第１のデバイス２と第２のデバイス３とについて、時間差ΔＴｎ（ｎ＝１，２，・・・）をサンプリングする。統計的な評価の精度を確保するために、時間差ΔＴｎのサンプリング数に下限値を設けてもよい（サンプリング数が下限値以上になる場合に評価対象とし、下限値より小さい場合に評価対象としない）。そして、演算部１ｂは、例えば複数の時間差ΔＴｎの分散値が閾値以下の場合に、第１のデバイス２からのデータの取得と第２のデバイス３から取得されるデータの変化とに関係性があると判定する。
【００２７】
関係性があると判定した場合、演算部１ｂは、時間ΔＴを、例えば複数の時間差ΔＴｎの平均値とする。演算部１ｂは、第１のデバイス２および第２のデバイス３の識別情報に対応付けて、時間差ΔＴの情報を記憶部１ａに格納する。
【００２８】
一方、演算部１ｂは、複数の時間差ΔＴｎの分散値が閾値よりも大きい場合に、第１のデバイス２からのデータの取得と第２のデバイス３から取得されるデータの変化とに関係性がないと判定する。この場合、演算部１ｂは、第１のデバイス２および第２のデバイス３の組み合わせに対して、時間差ΔＴの決定を行わない。
【００２９】
前述のように、情報処理装置１は、第１のデバイス２および第２のデバイス３に加え、他の複数のデバイスからもデータを取得し得る。よって、演算部１ｂは、あるデバイスからのデータ取得のイベントに対し、当該デバイスと情報処理装置１が通信する他の全てのオンデマンド型のデバイスそれぞれとの組に対し、上記の処理を行ってもよい。すなわち、あるデバイスからのデータ取得のイベントに対して、他のオンデマンド型のデバイスそれぞれに関する時間差ΔＴの判定やデータ取得タイミングの決定を試みてもよい。
【００３０】
また、第１のデバイス２から取得されるデータの種別が複数であることもある。すなわち、情報処理装置１は、異なるタイミングで、異なる種別のデータを第１のデバイス２から取得することもある。その場合、情報処理装置１は、第１のデバイス２および第１のデバイス２から取得されるデータの種別毎に、上記の時間差ΔＴを決定してもよい。
【００３１】
演算部１ｂは、第２のデバイス３からデータを取得するタイミングを、第１のデバイス２からデータを取得してから時間ΔＴが経過した後と決定する。例えば、演算部１ｂは、その後、本番の運用処理を行う。演算部１ｂは、ある時刻Ｔｘにおいて、第１のデバイス２からデータを取得する。
【００３２】
すると、演算部１ｂは、時刻Ｔｘから時間ΔＴが経過した後に、第２のデバイス３からデータを取得する。このとき取得されるデータは、時刻Ｔｘから時刻Ｔｘ＋ΔＴの間に第２のデバイス３で保持されていたデータに対して、変化後のデータである可能性が高い。時間ΔＴは、統計的な評価の結果であり、第１のデバイス２からのデータの取得タイミングと第２のデバイス３におけるデータの変化タイミングに対する関係性が反映された時間だからである。時間ΔＴは、第１のデバイス２からのデータ取得時点から、第２のデバイス３において測定されるデータが変化するまでの時間を演算部１ｂにより予測した結果であるということもできる。こうして、情報処理装置１は、第２のデバイス３からデータを取得するタイミングを決定していくことで、データが変化した直後のタイミングを計り、オンデマンド型の第２のデバイス３からデータを効率的に取得できる。
【００３３】
例えば、変化のない（あるいは、変化が比較的小さい）データを、第２のデバイス３から一定周期で取得し続けるよりも、変化後のデータを効率的に取得できる。第２のデバイス３からデータを取得する頻度を減らせるので、情報処理装置１、第２のデバイス３および情報処理装置１と各デバイスとの通信に用いられるネットワークなどの負荷を抑えられる。更に、通信の頻度が減ることで、情報処理装置１や第２のデバイス３による消費電力を減らすこともできる。
【００３４】
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、施設内に配置されたセンサから取得した情報の変化を検知し、電気機器などのデバイスを自動制御する。例えば、住宅内において、センサから取得した情報により、家電機器などのデバイスを制御する情報処理システム（あるいは、そのようなシステムを備えた住宅）をスマートハウスと呼ぶこともある。
【００３５】
第２の実施の形態の情報処理システムは、ゲートウェイ１００、温度センサ２００、スマートコンセント３００，３００ａ、空調機４００およびＴＶ受像機５００を含む。ゲートウェイ１００は、ネットワーク１０を介して、温度センサ２００、スマートコンセント３００、空調機４００およびＴＶ受像機５００と接続されている。
【００３６】
ネットワーク１０は、例えばＬＡＮ（Local Area Network）である。ネットワーク１０は、有線ＬＡＮでもよいし、無線ＬＡＮでもよい。また、温度センサ２００、スマートコンセント３００，３００ａ、空調機４００およびＴＶ受像機５００の各種デバイスとゲートウェイ１００とは、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線技術を用いて接続されてもよい。ゲートウェイ１００は、ネットワーク２０にも接続されている。ネットワーク２０は、例えばインターネットである。ネットワーク２０には、サーバ６００が接続されている。
【００３７】
ゲートウェイ１００は、温度センサ２００、スマートコンセント３００，３００ａ、空調機４００およびＴＶ受像機５００などのデバイスからデータを取得する装置である。例えば、ゲートウェイ１００は、ＥＣＨＯＮＥＴ  Ｌｉｔｅ（ＥＣＨＯＮＥＴは登録商標）と呼ばれる通信プロトコルを用いて各デバイスからデータを取得する。ゲートウェイ１００は、ＥＣＨＯＮＥＴ  Ｌｉｔｅ以外の通信プロトコルを用いて各デバイスからデータを取得してもよい。ゲートウェイ１００は、プロセッサとメモリとを備えたコンピュータによって実現される。
【００３８】
例えば、ゲートウェイ１００は、環境監視用のアプリケーション（例えば、施設内の温度や各デバイスの消費電力量を管理するソフトウェア）を実行する。例えば、ゲートウェイ１００は、Ｗｅｂサーバとしても機能し、ネットワーク１０またはネットワーク２０に接続されたクライアント端末（コンピュータやスマート端末など）に、各デバイスから取得したデータや当該データを加工したデータ（例えば、省エネのアドバイスなど）を提供する。クライアント端末はＷｅｂブラウザとして機能し、クライアント端末が備えるディスプレイに、提供されたデータを表示させる。また、ゲートウェイ１００は、各デバイスから取得したデータ（例えば、温度）に基づいて、何れかのデバイス（例えば、空調機４００）の動作を制御する。
【００３９】
なお、上記のアプリケーションを実行するコンピュータまたはＷｅｂサーバとして機能するコンピュータは、ゲートウェイ１００以外でもよい（例えば、ネットワーク２０に接続された他のコンピュータでもよい）。
【００４０】
温度センサ２００およびスマートコンセント３００，３００ａは、オンデマンド型のデバイス（オンデマンド型デバイス）の一例である。
温度センサ２００は、現在の室温を測定する。温度センサ２００は、ゲートウェイ１００から測定データを要求されると、現在の室温を示す測定データをゲートウェイ１００に送信する。
【００４１】
スマートコンセント３００は、空調機４００による現在の消費電力量を測定する電力センサである。スマートコンセント３００ａは、ＴＶ受像機５００による現在の消費電力量を測定する電力センサである。スマートコンセント３００，３００ａは、ゲートウェイ１００から測定データを要求されると、空調機４００およびＴＶ受像機５００それぞれの現在の消費電力量を示す測定データをゲートウェイ１００に送信する。
【００４２】
空調機４００およびＴＶ受像機５００は、プッシュ型のデバイス（プッシュ型デバイス）の一例である。例えば、空調機４００は、起動（電源ＯＮ）または停止（電源ＯＦＦ）のタイミングで、空調機４００の起動または停止を示すデータをゲートウェイ１００にプッシュ送信する。すなわち、ゲートウェイ１００から要求がなくても、当該タイミングにおいてゲートウェイ１００へデータを送信する。空調機４００は、例えば、冷房／暖房／送風などの動作モードの変更のタイミングでも、当該変更を示すデータをゲートウェイ１００にプッシュ送信する。ＴＶ受像機５００も同様に、起動または停止のタイミングや動作モードの変更（例えば、音量変更など）のタイミングで、その旨を示すデータをゲートウェイ１００にプッシュ送信する。
【００４３】
サーバ６００は、ゲートウェイ１００にプログラムを配信するサーバコンピュータである。例えば、ゲートウェイ１００はサーバ６００からプログラムをダウンロードできる。
ここで、前述のように、スマートハウスなどのシステムでは、例えば、室温が規定値を上回るあるいは下回ると空調機器の運転を抑制したり、利用電力量が規定値を超過するとアプリケーションにより省エネのアドバイスを表示したりする。このようなシステムでは、室温や電力量の変化をリアルタイムで把握することが重要である。
【００４４】
温度センサなどのよく利用されるセンサには、オンデマンド型センサが多い。オンデマンド型センサを利用してリアルタイムでデータの変化を把握するために、ゲートウェイ１００は、比較的短い周期で、オンデマンド型センサに対してデータ取得コマンドを送信することが考えられる。しかし、この場合、コマンドの送信頻度が増え、ネットワーク１０やゲートウェイ１００などの負荷が高まるおそれがある。そこで、ゲートウェイ１００は、オンデマンド型センサから効率的に変化後のデータを取得する機能を提供する。
【００４５】
図３は、第２の実施の形態のゲートウェイのハードウェア例を示す図である。ゲートウェイ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３および通信インタフェース１０４，１０４ａを有する。各ユニットがゲートウェイ１００のバスに接続されている。
【００４６】
プロセッサ１０１は、ゲートウェイ１００全体を制御する。プロセッサ１０１は、複数のプロセッシング要素を含むマルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。また、プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００４７】
ＲＡＭ１０２は、ゲートウェイ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００４８】
ＨＤＤ１０３は、ゲートウェイ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。ゲートウェイ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００４９】
通信インタフェース１０４は、ネットワーク１０を介して、温度センサ２００、スマートコンセント３００，３００ａ、空調機４００およびＴＶ受像機５００と通信を行う。通信インタフェース１０４ａは、ネットワーク２０を介して、他のコンピュータ（サーバコンピュータやクライアント端末など）と通信を行う。通信インタフェース１０４，１０４ａは、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００５０】
図４は、第２の実施の形態の温度センサのハードウェア例である。温度センサ２００は、プロセッサ２０１、ＲＡＭ２０２、フラッシュメモリ２０３、センサ部２０４および通信インタフェース２０５を有する。各ユニットが温度センサ２００のバスに接続されている。温度センサ２００以外のオンデマンド型デバイス（例えば、スマートコンセント３００，３００ａ）も、温度センサ２００と同様のハードウェアにより実現できる。
【００５１】
プロセッサ２０１は、温度センサ２００全体を制御する。プロセッサ２０１は、複数のプロセッシング要素を含むマルチプロセッサであってもよい。プロセッサ２０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。また、プロセッサ２０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００５２】
ＲＡＭ２０２は、温度センサ２００の主記憶装置である。ＲＡＭ２０２は、プロセッサ２０１に実行させるファームウェアやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ２０２は、プロセッサ２０１による処理に用いる各種データを記憶する。
【００５３】
フラッシュメモリ２０３は、温度センサ２００の補助記憶装置である。フラッシュメモリ２０３には、ファームウェアのプログラム、アプリケーションプログラム、および各種データが格納される。
【００５４】
センサ部２０４は、物理量を計測する装置である。センサ部２０４は、周囲の温度を計測し、計測結果をプロセッサ２０１に出力する。
通信インタフェース２０５は、ネットワーク１０を介して、ゲートウェイ１００と通信を行う。通信インタフェース２０５は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００５５】
なお、スマートコンセント３００，３００ａのセンサ部による計測対象は、消費電力量である。
図５は、第２の実施の形態の空調機のハードウェア例である。空調機４００は、プロセッサ４０１、ＲＡＭ４０２、フラッシュメモリ４０３および通信インタフェース４０４を有する。各ユニットが空調機４００のバスに接続されている。空調機４００以外のプッシュ型デバイス（例えば、ＴＶ受像機５００）もゲートウェイ１００との通信制御機能を、空調機４００と同様のハードウェアにより実現できる。
【００５６】
プロセッサ４０１は、空調機４００全体を制御する。プロセッサ４０１は、複数のプロセッシング要素を含むマルチプロセッサであってもよい。プロセッサ４０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。また、プロセッサ４０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００５７】
ＲＡＭ４０２は、空調機４００の主記憶装置である。ＲＡＭ４０２は、プロセッサ４０１に実行させるファームウェアやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ４０２は、プロセッサ４０１による処理に用いる各種データを記憶する。
【００５８】
フラッシュメモリ４０３は、空調機４００の補助記憶装置である。フラッシュメモリ４０３には、ファームウェアのプログラム、アプリケーションプログラム、および各種データが格納される。
【００５９】
通信インタフェース４０４は、ネットワーク１０を介して、ゲートウェイ１００と通信を行う。通信インタフェース４０４は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００６０】
図６は、第２の実施の形態のサーバのハードウェア例を示す図である。サーバ６００は、プロセッサ６０１、ＲＡＭ６０２、ＨＤＤ６０３、画像信号処理部６０４、入力信号処理部６０５、媒体リーダ６０６および通信インタフェース６０７を有する。各ユニットがサーバ６００のバスに接続されている。
【００６１】
プロセッサ６０１は、サーバ６００全体を制御する。プロセッサ６０１は、複数のプロセッシング要素を含むマルチプロセッサであってもよい。プロセッサ６０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。また、プロセッサ６０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００６２】
ＲＡＭ６０２は、サーバ６００の主記憶装置である。ＲＡＭ６０２は、プロセッサ６０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ６０２は、プロセッサ６０１による処理に用いる各種データを記憶する。
【００６３】
ＨＤＤ６０３は、サーバ６００の補助記憶装置である。ＨＤＤ６０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ６０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。サーバ６００は、フラッシュメモリやＳＳＤなどの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００６４】
画像信号処理部６０４は、プロセッサ６０１からの命令に従って、サーバ６００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、有機ＥＬ（Electro-Luminescence）ディスプレイなど各種のディスプレイを用いることができる。
【００６５】
入力信号処理部６０５は、サーバ６００に接続された入力デバイス１２から入力信号を取得し、プロセッサ６０１に出力する。入力デバイス１２としては、マウスやタッチパネルなどのポインティングデバイスやキーボードなどの各種の入力デバイスを用いることができる。サーバ６００には、複数の種類の入力デバイスが接続されてもよい。
【００６６】
媒体リーダ６０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ６０６は、例えば、プロセッサ６０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ６０２またはＨＤＤ６０３に格納する。
【００６７】
通信インタフェース６０７は、ネットワーク２０を介して、ゲートウェイ１００と通信を行う。通信インタフェース６０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。例えば、サーバ６００は、記録媒体１３から読み出したプログラムをゲートウェイ１００に送信できる。
【００６８】
図７は、第２の実施の形態のゲートウェイの機能例を示す図である。ゲートウェイ１００は、記憶部１１０、プッシュ受信部１２０、データ取得部１３０、決定部１４０、予約部１５０およびアプリケーション１６０を有する。
【００６９】
記憶部１１０は、例えば、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域として実装される。プッシュ受信部１２０、データ取得部１３０、決定部１４０および予約部１５０は、例えば、プロセッサ１０１が実行するプログラムのモジュールとして実装される。
【００７０】
記憶部１１０は、履歴テーブル、分散値テーブル、タイミング管理テーブルおよび予約テーブルを記憶する。履歴テーブルは、温度センサ２００、スマートコンセント３００，３００ａ、空調機４００およびＴＶ受像機５００などの各デバイスから取得したデータの履歴の情報である。分散値テーブルは、プッシュ型デバイスからのデータ取得のタイミングと、オンデマンド型デバイスにおけるデータ変化のタイミングとの関係性を評価するための指標となる分散値（時間差の分散値）を示す情報である。タイミング管理テーブルは、オンデマンド型デバイスからデータを取得するタイミングの情報である。予約テーブルは、アプリケーション１６０に対するデータの通知予約に関する情報である。
【００７１】
ゲートウェイ１００は、準備処理と運用処理の２段階の処理を実行する。プッシュ受信部１２０、データ取得部１３０、決定部１４０は、準備処理を実行する。プッシュ受信部１２０、データ取得部１３０、予約部１５０は、運用処理を実行する。準備処理は、本番の運用開始前の一定期間（例えば、数時間程度）中に実行される。
【００７２】
プッシュ受信部１２０は、プッシュ型デバイスからプッシュ型デバイスの状態に変化が生じた旨の通知を受信する。当該通知は、プッシュ型デバイスからプッシュ送信されたデータである。通知には、プッシュ型デバイスの識別情報が含まれる。プッシュ受信部１２０は、受信した通知の内容を、プッシュ型デバイスの識別情報と、受信時刻とに対応付けて履歴テーブルに登録する。
【００７３】
データ取得部１３０は、準備処理では、定期的にオンデマンド型デバイスにデータの取得要求を送信し、オンデマンド型デバイスからデータを取得する。取得するデータには、オンデマンド型デバイスの識別情報が含まれる。データ取得部１３０は、取得したデータを、オンデマンド型デバイスの識別情報と、受信時刻とに対応付けて履歴テーブルに登録する。データ取得部１３０は、運用処理では、決定部１４０により決定されたタイミングでオンデマンド型デバイスからデータを取得する。
【００７４】
決定部１４０は、オンデマンド型デバイスからデータを取得するタイミングを決定する。当該タイミングは、トリガデバイスからの通知タイミングに対して決定される。トリガデバイスは、オンデマンド型デバイスからデータを取得する契機（トリガ）となるイベントを通知するデバイスである。第２の実施の形態では、プッシュ型デバイスをトリガデバイスの候補とするが、プッシュ型デバイス以外のデバイスをトリガデバイスの候補としてもよい。
【００７５】
決定部１４０は、履歴テーブルに基づいて、トリガデバイスによる通知タイミングから一定時間後に、取得されるデータが変化するオンデマンド型デバイスと、データの変化までの時間とを判定する。決定部１４０は、判定した当該オンデマンド型デバイスの識別情報とデータの変化までの時間とを、トリガデバイスの識別情報に対応付けてタイミング管理テーブルに登録する。すなわち、当該トリガデバイスから通知を受けてから、タイミング管理テーブルに登録された時間を経過したタイミングが、該当のオンデマンド型デバイスからデータを取得するタイミングとなる。
【００７６】
予約部１５０は、アプリケーション１６０から予約イベントを受信する。予約イベントは、オンデマンド型デバイスが測定したデータ値の変化の通知を予約するイベントである。予約部１５０は、アプリケーション１６０から受信した予約内容を予約テーブルに登録する。予約部１５０は、データ取得部１３０がオンデマンド型デバイスから取得したデータに変化があると判定した場合、アプリケーション１６０にその旨を通知する。
【００７７】
アプリケーション１６０は、空調機４００やＴＶ受像機５００に対して様々な指示を行うアプリケーション（例えば、Ｗｅｂアプリケーション）である。例えば、アプリケーション１６０は、予約部１５０から取得する温度の値に基づいて、省電力モードに切り替えるよう空調機４００へ指示する。また、アプリケーション１６０は、オンデマンド型デバイスが測定したデータ値（例えば、温度や電力）や省エネのアドバイスなどをクライアント端末に通知する。
【００７８】
なお、アプリケーション１６０は、ゲートウェイ１００以外の装置にインストールされていてもよい。例えば、アプリケーション１６０は、ネットワーク２０に接続されたサーバコンピュータによって実行されてもよい。
【００７９】
図８は、第２の実施の形態の温度センサの機能例を示す図である。温度センサ２００は、記憶部２１０、送受信部２２０および計測部２３０を有する。記憶部２１０は、例えば、ＲＡＭ２０２またはフラッシュメモリ２０３に確保した記憶領域として実装される。送受信部２２０および計測部２３０は、例えば、プロセッサ２０１が実行するプログラムのモジュールとして実装される。
【００８０】
記憶部２１０は、温度センサ２００の動作に利用される設定情報や計測部２３０により計測された温度の履歴の情報を記憶する。
送受信部２２０は、ゲートウェイ１００からデータの取得要求を受信する。送受信部２２０は、データの取得要求に応じて、計測部２３０により計測された現在の温度の情報をゲートウェイ１００に送信する。
【００８１】
計測部２３０は、センサ部２０４を用いて周囲の温度を計測し、記憶部２１０に格納する。
なお、スマートコンセント３００，３００ａも温度センサ２００と同様の機能を有する。ただし、スマートコンセント３００，３００ａの計測部による計測対象は、消費電力量である。
【００８２】
図９は、第２の実施の形態の空調機の機能例を示す図である。空調機４００は、記憶部４１０、プッシュ送信部４２０および検出部４３０を有する。記憶部４１０は、例えば、ＲＡＭ４０２またはフラッシュメモリ４０３に確保した記憶領域として実装される。プッシュ送信部４２０および検出部４３０は、例えば、プロセッサ４０１が実行するプログラムのモジュールとして実装される。
【００８３】
記憶部４１０は、空調機４００の動作に利用される設定情報を記憶する。
プッシュ送信部４２０は、空調機４００における状態の変化（例えば、電源のオン／オフの切替や動作モードの変化）に応じてゲートウェイ１００へ当該状態の変化を示すデータをプッシュ送信する。
【００８４】
検出部４３０は、空調機４００の状態の変化を検出する。検出部４３０は、状態の変化の検出に応じて、プッシュ送信部４２０によるプッシュ送信を実行させる。
なお、ＴＶ受像機５００も空調機４００と同様の機能を有する。
【００８５】
図１０は、第２の実施の形態のパケット例を示す図である。パケット３０は、各デバイスからゲートウェイ１００へ、あるいは、ゲートウェイ１００から各デバイスへ送信されるパケットの例である。
【００８６】
パケット３０は、宛先デバイスＩＤ（IDentifier）、送信元デバイスＩＤおよびペイロードを含む。宛先デバイスＩＤには、宛先のデバイスまたはゲートウェイのＩＤが格納される。送信元デバイスＩＤには、送信元のデバイスまたはゲートウェイのＩＤが格納される。宛先デバイスＩＤおよび送信元デバイスＩＤは、デバイスまたはゲートウェイに割り振られたアドレスの情報でもよい。ペイロードには、各デバイスからゲートウェイ１００へ、または、ゲートウェイ１００から各デバイスへ送信する情報が格納される。
【００８７】
図１１は、第２の実施の形態の履歴テーブルの例を示す図である。履歴テーブル１１１は、記憶部１１０に格納される。履歴テーブル１１１は、デバイスＩＤ、データ種別、データ値および時刻の項目を含む。
【００８８】
デバイスＩＤの項目には、デバイスを識別するための情報が登録される。データ種別の項目には、データの種別を示す情報が登録される。データ値の項目には、データ種別の項目に対応するデータ値が登録される。時刻の項目には、時刻が登録される。
【００８９】
例えば、履歴テーブル１１１には、デバイスＩＤが“ｔｅｍｐ＿ｓｅｎｓｏｒ”、データ種別が“ｔｅｍｐｅｒａｔｕｒｅ”、データ値が“１６．５”および時刻が“２０１５／０１／３０  １０：００：００”という情報が登録される。
【００９０】
これは、温度センサ２００（“ｔｅｍｐ＿ｓｅｎｓｏｒ”）から温度（“ｔｅｍｐｅｒａｔｕｒｅ”）が１６．５℃であるという情報を２０１５年１月３０日１０時００分００秒に取得したことを示す。
【００９１】
また、例えば、履歴テーブル１１１には、デバイスＩＤが“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｎ”および時刻が“２０１５／０１／３０  １０：０２：１５”という情報が登録される。
【００９２】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から現在の状態（“ｓｔａｔｕｓ”）が電源ＯＮ（“ｏｎ”）になったという情報を２０１５年１月３０日１０時０２分１５秒に取得したことを示す。
【００９３】
図１２は、第２の実施の形態の分散値テーブルの例を示す図である。分散値テーブル１１２は、記憶部１１０に格納される。分散値テーブル１１２は、データ種別および分散値の項目を含む。
【００９４】
データ種別の項目には、データの種別を示す情報が登録される。分散値の項目には、閾値となる分散値を示す情報が登録される。当該閾値は、プッシュ型デバイスからのデータの取得タイミングと、オンデマンド型デバイスにおける測定データの変化のタイミングとの関係性を評価するための指標である。両タイミングの間の時間差を複数サンプリングし、当該時間差のばらつきが比較的小さければ（すなわち、分散が当該閾値以下であれば）、プッシュ型デバイスからのデータの取得タイミングと、オンデマンド型デバイスにおける測定データの変化のタイミングとの間に関係性があると評価できる。
【００９５】
例えば、分散値テーブル１１２には、データ種別が“ｔｅｍｐｅｒａｔｕｒｅ”および分散値“Ｒ１”という情報が登録される。
図１３は、第２の実施の形態のタイミング管理テーブルの例を示す図である。タイミング管理テーブル１１３は、記憶部１１０に格納される。タイミング管理テーブル１１３は、デバイスＩＤ、取得データ種別、トリガデバイスＩＤ、トリガデータ種別、トリガデータ値および待ち時間の項目を含む。
【００９６】
デバイスＩＤの項目には、デバイスを識別するための情報が登録される。取得データ種別の項目には、データの種別を示す情報が登録される。トリガデバイスＩＤの項目には、デバイスを識別するための情報が登録される。トリガデータ種別の項目には、トリガとするデータ（トリガデータ）の種別を示す情報が登録される。トリガデータ値の項目には、トリガデータのデータ値が登録される。待ち時間の項目には、トリガデバイスから通知を受信してからオンデマンド型デバイスにデータの取得要求を送信するまでの待ち時間が登録される。
【００９７】
例えば、タイミング管理テーブル１１３には、デバイスＩＤが“ｔｅｍｐ＿ｓｅｎｓｏｒ”、取得データ種別が“ｔｅｍｐｅｒａｔｕｒｅ”、トリガデバイスＩＤが“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、トリガデータ種別が“ｓｔａｔｕｓ”、トリガデータ値が“ｏｎ”および待ち時間が“２：１０”という情報が登録される。
【００９８】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から現在の状態（“ｓｔａｔｕｓ”）が電源ＯＮ（“ｏｎ”）であるという情報を取得してから２分１０秒待機した後に、温度センサ２００（“ｔｅｍｐ＿ｓｅｎｓｏｒ”）に温度（“ｔｅｍｐｅｒａｔｕｒｅ”）のデータの取得要求を送信することを示す。
【００９９】
図１４は、第２の実施の形態の予約テーブルの例を示す図である。予約テーブル１１４は、記憶部１１０に格納される。予約テーブル１１４は、サービスＩＤ、デバイスＩＤ、通知データおよび通知先ＵＲＬ（Uniform Resource Locator）の項目を含む。
【０１００】
サービスＩＤの項目には、サービスを識別する情報が登録される。デバイスＩＤの項目には、デバイスを識別するための情報が登録される。通知データの項目には、通知するデータ種別を示す情報が登録される。通知先ＵＲＬの項目には、通知先のＷｅｂアプリケーション（例えば、アプリケーション１６０）を示すＵＲＬが登録される。前述のように、ＵＲＬで示されるアプリケーションは、アプリケーション１６０でもよいし、他のサーバコンピュータで実行されるアプリケーションでもよい。
【０１０１】
例えば、予約テーブル１１４には、サービスＩＤが“ｅｎｅｒｇｙ＿ｓａｖｉｎｇ”、デバイスＩＤが“ｏｕｔｌｅｔ”、通知データが“ｐｏｗｅｒ”および通知先ＵＲＬが“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｎｏｔｉｆｙ／”という情報が登録される。
【０１０２】
これは、省電力のサービス（“ｅｎｅｒｇｙ＿ｓａｖｉｎｇ”）の場合、スマートコンセント３００（“ｏｕｔｌｅｔ”）に内蔵されている電力センサが測定する電力（“ｐｏｗｅｒ”）に変化が生じた際には、“ｈｔｔｐ：／／ｗｗｗ.ｆｏｏ.ｃｏｍ／ｎｏｔｉｆｙ／”にその旨を通知することを示す。
【０１０３】
図１５は、第２の実施の形態の準備処理の具体例を示す図である。図１５では、データ取得部１３０が定期的にオンデマンド型デバイス（例えば、温度センサ２００）からデータを取得し、プッシュ受信部１２０がプッシュ型デバイス（例えば、空調機４００）からプッシュ通知を受信する場合を示している。
【０１０４】
データ取得部１３０は、定期的にオンデマンド型デバイスにデータの取得要求を送信する。そして、データ取得部１３０は、時刻Ｔ０〜Ｔ１５の各タイミングで、オンデマンド型デバイスからデータを取得する（時刻Ｔ７〜Ｔ９は図示を省略している）。オンデマンド型デバイスが温度センサ２００であれば、取得されるデータには温度センサ２００が測定した現在の温度の情報が含まれる。図１５の例では、時刻Ｔ４のデータ値および時刻Ｔ１３のデータ値が、直前の時刻に取得したデータ値に比べて所定量以上変化している（所定量は、観測対象としたいデータ変化に応じて予め定められる）。
【０１０５】
プッシュ受信部１２０は、時刻Ｔｐ１にプッシュ型デバイスからの通知を受信する。例えば、プッシュ型デバイスが空調機４００であれば、冷房を起動した旨の通知を受信する。また、プッシュ受信部１２０は、時刻Ｔｐ１１に当該プッシュ型デバイスからの通知を受信する。例えば、プッシュ型デバイスが空調機４００であれば、冷房を起動した旨の通知を受信する。
【０１０６】
以上の情報は、履歴テーブル１１１に登録される。決定部１４０は、履歴テーブル１１１を参照し、時刻Ｔｐ１から時間ΔＴａ後の時刻Ｔｐ２までの間にデータ値に変化があるオンデマンド型デバイス（例えば、温度センサ２００）を特定する。決定部１４０は、変化したデータ値を当該オンデマンド型デバイスから取得した時刻Ｔ４を特定する。
【０１０７】
同様に、決定部１４０は、履歴テーブル１１１を参照し、時刻Ｔｐ１１から時間ΔＴａ後の時刻Ｔｐ１２までの間にデータ値に変化があるオンデマンド型デバイス（例えば、温度センサ２００）を特定する。決定部１４０は、変化したデータ値を当該オンデマンド型デバイスから取得した時刻Ｔ１３を特定する。
【０１０８】
こうして、決定部１４０は、評価対象とするプッシュ型デバイスとオンデマンド型デバイスとの組を特定する。決定部１４０は、あるプッシュ型デバイスとオンデマンド型デバイスの組について、一定数以上サンプリングできる場合、当該プッシュ型デバイスから通知を受信した時刻と、変化したデータ値を当該オンデマンド型デバイスから取得した時刻との時間差を算出する。例えば、決定部１４０は、時刻Ｔ４および時刻Ｔｐ１の時間差ΔＴｏｐ１を算出する。決定部１４０は、時刻Ｔ１３および時刻Ｔｐ１１の時間差ΔＴｏｐ２を算出する。そして、決定部１４０は、算出した時間差を用いて、平均値ΔＴｏｐと分散値Ｒを算出する。ここで、各組の時間差の平均値を時間ΔＴｏｐとする。決定部１４０は、分散値Ｒが分散値テーブル１１２に登録された値以下である場合、当該オンデマンド型デバイスからデータを取得するタイミングを、当該プッシュ型デバイスからデータを取得してから時間ΔＴｏｐが経過した後と決定する。
【０１０９】
次に、ゲートウェイ１００による準備処理の手順を説明する。まず、図１６によりオンデマンド型デバイスから定期的にデータを取得する手順を説明し、次に、図１８によりプッシュ型デバイスから通知を受けた場合の手順を説明する。以下に示す図１６，１８の処理は並行して実行される。
【０１１０】
図１６は、第２の実施の形態の準備処理例（その１）を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
（Ｓ１１）データ取得部１３０は、オンデマンド型デバイスからデータを取得する時間間隔を決定するためのタイマーが満了したか否かを判定する。タイマーが満了した場合、処理をステップＳ１２に進める。タイマーが満了していない場合、ステップＳ１１を繰り返す（すなわち、タイマーが満了するまで待機する）。タイマーの値は、例えば１０秒である。タイマーの値は、オンデマンド型デバイス毎に異なってもよい。
【０１１１】
（Ｓ１２）データ取得部１３０は、オンデマンド型デバイスにデータの取得要求を送信する。データ取得部１３０は、取得要求の応答としてオンデマンド型デバイスからデータを取得する。取得したデータには、デバイスＩＤ、データ種別、データ値が含まれる。
【０１１２】
（Ｓ１３）データ取得部１３０は、取得したデータを履歴テーブル１１１に登録する。また、データ取得部１３０は、データを取得した時刻を履歴テーブル１１１に登録する。
（Ｓ１４）データ取得部１３０は、オンデマンド型デバイスに設定されているタイマーをセットする。これにより、データ取得部１３０は、再度タイマーによる時間計測を開始する。そして、処理をステップＳ１１に進める。
【０１１３】
図１７は、第２の実施の形態のオンデマンド型デバイスの処理例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。図１７では、温度センサ２００を例示するが、スマートコンセント３００，３００ａも同様の手順となる。
【０１１４】
（Ｓ１０１）送受信部２２０は、ゲートウェイ１００からデータの取得要求を受信する。
（Ｓ１０２）計測部２３０は、データの取得要求に応じてセンサ部２０４により温度の計測結果を取得する。
【０１１５】
（Ｓ１０３）送受信部２２０は、計測部２３０により取得された温度のデータをゲートウェイ１００に送信する。
スマートコンセント３００，３００ａの場合、ゲートウェイ１００に対して消費電力量の情報が送信されることになる。
【０１１６】
図１８は、第２の実施の形態の準備処理例（その２）を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
（Ｓ２１）プッシュ受信部１２０は、何れかのプッシュ型デバイスから通知を受信したか否かを判定する。プッシュ型デバイスから通知を受信した場合、処理をステップＳ２２に進める。プッシュ型デバイスから通知を受信していない場合、ステップＳ２１を繰り返す（当該通知を受信するまで待機する）。プッシュ型デバイスから受信する通知の内容には、デバイスＩＤ、データ種別、データ値が含まれる。
【０１１７】
（Ｓ２２）プッシュ受信部１２０は、受信した通知の内容を履歴テーブル１１１に登録する。また、プッシュ受信部１２０は、通知を受信した時刻を履歴テーブル１１１に登録する。プッシュ受信部１２０は、データの取得タイミングの判定を実行するように決定部１４０に指示する。
【０１１８】
（Ｓ２３）決定部１４０は、時間ΔＴａだけ待機する。時間ΔＴａは例えば数秒程度でもよいし数分程度でもよい。時間ΔＴａは、監視対象に応じて定めることができる。時間ΔＴａ経過後、決定部１４０は、履歴テーブル１１１を参照し、プッシュ型デバイスの通知から時間ΔＴａが経過するまでの間にデータ値に変化のあるオンデマンド型デバイスを特定する。例えば、決定部１４０は、当該オンデマンド型デバイスから今回取得したデータ値が前回取得したデータ値よりも所定割合以上変化した場合に、データ値に変化があったと判断する（割合の情報は観測したいデータ変化に応じて予め記憶部１１０に格納される）。すなわち、決定部１４０は、所定割合よりも小さい変化を変化していないとみなす。こうして、決定部１４０は、プッシュ型デバイスとプッシュ型デバイスからの通知の内容と当該通知から時間ΔＴａ内にデータ値が変化するオンデマンド型デバイスとの組を決定する。
【０１１９】
（Ｓ２４）決定部１４０は、ステップＳ２３で決定した組が所定数以上、存在するか否かを判定する。所定数以上存在する場合、処理をステップＳ２５に進める。所定数以上存在しない場合、処理をステップＳ２１に進める。所定数は、例えば統計的な精度を確保できる程度の数として予め定められる（１０組程度でもよい）。空調機４００と温度センサ２００との例でいえば、決定部１４０は、空調機４００からデータ値“ｏｎ”を受信したイベントと、当該イベントから所定時間ΔＴａ内に温度センサ２００からデータを受信したイベントとの組が所定数以上、存在するか否かを判定する。
【０１２０】
（Ｓ２５）決定部１４０は、履歴テーブル１１１を参照し、プッシュ型デバイスから通知を受信した時刻と、変化したデータ値をオンデマンド型デバイスから取得した時刻との時間差を組毎に算出する。例えば、決定部１４０は、ステップＳ２２で履歴テーブル１１１に登録した時刻と、ステップＳ２３で特定したオンデマンド型デバイスのデータ値が変化した時刻との時間差を算出する。当該プッシュ型デバイスと当該オンデマンド型デバイスとの他の組についても同様に時間差を算出する。決定部１４０は、算出した各組の時間差に基づいて、時間差の平均値と分散値とを算出する。
【０１２１】
（Ｓ２６）決定部１４０は、分散値テーブル１１２を参照して、算出した分散値が分散値テーブル１１２の値（閾値）以下であるか否かを判定する。分散値が閾値以下である場合、処理をステップＳ２７に進める。分散値が閾値以下でない場合、処理をステップＳ２１に進める。例えば、ステップＳ２３で特定したオンデマンド型デバイスが温度センサ２００の場合、決定部１４０は、分散値テーブル１１２を参照し、各組の時間差を用いて算出した分散値が閾値Ｒ１以下であるか否かを判定する。閾値Ｒ１以下の場合、処理をステップＳ２７に進める。閾値Ｒ１以下でない場合、処理を終了する。
【０１２２】
（Ｓ２７）決定部１４０は、プッシュ型デバイスとオンデマンド型デバイスの組に関する情報をタイミング管理テーブル１１３に登録する。具体的には、決定部１４０は、ステップＳ２３で特定したオンデマンド型デバイスのデバイスＩＤ、オンデマンド型デバイスが送信するデータの種別をタイミング管理テーブル１１３のデバイスＩＤおよび取得データ種別に登録する。また、決定部１４０は、ステップＳ２１で通知したプッシュ型デバイスのデバイスＩＤをタイミング管理テーブル１１３のトリガデバイスＩＤに登録する。決定部１４０は、ステップＳ２１で受信したデータ種別、データ値をタイミング管理テーブル１１３のトリガデータ種別およびトリガデータ値に登録する。さらに、決定部１４０は、ステップＳ２５で算出した平均値をタイミング管理テーブル１１３の待ち時間に登録する。そして、処理をステップＳ２１に進める。
【０１２３】
このように、プッシュ型デバイスとオンデマンド型デバイスとの組が所定数設定した後に、各組の時間差に基づいてオンデマンド型デバイスからデータを取得するタイミングを決定する。
【０１２４】
決定部１４０は、プッシュ型デバイスとオンデマンド型デバイスとの組が所定数以上である場合、図１８の処理を繰り返すことで、当該組についてオンデマンド型デバイスからデータを取得するタイミングを更新する。これにより、当該タイミングの決定精度を向上できる。ただし、決定部１４０は、タイミング管理テーブル１１３に登録された組については、ステップＳ２３以降の処理を行わないよう制御してもよい。
【０１２５】
次に、運用処理の説明を行う。前述のように、ゲートウェイ１００は、準備処理を所定期間実行した後、準備処理の実行を終了し、運用処理の実行を開始する。まず、図１９により、アプリケーション１６０から予約イベントを受け付ける手順を説明する。次に、図２０により、プッシュ型デバイスから通知を受けたときの手順を説明する。以下に示す図１９，２０の処理は並行して実行される。
【０１２６】
図１９は、第２の実施の形態の運用処理例（その１）を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
（Ｓ３１）予約部１５０は、アプリケーション１６０から予約イベントを受け付けたか否かを判定する。予約イベントを受け付けた場合、処理をステップＳ３２に進める。予約イベントを受け付けていない場合、ステップＳ３１を繰り返す（予約イベントの受け付けを待機する）。ここで、アプリケーション１６０による予約イベントには、サービスＩＤ、デバイスＩＤ、通知データ、通知先ＵＲＬの情報が含まれる。
【０１２７】
（Ｓ３２）予約部１５０は、予約イベントの情報を予約テーブル１１４に登録する。そして、処理をステップＳ３１に進める。
図２０は、第２の実施の形態の運用処理例（その２）を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
【０１２８】
（Ｓ４１）プッシュ受信部１２０は、何れかのプッシュ型デバイスから通知を受信したか否かを判定する。プッシュ型デバイスから通知を受信した場合、処理をステップＳ４２に進める。プッシュ型デバイスから通知を受信していない場合、ステップＳ４１を繰り返す（当該通知を受信するまで待機する）。プッシュ型デバイスから受信する通知の内容には、デバイスＩＤ、データ種別、データ値が含まれる。
【０１２９】
（Ｓ４２）プッシュ受信部１２０は、受信した通知の内容と受信した時刻とを履歴テーブル１１１に登録する。プッシュ受信部１２０は、ステップＳ４１の通知元のプッシュ型デバイスがトリガデバイスであるか否かの判定を実行するようにデータ取得部１３０に指示する。
【０１３０】
（Ｓ４３）データ取得部１３０は、ステップＳ４１の通知元のプッシュ型デバイスがトリガデバイスであるか否かを判定する。トリガデバイスである場合、処理をステップＳ４４に進める。トリガデバイスでない場合、処理をステップＳ４１に進める。具体的には、ステップＳ４１の通知内容のデバイスＩＤ、データ種別およびデータ値が、タイミング管理テーブル１１３に登録されたトリガデバイスＩＤ、トリガデータ種別およびトリガデータ値の組に一致する場合、通知元のプッシュ型デバイスはトリガデバイスである。一致しない場合、通知元のプッシュ型デバイスはトリガデバイスでない。
【０１３１】
（Ｓ４４）データ取得部１３０は、タイミング管理テーブル１１３の待ち時間を参照し、当該待ち時間が経過するまで待機する。当該待ち時間の経過後、データ取得部１３０は、タイミング管理テーブル１１３のデバイスＩＤで示されるオンデマンド型デバイスに対して、タイミング管理テーブル１１３の取得データ種別に対応するデータの取得要求を送信する。
【０１３２】
（Ｓ４５）データ取得部１３０は、データの取得要求に対してオンデマンド型デバイスから応答を受信する。応答には、デバイスＩＤ、データ種別およびデータ値が含まれる。データ取得部１３０は、応答の内容を履歴テーブル１１１に登録する。また、データ取得部１３０は、応答を受信した時刻を履歴テーブル１１１に登録する。
【０１３３】
（Ｓ４６）データ取得部１３０は、履歴テーブル１１１を参照し、ステップＳ４５で受信したデータ値と、当該オンデマンド型デバイスから前回取得したデータ値とを比較して、変化しているか否かを判定する。例えば、ステップＳ２３と同様に、前回取得していたデータ値よりも所定割合以上変化した場合に、データに変化があったと判断してもよい。変化している場合、その旨を予約部１５０に通知する。そして、処理をステップＳ４７に進める。変化していない場合、処理をステップＳ４１に進める。
【０１３４】
（Ｓ４７）予約部１５０は、予約テーブル１１４のデバイスＩＤおよび通知データを参照し、ステップＳ４５の応答内容のデバイスＩＤ（オンデマンド型デバイス）およびデータ種別が予約テーブル１１４に登録されているか否かを判定する。登録されている場合、処理をステップＳ４８に進める。登録されていない場合、処理をステップＳ４１に進める。
【０１３５】
（Ｓ４８）予約部１５０は、予約テーブル１１４の通知先ＵＲＬを参照し、ステップＳ４５で受信した応答のデータ値を当該通知先に送信する。そして、処理をステップＳ４１に進める。
【０１３６】
このように、ゲートウェイ１００は、プッシュ型デバイスからの値の変更通知から、ある期間内に値が変わるオンデマンド型デバイスを発見する。ゲートウェイ１００は、以後、プッシュ型デバイスの変更通知を受信した際には当該期間だけ待機した上で、発見したオンデマンド型デバイスからデータを取得する。
【０１３７】
これにより、例えば、変化のない（あるいは、変化が比較的小さい）データを、温度センサ２００またはスマートコンセント３００から一定周期で取得し続けるよりも、変化後のデータを効率的に取得できる。温度センサ２００またはスマートコンセント３００からデータを取得する頻度を減らせるので、ゲートウェイ１００と温度センサ２００またはスマートコンセント３００との通信に用いられるネットワークなどの負荷を抑えられる。更に、通信の頻度が減ることで、ゲートウェイ１００や温度センサ２００またはスマートコンセント３００による消費電力を減らすこともできる。
【０１３８】
以上のように、ゲートウェイ１００によれば、システムへの負荷を軽減しながら、遅延のないように、オンデマンド型デバイスの変化後の値を取得できる。
なお、準備処理の段階では、何れのトリガデバイスとも対応付けられないオンデマンド型デバイスもあり得る。そのようなオンデマンド型デバイスについて、ゲートウェイ１００は、運用段階でも図１６で例示した手順と同じ手順によって、データを取得することになる。
【０１３９】
［第３の実施の形態］
次に、第３の実施の形態を説明する。前述の第２の実施の形態との相違する事項を主に説明し、共通する事項の説明を省略する。
【０１４０】
第２の実施の形態では、各デバイスから取得されたデータの履歴から、統計処理によりトリガデバイスを決定する例を示した。一方、第３の実施の形態では、プッシュ型デバイスからデータを取得したことを契機に、ゲートウェイ１００がオンデマンド型デバイスの測定データに変化があるか否かを確認する機能を提供する。
【０１４１】
ここで、第３の実施の形態の情報処理システムは、図２で示した第２の実施の形態の情報処理システムと同様である。また、第３の実施の形態の情報処理システムに含まれる装置や機能は、図３〜９で示した第２の実施の形態の装置や機能と同様である。そこで、第３の実施の形態では、第２の実施の形態と同じ符号、名称を用いる。第３の実施の形態では、第２の実施の形態で例示したテーブルに加えて、トリガ即時決定制御テーブルを更に用いる。
【０１４２】
図２１は、第３の実施の形態のトリガ即時決定制御テーブルの例を示す図である。トリガ即時決定制御テーブル１１５は、記憶部１１０に格納される。トリガ即時決定制御テーブル１１５は、デバイス種別、データ種別、データ値およびトリガ即時決定の項目を含む。
【０１４３】
デバイス種別の項目には、プッシュ型デバイスを示す情報が登録される。データ種別の項目には、データの種別を示す情報が登録される。データ値の項目には、データ種別の項目に対応するデータ値が登録される。トリガ即時決定の項目には、トリガデバイスの即時決定の対象とするか否かを示す情報が登録される。
【０１４４】
例えば、トリガ即時決定制御テーブル１１５には、デバイス種別が“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｎ”、トリガ即時決定が“Ｙｅｓ”という情報が登録される。
【０１４５】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から通知されたデータ種別“ｓｔａｔｕｓ”およびデータ値が“ｏｎ”の場合、空調機４００をトリガデバイスの即時決定対象とする（“Ｙｅｓ”）ことを示す。
【０１４６】
また、トリガ即時決定制御テーブル１１５には、デバイス種別が“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｆｆ”、トリガ即時決定が“Ｎｏ”という情報が登録される。
【０１４７】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から通知されたデータ種別“ｓｔａｔｕｓ”およびデータ値が“ｏｆｆ”の場合、空調機４００をトリガデバイスの即時決定対象としない（“Ｎｏ”）ことを示す。
【０１４８】
次に、第３の実施の形態の準備処理の手順を説明する（運用処理の手順については、第２の実施の形態と同様である）。第３の実施の形態の準備処理の手順は、図１８で説明した第２の実施の形態の準備処理の手順と一部が異なる。
【０１４９】
図２２は、第３の実施の形態の準備処理例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。第３の実施の形態では、図１８で示した手順に対して、ステップＳ２２の次にステップＳ２２ａ，Ｓ２２ｂ，Ｓ２２ｃを追加する。そこで、以下ではステップＳ２２ａ，Ｓ２２ｂ，Ｓ２２ｃを説明し、他のステップの説明を省略する。
【０１５０】
（Ｓ２２ａ）決定部１４０は、トリガ即時決定制御テーブル１１５とステップＳ２１で通知を受けたプッシュ型デバイスのデバイスＩＤ、データ種別およびデータ値とに基づいて、当該プッシュ型デバイスをトリガデバイスの即時決定対象とするか否かを判定する。即時決定対象とする場合、処理をステップＳ２２ｂに進める。即時決定対象としない場合、処理をステップＳ２３に進める。
【０１５１】
（Ｓ２２ｂ）決定部１４０は、オンデマンド型デバイスにデータの取得要求を送信する。ここで、送信先は、全てのオンデマンド型デバイスであってもよいし、予め決められたオンデマンド型デバイスでもよい。複数の種別のデータを測定するオンデマンド型デバイスに対しては、当該複数の種別のデータの取得要求を送信する。決定部１４０は、オンデマンド型デバイスから取得要求に対する応答を受信する。応答の内容には、デバイスＩＤ、データ種別、データ値が含まれる。決定部１４０は、応答の内容を履歴テーブル１１１に登録する。また、決定部１４０は、応答を受信した時刻を履歴テーブル１１１に登録する。
【０１５２】
（Ｓ２２ｃ）決定部１４０は、履歴テーブル１１１を参照し、オンデマンド型デバイス毎に、ステップＳ２２ｂで取得したデータ値と当該オンデマンド型デバイスからステップＳ２２ｂよりも前の時点で取得していたデータ値とを比較する。決定部１４０は、当該比較に応じて、データ値が変化しているオンデマンド型デバイスが存在するか否かを判定する。存在する場合、処理をステップＳ２７に進める。存在しない場合、処理をステップＳ２１に進める。１つのオンデマンド型デバイスから複数の種別のデータを取得している場合、データの種別毎に変化の有無を判定する。例えば、ステップＳ２３と同様に、前に取得していたデータ値よりも所定割合以上変化した場合に、データに変化があったと判断してもよい。
【０１５３】
図２３は、第３の実施の形態のタイミング管理テーブルの例を示す図である。タイミング管理テーブル１１３ａは、図２２で説明した第３の実施の形態の準備処理により登録される内容を幾つか例示している。
【０１５４】
例えば、タイミング管理テーブル１１３ａには、デバイスＩＤが“ｏｕｔｌｅｔ”、取得データ種別が“ｐｏｗｅｒ”、トリガデバイスＩＤが“ｔｅｌｅｖｉｓｉｏｎ”、トリガデータ種別が“ｓｔａｔｕｓ”、トリガデータ値が“ｏｎ”および待ち時間が“０：００”という情報が登録される。
【０１５５】
これは、ＴＶ受像機５００（“ｔｅｌｅｖｉｓｉｏｎ”）から現在の状態（“ｓｔａｔｕｓ”）が電源ＯＮ（“ｏｎ”）であるという情報をプッシュ受信部１２０が取得してから０秒経過後（待機せずに）に、データ取得部１３０がスマートコンセント３００（“ｏｕｔｌｅｔ”）に電力（“ｐｏｗｅｒ”）のデータの取得要求を送信することを示す。
【０１５６】
このように、ゲートウェイ１００は、プッシュ型デバイスから通知を受信すると、即座にトリガデバイスの決定を行ってもよい。ＴＶ受像機５００とスマートコンセント３００との例でいえば、決定部１４０は、ＴＶ受像機５００が電源ＯＮになった場合、スマートコンセント３００からデータ値を即座に取得する。決定部１４０は、スマートコンセント３００から今回取得したデータが、スマートコンセント３００から前回取得したデータ値に対して変化している場合には、ＴＶ受像機５００の電源ＯＮイベントを、スマートコンセント３００からデータを取得するトリガと決定する。こうして、ＴＶ受像機５００が電源ＯＮの状態になった直後に、スマートコンセント３００の測定データを適切に取得可能となる。
【０１５７】
［第４の実施の形態］
次に、第４の実施の形態を説明する。前述の第２の実施の形態との相違する事項を主に説明し、共通する事項の説明を省略する。
【０１５８】
プッシュ型デバイスの通知内容によっては、プッシュ型デバイスをトリガデバイスとして利用したくない場合もあり得る。例えば、空調機４００が電源ＯＦＦになった後の温度の情報を取得しなくてよい場合もあり得る。そこで、プッシュ型デバイスの通知内容に基づいてトリガデバイスを決定するか否かを選択する機能を提供する。
【０１５９】
ここで、第４の実施の形態の情報処理システムは、図２で示した第２の実施の形態の情報処理システムと同様である。また、第４の実施の形態の情報処理システムに含まれる装置や機能は、図３〜９で示した第２の実施の形態の装置や機能と同様である。そこで、第４の実施の形態では、第２の実施の形態と同じ符号、名称を用いる。また、第４の実施の形態では、第２の実施の形態で例示したテーブルに加えて、トリガ決定制御テーブルを更に用いる。
【０１６０】
図２４は、第４の実施の形態のトリガ決定制御テーブルの例を示す図である。トリガ決定制御テーブル１１６は、記憶部１１０に格納される。トリガ決定制御テーブル１１６は、デバイス種別、データ種別、データ値およびトリガ決定の項目を含む。
【０１６１】
デバイス種別の項目には、プッシュ型デバイスを示す情報が登録される。データ種別の項目には、データの種別を示す情報が登録される。データ値の項目には、データ種別の項目に対応するデータ値が登録される。トリガ決定の項目には、データ種別およびデータ値に対して、プッシュ型デバイスをトリガデバイスの決定処理の対象とするか否か（トリガの候補とするか否か）を示す情報が登録される。
【０１６２】
例えば、トリガ決定制御テーブル１１６には、デバイス種別が“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｎ”およびトリガ決定が“Ｙｅｓ”という情報が登録される。
【０１６３】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から通知された内容がデータ種別“ｓｔａｔｕｓ”およびデータ値“ｏｎ”の場合、空調機４００からの通知内容に基づくトリガデバイスの決定処理を行う（“Ｙｅｓ”）ことを示す。
【０１６４】
例えば、トリガ決定制御テーブル１１６には、デバイス種別が“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｆｆ”およびトリガ決定が“Ｎｏ”という情報が登録される。
【０１６５】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から通知された内容がデータ種別“ｓｔａｔｕｓ”およびデータ値“ｏｆｆ”の場合、空調機４００からの通知内容に基づくトリガデバイスの決定処理を行わない（“Ｎｏ”）ことを示す。
【０１６６】
次に、第４の実施の形態の準備処理の手順を説明する（運用処理の手順については、第２の実施の形態と同様である）。第４の実施の形態の準備処理の手順は、図１８で説明した第２の実施の形態の準備処理の手順と一部が異なる。
【０１６７】
図２５は、第４の実施の形態の準備処理例を示すフローチャートである。以下、図２５に示す処理をステップ番号に沿って説明する。第４の実施の形態では、図１８の手順に対して、ステップＳ２２の次にステップＳ２２ｄを実行する点が異なる。そこで、以下ではステップＳ２２ｄを説明し、他のステップの説明を省略する。
【０１６８】
（Ｓ２２ｄ）決定部１４０は、トリガ決定制御テーブル１１６のトリガ決定の項目を参照し、ステップＳ２１で通知を受け付けたプッシュ型デバイスのデバイスＩＤ、データ種別およびデータ値に基づいて、トリガデバイスを決定するか否かを判定する。決定する場合、処理をステップＳ２３に進める。決定しない場合、処理をステップＳ２１に進める。
【０１６９】
このように、決定部１４０は、トリガ決定制御テーブル１１６に登録された内容に基づいて、特定のプッシュ型デバイスからの特定の種別のデータ値については、トリガデバイスの決定を行わないよう制御することができる。これにより、運用において監視の必要性のないデータをオンデマンド型デバイスから取得せずに済む。すなわち、オンデマンド型デバイスから余計なデータが取得されることを抑制でき、データの取得を一層効率化できる。
【０１７０】
［第５の実施の形態］
次に、第５の実施の形態を説明する。前述の第２の実施の形態との相違する事項を主に説明し、共通する事項の説明を省略する。
【０１７１】
第５の実施の形態では、トリガデバイスの決定後であっても、オンデマンド型デバイスからのデータの取得要否を事後的に選択可能にする機能を提供する。例えば、当初は、トリガデバイスからの通知に応じてデータを取得していたオンデマンド型デバイスであっても、運用中に、定期的なデータ取得に切り替えるなど、プッシュ型デバイスをトリガとしたデータ取得が不要になることもあるからである。
【０１７２】
ここで、第５の実施の形態の情報処理システムは、図２で示した第２の実施の形態の情報処理システムと同様である。また、第５の実施の形態の情報処理システムに含まれる装置や機能は、図３〜９で示した第２の実施の形態の装置や機能と同様である。そこで、第５の実施の形態では、第２の実施の形態と同じ符号、名称を用いる。また、第５の実施の形態では、第２の実施の形態で例示したテーブルに加えて、オンデマンド取得制御テーブルを更に用いる。
【０１７３】
図２６は、第５の実施の形態のオンデマンド取得制御テーブルの例を示す図である。オンデマンド取得制御テーブル１１７は、記憶部１１０に格納される。オンデマンド取得制御テーブル１１７は、デバイス種別、データ種別、データ値およびオンデマンド取得の項目を含む。
【０１７４】
デバイス種別の項目には、プッシュ型デバイスを示す情報が登録される。データ種別の項目には、データの種別を示す情報が登録される。データ値の項目には、データ種別の項目に対応するデータ値が登録される。オンデマンド取得の項目には、オンデマンド型デバイスへのデータ取得要求の要否を示す情報が登録される。
【０１７５】
例えば、オンデマンド取得制御テーブル１１７には、デバイス種別が“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｎ”およびオンデマンド取得が“Ｙｅｓ”という情報が登録される。
【０１７６】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から通知されたデータ種別“ｓｔａｔｕｓ”およびデータ値“ｏｎ”の場合、データの取得要求をオンデマンド型デバイスに送信する（“Ｙｅｓ”）ことを示す。
【０１７７】
例えば、オンデマンド取得制御テーブル１１７には、デバイス種別が“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”、データ種別が“ｓｔａｔｕｓ”、データ値が“ｏｆｆ”およびオンデマンド取得が“Ｎｏ”という情報が登録される。
【０１７８】
これは、空調機４００（“ａｉｒｃｏｎｄｉｔｉｏｎｅｒ”）から通知されたデータ種別“ｓｔａｔｕｓ”およびデータ値“ｏｆｆ”の場合、空調機４００が何れかのオンデマンド型デバイスのトリガデバイスであっても、データの取得要求をオンデマンド型デバイスに送信しない（“Ｎｏ”）ことを示す。
【０１７９】
次に、第５の実施の形態の運用処理の手順を説明する（準備処理の手順については、第２の実施の形態と同様である）。第５の実施の形態の運用処理の手順は、図２０で説明した第２の実施の形態の運用処理の手順と一部が異なる。
【０１８０】
図２７は、第５の実施の形態の運用処理例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。第５の実施の形態では、図２０の手順に対し、ステップＳ４３の次にステップＳ４３ａを実行する点が異なる。そこで、ステップＳ４３ａを説明し、他のステップの説明を省略する。
【０１８１】
（Ｓ４３ａ）データ取得部１３０は、オンデマンド取得制御テーブル１１７のオンデマンド取得を参照し、ステップＳ４１で通知を受けたプッシュ型デバイスのデバイスＩＤ、データ種別およびデータ値に基づいて、オンデマンド型デバイスからデータ値を取得するか否かを判定する。取得する場合、処理をステップＳ４４に進める。取得しない場合、処理をステップＳ４１に進める。
【０１８２】
このように、データ取得部１３０は、オンデマンド取得制御テーブル１１７に登録された内容に基づいて、データの取得要求をオンデマンド型デバイスに送信しないよう制御する。
【０１８３】
第５の実施の形態によれば、あるプッシュ型デバイスがトリガデバイスとして決定されていても、当該プッシュ型デバイスの通知内容に応じて、オンデマンド型デバイスからのデータ取得を抑制できる。これにより、運用において監視の必要性のない（監視の必要性がなくなった）データをオンデマンド型デバイスから取得せずに済む。すなわち、オンデマンド型デバイスから余計なデータが取得されることを抑制でき、データの取得を一層効率化できる。
【０１８４】
なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２〜第５の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。
【０１８５】
例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータ（例えば、サーバ６００）に格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えばサーバ６００から受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【０１８６】
以上の第１〜第５の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１）  コンピュータに、
複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、
前記第２のデバイスからデータを取得するタイミングを、前記第１のデバイスからデータを取得してから前記時間が経過した後と決定する、
処理を実行させるデータ取得プログラム。
【０１８７】
（付記２）  前記判定では、前記第１のデバイスからデータを取得した時刻と前記第２のデバイスから変化後のデータを取得した時刻との時間差に応じた統計量に基づいて、前記時間を判定する、付記１記載のデータ取得プログラム。
【０１８８】
（付記３）  前記判定では、前記時間差の分散が閾値以下である場合に、前記時間を前記時間差の平均値とする、付記１または２記載のデータ取得プログラム。
（付記４）  前記判定では、前記第１のデバイスからデータを取得した時点以後の所定期間内にデータを取得した他のデバイスを前記判定の対象とする、付記１乃至３の何れか１つに記載のデータ取得プログラム。
【０１８９】
（付記５）  前記判定では、前記第１のデバイスから取得したデータの種別毎に前記第２のデバイスと前記時間とを判定し、
前記決定では、前記第１のデバイスから取得されるデータの種別毎に前記タイミングを決定する、付記１乃至４の何れか１つに記載のデータ取得プログラム。
【０１９０】
（付記６）  前記判定では、前記第１のデバイスが所定の種類のデバイスである場合、前記第１のデバイスからデータを取得すると、複数の他のデバイスにデータの取得要求を送信して前記複数の他のデバイスからデータを取得し、前記第２のデバイスを判定する、付記１乃至５の何れか１つに記載のデータ取得プログラム。
【０１９１】
（付記７）  前記判定では、前記第１のデバイスから取得されるデータの種別に応じて、前記第１のデバイスからの当該データの取得を、他のデバイスからデータを取得するためのトリガの候補とするか否かを選択する、付記１乃至６の何れか１つに記載のデータ取得プログラム。
【０１９２】
（付記８）  前記決定では、前記第１のデバイスから取得されるデータの種別に応じて、前記タイミングにおいて前記第２のデバイスからデータを取得するか否かを更に選択する、付記１乃至６の何れか１つに記載のデータ取得プログラム。
【０１９３】
（付記９）  前記第１のデバイスは、前記コンピュータから要求されなくても、前記コンピュータにデータを送信するデバイスである、付記１乃至８の何れか１つに記載のデータ取得プログラム。
【０１９４】
（付記１０）  複数のデバイスから取得したデータの履歴を記憶する記憶部と、
前記データの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、前記第２のデバイスからデータを取得するタイミングを、前記第１のデバイスからデータを取得してから前記時間が経過した後と決定する演算部と、
を有する情報処理装置。
【０１９５】
（付記１１）  コンピュータが、
複数のデバイスから取得したデータの履歴の情報に基づいて、第１のデバイスからデータを取得した後に、取得されるデータに変化がある第２のデバイスと変化までの時間とを判定し、
前記第２のデバイスからデータを取得するタイミングを、前記第１のデバイスからデータを取得してから前記時間が経過した後と決定する、
データ取得方法。
【符号の説明】
【０１９６】
１  情報処理装置
１ａ  記憶部
１ｂ  演算部
２  第１のデバイス
３  第２のデバイス
【図１】
0006515596.tif 000002
【図２】
0006515596.tif 000003
【図３】
0006515596.tif 000004
【図４】
0006515596.tif 000005
【図５】
0006515596.tif 000006
【図６】
0006515596.tif 000007
【図７】
0006515596.tif 000008
【図８】
0006515596.tif 000009
【図９】
0006515596.tif 000010
【図１０】
0006515596.tif 000011
【図１１】
0006515596.tif 000012
【図１２】
0006515596.tif 000013
【図１３】
0006515596.tif 000014
【図１４】
0006515596.tif 000015
【図１５】
0006515596.tif 000016
【図１６】
0006515596.tif 000017
【図１７】
0006515596.tif 000018
【図１８】
0006515596.tif 000019
【図１９】
0006515596.tif 000020
【図２０】
0006515596.tif 000021
【図２１】
0006515596.tif 000022
【図２２】
0006515596.tif 000023
【図２３】
0006515596.tif 000024
【図２４】
0006515596.tif 000025
【図２５】
0006515596.tif 000026
【図２６】
0006515596.tif 000027
【図２７】
0006515596.tif 000028