検索システム
【課題】複数の検索エンジンから、複数の認証サーバの複数のアカウントから参照権限のある文書を、一度のログインで、一台の検索エンジンのみで、一度にFederated Searchする。
【解決手段】アカウント対応データベースを備えたホストシステムに、複数の検索エンジンが個別に作成したインデックスを再インデクシングする機能を設け、予め全ての検索エンジンのインデックスを作成しておくことで、検索時にはアカウント対応データベースから対応情報を読み出し、対応する全てのアカウント権限で、ホストシステムのみによる検索を行う。
【解決手段】アカウント対応データベースを備えたホストシステムに、複数の検索エンジンが個別に作成したインデックスを再インデクシングする機能を設け、予め全ての検索エンジンのインデックスを作成しておくことで、検索時にはアカウント対応データベースから対応情報を読み出し、対応する全てのアカウント権限で、ホストシステムのみによる検索を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は検索システムに関し、例えば、エンタープライズサーチ、特に複数検索エンジンによるFederated Searchに関するものである。
【背景技術】
【０００２】
近年、一般的な企業では多数の電子文書を扱っているが、その管理と検索に多くの時間を割いている実情があり、思った以上に文書管理にコストが発生している。このため、このようなコストを削減することは今や企業にとって性急な課題となっているのが現状である。
【０００３】
効率的な電子文書管理及び検索するために提案されているエンタープライズサーチは、企業内の文書検索機能を提供する検索実行装置である。これを用いると、所望の文書の検索が比較的高速かつ正確に行えるため、導入する事例が増えている。
【０００４】
ただし、今後、さらなる電子文書の増加に伴い、複数のエンタープライズサーチの検索結果を統合、整理、整列する仕組み（この仕組みをFederated Searchと呼ぶ）が必要となることが予想される。ここで、検索結果を統合するとは、フォーマットの異なる検索結果をあらかじめ決められたルールで統一することであり、整理するとは、同一の検索結果を省略することであり、整列するとは、ユーザによって指定されたオーダーによって検索結果を並び替えることである。
【０００５】
図１は、従来のFederated Searchシステムの概要を示す構成図である。Federated Searchシステムは、認証サーバを登録する認証サーバ管理ＤＢ１０９を備えたホストシステム１０１と、ユーザの認証を行う認証サーバ１０８と、複数の検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎと、電子文書の実際の置き場となる複数のファイルシステム群１０７ａ、１０７ｂ、・・・、１０７ｎから構成される。ホストシステム１０１及び検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎは、ホストシステム１０１に接続されている。ファイルシステム群１０７ａ、１０７ｂ、・・・、１０７ｎは、各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎに接続されている。
【０００６】
ホストシステム１０１は、ユーザのアカウントを処理する認証処理部１０２と、検索の要求・検索結果の統合を行う検索処理部１０３と、を備える。また、各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎは電子文書の検索を行う検索処理部１０５ａ、１０５ｂ、・・・、１０５ｎとファイルシステムのデータを蓄積するインデックス部１０６ａ、１０６ｂ、・・・、１０６ｎとから構成されている。
【０００７】
このようなFederated Searchシステムにおいては、まずホストシステム１０１が、ユーザからユーザの認証情報と検索クエリを受け取ると、認証処理部１０２は登録された認証サーバ１０８で認証を行う。認証に成功すれば、検索処理部１０３がそれぞれの検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎ向けにカスタマイズしたクエリを作成する。このとき、クエリには、検索を実行したユーザの権限情報を含める。ホストシステム１０１はクエリを利用して各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎに検索を要求し、応答を待つ。各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎの検索処理部１０５ａ、１０５ｂ、・・・、１０５ｎでは、クエリに含まれる権限情報から、そのアカウントが参照権限を持つ文書のみを検索対象としてインデックス部１０６ａ、１０６ｂ、・・・、１０６ｎに対し、検索を実行する。検索処理部１０２は各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎの検索結果が出揃ったところで各検索結果を統合し、整理し、整列してユーザに応答を返す。
【０００８】
各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎのインデックス部１０６ａ、１０６ｂ、・・・、１０６ｎでは、定期的にファイルシステムの更新状況を調べ、変更があった場合には、検索用のインデックスを再作成し、検索結果が常に最新となるように努めている。
【０００９】
以上のようなFederated Searchシステムは、例えば、特許文献１にも開示されている。
【００１０】
【特許文献１】特開２００２−２４５０３９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、企業内における文書管理の運用形態として、社内での個人認証が必ずしも一種類の認証サーバのみで成り立っているとは限らない。また、各検索エンジンはFederated Searchのために独占できるものではなく、多くのユーザがさまざまな形で使用することが想定される。
【００１２】
複数の認証サーバを運用する企業においては、一人のユーザが別々の認証サーバに複数のアカウントを持っていて、各ファイルシステムが別々の認証サーバによる参照権限を持っているケースが考えられる。
【００１３】
しかし、従来のFederated Searchでは、ユーザは一度の検索で一つのアカウント参照権限に対する文書しか検索できない。もし、他のアカウントの参照権限に対する文書を検索するとすれば、一度ログアウトして、別のアカウントにログインしなおしてから再度検索を実行しなければならない。
【００１４】
また、従来のFederated Searchにおいては、一度実行する度に、全ての検索エンジンが検索処理を余儀なくされるため、各々の検索エンジンに対する負荷は、検索実行数に比例して大きくなる。
【００１５】
さらに、従来のFederated Searchにおける処理プログラムにとっては、検索結果を得るために、全ての検索エンジンの検索完了を待たなければならない。また、当該処理プログラムは検索の度に検索クエリの作成、結果の統合、整理、整列を行うため、同時に多数の検索が実行される環境ではシステムへの負荷が増大する。
【００１６】
以上のような要因により、本来、高速な検索を提供すべきエンタープライズサーチの利点が損なわれてしまっているのが現状である。
【００１７】
本発明はこのような状況に鑑みてなされたものであり、ユーザにとって使い勝手が良く、検索エンジンの負荷を削減することのできるFederated Searchを提供するものである。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、本発明では、複数の認証サーバにおける複数のアカウントを統合するテーブルを設け、あらかじめ認証を行ったアカウントの情報をテーブルに保存しておき、以後、いずれかひとつのアカウントで認証を行うだけで、対応する全てのアカウントの権限を伴った検索が行うようにしている。
【００１９】
また、本発明は、検索エンジン内を定期的に巡回する専用のクローラと、巡回した結果得られた文書のメタデータのＸＭＬファイルを、統一フォーマットに変換し、再インデックシングを行う。そして、検索時には、実際の各検索エンジンにおいてその都度検索するのではなく、各検索エンジンから集約したインデックス情報に対してのみ検索を実行することによって、登録された全ての検索エンジンによるFederated Searchを行うようにしている。
【００２０】
即ち、本発明による検索システムは、ホストコンピュータと、複数の認証サーバと、複数のファイルシステム群の少なくとも１つにそれぞれ接続された複数の検索エンジンと、を備える。そして、ホストコンピュータは、検索を実行するユーザについて、複数の認証サーバについての認証処理を行う認証処理部と、検索を実行するユーザの検索要求に基づいて、複数の検索エンジンから取得した複数のファイルシステム群のインデックス情報に対して検索処理を実行する検索処理部と、を有する。さらに、認証処理部は、全登録ユーザが有する複数の認証サーバのアカウント情報を管理する管理情報に基づいて、検索を実行するユーザのログイン時に、当該ユーザがアカウントを有する全ての認証サーバを特定し、検索処理部は、特定された認証サーバと関連付けられたファイルシステム群に対応するインデックス情報に対して検索処理を実行する。
【００２１】
ホストコンピュータは、さらに、複数のファイルシステム群のインデックス情報をまとめて格納するインデックス部を備える。
【００２２】
複数の検索エンジンのそれぞれは、対応するファイルシステム群のインデックス情報を任意のタイミングで更新して更新インデックス情報を生成する。そして、インデックス部は、検索エンジンに対して更新インデックス情報の送信を指示するクローラを送信し、このクローラに応答して検索エンジンが返信した更新インデックス情報を用いて、インデックス部が保持するインデックス情報を更新する。
【００２３】
インデックス部は、統一フォーマットで生成されたインデックス情報を保持している。複数の検索エンジンが統一フォーマットと異なるフォーマットで更新インデックス情報を保持する場合には、インデックス部及び該当する検索エンジンの何れか一方で統一フォーマットの更新インデックス情報に変換されるようになっている。
【００２４】
さらに、インデックス部は、複数の検索エンジンにおけるインデックス情報の更新履歴を管理する検索エンジン管理情報を参照し、最も古い更新インデックス情報を有する検索エンジン、或いはインデックス情報を更新したことがない検索エンジンを特定し、特定された検索エンジンに対してクローラを送信する。
【００２５】
さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。
【発明の効果】
【００２６】
本発明のFederated Searchを用いれば、ユーザは一回のログインだけで、自分が有する全てのアカウントによるアクセス権限を行使することができるので使い勝手が良く、また、検索エンジンにも負荷を掛けることなく検索を実行することができるようになる。
【発明を実施するための最良の形態】
【００２７】
以下、添付図面を参照して本発明の実施形態に係る統合エンタープライズサーチシステム（検索システム）について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
【００２８】
まず統合エンタープライズサーチシステム等の構成を説明し、その後フローチャートを用いてその動作について説明する。
【００２９】
＜システム構成＞
図２は、本実施形態による統合エンタープライズサーチシステム（検索システム）の概略構成を示すブロック図である。
当該統合エンタープライズサーチシステムは、認証サーバ管理ＤＢ９とアカウント対応管理ＤＢ１０と検索エンジン管理ＤＢ７を有するホストシステム１と、ホストシステム１に接続された複数のエンタープライズサーチ用検索エンジン５ａ、５ｂ、・・・、５ｎと、その検索エンジンに接続されたファイルシステム群６ａ、６ｂ、・・・、６ｎと、ホストシステム１及びファイルシステム群６ａ、６ｂ、・・・、６ｎの各ファイルシステムの双方に接続された認証サーバ群８ａ、８ｂ、・・・、８ｍと、を備えている。
【００３０】
ホストシステム１は、主に認証に関する処理を行う認証処理部２と、検索に関する処理を行う検索処理部３と、クローラを発行して各ファイルシステム群からメタデータを取得し、インデックシング処理を行うインデックス部４と、を含んでいる。発行されたクローラは検索エンジン５ａ〜５ｎに送られる。クローラを受け取った検索エンジン５ａ〜５ｎは、各ファイルシステムのインデックス情報のメタデータをインデックス部４に返信する（詳細は後述する）。
【００３１】
検索対象となる電子文書は、実際にはファイルシステム群６ａ、６ｂ、・・・、６ｎに置かれている。各検索エンジン５ａ、５ｂ、・・・、５ｎは、例えばＮＦＳやＣＩＦＳといったファイル共有プロトコルによるアクセス権限に基づき、文書を共有している。
【００３２】
各検索エンジンでは、ホストシステム１のインデックス部４とは別に、個別にファイルシステムのインデックシング処理を行い、検索情報が常に最新に保たれるようにしている。なお、インデックシング処理する情報としては、単に文書名、容量などの基本的な情報だけでなく、ファイル共有プロトコルのアクセス制御リスト（ＡＣＬ：Access Control List）が含まれる。検索処理部３はＡＣＬ情報により、アクセス権限を付加した文書検索を実現する。
【００３３】
検索エンジン管理ＤＢ７は、各検索エンジンの登録情報（図５参照）を保存している。ホストシステム１のインデックス部４は、検索エンジン管理ＤＢ７の情報を基にクローリングする検索エンジンを決定する。
【００３４】
また、認証サーバ管理ＤＢ９は、アカウントの管理を行う複数の認証サーバ８ａ、８ｂ、・・・、８ｍの接続に関する情報（図３参照）を保存している。ここで、認証サーバとしては、例えばＮＩＳサーバ、ＬＤＡＰサーバといったものが挙げられる。上述したファイルシステム群６ａ、６ｂ、・・・、６ｎのファイル共有プロトコルのＡＣＬは、これら認証サーバのアカウントによって作成されている。
【００３５】
アカウント対応管理ＤＢ１０は、複数の認証サーバのアカウント情報の対応付けを行うための情報（認証サーバ、ユーザ、及びユーザアカウントの対応関係を示す（図４参照））を保存している。ユーザは検索を行う前に、あらかじめ自分の持つ全てのアカウント情報を対応付けておく。対応付けの処理は図７のフローチャートを用いて後述される。この対応情報はアカウント対応管理ＤＢ１０に保存され、検索の際に呼び出される。ユーザは対応に属するいずれか一つのアカウントでログインを行って検索を実行する。すると、ホストシステム１の認証処理部２がこの対応を取得し、対応に属する全てのアカウントの権限で検索を行う。
【００３６】
＜認証サーバ管理ＤＢのデータ構造＞
図３は、認証サーバ管理ＤＢ９のデータ構造の一例を示す図である。
図３において、認証サーバＩＤカラム２１は認証サーバを一意に識別する値であり、例えばＩＰアドレスやホスト名といったものが挙げられる。認証サーバの種別カラム２２にはその名の通り、認証サーバの種別が登録される。認証サーバには、例えばMicrosoft社のActive Directory（登録商標）やOpenLDAPといったものがあり、ホストシステム１の認証処理部２が、これらとの通信手段をサポートしている。
【００３７】
管理者ＩＤカラム２３及び管理パスワードカラム２４はそれぞれ、各認証サーバの管理者のＩＤとパスワードを格納するカラムで、認証処理部２が認証サーバにログインする際に用いるものである。
【００３８】
＜アカウント対応管理ＤＢのデータ構造＞
図４は、アカウント対応管理ＤＢ１０のデータ構造の一例を示す図である。
図４において、対応ＩＤカラム３１は一つ一つの対応を管理する番号であり、同じ対応に属するアカウント（認証ユーザＩＤ３３）には同じ対応ＩＤが振られる。なんらかの対応に属するアカウントでログインし、検索を行った結果には、そのアカウントと同じ対応ＩＤを持つ全てのアカウント権限が反映される。例えば、認証サーバ１に属するユーザ１（アカウント１）と、認証サーバ２に属するユーザ２（アカウント２）が同一の対応ＩＤ１をもつ場合、ユーザ１でログインして、検索を行った結果は、ユーザ２の参照可能なファイルもヒットする。
【００３９】
認証サーバＩＤカラム３２には認証サーバを識別する値（例えばＩＰアドレスや、ホスト名）が格納される。認証ユーザーＩＤカラム３３には該当する認証サーバが持つ認証ＩＤが格納される。
【００４０】
一つの行は一つの対応に含まれるアカウントを表しており、初回ログインを行ったアカウントが他の認証サーバからアカウントを追加する場合に生成され、同じアカウントが異なる対応に同時に属することはない。
【００４１】
＜検索エンジン管理ＤＢのデータ構造＞
図５は、検索エンジン管理ＤＢ７のデータ構造の一例を示す図である。
図５において、検索エンジンＩＤカラム４１は検索エンジンを一意に識別する値であり、例えばＩＰアドレスやホスト名といったものが想定される。
【００４２】
最終インデックス日時カラム４２には、ホストシステム１のインデックス部４によって最後にインデックスされた日時が格納される。
【００４３】
また、フォーマット変換ＸＳＬＴカラム４３には、各検索エンジン固有のメタデータのＸＭＬを統一フォーマットのメタデータＸＭＬに変更するためのＸＳＬＴコードが格納される。ホストシステム１のインデックス部４がＸＳＬＴコードを含むクローラを発行し、これが各検索エンジンに順次派遣される。クローラを受け取った各検索エンジンにおけるインデックス部５３（図６参照）は、クローラに含まれるＸＳＬＴコードを使用し、検索エンジン固有のメタデータＸＭＬを統一フォーマットのＸＭＬに変換する。なお、ＸＳＬＴコードは管理者が作成し、検索エンジンを検索エンジン管理ＤＢに登録するときに、同時に登録される。
【００４４】
＜検索エンジンの内部構成＞
図６は、図２における検索エンジン５ａ、５ｂ、・・・、５ｎの詳細な内部構成を示す図である。
検索エンジン５１は一般的なエンタープライズ検索エンジンであり、主に検索処理を行う検索処理部５２と、主にインデックシング処理を行うインデックス部５３を備えている。
【００４５】
検索エンジン５１はファイルシステム群５４の各ファイルシステム５４ａ、５４ｂ、５４ｃ、・・・、５４ｒと接続されている。各ファイルシステムは、認証サーバ５５の各認証サーバ５５ａ、５５ｂ、・・・、５５ｍのいずれかと関連付けられている。なお、一つのファイルシステムに関連付けられる認証サーバは複数あってもよい。例えば、ファイルシステム５４ｂには、認証サーバ５５ａと５５ｂが関連付けられていてもよい。このとき、ファイルシステム５４ｂのアクセス権限は、認証サーバ５５ａからログインしたときには認証サーバ５５ａのＡＣＬに従い、認証サーバ５５ｂからログインしたときには、認証サーバ５５ｂのＡＣＬに従う。
【００４６】
検索エンジン５１のインデックス部５３は、ファイルシステム群５４に対し各ファイルシステムの更新状況に応じて定期的にクローリング処理を実施する。そして、クローリング処理の結果得られた文書のメタデータは、インデックス部５３によって順次インデックシングされる。インデックシングされるメタデータには、文書の名称やパス、サイズといった一般的な属性のほか、認証サーバのＡＣＬが含まれる。
【００４７】
各検索エンジンが個別に行うインデックシング処理とは別に、ホストシステム１のインデックス部４も、登録された各検索エンジンに関して、定期的にインデックス情報の更新を行っている。インデックス部４から各検索エンジンにクローラが派遣されると、各検索エンジンのインデックス部５３は、蓄積されたインデックスの差分のメタデータをＸＭＬ形式でホストシステム１のインデックス部４に譲り渡す。このとき譲り渡されたメタデータは、インデックス部４においてそのままの形でインデックシング処理できるとは限らない。なぜなら、各検索エンジンによってメタデータの名称やインデックスする項目はまちまちだからである。そこで、クローラを受け取ると、各検索エンジンのインデックス部５３は、メタデータのＸＭＬを検索エンジンごとに登録されたＸＳＬＴで変換し、ホストシステム１のインデックス部４で解釈できる形式に変更する。このＸＳＬＴは、検索エンジンをシステムに登録する際に、同時に検索エンジン管理ＤＢに登録しておく。そして、クローラには、それを派遣する各検索エンジンのＸＳＬＴの情報が含まれている。
【００４８】
＜アカウント対応作成処理＞
図７は、複数認証サーバにおけるアカウント対応作成処理の概要を説明するためのフローチャートである。
まず、認証処理部２はユーザがメインのアカウントでログイン後、その求めに応じてアカウント対応追加画面を表示する（ステップＳ１０１）。この画面には現在システムに登録されている認証サーバの一覧と、認証ＩＤ（アカウントＩＤ）とパスワードの入力欄がある。
【００４９】
ユーザが自身のアカウント対応に新たにアカウントを追加することを指示した場合（ステップＳ１０２）、認証処理部２は、入力欄に、自分の所持するアカウントのうちログインに使用したもの以外のアカウント情報の入力をユーザに促し、その入力を受け付ける（ステップＳ１０３）。
【００５０】
次に、認証処理部２は、ユーザの入力情報をもとに該当する認証サーバに認証を問い合わせる（ステップＳ１０４）。認証が成功すれば（ステップＳ１０５）、認証処理部２は、当該アカウントをログインに使用したユーザと同じ対応ＩＤで保存する（ステップＳ１０６）。認証に失敗したときには当該アカウントは保存されない。以上の処理が繰り返される。
【００５１】
なお、ログインに使用したユーザ自身のＤＢ内のレコードは、初回ログイン時に自動で作成され、対応ＩＤも未使用のものから自動で採番される。
【００５２】
＜ログインから検索までの処理＞
図７は、統合エンタープライズサーチにおけるログインから検索までの処理の流れを説明するためのフローチャートである。
ホストシステム１がユーザのログイン（ステップＳ２０１）及び検索条件の入力を受け付けると（ステップＳ２０２）、認証処理部２はユーザのログインアカウントの認証サーバＩＤと認証ＩＤから、アカウント対応管理ＤＢ１０に対し、対応表を問い合わせし、同じユーザがアクセス権限を有する認証サーバの情報（認証サーバＩＤ）を取得する（ステップＳ２０３）。この時点では、ログインした認証サーバのみに接続されている状態である。
【００５３】
続いて、認証処理部２は、対応表の認証サーバＩＤを基に、認証サーバ管理ＤＢ９に認証サーバへの接続情報を問い合わせる（ステップＳ２０４）。
【００５４】
そして、対応する認証サーバとの接続後、認証処理部２は、アカウントの認証ＩＤからアカウントの権限情報を引き出す（ステップＳ２０５）。権限情報としては、例えば個体識別情報（ＵＩＤ）やグループ識別情報（ＧＩＤ）がある。この段階で、当該ユーザがアカウントを有する全ての認証サーバにアクセス可能な状態となる。
【００５５】
最後に、検索処理部３は、得られた各アカウントの権限情報を検索クエリに埋め込んで、インデックス部４に対して検索を実行する（ステップＳ２０６）。
【００５６】
＜インデックシング処理＞
図９はホストシステム１のインデックス部４におけるインデックシング処理を説明するためのフローチャートである。
インデックス部４は、定期的に検索エンジン管理ＤＢ７の最終インデックス日時を参照する（ステップＳ３０１）。そして、インデックス部４は、インデックスが過去一度も更新されていないか否かチェックする（ステップＳ３０２）。過去にインデックシング処理されたことがある場合には処理はステップＳ３０４に移行し、されたことが無ければ処理はステップＳ３０６に移行する。
【００５７】
また、インデックス部４は、処理中の検索エンジンが検索エンジンの中で最も長い間更新されていないものか否かを判定する（ステップＳ３０４）。最も長い間更新されていないものであれば、処理はステップＳ３０６に移行し、そうでなければ処理はステップＳ３０１に移行する。
【００５８】
そして、インデックス部４は、該当する検索エンジンにクローラを派遣する（ステップＳ３０５）。なお、クローラの派遣に必要なＩＰアドレスなどの検索エンジンへの接続情報は、全て検索エンジン管理ＤＢに保存されている。また、クローラには最終インデックス履歴の情報が含まれている。
【００５９】
派遣先の検索エンジンのインデックス部５３は、そのクローラを取得し、クローラに含まれるインデックス履歴に基づいて、検索エンジン内のインデックスが前回のクローラ派遣時から更新されたか否か判断する（ステップＳ３０６）。この判断結果はインデックス部５３からインデックス部４に通知される。
【００６０】
前回からの更新がなければ（ステップＳ３０７）、インデックス部４は、検索エンジン管理ＤＢ７の最終インデックス日時を更新して終了する（ステップＳ３１１）。一方、更新があれば（ステップＳ３０７）、インデックス部４は、インデックス部５３から更新インデックス部分の差分メタデータをＸＭＬ形式で受け取る（ステップＳ３０８）。さらに、インデックス部４は、検索エンジン管理ＤＢ７から取得したフォーマット変換ＸＳＬＴファイル（コード）に基づいて、更新インデックス部分の差分メタデータのＸＭＬファイルを統一フォーマットのＸＭＬファイルに変換する（ステップＳ３０９）。
【００６１】
続いて、インデックス部４は、新たに取得した統一フォーマットのＸＭＬファイルのメタデータを用いて再インデックシング処理を行う（ステップ３１０）。
【００６２】
そして、再インデクシング完了後、ステップＳ３０７でＮＯの場合、或いは、ステップＳ３０４でＮＯの場合、インデックス部４は、検索エンジン管理ＤＢ７の最終インデックス日時を更新する（ステップ８１１）。
【００６３】
なお、図９の処理では、インデックス部４が差分メタデータを統一フォーマットのＸＭＬファイルに変換しているが、クローラを受け取った各検索エンジンのインデックス部５３が統一フォーマットのＸＭＬに変換後、差分メタデータをホストシステム１のインデックス部４に送信するようにしてもよい。その場合には、クローラには各検索エンジンのフォーマット変換ＸＳＬＴファイルが含まれるようにするか、別の方法でフォーマット変換ＸＳＬＴファイルを通知する必要がある。
【００６４】
＜変換前後のＸＭＬ＞
図１０は、検索エンジンから得たメタデータのＸＭＬ（変換前）と、それを変換ＸＳＬＴコードにより再インデクシング可能な統一的なファイルに変換して得られたＸＭＬ（変換後）の例を示す図である。
【００６５】
検索エンジン固有のメタデータのＸＭＬ９１は、具体的な文書を、ある検索エンジンでクローリングした結果得られたメタデータのＸＭＬを表す。また、再インデクシング用に変換されたメタデータのＸＭＬ９２は、検索エンジン固有の上記ＸＳＬＴコードにより変換されたＸＭＬを表している。
【００６６】
この例では、文書「２００７年度決算報告．ｐｄｆ」のメタデータとして、ファイル名、ファイルパス、容量、変更日時、内容、ファイルのオーナー…などの情報がＸＭＬ形式で表示されている。検索エンジン固有のメタデータのＸＭＬ９１では、それぞれのメタデータはfilename、filepath、date、content、owner・・・という要素の内容になっているが、各要素名は検索エンジン固有のものであるので、ホストシステム１のインデックス部４がこのＸＭＬを正しく解釈しインデクシングを実行できる保証は無い。これは、例えばファイル名に相当するものがfilename要素の内容であるとインデックス部４が判断できないためである。
【００６７】
変換後のＸＭＬ９２は、ホストシステム１のインデックス部４がインデクシング可能な形のメタデータのＸＭＬである。インデックス部４は、このファイルを基に検索エンジンインデックスの再インデックシング処理を行うことができる。
【００６８】
＜まとめ＞
本実施形態では、全登録ユーザが有する複数の認証サーバのアカウント情報を管理する管理情報に基づいて、ログイン時に、ログインユーザがアカウントを有する全ての認証サーバを特定し、特定された認証サーバと関連付けられたファイルシステム群に対応するインデックス情報に対して検索処理を実行する。これにより、一度のログインであらかじめ対応付けられた全てのアカウントが参照権限を持つ文書を検索することが可能となる。従って、ユーザにとっては、他のアカウントで再ログインのうえ、再検索を行う手間を省略することが可能となる。
【００６９】
また、複数のファイルシステム群のインデックス情報を一箇所にまとめて管理している。これにより、ホストコンピュータが、検索処理の度に、各検索エンジンからそれぞれの検索結果を取得する必要がなく、システムの負荷を軽減することができるようになる。また、各検索エンジンの検索待ち時間を省略することが可能となる。
【００７０】
複数の検索エンジンのそれぞれは、対応するファイルシステム群のインデックス情報を任意のタイミングで更新して更新インデックス情報を生成する。そして、ホストコンピュータ（インデックス部）から、検索エンジンに対して更新インデックス情報の送信を指示するクローラを送信し、このクローラに応答して検索エンジンが返信した更新インデックス情報を用いて、インデックス部が保持するインデックス情報を更新する。これにより、インデックス情報の更新も効率的に実行することができるようになる。
【００７１】
なお、ホストコンピュータ（インデックス部）は、統一フォーマットで生成されたインデックス情報を保持している。複数の検索エンジンが統一フォーマットと異なるフォーマットで更新インデックス情報を保持する場合には、インデックス部及び該当する検索エンジンの何れか一方で統一フォーマットの更新インデックス情報に変換されるようになっている。これにより、検索の度に、各検索エンジンの検索結果を統合し、整理し、整列する作業を省略することができるようになるので、システムの負荷を軽減することができる。
【００７２】
さらに、インデックス部は、複数の検索エンジンにおけるインデックス情報の更新履歴を管理する検索エンジン管理情報を参照し、最も古い更新インデックス情報を有する検索エンジン、或いはインデックス情報を更新したことがない検索エンジンを特定し、特定された検索エンジンに対してクローラを送信する。
【００７３】
なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００７４】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【００７５】
また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【図面の簡単な説明】
【００７６】
【図１】従来のＦｅｄｅｒａｔｅｄ Ｓｅａｒｃｈシステムの概略構成図である。
【図２】本発明の実施形態に係る統合エンタープライズサーチシステムの概略構成を示すブロック図である。
【図３】認証サーバ管理ＤＢのデータ構造の一例を示す図である。
【図４】アカウント対応管理ＤＢのデータ構造の一例を示す図である。
【図５】検索エンジン管理ＤＢのデータ構造の一例を示す図である。
【図６】検索エンジンの内部構成図である。
【図７】認証処理部の行うアカウント対応作成手順を示すフローチャートである。
【図８】統合エンタープライズサーチにおけるログイン後から検索までの手順を示すフローチャートである。
【図９】インデックス部の行うインデックス作成手順を示すフローチャートである。
【図１０】ＸＳＬＴによるメタデータＸＭＬの変換の一例を示す図である。
【符号の説明】
【００７７】
１・・・ホストシステム、２・・・認証処理部、３・・・検索処理部、４・・・インデックス部、５ａ乃至５ｎ・・・検索エンジン、６ａ乃至６ｎ・・・ファイルシステム群、７・・・検索エンジン管理ＤＢ、８ａ乃至８ｍ・・・認証サーバ、９・・・認証サーバ管理ＤＢ、１０・・・アカウント対応管理ＤＢ
【技術分野】
【０００１】
本発明は検索システムに関し、例えば、エンタープライズサーチ、特に複数検索エンジンによるFederated Searchに関するものである。
【背景技術】
【０００２】
近年、一般的な企業では多数の電子文書を扱っているが、その管理と検索に多くの時間を割いている実情があり、思った以上に文書管理にコストが発生している。このため、このようなコストを削減することは今や企業にとって性急な課題となっているのが現状である。
【０００３】
効率的な電子文書管理及び検索するために提案されているエンタープライズサーチは、企業内の文書検索機能を提供する検索実行装置である。これを用いると、所望の文書の検索が比較的高速かつ正確に行えるため、導入する事例が増えている。
【０００４】
ただし、今後、さらなる電子文書の増加に伴い、複数のエンタープライズサーチの検索結果を統合、整理、整列する仕組み（この仕組みをFederated Searchと呼ぶ）が必要となることが予想される。ここで、検索結果を統合するとは、フォーマットの異なる検索結果をあらかじめ決められたルールで統一することであり、整理するとは、同一の検索結果を省略することであり、整列するとは、ユーザによって指定されたオーダーによって検索結果を並び替えることである。
【０００５】
図１は、従来のFederated Searchシステムの概要を示す構成図である。Federated Searchシステムは、認証サーバを登録する認証サーバ管理ＤＢ１０９を備えたホストシステム１０１と、ユーザの認証を行う認証サーバ１０８と、複数の検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎと、電子文書の実際の置き場となる複数のファイルシステム群１０７ａ、１０７ｂ、・・・、１０７ｎから構成される。ホストシステム１０１及び検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎは、ホストシステム１０１に接続されている。ファイルシステム群１０７ａ、１０７ｂ、・・・、１０７ｎは、各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎに接続されている。
【０００６】
ホストシステム１０１は、ユーザのアカウントを処理する認証処理部１０２と、検索の要求・検索結果の統合を行う検索処理部１０３と、を備える。また、各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎは電子文書の検索を行う検索処理部１０５ａ、１０５ｂ、・・・、１０５ｎとファイルシステムのデータを蓄積するインデックス部１０６ａ、１０６ｂ、・・・、１０６ｎとから構成されている。
【０００７】
このようなFederated Searchシステムにおいては、まずホストシステム１０１が、ユーザからユーザの認証情報と検索クエリを受け取ると、認証処理部１０２は登録された認証サーバ１０８で認証を行う。認証に成功すれば、検索処理部１０３がそれぞれの検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎ向けにカスタマイズしたクエリを作成する。このとき、クエリには、検索を実行したユーザの権限情報を含める。ホストシステム１０１はクエリを利用して各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎに検索を要求し、応答を待つ。各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎの検索処理部１０５ａ、１０５ｂ、・・・、１０５ｎでは、クエリに含まれる権限情報から、そのアカウントが参照権限を持つ文書のみを検索対象としてインデックス部１０６ａ、１０６ｂ、・・・、１０６ｎに対し、検索を実行する。検索処理部１０２は各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎの検索結果が出揃ったところで各検索結果を統合し、整理し、整列してユーザに応答を返す。
【０００８】
各検索エンジン１０４ａ、１０４ｂ、・・・、１０４ｎのインデックス部１０６ａ、１０６ｂ、・・・、１０６ｎでは、定期的にファイルシステムの更新状況を調べ、変更があった場合には、検索用のインデックスを再作成し、検索結果が常に最新となるように努めている。
【０００９】
以上のようなFederated Searchシステムは、例えば、特許文献１にも開示されている。
【００１０】
【特許文献１】特開２００２−２４５０３９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、企業内における文書管理の運用形態として、社内での個人認証が必ずしも一種類の認証サーバのみで成り立っているとは限らない。また、各検索エンジンはFederated Searchのために独占できるものではなく、多くのユーザがさまざまな形で使用することが想定される。
【００１２】
複数の認証サーバを運用する企業においては、一人のユーザが別々の認証サーバに複数のアカウントを持っていて、各ファイルシステムが別々の認証サーバによる参照権限を持っているケースが考えられる。
【００１３】
しかし、従来のFederated Searchでは、ユーザは一度の検索で一つのアカウント参照権限に対する文書しか検索できない。もし、他のアカウントの参照権限に対する文書を検索するとすれば、一度ログアウトして、別のアカウントにログインしなおしてから再度検索を実行しなければならない。
【００１４】
また、従来のFederated Searchにおいては、一度実行する度に、全ての検索エンジンが検索処理を余儀なくされるため、各々の検索エンジンに対する負荷は、検索実行数に比例して大きくなる。
【００１５】
さらに、従来のFederated Searchにおける処理プログラムにとっては、検索結果を得るために、全ての検索エンジンの検索完了を待たなければならない。また、当該処理プログラムは検索の度に検索クエリの作成、結果の統合、整理、整列を行うため、同時に多数の検索が実行される環境ではシステムへの負荷が増大する。
【００１６】
以上のような要因により、本来、高速な検索を提供すべきエンタープライズサーチの利点が損なわれてしまっているのが現状である。
【００１７】
本発明はこのような状況に鑑みてなされたものであり、ユーザにとって使い勝手が良く、検索エンジンの負荷を削減することのできるFederated Searchを提供するものである。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、本発明では、複数の認証サーバにおける複数のアカウントを統合するテーブルを設け、あらかじめ認証を行ったアカウントの情報をテーブルに保存しておき、以後、いずれかひとつのアカウントで認証を行うだけで、対応する全てのアカウントの権限を伴った検索が行うようにしている。
【００１９】
また、本発明は、検索エンジン内を定期的に巡回する専用のクローラと、巡回した結果得られた文書のメタデータのＸＭＬファイルを、統一フォーマットに変換し、再インデックシングを行う。そして、検索時には、実際の各検索エンジンにおいてその都度検索するのではなく、各検索エンジンから集約したインデックス情報に対してのみ検索を実行することによって、登録された全ての検索エンジンによるFederated Searchを行うようにしている。
【００２０】
即ち、本発明による検索システムは、ホストコンピュータと、複数の認証サーバと、複数のファイルシステム群の少なくとも１つにそれぞれ接続された複数の検索エンジンと、を備える。そして、ホストコンピュータは、検索を実行するユーザについて、複数の認証サーバについての認証処理を行う認証処理部と、検索を実行するユーザの検索要求に基づいて、複数の検索エンジンから取得した複数のファイルシステム群のインデックス情報に対して検索処理を実行する検索処理部と、を有する。さらに、認証処理部は、全登録ユーザが有する複数の認証サーバのアカウント情報を管理する管理情報に基づいて、検索を実行するユーザのログイン時に、当該ユーザがアカウントを有する全ての認証サーバを特定し、検索処理部は、特定された認証サーバと関連付けられたファイルシステム群に対応するインデックス情報に対して検索処理を実行する。
【００２１】
ホストコンピュータは、さらに、複数のファイルシステム群のインデックス情報をまとめて格納するインデックス部を備える。
【００２２】
複数の検索エンジンのそれぞれは、対応するファイルシステム群のインデックス情報を任意のタイミングで更新して更新インデックス情報を生成する。そして、インデックス部は、検索エンジンに対して更新インデックス情報の送信を指示するクローラを送信し、このクローラに応答して検索エンジンが返信した更新インデックス情報を用いて、インデックス部が保持するインデックス情報を更新する。
【００２３】
インデックス部は、統一フォーマットで生成されたインデックス情報を保持している。複数の検索エンジンが統一フォーマットと異なるフォーマットで更新インデックス情報を保持する場合には、インデックス部及び該当する検索エンジンの何れか一方で統一フォーマットの更新インデックス情報に変換されるようになっている。
【００２４】
さらに、インデックス部は、複数の検索エンジンにおけるインデックス情報の更新履歴を管理する検索エンジン管理情報を参照し、最も古い更新インデックス情報を有する検索エンジン、或いはインデックス情報を更新したことがない検索エンジンを特定し、特定された検索エンジンに対してクローラを送信する。
【００２５】
さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。
【発明の効果】
【００２６】
本発明のFederated Searchを用いれば、ユーザは一回のログインだけで、自分が有する全てのアカウントによるアクセス権限を行使することができるので使い勝手が良く、また、検索エンジンにも負荷を掛けることなく検索を実行することができるようになる。
【発明を実施するための最良の形態】
【００２７】
以下、添付図面を参照して本発明の実施形態に係る統合エンタープライズサーチシステム（検索システム）について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
【００２８】
まず統合エンタープライズサーチシステム等の構成を説明し、その後フローチャートを用いてその動作について説明する。
【００２９】
＜システム構成＞
図２は、本実施形態による統合エンタープライズサーチシステム（検索システム）の概略構成を示すブロック図である。
当該統合エンタープライズサーチシステムは、認証サーバ管理ＤＢ９とアカウント対応管理ＤＢ１０と検索エンジン管理ＤＢ７を有するホストシステム１と、ホストシステム１に接続された複数のエンタープライズサーチ用検索エンジン５ａ、５ｂ、・・・、５ｎと、その検索エンジンに接続されたファイルシステム群６ａ、６ｂ、・・・、６ｎと、ホストシステム１及びファイルシステム群６ａ、６ｂ、・・・、６ｎの各ファイルシステムの双方に接続された認証サーバ群８ａ、８ｂ、・・・、８ｍと、を備えている。
【００３０】
ホストシステム１は、主に認証に関する処理を行う認証処理部２と、検索に関する処理を行う検索処理部３と、クローラを発行して各ファイルシステム群からメタデータを取得し、インデックシング処理を行うインデックス部４と、を含んでいる。発行されたクローラは検索エンジン５ａ〜５ｎに送られる。クローラを受け取った検索エンジン５ａ〜５ｎは、各ファイルシステムのインデックス情報のメタデータをインデックス部４に返信する（詳細は後述する）。
【００３１】
検索対象となる電子文書は、実際にはファイルシステム群６ａ、６ｂ、・・・、６ｎに置かれている。各検索エンジン５ａ、５ｂ、・・・、５ｎは、例えばＮＦＳやＣＩＦＳといったファイル共有プロトコルによるアクセス権限に基づき、文書を共有している。
【００３２】
各検索エンジンでは、ホストシステム１のインデックス部４とは別に、個別にファイルシステムのインデックシング処理を行い、検索情報が常に最新に保たれるようにしている。なお、インデックシング処理する情報としては、単に文書名、容量などの基本的な情報だけでなく、ファイル共有プロトコルのアクセス制御リスト（ＡＣＬ：Access Control List）が含まれる。検索処理部３はＡＣＬ情報により、アクセス権限を付加した文書検索を実現する。
【００３３】
検索エンジン管理ＤＢ７は、各検索エンジンの登録情報（図５参照）を保存している。ホストシステム１のインデックス部４は、検索エンジン管理ＤＢ７の情報を基にクローリングする検索エンジンを決定する。
【００３４】
また、認証サーバ管理ＤＢ９は、アカウントの管理を行う複数の認証サーバ８ａ、８ｂ、・・・、８ｍの接続に関する情報（図３参照）を保存している。ここで、認証サーバとしては、例えばＮＩＳサーバ、ＬＤＡＰサーバといったものが挙げられる。上述したファイルシステム群６ａ、６ｂ、・・・、６ｎのファイル共有プロトコルのＡＣＬは、これら認証サーバのアカウントによって作成されている。
【００３５】
アカウント対応管理ＤＢ１０は、複数の認証サーバのアカウント情報の対応付けを行うための情報（認証サーバ、ユーザ、及びユーザアカウントの対応関係を示す（図４参照））を保存している。ユーザは検索を行う前に、あらかじめ自分の持つ全てのアカウント情報を対応付けておく。対応付けの処理は図７のフローチャートを用いて後述される。この対応情報はアカウント対応管理ＤＢ１０に保存され、検索の際に呼び出される。ユーザは対応に属するいずれか一つのアカウントでログインを行って検索を実行する。すると、ホストシステム１の認証処理部２がこの対応を取得し、対応に属する全てのアカウントの権限で検索を行う。
【００３６】
＜認証サーバ管理ＤＢのデータ構造＞
図３は、認証サーバ管理ＤＢ９のデータ構造の一例を示す図である。
図３において、認証サーバＩＤカラム２１は認証サーバを一意に識別する値であり、例えばＩＰアドレスやホスト名といったものが挙げられる。認証サーバの種別カラム２２にはその名の通り、認証サーバの種別が登録される。認証サーバには、例えばMicrosoft社のActive Directory（登録商標）やOpenLDAPといったものがあり、ホストシステム１の認証処理部２が、これらとの通信手段をサポートしている。
【００３７】
管理者ＩＤカラム２３及び管理パスワードカラム２４はそれぞれ、各認証サーバの管理者のＩＤとパスワードを格納するカラムで、認証処理部２が認証サーバにログインする際に用いるものである。
【００３８】
＜アカウント対応管理ＤＢのデータ構造＞
図４は、アカウント対応管理ＤＢ１０のデータ構造の一例を示す図である。
図４において、対応ＩＤカラム３１は一つ一つの対応を管理する番号であり、同じ対応に属するアカウント（認証ユーザＩＤ３３）には同じ対応ＩＤが振られる。なんらかの対応に属するアカウントでログインし、検索を行った結果には、そのアカウントと同じ対応ＩＤを持つ全てのアカウント権限が反映される。例えば、認証サーバ１に属するユーザ１（アカウント１）と、認証サーバ２に属するユーザ２（アカウント２）が同一の対応ＩＤ１をもつ場合、ユーザ１でログインして、検索を行った結果は、ユーザ２の参照可能なファイルもヒットする。
【００３９】
認証サーバＩＤカラム３２には認証サーバを識別する値（例えばＩＰアドレスや、ホスト名）が格納される。認証ユーザーＩＤカラム３３には該当する認証サーバが持つ認証ＩＤが格納される。
【００４０】
一つの行は一つの対応に含まれるアカウントを表しており、初回ログインを行ったアカウントが他の認証サーバからアカウントを追加する場合に生成され、同じアカウントが異なる対応に同時に属することはない。
【００４１】
＜検索エンジン管理ＤＢのデータ構造＞
図５は、検索エンジン管理ＤＢ７のデータ構造の一例を示す図である。
図５において、検索エンジンＩＤカラム４１は検索エンジンを一意に識別する値であり、例えばＩＰアドレスやホスト名といったものが想定される。
【００４２】
最終インデックス日時カラム４２には、ホストシステム１のインデックス部４によって最後にインデックスされた日時が格納される。
【００４３】
また、フォーマット変換ＸＳＬＴカラム４３には、各検索エンジン固有のメタデータのＸＭＬを統一フォーマットのメタデータＸＭＬに変更するためのＸＳＬＴコードが格納される。ホストシステム１のインデックス部４がＸＳＬＴコードを含むクローラを発行し、これが各検索エンジンに順次派遣される。クローラを受け取った各検索エンジンにおけるインデックス部５３（図６参照）は、クローラに含まれるＸＳＬＴコードを使用し、検索エンジン固有のメタデータＸＭＬを統一フォーマットのＸＭＬに変換する。なお、ＸＳＬＴコードは管理者が作成し、検索エンジンを検索エンジン管理ＤＢに登録するときに、同時に登録される。
【００４４】
＜検索エンジンの内部構成＞
図６は、図２における検索エンジン５ａ、５ｂ、・・・、５ｎの詳細な内部構成を示す図である。
検索エンジン５１は一般的なエンタープライズ検索エンジンであり、主に検索処理を行う検索処理部５２と、主にインデックシング処理を行うインデックス部５３を備えている。
【００４５】
検索エンジン５１はファイルシステム群５４の各ファイルシステム５４ａ、５４ｂ、５４ｃ、・・・、５４ｒと接続されている。各ファイルシステムは、認証サーバ５５の各認証サーバ５５ａ、５５ｂ、・・・、５５ｍのいずれかと関連付けられている。なお、一つのファイルシステムに関連付けられる認証サーバは複数あってもよい。例えば、ファイルシステム５４ｂには、認証サーバ５５ａと５５ｂが関連付けられていてもよい。このとき、ファイルシステム５４ｂのアクセス権限は、認証サーバ５５ａからログインしたときには認証サーバ５５ａのＡＣＬに従い、認証サーバ５５ｂからログインしたときには、認証サーバ５５ｂのＡＣＬに従う。
【００４６】
検索エンジン５１のインデックス部５３は、ファイルシステム群５４に対し各ファイルシステムの更新状況に応じて定期的にクローリング処理を実施する。そして、クローリング処理の結果得られた文書のメタデータは、インデックス部５３によって順次インデックシングされる。インデックシングされるメタデータには、文書の名称やパス、サイズといった一般的な属性のほか、認証サーバのＡＣＬが含まれる。
【００４７】
各検索エンジンが個別に行うインデックシング処理とは別に、ホストシステム１のインデックス部４も、登録された各検索エンジンに関して、定期的にインデックス情報の更新を行っている。インデックス部４から各検索エンジンにクローラが派遣されると、各検索エンジンのインデックス部５３は、蓄積されたインデックスの差分のメタデータをＸＭＬ形式でホストシステム１のインデックス部４に譲り渡す。このとき譲り渡されたメタデータは、インデックス部４においてそのままの形でインデックシング処理できるとは限らない。なぜなら、各検索エンジンによってメタデータの名称やインデックスする項目はまちまちだからである。そこで、クローラを受け取ると、各検索エンジンのインデックス部５３は、メタデータのＸＭＬを検索エンジンごとに登録されたＸＳＬＴで変換し、ホストシステム１のインデックス部４で解釈できる形式に変更する。このＸＳＬＴは、検索エンジンをシステムに登録する際に、同時に検索エンジン管理ＤＢに登録しておく。そして、クローラには、それを派遣する各検索エンジンのＸＳＬＴの情報が含まれている。
【００４８】
＜アカウント対応作成処理＞
図７は、複数認証サーバにおけるアカウント対応作成処理の概要を説明するためのフローチャートである。
まず、認証処理部２はユーザがメインのアカウントでログイン後、その求めに応じてアカウント対応追加画面を表示する（ステップＳ１０１）。この画面には現在システムに登録されている認証サーバの一覧と、認証ＩＤ（アカウントＩＤ）とパスワードの入力欄がある。
【００４９】
ユーザが自身のアカウント対応に新たにアカウントを追加することを指示した場合（ステップＳ１０２）、認証処理部２は、入力欄に、自分の所持するアカウントのうちログインに使用したもの以外のアカウント情報の入力をユーザに促し、その入力を受け付ける（ステップＳ１０３）。
【００５０】
次に、認証処理部２は、ユーザの入力情報をもとに該当する認証サーバに認証を問い合わせる（ステップＳ１０４）。認証が成功すれば（ステップＳ１０５）、認証処理部２は、当該アカウントをログインに使用したユーザと同じ対応ＩＤで保存する（ステップＳ１０６）。認証に失敗したときには当該アカウントは保存されない。以上の処理が繰り返される。
【００５１】
なお、ログインに使用したユーザ自身のＤＢ内のレコードは、初回ログイン時に自動で作成され、対応ＩＤも未使用のものから自動で採番される。
【００５２】
＜ログインから検索までの処理＞
図７は、統合エンタープライズサーチにおけるログインから検索までの処理の流れを説明するためのフローチャートである。
ホストシステム１がユーザのログイン（ステップＳ２０１）及び検索条件の入力を受け付けると（ステップＳ２０２）、認証処理部２はユーザのログインアカウントの認証サーバＩＤと認証ＩＤから、アカウント対応管理ＤＢ１０に対し、対応表を問い合わせし、同じユーザがアクセス権限を有する認証サーバの情報（認証サーバＩＤ）を取得する（ステップＳ２０３）。この時点では、ログインした認証サーバのみに接続されている状態である。
【００５３】
続いて、認証処理部２は、対応表の認証サーバＩＤを基に、認証サーバ管理ＤＢ９に認証サーバへの接続情報を問い合わせる（ステップＳ２０４）。
【００５４】
そして、対応する認証サーバとの接続後、認証処理部２は、アカウントの認証ＩＤからアカウントの権限情報を引き出す（ステップＳ２０５）。権限情報としては、例えば個体識別情報（ＵＩＤ）やグループ識別情報（ＧＩＤ）がある。この段階で、当該ユーザがアカウントを有する全ての認証サーバにアクセス可能な状態となる。
【００５５】
最後に、検索処理部３は、得られた各アカウントの権限情報を検索クエリに埋め込んで、インデックス部４に対して検索を実行する（ステップＳ２０６）。
【００５６】
＜インデックシング処理＞
図９はホストシステム１のインデックス部４におけるインデックシング処理を説明するためのフローチャートである。
インデックス部４は、定期的に検索エンジン管理ＤＢ７の最終インデックス日時を参照する（ステップＳ３０１）。そして、インデックス部４は、インデックスが過去一度も更新されていないか否かチェックする（ステップＳ３０２）。過去にインデックシング処理されたことがある場合には処理はステップＳ３０４に移行し、されたことが無ければ処理はステップＳ３０６に移行する。
【００５７】
また、インデックス部４は、処理中の検索エンジンが検索エンジンの中で最も長い間更新されていないものか否かを判定する（ステップＳ３０４）。最も長い間更新されていないものであれば、処理はステップＳ３０６に移行し、そうでなければ処理はステップＳ３０１に移行する。
【００５８】
そして、インデックス部４は、該当する検索エンジンにクローラを派遣する（ステップＳ３０５）。なお、クローラの派遣に必要なＩＰアドレスなどの検索エンジンへの接続情報は、全て検索エンジン管理ＤＢに保存されている。また、クローラには最終インデックス履歴の情報が含まれている。
【００５９】
派遣先の検索エンジンのインデックス部５３は、そのクローラを取得し、クローラに含まれるインデックス履歴に基づいて、検索エンジン内のインデックスが前回のクローラ派遣時から更新されたか否か判断する（ステップＳ３０６）。この判断結果はインデックス部５３からインデックス部４に通知される。
【００６０】
前回からの更新がなければ（ステップＳ３０７）、インデックス部４は、検索エンジン管理ＤＢ７の最終インデックス日時を更新して終了する（ステップＳ３１１）。一方、更新があれば（ステップＳ３０７）、インデックス部４は、インデックス部５３から更新インデックス部分の差分メタデータをＸＭＬ形式で受け取る（ステップＳ３０８）。さらに、インデックス部４は、検索エンジン管理ＤＢ７から取得したフォーマット変換ＸＳＬＴファイル（コード）に基づいて、更新インデックス部分の差分メタデータのＸＭＬファイルを統一フォーマットのＸＭＬファイルに変換する（ステップＳ３０９）。
【００６１】
続いて、インデックス部４は、新たに取得した統一フォーマットのＸＭＬファイルのメタデータを用いて再インデックシング処理を行う（ステップ３１０）。
【００６２】
そして、再インデクシング完了後、ステップＳ３０７でＮＯの場合、或いは、ステップＳ３０４でＮＯの場合、インデックス部４は、検索エンジン管理ＤＢ７の最終インデックス日時を更新する（ステップ８１１）。
【００６３】
なお、図９の処理では、インデックス部４が差分メタデータを統一フォーマットのＸＭＬファイルに変換しているが、クローラを受け取った各検索エンジンのインデックス部５３が統一フォーマットのＸＭＬに変換後、差分メタデータをホストシステム１のインデックス部４に送信するようにしてもよい。その場合には、クローラには各検索エンジンのフォーマット変換ＸＳＬＴファイルが含まれるようにするか、別の方法でフォーマット変換ＸＳＬＴファイルを通知する必要がある。
【００６４】
＜変換前後のＸＭＬ＞
図１０は、検索エンジンから得たメタデータのＸＭＬ（変換前）と、それを変換ＸＳＬＴコードにより再インデクシング可能な統一的なファイルに変換して得られたＸＭＬ（変換後）の例を示す図である。
【００６５】
検索エンジン固有のメタデータのＸＭＬ９１は、具体的な文書を、ある検索エンジンでクローリングした結果得られたメタデータのＸＭＬを表す。また、再インデクシング用に変換されたメタデータのＸＭＬ９２は、検索エンジン固有の上記ＸＳＬＴコードにより変換されたＸＭＬを表している。
【００６６】
この例では、文書「２００７年度決算報告．ｐｄｆ」のメタデータとして、ファイル名、ファイルパス、容量、変更日時、内容、ファイルのオーナー…などの情報がＸＭＬ形式で表示されている。検索エンジン固有のメタデータのＸＭＬ９１では、それぞれのメタデータはfilename、filepath、date、content、owner・・・という要素の内容になっているが、各要素名は検索エンジン固有のものであるので、ホストシステム１のインデックス部４がこのＸＭＬを正しく解釈しインデクシングを実行できる保証は無い。これは、例えばファイル名に相当するものがfilename要素の内容であるとインデックス部４が判断できないためである。
【００６７】
変換後のＸＭＬ９２は、ホストシステム１のインデックス部４がインデクシング可能な形のメタデータのＸＭＬである。インデックス部４は、このファイルを基に検索エンジンインデックスの再インデックシング処理を行うことができる。
【００６８】
＜まとめ＞
本実施形態では、全登録ユーザが有する複数の認証サーバのアカウント情報を管理する管理情報に基づいて、ログイン時に、ログインユーザがアカウントを有する全ての認証サーバを特定し、特定された認証サーバと関連付けられたファイルシステム群に対応するインデックス情報に対して検索処理を実行する。これにより、一度のログインであらかじめ対応付けられた全てのアカウントが参照権限を持つ文書を検索することが可能となる。従って、ユーザにとっては、他のアカウントで再ログインのうえ、再検索を行う手間を省略することが可能となる。
【００６９】
また、複数のファイルシステム群のインデックス情報を一箇所にまとめて管理している。これにより、ホストコンピュータが、検索処理の度に、各検索エンジンからそれぞれの検索結果を取得する必要がなく、システムの負荷を軽減することができるようになる。また、各検索エンジンの検索待ち時間を省略することが可能となる。
【００７０】
複数の検索エンジンのそれぞれは、対応するファイルシステム群のインデックス情報を任意のタイミングで更新して更新インデックス情報を生成する。そして、ホストコンピュータ（インデックス部）から、検索エンジンに対して更新インデックス情報の送信を指示するクローラを送信し、このクローラに応答して検索エンジンが返信した更新インデックス情報を用いて、インデックス部が保持するインデックス情報を更新する。これにより、インデックス情報の更新も効率的に実行することができるようになる。
【００７１】
なお、ホストコンピュータ（インデックス部）は、統一フォーマットで生成されたインデックス情報を保持している。複数の検索エンジンが統一フォーマットと異なるフォーマットで更新インデックス情報を保持する場合には、インデックス部及び該当する検索エンジンの何れか一方で統一フォーマットの更新インデックス情報に変換されるようになっている。これにより、検索の度に、各検索エンジンの検索結果を統合し、整理し、整列する作業を省略することができるようになるので、システムの負荷を軽減することができる。
【００７２】
さらに、インデックス部は、複数の検索エンジンにおけるインデックス情報の更新履歴を管理する検索エンジン管理情報を参照し、最も古い更新インデックス情報を有する検索エンジン、或いはインデックス情報を更新したことがない検索エンジンを特定し、特定された検索エンジンに対してクローラを送信する。
【００７３】
なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００７４】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【００７５】
また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【図面の簡単な説明】
【００７６】
【図１】従来のＦｅｄｅｒａｔｅｄ Ｓｅａｒｃｈシステムの概略構成図である。
【図２】本発明の実施形態に係る統合エンタープライズサーチシステムの概略構成を示すブロック図である。
【図３】認証サーバ管理ＤＢのデータ構造の一例を示す図である。
【図４】アカウント対応管理ＤＢのデータ構造の一例を示す図である。
【図５】検索エンジン管理ＤＢのデータ構造の一例を示す図である。
【図６】検索エンジンの内部構成図である。
【図７】認証処理部の行うアカウント対応作成手順を示すフローチャートである。
【図８】統合エンタープライズサーチにおけるログイン後から検索までの手順を示すフローチャートである。
【図９】インデックス部の行うインデックス作成手順を示すフローチャートである。
【図１０】ＸＳＬＴによるメタデータＸＭＬの変換の一例を示す図である。
【符号の説明】
【００７７】
１・・・ホストシステム、２・・・認証処理部、３・・・検索処理部、４・・・インデックス部、５ａ乃至５ｎ・・・検索エンジン、６ａ乃至６ｎ・・・ファイルシステム群、７・・・検索エンジン管理ＤＢ、８ａ乃至８ｍ・・・認証サーバ、９・・・認証サーバ管理ＤＢ、１０・・・アカウント対応管理ＤＢ
【特許請求の範囲】
【請求項１】
ホストコンピュータと、複数の認証サーバと、複数のファイルシステム群の少なくとも１つにそれぞれ接続された複数の検索エンジンと、を備える検索システムであって、
前記ホストコンピュータは、
検索を実行するユーザについて、前記複数の認証サーバについての認証処理を行う認証処理部と、
前記検索を実行するユーザの検索要求に基づいて、前記複数の検索エンジンから取得した前記複数のファイルシステム群のインデックス情報に対して検索処理を実行する検索処理部と、を有し、
前記認証処理部は、全登録ユーザが有する前記複数の認証サーバのアカウント情報を管理する管理情報に基づいて、前記検索を実行するユーザのログイン時に、当該ユーザがアカウントを有する全ての前記認証サーバを特定し、
前記検索処理部は、前記特定された認証サーバと関連付けられた前記ファイルシステム群に対応する前記インデックス情報に対して検索処理を実行することを特徴とする検索システム。
【請求項２】
前記ホストコンピュータは、さらに、前記複数のファイルシステム群のインデックス情報をまとめて格納するインデックス部を備えることを特徴とする請求項１に記載の検索システム。
【請求項３】
前記複数の検索エンジンのそれぞれは、対応するファイルシステム群のインデックス情報を任意のタイミングで更新して更新インデックス情報を生成し、
前記インデックス部は、検索エンジンに対して前記更新インデックス情報の送信を指示するクローラを送信し、このクローラに応答して前記検索エンジンが返信した前記更新インデックス情報を用いて、前記インデックス部が保持する前記インデックス情報を更新することを特徴とする請求項２に記載の検索システム。
【請求項４】
前記インデックス部は、統一フォーマットで生成された前記インデックス情報を保持することを特徴とする請求項３に記載の検索システム。
【請求項５】
前記複数の検索エンジンが前記統一フォーマットと異なるフォーマットで前記更新インデックス情報を保持する場合には、前記インデックス部及び該当する検索エンジンの何れか一方で統一フォーマットの更新インデックス情報に変換されることを特徴とする請求項４に記載の検索システム。
【請求項６】
前記インデックス部は、前記複数の検索エンジンにおけるインデックス情報の更新履歴を管理する検索エンジン管理情報を参照し、最も古い更新インデックス情報を有する検索エンジン、或いはインデックス情報を更新したことがない検索エンジンを特定し、特定された検索エンジンに対して前記クローラを送信することを特徴とする請求項４に記載の検索システム。
【請求項１】
ホストコンピュータと、複数の認証サーバと、複数のファイルシステム群の少なくとも１つにそれぞれ接続された複数の検索エンジンと、を備える検索システムであって、
前記ホストコンピュータは、
検索を実行するユーザについて、前記複数の認証サーバについての認証処理を行う認証処理部と、
前記検索を実行するユーザの検索要求に基づいて、前記複数の検索エンジンから取得した前記複数のファイルシステム群のインデックス情報に対して検索処理を実行する検索処理部と、を有し、
前記認証処理部は、全登録ユーザが有する前記複数の認証サーバのアカウント情報を管理する管理情報に基づいて、前記検索を実行するユーザのログイン時に、当該ユーザがアカウントを有する全ての前記認証サーバを特定し、
前記検索処理部は、前記特定された認証サーバと関連付けられた前記ファイルシステム群に対応する前記インデックス情報に対して検索処理を実行することを特徴とする検索システム。
【請求項２】
前記ホストコンピュータは、さらに、前記複数のファイルシステム群のインデックス情報をまとめて格納するインデックス部を備えることを特徴とする請求項１に記載の検索システム。
【請求項３】
前記複数の検索エンジンのそれぞれは、対応するファイルシステム群のインデックス情報を任意のタイミングで更新して更新インデックス情報を生成し、
前記インデックス部は、検索エンジンに対して前記更新インデックス情報の送信を指示するクローラを送信し、このクローラに応答して前記検索エンジンが返信した前記更新インデックス情報を用いて、前記インデックス部が保持する前記インデックス情報を更新することを特徴とする請求項２に記載の検索システム。
【請求項４】
前記インデックス部は、統一フォーマットで生成された前記インデックス情報を保持することを特徴とする請求項３に記載の検索システム。
【請求項５】
前記複数の検索エンジンが前記統一フォーマットと異なるフォーマットで前記更新インデックス情報を保持する場合には、前記インデックス部及び該当する検索エンジンの何れか一方で統一フォーマットの更新インデックス情報に変換されることを特徴とする請求項４に記載の検索システム。
【請求項６】
前記インデックス部は、前記複数の検索エンジンにおけるインデックス情報の更新履歴を管理する検索エンジン管理情報を参照し、最も古い更新インデックス情報を有する検索エンジン、或いはインデックス情報を更新したことがない検索エンジンを特定し、特定された検索エンジンに対して前記クローラを送信することを特徴とする請求項４に記載の検索システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１０−１０２５１８（Ｐ２０１０−１０２５１８Ａ）
【公開日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願番号】特願２００８−２７３５５２（Ｐ２００８−２７３５５２）
【出願日】平成２０年１０月２３日（２００８．１０．２３）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
【公開日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願日】平成２０年１０月２３日（２００８．１０．２３）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
[ Back to top ]