JP5252902B2 - 業務文書処理システム - Google Patents

Description

本発明は、文書構造を利用した業務文書の検索技術に関する。

組織内に蓄積された膨大な量の業務文書に対して、検索により有効活用を図り、組織内の知識の共有を行おうとする動きがある。このような需要に対して、ファスト サーチ＆トランスファ株式会社やグーグル株式会社などが高速な文書検索技術を提供しており、エンタープライズサーチと呼ばれる、企業内のサイトやデータを複数のサイト間で横断的・総合的に検索するシステムの市場が急速に形成されつつある。これらの検索において対象となるのは、文字列（plain text）データである。単語レベルやn-gramであらかじめインデックスを構築しておくことにより、高速な検索を可能としている。

一方、組織内で作成される文書はplain textであるとは限らず、マイクロソフト株式会社のMicrosoft Office Word・Microsoft Office Excelや、アドビシステムズ株式会社のAdobe PDFなどのフォーマットの文書も多く利用されている。これらのフォーマットの文書を検索対象とする場合は、ファイル内に含まれる文字列情報を抽出しておいて検索対象とする方法が一般的である。また、特許文献１に示すような、表を検索対象とする検索手法についても提案されている。
特開２００７−１７９２０３号公報

ところで、組織内で作成される文書には、図１〜図３に例示するような表が含まれる文書、図４に例示するような、右寄せ・左寄せ・センタリングなど書式情報が指定された文書や、図５に例示するような、Microsoft Office Excel等の表計算ソフトで作成することで整形を行った文書などが多く含まれる。

従来のエンタープライズサーチでは、こういったファイルを対象として検索を行う際には、文書内に含まれる文字列を検索対象としていた。このため、図１〜図３および図５に例示した文書においては、表の各セルの位置関係が無視されて検索される。また、図４に例示した文書においては、書式情報が無視されて検索される。この結果、例えば、図１に例示した文書において、検索対象文字列は「登録日 ２００７年６月１日 分類名 パソコン 品番 Ａ００１ Ａ００２ Ａ００３ 品名 ＨｙｐｅｒＰＣ ００１ …」などとなり、この文字列に対して検索用インデックスが作成される。したがって、「『品番』のセルの下に『品名』のセルがある」というセル同士の位置関係を指定した検索を行うことができない。また、例えば、図４に例示した文書において、検索対象文字列は「配布先：各課 ２００７年８月３１日 返信不要 庶務課通達 第３１号 ２００７年上期分 〆日の連絡 …」などとなり、「右寄せで『庶務課通達』と『第３１号』とある」という書式情報を指定した検索を行うことができない。

また、図１〜図３および図５に示した例はいずれも、フォーマットに記入する種類の文書である。これらの文書は、未記入の状態では文書内に含まれる文字列は項目名だけであるが、「仕様一覧」、「登録日」、「分類名」など、きわめて一般的な語しか含まれない。このため、このような文書に対し、同じフォーマットの文書をまとめて探すことを目的として項目名を検索語として（セルの位置関係を指定することなしに）検索を行っても、きわめて一般的な語を検索語として用いることになってしまい、目的としない文書を大量に誤検出してしまう。図４に示した、書式が指定された文書についても、同様の問題が生じる。業務文書では定型表現が多いため（「御中」・「依頼」・「連絡」・「配布先」・「期限」・「緊急」・「提出」・「につきまして」・「よろしくお願いいたします」・「以上」など）、文書内の表現としてのバラエティが少ない。このため、検索エンジンの精度が下がってしまい、目的としない文書を大量に誤検出してしまう。

さらに、特許文献１に開示の方法は、罫線情報を基にセルを切り出し、検索クエリと比較するものなので、検索処理を高速に実行することができない。

本発明はこのような状況に鑑みてなされたものであり、表の各セルの位置関係や書式情報を指定した検索を高速に行うための文書処理を提供するものである。

上記課題を解決するために、文書中の表を文字列にエンコードした結果を用いて検索用インデックスを予め構築しておくことを特徴とする。これにより、エンタープライズサーチ分野で利用されている高速な文字列検索手法を活用して、表の各セルの位置関係を指定した検索を行うことができる。

