JP2006172416A - ネット家電機器コントローラ及びこれを用いたネットワークシステム - Google Patents

Abstract

【課題】既に規格化された統一仕様で規定される共通のプロパティのみならず、機器毎に規定される独自のプロパティについても、統一的に制御することが可能なネット家電機器コントローラを提供する。
【解決手段】コントローラＡは、機器Ｂ１〜Ｂｎの起動時アナウンスからグループとクラスを識別する手段と識別結果に応じた定義ファイルを読み込み、汎用的制御に必要なオブジェクトＯＢＪ０を生成して動的に取り込む手段とオブジェクトＯＢＪ０を用いて機器Ｂ１〜Ｂｎに個別情報を問い合わせる手段と機器Ｂ１〜Ｂｎの個別情報に応じた定義ファイルを読み込み、当該機器の個別的制御に必要なオブジェクトＯＢＪ１〜ＯＢＪｎを生成して動的に取り込む手段とオブジェクトＯＢＪ１〜ＯＢＪｎを用いて機器Ｂ１〜Ｂｎの個別的制御を行う手段とを有して成る構成としている。
【選択図】図４

Description

本発明は、ホームネットワークを構築するネット家電機器の統括制御を行うネット家電機器コントローラ及びこれを用いたネットワークシステムに関するものであり、特に、複数のメーカで生産されたネット家電機器の統一的制御アプリケーションの構築、並びに、これを基礎としたビジネスモデルに関するものである。

近年、複数の企業が共同で策定したＨＡＶｉ［Home Audio/Video interoperability］対応のＡＶ［Audio Visual］機器で構成されるネットワークや、ホームオートメーションのためのホームバス規格であるＨＢＳ［Home Bus System］に基づいたネットワーク、或いは、複数の企業などが設立したエコーネットコンソーシアムが提唱している家庭内の電灯線や無線を利用したネットワークの規格であるＥＣＨＯＮＥＴ［Energy Conservation and HOmecare NETwork］に基づいたネットワークなど、ネット家電機器で構成されるホームネットワークの実用化が進められている。

このようなネット家電機器のうち、娯楽を目的とした音楽や映画、ゲームなどを扱うＡＶ系のネット家電機器は、機器夫々の操作体系に共通点が多く、ユーザインターフェイスが比較的一元化されている。そのため、上記した仕様を規定しておけば、比較的簡単にマルチベンダー対応の統一的制御アプリケーションを提供することが可能である。

一方、設備系の家電機器（いわゆる白物家電）をターゲットとしたホームネットワークにおいては、ターゲットとする機器がエアコンであったり、洗濯機であったりと、機器夫々が独自のユーザインターフェイスを必要とするため、ＡＶ系のホームネットワークに比べて、統一的制御アプリケーションを作成することが難しいという問題があった。

先出のＥＣＨＯＮＥＴ仕様では、上記の問題点に鑑み、白物家電の統一的な体系を構築して管理する手法をとっている。具体的には、家電機器の用途や利用環境等に応じて大きなグループ分けを行い、さらにそのグループ内で家電機器の種別や形態を定義し、夫々をオブジェクトに位置付けて管理している。

ＥＣＨＯＮＥＴで規定されるグループとしては、「センサー関連機器グループ」、「住宅・設備機器関連グループ」、「調理・家事関連機器グループ」、「健康関連機器グループ」、「管理・操作関連機器グループ」などがある。

上記グループの下には、夫々に属する家電機器が定義されている。例えば、「空調関連機器グループ」であれば、「家庭用エアコン」、「冷風機」、「扇風機」、「換気扇」、「空気清浄機」など、およそ国内で製造販売されている殆どの機器が定義されている。ＥＣＨＯＮＥＴでは、これらの定義をクラスと呼称している。

ＥＣＨＯＮＥＴ仕様に準拠したネット家電機器は、上記したグループとクラスの識別コードを内蔵することが義務付けられており、ネットワークを通じて機器から直接グループコードとクラスコードを読み出すことができるようになっている。

さらに、各クラスは、ＥＰＣ（エコーネットプロパティコード）と呼ばれる属性識別子を持っており、各家電機器の属性を表現する識別コードが割り当てられている。また、各ＥＰＣには、ＥＤＴ（エコーネットプロパティ値データ）と呼ばれる属性値が定義されており、一般的には、ＥＰＣ毎に独自のＥＤＴが定義される。

例えば、「家庭用エアコン」というクラスは、「運転モード」というＥＰＣを持っており、該ＥＰＣには、「冷房」、「暖房」、「除湿」、「送風」、「自動」というＥＤＴが定義されている。同様に、「洗濯機」というクラスは、「洗濯設定」というＥＰＣを持っており、該ＥＰＣには、「洗濯開始」、「洗濯一時停止」、「洗濯停止」というＥＤＴが定義されている。

このように、家庭用白物家電機器のネットワーク化は、国内における家電機器メーカが共通した通信仕様に基づいて商品化することによりはじめて達成されるものであり、白物家電に関して言えば、上記したＥＣＨＯＮＥＴ仕様を中心として、徐々にインフラが整いつつあるのが現状である。

なお、本願発明に関連する従来技術としては、機器の識別情報と画面作成用情報のダウンロード先を機器から取り出し、サーバのＷＥＢ画面を創生するホームネットワークゲートウェイ装置が開示・提案されている（例えば、特許文献１を参照）。

また、本願発明に関連する他の従来技術としては、公開されたインターネットサーバ上に種々のコンテンツを置き、そのデータの利用状況に応じて利用者に課金を行うデータ処理装置（例えば、特許文献２を参照）や、ＷＥＢページを利用した家庭用機器の遠隔制御サービス提供装置（例えば、特許文献３を参照）が開示・提案されている。

特許第３３１８２８９号 特開２００１−１７５６０５号 特開２００３−３３７７７２号

確かに、ＥＣＨＯＮＥＴに代表される白物系ネット家電機器の統一仕様に基づいて、制御アプリケーションを構築しておけば、各機器に共通する基本的操作に関する限り、白物系ネット家電機器のマルチベンダー化を実現することが可能である。

しかしながら、ネット家電機器の従来仕様に基づく制御アプリケーションでは、あくまでその統一仕様で規定される共通のプロパティ（属性）についてのみ、マルチベンダー化を実現し得るに過ぎず、必ずしも完全なものであるとは言えない面があった。

特に、日本国内においては、各白物系家電メーカが自社の機器に独自の機能を搭載して差別化を行うことが恒常的に行われており、例えば、ＥＣＨＯＮＥＴで規定されるＥＰＣとＥＤＴだけでは、その機器の最も前面に押し出したい機能（すなわち、機器毎のオリジナル機能）を表現することができない、という課題があった。

