JP2020155085A - データ管理システム - Google Patents

Abstract

【課題】階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。【解決手段】管理システムは、管理対象データであるメタデータを生成する最下層の複数の処理装置と、それら処理装置が生成したメタデータの一部を記憶する少なくとも１階層の上位の管理装置（例えばメタデータサーバ）と、を含む階層構造を有する。管理装置は、メタデータのうち、自装置内に実体データを記憶していない項目については、階層構造状でその管理装置の下位にある管理装置又は処理装置に記憶されている、その項目の実体データを特定するリンク情報を記憶している。管理装置は、要求されたメタデータの項目の実体データを持っていない場合、リンク情報を用いてその実体データをユーザに提供する。【選択図】図６

Description

本発明は、データ管理システムに関する。

出願人は、管理装置（又は管理システム）と複数の処理装置とからなる２層構造を含むドキュメント管理システムを提案している（特許文献１〜４参照）。処理装置は、主として、本システムに登録されるドキュメントを暗号化等により保護する処理と、この処理により得られた保護済みドキュメントを送信先のユーザに配信する処理とを担う。管理装置は、処理装置群を管理すると共に、それら処理装置が生成した保護済みドキュメントのメタデータを保管し、保管したメタデータの提供を行う。ユーザは、それぞれ自分のホームとする処理装置に登録される、例えば、処理装置は、企業の部署等の単位ごとに設置され、その単位に属するユーザはその単位に設置された処理装置に登録される。

ユーザがシステムに登録したドキュメントの保護済みドキュメントは、そのユーザがホームとする処理装置に保存される。そして、そのユーザが指定した送信先のユーザであって、その処理装置自身、又は、その処理装置に対して安全であるものとして登録された他の処理装置、を介してそのドキュメントの配信を要求したユーザの端末に送信される。保護済みドキュメントは、それが登録された処理装置と、送信先に指定されたユーザの端末には保存されるが、管理装置や他の処理装置、他の端末には保存されない。

また、保護済みドキュメントのメタデータには、その保護済みドキュメントに対する閲覧権限等の権限を持つユーザの情報が保持される、この権限の情報は、その保護済みドキュメントをシステムに登録したユーザ（登録者）等の権限を有する者が処理装置を介してシステムに登録したり、変更したりする。端末は、その端末を操作しているユーザから、その端末内の保護済みドキュメントの閲覧指示を受けた場合、その保護済みドキュメントの識別情報に対応する最新のメタデータを近傍の処理装置を介して取得し、そのユーザが現在その保護済みドキュメントの閲覧権限を持つのかを、その最新のメタデータに基づき判定する。閲覧権限を持つと判定した場合は、端末はその保護済みドキュメントをメタデータ中の鍵情報を用いて復号して表示し、そうでない場合は閲覧不可の旨をユーザに通知する。

以上に説明したように、このシステムは、保護済みドキュメントが、これを登録したユーザのホームの処理装置と、そのユーザが指定した送信先の各ユーザの端末と、にしか保持されないという仕組みにより、保護済みドキュメントが第三者の手に渡りにくくしている。

特開２０１８−１５６４０９号公報 特開２０１８−１５６４１０号公報 特開２０１８−１５６４１１号公報 特開２０１８−１５６３８３号公報

第１の管理装置に管理されている第２の管理装置が存在するような階層構造になっている管理システムにおいて、管理の対象となるデータ（以下、管理対象データと呼ぶ）の実体を最上位の管理装置（例えば第１の管理装置）が全て管理しようとするとセキュリティ上問題になることがあった。例えば、最上位の管理装置が管理対象データの実体を全て管理しようと下位の管理装置（例えば第２の管理装置）が管理する一部の管理対象データの実体を上位の管理装置に提供する際、下位の管理装置と上位の管理装置を運営する主体（例えば企業）が異なる場合や、下位の管理装置に管理される管理対象データやこれに対応付けられたデータが下位の管理装置の外になるべく出したくないデータである場合等がその一例である。

本発明は、階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供することを目的とする。

請求項１に係る発明は、階層構造をなす複数の装置を含み、前記複数の装置のうち、ある階層に位置する少なくとも一以上の装置は、ドキュメントについての複数の項目からなるメタデータについて実体データ又はリンク情報を記憶する記憶手段、を備え、前記リンク情報は、前記階層構造上の下位又は上位の装置に記憶されている前記実体データの所在を表す情報であることを特徴とするデータ管理システムである。

請求項２に係る発明は、前記階層構造上の特定階層以上の各階層に位置する前記装置の前記記憶手段に前記実体データが記憶される前記項目の数は、当該装置が位置する階層が上位であるほど少ない、ことを特徴とする請求項１に記載のデータ管理システムである。

請求項３に係る発明は、同一のドキュメントのメタデータの一部又は全部の項目の実体データを前記記憶手段に記憶している前記階層構造上の各階層の前記装置は、前記階層構造における当該装置の位置する階層が上位になるほど、前記記憶手段に前記メタデータのうち前記実体データを記憶する項目が少ない、ことを特徴とする請求項１に記載のデータ管理システムである。

請求項４に係る発明は、前記複数の装置のうち前記階層構造の最下階層及び最上階層を除く各階層に位置する装置は、前記下位の装置から前記記憶対象の項目の実体データを受信する受信手段と、受信した前記記憶対象の項目の実体データのうちの所定の一部の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、前記受信手段が受信した前記記憶対象の項目の実体データを、前記リンク情報と対応付けて前記記憶手段に格納する制御を行う格納制御手段と、を更に含む請求項２又は３に記載のデータ管理システムである。

請求項５に係る発明は、前記格納制御手段は、前記受信手段が前記記憶対象の項目の実体データの受信の際に得た前記下位の装置の情報から前記リンク情報を生成し、生成したリンク情報と、前記受信手段が受信した前記記憶対象の項目の実体データと、を前記記憶手段に格納する、ことを特徴とする請求項４に記載のデータ管理システムである。

請求項６に係る発明は、前記階層構造上の前記最下階層に位置する装置は、当該装置が前記ドキュメントについて実行した処理に基づいて前記ドキュメントの前記メタデータを生成する手段と、生成した前記メタデータのうちの所定の一部の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、を更に含む請求項１〜５のいずれか１項に記載のデータ管理システムである。

請求項７に係る発明は、前記複数の装置の各々は、前記メタデータについての検索要求を受信する手段と、前記検索要求を満たす前記メタデータを検索するための制御を行う検索制御手段であって、当該装置に対応する前記階層構造上の下位又は上位のうちの少なくとも一方の装置に対して前記検索要求を転送する機能を持つ検索制御手段と、を更に含む請求項１〜６のいずれか１項に記載のデータ管理システムである。

請求項８に係る発明は、同一のメタデータの一部又は全部の項目の実体データを前記記憶手段に記憶している前記階層構造上の各階層の前記装置は、当該メタデータの識別情報を前記記憶手段に記憶しており、前記検索制御手段は、前記検索要求が特定の識別情報を持つ前記メタデータを求めるものである場合において、当該識別情報が前記記憶手段に記憶されていない場合には、当該装置に対応する前記階層構造上の上位の装置に前記検索要求を転送し、当該識別情報が前記記憶手段に記憶されている場合には、当該装置に対応する前記階層構造上の上位の装置には前記検索要求を転送しない、請求項７に記載のデータ管理システムである。

請求項１、２、３に係る発明によれば、階層構造になっている管理システムにおいて、ドキュメントのメタデータのすべての項目の実体データを最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供することができる。

請求項４又は６に係る発明によれば、請求項１に係るシステムのために、階層構造の上位になるほど実体データを記憶している項目が少なくなるようにすることができる。

請求項５に係る発明によれば、下位の装置からリンク情報が送られてこない場合でも，リンク情報を記憶することができる。

請求項７に係る発明によれば、検索要求が求めるメタデータが自装置にない場合に，システム内の他の装置にてその検索要求が処理されるようにすることができる。

請求項８に係る発明によれば、ある識別情報を持つメタデータを検索する検索要求に対して、自装置にそのメタデータがない場合に、そのメタデータを記憶している可能性がある上位の装置にその検索要求を処理させることができる。

ドキュメント管理システムの構成の例を示す図である。 組織内管理システムを設けたシステム構成の例を示す図である。 メタデータの項目を例示する図である。 ドキュメント管理システムに含まれる処理装置及びＭＤＳ（メタデータサーバ）の階層構造を例示する図である。 階層が上位になるにつれ、メタデータのうち処理装置及びＭＤＳが実体データを記憶する項目を少なくしていくことを説明する図である。 あるレベルのＭＤＳが記憶しているメタデータの項目内容を示す図である。 図６の例より下位のレベルのＭＤＳが記憶しているメタデータの項目内容を示す図である。 ドキュメントの登録を指示されたときに処理装置が実行する処理手順の例を示す図である。 下位装置からメタデータがアップロードされたときにＭＤＳが実行する処理手順の例を示す図である。 ユーザの端末から検索要求を受け取ったときに処理装置が実行する処理手順の例を示す図である。 他の装置から検索要求を受け取ったときにＭＤＳが実行する処理手順の例を示す図である。 他の装置から検索要求を受け取ったときにＭＤＳが実行する処理手順の別の例を示す図である。