本発明は、表内の隣接するセルの組に対し、両セル内の文字列を、隣接関係を示す記号でつないだ文字列にエンコードすることを特徴とする。例えば、図１に例示した文書に含まれる表の場合、「『登録日』のセルの右に『２００７年６月１日』のセルがある」という隣接関係を「登録日→２００７年６月１日」という文字列にエンコードし、「『登録日』のセルの下に『分類名』のセルがある」という隣接関係を「登録日↓分類名」という文字列にエンコードし、「『登録日』のセルの右下に『パソコン』のセルがある」という隣接関係を「登録日＼パソコン」という文字列にエンコードし、「『分類名』のセルの下に『Ａ００２』と『Ａ００３』のセルがある」という隣接関係を「分類名↓Ａ００２」と「分類名↓Ａ００３」という文字列にエンコードする。これらのエンコード結果を基にインデックスを作成することにより、セル同士の位置関係を指定した検索が可能となる。

本発明は、文書中の書式を指定された文字列に対して、書式を埋め込んだ文字列にエンコードした結果を用いて検索用インデックスを予め構築しておく。これにより、エンタープライズサーチ分野で利用されている高速な文字列検索手法を活用して、書式情報を指定した検索を行う。

本発明は、書式を指定された文字列に対し、元々の文字列に加えて文字列内の各文字を、書式を示す記号でつないだ文字列にエンコードする。例えば、図４に例示した文書に含まれる文字列の場合、「２００７年８月３１日」に加えて「┤２┤０┤０┤７┤年┤８┤月┤３┤１┤日┤」とエンコードする。これにより、元々の文字列「２００７年８月３１日」に対して構築したインデックスを用いれば書式を指定しない検索を行うことができ、文字列内の各文字を、書式を示す記号でつないだ文字列「┤２┤０┤０┤７┤年┤８┤月┤３┤１┤日┤」に対して構築したインデックスを用いることにより、書式を指定した検索を行う。

即ち、本発明による業務文書処理装置は、業務文書の検索を実行する業務文書処理システムであって、複数の業務文書を蓄積するデータベースであって、業務文書の構造を符号化して生成された検索用インデックスを、複数の業務文書のそれぞれに対応して記憶する業務文書データベースと、利用者が入力し、業務文書の構造を示す検索クエリを受信する検索クエリ受信手段と、入力された検索クエリを符号化する検索クエリ符号化手段と、符号化された検索クエリを、業務文書データデースの検索用インデックスと比較して、検索クエリの条件に合致する業務文書を検索する検索実行手段と、検索結果を利用者に提示する検索結果提示手段と、を備える。ここで、業務文書の構造は、業務文書が表を含む場合には表を構成するセルの位置関係であり、業務文書が所定の書式で構成される場合には書式情報である。なお、業務文書が表を含む場合、検索クエリは、第１の検索語を含む第１のセルと第２の検索語を含む第２のセルとの位置関係を示すものである。また、業務文書が所定の書式で構成される場合、検索クエリは、検索語の書式情報を指定するものとなっている。

業務文書が表を含む場合、検索クエリ符号化手段は、第１のセルと第２のセルとの隣接関係を示す記号を用いて第１及び第２の検索語を結合することにより、検索クエリを符号化する。また、業務文書が所定の書式で構成される場合、検索クエリ符号化手段は、検索語を構成する文字列の各文字を、所定の書式を示す記号を用いて結合することにより検索クエリを符号化する。

本発明による業務文書処理システムは、業務文書をデータベースに登録する業務文書処理システムであって、登録すべき前記業務文書の構造を分析し、分析結果に基づいて、業務文書の構造を符号化して、符号化された業務文書の構造をインデックス情報とするインデックス情報生成手段と、業務文書とインデックス情報とを対応付けて、データベースに登録する登録手段と、を備えることを特徴とする。

業務文書が表を含む場合、インデックス情報生成手段は、第１の文言を含む第１のセルと第２の文言を含む第２のセルとの位置関係を示す記号を用いて、第１の文言と第２の文言とを結合して得られた情報をインデックス情報とする。この処理は、業務文書に含まれる表の全てのセルについて実行される。

