JP4829698B2 - 文書検索システム、文書検索方法、及びプログラム - Google Patents

Description

本発明は、記憶装置に記憶された複数の文書の中から、ユーザにより入力された検索条件に従って文書を検索する文書管理システム、及びその制御方法、プログラム、記憶媒体に関するものである。

従来から、文書管理サーバなどの大容量の記憶装置に記憶された複数の文書の中から、ユーザが所望する文書を検索する場合に、その文書を検索するための検索条件をユーザが入力し、入力された検索条件に従って文書を検索することが可能である。この時、検索条件として、例えば、検索対象となる文書の中に含まれている文字列の一部を検索キーワードとして指定したり、またはそのキーワードの組み合わせ方を示す検索論理式を指定したりすることができる。

一方、近年では文書管理サーバなどの記憶装置の許容記憶容量が増加し、多数の文書を記憶することが可能となっている。また、例えばＨＤＤ（ハードディスクドライブ）のような記憶装置を備えたＭＦＰ（マルチファンクションペリフェラル）がネットワーク上に複数接続されている場合は、各ＭＦＰのＨＤＤに記憶された複数の文書の中から所望の文書を検索することができる。これらの環境においては、検索の対象となる文書は膨大な数になることが多く、ユーザが入力する検索条件によっては、検索結果としてユーザが期待した数以上の文書が該当してしまい、所望する文書が見つからないといった問題が発生する場合がある。特に、検索に不慣れなユーザが検索を行う場合は、期待する検索結果を得るために何度も検索条件を入力し直して、その都度検索を実行しなければならず、手間がかかっていた。

このような問題を解決するために、ユーザが入力した検索条件に従って検索を実行する際の手間を軽減するための技術が知られている。具体的には、ユーザが検索条件を入力して検索を実行している最中に、検索結果として該当した件数が予め設定された閾値を超えた時点で検索を中断し、ユーザが検索式を再入力できる状態にすることができるものである。（例えば、特許文献１参照）
特開平０８−３１４９６５号公報

しかしながら、上述した従来技術では次のような問題があった。

特許文献１では、検索結果としてヒットする文書数が多すぎる場合には、検索の終了を待たずに検索を中断し、検索条件の再入力を行うことが可能であるが、検索結果としてヒットする文書数がどれくらになるかは検索を開始してみなければ分からなかった。

そのため、ユーザは中断される可能性があるにも関わらず、検索処理の進行を待たなければならなかった。また、実際に検索処理を実行する検索エンジンは、検索結果が膨大な数になってしまい、ユーザが改めて検索条件を作成した場合、結果的に意味のない検索処理をすることになってしまうことになる。さらに、検索対象の文書を記憶した記憶装置または検索エンジンがネットワークを介した外部に存在するような環境では、検索要求や検索結果の情報などを何度もネットワーク上に送出しなければならず、ネットワークに負荷がかかってしまうという可能性もある。

本発明は、上記の問題点に鑑みなされたものであり、予め管理された情報に基づいて、入力された検索条件が適正であるか否かを検索実行前に判定することができる文書検索システム、及びその制御方法、プログラム、記憶媒体を提供することを目的とする。

上記目的を達成するために本発明の文書検索システムは、検索条件と当該検索条件を用いて検索した場合にヒットする文書の数を対応付けて管理する管理手段と、検索条件を入力する入力手段と、前記入力手段により検索条件が入力された場合に、前記管理手段が管理する文書の数を参照し、前記入力された検索条件を用いて検索した場合にヒットする文書の数が所定の数よりも多いか否かを、当該検索を実行する前に判定する判定手段と、前記判定手段による判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、当該検索の実行を制限する制御手段と、所定期間が経過したことに応じて前記管理手段が管理する検索条件を用いた検索を実行し、当該検索の結果に基づき前記管理手段が管理する文書の数を更新する更新手段と、を備えることを特徴とする。

また、本発明の文書検索方法は、検索条件と当該検索条件を用いて検索した場合にヒットする文書の数を対応付けて管理する管理工程と、検索条件を入力する入力工程と、前記入力工程で検索条件が入力された場合に、前記管理工程で管理された文書の数を参照し、前記入力された検索条件を用いて検索した場合にヒットする文書の数が所定の数よりも多いか否かを、当該検索を実行する前に判定する判定工程と、前記判定工程における判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、当該検索の実行を制限する制御工程と、所定期間が経過したことに応じて前記管理工程で管理された検索条件を用いた検索を実行し、当該検索の結果に基づき前記管理工程で管理された文書の数を更新する更新工程と、を備えることを特徴とする。

本発明によれば、検索条件と当該検索条件を用いて検索した場合にヒットする文書の数を対応付けて管理し、当該管理された文書の数に基づいて、入力された検索条件が適正であるか否かを検索実行前に判定することができるので、無駄な検索の実行を抑制することができ、使い勝手がよくなる。また特に、所定期間が経過したことに応じて、前記管理された文書の数を更新する構成を有することにより、検索対象となる文書の増減がある場合にも、ユーザの手間を必要とせずに適切な判定を行うことが可能となる。

以下に、本発明の実施形態を説明する。

（第１の実施形態）
図１は、本発明の第１の実施形態にかかわる文書管理システムのシステム全体の構成図を示している。ＬＡＮ（ローカルエリアネットワーク）１５０上には、ＭＦＰ（マルチファンクションペリフェラル）１００、ＭＦＰ１００と同様の構成を備えたＭＦＰ１１０、ＰＣ１２０、文書管理サーバ１３０がそれぞれ接続されている。ＬＡＮ１５０上の各端末は相互にデータ通信が可能であって、ＬＡＮ１５０を介してインターネットにも接続されている。

文書管理サーバ１３０は、ＨＤＤなどの記憶装置１３３を備えており、複数の文書を記憶しておくことができる。なお、記憶装置１３３が記憶する文書とは、文字コードからなるテキストデータでなくともよく、後述するＭＦＰ１００のスキャナ装置で原稿上の画像を読み取って得られたビットマップ画像や、その他のフォーマットの画像データであってもよい。ＣＰＵ１３１は、文書管理サーバ１３０全体の動作を制御するものであり、記憶装置１３３内に設けられたメモリに格納されたプログラムを読み出して動作する。

また、ＣＰＵ１３１はネットワークＩ／Ｆ１３２を介して、ＬＡＮ１５０上の端末（例えばＭＦＰ１００）から文書の検索要求を受信すると、検索要求とともに受け取った検索条件に従って記憶装置１３３に記憶された文書を対象として検索を実行する。そして、検索終了後、ネットワークＩ／Ｆ１３２を介して、検索結果としてヒットした文書の総数、及び各文書のインデックス情報（文書名、ページ数、保存日時、など）を検索依頼元の端末に通知する。

図２は、ＭＦＰ１００のシステム構成図である。ＭＦＰ１００は原稿上の画像を読み取って入力し、印刷・保存、または画像データを他の外部装置へ送信することができる。ＭＦＰ１００は大きく分けて、装置全体の制御を行う制御ユニット２００、出力画像の記録紙への印刷を行うプリンタ装置２５０、原稿から画像を読み取り、画像データとして装置内部に入力するスキャナ装置２６０からなる。

