JP2007299063A - 情報処理装置、情報処理方法 - Google Patents

Abstract

【課題】 複数の装置において同一の体系でデータを管理すると共に、競合回避のためのロックを少なくするための技術を提供すること。
【解決手段】 フォルダ関係保持部３０５は、階層的に配置されたファイル及び／又はフォルダにおいて、親と子のみの関係を管理する。フォルダ関係保持部３０５が管理しているファイル及び／又はフォルダのうち操作対象をロックした状態で操作する。そして、操作結果を、フォルダ関係保持部３０５が管理している情報と同じものを管理している装置に反映させるべく、指示されたタイミングでもってこの装置に通知する。
【選択図】 図３

Description

本発明は、ファイル及び／又はフォルダの管理技術に関するものである。

近年、ネットワークで接続される複数の装置が連携して、仮想的に単一の体系でデータを管理する分散データ管理システムが実現されている。

例えば、各装置のローカルファイルシステムとは別に、全装置を統合した体系である仮想分散ファイルシステムを提供することが行なわれている（特許文献１を参照）。この種のシステムでは、ローカルファイルシステム上で実際にデータを保存するパスと、仮想分散ファイルシステム上でのパスとの対応データを持つ。クライアントからは、仮想分散ファイルシステム上でのパスを用いてアクセスするので、ローカルファイルシステムを隠蔽し、複数台の装置を単一化した仮想分散ファイルシステムを提供している。

ここで、仮想的な単一体系は、ローカルファイルシステムで用いられるのと同じフォルダのツリー構造である。体系としては、まずルートフォルダがある。ルートフォルダの下に、サブフォルダとコンテンツを保存する。サブフォルダについても、同様にそのサブフォルダとコンテンツを保存する。このようにして、全体としてツリー構造でフォルダ群が構成され、コンテンツはいずれか一つのフォルダに保存される。なお、サブフォルダやコンテンツを保存しているフォルダを親フォルダと呼ぶ。

仮想分散ファイルシステムは複数の装置から操作可能なため、競合が発生するような操作を複数の装置で並行して実行されることがある。操作後に実行結果を他の装置に共有する際に、競合する操作であった場合には、競合を解消する必要が生じる。これは複雑な処理になるため、フォルダやコンテンツをロックすることで、競合が生じるような操作を並行して実行できないようにする方法が取られることが多い。例えば、あるフォルダ以下を削除する操作を行なう場合には、操作する装置でこのフォルダ以下の全フォルダとコンテンツをロックする。それらが全てロックできた後に、各フォルダとコンテンツを削除する。ロックされているフォルダやコンテンツは、他の装置では変更できないので、競合する操作が行なわれることはない。
特開２００１−０５１８９０号公報

しかしながら、従来の分散データ管理システムでは、フォルダやコンテンツが、ツリー構造上のいずれかの位置で保存されなければならないため、ツリー構造が変わるような変更操作を行なう際には、ロックしなければならないフォルダが増えるという問題があった。そのため、他の装置で既にロックされていて変更処理ができないフォルダが増え、並行して実行できる操作が限られることになっていた。特に、装置がネットワークから切り離されオフライン状態で利用される場合には、ロックしている期間が長期に渡るため、この問題がより顕著になる。

例えば、ある装置で特定のフォルダを削除する可能性がある場合、このフォルダ以下をロックしておく。この場合、この装置とオフラインになっている別の装置では、このフォルダ以下の任意のフォルダやコンテンツを変更できなくなる。

本発明は以上の問題に鑑みてなされたものであり、複数の装置において同一の体系でデータを管理すると共に、競合回避のためのロックを少なくするための技術を提供することを目的とする。

本発明の目的を達成するために、例えば、本発明の情報処理装置は以下の構成を備える。

即ち、情報処理装置であって、
前記情報処理装置内のそれぞれのファイル若しくはフォルダのメタデータを、ネットワークで構成された複数の情報処理装置と共有可能に管理する管理手段と、
前記情報処理装置内の第１のフォルダと第２のフォルダとの関係を親子階層として登録する登録手段と、
オフラインで操作した前記ファイルまたはフォルダの操作結果を指示されたタイミングで前記複数の情報処理装置に反映させる反映手段とを備え、
前記反映を行うにあたり、前記登録手段により前記第２のフォルダと関係付けられていた親階層の前記第１のフォルダがオフライン中に削除されていた場合には、第２のフォルダに親フォルダを持たせない登録を行うことを特徴とする。

本発明の目的を達成するために、例えば、本発明の情報処理方法は以下の構成を備える。

即ち、情報処理装置が行う情報処理方法であって、
前記情報処理装置内のそれぞれのファイル若しくはフォルダのメタデータを、ネットワークで構成された複数の情報処理装置と共有可能に管理する管理工程と、
前記情報処理装置内の第１のフォルダと第２のフォルダとの関係を親子階層として登録する登録工程と、
オフラインで操作した前記ファイルまたはフォルダの操作結果を指示されたタイミングで前記複数の情報処理装置に反映させる反映工程とを備え、
前記反映を行うにあたり、前記登録工程で前記第２のフォルダと関係付けられていた親階層の前記第１のフォルダがオフライン中に削除されていた場合には、第２のフォルダに親フォルダを持たせない登録を行うことを特徴とする。

本発明の構成によれば、各装置において同一のフォルダ体系でデータを管理できると共に、競合処理を防ぐために必要なロックを減らし、並行して実行可能な操作を増やすことができる。

以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。

［第１の実施形態］
図１は、本実施形態に係るシステム（分散データ管理システム）の基本的な構成を示すブロック図である。

同図において１０１，１１１はそれぞれシステムを構成するコンピュータであり、同図に示す如く、それぞれのコンピュータは同じ機能構成を有するものであり、互いにネットワーク１２１を介してデータ通信が可能な構成を有する。

以下では、コンピュータ１０１の機能構成について説明するが、アプリケーション１０５とアプリケーション１１５，分散データ管理モジュール１０４と分散データ管理モジュール１１４、ＲＤＢＭＳ（リレーショナルデータベースマネージメントシステム）１０３とＲＤＢＭＳ１１３、ファイルシステム１０２とファイルシステム１１２、は同じ機能を有するものであるので、以下の説明はそのままコンピュータ１１１について同様に適用することができる。

ファイルシステム１０２は、パスを用いてファイルの作成、変更、取得、削除を管理する。こうしたファイルシステムは、コンピュータ装置では一般的に利用されるものであるので、如何なるファイルの管理形態を用いても良い。例えば、ＦＡＴ、ＮＴＦＳ（Ｗｉｎｄｏｗｓ（登録商標））、ＵＦＳ（Ｕｎｉｘ（登録商標））等を用いることができる。

ＲＤＢＭＳ１０３は、リレーショナルモデルに従って、表形式のデータの登録、変更、取得、削除を管理する。ＲＤＢＭＳの形態は問わない。また、ＲＤＢＭＳについても、コンピュータ装置では一般的に利用されるものであるので、これに関する説明は省略する。

分散データ管理モジュール１０４は、本実施形態における主要部分であり、その具体的な動作などについては後述する。

アプリケーション１０５は、分散データ管理モジュール１０４を用いてデータの管理を行うものであれば良く、アプリケーション１０５の種別については特に限定するものではない。アプリケーション１０５がデータの登録や取得を行う場合には、このアプリケーション１０５を実行しているコンピュータ（この場合コンピュータ１０１）で動作する分散データ管理モジュール（この場合分散データ管理モジュール１０４）を利用する。

以下では、ファイルシステム１０２、ＲＤＢＭＳ１０３、分散データ管理モジュール１０４、アプリケーション１０５のそれぞれはソフトウェアの形態でもって実装するが、部分的にハードウェアを用いて構築しても良い。

また以下の説明は、各ソフトウェアの機能が同等であれば、異なるソフトウェア構成が適用可能である点を妨げるものではない。特に、アプリケーションは、コンピュータごとに異なる場合が多い。

また、以下の説明では、分散データ管理モジュール１０４と分散データ管理モジュール１１４とが通信を行うことで提携し、分散データ管理システムを構成する。

また、以下の説明では、２台のコンピュータ１０１、１１１（即ち、２つの分散データ管理モジュール１０４，１１４）で分散データ管理システムを構成する場合について説明するが、３台以上のコンピュータをネットワーク１２１を介して接続することで分散データ管理システムを構成しても良く、その場合においても、以下の説明におけるコンピュータの動作を個々のコンピュータに適用すればよい。

