JP2008502973A - ローカルネットワークシステムに関するゲートウェイ - Google Patents

Abstract

ゲートウェイ（１５０）は、ターゲット装置（２０−２３）のローカルネットワーク（４０，４５）に接続される。当該ゲートウェイ（１５０）は、発生し得るイベント（１７３）、及び、各イベントに関して前記ターゲット装置（２０−２３）を制御する命令、を記憶するイベント処理機能部（１６２）を有する。リモートサーバ（５０）は、前記ターゲット装置の制御に関して前記イベント処理機能部（１６２）を設定するアプリケーション（１３０）を支援するとともに、前記ターゲット装置（２０−２３）と直接通信する。当該ゲートウェイ（１５０）は、前記リモートサーバ（５０）との通信が中断される場合に、ターゲット装置（２０−２３）の動作を可能にするように継続する。本発明は、サーバ（５０）におけるＪａｖａ(登録商標)仮想マシンによって支援されるＯＳＧｉＪａｖａ(登録商標)アプリケーション（１３０）を有するＯＳＧｉ仮想ゲートウェイモデルの強化として用いられ得る。イベント処理機能部（１６２）は、ゲートウェイ（１５０）のネイティブコードで書かれたアプリケーションを実行することによって達成され得る。

Description

本発明は、家庭環境内における機器の制御に関するシステムなどの、ローカルネットワーキングシステムに関するゲートウェイに関する。

家庭環境内におけるネットワーク機器、及び家庭内から又は家庭から離れた場所からの機器の遠隔制御に関して、かなりの興味が存在する。

機器の制御用に、欧州ホームシステム（ＥＨＳ）プロトコル、ＺｉｇＢｅｅ、Ｘ１０、及びユニバーサルプラグアンドプレイプロトコル（ＵＰｎＰ）などの様々なプロトコルが近年開発されてきた。

ネットワーク化に関するコーヒレントなフレームワークを作成する試みにおいて、オープンサービスゲートウェイイニシアチブ（ＯＳＧｉ）は、アプリケーション（又は「サービス」）が、家庭、自動車、及び小規模オフィスなどのローカルネットワークにおいて使用、インストール、及び実行されるのを可能にすることを目的とするオープン管理フレームワークを提案した。当該ローカルネットワークの中核は、ＯＳＧｉフレームワークを実行するＯＳＧｉサービスプラットフォームを支援するゲートウェイである。当該サービスプラットフォームは、Ｊａｖａ(登録商標)仮想マシン（ＪＶＭ）周辺に基づく。当該ＯＳＧｉサービスプラットフォーム仕様書の最新発行版は、「The OSGi Alliance」からの2003年3月のバージョン3であり、ＯＳＧｉに関する更なる情報は、www.osgi.orgにおいて参照され得る。

ＯＳＧｉは、レジデンシャルゲートウェイサービスモデル及び仮想ゲートウェイモデルの両方を規定していている、前記レジデンシャルゲートウェイサービスモデルの簡略化された例は、図1に示される。ユーザアプリケーション（サービス）１３０が実行されるサービスプラットフォーム１１２は、ユーザの家など、クライアントに位置される。制御されるべきターゲット装置２０−２３は、ＺｉｇＢｅｅ及びＸ１０などの異なるネットワークプロトコルであって、それらの物理接続においても異なり得るネットワークプロトコルにそれぞれ基づき得るローカルネットワーク４０及び４５によってゲートウェイ１１０に接続される。ゲートウェイ１１０は、ネットワーク５５を介してリモートサーバ５０に接続される。リモートサーバ５０は、初めにアプリケーション１３０をサービスプラットフォーム１１２に供給し、サービスオペレーションサポート及び他の機能を提供する。このモデルは、クライアント側にＪａｖａ(登録商標)仮想マシン（ＪＶＭ）を必要とするが、当該ＪＶＭは、機器、サーモスタット、及び照明用のオン／オフ命令などの簡単なアプリケーションを支援することのみを望むクライアントにとって負担になる構成要件になり得る。

ＯＳＧｉ仮想ゲートウェイモデルは、図２に示される。ここで、アプリケーション１３０が実行されるサービスプラットフォーム１１５は、クライアントから離れたサーバ５０に位置され、ネットワーク５５を介して当該クライアントに接続される。このモデルにおいて、当該クライアントは、ゲートウェイ１２０がサーバ５０とローカルネットワーク４０及び４５との間の簡単なインターフェイスとして動作するような前提とすると、Ｊａｖａ(登録商標)仮想マシンを必要としない。サービスプラットフォーム１１５から受信されるメッセージは、ローカルネットワーク４０及び４５に転送され、ローカルネットワーク４０及び４５における装置２０−２３から受信されるメッセージは、ネットワーク５５を介してサービスプラットフォーム１１５に送信される。仮想ゲートウェイモデルが有する不利な点は、全ての処理がリモートサーバ５０におけるサービスプラットフォーム１１５で発生するので、クライアントのネットワークの動作の成功は、リモートサーバ５０とゲートウェイ１２０との間の連続的な通信リンクに依存する。メンテナンス又は故障になどにより、通信が中断される場合か、又はサービスプラットフォーム１１５が動作していない場合、クライアントにおける装置２０−２３を制御することは不可能である。この結果は、ユーザが家庭内のユーザの装置２０−２３を動作させることが可能でないか、又はセキュリティ又は監視アプリケーションが実行され得ないことになり得る。