制御ユニット２００は、ネットワークＩ／Ｆ２０１を介して各クライアント端末や文書管理サーバなどと通信する。入出力バッファ２０２は、ネットワークから入力される印刷のための制御コードや、各種ＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データや、またはＭＦＰ１００に関する各種データを送受信する際に利用される。ＣＰＵ２０５はＭＦＰ１００全体の動作を制御する。プログラムＲＯＭ２２０には、ＣＰＵ２０５の動作を記述するプログラムが格納されている。ＣＰＵ２０５は、プログラムＲＯＭ２２０に記憶されているプログラムを読み出して実行することで、ＭＦＰ１００の備える各種機能を実現する。

ＲＡＭ２０９は、制御コードやデータの解釈や印刷、画像の読み取り等に必要な計算、入出力される画像データの処理のためのワークメモリに利用される。不揮発性ＲＡＭ（ＮＶＲＡＭ）２０８は、装置の電源が遮断されても保持しておく必要のあるデータを格納する。プログラムＲＯＭ２２０内にある制御データ解釈部２２１とＰＤＬデータ解釈部２２２は、それぞれ外部のＰＣなどから受信した印刷制御データやＰＤＬデータを解釈する。画像情報生成部２２３は、各種の画像オブジェクトを生成する。ビットマップ画像展開部２２４は、画像オブジェクトをビットマップ画像データに展開する。検索条件判定部２２５は、操作パネル部２３０でユーザが入力した検索条件が適正であるか否かを判定する。

ビットマップ画像転送部２０６は、ビットマップ画像展開部２２４によって展開されたビットマップ画像や、スキャナ装置２６０から原稿上の画像を読み込んで得られたビットマップ画像等を、プリンタ装置２５０に転送する。エンジンＩ／Ｆ部２０７は、ビットマップ画像転送部２０６とプリンタ装置２５０のエンジン制御部２５１を接続するＩ／Ｆである。

ビットマップ画像受信部２１０は、スキャナ装置２６０で読み込まれたビットマップ画像を受信する。スキャナＩ／Ｆ部２１１は、スキャナ装置２６０のスキャナ制御部２６１とビットマップ画像受信部２１０を接続するＩ／Ｆである。

操作パネル部２３０は、ユーザから操作指示を受け付け、またはエラーや各種処理結果、操作ガイドなどの表示を行う。パネルＩ／Ｆ部２０３は、操作パネル部２３０と制御ユニット２００を接続するＩ／Ｆである。外部メモリ部２４０は、印刷データや外部から取得した画像データ、装置の各種情報などを記憶しておくことができ、メモリＩ／Ｆ部２０４を介して制御ユニット２００と接続されている。

図３は、操作パネル部２３０に備えられた液晶表示部に表示される検索条件入力画面である。ＭＦＰ１００はモードキー３０１〜３０４を選択することにより、ＭＦＰ１００が備える各種モードを切り替えることができる。モードキー３０１を選択した場合は、「コピーモード」が選択される。コピーモードは、スキャナ装置２６０で読み取って得た画像データをプリンタ装置２５０において印刷するといったコピー処理を行うモードである。

モードキー３０２を選択した場合は、「送信モード」が選択される。送信モードは、スキャナ装置２６０で読み取って得た画像データを、電子メールに添付するなどをして、ＬＡＮ１５０を介して外部装置に対して送信する送信処理を行うモードである。モードキー３０４を選択した場合は、「ボックスモード」が選択される。ボックスモードは、スキャナ装置２６０で読み取って得た画像データを、ＭＥＭＯＲＹ２１２に設けられた記憶領域（ボックス）に記憶するか、またはＬＡＮ上の他の装置に備えられた記憶領域に記憶させる処理を行うモードである。

図３に示す画面は、検索モードが選択された場合に表示される画面である。検索モードは、文書管理サーバ１３０のＨＤＤ１３３に記憶された複数の文書の中から、ユーザが所望する文書を検索する処理を行うモードである。図３に示す検索条件入力画面上において、ユーザは所望の文書を検索するために用いる検索条件を入力することができる。検索場所指定欄３１０には、検索対象としたい文書が記憶されている記憶装置を指定する。ここでは、文書管理サーバ１３０が選択されていることが分かる。検索場所指定欄３１０右隅の▼印を押下すると、検索場所として指定可能な他の選択肢がコンボボックスとして表示される。

キーワード指定欄３２０には、最大３種類の文字列を入力することができる。この文字列は検索条件として用いられる検索キーワードであって、例えば“売上”という文字列が指定された場合は、文書中に“売上”の文字列が含まれている文書が、検索結果としてヒットする。なお、「検索結果としてヒットする」とは、検索条件として指定された条件に適合する文書が、検索を実行した検索エンジンによって特定されて、例えばそれらの文書名などを含むインデックス情報が通知されることを意味している。

続いて、論理式指定欄３３０には、キーワード指定欄３２０で入力された文字列の組み合わせを示すために演算子を用いた検索論理式を入力することができる。例えば、図３に示す“＊”は論理積演算子であって、両隣の文字列をＡＮＤ条件で組み合わせて検索条件とする。“＋”は論理和演算子であって、両隣の文字列をＯＲ条件で組み合わせて検索条件とする。図３に示す論理式では、“推移”と“２０１０年”の文字列をＯＲ条件として組み合わせた上で、さらにその結果と“売上”の文字列をＡＮＤ条件として組み合わせている。キーワードを１種類だけ指定する場合には、演算子を使用せずに“１”という論理式を作成することも可能である。論理式の指定方法は、上述した以外にも公知の検索条件を指定するための方法であれば、いずれの方法であっても構わない。

なお、ここでは文書を検索するための条件として、検索したい文書中に含まれる文字列を指定する場合について説明したが、検索条件として他の項目を用いてもよい。例えば、検索したい文書の文書名や作成者、または記憶装置に記憶された日付を検索条件として指定できるようにしてもよい。図３に示す画面で検索条件の入力が完了したら、実行ボタン３４０を押下することによって、ＣＰＵ２０５はネットワークＩ／Ｆ２０１を介して文書管理サーバ１３０に、入力された検索条件を含む検索要求を送信する。

図４は、文書管理サーバ１３０から通知されてきた検索結果情報に基づいて、操作パネル部２３０に表示される検索結果表示画面を示している。この画面の上部には、検索条件表示欄４０１が設けられており、図３に示す画面で入力された検索条件が、図示するようにキーワードと論理式を組み合わせた形で表示されている。文書数表示欄４０２には、検索結果としてヒットした文書数が表示される。図４の例では、検索条件表示欄４０１に表示された検索条件を用いて検索を実行した結果、１１８件の文書が検索結果としてヒットしたことを示している。また、検索結果表示画面には、検索結果としてヒットした文書のインデックス情報が、項目４１１〜４１４に対応する情報とともにリスト状で表示される。ここで表示される項目４１１〜４１４はそれぞれ、文書名、文書に含まれるページ数、文書の保存日、文書の保存場所を示す。

さて、第１の実施形態では、検索結果として多数の文書がヒットした場合は、より絞り込んだ検索条件を用いて再検索を行う必要が生じ手間がかかってしまうという問題を解決するために、入力された検索条件が適正か否かの判定を行うようにしている。例えば、検索結果としてヒットする文書数の上限値が予め１００件と設定されているとする。この場合、図４の例では、検索結果としてヒットした文書数は上限値を上回っているので、“売上”＊（“推移”＋“２０１０年”）の検索条件は適正でない検索条件として判定される。

