JPH11112595A - 電子機器、電源制御方法及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 検索能力を維持しながら消費電力を抑える。 【解決手段】 ノードとしての機能を有する電子機器
２，３は、オブジェクト２Ａ，２Ｂ，３Ａ，３Ｂのサー
ビスモジュールの属性情報を保持する属性データベース
２Ｇ，３Ｇと、この属性データベース２Ｇ，３Ｇの保持
する属性情報を他の電子機器のサービスレジストリに送
出して外部からの上記属性情報についての照会に対する
応答を委託してから電源を停止状態にするサービスレジ
ストリ２Ｅ，３Ｅとを有する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、制御対象の属性
情報を保持してその属性情報に対する照会に応答する電
子機器、制御対象の電源を制御する電源制御方法、及び
制御対象の属性情報に対する照会に応答する一連の処理
手順を記録された記録媒体に関する。

【０００２】

【従来の技術】従来、例えば、テレビジョン受像器、ビ
デオテープレコーダ、チューナ等のＡＶ機器が接続さ
れ、オーディオ信号、映像信号、制御信号その他の情報
信号が伝送されるネットワークが提供されている。この
ネットワークとしては、ネットワークに接続されるＡＶ
機器が分散してそれぞれ動作すると共に、ネットワーク
を介して伝送される情報信号に応じて協調動作するいわ
ゆる分散協調ネットワークがある。

【０００３】分散協調ネットワークにおいては、ノード
としての機能を有する電子機器は、制御対象であるオブ
ジェクトのサービスモジュールの属性情報を管理するサ
ービスレジストリを有し、ネットワークを介して他の機
器のサービスモジュールにもアクセス可能な分散協調動
作をするネットワークを形成する。

【０００４】

【発明が解決しようとする課題】ところで、家庭内のＡ
Ｖネットワークを考えたときに、接続の変化が簡単に起
きる可能性を考慮すれば、他のノードのサービスモジュ
ールに関する情報をサービスレジストリが保持すること
は可能な限り避けたほうが良い。

【０００５】ここでいうＡＶネットワークとは、通常据
え置きで接続の変化はほとんどないであろうテレビジョ
ン受像器等のみならず携帯型のＣＤプレーヤーやビデオ
カメラ等の接続も含む。このようないつ切断されるかわ
からない機器に関する情報を例えば接続時に特定のサー
バに格納することは無駄になる可能性が高いし必要でも
ない。

【０００６】したがって、接続された際に他のサーバを
統括するプロキシサーバ（proxy server）に常に委任す
るという解決法によると、ネットワークへの機器の接続
や切り離しが頻繁に行われるであろう家庭内でのＡＶ機
器のネットワークではプロキシサーバが切り離されるこ
とも十分考えられるので、切断時の処理を行わなければ
ならない。

【０００７】また、接続時に委任する場合には、検索が
あった時点までに接続の変更が行われている可能性があ
るため、プロキシサーバの持つデータの保証がしにくく
使用時に確認が必要であった。

【０００８】しかし、一方で各ノードのサービスレジス
トリが協調作業をする分散協調型のネットワークにおい
ては、このネットワークを流れる検索要求のパケットの
監視と処理を行うために常にＣＰＵと通信周りのサービ
スモジュールは稼動状態にある必要があるので電力を消
費する。

【０００９】すなわち、基本となるネットワーク中の各
ノードのサービスレジストリが分散協調動作をするシス
テムでは、ノード内の全てのサービスモジュールが使わ
れていない場合であっても、サービスレジストリが検索
を処理して答えるために、宛先が特定されずに配信され
るブロードキャストメッセージがある。

【００１０】このため、ＣＰＵは、このブロードキャス
トメッセージを処理するために常に作動している必要の
で、サービスモジュールが使用されていないときにも電
力が消費される。

【００１１】この発明は、上述の実情に鑑みてなされる
ものであって、各ノードのサービスレジストリのＣＰＵ
がブロードキャストメッセージに応答するために常に動
作する必要のないような電子機器、及び電源を制御する
電源制御方法並びにこのような手順が記録された記録媒
体を提供することを目的とする。

【００１２】

【課題を解決するための手段】上述の課題を解決するた
めに、この発明に係る電子機器は、単数又は複数の制御
対象を制御するものであって、上記制御対象の属性情報
を保持する属性情報保持手段と、上記属性情報保持手段
を管理し、上記属性情報保持手段の保持する属性情報を
他の電子機器の備える属性情報管理手段に送出して外部
からの上記属性情報についての照会に対する応答を委託
してから電源を停止状態にする属性情報管理手段とを有
するものである。

【００１３】また、この発明に係る電子機器は、単数又
は複数の制御対象を制御する電子機器であって、上記制
御対象の属性情報を保持し、他の電子機器からの委託に
応じて上記他の電子機器の制御対象の属性情報をも併せ
て保持する属性情報保持手段と、上記属性情報保持手段
を管理して上記属性情報保持手段の保持する属性情報に
ついて、上記他の電子機器からの委託に応じて上記他の
電子機器の制御対象の属性情報についても、外部からの
照会に応答する属性情報管理手段とを有するものであ
る。

【００１４】上述の課題を解決するために、この発明に
係る電源制御方法は、単数又は複数の制御対象の電源を
制御する電源制御方法において、上記制御対象の属性情
報を取得する属性情報取得工程と、上記属性情報取得工
程にて取得した属性情報を管理し、上記属性情報を他の
電子機器に送出して外部からの上記属性情報についての
照会に対する応答を委託してから電源を停止状態にする
属性情報管理工程とを有するものである。

【００１５】また、この発明に係る電源制御方法は、単
数又は複数の制御対象の電源を制御する電源制御方法で
あって、上記制御対象の属性情報を取得し、他の電子機
器からの委託に応じて上記他の電子機器の制御対象の属
性情報をも併せて取得する属性情報取得工程と、上記属
性情報取得工程にて取得した属性情報について、上記他
の電子機器からの委託に応じて上記他の電子機器の制御
対象の属性情報についても、外部からの照会に応答する
属性情報管理工程とを有するものである。

【００１６】上述の課題を解決するために、この発明に
係る記録媒体は、単数又は複数の制御対象の属性情報を
取得する属性情報取得手順と、上記属性情報取得手順に
て取得した属性情報を他の電子機器に送出して外部から
の上記属性情報についての照会に対する応答を委託して
から電源を停止状態にする属性情報管理手順とを有する
プログラムが記録されたものである。

【００１７】また、この発明に係る記録媒体は、単数又
は複数の制御対象の属性情報を取得すると共に他の電子
機器からの委託に応じて上記他の電子機器の制御対象の
属性情報をも併せて取得する属性情報取得手順と、上記
属性情報取得手順にて取得した属性情報について、上記
他の電子機器からの委託に応じて上記他の電子機器の制
御対象の属性情報についても、外部からの照会に応答す
る属性情報管理手順とを有するプログラムが記録された
ものである。

【００１８】

【発明の実施の形態】以下、この発明に係る電子機器、
電源制御方法及び記録媒体について、図面を参照して説
明する。

【００１９】図１は、ノード（node）として機能する電
子機器として、テレビジョン受像器２及びビデオテープ
レコーダ３をネットワーク４にて接続したＡＶシステム
の通信系を示す機能ブロック図である。

【００２０】ここでテレビジョン受像器２及びビデオテ
ープレコーダ３の通信系は、制御対象であるオブジェク
トが異なる点と、このオブジェクトの相違により各機器
において制御手順が異なる点を除いて共通の構成でな
る。したがって、以下の説明において共通する構成は共
通の英文字を付して示し、各機器ごとの重複した説明は
省略する。

【００２１】テレビジョン受像器２は、図示しないチュ
ーナ部において、所望のチャンネルを受信してビデオ信
号及びオーディオ信号を出力する。またテレビジョン受
像器２は、図示しないモニタ部において、チューナ部よ
り出力されるビデオ信号を表示し、又はビデオテープレ
コーダ３で再生したビデオ信号を表示する。

【００２２】テレビジョン受像器２において、各オブジ
ェクト２Ａ及び２Ｂは、それぞれチューナ部及びモニタ
部を制御する制御モジュールにより構成され、このテレ
ビジョン受像器２内において、それぞれ固有のＩＤが割
り当てられるようになされている。

【００２３】これに対してビデオテープレコーダ３は、
図示しないチューナ部において、所望のチャンネルを受
信してビデオ信号及びオーディオ信号を出力する。さら
にビデオテープレコーダ３は図示しない磁気記録再生部
において、チューナ部又はテレビジョン受像器２で受信
したビデオ信号及びオーディオ信号を記録し、また記録
したビデオ信号及びオーディオ信号を再生する。

【００２４】ビデオテープレコーダ３において、オブジ
ェクト３Ａ及び３Ｂは、それぞれチューナ部及び磁気記
録再生部を制御する制御サービスモジュール（service
module）により構成され、ビデオテープレコーダ３内に
おいて固有のＩＤが割当てられるようになされている。

【００２５】これらのオブジェクト２Ａ〜３Ｂは、不特
定多数に通知する必要のある各種イベント（event）が
発生すると、イベントマネージャ（event manager）２
Ｄ、３Ｄを介して、機器内の他のサービスモジュールに
イベントを通知し、また必要に応じてイベントマネージ
ャ２Ｄ、３Ｄ、ブロードキャストマネージャ２Ｆ、３
Ｆ、ネットワーク４を介して外部機器にイベントを通知
する。

【００２６】ここでイベントとは、各オブジェクト２Ａ
〜３Ｂの制御対象における状態の変化を意味する。例え
ば、ビデオテープレコーダ３においては、例えばユーザ
が操作子を操作してチューナ部の受信チャンネルを切り
換えた場合、磁気テープの装填、排出、再生の終了等が
該当する。

【００２７】また、各機器２、３がネットワーク４に接
続された場合もイベントの発生であり、テレビジョン受
像器２及びビデオテープレコーダ３においては、図示し
ないオブジェクトの制御対象によりネットワーク４への
接続が物理的に検出され、この検出結果に基づいてこの
オブジェクトより、このイベント情報が通知されるよう
になされている。

【００２８】各オブジェクト２Ａ〜３Ｂは、イベントマ
ネージャ２Ｄ、３Ｄを経由して機器内サービスモジュー
ルとの間で送受するメッセージによりこのようなイベン
トの発生を機器内の各サービスモジュールに通知する。
イベントマネージャ２Ｄ、３Ｄは、このイベントを通知
する際に、ブロードキャストマネージャ２Ｆ、３Ｆに対
してメッセージのブロードキャスト（broadcast）を依
頼する。

【００２９】さらにオブジェクト２Ａ〜３Ｂは、機器内
の他のオブジェクトより送出された自己宛のメッセー
ジ、他の機器よりネットワーク４に送出された自己宛の
メッセージを取得しこれにより他のオブジェクト、さら
には外部機器における状態変化に応動して制御対象の動
作を制御するようになされている。

【００３０】このようなメッセージ交換において、これ
らのオブジェクト２Ａ〜３Ｂは、メッセンジャ（messen
ger）２Ｃ、２Ｃを介してイベントマネージャ２Ｄ、３
Ｄ及び属性情報管理手段であるサービスレジストリ（se
rvice registry）２Ｆ、３Ｆにメッセージを通知する。
そして、このイベントマネージャ２Ｄ、３Ｄ及びサービ
スレジストリ２Ｅ、３Ｅにおけるメッセージの配送によ
り、機器内の登録済みの配送先、機器外の不特定の配送
先にメッセージを通知する。

【００３１】またこれとは別に、イベントマネージャ２
Ｄ、３Ｄ及びサービスレジストリ２Ｅ、３Ｅにより配送
されたメッセージを、メッセンジャ２Ｃ、３Ｃを介して
受け取ることにより、機器内外、ネットワーク４上に外
部機器より送出されたメッセージを取得する。

【００３２】このようなメッセージの配送は、機器内の
登録済みの配送先については、イベントマネージャ２
Ｄ、３Ｄ自身の機能により、機器外の不特定多数の配送
先については、イベントマネージャ２Ｄ、３Ｄがブロー
ドキャストマネージャ２Ｆ、３Ｆを利用して実行され
る。またネットワーク４を介して受信したブロードキャ
ストによるメッセージの場合、イベントマネージャ２
Ｄ、３Ｄにより登録済みの配送先への１対１通信により
配送される。

【００３３】これによりオブジェクト２Ａ〜３Ｂは、イ
ベントマネージャ２Ｄ、３Ｄ及びサービスレジストリ２
Ｅ、３Ｅとの間の１対１の通信により、種々のメッセー
ジを機器内外に通知できるようになされている。また機
器内外に関わらず、送信先が１つの通常通信において
は、メッセンジャ２Ｃ、３Ｃが処理し、機器外の特定機
器が宛先の場合にも、このメッセンジャ２Ｃ、３Ｃが処
理する。

【００３４】さらにテレビジョン受像器２及びビデオテ
ープレコーダ３は、サービスレジストリ２Ｅ、３Ｅ、属
性情報保持手段である属性データベース（attribute da
tabase）２Ｇ、３Ｇ及びクイリデータベース（query da
tabase）２Ｈ、３Ｈをそれぞれ有している。

【００３５】属性データベース２Ｇ、３Ｇは、各機器
２、３のオブジェクト２Ａ〜３Ｂの属性情報を保持し、
サービスレジストリ２Ｅ、３Ｅの制御の下に属性情報の
読み出し及び書き込みが行われる。

【００３６】クイリデータベース２Ｈ、３Ｈは、例えば
検索等の照会に係る情報を保持し、サービスレジストリ
２Ｅ、３Ｅの制御の下にこのような情報の読み出し及び
書き込みが行われる。

【００３７】サービスレジストリ２Ｅ、３Ｅは、各機器
２、３のオブジェクトの属性情報を登録・管理してい
る。そして、これらテレビジョン受像器２及びビデオテ
ープレコーダ３の内部及び外部から、メッセンジャ２
Ｃ、３Ｃを介して与えられる照会に対して、属性データ
ベース２Ｇ、３Ｇ及びクイリデータベース２Ｈ、３Ｈを
利用して応答する。

