JP2008501202A

JP2008501202A - ローカルネットワーク化システム用の装置アブストラクションレイヤ

Info

Publication number: JP2008501202A
Application number: JP2007517573A
Authority: JP
Inventors: アンソニーアダムソン; ドウグラスアールホスキンス; ロビンジェイブラックウェル; フィリップエイルトランド
Original assignee: Koninklijke Philips NV; Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2004-05-24
Filing date: 2005-05-23
Publication date: 2008-01-17
Also published as: MXPA06013703A; WO2005117389A8; KR20070033338A; EP1757060A1; BRPI0511455A; TW200616398A; GB0411528D0; WO2005117389A1; CN1957583A; RU2006145862A

Abstract

ローカルネットワーク化システムが、処理プラットフォーム（１１０）と、住宅機器等の目標装置（１５１〜１５３）とを有する。上記プラットフォームは、オープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）のもののようなオープン・サービス・ゲートウェイ・フレームワークをサポートすると共に、目標装置（１５１〜１５３）を制御するためのアプリケーション（１３０）を実行する。上記目標装置は、各々、アプリケーション・プログラミング・インターフェース（ＡＰＩ，１３４）を介してアプリケーション（１３０）により操作することが可能なエンティティ（１３３）により表される。これらエンティティは装置タイプの共通の階層構造に従い、その場合において、この階層構造におけるより低い装置タイプを表すエンティティは該階層構造におけるより高い装置タイプの特性を受け継ぐ。これは、アプリケーションに対して一貫したＡＰＩを提供する。上記エンティティは、住宅定型制御言語（ＨＵＣＬ）のような共通言語を使用するアブストラクションレイヤの一部を形成することができる。各エンティティは上記フレームワークに装置サービスとして登録することができ、又は複数のエンティティ（１４７）を表す単一の装置サービス（１４６）を上記フレームワークに登録することができる。

Description

本発明は、ローカルネットワーク化システム、斯かるシステムに使用するプラットフォーム及び斯かるプラットフォームを動作させる命令に関する。

住宅環境内で機器をネットワーク化することへの大きな関心が存在し、近年、種々のネットワーク化プロトコルが開発されている。ユニバーサル・プラグ・アンド・プレイ・プロトコル（ＵＰｎＰ）は主にパーソナルコンピュータ周辺機器に採用されており、該プロトコルのオーディオ・ビジュアル（ＡＶ）拡張は、メディアサーバ又はメディアプレーヤ等のＡＶ装置が、同様の装置上でどのようなコンテンツが利用可能であるかを決定すると共に、斯かるコンテンツの装置間での伝送を制御するのを可能にする。ＵＰｎＰは、処理能力及び電力消費を含み、ホスト装置に大きな要求を行い得るような、かなり“重い”プロトコルと考えられる。結果として、ＵＰｎＰは、限られた資源しか有さず、それ以外では最小限の処理能力しか必要としないような低（電池）給電機器に使用するには理想的には適していない。ヨーロッパ・ホーム・システム（ＥＨＳ）プロトコル、ジグビ及びＸ１０等の他のプロトコルは、各々、住宅用機器を制御するために使用されている。ホームネットワークは広範囲の機器を含む傾向があり、斯かる機器は、強力な処理能力を備えるパーソナルコンピュータ及びメディアプレーヤから、小型機器、サーモスタット及び電灯スイッチ等の単純なオン／オフ命令のみしか必要としない単純装置まで多様である。

オープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）は、アプリケーション（又は“サービス”）が、住宅、車及び小さなオフィス等のローカルネットワークにおいて配備され、インストールされ、且つ、実行されるのを可能にすることを狙ったオープンな管理されたフレームワークである。斯かるローカルネットワークの心臓部はゲートウェイであり、該ゲートウェイはＯＳＧｉフレームワークを実行するＯＳＧｉサービスプラットフォームをサポートする。ＯＳＧｉサービスプラットフォーム仕様の最新公開版は、ＯＳＧｉアライアンスからの２００３年の３月のバージョン３であり、ＯＳＧｉに関する更なる情報はwww.osgi.orgで見付けることができる。該サービスプラットフォーム仕様の一部は、サービスプラットフォームに接続された装置のアクセスをカバーする。これを達成するために、該仕様は２つのタイプのエンティティを導入する。即ち、“プリンタ”、“マウス”、“電灯（ランプ）”等の概念を表す“装置エンティティ”及び“ＵＳＢ”、“シリアル”等の概念を表す“ドライバ”エンティティである。例えば、“ＵＳＢマウス”を表すために、ＯＳＧｉドライバ選択器エンティティは適切な装置及びドライバを選択し、これらを一緒にする。

オープンであり且つ拡張可能であるために、ＯＳＧｉは、これら装置エンティティに対するアプリケーションからの共通インターフェースも、装置エンティティとドライバエンティティとの間の共通インターフェースも定義していない。この結果、会社が自身の所有のアプリケーションプログラミングインターフェース（ＡＰＩ）を開発してしまい、これが当該仕様のオープンさを低減させている。

図１は、既存のＯＳＧｉ装置アクセス仕様の簡略化モデルを示す。アプリケーション１０は、特定のサービスを実施するソフトウェアを表している。この簡単なケースにおいて、アプリケーション１０は住宅内の２つの電灯２０、３０を制御し、これら電灯を１日の特定の時間においてオン及びオフする。制御されるべき第１の電灯２０は、ヨーロッパ・ホーム・システム（ＥＨＳ）プロトコルに従い動作する。制御されるべき第２の電灯３０は、ジグビ（ZigBee）プロトコルに従い動作する。ＥＨＳ及びジグビの両者は、住宅ネットワーク化用の既存のプロトコルである。各電灯２０、３０用のベースドライバ２２、３２は、新たなハードウェアを発見し、ＯＳＧｉフレームワークによる対応する“装置サービス”２５、３５を登録する。各装置サービス２５、３５は、制御されるべき実際のハードウェア装置２０、３０のソフトウェア表現である。アプリケーション１０は、自身が対話する各々の可能性のある電灯装置２５、３５について知らねばならず、当該アプリケーション１０を装置サービス２５、３５とインターフェースさせる各ＡＰＩの詳細を知らねばならない。電灯装置のＥＨＳ表現２５は、電灯装置のジグビ表現３５とは大幅に相違する。従って、アプリケーション１０は、簡単なアプリケーションに対しても複雑なソフトウェアとなる。更に、装置サービスは標準化されていないので、異なる売り手は、同じハードウェア装置（例えば、電灯２０）を、異なるドライバ２１及び装置サービス表現２５を用いて異なる方法で自由に表すことができる。第２のアプリケーション１１は、異なる売り手により供給されるが、電灯２０もオン及びオフする必要があるような例を考察すると、該第２のアプリケーションの開発者は、ＡＰＩ２６の詳細を知らねばならないか、又は電灯２０を制御することができる自身の装置及びドライバを供給しなければならない。

本発明は、ＯＳＧｉフレームワークのような、ローカルネットワーク化アーキテクチャ内での改善されたインターフェースを提供するものである。

従って、本発明の第１の態様は、ローカルネットワークにおける目標装置を制御するために使用するプラットフォームにおいて、オープン・サービス・ゲートウェイ・フレームワークをサポートすると共に、前記目標装置を制御するための少なくとも１つのアプリケーションを実行することができるプロセッサを有し、前記目標装置の各々はアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介して前記アプリケーションにより操作することが可能なエンティティにより表され、これらエンティティは装置タイプの共通の階層構造に従い、該階層構造においてより低い装置タイプを表すエンティティは、該階層構造においてより高い装置タイプの特性を受け継ぎ、これにより、アプリケーションに対して一貫したＡＰＩを提供するようなプラットフォームを提供する。

上記オープン・サービス・ゲートウェイ・フレームワークは、限定されるものではないが、好ましくはオープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）フレームワークである。