本発明の目的は、ローカルネットワーク内の装置を制御する代替的な構成を提供することである。

したがって、本発明の第１態様は、ターゲット装置のローカルネットワークを制御するゲートウェイであって、
発生し得るイベント、及び、各イベントに関して前記ターゲット装置を制御する命令、を記憶するイベント処理(event handling)機能部と、
リモートサーバと通信するサーバインターフェイスであって、当該リモートサーバがアプリケーションを支援し、当該サーバインターフェイスが前記ターゲット装置の制御に関して前記イベント処理機能部を設定する命令を前記アプリケーションから受信するサーバインターフェイスと、
前記ターゲット装置と通信するインターフェイスと、
を備え、
当該ゲートウェイが、前記リモートサーバとの通信が中断される場合に、ターゲット装置の連続動作を可能にするように動作可能である、
ゲートウェイを提供する。

前記ゲートウェイ及びターゲット装置は、前記リモートサーバと通信することの中断の場合に「生存セル」として効果的に動作する。このことは、医療機器及びホームセキュリティの監視などの重要なアプリケーションに関して特に重要であり得る。

本発明は、ＯＳＧｉのＪａｖａ(登録商標)アプリケーションが該サーバにおけるＪａｖａ(登録商標)仮想マシンによって支援される、ＯＳＧｉ仮想ゲートウェイモデルの強化として用いられ得る。しかし、該リモートアプリケーションが中断される場合に、装置制御に関するアプリケーション及びターゲット装置間の通信リンクに完全に依存するよりもむしろ、当該ゲートウェイは、ターゲット装置の制御を自身で提供し得る。当該ゲートウェイの機能は、大幅にパワーがない処理プラットフォームによっても提供され得、したがって、ＪＶＭを支援するのに必要とされるものよりも安価である。好ましくは、前記イベント処理機能部は、当該ゲートウェイのネイティブコードで書かれるアプリケーションによって達成される。

１つの共通のプロトコルが、当該ゲートウェイ内において、及び好ましくは当該ゲートウェイ及び前記サーバ間のインターフェイスに関しても、用いられるのが好ましい。特に有利なプロトコルは、ホームユニフォーム制御言語（ＨＵＣＬ）である。これは、処理能力及び電力消費などのホスト装置の要求を最小限にし得る軽量のプロトコルである。ＨＵＣＬがターゲット装置と直接通信するのに用いられる場合にも、当該ターゲット装置は、低減された処理及び電力消費の同様な利益を得る。共通プロトコルの使用は、全ての装置に関して標準的なインターフェイスを提供する。

本発明の更なる態様は、サーバ及び少なくとも１つのクライアントを備える、ターゲット装置を制御するシステムであって、前記クライアントが、
発生し得るイベント、及び、各イベントに関して前記ターゲット装置を制御する命令、を記憶するイベント処理機能部と、
前記サーバと通信するサーバインターフェイスと、
前記ターゲット装置と通信するインターフェイスと、
を有するゲートウェイを備え、
前記サーバが、前記ターゲット装置の制御に関して前記イベント処理機能部を設定するアプリケーションを支援し、前記ゲートウェイが、当該ゲートウェイと前記サーバと間の通信が中断される場合に、ターゲット装置の連続動作を可能にするように動作可能である、システムを提供する。

本文書に記載の機能性は、ソフトウェア、ハードウェア、又はこれらの組み合わせで実施化され得る。本発明は、いくつかの個別の要素を備えるハードウェアを用いて、また適切にプログラムされた計算機を用いて実施化され得る。

更に、本発明の別の態様は、ターゲット装置のローカルネットワークを制御するゲートウェイに関する命令であって、当該命令が、前記ゲートウェイの処理器に、
発生し得るイベント、及び、各イベントに関して前記ターゲット装置を制御する命令、を記憶するイベント処理機能部と、
リモートサーバと通信するサーバインターフェイスであって、当該リモートサーバがアプリケーションを支援し、当該サーバインターフェイスが前記ターゲット装置の制御に関して前記イベント処理機能部を設定する命令を前記アプリケーションから受信するサーバインターフェイスと、
前記ターゲット装置と通信するインターフェイスと、
を支援させ、
前記ゲートウェイが、前記リモートサーバとの通信が中断される場合に、ターゲット装置の連続動作を可能にするように動作可能である、命令を提供する。

ソフトウェアは、機器の寿命におけるいかなる時点においても当該ゲートウェイにインストールされ得ることが理解される。該ソフトウェアは、電子メモリ装置、ハードディスク、光学ディスク、又は他の機械読取可能記憶媒体に記憶され得る。該ソフトウェアは、機械読取可能担体における計算機プログラム製品として提供され得るか、又はネットワーク接続を介して当該ゲートウェイに直接ダウンロードされ得る。

