(57)【要約】【課題】  ユーザが指定したキーワードの順序を鑑みてフォルダパスから文書を検索することができるようにする。すなわち検索結果の精度向上を図る。【解決手段】  フォルダ等の階層構造を利用して文書を分類管理する文書管理システムにおいて、各フォルダのパス情報をインデキシングして保存しておき、ユーザが指定したキーワードからインデキシング情報に対する検索キーワードを生成し、インデキシング情報に対して検索を実行する【選択図】  図３
2009134582.tif 000002
【特許請求の範囲】
【請求項１】
フォルダの階層構造を利用して文書を分類管理する文書管理システムにおいて、
各フォルダにおけるパス情報をインデキシングして保持しておくパス情報インデキシング手段と、
ユーザが指定したキーワードから前記インデキシング情報に対する検索キーワードを生成する検索キーワード生成手段と、
前記インデキシング情報に対して前記検索キーワードで検索するパス情報検索手段と、
を有することを特徴とする文書管理システム。
【請求項２】
前記検索キーワード生成手段は、ユーザが複数指定したキーワードを左から順に階層構造の上位とみなしてインデキシング情報に対する検索キーワードを生成することを特徴とする請求項１に記載の文書管理システム。
【請求項３】
前記検索キーワード生成手段は、ユーザが複数指定したキーワードをすべてのパターンで並び替えてインデキシング情報に対する検索キーワードを階乗通り生成することを特徴とする請求項１に記載の文書管理システム。
【請求項４】
請求項１に記載の文書管理システムにおいて、システムは検索キーワードの指定時の予約語をあらかじめ用意しておき、ユーザは前記予約語を使用してキーワードを指定する検索キーワード指定手段を有することを特徴とする文書管理システム。
【請求項５】
前記検索キーワード生成手段は、ユーザに指定された予約語を解析してキーワードの並び順を制御してインデキシング情報に対する検索キーワードを生成することを特徴とする請求項１〜請求項４のいずれかに記載の文書管理システム。
【請求項６】
前記検索キーワード生成手段はユーザインタフェース上でユーザが切り替えられることを特徴とする請求項１〜請求項５のいずれかに記載の文書管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は文書管理システムにおける文書検索方法に関するものである。
【背景技術】
【０００２】
多くの文書管理システムにおいては、フォルダによる文書の分類管理がなされており、ユーザは階層をたどることによって所望の文書を得ることができる。また、或いは文書名や作成者などの属性情報に対してキーワードで検索することによって文書を得ることができる。
【０００３】
しかしながら運用の規模やルールの不明瞭などが原因で非常に大量の文書が無秩序に格納されている場合、所望の文書を得ることが困難になるといった問題がある。
【０００４】
例えば「ＡＢＣシステムＶ１．２の中のＸＹＺチームの定例の議事録」情報をユーザが取得したいとする。それらが以下のような階層構造で格納されているとする。
【０００５】
Ｃ：￥Ｐｒｏｊｅｃｔ￥ＡＢＣ￥Ｖ１．２￥Ｔｅａｍ￥ＸＹＺ￥定例
さらにフォルダに含まれるファイル名が以下のように日付のみであるとする。
【０００６】
２００７０５１１．ｔｘｔ
フォルダ構造をたどって見つける場合、その構造が明確に定まっておらず似たようなフォルダが乱立している場合は困難となる。またファイル名には日付の情報しかないため検索は難しい。フォルダ名で検索する場合も通常検索対象は１つのフォルダであるため「ＡＢＣシステムＶ１．２の中のＸＹＺチームの定例の議事録」のフォルダを検索することはできない。
【０００７】
膨大な数のファイルの中から所要のファイルを効率よく検索する方法の一つに階層構造のディレクトリによって管理されているファイルにキーワードを付与する際、任意の階層のディレクトリを指定して、任意のキーワードを入力すると、入力されたキーワードを指定された階層以下の階層に属する各ファイルのキーワードとしてキーワードファイルに登録するといった方法がある（例えば、特許文献１参照）。
【０００８】
またフォルダ階層を持つ文書管理システムにおいて、フォルダの索引を自動的に作成し、ユーザが容易に目的のフォルダを見つけ出すシステムがある（例えば、特許文献２参照）。索引を作ることによって単一のフォルダのみならずフォルダの階層構造も検索の対象となるが、ユーザがキーワードを複数指定して階層構造を検索するようなことは該先行例では述べられていない。
【０００９】
また、Ｇｏｏｇｌｅ（登録商標）デスクトップには、フォルダのパスで検索する機能がある。Ｇｏｏｇｌｅデスクトップでは例えば「ＡＢＣ  Ｖ１．２  ＸＹＺ  定例」で検索すると、これらのキーワードを含むフォルダパスが検索対象となる。しかしながらユーザの指定するキーワードの順序によってヒットする結果やランキングが変化することはなく、指定されたキーワードを含むパスを単純に検索していると思われる。
【特許文献１】特開２００１−２８００７号公報
【特許文献２】特開２００４−１１０６０９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述のごとく、大量の文書が無秩序に格納されている場合、特にそれが複数のユーザによって作成された場合は、フォルダを辿って文書を探すことは難しい。また単純な文書名、フォルダ名の検索では関連のない文書まで検索されてしまうという課題がある。ユーザがキーワードを付与する場合は当然その作業が必要になってしまう。フォルダパスに対する検索はこれらの課題に対して有効であるが、ユーザが指定したキーワードを含むすべてのフォルダパスが検索されるため、やはり関連のない文書まで検索される可能性があった。
【課題を解決するための手段】
【００１１】
上述した課題を解決するために、第１の発明である文書管理システムは、
フォルダの階層構造を利用して文書を分類管理する文書管理システムにおいて、
各フォルダにおけるパス情報をインデキシングして保持しておくパス情報インデキシング手段と、
ユーザが指定したキーワードから前記インデキシング情報に対する検索キーワードを生成する検索キーワード生成手段と、
前記インデキシング情報に対して前記検索キーワードで検索するパス情報検索手段と、
を有することを特徴とする。
【発明の効果】
【００１２】
本発明によって、ユーザが指定したキーワードの順序を鑑みてフォルダパスから文書を検索することができる。すなわち検索結果の精度向上が期待できる。
【発明を実施するための最良の形態】
【００１３】
次に、本発明の詳細を実施例の記述に従って説明する。
【実施例１】
【００１４】
以下、本発明の実施例を図面に基づいて説明する。
【００１５】
図１は本発明に係る文書管理システムの一実施例を示すブロック構成図である。ここではネットワーク上にクライアントＰＣ１０１、文書管理サーバ１０２、データベース１０３、スキャナ１０４、プリンタ１０５が接続されている。
【００１６】
クライアントＰＣ１０１は文書管理システムのクライアントＰＣであり、ユーザが実際に文書データの入力、参照、出力、などの操作を行うパーソナルコンピュータであり、図１では便宜上一つのみ記載しているが、本実施形態では、複数台のクライアントＰＣがネットワークに接続されていることを想定している。
【００１７】
文書管理サーバ１０２は文書管理システムのサーバＰＣであり、公知の技術で実現されるネットワーク処理の他に、主に文書データベースの構築、各装置間の文書データの送受信処理、アクセス制御を行なうセキュリティの管理、複数ユーザ間の排他制御処理、文書データを蓄積するデータベースの管理などを行なう。また本実施例ではデータベース１０３が付帯した構成となっている。
【００１８】
スキャナ１０４は、紙に印刷または記載された文字、図形、画像等のデータを読み取り、画像データに変換して出力する装置であり、ネットワークに接続されている。
【００１９】
プリンタ１０５はクライアントＰＣ１０１から送信された印刷データに従って印刷を行うプリンタである。
【００２０】
なおクライアントＰＣ１０１と文書管理サーバ１０２は、通常ユースケース上は別のノードに配置されるが同じノードであっても問題はない。
【００２１】
図２はクライアントＰＣ１０１、文書管理サーバ１０２のハードウェア構成を示すブロック図である。いずれもＩＢＭ−ＰＣ／ＡＴ互換機などの汎用ＰＣなので同じブロック図としている。２０１は内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するＣＰＵである。２０２はＢＩＯＳなどの基本ソフトウェアを格納してあるＲＯＭである。２０３はＣＰＵ２０１のワーク領域として利用され、また本発明を実現するためのプログラムをロードするための一時記憶として利用されるＲＡＭである。２０４は前記プログラムをファイルとして格納してあるＨＤＤ（ハードディスクドライブ）である。２０５は前記プログラムの中で操作画面を持つものを操作するための入力装置である。２０６は前記操作の確認のためのモニタである。２０７はネットワークに接続するためのＬＡＮ  Ｉ／Ｆである。
【００２２】
図３は本発明の実施の一形態に係るシステム構成図である。なお本発明に直接関連のない処理部については詳説しない。
【００２３】
ユーザインタフェース部３０１と検索キーワード送信部３０２はクライアントＰＣ１０１に存在する。ユーザインタフェース部３０１はユーザによって検索キーワードが指定され、検索実行命令を受け付ける。またユーザインタフェース部３０１は検索実行結果を表示する。検索キーワード送信部３０２はユーザに指定されたキーワードを文書管理サーバ１０２へ送信する。
【００２４】
検索キーワード生成部３０３、検索実行部３０４、検索結果送信部３０５、文書登録部３０６、インデキシング部３０７は文書管理サーバ１０２に存在する。検索キーワード生成部３０３は検索キーワード送信部３０２から渡された１つ以上の検索キーワード３１０を、必要に応じて並び替えて１つ以上の検索キーワード３１２を生成する。並び替えのパターンについては後で詳説する。検索実行部３０４は検索キーワード３１２で検索を実行する。検索結果送信部３０５は実行して得た検索結果３１１をユーザインタフェース部３０１に送信する。
【００２５】
また文書登録部３０６はクライアントＰＣ１０１やその他デバイスからインポートされた文書をデータベース１０３に登録する。インデキシング部３０７は文書登録部３０６で登録された文書の階層構造情報（フルパス）をインデキシングし、データベース１０３にインデックスを保存する。
【００２６】
図４は、図３で詳説した各処理部のうち、ユーザが検索を実行する際のフローチャートである。システムはユーザインタフェース部３０１上で、ユーザによって検索キーワードが１つ以上指定される（それを検索キーワード３１０とする）（ステップ４０１）。ユーザによって検索が実行されると、検索キーワード送信部３０２は検索キーワード３１０を文書管理サーバ１０２へ送る（ステップ３１１）。検索キーワード生成部３０３は検索キーワード３１０から検索キーワード３１２を生成する（ステップ４０３、４０４）。検索キーワード３１０を左から順に階層構造の上部とみなして連結する。検索実行部３０４は生成された検索キーワード３１２を用いて、すべてのフォルダパスに対して検索を実行する（ステップ４０６、４０７、４１０）。また検索実行部３０４は検索がＨｉｔした場合（ステップ４０８）、Ｈｉｔリストにそれを登録する（ステップ４０９）。検索結果送信部３０５はＨｉｔリストを検索結果３１１とし、ユーザインタフェース部３０１へ送る（ステップ４１１）。ユーザインタフェース部３０１は与えられた検索結果３１１を表示する（ステップ４１２）。
【００２７】
図４の例ではユーザに指定された検索キーワード３１０の並び順とフォルダの階層構造が一致していなければヒットしない。よってユーザが検索対象のフォルダ構造をある程度予想できる場合は、検索対象を絞ることができるためより的確に所望の文書を得ることができる。
【００２８】
図５は図４のフローチャートとは一部の処理が異なる。図４ではユーザに指定された検索キーワード３１０の順番とフォルダの階層構造が一致していなければヒットしないが図５のフローチャートではそれらが一致しなくてもヒットする。図４との違いはステップ５０３、５０７、５０８の検索キーワード生成部３０３の処理とステップ５０９、５１５の検索実行部３０４の処理のみであるため、その部分のみ説明する。
【００２９】
検索キーワード生成部３０３は検索キーワード送信部３０２から受け取った検索キーワード３１０を、すべてのパターンで並び替えて検索キーワード３１２を生成する（ステップ５０３、５０７、５０８）。例えば検索キーワード３１０として単語が４つ指定された場合、２４通りとなる。
【００３０】
また検索実行部３０４はステップで生成した検索キーワード３１２を使って検索を実行する。
【００３１】
図５の例ではユーザに指定された検索キーワード３１０の並び順に関わらず、検索キーワード３１０を含むすべてのフォルダパスがヒットする。よって図４とは逆にユーザが検索対象のフォルダ構造をほとんど知らない場合は、網羅的に検索するため、キーワードの並び順を変えては検索しなおすといったことをする必要がなくなる。
【００３２】
図６は、図４および図５のフローチャートとは一部の処理が異なる。図６はユーザが指定した検索キーワードをどのように並び替えて階層構造を検索するかをユーザが指定するときのフローチャートである。図５との違いはステップ６０７の検索キーワード生成部３０３の処理のみであるため、その部分のみ説明する。
【００３３】
検索キーワード生成部３０３は検索キーワード送信部３０２から受け取った検索キーワード３１０を、検索キーワード３１０に含まれる予約語に従って並び替える（ステップ６０７）。予約語は検索キーワード３１０の並び替えを制御するものであり、予めシステムに登録しておく。予約語としては例えば「＝」で結ばれたキーワード同士のみ並び替えるといったものが考えられる。
【００３４】
図６の例ではすなわちユーザが予約語を指定する手間は必要となるが、並び替えを制御することによって、図４の例と比較して検索がまったくヒットしない可能性を減らすことができる。また図５のように必要ない文書までヒットする可能性もまた減らすことができる。
【００３５】
なお、上記で説明した動作フローは一例であり、上記の処理の流れに限定されるものではない。
【００３６】
図７は、ユーザが指定した検索キーワード３１０から、検索に用いるキーワード３１２を生成する際、図４〜図６のそれぞれの処理を行った場合を例示した図である。
【００３７】
一実施例として、システムはユーザによって指定された検索キーワード３１０をワイルドカードで連結しフォルダパスのインデックスに対し検索を実行する。図７ではユーザによって「ａ」「ｂ」「ｃ」という３つのキーワードが与えられたとする。
【００３８】
（１）は図４のフローチャートの処理を行った場合であり、検索キーワード３１０は左から順に連結される。
【００３９】
（２）は図５のフローチャートの処理を行った場合であり、検索キーワード３１０は階乗通り並び替えて連結され、６パターンすべてで検索される。
【００４０】
（３）は図６のフローチャートの処理を行った場合であり、検索キーワード３１０は「＝」で結ばれている「ａ」と「ｂ」だけ並び替えて連結され、２パターンで検索される。
【００４１】
なお、図７は一例であり検索実行手段、及び予約語の制御はこれに限定されるものではない。
【００４２】
図４〜図６の動作の切り替えはシステムでハードコーディングしても良いが、ＧＵＩ上でユーザが切り替えられるようにしても良い。
【００４３】
図８に切り替えインターフェースの例を示す。８０１はユーザが検索を実行するユーザインタフェースであり内部にはユーザインタフェース部３０１が含まれる。８０１は例えばスタンドアロンアプリケーションでも良いしＷｅｂブラウザ上に実現しても良く実現手段には依存しない。８０２はユーザがキーワードを入力するテキストボックスである。８０３は検索実行ボタンである。８０４は上述したようにユーザが検索時にキーワードの並び順を考慮するかどうかを指定するラジオボタンである。指定された方法でシステムは検索を実行する。
【００４４】
図８の例は一つの例であり無論これに縛られるものではない。また図８の例では図６の動作へ切り替えるためのＵＩがないが、もちろん図６の動作への切り替えボタンを追加してもよい。
【図面の簡単な説明】
【００４５】
【図１】本発明の実施例における文書管理システムの全体構成を示すブロック図である。
【図２】本システムの一連のＰＣ、サーバのハードウェア構成を示すブロック図である。
【図３】本発明の実施例における文書管理システムのシステム構成図である。
【図４】本発明の実施例における検索実行時のフローチャートである。
【図５】本発明の実施例における検索実行時のフローチャートである。
【図６】本発明の実施例における検索実行時のフローチャートである。
【図７】検索キーワード生成部３０３が生成する検索キーワード３１２の例である。
【図８】本発明の実施例における検索画面である。
【符号の説明】
【００４６】
１０１  クライアントＰＣ
１０２  文書管理サーバ
１０３  データベース
３０１  ユーザインタフェース部
３０２  検索キーワード送信部
３０３  検索キーワード生成部
３０４  検索実行部
３０５  検索結果送信部
３０６  文書登録部
３０７  インデキシング部
３１０  ユーザが指定する検索キーワード
３１１  検索結果
３１２  システムが加工した検索キーワード
【図１】
2009134582.tif 000003
【図２】
2009134582.tif 000004
【図３】
2009134582.tif 000005
【図４】
2009134582.tif 000006
【図５】
2009134582.tif 000007
【図６】
2009134582.tif 000008
【図７】
2009134582.tif 000009
【図８】
2009134582.tif 000010