適正でない検索条件、即ち、その検索条件を用いて検索を実行した場合に検索結果として予め設定された上限値を上回る文書数がヒットする検索条件と判定された検索条件は、図５に示すような構造を用いてＭＥＭＯＲＹ２１２内で管理される。図５は、上限値を超える文書数が検索結果としてヒットする検索条件を特定するための情報（検索条件特定情報）である。検索条件特定情報は、図５に示すように、検索条件毎に１つのレコードとして管理されており、検索が実行されてその検索結果として上限値以上の文書数がヒットする毎に新たなレコードが追加されていく。各レコードには領域５０１〜５０５のそれぞれに検索条件に関する情報が含まれている。領域５０１には、検索結果として上限値を上回る数の文書がヒットした場合に、その検索に用いられた検索条件を示す情報が格納されている。領域５０２には、領域５０１に格納された検索条件を用いた検索が実行された日時を示す情報が格納されている。領域５０３には、検索の結果ヒットした文書数を示す情報が格納されている。領域５０４には、レコードを作成した後で、レコードの内容が更新された最新の日時を示す情報が格納されている。領域５０５には、レコードが作成または更新された際に、文書管理サーバ１３０のＨＤＤ１３３に格納されていた文書の総数を示す情報が格納されている。

次に、図６乃至図８のフローチャートを用いて、図５に示した検索条件特定情報に基づいて、ユーザにより入力された検索条件が適正な検索条件であるか否かを、過去の検索結果に基づいて検索実行前に判定する処理に関する動作を説明する。図６乃至図８に示す動作は、ＭＦＰ１００のＣＰＵ２０５が、プログラムＲＯＭ２２０またはＭＥＭＯＲＹ２１２に格納された検索条件判定部２２５などのプログラムを読み出して、実行するものである。

図６は、入力された検索条件が適正かどうか判定し、適正なものであると判定した場合に検索を実行するとともに、検索結果として上限値を上回る数の文書がヒットした場合に、その検索条件を特定するための情報を管理する動作に関するフローチャートである。

まずステップＳ６０１では、ユーザにより検索モードが選択されたか否かを判定する。ここで、検索モードが選択された場合は、ステップＳ６０２に進み、図３に示す検索条件入力画面を表示し、ユーザによる検索条件の入力を受け付ける。ステップＳ６０１で、検索モード以外のモードが選択された場合は、そのモードへ移行する。

次に、ステップＳ６０３において、実行ボタン３４０が押下されたか否かを判定する。実行ボタン３４０が押下されたと判定した場合は、ステップＳ６０４に進み、入力された検索条件が適正であるか否かを判定する。続くステップＳ６０５において、ステップＳ６０４における判定の結果に基づいて、検索条件が適正であると判断されたか否かを判断し、検索条件が適正であると判断した場合には、ステップＳ６０６に進む。なお、第１の実施形態における「適正な検索条件」とは、その検索条件を用いて検索を実行した場合に、予め設定された上限値を上回る数の文書が検索結果としてヒットすることがない検索条件とする。

ステップＳ６０６では、入力された検索条件を含む検索実行要求を文書管理サーバ１３０に送信する。続くステップＳ６０７では、文書管理サーバ１３０から通知された検索結果（文書の総数及びそれらの文書のインデックス情報を含む）を受け取って、ステップＳ６０８において操作パネル部２３０に表示する。なお、この後、フローチャートには記載しないが、操作パネル部２３０に表示された文書のインデックス情報に基づいて、ユーザが文書を選択すると、その文書を文書管理サーバ１３０からダウンロードしたり、他の装置へ送信したりすることが可能となっている。

ステップＳ６０９では、検索結果として文書管理サーバ１３０から通知された文書の総数が、上限値を上回っているか否かを判定する。ここで、「上限値」とは管理者モードにおいて予め設定される値であって、任意の整数Ｎ（０＜Ｎ）を設定することができる。

ステップＳ６０９で、検索結果としてヒットした文書の数が上限値を上回ると判定した場合は、ステップＳ６１０において、図５に示す検索条件特定情報として新たにレコードを作成して、検索に用いられた検索条件をＭＥＭＯＲＹ２１２に格納して管理する。これは、再び同一の検索条件が入力されて検索が実行された場合には、再度多数の文書が検索結果としてヒットしてしまうという無駄が発生するため、この無駄を防ぐために、入力された検索条件が適正であるか否かを判定するための情報として管理される。ステップＳ６０９で検索結果が上限値を下回っていた場合、またはステップＳ６１０で検索条件特定情報のレコードを作成した後、処理を終了する。

図７は、図６のステップＳ６０４における入力された検索条件を判定する処理を詳しく説明するためのフローチャートである。まずステップＳ７０１においてＭＥＭＯＲＹ２１２において管理されている検索条件特定情報を読み出す。続くステップＳ７０２において、ステップＳ６０２で入力された検索条件に一致する検索条件のレコードが、ステップＳ７０１で読み出した検索条件特定情報の中に存在するか否かを判定する。該当するレコードが存在する場合は、ステップＳ７０３に進み、入力された検索条件は適正でないと判定する。一方、該当するレコードが存在しない場合は、ステップＳ７０４に進み、入力された検索条件は適正であると判定する。

図８は、図６のステップＳ６０５において、検索条件が適正でないと判定されたと判断した場合の動作を説明するためのフローチャートである。まず、ステップＳ８０１において図９に示す画面を、操作パネル部２３０に表示させる。図９に示す画面は、入力された検索条件を用いた検索を実行すべきでない旨をユーザに通知するための画面であって、該検索条件を用いて検索した場合に検索結果として上限値を上回る数の文書がヒットしてしまう可能性があることを警告するための画面である。図９に示す画面には、ユーザに択一的に選択を促すボタン９１１〜９１３が表示される。

図８のステップＳ８０２では、ボタン９１１が押下されたか否かを判定する。ボタン９１１は、検索結果として多数の文書がヒットしてしまう可能性を考慮した上で、入力された検索条件を用いた検索を実行することをユーザが望む場合に押下するボタンである。ボタン９１１が選択された場合は、図６に示すステップＳ６０６に進み、検索処理を開始する。

ステップＳ８０２でボタン９１１が押下されていないと判定した場合は、ステップＳ８０３に進み、ボタン９１２が押下されたか否かを判定する。ボタン９１２は、図９に示す画面に表示された警告を受けて、ユーザが入力した検索条件を編集（再入力）することを望む場合に押下するボタンである。ボタン９１２が選択された場合は、図６に示すステップＳ６０２に戻り、検索条件の再入力を受け付ける。

ステップＳ８０３でボタン９１２が押下されていないと判定した場合は、ステップＳ８０４に進み、ボタン９１３が押下されたか否かを判定する。ボタン９１３は、図９に示す画面に表示された警告を受けて、ユーザが検索の実行をキャンセルする場合に押下するボタンであって、ボタン９１３が押下された場合は処理を終了する。なお、ステップＳ８０４でボタン９１３が押下されていないと判定した場合は、Ｓ８０２に戻り、ボタン９１１〜９１３のいずれかが押下されるまで監視する。

