(57)【要約】  【課題】  アクセス権限を考慮して統合検索を行う。  【解決手段】  検索ユーザ端末１５から検索要求がなされると、検索部１０はアクセス制御部１１に検索ユーザのユーザＩＤ等を供給し、アクセス制御部１１は、ユーザ権限記憶部１２を参照して検索ユーザのアクセス権限を返す。アクセス制御部１１は、例えば、アクセス権限とそれに対応するインデクスとの関係を規定した表を表引きして、検索ユーザのアクセス権限で参照可能なインデクス１４の識別子（複数の場合もある）を検索部１０に返す。検索部１０は、参照可能なインデクス１４の識別子に基づいて許容されるインデクス１４を参照してヒットしたレコードを取りだし、検索ユーザ端末１５に返す。【選択図】  図１
2009163772.tif 000002
【特許請求の範囲】
【請求項１】
各々異なる検索インデクスを複数記憶するインデクス記憶手段と、
各々異なる上記検索インデクスに対応し該対応する検索インデクスを検索して予め定められたレコード数を上限として検索スコアを含むヒットレコードを該検索スコアでソートして検索結果として出力する複数の検索手段と、
上記複数の検索手段により出力された上記複数の検索結果を、該検索結果が含むヒットレコード数の多い順に、合計のヒットレコード数が予め定められた累積上限値に達するまで、連結する連結手段と、
上記連結手段により連結された検索結果に含まれるヒットレコードを上記検索スコアでソートするソート手段と、
上記ソート手段によりソートされたヒットレコードを上位から予め定められた出力上限値だけ出力する出力手段と、
を備える検索システム。
【請求項２】
複数の検索装置と、上記複数の検索装置と通信する検索管理装置とを備え、
上記検索装置の各々は、
検索インデクスを記憶するインデクス記憶部と、
上記検索インデクスに対応し該対応する検索インデクスを検索する検索手段と、
を備え、上記インデクス記憶部に記憶される検索インデクスは検索装置毎に異なっており、
上記検索管理装置は、
検索要求を受け取る受取手段と、
上記受取手段により受け取られた検索要求を上記複数の検索装置に転送し、各検索装置に該検索要求に対応するヒットレコードを予め定められたレコード数を上限として上記ヒットレコードに含まれる検索スコアでソートして検索結果として出力させる転送手段と、
上記複数の検索装置により出力された上記複数の検索結果を該検索結果が含んでいるヒットレコード数の多い順に合計のヒットレコード数が予め定められた累積上限値に達するまで連結する連結手段と、
上記連結手段により連結された検索結果に含まれるヒットレコードを上記検索スコアでソートするソート手段と、
上記ソート手段によりソートされたヒットレコードを上位から出力上限値だけ出力する出力手段と、
を備える検索システム。
【請求項３】
検索要求を受け取る受取手段と、
検索インデクスを記憶するインデクス部と該検索インデクスに対応し該検索インデクスを検索する検索手段とを備え上記インデクス記憶部に記憶される検索インデクスが各々異なっている複数の検索装置に上記検索要求を転送し、各検索装置に該検索要求に対応するヒットレコードを予め定められたレコード数を上限として上記ヒットレコードに含まれる検索スコアでソートして出力させる転送手段と、
上記複数の検索装置により出力された複数の検索結果を該検索結果が含んでいるヒットレコード数が多い順に合計のヒットレコード数が予め定められた累積上限値に達するまで連結する連結手段と、
上記連結手段により連結されたヒットレコードを上記検索スコアでソートするソート手段と、
上記ソート手段によりソートされたヒットレコードを出力上限値だけ上位から出力する出力手段と、
を備える検索管理装置。
【請求項４】
コンピュータを、
検索要求を受け取る受取手段と、
検索インデクスを記憶するインデクス部と該検索インデクスに対応し該検索インデクスを検索する検索手段とを備え上記インデクス記憶部に記憶される検索インデクスが各々異なっている複数の検索装置に上記検索要求を転送し、各検索装置に該検索要求に対応するヒットレコードを予め定められたレコード数を上限として上記ヒットレコードに含まれる検索スコアでソートして出力させる転送手段と、
上記複数の検索装置により出力された複数の検索結果を該検索結果が含んでいるヒットレコード数が多い順に合計のヒットレコード数が予め定められた累積上限値に達するまで連結する連結手段と、
上記連結手段により連結されたヒットレコードを上記検索スコアでソートするソート手段と、
上記ソート手段によりソートされたヒットレコードを出力上限値だけ上位から出力する出力手段
として機能させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、検索システムおよびコンピュータプログラムに関する。
【背景技術】
【０００２】
従来、分散環境において、独立して管理され、開示される複数の文書ファイリングをまたがって、論理的に唯一のインデクスを構築し、インデクスに対して、一回の検索操作で、複数の文書ファイリングに存在する、複数の、文書の属性や、ＵＲＬなどで示される文書の位置を、一元的に管理し、検索が可能なデータベースが構築されている。このような検索を統合検索と呼ぶ。
【０００３】
統合検索のためのインデクス構築に際して、検索操作と独立して行われる収集操作によって、複数の文書ファイリングから、文書が収集される。収集操作は、収集対象とする文書ファイリングから、所定のアクセス権を有するユーザ、またはアプリケーションが、所定のネットワークプロトコルで、文書名を指定するか検索を行って、文書を特定し取得する。取得した文書を解析し、インデクス構築に必要な属性やキーワードを作成して、インデクスを構築する。
【０００４】
なお、この発明と関連する特許文献には、複数のデータベースにそれぞれ格納されている文章データを解析し必要項目を抽出し抽出結果をインデクス化し、単一のインデクスで複数のデータベースにアクセスすることを開示するものや（特許文献１）、記憶装置に記憶されている複数のファイルの各々から所定の情報を取得するとともに権限情報も取得し所定の情報と権限情報とを用いてインデクスを構築してユーザの権限に応じた範囲でしか検索が行われないようにすることを開示するもの（特許文献２）がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１６３４４５公報
【特許文献２】特開２００１−３４４２４５公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
この発明は、種々の文書ファイリングにわたって統合検索を行う場合でも、高速の検索が可能な検索技術を提供することを目的としている。
【課題を解決するための手段】
【０００７】
本発明の原理的な構成では、複数のインデクスを用いて検索を行う検索装置において、各インデクスから取得した、スコアを含むヒットレコードをスコアに基づいて各インデクスごとにソートし、ソートした上記スコアを含むヒットレコードを所定の規則で連結し、連結した上記スコアを含むヒットレコードをスコアに基づいて再度ソートし、再度ソートした後のヒットレコードの上位の所定数を検索結果として出力するようにしている。
【０００８】
この構成においては、インデクスごとにスコアを計算しソートを行うので、複数のインデクスに対して分散処理が可能であり、応答性を高め、スケーラビリティを確保することができる。また、インデクスごとにソートしたヒットレコードを連結する際に、インデクスごとのヒットレコードの処理対象上限値を定めておけば、不必要なヒットレコードをヒットレコード連結部に送る必要がなくなり、例えば通信コストを低減することが可能となる。
【０００９】
なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品もこの発明の技術的な範囲に含まれることも当然である。
【００１０】
この発明の上述の側面およびこの発明の他の側面は特許請求の範囲に記載され、以下実施例を用いて詳細に説明される。
【発明の効果】
【００１１】
この発明によれば、複数のインデクスを用いた場合でも、本構成を有していない場合と比較して、高速に検索を行える。
【図面の簡単な説明】
【００１２】
【図１】この発明の実施例１の検索装置を模式的に示すブロック図である。
【図２】上述の実施例１のインデクス構築装置を模式的に示すブロック図である。
【図３】上述の実施例１をイントラネット環境に適用した構成例を説明する図である。
【図４】この発明の実施例２の検索装置を模式的に示すブロック図である。
【図５】上述実施例２のインデクス別ヒットレコード数生成部における各インデクスのヒットレコード算出処理を説明するための、Ｂ＋ツリー構造の説明図である。
【図６】図５のＢ＋ツリー構造の管理ノードを説明する図である。
【図７】図５のＢ＋ツリー構造の中間ノードを説明する図である。
【図８】図５のＢ＋ツリー構造のリーフノードを説明する図である。
【図９】図５のＢ＋ツリー構造の検索を説明する図である。
【図１０】図５のＢ＋ツリー構造に含まれる件数管理情報を説明する図である。
【図１１】図５のＢ＋ツリー構造を用いてインデクスのヒットレコードを算出する処理を説明するフローチャートである。
【図１２】図１１の順位算出ルーチンを説明するフローチャートである。
【図１３】この発明の実施例３の構成を説明する図である。
【図１４】上述実施例３の動作を説明するフローチャートである。
【図１５】上述実施例３におけるレコードのフォーマットを説明する図である。
【図１６】上述実施例のスコア計算の例を説明する図である。
【発明を実施するための形態】
【００１３】
以下、この発明の実施例について説明する。
【００１４】
［実施例１］
実施例１は複数のインデクスを用いアクセス権限に応じて検索を制御するものである。
【００１５】
図１は、実施例１の検索装置を模式的に示しており、この図において、検索装置は、検索部１０、アクセス制御部１１、ユーザ権限記憶部１２およびインデクス記憶装置１３を含んで構成されている。インデクス記憶装置１３は、複数のインデクス（便宜上Ａ〜Ｎを付す）１４を記憶している。複数のインデクス１４はそれぞれ異なるレベルのアクセス権限が付与されている。もちろん、同一のアクセス権限が複数のインデクス１４に付与され、同一のアクセス権限のグループとして管理されても良い。１つのインデクス記憶装置１３にすべてのインデクス１４を記憶するのでなく、複数のインデクス記憶装置１３を設け、分散させて記憶するようにしても良い。この実施例の検索装置には検索ユーザ端末１５から検索要求が送られ、検索結果が検索ユーザ端末１５に返される。
【００１６】
インデクス記憶装置１３のインデクス１４は、後述するインデクス構築装置（図２）により構築・管理される。
【００１７】
この実施例において、検索ユーザ端末１５から検索要求がなされると、検索部１０はアクセス制御部１１に検索ユーザのユーザＩＤ等を供給し、アクセス制御部１１は、ユーザ権限記憶部１２を参照して検索ユーザのアクセス権限を返す。アクセス制御部１１は、例えば、アクセス権限とそれに対応するインデクスとの関係を規定した表を表引きして、検索ユーザのアクセス権限で参照可能なインデクス１４の識別子（複数の場合もある）を検索部１０に返す。検索部１０は、参照可能なインデクス１４の識別子に基づいて許容されるインデクス１４を参照してヒットしたレコードを取りだし、検索ユーザ端末１５に返す。ヒットしたレコードを、ランキングスコアに基づいて整理し、所定の表示数のレコードのみ検索ユーザ端末１５に返すようにしてもよい。
【００１８】
この例では、インデクス１４を参照してヒットしたレコードは、すべてアクセス可能なものであり、ヒットしたレコードについて個々にユーザのアクセス権限を検証する必要がない。
【００１９】
なお、検索ユーザが指定したインデクス１４あるいはすべてのインデクス１４に対して検索部１０が参照要求を行い、アクセス制御部１１が、ユーザ権限記憶部１２のユーザのアクセス権限を参照して参照の許否を行うようにしても良い。
【００２０】
つぎにこの実施例のインデクス構築装置について説明する。
【００２１】
図２は、この実施例のインデクス構築装置を模式的に示しており、この図において、インデクス構築装置は、プロセス起動部２０、インデクスレコード管理部２１、アクセス制御部２３、プロセス権限記憶部２４を含んで構成されている。プロセス起動部２０は、予めアクセス権限が設定されている。プロセス起動部２０は、インデクスレコード管理部２１のインデクスレコード管理プロセス２２を起動し、プロセス起動部２０のプロセスを付与する。ユーザあるいは管理者がインデクスレコード管理部２１のインデクスレコード管理プロセス２２を起動し、そのアクセス権限を付与するようにしても良い。起動されたインデクスレコード管理プロセス２２は、文書を保持する文書ファイリングシステム１０３（図３参照）にアクセスし、自らのアクセス権限で許容される文書を参照してインデクスレコードを生成する。文書ファイリングシステム１０３の文書へのアクセスはアクセス制御部２３およびプロセス権限記憶部２４により制御される。こうしてインデクスレコード管理プロセス２２は、自らのアクセス権限に対応する（同等以下の）セキュリティドメインの文書のインデクスレコードを生成して、インデクス記憶装置１３中の対応するアクセス権限のインデクス１４を構築したり、修正（挿入・削除）したりする。このインデクス１４の構築・修正の処理についてもアクセス制御部２３およびプロセス権限記憶部２４により制御される。
【００２２】
このようにしてアクセス権限ごとにインデクス１４が構築・管理される。
【００２３】
図３は、実施例１の検索装置およびインデクス構築装置をイントラネット環境で実現した構成例を示す。図３において、検索システム１００、複数のインデクス構築システム１０２、複数の文書ファイリングシステム１０３、ディレクトリサーバ１０４、ウェブサーバ１０５、アプリケーションサーバ１０６、クライアント端末１２０等が、ＬＡＮ１０８に配置されている。またＬＡＮ１０８にはルータ１０７、ネットワーク１２１を介してクライアント端末１２０が接続されている。
【００２４】
検索システム１００はインデクス保持部１０１を有し、複数のインデクス（図１のインデクス１４）を参照できる。
【００２５】
検索システム１００、インデクス構築システム１０２はそれぞれ記憶媒体１０９、１１０、あるいはネットワーク１２１を用いてインストールされる。
【００２６】
文書ファイリングシステム１０３は全体として単一のアクセス権限が付与されていても良いし（例えば１０３Ａ）、文書ファイリングシステム１０３の個々の文書あるいはディレクトリにアクセス権限が個別に付与されても良い。文書ファイリングシステム１０３Ａとインデクス構築システム１０２Ａは例えば同一のアクセス権限を有し、対応するセキュリティドメイン２００をなす。他のファイリングシステム１０３は種々のアクセス権限の文書等を含み、それぞれ、アクセス権限に対応するインデクス構築システム１０２によりインデクスレコードを生成できるようになっている。
【００２７】
インデクス構築システム１０２は対応するアクセス権限で各文書ファイリングシステム１０３の文書をアクセスしていき、文書ファイリングシステム１０３はディレクトリサーバ１０４を用いて権限を認証し、アクセスの許否を決定する。インデクス構築システム１０２は、対応するアクセス権限の文書を参照してインデクスレコードを生成して、インデクス保持部１０１の対応するインデクス１４を構築し、あるいは対応するインデクスにレコードを挿入する。また、必要に応じ、インデクスのレコードの削除等の処理を行う。
【００２８】
このようにして、インデクス保持部１０１にアクセス権限ごとにインデクス１４が構築されその後管理される。
【００２９】
検索ユーザはクライアント端末１２０を用いてウェブサーバ１０５およびアプリケーションサーバ１０６（あるいはＣＧＩプログラム等を用いて）を介して検索システム１００に検索要求を行う。検索システム１００は、ディレクトリサーバ１０４を用いて検索ユーザのアクセス権限を調べ、これに応じて対応するインデクス１４を参照して検索ユーザに許容されるヒットレコードのみをリストとしてクライアント端末１２０に返す。検索ユーザは、リストから選択した文書を所定の文書ファイリングシステム１０３から取り出すことができる。
【００３０】
なお、インデクス保持部１０１をインデクス構築システム１０２サイトに分散して配置し、検索システム１００がこれを参照するようにしても良い。また、インデクス構築システム１０２サイトに検索システム１００およびインデクス保持部１０１を分散配置してもよい。この場合、クライアント端末１２０の検索要求を代行して分散配置された複数の検索システム１００にディスパッチする。
【００３１】
［実施例２］
つぎにこの発明の実施例２について説明する。この実施例は複数のインデクスを用いた場合でも、ランキングスコアの小さなヒットレコードが表示リストに含まれないようにするものである。
【００３２】
図４は、この実施例の検索装置を模式的に示しており、この図において、検索部１０は、インデクス別ヒットレコード数生成部３０、インデクス選択部３１、ヒットレコード併合部３２、ヒットレコード一時記憶部３３、表示レコード出力部３４等を含んで構成されている。
【００３３】
検索ユーザ端末１５は、検索部１０に検索要求を送る。検索要求には検索キーと共に表示レコードの数を含ませることができる。インデクス別ヒットレコード数生成部３０は、検索キーに対してインデクス１４ごとにヒットレコード数を算出する。これについては後に説明する。インデクス選択部３１は、指定された表示レコード数あるいはデフォルトの表示レコード数に基づいてインデクス記憶装置１３から取り出すヒットレコード数を決定する。これを閾値と呼ぶ。閾値は、表示レコード数のＮ倍である（Ｎは十分に精度の良い結果を得られるように決められる）。インデクス選択部３１は、最も少ないインデクス数で閾値のヒットレコードを得られるようにインデクスを選択する。種々の態様が可能であるが、例えば、ヒットレコード数が多い順にインデクスを選び、それで閾値に達したら、そのインデクスのみを選ぶ。ヒットレコード数が閾値に達しない場合には、つぎにヒットレコード数が多いインデクスを選び、そのヒットレコード数を、現在のヒットレコード数の総数に累積する。累積値が閾値に達するまで、同様の処理を繰り返し、用いる１または複数のインデクスを確定する。
【００３４】
用いるインデクスが複数の場合にはヒットレコードをヒットレコード併合部３２で併合し、ヒットレコード一時記憶部３３にストアする。用いるインデクスが一個の場合にはヒットレコードをそのままヒットレコード一時記憶部３３にストアする。
【００３５】
ヒットレコード一時記憶部３３のヒットレコードはそこの含まれるランキングスコアに基づいてソートされ、ソート順に表示レコード出力部３４に送られる。表示レコード出力部３４の出力表示レコードリストは検索ユーザ端末１５に返される。
【００３６】
こうして、ヒットレコードの併合処理の回数を少なくすることができる。
【００３７】
つぎに、インデクス別ヒットレコード数生成部３０で行うヒットレコード数算出処理について説明する。もちろん、キーごとにヒットレコード数を予め求めて表を作成し、このような表を表引きしても良い。
【００３８】
インデクス記憶装置１３のインデクス１４は、例えば、図５に示すように、管理ノード、中間ノードおよびリーフノードにより記述されるＢ＋ツリー構造である。管理ノードは、図６に示すように、複数のＢ＋ツリーを管理する。各Ｂ＋ツリーはスキーマによりキー、バリュー等のバイト数等が規定される。管理ノードにより、検索キーが対応するＢ＋ツリーに振り分けられる。中間ノードは、図７に示すように、分岐を制御するキーと分岐する下位ノード（サブツリー）が規定される。また、この実施例に特有の構成として、各下位ノードについてそのサブツリーのリーフノードに属するレコードの数を件数管理情報として保持している。リーフノードは図８に示すようにキーとバリュー（例えば文書ＩＤ）との複数の対を含んでいる。リーフノードは、中間ノードにおいて分岐を制御するキーについても、そのキーとバリューとの対を含んでいる。また、つぎのリーフノードへのポインタも含まれ、いわゆる水平検索を行える。
【００３９】
検索に際しては、図９に示すように、管理ノードによりＢ＋ツリーが決定され、そのルートノードから中間ノードを沿って垂直検索が行われ、リーフノードに当直した後、水平検索が行われる。
【００４０】
ここで、図１０を用いて、中間ノードの件数管理情報について説明する。図１０において、中間ノードは、第１段目の中間ノード（管理ノードのつぎのノード）を例にすると、キー「ＬＥＦＴ」、Ｋ（０）１、Ｋ（０）２、Ｋ（０）３、・・・により下位ノード（サブツリー）に分岐する。キー「ＬＥＦＴ」の直下にはレコードは格納されない。「Ｋ（０）」は第１段目のキーであることを示す。第ｎ段目の中間ノードのキーは同様に「Ｋ（ｎ−１）」で表す。「ＬＥＦＴ」からＫ（０）１までの範囲のキーが分岐する下位ノード（サブツリー）のリーフノードに格納されるレコードの数Ｒ（０）１を、下位ノード０の件数管理情報にストアする。Ｋ（０）１からＫ（０）２までの範囲のキーが分岐する下位ノード（サブツリー）のリーフノードに格納されるレコードの数ｒ（０）１を求め、これにその前の下位ノードのレコードの数（この場合Ｒ０）を足して、Ｒ（０）１＝Ｒ（０）１＋ｒ（０）１を得、下位ノード１の件数管理情報に格納する。キーＫ（０）ＮからキーＫ（０）Ｎ＋１までの範囲のキーが分岐する下位ノードＮのリーフノードに格納されるレコードｒ（０）Ｎを求め、これにその直前の下位ノードＮ−１の件数管理情報（Ｒ（０）Ｎ−１）を足して、下位ノードＮの件数管理情報Ｒ（０）Ｎ＝Ｒ（０）Ｎ−１＋ｒ（０）Ｎを得る。同様に最後の下位ノードまで、件数管理情報を取得して管理する。
【００４１】
開始キーおよび終了キーを用いて検索するときに、中間ノードの件数管理情報を用いてリーフノードに到達した時点の順位を求めることができる。すなわち、順次辿っていく中間ノードにおいて、つぎに辿る下位の中間ノードを決定する。このとき、その左側の中間ノードの件数管理情報を求める。つぎに辿る中間ノードでも同様にし、この操作をリーフノードに至るまで繰り返す。例えば、第１段から第Ｎ段のそれぞれのキーＫ（０）Ａ、Ｋ（１）Ｂ、Ｋ（２）Ｃ、・・・、Ｋ（Ｎ−１）Ｄを辿っていくとすると、中間ノード０のキー（下位のノードまたはサブツリー。以下同様）Ｋ（０）Ａ−１の件数管理情報Ｒ（０）Ａ−１、中間ノード１のキーＫ（１）Ｂ−１の件数管理情報Ｒ（１）Ｂ−１、中間ノード２のキーＫ（２）Ｃ−１の件数管理情報Ｒ（２）Ｃ−１、・・・中間ノード（Ｎ−１）のキーＫ（Ｎ−１）Ｄ−１の件数管理情報Ｒ（Ｎ−１）Ｄ−１を累積してリーフノードに到達したときレコードの順位を得ることができる。
【００４２】
まず、開始キーを基づいて中間ノードを辿り、対応する件数管理情報を累積してリーフノードに到達したときのレコードの順位を求め、さらにリーフノードを水平検索する。開始キーを含むレコードに到達したときにそのレコードに至るまでの水平検索時のレコード数を求め、これをリーフノードに到達したときのレコードの順位に足して開始キーを含むレコード（開始キーを含むレコードがない場合には、検索範囲に含まれて開始キーに最も近いキーを含むレコード）の順位（Ｎｓｔａｒｔ）を求める。
【００４３】
つぎに、終了キーに基づいて中間ノードを辿り、対応する件数管理情報を累積してリーフノードに到達したときのレコードの順位を求め、さらにリーフノードを水平検索する。終了キーを含むレコードに到達したときにそのレコードに至るまでの水平検索時のレコード数を求め、これをリーフノードに到達したときのレコードの順位に足して終了キーを含むレコード（開始キーを含むレコードがない場合には、検索範囲に含まれて開始キーに最も近いキーを含むレコード）の順位（Ｎｅｎｄ）を求める。
【００４４】
インデクス別ヒットレコード数生成部３０は、ＮｓｔａｒｔおよびＮｅｎｄに基づいて検索範囲に含まれるキーを持つレコードの総数を算出する。終了キーを含むレコードが有る場合には、そのレコードの総数はＮｅｎｄ−Ｎｓｔａｒｔ＋１であり、終了キーを含むレコードがない場合には、そのレコードの総数はＮｅｎｄ−Ｎｓｔａｒｔである。
【００４５】
図１１は、インデクス別ヒットレコード数生成部３０における各インデクスごとのヒットレコード数算出処理を示している。図１１においては、語および文書ＩＤを用いて範囲検索における検索範囲のレコード（文書）の総数を算出する。総数の算出の処理は以下のとおりである。なお、検索者が語を入力すると、文書ＩＤの範囲が自動的に０ｘ３０００（１６進数表示）から０ｘ３ｆｆｆとされる。
【００４６】
［ステップＳ１０］：検索範囲を受け取る。
［ステップＳ１１］：Ｂ＋ツリーを決定する。
［ステップＳ１２］：開始キーを検索キーとする。
［ステップＳ１３］：検索キーが該当するキーを、選択する
［ステップＳ１４］：順位算出ルーチンを実施する。図９参照。
［ステップＳ１５］：順位算出ルーチンで取得した順位をＮｓｔａｒｔとする。
［ステップＳ１６］：終了キーを検索キーとする。
［ステップＳ１７］：順位算出ルーチンを実施する。
［ステップＳ１８］：順位算出ルーチンで取得した順位をＮｅｎｄとする。
［ステップＳ１９］：終了キーに該当するレコードがあるか。あればステップＳ２０ヘ進み、なければステップＳ２１へ進む。
［ステップＳ２０］：検索範囲の件数をＮｅｎｄ−Ｎｓｔａｒｔ＋１で算出する。
［ステップＳ２１］：検索範囲の件数をＮｅｎｄ−Ｎｓｔａｒｔで算出する。
【００４７】
順位算出ルーチンはつぎのとおりである。
【００４８】
［ステップＳ４０］：順位を０にリセットする。
［ステップＳ４１］：中間ノードにおいて検索キーが該当するキーの左のキーの件数管理情報を順位に累積する。
［ステップＳ４２］：検索キーが該当するキーの下位のノードに進む。
［ステップＳ４３］：ノードが中間ノードかリーフノードかを判別する。中間ノードであれば、ステップＳ４１に戻る。リーフノードであればステップＳ４４に進む。
［ステップＳ４４］：リーフノードに到達したときのレコードから検索キーに対応するキーのレコードまで水平検索で辿る。
［ステップＳ４５］：水平検索で辿ったレコードの数を上述の順位に累積する。
【００４９】
以上で実施例２の説明を終了する。
【００５０】
［実施例３］
つぎにこの発明の実施例３について説明する。この実施例は、インデクスを用いた検索処理を行う検索装置本体と検索装置本体の検索結果を連結等する検索管理装置とをネットワークを介して接続して検索システムを構築するものである。
【００５１】
図１３は、実施例３の検索システムを全体として示しており、図１３において図３と対応する箇所には対応する符号を付した。図１３において、検索システム１００は、検索管理サーバ３００と複数の検索サーバ３０１とを有して構成されている。検索サーバ３０１はそれぞれ対応するインデクス保持部３０２を有し、例えばこのインデクス保持部３０２に格納されているＢ＋ツリーの情報（実施例１、２と同様）を用いて検索を行う。検索管理サーバ３００は、クライアント１２０からの検索要求を受取り、アクセス制御等を行うとともに、検索要求に対して許容された検索サーバ３０１に検索要求をディスパッチする。検索管理サーバ３００は、検索要求をディスパッチした検索サーバ３０１から検索結果を受取り、出力上限値（例えばユーザが指定したもの。あるいはシステム上のデフォルト値）だけヒットレコードを取り出して検索結果としてクライアント端末１２０に返す。
【００５２】
図１４は、実施例３の検索システム１００における処理を示しており、その詳細は以下のとおりである。なお、これらの処理は検索管理サーバ３００および検索サーバ３０１で実行されるものであり、例えば記録媒体３０３、３０４に記憶されたプログラムを検索管理サーバ３００や検索サーバ３０１にインストールして実現できる。
【００５３】
［ステップＳ５０］：各検索サーバ３０１でインデクス保持部３０２のインデクスを用いて検索を行う。なお、各検索サーバ３０１は、出力制限値（ユーザに出力するレコードの数の上限）の例えば１０倍のレコード数を上限としてレコードを取り出す（上限値を超えたら検索を終了する）。このレコードは例えば図１５に示すようなキーとバリューとを含むものであり、キーは語キー（キーワード等の文書の属性）および文書ＩＤからなる。バリューは各レコードの検索スコアを算出するためのオカレンスデータであり、例えば、更新時刻、出現頻度、出現分布のデータからなる。オカレンスデータからスコアを計算し、このスコアに基づいてヒットレコードをソートする。
【００５４】
［ステップＳ５１］：検索管理サーバ３００は、検索サーバ３０１からソート済みのヒットレコードを受け取る。受け取るレコードはスコアを直接に含み、オカレンスデータは基本的には不要である。
［ステップＳ５２］：ソート済みのヒットレコード数が多い順に、検索サーバ３０１からのヒットレコードを連結する。
［ステップＳ５３］：連結したヒットレコードの総数が累積上限値、例えば、出力上限値の１０倍に達したかどうかを判別する。累積上限値に達しない場合にはステップＳ５２に戻り処理を繰り返す。達した場合にはステップＳ５４へ進む。
［ステップＳ５４］：連結したヒットレコードをスコアで再度ソートする。
「ステップＤ５５］：出力上限値だけ上位からヒットレコードを出力する。
【００５５】
各レコードのスコアは例えばつぎのように算出される。
［数１］
｛Ａ１×（出現密度）＋Ａ２×（更新日−基準日）｝×（出現分布情報で決定される値。例えば１〜２の値）
Ａ１、Ａ２は係数である。
【００５６】
出現密度は、キーワードが文書中に含まれる割合であり、例えば、定数×出現数／文書サイズで求められる。出現密度が大きいほどスコアが大きくなる。
【００５７】
更新日は文書を更新した日付であり、原則として基準時は検索を行っている日付に「２０４８」（約４年）を足したものである。「日付」は例えば０〜３２７６７の整数値であり、およそ、１９７０年１月１日から２０３８年１月１９日をカバーする。１日は１．３に相当する。通常、更新日は数カ月から数年程度前の日付である。更新日をそのまま用いると、約３０年分使用しない期間ができてしまうので、ダイナミックレンジが小さくなってしまう。そのため検索実行日から４年前（約２０４８）を基準日としている（更新日−基準日＝更新日−検索実行日＋２０４８）。更新日が新しいほどスコアは大きくなる。
【００５８】
出現分布情報は、文書中の文の列に語キーがどのように分布するかを示すものであり、文の列を３２ビットであらわし、当該文の位置に語キーが出現すれば「１」を立てる。文の数だけビットを設ければより性格であるが、この例では、語キーが出現する文の番号の３２の剰余が示すビット位置に「１」を立てている。複数の語キーを用いたときに３２ビットの出現分布情報のＡＮＤをとり、同一文中に当該複数の語キーが共起するかどうかを表す。ＡＮＤ結果の３２ビットの各値を評価すればより正確であるが、８ビットずつに４つのフラグメントに分け、１つのフラグメント中に「１」があれば２５％ずつ増分する。４つのフラグメントのすべてに「１」があれば２倍となり、すべてのフラグメントに「１」がなければ１倍のままである。
【００５９】
また、スコアが同一の値にならないように、スコアに文書サイズの下位数ビットを連結する。
【００６０】
図１６は、スコア計算の一例を示している。この例では、「コピー」と「富士ゼロックス株式会社」（「富士ゼロックス」は商標である）のＯＲ検索を行って、文書Ａ、Ｂ、Ｃがヒットした例である。検索日は「２００２年８月１日」である。
【００６１】
文書Ａのスコアはつぎのとおりである。すなわち、実際の出現密度の和が「０ｘ０９＋０ｘ１３＝０ｘ１Ｃ」（０ｘは１６進を表す）であり、文書サイズと合わせて「０ｘ１ＣＢ８」である。更新日の寄与を合わせて、「０ｘ３ＣＢ８」となり、出現分布で１．７５倍になり、「０ｘ６Ａ４７＝２７２０７」がスコアとなる。
【００６２】
文書Ｂのスコアはつぎのとおりである。出現密度と文書サイズから同様に「０ｘ１Ｆ４０」となる。「富士ゼロックス株式会社」からのオカレンスからは得られないので、デフォルト値の「０ｘ１８００」が用いられ、合わせて「０ｘ３７４０」となり、出現分布により２倍され、「０ｘ６Ｅ８０＝２８２８８」がスコアとなる。
【００６３】
文書Ｃのスコアはつぎのとおりである。実際の出現密度の和が「０ｘ１Ｄ＋０ｘ００＝０ｘ１Ｄ」であり、文書サイズと合わせて「０ｘ１Ｄ８０」である。更新日の寄与を合わせて「０ｘ１７Ｅ３」となる。出現分布により２倍され、「０ｘ２ＦＣ６＝１２２３０」がスコアとなる。
【００６４】
以上の結果、文書Ｂ、Ａ、Ｃの順にソートされる。
【００６５】
以上で実施例３の説明を終了する。この実施例によれば、スコア計算やソートを分散させて実行するため、応答性を高くでき、スケーラビリティもある。また、所定の上限値を超えるヒットレコードは検索管理サーバへ送らないので、通信コストが減少する。
【００６６】
なお、図１３では、検索管理サーバと検索サーバとを別々に構成し、ネットワーク（ＬＡＮやＷＡＮ）で接続したが、図３に示すように、検索管理サーバの機能と検索サーバの機能を一体化した場合にも、インデクスごとにスコアでソートを行い、これを連結し、その後、再度スコアでソートして検索結果とすることもできることはもちろんである。
【００６７】
なお、この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。例えば、実施例２の検索装置を図４に示すイントラネット環境に適用できることはもちろんであり、その際記録媒体等を用いて同様のシステムをコンピュータシステムにインストールして構築することもできる。
【符号の説明】
【００６８】
１０      検索部
１１      アクセス制御部
１２      ユーザ権限記憶部
１３      インデクス記憶装置
１４      インデクス
１５      検索ユーザ端末
２０      プロセス起動部
２１      インデクスレコード管理部
２２      インデクスレコード管理プロセス
２３      アクセス制御部
２４      プロセス権限記憶部
３０      インデクス別ヒットレコード数生成部
３１      インデクス選択部
３２      ヒットレコード併合部
３３      ヒットレコード一時記憶部
３４      表示レコード出力部
１００      検索システム
１０１      インデクス保持部
１０２      インデクス構築システム
１０３      文書ファイリングシステム
１０４      ディレクトリサーバ
１０５      ウェブサーバ
１０６      アプリケーションサーバ
１０７      ルータ
１０８      ＬＡＮ
１０９、１１０      記憶媒体
１２０      クライアント端末
１２１      ネットワーク
２００      セキュリティドメイン
３００      検索管理サーバ
３０１      検索サーバ
３０２      インデクス保持部
【図１】
2009163772.tif 000003
【図２】
2009163772.tif 000004
【図３】
2009163772.tif 000005
【図４】
2009163772.tif 000006
【図５】
2009163772.tif 000007
【図６】
2009163772.tif 000008
【図７】
2009163772.tif 000009
【図８】
2009163772.tif 000010
【図９】
2009163772.tif 000011
【図１０】
2009163772.tif 000012
【図１１】
2009163772.tif 000013
【図１２】
2009163772.tif 000014
【図１３】
2009163772.tif 000015
【図１４】
2009163772.tif 000016
【図１５】
2009163772.tif 000017
【図１６】
2009163772.tif 000018