【００３８】また、テレビジョン受像器２及びビデオテ
ープレコーダ３には、機器内のオブジェクトが使用中で
あるかどうかを監視し、不必要な電力消費を抑えるため
の処理をするサービスモジュールとしてパワーマネージ
ャ（power manager）２Ｊ、３Ｊが備えられている。こ
のパワーマネージャ２Ｊ、３Ｊは、メッセンジャ２Ｃ、
３Ｃを介してイベントを通知されることにより状態を知
らされ、所定の場合には電源のオン／オフを切り換え制
御する。

【００３９】続いて、テレビジョン受像器２及びビデオ
テープレコーダ３における電源の制御の一例について説
明する。

【００４０】テレビジョン受像器２及びビデオテープレ
コーダ３のサービスレジストリ２Ｅ、３Ｅは、制御対象
であるオブジェクトを構成するサービスモジュールの属
性情報を属性データベース２Ｇ、３Ｇに保持し、これら
電子機器の内部及び外部からの照会に応答している。例
えば、検索に対しては、検索条件に合致するサービスモ
ジュールの存在を確認して応答する。

【００４１】テレビジョン受像器２又はビデオテープレ
コーダ３が電源をオフにする際には、サービスレジスト
リ２Ｅ、３Ｅは、属性データベース２Ｇ、３Ｇの保持す
るこの電子機器の備えるサービスモジュールの属性情報
を他の電子機器のサービスレジストリに送り、属性情報
ついての照会に対する応答を委託し、その後にパワーマ
ネージャ２Ｊ、３Ｊが電源をオフにする。また、電源を
オフとせずに、各機器２、３を制御するＣＰＵを停止状
態とすることもある。

【００４２】例えば、テレビジョン受像器２が電源をオ
フにする際には、サービスレジストリ２Ｅは属性データ
ベース２Ｇの有するテレビジョン受像器２のサービスモ
ジュールの属性情報を、例えばビデオテープレコーダ３
のサービスレジストリ３Ｅに送出する。

【００４３】テレビジョン受像器２の属性データベース
２Ｇに保持されている属性情報をメッセンジャ２Ｃ及び
伝送モジュール２Ｉを介して、ネットワーク４に送出す
る。このようにテレビジョン受像器２からネットワーク
４に送出された属性情報は、ビデオテープレコーダ３の
伝送モジュール３Ｉ及びメッセンジャ３Ｃを介してサー
ビスレジストリ３Ｅに到達する。

【００４４】そして、テレビジョン受像器２は、ビデオ
テープレコーダ３のサービスレジストリ３Ｅに、送出し
た属性情報についての照会に対する応答を委託した後に
パワーマネージャ２Ｊにより電源をオフに制御する。ま
たは、テレビジョン受像器２は、電源をオフにする代わ
りにこのテレビジョン受像器２の全体を制御するＣＰＵ
を停止状態にする。

【００４５】一方、ビデオテープレコーダ３のサービス
レジストリ３Ｅは、テレビジョン受像器２の備えるサー
ビスモジュールの属性情報についての照会があった場合
には、テレビジョン受像器２のサービスレジストリ２Ｅ
に代わって応答する。そして、照会があったサービスモ
ジュールがテレビジョン受像器２に該当する場合には、
例えばこのテレビジョン受像器２のモニタ部が該当する
場合には、テレビジョン受像器２の電源をオン状態にす
る。あるいは、ＣＰＵが停止状態にある場合には、ＣＰ
Ｕを動作状態にする。

【００４６】以上のようにして、テレビジョン受像器２
及びビデオテープレコーダ３のサービスレジストリ２
Ｅ、３Ｅは、電源をオフにする、あるいはＣＰＵを停止
状態にする際に、サービスモジュールの属性情報に対す
る照会に対する応答を他の電子機器に託す。

【００４７】このことにより、テレビジョン受像器２又
はビデオテープレコーダ３の電源がオフの状態、あるい
はＣＰＵが停止状態にあっても、応答を委託した他の電
子機器が属性情報に対する照会に代わって応ずる。した
がって、照会に対して応答可能な分散協調動作を維持し
つつ消費電力の低減を図ることができる。

【００４８】続いて、テレビジョン受像器２及びビデオ
テープレコーダ３における電源制御の他の例について説
明する。

【００４９】テレビジョン受像器２及びビデオテープレ
コーダ３のサービスレジストリ２Ｅ、３Ｅは、サービス
モジュールの属性情報を保持し、これらの電子機器の内
部及び外部の電子機器から、例えば検索のような照会が
あった場合には、この照会に応答している。

【００５０】テレビジョン受像器２及びビデオテープレ
コーダ３のサービスレジストリ２Ｅ、３Ｅは、他の電子
機器のサービスレジストリに委託された場合には、自己
の備えるサービスモジュールの属性情報と共に上記他の
電子機器のサービスモジュールの属性情報も併せて属性
データベース２Ｇ、３Ｇに保持し、属性情報の照会に対
しては内部のサービスモジュールの属性情報のみならず
上記他の電子機器のサービスモジュールの属性情報につ
いての照会に対しても応答する。

【００５１】すなわち、テレビジョン受像器２及びビデ
オテープレコーダ３は、他の電子機器のサービスレジス
トリから委託を受け、上記他の電子機器の属性情報デー
タベースから属性情報を送られた場合には、上記他の電
子機器の属性情報を属性データベース２Ｇ、３Ｇに保持
する。そして、テレビジョン受像器２及びビデオテープ
レコーダ３のサービスレジストリ２Ｅ、３Ｅは、属性情
報についての照会があった場合には属性データベース２
Ｇ、３Ｇを参照して応答する。

【００５２】テレビジョン受像器２及びビデオテープレ
コーダ３は、上記他の電子機器が属性情報についての照
会に対する応答を委託してから電源をオフにした、ある
いはＣＰＵを停止状態にした場合には、上記他の電子機
器に係る属性情報について代わって応答する。そして、
属性情報についての照会が上記他の電子機器に該当する
場合には上記他の電子機器の電源をオンに制御する。あ
るいは停止状態にあるＣＰＵを動作状態にする。

【００５３】例えば、テレビジョン受像器２のサービス
レジストリ２Ｅは、例えばビデオテープレコーダ３のサ
ービスレジストリ３Ｅからビデオテープレコーダ３の属
性データベース３Ｇの有するビデオテープレコーダ３の
備えるサービスモジュールの属性情報を送られてビデオ
テープレコーダ３の属性情報に対する応答を委託された
場合には、この属性情報を属性データベース３Ｇに記録
する。

【００５４】そして、テレビジョン受像器２のサービス
レジストリ２Ｅは、属性情報について照会があったとき
には、属性データベース２Ｇを参照することにより内部
のサービスモジュールに対する属性情報についての照会
のみならずビデオテープレコーダ３のサービスモジュー
ルの属性情報についての照会にも応答する。

【００５５】さらに、ビデオテープレコーダ３の電源が
オフ状態にある、あるいはＣＰＵが停止状態にある場合
には、属性情報についての照会がビデオテープレコーダ
３に該当する場合には、例えばビデオテープレコーダ３
の磁気記録再生部を検索している場合には、ビデオテー
プレコーダ３の電源をオン状態とし、あるいは停止状態
にあるＣＰＵを動作状態にする。

【００５６】このように、テレビジョン受像器２及びビ
デオテープレコーダ３は、他の電子機器のサービスレジ
ストリから属性情報を送られてその属性情報に対する照
会への回答を委託された場合には、この属性情報を属性
情報データベース２Ｇ、３Ｇに記録し、上記他の電子機
器の属性情報についての照会があった場合には、上記た
の電子機器のサービスレジストリに代わってその照会に
応答する。

【００５７】上記他の電子機器は、属性情報に対する照
会への応答をテレビジョン受像器２又はビデオテープレ
コーダ３に委託してから電源をオフにすることにより、
あるいはＣＰＵを停止状態にすることにより、当該電子
機器の電源がオフ状態、あるいはＣＰＵが停止状態にあ
っても、ネットワーク４を介しての属性情報に対する照
会に応答することができる。

【００５８】したがって、上記他の電子機器において
は、外部からの照会に応答することが可能な分散協調動
作状態を維持しつつ消費電力の低減が図られている。上
記他の電子機器は、検索の対象に該当する場合には検索
があった時点で電源がオンに制御される。

【００５９】以上述べたように、テレビジョン受像器２
及びビデオテープレコーダ３のようなノードとしての機
能を有する電子機器は、単数又は複数のオブジェクトの
サービスモジュールの属性情報を保持する属性データベ
ースと、この属性データベースを管理し、上記属性デー
タベースの保持する属性情報を他の電子機器の備えるサ
ービスレジストリに送出して外部からの上記属性情報に
ついての照会に対する応答を委託してから電源を停止状
態にするサービスレジストリとを有している。

【００６０】また、テレビジョン受像器２及びビデオテ
ープレコーダ３等の電子機器は、単数又は複数のオブジ
ェクトの属性情報を保持し、他の電子機器から委託され
た場合には上記他の電子機器のオブジェクトのサービス
モジュールの属性情報をも併せて保持する属性データベ
ースと、上記属性データベースを管理して上記属性デー
タベースの保持する属性情報について、上記他の電子機
器から委託された場合には上記他の電子機器のオブジェ
クトのサービスモジュールの属性情報についても、外部
からの照会に応答するサービスレジストリとを有するも
のである。

【００６１】次に、電源制御方法に係る一連の工程につ
いて、図２及び図３に示すフローチャートを参照して説
明する。

【００６２】このフローチャートに示される工程は、テ
レビジョン受像器のサービスレジストリが他の電子機器
のサービスレジストリに、テレビジョン受像器に代わっ
て検索処理を行う代行を委託する際の処理手順を示すも
のである。

【００６３】ここでは、テレビジョン受像機内のサービ
スモジュールが稼働中でないこと、また、ユーザレベル
でのソフトウェアモジュールが稼働していないことを前
提とする。

【００６４】この一連の工程は、テレビジョン受像器の
サービスレジストリが、電源の停止状態の一具体例とし
ての電源遮断準備のメッセージを受け取ることから開始
される。すなわち、テレビジョン受像器のサービスレジ
ストリが電源遮断準備のメッセージをパワーマネージャ
から受けることによりこの一連の工程が開始される。こ
の電源切断準備のメッセージは、サービスレジストリが
検索に対する代行をする契機となるものである。

【００６５】最初のステップＳ７１においては、テレビ
ジョン受像器のサービスレジストリが現在他ノードの電
子機器の検索代行を行っているかどうかを確認する。

【００６６】他の電子機器の検索代行についての情報を
保存しておくデータベースのデータ構造は、例えば図４
のようなものになる。図中には、横方向に左から右に順
に、“ノードＩＤ”、“属性情報のデータベースＩ
Ｄ”、“属性情報のバイト数”の列が並んでいる。図中
の縦方向には、最初の行にはノードＩＤ“ＢＢ”、属性
情報のデータベース“データベースＢ”、属性情報のバ
イト数“サイズＢ”が表示されている。これに続く行の
表示は省略されている。この検索を行う属性情報に関す
るデータベースは、サービスレジストリの管理の下に、
例えばクイリデータベースに保持される。

【００６７】このデータベースの内容を確認することに
より、テレビジョン受像器のサービスレジストリが他の
電子機器の代行をしているか否かを確認する。そして、
テレビジョン受像器のサービスレジストリが他の電子機
器のサービスレジストリの代行をしている場合には“Ｙ
ＥＳ”としてステップＳ７２に進み、そうでない場合に
は“ＮＯ”としてステップＳ７３に進む。

【００６８】ステップＳ７２においては、上記図４に示
したデータベースにエントリが存在すればその先頭のも
のから他の電子機器に代行を委託、すなわち再依頼する
必要があるので、第１エントリのノードＩＤ“ＢＢ”の
属性情報の代理依頼の対象とする。すなわち、このター
ゲットノードをＢＢとする。そして、ステップＳ７４に
進む。

【００６９】ステップＳ７３においては、上記図４に示
したデータベースにエントリが存在しないのでテレビジ
ョン受像器の自己の属性情報だけを依頼すればよい。そ
こで、テレビジョン受像器のサービスレジストリは、自
ノードのノードＩＤの属性情報を代理依頼の対象とす
る。そして、ステップＳ７４に進む。例えば、自ノード
のノードＩＤを“ＡＡ”とすると、ターゲットノードを
ＡＡに設定することになる。そして、ステップＳ７４に
進む。

【００７０】ステップＳ７４においては、検索代行依頼
をする属性情報のサイズと属するノードＩＤとをパラメ
ータに含めて、検索代行依頼のメッセージを不特定の機
器に対して発信するブロードキャストを行う。そして、
ステップＳ７５に進む。なお、このブロードキャストに
ついては後に説明する。

【００７１】ここで、属性情報のサイズを知らせるの
は、他のノードが検索代行を引き受ける場合にそのノー
ドのＲＡＭ領域などに必要な属性情報を保存する余裕が
あるかどうかを判断するためである。すなわち、ノード
によっては複数のノードに検索代行依頼を行っておりそ
の場合にはデータを送る必要がないからである。

【００７２】検索代行依頼のメッセージは、図５に示す
ようになる。すなわち、図中には、左から右に順に、
“センダ（sender）ＩＤ”、“代行依頼識別ＩＤ”及び
“代行依頼内容”の３個の行が表され、さらに“代行依
頼内容”の欄は、“属性情報サイズ”及び“所属ノード
ＩＤ”の欄から構成されている。そして、センダＩＤ
“ＸＸＸＸＸＸＸＸ”、代行依頼識別ＩＤ“２３４
５”、属性情報サイズ“サイズＢ”、所属ノードＩＤ
“ＢＢ”が、それぞれ表示されている。