図２は、上記コンピュータ１０１、１１１に適用可能な（換言すると分散データ管理システムを構成するコンピュータに適用可能な）コンピュータのハードウェア構成を示すブロック図である。

２０１はＣＰＵで、ＲＡＭ２０３やＲＯＭ２０２に格納されているプログラムやデータを用いて本コンピュータ全体の制御を行うと共に、本コンピュータを適用した装置（コンピュータ１０１、１１１）が行う後述の各処理を実行する。

２０２はＲＯＭで、本コンピュータの設定データやブートプログラムなどを格納する。

２０３はＲＡＭで、ハードディスクドライブ２０４からロードされたプログラムやデータ、ネットワークインターフェース２０６を介して外部から受信したプログラムやデータを一時的に記憶する為のエリアを有する。また、ＣＰＵ２０１が各処理を実行する際に用いるワークエリアも有する。即ち、ＲＡＭ２０３は各種のエリアを適宜提供することができる。

２０４はハードディスクドライブで、ＯＳ（オペレーティングシステム）や、本コンピュータを適用した装置（コンピュータ１０１、１１１）が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータが保存されている。具体的には、本コンピュータをコンピュータ１０１に適用した場合、ファイルシステム１０２やアプリケーション１０５、分散データ管理モジュール１０４、ＲＤＢＭＳ１０３に相当するソフトウェアプログラムや、分散データ管理モジュール１０４、ファイルシステム１０２、ＲＤＢＭＳ１０３が管理する後述の各種のデータ、が保存されている。

２０５は入出力インターフェースであり、キーボード２０７やマウス２０８、表示部２０９をバス２１０に接続すると共に、これらの制御を行うためのインターフェースとして機能するものである。キーボード２０７やマウス２０８は、本コンピュータの操作者が操作することで、各種の指示をＣＰＵ２０１に入力することができるものであり、同様の目的を達成できるものであればその他の機器を用いても良い。

表示部２０９は、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ２０１による処理結果を画像や文字などでもって表示することができる。

２０６はネットワークインターフェースで、本コンピュータをネットワーク１２１に接続し、このネットワーク１２１を介して外部とのデータ通信を行うためのインターフェースとして機能する。例えば、本コンピュータをコンピュータ１０１に適用した場合、ネットワークインターフェース２０６は、ネットワーク１２１を介してコンピュータ１１１とのデータ通信を行うために使用される。

２１０は上述の各部を繋ぐバスである。

なお、以下の説明では、図１に示した各モジュール（アプリケーション１０５、１１５、分散データ管理モジュール１０４、１１４、ＲＤＢＭＳ１０３、１１３、ファイルシステム１０２、１１２）を、動作を行う主体として説明する。しかし、実際には各モジュールに対応するプログラムをＣＰＵ２０１が実行することで、対応するモジュールが行うとして説明する各処理が実行される。また、「保持部」として動作するモジュールは、ＲＡＭ２０３やハードディスクドライブ２０４に相当するものである。

また、以下説明する処理の過程でデータを一時的に記憶する場合、特に触れない限りはＲＡＭ２０３に格納するし、保存する場合にはハードディスクドライブ２０４に対して行うものとする。また、データの読み出しについては、特に触れない限りは、ハードディスクドライブ２０４から読み出すものとする。

図３は、分散データ管理モジュール１０４の機能構成を示すブロック図である。分散データ管理モジュール１０４と分散データ管理モジュール１１４とは上述の通り、異なるコンピュータにインストールはされているものの、基本的には同じものであるので、同図を用いた説明は、分散データ管理モジュール１１４についても同様に適用される。

同図において３０１はデータ識別子生成部で、本実施形態に係るシステム内に存在する各フォルダやファイルに対して固有の情報（データ識別子）を生成し、割り当てる。

ここで、例えば、コンピュータ１０１を初めてネットワーク１２１に接続する際、先ずコンピュータ１０１は、自身をネットワーク１２１に登録する処理を行うのであるが、その際、このコンピュータ１０１が有する分散データ管理モジュール１０４に対して、モジュールＩＤが割り当てられる。モジュールＩＤは、本実施形態に係るシステム内で固有のＩＤであり、固定長のデータである。

従って、データ識別子生成部３０１は、データ識別子を割り当てる対象（フォルダ若しくはファイル）が生成された順番を示す通番情報と、このモジュールＩＤとを組み合わせて、この対象に割り当てるデータ識別子を生成する。ここで、通番情報が示す番号についても固定長とするので、データ識別子もまた固定長のデータとなる。

例えば、分散データ管理モジュール１０４のモジュールＩＤが００１であり、コンピュータ１０１内で２０３番目に生成されたフォルダ（若しくはファイル）についてデータ識別子を生成する場合、通番情報が示す番号を５桁の固定長とすれば、データ識別子は、００１００２０３となる。

なお、データ識別子生成部３０１によるデータ識別子の生成方法については上記方法に限定するものではなく、様々な変形例が考えられる。例えば、コンピュータのネットワークアドレスや、データ識別子を生成しようとする日時を用いてデータ識別子を生成しても良いし、同一時刻内での通番を組み合わせて生成するようにしても良い。

図３に戻って、３０２は本体データ保持部で、様々なコンテンツのファイルを、ファイルシステム１０２を利用して保持する。コンテンツとしては、例えば、ＪＰＥＧデータやＭＰＥＧデータがある。本体データ保持部３０２はファイルを管理する場合、このファイルについてデータ識別子生成部３０１が生成したデータ識別子を用いて管理している。即ち、ファイルシステム１０２の既定フォルダ（例えば、／ｄａｔａ）の下に、データ識別子をファイル名としたファイルとして保持する。例えば、データ識別子が００１００２０３であるファイルは、ファイルシステム１０２上の／ｄａｔａ／００１００２０３として保存する。一方、本体データ保持部３０２が管理しているファイルを取得する場合には、このファイルのファイル名（即ち、このファイルのデータ識別子）を用いて、ファイルシステム１０２から読み出す。

なお、フォルダ下のファイルが増大するのを防ぐため、データ識別子を分割し、分割された識別子をフォルダ名としてサブフォルダを作成し、分割された残りの識別子をファイル名としてファイルを作成してもよい。上記の例で、識別子を４文字ずつ２分割すると、／ｄａｔａ／００１０／０２０３というファイルで保存される。あるいは、ファイルシステム１０２上の１ファイルに、複数のファイルデータを合わせて保持してもよい。この場合、ファイル上で各ファイルデータの位置を示すデータを別途保持する。

例えば、データ識別子が００１０００３１（サイズ１４０００バイト）と００１０００３２（サイズ１６０００バイト）である二つのデータを１ファイルにまとめる例を示す。以下の二つのファイルのそれぞれの内容は次のようになる。
・複数の実体を持つファイル（ファイル名 ／ｄａｔａ／００１０）
１バイトから１４０００バイト データ識別子００１０００３１の実体データ
１４００１バイトから１４３３６バイト パディング（全データが０ｘ００）
１４３３７バイトから３０３３６バイト データ識別子００１０００３２の実体データ
３０３３７バイトから３０７２０バイト パディング（全データが０ｘ００）
・位置データを保持するファイル（ファイル名 ／ｉｎｄｅｘ／００１０）
識別子＝００１０００３１ 始点＝１ 長さ＝１４０００
識別子＝００１０００３２ 始点＝１４３３７ 長さ＝１６０００
データを追加する時は、データ識別子の前半４文字に対応する実体ファイルに実体を追加し、位置データファイルに位置情報を追加する。

何れにしても、ファイルシステム１０２を利用して、データ識別子からファイルを保存、取得する方法については特に限定するものではない。

３０３は本体配置データ保持部で、各ファイルがどの分散データ管理モジュールによって管理されている（どのコンピュータ内に保持されている）のかを示すテーブル情報を保持している。このテーブル情報は、ＲＤＢＭＳ１０３を利用して保持、検索される。図６は、本体配置データ保持部３０３が保持するテーブル情報の構成例を示すブロック図である。