このように、図６のステップＳ６０５で検索条件が適正でない、即ち、その検索条件を用いて検索を実行した場合に、上限値を上回る数の文書が検索結果としてヒットすると判定した場合は、その検索条件を用いた検索が実行されないよう制御する。なお、「検索が実行されないよう制御する」とは、具体的には、図９に示す画面を用いて、入力された検索条件が適正でない旨を警告することによって、ユーザに検索の実行を再考することを促すよう操作パネル部２３０の表示を制御することを指す。これにより、ユーザは自分の入力した検索条件では、検索結果としてヒットする文書が多くなりすぎることを検索実行前に知ることができるので、無意味な検索の実行を抑制することができる。また、ボタン９１１を設けたことにより、「適正でない検索条件」と判断されたとしても、ユーザが望めば強制的に検索を実行することができる。これにより、例えば、判断の元となった情報が古い場合には、その検索条件を用いた検索の結果としてヒットする文書数が変化している可能性もあるので、ユーザは自らの判断で検索を実行するかどうかを決めることができる。

また、「検索が実行されないよう制御する」内容として、入力された検索条件が適正でないと判定された場合に、その検索条件を用いた検索を実行することを禁止するように制御してもよい。これにより、広すぎる検索条件を用いた検索を防ぐことができるので、実際に検索処理を行う検索エンジン、または検索要求や検索結果の情報を通信するネットワークにかかる負荷を軽減することができる。この場合、図９に示す画面には、ボタン９１１は表示されず、ボタン９１２及び９１３のみが表示される。

また、第１の実施形態では、ネットワーク上の文書管理サーバ１３０内に記憶されている文書を検索対象として検索を実行するために、検索要求を文書管理サーバ１３０に送信する例について説明したが、他の態様であっても構わない。例えば、図３に示す画面上の検索場所指定欄３１０において、ＭＦＰ１００内のＭＥＭＯＲＹ２１２を指定した場合には、ＭＦＰ１００内に備えられ、文書管理サーバ１３０と同様の機能を有する文書検索部が、入力された検索条件に従った検索を実行する。

以上のように説明した第１の実施形態によると、入力された検索条件を用いて検索を行った結果、上限値を上回る数の文書が検索結果としてヒットした場合に、その検索条件を特定するための情報をＭＥＭＯＲＹ２１２に格納して管理するようにしている。そして、その後ユーザにより検索条件が入力された場合に、管理した情報に基づいて、その検索条件が適正かどうか、即ち、その検索条件を用いて検索を実行した場合に、上限値を上回る数の文書が検索結果としてヒットする検索条件であるか否かを判定する。さらに、その判定の結果、入力された検索条件が適正でないと判定された場合には、その検索条件を用いた検索が実行されないよう制御するようにしている。

これにより、例えば、過去に検索を実行した際に、膨大な数の文書が検索結果としてヒットしてしまった検索条件を再び用いて検索を実行してしまうことを抑制することができる。つまり、ユーザは実際に検索処理が実行される前に、自分の入力した検索条件が適正なものかどうかを知ることができるので、検索式を入力する度に検索を実行してその間待たされることがなくなる。また、無駄な検索処理を抑制することにより、検索エンジンまたはネットワークに無駄な負荷がかかることを防ぐことができる。

（第２の実施形態）
次に、本発明の第２の実施形態を説明する。

第２の実施形態における第１の実施形態との違いは、第１の実施形態では検索場所として記憶装置を１つだけ指定して検索を実行させることについて説明したが、第２の実施形態では複数の記憶装置を指定して一斉に検索要求を行うことができる点である。また、それぞれの記憶装置毎に、上述した検索条件特定情報のレコードを管理するようにしている。第２の実施形態における基本的な構成は、第１の実施形態と同様であるので、ここでは第２の実施形態について第１の実施形態とは異なる部分についてのみ説明する。

図１０は、第２の実施形態にかかわる文書管理システムのシステム全体の構成図を示している。ここでは、図１に示した構成図と比較して、ＬＡＮ１５０、ＭＦＰ１００、ＭＦＰ１１０、ＰＣ１２０、文書管理サーバ１３０は同様であるが、それらに加えて、文書管理サーバ１３０と同様の機能を備える文書管理サーバ１４０を更に備えている。

図１１は、第２の実施形態における検索条件入力画面である。ここでは、第１の実施形態とは異なり、検索場所指定欄１１１０には複数の記憶装置を検索場所として指定することが可能となっている。ここで複数の記憶装置が指定された場合には、検索を実行する際に、各記憶装置に対して一斉に検索要求を行う。また、各記憶装置から通知される検索結果には、それぞれの記憶装置において検索結果としてヒットした文書のインデックス情報と文書数を示す情報が含まれている。

第２の実施形態では、検索結果として上限値を上回る数の文書がヒットした場合に、その検索に用いた検索条件を特定するための情報を、記憶装置毎に区別して管理する。図１２は、第２の実施形態における検索条件特定情報のレコードの構造を示している。

この検索条件特定情報は、１つまたは複数の記憶装置が指定されて検索が実行され、その検索結果としてヒットした文書数の合計が上限値を上回った場合にレコードが新たに作成されて追加される。各レコードのそれぞれには、検索に用いた検索条件（１２１１）とともに複数のサブレコード（１〜４）が含まれている。さらに各サブレコードのそれぞれには、検索を実行した記憶装置を示す情報（図１２には文書管理サーバ１４０で検索された結果を示すサブレコードを例示する）が領域１２２１に格納される。領域１２２２〜１２２５は、図５の領域５０２〜５０５とそれぞれ同様であるので説明は省略する。なお、サブレコードは、図１１の検索場所指定欄１１１０で指定された記憶装置の数だけ作成される。

次に、図６を参照して、第２の実施形態における動作の詳細について説明する。なお、特に説明しない部分については第１の実施形態と同様の動作をするものとする。

ステップＳ６０２では、図１１に示す画面を用いてユーザが入力した検索条件であって、１つまたは複数の記憶装置が検索場所として指定された検索条件の入力を受け付ける。ステップＳ６０６では、検索場所として指定された記憶装置のそれぞれに対して一斉に検索要求を行う。そして、ステップＳ６０７では各記憶装置から検索結果としてヒットした文書のインデックス情報及び文書数を示す情報を含む検索結果情報を受け取る。ステップＳ６０９では、それぞれの記憶装置において検索結果としてヒットした文書の合計数を算出したうえで、上限値を上回っているかどうかを判定する。上限値を上回る数の文書がヒットした場合は、ステップＳ６１０において記憶装置毎のサブレコードを含むレコードを新たに作成し、検索条件特定情報として管理する。

図１３は、第２の実施形態のステップＳ６０４における、入力された検索条件を判定する処理を詳しく説明するためのフローチャートである。なお、図１３に示す動作は、ＭＦＰ１００のＣＰＵ２０５が、プログラムＲＯＭ２２０またはＭＥＭＯＲＹ２１２に格納された検索条件判定部２２５などのプログラムを読み出して、実行するものである。

