JP2016525735A - リソース制約付きデバイスから情報をキャッシュするネットワークシステム、照明システム、及び方法 - Google Patents

Abstract

リソース制約付きデバイスから情報をキャッシュするためのネットワークシステム１００及び方法が提供される。リソース制約付きデバイス１１０は、リソース制約付きデバイス１１０のステータスに関する発生されたデータｄを、制御可能デバイス１５０を制御するためにネットワーク１３０を介して制御可能デバイス１５０に提供する。制御可能デバイス１５０は、データｄの受信に応答して、動作コンポーネント１５４の動作を制御する。制御可能デバイス１５０はまた、キャッシュメモリ１５６を備え、そこに、受信されたデータｄが記憶され、制御可能デバイス１５０は、記憶されているデータｄを求めるリクエストｒをリクエスト元デバイス１７０から受信するように構成され、且つ、記憶されているデータｄをリクエスト元デバイス１７０に提供するように構成される。ネットワークシステム１００は、リソース制約付きデバイス１１０にとってよりトランスペアレントなデータｄのためのキャッシュソリューションを提供する。

Description

本発明は、少なくとも１つのリソース制約付きデバイスを有するネットワークシステムに関し、データキャッシュソリューションを含む。更に、本発明は、ネットワークシステムを備える照明システムに関する。更に、本発明は、リソース制約付きデバイスから情報をキャッシュする方法に関する。

リソース制約付きデバイスは、自動化及び制御ネットワークにおいて、例えばバッテリ駆動式若しくは更にはエネルギー収集用の制御装置又はセンサとして広く使用されている。利用可能な処理及び送受信時間の制限をもたらす電力等に関するそれらのデバイスの制限により、リソース制約付きデバイスは、システム内でそれらの役割を果たすために、特定の制御ソリューションを必要とする。

そのような制約付きデバイスを取り扱うための専用プロトコル、例えばEnOcean社によって提供されるソリューションが存在する。また、ZigBeeによって開発されているGreen Power機能等、標準制御技術に組み込まれているソリューションも存在する。

かなりの期間にわたって非活動状態の無線機能を有する（従って、各期間中に無線フレーム受信が可能でない）リソース制約付きデバイスは、「スリーピー（sleepy）」デバイスと呼ばれる。そのような期間中、デバイスは、「スリープ中（sleep）」又は「休止中（asleep）」であると言われる。

典型的には、あるデバイスが、情報を取得するためにリソース制約付きデバイスにリクエストを送信するとき、メッセージは、リソース制約付きデバイスが「スリープ中」である期間中には回答されない。従って、リクエスト元デバイスは、リクエストされた情報を含む回答がリクエスト元デバイスに達する前に、数回のリクエストを送信しなければならないことがある。処理及びネットワークリソースの浪費をもたらし、リソース制約付きデバイスが他のデバイスと通信するネットワーク内の輻輳をもたらすことさえあり得るので、これは望ましくない。

米国特許出願公開第２０１２／０１５１０２８号は、この問題のための解決策を提供する。引用される特許出願のネットワークにおいて、「制約付きデバイス」（これは、定期的に「スリープ」モードにあるデバイスである）は、それらのスリープ及びウェークアップスケジュールを、ネットワーク内の無制約デバイス、例えば低電力無線ネットワークのエッジルータに送信し、無制約デバイスは、このスリープ及びアウェークスケジュールを様々な目的で使用することができる。例えば、リクエスト元デバイスが制約付きデバイスにメッセージを送信するとき、無制約デバイスは、リクエストを一時的にキャッシュし、スケジュールに従って制約付きデバイスがウェークアップされるべき瞬間にリクエストを転送することができる。この特定のソリューションは、制約付きデバイスがウェークアップする瞬間までリクエスト元デバイスが回答を依然として待機しなければならないという欠点を有する。

米国特許出願公開第２００８／０１２０４１４号は、リソース制約付きデバイスがそれらのデータ値（例えば、それらのセンサによって測定された値）をアクセスポイントに提供するソリューションを提供し、このアクセスポイントは、無制約デバイスであり、リソース制約付きデバイス及び別のネットワーク（例えば有線ネットワーク）と交信する。アクセスポイントは、受信されたデータ値を処理して、処理されたデータを記憶する。別のデバイスは、処理されたデータをアクセスポイントにリクエストすることができる。このソリューションでは、アクセスポイントは、リソース制約付きデバイスによって提供されたデータに基づくデータ用の一種のキャッシュを形成する。そのようなソリューションの主な目的は、リソース制約付きデバイスが、できるだけ多くスリープモードに入ることによってできるだけ電力を節約すると同時に、別のデバイスが、リクエストされたデータをできるだけすぐに提供するように利用可能であるようにすることである。残念ながら、このソリューションは、リソース制約付きデバイス及びリクエスト元デバイスにトランスペアレントでない。どちらのデバイスも、アクセスポイント（キャッシュ）のアドレスを知る必要があり、従って、それらは、アクセスポイントのアドレスを学習しなければならない。更なる欠点は、アクセスポイントが、比較的大きい通信帯域幅を有する強力なデバイスである必要があることである。アクセスポイントは、集中化されたユニットであり、これは、多くのリソース制約付きデバイスからデータを受信し、且つ、多くのリクエスト元デバイスからのリクエストに回答しなければならない。

本発明の目的は、比較的良いエネルギー効率で動作するリソース制約付きデバイスのデータをキャッシュするためのよりトランスペアレントなキャッシュソリューションを提供することである。

本発明の第１の態様は、リソース制約付きデバイスから情報をキャッシュするためのネットワークシステムを提供する。本発明の第２の態様は、照明システムを提供する。本発明の第３の態様は、ネットワークシステムにおいてリソース制約付きデバイスから情報をキャッシュする方法を提供する。有利な実施形態は、従属請求項で定義される。

本発明の第１の態様によるネットワークシステムは、制御可能デバイスと、リソース制約付きデバイスと、ネットワークとを備える。制御可能デバイスは、第１の通信インターフェースと、受信されたデータに基づいて特定のアクションを行うための動作コンポーネントとを備える。制御可能デバイスは、第１の通信インターフェースを介してデータを受信し、受信されたデータに応答して動作コンポーネントの動作を適合させるように構成される。リソース制約付きデバイスは、第２の通信インターフェースと、データ発生器とを備える。データ発生器は、リソース制約付きデバイスのステータスに関するデータを発生する。リソース制約付きデバイスは、制御可能デバイスの動作を制御するために第２の通信インターフェースを介して制御可能デバイスにデータを送信するように構成される。ネットワークは、制御可能デバイスとリソース制約付きデバイスとを相互接続し、それぞれの第１の通信インターフェースと第２の通信インターフェースとの間でデータを送信する。制御可能デバイスは、キャッシュメモリを更に備え、そこに、リソース制約付きデバイスから受信されたデータが記憶される。制御可能デバイスは、キャッシュメモリに記憶されているデータを求めるリクエストをリクエスト元デバイスから受信するように構成され、そのようなリクエストの受信に応答してリクエスト元デバイスにデータを提供する。

ネットワークシステムは、特に、制御可能デバイスを制御するためにリソース制約付きデバイスが使用されるネットワークに関する。リソース制約付きデバイスは、センサ又は制御装置、例えばスイッチ又はリモートコントロール（リモコン）でよく、制御可能デバイスは、感知された情報、又はリソース制約付きデバイスのユーザ操作可能な制御要素での制御入力に応答して、特定の操作を実施しなければならない。典型的な使用例は、発光器によって照明される空間内での人の存在を在室センサが感知すると発光器が発光を開始し始める照明システムである。別の典型的な使用例は、発光器によって照明される空間内でユーザによってスイッチが操作されるときに発光器がその発光を開始／停止／減光しなければならない照明システムである。制御可能デバイスは、リソースに関して特には制限されず、（無制限の）エネルギー源に接続され得て、一方、リソース制約付きデバイスは、例えば利用可能なエネルギーの量に関して制限される。

そのようなネットワークシステムでは、リソース制約付きデバイスは、特定のプロトコルに従って、制御可能デバイスの動作を制御するために制御可能デバイスにそのステータスに関するデータ（例えば、センサデータ、又は入力手段を介して受信されるデータ）を送信する。制御動作を実施するために、制御可能デバイスとリソース制約付きデバイスとの少なくとも一方は、どのデバイスが制御されるべきか、又はどのデバイスが制御データを提供するかを学習する。この知識が、それらのデバイスの少なくとも一方に（ネットワーク上で及び／又はリソース制約付きデバイスによって使用される特定のデータ送信プロトコルと併せて）存在すると、リソース制約付きデバイスは、制御可能デバイスを制御することが可能である。特定の（リクエスト元）デバイスが、リソース制約付きデバイスのステータスに関するデータをリクエストすることを望むこともあり得る。例えば、建造物管理システムにおいて、中央サーバは、監視中の特定の空間内で在室センサが感知している状況について、その在室センサから知ることを望むことがある。

本発明によれば、制御可能デバイスはまた、リソース制約付きデバイスによって提供されたデータをキャッシュメモリに記憶し、制御可能デバイスは、このデータに関するリクエストに回答するように適合される。従って、リソース制約付きデバイスは、キャッシュの存在に関する知識を有する必要はなく、リソース制約付きデバイスは、その構成の目的のアクションのみを行う。即ち、制御しなければならない制御可能デバイスにデータを送信する。従って、リソース制約付きデバイスに関して、キャッシュの使用は、完全にトランスペアレントである。例えば、リクエスト元デバイスが、特定のデータをリクエストするためにグループアドレスを使用すること、及び制御可能デバイスが、グループアドレスにアドレス指定されたメッセージを処理するデバイスであることもあり得る。その状況では、制御可能デバイスは、キャッシュメモリに記憶されているデータに基づいて、リクエストされたデータをリクエスト元デバイスに送信する。従って、この特定の例では、ソリューションは、リクエスト元デバイスにとっても完全にトランスペアレントである。なぜなら、リクエスト元デバイスは、制御可能デバイスにあるキャッシュメモリの特定の知識を有することを必要とされないからである。トランスペアレントなソリューションをリクエスト元デバイスに提供する他の例は、本明細書で以下に論じられる。

キャッシュメモリが、制御可能デバイスのより大きなメモリユニットの一部であり得ることに留意されたい。従って、キャッシュメモリと、制御可能デバイス内の他のメモリとの物理的な境界は検出するのが難しいことがあり、唯一重要なのは、制御可能デバイスが、リソース制約付きデバイスから受信されたデータを記憶し、このデータを求めるリクエストが制御可能デバイスに達するときにこのデータを提供することが可能であることである。

本発明は、複数の制御可能デバイス及び複数のリソース制約付きデバイスを有するネットワークシステムにも適用可能であることに留意されたい。そのようなネットワークシステムでは、リソース制約付きデバイスと制御可能デバイスとの様々な対が利用可能であり得、又は、リソース制約付きデバイスと制御可能デバイスとの様々なグループが存在し得る。本発明では、リソース制約付きデバイスは、１つ又は複数の制御可能デバイスを制御することができる。リソース制約付きデバイスは、１つ若しくは複数の制御可能デバイスの個々のアドレスに個別のメッセージを送信することによって、それらの制御可能デバイスにデータを送信することができ、又はリソース制約付きデバイスは、１つ若しくは複数の制御可能デバイスが属する１グループのデバイスにアドレス指定された単一のメッセージとしてデータを送信することができる。本発明では、提供されるキャッシュソリューションは、分散型のキャッシュソリューションである。なぜなら、（制御目的のために）特定のリソース制約付きデバイスから特定のデータを受信する制御可能デバイスのみが、受信されたデータをそれらのキャッシュメモリに記憶するからであり、全てのリソース制約付きデバイスのデータが記憶されている中央キャッシュは存在しないからである。それにより、そのような中央キャッシュでネットワーク過負荷が生じ得ることも防止される。リソース制約付きデバイスと制御可能デバイスの対、又はリソース制約付きデバイスと制御可能デバイスの様々なグループがネットワークシステム内に存在する場合、特定のリソース制約付きデバイスによって提供されるデータは、その特定のリソース制約付きデバイスがデータを送信する送信先の対又はグループの制御可能デバイスによってのみキャッシュされる。

ネットワークシステムのネットワークは、無線ネットワークであってもよい。無線ネットワークのプロトコルは、リソース（電力等）に関して制約されるデバイス間の通信のために設計され得る。そのようなネットワーク及びそのようなネットワークプロトコルの例は、ZigBee、ZigBeeのGreen Power機能、６ＬｏＷＰＡＮ（Low power Wireless Personal Area Networkを介するＩＰｖ６）、ＣｏＡＰ（Constrained Application Protocol：制約アプリケーションプロトコル）、Bluetooth（登録商標） Low Energy、DECT Ultra Low Energy、又はそれらの（要素の）組合せである。ネットワークが、無線ネットワークに必ずしも限定されないことに留意されたい。リソース制約付きデバイスを制御可能デバイスに接続する有線ネットワークも、本明細書で使用される用語「ネットワーク」の範囲内に入る。更に、用語「リソース制約付きデバイス」ではなく、「リソース制限付きデバイス」も使用される。