＜実施形態の制御の適用先となるシステムの例示＞
図１及び図２に、本実施形態の制御が適用されるドキュメント管理システムの概略構成を例示する。図１及び図２に示すシステムは、特許文献１〜４に例示したものと同様のものであり、ここでは概略の説明を行う。これらのシステムの詳細については、特許文献１〜４を参照されたい。

図１及び図２に例示するドキュメント管理システムは、電子的なドキュメントをセキュアに利用できる環境を提供し、ドキュメントの情報が漏洩するリスクを下げることを目指す。ここで、ドキュメントは、１つの単位（例えば１つのファイル）として流通可能なコンテントデータであり、データの種類は特に限定されない。例えば、ドキュメントの概念には、テキストデータ、ワードプロセッサソフトで作成された文書データ、表計算ソフトで作成されたスプレッドシートデータ、ＣＡＤ（Computer Aided Design）データ、画像データ、動画データ、音声データ、マルチメディアデータ、ウェブブラウザで表示されたページデータ、その他ＰＣ上で作成・編集・閲覧されプリントアウト対象となる様なデータなどが含まれる。

図１のドキュメント管理システムは、複数のローカルシステム１００とそれらローカルシステムに関する管理（特に後述する処理システムの管理）を行う管理システム２００とを含む。管理システム２００は、インターネット等の広域ネットワーク１０を介して各ローカルシステム１００と通信可能である。

ローカルシステム１００は、ローカルネットワーク１０８に接続された１以上の作成端末１０２、１以上の閲覧端末１０４、及び処理装置１１０を含む。ローカルネットワーク１０８は、企業等の組織内に設けられたプライベートネットワーク（例えばＬＡＮとして構成）であり、ファイアウォール等により広域ネットワーク１０から保護されている。処理装置１１０は、基本的に、ローカルシステム１００内に１つ設置される。組織内のプライベートネットワークが大規模なものである場合、プライベートネットワークを構成する個々のネットワークセグメントをそれぞれローカルシステム１００とし、それら個々のローカルシステム１００内に１つずつ処理装置１１０を設置してもよい。

作成端末１０２は、ドキュメントを作成するために用いられる端末であり、例えばデスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン、複合機、スキャナ、ファクシミリ装置、デジタルカメラ等がその例である。作成端末１０２には、ドキュメントの作成、編集等のためのアプリケーションがインストールされている。また、作成端末１０２には、作成したドキュメントの配信をドキュメント管理システムに依頼するためのソフトウエアがインストールされている。このソフトウエアの形態としては、後述する処理装置１１０と情報をやりとりするデバイスドライバとして実装、又はＷｅｂアプリによる実装、などが考えられる。

処理装置１１０は、作成端末１０２が作成したドキュメントを、ドキュメント管理システムが提供するセキュアな環境で用いる形態である保護済みドキュメント（以下では「ｅＤｏｃファイル」とも呼ぶ）へと変換するという保護処理を実行する。保護処理は、元のドキュメントをｅＤｏｃへとエンコードする処理ともいえ、この意味では処理装置１１０は一種のエンコーダである。この保護処理では、ドキュメントを、例えば、本実施形態のシステムのために設計された専用フォーマットのデータに変換すると共に、そのドキュメントの配信先に指定されたユーザにのみ復号可能な形で暗号化する。フォーマット変換と暗号化はどちらを先に行ってもよい。

また処理装置１１０は、保護済みドキュメントのメタデータを作成し、作成したメタデータを、内蔵するデータベースにその保護済みドキュメントと対応付けて保存すると共に、上位システムである管理システム２００にそのメタデータを登録する。メタデータは、当該保護済みドキュメントの書誌事項、配信先の情報、アクセス権限情報、各配信先が保護済みドキュメントの暗号化を解除するのに用いる鍵情報等を含む。書誌事項には、例えばそのドキュメントのＤＩＤ、そのドキュメントを本システムに登録したユーザ（すなわち配信者）のユーザＩＤ、登録の日時（すなわちエンコード日時）等の項目が含まれる。メタデータが含む項目の中には、このサービスで提供される機能に応じて、対応するデバイスやユーザからデータ付与や更新が行われる場合もある。また例えば、それら項目のうちの一部を、ドキュメント管理システムに対するドキュメントの登録指示を行ったユーザが指定し、別の一部は処理装置１１０が作成する。また、メタデータのうちの一部の項目の値を管理システム２００や閲覧端末１０４が設定することもあり得る。また、処理装置１１０は、生成した保護済みドキュメント（ｅＤｏｃファイル）を、ユーザの指定した配信先の閲覧端末１０４に送信する。

メタデータは、本実施形態の管理の対象である管理対象データの一例である。

保護済みドキュメントすなわちｅＤｏｃファイルは、元のドキュメントを専用フォーマットに変換し暗号化したものであり、ｅＤｏｃの本体とも呼ぶ。ｅＤｏｃファイルを閲覧可能とするには、対応するメタデータが必要となる。ｅＤｏｃファイルとメタデータとが揃って、閲覧可能な完全な保護済みドキュメントを構成する。このように、ｅＤｏｃファイルとこれに対応するメタデータとの組を、以下では「ｅＤｏｃ」と呼ぶ。

各ユーザには、それぞれ自分にとっての既定の処理装置１１０が決められている。既定の処理装置１１０は、典型的には、ユーザが所属する部署に設置された処理装置１１０である。典型的な利用シーンでは、ユーザは、自分の部署内の他のユーザと共有するドキュメントをその処理装置１１０に登録し、それら他のユーザに配信する。ユーザの既定の処理装置１１０は、そのユーザのユーザＩＤと対応付けてユーザＩＤサーバ２１０に登録されている。ユーザが、既定の処理装置１１０以外の処理装置１１０に対してドキュメントの登録を依頼した場合、依頼を受けた処理装置１１０は、そのドキュメントを保護済みドキュメントに変換し、メタデータを生成してそのメタデータを管理システム２００に登録すると共に、その保護済みドキュメントとメタデータとをそのユーザの既定の処理装置１１０に転送する。既定の処理装置１１０は、転送された保護済みドキュメントとメタデータを、内蔵するデータベースに保存する。一方、転送元の処理装置１１０は、既定の処理装置１１０に転送した保護済みドキュメント及びメタデータを、自身の記憶装置から削除する。これにより、ユーザが登録した保護済みドキュメントは、そのユーザの既定の処理装置１１０にのみ保存されることとなる。

閲覧端末１０４は、保護済みドキュメント（ｅＤｏｃファイル）の閲覧に用いられる端末である。ここで言う「閲覧」は、保護済みドキュメントをそのドキュメントが表す情報内容に応じた態様で利用することを意味する。例えば、保護済みドキュメントがワープロデータや図面等の文書を情報内容として持つ場合、閲覧は、閲覧端末１０４が表示したその文書をユーザが読む又は見ることである。また保護済みドキュメントが表す情報内容が音声である場合、閲覧とは、閲覧端末１０４が再生したその音声をユーザが聞くことである。閲覧端末１０４は、例えば、デスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン等の汎用のコンピュータに、保護済みドキュメントを閲覧するためのビューワアプリケーションをインストールして構成される。また、電子書籍端末のような閲覧専用の端末に、ビューワアプリケーションと同等の機能を持たせたものを閲覧端末１０４として用いてもよい。ビューワアプリケーションは、暗号化されている保護済みドキュメントをメタデータの情報を用いて復号する機能や、保護済みドキュメントの専用フォーマットで表されるデータを可読な状態のデータへとデコードする機能を有する。なお、ドキュメント管理システムに対応するビューワアプリケーションを持たないコンピュータは、専用フォーマットのデータを可読なデータへとデコードすることはできない。

また、一例として、ドキュメント管理システムを利用するユーザを認証するためのツールとして、ユーザが携帯する認証デバイス１３０を用いる。認証デバイス１３０は、ＩＣカードのように、当該デバイスを携帯するユーザに固有の識別情報を内蔵し、外部装置からの要求に応じてユーザ認証のためのデータ処理を実行するデバイスである。認証デバイス１３０は、そのような個人認証用のＩＣカードと同等の機能を内蔵したスマートフォンのような携帯端末であってもよい。閲覧端末１０４や作成端末１０２は、ＮＦＣ（Near Field Communication）等の無線通信プロトコルを用いて認証デバイス１３０と通信する機能を備える。閲覧端末１０４や作成端末１０２は、認証デバイス１３０との間で所定のプロトコルに沿ってユーザ認証のための情報をやりとりし、その認証デバイス１３０を携帯するユーザを認証する。あるいは、実際のユーザ認証は処理装置１１０や管理システム２００等、ドキュメント管理システムのサーバ側が実行し、閲覧端末１０４や作成端末１０２は、サーバ側と認証デバイス１３０との間のデータ転送の仲介を行う方式であってもよい。また、閲覧端末１０４や作成端末１０２が認証デバイス１３０の機能を内蔵していてもよい。

管理システム２００は、各ローカルシステム１００内の処理装置１１０を管理する。また管理システム２００は、それら各処理装置１１０が生成した保護済みドキュメントのメタデータを管理し、要求に応じてメタデータを閲覧端末１０４に提供する。管理システム２００は、１台のコンピュータ、又は相互に通信可能な複数のコンピュータにより構成され、ユーザＩＤサーバ２１０、ＤＩＤサーバ２２０、メタデータサーバ２３０、処理装置管理サーバ２４０の機能を有する。