まず、ステップＳ１３０１においてＭＥＭＯＲＹ２１２で管理されている検索条件特定情報に含まれる各レコードを読み出す。続くステップＳ１３０２において、入力された検索条件と各レコードに含まれる検索条件とを比較し、入力した検索条件に一致する検索条件を含むレコードが存在するかどうか判定する。該当するレコードが存在しない場合は、ステップＳ１３１１に進み、入力された検索条件は適正であると判定して図６のフローチャートへに戻る。ステップＳ１３０２で、該当するレコードが存在すると判定した場合は、ステップＳ１３０３に進み、そのレコードに含まれる各サブレコードを読み出す。続く、ステップＳ１３０４では、入力された検索条件において指定された記憶装置を示す情報のうちいずれか１つを取り出す。そして、ステップＳ１３０５では、取り出した情報が示す記憶装置に一致する記憶装置を示す情報を含むサブレコードが存在するかどうか判定する。該当するサブレコードが存在する場合は、そのサブレコードの領域１２２３に格納されている文書数情報を読み出してセットする。ステップＳ１３０５で、該当するサブレコードが存在しないと判定した場合は、ステップＳ１３０７に進み、文書数として０をセットする。ステップＳ１３０８では、指定された記憶装置全てについてステップＳ１３０４〜Ｓ１３０７の処理を完了したか判定し、完了していなければステップＳ１３０４に戻る。完了していれば、ステップＳ１３０９に進み、ステップＳ１３０６及びステップＳ１３０７でセットされた文書数の合計数が上限値を上回っているかどうか判定する。この判定の結果、上限値を上回っていればステップＳ１３１０に進み、入力された検索条件は適正でないと判定する。ステップＳ１３０９の判定の結果、上限値を上回っていなければステップＳ１３１１に進み、入力された検索条件は適正であると判定する。

なお、第２の実施形態における図６のステップＳ６１０における処理では、検索に用いた検索条件に対応するレコードを新たに作成しない場合もある。即ち、例えば図１３のステップＳ１３０９を介してステップＳ１３１１で、検索条件が適正であると判定された場合は、既にレコードがあるにも関わらず検索が実行されることになる。この時は、既に管理されている検索条件特定情報のレコードを更新するようにしてもよいし、検索場所として指定された記憶装置に対応するサブレコードが存在しない場合は、そのサブレコードを新たに作成するようにしてもよい。

上述のような動作は、以下のような場合に必要となる。例えば、ある検索条件に対して記憶装置Ａ（文書数４０）・Ｂ（文書数５０）・Ｃ（文書数３０）にそれぞれ対応するサブレコードが管理されているとする。なお、カッコ内はそれぞれの記憶装置で検索を行った結果としてヒットした文書数を示している。この時、検索場所として記憶装置Ａ・Ｄが指定されて同一の検索条件が入力された場合を考える。図１３のフローチャートに沿って判断すると、記憶装置Ｄに格納されている文書のうち、検索結果としてヒットする文書数は不明であるので、ステップＳ１３０９では合計文書数４０が上限値（＝１００）を超えていないと判定される。そして、この検索条件を用いて検索が実行された後、ステップＳ６０１に進む。ステップＳ６１０では、検索場所Ａのサブレコードは既に存在するので更新してもよいし、更新せずにスキップしてもよい、検索場所Ｄのサブレコードは存在しないので、新たに作成する。

以上のように説明した第２の実施形態では、検索場所として指定される記憶装置毎に、検索結果としてヒットした文書数を管理するようにしている。これにより、第１の実施形態で説明した効果に加えて、複数の記憶装置に対して検索要求を行うような環境であっても、入力された検索条件が適切かどうかを正確に判定することができるので、より使い勝手がよくなる。

（第３の実施形態）
次に、本発明の第３の実施形態を説明する。

第３の実施形態における第１の実施形態との違いは、第１の実施形態は検索条件特定情報として、キーワード及び論理式を含む検索条件毎にレコードを管理していたが、第３の実施形態では、キーワード毎にレコードを作成して管理する点である。第３の実施形態における基本的な構成は、第１の実施形態と同様であるので、ここでは第３の実施形態について第１の実施形態とは異なる部分についてのみ説明する。

図１４は、第３の実施形態における検索条件特定情報のレコードの構造を示す。図１４は、図３に示す画面で入力されている検索条件で検索した結果（文書数１０８件）に基づいて管理されている検索条件特定情報を示す。第１の実施形態では、キーワード及び論理式を含む検索条件毎にレコードを作成して管理していたが、第３の実施形態では、キーワード毎にレコードが作成されて管理されていることが分かる。領域１４０１には指定されたキーワードを示す情報が格納される。領域１４０２には、領域１４０１に格納されたキーワードを用いて検索が実行された日付の情報が格納される。領域１４０３には、領域１４０１に格納されたキーワードを含む文書の数を示す情報が格納される。言い換えれば、領域１４０３に格納される文書数とは、領域１４０１に格納されたキーワードのみを検索条件として指定した場合の検索結果としてヒットする文書数を意味する。なお、領域１４０３に格納されるべき情報は、キーワード毎に文書管理サーバ１３０から検索結果として通知されるものとする。

図１５は、図１４に示す検索条件特定情報に基づいて、図６のステップＳ６０４において検索条件が適正であるか否かを判定する処理を説明するためのフローチャートである。なお、図１５に示す動作は、ＭＦＰ１００のＣＰＵ２０５が、プログラムＲＯＭ２２０またはＭＥＭＯＲＹ２１２に格納された検索条件判定部２２５などのプログラムを読み出して、実行するものである。

まず、ステップＳ１５０１において、ＭＥＭＯＲＹ２１２に格納された検索条件特定情報を読み出す。続くステップＳ１５０２では、図３の論理式指定欄３３０に入力された論理式を解析し、論理積演算子（“＊”）で組み合わされていない独立項があるか否かを判断する。例えば、「Ａ＊Ｂ」という論理式であればＡとＢの両方が“＊”を用いて組み合わされているので、ステップＳ１５０２ではＮｏと判定される。また、「Ａ＋Ｂ＊Ｃ」の場合は、ＢとＣはそれぞれ“＊”で組み合わされているものの、直接的に“＊”を用いて組み合わされていないＡが存在するため、ステップＳ１５０２ではＹｅｓと判定される。さらに、「Ａ＊（Ｂ＋Ｃ）」という論理式の場合は、ＢとＣはそれぞれ“＊”を用いてＡと組み合わされているためステップＳ１５０２ではＮｏと判定される。なお、論理式として「Ａ」のみが指定された場合も、ステップＳ１５０２ではＹｅｓと判定されることになる。

ステップＳ１５０２において、論理積演算子（“＊”）で組み合わされていない独立項が存在すると判定した場合は、ステップＳ１５０３に進み、ステップＳ１５０２で特定された独立項のキーワードに対応する文書数が上限値を上回っているか否かを判定する。この判定に用いる文書数とは、ステップＳ１５０１で読み出した検索条件特定情報に含まれるレコードの領域１４０３に格納された情報を参照することにより得られる。

ステップＳ１５０２における判定の結果、上限値を上回る文書数が検索結果としてヒットするキーワードが独立項として存在する場合は、ステップＳ１５０４に進み、入力された検索条件が適正でないと判定する。また、ステップＳ１５０２において、上限値を上回る文書数が検索結果としてヒットするキーワードが独立項として存在しないと判定された場合は、ステップＳ１５０５に進み、入力された検索条件は適正であると判定する。

