JP5266992B2 - 電子ドキュメント管理システム、電子ドキュメント管理方法およびそのプログラム - Google Patents

Description

本発明は、電子ドキュメント管理システムに関し、より詳細には、ファイル検索のために使用されるメタデータを自動生成して管理する電子ドキュメント管理システムに関する。

従来、複数のクライアントが利用するさまざまな電子ドキュメントを、ネットワーク上に接続されたファイルサーバが一元管理し、各クライアントからの閲覧、印刷要求等に応じる電子ドキュメント管理システムが提供されている。

このような電子ドキュメント管理システムにおいては、ユーザが比較的簡単に目的のファイルにたどり着くことができるようにするため、一般に、ファイルの保管に関するルールを定めている。このような電子ドキュメント管理システムにおいては、ユーザは、定められたルールに則ってフォルダ作成やファイル保管をしたり、定められたルールに則って、作成日、作成者などのメタデータを入力したりすることが要求される。

しかし、実際の運用においては、煩雑なメタデータの入力作業をユーザが嫌うため、結果的にその作業が徹底されず、メタデータの付与が不完全なものとなり、後の検索において目的のファイルにたどりつけないという問題が生じていた。

一方、特開２００６−３３８６６９号公報（特許文献１）は、利便性に優れたドキュメントの管理を実現すべく、複数の場所にある複数のドキュメントを単一の識別子に関連付けすることを可能とするとともに、複数のドキュメント、フォルダ、またはフォルダツリーを単一の仮想コンテナにグループ化するための構成を開示する。しかしながら、特許文献１においても、メタデータの入力の遂行は依然としてユーザの規律意識に依存するものであって、特許文献１は、上述した問題についての解決手段を示すものではなかった。
特開２００６−３３８６６９号公報

本発明は、上記従来技術における課題に鑑みてなされたものであり、本発明は、ファイルサーバを用いた電子ドキュメント管理システムにおいて、ファイルの保管に際し、ユーザに特別な操作を要求することなく、後の検索に使用するためのメタデータを自動的に生成し、これをファイルに関連付けて自動的に保管することのできる電子ドキュメント管理システムを提供することを目的とする。

本発明者らは、ファイルの保管に際し、ユーザに特別な操作を要求することなく、後の検索に使用するためのメタデータを自動的に生成し、これをファイルに関連付けて自動的に保管することのできる電子ドキュメント管理システムにつき鋭意検討した結果、ファイルサーバのフォルダ階層構造の規則性に着目し、当該フォルダ階層構造を利用したメタデータを自動的に生成し、且つ、これをファイルに関連付けて自動的にドキュメント管理サーバに登録する構成に想到し、本発明に至ったのである。

一般に、ファイルサーバにおいては、一定のルールに則って構築されたフォルダの階層構造が予め用意されている。例えば、フォルダ名として顧客企業名などをつけた最上位階層のフォルダを作成した上で、該フォルダの下位階層に案件ごとのサブフォルダを作成し、それぞれに案件名などのファイル名をつけたフォルダの階層構造を用意する。

ユーザが電子ファイルを保存する場合、このように展開されたフォルダツリーの中から、フォルダ名を頼りに、目的のフォルダを見つけ出し、目的の電子ファイルにファイル名を付して保管する。このような作業は、定められたルールに基づいて行われるものではあるが、実際には、ユーザは、そのようなルールをさして意識することなく、直感的にこれらの作業を行うことができ、実際にこれらの作業は、ほぼ正確に行われている。

本発明においては、ユーザが日常的に行っているファイルの保存という行為によって、フォルダ階層構造における当該ファイルの位置情報が正確に決定されることを利用して、当該位置情報から自動的にメタデータを生成する。すなわち、ファイルサーバにおいて、ファイルが保存（または変更）されたことを契機として、当該ファイルをその位置情報とともに、ドキュメント管理サーバにアップロードし、これを受けたドキュメント管理サーバは、当該位置情報に所定のルールを適用することによって自動的にメタデータを生成する。さらに、本発明においては、アップロードされた各ファイルに対してユニークなファイル識別子を付与し、当該ファイル識別子と生成したメタデータとを関連付けてテーブル管理する。

すなわち、本発明によれば、複数のクライアント装置が共有する電子ドキュメントを保管するファイルサーバと、該ファイルサーバにネットワーク接続されたドキュメント管理サーバとを含む電子ドキュメント管理システムであって、前記ファイルサーバは、更新されたファイルを検出する手段と、更新されたファイルおよび該ファイルについての位置情報を前記ドキュメント管理サーバにアップロードする手段とを含み、前記ドキュメント管理サーバは、前記ファイルサーバからアップロードされた前記位置情報に対して文書の種類ごとに用意されたルールを適用してメタデータを生成する手段と、前記ファイルサーバからアップロードされた前記ファイルに対してユニークな識別子を付与する手段と、前記メタデータと前記ユニークな識別子とを関連付けて前記ルールごとにテーブル管理する手段と前記ユニークな識別子と前記ファイルの保管場所とを関連付けてテーブル管理する手段とを含む電子ドキュメント管理システムが提供される。