【００７３】ステップＳ７５においては、所定時間にわ
たって他のノードからの返事を待つために待機する。す
なわち、上記ステップＳ７４にてブロードキャストした
メッセージに対する他のノードからの応答を受け付け
る。そして、次のステップＳ７６に進む。

【００７４】ステップＳ７６においては、上記ステップ
Ｓ７５において他のノードから応答があったか否かによ
って分岐する。他のノードのサービスレジストリは、検
索の代行をすることができない場合には応答しないの
で、何らかの応答があればそのサービスレジストリは代
行を引き受ける用意があるということになる。返事があ
った場合には“ＹＥＳ”としてステップＳ７８に進み、
返事がなかった場合には“ＮＯ”としてステップＳ７７
に進む。

【００７５】なお、応答の際のパラメータとしては属性
情報を送る必要があるか否かを示すフラグが含むことが
変形例として考えられる。

【００７６】また、変形例としては、ステップＳ７６で
属性情報が不要であるという応答があった場合には改め
て検索依頼を行う必要はない。既に検索依頼を受けてい
ることになるからである。

【００７７】ステップＳ７７においては、所定の時間内
に返事がなかった場合であり、検索代行を依頼する相手
がいないことになるので依頼処理は失敗したことにな
る。この場合には、テレビジョン受像器のサービスレジ
ストリは、検索に対して応答する必要があるので、ＣＰ
Ｕを止めるわけには行かない旨をパワーマネージャに伝
える。そして、ステップＳ８２に進む。なお、図２中の
“”は、図３中の“”に手順がつながることを意味
している。

【００７８】ステップＳ７８においては、上記ステップ
Ｓ７６で応答があったサービスレジストリに対して検索
依頼を行うことになる。この際に送る属性情報は、所属
するノードＩＤとそのノードのサービスモジュールに関
して現在持っている全属性情報である。そして、ステッ
プＳ７９に進む。なお、図２中の“”は、図３中の
“”に手順がつながることを意味している。

【００７９】ステップＳ７９においては、テレビジョン
受像器のサービスレジストリが現在処理したのは自分が
代行しているノードに関するものであるという条件にし
たがって分岐する。そして、現在処理したのは自分が代
行しているノードに関するものであるときには“ＹＥ
Ｓ”としてステップＳ８０に進み、そうでない場合には
“ＮＯ”としてステップＳ８１に進む。

【００８０】このステップＳ７９においては、ここでは
ステップＳ７４からステップＳ７８までの処理の対象が
どのノードに係るものであるかの確認を対象となるノー
ドを保持する変数であるターゲットノード（targetNod
e）の値を調べることにより行う。

【００８１】ステップＳ８０においては、処理対象が自
ノードの属性情報でなかった場合には代行依頼を受けて
いたノードに対して再依頼したことになり、既に代行す
る必要はなくなっているので、上記図４に示した検索を
行う属性情報に関するデータベースから、対応するノー
ドＩＤのエントリを削除する。その後ステップＳ７１に
戻り必要な依頼がすべて終わるか依頼できなくなるまで
処理を繰り返す。ここで、自分が代行している全てのノ
ードを終えると、ステップＳ７３における自ノードに関
する検索代行要求の工程に進むことになる。なお、図３
中の“”は、図２中の“”に手順がつながることを
意味している。

【００８２】一方、ステップＳ８１においては、処理対
象が自ノードの属性情報だった場合には全ての属性情報
に対して依頼が終了したことになる。すなわち、検索代
行依頼は成功したことになる。そして、次のステップＳ
８２に進む。

【００８３】ステップＳ８２においては、テレビジョン
受像器のサービスレジストリは、パワーマネージャに対
して処理の成功又は失敗を通知する。処理が成功した場
合には、パワーマネージャは電源を停止状態に制御する
が、処理が失敗した場合にはＣＰＵは稼働している必要
があるので電源はオン状態に保たれる。

【００８４】そして、このステップＳ８２にてこの一連
の工程を終了し、次のメッセージの処理に移る。

【００８５】続いて、代理検索を受けているサービスレ
ジストリの検索依頼受信時の一連の手順を、図６に示す
フローチャートを参照して説明する。ここでは、テレビ
ジョン受像器のサービスレジストリが、ビデオテープレ
コーダのサービスレジストリから、ビデオテープレコー
ダのオブジェクトであるサービスモジュールの属性情報
を送られ、この属性情報についての応答を委託された場
合を例示する。

【００８６】ビデオテープレコーダのサービスレジスト
リに代わって検索代行を引き受けたテレビジョン受像器
のサービスレジストリは、自己のデータベース以外の属
性情報データベースを有することになる。したがって、
テレビジョン受像器のノードのみの検索の場合に加えて
検索処理手順に幾分変更が必要になり、データベースに
対する検索処理はデータベースの数だけ繰り返す必要が
ある。

【００８７】さらに、テレビジョン受像器のサービスレ
ジストリは、依頼されているデータベースに該当するも
のが含まれている場合には、該当するノードに電源投入
のメッセージを送る必要がある。

【００８８】この一連の工程は、テレビジョン受像器の
サービスレジストリが、自己のノードの属性情報のデー
タベースを検索することにより開始される。

【００８９】最初のステップＳ９１においては、上記図
４に示した検索を行う検索情報に関するデータベースの
エントリの数を確認する。ここでは、このデータベース
において、テレビジョン受像器に検索代行を依頼してい
るノードＩＤ“ＢＢ”等のエントリの数をＮとする。そ
して、次のステップＳ９２に進む。

【００９０】ステップＳ９２においては、検索代行を依
頼されているデータベースの数Ｎのうちで検索が終了し
たデータベースの数ｉを０に設定する。すなわち、ｉ＝
０と初期設定する。そして、次のステップＳ９３に進
む。

【００９１】ステップＳ９３においては、処理していな
い属性情報データベースが有るかどうか確認する。すな
わち、検索処理が終了したデータベースの数ｉが検索を
依頼されているデータベースの数Ｎより小さいという条
件、ｉ＜Ｎによって分岐する。この条件を満たす場合に
は、未処理のデータベースが存在するので“ＹＥＳ”と
してステップＳ９４に進む。この条件を満足しない場合
には全て処理済であるので“ＮＯ”として検索結果のリ
ストのＩＤを検索依頼元に通知し、この一連の工程を終
了する。

【００９２】ステップＳ９４においては、上記図４に示
したデータベースのエントリの内で現在の第ｉ番目のデ
ータベースの次のデータベース、すなわち第ｉ＋１番目
のエントリのデータベースの属性情報データベースの中
を検索する。そして、次のステップＳ９５に進む。

【００９３】ステップＳ９５においては、上記ステップ
Ｓ９４において、該当するサービスモジュールが存在す
るという条件によって分岐する。そして、この条件を満
たす場合にはステップＳ９６に進む、この条件を満たさ
ない場合にはステップＳ９８に進む。

【００９４】ステップＳ９６においては、ステップＳ９
４における該当するサービスモジュールをリストに追加
する。この際、ステップＳ９４の結果は別ノードでのサ
ービスモジュールＩＤであるので、変換が必要となる。
そして、次のステップＳ９７に進む。

【００９５】ステップＳ９７においては、検索に該当し
たことで、当該サービスモジュールが通信を受ける可能
性が発生したので、テレビジョン受像器のサービスレジ
ストリは、該当するノードに電源投入のメッセージを送
る。そして、次のステップＳ９８に進む。

【００９６】電源投入に成功すれば、上記ノードは自ら
検索を受けることができるようになり、検索代行を依頼
する必要がなくなるので、テレビジョン受像器のサービ
スレジストリは、上記図４に示した検索を行う属性情報
に関するデータベースから当該ノードのエントリを削除
し、さらに属性情報データベースも削除する。

【００９７】なお、この段階では上記該当したノードが
通信を受けるかどうかはわからず、直ぐに検索代行の再
依頼を受ける可能性があるので、検索を依頼されている
データベース削除を行わない変形例が挙げられる。

【００９８】ステップＳ９８においては、処理済のデー
タベースの数ｉをインクリメントする。すなわち、ｉ＝
ｉ＋１と設定する。そして、ステップＳ９３に戻る。

【００９９】ここで、変形例としては複数のノードに属
するサービスモジュールを一つのメッセージで通知でき
るように図７に示すような形式に変更することもでき
る。

【０１００】図中では、左から右に順に“検索識別Ｉ
Ｄ”、“ノード数”、“ノードＩＤ”、及び複数の“該
当モジュール数”の列を有している。そして、最初の行
には、検索識別ＩＤ“１２３４”、ノード数“２”、ノ
ードＩＤ“ＢＢ”、該当モジュール数“ｎ”、該当モジ
ュールＩＤ“Ｂ１”，・・・，該当モジュールＩＤ“Ｂ
ｎ”が表示されている。次の行には、ノードＩＤ“Ｃ
Ｃ”、該当モジュール数“ｍ”、該当モジュールＩＤ
“Ｃ１”，・・・，該当モジュールＩＤ“Ｃｍ”が、表
示されている。

【０１０１】このメッセージの形式を利用することによ
り、複数のノードに属するサービスモジュールに対し
て、一つのメッセージにて検索結果を通知することがで
きる。

【０１０２】続いて、電源制御方法の変形例について、
図８に示すフローチャートを参照して説明する。

【０１０３】他のノードからの検索結果を受け取った時
点でサービスレジストリが他のノードの宛先のプロキシ
（proxy ）を作成する実装では、リストを使わなくなっ
た時がプロキシを削除する適切なタイミングの候補であ
るので、通信が終了するまでサービスレジストリに対し
てリストが不要になった旨を通知する処理を行わないこ
とにすることが考えられる。

【０１０４】しかし、不必要にリストを保持してること
はメモリの無駄であり、また、新しく他のノードからの
検索結果が返ってきたときにリストの更新処理や、リス
ト変更のイベント処理などを行わなければならない。

【０１０５】これらの無駄を避けるために、リストとが
不要になったことを通知した際にプロキシを削除して良
いか否かの判断材料として、実際に通信を行う予定の相
手をサービスレジストリに通知してからリストとが不要
になったことを通知し、全ての通信が終わった後に通信
が終了したことを通知する実装が考えられる。

【０１０６】この場合にはリストに含まれている宛先に
対して通信を行う代わりに、通信相手をリストに含まれ
ている宛先から選択し、その通信相手をサービスレジス
トリに通信するようにすることができる。

【０１０７】この場合には、リスト全体が必要な工程
と、リストに含まれていたいくつかの宛先が必要な工程
に分けることができる。この実装では通信する予定であ
ることが知らされていない宛先のプロキシはリストが不
要になった際に削除し、通信予定が知らされている宛先
のプロキシは通信が終了したことを通知した際に削除さ
れることになる。通信予定の宛先の個数には制限はな
い。

【０１０８】この一連の工程は、ネットワーク中の他の
サービスモジュールとの通信が必要になることにより開
始される。

【０１０９】最初のステップＳ１０１においては、同一
ノードのサービスレジストリに対して検索要求のメッセ
ージを送り、次のステップＳ１０２においてはサービス
レジストリからの検索結果を待ち、これに続くステップ
Ｓ１０３においては、サービスレジストリの検索結果を
含むリストのＩＤを受け取る。そして、次のステップＳ
１０４に進む。

【０１１０】ステップＳ１０４においては、リストに含
まれている宛先の数が０であるという条件によって分岐
する。すなわち、リストに含まれている宛先の数が０の
場合には“ＹＥＳ”としてステップＳ１０７に進み、そ
うでない場合には“ＮＯ”としてステップＳ１０５に進
む。

【０１１１】ステップＳ１０５においては、通信相手を
リストに含まれている宛先から選択する。次のステップ
Ｓ１０６においては、通信相手をサービスレジストリに
通知する。そして、これに続くステップＳ１０７に進
む。

【０１１２】ステップＳ１０７においては、サービスレ
ジストリに対して、リストが不必要になったことを通知
する。そして、次のステップＳ１０８においては通信相
手との通信が必要な処理を行い、これに続くステップＳ
１０９においては通信が終了したことをサービスレジス
トリに通知する。そして、この通信が必要な処理に係る
一連の工程を終了する。

【０１１３】以上のような手順により、実際に通信を行
う相手をサービスレジストリに通知することにより、作
業の効率化を図っている。

【０１１４】続いて、電源制御方法の具体例として、ビ
デオテープレコーダにおいて、再生ボタンの押圧という
イベントに発生により開始される一連の工程について、
図９及び図１０に示すフローチャートを参照して説明す
る。

【０１１５】この具体例においては、単純な例として家
の中の各ＡＶ機器がデジタルネットワークに接続されて
おり、データの配信などは全てソフトウェアで操作でき
る状態を考える。このネットワークには、テレビジョン
受像器及びビデオテープレコーダが接続されている。

【０１１６】この一連の工程は、ネットワークに接続す
る機器のサービスモジュール間の通信が必要になる一例
であり、ユーザがビデオテープをビデオテープレコーダ
に挿入し、再生ボタンを押圧することにより開始される
ものである。すなわち、この一連の工程は、ビデオテー
プレコーダの再生ボタンの押圧というイベントの発生に
より開始される。

【０１１７】最初のステップＳ１１１においては、ネッ
トワーク内でサービスモジュールタイプがディスプレイ
の構成要素を含む機器を検索する。そして、これに続く
ステップＳ１１２に進む。

【０１１８】ステップＳ１１２においては、処理してい
ないデータベースの数を表す変数Ｉが０に設定される。
そして、次のステップＳ１１３に進む。

【０１１９】ステップＳ１１３においては、処理してい
ない検索結果があるという条件によって分岐する。すな
わち、処理すべきデータベースの数をＮとすると、Ｎ＞
Ｉを満たす場合には処理していない検索結果が残ってい
るので“ＹＥＳ”としてステップＳ１１４に進み、この
条件を満足しない場合には検索処理を終了したので“Ｎ
Ｏ”としてステップＳ１２２に進む。なお、図９中の
“”は、図１０中の“”に手順がつながることを意
味している。