本発明は、キャッシュメモリを埋めるだけの通信がなくされ得るという追加の利点を有することに留意されたい。本発明では、リソース制約付きデバイスによって制御可能デバイスに既に送信されたデータは、キャッシュメモリに記憶されている。

任意選択的に、リソース制約付きデバイスのステータスに関するデータは、ｉ）リソース制約付きデバイスのセンサの情報と、ｉｉ）リソース制約付きデバイスの制御要素の情報との少なくとも一方に基づく。センサの例は、温度センサ、湿度センサ、光強度及び／又は光の色を感知するための光センサ、在室／移動センサ、超音波レンジファインダ、サウンドレベルセンサ、空気圧センサ、運動センサ、加速度センサ、流量センサ、濃度センサ（例えばＣＯ_２センサ）、電力／電圧／電流メータ、ドア／窓開放センサ、振動センサ等である。制御要素の例は、オン／オフスイッチ、選択スイッチ（複数の離散又は連続値の１つの選択）、（小型）キーボード、減光スイッチ、スライダ、回転コントローラ、タッチパネル、パニックボタン等である。一実施形態では、制御要素はユーザ操作可能である。リソース制約付きデバイスは、自律的に動作することができ、又はユーザによって、明示的な制御アクションで若しくは暗黙的に（例えば窓を開放したときや窓開放センサをトリガしたときに）作動され得る。リソース制約付きデバイスは、固定位置に設置され得て、例えば壁／天井に取り付けられ得て、又は例えばリモートコントロールやキーボードのようにポータブルでもよい。リソース制約付きデバイスを備える多くのネットワークシステムにおいて、リソース制約付きデバイスは、外部電源のない場所に提供されるセンサであり、又は追加の電源を有さない入力デバイスである。感知される情報、及びユーザによって提供される入力は、しばしば、他のデバイス、即ち制御可能デバイスを制御するデータである。

センサと制御要素との組合せも提供され得る。例えば、制御可能デバイスを制御するために（例えば、光源をオン又はオフに切り替えるために）床の特定の位置でユーザがステップを踏まなければならないとき、床下に提供される圧力センサも制御要素として構成され得る。データとして制御可能デバイスに送信される前に、センサ又は制御要素の情報が処理され得る。例えば、センサが（例えばロボットアーム）の移動を感知するとき、カウンタが追加され得て移動をカウントし、制御可能デバイスに送信されるデータは、カウントされた値である。代替として、「処理」は、センサ又は制御要素によって取得される情報に対して機能を施すことである。

別の実施形態では、リソース制約付きデバイスのステータスに関するデータは、低バッテリステータスデータ又はエラーコードデータでよく、このデータは、制御可能デバイスにおいて、可聴又は可視信号発生コンポーネントを制御して可聴又は可視信号を発生させ、この信号が、リソース制約付きデバイスのバッテリがほぼ空であること、又はリソース制約付きデバイスでエラーが生じたことをユーザに知らせる。

任意選択的に、ネットワークシステムは、更なる通信インターフェースと、受信されたデータに基づいて特定のアクションを行うための更なる動作コンポーネントとを備える更なる制御可能デバイスを備え、更なる制御可能デバイスは、データをリソース制約付きデバイスから受信するように、及び受信されたデータに応答して更なる動作コンポーネントの動作を適合させるように構成される。リソース制約付きデバイスは、通信デバイスを介して更なる制御可能デバイスにもデータを送信するように構成される。更なる制御可能デバイスは、リソース制約付きデバイスから受信されたデータを記憶するための更なるキャッシュメモリを備え、更なる制御可能デバイスは、キャッシュメモリに記憶されているデータを求めるリクエストをリクエスト元デバイスから受信することを予想して、リソース制約付きデバイスから受信されたデータをキャッシュメモリに記憶し、データをリクエスト元デバイスに提供するように構成される。

この特定の任意選択的な実施形態では、リソース制約付きデバイスは、少なくとも２つの制御可能デバイスを制御する。例えば、照明システムにおいて、在室センサは、特定の空間内の複数の光源を制御することができる。リソース制約付きデバイスは、各制御可能デバイスを個別にアドレス指定することができる。しかし、リソース制約付きデバイスでの通信及び／又はメンテナンスの負担を軽減するために、本発明によるネットワークシステムにおいてしばしばデバイスのグループが形成され、リソース制約付きデバイスは、グループアドレスを使用してそのデータをグループアドレスに送信し、それにより、グループの制御可能デバイスは、受信されたデータに従ってそれらの動作を適合させる。制御可能デバイスと更なる制御可能デバイスは、それらのキャッシュメモリにデータを記憶し、どちらも、データを求めるリクエストを受信したときにデータを提供することができる。これは、本発明のキャッシュソリューションにおける少なくとも幾らかの冗長性を生み出す。制御可能デバイス及び更なる制御可能デバイスが、グループアドレスでアドレス指定可能なグループのメンバであるとき、リクエスト元デバイスは、グループアドレスを使用してデータをリクエストすることができ、その結果、制御可能デバイスからの回答及び更なる制御可能デバイスからの回答が得られる。

任意選択的に、制御可能デバイス、リソース制約付きデバイス、及び更なる制御可能デバイスは、ネットワークアドレスを提供され、それらのネットワークアドレスにアドレス指定されたメッセージをネットワークを介して受信するように構成される。ネットワークシステムは、リソース制約付きデバイスの名前又は識別子と、リソース制約付きデバイスから受信されたデータを記憶するためのキャッシュメモリを有する少なくとも１つの制御可能デバイスのネットワークアドレスとの間のマッピングを記憶するためのアドレス解決機能を備える。アドレス解決機能は、リソース制約付きデバイスの名前又は識別子に結合されたネットワークアドレスの提供を求めるリクエストに応答してネットワークアドレスを提供するように構成される。この任意選択的な実施形態は、ネットワークシステムのキャッシュソリューションを、リクエスト元デバイスにとってできるだけトランスペアレントにするための手段を提供する。多くのネットワークにおいて、多くの異なるプロトコルに従って、ネットワークに接続されたデバイスは、ネットワーク内での名前、又は識別子、及びネットワークアドレスを有することがあり、様々なソリューションが、この名前／識別子をネットワークアドレスにマッピングするために提供される。この任意選択的な実施形態では、リクエスト元デバイスが、リソース制約付きデバイスのネットワークアドレスを見つけることを試みるとき、アドレス解決機能は、リクエストされたデータをそのメモリキャッシュに記憶している又は少なくとも記憶している可能性が高い制御可能デバイスのネットワークアドレスを自動的に提供する。従って、リクエスト元デバイスは、リソース制約付きデバイスのデータを求めるリクエストを、このデータを提供することが可能なデバイスに自動的に送信する。

リソース制約付きデバイスの名前又は識別子と、制御可能デバイスのネットワークアドレスとの間のマッピングが構築されなければならない。特定のリソース制約付きデバイスと、特定のリソース制約付きデバイスに関する情報を記憶している特定の制御可能デバイスのネットワークアドレスとの間のマッピングをアドレス解決機能に提供する特定のプロトコルが使用され得る。例えば、制御可能デバイスが特定のリソース制約付きデバイスに関する情報を記憶するとすぐに、制御可能デバイスは、マッピング／解決情報を含むメッセージをアドレス解決機能に送信することができる。アドレス解決機能は、ドメインネームサーバ（ＤＮＳ）によって実現される機能と比較され得るが、相違点は、リソース制約付きデバイスの名前を制御可能デバイスのアドレスにマッピングする特定の記録が提供されることである。

デバイスのネットワークアドレスの例は、ＩＰネットワークでは、それぞれのデバイスのＩＰｖ４又はＩＰｖ６アドレスである。ＩＰｖ６アドレスは、媒体アクセス制御（ＭＡＣ）アドレスに基づくものでよい。他のネットワークシステムでは、ネットワークアドレスは、ＭＡＣアドレス自体でよい。そのようなアドレスに関して、ＭＡＣアドレスは、例えばＩＥＥＥ標準ＭＡＣ−４８、ＥＵＩ−４８、及びＥＵＩ−６４の１つによるアドレスである。

任意選択的に、制御可能デバイス、リソース制約付きデバイス、及び更なる制御可能デバイスは、ネットワークアドレス又は名前若しくは識別子を提供され、ネットワークアドレス又は名前若しくは識別子にアドレス指定されたメッセージを受信するように構成される。ネットワークシステムは、リソース制約付きデバイスによって提供される特定のリソースと、リソース制約付きデバイスから受信されたデータを記憶するためのキャッシュメモリを有する少なくとも１つの制御可能デバイスのネットワークアドレス、名前、又は識別子との間のマッピングを記憶するためのリソースディレクトリ機能を備える。リソースディレクトリ機能は、リソース制約付きデバイスによって提供される特定のリソースに関するネットワークアドレス、名前、又は識別子の提供を求めるリクエストの受信に応答して、ネットワークアドレス、名前、又は識別子を提供するように構成される。この実施形態は、キャッシュを有する少なくとも１つの制御可能デバイスに向かうマッピングが自動的に提供されるので、リクエスト元デバイスに対してトランスペアレント性を提供する。用語「リソース」は、このコンテキストでは、デバイスの「機能」又は例えば「能力」を識別するために使用される。例えば、リクエスト元デバイスは、フロア１の部屋５の占有に関する情報を提供するデバイスのネットワークアドレス、名前、又は識別子を尋ねることがある。リソースディレクトリ機能は、その後、この情報をキャッシュに記憶している（可能性が高い）制御可能デバイスのネットワークアドレス、名前、又は識別子を提供する。

任意選択的に、ネットワークアドレスは、個々のネットワークアドレス又はネットワークグループアドレスであり、個々のネットワークアドレスは、ネットワークシステムの単一のデバイスを一意的に識別し、ネットワークグループアドレスは、１グループのデバイスに属するアドレスである。又は、名前が、制御可能デバイスの個々の名前若しくはグループ名であり、個々の名前が、ネットワークシステムの単一のデバイスを一意的に識別し、グループ名が、１グループのデバイスに属する。ネットワークデバイスのグループへのブロードキャスト又はマルチキャストが、グループアドレス又はグループ名の範囲内に入ることに留意されたい。

任意選択的に、ネットワークがアドレス解決機能を備えるとき、アドレス解決機能は、ネットワークシステムのアドレス解決デバイスによって提供され、アドレス解決デバイスは、アドレス解決機能の諸機能を実施するように構成され、又はアドレス解決機能は、ネットワークシステムのデバイスに分散され、ネットワークシステムのデバイスは、互いに協働してアドレス解決機能を提供するように構成される。例えば、ドメインネームサーバ（ＤＮＳ）は、単一のサーバで具現化され、又はｘｍＤＮＳ又はｍＤＮＳ等、分散型のＤＮＳプロトコルが使用される。前述のように、本発明のアドレス解決機能と既知のＤＮＳソリューションとの相違点は、制御可能デバイスに記憶されているリソース制約付きデバイスのデータにリクエスト元デバイスがトランスペアレントにアクセスするために必要とされる特定のマッピングを含む特定の記録の使用である。

任意選択的に、ネットワークがリソースディレクトリ機能を備えるとき、リソースディレクトリ機能は、ネットワークシステムのリソースディレクトリデバイスによって提供され、リソースディレクトリデバイスは、リソースディレクトリ機能の諸機能を実施するように構成され、又はリソースディレクトリ機能は、ネットワークシステムのデバイスに分散され、ネットワークシステムのデバイスは、互いに協働してリソースディレクトリ機能を提供するように構成される。

任意選択的に、リソース制約付きデバイスは、通信インターフェースを介して特定の制御可能デバイスに更なるデータを送信する。更なるデータはまた、リソース制約付きデバイスのステータスに関し、制御可能デバイスのアクションを直接は制御しない。制御可能デバイスは、更なるデータをキャッシュに記憶し、更なるデータを求めるリクエストが制御可能デバイスによって受信されたときに、更なるデータをリクエスト元デバイスに提供するように構成される。特定のプロトコル及び／又はネットワーク通信技術では、更なるデータは、他のデバイスに送信されるデータパケットとして常に送信される。そのような状況では、リクエスト元デバイスがこの情報も取得することができるように、制御可能デバイスのキャッシュメモリにもこの情報を記憶することが有利である。この任意選択的な実施形態のソリューションも、リソース制約付きデバイスにとってトランスペアレントである。なぜなら、リソース制約付きデバイスは、（例えばプロトコルによって規定される）他の目的でこの情報を既に送信しており、リソース制約付きデバイスは、更なるデータのキャッシュの知識を有さないからである。

