JP2007293433A

JP2007293433A - 文書管理システム

Info

Publication number: JP2007293433A
Application number: JP2006118055A
Authority: JP
Inventors: Yoshiaki Sato; 吉明佐藤
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2006-04-21
Filing date: 2006-04-21
Publication date: 2007-11-08

Abstract

【課題】本発明は、サーバ／クライアント型の文書管理を効率的かつ適切に行う文書管理システムに関する。
【解決手段】文書管理システム１は、サーバ１０が、クライアント２０からの文書要求に応じて文書構成ファイルを提供すると、提供先のクライアント２０を特定する構成ファイル履歴テーブルを文書ファイル毎に作成し、クライアント２０からファイル名を指定した文書要求があると、指定ファイルに対応する構成ファイル保存クライアントテーブルを作成して当該クライアント２０に送信し、また、各クライアント２０が、取得した文書構成ファイルを蓄積して、構成ファイル保存クライアントテーブルを取得すると、構成ファイル保存クライアントテーブルに基づいて、取得対象の文書構成ファイルを蓄積する他のクライアント２０を特定して文書要求を行い、文書構成ファイルを取得する。
【選択図】図４

Description

本発明は、文書管理システムに関し、詳細には、サーバ／クライアント型の文書管理を効率的かつ適切に行う文書管理システムに関する。

近年、ワードプロセッサやＤＴＰソフト等の情報処理装置の普及に伴って、多くの文書が電子的に作成されたり、紙の文書がスキャナで読み取られて、電子文書ファイルとして管理されている。

このような文書ファイルの管理としては、従来、Peer to Peer（Ｐ２Ｐ）技術を利用した文書管理システムとクライアント／サーバ型文書管理システムとがある。Ｐ２Ｐ技術を利用した文書管理システムは、個人のコンピュータ上のファイル資源の共有を主とした文書管理プログラムが多く存在しており、このＰ２Ｐを利用した文書管理プログラムでは、特定の文書ファイル自体を共有して、拡散することで、仮想的な大規模蓄積領域を得ることを目的としている。このＰ２Ｐ技術を用いた文書管理においては、各コンピュータの情報を束ねるために、特別なサーバコンピュータ環境を必要とするものや個別のコンピュータ同士が自立的に情報を交換拡散してそれを必要としないものも存在する。また、Ｐ２Ｐ技術を用いた文書管理においては、拡散されたファイル資源の一部が複数のコンピュータ上に存在して多重化されていることから、複数のファイル資源提供元からの並列供給を行うことができ、ファイル資源提供性能の向上という利点を有している。他方、クライアント／サーバ型の文書管理システムにおいては、サーバがファイル資源を実蓄積領域に蓄積し、また、蓄積情報を検索を提供するための機能を提供し、クライアントがそれらを利用するという方法をとっている（特許文献１参照）。

特開２００４−１０２８２１号公報

しかしながら、上記従来のクライアント／サーバ型の文書管理システムにあっては、サーバへのファイル資源要求が集中すると、処理能力が不足することとなり、処理能力を補強するためには、強力なサーバ性能やネットワークの性能が必要となり、コストが高くつくという問題があった。

そこで、本発明は、サーバ性能や通信性能に関わらず、安価にかつ効率的にサーバの蓄積する文書ファイルを管理する文書管理システムを提供することを目的としている。

請求項１記載の発明の文書管理システムは、サーバが、少なくとも１つ以上の文書構成ファイルを有する文書ファイルをデータベースに複数蓄積して管理し、クライアントからの文書要求に応じて、当該蓄積する文書構成ファイルを提供する文書管理システムにおいて、前記サーバは、前記クライアントからのファイルを指定した文書要求に応じて当該指定されている文書構成ファイルを提供すると、当該文書構成ファイルの提供先の前記クライアントを特定する文書取得履歴リストを文書ファイル毎であってかつ当該文書ファイルの文書構成ファイル毎に作成するとともに、当該文書取得履歴リストの当該文書要求で指定されている文書構成ファイルに対応するリストを文書保持リストとして作成して当該クライアントに送信し、前記各クライアントは、前記取得した文書構成ファイルを所定の記憶手段に蓄積し、前記文書保持リストを取得したクライアントは、当該文書保持リストに基づいて、取得を意図する文書構成ファイルを蓄積する他のクライアントを特定し、当該他のクライアントに対して文書要求を行って、当該クライアントから当該文書構成ファイルを取得して文書ファイルを再構築することにより、上記目的を達成している。

この場合、例えば、請求項２に記載するように、前記サーバは、前記文書取得履歴リストに各文書構成ファイルのハッシュ値をも登録し、前記クライアントは、前記文書構成ファイルとともに当該文書構成ファイルのハッシュ値を当該サーバから取得して前記記憶手段に蓄積し、また、当該ハッシュ値を含む前記文書保持リストを前記サーバから取得し、前記他のクライアントへの文書要求によって、当該他のクライアントから前記文書構成ファイルとともに当該文書構成ファイルの前記ハッシュ値を取得し、前記サーバから取得したハッシュ値と当該他のクライアントから取得した前記ハッシュ値を比較して当該他のクライアントから取得した文書構成ファイルの適否を検証してもよい。