業務文書が所定の書式で構成される場合、インデックス情報生成手段は、業務文書に含まれる符号化前文字列（元の文字列）の各文字を、所定の書式を示す記号を用いて結合して得られた符号化文字列をインデックス情報とする。このとき、符号化文字列と符号化前文字列を含む文字列をインデックス情報とするようにしてもよい。この処理は、業務文書に含まれる全ての文字列について実行される。

さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。

本発明によれば、表の各セルの位置関係や書式情報を指定した検索を高速に行うことができるようになる。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

＜業務文書処理装置の構成＞
図８は、本発明の実施形態による業務文書処理装置の概略構成を示す機能ブロック図である。業務文書処理装置は、管理業務における文書およびそれに対して構築されたインデックスを保存した文書ＤＢ８００と、データを表示するための表示装置８０１と、表示されたデータに対してメニューを選択するなどの操作を行うためのキーボード８０２と、マウスなどのポインティングデバイス８０３と、必要な演算処理及び制御処理等を行う中央処理装置８０４と、中央処理装置８０４での処理に必要なプログラムを格納するプログラムメモリ８０５と、中央処理装置８０４での処理に必要なデータを格納するデータメモリ８０６と、を備えている。

中央処理装置８０４は、文書中の表を文字列にエンコードする表エンコード処理部８０７と、文書中の書式を指定された文字列を、書式を埋め込んだ文字列にエンコードする書式情報エンコード処理部８０８と、検索用インデックスを構築するインデックス構築処理部８０９と、構築したインデックスを用いて検索語の検索を行う検索処理部８１０と、を含んでいる。

データメモリ８０６は、文書中に含まれる表の各セルのデータを保持するセルデータ８１１および、表内のセルの隣接関係や書式情報を表現するための記号を保持するエンコード記号データ８１２を含んでいる。セルデータ８１１は、文書ＤＢ８００に格納されたデータに基づいて生成されたデータである。

＜セルデータとエンコード記号データ＞
図９は、データメモリ８０６に含まれるセルデータ８１１およびエンコード記号データ８１２のデータ構造を示す図である。図９Ａはセルデータ８１１のデータ構造を示し、図９Ｂはエンコード記号データのデータ構造を示している。

セルデータは、文字列９００、最小行番号９０１、最大行番号９０２、最小列番号９０３、最大列番号９０４を含み、文字列９００を含むセルの位置関係を示している。ここで、文字列９００は、そのセル内に書かれている文字列である。最小行番号９０１および最大行番号９０２は、そのセルが表の何行目にあるかを示す。例えば、図１に示す表の場合、「品番」のセルは３行目にある（１行目は「登録日」と「２００７年６月１日」のセル、２行目は「分類名」と「パソコン」のセル）。従って、最小行番号９０１および最大行番号９０２は両方とも“３”になる。「オプション」のセルのように複数行にまたがるセルにおいてはこれらの値が異なるものとなる。最小列番号９０３および最大列番号９０４は、同様に、そのセルが表の何列目にあるかを示す。例えば図１に示す表の場合、「品番」のセルは１〜２列目にまたがる（１列目には「オプション」のセルが、２列目には「マウス」などのセルがある）。従って、最小列番号９０３は“１”に、最大列番号９０４は“２”になる。

エンコード記号データは、エンコード記号データ８１２のデータ構造を示す。隣接関係９０５および書式情報９０６を含んでいる。隣接関係９０５は、表内のセルの隣接関係を表現するための記号を保持する。この例では、右に位置するセルを『→』で、下に位置するセルを『↓』で、右下に位置するセルを『＼』で表現する様子を示している。書式情報９０６は、書式情報を表現するための記号を保持する。この例では、右寄せが指定された文字列は『┤』で、左寄せが指定された文字列は『├』で表現する様子を示している。

＜検索処理及びインデックス構築処理＞
次に、図１０乃至１２を参照して、本実施形態の業務文書処理装置において実行される検索処理及びインデックス構築処理について説明する。図１０は、業務文書処理装置においける全体の処理を説明するためのフローチャートである。図１１は、表のエンコード処理（Ｓ１００１）の詳細を説明するためのフローチャートである。図１２は、書式のエンコード処理（Ｓ１００２）の詳細を説明するためのフローチャートである。