本発明の実施例は、例証ののみのために、添付の図面を参照にして以下に説明される。

図３は、本発明の実施例に従うゲートウェイ１５０の全体アーキテクチャを示す。ゲートウェイ１５０は、ローカルネットワークが必要とされる前提として位置される。ゲートウェイ１５０は、機器、照明、照明スイッチ、及びサーモスタットなどを含み得る複数のターゲット装置２０−２３に接続される。ターゲット装置２０−２３の集合の全体は、様々なネットワークプロトコルに従い動作し得る。この例において、ターゲット装置２０及び２１は、ＺｉｇＢｅｅプロトコルに従い動作するネットワーク４０の一部である。各ハードウェア装置２０−２３への物理ネットワーク層は、無線（例えば、ＺｉｇＢｅｅの場合はIEEE802.15.4、Bluetooth(tm)又は同等のもの場合はIEEE802.11）か、又は有線（例えば、シリアルバス、イーサネット(登録商標)ケーブル、電気ケーブル（Ｘ１０））であり得る。ゲートウェイ１５０は、リモートサーバ５０との通信リンクを提供するネットワーク５５にも接続する。サーバ５０は、ゲートウェイ１５０におけるサーバインターフェイス１７７と通信し得る１つ又は複数のアプリケーション１３０を支援する。ゲートウェイ１５０のクライアントアプリケーションであるサーバインターフェイス１７７は、ＨＵＣＬメッセージシステム１７２と直接相互作用するか、トリガー／タイムド・イベント情報に関してデータベース１６３を更新する。

ゲートウェイ１５０は、装置２０−２３の制御に関する機能性を支援する制御器１６０を含む。実際において、制御器１６０は、ローカルネットワーク４０及び４５並びに装置２０−２３とともに、クライアントにおける装置２０−２３がリモートサーバ５０との通信が中断される場合においても動作するようにされる「生存セル」を形成する。制御器１６０は、好ましい実施例においてはホームユニフォーム制御言語（ＨＵＣＬ）である共通プロトコルに従い動作する。ＨＵＣＬの主な機能は、国際特許出願公開の第2004/015926号、第2004/015927号、第2004/015928号、及び第2004/015929号に記載される。一群の装置プロトコルドライバ１７０は、ネットワーク４０及び４５で用いられるプロトコルと制御器１６０によって用いられる共通言語（ＨＵＣＬ）との間でインターフェイス（又はブリッジ）する。ＨＵＣＬメッセージシステム１７２は、図４に示されるように、プロトコルドライバ１７０と、制御器１６０内の機能的ユニットと、アプリケーションプログラムインターフェイス（ＡＰＩ）１６９との間におけるメッセージを配信する。ＨＵＣＬは、圧縮されたＸＭＬメッセージを用いる、ホスト機器への低要求を行う軽量プロトコルである。ＨＵＣＬは、制御器１６０内の機能ユニット間におけるメッセージのオーバヘッドを低減し得る基本及び広範囲の装置記述をも提供する。ＨＵＣＬのＡＰＩ１６９は、ローカルに実行されるアプリケーション１７５へインターフェイスする。

制御器１６０は、ネットワーク４０及び４５からのイベントを傾聴し、いずれかのアクションがイベントに応答して取られる必要があるかを見るためにデータベース１６３を確認するステップを継続的に動作する。そうである場合、該制御器は、（トリガーイベントと呼ばれる）必要なアクションを取る。タイマが終了する場合、この場合も、（タイムドイベントと呼ばれる）イベントを開始する。サーバインターフェイス１７７がサーバ５０からメッセージを受信する場合、これは、データベース１６３に記憶されるイベントのテーブル（図５）を更新する（例えば、アプリケーション１３０からのメッセージは「非照明スイッチが押される場合、照明Ａをオンにする」か、又は「午後８時に洗濯機をオンにする」と示すか、ＨＵＣＬメッセージシステムに「今照明Ａをオンにしなさい」などのターゲット装置への命令を発行するように示す。リモートアプリケーション１３０は、サーバインターフェイス１７７のみと通信する。

ゲートウェイ１５０とサーバ５０との間の通信が中断される場合、制御器１６０は、動作を継続し、データベース１６３に以前に記憶されていたトリガーイベント及びタイムドイベントへの応答を継続する。特定の制限された特徴は、中断の期間において支援され得ない。トリガーイベントによって必要とされるアクションがサーバ５０との通信を含む場合、このことは達成され得ない。また、中断の期間において、ゲートウェイ１５０は、サーバ５０によって、又はいかなるリモート端末２００によっても、制御器１６０の動作を修正するために、又はターゲット装置へ（サーバインターフェイス１７７及びＨＵＣＬメッセージシステム１７２を介して）直接命令を発行するために、アクセスされ得ない。以下のように、ローカルウェブサーバ１７６も、ゲートウェイ１５０が中断の期間においてローカルに構成されるのを可能にするために設けられ得る。

