JP3464174B2

JP3464174B2 - 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法

Info

Publication number: JP3464174B2
Application number: JP24399199A
Authority: JP
Inventors: 靖明山岸; 和彦高林; 和生原岡; 善久権野; 郁彦西尾
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1999-08-30
Filing date: 1999-08-30
Publication date: 2003-11-05
Anticipated expiration: 2019-08-30
Also published as: JP2001067259A

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、階層構造を有す
ると共に、ネットワーク上に分散されて配置されたデー
タを一斉同報的に配信する際に用いて好適な送信装置お
よび送信方法、受信装置および受信方法、ならびに、送
受信システムおよび送受信方法に関する。

【０００２】

【従来の技術】データの配信方法としては、種々の方法
が提案されており、例えば、現在のインターネット上に
おいては、ｈｔｔｐ(Hyper Text Transfer Protocol)の
ような、ＴＣＰ／ＩＰ(Transmission Control Protocol
/Internet Protocol) を基本とするプロトコルが採用さ
れている。ＴＣＰ／ＩＰでは、データの配信を受ける受
信側からデータのデータの送信側に対して発呼が行わ
れ、さらに、データの送受信を行う毎に、送信側と受信
側との間でコネクションが確立されるようになってい
る。そのため、信頼性の高いデータの配信を行うことが
できる。その反面で、送信側やネットワークの負荷が大
きくなり、効率的なデータ配信を行うことが困難になる
場合があった。

【０００３】すなわち、データの提供を受ける端末が増
加し、データを提供するサーバへのアクセスが集中する
と、サーバやネットワークに多大な負荷がかかり、デー
タを要求しても、そのデータを得るまでに多大な時間を
要することがあった。

【０００４】そこで、データの配信を、例えば、広い地
域にわたって一斉同報が可能な衛星回線やＣＡＴＶ(Cab
le Television)回線、実用化が予定されている地上波デ
ィジタル放送などを用いて行う方法が提案されている。
この場合、端末の増加によって、サーバやネットワーク
に対する負荷が影響を受けることがない。

【０００５】一方、近年では、インターネットなどディ
ジタル通信ネットワークの発達により、ネットワーク上
に膨大なデータが蓄積されるようになり、この膨大なデ
ータを効率的に利用することが求められている。そこ
で、ネットワーク上に分散されて存在するデータを階層
的に管理し、ユーザに提供する、ディレクトリサービス
が注目を集めている。ディレクトリサービスを利用する
ことで、ユーザは、ネットワーク上に分散して存在する
情報の中から、自分が必要な情報を素早く見つけ出し、
アクセスすることが可能になる。

【０００６】ディレクトリサービスは、例えば、国際標
準であるＯＳＩ(Open Systems Interconnection)などに
よって、Ｘ．５００シリーズとして規定されている。
Ｘ．５００によれば、ディレクトリについて、開放型シ
ステムの集合体であり、各開放型システムが協調して、
現実世界のオブジェクトの集合に関する情報の、論理的
なデータベースを持つと定義されている。

【０００７】Ｘ．５００による主なディレクトリサービ
スによれば、ディレクトリが擁する情報の検索や閲覧を
行うことができる。また、例えば電話帳に例えられる一
覧やユーザの認証などもディレクトリサービスで提供さ
れる。さらに、ディレクトリサービスでは、特に人間の
ユーザにとって覚え易く、推測ならびに認識し易いよう
に、オブジェクトの名前が付けられる。

【０００８】なお、このＸ．５００によるディレクトリ
サービスは、極めて包括的なものであって、プログラム
サイズが非常に大きく、ＴＣＰ／ＩＰをプロトコルとす
るインターネットでは実現が非常に難しい。そのため、
ＬＤＡＰ(Lightweight Directory Access Protocol) と
いった、ＴＣＰ／ＩＰ向けに軽量化されたディレクトリ
サービスが提案されている。

【０００９】ディレクトリサービスでは、ツリー構成か
らなるディレクトリ構造に基づきデータが管理される。
ディレクトリ構造は、データとデータとの節点に相当す
るコンテナエントリと、ツリーの末端であり、実体的な
データを持つリーフエントリとからなる。コンテナエン
トリは、自分の配下に他のコンテナエントリおよびリー
フエントリを持つことができる。リーフエントリは、配
下に他のエントリを持つことができない。ツリー全体を
表すエントリは、ルートエントリと称される。

【００１０】一例として、コンテナエントリによってジ
ャンルによる分類がなされ、リーフエントリに、直上の
コンテナエントリが表すジャンルのより具体的なデータ
が含まれる。

【００１１】近年では、上述した一斉同報を行うデータ
伝送手段、すなわち、衛星回線やＣＡＴＶ回線、地上波
ディジタル放送などで、上述のディレクトリサービスを
行うことが提案されている。この場合には、ディレクト
リサービスによる情報が一方向的に提供され、ユーザ側
からの情報の要求ができない。したがって、ディレクト
リサービスによるディレクトリ情報は、同一の情報が繰
り返し送信される。ユーザ側では、送信されてきた情報
を、例えばテレビジョン受像機などに接続して用いられ
る、ディジタル放送用受信機であるＩＲＤ(Integrated
Reciever Decoder) や、ＳＴＢ(Set Top Box) に蓄積す
る。

【００１２】ここで、ディレクトリサーバ側とユーザ側
との、情報の同期、すなわち同期管理について考える。
ディレクトリサーバ側では、実体的なディレクトリの更
新を検知し、ディレクトリの階層構造の動的な変化に対
応する。ディレクトリの階層構造の変化を反映させたデ
ィレクトリ情報を、ユーザに対して送信する。このと
き、全てのディレクトリ情報を送信するのではデータ量
が膨大になるので、変化の差分だけが抽出されて送信さ
れる。

【００１３】ディレクトリサーバ側では、ディレクトリ
情報の更新を検知する度に、あるいは、一定期間毎に、
ユーザに対して差分更新データを送信する。ユーザ側が
ディレクトリの更新に基づく差分更新データを常に受信
し、受信された差分更新データで蓄積されたディレクト
リ情報を更新することで、ディレクトリサーバとユーザ
との間で、ディレクトリ情報の同期を取ることができ
る。

【００１４】このとき、ユーザ側において、例えば受信
機の電源が投入されていないなどの何らかの理由により
休止状態とされ、ディレクトリサーバからの差分更新デ
ータが一定期間、受信できなかったとする。例えば、図
３６に示されるように、ディレクトリサーバからは、差
分更新データＭｓｇ１、Ｍｓｇ２およびＭｓｇ３が順に
送信されている。差分更新データＭｓｇ２は、差分更新
データＭｓｇ１によって更新されたディレクトリ情報に
対する差分であり、差分更新データＭｓｇ３は、差分更
新データＭｓｇ２によって更新されたディレクトリ情報
に対する差分である。

【００１５】一方、受信側が図３６の中央付近に示され
るように休止状態となっている場合、受信側は、差分更
新データＭｓｇ２が取得できていない。このような場
合、受信側では、差分更新データＭｓｇ３を用いて差分
更新データＭｓｇ１を更新することになり、正しく更新
がなされずに、ディレクトリサーバと受信機との間で、
情報に不整合が発生する可能性がある。

【００１６】

【発明が解決しようとする課題】しかしながら、上述し
たリーフエントリが更新される場合には、差分更新デー
タＭｓｇ３による差分更新処理が必ずしも差分更新デー
タＭｓｇ２を必要としていない場合が有り得る。その例
を図３７に示す。図中、塗り潰された四角がリーフエン
トリ、白抜きの四角がコンテナエントリをそれぞれ表
す。丸で囲まれたコンテナエントリは、ユーザが興味を
持っているジャンルであることを示す。

【００１７】図３７Ａは、初期状態であり、コンテナエ
ントリＢが配下にリーフエントリＢ．ｂを持ち、コンテ
ナエントリＡが配下にリーフエントリＡ．ａを持ってい
る。ユーザは、丸で囲まれた、コンテナエントリＢのジ
ャンルに興味があり、コンテナエントリＡのジャンルに
は興味が無いとする。この図３７Ａの状態に対して、差
分更新情報Ｍｓｇ２による変更が加えられ、コンテナエ
ントリＡに対してリーフエントリＡ．ｂが追加され、図
３７Ｂに示される構成とされる。さらに、図３７Ｂの構
成に対して、差分更新情報Ｍｓｇ３による変更が加えら
れ、コンテナエントリＢに対してリーフエントリＢ．ａ
が加えられる。

【００１８】ユーザは、コンテナエントリＢのジャンル
に興味があり、コンテナエントリＡのジャンルに興味が
無い。そのため、差分更新情報として必要なのは、リー
フエントリＢ．ａの追加を示す差分更新情報Ｍｓｇ３で
あって、リーフエントリＡ．ｂの追加を示す差分更新情
報Ｍｓｇ２は、必要無いことになる。

【００１９】上述した図３６の例のように、受信側にお
いて、差分更新情報Ｍｓｇ２を取りこぼした場合でも、
Ｍｓｇ２が必要無いことが分かっていれば、次に受信さ
れた差分更新情報Ｍｓｇ３に基づきディレクトリ構造を
変更することができる。しかしながら、差分更新情報Ｍ
ｓｇ２が必要無いことを受信側で知る方法が無ければ、
何らかの方法で差分更新情報Ｍｓｇ２を取得してからで
ないと、後続の、差分更新情報Ｍｓｇ３による変更処理
ができないという問題点があった。

【００２０】取りこぼした差分更新情報Ｍｓｇ２を、改
めて取得できるようにする方法としては、送信側で定期
的に全ディレクトリ構造の情報を放送する方法や、受信
側から送信側に対して、例えば双方向ネットワークなど
の双方向に通信を行える双方向通信手段によって必要な
情報（差分更新情報Ｍｓｇ２）を要求する方法などが考
えられる。

【００２１】しかしながら、定期的に全ディレクトリ構
造の情報を放送する方法では、その放送の周期が長く設
定されているような場合、無駄な待機時間を費やすこと
になってしまうという問題点があった。

【００２２】また、双方向通信によって受信側から送信
側へと必要な情報を要求する方法では、その情報を送信
するためのサーバなどの施設を配備する必要があり、コ
ストが余計にかかってしまうという問題点があった。

【００２３】したがって、この発明の目的は、必要な差
分更新情報を選択的に取得し、差分更新情報に基づくリ
ーフエントリの変更を、効率良く行えるようにした送信
装置および送信方法、受信装置および受信方法、ならび
に、送受信システムおよび送受信方法を提供することに
ある。

【００２４】この発明は、上述した課題を解決するため
に、コンテンツの所在を階層的に管理するディレクトリ
の階層構造を送信する送信装置において、上記ディレク
トリの階層構造の節点であって自分の配下の節点の情報
を格納可能なコンテナエントリと、上記コンテナエント
リの配下にあって、自分の配下の節点の情報を格納でき
ないリーフエントリとからなるディレクトリの階層構造
を管理する管理手段と、上記管理手段に管理される上記
ディレクトリの階層構造の変化を検出し、該検出の結果
に基づき、上記リーフエントリの変化の差分からなる差
分情報を求める検出手段と、上記コンテナエントリと、
該コンテナエントリの配下にあった上記リーフエントリ
に対応する上記差分情報を示す識別子とを関連付けたテ
ーブルと、上記差分情報と、該差分情報に対応する先行
条件識別子とを共に送信する送信手段とを有し、上記先
行条件識別子は、上記差分情報による上記リーフエント
リの更新処理を行う際に既に処理されていなければなら
ない差分情報を示す識別子であって、上記テーブルを参
照して、上記差分情報に対応する上記リーフエントリの
上位のコンテナエントリに関連付けられた上記識別子と
して求められることを特徴とする送信装置である。

【００２５】また、この発明は、コンテンツの所在を階
層的に管理するディレクトリの階層構造を送信する送信
方法において、上記ディレクトリの階層構造の節点であ
って自分の配下の節点の情報を格納可能なコンテナエン
トリと、上記コンテナエントリの配下にあって、自分の
配下の節点の情報を格納できないリーフエントリとから
なるディレクトリの階層構造を管理する管理のステップ
と、上記管理のステップに管理される上記ディレクトリ
の階層構造の変化を検出し、該検出の結果に基づき、上
記リーフエントリの変化の差分からなる差分情報を求め
る検出のステップと、上記コンテナエントリと、該コン
テナエントリの配下にあった上記リーフエントリに対応
する上記差分情報を示す識別子とを関連付けたテーブル
と、上記差分情報と、該差分情報に対応する先行条件識
別子とを共に送信する送信のステップとを有し、上記先
行条件識別子は、上記差分情報による上記リーフエント
リの更新処理を行う際に既に処理されていなければなら
ない差分情報を示す識別子であって、上記テーブルを参
照して、上記差分情報に対応する上記リーフエントリの
上位のコンテナエントリに関連付けられた上記識別子と
して求められることを特徴とする送信方法である。

【００２６】また、この発明は、送信された、コンテン
ツの所在を階層的に管理するディレクトリの階層構造を
受信する受信装置において、送信側から、上記ディレク
トリの階層構造の節点であって自分の配下の節点の情報
を格納可能なコンテナエントリと、上記コンテナエント
リの配下にあって、自分の配下の節点の情報を格納でき
ないリーフエントリとからなるディレクトリの階層構造
の変化を検出して求められた、上記コンテナエントリの
変化の差分からなる第１の差分情報と、上記リーフエン
トリの変化の差分からなる第２の差分情報とが送信さ
れ、さらに、上記送信側から、上記第２の差分情報に基
づく上記リーフエントリの更新処理の際に既に処理され
ていなければならない上記差分情報を示す上記識別子で
ある先行条件識別子が上記第２の差分情報と共に送信さ
れ、上記送信側から送信された上記第１の差分情報、上
記第２の差分情報および上記先行条件識別子とを受信す
る受信手段と、上記受信手段によって受信された上記第
１差分情報と上記第２の差分情報とに基づき構成される
ディレクトリの階層構造を管理する管理手段と、上記第
２の差分情報に基づき上記管理手段に管理される上記デ
ィレクトリの階層構造を変更する変更手段と、上記変更
手段による上記変更に用いた上記先行条件識別子を追記
記録する先行条件識別子記録手段とを有し、上記変更手
段による上記変更の際に、上記受信手段によって上記第
２の差分情報と共に受信された上記先行条件識別子の中
に、上記先行条件識別子記録手段に記録された上記先行
条件識別子と一致しない上記先行条件識別子が存在する
かどうかを調べるようにしたことを特徴とする受信装置
である。

【００２７】また、この発明は、送信された、コンテン
ツの所在を階層的に管理するディレクトリの階層構造を
受信する受信方法において、送信側から、上記ディレク
トリの階層構造の節点であって自分の配下の節点の情報
を格納可能なコンテナエントリと、上記コンテナエント
リの配下にあって、自分の配下の節点の情報を格納でき
ないリーフエントリとからなるディレクトリの階層構造
の変化を検出して求められた、上記コンテナエントリの
変化の差分からなる第１の差分情報と、上記リーフエン
トリの変化の差分からなる第２の差分情報とが送信さ
れ、さらに、上記送信側から、上記第２の差分情報に基
づく上記リーフエントリの更新処理の際に既に処理され
ていなければならない上記差分情報を示す上記識別子で
ある先行条件識別子が上記第２の差分情報と共に送信さ
れ、上記送信側から送信された上記第１の差分情報、上
記第２の差分情報および上記先行条件識別子とを受信す
る受信手段と、上記受信手段によって受信された上記第
１差分情報と上記第２の差分情報とに基づき構成される
ディレクトリの階層構造を管理する管理手段と、上記第
２の差分情報に基づき上記管理手段に管理される上記デ
ィレクトリの階層構造を変更する変更手段と、上記変更
手段による上記変更に用いた上記先行条件識別子を追記
記録する先行条件識別子記録手段とを有し、上記変更手
段による上記変更の際に、上記受信手段によって上記第
２の差分情報と共に受信された上記先行条件識別子の中
に、上記先行条件識別子記録手段により記録された上記
先行条件識別子と一致しない上記先行条件識別子が存在
するかどうかを調べるようにしたことを特徴とする受信
方法である。

【００２８】また、この発明は、コンテンツの所在を階
層的に管理するディレクトリの階層構造を送信し、送信
されたディレクトリの階層構造を受信する送受信システ
ムにおいて、ディレクトリの階層構造の節点であって自
分の配下の節点の情報を格納可能なコンテナエントリ
と、コンテナエントリの配下にあって、自分の配下の節
点の情報を格納できないリーフエントリとからなるディ
レクトリの階層構造を管理する第１の管理手段と、第１
の管理手段に管理されるディレクトリの階層構造の変化
を検出し、検出の結果に基づき、コンテナエントリの変
化の差分からなる第１の差分情報と、リーフエントリの
変化の差分からなる第２の差分情報を求める検出手段
と、コンテナエントリと、コンテナエントリの配下にあ
ったリーフエントリに対応する第２の差分情報を示す識
別子とを関連付けたテーブルと、第１の差分情報を送信
すると共に、第２の差分情報と、第２の差分情報に対応
する先行条件識別子とを共に送信する送信手段と、送信
手段で送信された、第１の差分情報と、第２の差分情報
と、第２の差分情報と共に送信された先行条件識別子と
を受信する受信手段と、受信手段によって受信された第
１差分情報と第２の差分情報とに基づき構成されるディ
レクトリの階層構造を管理する第２の管理手段と、第２
の差分情報に基づき第２の管理手段に管理されるディレ
クトリの階層構造を変更する変更手段と、変更手段によ
る変更に用いた第２の差分情報を示す先行条件識別子を
追記記録する先行条件識別子記録手段と、変更手段によ
る変更の際に、受信手段によって第２の差分情報と共に
受信された先行条件識別子の中に、先行条件識別子記録
手段に記録された先行条件識別子と一致しない先行条件
識別子が存在するかどうかを調べる比較手段とを有し、
先行条件識別子は、差分情報によるリーフエントリの更
新処理を行う際に既に処理されていなければならない差
分情報を示す識別子であって、テーブルを参照して、差
分情報に対応するリーフエントリの上位のコンテナエン
トリに関連付けられた識別子として求められることを特
徴とする送受信システムである。

【００２９】また、この発明は、コンテンツの所在を階
層的に管理するディレクトリの階層構造を送信し、送信
されたディレクトリの階層構造を受信する送受信方法に
おいて、ディレクトリの階層構造の節点であって自分の
配下の節点の情報を格納可能なコンテナエントリと、コ
ンテナエントリの配下にあって、自分の配下の節点の情
報を格納できないリーフエントリとからなるディレクト
リの階層構造を管理する第１の管理のステップと、第１
の管理のステップに管理されるディレクトリの階層構造
の変化を検出し、検出の結果に基づき、コンテナエント
リの変化の差分からなる第１の差分情報と、リーフエン
トリの変化の差分からなる第２の差分情報を求める検出
のステップと、コンテナエントリと、コンテナエントリ
の配下にあったリーフエントリに対応する第２の差分情
報を示す識別子とを関連付けたテーブルを作成するステ
ップと、第１の差分情報を送信すると共に、第２の差分
情報と、第２の差分情報に対応する先行条件識別子とを
共に送信する送信のステップと、送信のステップで送信
された、第１の差分情報と、第２の差分情報と、第２の
差分情報と共に送信された先行条件識別子とを受信する
受信のステップと、受信のステップによって受信された
第１差分情報と第２の差分情報とに基づき構成されるデ
ィレクトリの階層構造を管理する第２の管理のステップ
と、第２の差分情報に基づき第２の管理のステップに管
理されるディレクトリの階層構造を変更する変更のステ
ップと、変更のステップによる変更に用いた第２の差分
情報を示す先行条件識別子を追記記録する先行条件識別
子記録のステップと、変更のステップによる変更の際
に、受信のステップによって第２の差分情報と共に受信
された先行条件識別子の中に、先行条件識別子記録のス
テップにより記録された先行条件識別子と一致しない先
行条件識別子が存在するかどうかを調べる比較のステッ
プとを有し、先行条件識別子は、差分情報によるリーフ
エントリの更新処理を行う際に既に処理されていなけれ
ばならない差分情報を示す識別子であって、テーブルを
参照して、差分情報に対応するリーフエントリの上位の
コンテナエントリに関連付けられた識別子として求めら
れることを特徴とする送受信方法である。

