JP4497983B2 - ファイル共有制御システム、共有制御サーバおよび共有制御プログラム - Google Patents

Description

本発明は、ファイルのバックアップおよびその共有を制御するシステム、共有制御サーバおよびプログラムに関する。

近年のコンピュータ機器の性能向上によりパーソナルコンピュータの小型化が進み、 オフィス内で使用されるパーソナルコンピュータが小型化しつつある。また、オフィススペースの制約により、使用されるパーソナルコンピュータも、デスクトップ型のものからノート型の物にシフトしつつある。さらにまた、当然のように、ローカルエリアネットワーク（ＬＡＮ）によってネットワーク接続され、仕事の成果物である各種ファイル（ドキュメントファイルや表計算ソフトのデータファイル等）は、ファイルサーバーに格納するという業務運用が一般化してきている。
特開２００３−２９６１７５号公報

しかしながら、ノート型のパーソナルコンピュータが利用されるようになってくると、つぎのような事態が多々発生するようになってきた。
（１）オフィス内のＬＡＮ接続できない場所での作業時にノート型パーソナルコンピュータ（以下、「ノートＰＣ」とも称する。）をＬＡＮから切り離して移動し作業する。
（２）オフィス内にとどまらず、出先にもノートＰＣを持ち出して作業する。

このような利用方法を取る場合、以下のような作業方法をとるケースが頻繁に発生している。

タイプ１
業務に使用する各種のファイルはファイルサーバーから一旦ノートＰＣのローカルディスクにコピーして使用する。
作業終了後、ローカルディスクからファイルサーバーに書き戻す

タイプ２
新規に作成するファイルは、ローカルディスク内にて作成し、作業完了後ファイルサーバーに書き出す。

しかしながら、このような使用方法では、以下のようなトラブルが生じたときに、業務に必要とするファイルが永遠に失われてしまう事態となりかねない。
（１）使用しているノートＰＣが故障した場合
（２）誤操作により必要ファイルを削除してしまった場合
（３）ノートＰＣを紛失（盗難）した場合
上述した状況が発生する背景として、主として以下のような原因があると言われている。
（１）ファイルサーバーへのコピー作業が人間の手作業に依存している。
（２）ノートＰＣのローカルディスクのバックアップ手段になかなかよい物がない。

また、コストの問題と、使用場所を選ばなくても作業できるノートＰＣという特性上、 各ノートＰＣにバックアップ装置をつけるというのも現実的に無理という問題点もある。

その結果、一旦ノートＰＣに障害が発生した場合には、ファイルを復旧できないという致命的な事態となる確率が大きくなってきている。そして、コンピュータ性能の向上によりより大きなローカルディスクが標準的に装着されるようになってきており、その被害影響度合いはますます深刻度を増している。

また、システム設計などにおいて、１つのプロジェクトを複数人で実現することが一般化している。この場合、自己の担当箇所について、パーソナルコンピュータにて作業し、その成果物である各種ファイルを、サーバにも格納し、他の者がこれを閲覧し、場合によっては、更新できるようにしておく。

たとえば、特許文献１には、プロセス定義情報により、グループ名の羅列による処理経路が表わされ、あるグループが処理を終了すると、次のグループが処理を開始できるような協同作業支援システムが開示されている。しかしながら、各作業者が自由に作業を進めることで、全体を進行される場合には、上記システムを利用するのは困難である。また、予めプロセス定義情報を作成しておくという手順も必要となる。

本発明は、ユーザによる煩雑な操作なくファイルのバックアップができ、また、煩雑な操作なく、複数のコンピュータ間で、ファイルを共有することができるシステムを提供することを目的とする。

本発明の目的は、自己が所有するファイルが格納されたディレクトリパス、ディレクトリ名を含むレコードを有する所有ディレクトリ情報テーブル、および、前記ファイルのネットワークを介したアップロードおよびダウンロードを管理するローカルファイル管理手段を有するクライアントコンピュータと、ネットワークを介して送付された所有ディレクトリ情報テーブルのレコードに基づき生成された、前記ファイル所有者のノード名、当該クライアントコンピュータのファイルを格納するディレクトリ名、および、アップデート時刻を含むレコードを格納する所有者パス情報テーブル、ファイル所有者のノード名、ファイル名、当該ファイルが格納されたディレクトリパスを含むレコードを有する実ファイル情報テーブル、ファイル名、ファイルのタイムスタンプ、ファイルの内容を示す情報を含むレコードを有する実ファイル世代情報テーブル、前記ローカル管理手段からネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を、前記クライアントコンピュータに送信するセンター条件判断手段、並びに、前記クライアントコンピュータからの要求にしたがって、アップロードされたファイルを、記憶装置中、所定のディレクトリパスに格納し、また、所定のディレクトリパスに格納されたファイルを、前記クライアントコンピュータにダウンロードするセンターファイル管理手段を有する制御サーバとを備え、前記クライアントコンピュータが、前記判断結果にしたがって、前記ファイルのダウンロード或いはアップロードを、前記制御サーバに対して要求するローカル条件判断手段を有することを特徴とするファイル共有制御システムにより達成される。

本発明によれば、センター条件判断手段が、ファイルのタイムスタンプやファイルの内容の一致などに基づいて、判断結果を、クライアントコンピュータに送信し、クライアントコンピュータのローカル条件判断手段が、ファイルのダウンロード或いはアップロードの是非を判断する。これにより、ユーザが煩雑な操作をすることなく、ファイルのバックアップ（制御サーバへのファイルのアップロード）、バックアップされたファイルの取得（制御サーバからのファイルのダウンロード）を実現することができる。

好ましい実施態様においては、さらに、クライアントコンピュータが、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルを有し、前記ローカルファイル管理手段が、利用ディレクトリ情報テーブルに基づいて、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報を送信し、前記制御サーバのセンター条件判断手段が、ローカル管理手段からネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブル、および、実ファイル世代情報テーブルを参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を送信し、前記クライアントコンピュータのローカル条件判断手段が、前記判断結果にしたがって、前記ファイルのダウンロード或いはアップロードを、前記制御サーバに対して要求する。

本実施の形態によれば、クライアントコンピュータにおいて、他のクライアントコンピュータが所有するファイル中、利用したいものの情報を、利用ディレクトリ情報テーブルのレコードとして用意しておけば、センター条件判断手段およびセンター条件判断手段により、当該他のクライアントコンピュータのファイルのダウンロードなどの是非が判断される。これにより、他のクライアントコンピュータが所有するファイルを、利用者が共有することが可能となる。

別の実施態様においては、さらに、クライアントコンピュータが、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルを有し、前記ローカルファイル管理手段が、利用ディレクトリ情報テーブルに基づいて、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報を送信し、前記制御サーバのセンター条件判断手段が、ローカル管理手段からネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を送信し、前記クライアントコンピュータのローカル条件判断手段が、前記判断結果にしたがって、前記ファイルのダウンロード或いはアップロードを、前記ファイルを所有するクライアントコンピュータに対して要求する。

より好ましい実施態様においては、前記所有ディレクトリテーブルのレコードが、ファイルの公開の可否を示す公開フラグ、公開が可能である場合のファイルの更新の可否を示す公開タイプ情報を含み、前記所有者パス情報テーブルが、前記公開フラグおよび公開タイプ情報を含み、前記センター条件判断手段が、前記所有者パス情報テーブルの、公開フラグおよび公開タイプ情報を参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断する。

また、好ましい実施態様においては、前記ファイルの内容を示す情報が、ファイルのハッシュ値であり、前記センター条件判断手段が、ハッシュ値を比較することにより、ファイルの内容の一致を判断する。

