(57)【要約】本発明は、ネットワーク装置間の通信用のプロトコルに関係する。装置は、他の装置形式が付随しないコントローラ装置形式と、複数の他の装置形式が付随する基本装置形式とを有する装置形式の階層として論理的に構成される。装置は、固定長のシンプル装置記述メッセージと装置形式を有するフォーマットを実装し、いくつかの装置は、追加情報を有する拡張装置記述メッセージを更に実装する。
2005535248.tif 000002
【特許請求の範囲】
【請求項１】
トークン圧縮メッセージを受信し、
前記受信したトークン圧縮メッセージにおいて、入力メッセージを解凍することなく、ネットワーク装置からのシンプル装置記述応答を要求する入力シンプル装置記述クエリメッセージを認識し、
シンプル装置記述応答を要求する入力シンプル装置クエリメッセージへの応答として、装置形式を有するシンプル装置記述を送信することを有するネットワーク装置を動作する方法。
【請求項２】
請求項１に記載の方法であって、
シンプル装置記述を送信するステップが、前記ネットワーク装置のメモリから所定のシンプル装置記述を読み取り、前記所定のシンプル装置記述を送信することを有する方法。
【請求項３】
請求項１又は２に記載の方法であって、
前記ネットワーク装置が無線ネットワークの一部であり、
トークン圧縮メッセージを受信し、前記シンプル装置記述を受信するステップが、無線信号を使用する方法。
【請求項４】
トークン圧縮された人間に解読可能なメッセージを送受信するトランシーバと、
トークン圧縮された人間に解読可能なメッセージの入力時に、
前記入力メッセージを解凍することなく、ネットワーク装置からのシンプル装置記述応答を要求する受信した装置クエリメッセージを認識するステップと、
シンプル装置記述応答を要求する入力装置クエリメッセージへの応答として、装置形式を有するシンプル装置記述を前記トランシーバを通じて送信するステップと
を実行するように構成されたメッセージハンドラと
を有するネットワーク装置
【請求項５】
請求項４に記載のネットワーク装置であって、
人間に解読可能なフォーマットから事前に圧縮された所定のシンプル装置記述メッセージを格納するメモリを更に有し、
前記メッセージハンドラは、前記メモリから前記所定のシンプル装置記述メッセージを読み取り、入力装置クエリメッセージに応じて前記トランシーバを通じて前記メッセージを送信するように構成されたネットワーク装置。
【請求項６】
それぞれネットワークメッセージを送受信するトランシーバを有する複数のネットワーク装置と、
他の装置にシンプル装置クエリメッセージを送信し、シンプル装置記述メッセージを受信し、他の装置から受信した後にシンプル装置記述メッセージを解釈するように構成された少なくとも１つのネットワーク装置とを有するシステムであって、
各ネットワーク装置は、装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを送信することにより、その他の装置からの入力シンプル装置クエリメッセージに応答するように構成され、
前記複数のネットワーク装置は、メッセージを解凍する機能を備えず、圧縮メッセージを直接解釈する少なくとも１つの簡単な装置と、前記メッセージを解凍するメッセージ解凍構成と前記解凍されたメッセージを解釈するメッセージ解釈器とを有する少なくとも１つの複雑な装置とを有するシステム。
【請求項７】
請求項６に記載のシステムであって、
各簡単な装置は、人間に解読可能なフォーマットから事前に圧縮された所定のシンプル装置記述メッセージを格納するメモリを更に有し、
メッセージハンドラは、前記メモリから前記所定のシンプル装置記述メッセージを読み取り、入力装置クエリメッセージに応じて前記トランシーバを通じて前記メッセージを送信するように構成されたシステム。
【請求項８】
請求項６又は７に記載のシステムであって、
前記ネットワーク装置は、メッセージをデコードし、前記デコードされたメッセージで動作するように構成されたメッセージ解凍ユニットを有する少なくとも１つの装置を有するシステム。
【請求項９】
トークン圧縮メッセージを受信するコードと、
前記受信したトークン圧縮メッセージにおいて、入力メッセージを解凍することなく、ネットワーク装置からのシンプル装置記述応答を要求する入力シンプル装置記述クエリメッセージを認識するコードと、
シンプル装置記述応答を要求する入力シンプル装置クエリメッセージへの応答として、装置形式を有するシンプル装置記述を送信するコードと
を有するコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークプロトコルに関するものであり、特にプロトコルの実装に関するものである。
【背景技術】
【０００２】
ネットワーク管理用の従来技術のプロトコルは、ユニバーサル・プラグ・アンド・プレイであり、そのユニバーサル・プラグ・アンド・プレイは、帯域とバッテリー消費とある程度のコストが問題とならないインターネットアプリケーションで非常に有用である。家庭用電化製品(CE:consumer  electronics)へのプロトコルの実装は存在するが、プロトコルの限界のため、このような実装は、その実装がなければ最小の処理能力しか必要としない特に最も単純な装置に大きい負荷をかける。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従って、ライトやサーモスタットやCE装置(TVやDVDやPVRのリモコン)のような簡単な装置に組み込むのに適したプロトコルに対する必要性が存在する。そのプロトコルは実装が簡単であり、コスト効率の良いものであり、最小の帯域を必要とするが、可変の機能により広範囲の装置を通じてスケーラブルである。
【０００４】
この必要性は、無線アプリケーションに限定されず、有線アプリケーションに拡張する。
【課題を解決するための手段】
【０００５】
本発明の第１の態様によると、ネットワーク装置を動作する方法が提供され、トークン圧縮メッセージを受信し、受信したトークン圧縮メッセージにおいてネットワーク装置からのシンプル装置記述応答を要求する入力シンプル装置記述クエリメッセージを認識し、シンプル装置記述応答を要求する入力シンプル装置クエリメッセージへの応答として、装置形式を有するシンプル装置記述を送信することを有する。
【０００６】
このような方法は、この特許出願の対象であるプロトコルを実装する。プロトコル自体は、ホーム・ユニフォーム・コントロール言語(HUCL:home  uniform  control  language)と呼ばれる。
【０００７】
簡単な装置が圧縮されたトークン符号化メッセージで直接動作できる機能により、簡単な装置が必要以上のハードウェア又はソフトウェア要件を備えずに作られることが可能になる。更に複雑な装置は、メッセージを解凍し、更に複雑な方法でそのメッセージで動作することができる。従って、本発明による手法により、容易に統合ネットワークで簡単な装置が複雑な装置と組み合わせられることが可能になり、簡単な装置に過負荷をかけることなく複雑な装置の全機能を許容する。簡単な装置は、拡張装置記述クエリを単に無視してもよい。
【０００８】
シンプル装置記述は少数又は適度な数の所定のフィールドを有し、各フィールドは固定長である。一般的に、各メッセージに同じフィールドが使用されが、ある程度の変動が存在することがある。例えば、複合装置は、以下に説明するサブ装置の数を含む追加の整数フィールドを有してもよい。
【０００９】
シンプル装置記述メッセージは人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージ(token-compressed  message)の形式である。メッセージは他の装置の形式を表す装置形式値を有することが好ましい。装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択される。
【００１０】
HUCLプロトコルによると、基礎となるメッセージフォーマットは、XMLのような人間に解読可能なフォーマットである。しかし、帯域を確保するために、メッセージは圧縮形式でネットワーク装置間を通過する。それにもかかわらず、使用される圧縮方法が、共通ストリングをトークンと交換するトークン圧縮であるため、ネットワーク装置はこのような圧縮メッセージを処理することができる。従って、ネットワーク装置は、シンプル装置記述の応答を要求するクエリを認識するのに少なくとも十分な程度で、解凍せずに圧縮されたトークンを認識することができ、シンプル装置記述で応答することができる。このように、ネットワーク装置は、ほとんどオーバーヘッドなしに実装され得る。
【００１１】
トークン符号化(token  coding)の適切な形式は、http://www.w3.org/TR/wbxmlで入手可能な1999年6月24日の“wap  binary  XML  content  format”に記載されている。
【００１２】
基本装置形式に付随する少なくとも１つの階層(すなわち被制御装置の階層)が存在するが、コントローラ装置の対応する階層が存在しないことに留意すべきである。これは、シンプル装置記述メッセージをできる限り短く且つ簡単に保持するためである。ユニバーサル・リモコンのような多くのコントローラが多数の異なる装置形式を制御することが可能になる。
【００１３】
第２の態様において、本発明はネットワーク装置に関係し、トークン圧縮された人間に解読可能なメッセージを送受信するトランシーバと、トークン圧縮された人間に解読可能なメッセージの入力時に、入力メッセージを解凍することなく、ネットワーク装置からのシンプル装置記述応答を要求する受信した装置クエリメッセージを認識するステップと、シンプル装置記述応答を要求する入力装置クエリメッセージへの応答として装置形式を有するシンプル装置記述をトランシーバを通じて送信するステップとを実行するように構成されたメッセージハンドラとを有する。
【００１４】
ネットワーク装置は、人間に解読可能なフォーマットから事前に圧縮された所定のシンプル装置記述メッセージを更に有してもよく、メッセージハンドラは、メモリから所定のシンプル装置記述メッセージを読み取り、入力装置クエリメッセージに応じてトランシーバを通じてそれを送信するように構成される。
【００１５】
更なる態様において、本発明は、それぞれネットワークメッセージを送受信するトランシーバを有する複数のネットワーク装置と、他の装置にシンプル装置クエリメッセージを送信し、シンプル装置記述メッセージを受信し、他の装置から受信した後にシンプル装置記述メッセージを解釈するように構成された少なくとも１つのネットワーク装置とを有し、各ネットワーク装置は、装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを送信することにより、その他の装置からの入力シンプル装置クエリメッセージに応答するように構成され、複数のネットワーク装置は、メッセージを解凍する機能を備えず、圧縮メッセージを直接解釈する少なくとも１つの簡単な装置と、メッセージを解凍するメッセージ解凍構成と解凍されたメッセージを解釈するメッセージ解釈器とを有する少なくとも１つの複雑な装置とを有するシステムに関係する。
【発明を実施するための最良の形態】
【００１６】
本発明の更なる理解のため、添付図面を参照して単に一例として実施例について説明が行われる。
【００１７】
プロトコルHUCLは、主に無線システム用に設計された軽量の小帯域の制御プロトコルである。メッセージフォーマットはXMLに基づき、メッセージは送信前に圧縮される。XMLの使用は、送信されるデータを低減する圧縮を備えた拡張可能且つスケーラブルな解決策を提供し、送信機がオンになっている時間の量を低減し、消費電力を低減する。
【００１８】
HUCLプロトコルの一般原理と、それが装置で動作する方法について、簡単な例を参照して説明する。
【００１９】
図１を参照すると、照明スイッチ2と、照明設備4が備えられており、後者が本発明の実施例である。照明スイッチ2は、ユーザにより操作される物理的なロッカースイッチ6と、RFトランシーバ8と、バッテリー10と、制御回路12と、メモリ14とを有する。照明設備もまた、RFトランシーバ8と、メモリ14を有するが、主電源付きであり、電球22に電力を加える制御回路20を有する。従って、照明スイッチ2は、制御入力6(スイッチ)を有するコントローラの例であり、照明設備は被制御装置4の例である。コントローラのメモリ14は、コントローラが制御可能な装置形式と装置形式に属する制御機能のリスト24を有する。被制御装置4とコントローラ装置2の双方のメモリ14はまた、以下に詳細に説明される方法を制御回路に実行させるコード26を有する。
【００２０】
図２は、各装置のメモリ14に存在するソフトウェアの表示を示したものである。制御アプリケーション30は、特定のイベントが生じたときにHUCLソフトウェアスタック32と通信する。
【００２１】
同様に、HUCLソフトウェアスタック32は、RFソフトウェアスタック34と通信し、RFソフトウェアスタック34は、特定のイベントが生じたとき(例えばデータの受信時)にHUCLソフトウェアスタック32と通信する。
【００２２】
メッセージ36が送受信される。メッセージは、シンプル装置記述クエリメッセージを含む複数の形式でもよく、また何らかの複数の他のメッセージ形式でもよい。
【００２３】
照明設備4のメモリ14は、照明設備4からシンプル装置記述を要求するクエリを受信すると、単に送信され得る事前に圧縮されたシンプル装置記述メッセージを有する。照明設備の制御アプリケーションは、メッセージを解凍せずに、トランシーバ8から受信したこのような入力シンプル装置記述クエリメッセージを認識することができる。これは、送信されるメッセージを圧縮するためにトークン圧縮を使用しているためである。
【００２４】
装置の動作について、図３を参照して説明する。この一対の装置の動作の第１段階は、スイッチ2(コントローラ)が照明設備4(被制御装置)のアドレスを発見することである。これは装置発見として知られており、装置発見処理が(RFソフトウェアスタックで)提供されること、又はトランスポートスタックの上位で(HUCLソフトウェアスタックの下位レイヤで)装置発見が実装可能であることは、基礎のRFトランスポートスタックの要件である。
【００２５】
発見処理は、HUCLソフトウェアスタックに呼び出しを行い、まず既知の装置の数を要求し、次にその装置のネットワークアドレスを要求することで、(場合によってはあるユーザ相互作用の結果として)コントローラの制御アプリケーションにより開始される100。これらの装置のアドレスが返信される。
【００２６】
基礎のRFプロトコルに応じて、他の方法でネットワークアドレスが定められてもよい。
【００２７】
装置発見段階の最終結果は、制御アプリケーションがRFスタックにより認識された全ての装置のアドレスのリストを受ける102。処理のこの時点では、制御アプリケーションはそのアドレス以外にそれぞれの他の装置について認識しない。
【００２８】
対になる処理の第２段階は、制御アプリケーションが、アドレスを有する装置について情報を収集することである。この情報は装置記述と呼ばれる。制御装置は、HUCLソフトウェアスタックに呼び出しを行い、装置記述を要求する装置のアドレスを渡すことにより、このことを行う。
【００２９】
シンプル装置記述の要求は、RFリンクを通じて宛先装置に渡され104、前述のスイッチ／設備の例では、要求がスイッチから設備に送信される。要求を受信すると、宛先装置のHUCLソフトウェアスタックは、制御アプリケーションに呼び出しを行い、装置記述を要求する。記述のフォーマットは定められている。圧縮形式でない場合には、要求の送信者に返信される前に記述が圧縮される。
【００３０】
要求装置のHUCLソフトウェアスタックが装置記述を受信すると106、制御アプリケーションに渡される。この時点で、アプリケーションは装置についてある程度の基本情報を有しており、この装置と更に通信したいか否かについて決定を行うことができる。
【００３１】
HUCLの設計目標は、非常に簡単な装置で動作するのに適することであるが、装置を十分に記述するために必要な情報は潜在的には非常に複雑である。以下のリストは、装置の記述の一部として装置が提供しようとする情報の種類を示している。
【００３２】
装置形式(例えばDVD)
ベンダ名(例えばPhilips)
モデル番号(例えばDVD1010/002)
シリアル番号(例えばAH06848032345)
ベンダURL(例えばwww.philips.com)
このセクションを通じた例で使用されるスイッチのように、最も簡単な制御装置の場合には、この情報のほとんどが場合によっては冗長的である。しかし、このような情報がユーザ向けに表示可能なスクリーンを有するハイエンドの‘PDA’形式のリモコンでは有用である。
【００３３】
完全なメッセージを受信したときにキャッシュする記憶装置(RAM)が潜在的に必要となるため、照明設備4のようなローエンドの装置でのこのような記述の処理は問題を提示する。前述の記述データの全体のサイズは不確定であり、その情報のほとんどは‘自由記載(free  text)’であるため(ベンダ名は非常に長くなることがあり、URLは場合によってはパラメータで正確なページを特定することがある(例えばhttp://www.consumer.philips.com/global/b2c/ce/catalog/subcategory.jhtml?groupId=VIDEO&dvdId=0&catId=DVD&subCatId=DVDPLAYER))、その問題は当初に思われるものより悪くなる。
【００３４】
HUCLで克服する方法は、装置記述を２層の情報に分割することである。第１層は、装置の簡単すぎる記述であるが、更なる情報が利用可能であるか否かを特定する。これは自由記載(free  text)フィールドを含まないため、全体の長さが決定的になる。第２層の拡張情報は任意選択であるが、追加情報を提供する。
【００３５】
図９を参照すると、シンプル装置記述メッセージ230は、フィールドとして、装置形式232と、拡張装置記述が利用可能であるか否かを示すフィールド238と、キー情報を特定する他のフィールド236(例えばイベント申込みが利用可能であるか否かを示すフラグ)とを有する。任意選択の整数のフィールド234は、複合装置のサブ装置の数を表す。メッセージ230がヘッダとフッタをも有してよく、それらが簡潔性のために省略されていることを当業者は認識するであろう。メッセージは、同様に簡潔性のために省略されている圧縮XMLトークンを有する。シンプル装置記述のフィールドは全て固定長であり、それにより解凍することなく容易に処理され得る。
【００３６】
シンプル装置記述230を受信した後106(図３)、シンプル装置記述230はHUCLスタックに戻される。
【００３７】
この例では、照明設備4は利用可能な拡張装置記述を有さず、このことはシンプル装置記述230のフラグにより示される。
【００３８】
しかし、拡張装置記述が利用可能なその他の装置にポーリングされ、コントローラ装置がそれを要求した場合には、コントローラ装置の制御アプリケーションは“GetExtendedDescription”要求をその装置に返信してもよい108。
【００３９】
この要求を受信した装置のHUCLスタックは、拡張装置記述を要求する制御アプリケーションにGet  Extended  Descriptionの呼び出しを行う。
【００４０】
拡張装置記述はHUCLスタックに戻され、それを要求した装置の制御アプリケーションに戻される。その後、拡張記述は要求装置に戻される110。
【００４１】
GetEtendedDescriptionクエリが拡張装置記述を提供しない装置で受信されると、その要求は単に無視される。
【００４２】
このセクションを通じて使用されるスイッチ／設備の例に再び戻ると、スイッチが設備のアドレスのみを認識した時点から、スイッチは設備からそのシンプル装置記述を要求する。これを受信すると、標準の設備コマンドセットに準拠する照明設備と通信していることをスイッチが認識し、更に照明設備4が拡張装置記述を提供できないことを認識するのに十分な情報を提供する。
【００４３】
要求時に装置アプリケーションがシンプル装置記述をHUCLスタックに提供することは必須である。拡張装置記述を提供しない装置は、このような情報について受信した如何なる情報も無視することができる。
【００４４】
装置の形式(例えばTV、DVD、照明設備等)を特定する装置形式のフィールド232  が、(要求時に)装置により戻されるシンプル装置記述に含まれる。装置形式のフィールド232は、(シンプル装置記述を要求する)コントローラに対して装置が準拠する命令セットを特定する。HUCL装置は、単にその形式の識別子により自分を特定し、それが制御される方法を記述するメッセージを送信し続けない。HUCLには‘ランタイム’サービス記述の概念が存在しない。装置が照明設備として自分を特定した場合には、その装置で呼び出されるコマンドセットは、照明設備の形式の装置用のHUCL仕様で特定される。
【００４５】
図４を参照すると、全ての装置形式は基本装置形式50に付随する。最上位の要素58は、この例では、コントローラ装置形式52と、被制御装置用の基本装置形式54と、アラーム装置形式56とを有する。
【００４６】
従属装置形式68は、基本装置形式に付随する。この例では、TV装置形式64と、調光可能照明装置形式62と、PVR装置60が含まれる。
【００４７】
装置形式の分類は、コントローラの機能の範囲まで装置を制御することができるか否かを簡単なコントローラが特定することを可能にする目的のシステムを作ることである。
【００４８】
簡単なスイッチは照明設備と対になり、照明をオン及びオフすることができるが、スイッチの制御機能(すなわち、装置をオン又はオフする機能)は、オン／オフの概念を受け入れることができる如何なる装置(例えば、TV、ヒーター、プリンタ)にも適用可能であるべきである。
【００４９】
これが実装され得る１つの方法は、制御方法(オン又はオフすること)を認識する全ての装置のリストをスイッチが有することである。装置のシンプル装置記述を要求すると、返信された記述の装置形式のフィールドを調べて、制御方法を認識している装置形式のリスト内に存在するか否かを決定することができる。
【００５０】
この手法の２つの著しい欠点が存在する。第１に、スイッチは非常に簡単な装置であり、その内部のアプリケーションが、制御可能な全ての見込まれる装置のリストを保持することは望ましくない。そのリストは非常に大きくなる可能性がある。第２に、スイッチが作られた後に新しい形式の装置が作られると(その新しい形式の装置は簡単なオン・オフ機能を受け入れることができる)、スイッチはこの新しい装置形式をそのリストに有しておらず、制御可能であるかがわからない(すなわち、拡張可能でない)。
【００５１】
図４に示すように、HUCLは階層的に装置を分類する。装置形式のフィールド232(図９)は、階層内の装置を特定するため、新しい装置が作られても、階層内の適当なポイントに由来する限りは、依然として簡単なスイッチは、ある程度それを制御することができるということを認識する。
【００５２】
ツリーの下にある装置は、その上の装置形式の機能を引き継ぐ。ツリーの下の装置に適用されると、コマンドに対してある程度の解釈を追加する必要があることがある。例えば、オン／オフのコマンドが照明に送信されると、完全に明確にオンとオフをするが、同じコマンドがTVに送信されると、スタンバイモードへの出入りをする。
【００５３】
装置形式の記述の主な利点は、コントローラが特有の装置形式自体について認識していなくても、由来するものから装置を決定することができ、その装置についてある程度の認識をすることができ、それにより、(装置の観点から)ある程度少ない範囲で装置を制御することができる。
【００５４】
例えば、照明スイッチが装置のアドレスを取得し、その装置からシンプル装置記述を要求した場合について検討する。装置形式のフィールドは装置をTVとして特定するが、スイッチは認識している装置としてこの装置を認知しない。しかし、スイッチはまた、認識している‘基本装置’の派生であるという記述から定めることができる。最終結果として、スイッチは装置自体について何も認識していないにも関わらず、コントローラの機能(すなわちオンとオフ)の範囲までTVを制御することができる。装置は、スイッチがある程度まで依然として制御することができる基本装置に由来する限り、スイッチが製造されたずっと後に発明された‘XYZ’という真新しい分類の装置でもよい。
【００５５】
装置形式の階層は、２層だけ(最上位レベルの要素にコントローラと基本装置)を有してもよいが、少なくとも１つの更なる層及び／又は最上位レベルの要素が望ましい。これは、前述の基本装置の機能に準拠しない装置、すなわち基本的な‘オン’‘オフ’機能を有さない装置(例えばアラーム)に応じる。例示目的で、‘アラーム’形式の装置56が図４に示されており、当然のことながら、この‘アラーム’装置は、基本装置に由来する装置が有している必要がある通常のオン／オフ機能を実装しようとしない。従って、それは基本装置54自体と同じ階層のレベル58に位置する。
【００５６】
階層に対する第２の拡張も図４に示されている。すなわち、通常のTV装置64の下の拡張TV装置66である。ここで、拡張TV装置は基本装置54とTV装置64の双方の機能の全てを引き継ぐが、通常のTVに存在しないある程度の機能も有する。通常のTV装置を操作するように設計された通常のTVリモコンは、通常のTV装置の機能のレベルまで拡張TV装置を操作することができるが、拡張機能を制御することができない。
【００５７】
従って、HUCLプロトコルは、装置形式と機能を引き継いだ上位の装置を記述する拡張可能な機構を提供する。多レイヤの階層の概念は魅力的に思えるが、３又は４のレベルを超えて拡張すると、シンプル装置記述の大きさに影響を与え始めることになる。
【００５８】
HUCL内で、コントローラと制御可能な装置から装置記述を要求することができる。ある装置が“Get  Simple  Description”をコントローラ装置(例えばスイッチ)に送信すると、“コントローラ”の装置形式を含むシンプル装置記述を戻す。コントローラ装置はまた、製造者やモデル番号等のような更なる情報を提供する拡張装置記述を利用可能にしてもよい。
【００５９】
コントローラ装置により戻される装置形式が、装置形式のツリーに定められた異なるコントローラ形式の装置の階層が存在しない単に“コントローラ”52であることに特に留意すべきである。この理由は、前述のように、プロトコルとメッセージを小さく簡単に保持しようとするためである。スイッチ、TVリモコン、PVRリモコン等のように基本コントローラに由来する異なるコントローラ形式を有することができると考えられ得る。しかし、広範囲の装置を制御可能なユニバーサル・リモコンのようなインテリジェントコントローラで問題が生じる。全ての可能なコントローラ形式を単一の装置記述に含めることにより、潜在的に長いメッセージを生じることになり、初期のシンプル装置記述を簡単にしようとする理念に反する。コントローラ装置の正確な機能を決定するために、異なる機構が使用される。
【００６０】
コントローラ装置の機能を決定する第１の手段は、コントローラ装置で許可されており、装置名(例えば“ユニバーサル・リモコン”)のような情報を含んでもよい拡張装置記述によるものであり、これはテキスト情報でありアプリケーションソフトウェアにより直接解釈可能ではないが、それはユーザに提示され、コントローラについて情報に基づく選択を行う際に助けになり得る。
【００６１】
装置がコントローラについて更に決定する第２の手段は、それにクエリを行うことによるものである。
【００６２】
クエリの使用は、装置についての情報をゆっくりと供給する強力な機構であり、それがない場合には、全体で提供されると要求者に過負荷をかける。
【００６３】
コントローラ形式の各装置は、他の装置が特定の装置形式を制御可能であるか否かを尋ねる手段を提供する120(図５)。クエリで渡された装置形式は、シンプル装置記述で使用されるもの(すなわち装置形式の階層で定義されたもの)と同じフィールドである。コントローラは、クエリで渡された装置形式又はその装置形式が付随する装置形式であるコントローラのメモリ14に格納されたリストにおける最下位の装置形式を返信することにより、装置を制御できるレベルを返信する122。例えば、簡単なスイッチは、拡張TV装置を制御することができるか否かについて尋ねられる。前述の図４に示される階層に基づいて、応答は、基本装置のレベルまで制御できるということになる。スイッチは、一般的に拡張TV装置の装置形式については何も認識していないが、その装置形式は引き継いだ装置も有するため、基本装置を特定することができ、制御可能な最下位の階層的に上位の装置形式としてそれを戻す。
【００６４】
コントローラはまた、シンプル装置記述で戻された装置形式をスイッチが制御できるか否かを決定するアルゴリズムを実装する(図６)。スイッチが装置のアドレスを発見すると、そのシンプル装置記述を装置に要求し124、その情報を受信すると126、スイッチがこの形式の装置をある程度まで制御できるか否かをテストする128。これは、クエリ処理120の結果と同じ応答を要する問題である。その結果、２つのクエリ処理120、122、124、126、128は簡単なスイッチ装置の複雑性をあまり追加しない。同じことがその他の簡単な装置にも当てはまる。
【００６５】
XMLの使用と、最も簡単な装置でのその圧縮及び解凍はほとんど負荷にならないと考えられ得る。プロトコルを記述するためにXMLを使用することは、将来の拡張に対して容易に拡張可能であり、記述と理解が比較的容易であり、構造化された情報を容易に処理することができ、‘インターネットドメイン’とすぐに適合する解決策を提供する。
【００６６】
(HUCL内で定められた)XMLでのタグ圧縮技術(tagged  compression  technique)を使用することにより、内容の構造を保持するためのある程度の追加のオーバーヘッドを用いて、従来の純粋のバイナリベースのプロトコルのサイズまで比較的冗長なプロトコルスタックを減少する。
【００６７】
圧縮形式のコマンドが提示されると、コマンド構造の情報とデータ値の記述用のテーブルを使用して、その他のバイナリベースのプロトコルを読み取るのと同じ方法で読み取られることができる。バイナリデータがXMLベースの表記から生じた可能性があるという唯一のヒントは、構造を表すデータの存在である。
【００６８】
HUCL仕様は、常にメッセージが圧縮形式でトランスポート媒体を通じて伝送されることを定める。しかし、簡単な装置では、アプリケーションは圧縮メッセージで直接動作してもよいため、HUCLソフトウェアスタック内の圧縮／解凍ソフトウェアの存在に対するその装置での必要性を除去する。この場合、アプリケーションは、(ROMのアプリケーションイメージの一部として)事前に圧縮された形式でシンプル装置記述を格納し、その他のバイナリプロトコルのパーサ(parser)と本質的に類似する、受信した圧縮プロトコルメッセージ用のパーサ(parser)を有する。如何なる応答メッセージもまた、圧縮形式で格納される必要がある。
【００６９】
この手法を用いて、このセクションを通じて使用される照明スイッチと照明設備の例のような最も簡単な装置は、減少したソフトウェアスタックで実施されることが可能になり、単一の装置が理解及び送信に必要とするコマンドの数が比較的少なくなる(照明をオンにする、照明をオフにする、トグルする(toggle)、現在の状態を取得する、装置記述を取得する等)と考えられ、アプリケーションソフトウェアのオーバーヘッドが最小になる。
【００７０】
このことは、装置に対してスケーラブルな解決策を提示し、実行され得る圧縮データで動作するアプリケーションを実装することが現実的になる。しかし、装置が複雑になると、スタックに圧縮／解凍機能を含めて、全XML表記でプロトコルメッセージをアプリケーションに使用させることが容易になるポイントが存在する。この分割ポイントは装置設計者に完全に依存しており、HUCLで定義又は記載されていない。
【００７１】
図７は、HUCLを構成する構成要素が組み合わさる方法を示している。構成要素はメモリに記録されるソフトウェアコンポーネントであることがわかる。
【００７２】
以下のセクションでは、HUCLソフトウェアスタック32を形成するレイヤと、それが提供する機能について更に詳細に説明する。
【００７３】
トランスポート適応レイヤ180は、サービスのセットに関係なく、HUCLスタックの上位レイヤに一貫したトランスポートを提供する。このレイヤの要件は、プロトコル仕様に詳細に定められている。
【００７４】
メッセージングレイヤ182は、HUCLソフトウェアスタックの大部分の機能を提供する。アプリケーションはHUCL  APIを通じてこのレイヤと通信し、必要なときに(例えばデータを受信したときに)アプリケーションにコールバックを実行する。
【００７５】
メッセージングレイヤ182はまた、何らかの初期エラー報告を処理し、必要に応じて承認を処理する。紛失メッセージの検査とメッセージを応答に結合する検査に使用されるメッセージIDとトランザクションIDもまた、このレイヤにより完全に処理される。
【００７６】
メッセージングレイヤ182はまた、メッセージを圧縮又は解凍するときに、圧縮／解凍サービス184を利用する。前述のように、アプリケーションは圧縮形式でメッセージを排他的に処理するため、そのサービスに呼び出しは行われず、それがランタイムスタックから除去され得る。
【００７７】
簡単に言えば、圧縮及び解凍サービスは、圧縮形式と解凍形式との間でHUCLメッセージを変換する手段をメッセージレイヤに提供する。システムのこの構成要素がローエンドの装置に存在せず、アプリケーションとの全てのデータ交換が圧縮されたメッセージで行なわれることも可能である。
【００７８】
アプリケーションプログラミングインタフェースAPI186は、全てのアプリケーションがHUCLソフトウェアスタックと通信するインタフェースである。特定のイベントが下位のレイヤで生じた結果として(例えばトランスポートスタックを介してメッセージが受信された結果として)HUCLスタックがアプリケーションに非同期のコールバックを行うという点で、通信は双方向である。
【００７９】
HUCLは、独立のトランスポートスタック34であり、これは、HUCLメッセージングプロトコルが有線と無線の双方の多様なトランスポートスタックの上位に構成され得ることを意味する。
【００８０】
HUCLは軽量プロトコルとして設計されているため、新興のZigbee(802.15.4)規格のような軽量のトランスポートスタックにも最適であるが、有線(例えばイーサーネット)と無線(例えば802.11b)の双方の広範囲の他のプロトコルに広まるTCP&UDP/IPの上位にも同様に位置することができる。
【００８１】
HUCLがトランスポートスタック34に実装されるためには、HUCLスタックのメッセージングレイヤに複数のサービスを提供できなければならない。このことは、これらの装置がトランスポートスタック自体に存在し得るか、又はHUCLスタックのトランスポート抽象レイヤの何らかの欠いたサービス(missing  service)を実装可能でなければならないことを意味する。これらのサービスは、アドレス指定やメッセージ配信や装置発見(例えばネットワークの他の装置のアドレスを発見すること)のような側面をカバーしてもよい。
【００８２】
プロトコル自体は、媒体214に記録されたドキュメントであり、図８に示すように以下の情報を有する。
【００８３】
全てのHUCLメッセージが準拠するフォーマットを定めた一般HUCLメッセージフォーマット200
制御プロトコルを形成する特有のメッセージを定めたメッセージ定義202
どのメッセージがいつ送信されたかと、メッセージ受信時のアプリケーションの要件を定めたメッセージシーケンス要件(message  sequencing  requirement)204
HUCLとそれを使用するアプリケーションの間の双方向インタフェースを定めたHUCL  API定義206
HUCLソフトウェアスタックのメッセージングシステム要件及び機能208
HUCLメッセージの圧縮機構を定めた圧縮アルゴリズム210
HUCLソフトウェアスタックがトランスポートシステム(例えばRFスタック)とインタフェース接続する方法を定めたトランスポート適応レイヤ定義212
従って、HUCLは単にメッセージフォーマットの定義だけではなく、メッセージ交換及び圧縮を包含する。前述のリストの後の４つの項目は、装置に存在するHUCLソフトウェアスタックを形成し、最初の３つの項目はスタックとアプリケーションが準拠しなければならない要件を定める。
【００８４】
この開示を読むことにより、他の変更形態と変形形態が当業者に明らかになる。そのような変更形態と変形形態は、ネットワークの設計と製造と使用の際に既に既知であり、ここに記載された機能に加えて又はその代わりに使用され得る相当物及び他の機能を有してもよい。この出願では、特許請求の範囲は特定の組み合わせの機能に対して策定されているが、当然のことながら、本発明と同じ技術的な課題の一部又は全てを緩和しようとしまいと、開示の範囲は明示的又は暗示的にここに開示されている如何なる新規な機能若しくは如何なる新規な機能の組み合わせ又はその一般化を含む。この結果、この出願は、この出願又はそれから導かれる如何なる出願の遂行の間に、そのような機能及び／又はそのような機能の組み合わせに対して新しい特許請求の範囲が策定され得るという予告を提示する。
【００８５】
特に、例で使用される特有のサブルーチン名は容易に変更され得る。装置を制御するコンピュータプログラムは、メモリ14に記録されたものとして示されているが、CDやフロッピー（登録商標）ディスク等のようなその他の多数の形式の記録媒体に記録され得ることを当業者は認識するであろう。
【００８６】
更に、照明設備と照明スイッチの非常に簡単な例が広く前述されたことに留意すべきである。更に多数の複雑な制御シナリオも可能であることを当業者は認識するであろう。
【図面の簡単な説明】
【００８７】
【図１】本発明の実施例による一対の装置を有するシステムを示したものである。
【図２】１つの装置のソフトウェアの概要を示したものである。
【図３】装置発見処理のフローチャートである。
【図４】装置形式の階層の概要である。
【図５】被制御装置の制御機能を被制御装置に通知するためにコントローラが実行するステップを示したものである。
【図６】被制御装置の制御機能を決定するためにコントローラが実行するステップを示したものである。
【図７】ソフトウェアの構成を示したものである。
【図８】HUCLプロトコルを示したものである。
【図９】シンプル装置記述メッセージを示したものである。
【図１】
2005535248.tif 000003
【図２】
2005535248.tif 000004
【図３】
2005535248.tif 000005
【図４】
2005535248.tif 000006
【図５】
2005535248.tif 000007
【図６】
2005535248.tif 000008
【図７】
2005535248.tif 000009
【図８】
2005535248.tif 000010
【図９】
2005535248.tif 000011
【国際調査報告】
2005535248.tif 000012
2005535248.tif 000013
2005535248.tif 000014