以下、本発明を、実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。

図１は、本実施形態の電子ドキュメント管理システム１０を示す。電子ドキュメント管理システム１０は、複数のクライアント装置が共有する電子ドキュメントを保管するファイルサーバ１２と、ドキュメント管理サーバ１４とを含んで構成されている。電子ドキュメント管理システム１０においては、ファイルサーバ１２、ドキュメント管理サーバ１４、ならびに、クライアント装置として例示する画像形成装置１６およびパーソナル・コンピュータ（ＰＣ）１８が、ローカルエリア・ネットワーク（ＬＡＮ）、ワイドエリア・ネットワーク（ＷＡＮ）、またはインターネットといったネットワーク基盤として構成されるネットワーク２０に接続されている。

図１に示す例においては、画像処理装置１６は、スキャニング機能を備えるＭＦＰ(Multi Function Peripheral）として構成されており、ユーザは、当該機能を使用して紙媒体ドキュメントをスキャンしてイメージファイルが作成し、必要に応じてＯＣＲ処理を行ってテキストファイルとしたのち、ファイルサーバ１２を出力先として指定して当該ファイルを、ネットワーク２０を介して送信する。また、同様に、ユーザは、ＰＣ１８を用いて電子ドキュメントファイルを作成し、ファイルサーバ１２を出力先として指定してネットワーク２０を介して送信する。

ユーザがファイルをファイルサーバ１２に送信するにあたり、画像処理装置１６およびＰＣ１８が備える各ユーザ・インタフェースには、ファイルサーバ１２内に構築されているフォルダ階層構造が表示案内され、ユーザは、展開されたフォルダツリーの中からフォルダ名を頼りにファイルを保管すべきフォルダを見つけ出し、当該フォルダを格納先に指定してファイルを送信する。

ファイルをどのフォルダに保管するのかについては、予めルールが定められており、ユーザがこれに従うことがシステム運用の前提となるが、この程度のルールであれば、ユーザは何らの心理的負担を感じることなく、直感的且つ正確に遂行することができる。本実施形態の電子ドキュメント管理システム１０は、さらに、ドキュメント管理サーバ１４を含んで構成されており、ファイルサーバ１２からドキュメント管理サーバ１４へネットワーク２０を介して所定の情報を転送することによって、新規な電子ファイル管理を実現している。この点につき、以下、詳細に説明する。

図２は、本実施形態におけるファイルサーバ１２の機能ブロック図を示す。ファイルサーバ１２は、パーソナル・コンピュータ、またはワークステーションなどとして構成されるものであり、システム・コントローラとして機能するＣＰＵ、アプリケーション・ソフトウェアの実行空間を与えるためのＲＡＭ、ならびに処理を行うためのデータまたはプログラムなどを格納したＲＯＭ等のメモリ、およびＮＩＣを含むネットワーク・インターフェースなどの各種インターフェース部、および、共有ファイルを保管するための記憶装置２２を備えている。記憶装置２２は、例えばハードディスク装置や光ディスク装置などによって構成される。

ファイルサーバ１２は、ファイル更新監視部２４とファイルアップロード部２６とを備えており、これらの機能手段は、ファイルサーバ１２において、ＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、その他の適切なオペレーション・システム（ＯＳ）の管理下で、Ｃ、Ｃ＋＋、ＶｉｓｕａｌＣ＋＋、ＶｉｓｕａｌＢａｓｉｃ、Ｊａｖａ（登録商標）などのオブジェクト指向のプログラミング言語により記述された各種アプリケーション・プログラムが実行されることによって実現される。なお、ファイル更新監視部２４とファイルアップロード部２６は、記憶装置２２を監視可能な装置として、ファイルサーバ１２とは別個に実現することもできる。

ファイルサーバ１２の記憶装置２２内には、上述したように、予め定められたルールに基づいて、フォルダ階層構造が構築されており、最下位階層に位置する各フォルダに電子ファイルが保管されている。図３は、記憶装置２２内に構築されるフォルダ階層構造の一例を示す図であり、見積書等の電子ファイルを格納するために構築されたフォルダツリーが展開された様子を示す。

図３に示す例においては、予め以下のルールが定められている。すなわち、フォルダ階層構造は、見積書、計画書、および、それ以外の文書（例えば、受注書、図面等）ごとに構築し、それぞれの最上位階層のフォルダ名を、「見積書」、「計画書」、「プロジェクト」とするというルール、「見積書」フォルダの下の階層には、年ごとにフォルダを作成し、さらにその下の階層には月ごとにフォルダを作成するというルール、「計画書」フォルダの下の階層には、顧客ごとにフォルダを作成するというルール、「プロジェクト」フォルダについては、その下の階層には、顧客ごとにフォルダを作成し、さらにその下の階層には、案件番号ごとにフォルダを作成し、さらにその下の階層には格納する文書の種類ごとにフォルダを作成するというルールが定められている。

さらに、ユーザは、電子ファイルの格納について、見積書についてはその作成年月ごとに該当するフォルダに格納し、そのファイル名は案件番号＋拡張子とし、計画書については顧客ごとに該当するフォルダに格納し、そのファイル名は案件番号＋拡張子とし、それ以外の文書については、プロジェクトフォルダ下の該当する顧客のフォルダ下の、該当する案件番号のフォルダ下の該当する文書種類のフォルダに格納し、そのファイル名は任意とするというルールが義務付けられている。

上記ルールに基づいて、記憶装置２２内には、下記のフォルダが作成されている。すなわち、最上位階層に３つのフォルダ３０、４０、５０が作成されており、それぞれに「見積書」、「計画書」、「プロジェクト」というフォルダ名が付されている。「見積書」フォルダ３０の下の階層には、年ごとに３つのフォルダが作成されており、それぞれ、「２００４年」、「２００５年」、「２００６年」というフォルダ名が付され、さらに、これらのフォルダの下の階層には、月ごとにフォルダが作成されており、「２００６年」フォルダの下には「１月」、「２月」、「３月」というフォルダが作られている。また、「計画書」フォルダ４０の下の階層には、顧客ごとに３つのフォルダが作成されており、それぞれ、「吉田製作所」、「小原工業」、「中村」というフォルダ名が付されている。

さらに、「プロジェクト」フォルダ５０の下の階層には、「吉田製作所」というフォルダ名が付されたフォルダが作成されており、更にその下には案件番号（「１２３４５」）のフォルダが作成されている。なお、このフォルダ階層構造には、上述したように、プロジェクトに関する文書のうち、見積書および計画書以外の文書（例えば、受注書、図面等）をその文書の種類ごとに格納することになっているため、文書の種類ごとにフォルダを作成する必要がある。この文書の種類ごとのフォルダは、必要に応じてユーザ自身が作成することになっており、ユーザ自身が格納する文書の種類に対応したフォルダ名を付することになっている。図３に示す例においては、案件番号である「１２３４５」というフォルダ名が付されたフォルダの下の階層には、文書の種類ごとに３つのフォルダが作成されており、それぞれに、「受注書」、「図面」、「検査書」というフォルダ名が付されている。

ユーザが図３に示すフォルダ階層構造が構築されたファイルサーバ１２に、「見積書」の電子ファイルを保管する場合、まず、最上位階層のフォルダの中から「見積書」フォルダを見つけ出し、そこからより下の階層のフォルダを下って、目的の年がフォルダ名として付されたフォルダを見つけ出してこれを展開し、さらに、そこから下の階層を下って、目的の月がフォルダ名として付されたフォルダを見つけ出してこれを開き、そこに「見積書」の電子ファイルを格納する。図３は、「３月」フォルダに、「12345.jpg」、「23456.jpg」、および「34567.jpg」がファイル名として付された３つの「見積書」の電子ファイル３２〜３４がjpeg形式で格納される態様を示している。

同様に、ユーザが「計画書」の電子ファイルを保管する場合、まず、最上位階層のフォルダの中から「計画書」フォルダを見つけ出し、そこからより下の階層のフォルダを下っていって、目的の顧客名が付されたフォルダを見つけ出してこれを開き、そこに「計画書」の電子ファイルを格納する。図３は、「吉田製作所」フォルダ、「小原工業」フォルダ、および「中村」フォルダに、それぞれ、「12345.jpg」、「33333.jpg」、および「22222.jpg」がファイル名として付された「計画書」の電子ファイル４２〜４４がjpeg形式で格納される態様を示している。

同様に、ユーザが案件番号「１２３４５」のプロジェクトに関する見積書および計画書以外の文書の電子ファイルを保管する場合、まず、最上位階層のフォルダの中から「プロジェクト」フォルダを見つけ出し、そこからより下の階層のフォルダを下っていって、目的の顧客名が付されたフォルダを見つけ出し、さらに、そこからより下の階層のフォルダを下って、目的の案件番号がフォルダ名として付されているフォルダを見つけ出し、さらに、そこからより下の階層のフォルダを下って、文書の種類がフォルダ名として付されたフォルダを開き、そこに該当する文書の電子ファイルを格納する。図３は、「受注書」フォルダに「受注書.jpg」が、「図面」フォルダに「設計図ver1.jpg」が、「検査書」フォルダに「検査結果20080329.jpg」が、それぞれ電子ファイル５２〜５４として格納される態様を示している。

ここで、図３に例示したフォルダ階層構造および図２を参照しながら、ファイルサーバ１２のファイル更新監視部２４およびファイルアップロード部２６の機能について具体的に説明する。

ファイル更新監視部２４は、予め設定された監視タイミング（所定の時間間隔）をもって、間欠的に（例えば５分ごとに）動作して、記憶装置２２を監視する。ファイル更新監視部２４は、クライアント装置からの電子ファイルの送信によって記憶装置２２内のファイル情報が更新されたファイルを検出すると、ファイルアップロード部２６に対し、更新に係るファイルをドキュメント管理サーバ１４に転送するよう指示する。当該指示を受けたファイルアップロード部２６は、該当するファイルについて「位置情報」を生成し、当該ファイルをその「位置情報」とともにファイル転送サーバ１４にアップロードする。次に、ファイルサーバ１２の実行する処理について、図４に示す動作フローチャートをもとに、より詳細に説明する。

図４は、ファイルサーバ１２の動作を示すフローチャートである。ファイルサーバ１２では、まず、ステップ１００において、予め設定された監視タイミングであるか否かが判断され、監視タイミングであると判定された場合には（ステップ１００、Ｙｅｓ）、ステップ１０２において、記憶装置２２内のファイル情報が更新されたか否かを判定する。ここで、ファイル情報の更新とは、新規なファイル名を付された電子ファイルが新たにフォルダに格納されたことに加え、既にフォルダに格納されていたファイルの内容が上書きされたことを含む概念である。ファイル情報が更新されたか否かは、ＯＳのファイルシステムが一般的に有しているファイルやフォルダのタイムスタンプ情報（作成日、更新日の情報）が前回の動作時よりも新しい場合に更新されたものと判断することができる。ファイル情報が更新されていない場合には（ステップ１０２、Ｎｏ）、再び、ステップ１００に戻り、次の監視タイミングが来るまでステップ１００の判定が繰り返される。一方、ファイル情報が更新されている場合には（ステップ１０２、Ｙｅｓ）、ステップ１０４に進み、更新に係るファイルについて「位置情報」を生成し、当該ファイルを、生成した「位置情報」とともにドキュメント管理サーバ１４にアップロードした後、ステップ１００に戻る。

ここで、本実施形態におけるファイルの「位置情報」とは、更新されたファイルに関して階層関係にあるフォルダ名とファイル名を1行にまとめて記述した情報を意味する。仮に、図３に示す例において、「見積書」のフォルダツリー内において、ファイル３２が更新された場合には、対応する「位置情報」として、「\見積書\2006年\3月\12345.jpg」が生成され、この「位置情報」がファイル３２とともにドキュメント管理サーバ１４にアップロードされる。ドキュメント管理サーバ１４においては、この「位置情報」を利用してメタデータが自動的に生成され、ファイル３２に関連づけられた形で登録される。以上、本実施形態におけるファイルサーバ１２について説明してきたが、次に、本実施形態におけるドキュメント管理サーバ１４について説明する。

図５は、本実施形態におけるドキュメント管理サーバ１４の機能ブロック図を示す。ドキュメント管理サーバ１４は、先に説明したファイルサーバ１２と同様に、パーソナル・コンピュータ、またはワークステーションなどとして構成されるものであり、システム・コントローラとして機能するＣＰＵ、アプリケーション・ソフトウェアの実行空間を与えるためのＲＡＭ、ならびに処理を行うためのデータまたはプログラムなどを格納したＲＯＭ等のメモリ、およびＮＩＣを含むネットワーク・インターフェースなどの各種インターフェース部、ならびに、ハードディスク装置や光ディスク装置などによって構成される図示しない記憶装置を備えている。

ドキュメント管理サーバ１４は、さらに、ファイリング制御部６２と、ルール管理部６４と、メタデータ管理部６６と、ファイル管理部６８とを備えており、これらの機能手段は、ドキュメント管理サーバ１４において、ＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、その他の適切なオペレーティング・システム（ＯＳ）の管理下で、Ｃ、Ｃ＋＋、ＶｉｓｕａｌＣ＋＋、ＶｉｓｕａｌＢａｓｉｃ、Ｊａｖａ（登録商標）などのオブジェクト指向のプログラミング言語により記述された各種アプリケーション・プログラムが実行されることによって実現される。

上述したように、ドキュメント管理サーバ１４は、ファイルサーバ１２からネットワーク２０を介して更新されたファイルとその「位置情報」を受け取る。ファイリング制御部６２は、ファイルサーバ１２からアップロードされた「位置情報」を利用して、自動的にメタデータを生成する。メタデータの生成は、ルール管理部６４がテーブル管理するルールに基づいて行われる。次に、ファイリング制御部６２は、生成したメタデータとファイルとを関連付けてテーブル管理する。その際、ファイリング制御部６２は、各ファイルに対しユニークなファイル識別子を付与し、これを生成したメタデータと関連付けてメタデータ管理部６６が備えるテーブルに格納する。さらに、ファイリング制御部６２は、ファイルサーバ１２からアップロードされたファイルをファイル管理部６８に保管すると共に、ファイル管理部６８において、当該ファイルの格納場所とファイル識別子とを関連付けてテーブル管理する。以上、ドキュメント管理サーバ１４の機能手段について概説したが、次に、ドキュメント管理サーバ１４が実行する処理について、図６に示す動作フローチャートをもとに、より詳細に説明する。

図６は、ドキュメント管理サーバ１４の動作を示すフローチャートである。ドキュメント管理サーバ１４においては、まず、ステップ２００において、ファイルサーバ１２から更新されたファイルおよびその「位置情報」がアップロードされたか否かが判断され、アップロードされていない場合には（ステップ２００、Ｎｏ）、この判断が繰り返される。ステップ２００において、アップロードされたと判断した場合には（ステップ２００、Ｙｅｓ）、ステップ２０２において、アップロードされた「位置情報」に基づいてメタデータの生成ルールが検索される。メタデータの生成ルールの検索は、ルール管理部６４のメタデータ生成ルールテーブルを用いて実行される。図７は、ルール管理部６４が備えるメタデータ生成ルールテーブルを例示する。

次に、ステップ２０４において、検索されたルールに基づいて、「位置情報」からメタデータが生成されると共に、ユニークなファイル識別子が付与され、両者が関連付けられてメタデータ管理部６６のメタデータテーブルに格納される。図８乃至図１０は、メタデータ管理部６６において、対応するルールごとに用意されたメタデータテーブルを例示する。

次に、ステップ２０６において、ファイルサーバ１２からアップロードされたファイルをファイル管理部６８に保管して、ステップ２０８に進む。ステップ２０８においては、当該ファイルの格納場所とファイル識別子とを関連付けてファイル管理部６８が備えるテーブルに格納した後、ステップ２００に戻る。図１１は、ファイル管理部６８が備えるファイリング情報テーブルを例示する。以上、ドキュメント管理サーバ１４が実行する処理について、図６に示す動作フローチャートをもとに説明してきたが、次に、図３に例示したフォルダ階層構造、ならびに図７乃至図１０に例示した各種テーブルを参照しながら、本実施形態におけるドキュメント管理サーバ１４が実行する処理について、より具体的に説明する。

ここでは、図３に示したファイルサーバ１２の記憶装置２２内に保管された電子ファイルが更新された場合を例にとって具体的に説明する。ファイルサーバ１２内において、「見積書」フォルダツリーの最下位階層のファイル３２〜３４が更新された場合を想定する。ファイル３２〜３４の更新が検知されると、ファイルサーバ１２は、ファイル３２〜３４をそれぞれの「位置情報」とともにドキュメント管理サーバ１４にアップロードする。具体的には、ファイル３２とその位置情報「\見積書\2006年\3月\12345.jpg」、ファイル３３とその位置情報「\見積書\2006年\3月\23456.jpg」、および、ファイル３４とその位置情報「\見積書\2006年\3月\34567.jpg」が、それぞれ、ドキュメント管理サーバ１４にアップロードされる。

ドキュメント管理サーバ１４にファイル３２〜３４の「位置情報」がアップロードされると、ファイリング制御部６２は、ルール管理部６４が備えるメタデータ生成ルールテーブルを利用して、対応するルールを検索する。具体的には、アップロードされた「位置情報」の中から最上位階層のフォルダのフォルダ名を抽出し、メタデータ生成ルールテーブルの中から当該フォルダ名に対応付けられて格納されているルールを検索する。

図７は、ルール管理部６４が備えるメタデータ生成ルールテーブル７０を例示する。メタデータ生成ルールテーブル７０においては、最上位のフォルダ名ごとにメタデータの生成ルールがテーブル管理されている。具体的には、ファイルサーバからアップロードされる「位置情報」の中に含まれる最上位階層のフォルダ名ごとにメタデータの生成ルールとその識別子（ルールiｄ）が対応付けられており、さらに、当該ルールに基づいて生成されるメタデータの格納先が対応付けられている。

メタデータ生成ルールテーブル７０に格納されたルールにおいて、％と％の間に記載された部分が「メタデータ名」を意味している。また、「num (---)」は数値への変換を、「base (---)」はファイルの拡張子を取り除く変換を、「text (---)」はテキストへの変換を、それぞれ意味している。さらに加えて、「filename」はファイル名を、「f[n]」はフォルダの第n階層を意味している。ここでフォルダの第ｎ階層とは、上記最上位フォルダ（図３の例では「見積書」「計画書」「プロジェクト」）の下を第１階層として数えた値である。また、「最上位（階層の）フォルダ」とは必ずしもＯＳのファイルシステムが管理する最上位（ルート）フォルダではなく、このドキュメント管理システムにおいて管理しようとするフォルダの中で最上位階層のフォルダである。

なお、本実施形態においては、ユニークなファイル識別子の生成ルールについても、併せて、メタデータ生成ルールテーブル７０で管理しており、他のメタデータとともにファイル識別子を生成する。図７に示すテーブル中、「ファイルid (auto)」は自動でユニークなファイル識別子を生成する所定の式を意味している。

ここで、ファイル３２〜３４について検討すれば、最上位階層のフォルダのフォルダ名は、いずれも、「見積書」であるので、フォルダ名「見積書」に対応付けられて格納された「ルールid＝３２１」のルールが抽出され、ファイリング制御部６２において当該ルールに基づいてメタデータが生成されると同時に、各ファイルについてユニークなファイル識別子がメタデータの一つとして生成される。「ルールid＝３２１」においては、「年」、「月」、「案件ＩＤ」、および「文書タイプ」の４つのメタデータとともに、ユニークなファイル識別子としての「ファイルＩＤ」が生成される。

例えば、ファイル３２に関して、「ファイルＩＤ」については、所定の式を用いてユニークな識別子（５４３）が算出される。「年」については、フォルダの第１階層のフォルダ名（２００６年）が数値（２００６）へ変換される。「月」については、フォルダの第２階層のフォルダ名（３月）が数値（３）へ変換される。「案件ＩＤ」については、ファイル名（12345.jpg)からファイルの拡張子（.jpg）が取り除かれたのち、数値（12345）へ変換される。「文書タイプ」については、「見積書」とされる。ファイル３３およびファイル３４についても同様の手順でメタデータおよびファイル識別子が生成される。ファイリング制御部６２は、各ファイルにつきメタデータおよびファイル識別子を生成すると、それらをメタデータ生成ルールテーブル７０において格納先として指定されたメタデータ管理部６６の「mitsumori」テーブルに格納する。図８は、「mitsumori」テーブル８０を例示する。「mitsumori」テーブル８０においては、ファイル３２、３３、３４のそれぞれのメタデータ（年、月、案件ＩＤ、文書タイプ）と、ユニークなファイル識別子「５４３」、「５４２」、「５４１」とが関連付けられて格納されている。