サーバ５０において、ネットワーク５５を介してサーバインターフェイス１７７へのＨＵＣＬメッセージを送信／受信し得るホーム制御インターフェイス１３５が存在する。サーバインターフェイス１７７は、この場合、制御器１６０と通信し、制御器１６０は、プロトコルドライバ１７０を介してローカルネットワーク４０及び４５における様々な装置２０−２３と通信する。これらは、ＨＵＣＬメッセージを当該ネットワーク特有のプロトコルに変換し、また逆である上向きの通信に関しても同様である。データベース１６３は、ネットワーク４０及び４５における各ターゲット装置に関する情報（装置サービスと呼ばれるソフトウェア表現）を記憶する。この情報は、ＨＵＣＬ合成装置として記憶されることが好ましい。１つのＨＵＣＬ合成装置は、サーバ５０におけるサービスプラットフォーム１１５によって支援されるＯＳＧｉフレームワークを用いて登録され、当該合成装置は、ネットワーク４０及び４５におけるターゲット装置の群２０−２３を代表する。ＨＵＣＬ合成装置の概念は、国際特許出願第2004/015927号に記載される。ＨＵＣＬ合成装置の使用は、多数のターゲット装置２０−２３とより容易に協調し得るので、当該システムをよりスケーラブルにする。ＡＰＩ１６９の主なコンポーネントは、SendHUCLMsg()及びReceiveHUCLMsg()の命令と、ＨＵＣＬ合成装置のどのサブ装置が各メッセージにおいて識別されるかを識別するいくつかの追加的なアドレス処理情報である。ＨＵＣＬ合成装置の使用は、ゲートウェイ１５０及びサーバ５０の間の簡単なインターフェイスを可能にする。国際特許出願第2004/015956号に記載のＨＵＣＬプロトコルの特徴に従い、アプリケーション１３０は、当該ＨＵＣＬ合成装置に、各ターゲット装置の簡単な説明及び拡張された説明を問合せ得る。サーバ５０は、サーバ５０が自身が必要とされるようなターゲット装置２０−２３についての情報をリクエストするような方法で動作し得るか、又はサーバ５０は情報をローカルに記憶し得る。サーバ５０に情報を記憶することは、ゲートウェイ１５０を再構成する必要がある場合に有用であり得る。

制御器１６０は、イベントハンドラ(event handler)１６２、ログメカニズム部１６６、及びデータベースマネージャ１６４を含む。データベースマネージャ１６４は、ローカルデータベース１６３からのデータの記憶及び取得を制御する。イベントハンドラ１６２は、２つの主な態様を有する。
・可能なトリガー、条件、及びアクションが提示され、且つ対応するＨＵＣＬ命令がユーザの要件に従ってか、又はリモートアプリケーション１３０によって構成されて、データベース１６３に構築及び記憶されるような、イベント構成。イベントは、いかなるローカルクライアント（例えば、サーバインターフェイス１７７又はローカルウェブサーバ１７６など）によっても設定され得る。リモートアプリケーション１３０は、イベントを設定、更新、又は取り消すために、サーバインターフェイス１７７と通信する。
・制御器１６０が、装置プロトコルによって発生される全てのＨＵＣＬ装置イベントを受信するように加入し、いずれかが、記憶されたローカルイベントを起動（トリガー）するかを確認する、ＨＵＣＬ装置イベントハンドリング。トリガーが検出される場合、（もしあれば）その条件が確認され、事前構成されたＨＵＣＬ命令アクションが発送される。記憶されたイベントは、クライアントアプリケーション１７５又はリモートアプリケーション１３０によって、トリガー、条件、及びアクションを設定するためにイベントハンドラ１６２へのコールを用いて構成される。前記装置イベントは、「洗濯機が終了した」又は「照明スイッチが押された」などの、ターゲット装置によって発生されるイベントである。記憶されたイベントは、「受動赤外線（ＰＩＲ）検出器が室内の動きを感知する場合、盗難警報を鳴らしなさい」などの特定の装置イベントの発生に関連付けられる。ローカルイベントの発生に関する監視、及びそれらに影響を与える処理は、サーバ５０へのリンクの中断の発生の場合に自主的に生存セルにおいて継続する。リストは、特定の装置イベントに加入するクライアントのデータベースに維持される。
図５に示されるように、イベントハンドラ１６２は、ローカルイベントデータ１７３をデータベース１６３に記憶する。記憶されたイベントは、ＨＵＣＬ装置イベントによって装置プロトコルドライバから（例えば、照明のスイッチがオンにされる、若しくはサーモスタットが特定の温度に達するなど）か、イベントハンドラ１６２におけるタイマ１６１の満了によって（例えば、午後８時に照明をオンにするか、又はヒーターを３０分後にオフにするなどの記憶されたイベントデータに応答するなどして）起動され得る。イベントハンドラ１６２は、各イベントに関して、そのイベントに適用するいかなる条件（例えば、タイマ機能１６１によって監視され得る実際の時間又は経過時間など）と、そのイベントに応答して実行されなければならない一群のアクション（例えば、セキュリティの照明をオンにするなど）とを記憶する。適用し得る他の可能な条件は、例えば「自分が休暇中の場合にのみ午後８時に照明をオンにする」などであるか、又は例えば「暗いと光メータが示す場合にのみ外側の照明をオンにする」などの装置の状態に依存する条件である。

