JP2014238699A - 文書管理サーバ、文書管理方法、コンピュータプログラム - Google Patents

Abstract

【課題】 リクエストされた文書のイメージファイルを作成してクライアントに送信する文書管理サーバにおいて、該イメージファイルをキャッシュしているかどうかを容易に判断できるようにする。【解決手段】 クライアントからリクエストされた文書を特定するための文字列を生成し、当該生成された文字列に基づいて特定されるフォルダ階層構造が、キャッシュ格納領域内に存在するかどうかを判定する。存在しないと判定した場合は、前記リクエストされた文書の実ファイルを取得してイメージファイルを作成し、前記生成された文字列に基づいて特定されるフォルダ階層構造をキャッシュ格納領域内に作成し、更に、当該作成されたフォルダ階層構造のフォルダにイメージファイルをキャッシュとして格納する。【選択図】 図７

Description

本発明は、文書の管理を行う文書管理サーバ、文書管理方法、及びプログラムに関するものである。

文書管理サーバと複数のクライアントとで構成される文書管理システムでは、サーバは、クライアントからリクエストを受信し、当該リクエストされた文書に関する情報をクライアントに送信する。また、特許文献１のように、サーバが、リクエストされた文書のイメージデータ（表示用データ）を作成し、そのイメージデータをクライアントに送信して表示させることにより、クライアントの汎用ブラウザで文書の内容を表示できるようにするシステムもある。

このような文書管理システムにおいて、文書管理サーバは、複数のクライアントから、同一文書に対するリクエストを繰り返し受信する場合がある。これに対し、サーバ側に、該文書のイメージデータを再利用可能なデータ（以下、キャッシュ）として蓄積する機能を設けることで、同一文書に対するリクエストに対して高速に応答できるようにすることが考えられる。

また、特許文献２では、情報実体のキャッシュをメタ情報に基づいて検索できるように蓄積しておき、更に、メタ情報を保存したメタ情報テーブルを用いて、情報実体のキャッシュが既に蓄積されているかどうか検出できるようにしている。

特開２００５−２２２２３７号公報 特開２０００−０７６２５７号公報

しかしながら、特許文献２のように、テーブルを使ってキャッシュを参照する手法では、テーブルを格納するための領域が必要であり、物理的な資源（以下、リソース）を消費することになる。

また、クライアントからのリクエストに応じて作成した新しいイメージデータをキャッシュとして保存するたびに、テーブルを更新する必要があるため、クライアントに応答を返す処理の速度に影響を与える恐れもある。

また、メタ情報テーブル内に該当するメタ情報があるか確認し、メタ情報があれば、そのメタ情報に記述されたキャッシュ格納位置情報を用いてキャッシュを検索して、該キャッシュを取得するという手順を踏むので、キャッシュ有無の確認にも時間がかかる。

本発明の文書管理サーバは、クライアントから受信したリクエストに基づいて、当該リクエストされた文書を特定するための文字列を生成する生成手段と、前記生成手段で生成された文字列に基づいて特定されるフォルダ階層構造が、キャッシュ格納領域内に存在するかどうかを判定する判定手段と、前記判定手段で存在しないと判定した場合、前記リクエストされた文書の実ファイルを取得する実ファイル取得手段と、前記実ファイル取得手段で取得した前記実ファイルに基づいて、前記文書のイメージファイルを作成するイメージファイル作成手段と、前記生成手段で生成された文字列に基づいて特定されるフォルダ階層構造を、前記キャッシュ格納領域内に作成し、更に、当該作成されたフォルダ階層構造に、前記イメージファイル作成手段で作成された前記イメージファイルをキャッシュとして格納する格納手段と、前記判定手段で存在すると判定した場合、前記キャッシュ格納領域内の当該特定されるフォルダ階層構造にキャッシュとして格納されているイメージファイルを取得する取得手段と、前記取得されたイメージファイルを前記クライアントに送信する送信手段と、を有することを特徴とする。

本発明により、キャッシュ格納領域内に作成されたフォルダ階層構造に基づいて、キャッシュが既に格納されているかどうか判断できるようになる。