【０１２０】ステップＳ１１４においては、未処理の最
初の要素について処理を行う。ここれ、処理を行ったデ
ータベースの数はＩであるので、未処理の最初のデータ
ベースである第Ｉ＋１番目のデータベースについて処理
を行う。そして、このデータベースの処理が終わると、
処理の終わったデータベースの数を表す変数であるＩを
インクリメントしてＩ＝Ｉ＋１とする。そして、ステッ
プＳ１１５に進む。

【０１２１】ステップＳ１１５においては、ディスプレ
イが使用中であるという条件によって分岐する。すなわ
ち、この条件を満足する場合には“ＹＥＳ”としてステ
ップＳ１１３に戻り、この条件を満足しない場合には
“ＮＯ”として次のステップＳ１１６に進む。

【０１２２】ステップＳ１１６においては、ディスプレ
イに使用要求を出し、ステップＳ１１７に進む。

【０１２３】ステップＳ１１７においては、ステップＳ
１１６におけるディスプレイに対する使用要求が受け入
れられたか否かによって分岐する。すなわち、上記要求
が受け入れられた場合には“ＹＥＳ”としてステップＳ
１１８に進み、この要求が受け入れられなかったときに
は“ＮＯ”として上記ステップＳ１１３に戻る。

【０１２４】ステップＳ１１８においては、ディスプレ
イを含む機器がスピーカを含むか否かによって分岐す
る。すなわち、ディスプレイを含む機器がスピーカを含
む場合には“ＹＥＳ”としてステップＳ１２０に進み、
その機器がスピーカを含まない場合には“ＮＯ”として
ステップＳ１１２に進む。ここで、図９中の“”は、
図１０中の“”に手順がつながることを示している。

【０１２５】ステップＳ１２０においては、スピーカの
使用要求を出し、次のステップＳ１２１に進む。

【０１２６】ステップＳ１２１においては、上記ステッ
プＳ１２０の要求が受け入れられたか否かによって分岐
する。すなわち、スピーカの使用要求が受け入れられた
ときには“ＹＥＳ”としてこの一連の工程を終了する。
スピーカの使用要求が受け入れられなかったときには
“ＮＯ”としてステップＳ１２２に進む。

【０１２７】ステップＳ１２２においては、ネットワー
ク内でサービスモジュールタイプがスピーカの構成要素
を含む機器を検索する。そして、次のステップＳ１２３
に進む。

【０１２８】ステップＳ１２３においては、検索が終了
したデータベースの数を表す変数Ｉを０に設定する。そ
して、これに続くステップＳ１２４に進む。

【０１２９】ステップ１２４においては、処理していな
い検索結果があるか否かによって分岐する。処理すべき
データベースの数Ｎとすると、処理していない検索結果
があるとき、すなわちＮ＞Ｉを満足するときには“ＹＥ
Ｓ”としてステップＳ１２５に進み、検索を終了してＮ
＞Ｉを満足しないときには“ＮＯ”としてこの一連の処
理を終了する。

【０１３０】ステップＳ１２５においては、データベー
スの最初の要素について処理を行う。すなわち、処理が
終了した数を表す変数Ｉの次の第Ｉ＋１番目のデータベ
ースについて処理が行われる。この処理が終了すると、
上記変数はＩ＝Ｉ＋１とインクリメントされる。そし
て、これに続くステップＳ１２６に進む。

【０１３１】ステップＳ１２６においては、スピーカが
使用中であるという条件によって分岐する。スピーカが
使用中であるときには“ＹＥＳ”として上記ステップＳ
１２４に戻り、使用中でないときには“ＮＯ”として次
のステップＳ１２７に進む。

【０１３２】ステップＳ１２７においては、スピーカに
使用要求を出し、ステップＳ１２８に進む。

【０１３３】ステップＳ１２８においては、ステップＳ
１２７にてスピーカ出した使用要求が受け入れられたか
否かによって分岐する。すなわち、上記要求が受け入れ
られた場合には“ＹＥＳ”としてステップＳ１２９に進
み、使用要求が受け入れられなかった場合には“ＮＯ”
として上記ステップＳ１２４に戻る。

【０１３４】ステップＳ１２９においては、再生を開始
し映像信号をディスプレイに、音声信号をスピーカに送
る。そして、この一連の工程を終了する。

【０１３５】ここで、上記Ｓ１１３やＳ１２４において
未処理の検索結果がない場合には、エラーが発生したこ
とを示して処理を中断することも考えられる。この場合
エラーメッセージの表示先としてはビデオテープレコー
ダの備える液晶パネルやエラーランプ等の表示装置だけ
ではなく、ネットワーク制御用の端末に表示することの
考えられる。

【０１３６】アナログの通信線での直接の接続を含む場
合には、その部分の制御を行うソフトウェアモジュール
を作成し、ユーザが接続情報を入力することにより対応
することができる。このためには入力装置と表示装置と
を備えた機器がネットワーク中に含まれていることが必
要となる。

【０１３７】以上述べたように、電源制御方法は、単数
又は複数のオブジェクトのサービスモジュールの属性情
報を取得する属性情報取得工程と、この属性情報取得工
程にて取得した属性情報を他の電子機器の備えるサービ
スレジストリに送出して外部からの上記属性情報につい
ての照会に対する応答を委託してから電源を停止状態に
する属性情報管理工程とを有している。

【０１３８】また、電源制御方法は、単数又は複数のオ
ブジェクトのサービスモジュールの属性情報を取得し、
他の電子機器から委託された場合には上記他の電子機器
のオブジェクトのサービスモジュールの属性情報をも併
せて取得する属性情報取得工程と、上記属性情報取得工
程にて取得した属性情報について、上記他の電子機器か
ら委託された場合には上記他の電子機器のオブジェクト
のサービスモジュールの属性情報についても、外部から
の照会に応答する属性情報管理工程とを有するものであ
る。

【０１３９】次に、電子機器の備えるサービスレジスト
リ及びサービスモジュールにおける通信について説明す
る。電子機器の備える各サービスモジュールは、メッセ
ージを送ることによって処理依頼等の協調動作を実現す
る構成である。

【０１４０】ここで、サービスモジュール間の情報伝達
の手段としては、メッセージキューを用いた１対１の通
信と、送り手側は特定の聞き手を意識しないイベントを
用いた通信が各ノード内で供給されているものとする。

【０１４１】ここでいうサービスモジュールとは、ある
機能を実現するための装置だけでなく、メモリに格納さ
れＣＰＵで実行されるプログラムも含む。

【０１４２】サービスモジュールがプログラムの場合に
は、全体の実行手段を示したものではなく、各機能を実
現するためのサービスモジュール毎の動作を記述したオ
ブジェクト指向的なモデルを用いて説明する。同一ＣＰ
Ｕ上のタイムシェアリングや複数ＣＰＵを使った並列処
理や分散処理などが行われている場合にはサービスモジ
ュールの処理は並列実行されているものとみなす。

【０１４３】各ノードの電子機器には一般に複数のサー
ビスモジュールが備えられ、複数ノードがネットワーク
にて接続されているが本発明の想定している状況であ
る。

【０１４４】まず、基本となるノードに電源が入ってい
る状態での検索の手順を示す。ある特定の機能もしくは
属性を持つサービスモジュールと通信を行いたいサービ
スモジュールは同一ノード内のサービスレジストリに対
して検索要求のメッセージを送る。

【０１４５】検索要求を受けたサービスレジストリは管
理しているサービスモジュールに関する情報を利用して
検索に該当するものが自分と同じノード内に存在するか
どうかのチェックをする。同時にノード内からの検索を
受けたサービスレジストリはブロードキャストマネージ
ャに依頼して検索要求をネットワーク全体に流す。

【０１４６】ネットワークからの検索要求のブロードキ
ャストメッセージを受けた各ノードのブロードキャスト
マネージャはそれぞれのノード内のサービスレジストリ
に検索要求を配送する。ノード外からの検索要求を受け
たサービスレジストリは、ノード内からの検索を受けた
場合と同様に管理している情報を利用して検索に該当す
るものが自分と同じノード内に存在するかどうかのチェ
ックをする。ノード外からの検索要求に該当するものが
自ノード内に存在した場合には、検索要求元のサービス
レジストリに対して結果を通知する。

【０１４７】ノード内からの検索要求を受けたサービス
レジストリは、ネットワークを介して他のサービスレジ
ストリからの結果を待ちながら、自分自身の検索結果を
基にしたリストを作成し、他のサービスレジストリから
の結果が返ってきた場合には順次リストに追加する。ノ
ード内からの検索要求を受けたサービスレジストリは自
分自身の検索結果を作成後、指定された時間が経過した
後に検索要求リストのＩＤを知らせる。この指定された
時間は、０のことも有り得る。

【０１４８】検索要求元はサービスレジストリから返っ
てきたリストの内容を確認し、そこに含まれているサー
ビスレジストリのメールボックスに対して通信を行うこ
とによって処理依頼等を行う。検索要求元にとって知ら
されたリストが不要となった時点で、もう使わないこと
を示すメッセージをサービスレジストリに送り、サービ
スレジストリは該当するリストを削除し、それ以降に他
のノードから返ってくるそのリストに対する検索結果は
捨てることになる。

【０１４９】リストＩＤを検索要求元に知らせた後、削
除する前に他のノードからの検索結果がサービスレジス
トリに返ってきた場合には、該当するリストの内容を追
加し、リスト内容が更新されたことを示すイベントを発
生させることにより、検索元がイベントをチェックして
いれば対応が可能になる。

【０１５０】続いて、各サービスモジュールごとの処理
をフローチャートを参照して説明する。

【０１５１】基本的な流れとして、最初にサービスレジ
ストリを利用するサービスモジュールの処理、次にサー
ビスモジュールからの検索要求を受けたサービスレジス
トリの処理を示し、最後に他のノードのサービスレジス
トリからの検索要求を受けたサービスレジストリの処理
を示す。

【０１５２】その後、他のノードのサービスレジストリ
に転送した検索結果が返ってきた時のサービスレジスト
リの対応と、サービスレジストリからの結果を処理中に
検索結果に追加があった場合のサービスモジュールの処
理方法、検索結果が不用になった際の処理を示してか
ら、他のノードのサービスレジストリの代理依頼に関し
て説明する。

【０１５３】まず、他のサービスモジュールとの通信を
行うためにサービスレジストリを使う際の一連の工程
を、図１１に示すフローチャートを参照して説明する。

【０１５４】この一連の工程は、ネットワーク中の他の
サービスモジュールとの通信が必要になることから開始
される。すなわち、このネットワーク中に特定の機能を
有するサービスモジュール、もしくは特定の機能を提供
するソフトウエアモジュールを利用する必要が生じると
開始される。

【０１５５】最初のステップＳ１１においては、同一ノ
ードのサービスレジストリに対して検索要求のメッセー
ジを送る。すなわち、同一のノード内のサービスレジス
トリに対して、通信を行いたい相手の種別や属性情報、
位置情報等を含む検索要求を送る。そして、次のステッ
プＳ１２に進む。

【０１５６】ステップＳ１２においては、サービスレジ
ストリからの検索結果が返ってくるまで待機する。並列
処理が行える環境であれば、検索結果を待つ間にそれと
は関係のない処理を行ってもよい。そして、ステップＳ
１３に進む。

【０１５７】ステップＳ１３においては、サービスレジ
ストリの検索結果を含む例えばリスト番号のようなリス
トのＩＤを受け取る。オブジェクト指向的なモデルを使
用すれば、ここで受け取るのはリストを表現するオブジ
ェクトと通信を行う際の宛先であり、検索結果である検
索要求に合致する通信相手と通信を行うための宛先や要
求を満たす通信相手の数はリストとの通信によって得る
ことになる。ただし、実装上は通信相手の宛先を含む配
列データのメモリ上のアドレス等の直接的なデータを受
け取ることも考えられる。そして、次のステップＳ１４
に進む。

【０１５８】ステップＳ１４においては、リストに含ま
れている宛先の数を確認する。すなわちリストに含まれ
ている宛先の数が０であるという条件によって分岐す
る。この宛先の数が０の場合には必要とする通信相手が
いないことがわかるので、“ＹＥＳ”としてサービスレ
ジストリに対してリストが不用になったことを通知する
ステップＳ１６に進み通信相手がいない場合の処理に移
る。そうでない場合には“ＮＯ”として次のステップＳ
１５に進む。

【０１５９】ステップＳ１５においては、リストに含ま
れている宛先の数が０以外であるので、そのリスト中の
宛先と通信を行う。例えば、家の中のＡＶ機器のネット
ワーク上で、ビデオテープレコーダが表示先のディスプ
レイを探していた場合であれば、検索結果の中から使用
されていないものを一つ選択するまで通信を行うことに
なるし、テレビがチャンネルリストを表示しようとして
いるのであれば、利用可能な全てのチューナに対して通
信を行うことになる。いずれにせよ、リストをどのよう
に利用するかは検索元の自由であり、サービスレジスト
リは関知しない。そして、次のステップＳ１６に進む。

【０１６０】ステップＳ１６においては、サービスレジ
ストリに対してリストが不用になったことを通知する。
この時に不要なリストを特定するための識別情報として
上記ステップＳ１５で、サービスレジストリから受け取
ったものを利用する。サービスレジストリはこの情報に
より検索要求を特定し、必要な処理を行う。そして、こ
の通信が必要な処理に係る一連の工程を終了する。

【０１６１】なお、この一連の処理は必ずしも通信相手
との通信が全て終わった後である必要はない。例えばス
テップＳ１６においてビデオテープレコーダがディスプ
レイを探している例では使用中でないディスプレイを見
つける処理が終了すれば、その後は検索結果であるディ
スプレイのリストは不要なので、その時点でこの処理を
行っても問題ない。

【０１６２】続いて、上記ステップＳ１１で送られた検
索依頼を受けたサービスレジストリに係る一連の工程に
ついて、図１２に示すフローチャートを参照して説明す
る。この一連の工程は、同一ノード内のサービスモジュ
ールからの検索依頼を受け付けることから開始される。