ログメカニズム部１６６は、当該システムに、ログファイルにデータを書き込むことによって、重要なイベント及びエラーなどのデータを記録させる。これは、当該システムについてのデータを記録するのに用いられ得る。

ローカルウェブサーバ１７６は、１５０と同一のローカルネットワークに位置されるウェブブラウザからローカルの設定を可能にするバックアップとしてゲートウェイ１５０に設けられる。これは、制御器１６０にもリンクされる。当該システムと相互作用するウェブページは、ローカルウェブサーバ１７６を初めに見るように設定され得る。この場合、これは、前記リモート接続を検査し、利用可能である場合ユーザに再方向付けされ得る。利用可能でない場合、前記ローカルウェブページに初期設定され得る。

サーバインターフェイス１７７は、データベース１６３にインターフェイスし、現在のイベントのリストを取得し、ユーザに示すためにこれをアプリケーション１３０に送信し得る。サーバ５０との通信が中断される場合、ローカルウェブサーバ１７６は同様にこれを実行し得る。

２つの状況に関するサンプルメッセージのフローが、図６及び７を参照にして以下に説明される。初めに、図６は、命令がアプリケーション１３０からネットワークにおけるターゲット装置へ送信される場合のメッセージフローを示す。アプリケーション１３０から送信される命令の開始は、アプリケーションに直接通信するか、又はアプリケーション１３０と通信するウェブサーバ５０を介して、端末２００で実行する、例えばウェブブラウザなどのリモートユーザアプリケーションから生じ得る。ステップ６０１において、アプリケーション１３０は、ＨＵＣＬメッセージを、ネットワーク５５を介してホーム制御インターフェイス１３５を通じサーバインターフェイス１７７に送信する。この場合、インターフェイス１７７は、該装置命令を記述するメッセージ６０２を発生する。ステップ６０３において、ＨＵＣＬメッセージシステム１７２は、該命令メッセージを装置プロトコルドライバ１７０に伝達する。任意追加的に、ステップ６０４において、装置プロトコルドライバ１７０は、データベースＡＰＩを介してデータベース１６３から記憶された情報をリクエストし、ステップ６０５において、該応答がＨＵＣＬメッセージとして返送される。通常、どのネットワーク４０及び４５も、装置をアドレス処理するのに異なる方法を有し、ステップ６０４及び６０５におけるデータベースルックアップは、ネットワーク特有の情報を取得する１つの方法である。Ｘ１０ネットワークにおいて、装置は、その家及び装置コードによって参照される一方で、ＨＵＣＬは、単一の装置ＩＤを有する。ＺｉｇＢｅｅネットワークにおいて、ネットワーク及び装置アドレスが存在する。代替的な方法において、全てのネットワーク情報は、装置プロトコルドライバ１７０内にキャッシュされる。ステップ６０６において、装置プロトコルドライバ１７０は、命令をターゲットネットワーク４０及び４５における特定のターゲット装置２０−２３に送信されるメッセージに変換させる。

上述の代替案において（図６には示されないが）、リモートアプリケーション１３０は、データベース１６３にイベントを設定するように意図されるメッセージをネットワーク５５を介して送信する。ステップ６０１及び６０２は、以前と同一である。しかし、ステップ６０３において、（図５に「設定命令」として示される）記憶されるべきイベントの詳細を含むＨＵＣＬメッセージは、イベントハンドラ１６２に送信される。この場合、イベントハンドラ１６２は、この情報を用いてデータベース１６３を更新する。当該イベントは、トリガーイベント又はタイムドイベントであり得る。

上述のやり方でターゲット装置が制御される結果として、又はターゲット装置と相互作用するユーザに応答して（例えば照明スイッチをオンにするなど）、新たな装置イベントが発生され得る。このことは、図７に示されるメッセージのシーケンスを引き起こす。図７において、装置プロトコルイベントは、プロトコルドライバから送信される。ステップ７０１において、活動状況は、ネットワーク４５におけるハードウェアによって検出され、Ｌｉｎｕｘドライバなどの低レベルドライバを介して通信される。装置プロトコルドライバ１７０は、ターゲットネットワーク４５における活動状況を認識するようになる。追加的なステップ７０２及び７０３において、ＨＵＣＬメッセージは、装置プロトコルイベントサブスクライバ、並びに可能であるならば現在及び更新された装置の状態を含むデータを、データベース１６３へ／から転送する。各動作は、リクエスト７０２及び応答７０３を含む。ステップ７０４ａ及び７０４ｂにおいて、装置プロトコルドライバ１７０は、装置プロトコルイベントを表すＨＵＣＬイベントメッセージを発生し、それをＨＵＣＬメッセージシステム１７２を介して全ての加入されたターゲットに送信する。イベントハンドラ１６２は、全ての装置イベントに同意し、したがって、当該ネットワーク内のイベントに応答する位置に常にあり得る。またクライアントアプリケーション１７５も、装置イベントにも同意し、サーバインターフェイス１７７を含む。ステップ７０５において、イベントハンドラ１６２は、データベース１６３に保持されるイベントデータ１７３を、当該イベントに関連付けられるいずれかの条件が存在するかを決定するために、照会し、ステップ７０６においてデータを返送する。イベントハンドラ１６２は、この場合、（もし存在するなら）該イベント条件が満たされていたかを決定し得、そうである場合、ステップ７０７において当該イベントに関連付けられるＨＵＣＬ命令を発行する。この動作は、リモートサーバとの通信が中断される場合にも発生し得ることを特記され得る。