一貫した階層構造を持つエンティティの使用は、アプリケーションが目標装置と簡略化されているが、それでも能力のある態様で通信するのを可能にする。上記エンティティは、各装置固有及びネットワーク固有のＡＰＩから離れて抽象化すると共に、好ましくは共通の言語を使用するようなアブストラクション（抽象化）レイヤの一部を形成する。好ましくは、上記階層構造は、住宅定型制御言語（ＨＵＣＬ：Home Uniform Control Language）のような軽プロトコルの一部として設けられる。これは、アプリケーション開発者が当該システム上の各装置サービス（従って、目標装置）に標準のユーザに優しい方法でアクセスするのを可能にする。開発者は、アプリケーションを、ＯＳＧｉフレームワーク内の目標装置に対して高信頼度で使用することができるという確信をもって独立に書くことができる。加えて、当該システム上の“ＨＵＣＬドライバ”及び“ＨＵＣＬ装置サービス”オブジェクト間のインターフェースは、今や全ての対（pairing）の間で共通のＨＵＣＬインターフェースを使用して標準化される。これは、簡単なアプリケーションが、当該プラットフォームに異なるネットワーク化プロトコルにより接続された目標装置を、単一の装置サービスに基づいて制御するのを可能にする。新たな目標装置は、依然として既存のサービスアプリケーションは使用するが、新たなプロトコルを使用して追加することができる。ＨＵＣＬは、目標装置につなぐローカルネットワーク化プロトコルにインターフェースする、全ての装置サービス及びブリッジ（bridging）ドライバの間の共通言語として使用することができる。ＨＵＣＬを使用する他の利点はプロトコルの軽い性質であり、これはホスト装置に対する要求を低くさせる。ＨＵＣＬは圧縮されたＸＭＬメッセージを使用することができると共に、基本及び拡張記述を提供し、これはメッセージ処理のオーバーヘッドを減少させることができる。ＨＵＣＬの主たるフィーチャは、国際特許出願公開第WO2004/015926号、第WO2004/015927号、第WO2004/015928号及び第WO2004/015929号に記載されている。

ＨＵＣＬは、元々は、装置を制御するための軽量のプロトコルとして開発されたが、ＨＵＣＬがＯＳＧｉゲートウェイ内で使用するための理想的プロトコルを提供することもできることが理解された。ＨＵＣＬは、より低いレベルのベースドライバと一緒に、ネットワーク独立（共通言語）及びプロトコル独立（コマンドセット、パラメータ、機能等を含み、当該言語内での標準化された装置コマンド）の両方を与えるものである。他のプロトコルは、ブリッジする能力、複合装置のサポート、２以上のレイヤの副装置をサポートする能力又はＨＵＣＬにより提供されるオープンな仕様に欠け、従ってアブストラクションレイヤとして使用するには不適である。

アプリケーションは目標装置の“装置サービス”を介して通信し、該装置サービスは目標装置の装置タイプに対して固有であると共に、ＨＵＣＬバンドルからＯＳＧｉにおけるＵＰｎＰに使用されるものと同様の方法で得られる。これらの装置サービスは、アプリケーションに対して装置固有のジャバ・インターフェースを提供するので、“ヘルパ（helper）バンドル”と見ることができるが、ＸＭＬ又は圧縮されたＸＭＬメッセージを使用して低いレベルのドライバと通信することができる。目標装置がＨＵＣＬでないプロトコル（例えば、ＵＰｎＰ、Ｘ１０又はジグビ）を使用する場合、ＨＵＣＬドライバ（ブリッジドライバ）がＨＵＣＬから当該目標装置により使用されるプロトコルへ変換する。

装置サービスを扱う２つの主要な方法が提案される。第１の方法においては、各目標装置は、ＯＳＧｉフレームワークに登録されたＨＵＣＬ装置サービスにより表される。装置サービスは、これらが表す目標装置の機能、及び目標装置に従う装置タイプの階層構造を有する。階層構造を達成する１つの好ましい方法は、階層的ジャバクラス構造を使用することによるものであり、その場合、より低いレベルのジャバクラスは、これらが従属する一層高いレベルのクラスの特性を受け継ぐ。しかしながら、後の詳細な説明で一層完全に説明するように、この階層構造機能を達成する他の方法が存在する。第２の方法においては、単一の装置サービスがＯＳＧｉフレームワークに登録され、該装置サービスは、多数の副装置を表すことが可能なＨＵＣＬ複合装置である。各副装置は識別子により参照されると共に、第１の方法で使用された装置サービスのＨＵＣＬ等価版であり、これは装置タイプ及び機能の同一の階層構造に従う。第２の方法は、ＯＳＧｉフレームワークにより登録及び追跡されるべきエンティティの数を低減する利点を有する。

エンティティ又は装置サービスは、通常、個々のハードウェア目標装置にマッピングするが、ＯＳＧｉ仕様は、これに限られないことを記している。

本発明は、ＯＳＧｉフレームワークを実施化し、目標装置を制御するような如何なるプラットフォームにも適用可能である。これは、住居用ゲートウェイ、セットトップボックス、ＰＣ、パーソナル・デジタル・アシスタント（ＰＤＡ）、メディア・サーバ及び他の消費者向け電子又は医療装置を含む。

ここで述べる機能は、ソフトウェア、ハードウェア又はこれらの組み合わせで実施化することができる。本発明は、幾つかの別個のエレメントを有するハードウェアにより、及び適切にプログラムされたコンピュータにより実施化することができる。従って、本発明の他の態様は、ローカルネットワークにおける目標装置を制御するプラットフォームのための命令であって、これら命令は、前記プラットフォームのプロセッサにオープン・サービス・ゲートウェイ・フレームワークをサポートさせると共に、前記目標装置を制御するための少なくとも１つのアプリケーションを実行させ、前記目標装置の各々はアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介して前記アプリケーションにより操作することが可能なエンティティにより表され、これらエンティティは装置タイプの共通の階層構造に従い、該階層構造においてより低い装置タイプを表すエンティティは、該階層構造においてより高い装置タイプの特性を受け継ぎ、これにより、アプリケーションに対して一貫したＡＰＩを提供するような命令を提供する。

上記ソフトウェアは、当該装置の寿命の間における如何なる時点においてもゲートウェイにインストールすることができることが理解されるであろう。斯かるソフトウェアは、電子メモリ装置、ハードディスク、光ディスク又は他のマシン読み取り可能な記憶媒体に記憶することができる。該ソフトウェアは、マシン読み取り可能な担体上のコンピュータプログラム製品として供給することができるか、又はネットワーク接続を介して前記プラットフォームに直接ダウンロードすることができる。

本発明の更なる態様は、オープン・サービス・ゲートウェイ・フレームワークをサポートすると共に、ローカルネットワークにおける目標装置を制御するための少なくとも１つのアプリケーションを実行することができるようなプラットフォームと共に使用するためのエンティティのライブラリであって、各エンティティは、前記ネットワークにおける目標装置を表すと共にアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアプリケーションにより操作することができ、これらエンティティは装置タイプの共通の階層構造に従い、該階層構造においてより低い装置タイプを表すエンティティは、該階層構造においてより高い装置タイプの特性を受け継ぎ、これにより、アプリケーションに対して一貫したＡＰＩを提供するようなエンティティのライブラリを提供する。該ライブラリは前記ゲートウェイにより、又は上記プラットフォームによりアクセス可能な遠隔サーバによりホストされ得る。

以下、本発明の実施例を、添付図面を参照して例示のみとして説明する。