【０１６３】最初のステップＳ２１においては、ブロー
ドキャストマネージャを利用して他ノードのサービスレ
ジストリに検索要求を送る。すなわち、受け付けた検索
要求を他のノードのサービスレジストリに対してブロー
ドキャストするために、ブロードキャストマネージャに
依頼する。これは通常のサービスモジュールがネットワ
ークを意識する必要がないようにするためのモデルであ
り、ブロードキャストマネージャとサービスレジストリ
の双方の機能を兼ねるサービスモジュールとして実装す
ることもできる。

【０１６４】この際ブロードキャストする内容として
は、検索要求の他にブロードキャストのヘッダとして、
ブロードキャスト元のノードを特定するＩＤとサービス
レジストリ宛ての検索要求であることを示すＩＤ、返事
をする際に対応する検索要求を特定するための検索識別
ＩＤが含まれる。そして、次のステップＳ２２に進む。

【０１６５】ステップＳ２２においては、検索元に結果
を特定するためのリスト等のＩＤを用意する。このＩＤ
に対応して、配列等のデータ構造を作成することにな
る。

【０１６６】後にステップＳ２１で送った検索要求に対
するノードから返ってきた際にこのデータ構造に追加す
る必要があるため、ステップＳ２１で送った検索識別Ｉ
Ｄとここで用意したデータ構造のＩＤとの対応関係を記
録しておく。そして、ステップＳ２３に進む。

【０１６７】ここで、ＩＤは実装する際のプログラム言
語やＯＳに依存するが、オブジェクトＩＤやメモリのア
ドレス、サービスレジストリが管理するＩＤ等を用いる
ことになる。

【０１６８】ステップＳ２３においては、自ノードのサ
ービスモジュールに関してのデータベースである属性デ
ータベースを検索し、検索要求に合うサービスモジュー
ルのＩＤをステップＳ２２で用意したデータ構造に追加
する。この段階では検索結果は同一ノード内に存在する
サービスモジュールだけからなる。そして、ステップＳ
２４に進む。

【０１６９】ステップＳ２４においては、検索元にステ
ップＳ２２で用意したＩＤを通知する。このＩＤは同一
ノード内でのみ参照されるので、どのような形式のもの
であってもノード内でのみ整合性が取れていればよい。
そして、サービスモジュールからの検索依頼に対する処
理を行うこの一連の工程を終了し、次のメッセージの処
理に移る。

【０１７０】実際には一連の検索処理としてはステップ
Ｓ２１においてブロードキャストした検索に対する応答
が返ってきた段階で更に処理を行うことになるが、それ
は別のメッセージに対する処理として扱う。

【０１７１】続いて、上記ステップＳ２１でブロードキ
ャストされた他のノードからのサービスレジストリから
の検索要求を受けたサービスレジストリについての一連
の工程を、図１３に示すフローチャートを参照して説明
をする。

【０１７２】この一連の工程は、基本的には上述した自
ノードのサービスモジュールからの検索依頼を受けたと
きの処理と同じであるが、上記ステップＳ２１における
ブロードキャストを行わないことと、検索結果をノード
間通信で伝えるためにリストのＩＤだけでなく内容まで
通知する点が異なる。

【０１７３】この一連の工程は、他のノードのサービス
レジストリからの検索要求を受け付けることから開始さ
れる。最初のステップＳ３１においては、検索元に返す
情報を格納するためのデータ構造としてリストや配列な
どを用意する。そして、次のステップＳ３２に進む。

【０１７４】ステップＳ３２においては、検索要求元に
返すリストを作成する。これに続くステップＳ３３にお
いては、自ノードのサービスモジュールに関してデータ
ベースを検索し、検索要求に合うサービスモジュールの
ＩＤをステップＳ３２で用意したデータ構造に追加す
る。検索結果は同一ノード内に存在するサービスモジュ
ールだけからなる。そして、ステップＳ３４に進む。

【０１７５】ステップＳ３４においては、元のノードに
ステップＳ３３で検索した結果であるサービスモジュー
ルのＩＤのリストを通知する。上述の場合と違い、ステ
ップＳ３２で用意したデータ構造全体を示すものではな
く、リストに含まれる個々の要素と要素の個数を通知す
る。結果を通知する際には、検索結果の他にどの検索要
求に対するものかを示すための検索識別ＩＤも同時に通
知する。

【０１７６】ここで内容を全て通知するのは後にノード
間通信を行って要素の確認を行ったりすることを省略す
るためであり、リストが不要になったときに破棄するタ
イミングをノード内で判断できるようにするためでもあ
る。なお、変形例としてはデータ構造のＩＤだけを通知
することも考えられる。

【０１７７】しかし、上記ステップＳ２４でデータ構造
のＩＤだけを通知したのは後に他のノードからの検索結
果が図中の処理の結果として返ってきて内容が追加され
たときに変化があったことを知らせるためのＩＤとして
であるが、このステップＳ３４で通知するのはあくまで
もこのノード分の結果であり後に変更する必要がないの
で内容を通知しても何の問題もない。

【０１７８】いずれにせよ、ここで通知するサービスモ
ジュールのＩＤは別のノードで処理されるため、ネット
ワーク内でビット数が規定されている必要がある。これ
は各ノードで任意のＩＤを用いることができた上述の場
合との大きな違いとなる。

【０１７９】ステップＳ３４においては、ステップＳ３
３で作成しステップＳ３４で要素を追加したデータ構造
はもはや不要であるので破棄する。なお、ステップＳ３
４の変形例としてデータ構造のＩＤだけを通知する場合
には、この処理はこの時点では行えず、リスト破棄要求
のメッセージを受けた際に行うことになるが、利用中に
ノードがネットワークから切断されたような場合に無駄
なデータを破棄するための追加処理が必要になる。

【０１８０】このステップＳ４３において、他ノードの
サービスレジストリからの検索要求に対する一連の工程
を終了し、次のメッセージの処理に移る。

【０１８１】続いて、上記ステップＳ３３において通知
した検索結果を受け取ったサービスレジストリにおける
一連の工程を、図１４に示すフローチャートを参照して
説明する。

【０１８２】この一連の工程は、他ノードのサービスレ
ジストリからの検索結果のメッセージを受信することか
ら開始される。このメッセージには上記ステップＳ２１
にてブロードキャストする際に付加しておいた検索識別
ＩＤと、検索内容に合致するサービスレジストリのＩＤ
のリストや個数が含まれている。

【０１８３】最初のステップＳ４１においては、上記図
１２中のステップＳ２２で用意しておいた記録を用い、
検索識別ＩＤに対応するデータ構造のＩＤを特定し、そ
れが使用中であるかを確認する。ここで使用中というの
は、上記図１１中のステップＳ１６のリスト不要通知を
受けていないことを意味する。

【０１８４】検索識別ＩＤに対応するリストが使用中の
場合には、“ＹＥＳ”としてステップＳ４２以降の処理
を行うが、既にリスト不要通知を受けている場合には他
ノードの検索結果も不要なので“ＮＯ”としてこの一連
の工程を終了する。

【０１８５】ステップＳ４２においては、ステップＳ４
１で確認したデータ構造に対し、受け取った検索結果に
含まれるサービスモジュールのＩＤリストを追加する。
そして、次のステップＳ４３に進む。

【０１８６】ステップＳ４３においては、イベントマネ
ージャに対してデータ構造の内容に変更が生じたことを
示すイベントを通知することにより、そのデータ構造に
関心を持っているサービスモジュールが処理を行うため
の機会を提供する。このイベントのパラメータとしては
ステップＳ４２で変更したデータ構造のＩＤが含まれ
る。これにて、この一連の工程を終了し、次のメッセー
ジの処理に移る。

【０１８７】なお、ステップＳ４３においてはイベント
マネージャを利用したが、サービスレジストリ自体が検
索元のデータを記録しておき１対１通信によって通知す
るような変形例も可能である。

【０１８８】また、検索結果の要素数が０の場合には変
化は生じていないので、ステップＳ４３の通知は行う必
要がないのでその確認を行うことも考えられる。ただ
し、要素数の変化があったかどうかは利用側で確認する
ことも可能であるし、要素数０の場合にはそもそも検索
結果を通知しない変形例も考えられ、その場合には確認
は必須ではないので上記フローチャートには含めていな
い。

【０１８９】さらに、上記図１３中のステップＳ３２と
ステップＳ３３の間に所定の時間だけ他ノードからの返
事を待ち、一度検索元に検索結果を通知した後は追加処
理は行わないという変形例も考えられる。この場合ステ
ップＳ４１における使用中とは返答待ち期間中のことに
なり、ステップＳ４３は不要になる。

【０１９０】ステップＳ４３により、検索結果に変更が
あった場合に検索依頼元が行う処理は多様であり、状況
によって異なるのでフローチャートとして示すことはで
きない。例えば、先に言及したように使用中でないディ
スプレイを探すのが目的であれば既に見付けている場合
には何の処理も必要ないし、見つかっていない場合には
追加されたものに対するチェックを行うことになる。ま
た、全てのチューナーが提供できるチャンネル一覧を表
示するのが目的であれば追加されたチューナーのチャン
ネル情報を得るべく通信することになる。

【０１９１】続いて、検索結果変更のイベントを受けた
際の検索依頼元についての一連の工程を、図１５に示す
フローチャートを参照して説明する。

【０１９２】この一連の工程は、検索結果変更のイベン
ト通知を受けることにより開始される。すなわち、上記
図１４中のステップＳ４３でサービスレジストリがイベ
ントマネージャを利用した結果としてイベント通知を受
ける。もしくはサービスレジストリから直接メッセージ
で通知される。

【０１９３】イベントマネージャを使用する実装の場合
には、この通知を受けるためには上記図１１中のステッ
プＳ１４までにイベントマネージャに検索結果変更イベ
ントに対して興味があることを知らせておく必要があ
る。

【０１９４】最初のステップＳ５１においては、変更の
あったデータ構造のＩＤが自分の使用中のものかどうか
を確認する。これは主にイベント通知の場合にはイベン
トの種類だけで判断され、関係のないものに関しても通
知される可能性があるからである。サービスレジストリ
から直接通知される場合でもミスを避けるために確認し
て損はないが必須ではない。

【０１９５】そして、データ構造のＩＤが使用中のもの
であるときには“ＹＥＳ”としてステップＳ５２に進
み、そうでないときには“ＮＯ”としてこの一連の工程
を終了して次のメッセージの処理に移る。

【０１９６】ステップＳ５２においては、上述の通り、
状況に応じて必要な処理がなされる。そして、この一連
の工程を終了し、次のメッセージの処理に移る。

【０１９７】続いて、上記図１１中のステップＳ１６に
おけるリストの不要通知を受信したサービスレジストリ
についての一連の工程を、図１６に示すフローチャート
を参照して説明する。

【０１９８】この一連の工程は、上記ステップＳ１６で
検索依頼元が送ったリスト不要通知をサービスレジスト
リが受け取ることにより開始される。上記リストには、
メッセージのパラメータとしてリストとを特定するため
のＩＤが含まれている。

【０１９９】最初のステップＳ６１においては、リスト
のＩＤに対して不使用であることを示す情報を記憶す
る。これは他のノードのサービスレジストリからの検索
結果がいつ返ってくるか分からない状況においてステッ
プＳ４１での判断に使われることになる。ここで、情報
の記憶の仕方としては例えばＩＤに対して不使用フラグ
を立てることが考えられる。そして、次のステップＳ６
２に進む。

【０２００】ステップＳ６２においては、リスト自体を
破棄する。変形例としてはリストを破棄することはせ
ず、複数のリストをプールしておき再利用することが考
えられる。この場合には同一のオブジェクトＩＤやメモ
リのアドレスを再利用するため、リストのＩＤはサービ
スレジストリが管理するものになり、ここではリストの
内容を空にする処理が行われる。そして、この一連の処
理を終了し、次のメッセージの処理に移行する。

【０２０１】変形例としてはＩＤに対応するリストが存
在しない場合には不使用と判断することによってステッ
プＳ６１を省略し、ステップＳ６２だけを行うことが考
えられる。

【０２０２】次に、通信路上で検索要求等のメッセージ
のデータ形式や、各サービスレジストリが扱うデータ形
式について説明をする。様々な変形例が考えられるが基
本的に必要な情報の一例を示す。

【０２０３】単純な例として属性名と属性として任意の
文字列を持つ形で各サービスモジュール情報を持つ場合
は、図１７に示すように、複数の属性を一つのサービス
モジュールに対して与えたい場合には複数のエントリを
持つことになる。

【０２０４】このサービスレジストリの持つサービスモ
ジュールのデータベースの第１の例においては、図中横
方向には、左から右に順に“モジュールＩＤ”、“属性
名”及び“属性”の３つの列を有し、図中縦方向には、
モジュールＩＤ“１”に対して属性名“モジュールタイ
プ”及び属性“ブロードキャストマネージャ”が、モジ
ュールＩＤ“２”に対して属性名“モジュールタイプ”
及び属性“イベントマネージャ”が、モジュールＩＤ
“４”に対して属性名“モジュールタイプ”及び属性
“ネットワークマネージャ”が、モジュールＩＤ“１
１”に対しては属性名“モジュールタイプ”及び属性
“ディスプレイ”がそれぞれ対応して表示されている。

【０２０５】ここでモジュールＩＤとは、ノード内での
識別に使われるものであり、メッセージの宛先としても
使われることになる。

【０２０６】予め幾つかの属性を持つことを仮定して、
例えばタイプや表示するための名前は必ず持ち、任意個
数の追加属性を持ってもよい場合であれば図１８のよう
な形式になる。

