JP2004530990A - 持続的サーチセンターを実施するシステム及び方法 - Google Patents

Abstract

本発明の１つの特徴による方法は、ユーザがユーザセッションを開始するためにサーチツールバーからサーチアイコンを選択した後にサーチセンターペインを表示することを含む。このサーチセンターペインは、サーチフレームを含む。このサーチフレームは、クローズボタンを含む。又、上記方法は、サーチフレームにおいてサーチカテゴリーのドロップダウンリストからサーチカテゴリーを選択することも含む。上記方法は、更に、サーチキーワードを入力することを含む。更に、サーチカテゴリー及びサーチキーワードに一致するデータレコードに対してデータベースをサーチすることも含む。更に、上記方法は、サーチカテゴリー及びサーチキーワードに一致する上記データレコードをキャッシュ処理して、ユーザがユーザセッションを終了するためにクローズボタンを選択するまで、データレコードの持続性を維持することも含む。

Description

【技術分野】
【０００１】
本発明は、一般に、データ処理の分野に係る。より詳細には、本発明は、持続的で且つ却下可能なサーチセンターフレームを実施するためのシステム及び方法に係る。
【背景技術】
【０００２】
技術が進歩を続けそしてビジネス環境が益々複雑で多様になるにつれて、益々多くの会社が、それら企業ビジネスの種々の観点を遂行し且つ管理するために、種々の顧客関係管理（ＣＲＭ）ソフトウェア及びｅビジネスアプリケーションに依存するようになった。一般に、ｅビジネスアプリケーションは、会社又は企業が、双方向ネットワーク（例えば、インターネット、イントラネット、エクストラネット、等）を経て、その顧客、パートナー、供給者、ディストリビュータ、従業員等とビジネスを遂行できるように設計されている。ｅビジネスアプリケーションは、コアビジネスプロセス、供給チェーン、バックオフィスオペレーション及びＣＲＭファンクションを含む。ＣＲＭは、一般に、セールス及び／又はサービスに関して会社がその顧客と共に有する相互作用の種々の観点を含む。高いレベルにおいては、顧客関係管理が、顧客のニーズを理解し、その知識をレバレッジして、セールスを増加し、サービスを改善することに集中する。ＣＲＭアプリケーション及びソフトウェアは、一般に、セールスとサービスとの間に有効且つ効率的な相互作用を与え、そして顧客にまつわる会社の活動を統合して、顧客のシェア、及び顧客の満足度による顧客の維持を高めるように設計される。
【０００３】
典型的に、ＣＲＭ実施の戦略は、次のことを考慮する必要がある。
− 知識管理：有効なＣＲＭ実施の重要なファクターの１つは、顧客に関する情報の収集、その分析、分担及び追跡である。又、競合的効果に対し知識の使用に一体的なものは、この知識の結果としてどんなアクションをとるべきか従業員が知ることである。
− データベースの合併：有効で且つ効率的なＣＲＭ解決策の別の重要な観点は、単一データベースにおける顧客情報の合併と、顧客にまつわるビジネスプロセスの再エンジニアリングである。ここでの目標は、１つの場所に記録された顧客との全ての相互作用を行って、製造、マーケッティング、セールス及び顧客サポート活動を推進することである。
【０００４】
− チャンネル及びシステムの一体化：ＣＲＭアプリケーション／ソフトウェアは、ｅ−メールであるか、電話であるか、ウェブベースのユーザインターフェイス等であるかに拘らず、選択チャンネルを経て、一貫したそして高クオリティのやり方で顧客に応答する能力を与えることが非常に重要である。これは、種々の通信チャンネルと顧客又は企業データベースとの繋ぎ目のない一体化を必要とする。又、ＣＲＭと会社のビジネスシステム及びアプリケーションの他の部分との一体化も必要とする。
【０００５】
− テクノロジー及びインフラストラクチャー：顧客のサービスを改善するために、ＣＲＭアプリケーション／ソフトウェアは、オンライン顧客サービスを自動化し且つ簡素化するための種々のツールを含む。例えば、自己ヘルプモデルは、通常、ツールを組み合せて使用して実施することができる（例えば、直感的サーチ能力、エージェント技術又は自動化ｅ−メール等を伴う知識ベース）。
【０００６】
一般に、ｅビジネスアプリケーションは、ウェブ、コールセンター、フィールド、転売、小売及びディーラーネットワークを含む多数のチャンネルにわたって顧客への販売、市場調査及びサービスを容易にする顧客情報の単一ソースを組織的に生成できるように設計される。進歩型ｅビジネスアプリケーションは、通常、コンポーネントベースのアーキテクチャー上に構築され、そしてウェブベースであって、多数のコンピュータプラットホームにおいて移動クライアント、接続クライアント、シンクライアント及びハンドヘルドクライアント等を含む種々の形式のクライアントに対するサポートを与えるように設計される。
【０００７】
顧客アテンションに対する強力な競争、普及したチャンネル拡張、及びインターネットエクスプロージョンは、顧客選択の大量に生じる空前のレベルである。正しい解決策がある状態では、各相互作用は、顧客又は拡張された住居の独特のニーズを良好に理解する機会を与える。各相互作用の間に捕獲された（例えば、コールセンターを経て）顧客情報に資本投資することにより、顧客の目標を満足するように商品及びサービスの最良の組合せを示唆し、顧客が忠実なままでいる機会を高めることができる。
【０００８】
従来、コールセンターの役割は、サービスの停止を報告する顧客からの電話コールを取り扱い、サービスをアクチベート又はキャンセルし、或いは標準的な課金及び集金問題について問合せすることに限定されている。成功の手段は、サービスを効率良く配送すると共に、顧客コールセンターをできるだけ安価に運営することに基づいている。顧客の相互作用は、ビジネスを行う「コスト」と考えられる。
【０００９】
しかしながら、顧客が各通信チャンネルを経て一貫したサービス及びセールスサポートを要求するにつれて、コールセンターは、完全な顧客コンタクトセンターへと迅速に進化する。全ての顧客相互作用に対するサポートを益々与えるために、コールセンターの重要性は、迅速に上昇している。典型的に、コールセンターは、現在、次の能力を与える解決策を実施する。
− エージェントが単一のユーザインターフェイスを経てマルチメディア相互作用を取り扱うのを許す使い易い一体化エージェントデスクトップ；
【００１０】
− 電話、ｅ−メール、ウェブチャット、ウェブボイス、ファックス及びページを含む全ての通信チャンネルにわたって各相互作用の完全な知識を各エージェントが有するように確保するための顧客の合併されたビュー；
− 仕事が最も効率的なやり方で取り扱われそしてビジネスプロセス及びポリシーが常に実施されるように確保するためのワークフロー自動化及びダイナミックスクリプト；
【００１１】
− インバウンド及びアウトバウンドテレセール、ｅ−メール応答及びウェブキャンペーンを含む一体化されたセールス、マーケティング及び顧客サービス；及び
− 所有権の全コストを最小にするために迅速なアプリケーション展開及び既成の解決策を許す包括的ウェブベースアーキテクチャー。
【００１２】
上記能力をサポートするために、顧客関連情報を記憶する広範囲なデータベースが必要とされる。時々、この広範囲なデータベースのユーザは、データベースをサーチし、そして情報の記録又は断片を迅速に検索できることが重要である。例示的な筋書きにおいて、計算サポートグループのマネージャーは、顧客のアカウントに関する情報を見出すよう試み且つ特定のマーケッティング文献項目を要求している顧客からコールを受け取る。この例示的筋書きでは、広範囲なデータベースを経て迅速且つ効率的に精査して、顧客が要求した情報を探索することのできる中央ファシリティをもつことが非常に望ましい。
【発明を実施するための最良の形態】
【００１３】
本発明の特徴及び効果は、添付図面を参照することにより完全に理解されよう。
以下の詳細な説明において、本発明を完全に理解するために多数の特定の細部について述べる。しかしながら、当業者であれば、これらの特定の細部がなくても、本発明を理解しそして実施できることが明らかである。
【００１４】
Ｉ．システムの概要及び全体的アーキテクチャー
一実施形態において、本発明の教示が実施されるシステムは、図１に示す多層アーキテクチャーとして論理的に構成することができる。一実施形態において、図１に示す論理的多層アーキテクチャーは、種々のアプリケーションをサポートするための通常のサービスのためのプラットホームを与える。これらのサービスは、ユーザインターフェイス層１１０、オブジェクトマネージャー層１２０、データマネージャー層１３０、及びデータ交換層１４０を含む。
【００１５】
一実施形態において、ユーザインターフェイス層１１０は、１つ以上のアプリケーションに関連したアプレット、ビュー、チャート及びレポート等を与える。一実施形態では、ユーザインターフェイス層１１０を経て種々の形式のクライアントをサポートすることができる。これら種々の形式のクライアントは、慣例的に接続されるクライアント、リモートクライアント、イントラネットを経てのシンクライアント、Ｊａｖａ（登録商標）シンクライアント又は非ウインドウズベースのオペレーティングシステム、及びインターネットを経てのＨＴＭＬクライアント等を含む。
【００１６】
一実施形態において、オブジェクトマネージャー層１２０は、１つ以上のアプリケーションに関連した１セット以上のビジネスルール又はビジネスコンセプトを管理し、そしてユーザインターフェイス層１１０とデータマネージャー層１３０との間にインターフェイスを与えるように設計される。一実施形態において、ビジネスルール又はコンセプトは、ビジネスオブジェクトとして表わすことができる。一実施形態において、ビジネスオブジェクトは、アカウント、コンタクト、機会、サービス要求、解決策等の種々のビジネスルール又はコンセプトのコンフィギュレーション可能なソフトウェア表示として設計される。
【００１７】
一実施形態において、データマネージャー層１３０は、その下のデータの論理的なビューを維持し、そしてオブジェクトマネージャーが、データが記憶されたその下のデータ構造体又はテーブルとは独立して機能できるように設計される。一実施形態では、データマネージャー１３０は、データをアクセスするためにリアルタイムで構造問合せ言語（ＳＱＬ）を発生するといった幾つかのデータベース問合せファンクションも与える。一実施形態では、データマネージャー１３０は、データベーススキーマを定義する貯蔵ファイル１６０においてオブジェクト定義に対して動作するように設計される。一実施形態において、データ記憶サービス１７０は、１つ以上のアプリケーションに関連したデータモデルに対するデータ記憶を与える。
【００１８】
一実施形態において、データ交換層は、１つ以上の特定のターゲットデータベースとの相互作用を取り扱うと共に、データマネージャー層１３０とその下のデータソースとの間のインターフェイスを与えるように設計される。
図２は、図１に示された多層システムアーキテクチャーに含まれる種々のシステムコンポーネントを示す。
【００１９】
一実施形態において、多層アーキテクチャーは、１つ以上のソフトウェア層が異なるマシンに常駐できるようにする。例えば、一実施形態において、ユーザインターフェイス、オブジェクトマネージャー及びデータマネージャーは、全て、接続されたクライアント及び移動クライアントに常駐することができる。シンクライアントの場合、一実施形態では、オブジェクトマネージャー及びデータマネージャーは、システムサーバーに常駐することができる。別の例として、ユーザインターフェイスは、ＨＴＭＬクライアントに対してシステムサーバーに常駐する。当業者であれば、図２に示すシステムコンフィギュレーションは、説明上のものに過ぎず、本発明の教示の特定の実施及びアプリケーションに基づいて変化し得ることが明らかであり且つ理解されよう。
【００２０】
一実施形態において、図２に示すシステム環境は、２つ以上のデータベース２９０を含む。データベース２９０の１つ以上のサブセットを、レプリケーションマネージャーにより生成又は複写することができる。更に、移動クライアントは、付加的なリモートデータベース（ローカルデータベースとも称される）をもつこともできる。一実施形態において、移動クライアントに関連したリモート又はローカルデータベースがリードオンリーデータベースとして定義されない限り、これらの移動クライアントは、データをローカルで生成及び更新することができ、このデータは、最終的に、各移動クライアントがシステムサーバーと同期したときに一次データベースまで伝播される。
【００２１】
一実施形態において、データベース２９０は、予め定義されたデータスキーマ（例えば、テーブルオブジェクト、インデックスオブジェクト等）、貯蔵オブジェクト（例えば、ビジネスオブジェクト及びコンポーネント、ビュー定義及び可視性ルール等）、及びユーザ又は顧客のデータを含む種々の形式のデータを記憶するように設計される。一実施形態では、シンクライアントと共に動作するものを含む接続クライアント及びサーバーコンポーネントは、データベース２９０に直結して、リアルタイムで変化することができる。一実施形態では、移動クライアントは、サーバーデータのサブセットをローカルで使用するようにダウンロードし、そしてシステムサーバーを経てサーバーデータベースと周期的に同期して、ローカル及びサーバーデータベースの両方を更新することができる。
【００２２】
一実施形態において、ファイルシステム２９５は、アプリケーションサーバーに配置することのできるネットワークアクセス可能なディレクトリーである。一実施形態では、ファイルシステム２９５は、種々のアプリケーションにより生成された物理的ファイル、例えば、第三者テキストエディタにより生成されたファイル、及びデータベース２９０に記憶されない他のデータを記憶する。一実施形態において、ファイルシステム２９５に記憶される物理的ファイルは、種々のネーミング規定のもとで圧縮して記憶することができる。一実施形態において、接続クライアントは、ファイルをファイルシステム２９５から直接読み取り且つそれに書き込むことができる。一実施形態において、移動クライアントは、サーバーベースのファイルシステム２９０と周期的に同期させるところのローカルファイルシステムをもつことができる。一実施形態において、シンクライアントは、システムサーバーを経てファイルシステム２９０へアクセスする。
【００２３】
一実施形態では、企業サーバー２５０は、システムサーバー２５５の論理的グループで、これらシステムサーバーは、共通のテーブル所有者又はデータベースを共用し、共通のゲートウェイサーバーを指し、そしてサーバーマネージャー２６０を使用するグループとして管理することができる。一実施形態において、ゲートウェイサーバーへの接続は、ＴＣＰ／ＩＰを経て確立することができる。一実施形態では、企業サーバー２５０は、この企業サーバー２５０に多数のシステムサーバー２５５を配備することにより効果的に拡張することができ、従って、アプリケーションの中間段において高度の拡張性を与えることができる。
【００２４】
一実施形態において、サーバー２５５は、１つ以上の多数のサーバープログラムを実行する。これは、到来する処理要求を取り扱い、そしてサーバー上の全てのプロセスの状態を監視する。一実施形態では、サーバープログラムは、データをインポート及びエクスポートし、データベースをコンフィギュレーションし、ワークフロー及びプロセスオートメーションを実行し、データ同期及びレプリケーションに対して移動クライアントをサポートするように処理し、そしてビジネスルールを実施する等を含む１つ以上の特定ファンクション又はジョブを遂行するように設計され、構成される。一実施形態において、サーバー２５５は、ＮＴサービス（ウインドウズＮＴオペレーティングシステムのもとにある）であるか又はＵＮＩＸ（登録商標）オペレーティングシステムのもとにあるデーモン（例えば、バックグランドシェルプロセス）である。一実施形態において、サーバー２５５は、マルチプロセス及びマルチスレッドコンポーネントの両方をサポートし、そしてバッチ、サービス及び双方向モードにおいてコンポーネントを動作することができる。
【００２５】
一実施形態において、サーバーマネージャーは、サーバー２５５及び企業サーバー２５０に対する異なるプログラムにわたり共通の制御、管理及び監視を許すユーティリティとして構成される。一実施形態では、サーバーマネージャーは、次のタスクを実行するのに使用できる。即ち、サーバー２５５、コンポーネント及びタスクをスタートし、ストップし、休止し、及び再開し；企業サーバー内の多数のタスク、コンポーネント及びサーバーに対する状態を監視し、そして統計学的情報を収集し；そして企業サーバー、個々のサーバー、個々のコンポーネント、及びタスク等をコンフィギュレーションする。
【００２６】
一実施形態において、ゲートウェイサーバーは、サーバーにアクセスするための単一のエントリーポイントとして働く論理的エンティティとして構成することができる。一実施形態において、これは、企業サーバーにわたり改善された拡張性、負荷バランス及び高い利用性を与えるように使用できる。一実施形態において、ゲートウェイサーバーは、ネームサーバー及び接続仲介コンポーネントを含む。一実施形態において、ネームサーバーは、サーバーに関連したパラメータを追跡するように構成される。例えば、サーバーに関連した利用性及び接続性情報をネームサーバーに記憶することができる。システム内の種々のコンポーネントは、サーバーの利用性及び接続性に関する種々の情報についてネームサーバーに問合せすることができる。ウインドウズＮＴ環境では、ネームサーバーは、ＮＴサービスとして実行することができる。ＵＮＩＸ環境では、ネームサーバーは、デーモンプロセスとして実行することができる。一実施形態において、接続仲介コンポーネントは、クライアント接続要求を適当なサーバー（例えば、最もビジーでないサーバー）に向けるような負荷バランスファンクションを実行するように使用される。
【００２７】
一実施形態では、図２に示すように、システムによりサポートできる種々の形式のクライアントは、次のクライアントを含む。即ち、接続クライアント、移動クライアント、ＨＴＭＬシンクタイアント、ワイヤレスクライアント、ウインドウズのシンクライアント、及びＪａｖａのシンクライアント、等々。
【００２８】
一実施形態において、接続（専用とも称する）クライアントは、ＬＡＭ又はＷＡＮ接続を経てデータアクセスするためにデータベースサーバーに直結される。一実施形態において、これらの接続又は専用クライアントは、データをローカルに記憶しない。又、これらの接続クライアントは、ファイルシステムに直接アクセスすることができる。一実施形態では、移動クライアントは、ローカルデータアクセスするように設計及び構成され、従って、それら自身のローカルデータベース及び／又はローカルファイルシステムをもつことができる。一実施形態では、移動クライアントは、ゲートウェイサーバーを経てシステム内の他のコンポーネントと対話することができる。同期により、ローカルデータベース及びサーバーデータベースからの変更を交換することができる。
【００２９】
一実施形態では、ＨＴＭＬシンクライアントは、ウェブベースのアプリケーションをカスタマイズしそして実施するのに使用される１組のコンポーネントを含む。これらＨＴＭＬシンクライアントは、一実施形態では、サーバー、データベース及びウェブサーバー等を含む大きなシステムコンフィギュレーションの一部分である。ウェブアプリケーション、ウェブサーバー延長、ウェブエンジン及び種々のテンプレートを含むＨＴＭＬシンクライアントシステムコンフィギュレーションの主要コンポーネントが、図３に示されている。一実施形態において、ワイヤレスクライアントは、本質的に、ワイヤレス装置においてイネーブルされるシンクライアントである。ワイヤレスクライアントは、ワイヤレスアプリケーションプロトコル（ＷＡＰ）ベースのユーザインターフェイスを使用して、システムサーバーと情報／データを通信及び交換することができる。一実施形態において、ウインドウズのシンクライアント及びＪａｖａのシンクライアントは、システムに接続されたマシンからネットワークを経てアプリケーションに動的にアクセスすることができる。システムは、種々のデータベース、テーブル、ファイルシステム等を参照して、一例として以下に詳細に説明する。
【００３０】
ＩＩ．ｅサーチアプリケーション／システム及び関連システムコンポーネント
図４は、本発明の一実施形態による例示的サーチツールバー４００を示す。この実施形態では、サーチツールバー４００は、ドロップダウンリスト４０５、編集ボタン４１０、及びサーチアイコン４１５を含む。ドロップダウンリスト４０５から、ユーザは、コンテンツエリア又はサーチフレームをポピュレートするためのアイテムを選択することができる。コンテンツエリアフレーム及びサーチフレームに関する更なる詳細が図５に示され、この図を参照して以下に説明する。
【００３１】
編集ボタン４１０は、通常、サーチフレームをオープンして、ユーザがドロップダウンリスト４０５のアイテムを変更又は削除できるようにするために使用される。サーチアイコン４１５は、一般に、サーチセンターフレーム又はペインをオープンするのに使用される。サーチセンターフレーム又はペインの更なる詳細が、図５に示され、この図を参照して以下に説明する。
【００３２】
図５は、本発明の一実施形態による例示的サーチセンターフレーム又はペイン５００を示す。サーチセンターフレーム又はペイン５００は、ツールバーセクション５０５、コンテンツエリアフレーム５１０、サーチフレーム５１５及び結果フレーム５２０を含む。サーチツールバー４００（図４に示す）は、ツールバーセクション５０５に保持される。コンテンツエリアフレーム５１０は、一般に、サーチから得られる選択されたサーチ結果のコンテンツを表示するのに使用される。サーチフレーム５１５は、図２４及び２５に詳細に示され、これらの図を参照して以下に説明する。結果フレーム５２０は、通常、サーチから得られるサーチ結果のリストを表示するのに使用される。
【００３３】
サーチオブジェクト
サーチを実行する前に、幾つかのサーチオブジェクトを構成又は生成することが必要である。図６は、種々のサーチオブジェクトを生成する例示的プロセス６００を一般的に示すフローチャートである。この例示的プロセスは、次の動作を含むことができる。
− サーチエンジンオブジェクトがまだ存在しない場合には１つ以上のサーチエンジンオブジェクトを生成する（ブロック６１０）；
− １つ以上のサーチインデックスオブジェクトを生成し、そしてその生成されたサーチインデックスオブジェクトを１つ以上のビジネスコンポーネントオブジェクトに関連付ける（ブロック６１５）；
【００３４】
− １つ以上のサーチカテゴリーオブジェクトを生成し、そしてその生成されたサーチカテゴリーオブジェクトをサーチインデックスオブジェクトに関連付ける（ブロック６２０）；及び
− １つ以上のサーチ定義オブジェクトを生成する（ブロック６２５）。各サーチ定義オブジェクトは、ブロック６２９で生成される１つ以上のサーチカテゴリーオブジェクトのグループを表わすことに注意されたい。上記動作の各々を以下に詳細に説明する。
【００３５】
サーチエンジン
図７は、本発明の一実施形態によりサーチエンジンオブジェクトを生成する例示的プロセス７００を一般的に示すフローチャートである。各サーチエンジンオブジェクトの生成は、一般に、サーチエンジンオブジェクトを定義し（ブロック７１０）、そしてその定義されたサーチエンジンオブジェクトに関連した結果フィールドを生成又は構成する（ブロック７１５）ことを含む。
【００３６】
図８は、本発明の一実施形態によるサーチエンジンオブジェクト８００の特性を一般的に示す。この実施形態において、サーチエンジンオブジェクト８００は、一般に、サーチエンジンを表わし、そして２つの特性：ネーム８０５及びクラス８１０を含むことができる。ネーム８０５は、一般に、サーチエンジンのネーム、例えば、「ファルクラム(Fulcrum)」を指す。クラス８１０は、一般に、ネームが付けられたサーチエンジンに関連したサーチアダプタのクラスネームを指す。
【００３７】
各サーチエンジンは、それに関連した結果フィールドのデフォールトセットを有する。付加的な結果フィールドが生成されて、結果フィールドのデフォールトセットに追加される。結果フィールドオブジェクトは、一般に、結果フィールドを各サーチエンジンに関連付けるのに使用される。一実施形態では、各結果フィールドオブジェクトは、以下のルール及び仮定のもとで動作する。第１に、親のサーチエンジンオブジェクト、又は結果フィールドに関連したサーチエンジンに属するサーチテーブルに対して、定義された結果フィールドが一般的に生成される。第２に、定義された結果フィールドの幾つかを、サーチ定義ごとにカスタマイズすることができる。サーチ定義ごとに結果フィールドをカスタマイズするのに使用されるカスタム結果フィールドを以下に説明する。
【００３８】
図９は、本発明の一実施形態による例示的結果フィールドオブジェクト９００の特性を一般に示す。この実施形態では、結果フィールドオブジェクト９００は、次の特性を含むことができる。即ち、列ネーム９０５、生成列フラグ９１０、データタイプ９１５、インデックスモード９２０、ネーム９２５、テキスト長さ９３０、及びタイプ９３５。従って、結果フィールドオブジェクト９００の生成は、上記特性の幾つか又は全部を定義することを含む。結果フィールドオブジェクト９００の上記特性の中で、列ネーム９０５、ネーム９２５及びタイプ９３５は、必要な特性であり、そして生成列フラグ９１０、データタイプ９１５、インデックスモード９２０及びテキスト長さ９３０は、任意の特性である。
【００３９】
列ネーム９０５は、一般に、サーチインデックスにおける物理的列のネームである。列ネーム９０５は、異なる形式のデータベースソフトウェアに対して異なってもよい。ネーム９２５は、一般に、結果フィールドの論理的ネームである。タイプ９３５は、有効値を表示するピックリストを表わす。生成列フラグ９１０は、ユーザにより列を明確に生成する必要があるかどうか示す。データタイプ９１５は、列のデータ形式を特定する。データタイプ９１５の値は、例えば、「ｖａｒｃｈａｒ」、「ｃｈａｒａｃｔｅｒ」及び「ａｐｖａｒｃｈａｒ」を含む。インデックスモード９２０は、列のインデックスモードを特定する。インデックスモード９２０の値は、例えば、「ｌｉｔｅｒａｌ」、「ｎｏｎｅ」及び「ｎｏｒｍａｌ」を含む。テキスト長さ９３０は、結果フィールドに対して割り当てられねばならない記憶バイト量を特定する。
【００４０】
サーチインデックス
図１０は、本発明の一実施形態によりサーチインデックスオブジェクトを生成する例示的プロセス１０００を一般的に示すフローチャートである。各サーチインデックスオブジェクトの生成は、サーチインデックスオブジェクトを定義し（ブロック１０１０）、その定義されたサーチインデックスオブジェクトに対してサーチテーブルオブジェクトを生成し（ブロック１０１５）、その生成されたサーチテーブルオブジェクトに対して１つ以上のインデックスフィールドオブジェクトを生成し（ブロック１０２０）、そしてその生成されたサーチテーブルオブジェクトに対して１つ以上のフィルタフィールドオブジェクトを生成する（ブロック１０２５）ことを含む。各サーチインデックスオブジェクトの定義（ブロック１０１０）は、選択されたサーチエンジンによりインデックスされる必要のある１つ以上のビジネスコンポーネントを識別し、そしてサーチインデックスオブジェクトを生成して、その生成されたサーチインデックスオブジェクトを各識別されたビジネスコンポーネントに関連付けることを含む。
【００４１】
図１１は、本発明の一実施形態による例示的サーチインデックスオブジェクト１１００の特性を一般的に示す。図示されたように、各サーチインデックスオブジェクト１１００は、次の特性を有することができる。即ち、ネーム１１０５、インデックスビジネスコンポーネント１１１０、及びデータベーステーブルフラグ１１１５。ネーム１１０５は、サーチインデックスオブジェクト１１００の論理的ネームを含み、これは、必要な特性である。インデックスビジネスコンポーネント１１１０、及びデータベーステーブルフラグ１１１５は、任意のフィールドである。インデックスビジネスコンポーネント１１１０は、一般に、サーチインデックスオブジェクト１１００がマップするところのビジネスコンポーネントである。インデックスビジネスコンポーネント１１１０は、ビジネスコンポーネントが外部ディレクトリーをベースとする場合にはナルであることに注意されたい。データベーステーブルフラグ１１１５は、一般に、サーチインデックスオブジェクト１１００が物理的データベーステーブルへとマップするかどうか指示する。
【００４２】
各定義されたサーチインデックスオブジェクトに対して各サーチテーブルオブジェクトを生成及び構成する（図１０のブロック１０１５）ことは、一般に、選択されたサーチエンジン内にあって且つサーチインデックスを物理的に表わす物理的インデックステーブル又は集合にサーチインデックスを関連付けることを含む。図１２は、本発明の一実施形態による例示的サーチテーブルオブジェクト１２００の特性を一般に示す。一実施形態において、サーチテーブルオブジェクト１２００は、次の所要特性をもつことができる。即ち、テーブルネーム１２０５、及びエンジン１２１０。テーブルネーム１２０５は、サーチインデックスを物理的に表わす物理的インデックステーブル又は集合の実際の名前を一般的に特定する。エンジン１２１０は、選択されたサーチエンジンの名前、例えば、「ファルクラム」を含む。
【００４３】
図１３は、本発明の一実施形態による各生成されたサーチテーブルに対するインデックスフィールドマップオブジェクトを生成する例示的プロセス１３００を一般的に示すフローチャートである。インデックスフィールドマップオブジェクトは、サーチインデックスを指すことが必要なビジネスコンポーネントフィールドを一般的に示す。一実施形態では、インデックスフィールドマップオブジェクトは、図７に示すように生成されるサーチエンジンに関連された結果フィールドにビジネスコンポーネントフィールドをマップするのに一般的に使用できる。各生成されたサーチテーブルオブジェクトに対する各インデックスフィールドマップオブジェクトを生成しそして構成するプロセス１３００は、一般に、希望のビジネスコンポーネントを選択し（ブロック１３１０）、その選択されたビジネスコンポーネントを結果フィールドへマップし（ブロック１３２０）、そしてインデックスフィールドタイプ１３２５を選択することを含む。
【００４４】
インデックスフィールドタイプ１３２５は、１つ以上のアタッチされたドキュメント又はファイルに対して全テキストサーチを実行すべきであることを示すファイルアタッチメントを特定できることに注意されたい。換言すれば、インデックスフィールドタイプ１３２５がファイルアタッチメントを特定する場合には、そのファイルアタッチメントにより示された１つ以上のアタッチされたファイルにおいて全テキストサーチが実行される。
【００４５】
図１４Ａは、本発明の一実施形態による例示的インデックスフィールドオブジェクト１４００の特性を一般的に示す。この実施形態において、インデックスフィールドオブジェクト１４００は、次の特性を含むことができる。即ち、ビジネスコンポーネントフィールド１４１０、結果フィールド１４１５、インデックスフィールドタイプ１４２０、及びシーケンス１４２５。上記特性のうち、ネーム１４０５、ビジネスコンポーネントフィールド１４１０、及びシーケンス１４２５は、必要なものであり、そして結果フィールド１４１５及びインデックスフィールドタイプ１４２０は、任意である。ビジネスコンポーネントフィールド１４１０は、親のサーチインデックスオブジェクトに関連したアプレット又はビジネスコンポーネントのアクティブなフィールドを一般的に表わす。アクティブなフィールドは、選択されたサーチアクションに含まれることに注意されたい。シーケンス１４２５は、一般に、ビジネスコンポーネントフィールドがデータベーステーブルから読み取られるシーケンスである。結果フィールド１４１５は、インデックスフィールドがマップするところの結果を表わす。インデックスフィールドタイプ１４２０は、ビジネスコンポーネントフィールド１４１０において識別されたビジネスコンポーネントの形式を特定する。インデックスフィールドタイプ１４２０の値は、例えば、「行Ｉｄ」、「グループ」、「アタッチメント」、「改訂番号」、「組織的可視性」及び「グループ可視性」を含むことができる。インデックスフィールドタイプ１４２０に与えられる情報は、ランタイムに、ある特殊な処理を行うのに使用される。例えば、ビジネスコンポーネントフィールドＩｄは、通常、データベーステーブルの各行に対して行Ｉｄを保持する。それ故、「行Ｉｄ」のインデックスフィールドタイプを特定することは、インデックスされた列の値を行の識別子として識別し、従って、容易に検索及び処理を行うのに使用できる。
【００４６】
フィルタフィールドオブジェクトを生成し又は構成することは、一般に、結果フィールドとは別にそしてそれに加えて、親のサーチテーブルへとインデックスされるべきビジネスコンポーネントのフィールドを識別しそして定義することを含む。換言すれば、各サーチテーブルは、選択されたサーチエンジンに対して定義された結果フィールドと、サーチテーブルに対して定義されたフィルタフィールドとの必須セットを受け継ぐ。一般に、フィルタフィールドオブジェクトは、サーチ結果を限定するのに使用されるフィルタフィールドを定義する。これらのフィルタフィールドは、通常、サーチテーブルオブジェクトにより定義されるサーチテーブルへインデックスされる。
【００４７】
図１４Ｂは、本発明の一実施形態による例示的フィルタフィールドオブジェクト１４５０の特性を一般的に示す。この実施形態では、フィルタフィールドオブジェクト１４５０は、次の特性を含む。即ち、ネーム１４５５、列ネーム１４６０、データタイプ１４６５、インデックスモード１４７０、シーケンス１４７５、及びテキスト長さ１４８０。上記特性の中で、ネーム１４５５、列ネーム１４６０、及びシーケンス１４７５は、必要なものであり、そしてデータタイプ１４６５、インデックスモード１４７０及びテキスト長さ１４８０は、任意である。ネーム１４５５は、親のサーチインデックスオブジェクトに関連したビジネスコンポーネントのアクティブなフィールドを一般に表わす。列ネーム１４６０は、親のサーチインデックスの物理的な列の名前である。列ネーム１４６０は、異なる形式のデータベースソフトウェアと共に変化してもよいことに注意されたい。シーケンス１４７５は、フィルタフィールドが生成されるシーケンスを一般的に示す。データタイプ１４６５は、物理的列のデータ形式を特定する。データタイプ１４６５の値は、例えば、「ｖａｒｃｈａｒ」及び「ｃｈａｒ」を含むことができる。インデックスモード１４７０は、物理的列のインデックスモードを特定する。インデックスモード１４７０の値は、例えば、「ｌｉｔｅｒａｌ」、「ｎｏｎｅ」及び「ｎｏｒｍａｌ」を含むことができる。テキスト長さ１４８０は、生成されているフィルタフィールドに割り当てられるバイトで記憶の量を表わす。
【００４８】
サーチカテゴリー
図１５は、サーチカテゴリーオブジェクトを生成しそして構成する例示的プロセス１５００を一般に示すフローチャートである。サーチカテゴリーオブジェクトを生成しそして構成することは、サーチカテゴリーを定義し（ブロック１５１０）そしてその定義されたサーチカテゴリーをサーチインデックスに関連付ける（ブロック１５１５）ことを含む。サーチカテゴリーを生成しそして構成することは、更に、定義されたサーチカテゴリーに関するサーチ結果をナビゲートするときに使用されるべきドリルダウンビュー、ドリルダウンビジネスコンポーネント、及び行先フィールドを定義することを含む（ブロック１５２０）。又、サーチカテゴリーを生成しそして構成することは、サーチ結果をアタッチメントとして受け取ることのできるピックビューを定義することも含む（ブロック１５２５）。
【００４９】
各サーチカテゴリーオブジェクトは、一般に、サーチを実行できるところのサーチカテゴリーを表わす。各サーチカテゴリーオブジェクトは、一般に、サーチインデックスオブジェクトへマップすることに注意されたい。又、特定のサーチインデックスオブジェクトを１つ以上のサーチカテゴリーオブジェクトに関連させ又は関係付けできることにも注意されたい。
【００５０】
図１６は、本発明の一実施形態による例示的サーチカテゴリーオブジェクト１６００の特性を一般的に示す。この実施形態において、各サーチカテゴリーオブジェクト１６００は、次の特性を含む。即ち、ネーム１６０５、サーチインデックス１６１０、ドリルダウンビジネスコンポーネント１６１５、ドリルダウンビュー１６２０、及び結果識別子１６２５。上記特性の中で、ネーム１６０５及びサーチインデックス１６１０は、必要なものであり、そしてドリルダウンビジネスコンポーネント１６１５、ドリルダウンビュー１６２０、及び結果識別子１６２５は、任意である。ネーム１６０５は、一般に、サーチカテゴリーに対する論理的ネームを表わす。サーチインデックス１６１０は、一般に、サーチカテゴリーに関連したサーチインデックスオブジェクトの認識である。ドリルダウンビジネスコンポーネント１６１５は、ユーザがドリリングするところの行先ビジネスコンポーネントを現す。ドリルダウンビュー１６２０は、一般に、ユーザがドリルダウンするときに現われるビューである。結果識別子１６２５は、サーチ結果の概要列に使用される頭字語を一般に表わす。
【００５１】
サーチカテゴリーオブジェクトを使用して、ユーザは、同じサーチインデックスに基づいて多数のサーチカテゴリーを定義することができ、従って、異なるドリルダウンビュー及びピックビューを定義することができる。例えば、ソルーションコールセンターカテゴリーは、ソルーションレゾルーションドキュメントビューへドリルダウンすることができ、そしてソルーションｅサービスカテゴリーは、ソルーションリゾルーションｅサービスビューへドリルダウンすることができる。更に、ピックビューは、異なるサーチカテゴリーに対して異なるやり方で定義することができる。
【００５２】
親のサーチカテゴリーオブジェクトに対して１つ以上のピックビューオブジェクトを生成することは、一般に、サーチ結果を関連付けることのできるアプレットを識別することを含む。図１７は、本発明の一実施形態による例示的ピックビューオブジェクト１７００の特性を一般的に示す。この実施形態において、各ピックビューオブジェクト１７００は、次の特性を含むことができる。即ち、アプレット１７０５、ビュー１７１０、ネーム１７１５、及び行先フィールド１７２０。上記特性のうち、アプレット１７０５、ビュー１７１０及びネーム１７１５は、必要なものであるが、行先フィールド１７２０は、任意である。アプレット１７０５は、一般に、選択されたサーチ結果を受け取ることのできるアプレットのネームを表わす。ビュー１７１０は、一般に、アプレット１７０５を含むビューのネームである。ネーム１７１５は、一般に、ピックビューの論理的ネームを表わす。行先フィールド１７２０は、一般に、選択されたサーチ結果を受け取るように指定されたフィールドのネームである。
【００５３】
サーチ定義
図１８Ａは、サーチ定義オブジェクトを生成しそして構成する例示的プロセス１８００を一般に示すフローチャートである。サーチ定義オブジェクトを生成することは、一般に、サーチ定義に対してネームを特定し（ブロック１８１０）、そしてサーチ結果を分類するための仕様を与える（ブロック１８１５）ことを含む。サーチ定義は、一般に、サーチカテゴリーのグループ分けである。ユーザは、通常、アプリケーションに対して１つ以上のサーチ定義を与えることができる。サーチ定義オブジェクトが生成された後に、１つ以上のサーチカテゴリーオブジェクトをサーチ定義オブジェクトに関連付けることができる（ブロック１８２０）。一実施形態において、親のサーチ定義に関連したサーチカテゴリーオブジェクトは、サーチインデックスに関連したサーチカテゴリーとは異なる特性を含む。更に、１つ以上のカスタム結果フィールドオブジェクトをサーチ定義オブジェクトに対して生成することができる（ブロック１８２５）。
【００５４】
図１８Ｂは、本発明の一実施形態によるサーチ定義オブジェクト１８５０の特性を一般的に示す。この実施形態では、サーチ定義オブジェクト１８５０は、次の特性を含むことができる。即ち、ネーム１８５５、及び分類仕様１８６０。ネーム１８５５は、必要とされる特性であるが、分類仕様１８６０は、任意の特性である。ネーム１８５５は、一般に、サーチ定義の論理的ネームを表わす。分類仕様１８６０は、一般に、返送された記録を順序付けするのに使用される分類表現である。分類仕様１８６０に対する値は、例えば、「ＳＣＯＲＥ ＤＥＳＣ」及び「ＦＩＬＥＮＡＭＥ ＡＳＣ」を含むことができる。
【００５５】
図１９は、本発明の一実施形態によるサーチ定義に関連した例示的サーチカテゴリーオブジェクト１９００の特性を一般的に示す。この実施形態では、サーチ定義に関連したサーチカテゴリーオブジェクト１９００は、次の特性を含むことができる。即ち、ネーム１９０５、表示ネーム１９１０、フィルタサーチ仕様１９１５、使用フィルタサーチ１９２０、及びシーケンス１９２５。上記特性のうち、ネーム１９０５及び表示ネーム１９１０は、必要とされるものであるが、フィルタサーチ仕様１９１５、使用フィルタサーチ１９２０、及びシーケンス１９２５は、任意である。ネーム１９０５は、一般に、サーチカテゴリーを識別する。表示ネーム１９１０は、一般に、サーチカテゴリーの実際の表示ネームを表わす。一実施形態において、表示ネーム１９１０は、基本サーチアプレット又は進歩型サーチアプレットのカテゴリードロップダウンフィールドに現われる。フィルタサーチ仕様１９１５は、フィルタフィールドに適用される。使用フィルタサーチ１９２０は、フィルタサーチをサーチカテゴリーに適用すべき場合に「真」にセットしなければならない。シーケンス１９２５は、一般に、親のアプリケーションに対するサーチアプレットにおいてサーチカテゴリーがリストされる順序を特定する。
【００５６】
親のサーチ定義オブジェクトに対し１つ以上のカスタム結果フィールドオブジェクトを生成することは、一般に、結果フィールドに対してサーチ実行又は表示特性を特定することを含む。図２０は、本発明の一実施形態による例示的カスタム結果フィールドオブジェクト２０００の特性を一般的に示す。この実施形態では、カスタム結果フィールドオブジェクト２０００は、次の特性を含むことができる。即ち、表示ネーム２００５、表示フォーマット２０１０、ネーム２０１５、スケーリングファクター２０２０、シーケンス２０２５、テキスト整列２０３０、サーチへの使用２０３５、可視２０４０、及び巾２０４５。上記特性のうち、ネーム２０１５及びシーケンス２０２５は、必要とされるものである。ネーム２０１５は、一般に、カスタム結果フィールドの論理的ネームを表わす。シーケンス２０２５は、一般に、列が現われるべき順序を特定する。表示ネーム２００５、表示フォーマット２０１０、スケーリングファクター２０２０、テキスト整列２０３０、サーチへの使用２０３５、可視２０４０及び巾２０４５は、任意の特性である。表示ネーム２００５は、ユーザインターフェイスにおいて表示するためのネームである。表示フォーマット２０１０は、一般に、データに適用するためのフォーマットマスクを指示する。スケーリングファクター２０２０は、一般に、数字列に対する乗算ファクターを表わす。テキスト整列２０３０は、一般に、列におけるテキストの整列を特定する。サーチへの使用２０３５は、一般に、列をサーチに含ませるべきかどうか指示する。可視２０４０は、カスタム結果フィールドを表示すべき場合に「真」にセットすることができる。巾２０４５は、一般に、表示列の巾をピクセルで特定する。
【００５７】
図２１は、上述した例示的サーチオブジェクト間の関係の概要を示す。図示されたように、あるオブジェクトは、別のオブジェクトに対して１：１の関係をもつことができる。例えば、サーチカテゴリーオブジェクトとドリルダウンビューオブジェクトとの間に１：１の関係がある。更に、あるオブジェクトは、別のオブジェクトに対して１：Ｍの関係をもつことができる。例えば、サーチエンジンオブジェクトに関係するか又は関連付けされる多数のサーチ定義オブジェクトがある。
【００５８】
サーチ管理
サーチ管理は、一般に、選択されたサーチエンジン（例えば、ファルクラム）に対してサーチインデックスを生成しそして管理するための通常のツールである。一実施形態において、サーチインデックスを生成しそして管理することは、テーブル及びインデックスを管理するためのサーチインデックス管理（例えば、生成、インデックス、リフレッシュ等）と、サーチプロセス全体にわたって使用されるサーチ特性を設定するためのサーチ設定管理とを含む２つの主たる領域を包囲する。
【００５９】
サーチインデックス管理
サーチインデックスを管理するためのプロセスを開始するために、ユーザ又は管理者は、サーチインデックスビューへナビゲートする。図３０は、本発明の一実施形態による例示的サーチインデックスビュー３０００を示す。ユーザ又は管理者は、一般に、このサーチインデックスビューを使用して、新たなインデックスを生成し、選択された既存のインデックスをリフレッシュし、そして全ての既存のインデックスをリフレッシュすることができる。サーチインデックスビューは、サーチ管理設定リストアプレット３００５及びサーチインデックスリストアプレット３０１０の２つのアプレットを含む。サーチ管理設定リストアプレット３００５は、サーチインデックスビュー３０００の上部に表示される。サーチ管理設定リストアプレット３００５は、一般に、既存の管理設定を表示及び操作するか又は新たな管理設定を生成するのに使用できる。
【００６０】
サーチインデックスリストアプレット３０１０は、サーチインデックスビュー３０００の下部に表示される。一実施形態において、サーチインデックスリストアプレット３０１０は、リードオンリーアプレットとして実施される。サーチインデックスリストアプレット３０１０は、一般に、入手可能な全てのサーチインデックスオブジェクトのリストを表示する。サーチインデックスオブジェクトの説明は、サーチオブジェクトのセクションにおいて上述した。一実施形態において、サーチインデックスリストアプレットは、インデックス、リフレッシュ及び全リフレッシュを含む多数の方法をサポートする。インデックスは、一般に、新たなサーチインデックスを生成するのに使用できる。リフレッシュは、一般に、選択されたサーチインデックスを再インデックスするのに使用できる。全リフレッシュは、一般に、全ての有効で且つ既存のサーチインデックスを再インデックスするのに使用できる。
【００６１】
サーチ設定管理
サーチ設定の管理は、ランタイム特性を構成するためのサーチ実行設定と、サーチインデックスの管理又は生成中に使用される特性を構成するためのサーチ管理設定とを含む２つの主たる領域に分割することができる。
【００６２】
図３１は、本発明の一実施形態による例示的サーチ実行設定ビュー３１００を示す。このサーチ実行設定ビュー３１００は、サーチ設定リストアプレット３１０５と、サーチ設定特性リストアプレット３１１０との２つのアプレットを含む。ユーザ又は管理者は、一般に、サーチ実行設定ビュー３１００を使用して、選択されたサーチエンジン（例えば、ファルクラム）に対する特性を定義する。これら特性は、ネーム−値対としてリストされ、そして選択されたサーチエンジンを使用して所与のデータベースに対して行われたサーチに適用される。
【００６３】
サーチ設定リストアプレット３１０５は、サーチ実行設定ビュー３１００の上部に表示される。サーチ設定リストアプレット３１０５は、一般に、使用可能な設定のリストを示す。サーチ設定特性リストアプレット３１０５は、サーチ実行設定ビュー３１００の下部に表示される。サーチ設定特性リストアプレット３１０５は、一般に、基本的及び進歩型サーチ実行特性のリストを示す。特性は、例えば、同義語サーチ、ワード由来、スペルチェック、及び関連性ランク付けのための値を含むことができる。
【００６４】
図３２は、本発明の一実施形態による例示的サーチ管理設定ビュー３２００を示す。このサーチ管理設定ビューは、サーチ管理設定リストアプレット３２０５と、サーチ管理設定特性リストアプレット３２１０との２つのアプレットを含む。ユーザ又は管理者は、一般に、サーチ管理設定ビュー３２００を使用して、サーチ管理設定及び特性を定義する。サーチ管理設定リストアプレット３２０５は、サーチ管理設定ビュー３２００の上部に表示される。サーチ管理設定リストアプレット３２０５は、一般に、使用可能な設定のリストを示す。サーチ管理設定特性リストアプレット３２１０は、サーチ管理設定ビュー３２００の下部に表示される。サーチ管理設定特性リストアプレット３２１０は、一般に、サーチ管理特性のリストを示す。サーチ管理特性は、例えば、「キャラクタセット」３２１５であり、これは、「ＷＩＮ＿ＬＡＴＩＮ１」３２２０にセットすることができる。この「ＷＩＮ＿ＬＡＴＩＮ１」３２２０は、インデックスを生成している間に、選択されたサーチエンジンがタイプＬａｔｉｎ１のキャラクタを予想できることを示す。
【００６５】
サーチ実行
図２２は、本発明の一実施形態によりサーチをいかに実行するかの例示的プロセス２２００を一般的に示すフローチャートである。図２３は、本発明の一実施形態によるシステム２３００のブロック図である。上述したように、このシステムは、種々のデータベース、テーブル、ファイルシステム等を参照して一例として以下に説明する。しかしながら、当業者であれば、本発明の教示は、他の形式のデータベース、テーブル、ファイルシステム等にも適用できることが理解されよう。更に、以下のプロセスの説明は、図２２及び２３を参照して行うことにも注意されたい。
【００６６】
サーチを実行するために、ユーザは、一般に、サーチセンターユーザインターフェイスを経てサーチ基準を選択し又は特定する。一実施形態において、サーチ基準は、サーチカテゴリー及びサーチテキスト又はキーワードを含む。ユーザは、同時に多数のサーチカテゴリーを選択できることに注意されたい。サーチオブジェクトのセクションで上述したように、サーチカテゴリーを表わすサーチカテゴリーオブジェクトを生成しそしてサーチインデックス又はサーチ定義に関連付けることができる。ユーザは、サーチカテゴリー（１つ又は複数）を選択し、そしてサーチテキスト又はキーワードを入力した後に、サーチボタンを選択して、サーチを実行する。図２２のブロック２２１０において、ユーザ選択されたサーチカテゴリー及びユーザ入力されたサーチテキスト又はキーワードが受け取られる。
【００６７】
図２２のブロック２２１５において、選択されたサーチカテゴリー及びサーチテキスト又はキーワードは、サーチ実行仮想ビジネスコンポーネント（ＶＢＣ）２３０５（図２３に示す）へ通される。仮想ビジネスコンポーネント２３０５、２３１０（図２３に示す）は、一般に、外部データをビジネスコンポーネントして表わし、これは、一般に、データベーステーブル上のラッピング層を与える。仮想ビジネスコンポーネント２３０５、２３１０を使用することにより、外部データ（例えば、オラクルデータベース又はＳＡＰＲ／３データベースのデータ）を表わすことができる。更に、ビジネスサービスを使用してデータを転送することができる。その結果、データの複写を回避することができ、そしてレガシー及び非レガシーデータの一体的プレゼンテーションを得ることができる。
【００６８】
サーチカテゴリー（１つ又は複数）及びサーチテキスト又はキーワードがサーチ実行ＶＢＣ２３０５（図２３に示す）へ通されると、ＶＢＣ２３０５は、サーチ実行サービス２３１５と称される登録されたビジネスサービスを呼び出し、そしてサーチカテゴリー（１つ又は複数）及びサーチテキスト又はキーワードに沿ってパラメータとして通す（図２２のブロック２２２０）。ビジネスサービス２３１５、２３２０、２３２５、２３３０（図２３に示す）は、一般に、１組のファンクションの使用をカプセル化しそして簡単化するオブジェクトである。ビジネスコンポーネントオブジェクトは、通常、特定データ及びテーブルに結合される。他方、ビジネスサービス２３１５、２３２０、２３２５、２３３０は、特定データ及びテーブルに結合されない。むしろ、ビジネスサービス２３１５、２３２０、２３２５、２３３０は、オブジェクトに対して動作又は作用し、特定の目標を達成する。ビジネスサービス２３１５、２３２０、２３２５、２３３０は、一般に、データを移動しそしてアプリケーション間でデータフォーマットを変換するタスクを簡単化するのに使用される。
【００６９】
ビジネスサービス２３１５、２３２０、２３２５、２３３０は、入力及び出力に対する特性セットを使用する。この特性セットは、一般に、ネーム−値対を含むことのできるハイアラーキーデータ構造である。ネーム−値対は、例えば、（ＦｏｎｔＣｏｌｏｒ＝Ｇｒｅｅｎ）であり、ここで、ＦｏｎｔＣｏｌｏｒは、特性であり、そしてネーム−値対は、ＦｏｎｔＣｏｌｏｒ特性の値をＧｒｅｅｎの値にセットする。又、特性セットは、１つ以上の子の特性セットを含んでもよい。子の特性セットの各々は、次いで、１つ以上の孫の特性セットを含むことができる。
【００７０】
ユーザがサーチを実行してサーチ結果を発生すると、これらのサーチ結果は、ユーザセッションに対して持続的となる。換言すれば、サーチ結果のコンテンツは、キャッシュ処理され、ユーザセッションが終了するまでセーブされる（図２２のブロック２２２５）。従って、ユーザは、発生されたサーチ結果をユーザセッション内で検索しそして使用することができる。
【００７１】
サーチ結果の持続性は、ユーザがサーチ結果に対して幾つかのアクションを実行できるようにする。例えば、ユーザは、サーチを更に改善することができる。例えば、ユーザがキーワード「モデム」に対してサーチを遂行し、そして「モデム」に関するサーチ結果を受け取ると仮定する。ユーザは、次いで、実際に「５８Ｋモデム」を探していたことが分かる。ユーザは、「５８Ｋモデム」のサーチ結果に対して改善されたサーチを実行することができる。サーチを改善する付加的な詳細について以下に述べる。
【００７２】
サーチ結果の持続性の有用性の別の例として、ユーザは、サーチ結果をプレビューすることができる。ユーザは、サーチにより発生されたサーチ結果を受け取ると、「プレビュー」ボタンを選択して、ポップアップビューに記録された選択されたサーチ結果を見ることができる。ポップアップビューに記録されたサーチ結果をプレビューすることにより、ユーザは、クライアントにより発生される現在ウインドウを使用する必要がない。ユーザは、本質的に、クライアントにより発生されたウインドウと、サーチ結果記録のプレビューを表示するポップアップビューとを含む２つの別々のビューを有し、そしてそれを見ることができる。サーチ結果のプレビューに関する付加的な詳細は、以下に述べる。
【００７３】
サーチ結果持続性の有用性の付加的な例として、ユーザは、サーチ結果を別のオブジェクトにアタッチすることができる。サーチ結果をアタッチすることが有用な典型的な筋書きは、ユーザが現在サービス要求を分析しようと試みることである。この筋書きでは、ユーザは、既存の「ソルーション」に対してサーチを実行することにより開始する。サーチから得られる以前のソルーションが使用可能となった後に、ユーザは、それらのソルーションを経て進行して、現在サービス要求に対する適当なソルーションを見出すことができる。適当なソルーションが見つかると、ユーザは、「アタッチ」ボタンを選択して、適当なソルーションを現在サービス要求にアタッチすることができる。サーチ結果をアタッチすることについての付加的な詳細は、以下に述べる。
【００７４】
一実施形態では、キャッシュ処理されたビジネスサービスを使用して、持続性サーチ結果をサポートする。サーチを実行するのに使用されたキャッシュ処理されたビジネスサービスは、サーチ実行ビジネスサービスと称される。サーチセンターがオープンするか又はサーチがサーチツールバーからスタートされると、一般的にキャッシュ処理されたビジネスサービスのインスタンス（特に、サーチ実行ビジネス）が呼び出される。呼び出されたビジネスサービスインスタンスは、一般に、ユーザセッションが終了するまで、存在したままとされる。換言すれば、呼び出されたビジネスサービスインスタンスは、ユーザセッションが終了するまで、実行されたサーチに関する情報（例えば、サーチカテゴリー及びサーチテキスト又はキーワード）を保持する。例えば、ユーザセッションは、ユーザが終了を合図するか又は時間切れしたときに終了となる。
【００７５】
一実施形態において、ユーザセッションの開始又は終了を決定するコンポーネントは、アプリケーションオブジェクトマネージャー１２０（図１に示す）である。システム管理の観点から、セッションは、クライアントがアプリケーションオブジェクトマネージャー１２０に接続するときに開始され、そしてその接続が終了するときに終了となる。マルチタスクがサポートされる実施形態では、ユーザセッションをサポートするためにアプリケーションオブジェクトマネージャーにおいてタスクがスタートされる。マルチスレッディングがサポートされる実施形態では、ユーザセッションをサポートするためにアプリケーションオブジェクトマネージャーにおいてスレッドがスタートされる。
【００７６】
上述したように、サーチを実行するために使用されるビジネスサービスは、サーチ実行サービス２３１５と称される（図２３に示す）。一実施形態では、サーチ実行サービス２３１５は、次の外部インターフェイスをサポートする。即ち、：：ＳｅｔＳｅａｒｃｈＰａｒａｍｅｔｅｒｓ、：：ＥｘｅｃｕｔｅＳｅａｒｃｈ、：：ＩｓＳｅａｒｃｈＥｘｃｕｔｅｄ、：：ＧｅｔＮｕｍｂｅｒＯｆＲｅｓｕｌｔｓ、：：ＧｅｔＲｅｓｕｌｔＦｉｅｌｄｓ、及び：：ＧｅｔＲｅｓｕｌｔＦｉｅｌｄＶａｌｕｅｓ。一実施形態において、：：ＳｅｔＳｅａｒｃｈＰａｒａｍｅｔｅｒｓは、一般に、サーチカテゴリー及びサーチテキスト又はキーワードのようなサーチパラメータを受け取り、そしてその受け取ったサーチパラメータをサーチ実行サービス２３１５の内部のデータ構造体にセーブする。サーチ実行サービス２３１５によりサポートされる外部インターフェイスは、サーチ実行サービス２３１５の外部のオブジェクト、例えば、サーチ実行仮想ビジネスコンポーネント２３０５により呼び出されることに注意されたい。
【００７７】
：：ＥｘｃｕｔｅＳｅａｒｃｈは、一般に、選択されたサーチアダプタを使用してサーチを実行する。例えば、ファルクラムサーチエンジン２３４０が選択された場合には、：：ＥｘｃｕｔｅＳｅａｒｃｈは、ファルクラムに対してサーチアダプタをスタートし、そしてファルクラムサーチアダプタを使用してサーチを実行する。：：ＩｓＳｅａｒｃｈＥｘｅｃｕｔｅｄは、一般に、サーチが実行又は遂行されたかどうかチェックする。：：ＧｅｔＮｕｍｂｅｒＯｆＲｅｓｕｌｔｓは、一般に、サーチを実行又は遂行することにより得られる結果の数を返送する。：：ＧｅｔＲｅｓｕｌｔＦｉｅｌｄｓは、一般に、特定のサーチ結果行に表示される必要のある結果フィールドを返送する。一実施形態では、結果フィールドは、ランタイム中に動的に発生される。：：ＧｅｔＲｅｓｕｌｔＦｉｅｌｄＶａｌｕｅｓは、一般に、結果フィールドの値を検索するのに使用される。
【００７８】
一実施形態において、サーチ実行サービス２３１５は、：：ＣｒｅａｔｅＳｅａｒｃｈＡｄａｐｔｅｒ及び：：ＩｎｉｔｉａｌｉｚｅＳｅａｒｃｈＡｄａｐｔｅｒを含む幾つかの内部インターフェイスもサポートする。サーチ実行サービス２３１５によりサポートされる外部インターフェイスは、サーチ実行サービスの内部のコンポーネントでしか呼び出せないことに注意されたい。：：ＣｒｅａｔｅＳｅａｒｃｈＡｄａｐｔｅｒは、一般に、コンフィギュレーション情報を検討することによりサーチエンジンを選択し、そしてサーチエンジンに対して適当なサーチアダプタを動的に呼び出す。：：ＩｎｉｔｉａｌｉｚｅＳｅａｒｃｈＡｄａｐｔｅｒは、一般に、呼び出されたサーチアダプタを初期化するのに使用される。
【００７９】
一実施形態において、サーチアダプタクラスを一般的基本クラスＣＳＳＳｅａｒｃｈＡｄａｐｔｅｒ２３３５から導出することができる。ＣＳＳＳｅａｒｃｈＡｄａｐｔｅｒ２３３５は、サーチエンジン２３４０、２３４５、２３５０に共通のインターフェイスをサポートする。この実施形態では、ＣＳＳＳｅａｒｃｈＡｄａｐｔｅｒ２３３５によりサポートされるインターフェイスは、次のカテゴリーにおいてグループ分けすることができる。即ち、サーチエンジンを初期化するインターフェイス、サーチを実行又は遂行するインターフェイス、サーチが成功した場合にサーチ結果を記憶するためのバッファを割り当てるインターフェイス、その割り当てられたバッファにサーチ結果を充填するインターフェイス、及びエラーを取り扱うインターフェイス。サーチを実行又は遂行するインターフェイスは、サーチキーワードをパーズする方法と、フィルタサーチ仕様をパーズする方法と、可視性問合せを構成する方法とを含むことができる。可視性についての付加的な詳細は、以下で述べる。
【００８０】
サーチエンジンを初期化するインターフェイスは、結果バッファを初期化する方法と、サーチカテゴリーバッファを初期化する方法と、フィルタフィールドバッファを初期化する方法とを含むことができる。結果バッファは、一般に、サーチエンジンがサーチに対して発生する結果を保持する。一実施形態では、結果バッファは、サーチ結果行のアレーを含む。各サーチ結果行は、結果行に記憶される。従って、結果行は、１つのサーチ結果行に対する値を含む。これらの値は、ネーム−値対のハッシュテーブルに記憶される。例えば、結果行は、次のフィールドを含むことができる。即ち、ＲｏｗＩｄ、概要、関連性及びファイルサイズ。上記フィールドに対する値は、例えば、各々「１０−２３４４Ａ」、「サービス要求をいかに生成するか」、「９０％」及び「１５０ＫＢ」である。
【００８１】
結果フィールド情報は、一般に、現在選択されたサーチエンジンに対して結果フィールドの定義をキャッシュ処理するのに使用されるデータ構造である。一実施形態において、結果フィールドのこれら定義は、ユーザセッションごとに一度キャッシュ処理される。各結果フィールドは、一般に、現在選択されたサーチエンジン（例えば、ファルクラム）に関するテーブルにおける実際の物理的列の抽象である。
【００８２】
各結果フィールド情報データ構造は、一般に、現在選択されたサーチエンジンにより実行されるべき問合せを構成する間に又はサーチに対して得られる結果を表示する間に使用することのできる情報を記憶するフィールドを含む。従って、各結果フィールド情報データ構造は、ユーザインターフェイス（ＵＩ）ファンクション又は非ＵＩファンクションに関するフィールドを含むことができる。
【００８３】
一実施形態では、問合せを構成する間に使用できる結果フィールド情報データ構造におけるフィールド（即ち、非ＵＩファンクション）は、ネーム、列ネーム、データタイプ、インデックスモード、及びテキスト長さを含むことができる。ネームは、一般に、結果フィールドの名前を表わす。列ネームは、一般に、現在選択されたサーチエンジン（例えば、ファルクラム）に関するテーブルにおける物理的な列の名前を保持する。データタイプは、一般に、結果フィールドのデータタイプを特定する。データタイプの値は、例えば、「ｖａｒｃｈａｒ」、「ｃｈａｒａｃｔｅｒ」及び「ａｐｖａｒｃｈａｒ」を含むことができる。インデックスモードは、列のインデックスモードを特定する。インデックスモードの値は、例えば、「ｎｏｒｍａｌ」、「ｌｉｔｅｒａｌ」又は「ｎｏｎｅ」を含むことができる。
【００８４】
一実施形態において、結果を表示する間に使用できる結果フィールド情報データ構造におけるフィールド（即ち、ＵＩファンクション）は、表示ネーム、テキスト整列及び可視性を含むことができる。表示ネームは、一般に、ユーザインターフェイス（ＵＩ）に表示されるべきラベルを含む。テキスト整列は、一般に、結果の値を表示するときに使用されるべき整列を表わす。テキスト整列の値は、例えば、「ｌｅｆｔ」、「ｃｅｎｔｅｒ」及び「ｒｉｇｈｔ」を含むことができる。可視性は、一般に、結果フィールドを表示すべき場合に「真」にセットされそして結果フィールドを表示すべきでない場合に「偽」にセットされるべきブールのフラグである。
【００８５】
サーチカテゴリーバッファは、一般に、サーチカテゴリー情報データ構造を保持するのに使用される。各サーチカテゴリー情報データ構造は、一般に、現在アプリケーションに対してサーチを実行することのできるサーチカテゴリーに関する全ての情報をキャッシュするのに使用される。
各サーチカテゴリー情報データ構造は、一般に、現在選択されたサーチエンジンにより実行されるべき問合せを構成する間に又はサーチに対して得られる結果を表示する間に使用できる情報を記憶するフィールドを含むことができる。従って、各結果フィールド情報データ構造は、ユーザインターフェイス（ＵＩ）ファンクション又は非ＵＩファンクションに関するフィールドを含むことができる。
【００８６】
一実施形態において、問合せを構成する間に使用できるサーチカテゴリー情報データ構造におけるフィールド（即ち、非ＵＩファンクション）は、ネーム、インデックスネーム、テーブルネーム、フィルタフィールドオブジェクトアレーを含むことができる。ネームは、一般に、サーチカテゴリーの名前を表わす。インデックスネームは、一般に、その下のサーチインデックスの名前である。多数のサーチカテゴリーを同じサーチインデックスに関連付けできることに注意されたい。その結果、種々のアプリケーションのユーザは、サーチカテゴリーを、それらのアプリケーションに基づいてユーザのニーズに適合するようにカスタマイズすることができる。テーブルネームは、一般に、サーチインデックスに対応するその下のテーブルの名前を表わす。フィルタフィールドオブジェクトアレーは、一般に、１つ以上のフィルタフィールドオブジェクトを保持する。各フィルタフィールドオブジェクトは、サーチを制約又は限定するのに一般に使用されるフィルタフィールドを表わす。
【００８７】
一実施形態において、結果を表示する間に使用できるサーチカテゴリー情報データ構造におけるフィールド（即ち、ＵＩファンクション）は、表示ネーム、ドリルダウンビュー、及びドリルダウンビジネスコンポーネントを含むことができる。表示ネームは、一般に、ＵＩに表示されるべきラベルである。ドリルダウンビューは、一般に、サーチから得られる結果が表示されるときにユーザがナビゲートされるところのビューを表わす。ドリルダウンビューにおいて特定されたビューが表示されるときには、そのビューは、通常、種々のビジネスコンポーネントを含む。ドリルダウンビジネスコンポーネントは、一般に、サーチから得られる結果が、ドリルダウンビューにおいて特定されたビュー内に表示されるときにユーザをナビゲートしなければならないところのビジネスコンポーネントを表わす。
【００８８】
フィルタフィールド情報は、一般に、特定のサーチインデックスに対して定義されたフィルタフィールドの定義をキャッシュ処理するのに使用されるデータ構造である。各フィルタフィールド情報データ構造は、次のフィールドを含むことができる。即ち、ネーム、列ネーム、データタイプ、インデックスモード、及びテキスト長さ。ネームは、一般に、結果フィールドの名前を表わす。列ネームは、一般に、現在選択されたサーチエンジン（例えば、ファルクラム）に関するテーブルにおける物理的列の名前を保持する。データタイプは、一般に、結果フィールドのデータタイプを特定する。データタイプの値は、例えば、「ｖａｒｃｈａｒ」、「ｃｈａｒａｃｔｅｒ」及び「ａｐｖａｒｃｈａｒ」を含むことができる。インデックスモードは、列のインデックスモードを特定する。インデックスモードに対する値は、例えば、「ｎｏｒｍａｌ」、「ｌｉｔｅｒａｌ」又は「ｎｏｎｅ」を含むことができる。
【００８９】
適当なサーチアダプタが呼び出されるか又はスタートされると、選択されたサーチエンジン（例えば、ファルクラム）に対するデフォールトの基本的及び進歩型サーチ設定がセットされる。これらサーチ設定は、管理者により定義されることに注意されたい。更に、サーチのためにデータバッファが初期化され、プライム状態にされる。
【００９０】
次いで、サーチカテゴリー及びサーチテキストが入力パラメータから抽出される。サーチテキストは、ＡＮＤ、ＯＲ、ＮＥＡＲ等の特殊なキーワードに対してパーズされる。次いで、可視性ルール問合せ、フィルタフィールド仕様問合せ、及び実際のキーワード問合せを組み合せることにより、サーチＳＱＬステートメントが構成される。これらの構成されたＳＱＬステートメントが実行されて、サーチが行われる。サーチが遂行又は実行された後に、サーチから得られる結果が、選択されたサーチエンジン（例えば、ファルクラム）から検索され、そしてサーチアダプタにおいてキャッシュ処理される。
【００９１】
実行又は遂行されたサーチから得られる結果が、選択されたサーチエンジンから検索されて、サーチアダプタにおいてキャッシュ処理された後に、クライアントにより発生されたサーチセンターフレーム５００（図５に示す）へ通知が送信される。サーチセンターフレーム５００は、この通知を受け取ると、サーチ実行仮想ビジネスコンポーネント２３０５（図２３に示す）にコールして、サーチを呼び出し、サーチから得られる結果を得る。
【００９２】
サーチ実行仮想ビジネスコンポーネント２３０５は、サーチ実行ビジネスサービス２３１５（図２３に示す）をコールして、サーチ結果を検索する。サーチ実行サービス２３１５がサーチ結果を以前にキャッシュ処理している場合には、そのサービス２３１５は、サーチ結果行をサーチ実行仮想ビジネスコンポーネント２３０５へ送信する。しかしながら、サーチ実行サービス２３１５がサーチ結果をキャッシュ処理していない場合には、そのサービス２３１５は、アダプタ２３３５がアダプタのキャッシュからサービス２３１５へサーチ結果を送信するように要求する。サーチ実行サービス２３１５は、次いで、サーチ結果をキャッシュ処理し、そしてサーチ結果をサーチ実行仮想ビジネスコンポーネント２３０５へ送信する。サーチ結果がサーチ実行サービス２３１５において内部にキャッシュ処理されると、サーチエンジンへの接続を閉じることができる。
【００９３】
サーチ実行サーバー２３１５からサーチ結果を受け取ると、サーチ実行仮想ビジネスコンポーネント２３０５は、サーチ結果をサーチセンターフレーム５００（図５に示す）へ送信する。次いで、サーチ結果をサーチセンターフレーム５００内に表示することができる。ユーザは、以下に詳細に述べるように、これらサーチ結果をドリルダウン、プレビュー又はアタッチすることができる。
【００９４】
ユーザがサーチセンターをクローズした場合でも、サーチから得られる結果は依然キャッシュ処理され、そして次にユーザがサーチセンターをオープンしたときに使用できることに注意されたい。というのは、サーチ実行サービス２３１５がサーチ結果をキャッシュ処理するからである。最後にキャッシュ処理されたサーチ結果は、ユーザがユーザセッションを終了するまで保持される。
【００９５】
サーチセンターユーザインターフェイス
図４及び５に戻ると、図４は、本発明の一実施形態による例示的サーチツールバーアイコン４０５を示す。サーチセンターをオープンするために、ユーザは、サーチツールバーアイコン４０５をクリックする。図５は、本発明の一実施形態による例示的サーチセンターフレーム又はペイン５００を示す。サーチセンターフレーム又はペイン５００は、ツールバー選択５０５、コンテンツエリアフレーム５１０、サーチフレーム５１５、及び結果フレーム５２０を備えている。
【００９６】
図２４は、本発明の一実施形態による例示的サーチフレーム５１５を示す。このサーチフレーム５１５は、サーチセンターを退出するためにユーザが選択できるクローズボタン２４０５を備えている。更に、サーチフレーム５１５は、サーチカテゴリー及び探索カテゴリーのドロップダウンリストが現われるところの「捜索」ボックス２４１０も含む。サーチカテゴリー及び探索カテゴリーのドロップダウンリストに関する更なる詳細は、図２５に示され、これを参照して以下に説明する。
【００９７】
サーチフレーム５１５は、更に、更新領域２４１５を含む。ユーザが「捜索」ボックスから何を選択したかに基づき、ボックス２４１５Ａ、２４１５Ｂ、２４１５Ｃ及び２４１５Ｄに１組のコントロールが表示される。
一実施形態では、サーチフレーム５１５は、次のアクションボタンも含む。即ち、サーチ２４２０Ａ、セーブ２４２０Ｂ、及びリセット２４２０Ｃ。サーチボタン２４２０Ａは、サーチを進めるために使用することができる。セーブボタン２４２０Ｂは、一般に、現在サーチをドロップダウンリストにセーブするのに使用される。リセットボタン２４２０Ｃは、通常、ボックス２４１５Ａ、２４１５Ｂ、２４１５Ｃ及び２４１５Ｄのコンテンツをクリアするのに使用される。
【００９８】
図２５は、本発明の一実施形態による例示的サーチ選択ビュー２５００を示す。このサーチ選択ビュー２５００は、サーチ選択アプレット２５０５を含む。このサーチ選択アプレット２５０５は、サーチカテゴリーのドロップダウンリスト２５１０をサポートし、そしてカテゴリーを探索する。ユーザがドロップダウンリスト２５１０からサーチオプションを選択すると、その選択されたサーチオプションがセーブされる。選択されたサーチオプションは、ＳｅｔＳｅａｒｃｈＯｐｔｉｏｎ方法を呼び出すことによりサーチ実行サービスにおいてセーブすることができる。サーチ実行サービスにおいてサーチオプションをセーブすることは、既存のサーチカテゴリーをクリアして、テキスト又はキーワードをサーチすることになる。更に、選択されたサーチオプションに対応するサーチカテゴリーがサーチ選択サービスにおいてセーブされる。加えて、選択されたサーチオプションに対応する新たなビューが構築される。例えば、サーチオブジェクトのセクションで上述したサーチオブジェクトを指すサーチオプションをユーザが選択した場合には、基本的なサーチビューが構築される。例示的な基本的サーチビューが図２６に示され、この図を参照して以下に説明する。別の例として、ユーザが「進歩型サーチ」を選択した場合には、進歩型サーチビューが構築される。例示的な進歩型サーチビューが図２７に示され、この図を参照して以下に説明する。
【００９９】
図２６は、本発明の一実施形態による例示的な基本的サーチビュー及び基本的サーチ結果ビューを示す。基本的サーチビューは、サーチ選択アプレット２６０５及び基本的サーチアプレット２６１０を含む。サーチ選択アプレット２６０５により、ユーザは、サーチ実行サービス及びサーチ選択サービスから現在サーチカテゴリーをクリアすることができる。更に、ユーザは、新たなサーチカテゴリーを選択し、そしてその新たに選択されたサーチカテゴリーに対応する適当なビューへナビゲートすることができる。加えて、ユーザは、クローズボタン２４０５をクリックして、全てのアプレットを閉じ、そしてマスタービューを再構築することができる。
【０１００】
基本的サーチアプレット２６１０により、ユーザは、サーチテキスト又はキーワードを入力し、そしてサーチボタン２６１５を選択することができる。ユーザがサーチボタン２６１５を選択すると、入力されたサーチテキスト又はキーワードがサーチ選択サービスにおいてセーブされる。次いで、サーチ実行ビジネスサービスが、現在選択されたサーチエンジンに対応するサーチアダプタをスタートするか又はそれを呼び出す。サーチアダプタは、次いで、サーチを実行し、そしてその実行されたサーチから得られるサーチ結果を検索する。次いで、基本的サーチ結果ビューが構築される。
【０１０１】
基本的サーチ結果ビューは、上述したサーチ選択アプレット２６０５及び基本的サーチアプレット２６１０を含む。基本的サーチ結果ビューは、サーチ結果リストアプレット２６２０も含む。このサーチ結果リストアプレット２６２０は、サーチ実行サービスからサーチ結果を検索する。サーチ結果リストアプレット２６２０は、次いで、ビジネスコンポーネントに動的フィールドを生成し、これら動的フィールドをサーチ結果からの値でセットする。
【０１０２】
図２７は、本発明の一実施形態による例示的な進歩型サーチビュー及び進歩型サーチ結果ビューを示す。進歩型サーチビューは、サーチ選択アプレット２６０５と、進歩型サーチエントリーアプレット２７１０とを含む。サーチ選択アプレット２６０５の説明は、上記で行った。進歩型サーチビューにより、ユーザは、１つ以上のサーチインデックスソース２７１５を選択し、そしてサーチテキスト又はキーワードをキーワードボックス２７２０に入力することにより、サーチのためのパラメータを特定することができる。ユーザが１つ以上のサーチインデックスソース２７１５を選択し、サーチテキスト又はキーワードを入力し、そしてサーチボタン２７２５を選択すると、サーチが実行される。選択されたサーチカテゴリー２７１５に対して得られるサーチ結果が検索される。検索されたサーチ結果は、分類仕様基準に基づいて分類される。
【０１０３】
次いで、サーチ結果をリストするために、進歩型サーチ結果ビューが構築される。この進歩型サーチ結果ビューは、上述したサーチ選択アプレット２６０５及び進歩型サーチエントリーアプレット２７１０を含む。又、進歩型サーチ結果ビューは、進歩型サーチ結果アプレット２７３０も含む。この進歩型サーチ結果アプレット２７３０は、サーチ実行サービスからサーチ結果を検索し、現在サーチ定義に基づいてビジネスコンポーネントに対する動的フィールドを生成し、そしてこれら動的フィールドをユーザインターフェイスに表示する。
【０１０４】
進歩型サーチビュー及び基本的サーチビューの各々は、ビューオプションサーチタブ２６２５を含む。このビューオプションサーチタブ２６２５は、ユーザがサーチ設定又はサーチ設定のある特性をオーバーライドできるようにする。ビューオプションサーチタブ２６２５は、次のコントロールを含む。即ち、サーチ設定、サーチ項セパレータ、及びサーチ改善。一実施形態において、サーチ設定はドロップダウンリストである。進歩した状態を伴うユーザは、サーチ設定コントロールを使用して、サーチ設定ビューに生成されたデフォールトサーチ設定をオーバーライドすることができる。
【０１０５】
サーチ実行設定は、通常、管理者により生成されることに注意されたい。サーチ実行設定の１つは、各言語に対してデフォールトとしてマークされる。ビューオプションサーチタブ２６２５は、管理者又はユーザがデフォールトサーチ実行設定又はその設定のある特性をオーバーライドするのを許す。
【０１０６】
図２８は、本発明の一実施形態による例示的サーチ項セパレータコントロール２８００を示す。一実施形態において、このサーチ項セパレータコントロール２８００は、次のオプションをもつピックリスト２８０５を含む。即ち、「全ワード（ＡＮＤ一致）」２８１０、「任意ワード（ＯＲ一致）」２８１５、及び「厳密なフレーズ」２８２０。「全ワード（ＡＮＤ一致）」オプション２８１０は、ユーザにより入力された各サーチキーワードを含む記録又はドキュメントを探索するサーチを特定する。「任意ワード（ＯＲ一致）」オプション２８１５は、ユーザにより入力されたサーチキーワードの１つを含む記録又はドキュメントを探索するサーチを特定する。「厳密なフレーズ」オプション２８２０は、ユーザが入力した順序で全てのサーチキーワードを含む記録又はドキュメントを探索するサーチを特定する。
【０１０７】
図２９は、本発明の一実施形態による例示的サーチ改善コントロール２９００を示す。このサーチ改善コントロール２９００は、一般に、ユーザインターフェイスにおいて制御することのできる進歩型特徴をリストする。一実施形態において、ユーザは、接近サーチボタン２９０５を選択し、そしてサーチ改善コントロール２９００のキャラクタボックス２９１０に数字を入力することにより、接近サーチを特定することができる。
【０１０８】
ＩＩＩ．サーチ可視性：
サーチ結果における単一／多−ＯＲＧ可視性
一実施形態において、取引企業や顧客組織であって、それら企業の内外の多数のユーザグループに及ぶものは、それらグループ内及びグループ間のアプリケーションデータへのアクセス及び／又は可視性を制御する必要がある。一実施形態において、ここに述べるサーチシステムは、多組織（多−ｏｒｇ）可視性と称されるメカニズム又は方法を使用して、種々のグループ内及びグループ間のアプリケーションへのアクセスを管理及び制御する能力を取引企業又は顧客組織に与える。一実施形態において、データに対する可視性は、単一組織又はグループ内で個々のレベルに制御し又は制限することができる。例えば、アカウント、コンタクト及び機会等の種々の形式のデータ（例えば、記録）の可視性は、単一組織又はグループ内で個々のレベルに制御し又は制限することができる。一実施形態において、これら種類の記録へのアクセスは、各記録に対する仮想チームに位置付けられている個人に制限することができる。一実施形態において、製品及び価格リストのような付加的データ又は情報へのアクセスも制限することができる。一実施形態において、可視性についてのこれら制限は、個々のユーザのレベルではなく取引組織又はグループのレベルで実施され、制御される。
【０１０９】
一実施形態において、多−ｏｒｇ可視性は、企業レベル、制限されたレベル及び個人レベルにおいて可視性制御に関する論理層を与える。一実施形態において、ここに述べる多−ｏｒｇ可視性方法は、ユーザの位置が指定された組織（１つ又は複数）に基づいてデータへの可視性を制限する能力を与える。一実施形態において、多−ｏｒｇ可視性は、トランザクションデータ（例えば、アカウント、コンタクト及び機会等）、基準データ（例えば、価格リスト等）、及びランタイムコンフィギュレーションデータ（例えば、指定マネージャールール及びプロダクツコンフィギュレータモデル等）を含む種々のアプリケーション内のユーザデータに適用することができる。
【０１１０】
ここに述べるように、多−ｏｒｇ可視性方法／メカニズムは、次のファンクション又はタスクをサポートするのに使用できる。
− 広範な企業にわたるデータシェアリング、例えば、多チャンネルパートナー又は転売者の間での販売機会の分配；
− 異なるそして多様な内部組織への適当なビジネス論理の適用；
− 各ユーザ特有のビジネスコンテクストへの可視性の制限、例えば、ハードウェアの価格を含む全製品価格ではなくソフトウェア製品価格へのソフトウェア販売員の可視性の制限；
− 所与の問い合わせにおいてデータベースから検索する記録の数を制限するより多くの方法を与えることにより広範な責任と多数の直接的なレポートで移動ユーザ及び管理職に対するアプリケーション性能を改善する。
【０１１１】
一実施形態において、多−ｏｒｇ可視性は、データアクセスを異なるユーザへ制約する方法の１つである。「組織的可視性」がオンにされた場合に、ユーザは、その予め指定された位置により、ユーザの組織に関する記録又はデータしか見ることができない。一実施形態において、アプリケーションのビューによりデータベーステーブルに記憶されたデータに直接アクセスするときには、組織的可視性ルールをデータベース問合せの一部分として（例えば、ＳＱＬ問合せの一部分として）適用することができる。例えば、「機会」と称されるビジネスコンポーネントが多−ｏｒｇ可視性制御に対してイネーブルされた（多−ｏｒｇイネーブル）場合には、「全機会ビュー」と称されるビューを選択したユーザは、自分の組織に属する全ての機会を見る。「全機会ビュー」というビューは、データベースの「機会」テーブルと称される対応するデータベーステーブルにおいてルックアップされるので、そのビューのデータをポピュレートするのに使用されるＳＱＬ問合せは、多−ｏｒｇ問合せを含む。これらの可視性ルールは、異なる組織又はグループに属するユーザが、見ることを許された記録又はデータ（例えば、可視性を有するところの記録又はデータ）しか見ないよう確保するのに使用される。
【０１１２】
一実施形態において、ここに述べるように、全テキストサーチをサポートするために、システムの種々のデータベーステーブルは、第三者のサーチエンジン、例えば、「ファルクラム(Fulcrum)」サーチエンジンを使用してインデックスされる。一実施形態において、データベースの記録は、ユーザにより特定の記録を見ることができるかどうかに拘らず、サーチインデックスで示される。この形式のインデックスは、サーチに対する問題を引き起こす。というのは、可視性ルールがサーチインデックスに適用されない場合に、ユーザは、アクセス権をもたない記録を見ることができるからである。一実施形態では、この問題を克服するために、サーチ中に可視性ルールを施行することが必要である。
【０１１３】
以下の説明では、一実施形態において、可視性ルールをサーチのためにいかに実施及び施行できるかについて述べる。当業者であれば、ここに述べる特定の例は、単なる説明のために過ぎず、本発明の範囲を何ら限定するものではないことが明らかであり且つ理解されよう。以下の例では、サーチ可視性をいかに実施するか示すために「文献(Literature)」と称するビジネスコンポーネントを示すようする。この例では、「文献」というビジネスコンポーネントは、サーチのためにインデックスする必要があり、そして多−ｏｒｇ可視性のためにイネーブルされると仮定する。図３３は、「文献」というビジネスコンポーネントと、「組織(Organization)」というビジネスコンポーネントとの間の関係図である。この例において、多数の組織が各文献記録を共用することができ、そして単一の組織により多数の文献記録にアクセスすることができる。この例は、典型的な多数−多数関係を示す。
【０１１４】
一実施形態において、サーチ可視性の解決策は、例えば、サーチ管理時間中に、管理者がサーチインデックスを生成するとき、及びサーチ実行時間中に、対応する可視性ルールがサーチ結果に適用されるときに、種々のレベルで実施することができる。
【０１１５】
サーチ構成及び管理時間：
一実施形態において、サーチ構成時間中に、サーチインデックスが次の仕様に基づいて管理者により構成される。
− ビジネスコンポーネント（これは、データベーステーブルに基づく）；
− インデックスされるべき各ビジネスコンポーネントのフィールド；
− このインデックスに適用されるべき可視性のタイプ（この場合は組織の可視性）。
【０１１６】
一実施形態において、サーチインデックス構成は、ここに述べるように１組のサーチ構成及び管理ツールを使用して実行することができる。
サーチインデックスを構成した後に、管理者は、サーチ管理スクリーンを使用して、上述した構成に基づきサーチインデックスを生成することができる。一実施形態において、インデックスされているテーブルが多−ｏｒｇイネーブルされた場合に、各記録に関連した全ての組織も含ませることにより記録を正規化解除することができる。一実施形態では、記録の正規化解除は、図３３に示すように、交差テーブルを使用することにより行うことができる。
【０１１７】
文献ビジネスコンポーネントの例において、文献テーブルに関する所要のフィールド、例えば、ネーム、説明、等をインデックスする間に、各文献記録に関連した全ての組織ＩＤについてもインデックスが行われる。従って、正規化解除は、図３３に示すように、文献−組織交差テーブルを使用することにより行うことができる。
【０１１８】
図３４は、記録をインデックスしそして正規化解除するための方法の一実施形態を示すフローチャートである。
ブロック３４０５では、インデックスされるべきテーブルに基づいて既存のビジネスコンポーネントを選択する。
ブロック３４１０では、選択されたサーチ特有のビジネスコンポーネントにおいて対応サーチインデックスオブジェクトを生成する。
ブロック３４１５では、第三者のサーチインデックステーブルへとインデックスされるべきフィールドを選択する。
【０１１９】
ブロック３４２０では、使用する可視性のタイプ及びそれに関連したオブジェクト（例えば、文献組織リンク）を次のように特定することができる。
− 可視性フィールドが単一値フィールド（例えば、組織Ｉｄ）である場合には、サーチインデックス仮想ビジネスコンポーネントが、サーチテーブルを発生するようファルクラムサーチサーバーに求めるときに、対応する列を可視性列として識別する。
− 可視性フィールドが多値フィールド（例えば、組織、資格）である場合には、対応する列を可視性列として識別し、各値に対して１つの記録を挿入し、そしてフィルタ列に値をポピュレートする。（即ち、多値フィールドを個別のサーチテーブル記録へと正規化解除する。）
【０１２０】
ブロック３４２５では、このサーチインデックスに関連したサーチカテゴリー（例えば、文献サーチカテゴリー）を生成する。これは、サーチセンターＵＩに現われるものである。
ブロック３４３０では、サーチ管理スクリーンを使用して、以前に定義されたサーチインデックスの各々に対してファルクラムサーチテーブルを発生する。
【０１２１】
ブロック３４３５では、可視性タイプが組織にセットされる場合に、テーブルを次のように正規化解除する。
− インデックスされるべき各記録が単一の組織に関連付けされる場合には、ベーステーブルにおいて全ての記録をインデックスする。
− インデックスされるべき各記録が多数の組織に関連付けされる場合には、ベーステーブルを先ず交差テーブルと結合することにより正規化解除し、次いで、その正規化解除されたデータをインデックスする。例えば、各文献記録が多数の組織に関連付けされる場合には、ベーステーブルは、以下の例に示すように文献−組織交差テーブルと称される交差テーブルと「連結(JOIN)」される。