図２は、オープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）の住居用ゲートウェイに関する簡略化された全体モデルを示す。サービス・ゲートウェイ１１０は、住宅、事務所、車等に配置される。サービス・ゲートウェイ１１０は、ＯＳＧｉフレームワークをサポートするサービス・プラットフォーム１１２を含む。住宅内で種々のサービスを提供するアプリケーション１３０は、プラットフォーム１１２により実行されて、目標装置２０〜２３を制御する。アプリケーションは、消費者向け電子機器、白物、暖房及び換気、照明等の機器の制御を含む種々の目的を有することができる。目標装置２０〜２３は、電灯２０、電子機器２１又は如何なる他の電子装置も含むことができる。ゲートウェイ１１０は、ローカルネットワーク化プロトコルを使用して目標装置２０〜２３につながる。典型的な住宅は、ジグビ、Ｘ１０、ＵＰｎＰ、ＥＨＳ、ＫＮＸ及びエシュロン（Echelon）等の一連の目標ネットワークプロトコルに従って動作する目標装置を含むであろう。各ハードウェア装置に対する物理ネットワークレイヤは、無線（例えば、ジグビの場合のIEEE 802.15.4、IEEE 802.11等）又は有線（例えば、シリアルバス、イーサネット、ケーブル配線、電気ケーブル配線（Ｘ１０）等）であり得る。図２において、ネットワーク４０はジグビネットワークであり、ネットワーク４５はＸ１０ネットワークである。当該住宅の外の遠隔サーバ５０は、ゲートウェイ１１０と通信することができる。サービスはサーバ５０によりゲートウェイ１１０に供給することができるか、又は、幾つかの状況においては、サーバ５０上のアプリケーション１２０が住宅内の目標装置２０〜２３を制御することができる。上記遠隔サーバは、ネットワーク管理のために、及び新たなサービス又は更新されたサービスをゲートウェイ１１０に供給するためにも使用することができる。

図３は、ＯＳＧｉゲートウェイ１１０の一般的アーキテクチャを示す。サービスプラットフォーム１１２はＯＳＧｉフレームワークをサポートし、これは典型的には当該ゲートウェイ内のプロセッサにより実行されるソフトウェアにより適用される。ネットワーク内の目標装置を制御するアプリケーションは、サーバ５０上で遠隔的に（アプリケーション１２０）、又はサービスプラットフォーム１１２上でローカルに（アプリケーション１３０）実行することができる。本発明の一実施例によれば、住宅定型制御言語（ＨＵＣＬ）が、サービスプラットフォーム１１２によりサポートされるＯＳＧｉフレームワーク内のアブストラクションレイヤとして使用される。ローカルネットワーク内に存在する各目標装置１５１〜１５３は、“装置サービス”１３３により表される。これは、実際の物理的装置１５１〜１５３のソフトウェアでの表現である。完全な装置サービスは下記の情報を含む：
− ＨＵＣＬバージョン及び最小限サポートされるＨＵＣＬバージョンを含む、装置と対話するための基本情報；
− 装置タイプのリスト（ＨＵＣＬ装置タイプのコードのリスト、各コードは例えば電灯等の指定された装置タイプを表すように規格化されている）、この装置が制御することができる装置タイプの同様のリストを含む、装置を識別するための基本情報；
− 例えば、装置名、ロケーション・ストリング、製造者、モデル名、シリアル番号、ＵＩＵＲＬ（ユーザインターフェースＵＲＬ）等の種々の拡張データ；
− 目標装置へコマンドを送信すると共に、応答及びイベントを受信する機能。
更に、複数の目標装置を表すことができる複合装置は、該装置が表す副装置に対する参照を含む。

図１で使用された装置２５、３５とは対照的に、装置サービス１３３は階層構造を有している。これは、下記に説明するように、アプリケーション１３０が可能な限り大きな程度に目標装置を制御するのを可能にする。電灯、テレビジョン、冷蔵庫等の種々のタイプの目標装置（機器）は、各々、標準化された装置サービス１３３を有する。アプリケーション１３０が各装置サービス１３３と対話するのを可能にするＡＰＩは、良好に規定され、最早、所有物となるようなたいしたものではない。これは、アプリケーション１３０が装置サービス１３３と簡単な標準化された態様で通信するのを可能にする。斯かる階層構造を達成する一つの方法は、標準化された組のジャバ（登録商標）オブジェクト又はクラスタイプの階層構造を提供する他のプログラミング言語を使用することによるものであるが、他の方法も利用可能である。ＯＳＧｉフレームワーク内で動作するアプリケーション１２０、１３０は、目標装置により何のタイプのネットワーク化プロトコル（例えば、ＵＰｎＰ、ジグビ等）が使用されるかを知る必要はなく、これは当該アプリケーションを大幅に簡略化させる。複数のアプリケーションが、同一の装置サービス及びＡＰＩを使用することができる。

ＨＵＣＬバンドル１４０は、ドライバ１４１、１４２、１４３を接続し、ＯＳＧｉフレームワークに装置サービス１３３を登録し、ＨＵＣＬ管理システム等の一般的管理フィーチャを提供する。ジグビ及びＵＰｎＰ用のドライバ１４１、１４３は、各々、単一のエンティティとして示されている。しかしながら、これらドライバは、Ｘ１０用のドライバに関して示したのと同様の態様で、ベースドライバ１６２と、該ベースドライバ１６３の機能の幾つかを使用する特殊化（refinement）ドライバ１４２により分割することもできる。装置サービス１３３が自身をＯＳＧｉフレームワークに登録し、イベント予約を管理し（後に詳述する）、ＨＵＣＬメッセージをドライバに渡すのを可能にすると共に、斯かるドライバが目標ネットワークにより使用されるプロトコルへの翻訳の全てを実行するのを可能にすることにより、中央管理エンティティの役割を最小化することが可能である。この場合、ＨＵＣＬバンドル１４０の主たるタスクは：
− 中央管理；バージョンＩＤ等を記憶する；
− ドライバ及び装置サービスを追跡する（ＯＳＧｉフレームワークの関連する予約メカニズムを使用することによる等）；
− 装置サービスを登録する（図５Ａにおいては各装置サービスに対して、図５Ｂにおいては、装置サービスは複合装置に対してのみ登録することができる）；
− ＯＳＧｉドライバのロケータ対話（又は、低レベルベースドライバとして働くＨＵＣＬドライバに対するネットワーク対話）に参加する；
− イベント予約を管理する（必要に応じてイベントを送ることができるように）；
− ＨＵＣＬを使用して通信する；
− プロトコル翻訳（ＨＵＣＬと目標ネットワークプロトコルとの間の）を実行する；
− プログラマに優しいジャバＡＰＩから／へＨＵＣＬメッセージストリングを整理（marshall）／分解（unmarshall）する。

ドライバ１４１、１４２、１４３は、目標ネットワーク上の目標装置を管理し、これら目標装置をＯＳＧｉフレームワーク内のＨＵＣＬ装置サービス１３３として提示する。これは、装置サービス１３３が、標準化されたＨＵＣＬインターフェースを介してドライバ１４１、１４２、１４３と通信するのを可能にする。ドライバ１４１、１４２、１４３は、ジャバ、ネイティブコードで書くことができるか、又はジャバとネイティブコードとの混合で書くことができる。目標ネットワークドライバが存在する場合、他のネットワークもＨＵＣＬを使用することができるように、ＨＵＣＬブリッジドライバが標準のＨＵＣＬＡＰＩに変換する。

図４は、ＨＵＣＬアブストラクションレイヤを実施化したゲートウェイにおける、図１と同様のシナリオを示す。電灯を制御するアプリケーション１３０は、所定の時間で２つの電灯２０、３０をオン／オフする。この場合、各電灯２０、３０は、標準化されたＡＰＩ１３４を有する共通の汎用電灯装置サービス１３３により表される。アプリケーション１３０はＡＰＩ１３４を介して電灯装置１３３に対し命令を、目標ハードウェア装置がＥＨＳネットワークに接続された電灯２０であるか、又はジグビネットワークに接続された電灯３０であるかに無関係に同じ態様で渡すことができる。ＨＵＣＬ／ＥＨＳドライバ１４４は、ＨＵＣＬレイヤをＥＨＳプロトコル用のドライバにブリッジする。同様に、ＨＵＣＬ／ジグビドライバ１４１は、ＨＵＣＬレイヤをジグビプロトコル用のドライバにブリッジする。