次に、ファイルサーバ１２内において、「計画書」フォルダツリーの最下位階層のファイル４２〜４４が更新された場合を想定する。ファイル４２〜４４の更新が検知されると、ファイルサーバ１２は、ファイル４２〜４４をそれぞれの「位置情報」とともにドキュメント管理サーバ１４にアップロードする。具体的には、ファイル４２とその位置情報「\計画書\吉田製作所\12345.jpg」、ファイル４３とその位置情報「\計画書\小原工業\33333.jpg」、および、ファイル４４とその位置情報「\計画書\中村\22222.jpg」が、それぞれ、ドキュメント管理サーバ１４にアップロードされる。

ドキュメント管理サーバ１４にファイル４２〜４４の「位置情報」がアップロードされると、ファイリング制御部６２は、これらの「位置情報」の中の最上位階層のフォルダのフォルダ名に基づいてルールを検索する。

ここで、ファイル４２〜４４の場合、最上位階層のフォルダのフォルダ名は、いずれも、「計画書」であるので、図７に示すメタデータ生成ルールテーブル７０の中から、フォルダ名「計画書」に対応付けられて格納された「ルールid＝２５０」のルールが抽出され、ファイリング制御部６２において当該ルールに基づいてメタデータが生成されると同時に、各ファイルについてユニークなファイル識別が生成される。図７に示されるように、「ルールid＝２５０」においては、「顧客名」、「案件ＩＤ」、および「文書タイプ」の３つのメタデータとともに「ファイルＩＤ」が生成される。