【０１２２】
サーチ実行時間：
一実施形態において、サーチ実行時間中に、サーチは、サーチ仕様（例えば、ユーザにより入力されたキーワード）に基づいて実行されるだけでなく、ユーザに関連した可視性ルールにも基づいて実行される。例えば、ユーザが、サーチのためのキーワードを含むサーチテキストを入力すると、サーチは、ユーザにより入力されたキーワードに基づいて実行されるが、現在のユーザの組織に関する行／記録のみに限定される。一実施形態では、ユーザは、一度に１つの組織にしか属さないので、サーチ結果が複写されることはない。
【０１２３】
図３５は、本発明の教示による方法の一実施形態を示す。
ブロック３５０５において、インデックスが発生されたところのサーチカテゴリーがサーチセンターパネル／ＵＩに表示される。
ブロック３５１０において、ユーザは、サーチカテゴリーを選択し、そしてサーチのためのキーワードを入力する。例えば、ユーザは、「文献」と称するサーチカテゴリーを選択又は選出し、そしてサーチのためのキーワード「セールスブローチャー」を入力する。
ブロック３５１５において、サーチフレームは、入力を受け取り、そしてそれをその下のサーチ仮想ビジネスコンポーネントに通す。
【０１２４】
ブロック３５２０において、「サーチ実行仮想ビジネスコンポーネント」は、「サーチ実行サービス」と称するサービスに着手する。一実施形態において、各セッションに対して実行されるサービスの単一インスタンスがある。このサービスは、ビジネスコンポーネント層とサーチアダプタ層との間に抽象を与えるように使用される。一実施形態では、サービスは、次いで、転回して、適切なサーチアダプタ（例えば、ファルクラムサーチアダプタ）をコールし、これは、次いで、問合せ（例えば、ファルクラム−ＳＱＬ問合せ）を構成する。一実施形態において、この形式の問合せは、データベース問合せとは異なる。一実施形態において、ファルクラムサーチアダプタのようなサーチアダプタにより構成される問合せ構造は、次のように定義することができる。
ＳＥＬＥＣＴ＜ｓｅｌｅｃｔ−ｌｉｓｔ＞ＦＲＯＭ＜ｆｕｌｃｒｕｍ ｔａｂｌｅ＞
但し、（＜ｏｒｇａｎｉｚａｔｉｏｎ−ｃｏｌｕｍｎ＞ｃｏｎｔａｉｎｓ＜ｃｕｒｒｅｎｔ ｕｓｅｒ’ｓ ｏｒｇａｎｉｚａｔｉｏｎ ｉｄ＞）ＡＮＤ
（＜ｉｎｄｅｘｅｄ−ｃｏｌｕｍｎ＞ｃｏｎｔａｉｎｓ＜ｋｅｙｗｏｒｄ＞）
【０１２５】
一実施形態において、キーワード及び可視性ルール（例えば、組織的可視性）に基づくサーチは、次のものを含む。
− ＳＥＬＥＣＴ（選択）の条項を準備する。
− Ｆｕｌｃｒｕｍ（ファルクラム）テーブルリストをサーチのために準備する。一実施形態において、ＵＮＩＯＮ（合体）の条項を使用して多数のテーブルをサーチすることができる。
− 現在ユーザの組織Ｉｄを検索する。一実施形態において、ユーザは、１つの組織にしか属さない。この組織Ｉｄを使用して、その組織ＩｄがユーザのＩｄに合致する行／記録だけにサーチを制限する。
【０１２６】
− 現在ユーザがアクセスできる全ての行／記録の制限されたリストが決定されると、それらの制限されたリストから、ユーザにより入力されたキーワードを含む記録を選択するようにサーチが実行される。
− 問合せが首尾良く実行された後に、サーチ結果がアダプタから検索されて、ＵＩサーチ結果フレームに表示される。
【０１２７】
ブロック３５２５において、２つ以上のサーチカテゴリーが選択された場合には、各カテゴリーに対して上記プロセスを次のように繰り返す。
− ＦＲＯＭの条項においてファルクラムテーブルを合体する。
− 各選択されたカテゴリーに対し：
組織可視性ルール（組織フィルタ）を最初に適用して、ユーザがユーザの組織Ｉｄに基づいてアクセスできる行／記録のみにサーチを限定させる。
− １つのキーワード条項を準備する。
− 各選択されたカテゴリーに対しユーザにより入力されたキーワードに基づいてサーチを実行する。
【０１２８】
サーチ結果におけるカテゴリーアクセス制御可視性
文献及び製品のような非常に大量のマスターデータを有する顧客の場合には、フラットなリストにおいてマスターデータ（又は参照データ）のアイテムをサーチする簡単なタスクが、困難なタスクになる。一実施形態では、マスターデータがグループ分けされそして編成される。カタログ及びカテゴリーの導入は、種々の顧客がそれらのデータをハイアラーキー式にカテゴリー分けしそしてデータを通して容易にナビゲートできるようにする。一実施形態では、カタログがルートカテゴリーであり、そして多数のカテゴリー（カタログとも称される）が存在する。一実施形態では、同じカタログが２つ以上のマスターデータオブジェクトを含むことができる（例えば、文献、ソルーション、等）。一実施形態では、多数のカテゴリーレベルも存在する。一実施形態では、アクセス（例えば、読み取り／更新／挿入／削除）又はアクセスをマスターデータに制限するための能力は、ユーザグループをハイアラーキーにおいて任意のカテゴリーに関連付けすることにより行うことができる。
【０１２９】
ユーザグループ
一実施形態において、システムの種々のユーザは、種々のユーザグループに編成される。これは、人々やアカウントを、マスターデータの種々のカテゴリーに対する可視性をもつか又はもたないように指定できるグループへと編成できるようにする。一実施形態において、マスターデータの種々のカテゴリーへのユーザの関連付けは、カタログ管理スクリーンと称される種々のユーザインターフェイスにおいて確立される。例えば、エンドユーザがカタログを通してブラウズし又はピックリストを呼び出すときには、ユーザは、アクセス可能なカタログ又はこれらアクセス可能なカタログにおけるアイテムしか見ない。
【０１３０】
図３６は、本発明の教示による論理的データモデルの一実施形態を示す図である。高いレベルでは、これは、ユーザを管理し、マスターデータを管理し、そしてマスターデータへのユーザのアクセスを管理することを含むカテゴリーアクセス制御の概念を記述する論理的データモデルである。図３６に示すように、論理的データモデル３６００は、マスターデータブロック３６１０、アクセス制御ブロック３６２０、及び当事者ブロック３６３０を含む。本発明の教示によれば、データをよりアクセスし易く編成するために、ここに述べるようにハイアラーキーメカニズムが導入される。一実施形態において、アクセス制御ブロック３６２０は、当事者ブロック３６３０のアクセスをマスターデータブロック３６１０へ制御／制限するための制御構造体として使用される。
【０１３１】
図３７は、図３６に示された論理的データモデルの一実施形態の詳細なブロック図である。
一実施形態において、データ（データベーステーブルに記憶された）がアプリケーションにおける種々のビューを経て直接アクセスされるときには、カテゴリーアクセス制御可視性ルールがデータベースＳＱＬ問合せの一部分として適用される。例えば、ビジネスコンポーネント「文献」がアクセス制御イネーブルされた場合には、ユーザは、自分がアクセスすることのできるカテゴリーのもとにあるカテゴリー及び文献のみを見る。ユーザがアクセスできるカテゴリーのリストは、ランタイムにおいて、ユーザが属するユーザグループ及びアクセスの形式を決定することにより決定される。
【０１３２】
しかし、全テキストサーチが、システム又は内部データベースではなく第三者のサーチインデックスに対して実行されるので、このコンテクストにおけるアクセス制御は、以下に述べるように若干異なるやり方で実施される。組織可視性ルールについて上述したように、データベースにおける記録は、ユーザが特定の記録を見ることができるかどうかに拘らず、特定のサーチエンジン（例えば、ファルクラムサーチエンジン）のサーチインデックスへとインデックスされる。アクセス制御可視性ルールは、以下に詳細に述べるように、サーチ結果に適用される。
【０１３３】
以下の例は、アクセス制御可視性ルールの一実施形態を示す。この例では、文献ビジネスコンポーネントが、インデックスされる必要のあるビジネスコンポーネントで、アクセス制御イネーブルされると仮定する。これは、対応するデータベーステーブルにおける全ての文献記録が種々のカテゴリーに指定されており、そしてマスターデータのこれらカテゴリーへのアクセスがユーザグループに既に指定されていることを意味する。
【０１３４】
以下に述べるプロセスは、サーチ組織可視性ルールについて上述したプロセスに類似しているが、「組織」が、今度は「コンテンツカテゴリ」である。一実施形態では、サーチ結果が同じサーチに対して繰り返されることが相違する。例えば、同じ文献アイテムが２つの異なるカテゴリーに関連付けされ、そして同じユーザがこれら２つの異なるカテゴリーにアクセスできる場合には、この文献アイテムに対するサーチ結果が２回現われ、その相違は、それらが属するカテゴリーである。
【０１３５】
図３８は、論理的データモデル３８００の一実施形態を示すブロック図で、種々のビジネスコンポーネント（例えば、文献ビジネスコンポーネント、カテゴリービジネスコンポーネント等）間の関係を示す。
以下の説明は、一実施形態において、サーチに対するカテゴリーアクセス制御可視性をいかに実施できるか示す。当業者であれば、ここに述べる特定例は、説明のためのものに過ぎず、本発明の範囲を何ら限定するものではないことが明らかであり、理解されよう。一実施形態において、カテゴリーアクセス制御可視性は、例えば、サーチ管理及び構成時間中にサーチインデックスが生成されたとき、及びサーチ実行時間中に対応するアクセス制御可視性ルールが適用又は施行されるときに、種々のレベルで実施することができる。
【０１３６】
サーチ構成及び管理時間：
一実施形態において、サーチ構成時間中に、サーチインデックスは、管理者により次の仕様に基づいて構成される。
− ビジネスコンポーネント（これは、データベーステーブルに基づく）；
− インデックスされるべき各ビジネスコンポーネントのフィールド；
− このインデックスに適用されるべき可視性のタイプ（この場合は、グループ／アクセス制御の可視性）。
【０１３７】
一実施形態において、サーチインデックス構成は、ここに述べる１組のサーチ構成及び管理ツールを使用して実行することができる。
サーチインデックスを構成した後に、管理者は、サーチ管理スクリーンを使用して、上述した構成に基づきサーチインデックスを生成することができる。一実施形態において、インデックスされているテーブルがアクセス制御イネーブルされた場合に、各記録に関連した全てのカテゴリーを含ませることにより記録を正規化解除することができる。一実施形態では、記録の正規化解除は、交差テーブル（例えば、図３８に示すような文献−カテゴリー交差テーブル）を使用することにより行うことができる。
【０１３８】
文献ビジネスコンポーネントの例において、文献テーブルに関する所要のフィールド、例えば、ネーム、説明、等をインデックスする間に、各文献記録に関連した全てのカテゴリーＩＤについてもインデックスが行われる。従って、正規化解除は、図３８に示すように、文献−カテゴリー交差テーブルを使用することにより行うことができる。
【０１３９】
図３９は、記録をインデックスしそして正規化解除するための本発明の教示による方法の一実施形態を示すフローチャートである。
ブロック３９０５では、インデックスされるべきテーブルに基づいて既存のビジネスコンポーネントを選択する。
ブロック３９１０では、選択されたサーチ特有のビジネスコンポーネントにおいて対応サーチインデックスオブジェクトを生成する。
ブロック３９１５では、第三者のサーチインデックステーブルへとインデックスされるべきフィールドを選択する。
【０１４０】
ブロック３９２０では、使用する可視性のタイプ及びそれに関連したオブジェクト（例えば、文献カテゴリーリンク）を選択する。
ブロック３９２５では、カテゴリービジネスコンポーネントからのカテゴリーネームフィールドを含む。これは、以下に述べるようにサーチ結果を分類するのに使用できる。
ブロック３９３０では、サーチカテゴリーを生成し、そしてこれにサーチインデックスを関連させる。これは、サーチセンターＵＩに現われるものである。
ブロック３９３５では、サーチ管理スクリーンを使用して、以前に定義されたサーチインデックスの各々に対してファルクラムサーチテーブルを発生する。
【０１４１】
ブロック３９４０では、可視性タイプがアクセス制御にセットされる場合に、テーブルを次のように正規化解除する。
− インデックスされるべき各記録が多数のカテゴリーに関連付けされる場合には、ベーステーブルを先ず交差テーブルと結合することにより正規化解除し、次いで、その正規化解除されたデータをインデックスする。例えば、各文献記録が多数のカテゴリーに関連付けされる場合には、ベーステーブルは、以下に示す文献−カテゴリー交差テーブルのような交差テーブルと「連結(JOIN)」される。