同図において領域６０１には、管理されているそれぞれのファイルのデータ識別子が登録されている。また、領域６０２には、対応するファイルを管理している分散データ管理モジュールのモジュールＩＤが登録されている。例えば、データ識別子が「００１００２３８」であるファイルは、モジュールＩＤが「００１」である分散データ管理モジュール１０４によって管理されている。なお、同図のテーブル情報に、データ識別子と、このデータ識別子を有するファイルを管理している分散データ管理モジュールのモジュールＩＤと、を登録する場合には、ＲＤＢＭＳ１０３を用いて行う。このようにして、データ識別子とモジュールＩＤとを対応付けて管理することで、データ識別子を領域６０１に対するキーとして検索すれば、このデータ識別子を有するファイルを管理している分散データ管理モジュールのモジュールＩＤを検索することができる。

図３に戻って、３０４はメタデータ保持部で、分散データ管理モジュール１０４が管理するフォルダ若しくはファイルのメタデータを保持する。メタデータとしては、例えば、ファイル名（フォルダ名）や作成日時等がある。また、ファイルが画像データである場合、このファイルのメタデータには、この画像データのサムネイルが含まれる場合もある。このようなメタデータは、ＲＤＢＭＳ１０３を利用して保持、検索される。図７は、メタデータ保持部３０４が保持するメタデータの構成例を示す図である。同図では、メタデータとして、ファイル名（フォルダ名）とその作成日時とを用いた場合について示している。

同図において、領域７０１には、管理されているそれぞれのファイル若しくはフォルダのデータ識別子が登録されている。領域７０２には、対応するデータ識別子がフォルダのものであるのか、若しくはファイルのものであるのかを示している。同図では、「Ｆ」はフォルダを示しており、「Ｃ」はファイルを示している。従って、例えば、データ識別子が「００１００１８５」であるものはファイルであり、データ識別子が「００１００２０３」であるものはファイルである、ということが、同図のテーブルを参照すれば分かる。

領域７０３には、対応するファイル若しくはフォルダの名称（ファイル名若しくはフォルダ名）が登録されている。領域７０４には、対応するファイル若しくはフォルダの作成日時が登録されている。

このようにして、データ識別子とメタデータとを関連付けて（セットにして）管理することで、データ識別子を領域７０１に対するキーとして検索すれば、このデータ識別子を有するファイル若しくはフォルダのメタデータを検索することができる。

なお、メタデータに含まれる情報の種類については特に限定するものではない。また、メタデータに含まれる情報の種類については、フォルダとファイルとで異ならせるようにしても良い。この場合、フォルダのメタデータとファイルのメタデータとは、異なるテーブルに登録する。

図３に戻って、３０５はフォルダ関係保持部で、管理しているそれぞれのファイルやフォルダの間の関係を示す関係情報（フォルダ関係データ）を保持する。フォルダ関係データとは、ファイルとこのファイルが保持されているフォルダとの関係、フォルダとサブフォルダとの関係を示すものである。例えば、ファイルがフォルダに保持されているということは、このフォルダを親、このファイルを子とすることに等価である。また例えば、サブフォルダがあるフォルダに保持されているということは、このフォルダを親、このサブフォルダを子とすることに等価である。フォルダ関係データは、ＲＤＢＭＳ１０３を利用して保持、検索する。図８は、フォルダ関係データの構成例を示すブロック図である。

同図において、領域８０１には、親としてのフォルダのデータ識別子が登録されている。領域８０２には、子としてのサブフォルダ若しくはファイルのデータ識別子が登録されている。従って、例えば同図の場合、データ識別子「００１００２０３」を有するファイル若しくはフォルダの親は、データ識別子「００１００１８５」を有するフォルダであることが分かるし、データ識別子「００１００２３８」を有するファイル若しくはフォルダの親は、データ識別子「００１００１８５」を有するフォルダであることが分かる。即ち、これらのことから、データ識別子「００１００１８５」を有するフォルダ内には、データ識別子「００１００２０３」を有するファイル若しくはフォルダと、データ識別子「００１００２３８」を有するファイル若しくはフォルダとが子として格納されていることがわかる。

このように、各フォルダやファイルは、それらが階層的に配置されたものであったとしても、親とその子のみの関係を管理している。

従って、あるフォルダ（キーフォルダ）に属するファイル若しくはフォルダ（ファイル若しくはフォルダをまとめて「要素」と呼称する）を取得する場合は、領域８０１に対してキーフォルダのデータ識別子をキーとした検索処理を行う。この検索により、キーフォルダのデータ識別子に対応する子のデータ識別子が領域８０２から検索されるので、後はこの検索した子のデータ識別子に対応するフォルダ若しくはファイルを取得すればよい。また、ある要素の親フォルダを取得する場合は、領域８０２に対してこの要素のデータ識別子をキーとした検索処理を行う。この検索により、この要素の親フォルダのデータ識別子が領域８０１から検索されるので、後はこの検索したデータ識別子に対応するフォルダ（親フォルダ）を取得すればよい。

図３に戻って、３０６は通信部で、ネットワークインタフェース２０６を利用して、他のコンピュータが有する分散データ管理モジュールとのデータ通信を行う。

３０７は共有処理部で、本体配置データ保持部３０３、メタデータ保持部３０４、フォルダ関係保持部３０５に保持されている各データ（共有データ）を、他のコンピュータが有する分散データ管理モジュールと共有するための処理を行う。

それぞれのコンピュータにおける分散データ管理モジュールは、同じ構成でもって同じ共有データを保持している。即ち、それぞれのコンピュータで、同じ共有データを共有している。従って、あるコンピュータ（変更元）の分散データ管理モジュールが管理する共有データについて追加や削除、変更が行われた場合、即ち、変更元の分散データ管理モジュールが管理する共有データが、その他のコンピュータの分散データ管理モジュールが管理する共有データと異なった場合、変更元における共有処理部３０７は、その変更が起こった旨をその他のコンピュータに通知する。これにより、その他のコンピュータの分散データ管理モジュールが管理する共有データにも、この変更が反映されることになる。通知を受けたコンピュータにおける共有処理部３０７は、この変更を自身が管理する共有データに反映させる。これにより、全てのコンピュータは同じ共有データを管理することになる。

例えば、モジュールＩＤが００１であるコンピュータで、データ識別子が００１００２０３である共有データ（ファイル、コンテンツと同じ）が削除されれば、モジュールＩＤが００１以外のコンピュータのメタデータ保持部・フォルダ関係保持部・本体配置データ保持部の情報もデータ識別子が００１００２０３の共有データが削除されたことが反映される。

なお、あるコンピュータがオフラインである場合には、このコンピュータがオンラインになった時点で自身が管理する共有データについて上記反映を行えばよい。

３０８は、コンテンツ登録部で、アプリケーション１０５からの要求に従って、ファイル（コンテンツ）の追加、変更、削除の何れかを行う。

ファイルを追加する場合には（ファイルの追加がキーボード２０７やマウス２０８によって指示された場合には）、アプリケーション１０５は、ファイル自体のデータとこのファイルのメタデータとをコンテンツ登録部３０８に与える。一部のメタデータは、この時に生成したり、ファイルを解析することで生成したりしても良い。アプリケーション１０５からファイル追加要求を受けるとコンテンツ登録部３０８は、データ識別子生成部３０１を利用して、追加するファイルのデータ識別子を生成する。

既存のファイルを変更する場合には（ファイルの変更がキーボード２０７やマウス２０８によって指示された場合には）、アプリケーション１０５は、変更対象のファイルのデータ識別子と共に、変更したファイル若しくはメタデータをコンテンツ登録部３０８に与える。

既存のファイルを削除する場合には（ファイルの削除がキーボード２０７やマウス２０８によって指示された場合には）、アプリケーション１０５は、削除対象のファイルのデータ識別子をコンテンツ登録部３０８に与える。

以上説明したように、コンテンツ登録部３０８は、上記各要求に従って、本体データ保持部３０２、本体配置データ保持部３０３、メタデータ保持部３０４が保持するデータの追加、変更、削除を行う。コンテンツ登録部３０８が行う処理の詳細については図１０を用いて後述する。

３０９はフォルダ登録部で、アプリケーション１０５から要求に従って、フォルダの追加、変更、削除の何れかを行う。

フォルダを追加する場合には（フォルダの追加がキーボード２０７やマウス２０８によって指示された場合には）、アプリケーション１０５は、フォルダのメタデータをフォルダ登録部３０９に与える。一部のメタデータは、この時に生成したり、フォルダを解析することで生成したりしても良い。アプリケーション１０５からフォルダ追加要求を受けるとフォルダ登録部３０９は、データ識別子生成部３０１を利用して、追加するフォルダのデータ識別子を生成する。

