(57)【要約】【課題】一旦検索された文書のその後の属性変更等の状況を提示し得る文書管理システム、制御方法、及びプログラムを提供する。【解決手段】一旦検索された文書の表示更新が指示された場合に、その文書の属性が変更されたか、或いはその文書がデータベースから削除されている場合は、それら変更、或いは削除されたことを認識可能な状態でその文書の文書名等を表示する。また、表示された属性変更に係る文書の検索条件が要求された場合は、その変更後の新たな属性に係る検索条件（キーワード）を表示する。【選択図】図１３
2007156625.tif 000002
【特許請求の範囲】
【請求項１】
データベースに文書を登録し、管理、抽出することのできる文書管理システムにおいて、
文書の属性情報を保存する保存手段と、
検索条件を指定して文書の検索を指示する指示手段と、
前記指示手段により指定された検索条件と前記保存手段により保存された属性情報に基づいて文書を検索する検索手段と、
前記検索手段により一旦検索された文書の表示更新が指示された場合に、該文書の属性が変更されたか否か、或いは該文書が前記データベースから削除されたか否かを判別する判別手段と、
前記判別手段により、前記文書の属性が変更された、或いは該文書が削除されたと判別された場合に、それら変更、或いは削除されたことを認識可能な状態で当該文書を示す情報を表示する表示制御手段と、
を有することを特徴とする文書管理システム。
【請求項２】
前記指定手段により指定された検索条件、及び前記検索手段での検索結果を保存する保存手段と、
前記判別手段により、前記文書の属性が変更されたと判別された場合に、前記保存手段により保存されている該文書の検索条件を変更後の新たな検索条件に書換える書換え手段を有することを特徴とする請求項１に記載の文書管理システム。
【請求項３】
前記書換え手段により書換えられた新たな検索条件を表示する第２の表示制御手段を有することを特徴とする請求項１又は２に記載の文書管理システム。
【請求項４】
前記第２の表示制御手段は、前記指定手段による検索条件の指定順と同じ属性の順序で前記新たな検索条件を表示し、前記保存手段に保存されていなかった属性に係る検索条件は最後の方に表示することを特徴とする請求項３に記載の文書管理システム。
【請求項５】
前記文書の属性情報は、１種類の属性について複数の属性値を有することを特徴とする請求項１〜４の何れかに記載の文書管理システム。
【請求項６】
データベースに文書を登録し、管理、抽出することのできる文書管理システムの制御方法において、
文書の属性情報を保存する保存工程と、
検索条件を指定して文書の検索を指示する指示工程と、
前記指示工程により指定された検索条件と前記保存工程により保存された属性情報に基づいて文書を検索する検索工程と、
前記検索工程により一旦検索された文書の表示更新が指示された場合に、該文書の属性が変更されたか否か、或いは該文書が前記データベースから削除されたか否かを判別する判別工程と、
前記判別工程により、前記文書の属性が変更された、或いは該文書が削除されたと判別された場合に、それら変更、或いは削除されたことを認識可能な状態で当該文書を示す情報を表示する表示制御工程と、
を有することを特徴とする制御方法。
【請求項７】
前記指定工程により指定された検索条件、及び前記検索工程での検索結果を保存する保存工程と、
前記判別工程により、前記文書の属性が変更されたと判別された場合に、前記保存工程により保存されている該文書の検索条件を変更後の新たな検索条件に書換える書換え工程を有することを特徴とする請求項６に記載の制御方法。
【請求項８】
前記書換え工程により書換えられた新たな検索条件を表示する第２の表示制御工程を有することを特徴とする請求項６又は７に記載の制御方法。
【請求項９】
請求項６〜８の何れかに記載の制御方法を実行するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理システム、制御方法、及びプログラムに関し、特に、属性が変更された文書の検索技術に関する。
【背景技術】
【０００２】
従来、文書データを文書サーバで集中管理することにより、或る部門の複合機等で作成された文書データを他の部門の複合機で容易に印刷できるようにした文書管理システムが知られている。
【０００３】
従来の文書管理システムでは、絞込検索を行って検索された文書を表示することができる。当該絞込検索の後に当該文書に対して他のユーザが属性を変更していた場合には、同じ絞込検索条件で表示更新を指示したとしても、当該文書が表示ウィンドウから消去されてしまう。
【０００４】
一方、検索条件が変更された場合に、自動的に再検索処理を行なうように構成したものも実現されている（例えば、特許文献１参照）。
【特許文献１】特開２０００−２８５１２５
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記のように、従来は、一旦絞込検索を行った文書を表示して表示更新を指示すると、その文書の属性の変更処理がなされていた場合に、その文書が表示ウィンドウから消去されてしまうことがあった。このような場合、ユーザは、その文書が削除されたのか或いは属性が変更されたのかを判別できず、不便であった。
【０００６】
また、属性が変更された文書については、その属性変更後の検索条件が判るようにする機能が要望されていた。
【０００７】
本発明は、このような背景の下になされたもので、一旦検索された文書のその後の属性変更等の状況を提示し得る文書管理システム、制御方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明は、データベースに文書を登録し、管理、抽出することのできる文書管理システムにおいて、文書の属性情報を保存する保存手段と、検索条件を指定して文書の検索を指示する指示手段と、前記指示手段により指定された検索条件と前記保存手段により保存された属性情報に基づいて文書を検索する検索手段と、前記検索手段により一旦検索された文書の表示更新が指示された場合に、該文書の属性が変更されたか否か、或いは該文書が前記データベースから削除されたか否かを判別する判別手段と、前記判別手段により、前記文書の属性が変更された、或いは該文書が削除されたと判別された場合に、それら変更、或いは削除されたことを認識可能な状態で当該文書を示す情報を表示する表示制御手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、一旦検索された文書の表示更新が指示された場合に、該文書の属性が変更されたか否か、或いは該文書が前記データベースから削除されたか否かを判別し、前記文書の属性が変更された、或いは該文書が削除されたと判別された場合に、それら変更、或いは削除されたことを認識可能な状態で当該文書を示す情報を表示するので、一旦検索された文書のその後の属性変更等の状況を提示し得る文書管理システム、制御方法、及びプログラムを提供することが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明を実施するための最良の形態を図面に基づいて説明する。
【００１１】
図１は、本発明の実施の形態に係る文書管理システムの機能ブロック図である。本文書管理システムは、パーソナルコンピュータのＯＳ上で動作するクライアント・サーバ型のアプリケーションにより実現されるものである。すなわち、文書管理システムは、クライアントとして機能するパーソナルコンピュータに搭載されたクライアント側のアプリケーション（以下、クライアント側と称する。）１０００と、文書サーバとして機能するパーソナルコンピュータに搭載されたサーバ側のアプリケーション（以下、文書サーバ側と称する）１１００とにより構成されている。
【００１２】
＜クライアント側の文書入出力処理部＞
まず、クライアント側１０００の文書入出力や操作を行う処理部について説明する。
【００１３】
図１に示したユーザインタフェース部１００１は、ユーザインタフェース画面を所定の表示部（図示省略）に表示する。ユーザは、このユーザインタフェース画面上で、文書サーバ側１１００に対して文書の登録、文書サーバ側１１００からの文書の所得、或いは文書の検索等を行うための操作を行うことになる。
【００１４】
ユーザインタフェース画面上の操作で指示されたコマンド等の情報は、コマンド制御部１００２で解析され、その解析結果に応じた処理が行われることになる。この際、コマンド制御部１００２は、必要に応じて文書サーバ側１１００との通信を行うためのコマンドを作成する。クライアント１０００に接続されたスキャナ及びプリンタ（図示省略）等の入出力デバイス等は、デバイス制御部１００３によって制御される。
【００１５】
すなわち、デバイス制御部１００３は、スキャナを制御して原稿情報を文書データとしてクライアント側１０００に取込んだり、後述の外部モジュール通信部１０５を介して取込んだ文書データをクライアント側１０００に取込んだりする。また、デバイス制御部１００３は、上記のようにして取込んだ文書データを上記のプリンタにより印刷するように制御する。
【００１６】
ファイル制御部１００４は、文書サーバ側１１００に保存された文書ファイル等を当該クライアント側１０００にダウンロードしたり、当該クライアント側１０００に保存された文書ファイルを文書サーバ側１１００にアップロードしたりするための制御を行なう。また、外部モジュール通信部１００５は、クライアント側１０００（文書管理アプリケーション）以外の外部アプリケーションと通信を行なう。例えば、外部モジュール通信部１００５は、当該クライアント側１０００により保存された文書データ、文書サーバ側１１００から取得した文書データ等を外部アプリケーションに渡す処理を行なう。例えば、外部モジュール通信部１００５は、文書サーバ側１１００から取得した文書データをＭＡＰＩ（Ｍｅｓｓａｇｉｎｎｇ  ＡＰＩ）に対応したメーラーに渡す処理を行なう。また、外部モジュール通信部１００５は、外部アプリケーションから文書データ等を受け取る処理も行う。
【００１７】
＜クライアント側の内部処理部＞
次に、クライアント側１０００の各種処理部について説明する。文書管理制御部１００６は、クライアント側１０００の中核をなす部分であり、前述の入出力処理部より渡された画像データやコマンドに応じた各種の文書管理制御を行う。すなわち、文書管理制御部１００６は、後述する文書登録処理、文書検索要求処理、検索結果の表示処理、文書存在の確認要求処理、属性変更に係る文書の検索条件の表示処理等を行なうための制御を行なう。
【００１８】
ファイル解析部１００８は、クライアント側１０００に登録された文書データを解析して、その文書データが画像データとして扱えるか否かを判別する。画像データとして扱える文書データであれば、イメージ文書処理部１０１０によって必要に応じて画像処理が行われる。一方、画像データとして扱えない文字コードによる文書データ（以下、コード文書と称する）であれば、コード文書処理部１００９によって処理が行われる。
【００１９】
イメージ文書処理部１０１０は、プレビューイメージ作成処理等を行なう。また、イメージ文書処理部１００９は、コード文書に対するサムネイルの作成処理や、文書属性の取得処理等を行なう。ただし、文書サーバ上で文書データがコード文書として処理されることはあまりない。
【００２０】
通信制御部１０１１は、文書サーバ側１１００と通信するための制御を行う。すなわち、本実施の形態における通信制御部１０１１は、文書サーバ側１１００の処理に関連する処理に特化した通信制御だけを行っており、ＴＣＰ／ＩＰ等の通信そのものの制御は、ＯＳに用意された機能により行なっている。一時データ保存部１０１２は、文書管理制御部１００６が各種処理を行う際に一時的にデータ等を保存するために利用される。この一時データ保存部１０１２には、後述する本実施の形態に特有な属性変更に係る文書の検索条件等も保存される。
【００２１】
＜文書サーバ側の処理部＞
次に、文書サーバ側１１００の各種処理部について説明する。通信制御部１１０１は、クライアント側１０００の通信制御部１０１１との通信のための制御を行う。ただし、文書サーバ側１１００の通信制御部１１０１は、多数のクライアントアプリケーションの通信制御部との通信処理も制御可能となっている。この通信制御部１１０１も、クライアント側１０００の通信制御部１０１１と同様に、ＴＣＰ／ＩＰ等の通信そのものの制御は、ＯＳに用意された機能により行なっている。
【００２２】
検索制御部１１０２は、クライアント側１０００から依頼された検索処理、後述するボリュームデータベース１１０９に登録された文書データの検索用のインデックス作成処理等を行なう。ファイル解析部１１０３、コード文書処理部１１０４、イメージ文書処理部１１０５の主な機能は、それぞれ、クライアント側１０００のファイル解析部１００８、コード文書処理部１００９、イメージ文書処理部１０１０の機能と同じである。ただし、文書サーバ側１１００のファイル解析部１１０３は、ボリュームデータベース１１０９に登録された文書データから検索用のインデックスを抽出する処理を行っている。  
【００２３】
すなわち、ファイル解析部１１０３は、ボリュームデータベース１１０９に登録された登録された文書データの種別を判別し、コード文書であれば、インデックスデータをコード文書処理部１１０４により抽出させる。一方、イメージ文書であれば、イメージ文書処理部１１０５によりイメージ処理を実行させ、ＯＣＲエンジン１１０６を使用してインデックスデータを抽出させる。
【００２４】
文書管理制御部１１０７は、文書サーバ側１１００における文書管理に関する各種の処理を、当該文書サーバ側１１００各制御部に振り分けている。すなわち、文書管理制御部１１０７は、後述する文書検索処理、文書存在確認処理、これら処理の結果をクライアント側１０００に通知する処理等を行なうべく、文書サーバ側１１００各部を制御している。
【００２５】
データベース制御部１１０８は、ボリュームデータベース１１０９、属性データベース１１１０、全文検索用データベース１１１１に対するアクセス処理を行なう。
【００２６】
ボリュームデータベース１１０９は、画像文書としての文書データ、及びコード文書としての文書データを登録するデータベースである。属性データベース１１１０は、ボリュームデータベース１１０９に登録された各文書データの属性データを登録するデータベースである。この属性データベース１１１０には、文書の名前、作成日付、コメント等の文書属性情報の他、文書管理システムを使用するユーザの情報、各種の設定データ等が登録される。属性データベース１１１０に登録された情報は、後述する絞込み検索を行なう際に利用される。
【００２７】
全文検索用データベース１１１１は、ボリュームデータベース１１０９に登録された各文書データから抽出されたテキストデータを、インデックス情報として登録するデータベースである。クライアント側１０００から全文検索が要求された場合には、全文検索用データベース１１１１上で検索が行なわれる。
【００２８】
＜クライアント側の文書登録処理＞
次に、クライアント側１０００における文書登録処理を、図２のフローチャートに基づいて説明する。
【００２９】
クライアント側１０００の文書管理制御部１００６は、当該クライアント側１０００に文書データを取り込む処理を行う（ステップＳ１０１）。この処理では、デバイス制御部１００３、ファイル制御部１００４、外部モジュール通信部１００５などを使用する。例えば、ＯＳ上に存在する文書データファイル、スキャナからの画像データ、外部アプリケーションからの文書データ等を、当該クライアント側１０００に取り込む。
【００３０】
次に、文書管理制御部１００６は、取り込んだ文書データをファイル解析部１００８により解析させる（ステップＳ１０２）。この解析処理では、取り込んだ文書データに係るファイルが文書管理システムで扱えるか否かの判別処理、文書の属性情報の取り込み処理等が行なわれる。
【００３１】
次に、文書管理制御部１００６は、解析の結果、文書が画像文書、コード文書の何れであるかをファイル解析部１００８により判別させる（ステップＳ１０３）。この判別処理は、次のような理由で行なわれる。すなわち、文書データを文書サーバ側１１００に登録する際には、クライアント側１０００で文書データを確認するために表示されるサムネイルも実際の文書データと同時に登録する必要がある。本実施の形態では、このサムネイル作成処理をクライアント側１０００で行っている。そこで、クライアント側１０００のファイル解析部１００８により文書が画像文書、コード文書の何れであるかを判別し、その判別結果に応じて、次のようにしてサムネイルを作成している。
【００３２】
すなわち、ステップＳ１０３にて、コード文書であると判別された場合は、コード文書処理部１００９は、ファイル解析部１００８の指示に従って、解析に係るコード文書のサムネイルを作成する（ステップＳ１０４）。この際、コード文書処理部１００９は、当該コード文書のコード内に保存された属性情報を取り出す処理も併せて行なう。
【００３３】
一方、イメージ文書であると判別された場合、イメージ文書処理部１０１０は、ファイル解析部１００８の指示に従って、解析に係るイメージ文書に対して必要に応じて所定のイメージ文書処理を行ない、当該イメージ文書のサムネイルを作成する。（ステップＳ１０５）。
【００３４】
次に、イメージ文書処理部１０１０は、当該イメージ文書を画像変換する必要があれば、画像変換処理を行なう（ステップＳ１０６，Ｓ１０７）。この画像変換処理では、例えば、文書サーバに登録可能なファイル形式に変換する等の処理が行なわれる。
【００３５】
ステップＳ１０４又はＳ１０７の処理が終了するか、或いはステップＳ１０６にて画像変換する必要がないと判別された場合、文書管理制御部１００６は、通信制御部１０１１により、上記のサムネイル、及び文書データを文書サーバ側１１００に送信させる（ステップＳ１０８）。なお、送信する文書データには、文書の属性データ、当該文書管理システムを使用するユーザの情報、各種の設定データ等の文書付加情報も含まれている。
【００３６】
＜文書サーバ側の文書登録処理＞
次に、文書サーバ側１１００における文書登録処理を、図３のフローチャートに基づいて説明する。
【００３７】
文書サーバ側１１００の文書管理制御部１１０７は、クライアント側１０００から送信された文書データ、サムネイルを通信制御部１１０１を介して受信する（ステップＳ２０１）。次に、検索制御部１１０２は、受信した文書データをファイル解析部１１０３により解析させる（ステップＳ２０２）。この解析処理では、取り込んだ文書データが当該文書管理システムで扱えるファイル形式であるか否かの判別処理、文書の属性情報の取り込み処理等が行なわれる。
【００３８】
次に、検索制御部１１０２は、解析の結果、文書が画像文書、コード文書の何れであるかをファイル解析部１１０３により判別させる（ステップＳ２０３）。この判別処理は、次のような理由で行なわれる。すなわち、文書サーバ側１１００に登録した文書データを検索するためには、文書データから検索用のインデックスデータを抽出する必要がある。そこで、文書が画像文書、コード文書の何れであるかを判別し、その判別結果に応じて、次のようにしてインデックスデータを抽出している。
【００３９】
すなわち、ステップＳ２０３にて、コード文書である判別された場合は、コード文書処理部１１０４は、検索制御部１１０２の指示に従って、解析に係るコード文書からインデックスデータを抽出する（ステップＳ２０４）。
【００４０】
一方、イメージ文書であると判別された場合は、イメージ文書処理部１１０５は、検索制御部１１０２の指示に従って、解析に係るイメージ文書に対してイメージ文書処理を行なう（ステップＳ２０５）。このイメージ文書処理としては、ＯＣＲに適した画像を得るための画像変換処理等が行なわれる。ただし、実際にボリュームデータベース１１０９に登録するイメージ文書としては、クライアント側１０００から受信したイメージ文書をそのまま利用する。
【００４１】
次に、イメージ文書処理部１１０５は、ステップＳ２０５で画像変換されたイメージ文書に対して、ＯＣＲエンジン１１０６を用いてＯＣＲ処理、すなわち文字切出し・認識処理を行うことにより、検索用のインデックスデータを抽出する（ステップＳ２０６）。
【００４２】
ステップＳ２０４又はＳ２０６の処理が終了すると、文書管理制御部１１０７は、デーベース制御部１１０８を用いて、クライアント側１０００から受信した文書データ、及びサムネイルデータをボリュームデータベース１１０９に登録する（ステップＳ２０７）。次に、文書管理制御部１１０７は、上記のようにして受信に係る文書データから抽出した検索用のインデックスデータを、データベース制御部１１０８を用いて、全文検索用データベース１１１１に登録する（ステップＳ２０８）。
【００４３】
次に、文書管理制御部１１０７は、ボリュームデータベース１１０９に登録した文書データの属性データとＩＤデータ、全文検索用データベース１１１１に登録したインデックスデータのＩＤデータを、データベース制御部１１０８を用いて、属性データベース１１１０に登録する（ステップＳ２０９）。
【００４４】
このように、文書データのＩＤデータとインデックスデータのＩＤデータを属性データベース１１１０に登録することにより、属性データベース１１１０に登録された属性データと、ボリュームデータベース１１０９の登録された文書データと、全文検索用データベース１１１１に登録されたインデックスデータとの対応関係を認識できるようにしている。
【００４５】
なお、検索制御部１１０２は、当該文書管理システムを使用するユーザの情報、各種の設定データ等の文書属性データ以外の文書付加情報を解析している。この場合、例えば、文書付加情報がＸＭＬ形式で記述されている場合には、検索制御部１１０２は、図示しないＸＭＬパーサ等で文書付加情報を解析する。解析された文書付加情報は、データベース制御部１１０８により、属性データベース１１１０内の文書の付加情報保存領域に登録される。
【００４６】
＜属性データベースの構造＞
図４は、属性データベース１１１０に登録されているデータの構造を示す概念図である。ここではツリー構造を採っているが、必ずしもツリー構造である必要はない。なお、図４のツリー構造は、その一部を示したものであることは言うまでもない。
【００４７】
属性データベース１１１０は、上記のようにツリー構造を採って、親子関係のように階層化されている。すなわち、図４の例では、ルート３００１の子データとして複数のフォルダデータ３００２，３００３等が存在し、このフォルダデータ３００２の子データとして複数の文書ファイルデータ３００４〜３００６が存在する。更に、文書ファイルデータ３００４の子データとして複数のページレコードデータ３００７，３００８が存在し、文書ファイルデータ３００５の子データとしてページレコードデータ３００９が存在している。
【００４８】
フォルダデータ３００２，３００３等は、フォルダＩＤ、フォルダ属性情報、及びフォルダ付加情報により構成されている。また、文書ファイルデータ３００４〜３００６等は、文書ＩＤ、文書属性情報、及び文書付加情報により構成されている。文書属性情報としては、文書名、更新日時、コメントデータなどのデータが登録されている。なお、文書属性情報の詳細は、後述する。
【００４９】
また、ページレコードデータ３００７〜３００９等は、文書の各ページに関する情報として、ページＩＤ、ページ属性情報、検索インデックスＩＤ、及びボリュームデータＩＤにより構成されている。検索インデックスＩＤは、全文検索用データベース１１１１に登録されたインデックスのＩＤである。ボリュームデータＩＤは、ボリュームデータベース１１０９を示すＩＤ、具体的には文書データ自体とそのサムネイルが記録されている各記憶媒体を示すＩＤである。これら各ＩＤに基づいて、各データベース１１０９，１１１０，１１１１から所望の情報を引き出すことができる。
【００５０】
ページ属性情報としては、ページ番号、ページのファイルフォーマットといった情報が存在する。なお、コード文書はページ毎に分割して登録することができないため、１ページしか存在しない文書として扱われ、１つのコード文書に関するページレコードデータは１つしか存在しない。
【００５１】
＜文書属性情報の構造＞
図５（ａ）に示したＸＭＬ１０は、クライアント側１０００から送信されてくる文書データ中に記述された文書属性情報の例示したものである。本実施の形態では、文書データ中に記述された文書属性情報は、マークアップ言語の１つであるＸＭＬ形式で記述され、各属性の名称とその値が、ＸＭＬの要素名と、要素内容として記述されている。なお、この文書データは、後述する文書ｂに係るものである。
【００５２】
図５（ｂ）に示したＴＢＬ１０は、属性データベース１１１０に登録された文書属性情報、すなわち、図４に示した文書ファイルデータ３００４〜３００６中の文書属性情報を例示したものであり、図５（ａ）に示したＸＭＬ１０に対応するものである。すなわち、クライアント側１０００から送信された文書データ中に記述された文書属性情報を属性データベース１１１０に登録する場合は、図５（ｂ）に示したように、テーブル形式で属性の名称とその値を対応付けて登録することで、属性データベース１１１０に対して高速にアクセスできるようにしている。
【００５３】
＜クライアント側の絞込検索処理＞
次に、クライアント側１０００の絞込み検索処理を、図６のフローチャートに基づいて説明する。
【００５４】
ユーザがユーザインタフェース１００１上で検索条件としてのキーワードを指定して絞込検索要求を指示する（ステップＳ３０１）。すると、クライアント側１０００の文書管理制御部１００６は、上記の操作情報を取得してコマンド制御部１００２により解析させる（ステップＳ３０２）。
【００５５】
この場合、コマンド制御部１００２は、上記の絞込検索要求の操作情報に基づいて、絞込検索要求コマンドを生成し、文書管理制御部１００６に渡す。そこで、文書管理制御部１００６は、この絞込検索要求コマンドを上記の検索条件としてのキーワードと共に、通信制御部１０１１を介して文書サーバ側１１００に送信する。（ステップＳ３０３）。
【００５６】
次に、文書管理制御部１００６は、通信制御部１０１１を介して上記の検索条件による検索結果を文書サーバ側１１００から受け取り（ステップＳ３０４）、その検索結果をユーザインタフェース１００１上に表示する。（ステップＳ３０５）。この表示態様については、後述する。次に、文書管理制御部１００６は、文書サーバ側１１００から受け取った検索結果、検索でヒットした文書の属性情報、及び当該検索条件であるキーワードを一時データ保存部１０１２に保存して（ステップＳ３０６）、終了する。
【００５７】
＜文書サーバ側の絞込検索処理＞
次に、文書サーバ側１１００の絞込み検索処理を、図７のフローチャートに基づいて説明する。
【００５８】
文書サーバ側１１００の文書管理制御部１１０７は、通信制御部１１０１を介してクライアント側１０００からの検索要求コマンド、キーワードを受信する（ステップＳ４０１）。すると、それら検索要求コマンド、キーワードを検索制御部１１０２に送付して検索処理を実行させる（ステップＳ４０２）。
【００５９】
この場合、検索制御部１１０２は、受け取ったキーワードを用いて検索処理を行い、検索結果、及びヒットした各文書の属性情報を含む各種情報を、通信制御部１１０１を介してクライアント側１０００に送信する。（ステップＳ４０３）。
【００６０】
＜絞込検索結果の表示＞
図８は、クライアント側１０００のユーザインタフェース１００１に表示される検索結果の表示画面を示している。ウィンドウＷ１０内の検索条件表示領域Ｒｅｐ１０に検索条件としてのキーワードが表示され、検索結果表示領域Ｌｉｓｔ１０に検索処理でヒットした文書の文書名が表示される。
【００６１】
図８では、文書の属性情報に「２００４」、「Ｗｅｂ」、「文書管理」、「仕様書」のキーワードが含まれている文書を順番に検索して絞込んでいった場合の検索結果例を示している。この場合、検索条件表示領域Ｒｅｐ１０に表示されるキーワードは、絞り込み検索を行った順番が容易に判るように、階段状に表示される。また、検索結果表示領域Ｌｉｓｔ１０には、上記のキーワードによる絞込検索でヒットした文書の文書名である「文書ａ」、「文書ｂ」、「文書ｃ」が表示される。なお、文書名の代わりに、或いは文書名と共に、サムネイルを表示することも可能である。
【００６２】
＜絞込検索処理時の一時保存データ＞
図９は、絞込検索処理時に一時的に保存される一時保存データのデータ構造を示す概念図である。図９（ａ）に示したＳＣＨＴＢＬ１０は、検索条件を保存する検索条件テーブルの内容を示している。この検索条件テーブルＳＣＨＴＢＬ１０は、図６のステップＳ３０６の処理により、クライアント側１０００の一時データ保存部１０１２内に保存される。
【００６３】
図９（ａ）に示したように、検索条件テーブルＳＣＨＴＢＬ１０には、検索順番、検索に用いたキーワードの属性の名称、属性の値（キーワードそれ自体）がそれぞれ保存されている。この図９（ａ）の内容は、図８の検索条件（Ｒｅｐ１０）に対応したものを例示している。ここでは、「２００４」、「Ｗｅｂ」、「文書管理」、「仕様書」のキーワードが、それらキーワードの属性の名称である「年」、「Ｓｕｂ」、「分野」、「業務」と対応付けて、絞込検索を行った順に記録されている。
【００６４】
図９（ｂ）に示したＷＩＮＴＢＬ１０は、検索結果を保存する検索結果テーブルの内容を示している。この検索結果テーブルＷＩＮＴＢＬ１０も検索条件テーブルＳＣＨＴＢＬ１０と同様に、図６のステップＳ３０６の処理により、クライアント側１０００の一時データ保存部１０１２内に保存される。
【００６５】
この図９（ｂ）の内容は、図８の検索結果（Ｌｉｓｔ１０）に対応したものを例示しており、検索処理でヒットした文書の文書名である「文書ａ」「文書ｂ」「文書ｃ」が、それら文書の文書ＩＤと対応付けて記録されている。
【００６６】
＜他のユーザによる文書属性変更、文書削除＞
ここで他のユーザにより、図示しない他のクライアント機器を使って、図５に示した文書ｂの属性を変更し、文書ｃを文書サーバ、すなわちボリュームデータベース１１０９から削除して、前述の図９（ａ）に示した検索条件で絞込検索を行なったものとする。また、図５（ａ）に示した文書ｂに係る文書データ内の属性情報を、例えば、図１０（ａ）に示したＸＭＬ１１のように変更したものとする。この例では、属性「分野」の値が「文書管理」から「帳票管理」に、属性「Ｓｕｂ」の値が「Ｗｅｂ」から空欄に、属性「バージョン」の値が「１．０」から「２．０」に、それぞれ変更されている。
【００６７】
このような文書属性の変更を行なった場合、図５（ｂ）に示した文書属性テーブルＴＢＬ１０も、同様に、図１０（ｂ）に示したＴＢＬ１１のように変更される。また、このような属性変更を行い、文書ｃを削除して前述の図９（ａ）に示した検索条件で絞込検索を行なった場合には、例えば、図１０（ｃ）に示した検索結果テーブルＷＩＮＴＢＬ１１のような検索結果が得られる。
【００６８】
すなわち、図１０（ｃ）の検索結果テーブルＷＩＮＴＢＬ１１は、他のユーザにより属性が変更された文書ｂに関しては、その属性変更前にヒットしたものと同一の検索条件を使用して絞込み検索を行ったにも拘らず、ヒットしなかったことを示している。なお、検索結果テーブルＷＩＮＴＢＬ１１における文書ｄは、前回の絞込検索の後に追加登録された文書である。
【００６９】
＜クライアント側の表示更新処理＞
次に、本発明に特有な表示更新処理を、図１１、図１２のフローチャートに基づいて説明する。
【００７０】
ユーザは、前回の絞込検索で検索された文書にアクセスし、ユーザインタフェース１００１上で表示更新処理を指示する（図１１のステップＳ５０１）。この指示を受けて、クライアント側１０００の文書管理制御部１００６は、当該文書の前回の絞込検索時に用いた検索要求コマンド、及びキーワードを一時データ保存部１０１２から読み出し、文書サーバ側１１００に送付する（ステップＳ５０２）。
【００７１】
次に、文書管理制御部１００６は、通信制御部１０１１を介して文書サーバ側１１００から最新の検索結果を受け取る（ステップＳ５０３）。そして、受け取った最新の検索結果と、前回の絞込検索時の一時データ保存部１０１２に保存した検索結果とを比較する（ステップＳ５０４）。そして、文書管理制御部１００６は、両方の検索結果において共通に検索された文書が存在するか否かを判別する（ステップＳ５０５）。そして、存在する場合は、その共通に検索された文書の文書名を検索結果ウィンドウの検索結果領域に通常の表示態様で表示する（ステップＳ５０６）。なお、検索結果ウィンドウ等の実際の表示処理は、ユーザインタフェース部１００１により行なわれる（以下、同様）。
【００７２】
一方、共通に検索された文書が存在しない場合、例えば、前回の絞込検索時にのみ検索された文書が存在するような場合は、文書管理制御部１００６は、前回の絞込検索時にのみ検索された文書が文書サーバ側１１００に存在するのか否かを確認する文書存在確認要求コマンド、及び当該文書の文書ＩＤを、通信制御部１０１１を介して文書サーバ側１１００に送信する（ステップＳ５０７）。
【００７３】
次に、文書管理制御部１００６は、通信制御部１０１１を介して文書サーバ側１１００から文書存在の確認結果を受け取り（ステップＳ５０８）、前回の絞込検索時にのみ検索された文書が削除されたのか否かを判別する（ステップＳ５０９）。その結果、削除されていた場合は、文書管理制御部１００６は、検索結果ウィンドウの検索結果領域への文書名の表示を行なわない（ステップＳ５１０）。ただし、この場合、削除された旨のメッセージ、或いは削除されたことが判る形（例えば赤枠で囲む）で、削除に係る文書の文書名等を表示することも可能である。
【００７４】
一方、削除されていなかった場合は、文書管理制御部１００６は、当該文書の属性が変更されたものとして、検索結果ウィンドウの検索結果領域に当該文書の文書名を点滅表示する（ステップＳ５１１）。
【００７５】
ステップＳ５０６，Ｓ５１０，Ｓ５１１の何れかの処理が終了すると、文書管理制御部１００６は、一時データ保存部１０１２に保存されている前回の絞込検索で検索された全ての文書に対するステップＳ５０５〜Ｓ５１１の処理が終了したか否かを判別する（ステップＳ５１２）。その結果、未だ終了していなければ、文書管理制御部１００６は、ステップＳ５０５に戻り、残りの上記の文書に対してステップＳ５０５〜Ｓ５１１の処理を行なう。
【００７６】
一方、前回の絞込検索で検索された全ての文書に対するステップＳ５０５〜Ｓ５１１の処理が終了した場合は、文書管理制御部１００６は、前回の絞込検索では検索されずに今回の検索で新たに検索された文書があるか否かを判別する（ステップＳ５１３）。その結果、今回の検索で新たに検索された文書が有れば、文書管理制御部１００６は、その文書の文書名を検索結果ウィンドウの検索結果領域にＮｅｗマークを付けて表示し（ステップＳ５１４）、終了する。今回の検索で新たに検索された文書が無ければ、文書管理制御部１００６は、ステップＳ５１４をスキップして、終了する。
【００７７】
＜文書サーバ側の文書存在確認処理＞
文書サーバ側１１００の検索制御部１１０２は、通信制御部１１０１を介してクライアント側から文書存在確認要求コマンド、文書ＩＤを受信すると（図１２のステップＳ６０１）、その文書ＩＤを用いて文書存在確認処理を行う（ステップＳ６０２）。そして、検索制御部１１０２は、文書存在確認結果と文書の属性情報を含む各種情報を、通信制御部１１０１を介してクライアント側１０００に送信する。（ステップＳ６０３）。
【００７８】
＜表示更新処理時の絞込検索結果の再表示＞
図１３は、図１１の表示更新処理で表示される絞込検索結果の再表示例を示している。この再表示例は、文書ｂの属性は、最初の絞込み検索時には、図５（ａ）、（ｂ）の状態であったのだが、その後、他のユーザが文書ｂの属性を図１０（ａ）、（ｂ）のように変更し、文書ｃを削除すると共に文書ｄを追加した場合に対応している。
【００７９】
この場合、最初の絞込み検索時には、図８に示したような検索結果が表示されていたのに対し、再表示においては、図１３に示したように再表示される。すなわち、属性が変更された文書ｂの文書名は破線で示したように点滅表示され、削除された文書ｄの文書名は表示されずに追加された文書ｄの文書名が「ＮＥＷ」という文字と共に表示される。また、何ら変更が加えられていない文書ａの文書名は、通常の態様で表示される。
【００８０】
ユーザは、この再表示を見て、文書ｂの属性が変更されたことは認識できても、その変更後の属性内容、すなわち検索条件を知ることはできない。そこで、本実施の形態では、点滅状態で表示されている文書ｂの文書名をクリックして、図１４の属性変更文書の新たな検索条件の表示処理を実行させることにより、属性変更後の検索条件を認識できるようにしている。
【００８１】
＜属性変更文書の新たな検索条件の表示処理＞
ユーザが、上記のようにして属性変更に係る文書を選択して検索条件表示処理を指示する（図１４のステップＳ７０１）。このとき、クライアント側１０００の文書管理制御部１００６は、一時データ保存部１０１２に保存されている選択に係る文書の文書ＩＤ、及び検索条件確認コマンドを通信制御部１０１１を介して文書サーバ側１１００に送信する（ステップＳ７０２）。そして、文書管理制御部１００６は、通信制御部１０１１を介して文書サーバ側１１００から検索条件の確認結果、及び属性変更に係る文書の属性情報を受け取る（ステップＳ７０３）。
【００８２】
次に、文書管理制御部１００６は、文書が削除されている旨の確認結果であるか否かを判別する（ステップＳ７０４）。その結果、文書が削除されている旨の確認結果であれば、文書管理制御部１００６は、文書が削除されたことを示す警告メッセージを表示する（ステップＳ７１４）。そして、文書管理制御部１００６は、ステップＳ７０１で選択された文書の文書名を表示ウィンドウから消去して（ステップＳ７１５）、本処理を終了する。一方、文書が削除されている旨の確認結果でない場合は、文書管理制御部１００６は、ステップＳ７０３で受け取った属性変更に係る文書の属性情報（以下、新たな属性情報という）を一時データ保存部１０１２に保存する（ステップＳ７０５）。
【００８３】
なお、本実施の形態では、図１３のように属性が変更されて点滅表示されている文書名をクリックした場合に図１４の本フローの処理を行なうようにしている。従って、実際には、上記のステップＳ７０３→Ｓ７１４→Ｓ７１５の処理は不要である。それにも拘らずステップＳ７０３→Ｓ７１４→Ｓ７１５の処理を図１４に記載したのは、例えば、ユーザが文書名等を指定することなく、単に、新たな検索条件の表示処理を指示した場合にも対応することを想定したためである。
【００８４】
次に、文書管理制御部１００６は、一時データ保存部１０１２に保存されている検索条件テーブルに登録されている検索条件と新たな属性情報とに基づいて、双方に共通に存在する属性名（属性）に係る新たな検索条件を生成する。この生成された検索条件は、一時データ保存部１０１２に保存される（ステップＳ７０６）。この際、文書管理制御部１００６は、検索条件テーブルに登録されている属性（属性名）について検索順に１つずつ着目していき、着目に係る属性が新たな属性情報の中に存在すれば、その属性の属性名と、新たな属性情報の中の当該属性に係る属性値とを、新たな検索条件として順次、一時データ保存部１０１２に保存していく。
【００８５】
次に、文書管理制御部１００６は、検索条件テーブル中の全ての属性について上記の処理を完了したか否かを判別し（ステップＳ７０７）、完了していなければ、ステップＳ７０６に戻り、次の検索順の属性について同様の処理を行なう。
【００８６】
一方、検索条件テーブル中の全ての属性についてステップＳ７０６の処理を完了した場合、文書管理制御部１００６は、検索条件テーブルに存在せず、新たな属性情報にのみ存在する属性について、当該文書の文書属性テーブルを用いて、前回の絞込み検索時から属性値が変更されたものが有るか否かを判別する（ステップＳ７０８）。
【００８７】
その結果、属性値の変更がなされた属性が有れば、文書管理制御部１００６は、その属性の属性名と変更後の属性値を新たな検索条件として一時データ保存部１０１２に追加・保存して（ステップＳ７０９）、ステップＳ７１０に進む。一方、属性値の変更がなされた属性が無ければ、文書管理制御部１００６は、ステップＳ７０９をスキップしてステップＳ７１０に進む。
【００８８】
ステップＳ７１０では、文書管理制御部１００６は、一時データ保存部１０１２に保存した新たな検索条件（図１５参照）と検索要求コマンドを、通信制御部１０１１を介して文書サーバ側１１００に送信する。次に、文書管理制御部１００６は、通信制御部１０１１を介して文書サーバ側１１００から検索結果を受け取り（ステップＳ７１１）、その検索結果、及び上記の新たな検索条件をユーザインタフェース１００１上に表示する（ステップＳ７１２、図１６参照）。この際、文書管理制御部１００６は、前回の絞込検索時に使用しなかった属性に係る検索条件については、従前の属性に係る検索条件に追加するような形で表示する（図１５参照）。
【００８９】
次に、文書管理制御部１００６は、文書サーバ側１１００から受け取った検索結果、検索でヒットした文書の属性情報、及びステップＳ７０５〜Ｓ７０９の処理で作成した新たな検索条件を一時データ保存部１０１２に纏めて保存して（ステップＳ７１３）、終了する。
【００９０】
図１５は、文書ｂの変更された文書属性に対応する新たな検索条件テーブルを例示した図である。図１５の新たな検索条件テーブルＳＣＨＴＢＬ１１は、前回の絞込検索時の検索条件を図９（ａ）に示した検索条件テーブルＳＣＨＴＢＬ１０の内容とし、属性変更前の文書属性を図５（ｂ）に示した文書属性テーブルＴＢＬ１０の内容とし、属性変更後の文書属性を図１０（ｂ）の文書属性テーブルＴＢＬ１１の内容とした場合に対応している。
【００９１】
この例では、前回の検索条件テーブルＳＣＨＴＢＬ１０と、新たな検索条件テーブルＳＣＨＴＢＬ１１とを比較すると、「Ｓｕｂ」の属性値が「Ｗｅｂ」から「空欄」に変更され、「分野」の属性値が「文書管理」から「帳票管理」に変更されている。このような前回の検索条件テーブルＳＣＨＴＢＬ１０に存在していた属性の属性値の変更処理は、図１４のステップＳ７０６〜Ｓ７０７の処理により行なわれるものである。
【００９２】
また、上記の２つのテーブルを比較すると、新たな検索条件テーブルＳＣＨＴＢＬ１１には、５番目の検索条件として、属性名「バージョン」とその属性値「２．０」が追加されている。このような追加処理は、図１４のステップＳ７０８〜Ｓ７０９の処理により行なわれるものである。
【００９３】
図１６は、図１４のステップＳ７１２にて表示される新たな検索条件、及び検索結果の表示画面例を示している。この表示画面例は、図１３に示した検索結果画面Ｗ１１において、属性が変更された文書ｂを選択して検索条件の表示を指示した場合に対応している。
【００９４】
ウィンドウＷ１２内の検索条件表示領域Ｒｅｐ１２には検索条件が表示され、検索結果表示領域Ｌｉｓｔ１２には新たな検索条件でヒットした文書の文書名が表示される。
【００９５】
ここで、文書ｂの新たな検索条件は、図１５のＳＣＨＴＢＬ１１に示したものである。この新たな検索条件は、検索条件表示領域Ｒｅｐ１２のＡＮｅｗ１２の領域に検索の順番に従って階段状に表示される。また、前回の検索条件がＡＯｌｄ１２の領域に検索の順番に従って階段状に表示される。なお、前回の検索条件のルートと新たな検索条件のルートの枝分けは、異なる検索条件（キーワード）が出現した時点で行なわれる。
【００９６】
以上説明したように、本実施の形態では、一旦検索された文書の表示更新が指示された場合に、その文書の属性が変更されたか、或いはその文書が削除されている場合は、それら変更、或いは削除されたことを認識可能な状態でその文書の文書名を表示している。また、属性変更に係る文書の検索条件が要求された場合は、その変更後の新たな属性に係る検索条件（キーワード）を表示している。
【００９７】
なお、本発明は、上記の実施の形態に限定されることなく、例えば、１つの属性の種類について複数の属性値を有する場合にも、上記の実施の形態の処理を適用することが可能である。また、検索結果の表示形態としては、文書名の代わりにサムネイルを表示する、或いは文書名と共にサムネイルを表示することも可能である。
【００９８】
さらに、本発明の目的は、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。
【００９９】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１００】
又、プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。または、プログラムコードをネットワークを介してダウンロードしてもよい。
【０１０１】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１０２】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【図面の簡単な説明】
【０１０３】
【図１】本発明の実施の形態に係る文書管理システムの機能ブロック図である。
【図２】クライアント側の文書登録処理を示すフローチャートである。
【図３】文書サーバ側の文書登録処理を示すフローチャートである。
【図４】属性データベースに登録されているデータのデータ構造を示す概念図である。
【図５】文書の属性情報のデータ構造を説明するための概念図である。
【図６】クライアント側の絞込検索処理を示すフローチャートである。
【図７】文書サーバ側の絞込検索処理を示すフローチャートである。
【図８】クライアント側に表示される絞込検索結果画面を示す図である（属性変更前）。
【図９】一時的に保存される検索条件テーブル、及び検索結果テーブルを示す概念図である。
【図１０】文書属性の変更例、及びその変更後の表示更新指示に対応する検索結果を示す概念図である。
【図１１】クライアント側の表示更新処理を示すフローチャートである。
【図１２】文書サーバ側の文書存在確認処理を示すフローチャートである。
【図１３】表示更新処理でクライアント側に表示される絞込検索結果画面を示す図である（属性変更後）。
【図１４】クライアント側の属性変更に伴う新たな検索条件の表示処理を示すフローチャートである。
【図１５】属性変更後の新たな検索条件テーブルを示す概念図である。
【図１６】クライアント側に表示される検索結果画面を示す図である（属性変更後の新たな検索条件を含む）。
【符号の説明】
【０１０４】
１０００…クライアント側のアプリケーション、１００１…ユーザインタフェース部、１００６，１１０７…文書管理制御部、１０１２…一時データ保存部、１１００…文書サーバ側のアプリケーション、１１０２…検索制御部、１１０８…データベース制御部、１１０９…ボリュームデータベース、１１１０…属性データベース、Ｗ１０，１１，１２…検索結果画面、ＴＢＬ１０，１１…文書属性テーブル、ＳＣＨＴＢＬ１０，１１…検索条件テーブル、ＷＩＮＴＢＬ１０，１１…検索結果テーブル
【図１】
2007156625.tif 000003
【図２】
2007156625.tif 000004
【図３】
2007156625.tif 000005
【図４】
2007156625.tif 000006
【図５】
2007156625.tif 000007
【図６】
2007156625.tif 000008
【図７】
2007156625.tif 000009
【図８】
2007156625.tif 000010
【図９】
2007156625.tif 000011
【図１０】
2007156625.tif 000012
【図１１】
2007156625.tif 000013
【図１２】
2007156625.tif 000014
【図１３】
2007156625.tif 000015
【図１４】
2007156625.tif 000016
【図１５】
2007156625.tif 000017
【図１６】
2007156625.tif 000018