【００３０】上述したように、請求項１および請求項４
に記載の発明は、管理される、自分の配下の情報を格納
可能なコンテナエントリと、コンテナエントリの配下に
あって、自分の配下の情報を格納できないリーフエント
リとからなるディレクトリの階層構造の変化を検出し、
検出の結果に基づき、リーフエントリの変化の差分から
なる差分情報を求め、差分情報と、差分情報に対応する
リーフエントリを構成するために必要な差分情報を示す
情報とを共に送信するようにしているため、受信側で
は、受信した差分情報に基づきディレクトリの階層構造
を構成する際に、必要な差分情報を示す情報により、正
しいディレクトリの階層構造を構成するために必要な差
分情報を知ることができる。

【００３１】また、上述したように、請求項５および請
求項８に記載の発明は、送信された、自分の配下の情報
を格納可能なコンテナエントリと、コンテナエントリの
配下にあって、自分の配下の情報を格納できないリーフ
エントリとからなるディレクトリの階層構造の変化を検
出して求められた、コンテナエントリの変化の差分から
なる第１の差分情報と、リーフエントリの変化の差分か
らなる第２の差分情報と、第２の差分情報と共に送信さ
れた、第２の差分情報に対応するリーフエントリを構成
するために必要な差分情報を示す情報とを受信し、受信
された第１差分情報と第２の差分情報とに基づき構成さ
れるディレクトリの階層構造を管理し、第２の差分情報
に基づき変更し、変更に用いた第２の差分情報を示す情
報が蓄積的に記憶され、ディレクトリの階層構造の第２
の差分情報に基づく変更の際に、第２の差分情報と共に
受信された第２の差分情報を示す情報の中に、蓄積的に
記憶された第２の差分情報を示す情報と一致しない情報
が存在するかどうかを調べるようにしているため、管理
されるディレクトリの階層構造を、受信された第２の差
分情報に基づき変更する際に、必要となる第２の差分情
報を知ることができる。

【００３２】また、上述したように、請求項９および請
求項１２記載の発明は、送信側で管理される、自分の配
下の情報を格納可能なコンテナエントリと、コンテナエ
ントリの配下にあって、自分の配下の情報を格納できな
いリーフエントリとからなるディレクトリの階層構造の
変化を検出した結果に基づき、コンテナエントリの変化
の差分からなる第１の差分情報と、リーフエントリの変
化の差分からなる第２の差分情報を求め、第１の差分情
報を送信すると共に、第２の差分情報と、第２の差分情
報に対応するリーフエントリを構成するために必要な差
分情報を示す情報とを共に送信し、受信側では、送信さ
れた、第１の差分情報と、第２の差分情報と、第２の差
分情報と共に送信された必要な差分情報を示す情報とを
受信し、受信された第１差分情報と第２の差分情報とに
基づき構成されるディレクトリの階層構造を第２の差分
情報により変更する際に用いた第２の差分情報を示す情
報を蓄積的に記憶し、ディレクトリの階層構造の変更の
際に、第２の差分情報と共に受信された必要な差分情報
を示す情報の中に、記憶手段に蓄積的に記憶された情報
と一致しない情報が存在するかどうかを調べるようにし
ているため、管理されるディレクトリの階層構造を、受
信された第２の差分情報に基づき変更する際に、必要と
なる第２の差分情報を知ることができる。

【００３３】

【発明の実施の形態】以下、この発明の実施の第１の形
態を、図面を参照しながら説明する。図１は、この発明
に適用できる系の一例を示す。送信側１は、例えばイン
ターネットや放送ネットワークなどの、図示されないネ
ットワーク上に存在する多数のコンテンツをツリー状の
階層構造に整理し、ディレクトリ構造として管理してい
る。送信側１では、このディレクトリ構造を示すディレ
クトリ情報を放送ネットワーク２に対して送信する。受
信側３は、図２に一例が示されるように、放送ネットワ
ーク２に対して多数が接続され、放送ネットワーク２を
介してなされた放送をそれぞれが受信可能とされてい
る。受信側３は、放送ネットワーク２で放送されたディ
レクトリ情報を受信し、受信されたディレクトリ情報を
参照して、放送ネットワーク２や他のネットワーク上に
存在する多数の情報の中から必要な情報を選択し、入手
することができる。

【００３４】図１に一例が示されるように、送信側１
は、送信側ディレクトリサービスクライアント１０（以
下、送信側クライアント１０と略す）、送信側ディレク
トリサーバ１１（以下、送信側サーバ１１と略す）およ
び送信側ディレクトリサーバレプリケータ１２（以下、
送信側レプリケータ１２と略す）からなる。これら送信
側クライアント１０、送信側サーバ１１および送信側レ
プリケータ１２は、互いに例えばインターネットといっ
たネットワークなどで接続されており、相互に通信が行
われる。

【００３５】送信側クライアント１０は、例えば図示さ
れないネットワークなどによってコンテンツを提供する
コンテンツプロバイダであって、ディレクトリ構造の変
更や更新を行う。送信側クライアント１０は、ネットワ
ーク上の何処に位置していてもよい。送信側サーバ１１
は、送信側クライアント１０の内容照会や変更などを行
い、ディレクトリ構造を管理する。送信側サーバ１１
は、ネットワーク上で分散して構成することができる。
送信側レプリケータ１２は、送信側サーバ１１で管理さ
れているディレクトリ構造をモニタしてディレクトリ構
造の更新を検出する。そして、送信側レプリケータ１２
は、この検出結果に基づき、更新前の構造と更新後の構
造とを比較して差分を抽出し、ディレクトリ構造の差分
更新情報を構成する。差分更新情報の構成については、
後述する。

【００３６】差分更新情報は、定期的に放送ネットワー
ク２に送信される。さらに、この発明では、送信側サー
バ１１で管理されているディレクトリ構造の全体の情報
（以下、全構成情報と称する）が放送ネットワーク２に
送信される。詳細は後述するが、差分更新情報の送信の
間隔と全構成情報の送信の間隔とは、それぞれ個別に設
定される。受信側３では、受信された差分更新情報と全
構成情報とに基づき、受信側３ローカルでのディレクト
リ構造を構築する。

【００３７】受信側３は、受信側ディレクトリサーバレ
プリケータ１７（以下、受信側レプリケータ１７と略
す）、受信側ディレクトリサーバ１６（以下、受信側サ
ーバ１６と略す）および受信側ディレクトリサービスク
ライアント１５（以下、受信側クライアント１５と略
す）からなる。受信側３は、例えばパーソナルコンピュ
ータや従来技術で述べたＳＴＢ、ＩＲＤなどであり、受
信側クライアント１５は、ディレクトリ構造にアクセス
して複数の異なる形式のデータの取得ならびに表示がで
きるようにされた、例えばＷＷＷ(World Wide Web)ブラ
ウザなどのアプリケーションソフトウェアである。ま
た、受信側サーバ１６は、ローカルなデータベースから
なり、ディレクトリ情報が格納される。

【００３８】放送ネットワーク２で送信された全構成情
報、ディレクトリ構造の更新情報および更新情報の差分
情報などは、受信側レプリケータ１７に受信される。受
信側レプリケータ１７では、受信されたこれらの情報に
基づき、受信側サーバ１６にローカルで格納されたデー
タベースを更新し、ディレクトリ構造の再構築を行う。
受信側クライアント１５は、例えばユーザの指示によ
り、受信側レプリケータ１７に対して必要な情報を要求
する。受信側レプリケータ１７は、この要求に基づき受
信側サーバ１６のデータベースを検索して、受信側クラ
イアント１５に対して、例えば要求された情報のアドレ
スを返す。受信側クライアント１５は、このアドレスに
基づき、例えば図示されないネットワーク上に存在する
情報にアクセスすることができる。

【００３９】図３を用いて、ディレクトリ構造について
説明する。ディレクトリは、図に示されるように、ツリ
ー状の階層構造からなる。ツリーの各節点（ノード）を
エントリと称し、各エントリには、情報が格納される。
エントリには、ルートエントリ、コンテナエントリおよ
びリーフエントリの３種類が定義される。コンテナエン
トリは、さらに配下のエントリを包含することができる
エントリである。コンテナエントリによって構成される
階層を、以下、コンテナ階層と称する。

【００４０】コンテナエントリ以外のエントリを、リー
フエントリと称する。リーフエントリは、配下にエント
リを含むことができない、末端の節点である。リーフエ
ントリによる階層を、以下、リーフ階層と称する。リー
フ階層は、コンテナエントリの配下に構成される。

【００４１】また、ディレクトリツリーの最上位のエン
トリは、ルートエントリと称され、当該ディレクトリ構
造で完結される世界全体を示すエントリである。なお、
以下では、コンテナエントリは、少なくとも一つのリー
フエントリあるいはコンテナエントリを配下に持つもの
とする。

【００４２】エントリは、複数の属性を持つ。エントリ
が持つ属性のうちで、ディレクトリツリーで一意に識別
される名前を、エントリ名と称する。エントリ名によっ
て、そのエントリの、ディレクトリ構造上の位置を特定
することができる。図３の例では、ルートエントリに
は、エントリ名Ａが与えられている。ルートエントリの
直接的な配下のエントリには、図の左側に示されるリー
フエントリにはエントリ名Ａ．Ｂが、右側のコンテナエ
ントリにはエントリ名Ａ．Ｃがそれぞれ与えられる。以
下、ルートエントリから階層構造を辿った順にピリオド
で区切られて、各エントリに対してエントリ名が与えら
れる。

【００４３】図４は、コンテナエントリの構造の一例を
示す。コンテナエントリは、コンテナエントリ自身の属
性と、自分の配下のコンテナエントリおよびリーフエン
トリのリストとを有する。配下のエントリのリストは、
要素を含まないこともできる。また、コンテナエントリ
自身の属性は、図示されるように、複数持つことができ
る。

【００４４】図５は、リーフエントリの構造の一例を示
す。リーフエントリは、図５Ａに示されるように、リー
フエントリの属性を複数、有する。図５Ｂは、リーフエ
ントリの属性のより具体的な例である。各属性は、属性
名と属性値とからなる。例えばリーフエントリがコンテ
ンツの検索情報である場合には、属性名の一つにアドレ
スがあり、その属性値としてＵＲＬ(Uniform Resource
Locator)などのコンテンツのアドレス情報が記述され
る。

【００４５】ディレクトリ構造は、例えば、そのディレ
クトリ構造で完結する世界全体を表すルートエントリの
下に、コンテナエントリが例えば情報ジャンルに応じて
ツリー状に分類され配されて、構成される。

【００４６】送信側１の構成について、より具体的に説
明する。送信側サーバ１１には、図３〜図５で既に説明
したような構成に準えて、ディレクトリ構造が管理され
ている。送信側クライアント１０は、提供するコンテン
ツに応じて、送信側サーバ１１で管理されているディレ
クトリ構造に対して変更などを加える。送信側サーバ１
１に対してなされた変更は、送信側レプリケータ１２に
モニタされる。

【００４７】図６は、送信側レプリケータ１２の機能を
説明するための機能ブロック図である。送信側レプリケ
ータ１２は、例えば一般的なコンピュータシステムで構
成することができ、ＣＰＵ(Central Processing Unit)
、メモリ、ハードディスクといった記録および記憶媒
体、通信手段、タイマ、ユーザインターフェイスなどか
らなる。この図６に示される機能ブロックは、ＣＰＵ上
で動作するアプリケーションソフトウェアにより実現さ
れ、各モジュールは、アプリケーションソフトウェア上
の機能的な単位であって、それぞれがソフトウェアから
なる。

【００４８】送信側レプリケータ１２は、更新検知モジ
ュール２０、メッセージ生成モジュール２１およびメッ
セージ放送モジュール２２からなる。これらモジュール
２０、２１および２２のそれぞれは、コンテナ階層に関
する処理を行うモジュールと、リーフ階層に関する処理
を行うモジュールとを有する。

【００４９】更新検知モジュール２０は、送信側サーバ
１１を参照して、サーバ１１上に管理されているディレ
クトリ構造に変化があったかどうかを検知するモジュー
ルで、コンテナ階層更新検知モジュール２３とリーフ階
層更新検知モジュール２４とからなる。コンテナ階層更
新検知モジュール２３は、送信側サーバ１１をモニタし
て、コンテナ階層の構造の変化を検知する。また、リー
フ階層更新検知モジュール２４は、送信側サーバ１１を
モニタして、リーフ階層の構造およびリーフエントリの
内容の変化を検知する。

【００５０】メッセージ生成モジュール２１は、更新検
知モジュール２０によるディレクトリ構造の変化の検知
結果に基づく、ディレクトリ構造の差分更新情報が示さ
れたメッセージを生成するモジュールで、コンテナスト
ラクチャアップデートメッセージ生成モジュール２５
と、リーフエントリアップデートメッセージ生成モジュ
ール２６とからなる。コンテナストラクチャアップデー
トメッセージ生成モジュール２５は、コンテナ階層更新
検知モジュール２３の検知結果に基づき、コンテナ階層
における構造変化に関する差分更新情報が示されたメッ
セージを生成する。また、リーフエントリアップデート
メッセージ生成モジュール２６は、リーフ階層更新検知
モジュール２４の検知結果に基づき、リーフ階層におけ
る更新情報が示されたメッセージを生成する。

【００５１】メッセージ放送モジュール２２は、メッセ
ージ生成モジュール２１で生成されたメッセージを放送
ネットワーク２に対して放送するモジュールで、コンテ
ナストラクチャアップデートメッセージ放送モジュール
２７とリーフエントリアップデートメッセージ放送モジ
ュール２８とからなる。コンテナストラクチャアップデ
ートメッセージ放送モジュール２７は、上述した、コン
テナストラクチャアップデートメッセージ生成モジュー
ル２５で生成されたメッセージを放送する。また、リー
フエントリアップデートメッセージ放送モジュール２８
は、上述した、リーフエントリアップデートメッセージ
生成モジュール２６で生成されたメッセージを放送す
る。なお、メッセージ放送モジュール２２からの放送ネ
ットワーク２に対するメッセージの放送は、同一のメッ
セージが所定回数だけ、サイクリックに送信されて行わ
れる。

【００５２】次に、受信側３の構成について、より具体
的に説明する。図７は、受信側クライアント１５の機能
を説明するための機能ブロック図である。受信側クライ
アント１５は、例えば一般的なコンピュータシステムで
構成することができ、ＣＰＵ(Central Processing Uni
t) 、メモリ、ハードディスクといった記録および記憶
媒体、通信手段、ユーザインターフェイスなどからな
る。この図７に示される機能ブロックは、ＣＰＵ上で動
作するアプリケーションソフトウェアにより実現され、
各モジュールは、アプリケーションソフトウェア上の機
能的な単位であって、それぞれがソフトウェアからな
る。

【００５３】受信側クライアント１５は、上述したよう
に、例えばＷＷＷブラウザであり、供給されたコンテン
ツ、例えば画像データ、テキストデータ、音声データお
よび動画データを統一的に表示および再生することがで
きるようにされている。また、所定の入力手段を用いて
ユーザによって入力された指示に基づき、上述の表示な
らびに再生を制御することができる。

【００５４】受信側クライアント１５は、ディレクトリ
検索モジュール３０、ユーザ対話管理モジュール３１お
よびコンテンツ取得モジュール３２とからなる。また、
ユーザ対話管理モジュール３１に対して、例えばキーボ
ードなどのテキスト入力手段、マウスなどのポインティ
ングデバイスや表示装置などからなるユーザインターフ
ェイス３３が接続される。ユーザの、受信側クライアン
ト１５に対するコンテンツ検索要求の入力は、ユーザイ
ンターフェイス３３を用いて、ユーザ対話モジュール３
１に対して対話形式で行われる。

【００５５】ユーザ対話モジュール３１に対してコンテ
ンツ検索要求が入力されると、ユーザ対話管理モジュー
ル３１からディレクトリ検索モジュール３０に対して、
コンテンツのアドレスを検索するため、コンテンツに対
応するディレクトリエントリを検索するよう依頼が出さ
れる。ディレクトリ検索モジュール３０では、この検索
依頼に応じて、受信側サーバ１６に対してディレクトリ
エントリ検索要求を送る。

【００５６】受信側サーバ１６での検索要求に基づくデ
ィレクトリエントリの検索結果がディレクトリ検索モジ
ュール３０に返される。検索結果は、ディレクトリ検索
モジュール３０からユーザ対話管理モジュール３１に返
される。そして、検索結果のディレクトリエントリ情報
から、例えば検索結果がリーフエントリであれば、属性
の一つであるコンテンツのアドレス情報が取り出され
る。ユーザ対話管理モジュール３１からコンテンツ取得
モジュール３２に対して、取り出されたアドレス情報に
よって示されるコンテンツを取得するよう、コンテンツ
取得依頼が出される。

【００５７】コンテンツ取得モジュール３２では、受け
取ったコンテンツ取得依頼に基づき、コンテンツサーバ
３５に対してコンテンツの取得要求を送る。コンテンツ
サーバ３５は、受信側クライアント１５と、例えばイン
ターネットといった双方向ネットワーク３６を介して接
続されるサーバであり、ユーザに対してコンテンツを提
供する。コンテンツの提供は、双方向ネットワーク３６
を介して行ってもいいし、放送ネットワーク２によって
行うこともできる。

【００５８】コンテンツ取得要求に基づきコンテンツサ
ーバ３５から取得されたコンテンツは、例えば双方向ネ
ットワーク３６を介してコンテンツ取得モジュール３２
に供給され、コンテンツ取得モジュール３２からユーザ
対話管理モジュール３１に返される。ユーザ対話管理モ
ジュール３１では、受け取ったコンテンツをユーザイン
ターフェイス３３に出力する。

【００５９】なお、要求するコンテンツが放送ネットワ
ーク２で伝送されるものである場合には、コンテンツ取
得モジュール３２は、放送ネットワーク２で放送される
所望のコンテンツを、コンテンツ取得依頼に基づき直接
的に取得するようにしてもよい。

【００６０】図８は、受信側サーバ１６の機能を説明す
るための機能ブロック図である。この受信側サーバ１６
も、説明は省略するが、上述の受信側クライアント１５
と同様に、一般的なコンピュータシステムによって構成
される。受信側サーバ１６は、ディレクトリ更新要求処
理モジュール４０、ディレクトリデータベース４１およ
びディレクトリ検索要求処理モジュール４２からなる。

【００６１】ディレクトリデータベース４１は、送信側
サーバ１１で管理されるディレクトリ構造に基づくディ
レクトリ情報が格納されている。上述したように、受信
側レプリケータ１７は、放送ネットワーク２を介して送
信側１から送信されたディレクトリ構造の差分更新情報
を受信する。詳細は後述するが、受信側レプリケータ１
７からディレクトリ更新要求処理モジュール４０に対し
て、差分更新情報に基づきディレクトリデータベース４
１に格納されているディレクトリ情報の更新を行うよ
う、要求が出される。ディレクトリ更新要求処理モジュ
ール４０では、この要求に基づき、差分更新情報を用い
てディレクトリデータベース４１に格納されているディ
レクトリ情報の更新を行う。

【００６２】一方、上述した受信側クライアント１５か
らのディレクトリエントリの検索要求は、ディレクトリ
検索要求処理モジュール４０に受け取られる。ディレク
トリ検索要求処理モジュール４０によって、受け取った
検索要求に基づきディレクトリデータベース４１が検索
される。検索した結果得られたディレクトリエントリ、
例えばリーフエントリ中のアドレス情報は、ディレクト
リ検索要求処理モジュール４２から受信側クライアント
１５に返される。

【００６３】上述したように系を構成することで、ユー
ザは、受信側クライアント１５によってディレクトリ情
報を検索し、検索結果として、所望のコンテンツが提供
されるアドレス情報を得ることができる。そして、ユー
ザは、得られたアドレス情報に基づき所望のコンテンツ
を取得することができる。また、ディレクトリ構造は、
常に送信側レプリケータ１２によってモニタされ、ディ
レクトリ構造の差分更新情報および全構成情報がそれぞ
れに設定された間隔で送信され、放送ネットワーク２を
介して受信側レプリケータ１７に供給される。ユーザ側
では、供給された差分更新情報および全構成情報に基づ
き、受信側レプリケータ１７によってディレクトリデー
タベース４１に格納されたディレクトリ情報が変更され
る。そのため、ユーザは、常に実際のディレクトリ構造
と同期したディレクトリ情報を、ディレクトリデータベ
ース４１に保持することができる。