既存のフォルダを変更する場合には（フォルダの変更がキーボード２０７やマウス２０８によって指示された場合には）、アプリケーション１０５は、変更対象のフォルダのメタデータをフォルダ登録部３０９に与える。

既存のフォルダを削除する場合には（フォルダの削除がキーボード２０７やマウス２０８によって指示された場合には）、アプリケーション１０５は、削除対象のフォルダのデータ識別子をフォルダ登録部３０９に与える。

以上説明したように、フォルダ登録部３０９は、上記各要求に従って、メタデータ保持部３０４が保持するフォルダの追加、変更、削除を行なう。フォルダ登録部３０９が行う処理については後述する。

なお、フォルダ登録部３０９が行う処理は、フォルダ自体の追加、変更、削除であって、フォルダへのサブフォルダ登録やファイル登録ではない。これらは、次に説明するフォルダ関係の処理となる。

３１０はフォルダ関係登録部で、アプリケーション１０５からの要求に従って、フォルダ関係の追加、削除登録を行う。フォルダにファイルやサブフォルダを所属させる場合は、フォルダ関係の追加登録となる。また、フォルダに所属しているファイルやサブフォルダを所属させなくする場合は、フォルダ関係の削除登録となる。

フォルダ関係の登録処理は、所属させようとする親のフォルダのデータ識別子と、この親フォルダに所属させようとする要素（親フォルダに属するファイル若しくはサブフォルダ）のデータ識別子との組で構成されるレコードを、フォルダ関係保持部３０５に追加することで実現される。

一方、フォルダ関係の削除処理は、削除しようとする要素のデータ識別子と、この要素が属していた親フォルダのデータ識別子との組で構成されるレコードを、フォルダ関係保持部３０５から削除することで実現される。

このフォルダ関係登録処理を、上記ファイル登録処理やフォルダ登録処理から独立させたことで、ファイルやフォルダは必ずしも親フォルダを持たない。なお、本実施形態では、フォルダについては高々一つの親フォルダしか持つことができない。ファイルについては、複数の親フォルダを持つことができる。ただし、フォルダが複数の親フォルダを持てるようにしたり、ファイルが高々一つの親フォルダしか持てないようにしたりする形態でも構わない。

３１１は検索部で、アプリケーション１０５からの要求に従って、メタデータ保持部３０４に保持されているメタデータを利用して、ファイル若しくはフォルダを検索する処理を行う。この検索処理は、ＲＤＢＭＳ１０３の検索機能を用いて、メタデータ保持部３０４に保持されている図７のテーブルを構成する各領域に対する検索を行い、条件に合致するレコードを取得することで実現される。そして、取得されたレコードの領域７０１の値であるデータ識別子を検索結果リストとして返信する。例えば、名称に特定文字列を含むデータのデータ識別子を取得したり、作成日時が指定範囲にあるデータのデータ識別子を取得したりできる。また、複数の領域に対する条件の論理的組合せで検索を行なうこともできる。

例えば、前述の検索において、検索対象をファイルに絞り込んだり、フォルダに絞り込んだりすることも可能である。データ識別子のリストで検索結果を返信するだけでなく、メタデータの特定領域の組を要素とする結果リストで返信してもよい。また、結果リストを構成する際には、特定領域をキーとしてソートした順序で構成してもよい。

３１２はフォルダ探索部で、アプリケーション１０５からの要求に従って、メタデータ保持部３０４に保持されているメタデータと、フォルダ関係保持部３０５に保持されているフォルダ関係データとを用いて、フォルダ関係を辿ってフォルダ要素あるいは親フォルダとなるフォルダやファイルを探索する。フォルダ探索処理の詳細については後述する。

フォルダ構成が深い場合には、フォルダ探索を繰り返すことで、探索の起点となるフォルダから、フォルダ関係を辿って子フォルダやファイルを探索し、取得することができる。なお、探索の起点となるフォルダからフォルダ関係で結ばれていないフォルダやファイルも存在する。このようなフォルダやファイルについては、前述の検索部３１１を用いて探すことができる。

３１３はコンテンツ取得部で、本体データ保持部３０２に保持されているファイルと、メタデータ保持部３０４に保持されているメタデータとを取得する。フォルダを取得する場合には、本体配置データ保持部３０３に保持されている本体配置データを参照し、このフォルダが異なるコンピュータにおける分散データ管理モジュールによって管理されている場合には、通信部３０６を利用して、この分散データ管理モジュールからこのフォルダを取得する。コンテンツ取得処理の詳細は後述する。

次に、コンピュータ１０１が行う具体的な処理について説明する。図１０は、ファイルを扱う場合における処理のフローチャートである。なお、同図のフローチャートに示した各処理をＣＰＵ２０１に実行させるためのプログラムやデータ、処理対象のデータはハードディスクドライブ２０４に保存されており、ＣＰＵ２０１による制御に従って適宜ＲＡＭ２０３にロードされる。そしてＣＰＵ２０１がこのロードされたプログラムやデータを用いて処理を実行することで、コンピュータ１０１は以下説明する各処理を実行する。

同図のフローチャートに従った処理は、アプリケーション１０５が分散データ管理モジュール１０４に対して、ファイル登録要求を送信することで開始される。若しくは、他のコンピュータが有する分散データ管理モジュール（図１の場合、分散データ管理モジュール１１４）が、分散管理モジュール１０４に対してファイル登録要求を送信することでも開始される。

先ず、ステップＳ１００１では、分散データ管理モジュール１０４がアプリケーション１０５から受けた要求が、ファイルの追加要求であるのか否かをチェックする。このチェック処理では、受けた要求のヘッダにある登録要求種別データを参照する。他にも、リモートメソッド呼び出しを通信形態とすれば、呼び出しメソッドを変えることでこのチェック処理は可能である。例えば、ＷｅｂサービスやＣＯＲＢＡなど、あたかも同一プログラム中のメソッドを呼び出すのと同じように別の装置のプログラムを呼び出すことをリモートメソッド呼び出しと言う。このように、チェックする方法については特に限定するものではない。

そしてステップＳ１００１におけるチェックの結果、ファイル追加要求である場合には処理をステップＳ１００４に進め、ファイルの追加処理を実行する。ステップＳ１００４における処理の詳細については後述する。

一方、分散データ管理モジュール１０４がアプリケーション１０５から受けた要求がファイルの追加処理ではない場合には処理をステップＳ１００２に進め、この要求がファイルの削除要求であるのか否かをチェックする。このチェック処理は、上記ステップＳ１００１と同様にして行う。そしてステップＳ１００２におけるチェック処理の結果、ファイル削除処理である場合には処理をステップＳ１００５に進め、ファイルの削除処理を行う。ステップＳ１００５における処理の詳細については後述する。

一方、分散データ管理モジュール１０４がアプリケーション１０５から受けた要求がファイル削除要求ではない場合には処理をステップＳ１００３に進める。ステップＳ１００３では、ファイルの変更処理を行う。ステップＳ１００３における処理の詳細については図１１から図１３を用いて後述する。

図１１は、上記ステップＳ１００４におけるファイル追加処理の詳細を示すフローチャートである。

先ず、ステップＳ１１０１では、データ識別子生成部３０１を用いて、追加しようとするファイルに対するデータ識別子を生成する。そしてステップＳ１１０２では、ステップＳ１１０１で生成したデータ識別子をキーとして、追加しようとするファイルを本体データ保持部３０２に登録する。この登録については上述の通り、例えば、登録しようとするファイルを、ステップＳ１１０１で生成したデータ識別子をファイル名とするファイルとして登録する。

ステップＳ１１０３では、ステップＳ１１０１で生成したデータ識別子と、分散データ管理モジュール１０４のモジュールＩＤとをセットにして、図６に示すテーブルに登録する。即ち、データ識別子を領域６０１に登録すると共に、モジュールＩＤを領域６０２に登録する。

ステップＳ１１０４では、ステップＳ１１０１で生成したデータ識別子を図７に示すテーブルの領域７０１に登録し、領域７０２には登録しようとするものがファイルであることを示す「Ｃ」を登録し、領域７０３には登録しようとするファイルのファイル名を登録し、領域７０４には登録しようとするファイルの作成日時を登録する。なお、上述の通り、メタデータに含まれる情報については様々なものがある。