システム構成を示す図 コンピュータのモジュール構成を示す図 クライアントＰＣのソフトウエア構成を示す図 文書管理サーバのソフトウエア構成を示す図 文書管理構造の一例を示す図 クライアントＰＣが文書のイメージを表示するためリクエストを行う際のＵＲＩの例 リクエストに対して、イメージファイルを送信する処理を示すフローチャート フォルダ階層構造における文書を特定するための文字列の例 キャッシュ格納領域内のフォルダ階層構造を示す図 フォルダ階層構造における文書を特定するための文字列の別例 キャッシュ格納領域内のフォルダ階層構造の別例を示す図 キャッシュ格納領域内のフォルダ階層構造の二つの例の比較を示す図 文書管理サーバのソフトウエア構成を示す別例 イメージファイルを送信する処理を示すフローチャートの別例

［実施例１］
図１は、本発明の実施例１のシステム構成を説明する概略図である。図１において、文書管理サーバ１０１は、文書保存、検索など一般的な文書管理サービスを提供する。クライアントＰＣ（クライアントコンピュータ）１０２は、文書管理サーバが提供する文書管理サービスを利用するための文書管理クライアントのアプリケーションを実行する。本実施例では、文書管理クライアントは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）などの各種オペレーティングシステム上で動作するアプリケーションとするが、Ｗｅｂブラウザ上で動作するアプリケーションであってもよい。なお、図示しないが、文書管理クライアントＰＣ１０２は、ネットワーク１０３に複数接続される。ネットワーク１０３は、インターネットやイントラネットなどであり、ネットワーク対応機器（１０１、１０２など）が接続される。文書管理サーバ１０１は、ネットワーク１０３を介してインターネットあるいはイントラネットに文書管理サービスを公開するＷｅｂサービスも併せて提供する。なお、ネットワーク１０３がインターネットとした場合、文書管理サーバ１０１は、クラウドサービスとして提供されるように構成してもよい。その場合のシステム構成は一般的なクラウドサービス構成と同様に、クラウド上の仮想サーバを用いて文書管理サービスを提供すればよいので、クラウドサービス構成の詳細説明に関しては省略する。

図２は、実施例１の典型的な汎用コンピュータモジュール２００の構成を説明するブロック図である。文書管理サーバ１０１、クライアントＰＣ１０２のハードウェア構成は、典型的な汎用コンピュータモジュールを用いて実現可能である。汎用コンピュータモジュール２００には、キーボード２０４やマウス２０５のようなポインティングデバイスなどの入力装置、ディスプレイ装置２１３などの出力装置が接続される。

ＣＰＵ２０１は、少なくとも１つのプロセッサで構成され、コンピュータ読み取り可能な記憶媒体に記憶されたコンピュータプログラムを実行することによって、後述する各フローチャートの処理を実行し、コンピュータ全体の制御を行う。メモリ２０２は、ＲＡＭやＲＯＭから構成される。ビデオインターフェース２１２は、ディスプレイ装置２１３に画像を出力する。Ｉ／Ｏインターフェース２０３は、キーボード２０４やマウス２０５からの操作による入力を受け取る。記憶装置２０８は、ハードディスクドライブ（ＨＤＤ）２０９やフラッシュメモリ（シリコンドライブ）などで構成される不揮発性の記憶装置である。ドライブ２０６は、ＣＤ−ＲＯＭやＤＶＤなどの光学ドライブであり、不揮発性のデータソースとして用いられる。相互接続バス２０７は、ＣＰＵ２０１の制御に基づき各ブロック間の通信を仲介するバスである。ネットワークコントローラー（ＮＣ）２１０は、所定のネットワークインターフェース２１１を介してネットワーク１０３に接続され、他のネットワーク機器との通信制御処理を実行する。

なお、後述のフローチャートで示される処理を文書管理サーバ１０１およびクライアントＰＣ１０２に実行させるための各種制御プログラムは、各装置のメモリ２０２や記憶装置２０８などの記憶手段に記憶され、各装置のＣＰＵ２０１により実行される。また、文書管理サーバ１０１は、文書管理用のデータベースを有するが、そのデータベースも記憶装置２０８上に構築されるものとする。

図３は、文書管理クライアントアプリケーションのソフトウエア構成を説明するブロック図である。