そのため、ネット家電機器コントローラは、ＥＣＨＯＮＥＴ仕様に準拠しつつも、メーカ毎に相異なる仕様で作成されていた。すなわち、Ａ社製のネット家電機器コントローラは、あくまでＡ社製ネット家電機器によって構築されたホームネットワークを統括制御するものに過ぎず、Ａ社製ネット家電機器の機能は全て利用できるが、Ｂ社製ネット家電機器については、その全ての機能を利用することができない、というのが現状であった。

なお、特許文献１の従来技術は、あくまで、機器の識別情報と画面作成用情報のダウンロード先を機器から取り出し、サーバのＷＥＢ画面を創生するための技術に過ぎず、上記課題を解決し得るものではなかった。また、特許文献１の従来技術では、読み出す画面生成情報がＨＴＭＬ［Hyper Text Markup Language］形式で記述されていたため、特定の機器に対して特定のＨＴＭＬ情報を作っておく必要があり、適用機種が限定されてしまう、という課題があった。また、段落［００６４］に記されているように、特許文献１の従来技術は、ＨＴＭＬ情報と操作用のＣＧＩ［Common Gateway Interface］スクリプトをダウンロードして画面を構築する構成であるため、特定の機器に対して特定の操作用画面とＣＧＩスクリプトを用意しなければならず、先述と同様、適用機種が限定されてしまう、という課題があった。

また、上記した共通の仕様が一般に公開され、その仕様に準拠した製品を世に出そうと試みる企業が現れたとしても、当該企業は、制御対象となるネット家電機器と、当該ネット家電機器を制御するネット家電機器コントローラの２つを同時に商品化しなければならず、ネット家電機器に対する新規参入の敷居は必ずしも低いものではない、という問題点もあった。

本発明は、上記の問題点に鑑み、既に規格化された統一仕様で規定される共通のプロパティのみならず、機器毎に規定される独自のプロパティについても、統一的に制御することが可能であって、また、所定の仕様に準拠したネット家電機器のみでも、その商品化の可能性を広げる得るビジネスモデルを構築することが可能なネット家電機器コントローラ及びこれを用いたネットワークシステムを提供することを目的とする。

上記目的を達成すべく、本発明に係るネット家電機器コントローラは、ホームネットワークを構築するネット家電機器の統括制御を行うネット家電機器コントローラであって、前記ネット家電機器が通知するグループ情報及びクラス情報から当該ネット家電機器の属するグループ及びクラスを識別する手段と；識別されたグループ及びクラスでの汎用的制御に必要な第１の制御オブジェクトを読み込んで動的に取り込む手段、或いは、前記グループ及びクラスに応じた第１の制御対象定義ファイルを読み込み、当該第１の制御対象定義ファイルから前記第１の制御オブジェクトを生成して動的に取り込む手段と；前記第１の制御オブジェクトを用いて前記ネット家電機器にその個別情報を問い合わせる手段と；前記ネット家電機器が通知する個別情報から当該ネット家電機器の個別的制御に必要な第２の制御オブジェクトを読み込んで動的に取り込む手段、或いは、前記個別情報に応じた第２の制御対象定義ファイルを読み込み、当該第２の制御対象定義ファイルから前記第２の制御オブジェクトを生成して動的に取り込む手段と；前記第２の制御オブジェクトを用いて前記ネット家電機器の個別的制御を行う手段と、を有して成る構成としている。このような構成とすることにより、日々更新される新しい制御オブジェクトや制御対象定義ファイルを必要に応じて自己のプログラムの一部として利用することができる。従って、既に規格化された統一仕様で規定される共通のプロパティのみならず、機器毎に規定される独自のプロパティについても、統一的に制御することが可能となる。

なお、上記構成から成るネット家電機器コントローラは、広域ネットワークへの接続手段を有して成り、前記広域ネットワークを介して所定のサーバから、第２の制御オブジェクト或いは第２の制御対象定義ファイルをダウンロードする構成にするとよい。このような構成とすることにより、異なるメーカのネット家電機器であっても、サーバ上に当該ネット家電機器用の制御オブジェクトや制御対象定義ファイルを置いておくことにより、被制御機器からの固有情報を問い合わせて、自動的に必要な制御オブジェクトや制御対象定義ファイルをダウンロードし、アプリケーションに組み込むことが可能になる。また、コントローラ自体のメモリ容量を節約することができる上、常に新しい制御オブジェクトや制御対象定義ファイルを提供することが可能になる。

また、上記構成から成るネット家電機器コントローラは、前記ネット家電機器の個別情報と、第２の制御オブジェクト或いは第２の制御対象定義ファイルの所在情報と、が関連付けられた位置情報を格納する手段を有して成る構成にするとよい。このような構成とすることにより、制御オブジェクトや制御対象定義ファイルの検索に要する時間を短縮することが可能となる。

また、上記構成から成るネット家電機器コントローラは、前記広域ネットワークを介して所定のサーバから定期的或いは必要に応じて前記位置情報をダウンロードする構成にするとよい。このような構成とすることにより、常に新しい制御オブジェクトや制御対象定義ファイルを提供することが可能になる。

また、上記構成から成るネット家電機器コントローラは、第２の制御オブジェクト或いは第２の制御対象定義ファイルがコントローラ内に保持されているか否かを特定する手段を有して成る構成にするとよい。このような構成とすることにより、制御オブジェクトや制御対象定義ファイルの読込みを速やかに実施することが可能になる。

また、上記構成から成るネット家電機器コントローラは、第２の制御オブジェクトを一意に識別する個体識別情報を制御対象のネット家電機器に通知する手段と、前記ネット家電機器が通知する個体識別情報に基づいて第２の制御オブジェクト或いは第２の制御対象定義ファイルの読込みを制限する手段と、を有して成る構成にするとよい。このような構成とすることにより、個体識別情報の問い合せを行うことにより、新規に制御オブジェクトの構築が必要か否かを判断することができるようになる。

また、上記構成から成るネット家電機器コントローラは、第２の制御オブジェクト或いは第２の制御対象定義ファイルのダウンロード元として限定されるサーバのアドレス情報を静的に格納する手段を有して成る構成にするとよい。そして、本発明に係るネットワークシステムは、当該構成から成るネット家電機器コントローラと；前記ネット家電機器コントローラに統括制御されるネット家電機器と；前記広域ネットワークに接続され、前記ネット家電機器コントローラで静的に格納されたアドレス情報に基づいて、第２の制御オブジェクト或いは第２の制御対象定義ファイルのダウンロード元として限定されるサーバと；を有して成る構成にするとよい。

このような構成とすることにより、信頼できるダウンロード元からのみ、第２の制御オブジェクト或いは第２の制御対象定義ファイルを読み込むことができるので、その安全性を高めることが可能となる。