例えば、ファイル４２に関して、「ファイルＩＤ」については、所定の式を用いてユニークな識別子（１２３）が算出される。「顧客名」については、フォルダの第１階層のフォルダ名（吉田製作所）がテキスト化される。「案件ＩＤ」については、ファイル名（12345.jpg)からファイルの拡張子（.jpg）が取り除かれたのち、数値（12345）へ変換される。「文書タイプ」については、「計画書」とされる。ファイル４３および４４についても同様の手順でメタデータおよびファイル識別子が生成される。ファイリング制御部６２は、各ファイルにつきメタデータおよびファイル識別子を生成すると、それらをメタデータ生成ルールテーブル７０において格納先として指定されたメタデータ管理部６６の「keikakusho」テーブルに格納する。図９は、「keikakusho」テーブル８２を例示する。「keikakusho」テーブル８２においては、ファイル４２、４３、４４のそれぞれのメタデータ（顧客名、案件ＩＤ、文書タイプ）と、ユニークなファイル識別子「１２３」、「１２２」、「１２１」とが関連付けられて格納されている。

次に、ファイルサーバ１２内において、「プロジェクト」フォルダツリーの最下位階層のファイル５２〜５４が更新された場合を想定する。ファイル５２〜５４の更新が検知されると、ファイルサーバ１２は、ファイル５２〜５４をそれぞれの「位置情報」とともにドキュメント管理サーバ１４にアップロードする。具体的には、ファイル５２とその位置情報「プロジェクト\吉田製作所\12345\受注書\受注書.jpg」、ファイル５３とその位置情報「プロジェクト\吉田製作所\12345\図面\設計図ver1.jpg」、および、ファイル５４とその位置情報「プロジェクト\吉田製作所\12345\検査書\検査結果20080329.jpg」が、それぞれ、ドキュメント管理サーバ１４にアップロードされる。