図１２は、上記ステップＳ１００５におけるファイル削除処理の詳細を示すフローチャートである。

先ず、ステップＳ１２０１では、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子を受けるので、本体配置データ保持部３０３が保持する図６に示したテーブルから、この受けたデータ識別子に対応するモジュールＩＤを取得する。

次にステップＳ１２０２では、ステップＳ１２０１で取得したモジュールＩＤと、分散データ管理モジュール１０４のモジュールＩＤとを比較し、それぞれが一致するか否かをチェックする。即ち、本ステップにおける処理は、アプリケーション１０５から削除対象として指示されたファイルが、分散データ管理モジュール１０４が管理するファイルであるのか否かをチェックしている。

このチェック処理の結果、一致していない場合には処理をステップＳ１２０７に進める。ステップＳ１２０７では、上記ステップＳ１２０１で取得したモジュールＩＤで特定される他の分散データ管理モジュール（実際にファイルを保持しているコンピュータの分散データ管理モジュール）に対して、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子と共に、このファイルの削除指示を転送する。フォルダ関係保持部・本体配置データ保持部・メタデータ保持部・本体データ保持部の情報が更新される。

一方、ステップＳ１２０２におけるチェック処理の結果、一致している場合には、処理をステップＳ１２０３に進める。ステップＳ１２０３では、フォルダ関係保持部３０５が保持する図８に示したテーブルにおいて、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子が登録されている領域８０２と、このデータ識別子と対応付けて領域８０１に登録されているデータ識別子とを削除する。例えば、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子が「００２００７４５」であり、このファイルが分散データ管理モジュール１０４が管理するものである場合には、図８のテーブルから、データ識別子「００２００７４５」とデータ識別子「００１００３３１」とを削除する。これは、データ識別子「００１００３３１」を有する親フォルダ内におけるファイルのうち、データ識別子「００２００７４５」を有するファイル（即ち削除指示されたファイル）を削除することに等価である。

次にステップＳ１２０４では、本体配置データ保持部３０３が保持する図６に示したテーブルから、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子が登録されている領域６０１と、このデータ識別子と対応付けて領域６０２に登録されているモジュールＩＤとを削除する。

次にステップＳ１２０５では、メタデータ保持部３０４が保持する図７に示したテーブルから、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子が登録されている領域７０１と、このデータ識別子と対応付けて領域７０２，７０３，７０４に登録されている各データとを削除する。

次にステップＳ１２０６では、本体データ保持部３０２から、アプリケーション１０５から削除対象として指示されたファイルのデータ識別子をファイル名とするファイルを削除する。

図１３は、上記ステップＳ１００３におけるファイル変更処理の詳細を示すフローチャートである。

先ずステップＳ１３０１では、アプリケーション１０５から受けた要求が、メタデータの変更要求であるのか否かをチェックする。このチェック処理についても上記ステップＳ１００１と同様にして行う。

このチェック処理の結果、アプリケーション１０５から受けた要求が、メタデータの変更要求である場合には、処理をステップＳ１３０５に進める。ここで図１３のフローチャートに従った処理を行う場合には、変更しようとするファイルのデータ識別子、若しくは変更しようとするメタデータが付与されているファイルのデータ識別子がアプリケーション１０５から得られる。従って、ステップＳ１３０５では、メタデータ保持部３０４が保持する図７に示すテーブルにおいて、このデータ識別子とセットになっているデータのうち、変更指示されているデータを、変更指示に従って変更する。

一方、ステップＳ１３０１におけるチェック処理の結果、アプリケーション１０５から受けた要求が、メタデータの変更要求ではない場合には、処理をステップＳ１３０２に進める。

ステップＳ１３０２では、本体配置データ保持部３０３が保持する図６に示したテーブルから、アプリケーション１０５から受けたデータ識別子に対応するモジュールＩＤを取得する。

次にステップＳ１３０３では、ステップＳ１３０２で取得したモジュールＩＤと、分散データ管理モジュール１０４のモジュールＩＤとを比較し、それぞれが一致するか否かをチェックする。即ち、本ステップにおける処理は、アプリケーション１０５から変更要求されたファイルが、分散データ管理モジュール１０４が管理するファイルであるのか否かをチェックしている。

このチェック処理の結果、一致していない場合には処理をステップＳ１３０６に進める。ステップＳ１３０６では、上記ステップＳ１３０２で取得したモジュールＩＤで特定される他の分散データ管理モジュールに対して、アプリケーション１０５から変更要求されたファイルのデータ識別子と共に、このファイルの変更指示を転送する。

一方、ステップＳ１３０３におけるチェック処理の結果、一致している場合には、処理をステップＳ１３０４に進める。ステップＳ１３０４では、本体データ保持部３０２が保持するファイルのうち、アプリケーション１０５から受けたデータ識別子をファイル名とするファイルについて、変更要求に応じた変更処理を行う。

次に、フォルダの追加、削除、変更について説明する。フォルダの追加、削除、変更の何れを行うのかについてもファイルの場合と同様、アプリケーション１０５から指示され、分散データ管理モジュール１０４が何れが指示されたのかを判断するのであるが、分散データ管理モジュール１０４によるこの判断処理については、基本的には図１０に示したフローチャートと同様である。以下では、アプリケーション１０５からフォルダの追加要求を受けた場合に分散データ管理モジュール１０４が行う処理、削除要求を受けた場合に分散データ管理モジュール１０４が行う処理について説明する。なお、アプリケーション１０５からフォルダの変更要求を受けた場合に分散データ管理モジュール１０４が行う処理については、フォルダに対応するメタデータを変更するだけなので説明を省略する。

図１４は、分散データ管理モジュール１０４によるフォルダ追加処理のフローチャートである。なお、同図のフローチャートに従った処理は、アプリケーション１０５が分散データ管理モジュール１０４に対して、フォルダ追加要求を送信することで開始されるものである。

先ず、ステップＳ１４０１では、データ識別子生成部３０１を用いて、追加するフォルダに対するデータ識別子を生成する。そしてステップＳ１４０２では、メタデータ保持部３０４が保持している図７に示すテーブルにおいて、領域７０１にはステップＳ１４０１で生成したデータ識別子を追加登録し、領域７０２には「Ｆ」を追加登録し、領域７０３には、追加登録するフォルダのフォルダ名を追加登録し、領域７０４には、追加登録するフォルダの作成日時を追加登録する。

図１５は、分散データ管理モジュール１０４によるフォルダ削除処理のフローチャートである。

ステップＳ１５０１では、フォルダ関係保持部３０５が保持する図８に示したテーブルにおいて、アプリケーション１０５から削除指示されたフォルダのデータ識別子が登録された領域８０１と、この領域８０１に対応する領域８０２を削除する。若しくはアプリケーション１０５から削除指示されたフォルダのデータ識別子が登録された領域８０２のみを削除する。

これにより、削除指示されたフォルダの親フォルダ、子フォルダ、フォルダ要素であるファイルとのフォルダ関係が削除される。このフォルダの子フォルダやフォルダ要素であったファイルについては、この削除により親フォルダがなくなる。しかし、本実施形態では、親フォルダがなくてもよいので問題はない。

そしてステップＳ１５０２では、メタデータ保持部３０４が保持している図７に示すテーブルにおいて、削除指示されたフォルダのデータ識別子が登録されている領域７０１、及びこのデータ識別子に対応するメタデータが登録されている領域７０２から７０４を削除する。

図１６は、フォルダ探索処理のフローチャートである。フォルダ探索処理は、アプリケーション１０５が分散データ管理モジュール１０４に対して、フォルダ探索要求を送信することで開始される。

ステップＳ１６０１では、フォルダ関係保持部３０５が保持する図８に示したテーブルにおいて、フォルダ探索要求で指定された起点フォルダのデータ識別子を登録している領域８０１を特定し、対応する領域８０２に登録されているデータ識別子を取得し、リストに登録する。このリストは、初期状態では空の状態であり、フォルダ探索要求で指定された起点フォルダのデータ識別子を登録している領域８０１を特定する毎に、対応する領域８０２に登録されているデータ識別子を登録する。

そしてこの作成したリストが空になるまで、以下説明するステップＳ１６０４，Ｓ１６０５における処理を行う。

