(57)【特許請求の範囲】
【請求項１】
照明システムを制御する方法であって、前記照明システムは複数の照明器具と、前記複数の照明器具に結合されるネットワークルータと、制御ネットワークを介して前記ネットワークルータに結合され、ユーザによって操作される制御デバイスとを含み、前記方法は、
前記制御デバイスによって、前記複数の照明器具のうちの少なくとも１つによってコマンドが受信されるべき時点を示すタイミング情報及びコマンド情報を含む制御メッセージを供給するステップと、
前記ネットワークルータによって、前記制御ネットワークを介して前記制御メッセージを受信するステップと、
前記ネットワークルータによって、前記コマンド情報に基づいて前記コマンドを生成するステップと、
前記ネットワークルータによって、前記タイミング情報に基づいて、前記制御メッセージにおいて識別される前記複数の照明器具のうちの少なくとも１つに前記コマンドを送る第１の時点を決定するステップと、
前記ネットワークルータによって、前記決定された第１の時点にて、前記制御メッセージにおいて識別される前記複数の照明器具のうちの前記少なくとも１つに前記コマンドを送るステップと、を含み、
さらに、前記方法は、
前記ネットワークルータによって、前記受信された制御メッセージを所定の時間バッファするステップと、
前記ネットワークルータによって、前記所定の時間内の追加の制御メッセージの受信を確認するステップと、
追加の制御メッセージが到着しない場合又は前記追加の制御メッセージが先の前記制御メッセージに関連しないと決定される場合、前記先の制御メッセージを処理するステップと、
前記追加の制御メッセージが前記先の制御メッセージに関連し、前記追加の制御メッセージが前記先の制御メッセージの前に処理されるべきことが示される場合、前記追加の制御メッセージを処理するステップと
を含む、方法。
【請求項２】
前記タイミング情報は、
先に確立されたタイマーを参照せず、前記ネットワークルータ及び／若しくは前記制御デバイス内で動作する内部クロックを参照する絶対的時間、並びに／又は
前記ネットワークルータ及び／若しくは前記制御デバイス内で動作する先に確立された一時的タイマーを参照し、及び／若しくは、前記制御デバイスと前記ネットワークルータとの間の先の通信を介して確立されたタイミング情報を参照する相対的時間を表す、請求項１に記載の方法。
【請求項３】
前記制御デバイスによって、第２のタイミング情報及び第２のコマンド情報を含む第２の制御メッセージを供給するステップと、
前記ネットワークルータによって、前記制御ネットワークを介して前記第２の制御メッセージを受信するステップと
を更に含み、前記決定された第１の時点がまだ起こっていない場合、
前記ネットワークルータによって、前記第２の制御メッセージより先に受信された前記制御メッセージ内に含まれる前記コマンド情報を破棄するステップを含む、請求項１又は２に記載の方法。
【請求項４】
前記照明システムは、前記制御ネットワークを介して前記ネットワークルータに結合される更なる制御デバイスを含み、前記方法は更に、
前記ネットワークルータによって、前記ネットワークルータを介して同じ時点にて同じ照明器具を制御しようとする前記制御デバイスのうちの１つだけが当該照明器具を制御することを保証するよう、優先度管理プロセスを実施するステップを含む、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記優先度管理プロセスを実施する前記ステップは、
前記制御デバイスによって、前記ネットワークルータに優先度リクエストメッセージを送るステップと、
前記ネットワークルータによって、前記制御ネットワークを介して前記優先度リクエストメッセージを受信するステップと、
前記ネットワークルータによって、前記制御デバイスのために優先度レベルを割り当てるステップであって、前記優先度レベルは、前記複数の照明器具のうちの１つ又は複数に関連付けられる、ステップと、
前記制御デバイスによって、前記割り当てられた優先度レベルを受信するステップと
を含む、請求項４に記載の方法。
【請求項６】
前記制御デバイスによって、適合されたコマンド情報及び／又は適合されたタイミング情報を含む、同じ照明器具にアドレス指定される同じ又は変更された制御メッセージを供給するステップを更に含む、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記制御ネットワークは少なくとも部分的にインターネットプロトコルベース制御ネットワークであり、インターネット、イントラネット、モバイル通信ネットワーク、無線制御ネットワーク、及び／又はこれらの組み合わせのうちの少なくとも１つを含み、
前記制御デバイスは、パソコン、モバイル端末、ハンドヘルドデバイス等の前記制御ネットワークのサブスクライバー端末であり、前記制御デバイスは前記制御ネットワークの上流に動作的に接続され、前記制御ネットワークは前記ネットワークルータの上流に動作的に接続され、前記ネットワークルータは前記複数の照明器具の上流に動作的に接続される、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記ネットワークルータはパケットベースネットワーキングシステムを介して前記複数の照明器具に結合され、
前記ネットワークルータは、１つ以上の受信された制御メッセージ内に含まれる前記コマンド情報を使用して、前記複数の照明器具のうちの少なくとも２つの照明器具のための１つ以上のコマンドを含む単一のパケットを生成し、前記パケットベースネットワーキングシステム上で送る、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記ネットワークルータはパケットベースネットワーキングシステムを介して前記複数の照明器具に結合され、
前記ネットワークルータは前記パケットベースネットワーキングシステムのブロードキャスト機能又はマルチキャスト機能を使用して、前記コマンドを単一のブロードキャストコマンドとして又は単一のマルチキャストコマンドとして、前記複数の照明器具のうちの少なくとも２つの照明器具に送る、請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記制御メッセージは、ＨＴＴＰリクエスト、ＨＴＴＰＳリクエスト、ＣｏＡＰリクエスト、ＣｏＡＰＳリクエスト、ＤＴＬＳプロトコルリクエスト、ＵＰｎＰリクエスト、ＷｅｂＡＰＩプロトコルリクエスト等のＷｅｂサービスリクエスト、ＳＯＡＰリクエスト、ＵＤＰデータグラム、ＴＣＰセグメント、及び／又はこれらの組み合わせのうちの少なくとも１つを含む、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
照明システムを制御するためのコンピュータプログラムであって、前記照明システムは複数の照明器具と、前記複数の照明器具に結合されるネットワークルータと、制御ネットワークを介して前記ネットワークルータに結合され、ユーザによって操作される制御デバイスとを含み、前記コンピュータプログラムは、前記コンピュータプログラムが前記ネットワークルータ及び／又は前記制御デバイス上で実行されるとき、前記ネットワークルータ及び／又は前記制御デバイスにそれぞれ、請求項１乃至１０の１つ以上に記載される方法のステップを実行させるためのプログラムコード手段を含む、コンピュータプログラム。
【請求項１２】
複数の照明器具を制御するための照明制御システムであって、前記照明システムは前記複数の照明器具に結合されるネットワークルータと、制御ネットワークを介して前記ネットワークルータに結合され、ユーザによって操作される制御デバイスとを含み、
前記制御デバイスは、前記複数の照明器具のうちの少なくとも１つによってコマンドが受信されるべき時点を示すタイミング情報及びコマンド情報を含む制御メッセージを供給し、
前記ネットワークルータは、
前記制御ネットワークを介して前記制御メッセージを受信し、
前記コマンド情報に基づいて前記コマンドを生成し、
前記タイミング情報に基づいて、前記制御メッセージにおいて識別される前記複数の照明器具のうちの少なくとも１つに前記コマンドを送る第１の時点を決定し、
前記決定された第１の時点にて、前記制御メッセージにおいて識別される前記複数の照明器具のうちの前記少なくとも１つに前記コマンドを送り、
さらに、前記ネットワークルータは、
前記受信された制御メッセージを所定の時間バッファし、
前記所定の時間内の追加の制御メッセージの受信を確認し、
追加の制御メッセージが到着しない場合又は前記追加の制御メッセージが先の前記制御メッセージに関連しないと決定される場合、前記先の制御メッセージを処理し、
前記追加の制御メッセージが前記先の制御メッセージに関連し、前記追加の制御メッセージが前記先の制御メッセージの前に処理されるべきことが示される場合、前記追加の制御メッセージを処理する
照明制御システム。
【請求項１３】
複数の照明器具を制御するためのネットワークルータであって、前記複数の照明器具は前記ネットワークルータを介して制御ネットワークに結合され、ユーザによって操作される制御デバイスが前記制御ネットワークを介して前記ネットワークルータに結合され、前記ネットワークルータは、
前記制御デバイスによって供給され、前記複数の照明器具のうちの少なくとも１つによってコマンドが受信されるべき時点を示すタイミング情報及びコマンド情報を含む制御メッセージを前記制御ネットワークを介して受信し、
前記コマンド情報に基づいて前記コマンドを生成し、
前記タイミング情報に基づいて、前記制御メッセージにおいて識別される前記複数の照明器具のうちの少なくとも１つに前記コマンドを送る第１の時点を決定し、
前記決定された第１の時点にて、前記制御メッセージにおいて識別される前記複数の照明器具のうちの前記少なくとも１つに前記コマンドを送り、
さらに、前記ネットワークルータは、
前記受信された制御メッセージを所定の時間バッファし、
前記所定の時間内の追加の制御メッセージの受信を確認し、
追加の制御メッセージが到着しない場合又は前記追加の制御メッセージが先の前記制御メッセージに関連しないと決定される場合、前記先の制御メッセージを処理し、
前記追加の制御メッセージが前記先の制御メッセージに関連し、前記追加の制御メッセージが前記先の制御メッセージの前に処理されるべきことが示される場合、前記追加の制御メッセージを処理する
ネットワークルータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、照明システムの制御方法、照明制御システム、複数の照明器具を制御するための制御デバイス、及び複数の照明器具を制御するためのネットワークルータを対象とする。本発明は、特に、照明システムにおいて、コマンド情報及びタイミング情報の両方を含む制御メッセージを生成することに関する。本発明は更に対応するコンピュータプログラムを対象とする。
【背景技術】
【０００２】
ＵＳ２００２／００５０７９９Ａ１は、照明負荷を制御するための照明装置を開示する。装置はネットワークインターフェイスを介してネットワークに接続されており、装置がオートモードにあるとき、照明負荷に送られるべきコマンドをネットワークから受信する。マニュアルモードでは、装置はネットワークからではなくリモコンからユーザー命令を直接受け、対応するコマンドを照明負荷に送る。ネットワークインターフェイスはプロトコル処理部及び時間情報を記憶するためのメモリを更に含む。この時間情報は、日時等の絶対的時間、ゼロ時点後の経過時間等の相対的時間、又はクロック発振器若しくは商用電力周波数における基準時点から複数のパルスをカウントした後の特定の時点におけるパルス等のカウント情報を意味する。時間情報はネットワークを介して受信される。装置は時間情報に基づいて照明負荷を制御する。映画の鑑賞中、いわゆるステージエフェクトを改良するために、テレビ等のＡＶユニットを照明装置とリンクさせることによって照明の光強度及び色を変更することが述べられている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明の一課題は、ラジカルに新しいネットワークプロトコルを使用することを要さずに既存の照明システムに容易に実装され得る、低複雑性かつ低コストではあるが、正確かつロバストな照明システムのタイミング制御を可能にする手段を提供することである。
【課題を解決するための手段】
【０００４】
本発明の第１の側面によれば、照明システムの制御方法が提供される。照明システムは複数の照明器具と、複数の照明器具に結合されるネットワークルータと、制御ネットワークを介してネットワークルータに結合される制御デバイスとを含む。方法は、
制御デバイスによって、タイミング情報及びコマンド情報を含む制御メッセージを供給するステップと、
ネットワークルータによって、制御ネットワークを介して制御メッセージを受信し、タイミング情報に基づいて第１の時点を決定するステップと、
ネットワークルータによって、コマンド情報に基づいてコマンドを生成するステップと、
ネットワークルータによって、決定された第１の時点にて、制御メッセージにおいて識別される複数の照明器具のうちの少なくとも１つにコマンドを送るステップとを含む。
【０００５】
本発明は、従来技術によれば、特に、制御デバイスと照明器具との間の異種制御ネットワークに起因する「長」距離のために、このような照明システムシナリオではコマンドセットの正確なタイミングが不可能であるとの認識を含む。従来技術の教示を実践する場合、同期要件を十分に満たすことができない。照明器具と制御デバイスとをインターリンクする制御ネットワークは、サーバ、基地局、ネットワークコントローラ、ルータ、スイッチ、ハブ等、多くのコンポーネントを含み得る。したがって、制御デバイスによって送信されたコマンドは照明器具に到達する前にかなり長い道のりを進み得る。このような長い道のりは複数のいわゆる「ホップ」、例えば、無線通信路から有線通信路等の物理層タイプの変化を含み得る。これは、多様であり特に予測不能なレイテンシをもたらし得る。また、レイテンシはネットワーク及びそのルータの状態に強く依存し得る。タイミング問題に関して照明器具を正確に制御することを狙いとするとき、このようなレイテンシは望ましくない。例えば、第１の照明器具が第２の照明器具と全く同じ時点において、又は、第２の照明器具のオン／オフのある正確な期間前／後にオン／オフされなければならない可能性がある。このような要求は、例えば、照明制御のタイミングが重要である特定の照明設備において見られる。制御デバイスが照明器具に直接結合される、すなわち物理層リンクによってのみ結合される場合、上記タイミング問題は通常起こらないが、制御デバイスが潜在的に大きな制御ネットワークを介して照明器具に結合され、（ホップ及びネットワークレイテンシの観点から）制御デバイスと照明器具との間の「距離」が比較的長い場合、上述したように、状況は全く異なる。
【０００６】
本発明によれば、コマンド情報、例えばＨＴＴＰ（Hypertext Transfer Protocol）及び／又はＣｏＡＰ（Constrained Application Protocol）コマンドをタイミング情報と組み合わせる新しいタイプの制御メッセージが定められる。このような制御メッセージは制御デバイスによって生成され、制御ネットワークを介して、（必ずしも物理的距離の観点からではなく、ネットワークホップ及び／又はネットワークレイテンシの観点から）制御デバイスより複数の照明器具にはるかに近く配置される例えばプロキシサーバなどのネットワークプロキシ等のネットワークルータに供給され得る。ネットワークルータはその後、制御メッセージ、特にタイミング情報を復号して、生成されたコマンド、例えば生成されたＣｏＡＰ又はＨＴＴＰコマンドを決定された第１の時点にて送信することにより、時限態様（timed manner）で複数の照明器具を制御する。好ましくは、ネットワークルータは完全にアプリケーション非依存であり、また、この新たなタイプの制御メッセージを「知らない」照明器具の制御を許容する。
【０００７】
したがって、本発明によれば、制御デバイスが正確なタイミングを取り扱うだけでなく、特に、（ネットワークホップ及び／又はネットワークレイテンシの観点から）照明器具にはるかに近い更なるデバイスによって正確なタイミング制御が達成され得る。更に、上記予測不能かつ変動するネットワークレイテンシに対処することができるようになる。コマンドは最終的にネットワークルータによって時限制御態様で送信されるので、このようなネットワークレイテンシはタイミング問題に対して実質的に影響を及ばさなくなる。制御デバイスがタイミング情報を生成するが、実際のコマンドはネットワークルータによって、タイミング情報に基づいて決定された特定の時点で送信される。
【０００８】
したがって、本発明は（ネットワークホップ及び／又はネットワークレイテンシの観点から照明器具から遠方に位置し得る）制御デバイスから（照明器具の近くに位置する）ネットワークルータへのコマンドの最終送信の移転を可能にする。ネットワークルータは受信された制御メッセージの到着後すぐに盲目的に転送するのではなく、制御メッセージからコマンドを導出する、すなわち、コマンド情報に基づいてコマンドを導出し、生成されたコマンドをタイミング情報に従って複数の照明器具のうちの識別された少なくとも１つの照明器具に送る。したがって、ネットワークルータはスイッチ又はハブ等として振る舞うだけでなく、更に照明器具にコマンドを送る時点の計算を実行する。
【０００９】
結果として、本発明は上記で概述されたシナリオにおいて設置される１つ以上の照明器具、すなわち、例えば制御デバイスとネットワークルータとの間の大きな異種制御ネットワークのために、（ホップ及び／又はネットワークレイテンシの観点から）制御デバイスからは比較的遠いがネットワークルータの近くに設置される照明器具の正確な時間制御を可能にする。複数の照明器具が存在する場合、それらの照明器具を同時に制御することができる。このような正確なタイミング制御を実施するために、実質的に追加コンポーネントを設置する必要はなく、特に、このような新しい制御機構に対応するために照明器具は必ずしも適合する必要がない。したがって、本発明は、照明システムの正確な時間制御の技術的問題に対して単純で、低複雑性かつ低コストなソリューションを提供する。
【００１０】
言い換えれば、本発明の主な利点は、正確なタイミングパフォーマンスで、また完全にアプリケーション非依存な態様で複雑な時限制御シーケンスを実行できることであり、ここで、制御されるデバイス（すなわち、照明器具）は、出願人（PHILIPS）が生産するデバイスの任意の組み合わせ及び／又はサードパーティーＩＰ（Internet protocol）制御可能デバイスの任意の組み合わせであり得る。
【００１１】
本発明の説明において、用語「照明器具」は、例えばＩＰベース制御ネットワーク等の制御ネットワークに結合され、これを介して制御可能なあらゆる種類の照明を指す。このような照明器具は好ましくはＨＴＴＰインターフェイス又はＣｏＡＰインターフェイスを備える照明器具である。好ましくは、複数の照明器具の少なくとも一部又は全てがＩＥＥＥ８０２．１５．４ネットワークなどのローカルネットワーク等の第２のネットワーク内に配置される。更なる例示的実施形態を以下に述べる。
【００１２】
好ましくは、ネットワークルータはプロキシサーバ等のネットワークプロキシである／を含む。
【００１３】
上記及び後述される実施形態の特徴は、特徴が明らかに互いに択一的であると説明されない限り、他の実施形態を設計するために互いに組み合わせられ得る。
【００１４】
制御メッセージは好ましくはＩＰ（Internet Protocol）メッセージ等のネットワーク層プロトコルメッセージ（すなわち、ＯＳＩ（Open Systems Interconnection）モデルの意味では第３層メッセージ）である。
【００１５】
コマンド情報は好ましくは、ＨＴＴＰコマンド及び／又はＣｏＡＰコマンド等の複数のアプリケーション層プロトコルコマンド（すなわち、ＯＳＩモデルの意味では第７層コマンド）を含む。好ましくは、ネットワークルータは制御メッセージからこのようなアプリケーション層プロトコルコマンドを抽出し、これを決定された第１の時点にて識別された照明器具に送る。
【００１６】
一実施形態では、コマンド情報内に含まれるＨＴＴＰコマンドはＨＴＴＰリクエストであり、及び／又は、コマンド情報内に含まれるＣｏＡＰコマンドはＣｏＡＰリクエストである。
【００１７】
好ましくは、コマンド情報及びタイミング情報は共に制御メッセージのペイロードセクション内に含まれる。
【００１８】
第１の例では、コマンド情報はＵＤＰ（User Datagram Protocol）ヘッダー、ＨＴＴＰヘッダー、又はＣｏＡＰヘッダー等のプロトコルヘッダーを含み、また、複数の照明器具のうちの１つ以上を識別する識別子がこれに含まれる。コマンド情報は更に、ＨＴＴＰコマンド又はＣｏＡＰコマンドのペイロードセクション等、実際のコマンド（例えば、“ｏｎ”、“ｏｆｆ”、“強度＝４”、“ディミング＝ｏｎ”等）が含まれるコマンドペイロードセクションを含む。
【００１９】
第２の例では、コマンド情報は実質的に全体がコマンドＵＲＬ（Uniform Resource Locator）に符号化される。このようなＵＲＬは例えば“coap://lamp1.domain.example.com/set?level=23&status=on”のようであり得る。このようなＵＲＬはコマンドが送られる照明器具を識別する識別子を更に含む。
【００２０】
第３の例では、コマンド情報は、“ＧＥＴ”、“ＰＵＴ”、“ＰＯＳＴ”、“ＤＥＬＥＴＥ”などのＣｏＡＰ／ＨＴＴＰリクエスト等、コマンド情報内に含まれるコマンドのタイプを指定する指定を含む。このようなコマンド情報は、更に、ＵＲＬ及びペイロードセクションを含む。ペイロードセクションは、調光時間間隔、光強度値、色値等、更なる特定の照明制御コマンドを組み込むことを可能にする。この例では、識別子もＵＲＬ内に含まれる。
【００２１】
第４の例では、コマンド情報は第３の例に対応するが、識別子はＵＲＬ内に含まれておらず、コマンド情報はＩＰアドレス又はＩＰホスト名等の明示的なターゲットデバイス識別子を含む。したがって、完全なＵＲＬを提供する代わりに、例えばＵＲＬパス及びオプションでＵＲＬクエリパラメータのみが提供される。第２の例と比較すると、このようなＵＲＬパスは例えば“set/lamp/1”のようであり得る。このような制御メッセージのペイロードセクションは、例えば“level=23;status=on;color=1234”のように表現されるコマンドを含み得る。
【００２２】
また、上記例の全てにおいて、コマンド情報は好ましくは、ネットワークルータによってコマンドが識別された照明器具に送信されるべき時点を指定するタイミング情報と結合される。したがって、タイミング情報はネットワークルータがコマンド情報に基づくコマンド、好ましくはＨＴＴＰコマンド及び／又はＣｏＡＰコマンド等のアプリケーション層プロトコルコマンドを含むコマンドを識別された照明器具に送信する時点を示す情報を構成する。
【００２３】
特に、タイミング情報は、識別された照明器具によってコマンドが受信されるべき時点を示す情報を構成することが好ましい。
【００２４】
したがって、好適な一実施形態では、方法は、ネットワークルータによって、ネットワークルータが各照明器具に送信するコマンドがネットワークルータから各照明器具まで伝搬するのに要する時間を決定するステップを含む。決定された時間は、好ましくは、ネットワークルータに接続された照明器具ごとにネットワークルータ内に記憶される。このような伝搬時間の計算は、一実施形態では照明器具ごとにラウンドトリップタイム（ＲＴＴ）を測定することによって行われる。
【００２５】
制御メッセージ内に含まれるタイミング情報に基づいて第１の時点を決定するステップが決定された時間を考慮することを含むことが更に好ましい。したがって、タイミング情報はコマンドが対応する照明器具によって受信されるべき時点を指定することができる。よって、ネットワークルータはこのようなターゲット受信時間及び測定された時間に基づいて、コマンド送信時点を計算する。
【００２６】
制御デバイス、ネットワークルータ、制御ネットワーク及び上記制御メッセージの更なる特定の実施形態を以下に述べる。
【００２７】
好適な一実施形態では、コマンド情報は２つ以上のコマンドに関する情報を含み、タイミング情報は、各コマンドが１つ以上の照明器具に送信されるべき又は各コマンドが対応する照明器具によって受信されるべき時点を指定する情報を含む。したがって、コマンド情報は、例えば複数のプロトコルリクエストを含み、タイミング情報は、複数のプロトコルリクエストの各々の時点に関する情報を含み得る。また、タイミング情報内にコマンドがどれだけ頻繁に照明器具に送られるかが指定されてもよい。
【００２８】
例えば、コマンド情報は、ＨＴＴＰに従う又はＣｏＡＰに従う複数のＰＵＴリクエスト、複数のＧＥＴリクエスト、及び／又は複数のＰＯＳＴリクエストのうちの１つ以上を含む。これは後により詳述される。当然ながら、コマンド情報はこのようなリクエストの３つ以上を含んでもよい。
【００２９】
他の実施形態では、方法は更に、ネットワークルータによって、タイミング情報に基づいて第２の時点を決定するステップと、ネットワークルータによって、複数の照明器具のうちの同じ及び／又は異なる照明器具にコマンドを送るステップとを含む。
【００３０】
これにより、１つ以上の照明器具の同期制御が達成される。例えば、第２の時点は、他の照明器具が消灯／点灯される又は光強度レベルが調整される第１の時点の後の時点である。または、同じ照明器具が第１の時点において点灯され、第２の時点において消灯される。これにより、１つ以上の照明器具の周期的な制御を容易かつ正確に実施することができる。
【００３１】
一例では、制御デバイスは埋め込みコマンドＣ１（時間ｔ＝０）、Ｃ２（時間ｔ＝２ｓ）、及びＣ３（時間ｔ＝２ｓ）を備える制御メッセージを送る。このメッセージを受信すると、ネットワークルータはタイマーを起動するｔ＝０。ネットワークルータはすぐに（時間ｔ＝０にて）第１の照明器具にアドレス指定されたコマンドＣ１を送信する。タイマーがｔ＝２ｓに至るまで待った後、ネットワークルータは第２及び第３の照明器具にそれぞれコマンドＣ２及びＣ３を連続して送信し、Ｃ３はＣ２の後に可能な限り早く送信される。
【００３２】
例えば、コマンド情報は逐語的に又は何らかの他の符号化された形式で制御メッセージ内に埋め込まれたＨＴＴＰリクエスト及び／又はＣｏＡＰリクエストを含む。
【００３３】
好ましくは、タイミング情報は、コマンド情報内に含まれる各アプリケーションプロトコルリクエストがいつなされるか及びオプションでその頻度を表す。
【００３４】
例えば、タイミング情報は、
先に確立されたタイマーを参照せず、ネットワークルータ及び／若しくは制御デバイス内で動作する内部クロックを参照する絶対的時間、並びに／又は
ネットワークルータ及び／若しくは制御デバイス内で動作する先に確立された一時的タイマーを参照し、及び／若しくは、制御デバイスとネットワークルータとの間の先の通信を介して確立されたタイミング情報を参照する相対的時間を表す。
【００３５】
一実施形態では、相対的時間は、ネットワークルータが制御メッセージを受信した時間からのミリ秒数を表す整数によって指定される。時間ｔ＝０が指定される場合、ネットワークルータはそのタイミング情報に関連するコマンドを可能な限り早く送る。時間ｔ＝１０００が指定される場合、ネットワークルータの内部タイマーがコマンドを含んでいた制御メッセージの受信後１秒が経過したことを示すまで、ネットワークルータは待つ。好ましくはネットワークルータ内に含まれるタイマーは、一実施形態では、任意の組み込みコンピュータプラットフォーム上で実現可能な標準的なソフトウェア実装タイマーである。タイミング情報（例えば、上記のような整数）は選択された適切な方法、例えば、可変長のＡＳＣＩＩエンコーディング又はＢｉｇ−Ｅｎｄｉａｎ  ＵＩＮＴ３２等の固定長バイナリエンコーディングを用いて制御メッセージ内に符号化され得る。
【００３６】
他の実施形態では、ネットワークルータはリアルタイムクロックとして実装される絶対的時間基準を含む。この場合、制御デバイスは好ましくは制御メッセージ内に適切なフォーマット、例えば、日付、時間、及び秒の小数を用いてＡＳＣＩＩストリングを指定することを可能にするＩＳＯ８６０１日付及び時刻フォーマットで絶対的時間情報を含む。
【００３７】
あるいは、制御デバイスによって送られる第１の制御メッセージは指定された（又は名付けられた）タイマーへの参照を含み、これは上記の意味では絶対的時間基準ではなく、第１のメッセージの受信時にネットワークルータソフトウェアが作成する相対的時間基準である。その後、制御デバイスによって送信された第２の制御メッセージはこの指定されたタイマーを参照し、これは、ネットワークルータに、全てのタイミング値をこの指定された稼働タイマーに関して翻訳させる。例えば、第１の制御メッセージは時間ｔ＝０ｍｓにて送信されるべき単一のコマンドＣ１を含み、制御デバイスに知られるユニークなＩＤを含むタイマー“timer83AF04B938E2197A”を指定する。ネットワークルータはその後、新しい指定タイマー変数を作成し、これをゼロに初期設定する。制御デバイスからの第２の制御メッセージは、時間ｔ＝２５００ｍｓにて送信されるべきコマンドＣ１及び時間ｔ＝３５００ｍｓにて送信されるべきコマンドＣ２、並びにネットワークルータが既に稼働しているタイマーとして認識する指定タイマー“timer83AF04B938E2197A”への参照を含む。
【００３８】
好適な一実施形態では、方法は、
制御デバイスによって、第２のタイミング情報及び第２のコマンド情報を含む第２の制御メッセージを供給するステップと、
ネットワークルータによって、制御ネットワークを介して第２の制御メッセージを受信するステップと
を更に含み、決定された第１の時点がまだ起こっていない場合、
ネットワークルータによって、第２の制御メッセージより先に受信された制御メッセージ内に含まれるコマンド情報を破棄するステップを含む。
【００３９】
上記で詳述したように、コマンド情報は２つ以上のコマンドを含み、タイミング情報は２つ以上の時点に関する情報、すなわち、各コマンドが各照明器具によって受信されるべき又はネットワークルータによって送られるべき時点に関する情報を含み得る。したがって、本実施形態では、用語「第１の時点」は、ネットワークルータによってまだ送信されていない先の制御メッセージのコマンドに関連付けられた時点を意味すると理解されたい。したがって、第２の制御メッセージの到着時点においてネットワークルータがまだ送信していない先の制御メッセージ内に含まれていたコマンドは、好ましくは破棄される。
【００４０】
この実施形態は、ネットワークルータから照明器具へのネットワークパス及び制御デバイスからネットワークルータへのネットワークパスにおける制御メッセージの紛失又は誤った順番（アウオトブオーダー）に対処するために特に好適である。制御デバイスは第１の制御メッセージを第２の制御メッセージの前に送信した可能性があり、又は、第２の制御メッセージを第１の制御メッセージの前に送信した可能性がある。
【００４１】
この実施形態の第１の変形例では、後の制御メッセージ（すなわち、第２の制御メッセージ）内に含まれるタイミング情報は如何なる絶対的な／先に確立されたタイマーも参照しない。この場合、少なくとも以下のモードが存在する。
１）「全ての後のコマンドをキャンセル」：各照明器具について、ネットワークルータは第２の制御メッセージ内に指定されるコマンドより後に送信されるあらゆる保留中の送信イベント（すなわち、先に送信された制御メッセージから得られた送信されるべきコマンド）をキャンセル／破棄する。よって、コンフリクトが生じる場合、第２の制御メッセージが常に勝利する。
２）「付加的」：いずれの保留中の送信イベントも保持され、第２の制御メッセージからの新しいイベントは単純に追加される。これは第１の（先に受信された）制御メッセージからのコマンドと第２の制御メッセージからのコマンドとの混合が照明器具に送信されることをもたらし得る。レンダリング結果が予測不能であり得る。
３）「制御可能」：ネットワークルータは制御メッセージベースで又はネットワークルータ構成の一部として、モード１）とモード２）との間で切り替わる。この第３のモードを実現するために、制御デバイスは、ルータに両モード間で切り替わることを指示するためのスイッチコマンドを送信し得る。
４）「時限コマンドごとに制御可能」：モード３）と同様であるが、今度は、ネットワークルータは第２の制御メッセージ内に含まれる各コマンドに基づいてモード１）とモード２）との間で切り替わる。
【００４２】
上記実施形態の第２の変形例では、後の制御メッセージ内に含まれるタイミング情報は絶対的タイマー又はネットワークルータにおいて先に確立されたタイマーを参照する。この場合、少なくとも以下のモードが存在する。
１）「全ての後のコマンドをキャンセル」：各照明器具について、ネットワークルータは時間ｔ＞＝ｍｉｎ（ｔｉ）にスケジュールされたあらゆる保留中の「送信イベント」をキャンセル／破棄し、ここで、ｔｉは対応する照明器具のための第２の制御メッセージ内の時間値である。
２）「重複のみをキャンセル」：各照明器具について、ネットワークルータは全く同じ時点ｔｉにスケジュールされている第１の制御メッセージから導出されたあらゆる保留中の「送信イベント」をキャンセル／破棄し、ここで、ｔｉは対応する照明器具のための第２の制御メッセージ内に含まれる時間値である。
３）「付加的」：第１の変形例のモード２）と同様である。
４）「制御可能」：第１の変形例のモード３）と同様である。
５）「時限コマンドごとに制御可能」：第１の変形例のモード４）と同様であるが、ここでは、時限コマンドごとに個別に制御可能である。
【００４３】
一実施形態では、方法は、ネットワークルータによって、受信された制御メッセージ内に含まれる少なくとも１つのホスト名にＤＮＳ（Domain Name System）リゾルバを適用するステップを含む。これは、ＵＲＩにおける権限（すなわち、サーバ名）をＣｏＡＰ又はＨＴＴＰリクエストにおけるシンボリック権威によって照明器具のＩＰアドレスに変換することを可能にする。したがって、解決されたＩＤアドレスは、制御メッセージにおいて識別される照明器具のうちの１つのＩＰアドレスである。
【００４４】
制御メッセージ自体は変換されず、制御メッセージにおいて識別される照明器具（例えば、“luminaire01.room3.floor5.building34.example.com”）をＩＰアドレスに変換するためにルックアップが行われるだけである。ＩＰアドレスは、ネットワークルータがコマンドを含むＩＰパケットを照明器具に送信することを可能にする。したがって、コマンドを備える制御メッセージは同じままであり、識別子だけが変更される。
【００４５】
あるいは、制御デバイスがネットワークルータに代わってこの変換を実行する。両アプローチにはそれぞれの利点があり、選択はネットワーク構成に依存し得る。例えば、制御デバイスは照明器具の実際のＩＰアドレスを知らず、ホスト名（すなわち、サーバ名又は権限）しか知らない可能性がある。この場合、制御デバイスはＩＰアドレスを得るためにＤＮＳルックアップ（「解決」オペレーション）を行わなければならないが、他の制御デバイスから受信され実行された先の制御メッセージからＩＰアドレスを既に知っている可能性があるネットワークルータにこれを委任することもできる。結果として、制御デバイスが変換を行う必要がないので、これは時間の節約となる。
【００４６】
好適な一実施形態では、ネットワークルータはプロキシサーバ等のネットワークプロキシを含む。したがって、ネットワークルータは他のサーバからのリソース、すなわち照明器具を求める制御デバイスからの制御メッセージのための仲介者として振る舞う。一実施形態では、制御デバイスはネットワークプロキシを含むネットワークルータに接続し、制御メッセージにより、ファイル、接続、及び／又はウェブページ等のサービス又は照明制御から入手可能な他のリソースをリクエストする。ネットワークプロキシは制御メッセージを評価し、コマンド及び第１の時点の両方を導出する。ネットワークプロキシは、コマンドがタイミング情報において指定された時点にて照明器具に到達するよう、導出されたコマンドを識別された照明器具に送信する。
【００４７】
他の好適な実施形態では、ネットワークルータは加えて又は代替的に６ＬｏＷＰＡＮ（IPv6 over Low Power Wireless Personal Area Network）ボーダールータ又は他のルータを含む。これにより、６ＬｏＷＰＡＮ規格を実装するネットワーク上で動作する照明器具はネットワークルータに直接結合され、ネットワークルータによって直接アドレス指定され得る。好ましくは、照明器具とネットワークルータとの間には２つ以上のネットワークホップが存在しない。代替的な実施形態では、ネットワークルータは、ＺｉｇＢｅｅ若しくは他の６ＬＰｏｗＰＡＮに基づかない８０２．１５．４ベースネットワーク、又はＩＰパケットの使用に基づかない任意の他のネットワークを使用して照明器具に結合する。この実施形態では、照明器具を結合するネットワーク側においてコマンドを伝達するために非ＩＰパケットが使用されるので、ネットワークルータはある種のルータとして振る舞うだけでなく、ある種のプロトコルネットワークルータとしても振る舞う。
【００４８】
通常、ネットワークルータと複数の照明器具との間の制御パスの平均レイテンシ、レイテンシの分散、ホップ数、パケットロス率の１つ以上が、制御デバイスと複数の照明器具との間の制御ネットワークパスの対応するパラメータより低いことが好ましい。上記のように、照明器具と制御デバイスとの間の比較的長いパスは、例えば社内イントラネット、インターネット、モバイル通信ネットワーク等を含み得る潜在的に大きくかつ異種の制御ネットワークのために発生する。本開示で述べられる制御ネットワークは照明器具とネットワークルータとの間に設置されず、もっぱらネットワークルータと制御デバイスとの間に設置される。
【００４９】
好適な一実施形態では、複数の照明器具のうちの少なくとも１つがウェブページを提供し、当該少なくとも１つの照明器具に送られるコマンドは、当該少なくとも１つの照明器具によって提供されるウェブページの設定を変更する。但し、照明器具はＨＴＴＰ又はＣｏＡＰコマンドに応答可能であるためにウェブページを提供しなければならないわけではないことを理解されたい。
【００５０】
例えば、照明器具が提供するウェブページはＨＴＴＰ及び／又はＣｏＡＰに基づく。ＨＴＴＰはウェブブラウジング及びウェブサービスのためのプロトコルとしてインターネット上で広く利用されているため、今日、多くの照明器具等の組み込み製品もＨＴＴＰプロトコルをサポートする。この実施形態の利点は、ユーザーが閲覧及び設定を変更できるウェブページが照明器具によって提供されることである。他の利点は、制御デバイスから／ネットワークルータからＨＴＴＰリクエストに基づきコマンドを直接受け取ることが可能な点である。これは“ＨＴＴＰ  ＲＥＳＴ  ＡＰＩ”とも呼ばれ得る。例えば、ＩＰネットワークを介して照明を制御するためにカスタムＨＴＴＰインターフェイスが定められる。この場合、照明器具を点灯して特定の色にするコマンドは以下の例示的なＨＴＴＰ  ＧＥＴリクエストのようなものである。
GET http://130.145.2.3/lamp?state=on&color=0xFF0000
【００５１】
制御メッセージ内に含まれるこのようなＨＴＴＰ  ＧＥＴリクエストはペイロードデータを一切有さず、全ての情報が、ＨＴＴＰクエリパラメータの形式でリクエストＵＲＩ（Uniform Resource Identifier）自体に符号化される。同じアプローチがＣｏＡＰ及び他のプロトコル、特に更なるＲＥＳＴ（REpresentational State Transfer）ベースプロトコルについても可能である。
【００５２】
上記ＨＴＴＰ／ＣｏＡＰコマンドをタイミング情報と組み合わせるために、制御メッセージは、一例では、全ての関連するコマンド情報がリクエストＵＲＩ（Uniform Resource Identifier）に符号化されるＨＴＴＰ  ＧＥＴリクエスト又はＣｏＡＰ  ＧＥＴリクエストを含む。あるいは、これらはペイロードが取り付けられたＨＴＴＰ  ＰＵＴ又はＣｏＡＰ  ＰＵＴリクエストでもよい。
【００５３】
一実施形態では、制御メッセージペイロードセクションは制御される照明器具の要件に適合される。しかし、概して、制御メッセージペイロードセクションはテキストフォーマット、例えばＸＭＬフォーマット、圧縮ＸＭＬフォーマット、ＪＳＯＮフォーマット、カスタムバイナリフォーマット、及び／又はＨＴＴＰ／ＣｏＡＰ規格のために定められた任意の他のコンテンツタイプであり得る。
【００５４】
次に、ＨＴＴＰ／ＣｏＡＰリクエストを実行するためのタイミング情報の１つの可能な表現を与える。他の表現も可能である。制御メッセージのある可能な定義は、以下に示されるようにＡＳＣＩＩテキストフォーマットで時間／メソッドコード／ＵＲＩトリプレットのリストをペイロードとして保持する、制御デバイスからネットワークルータへのＨＴＴＰ  ＰＵＴリクエストであり得る。
0.0 GET coap://lamp1.domain.example.com/set?level=23&status=on
2.0 GET coap://lamp2.domain.example.com/set?level=13&status=on
2.0 GET coap://lamp3.domain.example.com/set?level=17&status=on&color=0xFF0101
【００５５】
この例によれば、第１の照明器具（“ｌａｍｐ１”）は制御メッセージの受信直後に点灯され、一方、第２（“ｌａｍｐ２”）及び第３の照明器具（“ｌａｍｐ３”）は２秒（“２．０”）後に点灯される。
【００５６】
タイミング情報は拡張できる。例えば、他の例では、タイミング情報はネットワークルータがコマンドを送信すべき複数の時点を定める。このようなタイミング情報を含む制御メッセージは以下のようであり得る。
1.2 5.8 15.0 23.0 GET coap://lamp1.domain.example.com/set?level=23&status=on
【００５７】
２つ以上のコマンドを含む制御メッセージの他の例は、コマンドの反復を可能にするものである。
1.0 repeat 15 every 2.0 : GET coap://lamp1.domain.example.com/set?level=23
1.3 repeat 15 every 2.0 : GET coap://lamp1.domain.example.com/set?level=9
【００５８】
これは照明をまず高いレベルに設定し、３００ｍｓ後に低いレベルに設定する。シーケンスは２秒ごとに１５回繰り返される。一実施形態では、例えば変数を使用することによって、数学を実行することによって、及び高度な制御文（for/while/if-then/switch/...）を使用することによってより複雑なタイミング情報を定めるために、スクリプト言語（例えば、Ｐｙｔｈｏｎ、Ｐｅｒｌ、Ｒｕｂｙ、ｐｈｐ、ＪａｖａＳｃｒｉｐｔ（登録商標）、又はこれらの簡易バージョン）又は場合によってはバイトコードインタープリタプログラミング言語（Ｊａｖａ（登録商標）、Ｃ＃）が使用される。
【００５９】
一実施形態では、ベーシックな時間情報は秒単位の浮動小数値で符号化される。また、ＡＳＣＩＩで符号化された秒単位の整数、又は、より容易なパーシングのためにＢｉｇ−Ｅｎｄｉａｎ  ＵＩＩＮＴ３２で符号化された整数も適切である。このようなタイミング情報の後には好ましくはスペースが続き、好ましくはＣｏＡＰ又はＨＴＴＰリクエストコード（例えば、“ＧＥＴ”、“ＰＵＴ”、“ＰＯＳＴ”、又は“ＤＥＬＥＴＥ”）が続き、好ましくはアドレスを含むＵＲＩ（Uniform Resource Identifier）が続き、ＨＴＴＰ／ＣｏＡＰリクエストをなす。全ての関連する情報がリクエストＵＲＩに符号化される照明器具（ｌａｍｐ１〜３）の特定のＡＰＩ（Application Programming Interface）のため、上記で列挙されるＣｏＡＰリクエストのためのペイロードは本例では不要であり、使用／定義されない。したがって、メソッド（ＧＥＴ、ＰＯＳＴ等）及びリクエストＵＲＩのみを定めることにより、実行されるべきＨＴＴＰ又はＣｏＡＰリクエストが完全に示される。
【００６０】
上述したように、ネットワークルータが１つ以上のタイマーを含み、タイミング情報がネットワークルータ内で実行中の１つ以上のタイマーを参照する相対的時間を表すことは好ましい。上記の例では、制御メッセージは特定の時間において、すなわち第１の時点ｔ＝０ｓ（ゼロ）及び第２の時点ｔ＝２ｓにおいて３つの照明器具（ｌａｍｐ１、ｌａｍｐ２、ｌａｍｐ３）に指示されるべき３つのコマンドを含んでいた。いくらかの時間が経過した後、制御デバイスは最も低い指定時間がゼロではない第２の制御メッセージを供給し得る。これは、先に確立されたタイムベース、すなわち、上記の先に受信された制御メッセージの処理に使用されたタイマーが参照されることをネットワークルータに示す。以下に一例を示す。
12.0 GET coap://lamp1.domain.example.com/set?status=off
14.0 GET coap://lamp2.domain.example.com/set?level=1&status=on
【００６１】
この場合、第２の制御メッセージを復号する際、ネットワークルータは好ましくは、第２の制御メッセージのＩＰソースアドレス（第１の制御メッセージにおける第１のＩＰソースアドレスに一致する）に基づき、そのセッションに使用されたタイマーを識別する。
【００６２】
したがって、他の実施形態では、制御デバイスによって供給される制御メッセージは、更にセッション識別子又は“cookie”を含む。セッション識別子は、２つ以上の制御デバイスによる複数の照明器具の正確なタイミング制御を容易にする。例えば、複数の照明器具（例えば、１０個の照明器具）がネットワークルータに結合され、第１の制御デバイス及び第２の制御デバイスが制御ネットワークを介してネットワークルータに結合され、第１の制御デバイスは複数の照明器具の第１の部分（例えば、照明器具１〜５）を制御し、第２の制御デバイスは複数の照明器具の第２の部分（例えば、照明器具６〜１０）を制御する。制御メッセージ内に含まれるタイミング情報が参照するタイマーをネットワークルータが備える上記例に関して述べられた機能を好適に提供するために、ネットワークルータは、ここでは好ましくは２つ以上のタイマーを含み、異なる制御デバイスによって送られる制御メッセージを区別するよう構成される。したがって、好ましくは制御メッセージ内にセッション識別子（ＵＳＩ）が含まれ、制御デバイス又は制御デバイス上で動作するアプリケーション（「アプリ」とも称する）がセッション識別子を使用して先に確立されたタイムベースを参照できる。したがって、セッション識別子がネットワークルータ内で動作する複数のタイマーのうちの特定の１つを指すことが好ましい。
【００６３】
一実施形態では、ネットワークルータはＨＴＴＰをＣｏＡＰに及び好ましくはその反対に変換するよう構成される。これは、ＨＴＴＰにのみ基づく制御デバイス、例えばスマートフォン、ＰＣ、又はインターネット上のウェブサービスによってもＣｏＡＰ照明器具を制御することを可能にする。ＣｏＡＰは比較的新しく、現在も標準化が進行中であるので、現在、市場にはほとんどＣｏＡＰ制御型の照明器具は存在しないが、これは２０１２／２０１３に標準化が終了した後には変化すると予想される。例えば、制御デバイスとしてのタブレット又はスマートフォン等のモバイルデバイスから、ネットワークプロキシ及び６ＬｏＷＰＡＮ（IPv6 over Low Power Wireless Personal Area Network）ボーダールータを含むネットワークルータにＨＴＴＰ制御メッセージが送信され、ネットワークルータは、内蔵ＨＴＴＰ−ＣｏＡＰクロスプロトコルマッピングプロキシを介してＨＴＴＰ制御メッセージをＣｏＡＰパケットフォーマットに変換する。変換されたメッセージはネットワークルータにより、ＩＰ／６ＬｏＷＰＡＮ上のＵＤＰ（User Datagram Protocol）上で、複数の照明器具を相互接続する制約ＩＥＥＥ８０２．１５．４ネットワークセグメントに伝送される。しかし、本発明では具体的なアプリケーションプロトコルフォーマットは問題とはならないことを理解されたい。
【００６４】
照明システムが制御ネットワークを介してネットワークルータに結合されるよう構成された更なる制御デバイスを含み、また制御デバイスがネットワークルータを介して同じ時点において同じ照明器具を制御しようとする場合、方法が更に、
ネットワークルータによって、制御デバイスのうちの１つだけが当該照明器具を制御することを保証するよう、優先度管理プロセスを実施するステップを含むことが好ましい。
【００６５】
例えば、優先度管理プロセスを実施するステップは、
制御デバイスによって、ネットワークルータに優先度リクエストメッセージを送るステップと、
ネットワークルータによって、制御ネットワークを介して優先度リクエストメッセージを受信するステップと、
ネットワークルータによって、制御デバイスの優先度レベルを割り当てるステップであって、優先度レベルは、複数の照明器具のうちの１つ又は複数に関連付けられる、ステップと、
制御デバイスによって、割り当てられた優先度レベルを受信するステップと
を含む。
【００６６】
この実施形態は、特に照明器具が２つ以上の制御デバイスによって制御される場合、例えば、第１の制御デバイス及び第２の制御デバイスが制御ネットワークを介してネットワークルータに結合され、同じ（１つ又は複数の）照明器具を制御する場合、複数の照明器具の正確なタイミング制御を容易にする。この実施形態はアクセスポリシーの実施を可能にする。一例では、第１の制御デバイスに特定の照明器具への排他的アクセスを与える優先度レベルが第１の制御デバイスに割り当てられる。第２の制御デバイスには、必然的に当該特定の照明器具に対して第２の制御デバイスがコマンドを出せないことを保証する他の優先度レベルが割り当てられる。当然ながら、より多くの区分された優先度レベル、例えば１から１０の段階を定めることも可能である。したがって、制御デバイスからネットワークルータが受信する制御メッセージは、制御メッセージ内に示される優先度レベルに応じて取り扱われ、最も高い優先度レベルを含む制御メッセージが最初に処理される。したがって、方法が、例えば制御デバイスが割り当て優先度レベルを制御メッセージ内に含めるステップを更に含むことが更に好ましい。
【００６７】
例えば、上記実施形態において、制御デバイスは優先度リクエストメッセージにより、特定の照明器具の制御状態をネットワークルータに尋ねる。制御デバイス又は制御デバイスのユーザーが特定の照明器具宛ての制御メッセージを送信すべきか否かを決定し得るよう、ネットワークルータは、制御状態（例えば、「制御されている」、「制御デバイスｘｙによって制御されている」、「制御デバイスｘｙ＠優先度レベルｐｌによって制御されている」、又は「制御されていない」）を制御デバイスに通知する。
【００６８】
制御コンフリクトの回避を向上させるために、制御メッセージを供給する前に制御デバイスが優先度リクエストメッセージを送信することが好ましい。
【００６９】
ネットワークルータによって優先度管理プロセスを実施するステップを含む方法の他の実施形態では、制御デバイスの積極的な参加はなく、ネットワークルータが全ての優先度処理を取り扱う。この実施形態では、２つ以上の制御デバイスは優先度リクエストを送信せず又は割り当て優先度に関する情報を受信しない。この実施形態は次のように構成され得る。例示的な一実施形態では、２つ以上のコントローラが共に同じ照明器具を制御しようとしているコンフリクト状況を検出するために、ネットワークルータ内の機構が全制御デバイスからの全制御メッセージを検査する。このようなコンフリクト状況の検出は、例えば、２つ以上の別個の制御デバイスが、当該照明器具に関する、互いに２秒未満しか離れていないタイミング情報を含む制御メッセージをそれぞれ送信したかを検討することにより、実施される。このようなコンフリクト状況が検出される場合（そしてそれが存在する限り）、優先度管理プロセスを実施するネットワークルータは、好ましくは、最も高い優先度を有する単一の制御デバイスからのメッセージを除き、関与する制御デバイスからの全制御メッセージについて、該当する照明器具に送られるコマンドに変換されることを妨げる。衝突する制御デバイスのうちのいずれが最も高い優先度を有すべきかを決定するために、ネットワークルータは様々なプロセスを用いることができる。第１の例では、ネットワークルータは各制御デバイスに数値優先度レベルを割り当てるテーブルを使用し、この割り当ては制御デバイスのＩＤ又は他のデバイス特徴に基づく。ネットワークルータは好ましくは、先に作成させたテーブル内の各制御デバイスの制御デバイスＩＤ／制御デバイス特徴をルックアップする。ネットワークルータは最も高い数値を有する制御デバイスに最も高い優先度を割り当てる。第２の例では、ネットワークルータは、照明器具の（衝突する）制御デバイスのグループに最初に（又は最後に）加わった制御デバイスに最も高い優先度を割り当てる。これらの２つの例を組み合わせることもでき、例えば、第１の例に従って同じ優先度数値を有する２つの制御デバイス間で選択をするために第２の例を用いてもよい。当然ながら、上述の２秒はあくまで例示的な時間距離に過ぎないことを理解されたい。２つ以上の衝突する制御メッセージ間の時間距離は、当然ながらより短くても長くてもよい。
【００７０】
一実施形態では、制御メッセージはＵＤＰ（User Datagram Protocol）リクエストを含む。例えば、複数の照明器具を互いに相互接続する６ＬｏＷＰＡＮ制約ネットワークにおいて、ＵＤＰプロトコルに加えてＣｏＡＰプロトコルが使用される。
【００７１】
他の実施形態では、方法は更に、
ネットワークルータによって、受信された制御メッセージを所定の時間バッファするステップと、
ネットワークルータによって、所定の時間内の追加の制御メッセージの受信を確認するステップと、
追加の制御メッセージが到着しない場合又は追加の制御メッセージが先の制御メッセージに関連しないと決定される場合、制御メッセージを処理するステップと、
追加の制御メッセージが先の制御メッセージに関連し、追加の制御メッセージが先の制御メッセージの前に処理されるべきことが示される場合、追加の制御メッセージを処理するステップとを含む。
【００７２】
この実施形態は、特に、２つ以上の制御デバイスによって送信された制御メッセージが送信された順番と同じ順番でネットワークルータに到着せず、異なる順番（アウトオブオーダー）で到着する場合に、照明器具の正確なタイミング制御を容易にする。このようなシナリオは例えばＵＤＰベースネットワークにおいて起こり得る。このようなアウトオブオーダー受信の考えられる原因は、（ホップ／レイテンシの観点からの）第１の制御デバイスとネットワークルータとの間の距離が、第２の制御デバイスとネットワークルータとの間の距離と大きく異なり得ることである。あるいは、単一の制御デバイスによって送信される異なる制御メッセージは制御ネットワークによって異なる態様で送られ、これは、ｔ＝０ｓにおいて送信された第１の制御メッセージが、ｔ＝０ｓの後に送信された第２の制御メッセージよりも遅くに到着することを示唆する。ネットワークルータにおけるこのようなアウトオブオーダー受信によるコンフリクトを避けるために、この実施形態は、本質的に、受信された制御メッセージの所定の期間のバッファリングを提供する。所定の期間の時間は、制御される照明システムの要求に適合され、例えば、２０ミリ秒から２分の間で変化し得る。
【００７３】
先の制御メッセージと更なる制御メッセージとの間の関係は、例えば両メッセージが同じ照明器具を対象とすることを認識することにより、両メッセージが共通のタイムベースを参照することを認識することにより、及び／又は両メッセージが同じソースによって送信されたことを認識することにより識別され得る。このような関連するメッセージは「フォローアップメッセージ」とも呼ばれ得る。
【００７４】
更なる制御メッセージが先の制御メッセージの前に処理されるべきであることの指示は、一実施形態では制御デバイスによって、例えば制御メッセージ内に順番の指標及び／又は絶対的時間等のタイムスタンプを含めることによって実施される。
【００７５】
したがって、先の制御メッセージの後にネットワークルータに到着する更なる制御メッセージは、状況によっては、ネットワークルータが誤った順番で受信された制御メッセージを正しい順番にするよう、先の制御メッセージの前に処理され得る。
【００７６】
他の実施形態では、ネットワークルータが先の制御メッセージが処理されたことを制御デバイスに通知した後にのみ更なる制御メッセージを供給することにより、アウトオブオーダー制御メッセージに伴うコンフリクトが回避される。
【００７７】
上記実施形態の１つ以上と組み合わせられ得る他の実施形態では、アウトオブオーダー制御メッセージに伴うコンフリクトは、制御デバイスが、適合されたコマンド情報及び／又は適合されたタイミング情報を含む、同じ照明器具にアドレス指定される同じ又は変更された制御メッセージを供給するという点で回避される。
【００７８】
このような制御メッセージはネットワークルータに周期的に（又は定期的に）供給され得る。例えば、制御デバイスは更新された制御メッセージを、照明器具のための更新されたコマンドを保持するネットワークルータに比較的頻繁に送信する。これは、例えば先のアウトオブオーダーメッセージ送信のために誤った照明設定が有効である時間を減らす。
【００７９】
上記実施形態において、用語「周期的に」は、制御デバイスが１つだけの更なる（同じ又は変更された）制御メッセージを供給する場合も含む。好ましくは、ネットワークルータは更なる制御メッセージからコマンド情報のコマンドを導出し、先の制御メッセージから導出されたコマンドを更なる制御メッセージから導出されたコマンドによってオーバーライド／置換する。
【００８０】
一例では、制御デバイスは以下の第１の制御メッセージを送信する。
0.0 GET coap://lamp1.domain.example.com/set?lamp=on&color=blue&fade=34
14.0 GET coap://lamp2.domain.example.com/set?lamp=on&color=red&fade=34
25.0 GET coap://lamp1.domain.example.com/set?lamp=off&fade=134
25.0 GET coap://lamp2.domain.example.com/set?lamp=off&fade=134
【００８１】
ある時間の経過後、例えば１５秒後、制御デバイスは以下の更なる制御メッセージを送信する。
20.0 GET coap://lamp1.domain.example.com/set?lamp=on&color=green&fade=34
21.0 GET coap://lamp2.domain.example.com/set?lamp=on&color=green&fade=34
30.0 GET coap://lamp1.domain.example.com/set?lamp=off&fade=134
32.0 GET coap://lamp2.domain.example.com/set?lamp=off&fade=134
【００８２】
上記したように、第１及び更なる制御メッセージの各コマンドに含まれる最初の数字は、各コマンドが指定された照明器具に送られる又は照明器具によって受信されるまでに経過しなければならない秒単位の時間を示す。したがって、更なる制御メッセージは、制御デバイスからネットワークルータまでのネットワークレイテンシが１０秒未満であると仮定すると、おそらく２５秒が経過（第１の制御メッセージ内の最後のコマンド）する前にネットワークルータによって受信される。好ましくは、ネットワークルータは更なる制御メッセージ内で時間値２０．０が最も低いことを認識し（更なる制御メッセージ内の最初のコマンド）、これはスケジュールされている２５．０より低く、よって、ネットワークルータは時間値２０．０より後のスケジュールイベントを全て除去する。この実施形態では、ネットワークルータは更なる制御メッセージ（すなわち、更なるスケジュール）が先の制御メッセージ（すなわち、先のスケジュール）を更新すると仮定する。
【００８３】
他の好適な実施形態では、制御デバイスによって送信される追加の制御メッセージがネットワークルータへの命令を更に含み、命令はネットワークルータに、先に受信されてまだ実行されていない制御メッセージ内に含まれていたあらゆるコマンドを置換させる。
【００８４】
例えば制御ネットワーク内のコンポーネントのエラーにより、後の制御メッセージが永久的に失われる場合、ネットワークルータは好適に、先に受信された制御メッセージを依然として実行／処理できる。制御メッセージ内に含まれる最後のコマンドが消灯コマンドであることが好ましいことに留意されたい。上記例では、すなわち照明器具“ｌａｍｐ１”及び“ｌａｍｐ２”が時間ｔ＝２５．０において消灯／ゆっくりとフェードアウトされる。好ましくは制御メッセージ内に定められる、この種の「失敗した場合（if-fail）」挙動は、制御ネットワークエラーが更なる制御メッセージを永久にネットワークルータに到着させなくした後に照明器具が永久に点灯したままになることを回避する。
【００８５】
制御デバイスによって同じ又は変更された制御メッセージをネットワークルータに周期的に供給するステップを含む上記実施形態では、制御デバイスが、先に供給された制御メッセージを後の制御メッセージに再び含めることが好ましい。これは、先の制御メッセージが紛失された又は遅れた場合に対処することを援助する。一例では、先の制御メッセージはシーケンス内で１番目としてラベルされ、以下を含む。
0.0 GET coap://lamp1.domain.example.com/set?lamp=on&color=blue&fade=34
14.0 GET coap://lamp2.domain.example.com/set?lamp=on&color=red&fade=34
25.0 GET coap://lamp1.domain.example.com/set?lamp=off&fade=134
25.0 GET coap://lamp2.domain.example.com/set?lamp=off&fade=134
【００８６】
そして、例えば約１５秒後に送られる後の制御メッセージは、シーケンス内の２番目としてラベルされ、以下を含む。
0.0 GET coap://lamp1.domain.example.com/set?lamp=on&color=blue&fade=34
14.0 GET coap://lamp2.domain.example.com/set?lamp=on&color=red&fade=34
20.0 GET coap://lamp1.domain.example.com/set?lamp=on&color=green&fade=34
21.0 GET coap://lamp2.domain.example.com/set?lamp=on&color=green&fade=34
30.0 GET coap://lamp1.domain.example.com/set?lamp=off&fade=134
32.0 GET coap://lamp2.domain.example.com/set?lamp=off&fade=134
【００８７】
あるいは、アウトオブオーダーメッセージに伴うコンフリクトを回避するために、上記ＵＤＰ通信がＴＣＰ（Transmission Control Protocol）によって置換される。しかし、複数の照明器具のうちの１つ以上がこのようなＴＣＰ通信用に構成されていない可能性がある。
【００８８】
また、ＵＤＰに従って送信された制御メッセージ（例えば、ＣｏＡＰメッセージ）が制御ネットワーク内で紛失される可能性がある。このために、ＣｏＡＰは信頼できるトランスポート形式（例えば、ＣＯＮ（Confirmable）型メッセージ））を定め、宛先（照明器具）はこれに従ってＡＣＫ応答をする。リトライもサポートされる。
【００８９】
制御デバイスによって供給された制御メッセージが制御ネットワーク内で失われた場合（数回リトライした後でも）、制御デバイス内に含まれるＣｏＡＰプロトコルコンポーネントがこの事実を制御デバイス上で動作するアプリケーションに知らせることが好ましい。その後どうするかはアプリケーション次第、すなわち制御デバイスのユーザー次第である。代わりに又は加えて、制御メッセージが失われた場合、ネットワークルータは適切なＣｏＡＰ応答によってこの事実を制御デバイスに通知する。この応答は好ましくは、どの照明器具へのどのコマンドが送信できなかったかを示すペイロードを含む。その後どうするかは制御アプリケーション次第である。
【００９０】
上記によれば、通常、制御メッセージがＵＲＩ（Uniform Resource Identifier）、又はその構成要素、好ましくは組み込みＨＴＴＰ／ＣｏＡＰリクエストを示すＵＲＩ及びタイミング情報を示す値を含むことが好ましい。
【００９１】
照明器具は好ましくは、例えばＨＴＴＰ及び／又はＣｏＡＰを使用するＩＰデバイスである。
【００９２】
本発明の第２の側面によれば、照明システムを動作させるためのコンピュータプログラムが提供される。コンピュータプログラムは、コンピュータプログラムが照明システムを制御するデバイス上で実行されたとき、照明システムに本発明の第１の側面に係る方法のステップを実行させるプログラムコード手段を含む。
【００９３】
本発明の第２の側面のコンピュータプログラムは、他のハードウェアと共に又はその一部として供給される光学記憶媒体又はソリッドステート媒体等の適切な媒体上で記憶又は供給され得るが、インターネット又は他の有線若しくは無線通信システムを介して等、他の形態でも供給され得る。
【００９４】
本発明の第３の側面によれば、複数の照明器具を制御するための照明制御システムが提供される。照明システムは複数の照明器具に結合されるネットワークルータと、制御ネットワークを介してネットワークルータに結合される制御デバイスとを含み、
制御デバイスは、タイミング情報及びコマンド情報を含む制御メッセージを供給し、
ネットワークルータは、
制御ネットワークを介して制御メッセージを受信し、
タイミング情報に基づいて第１の時点を決定し、
コマンド情報に基づいてコマンドを生成し、
決定された第１の時点にて、制御メッセージにおいて識別される複数の照明器具のうちの少なくとも１つにコマンドを送る。
【００９５】
本発明の第４の側面によれば、複数の照明器具を制御するための制御デバイスが提供される。複数の照明器具はネットワークルータを介して制御ネットワークに結合される。制御デバイスは制御ネットワークを介してネットワークルータに結合される。また、制御デバイスは、
タイミング情報及びコマンド情報を含む制御メッセージを供給し、
制御メッセージはネットワークルータによって受信され、ネットワークルータは、タイミング情報に基づいて第１の時点を決定し、コマンド情報に基づいてコマンドを生成し、決定された第１の時点にて、制御メッセージにおいて識別される複数の照明器具のうちの少なくとも１つにコマンドを送り得る。
【００９６】
本発明の第５の側面によれば、複数の照明器具を制御するためのネットワークルータが提供される。複数の照明器具はネットワークルータを介して制御ネットワークに結合される。制御デバイスが制御ネットワークを介してネットワークルータに結合される。ネットワークルータは、
制御デバイスによって供給され、タイミング情報及びコマンド情報を含む制御メッセージを制御ネットワークを介して受信し、
タイミング情報に基づいて第１の時点を決定し、
コマンド情報に基づいてコマンドを生成し、
決定された第１の時点にて、制御メッセージにおいて識別される複数の照明器具のうちの少なくとも１つにコマンドを送る。
【００９７】
本発明の更なる側面に係るコンピュータプログラム、照明制御システム、制御デバイス、及びネットワークルータは、本発明の第１の側面に係る方法の利点を共有する。更なる側面に係るコンピュータプログラム、照明制御システム、制御デバイス、及びネットワークルータは、第１の側面の方法に関して説明される、特に従属請求項に記載される実施形態に対応する実施形態を有する。
【００９８】
したがって、ネットワークルータの好適な一実施形態では、ネットワークルータは制御メッセージを受信するよう構成されたネットワークプロキシである／を含む。好ましくは、ネットワークルータは組み込みタイマーを含む。コマンド情報は好ましくはＨＴＴＰリクエスト及び／又はＣｏＡＰリクエストを含む。
【００９９】
一実施形態では、送信コマンドが制御メッセージのタイミング情報内に指定される時点において各照明器具によって受信されるよう、ネットワークルータは、導出されたコマンドを送信するための時点を決定するためにＲＴＴ測定を実施するよう構成される。
【０１００】
本発明は、以下の例示的なネットワーク構成において好適に適用され得る：制御ネットワークは少なくとも部分的にインターネットプロトコルベース制御ネットワークであり、インターネット、イントラネット、モバイル通信ネットワーク、無線及び／若しくは有線制御ネットワーク、並びに／又はこれらの組み合わせのうちの少なくとも１つを含む。制御デバイスは、例えば、パソコン、モバイル端末、ハンドヘルドデバイス、タブレットデバイス、又は携帯電話等の制御ネットワークのサブスクライバー端末である。好ましくは、制御デバイスは制御ネットワークの上流に動作的に接続され、制御ネットワークはネットワークルータの上流に動作的に接続され、ネットワークルータは複数の照明器具の上流に動作的に接続される。
【０１０１】
例えば、制御ネットワークは３Ｇ／４Ｇモバイル通信ネットワーク、イーサネット（登録商標）ＬＡＮ、又はＩＥＥＥ８０２．１５．４ネットワークを含む。制御デバイスは例えばタブレットデバイスである。
【０１０２】
好適な一実施形態では、制御メッセージは、ＨＴＴＰリクエスト、ＨＴＴＰＳリクエスト、ＣｏＡＰリクエスト、ＣｏＡＰＳリクエスト、ＤＴＬＳプロトコルリクエスト、ＵＰｎＰリクエスト、ＷＡＰＩプロトコルリクエスト等のＷｅｂサービスリクエスト、ＳＯＡＰリクエスト、ＵＤＰデータグラム、ＴＣＰセグメント、及び／又はこれらの組み合わせのうちの少なくとも１つを含む。例えば、ＣｏＡＰＳ  ｏｖｅｒ  ＵＤＰが使用される。
【０１０３】
一実施形態では、ネットワークルータはパケットベースネットワーキングシステムを介して複数の照明器具に結合される。好ましくは、コマンド情報から導出されたコマンドの照明器具への送信を改良するために、ネットワークルータはこのパケットベースネットワーキングシステムの特定の特性を利用し又はその上で特定のプロトコルを使用する。
【０１０４】
第１の例では、ネットワークルータは、少なくとも２つの照明器具のためのコマンドをパケットベースネットワーキングシステムに送られる単一のパケットに組み合わせることにより、利用可能なネットワーク帯域をより有効に活用する。特に、ネットワークルータは１つ以上の受信制御メッセージ内に含まれるコマンド情報を使用して、複数の照明器具のうちの少なくとも２つの照明器具のための１つ以上のコマンドを含む単一のパケットを、上記パケットベースネットワーキングシステム上で生成及び送信する。
【０１０５】
一部のパケットベースネットワークでは、少なくとも２つの照明器具が共にこのようなパケットを受信することを保証するために、好ましくはブロードキャスト又はマルチキャストタイプのパケットが使用される。
【０１０６】
他のタイプのネットワークでは、全てのパケットが黙示的にブロードキャスト性質であり、すなわち、パケットベースネットワーク内の全ての関与する照明器具によって受信される。好ましくは、どちらの場合においても、パケットを受信する照明器具は少なくとも部分的にパケットコンテンツを復号し、パケット内にその照明器具宛てのコマンドが存在するか否かを決定する。一部の場合では、例えば、全ての照明器具が同じ時点で消灯されなければならない場合、ネットワークルータは好ましくは、パケットを受信する全ての照明器具においてアクションをトリガーする単一のグローバルコマンドをパケット内に生成する。他の場合では、例えば、同じ時点において第１の照明器具Ｌ１が緑色にならなくてはならず、第２の照明器具Ｌ２が赤色にならなければならない場合、２つのコマンド「L1 turn green（Ｌ１が緑色になる）」及び「L2 turn red（Ｌ２が赤色になる）」が同じパケット内に含まれ得る。
【０１０７】
好ましくは、ネットワークルータは、グループＩＤ又はグループアドレスのシステムを活用することにより送信されるコマンドの数を減らし、ここで、全ての照明器具が自身が所属するグループを決定する情報を備え、照明器具がそのような情報を調べて自身が特定のコマンド、例えば「グループＡが青色になる」等に応じなければならないかを見る。
【０１０８】
第２の例では、ネットワークルータは複数の照明器具のうちの少なくとも２つにコマンドを単一のブロードキャストコマンド又は単一のマルチキャストコマンドとして送信するために、上記パケットベースネットワーキングシステムのブロードキャスト機能又はマルチキャスト機能を使用する。
【０１０９】
ブロードキャスト又はマルチキャストはコマンドをユニキャストを用いて送信するより効率的な可能性があるので、場合によっては有利に使用され得る。一部のネットワーキングシステムでは、ユニキャストではなくブロードキャスト／マルチキャストによってコマンドを送信することにより、ＡＣＫメッセージのトリガリングが回避される。したがって、一部の場合では、コマンドが単一の照明器具のみを対象とし、全ての他の照明器具がコマンドを受信時に破棄するとしても、ＡＣＫメッセージが抑制され、よって伝送媒体の使用時間が減少するので、ブロードキャスト／マルチキャスト機構の使用が依然として有益であり得る。ルータの直近のラジオレンジ外の遠方のノードに到達するためにマルチホップルーティングを使用する無線ネットワークでは、ラジオレンジ内のノードにアクセスするためには（ルーティングされない）ブロードキャスト／マルチキャストメッセージを使用し、ラジオレンジ外のノードに到達するためには（ルーティングされる）ユニキャストを使用することがネットワークルータにとって有益であり得る。
【０１１０】
好ましくは、ネットワークルータは、好適には制御デバイスによる特定の使用パターンに基づき、ブロードキャスト／マルチキャストスタイルコマンド送信の使用と（ＡＣＫが通知される）特定の照明器具のためのユニキャストスタイルコマンド送信の使用との間で動的に切り替わるよう構成される。例えば、制御デバイスが例えば１秒あたり４回光設定を連続的に調整する一連の制御メッセージを送信する場合、ネットワークルータは好ましくは、適用可能なパケットベースネットワークを介する照明器具へのメッセージ伝送のスピードが増すよう、ブロードキャスト／マルチキャストスタイルコマンド送信に切り替わる。
【０１１１】
概して言えば、本発明は「モノのインターネット」と呼ばれるトレンドもサポートし、これは、益々多くの電子デバイスがインターネット接続されていくことを意味する。ＩＰ（Internet Protocol）接続は、インターネットサービス又は接続されている他のモノとのＩＰ上の通信により、製品又は製品のグループに付加価値を与え得る。今日、製品にＴＣＰ／ＩＰ又はＵＤＰ／ＩＰ上のカスタムプロトコルが実装されることもあるが、ＵＰｎＰ、ウェブサービスＡＰＩ（ＷＡＤＬ／ＷＳＤＬ／ＷＳ４Ｄ／ＳＯＡＰ）若しくはＨＴＴＰ、又は資源制約デバイスでの使用のためにはＣｏＡＰ等、より標準化されたアプローチへのトレンドが存在する。本発明の説明において、これらのアプローチはいずれも「ＩＰ制御」と呼ばれ、ＩＰは特にＩＰｖ６又はＩＰｖ４プロトコルであり得る。現在の標準化された接続のベースは多くの場合ＨＴＴＰであり、一方、資源制約デバイスについては、将来ＣｏＡＰがＨＴＴＰに取って代わることが予想される。
【０１１２】
組み込みインターネット接続（embedded internet connectivity）のためには、好ましくはＩＥＴＦ（Internet Engineering Task Force）規格が使用される。
【０１１３】
好適な一実施形態では、照明器具は、ネットワークルータに結合されるＩＥＥＥ８０２．１５．４ベースネットワークにおいて相互接続される。ＣｏＡＰはＩＥＴＦのConstrained Restful Environments (CoRE) Working Groupにおいて標準化されることを述べる。ＣｏＡＰは、ＣｏＡＰ制御メッセージが典型的には単一の８０２．１５．４  １２７バイト無線フレームにフィットするよう、非常にコンパクトなデータフォーマットを達成することを狙う。
【０１１４】
本発明は、特に以下の例示的なアプリケーションにおける使用に適する：オーディオトラックから導出されるイベントによって制御されるダイナミック照明（光及び音楽によるムード）；タブレット（例えば、Ａｎｄｒｏｉｄタブレット）又はホームＰＣ等でプレイされるゲーム内のイベントにマッチするためのダイナミック照明制御；防犯手段としてのホームライトの自然な自動制御；人感センサに基づくホームライトの制御；雰囲気照明シーン、例えばカスタマイズされたディナーモード、リラックスモード、又は読書モード；照明器具がダイナミックに制御されるプロフェッショナル照明システム、例えば、スマートフォンによるオフィス内の照明器具の制御、又は、ＰＣ、タブレット、クラウドサーバ、又は組み込みＩＰコントローラ（ＥＣ）上で動作するオリジナル「クリスマスアプリ」に基づくショッピングセンター内に設置されたＩＰベースＲＧＢ照明の利用；１つ以上の照明器具がダイナミックに制御されるホームライトシステム、例えば、スマートフォンアプリによって音楽と連動して制御される２つの「ＬｉｖｉｎｇＣｏｌｏｒｓ」照明、又は、ＩＰ接続テレビよって制御される部屋幅のＡｍｂｉｌｉｇｈｔエフェクト。
【０１１５】
更に、本発明は以下の特性のうちの１つ以上を備えるコンシューマ及びプロフェッショナル照明システムの両方におけるアプリケーションに特に有用である。
−１つ又は複数の照明器具の動的な及び同時の照明変化が要求される。例：照明変化がゲームにリンクされる及び／又は雰囲気照明が再生中のオーディオ又はビデオコンテンツにリンクされる（例えば、「部屋全体のＡｍｂｉｌｉｇｈｔ」）；又は、ユーザー入力を要する光の創造的アプリケーション、例えば、３Ｇ接続を介してネットワーク接続されるハンドヘルド／タブレットデバイスにより送信されるオペレーター設定に応答するホール内のプロフェッショナルダイナミック照明設備等。
−光設定の変化に関して低レイテンシが好ましいが、必ずしも要求されない。
−高度な同期性が要求される。例：複数の照明が色／強度／設定が好ましくは同じ時点において又は特定のシフトされた時点において変化する。
−時に正確なタイミングが要求される又は好ましい。例：照明カラーが再生中の音楽トラックと同期して正確な時点において変化すべきである；又は、照明が正確な周波数（例えば、４Ｈｚ又は８Ｈｚ）で点灯／消灯することが要求されるが、エフェクトの正確な開始時間はさほど重要ではない「ストロボライト」エフェクトが可能にされる。
−制御アプリケーションから被制御照明へのネットワーク接続がスループット及び／又はレイテンシにおいて制限される。
−制御デバイスが被制御デバイスと直接無線通信しない。制御デバイスからいずれかの宛先デバイス（照明器具）に到達するのに、少なくとも２つのホップが必要とされる。制御デバイスと宛先デバイスとの間の制御ネットワークは、多数のホップ及び予測不能な変動レイテンシを有し得る。例：ＰＣ／スマートフォン／タブレットがＷｉ−Ｆｉインフラを介してＩＥＥＥ８０２．１５．４ＲＦ制御可能照明に間接的に接続され、Ｗｉ−Ｆｉルータにおけるバッファリング問題が時にＷｉ−Ｆｉクライアントへの／からのＩＰパケットのレイテンシに高度なばらつきを生じさせる状況。別例：スマートフォン／タブレットが３Ｇ／ＧＳＭ（登録商標）インフラを介して８０２．１５．４ＲＦ制御可能照明に間接的に接続される同様な状況。
−照明器具へのネットワーク接続が、ＺｉｇＢｅｅ若しくは低帯域幅無線技術にマッピングされたインターネットプロトコルバージョンである６ＬｏＷＰＡＮ（ＩＰｖ６）等の８０２．１５．４ベースプロトコル、又はエンドツーエンド通信原理を支持する同様なパケットベース技術を使用する。ここでの特徴は、照明が遠隔制御される通常のシナリオにおいて、ソース（すなわち、制御デバイス）が複数の宛先（すなわち、制御される照明器具）に独立して伝搬される別々のデータパケットを送信することである。宛先はソースにＡＣＫパケットを返信し、ソースがＡＣＫを受信しない場合、ソースは先のパケットが紛失したとみなし、宛先へのパケットの送信をリトライする。
【０１１６】
特に、本発明はＳＭＩＬ（Synchronized Multimedia Integration Language）とは異なることを理解されたい。この言語は、マルチメディア表現をタイミング情報と共に表すための言語である。ＳＭＩＬプログラム、例えばＳＭＩＬプレイヤーは、例えばユーザーがレンダリングされるべきＳＭＩＬドキュメントをアクティブに選択する特定のホストデバイス上で動作する。その後、ＳＭＩＬドキュメントにおいて定められたメディアオブジェクトが、ＳＭＩＬドキュメントにおいて定められたタイミング情報に従って例えばスクリーン及びスピーカー上にローカルにレンダリングされる。本発明では、遠隔デバイス、すなわち制御デバイスがタイミング情報及びプロトコルリクエストのリスト（すなわち、コマンド情報）を含むデータオブジェクト、すなわち制御メッセージを、何もレンダリングせず単にタイミング情報に従ってプロトコルリクエストを実行するデバイスに送信することが好ましい。
【０１１７】
要約すると、本発明は、１つ以上のＨＴＴＰ又はＣｏＡＰリクエストをタイミング情報と共に組み合わせ得るＨＴＴＰ又はＣｏＡＰリクエストメッセージを定める。メッセージは制御デバイスによって制御ネットワークを介してネットワークプロキシ（すなわち、ネットワークルータ）に送信される。ネットワークプロキシはメッセージを復号し、その後、宛先デバイス、特に照明器具を、ＨＴＴＰ又はＣｏＡＰリクエストを用いて時限態様で制御する。ネットワークプロキシはアプリケーションに依存せず、また、時限リクエストを知らないサードパーティーＨＴＴＰ又はＣｏＡＰベースデバイスの制御を可能にする。ネットワークプロキシの位置を、ネットワークホップ及び／又はネットワークレイテンシの観点から制御される宛先デバイスの「近くに」選択することにより、改良されたタイミングパフォーマンスが得られる。
【０１１８】
また、本発明の好適な実施形態は従属請求項と各独立請求項との任意の組み合わせであり得ることを理解されたい。
【０１１９】
また、照明器具を制御する代わりに、本開示で述べられる制御メッセージ、制御デバイス、ネットワークルータ、及びコンピュータプログラムは、照明システム以外のシステム、すなわち、照明器具以外の宛先デバイスを含むシステムにも好適に用いられ得ることを理解されたい。例えば、照明システムを制御する代わりに、ネットワークルータは生成されたコマンドを１つ以上のハプティック（すなわち、触覚）エフェクト生成デバイス、ウィンドエフェクト生成デバイス、霧生成デバイス、オーディオエフェクト生成デバイス、ヒューマンモーション生成デバイス、ネットワーク制御可能なグラフィクスプレゼンテーションデバイス、ネットワーク制御可能なデジタルメディアレンダラー、及び／又は正確かつ適時に制御されるべき他の宛先デバイスに送信する。したがって、本発明は照明器具の制御に限定されない。
【０１２０】
本発明の上記及び他の側面は、後述される実施形態を参照して説明され、明らかになろう。
【図面の簡単な説明】
【０１２１】
【図１】図１は、本発明の方法の一実施形態によって動作させられ得る照明システムの表現を概略的かつ例示的に示す。
【図２】図２は、本発明の技術的問題を説明するための、アクセスポイントからクライアントへのトリップの間に及びクライアントからアクセスポイントへのトリップの間に生じ得る信号のラウンドトリップタイム（ｐｉｎｇディレイ）の経時的な表現を概略的かつ例示的に示す。
【図３】図３は、本発明の方法の特定の実施形態を説明する制御図の表現を概略的かつ例示的に示す。
【図４Ａ】図４Ａは、本発明に係る制御メッセージの構成を概略的かつ例示的に示す。
【図４Ｂ】図４Ｂは、図４Ａに示される制御メッセージ内に含まれ得るコマンド情報の定義の４つの例を概略的に示す。
【発明を実施するための形態】
【０１２２】
図１は、本発明の方法の一実施形態によって動作させられ得る照明システム１００の表現を概略的かつ例示的に示す。
【０１２３】
照明システム１００は、参照符号Ｌ１、Ｌ２、Ｌ３、及びＬ４によって示される複数の照明器具を含む。例えば、これらの照明器具はＩＥＥＥ８０２．１５．４ベースネットワーク内に配置され、対応するインターフェイスを呈する。
【０１２４】
照明器具Ｌ１、Ｌ２、Ｌ３、及びＬ４はネットワークルータ１１２、例えばネットワークプロキシを含む６ＬｏＷＰＡＮルータに接続される。照明器具Ｌ１、Ｌ２、Ｌ３、及びＬ４は制御デバイス１３２によって制御される。
【０１２５】
ネットワークルータ１１２と制御デバイス１３２とは制御ネットワーク１２０を介して互いに結合される。このような制御ネットワークは、複数のネットワークホップを呈する比較的大きな異種制御ネットワークであり、制御ネットワーク１２０を横断する信号は、変動するレイテンシを呈する可能性が高い。
【０１２６】
図示の例では、制御ネットワーク１２０は３Ｇ／４Ｇネットワーク若しくはＩＥＥＥ８０２．１１ｎベースネットワーク等の無線通信ネットワーク１２６、インターネット１２４、及び社内イントラネット１２２を含む。したがって、制御デバイス１３２は携帯電話、タブレットデバイス、ノートブック、ＰＤＡ（Personal Digital Assistant）、ＩＥＥＥ８０２．１１ｎクライアントデバイス等のユーザーによって操作されるモバイル端末であり得る。
【０１２７】
言い換えれば、照明器具Ｌ１、Ｌ２、Ｌ３、及びＬ４を制御するための制御デバイス１３２は、制御ネットワーク１２０のサブスクライバー端末である。制御デバイス１３２は制御ネットワーク１２０の上流に動作的に接続され、制御ネットワーク１２０はネットワークルータ１１２の上流に動作的に接続される。ネットワークルータ１１２は複数の照明器具Ｌ１、Ｌ２、Ｌ３、及びＬ４の上流に動作的に接続される。例えば、本発明の第２の側面のコンピュータプログラムは部分的に制御デバイス１３２上で動作し、部分的にネットワークルータ１１２上で動作する。
【０１２８】
本発明の技術的問題を説明するために、図２は、穏やかな負荷条件下で従来のＩＥＥＥ８０２．１１ｎルータにおいて生じ得る、経時的に測定されたラウンドトリップタイム（ｐｉｎｇディレイ又はラウンドトリップディレイとも知られる）の表現を概略的かつ例示的に示す。このようなルータは制御ネットワーク１２０の一部であり得る。
【０１２９】
図２において、縦軸はミリ秒単位のＲＴＴを示し、横軸は秒単位の時間を示す。実線はアクセスポイントからクライアントに送信された信号の経時的なＲＴＴを示し、破線はクライアントからアクセスポイントに送信された信号に関して生じるＲＴＴを示す。
【０１３０】
制御ネットワーク１２０内で生じ得る予測不能なネットワークトラフィックのため、及び、ネットワークホップの数が大きくかつ変動するため、ＲＴＴは時間と共に大きく変化し、例えば、第１の時点で送信された信号が第２の時点で送信された信号より数秒はやい可能性がある。しかし、ＲＴＴの変動には多くの他の原因が存在する。
【０１３１】
特に、図２によれば、ＲＴＴは周期的に約６秒のピークに達する。
【０１３２】
この現象のため、図１に例示的に示されるようなシナリオにおける正確なタイミング制御は、従来技術の教示によっては不可能である。
【０１３３】
変動するネットワークレイテンシ、ネットワークホップ等に対処するために、制御デバイス１３２は、タイミング情報及びコマンド情報を含む制御メッセージを供給する。制御メッセージは制御ネットワークを介してネットワークルータ１１２によって受信される。ネットワーク１１２はタイミング情報に基づいて第１の時点を決定する。また、ネットワークルータ１１２はコマンド情報に基づいてコマンドを生成する。その後、ネットワークルータ１１２は決定された第１の時点にて、制御メッセージにおいて識別される複数の照明器具Ｌ１、Ｌ２、Ｌ３、Ｌ４のうちの少なくとも１つにコマンドを送る。
【０１３４】
上記を図３に例示的に示す。図示の例において、制御デバイス１３２によって供給される制御メッセージは３つのコマンドＣ１、Ｃ２、及びＣ３を含む。これらのコマンドは例えばＨＴＴＰリクエスト又はＣｏＡＰリクエストであり得る。リクエストごとに、制御メッセージ内にタイミング情報が含まれている。このタイミング情報は、どの時点で各コマンドが識別された照明器具に送られるべきか、又は、どの時点で各コマンドが識別された照明器具によって受信されるべきかを指定する。例えば、図３に従って処理される制御メッセージは以下を含むペイロードを有する。
0.0 GET coap://lamp1.domain.example.com/set?level=23&status=on
2.0 GET coap://lamp2.domain.example.com/set?level=13&status=on
2.0 GET coap://lamp3.domain.example.com/set?level=17&status=on&color=0xFF0101
【０１３５】
この例によれば、タイミング情報は秒を示す浮動小数点値によって表される（０．０／２．０／２．０）。小数点値の後にはスペースが続き、その後にはＣｏＡＰリクエストコード（“ＧＥＴ”）が続き、その後にはＣｏＡＰリクエストがされるべき照明器具を識別するＵＲＩが続く。
【０１３６】
したがって、このような制御メッセージを受信すると、ネットワークルータ１１２はタイマーを設定し（ステップ３１０）、タイミング情報“０．０”は関連付けられたコマンド
0.0 GET coap://lamp1.domain.example.com/set?level=23&status=on
ができるだけ早く送られるべきことを示すため、直後に点灯コマンドである第１のコマンドＣ１を第１の照明器具Ｌ１（“ｌａｍｐ１”）に送る。
【０１３７】
その後、ネットワークルータ１１２はコマンドＣ１が送られたことを制御デバイス１３２に示す。典型的には、制御メッセージ内に含まれるコマンド情報を受信及び処理した後、ネットワークルータ１１２はＨＴＴＰ又はＣｏＡＰ応答を送る。このような応答は、（図３に示されるように）“ＯＫ”又はエラーコードであり得る。オプションで、ネットワークルータ１１２はより後の時点において、照明器具Ｌ１、Ｌ２、Ｌ３、及び／又はＬ４に送られたコマンドの結果を制御デバイス１３２に送り返してもよい。
【０１３８】
一方、照明設定変化ライン３２０によって示されるように、照明器具Ｌ１は自身が点灯されたことをネットワークルータ１１２に通知する。
【０１３９】
ネットワークルータ１１２はタイマーの設定後２秒（“２．０”）経過するまで待ち（ステップ３３０）、即座にコマンドＣ２を照明器具Ｌ２に及びコマンドＣ３を照明器具Ｌ３に送る。照明器具Ｌ２及びＬ３は、各自の設定が照明設定変化ライン３４０によって示されるようにコマンドに従って変更されたことをネットワークルータ１１２に通知する。
【０１４０】
図４Ａは、本発明に係る制御メッセージ４００のセットアップを概略的かつ例示的に示す。
【０１４１】
制御メッセージ４００はＩＰヘッダー４１０、ＨＴＴＰヘッダー又はＣｏＡＰヘッダー等のプロトコルヘッダー４２０、及び制御メッセージペイロードセクション４３０を含む。
【０１４２】
ペイロードセクション４３０は、複数のコマンド４３４−１〜４３４−Ｎを指定するコマンド情報と、ネットワークルータ１１２が関連付けられたコマンドを送るべき又は関連付けられたコマンドが識別される照明器具によって受信されるべき時点４３２−１〜４３２−Ｎを指定する関連付けられたタイミング情報との両方を含む。
【０１４３】
図４Ｂは、図４Ａに示される制御メッセージ内に含まれ得るコマンド情報の定義の４つの例を概略的に示す。
【０１４４】
第１の例では、コマンド情報４３４Ａは、ＵＤＰ（User Datagram Protocol）ヘッダー、ＨＴＴＰヘッダー、又はＣｏＡＰヘッダー等の少なくとも１つのプロトコルヘッダー４３４Ａ１によって定められ、１つ以上の照明器具Ｌ１、Ｌ２、Ｌ３、及びＬ４を識別する識別子がその中に含まれる。コマンド情報４３４Ａは更に、実際のコマンド（例えば、“ｏｎ”、“ｏｆｆ”、“強度＝４”、“ディミング＝ｏｎ”等）が含まれるコマンドペイロードセクション４３４Ａ２によって定められる。
【０１４５】
第２の例では、コマンド情報４３４Ｂは、実質的に全体としてコマンドＵＲＬ（Uniform Resource Locator）に符号化される。このようなＵＲＬは、例えば“coap://lamp1.domain.example.com/set?level=23&status=on”のようであり得る。このようなＵＲＬは、コマンドが送られるべき照明器具を識別する識別子を更に含む。
【０１４６】
第３の例では、コマンド情報４３４Ｃは、“ＧＥＴ”、“ＰＵＴ”、“ＰＯＳＴ”、“ＤＥＬＥＴＥ”などのＣｏＡＰ／ＨＴＴＰリクエスト等、コマンド情報内に含まれるコマンドタイプを指定する指定フィールド４３４Ｃ１によって定められる。このようなコマンド情報４３４Ｃは、更に、ＵＲＬ４３４Ｃ２及びペイロードセクション４３４Ｃ３によって定められる。ペイロードセクション４３４Ｃ３は、調光時間間隔、光強度値、色値等の更なる特定の照明制御コマンドを組み込むことを可能にする。この例では、識別子もＵＲＬ４３４Ｃ２内に含まれている。
【０１４７】
第４の例では、コマンド情報４３４Ｄは、“ＧＥＴ”、“ＰＵＴ”、“ＰＯＳＴ”、“ＤＥＬＥＴＥ”などのＣｏＡＰ／ＨＴＴＰリクエスト等、コマンド情報内に含まれるコマンドタイプを指定する指定フィールド４３４Ｄ１によって定められる。しかし、第３の例とは異なり、識別子はＵＲＬ内に含まれておらず、コマンド情報４３４Ｄは、ＩＰアドレス又はＩＰホスト名等の明示的なターゲットデバイス識別子４３４Ｄ２によって更に定められる。したがって、完全なＵＲＬを提供する代わりに、例えばＵＲＬパス４３４Ｄ３のみが、及びオプションでＵＲＬクエリパラメータが提供される。第２の例と比較すると、このようなＵＲＬパスは例えば“set/lamp/1”のようであり得る。更に、コマンド情報４３４Ｄは、例えば“level=23;status=on;color=1234”によって示されるコマンドを含み得るペイロードセクション４３４Ｄ４によって定められる。
【０１４８】
上記実施形態では、照明システムはＩＥＥＥ８０２．１５．４ベースネットワーク内に配置される４つの照明器具を含んだ。当然ながら、本発明はこのような構成に限定されず、照明器具が４つより多い又は少ない場合、及び、照明器具が異なるネットワーク内に配置される場合にも適用され得る。
【０１４９】
上記実施形態では、制御されるデバイスは照明器具である。しかし、本発明は照明器具の制御に限定されない。原則的に、本発明の主題（制御方法／システム、コンピュータプログラム、ネットワークルータ、及び制御デバイス）はあらゆる種類の宛先デバイスを制御し得る。代替的な宛先デバイスの例は上記で挙げられている。
【０１５０】
また、各図面の要素の配置は、主に説得力のある説明の目的に従うものであり、本発明に従って製造されたデバイスの部品の如何なる実際の幾何学的配置にも関係しないことを理解されたい。
【０１５１】
特許請求の範囲において、用語「含む（又は備える若しくは有する等）」は他の要素又はステップを除外せず、要素は複数を除外しない。
【０１５２】
単一のユニット又はデバイスが、請求項内に記載される複数のアイテムの機能を果たし得る。
【０１５３】
請求項内の如何なる参照符号も特許請求の範囲を限定するものと解されるべきではない。
【図１】
0006461791.tif 000002
【図２】
0006461791.tif 000003
【図３】
0006461791.tif 000004
【図４Ａ】
0006461791.tif 000005
【図４Ｂ】
0006461791.tif 000006