ドキュメント管理サーバ１４にファイル５２〜５４の「位置情報」がアップロードされると、ファイリング制御部６２は、これらの「位置情報」の中の最上位階層のフォルダのフォルダ名に基づいてルールを検索する。

ここで、ファイル５２〜５４の場合、最上位階層のフォルダのフォルダ名は、いずれも、「プロジェクト」であるので、図７に示すメタデータ生成ルールテーブル７０の中から、フォルダ名「プロジェクト」に対応付けられて格納された「ルールid＝２００」のルールが抽出され、ファイリング制御部６２において当該ルールに基づいてメタデータが生成されると同時に、各ファイルについてユニークなファイル識別子が生成される。図７に示されるように、「ルールid＝２００」においては、「顧客名」、「案件ＩＤ」、および「文書タイプ」の３つのメタデータとともにユニークなファイル識別子としての「ファイルＩＤ」が生成される。

例えば、ファイル５２に関しては、「ファイルＩＤ」については、所定の式を用いてユニークな識別子（３４５）が算出される。「顧客名」については、フォルダの第１階層のフォルダ名（吉田製作所）がテキスト化される。「案件ＩＤ」については、フォルダの第２階層のフォルダ名（12345）がテキスト化される。「文書タイプ」については、フォルダの第３階層のフォルダ名（受注書）がテキスト化される。ファイル５３および５４についても同様の手順でメタデータおよびファイル識別子が生成される。ファイリング制御部６２は、各ファイルにつきメタデータおよびファイル識別子を生成すると、それらをメタデータ生成ルールテーブル７０において格納先として指定されたメタデータ管理部６６の「project」テーブルに格納する。図１０は、「project」テーブル８４を例示する。「project」テーブル８４においては、ファイル５２、５３、５４のそれぞれのメタデータ（顧客名、案件ＩＤ、文書タイプ）と、ユニークなファイル識別子「３４５」、「３４４」、「３４３」とが関連付けられて格納されている。