アプリケーション３０１は、各種の機能を実行するためのユーザーインターフェースをディスプレイ装置２１３の画面上に表示させ、ユーザーからの要求をキーボード２０４やマウス２０５を介して受け付けて、各機能処理を実行する。３０２〜３０３は、アプリケーションを構成するコンポーネントを示している。コンポーネント３０２はアプリケーションのＵＩ部であり、ユーザーインターフェースの構築や、ユーザーからの各種入力操作の受け付けおよび入力操作による処理結果の表示を行う。コンポーネント３０３は、ライブラリー管理部であり、アプリケーション３０１で利用するライブラリーを管理し、ライブラリーへの文書の格納や、ライブラリー内文書の閲覧、更新、属性変更、検索などの各種文書操作を実行する。ここで言うライブラリーとは、文書管理を行うための保存単位のことであり、文書データと、文書属性などの文書管理用のデータを保存する。本発明においては文書の過去バージョンや、文書の更新履歴も保存する。ライブラリー管理部３０３は、アプリケーションＵＩ部３０２から受け取った文書操作の要求を文書管理サーバ１０１に渡し、その要求の処理結果を文書管理サーバから受け取って、アプリケーションＵＩ部３０２に渡す。３０５は、ライブラリー管理部３０３が文書管理サーバに接続するためのインターフェースを示す。

図４は、文書管理サーバ１０１のソフトウエア構成を説明するブロック図である。サーバソフトウエア４０１は、サーバの管理者からの指示を受け付けるためのユーザーインターフェースやディスプレイに各種情報を表示するためのＵＩ部を備える。文書管理部４０２は、サーバソフトウエア４０１で利用する文書のデータベース４０５を管理するものであり、データベースに文書の格納を行ったり、データベースから文書の取得を行ったりする。データベース４０５は記憶装置２０８上に構築され、文書管理サーバ１０１で扱う文書の実データはデータベース４０５内に蓄積される。

キャッシュ管理部４０３は、文書の実データに基づいて作成されたイメージファイルをキャッシュとして蓄積して管理することにより、ユーザーからのリクエストに応じて該キャッシュを繰り返し利用できるようにする。なお、キャッシュ管理の構造はキャッシュ管理部４０３により決定され、また、キャッシュ格納領域は記憶装置２０８上に構築されるものとする。本実施例１においてキャッシュ管理は、データベース４０５から独立したファイルシステムによって行われる。

イメージファイル作成部４０４は、文書の実データからイメージデータと非イメージデータとを抽出し、イメージデータはそのままあるいは必要に応じて拡大縮小などの画像変換を行う。非イメージデータについては、例えばテキストをフォントイメージに置き換えてイメージデータとして描画し、ベクター形式データについては出力サイズに合わせてイメージデータとして描画する。そしてそれらを結合することにより、クライアントＰＣのブラウザで文書の内容を表示できるファイルフォーマットのイメージファイルに変換する。本実施例においてイメージファイル作成部４０４は、文書の実ファイルから表示イメージの総ページ数を算出することができて、ページごとのイメージファイルを作成するものとする。

図５は、文書管理サーバ１０１の記憶装置２０８に格納される文書の管理構造（データベースにおける文書管理の階層構造）の一例を説明するブロック図である。最上位にはシステム管理者がユーザーに対して同一の操作やセキュリティポリシーを提供することを可能にするための管理設定を共有する最上位階層５０１が存在する。そして、その下に、文書の一意性を保証する二次階層５０２、同一の文書属性情報（同一の属性項目）を共有する三次階層５０３という構造になっている。さらにその下に、文書を格納するためのフォルダ５０４と文書５０５とがそれぞれに配置される。

本実施例において文書管理サーバ１０１はＷｅｂサービスを提供し、５０１へアクセスするためのネットワークアドレスが割り当てられている。そして、５０１内において二次階層５０２を一意に識別するための識別符号（以下、サイトＩＤ）が割り当てられている。さらに、二次階層５０２の各サイトの配下の階層に配置される文書に対しては、各サイト内においてそれぞれの文書を一意に識別するための識別符号（以下、文書ＩＤ）が割り当てられている。よって、ネットワークアドレスとサイトＩＤと文書ＩＤの組み合わせによって、すべての文書を一意に特定することを可能にしている。