図１５に示すフローチャートでは、論理式の中に論理積演算子で組み合わせられていない独立項が存在し、且つその独立項のキーワードにより検索結果としてヒットする文書数が上限値を上回る場合に、入力された検索条件を適正でないと判定するようにしている。即ち、上記のような独立項が存在した場合は、他のキーワード及び論理式がどのようなものであろうとも、検索結果としてヒットする文書数は上限値を上回ってしまうので、検索条件として適性でないと判定している。なお、ここではＡＮＤ条件を示す“＊”、及びＯＲ条件を示す“＋”のみを論理式に使用できる場合について説明したが、他の演算子を使用できるようにした場合は、それに応じて図１５のフローチャートに替わる適切な判定方法を採用するようにしてもよい。

以上のように説明した第３の実施形態では、検索条件として指定されるキーワード毎に検索条件特定情報のレコードを作成して管理するようにしている。これにより、第１の実施形態で説明した効果に加えて、より柔軟に検索条件が適正か否かの判定を行うことが可能となる。具体的には、第１の実施形態では、「Ａ＋Ｂ＋Ｃ」という検索条件を特定するための情報が検索条件特定情報として管理されている場合に、「Ａ＋Ｂ＊Ｃ」という検索条件が入力されたとしても、該当するレコードは存在しないと判定していた。しかしながら、第３の実施形態では、Ａ・Ｂ・Ｃそれぞれが別々のレコードとして管理されているので、論理式の組み合わせ方が異なったとしても、各キーワードに対応するレコードが管理されていれば、検索条件が適正であるか否かを判定することが可能となる。

（第４の実施形態）
次に、本発明の第４の実施形態を説明する。

第４の実施形態における第１の実施形態との違いは、第１の実施形態は検索条件が適正かどうかを判断するための条件として、検索結果としてヒットする文書数の上限値を１つ設定していたが、第４の実施形態では２種類の上限値を設けている点である。第４の実施形態における基本的な構成は、第１の実施形態と同様であるので、ここでは第４の実施形態について第１の実施形態とは異なる部分についてのみ説明する。

図１６は、第４の実施形態における検索条件特定情報のレコードの構造を示す。図１６に示すように、第４の実施形態では検索条件特定情報として管理されるレコードは、グループ（１）またはグループ（２）に分類されている。グループ（１）とは、このグループに含まれるレコードにより特定される検索条件を用いて検索を実行した場合、第１の上限値（以下、禁止上限値とする）を上回る数の文書が検索結果としてヒットすることを意味する。グループ（２）とは、このグループに含まれるレコードにより特定される検索条件を用いて検索を実行した場合、禁止上限値は上回らないが、禁止上限値よりも低い値である第２の上限値（警告上限値）を上回る数の文書が検索結果としてヒットすることを意味する。なお、これらの上限値は、予めユーザが任意に設定できるようにしてもよいし、文書検索システム全体を管理する管理者により設定されるようにしてもよい。

このように、第４の実施形態では、検索を実行した結果として、設定された数以上の文書がヒットした場合に、ヒットした文書数に応じて２つのグループに分類したうえで、検索条件特定情報のレコードとして管理する。なお、各レコードの領域１６０１〜１６０５に格納される情報の内容は図５の領域５０１〜５０５に格納される情報の内容と同様であるので、説明は省略する。

次に図１７乃至図１９のフローチャートを用いて、図１６に示した情報に基づいて、ユーザにより入力された検索条件が適正であるか否かを、検索実行前に判定する処理に関する詳細な動作を説明する。図１７乃至図１９に示す動作は、ＭＦＰ１００のＣＰＵ２０５が、プログラムＲＯＭ２２０またはＭＥＭＯＲＹ２１２に格納された検索条件判定部２２５などのプログラムを読み出して、実行するものである。

図１７は、入力された検索条件が適正であるかどうか判定し、適正であると判定した場合に検索を実行し、さらに検索結果として設定された数以上の文書がヒットした場合に、その検索条件を特定するための情報を管理する動作を説明するフローチャートである。まずステップＳ１７０１では、ユーザにより検索モードが選択されたか否かを判定する。ここで、検索モードが選択された場合は、ステップＳ１７０２に進み、図３に示す検索モード基本画面上においてユーザによる検索条件の入力を受け付ける。ステップＳ１７０１で、検索モード以外のモードが選択された場合は、それぞれのモードに移行する。

次に、ステップＳ１７０２において、実行ボタン３４０が押下されたか否かを判定する。実行ボタン３４０が押下されたと判定した場合は、ステップＳ１７０４に進み、入力された検索条件が適正か否かを判定する。続くステップＳ１７０５において、ステップＳ１７０４における判定の結果に基づいて、検索条件が適正か否かを判定し、検索条件が適正であると判定された場合には、ステップＳ１７０６に進む。

ステップＳ１７０６では、入力された検索条件を含む検索実行要求を文書管理サーバ１３０に送信する。続くステップＳ１７０７では、文書管理サーバ１３０から検索結果としてヒットした文書数を示す情報及びそれらの文書のインデックス情報を含む検索結果を受け取って、ステップＳ１７０８において操作パネル部２３０に表示する。

ステップＳ１７０９では、検索結果として文書管理サーバ１３０から通知された文書数が、警告上限値を上回っているか否かを判定する。

ステップＳ１７０９で、検索結果としてヒットした文書数が警告上限値を上回っていると判定した場合は、続くステップＳ１７１０において、検索結果としてヒットした文書数が禁止上限値を上回っているか否かを判定する。ここで、禁止上限値を上回っていると判定した場合は、ステップＳ１７１１に進み、検索に用いた検索条件を特定するための情報として検索条件特定情報のグループ（１）に新たにレコードを作成して終了する。ステップＳ１７１０で、禁止上限値を下回っていると判定した場合は、ステップＳ１７１２に進み、検索に用いた検索条件を特定するための情報として検索条件特定情報のグループ（２）に新たにレコードを作成（若しくはレコードを更新）して終了する。なお、ステップＳ１７０９において、文書数が警告上限値を下回っていると判定した場合はそのまま終了する。

図１８は、図１７のステップＳ１７０４における入力された検索条件を判定する処理を詳しく説明するためのフローチャートである。まずステップＳ１８０１においてＭＥＭＯＲＹ２１２において管理されている検索条件特定情報のレコードを読み出す。続くステップＳ１８０２において、ステップＳ１７０２で入力された検索条件を特定するレコードが、ステップＳ１８０１で読み出したレコードの中に存在するか否かを判定する。該当するレコードが存在する場合は、ステップＳ１８０３に進み、そのレコードがグループ（１）に分類されているか否かを判定する。ステップＳ１８０３における判定の結果、該当するレコードがグループ（１）に分類されていると判定した場合は、ステップＳ１７０２で入力された検索条件が禁止レベルであると判定して、ステップＳ１７０５に進む。一方、ステップＳ１８０３における判定の結果、該当するレコードがグループ（１）に分類されていない（即ち、グループ（２）に分類されている）と判定した場合は、ステップＳ１７０２で入力された検索条件が警告レベルであると判定して、ステップＳ１７０５に進む。

図１９は、図１７のステップＳ１７０５において、検索条件が適正でないと判定された場合の動作を説明するためのフローチャートである。まず、ステップＳ１７０５において、検索条件が適正でないとされた場合は、ステップＳ１７０４において禁止レベルまたは警告レベルのいずれかであると判定されているので、ステップＳ１９０１でそのどちらであるかを判断する。ステップＳ１９０１での判断の結果、警告レベルであると判断された場合は、ステップＳ１９０２に進み、図９に示す画面を表示する。続く、ステップＳ１９０３〜Ｓ１９０５では、ユーザがボタン９１１〜９１３のうち、どのボタンを押下したかを判定し、それぞれ処理を異ならせる。なお、この動作は第１の実施形態における図８のステップＳ８０２〜Ｓ８０４と同様であるので、説明は省略する。