先ずステップＳ１６０３では、リストに登録しているデータ識別子を１つ読み出し、読み出したデータ識別子をリストから削除する。そして図７に示したテーブルを参照し、この読み出したデータ識別子が登録されている領域７０１を検索し、検索した領域７０１に対応するメタデータを取得する。例えば、読み出したデータ識別子が「００１００２０３」である場合には、メタデータ｛「Ｃ」、「○○◇◇」、「２００５年２月１５日１６：３２」｝を取得する。

そして、ステップＳ１６０４では、取得したメタデータのうち、領域７０３，７０４に登録されているデータを結果リストに登録する。例えば、読み出したデータ識別子が「００１００２０３」である場合には、「○○◇◇」、「２００５年２月１５日１６：３２」を結果リストに登録する。この結果リストは、初期状態では空の状態であり、ステップＳ１６０４における処理を行う毎に領域７０３，７０４に登録されているメタデータを登録する。

そして処理をステップＳ１６０５を介してステップＳ１６０２に戻す。そしてリストが空である場合には本処理を終了するのであるが、空ではない場合には、処理ステップＳ１６０３に進め、未だリスト中に残っているデータ識別子のうち１つを読み出して以降の処理を行う。

そして以上のようにして作成した結果リストを、要求元に送信する。

図１７は、ファイルの取得処理のフローチャートである。ファイルの取得処理は、アプリケーション１０５が分散データ管理モジュール１０４に対して、ファイル取得要求を送信することで開始される。

先ずステップＳ１７０１では、ファイル取得要求でメタデータも要求されているか否かをチェックする。このチェックは、上記ステップＳ１００１におけるものと同様にして行う。このチェックの結果、要求されていない場合には処理をステップＳ１７０３に進め、要求されている場合には処理をステップＳ１７０２に進める。

ステップＳ１７０２では、図７に示したテーブルにおいて、ファイル取得要求によって指定されたデータ識別子とセットにして登録されているメタデータを取得する。例えば、データ識別子が「００１００２０３」である場合には、「○○◇◇」、「２００５年２月１５日１６：３２」をメタデータとして取得する。そして取得したメタデータを順次結果データに追加登録する。そして処理をステップＳ１７０３に進める。

ステップＳ１７０３では、本体配置データ保持部３０３が保持する図６に示したテーブルから、ファイル取得要求によって指定されたデータ識別子に対応するモジュールＩＤを取得する。

次にステップＳ１７０４では、ステップＳ１７０３で取得したモジュールＩＤと、分散データ管理モジュール１０４のモジュールＩＤとを比較し、それぞれが一致するか否かをチェックする。即ち、本ステップにおける処理は、ファイル取得要求で指定されたデータ識別子が示すファイルが、分散データ管理モジュール１０４が管理するファイルであるのか否かをチェックしている。

このチェック処理の結果、一致していない場合には処理をステップＳ１７０６に進める。ステップＳ１７０６では、上記ステップＳ１７０３で取得したモジュールＩＤで特定される他の分散データ管理モジュールに対して、ファイル取得要求で指定されたデータ識別子と共に、このファイルの取得指示を転送する。

一方、ステップＳ１７０４におけるチェック処理の結果、一致している場合には、処理をステップＳ１７０５に進める。ステップＳ１７０５では、本体データ保持部３０２から、ファイル取得要求で指定されたデータ識別子をファイル名とするファイルを取得し、結果データに追加登録する。

このようにして作成された結果データを、本処理の結果として要求元に返信する。

以上の処理によって、本実施形態では、それぞれのコンピュータ１０１、１１１内には、図９に示す如く、メタデータ９０１（９１１），フォルダ関係データ９０２（９１２）、本体配置データ９０３（９１３）、そして本体データ９０４（９１４）が登録されることになる。なお、コンピュータ１０１側に登録されているメタデータ９０１、フォルダ関係データ９０２、本体配置データ９０３と、コンピュータ１１１側に登録されているメタデータ９１１、フォルダ関係データ９１２、本体配置データ９１３とはそれぞれ、分散データ管理モジュール１０４の共有処理部３０７、分散データ管理モジュール１１４の共有処理部３０７によって同一に保たれる。

なお、本体データ９０４と本体データ９１４とは互いに同じものである必要はない。

各コンピュータで同一のメタデータ、フォルダ関係データ、本体配置データを保持している為、それぞれのコンピュータにおける分散管理モジュールでは、論理的に同一のフォルダ体系として各データが管理されていることになる。従って、どの分散管理モジュールからも、フォルダ登録、コンテンツ登録、フォルダ関係登録、フォルダ探索、検索、コンテンツ取得を同等に行うことができる。すなわち、自コンピュータに本体ファイルはなくとも他コンピュータにある本体ファイルを操作でき、その結果がシステム内のコンピュータに反映される。

図４は、コンピュータが管理するフォルダ（ファイル）の階層構造の一例を示す図である。４０１は、分散データ管理モジュール１０４が管理する階層構造を示しており、４０２は、分散データ管理モジュール１１４が管理する階層構造を示している。フォルダやファイル間の線はフォルダ関係を示している。

４１１〜４１７、４５１〜４５７は何れもフォルダを示しており、同図に示す如く、分散データ管理モジュール１０４と分散データ管理モジュール１１４とで同じフォルダ構造（フォルダの階層構造）でもってフォルダを管理している。従って、例えば、フォルダ４１１とフォルダ４５１とは同じフォルダである。従って、フォルダ４１１に対しての変更は、共有処理部３０７により、フォルダ４５１に対しても反映される。

また、４２１〜４２６、４６１〜４６６は何れもファイルを示している。例えば、ファイル４２１とファイル４６１とは同じファイルである。

ここで、ファイル４２１〜４２６のうちファイル４２４〜４２６については分散データ管理モジュール１０４側で管理されているものではなく、分散データ管理モジュール１１４側で管理されているものである。同様に、ファイル４６１〜４６６のうちファイル４６１〜４６３については分散データ管理モジュール１１４側で管理されているものではなく、分散データ管理モジュール１０４側で管理されているものである。また、フォルダ４１１、４１２、４１７とファイル４２２、４２５は親フォルダを持たない。これは、対応するフォルダ４５１、４５２、４５７とファイル４６２、４６５についても同様である。

また、コンピュータ１０１とコンピュータ１１１とが、ネットワーク１２１に接続されていない状態、いわゆるオフライン状態になった場合でも、オフラインになった時点でのフォルダ体系は、それぞれのコンピュータで同一である。またそれぞれのコンピュータは、ファイル取得等、ファイルを利用する処理を除いて、オフライン状態でもオンライン時における上記各処理（上記各フローチャートで示した処理）と同じ処理を行うことができる。

しかし、オフライン状態でフォルダ登録、コンテンツ登録、フォルダ関係登録を行なうと、オフライン状態である間、それぞれのコンピュータが管理するファイルやフォルダの階層構造やメタデータなどが変わってしまう。そこで、本実施形態では、コンピュータをネットワーク１２１に接続した際に、共有処理部３０７が、変更した点を他のコンピュータに通知する。このような通知処理を、ネットワーク１２１に接続しているそれぞれのコンピュータが行うことで、結果として、それぞれのコンピュータは同じ階層構造でもってファイルやフォルダを管理することができる。

ここで、従来の技術における問題点として上述したように、１つの記憶装置に保持されているデータを複数台のコンピュータが共有して操作する場合には、例えば、複数台のコンピュータが同一のファイルを変更しようとするケース等が生じ得る。このようなケースが発生すると、何れのコンピュータが優先的にデータ操作を行えるのかを決定しなくてはいけないという問題が生じる。そこで、競合する処理が発生しないように、操作に関係するファイルやフォルダをロックしなければ処理ができないようにする方法を取る。あるフォルダやファイルをロックをできるのは、システムを構成している全てのコンピュータのうち、１台のコンピュータの分散データ管理モジュールのみである。また、オフライン状態にある分散データ管理モジュールは新たにロックを取得することはできない。

ロックを実現する方法は様々であるが、ここでは、一つの分散データ管理モジュール（分散データ管理モジュール１０４）がロックサーバとなる形態を取る。即ち、分散データ管理モジュール１０４だけが、ロック管理部を備える。各分散データ管理モジュールは、ロック取得要求とロック解除要求を、分散データ管理モジュール１０４に送信する。