任意選択的に、更なるデータは以下のものの１つを含む。ｉ）リソース制約付きデバイスの識別子、ｉｉ）リソース制約付きデバイスの能力、ｉｉｉ）リソース制約付きデバイスの構成情報、例えば使用されるセキュリティサービス、ｉｖ）鮮度データ、例えば、タイムスタンプ、シーケンス番号、フレームカウンタ、ｖ）リソース制約付きデバイスの電力ステータス、ｖｉ）リソース制約付きデバイスのエネルギーステータス等。エネルギーは、しばしば、リソース制約付きデバイスの最も限られたリソースであり、センサ監視プロトコルにおいて、あらゆるデータパケットで、実際の電力及び／又はエネルギーステータス（例えば、バッテリにどれほどエネルギーが残っているか、又は例えば電力ラインを介する受信電力のステータス）を送信する必要があり得、それにより、センサは、全てのエネルギーが消費される前に交換される、新たなバッテリを受け取る、又は再充電されることがある。そのような更なるデータの他の例は、以下のものである。ｖｉｉ）リソース制約付きデバイスの位置情報、ｖｉｉｉ）１つ又は複数のエラーコード、ｉｘ）１つ又は複数のログエントリ、ｘ）リソース制約付きデバイスのハードウェアに対する物理的侵入の検出フラグ、ｘｉ）製造業者名／タイプ／モデル／シリアル番号、ｘｉｉ）ファームウェアバージョン、ｘｉｉｉ）通信インターフェースからのネットワーク診断情報、ｘｉｖ）通信インターフェースを介して送受信されるパケットの数、ｘｖ）リソース制約付きデバイスのルーティングペアレントの数又はアドレス、ｘｖｉ）リソース制約付きデバイスによって制御される他の制御可能デバイスの数又はアドレス、ｘｖｉｉ）ネットワーク輻輳の尺度、ｘｖｉｉｉ）入力デバイスの全ての入力のステータス、ｘｉｘ）リソース制約付きデバイスの全ての制御要素及び／又はセンサのステータス。

任意選択的に、キャッシュメモリは、リソース制約付きデバイスに提供されなければならない他のデータも記憶するように構成され、制御可能デバイスは、他のデータを受信し、他のデータを後でリソース制約付きデバイスに提供するように構成され、また制御可能デバイスは、他のデータをキャッシュメモリに少なくとも一時的に記憶し、リソース制約付きデバイスが他のデータを受信することが可能であるときに他のデータをリソース制約付きデバイスに送信するように構成される。次いで、データ提供デバイスが、リソース制約付きデバイスに他のデータを提供することを望むとき、この任意選択的な実施形態は、リソース制約付きデバイスによってデータが受信されることを保証するための手段を提供する。データ提供デバイスは、リクエスト元デバイスでよいが、制御可能デバイス及び／又はリソース制約付きデバイスと通信することが可能なネットワーク内の別のデバイスでもよい。前述のように、この実施形態は、アドレス解決機能又はリソース解決機能と組み合わされてよく、それらの機能は、キャッシュメモリを有し、特定のリソース制約付きデバイスと交信する制御可能デバイスのネットワークアドレス又は名前を提供する。語「他の」は、定義により、他のデータが、リソース制約付きデバイスによって制御可能デバイスに提供されるデータ又は更なるデータとは異なる性質のものであることを示すためには使用されないことに留意されたい。用語「他の」は、このコンテキストでは、リクエスト元デバイス（又はデータ提供デバイス）からリソース制約付きデバイスに送信されるデータと、リソース制約付きデバイスから制御可能デバイスに送信されるデータとを区別するために使用される。

任意選択的に、リソース制約付きデバイスの通信インターフェースは、動作モードと非動作モードを有し、リソース制約付きデバイスは、このインターフェースが非動作モードであるときには、通信インターフェースを介して他のデバイスと通信することが可能でなく、このインターフェースが動作モードであるときには、通信インターフェースを介して他のデバイスと通信することが可能である。動作モード及び非動作モードに関するスケジュールは、定期的なスケジュールでよいが、割り込みによって影響を及ぼされることもある。割り込みの一例は、リソース制約付きデバイスが、ユーザによって操作されるスイッチを備えることである。別の割り込みは、所定の値から外れる又は例えば閾値を超える値を検出するセンサからのものであり得る。別の実施形態では、動作モード及び非動作モードに関するスケジュールは、収集されたエネルギーに基づいて、エネルギー収集デバイスで決定され得る。極端な場合でさえ、リソース制約付きデバイスは、通信インターフェースを介する通信中に全ての収集されたエネルギーを使用し、エネルギーの不足により非動作モードに入り、十分なエネルギーを収集された後に動作モードに再び入ることができる。

本発明の第２の態様によれば、光源と、光源制御デバイスと、本発明の第１の態様によるリソース制約付きデバイスから情報をキャッシュするためのネットワークシステムとを備える照明システムが提供される。光源は、制御可能デバイスであり、光源の発光は、光源制御デバイスからのデータの受信に応答して制御される。光源制御デバイスは、リソース制約付きデバイスである。

光源制御デバイスは、例えば、ユーザによって操作され得る入力デバイス、例えばスイッチ、又は光（例えば日光）の強度を感知するセンサ、若しくは在室センサである。しばしば、照明システムにおいて、１つの光源制御デバイスが複数の光源を制御し、従って、光源制御デバイスによって送信されるデータは、複数の光源に送信される。データを複数の光源に送信することは、複数のデータパケットを複数の光源に送信することによって、１グループのデバイスにアドレス指定された単一のデータパケットを送信することによって、又はブロードキャストプロトコルを使用してデータを少なくとも全ての光源に送信することによって実施され得る。

光源制御デバイスのステータスに関するデータをリクエストし得るリクエスト元デバイスは、例えば建造物管理システムであり、これは、部屋が占有されているかどうか、特定の部屋内で光源が依然としてオンであるかどうか、特定の部屋内で日光がどれほど検出されるか、特定の部屋内のリソース制約付きデバイスのバッテリ／電力ステータスがどのような状態か等を知ることを望む。

本発明の第１の態様によるネットワークシステムの他の典型的な使用例は、例えば、リソース制約付きデバイスとして働く煙センサと、制御可能デバイスとして働く可視又は可聴アラーム信号を発生するデバイスとを備えるアラームシステムである。典型的なリクエスト元デバイスは、定期的に煙センサのステータスをリクエストする建造物の中央アラームセンサである。本発明の第１の態様によるネットワークシステムの更なる典型的な使用例は、建造物の空調管理システムにおけるネットワークシステムの使用であり、ここで、リソース制約付きデバイスは、温度、湿度、ＣＯ_２センサ、太陽光センサ、及び／又は風力センサによって形成されてよく、制御可能デバイスは、例えば、加熱デバイス、換気デバイス、空気調和デバイス、窓開放／閉止デバイス、ブラインドを開閉するデバイス等である。建造物管理システムは、建造物内の様々なセンサのステータスを知ることを望むリクエスト元デバイスでよい。

本発明の第３の態様によれば、ネットワークシステムにおいてリソース制約付きデバイスから情報をキャッシュする方法が提供される。ネットワークシステムは、リソース制約付きデバイスと、制御可能デバイスとを備える。方法は、ａ）リソース制約付きデバイスのステータスに関するデータを発生する段階と、ｂ）発生されたデータをリソース制約付きデバイスから制御可能デバイスに送信する段階と、ｃ）発生されたデータを制御可能デバイスで受信する段階と、ｄ）受信されたデータに応答して、制御可能デバイスで特定のアクションを行う段階と、ｅ）受信されたデータを制御可能デバイスのキャッシュメモリに記憶する段階と、ｆ）キャッシュメモリに記憶されているデータを求めるリクエストをリクエスト元デバイスから受信する段階と、ｇ）受信されたリクエストに応答して、キャッシュメモリに記憶されているデータをリクエスト元デバイスに提供する段階とを含む。本発明の第３の態様による方法は、本発明の第１の態様によるネットワークシステムと同じ利益を提供し、システムの対応する実施形態と同様の効果を有する同様の実施形態を有する。

送信段階は、発生されるデータが、例えば制御可能デバイスに明示的にアドレス指定されたデータパケットとして送信される状況、又はそのデータが、例えば制御可能デバイスに明示的にはアドレス指定されないデータパケットとして送信されるが、例えばグループアドレス若しくはマルチキャストが使用され、グループアドレスに送信された若しくはマルチキャストを介して送信されたデータパケットを制御可能デバイスが受信することが可能であるので、データが制御可能デバイスによって受信される状況を含む。

方法の段階の上記の順序は、段階の実際の順序を限定しないことに更に留意されたい。段階が互いに依存している限りにおいてのみ、相互依存性が実際の順序を定める。例えば、特定のアクションを行う段階と、受信されたデータを記憶する段階とは、互いに独立しているので、別の順序で実施され得る。それらは、データを受信する段階にのみ依存する。

任意選択的に、ネットワークシステムのデバイスのサブセットは、ネットワークグループアドレスを提供され、ネットワークシステムは、デバイスのグループのネットワークグループアドレスと、グループのそれぞれのデバイスの名前との間のマッピングを記憶するためのアドレス解決機能を含む。方法は、ｉ）ネットワークシステムの特定のデバイスの特定の名前に関するアドレスを提供するようにアドレス解決機能にリクエストする段階と、ｉｉ）アドレスの提供を求めるリクエストの受信に応答して、特定のデバイスが属するグループのネットワークグループアドレスを提供する段階とを含む。この任意選択的な実施形態の段階は、典型的には、（ｆ）リクエスト元デバイスからリクエストを受信する段階の前に行われ、前に論じられた方法の実施形態の段階ａ）〜ｅ）と並行して行われてもよく、又は、段階ｅ）の後、且つ段階ｆ）の前に行われてもよい。

本発明の別の態様によれば、１つ又は複数の処理装置システムに本発明の前述の態様による方法を実施させるための命令を含む分散型ソフトウェアシステムが提供される。ソフトウェアシステムの様々な部分が、様々な物理的実体に分散された様々な処理装置システムで実行され得る。分散型ソフトウェアシステムは、様々なコンピュータプログラムを備え、それらのコンピュータプログラムの組が、１つ又は複数の処理装置に本発明の前述の態様による方法を実施させるための全ての命令を備える。分散型ソフトウェアシステムは、ハードディスク、フロッピー（登録商標）、メモリ等、適切な記憶媒体に記憶され得る。ソフトウェアシステムは、幾つかのデバイスに分散されて記憶されてもよく、これは、ソフトウェアシステムの幾つかの部分が、他の適切な記憶媒体に物理的に記憶されることを意味する。ソフトウェアは、ワイヤに沿って、若しくは無線で、又はデータネットワーク、例えばインターネットを使用して信号として送信され得る。ソフトウェアは、ダウンロード及び／又はサーバ上での遠隔使用に利用可能にされ得る。

本発明の更に別の態様によれば、本発明は、本発明の第１の態様によるネットワークシステムで使用される制御可能デバイスの機能及び特徴を備える単一の制御可能デバイスに関することがある。単一の制御可能デバイスは、ネットワークシステムの任意選択的な実施形態に従って修正され得る。

本発明のこれら及び他の態様は、本明細書で以下に述べる実施形態を参照すれば明らかになり、解明されよう。

本発明の上記のオプション、実装形態、及び／又は態様の２つ以上が、有用と考えられる任意の様式で組み合わされ得ることは、当業者によって理解されよう。

システム及び方法の上記の修正並びに変形に対応する本明細書で開示されるシステム及び方法の修正並びに変形は、本明細書に基づいて当業者によって実施され得る。

本発明の第１の態様によるネットワークシステムの一実施形態を概略的に示す図である。 ネットワークシステムの別の実施形態を概略的に示す図である。 ネットワークシステムの更なる実施形態を概略的に示す図である。 リソース制約付きデバイスの実施形態を概略的に示す図である。 制御可能デバイスの実施形態を概略的に示す図である。 ネットワークシステム内のリソース制約付きデバイスから情報をキャッシュする方法の一実施形態を概略的に示す図である。 ネットワークシステム内のリソース制約付きデバイスから情報をキャッシュする方法の更なる実施形態を論じるために使用されるネットワークシステムの一実施形態を概略的に示す図である。

異なる図面中で同じ参照番号によって表される要素は、同じ構造的特徴及び同じ機能を有する、又は同じ信号であることに留意されたい。そのような要素の機能及び／又は構造が説明されている場合、詳細な説明において、それらを繰り返し説明する必要はない。

図面は、概略的なものにすぎず、正確な縮尺では描かれていない。特に、見やすくするために、幾つかの寸法が大きく強調されている。

図１に、第１の実施形態が示されている。図１は、本発明の第１の態様によるネットワークシステム１００の一実施形態を概略的に示す。ネットワークシステム１００は、制御可能デバイス１５０と、リソース制約付きデバイス１１０と、ネットワーク１３０とを備える。

制御可能デバイス１５０は、第１の通信インターフェース１５２と、受信されたデータｄに基づいて特定のアクションを行うための動作コンポーネント１５４とを備える。制御可能デバイス１５０は、第１の通信インターフェース１５２を介してデータｄを受信するように構成される。制御可能デバイス１５０は、キャッシュメモリ１５６を更に備え、キャッシュメモリ１５６内で、受信されたデータｄはまた、このキャッシュメモリ１５６の特定のフィールド、レコード、又は位置１５８に記憶される。

リソース制約付きデバイス１１０は、エネルギー／電力であり得るそのリソースの１つに関して制限される。例えば、リソース制約付きデバイス１１０は、例えば、場合によってはエネルギー収集デバイスと組み合わせて、リソース制約付きデバイス１１０に電力を提供するためのバッテリ（図示せず）を備える。リソース制約付きデバイス１１０は、第２の通信インターフェース１１４と、データ発生器１１２とを更に備える。データ発生器１１２は、制御可能デバイス１５０の動作コンポーネント１５４を制御するために制御可能デバイス１５０に送信されなければならないデータｄを発生する。発生されたデータｄは、リソース制約付きデバイス１１０のステータスに基づく。データｄが発生された場合、データｄは、第２の通信インターフェース１１４及びネットワーク１３０を介して制御可能デバイス１５０に送信される（１３２）。