【０１４２】
サーチ実行時間：
一実施形態において、サーチ時間に、サーチは、サーチ仕様又は基準（例えば、ユーザにより入力されたキーワード）に基づいて実行されるだけでなく、その特定ユーザに関連した可視性ルールにも基づいて実行される。例えば、ユーザが、サーチのためのキーワードを含むサーチテキストを入力すると、サーチは、ユーザにより入力されたキーワードに基づいて実行されるが、アクセス制御可視性ルールに基づいてユーザにアクセスできる行／記録のみに限定される。一実施形態では、ユーザは、多数のカテゴリーにアクセスできるので、サーチ結果が複写エントリーをもつことができる（例えば、同じエントリーが２つの異なるカテゴリーに属することがある）。
【０１４３】
図４０は、本発明の教示によるプロセスの一実施形態を示すフローチャートである。
ブロック４００５において、サーチセンターは、上述したようにインデックスが発生されたところのサーチカテゴリーを表示する。
ブロック４０１０において、ユーザは、サーチカテゴリーを選択し、そしてサーチのためのキーワードを入力する。例えば、ユーザは、「文献」と称するサーチカテゴリーを選択又は選出し、そしてキーワード「セールスブローチャー」を入力する。
ブロック４０１５において、サーチフレームは、ユーザから入力を受け取り、そしてそれをその下のサーチ仮想ビジネスコンポーネントに通す。
【０１４４】
ブロック４０２０において、「サーチ実行仮想ビジネスコンポーネント」は、「サーチ実行サービス」と称するサービスに着手する。一実施形態において、各セッションに対して実行されるサービスの単一インスタンスがある。このサービスは、ビジネスコンポーネント層とサーチアダプタ層との間に抽象を与えるように使用される。一実施形態では、サービスは、次いで、転回して、適切なサーチアダプタ（例えば、ファルクラムサーチアダプタ）をコールし、これは、次いで、問合せ（例えば、ファルクラム−ＳＱＬ問合せ）を構成する。一実施形態において、この形式の問合せは、データベース問合せとは異なる。一実施形態において、ファルクラムサーチアダプタのようなサーチアダプタにより構成される問合せ構造は、次のように定義することができる。
ＳＥＬＥＣＴ＜ｓｅｌｅｃｔ−ｌｉｓｔ＞ＦＲＯＭ＜ｆｕｌｃｒｕｍ ｔａｂｌｅ＞
但し、（＜ｃａｔｅｇｏｒｙ−ｃｏｌｕｍｎ＞ｃｏｎｔａｉｎｓ＜ａｌｌ ｖａｌｉｄ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃａｔｅｇｏｒｉｅｓ＞）ＡＮＤ
（＜ｉｎｄｅｘｅｄ−ｃｏｌｕｍｎ＞ｃｏｎｔａｉｎｓ＜ｋｅｙｗｏｒｄ＞）
【０１４５】
一実施形態において、キーワード及びアクセス制御可視性ルールに基づくサーチのプロセスは、次のものを含む。
− ＳＥＬＥＣＴ（選択）の条項を準備する。
− Ｆｕｌｃｒｕｍ（ファルクラム）テーブルリストをサーチのために準備する。一実施形態において、ＵＮＩＯＮ（合体）の条項を使用して多数のテーブルをサーチすることができる。
− ユーザがアクセスできる全てのカテゴリーを検索する。一実施形態において、これは、ユーザが属する全てのユーザグループを決定し、そしてこれらユーザグループに関連したカテゴリーを決定することにより行われる。この問合せは、現在ユーザがアクセスできる全ての有効なアクセス制御カテゴリーを返送する。これらのカテゴリーＩｄを使用すると、ＯＲの条項は、カテゴリーＩｄがこのリストに一致するところの行／記録のみにサーチを制限するように構成される。
【０１４６】
− 現在ユーザがアクセスできる全ての行／記録の制限されたリストが決定されると、ユーザにより入力されたキーワードを含む行／記録に対してサーチが実行される。
− 問合せが首尾良く実行された後に、アダプタからサーチ結果を検索し、そしてそのサーチ結果をＵＩサーチ結果フレームに表示する。
【０１４７】
ブロック４０２５において、２つ以上のサーチカテゴリーが選択された場合には、各カテゴリーに対して上記プロセスを次のように繰り返す。
− ＦＲＯＭの条項においてファルクラムテーブルを合体する。
− 各選択されたカテゴリーに対し：
カテゴリー可視性ルール（カテゴリーフィルタ）を最初に適用して、対応するユーザグループ及びそれらユーザグループに関連したカテゴリーに基づいて、ユーザがアクセスできる行／記録のみにサーチを限定させる。
− １つのキーワード条項を準備する。
− 各選択されたカテゴリーに対しユーザにより入力されたキーワードに基づきファルクラムにおいてサーチを実行する。
【０１４８】
不可視／暗黙フィルタサーチ
一実施形態において、「不可視」又は「暗黙」サーチフィルタは、サーチ結果が不可視／暗黙問合せに基づいて自動的にフィルタされるように構築される。
不可視サーチフィルタ：
一実施形態において、各サーチインデックス（及びより詳細にはサーチテーブル）オブジェクトに対し、ユーザは、フィルタフィールドを定義することができる。これらフィルタフィールドは、特に、サーチ結果をフィルタする目的で使用される。ファルクラムのようなサーチエンジンを使用する場合には、これらのビジネスコンポーネントフィールドは、ファルクラム列（例えば、ファルクラムサーチテーブルにおける）へと直接マップし、そしてここに述べるように、通常のインデックスプロセスの一部分としてインデックスされる。一実施形態では、このインデックス動作は、ビジネスコンポーネントレベルではなく、データベースレベルで直接行われる。
【０１４９】
不可視／暗黙フィルタリングの概念は、以下の例で述べる問題を解決するために導入される。システム構成の一実施形態において、異なる形式のドキュメントが同じテーブルに記憶される。例えば、ソリューション及びレゾリューションドキュメントは、Ｓ＿ＲＥＳＩＴＥＭと称される同じテーブルにセーブされる。現在、異なる形式のドキュメントの記録は、フラグフィールド又はフラグ列（例えば、ＳＯＬＵＴＩＯＮ＿ＩＴＥＭ＿ＦＬＧと称されるフラグ）を使用して区別される。例えば、このフラグ列における「Ｙ」値は、ソルーション記録を指示する。ソルーションのみに関するサーチ結果をフィルタするために、ランタイムに、あるフィルタサーチ仕様を使用することが必要となる。一実施形態では、フィルタサーチ仕様は、ビジネスコンポーネントサーチ仕様に類似しており、そして同様に機能する。フィルタフィールドを生成しそしてそれを使用してサーチ結果をフィルタリングするプロセスを以下に詳細に説明する。
【０１５０】
サーチ構成時間
図４１は、フィルタサーチ仕様を生成するための本発明の教示による方法の一実施形態を示すフローチャートである。
ブロック４１０５では、インデックスされるべきビジネスコンポーネント（例えば、ソリューションビジネスコンポーネント）を識別する。
ブロック４１１０では、上記ビジネスコンポーネント（例えば、ソリューションビジネスコンポーネント）に対するサーチインデックスを構成する。
ブロック４１１５では、サーチインデックス及び特定のサーチエンジンに対するサーチテーブル（例えば、ファルクラムサーチエンジンに対するＦＵＬ＿ＳＯＬＮ）を特定する。
【０１５１】
ブロック４１２０では、フィルタフィールドとして働くビジネスコンポーネントにおいてフィールドを識別する。一実施形態において、サポートされるフィールド形式は、Ｖａｒｃｈａｒｓ又はＣｈａｒフィールドである。
ブロック４１２５では、サーチテーブルオブジェクトのもとでフィルタフィールドを定義する。例えば、データタイプ、インデックスモード等の他の属性と共に、ファルクラムサーチテーブルにおいて列ネームを特定する。
ブロック４１３０では、このサーチインデックスに関連したサーチカテゴリーを生成する。例えば、オール・ソリューションと称されるサーチを生成する。
【０１５２】
ブロック４１３５では、サーチエンジン（例えば、サーチエンジンファルクラム）のもとでサーチ定義を生成する。例えば、「コールセンターサーチ定義」と称されるサーチ定義を生成する。上述したように、サーチ定義は、サーチカテゴリーのグループである。
ブロック４１４０では、サーチ定義がアプリケーションに関連付けされる。アプリケーションに着手すると、サーチ定義に属するカテゴリーがサーチセンターのＵＩに表示される。
ブロック４１４５では、サーチカテゴリー「オール・ソルーション」をこのサーチ定義に関連付ける。
【０１５３】
ブロック４１５０では、このカテゴリーに対するフィルタサーチ仕様を定義し、ある形式の記録（例えば、ソルーション記録）のみをフィルタする。例えば、この場合のフィルタ仕様は、［ソルーションアイテム］＝「Ｙ」と特定される。一実施形態において、サポートされるフィルタされたサーチ仕様シンタックスについて以下に説明する。
ブロック４１５５では、ランタイム又は実行時間に、フィルタサーチ仕様がパーズされ、そしてそれに対応するカテゴリーに関するサーチ結果に適用される。サポートされるフィルタされたサーチ仕様シンタックスについて以下に説明する。
【０１５４】
サーチ実行時間：
一実施形態において、サーチ実行時間に、サーチは、ユーザにより入力されたキーワードに基づいて実行されるだけではなく、フィルタサーチ仕様にも基づいて実行される。例えば、ユーザが、キーワードを含むサーチテキストを入力すると、サーチは、ユーザにより入力されたキーワードに基づいて実行されるが、フィルタサーチ仕様の条項を満足する行／記録のみに制限される。一実施形態では、フィルタサーチ使用は、上述した可視性サーチ仕様と共存し得る（例えば、組織的可視性サーチ仕様又はカテゴリーアクセス制御可視性サーチ仕様）。
【０１５５】
図４２は、本発明の教示による方法の一実施形態を示すフローチャートである。この例に示すように、サーチは、キーワード及びフィルタサーチ仕様に基づいて実行される。
ブロック４２０５では、サーチセンターは、上述したようにインデックスが発生されたところのサーチカテゴリーを表示する。
ブロック４２１０では、ユーザは、サーチカテゴリーを選択し、そしてサーチキーワードを入力する。例えば、ユーザは、「ソリューション」と称されるサーチカテゴリーを選択し、そしてキーワード「セールスブローチャー」を入力する。
【０１５６】
ブロック４２１５では、サーチフレームは、入力を受け取り、そしてそれをその下のサーチ仮想ビジネスコンポーネントに通す。
ブロック４２２０では、「サーチ実行仮想ビジネスコンポーネント」は、「サーチ実行サービス」と称するサービスに着手する。一実施形態において、各セッションに対して実行されるサービスの単一インスタンスがある。このサービスは、ビジネスコンポーネント層とサーチアダプタ層との間に抽象を与えるように使用される。一実施形態では、サービスは、次いで、転回して、適切なサーチアダプタ（例えば、ファルクラムサーチアダプタ）をコールし、これは、次いで、問合せ（例えば、ファルクラム−ＳＱＬ問合せ）を構成する。一実施形態において、この形式の問合せは、データベース問合せとは異なる。一実施形態において、ファルクラムサーチアダプタのようなサーチアダプタにより構成される問合せ構造は、次のように定義することができる。
ＳＥＬＥＣＴ＜ｓｅｌｅｃｔ−ｌｉｓｔ＞ＦＲＯＭ＜ｆｕｌｃｒｕｍ ｔａｂｌｅ＞
但し、（（＜ｖｉｓｉｂｉｌｉｔｙ ｃｏｎｓｔｒａｉｎｔ＞）ＡＮＤ（＜ｆｉｌｔｅｒ ｃｏｌｕｍ＞＝＜ｆｉｌｔｅｒ ｓｅａｒｃｈ ｓｐｅｃ＞））ＡＮＤ
（＜ｉｎｄｅｘｅｄ−ｃｏｌｕｍｎ＞ｃｏｎｔａｉｎｓ＜ｋｅｙｗｏｒｄ＞）
【０１５７】
一実施形態において、キーワード及び不可視／暗黙サーチフィルタに基づくサーチは、次のものを含む。
− ＳＥＬＥＣＴ（選択）の条項を準備する。
− Ｆｕｌｃｒｕｍ（ファルクラム）テーブルリストをサーチのために準備する。一実施形態において、ＵＮＩＯＮ（合体）の条項を使用して多数のテーブルをサーチすることができる。
− 上述した多−ｏｒｇ可視性ルール及び／又はアクセス制御可視性ルールに基づいて可視性の条項を準備する。
【０１５８】
− サーチ仕様をパーズしてファルクラムＳＱＬシンタックスに合致させる。
− フィルタサーチ仕様を可視性制約と共に添付する（多−ｏｒｇ可視性及び／又はアクセス制御可視性にもとづいて）。
− 実際のキーワード制約を準備する。
− 問合せが首尾良く実行された後に、サーチアダプタからサーチ結果を検索し、そしてサーチ結果をＵＩサーチ結果フレームに表示する。
【０１５９】
ブロック４２２５において、２つ以上のサーチカテゴリーが選択された場合には、各カテゴリーに対して上記プロセスを次のように繰り返す。
− ＦＲＯＭの条項においてファルクラムテーブルを合体する。
− 各選択されたカテゴリーに対し：
可視性の条項を適用する。
フィルタフィールドの条項を適用する。
− １つのキーワード条項を準備する。
− 可視性ルール、サーチフィルタ仕様及びキーワードに基づいてサーチアダプタ（例えば、ファルクラム）におけるサーチを実行する。
【０１６０】
サポートされたフィルタサーチ仕様シンタックス
一実施形態において、サポートされるフィルタサーチ仕様シンタックスを以下に示す。
［フィルタ表現］ ｛＜ブール演算子＞ ［フィルタ表現］・・・｝
［フィルタ表現］：：［フィルタフィールドネーム］
［演算子］［値］
［フィルタフィールドネーム］：サーチカテゴリーに属するフィルタフィールドの名前
［演算子］：＝、＜＞、ＬＩＫＥ、ＮＯＴ ＬＩＫＥ
ＬＩＫＥ及びＮＯＴ ＬＩＫＥは、ワイルドカード＊をサポートし、そして
［値］：フィールドの値。例えば、「Ｙ」、
又は関数「LookupValue (<LOV Name>, <Independent LOV code>)」であってもよい。
＜ブール演算子＞：：ＯＲ、ＡＮＤ
例：