ユーザＩＤサーバ２１０は、ドキュメント管理システムを利用する各ユーザの情報を管理するサーバである。ドキュメント管理システムを利用するユーザには、２つの階層がある。１つは、ドキュメント管理システムの利用のための契約を本システムの運営者と結んだ契約者であり、もう１つはその契約の下で実際にシステムを利用してドキュメントの登録や閲覧を行う一般ユーザである。例えば、会社が契約者であり、その会社のローカルネットワーク１０８に処理装置１１０が設置され、その会社の社員が一般ユーザとして、その処理装置１１０を介してドキュメント管理システムを利用するケースが多いと想定される。ユーザＩＤサーバ２１０は、契約者と一般ユーザのそれぞれについての情報を保持し、管理する。

ＤＩＤサーバ２２０は、保護済みドキュメントの識別情報（ＩＤ）であるＤＩＤ（ドキュメントＩＤ）を管理する。実際に保護済みドキュメントにＤＩＤを付与するのはその保護済みドキュメントを作成した処理装置１１０であるが、ＤＩＤサーバ２２０は処理装置１１０に対してＤＩＤの発行権限と発行枠（発行数）を付与し、その発行権限と発行枠の中で処理装置１１０が実際に発行したＤＩＤの報告を受けて記録する。これにより、ＤＩＤサーバ２２０は、不正なＤＩＤの発生を抑止し、不正なＤＩＤを持つドキュメントを検知可能とする。

メタデータサーバ２３０は、処理装置１１０が生成した保護済みドキュメント（ｅＤｏｃファイル）のメタデータを保持し、管理する。メタデータサーバ２３０は、ユーザから閲覧端末１０４を介して保護済みドキュメントのメタデータを要求された場合、そのユーザが正当な者であれば、メタデータをその閲覧端末１０４に提供する。なお、メタデータを要求するユーザ（閲覧者）がメタデータサーバ２３０にとって「正当な者」であるとは、そのユーザと、そのユーザがその要求を発する際に用いた閲覧端末１０４との組合せが、そのｅＤｏｃファイルのＤＩＤ（これはその要求に含まれる）に対応づけてメタデータサーバ２３０が保持しているメタデータ中の配信先情報に示される配信先ユーザ及び配信先の閲覧端末１０４の組合せに該当する場合のことである。

処理装置管理サーバ２４０は、各処理装置１１０のステータス（状態）を管理するサーバである。

図１のシステムにおける処理の流れを概説する。

ユーザは、ドキュメントをドキュメント管理システムに登録したい（すなわち配信したい）場合、作成端末１０２に対して認証デバイス１３０等を用いてログインし、ドキュメント登録を指示する。ユーザは、作成端末１０２に保持されているドキュメントからドキュメント管理システムに登録するものを選んでその登録を指示する。

すると、作成端末１０２は、選ばれたドキュメントに対する属性データのうちそのユーザが指定すべき項目（例えばドキュメントの配信先）の入力を受け付ける。ここで、配信先として、ユーザと閲覧端末１０４の組合せの指定を受け付けるようにしてもよい。この場合、ユーザと、そのユーザがドキュメントの閲覧に用いる閲覧端末１０４との組合せが、配信先として指定された組合せと一致する場合に、ユーザはそのドキュメントを閲覧可能となる。

作成端末１０２は、ユーザが入力した配信先等の属性項目と、作成端末１０２自身が生成した他の属性項目（例えば登録者の情報、作成日時等）と合わせた属性データを、そのドキュメントのデータと共に処理装置１１０に送信する。

処理装置１１０は、作成端末１０２から受信した登録対象のドキュメントに対して保護処理を施すことで保護済みドキュメント（ｅＤｏｃファイル）を生成する。この生成では、受信したドキュメントをドキュメント管理システムの専用フォーマットへとエンコードし、エンコードしたデータを、生成した暗号鍵を用いて暗号化することで、ｅＤｏｃファイルを生成する。エンコードと暗号化の順序は逆でもよい。また処理装置１１０は、そのｅＤｏｃに対して一意なＤＩＤを付与する。生成されたＤＩＤは、ｅＤｏｃファイル内に（例えばそのファイルのプロパティの一項目として）組み込まれる。

また処理装置１１０は、生成したｅＤｏｃファイルに対応するメタデータを生成する。このメタデータには、作成端末１０２からそのドキュメントと共に受け取った属性データと、処理装置１１０自身が生成した属性項目（例えば、ＤＩＤ、処理装置自身のＩＤ、エンコード日時、暗号鍵情報）の値とが含まれる。メタデータに含まれる暗号鍵情報は、ｅＤｏｃファイルの暗号化を解除するための鍵を示す情報である。暗号化に共通鍵方式を用いた場合、暗号鍵情報はその共通鍵を示す情報である。ただし、共通鍵そのものを平文でメタデータに含めると、盗聴や傍受により悪用される懸念があるので、その共通鍵を配信先ユーザの公開鍵で暗号化したものを暗号鍵情報としてメタデータに組み込む。

また、処理装置１１０は、生成したｅＤｏｃファイルとメタデータを、内蔵するデータベースに保存する。

処理装置１１０は、生成したメタデータを管理システム２００に送信して登録する。管理システム２００（メタデータサーバ２３０）は、受信したメタデータを保存する。なお、詳細は後述するが、本実施形態特有の制御として、処理装置１１０は、生成したメタデータの全項目の実体データを管理システム２００に送るのではなく、そのうちの所定の（すなわち予め定めた）一部の項目群のみの実体データを管理システム２００に送る。

処理装置１１０は、生成したｅＤｏｃファイルを、配信先に指定された閲覧端末１０４に配信する。この配信は、ローカルシステム１００内のローカルネットワーク１０８を介して行われる。

閲覧端末１０４が受信したｅＤｏｃファイルは、暗号化等により保護されているのでそのままでは閲覧が不可能である。ユーザは、閲覧端末１０４でそのｅＤｏｃファイルを閲覧したい場合、閲覧端末１０４にログインした上で、閲覧端末１０４の画面上でそのｅＤｏｃの閲覧を指示する。この指示を受けた閲覧端末１０４は、アクセス可能な処理装置１１０、又は管理システム２００、にアクセスしてそのｅＤｏｃのメタデータを要求する。この要求には、そのｅＤｏｃのＤＩＤが含まれる。

この要求を受けた処理装置１１０は、そのＤＩＤに対応するメタデータの最新版を管理システム２００から取得し、その閲覧端末１０４に送信する。なお、管理システム２００（特にメタデータサーバ２３０）がその要求を受ける構成の場合には、管理システム２００がそのＤＩＤに対応するメタデータの最新版をその閲覧端末１０４に送信する。なお、処理装置１１０に対するユーザの操作によりメタデータに変更（例えばアクセス権限情報の変更）が加えられた場合、その変更は管理システム２００に伝達され、管理システム２００は自身が持つそのメタデータに対してその変更を反映させる。これにより、管理システム２００は、常に、保護済みドキュメントのメタデータの最新版を有する。

ここで、保護済みドキュメントの閲覧指示を受けた閲覧端末１０４にとってすぐに必要なのは、メタデータのうちの配信先情報とアクセス権限情報なので、処理装置１１０又は管理システムは、その要求に応じて閲覧端末１０４に対して、アクセス権限情報のみを送信してもよい。なお、配信先情報は、例えば、その保護済みドキュメントの配信先として指定されたユーザＩＤのリストを含む。また、配信先情報は、ユーザＩＤと端末ＩＤのペアのリストを含む場合もある。またアクセス権限情報は、例えば、その保護済みドキュメントの配信先情報に含まれる各ユーザＩＤに対応付けてそのユーザが持つ権限（例えば、閲覧のみ可能、又は閲覧と編集が可能等）の内容を示す情報を含む。

閲覧端末１０４は、要求したメタデータを受信すると、そのメタデータに含まれる配信先情報に、当該閲覧端末１０４と現在この閲覧端末１０４を利用しているユーザとの組合せが含まれるかどうかを判定する。含まれていない場合、そのユーザはその閲覧端末１０４でそのｅＤｏｃを閲覧する権限がないので、閲覧端末１０４はｅＤｏｃファイルを開かず、閲覧権限がない旨を示すエラーメッセージを表示する。含まれる場合は、そのユーザはその閲覧端末１０４でそのｅＤｏｃファイルを閲覧する権限を持つ。この場合閲覧端末１０４は、そのｅＤｏｃファイルをそのメタデータに含まれる鍵情報を用いて復号し、そのｅＤｏｃファイルの復号結果の情報内容に応じた態様で出力する。

メタデータが最初の管理システム２００に登録された後、そのメタデータに含まれる配信先情報やアクセス権限情報が配信者、又は配信先の変更権限が与えられた者（例えばデータの編集権限を保有する者）により変更されることがある。ｅＤｏｃが作成・登録された時点で配信先に指定されたユーザであっても、その後の変更により配信先から外された場合には、閲覧端末１０４は、管理システム２００から取得した最新のメタデータに含まれる配信先情報によりそのことを検知し、ｅＤｏｃファイルの表示を行わない。

図１は、処理装置１１０群と管理システム２００の２階層の階層構造を持つシステムであったが、新たな管理システムの階層を挿入することで、３階層以上のシステムとすることもできる。図２に３階層のシステムを例示する。