なお、図３について上述したように、「プロジェクト」フォルダツリーの最下位階層のファルダは、ユーザによって文書タイプごとに作成されるものであるが、運用状況によっては、ユーザが勝手にテンポラリフォルダを作成して独自のフォルダ名を付与してしまうことが予想される。このような状況を放置すると、データベース上にシステム管理者の予定しない「文書タイプ」がメタデータとして登録されてしまうことになる。本実施形態においては、このような事態を回避するために、文書タイプごとに作成されるフォルダのフォルダ名について、予め決めたものだけを受け付けるようにすることが好ましい。以下この点について図１１を参照して説明する。

図１１は、「プロジェクト」フォルダの階層構造において、ユーザによって作成が許可されている「文書タイプ」フォルダのフォルダ名を制限するために使用されるフォルダ名制限テーブル８５を例示する。図１０について上述したように、「ルールid＝２００」においては、フォルダの第３階層のフォルダ名がテキスト化されてなるメタデータが「文書タイプ」としてメタデータ管理部６６の「project」テーブルに格納されるが、この際、図１１に示すフォルダ名制限テーブル８５が参照される。ユーザが付したフォルダ名がシステム管理者の予定しないもの（例えば、「設計図」）であった場合でも、メタデータを生成する際にフォルダ名制限テーブル８５が参照され、自動的に正規の文書タイプ（例えば、「図面」）がメタデータとして登録される。なお、図１１中「*」はワイルドカードを表しており、任意の文字列と置換される。例えば「受注書」「受注管理」「受注物」というフォルダ名は全て「受注*」と合致し、文書タイプは「受注書」となる。また、このフォルダ名制限テーブルは上から順に適用され、「受注*」「図面」「設計図」「検査書」のいずれにも合致しないフォルダ名のみが「*」と合致したとして「その他」文書タイプが割り当てられる。