また、本発明の目的は、クライアントコンピュータが有する、自己が所有するファイルが格納されたディレクトリパス、ディレクトリ名を含むレコードを有する所有ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、クライアントコンピュータ名、当該クライアントコンピュータのファイルを格納するディレクトリ名、および、アップデート時刻を含むレコードを格納する所有者パス情報テーブル、ファイル所有者のノード名、ファイル名、当該ファイルが格納されたディレクトリパスを含むレコードを有する実ファイル情報テーブル、ファイル名、ファイルのタイムスタンプ、ファイルの内容を示す情報を含むレコードを有する実ファイル世代情報テーブル、ネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を、前記クライアントコンピュータに送信するセンター条件判断手段、並びに、前記クライアントコンピュータからの要求にしたがって、アップロードされたファイルを、記憶装置中、所定のディレクトリパスに格納し、また、所定のディレクトリパスに格納されたファイルを、前記クライアントコンピュータにダウンロードするセンターファイル管理手段を備え、前記クライアントコンピュータから前記判断結果にしたがった前記ファイルのダウンロード或いはアップロードの要求に応じて、前記センターファイル管理手段が、前記ファイルをダウンロード或いはアップロードすることを特徴とするファイル共有制御サーバによっても達成される。

好ましい実施態様においては、前記センター条件判断手段が、クライアントコンピュータが有する、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を、前記クライアントコンピュータに送信する。

また、本発明の目的は、クライアントコンピュータが有する、自己が所有するファイルが格納されたディレクトリパス、ディレクトリ名を含むレコードを有する所有ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、クライアントコンピュータ名、当該クライアントコンピュータのファイルを格納するディレクトリ名、および、アップデート時刻を含むレコードを格納する所有者パス情報テーブルと、ファイル所有者のノード名、ファイル名、当該ファイルが格納されたディレクトリパスを含むレコードを有する実ファイル情報テーブルと、ファイル名、ファイルのタイムスタンプ、ファイルの内容を示す情報を含むレコードを有する実ファイル世代情報テーブルとを備えたコンピュータにより読み出し可能なプログラムであって、前記コンピュータを、ネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を、前記クライアントコンピュータに送信するセンター条件判断手段、並びに、前記クライアントコンピュータからの要求にしたがって、アップロードされたファイルを、記憶装置中、所定のディレクトリパスに格納し、また、所定のディレクトリパスに格納されたファイルを、前記クライアントコンピュータにダウンロードするセンターファイル管理手段であって、クライアントコンピュータから前記判断結果にしたがった前記ファイルのダウンロード或いはアップロードの要求に応じて、前記ファイルをダウンロード或いはアップロードするセンターファイル管理手段として機能させることを特徴とするファイル共有制御プログラムによっても達成される。

好ましい実施態様においては、前記コンピュータを、センター条件判断手段として機能させる際に、クライアントコンピュータが有する、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記ファイルに関するダウンロード或いはアップロードの条件を判断し、判断結果を、前記クライアントコンピュータに送信するように、前記コンピュータを動作させる。

本発明によれば、ユーザによる煩雑な操作なくファイルのバックアップができ、また、煩雑な操作なく、複数のコンピュータ間で、ファイルを共有することができるシステムを提供することが可能となる。

以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本発明の実施の形態にかかるファイルバックアップ・共有制御サーバ（以下、「制御サーバ」或いは場合によって「センターコントローラ」と称する。）を含むシステム全体の構成を示すブロックダイヤグラムである。図１に示すように、ファイルバックアップ・共有制御サーバ１０と、複数のクライアント・パーソナルコンピュータ（以下、「クライアントＰＣ」或いは場合によって「ノード」と称する）１２−１、１２−２、・・・、１２−ｎは、ネットワーク１４を介して接続可能となっている。また、ネットワーク１４には、制御サーバ１０におけるファイルバックアップやファイル共有の処理について、クライアントＰＣに通知するメールサーバ１６が接続されていても良い。本実施の形態において、ネットワークとして、ＴＣＰ／ＩＰを利用しているが、これに限定されるものではなく、任意の有線或いは無線のネットワークを利用することができる。

図２（ａ）に示すように、制御サーバ１０は、後述するオンラインノード管理テーブル２００、所有者パス(path)情報テーブル２０１、実ファイル情報テーブル２０２および実ファイル世代情報テーブル２０３を含むデータベース２０を有する。また、制御サーバ１０は、クライアントＰＣ１２からの送信された電文の内容およびテーブルの内容に基づいて、ファイルのダウンロード或いはアップロードに関して、どの条件に合致するかを判断する条件判断部（センター条件判断部）２２と、ファイルの読み出し／書き込みおよび送信／受信を管理するファイル管理部（センターファイル管理部）２４とを有している。条件判断部２２およびファイル管理部２４の機能は、制御サーバ１０のメモリなどの記憶装置に記憶されたエージェントプログラム（以下、単に「エージェント」と称する。）により実現される。

図２（ｂ）に示すように、各クライアントＰＣ１２の記憶装置３０には、ノード基本情報テーブル２１１、所有ディレクトリ情報テーブル２１２および利用ディレクトリ情報テーブル２１３が記憶される。また、各クライアントＰＣ１２は、ファイルのダウンロード或いはアップロードに関しての条件を判断する条件判断部（ローカル条件判断部）３２、および、ファイルをアップロード或いはダウンロードするファイル管理部（ローカルファイル管理部）３４を備えている。記憶装置３２には、エージェント（図示せず）が記憶されており、条件判断部３２およびファイル管理部３４の機能は、エージェントにより実現される。

図３は、ノード基本情報テーブル２１１のデータ構成を示す図である。図３に示すように、ノード基本情報テーブル２１１は、項目として、「自ノード名」、「ノード識別キー」、「センターコントローラＩＰアドレス」、「センターコントローラListenポート番号」、「E-Mailアドレス」および「ディレクトリSync間隔」から構成される。

図４は、所有ディレクトリ情報テーブル２１２のデータ構成を示す図である。図４に示すように、所有ディレクトリ情報テーブル２１２のレコードは、項目として、「所有ディレクトリPath（パス）」、「所有ディレクトリ呼称」、「最大保存世代数」、「削除ファイル保存期間」、「公開フラグ」、「公開パスワード」、「公開タイプ」、「通知メール受領フラグ」、「前回同期時刻（ノード側）」および「前回同期時刻（センター側）」を含む。所有ディレクトリ情報テーブルのレコードは、クライアントＰＣ（たとえば、クライアントＰＣ１２−１）が所有する一群のファイルを特定するための情報である。たとえば、「所有ディレクトリPath」および「所有ディレクトリ呼称」により特定されるディレクトリに属するファイル群を特定することができる。「公開フラグ」が「ON」である場合には、そのファイル群は、他のクライアントＰＣ（たとえば、クライアントＰＣ１２−２）と共有することができる。

図５は、利用ディレクトリ情報テーブル２１３のデータ構成を示す図である。図５に示すように、利用ディレクトリ情報テーブル２１３のレコードは、項目として、「ディレクトリ所有者ノード名」、「ディレクトリ呼称」、「公開パスワード」、「ファイル格納先基準ディレクトリPath（パス）」、「通知メール受領フラグ」、「変更結果反映フラグ」、「前回同期時刻（ノード側）」および「前回同期時刻（センター側）」を含む。「ディレクトリ所有者ノード名」および「ディレクトリ呼称」により、クライアントＰＣ（たとえば、クライアントＰＣ１２−１）が、ファイルの共有を希望する他のクライアントＰＣ（たとえば、クライアントＰＣ１２−２）のファイル群が特定される。「公開パスワード」により、そのファイル群の共有が許可される。また、「ファイル格納先基準ディレクトリパス」により、クライアントＰＣ（たとえば、クライアントＰＣ１２−１）が、他のクライアントＰＣ（たとえば、クライアントＰＣ１２−２）から共有を希望するファイル群をダウンロードした際の、クライアントＰＣ（たとえば、クライアントＰＣ１２−１）における格納場所が特定される。