例えば、会社で文書管理システムを運用する場合、各ユーザーがアクセス可能な領域を次のように定めてもよい。例えば、会社の部門ごとに二次階層５０２として各サイト（ＡＡＡ，ＢＢＢ，ＣＣＣ）を割り当て、各部門内の課ごとに三次階層５０３としてライブラリー（ＤＤＤＤ，ＥＥＥＥ）を割り当てる。そして、各課に属するユーザーが各ライブラリーの配下にあるフォルダ５０４や文書５０５にアクセスできるようにアクセス権を付与する。各課では同種の文書を共有することが多いので、予め各課で定義した属性項目を設定し、各文書に対して各属性項目に対応する属性値を対応づけて登録しておけば、各文書を検索しやすくなる。

図６は、クライアントＰＣ１０２上で動作するアプリケーション３０１から文書管理サーバ１０１に対して、文書のイメージを表示するためのリクエストを行う際のＵＲＩの例である。オーソリティー部およびパス部６０１には最上位階層５０１を特定するためのネットワークアドレスとイメージをリクエストするためのオブジェクトのパスを含む。クエリ部には以下の要素を含む。すなわち、二次階層５０２のサイトＩＤを指定するクエリ６０２、文書ＩＤを指定するクエリ６０３、文書の属性情報である更新日時を指定するクエリ６０４、表示させたい先頭ページのページ番号を指定するクエリ６０５と、表示させたい最終ページのページ番号を指定するクエリ６０６である。図５の説明で述べたとおり、文書を特定するために三次階層５０３やそれ以下のフォルダを特定するための情報を含める必要はない。なお、本実施例においてリクエストはＵＲＩで記述されるが、本発明を実現するための手法はこれに限定されず、アプリケーション３０１と文書管理サーバ１０１との間で規定されていて、６０１から６０６に相当する要素が含まれるような書式であればよい。

図７は、クライアントＰＣ１０２から受信した図６のようなリクエスト（文書表示のリクエスト）に対して、文書管理サーバ１０１が文書のイメージファイルを送信する処理を示すフローチャートである。

ステップ７０１において、キャッシュ管理部４０３は、クライアントＰＣから受信した図６に示されるような文書表示リクエストのＵＲＩに基づいて、文書を特定するための一意の文字列を生成する。生成される文字列の詳細については図８の説明と併せて後述する。

ステップ７０２において、キャッシュ管理部４０３は、記憶装置２０８上のキャッシュ格納領域内に、ステップ７０１で生成された文字列に基づいて特定される階層構造と同様のフォルダ階層構造が存在するかどうかを判定する。存在すればステップ７０９に、存在しなければステップ７０３に進む。なお、ステップ７０２の判定処理の具体例は後述する。

ステップ７０３において、文書管理部４０２は、クライアントＰＣ１０２からリクエストされた文書の実ファイル（文書の実体データ）をデータベース４０５から取得する実ファイル取得処理を実行する。図６の説明に示したとおり、イメージをリクエストするＵＲＩに基づいて文書は一意に特定される。

ステップ７０４において、イメージファイル作成部４０４は、ステップ７０３で取得した文書の実ファイルに基づいて、表示イメージの総ページ数を算出する。

ステップ７０５において、イメージファイル作成部４０４は、ステップ７０３で取得した文書の実ファイルに基づいて、ページごとのイメージファイルを作成する。

ステップ７０６において、キャッシュ管理部４０３は、記憶装置２０８のキャッシュ格納領域内のトップフォルダの直下に、ステップ７０１で生成された文字列と等しい構造を持ち等しい名前を持つようなフォルダ階層を作成する。

ステップ７０７において、キャッシュ管理部４０３は、ステップ７０６で作成されたフォルダのうち最下層のフォルダの下に、ステップ７０４で算出された文書の表示イメージの総ページ数を示す文字列をフォルダ名に持つフォルダを作成する。

ステップ７０８において、キャッシュ管理部４０３は、ステップ７０７で作成されたフォルダの下に、ステップ７０５で作成されたページごとのイメージファイルをキャッシュとして格納する。このとき、各ページに対応するイメージファイルのファイル名は、それぞれのページのページ番号とする。なお、ステップ７０６〜７０８の処理により、記憶装置２０８のキャッシュ格納領域内に構築された階層構造については、図９の説明と併せて後述する。

