JP3518933B2 - 構造化文書検索方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、文書データベースを、
ユーザの指定する検索文字列から、文書中のユーザ指定
の文書構造部分のみを対象として探索し、所望の文書を
検索する文書検索方法に係わり、特に大量な文書を登録
し、高速な検索を行う場合に好適な情報検索方法に関
し、大規模文書データベースに適用されるものである。

【０００２】

【従来の技術】先に、文書の登録の際にキーワード付け
を行う必要のないフルテキストサーチ方式を「特開平０
３−１７４６５２」で提案した。この方式は、文書を単
語単位に圧縮した凝縮本文と、文書中の使用文字を一文
字単位で登録した文字成分表を用いて、検索語に関連し
ない文書をふるい落とすことによってサーチ速度を等価
的に高め、フルテキストサーチを実用レベルで高速に行
うことを目的としたものである。また、この文字成分表
を改良し更に高速なフルテキストサーチを実現する連接
文字成分表方式を「特開平０５−１７４０６４」で提案
した。この公知例で用いている連接文字成分表は、テキ
ストの中に含まれる所定の長さの連接する文字列を重複
なく全て取り出し、これらを含む文書の識別子情報とし
て、文書を特定する番号に対応するビット位置を１とし
たビット列で記述するものである。しかし、全ての連接
文字について識別子情報をビット列で記述すると、文字
の組み合わせの個数分だけビット列が必要となり、連接
文字成分表が膨大な容量になる。そこで、本公知例で
は、ハッシュ関数を用いて１個のビット列に複数個の連
接文字を割り当てるようにして、容量を抑える工夫をし
ている。

【０００３】

【発明が解決しようとする課題】しかしながら、従来の
ハッシュ関数を用いて１個のビット列、すなわち該連接
文字の出現する文書番号を格納した文書識別子情報に複
数個の連接文字を割り当てた場合には、同じビット列に
まったく別の連接文字の文書識別子情報も重畳されるこ
とになる。従って、ある連接文字を指定して該当するビ
ット列から文書識別子情報を取り出した場合、その情報
からはまったく別の連接文字を含む文書が得られる可能
性がある。つまり、ハッシュ関数を用いた連接文字成分
表による検索結果には検索ノイズが含まれることにな
る。このことは、大量の文書を登録する大規模な文書検
索システムでは、検索文字列を含む可能性のない不要な
文書のふるい落とし、すなわち絞り込みが適切に行われ
ない可能性があることを意味し、その場合には検索性能
の低下につながる。

【０００４】ハッシュ関数を用いずに、全ての連接文字
についてそれぞれ１個のビット列を対応させることも考
えられるが、その場合にはビット列のデータ量が膨大な
ものとなり、実用的ではない。具体的に説明すると、日
本語で使用する文字コードは、現在約８，０００種類あ
るので、２文字の組み合わせとしての連接文字の種類
は、 ８，０００×８，０００＝６，４００万種類 となる。登録する文書数を１００万件とした場合、この
６，４００万種類のそれぞれの連接文字に１００万ｂｉ
ｔの文書識別子情報をビット列として対応させるので、 ６，４００万種類×１００万ｂｉｔ＝８ＴＢｙｔｅ もの容量が必要になる。この文字成分表の大きさに対
し、文書本体の大きさを２０ＫＢ／件としても、１００
万件で、 ２０ＫＢ×１００万件＝２０ＧＢｙｔｅ であり、圧倒的に文字成分表の容量のほうが大きくなっ
てしまう。この文字成分表の容量を削減するためには、
固定長のビット列で該当文字が出現する文書識別子情報
を格納するだけでなく、該当文書数が少ない場合には文
書番号を直接書き込むことも考えられる。これをＩＤリ
スト格納形式と呼ぶ。また、従来のビット列で文書識別
子情報を格納する形式をビットリスト格納形式と呼ぶ。
例えば、１００万件を格納するデータベースでビットリ
スト格納形式で各文字の出現する文書識別子情報を格納
するには、各文字あたり、たとえ一件しか出現する文書
がなくとも １００万ｂｉｔ＝１２５ＫＢ の容量が必ず必要となるが、文書番号で出現する文書識
別子情報を格納するＩＤリスト格納形式では、文書ＩＤ
を４Ｂ，格納文書ＩＤの数も４Ｂで格納するとして、 ４Ｂ＋４Ｂ＝８Ｂ の容量で済むことになる。