また、ネット家電機器のみでも、その商品化の可能性を広げるべく、第２の制御オブジェクト或いは第２の制御対象定義ファイルの読込みプロトコル等を公開した場合であっても、前記サーバをネット家電機器コントローラのメーカ（或いは、その子会社や関連会社など）が所有・運営しておけば、ネット家電機器のみを製造する他メーカに対して、前記サーバの使用許可契約等を要求することができる。従って、ネット家電機器コントローラのメーカは、自社の権利を保護し、或いは、契約料等として利益の還元を得ることが可能となる。

上記したように、本発明に係るネット家電機器コントローラ及びこれを用いたネットワークシステムであれば、既に規格化された統一仕様で規定される共通のプロパティのみならず、機器毎に規定される独自のプロパティについても、統一的に制御することを可能とし、また、所定の仕様に準拠したネット家電機器のみでも、その商品化の可能性を広げる得るビジネスモデルを構築することが可能となる。

以下では、ＥＣＨＯＮＥＴ仕様に準拠したホームネットワークの統括制御手段として、本発明に係るネット家電機器コントローラを用いた場合を例示しながら、本発明の内容を詳細に説明する。

図１は、ＥＣＨＯＮＥＴ仕様におけるグループ情報（グループコード）及びクラス情報（クラスコード）の一定義例を示す図であり、ＥＣＨＯＮＥＴコンソーシアムのホームページ（http://www.echonet.gr.jp/）で公開されている定義情報の一部抜粋である。

本図に示すように、ＥＣＨＯＮＥＴ仕様において、「センサー関連機器グループ」のカテゴリには、グループコード（０ｘ００）が割り当てられている。また、当該グループに属するクラスとして、ガス漏れセンサ（０ｘ０１）、防犯センサ（０ｘ０２）、非常ボタン（０ｘ０３）など多数のセンサが定義されている。また、「空調関連機器グループ」のカテゴリには、グループコード（０ｘ０１）が割り当てられており、そのクラスとして、家庭用エアコン（０ｘ３０）や冷風機（０ｘ３１）などが定義されている。同様に、「住宅設備機器グループ」のカテゴリには、グループコード（０ｘ０２）が割り当てられており、そのクラスとして、電動ブラインド（０ｘ６０）や電動シャッタ（０ｘ６１）などが定義されている。なお、上記各クラスは、先述の通り、ＥＰＣと呼ばれる属性識別子を持っており、各機器の属性を表現する識別コードが割り当てられている。また、各ＥＰＣには、ＥＤＴと呼ばれる属性値が定義されており、一般的には、ＥＰＣ毎に独自のＥＤＴが定義される。この他にも、ＥＣＨＯＮＥＴ仕様では、多くのグループとクラスが定義されているが、詳細については割愛する。

また、ＥＣＨＯＮＥＴ仕様では、図２に示すように、各クラス共通のプロパティを持つ「スーパークラス（基底クラス）」を規定し、その中で機器のスイッチ状態（ＯＮ／ＯＦＦ）やメーカコード、製品コード、個体識別情報などを規定している。上記のスーパークラスは、ＥＣＨＯＮＥＴ仕様に準拠した全ての機器に搭載が義務付けられている。そのため、アプリケーションは、ＥＣＨＯＮＥＴ仕様に準拠したネット家電機器のスーパークラスに問い合わせることで、その機器を製造したメーカを知ることが可能である。ただし、スーパークラス内で規定されるＥＰＣには、その搭載が必須とされているものと任意（オプション）とされているものがあり、注意を要する。例えば、機器のメーカコードは必須であるが、製品コードは必須ではない。

本発明に係るネット家電機器コントローラは、上記のスーパークラス内で規定されるＥＰＣを利用して、被制御機器の特定を行い、その特定結果に応じたプログラムモジュール或いは制御対象定義ファイルを個別に読み込むことで、メーカ固有の制御オブジェクトを構築し、異なるメーカ間でも共通したアプリケーションを提供しようとするものである。

図３は、本発明に係るネット家電機器コントローラを備えたホームネットワークの一実施形態を示すシステムブロック図である。本図に示すように、本発明に係るホームネットワークは、共通の通信プロトコルを持つネット家電機器コントローラＡ（以下、単にコントローラＡと呼ぶ）と被制御機器Ｂとを伝送経路Ｃ経由で接続することにより構築されている。また、コントローラＡは、図６に示すように、インターネットＤ（或いは、その他の広域ネットワーク）への接続手段であるゲートウェイａ７を有して成り、インターネットＤを介して、後述する制御対象定義ファイルを保持するサービスサイトＥにアクセス可能な構成とされている。なお、コントローラＡとサービスサイトＥとの接続関係については後ほど詳細に説明する。

コントローラＡは、自身の動作を統括制御するコントローラ制御部ａ１と、被制御機器Ｂとの通信を制御する通信制御部ａ２と、伝送経路Ｃとの接続を確立するための通信インターフェイスａ３と、コントローラ制御部ａ１によって実行される各種アプリケーションやオブジェクトの作業領域として用いられるメモリ部ａ４と、を有して成る。なお、上記の通信制御部ａ２及び通信インターフェイスａ３は、一般的に被制御機器Ｂのそれと同一規格とされている。

メモリ部ａ４には、主制御アプリケーションＡＰＰ１のほか、本発明の特徴部分であるオブジェクト管理アプリケーションＡＰＰ２が展開される。また、メモリ部ａ４には、被制御機器Ｂの特定に際してその個別情報を問い合わせるためのデフォルトオブジェクトＯＢＪ０が展開されるほか、制御対象となる被制御機器Ｂが増える毎に、制御オブジェクトＯＢＪ１、ＯＢＪ２、…、ＯＢＪｎが動的に追加されていく。なお、制御オブジェクトＯＢＪ１〜ＯＢＪｎとは、被制御機器毎に用意されたプログラムモジュールのことである。

動的に追加される制御オブジェクトＯＢＪ１〜ＯＢＪｎは、制御オブジェクト管理アプリケーションＡＰＰ２によって管理されるものであり、いわゆるオブジェクト指向言語によってプログラミングされている。各制御オブジェクトＯＢＪ１〜ＯＢＪｎは、制御オブジェクト管理アプリケーションＡＰＰ２を介して主制御アプリケーションＡＰＰ１から指令を受け、通信制御部ａ２に具体的なコマンドを渡す。当該コマンドは、通信インターフェイスａ３を経由して伝送経路Ｃに伝達され、被制御機器Ｂの通信インターフェイスｂ３で受信される。これにより、被制御機器Ｂはコマンドに応じた動作を行う。