図６（ａ）は、オンラインノード管理テーブル２００のデータ構成を示す図である。図６（ａ）に示すように、オンラインノード管理テーブル２００のレコードは、項目として、「ノード名」、「ノード識別コード」、「ノードＩＰアドレス」、「ノードポート番号」、「ノード状態」、「Online（オンライン）開始日時」、「Offline（オフライン）日時」、「ノード管理者アドレス」を含む。このレコードに含まれる項目の値により、制御サーバ１０は、ネットワーク１４を介して接続したクライアントＰＣ１２を特定することができる。

図６（ｂ）は、所有者パス情報テーブル２０１のデータ構成を示す図である。図６（ｂ）に示すように、所有者パス情報テーブルのレコードは、項目として、「ノード名」、「所有ディレクトリ呼称」、「最大保存世代数」、「削除ファイル保存期間」、「公開フラグ」、「公開パスワード」、「公開タイプ」、「通知メール受領フラグ」、「Path内Syncフラグ」、「更新者ノード名」、「最終Upload（アップロード）時刻」および「削除フラグ」を含む。

このレコードは、クライアントＰＣ１２の所有ディレクトリ情報テーブルのレコードが、制御サーバ１０に登録される際に新規に作成される。したがって、「ノード名」は、クライアントＰＣのノード名に相当し、また、所有者パス情報テーブルのレコード中、「所有ディレクトリ呼称」、「最大保存世代数」、「削除ファイル保存期間」、「公開フラグ」、「公開パスワード」、「公開タイプ」、「通知メール受領フラグ」の値が、所有ディレクトリ情報のレコード中、対応する項目の値として格納される。

図７（ａ）は、実ファイル情報テーブル２０２のデータ構成を示す図である。図７（ａ）に示すように、実ファイル情報テーブル２０２のレコードは、項目として、「ノード名」、「所有ディレクトリ呼称」、「相対Path（パス）」、「実ファイル名」、「サーバファイル名」および「削除フラグ」を有する。「ノード名」は、クライアントＰＣ１２のノード名に対応し、「所有ディレクトリ呼称」は、所有ディレクトリ情報テーブルのレコード中、「所有ディレクトリ呼称」に対応する。「相対Path」は、ファイルが、クライアントＰＣ１２において、所有ディレクトリ内のサブディレクトリに格納されている場合の、所有ディレクトリからの相対パスを示す。また、「サーバファイル名」は、当該ファイルを制御サーバ１０において格納する場合のファイル名である。この実ファイル情報テーブル２０２のレコードにより、クライアントＰＣ１２中のファイルを特定することができる。

図７（ｂ）は、実ファイル世代情報テーブル２０３のデータ構成を示す図である。図７（ｂ）に示すように、実ファイル世代情報テーブル２０３のレコードは、項目として、「サーバファイル名」、「登録日時」、「登録ディレクトリ」、「登録ノード名」、「格納ファイルサイズ」、「ファイルサイズ」、「ハッシュ値」、「圧縮後ハッシュ値」および「タイムスタンプ」を有する。「登録日時」は、ファイルが制御サーバ１０の記憶装置に格納された日時に相当する。「登録ディレクトリ」は、制御サーバ１０にファイルを格納するときのパスに相当する。制御サーバ１０は、記憶装置に、格納ファイル情報テーブル（図示せず）を記憶しておく。この格納ファイル情報テーブルのレコードには、クライアントＰＣ１２からアップロードされたファイルを、制御サーバ１０にて保存する、記憶装置内のディレクトリパスに相当する「ファイルバックアップ基準Path（パス）」が含まれる。登録ディレクトリは、格納ファイル情報テーブルの何れかのレコードの値と一致する。

まず、クライアントＰＣ（例として、クライアントＰＣ１２−１を考える。）から、当該クライアントＰＣ１２−１が所有するファイルをアップロードし、或いは、制御サーバ１０からファイルをダウンロードする際の手順について説明する。本実施の形態においては、クライアントＰＣ１２−１自身のファイルを、制御サーバ１０にアップロードすることにより、制御サーバ１０にバックアップすることができる。バックアップされたファイルを、クライアントＰＣ１２−１がダウンロードすることで、バックアップされたファイルを取得することができる。

クライアントＰＣ１２−１のファイルを共有する場合には、クライアントＰＣ１２−１がファイルを制御サーバ１０にアップロードし、そのファイルを利用する他のクライアントＰＣ（例として、クライアントＰＣ１２−２を考える。）は、制御サーバ１０から、ファイルをダウンロードする。また、他のクライアントＰＣ１２−２において一定の作業がなされ、更新されたファイルが、制御サーバ１０にアップロードされ、その後、クライアントＰＣ１２−１に、更新が反映されるように、そのファイルがダウンロードされる場合もある。

図８は、クライアントＰＣ（ノード）と、制御サーバ（センターコントローラ）との間で、ファイルを比較した結果の態様を示す表である。以下、図８を参照して、比較結果の態様にしたがった処理について概説する。

なお、所有者とは、初期的に、自己のファイルを制御サーバ１０にアップロードする者をいい、利用者とは、初期的に、他人がアップロードしたファイルをダウンロードして利用する者をいう。

処理は、以下に述べる基本原則に従う。
（１）ディレクトリ内のファイルを更新してもよいノードが、センターコントローラよりも新しいファイルを持っている場合は、センターコントローラにアップロードする。
（２）ディレクトリ内のファイルを更新してもよいノードが、センターコントローラよりも 古いファイルを持っている場合は、センターコントローラから、ファイルをダウンロードして上書きする。ただし、ノード内のファイルがセンターセンターコントローラ内に履歴として存在しているかをチェックして、履歴にある場合には、センターコントローラからファイルをダウンロードして上書きする。その一方、履歴にない場合には、ノードのファイルの名称を変更（元のファイル名に追加の拡張子「.dif」を付けた名前）する。

［ケース１：所有者、非公開、ファイル一致］
所有ディレクトリは、公開されていない。つまり、当該ファイルに関する所有ディレクトリ情報のレコード中、「公開フラグ」は「OFF」である。また、ノードのファイルとセンターコントローラのファイルとは一致する。
この場合、なんらアクションは生じない。

［ケース２：所有者、非公開、ノードのファイルが旧バージョン］
所有ディレクトリは公開されておらず、また、ノードのファイルとセンターコントローラのファイルとでは、ノードのものが古い。この場合、センターコントローラのファイルをノードにダウンロードする。

なお、通常の本ケースは発生しないが、ノードで古いファイルに手動で置き換えたりした場合や、所有ディレクトリを公開・更新可の状態から非公開に切り替えた時に、その変更がセンターコントローラに反映される前にディレクトリ利用者のクライアントＰＣで、変更されたファイルがアップロードされた場合などで、生じる可能性がある。

［ケース３：所有者、非公開、ノードのファイルが新バージョン］
所有ディレクトリは公開されておらず、かつ、ノードのファイルが新しい場合には、ノードＰＣのファイルをセンターコントローラにアップロードする。アップロードされたセンターコントローラでは、アップロードされたファイルを新世代のファイルとして格納する。

［ケース４：所有者、非公開、ノードにファイルなし］
所有ディレクトリは公開されておらず、かつ、ノードにファイルが無い場合には、ノードからのファイル同期(Sync)処理終了の通知が、センターコントローラに来たタイミングで、センターコントローラは、所有者パス情報テーブルの、そのファイルに対応するレコード中、「削除フラグ」を「ON」にする。