【０１６１】
サーチ結果アタッチメント／プレビュー
アタッチメント
一実施形態において、サーチ結果リストアプレット又は探索結果リストアプレットにおける記録は、コンテンツエリアにおけるアクティブな親オブジェクトにアタッチするか又は関連付けることができる。一実施形態において、サーチ結果リストアプレット又は探索結果リストアプレットにおける記録をコンテンツエリアにおけるアクティブな親オブジェクトにアタッチするためには、それらの間の関係がＭ対Ｍ関係であることが必要である。一実施形態において、この関係は、２つのビジネスコンポーネント間のリンクを交差テーブルと共に生成することにより実施される。一実施形態において、サーチカテゴリー又は探索オブジェクトがビジネスオブジェクトのビジネスコンポーネントの１つであり、そしてそれらの間にＭ対Ｍリンクが存在する場合には、サーチ結果記録又は行を各オブジェクトにアタッチすることができる。
【０１６２】
一実施形態では、多層システムアーキテクチャーにおいてビジネスオブジェクト層にアタッチメント（関連性とも称される）が生成される。一実施形態では、関連性又はアタッチメントを照合するためにビューへ直接進行する能力をユーザに与えるため、「ピックビュー」と称される特徴が、それに対応するサーチカテゴリー又は探索オブジェクトに付加される。このピックビューは、関連性が生じた後、及び候補関連性の後に、ユーザが進むことのできるビューを定義する。従って、上述したサーチツールを使用してサーチカテゴリー又は探索オブジェクトに新たなピックビューを追加することができる。
【０１６３】
上述したように、サーチツールにおいて、ピックビューは、サーチカテゴリー及び探索オブジェクトのもとでアクセスすることができる。これらピックビューのビジネスオブジェクトは、上述したように関連性を受け入れることができる。一実施形態において、ピックビューにおいて定義されたアプレットネームは、ユーザがサーチ結果記録を追加するところのアプレットである。
【０１６４】
一実施形態において、ピックビューに対する外部ドキュメントの関連性がサポートされる。一般に、このピックビューは、「ＸＸＸアタッチメント」と称される。この関連性の制約は、データベース記録の関連性とは異なる。一実施形態において、このアプレットは、ＣＳＳＳＷＥＦｒａｍｅＬｉｓｔＦｉｌｅに基づくものでなければならず、そしてそのビジネスコンポーネントは、ＣＳＳＢＣＦｉｌｅに基づくものでなければならない。このアプレットは、記述のような任意のフィールドを含んでもよい。一実施形態において、これらのフィールドは、アタッチメントが生成されるときには埋められない。
【０１６５】
ここに述べるように、各サーチカテゴリーは、サーチインデックスと称される属性を有する。一実施形態において、サーチインデックスの「ＤＢテーブル」と称される属性を使用して、サーチ結果行／記録が外部ドキュメントであるかデータベース記録であるか決定される。例えば、この属性が、偽のような特定の値にセットされる場合には、それに対応するサーチカテゴリーが外部ドキュメントであると仮定される。
【０１６６】
プレビュー
一実施形態において、結果記録のプレビューが、ここに述べるサーチシステムの特徴として含まれる。一実施形態において、結果記録をプレビューするためには、ドリルダウンビューが必要とされる。一実施形態では、ドリルダウンビュー、ドリルダウンビジネスコンポーネント及び行先フィールドが、サーチカテゴリー又は探索オブジェクトにおいてサーチツールを使用して定義される。一実施形態では、ドリルダウンビューは、ポップアップブラウザにおいてショーアップされる。上述したように、一実施形態では、外部ドキュメントのプレビューもサポートされる。
【０１６７】
ユーザ手順
顧客サポート要員が、ここに述べるサーチシステムに含まれたプレビュー及びアタッチメント特徴をいかに使用するかの例を以下に説明する。この例において、「ＸＹＺ」会社の顧客サポート要員は、システムコールセンターウェブクライアントを実行し、そしてサービススクリーンと称されるスクリーンへ進む。顧客サポート要員は、ネットワークカードプロジェクトに関する自分の待ち行列にサービス要求を有すると仮定する。彼は、問題の記述を読む。彼は、それが既知の問題であり、それに対して既にソルーション（解決策）があることを通知する。次いで、サーチセンターペインをオープンし、ソルーションを選択し、そしてキーワード「ネットワークカード」をタイプする。次いで、サーチを実行し、多数のソルーションアイテムを得る。顧客サポート要員は、結果リストにおける各行／記録に対してプレビューボタンをクリックすることにより現在問題に対する適切なソリューションを識別する。顧客サポート要員は、適切なソリューションを識別した後、アタッチボタンをクリックする。このオペレーションは、結果行／記録を現在サービス要求にアタッチし、次いで、顧客サポート要員を正しいビューへ導いて、関連性を再検討させる。顧客サポート要員は、次いで、自分が見つけたソルーションを自分の顧客に文書で知らせ（例えば、ｅ−メールにより）、そしてサービス要求の状態を更新する。図４３は、上記例で説明したプロセスの一実施形態を示すフローチャートである。
【０１６８】
管理者手順
上述したように、既存のサーチカテゴリー又は新たなサーチカテゴリーに対する新たなピックビューは、上述したサーチツールを使用して構成することができる。一実施形態では、ここに述べるサーチシステムにおいて次のピックビューが実施される。
ソルーション
− サービス要求ソルーションビュー。アプレット：ＳＲソルーション
リストアプレット
− リゾルーションドキュメント管理ビュー。アプレット：ソルーション
リストアプレットで、リゾルーションドキュメント用の内部出版付き
プロダクツ
− アクティビティプロダクツビュー。アプレット：プロダクツリストＩｄ
ドリルダウンアプレット
【０１６９】
ドキュメント
− 管理セールスツールリスト。アプレット：文献リスト管理アプレット
− アグリーメントアタッチメントビュー。アプレット：アグリーメント
新アタッチメントリストアプレット
− アセットＭｇｍｔ−アセットアタッチメント。アプレット：アセット
Ｍｇｍｔ−アセットアタッチメントリストアプレット
− 欠陥詳細、アタッチメント付き。アプレット：ＰＤアタッチメントリスト
アプレット
− レゾルーションドキュメント管理ビュー。アプレット：ＳＲ
レゾルーションアイテムリストフレーム
【０１７０】
一実施形態では、ここに述べるサーチシステムにおいて次の探索オブジェクトピックビューも実施される。
アカウント
− 機会詳細−間接的アカウントビュー。
アプレット：間接的アカウントリストアプレット
会社コンタクト
− アカウント詳細−コンタクトビュー。アプレット：アカウントコンタクト
リストアプレット
− アクティビティコンタクトビュー。アプレット：コンタクト（オール）
リストアプレット
− チャンネルパートナー詳細−コンタクトビュー。アプレット：
パートナーコンタクトリストアプレット
− 機会詳細−コンタクトビュー。アプレット：機会コンタクトリストアプレット
【０１７１】
機会
− コンタクト詳細−機会ビュー。アプレット：機会リストアプレット−基本
プロダクツ欠陥
− アセットＭｇｍｔ−アセット関連欠陥リストビュー。
アプレット：プロダクツ欠陥リストアプレット−その他
サービス要求
− 関連サービス要求。アプレット：サービス要求リストアプレット
【０１７２】
一実施形態において、サーチカテゴリー又は探索オブジェクトに対する新たなピックビューを構成するために、次のことが必要となる。
− ビューは、ビューウェブテンプレートアイテムにアプレットを含む。
− アプレットは、サーチカテゴリーと同じビジネスコンポーネントに基づく。
− ピックビューが属するビジネスオブジェクトは、そのサブビジネスコンポーネントの１つとしてサーチカテゴリー又は探索オブジェクトを含む。一次ビジネスコンポーネントとサーチカテゴリー又は探索オブジェクトとの間にリンクが必要とされる。このリンクは、Ｍ対Ｍ関係であることが必要とされる（例えば、リンクに交差テーブルが存在する）。
【０１７３】
一実施形態において、データモデル仕様は、次の通りである。
Ｓ＿ＳＲＣＨ＿ＰＩＣＫＶＩＥＷ
１．ＶＡＲＣＨＡＲ２（７５）としての「ＶＩＥＷ＿ＮＡＭＥ」
２．ＶＡＲＣＨＡＲ２（７５）としての「ＡＰＰＬＥＴ＿ＮＡＭＥ」
一実施形態において、このテーブルは、貯蔵ファイルへとコンパイルされ、そして上述したサーチツールを使用して構成することができる。サーチピックビューに対する親オブジェクトは、サーチカテゴリーである。従って、サーチカテゴリーは、多数のピックビューをもつことができる。
【０１７４】
一実施形態において、ＶＩＥＷ＿ＮＡＭＥは、属性ビューネームにマップする。これは、ウェブクライアントのコンテンツエリアにおけるビューを比較するのに使用される。一実施形態において、ＡＰＰＬＥＴ＿ＮＡＭＥは、属性アプレットネームにマップする。これは、サーチ結果記録を追加できるアプレットを指定するのに使用される。
【０１７５】
図４４は、本発明の教示によるアタッチメント／関連付けプロセスの一実施形態を示すフローチャートである。
ブロック４４０５では、ｍ＿ｐＦｒａｍｅＭｇｒ：：ＧｅｔＶｉｅｗという名前の方法をコールし、コンテンツエリアペインにおいて現在ビューを得る。
ブロック４４０７では、貯蔵部において現在ビューがアクティブ結果記録のサーチカテゴリーのピックビューのリストにあるものかどうかチェックする。現在ビューがピックビューのリストにない場合には、スクリーンの定義を得、次いで、ピックビュー内にあって且つ現在スクリーン内にある第１候補ビューを探索する。
【０１７６】
ブロック４４０９では、結果記録が追加されるフレームへの参照を得る。
判断ブロック４４１１では、サーチカテゴリーが外部ドキュメントであるかどうかチェックする。外部ドキュメントである場合には、ブロック４４２１へ進み、さもなければ、ブロック４４３１へ進む。
サーチカテゴリーが外部ドキュメントである場合には、
ブロック４４２１において、アプレットに新たな記録を生成する。
ブロック４４２３において、ＣＳＳＢＣＦｉｌｅ：：ＣｒｅａｔｅＦｉｌｅという名前の方法をコールして、ファイルシステムにファイルをロードする。
ブロック４４２５において、記録を書き込む。
【０１７７】
さもなければ、
ブロック４４３１において、ＣＳＳＢｕｓＣｏｍｐ：：ＧｅｔＡｓｓｏｃＬｉｓｔ（）という名前の方法を呼び出して、関連付けリストを得る。
ブロック４４３３において、ＣＳＳＡｓｓｏｃＬｉｓｔ−＞ＳｅｔＳｅａｒｃｈＳｐｅｃ（）という名前の方法を呼び出して、記録を探索する。
ブロック４４３５において、Ｅｘｅｃｕｔｅ（）、Ｈｏｍｅ（）を呼び出す。次いで、１つの記録のみがなければならない。
ブロック４４３７において、ＣＳＳＡｓｓｏｃＬｉｓｔ：：ＡｓｓｏｃＣｕｒｒｅｎｔＲｏｗ（）という名前の方法を呼び出して、記録を関連付ける。
【０１７８】
終了
ブロック４４４１において、ｍ＿ｐＦｒａｍｅＭｇｒ：：ＢｕｉｌｄＶｉｅｗＡｓｙｎｃという名前の方法を呼び出し、コンテンツエリアにおいてビューをリフレッシュする。ビューがピックビューでない場合には、コンテンツエリアにおいてピックビューを構築する。
【０１７９】
図４５は、本発明の教示によるプレビュープロセスの一実施形態を示すフローチャートである。
ブロック４５０５では、サーチカテゴリーが外部ドキュメントであるかどうかチェックする。サーチカテゴリーが外部ドキュメントである場合には、ブロック４５１１へ進む。さもなければ、ブロック４５３１へ進む。
サーチカテゴリーが外部ドキュメントである場合には、
ブロック４５１１において、ファイル経路を検索する。
ブロック４５１３において、ｍ＿ｐＦｒａｍｅＭｇｒからＣＳＳＳＷＥＨｔｔｐＲｅｓｐｏｎｓｅに対するポインタを検索する。
ブロック４５１５において、ＣＳＳＳＷＥＨｔｔｐＲｅｓｐｏｎｓｅから出力ストリームを得る。
ブロック４５１７において、ファイルコンテンツを出力ストリームへ書き込む。
ブロック４５１９において、コンテンツタイプをルックアップし、セットする。
ブロック４５２１において、ｍ＿ｐＦｒａｍｅＭｇｒ：：ＰｏｓｔＡｃｔｉｏｎＤｏｎｅ（）という名前の方法を呼び出す。
【０１８０】
さもなければ、
ブロック４５３１において、ドリルダウンビュー、ドリルダウンビジネスコンポーネント及び行先フィールドを、選択された結果行／記録のサーチカテゴリー又は探索オブジェクト定義から検索する。
ブロック４５３３において、ビューがアクセスできるかどうかチェックする。
ブロック４５３５において、ビューのビジネスオブジェクトを得る。サーチ仕様を設定することにより行を探索する。
ブロック４５３７において、ｍ＿ｐＦｒａｍｅＭｇｒ：：ＢｕｉｌｄＶｉｅｗＡｓｙｎｃという名前の方法を呼び出す。ビューｉｄをＳＷＥ＿ＨＴＭＬ＿ＰＯＰＵＰ＿ＷＩＮＤＯＷ＿ＳＴＲにセットし、ポップアップブラウザにおいてビューがショーアップされるようにする。
終了
【０１８１】
Ｖ．リモートクライアントサーチ
概要
一実施形態において、ここに述べるシステムは、サーチインデックスファイルをリモートクライアントにダウンロードできるようにする特徴又はメカニズムも備えている。このシステムは、現在、移動及び接続の両クライアントに対しサーチ管理スクリーンを経てサーチインデックスを生成する能力を与える。
【０１８２】
現在、移動ユーザは、サーチ管理スクリーンを使用して、それらのマシンにおいてローカルにインデックスを生成することが必要である。サーチインデックスの生成は、時間のかかるタスクであるから、本発明は、移動ユーザがサーチインデックスをより効率的に生成できるような新たなメカニズムを提供する。一実施形態において、サーチインデックスは、サーバーにおいて生成され、そしてデータベースにファイルアタッチメントとしてセーブされる。同期時間中に、これらのファイルは、移動クライアントのマシンにダウンロードすることができる。
【０１８３】
一実施形態では、新たなファンクションをサポートするのに少なくとも新たなテーブルが必要とされる。この新たなテーブルに対するスキーマは、以下のデータモデルのセクションで説明する。
一実施形態において、サーチを実際に実行する前に、インデックスがローカルマシンの正しいサーチディレクトリーにコピーされるよう確保することが必要である。一実施形態において、サーチインデックス要求ビューと称されるビューを使用して、正しいディレクトリーに対するサーチインデックスを得る。
【０１８４】
図４６は、リモートサーチインデックス動作を実行するためのプロセスの一実施形態を示す高レベルフローチャートである。一実施形態において、ユーザは、どちらのインデックスオブジェクトをサーチしたいか選択し、そしてそれらをダウンロードのためにマークする必要がある。次いで、データベース同期オペレーションを実行して、インデックスファイルをアタッチメントとしてダウンロードする。次いで、ユーザは、サーチインデックス要求ビューの圧縮解除ボタンをクリックして、インデックスファイルを正しいディレクトリーへと圧縮解除する。
【０１８５】
図４７は、インデックスをＤＢ及びファイルサーバーにアップロードすると共に、インデックスをリモートクライアントにダウンロードするためのプロセスの一実施形態を示すフローチャートである。
インデックスをＤＢ及びファイルサーバーにアップロード：
ブロック４７０５において、カタログ、ディクショナリーファイル等のファルクラム発生ファイルを、キャラクタセット情報及び設定ネームと共にデータベースにファイルアタッチメントとしてセーブする。一実施形態では、これは、インデックスファイルが生成又はリフレッシュされるたびに行われる。従って、ほとんどの現在インデックスファイルは、データベースにアタッチメントとして記憶される。
【０１８６】
インデックスをリモートクライアントへダウンロード：
ブロック４７１０において、サーチインデックス要求ビューへ進み、サーチを希望するサーチインデックスを選択する（例えば、サーチを希望する各サーチインデックスに対してダウンロード列をチェックする）。
ブロック４７１５において、データベース同期を実行して、インデックスファイルアタッチメントをローカルデータベースにダウンロードする。
ブロック４７２０において、サーチインデックス要求ビューへ戻り、圧縮解除ボタンをクリックして、サーチインデックスファイルアタッチメントをローカルマシンにおいて正しいディレクトリーへと圧縮解除する。
ブロック４７２５において、インデックス及び他のファイルがコピーされると、それらに対してサーチを実行することができる。
【０１８７】
一実施形態において、サーバーからＢＤテーブルへのその後のダウンロードは、サーチインデックスファイルにおいて改訂番号が変更された場合だけ行われる。この場合に、ユーザは、もう一度インデックスファイルを上述したように圧縮解除しなければならない。
【０１８８】
図４８は、サーチインデックス要求ビュー（ＵＩ）の一実施形態を例示する図である。図４８に示すように、サーチインデックス要求ビューは、対応するインデックスファイルアタッチメントをローカルデータベースにダウンロードするために選択することのできる（例えば、対応するダウンロード列をクリックすることにより）サーチインデックスのリストを備えている。圧縮解除ボタンを使用して、サーチインデックスファイルアタッチメントがローカルマシン上の正しいディレクトリーへと圧縮解除される。
【０１８９】
データモデル仕様
一実施形態において、本発明の教示により使用されるテーブルに対するスキーマを以下に説明する。
Ｓ＿ＳＲＣＨ＿ＩＮＤＸＩＮＦＯ
一実施形態において、これは、サーチインデックス関連情報を保持するテーブルである。このテーブルは、インデックスネーム、エンジンネーム、及びキャラクタセット（又はコードページ）等を含む。
【０１９０】