このように、制御オブジェクトＯＢＪ１〜ＯＢＪｎは、主制御アプリケーションＡＰＰ１に動的にリンクされるプログラムモジュールとみなすことができる。すなわち、主制御アプリケーションＡＰＰ１は、制御オブジェクトＯＢＪ１〜ＯＢＪｎの共通インターフェイスであるオブジェクト管理アプリケーションＡＰＰ２を介して、個々の制御オブジェクトＯＢＪ１〜ＯＢＪｎにアクセスし、制御対象ごとに異なる動作を行うことができる。

被制御機器Ｂは、家庭用エアコンや冷蔵庫などのネット家電機器であり、自身の動作を統括制御する機器制御部ｂ１と、コントローラＡとの通信を制御する通信制御部ｂ２と、伝送経路Ｃとの接続を確立するための通信インターフェイスｂ３と、各種機器情報の格納領域として用いられるメモリ部ｂ４と、を有して成る。

メモリ部ｂ４には、グループ情報（グループコード）、クラス情報（クラスコード）、メーカ情報（メーカコード）、製品情報（製品コード）や、個体識別情報、制御状態値などが保持される。上記各情報のうち、グループ情報、クラス情報、メーカ情報、及び、製品情報については、被制御機器Ｂに特有の不変値であるため、一般にメモリ部ｂ４の不揮発領域（ＲＯＭ［Read Only Memory］などの不揮発性メモリ）に保持される。一方、上記各情報のうち、個体識別情報や制御状態値については、その時々によって変化する変動値であるため、一般にメモリ部ｂ４の揮発領域（ＲＡＭ［Random Access Memory］などの揮発性メモリ）に保持される。なお、上記の個体識別情報とは、個々の被制御機器を一意に識別するためにコントローラＡから付与される情報であり、初期値としては、０ｘ０が保持されている。

コントローラＡからネットワーク経由で伝送されたコマンドは、通信インターフェイスｂ３で受信され、通信制御部ｂ２を経由して機器制御部ｂ１に与えられる。これにより、被制御機器Ｂでは、コマンドに応じた動作が実現される。

上記構成から成るコントローラＡは、被制御機器Ｂ１〜Ｂｎの制御に際し、まずデフォルトオブジェクトＯＢＪ０を構築して被制御機器Ｂ１〜Ｂｎのグループや種別が不明のまま当該機器との通信を確立した後、改めて被制御機器Ｂ１〜Ｂｎにその個別情報を問い合せ、その内容に応じて適切な制御対象定義ファイル読み込んで制御オブジェクトＯＢＪ１〜ＯＢＪｎのインスタンスを再構築する構成とされている。以下では、コントローラＡによる被制御機器Ｂの制御シーケンス（コントローラＡによる制御オブジェクトの構築シーケンス）について、図４を参照しながら、詳細に説明する。

被制御機器Ｂ１〜Ｂｎ（図３の被制御機器Ｂと同一構成）は、その起動に際して、起動時アナウンス（Ｓ１）を伝送経路Ｃに送信する。当該送信は、ブロードキャスト、マルチキャスト、または、コントローラＡを特定したユニキャストなどで行なわれ、コントローラＡに到達することが必要である。なお、起動時アナウンス（Ｓ１）の内容には、被制御機器Ｂ１〜Ｂｎのグループ情報とクラス情報が含まれている。

起動時アナウンス（Ｓ１）を受信したコントローラＡは、該起動時アナウンス（Ｓ１）に含まれるグループ情報とクラス情報から対象機器を確認し、定義ファイルデータベースａ５（図６を参照）からデフォルトの制御対象定義ファイルを読み込む（Ｓ２）。

なお、デフォルトの制御対象定義ファイルは、全機種共通のプログラムモジュールであってもよいし、クラス共通のプログラムモジュールであってもよい。ここで重要なのは、最初に読み込まれるデフォルトのプログラムモジュールにより、コントローラＡが、被制御機器Ｂ１〜Ｂｎに対してスーパークラスに規定されている属性情報を問い合わせることができるようになることである。

デフォルトのプログラムモジュールが全機種共通であった場合は、グループ情報やクラス情報を検索する必要がなく、単に被制御機器Ｂ１〜Ｂｎとの通信を確立し、スーパークラスに定義されている属性情報の問い合せを行えるだけでよい。ただし、当該方式を採用した場合、その後最低１回は、被制御機器用のプログラムモジュールを構築し直さなければならない。なぜなら、この時点では未だスーパークラスの機能しかインスタンス化（実体化）することができず、スーパークラスのインスタンス（実体）が被制御機器Ｂ１〜Ｂｎから受け取ったクラス情報などに基づいて全機種共通のオブジェクトでよいと判断し、読み込んだデフォルトの制御対象定義ファイルを元にオブジェクトのインスタンスを生成して初めて、その機器を制御することが可能となるからである。

一方、デフォルトのプログラムモジュールがクラス共通のプログラムモジュールである場合には、その後、被制御機器Ｂ１〜Ｂｎの個別情報（メーカ情報と製品情報）を問い合わせ、クラス共通のプログラムモジュールだけで十分と判断した場合、その後の被制御機器用プログラムモジュールの再構築が必要なくなる。

なお、図４のシーケンスは、上記２つのケースのうち、デフォルトのプログラムモジュールがクラス共通の場合のみを示している。

コントローラＡは、デフォルトの制御対象定義ファイルを読み込んだ後、デフォルトオブジェクトＯＢＪ０のインスタンスを生成する（Ｓ３）。このように、被制御機器Ｂ１〜Ｂｎの属性情報管理に際しては、制御対象個別のプログラムを用意する必要はなく、一部の共通機能をデフォルトオブジェクトＯＢＪ０（スーパークラス）として、一まとめに取り扱う方がプログラムのオーバーヘッドを縮小できる。なお、スーパークラスには、図２に示すように、実行部分（実行可能なプログラム）も含まれており、具体的には、被制御機器Ｂ１〜Ｂｎのグループ情報、クラス情報、メーカ情報、製品情報、個体識別情報の管理プログラムと基本的な通信プログラムがそれに当たる。

デフォルトオブジェクトＯＢＪ０は、そのインスタンスが生成された直後に、被制御機器Ｂ１〜Ｂｎとのリンク処理を行う（Ｓ４）。なお、上記のリンク処理とは、具体的には起動時アナウンス（Ｓ１）の内容に含まれている被制御機器Ｂ１〜Ｂｎのアドレス情報などをオブジェクト内に保持し、自身が担当する被制御機器を確定する処理のことである。

コントローラＡは、デフォルトオブジェクトＯＢＪ０を作成した後、当該デフォルトオブジェクトＯＢＪ０に対して被制御機器Ｂ１〜Ｂｎの個別情報を問い合わせる（Ｓ５）。具体的には、被制御機器Ｂ１〜Ｂｎに保持されているメーカ情報と製品情報（図２、図３を参照）を問い合わせる。