また、例えば、請求項３に記載するように、前記サーバは、前記文書取得履歴リストに各文書構成ファイルのハッシュ値をも記憶し、前記クライアントは、前記文書構成ファイルとともに当該文書構成ファイルのハッシュ値を当該サーバから取得して前記記憶手段に蓄積し、また、当該ハッシュ値を含む前記文書保持リストを前記サーバから取得し、前記他のクライアントへの文書要求において、当該文書要求にかかる文書構成ファイルのハッシュ値を送り、当該他のクライアントは、前記記憶手段に蓄積している当該文書要求のあった文書構成ファイルのハッシュ値と当該文書要求とともに送られてきたハッシュ値を比較して当該文書構成ファイルの適否を検証し、当該文書構成ファイルが適正であると、当該文書構成ファイルを当該文書要求を行ってきたクライアントに送信してもよい。

さらに、例えば、請求項４に記載するように、前記他のクライアントに文書要求を行ったクライアントは、当該文書要求に失敗すると、当該他のクライアントを特定した文書取得失敗情報を前記サーバに送信し、前記サーバは、前記文書取得履歴リストから当該文書取得失敗情報に対応する文書構成ファイルに対して登録されている当該他のクライアントを削除してもよい。

また、例えば、請求項５に記載するように、前記サーバは、前記クライアントを任意のグループ毎にグループ分けし、前記文書取得履歴リストを当該グループ毎に管理して、前記クライアントから文書要求があると、当該文書要求をしてきたクライアントの属するグループに対して登録されている当該文書要求にかかる文書ファイルの文書保持リストを作成して送信してもよい。

さらに、例えば、請求項６に記載するように、前記サーバは、前記文書取得履歴リストに登録した文書ファイルまたは文書構成ファイルが無効になると、当該文書ファイルまたは当該文書構成ファイルの前記文書取得履歴リストを削除するとともに、当該文書ファイルの文書要求を行ってきた各クライアントに対して、当該文書構成ファイルの削除を指示し、当該削除指示を受けたクライアントが、当該削除指示に対応する文書構成ファイルを前記記憶手段から削除してもよい。

また、例えば、請求項７に記載するように、前記クライアントは、前記記憶手段の文書構成ファイルの蓄積容量の上限容量が予め設定されており、前記サーバから取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、新たな文書構成ファイルの蓄積を中止してもよい。

さらに、例えば、請求項８に記載するように、前記クライアントは、前記記憶手段の文書構成ファイルの蓄積容量の上限容量が予め設定されており、前記サーバから取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、当該蓄積している文書構成ファイルのうち、蓄積順の最も古い文書構成ファイルから順次削除して、新たな文書構成ファイルの蓄積を行ってもよい。

また、例えば、請求項９に記載するように、前記クライアントは、前記記憶手段の文書構成ファイルの蓄積容量の上限容量が予め設定されており、前記サーバから取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、当該蓄積している文書構成ファイルのうち、他のクライアントからの文書要求数の多い順であって、かつ、蓄積順の古い文書構成ファイルから順次削除して、新たな文書構成ファイルの蓄積を行ってもよい。

さらに、例えば、請求項１０に記載するように、前記クライアントは、前記文書構成ファイルの蓄積容量が前記上限容量に到達して、前記蓄積を拒否した文書構成ファイル、または、前記削除した文書構成ファイルを前記サーバに通知し、当該サーバが、当該文書構成ファイルまたは当該クライアントの前記文書取得履歴リストへの登録を中止または当該クライアントを前記文書取得履歴リストから削除してもよい。

本発明の文書管理システムによれば、サーバが、クライアントからの文書要求に応じて文書構成ファイルを提供すると、当該文書構成ファイルの提供先のクライアントを特定する文書取得履歴リストを文書ファイル毎であってかつ当該文書ファイルの文書構成ファイル毎に作成するとともに、当該文書取得履歴リストの当該文書要求で指定されている文書構成ファイルに対応するリストを文書保持リストとして作成して当該クライアントに送信し、各クライアントが、取得した文書構成ファイルを蓄積して、文書保持リストを取得したクライアントが、当該文書保持リストに基づいて、取得を意図する文書構成ファイルを蓄積する他のクライアントを特定して、当該他のクライアントに対して文書要求を行い、当該クライアントから当該文書構成ファイルを取得するので、クライアントによっても文書ファイルを提供して、サーバにのみ文書要求が集中するのを防止することができ、サーバ性能や通信性能に関わらず、安価にかつ効率的に文書を管理することができる。

以下、本発明の好適な実施例を添付図面に基づいて詳細に説明する。なお、以下に述べる実施例は、本発明の好適な実施例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。

図１〜図９は、本発明の文書管理システムの一実施例を示す図であり、図１は、本発明の文書管理システムの一実施例を適用した文書管理システム１のシステム構成図である。

図１において、文書管理システム１は、複数のサーバ１０とクライアント２０が図示しないＬＡＮ（Local Area Network）、インターネット等の所定の通信経路で相互に接続されており、各サーバ１０とクライアント２０が通信経路を介して相互にデータの送受信を行う。

サーバ１０は、通常のハードウェア構成に、ディスプレイ、キーボード、マウス等の入力部等を備えた一般的なサーバが用いられているとともに、その機能構成として、文書管理サーバ機能モジュール１１、構成ファイルリスト保存機能モジュール１２及び無効構成ファイル削除指示機能モジュール１３等の文書管理機能モジュール１４を備えており、この文書管理機能モジュール１４は、ＣＤ（Compact Disc）、ＣＤ−ＲＷ（Compact Disc Rewritable ）、フレキシブルディスク等の記録媒体に記録されている文書管理プログラムを読み込んで導入することで、構築されている。