（１）図１０において、まず、中央処理装置８０４は、ユーザの指示を受付け、その指示に対応する処理が検索処理であるかインデックス構築であるかを判断する（ステップＳ１０００）。対象処理が検索対象の文書に対するインデックス構築である場合、まず、インデックス構築処理部は、業務文書のデータを分析し、表の有無及び書式（文書構造）を判断する。そして、表エンコード処理部８０７は、文書内に含まれる表のエンコードを行う（ステップＳ１００１）。また、書式情報エンコード処理部８０８は、書式を指定された文字列のエンコードを行う（ステップＳ１００２）。表の各セルの中に、所定の書式を含む場合には、セル内の文字列のエンコードを行うようにしても良い。その後、インデックス構築処理部８０９は、エンコードされた情報から業務文書のインデックス情報を構築する（ステップＳ１００３）。よって、文書ＤＢ８００には、業務文書とそれに対応するインデックス情報が組となって蓄積されることになる。なお、ステップＳ１００１およびステップＳ１００２における処理は、図１１および図１２において後に詳述する。また、ステップＳ１００３において行う処理は、既存のエンタープライズサーチ分野における文字列検索技術を用いて行うことができる。

ステップＳ１０００において、ユーザの指示した処理が検索処理である場合、中央処理装置８０４は、セルの隣接関係と書式のどちらが指定されたかを判断する（ステップＳ１００４）。セルの隣接関係が指定された場合、表エンコード処理部８０７は、検索クエリで指定されたセルの隣接関係のエンコードを行う（ステップＳ１００５）。一方、書式が指定された場合は、書式情報エンコード処理部８０８は、ユーザが検索クエリを用いて指定した書式のエンコードを行う（ステップＳ１００６）。

そして、検索処理部８１０は、検索クエリを実行し（ステップＳ１００７）、得られた検索結果を返す（ステップ１００７）。なお、ステップＳ１００５における処理では、例えば、図６のような検索クエリ設定画面で指定されたセルの隣接関係がエンコードされる。図６において、検索語２のように、他のセルとの隣接関係が指定された検索語について、表エンコード処理部８０７は、エンコート記号データにおける隣接関係９０５を参照し、両セル内の文字列を、隣接関係を示す記号でつないだ文字列にエンコードする。また、ステップＳ１００６における処理では、例えば、図７のような検索クエリ設定画面で指定された書式情報がエンコードされる。図７において、検索語１および検索語２のように書式を指定された検索語について、書式情報エンコード処理部８０８は、エンコード記号データにおける書式情報９０６を参照し、文字列内の各文字を、書式を示す記号でつないだ文字列にエンコードする。また、ステップＳ１００７における処理は、既存のエンタープライズサーチ分野における文字列検索技術を用いて行うことができる。さらに、ステップＳ１００８における処理は、その結果を表示装置８０１に表示するものである。表示結果は、例えば、図１３に示すようになるが、その詳細については後述する。また、検索クエリで指定された隣接関係を含む業務文書の検索結果を表示する場合、セル同士の位置関係を示す複数の画像（例えば、サムネイル画像）を画面に表示するようにしても良い（図示せず）。これにより、利用者は、業務文書におけるセルの配置が所望のものを選択することができるようになる。

（２）続いて、図１０における、文書内に含まれる表のエンコードを行う処理Ｓ１００１の詳細について、図１１を参照しながら説明する。図１１における各工程の動作主体は、特に断らない限り、表エンコード処理部８０７である。

まず、隣接関係を調べる対象の一方のセル番号の初期値が設定される（Ｓ１１０１）。ｉ番目（最初はｉ＝１）のセルが存在するか否かが判断され（Ｓ１１０２）、存在しない場合には、処理は終了する。一方、ｉ番目のセルが存在する場合には、処理はステップＳ１１０３に移行し、隣接関係を調べる対象のもう一方のセル番号が指定される。

次に、ｊ番目のセルが存在するか否かが判断される（Ｓ１１０４）。ｊ番目のセルが存在しない場合には、ｉの数値が１つだけインクリメントされ（Ｓ１１０５）、処理はステップＳ１１０２に戻る。