ステップ７０９において、キャッシュ管理部４０３は、クライアントＰＣ１０２からリクエストされたページに対応する文書のイメージファイルを、記憶装置２０８上のキャッシュ格納領域から取得する。ステップ７１０において、文書管理サーバ１０１は、クライアントＰＣ１０２に対してステップ７０９で取得したイメージファイルを送信する。

図８は、ステップ７０１において生成される、フォルダ階層構造における文書を特定するための文字列の例である。ブロック８０１はクエリ６０２によって指定されたサイトＩＤを含む。ブロック８０２はクエリ６０３によって指定された文書ＩＤを含む。ブロック８０３はクエリ６０５によって指定された文書の更新日時を含む。各ブロックはフォルダ階層構造を記述するためのパス区切り文字（図８の例では「＼」）によって接続される。なお、リクエストのＵＲＩと同様に文書を特定できればよいので、図８の文字列には、三次階層５０３やそれ以下のフォルダを特定するための情報を含まなくても構わない。よって、図８の文字列は、図５に示されるような階層構造をそのまま表現するものではない。

図９は、ステップ７０３〜７０８の処理によりイメージファイルがキャッシュとして格納されたキャッシュ格納領域内のフォルダ階層構造を示す図である。キャッシュ格納領域の最上位フォルダ以下の階層構造は、ステップ７０１で生成された図８で示す文字列に基づいて生成される。この階層構造は、ブロック８０１に示されるサイトＩＤをフォルダ名に持つフォルダ９０１、ブロック８０２に示される文書ＩＤをフォルダ名に持つフォルダ９０２、ブロック８０３に示される文書の更新日時をフォルダ名に持つフォルダ９０３である。９０１〜９０３のフォルダは、ステップ７０６の処理によって作成される。更に、フォルダ９０３の直下には、ステップ７０７の処理により、文書の総ページ数を示す文字列をフォルダ名に持つフォルダ９０４が作成される。特定文書の特定更新日時のバージョンにおける総ページ数は一意に定まるため、フォルダ９０４はフォルダ９０３の直下に必ず１つ作成されることとなる。そして、ステップ７０８の処理により、フォルダ９０４内に文書の各ページのイメージファイルが格納される。前述のとおり、各イメージファイルのファイル名はそれぞれのページのページ番号とする。なお、図９のキャッシュ格納領域のフォルダ階層構造は、図８の文字列に基づいて作成されるので、図５に示した階層構造と同じではない。

ここで、キャッシュ格納領域内にイメージファイルがキャッシュされているか否かを判定するための、ステップ７０２における判定方法について、図８，９を参照しながら説明する。図６のＵＲＩに基づきステップ７０１で生成された図８の文字列を参照して、キャッシュ格納領域内に、ブロック８０１に相当するフォルダ９０１、ブロック８０２に相当するフォルダ９０２、ブロック８０３に相当するフォルダ９０３、が存在するか判断する。このとき、キャッシュが未だ格納されていなければ、キャッシュ格納領域内に該当する階層構造のフォルダが作成されていないはずである。すなわち、図８の文字列に対応する名称のフォルダ９０１〜９０３が存在するかどうかに基づいて、キャッシュを既に格納しているかどうかを判断できる。そして、該当する名称のフォルダが存在し、キャッシュが既に格納されていると判断できた場合、更に、フォルダ９０３の直下には唯一のフォルダ９０４が存在する。そして、ステップ７０９では、フォルダ９０４内のイメージファイルのうち、クエリ６０５とクエリ６０６とによって指定されたページのページ番号をファイル名に持つイメージファイルを取得する。

上述したように、実施例１によれば、キャッシュ格納領域内に作成された階層構造に基づいて、キャッシュが既に格納されているかどうか判断できるので、特許文献２のようにキャッシュの有無を判定するためのテーブルを用意せずに済む。また、テーブルを用いずにキャッシュ格納領域内のフォルダ階層構造に基づいてキャッシュの有無を判定できるので、高速に応答を返すことができる。