個別情報の問い合せを受けたデフォルトオブジェクトＯＢＪ０は、担当する被制御機器Ｂ１〜Ｂｎに対して個別情報要求（Ｓ６）を行い、被制御機器Ｂ１〜Ｂｎが返す個別情報応答（Ｓ７）から被制御機器Ｂ１〜Ｂｎの個別情報を受け取る。

被制御機器Ｂ１〜Ｂｎの個別情報を受け取ったデフォルトオブジェクトＯＢＪ０は、個別情報通知（Ｓ８）として、前記個別情報をコントローラＡに通知する。個別情報を受け取ったコントローラＡは、当該個別情報の内容から読み込むべき制御対象定義ファイルを確定してその読込みを行い（Ｓ９）、改めて制御オブジェクトＯＢＪ１〜ＯＢＪｎを生成する（Ｓ１０）。なお、デフォルトオブジェクトＯＢＪ０は、この時点でその役割を終えるため、デストラクト（破棄）される（Ｓ１１）。

図５は、制御オブジェクトの動的な取込みを概念的に示したブロック図である。本図に示すように、制御オブジェクトＯＢＪ１〜ＯＢＪｎは、制御オブジェクト管理アプリケーションＡＰＰ２が制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎを読み込むことにより、コントローラＡ内部でインスタンス化され、主制御アプリケーションＡＰＰ１にリンクされる。なお、制御オブジェクトＯＢＪ１〜ＯＢＪｎをプログラムモジュールとして直接読み込み、主制御アプリケーションＡＰＰ１にリンクしても構わないが、一般的にはスケーラビリティの観点から、制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎを読み込み、コントローラＡ内部でオブジェクトのインスタンスを生成するほうが好ましい。

再び、図４に戻って、コントローラＡによる制御シーケンスの説明を続ける。コントローラＡは、生成された制御オブジェクトＯＢＪ１〜ＯＢＪｎを自己の制御プログラムの一部として取り込むが、このとき、オブジェクトを一意に識別するコードを生成し、個体識別情報として、制御オブジェクトＯＢＪ１〜ＯＢＪｎに通知する（Ｓ１２）。個体識別情報は、被制御機器Ｂ１〜Ｂｎに設けられたメモリ部ｂ４の揮発領域（図３を参照）に保持される情報であり、例えば、ＥＣＨＯＮＥＴ仕様では、バージョン３．０以後、必須情報としてその搭載が規定されているものである。なお、ＥＣＨＯＮＥＴ以外においても、ネットワークを通じて、何らかの識別子を書き込めることが好ましい。

制御オブジェクトＯＢＪ１〜ＯＢＪｎは、受け取った個体識別情報を書き込むよう、伝送経路Ｃを介して被制御機器Ｂ１〜Ｂｎに指示を送る（Ｓ１３）。指示を受けた被制御機器Ｂ１〜Ｂｎは、自己の個体識別情報を更新する（Ｓ１４）。これにより、コントローラＡは、以後、起動時アナウンス（Ｓ１）と同様のメッセージが被制御機器Ｂ１〜Ｂｎから送信されてきても、個体識別情報の問い合せを行うことにより、新規に制御オブジェクトの構築が必要か否かを判断することができるようになる。

ただし、メモリ部ａ４の揮発領域がクリアされる可能性がなければ格別、実際にはコントローラＡ（またはサーバ）も停止し得るという前提の下、メモリ部ａ４の揮発領域に構築されている制御オブジェクトを再利用する場合には、新たな個体識別情報を用いて当該制御オブジェクトをシリアライズし直さなければならない。従って、制御オブジェクトの再利用に際しては、当該制御オブジェクトを読み書き可能な形式に変換して、不揮発領域に置いておくことが必要となる。具体的には、上記制御オブジェクトをシリアライズした制御対象定義ファイルをコピーファイルの形で不揮発的に残しておく必要がある。なお、当該コピーファイルのフォーマットは、元の制御対象定義ファイルと同一（後述するＸＭＬ［eXtensible Markup Language］形式）である。ただ、そこに具体的なデータが記載され、元の揮発領域とは別の場所（不揮発領域）に保管される。

すなわち、当該シーケンスで個体識別情報が既に存在する場合には、前述のステップＳ９にて上記コピーファイルを読み込み、先の制御オブジェクトを再構築することになる。このように、本発明に係るコントローラＡでは、制御対象定義ファイルが初めて読み込まれたものであるか、その後に個別情報が書き込まれたコピーファイルであるかは区別されておらず、被制御機器から個体識別情報が返された場合、それに対応するコピーファイルが格納されていれば、それを読み込むことになり、格納されていなければ、新規に制御対象定義ファイルを読み込むことになる。

このようにして、コントローラＡ内部には、被制御機器Ｂ１〜Ｂｎ毎の制御プログラムモジュールが構築される。以後、コントローラＡは、制御コマンドを受け付けた場合（Ｓ１５）、当該制御コマンドに基づき、関連する各制御オブジェクトＯＢＪ１〜ＯＢＪｎに対してコマンドの実行を行う（Ｓ１６）。各制御オブジェクトＯＢＪ１〜ＯＢＪｎは、各被制御機器Ｂ１〜Ｂｎに対してコマンドの送信（Ｓ１７）とコマンドの応答受取り（Ｓ１８）を行い、被制御機器Ｂ１〜Ｂｎを実際に制御することができるようになる。制御オブジェクトＯＢＪ１〜ＯＢＪｎは、このような実行結果をコントローラＡに対してコマンド実行結果送信（Ｓ１９）の形で通知し、当該通知を受け取ったコントローラＡは、その旨を制御結果通知（Ｓ２０）としてユーザに報知する。これにより、ユーザは、制御コマンドが首尾よく実施されたことを知ることになる。

以上のようなオブジェクトの構築方法を採用することにより、コントローラＡは、プログラムモジュールさえ用意すれば、どのような被制御機器Ｂ１〜Ｂｎもコントロールできるようになる。すなわち、本実施形態のコントローラＡであれば、日々更新される新しい制御オブジェクトや制御対象定義ファイルを必要に応じて自己のプログラムの一部として利用することができる。従って、既に規格化された統一仕様で規定される共通のプロパティのみならず、被制御機器毎に規定される独自のプロパティについても、統一的に制御することが可能となる。

なお、本発明の実施に際して重要なことは、制御オブジェクトＯＢＪ１〜ＯＢＪｎの構築に先立ち、制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎ（またはプログラムモジュール）がコントローラＡ内部に置かれている必要はないという点である。すなわち、先述したデフォルトの制御対象定義ファイル（またはプログラムモジュール）については、コントローラＡ内に置かれている必要があるが、被制御機器Ｂ１〜Ｂｎ毎の制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎ（またはプログラムモジュール）については、すでに被制御機器Ｂ１〜Ｂｎとの間の通信が確立しており、さらに被制御機器Ｂ１〜Ｂｎのグループや種別が判明しているため、当該制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎの所在が明らかでありさえすれば、別段コントローラＡ内部に置かれている必要がない。