用語「リソース制約付きデバイス１１０のステータス」は、幾つかの実施形態を含む。それらの実施形態を限定せずに、リソース制約付きデバイス１１０のステータスは、リソース制約付きデバイス１１０のセンサ（図示せず）の情報、リソース制約付きデバイス１１０の制御要素（ユーザ制御可能なスイッチ等）の情報、又は例えば、バッテリ若しくは収集ハードウェア（図示せず）のステータスに関係していてよい。制御可能デバイス１５０において、この情報に基づくデータｄは、動作コンポーネント１５４で、例えば、ライト及び／又はオーディオを発生するための手段のオン又はオフへの切替え、特定の動作モードでライト及び／又はオーディオを発生する（例えば、別の色の光を発光する、別の強度の光を発光する、又は特定の可聴又は可視信号を発生若しくは放出する）ためのそのような手段の切替え、アクチュエータの制御、ディスプレイへの情報の表示をもたらす。

図１に、リクエスト元デバイス１７０が描かれており、これもまた通信インターフェース１７２を備え、ネットワーク１３０に接続されたデバイスと通信することが可能である。リクエスト元デバイス１７０は、データｄを求めるリクエストｒを送信することができる。例えば、リクエスト元デバイス１７０は、リソース制約付きデバイス１１０の制御要素又はセンサの現在の（又は既知の最新の）ステータスを知りたいので、リクエストｒを送信する（１３４）ことがある。

制御可能デバイス１５０は、データｄを求めるそのようなリクエストｒを受信することができる。制御可能デバイス１５０は、そのキャッシュメモリ１５６に記憶されているデータｄを有するとき、データｄを求めるリクエストｒの受信に応答して、データｄをリクエスト元デバイス１７０に送信する（１３６）ように構成される。

ネットワーク１３０は、無線ネットワークでよいが、リソース制約付きデバイスと制御可能デバイスとの間の有線ネットワークでもよい。

一実施形態では、リソース制約付きデバイス１１０の少なくとも第２の通信インターフェース１１４は、非動作モード及び動作モードで動作することができる。非動作モードでは、第２の通信インターフェース１１４は、ネットワーク１３０と情報を送受信することが可能でない。動作モードでは、第２の通信インターフェース１１４は、ネットワーク１３０と情報を送受信することが可能である。第２の通信インターフェース１１４は、例えばリソース制約付きデバイスで利用可能なエネルギーの量が絶対最小値に達したときに非動作モードに入るように自動で制御され得て、それにより動作することができなくなり、十分なエネルギーが（例えばエネルギー収集要素から）利用可能になるときに、動作モードに入るように制御され得る。また、リソース制約付きデバイス１１０は、動作及び非動作モードに入るために、スケジュールに従って、又は割り込みに基づいて、第２の通信インターフェース１１４を制御するように構成され得る。このシナリオでは、非動作モードに入るための制御は、例えば、利用可能なエネルギーの量等、制約付きリソースの不要な使用を防止するために行われる。

図２は、ネットワークシステム２００の別の実施形態を概略的に示す。図２のネットワークシステム２００は、図１のネットワークシステム１００と同様であり、その相違点は、「更なるデータ」及び「他のデータ」も、ネットワークシステムの様々なデバイス間で送信されることである。ネットワークシステム２００は、リソース制約付きデバイス２１０と、制御可能デバイス２５０と、ネットワーク１３０とを備える。

また、リソース制約付きデバイス２１０は、データ発生器１１２と、第２の通信インターフェース１１４とを備える。リソース制約付きデバイス２１０は、データｄと共に、更なるデータｆｄも送信する（２３２）ように構成され得る。更なるデータｆｄも、リソース制約付きデバイス２１０のステータスに関係するが、このデータは、制御可能デバイス２５０によって、その動作コンポーネント１５４を制御するために使用されない。

制御可能デバイス２５０も、第１の通信インターフェース１５２と、動作コンポーネント１５４と、キャッシュメモリ２５６とを備える。データｄ及び更なるデータｆｄは、例えば、第１の通信インターフェース１５２によって受信されるデータパケットとして受信される。制御可能デバイス２５０は、動作コンポーネント１５４の動作ステータスを変更するためにデータｄを使用するように構成され、且つ、データｄ及び更なるデータｆｄをキャッシュメモリ２５６に記憶するように構成される。制御可能デバイス２５０は、リクエスト元デバイス２７０から、データｄ及び／又は更なるデータｆｄを求めるリクエストｒを受信することができる。そのようなリクエストｒの受信に応答して、リクエストされたデータｄ及び／又は更なるデータｆｄがキャッシュメモリ２５６に記憶されているとき、制御可能デバイスは、データｄ及び／又は更なるデータｆｄをリクエスト元デバイス２７０に送信する（２３６）ように構成される。

更なるデータｆｄは、典型的には、リソース制約付きデバイス２１０によって制御可能デバイス２５０に送信されるデータパケットとして常に送信されるデータである。従って、このデータを含むことによって、追加のオーバーヘッドは生成されない。更なるデータの取り得る実施形態を限定せずに、更なるデータの例は、以下のものである。リソース制約付きデバイス２１０の電力ステータス、リソース制約付きデバイス２１０のエネルギーステータス、リソース制約付きデバイス２１０の識別子、リソース制約付きデバイス２１０の能力、リソース制約付きデバイス２１０の構成情報、鮮度データ、リソース制約付きデバイス２１０の位置情報、１つ又は複数のエラーコード、１つ又は複数のログエントリ、リソース制約付きデバイスのハードウェアに対する物理的侵入の検出フラグ、製造業者名／タイプ／モデル／シリアル番号、ファームウェアバージョン、第２の通信インターフェースからのネットワーク診断情報、第２の通信インターフェースを介して送受信されるパケットの数、リソース制約付きデバイス２１０のルーティングペアレントの数又はアドレス、リソース制約付きデバイス２１０によって制御される他の制御可能デバイスの数又はアドレス、ネットワーク輻輳の尺度、入力デバイスの全ての入力のステータス、リソース制約付きデバイス２１０の全ての制御要素及び／又はセンサのステータス。

リクエスト元デバイス２７０が、リソース制約付きデバイス２１０に他のデータｏｄを送信する（２３８）ことを望むとき、データは、大抵は、リソース制約付きデバイス２１０によって受信されない。なぜなら、リソース制約付きデバイス２１０の（少なくとも）第２の通信インターフェース１１４は、大抵の時間はスリープモードであり得るからである。制御可能デバイス２５０のキャッシュメモリは、他のデータｏｄを一時的に記憶するために使用され得る。制御可能デバイス２５０は、他のデータｏｄを含むデータパケットをリクエスト元デバイス２７０から受信することができ、他のデータｏｄがリソース制約付きデバイス２１０に提供されなければならないことが制御可能デバイス２５０に示される。制御可能デバイスは、他のデータｏｄをキャッシュメモリ２５６に少なくとも一時的に記憶するように構成され、それにより、データは、後の時点で、リソース制約付きデバイス２１０に提供され得る。制御可能デバイス２５０は、リソース制約付きデバイス２１０の第２の通信インターフェース１１４が動作モードであることを知ると、他のデータｏｄをリソース制約付きデバイス２１０に送信する（２４０）。制御可能デバイス２５０は、例えば、前に受信されたスケジュール、若しくは第２の通信インターフェース１１４のモードのスケジュールの既知のパターンに基づいて、又は例えばその制御可能デバイス２５０がリソース制約付きデバイス２１０からデータｄ及び／又は更なるデータｆｄを最近受信したことに基づいて、第２の通信インターフェース１１４が動作モードである期間に関する知識を有することがある。他のデータｏｄの例は、リソース制約付きデバイス２１０に関するデータ設定、プログラム更新、及びまた、例えば、制御可能デバイスによってまだキャッシュされていないデータｄを求めるリクエストでよい。

図１及び図２の上の論述では、リソース制約付きデバイスのデータを求めるリクエストｒが制御可能デバイス１５０、２５０に達する、又は提供される他のデータｏｄが制御可能デバイス１５０、２５０に達すると仮定されている。これは、リクエスト元デバイス１７０、２７０が、例えば、複数のデバイスに向けて同時にこのデータを送信するために複数のメッセージのユニキャスト又はグループキャストメッセージを使用するときに当てはまることがあり、それにより、リクエストｒ、及び他のデータｏｄを含むデータパケットが、制御可能デバイス１５０、２５０によって受信され、リソース制約付きデバイス１１０、２１０の第２の通信インターフェースが動作モードであるときには、リソース制約付きデバイス１１０、２１０によって受信される。特定の用途において、また特にネットワーク標準において、メッセージは全てのデバイスに送信される。代替として、リソース制約付きデバイス及び制御可能デバイスは、グループとして配置され、そのようなグループの１つ又は複数のデバイスに関するデータパケットが、全体としてグループに即座にアドレス指定される。メッセージが重要であるデバイスのみが、メッセージを解釈して処理する。

図１及び図２のネットワークシステム１００及び２００は、複数のリソース制約付きデバイスと、複数の制御可能デバイスとを備えてもよいことに更に留意されたい。単一のリソース制約付きデバイスが、１つ又は複数の制御可能デバイスの動作を制御するためのデータｄをそれらの制御可能デバイスに送信することができる。単一の制御可能デバイスが、１つ又は複数のリソース制約付きデバイスから、制御可能デバイスの動作を制御するためのデータｄを受信することができる。従って、単一のリソース制約付きデバイスがデータｄを複数の制御可能デバイスに送信するとき、各制御可能デバイスは、データｄをそのそれぞれのキャッシュメモリにも記憶する。複数のユニキャスト又は１つのグループキャストがリクエスト元デバイスによって使用されるとき、データｄをキャッシュメモリに有する複数の制御可能デバイスが、リクエストｒを受信することができる。第１の実施形態では、キャッシュメモリにデータｄを有する全ての制御可能デバイスが、データｄをリクエスト元デバイスに送信することによって応答し、リクエスト元デバイスは、データｄを含むメイン応答として少なくとも１つの受信された応答を選択するためのハードウェア、アルゴリズム、又はヒューリスティックスを有する。また、複数の制御可能デバイスが、全ての制御可能デバイスが応答を送信することを防止するアルゴリズムを実装していることも可能である。例えば、全ての制御可能デバイスが、ネットワークを介して（例えば無線ネットワークで）送信される全てのメッセージを聞くことが可能であるとき、ある制御可能デバイスは、別の制御可能デバイスが既に応答を送信していることが検出されているときには、応答を送信しないと決定することができる。

図３は、ネットワークシステム３００の更なる実施形態を概略的に示す。ネットワークシステム３００は、リソース制約付きデバイス３１０と、制御可能デバイス３５０と、リクエスト元デバイス３７０と、アドレス解決機能３９０と、ネットワーク１３０とを備える。少なくとも、制御可能デバイス３５０は、ネットワーク１３０内での第１のネットワークアドレスＮＡ１を有する。制御可能デバイス３５０は、第１の通信インターフェース１５２を介して、第１のネットワークアドレスＮＡ１にアドレス指定されたデータ／情報／パケットをネットワーク１３０を介して受信するように構成される。制御可能デバイス３５０の他の特徴は、図１及び図２の制御可能デバイス１５０、２５０の特徴と同様である。第２のネットワークアドレスＮＡ２が、リソース制約付きデバイス３１０に割り当てられ得て、リソース制約付きデバイス３１０の第２の通信インターフェース１１４は、第２のネットワークアドレスＮＡ２にアドレス指定されたデータ／情報／パケットをネットワーク１３０を介して受信するように構成され得る。リソース制約付きデバイス３１０の他の特徴は、図１及び図２のリソース制約付きデバイス１１０、２１０の特徴と同様である。リソース制約付きデバイスは、名前又は識別子も有していてよい。名前は、人が読むことが可能であり理解することが可能であり得る文字列である。識別子も、文字列であり、これは、識別子を割り当てる特定のスキームの知識を人が有さない限り、大抵は人が理解できないものである。リソース制約付きデバイス３１０は、名前又は識別子のみの使用に基づいて、ネットワークを介してデータ／情報／データパケットを直接受信することはできない。ネットワークを介して送信されるデータ／情報／データパケットは、この実施形態のコンテキストでは、ネットワークアドレスを備えるべきである。ネットワークアドレスの一例は、ＩＰアドレス又はＭＡＣアドレスである。ネットワークアドレスは、ネットワーク内部で、データパケットを正しいデバイスに送達するために使用され、データパケットを受信するデバイスは、受信されたデータパケットがデバイス内で更に処理及び解釈されなければならないかどうかを決定するためにネットワークアドレスを使用することができる。デバイスの名前の一例は、「light_source_room_5」又は「temperature_sensor_corridor」である。

