(57)【特許請求の範囲】
【請求項１】
ウェブページを記憶するための少なくとも一つの第１のメモリと、ウェブページを生成するのに使用するデータを記憶するための少なくとも一つの第２のメモリを含むメモリ管理システムと、を有するシステムであって、上記メモリ管理システムは、上記の少なくとも一つの第２のメモリ内に記憶されたデータのうち変更されたデータを識別することができ、かつ、上記の少なくとも一つの第２のメモリへの全ての処理を順番に含む少なくとも一つのデータベースのログを維持することができ、上記少なくとも一つの第２のメモリ内に記憶されたデータへの変更に基づいて、上記少なくとも一つの第１のメモリに記憶されたウェブページを更新するためのシステムにおいて、
上記システムは、さらに、少なくとも一つのサーバーを有し、上記少なくとも一つのサーバーは、
上記少なくとも一つの第１のメモリに記憶された各ウェブページと、当該ウェブページを生成するのに使用される上記少なくとも一つの第２のメモリ内に記憶されたデータと、の間のウェブページ−データ関係を維持し、
上記メモリ管理システムからどのデータが変更されたかを識別する情報を受信し、
受信した変更されたデータを識別する情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定し、
上記変更されたデータに関係あるウェブページを含む上記少なくとも一つの第１のメモリに対して当該ウェブページを更新するための更新命令を伝える
ようにプログラムされたことを特徴とするウェブページ更新システム。
【請求項２】
上記の少なくとも一つのサーバーは、さらに、
ＵＲＬを含むウェブコンテント要求を受信すると、当該ウェブコンテント要求に応じて、上記少なくとも一つの第２のメモリに対して少なくとも一つの照会あるいは処理を発し、
上記ウェブコンテント要求のＵＲＬと上記照会あるいは処理との間のＵＲＬ−照会／処理関係を維持し、
上記照会あるいは処理と、当該照会あるいは処理によりアクセスされる上記記憶されたデータと、の間の照会／処理−データ関係を維持し、
上記ＵＲＬ−照会／処理関係および上記照会／処理−データ関係から、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出し、
上記少なくとも一つの第１のメモリに記憶されたウェブページのうち、上記変更されたデータに関係するウェブページのロケーションを特定する
ようにプログラムされたことを特徴とする請求項１記載のウェブページ更新システム。
【請求項３】
上記の更新命令には、上記記憶されたウェブページを無効化あるいは削除するメッセージが含まれることを特徴とする請求項２記載のウェブページ更新システム。
【請求項４】
上記の更新命令には、上記記憶されたウェブページをリフレッシュするメッセージが含まれることを特徴とする請求項２記載のウェブページ更新システム。
【請求項５】
もし、上記記憶されたウェブページがウェブサーバーの中にあれば、上記の更新命令には、新しいウェブページを生成し、上記のウェブサーバー内に上記の新しいウェブページを記憶するメッセージが含まれることを特徴とする請求項４記載のウェブページ更新システム。
【請求項６】
上記の少なくとも一つのサーバーは、さらに、上記の受信したＵＲＬに対する要求および配布のタイムスタンプを含むウェブサーバーのログを維持し、
上記照会あるいは処理に対する発行タイムスタンプを含む照会および処理のログを維持し、
上記ウェブサーバーのログと上記照会および処理のログとから、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出し、
上記変更されたデータの識別情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定する
ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
【請求項７】
上記の少なくとも一つのサーバーは、
上記ウェブコンテント要求を受信し、上記ウェブサーバーのログを維持するようにプログラムされたウェブサーバーと、
上記ウェブサーバーから回送されたウェブコンテント要求を受信し、上記の回送されたウェブコンテント要求に応えて上記の少なくとも一つの照会あるいは処理を上記の少なくとも一つの第２のメモリに発するようにプログラムされたアプリケーションサーバーと、
上記の発せられた照会あるいは処理と当該照会あるいは処理によってアクセスされた記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
上記照会および処理のログおよび上記ウェブサーバーのログから上記ウェブコンテント要求のＵＲＬと上記発せられた照会あるいは処理との関係を決定し、上記のコンテント変更モニターから上記変更されたデータと関係がある照会あるいは処理の識別情報を受信し、記憶されたウェブページのうちどのウェブページが上記変更されたデータと関係のある上記の照会あるいは処理と関係するかを決定し、上記変更されたデータと関係のある上記ウェブページを含む上記少なくとも一つの第１のメモリへ更新命令を送信する、ようにプログラムされたコンテント配布サービスサーバーと
を含むことを特徴とする請求項６記載のウェブページ更新システム。
【請求項８】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
特定の照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含む各照会に対するビューテーブルを定義し、
上記のメモリ管理システムから変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、当該変更されたデータと関係ある照会はどれかを決定する
ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
【請求項９】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された処理を受信し、
各処理に対してデーモンを定義し、該デーモンは、特定の処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータに対して基準を確立し、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記の変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
【請求項１０】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成し、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
【請求項１１】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
【請求項１２】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項８記載のウェブページ更新システム。
【請求項１３】
要求／配布ログを読むことによってネットワークの通信量を知り、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例を集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成するためのスニッファをさらに含むことを特徴とする請求項６記載のウェブページ更新システム。
【請求項１４】
特定の記憶済みウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに対して、ある特定の記憶されたウェブページの無効性を知らせるための無効化モジュールと、
上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
を含むことを特徴とする請求項６記載のウェブページ更新システム。
【請求項１５】
上記の少なくとも一つのサーバーは、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
ようにプログラムされることを特徴とする請求項６記載のウェブページ更新システム。
【請求項１６】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーはアクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーが、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
上記変更されたデータがある特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に、ある定められた値によって置き換えられ、
もし、上記変更されたデータがある特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
ことを特徴とする請求項１５記載のウェブページ更新システム。
【請求項１７】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
ようにプログラムされることを特徴とする請求項１６記載のウェブページ更新システム。
【請求項１８】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
ことを特徴とする請求項１７記載のウェブページ更新システム。
【請求項１９】
上記の少なくとも一つのサーバーは、さらに、
受信されたウェブコンテント要求に含まれるＵＲＬからのＵＲＬ／関連処理マッピングログと、上記のウェブコンテント要求に応えて上記の少なくとも一つの第２のメモリへ発せられた照会あるいは処理を維持し、
上記の変更済みデータの同一性と、上記の発せられた照会あるいは処理と記憶済みデータとの間の上記の維持された関係と、上記のＵＲＬ／関連処理マッピングログとから、どの記憶済みウェブページが上記変更されたデータと関係があるかを決定する
ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
【請求項２０】
上記の少なくとも一つのサーバーは、
上記のＵＲＬ／関連処理マッピングログを維持し、回送されたウェブコンテント要求を受信し、上記の回送されたウェブコンテント要求に応えて上記の少なくとも一つの照会あるいは処理を、上記の少なくとも一つの第２のメモリに発するようにプログラムされたアプリケーションサーバーと、
上記の発せられた照会あるいは処理と、上記の照会あるいは処理によってアクセスされる記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
上記のコンテント変更モニターから上記変更されたデータと関係ある照会あるいは処理の識別情報を受信し、上記のＵＲＬ／関連処理マッピングログを受信し、上記記憶されたウェブページのうちどのウェブページが上記変更されたデータと関係ある上記の照会あるいは処理と関係するかを決定し、上記の更新命令を上記変更されたデータと関係ある上記記憶されたウェブページを含む上記の少なくとも一つの第１のメモリへ送信するようにプログラムされるコンテント配布サービスサーバーと
を含むことを特徴とする請求項１９記載のウェブページ更新システム。
【請求項２１】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送られた照会を受信し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
上記のメモリ管理システムから上記変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
ようにプログラムされることを特徴とする請求項１９記載のウェブページ更新システム。
【請求項２２】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送られた処理を受信し、
各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立し、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項２０記載のウェブページ更新システム。
【請求項２３】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成し、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項２０記載のウェブページ更新システム。
【請求項２４】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項２０記載のウェブページ更新システム。
【請求項２５】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項２１記載のウェブページ更新システム。
【請求項２６】
要求／配布ログを読むことによってネットワークの通信量を知るスニッファを含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成することを特徴とする請求項１９記載のウェブページ更新システム。
【請求項２７】
特定の記憶済みウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせるための無効化モジュールと、
上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
を含むことを特徴とする請求項１９記載のウェブページ更新システム。
【請求項２８】
少なくとも一つのサーバーは、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
ようにプログラムされることを特徴とする請求項１９記載のウェブページ更新システム。
【請求項２９】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーはアクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーは、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換えられ、
もし、上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
ことを特徴とする請求項２８記載のウェブページ更新システム。
【請求項３０】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
先に決定された値によって置き換えられた上記リンクされた照会条件の該当部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
ようにプログラムされることを特徴とする請求項２９記載のウェブページ更新システム。
【請求項３１】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
ことを特徴とする請求項３０記載のウェブページ更新システム。
【請求項３２】
上記の少なくとも一つのサーバーは、
回送されたウェブコンテント要求を受信し、コンテント配布サービスプロバイダＡＰＩコールを発するようにプログラムされたアプリケーションサーバーと、
コンテント配布サービスプロバイダＡＰＩコールを受信し、ＵＲＬ／関連処理マッピングログを維持し、上記のコンテント配布サービスプロバイダＡＰＩコールに応えて上記の少なくとも一つの照会あるいは処理を上記の少なくとも一つの第２のメモリへ発するようにプログラムされたコンテント配布サービスプロバイダＡＰＩハンドラと、
上記の発せられた照会あるいは処理と上記照会あるいは処理によってアクセスされる記憶済みデータとの間の関係を維持し、いずれの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
上記のコンテント変更モニターから上記変更されたデータと関係のある上記の照会あるいは処理の識別情報を受信し、上記のＵＲＬ／関連処理マッピングログを受信し、上記記憶されたウェブページのうちどのウェブページが上記変更されたデータと関係ある上記の照会あるいは処理と関係するかを決定し、上記の更新命令を上記変更されたデータと関係ある上記の記憶されたウェブページを含む上記の少なくとも一つの第１のメモリへ送信するようにプログラムされたコンテント配布サービスサーバーと
を含むことを特徴とする請求項１９記載のウェブページ更新システム。
【請求項３３】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送られた照会を受信し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
上記のメモリ管理システムから上記変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
【請求項３４】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送られた処理を受信し、
各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立し、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
【請求項３５】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成し、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
【請求項３６】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
【請求項３７】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項３３記載のウェブページ更新システム。
【請求項３８】
上記の少なくとも一つのサーバーは、さらに
受信したウェブコンテント要求を記憶済み手順へと変換し、
上記の記憶済み手順の中に含まれる上記のＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた照会と、からデータベース照会ログを維持し、
上記の記憶済み手順の中に含まれるＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた処理と、から処理ログを維持し、
上記データベース照会ログと上記処理ログとからＵＲＬ／関連処理マッピングテーブルを生成し、
上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と上記の記憶されたデータとの間の維持された関係と、上記のＵＲＬ／関連処理マッピングテーブルとから、上記記憶されたウェブページのいずれのウェブページが上記変更されたデータと関係があるかを決定する
ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
【請求項３９】
上記の少なくとも一つのサーバーは、
受信されたウェブコンテント要求を記憶済み手順へと変換し、上記の記憶済み手順に含まれるＵＲＬと、上記の記憶済み手順に応えて上記の少なくとも一つの第２のメモリに発せられた照会と、から上記のデータベース照会ログを生成し、記憶済み手順に含まれるＵＲＬと、上記の記憶済み手順に応えて上記の少なくとも一つの第２のメモリに発せられた処理と、から処理ログを生成するようにプログラムされたアプリケーションサーバーと、
上記の発せられた照会あるいは処理と上記の照会あるいは処理によってアクセスされた記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
上記のデータベース照会ログと上記の処理ログとからＵＲＬ／関連処理マッピングテーブルを生成し、上記の変更済みデータの識別情報と、上記の発せられた照会あるいは処理と上記の記憶されたデータとの間の維持された関係と、上記のＵＲＬ／関連処理マッピングテーブルとから、上記記憶されたウェブページのいずれのウェブページが上記変更されたデータと関係があるかを決定し、上記の更新命令を上記変更されたデータと関係ある記憶済みウェブページを含む上記の少なくとも一つの第１のメモリへと送信するためのコンテント配布サービスサーバーと
を含むことを特徴とする請求項３８記載のウェブページ更新システム。
【請求項４０】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送られた照会を受信し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
上記のメモリ管理システムから上記変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
【請求項４１】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送られた照会あるいは処理を受信し、
各照会あるいは処理に対するデーモンを定義し、該デーモンは、当該照会あるいは処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立し、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
【請求項４２】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成し、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
【請求項４３】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
【請求項４４】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項４０記載のウェブページ更新システム。
【請求項４５】
要求／配布ログを読むことによってネットワークの通信量を知るスニッファを含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成することを特徴とする請求項３８記載のウェブページ更新システム。
【請求項４６】
ある特定の記憶されたウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶されたウェブページの無効性を知らせるための無効化モジュールと、
上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
を含むことを特徴とする請求項３８記載のウェブページ更新システム。
【請求項４７】
少なくとも一つのサーバーは、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
ようにプログラムされることを特徴とする請求項３８記載のウェブページ更新システム。
【請求項４８】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーは、アクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーが、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換えられ、
もし、上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
ことを特徴とする請求項４７記載のウェブページ更新システム。
【請求項４９】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
ようにプログラムされることを特徴とする請求項４８記載のウェブページ更新システム。
【請求項５０】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
ことを特徴とする請求項４９記載のウェブページ更新システム。
【請求項５１】
上記の少なくとも一つのサーバーは、さらに
上記の受信したウェブコンテント要求からＵＲＬ情報を抽出し、
上記の発せられた照会および処理から照会と処理とを抽出し、
上記の抽出されたＵＲＬ情報と上記の抽出された照会および処理情報とからＵＲＬ／関連処理マッピングログを維持し、
上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と記憶されたデータとの間の維持される関係と、上記のＵＲＬ／関連処理マッピングログとから、上記記憶されたウェブページの中でいずれのウェブページが上記変更されたデータと関係あるかを決定する
ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
【請求項５２】
上記の少なくとも一つのサーバーは、
上記の受信されたウェブコンテント要求からＵＲＬ情報を抽出し、上記の発せられた照会と処理とから照会情報と処理情報とをそれぞれ抽出し、上記の受信されたウェブコンテント要求を回送し、上記のＵＲＬ／関連処理マッピングログを維持するためのアプリケーションサーバープロキシと、
上記アプリケーションサーバープロキシによって回送されるウェブサーバー要求を受信し、上記の回送されたウェブコンテント要求に応えて上記の少なくとも一つの照会あるいは処理を発するためのアプリケーションサーバーと、
上記の発せられた照会あるいは処理と上記の照会あるいは処理によってアクセスされた記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
上記のコンテント変更モニターから上記変更されたデータと関係がある照会あるいは処理の識別情報を受信し、上記のＵＲＬ／関連処理マッピングログを受信し、上記記憶されたウェブページの中でどのウェブページが、上記変更されたデータと関係のある上記の照会あるいは処理と関係するかを決定し、上記変更されたデータと関係のある上記記憶されたウェブページを含む上記の少なくとも一つの第１のメモリへの更新命令を送信するようにプログラムされたコンテント配布サービスサーバーと
を含むことを特徴とする請求項５１記載のウェブページ更新システム。
【請求項５３】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
照会ごとに、当該照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
上記のメモリ管理システムから上記変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係ある照会はどれかを決定する
ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
【請求項５４】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された処理を受信し、
各処理に対してデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立し、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
【請求項５５】
上記のコンテント変更モニターは、
上記の少なくとも一つの第２のメモリに送信された照会を受信し、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成し、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
【請求項５６】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
【請求項５７】
上記のコンテント変更モニターは、
少なくとも一つの第３のメモリを持ち、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
照会ごとに、当該照会と関係ある上記の少なくとも一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
ようにプログラムされることを特徴とする請求項５３記載のウェブページ更新システム。
【請求項５８】
要求／配布ログを読むことによってネットワークの通信量を知るスニッファを含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成することを特徴とする請求項５１記載のウェブページ更新システム。
【請求項５９】
特定の記憶済みウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理の間との関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせるための無効化モジュールと、
上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
を含むことを特徴とする請求項５１記載のウェブページ更新システム。
【請求項６０】
少なくとも一つのサーバーは、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
ようにプログラムされることを特徴とする請求項５１記載のウェブページ更新システム。
【請求項６１】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーはアクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーが、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換えられ、
もし、上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
ことを特徴とする請求項６０記載のウェブページ更新システム。
【請求項６２】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
ようにプログラムされることを特徴とする請求項６１記載のウェブページ更新システム。
【請求項６３】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
ことを特徴とする請求項６２記載のウェブページ更新システム。
【請求項６４】
ウェブページを記憶するための少なくとも一つの第１のメモリと、ウェブページを生成するのに使用するデータを記憶するための少なくとも一つの第２のメモリを含むメモリ管理システムと、を有するシステムにおいて、上記メモリ管理システムは、上記の少なくとも一つの第２のメモリ内に記憶されたデータのうち変更されたデータを識別することができ、かつ、上記の少なくとも一つの第２のメモリへの全ての処理を順番に含む少なくとも一つのデータベースのログを維持することができ、上記少なくとも一つの第２のメモリ内に記憶されたデータへの変更に基づいて、上記少なくとも一つの第１のメモリに記憶されたウェブページを更新するための方法において、
上記少なくとも一つの第１のメモリに記憶された各ウェブページと、当該ウェブページを生成するのに使用される上記少なくとも一つの第２のメモリ内に記憶されたデータと、の間のウェブページ−データ関係を維持する段階と、
上記メモリ管理システムからどのデータが変更されたかを識別する情報を受信する段階と、
受信した変更されたデータを識別する情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定する段階と、
上記変更されたデータに関係あるウェブページを含む上記少なくとも一つの第１のメモリに対して当該ウェブページを更新するための更新命令を送る段階と
を備えることを特徴とするウェブページ更新方法。
【請求項６５】
上記の方法は、さらに、
ＵＲＬを含むウェブコンテント要求を受信する段階と、
上記少なくとも一つの第２のメモリに対して少なくとも一つの照会あるいは処理を発する段階と、
上記ウェブコンテント要求のＵＲＬと上記照会あるいは処理との間のＵＲＬ−照会／処理関係を維持する段階と、
上記照会あるいは処理と、当該照会あるいは処理によりアクセスされる上記記憶されたデータと、の間の照会／処理−データ関係を維持する段階と、
上記ＵＲＬ−照会／処理関係および上記照会／処理−データ関係から、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出す段階と、
上記少なくとも一つの第１のメモリに記憶されたウェブページのうち、上記変更されたデータに関係するウェブページのロケーションを識別する段階と
を含むことを特徴とする請求項６４記載のウェブページ更新方法。
【請求項６６】
更新命令を送る上記の段階は、上記記憶されたウェブページを無効化あるいは削除するメッセージを送ることを含むことを特徴とする請求項６５記載のウェブページ更新方法。
【請求項６７】
更新命令を送る上記の段階は、上記記憶されたウェブページをリフレッシュするメッセージを送ることを含むことを特徴とする請求項６５記載のウェブページ更新方法。
【請求項６８】
もし上記記憶されたウェブページがウェブサーバーの中にあれば、更新命令を送る上記の段階は、新しいウェブページを生成するメッセージを送り、かつ上記のウェブページをウェブサーバーの中に記憶することを含むことを特徴とする請求項６７記載のウェブページ更新方法。
【請求項６９】
上記の方法は、さらに、
上記の受信したＵＲＬに対する要求および配布のタイムスタンプを含むウェブサーバーのログを維持する段階と、
上記照会あるいは処理に対する発行タイムスタンプを含む照会および処理のログを維持する段階と、
上記ウェブサーバーのログと上記照会および処理のログとから、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出す段階と、
上記変更されたデータの識別情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定する段階と
を含むことを特徴とする請求項６５記載のウェブページ更新方法。
【請求項７０】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
特定の照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含む各照会に対するビューテーブルを定義する段階と、
上記のメモリ管理システムから変更されたデータを受信する段階と、
上記のビューテーブルと上記変更されたデータとから、当該変更されたデータと関係ある照会はどれかを決定する段階と
を含むことを特徴とする請求項６９記載のウェブページ更新方法。
【請求項７１】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された処理を受信する段階と、
各処理に対してデーモンを定義し、該デーモンは、特定の処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立する段階と、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項６９記載のウェブページ更新方法。
【請求項７２】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成する段階と、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項６９記載のウェブページ更新方法。
【請求項７３】
上記の方法は、さらに、
上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させる段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項７０記載のウェブページ更新方法。
【請求項７４】
上記の方法は、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項７０記載のウェブページ更新方法。
【請求項７５】
要求／配布ログを読むことによってネットワークの通信量を知る段階と、
照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例を集める段階と、
上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階と
をさらに含むことを特徴とする請求項６９記載のウェブページ更新方法。
【請求項７６】
上記の方法は、さらに
無効化の方針を作り出し、関連のある照会あるいは処理統計を集める登録段階と、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに対して、ある特定の記憶されたウェブページの無効性を知らせる無効化段階と、
予備データ構造を作る段階と
を含むことを特徴とする請求項６９記載のウェブページ更新方法。
【請求項７７】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
を含むことを特徴とする請求項６９記載のウェブページ更新方法。
【請求項７８】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
上記変更されたデータがある特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、特定のテーブルに限られたリンクされた照会条件のそれらの部分を、他の特定のテーブルに限られたリンクされた照会条件のそれらの部分を評価する前に定められた値によって置き換える段階をさらに含み、
もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
ことを特徴とする請求項７７記載のウェブページ更新方法。
【請求項７９】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
を含むことを特徴とする請求項７８記載のウェブページ更新方法。
【請求項８０】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
ことを特徴とする請求項７９記載のウェブページ更新方法。
【請求項８１】
上記の方法は、さらに
受信されたウェブコンテント要求に含まれるＵＲＬからのＵＲＬ／関連処理マッピングログと、上記のウェブコンテント要求に応えて上記の少なくとも一つの第２のメモリへ発せられた照会あるいは処理を維持する段階と、
上記の変更済みデータの同一性と、上記の発せられた照会あるいは処理と記憶済みデータとの間の上記の維持された関係と、上記のＵＲＬ／関連処理マッピングログとから、どの記憶済みウェブページが上記変更されたデータと関係があるかを決定する段階と
を含むことを特徴とする請求項６５記載のウェブページ更新方法。
【請求項８２】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送られた照会を受信する段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と、
上記のメモリ管理システムから上記変更されたデータを受信し、上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する段階と
を含むことを特徴とする請求項８１記載のウェブページ更新方法。
【請求項８３】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送られた処理を受信する段階と、
各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立する段階と、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項８１記載のウェブページ更新方法。
【請求項８４】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成する段階と、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項８１記載のウェブページ更新方法。
【請求項８５】
上記の方法は、さらに
少なくとも一つの第３のメモリを持ち、さらに、上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させる段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項８２記載のウェブページ更新方法。
【請求項８６】
上記の方法は、さらに
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項８２記載のウェブページ更新方法。
【請求項８７】
要求／配布ログを読むことによってネットワークの通信量を知る段階を含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階を含むことを特徴とする請求項８１記載のウェブページ更新方法。
【請求項８８】
上記の方法は、さらに
無効化の方針を作り出し、関連のある照会あるいは処理統計を集める段階と、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせる段階と、
予備データ構造を作る段階と
を含むことを特徴とする請求項８１記載のウェブページ更新方法。
【請求項８９】
上記方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
を含むことを特徴とする請求項８１記載のウェブページ更新方法。
【請求項９０】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータがその特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、特定のテーブルに限られたリンクされた照会条件の該当部分を、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換える段階をさらに含み、
もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
ことを特徴とする請求項８９記載のウェブページ更新方法。
【請求項９１】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
を含むことを特徴とする請求項９０記載のウェブページ更新方法。
【請求項９２】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
ことを特徴とする請求項９１記載のウェブページ更新方法。
【請求項９３】
上記の方法は、さらに
受信したウェブコンテント要求を記憶済み手順へと変換する段階と、
上記の記憶済み手順の中に含まれる上記のＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた照会と、からデータベース照会ログを維持する段階と、
上記の記憶済み手順の中に含まれるＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた処理と、から処理ログを維持する段階と、
上記データベース照会ログと上記処理ログとからＵＲＬ／関連処理マッピングテーブルを生成する段階と、
上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と上記の記憶されたデータとの間の維持された関係と、上記のＵＲＬ／関連処理マッピングテーブルとから、上記記憶されたウェブページのいずれのウェブページが上記変更されたデータと関係があるかを決定する段階と
を含むことを特徴とする請求項６５記載のウェブページ更新方法。
【請求項９４】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送られた照会を受信し、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
上記のメモリ管理システムから上記変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
ようにプログラムされることを特徴とする請求項９３記載のウェブページ更新方法。
【請求項９５】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送られた照会あるいは処理を受信する段階と、
各照会あるいは処理に対するデーモンを定義し、該デーモンは、当該照会あるいは処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータに対して基準を確立する段階と、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項９３記載のウェブページ更新方法。
【請求項９６】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成する段階と、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項９３記載のウェブページ更新方法。
【請求項９７】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリから少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを少なくとも一つの第２のメモリと一致させる段階と、
特定の照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含む各照会に対するビューテーブルを定義する段階と
を含むことを特徴とする請求項９４記載のウェブページ更新方法。
【請求項９８】
上記の方法は、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項９４記載のウェブページ更新方法。
【請求項９９】
要求／配布ログを読むことによってネットワークの更新を知る段階と、
照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集める段階と、
上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階と
をさらに含むことを特徴とする請求項９３記載のウェブページ更新方法。
【請求項１００】
上記の方法は、さらに
無効化の方針を作り出し、関連のある照会あるいは処理統計を集める段階と、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶されたウェブページの無効性を知らせる段階と、
予備データ構造を作る段階と
を含むことを特徴とする請求項９３記載のウェブページ更新方法。
【請求項１０１】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
を含むことを特徴とする請求項９３記載のウェブページ更新方法。
【請求項１０２】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に、特定のテーブルに限られたリンクされた照会条件の該当部分を、定められた値によって置き換える段階をさらに含み、
もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
ことを特徴とする請求項１０１記載のウェブページ更新方法。
【請求項１０３】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
を含むことを特徴とする請求項１０２記載のウェブページ更新方法。
【請求項１０４】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
ことを特徴とする請求項１０３記載のウェブページ更新方法。
【請求項１０５】
上記の方法は、さらに
上記の受信したウェブコンテント要求からＵＲＬ情報を抽出する段階と、
上記の発せられた照会および処理から照会と処理とを抽出する段階と、
上記の抽出されたＵＲＬ情報と上記の抽出された照会および処理情報とからＵＲＬ／関連処理マッピングログを維持する段階と、
上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と記憶されたデータとの間の維持される関係と、上記のＵＲＬ／関連処理マッピングログとから、上記記憶されたウェブページの中でいずれのウェブページが上記変更されたデータと関係あるかを決定する段階と
を含むことを特徴とする請求項６５記載のウェブページ更新方法。
【請求項１０６】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送られた照会を受信し、
照会ごとに、当該照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
上記のメモリ管理システムから上記変更されたデータを受信し、
上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
ようにプログラムされることを特徴とする請求項１０５記載のウェブページ更新方法。
【請求項１０７】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送られた処理を受信する段階と、
各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータに対して基準を確立する段階と、
上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
【請求項１０８】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成する段階と、
上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
【請求項１０９】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリから少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを少なくとも一つの第２のメモリと一致させる段階と、
照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項１０６記載のウェブページ更新方法。
【請求項１１０】
上記の方法は、さらに、
上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
照会ごとに、当該照会と関係ある上記の少なくとも一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
を含むことを特徴とする請求項１０６記載のウェブページ更新方法。
【請求項１１１】
要求／配布ログを読むことによってネットワークの通信量を知る段階と、
照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集める段階と、
上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階と
をさらに含むことを特徴とする請求項１０５記載のウェブページ更新方法。
【請求項１１２】
上記の方法は、さらに
無効化の方針を作り出し、関連のある照会あるいは処理統計を集める段階と、
データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせる段階と、
予備データ構造を作る段階と
を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
【請求項１１３】
上記の方法は、さらに
上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
【請求項１１４】
もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、特定のテーブルに限られたリンクされた照会条件の該当部分を、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換える段階をさらに含み、
もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
ことを特徴とする請求項１１３記載のウェブページ更新方法。
【請求項１１５】
特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
を含むことを特徴とする請求項１１４記載のウェブページ更新方法。
【請求項１１６】
特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
ことを特徴とする請求項１１５記載のウェブページ更新方法。
【請求項１１７】
上記登録モジュールは、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
ウェブコンテント要求のＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連することのない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定し、
上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
ことを特徴とする請求項１４記載のウェブページ更新システム。
【請求項１１８】
結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１１７記載のウェブページ更新システム。
【請求項１１９】
上記の無効化モジュールは、さらに
いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
ようにプログラムされ、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１４記載のウェブページ更新システム。
【請求項１２０】
上記の情報管理モジュールは、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
関係のある照会例を識別し、それらを整えられた方法で処理することにより照会例の合体を実行し、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
ようにプログラムされることを特徴とする請求項１４記載のウェブページ更新システム。
【請求項１２１】
上記の無効化器／リフレッシュ器は、さらに
特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
ようにプログラムされることを特徴とする請求項１４記載のウェブページ更新システム。
【請求項１２２】
上記の無効化器／リフレッシュ器は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項１４記載のウェブページ更新システム。
【請求項１２３】
上記登録モジュールは、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定し、
上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
ことを特徴とする請求項２７記載のウェブページ更新システム。
【請求項１２４】
結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１２３記載のウェブページ更新システム。
【請求項１２５】
上記の無効化モジュールは、さらに
いずれのデータベースポーリング要求が生成されるべきかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
ようにプログラムされ、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項２７記載のウェブページ更新システム。
【請求項１２６】
上記の情報管理モジュールは、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
関係のある照会例を識別し、それらを整えられた方法で処理することにより照会例の合体を実行し、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
ようにプログラムされることを特徴とする請求項２７記載のウェブページ更新システム。
【請求項１２７】
上記の無効化器／リフレッシュ器は、さらに特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
ようにプログラムされることを特徴とする請求項２７記載のウェブページ更新システム。
【請求項１２８】
上記の無効化器／リフレッシュ器は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項２７記載のウェブページ更新システム。
【請求項１２９】
上記登録モジュールは、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定するようにプログラムされ、
上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
ことを特徴とする請求項４６記載のウェブページ更新システム。
【請求項１３０】
結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１２９記載のウェブページ更新システム。
【請求項１３１】
上記の無効化モジュールは、さらに
いずれのデータベースポーリング要求が生成されるべきかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
ようにプログラムされ、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項４６記載のウェブページ更新システム。
【請求項１３２】
上記の情報管理モジュールは、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
関係のある照会例を識別し、それらを整えられた方法で処理することにより照会例の合体を実行し、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
ようにプログラムされることを特徴とする請求項４６記載のウェブページ更新システム。
【請求項１３３】
上記の無効化器／リフレッシュ器は、さらに
特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
ようにプログラムされることを特徴とする請求項４６記載のウェブページ更新システム。
【請求項１３４】
上記の無効化器／リフレッシュ器は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項４６記載のウェブページ更新システム。
【請求項１３５】
上記登録モジュールは、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定するようにプログラムされ、
上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
ことを特徴とする請求項５９記載のウェブページ更新システム。
【請求項１３６】
結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１３５記載のウェブページ更新システム。
【請求項１３７】
上記の無効化モジュールは、さらに
いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
ようにプログラムされ、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項５９記載のウェブページ更新システム。
【請求項１３８】
上記の情報管理モジュールは、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行し、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
ようにプログラムされることを特徴とする請求項５９記載のウェブページ更新システム。
【請求項１３９】
上記の無効化器／リフレッシュ器は、さらに
特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
ようにプログラムされることを特徴とする請求項５９記載のウェブページ更新システム。
【請求項１４０】
上記の無効化器／リフレッシュ器は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項５９記載のウェブページ更新システム。
【請求項１４１】
上記登録段階は、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する
段階を含むことを特徴とする請求項７６記載のウェブページ更新方法。
【請求項１４２】
結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１４１記載のウェブページ更新方法。
【請求項１４３】
上記の無効化段階は、さらに
いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項７６記載のウェブページ更新方法。
【請求項１４４】
上記の方法は、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入し、それらをグループとして処理することで更新の合体を実行する段階と
を含むことを特徴とする請求項７６記載のウェブページ更新方法。
【請求項１４５】
上記の方法は、さらに
特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
ことを特徴とする請求項７６記載のウェブページ更新方法。
【請求項１４６】
上記の方法は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項７６記載のウェブページ更新方法。
【請求項１４７】
上記登録段階は、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶する段階と、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録する段階と、結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項８８記載のウェブページ更新方法。
【請求項１４８】
結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１４７記載のウェブページ更新方法。
【請求項１４９】
上記の無効化段階は、さらに
いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項８８記載のウェブページ更新方法。
【請求項１５０】
上記の方法は、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する段階と
を含むことを特徴とする請求項８８記載のウェブページ更新方法。
【請求項１５１】
上記の方法は、さらに
特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
ことを特徴とする請求項８８記載のウェブページ更新方法。
【請求項１５２】
上記の方法は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページを無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項８８記載のウェブページ更新方法。
【請求項１５３】
上記登録段階は、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶する段階と、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録する段階と、
結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１００記載のウェブページ更新方法。
【請求項１５４】
結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１５３記載のウェブページ更新方法。
【請求項１５５】
上記の無効化段階は、さらに
いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１００記載のウェブページ更新方法。
【請求項１５６】
上記の方法は、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する段階と
を含むことを特徴とする請求項１００記載のウェブページ更新方法。
【請求項１５７】
上記の方法は、さらに
特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
ことを特徴とする請求項１００記載のウェブページ更新方法。
【請求項１５８】
上記の方法は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページを無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項１００記載のウェブページ更新方法。
【請求項１５９】
上記登録段階は、さらに
オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶する段階と、
ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録する段階と、結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１１２記載のウェブページ更新方法。
【請求項１６０】
結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１５９記載のウェブページ更新方法。
【請求項１６１】
上記の無効化段階は、さらに
いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
を含み、
上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１１２記載のウェブページ更新方法。
【請求項１６２】
上記の方法は、さらに
関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する段階と
を含むことを特徴とする請求項１１２記載のウェブページ更新方法。
【請求項１６３】
上記の方法は、さらに
特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
ことを特徴とする請求項１１２記載のウェブページ更新方法。
【請求項１６４】
上記の方法は、さらに
特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページを無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項１１２記載のウェブページ更新方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、広くコンテント配布ネットワークに関し、また、実施形態において、コンテント配布サービスを改善する、動的に作られかつ静的であるウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法に関する。
【０００２】
本発明の実施形態は、２０００年７月１４日出願の米国仮出願第６０／２１８４１８号  ”Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｉｎｔｅｌｌｉｇｅｎｔ  Ｃａｃｈｉｎｇ  ａｎｄ  Ｒｅｆｒｅｓｈ  ｏｆ  Ｄｙｎａｍｉｃａｌｌｙ  Ｇｅｎｅｒａｔｅｄ  ａｎｄ  Ｓｔａｔｉｃ  Ｗｅｂ  Ｃｏｎｔｅｎｔｓ”から優先権主張しており、その内容は、ここに取り込まれるものとする。
【０００３】
【従来の技術及び発明が解決しようとする課題】
ウェブの性能は、コンテントプロバイダ間の差別化にとって大事な点である。主要なウェブサイト内で起こるクラッシュと速度低下は、ウェブ通信を高速で行おうとする際に企業が直面する問題点を示している。インターネットのバックボーン技術が発達したので、サービス管理の領域の多くの新機軸によって帯域幅とウェブコンテント読み出し応答時間が改善された。しかし、これらの改善によって、インターネット内の全ての点における通信の問題を解決することはできない。
【０００４】
例えば、図１において、日本のネットワーク１４のエンドユーザー１２が、米国のネットワーク１８内のウェブサイト１６からの、あるページにアクセス要求を出したとする。この要求は、ウェブサイト１６に届く前にいくつかのゲートウェイ２０，２２，２４を通過しなくてはならない。ウェブサイト１６は、大きな帯域幅を持つこと（大量のデータを瞬時にやり取りする能力）ができるが、日本のネットワーク１４を米国のネットワーク１８にに接続するゲートウェイは、遅いことが多く、そして、エンドユーザー１２がウェブサイト１６から該当ページにアクセスしようとするときに、ゲートウェイにボトルネックが生じる。そのようなボトルネックは、データ１ページのアクセス時間が１０秒あるいはそれ以上の単位となることがある。ゲートウェイのボトルネックゆえに、また、エンドユーザー１２からウェブサイト１６への／からのインターネットの通り道に沿って不確実な点が多いために、コンテント配布のネットワークあるいはシステムが、現在開発されている。
【０００５】
基本的には、コンテント配布システムは、少なくとも２つの大きな目的のために、設計され開発される：１つは付加のバランスを達成すること、他は応答時間を減少することである。コンテント配布システムは、全てのゲートウェイを迂回するか伝送路内のインターネットゲートウェイの数を減らす間にコンテントを配布するために、高速専用回線を用いて実現することができる。しかし、そのような専用ネットワークは高価であり、全てのネットワークに対して展開することはできない。コンテント配布システムを実現する他の方法は、知的キャッシュやミラーリングや代理サーバーを用いるか、希望するコンテントを含み、エンドユーザーの近くにあるかアクセスが容易な、エンドユーザーが高速な応答時間を保証するような利用可能サーバーに向け直す他の技術を用いて行われる。向け直されたいくつかの通信によって、通信のサージが減少し、エンドユーザーは高速応答時間の恩恵を受ける。そのようなネットワークやシステムのアーキテクチャや機能性を示すのに使用される用語は、コンテント配布サービス（ＣＤＳ）である。
【０００６】
ＣＤＳに対して、多くの研究方法とアーキテクチャとが提案されており、これらのサービスとシステムとアーキテクチャの殆どは、静的コンテントに照準を合わせている。例えば、ＣａｃｈｅＰｏｒｔａｌＴＭは、ＣＤＳを提供するシステムであり、係属中の米国特許出願第０９／５４５８０５号２０００年４月７日出願の  ”Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｅｆｆｉｃｉｅｎｔ  Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ”  に記載されており、その内容は、ここに参考として取り込まれるものとする。ＣａｃｈｅＰｏｒｔａｌは、コンテントをエンドユーザーにネットワークの遅延を少なく提供するエッジキャッシュとして使用されるミラーサーバーにアクセスする。ＣａｃｈｅＰｏｒｔａｌは、ミラーサーバー内のコンテントを取り除いたりリフレッシュしたり無効化したりするのと同様にミラーサーバー間にコンテントを配布することができる。また、ＣａｃｈｅＰｏｒｔａｌは、ミラーサーバー内のコンテントのアトリビュートを変更することができる。例えば、ＣａｃｈｅＰｏｒｔａｌは、オブジェクトが更新されたかどうかを確認することができる。もし、ＣａｃｈｅＰｏｒｔａｌが、更新されていないと知ると、ＣａｃｈｅＰｏｒｔａｌは、リフレッシュ時刻のログされた値や最後に変更された日付ログを変えることができる。
【０００７】
しかし、多くのｅビジネスのサイトにとっては、アプリケーションのサーバーとデータベースとにおいて表現されるビジネス処理の現在の状況に基づいて、ウェブページが動的に作られる。ここで必要とされる技術は、静的なコンテント配布に必要とされるものよりもさらに複雑である。現在の技術に基づいて、ウェブページを配布するアプリケーションサーバーやデータベースやウェブサーバーあるいはウェブサーバーが独立した構成要素であるという事実によって、キャッシュされたウェブページのデータベースコンテントが変更されたことを反映する効率的な機構はなかった。その結果として、従来のアプリケーションサーバーは、一般に、動的に作られたウェブページをキャッシュができないようにするか、その場で無効にするよう定める。そうすることによって、そのような要求の処理時間は、現在のデータを供給するのに必要な計算を実行するために、ネットワークを一回りするのに必要な時間であり、ウェブサーバーから現在のデータを受信する時間であり、またバックエンドシステム（すなわちアプリケーションサーバーとデータベース）のための時間である。
【０００８】
図２は、バックエンドシステムを備えたウェブサイトのための、典型的な現在のウェブページ配布機構２４の概略を示している。例えば、ｅビジネスサイトは、ｅビジネスサイトがウェブサイトを通じて得る全ての製品の価格や品目明細や量を維持するためのデータベース管理システム（ＤＢＭＳ）２６を利用することができる。ここで記載されるＤＢＭＳには、コンテントを記憶するデータベースのようなメモリが含まれる。図２に示すようにエンドユーザー２８は、インターネットにアクセスし、ｅビジネスサイトにおける製品の情報を要求するために、ウェブブラウザ３０とやりとりを行う。そのような要求には、製品名や製品番号のようなパラメータが含まれ得、またクッキー３４のような他のものが含まれうる。
【０００９】
クッキーは特定のウェブサイトにより送られ、今はエンドユーザーのコンピュータにある小さなファイルである。クッキーは、エンドユーザーが何をしているかを追跡し続け、またユーザーを識別するのにウェブサイトにより使用される。例えば、エンドユーザーが特定のウェブサイトでボタンをクリックすると、ウェブサイトは、クッキーをエンドユーザーのコンピュータに送る。このクッキーは、エンドユーザーがウェブサイトを渡っていく様子をモニターすることができる。ユーザーが次にそのウェブサイトにログするとき、ウェブサイトは特定の位置のクッキーを捜すことができる。もし、クッキーが見つかれば、エンドユーザーが２度目以上の顧客であると分かる。ウェブサイトは、また、ウェブページをエンドユーザーのためにカスタマイズするために、クッキーからの上記のウェブサイトを渡っていく様子に関する情報を使用することができる。
【００１０】
再び図２を参照して、ウェブページ要求３２は、顧客ブラウザ３０からキャッシュ３６に送られることができる。図２において、キャッシュブロック３６は、異なる種類のキャッシュのうちのいずれか一つであることを示す点線で識別される。キャッシュの一つの種類は、エッジキャッシュ（ｅｄｇｅ  ｃａｃｈｅ）と呼ばれる。エッジキャッシュは、また代理キャッシュと呼ばれ、通常  ＣａｓｈｅＰｏｒｔａｌＴＭ  のようなサードパーティのコンピュータ配布サービスプロバイダによって管理され維持される。コンテントプロバイダは、コンテントをこのエッジキャッシュに記憶することができ、エンドユーザーに近い位置でこれを利用可能にすることができる。他の種類のキャッシュは、反転キャッシュと呼ばれ、これは、エンドユーザーに近いエンティティによって所有され、普通エンドユーザーに近いところに置かれるキャッシュである。他の種類のキャッシュは、サーバー側キャッシュと呼ばれ、これはコンテントプロバイダによって所有されるキャッシュである。さらに他の種類のキャッシュにウェブサーバーキャッシュと呼ばれるものがある。ウェブサーバーキャッシュは、典型的にはウェブサーバーのコンテントをディスクからユーザーへ配布する機械の中にある。しかし、ディスクのアクセスは遅いので、ディスクからのコンテントは、該ウェブサーバー内の他の場所へとコピーすることができる。この場所は、そのコンテントへのアクセスがディスクよりも高速である。これらの記憶装置の場所は、ウェブサーバーキャッシュとして知られている。
【００１１】
再び図２を参照して、もしキャッシュ３６内にページが見つからない、あるいはキャッシュ３６内で期限切れか無効になったと言う理由でキャッシュ３６によってウェブページ要求３２がサービスされないときは、この要求はｅビジネスウェブサーバー３８へと回送される。いくつかのｅビジネスアプリケーションにおいて、カタログページのように頻繁にアクセスされるいくつかのページは、あらかじめ作られて前もってウェブサーバー３８に載せられる。例えば、ウェブサーバーマシン３８は、ＨＴＴＰＤと呼ばれるサブディレクトリを持つことができる。静的なウェブページ（頻繁には変更されない）は、そのサブディレクトリの中に記憶される。もし、それらのページが顧客ブラウザ３０によって要求され、かつＨＴＴＰＤサブディレクトリが最新のウェブページのコピーを含んでいれば、それらのページは、ウェブサーバー３８から顧客ブラウザ３０へとアプリケーションサーバー４０へは決して行かずに直接に送り返されるであろう。
【００１２】
しかし、製品情報や利用可能ページのようなページは、動的であり頻繁に変更される。そのようなページは、典型的にはウェブサーバー３８内に記憶されないが、そのようなページが要求されるときにバックエンドシステムによって動的に作られ、アプリケーションサーバー４０やＤＢＭＳ２６や“ファイルシステム＋ネットワーク”あるいは外部データ源４２を含むことができる。動的に作られたウェブページに対する要求４４が受信されると、ウェブサーバー３８は、その要求をアプリケーションサーバー４０が理解できる新しい要求４６（ＵＲＬと他のパラメータを含む）へと変換するＣＧＩ（ｃｏｍｍｏｎ  ｇａｔｅｗａｙ  ｉｎｔｅｒｆａｃｅ）と呼ばれるサブディレクトリを利用することができる。アプリケーションサーバー４０は、ウェブページ要求３８とウェブサーバー３８からの他のパラメータを受信し、必要な計算を実行し、もし必要なら照会２４０を介してＤＢＭＳ２６にアクセスする。ＤＢＭＳ２６は、それから情報４６をアプリケーションサーバー４０に戻し、そこでは、アプリケーションサーバー４０は、このデータを使ってＨＴＭＬ内に動的に作られたウェブページ４８に合わせる。
【００１３】
理解しておきたいのは、アプリケーションサーバー４０は、ウェブサーバー３８とは異なるマシンでよいか、あるいはウェブサーバー３８と実質的に同じマシンでも良く、ウェブサーバー３８とは異なる機能を実行することである。さらに広く理解しておきたいのは、この明細書において図示されているウェブサーバー３８やアプリケーションサーバー４０やＡＰＩハンドラ（次の図を参照）やＤＢＭＳ２６やコンテント変更監視部品（次の図を参照）は、別々の機能ブロックとして示されているが、これらの機能要素の全ては、一つのサーバーに結合されるか、多数のサーバーに分けることができるということである。さらに、図２と本明細書のいくつかの他の図に図示されるのは、Ｆｉｌｅｓｙｓｔｅｍ  ＋  Ｎｅｔｗｏｒｋ  ４２  と名付けられた機能ブロックである。理解しておきたいのは、このブロック４２は、ＤＢＭＳブロック２６を一般化したものであり、ＤＢＭＳおよび／あるいは他のデータの外部ソースを含んでも良いということである。
【００１４】
プログラムがアプリケーションサーバー４０上で実行されるとき、一つの照会２４０をＤＢＭＳ２６へ発し、その結果４６を受け取り、さらに実行を続け、要求されたウェブページ４８を作るのにさらに情報が必要であれば、次の照会２４０を発して追加情報４６を受け取ることができる。例えば、航空便予約情報システムの例において、第１の照会２４０は、特定の日における利用可能な便を決定するのに発せられ、次の照会２４０は、それらの便の価格を決定するのに発せられる。そうするうちに、異なるＤＢＭＳ２６あるいは４２にアクセスする必要が出てくるかも知れない。一旦、アプリケーションサーバー４０が動的に生成されるウェブページ４８を組み立ててしまうと、そのウェブページは、参照番号４８で示されるようにウェブサーバー３８に送り返される。ウェブサーバー３８は、それから、受け取ったウェブページを参照番号５０で示すようにウェブブラウザ３０へと送り返す。
【００１５】
追加すると、ウェブサーバー３８が、この動的に作られたページ５０をウェブブラウザ３０に送るとき、このページをキャッシュ３６に記憶することもできる。他のユーザーが同じ情報を要求したとき、キャッシュ３６内の動的に作られたページ５０に対して、ウェブページ５０は、キャッシュ３６からエンドユーザーへ直接に配布されることができ、このときもしウェブページがバックエンドシステムによって動的に作られるべきものであったなら、必要であろう処理時間の追加は無い。
【００１６】
しかし、動的に作られたウェブページは、しばしば変更され、そしてキャッシュ３６内あるいはウェブサーバー３８内の記憶装置は、ビジネスがエンドユーザーに最新の情報を渡す事にかかっているような、あるｅビジネスウェブサイトにとって問題である。しかし、非常に最新のウェブページ情報を得ることは、キャッシュ３６やウェブサーバー３８やアプリケーションサーバー４０やＤＢＭＳ２６，４２が異なるマシン内にあり、それぞれ独立した存在であることから難しい。さらに、キャッシュ３６あるいはウェブサーバー３８内に記憶されたウェブページが最新のものであることを保証するのに、独立に動作するこれらのマシン間には、少ししかあるいは全く同格なものがない。
【００１７】
キャッシュ３６内のウェブページが新しいものである確率を高める一つの方法は、ウェブサーバー３８を通じて定期的にページをリフレッシュすることである。しかし、これは、ウェブサーバー３８やアプリケーションサーバー４０やＤＢＭＳ２６への不必要な多くの要求となり、定期的なリフレッシュをもってしても、キャッシュ３６内のウェブページは新しいものであるという保証はできない。キャッシュ３６内に記憶されたデータが新しいことを保証するのが難しいことから、キャッシュ３６内に記憶される重要な動的ウェブページは、典型的には、即刻削除されるように設定される。代わりに、そのようなウェブページは、キャッシュ不可能として指定される。
【００１８】
こうして、動的なウェブページに対する典型的な要求は、ウェブサーバー３８やアプリケーションサーバー４０やＤＢＭＳ２６あるいは外部データソース４２を通り、最後に、生成されたウェブページは、エンドユーザー２８のところへ送り返される。このネットワークを巡るための時間には、バックエンドシステム（すなわち、アプリケーションサーバー４０とＤＢＭＳ２６と外部データソース４２）が、現在のデータを供給するのに必要な計算を実行するための時間が含まれている。その時間は１０〜２０秒の間であり、非常に遅い。たとえ、いくつかの動的なウェブページが１時間に１回しか変化しなかったとしても、変化する可能性があるという事実は、ビジネスがコンテントとキャッシュ不可能にするか、即刻削除するように設定するのに充分であろう。こうして、たとえ、変更しようとするデータの前に多くの要求があったとしても、従来のシステムは、バックエンドシステムでの処理の実行を併せて、それらの要求にネットワークを巡らせるであろう。
【００１９】
【課題を解決するための手段】
本発明の請求項１は、ウェブページを記憶するための少なくとも一つの第１のメモリと、ウェブページを生成するのに使用するデータを記憶するための少なくとも一つの第２のメモリを含むメモリ管理システムと、を有するシステムであって、上記メモリ管理システムは、上記の少なくとも一つの第２のメモリ内に記憶されたデータのうち変更されたデータを識別することができ、かつ、上記の少なくとも一つの第２のメモリへの全ての処理を順番に含む少なくとも一つのデータベースのログを維持することができ、上記少なくとも一つの第２のメモリ内に記憶されたデータへの変更に基づいて、上記少なくとも一つの第１のメモリに記憶されたウェブページを更新するためのシステムにおいて、上記システムは、さらに、少なくとも一つのサーバーを有し、上記少なくとも一つのサーバーは、上記少なくとも一つの第１のメモリに記憶された各ウェブページと、当該ウェブページを生成するのに使用される上記少なくとも一つの第２のメモリ内に記憶されたデータと、の間のウェブページ−データ関係を維持し、上記メモリ管理システムからどのデータが変更されたかを識別する情報を受信し、受信した変更されたデータを識別する情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定し、上記変更されたデータに関係あるウェブページを含む上記少なくとも一つの第１のメモリに対して当該ウェブページを更新するための更新命令を伝えるようにプログラムされたことを特徴とする。
【００２０】
【発明の効果】
従って、キャッシュやウェブサーバ内に記憶されるデータをＤＢＭＳや外部データソース内に記憶されるデータと同期を取る、ウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法を提供するのが、本発明の実施形態の利点である。
【００２１】
ＤＢＭＳあるいは外部データソース内のデータが変化したときに、そのデータを利用するキャッシュあるいはウェブサーバー内に記憶されるウェブページが無効化されるような、ウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法を提供するのが、本発明の実施形態のさらなる利点である。
【００２２】
ＤＢＭＳあるいは外部データソース内のデータが変化したときに、そのデータを利用するキャッシュあるいはウェブサーバー内に記憶されるウェブページがリフレッシュされるような、ウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法を提供するのが、本発明の実施形態のさらなる利点である。すなわち、キャッシュ等に記憶されるウェブページは、その構成要素となる元のデータが変化すると、リフレッシュされ、変化後のデータに基づいた最新のウェブページを再度キャッシュ等に記憶することができる。その結果として、エンドユーザは、たとえ動的に作られたページでも、フロントエンドキャッシュあるいはエッジキャッシュから得ることができる。
【００２３】
多くのコンテントの要求がキャッシュから出され得るので、バックエンドシステムへの負荷が軽減され得るような、ウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法を提供するのが、本発明の実施形態のさらなる利点である。
【００２４】
これらの利点及び他の利点は、ＤＢＭＳ内あるいは外部のデータソース内に記憶されるデータへの変更に基づいて、キャッシュあるいはウェブサーバー内に記憶されるウェブページを更新するためのシステムによって得られる。更新には、ウェブページの無効化とリフレッシュが含まれうる。記憶されたウェブページを更新するためのシステムは、ウェブページを生成するのに使用されるデータを記憶するためのＤＢＭＳを持つ、より大きなシステムの一部であってよい。ＤＢＭＳは、データベース内に記憶される変更済みデータを識別することができる。
【００２５】
記憶されたウェブページを更新するためのシステムは、一つあるいは二つ以上のサーバーからできており、これは、記憶済みのウェブページと記憶済みのデータとの間の関係を維持し、データベース管理システムからの変更済みデータの同一性を受信するようにプログラムされている。加えて、サーバーは、識別された変更済みデータと維持されている関係とから、記憶済みのウェブページのいずれが識別済みの変更済みデータと関係があるかを決定する事ができる。さらに、サーバーは、記憶済みウェブページを更新する目的で、識別済みの変更済みデータと関係する、記憶済みウェブページを含むキャッシュに更新命令を送ることができる。
【００２６】
本発明の実施形態のこれらのそして他の目的と特徴と利点は、図面と添付の請求の範囲を読めば、以下の本発明の実施形態の詳細な説明から、当業者には明らかであろう。
【００２７】
【発明の実施の形態】
好ましい実施形態に関する以下の説明において、本明細書の一部を形成する添付図面について言及し、かつ、その内容を、これらの図面において本発明を実施できる特定の例示的実施形態によって示す。本発明の好ましい実施形態の範囲から逸脱することなく、他の実施形態を利用でき、かつ、構造的変更がなされ得ることが理解されるべきである。
【００２８】
ウェブ性能は、コンテントプロバイダ間の区別化のキーポイントである。主要なウェブサイト内におけるクラッシュやスローダウンは、会社が高速のウェブトラフィックを処理する場合に直面する問題点を明示する。インターネットのバックボーン技術が発展するにつれて、サービス管理領域における革新は、帯域およびウェブコンテントの検索応答時間を改善してきた。しかしながら、インフラストラクチャに対するこれらの改善は、インターネット内の全ての地点におけるトラフィック問題を解決することができない。ゲートウェイのボトルネックは、１ページのデータに対して約１０秒以上のアクセス時間という結果となり得る。ゲートウェイのボトルネックのために、また、エンドユーザーからウェブサイトへのインターネット経路に伴う多くの不確実性が存在するので、コンテント配布ネットワークまたはシステムが現在も開発されている。
【００２９】
基本的に、コンテント配布システムは、２つの主要な目的（一方は、ロードのバランスを達成することであり、他方は、応答およびアクセス時間を短縮することである）のために設計される。本明細書において説明される本発明の実施形態は、コンテント配布システムを介して応答およびアクセス時間を短縮する。前記コンテント配布システムは、有効なサーバーへユーザーを向け直すために、インテリジェントキャッシュおよびプロキシサーバーを用いる。前記有効なサーバーとは、所望のコンテントを有し、かつ、ユーザーに近いかまたはユーザーにとって容易にアクセス可能であるサーバーである。向け直されたトラフィックのうちの幾つかによって、トラフィックサージは減少し、かつ、エンドユーザーは、より高速の応答時間からの恩恵を受ける。
【００３０】
本発明の実施形態は、ウェブサーバー内の他に、キャッシュ内で動的に発生されたウェブコンテントをインテリジェントリフレッシュするための方法およびシステムを有する。これらの方法およびシステムアーキテクチャについては、キャッシュ内の全てのコンテントがアプリケーション内およびＤＢＭＳ内のコンテントと一致することを確実にするために、静的コンテントのリフレッシュに適用することもできる。
【００３１】
ウェブコンテントのインテリジェントキャッシュおよびリフレッシュ
＜インテリジェントキャッシュおよびリフレッシュ機構１＞
図３は、本発明の好ましい実施形態によるインテリジェントウェブページキャッシュおよびリフレッシュ機構１０を例示する。図３に示すように、キャッシュ５４に記憶されていないかまたはキャッシュ５４において無効なウェブページをエンドユーザー５２が要求すれば、該要求５６がウェブサーバー５８上に渡される。エンドユーザーによるウェブページ要求６０がウェブサーバー５８により受信されると、ウェブサーバー５８は、要求された各々のウェブページ６６のための要求時間６２と配布時間６４とを記憶するログ６８を保持する。例えば、ログ６８は、前記要求に関するＵＲＬと、このような要求の到着に関するタイムスタンプと、ウェブサーバー５８へのウェブページの返信に関するタイムスタンプとを有することができる。したがって、図３の例においては、ウェブサーバーログ６８は、時刻０と時刻５との間にＵＲＬ１に関する要求が処理されたことを示す。また、時刻４と時刻６との間に、ＵＲＬ２に関する要求が処理されたことになる。ウェブサーバー５８が要求６０を受信した後に、該ウェブサーバー５８は、該要求６０を、幾つかのオプションパラメータとともにアプリケーションサーバー７０へ送信する。
【００３２】
アプリケーションサーバー７０がウェブサーバー５８からの要求７２を受信した後に、該アプリケーションサーバー７０は、該要求７２を処理し、かつ、必要に応じて、下方にあるＤＢＭＳ７４へ（照会７６を介してＤＢＭＳ７４へ）アクセスする。ＤＢＭＳ７４がアプリケーションサーバー７０から１つまたは複数の照会７６を受信すると、該ＤＢＭＳ７４は、いつ照会８２がＤＢＭＳ７４上で実行されたのかに関するタイムスタンプ８０を記憶するためのデータベース照会ログ７８を保持することができる。例えば、図３において、ＳＱＬ１として識別されるＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ  ｑｕｅｒｙ  ｌａｎｇｕａｇｅ）がＴ＝１において実行され、ＳＱＬ２がＴ＝２において実行され、ＳＱＬ３がＴ＝３において実行され、かつ、ＳＱＬ４がＴ＝４．５において実行されたことになる。
【００３３】
アプリケーションサーバー７０が、１つのまたは多数のＤＢＭＳ７４に対する照会７６に制約されるものではないことが理解されるべきである。アプリケーションサーバー７０は、幾つかの必要な外部呼、ＡＰＩ呼、またはｈｔｔｐ要求８４を、他のファイルシステム、ＤＢＭＳ、またはサーバー８６へ発することもできる。概して、本明細書における説明の大部分がＤＢＭＳ７４を参照して与えられているが、本発明の実施形態においては、この説明における全ての図面において”Ｆｉｌｅ  ｓｙｓｔｅｍ  ＋  ｎｅｔｗｏｒｋ”というラベルを付されたブロックにより表される外部データソースに対して、アクセス８４がなされ得ることが理解されるべきである。したがって、いつ処理９２が外部データソース８６上で実行されたのかに関するタイムスタンプ９０を記憶できる処理ログ８８についても、データベース照会ログ７８と同様に維持することができる。
【００３４】
本発明の好ましい実施形態において、コンテント配布サービスプロバイダ（本明細書において、例示的目的のみのためにＣａｃｈｅＰｏｒｔａｌサーバーとして例示される）は、ウェブサーバーログ６８と、データベース照会ログ７８と、任意に処理ログ情報８８とを受信する。この情報によって、ＣａｃｈｅＰｏｒｔａｌ９４は、ＵＲＬ／関連処理マッピングテーブル９６を発生しかつ維持することができ、該ＵＲＬ／関連処理マッピングテーブル９６は、ＵＲＬ９８と処理または照会１００との関連を記憶する。例えば、ウェブサーバーログ６８は、ＵＲＬ１に関する要求が時刻Ｔ＝０と時刻Ｔ＝５との間に発生することを示すので、ＳＱＬ１，２，３は、ＵＲＬ１に関する要求と結びついて行われた可能性が高い。しかしながら、ＵＲＬ１，２は両方とも時刻Ｔ＝４と時刻Ｔ＝５との間に処理されるので、どちらの要求が、時刻Ｔ＝４．５において発生したＳＱＬ４に関連しているのかは不明である。（ウェブサーバーを多重処理またはマルチスレッドすることができ、このことが、ウェブページに関する多数の要求を同時に処理することを可能にすることが理解されるべきである。）したがって、ＵＲＬ／関連処理マッピングテーブル９６において、ＵＲＬ１とＳＱＬ１〜４との関連が生じ、かつ、ＵＲＬ２とＳＱＬ４との関連が生じる。同様に、ＵＲＬ／関連処理マッピングテーブル９６において、他の関連が生じ、かつ、記憶される。
【００３５】
コンテント変更モニター部品１０４（本明細書において後述する）は、ＤＢＭＳ記録と照会との関連を維持するか、または、該関連にアクセスする必要がある。さらに、コンテント変更モニター部品１０４は、外部データソース内またはＤＢＭＳ内のデータに対する変更を監視しかつ検出する。データの変更が検出されると、コンテント変更モニター部品１０４は、その既知の関連から、変更されたデータによりどの照会または処理が影響を受けるのかを決定することができる。例えば、照会ＳＱＬ１，２がＤＢＭＳ７４内における組１，２のアクセスという結果となると仮定する。これらの組の１つにおける任意のデータが変更されれば、この変更は、コンテント変更モニター部品１０４により検出され、かつさらに、該コンテント変更モニター部品１０４は、変更されたデータにより照会ＳＱＬ１，２が影響を受け得ると決定する。結果的に、これらの照会を用いて発生されたウェブページは廃れたものとなり得る。好ましい実施形態においては、潜在的に影響を受けた照会１０２が、ＣａｃｈｅＰｏｒｔａｌ９４に対して呈される。
【００３６】
次に、前記ＣａｃｈｅＰｏｒｔａｌ９４は、どのＵＲＬが前記潜在的に影響を受けた照会１０２に関連するのかを決定するために、ＵＲＬ／関連処理マッピングテーブル９６を用いる。次に、これらのＵＲＬに関連するウェブページについては、無効にするかまたはリフレッシュする必要がある。コンテント配布サービスプロバイダとして、ＣａｃｈｅＰｏｒｔａｌ９４は、ウェブページがどこに記憶されたのかに関する痕跡を保持する。これにより、ウェブページをリフレッシュするかまたは無効にすることが必要となったときに、ＣａｃｈｅＰｏｒｔａｌ９４は、無効化（またはリフレッシュ）要求（またはメッセージ）２４２を適切な位置へ送信する。
【００３７】
リフレッシュ要求と無効化要求との違いは、リフレッシュ要求によって、キャッシュ５４がウェブサーバー５８から新たなページを要求することである。次に、ウェブサーバー５８は、そのバックエンドシステムを用いて、要求されたウェブページを検索し、かつ、該ウェブページをキャッシュ５４内に戻して記憶する。あるいはまた、アプリケーションサーバー７０、ＤＢＭＳ７４、またはＣａｃｈｅＰｏｒｔａｌ９４により、新たなページを準備することもできる。これに対し、キャッシュ５４内のウェブページを無効にすることにより、該ウェブページは、単に、無効、期限切れ、または、削除予定というタグを付され、新たなウェブページのために何の要求も行われない。代わりに、新たなウェブページは、次のエンドユーザーによりその無効なウェブページに関する要求がなされるまで発生されない。エンドユーザー５２が無効なウェブページを要求すると、該エンドユーザーの要求は、向け直されたウェブページ要求をウェブサーバー５８に対して発生するが、このことは、処理するのに長い時間がかかることがある。しかしながら、それと同じウェブページを要求する後続ユーザーが多数存在すれば、この長いアクセス時間は全体として問題ではない。最初の要求を行ったエンドユーザーが長いアクセス時間を我慢する一方で、後続の要求が、最初のエンドユーザーの要求の恩恵を受けることになる。その理由は、これらの後続の要求が、キャッシュ５４から新たなコンテントに直接的にアクセスできるためである。したがって、全体として、無効化方法は、多数のエンドユーザー５２にとって好ましい。
【００３８】
ウェブページを無効にすべきかまたはリフレッシュすべきかに関する決定は、とりわけ、ウェブページがアクセスされる頻度とシステムリソースとの関数である。例えば、ウェブページが稀にしかアクセスされなければ、ウェブページをリフレッシュする意味がない。一定期間にわたってウェブページを何度もリフレッシュする必要はなく、かつ、該期間の間に該ウェブページに関する要求が何も発生しなければリソースの浪費となる。このような場合には、ウェブページをリフレッシュする前に新たな要求まで待機することが有益であり得る。これに対し、ウェブページに対して頻繁なアクセスが予測されれば、直ちにコンテントをリフレッシュすることが有益であり得る。その理由は、このようなリフレッシュは、近い将来に必要とされる可能性が高いためである。
【００３９】
リフレッシュが最適な代替案ではあり得ない他の理由は、キャッシュが、しばしば置き換え計画を用いることである。すなわち、キャッシュは限られた量のコンテントを記憶するだけであり、かつ、多量のコンテントがキャッシュに記憶されることになれば、キャッシュは、記憶されたオブジェクトのうちどれを捨てて新たなコンテントに置き換えることができるのかを決定する必要がある。キャッシュは、最も稀にしか用いられないコンテントまたは最近では最も利用されていないコンテントを、該キャッシュから捨てるように決定することができる。しかしながら、キャッシュ内のウェブページを、該ウェブページに関連するデータが変更される度に自動的にリフレッシュすることにより、キャッシュ内においてリフレッシュされたウェブページは、常に最近用いられたように見える。これにより、ウェブページは、たとえエンドユーザーにより稀にしかアクセスされなくても、キャッシュから捨てられることはない。
【００４０】
リフレッシュメッセージの代替案として、ＣａｃｈｅＰｏｒｔａｌ９４からウェブサーバー５８へ直接的にコマンドを送信することができ、このことは、ウェブサーバー５８には、エンドユーザーから目標とされたウェブページに関する要求であるかのように見える。このコマンドによって、ウェブサーバー５８は、そのバックエンドシステムを用いて、新たに発生された動的ウェブページを取ってくる。キャッシュ５４が遠隔的に配置されれば、ウェブページをリフレッシュするようにキャッシュに命令することは不適切に遅くなり得るので、この代替案はより効率的であり得る。さらに、キャッシュ５４については、異なるエンティティが所有することができ、または、該キャッシュ５４は、コンテントを記憶する以外の処理能力をほとんど持たないキャッシュであってもよい。
【００４１】
この説明に関する多くの図においてキャッシュブロック５４が例示されかつ説明されているが、静的および動的に作られたウェブページについては必ずしもキャッシュ５４に記憶されるとは限らず、追加的にまたは他にウェブサーバー５８に記憶できることが理解されるべきである。無効とすべきまたはリフレッシュすべきウェブページがウェブサーバー５８に記憶されれば、ＣａｃｈｅＰｏｒｔａｌ９４は、該ウェブページを無効としてマーキングするウェブサーバー５８に要求を向けるかまたは新たなウェブページを取ってくることができる。あるいはまた、ＣａｃｈｅＰｏｒｔａｌ９４は、新たなウェブページを発生するために、アプリケーションサーバー７０へ直接的に要求を送信することができる。
【００４２】
本明細書における説明がＣａｃｈｅＰｏｒｔａｌ９４に言及しているが、任意のコンテント配布システムを用いることもできることが理解されるべきである。
【００４３】
本発明の好ましい実施形態によれば、コンテント変更モニター部品１０４は、ウェブサーバーログ６８へアクセスすることができ、かつこれにより、ＵＲＬ／関連処理マッピングテーブル９６を作り出すことができ、かつ、どのウェブページを無効にすべきかまたは維持すべきかを決定することができる。コンテント変更モニター部品１０４が、さらに、キャッシュ５４または他のウェブサーバー５８に記憶されたコンテントの位置を識別すれば、該コンテント変更モニター部品１０４は、無効化メッセージまたはリフレッシュメッセージをその位置へ送信することさえできる。したがって、コンテント変更モニター部品１０４またはＣａｃｈｅＰｏｒｔａｌ９４のいずれかが、無効化メッセージまたはリフレッシュメッセージを送信することが可能となり得る。さらに、コンテント配布サービスプロバイダの機能性とコンテント変更モニター部品１０４の機能性（本明細書において、より詳細に後述する）とを同じサーバーに合併できることもまた理解されるべきである。
【００４４】
前述したように、前記アプリケーションサーバー７０、ＤＢＭＳ７４、外部データソース８６、ウェブサーバー５８、キャッシュ５４は、独立型の構成要素であることがあり、したがって、これら全てのシステム上におけるクロックを同期させることはできない。これらのシステムを同期させるためには、既知の照会または処理を備えた特定のＵＲＬ要求をウェブサーバー５８へ発することができる。ウェブサーバー５８内、アプリケーションサーバー７０内、ＤＢＭＳ７４内、または、外部データソース内におけるログファイルのタイムスタンプを検査することができる。この情報に基づいて、全てのシステム間の時間差を計算することができ、かつ、適切な調整を行うことができる。
【００４５】
＜インテリジェントキャッシュおよびリフレッシュ機構２＞
エンドユーザーが最新のウェブページにアクセスできることを確実にする鍵は、特定のデータと要求されたウェブページのＵＲＬとの関連を理解することである。ウェブサーバーを全体的に見ると、該ウェブサーバーは、ウェブページのＵＲＬを内部に有する要求をエンドユーザーから受信する。これにより、ウェブサーバーは、要求されたウェブページを識別する。しかしながら、ウェブサーバーは、どのデータベースの照会が、特定の要求されたウェブページに関連するのかを識別することができない。これに対し、ＤＢＭＳは、アプリケーションサーバーから照会を受信するが、これらの照会は、その内部にＵＲＬ情報を埋め込まれていない。純粋に機能的な観点から見て、このことは、どのウェブページが特定のデータ片を必要としているのかをデータベース管理システムが識別する必要がないので意味をなす。ＤＢＭＳは、単に、データに関する要求を照会形式で受信し、かつ、結果をアプリケーションサーバーへ返信する。このことは、幾分問題を呈するが、ウェブサーバーがＵＲＬを識別する一方でデータベース管理システムが照会を識別するので、該ＵＲＬを該照会に明確にリンクさせるものは何も存在しない。
【００４６】
この関連を構成する鍵は、アプリケーションサーバーにある。万一ウェブサーバーがアプリケーションサーバーへ要求を送信すれば、アプリケーションサーバーは、ウェブサーバーからの要求から、要求されたページのＵＲＬを識別する。アプリケーションサーバーは、幾つかの計算を行うことができ、次に、どの照会をＤＢＭＳに対して構成すべきかを決定することができる。これにより、ＵＲＬおよびＤＢＭＳ照会の関連は、アプリケーションサーバーの動作において明白となる。
【００４７】
それでもなお、ＵＲＬおよびデータベース照会の関係が明らかにアプリケーションサーバーの動作から得られるので、アプリケーションサーバーがＵＲＬ／関連処理マッピングテーブルを作り出しかつ維持することが可能である。したがって、図４において、本発明の他の実施形態１０６が例示されており、この実施形態においては、アプリケーションサーバー１０８は、要求されたＵＲＬおよびＤＢＭＳ  ＳＱＬ呼と外部呼との間のマッピングを記憶するＵＲＬ／関連処理マッピングテーブル１１０を保持する。アプリケーションサーバーによるＵＲＬ／関連処理マッピングテーブルの作成は、図５に例示されている。
【００４８】
いったん、コンテント変更モニター部品１１２が、ＤＢＭＳの変更を検出し、関連する照会を決定し、かつ、ＣａｃｈｅＰｏｒｔａｌ１１６に通知１１４を行うと、ＣａｃｈｅＰｏｒｔａｌ１１６は、ＵＲＬ／関連処理マッピングテーブル１１０にアクセスして、照会に関連するＵＲＬを識別し、かつ、キャッシュ１１８内のページを無効にするかまたはリフレッシュする。同様に、ページがウェブサーバー１２０内に存在すれば、ＣａｃｈｅＰｏｒｔａｌ１１６は、アプリケーションサーバー１０８に新たなページを発生するように要求することができ、または、最新のデータを有する新たなページを取ってくるかまたは要求するために、アプリケーションサーバー１０８に、ウェブサーバー１２０に対して照会または要求を発するように要求することができる。
【００４９】
＜インテリジェントキャッシュおよびリフレッシュ機構３＞
アプリケーションサーバーが照会を発するときに、該アプリケーションサーバーは、ＡＰＩ形式の"直接的な呼"ＳＱＬexecストリングであってもよい。このストリングまたは照会については、アプリケーションサーバー内のプログラムが実行されている間に発することができる。結局は、このプログラムがアプリケーションサーバー内で実行されている間に、幾つかの照会をこのストリング形式で発することができる。このＳＱＬexec照会は、照会ストリングおよびハンドラカーソルという２つのパラメータを有する。照会ストリングは照会それ自体を識別し、その一方で、ハンドラカーソルは、ＤＢＭＳ内または外部ソース内に配置された結果を指すポインタである。ＵＲＬは必ずしもＤＢＭＳに渡される照会内パラメータの１つではない、ことが理解されるべきである。
【００５０】
しかしながら、図６に例示した本発明の他の実施形態１２２において、このような“直接的な呼”は、ＣａｃｈｅＰｏｒｔａｌＡＰＩ呼１２４に置き換えられる。図６の実施形態において、アプリケーションサーバー１２６は、ＣａｃｈｅＰｏｒｔａｌＡＰＩ呼１２４を実行し、該ＣａｃｈｅＰｏｒｔａｌＡＰＩ呼１２４は、図６に示すように、パラメータの一部としてＵＲＬ情報を有する。ＣａｃｈｅＰｏｒｔａｌＡＰＩ呼１２４は、ＣａｃｈｅＰｏｒｔａｌＡＰＩハンドラ１２８により実行され、該ＣａｃｈｅＰｏｒｔａｌＡＰＩハンドラ１２８は、ＵＲＬ情報を除去し、かつ次に、ＳＱＬｅｘｅｃストリングと等価なもの１３０を、ＤＢＭＳ１３２または外部ソース１３４へ送信する。ＣａｃｈｅＰｏｒｔａｌＡＰＩハンドラ１２８は、さらに、ＵＲＬ／関連処理マッピングテーブル１３６を維持する。ＣａｃｈｅＰｏｒｔａｌＡＰＩハンドラ１２８によるＵＲＬ／関連処理マッピングテーブルの作成は、図７に例示されている。
【００５１】
いったん、コンテント変更モニター部品１３８が、ＤＢＭＳの変更を検出し、関連する照会を決定し、かつ、ＣａｃｈｅＰｏｒｔａｌシステム１４２に通知１４０を行うと、ＣａｃｈｅＰｏｒｔａｌシステム１４２は、ＵＲＬ／関連処理マッピングテーブル１３６にアクセスして、照会に関連するＵＲＬを識別し、かつ、キャッシュ１４４内のページを無効にするかまたはリフレッシュする。同様に、ページがウェブサーバー１４６内に存在すれば、ＣａｃｈｅＰｏｒｔａｌ１４２は、アプリケーションサーバー１２６に、新たなページを発生するように要求することができ、または、該アプリケーションサーバー１２６は、最新のデータを有する新たなページを取ってくるように、ウェブサーバー１４６に対して照会または要求を発することができる。
【００５２】
＜インテリジェントキャッシュおよびリフレッシュ機構４＞
しかしながら、図８に例示した本発明の他の実施形態１４８において、アプリケーションサーバーによる“直接的な呼”は、ＣａｃｈｅＰｏｒｔａｌにより記憶された手順１５０、または、ＣａｃｈｅＰｏｒｔａｌによりサポートされた他の記憶された手順の実行に置き換えられ、これらの手順は、アプリケーションサーバー、ＤＢＭＳ、または外部ソースにより実行できる関数を有する。記憶された手順は、ある一定の目的に従いかつＤＢＭＳ１５４内のソースコードとなる共通の関数である。ＣａｃｈｅＰｏｒｔａｌにより記憶された手順は、アプリケーションサーバー１５２、ＤＢＭＳ１５４、または外部ソース１５６のために書き込まれ、かつ、これらにより実行される。図８の実施形態において、アプリケーションサーバー１５２は、ＣａｃｈｅＰｏｒｔａｌにより記憶された手順１５０を実行し、該ＣａｃｈｅＰｏｒｔａｌにより記憶された手順１５０は、パラメータの１つとしてＵＲＬ情報を有する。前記記憶された手順は、照会１５８または処理１６０を、関連するＤＢＭＳ１５４または外部ソース１５６へ発する。ＤＢＭＳ１５４または外部ソース１５６からのデータは、記憶された手順１５０を介してアプリケーションサーバー１５２へ戻される。
【００５３】
ＣａｃｈｅＰｏｒｔａｌにより記憶された手順１５０は照会およびＵＲＬ情報の両方を有するので、該記憶された手順は、データベース照会ログ１６２および／または処理ログ１６４を維持し、これらのログは、ＣａｃｈｅＰｏｒｔａｌ１６６によりアクセスされて、ＵＲＬ／関連処理マッピングテーブル１６８を作り出す。ＣａｃｈｅＰｏｒｔａｌによるＵＲＬ／関連処理マッピングテーブルの作成は、図９に例示されている。図６においては、ＣａｃｈｅＰｏｒｔａｌＡＰＩハンドラが、照会がＤＢＭＳまたは外部ソースのいずれかに分割される前に、これらの照会をインターセプトしたことを特筆しておく。しかしながら、図８においては、要求は、ＤＢＭＳ１５４または外部ソースのいずれかに分割されるが、インターセプトされない。したがって、ＣａｃｈｅＰｏｒｔａｌ１６６により、別個のログ１６２，１６４は書き込まれ、かつ次に、合併される必要がある。
【００５４】
いったん、コンテント変更モニター部品１６８が、ＤＢＭＳの変更を検出し、関連する照会を決定し、かつ、ＣａｃｈｅＰｏｒｔａｌシステム１６６に通知１７０を行うと、ＣａｃｈｅＰｏｒｔａｌシステム１６６は、ＵＲＬ／関連処理マッピングテーブル１６８にアクセスして、照会に関連するＵＲＬを識別し、かつ、キャッシュ１７２内のページを無効にするかまたはリフレッシュする。同様に、ページがウェブサーバー１７４内に存在すれば、ＣａｃｈｅＰｏｒｔａｌ１６６は、アプリケーションサーバー１５２に、新たなページを発生するように要求することができ、または、該アプリケーションサーバー１５２は、最新のデータを有する新たなページを取ってくるようにウェブサーバー１７４に対して照会または要求を発することができる。
【００５５】
＜インテリジェントキャッシュおよびリフレッシュ機構５＞
図１０に例示した本発明の他の実施形態において、アプリケーションサーバー１７６は、アプリケーションサーバープロキシ２００により“包囲”される。好ましい実施形態においてはＣａｃｈｅＰｏｒｔａｌサーバー１７８の一部であるアプリケーションサーバープロキシ２００は、ウェブサーバー１８２から要求１８０を受信し、かつ、要求１８４をアプリケーションサーバー１７６へ回送する。さらに、アプリケーションサーバープロキシ２００は、ＤＢＭＳ１９４または外部ソース１９６から結果１９０，１９２を受信する他に照会１８６または外部要求１８８を発するために、アプリケーションサーバー１７６用のプロキシとして作用する。アプリケーションサーバープロキシ２００は、さらに、結果をＤＢＭＳまたは外部ソース１９８からアプリケーションサーバー１７６へ回送する。
【００５６】
したがって、ある意味では、前記アプリケーションサーバープロキシ２００は、アプリケーションサーバー１７６への入力に従い、かつ、該アプリケーションサーバー１７６の出力を監視する。こうすることにより、アプリケーションサーバープロキシ２００は、要求されたページのＵＲＬを、該ＵＲＬがアプリケーションサーバー１７６内に入ったときに決定し、かつ、アプリケーションサーバー１７６がＤＢＭＳ１９４または外部ソース１９６を呼び出したときにＵＲＬに関連づけることができる特定の照会１８６を決定する。したがって、アプリケーションサーバープロキシ２００は、その時のＵＲＬと照会との関係を識別する。アプリケーションサーバー１７６による照会および外部呼の他に該アプリケーションサーバー１７６への要求をインターセプトする際に、アプリケーションサーバープロキシ２００は、要求されたＵＲＬおよびＤＢＭＳ  ＳＱＬ呼と外部呼との間におけるマッピング２０２を作り出すことができる。
【００５７】
図１０の実施形態の利点は、アプリケーションサーバープロキシ２００が、アプリケーションサーバー１７６を変更してＣａｃｈｅＰｏｒｔａｌＡＰＩ呼を発生させる必要なしにＵＲＬ／関連処理マッピングテーブル２０２を発生できることである。したがって、この代替的実施形態による利点は、アプリケーションサーバー１７６の所有者とＣａｃｈｅＰｏｒｔａｌ１７８との間において必要とされる協力が少なくて済むことである。この機構については、ネットワークを通過するメッセージとストリングとに従うことができる“スニッファ（ｓｎｉｆｆｅｒ）”のようなハードウェア装置を用いて実施することもできることを特筆しておく。この機構については、本明細書において前述した機構１とともに用いることができることも特筆しておく。
【００５８】
コンテント変更監視
＜コンテント変更監視機構１＞
図１１は、本発明の実施形態によるコンテント変更モニター部品２０４を例示する。図１１の実施形態において、ＤＢＭＳ２０８に発せられた照会２０６または外部ソース２１２に発せられた処理２１０は、コンテント変更モニター部品へも伝達される。次に、コンテント変更モニター部品２０４は、各々の照会２０６または処理２１０に関するビュー定義２１４を作り出し、該ビュー定義２１４は、これら特定の照会または処理に関連するデータを識別するための基準を確立する。次に、ビュー定義２１４は、前記照会または処理に関連するビューテーブル２１６を発生するために用いられ、該ビューテーブル２１６は、前記照会または処理に関連する全てのデータに対するポインタのリストである。
【００５９】
例えば、住宅管理用途のためのＤＢＭＳが、家および代理店の属性リストである下記の表１と表２とを有すると仮定する。
【表１】
0003620448.tif 000002
【表２】
0003620448.tif 000003
【００６０】
図１１を参照すると、この住宅用途に頻繁に発せられる照会ＳＱＬ１（下記参照）が、コンテント変更モニター部品２０４により受信されると仮定する。概して、照会は、“［照会条件のリストが満たされる］場合の［データソース］から［データまたは属性］を選択する”という形式である。本例において、ＳＱＬ１は、以下のように定義される。
【表３】
0003620448.tif 000004
【００６１】
ＳＱＬ１がコンテント変更モニター部品２０４により受信された後に、ビューテーブルを作り出すための文（この文は、ビュー定義２１４を有する）が実行される。本例において、文は以下の通りである。
【表４】
0003620448.tif 000005
【００６２】
この文は、照会ＳＱＬ１の基準（ビュー定義）を満たす表１における入力に対するポインタのリストを有するビューテーブル２１６を作り出す。この例において、ＳＱＬ１のビュー定義は、ｈｏｕｓｅ．ａｇｅｎｔｉｄ  ＝  ａｇｅｎｔ．ｉｄ，  ｈｏｕｓｅ．ｐｒｉｃｅ＜５０，  ａｎｄ  ｈｏｕｓｅ．ｐｒｉｃｅ＞２０  という特定の代理店および指定された価格範囲である。この例において、ＶＩＥＷ１として定義されるビューテーブル２１６が作り出される。さらに、ビューログ２１８は、各々のビューテーブル２１６のために維持され、該ビューテーブル２１６に対する全ての処理の記録を保持する。
【００６３】
各々のビューテーブルの入力（ポインタ）は、ビューテーブル２１６とその関連データとの関係を確立する。したがって、特定のデータを更新するためのコマンドをＤＢＭＳ２０８が受信すれば、データを更新させた前後のいずれかに、ＤＢＭＳ２０８は、さらに、データ更新により潜在的に影響を受けるあらゆるビューテーブル２１６を識別する。次に、ＤＢＭＳ２０８は、適切なビューテーブル２１６を無効にするかまたは維持する。
【００６４】
無効化のために、ＤＢＭＳ２０８は、特定のビューテーブル２１６を無効としてマーキングする。このことについては、ビューテーブル２１６の属性を設定し、“無効”処理をビューログ２１８に記録することなどにより行うことができる。さらに、このシステムは、ビューテーブル２１６の“最後に変更された日付”属性を更新することもできる。しかしながら、ビューテーブル２１６それ自体は、更新されない。あるいはまた、ビューテーブル２１６内の全ての入力を削除することもできる。
【００６５】
したがって、前記コンテント変更モニター部品２０４は、特定のビューテーブル２１６が無効にされたことを上述の指示から決定することができる。無効化が検出されれば、コンテント変更モニター部品２０４は、特定のビューテーブル２１６に関連する照会または処理をＣａｃｈｅＰｏｒｔａｌへ伝達することができる。次に、前記システムは、前記照会または処理に関連する１つ以上のＵＲＬを識別することができ、かつ、これらのＵＲＬに関連するウェブページがキャッシュに記憶されれば、前記システムは、該ウェブページを無効としてマーキングすることができる。無効化は、単に、どのウェブページを無効にすべきかを識別することに関連していることが理解されるべきである。したがって、前記システムは、特定のビューテーブル２１６を維持するための作用が生じる必要があることを検出するが、その作用を開始することはない。このことは、ビューテーブル２１６を更新する費用を節減する。
【００６６】
ビューテーブル２１６の維持について、以下に説明する。前述したように、ビューログ２１８は、各々のビューテーブル２１６のために維持され、該ビューテーブル２１６に対する全ての処理の記録を保持する。ビューログの入力は、ビューテーブル２１６が変更されたという明確な表示を何も与えない“照会”と、ビューテーブル２１６（したがって、ＤＢＭＳ２０８）が変更されたという表示をもたらす“更新”、“挿入”または“削除”とを有する。維持のために、前記システムは、“更新”、“挿入”または“削除”処理にしたがって、ビューテーブル２１６を更新し、これらの処理は、ビューログ２１８に記録され、かつさらに、“最後に更新された日付”属性を更新する。
【００６７】
ビューログ２１８において“更新”、“挿入”または“削除”入力を検出することにより、コンテント変更モニター部品２０４は、ビューテーブル２１６の維持が発生したと決定することができる。ビューテーブル２１６の維持が検出されれば、コンテント変更モニター部品２０４は、特定のビューテーブル２１６に関連する照会または処理をＣａｃｈｅＰｏｒｔａｌへ伝達することができる。次に、前記システムは、前記照会または処理に関連する１つ以上のＵＲＬを識別することができ、かつ、これらのＵＲＬに関連するウェブページがキャッシュに記憶されれば、前記システムは、該ウェブページを無効としてマーキングすることができる。しかしながら、特定のビューテーブル２１６が維持（更新）されるときに、ＤＢＭＳ２０８または外部ソース２１２を更新する費用の多くが発生するので、他の実施形態においては、たとえウェブページに対してユーザーの要求がなかったとしても、新たなデータをアプリケーションサーバーへ渡して該ウェブページをリフレッシュすることにより、費用効率を高くすることができる。
【００６８】
ビューテーブルについては包含的ポインタとして説明したが、本発明の他の実施形態において、ビューテーブルは、追加的にまたは他に、ビューテーブルにより表された特定の照会に実際のデータが関連づけたコピーを有することができる。照会が発せられたときにＤＢＭＳからのデータにアクセスするためにポインタが用いられるので、ビューテーブル内にデータのコピーを有することは、照会の応答時間を改善する。しかしながら、不都合な点は、データベースが変更されると常に、ビューテーブル内のデータのコピーも変更する必要があることである。
【００６９】
再び図１１を参照すると、ＤＢＭＳではなく外部ソース２１２がアクセスされれば、外部ソース２１２に対する変更を監視するためにデーモン２２０を初期化することができる。例えば、デーモン２２０は、処理とその関連データとの関連を識別しかつこの関連データが変更されたかどうかを所定の間隔で検査するプログラムであってもよい。外部ソース２１２内のデータが変更されたことをデーモン２２０が検出すれば、デーモン２２０は、コンテント変更モニター部品２０４に通知し、かつ、無効化または維持が上記に定義したように進行することができる。
【００７０】
さらに他の実施形態においては、全ての照会または処理が、ビューまたはデーモン定義２２０を有しているわけではない。ビュー定義２１４またはデーモン定義２２０については、最も頻繁に発せられる照会のみのために、かつ／または、より頻繁に更新される結果を有する照会または処理のために、選択的に定義することができる。
【００７１】
＜コンテント変更監視機構２＞
図１２は、本発明の他の実施形態によるコンテント変更モニター部品２２２を例示する。図１２の実施形態において、ＤＢＭＳまたは外部データソースに対して発せられた照会２２４または処理２４４は、コンテント変更モニター部品２２２へも伝達される。次に、コンテント変更モニター部品２２２は、トリガ定義を作り出し、該トリガ定義は、ある一定の照会条件が満たされたときにアクティブ状態となるように定義されたトリガ文を有する。
【００７２】
例えば、上記に定義したように、住宅管理用途のためのＤＢＭＳが表１と表２とを有すると仮定する。図１２を参照して、さらに、上記に定義したように、照会ＳＱＬ１がコンテント変更モニター部品２２２により受信されると仮定する。ＳＱＬ１が受信された後に、１つ以上のトリガ文を有するトリガ定義２２６が作り出される。概して、トリガ定義は、“［データソースのリストを］［更新する／挿入する／削除する］［と同時に／前に／後に］［トリガ文のリストを実行する］”という形式のものである。本例において、トリガ定義２２６は、以下の通りに作り出される。
【表５】
0003620448.tif 000006
【００７３】
上記に与えた例示的トリガ定義２２６において、トリガ文は、ＩＦ−ＴＨＥＮ−ＥＬＳＥＩＦ節に包含される。上述したように、トリガ文は、ある一定の照会条件が満たされたときにアクティブ状態となるように定義される。トリガ文は、特定のデータに対する変更が、ある一定の照会に対して影響力を有するか、かつ次に、これらの照会と特定のデータとの関連を確立するかどうかを決定する。本発明の実施形態において、トリガ文は、“［照会条件が満たされれば］［作用を行う］”という形式を有することができるが、これに制約されるものではない。トリガ文がアクティブ状態であれば、データを更新させた前後のいずれかに、指定された作用が行われる。例えば、作用は、キャッシュ内、アプリケーションサーバー内、ウェブサーバー内、ＣａｃｈｅＰｏｒｔａｌ内、またはコンテント変更モニター部品内の特定のウェブページを無効にするためのコマンドの発行を有することができる。本例において、トリガ定義２２６内のトリガ文は、２０〜５０の価格によってＤＢＭＳへの挿入、削除、または更新を検出し、かつ、このようなＤＢＭＳ変更が検出されれば、トリガ定義が満たされたことを示すメッセージを送信しようとする。
【００７４】
本発明の他の実施形態において、多数の照会を表す多数のトリガ文を、１つのトリガ定義に合併することができる。例えば、“［照会条件１が満たされれば］［照会１に関連するウェブサーバーを無効にする］、［または他に、照会条件２が満たされれば］［照会に関連するウェブサーバーを無効にする］、［または他に、…］”というトリガ文を有するトリガ定義を作り出すことができる。例示目的のみのために本例を継続し、照会ＳＱＬ２（下記を参照）がコンテント変更モニター部品２２２により受信されると仮定する。ＳＱＬ２は、以下のように定義される。
【表６】
0003620448.tif 000007
【００７５】
この第２照会に関するトリガ定義を実施する１つの方法は、別個のトリガ定義を作り出すことである。本例においては、別個のトリガ定義を以下の通りに作り出すことができる。
【表７】
0003620448.tif 000008
【００７６】
しかしながら、あるいはまた、２つのトリガ定義を１つに合併することもでき、このことは、ＤＢＭＳが処理しかつ監視するために、より効率的かつ低費用であり得る。本例においては、ｐｒｉｃｅｍｖテーブルが更新されたときに、条件検査を行うために、より少数のトリガ定義が活性化状態にされる必要がある。本例においては、合併されたトリガを以下の通りに定義することができる。
【表８】
0003620448.tif 000009
【００７７】
トリガ２０−４０−５０において、ＳＱＬ２のためのトリガ文が最初に実行され、その後に、ＳＱＬ１のためのトリガ文が実行されることを特筆しておく。ＳＱＬ２の照会条件（２０〜４０の価格）を満たす価格はＳＱＬ１の照会条件（２０〜５０の価格）をも満たすので、ＳＱＬ２のためのトリガ文が満たされれば、検査は直ちに中止される。したがって、トリガ定義が全て行われる必要がないようにトリガ定義を順番に並べることにより、さらなる効率性を実現することができる。
【００７８】
合併されたトリガ定義については、重複する条件を備えた照会が多数存在する状況に適用することもでき、かつ、望ましい作用は、変更されたデータに関連するウェブページを無効にすることである。例えば、以下の３つの一般化された照会がコンテント変更モニター部品により受信されると仮定する。
【表９】
0003620448.tif 000010
【００７９】
一般的な合併されたトリガ定義については、以下の通りに作り出すことができる。
【表１０】
0003620448.tif 000011
【００８０】
照会条件２に対する変更が、ＳＱＬ４，５，６に関連するウェブページに影響を及ぼすことができるので、照会条件２が満たされれば、検査は直ちに中止される。したがって、前述のように、トリガ定義が全て行われる必要がないようにトリガ定義を順番に並べることにより、さらなる効率を実現することができる。本例の照会においては単純なＡＮＤ文が用いられたが、これらの照会における複雑なブール代数または関連する代数が、トリガ定義におけるトリガ文の複雑さに対応する効果を有することが理解されるべきである。
【００８１】
図３〜図１０に関連して上述したように、本発明の実施形態において、ＵＲＬ／関連処理マッピングテーブルは、コンテント変更モニター部品により維持されない。むしろ、図１１および図１２に関連して上述したように、コンテント変更モニター部品は、照会／処理とこれらに関連するデータとの関係を維持するだけである。好ましい実施形態において、コンテント変更モニター部品がデータに対する変更を検出すると、該コンテント変更モニター部品は、変更されたデータに関連する照会／処理が他の構成要素（ウェブサーバー、ＣａｃｈｅＰｏｒｔａｌ、または他のコンテント配布システム／サービスプロバイダなどであり得る）に対して無効であることを示すメッセージを伝達する。これにより、これらの構成要素は、ＵＲＬ／関連処理マッピングテーブルにアクセスし、無効な照会／処理に関連するウェブページのＵＲＬを決定し、かつ、無効化メッセージまたはリフレッシュメッセージを、これらのウェブページを記憶しているキャッシュまたはウェブサーバーへ伝達することができる。
【００８２】
しかしながら、本発明の他の実施形態においては、ＵＲＬ／関連処理マッピングテーブルに包含される情報を、種々の異なる実施手段において維持できることが理解されるべきである。例えば、コンテント変更モニター部品は、ＵＲＬ／関連処理マッピングテーブルを維持することができる。コンテント変更モニター部品がデータに対する変更を検出すると、該コンテント変更モニター部品は、変更されたデータに関連する照会／処理を識別し、ＵＲＬ／関連処理マッピングテーブルにアクセスし、無効な照会／処理に関連するウェブページのＵＲＬを決定し、かつ、関連する照会／処理が他の構成要素（ウェブサーバー、ＣａｃｈｅＰｏｒｔａｌ、または他のコンテント配布システム／サービスプロバイダなどであり得る）に対して無効であることを示すメッセージを伝達する。これにより、これらの構成要素は、無効化メッセージまたはリフレッシュメッセージを、これらのウェブページを記憶しているキャッシュまたはウェブサーバーへ伝達することができる。他の実施形態において、コンテント変更モニター部品は、無効化メッセージまたはリフレッシュメッセージを、これらのウェブページを記憶しているキャッシュまたはウェブサーバーへ直接的に伝達することができる。
【００８３】
再び図１２を参照すると、ＤＢＭＳ２３０ではなく外部ソース２２８がアクセスされれば、外部ソース２２８に対する変更を監視するためにデーモン２３２を初期化することができる。例えば、デーモン２３２は、処理とその関連データとの関連を識別しかつこの関連データが変更されたかどうかを所定の間隔で検査するプログラムであってもよい。トリガと同様に、デーモン２３２は、ある一定のデータまたはテーブルが変更されるかまたは変更される予定であるときにアクティブ状態となるように定義され、かつ、照会とその関連データとの関連を確立する。デーモン２３２がアクティブ状態であれば、データを更新させた前後のいずれかに、デーモン定義が実行される。デーモン定義については、概して、“［条件があれば］［作用を行う］”として記述することができる。この条件は、特定のデータの更新が、これに関連する照会に対して影響力を有するかどうかを検査する。条件が満たされれば、何らかの作用が行われる。例えば、デーモン定義において定義された作用は、新たなページを発生するために新たなデータをアプリケーションサーバーへ渡す他に、ＣａｃｈｅＰｏｒｔａｌ、キャッシュ、アプリケーションサーバー、ウェブサーバー、またはコンテント変更モニター部品２２２へ、特定のウェブページの無効化を信号で伝えることができる。
【００８４】
さらに他の実施形態において、全ての照会および処理がトリガ定義またはデーモン定義を有するわけではない。トリガまたはデーモンについては、最も頻繁に発せられる照会／処理のみのために、および／または、より頻繁に更新される結果を有する照会／処理のために、選択的に定義することができる。
【００８５】
＜コンテント変更監視機構３＞
図１３は、本発明の他の実施形態によるコンテント変更モニター部品を例示する。図１３の実施形態は、ビュー定義および／またはトリガ定義を、ＤＢＭＳ２３６または外部ソース２３８とは別個のサーバー２３４に合併し、該サーバー２３４は、ＣａｃｈｅＰｏｒｔａｌサーバーまたは他のコンテント配布サービスプロバイダ用サーバーを有することができるが、これに制約されるものではない。
【００８６】
本発明の他の実施形態において、関連するスキーマおよびＤＢＭＳ２３６および外部データソースからの制約の他に、ＤＢＭＳ２３６および外部データソース２３８全体については、模写仕様を用いてサーバー２３４上に模写を取ることができる。別個のサーバー２３４は、ＤＢＭＳ２３６または外部データソース２３８において用いられるものと同じ形式のデータ管理システムを必ずしも有しているとは限らないことを特筆しておく。模写仕様においては、自動化されたデータ同期化についても指定することができ、これにより、ＤＢＭＳ２３６または外部データソース２３８においてデータ変更が発生したときに、このような変更は、別個のサーバー２３４へ自動的に伝達される。さらに他の実施形態においては、ＤＢＭＳ２３６または外部データソース２３８に対する挿入、更新、削除処理を検出するために、模写仕様を用いるのではなくビューログを監視することができる。これらの処理については、別個のサーバー２３４内のコピーデータを一致させるために、該コピーデータ上において行うことができる。
【００８７】
一致したコピーデータによって、上述したコンテント変更監視機構１またはコンテント変更監視機構２を適用することができる。本発明の好ましい実施形態においては、更新、挿入、削除作用が、特定のＵＲＬ要求に関連する照会または処理に対して影響力を有しているかどうかを決定するために、ビュー文、ビュー定義、ビューテーブル、ビューログについても別個のサーバー２３４内に維持することができる。他の実施形態においては、これらのデータ構造を、ＤＢＭＳ２３６または外部データソース２３８により維持することができ、かつ、この情報を、コンテント変更モニター部品２３４へ送信することができる。ＤＢＭＳ２３６または外部データソース２３８に対する変更が検出されると、キャッシュまたはウェブサーバーに記憶された関連するウェブページを、別個のサーバー２３４により送信されたメッセージ２４６により無効にするかまたはリフレッシュすることができる。
【００８８】
図１３の実施形態によって、ビューテーブルとビューログとを維持する費用を、別個のサーバーにより生じさせることが可能となり、かつ、顧客のウェブサーバー、ＤＢＭＳ、外部データソースに対して要求される変更は最小限となる。この自由なシステムの結合は、自分たちの機械を変更することが厄介な会社のために好ましいものであり得る。
【００８９】
インテリジェント無効化器／リフレッシュ器
本発明の他の実施形態においては、一致したデータのコピーを別個のサーバー内に維持するのではなく、必要なデータのみが別個のサーバー上にコピーされる。コンテント変更モニター部品に関するこの実施形態は、以後本明細書においてインテリジェント無効化器／リフレッシュ器と称するものを有することができる。しかしながら、インテリジェント無効化器／リフレッシュ器の機能性を、別個のサーバー、コンテント変更モニター部品、ＣａｃｈｅＰｏｒｔａｌ、または、他のコンテント配布サービスプロバイダ、ウェブサーバー、アプリケーションサーバーなどの中に組み込めることが理解されるべきである。さらに、以下の説明は無効化に焦点を当てているが、他の実施形態においてはリフレッシュも実行できることを特筆しておく。
【００９０】
＜インテリジェント無効化器／リフレッシュ器の機能的概観＞
インテリジェント無効化器／リフレッシュ器に関する説明については、例によって最適に呈することができる。ＤＢＭＳが以下のテーブルを有すると仮定する。
ｃａｒ（ｍａｋｅ，  ｍｏｄｅｌ，  ｐｒｉｃｅ）
ｍｉｌｅａｇｅ（ｍｏｄｅｌ，  ｍｐｇ）
【００９１】
さらに、ウェブページＵＲＬ１を発生するために、以下の照会ＱＵＥＲＹ１がＤＢＭＳに対して発せられたと仮定する。
【表１１】
0003620448.tif 000012
【００９２】
無効化器／リフレッシュ器もまたこの照会を受信するので、該無効化器／リフレッシュ器は、ＵＲＬ１とＱＵＥＲＹ１との関連を維持することができる。以下に、一連の対応ビューログ入力により明白なように、新たな組（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５０００）がテーブル”ｃａｒ”内に挿入されたと仮定する。ＱＵＥＲＹ１は１つのテーブル（ｃａｒ）にアクセスしさえすればよいので、ＱＵＥＲＹ１に記述された照会条件（ｍａｋｅ  ＝  ”Ｔｏｙｏｔａ”）を新たな組の値が満たすかどうかを決定することができる。本例においては、新たな組の値が照会条件を満たすので、ＱＵＥＲＹ１に関する結果が影響を与えられ、かつこれにより、ＵＲＬ１を無効にするかまたはリフレッシュする必要がある。同様に、組（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５０００）が、テーブル”ｃａｒ”から削除されれば、この組はＱＵＥＲＹ１に記述された照会条件を満たすので、ＱＵＥＲＹ１に関する結果が影響を与えられ、かつこれにより、ＵＲＬ１を無効にするかまたはリフレッシュする必要がある。さらに、挿入処理の前の削除処理として更新処理を調べることができるので、更新処理を扱うために、今述べた手順を実施することができる。概して、本明細書における説明は、説明の目的のために、“挿入”のような１つの形式のデータベースに言及しているが、この説明が、削除処理および更新処理にも概念的に適用可能であることが理解されるべきである。
【００９３】
同じテーブルを必要とする他の例において、ウェブページＵＲＬ２を発生するために、以下の照会ＱＵＥＲＹ２が発せられたと仮定する。
【表１２】
0003620448.tif 000013
【００９４】
この照会が１つ以上のテーブルを必要とし、かつ、結合照会条件（多数のデータテーブルに対してアクセスを要求する照会条件）が存在することを特筆しておく。明確には、”ｗｈｅｒｅ”という語の後に定義される照会条件において、テーブル”ｃａｒ”は、ｃａｒ．ｍａｋｅとｃａｒ．ｍｏｄｅｌとに関する値を決定するためにアクセスされる必要があり、テーブル”ｍｉｌｅａｇｅ”は、ｍｉｌｅａｇｅ．ｍｏｄｅｌに関する値を決定するためにアクセスされる必要がある。以下に、一連の対応するビューログ入力により明白なように、新たな組（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５０００）がテーブル”ｃａｒ”内に挿入されたと仮定する。ＱＵＥＲＹ１は２つのテーブルにアクセスする必要があるので、テーブル”ｃａｒ”に関連するＱＵＥＲＹ２に記述された照会条件の一部分のみを新たな組の値が満たすことができるかどうかが最初に決定される。照会条件の一部分が満たされなければ、照会条件の他の部分はテストされる必要がなく、かつ、新たな挿入処理はＱＵＥＲＹ２の結果に対して影響力を有していないことと、ＵＲＬ２は無効にされる必要もリフレッシュされる必要もないこととが識別される。
【００９５】
しかしながら、新たに挿入された組が、テーブル”ｃａｒ”に関連する照会条件の一部分を満たせば、テーブル”ｍｉｌｅａｇｅ”に関連する照会条件の残りが検査されるまで、ＱＵＥＲＹ２の結果が影響を受けるのかどうかをなおも決定することができない。部分的な照会条件ｃａｒ．ｍｏｄｅｌ  ＝  ｍｉｌｅａｇｅ．ｍｏｄｅｌが満たされるかどうかを検査するためには、テーブル”ｍｉｌｅａｇｅ”にアクセスする必要がある。部分的な照会条件を検査するためには、以下の副照会ＱＵＥＲＹ３を、コンテント変更モニター部品により発生し、かつ、ＤＢＭＳへ発することができる。
【表１３】
0003620448.tif 000014
【００９６】
この副照会については、テーブル”ｍｉｌｅａｇｅ”に関連していない全ての条件を除去することと、結合処理において必要とされるテーブル”ｃａｒ”内の全ての属性を、新たに挿入された組における該全ての属性に対応する値に置き換えることとにより、準備することができる。本例においては、ｃａｒ．ｍｏｄｅｌは、ストリング”Ａｖａｌｏｎ”に置き換えられる。その理由は、これが、属性ｍｉｌｅａｇｅ．ｍｏｄｅｌの値と結合するために用いられる唯一の値であるためである。ＱＵＥＲＹ３に関する結果が存在すれば、新たな挿入処理がＱＵＥＲＹ２の結果に対して影響力を有し、かつこれにより、ＵＲＬ２を無効にするかまたはリフレッシュする必要がある。
【００９７】
属性ｍｉｌｅａｇｅ．ｍｏｄｅｌについてはテーブル”ｍｉｌｅａｇｅ”から検索する必要があるので、属性ｍｉｌｅａｇｅ．ｍｏｄｅｌの値を、索引構造または結合索引としてインテリジェント無効化器／リフレッシュ器にセーブできることを特筆しておく。この後に、属性ｍｉｌｅａｇｅ．ｍｏｄｅｌの値を要求する後続の照会が発せられれば、結合索引にアクセスすることができ、かつ、ＱＵＥＲＹ３を再び発する必要がない。その理由は、ＱＵＥＲＹ２を処理するために必要とされる全ての情報は、既に有効であるためである。結合索引については、データベース更新ログに列挙された処理を行うことにより維持することができる。
【００９８】
より複雑な例においては、ＤＢＭＳが以下の２つのテーブルを有すると仮定する。
ｃａｒ（ｍａｋｅ，  ｍｏｄｅｌ，  ｐｒｉｃｅ）
ｍｉｌｅａｇｅ（ｍａｋｅ，  ｍｏｄｅｌ，  ｍｐｇ）
【００９９】
さらに、ウェブページＵＲＬ４を発生するために、以下の照会ＱＵＥＲＹ４が発せられたと仮定する。
【表１４】
0003620448.tif 000015
【０１００】
この照会が１つ以上のテーブルを必要とし、かつ、結合照会条件が存在することを特筆しておく。以下に、新たな組（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５０００）が、テーブル”ｃａｒ”内に挿入されたと仮定する。ＱＵＥＲＹ４は２つのテーブルにアクセスする必要があるので、テーブル”ｃａｒ”に関連する照会条件の一部分のみを新たな組の値が満たすことができるかどうかが最初に決定される。前記照会条件の一部分が満たされなければ、照会条件の他の部分はテストされる必要がなく、かつ、新たな挿入処理はＱＵＥＲＹ４の結果に対して影響力を有していないことと、ＵＲＬ４は無効にされる必要もリフレッシュされる必要もないこととが識別される。
【０１０１】
しかしながら、たとえ、新たに挿入された組が、テーブル”ｃａｒ”に関連する照会条件の一部分を満たしても、テーブル”ｍｉｌｅａｇｅ”に関連する照会条件の残りが検査されるまで、ＱＵＥＲＹ４の結果が影響を与えられるのかどうかをなおも決定することができない。部分的な照会条件ｃａｒ．ｍｏｄｅｌ  ＝  ｍｉｌｅａｇｅ．ｍｏｄｅｌが満たされるかどうかを検査するためには、テーブル”ｍｉｌｅａｇｅ”にアクセスする必要がある。部分的な照会条件を検査するためには、以下の副照会ＱＵＥＲＹ５を、ＤＢＭＳへ発することができる。
【表１５】
0003620448.tif 000016
【０１０２】
この副照会については、テーブル”ｍｉｌｅａｇｅ”に関連していない全ての条件を除去することと、結合処理において必要とされるテーブル”ｃａｒ”内の全ての属性を、新たに挿入された組に対応する値に置き換えることとにより、準備することができる。本例においては、ｃａｒ．ｍｏｄｅｌは、ストリング”Ａｖａｌｏｎ”に置き換えられ、かつ、ｃａｒ．ｍａｋｅは、ストリング”Ｔｏｙｏｔａ”に置き換えられる。その理由は、これらが、属性ｍｉｌｅａｇｅ．ｍｏｄｅｌ，ｍｉｌｅａｇｅ．ｍａｋｅの値に結合するために用いられる唯一の値であるためである。ＱＵＥＲＹ５に関する結果が存在すれば、新たな挿入処理がＱＵＥＲＹ４の結果に対して影響力を有し、かつこれにより、ＵＲＬ４を無効にするかまたはリフレッシュする必要がある。
【０１０３】
属性ｍｉｌｅａｇｅ．ｍｏｄｅｌの値およびｍｉｌｅａｇｅ．ｍａｋｅの値については、結合索引としてインテリジェント無効化器／リフレッシュ器にセーブできることを特筆しておく。この後に、属性ｍｉｌｅａｇｅ．ｍｏｄｅｌまたはｍｉｌｅａｇｅ．ｍａｋｅの値を要求する後続の照会が発せられれば、結合索引にアクセスすることができ、かつ、ＱＵＥＲＹ５を再び発する必要がない。その理由は、ＱＵＥＲＹ５を処理するために必要とされる全ての情報は、既に有効であるためである。
【０１０４】
さらに他の例においては、上記に定義したＱＵＥＲＹ２，４がＤＢＭＳへ発せられ、かつ、新たな組（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５０００）がテーブル”ｃａｒ”内に挿入されたと仮定する。コンテント変更モニター部品は、副照会を特定の順番で作り出しかつ発することにより、ある程度の効率を達成することができる。本例においては、最初にＱＵＥＲＹ３がＤＢＭＳへ発せられ、かつ、副照会に関する結果が何も存在しなければ、ＵＲＬ２，４の両方とも無効にする必要はないと決定することができる。しかしながら、ＱＵＥＲＹ３に関する結果が存在すれば、コンテント変更モニター部品は、最初にＵＲＬ２を無効にし、かつ次に、ＱＵＥＲＹ５をＤＢＭＳへ発することができる。ＱＵＥＲＹ５に関する結果を、ＱＵＥＲＹ２，４の両方に関する結合索引としてセーブできることを特筆しておく。
【０１０５】
本発明の実施形態においては、本明細書において“挿入”の例によって前述した技術を、ＤＢＭＳに対する削除処理と更新処理とを扱うように拡張でき、かつさらに、関連する演算子の他に”ｏｒ”または”ｎｏｔ”または他のブール演算子を用いる照会に拡張できることを特筆しておく。
【０１０６】
ＤＢＭＳへ副照会を発するのではなく結合索引を構築するための計画を定義することができる。例えば、結合索引が適度に小さければ、または、ＤＢＭＳの照会頻度が高ければ、結合索引をセーブしかつ維持することが好ましい。しかしながら、ＤＢＭＳに関する多くの属性を結合索引にセーブする必要があり、結合索引を頻繁に更新する必要があり、または、ＤＢＭＳの照会頻度が低ければ、副照会を発する方がより効率的であり得る。
【０１０７】
＜インテリジェント無効化器／リフレッシュ器のアーキテクチャ＞
図１４は、本発明の好ましい実施形態による動的コンテントキャッシュおよび無効化およびリフレッシュシステム２４８に関する全体的アーキテクチャを示す。図１４に示すように、システム内には、動的コンテント要求処理、ＤＢＭＳ更新処理、ＵＲＬ／関連処理決定処理（“スニッフィング（ｓｎｉｆｆｉｎｇ）”）、ＤＢＭＳ変更検出および無効化処理（“無効化”）という、４つの独立した処理（矢印により示されている）が存在する。
【０１０８】
前記アーキテクチャの主要な構成要素は、スニッファ２５０と、無効化器／リフレッシュ器２５２とを有する。スニッファ２５０は、ユーザーによるウェブページ要求を検出し、かつ、照会例（ｑｕｅｒｙ  ｉｎｓｔａｎｃｅ：ＱＩ）マッピング２５４（本明細書においては、ＵＲＬ／関連処理マッピングまたはＱＩ／ＵＲＬマップと称する）に対するＵＲＬ＋クッキー＋ポストデータを作り出す。本明細書において定義したＵＲＬ情報が、要求されたウェブページのＵＲＬと、ウェブページに伴うことができるクッキーと、ウェブサーバーからアプリケーションサーバーへ送信されたポストデータ情報とを有することが理解されるべきである。スニッファ２５０は、ＱＩを収集するが、これらのＱＩを解釈しない。無効化器／リフレッシュ器２５２は、ＤＢＭＳに対する更新に“従い”、かつ、ＱＩ／ＵＲＬマップ２５４を用いて、関連するキャッシュ２５６またはウェブサーバーに対し、特定の記憶されたページの無効化について通知する。こうするために、インテリジェント無効化器／リフレッシュ器２５２は、ＱＩを解釈することを必要とし、かつ、ＱＩ／ＱＴテーブルにアクセスする必要があり、これにより、これらの照会形式（ＱＴ）が、より効率的な無効化のために、コンパイル／登録の間に決定される。
【０１０９】
スニッファ２５０および無効化器／リフレッシュ器２５２のいずれも、ボトルネックになるべきではないことが理解されるべきである。スニッファ２５０は、ウェブサーバー２５８に匹敵する速度で動作する必要があるが、このことは、通常は問題ではない。その理由は、ウェブサーバー２５８が、動的コンテントにのための要求を供給するために、スニッファ２５０よりも多くの処理を行う必要があるためである。無効化器／リフレッシュ器２５２もまた、ボトルネックになるべきではない。その理由は、無効化器／リフレッシュ器２５２が、ＤＢＭＳ２６０の外部で動作し、かつ、無効化に費やすべき所要時間を管理するためである。しかしながら、無効化器／リフレッシュ器２５２が、無効化のための関連データを集めるために余分の照会をＤＢＭＳへ送信する必要があれば、該無効化器／リフレッシュ器２５２がＤＢＭＳ２６０に対する負荷を増加できることを特筆しておく。
【０１１０】
説明のみの目的のために、本明細書においてインテリジェントキャッシュおよびリフレッシュ機構１〜５のいずれかに関連して上述したアーキテクチャをネットワークトラフィックに従うために用いることができ、かつ、該アーキテクチャはＵＲＬ／関連処理マッピングテーブルを発生できるが、図１４に示したアーキテクチャは、インテリジェント無効化器／リフレッシュ器２４８を説明する例として用いられることが理解されるべきである。
【０１１１】
図１４を参照すると、矢印（１）〜（６）は、通常の動的コンテント要求が進み得る段階を説明する。スニッファ２５０および無効化器／リフレッシュ器２５２は、動的コンテント要求を妨げも変更もしない。その代わりに、これらは、３つのログ（２つのＨＴＴＰ要求／配布ログ２６２、および、照会例／配布ログ２６４）に依存して、全ての関連情報を集める。矢印（Ｕｐｄ）２６６は、ＤＢＭＳ２６０に対する更新を示す。これらの更新２６６は、照会２６８から独立している。スニッファ２５０および無効化器／リフレッシュ器２５２は、ＤＢＭＳ更新処理も変更しない。その代わりに、これらは、ＤＢＭＳ更新ログに依存して、全ての関連情報を集める。
【０１１２】
矢印（ａ）〜（ｃ）は、スニッファ照会例／ＵＲＬマップ発生処理を示し、その一方で、矢印（Ａ）〜（Ｃ）は、キャッシュコンテント無効化処理を示す。これら２つの処理は、非同期であるが相補的である。
【０１１３】
「このアーキテクチャの特性」
インテリジェント無効化器／リフレッシュ器のアーキテクチャは、ウェブサーバー２５８、アプリケーションサーバー２７０、またはＤＢＭＳ２６０に対する変更がほとんどまたは全く必要とされないように設計される。しかしながら、好ましい実施形態においては、これらのエンティティからの協同は、アーキテクチャの性能を向上させることができる。
【０１１４】
前記アーキテクチャについては幾つかのモードに展開することができ、かつ、これらのモードは、コールドスタート、ウォームスタート、ホットスタートを有するが、これらに制約されるものではない。コールドスタートモードにおいては、顧客は、システムを得て、ソフトウェアをインストールし、かつ直ちに、動作を開始させることができる。システムは、関連ログを発生し始め、かつ、自己同調を行って性能を向上させる。コールドスタートモードは迅速な展開をもたらすが、システムが初期同調されていないので、システムが高性能を達成するためには時間がかかることがある。
【０１１５】
ウォームスタートモードにおいては、顧客は、システムを得て、ソフトウェアをインストールし、かつ、システムに既存のログを供給することができる。システムは、初期の性能方針を生じさせるために３つのログを用いる。したがって、ウォームスタートモードは、比較的迅速な展開と、ある程度の初期性能とをもたらす。
【０１１６】
ホットスタートモードにおいては、顧客と、ＣａｃｈｅＰｏｒｔａｌまたは他のコンテント配布サービスプロバイダのようなインテリジェント無効化器／リフレッシュ器の所有者とは、展開前に、関連するドメインの専門知識を交換することができ、かつ次に、初期の性能方針を、コンテント配布サービスプロバイダの技術的表示により高性能用に同調させることができる。前記システムは、初期の性能方針を無効化／改善するために、既存のログを用いることもできる。このオプションは、高度な初期性能をもたらすが、顧客との対話を必要とする。
【０１１７】
「用語」
主要な構成要素についてさらに詳細に説明する前に、関連する用語について多少理解すべきである。照会形式（ＱＴ）は、照会の定義である。これは、変数を有しても有していなくてもよい有効なＳＱＬ文である。照会形式については、Ｑ（Ｖ１，．．．，Ｖｎ）として示され、ここで、各々のＶｉは、照会がＤＢＭＳに渡される前に、アプリケーションにより例示する必要がある変数である。
【０１１８】
結合照会形式は、変数を有していない有効なＳＱＬ文である。結合照会形式については、Ｑ（ａ１，．．．，ａｎ）として示され、ここで、各々のａｉは、変数Ｖｉのために例示される値である。アプリケーションサーバーによりＤＢＭＳに渡される照会は、結合照会である。
【０１１９】
照会例（ＱＩ）は、関連する要求タイムスタンプを備えた結合照会形式である。結合照会形式については、Ｑｔ（ａ１，．．．，ａｎ）として示され、ここで、ｔは、アプリケーションサーバーが要求をＤＢＭＳに渡した時刻である。
【０１２０】
したがって、多数の照会例は、同じ結合照会形式を有することができ、かつ、同じ結合照会形式は、同じ照会形式を有することができる。
【０１２１】
「スニッファ」
“スニッファ”は、ネットワークトラフィックに“従う”ようにネットワーク上に配置することができるハードウェアまたはソフトウェア装置である。スニッファについては、イーサネット上に配置することができ、該イーサネットを介して、ウェブサーバー、アプリケーションサーバー、およびＤＢＭＳが通信する。スニッファは、照会例ＱＩマッピング（ＵＲＬ／関連処理マッピングテーブル）に対するＵＲＬ＋クッキー＋ポストデータを作り出す。スニッファは、照会の発生を収集するが、これらを解釈しない。ＵＲＬ＋クッキー＋ポストデータ情報については、着信ＨＴＴＰ要求に従うモジュールを用いて、ウェブサーバーへの入力において収集することができる。さらに、ＵＲＬ＋クッキー＋ポストデータ情報については、アプリケーションサーバーにより設定された環境変数セットを用いるモジュールを用いて、アプリケーションサーバーへの入力において収集することができる。例えば、ＵＲＬ情報については、ＱＵＥＲＹ＿ＳＴＲＩＮＧの前のＨＴＴＰ＿ＨＯＳＴ環境変数を用いて収集することができ、かつ、クッキー情報については、ＨＴＴＰ＿ＣＯＯＫＩＥ環境変数を用いて収集することができ、かつ、ポストデータ情報については、ＨＴＴＰメッセージ主要部を用いて収集することができる。
【０１２２】
「無効化器／リフレッシュ器」
図１５に例示するように、無効化器／リフレッシュ器２７２は、登録モジュール２７４，情報管理モジュール２７６、無効化モジュール２７８という３つの堅く結合されたモジュールからなる。
【０１２３】
「登録モジュール」
登録モジュール２７４は、補助索引およびデータ構造２８０の作成のために、無効化方針の作成と、関連照会の統計の収集と、これらの方針および統計を情報管理モジュール２７６に渡すこととに対して責任を有する。すなわち、登録モジュール２７４は、“何を無効にすべきか”についての質問に応答する。
【０１２４】
オフラインモードで動作するときに、システム管理者は、無効化器／リフレッシュ器２７２が検出する必要がある照会形式（ＱＴ）を登録することができる。これらのＱＴについては識別することができる。その理由は、アプリケーションサーバー２８２により発生することができるＱＴは限られた数しか存在しないためである。ホットスタートの間に、ドメインの専門家は、どちらの形式（結合または非結合）の照会がアプリケーションサーバー２８２により作り出されるのかを宣言することができる。登録モジュール２７４は、この情報を、無効化器／リフレッシュ器または補助データ構造２８０内に登録する。照会形式については、ウェブサイトのアプリケーションサーバー設計者により供給することができる。その理由は、どの形式の照会をアプリケーションサーバー２８２から発することができるのかを前記設計者が知っているためである。
【０１２５】
オンラインモードで動作するときに、登録モジュール２７４は、ＱＩ／ＵＲＬマップ２８４を走査し、かつ、新たなＱＴおよびＱＩを登録する。照会形式のディレクトリに関して、無効化器／リフレッシュ器２７２は、該無効化器／リフレッシュ器２７２が既知の照会形式と関連づけることができない照会例が存在するかどうかを調べるために、常に、ＱＩ／ＵＲＬマップ２８４に従う。このような照会例に遭遇すれば、無効化器／リフレッシュ器２７２は、これらの照会例を解釈して、その照会形式を識別する。例えば、無効化器／リフレッシュ器２７２がログ内に以下の３つの照会例を観測すれば、
【表１６】
0003620448.tif 000017
照会形式を、以下のように得ることができる。
【表１７】
0003620448.tif 000018
【０１２６】
さらに、ハードコードされた（ｈａｒｄ−ｃｏｄｅｄ）無効化方針２８６は、このモードにおいて登録される。無効化方針登録に関して、ホットスタートの間に、ドメインの専門家およびＣａｃｈｅＰｏｒｔａｌの技術者は、無効化処理を管理する指針を確立する。これらの指針については、無効化器／リフレッシュ器の内部データ構造内にまたは補助データ構造２８０内に登録することができる。例えば、登録された無効化方針２８６は、“最も頻繁にアクセスされる１００個のページのみをキャッシュする（ｃａｃｈｅ）かまたは無効化する”ことであってもよい。
【０１２７】
無効化方針を見つけるために、無効化器／リフレッシュ器２７２は、無効化処理を管理する性能指針を、常に確立／更新することができる。考慮すべき幾つかのパラメータは、本明細書において説明するように、データベースポーリング（無効化／リフレッシュ処理において必要とされる余分の情報を集める目的による、データベースへのアクセス）頻度と、結合索引のサイズと、結合索引維持の頻度などを有することができる。例えば、結合索引については、特定の照会のために最初に作り出すことができるが、時間の経過とともに、無効化器／リフレッシュ器２７２は、結合索引の更新頻度が、該結合索引の維持を保証するのに十分高いと決定することができる。同様に、オンラインモードにおいて、登録モジュール２７４は、照会統計を動的に作り出し、かつ、無効化方針を作り出す／更新することもできる。
【０１２８】
「無効化モジュール」
無効化モジュール２７８は、“いつ無効にすべきか”という質問に応答する責任を有する。ＱＩ／ＵＲＬマップ２８４に従う登録モジュール２７４とは違い、無効化モジュールは、補助データ構造２８０（ＱＩ／ＱＴ、結合索引などをマッピングし続けるために必要とされる貯蔵所）を作り出すために、データベース更新ログに従い、更新情報を情報管理ユニットに渡し、かつ、無効化方針２８６を修正するために、更新情報を登録ユニットへ渡す。さらに、無効化モジュール２７８は、ＤＢＭＳ２８８（データベースポーリング）へ送信される副照会をスケジューリングするために無効化方針２８６と補助データ構造２８０とを用い、かつ、無効化メッセージ２９０を適切なキャッシュ２９２またはウェブサーバーへ送信する。無効化モジュール２７８は、データベースポーリング要求のスケジューリングと、要求の発生／結果の解釈とを行うことができる。
【０１２９】
通常は、無効化器／リフレッシュ器２７２は、どのキャッシュページを無効にすべきかを決定するために内部補助構造２８０を用いる。しかしながら、幾つかの場合には、内部的に維持された情報が、この目的のために十分ではないことがある。これらの場合には、無効化モジュールは、どの情報ポーリング要求を発生する必要があるのかと、いつこれらの要求がＤＢＭＳ２８８へ渡されるべきなのかとを識別することにより、データベースポーリング要求のスケジューリングを行うことができる。
【０１３０】
さらに、前記無効化モジュール２７８は、情報要求を、ＤＢＭＳにとって理解可能な形式（すなわち、照会）に変換することと、照会結果を、無効化器／リフレッシュ器２７２が用いることができる形式に変換することとにより、要求の発生／結果の解釈を行うことができる。
【０１３１】
「情報管理モジュール」
情報管理モジュール２７６は、無効化モジュール２７８が意思決定の目的のために用いる補助データ構造２８０を作り出す。この決定は、照会形式または照会例のいずれかに基づくことができることを特筆しておく。例えば、照会形式に基づく決定は、無効化のために単独のテーブル照会がデータベース（データベースポーリング）へのさらなるアクセスを要求しない決定であってもよい。他の例においては、ＱＩに基づく決定は、照会のドメインが小さければ、更新管理中に前記照会に低い優先順位を与えるものであってもよい。すなわち、所定の照会に関して、インテリジェント無効化器／リフレッシュ器２７２は、いくつのウェブページが潜在的に影響を与えられるのかを識別し、潜在的な影響が大きいほど、そのＱＩに関する優先順位は高い。
【０１３２】
更新時間と照会時間とは相関しないので、無効化スケジュールの最適化において、この遅延から何らかの恩恵を得ることができる。したがって、照会管理のための決定パラメータは、照会形式／定義を有することができる。その理由は、あまりに多くのオーバーヘッドを必要とする照会形式をキャッシュすることできないためである。他の決定パラメータは、変数値（照会例）であってもよい。その理由は、それほど頻繁に要求されない照会例をキャッシュすることできないためである。適切な関係の更新速度についても考慮することができる。その理由は、頻繁な更新を必要とするページをキャッシュすることできないためである。
【０１３３】
情報管理モジュール２７６は、ＱＩ／ＱＴ合併と、更新合併とを行うことができる。維持すべきＱＴ，ＱＩの数は大きくてもよいので、各々のＱＩを個々に処理する代わりに、無効化器／リフレッシュ器２７２は、関連する例を見出すこととこれらをグループとして処理することとにより、ＱＩ／ＱＴ合併を行うことができる。同様に、多数の照会形式が互いに類似／関連した部分を有していれば、これらの部分は、調和した方法で処理される。さらに、処理すべきＤＢＭＳ更新、削除、または挿入の数は大きくてもよいので、各々の変更を個々に処理する代わりに、無効化器／リフレッシュ器２７２は、関連する更新を見出し、かつ、これらをグループとして処理する。このことは、特に、範囲更新を処理するときに重要である。
【０１３４】
＜情報ポーリングの量を低減させるための技術＞
範囲の照会は多くの類似した組を有することができる。範囲更新の例は、データベース内の全ての製品価格を５％増加させる処理である。関連するウェブページを無効にする必要があるかどうかを決定するために、無効化器／リフレッシュ器は、各々の更新を１度に１つ検出し、かつ、１度に１つの更新を処理することができる。しかしながら、このことは時間の浪費となり、かつ、データベース情報ポーリング（副照会）の作成が過剰となり得る。本発明の好ましい実施形態においては、インテリジェント無効化器／リフレッシュ器は、全ての更新が終了するまで待機し、かつ、全ての更新を、単一の仮想テーブルに対する更新として処理することができる。このセクションにおいては、特に、更新、挿入、および削除ＤＢＭＳ処理に関する範囲照会が発せられる際の、情報ポーリングの量を低減させるための技術について説明する。
【０１３５】
図１６は、時間線２９４と、イベントのシーケンスとを示す。”ｓｙｎｃ”イベントは、無効化器／リフレッシュ器が更新ログから更新を回収する時刻である。ｓｙｎｃイベントが頻繁であれば、無効化処理はよりリアルタイムなものとなるが、意思決定のための時間はより短くなる。”ｕｐ”イベントは、データベースに対して発生する更新を示す。”ｑｉ”イベントは、スニッファにより記録された照会例を示す。ｓｙｎｃ１とｓｙｎｃ２との間にログをとられた更新は、ｓｙｎｃ２の後に処理されることを特筆しておく。
【０１３６】
例示のみの目的のために、ｃｏｎｄ（ｑｉ１）→ｃｏｎｄ（ｑｉ２）（ｑｉ１の条件は、ｑｉ２の条件を包含する）、かつ、ｑｉ１がまだ無効化されていない（図１６に示したように、ｑｉ１がｓｙｎｃ１の後に発生した、または、いかなる関連する更新もｓｙｎｃ１の前に発生しなかった）と仮定する。これらの環境の下では、ｑｉ１を無効化する必要があれば、ｑｉ２についてもまた無効化する必要がある。
【０１３７】
同様の例においては、ｃｏｎｄ（ｑｉ２）→ｃｏｎｄ（ｑｉ１）、かつ、ｑｉ１がまだ無効化されていないと仮定する。これらの環境の下では、ｑｉ２を無効化する必要があれば、ｑｉ１についてもまた無効化する必要がある。
【０１３８】
したがって、照会例を無効化する必要がある部分的順番を記述する照会例格子（ｌａｔｔｉｃｅｓ）を形成することができる。この概念については、以下の説明において一般化することができる。無効化器／リフレッシュ器が、内部データ構造に登録された以下の照会形式を有していると仮定する。
ＱＴ＝ＦｆＡＧΠＡＰσＣ（Ｒ１×．．．×ＲＮ）［Ｖ１，．．．，ＶＭ］
ここで、σは選択演算子、Πは投影演算子、Ｆはグループバイ（ｇｒｏｕｐ−ｂｙ）演算子、×は直積演算子、Ｒｊは関係、Ｃは照会条件、Ｖｊは照会変数／パラメータ、ＡＰは投影属性のセット、ＡＧはグループバイ属性のセット、および、ｆは集合関数である。
【０１３９】
この形式による全ての既知照会例のセットについては、以下の属性との関係（ＱＩＴｂｌＱＴ）として示すことができる。
【表１８】
0003620448.tif 000019
ここで、ＱＩＤはテーブルＱＩＴｂｌＱＴ内における属性、Ｍはこの照会形式を形成する変数の数、Ｒｅｑ＿ｔｉｍｅは照会が最後に発せられた際のタイムスタンプである。
【０１４０】
ここまでは実行されておらず、かつ、無効化もされていない全ての照会例のセット（およびこれらの結果）については、以下のように公式化することができる。
ＦｆＡＧΠＡＰｖσＣｖ（Ｒ１×．．．×ＲＮ×ＱＩＴｂｌＱＴ）
ここで、ＡＰｖ＝ＡＰ  ∪  ｛ＱＩＤ｝、Ｃｖは、ＱＩＴｂｌＱＴにおいて、対応する属性名により各々のＶｉが置き換えられるように増大された条件Ｃである。
【０１４１】
「正の照会格子」
正の照会格子は、”ａｎｄ”ブール演算子により関連づけられた照会条件のシーケンスである。正の照会格子は、いつデータベースの変更が照会に影響を及ぼさなくなるのかを決定するための効率的な機構であり得る。その理由は、ある照会条件が満たされなければすぐに、データベースの変更が照会結果に影響を及ぼさなくなることが識別され、かつ、残りの照会条件を検査する必要がなくなるためである。
【０１４２】
概して、条件Ｃｖを、連言標準形で以下の通りに再書き込みできることを特筆しておく。
Ｃｖ  ＝  Ｃ１∧．．．∧Ｃｃ，
ここで、Ｃｊは副条件または副照会（ｗｈｅｒｅ節などにおいて用いられる集合）である。したがって、照会を、以下のように再書き込みすることもできる。
ＦｆＡＧΠＡＰｖ（σＣ１（Ｒ１×．．．×ＱＩＴｂｌＱＴ）∩．．．∩（σＣｃ（Ｒ１×．．．×ＱＩＴｂｌＱＴ））
または、
ＦｆＡＧΠＡＰｖ（σＣ１（Ｒ１×．．．×ＱＩＴｂｌＱＴ）∩．．．∩ΠＡＰｖσＣｃ（Ｒ１×．．．×ＱＩＴｂｌＱＴ））
【０１４３】
Ｒ１（ｓｙｎｃ１）が、ｓｙｎｃ１における関係Ｒの状態を表すものとする。これにより、ｓｙｎｃ２における関係Ｒ１の状態を、以下のように示すことができる。
Ｒ１（ｓｙｎｃ２）  ＝  Ｒ１（ｓｙｎｃ１）＋Δ＋（Ｒ１）−Δ−（Ｒ１）
ここで、Δ＋（Ｒ１）は関係Ｒ１に追加された新たな組であり、かつ、Δ−（Ｒ１）は関係Ｒ２に追加された削除組である。ｑｉｄに等しいＩＤを備えた照会例が与えられると、全てのＣｊに関して、
ｑｉｄ  ∈  ΠＱＩＤσＣｊ（Δ＋（Ｒ１）×．．．×ＱＩＴｂｌＱＴ）、または、
ｑｉｄ  ∈  ΠＱＩＤσＣｊ（Δ−（Ｒ１）×．．．×ＱＩＴｂｌＱＴ）
であることを包含する十分な証拠が存在すれば、ｑｉｄというＩＤを備えた照会例を無効にする必要がある。余分の情報を保持することにより、過剰な無効化量を低減させるために関数ｆの意味を用いることができることを特筆しておく。例えば、集合関数をａｖｇ（Ａ１）とすれば、ａｖｇ（Ａ１）およびｓｙｎｃ１におけるｃｏｕｎｔ（ＡＧ）の値が既知であれば、Δ＋（Ｒ１）とΔ−（Ｒ１）とを用いて、ｓｙｎｃ２におけるａｖｇ（Ａ１）の値を決定することができる。
【０１４４】
Ｑ＝｛ｑ１，．．．，ｑｎ｝が全ての照会定義を示すものとする。これにより、Ｌｐ（Ｖｐ，Ｅｐ）（正の照会格子）は、方向をもつ非環式グラフとなり、ここで、Ｖｐにおける頂点は、照会（必ずしもＱにあるとは限らない）に対応し、かつ、Ｅｐにおける縁部は、（これらの照会間の）無効化関係に対応しており、これらの関係は以下の通りに定義される。
【数１】
0003620448.tif 000020
したがって、正の照会格子については、照会例を無効にしないという決定を伝達するために用いることができる。
【０１４５】
図１７は、例示的な正の照会格子を示す。この例においては、更新が左上の照会２９６（下記）に影響を及ぼさないことが既知であると仮定する。
【表１９】
0003620448.tif 000021
これにより、さらなる処理を行わずに、照会２９８（下記）もまた更新により影響を受けないと決定することができる。
【表２０】
0003620448.tif 000022
【０１４６】
以下の例は、新たに挿入、削除、または更新された組により、どの照会結果が影響を与えられたのかを識別することが可能となる方法を例示する。この例においては、本明細書において前述したように、照会ＱＵＥＲＹ２（下記）がウェブページ（ＵＲＬ２と称する）を生じさせるために発せられたと仮定する。
【表２１】
0003620448.tif 000023
【０１４７】
この照会が、１つ以上のテーブルを必要としかつ結合処理を備えることを特筆しておく。以下に、データベースログに基づいて、範囲挿入が行われかつ少数の組がテーブル”ｃａｒ”内に挿入されたと仮定する。挿入された組は、
（Ａｃｕｒａ，  ＴＬ，  ３０，０００）
（Ａｃｕｒａ，  ＲＬ，  ４０，０００）
（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５，０００）
（Ｔｏｙｏｔａ，  Ｃａｍｒｙ，  ２０，０００）
（Ｔｏｙｏｔａ，  ４Ｒｕｎｎｅｒ，  ３０，０００）
を有する。
【０１４８】
Δ＋（ｃａｒ）は、｛（Ａｃｕｒａ，  ＴＬ，  ３０，０００），（Ａｃｕｒａ，  ＲＬ，  ４０，０００），（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５，０００），（Ｔｏｙｏｔａ，  Ｃａｍｒｙ，  ２０，０００），（Ｔｏｙｏｔａ，  ４Ｒｕｎｎｅｒ，  ３０，０００）｝のセットである。一時的テーブルＴＥＭＰがΔ＋（ｃａｒ）のために作り出されると仮定する。照会ＱＵＥＲＹ２については、ＱＵＥＲＹ６（下記）に変換することができる。
【表２２】
0003620448.tif 000024
【０１４９】
ｍｉｌｅａｇｅ．ｍｏｄｅｌの値が有効であれば、Δ＋（ｃａｒ）のための一時的テーブルＴＥＭＰを無効化器内において作り出すことができ、かつ、照会処理をＱＵＥＲＹ６のために行えることを特筆しておく。照会結果が空白でなければ、ＵＲＬ２は範囲挿入処理により影響を与えられたことになる。しかしながら、ｍｉｌｅａｇｅ．ｍｏｄｅｌの値が有効でなければ、一時的テーブルＴＥＭＰをΔ＋（ｃａｒ）のためのＤＢＭＳ上において作り出すことができ、かつ、ＱＵＥＲＹ６のため照会処理をＤＢＭＳ上において行うことができる。同様に、照会結果が空白でなければ、ＵＲＬ２は範囲挿入処理により影響を与えられたことになる。あるいはまた、ｍｉｌｅａｇｅ．ｍｏｄｅｌ値に関する値が有効でなければ、該値をＤＢＭＳから要求することができる。ＤＢＭＳからデータをポーリングする照会は、以下の通りであってもよい。
【表２３】
0003620448.tif 000025
【０１５０】
他の例においては、以下のＱＵＥＲＹ７〜９が、ウェブページＵＲＬ７〜９を生じさせるために発せられたと仮定する。
【表２４】
0003620448.tif 000026
これら３つの照会が同じ形式のものであるので、照会例テーブルＱＩＴｂｌＱＴについては、以下の通りに、この照会形式のために作り出すことができる。
【表２５】
0003620448.tif 000027
ここで、照会形式は、以下の通りである。
【表２６】
0003620448.tif 000028
【０１５１】
これは、要求時間が示されていない簡略化されたテーブルであることを特筆しておく。さらに、データベースログに基づいて、範囲挿入が行われかつ少数の組がＤＢＭＳにおけるテーブル”ＣＡＲ”内に挿入されたと仮定する。挿入された組は、
（Ａｃｕｒａ，  ＴＬ，  ３００００）
（Ａｃｕｒａ，  ＲＬ，  ４００００）
（Ｔｏｙｏｔａ，  Ａｖａｌｏｎ，  ２５０００）
（Ｔｏｙｏｔａ，  Ｃａｍｒｙ，  ２００００）
（Ｔｏｙｏｔａ，  ４Ｒｕｎｎｅｒ，  ３００００）
である。
【０１５２】
挿入された組のための一時的テーブルについては、ｔｅｍｐ１として作り出すことができ、かつ、ＱＵＥＲＹ７〜９のためのＱＩＴｂｌＱＴについては、ｔｅｍｐ２として作り出すことができるとする。ＱＵＥＲＹ７〜９については、以下の照会に変換することができる。
【表２７】
0003620448.tif 000029
【０１５３】
照会の結果は、ＱＵＥＲＹ７，９であり、このことは、これら２つの照会を用いるウェブページを無効にする必要があることを意味する。
【０１５４】
照会形式が、以下の
【表２８】
0003620448.tif 000030
という照会形式に関して、
【表２９】
0003620448.tif 000031
であれば、これらの照会例および挿入された組については、以下の単一の照会表示に変換することができる。
【表３０】
0003620448.tif 000032
【０１５５】
この照会表示が、テーブルＴＥＭＰ１，２に基づいて応答できない照会条件ｔｅｍｐ１．ｍｏｄｅｌ＝ｍｉｌｅａｇｅ．ｍｏｄｅｌを有していることを特筆しておく。ｍｉｌｅａｇｅ．ｍｏｄｅｌ情報が有効でなければ、代わりに、以下の照会を、必要とする情報を回収するためにＤＢＭＳへ発することができる。
【表３１】
0003620448.tif 000033
【０１５６】
この照会の結果が、ただ１つの属性ｍｏｄｅｌを有するＴＥＭＰ３として記憶されると仮定する。これにより、無効化を検査するための上記の照会表示を、以下のように再書き込みすることができる。
【表３２】
0003620448.tif 000034
【０１５７】
照会結果は、範囲挿入により影響を与えられた結果を有する照会となる。完全かつ正式な記述は、照会Ｑ（＄ａ，＄ｂ，＄ｃ）を用いる例（本明細書において後述する）において与えられる。
【０１５８】
「負の照会格子」
負の照会格子は、”ｏｒ”ブール演算子により関連づけられた照会条件のシーケンスである。負の照会格子は、いつデータベースの変更が照会に影響を及ぼすのかを決定するための効率的な機構であり得る。その理由は、ある照会条件が満たされればすぐに、データベースの変更が照会結果に影響を及ぼすことが識別され、かつ、残りの照会条件を検査する必要がなくなるためである。
【０１５９】
条件Ｃｖを、以下の通りに再書き込みできることを特筆しておく。
Ｃｖ  ＝  Ｃ１∨．．．∨Ｃｃ，
ここで、Ｃｊは副条件または副照会（ｗｈｅｒｅ節などにおいて用いられる集合）である。この場合には、照会を、以下のように再書き込みすることもできる。
ＦｆＡＧΠＡＰｖ（σＣ１（Ｒ１×．．．×ＱＩＴｂｌＱＴ）∪．．．∪（σＣｃ（Ｒ１×．．．×ＱＩＴｂｌＱＴ））
または、
ＦｆＡＧΠＡＰｖ’（σＣ１（Ｒ１×．．．×ＱＩＴｂｌＱＴ）∪．．．∪ΠＡＰｖ’σＣｃ（Ｒ１×．．．×ＱＩＴｂｌＱＴ））
【０１６０】
任意のＣｊに関して、
ｑｉｄ  ∈  ΠＱＩＤσＣｊ（Δ＋（Ｒ１）×．．．×ＱＩＴｂｌＱＴ）、または、
ｑｉｄ  ∈  ΠＱＩＤσＣｊ（Δ−（Ｒ１）×．．．×ＱＩＴｂｌＱＴ）
であることを包含するのに十分な証拠が存在すれば、ｑｉｄというＩＤを備えた照会例を無効にする必要がある。
【０１６１】
Ｑ＝｛ｑ１，．．．，ｑｎ｝が全ての照会定義を示すものとする。これにより、Ｌｎ（Ｖｎ，Ｅｎ）（負の照会格子）は、方向をもつ非環式グラフとなり、ここで、Ｖｎにおける頂点は、照会（必ずしもＱにあるとは限らない）に対応し、かつ、Ｅｎにおける縁部は、（これらの照会間の）無効化関係に対応しており、これらの関係は以下の通りに定義される。
【数２】
0003620448.tif 000035
したがって、負の照会格子については、照会例を無効にするという決定を伝達するために用いることができる。
【０１６２】
図１８は、例示的な負の照会格子を示す。この例においては、更新が左上の照会３００（下記）に影響を及ぼすことが既知であると仮定する。
【表３３】
0003620448.tif 000036
【０１６３】
これにより、さらなる処理を行わずに、照会３０２（下記）もまた更新により影響を受けると決定することができる。
【表３４】
0003620448.tif 000037
【０１６４】
＜ＳＱＬ照会に基づくデータベースポーリング＞
このセクションは、様々なシンタックスの照会を処理する方法を列挙する。他の照会のように、これらの照会の結果については、結合索引を作り出しかつ維持するために用いることができることが理解されるべきである。
【０１６５】
「セレクト文」
Ｑ  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Ｔｂｌ、または、
Ｑ  ＝  ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  Ａ１  ＦＲＯＭ  Ｔｂｌ
という形式の照会に関し、ＤＢＭＳの変化Δ＋Ｔｂｌ，Δ−Ｔｂｌが与えられれば、無効化器／リフレッシュ器は、
Ｐ１  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Δ＋Ｔｂｌ、および、
Ｐ２  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Δ−Ｔｂｌ
が空白であるかどうかを評価することができる。
【０１６６】
「条件的セレクト文」
Ｑ  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Ｔｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  Ａ２，  ．．．）
という形式の照会に関し、照会を、以下のような、より小さな２つの照会に分割することができる。
Ｑ１  ＝  ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Ｔｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  Ａ２，  ．．．）
Ｑ２  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Ｑ１
Ｑ１がＤＢＭＳの変化Δ＋Ｔｂｌ，Δ−Ｔｂｌにより影響を受けるかどうかを決定するために、無効化器／リフレッシュ器は、
Ｓ１  ＝  ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Δ＋Ｔｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．）、および、
Ｓ２  ＝  ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Δ−Ｔｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．）
が空白であるかどうかを評価することができる。結果が空白であれば、Ｑ２に関して検査する必要はない。結果が空白でなければ、無効化器／リフレッシュ器は、
Ｐ１  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Ｓ１、および、
Ｐ２  ＝  ＳＥＬＥＣＴ  Ａ１  ＦＲＯＭ  Ｓ２
が空白であるかどうかを評価することができる。
【０１６７】
「照会変数を備えた条件的セレクト文」
Ｑ（Ｖ１，  Ｖ２，  ．．．）  ＝  ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Ｔｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  Ａ２，  ．．．，  Ｖ１，  Ｖ２，  ．．．）
という形式の照会に関し、このパラメータ照会を、以下のような非パラメータ照会として再書き込みすることができる。
ＱＩ  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  Ａ２，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ＱＩＴｂｌ．Ｖ２，  ．．．）
ここで、ＱＩＴｂｌは、まだ無効化されていない全ての照会例からなるテーブルである。ＤＢＭＳの変化Δ＋Ｔｂｌ，Δ−Ｔｂｌが与えられれば、
ＱＩ＋  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ＋Ｔｂｌ，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１  ．．．，  ＱＩＴｂｌ．Ｖ１，  ＱＩＴｂｌ．Ｖ２，  ．．．）
ＱＩ−  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ−Ｔｂｌ，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１  ．．．，  ＱＩＴｂｌ．Ｖ１，  ＱＩＴｂｌ．Ｖ２，  ．．．）
における全ての照会例を無効にすることができる。ＱＩ＋，ＱＩ−のいずれも、元のＤＢＭＳにアクセスする必要がないことを特筆しておく。
【０１６８】
「照会変数を備えた条件的結合文」
Ｑ（Ｖ１，  Ｖ２，  ．．．）  ＝  ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  Ｔｂｌ，  Ｔｂｌ２  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  Ａ２，  ．．．，  Ｖ１，  Ｖ２，  ．．．）
という形式の照会に関し、このパラメータ照会を、以下のような非パラメータ照会として再書き込みすることができる。
Ｑ’  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ１，  Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  Ａ２，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ＱＩＴｂｌ．Ｖ２，  ．．．）
ここで、ＱＩＴｂｌは、まだ無効化されていない全ての照会例からなるテーブルである。ＤＢＭＳの変化Δ＋Ｔｂｌ，Δ−Ｔｂｌ，Δ＋Ｔｂｌ２，Δ−Ｔｂｌ２が与えられれば、
ＱＩ１＋  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ１，  Δ＋Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ２＋  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ２，  Δ＋Ｔｂｌ１，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ３＋  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ＋Ｔｂｌ１，  Δ＋Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ４＋  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ−Ｔｂｌ１，  Δ−Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ１−  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ１，  Δ−Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ２−  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ２，  Δ−Ｔｂｌ１，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ３−  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ−Ｔｂｌ１，  Δ−Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
ＱＩ４−  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ＋Ｔｂｌ１，  Δ＋Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｃｏｎｄ（Ａ１，  ．．．，  ＱＩＴｂｌ．Ｖ１，  ．．．）
における全ての照会例を無効にすることができる。ＱＩ３＋，ＱＩ４＋，ＱＩ３−，ＱＩ４−については、ＤＢＭＳの外部で完全に実行することができる。これに対し、ＱＩ１＋，ＱＩ２＋，ＱＩ１−，ＱＩ２−は、元のテーブルへのアクセスを要求する。ＤＢＭＳへのアクセスを最小限にするために、元のテーブルへの参照を、照会から除去することができる。ＱＩが、無効にすべき照会例を記述していることを特筆しておく。同様に、損なわれない状態に維持される照会例については、
ＫＥＥＰ１  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ１１，  Δ＋Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ（．．．），
ＫＥＥＰ２  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ１２，  Δ＋Ｔｂｌ１，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ（．．．），
ＫＥＥＰ３  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ１１，  Δ−Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ（．．．），
ＫＥＥＰ４  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Ｔｂｌ２，  Δ−Ｔｂｌ１，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ（．．．）
により記述される。
【０１６９】
損なわれない状態に維持すべき照会例の記述が与えられれば、ＱＩ１＋，ＱＩ２＋，ＱＩ１−，ＱＩ２−により無効にされる照会例のセットを、以下の通りに見出すことができる。
ＱＩａｇｇ  ＝  （ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  ＱＩＴｂｌ）  ＭＩＮＵＳ  （ＫＥＥＰ１  ＵＮＩＯＮ  ＫＥＥＰ２  ＵＮＩＯＮ  ＫＥＥＰ３  ＵＮＩＯＮ  ＫＥＥＰ４）
ＱＩａｇｇは、ＱＩ１＋，ＱＩ２＋，ＱＩ１−，ＱＩ２−の代わりに用いられる。ＫＥＥＰもまた、少なくとも１つのベーステーブルへのアクセスを必要とするが、速度が必要不可欠であれば、以下のように、さらにΔファイルに制約することができることを特筆しておく。
ＫＥＥＰ’１  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ＋Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ’（．．．），
ＫＥＥＰ’２  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ＋Ｔｂｌ１，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ’（．．．），
ＫＥＥＰ’３  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ−Ｔｂｌ２，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ’（．．．），
ＫＥＥＰ’４  ＝  ＳＥＬＥＣＴ  ＱＩＴｂｌ．ＱＩＤ  ＦＲＯＭ  Δ−Ｔｂｌ１，  ＱＩＴｂｌ  ＷＨＥＲＥ  ｎｏｔ  ｃｏｎｄ’（．．．）
ここで、ｃｏｎｄ’は、対応するΔファイルとＱＩＴｂｌとを用いて応答できる条件の一部である。この作用は、ＫＥＥＰ’ｉ⊇ＫＥＥＰｉであれば無効化中（ｕｎｄｅｒ−ｖａｌｉｄａｔｉｏｎ）という結果となり、したがって、このことは、全てのｉに関して、ＫＥＥＰ’ｉ⊆ＫＥＥＰｉである場合にのみ用いられるべきであることを特筆しておく。
【０１７０】
「集合を備えたセレクト文」
Ｑ  ＝  ＳＥＬＥＣＴ  ｆｕｎｃ（Ａ１），  Ａ２  ＦＲＯＭ  Ｔｂｌ  ＧＲＯＵＰＢＹ  Ａ２
という形式の照会に関し、ＤＢＭＳの変化Δ＋Ｔｂｌ，Δ−Ｔｂｌが与えられれば、これらについては、特別な条件で処理することができる。
【０１７１】
「ＥＸＩＳＴＳを備えた入れ子状態の副照会」
【表３５】
0003620448.tif 000038
という形式の照会に関し、副照会の状態が空白状態から非空白状態に（またはこの逆方向に）変化した場合にのみ、Ｑが無効にされる。これは、評価するのに費用がかかりすぎることがあるので、Ｑの代わりに副照会を無効にすることができる。副照会の結果に何らかの変化が生じれば、Ｑに関する結果もまた変化すると仮定することができる。このことについては、結合照会と、変数を備えた照会と、より複雑な条件を備えた照会とに拡張することができる。
【０１７２】
「さらに入れ子状態にされた副照会」
【表３６】
0003620448.tif 000039
という形式の照会に関し（ここで、ＡはテーブルＴｂｌ内の属性）、これらは、評価するのに費用がかかりすぎることがあるので、Ｑの代わりに副照会を無効にすることができる。副照会の結果に何らかの変化が生じれば、Ｑの結果もまた変化すると仮定することができる。このことについては、結合照会と、変数を備えた照会とに拡張することができる。
【０１７３】
「セット処理」
【表３７】
0003620448.tif 000040
という形式の照会に関し、これらは、評価するのに費用がかかりすぎることがあるので、Ｑの代わりに２つの副照会を無効にすることができる。これらの副照会のいずれかにおいて何らかの変化が生じれば、Ｑの結果もまた変化すると仮定することができる。このことについては、結合照会と、変数を備えた照会とに拡張することができる。
【０１７４】
例えば、以下の照会が与えられると、
【表３８】
0003620448.tif 000041
この照会を、以下の照会に変換することができる。
【表３９】
0003620448.tif 000042
次に、この照会を、以下の断片に分割することができる。
【表４０】
0003620448.tif 000043
テーブルＲ１に対する挿入のセットΔＲ１が存在すると仮定する。これらの断片については、さらに、以下のように、正確なものとすることができる。
【表４１】
0003620448.tif 000044
最後の照会は評価するのに費用がかかりすぎることがあるので、該最後の照会を、以下の通りに分割できることを特筆しておく。
【表４２】
0003620448.tif 000045
【０１７５】
無効にするための照会例のセットは、全ての照会（すなわち、全ての結果の共通部分）により戻される照会例のセットである。処理速度を上げるために、これらのポーリング照会のうちの幾つかを除去するか、または、より（潜在的に過剰な無効化を引き起こす）安価なポーリング照会に置き換えることができることを特筆しておく。
【０１７６】
元のＤＢＭＳはテーブルΔＲ１，ＱＩを有していないので、上記の照会については、以下の通りに再書き込みすることができる。
【表４３】
0003620448.tif 000046
したがって、３つのポーリング照会例（ＰｏｌｌＱ）をＤＢＭＳへ発する必要がある（または、関連する情報をＤＢＭＳの外部に維持することができる）。
【０１７７】
「追加のコメント」
前述の記載は、図３〜図１０に例示した５つのインテリジェントウェブページキャッシュおよびリフレッシュ機構と、図１１〜図１３に例示した３つのコンテント変更モニター部品とを説明した。さらに、コンテント変更モニター部品内に存在してもまたは該コンテント変更モニター部品と協同で作用してもよいインテリジェント無効化器／リフレッシュ器について説明してきた。本発明の他の実施形態において、任意のコンテント変更モニター部品を、インテリジェントウェブページキャッシュ／リフレッシュ機構およびインテリジェント無効化器／リフレッシュ器のいずれと協同しても使用できることが理解されるべきである。さらに、本明細書において説明した任意の機能ブロックを、異なるサーバー内または同じサーバー内に物理的に配置することができる。考えられる上述の組み合わせのいずれに関しても、ＣａｃｈｅＰｏｒｔａｌまたは他のコンテント配布サービスプロバイダが、コンテント変更モニター部品またはインテリジェント無効化器／リフレッシュ器を有し、かつ、記憶されたコンテントの無効化またはリフレッシュを行うことも可能である。
【０１７８】
本明細書において説明したコンテント変更モニター部品およびインテリジェント無効化器／リフレッシュ器を、時には、単一システム内で協同して使用できることがさらに理解されるべきである。照会は、より効率的な性能を達成するために、特定の機構を用いることができる。例えば、頻繁に用いられる照会は、概して、データベース内のプログラムの一部であるためにより高速であるトリガ定義の速度に適している。しかしながら、複雑な照会は、概して、ビュー定義に適している。その理由は、トリガ定義を用いて複雑な照会を定義することは非常に困難なためである。さらに、稀にしか用いられない照会例に関しては、何らかの種類の外部サーバーを用いることができる。
【０１７９】
コンテント変更モニター部品は、特定の照会を検査することができ、かつ、ビュー定義、トリガ定義、または、外部サーバーが用いられるべきかどうかを決定するプログラムを実行することができる。例えば、照会例が単一のデータベースにアクセスすれば、プログラムはトリガ定義を選択することができる。多数のデータベース照会または結合処理に対して、プログラムはビュー定義を選択することができる。稀にしか用いられない照会に関して、プログラムは、外部サーバーを選択することができる。
【０１８０】
呼び出されるべきＤＢＭＳが多数存在する場合に、アクセスすべきＤＢＭＳの位置および名前を識別する記憶された手順またはＡＰＩ呼に対し、さらなるストリングを追加する必要があることもまた理解されるべきである。多数のデータベースにアクセスすることが必要である追加情報は、ユーザーの氏名およびパスワードのような情報である。
【０１８１】
したがって、本発明の実施形態は、キャッシュに記憶されたデータとＤＢＭＳに記憶されたデータとを同期させるための、ウェブコンテントのインテリジェントキャッシュおよびリフレッシュのためのシステムおよび方法を提供する。本発明の実施形態は、ＤＢＭＳ内のデータが変化すると、該データを利用するウェブページが無効にされるウェブコンテントのインテリジェントキャッシュおよびリフレッシュのためのシステムおよび方法をも提供する。さらに、本発明の実施形態は、ＤＢＭＳ内のデータが変化すると、該データを利用するウェブページがリフレッシュされるウェブコンテントのインテリジェントキャッシュおよびリフレッシュのためのシステムおよび方法をも提供する。
【図面の簡単な説明】
【図１】エンドユーザーとウェブサイトとの間の、従来のコンテント配布パスの一例を図示したブロック図である。
【図２】バックエンドシステムを持つウェブサイトの、典型的なウェブページ配布機構の概略を図示したブロック図である。
【図３】本発明の一実施形態による知的ウェブページのキャッシュとリフレッシュの機構を図示するブロック図である。
【図４】本発明の他の一実施形態による、アプリケーションサーバーが、ＵＲＬと、関連する照会あるいはオペレーションとの関係を維持する、知的ウェブページのキャッシュとリフレッシュの機構を図示するブロック図である。
【図５】本発明の他の実施形態による、図４の実施形態においてアプリケーションサーバーによってＵＲＬ／関連動作のマッピング表を作るためのソースコードを含むフローチャートである。
【図６】ＣａｃｈｅＰｏｒｔａｌＴＭ  ＡＰＩハンドラが、ＵＲＬと、関連する照会あるいはオペレーションとの間の関係を、本発明の他の実施形態によって維持する、知的ウェブページのキャッシュとリフレッシュの機構を図示するブロック図である。
【図７】本発明の他の実施形態による、図６の実施形態の  ＣａｃｈｅＰｏｒｔａｌＴＭＡＰＩハンドラによるＵＲＬ／関連動作マッピング表を作るためのソースコードを含むフローチャートである。
【図８】本発明の他の実施形態によって、アプリケーションサーバーがユーザーの要求を記憶済みの手続に変換するような、知的ウェブページのキャッシュとリフレッシュの機構を図示するブロック図である。
【図９】本発明の他の実施形態による、図８の実施形態の  ＣａｃｈｅＰｏｒｔａｌＴＭによるＵＲＬ／関連動作マッピング表を作るためのソースコードを含むフローチャートである。
【図１０】アプリケーションサーバー代理が、ＵＲＬとそれに関連する照会あるいはオペレーション間の関係を、本発明の他の実施形態によって維持するような知的ウェブページのキャッシュとリフレッシュの機構を図示するブロック図である。
【図１１】本発明の他の実施形態による、ヴューの定義を利用するコンテント変更監視機構を図示したブロック図である。
【図１２】本発明の他の実施形態による、トリガの定義を利用するコンテント変更監視機構を図示したブロック図である。
【図１３】本発明の他の実施形態による、外部システム内のコンテント変更監視機構を図示したブロック図である。
【図１４】本発明の一実施形態による、動的コンテントキャッシュと無効化とリフレッシュのシステムの全体的なアーキテクチャを図示したブロック図である。
【図１５】本発明の一実施形態による、知的無効化器／リフレッシュ器のアーキテクチャを図示したブロック図である。
【図１６】本発明の一実施形態による、動的コンテントキャッシュと無効化とリフレッシュのシステム内のスニッファ（ｓｎｉｆｆｅｒ）によりログされたデータベースの更新イベントとログ検索と照会例の時間線と一例としてのシークエンスを図示したものである。
【図１７】本発明の一実施形態による、正の照会格子を図示したフローチャートである。
【図１８】本発明の一実施形態による、負の照会格子を図示したフローチャートである。
【符号の説明】
１０  インテリジェントウェブページキャッシュおよびリフレッシュ機構
５４  キャッシュ
５２  エンドユーザー
５８  ウェブサーバー
７０  アプリケーションサーバー
７４  ＤＢＭＳ
９４  ＣａｃｈｅＰｏｒｔａｌ
１０４  コンテント変更モニター部品
１０８  アプリケーションサーバー
１１２  コンテント変更モニター部品
１１６  ＣａｃｈｅＰｏｒｔａｌ
１１８  キャッシュ
１２０  ウェブサーバー
１２６  アプリケーションサーバー
１３２  ＤＢＭＳ
１３４  外部ソース
１３８  コンテント変更モニター部品
１４２  ＣａｃｈｅＰｏｒｔａｌ
１４４  キャッシュ
１４６  ウェブサーバー
１５２  アプリケーションサーバー
１５４  ＤＢＭＳ
１５６  外部ソース
１６６  ＣａｃｈｅＰｏｒｔａｌ
１７２  キャッシュ
１７４  ウェブサーバー
１７６  アプリケーションサーバー
１７８  ＣａｃｈｅＰｏｒｔａｌ
１９４  ＤＢＭＳ
２００  アプリケーションサーバープロキシ
２０４  コンテント変更モニター部品
２０８  ＤＢＭＳ
２１２  外部ソース
２１４  ビュー定義
２１６  ビューテーブル
２２０  デーモン定義
２２２  コンテント変更モニター部品
２２６  トリガ定義
２２８  外部ソース
２３０  ＤＢＭＳ
２３２  デーモン定義
２３６  ＤＢＭＳ
２３８  外部ソース
２４８  インテリジェント無効化器／リフレッシュ器
２５０  スニッファ
２５２  無効化器／リフレッシュ器
２５４  ＱＩ／ＵＲＬマップ
２５６  キャッシュ
２５８  ウェブサーバー
２６０  ＤＢＭＳ
２７０  アプリケーションサーバー
２７２  無効化器／リフレッシュ器
２８０  補助データ構造
２８２  アプリケーションサーバー
２８８  ＤＢＭＳ
【図１】
0003620448.tif 000047
【図２】
0003620448.tif 000048
【図３】
0003620448.tif 000049
【図４】
0003620448.tif 000050
【図５】
0003620448.tif 000051
【図６】
0003620448.tif 000052
【図７】
0003620448.tif 000053
【図８】
0003620448.tif 000054
【図９】
0003620448.tif 000055
【図１０】
0003620448.tif 000056
【図１１】
0003620448.tif 000057
【図１２】
0003620448.tif 000058
【図１３】
0003620448.tif 000059
【図１４】
0003620448.tif 000060
【図１５】
0003620448.tif 000061
【図１６】
0003620448.tif 000062
【図１７】
0003620448.tif 000063
【図１８】
0003620448.tif 000064