【０００５】一方、文書には、特許公報の例のように、
「発明の名称」、「発明者」、「出願人」、「請求の範
囲」、「発明が解決しようとする課題」のように、構造
を持ち、それぞれの構造内で特定の内容が収められる場
合が多い。このような構造化文書を対象に、探索対象の
文書構造を指定してフルテキストサーチを行うことを構
造指定検索と呼ぶ。この構造指定検索を実現するために
は、各構造毎に文字成分表を作成し、文字成分表サーチ
の段階で構造毎にそれぞれ別々の文字成分表を用いて検
索を行う必要がある。しかし、文書の各構造毎に文字成
分表を作成すると、各構造単位に同じ様な文字成分によ
る文書識別子情報を持つために容量が大きくなるという
問題が生じる。例えば、「発明の名称」、「発明者」、
「出願人」、「請求の範囲」等の文書構造が１０種類あ
る場合、文書の各構造についてそれぞれ文字成分表を作
成すると１０倍の文字成分表の容量が必要となる。この
ことは、上述の文書識別子情報をＩＤリスト形式で格納
して文字成分表の容量を削減する効果を相殺することに
なってしまう。また、複数の文書構造を対象に検索する
場合には、その回数分だけ文字成分表の検索を繰り返す
必要があり、ファイル入出力の回数が増え、効率的では
ないという問題もある。例えば、「“発明の名称”、
“請求の範囲”または、“効果”の文書構造中に“極限
作業”という文字列のある文書を探せ」という条件の場
合、３種類の構造のそれぞれに対応する文字成分表を検
索した後、それらのＯＲ演算を行う必要がある。本発明
の目的は、構造を持つ文書を格納する大規模な情報検索
システムにおいて、検索ノイズの少ない文字成分表を実
用的な容量で提供し、かつ効率的な文書構造指定検索を
実現することにある。

【０００６】

【課題を解決するための手段】上記目的を達成するた
め、本発明は、文書構造を持つ文書を格納し、ユーザが
検索対象の文書構造名と検索文字列を指定して、該当す
る文書を検索する文書検索システムにおいて、登録する
文書のそれぞれについて、文書のテキストデータにおけ
る文字の出現状況を記述した文字成分表を作成するステ
ップと、登録する文書のそれぞれについて、あらかじめ
定められた文書構造名に従って文書構造を認識し、構造
毎にテキストデータを分割するステップと、登録する文
書のそれぞれについて、出現する文字毎に各文字が出現
する文書構造に対応する特定のビット位置に特定ビット
値を立てることで、文字毎の出現文書構造位置を記述し
た構造ビット列を格納するステップと、ユーザからの検
索対象とする文書構造名と、検索文字列の入力を受ける
ステップと、ユーザから与えられた検索文字列につい
て、該文字成分表から、検索文字列を構成する文字成分
の全てが存在する文書を検索するステップと、該検索さ
れたそれぞれの文書毎に、検索文字列の各文字に対応す
る構造ビット列を読み出して、ユーザが指定する文書構
造のビット位置が特定ビット値となっている文書を抽出
するステップとからなり、ユーザが指定する文書構造に
検索文字列が含まれている文書を検索するようにしてい
る。さらに、文書構造の各名称と構造ビット列のビット
位置を対応付けるレコードからなる対応表を備え、該対
応表に基づき文書構造名と構造ビット列のビット位置の
対応をとるようにしている。さらに、前記対応表は、文
書構造の各名称と構造ビット列のビット位置と文書構造
の各名称を示す特殊な文字列である構造識別タグからな
るレコードからなり、前記構造識別タグをテキストデー
タの対応する文書構造に挿入し、該構造識別タグを挿入
されたテキストデータを蓄積するようにしている。さら
に、ユーザから入力された検索対象とする文書構造名に
基づき、前記構造ビット列の該検索対象とする文書構造
名に対応するビット位置を特定ビット値とした指定文書
構造ビット列を作成し、前記検索文字列の各文字に対応
する読み出された構造ビット列と前記指定文書構造ビッ
ト列の対応する各ビット位置のビット値同士についてＡ
ＮＤ演算をし、該演算の結果に基づき検索条件として指
定された複数の文書構造名間のＡＮＤまたはＯＲ条件の
処理を行なうようにしている。さらに、文字成分表の文
書識別子情報を格納する文書識別子情報ファイルと、構
造ビット列を格納する構造ビット列格納ファイルを別々
に作成し、文書識別子情報ファイルの各レコードに構造
ビット列格納ファイルへのポインタ情報を格納するよう
にしている。さらに、ユーザから検索対象とする文書構
造名が入力されたときは、前記検索文字列の各文字に対
応する読み出された構造ビット列と前記指定文書構造ビ
ット列の対応する各ビット位置のビット値同士について
ＡＮＤ演算をし、該演算の結果に基づき検索条件として
指定された複数の文書構造名間のＡＮＤまたはＯＲ条件
の処理を行ない、ユーザから検索対象とする文書構造名
が入力されないときは、前記文字成分表のみを参照し、
構造ビット列の読み出しを行なわないようにしている。

【０００７】