アドレス解決機能３９０は、リソース制約付きデバイス３１０の名前又は識別子と、少なくとも１つの制御可能デバイス３５０のネットワークアドレスとの間のマッピングを備え、少なくとも１つの制御可能デバイス３５０は、それがリソース制約付きデバイス３１０から受信する又は前に受信したデータｄを記憶するためのキャッシュメモリ１５６を有する。リクエスト元デバイス３７０は、リソース制約付きデバイスの指定された名前に関するネットワークアドレスを提供するために、アドレス解決機能３９０にリクエストｒｎａを送信するように構成され得る。アドレス解決機能３９０は、提供された名前がリソース制約付きデバイス３１０の名前であったときに、リソース制約付きデバイス３１０のデータｄをキャッシュメモリに記憶している制御可能デバイス３５０の第１のネットワークアドレスＮＡ１を提供するように構成される。その後、リクエスト元デバイス３７０は、リソース制約付きデバイス３１０のデータｄを求めるリクエストｒを送信するときに、受信された第１のネットワークアドレスＮＡ１を使用する。

アドレス解決機能３９０は、制御可能デバイスのネットワークアドレスを記憶することの代わりに又はそれに加えて、データｄをそのキャッシュメモリ１５６に備える制御可能デバイス３５０が存在するネットワークグループアドレスを記憶することができる。リソース制約付きデバイス３１０の特定の名前又は識別子に関するネットワークアドレスの提供を求めるリクエストを受信したのに応答して、アドレス解決機能３９０は、記憶されているネットワークグループアドレスをリクエスト元デバイスに提供することができる。

アドレス解決機能３９０は、例えば（ドメイン）ネームサーバである単一のデバイスによって提供され得る。この状況では、アドレス解決機能３９０は、ネットワーク１３０内で集中化される。アドレス解決機能３９０は、分散型で実装されてもよく、これは、ネットワーク１３０の複数のデバイスが協働してアドレス解決機能を実施することを意味する。「協働」は、単一のデバイスが完全なアドレス解決機能３７０を提供することはできず、複数のデバイスの組合せが、完全なアドレス解決機能３７０を提供することができることを意味する。

図３の上記の実施形態では、「アドレス解決機能」の代わりに又はそれに加えて、用語「リソースディレクトリ機能」が使用され得る。リソースディレクトリは、利用可能なリソースとそのようなリソースを提供するデバイスとの間のマッピングである。用語「リソース」は、このコンテキストでは、デバイスの「機能」又は「能力」を識別するために使用される。リソースディレクトリ機能は、そのような機能を提供する又はそのような能力を有するデバイスに向けてマッピングを提供し、且つ、リソースディレクトリ機能は、デバイスの名前、識別子、又はネットワークアドレスを記憶することができる。デバイスは、リソースディレクトリ機能にリクエストを送信することができ、リソースディレクトリ機能に、ネットワーク１３０内のどのデバイスが特定のリソースを提供するかを尋ね、リソースディレクトリ機能は、そのようなリソースを提供するデバイスの全て又は選択された組の名前／識別子／ネットワークアドレスを表す回答を提供することができる。好ましくは、リソース制約付きデバイスに関する限り、リソースディレクトリ機能は、特定のリソースを提供するリソース制約付きデバイスのデータｄを記憶している制御可能デバイスの名前／識別子／ネットワークアドレスを提供する。例えば、リクエスト元デバイスは、フロア１の部屋５の占有に関する情報を提供するデバイスのネットワークアドレス、名前、又は識別子を尋ねることがあり、リソースディレクトリ機能は、フロア１の部屋５内の在室センサデバイスによって制御されるフロア１の部屋５内の全ての光源のネットワークアドレスを提供することによって応答することができる。

図１、図２、及び図３のネットワークシステム１００、２００、及び３００は、特定の使用例で使用され得る。例えば、ネットワークシステムが照明システムであり、その際、リソース制約付きデバイスは、発光器／光源を制御するデバイスであり、制御可能デバイスは、発光器／光源である。例えば、ユーザによって操作され得るスイッチが、リソース制約付きデバイスであり、スイッチが提供される部屋内の全ての光源が、スイッチによって制御される制御可能デバイスでよい。同時に、やはり全ての光源を制御するセンサが部屋内に提供され得る。別の使用例は、建造物管理システムに関する。センサが、リソース制約付きデバイスでよい。センサの例は、温度センサ、湿度センサ、光強度センサ等である。制御可能デバイスは、例えば温度、湿度、光強度レベルに影響を及ぼすことがあるデバイス、例えば加熱デバイス、空気調和デバイス、シャッタやブラインド用のアクチュエータ等である。

図４ａは、リソース制約付きデバイスの実施形態を概略的に示す。第１の実施形態は、スイッチ４０２であり、これは、例えば光源のオンオフの切替えを制御するためにユーザによって操作され得る。第２の実施形態は、センサ４０４であり、これは、例えば温度、湿度、平均光強度等、特定の環境パラメータを測定する。第３の実施形態は、音センサ４０６である。第４の実施形態は、選択スイッチ４０８であり、これは、複数の異なるオプションの１つを選択するためにユーザによって操作され得る。様々なオプションは、例えば、特定の部屋内での様々な照明条件、又は再生されなければならない様々な音に関係することがある。第５の実施形態は、リモートコントローラ４１０であり、これは、別のデバイスを制御するためのユーザ入力を受信する。第６の実施形態は、カメラ４１２又は例えば在室センサである。第７の実施形態は、別のデバイスの制御に関するユーザ入力を受信するためのキーボード４１４である。上述のリソース制約付きデバイスのステータスに関係する送信されるデータｄは、制御要素（スイッチ）が配置されている実際の位置を示す値、又はセンサによって測定される実際の値でよい。送信されるデータｄはまた、制御要素（スイッチ）又はセンサから受信されたデータを処理した結果でもよく、送信されるデータｄは、より明示的には、「スイッチオン」、「青色光を発光する」、「スイッチオフ」、「シャッタを閉じる」等の制御データでよい。

図４ｂは、制御可能デバイスの実施形態を概略的に示す。第１の実施形態は、例えば光源４５２である。光源４５２は、受信されるデータｄに応じて光源４５２の発光器の発光を制御するための追加の回路（図示せず）を備える。例えば、発光の強度、又は色分布が制御され得る。他の制御可能なオプションは、例えば、光ビームの幅、及び光ビームが放出される方向でよい。第２の実施形態は、例えば加熱デバイス４５４である。第３の実施形態は、オーディオデバイスや警報器等、可聴信号を発生することが可能なデバイス４５６である。第４の実施形態は、空気調和ユニットのファン４５８である。ブラインド４６０又はシャッタが、第５の実施形態である。制御可能デバイスの上記の実施形態の動作コンポーネントは、それぞれ、発光器、加熱要素／システム、拡声器又は警報器、冷却システム／要素、シャッタの位置を移動させるためのアクチュエータである。

図５は、ネットワークシステム内のリソース制約付きデバイスから情報をキャッシュする方法５００の一実施形態を示す。ネットワークシステムは、リソース制約付きデバイスと、制御可能デバイスとを備える。この方法は、ｉ）リソース制約付きデバイスのステータスに関するデータを発生する段階５０２と、ｉｉ）発生されたデータをリソース制約付きデバイスから制御可能デバイスに送信する段階５０４と、ｉｉｉ）発生されたデータを制御可能デバイスで受信する段階５０６と、ｉｖ）受信されたデータに応答して、制御可能デバイスで特定のアクションを実施する段階５０８と、ｖ）受信されたデータを制御可能デバイスのキャッシュメモリに記憶する段階５１０と、ｖｉ）キャッシュメモリに記憶されているデータを求めるリクエストをリクエスト元デバイスから受信する段階５１６と、ｖｉｉ）受信されたリクエストに応答して、キャッシュメモリに記憶されているデータをリクエスト元デバイスに提供する段階５１８とを含む。任意選択的に、ネットワークシステムのデバイスのサブセットが、ネットワークグループアドレスを提供され、ネットワークシステムは、デバイスのグループのネットワークグループアドレスと、グループのそれぞれのデバイスの名前との間のマッピングを記憶するためのアドレス解決機能を備える。任意選択的に、方法５００は、更に、ａ）ネットワークシステムの特定のデバイスの特定の名前に関するアドレスを提供するようにアドレス解決機能にリクエストする段階５１２と、ｂ）リクエストの受信に応答して、特定のデバイスが属するグループのネットワークグループアドレスを提供する段階５１４とを含む。図５では、リクエストする段階５１２及び提供する段階５１４は、記憶する段階５１０と受信する段階５１６との間に示されているが、方法５００の段階のチェーンの別の点に提供されてもよく、又は図示される段階の１つ若しくは複数と並行して実行されてもよい。

以下の項では、方法及び／又はネットワークシステムの更なる実施形態が論じられる。

図６は、本発明の範囲内に入るネットワークシステムを概略的に示す。上部に、リクエスト元ｈｔｔｐクライアントデバイスＨＣが示されており、これは、外部ネットワークＥ−Ｎｅｔｗｏｒｋ ＥＮ（図６ではＥＮと表される）に結合される。外部ネットワークＥ−Ｎｅｔｗｏｒｋ ＥＮは、ドメインネームシステムサーバ又は分散型ドメインネーム解決機能Ｅ−ＤＮＳ ＥＤ（図６ではＥＤと表される）を有する。下部には、６ＬｏＷＰＡＮネットワーク６Ｎが示されており、ここに、幾つかのデバイスＲ、制御可能デバイスＣ１〜Ｃ３、及びリソース制約付きデバイスＲＲＤ１、ＲＲＤ２が提供される。６ＬｏＷＰＡＮネットワーク６Ｎ内部で、（内部）ドメインネームシステムＩＤも利用可能である。リソース制約付きデバイスＲＲＤ１及び制御可能デバイスＣ１、Ｃ２は、グループＸを形成する。６ＬｏＷＰＡＮネットワーク６Ｎは、６ＬｏＷＰＡＮ境界ルータ６ＬＢＲを介して外部ネットワークＥ−Ｎｅｔｗｏｒｋ ＥＮに結合される。

本発明の方法は、図６のネットワーク内部で実施され得る。

この方法は、初期化から始まる。リソース制約付きデバイスＲＲＤ１は、グループＸにステータス変更を報告し、グループＸのメンバである。リソース制約付きデバイスＲＲＤ１は、それが報告する報告先の各グループのメンバである。グループＸは、製造時又はコミッショニング時間中にデバイスにプログラム可能であり得る。コミッショニング労力を最小限にするために、リソース制約付きデバイス毎に一意的にマルチキャストアドレスを導出する、例えばそのデバイスのＩＥＥＥアドレス又はユニキャストアドレスから一意的にマルチキャストアドレスを導出するための標準定義された方法が存在し得る。リソース制約付きデバイスＲＲＤ１は、１つ／複数／全てのエクスポーズ可能なリソースに関するマルチキャストアドレスを使用することができる。即ち、リソース制約付きデバイスは、１つ又は複数のマルチキャストアドレスを使用して複数のグループに報告することができる。

リソース制約付きデバイスＲＲＤ１によって制御される制御可能デバイスＣ１、Ｃ２は、グループＸのメンバである。これは、（例えば、ローカルの又は集中化された、ユーザトリガされた又は自動の）コミッショニング処置の結果である。グループＸの制御可能デバイスＣ１、Ｃ２は、リソース制約付きデバイスＲＲＤ１からそれらが受信するデータに関するローカルキャッシュを生成する。これは、事前定義されても、コミッショニングプロセスの一部として構成されても、又はマルチキャストグループに送信された新たなリソース報告の受信時に動的に生成されてもよい。ローカルキャッシュは、例えば、制約付きデバイス／６ＬＢＲとの通信の信頼性、利用可能なキャッシュリソース、利用可能な他のキャッシュの数等の基準に基づいて、グループＸのメンバの幾つか、全て、又は所定のグループで生成され得る。更に、グループＸのメンバは、例えば報告頻度や閾値等、キャッシュされたリソースに関係付けられる他の重要な情報をキャッシュすることができる。ディスカバリサービス（例えば、Ｉ−ＤＮＳ ＩＤ及び／又はＥ−ＤＮＳ ＥＤ）が、リソース制約付きデバイスＲＲＤ１のリソースユニフォームリソースアイデンティファイアＵＲＩ（ホスト名）を、グループＸのマルチキャストアドレスに解決する。これは、（例えばリソース制約付きデバイスＲＲＤ１に関する登録プロセスがあればその一部として）自動的に導出されても、又はリソース制約付きデバイスＲＲＤ１自体、グループＸの他のメンバの任意のもの、若しくはコミッショニングツール／マネージャによって設定されてもよい。ディスカバリサービスＩ−ＤＮＳ ＩＤは、境界ルータ６ＬＢＲに、又はネットワーク内の任意の他のデバイスに位置され得て、集中化されても分散されてもよい。そのために標準のメカニズムが使用され得る。

初期化後、リクエスト元ＨＴＴＰクライアントＨＣは、リソース制約付きデバイスＲＲＤ１からデータをクエリすることができる。

ステップ１：リソース制約付きデバイスＲＲＤ１のデータを求める外部リクエストが存在する。リクエストは、ＨＴＴＰクライアントＨＣによって送信され得る。リクエストされたデータは、リソース制約付きデバイスＲＲＤ１によってグループＸに既に報告されているデータであることに留意されたい。