文書管理サーバ機能モジュール１１は、図示しないハードディスク等のデータベースに文書ファイルを蓄積する文書蓄積機能、文書検索機能、文書削除機能及び文書更新機能等の通常のサーバ１０としての機能を実現するための機能を備えており、文書ファイルの蓄積、検索、削除、更新等の処理を行う。この文書ファイルは、文書の実体である１つ以上の文書構成ファイルとその属性等から構成されており、この属性としては、例えば、文書名、作成者、作成日等であり、この属性として、ハッシュ値を有していてもよい。

構成ファイルリスト保存機能モジュール１２は、上記文書管理サーバ機能モジュール１１がデータベースに蓄積する文書ファイル毎に、当該文書ファイルを構成する文書構成ファイルと文書属性及び当該文書構成ファイルを取得したクライアント２０を特定するクライアント情報をリスト化して、構成ファイル履歴テーブル（文書取得履歴リスト）１４（図２参照）としてデータベースに保存し、また、このクライアント２０を任意のグループ毎にグループ化して当該グループ毎に構成ファイル履歴テーブル１４を作成して管理するグループ化機能等を備えている。

この構成ファイルリスト保存機能モジュール１２は、例えば、図２に示すような構成ファイル履歴テーブル１４をサーバ１０のデータベースに格納しており、構成ファイル履歴テーブル１４には、図２の場合、ファイル名、ハッシュ値及び取得クライアントリスト等が文書ファイル毎に、かつ、文書構成ファイル毎に各レコードに割り振られて記録されている。すなわち、この構成ファイル履歴テーブル１４は、グループ分けされたクライアント２０の各グループに属する全てのクライアント２０の取得した全ての文書構成ファイルの履歴を記録し、クライアント２０からの取得実績によりレコードまたは取得クライアントリストが追加される。

無効構成ファイルの削除指示機能モジュール１３は、文書構成ファイルの元文書ファイルが無効となった場合や取得クライアント２０が「０」になった場合に、該当するレコードの削除を構成ファイルリスト保存機能モジュール１２に指示し、構成ファイルリスト保存機能モジュール１２は、構成ファイル履歴テーブル１４の該当するレコードを削除する。

クライアント２０は、通常のハードウェア構成に、ディスプレイ、キーボード、マウス等の入力部及び図示しないハードディスクやキャッシュ等のメモリ（記憶手段）等を備えた一般的なパーソナルコンピュータ等が用いられているとともに、その機能構成として、文書管理クライアント機能モジュール２１、構成ファイル保存機能モジュール２２、構成ファイル保持クライアント取得機能モジュール２３、構成ファイル提供機能モジュール２４及び文書再構築機能モジュール２５等の文書管理機能モジュール２６を備えており、この文書管理機能モジュール２６は、ＣＤ、ＣＤ−ＲＷ、フレキシブルディスク等の記録媒体に記録されている文書管理プログラムを読み込んで導入することで、構築されている。

文書管理クライアント機能モジュール２１は、通常の文書の管理・編集に必要な機能モジュールであり、文書取得機能、文書表示機能、検索指示機能及び削除指示機能等を備えている。文書管理クライアント機能モジュール２１は、サーバ１０や他のクライアント２０に対して文書ファイルや文書構成ファイルを、当該ファイル名を指定して文書要求を行い、当該サーバ１０やクライアント２０から文書構成ファイルを取得するとともに、構成ファイル履歴テーブル１４から作成される当該文書構成ファイルの構成ファイル保存クライアントテーブル２６（図３参照）を取得する。

構成ファイル保存機能モジュール２２は、キャッシュ機能、上限制限機能及びキャッシュ削除機能等を備えており、キャッシュ機能で、サーバ１０や他のクライアント２０から取得した文書ファイルや文書構成ファイル及び構成ファイル保存クライアントテーブル２６をハードディスクやキャッシュ等のメモリ（なお、以下の説明では、キャッシュという。）に蓄積を行い、そのキャッシュ削除機能で、不要となった文書ファイルや文書構成ファイル及び構成ファイル保存クライアントテーブル２６の削除を行う。また、構成ファイル保存機能モジュール２２は、上限制限機能で、キャッシュの容量管理を行う。すなわち、構成ファイル保存機能モジュール２２の上限制限機能は、サーバ１０や他のクライアント２０から取得した文書ファイルや文書構成ファイル及び構成ファイル保存クライアントテーブル２６（以下、適宜、文書ファイル等という。）のキャッシュへの蓄積容量が、予め設定されているキャッシュの上限容量に到達すると、新たな文書ファイル等の蓄積を中止し、また、キャッシュ削除機能で、所定の削除順序でキャッシュの文書ファイル等の削除を行って、新たな文書ファイル等の蓄積を行う。この構成ファイル保存機能モジュール２２のキャッシュ削除機能での文書ファイル等の削除は、蓄積順の最も古い順に削除し、また、他のクライアント２０からの文書要求数の多い順であって、かつ、蓄積順の古い順に行う。

上記構成ファイル保存機能モジュール２２は、サーバ１０や他のクライアント２０から取得した構成ファイル保存クライアントテーブル、例えば、図３に示すような構成ファイル保存クライアントテーブル２６をクライアント２０のキャッシュに格納しており、構成ファイル保存クライアントテーブル２６には、図３の場合、文書構成ファイルのファイル名、ハッシュ値及び取得クライアントリスト等が各レコード毎に記録されている。この構成ファイル保存クライアントテーブル２６は、後述するように、サーバ１０が構成ファイル履歴テーブル１４に基づいて作成して、送信されるものである。