図１８は、ロック管理部が保持するロック管理データの構成例を示す図である。ロック管理データは、同じコンピュータ１０１内のＲＤＢＭＳ１０３で管理される。ロック管理データには、領域１８０１と領域１８０２とが設けられており、領域１８０１には、全てのコンピュータが保持するフォルダやファイルのデータ識別子が登録されている。また、それぞれのデータ識別子に対応するファイル若しくはフォルダのうち、ロックが取得されたファイル若しくはフォルダについては、ロックを取得した分散データ管理モジュールのモジュールＩＤが領域１８０２に登録されている。例えば、同図の場合、データ識別子「００１００２０３」のフォルダ（若しくはファイル）に対するロックは、モジュールＩＤが「００１」の分散データ管理モジュールによって取得されているし、データ識別子「００２００７４５」のフォルダ（若しくはファイル）に対するロックは、モジュールＩＤが「００２」の分散データ管理モジュールによって取得されている。なお、何も登録されていない領域１８０２に対応する領域１８０１内に登録されているデータ識別子（同図の場合、「００１００２３８」）のファイル（若しくはフォルダ）については、何れの分散データ管理モジュールもロックは取得していないことを示している。

図１９は、ロックサーバとしての分散データ管理モジュール１０４がロックを取得する処理のフローチャートである。同図に示したフローチャートは、ロック取得要求が発生すると開始される。

他のコンピュータにおける分散データ管理モジュールからロック取得要求を受けた場合、ステップＳ１９０１では、この要求でロック対象として指定されたファイル若しくはフォルダのロックが、他のコンピュータによって現在取得されているのか否かをチェックする。このチェック処理については上述の通りである。

即ち、図１８に示す管理データを参照し、ロック取得要求で指定されたロック対象のファイル若しくはフォルダのデータ識別子に対応する領域１８０２内に何も登録されていないか否かをチェックする。このチェックの結果、対応する領域１８０２内にモジュールＩＤが登録されている場合には、現在他の分散データ管理モジュールによってロックが取得されていると判断し、モジュールＩＤが登録されていない場合には、現在他の分散データ管理モジュールによってロックが取得されていないと判断する。

この判断の結果、ロックが既に取得されていると判断した場合には処理をステップＳ１９０４に進める。ステップＳ１９０４では、ロックの取得要求元に対してロック失敗の旨を通知する。

一方、ロックが既に取得されていないのであれば、処理をステップＳ１９０２に進め、ロック取得要求で指定されたロック対象のファイル若しくはフォルダに対するロックを取得する。本ステップにおける処理は、図１８に示す管理データにおいて、ロック取得要求で指定されたロック対象のファイル若しくはフォルダのデータ識別子に対応する領域１８０２内に、ロック取得要求元の分散データ管理モジュールのモジュールＩＤを登録することでなされるものである。

そしてステップＳ１９０３では、ロック取得要求元に対して、ロック取得の成功を通知する。

ここで、他の分散データ管理モジュールからロック解除の要求を受けた場合には、解除要求で指定されたロック解除対象のファイル若しくはフォルダのデータ識別子に対応する領域１８０２内を空にする。

各分散データ管理モジュールは、ロックを取得したファイル若しくはフォルダのデータ識別子を保持しておく。そして、コンテンツ登録、フォルダ登録、フォルダ関係登録処理にあたっては、必要なファイル若しくはフォルダのロックが取得されているかを確認した上で処理を進める。この確認は、ファイル若しくはフォルダのデータ識別子が、ロック取得済みのデータ識別子に含まれるかを調べることで行なわれる。そして、ロックを取得したファイル若しくはフォルダについてのみ、様々な操作を許可する。なお、必要なファイル若しくはフォルダのロックが一つでも取得されていない場合は処理を中止する。

各処理でロックが必要なファイル若しくはフォルダは以下の通りである。

ファイル作成処理 ：なし
ファイル削除処理 ：削除対象のコンテンツ
ファイル変更処理 ：変更対象のコンテンツ
フォルダ作成処理 ：なし
フォルダ削除処理 ：削除対象のフォルダ
フォルダ変更処理 ：変更対象のフォルダ
フォルダ関係作成処理：フォルダ関係により親フォルダ及び子フォルダになるフォルダ、若しくはフォルダ要素になるファイル
フォルダ関係削除処理：なし
コンピュータがオンライン状態にある場合は、各処理に必要なロックを、処理実行の直前に行い、処理実行直後にロックを解除すればよい。コンピュータをオフラインにする場合には、オフライン状態になる前に、必要なファイルやフォルダのロックを取得しておく。ロックが取得できていないと対象のファイル若しくはフォルダに対してオフライン状態で各処理の実行が許可されない。そして、再度、このコンピュータをオンライン状態にした時にそれぞれのロックを解除する。どのファイルやフォルダをロックしておくかはアプリケーションが定める。例えば、特定フォルダを必ずロックするとか、利用者に問い合わせるといった方法をアプリケーションが取ることが考えられる。

以上、本実施形態では、前述したように、各コンピュータ装置で同一のメタデータ、フォルダ関係データ、本体配置データが保持されているため、どの分散データ管理モジュールからも、フォルダ登録、コンテンツ登録、フォルダ関係登録、フォルダ探索、検索、コンテンツ取得が同等にできるというメリットがあった。さらに、ファイル登録あるいはフォルダ登録と、フォルダ関係登録とを独立にしたため、異なる分散データ管理モジュールからの競合処理を防ぐために必要なロックを軽減できるという効果がある。

例えば、ファイルの追加を行なう際には、いずれのフォルダもロックする必要がない。そして、ファイルの追加を行っている間に、他のコンピュータでは、全フォルダに関する処理を実行することができる。また、フォルダの削除などを行なう場合も、ロックする必要があるフォルダを軽減できる。図５は、本実施形態での操作を行なった場合のデータ変化の例を示す模式図である。

同図において５０１は、分散データ管理モジュール１０４が管理するファイルやフォルダの階層構造を示しており、５０２は、分散データ管理モジュール１１４が管理するファイルやフォルダの階層構造を示している。５１１〜５１５、５６１〜５６５は何れもフォルダを示しており、同図に示す如く、分散データ管理モジュール１０４と分散データ管理モジュール１１４とで同じフォルダ構造（フォルダの階層構造）でもってフォルダを管理している。従って、例えば、フォルダ５１１とフォルダ５６１とは同じフォルダである。各フォルダの横には、フォルダの名称を記載している。

また、５２１〜５２６、５７１〜５７６は何れもファイルを示している。例えば、ファイル５２１とファイル５７１とは同じファイルである。フォルダやコンテンツ間の線はフォルダ関係を示している。また、斜線で示しているフォルダは、ロックを取得しているフォルダを示す。

５３１は、分散データ管理モジュール１０４と分散データ管理モジュール１１４とがオフライン状態になる前に、それぞれが必要なロックを取得した状態における階層構造を示している。分散データ管理モジュール１０４では、フォルダ５１２を削除し、フォルダ５１１とフォルダ５１３、５１４を変更するので、フォルダ５１１、５１２、５１３、５１４のロックを取得している。分散データ管理モジュール１１４では、フォルダ５６５に関係付けられているファイル５７５を削除するので、フォルダ５６５のロックを取得している。

５３２は、分散データ管理モジュール１０４と分散データ管理モジュール１１４とがオフライン状態になり、個々の分散データ管理モジュールで各種処理が行なわれた後の状態における階層構造を示す。同図に示す如く、それぞれのコンピュータ１０１、１１１の操作者は、それぞれ任意の操作を行ったので、分散データ管理モジュール１０４側で管理されている階層構造と、分散データ管理モジュール１１４側で管理されている階層構造とは異なっている。より具体的には、分散データ管理モジュール１０４側で管理されている階層構造では、フォルダ５１２を削除し、フォルダ５１１の直下にフォルダ５１３とフォルダ５１４とを属させるような処理を行なっている。

フォルダ５１５は分散管理モジュール１１４でロックが取得されているので分散管理モジュール１０４では操作が禁止されている。一方、分散データ管理モジュール１１４側で管理されている階層構造では、フォルダ５６５に属するファイル５７５を削除する処理を行なっている。これらは、図示したようなロックを取得することで並行に処理可能である。

５３３は、分散データ管理モジュール１０４と分散データ管理モジュール１１４とをオンライン状態にした後に、共有処理部３０７が上記処理を実行することで、分散データ管理モジュール１０４側と分散データ管理モジュール１１４側とで管理されている階層構造を示す。同図に示す如く、それぞれのコンピュータ側で行った操作内容（変更内容）が、共有処理部３０７によって相手にも通知されているので、結果として５３３に示す如く、それぞれの分散データ管理モジュールが管理する階層構造は同じものとなる。

