JP5319133B2 - 文書管理システム、文書管理方法およびプログラム - Google Patents

Description

本発明は、文書を管理する文書管理システムに関する。

従来、文書のバージョンを検索する技術として、特許文献１に記載されているように、文書管理システムに保管される文書について、直前及び直後のバージョンの文書ＩＤを関連付けて保存しておく文書管理システムが知られている。そのような文書管理システムによって、ある特定の文書について関連付けられている直前及び直後のバージョンの文書ＩＤを順に辿ることで、特定のバージョンの文書を取得することができる。

従来の文書管理システムにおいて、文書作成や編集、複製などの各操作が管理されていて、各操作によりバージョンが更新されると、文書管理システムにより新しい文書ＩＤを付与された文書が生成される。しかしながら、例えば、メーラによるメール送信やローカル環境にダウンロードした後の修正等のように、文書管理システムの機能を使用せずに文書が生成、複製、更新された場合には、文書管理システムが、各操作の実行のイベントを検知できない。そのため、関連性を保持するための文書ＩＤを文書管理システムが生成、付与及び保管することができないので、元の文書と新しい文書との前後関係を保持することができず、目的のバージョンの文書を取り出すことができなくなってしまう。

一般オフィスのイントラネット内で文書管理システムが運用されている場合等に、そのようなケースが多く発生することが考えられる。例えば、イントラネットの外部に持ち出すために、文書管理システムから取り出した文書をノートＰＣやリムーバブルメディアにコピーする場合がある。そのような場合に、再びイントラネットに接続した環境に文書を置いたとしても、文書管理システムは、その文書を検知することができない。即ち、文書管理システムにおいて文書ＩＤで管理された状態ではないので、文書ＩＤでその文書を特定することができない。従って、前バージョンからバージョン関係を辿ることができず、関連バージョンを検索することができない。

また、ダウンロードした文書を他部門に公開するために部門間共有サーバに保存したり、メール等で他部門のメンバーに送信したりした場合においても、文書管理システムはその文書がメール転送されたことを検知できない。即ち、文書管理システム内で文書ＩＤで管理された状態ではなくなり、文書ＩＤでその文書を特定できないので、メールで転送された文書を、文書管理システムにおける文書との前後関係で管理することができない。また、文書管理システムは、転送された文書のロケーション情報も保持していないので、関連バージョンを検索することができない。

また、他の従来技術では、同一のファイル名又は文書名であることを前提に同一文書として扱い、文書の更新日付でバージョン関係を判断する場合もある。しかしながら、そのような場合に、ファイル名又は文書名を使用者が別名で保存してしまうと、同一派生文書と判断することができなくなってしまう。更に、メールにおける送受信において、一般的に更新日付などの属性情報は保持されない場合が多く、バージョン関係を属性から判断することは難しい。従って、そのような場合では、正規のバージョン関係を検知する方法がなく、バージョン関連情報が偽装されてしまうリスクがある。
特開平０９−３４７６３号公報（段落［００６７］）

そこで、上記の点に鑑み、本発明は、ネットワーク内に分散している共通の署名を有する文書について、その前後関係を自動的に判別し、バージョン関係を明らかにすることができる文書管理システムを提供することを目的とする。

上記課題を解決するため、本発明に係る文書管理システムは、文書の格納位置を示すロケーション情報を含む文書情報と当該文書の署名情報とが関連付けられて登録される記憶手段を備える文書管理システムであって、ユーザにより指定された指定文書を受信する受信手段と、前記受信手段により受信した前記指定文書から、署名情報を抽出する抽出手段と、前記記憶手段に登録されている文書の署名情報を参照し、前記指定文書のバージョンの異なる文書として、前記抽出手段により抽出された前記署名情報と一致する署名情報を有する文書を検索する検索手段と、文書のバージョン情報を前記署名情報に含まれる署名に基づいて決定する決定手段と、前記検索手段による検索結果に基づき、前記指定文書および前記指定文書のバージョンの異なる文書の文書情報と、前記署名情報に基づき決定されるバージョン情報とを関連付けて表示するための制御を行う表示制御手段とを備え、前記バージョン情報により、文書が正規バージョン又は派生バージョンであるかが示され、前記決定手段は、文書のバージョン情報を決定する際に、文書の署名に対応付いていない編集履歴が無い場合には、最後に付与された署名に基づき、前記正規バージョンとしてバージョン情報を決定し、文書の署名に対応付いていない編集履歴がある場合には、当該編集履歴に含まれる日付情報に基づき、前記派生バージョンとしてバージョン情報を決定し、前記表示制御手段は、文書情報を前記正規バージョン又は前記派生バージョンであることを識別可能に表示し、さらに文書情報の存在する文書ロケーションもあわせて表示するように制御する、ことを特徴とする。