構成ファイル保持クライアント取得機能モジュール２３は、キャッシュの構成ファイル保存クライアントテーブル２６から取得を意図する文書構成ファイルを蓄積している他のクライアント２０を特定して、当該他のクライアント２０に対して文書要求を行う。

構成ファイル提供機能モジュール２４は、ハッシュ値確認機能等を備えており、他のクライアント２０からの文書要求に応じて、文書構成ファイルを当該クライアント２０に提供する。構成ファイル提供機能モジュール２４は、そのハッシュ値確認機能で、ハッシュ値に基づいて、他のクライアント２０に提供する文書構成ファイルの適否の判定と当該文書構成ファイルの送信制御を判定を行う。

文書再構築機能モジュール２５は、ハッシュ値確認機能等を備えており、取得した文書構成ファイルと文書属性に基づいて元文書ファイルを再構築するとともに、そのハッシュ値確認機能で、ハッシュ値に基づいて、当該取得した文書構成ファイルの適否を判定する。なお、ハッシュ値は、与えられた原文から固定長の疑似乱数を生成する演算手法であるハッシュ関数によって生成された値である。

次に、本実施例の作用を説明する。本実施例の文書管理システム１は、各クライアント２０がサーバ１０から取得した文書構成ファイルをキャッシュに保持するとともに、サーバ１０から当該文書構成ファイルの構成ファイル保持クライアントテーブル２６を取得し、当該構成ファイル保持クライアントテーブル２６に基づいて、意図する文書構成ファイルを保持する他のクライアント２０を特定して、当該他のクライアント２０から文書構成ファイルを取得する。

なお、以下の説明では、サーバ１０が、各クライアント２０を予め任意のグループ毎にグループ分けし、当該グループによって提供する構成ファイル保存クライアントテーブル２６を選択・制御するグループ管理を行っている場合について説明する。

いま、図４に示すように、クライアント２０ａが、サーバ１０に対して、文書ファイルのファイル名、例えば、図４では、文書ファイルＢ１を指定した文書要求を行って文書の取得を要求すると、サーバ１０は、データベースに蓄積している複数の文書ファイルのなかから文書要求された文書ファイルＢ１の属性と構成ファイル（Ｆｉｌｅ１〜Ｆｉｌｅ３）を読み出し、図５に示すように、構成ファイル保存クライアントテーブル２６の作成・送信を行う。

すなわち、サーバ１０は、クライアント２０ａから文書ファイルを指定した文書要求があると、データベースに蓄積している指定文書ファイルの属性情報を取得し（ステップＳ１０１）、当該属性情報から指定文書ファイルの文書構成ファイルとそのハッシュ値のリストを取得する（ステップＳ１０２）。

次に、サーバ１０は、クライアント２０ａに提供するための空の構成ファイル保存クライアントテーブル２６を作成し（ステップＳ１０３）、データベースから当該文書要求してきたクライアント２０の属するグループの構成ファイル履歴テーブル１４を取得して（ステップＳ１０４）、ステップＳ１０２で取得した指定文書ファイルの文書構成ファイルリストに未処理要素があるかチェックする（ステップＳ１０５）。

ステップＳ１０５で、上記取得した指定文書ファイルの文書構成ファイルリストに未処理要素（未処理文書構成ファイル）があると、サーバ１０は、未処理要素の取得を行い（ステップＳ１０６）、構成ファイル履歴テーブル１４に当該未処理要素と同一ハッシュ値の要素があるかチェックする（ステップＳ１０７）。

ステップＳ１０７で、同一ハッシュ値の要素がないときには、サーバ１０は、当該取得した要素は不正であると判断して、ステップＳ１０５に戻って、上記同様に処理する（ステップＳ１０５〜Ｓ１０７）。

サーバ１０は、ステップＳ１０７で、同一ハッシュ値の要素があると、当該取得した要素は適正であると判断して、当該要素を構成ファイル保存クライアントテーブル２６に追加し（ステップＳ１０８）、ステップＳ１０５に戻って、上記同様に処理する（ステップＳ１０５〜Ｓ１０８）。

ステップＳ１０５で、当該取得した指定文書ファイルの文書構成ファイルリストの未処理要素がなくなると、サーバ１０は、作成した構成ファイル保存クライアントテーブル２６を当該文書要求をしてきたクライアント２０ａに送信して、処理を終了する（ステップＳ１０９）。

また、サーバ１０は、文書構成ファイルを特定した文書構成ファイルの取得を要求する文書要求がクライアント２０ａからあると（例えば、図４では、文書ファイルＢ１のＦｉｌｅ１を指定した文書要求があると）、サーバ１０は、データベースに蓄積している当該文書ファイルの文書構成ファイルのなかから文書要求された文書ファイルＢ１の属性と文書構成ファイル（Ｆｉｌｅ１）を読み出して、当該クライアント２０ａに送信するとともに、図６に示すように、構成ファイル履歴テーブル１４の更新処理を行う。

すなわち、サーバ１０は、文書構成ファイルを特定した文書要求がクライアント２０ａからあると、図６に示すように、当該要求クライアント２０ａの属するグループの構成ファイル履歴テーブル１４をデータベースから取得し（ステップＳ２０１）、指定の文書構成ファイルが当該取得した構成ファイル履歴テーブル１４に含まれているかチェックする（ステップＳ２０２）。