ステップ２：解決：リソース制約付きデバイスＲＲＤ１の名前、識別子、又はリソースがマルチキャストアドレスに解決される。解決（即ち解決のプロセス）は、例えば、６ＬＢＲによって提供されるＩ−ＤＮＳサービスＩＤによって、又は任意のディスカバリメカニズム、例えばマルチキャストドメインネームシステムｍＤＮＳ、ｘｍＤＮＳ、又はリソースディレクトリＲＤによって、（外部リクエストの場合には）６ＬＢＲ内で内部的に行われ得る。ディスカバリ情報は、ローカルネットワーク上で又はインターネット上で利用可能であり得る。外部クライアントの場合、２ステップ手法が使用され得る。即ち、外部クライアントは、まず６ＬＢＲにポイントされ得て、６ＬＢＲは、第２の解決プロセスを開始し、これは、（リンク）ローカルアドレス、エニーキャストアドレス、ユニキャストアドレス、又はマルチキャスト／グループアドレスにポイントし得る。代替として、エニーキャストアドレス、ユニキャストアドレス、又はマルチキャスト／グループアドレスを含めた、グローバルアドレスが使用されて、外部ｈｔｔｐクライアントＨＣに直接提供され得る。

ステップ３：データを求めるリクエスト、即ちクエリが、グループＸのマルチキャストアドレスに送信される。外部リクエストである場合、６ＬＢＲは、ディスカバリ／解決を行う。ユニキャストＨＴＴＰリクエストをマルチキャストＣｏＡＰ（Constrained Application Protocol）リクエストに変換する等、他のアクションを実行することもできる。リクエストが内部的である、即ち６ＬｏＷＰＡＮネットワーク６Ｎ内部のデバイスからのものである場合、リクエスタ自体が、ステップ２の解決を実施することができる。リクエスト内のアドレス情報は、制約付きデバイスに直接ポイントしていないので、リクエストされる実際のデータに関してリクエストフレーム内に何らかの標識が存在しなければならない。

ステップ４：グループＸのメンバがクエリに回答する。グループＸの全ての（現在活動中の）メンバがクエリを受信する。活動中のメンバは、少なくとも制御可能デバイスＣ１、Ｃ２である。クエリボディは、制御可能デバイスＣ１、Ｃ２のキャッシュで利用可能な／キャッシュされるデータにリンクされなければならない。一実施形態では、リンク付けは暗黙的でよい。例えば、リクエストが特定のグループにアドレス指定されることが、暗黙的に、特定の制約付きデバイス（又は更にはその特定のリソース）を示すことがある。また、リンク付けは、データが重畳していない場合には暗示的でよい。例えば、キャッシュが、１つのリソース制約付きデバイスのステータス／データのみをキャッシュし、そのようなステータス／データリソース自体を有さない場合である。別の実施形態では、明示的なデータマッピングが必要とされ得る。これは、事前定義されたマッピングでよく、事前定義されたストリングが、リクエストにおけるデータに追加される。例えば、「/sensor/occupancy/RRD1/status/occupancy」のリクエストされるセンサのデータ／ステータスは、「/light/L1/cache/sensor/occupancy/RRD1/status/occupancy」でよい。別の実施形態では、キャッシュ内の内部ステータス表現、例えば「/light/L1/handlers/occupancy」を、実際のリクエストされたリソース「/sensor/occupancy/RRD1/status/occupancy」にマッピングする必要性があり得る。マッピングは、使用される場合、キャッシュに内部的なものでよく、又は外界にエクスポーズされていてもよく、例えば解決メカニズム内にあり、それによりリクエスタ自体がマッピングを既に実施することができる。

リクエスト／クエリを受信するデバイスが、リクエストされたデータ（のコピー）を有さない場合、最も単純な実施形態では、リクエストを単に削除する。別の実施形態では又は他のエラー状況（例えば、データが現在の値を有さない、又は値が古い）では、デバイスは、リクエストに応答する別のノードを認識しない限り、リソース制約付きデバイスＲＲＤ１にリクエストを転送する。デバイス自体は、範囲内にあれば、転送のためにリクエストをバッファすることがあり、リソース制約付きデバイスのペアレント／プロキシがあればそこに転送することもある。デバイスは、データのキャッシュコピーを有する場合には、回答を準備し、任意選択的に、それがキャッシュされたコピーであることを（好ましくは標準準拠様式で）明確に示す。この任意選択的な標識は、好ましくは、そのような標識を受信することを予想していない又はそのような任意選択的な標識のフォーマットを知らないリクエスタが、それでも、リクエストされたデータの値を正確に読み取って、それにより標識を安全に無視することができるように含まれる。可能であれば、これは、この値の新しさ／残余有効期間も（好ましくは標準準拠様式で）示す。

好ましくは、応答の数を制限するためのメカニズムが存在する。分散型メカニズムが使用され得て、例えば、制御可能デバイスＣ１、Ｃ２は、ランダム化遅延後に応答をスケジュールし、ｘ（ここで、ｘは、０、１、２、３、又はそれよりも大きくてよい）よりも多くの応答が待機期間中に観察される場合には、デバイス自体のスケジュールされた応答を削除する。遅延は、純粋にランダムでよく、又はキャッシュノードに利用可能な何らかの情報、例えば、以前の転送の頻度／時間や、キャッシュされた情報の有効性／鮮度等に基づいていてもよい。応答する制御可能デバイスＣ１、Ｃ２をグループ内のデバイスの中から選択するための専用メカニズムが存在し得る。これは、例えば、制御可能デバイスＣ１、Ｃ２の活動（例えばハートビート信号）、及び選択基準、例えば最小値アドレスに基づいていてよい。選択は、受信された選択関連データに応じて、集中型で若しくはローカルで、又は各ノードによって自律式に行われ得る。また、制御可能デバイスＣ１、Ｃ２は、応答フレーム内のメタデータを埋めることができ、それにより、複数の制御可能デバイスＣ１、Ｃ２によって発生されるフレームは、同じフレームのコピーとみなされ得る。例えば、リソース制約付きデバイスＲＲＤ１のソースアドレスは、応答を送信する個々の制御可能デバイスＣ１、Ｃ２（キャッシュを有する）のソースアドレスではなく、応答のソースアドレスとして使用され得る。

リソース制約付きデバイスＲＲＤ１は、作動状態になった場合には回答することもできる。

好ましくは、例えば、クエリが指定された応答時間を有し、センサがウェークアップする前に時間が切れた場合、又は少なくとも１つの制御可能デバイスＣ１、Ｃ２が既に応答した場合、及び／又はキャッシュエントリが依然として有効／新しい場合に、スリープ中のリソース制約付きデバイスに対するクエリメッセージ（リクエストメッセージ）のバッファを停止させるため、又は更にはクエリメッセージを全くバッファしないと決定するための方法が存在する。この目的で、例えば、グループＸ内の制御可能デバイスＣ１、Ｃ２（キャッシュノード）は、バッファされたメッセージ内のデータ、例えば、ネットワークヘッダソース、宛先、及びフレームカウンタをチェックすることができる。制御可能デバイスＣ１、Ｃ２によって今応答された／回答可能なメッセージと同一である場合、メッセージは削除され得る。

ステップ５：応答が、リクエスタ／リクエスト元デバイス（リクエスト元ｈｔｔｐクライアントデバイスＨＣ）に送達される。応答は、重複除去される必要があり得て、例えば、利用可能であれば、リソース制約付きデバイスＲＲＤ１自体からの応答が選択され、又は最も新しい応答が選択される。これは、関連付けられる場合には、他の処理ステップ、例えばＣｏＡＰ−ＨＴＴＰプロトコル変換と共に、境界ルータ６ＬＢＲで行われ得る。また、リクエスト元デバイス自体によって行われてもよい。

ステップ６：任意選択的に、リクエスト元デバイス（を代表する境界ルータ６ＬＢＲ）が、グループＸのメンバになる。特にリクエストが頻繁である又は応答がタイムクリティカルである場合には、リクエスト元デバイス自体、及び／又は１つ／複数の（外部）ｈｔｔｐクライアントリクエスタＨＣを代表する境界ルータ６ＬＢＲが、グループＸのメンバになり得る。そうしないと、応答する（キャッシュを備える）多くのローカルの制御可能デバイスＣ１、Ｃ２が存在して、応答の重複除去をリソース集約的なものにする。利点：キャッシュを備える制御可能デバイスＣ１、Ｃ２の数及び位置は、リソース制約付きデバイスＲＲＤ１に何ら影響を及ぼさない。従って、このように追加のキャッシュノードを追加することは問題でない。

上述のネットワークシステム及び／又は方法の幾つかの変形形態は、以下のようなものである。ｉ）初期化中：このソリューションは、複数の制御可能デバイスが他のアドレス指定モード（例えばユニキャスト）を使用してリソース制約付きデバイスによって場合にも適用可能である。ｉｉ）リソース制約付きデバイスは、グループＸのメンバでなく、従ってリクエスト元デバイスからのクエリ／リクエストはそこに送信されず、キャッシュを備える制御可能デバイスＣ１、Ｃ２のみに送信される。ｉｉｉ）グループＸのメンバであり、（例えばそれらの隣接するテーブルから）リソース制約付きデバイスＲＲＤ１の真の識別／アドレスを知っているキャッシュを備える制御可能デバイスＣ１、Ｃ２は、現在の値に関してＲＲＤ１をポーリングすることをローカルで決定することができる。そのようなポーリング挙動は、任意選択的に、リソース制約付きデバイスＲＲＤ１のスリープスケジュールの知識によって最適化され得る。

上の議論は、主に、外部ｈｔｔｐクライアントＨＣからのリクエストに焦点を当てる。また、６ＬｏＷＰＡＮネットワーク６Ｎのデバイスの１つがリクエスト元デバイスであり、これが、リソース制約付きデバイスＲＲＤ１のステータスに関するデータを取得することを望むこともあり得る。例えば、デバイスＲ、Ｃ３、又はＲＲＤ２の１つが、リクエスト元デバイスでよい。そのようなデバイスは、まず、内部ドメインネームシステムＩＤを使用して、グループＸのマルチキャストアドレスを見つけることができる。前述のように、内部ＤＮＳ機能ＩＤは、境界ルータ６ＬＢＲによって実現され得る。その後、デバイスは、リソース制約付きデバイスＲＲＤ１のデータを求めるリクエストをグループＸに直接送信する。その後、キャッシュを備える１つ又は複数の制御可能デバイスＣ１、Ｃ２（及び、特定の状況では、リソース制約付きデバイスＲＲＤ１）は、データを送信することによって応答することができる。

更なるシナリオでは、制御可能デバイスＣ１、Ｃ２の１つではなく、且つグループＸのメンバでないデバイスが、リソース制約付きデバイスにデータ又は情報を書き込むことを望むことがあり得る。本明細書では以後、この状況の例示的実施形態が述べられる。

このシナリオは、リソース制約付きデバイスＲＲＤ１自体に達する必要があるメッセージを有するリクエスト元デバイスに焦点を当てる。そのような必要がある理由は、例えば、メッセージが、１回若しくは今後の報告のための、まだキャッシュされていないデータを求めるリクエストであること、又はメッセージが、例えばパラメータの提供、報告設定の変更、若しくは更には制約付きデバイスに対するソフトウェア更新を行うためのリソース制約付きデバイスＲＲＤ１への書き込み試行であることである。

ステップ７：リクエスト元デバイスは、リソース制約付きデバイスＲＲＤ１と通信する必要があり、ステップ２（上述）と同様に解決を行い、通信を求めるリクエストをリソース制約付きデバイスＲＲＤ１に送信する。

ステップ８：リソース制約付きデバイスＲＲＤ１から受信されたデータを記憶するためのキャッシュを有する制御可能デバイスＣ１、Ｃ２の少なくとも１つが、リソース制約付きデバイスＲＲＤ１に通信されることを意図された情報をキャッシュする。

ディスカバリ及びキャッシュプロセスにおける特定のリソースの表現は、例えばリソース制約付きデバイスの事前設定又はコミッショニング時間決定に基づいていてよい。例えば、コミッショニングツールは、構成コマンドを送信することができ、リソース制約付きデバイスＲＲＤ１（どの／幾つの制御可能デバイスＲＲＤ１）に宛てられる任意の情報がどの特定の制御可能デバイスＣ１、Ｃ２にキャッシュされているか、それをどう呼び出すか、どれほどの頻度で報告するか等を定義する。

キャッシュされないデータへのポインタ（例えば、Internet Engineering Task Force(IETF)及びInternet Societyによって発行されているRFC6690で論じられているもの等のＣｏＲＥリンクフォーマット記述）、又はリソース制約付きデバイスＲＲＤ１への汎用ポインタが、例えば構成プロセス中に、選択された制御可能デバイスＣ１、Ｃ２、又はディスカバリサービスに提供され得る。好ましくは、キャッシュを有する制御可能デバイスＣ１、Ｃ２は、例えば、リソース制約付きデバイスＲＲＤ１と最も頻繁に交信する、又は例えばリソース制約付きデバイスＲＲＤ１に物理的に最も近い制御可能デバイスＣ１、Ｃ２の中からインテリジェントに選択される。