【０２０７】このサービスレジストリの持つサービスモ
ジュールのデータベースの第２の例には、左から右に、
順に“モジュールＩＤ”、“モジュールタイプ”、“モ
ジュールネーム”、“属性数”、“属性数１”及び“属
性１”の６個の列を有し、図中縦方向には、モジュール
ＩＤ“１”に対してモジュールタイプ“１”、モジュー
ルネーム“ブロードキャストマネージャ”及び属性数
“０”が、モジュールＩＤ“２”に対してモジュールタ
イプ“２”、モジュールネーム“イベントマネージャ”
及び属性数“０”が、モジュールＩＤ“４”に対してモ
ジュールタイプ“３”、モジュールネーム“ネットワー
クメッセンジャ”及び属性数“０”が、モジュールＩＤ
“１１”に対してモジュールタイプ“１００”、モジュ
ールネーム“Ｄ−００１”、属性数“１”、属性名１
“サイズ”及び属性１“２１”がそれぞれ対応して表示
されている。

【０２０８】この場合、持つことが決まっている属性に
対して予め数字に意味を割り振ることにより、文字列を
記憶するのに比べ記憶領域を減らすことも考えられる。
図中においては、モジュールタイプに関して例えば“１
００”がディスプレイを示すことにより上記図１１の場
合と同様の情報を少ないバイト数で保持していることに
なる。

【０２０９】この例ではディスプレイである“Ｄ−００
１”は１個の追加属性を持ちそれは“サイズ”である
が、他のサービスモジュールは追加属性は持っていな
い。仮に“Ｄ−００１”が“ｂ／ｗ”か“カラー”かを
示す“カラー”という属性も持つとすれば、属性数は
“２”になることになる。

【０２１０】このようにあるタイプのサービスモジュー
ルに関しては、図１９に示すように、一般的な属性に対
しても予め属性タイプを数値で定義しておくことによっ
て記憶領域を更に減らす変形例も考えられる。

【０２１１】このサービスレジストリが持つサービスモ
ジュールのデータベースの第３の例においては、左から
右に、順に“モジュールＩＤ”、“モジュールタイ
プ”、“モジュールネーム”、“属性数”、“属性タイ
プ”、“属性名”及び“属性”の７個の列を有し、図中
の縦方向には、モジュールＩＤ“１”に対してモジュー
ルタイプ“１”、モジュールネーム“ブロードキャスト
マネージャ”及び属性数“０”が、モジュールＩＤ
“２”に対してモジュールタイプ“２”、モジュールネ
ーム“イベントマネージャ”及び属性数“０”が、モジ
ュールＩＤ“４”に対してモジュールタイプ“３”、モ
ジュールネーム“ネットワークメッセンジャ”及び属性
数“０”が、モジュールＩＤ“１１”に対してモジュー
ルタイプ“１００”、モジュールネーム“Ｄ−００
１”、属性数“３”、属性名タイプ“１０１”及び属性
“２１”が、次の行には属性タイプ“１０２”及び属性
“カラー”が、その次の行には属性タイプ“０”、属性
名“サウンド”及び属性“ステレオ”がそれぞれ表示さ
れている。

【０２１２】図中においては、属性タイプが“０”の場
合には未定義のタイプであり、属性名で区別する必要が
ある例を示している。この例においては属性タイプの
“１０１”は、サイズを意味し、“１０２”はカラーを
意味している。モジュールタイプの“１００”は図１２
と同様にディスプレイを意味している。複数の追加属性
を持つモジュラーの場合には続く属性数の後に可変長の
属性データが続くことになる。

【０２１３】この例では属性自体は全て文字列になって
いるが、属性タイプとして文字列以外の数値データであ
ることを示すようなフラグを付加することによって属性
として数値、例えば、整数、浮動小数点、ブーリアン、
列挙型等をとることもできるようにする変形例も考えら
れる。

【０２１４】上記図１２のフローチャートの入り口とな
る検索依頼メッセージのデータ形式はサービスレジスト
リの持つデータベースとどの程度複雑な検索を指定でき
るようにするかで変わってくるが、例えば上記図１７の
データベースに対して単純な検索だけを行う場合には図
２０のようになる。

【０２１５】図中には、横方向に左から右に“検索属性
名”及び“検索属性”の２つの列を有し、それぞれに対
応して、検索属性名“モジュールタイプ”及び検査属性
“ディスプレイ”がそれぞれ表示されている。

【０２１６】この場合の文字列の表現形式はノード内部
の処理系によって異なって構わない。例えば、先頭にバ
イト数を示すパスカル形式や文字列の終端を示すデータ
を付加するＣやＣ＋＋形式等がある。

【０２１７】上記図１７に示したサービスモジュールの
データベースの第１の例においては、属性名と属性は常
に文字列であることがわかっているのでこのような検索
依頼にて十分であるが、上記図１８に示した第２の例又
は図１９に示した第３の例のように、デは文字列以外の
データが含まれていることもある。したがって検索依頼
自体にその情報が含まれている必要がある。

【０２１８】そこで、文字列以外の情報を含む検索依頼
のメッセージのデータ形式を、図２１に示す。図中に
は、左から右に“検索属性タイプ”、“検索属性名”及
び“検索属性”の３個の列を有し、これらに対応して、
“検索属性タイプ“１０１”及び検索属性“２１”がそ
れぞれ示されている。なお、検索属性名に対応する欄は
空欄になっている。

【０２１９】ここで、検索属性では上記図１９に示した
データベース内の属性ＩＤと同じものである。検索属性
名は同図の例であれば検索属性タイプが０の場合のみ指
定されることになる。

【０２２０】またデータベースの例としては図示してい
ない検索属性に文字列以外のものを許すような変形例の
場合には、検索属性が文字列なのか数字なのかを示すた
めの属性タイプ情報を追加する必要がある。各データ型
を示す数値を予め割り当てておくのが効率的であるが、
拡張性を考慮して文字列を使うような変形例も有り得
る。

【０２２１】検索依頼の変形例としては、ＡＮＤ，Ｏ
Ｒ，ＮＯＴのような論理演算を含む複雑な検索を行える
ようにすること、特定のノード内のみ、指定したグルー
プに属するノード内のみ等の検索範囲を指定した検索を
行えるようにすること等があるが、ここでの説明は省略
する。

【０２２２】上記図１２に示した一連の工程において、
Ｓ２１の前のステップでサービスモジュールから検索依
頼を受けたサービスレジストリが図１９に示したような
データベースを持っていた場合に、ステップＳ２２で作
られる検索結果は例えば図２２のようになる。

【０２２３】すなわち、この検索結果リストは、図中の
左から右に、順に“該当モジュール数”、“該当モジュ
ールＩＤ１”の列を有している。そして、図中には、該
当モジュール数“１”及び該当モジュールＩＤ“１１”
がそれぞれ示されている。なお、該当モジュールＩＤの
欄は、複数個あってもよい。

【０２２４】ステップＳ２４で検索依頼元に通知される
のはこの検索結果全体を示す、例えば“２０１”のよう
なリストのＩＤだけであり、検索に該当したサービスモ
ジュールである“１１”ではない。

【０２２５】一方、ステップＳ２２で他のノードのサー
ビスレジストリにブロードキャストするメッセージは図
２３のようになる。

【０２２６】図中には、左から右に、順に“センダ（se
nder）ＩＤ”、“検索識別”、“検索内容”の欄を有
し、さらに上記“検索内容”の欄は、“検索属性Ｉ
Ｄ”、“検索属性名”及び“検索属性”の欄を有してい
る。そして、センダＩＤ“ＸＸＸＸＸＸＸＸ”、検索識
別ＩＤ“１２３４”、検索属性ＩＤ“１０１”及び検索
属性“２１”がそれぞれ表示されている。

【０２２７】この図に示したのはブロードキャストマネ
ージャにブロードキャストするように依頼する内容であ
り、ネットワークに流れるときにはにはブロードキャス
トマネージャがヘッダを付加することになる。上述した
ように、このヘッダには送信元のノードＩＤやブロード
キャストＩＤ等が含まれている。

【０２２８】ブロードキャストに対して結果を送り返す
際にノードＩＤとノード内でのモジュールＩＤが必要に
なるので、ノード内でのサービスレジストリのモジュー
ルＩＤであるセンダＩＤが図中に含まれている。

【０２２９】図中のメッセージに対する応答が返ってき
た時点で検索識別ＩＤに応じてどのリストに対して処理
をすればいいのかを覚えていく必要がある（上記図１４
中のステップＳ４１で参照される）が、そのためのデー
タは例えば図２４のようになる。

【０２３０】すなわち、図中には、左から右に、順に
“検索識別ＩＤ”、“検索結果のリストＩＤ”及び“不
要通知”の３個の欄を有し、検索識別ＩＤ“１２３４”
に対して検索結果のリストＩＤ“２０１”及び不要通知
“０（ＦＡＬＳＥ）”がそれぞれ表されている。

【０２３１】新しい検索識別ＩＤに対するエントリはス
テップＳ２１をブロードキャスト依頼した時点で用意さ
れ、ステップＳ２２で用意される検索結果のＩＤが記憶
されることになる。

【０２３２】上記図１４の処理が始まる前にデータベー
スが更新されていればいいので、実際にエントリーを追
加するタイミングは図１２に示したフローチャートの中
であれば何処でもよい。

【０２３３】ただし、サービスレジストリ相互の通信の
処理に関しては高い優先度を持たせるような変形例の場
合には、上記図１２中でステップＳ２１でブロードキャ
ストを依頼する前にステップＳ２２を実行し、データベ
ースの更新を終了しておくことが誤動作を防ぐ上では重
要になる。

【０２３４】上記図２３のメッセージを受け取ったサー
ビスレジストリの処理は上記図１３に示してある取りで
あり、内部的に作成する検索結果は上記図２２と同様で
ある。ここで出てくる新しいデータ形式としては、上記
図１３中のステップＳ３３で送る検索結果がリスト全体
を示すＩＤではなく、内容を含むものであるために通信
線を流れる図２５に示す形式のものがある。

【０２３５】同図のメッセージはブロードキャストでは
なく、１対１の通信としてブロードキャスト元のノード
のサービスレジストリ宛てに送られる。例えばノードＩ
Ｄ“ＡＡ”のブロードキャスト元のモジュールＩＤ“Ｘ
ＸＸＸＸＸＸＸ”のサービスレジストリ宛てに送られ
る。

【０２３６】この結果に含まれている“Ｂ１”から“Ｂ
ｎ”までのモジュールＩＤはサービスモジュールが属し
ているノード“ＢＢ”の中でのモジュールＩＤであり、
それ以外のノードにとっては意味は分からない只の数字
であるが、ノード“ＢＢ”宛てのメッセージのヘッダに
ノード内部での宛先として指定しておくことにより、ノ
ード“ＢＢ”のメッセンジャがメッセージの本体をその
サービスモジュールに届けることが保証されている。

【０２３７】これはサービスレジストリがブロードキャ
ストする際に返答先としてノード内のモジュールＩＤと
して指定していた“ＸＸＸＸＸＸＸＸ”に関しても同様
で他のノードは“ＸＸＸＸＸＸＸＸ”が何を意味するか
を知る必要はない。

【０２３８】ただし、ネットワークに接続されている全
てのノードが同様に扱う必要があるので、このモジュー
ルＩＤのビット長だけは例えば６４ｂｉｔ等に規定して
おく必要がある。

【０２３９】このネットワーク中でのモジュールＩＤと
ノード内部で使っているモジュールＩＤのサイズが異な
る場合には、サービスレジストリは外部に対して知らせ
た宛先としてのＩＤと内部でのモジュールＩＤの対応を
記録したデータベースを管理し、他のノードからのメッ
セージの配送の際にはメッセンジャーが参照する必要が
あるが、単純な対応関係を示したデータベースでもある
し、本論から外れるので説明は省略する。

【０２４０】同図のメッセージを受けた結果元々の検索
依頼を受けたノード“ＡＡ”のサービスレジストリは上
記図１４中のステップＳ４２において、自己のノード内
の検索結果である上記図２２にｎ個のモジュールＩＤを
追加して、図２６のように変更することになる。

【０２４１】図中には、左から右に、順に“該当モジュ
ール数”、“該当モジュールＩＤ１”、“該当モジュー
ルＩＤ２”、・・・、“該当モジュールＩＤｎ＋１”の
ｎ＋２個の欄を有し、該当モジュール数“２１”、該当
モジュールＩＤ１“１１”、該当モジュールＩＤ２“Ｂ
１´”、・・・、該当モジュールＩＤｎ＋１“Ｂｎ´”
がそれぞれ示されている。

【０２４２】ここで、図中においては、“Ｂ１”から
“Ｂｎ”ではなく、“Ｂ１′”から“Ｂｎ′”になって
いる理由は各ノード内でのモジュールＩＤの使い方は任
意であるため、ノード“ＢＢ”でのＩＤはそのままでは
ノード“ＡＡ”では別のサービスモジュールを指示して
しまうからである。

【０２４３】この“Ｂｉ”から“Ｂｉ′”へのもっとも
単純な変換はネットワーク中での通信に使われるモジュ
ールＩＤの前にノードＩＤを連結したものをノード内部
でのモジュールＩＤとして使い、自ノードの場合にはノ
ードＩＤとして使うことによって内部のサービスモジュ
ールと外部のサービスモジュールを区別して扱うことで
ある。この場合は図２７に示すような関係になる。

【０２４４】図中においては、左から右に、順に“ノー
ドＡＡでのモジュールＩＤ”、“ノードＩＤ”及び“サ
ービスモジュールの所属するノードでのモジュールＩ
Ｄ”の３個の列をそれぞれ有し、ノードＡＡでのモジュ
ールＩＤ“１１”に対しては、ノードＩＤ“０”及びサ
ービスモジュールの所属するノードでのモジュールＩＤ
“１１”、ノードＡＡでのモジュールＩＤ“Ｂ１´”に
対してはノードＩＤ“ＢＢ”及びサービスモジュールの
所属するノードでのモジュールＩＤ“Ｂ１”が、ノード
ＡＡでのモジュールＩＤ“Ｂｎ´”に対してはノードＩ
Ｄ“ＢＢ”及びサービスモジュールの所属するノードで
のモジュールＩＤ“Ｂｎ”がそれぞれ表示されている。
この図は、Ｂｉ´＝ＢＢ＊（位取り）＋Ｂｉであること
を示すものである。