一方、ｊ番目のセルが存在すると判断されると、処理はステップＳ１１０６に移行する。ステップＳ１１０６では、ｉ番目とｊ番目の２つのセルが互いに隣接しているかどうかが調べられる。例えば、１つ目のセル（ｉ番目のセル）の最大行番号９０２が２つ目のセル（ｊ番目のセル）の最小行番号９０１より１つ小さく、最小列番号９０３と最大列番号９０４で指定される範囲に共有部分がある場合、２つのセルは縦方向に隣接していることになる。また、１つ目のセルの最大列番号９０４が２つ目のセルの最小列番号９０３より１つ小さく、最小行番号９０１と最大行番号９０２で指定される範囲に共有部分がある場合、２つのセルは横方向に隣接していることになる。さらに、１つ目のセルの最大行番号９０２が２つ目のセルの最小行番号９０１より１つ小さく、１つ目のセルの最大列番号９０４（最小列番号９０３）が２つ目のセルの最小列番号９０３（最大列番号９０４）より１つ小さい（１つ大きい）場合、２つのセルは斜めに隣接していることになる。これらの確認の結果、２つのセルが隣接していた場合は、以下の処理を行う。

まず、隣接関係９０５が参照され、隣接関係を表す記号Ｃ_隣接関係が調べられる（ステップＳ１１０７）。記号Ｃ_隣接関係としては、「→」や「↓」や「＼」が用いられることになる。

次に、２つのセル内の文字列は、ステップＳ１１０７で調べた記号Ｃ_隣接関係で結合されて、エンコード結果文字列に加えられる（ステップＳ１１０８）。なお、ステップＳ１１０６での確認の結果、２つのセルが隣接していない場合は、ｊの数値が１つインクリメントされ（Ｓ１１０９）、エンコード処理は実行されない。エンコード処理が実行されない理由については図１２の説明の後に詳述する。

（３）さらに、図１０における、書式を指定された文字列のエンコードを行う処理Ｓ１００２の詳細について、図１２を参照しながら説明する。図１２における各工程の動作主体は、特に断らない限り、書式情報エンコード処理部８０８である。

まず、エンコード対象の文字列番号の初期値が設定される（Ｓ１２０１）。そして、ｉ番目（最初はｉ＝１）の文字列Ｓが存在するか否かが判断される（Ｓ１２０２）。ｉ番目の文字列が存在しない場合には、処理は終了する。ｉ番目の文字列が存在する場合には処理はステップＳ１２０３に移行する。

次に、エンコード記号データにおける書式情報９０６が参照され、書式情報を表す記号Ｃ_書式情報が調べられる（ステップＳ１２０３）。Ｃ_書式情報としては、例えば、「┤」や「├」が用いられることになる。続いて、書式が指定された対象文字列Ｓ内の各文字は、Ｃ_書式情報を用いて結合される（ステップ１２０４）。その後、元の文字列ＳとステップＳ１２０４で結合して生成された文字列が結合され、エンコード結果文字列として出力される（ステップＳ１２０５）。そして、次の文字列Ｓに関するエンコード処理に移行するため、ｉの数値が１つインクリメントされ（Ｓ１２０６）、処理はステップＳ１２０２に移行する。

（４）図１３は、図１０のステップＳ１００８における、検索結果を画面表示する例を示す図である。ここでは、図６に示したようなセルの隣接関係を指定された検索クエリの結果、すなわち、「『登録日』のセルの下に『分類名』のセルがある」という条件を満たす文書を検索した結果を表示している。図１３に示されるように、検索結果として得られた文書それぞれは、文書の一部分がプレビュー画面１３００として表示される。ここで、「分類名」のセル１３０１、及び「登録日」のセル１０３２が表示されているように、プレビュー画面１３００は、クエリで指定された部分を含む部分が切り出されて表示されている。このような表示を行うことにより、ユーザは指定したセルの隣接関係が含まれる文書が検索結果として得られていることを一瞥して確認できると共に、所望の文書を容易に探し出すことができる。

（５）前述のように、表のエンコードを行う際、ステップＳ１１０６でＮＯだった場合（２つのセルが隣接していない場合）はエンコード処理が実行されない。また、記号Ｃ_隣接関係でつないだ文字列と元の文字列をつなげることはしない。これに対し、書式を指定された文字列のエンコードを行う際は、ステップＳ１２０５で説明した通り、記号Ｃ_書式情報でつないだ文字列と元の文字列Ｓをつないでいる。この違いは次の２つの理由による。