図５Ａ及び５Ｂは、ＨＵＣＬバンドル１４０の２つの主たるオプションを示す。第１に、図５Ａにおいて、ＨＵＣＬバンドル１４０はベースドライバとして動作し、個々のＨＵＣＬ装置サービス１３３（各々が目標装置２０を表す）をＯＳＧｉフレームワークに登録する。ＯＳＧｉフレームワークは、サービス・リポジトリ（即ち、登録された装置サービス１３３の照会可能なリスト）を提供する。代替として、ＨＵＣＬバンドル１４０はＥＨＳベースドライバ１６０により発見された新たな装置を聴取し、次いで、これらをＨＵＣＬ装置に翻訳することができる。この場合、ＨＵＣＬバンドル１４０は、ベースドライバというよりも、特殊化（refining）ドライバである。ＨＵＣＬバンドル１４０と装置サービスとの間のインターフェース１６０を介しての全ての通信は、SendHUCLMsg()及びReceiveHUCLMsg()等のＡＰＩコールの形態である。アプリケーション１３０はＨＵＣＬ装置サービス１３３に対する機能をコールし、これはブリッジドライバ１４４と直接的に又は間接的に通信する。ＨＵＣＬバンドル１４０は全ての既存のブリッジドライバ１４４を追跡する。

図５Ｂにおいて、ＨＵＣＬバンドル１４０は自身をＯＳＧｉフレームワークにＨＵＣＬ装置サービスとして登録する。この場合、該ＨＵＣＬ装置サービスはＨＵＣＬ複合装置１４６である。複合装置１４６は多数の装置サービス１４７を表すことができ、これは、目標ネットワーク上に多数の目標装置２０が存在する場合に、より少ないシステム資源を使用する故に利点を有する。一例として、１０個の異なる目標装置２０が存在する場合、図５Ａに示した構成においては、これは１０個の装置サービスがＯＳＧｉフレームワークに登録されることを要するであろう。これに対し、図５Ｂに示す複合装置構成においては、１個の複合装置１４６のみがＯＳＧｉフレームワークに登録される。ＨＵＣＬ複合装置の概念は、国際特許出願公開第WO2004/15927号に記載されている。これは、多数の目標装置２０に一層容易に対処することができるので、当該システムを一層スケーラブルにさせる。ＨＵＣＬバンドル１４０とアプリケーション１３０との間のＡＰＩ１６５（図５ＡにおけるＡＰＩ１６０と等価である）の主たる構成要素は、SendHUCLMsg及びReceiveHUCLMsg()なるコマンドである。これらのコール内では、各メッセージ内でＨＵＣＬ複合装置１４６における何の副装置１４７が識別されるかを識別するために何らかの追加のアドレス指定情報が必要とされるが、メッセージ処理の全体の量は減少される。幾つかの段取りコマンド以外では、これらのみがＡＰＩ１６５に必要とされるコマンドである。複合装置１４６の使用は、ゲートウェイ１１０とバックエンドサーバ５０との間、又はジャバ-ネイティブ・インターフェース（ＪＮＩ）を介しての何れかにおける一層単純なインターフェースを可能にする。国際特許出願公開第WO2004/015956号に記載されたＨＵＣＬプロトコルのフィーチャによれば、アプリケーション１３０は装置サービスの簡単な記述及び拡張された記述に関して複合装置１４６に照会することができる。

図６Ａ〜８Ｂは、３つの典型的な動作に関して、図３のフレームワーク内で発生するメッセージの流れの例を示している。各例において、メッセージの流れは、個々の装置サービスが使用されるような状況（図５Ａにおけるような）、並びに汎用ＨＵＣＬバンドル及び複合装置１４６が使用されるような状況（図５Ｂにおけるような）の両方に関して示される。明瞭化のために、これらの及び後の例においては疑似コードが使用される。また、簡略化のために、当該例は目標装置として電灯２０を示すが、目標装置がもっと複雑であり得ることは理解されるであろう。

図６Ａ及び６Ｂは、新たな目標装置２０が当該システムに追加された場合に発生するメッセージの流れを示している。図６Ａは、個々の装置サービスが使用される場合のメッセージの流れを示す。新たな装置（電灯２０）が当該システムに最初に追加された場合、これは、ＥＨＳドライバ１６０により認識され、ステップ２０１においてバス活動が生じる。

ドライバ１６０は、ＨＵＣＬ／ＥＨＳドライバ１４４を介してＨＵＣＬバンドル１４０に、
eventListener.indicate(
EHSDriver, NEW_DEVICE, <type>)
なる形のメッセージ２０２を送信する。ステップ２０３において、電灯を表す新たな装置サービス１３３が‘myHUCLLamp2’なる名称で作成され、
Framework.registerNewDevice(myHUCLLamp2)
なる機能がＯＳＧｉフレームワーク上でコールされ、該新たな装置サービス１３３を登録する。該機能は、ドライバ１４４、ＨＵＣＬバンドル１４０又は装置サービス１３３自体によりコールすることができる。

ステップ２０４において、アプリケーション１３０内のサービストラッカは、新たな装置サービス‘myHUCLLamp2’を通知される。ＯＳＧｉのサービストラッカのフィーチャは、ＯＳＧｉサービスプラットフォーム仕様（バージョン３の１９章）に一層詳細に記載されている。

ステップ２０１に戻ると、新たな目標装置が当該システムに参加する正確な態様は、目標ネットワークプロトコルに従い変化する。幾つかのプロトコルにおいては、新たな目標装置２０はバス上に“新たな装置”イベントを生じさせる。他のものにおいては、新たな目標装置は目標ネットワーク内のポーリングメカニズムにより発見される。Ｘ１０の場合、新たな装置の指示は存在せず、斯かる装置は当該システムにユーザにより手で追加されねばならない。益々、安全要件はユーザが対話に関わることを必要とする。ＷｉＦｉの場合、ユーザが、一旦、新たな目標装置に対する暗号キーを入力すると、ゲートウェイ上の低レベルドライバ１６０が該新たな装置を識別し、記述を要求することができる。ＨＵＣＬ／ＵＰｎＰブリッジドライバ１４３は、これを認識し、該新たな装置識別は当該スタックを上まで続く。

図６Ｂは、汎用ＨＵＣＬバンドル及び複合装置１４６が使用される場合のメッセージの流れを示す。新たな装置（電灯２０）が当該システムに最初に追加されると、これは、ＥＨＳドライバ１６０により認識され、ステップ２１１においてバス活動が生じる。前と同様に、ドライバ１６０は、ＨＵＣＬ／ＥＨＳドライバ１４４を介してＨＵＣＬバンドル１４０に、
eventListener.indicate(
EHSDriver, NEW_DEVICE, <type>)
なる形のメッセージ２１２を送信する。しかしながら、この場合、該新たな装置はＨＵＣＬ複合装置１４６内の副装置として表される。該副装置に関して記憶される情報は、前述したサービス装置に関して記憶される情報のＨＵＣＬ等価版であり、実際の装置の上の階層構造における装置タイプのリストを含む。ＨＵＣＬバンドルのリスナとして予約された全てのアプリケーション１３０には、
HUCLEvent(“<deviceDescriptionChanged>”)
なるメッセージ２１３が送信される。アプリケーション１３０は、ＨＵＣＬバンドル１４０のリスナとして予約される。アプリケーション１３０内のイベントリスナは、ステップ２１４において、ＨＵＣＬバンドル１４０に対する更新を通知され、新たに追加された副装置を発見する。該新たに追加された副装置は、ＯＳＧｉフレームワークに明示的には登録されない。

図７Ａ及び７Ｂは、既存の装置が当該システムから削除された場合に発生するメッセージの流れを示している。図７Ａは、個々の装置サービス１３３が使用される場合のメッセージの流れを示す。既存の装置（電灯２０）が当該システムから削除された場合、これは、ＥＨＳドライバ１６０により認識され、ステップ２２１においてバス活動が生じる。ドライバ１６０はＨＵＣＬ／ＥＨＳドライバ１４４を介してＨＵＣＬバンドル１４０に、
eventListener.indicate(
EHSDriver, GONE_DEVICE,ID)
なる形のメッセージ２２２を送信する。ステップ２２３において、‘myHUCLLamp2’装置サービスが停止される。アプリケーション１３０のサービストラッカは、ステップ２２４において、装置サービス‘myHUCLLamp2’の削除を通知される。