【０１９１】
Ｓ＿ＳＲＣＨ＿ＩＮＤＸＩＮＦＯ＿ＡＴＴ
一実施形態において、これは、サーチエンジン＋サーチインデックス＋キャラクタセット（又はコードページ）組み合せに対して全てのサーチインデックス関連ファイルアタッチメントを保持するためのテーブルである。
【０１９２】

【０１９３】
図４９は、本発明の教示によるリモートクライアントサーチインデックスプロセスの一実施形態を示すフローチャートである。
ブロック４９０５では、各インデックスが生成されるか又はリフレッシュされた後に、インデックスファイルがファイルシステムにアタッチされ、そして記録がＳ＿ＳＲＣＨ＿ＩＮＤＸＩＮＦＯ＿ＡＴＴテーブルに挿入される。それに関連したキャラクタセット及びインデックスは、Ｓ＿ＳＲＣＨ＿ＩＮＤＸＩＮＦＯテーブルに記録される。
【０１９４】
ブロック４９１０において、移動ユーザがサーチ能力を使用する必要があるときに、先ずサーチインデックスをダウンロードしなければならない。一実施形態において、サーチインデックスをダウンロードするために、移動ユーザは、サーチインデックス要求ビューへナビゲートする。このビューにおいて、ユーザは、ダウンロードしたいインデックスに対してダウンロードチェックボックスをクリックする。一実施形態では、ユーザがダウンロードボックスをチェックするときに、システムは、Ｓ＿ＳＲＣＨ＿ＩＮＤＸＩＮＦＯ＿ＡＴＴテーブルを通過し、そしてデータベース同期が次に実行されるときに要求されるべき関連インデックスアタッチメントファイルをマークする。
【０１９５】
ブロック４９１５において、ユーザは、データベース同期を実行し、これは、マークされたインデックスファイルをリモートユーザのマシンにおいて検索する。一実施形態において、インデックスファイルが最後の同期以来変化しない場合には、それらがダウンロードされない。
ブロック４９２０において、ユーザは、サーチインデックス要求ビューへ復帰する。次いで、ユーザは、圧縮解除ボタンをクリックして、アタッチメントファイルを圧縮解除し、そしてそれらを正しいディレクトリーに入れる。プロセスが完了した後に、リモートユーザは、サーチインデックスを使用してサーチを行うことができる。
【０１９６】
添付図面に示されそしてそれら図面を参照して説明した機能的コンポーネントは、ソフトウェアコードセグメントを使用して実施できることに注意されたい。上記機能的コンポーネントがソフトウェアコードセグメントを使用して実施される場合には、これらコードセグメントは、マシン読み取り可能な媒体、例えば、フレキシブルディスク、ハードドライブ、ＣＤ−ＲＯＭ、ＤＶＤ、テープ、メモリ、又はコンピュータマシンによりアクセスできる記憶装置に記憶することができる。
【０１９７】
本発明は、好ましい実施形態に関連して以上に説明した。当業者であれば、上記説明に鑑み、多数の種々の変更や修正がなされ得ることが明らかであろう。
【図面の簡単な説明】
【０１９８】
【図１】本発明の教示が実施される多層システムアーキテクチャーを示す図である。
【図２】図１に示す多層アーキテクチャーに含まれる種々のシステムコンポーネントを示す図である。
【図３】ＨＴＭＬシンクライアントシステムコンフィギュレーションの主要コンポーネントを示す図である。
【図４】本発明の一実施形態によるサーチツールバーアイコンを例示する図である。
【図５】本発明の一実施形態によるサーチセンターフレーム又はペインを例示する図である。
【図６】種々のサーチオブジェクトを生成する例示的プロセスを一般的に示すフローチャートである。
【図７】本発明の一実施形態によりサーチエンジンオブジェクトを生成する例示的プロセスを一般的に示すフローチャートである。
【図８】本発明の一実施形態によるサーチエンジンオブジェクトの特性を一般的に示す図である。
【図９】本発明の一実施形態による例示的結果フィールドオブジェクトの特性を一般的に示す図である。
【図１０】本発明の一実施形態によりサーチインデックスオブジェクトを生成する例示的プロセスを一般的に示すフローチャートである。
【図１１】本発明の一実施形態による例示的サーチインデックスオブジェクトの特性を一般的に示す図である。
【図１２】本発明の一実施形態による例示的サーチテーブルオブジェクトの特性を一般的に示す図である。
【図１３】本発明の一実施形態により各生成されたサーチテーブルに対するインデックスフィールドマップオブジェクトを生成する例示的プロセスを一般的に示すフローチャートである。
【図１４Ａ】本発明の一実施形態による例示的インデックスフィールドオブジェクトの特性を一般的に示す図である。
【図１４Ｂ】本発明の一実施形態による例示的フィルタフィールドオブジェクトの特性を一般的に示す図である。
【図１５】サーチカテゴリーオブジェクトを生成しそして構成する例示的プロセスを一般的に示すフローチャートである。
【図１６】本発明の一実施形態による例示的サーチカテゴリーオブジェクトの特性を一般的に示す図である。
【図１７】本発明の一実施形態による例示的ピックビューオブジェクトの特性を一般的に示す図である。
【図１８Ａ】サーチ定義オブジェクトを生成しそして構成する例示的プロセスを一般的に示すフローチャートである。
【図１８Ｂ】本発明の一実施形態によるサーチ定義オブジェクトの特性を一般的に示す図である。
【図１９】本発明の一実施形態によるサーチ定義に関連した例示的サーチカテゴリーオブジェクトの特性を一般的に示す図である。
【図２０】本発明の一実施形態による例示的カスタム結果フィールドオブジェクトの特性を一般的に示す図である。
【図２１】上述した例示的サーチオブジェクト間の関係の概要を示す図である。
【図２２】本発明の一実施形態によりサーチをいかに実行するかの例示的プロセスを一般的に示すフローチャートである。
【図２３】本発明の一実施形態によるシステムのブロック図である。
【図２４】本発明の一実施形態による例示的サーチフレームを示す図である。
【図２５】本発明の一実施形態による例示的サーチ選択ビューを示す図である。
【図２６】本発明の一実施形態による例示的基本サーチビュー及び基本サーチ結果ビューを示す図である。
【図２７】本発明の一実施形態による例示的進歩型サーチビュー及び進歩型サーチ結果ビューを示す図である。
【図２８】本発明の一実施形態による例示的サーチ項セパレータ制御を示すである。
【図３０】本発明の一実施形態による例示的サーチインデックスビューを示す図である。
【図３１】本発明の一実施形態による例示的サーチ実行設定ビューを示す図である。
【図３２】本発明の一実施形態による例示的サーチ管理設定ビューを示す図である。
【図３３】交差テーブルを使用する記録の正規化解除を示す図である。
【図３４】記録をインデックスしそして正規化解除する方法の一実施形態を示すフローチャートである。
【図３５】本発明の教示に基づく方法のフローチャートである。
【図３６】本発明の教示に基づく論理的データモデルの一実施形態を示す図である。
【図３７】図３６に示す論理的データモデルの一実施形態の詳細なブロック図である。
【図３８】種々のビジネスコンポーネント間の関係を示す論理的データモデルの一実施形態を詳細に示すブロック図である。
【図３９】本発明の教示により記録をインデックスしそして正規化解除する方法の一実施形態を示すフローチャートである。
【図４０】本発明の教示によるプロセスの一実施形態を示すフローチャートである。
【図４１】本発明の教示によりフィルタサーチ仕様を生成するための方法の一実施形態を示すフローチャートである。
【図４２】本発明の教示による方法の一実施形態を示すフローチャートである。
【図４３】本発明の教示による方法の一実施形態を示すフローチャートである。
【図４４】本発明の教示による取り付け／関連付けプロセスの一実施形態を示すフローチャートである。
【図４５】本発明の教示によるプレビュープロセスの一実施形態を示すフローチャートである。
【図４６】リモートサーチインデックスを実行するためのプロセスの一実施形態の高レベルフローチャートである。
【図４７】本発明の教示によるプロセスの一実施形態を示すフローチャートである。
【図４８】サーチインデックス要求ビュー（ＵＩ）の一実施形態を示す図である。
【図４９】本発明の教示によるリモートクライアントサーチインデックスプロセスの一実施形態を示すフローチャートである。