１つ目の理由は、表においては全てのセルは何らかの他のセルと隣接関係にあるためである。したがって、各セルの組に対して処理を行えば、少なくとも一度はステップ１１０６でＹＥＳ（２つのセルが隣接している）と判断される。このことから、エンコード結果文字列は、ステップＳ１１０６でＹＥＳと判断された場合に得られる文字列から作成することができる。

２つ目の理由は、表のエンコードを行う際はセル内の文字列がエンコード結果文字列に現れる（例えば、「『登録日』のセルの下に『分類名』のセルがある」という隣接関係を表した「登録日↓分類名」というエンコード結果文字列には、「登録日」という文字列が含まれる）ためである。したがって、元の文字列「登録日」をことさらつなげる処理を行わなくても、エンコード結果文字列から構築したインデックスを用いて「登録日」というクエリで検索を行える。これに対し、書式を指定された文字列のエンコードでは、ステップＳ１２０４では、一文字ずつを記号Ｃ_書式情報でつなぐ処理を行う。このため元の文字列が一文字ずつに分断されてしまう。元の文字列Ｓとつなげたものを用いることにより、元の文字列を書式の指定なしでクエリとして検索を行った場合にも、書式を指定してクエリとして検索を行った場合にも、対応できる（例えば、図４に例示した文書に含まれる右寄せの「庶務課」に対して、「┤庶┤務┤課┤庶務課」をエンコード結果文字列としてインデックスを構築すれば、書式の指定がない「庶務課」というクエリにも、右寄せという書式を指定した「┤庶┤務┤課┤」というクエリにも対応できる）。

＜その他＞
なお、本実施形態で述べた表エンコード処理を行うことにより、例えば、図１に例示した表を「分類名パソコン」という検索語で検索することはできなくなる。しかし、このことは実用上問題ない。なぜならば、複数のセルにまたがって１つの単語を記述することは実際には考えにくく、「分類名」と「パソコン」という２つの検索語でアンド検索を行えば十分であるためである。

また、本実施形態で述べた書式を指定された文字列のエンコードを行うことにより、例えば、図４に例示した文書を書式なしの「８月３１日返信不要」という検索語で検索することはできなくなる。しかし、上記と同様に、このことは実用上問題ない。なぜならば、異なる書式にまたがって一つの単語を記述することは実際には考えにくく、「８月３１日」と「返信不要」という二つの検索語でアンド検索を行えば十分であるためである。

本実施形態で述べた書式を指定された文字列に対し一文字ずつ記号でつないでエンコードする方法は、文字列全体をまとめて記号ではさむ方法よりも優れている。なぜならば、例えばＨＴＭＬタグのように、図４に例示した文書を「┤庶務課通達┤」とエンコードした場合、各部分文字列はそのまま残される。このため、「右寄せで『庶務』となっている」などと部分文字列に対して書式情報を指定した検索を行うことができない。これに対して本発明で述べた方法では、各文字を記号でつなぐので、検索クエリを「┤庶┤務┤」とエンコードすれば良く、部分文字列に対しても書式情報を指定した検索が可能となるためである。

さらに、本実施形態においては、表内のセルの隣接関係や書式情報を表現するために「→」「↓」「＼」「┤」などの記号を利用したが、利用できる文字はこれに限らない。検索語として入力される危険性のない、エスケープシーケンスを利用することも可能である。

また、本実施形態では、ワイルドカードを含む検索を行うこともできる。例えば、図１に示す表に対して「『登録日』のセルの右に何らかのセルがある」文書を検索したい場合、検索クエリを「登録日→」とエンコードすれば良い。さらに、図３に示す表に対して「一番下の行の『電話番号』のセルの右は空欄であること」についても同様に、空欄であることを示す記号を９０５（図９）に定義して（ここでは例として「△」とおく）、「電話番号→△」として検索用インデックスの構築および検索クエリのエンコードを行えばよい。さらに、図１に示す表に対して「『登録日』のセルの左には何もないこと」についても同様に、左に何もないことを示す記号を図９の９０５に定義して（ここでは「⇒」とおく）「⇒登録日」として検索用インデックスの構築および検索クエリのエンコードを行えばよい。「→」ではない記号を定義することにより、セルの有無を明示的に指定できる。

