検索システム及びプログラム
【課題】複数の国や地域に存在する複数の検索サーバを対象に検索処理を実行する場合、検索結果をまとめる１つの検索サーバに処理負荷が集中する。
【解決手段】複数の検索サーバをドメインという単位でまとめて管理する。例えば事業所毎にドメインを作成する。他のドメインから検索要求を受信したマスター検索サーバとして機能する検索サーバは、同じドメイン内から収集された検索結果を統合、整理、整列した後に、検索要求の送信元である他のドメインに返送する。
【解決手段】複数の検索サーバをドメインという単位でまとめて管理する。例えば事業所毎にドメインを作成する。他のドメインから検索要求を受信したマスター検索サーバとして機能する検索サーバは、同じドメイン内から収集された検索結果を統合、整理、整列した後に、検索要求の送信元である他のドメインに返送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検索システム及び検索システムを構成する検索サーバに搭載されたコンピュータで実行されるプログラムに関する。例えば複数地点に存在する複数の検索サーバ間での検索処理の実行が想定される検索システム及び各検索サーバに搭載されたコンピュータに実行させて好適なプログラムに関する。
【背景技術】
【０００２】
今日、多くの企業では、多数の電子文書が扱われている。また、それらの企業では、多数の電子文書の管理と検索に多くの時間を要しており、結果的に多くのコストを要している。このため、電子文書のコスト削減は、企業にとって、性急に対応すべき課題となっている。
【０００３】
エンタープライズサーチは、企業内の文書検索機能を提供する検索実行装置である。エンタープライズサーチは、要求文書の検索を高速かつ正確に行うことができるため、導入事例が増えている。今後、さらなる電子文書の増加に伴い、複数のエンタープライズサーチのファイル検索結果（以下、「検索結果」という。）を統合、整理、整列する仕組みが必要になると予想される。この明細書では、この種の仕組みを「Federated Search」という。ここで、検索結果を「統合する」とは、フォーマットの異なる検索結果を予め決められたルールに従って統一することをいう。「整理する」とは、同一の検索結果を省略することをいう。「整列する」とは、ユーザによって指定されたオーダーによって検索結果を並び替えることをいう。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−７０５４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
規模の大きい企業では、検索システムを構成する検索サーバの数も大量になる。ところが、検索サーバの数が増えるのに従って、ファイル検索要求（以下、「検索要求」という。）を受け付けた検索サーバに掛かる負荷が非常に高くなる。その理由は、当該検索要求を受け付けた検索サーバが、各検索サーバの検索結果を統合する全ての処理を実行するためである。
【０００６】
また、一定規模以上の企業であれば、事業所が分散されていることが普通である。各事業所に検索サーバが配置される場合、検索要求に付随する大量のデータがインターネット経由で受け渡しされる。このため、通信負荷が高くなってしまう。
本発明は、以上の課題を解決することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、複数の検索サーバを「ドメイン」という単位にまとめ、ドメイン間で検索処理を実行する場合に適用して好適な処理機能を提供する。例えばドメインは、事業所ごと、国ごと、地域ごとに設定することができる。また、ドメインは、複数の国や地域を対象として設定することができる。
【０００８】
なお、本発明の１つの態様として、他のドメインから検索要求を受信し、マスター検索サーバとして機能する検索サーバが、同じドメインに属する他の検索サーバに対して検索要求を転送する処理と、受信した検索要求に従って検索処理を実行する処理と、同じドメインに属する他の検索サーバから収集された検索結果を統合、整理、整列する処理と、統合後の検索結果をドメインの検索結果として前記他のドメインに送信する処理とを実行するものを提案する。
【０００９】
また、本発明の１つの態様として、ユーザからの検索要求を受け付けたマスター検索サーバとして機能する検索サーバが、システムを構成するドメインの数だけスレッドを作成する処理と、同じドメインに属する他の検索サーバに対して検索要求を送信すると共に、他のドメインのマスター検索サーバに検索要求を送信する処理と、各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列する処理と、当該処理後の検索結果をユーザに提示する処理とを実行するものを提案する。
【発明の効果】
【００１０】
本発明の１つの態様によれば、他のドメインに属する検索サーバに対して検索要求を送信した検索サーバにおける負荷の集中を低減することができる。また、他のドメインに対して検索結果を送信する前に整理処理が実行されるため、通信負荷を低減することができる。
【図面の簡単な説明】
【００１１】
【図１】遠距離間を跨ぐワイドエリアサーチシステムの概略構成例を示す図。
【図２】ドメイン管理データベースに格納されているデータ例を示す図。
【図３】検索サーバがユーザから検索要求を受け付けた後、検索結果をユーザに提示するまでの処理の一例を示すフローチャート。
【図４】ドメイン毎の検索結果を個別に表示できる表示画面例を示す図。
【図５】ドメイン毎の検索結果を個別に表示できる他の表示画面例を示す図。
【図６】フィルタリング設定を行うフィルタ管理部の処理動作例を示すフローチャート。
【図７】フィルタリング設定を行うフィルタ管理部の別の処理動作例を示すフローチャート。
【図８】検索実行前にフィルタリング処理を行うフィルタ処理部の処理動作例を示すフローチャート。
【図９】検索実行後にフィルタリング処理を行うフィルタ処理部の処理動作例を示すフローチャート。
【図１０】フィルタ管理データベースのデータ構成例を示す図。
【図１１】国別に用意されたフィルタ管理データベースのデータ構成例を示す図。
【図１２】１つのドメイン内に複数のマスター検索サーバが存在する場合のシステム構成例を説明する図。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて、発明の実施形態例を説明する。なお、後述する実施形態はいずれも一例であり、本発明には、本明細書に記載する任意の機能を組み合わせることで実現されるシステム、本明細書に記載する一部の機能を周知技術で置換したシステム、本明細書に記載する機能に周知技術を追加したシステムも含まれる。また、後述する実施例で実行される機能は、計算機（コンピュータ）上で実行されるプログラムとして実現される。もっとも、プログラムの一部又は全部は、ハードウェアを通じて実現しても良い。
【００１３】
（システム構成）
図１に、実施例に係るワイドエリアサーチシステムの構成図を示す。実施例に係るワイドエリアサーチシステムは、日本と米国に跨って構成される例である。勿論、国名は一例であり、任意の国名や地域の組み合わせが考えられる。また、国や地域には、事業所、行政区域、国家間や地域を跨って設定される領域が含まれる。図１の場合、日本には２つのドメインが存在し、米国には１つのドメインが存在する。ドメインとは、検索の実行単位又は実行範囲を与える概念である。
【００１４】
各ドメインには、マスター検索サーバ１とスレーブ検索サーバ２が配置される。１つのドメインには、少なくとも１つのマスター検索サーバ１が存在する。この実施例の場合、１つのドメインには１つのマスター検索サーバ１が存在する。なお、スレーブ検索サーバ２は、１つのドメイン内に存在しない場合もある。ただし、図１の場合は、各ドメインに１つ又は２つのスレーブ検索サーバ２が存在する。
【００１５】
マスター検索サーバ１は、検索処理部３と、検索結果統合処理部４と、フィルタ管理部５と、フィルタ処理部６を有する。ここで、マスター検索サーバ１は、ドメイン内の検索処理の起点であると共に、他のドメインとの間で検索要求や検索結果を受け渡す際の窓口として機能する。一方、スレーブ検索サーバ２は、検索処理部３のみを有している。これらマスター検索サーバ１及びスレーブ検索サーバ２を構成する各処理部の具体的な機能については後述する。
【００１６】
マスター検索サーバ１は、ドメイン管理データベース７とフィルタ管理データベース８を保持し又は接続されている。ドメイン管理データベース７とフィルタ管理データベース８は、必ずしもマスター検索サーバ１と同じ筐体内、同じ部屋内、同じ施設内に存在しなくても良いが、マスター検索サーバ１が必要に応じてアクセスできることが要求される。
【００１７】
ドメイン間は、ＶＰＮ（Virtual Private Network）等の専用線で接続されている場合に限らず、ＷＡＮ（Wide Area Network）やインターネット経由で接続される場合も存在する。
【００１８】
マスター検索サーバ１とスレーブ検索サーバ２は、ＣＰＵ（Central Processing Unit）や主記憶装置等を備えるコンピュータ（計算機）として実現され、各処理部はコンピュータを通じて実行されるプログラムとして実現される。また、マスター検索サーバ１は、機能の一部としてＧＵＩ（Graphical User Interface）サーバやＣＬＩ（Command Line Interface）サーバを有し、ユーザからの検索要求を受け付ける機能を有している。なお、ユーザの操作入力には、不図示のマウス、キーボード、ポインティングデバイスその他の入力装置が使用される。
【００１９】
（ドメイン管理データベースのデータ構造）
図２に、ドメイン管理データベース７が格納する情報の一例を示す。図２の場合、ドメイン管理データベース７は、ユーザ識別ＩＤ２１、ドメイン名２２、認証サーバ２３、認証ユーザＩＤ２４、認証パスワード２５を格納する。これらの情報は、マスター検索サーバ１が他のドメインに対して検索要求を出す場合に参照される。マスター検索サーバ１は、これらの情報を利用してユーザを認証する。認証処理は、検索処理部３の機能として実行される。
【００２０】
例えば、DomainTokyoのマスター検索サーバ１にログインしたK-satoから検索要求を受け付けた場合を考える。この場合、DomainTokyoのマスター検索サーバ１は、ドメイン管理データベース７にアクセスし、検索要求を入力したユーザ（K-sato）のユーザ識別ＩＤを読み出す。図２の場合、K-satoは、操作中のマスター検索サーバ１が存在するDomainTokyoの他、DomainOsakaとDomainSanJoseの２箇所について登録されている。この場合、DomainTokyoのマスター検索サーバ１は、DomainOsakaに検索要求を出す場合にはK-satoの認証ユーザＩＤ“１”を使用し、DomainSanJoseに検索要求を出す場合にはSato-Kの認証ユーザＩＤ“１”を使用する。
【００２１】
もし、検索要求を入力したユーザが他のドメインに対するユーザアカウントを登録していない場合は、そのドメインに対する検索要求は送出されない。例えばT-suzukiは、DomainTokyoについてしかユーザアカウントが登録されていない。従って、DomainTokyoのマスター検索サーバ１にログインしたT-suzukiから検索要求が入力された場合、その検索要求は、DomainTokyoのマスター検索サーバ１から他のドメインには送信されないことになる。以上により、各ドメインのマスター検索サーバ１が、正しいユーザ権限を有するドメインに対してのみ検索を実行することが可能となる。
【００２２】
（検索結果統合処理部４の処理）
図３に、マスター検索サーバ１の検索結果統合処理部４が実行する処理動作例を示す。なお、図３に示す処理は、ユーザから検索要求を受け付けたマスター検索サーバ１の検索結果統合処理部４が実行する。
【００２３】
検索結果結合処理部４は、認証されたドメインに対して検索要求を送信する。このため、送信可能なドメインの数だけスレッドを作成する（ステップ３０１）。図２の場合、DomainTokyoのマスター検索サーバ１にログインしたK-satoから検索要求を受け付けたとき、３つのスレッドが作成される。これに対し、DomainTokyoのマスター検索サーバ１にログインしたT-suzukiから検索要求を受け付けたとき、１つのスレッドが作成される。
【００２４】
次に、検索結果統合処理部４は、ステップ３０１で作成した各スレッドを通じ、対応する各ドメインのマスター検索サーバ１に対して検索要求を送信する（ステップ３０２）。
【００２５】
この後、検索結果統合処理部４は、検索要求が送信されたドメインのマスター検索サーバ１から検索結果が取得されたか否かを判定する（ステップ３０３）。すなわち、各スレッドに対応する検索結果の受信を待ち受ける。判定時点において検索結果の取得が確認されない場合（ステップ３０３で否定結果の場合）、検索結果統合処理部４は、検索結果の待ち受け時間がタイムアウトしたか否かを判定する（ステップ３０４）。タイムアウトが検出されない場合（ステップ３０４で否定結果の場合）、検索結果統合処理部４は、ステップ３０３の判定処理に戻る。一方、タイムアウトが検出された場合（ステップ３０４で肯定結果の場合）、検索結果統合処理部４は、検索結果の待ち受け状態から抜け、ステップ３０８に移行する。
【００２６】
ここでは、検索結果の待ち受け時間中に、あるドメインから検索結果が受信された場合を考える。この場合、検索結果統合処理部４は、新たに取得した検索結果を既に取得されている検索結果の全体に統合、整理、整列する（ステップ３０５）。ここでの検索結果の整理により、最終的に表示される検索結果の全体数が必要とする件数以上に増えないようにできる。
【００２７】
なお、検索結果統合処理部４による検索結果の統合、整理、整列は、検索要求を他のドメインから受信したマスター検索サーバ１でも実行される。例えば取得したい検索結果の全体数が２０件の場合、各ドメインのマスター検索サーバ１は、最大でも２０件しか検索結果を返信しない。
【００２８】
仮に検索要求を受け付けたドメインのマスター検索サーバ１が、全体として既に１０件の検索結果を保持している場合、検索結果統合処理部４は、ステップ３０５の処理として、新たに取得した２０件の検索結果を既存の１０件の検索結果に統合した後、再び２０件に整理する。
【００２９】
ステップ３０５の処理動作の後、検索結果統合処理部４は、新たに取得したドメインからの検索結果を、不図示の表示装置の画面上に表示できる状態に制御する（ステップ３０６）。ここでの制御は、後述するようにユーザインターフェースの画面に依存する。詳細は後述するが、統合後の検索結果の表示領域の他に、各ドメインに対応する検索結果を選択的に表示できる場合、個別のドメインに対応する表示領域に、他のドメインから取得した検索結果を表示する又は表示する準備を行う。
【００３０】
次に、検索結果統合処理部４は、全てのドメインから検索結果が取得されたか否かを判定する（ステップ３０７）。検索結果が取得されていないドメインが存在する場合、検索結果統合処理部４はステップ３０３に戻り、新たな検索結果の取得を待ち受ける状態になる。一方、全てのドメインから検索結果が取得されたと判定された場合、検索結果統合処理部４は、不図示の表示装置の画面上にFederated Searchの検索結果を表示する（ステップ３０８）。
【００３１】
（検索結果の表示画面）
図４に、検索結果の表示画面例を示す。図４に示す表示画面例は、Federated Searchの検索結果が表示されるタブ画面（Federateタブ）４０１と、各ドメインに対応する３つのタブ画面４０２で構成される。Federateタブ４０１には、ユーザから検索要求を受けたマスター検索サーバ１が全てのドメインから検索結果を取得された段階で、全ドメインからの検索結果を統合し、整理し、整列した後の検索結果が一覧的に表示される。一方、タブ画面４０２には、対応するドメインから検索結果が取得された段階で検索結果が表示される。このため、ユーザは全てのドメインの検索結果が揃うまで待ち続ける必要はない。
【００３２】
なお、Federateタブ４０１及び各ドメイン専用のタブ画面４０２の表示形態は、検索結果の表示の準備が完了した段階で変化することが望ましい。例えば表示色が変化する、表示枠の太さが変化する、模様が変化する、輝度が変化する、表示位置が変化する表示の大きさが変化する等の制御を適用することが望ましい。これら表示形態の変化により、ユーザはどのタブが参照可能であるかを知ることができ、Federateタブ４０１が完了するまでの間に他の結果を参照することが可能となる。
【００３３】
図４の場合、検索結果の表示画面の左側には、ドメイン選択用の領域４０３が用意される。領域４０３を使用可能な場合、ユーザは、検索要求を送信するドメインに対応する領域４０３にチェックを入れる。これにより、不必要なドメインに対して検索要求が送信される事態を回避でき、その分、通信負荷と全ての検索結果が取得されるまでの時間の短縮を実現できる。ユーザは、Federateタブ４０１又は各ドメイン専用のタブ画面４０２を選択することにより、検索結果一覧４０４を参照することができる。
【００３４】
なお、Federateタブ４０１及び各ドメイン専用のタブ画面４０２そのものが、検索結果が取得された順番に追加的に表示されるようにしても良い。図４の場合であれば、検索結果の表示画面には、DomainTokyoのタブ画面４０２が最初に表示され、次にDomainOsakaのタブ画面４０２が先の１つに追加的に表示され、最後にDomainSanJoseのタブ画面４０２が先の２つに追加的に表示され、最後にFederated Searchのタブ画面が追加的に表示されるようにしても良い。最終的には、図４に示すように、４つのタブ画面が表示される。この場合も、ユーザは全てのドメインの検索結果が揃うまで待ち続ける必要はない。
【００３５】
図５に、検索結果の表示画面の別例を示す。図５に示す表示画面例は、ユーザから検索要求を受けたマスター検索サーバ１が、各ドメインから新たな検索結果が取得されるたび、既存の検索結果一覧５０１に追加するように表示していく。図の例では、DomainTokyoが一番最初に結果を返し、次にDomainOsakaが結果を返したため、先頭にDomainTokyoの結果が、その後ろにDomainOsakaの結果が続く形になっている。なお、全てのドメインから検索結果が得られた段階で、表示画面の表示内容をFederateタブ４０１（図４）の表示内容に変更しても良い。
【００３６】
（フィルタ管理部５の処理）
図６に、マスター検索サーバ１のフィルタ管理部５が実行する処理動作例を示す。フィルタ管理部５は、フィルタの強度を管理する機能を提供する。
【００３７】
フィルタ管理部５は、他のドメインから検索対象に追加された場合に動作する（ステップ６０１）。フィルタ管理部５は、自ドメインを検索対象に追加した他のドメインに対する検索結果の出力に対し、出力条件が最も厳しいフィルタを自動的に適用する（ステップ６０２）。その理由は、他のドメインの検索対象に自ドメインが追加された段階では、どのフィルタ強度を適用すれば良いのか一意に決定できないためである。このため、新規のドメイン登録には安全性が最も高い、換言すると最も出力条件が厳しいフィルタを適用する。
【００３８】
この後、フィルタ管理部５は、自ドメインのマスター検索サーバ１の管理者に宛ててメールを送信する（ステップ６０３）。自装置のドメインが検索対象に設定されたとの通知を受けた管理者は、自ドメインを検索対象に追加した他のドメインに対して適切なフィルタを設定する（ステップ６０４）。自ドメインを検索対象に設定した他のドメインが、自ドメインと同じ国内の場合、全くフィルタを掛けない設定にすることもできる。また、自ドメインを検索対象に設定した他のドメインが、自国と特定の関係にある国の場合、当該国にのみ有効な固有のフィルタを設定することもできる。
【００３９】
なお、ステップ６０１からステップ６０４までの間に検索要求が受信された場合、フィルタ管理部５は、最も強いフィルタを適用する。ステップ６０４で適切なフィルタを設定した後に検索要求が受信された場合、フィルタ管理部は、最も強いフィルタではなく、ステップ６０４で設定されたフィルタを適用する。
【００４０】
図７に、マスター検索サーバ１のフィルタ管理部５が実行する他の処理動作例を示す。フィルタ管理部５は、他のドメインから検索対象として追加された場合に動作する（ステップ７０１）。この点は、図６に示す処理動作と同じである。次に、フィルタ管理部５は、後述する国別フィルタ管理データベースを参照し、追加要求を出したドメインが属する国用のフィルタが用意されているか否かを判定する（ステップ７０２）。フィルタが用意されていない場合、フィルタ管理部５は、フィルタ管理データベース８から最も強いフィルタを取得する（ステップ７０３）。一方、フィルタが用意されている場合、フィルタ管理部５は、国別フィルタ管理データベースから該当するフィルタ条件を取得する（ステップ７０４）。その後、フィルタ管理部５は、フィルタ管理データベース８に対し、ドメイン名とフィルタ条件を追加する（ステップ７０５）。
【００４１】
（フィルタ処理部６の処理）
図８に、他のドメインから検索要求を受けたマスター検索サーバ１のフィルタ処理部６が実行する処理動作を示す。図８は、検索実行前にフィルタを適用する方式を採用する場合のフローチャートを示している。
【００４２】
フィルタ処理部６は、他のドメインから検索要求を受信することで動作を開始する（ステップ８０１）。まず、フィルタ処理部６は、検索要求の送信元であるドメイン用のフィルタが設定されているか否かを判定する（ステップ８０２）。
【００４３】
否定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されていない場合）、フィルタ処理部６は、予め管理者が用意している最も強度の高い（安全の高い）フィルタを適用する（ステップ８０３）。一方、肯定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されている場合）、フィルタ処理部６は、設定されているフィルタを読み出して適用する（ステップ８０４）。
【００４４】
続いて、フィルタ処理部６は、検索要求を受け付けた検索キーワードに対し、ステップ８０３又はステップ８０４で確定したフィルタ（出力条件）を追加する（ステップ８０５）。すなわち、受け付けた検索キーワードにフィルタ（出力条件）を付加したものを、自ドメイン内で使用する検索キーワードとする。図８のうちフィルタ処理部６の処理動作は、当該ステップまでである。
【００４５】
この後、ステップ８０５で作成された検索キーワードは、マスター検索サーバ１の検索処理部３に与えられる。検索処理部３は、検索要求元に応じて最適化された検索キーワードを用いて自ドメイン内を検索する（ステップ８０６）。その後、検索処理部３は、最終的に取得された検索結果を、自ドメインにおける検索結果として、検索要求の送信元のドメインに宛てて送信する（ステップ８０７）。
【００４６】
もっとも、フィルタの適用手法はこれに限らない。図９に、他のドメインから検索要求を受けたマスター検索サーバ１のフィルタ処理部６が実行する別の処理動作例を示す。図９は、検索実行後にフィルタを適用する方式を採用する場合のフローチャートを示している。すなわち、検索実行後にフィルタ条件を適用し、フィルタ条件で出力が禁止されたファイルを出力対象から除外する方式を採用する。
【００４７】
まず、フィルタ処理部６は、他のドメインから検索要求を受信することで動作を開始する（ステップ９０１）。この場合、フィルタ処理部６は、検索処理部３に検索の実行を指示する。検索処理部３は、検索要件に規定されている検索キーワードに基づいて自ドメイン内を検索する（ステップ９０２）。この時点では、検索キーワードのみに応じた検索結果が取得される。この後、検索結果はフィルタ処理部６に与えられる。
【００４８】
次に、フィルタ処理部６は、検索要求の送信元であるドメイン用のフィルタが設定されているか否かを判定する（ステップ９０３）。
【００４９】
否定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されていない場合）、フィルタ処理部６は、予め管理者が用意している最も強度の高い（安全の高い）フィルタを検索結果に対して適用する（ステップ９０４）。すなわち、予め管理者が用意している最も強度が高い（安全性の高い）フィルタ条件を検索結果に適用する。具体的には、フィルタ条件に該当するファイルを、ステップ９０２で取得された検索結果から除外する。
【００５０】
一方、肯定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されている場合）、フィルタ処理部６は、設定されているフィルタを読み出して検索結果に適用する（ステップ９０５）。すなわち、特定のドメイン用に最適化されている強度のフィルタ条件を検索結果に適用する。この場合も、フィルタ条件の強度が異なるだけで、フィルタ条件に該当するファイルを、ステップ９０２で取得された検索結果から除外する。
【００５１】
その後、フィルタ処理部６は、最終的に取得された検索結果を、自ドメインにおける検索結果として、検索要求の送信元のドメインに宛てて送信する（ステップ９０６）。なお、検索結果の他のドメインに対する送信は、検索処理部３を通じて実行しても良い。
【００５２】
（フィルタ管理データベースのデータ構造）
図１０に、フィルタ管理データベース８が格納する情報の一例を示す。図１０の場合、フィルタ管理データベース８は、ドメイン名１０１とフィルタ条件１０２で構成される。このフィルタ管理データベース８は、他のドメインから検索要求を受け付けた場合に適切なフィルタを適用するために参照される。
【００５３】
図１０は、最も出力条件が厳しい（安全性が高い）デフォルトのフィルタ条件と、DomainTokyo用のフィルタ条件だけが設定された状態を示している。この例の場合、デフォルトのフィルタ条件として、他のドメインに対して出力する検索結果から、画像ファイルと、音声ファイルと、ドキュメントファイルを除外することが規定されている。一方、DomainTokyo用のフィルタ条件として、他のドメインに対して出力する検索結果からドキュメントファイルを除外すること、すなわち画像ファイルと音声ファイルは検索結果に含めて良いことが規定されている。
【００５４】
例えば図８に示すフィルタ処理を適用する場合であれば、DomainTokyo以外のドメインから検索要求を受け付けた場合、受信した検索条件に対して「ドキュメントファイルと、画像ファイルと、音声ファイルを除外」という条件が追加され、その後、検索処理が実行される。そして、検索処理後に取得される検索結果はそのまま検索要求元のドメインに送出される。一方、DomainTokyoから検索要求を受け付けた場合、受信した検索条件に対して「ドキュメントファイルを除外」という条件が追加され、その後、検索処理が実行される。そして、検索処理後に取得された検索結果がそのまま検索要求元のドメインに送出される。勿論、図９に示すフィルタ処理を適用する場合には、受信した検索条件に対して取得された検索結果に対してフィルタ条件が適用され、フィルタ適用後のファイルが最終的な検索結果として検索要求元のドメインに送出される。以上により、ドメイン毎に検索結果の出力内容を最適化することができる。この機能は、輸出管理等に有効である。
【００５５】
図１１に、フィルタ管理データベース８の他の構成例を示す。図１１は、フィルタの設定処理を国別に自動実行する際に参照して好適なデータベースの一例である。図１１の場合、国名１１１とフィルタ条件１１２で構成される。なお、出力条件が最も厳しいフィルタ条件（デフォルト条件）は、図１１のデータベースの他にも設定されているものとする。この図１１の場合、米国、日本、中国が登録されている。例えば検索要求の送信元であるドメインが米国である場合、フィルタ処理部６は、検索結果にドキュメントファイルと画像ファイルが含まれないようにフィルタ処理を実行できる。すなわち、登録された国については自動的にフィルタ条件を最適化できる。なお、図１１の場合には、ドメインとして国が指定されているが、国以外のドメインについて個別のフィルタ条件を設定することもできる。
【００５６】
（他のシステム構成）
前述の説明では、１つのドメイン内にはマスター検索サーバ１が１つだけ存在する場合を想定した。しかし、図１２に示すように、１つのドメイン内に複数のマスター検索サーバ１が存在しても良い。図１２の場合、図１の構成に加えて負荷分散サーバ１２１が用意されている。負荷分散サーバ１２１は、他のドメインのマスター検索サーバ１から送信された検索要求を受信し、検索要求の転送先を振り分ける装置として機能する。すなわち、複数のマスター検索サーバ１を有するドメインとの通信は、マスター検索サーバ１同士の直接通信ではなく、負荷分散サーバ１２１を介しての通信となる。
【００５７】
負荷分散サーバ１２１は、自ドメイン内における複数のマスター検索サーバ１の負荷を監視し、検索処理の負荷がいずれかのマスター検索サーバ１に集中しないように動作する。例えば負荷分散サーバ１２１は、交互又は巡回的にマスター検索サーバ１を指定する。また例えば負荷分散サーバ１２１は、検索要求受信時における各マスター検索サーバ１の負荷の高さを参照し、負荷が少ないマスター検索サーバ１に又は複数のマスター検索サーバ１間で負荷が均等になるように検索要求の送信先を振り分ける。
【００５８】
（まとめ）
以上説明したように、ネットワーク経由で接続された複数の検索サーバ１、２で構成される検索システムにおいて、複数の検索サーバ１、２が複数のドメイン（例えば図１の場合、日本と米国）のいずれかに収容されるとき、他のドメイン（日本）から検索要求を受信した米国のマスター検索サーバ１は、同じドメイン（米国）に属する他の検索サーバ２に対して検索要求を転送する。この場合、米国のマスター検索サーバ１は、受信した検索要求に従って検索処理を実行し、同じドメインに属する他の検索サーバ２から収集された検索結果を統合、整理、整列し、当該処理後の検索結果をドメインの検索結果として他のドメイン（日本）に送信する。このとき、検索結果の一時的な統合、整理、整列が、検索要求の受信側である米国側のマスター検索サーバ１で実行されるため、検索要求をユーザから受け付けた日本側のマスター検索サーバ１に処理負荷が集中する事態を低減できる。また、検索結果を送り返す前に、検索結果の一時的な統合、整理、整列が米国側のマスター検索サーバ１で実行されるため、通信負荷も低減することができる。
【００５９】
また、検索システムを構成する全てのドメインのマスター検索サーバ１間において、検索結果の統合、整理、整列処理の内容をドメイン間の検索用に予め定め共通化しておくことにより、検索要求を受け付けた（他のドメインに対して検索要求を送信する）マスター検索サーバ１における処理負荷を低減することができる。具体的には、統合処理を省略することができる。
【００６０】
また、前述したように、ユーザから検索要求を受け付けたマスター検索サーバ１（図１の場合、DomainTokyo）は、システムを構成するドメインの数だけスレッドを作成し、同じドメインに属する他の検索サーバ２に対して検索要求を送信すると共に、他のドメイン（図１の場合、DomainOsakaとDomainSanJose）のマスター検索サーバ１に検索要求を送信する。また、日本側のマスター検索サーバ１は、各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列し、当該処理後の検索結果をユーザに提示する。すなわち、各時点で取得済みの検索結果から順番にユーザに提示する。これにより、検索結果の少なくとも一部が表示されるまでの時間を従来に比して短縮でき、検索結果が表示されるまでに要するユーザのストレスを低減することができる。
【００６１】
なお、従来システムの場合には、全ての検索サーバからの検索結果が揃うのを待って検索結果を表示する。例えばユーザからの検索要求を受け付けた検索サーバ（図１の場合、東京の事業所）からの距離が近い事業所（図１の場合、大阪の事業所）と遠い事業所（SanJoseの事業所）とが存在する場合、従来システムにおいて検索要求を発した検索サーバは、全ての事業所からの検索結果が揃った後に、統合、整理、整列を行ってから検索結果を表示する。このため、検索結果が最終的にユーザに提示されるまで処理時間が長くなり易く、ユーザに不要なストレスを与えることがあった。
【００６２】
しかし、前述の通り、実施例に係る検索システムの場合には、検索結果が受信されたドメインから順番に検索結果が提示される。このため、ユーザの待ち時間を短縮でき、ストレスを低減することができる。
【００６３】
さらに、前述したように、実施例に係る検索システムの場合には、他のドメインから検索要求を受信したマスター検索サーバ１が、他のドメインからの検索要求に対し、検索結果の出力条件が最も厳しいフィルタ処理を適用するものを提案する。または、他のドメインから検索要求を受信したマスター検索サーバが、検索要求の送信元のドメインを識別し、識別されたドメインに対応するフィルタ処理を実行する。このため、意図せぬ情報が検索結果の一部として他のドメインに送信される事態を回避できる。
【００６４】
特に、事業所が複数の国に分散して存在する場合、従来システムにおける検索結果には、国外への送信が禁止されている情報が意図せず含まれる可能性がある。しかし、実施例に係る検索システムの場合には、他国からの検索要求に対しては、最も厳しいフィルタ条件を適用するか、国別に最適化されたフィルタ条件を適用する。これにより、複数の国や地域で活動する事業者にとって安全性の高い検索システムを実現できる。
【符号の説明】
【００６５】
１…マスター検索サーバ
２…スレーブ検索サーバ
３…検索処理部
４…検索結果統合処理部
５…フィルタ管理部
６…フィルタ処理部
７…ドメイン管理データベース
８…フィルタ管理データベース
【技術分野】
【０００１】
本発明は、検索システム及び検索システムを構成する検索サーバに搭載されたコンピュータで実行されるプログラムに関する。例えば複数地点に存在する複数の検索サーバ間での検索処理の実行が想定される検索システム及び各検索サーバに搭載されたコンピュータに実行させて好適なプログラムに関する。
【背景技術】
【０００２】
今日、多くの企業では、多数の電子文書が扱われている。また、それらの企業では、多数の電子文書の管理と検索に多くの時間を要しており、結果的に多くのコストを要している。このため、電子文書のコスト削減は、企業にとって、性急に対応すべき課題となっている。
【０００３】
エンタープライズサーチは、企業内の文書検索機能を提供する検索実行装置である。エンタープライズサーチは、要求文書の検索を高速かつ正確に行うことができるため、導入事例が増えている。今後、さらなる電子文書の増加に伴い、複数のエンタープライズサーチのファイル検索結果（以下、「検索結果」という。）を統合、整理、整列する仕組みが必要になると予想される。この明細書では、この種の仕組みを「Federated Search」という。ここで、検索結果を「統合する」とは、フォーマットの異なる検索結果を予め決められたルールに従って統一することをいう。「整理する」とは、同一の検索結果を省略することをいう。「整列する」とは、ユーザによって指定されたオーダーによって検索結果を並び替えることをいう。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−７０５４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
規模の大きい企業では、検索システムを構成する検索サーバの数も大量になる。ところが、検索サーバの数が増えるのに従って、ファイル検索要求（以下、「検索要求」という。）を受け付けた検索サーバに掛かる負荷が非常に高くなる。その理由は、当該検索要求を受け付けた検索サーバが、各検索サーバの検索結果を統合する全ての処理を実行するためである。
【０００６】
また、一定規模以上の企業であれば、事業所が分散されていることが普通である。各事業所に検索サーバが配置される場合、検索要求に付随する大量のデータがインターネット経由で受け渡しされる。このため、通信負荷が高くなってしまう。
本発明は、以上の課題を解決することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、複数の検索サーバを「ドメイン」という単位にまとめ、ドメイン間で検索処理を実行する場合に適用して好適な処理機能を提供する。例えばドメインは、事業所ごと、国ごと、地域ごとに設定することができる。また、ドメインは、複数の国や地域を対象として設定することができる。
【０００８】
なお、本発明の１つの態様として、他のドメインから検索要求を受信し、マスター検索サーバとして機能する検索サーバが、同じドメインに属する他の検索サーバに対して検索要求を転送する処理と、受信した検索要求に従って検索処理を実行する処理と、同じドメインに属する他の検索サーバから収集された検索結果を統合、整理、整列する処理と、統合後の検索結果をドメインの検索結果として前記他のドメインに送信する処理とを実行するものを提案する。
【０００９】
また、本発明の１つの態様として、ユーザからの検索要求を受け付けたマスター検索サーバとして機能する検索サーバが、システムを構成するドメインの数だけスレッドを作成する処理と、同じドメインに属する他の検索サーバに対して検索要求を送信すると共に、他のドメインのマスター検索サーバに検索要求を送信する処理と、各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列する処理と、当該処理後の検索結果をユーザに提示する処理とを実行するものを提案する。
【発明の効果】
【００１０】
本発明の１つの態様によれば、他のドメインに属する検索サーバに対して検索要求を送信した検索サーバにおける負荷の集中を低減することができる。また、他のドメインに対して検索結果を送信する前に整理処理が実行されるため、通信負荷を低減することができる。
【図面の簡単な説明】
【００１１】
【図１】遠距離間を跨ぐワイドエリアサーチシステムの概略構成例を示す図。
【図２】ドメイン管理データベースに格納されているデータ例を示す図。
【図３】検索サーバがユーザから検索要求を受け付けた後、検索結果をユーザに提示するまでの処理の一例を示すフローチャート。
【図４】ドメイン毎の検索結果を個別に表示できる表示画面例を示す図。
【図５】ドメイン毎の検索結果を個別に表示できる他の表示画面例を示す図。
【図６】フィルタリング設定を行うフィルタ管理部の処理動作例を示すフローチャート。
【図７】フィルタリング設定を行うフィルタ管理部の別の処理動作例を示すフローチャート。
【図８】検索実行前にフィルタリング処理を行うフィルタ処理部の処理動作例を示すフローチャート。
【図９】検索実行後にフィルタリング処理を行うフィルタ処理部の処理動作例を示すフローチャート。
【図１０】フィルタ管理データベースのデータ構成例を示す図。
【図１１】国別に用意されたフィルタ管理データベースのデータ構成例を示す図。
【図１２】１つのドメイン内に複数のマスター検索サーバが存在する場合のシステム構成例を説明する図。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて、発明の実施形態例を説明する。なお、後述する実施形態はいずれも一例であり、本発明には、本明細書に記載する任意の機能を組み合わせることで実現されるシステム、本明細書に記載する一部の機能を周知技術で置換したシステム、本明細書に記載する機能に周知技術を追加したシステムも含まれる。また、後述する実施例で実行される機能は、計算機（コンピュータ）上で実行されるプログラムとして実現される。もっとも、プログラムの一部又は全部は、ハードウェアを通じて実現しても良い。
【００１３】
（システム構成）
図１に、実施例に係るワイドエリアサーチシステムの構成図を示す。実施例に係るワイドエリアサーチシステムは、日本と米国に跨って構成される例である。勿論、国名は一例であり、任意の国名や地域の組み合わせが考えられる。また、国や地域には、事業所、行政区域、国家間や地域を跨って設定される領域が含まれる。図１の場合、日本には２つのドメインが存在し、米国には１つのドメインが存在する。ドメインとは、検索の実行単位又は実行範囲を与える概念である。
【００１４】
各ドメインには、マスター検索サーバ１とスレーブ検索サーバ２が配置される。１つのドメインには、少なくとも１つのマスター検索サーバ１が存在する。この実施例の場合、１つのドメインには１つのマスター検索サーバ１が存在する。なお、スレーブ検索サーバ２は、１つのドメイン内に存在しない場合もある。ただし、図１の場合は、各ドメインに１つ又は２つのスレーブ検索サーバ２が存在する。
【００１５】
マスター検索サーバ１は、検索処理部３と、検索結果統合処理部４と、フィルタ管理部５と、フィルタ処理部６を有する。ここで、マスター検索サーバ１は、ドメイン内の検索処理の起点であると共に、他のドメインとの間で検索要求や検索結果を受け渡す際の窓口として機能する。一方、スレーブ検索サーバ２は、検索処理部３のみを有している。これらマスター検索サーバ１及びスレーブ検索サーバ２を構成する各処理部の具体的な機能については後述する。
【００１６】
マスター検索サーバ１は、ドメイン管理データベース７とフィルタ管理データベース８を保持し又は接続されている。ドメイン管理データベース７とフィルタ管理データベース８は、必ずしもマスター検索サーバ１と同じ筐体内、同じ部屋内、同じ施設内に存在しなくても良いが、マスター検索サーバ１が必要に応じてアクセスできることが要求される。
【００１７】
ドメイン間は、ＶＰＮ（Virtual Private Network）等の専用線で接続されている場合に限らず、ＷＡＮ（Wide Area Network）やインターネット経由で接続される場合も存在する。
【００１８】
マスター検索サーバ１とスレーブ検索サーバ２は、ＣＰＵ（Central Processing Unit）や主記憶装置等を備えるコンピュータ（計算機）として実現され、各処理部はコンピュータを通じて実行されるプログラムとして実現される。また、マスター検索サーバ１は、機能の一部としてＧＵＩ（Graphical User Interface）サーバやＣＬＩ（Command Line Interface）サーバを有し、ユーザからの検索要求を受け付ける機能を有している。なお、ユーザの操作入力には、不図示のマウス、キーボード、ポインティングデバイスその他の入力装置が使用される。
【００１９】
（ドメイン管理データベースのデータ構造）
図２に、ドメイン管理データベース７が格納する情報の一例を示す。図２の場合、ドメイン管理データベース７は、ユーザ識別ＩＤ２１、ドメイン名２２、認証サーバ２３、認証ユーザＩＤ２４、認証パスワード２５を格納する。これらの情報は、マスター検索サーバ１が他のドメインに対して検索要求を出す場合に参照される。マスター検索サーバ１は、これらの情報を利用してユーザを認証する。認証処理は、検索処理部３の機能として実行される。
【００２０】
例えば、DomainTokyoのマスター検索サーバ１にログインしたK-satoから検索要求を受け付けた場合を考える。この場合、DomainTokyoのマスター検索サーバ１は、ドメイン管理データベース７にアクセスし、検索要求を入力したユーザ（K-sato）のユーザ識別ＩＤを読み出す。図２の場合、K-satoは、操作中のマスター検索サーバ１が存在するDomainTokyoの他、DomainOsakaとDomainSanJoseの２箇所について登録されている。この場合、DomainTokyoのマスター検索サーバ１は、DomainOsakaに検索要求を出す場合にはK-satoの認証ユーザＩＤ“１”を使用し、DomainSanJoseに検索要求を出す場合にはSato-Kの認証ユーザＩＤ“１”を使用する。
【００２１】
もし、検索要求を入力したユーザが他のドメインに対するユーザアカウントを登録していない場合は、そのドメインに対する検索要求は送出されない。例えばT-suzukiは、DomainTokyoについてしかユーザアカウントが登録されていない。従って、DomainTokyoのマスター検索サーバ１にログインしたT-suzukiから検索要求が入力された場合、その検索要求は、DomainTokyoのマスター検索サーバ１から他のドメインには送信されないことになる。以上により、各ドメインのマスター検索サーバ１が、正しいユーザ権限を有するドメインに対してのみ検索を実行することが可能となる。
【００２２】
（検索結果統合処理部４の処理）
図３に、マスター検索サーバ１の検索結果統合処理部４が実行する処理動作例を示す。なお、図３に示す処理は、ユーザから検索要求を受け付けたマスター検索サーバ１の検索結果統合処理部４が実行する。
【００２３】
検索結果結合処理部４は、認証されたドメインに対して検索要求を送信する。このため、送信可能なドメインの数だけスレッドを作成する（ステップ３０１）。図２の場合、DomainTokyoのマスター検索サーバ１にログインしたK-satoから検索要求を受け付けたとき、３つのスレッドが作成される。これに対し、DomainTokyoのマスター検索サーバ１にログインしたT-suzukiから検索要求を受け付けたとき、１つのスレッドが作成される。
【００２４】
次に、検索結果統合処理部４は、ステップ３０１で作成した各スレッドを通じ、対応する各ドメインのマスター検索サーバ１に対して検索要求を送信する（ステップ３０２）。
【００２５】
この後、検索結果統合処理部４は、検索要求が送信されたドメインのマスター検索サーバ１から検索結果が取得されたか否かを判定する（ステップ３０３）。すなわち、各スレッドに対応する検索結果の受信を待ち受ける。判定時点において検索結果の取得が確認されない場合（ステップ３０３で否定結果の場合）、検索結果統合処理部４は、検索結果の待ち受け時間がタイムアウトしたか否かを判定する（ステップ３０４）。タイムアウトが検出されない場合（ステップ３０４で否定結果の場合）、検索結果統合処理部４は、ステップ３０３の判定処理に戻る。一方、タイムアウトが検出された場合（ステップ３０４で肯定結果の場合）、検索結果統合処理部４は、検索結果の待ち受け状態から抜け、ステップ３０８に移行する。
【００２６】
ここでは、検索結果の待ち受け時間中に、あるドメインから検索結果が受信された場合を考える。この場合、検索結果統合処理部４は、新たに取得した検索結果を既に取得されている検索結果の全体に統合、整理、整列する（ステップ３０５）。ここでの検索結果の整理により、最終的に表示される検索結果の全体数が必要とする件数以上に増えないようにできる。
【００２７】
なお、検索結果統合処理部４による検索結果の統合、整理、整列は、検索要求を他のドメインから受信したマスター検索サーバ１でも実行される。例えば取得したい検索結果の全体数が２０件の場合、各ドメインのマスター検索サーバ１は、最大でも２０件しか検索結果を返信しない。
【００２８】
仮に検索要求を受け付けたドメインのマスター検索サーバ１が、全体として既に１０件の検索結果を保持している場合、検索結果統合処理部４は、ステップ３０５の処理として、新たに取得した２０件の検索結果を既存の１０件の検索結果に統合した後、再び２０件に整理する。
【００２９】
ステップ３０５の処理動作の後、検索結果統合処理部４は、新たに取得したドメインからの検索結果を、不図示の表示装置の画面上に表示できる状態に制御する（ステップ３０６）。ここでの制御は、後述するようにユーザインターフェースの画面に依存する。詳細は後述するが、統合後の検索結果の表示領域の他に、各ドメインに対応する検索結果を選択的に表示できる場合、個別のドメインに対応する表示領域に、他のドメインから取得した検索結果を表示する又は表示する準備を行う。
【００３０】
次に、検索結果統合処理部４は、全てのドメインから検索結果が取得されたか否かを判定する（ステップ３０７）。検索結果が取得されていないドメインが存在する場合、検索結果統合処理部４はステップ３０３に戻り、新たな検索結果の取得を待ち受ける状態になる。一方、全てのドメインから検索結果が取得されたと判定された場合、検索結果統合処理部４は、不図示の表示装置の画面上にFederated Searchの検索結果を表示する（ステップ３０８）。
【００３１】
（検索結果の表示画面）
図４に、検索結果の表示画面例を示す。図４に示す表示画面例は、Federated Searchの検索結果が表示されるタブ画面（Federateタブ）４０１と、各ドメインに対応する３つのタブ画面４０２で構成される。Federateタブ４０１には、ユーザから検索要求を受けたマスター検索サーバ１が全てのドメインから検索結果を取得された段階で、全ドメインからの検索結果を統合し、整理し、整列した後の検索結果が一覧的に表示される。一方、タブ画面４０２には、対応するドメインから検索結果が取得された段階で検索結果が表示される。このため、ユーザは全てのドメインの検索結果が揃うまで待ち続ける必要はない。
【００３２】
なお、Federateタブ４０１及び各ドメイン専用のタブ画面４０２の表示形態は、検索結果の表示の準備が完了した段階で変化することが望ましい。例えば表示色が変化する、表示枠の太さが変化する、模様が変化する、輝度が変化する、表示位置が変化する表示の大きさが変化する等の制御を適用することが望ましい。これら表示形態の変化により、ユーザはどのタブが参照可能であるかを知ることができ、Federateタブ４０１が完了するまでの間に他の結果を参照することが可能となる。
【００３３】
図４の場合、検索結果の表示画面の左側には、ドメイン選択用の領域４０３が用意される。領域４０３を使用可能な場合、ユーザは、検索要求を送信するドメインに対応する領域４０３にチェックを入れる。これにより、不必要なドメインに対して検索要求が送信される事態を回避でき、その分、通信負荷と全ての検索結果が取得されるまでの時間の短縮を実現できる。ユーザは、Federateタブ４０１又は各ドメイン専用のタブ画面４０２を選択することにより、検索結果一覧４０４を参照することができる。
【００３４】
なお、Federateタブ４０１及び各ドメイン専用のタブ画面４０２そのものが、検索結果が取得された順番に追加的に表示されるようにしても良い。図４の場合であれば、検索結果の表示画面には、DomainTokyoのタブ画面４０２が最初に表示され、次にDomainOsakaのタブ画面４０２が先の１つに追加的に表示され、最後にDomainSanJoseのタブ画面４０２が先の２つに追加的に表示され、最後にFederated Searchのタブ画面が追加的に表示されるようにしても良い。最終的には、図４に示すように、４つのタブ画面が表示される。この場合も、ユーザは全てのドメインの検索結果が揃うまで待ち続ける必要はない。
【００３５】
図５に、検索結果の表示画面の別例を示す。図５に示す表示画面例は、ユーザから検索要求を受けたマスター検索サーバ１が、各ドメインから新たな検索結果が取得されるたび、既存の検索結果一覧５０１に追加するように表示していく。図の例では、DomainTokyoが一番最初に結果を返し、次にDomainOsakaが結果を返したため、先頭にDomainTokyoの結果が、その後ろにDomainOsakaの結果が続く形になっている。なお、全てのドメインから検索結果が得られた段階で、表示画面の表示内容をFederateタブ４０１（図４）の表示内容に変更しても良い。
【００３６】
（フィルタ管理部５の処理）
図６に、マスター検索サーバ１のフィルタ管理部５が実行する処理動作例を示す。フィルタ管理部５は、フィルタの強度を管理する機能を提供する。
【００３７】
フィルタ管理部５は、他のドメインから検索対象に追加された場合に動作する（ステップ６０１）。フィルタ管理部５は、自ドメインを検索対象に追加した他のドメインに対する検索結果の出力に対し、出力条件が最も厳しいフィルタを自動的に適用する（ステップ６０２）。その理由は、他のドメインの検索対象に自ドメインが追加された段階では、どのフィルタ強度を適用すれば良いのか一意に決定できないためである。このため、新規のドメイン登録には安全性が最も高い、換言すると最も出力条件が厳しいフィルタを適用する。
【００３８】
この後、フィルタ管理部５は、自ドメインのマスター検索サーバ１の管理者に宛ててメールを送信する（ステップ６０３）。自装置のドメインが検索対象に設定されたとの通知を受けた管理者は、自ドメインを検索対象に追加した他のドメインに対して適切なフィルタを設定する（ステップ６０４）。自ドメインを検索対象に設定した他のドメインが、自ドメインと同じ国内の場合、全くフィルタを掛けない設定にすることもできる。また、自ドメインを検索対象に設定した他のドメインが、自国と特定の関係にある国の場合、当該国にのみ有効な固有のフィルタを設定することもできる。
【００３９】
なお、ステップ６０１からステップ６０４までの間に検索要求が受信された場合、フィルタ管理部５は、最も強いフィルタを適用する。ステップ６０４で適切なフィルタを設定した後に検索要求が受信された場合、フィルタ管理部は、最も強いフィルタではなく、ステップ６０４で設定されたフィルタを適用する。
【００４０】
図７に、マスター検索サーバ１のフィルタ管理部５が実行する他の処理動作例を示す。フィルタ管理部５は、他のドメインから検索対象として追加された場合に動作する（ステップ７０１）。この点は、図６に示す処理動作と同じである。次に、フィルタ管理部５は、後述する国別フィルタ管理データベースを参照し、追加要求を出したドメインが属する国用のフィルタが用意されているか否かを判定する（ステップ７０２）。フィルタが用意されていない場合、フィルタ管理部５は、フィルタ管理データベース８から最も強いフィルタを取得する（ステップ７０３）。一方、フィルタが用意されている場合、フィルタ管理部５は、国別フィルタ管理データベースから該当するフィルタ条件を取得する（ステップ７０４）。その後、フィルタ管理部５は、フィルタ管理データベース８に対し、ドメイン名とフィルタ条件を追加する（ステップ７０５）。
【００４１】
（フィルタ処理部６の処理）
図８に、他のドメインから検索要求を受けたマスター検索サーバ１のフィルタ処理部６が実行する処理動作を示す。図８は、検索実行前にフィルタを適用する方式を採用する場合のフローチャートを示している。
【００４２】
フィルタ処理部６は、他のドメインから検索要求を受信することで動作を開始する（ステップ８０１）。まず、フィルタ処理部６は、検索要求の送信元であるドメイン用のフィルタが設定されているか否かを判定する（ステップ８０２）。
【００４３】
否定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されていない場合）、フィルタ処理部６は、予め管理者が用意している最も強度の高い（安全の高い）フィルタを適用する（ステップ８０３）。一方、肯定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されている場合）、フィルタ処理部６は、設定されているフィルタを読み出して適用する（ステップ８０４）。
【００４４】
続いて、フィルタ処理部６は、検索要求を受け付けた検索キーワードに対し、ステップ８０３又はステップ８０４で確定したフィルタ（出力条件）を追加する（ステップ８０５）。すなわち、受け付けた検索キーワードにフィルタ（出力条件）を付加したものを、自ドメイン内で使用する検索キーワードとする。図８のうちフィルタ処理部６の処理動作は、当該ステップまでである。
【００４５】
この後、ステップ８０５で作成された検索キーワードは、マスター検索サーバ１の検索処理部３に与えられる。検索処理部３は、検索要求元に応じて最適化された検索キーワードを用いて自ドメイン内を検索する（ステップ８０６）。その後、検索処理部３は、最終的に取得された検索結果を、自ドメインにおける検索結果として、検索要求の送信元のドメインに宛てて送信する（ステップ８０７）。
【００４６】
もっとも、フィルタの適用手法はこれに限らない。図９に、他のドメインから検索要求を受けたマスター検索サーバ１のフィルタ処理部６が実行する別の処理動作例を示す。図９は、検索実行後にフィルタを適用する方式を採用する場合のフローチャートを示している。すなわち、検索実行後にフィルタ条件を適用し、フィルタ条件で出力が禁止されたファイルを出力対象から除外する方式を採用する。
【００４７】
まず、フィルタ処理部６は、他のドメインから検索要求を受信することで動作を開始する（ステップ９０１）。この場合、フィルタ処理部６は、検索処理部３に検索の実行を指示する。検索処理部３は、検索要件に規定されている検索キーワードに基づいて自ドメイン内を検索する（ステップ９０２）。この時点では、検索キーワードのみに応じた検索結果が取得される。この後、検索結果はフィルタ処理部６に与えられる。
【００４８】
次に、フィルタ処理部６は、検索要求の送信元であるドメイン用のフィルタが設定されているか否かを判定する（ステップ９０３）。
【００４９】
否定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されていない場合）、フィルタ処理部６は、予め管理者が用意している最も強度の高い（安全の高い）フィルタを検索結果に対して適用する（ステップ９０４）。すなわち、予め管理者が用意している最も強度が高い（安全性の高い）フィルタ条件を検索結果に適用する。具体的には、フィルタ条件に該当するファイルを、ステップ９０２で取得された検索結果から除外する。
【００５０】
一方、肯定結果が得られた場合（検索要求の送信元であるドメイン用のフィルタが設定されている場合）、フィルタ処理部６は、設定されているフィルタを読み出して検索結果に適用する（ステップ９０５）。すなわち、特定のドメイン用に最適化されている強度のフィルタ条件を検索結果に適用する。この場合も、フィルタ条件の強度が異なるだけで、フィルタ条件に該当するファイルを、ステップ９０２で取得された検索結果から除外する。
【００５１】
その後、フィルタ処理部６は、最終的に取得された検索結果を、自ドメインにおける検索結果として、検索要求の送信元のドメインに宛てて送信する（ステップ９０６）。なお、検索結果の他のドメインに対する送信は、検索処理部３を通じて実行しても良い。
【００５２】
（フィルタ管理データベースのデータ構造）
図１０に、フィルタ管理データベース８が格納する情報の一例を示す。図１０の場合、フィルタ管理データベース８は、ドメイン名１０１とフィルタ条件１０２で構成される。このフィルタ管理データベース８は、他のドメインから検索要求を受け付けた場合に適切なフィルタを適用するために参照される。
【００５３】
図１０は、最も出力条件が厳しい（安全性が高い）デフォルトのフィルタ条件と、DomainTokyo用のフィルタ条件だけが設定された状態を示している。この例の場合、デフォルトのフィルタ条件として、他のドメインに対して出力する検索結果から、画像ファイルと、音声ファイルと、ドキュメントファイルを除外することが規定されている。一方、DomainTokyo用のフィルタ条件として、他のドメインに対して出力する検索結果からドキュメントファイルを除外すること、すなわち画像ファイルと音声ファイルは検索結果に含めて良いことが規定されている。
【００５４】
例えば図８に示すフィルタ処理を適用する場合であれば、DomainTokyo以外のドメインから検索要求を受け付けた場合、受信した検索条件に対して「ドキュメントファイルと、画像ファイルと、音声ファイルを除外」という条件が追加され、その後、検索処理が実行される。そして、検索処理後に取得される検索結果はそのまま検索要求元のドメインに送出される。一方、DomainTokyoから検索要求を受け付けた場合、受信した検索条件に対して「ドキュメントファイルを除外」という条件が追加され、その後、検索処理が実行される。そして、検索処理後に取得された検索結果がそのまま検索要求元のドメインに送出される。勿論、図９に示すフィルタ処理を適用する場合には、受信した検索条件に対して取得された検索結果に対してフィルタ条件が適用され、フィルタ適用後のファイルが最終的な検索結果として検索要求元のドメインに送出される。以上により、ドメイン毎に検索結果の出力内容を最適化することができる。この機能は、輸出管理等に有効である。
【００５５】
図１１に、フィルタ管理データベース８の他の構成例を示す。図１１は、フィルタの設定処理を国別に自動実行する際に参照して好適なデータベースの一例である。図１１の場合、国名１１１とフィルタ条件１１２で構成される。なお、出力条件が最も厳しいフィルタ条件（デフォルト条件）は、図１１のデータベースの他にも設定されているものとする。この図１１の場合、米国、日本、中国が登録されている。例えば検索要求の送信元であるドメインが米国である場合、フィルタ処理部６は、検索結果にドキュメントファイルと画像ファイルが含まれないようにフィルタ処理を実行できる。すなわち、登録された国については自動的にフィルタ条件を最適化できる。なお、図１１の場合には、ドメインとして国が指定されているが、国以外のドメインについて個別のフィルタ条件を設定することもできる。
【００５６】
（他のシステム構成）
前述の説明では、１つのドメイン内にはマスター検索サーバ１が１つだけ存在する場合を想定した。しかし、図１２に示すように、１つのドメイン内に複数のマスター検索サーバ１が存在しても良い。図１２の場合、図１の構成に加えて負荷分散サーバ１２１が用意されている。負荷分散サーバ１２１は、他のドメインのマスター検索サーバ１から送信された検索要求を受信し、検索要求の転送先を振り分ける装置として機能する。すなわち、複数のマスター検索サーバ１を有するドメインとの通信は、マスター検索サーバ１同士の直接通信ではなく、負荷分散サーバ１２１を介しての通信となる。
【００５７】
負荷分散サーバ１２１は、自ドメイン内における複数のマスター検索サーバ１の負荷を監視し、検索処理の負荷がいずれかのマスター検索サーバ１に集中しないように動作する。例えば負荷分散サーバ１２１は、交互又は巡回的にマスター検索サーバ１を指定する。また例えば負荷分散サーバ１２１は、検索要求受信時における各マスター検索サーバ１の負荷の高さを参照し、負荷が少ないマスター検索サーバ１に又は複数のマスター検索サーバ１間で負荷が均等になるように検索要求の送信先を振り分ける。
【００５８】
（まとめ）
以上説明したように、ネットワーク経由で接続された複数の検索サーバ１、２で構成される検索システムにおいて、複数の検索サーバ１、２が複数のドメイン（例えば図１の場合、日本と米国）のいずれかに収容されるとき、他のドメイン（日本）から検索要求を受信した米国のマスター検索サーバ１は、同じドメイン（米国）に属する他の検索サーバ２に対して検索要求を転送する。この場合、米国のマスター検索サーバ１は、受信した検索要求に従って検索処理を実行し、同じドメインに属する他の検索サーバ２から収集された検索結果を統合、整理、整列し、当該処理後の検索結果をドメインの検索結果として他のドメイン（日本）に送信する。このとき、検索結果の一時的な統合、整理、整列が、検索要求の受信側である米国側のマスター検索サーバ１で実行されるため、検索要求をユーザから受け付けた日本側のマスター検索サーバ１に処理負荷が集中する事態を低減できる。また、検索結果を送り返す前に、検索結果の一時的な統合、整理、整列が米国側のマスター検索サーバ１で実行されるため、通信負荷も低減することができる。
【００５９】
また、検索システムを構成する全てのドメインのマスター検索サーバ１間において、検索結果の統合、整理、整列処理の内容をドメイン間の検索用に予め定め共通化しておくことにより、検索要求を受け付けた（他のドメインに対して検索要求を送信する）マスター検索サーバ１における処理負荷を低減することができる。具体的には、統合処理を省略することができる。
【００６０】
また、前述したように、ユーザから検索要求を受け付けたマスター検索サーバ１（図１の場合、DomainTokyo）は、システムを構成するドメインの数だけスレッドを作成し、同じドメインに属する他の検索サーバ２に対して検索要求を送信すると共に、他のドメイン（図１の場合、DomainOsakaとDomainSanJose）のマスター検索サーバ１に検索要求を送信する。また、日本側のマスター検索サーバ１は、各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列し、当該処理後の検索結果をユーザに提示する。すなわち、各時点で取得済みの検索結果から順番にユーザに提示する。これにより、検索結果の少なくとも一部が表示されるまでの時間を従来に比して短縮でき、検索結果が表示されるまでに要するユーザのストレスを低減することができる。
【００６１】
なお、従来システムの場合には、全ての検索サーバからの検索結果が揃うのを待って検索結果を表示する。例えばユーザからの検索要求を受け付けた検索サーバ（図１の場合、東京の事業所）からの距離が近い事業所（図１の場合、大阪の事業所）と遠い事業所（SanJoseの事業所）とが存在する場合、従来システムにおいて検索要求を発した検索サーバは、全ての事業所からの検索結果が揃った後に、統合、整理、整列を行ってから検索結果を表示する。このため、検索結果が最終的にユーザに提示されるまで処理時間が長くなり易く、ユーザに不要なストレスを与えることがあった。
【００６２】
しかし、前述の通り、実施例に係る検索システムの場合には、検索結果が受信されたドメインから順番に検索結果が提示される。このため、ユーザの待ち時間を短縮でき、ストレスを低減することができる。
【００６３】
さらに、前述したように、実施例に係る検索システムの場合には、他のドメインから検索要求を受信したマスター検索サーバ１が、他のドメインからの検索要求に対し、検索結果の出力条件が最も厳しいフィルタ処理を適用するものを提案する。または、他のドメインから検索要求を受信したマスター検索サーバが、検索要求の送信元のドメインを識別し、識別されたドメインに対応するフィルタ処理を実行する。このため、意図せぬ情報が検索結果の一部として他のドメインに送信される事態を回避できる。
【００６４】
特に、事業所が複数の国に分散して存在する場合、従来システムにおける検索結果には、国外への送信が禁止されている情報が意図せず含まれる可能性がある。しかし、実施例に係る検索システムの場合には、他国からの検索要求に対しては、最も厳しいフィルタ条件を適用するか、国別に最適化されたフィルタ条件を適用する。これにより、複数の国や地域で活動する事業者にとって安全性の高い検索システムを実現できる。
【符号の説明】
【００６５】
１…マスター検索サーバ
２…スレーブ検索サーバ
３…検索処理部
４…検索結果統合処理部
５…フィルタ管理部
６…フィルタ処理部
７…ドメイン管理データベース
８…フィルタ管理データベース
【特許請求の範囲】
【請求項１】
ネットワーク経由で接続された複数の検索サーバで構成される検索システムにおいて、
前記複数の検索サーバは複数のドメインのいずれかに収容されるとき、
他のドメインから検索要求を受信してマスター検索サーバとして機能する検索サーバが、同じドメインに属する他の検索サーバに対して検索要求を転送する処理と、受信した検索要求に従って検索処理を実行する処理と、同じドメインに属する他の検索サーバから収集された検索結果を統合、整理、整列する処理と、当該処理後の検索結果をドメインの検索結果として前記他のドメインに送信する処理とを実行する
ことを特徴とする検索システム。
【請求項２】
請求項１に記載の検索システムにおいて、
前記検索結果を統合、整理、整列する処理の内容は、ドメイン間の検索用に予め定め共通化されている
ことを特徴とする検索システム。
【請求項３】
請求項１に記載の検索システムにおいて、
ユーザからの検索要求を受け付けたマスター検索サーバとして機能する検索サーバは、システムを構成するドメインの数だけスレッドを作成する処理と、同じドメインに属する他の検索サーバに対して検索要求を送信すると共に、他のドメインのマスター検索サーバに検索要求を送信する処理と、各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列する処理と、当該処理後の検索結果をユーザに提示する処理とを実行する
ことを特徴とする検索システム。
【請求項４】
請求項３に記載の検索システムにおいて、
統合後の検索結果をユーザに提示する前記処理は、
各時点で存在する前記統合後の検索結果が表示される第１のタブ画面と、各ドメインに専用の検索結果が表示される第２のタブ画面とのそれぞれに対応する検索結果を表示すると共に、各ドメインに対応する検索結果の取得状態を識別可能に表示する
ことを特徴とする検索システム。
【請求項５】
請求項３に記載の検索システムにおいて、
ドメインの検索結果をユーザに提示する前記処理は、各ドメインのマスター検索サーバから当該ドメインの検索結果が取得される度、取得済みの検索結果の表示領域に、新たに取得したドメインの検索結果を追加的に表示する
ことを特徴とする検索システム。
【請求項６】
請求項１に記載の検索システムにおいて、
他のドメインから検索要求を受信した前記マスター検索サーバは、他のドメインからの検索要求に対し、検索結果の出力条件が最も厳しいフィルタ処理を適用する
ことを特徴とする検索システム。
【請求項７】
請求項１に記載の検索システムにおいて、
他のドメインから検索要求を受信した前記マスター検索サーバは、検索要求の送信元のドメインを識別する処理と、識別されたドメインに対応するフィルタ処理を実行する処理とを適用する
ことを特徴とする検索システム。
【請求項８】
ネットワーク経由で接続された複数の検索サーバで構成される検索システムにおいて、前記複数の検索サーバが複数のドメインのいずれかに収容されるとき、
他のドメインから検索要求を受信してマスター検索サーバとして機能する検索サーバに搭載されるコンピュータに、
同じドメインに属する他の検索サーバに対して検索要求を転送する処理と、
受信した検索要求に従って検索処理を実行する処理と、
同じドメインに属する他の検索サーバから収集された検索結果を統合、整理、整列する処理と、
当該処理後の検索結果をドメインの検索結果として前記他のドメインに送信する処理と
を実行させることを特徴とするプログラム。
【請求項９】
ネットワーク経由で接続された複数の検索サーバで構成される検索システムにおいて、前記複数の検索サーバが複数のドメインのいずれかに収容されるとき、
ユーザからの検索要求を受け付けたマスター検索サーバとして機能する検索サーバに搭載されるコンピュータに、
システムを構成するドメインの数だけスレッドを作成する処理と、
同じドメインに属する他の検索サーバに対して検索要求を送信すると共に、他のドメインのマスター検索サーバに検索要求を送信する処理と、
各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列する処理と、
当該処理後の検索結果をユーザに提示する処理と
を実行させることを特徴とするプログラム。
【請求項１】
ネットワーク経由で接続された複数の検索サーバで構成される検索システムにおいて、
前記複数の検索サーバは複数のドメインのいずれかに収容されるとき、
他のドメインから検索要求を受信してマスター検索サーバとして機能する検索サーバが、同じドメインに属する他の検索サーバに対して検索要求を転送する処理と、受信した検索要求に従って検索処理を実行する処理と、同じドメインに属する他の検索サーバから収集された検索結果を統合、整理、整列する処理と、当該処理後の検索結果をドメインの検索結果として前記他のドメインに送信する処理とを実行する
ことを特徴とする検索システム。
【請求項２】
請求項１に記載の検索システムにおいて、
前記検索結果を統合、整理、整列する処理の内容は、ドメイン間の検索用に予め定め共通化されている
ことを特徴とする検索システム。
【請求項３】
請求項１に記載の検索システムにおいて、
ユーザからの検索要求を受け付けたマスター検索サーバとして機能する検索サーバは、システムを構成するドメインの数だけスレッドを作成する処理と、同じドメインに属する他の検索サーバに対して検索要求を送信すると共に、他のドメインのマスター検索サーバに検索要求を送信する処理と、各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列する処理と、当該処理後の検索結果をユーザに提示する処理とを実行する
ことを特徴とする検索システム。
【請求項４】
請求項３に記載の検索システムにおいて、
統合後の検索結果をユーザに提示する前記処理は、
各時点で存在する前記統合後の検索結果が表示される第１のタブ画面と、各ドメインに専用の検索結果が表示される第２のタブ画面とのそれぞれに対応する検索結果を表示すると共に、各ドメインに対応する検索結果の取得状態を識別可能に表示する
ことを特徴とする検索システム。
【請求項５】
請求項３に記載の検索システムにおいて、
ドメインの検索結果をユーザに提示する前記処理は、各ドメインのマスター検索サーバから当該ドメインの検索結果が取得される度、取得済みの検索結果の表示領域に、新たに取得したドメインの検索結果を追加的に表示する
ことを特徴とする検索システム。
【請求項６】
請求項１に記載の検索システムにおいて、
他のドメインから検索要求を受信した前記マスター検索サーバは、他のドメインからの検索要求に対し、検索結果の出力条件が最も厳しいフィルタ処理を適用する
ことを特徴とする検索システム。
【請求項７】
請求項１に記載の検索システムにおいて、
他のドメインから検索要求を受信した前記マスター検索サーバは、検索要求の送信元のドメインを識別する処理と、識別されたドメインに対応するフィルタ処理を実行する処理とを適用する
ことを特徴とする検索システム。
【請求項８】
ネットワーク経由で接続された複数の検索サーバで構成される検索システムにおいて、前記複数の検索サーバが複数のドメインのいずれかに収容されるとき、
他のドメインから検索要求を受信してマスター検索サーバとして機能する検索サーバに搭載されるコンピュータに、
同じドメインに属する他の検索サーバに対して検索要求を転送する処理と、
受信した検索要求に従って検索処理を実行する処理と、
同じドメインに属する他の検索サーバから収集された検索結果を統合、整理、整列する処理と、
当該処理後の検索結果をドメインの検索結果として前記他のドメインに送信する処理と
を実行させることを特徴とするプログラム。
【請求項９】
ネットワーク経由で接続された複数の検索サーバで構成される検索システムにおいて、前記複数の検索サーバが複数のドメインのいずれかに収容されるとき、
ユーザからの検索要求を受け付けたマスター検索サーバとして機能する検索サーバに搭載されるコンピュータに、
システムを構成するドメインの数だけスレッドを作成する処理と、
同じドメインに属する他の検索サーバに対して検索要求を送信すると共に、他のドメインのマスター検索サーバに検索要求を送信する処理と、
各時点までに取得された各ドメインの検索結果を対象として統合、整理、整列する処理と、
当該処理後の検索結果をユーザに提示する処理と
を実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−２０４０５８（Ｐ２０１１−２０４０５８Ａ）
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願番号】特願２０１０−７１４１７（Ｐ２０１０−７１４１７）
【出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
[ Back to top ]