［ケース５：所有者、非公開、センターコントローラにファイルなし］
所有ディレクトリは公開されておらず、かつ、センターコントローラにファイルがない場合には、ノードからセンターコントローラに、ファイルをアップロードする。受信したセンターコントローラはそのファイルを新規ファイルとして、記憶装置に記憶する。

［ケース６：所有者、公開、更新不可、ファイル一致］
所有ディレクトリは公開されている。その一方、利用者による更新は不可、つまり、所有者パス情報テーブルにおいて、当該ファイルについてのレコード中、「公開タイプ」が、「更新不可」となっている。また、ノードのファイルと、センターコントローラのファイルとは一致する。このような場合には、なんらアクションは生じない。

［ケース７：所有者、公開、更新不可、ノードのファイルが旧バージョン］
所有ディレクトリは公開され、かつ、利用者による更新は不可となっている。また、ノードのファイルと、センターコントローラのファイルとでは、ノードのものが古い。この場合、センターコントローラのファイルの更新者がノード所有者と同じか確認する。ここで、センターコントローラのファイルの更新者は、ノードからセンターコントローラに送信される電文中の「ノード名」により特定される。両者が同一であれば、ノードは、センターコントローラのファイルをダウンロードして上書きする。両者が異なる場合には、ノードのファイルの名称を変更した上で、センターコントローラからファイルをダウンロードする。

［ケース８：所有者、公開、更新不可、ノードのファイルが新バージョン］
所有ディレクトリは公開され、かつ、利用者による更新は不可となっている。また、ノードのファイルとセンターコントローラのファイルとでは、ノードのものが新しい。この場合には、ノードのファイルをセンターコントローラにアップロードする。ファイルをアップロードされたセンターコントローラでは、アップロードされたファイルを新世代のファイルとして格納する。

［ケース９：所有者、公開、更新不可、ノードにファイルなし］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、ノードにはファイルが存在しない。この場合には、ノードからファイル同期(Sync)処理終了の通知がセンターコントローラに来たタイミングで、センターコントローラは、所有者パス情報テーブルの、そのファイルに対応するレコード中、「削除フラグ」を「ON」にする。

［ケース１０：所有者、公開、更新不可、センターコントローラにファイルなし］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、センターコントローラとでは、センターコントローラにファイルが存在しない。この場合には、ノードからセンターコントローラに、ファイルをアップロードする。受信したセンターコントローラはそのファイルを新規ファイルとして、記憶装置に記憶する。

［ケース１１：所有者、公開、更新可、ファイル一致］
所有ディレクトリは公開され、かつ、利用者による更新は可、つまり、所有者パス情報テーブルにおいて、当該ファイルについてのレコード中、「公開タイプ」が「公開可」となっている。また、ノードのファイルとセンターコントローラのファイルとは一致する。このような場合には、なんらアクションは生じない。

［ケース１２：所有者、公開、更新可、ノードのファイルが旧バージョン］
所有ディレクトリは公開され、利用者による更新は可となっている。また、ノードのファイルとセンターコントローラのファイルとでは、ノードのものが古い。この場合、センターコントローラのファイルの更新者がノード所有者と同じか確認する。両者が同一であれば、ノードは、センターコントローラのファイルをダウンロードして上書きする。両者が異なる場合には、ノードのファイルの名称を変更した上で、センターコントローラからファイルをダウンロードする。

［ケース１３：所有者、公開、更新可、ノードのファイルが新バージョン］
所有ディレクトリは公開され、利用者による更新は可となっている。また、また、ノードのファイルとセンターコントローラのファイルとでは、ノードのものが新しい。この場合には、ノードのファイルをセンターコントローラにアップロードする。ファイルをアップロードされたセンターコントローラでは、アップロードされたファイルを新世代のファイルとして格納する。

［ケース１４：所有者、公開、更新可、ノードにファイルなし］
所有ディレクトリは公開され、利用者による更新は可となっている。また、ノードにはファイルが存在しない。この場合には、ノードからファイル同期(Sync)処理終了の通知がセンターコントローラに来たタイミングで、センターコントローラは、所有者パス情報テーブルの、そのファイルに対応するレコード中、「削除フラグ」を「ON」にする。

［ケース１５：所有者、公開、更新可、センターコントローラにファイルなし］
所有ディレクトリは公開され、利用者による更新は可となっている。また、センターコントローラにファイルが存在しない。この場合には、ノードからセンターコントローラに、ファイルをアップロードする。受信したセンターコントローラはそのファイルを新規ファイルとして、記憶装置に記憶する。

［ケース１６：利用者、非公開］
所有ディレクトリは公開されていない。したがって、利用者からのファイル同期処理の開始時点で、センターコントローラからアクセスが拒否される。

［ケース１７：利用者、公開、更新不可、ファイル一致］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、利用者のノード（以下、「利用者ノード」と称する。）のファイルとセンターコントローラのファイルとは一致する。この場合、なんらアクションは生じない。

［ケース１８：利用者、公開、更新不可、利用者ノードのファイルが旧バージョン］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、利用者ノードのファイルとセンターコントローラのファイルとでは、利用者ノードのものが古い。ここで、利用者ノードのファイルが、センターコントローラの履歴に存在する場合には、利用者ノードは、センターコントローラからファイルをダウンロードして上書きする。その一方、利用者ノードのファイルがセンターコントローラの履歴に存在しない場合には、利用者ノードは、ファイルの名称を変更した後、センターコントローラからファイルをダウンロードする。なお、ファイルがセンターコントローラの履歴に存在するとは、実ファイル世代情報テーブル中に、当該ファイルに関するレコードが存在することを意味する。

［ケース１９：利用者、公開、更新不可、利用者ノードのファイルが新バージョン］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、利用者ノードのファイルとセンターコントローラのファイルとでは、利用者ノードのものが新しい。この場合、ファイルの更新は不可であるため、なんらアクションは生じない。

［ケース２０：利用者、公開、更新不可、利用者ノードにファイルなし］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、利用者ノードにはファイルが存在しない。この場合、利用者ノードは、センターコントローラからファイルをダウンロードする。

［ケース２１：利用者、公開、更新不可、センターコントローラにファイルなし］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、センターコントローラにファイルが存在しない。この場合にも、ファイルの更新は不可であるため、なんらアクションは生じない。

［ケース２２：利用者、公開、更新可、ファイル一致］
所有ディレクトリは公開され、利用者による更新は可となっている。また、利用者ノードのファイルとセンターコントローラのファイルとは一致する。この場合には、なんらアクションは生じない。

［ケース２３：利用者、公開、更新可、利用者ノードのファイルが旧バージョン］
所有ディレクトリは公開され、利用者による更新は可となっている。また、利用者ノードのファイルとセンターコントローラのファイルとでは、利用者ノードのものが古い。この場合、利用者ノードのファイルがセンターコントローラの履歴に存在している場合には、利用者ノードは、センターコントローラからファイルをダウンロードし上書きする。その一方、利用者ノードのファイルがセンターコントローラの履歴に存在しない場合には、利用者ノードは、ファイルの名称を変更した後、センターコントローラからファイルをダウンロードする。

［ケース２４：利用者、公開、更新可、利用者ノードのファイルが新バージョン］
所有ディレクトリは公開され、利用者による更新は可となっている。また、利用者ノードのファイルとセンターコントローラのファイルとでは、利用者ノードのファイルが新しい。この場合、利用者ノードのファイルを、センターコントローラにアップロードする。ファイルをアップロードされたセンターコントローラは、アップロードされたファイルを新世代のファイルとして格納する。また、センターコントローラは、メールサーバ１６に、利用者ノードによるファイル更新を、所有者のノードにメールにて通知するよう指示する。

［ケース２５：利用者、公開、更新可、利用者ノードにファイルなし］
所有ディレクトリは公開され、利用者による更新は可となっている。また、利用者ノードにファイルが存在しない。この場合には、利用者ノードは、センターコントローラからファイルをダウンロードする。