さらに言えば、コントローラＡが一般的なイーサネット（登録商標）プロトコルによるネットワーク接続手段を有しており、かつ、システム内にゲートウェイが存在してインターネットに接続可能な場合には、制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎがシステム内部に置かれている必要すらなく、所定のサーバからインターネットを介して制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎ（またはプログラムモジュール）をダウンロードすればよい。

これにより、コントローラＡは、制御対象定義ファイルＦＩＬＥ１〜ＦＩＬＥｎを保持するためのメモリを節約することができる上に、日々更新される新しい制御対象定義ファイルを必要に応じて自己のプログラムの一部として利用することが可能になり、異なるメーカのネット家電製品であっても、サービスサイトのサーバ上に当該ネット家電製品用の制御対象定義ファイルを置いておくことにより、被制御機器の個別情報を問い合わせて、自動的に必要な制御対象定義ファイルをダウンロードし、アプリケーションに組み込むことが可能になる。

サービスサイトから制御対象定義ファイルをダウンロードする動作について、図６を参照しながら、より具体的に説明する。図６は、コントローラＡとサービスサイトとの接続関係を示す概念図であり、コントローラＡで２つの被制御機器Ｂ１、Ｂ２を制御する様子が示されている。なお、以下の説明において、被制御機器Ｂ１は、コントローラＡ内にその制御対象定義ファイルが搭載済みの機器であり、被制御機器Ｂ２は、コントローラＡ内にその制御対象定義ファイルが未搭載の機器であるとする。

本図に示すように、コントローラＡは、搭載済みの制御対象定義ファイルが格納された定義ファイルデータベースａ５と、制御対象定義ファイルの所在を示した定義ファイル位置情報が格納された位置情報データベースａ６と、インターネットＤへの接続手段であるゲートウェイａ７と、を有して成り、インターネットＤを介して、サービスサイトＥにアクセス可能な構成とされている。一方、サービスサイトＥは、コントローラＡに未搭載の制御対象定義ファイルが格納された定義ファイルデータベースｅ１を有して成る。

まず、コントローラＡが被制御機器Ｂ１からの個別情報を通信インターフェイスａ３で受け取った場合について説明する。この場合、コントローラＡの制御オブジェクト管理アプリケーションＡＰＰ２は、位置情報データベースａ６を検索して、被制御機器Ｂ１用の制御オブジェクトＯＢＪ１とその構築に必要となる制御対象定義ファイルＦＩＬＥ１を特定し、かつ、当該制御対象定義ファイルＦＩＬＥ１がすでに自己の定義ファイルデータベースａ５に保持されていることを知る。そこで、制御オブジェクト管理アプリケーションＡＰＰ２は、定義ファイルデータベースａ５から制御対象定義ファイルＦＩＬＥ１を読み出し、被制御機器Ｂ１用のプログラムモジュールとして、制御オブジェクトＯＢＪ１を構築する。以後、コントローラＡは、制御オブジェクトＯＢＪ１に指令を出して被制御機器Ｂ１に対する制御を行うことが可能となる。なお、被制御機器Ｂ１の状態は、制御オブジェクトＯＢＪ１の属性情報を参照することで知ることができる。

次に、コントローラＡが被制御機器Ｂ２からの個別情報を通信インターフェイスａ３で受け取った場合について説明する。この場合も、コントローラＡの制御オブジェクト管理アプリケーションＡＰＰ２は、位置情報データベースａ６を検索して、被制御機器Ｂ２用の制御オブジェクトＯＢＪ２とその構築に必要となる制御対象定義ファイルＦＩＬＥ２を特定し、かつ、当該制御対象定義ファイルＦＩＬＥ２がインターネットＤ上のサービスサイトＥに置かれていることを知る。そこで、制御オブジェクト管理アプリケーションＡＰＰ２は、ゲートウェイａ７からインターネットＤを経由して、サービスサイトＥにアクセスし、両者間のネットワーク接続を確立する。そして、該ネットワーク接続の確立後、制御オブジェクト管理アプリケーションＡＰＰ２は、定義ファイルデータベースｅ１から制御対象定義ファイルＦＩＬＥ２を取得（ダウンロード）し、被制御機器Ｂ２用のプログラムモジュールとして、制御オブジェクトＯＢＪ２を構築する。以後、コントローラＡは、制御オブジェクトＯＢＪ２に指令を出して被制御機器Ｂ２に対する制御を行うことが可能となる。なお、被制御機器Ｂ２の状態は、制御オブジェクトＯＢＪ２の属性情報を参照することで知ることができる。

以上のように、本実施形態のコントローラＡは、位置情報データベースａ６に制御対象定義ファイル夫々の所在を登録しておくことにより、制御対象定義ファイルＦＩＬＥ１、ＦＩＬＥ２がコントローラＡ内に保持されているか否かを特定する構成とされている。このような構成とすることにより、所望の制御対象定義ファイルがコントローラＡの内外いずれに存在するかに依ることなく、共通の操作で被制御機器Ｂ１、Ｂ２を制御することが可能となる上、制御対象定義ファイルＦＩＬＥ１，ＦＩＬＥ２の読込みを速やかに実施することができるので、制御対象定義ファイルの検索時間を短縮することが可能となる。

また、本実施形態のコントローラＡは、インターネットＤを介してサービスサイトＥのサーバから定期的或いは必要に応じて上記の定義ファイル位置情報をダウンロードする構成とされている。このような構成とすることにより、常に新しい制御対象定義ファイルを提供することが可能になる。

図７は、制御対象定義ファイルの所在を示す位置情報のデータフォーマットの一例である。本図に示すように、本実施形態の位置情報は、グループコード、クラスコード、メーカコード、製品コード、及び、ＵＲＬ［Uniform Resource Locator］形式のファイルアドレスが関連付けられており、メーカコードと製品コードから、所望の制御対象定義ファイルの所在を検索することができる。

例えば、メーカコードが（０ｘ０００８）で、製品コードが（０ｘ３３ＣＣ）である被制御機器については、「http://server/download/brind_maker008.xml」というアドレスから特定されるファイルが所望の制御対象定義ファイルであることが分かる。従って、コントローラＡは、上記ＵＲＬをインターネットから直接読み込めば、所望の制御対象定義ファイルを取得することができる。

また、メーカコードが（０ｘ０００３）で、製品コードが付与されていない被制御機器については、「file://home/conf/aircon.xml」というアドレスから特定されるファイルが所望の制御定義ファイルであることが分かる。なお、製品コードが付されていない場合とは、既に商品化されているＥＣＨＯＮＥＴ仕様の被制御機器であって、製造コードを問い合わせても、その応答がない場合などが想定される。このような場合には、その機器が特殊な機能を持っておらず、クラスの標準的な定義ファイルでも管理可能であるという前提の下、デフォルト定義ファイルが読み込まれることになる。

