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