(57)【特許請求の範囲】
【請求項１】
単数又は複数の制御対象を制御する電子機器において、
上記制御対象の属性情報を保持する属性情報保持手段と、
上記属性情報保持手段を管理し、上記属性情報保持手段の保持する属性情報を他の電子機器の備える属性情報管理手段に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理手段と、
上記制御対象において発生したイベントのメッセージを上記電子機器内の他のサービスモジュールに送信するメッセージ送信手段と、
上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手段と
を備えることを特徴とする電子機器。
【請求項２】
上記電源の停止状態は、上記電子機器の備えるＣＰＵを停止させると共に消費電力を抑えた待機状態とすることを特徴とする請求項１記載の電子機器。
【請求項３】
単数又は複数の制御対象を制御する電子機器において、
上記制御対象の属性情報を保持し、他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも併せて保持する属性情報保持手段と、
上記属性情報保持手段を管理して上記属性情報保持手段の保持する属性情報について、上記他の電子機器から委託された上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理手段と、
上記制御対象において発生したイベントのメッセージを上記電子機器内の他のサービスモジュールに送信するメッセージ送信手段と、
上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手段と
を備えることを特徴とする電子機器。
【請求項４】
上記属性情報管理手段は、上記属性情報保持手段の保持する属性情報を、上記他の電子機器からの委託に応じて上記属性情報保持手段の保持する上記他の電子機器の制御対象の属性情報をも、上記他の電子機器以外の他の電子機器に送出して外部からの照会に対する応答を委託してから電源を停止状態にすることを特徴とする請求項３の電子機器。
【請求項５】
上記電源の停止状態は、上記電子機器の備えるＣＰＵを停止させると共に消費電力を抑えた待機状態とすることを特徴とする請求項４記載の電子機器。
【請求項６】
単数又は複数の制御対象の電源を制御する電源制御方法において、
上記制御対象の属性情報を取得する属性情報取得工程と、
上記属性情報取得工程にて取得した属性情報を管理し、上記属性情報を他の電子機器に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理工程と、
上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信工程と、
上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト工程と
を有することを特徴とする電源制御方法。
【請求項７】
単数又は複数の制御対象の電源を制御する電源制御方法において、
上記制御対象の属性情報を取得し、他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも併せて取得する属性情報取得工程と、
上記属性情報取得工程にて取得した属性情報について、上記他の電子機器から委託された上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理工程と、
上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信工程と、
上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト工程と
を有することを特徴とする電源制御方法。
【請求項８】
上記属性情報管理工程は、上記属性情報取得工程にて取得した属性情報を、上記他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも、上記他の電子機器以外の他の電子機器に送出してこれらの属性情報について外部からの照会に対する応答を委託してから電源を停止状態にすることを特徴とする請求項７記載の電源制御方法。
【請求項９】
単数又は複数の制御対象の属性情報を取得する属性情報取得手順と、
上記属性情報取得手順にて取得した属性情報を他の電子機器に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理手順と、
上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信手順と、
上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手順と
を有するプログラムが記録された記録媒体。
【請求項１０】
単数又は複数の制御対象の属性情報を取得すると共に他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも併せて取得する属性情報取得手順と、
上記属性情報取得手順にて取得した属性情報について、上記他の電子機器からの委託された上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理手順と、
上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信手順と、
上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手順と
を有するプログラムが記録された記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、制御対象の属性情報を保持してその属性情報に対する照会に応答する電子機器、制御対象の電源を制御する電源制御方法、及び制御対象の属性情報に対する照会に応答する一連の処理手順を記録された記録媒体に関する。
【０００２】
【従来の技術】
従来、例えば、テレビジョン受像器、ビデオテープレコーダ、チューナ等のＡＶ機器が接続され、オーディオ信号、映像信号、制御信号その他の情報信号が伝送されるネットワークが提供されている。このネットワークとしては、ネットワークに接続されるＡＶ機器が分散してそれぞれ動作すると共に、ネットワークを介して伝送される情報信号に応じて協調動作するいわゆる分散協調ネットワークがある。
【０００３】
分散協調ネットワークにおいては、ノードとしての機能を有する電子機器は、制御対象であるオブジェクトのサービスモジュールの属性情報を管理するサービスレジストリを有し、ネットワークを介して他の機器のサービスモジュールにもアクセス可能な分散協調動作をするネットワークを形成する。
【０００４】
【発明が解決しようとする課題】
ところで、家庭内のＡＶネットワークを考えたときに、接続の変化が簡単に起きる可能性を考慮すれば、他のノードのサービスモジュールに関する情報をサービスレジストリが保持することは可能な限り避けたほうが良い。
【０００５】
ここでいうＡＶネットワークとは、通常据え置きで接続の変化はほとんどないであろうテレビジョン受像器等のみならず携帯型のＣＤプレーヤーやビデオカメラ等の接続も含む。このようないつ切断されるかわからない機器に関する情報を例えば接続時に特定のサーバに格納することは無駄になる可能性が高いし必要でもない。
【０００６】
したがって、接続された際に他のサーバを統括するプロキシサーバ（proxy server）に常に委任するという解決法によると、ネットワークへの機器の接続や切り離しが頻繁に行われるであろう家庭内でのＡＶ機器のネットワークではプロキシサーバが切り離されることも十分考えられるので、切断時の処理を行わなければならない。
【０００７】
また、接続時に委任する場合には、検索があった時点までに接続の変更が行われている可能性があるため、プロキシサーバの持つデータの保証がしにくく使用時に確認が必要であった。
【０００８】
しかし、一方で各ノードのサービスレジストリが協調作業をする分散協調型のネットワークにおいては、このネットワークを流れる検索要求のパケットの監視と処理を行うために常にＣＰＵと通信周りのサービスモジュールは稼動状態にある必要があるので電力を消費する。
【０００９】
すなわち、基本となるネットワーク中の各ノードのサービスレジストリが分散協調動作をするシステムでは、ノード内の全てのサービスモジュールが使われていない場合であっても、サービスレジストリが検索を処理して答えるために、宛先が特定されずに配信されるブロードキャストメッセージがある。
【００１０】
このため、ＣＰＵは、このブロードキャストメッセージを処理するために常に作動している必要があるので、サービスモジュールが使用されていないときにも電力が消費される。
【００１１】
この発明は、上述の実情に鑑みてなされるものであって、各ノードのサービスレジストリのＣＰＵがブロードキャストメッセージに応答するために常に動作する必要のないような電子機器、及び電源を制御する電源制御方法並びにこのような手順が記録された記録媒体を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上述の課題を解決するために、この発明に係る電子機器は、単数又は複数の制御対象を制御するものであって、上記制御対象の属性情報を保持する属性情報保持手段と、上記属性情報保持手段を管理し、上記属性情報保持手段の保持する属性情報を他の電子機器の備える属性情報管理手段に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理手段と、上記単数又は複数の制御対象において発生したイベントのメッセージを上記電子機器内の他のサービスモジュールに送信するメッセージ送信手段と、上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手段とを備えるものである。
【００１３】
また、この発明に係る電子機器は、単数又は複数の制御対象を制御する電子機器であって、上記制御対象の属性情報を保持し、他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも併せて保持する属性情報保持手段と、上記属性情報保持手段を管理して上記属性情報保持手段の保持する属性情報について、上記他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理手段と、上記制御対象において発生したイベントのメッセージを上記電子機器内の他のサービスモジュールに送信するメッセージ送信手段と、上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手段とを備えるものである。
【００１４】
上述の課題を解決するために、この発明に係る電源制御方法は、単数又は複数の制御対象の電源を制御する電源制御方法において、上記制御対象の属性情報を取得する属性情報取得工程と、上記属性情報取得工程にて取得した属性情報を管理し、上記属性情報を他の電子機器に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理工程と、上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信工程と、上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト工程とを有するものである。
【００１５】
また、この発明に係る電源制御方法は、単数又は複数の制御対象の電源を制御する電源制御方法であって、上記制御対象の属性情報を取得し、他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも併せて取得する属性情報取得工程と、上記属性情報取得工程にて取得した属性情報について、上記他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理工程と、上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信工程と、上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト工程とを有するものである。
【００１６】
上述の課題を解決するために、この発明に係る記録媒体は、単数又は複数の制御対象の属性情報を取得する属性情報取得手順と、上記属性情報取得手順にて取得した属性情報を他の電子機器に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理手順と、上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信手順と、上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手順とを有するプログラムが記録されたものである。
【００１７】
また、この発明に係る記録媒体は、単数又は複数の制御対象の属性情報を取得すると共に他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報をも併せて取得する属性情報取得手順と、上記属性情報取得手順にて取得した属性情報について、上記他の電子機器からの委託に応じて上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理手順と、上記制御対象において発生したイベントのメッセージを電子機器内の他のサービスモジュールに送信するメッセージ送信手順と、上記イベントのメッセージを、ネットワークを介して上記他の電子機器にブロードキャストするブロードキャスト手順とを有するプログラムが記録されたものである。
【００１８】
【発明の実施の形態】
以下、この発明に係る電子機器、電源制御方法及び記録媒体について、図面を参照して説明する。
【００１９】
図１は、ノード（node）として機能する電子機器として、テレビジョン受像器２及びビデオテープレコーダ３をネットワーク４にて接続したＡＶシステムの通信系を示す機能ブロック図である。
【００２０】
ここでテレビジョン受像器２及びビデオテープレコーダ３の通信系は、制御対象であるオブジェクトが異なる点と、このオブジェクトの相違により各機器において制御手順が異なる点を除いて共通の構成でなる。したがって、以下の説明において共通する構成は共通の英文字を付して示し、各機器ごとの重複した説明は省略する。
【００２１】
テレビジョン受像器２は、図示しないチューナ部において、所望のチャンネルを受信してビデオ信号及びオーディオ信号を出力する。またテレビジョン受像器２は、図示しないモニタ部において、チューナ部より出力されるビデオ信号を表示し、又はビデオテープレコーダ３で再生したビデオ信号を表示する。
【００２２】
テレビジョン受像器２において、各オブジェクト２Ａ及び２Ｂは、それぞれチューナ部及びモニタ部を制御する制御モジュールにより構成され、このテレビジョン受像器２内において、それぞれ固有のＩＤが割り当てられるようになされている。
【００２３】
これに対してビデオテープレコーダ３は、図示しないチューナ部において、所望のチャンネルを受信してビデオ信号及びオーディオ信号を出力する。さらにビデオテープレコーダ３は図示しない磁気記録再生部において、チューナ部又はテレビジョン受像器２で受信したビデオ信号及びオーディオ信号を記録し、また記録したビデオ信号及びオーディオ信号を再生する。
【００２４】
ビデオテープレコーダ３において、オブジェクト３Ａ及び３Ｂは、それぞれチューナ部及び磁気記録再生部を制御する制御サービスモジュール（service module）により構成され、ビデオテープレコーダ３内において固有のＩＤが割当てられるようになされている。
【００２５】
これらのオブジェクト２Ａ〜３Ｂは、不特定多数に通知する必要のある各種イベント（event）が発生すると、イベントマネージャ（event manager）２Ｄ、３Ｄを介して、機器内の他のサービスモジュールにイベントを通知し、また必要に応じてイベントマネージャ２Ｄ、３Ｄ、ブロードキャストマネージャ２Ｆ、３Ｆ、ネットワーク４を介して外部機器にイベントを通知する。
【００２６】
ここでイベントとは、各オブジェクト２Ａ〜３Ｂの制御対象における状態の変化を意味する。例えば、ビデオテープレコーダ３においては、例えばユーザが操作子を操作してチューナ部の受信チャンネルを切り換えた場合、磁気テープの装填、排出、再生の終了等が該当する。
【００２７】
また、各機器２、３がネットワーク４に接続された場合もイベントの発生であり、テレビジョン受像器２及びビデオテープレコーダ３においては、図示しないオブジェクトの制御対象によりネットワーク４への接続が物理的に検出され、この検出結果に基づいてこのオブジェクトより、このイベント情報が通知されるようになされている。
【００２８】
各オブジェクト２Ａ〜３Ｂは、イベントマネージャ２Ｄ、３Ｄを経由して機器内サービスモジュールとの間で送受するメッセージによりこのようなイベントの発生を機器内の各サービスモジュールに通知する。イベントマネージャ２Ｄ、３Ｄは、このイベントを機器外に通知する際に、ブロードキャストマネージャ２Ｆ、３Ｆに対してメッセージのブロードキャスト（broadcast）を依頼する。
【００２９】
さらにオブジェクト２Ａ〜３Ｂは、機器内の他のオブジェクトより送出された自己宛のメッセージ、他の機器よりネットワーク４に送出された自己宛のメッセージを取得しこれにより他のオブジェクト、さらには外部機器における状態変化に応動して制御対象の動作を制御するようになされている。
【００３０】
このようなメッセージ交換において、これらのオブジェクト２Ａ〜３Ｂは、メッセンジャ（messenger）２Ｃ、３Ｃを介してイベントマネージャ２Ｄ、３Ｄ及び属性情報管理手段であるサービスレジストリ（service registry）２Ｆ、３Ｆにメッセージを通知する。そして、このイベントマネージャ２Ｄ、３Ｄ及びサービスレジストリ２Ｅ、３Ｅにおけるメッセージの配送により、機器内の登録済みの配送先、機器外の不特定の配送先にメッセージを通知する。
【００３１】
またこれとは別に、イベントマネージャ２Ｄ、３Ｄ及びサービスレジストリ２Ｅ、３Ｅにより配送されたメッセージを、メッセンジャ２Ｃ、３Ｃを介して受け取ることにより、機器内外、ネットワーク４上に外部機器より送出されたメッセージを取得する。
【００３２】
このようなメッセージの配送は、機器内の登録済みの配送先については、イベントマネージャ２Ｄ、３Ｄ自身の機能により、機器外の不特定多数の配送先については、イベントマネージャ２Ｄ、３Ｄがブロードキャストマネージャ２Ｆ、３Ｆを利用して実行される。またネットワーク４を介して受信したブロードキャストによるメッセージの場合、イベントマネージャ２Ｄ、３Ｄにより登録済みの配送先への１対１通信により配送される。
【００３３】
これによりオブジェクト２Ａ〜３Ｂは、イベントマネージャ２Ｄ、３Ｄ及びサービスレジストリ２Ｅ、３Ｅとの間の１対１の通信により、種々のメッセージを機器内外に通知できるようになされている。また機器内外に関わらず、送信先が１つの通常通信においては、メッセンジャ２Ｃ、３Ｃが処理し、機器外の特定機器が宛先の場合にも、このメッセンジャ２Ｃ、３Ｃが処理する。
【００３４】
さらにテレビジョン受像器２及びビデオテープレコーダ３は、サービスレジストリ２Ｅ、３Ｅ、属性情報保持手段である属性データベース（attribute database）２Ｇ、３Ｇ及びクイリデータベース（query database）２Ｈ、３Ｈをそれぞれ有している。
【００３５】
属性データベース２Ｇ、３Ｇは、各機器２、３のオブジェクト２Ａ〜３Ｂの属性情報を保持し、サービスレジストリ２Ｅ、３Ｅの制御の下に属性情報の読み出し及び書き込みが行われる。
【００３６】
クイリデータベース２Ｈ、３Ｈは、例えば検索等の照会に係る情報を保持し、サービスレジストリ２Ｅ、３Ｅの制御の下にこのような情報の読み出し及び書き込みが行われる。
【００３７】
サービスレジストリ２Ｅ、３Ｅは、各機器２、３のオブジェクトの属性情報を登録・管理している。そして、これらテレビジョン受像器２及びビデオテープレコーダ３の内部及び外部から、メッセンジャ２Ｃ、３Ｃを介して与えられる照会に対して、属性データベース２Ｇ、３Ｇ及びクイリデータベース２Ｈ、３Ｈを利用して応答する。
【００３８】
また、テレビジョン受像器２及びビデオテープレコーダ３には、機器内のオブジェクトが使用中であるかどうかを監視し、不必要な電力消費を抑えるための処理をするサービスモジュールとしてパワーマネージャ（power manager）２Ｊ、３Ｊが備えられている。このパワーマネージャ２Ｊ、３Ｊは、メッセンジャ２Ｃ、３Ｃを介してイベントを通知されることにより状態を知らされ、所定の場合には電源のオン／オフを切り換え制御する。
【００３９】
続いて、テレビジョン受像器２及びビデオテープレコーダ３における電源の制御の一例について説明する。
【００４０】
テレビジョン受像器２及びビデオテープレコーダ３のサービスレジストリ２Ｅ、３Ｅは、制御対象であるオブジェクトを構成するサービスモジュールの属性情報を属性データベース２Ｇ、３Ｇに保持し、これら電子機器の内部及び外部からの照会に応答している。例えば、検索に対しては、検索条件に合致するサービスモジュールの存在を確認して応答する。
【００４１】
テレビジョン受像器２又はビデオテープレコーダ３が電源をオフにする際には、サービスレジストリ２Ｅ、３Ｅは、属性データベース２Ｇ、３Ｇの保持するこの電子機器の備えるサービスモジュールの属性情報を他の電子機器のサービスレジストリに送り、属性情報ついての照会に対する応答を委託し、その後にパワーマネージャ２Ｊ、３Ｊが電源をオフにする。また、電源をオフとせずに、各機器２、３を制御するＣＰＵを停止状態とすることもある。
【００４２】
例えば、テレビジョン受像器２が電源をオフにする際には、サービスレジストリ２Ｅは属性データベース２Ｇの有するテレビジョン受像器２のサービスモジュールの属性情報を、例えばビデオテープレコーダ３のサービスレジストリ３Ｅに送出する。
【００４３】
テレビジョン受像器２の属性データベース２Ｇに保持されている属性情報をメッセンジャ２Ｃ及び伝送モジュール２Ｉを介して、ネットワーク４に送出する。このようにテレビジョン受像器２からネットワーク４に送出された属性情報は、ビデオテープレコーダ３の伝送モジュール３Ｉ及びメッセンジャ３Ｃを介してサービスレジストリ３Ｅに到達する。
【００４４】
そして、テレビジョン受像器２は、ビデオテープレコーダ３のサービスレジストリ３Ｅに、送出した属性情報についての照会に対する応答を委託した後にパワーマネージャ２Ｊにより電源をオフに制御する。または、テレビジョン受像器２は、電源をオフにする代わりにこのテレビジョン受像器２の全体を制御するＣＰＵを停止状態にする。
【００４５】
一方、ビデオテープレコーダ３のサービスレジストリ３Ｅは、テレビジョン受像器２の備えるサービスモジュールの属性情報についての照会があった場合には、テレビジョン受像器２のサービスレジストリ２Ｅに代わって応答する。そして、照会があったサービスモジュールがテレビジョン受像器２に該当する場合には、例えばこのテレビジョン受像器２のモニタ部が該当する場合には、テレビジョン受像器２の電源をオン状態にする。あるいは、ＣＰＵが停止状態にある場合には、ＣＰＵを動作状態にする。
【００４６】
以上のようにして、テレビジョン受像器２及びビデオテープレコーダ３のサービスレジストリ２Ｅ、３Ｅは、電源をオフにする、あるいはＣＰＵを停止状態にする際に、サービスモジュールの属性情報に対する照会に対する応答を他の電子機器に託す。
【００４７】
このことにより、テレビジョン受像器２又はビデオテープレコーダ３の電源がオフの状態、あるいはＣＰＵが停止状態にあっても、応答を委託した他の電子機器が属性情報に対する照会に代わって応ずる。したがって、照会に対して応答可能な分散協調動作を維持しつつ消費電力の低減を図ることができる。
【００４８】
続いて、テレビジョン受像器２及びビデオテープレコーダ３における電源制御の他の例について説明する。
【００４９】
テレビジョン受像器２及びビデオテープレコーダ３のサービスレジストリ２Ｅ、３Ｅは、サービスモジュールの属性情報を保持し、これらの電子機器の内部及び外部の電子機器から、例えば検索のような照会があった場合には、この照会に応答している。
【００５０】
テレビジョン受像器２及びビデオテープレコーダ３のサービスレジストリ２Ｅ、３Ｅは、他の電子機器のサービスレジストリに委託された場合には、自己の備えるサービスモジュールの属性情報と共に上記他の電子機器のサービスモジュールの属性情報も併せて属性データベース２Ｇ、３Ｇに保持し、属性情報の照会に対しては内部のサービスモジュールの属性情報のみならず上記他の電子機器のサービスモジュールの属性情報についての照会に対しても応答する。
【００５１】
すなわち、テレビジョン受像器２及びビデオテープレコーダ３は、他の電子機器のサービスレジストリから委託を受け、上記他の電子機器の属性情報データベースから属性情報を送られた場合には、上記他の電子機器の属性情報を属性データベース２Ｇ、３Ｇに保持する。そして、テレビジョン受像器２及びビデオテープレコーダ３のサービスレジストリ２Ｅ、３Ｅは、属性情報についての照会があった場合には属性データベース２Ｇ、３Ｇを参照して応答する。
【００５２】
テレビジョン受像器２及びビデオテープレコーダ３は、上記他の電子機器が属性情報についての照会に対する応答を委託してから電源をオフにした、あるいはＣＰＵを停止状態にした場合には、上記他の電子機器に係る属性情報について代わって応答する。そして、属性情報についての照会が上記他の電子機器に該当する場合には上記他の電子機器の電源をオンに制御する。あるいは停止状態にあるＣＰＵを動作状態にする。
【００５３】
例えば、テレビジョン受像器２のサービスレジストリ２Ｅは、例えばビデオテープレコーダ３のサービスレジストリ３Ｅからビデオテープレコーダ３の属性データベース３Ｇの有するビデオテープレコーダ３の備えるサービスモジュールの属性情報を送られてビデオテープレコーダ３の属性情報に対する応答を委託された場合には、この属性情報を属性データベース３Ｇに記録する。
【００５４】
そして、テレビジョン受像器２のサービスレジストリ２Ｅは、属性情報について照会があったときには、属性データベース２Ｇを参照することにより内部のサービスモジュールに対する属性情報についての照会のみならずビデオテープレコーダ３のサービスモジュールの属性情報についての照会にも応答する。
【００５５】
さらに、ビデオテープレコーダ３の電源がオフ状態にある、あるいはＣＰＵが停止状態にある場合には、属性情報についての照会がビデオテープレコーダ３に該当する場合には、例えばビデオテープレコーダ３の磁気記録再生部を検索している場合には、ビデオテープレコーダ３の電源をオン状態とし、あるいは停止状態にあるＣＰＵを動作状態にする。
【００５６】
このように、テレビジョン受像器２及びビデオテープレコーダ３は、他の電子機器のサービスレジストリから属性情報を送られてその属性情報に対する照会への回答を委託された場合には、この属性情報を属性情報データベース２Ｇ、３Ｇに記録し、上記他の電子機器の属性情報についての照会があった場合には、上記たの電子機器のサービスレジストリに代わってその照会に応答する。
【００５７】
上記他の電子機器は、属性情報に対する照会への応答をテレビジョン受像器２又はビデオテープレコーダ３に委託してから電源をオフにすることにより、あるいはＣＰＵを停止状態にすることにより、当該電子機器の電源がオフ状態、あるいはＣＰＵが停止状態にあっても、ネットワーク４を介しての属性情報に対する照会に応答することができる。
【００５８】
したがって、上記他の電子機器においては、外部からの照会に応答することが可能な分散協調動作状態を維持しつつ消費電力の低減が図られている。上記他の電子機器は、検索の対象に該当する場合には検索があった時点で電源がオンに制御される。
【００５９】
以上述べたように、テレビジョン受像器２及びビデオテープレコーダ３のようなノードとしての機能を有する電子機器は、単数又は複数のオブジェクトのサービスモジュールの属性情報を保持する属性データベースと、この属性データベースを管理し、上記属性データベースの保持する属性情報を他の電子機器の備えるサービスレジストリに送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にするサービスレジストリとを有している。
【００６０】
また、テレビジョン受像器２及びビデオテープレコーダ３等の電子機器は、単数又は複数のオブジェクトの属性情報を保持し、他の電子機器から委託された場合には上記他の電子機器のオブジェクトのサービスモジュールの属性情報をも併せて保持する属性データベースと、上記属性データベースを管理して上記属性データベースの保持する属性情報について、上記他の電子機器から委託された場合には上記他の電子機器のオブジェクトのサービスモジュールの属性情報についても、外部からの照会に応答するサービスレジストリとを有するものである。
【００６１】
次に、電源制御方法に係る一連の工程について、図２及び図３に示すフローチャートを参照して説明する。
【００６２】
このフローチャートに示される工程は、テレビジョン受像器のサービスレジストリが他の電子機器のサービスレジストリに、テレビジョン受像器に代わって検索処理を行う代行を委託する際の処理手順を示すものである。
【００６３】
ここでは、テレビジョン受像機内のサービスモジュールが稼働中でないこと、また、ユーザレベルでのソフトウェアモジュールが稼働していないことを前提とする。
【００６４】
この一連の工程は、テレビジョン受像器のサービスレジストリが、電源の停止状態の一具体例としての電源遮断準備のメッセージを受け取ることから開始される。すなわち、テレビジョン受像器のサービスレジストリが電源遮断準備のメッセージをパワーマネージャから受けることによりこの一連の工程が開始される。この電源切断準備のメッセージは、サービスレジストリが検索に対する代行をする契機となるものである。
【００６５】
最初のステップＳ７１においては、テレビジョン受像器のサービスレジストリが現在他ノードの電子機器の検索代行を行っているかどうかを確認する。
【００６６】
他の電子機器の検索代行についての情報を保存しておくデータベースのデータ構造は、例えば図４のようなものになる。図中には、横方向に左から右に順に、“ノードＩＤ”、“属性情報のデータベースＩＤ”、“属性情報のバイト数”の列が並んでいる。図中の縦方向には、最初の行にはノードＩＤ“ＢＢ”、属性情報のデータベース“データベースＢ”、属性情報のバイト数“サイズＢ”が表示されている。これに続く行の表示は省略されている。この検索を行う属性情報に関するデータベースは、サービスレジストリの管理の下に、例えばクイリデータベースに保持される。
【００６７】
このデータベースの内容を確認することにより、テレビジョン受像器のサービスレジストリが他の電子機器の代行をしているか否かを確認する。そして、テレビジョン受像器のサービスレジストリが他の電子機器のサービスレジストリの代行をしている場合には“ＹＥＳ”としてステップＳ７２に進み、そうでない場合には“ＮＯ”としてステップＳ７３に進む。
【００６８】
ステップＳ７２においては、上記図４に示したデータベースにエントリが存在すればその先頭のものから他の電子機器に代行を委託、すなわち再依頼する必要があるので、第１エントリのノードＩＤ“ＢＢ”の属性情報の代理依頼の対象とする。すなわち、このターゲットノードをＢＢとする。そして、ステップＳ７４に進む。
【００６９】
ステップＳ７３においては、上記図４に示したデータベースにエントリが存在しないのでテレビジョン受像器の自己の属性情報だけを依頼すればよい。そこで、テレビジョン受像器のサービスレジストリは、自ノードのノードＩＤの属性情報を代理依頼の対象とする。そして、ステップＳ７４に進む。例えば、自ノードのノードＩＤを“ＡＡ”とすると、ターゲットノードをＡＡに設定することになる。そして、ステップＳ７４に進む。
【００７０】
ステップＳ７４においては、検索代行依頼をする属性情報のサイズと属するノードＩＤとをパラメータに含めて、検索代行依頼のメッセージを不特定の機器に対して発信するブロードキャストを行う。そして、ステップＳ７５に進む。なお、このブロードキャストについては後に説明する。
【００７１】
ここで、属性情報のサイズを知らせるのは、他のノードが検索代行を引き受ける場合にそのノードのＲＡＭ領域などに必要な属性情報を保存する余裕があるかどうかを判断するためである。
【００７２】
検索代行依頼のメッセージは、図５に示すようになる。すなわち、図中には、左から右に順に、“センダ（sender）ＩＤ”、“代行依頼識別ＩＤ”及び“代行依頼内容”の３個の行が表され、さらに“代行依頼内容”の欄は、“属性情報サイズ”及び“所属ノードＩＤ”の欄から構成されている。そして、センダＩＤ“ＸＸＸＸＸＸＸＸ”、代行依頼識別ＩＤ“２３４５”、属性情報サイズ“サイズＢ”、所属ノードＩＤ“ＢＢ”が、それぞれ表示されている。
【００７３】
ステップＳ７５においては、所定時間にわたって他のノードからの返事を待つために待機する。すなわち、上記ステップＳ７４にてブロードキャストしたメッセージに対する他のノードからの応答を受け付ける。そして、次のステップＳ７６に進む。
【００７４】
ステップＳ７６においては、上記ステップＳ７５において他のノードから応答があったか否かによって分岐する。他のノードのサービスレジストリは、検索の代行をすることができない場合には応答しないので、何らかの応答があればそのサービスレジストリは代行を引き受ける用意があるということになる。返事があった場合には“ＹＥＳ”としてステップＳ７８に進み、返事がなかった場合には“ＮＯ”としてステップＳ７７に進む。
【００７５】
なお、応答の際のパラメータとして属性情報を送る必要があるか否かを示すフラグが含まれることが変形例として考えられる。ノードによっては複数のノードに検索代行依頼を行っており、その場合にはデータを送る必要がないからである。
【００７６】
また、変形例としては、ステップＳ７６で属性情報が不要であるという応答があった場合には改めて検索依頼を行う必要はない。既に検索依頼を受けていることになるからである。
【００７７】
ステップＳ７７においては、所定の時間内に返事がなかった場合であり、検索代行を依頼する相手がいないことになるので依頼処理は失敗したことになる。この場合には、テレビジョン受像器のサービスレジストリは、検索に対して応答する必要があるので、ＣＰＵを止めるわけには行かない旨をパワーマネージャに伝える。そして、ステップＳ８２に進む。なお、図２中の“▲２▼”は、図３中の“▲２▼”に手順がつながることを意味している。
【００７８】
ステップＳ７８においては、上記ステップＳ７６で応答があったサービスレジストリに対して検索依頼を行うことになる。この際に送る属性情報は、所属するノードＩＤとそのノードのサービスモジュールに関して現在持っている全属性情報である。そして、ステップＳ７９に進む。なお、図２中の“▲１▼”は、図３中の“▲１▼”に手順がつながることを意味している。
【００７９】
ステップＳ７９においては、テレビジョン受像器のサービスレジストリが現在処理したのは自分が代行しているノードに関するものであるという条件にしたがって分岐する。そして、現在処理したのは自分が代行しているノードに関するものであるときには“ＹＥＳ”としてステップＳ８０に進み、そうでない場合には“ＮＯ”としてステップＳ８１に進む。
【００８０】
このステップＳ７９においては、ここではステップＳ７４からステップＳ７８までの処理の対象がどのノードに係るものであるかの確認を対象となるノードを保持する変数であるターゲットノード（targetNode）の値を調べることにより行う。
【００８１】
ステップＳ８０においては、処理対象が自ノードの属性情報でなかった場合には代行依頼を受けていたノードに対して再依頼したことになり、既に代行する必要はなくなっているので、上記図４に示した検索を行う属性情報に関するデータベースから、対応するノードＩＤのエントリを削除する。その後ステップＳ７１に戻り必要な依頼がすべて終わるか依頼できなくなるまで処理を繰り返す。ここで、自分が代行している全てのノードを終えると、ステップＳ７３における自ノードに関する検索代行要求の工程に進むことになる。なお、図３中の“▲３▼”は、図２中の“▲３▼”に手順がつながることを意味している。
【００８２】
一方、ステップＳ８１においては、処理対象が自ノードの属性情報だった場合には全ての属性情報に対して依頼が終了したことになる。すなわち、検索代行依頼は成功したことになる。そして、次のステップＳ８２に進む。
【００８３】
ステップＳ８２においては、テレビジョン受像器のサービスレジストリは、パワーマネージャに対して処理の成功又は失敗を通知する。処理が成功した場合には、パワーマネージャは電源を停止状態に制御するが、処理が失敗した場合にはＣＰＵは稼働している必要があるので電源はオン状態に保たれる。
【００８４】
そして、このステップＳ８２にてこの一連の工程を終了し、次のメッセージの処理に移る。
【００８５】
続いて、代理検索を受けているサービスレジストリの検索依頼受信時の一連の手順を、図６に示すフローチャートを参照して説明する。ここでは、テレビジョン受像器のサービスレジストリが、ビデオテープレコーダのサービスレジストリから、ビデオテープレコーダのオブジェクトであるサービスモジュールの属性情報を送られ、この属性情報についての応答を委託された場合を例示する。
【００８６】
ビデオテープレコーダのサービスレジストリに代わって検索代行を引き受けたテレビジョン受像器のサービスレジストリは、自己のデータベース以外の属性情報データベースを有することになる。したがって、テレビジョン受像器のノードのみの検索の場合に加えて検索処理手順に幾分変更が必要になり、データベースに対する検索処理はデータベースの数だけ繰り返す必要がある。
【００８７】
さらに、テレビジョン受像器のサービスレジストリは、依頼されているデータベースに該当するものが含まれている場合には、該当するノードに電源投入のメッセージを送る必要がある。
【００８８】
この一連の工程は、テレビジョン受像器のサービスレジストリが、自己のノードの属性情報のデータベースを検索することにより開始される。
【００８９】
最初のステップＳ９１においては、上記図４に示した検索を行う検索情報に関するデータベースのエントリの数を確認する。ここでは、このデータベースにおいて、テレビジョン受像器に検索代行を依頼しているノードＩＤ“ＢＢ”等のエントリの数をＮとする。そして、次のステップＳ９２に進む。
【００９０】
ステップＳ９２においては、検索代行を依頼されているデータベースの数Ｎのうちで検索が終了したデータベースの数ｉを０に設定する。すなわち、ｉ＝０と初期設定する。そして、次のステップＳ９３に進む。
【００９１】
ステップＳ９３においては、処理していない属性情報データベースが有るかどうか確認する。すなわち、検索処理が終了したデータベースの数ｉが検索を依頼されているデータベースの数Ｎより小さいという条件、ｉ＜Ｎによって分岐する。この条件を満たす場合には、未処理のデータベースが存在するので“ＹＥＳ”としてステップＳ９４に進む。この条件を満足しない場合には全て処理済であるので“ＮＯ”として検索結果のリストのＩＤを検索依頼元に通知し、この一連の工程を終了する。
【００９２】
ステップＳ９４においては、上記図４に示したデータベースのエントリの内で現在の第ｉ番目のデータベースの次のデータベース、すなわち第ｉ＋１番目のエントリのデータベースの属性情報データベースの中を検索する。そして、次のステップＳ９５に進む。
【００９３】
ステップＳ９５においては、上記ステップＳ９４において、該当するサービスモジュールが存在するという条件によって分岐する。そして、この条件を満たす場合にはステップＳ９６に進む、この条件を満たさない場合にはステップＳ９８に進む。
【００９４】
ステップＳ９６においては、ステップＳ９４における該当するサービスモジュールをリストに追加する。この際、ステップＳ９４の結果は別ノードでのサービスモジュールＩＤであるので、変換が必要となる。そして、次のステップＳ９７に進む。
【００９５】
ステップＳ９７においては、検索に該当したことで、当該サービスモジュールが通信を受ける可能性が発生したので、テレビジョン受像器のサービスレジストリは、該当するノードに電源投入のメッセージを送る。そして、次のステップＳ９８に進む。
【００９６】
電源投入に成功すれば、上記ノードは自ら検索を受けることができるようになり、検索代行を依頼する必要がなくなるので、テレビジョン受像器のサービスレジストリは、上記図４に示した検索を行う属性情報に関するデータベースから当該ノードのエントリを削除し、さらに属性情報データベースも削除する。
【００９７】
なお、この段階では上記該当したノードが通信を受けるかどうかはわからず、直ぐに検索代行の再依頼を受ける可能性があるので、検索を依頼されているデータベース削除を行わない変形例が挙げられる。
【００９８】
ステップＳ９８においては、処理済のデータベースの数ｉをインクリメントする。すなわち、ｉ＝ｉ＋１と設定する。そして、ステップＳ９３に戻る。
【００９９】
ここで、変形例としては複数のノードに属するサービスモジュールを一つのメッセージで通知できるように図７に示すような形式に変更することもできる。
【０１００】
図中では、左から右に順に“検索識別ＩＤ”、“ノード数”、“ノードＩＤ”、及び複数の“該当モジュール数”の列を有している。そして、最初の行には、検索識別ＩＤ“１２３４”、ノード数“２”、ノードＩＤ“ＢＢ”、該当モジュール数“ｎ”、該当モジュールＩＤ“Ｂ１”，・・・，該当モジュールＩＤ“Ｂｎ”が表示されている。次の行には、ノードＩＤ“ＣＣ”、該当モジュール数“ｍ”、該当モジュールＩＤ“Ｃ１”，・・・，該当モジュールＩＤ“Ｃｍ”が、表示されている。
【０１０１】
このメッセージの形式を利用することにより、複数のノードに属するサービスモジュールに対して、一つのメッセージにて検索結果を通知することができる。
【０１０２】
続いて、電源制御方法の変形例について、図８に示すフローチャートを参照して説明する。
【０１０３】
他のノードからの検索結果を受け取った時点でサービスレジストリが他のノードの宛先のプロキシ（proxy ）を作成する実装では、リストを使わなくなった時がプロキシを削除する適切なタイミングの候補であるので、通信が終了するまでサービスレジストリに対してリストが不要になった旨を通知する処理を行わないことにすることが考えられる。
【０１０４】
しかし、不必要にリストを保持してることはメモリの無駄であり、また、新しく他のノードからの検索結果が返ってきたときにリストの更新処理や、リスト変更のイベント処理などを行わなければならない。
【０１０５】
これらの無駄を避けるために、リストとが不要になったことを通知した際にプロキシを削除して良いか否かの判断材料として、実際に通信を行う予定の相手をサービスレジストリに通知してからリストとが不要になったことを通知し、全ての通信が終わった後に通信が終了したことを通知する実装が考えられる。
【０１０６】
この場合にはリストに含まれている宛先に対して通信を行う代わりに、通信相手をリストに含まれている宛先から選択し、その通信相手をサービスレジストリに通信するようにすることができる。
【０１０７】
この場合には、リスト全体が必要な工程と、リストに含まれていたいくつかの宛先が必要な工程に分けることができる。この実装では通信する予定であることが知らされていない宛先のプロキシはリストが不要になった際に削除し、通信予定が知らされている宛先のプロキシは通信が終了したことを通知した際に削除されることになる。通信予定の宛先の個数には制限はない。
【０１０８】
この一連の工程は、ネットワーク中の他のサービスモジュールとの通信が必要になることにより開始される。
【０１０９】
最初のステップＳ１０１においては、同一ノードのサービスレジストリに対して検索要求のメッセージを送り、次のステップＳ１０２においてはサービスレジストリからの検索結果を待ち、これに続くステップＳ１０３においては、サービスレジストリの検索結果を含むリストのＩＤを受け取る。そして、次のステップＳ１０４に進む。
【０１１０】
ステップＳ１０４においては、リストに含まれている宛先の数が０であるという条件によって分岐する。すなわち、リストに含まれている宛先の数が０の場合には“ＹＥＳ”としてステップＳ１０７に進み、そうでない場合には“ＮＯ”としてステップＳ１０５に進む。
【０１１１】
ステップＳ１０５においては、通信相手をリストに含まれている宛先から選択する。次のステップＳ１０６においては、通信相手をサービスレジストリに通知する。そして、これに続くステップＳ１０７に進む。
【０１１２】
ステップＳ１０７においては、サービスレジストリに対して、リストが不必要になったことを通知する。そして、次のステップＳ１０８においては通信相手との通信が必要な処理を行い、これに続くステップＳ１０９においては通信が終了したことをサービスレジストリに通知する。そして、この通信が必要な処理に係る一連の工程を終了する。
【０１１３】
以上のような手順により、実際に通信を行う相手をサービスレジストリに通知することにより、作業の効率化を図っている。
【０１１４】
続いて、電源制御方法の具体例として、ビデオテープレコーダにおいて、再生ボタンの押圧というイベントに発生により開始される一連の工程について、図９及び図１０に示すフローチャートを参照して説明する。
【０１１５】
この具体例においては、単純な例として家の中の各ＡＶ機器がデジタルネットワークに接続されており、データの配信などは全てソフトウェアで操作できる状態を考える。このネットワークには、テレビジョン受像器及びビデオテープレコーダが接続されている。
【０１１６】
この一連の工程は、ネットワークに接続する機器のサービスモジュール間の通信が必要になる一例であり、ユーザがビデオテープをビデオテープレコーダに挿入し、再生ボタンを押圧することにより開始されるものである。すなわち、この一連の工程は、ビデオテープレコーダの再生ボタンの押圧というイベントの発生により開始される。
【０１１７】
最初のステップＳ１１１においては、ネットワーク内でサービスモジュールタイプがディスプレイの構成要素を含む機器を検索する。そして、これに続くステップＳ１１２に進む。
【０１１８】
ステップＳ１１２においては、処理が終了したデータベースの数を表す変数Ｉが０に設定される。そして、次のステップＳ１１３に進む。
【０１１９】
ステップＳ１１３においては、処理していない検索結果があるという条件によって分岐する。すなわち、処理すべきデータベースの数をＮとすると、Ｎ＞Ｉを満たす場合には処理していない検索結果が残っているので“ＹＥＳ”としてステップＳ１１４に進み、この条件を満足しない場合には検索処理を終了したので“ＮＯ”としてステップＳ１２２に進む。なお、図９中の“▲２▼”は、図１０中の“▲２▼”に手順がつながることを意味している。
【０１２０】
ステップＳ１１４においては、未処理の最初の要素について処理を行う。ここれ、処理を行ったデータベースの数はＩであるので、未処理の最初のデータベースである第Ｉ＋１番目のデータベースについて処理を行う。そして、このデータベースの処理が終わると、処理の終わったデータベースの数を表す変数であるＩをインクリメントしてＩ＝Ｉ＋１とする。そして、ステップＳ１１５に進む。
【０１２１】
ステップＳ１１５においては、ディスプレイが使用中であるという条件によって分岐する。すなわち、この条件を満足する場合には“ＹＥＳ”としてステップＳ１１３に戻り、この条件を満足しない場合には“ＮＯ”として次のステップＳ１１６に進む。
【０１２２】
ステップＳ１１６においては、ディスプレイに使用要求を出し、ステップＳ１１７に進む。
【０１２３】
ステップＳ１１７においては、ステップＳ１１６におけるディスプレイに対する使用要求が受け入れられたか否かによって分岐する。すなわち、上記要求が受け入れられた場合には“ＹＥＳ”としてステップＳ１１８に進み、この要求が受け入れられなかったときには“ＮＯ”として上記ステップＳ１１３に戻る。
【０１２４】
ステップＳ１１８においては、ディスプレイを含む機器がスピーカを含むか否かによって分岐する。すなわち、ディスプレイを含む機器がスピーカを含む場合には“ＹＥＳ”としてステップＳ１２０に進み、その機器がスピーカを含まない場合には“ＮＯ”としてステップＳ１１２に進む。ここで、図９中の“▲１▼”は、図１０中の“▲１▼”に手順がつながることを示している。
【０１２５】
ステップＳ１２０においては、スピーカの使用要求を出し、次のステップＳ１２１に進む。
【０１２６】
ステップＳ１２１においては、上記ステップＳ１２０の要求が受け入れられたか否かによって分岐する。すなわち、スピーカの使用要求が受け入れられたときには“ＹＥＳ”としてこの一連の工程を終了する。スピーカの使用要求が受け入れられなかったときには“ＮＯ”としてステップＳ１２２に進む。
【０１２７】
ステップＳ１２２においては、ネットワーク内でサービスモジュールタイプがスピーカの構成要素を含む機器を検索する。そして、次のステップＳ１２３に進む。
【０１２８】
ステップＳ１２３においては、検索が終了したデータベースの数を表す変数Ｉを０に設定する。そして、これに続くステップＳ１２４に進む。
【０１２９】
ステップ１２４においては、処理していない検索結果があるか否かによって分岐する。処理すべきデータベースの数Ｎとすると、処理していない検索結果があるとき、すなわちＮ＞Ｉを満足するときには“ＹＥＳ”としてステップＳ１２５に進み、検索を終了してＮ＞Ｉを満足しないときには“ＮＯ”としてこの一連の処理を終了する。
【０１３０】
ステップＳ１２５においては、データベースの最初の要素について処理を行う。すなわち、処理が終了した数を表す変数Ｉの次の第Ｉ＋１番目のデータベースについて処理が行われる。この処理が終了すると、上記変数はＩ＝Ｉ＋１とインクリメントされる。そして、これに続くステップＳ１２６に進む。
【０１３１】
ステップＳ１２６においては、スピーカが使用中であるという条件によって分岐する。スピーカが使用中であるときには“ＹＥＳ”として上記ステップＳ１２４に戻り、使用中でないときには“ＮＯ”として次のステップＳ１２７に進む。
【０１３２】
ステップＳ１２７においては、スピーカに使用要求を出し、ステップＳ１２８に進む。
【０１３３】
ステップＳ１２８においては、ステップＳ１２７にてスピーカ出した使用要求が受け入れられたか否かによって分岐する。すなわち、上記要求が受け入れられた場合には“ＹＥＳ”としてステップＳ１２９に進み、使用要求が受け入れられなかった場合には“ＮＯ”として上記ステップＳ１２４に戻る。
【０１３４】
ステップＳ１２９においては、再生を開始し映像信号をディスプレイに、音声信号をスピーカに送る。そして、この一連の工程を終了する。
【０１３５】
ここで、上記Ｓ１１３やＳ１２４において未処理の検索結果がない場合には、エラーが発生したことを示して処理を中断することも考えられる。この場合エラーメッセージの表示先としてはビデオテープレコーダの備える液晶パネルやエラーランプ等の表示装置だけではなく、ネットワーク制御用の端末に表示することの考えられる。
【０１３６】
アナログの通信線での直接の接続を含む場合には、その部分の制御を行うソフトウェアモジュールを作成し、ユーザが接続情報を入力することにより対応することができる。このためには入力装置と表示装置とを備えた機器がネットワーク中に含まれていることが必要となる。
【０１３７】
以上述べたように、電源制御方法は、単数又は複数のオブジェクトのサービスモジュールの属性情報を取得する属性情報取得工程と、この属性情報取得工程にて取得した属性情報を他の電子機器の備えるサービスレジストリに送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理工程とを有している。
【０１３８】
また、電源制御方法は、単数又は複数のオブジェクトのサービスモジュールの属性情報を取得し、他の電子機器から委託された場合には上記他の電子機器のオブジェクトのサービスモジュールの属性情報をも併せて取得する属性情報取得工程と、上記属性情報取得工程にて取得した属性情報について、上記他の電子機器から委託された場合には上記他の電子機器のオブジェクトのサービスモジュールの属性情報についても、外部からの照会に応答する属性情報管理工程とを有するものである。
【０１３９】
次に、電子機器の備えるサービスレジストリ及びサービスモジュールにおける通信について説明する。
電子機器の備える各サービスモジュールは、メッセージを送ることによって処理依頼等の協調動作を実現する構成である。
【０１４０】
ここで、サービスモジュール間の情報伝達の手段としては、メッセージキューを用いた１対１の通信と、送り手側は特定の聞き手を意識しないイベントを用いた通信が各ノード内で供給されているものとする。
【０１４１】
ここでいうサービスモジュールとは、ある機能を実現するための装置だけでなく、メモリに格納されＣＰＵで実行されるプログラムも含む。
【０１４２】
サービスモジュールがプログラムの場合には、全体の実行手段を示したものではなく、各機能を実現するためのサービスモジュール毎の動作を記述したオブジェクト指向的なモデルを用いて説明する。同一ＣＰＵ上のタイムシェアリングや複数ＣＰＵを使った並列処理や分散処理などが行われている場合にはサービスモジュールの処理は並列実行されているものとみなす。
【０１４３】
各ノードの電子機器には一般に複数のサービスモジュールが備えられ、複数ノードがネットワークにて接続されているが本発明の想定している状況である。
【０１４４】
まず、基本となるノードに電源が入っている状態での検索の手順を示す。ある特定の機能もしくは属性を持つサービスモジュールと通信を行いたいサービスモジュールは同一ノード内のサービスレジストリに対して検索要求のメッセージを送る。
【０１４５】
検索要求を受けたサービスレジストリは管理しているサービスモジュールに関する情報を利用して検索に該当するものが自分と同じノード内に存在するかどうかのチェックをする。同時にノード内からの検索を受けたサービスレジストリはブロードキャストマネージャに依頼して検索要求をネットワーク全体に流す。
【０１４６】
ネットワークからの検索要求のブロードキャストメッセージを受けた各ノードのブロードキャストマネージャはそれぞれのノード内のサービスレジストリに検索要求を配送する。ノード外からの検索要求を受けたサービスレジストリは、ノード内からの検索を受けた場合と同様に管理している情報を利用して検索に該当するものが自分と同じノード内に存在するかどうかのチェックをする。ノード外からの検索要求に該当するものが自ノード内に存在した場合には、検索要求元のサービスレジストリに対して結果を通知する。
【０１４７】
ノード内からの検索要求を受けたサービスレジストリは、ネットワークを介して他のサービスレジストリからの結果を待ちながら、自分自身の検索結果を基にしたリストを作成し、他のサービスレジストリからの結果が返ってきた場合には順次リストに追加する。ノード内からの検索要求を受けたサービスレジストリは自分自身の検索結果を作成後、指定された時間が経過した後に検索要求リストのＩＤを知らせる。この指定された時間は、０のことも有り得る。
【０１４８】
検索要求元はサービスレジストリから返ってきたリストの内容を確認し、そこに含まれているサービスレジストリのメールボックスに対して通信を行うことによって処理依頼等を行う。検索要求元にとって知らされたリストが不要となった時点で、もう使わないことを示すメッセージをサービスレジストリに送り、サービスレジストリは該当するリストを削除し、それ以降に他のノードから返ってくるそのリストに対する検索結果は捨てることになる。
【０１４９】
リストＩＤを検索要求元に知らせた後、削除する前に他のノードからの検索結果がサービスレジストリに返ってきた場合には、該当するリストの内容を追加し、リスト内容が更新されたことを示すイベントを発生させることにより、検索元がイベントをチェックしていれば対応が可能になる。
【０１５０】
続いて、各サービスモジュールごとの処理をフローチャートを参照して説明する。
【０１５１】
基本的な流れとして、最初にサービスレジストリを利用するサービスモジュールの処理、次にサービスモジュールからの検索要求を受けたサービスレジストリの処理を示し、最後に他のノードのサービスレジストリからの検索要求を受けたサービスレジストリの処理を示す。
【０１５２】
その後、他のノードのサービスレジストリに転送した検索結果が返ってきた時のサービスレジストリの対応と、サービスレジストリからの結果を処理中に検索結果に追加があった場合のサービスモジュールの処理方法、検索結果が不用になった際の処理を示してから、他のノードのサービスレジストリの代理依頼に関して説明する。
【０１５３】
まず、他のサービスモジュールとの通信を行うためにサービスレジストリを使う際の一連の工程を、図１１に示すフローチャートを参照して説明する。
【０１５４】
この一連の工程は、ネットワーク中の他のサービスモジュールとの通信が必要になることから開始される。すなわち、このネットワーク中に特定の機能を有するサービスモジュール、もしくは特定の機能を提供するソフトウエアモジュールを利用する必要が生じると開始される。
【０１５５】
最初のステップＳ１１においては、同一ノードのサービスレジストリに対して検索要求のメッセージを送る。すなわち、同一のノード内のサービスレジストリに対して、通信を行いたい相手の種別や属性情報、位置情報等を含む検索要求を送る。そして、次のステップＳ１２に進む。
【０１５６】
ステップＳ１２においては、サービスレジストリからの検索結果が返ってくるまで待機する。並列処理が行える環境であれば、検索結果を待つ間にそれとは関係のない処理を行ってもよい。そして、ステップＳ１３に進む。
【０１５７】
ステップＳ１３においては、サービスレジストリの検索結果を含む例えばリスト番号のようなリストのＩＤを受け取る。オブジェクト指向的なモデルを使用すれば、ここで受け取るのはリストを表現するオブジェクトと通信を行う際の宛先であり、検索結果である検索要求に合致する通信相手と通信を行うための宛先や要求を満たす通信相手の数はリストとの通信によって得ることになる。ただし、実装上は通信相手の宛先を含む配列データのメモリ上のアドレス等の直接的なデータを受け取ることも考えられる。そして、次のステップＳ１４に進む。
【０１５８】
ステップＳ１４においては、リストに含まれている宛先の数を確認する。すなわちリストに含まれている宛先の数が０であるという条件によって分岐する。この宛先の数が０の場合には必要とする通信相手がいないことがわかるので、“ＹＥＳ”としてサービスレジストリに対してリストが不用になったことを通知するステップＳ１６に進み通信相手がいない場合の処理に移る。そうでない場合には“ＮＯ”として次のステップＳ１５に進む。
【０１５９】
ステップＳ１５においては、リストに含まれている宛先の数が０以外であるので、そのリスト中の宛先と通信を行う。例えば、家の中のＡＶ機器のネットワーク上で、ビデオテープレコーダが表示先のディスプレイを探していた場合であれば、検索結果の中から使用されていないものを一つ選択するまで通信を行うことになるし、テレビがチャンネルリストを表示しようとしているのであれば、利用可能な全てのチューナに対して通信を行うことになる。いずれにせよ、リストをどのように利用するかは検索元の自由であり、サービスレジストリは関知しない。そして、次のステップＳ１６に進む。
【０１６０】
ステップＳ１６においては、サービスレジストリに対してリストが不用になったことを通知する。この時に不要なリストを特定するための識別情報として上記ステップＳ１５で、サービスレジストリから受け取ったものを利用する。サービスレジストリはこの情報により検索要求を特定し、必要な処理を行う。そして、この通信が必要な処理に係る一連の工程を終了する。
【０１６１】
なお、この一連の処理は必ずしも通信相手との通信が全て終わった後である必要はない。例えばステップＳ１６においてビデオテープレコーダがディスプレイを探している例では使用中でないディスプレイを見つける処理が終了すれば、その後は検索結果であるディスプレイのリストは不要なので、その時点でこの処理を行っても問題ない。
【０１６２】
続いて、上記ステップＳ１１で送られた検索依頼を受けたサービスレジストリに係る一連の工程について、図１２に示すフローチャートを参照して説明する。この一連の工程は、同一ノード内のサービスモジュールからの検索依頼を受け付けることから開始される。
【０１６３】
最初のステップＳ２１においては、ブロードキャストマネージャを利用して他ノードのサービスレジストリに検索要求を送る。すなわち、受け付けた検索要求を他のノードのサービスレジストリに対してブロードキャストするために、ブロードキャストマネージャに依頼する。これは通常のサービスモジュールがネットワークを意識する必要がないようにするためのモデルであり、ブロードキャストマネージャとサービスレジストリの双方の機能を兼ねるサービスモジュールとして実装することもできる。
【０１６４】
この際ブロードキャストする内容としては、検索要求の他にブロードキャストのヘッダとして、ブロードキャスト元のノードを特定するＩＤとサービスレジストリ宛ての検索要求であることを示すＩＤ、返事をする際に対応する検索要求を特定するための検索識別ＩＤが含まれる。そして、次のステップＳ２２に進む。
【０１６５】
ステップＳ２２においては、検索元に結果を特定するためのリスト等のＩＤを用意する。このＩＤに対応して、配列等のデータ構造を作成することになる。
【０１６６】
後にステップＳ２１で送った検索要求に対するノードから返ってきた際にこのデータ構造に追加する必要があるため、ステップＳ２１で送った検索識別ＩＤとここで用意したデータ構造のＩＤとの対応関係を記録しておく。そして、ステップＳ２３に進む。
【０１６７】
ここで、ＩＤは実装する際のプログラム言語やＯＳに依存するが、オブジェクトＩＤやメモリのアドレス、サービスレジストリが管理するＩＤ等を用いることになる。
【０１６８】
ステップＳ２３においては、自ノードのサービスモジュールに関してのデータベースである属性データベースを検索し、検索要求に合うサービスモジュールのＩＤをステップＳ２２で用意したデータ構造に追加する。この段階では検索結果は同一ノード内に存在するサービスモジュールだけからなる。そして、ステップＳ２４に進む。
【０１６９】
ステップＳ２４においては、検索元にステップＳ２２で用意したＩＤを通知する。このＩＤは同一ノード内でのみ参照されるので、どのような形式のものであってもノード内でのみ整合性が取れていればよい。そして、サービスモジュールからの検索依頼に対する処理を行うこの一連の工程を終了し、次のメッセージの処理に移る。
【０１７０】
実際には一連の検索処理としてはステップＳ２１においてブロードキャストした検索に対する応答が返ってきた段階で更に処理を行うことになるが、それは別のメッセージに対する処理として扱う。
【０１７１】
続いて、上記ステップＳ２１でブロードキャストされた他のノードからのサービスレジストリからの検索要求を受けたサービスレジストリについての一連の工程を、図１３に示すフローチャートを参照して説明をする。
【０１７２】
この一連の工程は、基本的には上述した自ノードのサービスモジュールからの検索依頼を受けたときの処理と同じであるが、上記ステップＳ２１におけるブロードキャストを行わないことと、検索結果をノード間通信で伝えるためにリストのＩＤだけでなく内容まで通知する点が異なる。
【０１７３】
この一連の工程は、他のノードのサービスレジストリからの検索要求を受け付けることから開始される。最初のステップＳ３１においては、検索元に返す情報を格納するためのデータ構造としてリストや配列などを用意する。
【０１７４】
ステップＳ３１においては、検索要求元に返すリストを作成する。これに続くステップＳ３２においては、自ノードのサービスモジュールに関してデータベースを検索し、検索要求に合うサービスモジュールのＩＤをステップＳ３１で用意したデータ構造に追加する。検索結果は同一ノード内に存在するサービスモジュールだけからなる。そして、ステップＳ３３に進む。
【０１７５】
ステップＳ３３においては、元のノードにステップＳ３２で検索した結果であるサービスモジュールのＩＤのリストを通知する。上述の場合と違い、ステップＳ３２で用意したデータ構造全体を示すものではなく、リストに含まれる個々の要素と要素の個数を通知する。結果を通知する際には、検索結果の他にどの検索要求に対するものかを示すための検索識別ＩＤも同時に通知する。
【０１７６】
ここで内容を全て通知するのは後にノード間通信を行って要素の確認を行ったりすることを省略するためであり、リストが不要になったときに破棄するタイミングをノード内で判断できるようにするためでもある。なお、変形例としてはデータ構造のＩＤだけを通知することも考えられる。
【０１７７】
しかし、上記ステップＳ２４でデータ構造のＩＤだけを通知したのは、後に他のノードからの検索結果が図中の処理の結果として返ってきて内容が追加されたときに、変化があったことを知らせるためのＩＤとしてであるが、このステップＳ３３で通知するのはあくまでもこのノード分の結果であり、後に変更する必要がないので、内容を通知しても何の問題もない。
【０１７８】
いずれにせよ、ここで通知するサービスモジュールのＩＤは別のノードで処理されるため、ネットワーク内でビット数が規定されている必要がある。これは各ノードで任意のＩＤを用いることができた上述の場合との大きな違いとなる。
【０１７９】
ステップＳ３４においては、ステップＳ３１で作成しステップＳ３２で要素を追加したデータ構造はもはや不要であるので破棄する。なお、ステップＳ３４の変形例としてデータ構造のＩＤだけを通知する場合には、この処理はこの時点では行えず、リスト破棄要求のメッセージを受けた際に行うことになるが、利用中にノードがネットワークから切断されたような場合に無駄なデータを破棄するための追加処理が必要になる。
【０１８０】
このステップＳ３４において、他ノードのサービスレジストリからの検索要求に対する一連の工程を終了し、次のメッセージの処理に移る。
【０１８１】
続いて、上記ステップＳ３３において通知した検索結果を受け取ったサービスレジストリにおける一連の工程を、図１４に示すフローチャートを参照して説明する。
【０１８２】
この一連の工程は、他ノードのサービスレジストリからの検索結果のメッセージを受信することから開始される。このメッセージには上記ステップＳ２１にてブロードキャストする際に付加しておいた検索識別ＩＤと、検索内容に合致するサービスレジストリのＩＤのリストや個数が含まれている。
【０１８３】
最初のステップＳ４１においては、上記図１２中のステップＳ２２で用意しておいた記録を用い、検索識別ＩＤに対応するデータ構造のＩＤを特定し、それが使用中であるかを確認する。ここで使用中というのは、上記図１１中のステップＳ１６のリスト不要通知を受けていないことを意味する。
【０１８４】
検索識別ＩＤに対応するリストが使用中の場合には、“ＹＥＳ”としてステップＳ４２以降の処理を行うが、既にリスト不要通知を受けている場合には他ノードの検索結果も不要なので“ＮＯ”としてこの一連の工程を終了する。
【０１８５】
ステップＳ４２においては、ステップＳ４１で確認したデータ構造に対し、受け取った検索結果に含まれるサービスモジュールのＩＤリストを追加する。そして、次のステップＳ４３に進む。
【０１８６】
ステップＳ４３においては、イベントマネージャに対してデータ構造の内容に変更が生じたことを示すイベントを通知することにより、そのデータ構造に関心を持っているサービスモジュールが処理を行うための機会を提供する。このイベントのパラメータとしてはステップＳ４２で変更したデータ構造のＩＤが含まれる。これにて、この一連の工程を終了し、次のメッセージの処理に移る。
【０１８７】
なお、ステップＳ４３においてはイベントマネージャを利用したが、サービスレジストリ自体が検索元のデータを記録しておき１対１通信によって通知するような変形例も可能である。
【０１８８】
また、検索結果の要素数が０の場合には変化は生じていないので、ステップＳ４３の通知は行う必要がないのでその確認を行うことも考えられる。ただし、要素数の変化があったかどうかは利用側で確認することも可能であるし、要素数０の場合にはそもそも検索結果を通知しない変形例も考えられ、その場合には確認は必須ではないので上記フローチャートには含めていない。
【０１８９】
さらに、上記図１３中のステップＳ３２とステップＳ３３の間に所定の時間だけ他ノードからの返事を待ち、一度検索元に検索結果を通知した後は追加処理は行わないという変形例も考えられる。この場合ステップＳ４１における使用中とは返答待ち期間中のことになり、ステップＳ４３は不要になる。
【０１９０】
ステップＳ４３により、検索結果に変更があった場合に検索依頼元が行う処理は多様であり、状況によって異なるのでフローチャートとして示すことはできない。例えば、先に言及したように使用中でないディスプレイを探すのが目的であれば既に見付けている場合には何の処理も必要ないし、見つかっていない場合には追加されたものに対するチェックを行うことになる。また、全てのチューナーが提供できるチャンネル一覧を表示するのが目的であれば追加されたチューナーのチャンネル情報を得るべく通信することになる。
【０１９１】
続いて、検索結果変更のイベントを受けた際の検索依頼元についての一連の工程を、図１５に示すフローチャートを参照して説明する。
【０１９２】
この一連の工程は、検索結果変更のイベント通知を受けることにより開始される。すなわち、上記図１４中のステップＳ４３でサービスレジストリがイベントマネージャを利用した結果としてイベント通知を受ける。もしくはサービスレジストリから直接メッセージで通知される。
【０１９３】
イベントマネージャを使用する実装の場合には、この通知を受けるためには上記図１１中のステップＳ１４までにイベントマネージャに検索結果変更イベントに対して興味があることを知らせておく必要がある。
【０１９４】
最初のステップＳ５１においては、変更のあったデータ構造のＩＤが自分の使用中のものかどうかを確認する。これは主にイベント通知の場合にはイベントの種類だけで判断され、関係のないものに関しても通知される可能性があるからである。サービスレジストリから直接通知される場合でもミスを避けるために確認して損はないが必須ではない。
【０１９５】
そして、データ構造のＩＤが使用中のものであるときには“ＹＥＳ”としてステップＳ５２に進み、そうでないときには“ＮＯ”としてこの一連の工程を終了して次のメッセージの処理に移る。
【０１９６】
ステップＳ５２においては、上述の通り、状況に応じて必要な処理がなされる。そして、この一連の工程を終了し、次のメッセージの処理に移る。
【０１９７】
続いて、上記図１１中のステップＳ１６におけるリストの不要通知を受信したサービスレジストリについての一連の工程を、図１６に示すフローチャートを参照して説明する。
【０１９８】
この一連の工程は、上記ステップＳ１６で検索依頼元が送ったリスト不要通知をサービスレジストリが受け取ることにより開始される。上記リストには、メッセージのパラメータとしてリストとを特定するためのＩＤが含まれている。
【０１９９】
最初のステップＳ６１においては、リストのＩＤに対して不使用であることを示す情報を記憶する。これは他のノードのサービスレジストリからの検索結果がいつ返ってくるか分からない状況においてステップＳ４１での判断に使われることになる。ここで、情報の記憶の仕方としては例えばＩＤに対して不使用フラグを立てることが考えられる。そして、次のステップＳ６２に進む。
【０２００】
ステップＳ６２においては、リスト自体を破棄する。変形例としてはリストを破棄することはせず、複数のリストをプールしておき再利用することが考えられる。この場合には同一のオブジェクトＩＤやメモリのアドレスを再利用するため、リストのＩＤはサービスレジストリが管理するものになり、ここではリストの内容を空にする処理が行われる。そして、この一連の処理を終了し、次のメッセージの処理に移行する。
【０２０１】
変形例としてはＩＤに対応するリストが存在しない場合には不使用と判断することによってステップＳ６１を省略し、ステップＳ６２だけを行うことが考えられる。
【０２０２】
次に、通信路上で検索要求等のメッセージのデータ形式や、各サービスレジストリが扱うデータ形式について説明をする。様々な変形例が考えられるが基本的に必要な情報の一例を示す。
【０２０３】
単純な例として属性名と属性として任意の文字列を持つ形で各サービスモジュール情報を持ち、図１７の形式で属性情報を保持する場合において、複数の属性を一つのサービスモジュールに対して与えたい場合には複数のエントリを持つことになる。
【０２０４】
このサービスレジストリの持つサービスモジュールのデータベースの第１の例においては、図中横方向には、左から右に順に“モジュールＩＤ”、“属性名”及び“属性”の３つの列を有し、図中縦方向には、モジュールＩＤ“１”に対して属性名“モジュールタイプ”及び属性“ブロードキャストマネージャ”が、モジュールＩＤ“２”に対して属性名“モジュールタイプ”及び属性“イベントマネージャ”が、モジュールＩＤ“４”に対して属性名“モジュールタイプ”及び属性“ネットワークマネージャ”が、モジュールＩＤ“１１”に対しては属性名“モジュールタイプ”及び属性“ディスプレイ”がそれぞれ対応して表示されている。
【０２０５】
ここでモジュールＩＤとは、ノード内での識別に使われるものであり、メッセージの宛先としても使われることになる。
【０２０６】
予め幾つかの属性を持つことを仮定して、例えばタイプや表示するための名前は必ず持ち、任意個数の追加属性を持ってもよい場合であれば図１８のような形式になる。
【０２０７】
このサービスレジストリの持つサービスモジュールのデータベースの第２の例には、左から右に、順に“モジュールＩＤ”、“モジュールタイプ”、“モジュールネーム”、“属性数”、“属性数１”及び“属性１”の６個の列を有し、図中縦方向には、モジュールＩＤ“１”に対してモジュールタイプ“１”、モジュールネーム“ブロードキャストマネージャ”及び属性数“０”が、モジュールＩＤ“２”に対してモジュールタイプ“２”、モジュールネーム“イベントマネージャ”及び属性数“０”が、モジュールＩＤ“４”に対してモジュールタイプ“３”、モジュールネーム“ネットワークメッセンジャ”及び属性数“０”が、モジュールＩＤ“１１”に対してモジュールタイプ“１００”、モジュールネーム“Ｄ−００１”、属性数“１”、属性名１“サイズ”及び属性１“２１”がそれぞれ対応して表示されている。
【０２０８】
この場合、持つことが決まっている属性に対して予め数字に意味を割り振ることにより、文字列を記憶するのに比べ記憶領域を減らすことも考えられる。図中においては、モジュールタイプに関して例えば“１００”がディスプレイを示すことにより上記図１１の場合と同様の情報を少ないバイト数で保持していることになる。
【０２０９】
この例ではディスプレイである“Ｄ−００１”は１個の追加属性を持ちそれは“サイズ”であるが、他のサービスモジュールは追加属性は持っていない。仮に“Ｄ−００１”が“ｂ／ｗ”か“カラー”かを示す“カラー”という属性も持つとすれば、属性数は“２”になることになる。
【０２１０】
このようにあるタイプのサービスモジュールに関しては、図１９に示すように、一般的な属性に対しても予め属性タイプを数値で定義しておくことによって記憶領域を更に減らす変形例も考えられる。
【０２１１】
このサービスレジストリが持つサービスモジュールのデータベースの第３の例においては、左から右に、順に“モジュールＩＤ”、“モジュールタイプ”、“モジュールネーム”、“属性数”、“属性タイプ”、“属性名”及び“属性”の７個の列を有し、図中の縦方向には、モジュールＩＤ“１”に対してモジュールタイプ“１”、モジュールネーム“ブロードキャストマネージャ”及び属性数“０”が、モジュールＩＤ“２”に対してモジュールタイプ“２”、モジュールネーム“イベントマネージャ”及び属性数“０”が、モジュールＩＤ“４”に対してモジュールタイプ“３”、モジュールネーム“ネットワークメッセンジャ”及び属性数“０”が、モジュールＩＤ“１１”に対してモジュールタイプ“１００”、モジュールネーム“Ｄ−００１”、属性数“３”、属性名タイプ“１０１”及び属性“２１”が、次の行には属性タイプ“１０２”及び属性“カラー”が、その次の行には属性タイプ“０”、属性名“サウンド”及び属性“ステレオ”がそれぞれ表示されている。
【０２１２】
図中においては、属性タイプが“０”の場合には未定義のタイプであり、属性名で区別する必要がある例を示している。この例においては属性タイプの“１０１”は、サイズを意味し、“１０２”はカラーを意味している。モジュールタイプの“１００”は図１２と同様にディスプレイを意味している。複数の追加属性を持つモジュラーの場合には続く属性数の後に可変長の属性データが続くことになる。
【０２１３】
この例では属性自体は全て文字列になっているが、属性タイプとして文字列以外の数値データであることを示すようなフラグを付加することによって属性として数値、例えば、整数、浮動小数点、ブーリアン、列挙型等をとることもできるようにする変形例も考えられる。
【０２１４】
上記図１２のフローチャートの入り口となる検索依頼メッセージのデータ形式はサービスレジストリの持つデータベースとどの程度複雑な検索を指定できるようにするかで変わってくるが、例えば上記図１７のデータベースに対して単純な検索だけを行う場合には図２０のようになる。
【０２１５】
図中には、横方向に左から右に“検索属性名”及び“検索属性”の２つの列を有し、それぞれに対応して、検索属性名“モジュールタイプ”及び検査属性“ディスプレイ”がそれぞれ表示されている。
【０２１６】
この場合の文字列の表現形式はノード内部の処理系によって異なって構わない。例えば、先頭にバイト数を示すパスカル形式や文字列の終端を示すデータを付加するＣやＣ＋＋形式等がある。
【０２１７】
上記図１７に示したサービスモジュールのデータベースの第１の例においては、属性名と属性は常に文字列であることがわかっているのでこのような検索依頼にて十分であるが、上記図１８に示した第２の例又は図１９に示した第３の例のように、デは文字列以外のデータが含まれていることもある。したがって検索依頼自体にその情報が含まれている必要がある。
【０２１８】
そこで、文字列以外の情報を含む検索依頼のメッセージのデータ形式を、図２１に示す。図中には、左から右に“検索属性タイプ”、“検索属性名”及び“検索属性”の３個の列を有し、これらに対応して、“検索属性タイプ“１０１”及び検索属性“２１”がそれぞれ示されている。なお、検索属性名に対応する欄は空欄になっている。
【０２１９】
ここで、検索属性では上記図１９に示したデータベース内の属性ＩＤと同じものである。検索属性名は同図の例であれば検索属性タイプが０の場合のみ指定されることになる。
【０２２０】
またデータベースの例としては図示していない検索属性に文字列以外のものを許すような変形例の場合には、検索属性が文字列なのか数字なのかを示すための属性タイプ情報を追加する必要がある。各データ型を示す数値を予め割り当てておくのが効率的であるが、拡張性を考慮して文字列を使うような変形例も有り得る。
【０２２１】
検索依頼の変形例としては、ＡＮＤ，ＯＲ，ＮＯＴのような論理演算を含む複雑な検索を行えるようにすること、特定のノード内のみ、指定したグループに属するノード内のみ等の検索範囲を指定した検索を行えるようにすること等があるが、ここでの説明は省略する。
【０２２２】
上記図１２に示した一連の工程において、Ｓ２１の前のステップでサービスモジュールから検索依頼を受けたサービスレジストリが図１９に示したようなデータベースを持っていた場合に、ステップＳ２２で作られる検索結果は例えば図２２のようになる。
【０２２３】
すなわち、この検索結果リストは、図中の左から右に、順に“該当モジュール数”、“該当モジュールＩＤ１”の列を有している。そして、図中には、該当モジュール数“１”及び該当モジュールＩＤ“１１”がそれぞれ示されている。なお、該当モジュールＩＤの欄は、複数個あってもよい。
【０２２４】
ステップＳ２４で検索依頼元に通知されるのはこの検索結果全体を示す、例えば“２０１”のようなリストのＩＤだけであり、検索に該当したサービスモジュールである“１１”ではない。
【０２２５】
一方、ステップＳ２２で他のノードのサービスレジストリにブロードキャストするメッセージは図２３のようになる。
【０２２６】
図中には、左から右に、順に“センダ（sender）ＩＤ”、“検索識別”、“検索内容”の欄を有し、さらに上記“検索内容”の欄は、“検索属性ＩＤ”、“検索属性名”及び“検索属性”の欄を有している。そして、センダＩＤ“ＸＸＸＸＸＸＸＸ”、検索識別ＩＤ“１２３４”、検索属性ＩＤ“１０１”及び検索属性“２１”がそれぞれ表示されている。
【０２２７】
この図に示したのはブロードキャストマネージャにブロードキャストするように依頼する内容であり、ネットワークに流れるときにはにはブロードキャストマネージャがヘッダを付加することになる。上述したように、このヘッダには送信元のノードＩＤやブロードキャストＩＤ等が含まれている。
【０２２８】
ブロードキャストに対して結果を送り返す際にノードＩＤとノード内でのモジュールＩＤが必要になるので、ノード内でのサービスレジストリのモジュールＩＤであるセンダＩＤが図中に含まれている。
【０２２９】
図中のメッセージに対する応答が返ってきた時点で検索識別ＩＤに応じてどのリストに対して処理をすればいいのかを覚えていく必要がある（上記図１４中のステップＳ４１で参照される）が、そのためのデータは例えば図２４のようになる。
【０２３０】
すなわち、図中には、左から右に、順に“検索識別ＩＤ”、“検索結果のリストＩＤ”及び“不要通知”の３個の欄を有し、検索識別ＩＤ“１２３４”に対して検索結果のリストＩＤ“２０１”及び不要通知“０（ＦＡＬＳＥ）”がそれぞれ表されている。
【０２３１】
新しい検索識別ＩＤに対するエントリはステップＳ２１をブロードキャスト依頼した時点で用意され、ステップＳ２２で用意される検索結果のＩＤが記憶されることになる。
【０２３２】
上記図１４の処理が始まる前にデータベースが更新されていればいいので、実際にエントリーを追加するタイミングは図１２に示したフローチャートの中であれば何処でもよい。
【０２３３】
ただし、サービスレジストリ相互の通信の処理に関しては高い優先度を持たせるような変形例の場合には、上記図１２中でステップＳ２１でブロードキャストを依頼する前にステップＳ２２を実行し、データベースの更新を終了しておくことが誤動作を防ぐ上では重要になる。
【０２３４】
上記図２３のメッセージを受け取ったサービスレジストリの処理は上記図１３に示してある取りであり、内部的に作成する検索結果は上記図２２と同様である。ここで出てくる新しいデータ形式としては、上記図１３中のステップＳ３３で送る検索結果がリスト全体を示すＩＤではなく、内容を含むものであるために通信線を流れる図２５に示す形式のものがある。
【０２３５】
同図のメッセージはブロードキャストではなく、１対１の通信としてブロードキャスト元のノードのサービスレジストリ宛てに送られる。例えばノードＩＤ“ＡＡ”のブロードキャスト元のモジュールＩＤ“ＸＸＸＸＸＸＸＸ”のサービスレジストリ宛てに送られる。
【０２３６】
この結果に含まれている“Ｂ１”から“Ｂｎ”までのモジュールＩＤはサービスモジュールが属しているノード“ＢＢ”の中でのモジュールＩＤであり、それ以外のノードにとっては意味は分からない只の数字であるが、ノード“ＢＢ”宛てのメッセージのヘッダにノード内部での宛先として指定しておくことにより、ノード“ＢＢ”のメッセンジャがメッセージの本体をそのサービスモジュールに届けることが保証されている。
【０２３７】
これはサービスレジストリがブロードキャストする際に返答先としてノード内のモジュールＩＤとして指定していた“ＸＸＸＸＸＸＸＸ”に関しても同様で他のノードは“ＸＸＸＸＸＸＸＸ”が何を意味するかを知る必要はない。
【０２３８】
ただし、ネットワークに接続されている全てのノードが同様に扱う必要があるので、このモジュールＩＤのビット長だけは例えば６４ｂｉｔ等に規定しておく必要がある。
【０２３９】
このネットワーク中でのモジュールＩＤとノード内部で使っているモジュールＩＤのサイズが異なる場合には、サービスレジストリは外部に対して知らせた宛先としてのＩＤと内部でのモジュールＩＤの対応を記録したデータベースを管理し、他のノードからのメッセージの配送の際にはメッセンジャーが参照する必要があるが、単純な対応関係を示したデータベースでもあるし、本論から外れるので説明は省略する。
【０２４０】
同図のメッセージを受けた結果元々の検索依頼を受けたノード“ＡＡ”のサービスレジストリは上記図１４中のステップＳ４２において、自己のノード内の検索結果である上記図２２にｎ個のモジュールＩＤを追加して、図２６のように変更することになる。
【０２４１】
図中には、左から右に、順に“該当モジュール数”、“該当モジュールＩＤ１”、“該当モジュールＩＤ２”、・・・、“該当モジュールＩＤｎ＋１”のｎ＋２個の欄を有し、該当モジュール数“２１”、該当モジュールＩＤ１“１１”、該当モジュールＩＤ２“Ｂ１´”、・・・、該当モジュールＩＤｎ＋１“Ｂｎ´”がそれぞれ示されている。
【０２４２】
ここで、図中においては、“Ｂ１”から“Ｂｎ”ではなく、“Ｂ１′”から“Ｂｎ′”になっている理由は各ノード内でのモジュールＩＤの使い方は任意であるため、ノード“ＢＢ”でのＩＤはそのままではノード“ＡＡ”では別のサービスモジュールを指示してしまうからである。
【０２４３】
この“Ｂｉ”から“Ｂｉ′”へのもっとも単純な変換はネットワーク中での通信に使われるモジュールＩＤの前にノードＩＤを連結したものをノード内部でのモジュールＩＤとして使い、自ノードの場合にはノードＩＤとして使うことによって内部のサービスモジュールと外部のサービスモジュールを区別して扱うことである。この場合は図２７に示すような関係になる。
【０２４４】
図中においては、左から右に、順に“ノードＡＡでのモジュールＩＤ”、“ノードＩＤ”及び“サービスモジュールの所属するノードでのモジュールＩＤ”の３個の列をそれぞれ有し、ノードＡＡでのモジュールＩＤ“１１”に対しては、ノードＩＤ“０”及びサービスモジュールの所属するノードでのモジュールＩＤ“１１”、ノードＡＡでのモジュールＩＤ“Ｂ１´”に対してはノードＩＤ“ＢＢ”及びサービスモジュールの所属するノードでのモジュールＩＤ“Ｂ１”が、ノードＡＡでのモジュールＩＤ“Ｂｎ´”に対してはノードＩＤ“ＢＢ”及びサービスモジュールの所属するノードでのモジュールＩＤ“Ｂｎ”がそれぞれ表示されている。この図は、Ｂｉ´＝ＢＢ＊（位取り）＋Ｂｉであることを示すものである。
【０２４５】
しかしこれでは内部での自然なモジュールＩＤと外部のサービスモジュールを含む場合のモジュールＩＤの扱いが異なり、内部のサービスモジュールに対しても余分な記憶領域を使用しなければならない。
【０２４６】
これを解決する変形例としては、例えば内部のサービスモジュールとしては１００００未満のみを用い、それ以上のモジュールＩＤは外部のサービスモジュールを示すということにして、サービスレジストリが、自ノードのサービスモジュールの属性データベース、検索識別ＩＤに関するデータベースに続く第３番目のデータベースとして内部での自然な長さのモジュールＩＤと外部のモジュールＩＤ及び所属するノードＩＤの情報を管理する方法がある。
【０２４７】
この場合のデータベースは図の対応関係とほぼ同じになるが、自ノードに所属するサービスモジュールに関するエントリは必要ないし、モジュールＩＤとしてはノードにとって自然な長さのものが使える点が違う。図２８にこのようなデータベースの例を示す。
【０２４８】
図中には、左から右に“ノードＡＡでのモジュールＩＤ”、“所属するノードＩＤ”及び“所属するノードでのモジュールＩＤ”の３個の列を有し、ノードＡＡでのモジュールＩＤ“Ｂ１´（＝１０００１）”に対して所属するノードＩＤ“ＢＢ”及び所属するノードでのモジュールＩＤ“Ｂ１”、ノードＡＡでのモジュールＩＤ“Ｂｎ´（＝１００００＋ｎ）”に対して所属するノードＩＤ“ＢＢ”及び所属するノードでのモジュールＩＤ“Ｂｎ”がそれぞれ示されている。
【０２４９】
メッセンジャがメッセージを配送する際には最初に宛先のモジュールＩＤが概定値（例えば１００００）以上であるかどうかを確認し、それ未満であればそのままノード内部のサービスモジュールに配送し、それ以上であればサービスレジストリに実際のモジュールＩＤと所属するノードＩＤを問い合わせた上で宛先のノードのメッセンジャと協力して配送することになる。
【０２５０】
上記図１４中のステップ４３のイベントのパラメータは検索検索のＩＤだけであるので、図２２から図２６に変わった場合であれば、図２９のようになる。
【０２５１】
図中には、左から右に“イベントタイプ”及び“パラメータ”の欄を有し、このパラメータの欄には“検索結果のＩＤ”が示されている。そして、イベントタイプ“サーチリザルトアップデート（SearchResultUpdate）”に対して検索結果のＩＤ“２０１”が表示されている。
【０２５２】
また、上記図１１中のステップＳ１６にて検索依頼元が送り、図１６中のステップＳ６１の前にサービスレジストリが受けるメッセージのパラメータも検索結果のＩＤだけであるので、一連の例の場合であれば図３０のようになる。
【０２５３】
このメッセージを受けたサービスレジストリは図２４の対応するエントリの不要通知をＴＲＵＥに変更し、ＩＤが２０１である不要になったリストを破棄することになる。
【０２５４】
図２８のデータベースを使用している場合には、この際にリストに含まれている外部のモジュールＩＤに対応するエントリをデータベースから削除することになる。
【０２５５】
以上説明したように各ノードに存在するサービスレジストリは協調作業を行いながら、他のサービスモジュールに対してはネットワークを意識する必要がないようにしている。
【０２５６】
次に、上述したような１対１通信及びブロードキャストによるメッセージのデータの具体的な形式について説明する。
【０２５７】
オブジェクトサービスモジュールからイベントマネージャ及びサービスレジストリに送出するメッセージは、図３１に示すように、宛先、送信元を特定するヘッダと、メッセージの内容を特定するメッセージタイプのデータ、パラメータ長と示すデータ、メッセージに付随するパラメータを示すデータにより構成される。
【０２５８】
オブジェクトは、イベントを通知する場合、宛先のイベントマネージャは、メッセージタイプの部分にイベント通知を割り当て、イベント番号、イベントパラメータによりメッセンジャに依頼する。
【０２５９】
メッセンジャは、機器内のサービスモジュール間における送信先が１つの特定されているメッセージの送受信を管理する。すなわち各メッセンジャは、各サービスモジュールに設定されたＩＤと、ヘッダに設定された宛先のＩＤを基準にして、対応する宛先に各メッセージを通知する。この時メッセンジャは、対応するサービスモジュールが処理中の場合、このサービスモジュールに対する要求が失われないように、メッセージを保持する。
【０２６０】
なお、メッセンジャは、例えば各メッセージを一旦メモリに保持し、又は一連のメッセージの宛先を基準にしてアドレス間でリンクを形成し、このリンクのリストを管理することにより、各メッセージを対応するサービスモジュールに提供する。
【０２６１】
これによりこれらサービスモジュール間におけるメッセージの伝送において、メッセンジャは、いわゆる１対１通信により１の伝送元から送出したメッセージを１の伝送先に送信するようになされている。
【０２６２】
イベントマネージャは、メッセンジャを介して入力されるイベントメッセージを対応する機器内のサービスモジュールに配送し、またブロードキャストマネージャを利用する。
【０２６３】
ここでサービスリストは、各イベントの通知を必要とするオブジェクトのリストであり、メッセンジャを介して通知される所定のメッセージにより更新される。サービスレジストリは、機器内サービスモジュールのリストであり、サービス検索の際にブロードキャストマネージャが利用する。
【０２６４】
このサービスリストは、図３２に示すように、イベントの種類を示すイベント番号と、対応する宛先とを配列して形成される。
【０２６５】
イベントマネージャは、このサービスリストにしたがって、メッセンジャより取得したイベント情報のメッセージを配送する。すなわち、イベントマネージャは、“イベント１”について、“オブジェクト１”及び“オブジェクト２”を宛先にする旨、宛先リストが形成されている場合、通知されたメッセージを形成し、この２つのメッセージをメッセンジャに送信する。
【０２６６】
これに対して“イベント２”に対応する“メッセージ２”については、いずれのサービスモジュールにも配送することなくこのメッセージを処理する。さらにこのときイベントマネージャは、オブジェクトからブロードキャストの依頼があったと判断し、イベントマネージャは、サービスリストに基づいてこのメッセージを配送すると共に、ブロードキャストマネージャにこのメッセージのブロードキャストを依頼する。
【０２６７】
これによりテレビジョン受像器、ビデオテープレコーダでは、１対１通信又は１対多通信により得られる各種イベント情報を対応するサービスモジュールに発送するようになされている。かくするにつきテレビジョン受像器、ビデオテープレコーダでは、機器内においては、１対１通信によりメッセージが配送され、イベントマネージャは、単に複数の宛先に同一のメッセージを送信することになる。
【０２６８】
このようにしてメッセージを配送するにつき、イベントマネージャは、サービスリストに従って、宛先を特定してメッセージを操守する場合、メッセンジャに対してこのメッセージを送出する。メッセンジャは、宛先が機器内か否かを判断し、機器外の不特定多数が宛先のメッセージの場合、ブロードキャストマネージャにメッセージを送出する。
【０２６９】
イベントマネージャは、このようにブロードキャストマネージャ等にメッセージを送出する場合、図３３中のＡに示すようなメッセンジャにより通知されたメッセージの内容を転送する。これによりイベントマネージャは、ブロードキャストマネージャ等からは、同図中のＢに示すように、オブジェクトよりメッセージの通知を受ける場合と同一の形式により、メッセージの通知を受け付ける。
【０２７０】
このようにしてメッセージを配送するにつき、イベントマネージャは、受信したメッセージのメッセージタイプを確認する。さらにイベントマネージャは、メッセージタイプによって、受信したメッセージがオブザーブのメッセージと判断すると、このメッセージの内容に従ってサービスリストを更新する。これによりビデオテープレコーダ等では、ネットワークに新たに機器が接続された場合等において、サービスリストを更新することにより、この増設された機器に対して種々のイベントを通信できるようになされている。
【０２７１】
図３４は、このようなオブザーブの通知に使用されるメッセージのデータ形式を示す図である。なおこの図は、メッセージ部だけについて示す。このオブザーブのメッセージは、機器内外のオブジェクトにより必要に応じて生成され、例えばネットワークへの機器の接続が物理的に検出された場合に、この新たに増設された機器との間で、また既にネットワークに接続されている機器との間で、ネットワークメッセンジャを介して、又はブロードキャストマネージャを介してイベントマネージャに通知される。
【０２７２】
ここでこの一連のメッセージは、上記図３１及び図３３中のＡに示したように、メッセンジャを介してサービスモジュール間で一般に送受されるメッセージに対してパラメータを拡大して形成される。すなわちサービスリストへのオブザーバの登録を求めるメッセージは、図３４中のＡに示すように、メッセージタイプにオブザーバのタイプを示す３２ビットのデータが割り当てられ、通知を求めるイベント番号、通知先を示すオブザーバがパラメータに設定される。これに対して登録を取り消すメッセージは、同図中のＢに示すように、メッセージタイプに取り消しを示すタイプのデータが割り当てられ、取り消しを求めるイベント番号、取り消す通知先を示すオブザーバがパラメータに設定される。
【０２７３】
またイベントマネージャは、サービスリストの更新に伴い、登録、取り消しを求めるサービスモジュールに対して、同様の形式により要求確認を示す応答のメッセージを配送する。またブロードキャストマネージャを介して通知されたメッセンジャや機器内でのイベント通知に対して、同様に応答確認を示す応答のメッセージを配送する。ここでイベント通知を受け取った場合には、サービスレジストリに従ってイベント発生を通知する。このときこの通知は、イベント発生通知であることが、同図中のＣに示すように、続いて可変長によるパラメータ長のデータ、パラメータ長のデータ、パラメータのデータにより構成される。
【０２７４】
メッセンジャは、保持した外部機器ＩＤのリストを検索し、この外部機器ＩＤに従って伝送モジュールを介してネットワークにメッセージを送出する。このときメッセンジャはメッセージをネットワーク上での所定の形式に変換し、このメッセージを伝送モジュールに通知する。
【０２７５】
ここでこの所定の形式は、図３５中のＡ及びＢに示すように、ネットワークに接続された各ノードの機器で処理可能な、これらの機器に共通するパケットの形式であり、例えば同図に示すような形式である。すなわちメッセンジャは、メッセージをメッセージ部に設定し、このメッセージ部にヘッダを付加してパケットを形成する。
【０２７６】
ここでこのヘッダは、送信先でなる目的ノードが例えばＩＰアドレスであれば、ネットワークにより異なるが例えば３２ビットのデータにより記述され、このパケットタイプによって特定対象に送出する送信のパケット、外部機器からの要求に応答して要求を発行した特定対象に発信する応答のパケット、ネットワークに接続された各機器に対する各機器のパケット等を識別できるようになされている。なおブロードキャストによる場合、この種の伝送モジュールに提供するパケットは、ネットワークメッセンジャに替えてブロードキャストマネージャが生成することになる。
【０２７７】
さらにヘッダは、送信のパケットと応答のパケットの対応を特定するためのメッセージＩＤが付加される。さらにヘッダは、目的ノードの内部における識別用のＩＤが３２ビットのデータにより記述され、この目的ＩＤによって目的ノードの機器において、機器内のいずれかのオブジェクトに対する応答かを特定できるようになされている。
【０２７８】
さらにメッセンジャは、伝送モジュールより入力されるパケットを取得し、自己の機器を目的ノードに設定したパケットを選択して、このパケットのメッセージを送出する。これによりメッセンジャは、機器内オブジェクトのメッセージを外部機器に出力し、またこれとは逆に外部機器より通知されたメッセージを機器内オブジェクトに通知する。
【０２７９】
またメッセンジャは、イベントマネージャ及びサービスレジストリと同様に、受信したメッセージによって保持した外部機器ＩＤのリストを更新する。これによりビデオテープレコーダ等においては、増設された機器等に対しても、１対１通信により種々のメッセージを伝送できるようになる。
【０２８０】
ブロードキャストマネージャは、イベントマネージャ及びサービスレジストリよりメッセージを受け、伝送モジュールを介してこのメッセージをネットワークにブロードキャストする。さらにブロードキャストマネージャは、このブロードキャストをしたメッセージに関連する一連のメッセージを伝送モジュールを介してネットワークに送出する。
【０２８１】
またこれとは逆に、ブロードキャストマネージャは、他の機器よりネットワークにブロードキャストされたメッセージ、さらにはブロードキャストに関連するメッセージを伝送モジュールより取得し、イベントマネージャ及びサービスレジストリに通知する。
【０２８２】
次に、テレビジョン受像器、ビデオテープレコーダ等の電子機器に備えられ、これら電子機器の全体を制御するＣＰＵの操作状態について説明する。
【０２８３】
ここで例示するＣＰＵは、消費電力を変更する電力モードとしては、フルスピードモード（Fullspeed Mode）、スタンバイモード（Standby Mode）、サスペンドモード（Suspend Mode）、ハイバーネートモード（Hibernate Mode）の４種類を有するものである。
【０２８４】
フルスピードモードは、通常の動作モードであり、図３６に示すように、全ての内部クロックが設定された周波数で動作する。図中において上から下へ、ＣＰＵに供給されるクロック信号であるマスタークロック（MasterClock）と、ＣＰＵの各部の信号であるマスターアウト（MasterOut）、Ｔクロック（TClock）及びＰクロック（PClock）とのそれぞれの波形を示す。このフルスピードモードにおいては、上記のいずれの信号も動作している。
【０２８５】
ハイバーネートモードにおいては、図３７に示すように、ＣＰＵ内で生成される全てのクロックが全てハイレベルに固定されて停止する。図中では、ＣＰＵに供給されるクロック信号であるマスタークロックを除いたマスターアウト、Ｔクロック及びＰクロックがハイレベルに固定されて停止している。
【０２８６】
なお、図中のリセット（Reset）及びコールドリセット（ColdReset）は、ハイバーネートモードからフルスピードモードへのモード移行のシーケンスを示すものである。
【０２８７】
また、図示しないが、スタンバイモードはタイマ／割り込みクロックを除く内部クロックが全てハイレベルに固定されて停止するモードであり、上記図３６においてはＰクロックがハイレベルに固定される。
【０２８８】
サスペンドモードは、タイマ／割り込みを除く内部クロックとＴクロックが全てハイレベルに固定され、停止するモードであり、上記図３６においてはＴクロック及びＴクロックがハイレベルに固定される。
【０２８９】
このように、このＣＰＵにおいては、所定の内部クロックを停止させることにより消費電力を低減するモードを有している。すなわち、フルスピードモード、スタンバイモード、サスペンドモード及びハイバーネートモードの順に、停止される種類が増加するので、消費電力が削減される。
【０２９０】
したがって、テレビジョン受像器、ビデオテープレコーダ等の電子機器においては、ＣＰＵが通常に動作することが必要であるとき以外にはＣＰＵをフルスピードモード以外の他の電力モードの移行させて待機状態あるいは停止状態とすることにより、消費電力の低減を図ることができる。
【０２９１】
次に、記録媒体について説明する。
記録媒体は、単数又は複数の制御対象の属性情報を取得する属性情報取得手順と、上記属性情報取得手順にて取得した属性情報を他の電子機器に送出して外部からの上記属性情報についての照会に対する応答を委託してから電源を停止状態にする属性情報管理手順とを有するプログラムが記録されたものである。
【０２９２】
また、記録媒体は、単数又は複数の制御対象の属性情報を取得すると共に他の電子機器から委託された場合には上記他の電子機器の制御対象の属性情報をも併せて取得する属性情報取得手順と、上記属性情報取得手順にて取得した属性情報について、上記他の電子機器から委託された場合には上記他の電子機器の制御対象の属性情報についても、外部からの照会に応答する属性情報管理手順とを有するプログラムが記録されたものである。
【０２９３】
この記録媒体は、上記プログラムが記録されたいわゆるＣＤ−ＲＯＭやＭＯとして提供される。また、このプログラムは、通信回線等の媒体を介して供給される。
【０２９４】
以上述べたように、この発明に係る電子機器、電源制御方法及び記録媒体は、、例えばＡＶシステムを構成する各映像機器等に適用することができる。したがって、この発明は、ネットワークに対してメッセージをブロードキャストする情報ブロードキャスト手段と、装置内において、メッセージの配送を担当するイベントマネージャーとを配置することにより、機器内のオブジェクトから見て、機器内外を区別することなく、また特定対象、不特定対象を区別することなくメッセージの送受信をできるようにし、その分伝送に供する情報信号に対してネットワークを充分な時間開放することができるようにする。
【０２９５】
また、外部からの電源投入を意味するメッセージに対応するための方法としては、通常のメッセンジャを動かしておく方法もあるが、ＣＰＵがメッセージ毎に使用のソフトウェアを走らせなくてもよいように通信用のハードウェアで電源投入のメッセージのみを解釈して、ＣＰＵを含む本体部分の電源投入を行うことも考えられる。
【０２９６】
さらに、各ノードが、ノード内のサ−ビスモジュールのリストを管理し、不特定の機器に対するを利用した検索に答えるサービスレジストリを持ち、通常のサービスモジュールは オブジェクトはサービスレジストリを利用して必要なサービスモジュールを見つける構成のＡＶネットワークにおいて、使用中のサービスモジュールを持たない機器の電源を落しても他の機器のサービスモジュールが必要なサービスモジュールを見付けて利用できるように、電源を切る処理中にサービスレジストリが他の機器のサービスレジストリにリストの内容を知らせて検索に対する応答を委任し、委任されたサービスレジストリは検索に対して委任されたリスト中のサービスモジュールが必要になった際に同時に委任元のサービスレジストリを持つノードの電源を入れるようにするものである。
【０２９７】
【発明の効果】
上述のように、この発明に係る電子機器、電源制御方法及び記録媒体においては、他のノードのサービスモジュールに検索に対する応答を委任することによって、ブロードキャストメッセージ処理する必要もなくなり、ＣＰＵも止めることができるので電力消費を押さえることができる。
【０２９８】
また、この発明に係る電子機器、電源制御方法及び記録媒体においては、分散処理をしている場合には通常はサービスモジュールを持つ機器自体が検索に対応することになるので正当性が保証しやすい。さらに、電源を落すために委任している場合であっても、正当性のチェックは電源を落してから電源が入るまでの短時間のプロキシィを委任されているときにだけサービスモジュールを持つ機器のサービスレジストリに対する問い合わせにして検索を転送すればいいので、全体としては正当性のチェックを簡略にすることができる。
【図面の簡単な説明】
【図１】ネットワークに接続された電子機器の概略的な構成を示すブロック図である。
【図２】電源遮断直前の検索代行依頼に係る一連の工程を示すフローチャートである。
【図３】図２に続く工程を示すフローチャートである。
【図４】検索を行う属性情報に関するデータベースを示す図である。
【図５】検索代行依頼のためにサービスレジストリがブロードキャストするメッセージを示す図である。
【図６】代理検索を受けているサービスレジストリの検索依頼に係る一連の工程を示すフローチャートである。
【図７】ブロードキャストの検索要求に対する複数ノードの検索結果を示す図である。
【図８】他のサービスモジュールとの通信を行うためにサービスレジストリを使う変形例の一連の工程を示すフローチャートである。
【図９】ビデオテープレコーダの再生ボタンを押圧した際の一連の工程を示すフローチャートである。
【図１０】図９に続く工程を示すフローチャートである。
【図１１】他のサービスモジュールと通信を行うためにサービスレジストリを使う際の一連の工程を示すフローチャートである。
【図１２】同一モード内のサービスモジュールから検索要求を受け付けた際の一連の工程を示すフローチャートである。
【図１３】他ノードのサービスレジストリからの検索要求受信時の一連の工程を示すフローチャートである。
【図１４】他ノードのサービスレジストリからの検索結果受信時の一連の工程を示すフローチャートである。
【図１５】検索結果変更のイベント受けた際の検索結果依頼もとの一連の工程を示すフローチャートである。
【図１６】検索依頼元のサービスレジストリからのリスト不要通知受信時の一連の工程を示すフローチャートである。
【図１７】サービスレジストリの有するサービスモジュールのデータベースの第１の例を示す図である。
【図１８】サービスレジストリの有するサービスモジュールのデータベースの第２の例を示す図である。
【図１９】サービスレジストリの有するサービスモジュールのデータベースの第３の例を示す図である。
【図２０】サービスモジュールからサービスレジストリへの検索依頼のメッセージの第１の例を示す図である。
【図２１】サービスモジュールからサービスレジストリへの検索依頼のメッセージの第２の例を示す図である。
【図２２】サービスモジュールが作成する検索結果のメッセージの一例を示す図である。
【図２３】サービスレジストリがブロードキャストする検索依頼の転送のメッセージの一例を示す図である。
【図２４】検索識別ＩＤ対してサービスレジストリが保持しているデータベースの一例を示す図である。
【図２５】ブロードキャストの検索要求に対する検索結果のメッセージの一例を示す図である。
【図２６】サービスレジストリが作成する検索結果のメッセージの一例を示す図である。
【図２７】ノードＩＤを付加したモジュールＩＤの一例を示す図である。
【図２８】内部でのモジュールＩＤと外部でのモジュールＩＤとノードＩＤに関するデータベースを示す図である。
【図２９】検索結果不要通知のメッセージを示す図である。
【図３０】検索を行う属性情報に関するデータベースを示す図である。
【図３１】オブジェクトより送出されるメッセージを示す図である。
【図３２】イベントマネージャのサービスリストを示す図である。
【図３３】イベントマネージャよりブロードキャストマネージャに通知されるメッセージを示す図である。
【図３４】サービスリストの登録等に関するメッセージを示す図である。
【図３５】メッセンジャから伝送モジュールに送出するパケットの説明に供する図である。
【図３６】フルスピードモードにおけるＣＰＵの信号のタイミングチャートである。
【図３７】ハイバーネートモードにおけるＣＰＵの信号のタイミングチャートである。
【符号の説明】
２  テレビジョン受像器、３  ビデオテープレコーダ、２Ａ，２Ｂ，３Ａ，３Ｂ  オブジェクト、２Ｃ，３Ｃ  メッセンジャ、２Ｄ，３Ｄ  イベントマネージャ、２Ｅ，３Ｅ  サービスレジストリ、２Ｉ，３Ｉ  伝送モジュール、２Ｊ，３Ｊ  パワーマネージャ
【図１】
0003733709.tif 000002
【図２】
0003733709.tif 000003
【図３】
0003733709.tif 000004
【図４】
0003733709.tif 000005
【図５】
0003733709.tif 000006
【図６】
0003733709.tif 000007
【図７】
0003733709.tif 000008
【図８】
0003733709.tif 000009
【図９】
0003733709.tif 000010
【図１０】
0003733709.tif 000011
【図１１】
0003733709.tif 000012
【図１２】
0003733709.tif 000013
【図１３】
0003733709.tif 000014
【図１４】
0003733709.tif 000015
【図１５】
0003733709.tif 000016
【図１６】
0003733709.tif 000017
【図１７】
0003733709.tif 000018
【図１８】
0003733709.tif 000019
【図１９】
0003733709.tif 000020
【図２０】
0003733709.tif 000021
【図２１】
0003733709.tif 000022
【図２２】
0003733709.tif 000023
【図２３】
0003733709.tif 000024
【図２４】
0003733709.tif 000025
【図２５】
0003733709.tif 000026
【図２６】
0003733709.tif 000027
【図２７】
0003733709.tif 000028
【図２８】
0003733709.tif 000029
【図２９】
0003733709.tif 000030
【図３０】
0003733709.tif 000031
【図３１】
0003733709.tif 000032
【図３２】
0003733709.tif 000033
【図３３】
0003733709.tif 000034
【図３４】
0003733709.tif 000035
【図３５】
0003733709.tif 000036
【図３６】
0003733709.tif 000037
【図３７】
0003733709.tif 000038