［実施例２］
実施例１の図５の説明で前述したとおり、それぞれの文書には、二次階層５０２の各サイト内において一意に特定される文書ＩＤが割り当てられている。よって、図９のフォルダ９０１の直下には、最大で、二次階層５０２のサイトＣＣＣの下位階層に格納される全文書の数と同数のフォルダが作成される可能性があることになる。一般のファイルシステムでは、ある１つのフォルダ下に作成可能なサブフォルダの数には上限がある場合が多く、したがって、二次階層５０２の下位階層に格納される文書の数が膨大になるとその上限を超えることが考えられる。実施例２では、それを解決しつつ、実施例１と同様の効果を得るための手法を説明する。

図１０は、ステップ７０１において生成される、フォルダ階層構造における文書を特定するための文字列の別の例である。図１０のブロック８０１は、図８の８０１と同様にクエリ６０２によって指定されたサイトＩＤを含む。次に、キャッシュ管理部４０３は、クエリ６０３によって指定されている文書ＩＤ（アルファベット９文字とそれを３文字ごとに区切るハイフンとからなる文書ＩＤ）を、ハイフンを除去してアルファベット３文字からなる３つのグループに分割する。図１０のブロック１００１、ブロック１００２、ブロック１００３には、分割されたそれぞれのグループのアルファベット３文字を含む。なお、分割する文字数は３文字ごとに限るものではなく、予め定めた基準に基づいて文書ＩＤを分割すればよい。図１０のブロック８０３は、図８の８０３と同様に、クエリ６０５によって指定された文書の更新日時を含む。図１０の各ブロック（８０１，１００１，１００２，１００３，８０３）は、フォルダ階層構造を記述するためのパス区切り文字（＼）によって接続される。文書ＩＤを分割することで、１００１〜１００３の各ブロックにはある程度の重複を見込むことができる。

図１１は、実施例２において、ステップ７０３〜７０８の処理によりイメージファイルがキャッシュとして格納されたキャッシュ格納領域内のフォルダ階層構造を示す図である。フォルダ９０１は図９の９０１と同様である。フォルダ１１０１〜１１０３はそれぞれ、ブロック１００１〜１００３に示される文字列をフォルダ名に持つ。フォルダ９０３、フォルダ９０４、およびフォルダ９０４の直下に作成されるイメージファイルは、図９と同様である。

図１２は、実施例１の手法で構成されたキャッシュ格納領域内のフォルダ階層構造１２０２と、実施例２の手法で構成されたキャッシュ格納領域内のフォルダ階層構造１２０３との比較を示す図である。１２０１は、二次階層５０２のサイトＣＣＣの下位階層に格納される全文書の文書ＩＤを示すリストの例である。１２０２は、キャッシュ格納領域内に実施例１の手法で１２０１の各文書のイメージファイルを格納した場合のフォルダ階層構造を示す図である。なお、図１２のフォルダ階層構造１２０２では、フォルダ９０３以下の階層構造の説明は省略している。また、１２０３は、キャッシュ格納領域内に実施例２の手法で１２０１の各文書のイメージファイルを格納した場合のフォルダ階層構造を示す図である。同様に、図１２のフォルダ階層構造１２０３では、フォルダ９０３以下の階層構造の説明は省略している。上述したように、図１０で説明した手法で文書ＩＤを分割することで、ブロック１００１に相当する文字列には複数の文書の間である程度の重複を見込むことができる。したがって、図１２のフォルダ階層構造１２０３の例では、フォルダ１１０１や１１０２の直下に複数のサブフォルダが格納されることになる。結果として、フォルダ階層構造１２０２におけるフォルダ９０１の直下のフォルダの数よりも、フォルダ階層構造１２０３におけるフォルダ９０１の直下のフォルダの数の方が少なくなる。一方、末端となる階層のフォルダの数は１２０２と１２０３とで変わらないため、フォルダ９０３以下の構造に差異はなく、図７に示すイメージファイルの格納と取得の処理には差異が発生しない。

実施例２では、一般のファイルシステムにおけるサブフォルダ数の制限を超えるリスクを軽減することにより、大量の文書に対応できるキャッシュの階層構造を定義する文書管理システムを提供することができる。