本発明によれば、ネットワーク内に分散している同一文書について、その前後関係を自動的に判別し、バージョン関係を明らかにすることができる。

以下に、本発明を実施するための最良の形態について、図面を参照しながら詳しく説明する。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。

図１は、本実施形態に係る検索装置を含む文書管理システムの全体構成を示す図である。本発明においては、例えば、ユーザに対して文書管理システムの機能を提供するための文書管理アプリケーションを、ウェブサービス（Ｗｅｂアプリケーション）として提供する。図１に示すように、文書管理システムは、ストレージサーバ１００１と、検索サーバ１００５と、クライアント端末１００６とを含んでいる。ストレージサーバ１００１は、各種文書ファイルを記憶し、ネットワーク上の端末から文書に対してアクセスすることができる。クライアント端末１００６は、検索する元となる文書を指定する端末である。検索サーバ１００５は、インデキシングサービス１００２とバージョン検索サービス１００４とデータベース１００３を含んでいる。本実施形態においては、クライアント端末１００６は、ユーザ端末ともいう。

インデキシングサービス１００２は、ネットワーク上に分散している文書にアクセスし、文書の格納位置を示すロケーション情報を取得し、バージョン検索に必要なデータを文書から抽出・生成することによってインデキシングを行う。ここで、ロケーション情報とは、文書の場所を特定することができる情報をいう。例えば、ファイルサーバ上の文書であれば、ファイルサーバ名と共有フォルダから成る文書が格納されているネットワークパスと、文書名の組み合わせとなる。また、データベース内の文書であれば、ネットワーク上で一意に認識できるデータベースサーバ名と、データベースインスタンス名及びデータベース内のテーブル名と、プライマリキーの組み合わせとなる。データベース１００３は、インデキシングデータを文書のロケーション情報とともに格納している。

バージョン検索サービス１００４は、検索対象の文書から検索情報を抽出・生成し、データベース１００３に対して、検索した結果を判定して結果を返信する。本実施形態において、以上のサービス及びデータベースは１つのサーバ上に集約されずに、複数のサーバ上に構成することによって負荷を分散するようにしても良い。

図２は、図１におけるストレージサーバとクライアント端末のハードウエア構成の一例を示す図である。図２に示すホストコンピュータ１００は、ストレージサーバ１００１を構成するコンピュータ装置を示し、画像形成装置３００は、クライアント端末１００６を構成するコンピュータ装置を示している。また、図２に示すように、ホストコンピュータ１００と画像形成装置３００とが、ネットワーク等を介して通信できるように接続されている。

まず、ホストコンピュータ１００の構成について説明する。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当し、本実施形態のホストコンピュータ１００には一般的な情報処理装置のハードウェア構成を適用することができる。図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここで、ＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下、オペレーティングシステムのことをＯＳという。後述する各フローチャートの処理は、そのプログラムの実行により実現することができる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＰＲＴＣ２０８は、接続された画像形成装置３００との間の信号の交換を制御する。接続のための回線３１０には、ＬＡＮやＵＳＢ等、種々の接続形態を適用することができる。ネットワークコントローラ（ＮＣ）２１２はネットワークに接続され、ネットワークに接続された他の機器との通信制御処理を実行する。ここで、ネットワークを介して、更に他の画像形成装置、周辺機器と接続する構成であってもよい。

次に、画像形成装置３００の構成について説明する。図２に示すように、画像形成装置３００において、ＣＰＵ３０１は画像形成装置３００のＣＰＵであり、ＲＯＭ３０２や、外部メモリ３０３に記憶された制御プログラムに基づいて、システムバス３０４に接続される各ブロックを制御する。ＣＰＵ３０１の処理により生成された画像信号が、印刷部インタフェース３０５を介して、印刷部（画像形成装置エンジン）３０６に出力情報として出力される。また、ＣＰＵ３０１は、入力部３０７を介してホストコンピュータ１００との通信処理が可能であり、画像形成装置３００内の情報等をホストコンピュータ１００に通知できる。ＲＯＭ３０２内のプログラムＲＯＭには、ＣＰＵ３０１の制御プログラム等が格納されている。ＲＯＭ３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用するフォントデータ等が格納されている。ハードディスク等の外部メモリ３０３がない画像形成装置の場合に、ＲＯＭ３０２内のデータ用ＲＯＭには、ホストコンピュータ１００上で利用される情報等が格納されている。ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示されていない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御されている。外部メモリ３０３には、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等が格納されている。また、操作部３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。スキャナインタフェース３１２は、スキャナ部３１３から受取った画像データに対して、補正、加工、及び編集を行う。スキャナ部３１３は、原稿上の画像を露光走査して得られた反射光をＣＣＤに入力することで画像の情報を電気信号に変換する。更に、電気信号をＲ（赤）、Ｇ（緑）、Ｂ（青）の各色からなる輝度信号に変換し、輝度信号を画像データとして読み込む。ユーザが操作部３１１から読み取り開始を指示すると、スキャナ部３１３に原稿読み取り指示が与えられる。スキャナ部３１３は、原稿読み取り指示を受信すると原稿の読み取り動作を行う。なお、原稿の読み取り方法は不図示の原稿フィーダにセットされる自動送り方式の形態であってもよい。また、原稿を不図示のガラス面上に載せ、露光部を移動させることで原稿の走査を行う方法であってもよい。