【作用】上記手段により、構造ビット列を格納している
ため、ユーザの指定する検索対象文書構造に検索文字列
を含む文書だけを簡単な処理で検索することができる。
特に、ユーザの指定する検索対象文書構造が複数ある場
合、格納された構造ビット列と指定文書構造ビット列の
対応する各ビット位置のビットＡＮＤ処理だけで条件判
定ができるので、高速な検索処理が行なうことができ
る。また、構造指定検索を行うために、従来構造毎に文
字成分表を持たなければならなかったが、文書全体の文
字成分表を用いて検索対象文書を絞り、次に構造ビット
列にて文書構造まで踏み込んだ検索を行うことで、文字
成分表を単一にして容量を節約することができる。

【０００８】

【実施例】以下、本発明の実施例について詳細に説明す
る。図１は、本実施例の構成を示す図である。本実施例
は、登録検索用の端末１０１，１０２，．．．１１０、
ネットワーク２００、文書サーバ１０００からなる。文
書サーバ１０００には、ＬＡＮアダプタ１０１０、ＣＰ
Ｕ１０２０、ワークメモリ１０３０、文字テーブル１１
００とファイルポインタテーブル１１１０、文書構造識
別タグ対応表１２００を格納するメモリ１０５０、文字
成分表作成プログラム１３１０、構造認識プログラム１
３２０、構造ビット列格納プログラム１３３０、検索条
件入力プログラム１３４０、文字成分表検索プログラム
１３５０、構造ビット列ＡＮＤプログラム１３６０を格
納するメモリ１３００、文字成分表を格納するファイル
１４０１，１４０２，．．．、構造ビット列を格納する
ファイル１４１１，１４１２，．．．．、テキストデー
タ１４２０からなる。

【０００９】まず、構造ビット列を用いた構造指定検索
の概要について説明する。図２は、２文字の連接文字を
文字成分とする文字成分表と構造ビット列を用いた構造
指定検索方式の概要を示している。本図では、ユーザの
指定する条件として、検索対象文書構造に「“発明の名
称”，“請求の範囲”，“効果”のいずれか」を、検索
文字列として“極限作業”が指定された状況を示してい
る。最初に検索の第１ステップとして、文字成分表を用
いて検索文字列“極限作業”を含む文書を検索する。本
図の例では、文字成分表には、２文字の連接文字を文字
成分として、それぞれの文字成分を含む文書の識別子情
報がＩＤリスト形式で格納されている。文字成分表サー
チでは、検索文字列“極限作業”の２文字の連接文字
「“極限”、“限作”、“作業”」の３個の文字成分を
全て含む文書の検索を、各文字成分に対応する文書識別
子情報の積集合をとることによって行っている。図２の
例では、こうして得られた文字成分表の検索結果とし
て、文書ＩＤ列「１，７，１５，３８，．．．．」が示
されている。検索の第２ステップは、検索対象となる文
書構造と対応する構造ビット列の位置を１とした指定文
書構造ビット列（図２では“１００１００００１”であ
り、最初の“１”は発明の名称が、２番目の“１”は請
求の範囲が、最後の“１”は効果が指定されていること
を示している）と、検索文字列の文字成分に対応する構
造ビット列とのビットＡＮＤ処理を行う。構造ビット列
は、図に示すように、各文字成分についてその文字成分
が出現する文書の構造ビット列が並んでいるように格納
されている。この構造ビット列の並びから、文字成分表
で検索された文書に対応する構造ビット列を読み出し
て、指定文書構造ビット列とビットＡＮＤ処理を行い、
検索文字列を構成する全ての文字成分について結果が非
０である文書を最終の検索結果とする。図２の例では、
文字成分“限作”の文書番号１５に対応する構造ビット
列と指定文書構造ビット列とのビットＡＮＤ処理は
“０”となるので、文字成分表の検索結果から文書番号
１５は漏れ、文字成分“極限”，“限作”，“作業”の
文書番号１に対応する構造ビット列と指定文書構造ビッ
ト列とのビットＡＮＤ処理は、“発明の名称”と“効
果”の文書構造において“１”となるので文書番号１は
検索結果となり、文書番号７では“請求の範囲”で
“１”となるので文書番号７は検索結果となる。このよ
うに文字成分表による検索結果からさらに絞り込まれた
文書ＩＤ列「１，７，３８，・・・・」が最終結果とし
て得られている。