フォルダ関係登録処理が、ファイル登録処理やフォルダ登録処理から独立しているので、フォルダは必ずしも親フォルダを持たなくてもよい。ここでは、フォルダ５６５とフォルダ５６２との関係はなくなったため、フォルダ５６５はどのフォルダにも属さない状態で存在することになる。

従来の分散データ管理装置では、例えばフォルダ５１２を削除する際には、サブフォルダを全てロックする必要があったため、別のコンピュータでフォルダ５１５をロックすることができなかった。そのため、フォルダ５１５に属するコンテンツの削除を並行して行なうことができなかった。それに対し、本実施形態では、前述したように二つの処理を並行して実行できる。

［第２の実施形態］
第１の実施形態では、ファイル登録処理及びフォルダ登録処理と、フォルダ関係登録処理とを独立させるために、データ識別子生成部３０１を設け、これによって生成されたデータ識別子をキーとして、ファイルやフォルダを管理していた。しかし、上記処理を独立させるための実現方法は上記方法に限定するものではなく、様々な方法が適用可能である。例えば他にも、親フォルダを持たないフォルダやファイルを、管理用に用意した管理用フォルダのフォルダ要素として管理する方法がある。この方法を用いると、ファイルシステムを用いて管理が可能である。

また、本実施形態では、第１の実施形態と以下の点が異なる。まず、データ識別子の代わりに、ローカルファイルシステムでのパスを識別情報として用いる。ファイル追加処理では、ファイルを管理用フォルダに登録する。ファイル削除処理では、このファイルを削除する。フォルダ追加処理では、管理用フォルダにフォルダを登録する。フォルダ削除処理では、このフォルダを削除する。フォルダ関係追加処理では、追加するフォルダ関係に従って、親フォルダの下に子フォルダもしくはファイルを移動する。フォルダ関係削除処理では、削除されるフォルダ関係に従って、子フォルダもしくはファイルを管理用フォルダの下に移動する。

複数の分散データ管理モジュールでシステムを構成する場合は、全分散データ管理モジュールで、同じ処理を行う。あるいは、システムとして仮想ファイルシステムを設け、仮想ファイルシステム上で上記の処理を行ってもよい。この場合、仮想ファイルシステムのパスでデータを識別する。実際のフォルダやコンテンツは、ローカルファイルシステム上に保持し、仮想ファイルシステムのパスとローカルファイルシステムのパスとの対応データを保持することで、各分散データ管理モジュールから実際のデータにアクセスできる。

［第３の実施形態］
上記実施形態では、ファイルは、ファイル追加要求があったコンピュータによって保持されているが、これに限定するものではなく、ファイルシステムの空き容量が大きいコンピュータに保持させるようにしても良い。また、複数のコンピュータで同じファイルを保持させるようにしても良い。また、ファイル変更処理とファイル削除処理では、全てのコンピュータについて、同様の変更、削除処理を行なう。

［第４の実施形態］
上記実施形態では、フォルダ関係は、アプリケーションにより明示的に指定されるだけであった。これ以外にも、検索条件を満足するファイルもしくはフォルダを、仮想的なフォルダ関係とするいわゆる検索フォルダを設けてもよい。検索フォルダを追加した時は、そのメタデータとして検索条件を保持する。そして、フォルダ探索処理においては、フォルダ関係を取得する代わりに、メタデータとして保持されている検索条件を満足するファイルあるいはフォルダを、検索部３１１を用いて取得する。このようにして取得されたファイルあるいはフォルダを、あたかもフォルダ関係が設定されたフォルダ要素のようにして、フォルダ探索結果として返す。

［第５の実施形態］
上記実施形態では、１台のコンピュータで１つの分散データ管理モジュールが動作する形態であったが、複数の分散データ管理モジュールが別のプロセスなどとして動作してもよい。

［その他の実施形態］
また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行う。その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

本発明の第１の実施形態に係るシステム（分散データ管理システム）の基本的な構成を示すブロック図である。 コンピュータ１０１、１１１に適用可能な（換言すると分散データ管理システムを構成するコンピュータに適用可能な）コンピュータのハードウェア構成を示すブロック図である。 分散データ管理モジュール１０４の機能構成を示すブロック図である。 コンピュータが管理するフォルダ（ファイル）の階層構造の一例を示す図である。 本発明の第１の実施形態での操作を行なった場合のデータ変化の例を示す模式図である。 本体配置データ保持部３０３が保持するテーブル情報の構成例を示すブロック図である。 メタデータ保持部３０４が保持するメタデータの構成例を示す図である。 フォルダ関係データの構成例を示すブロック図である。 コンピュータ１０１、１１１内におけるデータを示す図である。 ファイルを扱う場合における処理のフローチャートである。 ステップＳ１００４におけるファイル追加処理の詳細を示すフローチャートである。 ステップＳ１００５におけるファイル削除処理の詳細を示すフローチャートである。 ステップＳ１００３におけるファイル変更処理の詳細を示すフローチャートである。 分散データ管理モジュール１０４によるフォルダ追加処理のフローチャートである。 分散データ管理モジュール１０４によるフォルダ削除処理のフローチャートである。 フォルダ探索処理のフローチャートである。 ファイルの取得処理のフローチャートである。 ロック管理部が保持するロック管理データの構成例を示す図である。 ロックサーバとしての分散データ管理モジュール１０４がロックを取得する処理のフローチャートである。

Claims (10)

1. 情報処理装置であって、
   前記情報処理装置内のそれぞれのファイル若しくはフォルダのメタデータを、ネットワークで構成された複数の情報処理装置と共有可能に管理する管理手段と、
   前記情報処理装置内の第１のフォルダと第２のフォルダとの関係を親子階層として登録する登録手段と、
   オフラインで操作した前記ファイルまたはフォルダの操作結果を指示されたタイミングで前記複数の情報処理装置に反映させる反映手段とを備え、
   前記反映を行うにあたり、前記登録手段により前記第２のフォルダと関係付けられていた親階層の前記第１のフォルダがオフライン中に削除されていた場合には、第２のフォルダに親フォルダを持たせない登録を行うことを特徴とする情報処理装置。
2. 前記操作では、自装置がロックを取得している前記ファイルまたはフォルダを自装置で削除または変更することを特徴とする請求項１に記載の情報処理装置。
3. 前記管理されているファイルまたはフォルダのうち操作対象をロックする要求を外部装置に送信する手段と、
   前記要求に応じて前記外部装置からロック可能／不可能である旨を示すロック情報を受信する手段と、
   前記操作対象についてロック可能である旨を受信している場合には、前記操作対象に対して操作を行う手段と
   を備えることを特徴とする請求項２に記載の情報処理装置。
4. 前記操作では、ロックを取得せずに前記ファイルまたはファイルを新規に登録することを特徴とする請求項１に記載の情報処理装置。
5. 前記管理手段は、識別子を用いてファイルとフォルダとを前記複数の情報処理装置と共有可能に管理することを特徴とする請求項１に記載の情報処理装置。
6. 前記識別子は、前記情報処理装置の情報と前記情報処理装置内でのファイル固有の情報から構成されることを特徴とする請求項５に記載の情報処理装置。
7. 前記管理手段は更に、各ファイルと各ファイルを保持している前記情報処理装置の番号とを関連付けて保持することを特徴とする請求項１に記載の情報処理装置。
8. 情報処理装置が行う情報処理方法であって、
   前記情報処理装置内のそれぞれのファイル若しくはフォルダのメタデータを、ネットワークで構成された複数の情報処理装置と共有可能に管理する管理工程と、
   前記情報処理装置内の第１のフォルダと第２のフォルダとの関係を親子階層として登録する登録工程と、
   オフラインで操作した前記ファイルまたはフォルダの操作結果を指示されたタイミングで前記複数の情報処理装置に反映させる反映工程とを備え、
   前記反映を行うにあたり、前記登録工程で前記第２のフォルダと関係付けられていた親階層の前記第１のフォルダがオフライン中に削除されていた場合には、第２のフォルダに親フォルダを持たせない登録を行うことを特徴とする情報処理方法。
9. コンピュータに請求項８に記載の情報処理方法を実行させるためのプログラム。
10. 請求項９に記載のプログラムを格納したことを特徴とする、コンピュータ読み取り可能な記憶媒体。

Images