次に、図７Ｂは、汎用ＨＵＣＬバンドルが使用される場合のメッセージの流れを示す。既存の装置（電灯２０）が当該システムから削除された場合、これは、ＥＨＳドライバ１６０により認識され、ステップ２３１においてバス活動が生じる。ここでも、ドライバ１６０はＨＵＣＬ／ＥＨＳドライバ１４４を介してＨＵＣＬバンドル１４０に、
eventListener.indicate(
EHSDriver, GONE_DEVICE,ID)
なる形のメッセージ２３２を送信する。該電灯を表す副装置は、ステップ２３３においてＨＵＣＬ複合装置１４６から削除される。
HUCLEvent(“<deviceDescriptionChanged>”)
なる形のメッセージが全ての予約リスナに送信され、これらリスナに当該削除を通知する。ステップ２３４において、アプリケーション１３０のイベントリスナは、該更新を通知され、削除された副装置を発見する。ここでも、ＯＳＧｉフレームワークには該削除は明示的には通知されない。ユーザが、装置の削除を、ユーザインターフェース上で確認アイコンをクリックすること等により確認するのが好ましい。

第３の例において、図８Ａ及び８Ｂはアプリケーション１３０が当該システムに既に登録された装置を制御したい場合に発生するメッセージの流れを示す。この例において、アプリケーション１３０は電灯２０をオンするための制御メッセージを送信し、電灯２０は当該システムに‘myHUCLLamp’なる名称で登録されている。図８Ａは、個々の装置サービス１３３が使用される場合のメッセージの流れを示す。最初に、アプリケーション１３０はステップ２４１においてＨＵＣＬ電灯装置サービス１３３に対して、
myHUCLLamp.on()
なる形のメッセージを送信する。ステップ２４２において、電灯装置サービス１３３は、
sendHUCLMsg(“…
<param1>255</param1>…”)
なる形のＨＵＣＬメッセージを送信する。これは、ＨＵＣＬ／ＥＨＳドライバ１４４により、ドライバ１６０に送信される（２４３）、
EHSDev5.sendEHSMsg(
TURN_ON)
なるメッセージに翻訳される。該翻訳は、単に上記メッセージのささいな再フォーマットであるか、又はルックアップテーブルの使用によるコマンドの翻訳を含み得る。最後に、ドライバ１６０は目標ネットワークのフォーマットのメッセージ２４４を電灯２０に送出し、これが電灯２０をオンさせる。

図８Ｂは、汎用ＨＵＣＬバンドル１４０が使用された場合のメッセージの流れを示す。最初に、アプリケーション１３０はステップ２５１においてＨＵＣＬバンドル１４０に対して、
sendHUCLMsgAddressedTo(DevID, “…
<param1>255</param1>…”)
なる形のメッセージを送信する。これは、複合装置サービス１４６のうちの特定の副装置１４７に供給され、その場合において、‘DevID’は、ＨＵＣＬ複合装置１４６のうちの電灯２０を表す副装置１４７を識別する識別子である。ＨＵＣＬバンドル１４０は制御メッセージを送出し、該メッセージはＨＵＣＬ／ＥＨＳドライバ１４４によりステップ２５２において、
EHSDev5.sendEHSMsg(TURN_ON)
なる形のＥＨＳメッセージに翻訳される。このメッセージはＥＨＳドライバ１６０に供給される。最後に、ドライバ１６０は目標ネットワークのフォーマットのメッセージ２５３を送出し、該メッセージが電灯２０をオンさせる。

図５Ａに戻ると、ＡＰＩ１３４を介してアプリケーション１３０とＨＵＣＬ装置オブジェクトとの間で受け渡されるメッセージは、LampOn(), LampOff(), TVOn(), TVOff(), SetChannel(int num), SetVolume(int level)のように標準化される。アプリケーション１３０の開発者には、これらの標準の組が提供される。

上述したように、ＨＵＣＬは階層構造の装置サービスを有する。図９Ａは、頂部に汎用ＨＵＣＬ装置３０１を有する装置サービス３００の例示的階層構造を示す。機能‘getSubDevices()’は、もし存在するならば、次のレイヤの副装置の装置サービスを戻す。該階層構造を下に移動すると、装置サービスは増加されたレベルの詳細／機能を有する。このように、装置サービス３０２は、オン／オフする能力を持つような目標装置を表す。該階層構造の左側を下に移動すると、装置サービス３０３はベーシックな電灯を定義し、該電灯は上の等級のフィーチャを受け継ぐ（即ち、これもオン／オフすることができる）。装置サービス３０４は、調光可能な電灯、即ち可能な値の範囲内で特定の輝度値に設定される機能を持つ電灯、を定義する。装置サービス３０４も、上の３０２及び３０３のフィーチャ（即ち、電灯であり、オン／オフすることができる）を受け継ぐ。該階層構造の右側を下に移動すると、装置サービス３０５はドアベルを定義し、該ドアベルはＨＵＣＬオン／オフ装置３０２のフィーチャを受け継ぐ。この例では、アプリケーション（例えば、アプリケーション１３０）が、“HUCLDimmableLamp”なるタイプの装置にどのように対話すべきかが分からない場合、該アプリケーションは依然として“HUCLBasicLamp”の定義を、又はベーシックな“HUCLDevice”の定義さえも、その機能を上記装置が理解するであろうとの確実性を以って使用することができる。効果的には、ＨＵＣＬはアプリケーションが“階層構造ツリーを上に歩む”のを可能にし、もし、アプリケーションが装置タイプ（例えば、調光可能な電灯）を認識することができないことが分かった場合は、装置サービス１３３の一部として提供される装置タイプリストに掲げられた他の装置タイプをチェックする。同様に、何かをオン／オフさせる能力を有するアプリケーションは、電灯、ドアベル又はオン／オフされることが可能な如何なる他のタイプの装置も駆動することができる。何故なら、全ての目標装置を表す装置サービスが、階層構造に従うからである。目標装置は、自身の“最低の”最も正確な表現の上の各レベルにおいて表されている。この方法は、開発者が特定の装置の全詳細を知らないような状況でも、装置が可能な最大限の程度に操作されるのを可能にする。

図９Ｂは階層構造の他の例を示す。プラットフォーム（この場合は、パーソナル・デジタル・アシスタント（ＰＤＡ）３２０）は、上述したＯＳＧｉフレームワーク及び制御アプリケーションをサポートする。ＰＤＡ３２０上で動作するアプリケーションは、調光可能な電灯３０４又は電灯３０３により使用される特定のコマンドを認識することはできないが、該アプリケーションはOnOffDevice用の装置タイプコード（即ち、オン／オフすることが可能な装置のタイプを表すコード）を認識し、従って電灯３０４の調光機能は制御することはできないが、電灯を有用な程度に制御することはできる。同様に、ＰＤＡ３２０上で動作するアプリケーションは“サーモスタット”３０８のレベルまでの装置サービスのみをサポートし、医療用又は工業用のサーモスタットのフィーチャを制御する能力は有さない。ＰＤＡ３２０上で動作するアプリケーションは、医療用サーモスタット３０９又は工業用サーモスタット３１０の進んだフィーチャを使用することはできないが、サーモスタット３５７、３５８の各々をオン及びオフし、基本的な温度の読みを得ることはできる。これは、目標装置の製造者が或るレベルまで相互動作する製品を提供するのみならず、斯かる製造者の製品に他の製品から差別化するような固有のフィーチャを追加させることを可能にする。図５Ｂを参照して先に説明した複合装置モデルにおいては、複合装置１４６内の各副装置１４７に関して記憶される情報は、この同じ階層構造に従う。