【００１０】以上、構造指定検索の概要について説明し
た。次に、本実施例で用いる文字成分表および構造ビッ
ト列の構造について説明する。本実施例では、連接文字
に対応する文書識別子情報を管理するのに、文字テーブ
ル、ファイルポインタテーブルを用いる。図３は文字テ
ーブルおよびファイルポインタテーブルの概要を示す図
である。たとえば、“構成”という文字列を含む文書を
検索する場合には、まず文字テーブルについて“構”の
文字に対応するレコードを参照してファイルポインタテ
ーブルへのポインタ情報５８０を得る。次に、ファイル
ポインタテーブルの先頭から５８０バイト目からの各レ
コードを参照して、第二文字目が“成”のレコードを探
索する。ファイルポインタテーブルには、各連接文字の
第一文字目ごとに、先頭に第二文字目が０のレコードを
格納しておく。第二文字目が０のレコードには、第一文
字目の一文字を含んでいる全ての文書の文書識別子情報
へのポインタを格納しておく。すなわち、第二文字目が
０のレコードは、第一文字だけからなる単一文字に対応
する文書識別子情報をアクセスするためのファイル識別
子（以後ファイルＩＤとも呼ぶ）とファイル内バイト位
置（以後オフセットとも呼ぶ）を格納する。したがっ
て、各連接文字ごとに第二文字目が０のレコードが必ず
存在するため、例えば、“構成”の連接文字を探索する
場合は、“構”に対応するファイルポインタテーブルの
先頭から５８０バイト目のレコードから探索を開始し、
再び第二文字目が０になるまで探索を続け、もし“成”
の文字が見つからない場合は、該当する連接文字がない
と判断できる。図３の例では、“成”のレコードが存在
するため、ここからファイルＩＤが１、オフセットが１
０３４という文書識別子情報へアクセスするための情報
を得ることができる。

【００１１】文書識別子情報は、図４のように複数のフ
ァイルに分割格納する。ファイルポインタテーブルのフ
ァイルＩＤ情報により、どのファイルに文書識別子情報
が格納されているかを特定する。なおかつ特定のファイ
ルＩＤは、文書識別子情報をビットリスト形式で持つと
あらかじめ決めておく。図４の例では、ファイル１が文
書識別子情報をビットリスト形式で持つファイルとして
いる。また、各文書識別子情報の先頭には、構造ビット
列を格納するファイルのオフセット情報が収められてい
る。図３の例で、連接文字“構成”に関する文書識別子
情報へのアクセス情報として、ファイルＩＤが１、オフ
セットが１，０３４が得られる。したがって、ファイル
１内の１，０３４バイト目からのデータを読み出すこと
で、構造ビット列を格納するファイルのオフセット情報
６，７３４と文書識別子情報を示すビット列“０１１１
０１０１０１・・・・”が得られることになる。このビ
ット列は、先頭ビットから文書番号に対応して、“１”
が連接文字“構成”を含む文書を示すことになる。従っ
て、この例では、“構成”を含む文書の文書番号、すな
わちＩＤリストは、１，２，３，５，７，９，・・・・
のように機械的に変換できる。図４の他のファイル（フ
ァイル２及びファイル３）は文書識別子情報をＩＤリス
ト形式で格納したものである。各ＩＤリストの先頭は、
ビットリスト形式で格納されたファイルと同様に、構造
ビット列を格納するファイルのオフセット情報である。
また、オフセット情報に連なるＩＤリストの先頭は、格
納してある文書番号の個数を示している。例えば、連接
文字“構造”の場合、図３の例で、ファイルＩＤが２、
オフセットが３４０であるので、ファイル２の先頭から
３４０バイト目を参照することによって、オフセット情
報６８４と、連接文字“構造”を含む文書数が５６個あ
り、文書番号が５６２、１０３８、・・・というＩＤリ
スト情報を取得する。

【００１２】構造ビット列についても、文書識別子情報
と同じ様に、ファイルポインタテーブルに格納されてい
るファイルＩＤにしたがって複数のファイルに分割して
格納する。図５は構造ビット列の格納ファイルの様子を
示している。例えば、連接文字“構造”の場合、図３の
例で、ファイルＩＤが２、オフセットが３４０であるの
で、文書識別子情報格納ファイル２の先頭から３４０バ
イト目を参照することによって、構造ビット列のオフセ
ット情報６８４が得られる。そこで、構造ビット列の格
納ファイル２の先頭から６８４バイト目を参照すること
によって、該当する文字成分“構造”を含む文書構造の
位置を示す構造ビット列“０１００１１１００１１１１
１１１”が得られる。この構造ビット列は、文書識別子
情報格納ファイルにあるオフセット情報の位置から、そ
の文字成分が出現する文書数分の数だけ順番に並べられ
ている。つまり、構造ビット列格納ファイル２からの構
造ビット列は、連接文字“構造”を含む文書数分すなわ
ち５６個分、文書５６２の構造ビット列、文書１０３８
の構造ビット列、と文書識別子情報にある文書ＩＤにし
たがって順番に並べられている。本実施例では、各構造
ビット列に１６ビットを割り当て、一文書につき１６個
の文書構造を管理できるようにしているが、このビット
数を増やすことによって、１６以上の文書構造を管理す
るように拡張することは容易である。

