(57)【要約】本発明は、ネットワーク間のブリッジングに関する。一つのネットワークは複数のサブデバイスを有する複合デバイスタイプを使用する。ブリッジデバイス（２０６）は、第１のネットワークデバイス（２０２）からのデバイス記述問合せに応答して、そのデバイスタイプを複合デバイスタイプとして示すとともに第２のネットワーク内のデバイスの数であるサブデバイスの数を示すメッセージで応答する。
2005535246.tif 000002
【特許請求の範囲】
【請求項１】
第１のネットワーク内に複数の第１のネットワークデバイスが存在し、第２のネットワーク内に複数の第２のネットワークデバイスが存在し、前記ネットワークデバイスの一つが前記第１及び第２の両ネットワーク内のブリッジデバイスであり、前記第１のネットワークが、複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、且つ前記第１のネットワーク内のデバイスが、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっている第１及び第２のネットワーク間のブリッジデバイスをオペレートする方法であって、該方法は、
前記ブリッジデバイスにおいて前記第１のネットワークからのデバイス記述問合せを受信し、
前記デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第２のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第１のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、
該更なるデバイス記述問合せに対して、前記他のデバイスの記述を含むデバイス記述メッセージで応答し、
第１のネットワークにおいて第２のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第１のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第１のネットワーク内のネットワークデバイスには第２のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスとして見えるようにすることを特徴とするブリッジデバイスオペレーティング方法。
【請求項２】
前記第２のネットワーク内のデバイスの数が変化し、前記第２のネットワーク内のデバイスの数を表す前記値が前記第２のネットワーク内のデバイスの数の瞬時値であることを特徴とする請求項１記載の方法。
【請求項３】
当該方法は、更に、前記ブリッジデバイスにおいて前記第２のネットワークからのデバイス記述問合せを受信し、
該デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第１のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第２のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、
該更なるデバイス記述問合せに対して、前記他のデバイスの記述を含むデバイス記述メッセージで応答し、
第２のネットワークにおいて第１のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第２のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第２のネットワーク内のネットワークデバイスには第１のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスとして見えるようにすることを特徴とする請求項１又は２記載の方法。
【請求項４】
第１のネットワーク内に複数の第１のネットワークデバイスが存在し、第２のネットワーク内に複数の第２のネットワークデバイスが存在し、前記第１のネットワークが、複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、且つ前記第１のネットワーク内のデバイスが、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっている第１及び第２のネットワーク間のブリッジングデバイスであって、該ブリッジデバイスは、
前記第１のネットワーク内の他のデバイスと通信するトランシーバと、
前記第２のネットワーク内の他のデバイスと通信するトランシーバと、
メッセージハンドラとを具え、該メッセージハンドラは、
前記ブリッジデバイスにおいて前記第１のネットワークからのデバイス記述問合せを受信し、前記デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第２のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第１のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、該更なるデバイス記述問合せに対して、前記他のデバイスの記述を対応するサブデバイスとして含むデバイス記述メッセージで応答し、
第１のネットワークにおいて第２のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第１のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第１のネットワーク内のネットワークデバイスには第２のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスとして見えるように構成されていることを特徴とするブリッジデバイス。
【請求項５】
前記第２のネットワーク内のデバイスの数が一定でなく、前記ブリッジデバイスは、前記第１のネットワークからのデバイス記述問合せに対して、前記第２のネットワーク内のデバイスの瞬間的な数で応答するよう構成されていることを特徴とする請求項４記載のブリッジデバイス。
【請求項６】
前記メッセージハンドラは、
前記ブリッジデバイスにおいて前記第２のネットワークからのデバイス記述問合せを受信し、該デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第１のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第２のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、該更なるデバイス記述問合せに対して、前記他のデバイスの記述を対応するサブデバイスとして含むデバイス記述メッセージで応答し、
第２のネットワークにおいて第１のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第２のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第２のネットワーク内のネットワークデバイスには第１のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスとして見えるようにすることを特徴とする請求項４又は５記載のブリッジデバイス。
【請求項７】
複数の第１のネットワークデバイスを含む第１のネットワークであって、該ネットワークは複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、該ネットワーク内のデバイスは、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっている第１のネットワークと、
複数の第２のネットワークデバイスを第２のネットワークデバイスを含む第２のネットワークとを具え、
前記ネットワークデバイスの１つが前記第１及び第２の両ネットワーク内のブリッジデバイスであるネットワークシステムにおいて、前記ブリッジデバイスは、
前記第１のネットワーク内の他のデバイスと通信するトランシーバと、
前記第２のネットワーク内の他のデバイスと通信するトランシーバと、
メッセージハンドラとを具え、該メッセージハンドラは、
前記ブリッジデバイスにおいて前記第１のネットワークからのデバイス記述問合せを受信し、前記デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第２のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第１のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、該更なるデバイス記述問合せに対して、前記他のデバイスの記述を対応するサブデバイスとして含むデバイス記述メッセージで応答し、
第１のネットワークにおいて第２のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第１のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第１のネットワーク内のネットワークデバイスには第２のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスとして見えるように構成されていることを特徴とするシステム。
【請求項８】
前記第２のネットワーク内のデバイスの数が一定でなく、前記ブリッジデバイスは、前記第１のネットワークからのデバイス記述問合せに対して、前記第２のネットワーク内のデバイスの瞬間的な数で応答するよう構成されていることを特徴とする請求項７記載のシステム。
【請求項９】
前記第２のネットワークは、複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、且つ前記第２のネットワーク内のデバイスは、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっており、
前記メッセージハンドラは、
前記ブリッジデバイスにおいて前記第２のネットワークからのデバイス記述問合せを受信し、該デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第１のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第２のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、該更なるデバイス記述問合せに対して、前記他のデバイスの記述を対応するサブデバイスとして含むデバイス記述メッセージで応答し、
第２のネットワークにおいて第１のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第２のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第２のネットワーク内のネットワークデバイスには第１のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスとして見えるように構成されていることを特徴とする請求項７又は８記載のシステム。
【請求項１０】
請求項１，２、又は３に記載の方法を実行するようにブリッジデバイスを制御するためのコントローラプログラム。
【請求項１１】
請求項１０に記載のコンピュータプログラムを記録した記録担体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークプロトコル、特に該プロトコルの実施に関するものである。
【背景技術】
【０００２】
ネットワーク管理用の従来のプロトコルはユニバーサルプラグアンドプレイ（ＵＰｎＰ）であり、このプロトコルはインターネットアプリケーションに極めて有用であって、帯域幅、電池消費及びコストが問題にならない。コンシューマエレクトロニクス（ＣＥ）においてこのプロトコルは実施されているが、プロトコルの広範性のために、このような実施は最小の処理能力を必要とする最も簡単なデバイスに特に重い負荷を課すことになる。
【０００３】
従って、ライト(電灯)、サーモスタット及びＣＥ機器（ＴＶ，ＤＶＤ及びＰＶＲ用のリモートコントロール）のような簡単なデバイスに組み込むのに好適なプロトコル、即ち簡単且つコストエフェクティブに実施可能であって最小の帯域幅を必要とし、しかも種々の能力を有する一連のデバイスに対してスケーラブルであるプロトコルが必要とされている。
【０００４】
この必要性は無線アプリケーションに限定されず、有線アプリケーションにも及ぶ。
【発明の開示】
【０００５】
第１の態様では、本発明は、第１のネットワーク内に複数の第１のネットワークデバイスが存在し、第２のネットワーク内に複数の第２のネットワークデバイスが存在し、前記ネットワークデバイスの一つが前記第１及び第２の両ネットワーク内のブリッジデバイスであり、前記第１のネットワークが、複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、且つ前記第１のネットワーク内のデバイスが、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっている第１及び第２のネットワーク間のブリッジデバイスをオペレートする方法に関し、該方法は、
前記ブリッジデバイスにおいて前記第１のネットワークからのデバイス記述問合せを受信し、
前記デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第２のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第１のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、
該更なるデバイス記述問合せに対して、前記他のデバイスの記述を含むデバイス記述メッセージで応答し、
第１のネットワークにおいて第２のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第１のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第１のネットワーク内のネットワークデバイスには第２のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスと見えるようにすることを特徴とする。
【０００６】
本発明によれば、第１のネットワーク内のデバイスは第２のネットワーク内のデバイスをアクセスする極めて簡単な方法として作用する複合デバイスタイプを用いる。第１ネットワークにはブリッジは単に複合デバイスのように見え、第２のネットワーク内の個々のデバイスはブリッジのサブデバイスのように見える。従って、第１のネットワーク内の殆どのデバイスは第２のネットワーク内のデバイスに容易にアクセスすることができる。最下位レベルではブリッジは各ネットワーク上で単一の物理アドレスとして現れる。デバイスがブリッジアドレスを発見すると、このデバイスは最初に、いつものように、「Get Simple Device Description」要求によりデバイス情報を要求する。ブリッジは、この要求に直接応答し、自身を複合デバイスとして識別し、ブリッジの「反対側」に位置するデバイスの数をリターンする。
【０００７】
次に、更なる問合せをブリッジに対して、それがあたかも任意の他の複合デバイスであるかのように行い、「擬似」内蔵デバイスの各々に対するシンプルデバイス記述を要求する。この要求及びそれに続くコマンドは全てブリッジ内の特定内蔵デバイスに対するものであると識別されるが、それらはブリッジにより「反対側」に位置する特定デバイスに転送される。
【０００８】
ブリッジは、それが含む内蔵デバイスの数が変化し得るためにノーマル複合デバイスではなく、ダイナミック複合デバイスである。ブリッジは「Get Simple Description」要求に対する標準応答の一部分として内蔵デバイスの数を識別するが、これはブリッジの反対側に位置するデバイスの瞬間的な数である。ダイナミック複合デバイスは反対側のデバイスの数を識別する属性も公開するため、第１ネットワーク内のデバイスは任意の瞬時にこれを問い合わせることができる。ブリッジがイベントサブスクリプションをサポートする場合には、デバイスの数が変化するとき属性の変化が通知されるために、デバイスは属性の変化を承認することもできる。
【０００９】
実施例では、本特許出願並びに同じ最先の優先権を主張する他の出願に記載されているプロトコルを用いる。このプロトコル自体はホームユニフォームコントロールランゲージ（ＨＵＣＬ）と呼ばれている。
【００１０】
本特許出願は、特にブリッジング、即ちネットワーク間のリンクに関するものであり、それらのネットワークがＨＵＣＬネットワークであるか否かは問わない。
【００１１】
実施例では、本発明の方法は、
更に、前記ブリッジデバイスにおいて前記第２のネットワークからのデバイス記述問合せを受信し、
該デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第１のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第２のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、
該更なるデバイス記述問合せに対して、前記他のデバイスの記述を含むデバイス記述メッセージで応答し、
第２のネットワークにおいて第１のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第２のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第２のネットワーク内のネットワークデバイスには第１のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスと見えるようにすることを特徴とする。
【００１２】
他の態様では、本発明は、第１のネットワーク内に複数の第１のネットワークデバイスが存在し、第２のネットワーク内に複数の第２のネットワークデバイスが存在し、前記第１のネットワークが、複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、且つ前記第１のネットワーク内のデバイスが、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっている第１及び第２のネットワークをリンクするブリッジングデバイスに関し、該ブリッジデバイスは、
前記第１のネットワーク内の他のデバイスと通信するトランシーバと、
前記第２のネットワーク内の他のデバイスと通信するトランシーバと、
メッセージハンドラとを具え、該メッセージハンドラは、
前記ブリッジデバイスにおいて前記第１のネットワークからのデバイス記述問合せを受信し、前記デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第２のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第１のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、該更なるデバイス記述問合せに対して、前記他のデバイスの記述を対応するサブデバイスとして含むデバイス記述メッセージで応答し、
第１のネットワークにおいて第２のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第１のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第１のネットワーク内のネットワークデバイスには第２のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスと見えるように構成されていることを特徴とする。
【００１３】
実施例では、第１及び第２のネットワークに接続するためのトランシーバは別個であるが、他の構成では、これらのトランシーバはいくつかのコンポーネント、例えば単一のアンテナを共用することができ、また両ネットワークとの無線周波数通信に対し１つのトランシーバを使用することもできる。
【００１４】
更に他の態様では、本発明は、複数の第１のネットワークデバイスを含む第１のネットワークであって、該ネットワークは複数のサブデバイスを有する複合デバイスタイプを含む複数のデバイスタイプの１つとして前記ネットワークデバイスのデバイス記述を含むメッセージ信号を用い、該ネットワーク内のデバイスは、個々のサブデバイスに関する更なるデバイス問合せを送り、個々のサブデバイスに関する情報を複合デバイスから受信することによって、複合デバイスについて更なる情報を発見するようになっている第１のネットワークと、
複数の第２のネットワークデバイスを第２のネットワークデバイスを含む第２のネットワークとを具え、
前記ネットワークデバイスの１つが前記第１及び第２の両ネットワーク内のブリッジデバイスであるネットワークシステムに関し、
前記ブリッジデバイスは、
前記第１のネットワーク内の他のデバイスと通信するトランシーバと、
前記第２のネットワーク内の他のデバイスと通信するトランシーバと、
メッセージハンドラとを具え、
該メッセージハンドラは、
前記ブリッジデバイスにおいて前記第１のネットワークからのデバイス記述問合せを受信し、前記デバイス記述問合せに対して、前記ブリッジデバイスの記述を複合デバイスタイプ及び前記第２のネットワーク内の他のデバイスの数を表す値として含むデバイス記述メッセージで応答し、
前記第１のネットワーク内のデバイスからの前記他のデバイスの１つに関する少なくとも１つの更なるデバイス記述問合せを受信し、該更なるデバイス記述問合せに対して、前記他のデバイスの記述を対応するサブデバイスとして含むデバイス記述メッセージで応答し、
第１のネットワークにおいて第２のネットワーク内のデバイスへの又はからの更なるメッセージをそれぞれ第１のネットワーク内のデバイスから又はへと、ブリッジデバイスの各サブデバイスへの又はからのメッセージとして転送して、第１のネットワーク内のネットワークデバイスには第２のネットワーク内のネットワークデバイスが複合デバイスタイプのブリッジデバイスのサブデバイスと見えるように構成されていることを特徴とする。
【００１５】
第２のネットワーク内のデバイスの数は一定にならないので、前記ブリッジデバイスは、前記第１のネットワークからのデバイス記述問合せに対して、前記第２のネットワーク内のデバイスの瞬間的な数で応答するよう構成することができる。
【００１６】
本発明は上述した方法を実行するようにブリッジデバイスを制御するためのコントローラプログラム及び該コンピュータプログラムを記録した記録担体にも関するものである。
【００１７】
本発明のより良い理解のために、図面を参照して複数の実施例について説明するが、これらは純粋に一例にすぎない。
【００１８】
本発明はブリッジ方法及び装置に関するものであるが、これらの方法及び装置について説明する前に、ＨＵＣＬプロトコル及び対応するデバイス、信号及び方法の詳細について図１−１０及び図１５を参照して説明する。
【００１９】
プロトコルＨＵＣＬは主として無線システム用に設計された軽量、低帯域幅制御プロトコルである。メッセージングフォーマットはＸＭＬに基づき、メッセージは伝送前に圧縮される。ＸＭＬの使用は、送出データを低減し、送信機のオン時間及び消費電力を低減する圧縮を具えた拡張可能でスケーラブルな解決を提供する。
【００２０】
ＨＵＣＬプロトコルの一般原理と、該プロトコルがデバイスをどのようにオペレートするかを簡単な例について以下に説明する。
【００２１】
図１において、ライトスイッチ２及び照明器具４が設けられている。ライトスイッチ２は、ユーザにより駆動される物理的ロッカースイッチ６と、制御回路１２及びメモリ１４を有するＲＦトランシーバ８及び電池１０とを備える。照明器具も、主電源で給電されるＲＦトランシーバ８及びメモリ１４を備えるとともに、電球２２に電力を供給する制御回路２０を備える。従って、ライトスイッチ２は制御入力６(スイッチ)を有するコントローラの一例であり、照明器具は被制御デバイス４の一例である。コントローラ内のメモリ１４は、該コントローラが制御し得るデバイスタイプ及びデバイスタイプに関する制御機能のリスト２４を含む。被制御デバイス４及びコントローラ２内のメモリ１４は制御回路に以下に詳細に説明する方法を実行させるためのコード２６も含む。
【００２２】
図２はメモリ１４内のデバイスの各々に存在するソフトウエアの構成の概略を示す。制御アプリケーション３０は所定のイベントが生起するときＨＵＣＬソフトウエアスタック３２と通信する。
【００２３】
同様に、ＨＵＣＬソフトウエアスタック３２はＲＦソフトウエアスタック３４と通信し、ＲＦソフトウエアスタック３４は、所定のイベントが例えばデータ受信時に生起するとき、ＨＵＣＬソフトウエアスタック３２と逆方向に通信する。
【００２４】
メッセージ３６が送受される。メッセージは、シンプルデバイス記述問合せメッセージを含む複数のタイプのもの、又は複数の他のメッセージタイプの任意のものとすることができる。
【００２５】
デバイスの動作を図３を参照して説明する。この一対のデバイスの動作における第１フェーズは、スイッチが器具のアドレスを発見することである。これはデバイス発見として既知であり、基礎ＲＦトランスポートスタックの要件は、デバイス発見を（ＲＦソフトウエアスタックに）付与する、又はデバイス発見をトランスポートスタック（ＨＵＣＬソフトウエアスタックの下位層）の上で実行可能にすることである。
【００２６】
発見プロセスは、制御アプリケーションによって、最初に、知っているデバイスの数を要求し、次いでこれらのデバイスのネットワークアドレスを要求するＨＵＣＬソフトウエアスタックへのコールを実行することにより開始される(ステップ１００)。これらのデバイスアドレスがリターンされる。
【００２７】
基礎ＲＦプロトコルに基づいて、ネットワークアドレスは他の方法で設定することもできる。
【００２８】
デバイス発見フェーズの最終結果は、制御アプリケーションに、ＲＦスタックにより知られた全てのデバイスのアドレスのリストが供給されることになる(ステップ１０２)。プロセスのこの時点において、制御アプリケーションは各デバイスについてそのアドレス以外は何も知らない。
【００２９】
ペアリングプロセスにおける第２フェーズは、制御アプリケーションがアドレスを有するデバイスについての情報を収集することにある。この情報はデバイス記述という。制御アプリケーションは、これを、ＨＵＣＬソフトウエアスタックへのコールを行い、デバイス記述を必要とするデバイスのアドレスを渡すことにより行う。
【００３０】
次いで、このシンプルデバイス記述（ＳＤＤ）の要求はＲＦリンクを経てあて先デバイスに送られ、上述のスイッチ／器具の例では、この要求はスイッチから器具へ伝送される(ステップ１０４)。この要求の受信時に、あて先デバイスにおけるＨＵＣＬソフトウエアスタックは制御アプリケーションに対して、デバイス記述を要求するコールを行う。この記述のフォーマットは定義されている。まだ圧縮フォームでない場合には、この記述は前記要求の発信者へ送り返す前に圧縮する。
【００３１】
要求デバイスにおけるＨＵＣＬソフトウエアスタックがデバイス記述を受信すると(ステップ１０６)、このデバイス記述は制御アプリケーションへ渡される。この時点において、アプリケーションはこのデバイスについての基本情報を持ち、これがこのデバイスと更に通信をしたいかについて決定を行うことができる。
【００３２】
ＨＵＣＬの設計目標は極めて簡単なデバイスをオペレートするのに好適とすることにあるが、デバイスを完全に記述するのに必要な情報が潜在的に極めて複雑である。以下のリストは、デバイスがその記述の一部として付与したい情報の例を示す。
デバイスタイプ  例えばＤＶＤ
ベンダーネーム  例えばＰｈｉｌｉｐｓ
モデルナンバ    例えばＤＶＤ１０１０／００２
シリアルナンバ  例えばＡＨ０６８４８０３２３４５
ベンダーＵＲＬ  例えばwww.philips.com
【００３３】
制御デバイスの最も簡単なもの、例えばこのセクションにおける上記の例で使用されるスイッチの場合には、この情報の大半はおそらく冗長である。しかし、スクリーンを有する「ＰＤＡ」タイプのリモートコントロール（以下リモコンと略記する）のようなハイエンドデバイスではこのような情報をユーザに表示させることができる。
【００３４】
ロウエンドデバイスにおけるこのような記述の処理は問題を生じ得る。その理由は、メッセージの受信時に完全なメッセージをキャッシュするために潜在的に記憶装置（ＲＡＭ）を必要とするためである。この問題は最初に思った以上に悪いものである。その理由は、上に示した記述データの総合サイズは不確定であり、情報の大半は「フリーテキスト」であるためである。ベンダーネームはきわめて長くなりうるとともに、ＵＲＬは正確なページを指定することができ、パラメータを有することもある。例えば
http://www.consumer.philips.com/global/b2c/ce/catalog/subcategory.jhtml?groupld=VIDEO&divld=0&catld=DVD&subCatld=DVDPLAYER
【００３５】
この問題をＨＵＣＬで解決する方法は、デバイス記述を２段階の情報に分割するものである。第１段階はデバイスの簡単化された記述であるが、更なる情報が使用可能である場合にはこれを識別するものである。この第１段階の情報はフリーテキストを含まないので、その全長は確定的である。第２段階の拡張情報はオプションであり、追加の情報を付与する。
【００３６】
図１５を参照して説明すると、シンプルデバイス記述（ＳＤＤ：Simple Device Description）メッセージ ２３０は、フィールドとして、デバイスタイプ２３２、拡張デバイス記述（ＥＤＤ：Extended Device Description）が使用可能かを示すフィールド２３８及びキー情報、例えばイベントサブスクリプションが使用可能かを示すフラグを識別する他のフィールド２３６を含む。オプションの整数フィールド２３４は複合デバイスのサブデバイスの数を表す。当業者に知られているように、メッセージ２３０はヘッダとフッタも含むが、簡単のために省略されている。このメッセージは、圧縮ＸＭＬトークンも含むが、同様に明瞭のために省略されている。シンプルデバイス記述のこれらのフィールドは全て固定長であるため、これらのフィールドは解凍する必要なしに容易に取り扱うことができる。
【００３７】
シンプルデバイス記述２３０の受信後(図３の１０６)、シンプルデバイス記述２３０はＨＵＣＬスタックに渡される。
【００３８】
拡張デバイス記述が使用可能であり、コントローラデバイスがこれを必要とする場合には、コントローラデバイスの制御アプリケーションは「Get Extended Description（拡張記述を取得せよ）」要求をデバイスに発行する（ステップ１０８）。
【００３９】
この要求を受信するデバイスのＨＵＣＬスタックは制御アプリケーションに対して「Get Extended Description」コールを行い、拡張デバイス記述を要求する。
【００４０】
拡張デバイス記述はＨＵＣＬスタックに渡され、これを要求したデバイスの制御アプリケーションに戻すことが行われる。次いで拡張記述は要求デバイスへリターンされる(ステップ１１０)。
【００４１】
「Get Extended Description」問合せが拡張デバイス記述を提供しないデバイスで受信されると、この要求は無視されるだけである。
【００４２】
このセクションで用いるスイッチ／器具の例に戻り説明すると、スイッチが器具のアドレスのみを知った時点から、スイッチは器具にシンプルデバイス記述を要求する。器具は、この要求の受信時に、スイッチが標準器具コマンドセットに準拠する照明器具と通信していることを知ることができるとともに (例えば)当該器具は拡張デバイス記述を提供し得ないことも知ることができる十分な情報を提供する。
【００４３】
デバイスアプリケーションは、要求されたときにシンプルデバイス記述をＨＵＣＬスタックに与える必要がある。拡張デバイス記述を提供しないデバイスはこのような情報に対するいかなる要求も無視することができる。
【００４４】
(要求されたときに)デバイスによりリターンされるシンプルデバイス記述には、デバイスのタイプ（例えば、ＴＶ，ＤＶＤ，照明器具など）を識別するデバイスタイプフィールド２３２が含まれる。デバイスタイプフィールド２３２は、（シンプルデバイス記述を要求する）コントローラに、デバイスが準拠する命令セットを識別させる。ＨＵＣＬデバイスは自身をそのデバイスタイプ識別子で識別するだけで、これらのデバイスはそれらがどのように制御されるかを記述するメッセージを送らない。ＨＵＣＬには「ランタイム」サービス記述コンセプトはない。あるデバイスを照明器具として識別する場合、このデバイスに要求されるコマンドセットは照明器具タイプデバイスに対するＨＵＣＬ仕様に文書で指定されている。
【００４５】
図４につき説明すると、全てのデバイスタイプはベースデバイスタイプ５０に従属する。最上位レベルの要素５８は、本例では、コントローラデバイスタイプ５２と、被制御デバイスに対するベーシックデバイスタイプ５４と、アラームデバイスタイプ５６とを含む。
【００４６】
従属デバイスタイプ６８はベーシックデバイスタイプに従属する。本例では、これらはＴＶデバイスタイプ６４、調光可能照明デバイスタイプ６２及びＰＶＲデバイス６０である。
【００４７】
デバイスタイプ分類は、シンプルコントローラがデバイスをコントローラの能力の範囲で制御し得るか識別することがでるシステムを生成するためであった。
【００４８】
シンプルスイッチは、ライトをターンオン及びオフするべく照明器具とペアを構成しうるが、スイッチの制御機能、即ちデバイスをオン、オフするその能力を、オン／オフコンセプトを受諾する任意のデバイス、例えばＴＶ、ヒータ、プリンタに拡張可能にすべきであるという意見もある。
【００４９】
これを実現する一つの方法は、スイッチが制御(オン／オフ)方法を知っている全てのデバイスのリストを持ち、スイッチがデバイスに対してシンプルデバイス記述を要求するとき、リターンされてきた記述内のデバイスタイプフィールドを調べ、それが制御方法を知っているデバイスタイプのリスト内にあるか決定することができる。
【００５０】
この方法には重大な２つの欠点がある。第１に、スイッチは極めて簡単なデバイスであり、そのデバイス内のアプリケーションが、制御し得る全ての可能なデバイスのリストを保持しなければならず  またこのリストは極めて大きくなるという不都合がある。第２に、(シンプルオン／オフ機能を受諾し得る)スイッチの生産後に新タイプのデバイスが生成される場合、スイッチはこの新デバイスタイプをそのリストに持たず、これを制御することはできない、即ち拡張可能でない。
【００５１】
ＨＵＣＬは図４に示すようにデバイスを階層的手法で分類する。デバイスタイプフィールド２３２(図１５)は階層構造内のデバイスを識別し、新デバイスが生成されたとしても、それが階層構造内の適切な点から導出される限り、シンプルスイッチは依然として新デバイスをある程度まで制御可能であることを知ることができる。
【００５２】
ツリー内の下位にあるデバイスはその上のデバイスタイプの機能を引き継ぐ。コマンドについては、ツリー内の下位デバイスに供給されるとき、若干の解釈を加える必要があり、例えばオン／オフコマンドは、ライトに供給されるとき、それをターンオン及びオフするものであること明らかであるが、ＴＶに供給されるとき、このコマンドはそれを待機モードに投入及び切断するものである。
【００５３】
デバイスタイプ記述の重要な利点は、コントローラが個別のデバイスタイプの知識をもたなくても、コントローラは該デバイスタイプが導出されるデバイスを決定することができ、該デバイスタイプの若干の知識を持っているので、デバイスを（デバイスの観点から）若干低い程度で制御することができることにある。
【００５４】
例えば、ライトスイッチがデバイスのアドレスを得る場合を考察すると、スイッチはこのデバイスにシンプルデバイス記述を要求する。デバイスタイプフィールドは該デバイスをＴＶと識別するが、スイッチはこれを知っているデバイスと認識しない。しかし、スイッチは前記記述から、それはスイッチが知っている「ベーシックデバイス」から導出されるものであることを決定することができる。最終結果は、デバイス自体については何も知らないにもかかわらず、スイッチはＴＶを、スイッチの能力の程度まで制御でき、即ちオン及びオフ制御することができることになる。デバイスは、スイッチが製造されたずっと後に「ＸＹＺ」という新ブランドカテゴリのデバイスになり得るが、それがベーシックデバイスから導出される限り、スイッチはこれをある程度制御することができる。
【００５５】
デバイスタイプ階層構造は丁度２つの階層を有し、最上位レベルの要素としてコントローラとベーシックデバイス有するものとし得るが、少なくとも１つの他の階層及び／又は最上位の要素が望まれる。これは、ベーシックデバイスにおいて上で示した機能に従わないデバイス、即ちベーシック機能「ターンオン」「ターンオフ」を行わないデバイス、例えばアラームを満足する。例示目的のために、「アラーム」タイプデバイス５６が図４に示され、この「アラーム」デバイスは、ベーシックデバイスから導出されるデータが持つべきノーマルオン／オフ機能を実行することを望まないこと当然である。従って、このデバイスは階層構造内にベーシックデバイス５４と同一のトップレベル５８に置く。
【００５６】
階層構造に対する第２の拡張も図４に示されている。即ちノーマルＴＶデバイス６６の下に拡張ＴＶデバイス６６が示されている。拡張ＴＶデバイスはベーシックデバイス５４とＴＶデバイス６４の両方の機能の全てを引き継ぐが、ノーマルＴＶに存在しない拡張機能を含むこともできる。ノーマルＴＶデバイスを操作するよう設計されたレギュラＴＶリモートコントロールは拡張ＴＶデバイスをノーマルＴＶデバイス機能のレベルまで操作し得るが、拡張機能を制御することはできない。
【００５７】
従って、ＨＵＣＬプロトコルは、デバイスタイプ及び機能を引き継ぐその上のデバイスを記述する拡張可能なメカニズムを提供する。多層の階層構造のアイディアは魅力的に思われるが、３又は４レベル以上に拡張すると、シンプルデバイス記述のサイズに影響を与え始める。
【００５８】
ＨＵＣＬ内では、コントローラ並びに制御可能デバイスからデバイス記述を要求することができる。１つのデバイスが「Get Simple Device」要求をコントローラデバイス(例えばスイッチ)に送ると、「コントローラ」のデバイスタイプを含むシンプルデバイス記述がリターンされる。コントローラデバイスも、製造者、モデル番号などのような更なる情報を提供する拡張デバイス記述を利用することができる。
【００５９】
コントローラデバイスによりリターンされるデバイスタイプは簡単に「コントローラ５２」であり、デバイスタイプツリーで規定される種々のコントロータイプデバイスの階層構造は存在しないことが重要である。これも、プロトコル及びメッセージサイズを小さく且つ簡単に保つためである。スイッチ、ＴＶリモコン、ＰＶＲリモコンなどのようなベーシックコントローラから導出される種々のコントローラタイプを持たせることもできるかもしれない。しかし、広範囲のデバイスを制御し得るユニバーサルリモコンのようなインテリジェントコントローラの場合に問題が起こる。可能なコントローラタイプの全てをシンプルデバイス記述に含めることは潜在的に大きなメッセージを生ずることになり、最初のシンプルデバイス記述を簡単にするというアイディアに反することになる。コントローラデバイスの正確な能力を決定するために種々のメカニズムが使用される。
【００６０】
コントローラデバイスの能力を決定する第１の手段は、コントローラデバイスで許される拡張デバイス記述であり、デバイスネーム、例えば「ユニバーサルリモートコントロール」のような情報を含むことができ、この情報はテキスト情報であり、アプリケーションソフトウエアで直接解釈できないが、ユーザに提示してコントローラについての情報選択の実行を助けることができる。
【００６１】
デバイスがコントローラについてもっと詳しい情報を決定する第２の手段は問合せによる。
【００６２】
問合せの使用はデバイスについての情報をドリップフィード(drip-feeding)するパワフルなメカニズムであり、さもなければ大量情報の場合にリクエスタをオーバロードすることになる。
【００６３】
コントローラタイプの各デバイスは、他のデバイスに、特定デバイスタイプを制御し得るかどうかを問い合わせる手段１２０を提供する(図５)。問合せ内に挿入されるデバイスタイプはシンプルデバイス記述に使用されるものと同一のフィールド、即ちデバイスタイプ階層で規定されたものと同一のフィールドである。コントローラは、デバイスを制御し得るレベルをリターンし（図５の１２２）、これは、問合せ内に挿入されたデバイスタイプであるコントローラメモリ１４に記憶されたリスト内の最下位のデバイスタイプ又は該デバイスタイプに従属するデバイスタイプをリターンすることによって行われる。例えば、シンプルスイッチは、拡張ＴＶデバイスを制御し得るか問い合わされる。図４に示す階層構造に基づくと、リプライは、このスイッチはベーシックデバイスのレベルまで制御可能というものとなる。スイッチは典型的には拡張ＴＶデバイスのデバイスタイプについて何も知らないが、デバイスタイプは引き継がれたデバイスも含むので、ベーシックデバイスを識別し、これを制御可能な最下位の（階層的には上位の）デバイスタイプとしてリターンすることができる。
【００６４】
コントローラは、更に、スイッチがシンプルデバイス記述でリターンされるデバイスタイプを制御し得るか決定するアルゴリズムを実行する(図６)。スイッチはデバイスのアドレスを発見すると、そのデバイスにそのシンプルデバイス記述を要求し（ステップ１２４）、この情報を受信すると（ステップ１２６）、スイッチはこのタイプのデバイスをどの程度まで制御し得るかテストする（ステップ１２８）。これは問合せプロセス１２０と同一の質問であって、同様に応答する必要がある。両問合せプロセス１２０，１２２，１２４；１２６，１２８を加え合わすと大きくなりすぎてシンプルスイッチデバイスが複雑になるので加え合わせない。
【００６５】
デバイスは、全て同一の物理アドレスを介してアクセスされる複数の個別デバイス、例えば全て単一のＲＦトランシーバで同一場所に配置される複数の個別デバイスからなるものとすることが予測される。
【００６６】
このタイプのデバイスの例は、単一のＲＦトランシーバにより制御される個別に切替え可能なライトのバンク、又はアラームクロックが組込まれたＴＶであって両コンポーネントが同一のトランシーバで制御可能なものがある。
【００６７】
図７は発見プロセスを示す。スイッチは最初に基礎トランスポート媒体により知られている全てのデバイスのアドレスを得る。スイッチは４つの個別に制御可能なライトの単一アドレスを含む。スイッチはライトバンクに対し「Get Simple Description」コマンドを発行する（ステップ１４０）。この場合、何をリプライすべきか問題になる。４つのデバイス記述がリターンされる場合、スイッチが受信する予想の４倍のデータになる。多数のシンプルデバイス記述のリターンは拡張可能でなく、例えばライトバンクに２０のライトがある場合には問題を生ずる。
【００６８】
ＨＵＣＬにより与えられるこの問題の解決法は複合デバイスに対して特定デバイスタイプを使用することにある。
【００６９】
複合デバイスは、そのデバイスタイプとして「複合デバイス」をデバイスタイプフィールド２３２内に含むシンプルデバイス記述をリターンする（ステップ１４２）。このシンプルデバイス記述は、フィールド２３４内に、本例ではこの単一デバイス内に４つの内蔵デバイスがあることも識別する。
【００７０】
コントローラが複合デバイスと通信していることを識別したら、次のステップは、この複合デバイス内に何のデバイスが内蔵されているか決定する。コントローラは、更に、複合デバイスに対して「Get Simple Description」要求を行うが、この要求は個別の内蔵デバイス宛にする。内蔵デバイスはそれらのデバイス記述をリターンする（ステップ１４６）。
【００７１】
コントローラが内蔵デバイスの１つを制御することを決定すると、全ての制御コマンドがこの内蔵デバイスに向け、各コマンドに内蔵デバイスＩＤを含めて送付される。複合デバイスのコンセプトを確立すれば、多数の興味あるデバイスを有利に組合せる可能性が広がる。いくつかの例を以下に記載する。
【００７２】
一つの例は、一体のスイッチを備えたランプからなる単一デバイスであり、スイッチの機能は他のデバイスを制御できるように公開されている。このデバイスは、そのシンプルデバイス記述について問い合わされると、複合デバイスと提示するが、更に問い合わされると、１つの内蔵デバイスがコントローラであること、及び他のデバイスは制御可能なライトであることを発見する。複数のこのようなデバイスは、スイッチがこれらのデバイスのどれか１つを動作させることにより全てのデバイスでライトをターンオン／オフさせる、例えばラウンジ内のテーブルランプのどれか１つをターンオンすることによりラウンジ内の全てのテーブルランプをターンオンさせるように構成することができる。
【００７３】
ＣＥ領域における複合デバイスの他の可能な組合せは、例えばＴＶ＋ビデオカセットレコーダ（ＶＣＲ）又はＤＶＤ及びＶＣＲである。これらの組合わせの各々は、必要に応じ、２つのデバイスの複合デバイスとして記述することができる。
【００７４】
概念的には、デバイスはコアデバイスと０以上のサブコンポーネントからなり、例えばＴＶデバイス６０は例えばＴＶデバイス自体６０とチューナ６４、オーディオ６４及びディスプレイ６８からなるものとすることができる（図８）。
【００７５】
また、単一デバイスは２以上のサブコンポーネントの例を含むことができ、例えばＴＶ／ＶＣＲコンビネーションデバイスは、オーディオ６６及びディスプレイ６８に加えて、２つのチューナ６２，６４（一つはＴＶ用、他の一つはＶＣＲ用）を有することができる（図９）。
【００７６】
最も簡単なデバイスでのＸＭＬ及びその圧縮及び解凍の使用は処理をわずかに重くする。プロトコルの記述にＸＭＬを使用することは、将来の向上に対する拡張を容易にし、記述及び理解を簡単にし、構成された情報を容易に処理し、「インターネットドメイン」と即時互換性にする解決策を提供する。
【００７７】
ＸＭＬでのタグ圧縮技術（ＨＵＣＬで規定されている）を使用すると、コンテント構造を保持するための若干のオーバヘッドの付加で、比較的冗長なプロトコルを伝統的な純粋バイナリベースプロトコルにサイズダウンすることができる。
【００７８】
プロトコルが圧縮形態のコマンドで与えられても、コマンド構造の情報及びデータ値に対する定義テーブルを用いて、任意の他のバイナリベースプロトコルを読むのと同様に読みことができる。バイナリデータをＸＭＬベース表記から創出できる唯一の手掛かりは構造を表すデータの存在である。
【００７９】
ＨＵＣＬ仕様は、メッセージを常にトランスポート媒体によりその圧縮形態で伝送することを規定している。しかし、アプリケーションが、シンプルデバイス上で、圧縮されたメッセージを直接オペレートして、シンプルデバイスにＨＵＣＬソフトウエアスタック内の圧縮／解凍ソフトウエアを存在させる必要性を除去することができる。この場合、アプリケーションは、（ＲＯＭ内のアプリケーションイメージの一部として）シンプルデバイス記述を予め圧縮した形で格納し、アプリケーションは受信する圧縮プロトコルメッセージ用のパーサー（任意の他のバイナリプロトコルパーサーに類似する）を有し、いかなる応答メッセージも圧縮形態で記憶する必要はないようにする。
【００８０】
このアプローチを使用すると、このセクションにおいて用いるライトスイッ及び照明器具の例のような最も簡単なデバイスは縮小されたソフトウエアスタックで実現することができ、簡単なデバイスが理解し送出する必要があるコマンドの数が比較的少なくなり（turn light on(ライトオン)、turn light off(ライトオフ)、toggle(トグル)、get current state(現在状態取得)、get device description(デバイス記述取得)など）、アプリケーションソフトウエアのオーバヘッドが最小になる。
【００８１】
これはデバイスに対する拡張可能な解決を提供し、圧縮されたデータでオペレートするアプリケーションを実現すればこれを実現できるが、デバイスがもっと複雑になると、圧縮／解凍機能をスタック内に含ませ、アプリケーションにフルＸＭＬ表記のプロトコルメッセージを使用させることが容易になる点がある。このカットオフ点は完全にデバイス設計者にまかされ、ＨＵＣＬにより全く規定も定義もされていない。
【００８２】
図１０はＨＵＣＬを構成する要素がどのように組み合わさるのかを示す。これらの要素はメモリに記録されたソフトウエア要素である。
【００８３】
以下のセクションはＨＵＣＬソフトウエアスタック３２を構成する層とそれらが提供する機能について詳細に説明する。
【００８４】
先に述べたように、ＨＵＣＬは（例えばＴＣＰ／ＩＰと相違して）特定のトランスポートプロトコルに依存しないで、トランスポートスタック３４の上に直接位置する。種々のトランスポートスタック３４はそれらの性質により異なるサービスを異なるＡＰＩを介してアプリケーションに提供する。ＨＵＣＬトランスポートアダプテーション層１８０は特定のトランスポート層に対するバッファとして作用する。
【００８５】
トランスポートアダプテーション層１８０はＨＵＣＬスタック内の上位の層に一貫したトランスポート独立セットのサービスを提供する。この層の要件はプロトコル仕様に詳細に規定されている。
【００８６】
メッセージング層１８２はＨＵＣＬソフトウエアスタックの機能の大半を提供する。アプリケーションはＨＵＣＬ  ＡＰＩを介してこの層と通信し、この層は必要なとき(例えばデータ受信時)にアプリケーションへのコールを行う。
【００８７】
メッセージング層１８２は初期エラー報告及び必要なら確認応答（ＡＣＫ）も処理する。メッセージの紛失やメッセージの結合の検査に使用されるメッセージＩＤ及びトランザクションＩＤもこの層で完全に処理される。
【００８８】
メッセージング層１８２は、メッセージが圧縮又は解凍を必要とするとき、圧縮／解凍サービス１８４を用いることもできる。先に述べたように、アプリケーションはもっぱらメッセージを圧縮された形態で処理し、これらのサービスに対するコールは行われず、これらはランタイムスタックから除去することができる。
【００８９】
簡単に言えば、圧縮及び解凍サービスはメッセージ層に、ＨＵＣＬメッセージを圧縮された形から解凍された形に変換する手段を提供する。システムのこの要素はロウエンドデバイスに存在させないことができ、この場合にはアプリケーションとの全てのデータ交換は圧縮されたメッセージで行われる。
【００９０】
アプリケーションプログラミングインターフェースＡＰＩ１８６はインターフェースであり、全てのアプリケーションはこのインターフェースを介してＨＵＣＬソフトウエアスタックと通信する。通信は双方向であり、ＨＵＣＬスタックは、下位層で生起するイベント（例えばトランスポートスタックから受信されるメッセージ）の結果としてアプリケーションへの非同期コールを行う。
【００９１】
ＨＵＣＬはトランスポートスタック３４と独立であり、これは、ＨＵＣＬメッセージングプロトコルは種々のトランスポートスタック、即ち有線及び無線の双方の上に構築することができることを意味する。
【００９２】
ＨＵＣＬスタックは軽量プロトコルとして設計されているため、新生のＺｉｇｂｅｅ（IEEE802.15.4）標準と同様に軽量トランスポートスタックに最も適するが、このスタックはＴＣＰ及びＴＣＰ／ＩＰの上に等しく良好に置くことができ、広範囲の他のプロトコル、即ち有線（例えばイーサネット（登録商標））及び無線(例えばIEEE802.11b)の双方を解放することができる。
【００９３】
トランスポートスタック３４上で実行すべきＨＵＣＬに対しては、複数のサービスをＨＵＣＬスタックのメッセージング層に提供可能にする必要がある。これは、これらのサービスはトランスポートスタック自体に存在させる、或いは、紛失したサービスをＨＵＣＬスタックのトランスポートアダプテーション層で実行可能にする必要があるかのいずれかであることを意味する。これらのサービスは、アドレッシング、メッセージ配信、デバイス発見（例えばネットワーク上の他のデバイスのアドレスの発見）のような態様をカバーするものとすることができる。
【００９４】
次に、本発明によるブリッジングについて、特にＨＵＣＬを参照して説明する。しかし、本発明の原理はＨＵＣＬに限定されず、他のネットワークプロトコルに適用することができる。
【００９５】
異なるネットワーク間のブリッジングは任意のプロトコルの重要部分である。一般に採用されているネットワークプロトコル及びトランスポート媒体は決して一つにならない。
【００９６】
ＨＵＣＬの観点からすれば、２つの異なるタイプのブリッジングが可能であり、第１は、異なるトランスポートスタック間のブリッジングであり（この場合にはＨＵＣＬが両者の共通プロトコルである）、第２は、異なるプロトコル間のブリッジングである。
【００９７】
ＨＵＣＬトランスポートスタックブリッジングは、互いに通信する必要があるが異なる基礎トランスポートスタック又はネットワーク２１０，２１２を使用する複数のＨＵＣＬデバイスが存在するときに必要になる。以下の例はこのような例の一つを示す。
【００９８】
図１１は複数のデバイス２００の全てがＨＵＣＬプロトコルを使用する場合の本発明によるシナリオを示す。これらのデバイスのいくつか２０２はＺｉｇｂｅｅネットワーク２１０上で動作し、他のデバイス２０４はＩＥＥＥ８０２．１１ｂネットワーク２１２上で動作するため、全てのデバイスは「同一の言語（ＨＵＣＬ）を話す」が、Ｚｉｇｂｅｅデバイス２０２は異なるトランスポートネットワークのために８０２．１１ｂデバイス２０４と直接通信できない。
【００９９】
この状態におけるブリッジはＺｉｇｂｅｅ及び８０２．１１ｂトランシーバの両方を備えるブリッジデバイス２０６からなり、これらのトランシーバの上にＨＵＣＬブリッジソフトウエアが存在する。ネットワーク全体はHUCLに基づくため、ブリッジの仕事は主としてルータの仕事になる。ブリッジはＺｉｇｂｅｅネットワーク２１０内のデバイスと通信する第１のトランシーバ２２４と、第２のネットワーク２１２内のデバイスと通信する第２のトランシーバ２２６を有する。第１のネットワーク内にはブリッジ２０６以外に１つのデバイス２０２のみを示すが、もっと多くのデバイスが存在してもよいこと勿論である。
【０１００】
複合デバイスタイプを使用するとＨＵＣＬブリッジを大きく簡単化することができる。最下位レベルではブリッジは各ネットワーク上に単一の物理アドレスとして現れる。あるデバイスがブリッジアドレスを発見すると、このデバイスは最初に、「Get Simple Description」要求によりデバイス情報を要求するのが常である。ブリッジは直ちにこれに応答し、自身を複合デバイスと識別し、ブリッジの「反対側」に位置するデバイスの数をリターンする。
【０１０１】
次に、更なる問合せをブリッジに対して、それがあたかも他の複合デバイスであるかのように行い、「擬似」内蔵デバイスの各々に対するシンプルデバイス記述を要求する。この要求及びそれに続くコマンドは全てブリッジ内の特定内蔵デバイスに対するものであると識別されるが、それらはブリッジによって「反対側」に位置する特定デバイスに転送される。
【０１０２】
ブリッジは、それが含む内蔵デバイスの数が変化し得るためにノーマル複合デバイスではなく、ダイナミック複合デバイスである。ブリッジは「Get Simple Description」要求に対する標準応答の一部分として内蔵デバイスの数を識別するが、これはブリッジの反対側に位置するデバイスの瞬間的な数である。ダイナミック複合デバイスは反対側のデバイスの数を識別する属性も開示するため、デバイスは任意の瞬時にこれを問い合わせることができる。ブリッジがイベントサブスクリプションをサポートする場合には、デバイスの数が変化するとき属性の変化が通知されるために、デバイスは属性の変化を承認することもできる。
【０１０３】
ホームネットワーク内のデバイスを外部から制御可能にするホームゲートウェイをブリッジの一部として実現することができる。図１２に示すシナリオは有線ＩＰベーストランスポートを介して外界に接続されたゲートウェイ２２０を示し、このゲートウェイは家庭内のデバイスを２つのＺｉｇｂｅｅネットワーク２１０と８０２．１１ｂネットワーク２１２で接続する。
【０１０４】
外部のＩＰドメイン２２２からのコマンド及び要求は標準のＩＰアドレス方式（ＩＰｖ４又はＩＰｖ６）を用いてホームゲートウェイに送られる。これらが到達すると、家庭内のデバイスはゲートウェイ内に含まれる内蔵デバイスとして表現され、コマンド及び要求が任意の複合デバイスで使用される通常のメカニズムによってこれらのデバイスに送られる。ゲートウェイは内部に、内蔵デバイス数を２つの可能なネットワークの一つに位置する実デバイスアドレスとマッピングするテーブルを有する。ゲートウェイは次いで要求を正しいデバイスに転送する。
【０１０５】
第２の異なるタイプのブリッジングは２以上のネットワークでプロトコル自体（及び可能ならトランスポート媒体）が異なる場合のプロトコルブリッジングである。これを図１３につき説明する。プロトコルブリッジ２２０はメッセージを理解し、メッセージを一つのプロトコルから他のプロトコルに変換することができる。しかし、上述したように複合デバイスコンセプトを用いて他のプロトコル上に物理的に存在するデバイスをＨＵＣＬネットワークに提示することができる。
【０１０６】
ＨＵＣＬは基礎トランスポートスタックのアドレッシング方式を採用するものとする。これによりデバイスの複雑性とメッセージのサイズを最小に維持することができる。ブリッジタイプデバイスはアドレステーブルを必要とするのみである。
【０１０７】
プロトコル自体は媒体２１４上に記録されたドキュメントであり、図１４に示すように以下の情報：
全てのＨＵＣＬメッセージが準拠するフォーマットを定義するジェネリックＨＵＣＬメッセージフォーマット２００；
制御プロトコルを構成する個々のメッセージを定義するメッセージ定義２０２；
どのメッセージがいつ送られるかを規定するメッセージシーケンシング要件２０４及びメッセージ受信時のアプリケーションの要件；
ＨＵＣＬとこれを用いるアプリケーションとの間の双方向インターフェースを定義するＨＵＣＬ  ＡＰＩ定義２０６；
ＨＵＣＬソフトウエアスタックのメッセージングシステム要件及び機能２０８；
ＨＵＣＬメッセージの圧縮メカニズムを定義する圧縮アルゴリズム２１０；
ＨＵＣＬソフトウエアスタックがトランスポートシステム（例えばＲＦスタック）にインターフェースする方法を定義するトランスポートアダプテーション層定義２１２；
を含む。
【０１０８】
従って、ＨＵＣＬは単にメッセージフォーマット定義ではなく、メッセージ交換及び圧縮も包含するものである。上記リストの最後の４項目はＨＵＣＬソフトウエアスタックを構成し、デバイスに存在させるものであり、最初の３項目はスタックとアプリケーションが準拠しなければならない要件を規定するものである。
【０１０９】
本明細書を読めば、他の変形及び変更が当業者に明らかである。この変形及び変更はネットワークの設計、製造及び使用において既に知られている等価な特徴及び他の特徴を含んでもよく、更にここに記載された特徴の代わりに又はこれに付加する特徴を含んでもよい。本発明の特許請求の範囲が特徴の特定の組み合わせとして表現されていたとしても、更に、個々に明示的に又は暗示的に開示したいかなる新規な特徴又は特徴のいかなる組み合わせも、それがこの特許請求の範囲に記載された発明と同一であるか否かにかかわらず、本発明が解決する技術的課題と同じ課題の一部又は全部を解決するか否かにかかわらず、この出願の開示の範囲に含まれるものと解されるべきである。本出願人は、ここに、この出願又はこの出願から継続された出願が手続きの継続中に、前記の特徴及び／又は前記の特徴の組み合わせについて新しい特許請求の範囲を提出することがあり得ることを明記する。
【０１１０】
特に、特定のＨＵＣＬプロトコルについて記載したが、本発明は複合デバイスタイプに対応するデバイスタイプを有する、又は含むように構成された任意のネットワークに対し使用することができる。
【０１１１】
上述の例で使用した特定のサブルーチン名は容易に変更することができる。デバイスを制御するコンピュータプログラムはメモリ１４に記録されているものとして示したが、当業者であればこれをＣＤ、フロッピディスクなどのような多くの他のタイプの記録担体に記録されたものとすることができる。
【０１１２】
更に、照明器具及びライトスイッチの極めて簡単な例について広範囲に記載したが、当業者であれば多くのもっと複雑な制御シナリオも可能であることが理解される。
【０１１３】
ブリッジデバイスの上記の説明は、ブリッジデバイスは単一デバイスであるものと仮定しているが、当業者であれば、いくつかのネットワークに対して、各ネットワーク内に別個の物理デバイスを実現し、これらのデバイスを第３のデバイスを用いて一緒にリンクすることができるようにするのが好ましいとすることができる。このような複合ブリッジコンポーネントはここで使用する「ブリッジデバイス」の範囲に含むことを意図する。
【図面の簡単な説明】
【０１１４】
【図１】ＨＵＣＬを用いて通信するデバイスの１対のデバイスを示す。
【図２】ＨＵＣＬ内の１つのデバイスにおけるソフトウエアの構成を示す概略図である。
【図３】デバイス発見プロセスのフロー図である。
【図４】デバイスタイプ階層構造の概略図である。
【図５】コントローラが被制御デバイスに、該デバイスに対するその制御能力を知らせるために実行する手順を示す図である。
【図６】コントローラが被制御デバイスに対するその制御能力を決定するために実行する手順を示す図である。
【図７】複合デバイスに対するデバイス発見プロセスのフロー図である。
【図８】複合デバイスを示す図である。
【図９】別の複合デバイスを示す図である。
【図１０】ソフトウエアの構造を示す図である。
【図１１】ブリッジデバイスを含む本発明のシステムの一実施例を示す図である。
【図１２】インターネットに接続されたブリッジデバイスを含む本発明のシステムの一実施例を示す図である。
【図１３】本発明によるネットワークと他のネットワークとの間にブリッジデバイスを有するシステムの一実施例を示す図である。ブリッジデバイスを有するシステムの一実施例を示す図である。
【図１４】ＨＵＣＬプロトコルを示す図である。
【図１５】シンプルデバイス記述メッセージを示す図である。
【図１】
2005535246.tif 000003
【図２】
2005535246.tif 000004
【図３】
2005535246.tif 000005
【図４】
2005535246.tif 000006
【図５】
2005535246.tif 000007
【図６】
2005535246.tif 000008
【図７】
2005535246.tif 000009
【図８】
2005535246.tif 000010
【図９】
2005535246.tif 000011
【図１０】
2005535246.tif 000012
【図１１】
2005535246.tif 000013
【図１２】
2005535246.tif 000014
【図１３】
2005535246.tif 000015
【図１４】
2005535246.tif 000016
【図１５】
2005535246.tif 000017
【国際調査報告】
2005535246.tif 000018
2005535246.tif 000019
2005535246.tif 000020