オプション１：ディスカバリメカニズムは、直接通信のために、リソース制約付きデバイスＲＲＤ１（及び／又はそのペアレント／プロキシ）に直接ポイントする方法を有する。これは、リクエスト元デバイス及び／又はディスカバリメカニズムが異なるリクエストタイプを区別することが可能であることを必要とすることがある。例えば、「occusensor-write.room65.floor1.HTC34.example.com」を求めるリクエストは、センサのＩＰアドレスに解決され得、「occusensor.room65.floor1.HTC34.example.com」を求めるリクエストは、制御可能デバイスＣ１、Ｃ２のグループアドレスに解決され得る。ディスカバリシステムエントリ又はルーティングメカニズムが、リソース制約付きデバイスＲＲＤ１にターゲットされたユニキャスト通信がペアレント／プロキシノードを介して進むことを保証し得る。ペアレント／プロキシノードは、リソース制約付きデバイスＲＲＤ１によって必ずしも制御されない。即ち、リソース制約付きデバイスＲＲＤ１から制御データを受信する制御可能デバイスＣ１、Ｃ２では必ずしもない。ペアレント／プロキシノードは、集中化されても、リソース制約付きデバイスＲＲＤ１の範囲内にあってもよい。ペアレント／プロキシノードのタスクは、リソース制約付きデバイスＲＲＤ１向けのメッセージをバッファすること、好ましくは、各リソース制約付きデバイスＲＲＤ１に関する待機中のメッセージのキューを管理すること、好ましくはまた、処理ステータス、例えばバッファの利用可能性や予想される送達時間等についてリクエスト元デバイスを更新すること、好ましくはまた、リクエストを重複除去することである。

オプション２：ディスカバリメカニズムは、リソース制約付きデバイスＲＲＤ１からのデータを記憶するためのキャッシュを有する制御可能デバイスＣ１、Ｃ２にポイントすることのみを可能にすることができる。これは、グループを含む１つの／任意の／幾つかの／全てのリソース制約付きデバイスＣ１、Ｃ２、Ｃ３にポイントすることができる。このとき、リソース制約付きデバイスＣ１〜Ｃ３のタスクは、通信を求めるリクエストに回答することが可能でないと判断すること、又は制御可能デバイスＣ１〜Ｃ３のキャッシュに現在記憶されているデータに基づいて特定のデータを提供することが可能でないと判断すること、及びリクエストがリソース制約付きデバイスＲＲＤ１に送達されることを保証することである。当然、上のステップ４で述べられた制御可能デバイスＣ１〜Ｃ３の選択メカニズムは、このプロセスに能動的に関連付けられる（キャッシュを有する）制御可能デバイスＣ１〜Ｃ３の数を制限するために使用され得る。

オプション２Ａ：リソース制約付きデバイス毎に専用のペアレント／プロキシデバイスが存在する。リソース制約付きデバイスＲＲＤ１との通信を求めるリクエストをキャッシュする制御可能デバイスは、そのペアレント／プロキシデバイスを介してリソース制約付きデバイスＲＲＤ１に転送しなければならない。このとき、ディスカバリ及び／又はルーティングは、これに対処するように構成されなければならない。そのようなペアレント／プロキシデバイスは、上の段落で述べられたタスクに加えて、通信を求めるリクエストをキャッシュする複数のデバイスによって場合によっては転送されるメッセージを重複除去しなければならない。好ましくは、メッセージは、好ましくはネットワークレイヤオリジネータのアドレスに基づいて、可能な最小レベルでの重複フィルタリングを可能にする。より高いレイヤ情報も重複除去のために使用され得るが、ペアレント／プロキシノードでの追加のコードを必要とする。更に、リソース制約付きデバイスＲＲＤ１は、受信されたフレームを重複フィルタリングすることが可能であり、重複したフレームが取り扱われ、それらに対して応答が複数回送信されることを防止すべきである。

オプション２Ｂ：「ペアレントノード」が存在しない／複数の「ペアレント」ノードが存在しない。キャッシュを有する制御可能デバイスＣ１、Ｃ２の１つ／幾つか（即ち、リソース制約付きデバイスＲＲＤ１によって制御されるデバイス）は、リソース制約付きデバイスＲＲＤ１へのリクエストの直接の転送をスケジュールする。リソース制約付きデバイスＲＲＤ１は、重複されたリクエストを無視することができる。制御可能デバイスＣ１、Ｃ２は、可能であれば、リソース制約付きデバイスＲＲＤ１とのトラフィックを観察すべきである。リクエストに応答するリソース制約付きデバイスＲＲＤ１を認識した場合、制御可能デバイスＣ１、Ｃ２は、それらのキューをチェックしなければならず、まだ送信スケジュール内に残っている同じリクエストのコピーをキューが有する場合には、それを削除しなければならない。これを容易にするために、制御可能デバイス（キャッシュを有する）は、真のネットワークオリジネータアドレスをグループアドレス／エニーキャストアドレスによって置き換える必要があり得る。代替として、リソース制約付きデバイスＲＲＤ１は、実際のリクエスタアドレスとは無関係に、１つの／任意のグループに応答するように構成され得て、グループメンバは、（例えばリクエスタのアドレスを含む）待機中のクエリを追跡し、次いで応答をマッチングする役割を担う。

オプション２Ｃ：キャッシュ内での制御可能デバイスＣ１、Ｃ２における空データ作成。データを報告するようにリソース制約付きデバイスＲＲＤ１にリクエストするために、リクエスト元デバイスは、（例えば、ＲＥＳＴｆｕｌアーキテクチャの用語では、キャッシュを有する制御可能デバイスＣ１、Ｃ２のグループＸにアドレス指定される、空のリソースを作成するＰＵＴ又はＰＯＳＴリクエストを形成することによって）それまで存在していなかったデータフィールドを一旦作成することができる。これは、キャッシュに新規作成されたデータによって示される対応するデータ値についてソース制約デバイスＲＲＤ１に尋ねるように、（キャッシュを有する）制御可能デバイスＣ１、Ｃ２をトリガすることができる。

データクエリの場合、（キャッシュを有する）制御可能デバイスＣ１、Ｃ２は、リソース制約付きデバイスＲＲＤ１のステータスに関係付けられる追加の情報を記憶するために、データフィールド／レコードを事前に作成する。制御可能デバイスＣ１、Ｃ２又はペアレント／プロキシノードは、同じデータが複数回書き込まれる場合に、調停メカニズムを必要とすることがある。このメカニズムは、予め構成されてよく、又はメッセージ内で搬送されてもよい。例えば、制約付きメッセージの場合、最初に到着したメッセージのみ、又は最も新しいメッセージのみが、キャッシュに記憶され得る。パケットの重要性を判断する優先順位設定が存在し得る。期限切れパケットの削除を可能にするパケット寿命表示が存在することがある。制御可能デバイスＣ１、Ｃ２のペアレント／プロキシノードは、更に、書き込まれるべき値が送達される前に書き込まれるべきデータの変更をリソース制約付きデバイスが報告する場合に関する命令を必要とすることがある。例えば、ロールベースの優先権設定は、リソース制約付きデバイスＲＲＤ１と例えばコミッショニングツールとの間で調停することができる。そのような状況に対処するインテリジェンスは、リクエスト元デバイス側にあってよい。これは、パケットを再呼び出し／キャンセルするため又は前のパケットを取り換える意図を示すためのリクエスト元デバイスでのハードウェア又はソフトウェアを必要とすることがある。

任意選択的に、制御可能デバイスＣ１、Ｃ２のペアレント／プロキシノードは、リクエスト元デバイスへのバッファリングを確認する。

ステップ９：リソース制約付きデバイスＲＲＤ１が、動作モードをイネーブルにすることによって受信窓を開く。リクエストは、リソース制約付きデバイスＲＲＤ１に送達される。リソース制約付きデバイスＲＲＤ１が受信窓を時々開くと仮定される。受信窓（例えば、定期的なポーリング、定期的なリスニング、今送信されたフレーム後の肯定／応答受信のための受信窓、又はリソース制約付きデバイスによって送信されるフレーム内で告知される受信窓）の利用可能性を通信する、又は（例えば、肯定／応答フレーム内の何らかの標識、ポーリング応答、又はウェークアップメカニズムによって）受信窓の開放をトリガする正確なメカニズムが当該技術分野で知られている。同様に、必要であればセキュリティ及びアクセス制御メカニズムが、当該技術分野で知られている。そのようなメカニズムの幾つかは、使用される正確な通信プロトコル、例えば媒体アクセス制御によって指定される。複数の制御可能デバイスＣ１、Ｃ２のペアレント／プロキシノードの場合、調停メカニズム、例えばランダム遅延が、キャッシュを有するデバイスの１つのみが任意の所与の時点で送信することを保証するために使用され得る。遅延は、媒体アクセス制御、又はスタック内のより高い階層によって提供され得る。

送達中に能動的に関与しないキャッシュを有するデバイスは、通常通り機能することができ、例えば、リソース制約付きデバイスの送信によって受信窓がトリガされる場合に通常通り挙動して、例えば必要であればリソース制約付きデバイスに応答を送信し、及び／又は必要であればメッセージを転送することができる。代替として、それらのデバイスは、それらの挙動を変更して、リソース制約付きデバイスＲＲＤ１へのメッセージ送達をより良く実現し、例えば応答を送信するのを控える及び／又は転送を延期することができる。

任意選択的に、リソース制約付きデバイスＲＲＤ１は、「ｏｋ」を含む新たなデータの受信を確認する。任意選択的に、キャッシュを有する制御可能デバイスＣ１、Ｃ２のペアレント／プロキシノードは、リクエスト元デバイスへの（任意選択的に前のステップでの「ｏｋ」の受信を含む）ＷＲＩＴＥ（書込み）を確認する。

ステップ１０：必要とされる場合、リソース制約付きデバイスＲＲＤ１は、リクエストに応答する。リソース制約付きデバイスＲＲＤ１は、受信されたメッセージを分析する。当技術分野で知られているように、リソース制約付きデバイスＲＲＤ１は、メッセージを重複除去する、又はセキュリティ証明書をチェックすることができる。リソース制約付きデバイスＲＲＤ１は、リクエストタイプ及びアドレス指定されたデータがサポートされ得るかどうかをチェックすることができる。好ましくは、１回アクション（例えばデータクエリ）であるかどうか、又は今後定期的な通信が必要とされるかどうかは、リクエストから明らかである。更に、報告トリガ／条件（時間、イベント、閾値等）や、どのアドレスに報告されるか等に関する情報を含むことがある。或いは、制約付きデバイス自体が決定することができる。メッセージが書き込みリクエストである場合、リソース制約付きデバイスは、受信された情報を記憶する、例えばパラメータ値を更新する、又は新たなデータフィールドを作成することができる。リソース制約付きデバイスは、その挙動を修正し、例えば報告／ポーリング頻度を変更し、又は、例えば書き込みリクエストがソフトウェア更新の一部である場合には受信窓をより長く開くことができる。任意選択的に、リソース制約付きデバイスＲＲＤ１は、実施されるアクションを確認し、又は、アクションの完了に失敗した場合にはエラー番号を報告する。

メッセージがデータクエリである場合、制約付きデバイスは、応答メッセージを準備する。応答メッセージは、例えば、１回の報告かそれとも今後継続される報告か、何が報告トリガであるか（時間、イベント、閾値等）、どのアドレスに報告されるか（必要であれば新たなグループアドレス割り当てを含む）、データ寿命／有効性、報告頻度、別のパラメータと併せた報告等の、このリソースに関する報告挙動の特性を含む。報告特性は、元のクエリでリクエストされたものでよく、又は制約付きデバイスによってその能力及び必要性に従って修正されたものでよい。

リソース制約付きデバイスＲＲＤ１は、このリクエスト元デバイスのアドレスが受信リクエストメッセージから導出され得る場合には、応答を、元のリクエスト元デバイスに直接アドレス指定することができる。代替として、リソース制約付きデバイスＲＲＤ１は、制御可能デバイスＣ１、Ｃ２に応答をアドレス指定することができる。又は代替として、リソース制約付きデバイスＲＲＤ１は、単に、リクエストメッセージのネットワークレイヤヘッダに示されるソースアドレスに応答する。最も単純な実施形態では、リソース制約付きデバイスＲＲＤ１は、単に、応答を元のリクエスト元デバイスに転送して返す。別の実施形態では、キャッシュを有する少なくとも１つ／幾つか／全てのデバイスが、新規データフィールドを作成して、このデータ／情報をキャッシュする、又はステップ８で事前に作成されたデータフィールドを追加する必要があり得る。それらは、例えば、リソース制約付きデバイスのために既にキャッシュされているパラメータの量、デバイスとの交信の頻度、共有リソース報告等に応じて、リクエスト元デバイス／リソース制約付きデバイスによって元々アドレス指定されたグループから選択されるキャッシュを有するデバイスでよく、又はキャッシュを有する他のデバイスでよい。キャッシュを有するデバイスは、それに従って、ディスカバリメカニズムを更新する必要があり得る。リクエスト元デバイスは、応答を待機するか、又は前述の様式でキャッシュを有するデバイスへのクエリリクエストを形成する。リクエスト元デバイスはまた、このパラメータに関してキャッシュを有するデバイスとなることを選択することもでき、任意選択的に、リソース制約付きデバイスＲＲＤ１に、このパラメータの任意の将来の変化をリクエスト元デバイス自体に報告するようにリクエストすることができる。