上述したように、多くのプログラミング言語が関連した機能を提供する。例えば、ジャバ（登録商標）においては、各オブジェクトは“クラス”のインスタンス生成であり、クラスは他のクラスを拡張して、クラス階層構造を形成することができる。図９Ａ及び９Ｂに示す階層構造は、ジャバ又は他のプログラミング言語における一群のオブジェクトのクラス階層構造を用いて実施化することができる。他の例として、階層構造は、プログラミング言語の“組み込み型”クラス階層構造を使用しない方法で実施化することもできる。実施化されるプログラミング言語のクラス階層構造を使用しないで装置階層構造を動作させる一つの方法は、単一の固定のクラス（多分、HUCLDeviceと呼ばれる）のインスタンス生成により装置を表すことであり、これは“sendMessage (commandText)”,“setVariable (variableID, variableValue)”又は“invokeCommand (commandID, commandParameter1, ...)”のような汎用の非装置固有の方法のみを有する。この場合、階層構造は紙上に文書化され、ソフトウェアコンポーネントのプログラミングにおいて、個々の呼出しに対する応答をコーディングすることにより（即ち、非オブジェクト指向コード）、又は非露出ＡＰＩのオブジェクト指向設計により（即ち、オブジェクト指向コードは使用するが、これをＡＰＩでは表現しない）、実施化される。各場合において、拡張装置が、簡単な装置により理解されるメッセージ、変数及び／又はコマンド呼出の全てに対し正しく反応すると共に、幾つかの追加のコマンド及び機能に対する応答を理解及び実施化することも期待することができる。この第２の状況においては、装置階層構造は依然として存在し（少なくとも概念的に）且つ有用であるが、プログラミング言語の組み込み型クラス階層構造を用いることにより直接的には実施化されない。

一例として、機能On()及びOff()をサポートするベーシックな電灯と、機能Dim()もサポートする複雑な電灯を考察しよう。非オブジェクト指向コードにおいては、これを、スイッチステートメントを使用して実施しなければならない。以下は、ベーシックな電灯のためのＨＵＣＬ装置ソフトウェア用の例示的疑似コードである：

複雑な電灯のためのＨＵＣＬ装置ソフトウェア用の疑似コードは：

ここで、“複雑な電灯（ComplexLamp）”用のコードは、“電灯（Lamp）”の機能の全てを果たすと共に、ComplexLamp仕様に定義された追加のコマンドも果たす。両プログラムは、機能On()、Off()及びUnknownCommand()も果たし、ComplexLampは付加的に機能Dim(dimLevel)を果たす。この例は、装置階層構造をプログラミング言語のクラス階層構造を使用せずに実施化する。上記階層構造を、この第２のやり方ではあるが、幾つかのオブジェクト指向プログラミングのフィーチャを用いて実施化することも可能である。複雑な電灯に対するＨＵＣＬ装置ソフトウェアのための例示的疑似コードは：

ここで、アプリケーションに提供されるＡＰＩは先の例と同じであり、プログラミング言語のクラス階層構造を直接的には使用しない。しかしながら、この例では、ソフトウェアを一層明瞭に又は一層保守容易にするために、複雑な電灯用の疑似コード内でComplexLamp及びLampなるクラスが使用されている。

目標装置は、開発者から如何なる低いレベルのＨＵＣＬコードも隠蔽するような態様で制御される。図５Ａのモデルにおいては、装置サービスクラス自体が高いレベルの方法コール(例えば、LampOn(), SetChannel(int num))を低いレベルのＨＵＣＬコードに翻訳する責任を負う一方、図５Ｂでは、ラッパ機能１６２が使用される。ラッパ機能は、開発者に優しい高レベルのジャバコマンドの低レベルＨＵＣＬコードへの翻訳を実行する。

図８Ａ及び８Ｂには、アプリケーション１３０が如何にして制御メッセージを目標装置２０に送出することができるかが示されていた。これは、アプリケーションが、目標装置をアプリケーション１３０に分かる時間にオン／オフすることを要する場合に生じ得る。しかしながら、アプリケーションが目標装置において発生する特定のイベントに応答することが望ましいような状況も存在する。一例として、移動センサの形態の目標装置が部屋内の移動を検出した場合、ゲートウェイ１１０で動作している保安アプリケーションに通知し、該アプリケーションがユーザに警告することができるようにするのが望ましい。既存のＯＳＧｉフレームワークは、この種の通知をサポートするメカニズムを提供していない。

図１０はイベントの警報アプリケーション用の簡単なメカニズムを示す。最も低いレベルにおいて、ドライバ１６０は、数秒毎のように、周期的に目標装置２０をポーリングする。該目標装置２０の状態の変化があった場合、ドライバ１６０は装置サービス１３３に通知する。ドライバのＡＰＩから、如何なる状態の変化も検出することができる。これは、ドライバ１６０からＨＵＣＬバンドル１４０に対する方法コールにより、又はＨＵＣＬバンドル１４０がドライバ１６０をポーリングして該ドライバの状態を監視することにより達成することができる。ＨＵＣＬバンドル１４０は、ドライバ１６０から得られた情報をＨＵＣＬイベントメッセージに整形する。次いで、これらのイベントは装置サービス１３３に渡され、該装置サービスは斯かるイベントをジャバイベントオブジェクトに編成する。アプリケーション１３０は、これらアプリケーションが制御する又はこれらアプリケーションが状態を通知されることに関心のある装置バンドルを予約する。各装置サービス１３３は、リスニング予約リスト１８０を維持し、該リストは関心を登録した（例えば、登録する際に、java.util.Vectorに各々を追加する）アプリケーションを掲載する。各アプリケーションは、イベントの通知を受信するためのイベントリスナ１８２を含む。ドライバ１６０により送信され、電灯の新たな状態を示すメッセージは、装置サービス１３３により受信される。装置サービス１３３は、報告可能なイベントが発生したかを決定し（１８３）、もしそうなら、登録された（１８０）全ての関心のあるアプリケーションに通知する。

以下、このメカニズムを使用する例を、調光可能な電灯である目標装置に関して説明する。図９Ａに示した階層構造によれば、調光可能電灯（DimmableLamp）装置３０４は、ＨＵＣＬベーシック電灯装置３０３及びオン／オフ装置（OnOffDevice）３０２の機能を拡張する。したがって、イベント階層構造が、このオブジェクト階層構造を鏡写するのが好ましい。これは、DimmableLamp装置サービスに予約されたアプリケーションも、全てのオン／オフイベントの通知を受信することを意味する。多くの高いレベルのクラスのイベントを受け継ぐ装置サービスにより表された、もっと複雑な目標装置の場合、アプリケーションは、該装置サービスにより受け継がれた全てのイベントの通知を受信するであろう。階層構造的装置サービスによるのと同様に、これは、アプリケーション開発者に対して簡単ではあるが、それでも強力なツールを提供する。付録は、この例におけるイベント階層構造を実施化するためのコードの更なる詳細を含んでいる。

前述したように、ＨＵＣＬ管理エンティティは、ドライバ及び装置サービスを登録する責任を負う。ＯＳＧｉフレームワークは、全ての関心バンドルに、当該システム上の全ての新たな装置サービスの到来を通知するためのメカニズムを提供する。当該システム上にＨＵＣＬ管理バンドルを設けることにより、このバンドルは全ての新たな装置サービスの到来を聴取し、これら装置サービスがＨＵＣＬ装置を表すなら、これら装置サービスを装置サービスの集合に追加することができる。次いで、このバンドルは、この集合に対するアクセスを、これら装置サービスを使用する関心のある如何なる他のバンドルにも提供する。

上記コードの断片は、これらの装置サービスを使用することに関心のあるバンドルが、どの様にして、全ての装置サービスのリストをＨＵＣＬ管理バンドルから得ることができるかを示している。装置サービスは、これら装置サービスが実施化するＨＵＣＬ装置インターフェースに関して照会することができ、そのように使用することができる。このコードは、開発者が、装置に関心があるかを発見するために如何にして同質多形を使用するかの図示である。この例において、開発者はHUCLLamp及びHUCLDoorbellに関心がある。“instanceof”演算子は現在のHUCLDeviceが関心装置“のインスタンス（instance of）”であるかを調べるために使用される。もしそうなら、HUCLDeviceは、発見された装置のクラスに割り当てられる。かくして、該割り当てられたオブジェクトは該装置を制御するために使用することができる。