【００６４】次に、図９、図１０、図１１および図１２
を用いて、上述したディレクトリ構造の差分更新情報お
よび全構成情報について説明する。以下では、スキーマ
バージョンＳｖで特定されるあるコンテナ階層のコンテ
ナエントリＸの配下に、コンテナエントリＣまたはリー
フエントリｌを追加または削除する処理を、（Ｓｖ，Ｘ，〔＋／−〕〔Ｃ／ｌ〕）と記述する。このディレクトリ構造に対する処理を示す
記述は、この記述による処理で変化したディレクトリ構
造の、元の構造との差分を表しており、これを差分更新
情報として用いることができる。

【００６５】一方、全構成情報は、ある時点でのディレ
クトリ構造を示す情報である。全構成情報をルートエン
トリとの差分であると考えることで、上述した差分更新
情報を用いて全構成情報を表現することができる。

【００６６】スキーマバージョンＳｖは、ディレクトリ
構造の変更に伴い変化する値である。コンテナエントリ
Ｘ（またはＣ）は、コンテナエントリ名であり、ここで
は大文字のアルファベットで表す。リーフエントリｌ
は、リーフエントリ名であり、ここでは小文字のアルフ
ァベットで表す。エントリの追加は〔＋〕で表され、削
除は〔−〕で表される。括弧〔〕中のスラッシュ記号
は、その両側に記された何方かが記述されることを示
す。なお、図９および図１０において、二重線の四角
は、コンテナエントリを表し、単線の四角は、リーフエ
ントリを表す。ルートエントリは、接続線だけが示さ
れ、本体は省略されている。

【００６７】図９Ａにおいて、図示されないルートエン
トリの配下にコンテナエントリＡのみが存在する、ディ
レクトリ構造１００が構成されている。この状態をスキ
ーマバージョンＳｖ＝１とする。この状態に、上述の記
述に従い（１，Ａ，＋Ｂ）の処理を行う。すなわち、コ
ンテナエントリＡの配下にコンテナエントリＢが加えら
れる。すると、図９Ｂに示すディレクトリ構造１０１に
なる。図９Ａの状態にコンテナエントリＢが加えられた
ことで、コンテナエントリの階層イメージが変化したと
され、スキーマバージョンＳｖ＝２とされる。

【００６８】図９Ｂの状態に、さらに（２，Ａ，＋ａ）
の処理を行う。すなわち、コンテナエントリＡの配下に
リーフエントリａを加える。すると、図９Ｃに示すディ
レクトリ構造１０２になる。さらにまた、図９Ｃの状態
に（２，Ａ，−ａ）の処理を行う。すなわち、リーフエ
ントリａを、コンテナエントリＡの配下から削除する。
すると、図９Ｄに示すディレクトリ構造１０３になる。
さらに、図９Ｄの状態に（２，Ａ，−Ｂ）の処理を行
う。すなわち、コンテナエントリＢを、コンテナエント
リＡの配下から削除する。すると、図９Ｅに示すディレ
クトリ構造１０４になる。

【００６９】図９Ｅの状態では、コンテナエントリの階
層イメージが図９Ｄの状態から変化しているため、スキ
ーマバージョンＳｖが更新され、スキーマバージョンＳ
ｖ＝３になる。したがって、図９Ｅの状態において、コ
ンテナエントリＡの配下にコンテナエントリＣを加える
処理は、（３，Ａ，＋Ｃ）と記述できる。この処理を行
うと、図９Ｆに示されるディレクトリ構造１０５とな
る。

【００７０】この図９の例では、（１，Ａ，＋Ｂ）、
（２，Ａ，＋ａ）、（２，Ａ，−ａ）、（２，Ａ，−
Ｂ）および（３，Ａ＋Ｃ）がそれぞれの段階での差分更
新情報とされる。

【００７１】図１０は、ディレクトリ構造を変更する別
の例を示す。上述の図９に示される例では、一度に一つ
の処理を行っていたが、図１０では、２つずつの処理を
まとめて行っている。図１０Ａは、図示されないルート
エントリの配下にコンテナエントリＡのみが存在してい
るディレクトリ１０６を示す。この状態がスキーマバー
ジョンＳｖ＝１とする。この図１０Ａの状態に対して、
（１，Ａ，＋Ｂ）および（１，Ａ，＋ａ）の処理を順に
行う。すなわち、コンテナエントリＡの配下に、コンテ
ナエントリＢとリーフエントリａとが追加される。する
と、図１０Ｂに示すディレクトリ構造１０７となる。コ
ンテナエントリの階層イメージが変わり、スキーマバー
ジョンＳｖ＝２となる。

【００７２】図１０Ｂの状態に、さらに、（２，Ａ，−
ａ）および（２，Ｂ，＋ｂ）の処理を順に行う。すなわ
ち、コンテナエントリＡの配下からリーフエントリａを
削除し、その後、コンテナエントリＢの配下にリーフエ
ントリｂを追加する。すると、図１０Ｃに示すディレク
トリ構造１０８となる。

【００７３】図１０Ｃの状態に対して、さらに、（２，
Ｂ，＋Ｃ）および（２，Ｃ，＋ｃ）の処理を行う。すな
わち、コンテナエントリＢの配下にコンテナエントリＣ
を追加した後に、追加されたコンテナエントリＣの配下
にリーフエントリｃを追加する。この処理においては、
追加されたコンテナエントリに対してさらにエントリが
追加されるため、処理の前後を入れ換えることができな
い。処理後、図１０Ｄに示すディレクトリ構造１０９と
なり、コンテナエントリの階層イメージが変わったた
め、スキーマバージョンＳｖが更新され、スキーマバー
ジョンＳｖ＝３とされる。

【００７４】この図１０の例では、（１，Ａ，＋Ｂ）お
よび（１，Ａ，＋ａ）、（２，Ａ，−ａ）および（２，
Ｂ，＋ｂ）、ならびに、（２，Ｂ，＋Ｃ）および（２，
Ｃ，＋ｃ）がそれぞれの段階での差分更新情報とされ
る。上述したように、複数の処理を一つのディレクトリ
構造の更新処理としてまとめて行うときには、処理の順
序を考慮する必要がある。

【００７５】図１１は、上述した図９に対応した一例の
全構成情報を示す。全構成情報は、所定の周期Ｔで以て
送信側レプリケータ１７から送信される。以下、全構成
情報が送信される周期Ｔを、全構成情報通知周期Ｔと称
する。図１１において、図の左方向から右方向へ時間の
経過が表され、構造１００、１０１、１０２、１０３お
よび１０４とディレクトリ構造が変化される間隔は、一
定であるものとする。また、ここでは、全構成情報通知
周期Ｔが構造１００〜１０２、構造１０２〜１０４の間
隔と対応している。

【００７６】上述したように、この例では、全構成情報
は、ある時点におけるディレクトリ構造の、ルートエン
トリからの差分情報として表される。したがって、構造
１０２に対応する全構成情報は、図１１に示されるよう
に、処理の順に（０，ｒｏｏｔ，＋Ａ）、（０，Ａ，＋
Ｂ）および（０，Ａ，＋ａ）と表すことができる。すな
わち、ルートエントリに対して、この順序で各処理がな
され、各エントリが追加されて、構造１０２が構成され
たように表現される。同様に、構造１０４は、ルートエ
ントリの配下にコンテナエントリＡが存在するだけなの
で、構造１０４の時点に対応する全構成情報は、（０，
ｒｏｏｔ，＋Ａ）と表現される。

【００７７】なお、全構成情報通知周期Ｔではスキーマ
バージョンＳｖは、０にリセットされ、全構成情報にお
けるＳｖは常に０である。

【００７８】図１２は、上述した図１０に対応した一例
の全構成情報を示す。この例では、構造１０６〜構造１
０９の間隔が全構成情報通知周期Ｔ’と対応している。
構造１０９に対応する全構成情報は、処理の順に（０，
ｒｏｏｔ，＋Ａ）、（０，Ａ，＋Ｂ）、（０，Ｂ，＋
ｂ）、（０，Ｂ，＋Ｃ）および（０，Ｃ，＋ｃ）と表す
ことができる。

【００７９】なお、ディレクトリ構造の差分更新情報お
よび全構成情報は、上述の例に限定されず、適用される
システムに応じて様々な形式とすることができる。

【００８０】この発明が適用される系では、上述したよ
うに、差分更新情報および全構成情報は、送信側１から
受信側３に対して放送ネットワーク２を介して一方向的
に送信される。また、一つの送信側１に対して複数の受
信側３が存在し、複数の受信側３の稼働状態もそれぞれ
異なる。そのため、送信側１で管理されているディレク
トリ情報と、受信側３で管理されているディレクトリ情
報とを同期させる必要がある。

【００８１】以下、送信側１の送信側サーバ１１に格納
されたディレクトリ情報と、受信側３の受信側サーバ１
６に格納されたディレクトリ情報とを同期させ、ディレ
クトリ構造の同期管理方法について説明する。

【００８２】最初に、図１３のフローチャートを用いて
コンテナエントリの同期管理方法について説明する。先
ず、ステップＳ１で、送信側クライアント１０によっ
て、送信側サーバ１１で管理されているディレクトリ構
造の、コンテナ階層の構成が変更される。例えば、コン
テナエントリの配下に新たなコンテナエントリやリーフ
エントリが追加される処理や、コンテナエントリの配下
のコンテナエントリやリーフエントリが削除される処理
が行われる。

【００８３】次のステップＳ２では、送信側サーバ１１
に対してなされた変更が送信側レプリケータ１２によっ
て検知され、検知結果に基づき、コンテナ階層構成の変
更によるコンテナ構造更新情報Ｍｓｇ．１が生成され
る。生成されたコンテナ構造更新情報Ｍｓｇ．１は、放
送ネットワーク２に対して放送される。コンテナ構造更
新情報Ｍｓｇ．１の放送は、同一の内容が所定回数、サ
イクリックに繰り返されて行われる。

【００８４】放送されたコンテナ構造更新情報Ｍｓｇ．
１は、ステップＳ３で、受信側レプリケータ１７によっ
て受信される。受信側レプリケータ１７は、受信側サー
バ１６に格納されたディレクトリ情報に管理されるコン
テナ階層構成を、受信したコンテナ構造更新情報Ｍｓ
ｇ．１に基づき変更する。これにより、送信側１と受信
側３とで、ディレクトリ情報のコンテナ階層の構造の同
期がとられる。

【００８５】コンテナ構造更新情報Ｍｓｇ．１のフォー
マットは、例えば、このように定義される。「MessageID 」（メッセージＩ
Ｄ）は、このメッセージ（コンテナ構造更新情報Ｍｓ
ｇ．１）の識別情報であって、例えば、このメッセージ
が生成される毎に１ずつ増加される整数である。また、
「差分更新情報」は、コンテナ階層構成の変更による、
上述したディレクトリ構造の差分更新情報である。

【００８６】図１３のフローチャートにおけるステップ
Ｓ２の処理を、図１４のフローチャートを用いて、より
詳細に説明する。この図１４のフローチャートによる処
理は、全て送信側レプリケータ１２上で行われる。先
ず、ステップＳ１０で、送信側サーバ１１上のコンテナ
エントリの階層構成の情報が全て読み込まれる。読み込
まれたコンテナエントリの階層構成の情報は、送信側レ
プリケータ１２が有する、例えばメモリやハードディス
クといった記録または記憶媒体に、コピー１として記憶
される。

【００８７】コピー１が記憶されたら、次のステップＳ
１１で、タイマが所定の時間にセットされ、起動され
る。ステップＳ１２によって、タイマにセットされた所
定時間を超過したかどうかが判断され、所定時間を超過
したと判断されたなら、処理はステップＳ１３に移行す
る。ステップＳ１３では、再び送信側サーバ１１上のコ
ンテナエントリの階層構成の情報が全て読み込まれる。
読み込まれたコンテナエントリの階層構造は、送信側レ
プリケータ１２が有する、例えばメモリやハードディス
クといった記録または記憶媒体に、コピー２として記憶
される。

【００８８】次のステップＳ１４では、ステップＳ１０
で記憶されたコピー１と、ステップＳ１３で記憶された
コピー２とが比較される。比較の結果、両者に差分が無
いとされれば（ステップＳ１５）、処理はステップＳ１
１へ戻され、再びタイマがセットされ、コピー２の記憶
がなされる。

【００８９】一方、ステップＳ１４で、コピー１とコピ
ー２との間に差分があるとされれば、処理はステップＳ
１６に移行する。ステップＳ１６では、コピー１とコピ
ー２との差分に基づき、差分更新情報が生成される。そ
して、この差分更新情報が記述されたコンテナ構造更新
情報Ｍｓｇ．１が生成される。生成されたコンテナ構造
更新情報Ｍｓｇ．１は、放送ネットワーク２に対して送
信され、放送される。放送されたコンテナ構造更新情報
Ｍｓｇ．１は、受信側レプリケータ１７に受信される。

【００９０】ステップＳ１６でコンテナ構造更新情報Ｍ
ｓｇ．１が放送されると、次のステップＳ１７で、コピ
ー１の内容がコピー２の内容で置き替えられ、処理はス
テップＳ１１に戻される。

【００９１】図１３のフローチャートにおけるステップ
Ｓ３の処理を、図１５のフローチャートを用いて、より
詳細に説明する。この図１５のフローチャートによる処
理は、全て受信側レプリケータ１７上で行われる。最初
のステップＳ２０で、送信側レプリケータ１２によって
放送ネットワーク２を介して放送されたコンテナ構造更
新情報Ｍｓｇ．１が、受信側レプリケータ１７によって
受信される。

【００９２】ステップＳ２１で、ステップＳ２０での受
信がコンテナ構造更新情報Ｍｓｇ．１の初回の受信かど
うかが判断される。そして、この受信が初回の受信であ
ると判断されたら、処理はステップＳ２３に移行し、受
信されたコンテナ構造更新情報Ｍｓｇ．１のメッセージ
ＩＤが受信側レプリケータ１７が有する、例えばメモリ
やハードディスクといった記録または記憶媒体に、コピ
ー３として記憶される。

【００９３】次のステップＳ２４では、受信されたコン
テナ構造更新情報Ｍｓｇ．１の内容、すなわち、コンテ
ナ構造更新情報Ｍｓｇ．１に記述された差分更新情報に
基づき、受信側サーバ１６で管理されているディレクト
リ情報が更新され、そのディレクトリ情報で示されるコ
ンテナ階層の構成が変更される。ステップＳ２４の処理
の後、処理はステップＳ２０に戻される。

【００９４】一方、上述のステップＳ２１で、ステップ
Ｓ２０でのコンテナ構造更新情報Ｍｓｇ．１の受信が初
回の受信では無いと判断されたら、処理はステップＳ２
２に移行する。ステップＳ２２では、受信されたコンテ
ナ構造更新情報Ｍｓｇ．１に記述されるメッセージＩＤ
と、前回の受信の際のステップＳ２３の処理でコピー３
として記憶されたメッセージＩＤとが同一であるかどう
かが判断される。若し、同一であるとされれば、処理は
ステップＳ２０に戻される。

【００９５】一方、ステップＳ２２で、両者のメッセー
ジＩＤが同一では無いとされれば、処理はステップＳ２
３に移行する。ステップＳ２３では、上述したように、
メッセージＩＤが記憶媒体にコピー３として記憶され
る。この場合には、新たに受信されたメッセージＩＤ
で、前回受信され記憶されたメッセージＩＤが例えば上
書きされることになる。そして、次のステップＳ２４
で、受信されたコンテナ構造更新情報Ｍｓｇ．１に基づ
き、受信側サーバ１６上のコンテナエントリ階層の内容
が変更される。

【００９６】次に、図１６のフローチャートを用いてリ
ーフエントリの同期管理方法について説明する。先ず、
ステップＳ３０で、送信側クライアント１０によって、
送信側サーバ１１で管理されているディレクトリ構造
の、あるコンテナエントリの配下のリーフエントリが変
更される。例えば、あるコンテナエントリの配下の新た
なリーフエントリの追加や、あるコンテナエントリの配
下のリーフエントリの削除や修正といった処理が行われ
る。

【００９７】次のステップＳ３１では、送信側サーバ１
１のあるコンテナエントリの配下のリーフエントリに対
してなされた変更が送信側レプリケータ１２によって検
知される。そして、検知結果に基づき、あるコンテナエ
ントリ配下のリーフエントリの変更によるリーフ更新情
報Ｍｓｇ．ｘ１が生成される。生成されたリーフ更新情
報Ｍｓｇ．ｘ１は、放送ネットワーク２を介して複数の
受信側レプリケータ１７に対してサイクリックに放送さ
れる。

【００９８】放送されたリーフ更新情報Ｍｓｇ．ｘ１
は、ステップＳ３２で、受信側レプリケータ１７によっ
て受信される。受信側レプリケータ１７は、受信したリ
ーフ更新情報Ｍｓｇ．ｘ１に基づき、受信側サーバ１６
に格納されたディレクトリ情報に管理される、対応する
リーフエントリを変更する。これにより、送信側１と受
信側３とで、ディレクトリ情報のリーフエントリの同期
がとられる。

【００９９】リーフ更新情報Ｍｓｇ．ｘ１のフォーマッ
トは、例えば、このように定義される。「MessageID 」（メッセージＩ
Ｄ）は、このメッセージ（リーフ更新情報Ｍｓｇ．ｘ
１）の識別情報であって、例えば、このメッセージが生
成される毎に１ずつ増加される整数である。また、「差
分更新情報」は、上述したディレクトリ構造の差分更新
情報である。

【０１００】図１６のフローチャートにおけるステップ
Ｓ３１の処理を、図１７のフローチャートを用いて、よ
り詳細に説明する。この図１７のフローチャートによる
処理は、全て送信側レプリケータ１２上で行われる。先
ず、ステップＳ４０で、送信側サーバ１１上の、あるコ
ンテナエントリの配下のリーフエントリ名が全て読み込
まれる。読み込まれたリーフエントリ名は、送信側レプ
リケータ１２が有する、例えばメモリやハードディスク
といった記録または記憶媒体に、コピー４として記憶さ
れる。

【０１０１】コピー１が記憶されたら、次のステップＳ
４１で、タイマが所定の時間にセットされ、起動され
る。ステップＳ４２によって、タイマにセットされた所
定時間を超過したかどうかが判断され、所定時間を超過
したと判断されたなら、処理はステップＳ４３に移行す
る。ステップＳ４３では、再び送信側サーバ１１上の、
あるコンテナエントリの配下のリーフエントリ名が全て
読み込まれる。読み込まれたリーフエントリ名は、送信
側レプリケータ１２が有する、例えばメモリやハードデ
ィスクといった記録または記憶媒体に、コピー５として
記憶される。

【０１０２】次のステップＳ４４では、ステップＳ４０
で記憶されたコピー４と、ステップＳ４３で記憶された
コピー５とが比較される。比較の結果、両者の間に差分
が無いとされれば（ステップＳ４５）、処理はステップ
Ｓ４１へ戻され、再びタイマがセットされ、コピー５の
記憶が行われる。

【０１０３】一方、ステップＳ４４で、コピー４とコピ
ー５との間に差分があるとされれば、処理はステップＳ
４６に移行する。ステップＳ４６では、コピー４とコピ
ー５との差分に基づき、差分更新情報が生成される。そ
して、この差分更新情報が記述されたリーフ更新情報Ｍ
ｓｇ．ｘ１が生成される。生成されたリーフ更新情報Ｍ
ｓｇ．ｘ１は、放送ネットワーク２に対して送信され、
放送される。放送されたリーフ更新情報Ｍｓｇ．ｘ１
は、複数の受信側レプリケータ１７に受信される。

【０１０４】ステップＳ４６でリーフ更新情報Ｍｓｇ．
ｘ１が放送されると、次のステップＳ４７で、コピー４
の内容がコピー５の内容で書き替えられ、処理はステッ
プＳ４１に戻される。

【０１０５】なお、上述の図１７のフローチャートの処
理は、送信側レプリケータ１２によって、送信側サーバ
１１が管理するディレクトリ構造上の全てのコンテナエ
ントリに対して行われる。

【０１０６】ところで、受信側３では、受信されないリ
ーフ更新情報Ｍｓｇ．ｘ１があると、その後に受信され
たリーフ更新情報Ｍｓｇ．ｘ１に基づくリーフエントリ
の更新処理を行った際に、送信側におけるディレクトリ
構造の変化が正しく反映されずに、更新されたディレク
トリ構造に不整合を生ずるおそれがある。