図２に示す例では、企業等の組織のプライベートネットワークである組織内ネットワーク内にローカルシステム１００が複数存在する。そして、組織内ネットワークには、組織内管理システム１５０が設けられている。組織内管理システム１５０は、ドキュメント管理システムのうち当該組織内の処理やそれに必要な情報を管理する。すなわち、管理システム２００は、ドキュメント管理システムのサービスプロバイダが運用し、ドキュメント管理システムを利用する複数の組織についての情報や処理を管理するのに対し、組織内管理システム１５０はそれら情報や処理のうち当該組織に関する部分を、管理システム２００の管理下で管理する。

組織内管理システム１５０は、ローカルユーザＩＤサーバ１５２、ローカルＤＩＤサーバ１５４、及びローカルメタデータサーバ１５６を有する。

ローカルユーザＩＤサーバ１５２は、当該組織のメンバのうちドキュメント管理システムにユーザ登録されているユーザの情報を管理する。ローカルユーザＩＤサーバ１５２が保持する個々のユーザの情報は、ユーザＩＤサーバ２１０が保持する一般ユーザの情報と同様である。処理装置１１０に対して、その処理装置１１０を取得し利用するユーザ（すなわちその処理装置１１０を「既定の処理装置」とするユーザ）が登録されると、処理装置１１０は登録されたユーザの情報を組織内のローカルユーザＩＤサーバ１５２に送る。ローカルユーザＩＤサーバ１５２は、受け取ったユーザの情報を保存すると共に、広域ネットワーク３００経由で中央の管理システム２００のユーザＩＤサーバ２１０に送る。ユーザＩＤサーバ２１０は、受け取ったユーザの情報を保管する。また、処理装置１１０に登録されたユーザの情報に変更が生じた場合、管理者等が処理装置１１０に対してそのユーザの情報の変更を行う。処理装置１１０は、このユーザ情報の変更内容の情報（例えばユーザＩＤと、変更された情報項目の項目名と、その項目の変更後の値とを含む）をローカルユーザＩＤサーバ１５２に送信し、ローカルユーザＩＤサーバ１５２は、受信した変更に内容に応じて自身が保管している当該ユーザの情報を変更する。また、ローカルユーザＩＤサーバ１５２は、受け取った変更内容の情報を中央のユーザＩＤサーバ２１０に送り、ユーザＩＤサーバ２１０は送られてきた情報に応じて、自分が保持するそのユーザの情報を変更する。

ローカルＤＩＤサーバ１５４は、当該組織の組織内ネットワークに属する各ローカルシステム１００内の処理装置１１０が発行したＤＩＤを受け取り、保管する。ローカルＤＩＤサーバ１５４が保持する情報は、ＤＩＤサーバ２２０が保持する情報と同様である。またローカルＤＩＤサーバ１５４は、処理装置１１０から受け取ったＤＩＤの情報を中央のＤＩＤサーバ２２０に送り、ＤＩＤサーバ２２０はその情報を保管する。また、ローカルＤＩＤサーバ１５４は、中央のＤＩＤサーバ２２０からＤＩＤの発行権限及び発行枠を付与され、その発行枠の範囲内で、その発行権限に基づいて管理下の各処理装置１１０に対してＤＩＤの発行権限及び発行枠を付与する。

ローカルメタデータサーバ１５６は、当該組織の組織内ネットワークに属する各ローカルシステム１００内の処理装置１１０が生成したｅＤｏｃのメタデータを受け取り、保管する。ローカルメタデータサーバ１５６が保持する情報は、メタデータサーバ２３０が保持する情報と同様である。またローカルメタデータサーバ１５６は、処理装置１１０から受け取ったメタデータを中央のメタデータサーバ２３０に送り、メタデータサーバ２３０はそのメタデータを保管する。

以上に例示した図１及び図２のシステムにおいて、処理装置１１０がｅＤｏｃと共に生成したメタデータの全部の項目の値が上位の装置、すなわち組織内管理システム１５０や管理システム２００に登録されると、不都合な場合がある。例えば、処理装置１１０が設置されている部署における部署内限定の極秘情報が、ｅＤｏｃのメタデータ内に含まれる場合、その部署は、その極秘情報を上位の組織内管理システム１５０や管理システム２００に開示することを望まない。同様に、組織の秘密事項がメタデータに含まれる場合、その組織は、その秘密事項を組織外にある管理システム２００に開示することは望まない。

そこで、本実施形態では、メタデータの項目のうち下位の装置（例えば処理装置１１０）が秘密にしたい項目が上位の装置（例えば管理システム２００）に登録されないように制御する。

このドキュメント管理システム、特にそのうちのメタデータを管理する機構が、データ管理システムの一例である。

この制御について説明する前に、本実施形態におけるメタデータの項目構成の例を、図３を参照して説明する。

図３に例示するメタデータに含まれる項目群は、書誌情報、基本アプリ関連情報、アクセスログ情報、拡張情報、という４つの種別に大別される。個々のｅＤｏｃのメタデータには、これら４つの種別の項目群が含まれ得る。

書誌情報は、当該メタデータに対応するｅＤｏｃについての書誌を示す情報である。書誌情報には、当該メタデータに対応するｅＤｏｃのＤＩＤ、契約識別情報、ドキュメント名、配信者ＩＤ、エンコード日時、処理装置、等の項目が含まれる。契約識別情報は、そのｅＤｏｃを生成した処理装置１１０が所属する組織が、中央の管理システム２００の運営者と結んでいる、本実施形態のシステムの利用のための契約を識別する識別情報である。またドキュメント名はそのｅＤｏｃのファイル名である。配信者ＩＤは、そのｅＤｏｃを処理装置１１０に対して登録したユーザのユーザＩＤである。エンコード日時は、そのユーザからの登録指示に応じてｅＤｏｃが作成（すなわちエンコード）された日時であり、処理装置ＩＤは、そのｅＤｏｃを作成した処理装置１１０の識別情報である。

基本アプリ関連情報は、ｅＤｏｃに対して本実施形態のシステムが提供するサービス（基本アプリと呼ぶ）が用いる情報である。基本アプリ（ここで「アプリ」は、アプリケーションの略）には、ｅＤｏｃの配信、配信されたｅＤｏｃに対するユーザのアクセス管理（例えば閲覧等の可否の管理）等がある。基本アプリ関連情報には、例えばアクセス権限情報、配信先情報、暗号化情報、キーワード情報、オフライン有効期間などの項目が含まれる。アクセス権限情報、配信先情報については既に説明した。暗号化情報は、暗号化されているｅＤｏｃを復号するための鍵を示す情報である。ｅＤｏｃは、所定形式にエンコードしたドキュメントをある鍵で暗号化したものであるが、暗号化情報は、配信先ユーザのそれぞれについて、暗号化に用いたその鍵をその配信先ユーザの公開鍵で暗号化した鍵情報を含む。キーワード情報は、本実施形態のシステムが提供する簡易的な検索サービスに用いられる、当該ｅＤｏｃの検索用キーワード（すなわち検索インデックス）群を含む。なお、ここでいう「簡易的な検索サービス」は、後述する外部アプリの１つが提供する高度な検索サービスとの比較のための用語である。オフライン有効期間は、閲覧端末１０４が既に取得済みのメタデータ中のアクセス権限情報及び配信先情報が有効である期間の長さである。閲覧端末１０４が処理装置１１０、組織内管理システム１５０又は管理システム２００等からそのメタデータを取得した時点から、オフライン有効期間の長さの期間内では、閲覧端末１０４は、その取得済みのメタデータ内のアクセス権限情報及び配信先情報を用いて、そのメタデータに対応するｅＤｏｃに対するユーザのアクセスを制御する。一方、取得済みのメタデータ内のオフライン有効期間が過ぎた時点でユーザからそのｅＤｏｃに対する閲覧等のアクセスが要求された場合には、閲覧端末１０４は、最寄りの処理装置１１０、組織内管理システム１５０又は管理システム２００からそのメタデータの最新版の情報を取得する。そして、これに応じて取得した最新版の情報に従って、その要求に係るアクセスを許可するか否かを制御する。

アクセスログ情報は、当該メタデータに対応するｅＤｏｃへのユーザからのアクセスについてのログ情報である。アクセスログ情報には、例えばユーザからｅＤｏｃへのアクセスがあるごとに、アクセス日時、アクセス種別（例えば閲覧、編集等）、そのユーザのユーザＩＤ（すなわち項目「アクセス者」）等の項目が互いに対応付けて追加される。

拡張情報は、メタデータの項目のうち外部アプリが用いる項目群のことである。本実施形態のシステムの運営者以外の者が、運営者の許可を受けて、そのシステムを介してユーザ側に提供するサービスが外部アプリである。拡張情報には、外部アプリが実行する処理の材料となる情報を含む項目、又は外部アプリの処理結果を保持する項目、が含まれ得る。図３には、前者の例として、高度な検索サービスを提供するいくつかの外部アプリが検索のために用いる高度検索用インデックス、分野別の翻訳サービスを提供する外部アプリがその翻訳のために利用する分野別翻訳用処理データ、を例示している。また、後者の例として、ある外部アプリＡの処理結果を保持する項目を示している。

次に、図４を参照して、本実施形態のシステムの階層構造の例を説明する。図４は、特にメタデータの管理の観点から、メタデータサーバ（図ではＭＤＳと表記）の階層構造を示している。しかし、ＭＤＳと同じ階層には、そのＭＤＳと共に管理を担う、ユーザＩＤサーバ、ＤＩＤサーバ等が存在する。

図４に例示する階層構造は、図１及び図２に例示したシステムよりも多い、レベル０〜４の５つの階層を有する。