［実施例３］
実施例１で説明したような文書管理システムにおいて、キャッシュ格納領域を収容する記憶装置２０８の物理的な容量は一般に有限である。クライアントＰＣ１０２からのリクエストに応じて文書のイメージファイルの作成と格納をしすぎると、記憶装置２０８の容量の上限を超えてしまうことが考えられる。実施例３では、それを解決しつつ、実施例１と同様の効果を得るための手法を説明する。

図１３は、文書管理サーバ１０１のソフトウエア構成を説明するブロック図の拡張の例である。ユーザー認証部１３０１は、クライアントＰＣ１０１からユーザーＩＤとパスワードの組み合わせなどの一般的な認証情報を受信し、その認証情報の認証処理を実行して、受け付けた認証情報に対する承認を与える。認証情報の確認（認証処理）は、文書管理サーバ１０１内に格納されるユーザーリストとの照合を行う手法であっても、外部のサーバを用いて認証を行う手法であっても、本実施例においてはどちらでもかまわない。文書管理サーバ１０１は、クライアントＰＣ１０１からのリクエストに対して任意のタイミングでユーザー認証部１３０１によるアカウント認証を行う。ユーザーからの能動的な切断リクエストを受信したり、文書管理サーバ１０１内の定義による自動的な切断が発生したりするまで、クライアントＰＣ１０１からのリクエストを承認されたユーザーのリクエストとして扱う。

アクセス制御部１３０２は、承認されたユーザーからの個々のリクエストについて、文書管理サーバ１０１のリソースを使用する権限を持つかどうか、どのように使用できるかを判断する（権限判断）。そして、アクセス制御部１３０２は、その判断結果に基づいて、リクエストを受け付けるか否か、リクエストに対してどのように機能を提供するかを決定する。なお、その判断手法は、文書管理サーバ１０１内に格納されるアクセス制御リストとの照合を行う手法であっても、外部のサーバを用いる手法であっても、本実施例においてはどちらでもかまわない。

図１４は、クライアントＰＣ１０２から受信した図６のようなリクエスト（文書表示のリクエスト）に対して、文書管理サーバ１０１が文書のイメージファイルを送信する処理を示すフローチャートの別の例である。なお、図１４のフローチャートの開始時点には、ユーザー認証部１３０１による認証情報の確認が完了していて、リクエストは承認されたユーザーによるものとして扱われることとする。

ステップ１４０１において、アクセス制御部１３０２は、リクエストしたユーザーが文書の表示権限を持つかどうかを判断する。表示権限を持っていればステップ７０１に進み、表示権限がなければステップ１４０２に進む。図１４のステップ７０１〜７１０の各処理については図７のステップ７０１〜７１０の各処理と同様であるので詳細説明は省略する。

ステップ１４０２において、文書管理サーバ１０１は、クライアントＰＣ１０２に対して文書の表示権限がない旨を送信する。

ステップ１４０３において、アクセス制御部１３０２は、リクエストしたユーザーが再利用可能なイメージファイルをキャッシュとして保持する権限、すなわちキャッシュ格納領域にイメージファイルを格納するための格納権限を有するかどうかを判断する。この権限判断処理により、格納権限を持っていればステップ７０６に進み、格納権限がなければステップ７１０に進む。

実施例３において、キャッシュの格納権限を持たないユーザーの指示に基づいてクライアントＰＣ１０２が、文書の表示リクエストを文書管理サーバ１０１へ送信した場合、ステップ７０５で作成されたイメージファイルはキャッシュされずにステップ７１０でクライアントＰＣ１０２に送信された後に破棄される。

なお、キャッシュ格納領域にイメージファイルを格納する権限は、文書管理サーバ１０１の管理者が各ユーザーに対して個別に設定できるものであってもよい。あるいは、ユーザーのアクセス頻度や文書表示リクエスト頻度に対して所定の閾値と比較することで、該閾値を超えるユーザーに対してキャッシュ格納領域にイメージファイルを格納する格納権限を自動的に付与する処理を行うものであってもよい。

実施例３では、キャッシュ格納領域を利用可能なユーザーを制限することにより、イメージファイルをキャッシュしすぎて記憶装置２０８の容量の上限を超えることがないような文書管理システムを提供することができる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (9)