【０１０７】そこで、上述したリーフ更新情報Ｍｓｇ．
ｘ１に対して、さらに、当該リーフ更新情報Ｍｓｇ．ｘ
１によるリーフエントリの更新処理を行う際に既に処理
されていなければならない差分更新情報を付加すること
ができる。以下では、あるリーフ更新情報によるリーフ
エントリの更新処理を行う際に既に処理されていなけれ
ばならない差分更新情報を、プリリクジットメッセージ
と称し、当該差分更新情報を示すメッセージＩＤを、プ
リリクジットメッセージＩＤと称する。

【０１０８】プリリクジットメッセージＩＤを用いた場
合の処理は、上述したプリリクジットメッセージＩＤを
用いない場合の処理と、以下に記す２点で異なる。１つ
は、上述の図１３のフローチャートによる、コンテナ構
成更新情報に関する処理（ステップＳ２）が、所定周期
に設定されたタイマ（全構成情報通知周期タイマと称す
る）に基づき、所定周期でなされる点である。２つ目
は、上述の図１６でフローチャートによる、リーフ更新
情報に関する処理が各コンテナエントリ毎に行われる点
である。

【０１０９】コンテナ構成更新情報Ｍｓｇ．１は、コン
テナエントリの更新が検知される毎に、更新があった分
だけが差分更新情報として放送されると共に、が全構成
情報通知周期タイマで示される周期で、ディレクトリ構
造の全構成情報、すなわち、ルートエントリからの差分
情報が放送される。図１８は、全構成情報通知周期タイ
マを用いた場合の、上述した図１３のフローチャートの
ステップＳ２に対応した、コンテナ構成更新情報Ｍｓ
ｇ．１の生成ならびに放送の一例の処理を示すフローチ
ャートである。

【０１１０】図１８のフローチャートによる処理は、全
て送信側レプリケータ１２上で行われる。先ず、最初の
ステップＳ１００で、全構成情報通知周期Ｔを計測する
全構成情報通知周期タイマＴ₁を、後述のステップＳ１
０２でセットされるタイマＴ₂の整数倍の時間にセット
され、タイマＴ₁が起動される。なお、全構成情報通知
周期タイマＴ₁の値の詳細な設定方法については、後述
する。

【０１１１】タイマＴ₁がセットされると、次のステッ
プＳ１０１で、送信側サーバ１１上のコンテナエントリ
の階層構成の情報が全て読み込まれる。読み込まれたコ
ンテナエントリの階層構成の情報は、送信側レプリケー
タ１２が有する、例えばメモリやハードディスクといっ
た記録または記憶媒体に、コピー６として記憶される。

【０１１２】コピー６が記憶されたら、次のステップＳ
１０２で、タイマＴ₂が所定の時間にセットされ、起動
され、その次のステップＳ１０３では、上述のステップ
Ｓ１００でセットされた全構成情報通知周期タイマＴ₁
若しくはタイマＴ₂の何れかがセットされた時間を超過
するまで待機される。タイマＴ₁若しくはタイマＴ₂の
何れかがセットされた時間を超過したら、処理はステッ
プＳ１０４に移行する。

【０１１３】ステップＳ１０４では、上述のステップＳ
１０３で超過したタイマが全構成情報通知周期タイマＴ
₁であるかどうかが判断される。若し、セットされた時
間を超過したタイマがタイマＴ₁ではない、すなわち、
タイマＴ₂であると判断された場合には、処理はステッ
プＳ１０６に移行する。

【０１１４】一方、ステップＳ１０４で、全構成情報通
知周期タイマＴ₁が超過したと判断されれば、処理はス
テップＳ１０５に移行し、上述のステップＳ１０１で記
憶されたコピー６の内容がクリアされる。クリアされる
ことによって、コピー６の内容は、ルートエントリのみ
とされる。コピー６の内容がクリアされると、処理はス
テップＳ１０６に移行する。

【０１１５】ステップＳ１０６では、再び送信側サーバ
１１上のコンテナエントリの階層構成の情報が全て読み
込まれる。読み込まれたコンテナエントリの階層構造
は、送信側レプリケータ１２が有する、例えばメモリや
ハードディスクといった記録または記憶媒体に、コピー
７として記憶される。

【０１１６】次のステップＳ１０７では、上述したコピ
ー６と、ステップＳ１０６で記憶されたコピー７とが比
較される。若し、比較の結果、両者に差分が無いとされ
れば（ステップＳ１０８）、処理はステップＳ１００へ
戻され、再び全構成情報通知周期タイマＴ₁がセットさ
れ、上述した、以降の処理が行われる。

【０１１７】なお、上述のステップＳ１０４により全構
成情報通知周期タイマＴ₁が超過し、ステップＳ１０５
でコピー６の内容がクリアされている場合、ステップＳ
１０７のコピー６とコピー７との比較により、ルートエ
ントリに対しての、コピー２として記憶されたコンテナ
エントリの階層構造の差分が求められることになる。

【０１１８】一方、ステップＳ１０８で、コピー６とコ
ピー７との間に差分があると判断されれば、処理はステ
ップＳ１０９に移行する。ステップＳ１０９では、コピ
ー６とコピー７との差分に基づき、差分更新情報が生成
される。そして、この差分更新情報が記述されたコンテ
ナ構造更新情報Ｍｓｇ．１が生成される。生成されたコ
ンテナ構造更新情報Ｍｓｇ．１は、放送ネットワーク２
に対して送信され、放送される。放送されたコンテナ構
造更新情報Ｍｓｇ．１は、受信側レプリケータ１７に受
信される。

【０１１９】ステップＳ１０９でコンテナ構造更新情報
Ｍｓｇ．１が放送されると、次のステップＳ１１０で、
コピー６の内容がコピー７の内容で置き替えられ、処理
はステップＳ１００に戻される。

【０１２０】なお、この例における受信側レプリケータ
１７での、上述した図１３のフローチャートのステップ
Ｓ３に対応した処理は、上述した図１５のフローチャー
トに従って行われる。

【０１２１】プリリクジットメッセージＩＤを用いるこ
の例では、リーフ更新情報Ｍｓｇ．ｘ１に、上述したプ
リリクジットメッセージＩＤリストを追加して、プリリ
クジットメッセージＩＤリスト付きリーフ更新情報Ｍｓ
ｇ．ｘ１を作成する。リーフ更新情報Ｍｓｇ．ｘ１にプ
リリクジットメッセージＩＤリストが追加された、プリ
リクジットメッセージＩＤリスト付きリーフ更新情報Ｍ
ｓｇ．ｘ１は、各コンテナエントリのそれぞれについ
て、所定間隔で送信側レプリケータ１２から受信側レプ
リケータ１７に放送される。以下、繁雑さを避けるため
に、「プリリクジットメッセージＩＤリスト付きリーフ
更新情報Ｍｓｇ．ｘ１」を、「リーフ更新情報Ｍｓｇ．
ｘ１”」と略称する。

【０１２２】プリリクジットメッセージは、送信側レプ
リケータ１２において、コンテナエントリの配下のリー
フエントリに対してなされた変更に基づき生成されたリ
ーフ更新情報Ｍｓｇ．ｘ１の履歴を、各コンテナエント
リ毎に一覧した差分更新通知履歴テーブルを参照して作
成される。差分更新通知履歴テーブルの一例を図１９に
示す。このように、差分更新通知履歴テーブルには、コ
ンテナエントリ名と、そのコンテナエントリの配下のリ
ーフエントリの変更に伴い生成されたリーフ更新情報Ｍ
ｓｇ．ｘ１のメッセージＩＤのリストが、各コンテナエ
ントリについて記述されている。

【０１２３】送信側レプリケータ１２では、リーフ更新
情報Ｍｓｇ．ｘ１を作成する際に、この差分更新通知履
歴テーブルを参照し、対応するコンテナエントリ配下の
リーフエントリに関する、最新のものから所定個前まで
のリーフ更新情報Ｍｓｇ．ｘ１のメッセージＩＤを取得
する。取得された複数のメッセージＩＤは、プリリクジ
ットメッセージＩＤとして一覧され、プリリクジットメ
ッセージＩＤリストが作成される。

【０１２４】リーフ更新情報Ｍｓｇ．ｘ１に対してプリ
リクジットメッセージＩＤリストが追加された、上述の
リーフ更新情報Ｍｓｇ．ｘ１”のフォーマットは、このようになる。メッセージＩＤ(MessageID) および差
分更新情報は、上述したリーフ更新情報Ｍｓｇ．ｘ１と
同等のものである。

【０１２５】プリリクジットメッセージＩＤリストを用
いた場合の、図１６のフローチャートにおけるステップ
Ｓ３１の処理を、図２０のフローチャートを用いて、よ
り詳細に説明する。この図２０のフローチャートによる
処理は、全て送信側レプリケータ１２上で行われる。図
２０のフローチャートによる処理は、送信側レプリケー
タ１２によって、送信側サーバ１１が管理するディレク
トリ構造上の全てのコンテナエントリに対して行われ
る。

【０１２６】先ず、最初のステップＳ１２０で、全構成
情報通知周期Ｔを計測する全構成情報通知周期タイマＴ
₁’を、後述のステップＳ１２２でセットされるタイマ
Ｔ₂の整数倍の時間にセットされ、タイマＴ₁が起動さ
れる。なお、詳細は後述するが、全構成情報通知周期タ
イマＴ₁’は、上述した全構成情報通知周期タイマＴ₁
と別個に時間をセットすることができる。全構成情報通
知周期タイマＴ₁の設定方法については、後述する。

【０１２７】タイマＴ₁’がセットされると、次のステ
ップＳ１２１で、送信側サーバ１１上の、あるコンテナ
エントリ（コンテナエントリＡとする）の配下のリーフ
エントリ名が全て読み込まれる。読み込まれたリーフエ
ントリ名は、送信側レプリケータ１２が有する、例えば
メモリやハードディスクといった記録または記憶媒体
に、コピー８として記憶される。

【０１２８】コピー８が記憶されたら、次のステップＳ
１２２で、タイマＴ₂が所定の時間にセットされ、起動
され、その次のステップＳ１２３では、上述のステップ
Ｓ１２０でセットされた全構成情報通知周期タイマ
Ｔ₁’若しくはタイマＴ₂の何れかがセットされた時間
を超過するまで待機される。タイマＴ₁’若しくはタイ
マＴ₂の何れかがセットされた時間を超過したら、処理
はステップＳ１２４に移行する。

【０１２９】ステップＳ１２４では、上述のステップＳ
１２３で超過したタイマが全構成情報通知周期タイマＴ
₁’であるかどうかが判断される。若し、セットされた
時間を超過したタイマがタイマＴ₁’ではない、すなわ
ち、タイマＴ₂であると判断された場合には、処理はス
テップＳ１２６に移行する。

【０１３０】一方、ステップＳ１２４で、全構成情報通
知周期タイマＴ₁’が超過したと判断されれば、処理は
ステップＳ１２５に移行し、上述のステップＳ１２１で
記憶されたコピー８の内容がクリアされる。クリアされ
ることによって、コピー８の内容は、上述したコンテナ
エントリＡのみとされる。コピー８の内容がクリアされ
所定のコンテナエントリのみとされると、処理はステッ
プＳ１２６に移行する。

【０１３１】ステップＳ１２６では、再び送信側サーバ
１１上の、あるコンテナエントリ（この例ではコンテナ
エントリＡ）の配下のリーフエントリ名が全て読み込ま
れる。読み込まれたリーフエントリ名は、送信側レプリ
ケータ１２が有する、例えばメモリやハードディスクと
いった記録または記憶媒体に、コピー９として記憶され
る。

【０１３２】次のステップＳ１２７では、上述したコピ
ー８と、ステップＳ１２６で記憶されたコピー９とが比
較される。比較の結果、両者の間に差分が無いとされれ
ば（ステップＳ１２８）、処理はステップＳ１２０へ戻
され、再び全構成情報通知周期タイマＴ₁’がセットさ
れ、上述した、以降の処理が行われる。

【０１３３】一方、ステップＳ１２８で、コピー８とコ
ピー９との間に差分があるとされれば、処理はステップ
Ｓ１２９に移行する。ステップＳ１２９では、上述した
差分更新通知履歴テーブルを参照し、対象としているコ
ンテナエントリＡに対応するリーフ更新情報Ｍｓｇ．ｘ
１のメッセージＩＤのリストを取得する。次のステップ
Ｓ１３０で、取得されたメッセージＩＤのリストをプリ
リクジットメッセージＩＤリストとしてリーフ更新情報
Ｍｓｇ．ｘ１”が生成され、放送される。

【０１３４】ステップＳ１３０で生成されたリーフ更新
情報Ｍｓｇ．ｘ１”は、ステップＳ１３１で、差分更新
通知履歴テーブルの対象となるコンテナエントリのメッ
セージＩＤのリストに追記される。

【０１３５】ステップＳ１３１で、差分更新通知履歴テ
ーブルへのメッセージＩＤの追記が行われると、次のス
テップ１３２で、コピー８の内容がコピー９の内容で書
き替えられ、処理はステップＳ１２０に戻される。

【０１３６】なお、上述のステップＳ１２４で全構成情
報通知周期タイマＴ₁’が超過し、次のステップＳ１２
５でコピー８の内容がクリアされた場合には、ステップ
ＳステップＳ１２９で生成される差分更新情報は、配下
の情報がクリアされたコンテナエントリに対して、新た
にリーフエントリを追加するようになされる。

【０１３７】上述のフローチャート中のステップＳ１２
９の処理において、送信側レプリケータ１２では、過去
において放送されたリーフ更新情報Ｍｓｇ．ｘ１”を保
存している必要がある。そのため、送信側レプリケータ
１２では、上述した図２０で示されるフローチャートの
ステップＳ１３０の処理を、図２１に示すフローチャー
トに従って行う。

【０１３８】先ず、送信側レプリケータ１２において、
例えばメモリやハードディスクなどに、リポジトリと称
する所定の記憶領域を設定する。図２１において、最初
のステップＳ９０で、図２０で上述したステップＳ１２
９で、差分更新通知履歴テーブルを参照して取得され
た、対象コンテナエントリに対応するリーフ更新情報Ｍ
ｓｇ．ｘ１のメッセージＩＤのリストに列挙されている
メッセージＩＤを、プリリクジットメッセージＩＤとし
て、差分更新情報を記述したリーフ更新情報Ｍｓｇ．ｘ
１”を生成する。次のステップＳ９１で、生成されたリ
ーフ更新情報Ｍｓｇ．ｘ１”がリポジトリに格納され
る。そして、次のステップＳ９２で、ステップＳ９０で
生成されたリーフ更新情報Ｍｓｇ．ｘ１”が放送ネット
ワーク２を介して放送される。

【０１３９】プリリクジットメッセージＩＤリストを用
いた場合の、図１６のフローチャートにおけるステップ
Ｓ３２の処理を、図２２のフローチャートを用いて、よ
り詳細に説明する。この図２２のフローチャートによる
処理は、全て受信側レプリケータ１７上で行われる。最
初のステップＳ８０で、送信側レプリケータ１２によっ
て放送ネットワーク２を介して放送されたリーフ更新情
報Ｍｓｇ．ｘ１”が、受信側レプリケータ１７によって
受信される。

【０１４０】ステップＳ８１で、ステップＳ８０での受
信がリーフ更新情報Ｍｓｇ．ｘ１”の初回の受信である
かどうかが判断される。若し、この受信が初回の受信で
あると判断されたら、処理はステップＳ８５に移行す
る。ステップＳ８５では、受信されたリーフ更新情報Ｍ
ｓｇ．ｘ１”のメッセージＩＤが、受信側レプリケータ
１７が有する例えばメモリやハードディスクといった記
録または記憶媒体に上に形成される、メッセージＩＤリ
ストに追記記録される。

【０１４１】次のステップＳ８６では、受信されたリー
フ更新情報Ｍｓｇ．ｘ１”の内容、すなわち、リーフ更
新情報Ｍｓｇ．ｘ１”に記述された差分更新情報に基づ
き、受信側サーバ１６で管理されているディレクトリ情
報のうち、対応するリーフエントリの内容が変更され
る。ステップＳ８６の処理の後、処理はステップＳ８０
に戻される。

【０１４２】一方、上述のステップＳ８１で、ステップ
Ｓ８０でのリーフ更新情報Ｍｓｇ．ｘ１”の受信が初回
の受信では無いと判断されたら、処理はステップＳ８２
に移行する。ステップＳ８２では、メッセージＩＤリス
トが参照され、ステップＳ８０で受信されたリーフ更新
情報Ｍｓｇ．ｘ１”のメッセージＩＤがメッセージＩＤ
リスト上に存在するかどうかが判断される。若し、存在
すると判断されたら、処理はステップＳ８０に戻され
る。

【０１４３】一方、ステップＳ８２でメッセージＩＤリ
スト上に受信したリーフ更新情報Ｍｓｇ．ｘ１”のメッ
セージＩＤが存在しないと判断されたら、処理はステッ
プＳ８３に移行する。ステップＳ８３では、受信したリ
ーフ更新情報Ｍｓｇ．ｘ１”のプリリクジットメッセー
ジＩＤリスト上のメッセージＩＤのうち、メッセージＩ
Ｄリスト上に無いものがあるかどうかが判断される。若
し、無い、すなわち、プリリクジットメッセージＩＤリ
スト上のメッセージＩＤが全てメッセージＩＤリストに
存在すると判断されたら、処理は上述したステップＳ８
５に移行する。

【０１４４】一方、ステップＳ８３で、受信したリーフ
更新情報Ｍｓｇ．ｘ１”のプリリクジットメッセージＩ
Ｄリスト上のメッセージＩＤのうち、メッセージＩＤリ
ストに無いものがあると判断されれば、処理はステップ
Ｓ８４に移行する。ステップＳ８４では、メッセージＩ
Ｄリストに無いメッセージＩＤを有するリーフ更新情報
Ｍｓｇ．ｘ１”の取得がなされる。

【０１４５】このステップＳ８４によるリーフ更新情報
Ｍｓｇ．ｘ１”の取得は、例えば双方向に通信が可能な
双方向ネットワークで送信側レプリケータ１２と受信側
レプリケータ１７とを接続し、この双方向ネットワーク
を用いて行うことができる。例えば、受信側レプリケー
タ１７から送信側レプリケータ１２に対して、メッセー
ジＩＤリストに無いメッセージＩＤを有するリーフ更新
情報Ｍｓｇ．ｘ１”が、双方向ネットワークを介して要
求される。送信側レプリケータ１２では、この要求に応
じて、該当するリーフ更新情報Ｍｓｇ．ｘ１”を双方向
ネットワークを介して受信側レプリケータ１７に送信す
る。

【０１４６】また、ステップＳ８４によるリーフ更新情
報Ｍｓｇ．ｘ１”の取得は、上述に限らず、双方向ネッ
トワークでは、受信側レプリケータ１７から送信側レプ
リケータ１２に対する、メッセージＩＤリストに無いメ
ッセージＩＤを有するリーフ更新情報Ｍｓｇ．ｘ１”の
要求のみ行い、送信側レプリケータ１２において、該当
するリーフ更新情報Ｍｓｇ．ｘ１”を放送ネットワーク
２を介して放送するようにしてもよい。

【０１４７】ところで、上述したように、図１６のフロ
ーチャート中のステップＳ３１による、リーフ更新情報
Ｍｓｇ．ｘ１の放送は、送信側１で管理されるディレク
トリ構造中の、全コンテナエントリのそれぞれに関して
行われ、放送されるリーフ更新情報Ｍｓｇ．ｘ１は、膨
大な量になることが予想される。したがって、受信側３
では、必要とされている、すなわち、頻繁に照会される
コンテナエントリの配下のリーフエントリに対するリー
フ更新情報Ｍｓｇ．ｘ１のみを、放送された多数のリー
フ更新情報Ｍｓｇ．ｘ１から、効率よくフィルタ処理す
る必要がある。

【０１４８】以下に、リーフ更新情報Ｍｓｇ．ｘ１に対
して、効率的にフィルタ処理を行う方法について説明す
る。送信側レプリケータ１２は、放送されるリーフ更新
情報Ｍｓｇ．ｘ１に対して、受信側レプリケータ１７に
おいてフィルタ処理を行うためのフィルタリングマスク
を付加する。フィルタリングマスクを解釈するためのマ
スクスキーマ構造と、マスクスキーマ構造を送信側レプ
リケータ１２から受信側レプリケータ１７に通知する方
法などについては、後述する。