一方、ステップＳ１９０１での判断の結果、禁止レベルであると判断された場合は、ステップＳ１９０６に進み、図９に示す画面を表示する。但し、この時はステップＳ１７０２で入力された検索条件を用いた検索の実行が禁止されているので、ボタン９１１は表示されず、ボタン９１２及びボタン９１３のみが表示される。続くステップＳ１９０７及びＳ１９０８では、ユーザがボタン９１２及び９１３のいずれを押下したかを判定し、それぞれ処理を異ならせる。なお、この動作は、第１の実施形態における図８のステップＳ８０３及びＳ８０４と同様であるので、説明は省略する。

以上のように説明した第４の実施形態によれば、２種類の上限値の値を設定し、それぞれの値に基づいて入力された検索条件が適正であるか否かを判定する。そして、その判定の結果に応じて、入力された検索条件を用いた検索が実行されないようにするための制御内容を異ならせる。これにより、第１の実施形態で説明した効果に加えて、入力された検索条件のより詳細な判定及び、その判定に応じた適切な制御を行うことができるという効果がある。具体的には、例えば、ユーザが検索結果を確認できる限界数を上回る数の文書がヒットすることが予想される検索条件が入力された場合は、その検索条件を用いた検索の実行を禁止することができる。また、前述の限界数は下回るものの、比較的多い数の文書がヒットすることが予想される検索条件が入力されら場合は、その検索条件で検索すべきでない旨をユーザに警告することができる。

（第５の実施形態）
次に、本発明の第５の実施形態を説明する。

第５の実施形態における第１の実施形態との違いは、第１の実施形態において、検索条件特定情報として管理されているレコードを自動的に更新し、最新の情報を反映したものとする点である。第５の実施形態における基本的な構成は、第１の実施形態と同様であるので、ここでは第５の実施形態について第１の実施形態とは異なる部分についてのみ説明する。

図２０は、ＭＦＰ１００が動作していない任意のタイミングにおいて、自動的に実行される動作であって、検索条件特定情報として管理されているレコードを更新または削除するための処理を行う動作を説明するためのフローチャートである。なお、この処理はユーザが手動で指示したことに応じて、実行するようにしてもよい。図２０に示す動作は、ＭＦＰ１００のＣＰＵ２０５が、プログラムＲＯＭ２２０またはＭＥＭＯＲＹ２１２に格納された検索条件判定部２２５などのプログラムを読み出して、実行するものである。

まずステップＳ２００１において、ＭＥＭＯＲＹ２１２に格納されている検索条件特定情報の中から、レコードを１つ取り出す。続くステップＳ２００２において、取り出したレコードの領域５０４に格納された情報を参照し、最新のレコード更新日から３ヶ月以上が経過しているか否かを判定する。なお、この３ヶ月という期間はユーザが任意に設定できるものとする。ステップＳ２００２で、最新の更新日から３ヶ月が経過していないと判定した場合は、ステップＳ２００８に進む。また、ステップＳ２００２で、最新の更新日から３ヶ月以上が経過していると判定した場合は、ステップＳ２００３に進み、取り出したレコードの領域５０１に格納されている検索条件を含む検索要求を、文書管理サーバ１３０に対して行う。

ステップＳ２００４では、文書管理サーバ１３０から通知された、結果の結果ヒットした文書数を示す情報を受け取る。そして、ステップＳ２００５では、受け取った文書数が予め設定された上限値を上回っているか否かを判定する。その結果、文書数が上限値を上回っていると判定した場合は、ステップＳ２００６に進み、レコードの中の領域５０３〜５０５に格納されている情報を更新する。一方、ステップＳ２００５で文書数が上限値を下回っていると判定した場合は、ステップＳ２００７に進み、レコードを削除する。ステップＳ２００８では、検索条件特定情報として管理されているレコードの全てに対して処理を行ったかどうか判定し、完了していれば終了し、未処理のレコードがあればステップＳ２００１に戻る。

以上のように説明した第５の実施形態によれば、検索条件特定情報として管理されているレコードを最新の情報に基づいて更新または削除するようにしている。これにより、例えばある検索条件を用いて過去に検索した際には上限値以上の文書数がヒットした場合であっても、その後時間が経過してヒットする文書数が減少し、上限値を下回っている場合には、レコードを削除することができる。また、ここでは第１の実施形態を基にして説明したが、第４の実施形態のように警告レベルと禁止レベルとに区別してレコードを管理している場合に応用させることもできる。具体的には、グループ（２）（警告レベル）として管理されているレコードにより特定される検索条件でヒットする文書数が、時間が経過して増加してしまった場合には、レコードをグループ（２）からグループ（１）（禁止レベル）へ移動させて更新することができる。即ち、第５の実施形態では、検索条件特定情報が最新の情報に基づいて管理されているので、より正確な情報に基づいて入力された検索条件が適正であるか否かを判定することができる。

（第６の実施形態）
次に、本発明の第６の実施形態を説明する。

第６の実施形態における第１の実施形態との違いは、第１の実施形態において、検索条件特定情報として管理されているレコードを、文書管理サーバ１３０に記憶されている文書の総数に応じて自動的に更新し、最新の情報を反映したものとする点である。第６の実施形態における基本的な構成は、第１の実施形態と同様であるので、ここでは第６の実施形態について第１の実施形態とは異なる部分についてのみ説明する。なお、第６の実施形態では、第４の実施形態で説明したように、２種類の上限値を用いて検索条件特定情報のレコードを管理しているものとする。

図２１は、ＭＦＰ１００が動作していない任意のタイミングにおいて、自動的に実行される動作であって、検索条件特定情報として管理されているレコードを更新または削除するための処理を行う動作を説明するためのフローチャートである。なお、この処理はユーザが手動で指示したことに応じて、実行するようにしてもよい。図２１に示す動作は、ＭＦＰ１００のＣＰＵ２０５が、プログラムＲＯＭ２２０またはＭＥＭＯＲＹ２１２に格納された検索条件判定部２２５などのプログラムを読み出して、実行するものである。

まずステップＳ２１０１において、文書管理サーバ１３０に対して記憶装置１３３に記憶されている文書の総数を通知することを要求する。続くステップＳ２１０２で、文書管理サーバ１３０から通知された文書の総数を示す情報を受け取る。

ステップＳ２１０３では、ＭＥＭＯＲＹ２１２に格納されている検索条件特定情報のレコードを１つ取り出す。続くステップＳ２１０４において、ステップＳ２１０２で受け取った情報、及びステップＳ２１０３で取り出したレコードの領域５０３・５０５に格納されている情報に基づいて予測文書数を算出する。予測文書数とは、各検索条件を用いて検索を実行した場合に、現時点でヒットする文書数を、現在記憶装置に記憶されている文書の総数に基づいて予測した数である。即ち、「“予測文書数”＝“レコード領域５０３の文書数”×（“Ｓ２１０２で受け取った文書の総数”÷“レコード領域５０５の文書総数”）」の計算式を用いて求められるものである。ここでは、記憶されている文書の総数の増減に比例して、同じ検索条件でヒットする文書数も増減すると仮定して、文書の総数の増減に基づいてヒットする文書数を予測している。