【０２４５】しかしこれでは内部での自然なモジュール
ＩＤと外部のサービスモジュールを含む場合のモジュー
ルＩＤの扱いが異なり、内部のサービスモジュールに対
しても余分な記憶領域を使用しなければならない。

【０２４６】これを解決する変形例としては、例えば内
部のサービスモジュールとしては１００００未満のみを
用い、それ以上のモジュールＩＤは外部のサービスモジ
ュールを示すということにして、サービスレジストリ
が、自ノードのサービスモジュールの属性データベー
ス、検索識別ＩＤに関するデータベースに続く第３番目
のデータベースとして内部での自然な長さのモジュール
ＩＤと外部のモジュールＩＤ及び所属するノードＩＤの
情報を管理する方法がある。

【０２４７】この場合のデータベースは図の対応関係と
ほぼ同じになるが、自ノードに所属するサービスモジュ
ールに関するエントリは必要ないし、モジュールＩＤと
してはノードにとって自然な長さのものが使える点が違
う。図２８にこのようなデータベースの例を示す。

【０２４８】図中には、左から右に“ノードＡＡでのモ
ジュールＩＤ”、“所属するノードＩＤ”及び“所属す
るノードでのモジュールＩＤ”の３個の列を有し、ノー
ドＡＡでのモジュールＩＤ“Ｂ１´（＝１０００１）”
に対して所属するノードＩＤ“ＢＢ”及び所属するノー
ドでのモジュールＩＤ“Ｂ１”、ノードＡＡでのモジュ
ールＩＤ“Ｂｎ´（＝１００００＋ｎ）”に対して所属
するノードＩＤ“ＢＢ”及び所属するノードでのモジュ
ールＩＤ“Ｂｎ”がそれぞれ示されている。

【０２４９】メッセンジャがメッセージを配送する際に
は最初に宛先のモジュールＩＤが概定値（例えば１００
００）以上であるかどうかを確認し、それ未満であれば
そのままノード内部のサービスモジュールに配送し、そ
れ以上であればサービスレジストリに実際のモジュール
ＩＤと所属するノードＩＤを問い合わせた上で宛先のノ
ードのメッセンジャと協力して配送することになる。

【０２５０】上記図１４中のステップ４３のイベントの
パラメータは検索検索のＩＤだけであるので、図２２か
ら図２６に変わった場合であれば、図２９のようにな
る。

【０２５１】図中には、左から右に“イベントタイプ”
及び“パラメータ”の欄を有し、このパラメータの欄に
は“検索結果のＩＤ”が示されている。そして、イベン
トタイプ“サーチリザルトアップデート（SearchResult
Update）”に対して検索結果のＩＤ“２０１”が表示さ
れている。

【０２５２】また、上記図１１中のステップＳ１６にて
検索依頼元が送り、図１６中のステップＳ６１の前にサ
ービスレジストリが受けるメッセージのパラメータも検
索結果のＩＤだけであるので、一連の例の場合であれば
図３０のようになる。

【０２５３】このメッセージを受けたサービスレジスト
リは図２４の対応するエントリの不要通知をＴＲＵＥに
変更し、ＩＤが２０１である不要になったリストを破棄
することになる。

【０２５４】図２８のデータベースを使用している場合
には、この際にリストに含まれている外部のモジュール
ＩＤに対応するエントリをデータベースから削除するこ
とになる。

【０２５５】以上説明したように各ノードに存在するサ
ービスレジストリは協調作業を行いながら、他のサービ
スモジュールに対してはネットワークを意識する必要が
ないようにしている。

【０２５６】次に、上述したような１対１通信及びブロ
ードキャストによるメッセージのデータの具体的な形式
について説明する。

【０２５７】オブジェクトサービスモジュールからイベ
ントマネージャ及びサービスレジストリに送出するメッ
セージは、図３１に示すように、宛先、送信元を特定す
るヘッダと、メッセージの内容を特定するメッセージタ
イプのデータ、パラメータ長と示すデータ、メッセージ
に付随するパラメータを示すデータにより構成される。

【０２５８】オブジェクトは、イベントを通知する場
合、宛先のイベントマネージャは、メッセージタイプの
部分にイベント通知を割り当て、イベント番号、イベン
トパラメータによりメッセンジャに依頼する。

【０２５９】メッセンジャは、機器内のサービスモジュ
ール間における送信先が１つの特定されているメッセー
ジの送受信を管理する。すなわち各メッセンジャは、各
サービスモジュールに設定されたＩＤと、ヘッダに設定
された宛先のＩＤを基準にして、対応する宛先に各メッ
セージを通知する。この時メッセンジャは、対応するサ
ービスモジュールが処理中の場合、このサービスモジュ
ールに対する要求が失われないように、メッセージを保
持する。

【０２６０】なお、メッセンジャは、例えば各メッセー
ジを一旦メモリに保持し、又は一連のメッセージの宛先
を基準にしてアドレス間でリンクを形成し、このリンク
のリストを管理することにより、各メッセージを対応す
るサービスモジュールに提供する。

【０２６１】これによりこれらサービスモジュール間に
おけるメッセージの伝送において、メッセンジャは、い
わゆる１対１通信により１の伝送元から送出したメッセ
ージを１の伝送先に送信するようになされている。

【０２６２】イベントマネージャは、メッセンジャを介
して入力されるイベントメッセージを対応する機器内の
サービスモジュールに配送し、またブロードキャストマ
ネージャを利用する。

【０２６３】ここでサービスリストは、各イベントの通
知を必要とするオブジェクトのリストであり、メッセン
ジャを介して通知される所定のメッセージにより更新さ
れる。サービスレジストリは、機器内サービスモジュー
ルのリストであり、サービス検索の際にブロードキャス
トマネージャが利用する。

【０２６４】このサービスリストは、図３２に示すよう
に、イベントの種類を示すイベント番号と、対応する宛
先とを配列して形成される。

【０２６５】イベントマネージャは、このサービスリス
トにしたがって、メッセンジャより取得したイベント情
報のメッセージを配送する。すなわち、イベントマネー
ジャは、“イベント１”について、“オブジェクト１”
及び“オブジェクト２”を宛先にする旨、宛先リストが
形成されている場合、通知されたメッセージを形成し、
この２つのメッセージをメッセンジャに送信する。

【０２６６】これに対して“イベント２”に対応する
“メッセージ２”については、いずれのサービスモジュ
ールにも配送することなくこのメッセージを処理する。
さらにこのときイベントマネージャは、オブジェクトか
らブロードキャストの依頼があったと判断し、イベント
マネージャは、サービスリストに基づいてこのメッセー
ジを配送すると共に、ブロードキャストマネージャにこ
のメッセージのブロードキャストを依頼する。

【０２６７】これによりテレビジョン受像器、ビデオテ
ープレコーダでは、１対１通信又は１対多通信により得
られる各種イベント情報を対応するサービスモジュール
に発送するようになされている。かくするにつきテレビ
ジョン受像器、ビデオテープレコーダでは、機器内にお
いては、１対１通信によりメッセージが配送され、イベ
ントマネージャは、単に複数の宛先に同一のメッセージ
を送信することになる。

【０２６８】このようにしてメッセージを配送するにつ
き、イベントマネージャは、サービスリストに従って、
宛先を特定してメッセージを操守する場合、メッセンジ
ャに対してこのメッセージを送出する。メッセンジャ
は、宛先が機器内か否かを判断し、機器外の不特定多数
が宛先のメッセージの場合、ブロードキャストマネージ
ャにメッセージを送出する。

【０２６９】イベントマネージャは、このようにブロー
ドキャストマネージャ等にメッセージを送出する場合、
図３３中のＡに示すようなメッセンジャにより通知され
たメッセージの内容を転送する。これによりイベントマ
ネージャは、ブロードキャストマネージャ等からは、同
図中のＢに示すように、オブジェクトよりメッセージの
通知を受ける場合と同一の形式により、メッセージの通
知を受け付ける。

【０２７０】このようにしてメッセージを配送するにつ
き、イベントマネージャは、受信したメッセージのメッ
セージタイプを確認する。さらにイベントマネージャ
は、メッセージタイプによって、受信したメッセージが
オブザーブのメッセージと判断すると、このメッセージ
の内容に従ってサービスリストを更新する。これにより
ビデオテープレコーダ等では、ネットワークに新たに機
器が接続された場合等において、サービスリストを更新
することにより、この増設された機器に対して種々のイ
ベントを通信できるようになされている。

【０２７１】図３４は、このようなオブザーブの通知に
使用されるメッセージのデータ形式を示す図である。な
おこの図は、メッセージ部だけについて示す。このオブ
ザーブのメッセージは、機器内外のオブジェクトにより
必要に応じて生成され、例えばネットワークへの機器の
接続が物理的に検出された場合に、この新たに増設され
た機器との間で、また既にネットワークに接続されてい
る機器との間で、ネットワークメッセンジャを介して、
又はブロードキャストマネージャを介してイベントマネ
ージャに通知される。

【０２７２】ここでこの一連のメッセージは、上記図３
１及び図３３中のＡに示したように、メッセンジャを介
してサービスモジュール間で一般に送受されるメッセー
ジに対してパラメータを拡大して形成される。すなわち
サービスリストへのオブザーバの登録を求めるメッセー
ジは、図３４中のＡに示すように、メッセージタイプに
オブザーバのタイプを示す３２ビットのデータが割り当
てられ、通知を求めるイベント番号、通知先を示すオブ
ザーバがパラメータに設定される。これに対して登録を
取り消すメッセージは、同図中のＢに示すように、メッ
セージタイプに取り消しを示すタイプのデータが割り当
てられ、取り消しを求めるイベント番号、取り消す通知
先を示すオブザーバがパラメータに設定される。

【０２７３】またイベントマネージャは、サービスリス
トの更新に伴い、登録、取り消しを求めるサービスモジ
ュールに対して、同様の形式により要求確認を示す応答
のメッセージを配送する。またブロードキャストマネー
ジャを介して通知されたメッセンジャや機器内でのイベ
ント通知に対して、同様に応答確認を示す応答のメッセ
ージを配送する。ここでイベント通知を受け取った場合
には、サービスレジストリに従ってイベント発生を通知
する。このときこの通知は、イベント発生通知であるこ
とが、同図中のＣに示すように、続いて可変長によるパ
ラメータ長のデータ、パラメータ長のデータ、パラメー
タのデータにより構成される。

【０２７４】メッセンジャは、保持した外部機器ＩＤの
リストを検索し、この外部機器ＩＤに従って伝送モジュ
ールを介してネットワークにメッセージを送出する。こ
のときメッセンジャはメッセージをネットワーク上での
所定の形式に変換し、このメッセージを伝送モジュール
に通知する。

【０２７５】ここでこの所定の形式は、図３５中のＡ及
びＢに示すように、ネットワークに接続された各ノード
の機器で処理可能な、これらの機器に共通するパケット
の形式であり、例えば同図に示すような形式である。す
なわちメッセンジャは、メッセージをメッセージ部に設
定し、このメッセージ部にヘッダを付加してパケットを
形成する。

【０２７６】ここでこのヘッダは、送信先でなる目的ノ
ードが例えばＩＰアドレスであれば、ネットワークによ
り異なるが例えば３２ビットのデータにより記述され、
このパケットタイプによって特定対象に送出する送信の
パケット、外部機器からの要求に応答して要求を発行し
た特定対象に発信する応答のパケット、ネットワークに
接続された各機器に対する各機器のパケット等を識別で
きるようになされている。なおブロードキャストによる
場合、この種の伝送モジュールに提供するパケットは、
ネットワークメッセンジャに替えてブロードキャストマ
ネージャが生成することになる。

【０２７７】さらにヘッダは、送信のパケットと応答の
パケットの対応を特定するためのメッセージＩＤが付加
される。さらにヘッダは、目的ノードの内部における識
別用のＩＤが３２ビットのデータにより記述され、この
目的ＩＤによって目的ノードの機器において、機器内の
いずれかのオブジェクトに対する応答かを特定できるよ
うになされている。

【０２７８】さらにメッセンジャは、伝送モジュールよ
り入力されるパケットを取得し、自己の機器を目的ノー
ドに設定したパケットを選択して、このパケットのメッ
セージを送出する。これによりメッセンジャは、機器内
オブジェクトのメッセージを外部機器に出力し、またこ
れとは逆に外部機器より通知されたメッセージを機器内
オブジェクトに通知する。

【０２７９】またメッセンジャは、イベントマネージャ
及びサービスレジストリと同様に、受信したメッセージ
によって保持した外部機器ＩＤのリストを更新する。こ
れによりビデオテープレコーダ等においては、増設され
た機器等に対しても、１対１通信により種々のメッセー
ジを伝送できるようになる。

【０２８０】ブロードキャストマネージャは、イベント
マネージャ及びサービスレジストリよりメッセージを受
け、伝送モジュールを介してこのメッセージをネットワ
ークにブロードキャストする。さらにブロードキャスト
マネージャは、このブロードキャストをしたメッセージ
に関連する一連のメッセージを伝送モジュールを介して
ネットワークに送出する。

【０２８１】またこれとは逆に、ブロードキャストマネ
ージャは、他の機器よりネットワークにブロードキャス
トされたメッセージ、さらにはブロードキャストに関連
するメッセージを伝送モジュールより取得し、イベント
マネージャ及びサービスレジストリに通知する。

【０２８２】次に、テレビジョン受像器、ビデオテープ
レコーダ等の電子機器に備えられ、これら電子機器の全
体を制御するＣＰＵの操作状態について説明する。

【０２８３】ここで例示するＣＰＵは、消費電力を変更
する電力モードとしては、フルスピードモード（Fullsp
eed Mode）、スタンバイモード（Standby Mode）、サス
ペンドモード（Suspend Mode）、ハイバーネートモード
（Hibernate Mode）の４種類を有するものである。