【００１３】このように、ファイルポインタテーブルに
は、データベース中に存在する連接文字のみを登録する
ので、データベース中に存在しない文字の組み合わせは
全て排除できるという利点がある。したがって、文字テ
ーブルやファイルポインタテーブルで実現している連接
文字の管理情報を格納するファイル量やメモリ量を大幅
に削減することができる。また、文書識別子情報をビッ
ト列あるいはＩＤリストの形式で格納し、多くの文書を
格納する場合はビット列で、少ない文書を格納する場合
はＩＤリストの形式で管理することによりファイル容量
を大幅に削減することができる。具体的に説明すると、
ビットリスト形式で文書識別子情報を格納するには、常
にデータベースに登録した全件分のビット数が必要にな
るが、ＩＤリストの形式で文書識別子情報を格納する場
合には、文書識別子を表わすビット数×登録文書数です
むことになる。例えば、データベースの全登録件数が１
００万件で、一個の文書識別子情報を表わすのに３２ビ
ットを割り当てるとすると、連接文字“構造”を含む文
書を１０件登録する場合には、ビットリスト形式なら
ば、 １００万ｂｉｔ＝１２５ＫＢ の格納領域が必要となるが、ＩＤリスト形式ならば、 ３２ｂｉｔ×１０件＝４０Ｂ の格納領域ですむことになる。一方、例えば、連接文字
“構成”を含む文書が１００万件中で９０万件ある場合
には、ビットリスト形式ならば、 １００万ｂｉｔ＝１２５ＫＢ の格納領域にすむのに対し、ＩＤリスト形式の場合、 ３２ｂｉｔ×９０万件＝３．６ＭＢ の領域が必要となる。したがって、この１００万件を、
文書識別子３２ビットで格納する場合には、 １００万ｂｉｔ÷３２ｂｉｔ＝３１，２５０件 を境として、これよりも登録件数が多い場合はビットリ
スト形式で、少ない場合はＩＤリスト形式で文書識別子
情報を格納するのが、最も格納領域を有効に使用する方
法である。

【００１４】また、構造ビット列を各文字成分に対応さ
せて格納することにより、文字テーブル、ファイルポイ
ンタテーブルと文書識別子情報ファイルからなる文字成
分表を文書構造毎に複数個作成する必要がないという利
点がある。このことは、データベースのファイル削減に
大きな効果がある。

【００１５】以上、構造指定検索の概要と、文字成分表
および構造ビット列の構造について説明した。これよ
り、文書データの登録方法について説明する。図６は、
登録の流れを示すＰＡＤ図である。データの登録時に
は、文字成分表作成プログラム１３１０で登録文書の各
文字成分について必要に応じて文字テーブル、ファイル
ポインタテーブルに文字成分を登録し、各文字成分につ
いて文書識別子情報ファイルに文書ＩＤを格納する（６
０２０）。また、構造認識プログラム１３２０で各文書
の構造毎にテキストデータを分割し（６０３０）、構造
ビット列格納プログラム１３３０により各構造で用いら
れている各文字単位に構造ビット列を作成し格納する
（６０４０）。

【００１６】文字成分表の登録ステップ（６０２０）で
は、文書中に使われている各文字成分について、文字テ
ーブル、ファイルポインタテーブルを参照し、文字成分
が登録されているかチェックし、登録されていない場合
には、文字テーブル、ファイルポインタテーブルに文字
成分を登録する。この文字テーブルあるいはファイルポ
インタテーブルに該当文字が登録されていないときに
は、文書識別子情報を格納するファイルの空領域を確保
して、ファイルＩＤとオフセット値をファイルポインタ
テーブルに格納する。こうして文書中の各文字成分につ
いて、文書識別子情報を格納するファイルＩＤとオフセ
ット値をファイルポインタテーブルから取得し、該当す
る文書識別子情報を格納したファイルに文書ＩＤを格納
していく。

【００１７】構造分割のステップ（６０３０）では、図
７に示す文書構造識別タグ対応表にしたがって、識別タ
グ間のテキストデータを抽出する。例えば、図８に示す
ように、テキストデータを“＃ＢＩＪ−Ｔｉｔｌｅ”，
“＃ＢＩＪ−Ｉｎｖｅｎｔｏｒ”のような識別タグで区
切り、それぞれ“発明の名称”，“発明者”の文書構造
のテキストデータとして、次の構造ビット列格納ステッ
プへ送る。文書構造識別タグ対応表には、次の処理ステ
ップの構造ビット列格納ステップで用いる構造ビット列
のそれぞれの文書構造に対応するビット位置も格納して
いる。