前述したゲートウェイは、汎用ＰＣ又は専用処理ユニット等の種々の処理プラットフォーム上で実施化することができる。図１１は、斯かる処理プラットフォームの主たる構成要素を示す。中央処理ユニット４０１は、前述したようにソフトウェアを実行して、ＯＳＧｉフレームワーク、アプリケーション及びＨＵＣＬアブストラクションレイヤをサポートする。典型的には、中央処理ユニット４０１は、ジャバ仮想マシン（ＪＶＭ）をサポートするネイティブなオペレーティングシステム（例えば、リナックスに基づく）を有する。上記ＪＶＭは、ＯＳＧｉフレームワーク及びアプリケーションをホストする。ハードディスクのような、不揮発性メモリ４０２及び揮発性メモリ４０３は、オペレーティングソフトウェア及び装置サービスのライブラリを記憶し、処理ユニット４０１により使用される。広帯域ＡＤＳＬ又はケーブルモデム等のモデム４０６は通信回線４０７につながり、該回線は当該ゲートウェイを、これもアプリケーションがサポートされ得るような遠隔サーバ（図２の５０）に結合する。広帯域モデム４０６はゲートウェイ１１０の外側でもよい。制御される装置への／からの制御メッセージは、ローカルネットワーク接続部４１５により伝達され、これら接続部は有線（４１２）及び無線（４１１）技術の組み合わせを使用する。特定のローカルネットワークをサポートするために、ローカルエリアネットワークカード及び無線、赤外線又は電力線（Ｘ１０）モデム等の適切なハードウェアを設けることができる。ユーザ入力は、キーパッド、キーボード、マウス又はタブレット等の入力装置４１０により、直接的にゲートウェイに供給することができる。他の例として、ユーザ入力は、ゲートウェイ１１０とローカルにネットワーク化されたリモートコントロールユニットから、又は通信リンク４０７から受信することもできる。一例として、ユーザが住宅から離れており、住宅内の機器を制御するためにゲートウェイに命令を送信したい場合、ユーザは遠隔端末と対話して、回線４０７を介しゲートウェイ１１０に命令を送信する。出力は、ディスプレイドライバ４０８及びディスプレイ４０９を介してユーザに直接提示するか、ローカルのリモートコントロールユニットへ、又はリンク４０７を介して遠隔端末へ供給することができる。バス４０５、又は異なるタイプのバスの組み合わせが、上記各ユニットを接続する。

多様なアプリケーション１３０を、ゲートウェイ１１０上で、又は遠隔サーバ５０上で実行することができる。これらの例は、所定の時間に電灯をオン及びオフさせることによる建物の占有の模擬、暖房及び換気の制御、ビデオレコーダのプログラミング、娯楽及び消費者用電子装置の制御のような住宅制御；建物の保安又は建物の占有者の健康の遠隔監視；遠隔故障報告／診断を含む。

尚、上述した実施例は本発明を限定するというよりは解説するものであり、当業者であれば添付請求項の範囲から逸脱することなしに他の実施例を設計することができることに注意すべきである。また、請求項において、括弧内に配置された如何なる符号も請求項を限定するものと見なしてはならない。また、“有する”及び“含む”なる用語は、請求項に記載されたもの以外の他の構成要素又はステップの存在を排除するものではない。

上記記載において、図面を参照して、処理プラットフォーム（１１０）及び住宅機器等の目標装置（１５１〜１５３）を有するローカルネットワーク化システムが説明された。該プラットフォームはオープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）のもののようなオープン・サービス・ゲートウェイ・フレームワークをサポートすると共に、目標装置（１５１〜１５３）を制御するためのアプリケーション（１３０）を実行する。目標装置は、各々、アプリケーション・プログラミング・インターフェース（ＡＰＩ、１３４）を介してアプリケーション（１３０）により操作することが可能なエンティティ（１３３）により表される。斯かるエンティティは装置タイプの共通の階層構造に従い、その場合において、当該階層構造における一層低い装置タイプを表すエンティティは、該階層構造における一層高い装置タイプの特性を受け継ぐ。これは、アプリケーションに対して一貫したＡＰＩを提供する。上記エンティティは、住宅定型制御言語（ＨＵＣＬ）のような共通言語を使用するアブストラクションレイヤの一部を形成することができる。各エンティティは、上記フレームワークに装置サービスとして登録することができるか、又は単一の装置サービスを、複数のエンティティを表すフレームワークに登録することができる。

付録

イベント報告フィーチャのための他の説明題材。

基本イベントクラスは：

であり得る。
予約アプリケーションにDimmableLamp装置上のイベントを通知するDimmableLampEventは、以下のように、クラスにより指定することができる：
public class DimmableLampEvent extends OnOffDeviceEvent {
static int BRIGHTNESS_CHANGED;

/* Overridden from OnOffDeviceEvent */
public int getEventTrigger();

public DimmableLampEvent(int trigger);
}

アプリケーションは、これらのイベントに対する関心を、適切なイベント・リスナ・インターフェースを実施化することにより登録する。OnOffDeviceのための斯様なインターフェースの一例は：
public interface OnOffDeviceListener extends EventListener {
public void onOffDeviceEventOccurred(OnOffDeviceEvent e);
}
である。

図１は、従来のＯＳＧｉフレームワークを使用して電灯を制御する例示的シナリオを示す。図２は、ＯＳＧｉ住居用ゲートウェイのための全体モデルを示す。図３は、本発明の一実施例によるＯＳＧｉフレームワークを示す。図４は、図３のフレームワーク上で実施化された、図１と同様のシナリオを示す。図５Ａは、図３のフレームワークを実施化する１つの方法を示す。図５Ｂは、図３のフレームワークを実施化する他の方法を示す。図６Ａは、新たな目標装置がネットワークに参加した場合に発生するメッセージの流れを示す。図６Ｂは、新たな目標装置がネットワークに参加した場合に発生するメッセージの流れを示す。図７Ａは、既存の目標装置がネットワークから削除された場合に発生するメッセージの流れを示す。図７Ｂは、既存の目標装置がネットワークから削除された場合に発生するメッセージの流れを示す。図８Ａは、アプリケーションが目標装置を制御する場合に発生するメッセージの流れを示す。図８Ｂは、アプリケーションが目標装置を制御する場合に発生するメッセージの流れを示す。図９Ａは、当該フレームワーク内で使用される装置サービスの階層構造の一例を示す。図９Ｂは、当該フレームワーク内で使用される装置サービスの階層構造の他の例を示す。図１０は、アプリケーションに目標装置内のイベントを通知するメカニズムを示す。図１１は、図３のフレームワークを実施化することができるプラットフォームの一例を示す。

Claims