【０２８４】フルスピードモードは、通常の動作モード
であり、図３６に示すように、全ての内部クロックが設
定された周波数で動作する。図中において上から下へ、
ＣＰＵに供給されるクロック信号であるマスタークロッ
ク（MasterClock）と、ＣＰＵの各部の信号であるマス
ターアウト（MasterOut）、Ｔクロック（TClock）及び
Ｐクロック（PClock）とのそれぞれの波形を示す。この
フルスピードモードにおいては、上記のいずれの信号も
動作している。

【０２８５】ハイバーネートモードにおいては、図３７
に示すように、ＣＰＵ内で生成される全てのクロックが
全てハイレベルに固定されて停止する。図中では、ＣＰ
Ｕに供給されるクロック信号であるマスタークロックを
除いたマスターアウト、Ｔクロック及びＰクロックがハ
イレベルに固定されて停止している。

【０２８６】なお、図中のリセット（Reset）及びコー
ルドリセット（ColdReset）は、ハイバーネートモード
からフルスピードモードへのモード移行のシーケンスを
示すものである。

【０２８７】また、図示しないが、スタンバイモードは
タイマ／割り込みクロックを除く内部クロックが全てハ
イレベルに固定されて停止するモードであり、上記図３
６においてはＰクロックがハイレベルに固定される。

【０２８８】サスペンドモードは、タイマ／割り込みを
除く内部クロックとＴクロックが全てハイレベルに固定
され、停止するモードであり、上記図３６においてはＴ
クロック及びＴクロックがハイレベルに固定される。

【０２８９】このように、このＣＰＵにおいては、所定
の内部クロックを停止させることにより消費電力を低減
するモードを有している。すなわち、フルスピードモー
ド、スタンバイモード、サスペンドモード及びハイバー
ネートモードの順に、停止される種類が増加するので、
消費電力が削減される。

【０２９０】したがって、テレビジョン受像器、ビデオ
テープレコーダ等の電子機器においては、ＣＰＵが通常
に動作することが必要であるとき以外にはＣＰＵをフル
スピードモード以外の他の電力モードの移行させて待機
状態あるいは停止状態とすることにより、消費電力の低
減を図ることができる。

【０２９１】次に、記録媒体について説明する。記録媒
体は、単数又は複数の制御対象の属性情報を取得する属
性情報取得手順と、上記属性情報取得手順にて取得した
属性情報を他の電子機器に送出して外部からの上記属性
情報についての照会に対する応答を委託してから電源を
停止状態にする属性情報管理手順とを有するプログラム
が記録されたものである。

【０２９２】また、記録媒体は、単数又は複数の制御対
象の属性情報を取得すると共に他の電子機器から委託さ
れた場合には上記他の電子機器の制御対象の属性情報を
も併せて取得する属性情報取得手順と、上記属性情報取
得手順にて取得した属性情報について、上記他の電子機
器から委託された場合には上記他の電子機器の制御対象
の属性情報についても、外部からの照会に応答する属性
情報管理手順とを有するプログラムが記録されたもので
ある。

【０２９３】この記録媒体は、上記プログラムが記録さ
れたいわゆるＣＤ−ＲＯＭやＭＯとして提供される。ま
た、このプログラムは、通信回線等の媒体を介して供給
される。

【０２９４】以上述べたように、この発明に係る電子機
器、電源制御方法及び記録媒体は、、例えばＡＶシステ
ムを構成する各映像機器等に適用することができる。し
たがって、この発明は、ネットワークに対してメッセー
ジをブロードキャストする情報ブロードキャスト手段
と、装置内において、メッセージの配送を担当するイベ
ントマネージャーとを配置することにより、機器内のオ
ブジェクトから見て、機器内外を区別することなく、ま
た特定対象、不特定対象を区別することなくメッセージ
の送受信をできるようにし、その分伝送に供する情報信
号に対してネットワークを充分な時間開放することがで
きるようにする。

【０２９５】また、外部からの電源投入を意味するメッ
セージに対応するための方法としては、通常のメッセン
ジャを動かしておく方法もあるが、ＣＰＵがメッセージ
毎に使用のソフトウェアを走らせなくてもよいように通
信用のハードウェアで電源投入のメッセージのみを解釈
して、ＣＰＵを含む本体部分の電源投入を行うことも考
えられる。

【０２９６】さらに、各ノードが、ノード内のサ−ビス
モジュールのリストを管理し、不特定の機器に対するを
利用した検索に答えるサービスレジストリを持ち、通常
のサービスモジュールは オブジェクトはサービスレジ
ストリを利用して必要なサービスモジュールを見つける
構成のＡＶネットワークにおいて、使用中のサービスモ
ジュールを持たない機器の電源を落しても他の機器のサ
ービスモジュールが必要なサービスモジュールを見付け
て利用できるように、電源を切る処理中にサービスレジ
ストリが他の機器のサービスレジストリにリストの内容
を知らせて検索に対する応答を委任し、委任されたサー
ビスレジストリは検索に対して委任されたリスト中のサ
ービスモジュールが必要になった際に同時に委任元のサ
ービスレジストリを持つノードの電源を入れるようにす
るものである。

【０２９７】

【発明の効果】上述のように、この発明に係る電子機
器、電源制御方法及び記録媒体においては、他のノード
のサービスモジュールに検索に対する応答を委任するこ
とによって、ブロードキャストメッセージ処理する必要
もなくなり、ＣＰＵも止めることができるので電力消費
を押さえることができる。

【０２９８】また、この発明に係る電子機器、電源制御
方法及び記録媒体においては、分散処理をしている場合
には通常はサービスモジュールを持つ機器自体が検索に
対応することになるので正当性が保証しやすい。さら
に、電源を落すために委任している場合であっても、正
当性のチェックは電源を落してから電源が入るまでの短
時間のプロキシィを委任されているときにだけサービス
モジュールを持つ機器のサービスレジストリに対する問
い合わせにして検索を転送すればいいので、全体として
は正当性のチェックを簡略にすることができる。

【図面の簡単な説明】

【図１】ネットワークに接続された電子機器の概略的な
構成を示すブロック図である。

【図２】電源遮断直前の検索代行依頼に係る一連の工程
を示すフローチャートである。

【図３】図２に続く工程を示すフローチャートである。

【図４】検索を行う属性情報に関するデータベースを示
す図である。

【図５】検索代行依頼のためにサービスレジストリがブ
ロードキャストするメッセージを示す図である。

【図６】代理検索を受けているサービスレジストリの検
索依頼に係る一連の工程を示すフローチャートである。

【図７】ブロードキャストの検索要求に対する複数ノー
ドの検索結果を示す図である。

【図８】他のサービスモジュールとの通信を行うために
サービスレジストリを使う変形例の一連の工程を示すフ
ローチャートである。

【図９】ビデオテープレコーダの再生ボタンを押圧した
際の一連の工程を示すフローチャートである。

【図１０】図９に続く工程を示すフローチャートであ
る。

【図１１】他のサービスモジュールと通信を行うために
サービスレジストリを使う際の一連の工程を示すフロー
チャートである。

【図１２】同一モード内のサービスモジュールから検索
要求を受け付けた際の一連の工程を示すフローチャート
である。

【図１３】他ノードのサービスレジストリからの検索要
求受信時の一連の工程を示すフローチャートである。

【図１４】他ノードのサービスレジストリからの検索結
果受信時の一連の工程を示すフローチャートである。

【図１５】検索結果変更のイベント受けた際の検索結果
依頼もとの一連の工程を示すフローチャートである。

【図１６】検索依頼元のサービスレジストリからのリス
ト不要通知受信時の一連の工程を示すフローチャートで
ある。

【図１７】サービスレジストリの有するサービスモジュ
ールのデータベースの第１の例を示す図である。

【図１８】サービスレジストリの有するサービスモジュ
ールのデータベースの第２の例を示す図である。

【図１９】サービスレジストリの有するサービスモジュ
ールのデータベースの第３の例を示す図である。

【図２０】サービスモジュールからサービスレジストリ
への検索依頼のメッセージの第１の例を示す図である。

【図２１】サービスモジュールからサービスレジストリ
への検索依頼のメッセージの第２の例を示す図である。

【図２２】サービスモジュールが作成する検索結果のメ
ッセージの一例を示す図である。

【図２３】サービスレジストリがブロードキャストする
検索依頼の転送のメッセージの一例を示す図である。

【図２４】検索識別ＩＤ対してサービスレジストリが保
持しているデータベースの一例を示す図である。

【図２５】ブロードキャストの検索要求に対する検索結
果のメッセージの一例を示す図である。

【図２６】サービスレジストリが作成する検索結果のメ
ッセージの一例を示す図である。

【図２７】ノードＩＤを付加したモジュールＩＤの一例
を示す図である。

【図２８】内部でのモジュールＩＤと外部でのモジュー
ルＩＤとノードＩＤに関するデータベースを示す図であ
る。

【図２９】検索結果不要通知のメッセージを示す図であ
る。

【図３０】検索を行う属性情報に関するデータベースを
示す図である。

【図３１】オブジェクトより送出されるメッセージを示
す図である。

【図３２】イベントマネージャのサービスリストを示す
図である。

【図３３】イベントマネージャよりブロードキャストマ
ネージャに通知されるメッセージを示す図である。

【図３４】サービスリストの登録等に関するメッセージ
を示す図である。

【図３５】メッセンジャから伝送モジュールに送出する
パケットの説明に供する図である。

【図３６】フルスピードモードにおけるＣＰＵの信号の
タイミングチャートである。

【図３７】ハイバーネートモードにおけるＣＰＵの信号
のタイミングチャートである。

【符号の説明】

２ テレビジョン受像器、３ ビデオテープレコーダ、
２Ａ，２Ｂ，３Ａ，３Ｂ オブジェクト、２Ｃ，３Ｃ
メッセンジャ、２Ｄ，３Ｄイベントマネージャ、２Ｅ，
３Ｅ サービスレジストリ、２Ｉ，３Ｉ 伝送モジュー
ル、２Ｊ，３Ｊ パワーマネージャ

Claims (10)

【特許請求の範囲】
1. 【請求項１】 単数又は複数の制御対象を制御する電子
   機器において、 上記制御対象の属性情報を保持する属性情報保持手段
   と、 上記属性情報保持手段を管理し、上記属性情報保持手段
   の保持する属性情報を他の電子機器の備える属性情報管
   理手段に送出して外部からの上記属性情報についての照
   会に対する応答を委託してから電源を停止状態にする属
   性情報管理手段とを有することを特徴とする電子機器。
2. 【請求項２】 上記電源の停止状態は、上記電子機器の
   備えるＣＰＵを停止させると共に消費電力を抑えた待機
   状態とすることを特徴とする請求項１記載の電子機器。
3. 【請求項３】 単数又は複数の制御対象を制御する電子
   機器において、 上記制御対象の属性情報を保持し、他の電子機器からの
   委託に応じて上記他の電子機器の制御対象の属性情報を
   も併せて保持する属性情報保持手段と、 上記属性情報保持手段を管理して上記属性情報保持手段
   の保持する属性情報について、上記他の電子機器から委
   託された上記他の電子機器の制御対象の属性情報につい
   ても、外部からの照会に応答する属性情報管理手段とを
   有することを特徴とする電子機器。
4. 【請求項４】 上記属性情報管理手段は、上記属性情報
   保持手段の保持する属性情報を、上記他の電子機器から
   の委託に応じて上記属性情報保持手段の保持する上記他
   の電子機器の制御対象の属性情報をも、上記他の電子機
   器以外の他の電子機器に送出して外部からの照会に対す
   る応答を委託してから電源を停止状態にすることを特徴
   とする請求項３記載の電子機器。
5. 【請求項５】 上記電源の停止状態は、上記電子機器の
   備えるＣＰＵを停止させると共に消費電力を抑えた待機
   状態とすることを特徴とする請求項４記載の電子機器。
6. 【請求項６】 単数又は複数の制御対象の電源を制御す
   る電源制御方法において、 上記制御対象の属性情報を取得する属性情報取得工程
   と、 上記属性情報取得工程にて取得した属性情報を管理し、
   上記属性情報を他の電子機器に送出して外部からの上記
   属性情報についての照会に対する応答を委託してから電
   源を停止状態にする属性情報管理工程とを有することを
   特徴とする電源制御方法。
7. 【請求項７】 単数又は複数の制御対象の電源を制御す
   る電源制御方法において、 上記制御対象の属性情報を取得し、他の電子機器からの
   委託に応じて上記他の電子機器の制御対象の属性情報を
   も併せて取得する属性情報取得工程と、 上記属性情報取得工程にて取得した属性情報について、
   上記他の電子機器から委託された上記他の電子機器の制
   御対象の属性情報についても、外部からの照会に応答す
   る属性情報管理工程とを有することを特徴とする電源制
   御方法。
8. 【請求項８】 上記属性情報管理工程は、上記属性情報
   取得工程にて取得した属性情報を、上記他の電子機器か
   らの委託に応じて上記他の電子機器の制御対象の属性情
   報をも、上記他の電子機器以外の他の電子機器に送出し
   てこれらの属性情報について外部からの照会に対する応
   答を委託してから電源を停止状態にすることを特徴とす
   る請求項７記載の電源制御方法。
9. 【請求項９】 単数又は複数の制御対象の属性情報を取
   得する属性情報取得手順と、 上記属性情報取得手順にて取得した属性情報を他の電子
   機器に送出して外部からの上記属性情報についての照会
   に対する応答を委託してから電源を停止状態にする属性
   情報管理手順とを有するプログラムが記録された記録媒
   体。
10. 【請求項１０】 単数又は複数の制御対象の属性情報を
    取得すると共に他の電子機器からの委託に応じて上記他
    の電子機器の制御対象の属性情報をも併せて取得する属
    性情報取得手順と、 上記属性情報取得手順にて取得した属性情報について、
    上記他の電子機器からの委託された上記他の電子機器の
    制御対象の属性情報についても、外部からの照会に応答
    する属性情報管理手順とを有するプログラムが記録され
    た記録媒体。