【００１８】構造ビット列格納ステップ（６０４０）で
は、抽出された各文書構造のテキストデータごとにそこ
で用いられている各文字単位に構造ビット列を作成し格
納する。この構造ビット列の格納では、図７に示した文
書構造識別タグ対応表に格納しているビット位置に、そ
れぞれの文書構造のテキストデータ中に存在する文字成
分のデータを登録していく。例えば図８の例で、文書１
の文書構造「発明の名称」に“極限”という文字成分が
あるので、図５に示した例のように「発明の名称」を表
わす構造ビット列の第１ビットを１とする。各文字成分
に対応する構造ビットリストの格納位置は、本実施例で
既に説明したように、文字テーブル、ファイルポインタ
テーブルおよび文書識別子情報ファイルを参照すること
により行う。例えば、文字成分“極限”の場合には、文
字テーブルを第一文字の“極”で参照し、ファイルポイ
ンタテーブルへのオフセット値８７０を得る。次に、フ
ァイルポインタテーブルの先頭から８７０バイト目から
第二文字が“限”であるレコードを探索して、文書識別
子情報格納ファイルをアクセスするためのファイルＩＤ
とオフセット値を得る。こうして、文字成分“極限”に
対応する文書識別子情報をファイルＩＤが３のオフセッ
ト１０８４から読み出し、先頭４バイトの構造ビット列
を格納するファイルのオフセット値８６９２を得る。本
実施例では、このオフセット値８６９２から、文字成分
“極限”を含む文書について一文書につき１６ビットず
つ構造ビット列を格納する。従って、文書番号が１であ
る構造ビット列は、構造ビット列格納ファイルＩＤが３
で先頭から８６９２バイト目より１６ビットが対応して
いることがわかる。このようにして、登録する各文書の
文字成分について文字テーブル、ファイルポインタテー
ブル、および文書識別子情報の格納を行い、各文書の各
文字成分について、該文字成分が存在する文書構造の位
置を構造ビット列として格納していく。

【００１９】検索処理は、図９に示す手順で行う。ま
ず、検索語から文字成分を切り出す（９０１０）。次
に、切り出したそれぞれの文字成分について（９０２
０）、文字テーブルを探索する（９０３０）。そして、
該当するファイルポインタテーブルの各レコードについ
て、第二文字目の探索を行い（９０４０）、該当するフ
ァイルＩＤとオフセット値を得る。こうして、文書識別
子情報を格納したファイルとそのオフセット値により該
当する各連接文字に対応する文書識別子情報を取得する
（９０５０）。この文書識別子情報の取得の過程で該当
する連接文字が文字成分表に登録されていない場合（９
０６０，９０７０）には、すなわち検索語を構成する文
字成分のうちどれか一つでも文字成分表に登録されてい
なければ、検索語を含む該当文書がないので検索結果と
して０件という結果を、文書識別子情報探索プログラム
１３５０がＬＡＮアダプタ１０１０を介して検索端末に
返す。

【００２０】検索語を構成する全ての文字成分について
該当する文書識別子情報が得られた場合は、次に各文字
成分に対応する構造ビット列の読み出しを行う。この読
み出しは、ファイルポインタテーブルから得られるファ
イルＩＤと、文書識別子情報から得られる構造ビット列
格納ファイルのオフセット値および該文字成分を含む文
書数から行うことができる。こうして、全ての文字成分
について構造ビット列を読み出し、検索条件として指定
された文書構造を示すビット位置が１である文書のみを
抽出する（９０８０）。例えば、「発明の名称」に“極
限作業”という文字列を含む文書を検索する場合には、
検索文字列の各文字成分 “極限”、“限作”、“作業” のそれぞれについて、それぞれ文書識別子情報に記載さ
れた件数分の構造ビット列を読み込み、「発明の名称」
に該当するビット位置すなわち第１ビットが１である文
書のみを抽出する。このとき、検索文字列を構成する全
ての文字成分について該当する文書がない場合には、検
索文字列を指定の文書構造に含む文書は０件であるとす
ることができる（９０９０）。それ以外の場合には、全
てのこうして得られた、指定箇所に検索文字列の文字成
分を含む文書について、各文字成分を全て含む文書を検
索結果とする（９１００）。これは、得られたそれぞれ
の文字成分を含む文書の積集合（例えば、図２の場合、
検索結果の文書ＩＤ １，７，３８，・・・からなる積
集合）をとることによって行う。

【００２１】この構造ビット列の読み出しと指定文書構
造に文字成分が含まれているか否かの判定では、複数個
の文書構造についての判定を一度に行うことができる。
図７の文書構造識別タグ対応表に示したビット位置に各
文書構造が対応している場合、「発明の名称」あるいは
「請求の範囲」に検索文字列を含む文書を検索する場合
であれば、これらの構造と対応するビット位置を１とす
る指定文書構造ビット列“１００１０００００００００
０００”と構造ビット列とのビットＡＮＤを行い、結果
が非０となる文書を抽出結果とすればよい。また、「発
明の名称」かつ「請求の範囲」に検索文字列を含む文書
を検索する場合は、指定文書構造ビット列と構造ビット
列とのビットＡＮＤ結果が指定文書構造ビット列と等し
い文書を抽出結果とする。