ローカルネットワークにおける目標装置を制御するために使用するプラットフォームにおいて、オープン・サービス・ゲートウェイ・フレームワークをサポートすると共に、前記目標装置を制御するための少なくとも１つのアプリケーションを実行することができるプロセッサを有し、前記目標装置の各々はアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介して前記アプリケーションにより操作することが可能なエンティティにより表され、これらエンティティは装置タイプの共通の階層構造に従い、該階層構造においてより低い装置タイプを表すエンティティは、該階層構造においてより高い装置タイプの特性を受け継ぎ、これにより、アプリケーションに対して一貫したＡＰＩを提供することを特徴とするプラットフォーム。
請求項１に記載のプラットフォームにおいて、前記エンティティが、共通言語を使用する装置アブストラクションレイヤの一部を形成することを特徴とするプラットフォーム。
請求項２に記載のプラットフォームにおいて、前記アブストラクションレイヤが、前記共通言語と、前記目標装置とインターフェースするために使用されるプロトコルとの間でメッセージを翻訳するブリッジドライバを更に有することを特徴とするプラットフォーム。
請求項２又は請求項３に記載のプラットフォームにおいて、前記共通言語が住宅定型制御言語（ＨＵＣＬ）であることを特徴とするプラットフォーム。
請求項１ないし４の何れか一項に記載のプラットフォームにおいて、目標装置を表すエンティティが、前記フレームワークに装置サービスとして登録されることを特徴とするプラットフォーム。
請求項１ないし５の何れか一項に記載のプラットフォームにおいて、複数の目標装置を表すことが可能な装置サービスが前記フレームワークに登録され、各目標装置が該装置サービス内の個々のエンティティにより表されることを特徴とするプラットフォーム。
請求項６に記載のプラットフォームにおいて、前記装置サービスがＨＵＣＬ複合装置を有し、各目標装置が該複合装置の副装置であるようなエンティティにより表されることを特徴とするプラットフォーム。
請求項６又は請求項７に記載のプラットフォームにおいて、前記装置サービスとアプリケーションとの間のＡＰＩが、前記装置サービスにメッセージを送信するためのコマンドと前記装置サービスからメッセージを受信するためのコマンドとを有していることを特徴とするプラットフォーム。
請求項６ないし８の何れか一項に記載のプラットフォームにおいて、アプリケーションに、高レベルコマンドを前記ＡＰＩを介して使用される低レベルメッセージに翻訳するためにラッパ機能が設けられることを特徴とするプラットフォーム。
請求項１ないし９の何れか一項に記載のプラットフォームにおいて、アプリケーションが、前記装置タイプの階層構造の特定のレベルにおける目標装置を制御することができないと判断した場合、該アプリケーションが、前記目標装置を制御することが可能であるような前記階層構造における低いレベルを見付けることを特徴とするプラットフォーム。
請求項１０に記載のプラットフォームにおいて、前記エンティティが、特性が受け継がれているような前記階層構造における一層高い装置タイプのリストを含んでいることを特徴とするプラットフォーム。
請求項１０に記載のプラットフォームにおいて、前記アプリケーションが、前記装置タイプの階層構造に関する知識を使用することにより、前記目標装置を制御することが可能な前記階層構造における一層低いレベルを決定することを特徴とするプラットフォーム。
請求項１ないし１２の何れか一項に記載のプラットフォームにおいて、前記エンティティが、目標装置におけるイベントの発生を前記アプリケーションに通知するように構成されていることを特徴とするプラットフォーム。
請求項１３に記載のプラットフォームにおいて、エンティティが、イベントの発生を通知されることを欲するアプリケーションのリストを保持し、イベントが発生した場合に、これらアプリケーションに通知することを特徴とするプラットフォーム。
請求項１３又は請求項１４に記載のプラットフォームにおいて、前記エンティティがイベント通知の一貫した階層構造を有し、エンティティが該構造のより高いメンバのイベントを受け継ぐことを特徴とするプラットフォーム。
住居用ゲートウェイの形態の請求項１ないし１５の何れか一項に記載のプラットフォーム。
遠隔サーバと通信するための通信リンクに接続可能な請求項１６に記載の住居用ゲートウェイにおいて、該ゲートウェイにおいてサポートされる前記フレームワークが、前記遠隔サーバにより実行されるアプリケーションに対するインターフェースを提供することを特徴とする住居用ゲートウェイ。
ローカルネットワークにおける目標装置を制御するプラットフォームのための命令において、これら命令は、前記プラットフォームのプロセッサにオープン・サービス・ゲートウェイ・フレームワークをサポートさせると共に、前記目標装置を制御するための少なくとも１つのアプリケーションを実行させ、前記目標装置の各々はアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介して前記アプリケーションにより操作することが可能なエンティティにより表され、これらエンティティは装置タイプの共通の階層構造に従い、該階層構造においてより低い装置タイプを表すエンティティは、該階層構造においてより高い装置タイプの特性を受け継ぎ、これにより、アプリケーションに対して一貫したＡＰＩを提供することを特徴とする命令。
請求項１８に記載の命令において、前記エンティティが、共通言語を使用する装置アブストラクションレイヤの一部を形成することを特徴とする命令。
請求項１９に記載の命令において、前記アブストラクションレイヤが、前記共通言語と、前記目標装置とインターフェースするために使用されるプロトコルとの間でメッセージを翻訳するブリッジドライバを更に有することを特徴とする命令。
請求項１９又は請求項２０に記載の命令において、前記共通言語が住宅定型制御言語（ＨＵＣＬ）であることを特徴とする命令。
請求項１８ないし２１の何れか一項に記載の命令において、目標装置を表すエンティティが、前記フレームワークに装置サービスとして登録されることを特徴とする命令。
請求項１８ないし２２の何れか一項に記載の命令において、複数の目標装置を表すことが可能な装置サービスが前記フレームワークに登録され、各目標装置が該装置サービス内の個々のエンティティにより表されることを特徴とする命令。
請求項２３に記載の命令において、前記装置サービスがＨＵＣＬ複合装置を有し、各目標装置が該複合装置の副装置であるようなエンティティにより表されることを特徴とする命令。
請求項２３又は請求項２４に記載の命令において、前記装置サービスとアプリケーションとの間のＡＰＩが、前記装置サービスにメッセージを送信するためのコマンドと前記装置サービスからメッセージを受信するためのコマンドとを有していることを特徴とする命令。
請求項２３ないし２５の何れか一項に記載の命令において、アプリケーションに、高レベルコマンドを前記ＡＰＩを介して使用される低レベルメッセージに翻訳するためにラッパ機能が設けられることを特徴とする命令。
請求項１８ないし２６の何れか一項に記載の命令において、アプリケーションが、前記装置タイプの階層構造の特定のレベルにおける目標装置を制御することができないと判断した場合、該アプリケーションが、前記目標装置を制御することが可能であるような前記階層構造における低いレベルを見付けることを特徴とする命令。
請求項２７に記載の命令において、前記エンティティが、特性が受け継がれているような前記階層構造における一層高い装置タイプのリストを含んでいることを特徴とする命令。
請求項２７に記載の命令において、前記アプリケーションが、前記装置タイプの階層構造に関する知識を使用することにより、前記目標装置を制御することが可能な前記階層構造における一層低いレベルを決定することを特徴とする命令。
請求項１８ないし２９の何れか一項に記載の命令において、前記装置サービスが、目標装置におけるイベントの発生を前記アプリケーションに通知するように構成されていることを特徴とする命令。
請求項３０に記載の命令において、エンティティが、イベントの発生を通知されることを欲するアプリケーションのリストを保持し、イベントが発生した場合に、これらアプリケーションに通知することを特徴とする命令。
請求項３０又は請求項３１に記載の命令において、前記エンティティがイベント通知の一貫した階層構造を有し、エンティティが該構造のより高いメンバのイベントを受け継ぐことを特徴とする命令。
請求項１８ないし３２の何れか一項に記載の命令を担持するマシン読み取り可能な媒体を有するコンピュータプログラム。
オープン・サービス・ゲートウェイ・フレームワークをサポートすると共に、ローカルネットワークにおける目標装置を制御するための少なくとも１つのアプリケーションを実行することができるようなプラットフォームと共に使用するためのエンティティのライブラリにおいて、前記エンティティの各々は、前記ネットワークにおける目標装置を表すと共にアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアプリケーションにより操作することができ、これらエンティティは装置タイプの共通の階層構造に従い、該階層構造においてより低い装置タイプを表すエンティティは、該階層構造においてより高い装置タイプの特性を受け継ぎ、これにより、アプリケーションに対して一貫したＡＰＩを提供することを特徴とするエンティティのライブラリ。
請求項１ないし３４の何れか一項に記載のプラットフォーム、命令、コンピュータプログラム又はエンティティのライブラリにおいて、前記オープン・サービス・ゲートウェイ・フレームワークがオープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）フレームワークであることを特徴とするプラットフォーム、命令、コンピュータプログラム又はエンティティのライブラリ。