最上位の階層であるレベル０は、本実施形態のシステムの運営者が管理する中央ＭＤＳ２３０ａの階層である。中央ＭＤＳ２３０ａは、全世界で唯一のＭＤＳであり、全世界にある全ての処理装置１１０が生成したメタデータ群を記憶する。ただし、中央ＭＤＳ２３０ａが記憶するのは、それらメタデータの全項目ではなく、それら項目うち、中央ＭＤＳ２３０ａに記憶することが許された項目のみである。中央ＭＤＳ２３０ａは、このシステムにおける最上階層の装置に該当する。

上から２番目の階層であるレベル１は、国や地域等の管理単位ごとに設けられたＭＤＳ２３０ｂが属する階層である。ＭＤＳ２３０ｂは、その管理単位に属する各組織内の処理装置１１０が生成したメタデータ群を記憶する。ただし、ＭＤＳ２３０ｂが記憶するのは、それらメタデータの全項目ではなく、それらの項目うち、ＭＤＳ２３０ｂに記憶することが許された項目のみである。

上から３番目の階層であるレベル２は、国や地域等の管理単位内に存在する組織（例えば企業）に設置されたローカルＭＤＳ１５６ａの階層である。ローカルＭＤＳ１５６ａは、当該組織内の最上位のＭＤＳであり、その組織全体のメタデータを管理する。すなわち、ローカルＭＤＳ１５６ａは、その組織内の処理装置１１０が生成したメタデータ群を記憶する。ただし、ローカルＭＤＳ１５６ａが記憶するのは、それらメタデータの全項目ではなく、それら項目うち、ローカルＭＤＳ１５６ａに記憶することが許された項目のみである。

上から４番目の階層であるレベル３は、組織内での２番目の階層であり、例えばその組織内の管理単位ごとに設けられたローカルＭＤＳ１５６ｂを含む。組織内の管理単位には、例えばその組織が有する拠点、例えば本社、支社、営業所、工場、研究所等、がある。

図４の例は、組織が大規模であるため、組織内管理システムの階層を２階層にしている。管理単位のローカルＭＤＳ１５６ｂは、当該管理単位全体のメタデータを管理する。すなわち、ローカルＭＤＳ１５６ｂは、その管理単位（例えば組織内の１拠点）内の処理装置１１０が生成したメタデータ群を記憶する。ただし、ローカルＭＤＳ１５６ｂが記憶するのは、それらメタデータの全項目ではなく、それら項目うち、ローカルＭＤＳ１５６ｂに記憶することが許された項目のみである。

なお、本実施形態のシステムの運営者の委託を受けてサービスを提供するサービスプロバイダ（又はサービスの販売会社）があり、そのサービスプロバイダが例えば中小企業等の顧客組織にサービスを提供する場合が考えられる。この場合、サービスプロバイダと顧客組織とからなる集合を１つの組織と捉えることができる。この例では、個々の顧客組織にレベル３のローカルＭＤＳ１５６ｂが設けられ、サービスプロバイダにそれらローカルＭＤＳ１５６ｂを統括するレベル２のローカルＭＤＳ１５６ａが設けられる。

最下層であるレベル４は、メタデータを生成し、保存する処理装置１１０が属する階層である。処理装置１１０は、基本的には、自身が生成したメタデータの全項目を記憶する。ただし、メタデータの項目のうち所定の項目群については処理装置１１０内に記憶しないように設定することも可能である。処理装置１１０は、このシステムにおける最下階層の装置に該当する。

各階層の装置は、それぞれ、階層構造における自装置の直接の上位の装置のアドレス情報を記憶している。例えば、処理装置１１０は、階層構造において自分の上位の装置である、レベル３のローカルＭＤＳ１５６ｂ（又はこれを含むレベル３の組織内管理システム）のアドレス情報を有する。また例えばローカルＭＤＳ１５６ｂは、階層構造において自分の上位である、レベル２のローカルＭＤＳ１５６ｂ（又はこれを含むレベル２の組織内管理システム）のアドレス情報を有する。各階層の装置は、その上位の装置のアドレス情報を用いて、メタデータを上位の装置にアップロードする場合等、上位の装置と通信する場合に、そのアドレス情報を用いる。

次に、図４の各レベルの装置がそれぞれメタデータの項目群のうちのいずれの項目の実体データを記憶するかという記憶構成の例を、図５を参照して説明する。

記憶構成の基本的な考え方は、階層すなわちレベルが高くなるほど、その階層の装置が実体データを記憶する項目を少なくするというものである。図５の例は、図３に示したメタデータの項目群の種別のうち、種別ＩＤの番号が大きいものほど、ユーザ側（すなわち組織やその組織内の拠点、部署）にとって秘密度合いが高い場合の例である。

ここで、メタデータの項目の「実体データ」とは、そのメタデータのうちのその項目の実体的な値である。これに対して、後述するリンク情報は、当該項目の実体データを指し示す情報である。

最下層であるレベル４の処理装置１１０は、メタデータ及びそのメタデータに対応するｅＤｏｃ本体を生成し記憶する装置なので、基本的にメタデータの全項目を記憶する。図５の例では、レベル４の処理装置１１０は、書誌情報、基本アプリ関連情報、アクセスログ情報、拡張情報の４つの種別に属する全ての項目を記憶する。なお、図５では、各レベルの装置が記憶するメタデータ項目の種別を太字で示した。

また図５の例では、レベル３のローカルＭＤＳ１５６ｂは、書誌情報、基本アプリ関連情報、アクセスログ情報に属する項目群は記憶するが、拡張情報に属する項目群は記憶しない。この例は、拡張情報に属する項目群が、処理装置１１０の設置された部署の外には秘密である場合のものである。

また図５の例では、レベル２のローカルＭＤＳ１５６ａは、書誌情報、基本アプリ関連情報に属する項目群は記憶するが、アクセスログ情報及び拡張情報に属する項目群は記憶しない。この例は、アクセスログ情報に属する項目群が、ローカルＭＤＳ１５６ａの設置された拠点の外には秘密である場合のものである。

そして、組織の外にあるレベル１のＭＤＳ２３０ｂ及びレベル０の中央ＭＤＳ２３０ａは、書誌情報の一部の項目群は記憶するが、書誌情報の残りの部分、基本アプリ関連情報、アクセスログ情報及び拡張情報に属する項目群は記憶しない。この例は、書誌情報のうちの一部の項目と、基本アプリ関連情報に属する項目群が、組織の外には秘密である場合のものである。

以上に説明した図５の例では、主としてメタデータ項目の種別を単位として、上位の階層のＭＤＳほど、記憶するメタデータ項目の種別が少なくなった。しかし、種別を単位とするのは一例に過ぎない。各階層のＭＤＳがどの項目を記憶するかは、項目単位で規定可能である。例えば、レベル０及び１に属する中央ＭＤＳ２３０ａ及びＭＤＳ２３０ｂは、基本的には基本アプリ関連情報の種別に属する項目は記憶しないが、そのうちアクセス権情報及び配信先情報という２つの項目は記憶する、等のいった項目単位での制御が可能である。

図５に例示したように、階層が上がるにつれて、装置が実体データを記憶しているメタデータの項目が少なくなっていく記憶構成のことを、メタデータのエスカレーションと呼ぶ。

次に、図６及び図７を参照して、いくつかのレベル（すなわち階層）のＭＤＳが記憶するメタデータのデータ内容を説明する。

図６は、レベル１のＭＤＳ２３０ｂが記憶するメタデータのデータ内容を説明するための図である。図において、「項目ＩＤ」は、１つのｅＤｏｃのメタデータに含まれる各項目のＩＤ（すなわち識別情報）である。図示例では、わかりやすさを優先して、各項目の名称を項目ＩＤの欄に示している。「種別」は、それら各項目が属する種別を示す。そして「項目内容」は、ＭＤＳ２３０ｂが記憶している当該項目のデータ内容である。

図６の例では、ＭＤＳ２３０ｂは、書誌情報の種別に属する項目「ＤＩＤ」及び「契約識別情報」と、基本アプリ関連情報の種別に属する項目「アクセス権限情報」及び「暗号化情報」とについては、当該項目についての実体データを記憶している。例えば、ＭＤＳ２３０ｂは、ＤＩＤについては実際のＤＩＤの値を、契約識別情報については実際の契約識別情報の値を記憶している。項目内容に実体データが記憶されている項目は、当該ＭＤＳにとっての記憶対象の項目である。

これに対し、書誌情報のうちＤＩＤと契約識別情報を除く残りの項目については、ＭＤＳ２３０ｂは、項目内容として、当該項目の実体データの代わりにリンク情報を記憶している。項目のリンク情報は、包括的に言えば、当該項目の実体データを特定する情報である。この例では、項目のリンク情報は、階層構造において当該ＭＤＳの直下に位置する下位装置（すなわちＭＤＳ又は処理装置）に記憶されている、当該項目の項目内容を指し示す情報である。ここで、ツリー状に構成されたＭＤＳ及び処理装置の階層構造において、あるＭＤＳの「下位装置」とは、その階層構造におけるそのＭＤＳの子ノードに該当する装置のことである。例えばＭＤＳ２３０ｂが持つあるメタデータ内のある項目の項目内容であるリンク情報は、ＭＤＳ２３０ｂの子であるレベル２のローカルＭＤＳ１５６ａ群のうち、そのメタデータを持つＭＤＳ２３０ｂ内の、そのメタデータのその項目の項目内容を指し示す。リンク情報が指し示す下位装置の項目内容は、当該項目の実体データである場合もあれば、更なるリンク情報である場合もある。後者の場合も、リンク情報の指し示す先のリンク情報、更にこれが指し示すリンク情報と、連鎖的にリンク情報をたどることで、最終的に当該項目の実体データを取得することができる。この意味で、図示例のリンク情報も、当該項目の実体データを特定する情報である。