図３は、図１に示すシステムで利用されるデータの構造を示す図である。図３に示すように、「状態１」は、文書を新規に作成した場合を示す。次に、承認、即ち、文書に対して電子署名の付与を行うと、「状態２」に示すように、「状態１」のデータの末尾に署名データが付与される。本実施形態においては、文書に対して最初に付与された署名データを「第１署名」ともいう。そのような署名処理は、クライアント端末１００６上にインストールされた文書編集アプリケーション又はストレージサーバの機能等を用いてユーザが付与するようにしても良い。また、一般的に、「状態２」における文書がバージョン１とされる。

また、本実施形態において、署名情報には、署名を付与する対象の文書に関するハッシュ値と、証明書とが記憶されている。また、本実施形態において、証明書には、証明書のシリアル番号や、証明書の発行元がどこのサーバであるかを示す情報や、証明書の保持者及び保持者の所属組織等に関する情報や、証明書の有効期間等の情報が記載されている。

更に、「状態２」から編集を行うと、編集データは、「状態３」のように編集内容が状態２の末尾に追加される。ここで、再度、承認、即ち、文書に対して電子署名の付与を行うと、「状態４」に示すように、「状態３」のデータの末尾に署名データが付与される。本実施形態においては、文書に対して２番目に付与された署名データを「第２署名」ともいう。その署名データの付与処理は、上記と同様、クライアント端末１００６上にインストールされた文書編集アプリケーション又はストレージサーバの機能等を用いてユーザが付与するようにしても良い。また、一般的に、「状態４」における文書がバージョン２とされる。本実施形態においては、新規に作成された文書（図３に示す状態１）に付与され、「第１署名」や「第２署名」のような複数の署名データを総称して「署名情報」という。本実施形態においては、以上のように、署名データによって、その文書に対して何度目に署名が付与されたかが識別可能となり、編集履歴と対応付けられることができる。

図４は、検索サーバのインデキシングサービスによるインデキシング処理の概要を示す図である。以下、図４を参照しながら、本実施形態におけるインデキシング処理の概要を説明する。

文書データ４００１は、バージョン１とみなされる文書データである。署名情報４００２は、文書データ４００１に付与されている全ての署名データを示し、署名データ４００２ａは、その内の最初の署名データを示している。文書データ４００３は、バージョン２とみなされる文書データである。署名情報４００４は、文書データ４００３に付与されている全ての署名データを示し、最初に付与された署名データ４００２ａと２番目に付与された署名データ４００４ｂを含んでいる。データベース１００３は、抽出された署名情報４００２又は４００４を文書のロケーション情報と共に格納している。

図５は、検索サーバにおけるインデキシングサービスのモジュール構成を示す図である。以下、図５を参照しながら、本実施形態におけるインデキシングサービスの各モジュールの役割を説明する。

モジュール５００１は、文書検知部であって、ネットワーク上の文書にアクセスし、アクセスした文書がインデキシングする必要があるか否かを判定することにより、インデキシング対象の文書を検知する。その場合の判定方法は、例えば、データベース１００３に登録されている同じロケーション情報を有する文書情報と比較し、更新日付が更新されているか否かや、文書ハッシュ値が変更されているか否か等を判定する。

モジュール５００２は、文書情報収集制御部であって、インデキシングに必要な文書情報の収集を制御する。モジュール５００３は、ロケーション情報取得部であって、モジュール５００１において検知された文書のロケーション情報を取得する。モジュール５００４は、属性情報取得部であって、モジュール５００１で検知された文書の更新日付などの属性情報を取得する。モジュール５００５は、ローカルバージョン情報取得部であって、モジュール５００１で検知された文書について、取得可能で文書において編集される度に蓄積される編集履歴を示すローカルバージョン情報が存在するか否かを判定する。ここで、存在すると判定された場合には、ローカルバージョン情報を取得する。