ステップＳ２０２で、指定の文書構成ファイルが構成ファイル履歴テーブル１４に含まれていないときには、サーバ１０は、当該構成ファイル履歴テーブル１４に指定の文書構成ファイルの要素を追加し（ステップＳ２０３）、当該構成ファイル履歴テーブル１４の当該文書構成ファイルの取得クライアントリストの欄に、当該文書要求を行ってきたクライアント２０ａを追加して、処理を終了する（ステップＳ２０４）。

ステップＳ２０２で、指定の文書構成ファイルが構成ファイル履歴テーブル１４に含まれているときには、サーバ１０は、文書要求を行ってきたクライアント２０ａが当該構成ファイル履歴テーブル１４の当該文書構成ファイルの取得クライアントリストの欄に含まれているかチェックし（ステップＳ２０５）、含まれていないときには、当該構成ファイル履歴テーブル１４の当該文書構成ファイルの取得クライアントリストの欄に、当該文書要求を行ってきたクライアント２０ａを追加して、処理を終了する（ステップＳ２０４）。

ステップＳ２０５で、文書要求を行ってきたクライアント２０ａが当該構成ファイル履歴テーブル１４の当該文書構成ファイルの取得クライアントリストの欄に含まれているときには、サーバ１０は、当該クライアント２０ａが既に登録されていて追加する必要がないと判断して、処理を終了する。

そして、文書要求をサーバ１０に行ったクライアント２０ａは、図７に示すように文書取得処理を行う。すなわち、クライアント２０ａは、文書要求を行うと、当該取得文書ファイルの構成ファイル保存クライアントテーブル２６と属性をサーバ１０から取得し（ステップＳ３０１）、当該取得した構成ファイル保存クライアントテーブル２６が空であるかチェックする（ステップＳ３０２）。

ステップＳ３０２で、構成ファイル保存クライアントテーブル２６が空であると、クライアント２０ａは、文書構成ファイルを蓄積している他のクライアント２０が存在しないので、全ての文書構成ファイルをサーバ１０から取得し（ステップＳ３０３）、当該取得した属性と文書構成ファイルから文書（文書ファイル）を再構築する（ステップＳ３０４）。

クライアント２０ａは、文書ファイルを再構築すると、取得した文書構成ファイルをキャッシュに登録して、処理を終了する（ステップＳ３０５）。

ステップＳ３０２で、構成ファイル保存クライアントテーブル２６が空でないときには、クライアント２０ａは、未処理の要素があるか、すなわち、未取得の文書構成ファイルがあるかチェックし（ステップＳ３０６）、未処理の要素があるときには、構成ファイル保存クライアントテーブル２６に基づいて、当該未処理要素の文書構成ファイルを蓄積している他のクライアント２０を特定して、当該未処理要素の文書構成ファイルを当該他のクライアント２０から取得する（ステップＳ３０７）。

クライアント２０ａは、他のクライアント２０からの文書構成ファイルの取得を行うと、当該クライアント２０からの文書構成ファイルの取得に成功したかチェックし（ステップＳ３０８）、文書構成ファイルの取得に成功すると、ステップＳ３０６に戻って、上記同様に処理する（ステップＳ３０６〜Ｓ３０８）。

ステップＳ３０８で、他のクライアント２０からの文書構成ファイルの取得に失敗すると、クライアント２０ａは、当該文書構成ファイルと当該文書構成ファイルの取得に失敗したクライアント２０を特定する旨をサーバ１０に通知する失敗通知処理を行い（ステップＳ３０９）、サーバ１０から当該取得に失敗した文書構成ファイルを取得して（ステップＳ３１０）、ステップＳ３０６に戻って、上記同様に処理する（ステップＳ３０６〜Ｓ３１０）。

すなわち、例えば、図８に示すように、文書ファイルＢ１の文書要求をサーバ１０に行ったクライアント２０ａは、サーバ１０から当該文書ファイルＢ１の構成ファイル保存クライアントテーブル２６と属性を取得し、当該構成ファイル保存クライアントテーブル２６が空であると、全ての文書構成ファイル（Ｆｉｌｅ１〜Ｆｉｌｅ３）をサーバ１０から取得して文書ファイルＢ１の再構築を行うが、構成ファイル保存クライアントテーブル２６が空でないとき、すなわち、文書構成ファイルを蓄積している他のクライアント２０ｂが登録されていると、当該構成ファイル保存クライアントテーブル２６で特定した他のクライアント２０ｂから全ての文書構成ファイルを取得できたときには、当該取得した文書構成ファイルで文書ファイルＢ１の再構築を行い、取得に失敗した文書構成ファイルがあると、当該文書構成ファイルについては、サーバ１０から当該取得に失敗した文書構成ファイルを取得して、文書ファイルＢ１の再構築を行う。なお、図８では、文書ファイルＢ１を構成する文書構成ファイルＦｉｌｅ１〜Ｆｉｌｅ３のうち、文書構成ファイルＦｉｌｅ２と文書構成ファイルＦｉｌｅ３については他のクライアント２０ｂから取得し、文書構成ファイルＦｉｌｅ１については、サーバ１０から取得して、文書ファイルＢ１を再構築して、再構築した文書構成ファイルＢ１をキャッシュに登録している例を示している。

そして、各クライアント２０は、キャッシュの管理処理を、図９に示すように行う。すなわち、クライアント２０は、文書構成ファイルのキャッシュ登録タイミングになると、図９に示すように、登録対象の文書構成ファイルのファイルサイズを取得し（ステップＳ４０１）、次に、現在のキャッシュの総サイズ（使用済み総サイズ）を取得する（ステップＳ４０２）。