例えば、リンク情報は、下位装置のネットワーク上での位置を示す情報と、その下位装置内に記憶されたそのメタデータ内の当該項目を識別する情報とを含むものである。ここで、メタデータ内の当該項目を識別する情報は、そのメタデータの識別情報と、その項目の識別情報との組合せであってもよい。メタデータの識別情報には、例えばそのメタデータに対応するｅＤｏｃのＤＩＤを用いる。また、項目の識別情報は、例えばＤＩＤ、契約識別情報、ドキュメント名、ユーザＩＤ等といった個々の項目を一意に識別する情報である。この例では、メタデータの識別情報と項目の識別情報との組合せにより、特定のメタデータ内の特定の項目が識別される。

具体的な例では、リンク情報はＵＲＩ（Uniform Resource Identifier）又はＵＲＬ（Uniform Resource Locator）等の形式で記述される。あるＭＤＳ２３０ｂの下位装置であるローカルＭＤＳ１５６ａのホスト名が例えば「eduser.sample.com」である場合において、ＭＤＳ２３０ｂ内にある、ＤＩＤが「xxxx」であるｅＤｏｃのメタデータ内の項目「yyyy」の項目内容であるリンク情報は、例えば「data://eduser.sample.com/intApr?DID=xxx&AprID=yyyy」となる。

なお、リンク情報の記述形式はＵＲＩやＵＲＬに限らない。例えば上に例示したＵＲＬと同内容をＳＱＬのクエリとして記述した場合、「SELECT `DID`,`did` FROM `metadata3` WHERE `AprID`,`xxx`」となり、ＭＤＳ２３０ｂはそのリンク情報を参照し、下位装置に対してそのクエリを送ることで、そのメタデータの項目の項目内容を取得する。

リンク情報は、項目単位のものであってもよいし、複数の項目からなるグループ単位のものであってもよい。図６の例では、書誌情報に属するドキュメント名から処理装置ＩＤまでの４項目からなるグループについて、下位装置内のそのグループを指し示すリンク情報が記述されている。

図７に示す例は、レベル２のローカルＭＤＳ１５６ａが記憶するメタデータのデータ内容を説明するための図である。レベル１のＭＤＳ２３０ａが記憶するメタデータ（図６参照）と比較すると、ローカルＭＤＳ１５６ａが記憶するメタデータは、書誌情報内のドキュメント名から処理装置ＩＤまでの４つの項目について実体データを含んでいる点が異なる。なお、アクセスログ情報の項目内容はリンク情報となっているが、このリンク情報は、下位装置であるレベル３のローカルＭＤＳ１５６ｂ内の、当該メタデータ内のアクセスログ情報の項目内容を指し示す。

さて、本実施形態のシステムでは、図５に例示したような階層間の記憶構成を実現するために、処理装置１１０、ローカルＭＤＳ１５６，１５６ａ，１５６ｂ、及びＭＤＳ２３０ｂ等の各装置は、メタデータが含む項目のうち、それぞれ上位の装置（すなわちツリー状の階層構造における当該処理装置１１０の親のノードに該当する装置）にアップロード（すなわち送信）すべき項目を示すメタデータ管理情報を有している。すなわち、メタデータ管理情報にて、アップロードすべき項目として示されていない項目は、上位の装置に対して実体データを秘密にすべき項目である。各装置は、記憶しているメタデータのうち、メタデータ管理情報に示される項目の実体データを、当該装置の上位の装置にアップロードする。

次に、図８を参照して、ユーザの作成端末１０２からドキュメントの登録要求を受けたときの処理装置１１０が実行する処理手順の例を説明する。

この手順では、処理装置１１０は、まずそのドキュメントのｅＤｏｃ化処理を実行する（Ｓ１０）。すなわち、例えば、そのドキュメントを本システムの専用フォーマットへとエンコードし、エンコード結果を暗号化することで、ｅＤｏｃファイルを生成する。また処理装置１１０は、そのｅＤｏｃのメタデータを生成し、そのメタデータのうち実体データを取得可能な項目については、その実体データをその項目の値として記憶する（Ｓ１２）。次に処理装置１１０は、自装置が有するメタデータ管理情報を参照することで、先ほど作成して記憶したメタデータの各項目のうち、実体データを、階層構造において当該処理装置１１０の上位のローカルＭＤＳ１５６ｂにアップロードすべき項目を特定する（Ｓ１４）。そして、作成したメタデータのうち、特定した項目の実体データを、そのメタデータの識別情報及びその項目の識別情報と対応付けて、そのローカルＭＤＳ１５６ｂにアップロードする（Ｓ１６）。

なお、作成したメタデータ内の項目のうち、アップロードがなされなかった項目の実体データは、本実施形態のシステム全体において、その処理装置１１０のみが記憶していることとなる。

次に図９を参照して、下位装置からメタデータのアップロードを受けた装置の処理手順の例を説明する。この処理手順を実行する装置は、階層構造のうち、最下位（すなわち処理装置１１０）と最上位（すなわち中央ＭＤＳ２３０ａ）を除いた残りの装置、すなわちローカルＭＤＳ１５６ａ，１５６ｂ及びＭＤＳ２３０ａである。

この手順では、装置は、下位装置から登録対象のメタデータのアップロードを受け付け、そのメタデータに含まれる各項目の実体データを取得する（Ｓ２０）。次に、装置は、アップロードされたメタデータを、内蔵するデータベースに登録する（Ｓ２２）。Ｓ２２では、装置は、アップロードされたメタデータのためのエントリをデータベース内に作成し、そのエントリの各項目に対し、アップロードされたメタデータに含まれる当該項目の実体データを登録する（Ｓ２４）。

また装置は、下位装置から実体データがアップロードされなかった項目についてのリンク情報を生成し、そのリンク情報を当該メタデータの当該項目の項目内容として、データベースに登録する（Ｓ２６）。アップロードのための通信により、下位装置のホスト名がわかり、またメタデータを識別するＤＩＤはアップロードされるデータに含まれている。これらの情報と、実体データがアップロードされなかった項目の情報から、リンク情報が生成可能である。

次に装置は、自装置が有するメタデータ管理情報を参照することで、下位装置からアップロードされたメタデータの各項目のうち、階層構造において当該装置の上位の装置に実体データをアップロードすべき項目を特定する（Ｓ２６）。そして、特定した項目の実体データを、そのメタデータの識別情報及びその項目の識別情報と対応付けて、その上位装置にアップロードする（Ｓ２８）。

階層構造を構成する処理装置１１０、ローカルＭＤＳ１５６ａ及び１５６ｂ、ＭＤＳ２３０ａが、それぞれ図８又は図９に示す処理を行うことで、図５に例示したメタデータのエスカレーションが実現される。

図９の手順では、下位装置からメタデータの各項目の実体データのアップロードを受けたＭＤＳが、実体データがアップロードされなかった項目についてのリンク情報を作成した。別の例として、下位装置が、上位のＭＤＳに実体データをアップロードしない項目又は項目のグループについてのリンク情報を生成し、生成したリンク情報を、実体データと共に上位のＭＤＳにアップロードしてもよい。この場合、ＭＤＳは、下位装置からアップロードされた各項目の実体データ及びリンク情報を、内蔵するデータベースに記憶すればよい。

次に、本実施形態のシステムにおけるメタデータの検索処理について説明する。

処理装置１１０は、ユーザの端末（例えば閲覧端末１０４）からメタデータの検索要求を受け付ける。検索要求には、検索条件が含まれる。検索条件は、ユーザが欲するメタデータが満たすべき条件である。１つの例では、検索条件は、ユーザが欲するメタデータに含まれる各項目が満たすべき条件の論理式として表現される。例えば、ユーザが特定のｅＤｏｃのメタデータを欲している場合には、検索条件は、そのｅＤｏｃのＤＩＤの値をメタデータの項目「ＤＩＤ」の値として含む、というものとなる。また、検索要求には、検索条件に付随して、検索結果として得たい１以上の項目を指定する検索項目情報が含まれていてもよい。ユーザは、検索結果としてメタデータ全体を得たい場合もあれば、メタデータ中の特定の１以上の項目のみを得たい場合もある。例えば、ユーザが得たい項目（すなわち検索対象の項目）の項目ＩＤのリストが、検索項目情報となる。

処理装置１１０は、ユーザの端末から検索要求を受けた場合、その検索要求を、レベル３の階層にある、自分の上位の装置であるローカルＭＤＳ１５６ｂに転送する機能を有する。例えば、処理装置１１０が、ユーザから指定差入れた検索要求に示されるＤＩＤを含むメタデータを記憶していない場合、そのメタデータは他の処理装置１１０で作成されたｅＤｏｃのメタデータなので、上位に検索要求を転送するのである。

下位の処理装置１１０から検索要求の転送を受けたローカルＭＤＳ１５６ｂは、その検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にあるかどうかを調べ、もしなければ、その検索要求を自装置の上位のローカルＭＤＳ１５６ａに転送する。