【０１４９】リーフ更新情報Ｍｓｇ．ｘ１にフィルタリ
ングマスクを付加したメッセージ（リーフ更新情報Ｍｓ
ｇ．ｘ１’とする）の構造を、次のように定義し、上述
のリーフ更新情報Ｍｓｇ．ｘ１を全てこのリーフ更新情
報Ｍｓｇ．ｘ１’で置き替えて考える。すなわち、リー
フ更新情報Ｍｓｇ．ｘ１’は、このように定義される。「MessageID 」（メッセージＩ
Ｄ）は、上述のリーフ更新情報Ｍｓｇ．ｘ１の場合と同
様に、このメッセージ（リーフ更新情報Ｍｓｇ．ｘ
１’）の識別情報であって、例えば、このメッセージが
生成される毎に１ずつ増加される整数である。「差分更
新情報」は、ここに記述されるフィルタリングマスクで
特定されるコンテナエントリ配下のリーフエントリの、
追加、削除および属性変更といった手続の情報である。

【０１５０】「FilteringMask 」（フィルタリングマス
ク）の構造は、次のように定義される。すなわち、フィ
ルタリングマスクは、このように定義される。「MaskSchema Version」（マス
クスキーマバージョン）は、例えば上述のコンテナ構造
更新情報Ｍｓｇ．１におけるメッセージＩＤに相当し、
例えばこのフィルタリングマスクが生成される毎に１、
増加される値である。「Mask Value」（マスク値）は、
例えばビット列あるいはバイト単位で表されるマスクの
値である。

【０１５１】なお、マスク値の構造は、マスクスキーマ
バージョンによって対応付けられるマスクスキーマ（後
述する）によって規定される。マスクスキーマは、後述
する別のメッセージによって送信側レプリケータ１２か
ら受信側レプリケータ１７に通知される。

【０１５２】マスク値の割当方法について説明する。こ
の例では、あるコンテナエントリの配下のコンテナエン
トリのそれぞれを、所定ビット数からなるビット列で識
別する。受信側レプリケータ１７では、受信されたリー
フ更新情報Ｍｓｇ．ｘ１’中に記述されるマスク値を参
照することによってフィルタ処理を行い、必要なリーフ
更新情報Ｍｓｇ．ｘ１’を選択的に抽出することができ
る。

【０１５３】フィルタリングマスクのマスク値のビット
配列構造は、コンテナエントリの階層構造に対応させて
決定される。例えば図２３Ａに一例が示されるように、
図３で説明したエントリ名の記述方法に倣い、上位のコ
ンテナエントリＸの配下のエントリＸ．Ａ、Ｘ．Ｂ、
Ｘ．Ｃ、Ｘ．ＤおよびＸ．Ｅを互いに識別するために、
それぞれ３ビットのマスク値（０００）、（００１）、
（０１０）、（０１１）および（１００）が割り当てら
れる。なお、〔... 〕は、より上位のコンテナエントリ
が存在することを示す。

【０１５４】このようにマスク値が与えられた、コンテ
ナエントリＸの配下のコンテナエントリに対して、エン
トリの追加や削除が行われた場合、図２４のフローチャ
ートに従って処理が行われ、コンテナエントリの増減に
応じてマスク値の割り当てを行う。なお、以下では、コ
ンテナエントリの追加や削除が行われる前のコンテナ階
層を、更新前コンテナ階層と称する。更新前コンテナ階
層のマスク桁数Ｍ’は、送信側レプリケータ１２の例え
ばメモリに記憶されているものとする。

【０１５５】先ず、最初のステップＳ６０で、送信側レ
プリケータ１２によって、対象となるコンテナエントリ
の配下のコンテナエントリの数Ｎが取得される。コンテ
ナエントリ中の、配下のコンテナエントリのリストを参
照することで、コンテナエントリ数Ｎが求められる。次
のステップＳ６１では、Ｎ個の要素を一意に識別可能な
ビット数Ｍが選ばれ、マスクの桁数がＭ桁とされる。例
えば、上述した図２３Ａの例では、コンテナエントリＸ
は、配下のコンテナエントリを５個有しているので、５
個を一意に識別可能なビット数〔３〕がマスクの桁数と
される。

【０１５６】次に、ステップＳ６２で、上述のステップ
Ｓ６１で割り当てられたビット数Ｍが、対応する更新前
コンテナ階層に割り当てられたマスク桁数Ｍ’と同一か
どうかが判断される。若し、マスク桁数Ｍとマスク桁数
Ｍ’とが同一であれば、処理はステップＳ６３に移行す
る。

【０１５７】ステップＳ６３では、更新後のコンテナ階
層のコンテナエントリのうち、更新前コンテナ階層のコ
ンテナエントリに対応するエントリには、同一のマスク
値を割り当てる。さらに、次のステップＳ６４で、例え
ば更新後のコンテナ階層に新規にコンテナエントリの追
加が起こったなどして、更新後のコンテナ階層に、更新
前コンテナ階層に対応するコンテナエントリが存在しな
いコンテナエントリがあった場合、そのコンテナエント
リに対して、同一のコンテナ階層の他のコンテナエント
リのマスク値と重複しないようなマスク値が与えられ
る。

【０１５８】一方、上述のステップＳ６２で、マスク桁
数Ｍとマスク桁数Ｍ’とが同一ではないと判断された
ら、処理はステップＳ６５に移行し、当該コンテナ階層
の全コンテナエントリのそれぞれに対して、一意にマス
ク値が与えられる。

【０１５９】例えば、上述の図２３Ａの状態に、新たに
コンテナエントリ”... Ｘ．Ｆ”が追加され、図２３Ｂ
のようなコンテナ階層になったとする。コンテナエント
リ”... Ｘ”の配下のコンテナエントリ数Ｎは、６であ
り、一意に表現するためには３ビットが必要とされ、更
新後のコンテナエントリ”... Ｘ”の配下のコンテナ階
層のマスク桁数Ｍ＝３でる。更新前コンテナ階層のマス
ク桁数Ｍ’＝３であって、マスク桁数Ｍ’とマスク桁数
Ｍとは等しい。したがって、図２３Ｂに示される各コン
テナエントリ”... Ｘ．Ａ”、”... Ｘ．Ｂ”、”...
Ｘ．Ｃ”、”... Ｘ．Ｄ”および”... Ｘ．Ｅ”は、更
新前コンテナ階層の対応するエントリのマスク値がそれ
ぞれ割り当てられる（ステップＳ６３）。一方、新規に
追加されたコンテナエントリ”... Ｘ．Ｆ”は、同じコ
ンテナ階層の他のコンテナエントリと重複しないよう
に、マスク値（１０１）が割り当てられる（ステップＳ
６４）。

【０１６０】また例えば、上述の図２３Ａの状態から、
コンテナエントリ”... Ｘ．Ｃ”を削除して、図２３Ｃ
のようなコンテナ階層になったとする。この場合、コン
テナエントリ”... Ｘ”配下のコンテナエントリ数Ｎ
は、４であり、２ビットのマスク桁数Ｍで各コンテナエ
ントリを識別可能なので、更新後のコンテナ階層のマス
ク桁数Ｍ＝２である。一方、更新前コンテナ階層のマス
ク桁数Ｍ’＝３であって、更新前と更新後とで、マスク
桁数が異なる。したがって、ステップＳ６５の処理によ
って、当該階層の全エントリに、マスク桁数Ｍ＝２で新
たにマスク値が割り当てられる。

【０１６１】さらに、図２３Ｃの状態に、新たにコンテ
ナエントリ”... Ｘ．Ｇ”が追加され、図２３Ｄの状態
になったとする。この場合、コンテナエントリ”...
Ｘ”配下のコンテナエントリ数Ｎは５であり、コンテナ
エントリを互いに識別するためには、マスク桁数Ｍ＝３
とする必要がある。マスク桁数Ｍが更新前のマスク桁数
Ｍ’＝２と異なるため、ステップＳ６５の処理によっ
て、コンテナエントリ”... Ｘ”の配下の全コンテナエ
ントリに、新たにマスク値が割り当てられる。

【０１６２】マスク値のビットアサインは、ディレクト
リ構造の上位側から、コンテナ階層順にシリアルになさ
れる。一方、この実施の一形態では、上述のように、同
一階層に存在するエントリ数によってマスク桁数が異な
る。また、エントリの削除や追加などによって、コンテ
ナ階層中のエントリ数が変化し、それに伴いマスク桁数
が変化する。そのため、マスク値を表すビット列中のど
のビットがどのコンテナエントリ（あるいはコンテナ階
層）に対応するかを判断し、マスク値を解釈するための
情報機構が必要となる。

【０１６３】この実施の一形態では、マスク値を解釈す
るための情報機構として、次に示すマスクスキーマ(Mas
kSchema)を定義する。マスクスキーマは、このように定義される。「MaskSchema Version」（マス
クスキーマバージョン）は、例えば上述のコンテナ構造
更新情報Ｍｓｇ．１におけるメッセージＩＤに相当し、
例えば対応するフィルタリングマスクが生成される毎に
１、増加される値である。「TotalMaskLength 」（全マ
スク長）は、全体のコンテナ階層に対応する、マスク値
全体のビット長を表す。すなわち、全マスク長は、ディ
レクトリ構造の全ての階層を表現するために必要なビッ
ト数に対応する。「Set of ContainerEntryMaskSchema
」（セットオブコンテナエントリマスクスキーマ）
は、後述する「 ContainerEntryMaskSchema 」（コンテ
ナエントリマスクスキーマ）の配列を表す。

【０１６４】上述のコンテナエントリマスクスキーマ
は、あるコンテナエントリに対応するフィルタリングマ
スクを規定する。すなわち、コンテナエントリマスクス
キーマは、このように定義される。「ContainerEntryName」（コン
テナエントリ名）は、対象となるコンテナエントリのエ
ントリ名を表す文字列である。「OffsetLength」（オフ
セット長）は、このコンテナエントリに対応するフィル
タリングマスクの、全マスク値の最初のビットからのオ
フセット値であり、「MaskLength」（マスク長）は、マ
スク値の桁数（ビット長）である。「AssignedMaskValu
e 」（割り当てマスク値）は、対象となるコンテナエン
トリに割り当てられたマスク値であり、ビット列で表さ
れる。

【０１６５】図２５を用いて、コンテナエントリマスク
スキーマの符号化について説明する。図２５Ａは、上述
の図２３Ａに対応する図であって、上位のコンテナエン
トリ”... Ｘ”の配下に、コンテナエントリ名”...
Ｘ．Ａ”、”... Ｘ．Ｂ”、”... Ｘ．Ｃ”、”...
Ｘ．Ｄ”および”... Ｘ．Ｅ”の５つのコンテナエント
リが存在し、それぞれ３桁のマスク長で以てマスク値が
割り当てられている。なお、ここでは説明のため、これ
ら５つのコンテナエントリは、配下に他のエントリを有
しないものとする。

【０１６６】図２５Ｂは、コンテナエントリ”... Ｘ．
Ｃ”のマスク値の一例を示す。この例では、オフセット
長が７７ビットであることから、コンテナエント
リ”... Ｘ．Ｃ”に３ビットのマスク長で割り当てられ
た割り当てマスク値が、コンテナエントリ”... Ｘ．
Ｃ”のマスク値の７８ビット目から開始される３ビット
であることが分かる。オフセット長に含まれる７７ビッ
トのマスク値は、コンテナエントリ”... Ｘ．Ｃ”より
上位のコンテナエントリに対応する割り当てマスク値で
ある。

【０１６７】このように、マスク値における対象コンテ
ナエントリの割り当てマスク値の位置が規定され、コン
テナエントリマスクスキーマが符号化される。

【０１６８】コンテナエントリマスクスキーマのより具
体的な例を示す。上述したコンテナエントリ”... Ｘ．
Ｃ”に対応するコンテナエントリマスクスキーマは、例
えば、このようになる。なお、括弧()内は、説明のためのもの
であって、実際に記述する必要は無い。

【０１６９】また、図２５Ａに示されるコンテナエント
リ”... Ｘ．Ｄに対応するコンテナエントリマスクスキ
ーマは、例えば、このようになる。

【０１７０】このときのマスクスキーマは、例えばマス
クスキーマバージョンを４９８、全マスク長を１３４ビ
ットとした場合、このようになる。上述の例では、コンテナエント
リ”... Ｘ．Ｃおよび”... Ｘ．Ｄのコンテナエントリ
マスクスキーマがマスクスキーマ中に記述されている
が、〔....〕の部分には、さらに他のコンテナエントリ
マスクスキーマが記述される。この例で分かるように、
マスクスキーマには、一つのディレクトリ構造における
全コンテナエントリに関するコンテナエントリマスクス
キーマが記述される。

【０１７１】なお、この例で、全マスク長が１３４ビッ
トとなっているのに対して、コンテナエントリ”...
Ｘ．Ｃおよび”... Ｘ．Ｄについてのコンテナエントリ
マスクスキーマでは、オフセット値が７７ビットおよび
マスク長が３ビットの、合計で８０ビットである。これ
は、これらコンテナエントリ”... Ｘ．Ｃおよび”...
Ｘ．Ｄの配下にも、さらにコンテナ階層が存在すること
を示している。

【０１７２】上述したマスクスキーマにおいて、コンテ
ナエントリ”... Ｘ．Ｃに対応するフィルタリングマス
クの符号化は、例えば、このようになる。なお、マスク値(Mask Value)は、〔０
１１〕以外の部分も全て、他の階層のコンテナエントリ
の割り当てマスク値からなるビットで埋められる。

【０１７３】同様に、コンテナエントリ”... Ｘ．Ｄに
対応するフィルタリングマスクの符号化は、例えば、このようになる。

【０１７４】送信側レプリケータ１２では、送信側サー
バ１１をモニタして、コンテナエントリの階層構造の変
更を検知して、上述したマスクスキーマの変更を行う。
したがって、受信側３において適切なフィルタ処理を行
うためには、送信側レプリケータ１２によって、階層構
造の変更に基づく差分更新情報の通知と共に、変更され
たマスクスキーマが受信側レプリケータ１７に通知され
る必要がある。

【０１７５】この実施の一形態では、マスクスキーマを
送信側レプリケータ１２から受信側レプリケータ１７に
通知するために、上述したコンテナ構造更新情報Ｍｓ
ｇ．１の構造に対して、マスクスキーマ構造を追加す
る。マスクスキーマ構造を追加されたコンテナ構造更新
情報Ｍｓｇ．１’を、このように定義する。マスクスキーマは、コンテナ階層
の構成が変更される毎に変更される可能性がある。その
ため、このコンテナ構造更新情報Ｍｓｇ．１’も、コン
テナ階層の構成の変更に応じて生成される。「MessageI
D 」（メッセージＩＤ）は、コンテナ構造更新情報Ｍｓ
ｇ．１’が生成される毎に１ずつ増加される整数であ
る。以下では、上述したコンテナ構造更新情報Ｍｓｇ．
１を、全てこのコンテナ構造更新情報Ｍｓｇ．１’に置
き替えるものとする。

【０１７６】送信側レプリケータ１２では、上述した図
１７のフローチャートにおけるステップＳ４６で、コン
テナ階層に対応させたフィルタリングマスクが付加され
たメッセージである、リーフ更新情報Ｍｓｇ．ｘ１’を
生成し、受信側レプリケータ１７に放送している。ここ
で、受信側３では、リーフ更新情報Ｍｓｇ．ｘ１’によ
る受信側レプリケータ１７でのフィルタ処理を行う前
に、受信側クライアント１５が必要としているコンテナ
階層の対象部分を特定しておく必要がある。

【０１７７】このため、受信側レプリケータ１７におい
て、対象となるコンテナ階層をフィルタ処理するための
マスクを列挙したリストを作成する。このリストを、タ
ーゲットマスクリストと称する。

【０１７８】図２６を用いてターゲットマスクリストに
ついて説明する。先ず、図２６Ａに示されるようなディ
レクトリ構造を想定する。図２６Ａのディレクトリ階層
は、最上位のルートエントリ以外は全てコンテナエント
リで構成されているものとする。各四角はコンテナエン
トリを表し、二重線の四角で示されるコンテナエントリ
は、例えばユーザの嗜好に基づき受信側クライアント１
５でフィルタ処理を行うように特定されたエントリであ
る。各エントリ内に表示された数字は、当該エントリ毎
に割り当てられたマスク値である。

【０１７９】図２６Ａに示されるように、ユーザの嗜好
に基づきフィルタ処理するように受信側クライアント１
５で特定されたコンテナエントリのそれぞれに対して、
マスク１〜５が割り当てられている。このディレクトリ
構造において、マスク１〜５の全マスク長分のマスク値
は、ディレクトリ構造を上位側から辿り、マスク１が

〔０００〕、マスク２が〔００１０〕マスク３が〔０１
０〕、マスク４が〔１００００〕およびマスク５が〔１
００１０〕となる。

【０１８０】図２６Ｂは、このように特定されたマスク
がリストとされたターゲットマスクリストの一例を示
す。ターゲットマスクリストは、ディレクトリの構造を
特定するスキーマバージョンと、ユーザの嗜好などに基
づき受信側クライアント１５で特定された上述したマス
ク値のリストとからなる。すなわち、このターゲットマ
スクリストは、スキーマバージョンで記述されたディレ
クトリ構造でのみ有効なリストである。

【０１８１】図２７は、ターゲットマスクリストを作成
する処理のフローチャートである。このフローチャート
は、受信側レプリケータ１７で実行される。先ず、最初
のステップＳ７０で、受信側レプリケータ１７によっ
て、コンテナ構造更新情報Ｍｓｇ．１’が受信される。
ステップＳ７１で、ステップＳ７０での受信がコンテナ
構造更新情報Ｍｓｇ．１’の初回の受信であるかどうか
が判断され、初回の受信であると判断されれば、処理は
ステップＳ７３に移行する。

【０１８２】ステップＳ７３では、受信されたコンテナ
構造更新情報Ｍｓｇ．１’のメッセージＩＤを、受信側
レプリケータ１７が有する、例えばメモリやハードディ
スクといった記録または記憶媒体に、コピー１０として
記憶される。

【０１８３】次のステップＳ７４で、受信されたコンテ
ナ構造更新情報Ｍｓｇ．１’の内容に基づき、コンテナ
階層を生成する。生成されたコンテナ階層を示す情報が
受信側レプリケータ１７から受信側クライアント１５に
提示され、特定すべきコンテナエントリの選択が促され
る。例えば、受信側クライアント１５では、所定の表示
手段を用いて、供給されたコンテナ階層を示す情報に基
づく表示を行う。ユーザは、この表示に基づき、所定の
方法で必要なコンテナエントリを選択する。選択された
コンテナエントリの情報は、受信側クライアント１５か
ら受信側レプリケータ１７に渡される。

【０１８４】なお、コンテナエントリの特定は、ユーザ
の直接的な選択によってなされるのに限定されない。例
えば、受信側クライアント１５によって、ユーザが照会
を行ったコンテナエントリの情報を蓄積し、蓄積された
情報に基づきユーザの嗜好の傾向を学習して自動的に必
要と思われるコンテナエントリを選択するようにもでき
る。さらに、ユーザによる直接的な選択と、学習による
自動的な選択とを併用することもできる。

【０１８５】このようにして、ステップＳ７４でコンテ
ナエントリが選択されると、ステップＳ７５で、選択さ
れたコンテナ階層に対応するフィルタリングマスクが設
定される。設定されたフィルタリングマスクの一覧は、
ターゲットマスクリストとして、例えば受信側レプリケ
ータ１７が有する、例えばメモリやハードディスクとい
った記録または記憶媒体に記憶される。

【０１８６】一方、上述のステップＳ７１で、コンテナ
構造更新情報Ｍｓｇ．１’の受信が初回ではないと判断
されれば、処理はステップＳ７２に移行する。ステップ
Ｓ７２では、受信されたコンテナ構造更新情報Ｍｓｇ．
１’のメッセージＩＤが、前回までのコンテナ構造更新
情報Ｍｓｇ．１’の受信によりステップＳ７３でコピー
１０として記憶媒体に記憶されたメッセージＩＤと同一
かどうかが判断される。

【０１８７】若し、両者が同一であると判断されたら、
処理はステップＳ７０に戻される。一方、ステップＳ７
３で両者が同一では無いと判断されたら、処理はステッ
プＳ７４に移行し、今回受信されたコンテナ構造更新情
報Ｍｓｇ．１’のメッセージＩＤが前回までのメッセー
ジＩＤの代わりに記憶媒体に記憶され、今回受信された
コンテナ構造更新情報Ｍｓｇ．１’に基づき以降の処理
が行われる。