また、本実施形態において文書中に含まれる表の検索を行う際には、図６に示したようにセル間の隣接関係をユーザに指定させる方法のほか、表そのもの（または表の一部分）を検索クエリとしてユーザに指定させることも可能である。その場合は、ユーザが指定した表（または表の一部分）を、表エンコード処理部８０７を用いてエンコードし、クエリとして用いればよい。

さらに、本明細書においては、書式指定の例として右寄せと左寄せについて述べた。センタリング・フォント・フォントサイズについても同様に行うことができる。さらに、表のセルに書かれている文字列が、セルの中で（右寄せ・上寄せ・フォント・フォントサイズなど）書式指定されている場合についても同様に行うことができる。

＜まとめ＞
以上のように、本発明では、複数の業務文書を蓄積する業務文書データベースは、業務文書の構造（表の有無、所定の書式で構成されていること）を符号化して生成された検索用インデックスを、複数の業務文書のそれぞれに対応して記憶している。検索の際には、利用者は、業務文書の構造を示す検索クエリを指定し、そのクエリが符号化される。そして、業務文書データデースの検索用インデックスと比較され、検索クエリの条件に合致する業務文書が検索される。これにより、特殊な文書構造をなす業務文書であっても適切にかつ迅速に検索することができる。従って、組織内の膨大な業務文書を有効に活用することができるようになる。

より具体的には、本発明で述べた手法を用いれば、エンタープライズサーチ分野で利用されている高速な文字列検索手法を活用して、図６および図７に示すように、表の各セルの位置関係や書式情報を指定した検索を非常に高速に行うことができる。検索する際には、利用者は、検索クエリとしてセルの隣接関係を指定した検索語を指定する。そして、検索語を、隣接関係を示す記号でつないだ文字列にエンコードして用いることにより、隣接関係と検索語の包含の両方の条件を満たす文書を検索することができる。このように、検索手順も非常に簡単なので、利用者にとって非常に使い勝手の良い検索システムを構築することができる。

また、本発明で述べた手法は、図１〜図３および図５に示した例において、表のセルに書き込んだ文字列が長かったためにセルの行数が増えてしまった場合にも影響を受けない。また、例示したようなフォーマットに記入する種類の文書に対して、同じフォーマットの文書をまとめて探すことも容易かつ迅速となる。さらに、フォーマットを更新した際に、古いフォーマットの文書を網羅的に探すような検索も可能である。

組織全体では文書の検索を行う人は組織の構成員全体におよぶので非常に多く、本発明により各人において効率化を達成できるので、組織全体での効率化の効果はさらに大きいものとなる。

なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施の形態の機能を実現するソフトウェアのプログラムコードをネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

組織内で用いられる業務文書のうち、表を含む文書例（１）を示す図である。 組織内で用いられる業務文書のうち、表を含む文書例（２）を示す図である。 組織内で用いられる業務文書のうち、表を含む文書例（３）を示す図である。 組織内で用いられる業務文書のうち、書式が指定された文書例を示す図である。 組織内で用いられる業務文書のうち、表計算ソフトで当該文書を作成することで整形を行っている文書例を示す図である。 セルの隣接関係を指定して検索クエリを作成する画面の例である。 書式情報を指定して検索クエリを作成する画面の例である。 本発明の実施形態による業務文書処理装置の概略構成を示す機能ブロック図である。 セルデータ及びエンコード記号データのデータ構造例を示す図である。 業務文書処理装置による検索及びインデックス構築の処理全体を説明するためのフローチャートである。 文書内に含まれる表のエンコードを行う処理の詳細を説明するためのフローチャートである。 書式を指定された文字列のエンコードを行う処理の詳細を説明するためのフローチャートである。 検索結果として得られた文書を表示する画面の例を示す図である。

符号の説明

８００・・・文書ＤＢ
８０１・・・表示装置
８０２・・・キーボード
８０３・・・ポインティングデバイス
８０４・・・中央処理装置
８０５・・・プログラムメモリ
８０６・・・データメモリ

Claims (7)