まとめると、本発明は、リソース制約付きデバイスから情報をキャッシュするためのネットワークシステム及び方法に関する。リソース制約付きデバイスは、リソース制約付きデバイスのステータスに関係する発生されたデータを、制御可能デバイスを制御するためにネットワークを介して制御可能デバイスに提供する。制御可能デバイスは、データの受信に応答して、動作コンポーネントの動作を制御する。制御可能デバイスはまた、キャッシュメモリを備え、そこに、受信されたデータが記憶され、制御可能デバイスは、記憶されているデータを求めるリクエストをリクエスト元デバイスから受信するように構成され、且つ、記憶されているデータをリクエスト元デバイスに提供するように構成される。ネットワークシステムは、リソース制約付きデバイスにとってよりトランスペアレントなデータ用のキャッシュソリューションを提供する。

上記の実施形態は、本発明を限定せずに例示するものであり、当業者が、添付の特許請求の範囲の範囲から逸脱することなく多くの代替実施形態を設計することが可能であることに留意すべきである。

特許請求の範囲において、括弧内に記載された任意の参照符号は、特許請求の範囲を限定するものとは解釈されないものとする。動詞「備える」及びその語形変化の使用は、特許請求の範囲に述べられるもの以外の要素又はステップの存在を除外しない。要素に先立つ数詞「１つの」は、複数のそのような要素の存在を除外しない。本発明は、複数の異なる要素を備えるハードウェアによって、及び適切にプログラムされたコンピュータによって実施され得る。幾つかの手段を列挙するデバイス請求項において、これらの手段の幾つかは、ハードウェアの同一の要素によって具現化され得る。特定の手段が互いに異なる従属請求項に記載されていることだけでは、これらの手段の組合せが有利に使用され得ないことは示さない。

Claims (15)

1. リソース制約付きデバイスから情報をキャッシュするためのネットワークシステムであって、前記ネットワークシステムは、
   第１の通信インターフェースと、受信されたデータに基づいて特定のアクションを行うための動作コンポーネントとを備える制御可能デバイスであって、前記第１の通信インターフェースを介して前記データを受信し、前記受信されたデータに応答して前記動作コンポーネントの動作を適合させる制御可能デバイスと、
   第２の通信インターフェースと、前記リソース制約付きデバイスのステータスに関するデータを発生するためのデータ発生器とを備えるリソース制約付きデバイスであって、前記第２の通信インターフェースを介して前記制御可能デバイスに前記データを送信して、前記制御可能デバイスの動作を制御するリソース制約付きデバイスと、
   前記制御可能デバイス及び前記リソース制約付きデバイスを互いに接続するため、及びそれらそれぞれの第１及び第２の通信インターフェースの間で前記データを送信するためのネットワークと
   を備え、
   前記制御可能デバイスが、前記リソース制約付きデバイスから受信された前記データを記憶するためのキャッシュメモリを備え、
   前記制御可能デバイスが、前記リソース制約付きデバイスから受信された前記データを前記キャッシュメモリに記憶し、且つ、前記キャッシュメモリに記憶されている前記データを求めるリクエストをリクエスト元デバイスから受信し、且つ、前記リクエスト元デバイスに前記データを提供する、
   ネットワークシステム。
2. 前記リソース制約付きデバイスのステータスに関する前記データが、
   前記リソース制約付きデバイスのセンサの情報と、
   前記リソース制約付きデバイスの制御要素の情報と、
   前記制御可能デバイスで信号を発生するための、前記リソース制約付きデバイスの低バッテリステータスに関する又は前記リソース制約付きデバイスのエラーに関する情報とのうちの少なくとも１つに基づく、請求項１に記載のネットワークシステム。
3. 更なる通信インターフェースと、前記受信されたデータに基づいて特定のアクションを行うための更なる動作コンポーネントとを備える更なる制御可能デバイスであって、前記データを前記リソース制約付きデバイスから受信するように、及び前記受信されたデータに応答して前記更なる動作コンポーネントの動作を適合させる更なる制御可能デバイスを更に備え、
   前記リソース制約付きデバイスが、前記データを前記更なる制御可能デバイスにも送信し、
   前記更なる制御可能デバイスが、前記リソース制約付きデバイスから受信された前記データを記憶するための更なるキャッシュメモリを備え、
   前記更なる制御可能デバイスが、前記リソース制約付きデバイスから受信された前記データを前記更なるキャッシュメモリに記憶し、前記更なるキャッシュメモリに記憶されている前記データを求める前記リクエストを前記リクエスト元デバイスから受信し、前記リクエスト元デバイスに前記データを提供する、
   請求項１に記載のネットワークシステム。
4. 前記制御可能デバイス、前記リソース制約付きデバイス、及び請求項３を参照するときには前記更なる制御可能デバイスが、ネットワークアドレスを設けられ、前記ネットワークを介して前記ネットワークアドレスにアドレス指定されるメッセージを受信し、
   前記ネットワークシステムが、前記リソース制約付きデバイスの名前又は識別子と、前記リソース制約付きデバイスから受信されたデータを記憶するためのキャッシュメモリを有する少なくとも１つの制御可能デバイスのネットワークアドレスとの間のマッピングを記憶するためのアドレス解決機能を備え、前記アドレス解決機能が、前記リソース制約付きデバイスの前記名前又は前記識別子に結合された前記ネットワークアドレスの提供を求めるリクエストの受信に応答して前記ネットワークアドレスを提供する、
   請求項１又は３に記載のネットワークシステム。
5. 前記制御可能デバイス、前記リソース制約付きデバイス、及び請求項３を参照するときには前記更なる制御可能デバイスが、ネットワークアドレス、名前、又は識別子を設けられ、前記ネットワークアドレス、前記名前、又は前記識別子にアドレス指定されるメッセージを受信し、
   前記ネットワークシステムが、前記リソース制約付きデバイスによって提供される特定のリソースと、前記リソース制約付きデバイスから受信されたデータを記憶するためのキャッシュメモリを有する少なくとも１つの制御可能デバイスのネットワークアドレス、名前、又は識別子との間のマッピングを記憶するためのリソースディレクトリ機能を備え、前記リソースディレクトリ機能が、前記リソース制約付きデバイスが特定のリソースを提供するときに、特定のリソースに関する前記ネットワークアドレス、前記名前、又は前記識別子を提供することを求めるリクエストの受信に応答して、前記ネットワークアドレス、前記名前、又は前記識別子を提供する、
   請求項１又は３に記載のネットワークシステム。
6. 前記ネットワークアドレスが、個々のネットワークアドレス又はネットワークグループアドレスであり、前記個々のネットワークアドレスが、前記ネットワークシステムの単一のデバイスを一意的に識別し、前記ネットワークグループアドレスが、１グループのデバイスに属するアドレスであり、
   請求項５を参照するときに、前記名前が、制御可能デバイスの個々の名前又はグループ名であり、前記個々の名前が、前記ネットワークシステムの単一のデバイスを一意的に識別し、前記グループ名が、１グループのデバイスに属する、
   請求項４又は５に記載のネットワークシステム。
7. 請求項４を参照するときに、前記アドレス解決機能が、前記ネットワークシステムのアドレス解決デバイスによって提供され、前記アドレス解決デバイスが、前記アドレス解決機能の諸機能を実施し、
   請求項４を参照するときに、前記アドレス解決機能が、前記ネットワークシステムのデバイスに分散され、前記ネットワークシステムの前記デバイスが、互いに協働して前記アドレス解決機能を提供し、
   請求項５を参照するときに、前記リソースディレクトリ機能が、前記ネットワークシステムのリソースディレクトリデバイスによって提供され、前記リソースディレクトリデバイスが、前記リソースディレクトリ機能の諸機能を実施し、
   又は、
   請求項５を参照するときに、前記リソースディレクトリ機能が、前記ネットワークシステムのデバイスに分散され、前記ネットワークシステムの前記デバイスが、互いに協働して前記リソースディレクトリ機能を提供するように構成される、
   請求項４又は５に記載のネットワークシステム。
8. 前記リソース制約付きデバイスが、更なるデータを前記第２の通信インターフェースを介して前記制御可能デバイスに送信し、前記更なるデータがまた、前記リソース制約付きデバイスのステータスに関し、前記制御可能デバイスのアクションを直接は制御せず、
   前記制御可能デバイスが、前記更なるデータを前記キャッシュメモリに記憶し、前記更なるデータを求めるリクエストが前記制御可能デバイスによって受信されたときに、前記更なるデータを前記リクエスト元デバイスに提供する、
   請求項１に記載のネットワークシステム。
9. 前記更なるデータが、
   前記リソース制約付きデバイスの電力ステータス、前記リソース制約付きデバイスのエネルギーステータス、前記リソース制約付きデバイスの識別子、前記リソース制約付きデバイスの能力、前記リソース制約付きデバイスの構成情報、鮮度データ、前記リソース制約付きデバイスの位置情報、１つ又は複数のエラーコード、１つ又は複数のログエントリ、前記リソース制約付きデバイスのハードウェアに対する物理的侵入の検出フラグ、製造業者名／タイプ／モデル／シリアル番号、ファームウェアバージョン、前記第２の通信インターフェースからのネットワーク診断情報、前記第２の通信インターフェースを介して送受信されるパケットの数、前記リソース制約付きデバイスのルーティングペアレントの数又はアドレス、前記リソース制約付きデバイスによって制御される他の制御可能デバイスの数又はアドレス、ネットワーク輻輳の尺度、入力デバイスの選択された入力のステータス、前記リソース制約付きデバイスの選択された制御要素及び／又はセンサのステータスのうちの１つを備える、請求項８に記載のネットワークシステム。
10. 前記キャッシュメモリは、また、前記リソース制約付きデバイスに提供されなければならない他のデータを記憶し、前記制御可能デバイスが、前記他のデータを受信し、前記他のデータを前記キャッシュメモリに少なくとも一時的に記憶し、前記リソース制約付きデバイスが前記他のデータを受信することが可能であるときに、前記他のデータを前記リソース制約付きデバイスに送信する、請求項１に記載のネットワークシステム。
11. 請求項１に記載のネットワークシステムで使用するための制御可能デバイスであって、
    前記制御可能デバイスが、通信インターフェースと、受信されたデータに基づいて特定のアクションを行うための動作コンポーネントとを備え、前記制御可能デバイスが、前記通信インターフェースを介して前記データを受信し、前記受信されたデータに応答して前記動作コンポーネントの動作を適合させ、
    前記制御可能デバイスが、前記制御可能デバイスの動作を制御するリソース制約付きデバイスから受信された前記データを記憶するためのキャッシュメモリを備え、
    前記制御可能デバイスが、前記リソース制約付きデバイスから受信された前記データを前記キャッシュメモリに記憶し、且つ、前記キャッシュメモリに記憶されている前記データを求めるリクエストをリクエスト元デバイスから受信し、且つ、前記リクエスト元デバイスに前記データを提供する、
    制御可能デバイス。
12. 光源と、光源制御デバイスと、請求項１に記載のネットワークシステムとを備える照明システムであって、
    前記光源が、前記制御可能デバイスであり、前記光源の発光が、前記光源制御デバイスからのデータの受信に応答して制御され、
    前記光源制御デバイスが、前記リソース制約付きデバイスである、
    照明システム。
13. ネットワークシステムにおいてリソース制約付きデバイスから情報をキャッシュする方法であって、前記ネットワークシステムが、リソース制約付きデバイスと、制御可能デバイスとを備え、前記方法が、
    前記リソース制約付きデバイスのステータスに関するデータを発生する段階と、
    前記発生されたデータを前記リソース制約付きデバイスから前記制御可能デバイスに送信する段階と、
    前記発生されたデータを前記制御可能デバイスで受信する段階と、
    前記受信されたデータに応答して、前記制御可能デバイスで特定のアクションを行う段階と、
    前記受信されたデータを前記制御可能デバイスのキャッシュメモリに記憶する段階と、
    前記キャッシュメモリに記憶されている前記データを求めるリクエストをリクエスト元デバイスから受信する段階と、
    受信されたリクエストに応答して、前記キャッシュメモリに記憶されているデータを前記リクエスト元デバイスに提供する段階と、
    を含む、方法。
14. 請求項１３に記載のネットワークシステムにおいてリソース制約付きデバイスから情報をキャッシュする方法であって、前記ネットワークシステムの前記デバイスのサブセットが、ネットワークグループアドレスを提供され、前記ネットワークシステムが、デバイスのグループのネットワークグループアドレスと、前記グループのそれぞれのデバイスの名前との間のマッピングを記憶するためのアドレス解決機能を備え、前記方法が、
    前記ネットワークシステムの特定のデバイスの特定の名前に関するアドレスを提供するように前記アドレス解決機能にリクエストする段階と、
    前記リクエストの受信に応答して、前記特定のデバイスが属するグループのネットワークグループアドレスを提供する段階と、
    を含む、方法。
15. １つ又は複数の処理装置システムに請求項１３に記載の方法を実施させるための命令を含む、分散型ソフトウェアシステム。

Images