ステップＳ２１０５では、算出した予測文書数が、警告上限値を上回っているか否かを判定する。ステップＳ２１０５で、予測文書数が警告上限値を上回っていると判定した場合は、続くステップＳ２１０６において、予測文書数が禁止上限値を上回っているか否かを判定する。ここで、禁止上限値を上回っていると判定した場合は、ステップＳ２１０７に進み、ステップＳ２１０３で取り出したレコードを、グループ（１）のレコードとして更新する。ステップＳ２１０７で、禁止上限値を下回っていると判定した場合は、ステップＳ２１０８に進み、ステップＳ２１０３で取り出したレコードを、グループ（２）のレコードとして更新する。なお、ステップＳ２１０５において、文書数が警告上限値を下回っていると判定した場合は、ステップＳ２１０９に進み、ステップＳ２１０３で取り出したレコードを削除する。

ステップＳ２１１０では、検索条件特定情報として管理されている全てのレコードに対して処理を終了したか否かを判断し、未処理のレコードがあればステップＳ２１０３に戻り、全て完了していれば終了する。

以上のように説明した第６の実施形態によれば、検索条件特定情報として管理されているレコードを記憶装置に記憶されている文書の総数の増減に基づいて更新または削除するようにしている。これにより、第５の実施形態で説明した効果に加えて、検索条件特定情報を更新するためにわざわざ検索を実行することなく、簡易的に検索条件特定情報を最新の状態に更新しておくことができるので、より使い勝手がよくなる。

なお、第１〜第６の実施形態として説明した内容は、それぞれ別々の形で実施してもよいし、組み合わせて実施することも可能である。また、検索条件の指定方法や、検索条件特定情報の管理方法、または検索対象となる文書の内容は、上述したものに限定されず、他の態様であっても構わない。

（その他の実施形態）
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体（記録媒体）等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、以下のようなものがある。フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。すなわち、ホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをダウンロードする。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他にも、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後にも前述した実施形態の機能が実現される。すなわち、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行うことによっても前述した実施形態の機能が実現される。

本発明の実施形態における文書管理システムのシステム全体の構成図である。 本発明の実施形態におけるＭＦＰ１００のシステムブロック図である。 本発明の実施形態における操作パネル部の検索条件入力画面を示す図である。 本発明の実施形態における操作パネルの検索結果表示画面を示す図である。 本発明の実施形態における検索条件特定情報のレコード構造を示す図である。 本発明の実施形態における検索の実行と、その検索の結果に基づいて検索条件特定情報を管理する一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件が適正であるか否かを判定する一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件が適正でないと判定した場合の一連の処理を明確に記述したフローチャートである。 本発明の実施形態における操作パネル部の警告表示画面を示す図である。 本発明の実施形態における文書管理システムのシステム全体の構成図である。 本発明の実施形態における操作パネル部の検索条件入力画面を示す図である。 本発明の実施形態における検索条件特定情報のレコード構造を示す図である。 本発明の実施形態における検索条件が適正であるか否かを判定する一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件特定情報のレコード構造を示す図である。 本発明の実施形態における検索条件が適正であるか否かを判定する一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件特定情報のレコード構造を示す図である。 本発明の実施形態における検索の実行と、その検索の結果に基づいて検索条件特定情報を管理する一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件が適正であるか否かを判定する一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件が適正でないと判定した場合の一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件特定情報を更新するための一連の処理を明確に記述したフローチャートである。 本発明の実施形態における検索条件特定情報を更新するための一連の処理を明確に記述したフローチャートである。

符号の説明

１００ ＭＦＰ（マルチファンクションプリンター）
１３０ 文書管理サーバ
１３３ 記憶装置（ＨＤＤ：ハードディスクドライブ）
１５０ ＬＡＮ（ローカルエリアネットワーク）
２００ 制御ユニット
２０１ ネットワークインターフェース
２０５ ＣＰＵ
２０９ ＲＡＭ
２１２ ＭＥＭＯＲＹ
２２０ プログラムＲＯＭ
２２５ 検索条件判定部
２３０ 操作パネル部
２５０ プリンタ装置
２６０ スキャナ装置

Claims (9)

1. 検索条件と当該検索条件を用いて検索した場合にヒットする文書の数を対応付けて管理する管理手段と、
   検索条件を入力する入力手段と、
   前記入力手段により検索条件が入力された場合に、前記管理手段が管理する文書の数を参照し、前記入力された検索条件を用いて検索した場合にヒットする文書の数が所定の数よりも多いか否かを、当該検索を実行する前に判定する判定手段と、
   前記判定手段による判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、当該検索の実行を制限する制御手段と、
   所定期間が経過したことに応じて前記管理手段が管理する検索条件を用いた検索を実行し、当該検索の結果に基づき前記管理手段が管理する文書の数を更新する更新手段と、
   を備えることを特徴とする文書検索システム。
2. ネットワークを介して接続された文書管理サーバに対して、前記入力された検索条件を用いた検索の実行を要求する要求手段を更に備えることを特徴とする請求項１に記載の文書検索システム。
3. 前記入力手段により入力される検索条件は、少なくとも文書に含まれる文字列、または該文字列の組み合わせを示す論理式を含むことを特徴とする請求項１または２に記載の文書検索システム。
4. 前記判定手段による判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、前記制御手段は、当該検索の実行を禁止することを特徴とする請求項１から３のいずれか１項に記載の文書検索システム。
5. 前記判定手段による判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、前記制御手段は、当該検索を実行すべきでない旨をユーザに通知するための画面を表示手段に表示させることを特徴とする請求項１から３のいずれか１項に記載の文書検索システム。
6. 前記判定手段による判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、前記制御手段は、前記入力手段により入力された検索条件を編集するための画面を表示手段に表示させることを特徴とする請求項１から３のいずれか１項に記載の文書検索システム。
7. 第１の値、及び当該第１の値よりも小さい第２の値を設定する設定手段を更に備え、
   前記制御手段は、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記第１の値よりも大きいと判定した場合は当該検索の実行を禁止し、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記第１の値よりも小さく且つ前記第２の値よりも大きいと判定した場合は当該検索を実行すべきでない旨をユーザに通知するための画面を表示手段に表示させることを特徴とする請求項１から６のいずれか１項に記載の文書検索システム。
8. 検索条件と当該検索条件を用いて検索した場合にヒットする文書の数を対応付けて管理する管理工程と、
   検索条件を入力する入力工程と、
   前記入力工程で検索条件が入力された場合に、前記管理工程で管理された文書の数を参照し、前記入力された検索条件を用いて検索した場合にヒットする文書の数が所定の数よりも多いか否かを、当該検索を実行する前に判定する判定工程と、
   前記判定工程における判定の結果、前記入力された検索条件を用いて検索した場合にヒットする文書の数が前記所定の数よりも多いと判定された場合に、当該検索の実行を制限する制御工程と、
   所定期間が経過したことに応じて前記管理工程で管理された検索条件を用いた検索を実行し、当該検索の結果に基づき前記管理工程で管理された文書の数を更新する更新工程と、
   を備えることを特徴とする文書検索方法。
9. 請求項８に記載の文書検索方法をコンピュータに実行させるためのプログラム。

Images