また、ローカルＭＤＳ１５６ｂは、その検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にある場合には、そのメタデータを、転送元の処理装置１１０経由で、又は直接、検索要求を出したユーザの端末に提供する。前者の場合、ローカルＭＤＳ１５６ｂは、その処理装置１１０に対してそのメタデータを応答し、これを受け取ったその処理装置１１０が、そのメタデータを要求元の端末に送信する。後者の場合、検索要求には、要求元であるユーザの端末のアドレス情報が含まれており、ローカルＭＤＳ１５６ｂはそのアドレス情報を用いてその端末に対してそのメタデータを送信する。

ここで、その検索要求中の検索条件を満たすメタデータが、ローカルＭＤＳ１５６ｂのデータベース内にある場合でも、そのメタデータの一部の項目の実体データがない場合がある。その場合、そのデータベースには、その項目の項目内容として実体データの代わりにリンク情報が含まれる。ローカルＭＤＳ１５６ｂはそのリンク情報を用いて、その項目の実体データが、検索要求を出したユーザの端末に提供されるようにするための制御を行う。

この制御では、ローカルＭＤＳ１５６ｂは、そのリンク情報を用いて、例えば、そのリンク情報が指し示す（すなわちそのリンク情報のリンク先）データに対する要求を発する。この要求は、そのリンク情報が示す下位の処理装置１１０に送られる。この下位の処理装置１１０は、そのリンク情報が示す項目の実体データを持っており、その実体データをローカルＭＤＳ１５６ｂに返す。ローカルＭＤＳ１５６ｂは、返された実体データを、検索要求の転送元の処理装置１１０（すなわちユーザから検索要求を受け付けた装置）経由で、あるいは直接、検索要求元のユーザの端末に提供する。

またその制御の別の例では、ローカルＭＤＳ１５６ｂは、そのリンク情報が示す下位の処理装置１１０に対して、その検索要求を転送する。転送された検索要求を受け取ったその下位の処理装置１１０は、その検索要求の検索条件を満たす管理データの、検索項目情報が示す各項目の実体データを、直接、又は転送元のローカルＭＤＳ１５６を経由して、検索要求元のユーザの端末に提供する。

また、レベル３のローカルＭＤＳ１５６から検索要求の転送を受けた、レベル２にある上位のローカルＭＤＳ１５６ａは、その検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にあるかどうかを調べ、もしなければ、その検索要求をレベル２の階層にある自装置の上位のＭＤＳ２３０ｂに転送する。また、検索条件を満たすメタデータが、自分の内蔵するデータベース内にある場合、検索項目情報が示すユーザの欲する項目の実体データがそのデータベース内にあるならば、その項目の実体データを、直接、又は転送元のローカルＭＤＳ１５６ｂを経由して、検索要求元のユーザの端末に提供する。後者は、言い換えれば、検索要求が転送された経路を逆にたどって、メタデータをユーザの端末に転送することである。また、ローカルＭＤＳ１５６ａは、転送された検索要求中の検索条件を満たすメタデータが、自分の内蔵するデータベース内にある場合でも、検索項目情報が示すユーザの欲する項目の実体データがそのデータベース内にない場合には、その項目に対応するリンク情報を用いて、その項目の実体データが、検索要求を出したユーザの端末に提供されるようにするための制御を行う。この制御は、レベル３のローカルＭＤＳ１５６ｂの場合と同様でよい。

このように、各レベルのＭＤＳは、検索要求を上位又は下位の装置に転送することで、検索要求が求める検索結果を得る。

以下に、検索のための処理装置１１０、ローカルＭＤＳ１５６ａ及び１５６ｂ、ＭＤＳ２３０ａ及び２００ｂが実行する手順の例を説明する。以下では、検索条件としてＤＩＤが指定されている場合を例に取る。

例えば、ユーザが閲覧端末１０４に対して、閲覧端末１０４内に記憶されたあるｅＤｏｃの閲覧を要求したり、そのｅＤｏｃについてのメタデータの同期を指示したりした場合、閲覧端末１０４は、アクセス可能な処理装置１１０に対して、そのメタデータの最新版を要求する。この要求は、そのｅＤｏｃを特定する情報としてＤＩＤを含む。従って、この要求は、検索条件としてＤＩＤが指定されている検索要求の一例である。

図１０は、その検索要求を受け取った処理装置１１０が実行する処理手順の一例を示す。この手順では、検索要求を受け取った処理装置１１０は、検索要求中の検索条件が示すＤＩＤの値を読み取り、その値を項目「ＤＩＤ」の項目内容として持つメタデータを、内蔵するデータベースから検索する。そして、その検索条件を満たすメタデータがデータベース内から検索できたかどうかを判定する（Ｓ３０）。検索できた場合、処理装置１１０は、その検索できたメタデータを、要求元の閲覧端末１０４に応答する（Ｓ３２）。処理装置１１０のデータベースには、基本的に、メタデータ内の全ての項目の実体データが記憶されているので、処理装置１１０に対してメタデータの全項目の実体データを提供可能である。

Ｓ３０の判定結果がＮｏである場合、処理装置１１０は、その検索要求の検索条件であるＤＩＤを持つメタデータを記憶していない。そのメタデータは、他の処理装置１１０が生成したｅＤｏｃのメタデータである。この場合、処理装置１１０は、階層構造における上位のローカルＭＤＳ１５６ｂに対して、その検索要求を転送する（Ｓ３４）。

またこの例では、処理装置１１０から転送された検索要求を受け取ったローカルＭＤＳ１５６ｂは、図１１に示す処理手順を実行する。レベル２のローカルＭＤＳ１５６ａ、レベル１のＭＤＳ２３０ｂ、及びレベル０のＭＤＳ２３０ａも同様の処理手順を実行する。以下、以下の図１１の処理手順を説明する。以下の説明では、ローカルＭＤＳ１５６ｂ、ローカルＭＤＳ１５６ａ、ＭＤＳ２３０ｂ、及びＭＤＳ２３０ａを、「ＭＤＳ」と総称する。

図１１の手順では、下位の装置から転送された検索要求を受け取ったＭＤＳは、その検索要求中の検索条件が示すＤＩＤの値を読み取り、その値を項目「ＤＩＤ」の項目内容として持つメタデータを、内蔵するデータベースから検索する。そして、その検索条件を満たすメタデータがデータベース内から検索できたかどうかを判定する（Ｓ４０）。検索できた場合、ＭＤＳは、データベース内のそのメタデータが、検索要求中の検索項目情報が示す検索対象のすべての項目の実体データを含んでいるかどうかを判定する（Ｓ４２）。Ｓ４２の判定結果がＹｅｓの場合、ＭＤＳは、検索したそのメタデータのうちの検索対象の項目の実体データを要求元の閲覧端末１０４に応答する（Ｓ４４）。この応答は、ＭＤＳが直接行ってもよいし、検索要求の転送の経路を逆にたどって行ってもよい。

Ｓ４２の判定結果がＮｏの場合、検索対象の項目のうちそのＭＤＳが実体データを持っていない項目については、ＭＤＳはリンク情報を持っている。ＭＤＳは、そのリンク情報が示す下位装置に対して、その検索要求を、転送する（Ｓ４６）。

Ｓ４０の判定結果がＮｏの場合は、ＭＤＳは、上位の装置に対してその検索要求を転送する（Ｓ４８）。

Ｓ４６で当該ＭＤＳから検索要求の転送を受けた装置が処理装置１１０である場合、その処理装置１１０は、その検索要求の対象であるメタデータのすべての項目の実体データを持っているはずである。したがって、その処理装置１１０は、そのメタデータのうちの検索対象の項目の実体データを、直接に、又は検索要求の転送の経路を逆にたどって、要求元の閲覧端末１０４に応答する。

Ｓ４６で当該ＭＤＳから検索要求の転送を受けた装置が別のＭＤＳである場合、当該別のＭＤＳは、図１１の処理を実行する。ただし、この場合、当該別のＭＤＳは、検索要求の対象であるメタデータのすべての項目の実体データを持っているはずなので、Ｓ４０及びＳ４８の処理は不要である。

Ｓ４８で当該ＭＤＳから検索要求の転送を受けた装置が別のＭＤＳである場合、当該別のＭＤＳは、図１１の処理を実行する。

転送された検索要求を受け取ったＭＤＳが実行する処理手順の別の例を、図１２を参照して説明する。図１２の手順において、図１１の手順と同様のステップには，同一符号を付した。

図１２の手順では、ＭＤＳは、Ｓ４２の判定結果がＮｏの場合、検索対象の項目のうちＭＤＳ自身（以下では「注目するＭＤＳ」と呼ぶ）が持っていない項目の実体データを、下位装置から取得する（Ｓ５０）。すなわち、この場合、注目するＭＤＳは、そのＭＤＳ自身が持っていない項目についてのリンク情報を持っているので、そのリンク情報を用いて、下位装置に対して、それら項目についての実体データを要求する。この要求を受けた下位装置は、その項目の実体データを持っていれば、その実体データを要求元の上位のＭＤＳに応答し、持っていなければ、その下位装置が有するリンク情報を用いて、更なる下位装置に対してその項目の実体データを要求する。このようにリンク情報を用いて下位の装置へと要求を伝播していくことで、最終的にその項目の実体データにたどり着き、その実体データがその伝搬の経路の逆の経路で、注目するＭＤＳへともたらされる。このようにして注目するＭＤＳは、検索要求が求めているメタデータの項目の実体データを入手する。そして、このＭＤＳは、それらの項目の実体データを、直接、又はＳ４０で取得した検索要求が転送されてきた経路を逆にたどって、要求元のユーザの閲覧端末１０４に応答する（Ｓ４４）。