そして、クライアント２０は、上記取得した登録対象の文書構成ファイルのサイズと現在のキャッシュの総サイズを加算した加算サイズが、予め設定されているキャッシュの上限サイズ（上限容量）以下であるかチェックし（ステップＳ４０３）、以下であると、キャッシュの容量に余裕があると判断して、当該登録対象の文書構成ファイルをキャッシュに登録して処理を終了する（ステップＳ４０４）。

ステップＳ４０３で、上記加算サイズが上限サイズを超えていると、クライアント２０は、キャッシュから削除する文書構成ファイルを選択し（ステップＳ４０５）、当該選択した文書構成ファイルをキャッシュから削除する（ステップＳ４０６）。

そして、クライアント２０は、このキャッシュから削除する文書構成ファイルの選択は、例えば、キャッシュ登録順（蓄積順）の最も古い文書構成ファイル、または、キャッシュ登録（蓄積）されている文書構成ファイルのうち、他のクライアント２０からの文書要求数の多い順であって、かつ、登録順の古い文書ファイルから順次削除対象とする。

クライアント２０は、文書構成ファイルをキャッシュから削除すると、当該文書構成ファイルを削除した旨の削除通知をサーバ１０に行い（ステップＳ４０７）、ステップＳ４０２に戻って、現在のキャッシュの総サイズの取得から上記同様に処理して、ステップＳ４０３で、文書構成ファイルのキャッシュからの削除によって上記加算サイズが上限サイズ以下となると、当該登録対象の文書構成ファイルをキャッシュに登録して処理を終了する（ステップＳ４０４）。

そして、サーバ１０は、クライアント２０から文書構成ファイルの削除通知を受け取ると、構成ファイル履歴テーブル１４の当該削除通知のあった文書構成ファイルの取得クライアントリストの欄から当該削除通知を行ってきたクライアント２０を削除する。このとき、当該文書構成ファイルの取得クライアントリストに、当該削除通知をしてきたクライアント２０のみが登録されていて、当該クライアント２０を削除すると、取得クライアントリストが空になるときには、当該文書構成ファイルのレコードを削除する。

このように、本実施例の文書管理システム１は、サーバ１０が、クライアント２０からの文書要求に応じて文書構成ファイルを提供すると、当該文書構成ファイルの提供先のクライアント２０を特定する構成ファイル履歴テーブル（文書取得履歴リスト）１４を文書ファイル毎に作成し、クライアント２０からファイル名を指定した文書要求があると、当該指定のファイルに対応する構成ファイル保存クライアントテーブル２６を作成して当該クライアント２０に送信し、また、各クライアント２０が、取得した文書構成ファイルを蓄積して、構成ファイル保存クライアントテーブル２６を取得したクライアント２０が、当該構成ファイル保存クライアントテーブル２６に基づいて、取得を意図する文書構成ファイルを蓄積する他のクライアント２０を特定して、当該他のクライアント２０に対して文書要求を行って、当該クライアント２０から当該文書構成ファイルを取得している。

したがって、クライアント２０によっても文書ファイルや文書構成ファイルを提供することができるとともに、サーバ２０にのみ文書要求が集中するのを防止することができ、サーバ性能や通信性能に関わらず、安価にかつ効率的に文書ファイルを管理することができる。

すなわち、クライアント２０でサーバ１０の文書資源の一部である文書構成ファイルを多重化して提供することで、サーバ機能の補強を行うことなく、資源の提供性能を向上させることができる。

また、本実施例の文書管理システム１は、他のクライアント２０に文書要求を行ったクライアント２０は、当該文書要求に失敗すると、当該他のクライアント２０を特定した文書取得失敗情報をサーバ２０に送信し、サーバ２０が、構成ファイル履歴テーブル１４から当該文書取得失敗情報に対応する文書構成ファイルに対して登録されている当該他のクライアント２０を削除している。

したがって、構成ファイル履歴テーブル１４の正確性を向上させることができ、クライアント２０による無駄な文書要求等を防止して、利用性をより一層向上させることができる。

さらに、本実施例の文書管理システム１は、サーバ２０が、クライアント１０を任意のグループ毎にグループ分けし、構成ファイル履歴テーブル１４を当該グループ毎に管理して、クライアント２０から文書要求があると、当該文書要求をしてきたクライアント２０の属するグループに対して登録されている当該文書要求にかかる文書ファイルの構成ファイル履歴テーブル１４から構成ファイル保存クライアントテーブル２６を作成して送信している。

したがって、グループ外からの構成ファイル保存クライアントテーブル２６の不要な取得を防止することができ、グループ内でのセキュリティを確保することができる。

また、本実施例の文書管理システム１は、サーバ１０が、構成ファイル履歴テーブル１４に登録した文書ファイルや文書構成ファイルが無効になると、構成ファイル履歴テーブル１４から当該文書ファイルや当該文書構成ファイルを削除するとともに、当該ファイルの文書要求を行ってきた各クライアント２０に対して、当該文書構成ファイルの削除を指示し、当該削除指示を受けたクライアント２０が、当該削除指示に対応する文書構成ファイルをキャッシュから削除している。

したがって、無駄なファイルをキャッシュから削除することができ、キャッシュを有効利用することができる。

さらに、本実施例の文書管理システム１は、クライアント２０が、キャッシュの文書構成ファイル（文書ファイル等）の蓄積容量の上限容量が予め設定されており、サーバ１０から取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、新たな文書構成ファイルの蓄積を中止している。