1. クライアントから受信したリクエストに基づいて、当該リクエストされた文書を特定するための文字列を生成する生成手段と、
   前記生成手段で生成された文字列に基づいて特定されるフォルダ階層構造が、キャッシュ格納領域内に存在するかどうかを判定する判定手段と、
   前記判定手段で存在しないと判定した場合、前記リクエストされた文書の実ファイルを取得する実ファイル取得手段と、
   前記実ファイル取得手段で取得した前記実ファイルに基づいて、前記文書のイメージファイルを作成するイメージファイル作成手段と、
   前記生成手段で生成された文字列に基づいて特定されるフォルダ階層構造を、前記キャッシュ格納領域内に作成し、更に、当該作成されたフォルダ階層構造に、前記イメージファイル作成手段で作成された前記イメージファイルをキャッシュとして格納する格納手段と、
   前記判定手段で存在すると判定した場合、前記キャッシュ格納領域内の当該特定されるフォルダ階層構造にキャッシュとして格納されているイメージファイルを取得する取得手段と、
   前記取得されたイメージファイルを前記クライアントに送信する送信手段と、
   を有することを特徴とする文書管理サーバ。
2. 前記生成手段は、前記リクエストに含まれるＵＲＩに基づいて当該リクエストされた文書を特定するための文字列を生成することを特徴とする請求項１に記載の文書管理サーバ。
3. 前記実ファイル取得手段は、前記判定手段で存在しないと判定した場合、前記リクエストに含まれるＵＲＩに基づいて特定される前記文書の実ファイルを取得することを特徴とする請求項１に記載の文書管理サーバ。
4. 前記イメージファイル作成手段は、前記実ファイル取得手段で取得した前記実ファイルに基づいて、前記文書のページごとに前記イメージファイルを作成し、
   前記格納手段は、前記生成手段で生成された文字列に基づいて特定されるフォルダ階層構造を、前記キャッシュ格納領域内に作成し、更に、前記イメージファイル作成手段でページごとに作成された各イメージファイルのファイル名をページ番号にして、当該作成されたフォルダ階層構造に各イメージファイルをキャッシュとして格納することを特徴とする請求項１に記載の文書管理サーバ。
5. 前記生成手段は、前記リクエストされた文書の文書ＩＤを予め定めた基準に基づいて分割し、当該分割された文書ＩＤを用いて前記リクエストされた文書を特定するための文字列を生成することを特徴とする請求項１に記載の文書管理サーバ。
6. 前記クライアントのユーザーが、前記キャッシュ格納領域に前記イメージファイルを格納する格納権限を有するか否かを判断する権限判断手段を更に有し、
   前記格納手段は、前記権限判断手段により前記格納権限を有さないと判断した場合は、前記イメージファイルをキャッシュとして格納しないように制御することを特徴とする請求項１に記載の文書管理サーバ。
7. 生成手段が、クライアントから受信したリクエストに基づいて、当該リクエストされた文書を特定するための文字列を生成する生成ステップと、
   判定手段が、前記生成ステップで生成された文字列に基づいて特定されるフォルダ階層構造が、キャッシュ格納領域内に存在するかどうかを判定する判定ステップと、
   実ファイル取得手段が、前記判定ステップで存在しないと判定した場合、前記リクエストされた文書の実ファイルを取得する実ファイル取得ステップと、
   イメージファイル作成手段が、前記実ファイル取得ステップで取得した前記実ファイルに基づいて、前記文書のイメージファイルを作成するイメージファイル作成ステップと、
   格納手段が、前記生成ステップで生成された文字列に基づいて特定されるフォルダ階層構造を、前記キャッシュ格納領域内に作成し、更に、当該作成されたフォルダ階層構造に、前記イメージファイル作成手段で作成された前記イメージファイルをキャッシュとして格納する格納ステップと、
   取得手段が、前記判定ステップで存在すると判定した場合、前記キャッシュ格納領域内の当該特定されるフォルダ階層構造にキャッシュとして格納されているイメージファイルを取得する取得ステップと、
   送信手段が、前記取得されたイメージファイルを前記クライアントに送信する送信ステップと、
   を有することを特徴とする文書管理方法。
8. コンピュータを、請求項１乃至６のいずれか１項に記載の各手段として機能させるためのコンピュータプログラム。
9. 請求項８記載のコンピュータプログラムを格納した、コンピュータ読み取り可能な記憶媒体。

Images