制御器１６０に、制限された処理及び記憶容量を用いて有用な機能性レベルを提供させるこのアーキテクチャの特徴の１つは、ＨＵＣＬの装置種類階層である。このことは、図８を参照にして説明される。ＨＵＣＬは、装置サービスの階層型構成を有する。図８は、装置サービス３００の例証的階層を示し、通常のＨＵＣＬ装置３０１が上部にある。関数「getSubDevices()」は、もしいずれかが存在する場合、サブ装置の次の層の装置サービスを返送する。当該階層を下に移動すると、装置サービスは、詳細／機能性の増加したレベルを有する。したがって、装置サービス３０２は、オン／オフをする能力を有するターゲット装置を表す。当該階層の左手側に下に移動すると、装置サービス３０３は、そのサービスの上のクラスの特徴を継承する基本ランプを規定し、すなわちこれもオン／オフをし得る。装置サービス３０４は、薄暗くすることが可能なランプ、すなわち可能な値の範囲内で特定の輝度値に設定される機能を有するランプを規定する。装置サービス３０４は、そのサービスの上の３０２及び３０３の特徴を継承し、すなわち、それはランプであり、オン・オフをし得る。当該階層の右手側に下に移動すると、装置サービス３０５は、ＨＵＣＬオン／オフ装置３０２の特徴を継承するドアベルを規定する。この例において、アプリケーション(例えばアプリケーション１３０)が「HUCLDimmableLamp」種類の装置と通信する方法を知らない場合、該装置サービスがこの機能性を理解し得るという確信を持って、「HUCLBasicLamp」規定、又は基本の「HUCLDevice」規定さえもなお使用し得る。実際上、ＨＵＣＬは、アプリケーションが「階層ツリーを上る」ようにさせ、アプリケーションが装置種類を認識しない（例えば薄暗くすることが可能であるランプなど）ことを発見する場合、該アプリケーションは、該装置サービスの一部として提供される装置種類リストに列挙される他の装置種類を確認する。同様に、何かをオン／オフさせる能力を有するアプリケーションは、全てのターゲット装置を表す装置サービスが当該階層に従うので、ランプ、ドアベル、又はオン／オフされる事が可能である他のいかなる種類の装置も駆動させることが可能である。ターゲット装置は、「最下層」の最も正確な表現より上のどのレベルにおいても表現され得る。この解決法は、装置が、開発者が特定の装置の完全な詳細を知らない状況においても、最大限の程度に操作されるのを可能にする。このことは、ターゲット装置の製造業者が、特定のレベルに相互運用し得る製品を提供するだけでなく、彼らの製品を他の製品と差別化する製品に独特の特徴を追加することを可能にさせる。

上述のゲートウェイ１５０は、Ｊａｖａ(登録商標)仮想マシン及びＯＳＧｉＪａｖａ(登録商標)アプリケーションを支援する必要がないので、そのアーキテクチャが、控えめな処理能力の処理プラットフォームに特に適しているが、汎用ＰＣ又は専用処理ユニットなどの様々な処理プラットフォームで実施化され得る。図９は、処理プラットフォームの主なコンポーネントを示す。中央処理ユニット４０１は、上述のように、制御器１６０及びクライアントアプリケーション１７５を支援するソフトウェアを実行する。通常、中央処理ユニット４０１は、（例えばＬｉｎｕｘに基づくなどの）ネイティブのオペレーティングシステムを有する。ハードディスク等の不揮発性メモリ４０２及び揮発性メモリ４０３は、処理ユニット４０１によって使用されるオペレーティングシステムを記憶する。ブロードバンドＡＤＳＬ又はケーブルモデムなどのモデム４０６は、アプリケーションが支援されるリモートサーバ（５０、図３）へゲートウェイ１５０を参加させるネットワーク５５に接続する。ブロードバンドモデム４０６は、ゲートウェイ１５０に対して外部的であり得る。制御される装置へ／からの制御メッセージは、有線４１２及び無線４１１技術の組み合わせを用いるローカルネットワーク接続４１５によって伝達される。ローカルエリアネットワークカード、無線、赤外線、又は電力線（例えばＸ１０）モデムなどの適切なハードウェアが、特定のローカルネットワークを支援するのに提供され得る。ユーザ入力は、キーパッド、キーボード、マウス、又はタブレットなどの入力装置４１０によってゲートウェイに直接供給され得る。代替的に、ユーザ入力は、ゲートウェイ１５０とローカルにネットワーク化されるリモート制御ユニットからか、又はネットワーク５５に接続される端末２００から受信され得る。例として、ユーザが自身の家から離れていて、その家の中の機器を制御する命令を該ゲートウェイに送信したいと望む場合、ユーザは、リモート端末２００と相互作用し、命令をネットワーク接続を介してゲートウェイ１５０に送信し得る。出力は、ディスプレイドライバ４０８及びディスプレイ４０９を介してユーザへ、ローカル制御ユニット２２０へ、又はリモート端末２００へ直接提示され得る。バス４０５、又は異なる種類のバスの組み合わせは、上述のユニットを接続する。

