(57)【特許請求の範囲】
【請求項１】
複数のサーバ上でそれら複数のサーバと夫々関連し、関連するサーバ上の少なくとも一つのサイトに関係するデータのインデックスファイルを夫々作成するための、複数のサーバエージェントと、
インデックスファイルからインデックス情報を記憶するための中央インデックスであって、そこではサーバエージェントが、サーバエージェントから中央インデックスへのインデックスファイルを転送するために、中央インデックスとの通信を開始する、中央インデックスと
を含み、
少なくとも１つのサイトが、データベースへのアクセスによって作成される少なくとも１つの動的ページを提供し、動的ページに関連するインデックスファイルが、対応する形式処理プログラムによって有効なページを作成する、予定の入力データを含む、
インデクシングシステム。
【請求項２】
それぞれのサーバエージェントが、関連するサーバ上の少なくとも１つのサイトをレビューするように適応され、形成されて中央インデックスに伝送されるインデックスファイルは少なくとも１つのサイトへの変更を表し、インデックス情報を更新するためのものである、請求項１に記載のインデクシングシステム。
【請求項３】
それぞれのインデックスファイルが、それぞれのサーバのサイトでリンクの有効性に影響を及ぼすあらゆる変化に関する情報を含む、請求項２に記載のインデクシングシステム。
【請求項４】
サーバエージェントが、前記変化を特定する際に、変更の結果生じた無効にされたリンクを含む別のサイトに関連付けられる対応するサーバに、変更の通知を伝送するように配列される、請求項３に記載のインデクシングシステム。
【請求項５】
中央インデックスが、変更によって影響を受けたサイトを特定し、そのサイトに関連付けられた対応するサーバに通知を伝送するように適応される、請求項４に記載のインデクシングシステム。
【請求項６】
通知が、対応するサーバに関する情報を更新するためのアクションを実施するように適応されている対応するサーバのそれぞれのサーバエージェントに伝送される、請求項５に記載のインデクシングシステム。
【請求項７】
通知が、対応するサーバの管理者に伝送され、通知受信時に、管理者が対応するサーバに関する情報を更新するためのアクションを実施できる、請求項５に記載のインデクシングシステム。
【請求項８】
動的ページに関連するインデックスファイルが、さらに、動的ページに関する、予定の出力データおよびテキストを含む、請求項１又は２に記載のインデクシングシステム。
【請求項９】
動的ページに関連付けられるサーバエージェントが、データベースにアクセスし、インデックスファイル内のデータベースの１つまたは複数の列を含むように適応される、請求項１又は２に記載のインデクシングシステム。
【請求項１０】
動的ページに関連付けられるサーバエージェントが、データベースのあらゆる変化を特定するためにデータベース内にトリガを導入し、変化が動的ページに関連付けられるインデックスファイルに含まれる、請求項１又は２に記載のインデクシングシステム。
【請求項１１】
動的ページに関連付けられるインデックスファイルが、ユーザにより過去に検索されたページの入力データの記録を含む、請求項１又は２に記載のインデクシングシステム。
【請求項１２】
動的ページに関連付けられるインデックスファイルが、ユーザにより過去に検索された、動的ページのテキスト全文のインデックスを含む、請求項１又は２に記載のインデクシングシステム。
【請求項１３】
入力／出力組または行／列索引付けが記憶される各動的ページに関連付けられたインデックスファイルが、さらに、形式処理プログラムおよびページに関連付けられたテキストを特定するための識別子を含む、請求項１又は２に記載のインデクシングシステム。
【請求項１４】
探索照会に応じて中央インデックスにアクセスするためのサーバを含む、請求項１又は２に記載のインデクシングシステム。
【請求項１５】
サーバが提供するサイトを索引付けするためにサーバ上にサーバエージェントを提供することと、
サイトのサイトデータを表すインデックスファイルであって、サイトの動的ページに関する情報と、動的ページを作成するための、予定の入力データとを含むインデックスファイルをコンパイルすることと、
中央インデックスにファイルを伝送し、サーバエージェントがインデックスファイルの転送のために中央インデックスとの通信を開始することとを含む、索引付けする方法。
【請求項１６】
サーバエージェントがサイトを処理し、インデックスファイルが１つまたは複数のサイトへの変更を表し中央インデックスにより保持されるインデックス情報を更新するために用いられる、請求項１５に記載の索引付けする方法。
【請求項１７】
サーバエージェントがサイトに関するリンク情報を記録し、リンク情報の有効性に影響を及ぼすあらゆる変化がインデックスファイルに記録される、請求項１６に記載の索引付けする方法。
【請求項１８】
関連付けられたサーバエージェントのある複数のサーバの内の１つでの前記変更を特定し、それぞれのサーバエージェントから、変更の通知を、そのリンクの別のサイトに関連付けられた対応するサーバに伝送することを含む、請求項１７に記載の索引付けの方法。
【請求項１９】
中央インデックスが、サイトアドレスのリストを有し、前記変更を示すインデックスファイルの受信時に、変更によって影響を及ぼされる、関連付けられたサイトが特定され、通知が影響を及ぼされるサイトの対応するサーバに送信される、請求項１７に記載の索引付けする方法。
【請求項２０】
通知が、対応するサーバに関する情報を更新するためのアクションを実施する対応するサーバの関連サーバエージェントに伝送される、請求項１８に記載の索引付けする方法。
【請求項２１】
通知が対応するサーバの管理者に伝送され、通知の受信時に、管理者が対応するサーバに関する情報を更新するためのアクションを実施できる、請求項１８に記載の索引付けする方法。
【請求項２２】
インデックスファイルが動的ページを生成するために使用される、予定の出力データを含む、請求項１５に記載の索引付けする方法。
【請求項２３】
動的ページに関連付けられるサーバエージェントが、動的ページを作成する少なくとも１つのデータベースを特定し、インデックスファイルに包含するためにテキストおよび入力組を抽出する、請求項１５に記載の索引付けする方法。
【請求項２４】
サーバエージェントが、前記入力組と関連付けられる出力組を抽出する、請求項２３に記載の索引付けする方法。
【請求項２５】
前記サーバエージェントが、インデックスファイルに包含するためにデータベースの列を抽出する、請求項２４に記載の索引付けする方法。
【請求項２６】
サーバエージェントが、データベース内で変化が起きるとサーバエージェントに報告するためにデータベース内にトリガを導入し、該変化がインデックスファイルに含まれる、請求項２３に記載の索引付けする方法。
【請求項２７】
インデックスファイルが、過去に検索された動的ページを作成するために使用されたデータの記録を含む、請求項１５に記載の索引付けする方法。
【請求項２８】
インデックスファイルが、ユーザにより過去に検索された、動的ページのテキストのインデックスを含む、請求項１５に記載の索引付けする方法。
【請求項２９】
前記サーバエージェントが、ファイルを所定の位置に格納することにより前記通信を開始する、請求項１に記載のインデクシングシステム。
【請求項３０】
前記通信がインターネットにおいて為される、請求項１に記載のインデクシングシステム。
【請求項３１】
前記サーバエージェントが、ファイルを所定の位置に格納することにより前記通信を開始する、請求項１５に記載の索引付けする方法。
【請求項３２】
前記通信がインターネットにおいて為される、請求項１５に記載の索引付けする方法。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、サーバからアクセス可能なデータのインデックスを作成する方法およびシステムに関し、特に、インターネット上に含まれる情報用のインデックスを作成する方法およびシステムに関する。
【０００２】
（発明の背景）
インターネット等の分散型通信網の特徴の１つとしては、無制限のアクセスを提供し、かつネットワーク上でデータを自由に公表することが挙げられる。しかし、ネットワークが拡大するにつれて、ユーザが必要とするデータの位置を突き止めることはきわめて困難になり、データに対する分かりやすいまたは有効なインデックスまたはポータルを維持することはなおさらに難しくなっている。データは、テキスト、グラフィックス、ビデオ、音声およびプログラムデータまたはコードを含んでもよい。効果的に中央制御権威を持たないインターネットの成長は、現在では必要とされるデータの位置を突き止めることが、無駄骨を折ることに類似するほどである。それにも関わらず、数多くの企業はサーチエンジンおよびインターネットデータ、特にワールドワイドウェブ上で公表されるデータへのポータルを維持する。
【０００３】
大部分のサーチエンジンは、エンジンが、キーワードなどの照会用語に基づいて探索できるウェブページのインデックスに依存している。該インデックスは、通常、ウェブアドレス、すなわち全域資源位置指示子（ＵＲＬ）のデータベースによって提供され、テキスト情報の用語は、ウェブに掲載されるテキストの各ページを表すために使用される。
【０００４】
Ｌｙｃｏｓ、Ｈｏｔｂｏｔ等の多くのサーチエンジンは、典型的には通常のＨＴＴＰプロトコルによって、ウェブページを検索するためのスパイダプログラムを使用してインデックスを獲得し、索引付けしなければならないこのページからデータを抽出する。同時に、他のページのリンクも注記され、プロセスはその後新規に発見されたリンクについて繰り返される。これは自動的に実行されるため、ビジットされたウェブサイトの管理者または作者からの協力は必要とされない。しかしながら、ページは、処理のためにすべて中央サイトに持ち込まれ、処理されるデータの量のために、新規のページまたは修正されたページが、処理されるには数ヶ月待機しなければならない場合がある。
【０００５】
Ａｌｉｗｅｂなどの分散されたインデクサが利用可能である。このシステムでは、インデクシング情報は、システム管理者またはページの作者によってテンプレートの中に手動で入力される。それから、ページは検索のためにスパイダプログラムが使用できる。ページについての情報は人間によって生成されるため、ページコンテンツについての情報は、通常非常に正確である。しかしながら、多くの管理者および作者はこのような情報を提供する態勢になく、多くの場合テンプレートを完成させるために十分な時間を費やさないため、インデックスはしばしば不完全且つ時代遅れである。
【０００６】
Ｙａｈｏｏによって最初に提供されたサーチエンジンなどの別の種類のサーチエンジンでは、インデックスは、人間によるページの手作業の検査で構築される。検査は手作業であるため、特定のトピックの下のウェブページの分類は、ページの質のレーティングがそうであるように、通常、かなり正確である。しかしながら、使用できる人々の数が限られ、カバーされるウェブの範囲および新しいウェブページと修正されたページがレビューされる速度は制限されている。
【０００７】
Ｆｉｓｈなどのクライアントベースのサーチエンジンは、個人の探索者またはウェブユーザを拠点としている。彼らは、合意可能なユーザインタフェースについて、および個人専用される探索についてさらに大きな範囲を提供する。しかしながら、彼らは、ウェブのかなりの部分を独立して探索する場合に大量の帯域幅を無駄にする可能性がある。
【０００８】
ＭｅｔａＣｒｒａｗｌｅｒやＤｏｇｐｉｌｅなどのいくつかのサーチエンジンは、探索要求を受信すると、他のサーチエンジンの探索サイトを探索し、これらからの結果を受信し、ユーザに表示するために結果を統合する（これがメタサーチ（ｍｅｔａｓｅａｒｃｈ）として知られている）。これが、いくつかのサーチエンジンは、他のサーチエンジンによってビジットされていないサイトからのデータを含むので、ウェブのより優れたカバレージにつながる。しかしながら、これは非効率的なアプローチであり、さまざまな探索インデックスの間にはかなりの重複があるため、ユーザに結果を戻す際に追加の遅延もあり、関連する順序で結果を格付けするために使用できる方法は限られている。
【０００９】
Ｈａｒｖｅｓｔなどの別の種類の分散型サーチエンジンは、サイトを十分に調べ、そのコンテンツに索引付けをし、それらをサイトで格納されているファイルに入れるために、さまざまなウェブサーバでギャザラ（Ｇａｔｈｅｒｅｒｓ）と呼ばれる装置を有する。これらのインデックスファイルは、ある特定の探索についてユーザによって起動されるＢｒｏｋｅｒｓのような既知のプログラムによって検索できる。このアプローチは、帯域幅の使用に関して節約するが、スパイダは、依然として、サーバに記憶されているインデックスが定期的に更新されていることを確実にするために、定期的にサイトをビジットしなければならない。
【００１０】
インターネット上で使用可能なウェブページのインデクシングは、数多くの困難を呈する。これらは、インターネット自体のダイナミズム、およびインターネット上での情報のダイナミズムを含む。これが、ウェブについて完全に最新で、完成したインデックスがないという状況を生じさせる。
【００１１】
他の重要な問題とは、（９０％を超えると推定される）インターネット上での情報の大半が、動的ページ用の基礎として使用されるデータベース内に位置しているという点である。動的ページとは、ｈｔｍｌで手作業によって作成されないが、むしろそれらを構成するｈｔｍｌがプログラムまたはスクリプトによって「動的に」作成されるか、あるいは情報が、例えばＪａｖａを使用するなど、なんらかの他の方法で提示されるページのことである。これらのページは、ユーザが照会を提出する時点でプログラムによって構築される。スパイダなどの最新のインデクシング方法は、動的ページに、または動的ページを作成するために使用されるデータベースにも索引付けをすることはできない。
【００１２】
（発明の概要）
本発明に従って、サーバからアクセス可能なデータのインデックスを作成するための方法であって、前記サーバ上でデータを処理して中央インデックス用のデータアイテムにアクセスすることであって、前記データアイテムがネットワークアドレスと用語を含むことと、
前記データアイテムを含むインデックスファイルをコンパイルすることと、
前記インデックスファイルを前記中央インデックスに伝送することとを含む、方法を提供する。
【００１３】
また本発明は、本方法のステップを実行するための構成要素を有するエージェントを提供する。
【００１４】
好ましくは、本方法は、
前記中央インデックスで、インデックスデータベースを有する前記インデックスファイルを受信することと、
前記インデックスファイル内のエントリに基づいて前記インデックスデータベースを維持することであって、前記インデックスデータベースがサーチエンジンによる使用のために適応されていることとをさらに含む。
【００１５】
また本発明は、
ページを作成するためのプログラムに提出するために動的ページおよび入力組を作成するためのプログラム用プログラムアドレスを含むページエントリと、
動的ページを特定し、検索用語に対応する組を特定する探索エントリと、
を含む、サーバからアクセス可能なデータのインデックスを提供する。
【００１６】
また本発明は、
探索照会の探索用語に対応する動的ページを特定するために探索エントリにアクセスするための手段と、
特定された動的ページのためにアドレスを作成するためにページエントリにアクセスするための手段であって、前記アドレスが前記プログラムアドレスおよび前記組に基づいて作成される手段とを含む、インデックス上で利用可能なサーチエンジンを提供する。
【００１７】
また本発明は、エージェント、インデックスおよびサーチエンジンを含むインデクシングシステムを提供する。
【００１８】
また本発明は、
少なくとも１つのサイトへのアクセスを提供するためのサーバと、
サイトに関係するデータのインデックスファイルを作成するためのサーバエージェントと、
インデックスファイルからのインデックス情報を記憶するための中央インデックスであって、サーバエージェントがインデックスファイルの転送のために中央インデックスとの通信を開始する中央インデックスとを含む、インデクシングシステムを提供する。
【００１９】
また本発明は、
サーバが提供するインデクシングサイトにサーバエージェントを提供することと、
サイトのサイトデータを表すインデックスファイルをコンパイルすることと、
中央インデックスにファイルを伝送し、そこではサーバエージェントがインデックスファイルの転送のために中央インデックスとの通信を開始することとを含む、検索付けする方法を提供する。
【００２０】
また本発明は、
動的ページを作成する際にアクセスされる少なくとも１つのデータベースを特定することと、
データベースのパラメータおよび環境変数を求めることと、
ページの入力フィールドとデータベース間の関係性を決定することと、
入力に対応するデータベースの列を特定することと、
インデックスファイル内で入力を介してアクセスできるデータベースの行のデータを記憶することとを含む、動的ページを索引付けするための方法を提供する。
【００２１】
また本発明は、前記ユーザコンピュータシステム上に記憶されるネットワークアドレスの変更を決定するために、インデクシングシステムのインデックスと通信するための手段を有する、ユーザコンピュータシステム上で実行可能なブラウザエージェントを提供する。
【００２２】
以下で、本発明の好ましい実施形態を、添付の図面を参照しながら例のみを用いて説明する。
【００２３】
（発明の好ましい実施形態の詳細な説明）
分散方法でインデクシングデータをレビューし、照合するが、この中央記憶は標準的な方法で分散またはミラー化することができるが、ユーザによるアクセスのためのインデクシングデータを中心的に記憶するインターネット用のインデクシングシステムが後述される。該インデクシングシステムは、中央記憶装置を提供する中央インデックス（ＣＩ）２１４と通信する、図２に図示されるような、数多くのサーバベースエージェント（ＳＢＡ）２０８、２２２を含む。システムは、探索要求を処理するときに中央インデックスを使用する中央サーチエンジン（ＣＳＥ）２１６も含む。エージェント２０８、２２２は、サーバ製造業者によって分散される各ハイパテキスト転送プロトコル（ＨＴＴＰ）とともに含むことができる。エージェントは、追加済み新規サイト／ページ、削除済み旧ページ、または修正された旧ページなどのそのローカルサーバ上でデータに加えられた変化がないか定期的にチェックする。注記される修正派、リンク、静的ページまたは動的ページの削除、作成または修正を含んでよい。あらゆる変更があった場合、エージェントはインデックスデータファイルを作成し、ＣＩの中央インデクシングデータベースに関連するインデクシング変更を報告する。中央インデクシングデータベースは、ＣＳＥなどのオンラインで使用可能なサーチエンジン用の包括的且つ最新のインデクシングデータベースである。
【００２４】
インデクシングシステムが、
（ｉ）最新インでクスを維持する、
（ｉｉ）インターネットの大部分をカバーするインデックスを作成する、
（ｉｉｉ）旧いリンクを管理、更新する、
（ｉｖ）動的に作成されたページを索引付けする、
（ｖ）個々のウェブサイトに関する詳細な統計情報を収集する、
（ｖｉ）高度比較ショッピング機能を用いてｅ−コマースポータルを作成する
ことができることは、以下の説明から明らかになるだろう。
【００２５】
図１は、ユーザがインデクシングシステムを使用してデータを検索するために使用するのに適した典型的なコンピュータシステム２００の図である。コンピュータ２００は、１台または複数台の中央処理装置（ＣＰＵ）１０２、メモリシステム１０４、入力／出力（Ｉ／Ｏ）アダプタ１０６、二次記憶装置１０８、ネットワークインタフェース１１０、ユーザインタフェースアダプタ１１４、およびディスプレイアダプタ１１２を含んでよい。コンピュータ構成要素のすべては、システムバス１１５によって接続される。該ディスプレイアダプタ１１２は、ユーザに対して推奨策を表示するためにディスプレイ１１６に接続されてよい。該ユーザインタフェースアダプタ１１４は、ユーザ入力装置１１８に接続されてよい。ユーザは、ネットワークインタフェース１１０を通してインターネットに接続されてよい。ユーザは、例えば、Ａｍｅｒｉｃａ  Ｏｎｌｉｎｅ（登録商標）などのサービスプロバイダに対するモデムを通した接続などのインターネットインタフェース１２０に、あるいはケーブル接続を通してインターネットサービスプロバイダに接続されてよい。
【００２６】
図２では、ユーザ２００は、インターネット２０４に結合される、インターネットサービスプロバイダ（ＩＳＰ）２０２に接続される。やはりインターネット２０４に結合されるのは、典型的には、例えばｈｔｍｌページおよびその他の文書とスクリプトを含んでよい１つまたは複数のサイトへのアクセスを実現、提供するＨＴＴＰサーバ（ＨＳ）２０６である第１サーバである。ＨＳサーバ２０６は、第１ＨＳサーバ１０６上の文書からデータ収集活動を実施するサーバベースエージェント（ＳＢＡ）２０２を含む。ＳＢＡ２０８は、いつでも動作してよいか、あるいは非活動の期間が散在する間隔の間実行してよい。ＳＢＡ２０８は、収集されたデータブロック２１０に記憶される、すべての文書更新のリスティングを作成するためにＨＳサーバ２０６上に位置するすべての文書を調べる。ＳＢＡ２０８は、インデックスサーバ２１２で実行されるソフトウェアによって提供できる、インデックスファイルまたはインデックスデルタファイルの形の文書更新のリスティングを中央インデックス（ＣＩ）２１４に伝送する。インデックスファイルは、データの位置究明用のアドレスとともに、多様なウェブページに含まれるものなどの、ネットワーク上の多様なロケーションに含まれるものに関する情報を提供するデータのファイルである。該ファイルは、複雑な構造を有してよく、数多くのファイルおよび／またはサーバ上で分散されてよい。インデックスファイルに対する参照は、ネットワーク上のデータに対する変更という点で既存のインデックスファイルに加えられる必要のある変更を単に含むファイルである、インデックスデルタファイルに対する参照も含んでよい。インデクシングシステムの効率的なインプリメンテーションが、後述されるように、ＳＢＡおよびＣＩとＣＳＥのソフトウェアインプリメンテーションを提供することであり、ＣＩが図１３に関して後述されるアーキテクチャを有することが、当業者に明らかとなるだろう。また、インターネットのような通信網で数多くの構成要素を分散できること、およびソフトウェア構成要素の数が、ソフトウェア構成要素と同じプロセスを実行する、ＡＳＩＣなどのハードウェア回路にいよって置換できることも当業者に明らかになるだろう。
【００２７】
ＣＩ２１４は、例えば、ＳＢＡ２２２およびＳＢＡ２２２によって第２サーバ２２０上のウェブページから収集された、収集済みデータ２２４の選択したものも有する、第２サーバ２２０などの多数のその他のサーバから更新を受け取る。ＣＩ２１４は、第１ＨＳ２０６および第２ＨＳ２２０などの多様なサーバから受信される更新を組み込むためにそのコンテンツを更新する。インデックスサーバ２１２は、ＣＳＥ２１６も備えてよい。サーチエンジン２１６のインタフェースは、なんらかのＵＲＬに位置してよい。サーチを実行するように要求されると、サーチエンジン２１６は、応答を形成する前にＣＩ２１４のエントリを通して探索してよい。しかしながら、中央サーチエンジン（ＣＳＥ）２１６は、ＣＩ２１４と同じサーバ２１２に位置する必要はない。
【００２８】
ＣＩ２１４の機能は、指定領域について、または指定ドメインについてであるが、ＣＩ２１４と類似した機能を実行する数多くの領域インデックスにも適用されてよい。これらの領域インデックスは、ＣＩ２１４がすべてのサーバ用のインデクシング情報を維持するように、ＣＩ２１４の領域インデックス情報を提供してよい。
【００２９】
１．１  サーバベースエージェント（ＳＢＡ）
ＳＢＡは、そのサーバ上のデータを自動的に探索するサーバ上のプログラムである。それは、ウェブサーバの一部である場合もあれば、別個である場合もある。ＳＢＡは、典型的には遭遇する状況に反応し、長い時間期間実行してよい。それは、サーチエンジンが、ウェブサーバのサイトで入手できる静的ウェブページと動的ウェブページの両方ともを探索できるようにするＣＩに情報を送信することができる。それは、旧いリンクに対処するために、いつページが移動または削除されるのかを通知することもでき、それは、ウェブサーバごとに、サーチエンジン結果の格付けを改善するために使用できるウェブページ使用量データを収集することができる。
【００３０】
基本ＳＢＡによって実施される基本的なアクションは以下のとおりである。
（ａ）ｕｐｄａｔｅ＿ｌｏｃａｌ（）――ローカルサーバ上のデータの変化を注記し、ｌｏｃａｌ＿ｉｎｄｅｘファイルおよびｉｎｄｅｘ＿ｄｅｌｔａファイルを構築する。
（ｂ）ｒｅｐｏｒｔ（ＣＩ＿ａｄｄｒｅｓｓ，ｉｎｄｅｘ＿ｄｅｌｔａ）――アドレスＣＩ＿ａｄｄｒｅｓｓでＣＩに対するレポートを作成し、更新動作で検出された局所的な変更を記述するｉｎｄｅｘ＿ｄｅｌｔａファイルを伝送する。
【００３１】
ＳＢＡ２０８は、２つの基本的なインデクシング機能、つまり専用のインデックスとｉｎｄｅｘ＿ｄｅｌｔａファイルの更新、およびＣＩ２１４へのｉｎｄｅｘ＿ｄｅｌｔａファイあるの報告を実行する。これらの２つの基本的なインデクシング機能は同じ頻度で動作してよい。例えば、ＳＢＡ２０８は、例えば２４時間毎などの定期的な間隔でエージェント２０８に動作するようにプロンプトを出すタイマを有してよい。アクティブでない間、ＳＢＡ２０８は、過去のアクティブ期間からのサーバ上のすべての文書のそのインデックスエントリを維持する。ＳＢＡ２０８がそのタイマによって目覚まされると、それはサーバサイトのディレクトリツリーの変化がないか、あるいは個々のファイルが変更されたかどうかをチェックする。検出されるあらゆる変化は記憶されてから、ＣＩ２１４に報告される。変化がない場合、ＳＢＡ２０８０は、帯域幅を保存するように、ＣＩ２１４にｉｎｄｅｘ＿ｄｅｌｔａファイルを送信しないようにプログラミングされてよい。ＳＢＡ２０８は、そのサーバサイトにある文書用のそのローカルインデックスファイルも更新する。
【００３２】
定期的な予定された間隔で更新する代わりに、ＳＢＡ２０８は、ウェブサイト上のページが変更されるたびに更新してよい。このケースでは、ＳＢＡ２０８は変更の著者（またはウェブサイト管理者）に、該変更をＣＩ２１４に即座に提出するように申し出てよい。また、ＳＢＡ２０８は、同じダイアログ中に著者に、著者がページを反映すると感じるあらゆる主題キーワードを入力する、あるいは更新するようにプロンプトを出してよい。それから、これらのキーワードはｉｎｄｅｘ＿ｄｅｌｔａファイルでＣＩ２１４に提出されてよい。言うまでもなく、著者はキーワードを入力するというオプションを単に無視してよい。
【００３３】
レポート動作間の時間は固定された間隔で設定されてよいか、あるいはローカルサーバ２０６またはインデックスサーバ２１２の性質またはニーズに合うように動的に改変されてよい。
【００３４】
更新動作の一部として、ＳＢＡ２０８は、ローカルサーバ２０６上のページ内のハイパテキストリンクをレビューしてよい。その後、該レビューされたリンクは、リンクが加算されたのか、あるいは減算されたのかを判断するために過去の更新動作中に形成されたリンクリストと比較される。ＳＢＡ２０８は、ＣＩ２１４に転送されるｉｎｄｅｘ＿ｄｅｌｔａファイルに変更されたリンクのリストを含める。それから、この情報は、ＣＩ２１４によって、さらに詳細に後述される数多くの方法の内の１つまたは複数を使用して旧いリンクに対する参照を削除するために使用されてよい。
【００３５】
ＳＢＡ２０８は、インターネットのユーザによってページがアクセスされた回数とそのページで費やされた時間、これらのユーザがサイトをビジットする直前にいたページ、サイトについての帯域統計、および前回の更新動作以来どのような接続が行われたのかなどの、ローカルサーバ２０６についての統計情報を収集するように構成されてもよい。このような情報は、サイトの設計およびレイアウトを最適化するのを補助するウェブサイト管理者または著者にとって有効である場合がある。このような情報は、中央リポジトリ内で照合されると、余分なインフラストラクチャがインターネットに追加される必要があるところを特定するための有効なデータ、つまり探索結果の集合内でページの関連性格付けを決定する際のサポート情報を提供してよい。
【００３６】
ＳＢＡは、後述されるように、動的ページを索引付けすることができ、それが特定のアプリケーションの特殊目的インデックスを作成する機会を提供する。この１つの例が、ＳＢＡがインストールされているその他のｅ−コマースサイトに関する情報を提供するｅ−コマースポータルサイトを形成するｅ−コマースインデックスである。
【００３７】
特殊目的ＳＢＡの別の例は、代理サーバを含むアプリケーションである。
【００３８】
１．２  中央インデックス（ＣＩ）
ＣＩ２１４は、ＳＢＡ２０８と２２２が、それらが報告するｉｎｄｅｘ＿ｄｅｌｔａを有するときにＣＩ２１４に接続するという点で、対応するＳＢＡ２０８と２２２に対するサーバとしての役割を果たす。ＣＩ２１４は、典型的には、ＨＴＴＰサーバ２１２、つまりインデックスサーバを通してインターネットに接続される。
【００３９】
ＣＩ２１４は、ある特定のサーバからｉｎｄｅｘ＿ｄｅｌｔａファイルを受信すると、ＣＩ２１４はそのインデックスデータベースを相応して更新する。インターネット探索者が使用するためにＣＳＥ２１６は、インデックスデータベース内の新しいデータを即座に使用できる。
（ｉ）ＳＢＡが、独自のパラメータ設定値に基づきＣＩにインデックスファイルを送信することと、
（ｉｉ）ＳＢＡが、独自のパラメータ設定値に基づき、ＣＩにｉｎｄｅｘ＿ｄｅｌｔａファイルを送信することと、
（ｉｉｉ）ＳＢＡが、ＣＩに変化が発生した旨のショートメッセージを送信し、その結果ＣＩが既存の方法によるインデクシングのために、あるいはインデックスまたはｉｎｄｅｘ＿ｄｅｌｔａファイルを検索するためにスパイダを送信することを含むが、それに制限されない、それが選ぶ任意の方法で後に変化を検索してよいことと、
（ｉｖ）ＳＢＡが、ＣＩに対してよりむしろ領域インデックスに対しショートメッセージまたはインデックスまたはｉｎｄｅｘ＿ｄｅｌｔａファイルを送信することと、
を含む、ＳＢＡとＣＩ間でデータが転送されてよい方法について数多くのオプションがある。
【００４０】
ＣＩ２１４は、インデクシングデータを蓄積することに加え、ローカルサーバでのロードに関係する統計も蓄積してよい。
【００４１】
ＣＩ２１４は、すべてのインターネット文書の構築日付と修正日付のリストも有してよい。このデータリストは探索で役に立ってよく、あるトピックに関する最も最新の情報を得るための有効な機構を可能にする。ＣＩ２１４は、日付リスト内の情報に基づき、サイトがもはや維持されていないサイトであるかどうかも評価してよい。
【００４２】
２．１  旧いリンク
ＣＩはインデックスデータベース内に、それに対するリンクを含むあるいはそれを参照するページのＵＲＬを一覧表示する、ＵＲＬごとのインデックスを維持する。これが、各主題ＵＲＬを、主題ＵＲＬにリンクしているページを有するそれ以外のＵＲＬに関係付けるＵＲＬのライブラリである。ある特定のＵＲＬが削除された、あるいは移動されたことを示すインデックス情報がＣＩに報告されると、ＣＩは、どのＵＲＬが削除されたＵＲＬへのリンクを含むのかを判断するためにＵＲＬインデックスを探索してから、参照側サーバのそれぞれでＳＢＡに通知を送信してよい。その後、ローカルＳＢＡが、このような通知に応えてなんらかの処置を講じてよい。例えば、ＳＢＡは、著者に参照側ページを、あるいはウェブサイト管理者に、リンクが削除または移動されたことを通知してよい。ＳＢＡは、自動処置を講じるようにプログラミングされてもよい。ＳＢＡが削除されたあるいは移動されたリンクを考慮して講じてよい自動処置の一例とは、マークされたリンクがもはや有効ではないことを示すために、参照側ページのｈｔｍｌコードに警告を追加することである。別の例は、ＳＢＡが、可能であるならば、ＵＲＬがこれまで参照していたサイトのルートディレクトリへのリンクでリンクを置換してよいということである。ＣＩが、ＵＲＬが削除されたというよりむしろ移動されたと通知される場合、参照側サイトにあるＳＢＡは、新しいＵＲＬに対するリンクを更新するように構成されてよい。
【００４３】
旧いリンクは、サーバ上の既存のｈｔｍｌ文書内のリンクがなんらかの方法で変更されると発生する。該変更とは、ターゲットページとしても知られるリンク内で参照されるページが削除された、移動された（例えば、そのＵＲＬが変更された）、あるいはそのコンテンツが修正された場合である可能性がある。変更は伝達され、その結果参照側ページをロードするまたは見るユーザは、例えば、空のターゲットページ、または元のリンクの著者がリンクを形成するときに依存していた情報をもはや含んでいないターゲットページに導かれない。
【００４４】
ｈｔｍｌ文書内でリンクを形成するための共通構文は以下のとおりであり、
＜ｈｒｅｆ＝“ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｌｉｎｋｔｏ＿ｄｏｃ．ｈｔｍｌ”＞ｌｉｎｋ  ｐｈｒａｓｅ＜／Ａ＞
この場合、「ｈｒｅｆ」は別の文書に対するハイパリンクを作成するために使用されるｈｔｍｌ属性であり、「ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｌｉｎｋｔｏ＿ｄｏｃ．ｈｔｍｌ」は、それ以外の場合ターゲット文書として知られている、リンクされている文書のインターネットアドレスであり、「ｌｉｎｋ  ｐｈｒａｓｅ」は、ｌｉｎｋｔｏ＿ｄｏｃ．ｈｔｍｌへのリンクに続くためにクリックするｈｔｍｌ文書中の句のことである。それ以外の属性は、「ｈｒｅｆ」属性に加えて、同文書内の別の点へのリンクを形成するために使用されてよい。
【００４５】
同じウェブサイト内で発生する旧いリンクについて、ＳＢＡは、これらを自動的に更新するためにセットアップされるか、あるいは代わりにそれはウェブサイト管理者に、彼らがＳＢＡを使用することにより手動で変更を実現するのか、あるいは自動的に実現するのかを決定できるように知らせることができるだろう。
【００４６】
図３に図示されるように、ＳＢＡは、ステップ３０２で、別のタグを探索することによってリンクがないかサーバ上の第１ｈｔｍｌ文書を走査する。ＳＢＡは、ステップ３０４で、文書中で見つけられたリンクのリストを形成する。リストは、例えば、形式（ｌｉｎｋ＿ｆｒｏｍ，ｌｉｎｋ＿ｔｏ）を取る数多くの組を含んでよく、この場合ｌｉｎｋ＿ｆｒｏｍはソースｈｔｍｌ文書を示し、ｌｉｎｋ＿ｔｏはターゲットｈｔｍｌ文書（つまり、リンクが指す文書）を示す。
【００４７】
それから、ＳＢＡは、ステップ３０６で、過去のリンク走査以来発生したリンク内の変化を特定する。それから、変化したリンクに関係するこれらのリンク組が、ステップ３０８で、ｌｉｎｋｃｈａｎｇｅ＿ｌｉｓｔファイルに記憶される。それから、ＳＢＡは、ステップ３１０で、サーバ上の残りのｈｔｍｌ文書の走査を進め、その結果ｌｉｎｋｃｈａｎｇｅ＿ｌｉｓｔは、サーバ上のすべての文書に含まれているリンクのすべての変化を含む。
【００４８】
それから、ＳＢＡはさまざまな経路に沿って進んでよいか、あるいは並列経路に沿って進んでよい。ステップ３１２で、進むための１つのオプションは、ＳＢＡがその他のサーバにｌｉｎｋｃｈａｎｇｅ＿ｌｉｓｔに含まれる関連する変化を伝送することである。このアプローチは、インターネット４４０を通して通信中の３つのサーバ４１０、４２０および４３０を示す図４に示されている。サーバ名ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ１．ｃｏｍを有する第１サーバ４１０は、ＳＢＡ＿ｓｅｒｖｅｒ１と題されるＳＢＡ４１２を有する。Ｄｏｃ１．ｈｔｍｌと題されるｈｔｍｌ文書４１４は、第１サーバ上に存在する。第２サーバ４２０は、アドレスｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ２．ｃｏｍを有し、ＳＢＡ＿ｓｅｒｖｅｒ２と呼ばれるＳＢＡ４２２も有する。第２サーバは２つのｈｔｍｌ文書、つまりｄｏｃ２．ｈｔｍｌ  ４２４とｒｅｆｌ．ｈｔｍｌ  ４２５を有する。第３サーバ４３０は、アドレスｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ３．ｃｏｍを有する。第３サーバ４３０はＳＢＡ＿ｓｅｒｖｅｒ３と呼ばれるＳＢＡ４３２を有する。第３サーバ４３０は、ｒｅｆ２．ｈｔｍｌと題されるｈｔｍｌ文書４３５を有する。
【００４９】
第１サーバ４１０上のｈｔｍｌ文書ｄｏｃ１．ｈｔｍｌ  ４１４は、第２サーバ４２０上のｒｅｆ１．ｈｔｍｌ  ４２および第３サーバ４３０上のｒｅｆ２．ｈｔｍｌ  ４３５に対するリンクを含む、数多くのリンクを含む。ステップ３０４で前述されたように、各サーバ上のＳＢＡは、ソース文書およびターゲット文書の組のリストを作成する。したがって、第１ＳＢＡ４１２によって作成されるｌｉｎｋｔｏ＿ｌｉｓｔファイル４１６は、描かれている少なくとも２つの組、つまり
（ｗｗｗ．ｓｅｒｖｅｒ１．ｃｏｍ／ｄｏｃ１．ｈｔｍｌ，ｗｗｗ．ｓｅｒｖｅｒ２．ｃｏｍ／ｒｅｆ１．ｈｔｍｌ）および
（ｗｗｗ．ｓｅｒｖｅｒ１．ｃｏｍ／ｄｏｃ１．ｈｔｍｌ，ｗｗｗ．ｓｅｒｖｅｒ３．ｃｏｍ／ｒｅｆ２．ｈｔｍｌ）
を含む。
【００５０】
同様にして、第２サーバ４２０は、ソース文書が第２サーバ４２０上のｈｔｍｌ文書であり、ターゲット文書がソース文書内のリンクによって参照される文書である、ソース文書およびターゲット文書の組を一覧表示し、その他のサーバ上で記憶されるｌｉｎｋｔｏ＿ｌｉｓｔファイル４２６も含む。示されている例では、ｄｏｃ２．ｈｔｍｌ  ４２４は、第３サーバ上のｒｅｆ２．ｈｔｍｌ  ４３５に対するリンクを含む。結果的にｌｉｎｎｋｔｏ＿ｌｉｓｔファイル４２６は、組（ｗｗｗ．ｓｅｒｖｅｒ２．ｃｏｍ／ｄｏｃ２．ｈｔｍｌ，ｗｗｗ．ｓｅｒｅｒ３．ｃｏｍ／ｒｅｆ２．ｈｔｍｌ）を含む。サーバ４１０、４２０および４３０は、その他のサーバ上の文書へのリンクを有する追加文書を含んでよい。
【００５１】
図３を参照し直すと、ステップ３１２で、ＳＢＡ４１２は、ｌｉｎｋｃｈａｎｇｅ＿ｌｉｓｔの関連する変化を、ターゲット文書が位置するサーバに伝送する。例えば、ｄｏｃ１．ｈｔｍｌからのリンクのあらゆる変化は、ターゲット文書を含む関連するサーバに報告される。このようにして、ｄｏｃ１．ｈｔｍｌがｒｅｆ２．ｈｔｍｌへのリンクを含むように変更される場合には、この新規リンクはｌｉｎｋｃｈａｎｇｅ＿ｌｉｓｔに含まれ、この組はサーバ４２０に伝送される。サーバ４２０は、サーバ４１０から情報を受信し、第２リスト、ｌｉｎｋｆｒｏｍ＿ｌｉｓｔ  ４２８を第１サーバ４１０とそれ以外のサーバから受信された情報からアセンブルする。Ｌｉｎｋｆｒｏｍ＿ｌｉｓｔファイル４２８は、他の文書によってリンクされる第２サーバ４２０上に含まれる文書のリストである。
【００５２】
同様に、第３サーバ４３０上のｒｅｆ２．ｈｔｍｌは、２つの異なる文書、つまり第１サーバ４１０上のｄｏｃ１．ｈｔｍｌ  ４１４と第２サーバ４２０上のｄｏｃ２．ｈｔｍｌ  ４２４によってリンクされる。第３サーバ４３０は、ｄｏｃ１．ｈｔｍｌとｄｏｃ２．ｈｔｍｌによってｒｅｆ２．ｈｔｍｌがリンクされる第１サーバと第２サーバ４１０と４２０から情報を受信し、その情報はｌｉｎｋｆｒｏｍ＿ｌｉｓｔ  ４３８からアセンブルされる。
【００５３】
このプロトコルの元では、各ＳＢＡは、すべてのリンクについてソースファイルとターゲットファイルを示すｌｉｎｋｔｏ＿ｌｉｓｔファイルをアセンブルし、この場合ソースはそのサーバ上に含まれる。ＳＢＡは、他のサーバ上のどの文書がそのサーバ上に含まれる文書に接続するリンクを有するのかを示す他のサーバから受信される情報からｌｉｎｋｆｒｏｍ＿ｌｉｓｔもアセンブルする。各ＳＢＡは、リンクについてそのサーバ上に含まれる文書を定期的に走査し、図３に図示されるステップに示されるように、リンクの変化を特定する。これは、例えば、２４時間毎、または週に一度、あるいはサーバ上に記憶されているｈｔｍｌページに対して加えられる修正の予想される頻度に従ってサーバ管理者によって選択されるそれ以外のなんらかの定期的な時間間隔で発生してよい。これにより、各ＳＢＡが、妥当に最新であるｌｉｎｋｆｒｏｍ＿ｌｉｓｔファイルをアセンブルできることが確実になる。
【００５４】
それから、ステップ３１６で、ＳＢＡは、そのサーバ上のターゲットｈｔｍｌ文書で検出された変更を、ソースｈｔｍｌ文書、つまりカレントサーバへのリンクを含むそれらの文書を含むそれらのサーバに伝送してよい。これは、ソース、つまりｌｉｎｋ＿ｔｏ文書のサーバが、ターゲット文書での変更に従ってソース文書中のリンクに適応できるようにする。これは、さらに後述される。
【００５５】
更新されたリンクを維持し、旧いリンクを回避するための別のプロトコルは、リンクの変化をＣＩに伝送するというステップ３１８を含む。ＣＩは、文書間のすべてのリンクのリストを維持し、ソース文書に、ターゲット文書の変化が受信されると、ターゲット文書の変化をソース文書に知らせる。
【００５６】
これは、ｈｔｍｌ文書を含み、インターネット５０４を介して接続される第１ＨＴＴＰサーバ、第２ＨＴＴＰサーバ、および第３ＨＴＴＰサーバ、５１０、５２０および５３０を示す図５に参照してさらに説明される。第１サーバ５１０は、ＳＢＡ＿ｓｅｒｖｅｒ１と呼ばれるＳＢＡ５１２を含み、第２サーバと第３サーバ５２０と５３０もそれぞれのＳＢＡ５２２と５３２を含む。それぞれのＳＢＡは、ステップ３０４による方法でｌｉｎｋｔｏ＿ｌｉｓｔファイル５１６、５２６および５３６をアセンブルする。第１サーバ、第２サーバおよび第３サーバ５１０、５２０、および５３０は、そのアドレスが、例えば、ｈｔｔｐ：／／ｗｗｗ．ｃｉ．ｃｏｍである中央インデックスサーバ５５０に接続される。ＣＩサーバ５５０は、ＣＩ５５２を含む。ＣＩは、前述されたような方法で接続されたサーバから受信されるインデクシング情報を含む。
【００５７】
第１ＳＢＡ５１２は、ステップ３１８でリンクの変化をＣＩに伝送する。ＣＩ５５２は、文書間のすべてのリンクのリスティングであるｌｉｎｋ＿ｌｉｓｔ  ５５４を維持する。したがって、第１サーバ５１０上のｄｏｃ１．ｈｔｍｌ  ５１４は、ｒｅｆ１．ｈｔｍｌとｒｅｆ２．ｈｔｍｌへのリンクを含み、ｌｉｎｋ＿ｌｉｓｔは、組（ｗｗｗ．ｓｅｒｖｅｒ１．ｃｏｍ／ｄｏｃ１．ｈｔｍｌ、ｗｗｗ．ｓｅｒｖｅｒ２．ｃｏｍ／ｒｅｆ１．ｈｔｍｌ）、および組（ｗｗｗ．ｓｅｒｖｅｒ１．ｃｏｍ／ｄｏｃ１．ｈｔｍｌ、ｗｗｗ．ｓｅｒｖｅｒ３．ｃｏｍ／ｒｅｆ２．ｈｔｍｌ）を含む。さらに、第２サーバ５２０上のｄｏｃ２．ｈｔｍｌ  ５２４は、第３サーバ５３０のｒｅｆ２．ｈｔｍｌ５３５へのリンクを含む。したがって、ファイルｌｉｎｋ＿ｌｉｓｔ  ５５４も、組（ｓｅｒｖｅｒ２．ｃｏｍ／ｄｏｃ２．ｈｔｍｌ、ｓｅｒｖｅｒ３．ｃｏｍ／ｒｅｆ２．ｈｔｍｌ）を含む。ＣＩ５１２は、すべてのリンク情報を含むので、このプロトコルには各サーバでのｌｉｎｋｆｒｏｍ＿ｌｉｓｔファイルを維持するという要件はない。
【００５８】
図６は、別のサーバ上のターゲット文書が変更されたという情報を受信したのに応えてＳＢＡによって実行されるプロセスを示す。ローカルＳＢＡは、ステップ６０２で、変更の種類の表示とともに、ターゲット（ｌｉｎｋ＿ｔｏ）文書内の変更の通知を受け取る。それから、ＳＢＡは、ターゲット文書が削除されたかどうかを判断する。
【００５９】
ターゲット文書が削除されたのか、あるいはそれ以外の場合取り除かれたのかを判断すると、ＳＢＡは、以下の処置の１つまたは複数を講じてよい。第１にＳＢＡは、ステップ６０６で、サーバ管理者にメッセージを伝送し、管理者にターゲット文書の変更を通知する。管理者は、サーバ上のどの１つのまたは複数のソース文書が問題のターゲット文書へのリンクを含むのかに関しても知らされてよい。このようにすることを許可されている、あるいはこのようにするように構成されている場合、ＳＢＡは、例えば、リンクが無効であることを示すためにソース文書中にマークを挿入することによって、ステップ６０８でソース文書を自動的に修正してよい。さらに、ＳＢＡは、ステップ６１０で、ソース文書からリンクを削除することを許可される、あるいは削除するように構成されてよい。さらに、ＳＢＡは、ステップ６１２で、代替ターゲット文書への新規リンクで、現在の主題文書へのリンクを置換することを許可される、または置換するように構成されてよい。
【００６０】
代替文書を決定する１つの考えられる方法は、同じワードを含み、これらのワードについて類似したワード頻度のものを見つけることだろう。ＣＩは、削除された文書から１０個の最も頻繁なワードを有するすべての文書に対する探索を行うことができるだろう。これらの文書の集合の内、それは削除された文書ワード頻度に最も近い相対的なワード非インドを有するものを探すことができる。これは、文書中のワードの頻度を示す、順方向インデックスを調べることを含むだろう。
【００６１】
ＳＢＡが、ターゲット文書のＵＲＬが変更されたと判断すると、ステップ６１４、ＳＢＡはサーバ管理者にＵＲＬの変更に関する通知を提供してよい、ステップ６１６。ＳＢＡは、ステップ６１８で、ソース文書のアンカータグ内のターゲット文書のＵＲＬを修正することを許可される、あるいは修正するように構成されてもよい。
【００６２】
ＳＢＡがターゲット文書が削除されていないし、移動されてもいないと判断する場合には、ＳＢＡはターゲット文書のコンテンツが変化したかどうかを、ステップ６２０で判断する。
【００６３】
ページのコンテンツが大きく変化したかどうかを判断する１つの方法は、ページのタイトルが大きく変化したかどうかを確かめることである。これは、テキストの２つの小さな部分を比較することを必要とする。過去のタイトルの部分列が残っている場合には、ページはおそらく大きく変化しなかったのだろう。すべてのワードが異なる場合には、旧いワードと新しいワードの間には何の意味的なリンクはなく（ｗｏｒｄＮｅｔなどの意味辞書が使用できる）、そのときには、コンテンツが大きく変化したと結論付けることができる。
【００６４】
いったんＳＢＡが、ステップ６２２で、ターゲット文書のコンテンツの変化が十分に重要であると判断すると、ＳＢＡは、１つまたは複数の方法で進んでよい。例えば、ＳＢＡは、ステップ６２３で、ターゲットページのコンテンツの変化をサーバ管理者に知らせるだけでよい。それから、管理者は、著者が、ターゲットページが依然としてソースページからのリンクを維持する価値があるかどうかに関して手動の決定を下すことができるように、ソースページの著者に知らせてよい。ＳＢＡは、ステップ６２４で、ソース文書内のリンクを削除することを許可されるか、あるいは削除するように構成されてよい、あるいはステップ６２６で、ターゲット文書へのリンクを、代替ターゲット文書への新しいリンクで置換することを許可されてよい。
【００６５】
代替文書を選ぶ方法は、文書が削除された前記ケースと同じである。
【００６６】
ＳＢＡは、ステップ６２８で、ターゲット文書が位置しているサーバがもはや使用できないと判断してもよい。使用できない場合には、ＳＢＡは以下のステップの１つまたは複数を講じてよい。ＳＢＡは、ステップ６３０で、サーバ管理者に、ターゲット文書を含むサーバがもはや使用できない旨を知らせてよい。ＳＢＡは、このようにすることを許可されている、あるいはこのようにするように構成されている場合には、ターゲット文書がもはや使用できないことを示すマークによって、ステップ６３２でソース文書を修正してよい。ＳＢＡは、このようにすることを許可されている、あるいはこのようにするように構成されている場合は、ステップ６３４で、ソース文書内のリンクを単に消去してもよい。また、ＳＢＡは、ステップ６３６で、ソース文書内のリンクを代替ターゲット文書への新しいリンクで置換してもよい。
【００６７】
ターゲット文書のサーバのＳＢＡは、図７に示されるように、ターゲット文書が変化した、または移動したことをユーザに警告するためのステップを講じてもよい。いったんＳＢＡが他のサーバ上のソース文書がリンクを有するｈｔｍｌ文書内に変化があることを検出すると、ステップ７０２、ＳＢＡは、ステップ７０４で、ターゲット文書の変化が、ユーザが変化に関して警告されなければならないほど十分に重要であるかどうかを判断する。
【００６８】
ＳＢＡが、ユーザが文書に対する変化に関して通知されなければならないと判断する場合、ＳＢＡは、ステップ７０６で文書が削除されたかどうかを判断する。ターゲット文書が削除されている場合には、ＳＢＡは、ステップ７０８で、ターゲット文書が削除されていることをユーザに知らせる新しいｈｔｍｌ文書を形成することを許可される、または形成するように構成されてよいか、あるいはステップ７１０で、削除されたターゲットページの代わりに、表示する代替ページをユーザに知らせる新しいｈｔｍｌ文書を作成してよい。
【００６９】
ＳＢＡが、ステップ７１２で、ターゲット文書のＵＲＬが変更されたと判断すると、ＳＢＡは、ステップ７１４で、旧いＵＲＬで、ユーザに新しいＵＲＬを通知する新しいページを作成してよい。この新しいページは、新しいＵＲＬでのターゲット文書へのハイパテキストリンクも含んでよい。
【００７０】
ＳＢＡは、限られた時間、新しいページを掲示するように構成されてよい。新しいページが表示される時間の長さは、古いＵＲＬへの追加リンクが残っているかどうかに従って設定されてよい。ＳＢＡは、どのソース文書が古いＵＲＬにリンクするのかを示す現在のｌｉｎｋ＿ｆｒｏｍリストを維持する。ステップ７１６で、古いＵＲＬへのこれ以上のリンクが残っていないことが判断されると、ステップ７１８で新しい宛先変更ページが削除されてよい。加えて、ＳＢＡは、ステップ７２０で、例えば６ヶ月などの所定の長さの時間が経過した後に古いＵＲＬの新しいページを削除するようにプログラミングされてよい。
【００７１】
ユーザのブラウザが、変化したことがある、または変化した、またはもはや使用できないサイトに、ユーザを向けるブックマークを含んでいないことを確実にするために中央インデックスによって維持されるデータベースに対して参照を有することができる。該ブラウザは、図８にステップ８０２で、ブックマークが付いたページが依然として使用できる旨を確実にするために、中央インデックスを用いて定期的にチェックするエージェントが提供できる。ブラウザエージェントが、ステップ８０４で、ブックマークが消えていると判断すると、ブラウザエージェントは、ステップ８０６で、ブックマークを無効であるとマークしてよい。ブラウザエージェントが、ステップ８０８で、中央インデックスから、ブックマークがそのＵＲＬを変更したと判断すると、ブラウザエージェントは、ステップ８１０で、新しいＵＲＬを反映するためにブックマークを変更するように構成されてよい。ブラウザエージェントが、ステップ８１２で、ブックマークに位置するページのコンテンツが変更されたと判断すると、ブラウザエージェントは、ステップ８１４で、ユーザに代替のブックマークを勧めてよい。
【００７２】
２．２  動的ページおよび生成された静的ページ
動的ページとは、ｈｔｍｌで手作業により作成されないウェブページのことであり、典型的には、それらを構成するｈｔｍｌは、プログラムによって「動的に」作成される。これらのページは、例えば、ｈｔｍｌ形式照会がユーザによって提出される時点でプログラムによって構築される。大部分の動的なページは、その構築においてデータベースからのデータを使用する。それ以外の種類の動的ページ（例えば、チャート）は、ＪａｖａまたはＪａｖａｓｃｒｉｐｔプログラムまたはスクリプトによって構築される。動的ページは、そのＵＲＬがブラウザによって要求されるたびにプログラムまたはスクリプトによって生成されるウェブページであると見なすことができ、それはウェブサーバ上には記憶されていない。大部分の動的ページは、バックエンドデータベースから作成される。いくつかのページは、事前にデータベースから生成され、静的ページとして記憶されてよく、動的ページに対する参照は、通常、作成された、または事前に作成された静的ページを含むと解釈されなければならない。入力組は、有効な動的ページを結果的に戻す入力を送信するために使用される。
【００７３】
データベース内に情報を含むいくつかのサイトは、要求時に動的なページを作成しないが、定期的に更新される多数の静的ページを作成するためにスクリプトを使用する。これらのページは、一般的には、どこか他のところからのそれらに対するリンクはないだろうという点で、動的ページに類似した特性を有する。したがって、スパイダなどの従来のインデクシング方法は、スパイダがリンクを介してウェブページを見つけるため、これらのページを見つけない可能性がある。これらの作成された静的ページは、考えられるすべてのページの包括的な集合よりむしろ、頻繁にアクセスされる動的ページのキャッシュであってよい。作成された静的ページまたは事前に作成された静的ページは、（例えば、考えられるページのすべてまたは部分集合を作成することによって、あるいはそれらが検索されるにつれて動的ページをキャッシュに入れることによって）データベース内の情報へのアクセスを加速するために静的ページとして記憶されるウェブページであると見なすことができる。これらは、他の静的ページと同じように捕捉されてよいが、動的ページまたはデータベースへの接続を認識することによってさらに効率的に索引付けられてよく、動的ページに対する参照は、通常、作成されたまたは事前に作成された静的ページを含むと解釈されなければならない。動的ページおよびこれらの作成された静的ページの索引付けは以下に後述される。
【００７４】
以下の詳細な説明から理解されるように、作成される静的ページサイトはページを作成し、高速アクセスのための静的ページとしてそれらを記憶するが、事前に作成される静的ページの作成は、ＳＢＡが作成し、動的ページを索引付けるが、それらを記憶しない方法（後述されるケース２．３）に類似している。したがって、作成される静的ページは、他の任意の静的ページのようにＳＢＡによって索引付けられるだろうが、組の表現は、ＳＢＡがすべてのこれらの作成されたページを表すための最もコンパクトな方法であり、これらのページを作成するスクリプトは、索引付け時にＳＢＡによって使用できる。したがって、これらの静的ページは、静的なリンクが、動的リンクよりむしろＣＳＥによる探索結果ページで作成されるという点を除き、動的ページ組インデクシング方法（後述されるケース２．１）によって処理される。
【００７５】
ｈｔｍｌ形式は、ウェブページの視聴者が、彼らが現在アクセスしているウェブサイトに情報を提出できるようにするｈｔｍｌでの構成子である。例えば、Ｌｙｃｏｓなどのサーチエンジンを使用するとき、ユーザは、１つまたは複数のキーワードを、それらを現在表示されている画面の一部の中に打ち込むことによって提出し、それから「探索」などの画面上のボタンをクリックしてキーワードの転送を開始する。それから、キーワードは、現在アクセスされているウェブサイトで受け取られる。
【００７６】
ｈｔｍｌ形式構成子は、ユーザによって提出されるワードまたは入力を処理するプログラムに名前を指定する。これは、動的ページを作成するプログラムである。このようなプログラムは、多くの場合、ｃｇｉスクリプト（ｃｇｉは、「共通ゲートウェイインタフェース」を意味する）であるだろう。該ｃｇｉスクリプトはユーザによって送信される情報を受信し、情報を、ローカルデータベースまたはリモートデータベースからの情報の部分に対する要求として解釈し、ＳＱＬ照会などのデータベースに対する照会を作成する。それから、ｃｇｉスクリプトは、データベースから要求されたデータを検索し、このデータを使用してページを構築し、動的ページをユーザに戻す。動的ページを作成するために使用されるｃｇｉスクリプト以外のプログラムがあり、ここでの形式処理プログラムに対する参照は、動的ページを生成するために使用できる（Ｊａｖａサーブレットおよびリモートメソッドを含む）機械コードまたは中間または仮想機械コードに従って解釈されるか、あるいはコンパイルされるかに関係なく、任意の種類の、あるいは任意の言語での任意のスクリプトまたは実行可能なファイルを意味すると解釈されなければならない。用語は、ユーザが新規探索を開始できるようにするためのフィールド、およびＪａｖａウィンドウなどの入力を収集するそれ以外の手段を含む動的ページも含むが、形式ページは、ユーザが入力を指定するためのフィールド、メニュー、および／またはその他の手段を含むウェブページであると見なすことができ、最も多くの場合は静的ページである。動的ページを作成するために、形式ページがどのようにして使用されるのかを示す例は、ＳＢＡが図１１に示されるようにサーバ２０６上でどのように動作するのかを示すときに、図９から図１０に関して後述される。
【００７７】
２．２．１  動的ページおよび作成された静的ページの索引付けの概要
２．２．１．１  ＳＢＡの動作
動的ページを索引付けするためにＳＢＡによって実行される一般的なステップは、図１２に図示されている。インストール中、ＳＢＡは、ステップ１２０２でウェブサイト管理者のニーズに合うように構成されてよい。例えば、ＳＢＡは、（ｉ）どの程度頻繁にＳＢＡが変化がないかウェブサイトをチェックするのか、（ｉｉ）旧いリンクの自動的な更新、つまりウェブサイト管理者だけに提案された更新で警告する
（ｉｉｉ）索引付けられてはならないページに対する制限
（ｉｖ）索引付けられてはならないデータベース（複数の場合がある）内のデータ（例えば、列）に対する制限（例えば、機密情報、重要ではないまたは有効ではない情報、あるいはそれ以外の情報がユーザによって提供される場合にだけ表示されなければならない情報―この最後の点の例は、ユーザがある人の名前を入力し、電話番号が戻される場合であり、これは逆に起こってはならない。
（ｖ）変更が、索引付けられるように設定されていたデータベースに加えられるときに、ＳＢＡが自動的に索引付け情報を更新するオプション（「データベーストリガ」）
を含む、数多くのパラメータで構成されてよい。
【００７８】
いったん構成されると、ＳＢＡは、ステップ１２０４で、ローカルウェブサイトを精査し、動的ページの作成で使用されるデータベース（複数の場合がある）を見つける。それから、ＳＢＡは、種類、使用される照会言語、ユーザ名とパスワード、およびアクセス方法などの各データベースについての追加情報を決定し（この情報は、ウェブサイト管理者によって手作業で提供されるか、ＳＢＡによって自動的に決定されてよい）、その結果ＳＢＡは、ステップ１２０６で各データベースに接続し、各データベースからデータを検索することができる。それから、ＳＢＡは後述される方法の１つを使用し、関連するデータベース（複数の場合がある）からインデクシング情報を抽出し、圧縮されたフォーマットをとってよいこの情報は、ステップ１２０８で、後述される方法の１つを使用してＣＩに送信される。このようにするように構成されている場合、ＳＢＡは、ステップ１２１０で、索引付けられているデータベースにいつ変更が加えられるのかを自動的に検出するトリガをインストールする。それから、ＳＢＡは、ステップ１２１４で、発生した可能性のあるあらゆる変化についてウェブサイトをチェックする前に、インストールプロセス中、またはそれ以降に設定されてよい事前に定められる期間（ステップ１２１２で）待機する。サイトが変化した場合（ステップ１２１６）、ＳＢＡは、ステップ１２１８で、ＣＩに関連するインデックス情報を送信する。
【００７９】
２．２．１．２  ＣＩの動作
図１３は、ＣＩ２１４の構造およびＣＳＥ２１６に対する関係性を示す。索引付け情報が多くのＳＢＡから受信されると、ＣＩインデクサ１３００は、まず、この情報のために順方向インデックスエントリ１３０２と１３０４を構築する。それから、それは、反転されたインデックス１３０６を更新するために、順方向インデックスエントリ内の情報を利用する。それから、ＳＢＡとＣＩがデルタ、つまりインデックスデルタファイルと通信しない限り、静的ページ１３０４の順方向インデックスエントリは削除される可能性があり、そのケースではそれらの順方向インデックスエントリは残らなければならない。それらを削除すると、静的ページに必要とされるＣＩでの記憶域は大幅に削減されるだろう。動的ページ１３０２に対する順方向インデックスエントリは、通常、削除できない。順方向インデックスと反転インデックスが構築されてよい方法に対して、反転インデックスが順方向インデックスからの表を共用するアプローチを含む、数多くの代替アプローチがあることが注意されなければならない。反転インデックス１３０６の索引が付けられた用語のディクショナリおよび／またはシソーラスを備えることができる照会用語の辞典１３０８が維持される。辞典１３０８の機能が、反転インデックス１３０６の中に統合できることが当業者に明らかになるだろう。
【００８０】
辞典１３０８は、ｗｏｒｄＩＤマッピングにワード、つまり用語を提供し、反転インデックス１３０６は、ｗｏｒｄＩＤをｄｏｃＩＤマッピングに提供し、順方向インデックス１３０２、１３０４は、ｄｏｃＩＤをＵＲＬマッピングに提供する。探索者が、探索するものに、１つまたは複数の照会を提供するとき、辞典１３０８は、インデックス内に用語が存在しているかどうか、および存在する場合には、その対応するｗｏｒｄＩＤを突き止めるために調べられる。それから、反転インデックスは、探索者の照会用語を含む、文書の完全な集合を表すｗｏｒｄＩＤのすべてのｄｏｃＩＤを見つけるために探索される。
【００８１】
反転インデックス１３０６に記憶される情報は、
（ｉ）ｄｏｃＩＤが静的ページに対応するのか、動的ページに対応するのか
（ｉｉ）照会用語が、（タイトルなどの）重要なフィールドで見つけられるのか、テキストの本文で見つけられるのか
（ｉｉｉ）照会用語が、指定された文書内で密接に位置し（そのためおそらく関係付けられ）ているのか、あるいは明らかに関係付けられていないのか
（ｉｖ）文書が、照会用語のすべてを含むのか、あるいはいくつかだけを含むのか
を含んでよい。
この情報は、ユーザの照会に十中八九関連しているそれらの文書がリストの先頭にあるように、ｄｏｃＩＤのリストを並べるために使用される。それから、ｄｏｃＩＤごとに、順方向インデックスが調べられ、元の文書を検索できるＵＲＬを突き止める。動的ページのケースでは、これは、形式処理プログラムＵＲＬ、方法、入力フィールドおよび入力組からＵＲＬを構築し直すことを必要とする。順方向インデックスコンテンツは、探索者が指定した可能性のある正確な句の存在を確認するために、およびどれが求める結果になるのか（ｗｈｉｃｈ  ｒｅｓｕｌｔｓ  ｔｏ  ｐｕｒｓｕｅ）を考えるときに、探索者がレビューしてよい関連するコンテンツの短い抜粋を提供するために使用されてもよい。
【００８２】
図１４に関して、ＣＩは、ステップ１４０２でＳＢＡからのメッセージを受信するために待機する。ＣＩがメッセージを受信すると、それは、ステップ１４０４で、新しい索引付け情報を追加し、その順方向インデックス１３０２、１３０４内の既存の索引付け情報を修正する。それから、ＣＩは新しい索引付け情報を追加し、ステップ１４０６で、その逆インデックス１３０６内の既存の索引付け情報を修正する。それから、ＣＩはＳＢＡからの追加メッセージを待機する。
【００８３】
２．２．１．３  ＣＳＥの動作
図１５に関して、ＣＳＥは、ステップ１５０２で、ユーザが探索と一句に関する情報を要求するのを待機する。ＣＳＥは、ステップ１５０４で、ユーザがブラウザを通して適切な探索情報（例えば、キーワード）を入力し、サーチエンジンウェッブページ上の提出ボタンまたは探索ボタンを押すことによって照会を受け取る。ＣＳＥは、ステップ１５０６で、ＣＩの逆転インデックス１３０６を調べ、それぞれのキーワードに一致する動的ページ作成点のリストを形成する。それから、ＣＳＥは、ステップ１５０８で、すべての照会ワードに一致する動的ページ作成点を見つけるためにキーワードのリストをマージし、結果的に事前結果リストを生じさせる。事前結果リスト内のアイテムは、ステップ１５１０と１５１２で、この情報を含む有効な動的ページがあるかどうかを確かめるためにチェックされる。ない場合には、アイテムは（ステップ１５１４で）リストから削除され、次のアイテムがチェックされる。この情報を含む有効な動的ページがある場合には、このページを作成する入力が注記され、結果リストに入れられ、エントリは、ステップ１５１６で事前結果リストから削除される。各アイテムは、ステップ１５１８で、何も残らなくなるまで（何かが残されている場合、ＣＳＥはステップ１５１０に戻る）事前結果リスト内でチェックされる。ステップ１５１６で決定される入力を使用して、ＵＲＬが、ステップ１５２０で、結果リスト内の動的ページごとに構築される。指定されるキーワードを含む静的ページの集合は、ステップ１５２１で決定される。関連付けられるＵＲＬは、静的ページおよび動的ページのための結合された結果リストを形成するために結果リストに追加される。それから、結果は、ステップ１５２２で、照会に対する関連性の順序で格付けされる（これを行うための標準的な技法がある）。それから、ＣＳＥは、ステップ１５２４で、ｈｔｍｌ結果ページを作成し、要求側ブラウザにそれを戻す。典型的には、この結果ページは、ユーザによって入力されるキーワードに基づいて、動的ページと静的ページの両方へのリンクを含むだろう。ＣＳＥのユーザが動的ページに対するリンクをクリックすると、彼らはＣＳＥによって構築されたＵＲＬに基づいてデータベース情報から形成される動的ページに直接移動する。
【００８４】
２．２．２  動的ページの索引付け
２．２．２．１  株式情報例
動的ページの索引付けは、株式仲買人からの多様な株式市場に上場されている企業に関する勧めを提供するために、図９Ａから図９Ｃに図示されるように動的ページを作成できる株式情報例に関して後述される。形式ページは図９Ａに図示され、特定の入力を含むことにより照会が入力された形式ページが図９Ｂに図示されている。それから、結果として生じる動的ページが作成され、図１０に図示されるように、ウェブサーバ２０６のデータベース１００２から抽出されたデータを表すエントリ９００が強調表示される図９Ｃに図示されるようなユーザのブラウザに送信される。図１０は、ページ１００４の入力フィールド１０１０に入力されるデータを要求とともに受信する形式処理プログラム１００８にｈｔｔｐ要求を戻すために、ユーザのブラウザ１００６に送信される形式ページ１００４を使用できるメッセージフローを示す。プログラム１００８は、ユーザのブラウザに戻すｈｔｔｐ応答を作成するために使用できるプログラム１００８に結果を戻すために、リレーショナルデータベース１００２に対するＳＱＬ照会を生成する。応答は、プログラム１００８によって作成される動的ページを定義するコードを含み、応答は、ユーザのブラウザ上での、図９Ｃに図示されるような、動的ページの表示を引き起こす。
【００８５】
さらに特定すると、図９Ａの形式ページのＵＲＬは、
ｈｔｔｐ：／／ｗｗｗ．ｓｔｏｃｋａｄｖｉｃｅ．ｃｏｍ／ｂｒｏｋｅｒ．ｈｔｍｌ
である。
【００８６】
一方の入力フィールドは株式コード用であり、他方の入力フィールドは仲買人の名前用である。株式コード用の形式入力の名前は「ｓｃｏｄｅ」であり、仲買人名の形式入力の名前は「ｂｎａｍｅ」である。
【００８７】
ｂｒｏｋｅｒ．ｈｔｍｌ上のｈｔｍｌ形式タグの例は、
＜ＦＯＲＭ  ＡＣＴＩＯＮ＝ｈｔｔｐ：／／ｗｗｗ．ｓｔｏｃｋａｄｖｉｃｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａ  ＭＥＴＨＯＤ＝“ＧＥＴ”＞Ｓｔｏｃｋ  ｃｏｄｅ  ｅｇ  ＡＯＬ  ＜ＩＮＰＵＴ  ＴＹＰＥ＝“ｔｅｘｔ”ＮＡＭＥ＝“ｓｃｏｄｅ”ＳＩＺＥ＝１０＞＜ｂｒ＞
Ｓｔｏｃｋ  ｂｒｏｋｅｒ＜ＩＮＰＵＴ  ＴＹＰＥ＝“ｔｅｘｔ”ＮＡＭＥ＝“ｂｎａｍｅ”ＳＩＺＥ＝１０＞＜ｂｒ＞
＜ＩＮＰＵＴ  ＴＹＰＥ＝“ｓｕｂｍｉｔ”ＶＡＬＵＥ＝“Ｓｕｂｍｉｔ”＞＜ｂｒ＞
となるだろう。
【００８８】
形式処理プログラムの例のＵＲＬは、
ｈｔｔｐ：／／ｗｗｗ．ｓｔｏｃｋａｖｉｃｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａ
である。この例では、情報は、Ｏｒａｃｌｅ（商標）データベース１００２に記憶される。
【００８９】
作成される動的ページは、仲買人の株式―買い、売り等の格付けを含む。これらの格付けを含む例の表は以下のとおりである。
0004873813.tif 000002
【００９０】
別の表は、ｓｔｏｃｋ＿ｉｎｆｏと呼ばれる。それは、ｓｔｏｃｋ＿ｃｏｄｅ単位で索引付けされる。それは２つのそれ以外の列を有し、ｅｘｃｈａｎｇｅ、つまり企業が上場されている株式証券取引所と、他方は、企業の名前を含むｓｔｏｃｋ＿ｎａｍｅである。
0004873813.tif 000003
【００９１】
第３の表、ｓｔｏｃｋ＿ｂｒｏｋｅｒｓは、列、ｎａｍｅ（一次キー）、ｐｈｏｎｅ＿ｎｏ、およびｅｍａｉｌを有する。
0004873813.tif 000004
【００９２】
プログラム１００８のｃｇｉ−ｓｃｒｉｐｔは、ユーザが‘ＹＨＯＯ’と‘ｊａｃｋｓｏｎ’をそれぞれの形式フィールドに入力してから、提出ボタンを押すと、以下のＳＱＬ照会を生成する。
ｓｅｌｅｃｔ  ｒａｔｉｎｇ，ｓｔｏｃｋ＿ｎａｍｅ，ｅｍａｉｌ
ｆｒｏｍ  ｓｔｏｃｋ＿ｉｎｆｏ，ｓｔｏｃｋ＿ｒａｔｉｎｇ，ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ
この場合、
ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ＝'ＡＯＬ'ａｎｄ
ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ．ｎａｍ＝'ｊａｃｋｓｏｎ'ａｎｄ
ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ＝ｓｔｏｃｋ＿ｒａｔｉｎｇ．ｓｔｏｃｋ＿ｃｏｄｅ  ａｎｄ
ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ．ｎａｍｅ＝ｓｔｏｃｋ＿ｒａｔｉｎｇ．ｎａｍｅ；
【００９３】
ｃｇｉ−ｓｃｒｉｐｔは、動的ページに、ある特定の仲買人からのある特定の株式の格付け、および株式の名前、および仲買人のｅｍａｉｌアドレスを表示する（図９Ｃを参照すること）。
【００９４】
２．２．２．２  サーバベースエージェント
本項でＳＢＡについて示される詳細の多くは、バックエンドデータソースがＳＱＬデータベースであるという仮定の元にある。いくつかの改変を含む基本的な技法は、ＳＱＬ以外の照会言語を使用するバックエンドデータベースから作成される動的ページの索引付けに、およびその他のバックエンドデータソースにも適用可能だろう。前述されたように、ＳＢＡは、スタンドアロンソフトウェアモジュールとして実現されてよいか、あるいはＨＴＴＰサーバ（ＨＳ）に含まれてよいか、あるいは何らかのほかのさらに大きなソフトウェアモジュールに含まれてよい。
【００９５】
多くの市販されているデータベースについて、データベースへの接続は、データベース（ＤＢ）１００８の上位装置として働く同じコンピュータからである必要はない。つまり、ＤＢは、ＨＴＴＰサーバディレクトリツリー（ＨＳＤＴ）を記憶するサーバ２０６に対する別のコンピュータ上にある場合があることを意味する。
【００９６】
ＳＢＡは、ＨＳＤＴと同じコンピュータ上に、あるいはＨＳＤＴの一部であるすべてのファイルの表示を可能にするコンピュータ上でインストールできる。これは、ＳＢＡの上位装置として働くコンピュータ、および共通のネットワークファイルシステムの一部であるＨＳＤＴの上位装置として働くコンピュータを介して実行できるだろう。またリモート機械上のＳＢＡが、別のコンピュータ上で上位装置として働かされるＨＳＤＴを表示するための他の考えられる方法もある。
【００９７】
図１６に関して、ＳＢＡが（ステップ１６０２で）インストールされると、それは（ステップ１６０４で）コンピュータ管理者によって手動でＨＳＤＴのロケーションを通知されてよいか、あるいはそれは（ステップ１６０６で）自動的にこのロケーションを演繹することができる。好ましい方法ではない後者のオプションは、ＳＢＡが、ネットワークファイルシステム全体、つまりＨＳＤＴの場合ローカルファイルシステムを探索することを必要とする。これを達成する１つの方法は、ｈｔｍｌファイルの位置を突き止めることによる。
【００９８】
ＳＢＡは、ウェブサイト（ＷＳ）のロケーション（つまり、ブラウザに対しサービスを提供できる実際のファイル）を突き止めることも必要とする。これは、ステップ１６０８でコンピュータ管理者によって手動で提供されてよいか、あるいはＳＢＡは、ステップ１６１０で自動的にこれを演繹することができる。これを達成する１つの方法とは、ＳＢＡが、ｈｔｍｌファイルを含むこのサブツリーを見つけるために、ＨＳＤＴを調べることである。
【００９９】
それから、ＳＢＡは、ステップ１６１２で、それが動的ページを作成するために使用できるかどうかを判断するためにＷＳ内の各ページを見る。ＳＢＡは、リスト、つまり動的ページを作成できるだろうそれらのページのｄｙｎ＿ｌｉｓｔを作成する。これを判断する１つの方法は、ページからｈｔｍｌの存在を特定することによる。私達の株式情報例では、ＳＢＡは、ファイル「ｂｒｏｋｅｒ．ｈｔｍｌ」を見て、それがその中に形式タグを有することを認識するだろう。それから、それはこのファイルをｄｙｎ＿ｌｉｓｔに追加するだろう。
【０１００】
それから、ＳＢＮは、ステップ１６１４でｄｙｎｄｂ＿ｌｉｓｔと呼ばれる新しいリストを作成する。Ｄｙｎｄｂ＿ｌｉｓｔは、データベースにアクセスすることを経由して動的ページを作成できるそれらのページのリストだけを含むため、リストｃｙｎｄｂ＿ｌｉｓｔは、通常、同じ番号またはｄｙｎ＿ｌｉｓｔより少ないアイテムを含むだろう。ｄｙｎ＿ｌｉｓｔ内のページについて、ＳＢＡは形式アクションファイル、ａｃｔ＿ｆｉｌｅと名前が付けられるファイルを見る。ａｃｔ＿ｆｉｌｅがバイナリである（ネイティブ機械コードまたは解釈されたバイトコードのなんらかの形、例えば、Ｊａｖａ仮想機械にコンパイルされる）場合には、ＳＢＡはその中から文字列のリストｓｔｒ＿ｌｉｓｔを抽出する。文字列は、文字、数字および句読点などの文字を表す値に相当するバイナリ内で見つけられるバイトのシーケンスである。したがって、ｓｔｒ＿ｌｉｓｔは、典型的には、読み取り可能なワードおよび名前または用語のリストとなるだろう。ａｃｔ＿ｆｉｌｅがバイナリではない場合には、文字列は容易に可視である。それから、ＳＢＡは、ＳＱＬ文である文字列を見つけるためにｓｔｒ＿ｌｉｓｔのメンバーを調べる。特に、ＳＢＡは、ＳＱＬ選択文を探すだろう。ＳＱＬ選択文は、データベースを照会するために使用される。そのａｃｔ＿ｆｉｌｅｓがＳＱＬ選択文を含むこれらのページは、動的ページを構築するためにデータベースにアクセスするものであると仮定されるだろう。これらのページは、ｄｙｄｎｄｂ＿ｌｉｓｔに記録され、それらのアクションファイルの名前はｄｂａｃｔ＿ｌｉｓｔに記憶されるだろう。株式情報例では、ａｃｔ＿ｆｉｌｅは、ｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａである。この形式処理プログラムがＳＱＬ選択文を含むので、ファイルｂｒｏｋｅｒ．ｈｔｍｌもｄｙｎｎｄｂ＿ｌｉｓｔ内にあるだろう。
【０１０１】
この時点で、ＳＢＡは、データベースにアクセスすることによってどのページおよびその関連付けられる形式処理プログラムが動的ページを作成するのかを判断した。ｄｙｎｂ＿ｌｉｓｔ内のページごとに、データベースの名前、そのユーザ名、そのパスワードおよびそのネットワークアドレスも特定されなければならない。ｄｙｎｄｂ＿ｌｉｓｔ内の各ページによってアクセスされるデータベース種類は、ステップ１６１６で、ウェブサイトのシステム管理者によって手作業で指定されてよい。代わりに、ＳＢＡは、ステップ１６１８から１６２２でこれらのパラメータを自動的に演繹してよい。
【０１０２】
データベース種類およびそれ以外のデータベースアクセスパラメータは、ステップ１６１８で、ｃｇｉスクリプトに可視にされる環境変数の集合から、およびスクリプト自体のコンテンツから証拠を収集することにより自動的に演繹されてよい。環境変数は、実行中のプログラムがその値をチェックできるプログラムの外側から名前が指定される値である。ｃｇｉスクリプトに可視である環境編集を求める少なくとも２つの方法がある。非相互的な（ｎｏｎ−ｃｒｏｓｓ）ＨＳアプローチは、ＨＳのそれぞれの特定の種類を決定することであり、ＨＳがそのｃｇｉスクリプトの環境にインポートする環境変数のリストはＨＳＤＴ内にある。例えば、Ａｐａｃｈｅ  ＨＴＴＰサーバを使用すると、これはそのＨＴＴＰサーバディレクトリツリー内のｃｏｎｆ／ｈｔｔｐｄ．ｃｏｎｆファイル内で発生する。ｃｇｉスクリプトにとって可視の環境変数を求めるためのその他の相互サーバ方法は、ＳＢＡが、ＷＳの中に一時的に、環境変数を単に一覧表示するだけの簡略なスクリプトをインストールすることである。それから、ＳＢＡは、すべての環境変数の値および名前を示すこのインストールされたスクリプトに対してＨＴＴＰ  ＧＥＴ要求を実行する。
【０１０３】
いったんＨＳのｃｇｉスクリプトに可視であるすべての環境変数が既知となると、ステップ１６２０で、ＳＢＡは、リストｋｎｏｗｎｄｂ＿ｌｉｓｔに記憶されている、それが知っているデータベース種類の既知の標準的な環境変数がないか、それらを調べる。例えば、Ｏｒａｃｌｅデータベースが使用されている場合には、ＯＲＡＣＬＥ＿ＢＡＳＥ、ＯＲＡＣＬＥ＿ＨＯＭＥおよびＯＲＡＣＬＥ＿ＳＩＤなどの環境変数が存在するだろう。株式情報例では、これらはｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａがオラクルデータベースにアクセスできるために検出されるだろう環境変数である。このチェックは、ＳＢＡのｋｎｏｗｎｄｂ＿ｌｉｓｔ内のすべてのデータベースについて行われるだろう。このリストは、大多数のウェブサイトがカバーされてよいことを確実にするために、多くの異なる種類のデータベースによって使用される環境変数を含んでよい。
【０１０４】
ＳＢＡは、ステップ１６２２で、どのベンダのデータベースがｄｙｎｄｂ＿ｌｉｓｔの各エントリによってアクセスされているのかを演繹する。通常、１つのデータベースだけがＷＳでｃｇｉ−スクリプトに可視であるだろうが、必ずしもではない。ただ１つのデータベースがある場合には、ｄｙｎｄｂ＿ｌｉｓｔ内のそれぞれのページがそれにアクセスすることが既知である。複数のデータベースがある場合には、ＳＢＡは、ｄｙｎｄｂ＿ｌｉｓｔからのどのページがどのデータベースにアクセスするのかを決定する。これを決定するために、ＳＢＡは、どのようにして一定のｃｇｉスクリプトが特定のデータベースに接続するのかについての発見的教授法を使用する。例えば、ｃｇｉスクリプトがコンパイルされたＣであり、それがオラクルデータベースにアクセスする場合には、ｃｇｉスクリプトから抽出される文字列の１つは、ライブラリ名「ｓｑｌｃａ」を含むだろう。いったんｃｇｉスクリプトからデータベースに対する一致が行われると、ＳＢＡはｅ−タベースについてデータベース名、ユーザ名およびパスワードを、およびそれが必要とされる場合はそのネットワークアドレスを特定するために進むことができる。
【０１０５】
ＳＢＡは、これらが必要とされる場合、データベースの名前およびデータベースのユーザ名とパスワードを決定する。ステップ１６２４と１６２８では、これは、これらの詳細をサイト管理者が入力することによって手動で実行されてよい。代わりに、ＳＢＡは、ステップ１６２６と１６３０でこれらを自動的に決定することができる。データベース名は、通常、アクセスされているデータベースのための環境変数内に含まれるか、あるいはｃｇｉスクリプト自体に、またはなんらかのほかのシステム情報ソース内で見つけられてよい。例えば、オラクルを使用すると、ＯＲＡＣＬＥ＿ＳＩＤ環境変数が設定されると、それはデータベース名を含むだろう。設定されない場合、それはユーザ名文字列の最後にあるだろう。ＳＢＡは、データベース名を探すために、データベース型とｃｇｉスクリプト型の組み合わせごとに発見的教授法を使用する。株式情報例について、データベース名は、ｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａがオラクルデータベースにアクセスするため、ＯＲＡＣＬＥ＿ＳＩＤで見つけられるだろう。
【０１０６】
ＳＢＡは、ステップ１６３０で、データベースのユーザ名およびパスワードを探すために類似する発見的教授法を使用する。これらも、スクリプト自体の、あるいは何らかのシステム情報ソースの環境変数であるだろう。ＳＢＡは、データベース型およびｃｇｉスクリプト型の組み合わせごとに発見的教授法を使用する。株式情報例については、ユーザ名とパスワードは、形式処理プログラムｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａのテキストに含まれ、ＳＢＡはプログラム内のどの文字列が十中八九ユーザ名とパスワードであるのかを特定し、それは、それらが正しいことを確認するためにそれらを試すだろう。
【０１０７】
ここでは、データベース型、データベース名、ユーザ名およびパスワードは、ＳＡがデータベースに接続を行うことができるｃｇｉスクリプトについて機知である。ＳＢＡがプログラミング言語Ｊａｖａで実現される場合、これは便宜的にＪＤＢＣを用いて実行できるだろう。ＪＤＢＣは、多くの異なる種類のデータベースに一様なＳＱＬインタフェースを提供する事前作成されたコード（ＡＰＩ）のライブラリである。
【０１０８】
株式情報例を考えると、株式情報を含むデータベースはユーザ名「ａｄｍｉｎ」とパスワード「ｂｏｇｇｌｅ」が指定されるｓｔｏｃｋ＿＿ｄｂと呼ばれるオラクルデータベースである。また、データベース用のリモートデータベース管理システム（ＲＤＢＭＳ）は、ポート１５００で傾聴するホストサーバａｃｈｉｌｌｅｓ．ｓｔｏｃｋａｖｉｃｃ．ｃｏｍで実行中である。このケースでは、このデータベースに接続するための例Ｊａｖａコードは、以下のとおりだろう。
Ｃｌａｓｓ．ｆｏｒＮａｍｅ（“ｏｒａｃｌｅ．ｊｄｂｃ．ｄｒｉｖｅｒ．ＯｒａｃｌｅＤｒｉｖｅｒ”）．ｎｅｗＩｎｓｔａｎｃｅ（）
Ｓｔｒｉｎｇ  ｕｒｌ＝“ｊｄｂｃ：ｏｒａｃｌｅ：ｔｈｉｎ：＠Ａｃｈｉｌｌｅｓ．ｓｔｏｃｋａｄａｖｉｃｅ．ｃｏｍ：１５００：ｓｔｏｃｋ＿ｄｂ”；
Ｃｏｎｎｅｃｔｉｏｎ  ｃｏｎ＝ＤｒｉｖｅｒＭａｎａｇｅｒ．ｇｅｔＣｏｎｎｅｃｔｉｏｎ（ｕｒｌ，“ａｄｍｉｎ”，“ｂｏｇｇｌｅ”）；
【０１０９】
ここで、ＳＢＡは、形式入力フィールドと、それが対応するデータベース列の関係性を決定する。これを決定するための数多くの技法がある。１つのアプローチでは、ＳＢＡは、ステップ１６３２で、形式入力とＳＱＬ照会の関係性を、形式処理プログラムを調べることによって演繹する。
【０１１０】
ただ１つの形式入力フィールドがある場合、形式入力フィールドとデータベース列の関係を見つけ出すことは自明である。ＳＱＬ文の中の変数のロケーションは、１つの形式入力フィールドと一致される。以下のとおりに、単純な入力フィールドのある単純な例を考えてみる。
【０１１１】
形式タブテキストは、
＜ＦＯＲＭ  ＡＣＴＩＯＮ＝“ｈｔｔｐ：／／ｗｗｗ．ｓｔｏｃｋａｖｉｃｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｓｔｏｃｋｓ”
ＭＥＴＨＯＤ＝“ＧＥＴ”＞
Ｅｎｔｅｒ  ｃｏｄｅ：＜ＩＮＰＵＴ  ＴＹＰＥ＝“ｔｅｘｔ”ＮＡＭＥ＝“ｃｏｄｅ”ＳＩＺＥ＝１０＞＜ｂｒ＞
＜ＩＮＰＵＴ  ＴＹＰＥ＝“ｓｕｂｍｉｔ”ＶＡＬＵＥ＝“Ｇｅｔ  ｑｕｏｔｅ！”＞＜ｂｒ＞
である。
【０１１２】
照会は、
ｓｅｌｅｃｔ  ｓｔｏｃｋ＿ｎａｍｅ，ｃｌｏｓｅ
ｆｏｒｍ  ｓｔｏｃｋ＿ｉｎｆｏ，ｓｔｏｃｋ＿ｐｒｉｃｅｓ
であり、この場合、
ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｓｏｃｋ＿ｃｏｄｅ＝：ｃｏｄｅ＿ｔｈａｔ＿ｗａｓ＿ｉｎｐｕｔおよび
ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ＝ｓｔｏｃｋ＿ｐｒｉｃｅｓ．ｓｔｏｃｋ＿ｃｏｄｅ
である。
【０１１３】
これは、ｃｇｉスクリプトがコンパイルされたＣ−：ｃｏｄｅ＿ｔｈａｔ＿ｗａｓ＿ｉｎｐｕｔであり、プログラム変数であるように考えられ？、これは「ｃｏｄｅ」と呼ばれる入力フィールドに一致するだろう。これは、この入力フィー独活がデータベース列ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅに一致することを示す。このデータベース列は、形式に対するすべての考えられる入力の集合を含む。
【０１１４】
複数の入力フィールドがある場合、入力フィールドをデータベース列に一致させることはさらに困難である。このマッチングは、（形式入力フィールドごとに値を指定するプロセスで）ｃｇｉスクリプトに対してＳＢＡが要求をこない、結果として生じるデータベースに対する入力を観察することによって達成されてよい。この観察は、数多くの異なる方法で実施されてよい。１つの方法は、ステップ１６３４で示されるように、ＳＢＡが、開放データベース接続性（ＯＤＢＣ）捜査プログラム（ｓｎｉｆｆｅｒ）または何らかのその他の方法をインストールすることである。これは、ある特定のデータベースに送信されるログ照会を検出し、ログするだろう。さらに幅広い範囲のオペレーティングシステムまたはｃｇｉスクリプト型について作用する他の方法がある。これらの代替策の１つであるステップ１６３６は、（コンパイルされていない形式の場合）ＳＢＡが形式処理スクリプトを改変する、あるいは、それが、それが実施するＳＱＬ照会をＳＢＡに知らせるように（コンパイルされている場合には）ラッパーを提供することを含む。
【０１１５】
ＳＢＡがＳＱＬ照会を監視した後（ステップ１６３４または１６３６）、それは２つの方法の内の一方によって、形式入力とデータベース列の関係を決定する。ステップ１６３８では、ＳＢＡは、ページごとに形式インタフェースに対する照会を行い、結果として生じるＳＱＬ照会を観察し、どの形式入力が、どのデータベース列のどのエントリに一致するのかを注記する。代わりに、ステップ１６４０では、ＳＢＡは、形式入力および人間の探索者から生じるＳＱＬ照会を観察し、注記する。
【０１１６】
次に、ＳＢＡが、動的ページを索引付けするために使用する方法およびこれらのケースのそれぞれでＣＩに送信される必要がある情報の数多くの代替策がある。使用される方法は、ステップ１６４２でサイト管理者によって設定されてよい。
【０１１７】
３つの決定点、つまりステップ１６４４、１６４６および１６５６で、どの索引付け方法が使用されるべきかに関する決定が示される。４つの主要な合うロー値が概略された。ケース１と２について、２つの方法が与えられた。１．１と２．１に示される方法は、通常、好ましい方法である。情報が複数のデータベースに記憶され、相対的に独立している一定のデータベースの場合、一定の照会（例えば、接合）は、組の展開を生じさせるだろう。１．２と２．２などのそれ以外の方法を使用すると、これらのケースでは、ＳＢＡからＣＩへ伝送されるデータの量は最小限に抑えられるだろう。この交換は、データベースおよびＳＱＬ照会を分析する時点で、ＳＢＡによって自動的に決定されてよい。
【０１１８】
２．２．２．３．１  索引付け方法の分類
索引付け方法を考えるとき、さまざまなデータベースに、さまざまな状況で使用されてよい数多くの代替策がある。いくつかのデータベースにとって、インタフェース（例えば、形式、Ｊａｖａ等）を使用して探索してよい用語に索引付けを制限することが適切である―ケース１と３。それ以外のデータベースにとっては、データベースに記憶されるすべての情報で索引付け、このようにして探索者によって指定される情報だけを使用して通常検索できないだろうページの検索を可能にすることが適切である場合がある―ケース２と４。いくつかのケースでは、データベースを分析し、データベース内のすべての入力および／または出力を索引付けすること（ケース１と２）が適切である場合があるが、それ以外のケースでは、ユーザによって実際に検索されたそれらのページに索引付けを制限することが必要である場合がある（ケース３と４）。
【０１１９】
動的ページを索引付けすることに対する２つの基本的なアプローチ、つまり、作成されたあるいは作成できる実際のページを索引付けること（ケース２．３および４．２）、またはそれがデータベースに記憶される方法に類似する形式で情報を送信すること（ケース１．２および２．２）がある。第３アプローチは、この後者の代替策の変形、つまりデータベースから抽出される情報の組を送信することである（ケース１．１、２．１、３．１および４．１）。独立した表の接合のまれなケースでは、ケース１．２または２．２は、前述されたようにさらに効率的であり、ＳＢＡによって自動的に選択されてよいが、この「組方法」は、非常に一般的に適用可能であり、データベースに対する直接的なアクセスがないときにも使用できる。
【０１２０】
さまざまな方法は、以下の通りに要約される。
ケース１：考えられるすべての動的ページの入力を索引付けする。
ケース１．１：ＳＢＡは、すべての考えられる入力組を決定し、送信する（ステップ１６５８）。
ケース１．２：ＳＢＡは、動的ページ（例えば、ＳＱＬ「ｗｈｅｒｅ」節（ステップ１６６０））を作成するために使用されるデータベースからデータを抽出するために、形式処理プログラムによって使用されるすべてのデータベースを送信する。
ケース２：考えられるすべての動的ページの完全テキストを索引付けする。
ケース２．１：ＳＢＡは、静的テキストおよび考えられるすべての入力／出力組を決定し、送信する（ステップ１６６２）。
ケース２．２：ＳＢＡは、静的テキストおよび
（ｉ）動的ページを作成するために使用されるデータベースからデータを抽出するために形式処理プログラムによって使用され、
（ｉｉ）出力列である（ステップ１６６４）
すべてのデータベース列を送信する。
ケース２．３：ＳＢＡは、それらが静的ページであるかのように、考えられるすべての動的ページの索引を作成する。
ケース３：人間の探索者によって塩策されたページの入力を索引付けする（ステップ１６４８）。
ケース３．１：ＳＢＡは、人間の探索者によって入力されるユーザ入力を観察し、入力組を送信する。
ケース４：人間の探索者によって検索されたページの完全テキストを索引付けする（ステップ１６５０）。
ケース４．１：ＳＢＡは、人間の探索者によって入力されるユーザ入力および結果として生じる出力を観察し、これらを入力／出力組として送信する。
ケース４．２：ＳＢＡは、それらが静的ページであるかのように、検索された動的ページに索引付ける。
【０１２１】
ケース１は、ケース２の部分集合である。ケース１は、ステップ１６５８と１６６０に示されるように、形式入力だけに対する探索を可能にするデータを送信することを必要とする。ケース２は、完全テキストでの探索を可能にするデータを送信することを必要とする。したがって、ケース１は、出力が索引付けされないことを除き、ケース２と同じである。
【０１２２】
ケース２は、ケース１に非常に類似している。しかしながら、ＳＢＡは、形式処理プログラム内のＳＱＬ照会によって選択される列も送信する。ＳＢＡは、句の探索を可能とするために、このテキストのワード位置、および動的ページに表示されるデータベースエントリのワード位置も含む、静的テキストも送信する。ステップ１６６２と１６６４は、ケース２に対応する動的ページ索引付けのオプションである。
【０１２３】
ケース２．１
このシナリオはステップ１６６２に対応する。考えられるすべてのページが、（ステップ１６４４で）索引付けられるために選ばれ、それらの完全テキストは索引付けられなければならない（ステップ１６５６）。すべての入力と出力の集合が、ＳＢＡが実行する照会によって一覧表示されることは、私達の株式情報例で理解できる。つまり、サーチエンジンのユーザは、形式入力または動的ページに表示されるワードに対して探索できる。後者の場合、対応する入力とは、同じ組に含まれるものである。
【０１２４】
例では、ＳＢＡによって実行されなければならない照会は、
ｓｅｌｅｃｔ  ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ，ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ．ｎａｍｅ，ｒａｔｉｎｇ，ｓｔｏｃｋ＿ｎａｍｅ，ｅｍａｉｌ  ｆｒｏｍ  ｓｔｏｃｋ＿ｉｎｆｏ，ｓｔｏｃｋ＿ｒａｔｉｎｇ，ｓｔｏｃｋ＿ｂｒｏｋｅｒｓであり、
この場合、
ｓｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ＝ｓｔｏｃｋ．ｒａｔｉｎｇ．ｓｔｏｃｋ＿ｃｏｄｅおよび
ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ．ｎａｍｅ＝ｓｔｏｃｋ＿ｒａｔｉｎｇ．ｎａｍｅであり、
以下の入力／出力組を示す。
0004873813.tif 000005
【０１２５】
形式処理プログラムによって動的ページに載せられる任意の静的テキストは、ステップ１６６６で注記される。これらは、通常、同じとなり、このようにして、動的ページ作成店から動的ページの完全な集合について一度送信されてよい。探索者は、これらのワードに関して実行されてもよい。静的テキスト、前記データベースコンテンツ（つまり、入力／出力組）および形式処理プログラムのＵＲＬなどの情報は、ステップ１６６８でＣＩに送信される。
【０１２６】
いくつかのサイトでは、ページが要求されるときにデータベース検索を回避することによってアクセスを加速するためのデータベースから事前に生成された静的ページがあるだろう。これらの静的ページは、別個に索引付けされてはならないが、むしろＳＢＡは、動的ページについてと同じ方法で組方法を使用してそれらを索引付けする。
【０１２７】
これらのページの生成は、ＳＢＡ索引付けケース２．３に類似している。相違点は、ケース２．３は動的ページを作成し、索引付けするが、それらを記憶しないが、前記サイトはページを作成し、それらを高速アクセス用の静的ページとして記憶するという点である。したがって、これらの作成された静的ページは、それ以外の静的ページによって索引付けることができるだろうが、組の表現は、ＳＢＡがこれらのすべての作成されたページを表すための最もコンパクトな方法であり、これらのページを作成するスクリプトは、索引付け時にＳＢＡによって使用できる。したがって、これらの静的ページは、静的リンクが、動的リンクよりむしろ探索結果ページで作成されるだろうという点を除き、動的ページ組方法（つまり、ケース２．１）によって処理されなければならない。作成された静的ページが、動的ページを含み冗長である（つまり、それらが頻繁にアクセスされる動的ページのキャッシュに入れられたバージョンである）場合、ＵＲＬの動的バージョンよりむしろ、ＵＲＬの静的バージョンが中央検索エンジンによって戻される。ＳＢＡは、形式入力から静的ＵＲＬを構築するＪａｖａｓｃｒｉｐｔまたは類似物を見つける、および／またはステップ１６３２で動的ページのなんらかの部分集合の作成スクリプトを発見してよい。
【０１２８】
ケース２．２
このオプションは、ステップ１６６４に相当する。このケースでは、ＣＳＥは、ユーザがサーチエンジン照会を行う時点でＳＱＬ（類似）照会を実施する。これは、入力のある特定の組み合わせによって指定される動的ページが、有効なコンテンツを含む動的ページを生じさせることを検証するために実行される。
【０１２９】
この方法では、ＳＢＡは、
（ｉ）動的ページを作成するために使用されるデータベースからデータを抽出するために形式処理プログラムによって使用され、
（ｉｉ）出力列である、
すべてのデータベース列を送信する。
【０１３０】
ステップ１６６８では、データベースの列、静的ワードおよび形式処理プログラムのＵＲＬなどの情報が、ＣＩに送信される。
【０１３１】
ケース３．１
このケースは、ステップ１６４８と１６５２に相当する。このアプローチは、実質的には異なる。それは、動的ページの構築で使用できるデータの考えられるすべての部分を抽出するためにデータベースを照会することを必要としない。むしろ、ＳＢＡは、ステップ１６４８で形式インタフェースに対して行われる照会を注記するだけである。効率性の理由から、ＳＢＡは、それが数多くのそれらを観察した後に観察された入力組を送信するにすぎない。これはステップ１６５２で実行される。
【０１３２】
このアプローチの優位点とは、ＣＩで索引付けされている情報が、その有効性について濾過されている―それは、それが使用されている場合にだけ索引付けされるだろうという点である。
【０１３３】
１つのアプローチは、ＳＢＡがＯＤＢＣ捜査プログラムをインストールする場合である（初期のステップは、おそらくそのインストールを必要としていた）。このＯＤＢＣ捜査プログラムは、形式処理プログラムからバックエンドデータベースの中に入る入力を監視する。初期に形式処理プログラムを検査すると、ＳＢＡは、ＳＱＬ照会内のワードを見て、その結果それはそれを再び認識できるだろう。ＳＢＡは、形式入力フィールドからＳＱＬ照会の可変スロットへの写像も解決するだろう。つまり、ＳＢＡが実行時にＳＱＬ照会を見ると、それは、形式入力にどの値が入力されたのかを認識できるだろう。
【０１３４】
加えて、ＳＢＡは、動的ページに表示される静的テキストを抽出する。ＳＢＡは、句の探査を可能とするために、これらのワードのワード位置、およびデータベースから抽出されるワードが挿入される位置も送信してよい。
【０１３５】
それから、ＳＢＡは、照会自体を実行する、あるいはそれ以外の何らかの方法によって、照会が空ではない結果集合を戻すことを確かめる必要がある。結果集合が空ではなかった場合、ＳＢＡはこの入力組をＣＩに報告できる。
【０１３６】
ＳＢＡは、照会のリストを保つにすぎず、ＣＩに、スレッショルドを上回る一番上のいくつかを送信するにすぎない。代わりに、ＳＢＡは、その一致が一定の事前設定されたスレッショルドを渡した後に、ＣＩに対する照会を報告してよい。
【０１３７】
ケース４．１
このケースは、ステップ１６５０と１６５４で実現される。このケースは、ケース３．１に非常に類似している。唯一の相違点は、ＳＢＡが、形式インタフェースに対するユーザ照会を見ると、ＳＱＬ照会によって戻される値も注記するという点である。これは、照会自体を繰り返す、またはそれ以外の何らかの方法によって実行されてよい。
【０１３８】
ＳＢＡは、ここで、ＣＩに全体的な入力／出力組を送信できる。再び、動的ページは、それらの実用性に従ってＣＩで索引付けされるだろう。
【０１３９】
加えて、ＳＢＡは、動的ページに表示される静的テキストを抽出する。ＳＢＡは、句の探索を可能とするために、これらのワードのワード位置およびデータベースから抽出されるワードが挿入されるワード位置も送信する。
【０１４０】
ケース２．３および４．２
これらのケースでは、ＳＢＡは、考えられるすべての動的ページのインデックスを、それらが静的ページであるかのように作成する。したがって、動的ページを索引付けするために説明される詳細な方法は、これらのケースでは当てはまらない。
【０１４１】
２．２．２．４  ＣＩ記憶要件
ケース１およびケース２は、概して、ケース３および４より、さらに多くの記憶域をＣＩで必要とするだろう。これは、最初の２つのケースが、サイトの考えられるすべての動的ページを索引付けしようと試みるためである。第２の２つのケースは、サイトで最も一般的な動的ページだけを索引付けしようと試みる。
【０１４２】
２．２．２．５  データベーストリガ
ステップ１６６８は、ＳＢＡのインストール後に直接的に実行される索引付けの最後にマークをつける。ステップ１６７０以降に、データベースに対する変更を送信する問題が対処される。
【０１４３】
任意のサーチエンジンインデックスにまつわる重要な問題は、その中の情報の現在性を維持することである。バックエンドデータベース内での情報の大規模な記憶を考慮すると、中央サーチエンジンが最新であることは重要である。
【０１４４】
これを達成するための１つの方法は、データベーストリガを使用することによる。ＳＢＡは、動的ページの索引付け情報に影響を及ぼす列が変化するときに、それと通信するデータベーストリガをインストールしてよい。
【０１４５】
典型的なデータベースは、データベース表あたり１つの特定のタイプのトリガだけを可能にする。このため、ステップ１６７０で、ＳＢＡが、その表を利用するあらゆる動的ページ作成点に関連する変更についてＳＢＡに通知する表ごとの単一トリガを構築することが便利である。ステップ１６７２では、ＳＢＡは、ｄｙｎｄｂ＿ｌｉｓｔ内のエントリによって使用されるすべてのデータベースで構築されたトリガをインストールする。
【０１４６】
以下は、株式情報例でのｓｔｏｃｋ＿ｉｎｆｏデータベース表にインストールされる可能性のある例のトリガである。これは、完全テキスト索引付けが使用されていた場合（つまり、ケース２と４）に使用されるトリガだろう。入力だけが索引付けされている場合には、ｓｔｏｃｋ＿ｃｏｄｅ列だけがチェックされる必要があるだろう。また、株式情報例のその他のデータベース表でのトリガに対するニーズもある。
ＣＲＥＡＴＥ  ｏｒ  ＲＥＰＬＡＣＥ  ＴＲＩＧＧＥＲ  ＳＥＮＤＥＲ（）
ＡＦＴＥＲ  ＩＮＳＥＲＴ  ｏｒ  ＵＰＤＡＴＥ  ＯＦ  ｓｔｏｃｋ＿ｃｏｄｅ，  ｓｔｏｃｋ＿ｎａｍｅ
ＯＮ  ｓｔｏｃｋ＿ｉｎｆｏ
ＦＯＲ  ＥＡＣＨ  ＲＯＷ
ＤＥＣＬＡＲＥ
Ｍｓｇ      ｖａｒｃｈａｒ（３０）；
ＰｉｐｅＮａｍｅ    ｖａｒｃｈａｒａ（３０）；
Ｌａｓｔｓｔａｔｕｓ  ｉｎｔｅｇｅｒ；
ＴｒａｃｅＭｏｄｅ    ｖａｒｃｈａｒ（３０）；
ＢＥＧＩＮ
ＰｉｐｅＮａｍｅ：＝‘Ｓｌａｖｋｏ’
Ｌａｓｔｓｔａｔｕｓ  ：＝０；
Ｉｆ（ｎｅｗ．ｓｔｏｃｋ＿ｃｏｄｅ  ｉｓ  ｎｏｔ  ｎｕｌｌ）ｔｈｅｎ
Ｍｓｇ：＝Ｍｓｇ｜｜‘：ｓｔｓｏｃｋ＿ｉｎｆｏ：’｜｜‘ｓｔｏｃｋ＿ｃｏｄｅ：’｜｜：ｎｅｗ．ｓｔｏｃｋ＿ｃｏｄｅ；
ｅｎｄ  ｉｆ；
ｉｆ（：ｎｅｗ．ｓｕｒｎａｍｅ  ｉｓ  ｎｏｔ  ｎｕｌｌ）ｔｈｅｎ
Ｍｓｇ：＝Ｍｓｇ｜｜‘ｓｔｏｃｋ＿ｉｎｆｏ：’｜｜‘ｓｔｏｃｋ＿ｎａｍｅ：’｜｜：ｎｅｗ．ｓｕｒｎａｍｅ；
ｅｎｄ  ｉｆ；
ＤＢＭＳ＿ＰＩＰＥ．ｐａｃｋ＿ｍｅｓｓａｇｅ（Ｍｓｇ）；
ＬａｓｔＳｔａｔｕｓ：＝ＤＢＭＳ＿ＰＩＰＥ．ｓｅｎｄ＿ｍｅｓｓａｇｅ（ＰｉｐｅＮａｍｅ）；
ＤＢＭＳ＿ＯＵＰＵＴ．ｐｕｔ＿ｌｉｎｅ（‘ｍｅｓｓａｇｅ  ｓｅｎｔ’）
ＥＮＤ；
【０１４７】
このトリガは、データベースパイプを使用することによって、ＳＢＡに関連するデータベースに対する変更を、それらが発生したときに通知するだろう。ＳＢＡは、ステップ１６７８で変更について聞くと、それはＣＩに知らせる。それは、即座にこれを行うか、あるいは更新のバッチが蓄積するまで待機することができる。
【０１４８】
索引付け情報がデータベース列として送信されている場合、これは自明である。行が挿入されると、ＳＢＡはこの新しい行をＣＩに送信する。ＣＩはそれを順方向インデックスエントリに追加し、そこからワードを反転インデックスに入れる。行が削除された場合、それは、どの行番号かを特定する。ＳＢＡはＣＩに告げ、それは順方向インデックスから行を削除する。それは反転インデックスを調べ、古いワードも削除する。行が更新されている場合には、行番号は既知である。ＣＩはこの行を取り、値を適切に変更する。あらゆる新しいワードは反転インデックスに追加される。削除されたワードは、その反転インデックスエントリから取り除かれる。
【０１４９】
索引付け情報が組みとして送信されている場合、データベース行に変更が加えられた後に、ＳＢＡは、この変更によって影響を受ける組を選択する照会を実施できる。例えば、「ｊａｃｋｓｏｎ（ジャクソン）」と呼ばれる仲買人が名前を「ｓｔｅｖｅｎｓ（スチーブンス）」に変更する場合、例について変更された組を検出するための探索は、以下
ｓｅｌｅｃｔ  ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ，ｒａｔｉｎｇ，ｓｔｏｃｋ＿ｎａｍｅ，ｅｍａｉｌ
ｆｒｏｍ  ｓｔｏｃｋ＿ｉｎｆｏ，ｓｔｏｃｋ＿ｒａｔｉｎｇ，ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ
ｗｈｅｒｅ
ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ．ｎａｍｅ＝‘ｓｔｅｖｅｎｓ’  ａｎｄ
ｓｔｏｃｋ＿ｉｎｆｏ．ｓｔｏｃｋ＿ｃｏｄｅ＝ｓｔｏｃｋ＿ｒａｔｉｎｇ．ｓｔｏｃｋ＿ｃｏｄｅ  ａｎｄ
ｓｔｏｃｋ＿ｂｒｏｋｅｒｓ．ｎａｍｅ＝ｓｔｏｃｋ＿ｒａｔｉｎｇ．ｎａｍｅとなり、以下の結果を示す。
0004873813.tif 000006
【０１５０】
ＳＢＡは、変更される特定のデータベース列にアクセスするすべての形式処理プログラムについて、影響を受けた組を計算する。ＣＩは、すべての古い組の位置を突き止め、それらを削除するか、更新する。
【０１５１】
２．２．２．６  ＣＩ２１４の構造およびＣＳＥ２１６の動作
ＣＩの基本的な構造は、順方向インデックスおよび逆転インデックスを含む。静的ページについては、情報は、既存のサーチエンジンによって使用されるような確立された技法を使用して、これらのインデックスに記憶される。静的ページの順方向インデックスエントリ１７０２の例および逆転インデックスエントリ１７０４は、辞典の例のエントリ１７０６とともに（表記「ｆｉｅｌｄ：ｘ」は、フィールドのｘビットを示す）図１７に図示されている。ヒットのフォーマットは１６ビットを備え、１２ビットは文書中のワードまたは用語の位置用であり、４ビットはテキスト大文字使用のためのその他の情報用である。ケース２．１と４．１でのように、組の記憶を含む、ＣＩによって動的ページ作成点のための順方向インデックスエントリ１８０２のために使用される構造は、図１８に図示されており、反転インデックスエントリ１８０４はケース２．１と４．１用であり、辞典エントリ１８０６は逆転インデックスとともに使用される。このケースでは、ヒットのフォーマットは、１６ビットを使用して記憶されてよい組番号にすぎない。
【０１５２】
図１８は、動的ページを索引付けするための順方向インデックスエントリおよび逆転インデックスエントリを使用するＣＩ構造の例である。順方向インデックスは、動的ページ作成点全体についての情報のブロックを含む。これらのブロックのそれぞれは、番号（ｄｙｎＩＤ）で索引付けられる。これらのブロックの中で、ＳＢＡによって送信される情報の組または列は、前述されたように記憶される。
【０１５３】
列または組に加えて、ＳＢＡによって送信されただろう動的ページ作成に関係する情報の数多くのそれ以外の部分がある。これらは、形式ページのＵＲＬ（図１８のｆＵＲＬ）、形式処理プログラムのＵＲＬ（図１８のｆｌｉｐＵＲＬ）、形式のメソッド（ＧＥＴまたはＰＯＳＴ）（図１８の方法）、形式入力フィールドの数（図１８のｎｆｉｅｌｄｓ）、それらの名前（図１８のｆｉｅｌｄ１  ｆｉｅｌｄ２）、およびそれらが相当するデータベース列を含む。形式ページのタイトル（図１８のタイトル）、形式ページからの初期テキスト、および動的ページで発生する静的なワードのリストなどのメタ情報もあるだろう。
【０１５４】
ケース１．２またはケース２．２について、形式処理プログラムによって使用されるＳＱＬ照会は、順方向インデックスエントリにも記憶されるだろう。また、組が次々に記憶される代わりに、ＳＱＬ照会内で言及されるデータベース列が記憶されるだろう。順方向インデックスにデータベース列を記憶することの代替策として、それらは、標準データベースに記憶できる。これが、ＳＱＬ照会のさらに容易な実行を可能にするだろう。
【０１５５】
逆転インデックスは、ｗｏｒｄＩＤで索引付けされる特定のワードに関する情報のブロックを含む。これらの情報のブロックは、各ｄｙｎＩＤの後にワードの発生のリスト、その動的ページ作成点の「ヒット」が続くｄｙｎＩＤのリストから成り立つだろう。ｄｙｎＩＤは、動的ページ作成点のＩＤ番号を指す。ヒットの実際の性質は、動的ページ作成点のために使用されてきた索引付け方法に依存する。ｄｙｎＩＤは、句の探索を可能にするために、入力と出力を、動的ページ上での静的ワード位置に連結する情報も指す。
【０１５６】
２．２．２．７  ヒットの記述
ケース１．１、２．１、３．１および４．１の逆転インデックスにおけるヒットは、ワードが発生する組の数にすぎない。組番号は、図１８に図示されるように、順方向インデックス内のそのｄｙｎＩＤ用の組のリスト内での組の位置を指す。
【０１５７】
ケース１．２および２．２の場合、逆転インデックス内のヒットは、ワードが順方向インデックスで発生する列および行を指す。
【０１５８】
ケース２．３または４．２でのような静的ページ、つまり動的ページ上の静的テキストのヒットは、図１７に図示されるように、ページ上のそのワード位置に、テキスト属性などのそれ以外の情報を加えたものにすぎない。
【０１５９】
２．２．２．８  株式情報例のＣＳＥとＣＩ間の対話
ケース２．１または４．１について株式情報例でＣＩに送信されるデータは、以下の組を有している。
0004873813.tif 000007
【０１６０】
すべての組は、それらが順方向リンク内にあるように記憶されるだろう。ＣＳＥは、組の中の列のどれが形式入力に相当するのかを注記する―つまり、株式情報例のケースでは最初の２つ。
【０１６１】
ユーザは、「ｊａｃｋｓｏｎ」ＡＮＤ（論理積）「Ｙａｈｏｏ」に対する探索を実行できる（この場合、ＡＮＤはブール演算子である）。ＣＳＥは、その逆転インデックスエントリから、これらのワードの少なくとも１つが発生する組を認識する。事前結果リストは、探索ワードの１つに一致するあらゆる組を有するすべてのｄｙｎＩＤを含む。リストは、ワード「Ｙａｈｏｏ」を含む組についてのワード「ｊａｃｋｓｏｎ」と２つの組番号を含む組についての３つの組番号を含むｂｒｏｋｅｒ．ｈｔｍｌ動的ページ作成点に対する事前結果エントリを有するだろう。
【０１６２】
それから、ＣＳＥは、（ユーザがＡＮＤ探索を要求したので）探索ワードの両方含む組、およびこれらの組の組番号を有するそれらのｄｙｎＩＤを特定する。株式情報例では、両方の探索ワードを含む１つの組があるため、ｂｒｏｋｅｒ．ｈｔｍｌのそのｄｙｎＩＤが戻される。
【０１６３】
それから、ＣＳＥは、戻された組番号、つまり組み５の入力を見て、照会文字列を作成する。このケースでは、入力は、組の最初の２つの列である。組５では、値は「ＹＨＯＯ」と「ｊａｃｋｓｏｎ」である。形式フィールド名も順方向インデックスエントリに記憶されているので、ＣＳＥは、
ｓｃｏｄｅ＝ＹＨＯＯ＆ｂｎａｍｅ＝Ｊａｃｋｓｏｎ
である照会文字列を構築できる。
【０１６４】
ＣＳＥは、（やはり順方向インデックスに記憶される）形式処理プログラムのＵＲＬもチェックする―このケースでは、それは、
ｈｔｔｐ：／／ｗｗｗ．ｓｔｏｃｋａｄｖｉｃｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａ
である。
【０１６５】
それから、ＣＳＥは、以下のとおりに動的ページの全体的なＵＲＬを構築するためにこれらをまとめる。
ｈｔｔｐ：／／ｗｗｗ．ｓｔｏｃｋａｄｖｉｃｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｂｒｏｋｅｒｄａｔａ？ｓｃｏｄｅ＝ＹＨＯＯ＆ｂｎａｍｅ＝ｊａｃｋｓｏｎ
【０１６６】
探索は、動的ページに表示されるそれ以外のワードも含む。特に株式情報例および図９Ｃに関して、ワード「ｂｒｏｋｅｒ」はすべての動的ページに表示される。このケースでは、ｄｙｎＩＤ  ５０００も含む逆転インデックスにヒットがある。それは、静的ワード上のヒットとしてマークされるだろう。
【０１６７】
２．３  アプレットページの索引付け
アプレットは、データベースにアクセスするために一般的に使用されている別の方法である。アプレットは、Ｊａｖａで作成される小さなプログラムである。アプレットは、ウェブページのｈｔｍｌコードで名前を指定され、ユーザがそのウェブページを見ると、アプレットは、ウェブページとともにユーザのコンピュータにダウンロードされる。それから、該アプレットプログラムは自動的に実行される。アプレットは、ウェブページ上でテキストを入力するためのボックス、およびこのテキストを提出するためにクリックするためのボタンを提示できる。提出時、アプレットは、照会の結果を示すために、ページ上の外観の変化を生成することができる。
【０１６８】
これらのページは、前述された意味では動的ページではないが、それらはユーザ入力を受け入れ、バックエンドデータベースから引き出される結果を表示することができるという特徴を有する。
【０１６９】
データベースがアプレットからアクセスされてよい２つの主要な方法がある。第１に、アプレットは、データベース自体に連結するための文を含んでよい。それ以外の主要なオプションは、アプレットがその結果としてデータベースアクセスを実施する別のＪａｖａクラスでリモートメソッド呼び出しを実行するということである。
【０１７０】
２．３．１  アプレット用のサーバベースエージェント
ＳＢＡは最初にインストールされると、それはウェブサイトのディレクトリツリーを調べ、各ｈｔｍｌページをチェックする。前述されたように、ＳＢＡは、形式タグを含むページを特定することができる。このケースでは、それはアプレットタグを含むページも探す。
【０１７１】
これらのページを、データベースにアクセスするにすぎないアプレットに狭めるために、ＳＢＡはＪａｖａバイナリからａｓｃｉｉ文字列を見て、ＳＱＬ照会を特定する。アプレット自体がデータベースにアクセスする場合、ＳＢＡは、アプレットから文字列内のＳＱＬ照会を見つける必要がある。ＳＱＬ文が見つけられる場合、このページが、その出力がデータベースへのアクセスを伴うページであると見なされる。
【０１７２】
それ以外のケースは、アプレットが、リモートメソッド呼び出しを使用して、データベース照会を実行するクラスを呼び出してよいということである。アプレットに呼び出されるこのＪａｖａクラスはアプレットコードと同じディレクトリ内になければならない。また、アプレットによって呼びだされるあらゆるクラスの名前はアプレットに対する文字列のリスト内で発生するだろう。したがって、ＳＢＡはアプレットコード内で名前が指定され、ウェブサイトディレクトリツリーの上位装置として働く機械上でのアプレットのディレクトリ内で発生する各クラスから抽出される文字列をチェックする。これらのどれかがＳＱＬ文を含んでいる場合には、アプレットタグを含んでいた元のページが、バックエンドデータベースにアクセスするページであると見なされる。
【０１７３】
ユーザ名およびパスワードの決定は、前述されたように形式処理プログラムと同様に起こる。バイナリ内の文字列が特定される。ユーザ名およびパスワードはＪａｖａデータベース接続性（ＪＤＢＣ）接続文で指定される。データベースへの接続に加え、ＳＢＡは、ＪＤＢＣ  ＵＲＬについての情報を決定する必要がある。アプレットのケースでは、ＪＤＢＣ  ＵＲＬは、すでに存在するだろう―したがって、ＳＢＡはそれに直接的にアクセスできる。
【０１７４】
このケースは、バックエンドデータベースにアクセスするためにテキストフィールド入力を使用するアプレットページを索引付けすることを伴う。それから、ＳＢＡはデータベースにアクセスするために使用されるテキストフィールド入力の名前を決定する。これは、前述された形式入力フィールドの名前に同等である。ＳＢＡは、アプレットのフィールドの名前を見る、アプレットのサブクラスを作成することによってこれを達成する。
ｃｌａｓｓ  Ｅｘｔｒａｃｔ  ｅｘｔｅｎｄｓ  ＯｒｉｇｉｎａｌＡｐｐｌｅｔ｛
ｐｕｂｌｉｃ  ｓｔａｔｉｃ  ｖｏｉｄｍａｉｎｓ（Ｓｔｒｉｎｇ［］ａｒｇｖ）｛
Ｆｉｅｌｄ［］ｆｄｓ＝ＯｒｉｇｉｎａｌＡｐｐｌｅｔ．ｇｅｔＦｉｅｌｄｓ（）；
｝
｝
【０１７５】
それから、これは初期にアプレットがバックエンドデータベースにアクセスすることを検証することが判明していたので、ＳＢＡは、アプレットによって使用されるＳＱＬ照会を考慮する。
【０１７６】
テキストフィールドをデータベース列に一致させるプロセスは、形式処理プログラムに関して同じである。ＳＢＡは、バックエンドデータベースに送信される照会を監視するＯＤＢＣ捜査プログラムをインストールする。それから、ＳＢＡは、アプレットに照会を送信し、作成されるＳＱＬ照会を監視する。
【０１７７】
ＣＩの構造およびＳＢＡからＣＩに送信される情報は、一般的に、動的ページのケースに関して同じである。この情報は、テキストフィールド入力に対応する入力組またはデータベース列を含む。
【０１７８】
サーチエンジンの結果ページ上でクリック可能なリンクを作成するために、ＳＢＡは、元のアプレットのサブクラスであるそのサイトで新しいアプレットをインストールする。ＳＢＡは新しいアプレットを含む新しいページもインストールする。
【０１７９】
サーチエンジンの結果ページに表示されるリンクは、ＳＢＡによってインストールされる別のスクリプトに対してだろう。このスクリプトは、サーチエンジンによって送信される照会文字列を読み取り、パラメータとしてサーチエンジンによって送信された照会文字列を含むことによって新しいアプレットを含むページ上のアプレットタグを改変する。それから、スクリプトは、新しいアプレットを含むページに宛先変更する。新しいアプレットはオリジナルのサブクラスである。そのｉｎｉｔ（）メソッドにおいて、それは照会文字列の中で読み取り、テキストフィールド内で相応してテキストを設定し、提出ボタンのクリックを真似る。このコードの部分の例は以下のとおりである。
Ｐｕｂｌｉｃ  ｃｌａｓｓ  ＲｅｓｕｌｔＡｐｐｌｅｔ  ｅｘｔｅｎｄｓ  ＤＢＡｐｐｌｅｔ｛
Ｂｕｔｔｏｎ  ｓｕｂｍｉｔ＝ｎｅｗ  Ｂｕｔｔｏｎ（“Ｅｎｔｅｒ”）；
ｐｕｂｌｉｃ  ｖｏｉｄ  ｉｎｉｔ（）｛
ｓｕｐｅｒ．ｉｎｉｔ（）；
ｆｉｅｌｄ１．ｓｅｔＴｅｘｔ（"ｓｏｍｅｔｅｘｔ"）；
ＳｕｂｍｉｔＡｃｔｉｏｎＬｉｓｔｎｅｒ  ｓａｌ＝ｎｅｗ  ＳｕｂｍｉｔＡｃｔｉｏｎＬｉｓｔｅｎｅｒ（ｔｈｉｓ）；
Ｓｕｂｍｉｔ．ａｄｄＡｃｔｉｏｎＬｉｓｔｅｎｅｒ（ｓａｌ）；
Ｓａｌ．ａｃｔｉｏｎＰｅｒｆｏｒｍｅｄ（ｎｕｌｌ）；
｝
｝
【０１８０】
２．３  ウェブサーバ統計
ＳＢＡは、そのローカルサーバについての有効な統計情報も収集してよい。
（ｉ）ローカルサーバによって作成されるログファイルにアクセスすること
（ｉｉ）ＨＴＴＰ接続を直接的に監視すること
（ｉｉｉ）サーバと統合されているＳＢＡのケースでは、内部データ構造にアクセスすることによって、
ＳＢＡがこの情報を収集してよい数多くの方法がある。
【０１８１】
ＳＢＡによって収集されてよい統計は多数であり、
（ｉ）ページまたはサイトに対するヒットの数
（ｉｉ）このページからリンクされたページ（つまり、ユーザがこのページに到達する単にやってきた元のページであり、これは、ユーザが探索照会ページからきた場合には、（探索のＵＲＬから入手可能な）使用されたサーチエンジンキーワードを含むことがある。
（ｉｉｉ）ページ、ページセットまたはウェブサイトで過ごした時間量
（ｉｖ）彼らのアドレス、ロケーション等ユーザについてのデモグラフィックス情報
（ｖ）単一ページのパケット間の時間およびページ要素（例えば、画像、アプレット、音等）間の時間を含む、サーバの帯域幅統計
を含む。
【０１８２】
ＳＢＡによって収集されるこの情報は、それ以外の情報と類似した方法でＣＩに送信されてよい。それは、
（ｉ）個々のサーチエンジンユーザのデモグラフィックスプロファイルに探索結果を合わせるために、
（ｉｉ）最も高速の応答を出すことができなければならないサイト（例えば、ミラーサイト等）にユーザを向けるために、
（ｉｉｉ）ユーザがページで過ごした平均時間、ユーザのデモグラフィックスプロファイル、および／またはある特定のページを見つけた過去の探索で使用されたキーワードおに従ってサーチエンジン結果を格付けするために、
使用されてよい。
【０１８３】
２．４  Ｅ−コマースアプリケーション
Ｅ−コマースは、動的ページに関する索引付け情報を提供するＳＢＡの専門家アプリケーションである。ＣＩは、ショッピングサイトにインストールされるＳＢＡ用のｅ−コマースポータルを提供するために使用されてよい。索引付けられてよい情報は、
（ｉ）製品名／型／製造メーカ等
（ｉｉ）大量価格設定と割引、税金等を含む価格
（ｉｉｉ）ロケーション
（ｉｖ）納品時間および運送費用オプション
（ｖ）品質およびレビュー
（ｖｉ）製品の写真
（ｖｉｉ）保証情報
（ｖｉｉｉ）支払いオプション、ポイントプログラム等
を含む。
【０１８４】
Ｅ−コマースポータルは、運賃を含む価格、納品時間、保証期間とロケーション、品質とレビュー、および支払い要件などの１つの基準または基準の組み合わせに基づいた探索を提供してもよい。
【０１８５】
購入は、ＣＩのポータルを通して発生してよい、あるいはユーザは関連するｅ−コマースサイトに向けられてよい。
【０１８６】
ＣＩのｅ−コマースポータルは、買い手のロケーションおよび製品の物理的なロケーション、売上税、および関税発行等に基づいた最適コスト（運賃コスト）を特定するために総費用計算を実行してよい。
【０１８７】
ＳＢＡは、ｅ−コマースサイトを構築するためのｅ−コマースパッケージを含んでよく、ＣＩのｅ−コマースポータルまたはローカルサイトのどちらかを通して支払いおよび運賃が発生するためのオプションが存在する。
【０１８８】
明細書を通して、インターネットに関して、ウェブサーバを使用して、ｈｔｍｌページの形を取るウェブサイトに関連してインデクシングシステムを使用することに対して参照がなされてきた。しかしながら、発明は、探索目的のために索引付けされてよいデータへのアクセスを提供する任意の形のサーバにも適用可能であることが理解されるべきである。
【０１８９】
多くの修正は、添付図面に関して、前述されたように、保温発明の範囲から逸脱することなく当業者に明らかになるだろう。
【図面の簡単な説明】
【図１】  インターネットへの接続に適切なコンピュータシステムの概略図である。
【図２】  インターネットに接続されたインデクシングシステムの好ましい実施形態の概略図である。
【図３】  インデクシングシステムの古いリンクを処理するための基本的な方法のフロー図である。
【図４】  インターネットに接続されたインデクシングシステムのサーバベースエージェントを含む３つのウェブサーバの例を示す概略図である。
【図５】  サーバベースエージェントおよびインデクシングシステムの中央ボックスを含む３つのウェブサーバの例を示す概略図である。
【図６Ａ】  別のウェブサーバ上の文書にリンクされた文書が変化した旨の情報を受信したことに対する、サーバベースエージェントの応答のフロー図である。
【図６Ｂ】  別のウェブサーバ上の文書にリンクされた文書が変化した旨の情報を受信したことに対する、サーバベースエージェントの応答のフロー図である。
【図７】  別のウェブサーバ上でリンクされる文書が変化した、または移動した旨をウェブ作者に通知するサーバベースエージェントのフロー図である。
【図８】  ブックマークに対する変更を更新するために、ウェブブラウザが中央インデックスとどのようにチェックするのかに関するフロー図である。
【図９Ａ】  株式コードおよび株式仲買人の氏名を入力するための形式入力を含むウェブページの例である。
【図９Ｂ】  入力が形式入力フィールド内でなされた状態の、図９Ａと同一の例である。
【図９Ｃ】  図９Ｂの提出ボタンを押すと戻るウェブページを示す。
【図１０】  データを形式ページに入力することによって動的ページがどのようにして作成されるのかを示す概略図である。
【図１１】  サーバベースエージェント、静的ページおよびデータベースを含み、かつ要求時に動的ページを作成する処理プログラムからのウェブサーバを示す概略図である。
【図１２】  動的ページに索引付けするためのサーバベースエージェントのプロセスのフロー図である。
【図１３】  中央インデックスのブロック図である。
【図１４】  中央インデックスによって実行されるプロセスのフロー図である。
【図１５Ａ】  動的ページ索引付けのためのインデクシングシステムの中央サーチエンジンによって実行されるプロセスのフロー図である。
【図１５Ｂ】  動的ページ索引付けのためのインデクシングシステムの中央サーチエンジンによって実行されるプロセスのフロー図である。
【図１６Ａ】  動的ページ索引付けのためにサーバベースエージェントによって実行されるプロセスのフロー図である。
【図１６Ｂ】  動的ページ索引付けのためにサーバベースエージェントによって実行されるプロセスのフロー図である。
【図１６Ｃ】  動的ページ索引付けのためにサーバベースエージェントによって実行されるプロセスのフロー図である。
【図１６Ｄ】  動的ページ索引付けのためにサーバベースエージェントによって実行されるプロセスのフロー図である。
【図１７】  中央インデックスの順方向インデックスおよび反転インデックス内の静的ページインデックスエントリ用の例の構造を示す図である。
【図１８】  中央インデックスの順方向インデックスおよび反転インデックス内の動的ページインデックスエントリの例の構造を示す図である。
【符号の説明】
１０２  ＣＰＵ、１０４  メモリシステム、１０６  アダプタ、１０８  二次記憶装置、１１０  ネットワークインターフェース、１１２  ディスプレイアダプタ、１１４  ユーザインターフェースアダプタ、１１５  システムバス、１１６  ディスプレイ、２００  コンピュータシステム、２０８  サーバベースエージェント、２１４  中央インデックス、２１９  中央サーチエンジン、２２２  サーバベースエージェント。
【図１】
0004873813.tif 000008
【図２】
0004873813.tif 000009
【図３】
0004873813.tif 000010
【図４】
0004873813.tif 000011
【図５】
0004873813.tif 000012
【図６Ａ】
0004873813.tif 000013
【図６Ｂ】
0004873813.tif 000014
【図７】
0004873813.tif 000015
【図８】
0004873813.tif 000016
【図９Ａ】
0004873813.tif 000017
【図９Ｂ】
0004873813.tif 000018
【図９Ｃ】
0004873813.tif 000019
【図１０】
0004873813.tif 000020
【図１１】
0004873813.tif 000021
【図１２】
0004873813.tif 000022
【図１３】
0004873813.tif 000023
【図１４】
0004873813.tif 000024
【図１５Ａ】
0004873813.tif 000025
【図１５Ｂ】
0004873813.tif 000026
【図１６Ａ】
0004873813.tif 000027
【図１６Ｂ】
0004873813.tif 000028
【図１６Ｃ】
0004873813.tif 000029
【図１６Ｄ】
0004873813.tif 000030
【図１７】
0004873813.tif 000031
【図１８】
0004873813.tif 000032