上述したように、メタデータ管理部６６には対応するルールごとにテーブルが用意されており、ファイリング制御部６２は、各ファイルについて、ユニークなファイル識別子とメタデータを関連付けて各テーブルに格納した後、ファイル本体をファイル管理部６８に保管する。その際、ファイリング制御部６２は、ファイル管理部６８に用意されるファイリング情報テーブルに、ファイルの格納場所とそのファイルのユニークな識別子（ファイルＩＤ）とを関連付けて格納する。図１２は、ファイル管理部６８に用意されたファイリング情報テーブル９０を例示する。ファイリング情報テーブル９０には、「ファイルＩＤ」と「ファイル格納場所」とが関連付けられて格納されている。図１１に示すように、本実施形態においては、「ファイルＩＤ」と、「対応ルール」、「更新日時」、「位置情報」とを関連付けられて格納することもできる。

以上、本実施形態の電子ドキュメント管理システム１０について説明してきたが、電子ドキュメント管理システム１０においては、ユーザは、単に、ファイルサーバ１２にファイルを保存する行為だけが要求され、メタデータに係る追加的な入力作業を行う必要がない。電子ドキュメント管理システム１０においては、所定のメタデータが自動的に生成されるため、システムの運用がユーザの規律意識に左右されることなく確実に遂行され、その結果、後のファイルの利活用が容易になる。また、ファイルサーバ１２上でファイルが更新される度に、更新された内容のファイルに対しユニークな識別子が付与されてデータベースに登録されるため、例えば、ファイルサーバ１２上の、同じ場所の同じファイル名に上書きしたファイルについても、上書き前のファイルとは別の識別子を有する別ファイルとしてデータベースに登録され、ファイルの更新の履歴を管理することができる。