【００２２】このようにして得られた文字成分表の検索
結果は、検索ノイズが非常に少ないので、文字成分表の
サーチ結果を表示しても十分実用できる。なお、上記の
説明では文書構造名を指定した検索について述べたが、
文書構造名の指定がない場合は、文書識別子ファイルを
参照するだけで、構造ビット列格納ファイルにはアクセ
スしない。

【００２３】もちろん、文字成分表のサーチ結果をもと
に、文書本文を探索し実際に検索語を含む文書のみに絞
り込むかあるいは、複数の検索語間の位置的関係を満た
す文書を探すことも可能である。また、文字成分表の検
索結果を一度検索端末に表示し、ユーザの指定により本
文の探索を行うかどうかを決定してもよい。

【００２４】また、本実施例で用いた文字成分表は、連
接する２文字を文字成分としたが、３文字以上の連接文
字を文字成分として本発明を実施することも容易に実現
できる。３文字以上の連接文字を文字成分として文字成
分表を構成することは、文字成分表サーチの検索精度を
高めるという点で効果がある。特に、カタカナなどの文
字種類の少ない文字種によって構成された検索文字列を
検索する場合に効果がある。同様に文字成分表サーチの
精度を上げるために、１文字飛びに２文字の組み合わせ
を文字成分とすることも考えられる。このような飛び飛
びに数文字の組み合わせすなわちスキップ文字列を文字
成分とすることは、前後間の文字の相関が強い英単語な
どの検索をするのに適している。さらに、通常の連接文
字とこのスキップ文字列の両方を併用することもでき
る。この場合には、通常の連接文字を文字成分とするよ
りは文字成分表のファイル容量を必要とするが、３文字
の連接文字をとるよりは、少ないファイル容量でより高
精度な文字成分表サーチを実現できる。

【００２５】以上、本実施例によれば、構造ビット列と
指定文書構造ビット列とのビットＡＮＤ処理だけで、文
書構造を指定した条件判定を高速に行えるという利点が
ある。また、構造指定検索を行うために、従来の文字成
分表と別に構造ビット列を格納することで文字成分表の
容量を最小限にし、構造を指定しない通常の検索処理に
ついても従来の高速性をそのまま維持して、構造指定検
索機能を付加することが可能となる。

【００２６】

【発明の効果】本発明によれば、構造ビット列を格納し
ておくことにより、ユーザの指定する検索対象文書構造
に検索文字列を含む文書だけを、簡単な処理で検索する
ことができる。特に、ユーザの指定する検索対象文書構
造が複数ある場合、格納された構造ビット列と指定文書
構造ビット列の対応する各ビット位置のビットＡＮＤ処
理だけで条件判定ができるので、高速な検索処理が行え
るという利点がある。また、構造指定検索を行うため
に、従来構造毎に文字成分表を持たなければならなかっ
たが、文書全体の文字成分表を用いて検索対象文書を絞
り、次に構造ビット列にて文書構造まで踏み込んだ検索
を行うことで、文字成分表を単一にしてファイルおよび
メモリ容量を節約できるという利点がある。

【図面の簡単な説明】

【図１】第一の実施例の構成を示す図である。

【図２】構造指定検索方法の概要を示す図である。

【図３】文字成分表のテーブル構成を示す図である。

【図４】文書識別子情報格納ファイルの概要を示す図で
ある。

【図５】構造ビット列格納ファイルの概要を示す図であ
る。

【図６】文書の登録処理を示すＰＡＤ図である。

【図７】文書構造識別タグ対応表の一例を示す図であ
る。

【図８】文書構造別テキストデータ切り出しの例を示す
図である。

【図９】検索処理を示すＰＡＤ図である。

【符号の説明】