【０１８８】上述した、リーフ更新情報Ｍｓｇ．ｘ１に
対してプリリクジットメッセージＩＤリストが追加され
たリーフ更新情報Ｍｓｇ．ｘ１”に、さらにフィルタリ
ングマスクリストを追加した場合の、図１６のフローチ
ャートにおけるステップＳ３２の処理を、図２８のフロ
ーチャートを用いて、より詳細に説明する。なお、プリ
リクジットメッセージＩＤリストとフィルタリングマス
クリストとが追加されたリーフ更新情報Ｍｓｇ．ｘ１
を、以下では、リーフ更新情報Ｍｓｇ．ｘ１＃と称す
る。

【０１８９】図２８のフローチャートによる処理は、全
て受信側レプリケータ１７上で行われる。最初のステッ
プＳ２８０で、送信側レプリケータ１２によって放送ネ
ットワーク２を介して放送されたリーフ更新情報Ｍｓ
ｇ．ｘ１＃が、受信側レプリケータ１７によって受信さ
れる。

【０１９０】次のステップＳ２８１で、ステップＳ２８
０で受信したリーフ更新情報Ｍｓｇ．ｘ１＃のフィルタ
リングマスクがターゲットマスクリスト中に存在するか
どうかが判断される。若し、存在しないと判断されれ
ば、処理はステップＳ２８０に戻される。一方、受信さ
れたリーフ更新情報Ｍｓｇ．ｘ１＃のフィルタリングマ
スクがターゲットマスクリスト中に存在すると判断され
れば、処理はステップＳ２８１に移行する。

【０１９１】ステップＳ２８２で、ステップＳ２８０で
の受信がリーフ更新情報Ｍｓｇ．ｘ１＃の初回の受信で
あるかどうかが判断される。若し、この受信が初回の受
信であると判断されたら、処理はステップＳ２８６に移
行する。ステップＳ２８６では、受信されたリーフ更新
情報Ｍｓｇ．ｘ１＃のメッセージＩＤが、受信側レプリ
ケータ１７が有する例えばメモリやハードディスクとい
った記録または記憶媒体に上に形成される、メッセージ
ＩＤリストに追記記録される。

【０１９２】次のステップＳ２８７では、受信されたリ
ーフ更新情報Ｍｓｇ．ｘ１＃の内容、すなわち、リーフ
更新情報Ｍｓｇ．ｘ１＃に記述された差分更新情報に基
づき、受信側サーバ１６で管理されているディレクトリ
情報のうち、対応するリーフエントリの内容が変更され
る。ステップＳ２８７の処理の後、処理はステップＳ２
８０に戻される。

【０１９３】一方、上述のステップＳ２８２で、ステッ
プＳ２８０でのリーフ更新情報Ｍｓｇ．ｘ１＃の受信が
初回の受信では無いと判断されたら、処理はステップＳ
２８３に移行する。ステップＳ２８３では、メッセージ
ＩＤリストが参照され、ステップＳ２８０で受信された
リーフ更新情報Ｍｓｇ．ｘ１＃のメッセージＩＤがメッ
セージＩＤリスト上に存在するかどうかが判断される。
若し、存在すると判断されたら、処理はステップＳ２８
０に戻される。

【０１９４】一方、ステップＳ２８３でメッセージＩＤ
リスト上に受信したリーフ更新情報Ｍｓｇ．ｘ１＃のメ
ッセージＩＤが存在しないと判断されたら、処理はステ
ップＳ２８４に移行する。ステップＳ２８４では、受信
したリーフ更新情報Ｍｓｇ．ｘ１＃のプリリクジットメ
ッセージＩＤリスト上のメッセージＩＤのうち、メッセ
ージＩＤリスト上に無いものがあるかどうかが判断され
る。若し、無いものが無い、すなわち、プリリクジット
メッセージＩＤリスト上のメッセージＩＤが全てメッセ
ージＩＤリストに存在すると判断されたら、処理は上述
したステップＳ２８６に移行する。

【０１９５】一方、ステップＳ２８４で、受信したリー
フ更新情報Ｍｓｇ．ｘ１＃のプリリクジットメッセージ
ＩＤリスト上のメッセージＩＤのうち、メッセージＩＤ
リストに無いものがあると判断されれば、処理はステッ
プＳ２８５に移行する。ステップＳ２８５では、メッセ
ージＩＤリストに無いメッセージＩＤを有するリーフ更
新情報Ｍｓｇ．ｘ１＃の取得がなされる。

【０１９６】このステップＳ２８５によるリーフ更新情
報Ｍｓｇ．ｘ１＃の取得は、例えば双方向に通信が可能
な双方向ネットワークで送信側レプリケータ１２と受信
側レプリケータ１７とを接続し、この双方向ネットワー
クを用いて行うことができる。

【０１９７】例えば、受信側レプリケータ１７から送信
側レプリケータ１２に対して、メッセージＩＤリストに
無いメッセージＩＤを有するリーフ更新情報Ｍｓｇ．ｘ
１＃が、双方向ネットワークを介して要求される。送信
側レプリケータ１２では、この要求に応じて、該当する
リーフ更新情報Ｍｓｇ．ｘ１＃を双方向ネットワークを
介して受信側レプリケータ１７に送信する。

【０１９８】また、ステップＳ２８５によるリーフ更新
情報Ｍｓｇ．ｘ１＃の取得は、上述に限らず、双方向ネ
ットワークでは、受信側レプリケータ１７から送信側レ
プリケータ１２に対する、メッセージＩＤリストに無い
メッセージＩＤを有するリーフ更新情報Ｍｓｇ．ｘ１＃
の要求のみ行い、送信側レプリケータ１２において、該
当するリーフ更新情報Ｍｓｇ．ｘ１＃を放送ネットワー
ク２を介して放送するようにしてもよい。

【０１９９】図２１を用いて既に説明したように、送信
側レプリケータ１２では、放送されたリーフ更新情報Ｍ
ｓｇ．ｘ１”がリポジトリに蓄積される。したがって、
上述の図２８のステップＳ２８５の処理の際に、送信側
レプリケータ１２は、受信側レプリケータ１７から双方
向ネットワークを介して要求されたリーフ更新情報Ｍｓ
ｇ．ｘ１”をリポジトリから取り出して、受信側レプリ
ケータ１７に対して送信する。

【０２００】上述したターゲットマスクリストは、複数
のグループに分割して、分割されたそれぞれのグループ
に一意に優先度（クラス）を割り当てることができる。
この、リストに列挙されたマスク値のそれぞれに優先度
が設けられたターゲットマスクリストを、以下、優先度
付きターゲットマスクリストと称する。優先度付きター
ゲットマスクリストは、受信側レプリケータ１７が有す
る、例えばメモリやハードディスクといった記録または
記憶媒体に記憶される。

【０２０１】優先度付きターゲットマスクリストについ
て、より具体的に説明する。図２９Ａのようなディレク
トリ構成を想定する。図２９Ａのディレクトリ階層は、
最上位のルートエントリ以外は全てコンテナエントリで
構成されているものとする。各四角はコンテナエントリ
を表し、二重線の四角で示されるコンテナエントリは、
例えばユーザの嗜好に基づき受信側クライアント１５で
フィルタ処理を行うように特定されたエントリである。
各エントリ内に表示された数字は、当該エントリ毎に割
り当てられた、マスク１〜６のマスク値である。二重線
の四角で示される各コンテナエントリのマスク値が列挙
され、ターゲットマスクリストが作成される。

【０２０２】図２９Ａに示されるように、ユーザの嗜好
に基づきフィルタ処理するように受信側クライアント１
５で特定されたコンテナエントリのそれぞれに対して、
マスク１〜６が割り当てられている。このディレクトリ
構造において、マスク１〜６の全マスク長分のマスク値
は、ディレクトリ構造を上位側から辿り、マスク１が

〔０００〕、マスク２が〔００１０〕マスク３が〔０１
０〕、マスク４が〔１００００〕およびマスク５が〔１
００１０〕となる。また、マスク６のマスク値は、〔１
０〕である。

【０２０３】ターゲットマスクリストに列挙された各マ
スク値に対して、優先度が設定され、優先度付きターゲ
ットマスクリストが作成される。一例として、クラスの
値が小さい方が優先度が高く、クラスの値が大きい方が
優先度が低い場合、マスク４に対応するエントリがユー
ザの嗜好を最も反映していて最も優先度が高く、優先度
がクラス１に設定される。マスク１およびマスク５に対
応するエントリは、マスク４に対応するエントリよりも
優先度が低いが、マスク２、３および６に対応する各エ
ントリよりも優先度が高く、優先度がクラス２に設定さ
れる。一方、マスク２、３および６に対応するエントリ
は、マスク１〜６に対応するエントリ中では、最もユー
ザの関心が薄く、優先度も低く設定され、クラス３とさ
れる。

【０２０４】図２９Ｂは、このようにして優先度クラス
が各エントリに対応するマスク値に設定された、優先度
付きターゲットマスクリストの一例を示す。優先度付き
ターゲットマスクリストは、ディレクトリの構造を特定
するスキーマバージョンと、ユーザの嗜好などに基づき
受信側クライアント１５で特定され、さらに優先度クラ
スが設定された、上述したマスク値のリストとからな
る。すなわち、この優先度付きターゲットマスクリスト
は、スキーマバージョンで記述されたディレクトリ構造
でのみ有効なリストである。

【０２０５】図３０は、優先度付きターゲットマスクリ
ストを作成する一例の処理のフローチャートである。こ
のフローチャートは、受信側レプリケータ１７で実行さ
れる。先ず、最初のステップＳ２７０で、受信側レプリ
ケータ１７によって、コンテナ構造更新情報Ｍｓｇ．
１’が受信される。ステップＳ２７１で、ステップＳ２
７０での受信がコンテナ構造更新情報Ｍｓｇ．１’の初
回の受信であるかどうかが判断され、初回の受信である
と判断されれば、処理はステップＳ２７３に移行する。

【０２０６】ステップＳ２７３では、受信されたコンテ
ナ構造更新情報Ｍｓｇ．１’のメッセージＩＤを、受信
側レプリケータ１７が有する、例えばメモリやハードデ
ィスクといった記録または記憶媒体に、コピー１１とし
て記憶される。

【０２０７】次のステップＳ２７４で、受信されたコン
テナ構造更新情報Ｍｓｇ．１’の内容に基づき、コンテ
ナ階層を生成する。生成されたコンテナ階層を示す情報
が受信側レプリケータ１７から受信側クライアント１５
に提示され、特定すべきコンテナエントリの選択ならび
に選択されたコンテナエントリに対する優先度の設定が
促される。例えば、受信側クライアント１５では、所定
の表示手段を用いて、供給されたコンテナ階層を示す情
報に基づく表示を行う。ユーザは、この表示に基づき、
所定の方法で必要なコンテナエントリを選択すると共
に、そのコンテナエントリに対する優先度を設定する。
選択されたコンテナエントリの情報および設定された優
先度の情報は、受信側クライアント１５から受信側レプ
リケータ１７に渡される。

【０２０８】なお、コンテナエントリの特定は、ユーザ
の直接的な選択によってなされるのに限定されない。例
えば、受信側クライアント１５によって、ユーザが照会
を行ったコンテナエントリの情報を蓄積し、蓄積された
情報に基づきユーザの嗜好の傾向を学習して自動的に必
要と思われるコンテナエントリを選択するようにもでき
る。さらに、ユーザによる直接的な選択と、学習による
自動的な選択とを併用することもできる。

【０２０９】また、選択されたコンテナエントリに対す
る優先度の設定も、上述では、受信側クライアント１５
に、ターゲットマスクリストを表示させ、ユーザに対し
て嗜好に応じて優先度を設定するように促すと説明した
が、これはこの例に限定されない。例えば、コンテナエ
ントリに対する過去のアクセスの実績に基づき学習や統
計処理を行い、その結果に基づき自動的に優先度を設定
するようにしてもよい。

【０２１０】このようにして、ステップＳ２７４でコン
テナエントリが選択されると、ステップＳ２７５で、選
択されたコンテナ階層に対応するフィルタリングマスク
が設定されると共に、設定されたフィルタリングマスク
に対して優先度が設定される。優先度が設定されたフィ
ルタリングマスクの一覧は、優先度付きターゲットマス
クリストとして、例えば受信側レプリケータ１７が有す
る、例えばメモリやハードディスクといった記録または
記憶媒体に記憶される。

【０２１１】一方、上述のステップＳ２７１で、コンテ
ナ構造更新情報Ｍｓｇ．１’の受信が初回ではないと判
断されれば、処理はステップＳ２７２に移行する。ステ
ップＳ２７２では、受信されたコンテナ構造更新情報Ｍ
ｓｇ．１’のメッセージＩＤが、前回までのコンテナ構
造更新情報Ｍｓｇ．１’の受信によりステップＳ２７３
でコピー７として記憶媒体に記憶されたメッセージＩＤ
と同一かどうかが判断される。

【０２１２】若し、両者が同一であると判断されたら、
処理はステップＳ２７０に戻される。一方、ステップＳ
２７３で両者が同一では無いと判断されたら、処理はス
テップＳ２７４に移行し、今回受信されたコンテナ構造
更新情報Ｍｓｇ．１’のメッセージＩＤが前回までのメ
ッセージＩＤの代わりに記憶媒体に記憶され、今回受信
されたコンテナ構造更新情報Ｍｓｇ．１’に基づき以降
の処理が行われる。

【０２１３】図３１は、図３０のフローチャートに従っ
て作成された優先度付きターゲットマスクリストに基づ
き、放送されたリーフ更新情報Ｍｓｇ．ｘ１＃を選択的
に受信する一例の処理を示すフローチャートである。な
お、ここで説明する例は、リーフ更新情報Ｍｓｇ．ｘ１
＃にプリリクジットメッセージＩＤリスト含まれていな
い場合の例である。

【０２１４】以下で、メッセージバッファおよびメッセ
ージキューは、受信側レプリケータ１７が有し、受信側
レプリケータ１７によって読み出し／書き込み可能とさ
れた、例えばメモリやハードディスクといった記憶媒体
の所定の記憶領域からなる。メッセージバッファは、デ
ータを溜め込むためのメモリであり、メッセージキュー
は、例えばＦＩＦＯ(First In-First Out)的に用いられ
るメモリである。

【０２１５】受信側レプリケータ１７は、優先度付きタ
ーゲットマスクリストに列挙されたフィルタリングマス
クを有するリーフ更新情報Ｍｓｇ．ｘ１＃を、放送ネッ
トワーク２で放送されたリーフ更新情報Ｍｓｇ．ｘ１＃
の中から選択的に受信する。このとき、フィルタリング
マスクに付された優先度に応じて、優先度の高いものか
ら処理を行う。このようにして取得されたリーフ更新情
報Ｍｓｇ．ｘ１＃により、上述した図１６のフローチャ
ートにおけるステップＳ３２の処理が実行される。

【０２１６】図３１において、最初のステップＳ１５０
で、受信されたメッセージ（リーフ更新情報Ｍｓｇ．ｘ
１＃）をメッセージバッファに溜め込む単位時間であ
る、メッセージバッファリング単位時間Ｔｂを設定す
る。それと共に、単位時間Ｔｂに基づき動作するタイマ
Ｔｍが起動される。単位時間Ｔｂは、例えば１０秒程度
〜１分程度に設定される。

【０２１７】メッセージバッファリング単位時間Ｔｂが
設定されたら、次のステップＳ１５１で、受信側レプリ
ケータ１７によって、放送ネットワーク２によって放送
されたリーフ更新情報Ｍｓｇ．ｘ１＃が受信される。受
信側レプリケータ１７では、記憶媒体に記憶されている
ターゲットマスクリストが参照され、受信されたリーフ
更新情報Ｍｓｇ．ｘ１＃に示されるフィルタリングマス
クが優先度付きターゲットマスクリストに存在するかど
うかが判断される（ステップＳ１５２）。

【０２１８】若し、ステップＳ１５２で、受信されたリ
ーフ更新情報Ｍｓｇ．ｘ１＃に示されるフィルタリング
マスクが優先度付きターゲットマスクリスト中に存在し
ないと判断されれば、処理はステップＳ１５７に移行す
る。ステップＳ１５７では、タイマＴｍにより、上述の
ステップＳ１５０で設定されたメッセージバッファリン
グ単位時間Ｔｂを超過していないとされたら、処理がス
テップＳ１５１に戻される。若し、ステップＳ１５７
で、単位時間Ｔｂを超過したとされれば、処理は後述す
るステップＳ１５８に移行する。

【０２１９】一方、上述のステップＳ１５２で、当該フ
ィルタリングマスクが優先度付きターゲットマスクリス
ト中に存在すると判断されれば、処理はステップＳ１５
３に移行し、ステップＳ１５１での受信がリーフ更新情
報Ｍｓｇ．ｘ１＃の初回の受信であるかどうかが判断さ
れる。若し、初回の受信であるとされれば、処理ステッ
プＳ１５５へ移行し、受信されたリーフ更新情報Ｍｓ
ｇ．ｘ１＃に示されるメッセージＩＤが、受信側レプリ
ケータ１７が有する、例えばメモリやハードディスクと
いった記録または記憶媒体に、コピー１２として記憶さ
れる。そして、次のステップＳ１５６で、受信されたリ
ーフ更新情報Ｍｓｇ．ｘ１＃がメッセージバッファに記
録され、溜め込まれる。

【０２２０】一方、ステップＳ１５３で、上述のステッ
プＳ１５１でのリーフ更新情報Ｍｓｇ．ｘ１＃の受信が
初回の受信では無いと判断されたら、処理はステップＳ
１５４に移行する。ステップＳ１５４では、受信された
リーフ更新情報Ｍｓｇ．ｘ１＃のメッセージＩＤが、前
回までのリーフ更新情報Ｍｓｇ．ｘ１＃の受信によりス
テップＳ１５５でコピー１２として記憶媒体に記憶され
たメッセージＩＤと同一かどうかが判断される。

【０２２１】若し、ステップＳ１５４で両者が同一であ
ると判断されたら、処理はステップＳ１５７に移行し、
タイマＴｍに示される時間情報に基づき、メッセージバ
ッファリング単位時間Ｔｂを超過していなければ処理が
ステップＳ１５１に戻され、単位時間Ｔｂを超過してい
れば、処理がステップＳ１５８に移行する。

【０２２２】一方、ステップＳ１５４で両者が同一では
無いと判断されたら、処理は上述したステップＳ１５５
に移行し、今回受信されたリーフ更新情報Ｍｓｇ．ｘ１
＃のメッセージＩＤが前回までのメッセージＩＤの代わ
りにコピー１２として記憶媒体に記憶され、ステップＳ
１５６で、リーフ更新情報Ｍｓｇ．ｘ１＃がメッセージ
バッファに溜め込まれ、処理がステップＳ１５７に移行
される。

【０２２３】上述したように、ステップＳ１５７で、タ
イマＴｍに示される時間情報に基づき、メッセージバッ
ファリング単位時間Ｔｂを超過したと判断されたら、処
理はステップＳ１５８に移行する。ステップＳ１５８で
は、優先度付きターゲットマスクリストが参照され、メ
ッセージバッファに溜め込まれた複数のリーフ更新情報
Ｍｓｇ．ｘ１＃が優先度クラス毎に分類される。そし
て、次のステップＳ１５９で、優先度の高いクラスのリ
ーフ更新情報Ｍｓｇ．ｘ１＃から順に、メッセージキュ
ーに格納され、処理はステップＳ１５０に戻される。

【０２２４】例えば、上述した図２９Ｂのように優先度
付きターゲットマスクリストが設定された場合、受信側
によって、次に記す５つのリーフ更新情報Ｍｓｇ．ｘ１
＃を、所定の単位時間内に受信したものとする。すなわ
ち、各々のＭｓｇ．ｘ１＃をＭｓｇ．−００Ｘと表し、Ｍｓｇ．−００１：マスク３で選択されるコンテナエン
トリ配下のリーフエントリに対するリーフ更新情報、Ｍｓｇ．−００２：マスク１で選択されるコンテナエン
トリ配下のリーフエントリに対するリーフ更新情報、Ｍｓｇ．−００３：マスク５で選択されるコンテナエン
トリ配下のリーフエントリに対するリーフ更新情報、Ｍｓｇ．−００４：マスク４で選択されるコンテナエン
トリ配下のリーフエントリに対するリーフ更新情報、Ｍｓｇ．−００５：マスク６で選択されるコンテナエン
トリ配下のリーフエントリに対するリーフ更新情報、これら５つのリーフ更新情報Ｍｓｇ．ｘ１＃が受信側に
受信されたとする。