［ケース２６：利用者、公開、更新可、センターコントローラにファイルなし］
所有ディレクトリは公開され、利用者による更新は不可となっている。また、センターコントローラにファイルが存在しない。

この場合、利用者ノードがセンターコントローラにファイルをアップロードする。ファイルを受信したセンターコントローラは、そのファイルを新規ファイルとして登録する。或いは、所有者によって削除されたファイルが復活されたとして、センターコントローラがそのファイルを登録しても良い。

次に、ファイル所有者のクライアントＰＣ（ノード）と、制御サーバ（センターコントローラ）との間の実際の情報の授受およびそれぞれにおける処理について、より詳細に説明する。初期的には、クライアントＰＣ１２のファイル管理部３４は、自己の情報（ノード名、ノード識別コード）などを制御サーバ１０に送信する。制御サーバ１０は、受信した情報に基づいて、オンラインノード管理テーブルのレコードを生成して、これをＤＢ２０に記憶しておく。

また、ファイルの授受に先立って、クライアントＰＣ１２のファイル管理部３４は、バックアップ或いは共有すべきファイルの情報を、所有ディレクトリ情報テーブル２１２のレコードとして用意する。このレコードの値が、ネットワーク１４を介して制御サーバ１０に送信されると、制御サーバ１０のファイル管理部２４は、このレコードの値に基づいて、所有者パス情報テーブル２０１のレコードを作成して、所有者パス情報テーブル２０１に格納する。

また、ファイル所有者のファイルを利用したい者（利用者）のクライアントＰＣ１２においては、ファイル管理部３４は、利用ディレクトリ情報テーブル２１３のレコードを用意しておく。たとえば、クライアントＰＣ１２が制御サーバ１０にアクセスして、所有者パス情報テーブルを参照し、利用したいファイルを指定して、そのレコードの情報を受信することにより、利用ディレクトリ情報テーブル２１３のレコードを作成することができる。

次に、図９を参照して、ファイル所有者のクライアントＰＣ１２におけるファイルのダウンロードおよびアップロードに関する同期(Sync)処理について説明する。

クライアントＰＣ１２のファイル管理部３４は、制御サーバ１０との間の通信を確立した後（ステップ９０１）、所有ディレクトリ内の各ファイルについて、そのファイルの基本属性情報を制御サーバ１０に送信する（ステップ９０２）。ファイル基本属性情報には、以下の項目の値が含まれる。
・ファイル名
・該当ファイルの絶対Pathから所有ディレクトリを基準とした相対Path
・ファイルのタイムスタンプ
・ファイルのMD5(Message Digest 5)ハッシュ値
・ファイルサイズ（バイト数）

制御サーバ１０のファイル管理部２４は、クライアントＰＣ１２−１から送信されたファイル基本情報の内容と、ＤＢ２０に格納されたテーブル（たとえば、所有者パス情報テーブル、実ファイル世代情報テーブル）中のレコードの値とを比較し、前述した何れのケースに該当するかを判断する（ステップ９０３）。ここでは、ファイルの一致、ファイルの更新者の一致などについて以下の態様が考えられる。
（１）ファイルの一致（クライアントＰＣの更新者および制御サーバに記録されている更新者も一致）。
（２）ファイルの一致（ただし、更新者は不一致）。
（３）クライアントＰＣ（ノード）のファイルのバージョンが古い（クライアントＰＣの更新者および制御サーバに記録されている更新者は一致）。
（４）クライアントＰＣのファイルのバージョンが古い（更新者は不一致）。
（５）クライアントＰＣのファイルのバージョンが新しい（クライアントＰＣの更新者および制御サーバに記録されている更新者は一致）。
（６）クライアントＰＣのファイルのバージョンが新しい（更新者は不一致）。
（７）ファイルが制御サーバに存在しない。

更新者の一致については、クライアントＰＣ１２と制御サーバ１０との間で通信を確立した際に、クライアントＰＣ１２から制御サーバ１０に送られる電文中のノード名と、所有者パス情報テーブル中のノード名とを比較することにより判断できる。

また、ファイル（の内容）の一致は、以下のように判断される。

ファイルが格納されている相対Path、ファイル名（実ファイル情報テーブル：図７（ａ）参照）、そのファイルのタイムスタンプおよび双方のファイルのMD5ハッシュ値（実ファイル世代情報テーブル：図７（ｂ）参照）が比較される。

同一のファイルであることを示す判定基準は、同一相対Pathで、かつ、同一ハッシュ値を持つファイルであることとする。すなわち、ファイル名、タイムスタンプが異なっていてもハッシュ値が同じであれば、双方のファイル内容は同じと識別する。ハッシュ値が異なる場合、双方のファイルのタイムスタンプを比較しどちらが新しいものかを判定する。

制御サーバ１０の条件判断部３２は、判断結果が上記（１）〜（７）の何れの態様であったかを、クライアントＰＣ１２に返信する（ステップ９０４）。

クライアントＰＣ１２の条件判断部３２は、判断結果を受信し、その結果に基づいて、ファイルをアップロードすべき場合には（ステップ９０５でイエス(Yes)）、ファイル管理部３４は、ファイルを制御サーバ１０に対してアップロードする（ステップ９０６）。その一方、ファイルをダウンロードすべき場合には（ステップ９０７でイエス(Yes)）、ファイル管理部３４は、制御サーバ１０に対して、ファイルのダウンロードを求める（ステップ９０８）。ダウンロード要求に応じて、制御サーバ１０からファイルがダウンロードされる（ステップ９０９）
ファイルのアップロード処理（ステップ９０６）についてより詳細に説明する。クライアントＰＣ１２のファイル管理部３４は、次の手順で自己の記憶装置３０に記憶されたファイルを加工した上で、制御サーバ１０のＤＢ２０にアップロードする。図１０（ａ）に示すように、クライアントＰＣ１２は、ファイル基本属性情報を再度収集する（ステップ１００１）。これは、先にステップ９０１において制御サーバ１０に送信したものを利用すればよい。次いで、ファイルの圧縮後の属性情報を収集する（ステップ１００２）。より詳細には、ファイルを、圧縮ツールを利用して圧縮し（ステップ１００３）、圧縮後のファイルのサイズ（バイト数）を算出し（ステップ１００４）、かつ、圧縮後のファイルのMD5ハッシュ値を算出する（ステップ１００５）。その後、ファイル基本属性情報、圧縮後の属性情報および圧縮されたファイルを、制御サーバ１０に送信する（ステップ１００５）。

制御サーバ１０は、図１０（ｂ）に示すように、ファイル等を受信すると（ステップ１０１１）、ＤＢ２０中、ファイル基本属性情報中の相対パスにしたがった位置にファイルを格納するとともに（ステップ１０１２）、ファイル基本属性情報および圧縮後の属性情報にしたがって、実ファイル世代情報テーブル２０３中の該当レコードの値を更新する（ステップ１０１３）。その後、制御サーバ１０は、ファイルのアップロードを通知する電文を、クライアントＰＣ１２に送信する（ステップ１０１４）。

クライアントＰＣ１２が、制御サーバ１０からファイルをダウンロードする際には、ダウンロードを要求する電文（ステップ９０８参照）中に、自己の「ノード名」、「ノード識別番号」などのほか、「相対Path」、「ファイル名」、ダウンロードするファイルの「タイムスタンプ」および「ハッシュ値」を含ませる。これにより、制御サーバ１０のファイル管理部２４は、ダウンロードすべきファイルを特定することが可能となる。

次に、ファイル利用者のクライアントＰＣ１２におけるファイルのダウンロードおよびアップロードに関する同期(Sync)処理について説明する。この処理も基本的には、図９を参照して説明したファイル所有者のクライアントＰＣにおける同期処理と類似する。