モジュール５００６は、署名データ取得制御部であって、モジュール５００１で検知された文書に付与されている署名データ取得処理を制御する。モジュール５００７は、文書取得部であって、モジュール５００６から指示された文書データを取得する。モジュール５００８は、署名データ抽出部であって、モジュール５００６から受信した文書データから署名データを抽出する。モジュール５００９は、データベースアクセス部であって、文書についての各種情報をデータベース１００３に格納し、又は、データベース１００３から取り出しを行う。データベース１００３には、モジュール５００２が収集した文書についての各種情報が格納されている。

図６は、検索サーバにおけるインデキシングサービスの処理の手順を示すフローチャートである。

まず、ステップＳ６００１において、モジュール５００１に示す文書検知部が、毎夜間など定期的にネットワーク上に存在する文書を探索する。その結果、文書が検出されれば、ステップＳ６００２において、モジュール５００１により、その文書が既にインデキシング済みか否かが判定される。その場合に、データベース１００３に登録されている同じロケーション情報を有する文書情報と比較することによって判定されても良い。また、例えば、更新日付が更新されているか否かや、文書ハッシュ値が変更されているか否かによって判定されても良い。ここで、検出された文書がインデキシング済みであると判定された場合に、そのまま処理は終了する。一方、インデキシングされていないと判定された場合に、モジュール５００２に示す文書情報収集制御部が、その文書についての各種情報を収集する。

ステップＳ６００３において、モジュール５００２は、モジュール５００３に示すロケーション情報取得部により、その文書のロケーション情報を取得する。次に、ステップＳ６００４において、モジュール５００４に示す属性情報取得部により、その文書の属性情報を取得する。ステップＳ６００５において、ローカルバージョン情報を有しているか否かが判定される。ここで、ローカルバージョン情報を有していると判定された場合には、ステップＳ６００６に進み、モジュール５００５に示すローカルバージョン情報取得部により、その文書のローカルバージョン情報を取得する。ローカルバージョン情報を有していないと判定された場合には、ステップＳ６００８に進む。

次に、ステップＳ６００８において、モジュール５００２は、モジュール５００６に示す署名データ取得制御部にその文書の署名データを取得するよう指示する。モジュール５００６は、モジュール５００７に示す文書取得部により文書を取得し、取得した文書をモジュール５００８に示す署名データ抽出部に送信する。モジュール５００８において、署名データが抽出され、モジュール５００２に返信される。モジュール５００２は、ステップＳ６００９〜Ｓ６０１２において収集された文書についての各種情報をモジュール５００９に示すデータベースアクセス部を介してデータベース１００３に格納する。ここでの各種情報とは、ロケーション情報、署名データ、属性情報、ローカルバージョン情報をいう。

図７は、検索サーバの検索サービスによる検索処理の概要を示す図である。以下、図７を参照し、本実施形態における検索処理の概要を説明する。

文書データ７００１は、バージョン２とみなされる文書データである。本実施形態においては、文書データ７００１が、ユーザにより検索元文書として指定されたとする。署名情報７００２に含まれる署名データ７００２ａは、文書データ７００１に付与されている署名データの内、最初に付与された署名データを示し、検索サービスにより、文書データ７００１から署名データ７００２ａが抽出される。検索サービスは、例えば、パターンマッチングによって、データベース１００３に登録されている署名データから、署名データ７００２ａと一致する署名データを含む署名情報を検索する。図７においては、その結果、署名情報７００３と７００５がヒットする例が示されている。署名情報７００３と署名情報７００５は、それぞれバージョン１、バージョン３とみなされる文書データ７００４と文書データ７００６の署名情報に対応している。署名情報７００５は、最初に付与された署名データ７００２ａ、２番目に付与された７００５ｂ、３番目に付与された７００５ｃを含んでいる。データベース１００３には、署名データに関連付けられたロケーション情報も格納されている。従って、検索サービスにより、ネットワーク上に散在する同一系列の文書について、そのバージョン番号と、実文書を特定可能なロケーション情報とをユーザに提示することができる。

図８は、検索サーバにおける検索サービスのモジュール構成を示す図である。以下、図８を参照して、本実施形態における検索サービスの各モジュールが担う役割を説明する。