1. 業務文書の検索を実行する業務文書処理システムであって、
   複数の業務文書を蓄積するデータベースであって、業務文書の構造を符号化して生成された検索用インデックスを、前記複数の業務文書のそれぞれに対応して記憶する業務文書データベースと、
   利用者が入力し、業務文書の構造を示す検索クエリを受信する検索クエリ受信手段と、
   前記入力された検索クエリを符号化する検索クエリ符号化手段と、
   前記符号化された検索クエリを、前記業務文書データデースの前記検索用インデックスと比較して、前記検索クエリの条件に合致する業務文書を検索する検索実行手段と、
   検索結果を前記利用者に提示する検索結果提示手段と、を備え、
   前記業務文書の構造は、前記業務文書が表を含む場合には前記表を構成するセルの位置関係であり、前記業務文書が所定の書式で構成される場合には書式情報であり、
   前記業務文書データベースは、前記検索用インデックスとして、前記表に関して、表を構成する各セルの隣接関係の種類を示す記号で各隣接するセル内の文字列をつなぐことによって生成された第１種検索用インデックスと、前記書式情報に関して、書式の種類を示す記号で文字列を構成する各文字をつなぐことにより生成された第２種検索用インデックスと、を格納し、
   前記検索クエリ符号化手段は、前記入力された検索クエリがセルの隣接関係による検索及び書式による検索のどちらを指定するものかを判定し、前記入力された検索クエリが前記セルの隣接関係による検索を指定する場合には、前記隣接関係の種類を示す記号によって検索対象の隣接セルに含まれる各文字列を符号化し、前記入力された検索クエリが前記書式による検索を指定する場合には、前記書式の種類を示す記号によって検索対象の文字列を符号化し、
   前記検索実行手段は、前記符号化された検索クエリを、前記第１種検索用インデックス或いは前記第２種検索用インデックスと比較して前記検索結果を取得することを特徴とする業務文書処理システム。
2. 前記第２種検索用インデックスは、前記業務文書における文字列の絶対的位置を示す記号を用いて当該文字列の各文字をつなぐことによって生成されたインデックスを含み、
   前記検索クエリ符号化手段は、前記入力された検索クエリが前記書式による検索を指定し、かつ、当該検索クエリに含まれる文字列の業務文書における絶対的位置を指定する場合には、業務文書における絶対的位置を示す記号で前記文字列を符号化することを特徴とする請求項１に記載の業務文書処理システム。
3. 前記検索結果提示手段は、表示装置の表示画面に、前記検索結果に対応する前記業務文書の一部分をプレビューとして表示することを特徴とする請求項１又は２に記載の業務文書処理システム。
4. 業務文書をデータベースに登録する業務文書処理システムであって、
   登録すべき前記業務文書の構造を分析し、当該分析結果に基づいて、前記業務文書の構造を符号化して、当該符号化された業務文書の構造をインデックス情報とするインデックス情報生成手段と、
   前記業務文書と前記インデックス情報とを対応付けて、前記データベースに登録する登録手段と、を備え、
   前記業務文書の構造は、前記業務文書が表を含む場合には前記表を構成するセルの位置関係であり、前記業務文書が所定の書式で構成される場合には書式情報であり、
   前記インデックス情報生成手段は、前記インデックス情報として、前記表に関して、表を構成する各セルの隣接関係の種類を示す記号で各隣接するセル内の文字列をつなぐことによって第１種検索用インデックスを生成し、前記書式情報に関して、書式の種類を示す記号で文字列を構成する各文字をつなぐことにより第２種検索用インデックスを生成し、
   前記登録手段は、前記業務文書と、前記第１種及び第２種検索用インデックスとを対応付けて前記データベースに登録することを特徴とする業務文書処理システム。
5. 前記インデックス情報生成手段は、前記業務文書における文字列の絶対的位置を示す記号を用いて当該文字列の各文字をつなぐことによって前記第２種検索用インデックスを生成することを特徴とする請求項４に記載の業務文書処理システム。
6. 前記インデックス情報生成手段は、前記業務文書に含まれる表の全てのセルについて前記第１種検索用インデックスを生成することを特徴とする請求項４に記載の業務文書処理システム。
7. 前記インデックス情報生成手段は、前記業務文書に含まれる全ての文字列について前記第２種検索用インデックスを生成することを特徴とする請求項４に記載の業務文書処理システム。

Images