したがって、文書構成ファイルの過剰な蓄積による負荷を抑制することができ、利用性を向上させることができる。

また、本実施例の文書管理システム１は、クライアント２０が、サーバ１０から取得した文書構成ファイルの蓄積容量がキャッシュの上限容量に到達すると、当該蓄積している文書構成ファイルのうち、蓄積順の最も古い文書構成ファイルから順次削除して、新たな文書構成ファイルの蓄積を行っている。

したがって、利用頻度の少ないと思われる文書構成ファイルを削除して、新たな文書構成ファイルを蓄積することができ、利用性を向上させることができる。

さらに、本実施例の文書管理システム１は、クライアント２０が、サーバ１０から取得した文書構成ファイルの蓄積容量がキャッシュの上限容量に到達すると、当該蓄積している文書構成ファイルのうち、他のクライアント２０からの文書要求数の多い順であって、かつ、蓄積順の古い文書構成ファイルから順次削除して、新たな文書構成ファイルの蓄積を行っている。

したがって、文書要求数が多く他のクライアント２０でも蓄積されている可能性が高く、かつ、利用頻度が低い文書構成ファイルを削除して、新たな文書構成ファイルを蓄積することができ、より一層利用性を向上させることができる。

また、本実施例の文書管理システム１は、クライアント２０が、文書構成ファイルの蓄積容量がキャッシュの上限容量に到達して、蓄積を拒否した文書構成ファイル、または、削除した文書構成ファイルをサーバ１０に通知し、サーバ１０が、当該文書構成ファイルまたは当該クライアント２０の構成ファイル履歴テーブル１４への登録を中止している。

したがって、構成ファイル履歴テーブル１４の内容を正確な状態に維持することができ、無駄な文書要求等の発生を防止して、利用性をより一層向上させることができる。

なお、上記説明において、各クライアント２０がハッシュ値に基づいて、文書構成ファイルの適否を判別して、文書構成ファイルの取得を制御してもよい。

すなわち、クライアント２０は、文書構成ファイルとともに当該文書構成ファイルのハッシュ値をサーバ１０から取得してキャッシュに登録し、ハッシュ値を含む構成ファイル保存クライアントテーブル２６をサーバ１０から取得すると、当該構成ファイル保存クライアントテーブル２６に基づいて、取得を意図する文書構成ファイルを蓄積する他のクライアント２０を特定して、当該他のクライアント２０に当該文書構成ファイルの文書要求を行って、当該他のクライアント２０から当該文書構成ファイルと当該文書構成ファイルのハッシュ値を取得し、サーバ１０から取得したハッシュ値と当該他のクライアント２０から取得したハッシュ値を比較して当該他のクライアント２０から取得した文書構成ファイルの適否を検証する。

このようにすると、適正な文書ファイルや文書構成ファイルを適切に取得することができ、文書の適正を向上させることができる。

また、クライアント２０は、ハッシュ値を含む構成ファイル保存クライアントテーブル２６をサーバ１０から取得すると、当該構成ファイル保存クライアントテーブル２６に基づいて、取得を意図する文書構成ファイルを蓄積する他のクライアント２０に対して、文書要求を行う際に、当該文書構成ファイルのハッシュ値を送り、当該他のクライアント２０が、キャッシュに登録している当該文書要求のあった文書構成ファイルのハッシュ値と当該文書要求とともに送られてきたハッシュ値から当該文書構成ファイルの適否を検証して、当該文書構成ファイルが適正であると判断すると、当該文書構成ファイルを当該文書要求を行ってきたクライアント２０に送信する。

このようにすると、文書構成ファイルを取得する前に、文書構成ファイルの適否を検証することができ、無駄な文書構成ファイルの送信を防止して、より一層利用性を向上させることができる。

以上、本発明者によってなされた発明を好適な実施例に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、サーバの蓄積する１つ以上の文書構成ファイルを有する文書ファイルをネットワーク等の通信回線を介してサーバとクライアントとで効率的に管理する文書管理システムに適用することができる。

本発明の文書管理システムの一実施例を適用した文書管理システムのシステム構成図。図１のサーバの格納している構成ファイル履歴テーブルの一例を示す図。図１のクライアントの格納している構成ファイル保存クライアントテーブルの一例を示す図。図１の文書管理システムによるクライアントがサーバに文書要求を行う際の文書管理処理の説明図。図１のサーバによる構成ファイル保存クライアントテーブルの作成・送信処理を示すフローチャート。図１のサーバによる構成ファイル履歴テーブルの更新処理を示すフローチャート。図１のクライアントによる文書取得処理を示すフローチャート。図１の文書管理システムによるクライアントがサーバと他のクライアントから文書構成ファイルを取得する文書管理処理の説明図。図１のクライアントによるキャッシュ管理処理を示すフローチャート。

符号の説明

１文書管理システム
１０サーバ
１１文書管理サーバ機能モジュール
１２構成ファイルリスト保存機能モジュール
１３無効構成ファイル削除指示機能モジュール
１４文書管理機能モジュール
２０、２０ａ、２０ｂクライアント
２１文書管理クライアント機能モジュール
２２構成ファイル保存機能モジュール
２３構成ファイル保持クライアント取得機能モジュール
２４構成ファイル提供機能モジュール
２５文書再構築機能モジュール
２６文書管理機能モジュール
Ｂ１文書（ファイル）

Claims