以上に説明したように、ドキュメント管理システムは、複数の処理装置１１０と各レベルのＭＤＳという階層構造をなす複数の装置から構成される。

ここで、処理装置１１０及びＭＤＳは、それぞれ各ｅＤｏｃのメタデータを記憶するデータベースを有する。このデータベースは記憶手段の一例である。また、またＭＤＳは、自身が内蔵するそのデータベースから、検索等に必要なメタデータ内のリンク情報を取得する機能を有しており、この機能が取得手段の一例である。また、ＭＤＳは、階層構造上の下位装置（すなわち処理装置１１０又は下位のＭＤＳ）から送信されてくるメタデータの項目群の実体データを受信する機能を有しており、この機能が受信手段の一例である。また、処理装置１１０及びＭＤＳは、メタデータの項目群のうち、上位の装置に実体データを送信すべき項目を規定する情報を保持しており、下位の装置から受信したメタデータのうち、その情報に規定される項目の実体データを上位の装置に送信する。この送信の機能が、送信する手段の一例である。

また、ＭＤＳは、下位装置から受信したメタデータの項目群の実体データと、実体データを受信しなかった項目についてのリンク情報とを、メタデータの識別情報（すなわちＤＩＤ）と対応付けてデータベースに格納する機能を有する。この機能が、格納制御手段の一例である。この機能は、下位装置から受信したメタデータの情報から、リンク情報を生成する機能を含んでいてもよい。

またＭＤＳは、ユーザの端末又は他の装置（すなわち処理装置１１０又は他のＭＤＳ）から検索要求を受信する機能を有しており、この機能が、検索要求を受信する手段の一例である。またＭＤＳは、図１１及び図１２に示したＳ４６、Ｓ４８及びＳ５０等に例示するように、他の装置から受信した検索要求を上位又は下位の装置に転送する機能を有しており、この機能は検索制御手段の一例である。

以上、本発明の実施形態について説明したが、以上に例示した実施形態はあくまで例示的なものにすぎない。

以上の実施形態では、ＭＤＳが持つメタデータ内の項目（又は項目のグループ）のリンク情報（例えば図６参照）は、当該ＭＤＳの下位装置における当該項目（又は項目のグループ）の項目内容を指すものであり、その項目内容はリンク情報である場合もあった。これに対して、別の例として、ＭＤＳが持つメタデータのリンク情報は、項目ごと又はグループごとではなく、メタデータ全体を単位とするものであってもよい。この場合のリンク情報は、当該メタデータを記憶しているその下位装置を特定する情報（例えばアドレス情報）と、そのメタデータの識別情報として機能するＤＩＤとを含む。

また更に別の例として、ＭＤＳが持つメタデータの項目又はグループについてリンク情報は、そのメタデータの下位装置（すなわちツリー状の階層構造における子の装置）内の情報を指す代わりに、階層構造におけるそのＭＤＳの子孫の装置群のいずれかに記憶されているその項目又はグループの実体データを指すものであってもよい。例えば、ＭＤＳが持つあるメタデータのリンク情報は、そのＭＤＳの子孫である、そのメタデータの全ての項目の実体データを持っている処理装置１１０内のメタデータ（又はそのメタデータ内の個々の項目の実体データ）を指すものであってもよい。

また、上記実施形態では、各レベルのＭＤＳがリンク情報を記憶していたが、リンク情報は、本実施形態のシステムの外部の装置に記憶されていてもよい。外部の装置は、メタデータの識別情報として機能するＤＩＤに対応付けて、そのメタデータの実体データを特定するリンク情報を記憶している。このリンク情報は、例えば、いずれかの処理装置１１０内にあるそのメタデータを特定する情報（例えばＵＲＬ）であってもよい。あるいは、外部の装置は、ＤＩＤに対応付けて、メタデータの項目ごとに、その項目の実体データを特定するリンク情報を記憶していてもよい。各レベルのＭＤＳ又は処理装置１１０は、検索要求の検索条件に示されるＤＩＤに対応するメタデータを記憶していない場合は、その外部の装置からそのＤＩＤに対応するリンク情報を取得する。すなわち、ＭＤＳは、外部の装置からリンク情報を取得する取得手段を有する。そして、そのリンク情報を用いてそのＤＩＤに対応するメタデータの実体データを取得し、取得した実体データを、直接、又はその検索要求の転送の経路を逆向きに経由して、要求元のユーザの閲覧端末１０４に提供する。

以上に例示した作成端末１０２、閲覧端末１０４、処理装置１１０，１１０Ｓ及び１１０Ｒ、ローカルユーザＩＤサーバ１５２、ローカルＤＩＤサーバ１５４、ローカルメタデータサーバ１５６、１５６ａ及び１５６ｂ、ユーザＩＤサーバ２１０、ＤＩＤサーバ２２０、メタデータサーバ２３０、２３０ａ、２３０ｂ、処理装置管理サーバ２４０等の各装置は、コンピュータに上述のそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）及びリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、フラッシュメモリやＳＳＤ（ソリッドステートドライブ）、ＨＤＤ（ハードディスクドライブ）や等の固定記憶装置を制御するコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容が記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

１００ ローカルシステム、１０２ 作成端末、１０４ 閲覧端末、１０８ ローカルネットワーク、１１０ 処理装置、１３０ 認証デバイス、１５０ 組織内管理システム、１５２ ローカルユーザＩＤサーバ、１５４ ローカルＤＩＤサーバ、１５６，１５６ａ，１５６ｂ ローカルメタデータサーバ、２００ 管理システム、２１０ ユーザＩＤサーバ、２２０ ＤＩＤサーバ、２３０，２３０ａ，２３０ｂ メタデータサーバ（ＭＤＳ）、２４０ 処理装置管理サーバ、３００ 広域ネットワーク。

Claims (8)

1. 階層構造をなす複数の装置を含み、
   前記複数の装置のうち、ある階層に位置する少なくとも一以上の装置は、
   ドキュメントについての複数の項目からなるメタデータについて実体データ又はリンク情報を記憶する記憶手段、を備え、
   前記リンク情報は、前記階層構造上の下位又は上位の装置に記憶されている前記実体データの所在を表す情報であることを特徴とする
   データ管理システム。
2. 前記階層構造上の特定階層以上の各階層に位置する前記装置の前記記憶手段に前記実体データが記憶される前記項目の数は、当該装置が位置する階層が上位であるほど少ない、ことを特徴とする請求項１に記載のデータ管理システム。
3. 同一のドキュメントのメタデータの一部又は全部の項目の実体データを前記記憶手段に記憶している前記階層構造上の各階層の前記装置は、前記階層構造における当該装置の位置する階層が上位になるほど、前記記憶手段に前記メタデータのうち前記実体データを記憶する項目が少ない、ことを特徴とする請求項１に記載のデータ管理システム。
4. 前記複数の装置のうち前記階層構造の最下階層及び最上階層を除く各階層に位置する装置は、
   前記下位の装置から前記記憶対象の項目の実体データを受信する受信手段と、
   受信した前記記憶対象の項目の実体データのうちの所定の一部の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、
   前記受信手段が受信した前記記憶対象の項目の実体データを、前記リンク情報と対応付けて前記記憶手段に格納する制御を行う格納制御手段と、
   を更に含む請求項２又は３に記載のデータ管理システム。
5. 前記格納制御手段は、前記受信手段が前記記憶対象の項目の実体データの受信の際に得た前記下位の装置の情報から前記リンク情報を生成し、生成したリンク情報と、前記受信手段が受信した前記記憶対象の項目の実体データと、を前記記憶手段に格納する、ことを特徴とする請求項４に記載のデータ管理システム。
6. 前記階層構造上の前記最下階層に位置する装置は、
   当該装置が前記ドキュメントについて実行した処理に基づいて前記ドキュメントの前記メタデータを生成する手段と、
   生成した前記メタデータのうちの所定の一部の項目の実体データを、当該装置に対応する前記階層構造上の上位の装置に送信する手段と、
   を更に含む請求項１〜５のいずれか１項に記載のデータ管理システム。
7. 前記複数の装置の各々は、
   前記メタデータについての検索要求を受信する手段と、
   前記検索要求を満たす前記メタデータを検索するための制御を行う検索制御手段であって、当該装置に対応する前記階層構造上の下位又は上位のうちの少なくとも一方の装置に対して前記検索要求を転送する機能を持つ検索制御手段と、
   を更に含む請求項１〜６のいずれか１項に記載のデータ管理システム。
8. 同一のメタデータの一部又は全部の項目の実体データを前記記憶手段に記憶している前記階層構造上の各階層の前記装置は、当該メタデータの識別情報を前記記憶手段に記憶しており、
   前記検索制御手段は、前記検索要求が特定の識別情報を持つ前記メタデータを求めるものである場合において、当該識別情報が前記記憶手段に記憶されていない場合には、当該装置に対応する前記階層構造上の上位の装置に前記検索要求を転送し、当該識別情報が前記記憶手段に記憶されている場合には、当該装置に対応する前記階層構造上の上位の装置には前記検索要求を転送しない、
   請求項７に記載のデータ管理システム。