(57)【要約】【課題】  分散ス卜レージシステムにおいて、大容量のデータおよび該データに対応するファイル名などのインデックス情報の保存，更新，および参照処理に伴う遅延を削減し、データ参照時にデータ矛盾が発生しないデータ管理技術を提供すること。【解決手段】  容量の大きなデータについてはアクセス速度の速い端末上に保存し、インデックス情報をメタデータとしてユーザの信頼する任意の端末上に保存し、メタデータにデータへのポインタ情報も含め、データ更新時にはメタデータの変更と該データの更新のタイミングを連携させ、データの参照が発生する可能性のある端末にはデータの複製を作っておいてメタデータを書き換え、また、複数の端末に存在するデータのメタデータを一つの端末に保存するようにした。【選択図】      図１
2005063374.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に存在する複数の装置に分散配置されたデータを管理するデータ管理方法であって、
前記複数の装置のうちの第１装置が、該第１装置とは別の第２装置にデータ保存指示を送信するステップと、
該指示を受け取った前記第２装置が、該データを作成し保存する際に該データの実体については当該第２装置の存在する端末あるいは該端末からネットワーク接続帯域の大きい別の端末に保存し、該データの保存が終了した後に「該保存したデータを識別する情報であるインデックス情報」と「該保存したデータの位置を表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」を前記第１装置に返答するステップと、
該返答を受け取った前記第１装置が、あらかじめ通知された端末上に存在する前記データを検索する時に利用するインデックス情報と、前記データの実体へのポインタ情報、あるいは前記データの実体の存在する単数あるいは複数の端末へのポインタ情報を格納した表である「メタデータ」について、該保存指示を出した該データについてインデックス情報を作成し、あるいは該返答に含まれる該インデックス情報を利用して該データに関する該インデックス情報と該返答に含まれる該ポインタ情報によって構成される項目を新たに作成するステップと
を有することを特徴とするデータ管理方法。
【請求項２】
ネットワーク上に存在する複数の装置上にデータを分散して保存する際のデータ管理方法であって、
前記複数の装置のうちの第１装置が、該第１装置とは別の第２装置にデータ保存指示を送信するステップと、前記第２装置から「該保存したデータを識別する情報であるインデックス情報」と「該保存したデータの位置を表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」の返答を受け取るステップと、その後、あらかじめポインタ情報の通知された端末上に存在するメタデータについて、該保存指示を出した該データについてインデックス情報を作成し、あるいは該返答に含まれる該インデックス情報を利用して、該データに関する該インデックス情報と該返答に含まれる該ポインタ情報によって構成されるエントリを新たに作成するステップとを有する
ことを特徴とするデータ管理方法。
【請求項３】
請求項１に記載のデータ管理方法において、さらに、
前記第２装置が、「該データを今後利用する可能性のある別の単数あるいは複数の端末」の情報を保持するステップと、データの保存操作を終了した後に、該データを今後利用する可能性のある端末の上に該データの複製を作成するステップと、該複製作成作業の終了後、前記第１装置あるいは前記第２装置が該データを管理するメタデータ内の該データのエントリに該複製へのポインタ情報を追加するステップとを有する
ことを特徴とするデータ管理方法。
【請求項４】
請求項２に記載のデータ管理方法において、さらに、
前記第１装置が、過去にデータ保存指示を出した該データを今後利用する可能性のある別の単数あるいは複数の端末へのポインタ情報を保持している該情報を前記第２装置に送信するステップを有する
ことを特徴とするデータ管理方法。
【請求項５】
請求項１に記載のデータ管理方法において、さらに、
前記第１装置が、前記第２装置にデータ更新指示を送信するステップと、
該指示を受け取った前記第２装置が、該データの更新された新しい実体を該第２装置の存在する端末あるいは該端末からネットワーク接続帯域の大きい別の端末に保存し、該実体の保存が終了した後に「該保存したデータを識別するインデックス情報」と「該保存したデータを表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」を前記第１装置に返答するステップと、
該返答を受け取った前記第１装置が、該データを管理するメタデータのうち該データのエントリのポインタ情報を該返答に含まれる該ポインタ情報に置き換えるステップと
を有することを特徴とするデータ管理方法。
【請求項６】
請求項１に記載のデータ管理方法において、さらに、
前記第１装置が、前記第２装置にデータ更新指示を送信すると同時に、該データを管理するメタデータのうち該データのエントリからポインタ情報を削除するステップと、
前記更新指示を受け取った前記第２装置が、該データの更新された新しい実体を該第２装置の存在する端末あるいは該端末からネットワーク接続帯域の大きい別の端末に保存し、該実体の保存が終了した後に「該保存したデータを識別するインデックス情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」を前記第１装置に返答するステップと、
該返答を受け取った前記第１装置が、該データを管理するメタデータのうち該データのエントリのポインタ情報に該返答に含まれる該ポインタ情報を追加するステップと
を有することを特徴とするデータ管理方法。
【請求項７】
請求項２に記載のデータ管理方法において、さらに、
前記第１装置が、前記第２装置にデータ更新指示を送信し、前記第２装置から更新完了の返答を受けた後に、該データを管理するメタデータのうち該データのエントリのポインタ情報を該返答に含まれる該ポインタ情報に置き換えるステップを有する
ことを特徴とするデータ管理方法。
【請求項８】
請求項２に記載のデータ管理方法において、さらに、
前記第１装置が、前記第２装置にデータ更新指示を送信すると同時に、該データを管理するメタデータのうち該データのエントリからポインタ情報を削除ステップと、前記第２装置から更新完了の返答を受けた後に、該データを管理するメタデータのうち該データのエントリのポインタ情報に該返答に含まれる該ポインタ情報を追加するステップとを有する
ことを特徴とするデータ管理方法。
【請求項９】
請求項５または６記載のデータ管理方法において、さらに、
前記第２装置が、「該データを今後利用する可能性のある別の単数あるいは複数の端末」の情報を保持し、該データの保存操作を終了した後に、該データを今後利用する可能性のある端末の上に該データの複製を作成するステップと、
該複製作成作業の終了後、前記第１装置あるいは第２装置が、該データを管理するメタデータ内の該データのエントリに該複製へのポインタ情報を追加するステップと
を有することを特徴とするデータ管理方法。
【請求項１０】
請求項７または８記載のデータ管理方法において、
前記第１装置が過去にデータ保存指示を出した前記データを今後利用する可能性のある別の単数あるいは複数の端末へのポインタ情報を保持していることを特徴とするデータ管理方法。
【請求項１１】
請求項１，３，５，６，９のいずれか１項に記載のデータ管理方法において、
前記データおよび前記メタデータに、「外部の名前解決システムによって、該データあるいは該メタデータが存在する端末のネットワークアドレスに変換可能」なデータ識別子を与え、前記データあるいは前記メタデータへのポインタ情報として前記データあるいは前記メタデータのデータ識別子を含めることを特徴とするデータ管理方法。
【請求項１２】
請求項１，３，５，６，９のいずれか1項に記載のデータ管理方法において、
前記データあるいは前記メタデータへのポインタ情報として、前記データあるいは前記メタデータが存在する端末のネットワークアドレスを含めることを特徴とするデータ管理方法。
【請求項１３】
請求項１，３，５，６，９のいずれか1項に記載のデータ管理方法において、さらに、
あるデータの参照が発生した端末が、該データのインデックス情報を保持しているメタデータ内の該データのポインタ情報を検索し、もし該データが自端末上に存在すれば該データを参照し、もし該データが自端末上に存在しなければ該データが保存された端末にアクセスして該データの内容を参照することを特徴とするデータ管理方法。
【請求項１４】
ネットワーク上に存在する複数の装置に分散配置されたデータを管理するデータ管理システムであって、さらに、
前記複数の装置のうちの第１装置が、該第１装置とは別の第２装置にデータ保存指示を送信する手段と、通知された端末上に存在するデータを検索する時に利用するインデックス情報と、前記データの実体へのポインタ情報、あるいは前記データの実体の存在する単数あるいは複数の端末へのポインタ情報を格納した表である「メタデータ」について、該保存指示を出した該データについてインデックス情報を作成し、あるいは該返答に含まれる該インデックス情報を利用して該データに関する該インデックス情報と該返答に含まれる該ポインタ情報によって構成される項目を新たに作成する手段を有し、
前記第２装置が、データを作成し保存する際に該データの実体については当該第２装置の存在する端末あるいは該端末からネットワーク接続帯域の大きい別の端末に保存し、該データの保存が終了した後に「該保存したデータを識別する情報であるインデックス情報」と「該保存したデータの位置を表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」を前記第１装置に返答する手段と
を有することを特徴とするデータ管理システム。
【請求項１５】
ネットワーク上に存在する複数の装置上にデータを分散して保存する際のデータ管理システムであって、
前記複数の装置のうちの第１装置が、該第１装置とは別の第２装置にデータ保存指示を送信する手段と、前記第２装置から「該保存したデータを識別する情報であるインデックス情報」と「該保存したデータの位置を表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」の返答を受け取る手段と、あらかじめポインタ情報の通知された端末上に存在するメタデータについて、該保存指示を出した該データについてインデックス情報を作成し、あるいは該返答に含まれる該インデックス情報を利用して、該データに関する該インデックス情報と該返答に含まれる該ポインタ情報によって構成されるエントリを新たに作成する手段を有することを特徴とするデータ管理システム。
【請求項１６】
ネットワーク上に存在する複数の装置に分散配置されたデータを管理するデータ管理システムにおけるデータ管理用プログラムであって、
前記複数の装置のうちの第１装置に、該第１装置とは別の第２装置にデータ保存指示を送信する手段と、通知された端末上に存在するデータを検索する時に利用するインデックス情報と、前記データの実体へのポインタ情報、あるいは前記データの実体の存在する単数あるいは複数の端末へのポインタ情報を格納した表である「メタデータ」について、該保存指示を出した該データについてインデックス情報を作成し、あるいは該返答に含まれる該インデックス情報を利用して該データに関する該インデックス情報と該返答に含まれる該ポインタ情報によって構成される項目を新たに作成する手段を実現させ、
前記第２装置に、データを作成し保存する際に該データの実体については当該第２装置の存在する端末あるいは該端末からネットワーク接続帯域の大きい別の端末に保存し、該データの保存が終了した後に「該保存したデータを識別する情報であるインデックス情報」と「該保存したデータの位置を表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」を前記第１装置に返答する手段を実現させるためのデータ管理用プログラム。
【請求項１７】
ネットワーク上に存在する複数の装置上にデータを分散して保存する際のデータ管理システムにおけるデータ管理用プログラムであって、
前記複数の装置のうちの第１装置に、第１装置とは別の第２装置にデータ保存指示を送信する手段と、前記第２装置から「該保存したデータを識別する情報であるインデックス情報」と「該保存したデータの位置を表すポインタ情報」と「該保存したデータが存在する端末を表すポインタ情報」のうちの少なくとも一つを含んだ「該保存終了通知」の返答を受け取る手段と、あらかじめポインタ情報の通知された端末上に存在するメタデータについて、該保存指示を出した該データについてインデックス情報を作成し、あるいは該返答に含まれる該インデックス情報を利用して、該データに関する該インデックス情報と該返答に含まれる該ポインタ情報によって構成されるエントリを新たに作成する手段を実現させるためのデータ管理用プログラム。
【請求項１８】
請求項１６または１７記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広域ネットワーク上での大容量のデータを保存する場合において、データ内容（コンテンツ）とそのメタデータをネットワーク上の複数の端末に分散配置して管理するようにしたデータ管理技術に関する。
【背景技術】
【０００２】
従来から、ネットワーク上のデータに、クライアントから透過的にアクセスすることを可能とする、ＮＦＳ（Network File System）に代表されるような分散ファイルシステムが利用されてきた（http://docs.sun.com/db/doc/806-3908（2003/07/04）（非特許文献１））。
【０００３】
これらの分散ファイルシステムにおいては、ネットワークの帯域不足や高遅延に起因するデータ参照のパフォーマンス低下を回避するために、クライアント端末上にデータの複製であるキャッシュを作成する技術が取り入れられている。
【０００４】
しかし、データ参照用のキヤッシュを用いたシステムにおいても、最新の情報を持つマスタデータはネットワーク内の単一かつ固定の端末上に存在している。このため、データの更新時には、マスタデータの存在する端末まで更新されたデータ内容を送信する必要があり、更新するデータの容量が大きい場合には、データの書き込み操作にかかる時間が大きくなるという問題が存在する。
【０００５】
一方、書き込みにもキャッシュを導入し、その所要時間を短縮する手法が一般に存在する。この手法では、クライアント端末に書き込みのためのライトバックキャッシュを設け、書き込み操作は自端末上のライトバックキャッシュに対して行われる。これはネットワーク経由の通信を伴わない端末ローカルな操作であるため、書き込み操作は短時間で終了する。
【０００６】
しかし、上述のライトバックキャッシュを用いる手法では、キャッシュがマスタデータへ反映されるまでの間、キャッシュとマスタデータとの間で情報の不整合が起こるため、データの一貫性を維持することが困難になるという問題が存在する。
【０００７】
具体的には、データを更新したクライアントが更新完了の通知を受け取った後に、ライトバックキャッシュがマスタデータへ反映されるまでの間に別のクライアントがマスタデータを参照してしまった場合、最初のクライアントが更新を完了しているにもかかわらず、後のクライアントは古いデータを参照してしまうという問題である。
【０００８】
更新するデータの容量が大きい場合や、更新クライアントとサーバとの間のネットワーク帯域が十分でない場合には、このような不整合が起こる可能性が高くなってしまう。
【０００９】
また、これらの分散ファイルシステムにおいては、ファイルの名前などのインデックス情報を含んだ属性情報を記録したｉノードとコンテンツであるファイル実体とを区別している。しかし、従来の分散ファイルシステムではｉノードをファイルの実体と同一の端末上に配置している。
【００１０】
そのため、あるユーザが利用する複数のファイルが異なる端末上に配置されており、該ユーザがそれら複数のファイルのインデックス情報をまとめて更新したい場合、複数の端末のｉノードを更新する必要があり、端末間の通信のために遅延が大きくなる。
【００１１】
一方、近年普及してきたＰ２Ｐ（Peer to Peer）型のファイル共有サービスでは、多数のクライアント端末に保存されたファイルについて、特定の識別子を持つファイルがどの端末に保存されているかを検索可能にすることによって、仮想的なストレージスペースを多数のクライアントの間で共有することを可能としている。
【００１２】
例えば、Ｎａｐｓｔｅｒに代表されるようなハイブリッドＰ２Ｐ型ファイル共有システムでは、参加端末は自分が共有するファイルのファイル名やカテゴリ名などのインデックス情報を既定のインデックスサーバに登録する。（伊藤直樹，「Ｐ２Ｐコンピューテイング〜技術解説とアプリケーション〜」，ソフトリサーチセンター，ＩＳＢＮ：４−８８３７３−１５６−１）（非特許文献２）
【００１３】
このファイルを参照したい別の端末は、インデックスサーバに検索メッセージを送信して目的のファイルが保存されている端末のネットワークアドレスを教えてもらい、そのアドレスを元に該当する端末からデータを参照する。
【００１４】
このようなハイブリッドＰ２Ｐ型ファイル共有システムは、基本的に多数のクライアント端末からのファイル参照のみを対象としており、書き込み可能な分散ファイルシステムの提供を目的としているわけではない。しかし、新たなファイルを仮想的な共有スペースに登録する処理をファイルの作成として捉えることが可能である。
【００１５】
このときのファイル作成は該ファイルが存在する端末上でのみ実行可能であり、また、作成のために必要な処理はインデックスサーバにファイルのインデックス情報を登録する処理のみであるので、ファイルの容量が大きい場合でも短時間で更新操作が終了する。
【００１６】
また、あるユーザが利用する複数のファイルが異なる端末上に配置されており、該ユーザがそれら複数のファイルのインデックス情報をまとめて更新したい場合でも、単一のインデックスサーバにアクセスすればよいので遅延が小さい。
【００１７】
しかし、インデックス情報が固定のサーバに集中するため、インデックスサーバの負荷が大きいとデータ参照時のインデックス検索に伴う遅延が大きくなってしまう。更に付加的な問題として、インデックスサーバの信頼性が低い場合やインデックスサーバの運用者が悪意を持っている場合に、正しいデータの参照が実行不可能になる場合がある。
【００１８】
一方、従来、各端末に複製されたデータ（複製データ）のうちの一つにデータの管理権限を持たせ、管理権限は複製データの間で自由に移動可能とし、データを更新する際には管理権限を持つ端末が更新の順序を制御して、全ての複製を同時に更新する、という複製データの分散管理方式が提案されている（中村元紀他著「環境適応型オンラインストーレジにおける複製管理方式の評価」信学技報ＩＮ２００２−１０８，２００２年１１月）（非特許文献３）。
【００１９】
この方式では、データの参照は任意の複製を参照すればデータ矛盾は起きないため、データ参照要求の発生した端末の近くの複製を参照することで遅延を削減できる。しかしこの方式でも、データの更新は全ての複製に通知する必要があるため、更新するデータの容量が大きい場合にははその転送遅延が大きくなる。
【００２０】
また、データのインデックス情報はデータの管理権限を持つ端末上で管理するため、あるユーザが利用する複数のデータの管理権限が異なる端末上に配置されており、該ユーザがそれら複数のデータのインデックス情報をまとめて更新したい場合、それら複数のデータの管理権限を持つ端末を全て検索する必要があり、更新遅延が大きくなる。
【００２１】
【非特許文献１】http://docs.sun.com/db/doc/806-3908（2003/07/04）
【非特許文献２】伊藤直樹，「Ｐ２Ｐコンピューテイング〜技術解説とアプリケーション〜」，ソフトリサーチセンター，ＩＳＢＮ：４−８８３７３−１５６−１）
【非特許文献３】中村元紀他著「環境適応型オンラインストーレジにおける複製管理方式の評価」信学技報ＩＮ２００２−１０８，２００２年１１月）
【発明の開示】
【発明が解決しようとする課題】
【００２２】
上述したように、従来の分散ファイルシステムでは、更新するデータの容量が大きい場合にデータの書き込み操作にかかる時間が大きくなる、あるいはデータの一貫性を維持することが困難である、という問題が存在する。
【００２３】
また、複数の端末に分散された複数のデータのインデックス情報を更新する場合、複数の端末にアクセスするため遅延が大きくなる、という問題が存在する。
【００２４】
従来のハイブリッドＰ２Ｐ（Peer to Peer）型のファイル共有サービスでは、任意のサーバ上にインデックス情報をおくことができないため、インデックスサーバの負荷が高い時にデータ参照のためのインデックス検索やインデックス情報の更新の遅延が大きくなる、という問題が存在する。
【００２５】
また、インデックスサーバの信頼性が低い場合やインデックスサーバの管理者が悪意を持っている時にデータ参照のためのインデックス検索やインデックス情報の更新が不可能になってしまう、という問題が存在する。
【００２６】
また、従来の複製データの分散管理方式では、更新するデータの容量が大きい場合にデータの書き込み操作にかかる時間が大きくなる、また、複数の端末に分散された複数のデータのインデックス情報を更新する場合、複数の端末にアクセスするため遅延が大きくなる、という問題が存在する。
【００２７】
本発明の目的は、このような従来の課題を解決し、広域ネットワークにおいて、大容量データの書き込み、更新、参照操作および属性やインデックス情報の更新の遅延を削減し、かつデータ矛盾の発生を防ぐ、分散ストレージシステムを実現するための、データの管理方法、データ管理装置、そのためのプログラムならびに該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することである。
【課題を解決するための手段】
【００２８】
まず、本発明における「メタデータ」を、データの名前やカテゴリなど、データを検索するときに使うインデックス情報、およびそのデータへのポインタ情報をエントリとして持つ表として保存されているデータ、と定義しておく。
【００２９】
本発明では、データとそれに対応するメタデータをそれぞれ任意の別々の端末に保存可能とし、データ保存指示部（第１装置）とデータ保存部（第２装置）が連携しながら、データ保存指示部（第１装置）がメタデータを、データ保存部（第２装置）がデータの実体を保存することを特徴としている（請求項１，２，１３，１４）。
【００３０】
データ保存部（第２装置）がデータの実体を保存する際、自端末上あるいは自端末近傍のネットワーク帯域の広い端末上に保存することによって、短時間でのデータの実体の保存が可能となる。
【００３１】
一方で、データ保存指示部（第１装置）はデータ保存部（第２装置）がデータ保存を終了した後に既定の端末上に存在するメタデータを更新する。このため、メタデータの更新までを含めたデータの更新操作も短時間のうちに終了する。よって、ＮＦＳなどの分散ファイルシステムで問題となるデータ更新の遅延削減を実現している。
【００３２】
データの整合性の問題については二つの場合が想定される。メタデータの更新が終了した時点でユーザに更新操作の終了が通知される場合、この通知が行われる前に該データを参照した別の端末には更新前の古いデータがよって、ライトバックキヤッシュを用いた分散ファイルシステムのようなデータの不整合の問題は生じない（請求項５）。
【００３３】
一方で、データの実体が更新が終了した時点でユーザに更新操作の終了が通知される場合は、該更新データの保存を行う前にあらかじめメタデータの該データに対応するエントリから古いデータへのポインタ情報を削除しておくことで、別の端末が更新済みのはずの古いデータを参照することを不可能にし、データ整合性を確保する（請求項６）。
【００３４】
また、複数のデータはそれぞれ別の端末に保存されていても、そのデータのインデックス情報を管理するメタデータは単一の端末上に存在する。そのため、複数のデータに関するインデックス情報の更新を行う場合でも、インデックス情報更新主体は一つの端末にのみアクセスすればよく、更新操作にかかる遅延を削減することが出来る（請求項１，２）。よって、既存の分散ファイルシステムなどにおいて複数の端末上に保存されたデータのインデックス情報の更新する際の通信遅延の問題を解決できる。
【００３５】
またユーザは、あらかじめ任意の端末上にメタデータを配置することができる。このため、ユーザ自身が運営するホームサーバなどの端末や、ユーザから委託されたプロバイダ一によって運営される信頼性の高い端末などにメタデータを配置することができる。よって、ハイブリッド型Ｐ２Ｐファイル共有サービスで問題となる、サービス事業者の提供するインデックスサーバへの負荷の集中や信頼性の問題を回避できる。
【発明の効果】
【００３６】
本発明のデータ管理技術を用いることによって、従来技術の課題を解決し、広域ネッ卜ワークにおいて大容量データの書き込み、更新、参照操作および属性やインデックス情報の更新の遅延を削減し、かつデータ矛盾の発生を防ぐ、分散ストレージシステムを実現することが可能である。
【００３７】
以下では、従来技術の課題として挙げなった点についての付随的なメリットについて説明する。
【００３８】
メタデータの保持するポインタ情報には、データの一意な識別子が含まれる。このデータ識別子は、何らかの名前解決サービス（ＤＮＳなど）によって、そのデータを持つ端末のネットワークアドレスに解決される。この場合、データが存在する端末を移動した場合にも、対応するメタデータを更新する処理が必要ないため、データの移動とメタデータの更新を並行して実行可能となり、メタデータの更新遅延を削減できる（請求項１１）。
【００３９】
また、データを持つ端末のネットワークアドレスもポインタ情報として保持することにより、名前解決サービスが利用できなくてもデータの参照を可能とし、名前解決サービスを利用することによる遅延を削減できる（請求項１２）。
【００４０】
データを参照する場合は、まずメタデータからデータの保存先を探索し、保存先の端末からデータを参照する。またデータを参照する可能性のある端末にはあらかじめ複製を作っておき、該データのポインタ情報に該端末を含むようにするため、データアクセスの遅延を削減可能である（請求項３，１３）。
【発明を実施するための最良の形態】
【００４１】
本発明では、データとそれに対応するメタデータをそれぞれ任意の別々の端末に保存可能とし、データ保存指示部（第１装置）とデータ保存部（第２装置）が連携しながら、データ保存指示部（第１装置）がメタデータを、データ保存部（第２装置）がデータの実体を保存する。
【００４２】
より具体的には、データを保存する際に、容量の大きなデータについてはアクセス速度の速い端末上に保存することでデータ保存の遅延を削減する。また、インデックス情報をメタデータとしてユーザの信頼する任意の端末上に保存し、メタデータにデータへのポインタ情報も含めることで、メタデータから該データへの参照遅延を削減する。データ更新時にはメタデータの変更と該データの更新のタイミングを連携させることで、データ矛盾の発生を防ぐ。データの参照が発生する可能性のある端末にはデータの複製を作っておいて、メタデータを書き換えることで参照時に大容量データを送信する遅延を削減する。また、複数の端末に存在するデータのメタデータを一つの端末に保存することによって、インデックス情報の更新や参照の遅延を削減する。
【実施例】
【００４３】
次に、本発明の具体的な実施例を、図面を参照して詳細に説明する
図１は、本発明の一実施例におけるネットワークおよび端末の構成図である。
【００４４】
同図に示すように、本実施例に係るネッ卜ワーク（５０）には、端末Ａ（１０）、端末Ｂ（２０）、端末Ｃ（３０）、および端末Ｄ（４０）が接続されている。端末Ａ（１０）にはユーザインタフェース部Ａ（１１）とデータ管理部Ａ（１２）とオペレーティングシステム（１５）が、端末Ｂ（２０）にはデータ管理部Ｂ（２２）とオペレーティングシステム（２５）が、端末Ｃ（３０）にはユーザインタフェース部Ｃ（３１）とデータ管理部Ｃ（３２）とオペレーティングシステム（３５）が、端末Ｄ（４０）にはデータ管理部Ｄ（４２）とオペレーティングシステム（４５）が、それぞれ存在し動作しているものとする。
【００４５】
それぞれのデータ管理部Ａ（１２），Ｂ（２２），Ｃ（３２），Ｄ（４２）は、ユーザからの指示に基づいてデータの保存指示および保存操作の両方の動作を実行する。つまり各データ管理部は、請求項の記述におけるデータ保存指示部（第１装置）とデータ保存部（第２装置）の両方による操作が可能である。
【００４６】
各部は、各部の存在する端末のネットワークアドレスが分かれば、互いにメッセージを送信、あるいは受信することが可能とする。また、端末Ｂ（２０）にはセンサＢ（２６）が、また端末Ｄ（４０）にはセンサＤ（４６）が、それぞれ接続されており、各端末は接続されたセンサが収集した情報を取り込むことが可能とする。
【００４７】
更に、各端末は一意なネットワークアドレスを持つものとする。ネットワークアドレスはネットワークの管理者が端末の管理者に通知して、端末の管理者が端末に設定する、あるいは端末の物理インタフエースにあらかじめ割り当てられたハードウエア番号を用いる、あるいはネットワーク内に一意な識別子を発行するサーバが存在し、該サーバが各端末の立ち上げ時に付与する、などの方法で取得可能である。
【００４８】
以下では、メタデータの持つインデックス情報の例としてデータ名とカテゴリ名を取り上げ、その詳細を説明する。メタデータとしてそれら以外の情報を扱う場合も、同様の説明が当てはまる。
【００４９】
本実施例では、端末Ａ（１０）を使用中のユーザ（１００）が、端末Ｂ（２０）に接続されたセンサＢ（２６）が取得するデータおよび端末Ｄ（４０）に接続されたセンサＤ（４６）が取得するデータを保存し、それらのデータのインデックス情報を更新することを考える。また、上記の処理の途中あるいは処理後に別のユーザ（１１０）が端末Ｃ（３０）から該データを参照し、更新することを考える。
【００５０】
なお、以下の実施例中のシーケンス図（図２，図４，図５，図７，図８，図９）においては、縦軸が時間の流れを表し、下に行く程時間が過ぎていくことを表すが、その長さは実際の処理時間には依存しないこととする。
【００５１】
図２は、端末Ｂ（２０）に接続されたセンサＢ（２６）が取得するデータを生成する場合のシーケンスを示した図である（請求項１，２）。
【００５２】
あるユーザ（１００）がユーザインタフェース部Ａ（１１）に対してデータの生成を要求する。この時、当該ユーザはデータ名Ｂと、カテゴリ名Ｘと、データの存在位置である端末Ｂ（２０）のネットワークアドレスと、自身が使用する可能性のある端末Ｃ（３０）のネットワークアドレスを通知する。
【００５３】
次に、ユーザインタフェース部Ａ（１１）は、データ管理部Ａ（１２）にデータの生成要求を示したメッセージを送信する。該メッセージには、上記ユーザから与えられたデータ名Ｂ、カテゴリ名Ｘ、端末Ｂ（２０）のネットワークアドレス、および端末Ｃ（３０）のネットワークアドレスの各情報を含める。なお、これらの情報をユーザが明示的に与えない場合、データ管理部Ａ（１２）が任意のファイルやデータベースから獲得するようにしてもよい。
【００５４】
データ管理部Ａ（１２）は、メタデータ（１４）を作成し、端末Ａ（１０）上に配置する。この時、オペレーティングシステム（１５）は、作成したメタデータ（１４）に一意な識別子を付与する。この識別子は端末Ａ（１０）のネットワークアドレスとローカルでシーケンシャルに付与される識別子を結合することなどで実現可能である。
【００５５】
また、この識別子と対応する端末Ａ（１０）の対応関係は、データ管理部Ａ（１２）あるいはオペレーティングシステム（１５）がＤＮＳなどの名前サービスに登録する（請求項１１）。
【００５６】
図３は、メタデータ（１４）のうちの一つのデータに対するエントリの例を示した図である。すなわち、メタデータ（１４）の一つのエントリは、インデックス情報であるデータ名（１４１）とカテゴリ名（１４２）と複数のポインタ情報（１４３〜１４４）の各フィールドからなり、メタデータはこれらのエントリを一つまたは複数持つ表である。
【００５７】
具体的には、データ名の例としては“conference1”のようなＡＳＣII文字列が、またカテゴリ名の例としては“conference”のようなＡＳＣII文字列が考えられる。
【００５８】
次に、データ管理部Ａ（１２）は、メタデータ（１４）中の一つのエントリのデータ名とカテゴリ名に、該ユーザインタフェース部Ａ（１１）から与えられたデータ名Ｂとカテゴリ名Ｘを登録する（ステップ（ａ））。
【００５９】
更に、データ管理部Ａ（１２）は、データの存在位置に関する情報である端末Ｂ（２０）のネットワークアドレスを用いてデータ管理部Ｂ（２２）にデータの生成要求を意図するメッセージを送信する。
【００６０】
この時、該メッセージには、データのインデックス情報の一部としてデータ名Ｂ、メタデータ（１４）の識別子、および該データが使用される可能性のある端末Ｃ（３０）のネットワークアドレスを含める。
【００６１】
なお、本実施例でメッセージにデータ名を含めることとしたが、データ名の代わりにインデックス情報の一部あるいは全部、あるいは該データの識別子、あるいは該データが存在する端末のネットワークアドレスなどを含んでもよい。
【００６２】
メッセージを受信したデータ管理部Ｂ（２２）は、センサＢ（２６）から情報を読み込み、データＢ（２４）を作成して端末Ｂ（２０）に保存する（ステップ（ｂ））。このデータの保存は同一端末上でのデータの移動であり、ネットワークを経由したデータの送信に比べて遅延が小さい。特にデータの容量が大きくネットワークの帯域が十分大きくない場合は顕著である。
【００６３】
またこのとき、端末Ｂ（２０）のオペレーティングシステム（２５）は、保存したデータに一意な識別子を付与する。この識別子はメタデータ（１４）と同様な方法で付与可能である。そしてデータ管理部Ｂ（２２）は該識別子とデータ名Ｂを含んだデータ生成確認メッセージをデータ管理部Ａ（１２）に送信する。
【００６４】
データ管理部Ａ（１２）は、受けとったメッセージ中のデータ名Ｂに対する「メタデータのエントリのポインタ情報」として、受けとったデータＢの識別子を登録する（ステップ（ｃ））。
【００６５】
次に、データ管理部Ｂ（２２）は、ユーザ（１００）が後で利用する可能性のある端末Ｃ（３０）のデータ管理部Ｃ（３２）に複製データの生成を意図したメッセージを送信する。該メッセージには、データＢ（２４）の実体（コンテンツ）と、データ名Ｂとメタデータ（１４）の識別子を含める（請求項３）。
【００６６】
該メッセージを受信したデータ管理部Ｃ（３２）は、端末Ｃ（３０）上に複製データＢ（３４）を生成し、オペレーティングシステム（３５）は生成したデータに一意な識別子を付与する（ステップ（ｄ））。
【００６７】
次に、データ管理部Ｃ（３２）は、該受信メッセージ中に含まれるメタデータ（１４）の識別子をＤＮＳなどの名前サービスに問い合わせ、対応する端末Ａ（１０）のネットワークアドレスを得て、データ管理部Ａ（１２）にポインタ情報の更新を意図したメッセージを転送する。該メッセージにはデータ名Ｂと複製データＢ（３４）の識別子を含める。
【００６８】
該メッセージを受信したデータ管理部Ａ（１２）は、メタデータ（１４）中のデータ名Ｂに対応するポインタ情報に該受信したメッセージ中に含まれる複製データＢ（３４）の識別子を追加する（ステップ（ｅ））。
【００６９】
図４は、図２中の区間Ｚ（２００）の間に、端末Ｃ（３０｝上のユーザ（１１０）がデータＢを参照する場合のシーケンスを示した図である（請求項１３）。
【００７０】
ユーザ（１１０）は、まずユーザインタフェース部Ｃ（３１）にあるカテゴリ名Ｘに対するデータのリストを要求する。この時ユーザ（１１０）はカテゴリ名Ｘとメタデータ（１４）の識別子を与える。
【００７１】
ユーザインタフェース部Ｃ（３１）は、カテゴリ名Ｘとメタデータ（１４）の識別子を含みデータのリスト要求を意図するメッセージをデータ管理部Ｃ（３２）に送信する。
【００７２】
データ管理部Ｃ（３２）は、与えられたメタデータ（１４）の識別子からＤＮＳなどの名前解決サービスを利用して該メタデータが存在する端末Ａ（１０）のネットワークアドレスを獲得し、データ管理部Ａ（１２）にメタデータの読み出し要求を意図するメッセージを送信する。
【００７３】
データ管理部Ａ（１２）は、メタデータを検索して（ステップ（ｆ））、該メタデータのエントリのうち該カテゴリ名Ｘを含むデータ名のリストをデータ管理部Ｃ（３２）に送信する。なお、本実施例の区間Ｚ（２００）においては、該当するデータ名はデータ名Ｂのみである。
【００７４】
データ管理部Ｃ（３２）は、受信したメッセージ内の情報であるデータ名Ｂを含んだメッセージをユーザインタフェース部Ｃ（３１）に送信する。
【００７５】
ユーザインタフェース部Ｃ（３１）は、受信したメッセージ中のデータ名Ｂをユーザ（１１０）に提示する。
【００７６】
次に、ユーザ（１１０）は、データ名Ｂに対するデータの読み出しをユーザインタフェース部Ｃ（３１）に要求する。この時メタデータ（１４）の識別子も要求に含める。
【００７７】
ユーザインタフェース部Ｃ（３１）は、データ名Ｂとメタデータ（１４）の識別子を含みデータの読み出し要求を意図するメッセージをデータ管理部Ｃ（３２）に送信する。
【００７８】
データ管理部Ｃ（３２）は、与えられたメタデータ（１４）の識別子から、ＤＮＳなどの名前解決サービスを利用して該メタデータが存在する端末Ａ（１０）のネットワークアドレスを獲得し、データ管理部Ａ（１２）にメタデータの読み出し要求を意図するメッセージを送信する。
【００７９】
データ管理部Ａ（１２）は、メタデータを検索して（ステップ（ｇ））、該メタデータのエントリのうち該データ名Ｂに対応するポインタ情報を含んだメタデータ通知メッセ一ジをデータ参照部（３２）に送信する。なお、本実施例の区間Ｚ（２００）においては、データＢ（２４）の識別子が該ポインタ情報となる。
【００８０】
該メッセージを受信したデータ管理部Ｃ（３２）は、該ポインタ情報が示す識別子からＤＮＳなどの名前解決サービスを利用して、該データＢ（２１）の存在端末のネットワークアドレスを獲得し、端末Ｂ（２０）のデータ管理部Ｂ（２２｝にデータの読み出し要求を意図するメッセージを送信する。該メッセージにはデータ名Ｂを含める。
【００８１】
該メッセージを受信したデータ管理部Ｂ（２２）は、データＢ（２４）を読み出し（ステップ（ｈ））、該データＢ（２４）の実体を含んだデータ提示メッセージをデータ管理部Ｃ（３２）に送信する。
【００８２】
該メッセージを受信したデータ管理部Ｃ（３２）は、ユーザインタフェース部Ｃ（３１）に該データＢ（２４）の実体を含んだメッセージを送信し、ユーザインタフェース部Ｃ（３１）はユーザ（１１０）に該データＢ（２４）の実体を提示する。
【００８３】
図５は、端末Ｄ（４０）に接続されたセンサＤ（４６）が取得するデータを生成する場合のシーケンスを示した図である。
【００８４】
ユーザ（１００）は、ユーザインタフェース部Ａ（１１）に別のデータの生成を要求する。この時、該ユーザ（１００）は，データ名Ｄと、カテゴリ名Ｘと、データの存在位置である端末Ｄ（４０）のネットワークアドレスと、自身が使用する可能性のある端末Ｃ（３０）のネットワークアドレスを通知する。
【００８５】
それ以降の手順（ステップ（ｉ）〜（ｍ）など）は、上述のデータＢ（２４）の生成手順（図２のステップ（ａ）〜（ｅ）など）と同様であり、その結果，端末Ｄ（４０）にデータＤ（４４）が、端末Ｃ（３０）に複製データＤ（３６）が、メタデータ（１４）内にデータＤ（４４）に対応するエントリが、それぞれ生成される。
【００８６】
図６は、この時点でのデータやメタデータの配置状況を示した図であり、図１に比べて、端末Ａ（１０）にメタデータ（１４）が、端末Ｂ（２０）にメタデータ（１４）が、端末Ｃ（３０）に複製データＢ（３４）と複製データＤ（３６）が、端末Ｄ（４０）にデータ（４４）が追加されている。
【００８７】
図７は、ユーザ（１００）が、メタデータ（１４）を更新する際のシーケンスを示した図である。
ユーザ（１００）は、ユーザインタフェース部Ａ（１１）にメタデータ（１４）の更新を要求する。この時、旧カテゴリ名Ｘと新カテゴリ名Ｙを通知する。
【００８８】
ユーザインタフェース部Ａ（１１）は、データ管理部Ａ（１２）にメタデータ（１４）の更新要求を意図するメッセージを送信する。該メッセージにはユーザから通知された旧カテゴリ名Ｘと新カテゴリ名Ｙを含める。
【００８９】
データ管理部Ａ（１２）は、メタデータ（１４）中のエントリのうちカテゴリ名Ｘであるものをカテゴリ名Ｙに置き換える（ステップ（ｎ））。
【００９０】
このように、カテゴリ名のようなインデックス情報の更新の際には、端末Ｂ（２０）や端末Ｄ（４０）上のデータＢ（２４）やデータＤ（４４）、あるいは端末Ｃ（３０）上の複製データＢ（３４）や複製データＤ（３６）にアクセスする必要はない。
【００９１】
図８は、この後、端末Ｃ（３０）のユーザ（１１０）がデータＤを参照する場合のシーケンスを示した図である（請求項１３）。
【００９２】
ユーザ（１１０）は、ユーザインタフェース部Ｃ（３１）にカテゴリ名Ｙに対するデータのリストを要求する。この時ユーザ（１１０）はカテゴリ名Ｙとメタデータ（１４）の識別子を与える。
【００９３】
ユーザインタフェース部Ｃ（３１｝は、カテゴリ名Ｙとメタデータ（１４）の識別子を含みデータのリスト要求を意図するメッセージをデータ管理部Ｃ（３２）に送信する。
【００９４】
データ管理部Ｃ（３２）は、与えられたメタデータ（１４）の識別子からＤＮＳなどの名前解決サービスを利用して該メタデータが存在する端末Ａ（１０）のネットワークアドレスを獲得し、データ管理部Ａ（１２）にメタデータの読み出し要求を意図するメッセージを送信する。
【００９５】
データ管理部Ａ（１２）は、メタデータを検索し（ステップ（ｏ））、該メタデータのエントリのうち該カテゴリ名Ｙを含むデータ名のリストをデータ管理部Ｃ（３２）に送信する。本実施例では、該当するデータ名はデータ名Ｂとデータ名Ｄである。
【００９６】
データ管理部Ｃ（３２）は、受信したメッセージ内の情報を含んだメッセージをユーザインタフェース部Ｃ（３１）に送信する。ユーザインタフェース部Ｃ（３１）は受信したメッセージ中のデータ名Ｂとデータ名Ｄをユーザ（１１０）に提示する。
【００９７】
次に、ユーザ（１１０）は、データ名Ｄに対するデータの読み出しをユーザインタフェース部Ｃ（３１）に要求する。この時、メタデータ（１４）の識別子も要求に含める。
【００９８】
ユーザインタフェース部Ｃ（３１）は、データ名Ｄとメタデータ（１４）の識別子を含みデータの読み出し要求を意図するメッセージをデータ管理部Ｃ（３２）に送信する。
【００９９】
データ管理部Ｃ（３２）は、与えられたメタデータ（１４）の識別子からＤＮＳなどの名前解決サービスを利用して該メタデータが存在する端末Ａ（１０）のネッ卜ワークアドレスを獲得し、データ管理部Ａ（１２）にメタデータの読み出し要求を意図するメッセージを送信する。
【０１００】
データ管理部Ａ（１２）は、メタデータを検索し（ステップ（ｐ））、該メタデータのエントリのうち該データ名Ｄに対応するポインタ情報を含んだメタデータ通知メッセージをデータ参照部（３２）に送信する。なお、本実施例においては、データＤ（２４）の識別子および複製データＤ（３６）の識別子が該ポインタ情報となる。
【０１０１】
該メッセージを受信したデータ管理部Ｃ（３２）は、該ポインタ情報を調べ、端末Ｃ上に存在する複製データＤ（３６）の識別子が含まれているため、複製データＤ（３６）を読み出し（ステップ（ｑ））、ユーザインタフェース部Ｃ（３１）に該複製データＤ（３６）の実体を含んだメッセージを送信する。ユーザインタフェース部Ｃ（３１）は、ユーザ（１１０）に該複製データＤ（３６）の実体（コンテンツ）を提示する。
【０１０２】
図９は、ユーザ（１１０）が複製データ（３６）を更新する場合のシーケンスを示した図である。更新内容の例としては、データの前半を破棄することなどが考えられる。
【０１０３】
本実施例では端末Ｃ（３０）と端末Ｄ（４０）の間のネットワーク接続帯域が大きい（例えば同一ＬＡＮに接続しており、１００Ｍｂｐｓのリンク帯域を持つ）ものとし、更新したデータは端末Ｄ（４０）に配置することとする。つまり、ユーザ（１１０）はユーザインタフェース部Ｃ（３１）にデータ名Ｄとデータの更新内容とメタデータ（１４）の識別子と端末Ｄ（４０）のネットワークアドレスを通知する。
【０１０４】
ユーザインタフェース部Ｃ（３１）は、データ管理部Ｃ（３２）にユーザ（１ｌ０）から受けとったデータ名Ｄとデータの更新内容とメタデータ（１４）の識別子と端末Ｄ（４０）のネットワークアドレスを含んだメッセージを送信する。
【０１０５】
該メッセージを受けとったデータ管理部Ｃ（３２）は、該メッセージ中の更新内容、端末Ｄ（４０）のネッ卜ワークアドレス、およびメタデータ（１４）の識別子をデータ名Ｄと関連させて記憶しておく（ステップ（ｒ））。
【０１０６】
図１０は、この時記憶する情報の例を示した図であり、上記の記憶は、例えば、データ名１０１と更新内容１０２とデータを配置する端末のネッ卜ワークアドレス１０３とメタデータの識別子１０４からなるエントリを持つ表として、保存すればよい。
【０１０７】
次に、データ管理部Ｃ（３２）は、メタデータ（１４）の識別子からＤＮＳなどの名前解決サービスを利用して、端末Ａ（１０）のネットワークアドレスを獲得し、データ管理部Ａ（１２）にデータ名Ｄとメタデータ（１４）の識別子を含みメタデータの更新を要求するメッセージを送信する。
【０１０８】
該メッセージを受信したデータ管理部Ａ（１２）は、メタデータ（１４）中の該データ名に対応するエントリのポインタ情報を記憶し、メタデータ（１４）の該エントリからポインタ情報を削除するとともに（ステップ（ｓ））、該記憶したポインタ情報、すなわちデータＤ（２４）の識別子と複製データＤ（３６）の識別子、およびデータ名Ｄを含んだメタデータの通知メッセージをデ一タ管理部Ｃ（３２）に送信する。
【０１０９】
これ以降は、区間Ｗ（２１０｝において該データ名Ｄに対応するポインタ情報の参照があっても、該ポインタ情報が存在しないためデータの参照は失敗し、古いデータを読み出すというデータ矛盾は発生しない。
【０１１０】
なお、本実施例では、請求項６に従った動作を示しているが、このメタデータ更新のステップを省略した場合は請求項５の動作となる。
【０１１１】
該メッセージを受信したデータ管理部Ｃ（３２）は、該メッセージ中に端末Ｃ（３０）上の複製データＤ（３６）の識別子が存在することを確認し、前もって記憶しておいたデータ名Ｄに対応する更新内容を複製データＤ（３６）に施し（ステップ（ｔ））、その結果となるデータの実体とメタデータ（１４）の識別子とデータ名Ｄを含んだデータ生成要求メッセージをデータ管理部Ｄ（４２）に送信する。その後、データ管理部Ｃ（３２）は複製データＤ（３６）を削除する。
【０１１２】
該メッセージを受信したデータ管理部（４２）は、データＤ（４４）の内容を該メッセージ中のデータ実体と置き換えてデータＤ（４４）を更新する（ステップ（ｕ））。そして、該メッセージ中に含まれるメタデータ（１４）の識別子からＤＮＳなどの名前解決サービスを利用して、端末Ａ（１０）のネットワークアドレスを獲得し、データ名Ｄとメタデータの識別子と該データの識別子とを含んだメタデータの更新を意図するメッセージをデータ管理部Ａ（１２）に送信する。
【０１１３】
該メッセージを受けとったデータ管理部Ａ（１２）は、メタデータ（１４）の該データ名に対するポインタ情報として、該メッセージ中の識別子を登録する（ステップ（ｖ））。
【０１１４】
これ以降、該データ名に対するポインタ情報は最新のデータの識別子を示すこととなり、データ矛盾は発生しない。
【０１１５】
なお、本実施例ではデータのポインタ情報として識別子を用いた例を説明したが、識別子の代わりに該データが存在する端末のネッ卜ワークアドレスを用いてもよい。この場合、識別子からＤＮＳなどの名前解決サービスを利用してデータが存在する端末のネットワークアドレスを獲得する処理は不要となる（請求項１２）。
【０１１６】
なお、上記実施例で説明したような図２，４，５，７，８，９の処理をコード化したプログラムは、ＣＤ−ＲＯＭ，ＦＤ，ＤＶＤのようなコンピュータ読み取り可能な記録媒体に記録してユーザに頒布したり、インターネットを介してユーザ装置にダウンロードさせることが可能である。
【図面の簡単な説明】
【０１１７】
【図１】本発明の一実施例におけるネットワークおよび端末の構成図である。
【図２】データＢの生成シーケンスを示した図である。
【図３】メタデータのうちの一つのデータに対するエントリの例を示した図である。
【図４】データＢの参照シーケンスを示した図である。
【図５】データＤの生成シーケンスを示した図である。
【図６】データ配置の例を示した図である。
【図７】メタデータの更新シーケンスを示した図である。
【図８】データＤの参照シーケンスを示した図である。
【図９】データＤの更新シーケンスを示した図である。
【図１０】データ更新時に利用する表のエントリの例を示した図である。
【符号の説明】
【０１１８】
１０：端末Ａ
１１：ユーザインタフェース部Ａ
１２：データ管理部Ａ
１４：メタデータ
１４１：データ名
１４２：カテゴリ名
１４３〜１４４：ポインタ情報
１５：オペレーティングシステム
２０：端末Ｂ
２２：データ管理部Ｂ
２４：データＢ
２５：オペレーティングシステム
２６：センサＢ
３０：端末Ｃ
３１：ユーザインタフェース部Ｃ
３２：データ管理部Ｃ
３４：複製データＢ
３５：オペレーティングシステム
３６：複製データＤ
４０：端末Ｄ
４２：データ管理部Ｄ
４４：データＤ
４５：オペレーティングシステム
４６：センサＤ
５０：ネットワーク
１００，１１０：ユーザ
１０１：データ名
１０２：更新内容
１０３：データ配置端末のアドレス
１０４：メタデータの識別子
【図１】
2005063374.tif 000003
【図２】
2005063374.tif 000004
【図３】
2005063374.tif 000005
【図４】
2005063374.tif 000006
【図５】
2005063374.tif 000007
【図６】
2005063374.tif 000008
【図７】
2005063374.tif 000009
【図８】
2005063374.tif 000010
【図９】
2005063374.tif 000011
【図１０】
2005063374.tif 000012