サーバが、少なくとも１つ以上の文書構成ファイルを有する文書ファイルをデータベースに複数蓄積して管理し、クライアントからの文書要求に応じて、当該蓄積する文書構成ファイルを提供する文書管理システムにおいて、前記サーバは、前記クライアントからのファイルを指定した文書要求に応じて当該指定されている文書構成ファイルを提供すると、当該文書構成ファイルの提供先の前記クライアントを特定する文書取得履歴リストを文書ファイル毎であってかつ当該文書ファイルの文書構成ファイル毎に作成するとともに、当該文書取得履歴リストの当該文書要求で指定されている文書構成ファイルに対応するリストを文書保持リストとして作成して当該クライアントに送信し、前記各クライアントは、前記取得した文書構成ファイルを所定の記憶手段に蓄積し、前記文書保持リストを取得したクライアントは、当該文書保持リストに基づいて、取得を意図する文書構成ファイルを蓄積する他のクライアントを特定し、当該他のクライアントに対して文書要求を行って、当該クライアントから当該文書構成ファイルを取得して文書ファイルを再構築することを特徴とする文書管理システム。
前記サーバは、前記文書取得履歴リストに各文書構成ファイルのハッシュ値をも登録し、前記クライアントは、前記文書構成ファイルとともに当該文書構成ファイルのハッシュ値を当該サーバから取得して前記記憶手段に蓄積し、また、当該ハッシュ値を含む前記文書保持リストを前記サーバから取得し、前記他のクライアントへの文書要求によって、当該他のクライアントから前記文書構成ファイルとともに当該文書構成ファイルの前記ハッシュ値を取得し、前記サーバから取得したハッシュ値と当該他のクライアントから取得した前記ハッシュ値を比較して当該他のクライアントから取得した文書構成ファイルの適否を検証することを特徴とする請求項１記載の文書管理システム。
前記サーバは、前記文書取得履歴リストに各文書構成ファイルのハッシュ値をも記憶し、前記クライアントは、前記文書構成ファイルとともに当該文書構成ファイルのハッシュ値を当該サーバから取得して前記記憶手段に蓄積し、また、当該ハッシュ値を含む前記文書保持リストを前記サーバから取得し、前記他のクライアントへの文書要求において、当該文書要求にかかる文書構成ファイルのハッシュ値を送り、当該他のクライアントは、前記記憶手段に蓄積している当該文書要求のあった文書構成ファイルのハッシュ値と当該文書要求とともに送られてきたハッシュ値を比較して当該文書構成ファイルの適否を検証し、当該文書構成ファイルが適正であると、当該文書構成ファイルを当該文書要求を行ってきたクライアントに送信することを特徴とする請求項１記載の文書管理システム。
前記他のクライアントに文書要求を行ったクライアントは、当該文書要求に失敗すると、当該他のクライアントを特定した文書取得失敗情報を前記サーバに送信し、前記サーバは、前記文書取得履歴リストから当該文書取得失敗情報に対応する文書構成ファイルに対して登録されている当該他のクライアントを削除することを特徴とする請求項１から請求項３のいずれかに記載の文書管理システム。
前記サーバは、前記クライアントを任意のグループ毎にグループ分けし、前記文書取得履歴リストを当該グループ毎に管理して、前記クライアントから文書要求があると、当該文書要求をしてきたクライアントの属するグループに対して登録されている当該文書要求にかかる文書ファイルの文書保持リストを作成して送信することを特徴とする請求項１から請求項４のいずれかに記載の文書管理システム。
前記サーバは、前記文書取得履歴リストに登録した文書ファイルまたは文書構成ファイルが無効になると、当該文書ファイルまたは当該文書構成ファイルの前記文書取得履歴リストを削除するとともに、当該文書ファイルの文書要求を行ってきた各クライアントに対して、当該文書構成ファイルの削除を指示し、当該削除指示を受けたクライアントが、当該削除指示に対応する文書構成ファイルを前記記憶手段から削除することを特徴とする請求項１から請求項５のいずれかに記載の文書管理システム。
前記クライアントは、前記記憶手段の文書構成ファイルの蓄積容量の上限容量が予め設定されており、前記サーバから取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、新たな文書構成ファイルの蓄積を中止することを特徴とする請求項１から請求項６のいずれかに記載の文書管理システム。
前記クライアントは、前記記憶手段の文書構成ファイルの蓄積容量の上限容量が予め設定されており、前記サーバから取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、当該蓄積している文書構成ファイルのうち、蓄積順の最も古い文書構成ファイルから順次削除して、新たな文書構成ファイルの蓄積を行うことを特徴とする請求項１から請求項６のいずれかに記載の文書管理システム。
前記クライアントは、前記記憶手段の文書構成ファイルの蓄積容量の上限容量が予め設定されており、前記サーバから取得した文書構成ファイルの蓄積容量が当該上限容量に到達すると、当該蓄積している文書構成ファイルのうち、他のクライアントからの文書要求数の多い順であって、かつ、蓄積順の古い文書構成ファイルから順次削除して、新たな文書構成ファイルの蓄積を行うことを特徴とする請求項１から請求項６のいずれかに記載の文書管理システム。
前記クライアントは、前記文書構成ファイルの蓄積容量が前記上限容量に到達して、前記蓄積を拒否した文書構成ファイル、または、前記削除した文書構成ファイルを前記サーバに通知し、当該サーバが、当該文書構成ファイルまたは当該クライアントの前記文書取得履歴リストへの登録を中止または当該クライアントを前記文書取得履歴リストから削除することを特徴とする請求項７から請求項９のいずれかに記載の文書管理システム。