ファイル利用者のクライアントＰＣ１２のファイル管理部３４は、制御サーバ１０との間の通信を確立した後、利用ディレクトリ内の各ファイルについて、そのファイルの基本属性情報を制御サーバ１０に送信する。
ファイル基本属性情報には、以下の項目の値が含まれる。
・ファイル名
・該当ファイルの絶対Pathから所有ディレクトリを基準とした相対Path
・ファイルのタイムスタンプ
・ファイルのMD5(Message Digest 5)ハッシュ値
・ファイルサイズ（バイト数）

制御サーバ１０のファイル管理部２４は、クライアントＰＣ１２−１から送信されたファイル基本情報の内容などと、ＤＢ２０に格納されたテーブル中のレコードの内容とを比較し、前述した何れのケースに該当するかを判断する（ステップ９０３）。ここでは、ファイルの一致などについて以下の態様が考えられる。
（１）ファイルの一致
（２）クライアントＰＣ（ノード）のファイルのバージョンが古い（実ファイル世代情報テーブルには、ファイルに関するレコードが存在する）。
（３）クライアントＰＣ（ノード）のファイルのバージョンが古い（実ファイル世代情報テーブルには、ファイルに関するレコードが存在しない）。
（４）クライアントＰＣ（ノード）のファイルのバージョンが新しい（所有者パス情報テーブルにおいて、ファイルに関するレコード中、ファイル更新は可能となっている）。
（５）クライアントＰＣ（ノード）のファイルのバージョンが新しい（ファイル更新は不可となっている）。
（６）ファイルが制御サーバに存在しない。

制御サーバ１０の条件判断部３２は、判断結果が上記（１）〜（６）の何れの態様であったかを、クライアントＰＣ１２に返信する。クライアントＰＣ１２の条件判断部３２は、判断結果を受信し、その結果に基づいて、ファイルをアップロードすべき場合には、ファイル管理部３４は、ファイルを制御サーバ１０に対してアップロードする。その一方、ファイルをダウンロードすべき場合には、ファイル管理部３４は、制御サーバ１０に対して、ファイルのダウンロードを求める。ダウンロード要求に応じて、制御サーバ１０からファイルがダウンロードされる。

なお、上記例においては、利用者のクライアントＰＣは、制御サーバ１０からファイルをダウンロードするように構成しているが、これに限定されるものではない。たとえば、制御サーバ１０にダウンロードを要求する前に、利用者のクライアントＰＣが、所有者のクライアントＰＣに対して、ダウンロード要求の電文を送信し、可能な場合には、所有者のクライアントＰＣからファイルをダウンロードしても良い。ここで、利用者のクライアントＰＣから所有者のクライアントＰＣに対して送信されるダウンロード要求の電文には、ファイルを特定するため、タイムスタンプおよびハッシュ値を含める。所有者のクライアントＰＣは、自己のファイルが、要求されたファイルと異なれば、利用者クライアントＰＣからのダウンロード要求を拒否すればよい。この場合には、利用者のクライアントＰＣは、制御サーバ１０に対して、ファイルのダウンロードを求めることになる。

次に、本実施の形態の適用事例について説明する。まず、制御サーバ１０を、クライアントＰＣ１２のファイルバックアップ装置として使用する場合について説明する。図１１に示すように、クライアントＰＣ１２において、あるファイル（クライアントＰＣ１２がファイル所有者となっているファイル）が更新されたと考える（ステップ１１０１）。クライアントＰＣ１２のファイル管理部３４が、更新されたファイルのファイル基本属性情報を制御サーバ１２に送信する（ステップ１１０２）。制御サーバ１０の条件判断部２２は、ファイル基本情報の内容と、ＤＢ２０に格納されたテーブル中のレコードの値とを比較して、先に説明した（１）〜（７）の何れの態様に該当するかを判断する（ステップ１１０３）。この例では、
（５）クライアントＰＣのファイルのバージョンが新しい（クライアントＰＣの更新者および制御サーバに記録されている更新者は一致）。
に該当すると判断される。判断結果は、クライアントＰＣ１２に送信され（ステップ１１００４）。クライアントＰＣ１２の条件判断部３２は、ファイルをアップロードすべきと判断し、ファイル管理部３４が、当該ファイルを制御サーバ１０にアップロードする（ステップ１１０５）。制御サーバ１０のファイル管理部２４は、アップロードされたファイルを、ＤＢ２０中の所定の位置に格納するとともに、実ファイル世代情報テーブルのレコードを更新する（ステップ１１０６）。

次に、チームで作業をする場合について説明する。あるクライアントＰＣ（たとえば、クライアントＰＣ１２−１）がライブラリアンとして機能し、他のクライアントＰＣ（たとえば、クライアントＰＣ１２−２、１２−３、・・・）が、チームのメンバーとして機能すると考える。

システム設計など、複数人で１つのプロジェクトに関する仕事をする場合などでは、いつだれがどのファイルを作成・変更したかの記録と作成・変更タイミングの衆知徹底がプロジェクト推進上重要なポイントとなる。このような場合は本機構の補助手段としてE-Mailのメーリングリスト機能をもったメールサーバ１６を組み合わせることにより、ファイルを共有化した作業を実現できる。

まず、ドキュメント全体を管理する立場の人（ライブラリアン）が所有ディレクトリを定義して、ライブラリアンのクライアントＰＣ１２−１が、所有ディレクトリ情報テーブルのレコードを、制御サーバ１０に登録する。これにより、制御サーバ１０には、必要な所有者Path情報テーブルのレコードが生成される。ここで、メールサーバ１６を介して、プロジェクトのメンバーのクライアントＰＣにメールが通知できるようなメーリングリストを設定しておく。

たとえば、プロジェクトのメンバーに、即時通知或いは１日１回のまとめ送りの何れかのメーリングリストに登録することにより、実際の作業に携わるプロジェクトのメンバーは他のメンバーが作成・修正したファイルを自動的に、自己のクライアントＰＣのローカルディスクに保管することができ、かつ、変更の都度、変更通知メールを受取ることができる。

また、実際の作業には携わらないが、全体の動向を知る必要のある人（例えばプロジェクトリーダー/サブリーダー）は、前日行われた変更内容をメールで通知を受け、その成果物である各種ファイルが、自己のクライアントＰＣのローカルディスクに既に保管されているというような状況を作り出す事が可能となる。

また、プロジェクトが一区切りついたとき（例えば、製品の１次リリース向けの作業完了時）には、ライブラリアンがその所有ディレクトリを公開・更新可から公開・更新不可と属性変更することにより、ドキュメントの凍結を行う事が簡単にできる。

また、そのリリース時点のファイルを固定・保管する為に、ライブラリアンが利用ディレクトリを定義し、一旦固定したファイルをローカルディスクに、ダウンロードし、その後、改めてそのローカルディスクのディレクトリを先に登録した、所有ディレクトリとは別の所有ディレクトリー（公開・更新不可）として定義する事により、特定時点のファイルを永久に保管する事が可能である。その後、元の所有ディレクトリを公開・更新可と属性変更することにより、次のリリースに向けた変更作業が継続できるようになる。

たとえば、図１２に示すように、ライブラリアンのクライアントＰＣ１２−１は、共有するファイルの所有ディレクトリ情報テーブルのレコードを、制御サーバ１０に送信する（ステップ１２０１）。ここで、レコード中、「公開フラグ」は「ON」、「公開タイプ」は「更新可」としておく。送信されたレコードは、制御サーバ１０において、所有者パス情報テーブルのレコードとして登録される（ステップ１２０２）。また、クライアントＰＣ１２−１は、メールサーバ１６に、メーリングリスト用の各メンバーのMailアドレスを登録する（ステップ１２０３）。