このような構成とすることにより、メーカ各社が被制御機器の生産と同時にその制御対象定義ファイルを用意しておけば、機器の製造日やメーカ等に関わりなく、本発明のコントローラＡを用いて、被制御機器をコントロールすることが可能となる。

図８は、制御対象定義ファイルの一例を示したものである。本図に示すように、本実施形態の制御対象定義ファイルは、ＸＭＬ形式で記述されている。なお、左端の数字は、説明の便宜上付加した行番号であり、実際のＸＭＬ文書に含まれるものではない。

１行目は、以下に続くデータがＸＭＬ文書であることを示すＸＭＬ宣言である。２〜３行目では、「echonet_node」という要素が定義され、さらにその属性として、「name」、「title」、「netID」、「nodeID」が夫々定義されている。

続く４行目〜１０行目では、「eoj（エコーネットオブジェクト）」という要素が定義され、さらにその属性として、「group_code（グループコード）」、「class_code（クラスコード）」、「instance_code」、「maker_code（メーカコード）」、「product_code（製品コード）」、「name」、「title」が夫々定義されている。これらの属性情報のうち、グループコード、クラスコード、メーカコード、製品コードを示す部分については、被制御機器の個別情報（対象識別コード群）として、被制御機器の特定に用いられる。

以下、１１行目〜２０行目、２１行目〜３２行目、３３行目〜４１行目には、「スイッチ」、「運転モード」、「温度設定」といったＥＰＣが定義されている。

上記のＸＭＬは、オブジェクト指向言語ではなく、データ指向言語である。つまり、本発明に係るコントローラＡの実装部分（アプリケーション部分）では、オブジェクト指向の概念が利用されており、そこで取り扱うデータに関しては、オブジェクト指向言語との相性がよいＸＭＬが利用されていることになる。ＸＭＬがオブジェクト指向のプログラムと相性がよいのは、ＸＭＬが階層構造での表現を得意とし、それがオブジェクト指向の継承と巧くマッチングするからである。

図９は、本発明に係るネットワークシステムを用いたビジネスモデルの一例を示す図であり、コントローラＡの製造メーカではないＹ社が、自社製のコントローラを新たに商品化することなく、被制御機器Ｂのみを商品化する際の概念的な流れを示したものである。

本図に示すように、コントローラＡは、Ｘ社によって商品化されており、Ｘ社は、自社の管理の下、サービスサイトＥを所有・運営しているものとする。なお、サービスサイトＥのサーバは、図６にも示した通り、コントローラＡに未搭載の制御対象定義ファイルＦＩＬＥ２が格納された定義ファイルデータベースｅ１を有して成り、広域ネットワークＤを介して、コントローラＡに対して制御対象定義ファイルＦＩＬＥ２を公開している。なお、制御対象定義ファイルＦＩＬＥ２には、先述の通り、それに記述された被制御機器Ｂに関して、機器の監視、機器の制御、複数の機器の連携動作などが定義されている。

Ｘ社製のコントローラＡは、制御対象定義ファイルＦＩＬＥ２のダウンロード元として限定されるサーバのアドレス情報を静的に格納する手段を有して成る。より具体的に述べると、コントローラＡは、サービスサイトＥのサーバからのみ、制御対象定義ファイルＦＩＬＥ２をダウンロード可能なようにプログラムされている。このような構成とすることにより、信頼できるダウンロード元からのみ、第２の制御オブジェクト或いは第２の制御対象定義ファイルを読み込むことができるので、その安全性を高めることが可能となる。なお、サービスサイトＥのサーバには、予め自社製品の定義ファイルが置かれている。

一方、Ｙ社は、被制御機器Ｂとして有効な製品を商品化しようとしているが、当該被制御機器Ｂを制御または監視するコントローラＡがなければ、商品として成り立たない状況にある。

ここで、Ｘ社は、サービスサイトＥのサーバなどで、制御対象定義ファイルＦＩＬＥ２の読込みプロトコル等を広く公開している。このような情報公開により、Ｙ社は、公開された制御対象定義ファイルＦＩＬＥ２の読込みプロトコル等を自社の被制御機器Ｂに実装し、Ｘ社製のコントローラＡによって制御可能な被制御機器Ｂを製造することができるようになる。従って、Ｙ社にとっては、被制御機器Ｂのみの市場参入が可能となる。一方、Ｘ社にとっては、Ｙ社が作成した被制御機器Ｂの制御手段として、コントローラＡの商品性を高めることが可能となる。

なお、制御対象定義ファイルＦＩＬＥ２の読込みプロトコル等を公開することにより、Ｘ社としては、上記メリットを得ることができる反面、自社の技術が競合他社に利用されるというリスクを負うことになる。しかしながら、本実施形態のネットワークシステムのように、制御対象定義ファイルＦＩＬＥ２のダウンロード元とされるサービスサイトＥのサーバを限定する構成であれば、当該サーバをＸ社が所有・運営することで、その権利を守ることが可能となる。

例えば、Ｙ社製の被制御機器Ｂは、国内のネット家電標準仕様（本実施形態では、ＥＣＨＯＮＥＴ仕様）に準拠しているものの、その機能自体に独自性が強く、別途制御対象定義ファイルＦＩＬＥ２をコントローラＡに読み込ませる必要がある場合について考える。

このような場合、本実施形態のネットワークシステムでは、被制御機器Ｂの制御に必要となる制御対象定義ファイルＦＩＬＥ２をサービスサイトＥのサーバに置かねばならないため、当該サーバをＸ社が所有・運営しておけば、Ｘ社は、被制御機器Ｂのみを製造するＹ社に対して、自社との商業的契約（すなわち、サーバの使用許可契約）を締結しなければ、その商品化（前記サーバに対する制御対象定義ファイルＦＩＬＥ２のアップロード）を認めない、といった制限を設けることができる。このような制限を設けることにより、Ｘ社としては、自社の権利を保護し、或いは、契約料等として利益の還元を得ることが可能となる。一方、Ｙ社としても、一から自社製のコントローラを開発して商品化するよりも、リスクが小さく、かつ、短期間にネット家電機器の商品化を行うことが可能となる。

このように、被制御機器Ｂの制御対象定義ファイルＦＩＬＥ２を公開サーバ上に置き、当該サーバの利用権を商業的に利用することにより、自社のみならず、同プロトコルを製品化する他社にとっても有利となるビジネスモデルを提供することが可能となる。