【０２２５】この場合には、リーフ更新情報Ｍｓｇ．ｘ
１＃の処理の順序付けは、各リーフ更新情報Ｍｓｇ．ｘ
１＃を優先度クラスと対応付けて、１．Ｍｓｇ．−００４（クラス１）２．Ｍｓｇ．−００３（クラス２）３．Ｍｓｇ．−００２（クラス２）４．Ｍｓｇ．−００５（クラス３）５．Ｍｓｇ．−００１（クラス３）このような順序となる。すなわち、この順序で各リーフ
更新情報Ｍｓｇ．ｘ１＃がメッセージキューに格納され
る。

【０２２６】メッセージキューに格納されたリーフ更新
情報Ｍｓｇ．ｘ１＃は、格納された順にメッセージキュ
ーから出力され、受信側レプリケータ１７のリーフエン
トリの更新処理を行うモジュール（図示しない）に渡さ
れる。リーフエントリ更新処理モジュールでは、渡され
たリーフ更新情報Ｍｓｇ．ｘ１＃を用いて、上述した図
１６のフローチャートのステップＳ３２によるリーフエ
ントリの更新処理が行われる。リーフエントリの更新処
理と、図３１のフローチャートによる、リーフ更新情報
Ｍｓｇ．ｘ１＃をメッセージバッファに溜め込む処理と
は、並列的に行われる。

【０２２７】なお、受信側レプリケータ１７において、
更新処理を行うために必要なリソースに制約がある場
合、例えば、処理時間の制約、メモリなどの記憶容量の
制約、あるいは、ＣＰＵの処理能力に制約がある場合な
どは、受信側レプリケータ１７で処理可能なリーフ更新
情報Ｍｓｇ．ｘ１＃の数に制限が生じる。すなわち、メ
ッセージキューの長さに制限がある。この場合には、メ
ッセージキューに格納できないリーフ更新情報Ｍｓｇ．
ｘ１＃は、破棄される。

【０２２８】一例として、例えば２秒間といった所定の
単位時間に、メッセージバッファに溜め込まれたリーフ
更新情報Ｍｓｇ．ｘ１＃の処理が全て行えないような場
合、高い優先度クラスのリーフ更新情報Ｍｓｇ．ｘ１＃
から順に処理が行われることになる。

【０２２９】次に、リーフ更新情報にフィルタリングマ
スクが追加されたリーフ更新情報Ｍｓｇ．ｘ１＃に対し
て、さらに、上述したプリリクジットメッセージＩＤリ
ストを追加した場合の処理について説明する。以下で
は、プリリクジットメッセージＩＤリストが追加された
リーフ更新情報Ｍｓｇ．ｘ１＃を、リーフ更新情報Ｍｓ
ｇ．ｘ１＃と称する。

【０２３０】上述の図２９Ａに示されるディレクトリ構
造の、マスク６に対応するコンテナエントリの配下の２
つのコンテナエントリに、リーフエントリ１および２が
それぞれ追加される場合について、図３２を参照しなが
ら説明する。なお、図３２Ａおよび図３２Ｃに一例が示
されるディレクトリ構造は、図２９に示されるディレク
トリ構造から、マスク６に対応するコンテナエントリを
中心に抜き出したものである。

【０２３１】図３２Ａがリーフエントリ追加前のディレ
クトリ構造であり、図３２Ｂのような経過を経てリーフ
エントリが追加され、図３２Ｃに示されるディレクトリ
構造が構成される。送信側レプリケータ１２において、
送信側サーバ１１上のディレクトリ構造の、マスク６に
対応するコンテナエントリ１００の配下の、コンテナエ
ントリ１０１にリーフエントリ１０３が追加されたこと
が検知される。コンテナエントリ１０１に対してリーフ
エントリ１０３が追加されたことを示すコンテナ構造更
新情報Ｍｓｇ．１’（Ｍｓｇ．−００６とする）が、送
信側レプリケータ１２から受信側レプリケータ１７に対
して放送される。次に、同様にしてコンテナエントリ１
０２に対してリーフエントリ１０４が追加されたことが
送信側レプリケータ１２に検知され、送信側レプリケー
タ１２から受信側レプリケータ１７に対して、その旨示
すコンテナ構造更新情報Ｍｓｇ．１’（Ｍｓｇ．−００
７とする）が送信側レプリケータ１２から受信側レプリ
ケータ１７に対して放送される。

【０２３２】コンテナエントリの配下にリーフエントリ
が追加されたことで、リーフエントリの属性情報が変化
し、送信側レプリケータ１２によって、送信側サーバ１
１上の、このリーフエントリの変更が検知される。検知
結果に基づき、先ず、リーフエントリ１０４の属性変化
を示すリーフ更新情報Ｍｓｇ．ｘ１＃（Ｍｓｇ．−００
９とする）が生成され、送信側レプリケータ１２から受
信側レプリケータ１７に対して放送される。続いて、リ
ーフエントリ１０３の属性変化を示すリーフ更新情報Ｍ
ｓｇ．ｘ１＃（Ｍｓｇ．−００８とする）が生成され、
送信側レプリケータ１２から受信側レプリケータ１７に
放送される。

【０２３３】このとき、図３２Ｂに示されるように、若
し、Ｍｓｇ．−００６およびＭｓｇ．−００７が放送さ
れている間、受信側レプリケータ１７が例えば電源が投
入されていないなどの理由で休止し、その後、稼働した
ような場合、Ｍｓｇ．−００６およびＭｓｇ．−００７
は、受信されず、その後に放送されたＭｓｇ．−００９
およびＭｓｇ．−００８は受信される。

【０２３４】このとき、リーフエントリの属性変更を示
すＭｓｇ．−００９およびＭｓｇ．−００８は、コンテ
ナエントリに対するリーフエントリの追加を示すＭｓ
ｇ．−００６およびＭｓｇ．−００７を受信し取得して
いないと、意味を成さない。そこで、Ｍｓｇ．−００９
に対して、Ｍｓｇ．−００９による処理を行う前にＭｓ
ｇ．−００７の処理を行う必要があることを示すプリリ
クジットメッセージを追加し、上述した、リーフ更新情
報Ｍｓｇ．ｘ１”として、送信側レプリケータ１２から
受信側レプリケータ１７に放送する。Ｍｓｇ．−００８
についても、同様にして、Ｍｓｇ．−００６の処理を予
め行う必要があることを示すプリリクジットメッセージ
が追加された、上述のリーフ更新情報Ｍｓｇ．ｘ１”と
して放送される。

【０２３５】上述したように、図３２の例では、受信側
レプリケータ１７では、次の４つのメッセージを受信す
る。すなわち、Ｍｓｇ．−００６：マスク６で選択されるコンテナエン
トリ１０１の配下のリーフエントリ（リーフエントリ１
０３）を追加するコンテナ構造更新情報、Ｍｓｇ．−００７：マスク５で選択されるコンテナエン
トリ１０２の配下のリーフエントリ（リーフエントリ１
０４）を追加するコンテナ構造更新情報、Ｍｓｇ．−００８：マスク６で選択されるコンテナエン
トリ１０１の配下のリーフエントリ１０３の属性の一部
を変更する、プリリクジットメッセージ中にＭｓｇ．−
００６が指定されている、リーフ更新情報、Ｍｓｇ．−００９：マスク５で選択されるコンテナエン
トリ１０２の配下のリーフエントリ１０４の属性の一部
を変更する、プリリクジットメッセージ中にＭｓｇ．−
００７が指定されている、リーフ更新情報、これらの４つのメッセージが、例えば図３２Ａから図３
２Ｃまでの期間に受信側レプリケータ１７に受信され
る。上述したように、Ｍｓｇ．−００６およびＭｓｇ．
−００７は、受信側レプリケータ１７が休止しているた
め、取りこぼされている。

【０２３６】このとき、リーフ更新情報Ｍｓｇ．ｘ１＃
の処理の順序付けは、各リーフ更新情報Ｍｓｇ．ｘ１＃
を優先度クラスと対応付けて、１．Ｍｓｇ．−００７（クラス２）２．Ｍｓｇ．−００９（クラス２）３．Ｍｓｇ．−００６（クラス３）４．Ｍｓｇ．−００８（クラス３）例えばこのようになる。すなわち、この順序で各リーフ
更新情報Ｍｓｇ．ｘ１＃がメッセージキューに格納され
る。受信側レプリケータ１７に取りこぼされたＭｓｇ．
−００７およびＭｓｇ．−００６は、それぞれＭｓｇ．
−００９およびＭｓｇ．−００８による処理の前に必須
な処理である。そのため、Ｍｓｇ．−００７およびＭｓ
ｇ．−００６は、それぞれＭｓｇ．−００９およびＭｓ
ｇ．−００８の前に置かれる。

【０２３７】受信側レプリケータ１７では、Ｍｓｇ．−
００９およびＭｓｇ．−００８の処理を行う前に、例え
ば受信側レプリケータ１７と送信側レプリケータ１２と
を双方向に接続する双方向ネットワークを設け、この双
方向ネットワークを用いて、Ｍｓｇ．−００７およびＭ
ｓｇ．−００６の順で送信側レプリケータ１２から取得
する必要がある。このとき、受信側レプリケータ１７あ
るいは送信側レプリケータ１２、または、双方向ネット
ワーク４そのものの処理資源の制約などにより、例えば
Ｍｓｇ．−００７の取得は可能であるが、Ｍｓｇ．−０
０６は取得できないような場合が考えられる。このとき
には、Ｍｓｇ．−００８による処理は、見送られる。

【０２３８】図３３は、優先度付きターゲットマスクリ
ストに基づき、放送されたリーフ更新情報Ｍｓｇ．ｘ１
＃を選択的に受信する処理において、プリリクジットメ
ッセージＩＤリストを適用した一例の処理を示すフロー
チャートである。

【０２３９】図３３において、最初のステップＳ１７０
で、後述するステップＳ１７１で受信されたメッセージ
（リーフ更新情報Ｍｓｇ．ｘ１＃）をメッセージバッフ
ァに溜め込む単位時間である、メッセージバッファリン
グ単位時間Ｔｂを設定する。それと共に、単位時間Ｔｂ
に基づき動作するタイマＴｍが起動される。単位時間Ｔ
ｂは、例えば１０秒程度〜１分程度に設定される。

【０２４０】メッセージバッファリング単位時間Ｔｂが
設定されたら、次のステップＳ１７１で、受信側レプリ
ケータ１７によって、放送ネットワーク２によって放送
されたリーフ更新情報Ｍｓｇ．ｘ１＃が受信される。上
述したように、リーフ更新情報Ｍｓｇ．ｘ１＃は、リー
フ更新情報Ｍｓｇ．１’にプリリクジットメッセージＩ
Ｄリストを追加したものである。受信側レプリケータ１
７では、記憶媒体に記憶されているターゲットマスクリ
ストが参照され、受信されたリーフ更新情報Ｍｓｇ．ｘ
１＃に示されるフィルタリングマスクが優先度付きター
ゲットマスクリストに存在するかどうかが判断される
（ステップＳ１７２）。

【０２４１】若し、ステップＳ１７２で、受信されたリ
ーフ更新情報Ｍｓｇ．ｘ１＃に示されるフィルタリング
マスクが優先度付きターゲットマスクリスト中に存在し
ないと判断されれば、処理はステップＳ１８０に移行す
る。ステップＳ１８０では、タイマＴｍにより、上述の
ステップＳ１７０で設定されたメッセージバッファリン
グ単位時間Ｔｂを超過していないとされたら、処理がス
テップＳ１７１に戻される。若し、ステップＳ１８０
で、単位時間Ｔｂを超過したとされれば、処理は後述す
るステップＳ１８１に移行する。

【０２４２】一方、上述のステップＳ１７２で、当該フ
ィルタリングマスクが優先度付きターゲットマスクリス
ト中に存在すると判断されれば、処理はステップＳ１７
３に移行し、ステップＳ１７１での受信がリーフ更新情
報Ｍｓｇ．ｘ１＃の初回の受信であるかどうかが判断さ
れる。若し、初回の受信であるとされれば、処理ステッ
プＳ１７８へ移行し、受信されたリーフ更新情報Ｍｓ
ｇ．ｘ１＃に示されるメッセージＩＤが履歴リストに記
録される。履歴リストは、受信側レプリケータ１７が有
する、例えばメモリやハードディスクといった記録また
は記憶媒体の所定領域に形成されるものである。次のス
テップＳ１７９で、受信されたリーフ更新情報Ｍｓｇ．
ｘ１＃がメッセージバッファに溜め込まれる。

【０２４３】一方、ステップＳ１７３で、上述のステッ
プＳ１７１でのリーフ更新情報Ｍｓｇ．ｘ１＃の受信が
初回の受信では無いと判断されたら、処理はステップＳ
１７４に移行する。ステップＳ１７４では、受信された
リーフ更新情報Ｍｓｇ．ｘ１＃のメッセージＩＤと一致
するものが、前回までのリーフ更新情報Ｍｓｇ．ｘ１＃
の受信によりステップＳ１７８で履歴リストに記録され
たメッセージＩＤの中にあるかどうかが判断される。

【０２４４】若し、ステップＳ１７４で一致するものが
あると判断されたら、処理はステップＳステップＳ１８
０に移行し、タイマＴｍに示される時間情報に基づき、
メッセージバッファリング単位時間Ｔｂを超過していな
ければ処理がステップＳ１７１に戻され、単位時間Ｔｂ
を超過していれば、処理がステップＳ１８１に移行す
る。

【０２４５】一方、ステップＳ１７４で一致するものが
無いと判断されたら、処理はステップＳ１７５に移行す
る。ステップＳ１７５では、受信されたリーフ更新情報
Ｍｓｇ．ｘ１＃中のプリリクジットメッセージＩＤリス
トに記されるメッセージＩＤのうち、履歴リストに無い
ものがあるかどうかが判断される。若し、受信されたリ
ーフ更新情報Ｍｓｇ．ｘ１＃中のプリリクジットメッセ
ージＩＤリストに記されるメッセージＩＤの全てが、履
歴リストに記録されていると判断されれば、処理はステ
ップＳ１７８に移行し、受信されたリーフ更新情報Ｍｓ
ｇ．ｘ１＃が履歴リストに記録される。

【０２４６】一方、ステップＳ１７５で、受信されたリ
ーフ更新情報Ｍｓｇ．ｘ１＃中のプリリクジットメッセ
ージＩＤリストに記されるメッセージＩＤのうち、履歴
リストに記録されていないものがあると判断されれば、
処理はステップＳ１７６に移行する。ステップＳ１７６
では、受信されたリーフ更新情報Ｍｓｇ．ｘ１＃中のプ
リリクジットメッセージＩＤリストに記されるメッセー
ジＩＤのうち、履歴リストに記録されていないメッセー
ジＩＤのリーフ更新情報Ｍｓｇ．ｘ１＃の取得がなされ
る。メッセージＩＤの取得は、例えば、上述した、受信
側レプリケータ１７と送信側レプリケータ１２とを接続
する双方向ネットワークを用いてなされる。取得された
リーフ更新情報Ｍｓｇ．ｘ１＃のメッセージＩＤは、次
のステップＳ１７７で、履歴リストに追加して記録され
る。履歴リストへの追加記録が終了すると、処理はステ
ップＳ１７８に移行する。

【０２４７】ステップＳ１７８では、上述したように、
受信されたリーフ更新情報Ｍｓｇ．ｘ１＃のメッセージ
ＩＤが履歴リストへ記録される。そして、次のステップ
Ｓ１７９で、受信されたリーフ更新情報Ｍｓｇ．ｘ１＃
がメッセージバッファに溜め込まれ、処理は次のステッ
プＳ１８０に移行する。

【０２４８】ステップＳ１８０では、上述したように、
タイマＴｍに示される時間情報に基づき、メッセージバ
ッファリング単位時間Ｔｂを超過したかどうかが判断さ
れる。若し、単位時間Ｔｂを超過したと判断されたら、
処理はステップＳ１８１に移行する。

【０２４９】ステップＳ１８１では、優先度付きターゲ
ットマスクリストが参照され、メッセージバッファに溜
め込まれた複数のリーフ更新情報Ｍｓｇ．ｘ１＃が優先
度クラス毎に分類される。そして、次のステップＳ１８
２で、優先度の高いクラスのリーフ更新情報Ｍｓｇ．ｘ
１＃から順に、メッセージキューに格納され、処理はス
テップＳ１７０に戻される。

【０２５０】次に、上述した全構成情報通知周期タイマ
Ｔ₁’およびＴ₁’の設定の方法について説明する。上
述したように、この実施の一形態においては、コンテナ
構造項新情報Ｍｓｇ．１’を放送するタイミングを決定
する際に用いる全構成情報通知周期タイマＴ₁’と、リ
ーフ更新情報Ｍｓｇ．ｘ１＃を放送するタイミングを決
定する際に用いる全構成情報通知周期タイマＴ₁’の２
種類のタイマは、それぞれ個別に値を設定することがで
きる。また、これらタイマＴ₁’およびＴ₁’は、設定
された値を任意の時点で変更することが可能とされてい
る。

【０２５１】この実施の一形態では、送信側１（送信側
レプリケータ１２）が受信側３（受信側レプリケータ１
７）の稼働状態を所定の方法でモニタし、モニタ結果に
基づきタイマＴ₁’およびＴ₁’の値を設定する。タイ
マＴ₁’およびＴ₁’の値を、それぞれ受信側３の稼働
状態に応じて、例えば時間帯毎に異なる値に設定する。

【０２５２】図３４は、全構成情報通知周期タイマ
Ｔ₁’およびＴ₁’の値を設定する処理の一例のフロー
チャートである。先ず、最初のステップＳ１４０で、受
信側レプリケータ１７が自身の稼働状況をモニタする。
すなわち、受信側レプリケータ１７の稼働状況が所定単
位時間毎にモニタされ、稼働状況の時間変動が受信側レ
プリケータ１７が有する、例えばメモリやハードディス
クといった記録または記憶媒体に記憶される。稼働状況
は、例えば、受信側レプリケータ１７の稼働時間、すな
わち、受信側レプリケータ１７における２種類の更新メ
ッセージを受信処理している時間を、各時間帯毎に累積
して得る。

【０２５３】モニタされ記憶された受信側レプリケータ
１７の稼働状況を示すデータは、次のステップＳ１４１
で送信側レプリケータ１２に通知される。受信側レプリ
ケータ１７から送信された稼働状況情報は、双方向ネッ
トワーク４を介して送信側レプリケータ１２に送信さ
れ、通知される。

【０２５４】送信側レプリケータ１２では、双方向ネッ
トワーク４を介して送られた受信側レプリケータ１７の
稼働状況情報を受信し、受信された稼働状況情報に基づ
き所定の統計処理を行う（ステップＳ１４２）。統計処
理は、例えば複数の受信側レプリケータ１７から送られ
た稼働状況情報を単位時間毎に累積することで行われ
る。この統計処理の結果、受信側レプリケータ１７の稼
働状況の時間変動統計情報が得られる。得られた時間変
動統計情報は、送信側レプリケータ１２に記憶される。

【０２５５】次のステップＳ１４３で、送信側レプリケ
ータ１２において、上述のステップＳ１４２での統計処
理結果に基づき、全構成情報通知周期タイマＴ₁’およ
びＴ₁’がセットされる。

【０２５６】例えば、ステップＳ１４２における統計処
理の結果が図３５に一例が示されるように得られたとす
る。なお、図３５において、横軸は、例えば一日におけ
る時刻を表す。縦軸が受信側レプリケータ１７の稼働率
を表し、一日のうち領域ｂの時間帯が稼働率の高い時間
帯で、領域ａおよび領域ｃは、一日のうち稼働率の比較
的低い時間帯であることが示されている。

【０２５７】この図３５のような統計結果に対して、例
えば、領域ａ、領域ｂおよび領域ｃに、それぞれ異なる
値で全構成情報通知周期タイマＴ₁’およびＴ₁’がセ
ットされる。領域ｂでは、領域ａおよび領域ｃよりも稼
働率が高く、送信側１からの放送に対する受信側３のア
クセス率が高いと考えられる。したがって、領域ｂの期
間は、タイマＴ₁’あるいはＴ₁’の設定時間を大きく
して、差分更新情報を放送する周期を長くしても、放送
された差分更新情報を受信側３が取りこぼす確率が他の
２つの領域ａおよびｃに比べて低いと予想される。