その一方、プロジェクトのメンバーのクライアントＰＣ１２−２、１２−３、・・・においては、制御サーバ１０の所有者パス情報テーブルのレコードを参照して、クライアントＰＣの記憶装置中に、利用ディレクトリ情報のレコードを作成しておく。

図１３に示すように、たとえば、プロジェクトのメンバーのクライアントＰＣ１２−２は、利用ディレクトリ情報テーブルのレコードにて特定されるディレクトリのファイルを作成、更新する（ステップ１３０１）。ファイルが作成、更新されると、クライアントＰＣ１２−２のファイル管理部３４が、ファイルの基本属性情報を、制御サーバ１０に送信する（ステップ１３０２）。

制御サーバ１０の条件判断部２２は、ファイルの基本属性情報と、当該ファイルの実ファイル世代情報の該当レコードの情報とを比較して（ステップ１３０３）、その判断結果を、各クライアントＰＣ１２−１、１２−３、・・・に送信する（ステップ１３０４）。また、制御サーバ１０は、メールサーバ１６に対して、メーリングリストを利用したMail送信を依頼する（ステップ１３０５）。クライアントＰＣ１２−１は、判断結果に基づいて、作成、更新にかかるファイルを制御サーバ１０にアップロードする。これにより、制御サーバ１０は、当該ファイルに関して、実ファイル世代情報テーブルの該当レコードを更新する。

各ＰＣ１２−１、１２−３、・・・の条件判断部２２は、ファイルのダウンロードをすべきと判断し、制御サーバ１０に対してファイルのダウンロードを要求する。これにより、メンバーがクライアントＰＣ１２−２を利用して作成、変更したファイルを取得することができる。

次に、ファイルの凍結作業と次のフェーズの作業開始について、図１４を参照して、説明する。まず、ライブラリアンのクライアントＰＣ１２−１が、メールサーバ１６に対して、変更作業停止の通知を、メーリングリストを利用してMail送信するように要求する（ステップ１４０１）。次いで、クライアントＰＣ１２−１は、所有ディレクトリ情報テーブルの該当ファイルのレコードにおいて、「公開タイプ」を「更新可」から「更新不可」に変更する（ステップ１４０２）。

その後、クライアントＰＣ１２−１は、凍結ファイル格納用のディレクトリを、記憶装置３０中に新規作成し、そのディレクトリを、利用ディレクトリとして登録する（ステップ１４０３）。つまり、利用ディレクトリ情報テーブルのレコードを作成する。この基本属性情報を制御サーバ１０に送信する結果、制御サーバ１０から、各ファイルの最新バージョンのものが全て、クライアントＰＣ１２−１にダウンロードされる（ステップ１４０４）。

ダウンロード終了後、クライアントＰＣ１２−１において、利用者ディレクトリ情報テーブルのレコードを削除し、改めて、そのローカルディレクトリについて、所有ディレクトリとして定義する（ステップ１４０５）。つまり、そのローカルディレクトリの情報を、所有ディレクトリ情報テーグルのレコードとして格納する。ここでは、「公開タイプ」を「更新不可」としておく。これにより、このローカルディレクトリのファイルは、別途、制御サーバ１０で管理されることになる。

その後、当初のディレクトリの「公開タイプ」を、「更新不可」から「更新可」に変更することで、利用者によるファイルの更新が可能となる（ステップ１４０６）。クライアントＰＣ１２−１は、メールサーバ１６に対して、変更作業再開の通知を、メーリングリストを利用してMail送信するように要求する（ステップ１４０７）。

上記クライアントＰＣ１２−１の処理は、上記シーケンスにしたがって自動的に実行することができる。

上述したクライアントＰＣ１２−１の処理の結果、制御サーバ１０のＤＢ２０には、各メンバーが継続して作業するための所有ディレクトリ（もともと作業に使用していたディレクトリ）と、リリースに伴って固定されたファイルが格納されている変更不可の所有ディレクトリの２つが存在することになる。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

図１は、本発明の実施の形態にかかるファイルバックアップ・共有制御サーバを含むシステム全体の構成を示すブロックダイヤグラムである。 図２（ａ）は制御サーバの構成を示すブロックダイヤグラム、図２（ｂ）は、クライアントＰＣの構成を示すブロックダイヤグラムである。 図３は、本実施の形態にかかるノード基本情報テーブルのデータ構成を示す図である。 図４は、本実施の形態にかかる所有ディレクトリ情報テーブルのデータ構成を示す図である。 図５は、本実施の形態にかかる利用ディレクトリ情報テーブルのデータ構成を示す図である。 図６（ａ）は、本実施の形態にかかるオンラインノード管理テーブルのデータ構成を示す図、図６（ｂ）は、所有者パス情報テーブルのデータ構成を示す図である。 図７（ａ）は、本実施の形態にかかる実ファイル情報テーブルのデータ構成を示す図、図７（ｂ）は、実ファイル世代情報テーブルのデータ構成を示す図である。 図８は、クライアントＰＣと、制御サーバとの間で、ファイルを比較した結果の態様を示す表である。 図９は、ファイル所有者のクライアントＰＣにおけるファイルのダウンロードおよびアップロードに関する同期(Sync)処理を示すフローチャートである。 図１０（ａ）、（ｂ）は、それぞれ、ファイルのアップロード処理を示す風呂チャートである。 図１１は、制御サーバを、クライアントＰＣのファイルバックアップ装置として使用する場合の処理を説明するための図である。 図１２は、チームで作業をする場合の、クライアントＰＣおよび制御サーバにて実行される処理を説明するための図である。 図１３は、チームで作業をする場合の、クライアントＰＣおよび制御サーバにて実行される処理を説明するための図である。 図１４は、チームで作業をする場合の、クライアントＰＣにおけるファイルの凍結作業と次のフェーズの作業開始を示すフローチャートである。

符号の説明

１０ 制御サーバ
１２ クライアントＰＣ
１４ ネットワーク
１６ メールサーバ
２０ ＤＢ
２２ 条件判断部（センター条件判断部）
２４ ファイル管理部（センターファイル管理部）
３０ 記憶装置
３２ 条件判断部（ローカル条件判断部）
３４ ファイル管理部（ローカルファイル管理部）

Claims (9)

1. 自己が所有するファイルが格納されたディレクトリパス、ディレクトリ名を含むレコードを有する所有ディレクトリ情報テーブルと、
   前記ディレクトリパスおよびディレクトリ名にて特定されるファイルと、を格納する第１の記憶装置、並びに、
   前記ファイルのネットワークを介したアップロードおよびダウンロードを管理するローカルファイル管理手段を有するクライアントコンピュータと、
   ファイル所有者のノード名、ファイル名、当該ファイルが格納されたディレクトリパスを含むレコードを有する実ファイル情報テーブルと、
   ファイル名、ファイルのタイムスタンプ、ファイルの内容を示す情報を含むレコードを有する実ファイル世代情報テーブルと、
   前記ファイルと、を格納する第２の記憶装置、
   前記ローカルファイル管理手段からネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す値を含むファイル基本属性情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルのレコードの対応する値を参照して、
   ディレクトリパスおよびファイル名にて特定されるファイルについて、前記クライアントコンピュータの第１の記憶装置に格納されたファイルが、制御サーバの第２の記憶装置に格納されたファイルよりも新しい場合には、前記クライアントコンピュータが、前記制御サーバに前記ファイルをアップロードし、その一方、
   前記ファイルについて、前記クライアントコンピュータの第１の記憶装置に格納されたファイルが、前記制御サーバの第２の記憶装置に格納されたファイルよりも古い場合には、前記クライアントコンピュータが、前記制御サーバから前記ファイルをダウンロードする、という条件の下で、前記ファイルに関するダウンロード或いはアップロードの是非を判断し、判断結果を、前記クライアントコンピュータに送信するセンター条件判断手段、並びに、
   前記クライアントコンピュータからの要求にしたがって、アップロードされたファイルを、前記第２の記憶装置中、所定のディレクトリパスに格納し、また、所定のディレクトリパスに格納されたファイルを、前記クライアントコンピュータにダウンロードするセンターファイル管理手段を有する前記制御サーバとを備え、
   前記クライアントコンピュータが、前記判断結果にしたがって、前記ファイルのダウンロード或いはアップロードを、前記制御サーバに対して要求するローカル条件判断手段を有することを特徴とするファイル共有制御システム。