１０１，１０２，・・・，１１０ 端末 ２００ ネットワーク １０００ 文書サーバ １０１０ ＬＡＮアダプタ １０２０ ＣＰＵ １０３０，１０５０，１３００ メモリ １１００ 文字テーブル １１１０ ファイルポインタテーブル １２００ 文書構造識別タグ対応表 １３１０ 文字成分表作成プログラム １３２０ 構造認識プログラム １３３０ 構造ビット列格納プログラム １３４０ 検索条件入力プログラム １３５０ 文字成分表検索プログラム １３６０ 構造ビット列ＡＮＤプログラム １４０１ 文書識別子情報ファイル１ １４０２ 文書識別子情報ファイル２ １４０３ 文書識別子情報ファイルｎ １４１１ 構造ビット列格納ファイル１ １４１２ 構造ビット列格納ファイル２ １４１３ 構造ビット列格納ファイルｎ １４２０ テキストデータ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 加藤 寛次 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所 システム開発研究 所内 (72)発明者 浅川 悟志 神奈川県横浜市戸塚区戸塚町5030番地 株式会社日立製作所 ソフトウェア開発 本部内 (56)参考文献 特開 平４−274557（ＪＰ，Ａ) 特開 平５−174064（ＪＰ，Ａ) 特開 平７−319920（ＪＰ，Ａ) 特開 平８−30633（ＪＰ，Ａ) 特開 平６−290217（ＪＰ，Ａ) 特開 平８−147311（ＪＰ，Ａ) 特開 平８−16600（ＪＰ，Ａ) 岩崎雅二郎，小川泰嗣，文字成分表に よる文字列検索の実現と評価，情報処理 学会研究報告（93−ＤＢＳ−92），1993 年 ３月22日，Ｖｏｌ．93，Ｎｏ．29, ｐ．１−10 小川泰嗣，岩崎雅二郎，林大川，全文 検索のための文字成分表方式の改良，情 報処理学会研究報告（94−ＤＢＳ− 99），1994年 ７月22日，Ｖｏｌ．94, Ｎｏ．62，ｐ．261−264 畠山敦，ソフトウェアによるテキスト サーチマシンの実現，情報処理学会研究 報告（92−ＦＩ−25），1992年 ５月12 日，Ｖｏｌ．92，Ｎｏ．32，ｐ．19−25 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 17/30

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】 文書構造を持つ文書を格納し、ユーザが
   検索対象の文書構造名と検索文字列を指定して、該当す
   る文書を検索する文書検索システムにおいて、 登録する文書のそれぞれについて、文書のテキストデー
   タにおける文字の出現状況を記述した文字成分表を作成
   するステップと、 登録する文書のそれぞれについて、あらかじめ定められ
   た文書構造名に従って文書構造を認識し、構造毎にテキ
   ストデータを分割するステップと、 登録する文書のそれぞれについて、出現する文字毎に各
   文字が出現する文書構造に対応する特定のビット位置に
   特定ビット値を立てることで、文字毎の出現文書構造位
   置を記述した構造ビット列を格納するステップと、 ユーザからの検索対象とする文書構造名と、検索文字列
   の入力を受けるステップと、 ユーザから与えられた検索文字列について、該文字成分
   表から、検索文字列を構成する文字成分の全てが存在す
   る文書を検索するステップと、 該検索されたそれぞれの文書毎に、検索文字列の各文字
   に対応する構造ビット列を読み出して、ユーザが指定す
   る文書構造のビット位置が特定ビット値となっている文
   書を抽出するステップとからなり、 ユーザが指定する文書構造に検索文字列が含まれている
   文書を検索することを特徴とする構造化文書検索方法。
2. 【請求項２】 請求項１記載の構造化文書検索方法にお
   いて、 文書構造の各名称と構造ビット列のビット位置を対応付
   けるレコードからなる対応表を備え、該対応表に基づき
   文書構造名と構造ビット列のビット位置の対応をとるこ
   とを特徴とする構造化文書検索方法。
3. 【請求項３】 請求項２記載の構造化文書検索方法にお
   いて、 前記対応表は、文書構造の各名称と構造ビット列のビッ
   ト位置と文書構造の各名称を示す特殊な文字列である構
   造識別タグからなるレコードからなり、前記構造識別タ
   グをテキストデータの対応する文書構造に挿入し、該構
   造識別タグを挿入されたテキストデータを蓄積すること
   を特徴とする構造化文書検索方法。
4. 【請求項４】 請求項１記載の構造化文書検索方法にお
   いて、 ユーザから入力された検索対象とする文書構造名に基づ
   き、前記構造ビット列の該検索対象とする文書構造名に
   対応するビット位置を特定ビット値とした指定文書構造
   ビット列を作成し、前記検索文字列の各文字に対応する
   読み出された構造ビット列と前記指定文書構造ビット列
   の対応する各ビット位置のビット値同士についてＡＮＤ
   演算をし、該演算の結果に基づき検索条件として指定さ
   れた複数の文書構造名間のＡＮＤまたはＯＲ条件の処理
   を行なうことを特徴とする構造化文書検索方法。
5. 【請求項５】 請求項１記載の構造化文書検索方法にお
   いて、 文字成分表の文書識別子情報を格納する文書識別子情報
   ファイルと、構造ビット列を格納する構造ビット列格納
   ファイルを別々に作成し、文書識別子情報ファイルの各
   レコードに構造ビット列格納ファイルへのポインタ情報
   を格納することを特徴とする構造化文書検索方法。
6. 【請求項６】 請求項４記載の構造化文書検索方法にお
   いて、 ユーザから検索対象とする文書構造名が入力されたとき
   は、前記検索文字列の各文字に対応する読み出された構
   造ビット列と前記指定文書構造ビット列の対応する各ビ
   ット位置のビット値同士についてＡＮＤ演算をし、該演
   算の結果に基づき検索条件として指定された複数の文書
   構造名間のＡＮＤまたはＯＲ条件の処理を行ない、 ユーザから検索対象とする文書構造名が入力されないと
   きは、前記文字成分表のみを参照し、構造ビット列の読
   み出しを行なわないことをことを特徴とする構造化文書
   検索方法。