なお、インターネット等にコンテンツデータを公開し、その利用を提供する従来のサービス（例えば、特許文献２を参照）では、実際にそのコンテンツデータを利用したユーザに対して課金が行われるのに対して、本発明に係るネットワークシステムのプロトコル公開サービスは、末端ユーザからは見えず、課金等も被制御機器Ｂを製造するメーカに割り当てられる。そのため、ネット家電機器のコストには影響を与えるが、ネットワークシステムの運用時にユーザが不快に思う従量制課金などを行なわなくとも運営できるシステムとなっている。

また、従来のＷＥＢページを利用した家庭用機器の遠隔操作サービス（例えば、特許文献３を参照）は、制御プログラムをＷＥＢページからダウンロードして利用するものであり、従来のプログラム配信方法と何ら変わるところがないのに対して、本発明に係るネットワークシステムでは、基本的にプログラムのダウンロードは必要とせず、コントローラＡに組み込まれたプログラムがインターネット上の所定サーバから自動的に定義ファイルをダウンロードするものであるという点で、明らかにその構成を異にするものである。

また、一般のポータルＷＥＢページやレンタルサーバは、いわゆるＷＥＢページの運営場所を提供するサービスであるのに対し、本発明に係るネットワークシステムのそれは、コンテンツデータの保持場所を提供するサービスであるという点で、明らかにその構成を異にするものである。

なお、上記の実施形態では、ＥＣＨＯＮＥＴ仕様に準拠したホームネットワークの統括制御手段として、本発明に係るネット家電機器コントローラを用いた場合を例示して説明を行ったが、本発明の適用対象はこれに限定されるものではなく、その他の仕様に準拠したネット家電機器コントローラにも広く適用することが可能である。

また、本発明の構成は、上記実施形態のほか、発明の主旨を逸脱しない範囲で種々の変更を加えることが可能である。

本発明は、ネット家電機器コントローラの汎用性向上に関して有用な技術である。

は、ＥＣＨＯＮＥＴ仕様におけるグループ情報（グループコード）及びクラス情報（クラスコード）の一定義例を示す図である。 は、スーパークラスを示す概念図である。 は、本発明に係るネット家電機器コントローラを備えたホームネットワークの一実施形態を示すシステムブロック図である。 は、コントローラＡによる被制御機器Ｂの制御シーケンス（制御オブジェクトの構築シーケンス）を説明するための図である。 は、制御オブジェクトの動的な取込みを概念的に示したブロック図である。 は、コントローラＡとサービスサイトとの接続関係を示す概念図である。 は、制御対象定義ファイルの所在を示す位置情報のフォーマット例である。 は、制御対象定義ファイルの一例を示したものである。 は、本発明に係るネットワークシステムを用いたビジネスモデルの一例を示す図である。

符号の説明

Ａ ネット家電機器コントローラ
ａ１ コントローラ制御部
ａ２ 通信制御部
ａ３ 通信インターフェイス
ａ４ メモリ部
ａ５ 定義ファイルデータベース
ａ６ 位置情報データベース
ａ７ ゲートウェイ
Ｂ（Ｂ１〜Ｂｎ） 被制御機器
ｂ１ 機器制御部
ｂ２ 通信制御部
ｂ３ 通信インターフェイス
ｂ４ 機器情報記憶部
Ｃ 伝送経路
Ｄ インターネット
Ｅ サービスサイト
ｅ１ 定義ファイルデータベース
ＡＰＰ１ 主制御アプリケーション
ＡＰＰ２ オブジェクト管理アプリケーション
ＯＢＪ０ デフォルトオブジェクト
ＯＢＪ１〜ＯＢＪｎ 制御オブジェクト
ＦＩＬＥ１〜ＦＩＬＥｎ 制御対象定義ファイル

Claims (8)

1. ホームネットワークを構築するネット家電機器の統括制御を行うネット家電機器コントローラであって、前記ネット家電機器が通知するグループ情報及びクラス情報から当該ネット家電機器の属するグループ及びクラスを識別する手段と；識別されたグループ及びクラスでの汎用的制御に必要な第１の制御オブジェクトを読み込んで動的に取り込む手段、或いは、前記グループ及びクラスに応じた第１の制御対象定義ファイルを読み込み、当該第１の制御対象定義ファイルから前記第１の制御オブジェクトを生成して動的に取り込む手段と；前記第１の制御オブジェクトを用いて前記ネット家電機器にその個別情報を問い合わせる手段と；前記ネット家電機器が通知する個別情報から当該ネット家電機器の個別的制御に必要な第２の制御オブジェクトを読み込んで動的に取り込む手段、或いは、前記個別情報に応じた第２の制御対象定義ファイルを読み込み、当該第２の制御対象定義ファイルから前記第２の制御オブジェクトを生成して動的に取り込む手段と；前記第２の制御オブジェクトを用いて前記ネット家電機器の個別的制御を行う手段と、を有して成ることを特徴とするネット家電機器コントローラ。
2. 広域ネットワークへの接続手段を有して成り、前記広域ネットワークを介して所定のサーバから、第２の制御オブジェクト或いは第２の制御対象定義ファイルをダウンロードすることを特徴とする請求項１に記載のネット家電機器コントローラ。
3. 前記ネット家電機器の個別情報と、第２の制御オブジェクト或いは第２の制御対象定義ファイルの所在情報と、が関連付けられた位置情報を格納する手段を有して成ることを特徴とする請求項２に記載のネット家電機器コントローラ。
4. 前記広域ネットワークを介して所定のサーバから定期的或いは必要に応じて前記位置情報をダウンロードすることを特徴とする請求項３に記載のネット家電機器コントローラ。
5. 第２の制御オブジェクト或いは第２の制御対象定義ファイルがコントローラ内に保持されているか否かを特定する手段を有して成ることを特徴とする請求項２〜請求項４のいずれかに記載のネット家電機器コントローラ。
6. 第２の制御オブジェクトを一意に識別する個体識別情報を制御対象のネット家電機器に通知する手段と、前記ネット家電機器が通知する個体識別情報に基づいて第２の制御オブジェクト或いは第２の制御対象定義ファイルの読込みを制限する手段と、を有して成ることを特徴とする請求項１〜請求項５のいずれかに記載のネット家電機器コントローラ。
7. 第２の制御オブジェクト或いは第２の制御対象定義ファイルのダウンロード元として限定されるサーバのアドレス情報を静的に格納する手段を有して成ることを特徴とする請求項２〜請求項５のいずれかに記載のネット家電機器コントローラ。
8. 請求項７に記載のネット家電機器コントローラと；当該ネット家電機器コントローラに統括制御されるネット家電機器と；前記広域ネットワークに接続され、前記ネット家電機器コントローラで静的に格納されたアドレス情報に基づいて、第２の制御オブジェクト或いは第２の制御対象定義ファイルのダウンロード元として限定されるサーバと；を有して成るネットワークシステム。

Images