モジュール８００１は、ユーザインタフェース部であって、ユーザが検索元の文書を指定し、又は、結果を受け取る。モジュール８００２は、検索元文書受信部であって、モジュール８００１により指定された検索元文書の文書データを受信する。モジュール８００３は、検索キー生成部であって、受信した文書を元に検索キーの生成制御をする。モジュール８００４は、署名データ抽出部であって、モジュール８００３に指定された文書データから署名データを抽出する。モジュール８００５は、データ検索部であって、モジュール８００３で生成された検索キーによって検索処理を実行する。モジュール８００６は、データベースアクセス部であって、データベース１００３にアクセスをする。モジュール８００７は、返信データ生成部であって、モジュール８００５から送信された検索結果を元に、返信データの生成を制御する。例えば、返信結果に含まれる文書のバージョン判定や、主系統の文書であるか否か等の判定はモジュール８００８を用いて判定し、返信データを生成する。モジュール８００８は、バージョン判定部であって、モジュール８００７から受信した文書の署名データを元に、バージョン判定処理を行う。例えば、図７に示す署名情報７００３は、文書に付与されている署名が１つであるのでバージョン１と判定し、署名情報７００５は、文書に付与されている署名が３つであるのでバージョン３と判定する。ここで、署名データに含まれる部門情報や署名者情報等から、付与されている署名がすべて同一の部門で付与された文書については、主系統の文書と判定する等の判定処理を行っても良い。モジュール８００９は、データ返信部であって、モジュール８００７で生成された返信データをモジュール８００１に返信する。

図９は、検索サーバにおける検索サービスの処理の手順を示すフローチャートである。

まず、ステップＳ９００１において、ユーザがモジュール８００１に示すユーザインタフェース部で検索元文書として指定した文書を、モジュール８００２に示す検索元文書受信部が受信する。次に、ステップＳ９００２において、モジュール８００３に示す検索キー生成部は、モジュール８００４に示す署名データ抽出部により文書に付与されている第１署名を抽出する。

次に、ステップＳ９００４において、モジュール８００３に示す検索キー生成部により、抽出した第１署名に基づき、検索用の情報を生成する。例えば、第１署名からハッシュ値を抽出することによって、検索用の情報を生成する。

ステップＳ９００５において、モジュール８００５に示すデータ検索部は、検索キー生成部により生成された検索キーを用いて、モジュール８００６に示すデータベースアクセス部を介し、データベース１００３から同一署名を検索する。ここで、検索キーとしてハッシュ値のみを使用する等、署名データを部分的に利用した場合には、モジュール８００５において、同一署名かどうかを判定するためにヒットした署名データと検索元文書から抽出した第１署名が同一であるか否かを確認する。

ステップＳ９００６において、モジュール８００５は、検索結果の有無を判定する。ここで、検索元文書の第１署名と同一の署名を含むデータが検出されなかった場合には、モジュール８００９に示すデータ返信部が、ヒットしなかった旨のデータをモジュール８００１に返信する。一方、検索元文書の第１署名と同一の署名を含むデータが検出された場合には、ステップＳ９００７に進み、モジュール８００８に示すバージョン判定部によりバージョン判定が行われる。バージョン判定については、後述する。バージョン判定が行われると共に、ステップＳ９００８において、返信データ生成部が、ヒット文書に対応する文書のロケーション情報、署名データ、属性情報、ローカルバージョン情報等をモジュール８００５を介して抽出し、返信データを生成する。ステップＳ９００９において、モジュール８００９は、生成された返信データを、検索結果としてモジュール８００１に返信する。結果を受信したモジュール８００１は、ユーザに対して検索結果を表示する。

図１０は、図９に示すバージョン判定処理の手順を示すフローチャートである。本フローチャートにおいて、文書毎に判定が行われる。即ち、ステップＳ１０００１〜Ｓ１０００９のループをモジュール８００８に入力される文書毎に繰り返し実行する。
まず、ステップＳ１０００２において、文書に付与されている署名をデータベース１００３から取り出す。

次に、第２署名から順に署名毎に、ステップＳ１０００３〜Ｓ１０００７のループが繰り返し実行される。まず、Ｓ１０００４において、１つ前の署名と同一のシステム（又は、同一の個人やその他のデータでも良い）の署名が行われているか否かが判定される。ここで、同一のシステムの署名が行われていると判定された場合には、ステップＳ１０００５に進む。ステップＳ１０００５において、直前の署名、即ち、その署名を付与されたバージョンから同じシステム（又は、個人やその他のデータでも良い）によって継続してメンテナンスされてきたと判断し、前バージョンの直系バージョンとして扱う。一方、同一のシステムの署名が行われていないと判定された場合には、ステップＳ１０００６において、前バージョンから派生したバージョンとして扱う。全ての署名データについて上記の処理が終了すると、ステップＳ１０００８において、その文書に付与されている署名データ数をカウントし、その文書のメジャーバージョン番号として決定する。

図１１は、本実施形態における検索ダイアログの表示の一例を示す図である。図１１に示す検索ダイアログは、ユーザが検索を行う場合に表示される。

テキストボックス１１００１は、検索元文書の文書パス及び文書名を入力し、又は、表示する。ボタン１１００２は、テキストボックス１１００１で表示される情報をファイルシステム等から探す際に用いられる文書参照ダイアログ表示ボタンである。文書参照ダイアログで指定された文書の文書パス及び文書名が、テキストボックス１１００１に入力される。ボタン１１００３は、押下されることによって、テキストボックス１１００１で指定された文書が検索サービスのモジュール８００２に送信され、検索処理が開始される。表示１１００４は、検索結果を表示する結果出力窓である。