【０２５８】そのため、一例として、領域ｂのように、
受信側レプリケータ１７の稼働率の高い領域ではタイマ
Ｔ₁’およびＴ₁’の設定値を大きくして差分更新情報
の放送周期を長くして、他の２つの領域ａおよびｃで
は、タイマＴ₁’およびＴ₁’の設定値を小さく取り差
分更新情報の放送周期を短くすることが考えられる。こ
のように、この実施の一形態では、通信資源を多く消費
する全構成情報通知の頻度を、受信側３の稼働率に応じ
て動的に変更することができるようにしている。それに
より、ディレクトリ構造の差分更新情報の通知を、効率
的に行うことができる。

【０２５９】

【発明の効果】以上説明したように、この発明によれ
ば、サーバに管理されたディレクトリ構造を放送する際
に、ディレクトリ構造に生じた変化を検知してその変化
の差分を示す差分更新情報を放送すると共に、差分更新
情報の放送の際に、受信側でその差分更新情報を用いて
処理をする前に既に処理されていなければいけない差分
更新情報が追加されるため、受信側では、例え差分更新
情報の取りこぼしがあった場合でも、限られたコストで
も不整合無く、ディレクトリ構造の更新を行うことがで
きる効果がある。

【０２６０】また、この実施の一形態によれば、送信側
からの、サーバに管理されたディレクトリ構造に生じた
変化を検知した検知結果に基づく差分更新情報の放送を
受信する受信側において、受信された差分更新情報をユ
ーザの嗜好などに応じて選択的に処理することができる
と共に、選択の際に、差分更新情報に対して優先度を設
けるようにされているため、ユーザ側の処理のリソース
に制限がある場合でも、必要な差分更新情報から順に処
理を行うことができる効果がある。

【図面の簡単な説明】

【図１】この発明に適用できる系の一例を示す略線図で
ある。

【図２】複数の受信側が放送ネットワークに接続される
ことを説明するための略線図である。

【図３】ディレクトリ構造を説明するための略線図であ
る。

【図４】コンテナエントリの構造の一例を示す略線図で
ある。

【図５】リーフエントリの構造の一例を示す略線図であ
る。

【図６】送信側レプリケータの機能を説明するための機
能ブロック図である。

【図７】受信側クライアントの機能を説明するための機
能ブロック図である。

【図８】受信側サーバの機能を説明するための機能ブロ
ック図である。

【図９】ディレクトリ構造の差分更新情報について説明
するための略線図である。

【図１０】ディレクトリ構造の差分更新情報について説
明するための略線図である。

【図１１】ディレクトリ構造の全構成情報について説明
するための略線図である。

【図１２】ディレクトリ構造の全構成情報について説明
するための略線図である。

【図１３】コンテナエントリの同期管理方法を説明する
ためのフローチャートである。

【図１４】コンテナエントリの同期管理方法をより詳細
に説明するためのフローチャートである。

【図１５】コンテナエントリの同期管理方法をより詳細
に説明するためのフローチャートである。

【図１６】リーフエントリの同期管理方法を説明するた
めのフローチャートである。

【図１７】リーフエントリの同期管理方法をより詳細に
説明するためのフローチャートである。

【図１８】リーフエントリの同期管理方法をより詳細に
説明するためのフローチャートである。

【図１９】差分更新通知履歴テーブルの一例を示す略線
図である。

【図２０】プリリクジットメッセージＩＤリストを用い
た場合の、リーフエントリの同期管理方法をより詳細に
説明するためのフローチャートである。

【図２１】送信側レプリケータで過去に放送されたリー
フ更新情報Ｍｓｇ．ｘ１”を保存する一例の処理のフロ
ーチャートである。

【図２２】プリリクジットメッセージＩＤリストを用い
た場合の、リーフエントリの同期管理方法をより詳細に
説明するためのフローチャートである。

【図２３】フィルタリングマスクのマスク値のビット配
列構造を説明するための略線図である。

【図２４】エントリの追加や削除が行われた場合の、コ
ンテナエントリの増減に応じたマスク値の割り当て処理
のフローチャートである。

【図２５】コンテナエントリマスクスキーマの符号化を
説明するための略線図である。

【図２６】ターゲットマスクリストを説明するための略
線図である。

【図２７】ターゲットマスクリストを作成する処理のフ
ローチャートである。

【図２８】プリリクジットメッセージＩＤリストとター
ゲットマスクリストとを用いた場合の、リーフエントリ
の同期管理方法をより詳細に説明するためのフローチャ
ートである。

【図２９】優先度付きターゲットマスクリストを説明す
るための略線図である。

【図３０】優先度付きターゲットマスクリストを作成す
る一例の処理のフローチャートである。

【図３１】優先度付きターゲットマスクリストに基づ
き、放送されたリーフ更新情報Ｍｓｇ．ｘ１＃を選択的
に受信する一例の処理を示すフローチャートである。

【図３２】ディレクトリ構造がリーフエントリを追加さ
れて変更される例を示す略線図である。

【図３３】優先度付きターゲットマスクリストに基づ
き、放送されたリーフ更新情報Ｍｓｇ．ｘ１＃を選択的
に受信する処理において、プリリクジットメッセージＩ
Ｄリストを適用した一例の処理を示すフローチャートで
ある。

【図３４】全構成情報通知周期タイマの値を設定する処
理の一例のフローチャートである。

【図３５】受信側の稼働率の統計処理の一例の結果を示
す略線図である。

【図３６】受信側で一定期間、ディレクトリサーバから
の差分更新データを受信できない例を示す略線図であ
る。

【図３７】受信側で、取りこぼした差分更新情報が必ず
しも必要ない場合があることを説明するための略線図で
ある。

【符号の説明】

１・・・送信側、２・・・放送ネットワーク、３・・・
受信側、１０・・・送信側ディレクトリサービスクライ
アント、１１・・・送信側ディレクトリサーバ、１２・
・・送信側ディレクトリサーバレプリケータ、１５・・
・受信側ディレクトリサービスクライアント、１６・・
・受信側ディレクトリサーバ、１７・・・受信側ディレ
クトリサーバレプリケータ、Ｍｓｇ．ｘ１・・・リーフ
更新情報

───────────────────────────────────────────────────── フロントページの続き (72)発明者原岡和生東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者権野善久東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者西尾郁彦東京都品川区北品川６丁目７番35号ソニー株式会社内 (56)参考文献特開平11−220493（ＪＰ，Ａ) 特開平11−219330（ＪＰ，Ａ) 特開平８−185348（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 G06F 13/00 H04L

Claims

(57)【特許請求の範囲】

【請求項１】コンテンツの所在を階層的に管理するデ
ィレクトリの階層構造を送信する送信装置において、上記ディレクトリの階層構造の節点であって自分の配下
の節点の情報を格納可能なコンテナエントリと、上記コ
ンテナエントリの配下にあって、自分の配下の節点の情
報を格納できないリーフエントリとからなるディレクト
リの階層構造を管理する管理手段と、上記管理手段に管理される上記ディレクトリの階層構造
の変化を検出し、該検出の結果に基づき、上記リーフエ
ントリの変化の差分からなる差分情報を求める検出手段
と、上記コンテナエントリと、該コンテナエントリの配下に
あった上記リーフエントリに対応する上記差分情報を示
す識別子とを関連付けたテーブルと、上記差分情報と、該差分情報に対応する先行条件識別子
とを共に送信する送信手段とを有し、上記先行条件識別子は、上記差分情報による上記リーフ
エントリの更新処理を行う際に既に処理されていなけれ
ばならない差分情報を示す識別子であって、上記テーブ
ルを参照して、上記差分情報に対応する上記リーフエン
トリの上位のコンテナエントリに関連付けられた上記識
別子として求められることを特徴とする送信装置。
【請求項２】請求項１に記載の送信装置において、上記検出手段で求められた上記差分情報を蓄積する差分
情報蓄積手段と、上記送信手段による送信を受信する受信側からの通信を
受信する受信手段とをさらに有し、上記受信手段によって受信された上記受信側からの要求
に基づき、上記差分情報蓄積手段に蓄積された上記差分
情報を上記受信側に送信するようにしたことを特徴とす
る送信装置。
【請求項３】請求項１に記載の送信装置において、上記検出手段は、上記検出の結果に基づき、上記コンテ
ナエントリのそれぞれの上記ディレクトリの階層構造上
での位置を示す位置情報と、上記リーフエントリのそれ
ぞれを上記ディレクトリの階層構造に基づき識別するリ
ーフエントリ識別情報とをさらに取得し、上記送信手段は、上記差分情報と該差分情報に対応する
上記先行条件識別子と共に、上記位置情報および上記リ
ーフエントリ識別情報を送信するようにしたことを特徴
とする送信装置。
【請求項４】コンテンツの所在を階層的に管理するデ
ィレクトリの階層構造を送信する送信方法において、上記ディレクトリの階層構造の節点であって自分の配下
の節点の情報を格納可能なコンテナエントリと、上記コ
ンテナエントリの配下にあって、自分の配下の節点の情
報を格納できないリーフエントリとからなるディレクト
リの階層構造を管理する管理のステップと、上記管理のステップに管理される上記ディレクトリの階
層構造の変化を検出し、該検出の結果に基づき、上記リ
ーフエントリの変化の差分からなる差分情報を求める検
出のステップと、上記コンテナエントリと、該コンテナエントリの配下に
あった上記リーフエントリに対応する上記差分情報を示
す識別子とを関連付けたテーブルを作成するステップ
と、上記差分情報と、該差分情報に対応する先行条件識別子
とを共に送信する送信のステップとを有し、上記先行条件識別子は、上記差分情報による上記リーフ
エントリの更新処理を行う際に既に処理されていなけれ
ばならない差分情報を示す識別子であって、上記テーブ
ルを参照して、上記差分情報に対応する上記リーフエン
トリの上位のコンテナエントリに関連付けられた上記識
別子として求められることを特徴とする送信方法。
【請求項５】送信された、コンテンツの所在を階層的
に管理するディレクトリの階層構造を受信する受信装置
において、送信側から、上記ディレクトリの階層構造の節点であっ
て自分の配下の節点の情報を格納可能なコンテナエント
リと、上記コンテナエントリの配下にあって、自分の配
下の節点の情報を格納できないリーフエントリとからな
るディレクトリの階層構造の変化を検出して求められ
た、上記コンテナエントリの変化の差分からなる第１の
差分情報と、上記リーフエントリの変化の差分からなる
第２の差分情報とが送信され、さらに、上記送信側か
ら、上記第２の差分情報に基づく上記リーフエントリの
更新処理の際に既に処理されていなければならない上記
差分情報を示す上記識別子である先行条件識別子が上記
第２の差分情報と共に送信され、上記送信側から送信された上記第１の差分情報、上記第
２の差分情報および上記先行条件識別子とを受信する受
信手段と、上記受信手段によって受信された上記第１差分情報と上
記第２の差分情報とに基づき構成されるディレクトリの
階層構造を管理する管理手段と、上記第２の差分情報に基づき上記管理手段に管理される
上記ディレクトリの階層構造を変更する変更手段と、上記変更手段による上記変更に用いた上記先行条件識別
子を追記記録する先行条件識別子記録手段とを有し、上記変更手段による上記変更の際に、上記受信手段によ
って上記第２の差分情報と共に受信された上記先行条件
識別子の中に、上記先行条件識別子記録手段に記録され
た上記先行条件識別子と一致しない上記先行条件識別子
が存在するかどうかを調べるようにしたことを特徴とす
る受信装置。
【請求項６】請求項５に記載の受信装置において、上記送信を行う送信側に対して送信を行う送信手段をさ
らに有し、上記変更手段による上記変更の際に、上記受信手段によ
って上記第２の差分情報と共に受信された上記先行条件
識別子の中に、上記先行条件識別子記録手段に記録され
た上記先行条件識別子と一致しない上記先行条件識別子
が存在するかどうかを調べた結果、上記一致しない上記
先行条件識別子が存在するとされた場合、上記送信手段
を用いて、上記一致しない上記先行条件識別子に対応す
る上記第２の差分情報を送信するように上記送信側に要
求することを特徴とする受信装置。
【請求項７】請求項５に記載の受信装置において、上記受信手段は、送信された、上記検出の結果に基づ
き、上記コンテナエントリのそれぞれの上記ディレクト
リの階層構造上での位置を示す位置情報と、上記リーフ
エントリのそれぞれを上記ディレクトリの階層構造に基
づき識別する識別情報とをさらに受信し、受信された上
記位置情報と上記識別情報とに基づき、選択的に上記第
２の差分情報と、該第２の差分情報と共に送信された上
記先行条件識別子とを取り込むようにしたことを特徴と
する受信装置。
【請求項８】送信された、コンテンツの所在を階層的
に管理するディレクトリの階層構造を受信する受信方法
において、送信側から、上記ディレクトリの階層構造の節点であっ
て自分の配下の節点の情報を格納可能なコンテナエント
リと、上記コンテナエントリの配下にあって、自分の配
下の節点の情報を格納できないリーフエントリとからな
るディレクトリの階層構造の変化を検出して求められ
た、上記コンテナエントリの変化の差分からなる第１の
差分情報と、上記リーフエントリの変化の差分からなる
第２の差分情報とが送信され、さらに、上記送信側か
ら、上記第２の差分情報に基づく上記リーフエントリの
更新処理の際に既に処理されていなければならない上記
差分情報を示す上記識別子である先行条件識別子が上記
第２の差分情報と共に送信され、上記送信側から送信された上記第１の差分情報、上記第
２の差分情報および上記先行条件識別子とを受信する受
信のステップと、上記受信のステップによって受信された上記第１差分情
報と上記第２の差分情報とに基づき構成されるディレク
トリの階層構造を管理する管理のステップと、上記第２の差分情報に基づき上記管理のステップに管理
される上記ディレクトリの階層構造を変更する変更のス
テップと、上記変更のステップによる上記変更に用いた上記先行条
件識別子を追記記録する先行条件識別子記録のステップ
とを有し、上記変更のステップによる上記変更の際に、上記受信の
ステップによって上記第２の差分情報と共に受信された
上記先行条件識別子の中に、上記先行条件識別子記録の
ステップにより記録された上記先行条件識別子と一致し
ない上記先行条件識別子が存在するかどうかを調べるよ
うにしたことを特徴とする受信方法。
【請求項９】コンテンツの所在を階層的に管理するデ
ィレクトリの階層構造を送信し、送信されたディレクト
リの階層構造を受信する送受信システムにおいて、上記ディレクトリの階層構造の節点であって自分の配下
の節点の情報を格納可能なコンテナエントリと、上記コ
ンテナエントリの配下にあって、自分の配下の節点の情
報を格納できないリーフエントリとからなるディレクト
リの階層構造を管理する第１の管理手段と、上記第１の管理手段に管理される上記ディレクトリの階
層構造の変化を検出し、該検出の結果に基づき、上記コ
ンテナエントリの変化の差分からなる第１の差分情報
と、上記リーフエントリの変化の差分からなる第２の差
分情報を求める検出手段と、上記コンテナエントリと、該コンテナエントリの配下に
あった上記リーフエントリに対応する上記第２の差分情
報を示す識別子とを関連付けたテーブルと、上記第１の差分情報を送信すると共に、上記第２の差分
情報と、該第２の差分情報に対応する先行条件識別子と
を共に送信する送信手段と、上記送信手段で送信された、上記第１の差分情報と、上
記第２の差分情報と、該第２の差分情報と共に送信され
た上記先行条件識別子とを受信する受信手段と、上記受信手段によって受信された上記第１差分情報と上
記第２の差分情報とに基づき構成されるディレクトリの
階層構造を管理する第２の管理手段と、上記第２の差分情報に基づき上記第２の管理手段に管理
される上記ディレクトリの階層構造を変更する変更手段
と、上記変更手段による上記変更に用いた上記第２の差分情
報を示す上記先行条件識別子を追記記録する先行条件識
別子記録手段と、上記変更手段による上記変更の際に、上記受信手段によ
って上記第２の差分情報と共に受信された上記先行条件
識別子の中に、上記先行条件識別子記録手段に記録され
た上記先行条件識別子と一致しない上記先行条件識別子
が存在するかどうかを調べる比較手段とを有し、上記先行条件識別子は、上記差分情報による上記リーフ
エントリの更新処理を行う際に既に処理されていなけれ
ばならない差分情報を示す識別子であって、上記テーブ
ルを参照して、上記差分情報に対応する上記リーフエン
トリの上位のコンテナエントリに関連付けられた上記識
別子として求められることを特徴とする送受信システ
ム。
【請求項１０】請求項９に記載の送受信システムにお
いて、上記送信を行う送信側と上記受信を行う受信側との間で
通信を行う通信手段と、上記検出手段で求められた上記差分情報を蓄積する差分
情報蓄積手段とをさらに有し、上記変更手段による上記変更の際に、上記比較手段によ
って調べた結果、上記一致しない上記先行条件識別子が
存在するとされた場合、上記通信手段を用いて、上記一
致しない上記先行条件識別子に対応する上記第２の差分
情報を送信するように上記送信側に要求し、該送信側で
は、上記通信手段を用いてなされた上記要求に基づき、
上記差分情報記録手段に記録された上記差分情報を上記
受信側に送信するようにしたことを特徴とする送受信シ
ステム。
【請求項１１】請求項９に記載の送信装置において、上記検出手段は、上記検出の結果に基づき、上記コンテ
ナエントリのそれぞれの上記ディレクトリの階層構造上
での位置を示す位置情報と、上記リーフエントリのそれ
ぞれを上記ディレクトリの階層構造に基づき識別するリ
ーフエントリ識別情報とをさらに取得し、上記送信手段は、上記第１の差分情報、上記第２の差分
情報および該第２の差分情報に対応する上記先行条件識
別子と共に、上記位置情報および上記リーフエントリ識
別情報とを送信し、上記受信手段は、上記送信手段から送信された上記位置
情報と上記リーフエントリ識別情報とをさらに受信し、
受信された該位置情報と該リーフエントリ識別情報とに
基づき、選択的に上記第２の差分情報と、該第２の差分
情報と共に送信された上記先行条件識別子とを取り込む
ようにしたことを特徴とする送受信システム。
【請求項１２】コンテンツの所在を階層的に管理する
ディレクトリの階層構造を送信し、送信されたディレク
トリの階層構造を受信する送受信方法において、上記ディレクトリの階層構造の節点であって自分の配下
の節点の情報を格納可能なコンテナエントリと、上記コ
ンテナエントリの配下にあって、自分の配下の節点の情
報を格納できないリーフエントリとからなるディレクト
リの階層構造を管理する第１の管理のステップと、上記第１の管理のステップに管理される上記ディレクト
リの階層構造の変化を検出し、該検出の結果に基づき、
上記コンテナエントリの変化の差分からなる第１の差分
情報と、上記リーフエントリの変化の差分からなる第２
の差分情報を求める検出のステップと、上記コンテナエントリと、該コンテナエントリの配下に
あった上記リーフエントリに対応する上記第２の差分情
報を示す識別子とを関連付けたテーブルを作成するステ
ップと、上記第１の差分情報を送信すると共に、上記第２の差分
情報と、該第２の差分情報に対応する先行条件識別子と
を共に送信する送信のステップと、上記送信のステップで送信された、上記第１の差分情報
と、上記第２の差分情報と、該第２の差分情報と共に送
信された上記先行条件識別子とを受信する受信のステッ
プと、上記受信のステップによって受信された上記第１差分情
報と上記第２の差分情報とに基づき構成されるディレク
トリの階層構造を管理する第２の管理のステップと、上記第２の差分情報に基づき上記第２の管理のステップ
に管理される上記ディレクトリの階層構造を変更する変
更のステップと、上記変更のステップによる上記変更に用いた上記第２の
差分情報を示す上記先行条件識別子を追記記録する先行
条件識別子記録のステップと、上記変更のステップによる上記変更の際に、上記受信の
ステップによって上記第２の差分情報と共に受信された
上記先行条件識別子の中に、上記先行条件識別子記録の
ステップにより記録された上記先行条件識別子と一致し
ない上記先行条件識別子が存在するかどうかを調べる比
較のステップとを有し、上記先行条件識別子は、上記差分情報による上記リーフ
エントリの更新処理を行う際に既に処理されていなけれ
ばならない差分情報を示す識別子であって、上記テーブ
ルを参照して、上記差分情報に対応する上記リーフエン
トリの上位のコンテナエントリに関連付けられた上記識
別子として求められることを特徴とする送受信方法。