2. さらに、クライアントコンピュータが、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルを有し、
   前記ローカルファイル管理手段が、利用ディレクトリ情報テーブルに基づいて、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報を送信し、
   前記制御サーバのセンター条件判断手段が、ローカル管理手段からネットワークを介して送付された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブル、および、実ファイル世代情報テーブルを参照して、前記条件の下で、前記ファイルに関するダウンロード或いはアップロードの是非を判断し、判断結果を送信し、
   前記クライアントコンピュータのローカル条件判断手段が、前記判断結果にしたがって、前記ファイルのダウンロード或いはアップロードを、前記制御サーバに対して要求することを特徴とする請求項１に記載のファイル共有制御システム。
3. 前記第２の記憶装置が、前記ファイル所有者のノード名、前記ディレクトリ名、ファイルの公開の可否を示す公開フラグ、および、公開が可能である場合のファイルの更新の可否を示す公開タイプ情報を含むレコードを有する所有者パス情報テーブルを格納し、
   前記第１の記憶装置の、前記所有ディレクトリ情報テーブルのレコードが、ファイルの公開の可否を示す公開フラグ、公開が可能である場合のファイルの更新の可否を示す公開タイプ情報を含み、
   前記センター条件判断手段が、前記所有者パス情報テーブルのレコード中、前記公開フラグおよび前記公開タイプ情報を参照して、前記ファイルに関するダウンロード或いはアップロードの是非を判断することを特徴とする請求項２に記載のファイル共有制御システム。
4. 前記センター条件判断手段が、前記ファイルの内容を示す情報が一致する場合には、前記タイムスタンプが相違する場合にも、前記クライアントコンピュータの第１の記憶装置に格納されたファイルと、制御サーバの第２の記憶装置に格納されたファイルとが一致すると判断し、前記判断結果として、ダウンロード或いはアップロードが不要であることを前記クライアントコンコンピュータに送信することを特徴とする請求項１ないし３の何れか一項に記載のファイル共有情報システム。
5. 前記ファイルの内容を示す情報が、ファイルのハッシュ値であり、前記センター条件判断手段が、ハッシュ値を比較することにより、ファイルの内容の一致を判断することを特徴とする請求項４に記載のファイル共有制御システム。
6. ファイル所有者のノード名、ファイル名、当該ファイルが格納されたディレクトリパスを含むレコードを有する実ファイル情報テーブルと、
   前記ファイル名、前記ファイルのタイムスタンプ、前記ファイルの内容を示す情報を含むレコードを有する実ファイル世代情報テーブルと、を記憶した第２の記憶装置と、
   クライアントコンピュータが第１の記憶装置に格納した、自己が所有するファイルが格納されたディレクトリパス、ディレクトリ名を含むレコードを有する所有ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルのレコードの対応する値を参照して、
   ディレクトリパスおよびファイル名にて特定されるファイルについて、前記クライアントコンピュータの第１の記憶装置に格納されたファイルが、制御サーバの第２の記憶装置に格納されたファイルよりも新しい場合には、前記クライアントコンピュータが、前記制御サーバに前記ファイルをアップロードし、その一方、
   前記ファイルについて、前記クライアントコンピュータの第１の記憶装置に格納されたファイルが、前記制御サーバの第２の記憶装置に格納されたファイルよりも古い場合には、前記クライアントコンピュータが、前記制御サーバから前記ファイルをダウンロードする、という条件の下で、前記ファイルに関するダウンロード或いはアップロードの是非を判断し、判断結果を、前記クライアントコンピュータに送信するセンター条件判断手段、並びに、
   前記クライアントコンピュータからの要求にしたがって、アップロードされたファイルを、前記第２の記憶装置中、所定のディレクトリパスに格納し、また、所定のディレクトリパスに格納されたファイルを、前記クライアントコンピュータにダウンロードするセンターファイル管理手段を備え、
   前記クライアントコンピュータからの、前記判断結果にしたがった前記ファイルのダウンロード或いはアップロードの要求に応じて、前記センターファイル管理手段が、前記ファイルをダウンロード或いはアップロードすることを特徴とするファイル共有制御サーバ。
7. 前記センター条件判断手段が、クライアントコンピュータが第１の記憶装置に格納した、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記条件の下で、前記ファイルに関するダウンロード或いはアップロードの是非を判断し、判断結果を、前記クライアントコンピュータに送信することを特徴とする請求項６に記載のファイル共有制御サーバ。
8. ファイル所有者のノード名、ファイル名、当該ファイルが格納されたディレクトリパスを含むレコードを有する実ファイル情報テーブルと、前記ファイル名、前記ファイルのタイムスタンプ、前記ファイルの内容を示す情報を含むレコードを有する実ファイル世代情報テーブルと、を格納しだ第２の記憶装置を備えたコンピュータにより読み出し可能なプログラムであって、前記コンピュータを、
   クライアントコンピュータが第１の記憶装置に格納した、自己が所有するファイルが格納されたディレクトリパス、ディレクトリ名を含むレコードを有する所有ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、ファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本属性情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルのレコードの対応する値を参照して、
   ディレクトリパスおよびファイル名にて特定されるファイルについて、前記クライアントコンピュータの第１の記憶装置に格納されたファイルが、制御サーバの第２の記憶装置に格納されたファイルよりも新しい場合には、前記クライアントコンピュータが、前記制御サーバに前記ファイルをアップロードし、その一方、
   前記ファイルについて、前記クライアントコンピュータの第１の記憶装置に格納されたファイルが、前記制御サーバの第２の記憶装置に格納されたファイルよりも古い場合には、前記クライアントコンピュータが、前記制御サーバから前記ファイルをダウンロードする、という条件の下で、前記ファイルに関するダウンロード或いはアップロードの是非を判断し、判断結果を、前記クライアントコンピュータに送信するセンター条件判断手段、並びに、
   前記クライアントコンピュータからの要求にしたがって、アップロードされたファイルを、前記第２の記憶装置中、所定のディレクトリパスに格納し、また、所定のディレクトリパスに格納されたファイルを、前記クライアントコンピュータにダウンロードするセンターファイル管理手段であって、クライアントコンピュータから前記判断結果にしたがった前記ファイルのダウンロード或いはアップロードの要求に応じて、前記ファイルをダウンロード或いはアップロードするセンターファイル管理手段として機能させることを特徴とするファイル共有制御プログラム。
9. 前記コンピュータを、センター条件判断手段として機能させる際に、クライアントコンピュータが第１の記憶装置に格納した、利用したいファイルを所有する他のクライアントコンピュータのノード名、ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルに基づき、前記クライアントコンピュータにて生成され、かつ、ネットワークを介して送信された、利用するファイルのファイル名、ディレクトリパス、ファイルのタイムスタンプ、および、ファイルの内容を示す情報を含むファイル基本情報に基づき、前記実ファイル情報テーブルおよび実ファイル世代情報テーブルを参照して、前記条件の下で、前記ファイルに関するダウンロード或いはアップロードの是非を判断し、判断結果を、前記クライアントコンピュータに送信するように、前記コンピュータを動作させることを特徴とする請求項８に記載のファイル共有制御プログラム。
   
   

Images