Claims (29)

1. ユーザがユーザセッションを開始するためにサーチツールバーからサーチアイコンを選択した後にサーチセンターペインを表示し、該サーチセンターペインは、サーチフレームを含み、該サーチフレームは、クローズボタンを含み、
   上記サーチフレームにおいてサーチカテゴリーのドロップダウンリストからサーチカテゴリーを選択し、
   サーチキーワードを入力し、
   上記サーチカテゴリー及び上記サーチキーワードに一致するデータレコードに対してデータベースをサーチし、そして
   上記サーチカテゴリー及び上記サーチキーワードに一致する上記データレコードをキャッシュ処理して、ユーザがユーザセッションを終了するためにクローズボタンを選択するまで、上記データレコードの持続性を維持する、
   という段階を備えた方法。
2. 上記サーチセンターペインに結果フレームを設け、そして
   上記サーチカテゴリー及び上記サーチキーワードに一致する上記データレコードのリストを上記結果フレームにおいて表示する、
   という段階を更に備えた請求項１に記載の方法。
3. 上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを見るために上記サーチセンターペインにコンテンツエリアフレームを設ける段階を更に備えた請求項２に記載の方法。
4. サーチインデックスを選択し、そして
   上記サーチカテゴリー及び上記サーチキーワードに一致するサーチインデックスからのデータレコードについてデータベースをサーチする、
   という段階を更に備えた請求項１に記載の方法。