広範囲の種類のアプリケーション１３０が、リモートサーバ５０において実行され得る。これらの例は、所定の時間においてランプをオンおよびオフにすることによってビルに居住していることの模擬、暖房及び換気の制御、ビデオレコーダのプログラミングなどのホームコントロール、娯楽及び民生電子装置の制御、ビルのセキュリティ又はビルの居住者の健康の遠隔監視、遠隔不良報告／診断、を含む。

上述の実施例は、本発明を制限するものよりもむしろ例証するものであり、当業者が、添付の請求の範囲から逸脱することなく、多数の代わりの実施例を設計することが可能であることを注意しなければならない。請求項において、括弧記号間に位置される如何なる参照符号も、請求項を制限するように解釈されてはならない。「有する」という語句は、請求項に記載される以外の要素又はステップの存在を排除しない。システム／装置／機器の請求項がいくつかの手段を列挙している場合において、これらの手段のいくつかは１つの同じハードウェアの項目によって、実施化することが可能である。

上述の説明において、また図面を参照にして、ターゲット装置２０−２３のローカルネットワーク４０および４５に接続されるゲートウェイが記載される。ゲートウェイ１５０は、発生し得るイベント１７３、及び、各イベントに関してターゲット装置２０−２３を制御する命令、を記憶するイベント処理機能部１６２を有する。リモートサーバ５０は、前記ターゲット装置の制御に関して前記イベント処理機能部１６２を設定するアプリケーション１３０を支援するとともに、前記ターゲット装置２０−２３と直接通信する。当該ゲートウェイ１５０は、前記リモートサーバ５０との通信が中断される場合に、ターゲット装置２０−２３の動作を可能にするように継続する。本発明は、サーバ５０におけるＪａｖａ(登録商標)仮想マシンによって支援されるＯＳＧｉＪａｖａ(登録商標)アプリケーション１３０を有するＯＳＧｉ仮想ゲートウェイモデルの強化として用いられ得る。イベント処理機能部１６２は、ゲートウェイ１５０のネイティブコードで書かれたアプリケーションを実行することによって達成され得る。

図１は、単純化されたＯＳＧｉレジデンシャルゲートウェイサービスモデルを示す。 図２は、単純化されたＯＳＧｉ仮想ゲートウェイモデルを示す。 図３は、本発明の実施例に従うゲートウェイを示す。 図４は、図３のゲートウェイで用いられるメッセージングシステムを示す。 図５は、図３のゲートウェイ内で用いられるイベントハンドラ及びデータベースを示す。 図６は、図３のゲートウェイ内のメッセージフローを示す。 図７は、図３のゲートウェイ内のメッセージフローを示す。 図８は、装置サービス階層を示す。 図９は、図３のゲートウェイを実施化するハードウェアを示す。

Claims (24)

1. ターゲット装置のローカルネットワークを制御するゲートウェイであって、
   発生し得るイベント、及び、各イベントに関して前記ターゲット装置を制御する命令、を記憶するイベント処理機能部と、
   リモートサーバと通信するサーバインターフェイスであって、当該リモートサーバがアプリケーションを支援し、当該サーバインターフェイスが前記ターゲット装置の制御に関して前記イベント処理機能部を設定する命令を前記アプリケーションから受信するサーバインターフェイスと、
   前記ターゲット装置と通信するインターフェイスと、
   を備え、
   当該ゲートウェイが、前記リモートサーバとの通信が中断される場合に、ターゲット装置の連続動作を可能にするように動作可能である、ゲートウェイ。