図１２は、本実施形態における検索結果の一例を示す図である。検索結果は、図１１に示す表示１１００４において表示される。本実施形態において、検索サーバ１００５は、クライアント端末１００６において文書情報とバージョン情報とを関連付けて表示するように制御する表示制御手段としての役割を果たす。

アイコン１２００１は、バージョン１の文書を示す。表示１２００２は、バージョン１の文書が実際に存在する文書ロケーションの一覧を示し、ここでは、２文書存在することが示されている。アイコン１２００３は、バージョン２の文書を示す。表示１２００４は、バージョン２の文書が実際に存在する文書ロケーションの一覧を示し、ここでは、３文書存在することが示されている。また、その内の１つの文書が、検索元文書であることが示されている。

アイコン１２００５は、バージョン３の文書を示す。また、図１２に示すように、アイコン１２００５の傍に最新版である旨のマークが表示されているので、ユーザは、アイコン１２００５で示される文書が最新版であることを認識することができる。表示１２００６は、バージョン３の文書が実際に存在する文書ロケーションの一覧を示し、ここでは、１つの文書だけ存在することが示されている。

アイコン１２００７は、バージョン２の文書について変更が加えられている文書を示す。表示１２００８は、アイコン１２００７が示す文書が実際に存在するロケーションの一覧を示している。

表示１２００２、１２００４、１２００６、１２００８は、それぞれのロケーション情報を示す文字列が実文書に対してリンクされており、例えば、それらの文字列をマウス等で指定することによって、実文書をダウンロード又は表示することができる。

また、図１２に示す表示１２００２、１２００４、１２００６、１２００８は、文書パス及び文書名のみ表示されているが、例えば、更新日時や作成者、署名者、署名した組織等の情報が表示されても良い。また、アイコン１２００１、１２００３、１２００５を接続する太実線は、バージョン１の文書の署名と同じ部署、又は同じ署名者が署名してバージョン改訂を行ったことを表す主系統のバージョン（正規バージョン）であることを示している。一方、アイコン１２００３からアイコン１２００７を接続する細実線は、派生バージョンであることを示している。

以上のように、本実施形態においては、ネットワークに分散配置された文書のバージョンについて文書に付与された署名データを元に、自動的にそれらの関連を検出し、指定した文書に対する各バージョンの文書を検索し、又は、取り出しを行うことができる。その場合に、本実施形態においては、文書管理システムにより管理された操作だけでなく、文書管理システムが、格納先を管理できないメール等の様々な方法によってネットワークに分散配置された文書についても適用することができる。

更に、文書が異なる名前で保存されている場合においても、署名データを元に判定を行うことにより、確実に、同一文書又は派生文書を判定することができる。また、署名データという信頼性の高い情報を元に判定処理を行うので、改竄等が行われても、容易に検知することができ、正規のバージョン情報を信頼性高く判別することができる。

本実施形態においては、署名の付与については、ユーザの運用時に署名を付与することを前提としている。しかしながら、例えば、図１３に示すように、ストレージサーバ１００１に対して文書の入力処理又は文書の出力処理を実行する過程において、必ず、ストレージアクセスサービスを経由するようにし、署名が付与されるような構成とされても良い。

一般的に、基本的なクライアントサーバシステムにおいて、文書の編集を行う場合には、ストレージアクセスサービスのようなアクセスコンポーネントが、ストレージサーバからクライアント端末に文書をダウンロードする。また、編集後には、ストレージアクセスサービスのようなアクセスコンポーネントが、編集後の文書をストレージサーバに再格納する。従って、ストレージサーバ１００１に対する入出力時に、自動的に文書に署名が付与される。従って、ユーザが署名付与を意識せずに、ダウンロードしたファイルがネットワーク上に分散しても一度ストレージサーバに格納された文書であれば、検索が可能となり、ユーザの利便性、又は、検索対象の拡大を行うことができる。

以上の説明においては、署名でのみバージョン判定が行われている。図１４に示すように、ユーザが、文書を一度クライアント端末や別サーバに移動し、クライアント端末や別サーバのローカル環境において編集更新を行った場合に、ストレージサーバ１００１から出力された文書は、全て同じバージョンであると判定されている。

そこで、本実施形態においては、モジュール８００８に示すバージョン判定部が、最後に付与された署名の後に編集記録のある文書の場合に、署名データを元にバージョン判定を行い、更に、リビジョン生成処理を行うようにしても良い。