また、本実施形態の電子ドキュメント管理システム１０においては、文書タイプごとに対応するルールに基づいてメタデータが生成され、当該ルールごとに別テーブルでメタデータが管理されるため、ファイルがさまざまなフォルダに分かれて保管されている場合であっても、これらのメタデータテーブルを利用することによって、同じ案件に係る異なる種類の文書や、同じ顧客とやり取りした複数種の文書などについて、所望のメタデータを利用して横串で検索することが可能になる。

上述した実施形態の各機能は、アセンブリ言語、Ｃ、Ｖｉｓｕａｌ Ｃ、Ｃ＋＋、Ｖｉｓｕａｌ Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなど、レガシープログラミング言語やオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。

これまで本発明を、実施形態をもって説明してきたが、本発明は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

電子ドキュメント管理システムを示す図。 ファイルサーバの機能ブロック図。 ファイルサーバの記憶装置内に構築されるフォルダ階層構造を示す図。 ファイルサーバの動作を示すフローチャート。 ドキュメント管理サーバの機能ブロック図。 ドキュメント管理サーバの動作を示すフローチャート。 メタデータ生成ルールテーブルを示す図。 「mitsumori」テーブルを示す図。 「keikakusho」テーブルを示す図。 「project」テーブルを示す図。 フォルダ名制限テーブルを示す図。 ファイリング情報テーブルを示す図。

符号の説明

１０…電子ドキュメント管理システム、１２…ファイルサーバ、１４…ドキュメント管理サーバ、１６…画像形成装置、１８…パーソナル・コンピュータ、２０…ネットワーク、２２…記憶装置、２４…ファイル更新監視部、２６…ファイルアップロード部、３０…フォルダ、４０…フォルダ、５０…フォルダ、３２〜３４…電子ファイル、４２〜４４…電子ファイル、５２〜５４…電子ファイル、６２…ファイリング制御部、６４…ルール管理部、６６…メタデータ管理部、６８…ファイル管理部、７０…メタデータ生成ルールテーブル、８０…「mitsumori」テーブル、８２…「keikakusho」テーブル、８４…「project」テーブル、８５…フォルダ名制限テーブル

Claims (7)

1. 複数のクライアント装置が共有する電子ドキュメントを保管するファイルサーバと、該ファイルサーバにネットワーク接続されたドキュメント管理サーバとを含む電子ドキュメント管理システムであって、
   前記ファイルサーバは、
   更新されたファイルを検出する手段と、
   更新されたファイルおよび該ファイルについての位置情報を前記ドキュメント管理サーバにアップロードする手段と
   を含み、
   前記ドキュメント管理サーバは、
   前記ファイルサーバからアップロードされた前記位置情報に対して文書の種類ごとに用意されたルールを適用してメタデータを生成する手段と、
   前記ファイルサーバからアップロードされた前記ファイルに対してユニークな識別子を付与する手段と、
   前記メタデータと前記ユニークな識別子とを関連付けて前記ルールごとにテーブル管理する手段と
   前記ユニークな識別子と前記ファイルの保管場所とを関連付けてテーブル管理する手段とを含む、
   電子ドキュメント管理システム。
2. 前記位置情報は、前記ファイルに関して階層関係にあるフォルダ名とファイル名を記述した情報である、請求項１に記載の電子ドキュメント管理システム。
3. 複数のクライアント装置が共有する電子ドキュメントを保管するファイルサーバにネットワーク接続されたドキュメント管理サーバであって、
   前記ドキュメント管理サーバは、
   前記ファイルサーバから更新されたファイルおよび該ファイルについての位置情報を取得する手段と
   取得した前記位置情報に対して文書の種類ごとに用意されたルールを適用してメタデータを生成する手段と、
   取得した前記ファイルに対してユニークな識別子を付与する手段と、
   前記メタデータと前記ユニークな識別子とを関連付けて前記ルールごとにテーブル管理する手段と、
   前記ユニークな識別子と前記ファイルの保管場所とを関連付けてテーブル管理する手段とを含む、
   ドキュメント管理サーバ。
4. 前記位置情報は、前記ファイルに関して階層関係にあるフォルダ名とファイル名を記述した情報である、請求項３記載のドキュメント管理サーバ。
5. ファイルサーバに保管される複数のクライアント装置が共有するドキュメントの管理を該ファイルサーバにネットワーク接続されたドキュメント管理サーバに実行させるコンピュータ実行可能な方法であって、該方法は、
   ドキュメント管理サーバにおいて、
   前記ファイルサーバから更新されたファイルおよび該ファイルについての位置情報を取得するステップと
   取得した前記位置情報に対して文書の種類ごとに用意されたルールを適用してメタデータを生成するステップと、
   取得した前記ファイルに対してユニークな識別子を付与するステップと、
   前記メタデータと前記ユニークな識別子とを関連付けて前記ルールごとにテーブルに登録するステップと、
   前記ユニークな識別子と前記ファイルの保管場所とを関連付けてテーブルに登録するステップを備えた方法。
6. 前記位置情報は、前記ファイルに関して階層関係にあるフォルダ名とファイル名を記述した情報である、請求項５に記載の方法。
7. ドキュメント管理サーバに、請求項５または６のいずれか一項に記載の方法を実行させるためのコンピュータ実行可能なプログラム。

Images