5. 上記サーチセンターペインにおいて結果フレームを設け、そして
   上記サーチカテゴリー及び上記サーチキーワードに一致するサーチインデックスからのデータレコードのリストを表示する、
   という段階を更に備えた請求項４に記載の方法。
6. 上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを見るために上記サーチセンターペインにコンテンツエリアフレームを設ける段階を更に備えた請求項５に記載の方法。
7. アタッチされたドキュメントを指定するサーチインデックスを選択し、そして
   上記サーチカテゴリー及び上記サーチキーワードに一致するデータレコードに対して上記アタッチされたドキュメントにおいて全テキストサーチを実行する、
   という段階を更に備えた請求項１に記載の方法。
8. 上記サーチセンターペインにおいて結果フレームを設け、そして
   上記サーチカテゴリー及び上記サーチキーワードに一致する上記アタッチされたドキュメントにおけるデータレコードのリストを表示する、
   という段階を更に備えた請求項７に記載の方法。
9. 上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを見るために上記サーチセンターペインにコンテンツエリアフレームを設ける段階を更に備えた請求項８に記載の方法。
10. サーチアイコンを含むサーチツールバーを表示し、
    ユーザがユーザセッションを開始するためにサーチアイコンを選択した後にサーチセンターペインを表示し、該サーチセンターペインは、サーチフレーム及び結果フレームを含み、
    上記サーチフレームにおいてサーチカテゴリーのドロップダウンリストからサーチカテゴリーを選択し、
    サーチキーワードを入力し、
    上記サーチカテゴリー及び上記サーチキーワードに一致するデータレコードに対してデータベースをサーチし、
    上記サーチカテゴリー及び上記サーチキーワードに一致する上記データレコードのリストを上記結果フレームにおいて表示し、そして
    上記結果フレームにリストされたデータレコードをキャッシュ処理して、ユーザがユーザセッションを終了するためにクローズボタンを選択するまで、上記データレコードの持続性を維持する、
    という段階を備えた方法。