2. 前記リモートサーバによって支援される前記アプリケーションが、第１言語で書かれ、前記イベント処理機能部が、第２の、より低いレベルの言語で書かれている、請求項１に記載のゲートウェイ。
3. 前記リモートサーバによって支援される前記アプリケーションが、Ｊａｖａ(登録商標)アプリケーションであり、前記イベント処理機能部が、前記ゲートウェイのネイティブのコードを用いて実施化される、請求項１又は２に記載のゲートウェイ。
4. 前記リモートサーバによって支援される前記アプリケーションが、オープンサービスゲートウェイイニシアチブ（ＯＳＧｉ）アプリケーションである、請求項１ないし３のいずれか一項に記載のゲートウェイ。
5. 前記サーバインターフェイスが、更に、前記ターゲット装置に渡される命令を前記アプリケーションから受信するように動作可能である、請求項１ないし４のいずれか一項に記載のゲートウェイ。
6. 前記記憶されるイベントの少なくともいくつかが、それらと関連付けられる条件を有し、前記イベント処理機能部が、前記関連付けられる条件が満たされるかどうかを決定するように構成される、請求項１ないし５のいずれか一項に記載のゲートウェイ。
7. 前記イベント処理機能部が、更に、時間依存イベントを処理するタイマを備える、請求項１ないし６のいずれか一項に記載のゲートウェイ。
8. 前記イベント処理機能部が、前記ターゲット装置の動作によって起動されるイベントに応答的である、請求項１ないし７のいずれか一項に記載のゲートウェイ。
9. 前記イベント処理機能部が、所定の時間に発生するようにプログラムされるイベントを記憶する、請求項１ないし８のいずれか一項に記載のゲートウェイ。
10. 前記リモートサーバとの通信が中断される場合、前記イベント処理機能部をローカル的に設定するインターフェイスを更に備える、請求項１ないし９のいずれか一項に記載のゲートウェイ。
11. 前記ターゲット装置に関するインターフェイスが、前記ターゲット装置によって使用されるプロトコルと前記ゲートウェイによって使用される共通プロトコルとの間で変換する少なくとも１つのドライバを備える、請求項１ないし１０のいずれか一項に記載のゲートウェイ。
12. 前記共通プロトコルが、前記アプリケーションとのインターフェイスするのにも用いられる、請求項１１に記載のゲートウェイ。
13. 前記共通言語が装置種類の共通階層構造を有し、当該階層における下位装置種類を表すエンティティが、当該階層における上位装置種類の特性を受け継ぎ、これにより、アプリケーションに一貫したＡＰＩを提示する、請求項１１又は１２に記載のゲートウェイ。
14. 前記共通言語が、ＸＭＬ形式のメッセージを用いる、請求項１１ないし１３のいずれか一項に記載のゲートウェイ。
15. 前記共通プロトコルが、ホームユニフォーム制御言語（ＨＵＣＬ）である、請求項１１ないし１４のいずれか一項に記載のゲートウェイ。
16. 機器を制御するレジデンシャルゲートウェイの形式である、請求項１ないし１５のいずれか一項に記載のゲートウェイ。
17. サーバ及び少なくとも１つのクライアントを備える、ターゲット装置を制御するシステムであって、前記クライアントが、
    発生し得るイベント、及び、各イベントに関して前記ターゲット装置を制御する命令、を記憶するイベント処理機能部と、
    前記サーバと通信するサーバインターフェイスと、
    前記ターゲット装置と通信するインターフェイスと、
    を有するゲートウェイを備え、
    前記サーバが、前記ターゲット装置の制御に関して前記イベント処理機能部を設定するアプリケーションを支援し、前記ゲートウェイが、当該ゲートウェイと前記サーバと間の通信が中断される場合に、ターゲット装置の連続動作を可能にするように動作可能である、システム。
18. 前記サーバによって支援される前記アプリケーションが、第１言語で書かれ、前記イベント処理機能部が、第２の、より低いレベルの言語で書かれている、請求項１７に記載のシステム。
19. 前記サーバによって支援される前記アプリケーションが、Ｊａｖａ(登録商標)アプリケーションであり、前記イベント処理機能部が、前記ゲートウェイのネイティブのコードを用いて実施化される、請求項１７又は１８に記載のシステム。
20. 前記サーバによって支援される前記アプリケーションが、オープンサービスゲートウェイイニシアチブ（ＯＳＧｉ）アプリケーションである、請求項１７ないし１９の何れか一項に記載のシステム。
21. 前記ターゲット装置に関するインターフェイスが、前記ターゲット装置によって使用されるプロトコルと前記ゲートウェイによって使用される共通プロトコルとの間で変換する少なくとも１つのドライバを備える、請求項１７ないし２０の何れか一項に記載のシステム。
22. 前記共通プロトコルが、前記アプリケーションとのインターフェイスするのにも用いられる、請求項１７ないし２１の何れか一項に記載のシステム。
23. 請求項１ないし１６の何れか一項に記載の、ターゲット装置のローカルネットワークを制御するゲートウェイに関する命令であって、前記ゲートウェイの処理器に、
    発生し得るイベント、及び、各イベントに関して前記ターゲット装置を制御する命令、を記憶するイベント処理機能部と、
    リモートサーバと通信するサーバインターフェイスであって、当該リモートサーバがアプリケーションを支援し、当該サーバインターフェイスが前記ターゲット装置の制御に関して前記イベント処理機能部を設定する命令を前記アプリケーションから受信するサーバインターフェイスと、
    前記ターゲット装置と通信するインターフェイスと、
    を支援させ、
    当該ゲートウェイが、前記リモートサーバとの通信が中断される場合に、ターゲット装置の連続動作を可能にするように動作可能である、命令。
24. 実質的に添付の図面を参照にして本文に記載され、当該図面に示した通りのゲートウェイ、システム、又はゲートウェイに関する命令。

Images