図１５は、本実施形態において、リビジョン生成処理の手順を示すフローチャートである。図１５に示すフローチャートは、図１０において説明したステップＳ１０００１〜Ｓ１０００８にステップＳ１５００１〜Ｓ１５００５を加えた処理を示している。

図１５に示すステップＳ１０００８まで、図１０と同様の処理を行い、その結果、バージョン番号が確定する。その後、ステップＳ１５００１において、最後に付与された署名後に、その文書に編集記録があるか否かが判定される。ここで、編集記録があると判定された場合に、ステップＳ１５００３に進み、次に利用できるローカルバージョン情報があるか否かが判定される。ここで、利用できるローカルバージョン情報があると判定された場合には、ステップＳ１５００４において、ローカルバージョン情報をリビジョン情報として採用する。一方、利用できるローカルバージョン情報がないと判定された場合に、ステップＳ１５００５で、同一バージョンと判定されている文書同士で文書の更新日付情報を比較し、古い日付の文書を小さいリビジョンとし、新しい日付の文書を大きいリビジョンとする。本フローチャートに示すように、文書の署名に対応付いていない編集記録がない場合には、最後に付与された署名により正規バージョンとしてバージョンが決定される。一方、文書の署名に対応付いていない編集記録がある場合には、派生バージョン（リビジョン）としてバージョンが決定される。

ローカルバージョン情報や更新日付によるバージョン判定方法は、署名データによる判定方法に比べると、信頼性の点で十分とはいえないので、結果を示すユーザインターフェースを工夫することによって参考情報である旨を示すようにしても良い。

図１６は、本実施形態における検索結果の他の例を示す図である。図１６に示すように、アイコン１６００１とアイコン１６００３を接続している破線によって、署名データのみによって判定された場合の実線と区別されている。

本実施形態において図１６に示すような結果表示を行うことによって、入出力時に強制的に署名の付与を行うストレージサーバ以外に分散した文書が、編集後に署名が行われないような場合にも、より詳細なバージョン判定を行うことができる。

以上のように、本実施形態の説明においては、ユーザが特定の文書を指定して検索した場合に、ネットワーク上から関連する同一系列の文書を取り出せるようにしている。ここで、検索機能だけでなく他の機能を用いている場合において本実施形態を適用するようにしても良い。例えば、ある文書の印刷を指示した場合に、図１１に示すボタン１１００３を押下した場合と同様の処理により関連文書の検索を行い、印刷指示した文書よりも最新の文書があるか否かを自動的に確認するようにしても良い。その場合に、指定文書よりも最新の文書が存在しなければ、そのまま印刷を実行する。一方、より新しい文書が存在するのであれば、ユーザインタフェース上にメッセージボックスを表示し、指定文書の代わりに最新文書を印刷するか否かをユーザに確認させるようにしても良い。その結果、印刷時に自動的に最新文書か否かの判定が行われることにより、誤って古い文書を印刷し、再度印刷し直すということを防ぐことができる。また、印刷前に、類似文書を探し、最新文書であるか否かの確認を行う手間を省くことができる。

本実施形態における文書管理システムは、ネットワーク内に分散している類似文書に対して、同一文書なのか同じ文書から派生した別文書なのかを判別することができる。更に、同一文書から派生した文書について、その前後関係を自動的に判別し、バージョン関係を明らかにすることができる。また、メール等の様々な手法でネットワーク内に分散配置された場合であっても、ある文書に対するバージョン情報（署名）を検出し、検出したバージョン情報に基づき、その文書に関連するバージョン違いの文書の検索又は取り出しを行うことができる。

本発明には、プログラムコード（検索プログラム）の指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた場合についても、本発明は適用される。その場合、書き込まれたプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

本実施形態に係る検索装置を含む文書管理システムの全体構成を示す図である。 図１におけるストレージサーバとクライアント端末のハードウエア構成の一例を示す図である。 図１に示すシステムで利用されるデータの構造を示す図である。 検索サーバのインデキシングサービスによるインデキシング処理の概要を示す図である。 検索サーバにおけるインデキシングサービスのモジュール構成を示す図である。 検索サーバにおけるインデキシングサービスの処理の手順を示すフローチャートである。 検索サーバの検索サービスによる検索処理の概要を示す図である。 検索サーバにおける検索サービスのモジュール構成を示す図である。 検索サーバにおける検索サービスの処理の手順を示すフローチャートである。 図９に示すバージョン判定処理の手順を示すフローチャートである。 本実施形態における検索ダイアログの表示の一例を示す図である。 本実施形態における検索結果の一例を示す図である。 本実施形態において、文書格納サーバアクセスサービスを経由し、署名が付与される構成を示す図である。 ユーザが、クライアント端末や別サーバのローカル環境において編集更新を行う場合を説明する図である。 本実施形態において、リビジョン生成処理の手順を示すフローチャートである。 本実施形態における検索結果の他の例を示す図である。