11. 上記サーチフレームにコンテンツエリアを設け、
    上記結果フレームにおいて表示されたデータレコードのリストからデータレコードを選択し、そして
    上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを表示する、
    という段階を更に備えた請求項１０に記載の方法。
12. サーチインデックスを選択し、そして
    上記サーチカテゴリー及び上記サーチキーワードに一致する上記サーチインデックスからのデータレコードについてデータベースをサーチする、
    という段階を更に備えた請求項１０に記載の方法。
13. 上記サーチカテゴリー及び上記サーチキーワードに一致する上記サーチインデックスからのデータレコードのリストを表示する段階を更に備えた請求項１２に記載の方法。
14. 上記サーチフレームにコンテンツエリアを設け、
    上記結果フレームに表示されたデータレコードのリストからデータレコードを選択し、そして
    上記結果フレームに表示されたデータレコードのリストから選択されたデータレコードのコンテンツを表示する、
    という段階を更に備えた請求項１３に記載の方法。
15. アタッチされたドキュメントを指定するサーチインデックスを選択し、そして
    上記サーチカテゴリー及び上記サーチキーワードに一致するデータレコードに対して上記アタッチされたドキュメントにおいて全テキストサーチを実行する、
    という段階を更に備えた請求項１０に記載の方法。
16. 上記サーチカテゴリー及び上記サーチキーワードに一致する上記アタッチされたドキュメントにおけるデータレコードのリストを表示する段階を更に含む請求項１５に記載の方法。
17. 上記サーチフレームにおいてコンテンツエリアを設け、
    上記結果フレームに表示されたデータレコードのリストからデータレコードを選択し、そして
    上記結果フレームに表示されたデータレコードのリストから選択されたデータレコードのコンテンツを表示する、
    という段階を更に備えた請求項１６に記載の方法。
18. サーチカテゴリーのリストと、サーチキーワードを入力するためにキーワードボックスとを含むサーチフレームであって、クローズボタンも含んでいるサーチフレームと、
    上記サーチキーワードに一致するデータレコードのリストと、上記サーチフレームに表示されたサーチカテゴリーのリストから選択されたサーチカテゴリーとを表示するための結果フレームと、
    上記結果フレームに表示されたデータレコードをキャッシュ処理して、ユーザセッションを終了するために上記クローズボタンが選択されるまで、上記データレコードの持続性を維持するビジネスサービスと、
    上記結果フレームに表示されたデータレコードのリストから選択されたデータレコードを表示するためのコンテンツエリアフレームと、
    を備えたシステム。
19. 上記サーチフレームは、サーチインデックスのリストと、該サーチインデックスのリストから選択されたサーチインデックスとを表示し、そして
    上記結果フレームは、上記サーチカテゴリー及びサーチキーワードに一致する上記選択されたサーチインデックスにおけるデータレコードのリストを表示する請求項１８に記載のシステム。
20. 上記サーチフレームは、サーチインデックスのリストと、該サーチインデックスのリストから選択されたサーチインデックスとを表示し、その選択されたサーチインデックスは、アタッチされたドキュメントを指定し、そして
    上記結果フレームは、上記アタッチされたドキュメントにおいて全テキストサーチが実行された後に上記サーチカテゴリー及びサーチキーワードに一致する上記アタッチされたドキュメントにおけるデータレコードのリストを表示する請求項１８に記載のシステム。
21. マシンにより実行されたときに、
    サーチアイコンを含むサーチツールバーを表示し、
    ユーザがユーザセッションを開始するためにサーチアイコンを選択した後にサーチセンターペインを表示し、該サーチセンターペインは、サーチフレームを含み、該サーチフレームは、クローズボタンを含み、
    上記サーチフレームにおいてサーチカテゴリーのドロップダウンリストからサーチカテゴリーを選択し、
    サーチキーワードを入力し、
    上記サーチカテゴリー及びサーチキーワードに一致するデータレコードに対してデータベースをサーチし、そして
    ユーザがユーザセッションを終了するために上記クローズボタンを選択するまで、上記サーチカテゴリー及びサーチキーワードに一致するデータレコードをキャッシュ処理する、
    という段階を備えたオペレーションをマシンが実行するようにさせる命令を備えたマシン読み取り可能な媒体。
22. サーチセンターペインにおいて結果フレームを設け、そして
    上記サーチカテゴリー及びサーチキーワードに一致するデータレコードのリストを上記結果フレームにおいて表示する、
    という段階を更に備えた請求項２１に記載のマシン読み取り可能な媒体。
23. 上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを見るために上記サーチセンターペインにコンテンツエリアフレームを設ける段階を更に備えた請求項２２に記載のマシン読み取り可能な媒体。
24. サーチインデックスを選択し、そして
    上記サーチカテゴリー及び上記サーチキーワードに一致するサーチインデックスからのデータレコードについてデータベースをサーチする、
    という段階を更に備えた請求項２１に記載のマシン読み取り可能な媒体。
25. 上記サーチセンターペインにおいて結果フレームを設け、そして
    上記サーチカテゴリー及び上記サーチキーワードに一致するサーチインデックスからのデータレコードのリストを表示する、
    という段階を更に備えた請求項２４に記載のマシン読み取り可能な媒体。
26. 上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを見るために上記サーチセンターペインにコンテンツエリアフレームを設ける段階を更に備えた請求項２５に記載のマシン読み取り可能な媒体。
27. アタッチされたドキュメントを指定するサーチインデックスを選択し、そして
    上記サーチカテゴリー及び上記サーチキーワードに一致するデータレコードに対して上記アタッチされたドキュメントにおいて全テキストサーチを実行する、
    という段階を更に備えた請求項２１に記載のマシン読み取り可能な媒体。
28. 上記サーチセンターペインにおいて結果フレームを設け、そして
    上記サーチカテゴリー及び上記サーチキーワードに一致する上記アタッチされたドキュメントにおけるデータレコードのリストを表示する、
    という段階を更に備えた請求項２７に記載のマシン読み取り可能な媒体。
29. 上記結果フレームにおいて表示されたデータレコードのリストから選択されたデータレコードのコンテンツを見るために上記サーチセンターペインにコンテンツエリアフレームを設ける段階を更に備えた請求項２８に記載のマシン読み取り可能な媒体。

Images