符号の説明

１００１ ストレージサーバ
１００２ インデキシングサービス
１００３ データベース
１００４ バージョン検索サービス
１００５ 検索サーバ
１００６ クライアント端末

Claims (6)

1. 文書の格納位置を示すロケーション情報を含む文書情報と当該文書の署名情報とが関連付けられて登録される記憶手段を備える文書管理システムであって、
   ユーザにより指定された指定文書を受信する受信手段と、
   前記受信手段により受信した前記指定文書から、署名情報を抽出する抽出手段と、
   前記記憶手段に登録されている文書の署名情報を参照し、前記指定文書のバージョンの異なる文書として、前記抽出手段により抽出された前記署名情報と一致する署名情報を有する文書を検索する検索手段と、
   文書のバージョン情報を前記署名情報に含まれる署名に基づいて決定する決定手段と、
   前記検索手段による検索結果に基づき、前記指定文書および前記指定文書のバージョンの異なる文書の文書情報と、前記署名情報に基づき決定されるバージョン情報とを関連付けて表示するための制御を行う表示制御手段とを備え、
   前記バージョン情報により、文書が正規バージョン又は派生バージョンであるかが示され、
   前記決定手段は、文書のバージョン情報を決定する際に、文書の署名に対応付いていない編集履歴が無い場合には、最後に付与された署名に基づき、前記正規バージョンとしてバージョン情報を決定し、文書の署名に対応付いていない編集履歴がある場合には、当該編集履歴に含まれる日付情報に基づき、前記派生バージョンとしてバージョン情報を決定し、
   前記表示制御手段は、文書情報を前記正規バージョン又は前記派生バージョンであることを識別可能に表示し、さらに文書情報の存在する文書ロケーションもあわせて表示するように制御する、
   ことを特徴とする文書管理システム。
2. 前記検索手段は、前記署名情報に基づくハッシュ値により検索を行うことを特徴とする請求項１に記載の文書管理システム。
3. 前記検索手段は、前記記憶手段に登録されている文書の署名情報に含まれる第１署名と、前記抽出手段により抽出された署名情報に含まれる第１署名とが一致する署名情報を有する文書を検索し、
   当該第１署名とは、文書に対して最初に付与された署名であることを特徴とする請求項１又は２に記載の文書管理システム。
4. 文書情報は、編集される度に蓄積される編集履歴を含み、
   前記記憶手段に対して新たな文書の文書情報が登録される際には、当該文書に対して第１署名を付与し、
   文書情報に新たに編集履歴が蓄積される場合には、当該文書に対して、何度目に付与されたかが識別可能な署名を新たに蓄積された編集履歴に対応付けて付与する付与手段を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の文書管理システム。
5. 文書の格納位置を示すロケーション情報を含む文書情報と当該文書の署名情報とが関連付けられて登録される記憶手段を備える文書管理システムにおいて実行される文書管理方法であって、
   前記文書管理システムの受信手段が、ユーザにより指定された指定文書を受信する受信工程と、
   前記文書管理システムの抽出手段が、前記受信工程により受信した前記指定文書から、署名情報を抽出する抽出工程と、
   前記文書管理システムの検索手段が、前記記憶手段に登録されている文書の署名情報を参照し、前記指定文書のバージョンの異なる文書として、前記抽出工程により抽出された前記署名情報と一致する署名情報を有する文書を検索する検索工程と、
   前記文書管理システムの決定手段が、文書のバージョン情報を前記署名情報に含まれる署名に基づいて決定する決定工程と、
   前記文書管理システムの表示制御手段が、前記検索工程による検索結果に基づき、前記指定文書および前記指定文書のバージョンの異なる文書の文書情報と、前記署名情報に基づき決定されるバージョン情報とを関連付けて表示するための制御を行う表示制御工程とを有し、
   前記バージョン情報により、文書が正規バージョン又は派生バージョンであるかが示され、
   前記決定工程では、文書のバージョン情報を決定する際に、文書の署名に対応付いていない編集履歴が無い場合には、最後に付与された署名に基づき、前記正規バージョンとしてバージョン情報を決定し、文書の署名に対応付いていない編集履歴がある場合には、当該編集履歴に含まれる日付情報に基づき、前記派生バージョンとしてバージョン情報を決定し、
   前記表示制御工程では、文書情報を前記正規バージョン又は前記派生バージョンであることを識別可能に表示し、さらに文書情報の存在する文書ロケーションもあわせて表示するように制御する、
   ことを特徴とする文書管理方法。
6. 請求項５に記載の文書管理方法の各工程をコンピュータに実行させるためのプログラム。

Images