JP3620448B2 - 動的に作られかつ静的であるウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法 - Google Patents

動的に作られかつ静的であるウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法 Download PDF

Info

Publication number
JP3620448B2
JP3620448B2 JP2000400915A JP2000400915A JP3620448B2 JP 3620448 B2 JP3620448 B2 JP 3620448B2 JP 2000400915 A JP2000400915 A JP 2000400915A JP 2000400915 A JP2000400915 A JP 2000400915A JP 3620448 B2 JP3620448 B2 JP 3620448B2
Authority
JP
Japan
Prior art keywords
query
web page
memory
data
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2000400915A
Other languages
English (en)
Other versions
JP2002032261A (ja
Inventor
ウェン−シャン・リー
カシム・セルカック・カンダン
ディワン・アグレウォール
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JP2002032261A publication Critical patent/JP2002032261A/ja
Application granted granted Critical
Publication of JP3620448B2 publication Critical patent/JP3620448B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99932—Access augmentation or optimizing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99939—Privileged access
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

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

Claims (164)

  1. ウェブページを記憶するための少なくとも一つの第１のメモリと、ウェブページを生成するのに使用するデータを記憶するための少なくとも一つの第２のメモリを含むメモリ管理システムと、を有するシステムであって、上記メモリ管理システムは、上記の少なくとも一つの第２のメモリ内に記憶されたデータのうち変更されたデータを識別することができ、かつ、上記の少なくとも一つの第２のメモリへの全ての処理を順番に含む少なくとも一つのデータベースのログを維持することができ、上記少なくとも一つの第２のメモリ内に記憶されたデータへの変更に基づいて、上記少なくとも一つの第１のメモリに記憶されたウェブページを更新するためのシステムにおいて、
    上記システムは、さらに、少なくとも一つのサーバーを有し、上記少なくとも一つのサーバーは、
    上記少なくとも一つの第１のメモリに記憶された各ウェブページと、当該ウェブページを生成するのに使用される上記少なくとも一つの第２のメモリ内に記憶されたデータと、の間のウェブページ−データ関係を維持し、
    上記メモリ管理システムからどのデータが変更されたかを識別する情報を受信し、
    受信した変更されたデータを識別する情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定し、
    上記変更されたデータに関係あるウェブページを含む上記少なくとも一つの第１のメモリに対して当該ウェブページを更新するための更新命令を伝える
    ようにプログラムされたことを特徴とするウェブページ更新システム。
  2. 上記の少なくとも一つのサーバーは、さらに、
    ＵＲＬを含むウェブコンテント要求を受信すると、当該ウェブコンテント要求に応じて、上記少なくとも一つの第２のメモリに対して少なくとも一つの照会あるいは処理を発し、
    上記ウェブコンテント要求のＵＲＬと上記照会あるいは処理との間のＵＲＬ−照会／処理関係を維持し、
    上記照会あるいは処理と、当該照会あるいは処理によりアクセスされる上記記憶されたデータと、の間の照会／処理−データ関係を維持し、
    上記ＵＲＬ−照会／処理関係および上記照会／処理−データ関係から、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出し、
    上記少なくとも一つの第１のメモリに記憶されたウェブページのうち、上記変更されたデータに関係するウェブページのロケーションを特定する
    ようにプログラムされたことを特徴とする請求項１記載のウェブページ更新システム。
  3. 上記の更新命令には、上記記憶されたウェブページを無効化あるいは削除するメッセージが含まれることを特徴とする請求項２記載のウェブページ更新システム。
  4. 上記の更新命令には、上記記憶されたウェブページをリフレッシュするメッセージが含まれることを特徴とする請求項２記載のウェブページ更新システム。
  5. もし、上記記憶されたウェブページがウェブサーバーの中にあれば、上記の更新命令には、新しいウェブページを生成し、上記のウェブサーバー内に上記の新しいウェブページを記憶するメッセージが含まれることを特徴とする請求項４記載のウェブページ更新システム。
  6. 上記の少なくとも一つのサーバーは、さらに、上記の受信したＵＲＬに対する要求および配布のタイムスタンプを含むウェブサーバーのログを維持し、
    上記照会あるいは処理に対する発行タイムスタンプを含む照会および処理のログを維持し、
    上記ウェブサーバーのログと上記照会および処理のログとから、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出し、
    上記変更されたデータの識別情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定する
    ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
  7. 上記の少なくとも一つのサーバーは、
    上記ウェブコンテント要求を受信し、上記ウェブサーバーのログを維持するようにプログラムされたウェブサーバーと、
    上記ウェブサーバーから回送されたウェブコンテント要求を受信し、上記の回送されたウェブコンテント要求に応えて上記の少なくとも一つの照会あるいは処理を上記の少なくとも一つの第２のメモリに発するようにプログラムされたアプリケーションサーバーと、
    上記の発せられた照会あるいは処理と当該照会あるいは処理によってアクセスされた記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
    上記照会および処理のログおよび上記ウェブサーバーのログから上記ウェブコンテント要求のＵＲＬと上記発せられた照会あるいは処理との関係を決定し、上記のコンテント変更モニターから上記変更されたデータと関係がある照会あるいは処理の識別情報を受信し、記憶されたウェブページのうちどのウェブページが上記変更されたデータと関係のある上記の照会あるいは処理と関係するかを決定し、上記変更されたデータと関係のある上記ウェブページを含む上記少なくとも一つの第１のメモリへ更新命令を送信する、ようにプログラムされたコンテント配布サービスサーバーと
    を含むことを特徴とする請求項６記載のウェブページ更新システム。
  8. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    特定の照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含む各照会に対するビューテーブルを定義し、
    上記のメモリ管理システムから変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、当該変更されたデータと関係ある照会はどれかを決定する
    ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
  9. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された処理を受信し、
    各処理に対してデーモンを定義し、該デーモンは、特定の処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータに対して基準を確立し、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記の変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
  10. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成し、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
  11. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項７記載のウェブページ更新システム。
  12. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項８記載のウェブページ更新システム。
  13. 要求／配布ログを読むことによってネットワークの通信量を知り、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例を集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成するためのスニッファをさらに含むことを特徴とする請求項６記載のウェブページ更新システム。
  14. 特定の記憶済みウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに対して、ある特定の記憶されたウェブページの無効性を知らせるための無効化モジュールと、
    上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
    を含むことを特徴とする請求項６記載のウェブページ更新システム。
  15. 上記の少なくとも一つのサーバーは、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
    ようにプログラムされることを特徴とする請求項６記載のウェブページ更新システム。
  16. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーはアクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーが、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
    上記変更されたデータがある特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に、ある定められた値によって置き換えられ、
    もし、上記変更されたデータがある特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
    ことを特徴とする請求項１５記載のウェブページ更新システム。
  17. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
    ようにプログラムされることを特徴とする請求項１６記載のウェブページ更新システム。
  18. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
    ことを特徴とする請求項１７記載のウェブページ更新システム。
  19. 上記の少なくとも一つのサーバーは、さらに、
    受信されたウェブコンテント要求に含まれるＵＲＬからのＵＲＬ／関連処理マッピングログと、上記のウェブコンテント要求に応えて上記の少なくとも一つの第２のメモリへ発せられた照会あるいは処理を維持し、
    上記の変更済みデータの同一性と、上記の発せられた照会あるいは処理と記憶済みデータとの間の上記の維持された関係と、上記のＵＲＬ／関連処理マッピングログとから、どの記憶済みウェブページが上記変更されたデータと関係があるかを決定する
    ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
  20. 上記の少なくとも一つのサーバーは、
    上記のＵＲＬ／関連処理マッピングログを維持し、回送されたウェブコンテント要求を受信し、上記の回送されたウェブコンテント要求に応えて上記の少なくとも一つの照会あるいは処理を、上記の少なくとも一つの第２のメモリに発するようにプログラムされたアプリケーションサーバーと、
    上記の発せられた照会あるいは処理と、上記の照会あるいは処理によってアクセスされる記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
    上記のコンテント変更モニターから上記変更されたデータと関係ある照会あるいは処理の識別情報を受信し、上記のＵＲＬ／関連処理マッピングログを受信し、上記記憶されたウェブページのうちどのウェブページが上記変更されたデータと関係ある上記の照会あるいは処理と関係するかを決定し、上記の更新命令を上記変更されたデータと関係ある上記記憶されたウェブページを含む上記の少なくとも一つの第１のメモリへ送信するようにプログラムされるコンテント配布サービスサーバーと
    を含むことを特徴とする請求項１９記載のウェブページ更新システム。
  21. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送られた照会を受信し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
    上記のメモリ管理システムから上記変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
    ようにプログラムされることを特徴とする請求項１９記載のウェブページ更新システム。
  22. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送られた処理を受信し、
    各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立し、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項２０記載のウェブページ更新システム。
  23. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成し、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項２０記載のウェブページ更新システム。
  24. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項２０記載のウェブページ更新システム。
  25. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項２１記載のウェブページ更新システム。
  26. 要求／配布ログを読むことによってネットワークの通信量を知るスニッファを含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成することを特徴とする請求項１９記載のウェブページ更新システム。
  27. 特定の記憶済みウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせるための無効化モジュールと、
    上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
    を含むことを特徴とする請求項１９記載のウェブページ更新システム。
  28. 少なくとも一つのサーバーは、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
    ようにプログラムされることを特徴とする請求項１９記載のウェブページ更新システム。
  29. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーはアクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーは、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
    上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換えられ、
    もし、上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
    ことを特徴とする請求項２８記載のウェブページ更新システム。
  30. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
    先に決定された値によって置き換えられた上記リンクされた照会条件の該当部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
    ようにプログラムされることを特徴とする請求項２９記載のウェブページ更新システム。
  31. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
    ことを特徴とする請求項３０記載のウェブページ更新システム。
  32. 上記の少なくとも一つのサーバーは、
    回送されたウェブコンテント要求を受信し、コンテント配布サービスプロバイダＡＰＩコールを発するようにプログラムされたアプリケーションサーバーと、
    コンテント配布サービスプロバイダＡＰＩコールを受信し、ＵＲＬ／関連処理マッピングログを維持し、上記のコンテント配布サービスプロバイダＡＰＩコールに応えて上記の少なくとも一つの照会あるいは処理を上記の少なくとも一つの第２のメモリへ発するようにプログラムされたコンテント配布サービスプロバイダＡＰＩハンドラと、
    上記の発せられた照会あるいは処理と上記照会あるいは処理によってアクセスされる記憶済みデータとの間の関係を維持し、いずれの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
    上記のコンテント変更モニターから上記変更されたデータと関係のある上記の照会あるいは処理の識別情報を受信し、上記のＵＲＬ／関連処理マッピングログを受信し、上記記憶されたウェブページのうちどのウェブページが上記変更されたデータと関係ある上記の照会あるいは処理と関係するかを決定し、上記の更新命令を上記変更されたデータと関係ある上記の記憶されたウェブページを含む上記の少なくとも一つの第１のメモリへ送信するようにプログラムされたコンテント配布サービスサーバーと
    を含むことを特徴とする請求項１９記載のウェブページ更新システム。
  33. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送られた照会を受信し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
    上記のメモリ管理システムから上記変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
    ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
  34. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送られた処理を受信し、
    各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立し、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
  35. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成し、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
  36. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項３２記載のウェブページ更新システム。
  37. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項３３記載のウェブページ更新システム。
  38. 上記の少なくとも一つのサーバーは、さらに
    受信したウェブコンテント要求を記憶済み手順へと変換し、
    上記の記憶済み手順の中に含まれる上記のＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた照会と、からデータベース照会ログを維持し、
    上記の記憶済み手順の中に含まれるＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた処理と、から処理ログを維持し、
    上記データベース照会ログと上記処理ログとからＵＲＬ／関連処理マッピングテーブルを生成し、
    上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と上記の記憶されたデータとの間の維持された関係と、上記のＵＲＬ／関連処理マッピングテーブルとから、上記記憶されたウェブページのいずれのウェブページが上記変更されたデータと関係があるかを決定する
    ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
  39. 上記の少なくとも一つのサーバーは、
    受信されたウェブコンテント要求を記憶済み手順へと変換し、上記の記憶済み手順に含まれるＵＲＬと、上記の記憶済み手順に応えて上記の少なくとも一つの第２のメモリに発せられた照会と、から上記のデータベース照会ログを生成し、記憶済み手順に含まれるＵＲＬと、上記の記憶済み手順に応えて上記の少なくとも一つの第２のメモリに発せられた処理と、から処理ログを生成するようにプログラムされたアプリケーションサーバーと、
    上記の発せられた照会あるいは処理と上記の照会あるいは処理によってアクセスされた記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
    上記のデータベース照会ログと上記の処理ログとからＵＲＬ／関連処理マッピングテーブルを生成し、上記の変更済みデータの識別情報と、上記の発せられた照会あるいは処理と上記の記憶されたデータとの間の維持された関係と、上記のＵＲＬ／関連処理マッピングテーブルとから、上記記憶されたウェブページのいずれのウェブページが上記変更されたデータと関係があるかを決定し、上記の更新命令を上記変更されたデータと関係ある記憶済みウェブページを含む上記の少なくとも一つの第１のメモリへと送信するためのコンテント配布サービスサーバーと
    を含むことを特徴とする請求項３８記載のウェブページ更新システム。
  40. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送られた照会を受信し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
    上記のメモリ管理システムから上記変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
    ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
  41. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送られた照会あるいは処理を受信し、
    各照会あるいは処理に対するデーモンを定義し、該デーモンは、当該照会あるいは処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立し、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
  42. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成し、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
  43. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項３９記載のウェブページ更新システム。
  44. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項４０記載のウェブページ更新システム。
  45. 要求／配布ログを読むことによってネットワークの通信量を知るスニッファを含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成することを特徴とする請求項３８記載のウェブページ更新システム。
  46. ある特定の記憶されたウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶されたウェブページの無効性を知らせるための無効化モジュールと、
    上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
    を含むことを特徴とする請求項３８記載のウェブページ更新システム。
  47. 少なくとも一つのサーバーは、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
    ようにプログラムされることを特徴とする請求項３８記載のウェブページ更新システム。
  48. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーは、アクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーが、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
    上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換えられ、
    もし、上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
    ことを特徴とする請求項４７記載のウェブページ更新システム。
  49. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
    ようにプログラムされることを特徴とする請求項４８記載のウェブページ更新システム。
  50. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
    ことを特徴とする請求項４９記載のウェブページ更新システム。
  51. 上記の少なくとも一つのサーバーは、さらに
    上記の受信したウェブコンテント要求からＵＲＬ情報を抽出し、
    上記の発せられた照会および処理から照会と処理とを抽出し、
    上記の抽出されたＵＲＬ情報と上記の抽出された照会および処理情報とからＵＲＬ／関連処理マッピングログを維持し、
    上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と記憶されたデータとの間の維持される関係と、上記のＵＲＬ／関連処理マッピングログとから、上記記憶されたウェブページの中でいずれのウェブページが上記変更されたデータと関係あるかを決定する
    ようにプログラムされることを特徴とする請求項２記載のウェブページ更新システム。
  52. 上記の少なくとも一つのサーバーは、
    上記の受信されたウェブコンテント要求からＵＲＬ情報を抽出し、上記の発せられた照会と処理とから照会情報と処理情報とをそれぞれ抽出し、上記の受信されたウェブコンテント要求を回送し、上記のＵＲＬ／関連処理マッピングログを維持するためのアプリケーションサーバープロキシと、
    上記アプリケーションサーバープロキシによって回送されるウェブサーバー要求を受信し、上記の回送されたウェブコンテント要求に応えて上記の少なくとも一つの照会あるいは処理を発するためのアプリケーションサーバーと、
    上記の発せられた照会あるいは処理と上記の照会あるいは処理によってアクセスされた記憶済みデータとの間の関係を維持し、どの照会あるいは処理が上記変更されたデータと関係があるかを決定するようにプログラムされたコンテント変更モニターと、
    上記のコンテント変更モニターから上記変更されたデータと関係がある照会あるいは処理の識別情報を受信し、上記のＵＲＬ／関連処理マッピングログを受信し、上記記憶されたウェブページの中でどのウェブページが、上記変更されたデータと関係のある上記の照会あるいは処理と関係するかを決定し、上記変更されたデータと関係のある上記記憶されたウェブページを含む上記の少なくとも一つの第１のメモリへの更新命令を送信するようにプログラムされたコンテント配布サービスサーバーと
    を含むことを特徴とする請求項５１記載のウェブページ更新システム。
  53. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    照会ごとに、当該照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
    上記のメモリ管理システムから上記変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係ある照会はどれかを決定する
    ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
  54. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された処理を受信し、
    各処理に対してデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立し、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変 更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
  55. 上記のコンテント変更モニターは、
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成し、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する
    ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
  56. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させ、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項５２記載のウェブページ更新システム。
  57. 上記のコンテント変更モニターは、
    少なくとも一つの第３のメモリを持ち、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行し、
    照会ごとに、当該照会と関係ある上記の少なくとも一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する
    ようにプログラムされることを特徴とする請求項５３記載のウェブページ更新システム。
  58. 要求／配布ログを読むことによってネットワークの通信量を知るスニッファを含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成することを特徴とする請求項５１記載のウェブページ更新システム。
  59. 特定の記憶済みウェブページが無効であることを適切なキャッシュあるいはウェブサーバーに知らせるための無効化器／リフレッシュ器をさらに含み、該無効化器／リフレッシュ器は、
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集めるための登録モジュールと、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理の間との関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせるための無効化モジュールと、
    上記無効化モジュールのために予備データ構造を作る情報管理モジュールと
    を含むことを特徴とする請求項５１記載のウェブページ更新システム。
  60. 少なくとも一つのサーバーは、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別し、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する
    ようにプログラムされることを特徴とする請求項５１記載のウェブページ更新システム。
  61. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の少なくとも一つのサーバーはアクセスが必要である各テーブルに対して、さらに、上記の少なくとも一つのサーバーが、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定するようにプログラムされ、
    上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、特定のテーブルに限られたリンクされた照会条件の該当部分は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換えられ、
    もし、上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかが決定される間のいかなる時でも、上記のリンクされた照会条件が満足されると決定されると、上記変更されたデータが上記のリンクされた照会条件を満足する
    ことを特徴とする請求項６０記載のウェブページ更新システム。
  62. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の少なくとも一つのサーバーは、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する
    ようにプログラムされることを特徴とする請求項６１記載のウェブページ更新システム。
  63. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の決定されていた値は索引構造の中に記憶され、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の索引構造は、上記の少なくとも一つのサーバーによってアクセスされて上記の同じ副照会を発しなくてはならないということを避ける
    ことを特徴とする請求項６２記載のウェブページ更新システム。
  64. ウェブページを記憶するための少なくとも一つの第１のメモリと、ウェブページを生成するのに使用するデータを記憶するための少なくとも一つの第２のメモリを含むメモリ管理システムと、を有するシステムにおいて、上記メモリ管理システムは、上記の少なくとも一つの第２のメモリ内に記憶されたデータのうち変更されたデータを識別することができ、かつ、上記の少なくとも一つの第２のメモリへの全ての処理を順番に含む少なくとも一つのデータベースのログを維持することができ、上記少なくとも一つの第２のメモリ内に記憶されたデータへの変更に基づいて、上記少なくとも一つの第１のメモリに記憶されたウェブページを更新するための方法において、
    上記少なくとも一つの第１のメモリに記憶された各ウェブページと、当該ウェブページを生成するのに使用される上記少なくとも一つの第２のメモリ内に記憶されたデータと、の間のウェブページ−データ関係を維持する段階と、
    上記メモリ管理システムからどのデータが変更されたかを識別する情報を受信する段階と、
    受信した変更されたデータを識別する情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定する段階と、
    上記変更されたデータに関係あるウェブページを含む上記少なくとも一つの第１のメモリに対して当該ウェブページを更新するための更新命令を送る段階と
    を備えることを特徴とするウェブページ更新方法。
  65. 上記の方法は、さらに、
    ＵＲＬを含むウェブコンテント要求を受信する段階と、
    上記少なくとも一つの第２のメモリに対して少なくとも一つの照会あるいは処理を発する段階と、
    上記ウェブコンテント要求のＵＲＬと上記照会あるいは処理との間のＵＲＬ−照会／処理関係を維持する段階と、
    上記照会あるいは処理と、当該照会あるいは処理によりアクセスされる上記記憶されたデータと、の間の照会／処理−データ関係を維持する段階と、
    上記ＵＲＬ−照会／処理関係および上記照会／処理−データ関係から、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出す段階と、
    上記少なくとも一つの第１のメモリに記憶されたウェブページのうち、上記変更されたデータに関係するウェブページのロケーションを識別する段階と
    を含むことを特徴とする請求項６４記載のウェブページ更新方法。
  66. 更新命令を送る上記の段階は、上記記憶されたウェブページを無効化あるいは削除するメッセージを送ることを含むことを特徴とする請求項６５記載のウェブページ更新方法。
  67. 更新命令を送る上記の段階は、上記記憶されたウェブページをリフレッシュするメッセージを送ることを含むことを特徴とする請求項６５記載のウェブページ更新方法。
  68. もし上記記憶されたウェブページがウェブサーバーの中にあれば、更新命令を送る上記の段階は、新しいウェブページを生成するメッセージを送り、かつ上記のウェブページをウェブサーバーの中に記憶することを含むことを特徴とする請求項６７記載のウェブページ更新方法。
  69. 上記の方法は、さらに、
    上記の受信したＵＲＬに対する要求および配布のタイムスタンプを含むウェブサーバーのログを維持する段階と、
    上記照会あるいは処理に対する発行タイムスタンプを含む照会および処理のログを維持する段階と、
    上記ウェブサーバーのログと上記照会および処理のログとから、上記記憶されたウェブページと上記記憶されたデータとの間のウェブページ−データ関係を引き出す段階と、
    上記変更されたデータの識別情報と上記ウェブページ−データ関係とから、上記記憶されたウェブページのいずれが上記変更されたデータと関係があるかを決定する段階と
    を含むことを特徴とする請求項６５記載のウェブページ更新方法。
  70. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
    特定の照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含む各照会に対するビューテーブルを定義する段階と、
    上記のメモリ管理システムから変更されたデータを受信する段階と、
    上記のビューテーブルと上記変更されたデータとから、当該変更されたデータと関係ある照会はどれかを決定する段階と
    を含むことを特徴とする請求項６９記載のウェブページ更新方法。
  71. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された処理を受信する段階と、
    各処理に対してデーモンを定義し、該デーモンは、特定の処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立する段階と、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項６９記載のウェブページ更新方法。
  72. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成する段階と、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項６９記載のウェブページ更新方法。
  73. 上記の方法は、さらに、
    上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させる段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項７０記載のウェブページ更新方法。
  74. 上記の方法は、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項７０記載のウェブページ更新方法。
  75. 要求／配布ログを読むことによってネットワークの通信量を知る段階と、
    照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例を集める段階と、
    上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階と
    をさらに含むことを特徴とする請求項６９記載のウェブページ更新方法。
  76. 上記の方法は、さらに
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集める登録段階と、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに対して、ある特定の記憶されたウェブページの無効性を知らせる無効化段階と、
    予備データ構造を作る段階と
    を含むことを特徴とする請求項６９記載のウェブページ更新方法。
  77. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
    を含むことを特徴とする請求項６９記載のウェブページ更新方法。
  78. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
    上記変更されたデータがある特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、特定のテーブルに限られたリンクされた照会条件のそれらの部分を、他の特定のテーブルに限られたリンクされた照会条件のそれらの部分を評価する前に定められた値によって置き換える段階をさらに含み、
    もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
    ことを特徴とする請求項７７記載のウェブページ更新方法。
  79. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
    を含むことを特徴とする請求項７８記載のウェブページ更新方法。
  80. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
    ことを特徴とする請求項７９記載のウェブページ更新方法。
  81. 上記の方法は、さらに
    受信されたウェブコンテント要求に含まれるＵＲＬからのＵＲＬ／関連処理マッピングログと、上記のウェブコンテント要求に応えて上記の少なくとも一つの第２のメモリへ発せられた照会あるいは処理を維持する段階と、
    上記の変更済みデータの同一性と、上記の発せられた照会あるいは処理と記憶済みデータとの間の上記の維持された関係と、上記のＵＲＬ／関連処理マッピングログとから、どの記憶済みウェブページが上記変更されたデータと関係があるかを決定する段階と
    を含むことを特徴とする請求項６５記載のウェブページ更新方法。
  82. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送られた照会を受信する段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と、
    上記のメモリ管理システムから上記変更されたデータを受信し、上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する段階と
    を含むことを特徴とする請求項８１記載のウェブページ更新方法。
  83. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送られた処理を受信する段階と、
    各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立する段階と、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項８１記載のウェブページ更新方法。
  84. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の記憶されたデータを識別する基準を確立するトリガー定義を生成する段階と、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項８１記載のウェブページ更新方法。
  85. 上記の方法は、さらに
    少なくとも一つの第３のメモリを持ち、さらに、上記の少なくとも一つの第２のメモリから上記の少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリと一致させる段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項８２記載のウェブページ更新方法。
  86. 上記の方法は、さらに
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項８２記載のウェブページ更新方法。
  87. 要求／配布ログを読むことによってネットワークの通信量を知る段階を含み、照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集め、上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階を含むことを特徴とする請求項８１記載のウェブページ更新方法。
  88. 上記の方法は、さらに
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集める段階と、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせる段階と、
    予備データ構造を作る段階と
    を含むことを特徴とする請求項８１記載のウェブページ更新方法。
  89. 上記方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
    を含むことを特徴とする請求項８１記載のウェブページ更新方法。
  90. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータがその特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
    上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、特定のテーブルに限られたリンクされた照会条件の該当部分を、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換える段階をさらに含み、
    もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
    ことを特徴とする請求項８９記載のウェブページ更新方法。
  91. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
    を含むことを特徴とする請求項９０記載のウェブページ更新方法。
  92. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
    ことを特徴とする請求項９１記載のウェブページ更新方法。
  93. 上記の方法は、さらに
    受信したウェブコンテント要求を記憶済み手順へと変換する段階と、
    上記の記憶済み手順の中に含まれる上記のＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた照会と、からデータベース照会ログを維持する段階と、
    上記の記憶済み手順の中に含まれるＵＲＬと、上記の記憶済み手順に応じて上記の少なくとも一つの第２のメモリへ発せられた処理と、から処理ログを維持する段階と、
    上記データベース照会ログと上記処理ログとからＵＲＬ／関連処理マッピングテーブルを生成する段階と、
    上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と上記の記憶されたデータとの間の維持された関係と、上記のＵＲＬ／関連処理マッピングテーブルとから、上記記憶されたウェブページのいずれのウェブページが上記変更されたデータと関係があるかを決定する段階と
    を含むことを特徴とする請求項６５記載のウェブページ更新方法。
  94. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送られた照会を受信し、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
    上記のメモリ管理システムから上記変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
    ようにプログラムされることを特徴とする請求項９３記載のウェブページ更新方法。
  95. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送られた照会あるいは処理を受信する段階と、
    各照会あるいは処理に対するデーモンを定義し、該デーモンは、当該照会あるいは処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータに対して基準を確立する段階と、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項９３記載のウェブページ更新方法。
  96. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成する段階と、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項９３記載のウェブページ更新方法。
  97. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリから少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを少なくとも一つの第２のメモリと一致させる段階と、
    特定の照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含む各照会に対するビューテーブルを定義する段階と
    を含むことを特徴とする請求項９４記載のウェブページ更新方法。
  98. 上記の方法は、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させるために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項９４記載のウェブページ更新方法。
  99. 要求／配布ログを読むことによってネットワークの更新を知る段階と、
    照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集める段階と、
    上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階と
    をさらに含むことを特徴とする請求項９３記載のウェブページ更新方法。
  100. 上記の方法は、さらに
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集める段階と、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶されたウェブページの無効性を知らせる段階と、
    予備データ構造を作る段階と
    を含むことを特徴とする請求項９３記載のウェブページ更新方法。
  101. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
    を含むことを特徴とする請求項９３記載のウェブページ更新方法。
  102. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
    上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に、特定のテーブルに限られたリンクされた照会条件の該当部分を、定められた値によって置き換える段階をさらに含み、
    もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
    ことを特徴とする請求項１０１記載のウェブページ更新方法。
  103. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
    を含むことを特徴とする請求項１０２記載のウェブページ更新方法。
  104. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
    ことを特徴とする請求項１０３記載のウェブページ更新方法。
  105. 上記の方法は、さらに
    上記の受信したウェブコンテント要求からＵＲＬ情報を抽出する段階と、
    上記の発せられた照会および処理から照会と処理とを抽出する段階と、
    上記の抽出されたＵＲＬ情報と上記の抽出された照会および処理情報とからＵＲＬ／関連処理マッピングログを維持する段階と、
    上記変更されたデータの識別情報と、上記の発せられた照会あるいは処理と記憶されたデータとの間の維持される関係と、上記のＵＲＬ／関連処理マッピングログとから、上記記憶されたウェブページの中でいずれのウェブページが上記変更されたデータと関係あるかを決定する段階と
    を含むことを特徴とする請求項６５記載のウェブページ更新方法。
  106. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送られた照会を受信し、
    照会ごとに、当該照会と関係ある上記の少なくとも一つの第２のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義し、
    上記のメモリ管理システムから上記変更されたデータを受信し、
    上記のビューテーブルと上記変更されたデータとから、上記変更されたデータと関係がある照会を決定する
    ようにプログラムされることを特徴とする請求項１０５記載のウェブページ更新方法。
  107. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送られた処理を受信する段階と、
    各処理に対するデーモンを定義し、該デーモンは、当該処理に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータに対して基準を確立する段階と、
    上記変更されたデータが上記のデーモンを満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
  108. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信する段階と、
    各照会に対して、当該照会に関係ある上記の少なくとも一つの第２のメモリ内の変更されたデータを識別する基準を確立するトリガー定義を生成する段階と、
    上記変更されたデータが上記のトリガー定義を満足するかどうかを決定することで、上記変更されたデータと関係ある照会を決定する段階と
    を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
  109. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリから少なくとも一つの第３のメモリにデータを複製して、上記の少なくとも一つの第３のメモリを少なくとも一つの第２のメモリと一致させる段階と、
    照会ごとに、当該照会と関係ある上記の少なくとの一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項１０６記載のウェブページ更新方法。
  110. 上記の方法は、さらに、
    上記の少なくとも一つの第３のメモリを上記の少なくとも一つの第２のメモリに一致させために、順番に、上記の少なくとも一つの第３のメモリ上のデータベースのログ内の全ての処理を実行する段階と、
    照会ごとに、当該照会と関係ある上記の少なくとも一つの第３のメモリ内にある全てのデータを示すポインタを含むビューテーブルを定義する段階と
    を含むことを特徴とする請求項１０６記載のウェブページ更新方法。
  111. 要求／配布ログを読むことによってネットワークの通信量を知る段階と、
    照会例配布ログを読むことによってＵＲＬ情報と照会あるいは処理例とを集める段階と、
    上記のウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との間の関係を生成する段階と
    をさらに含むことを特徴とする請求項１０５記載のウェブページ更新方法。
  112. 上記の方法は、さらに
    無効化の方針を作り出し、関連のある照会あるいは処理統計を集める段階と、
    データベース更新ログと、上記ウェブコンテント要求のＵＲＬと上記の発せられた照会あるいは処理との関係と、を読み、副照会のスケジューリングをし、適切なキャッシュあるいはウェブサーバーに特定の記憶済みウェブページの無効性を知らせる段階と、
    予備データ構造を作る段階と
    を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
  113. 上記の方法は、さらに
    上記の少なくとも一つの第２のメモリに送信された照会を受信し、該照会は、操作者によってリンクされる一つあるいは二つ以上の照会条件を含み、該リンクされる照会条件は、その照会に関係ある少なくとも一つの第２のメモリ内のデータを識別する段階と、
    上記変更されたデータが上記のリンクされた照会条件を満足するかを決定することにより、上記の照会が上記変更されたデータと関係があるかどうかを決定する段階と
    を含むことを特徴とする請求項１０５記載のウェブページ更新方法。
  114. もし、上記のリンクされた照会条件が上記の少なくとも一つの第２のメモリ内の二つ以上のテーブルにアクセスする必要があるならば、上記の方法は、アクセスが必要である各テーブルに対して、上記変更されたデータが当該テーブルに限られたリンクされた照会条件の該当部分を満足するかどうかを決定する段階をさらに含み、
    上記変更されたデータが特定のテーブルに限られたリンクされた照会条件の該当部分を満足するかが決定された後に、上記方法は、特定のテーブルに限られたリンクされた照会条件の該当部分を、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価する前に定められた値によって置き換える段階をさらに含み、
    もし、いかなる時でも、上記のリンクされた照会条件が満足されると、上記変更されたデータが、リンクされた照会条件を満足することを決定する段階をさらに含む
    ことを特徴とする請求項１１３記載のウェブページ更新方法。
  115. 特定のテーブルに限られたリンクされた照会条件の該当部分が評価され、それらの部分に対する値が決定した後に、他の特定のテーブルに限られたリンクされた照会条件の該当部分を評価するために、上記の方法は、さらに
    先に決定された値によって置き換えられた上記のリンクされた照会条件の部分と共に、リンクされた照会条件を含む他の特定のテーブルへ副照会を発する段階
    を含むことを特徴とする請求項１１４記載のウェブページ更新方法。
  116. 特定のテーブルに発せられた副照会がその副照会のために決定されていた値を返した後に、上記の方法は定められた値を索引構造の中に記憶する段階をさらに含み、
    もし次の照会が、同じ副照会を発する必要がある少なくとも一つのサーバーによって受信されると、上記の方法は、上記の同じ副照会を発しなくてはならないということを避けるために上記の索引構造にアクセスする段階をさらに含む
    ことを特徴とする請求項１１５記載のウェブページ更新方法。
  117. 上記登録モジュールは、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
    ウェブコンテント要求のＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連することのない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
    結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定し、
    上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
    ことを特徴とする請求項１４記載のウェブページ更新システム。
  118. 結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１１７記載のウェブページ更新システム。
  119. 上記の無効化モジュールは、さらに
    いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
    ようにプログラムされ、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１４記載のウェブページ更新システム。
  120. 上記の情報管理モジュールは、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
    関係のある照会例を識別し、それらを整えられた方法で処理することにより照会例の合体を実行し、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
    ようにプログラムされることを特徴とする請求項１４記載のウェブページ更新システム。
  121. 上記の無効化器／リフレッシュ器は、さらに
    特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
    ようにプログラムされることを特徴とする請求項１４記載のウェブページ更新システム。
  122. 上記の無効化器／リフレッシュ器は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項１４記載のウェブページ更新システム。
  123. 上記登録モジュールは、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
    結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定し、
    上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
    ことを特徴とする請求項２７記載のウェブページ更新システム。
  124. 結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１２３記載のウェブページ更新システム。
  125. 上記の無効化モジュールは、さらに
    いずれのデータベースポーリング要求が生成されるべきかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
    ようにプログラムされ、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項２７記載のウェブページ更新システム。
  126. 上記の情報管理モジュールは、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
    関係のある照会例を識別し、それらを整えられた方法で処理することにより照会例の合体を実行し、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
    ようにプログラムされることを特徴とする請求項２７記載のウェブページ更新システム。
  127. 上記の無効化器／リフレッシュ器は、さらに特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
    ようにプログラムされることを特徴とする請求項２７記載のウェブページ更新システム。
  128. 上記の無効化器／リフレッシュ器は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項２７記載のウェブページ更新システム。
  129. 上記登録モジュールは、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
    結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定するようにプログラムされ、
    上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
    ことを特徴とする請求項４６記載のウェブページ更新システム。
  130. 結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１２９記載のウェブページ更新システム。
  131. 上記の無効化モジュールは、さらに
    いずれのデータベースポーリング要求が生成されるべきかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
    ようにプログラムされ、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項４６記載のウェブページ更新システム。
  132. 上記の情報管理モジュールは、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
    関係のある照会例を識別し、それらを整えられた方法で処理することにより照会例の合体を実行し、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
    ようにプログラムされることを特徴とする請求項４６記載のウェブページ更新システム。
  133. 上記の無効化器／リフレッシュ器は、さらに
    特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
    ようにプログラムされることを特徴とする請求項４６記載のウェブページ更新システム。
  134. 上記の無効化器／リフレッシュ器は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項４６記載のウェブページ更新システム。
  135. 上記登録モジュールは、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
    結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定するようにプログラムされ、
    上記の記憶済みウェブページを更新することには、上記の記憶済みのウェブページのリフレッシュや無効化や削除が含まれる
    ことを特徴とする請求項５９記載のウェブページ更新システム。
  136. 結合索引が維持されるべきかどうかの上記の決定において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１３５記載のウェブページ更新システム。
  137. 上記の無効化モジュールは、さらに
    いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定し、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する
    ようにプログラムされ、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項５９記載のウェブページ更新システム。
  138. 上記の情報管理モジュールは、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行し、
    関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行し、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する
    ようにプログラムされることを特徴とする請求項５９記載のウェブページ更新システム。
  139. 上記の無効化器／リフレッシュ器は、さらに
    特定の照会に対して正の照会格子を形成し、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成し、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する
    ようにプログラムされることを特徴とする請求項５９記載のウェブページ更新システム。
  140. 上記の無効化器／リフレッシュ器は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定するようにプログラムされることを特徴とする請求項５９記載のウェブページ更新システム。
  141. 上記登録段階は、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶し、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録し、
    結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する
    段階を含むことを特徴とする請求項７６記載のウェブページ更新方法。
  142. 結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１４１記載のウェブページ更新方法。
  143. 上記の無効化段階は、さらに
    いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項７６記載のウェブページ更新方法。
  144. 上記の方法は、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
    関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入し、それらをグループとして処理することで更新の合体を実行する段階と
    を含むことを特徴とする請求項７６記載のウェブページ更新方法。
  145. 上記の方法は、さらに
    特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
    ことを特徴とする請求項７６記載のウェブページ更新方法。
  146. 上記の方法は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページをキャッシュしたり無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項７６記載のウェブページ更新方法。
  147. 上記登録段階は、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶する段階と、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録する段階と、結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項８８記載のウェブページ更新方法。
  148. 結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１４７記載のウェブページ更新方法。
  149. 上記の無効化段階は、さらに
    いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項８８記載のウェブページ更新方法。
  150. 上記の方法は、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
    関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する段階と
    を含むことを特徴とする請求項８８記載のウェブページ更新方法。
  151. 上記の方法は、さらに
    特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
    ことを特徴とする請求項８８記載のウェブページ更新方法。
  152. 上記の方法は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページを無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項８８記載のウェブページ更新方法。
  153. 上記登録段階は、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶する段階と、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録する段階と、
    結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１００記載のウェブページ更新方法。
  154. 結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１５３記載のウェブページ更新方法。
  155. 上記の無効化段階は、さらに
    いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１００記載のウェブページ更新方法。
  156. 上記の方法は、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
    関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する段階と
    を含むことを特徴とする請求項１００記載のウェブページ更新方法。
  157. 上記の方法は、さらに
    特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
    ことを特徴とする請求項１００記載のウェブページ更新方法。
  158. 上記の方法は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページを無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項１００記載のウェブページ更新方法。
  159. 上記登録段階は、さらに
    オフラインのモードにおいて、上記無効化器／リフレッシュ器が検出しなくてはならないそれらの照会の種類を登録し、かつ予備データ構造の中の登録済み照会の種類を記憶する段階と、
    ウェブコンテント要求ＵＲＬと発せられた照会あるいは処理の間の関連を調べ、既知の照会の種類に関連しない照会例を置き、その照会の種類を識別するのに照会例を分析し、識別された照会の種類をオンラインのモードで登録する段階と、結合索引の大きさや更新頻度あるいは照会頻度に基づいて、結合索引を維持するかどうかを決定する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１１２記載のウェブページ更新方法。
  160. 結合索引が維持されるべきかどうかの上記の決定の段階において、もし上記結合索引が所定値より小さいか、上記結合索引の更新頻度が所定頻度より低いか、データベースあるいは外部データソースの照会頻度が所定頻度より高いか、データベースあるいは外部データソースの照会費用が所定値より高いならば、前記結合索引が維持されることを特徴とする請求項１５９記載のウェブページ更新方法。
  161. 上記の無効化段階は、さらに
    いずれのデータベースポーリング要求が生成されなければならないかを識別するために、無効化方針と予備データ構造とを読むことでデータベースポーリング要求のスケジューリングをし、これらの要求がいつメモリ管理システムあるいは外部データソースに送られるべきかを決定する段階と、
    データベースポーリング要求をメモリ管理システムあるいは外部データソースによって読み取り可能な副照会あるいは副処理へと変換する段階と
    を含み、
    上記の記憶済みウェブページを更新することには、上記の記憶済みウェブページをリフレッシュしたり、無効化したり、削除したりすることが含まれることを特徴とする請求項１１２記載のウェブページ更新方法。
  162. 上記の方法は、さらに
    関係のある照会例を識別し、それらをグループとして処理することにより照会例の合体を実行する段階と、
    関係のある照会例を識別し、それらを整えられた方法で処理ことにより照会例の合体を実行する段階と、
    関係のあるデータベースあるいは外部データソースの更新や削除や挿入を識別し、それらをグループとして処理することで更新の合体を実行する段階と
    を含むことを特徴とする請求項１１２記載のウェブページ更新方法。
  163. 上記の方法は、さらに
    特定の照会に対して正の照会格子を形成する段階を含み、この正の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響しないと決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    特定の照会に対して負の照会格子を形成する段階を含み、この負の照会格子は、もしデータベースあるいは外部のデータソースが検出され一連の照会条件が評価されると、一つの照会条件が満足されない時すぐに、上記のデータベースあるいは外部のデータソースの変更が上記の特定の照会に影響すると決定することができ、それ以上は照会条件は評価の必要がなくなるような順序で並べられた上記一連の照会条件を備え、
    いつデータベースあるいは外部データソースが照会に影響しないかを決定するための上記の正の照会格子を利用し、いつデータベースあるいは外部データソースが照会に影響するかを決定するための上記の負の照会格子を利用する段階を含む
    ことを特徴とする請求項１１２記載のウェブページ更新方法。
  164. 上記の方法は、さらに
    特定のウェブページ要求により作られる多くの複雑な照会に基づいて、上記の記憶済みウェブページを無効化したりリフレッシュしたりすべきかを決定する段階を含むことを特徴とする請求項１１２記載のウェブページ更新方法。
JP2000400915A 2000-07-14 2000-12-28 動的に作られかつ静的であるウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法 Expired - Fee Related JP3620448B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US21841800P 2000-07-14 2000-07-14
US09/639,208 US6591266B1 (en) 2000-07-14 2000-08-14 System and method for intelligent caching and refresh of dynamically generated and static web content
US218.418 2000-08-14
US639.208 2000-08-14

Publications (2)

Publication Number Publication Date
JP2002032261A JP2002032261A (ja) 2002-01-31
JP3620448B2 true JP3620448B2 (ja) 2005-02-16

Family

ID=26912891

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000400915A Expired - Fee Related JP3620448B2 (ja) 2000-07-14 2000-12-28 動的に作られかつ静的であるウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法

Country Status (2)

Country Link
US (1) US6591266B1 (ja)
JP (1) JP3620448B2 (ja)

Families Citing this family (207)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8156074B1 (en) 2000-01-26 2012-04-10 Synchronoss Technologies, Inc. Data transfer and synchronization system
US8611873B2 (en) 2004-05-12 2013-12-17 Synchronoss Technologies, Inc. Advanced contact identification system
US8620286B2 (en) 2004-02-27 2013-12-31 Synchronoss Technologies, Inc. Method and system for promoting and transferring licensed content and applications
US6671757B1 (en) 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
US6591266B1 (en) * 2000-07-14 2003-07-08 Nec Corporation System and method for intelligent caching and refresh of dynamically generated and static web content
US7895334B1 (en) 2000-07-19 2011-02-22 Fusionone, Inc. Remote access communication architecture apparatus and method
US8073954B1 (en) 2000-07-19 2011-12-06 Synchronoss Technologies, Inc. Method and apparatus for a secure remote access system
US7571217B1 (en) * 2000-08-16 2009-08-04 Parallel Networks, Llc Method and system for uniform resource locator transformation
US7171455B1 (en) 2000-08-22 2007-01-30 International Business Machines Corporation Object oriented based, business class methodology for generating quasi-static web pages at periodic intervals
US6886004B2 (en) * 2000-08-24 2005-04-26 Red Hat, Inc. Method and apparatus for atomic file look-up
US7069292B2 (en) * 2000-08-29 2006-06-27 Fujitsu Limited Automatic display method and apparatus for update information, and medium storing program for the method
US6853994B1 (en) * 2000-08-30 2005-02-08 International Business Machines Corporation Object oriented based, business class methodology for performing data metric analysis
JP2002091851A (ja) * 2000-09-12 2002-03-29 Toshiba Corp 情報提供方法および中継サーバ装置
US7010578B1 (en) * 2000-09-21 2006-03-07 Akamai Technologies, Inc. Internet content delivery service with third party cache interface support
US7596564B1 (en) * 2000-09-29 2009-09-29 Vignette Corporation Method and system for cache management of a cache including dynamically-generated content
US7111057B1 (en) * 2000-10-31 2006-09-19 Akamai Technologies, Inc. Method and system for purging content from a content delivery network
US7127492B1 (en) * 2000-10-31 2006-10-24 International Business Machines Corporation Method and apparatus for distributed application acceleration
US6834390B2 (en) * 2000-12-06 2004-12-21 Microsoft Corporation System and related interfaces supporting the processing of media content
US7114162B2 (en) 2000-12-06 2006-09-26 Microsoft Corporation System and methods for generating and managing filter strings in a filter graph
US6954581B2 (en) * 2000-12-06 2005-10-11 Microsoft Corporation Methods and systems for managing multiple inputs and methods and systems for processing media content
US6961943B2 (en) * 2000-12-06 2005-11-01 Microsoft Corporation Multimedia processing system parsing multimedia content from a single source to minimize instances of source files
US7287226B2 (en) 2000-12-06 2007-10-23 Microsoft Corporation Methods and systems for effecting video transitions represented by bitmaps
US6882891B2 (en) * 2000-12-06 2005-04-19 Microsoft Corporation Methods and systems for mixing digital audio signals
US7447754B2 (en) 2000-12-06 2008-11-04 Microsoft Corporation Methods and systems for processing multi-media editing projects
US6912717B2 (en) 2000-12-06 2005-06-28 Microsoft Corporation Methods and systems for implementing dynamic properties on objects that support only static properties
US6983466B2 (en) * 2000-12-06 2006-01-03 Microsoft Corporation Multimedia project processing systems and multimedia project processing matrix systems
US6959438B2 (en) * 2000-12-06 2005-10-25 Microsoft Corporation Interface and related methods for dynamically generating a filter graph in a development system
US6768499B2 (en) * 2000-12-06 2004-07-27 Microsoft Corporation Methods and systems for processing media content
US7103677B2 (en) 2000-12-06 2006-09-05 Microsoft Corporation Methods and systems for efficiently processing compressed and uncompressed media content
US6774919B2 (en) * 2000-12-06 2004-08-10 Microsoft Corporation Interface and related methods for reducing source accesses in a development system
US7114161B2 (en) * 2000-12-06 2006-09-26 Microsoft Corporation System and related methods for reducing memory requirements of a media processing system
US7818435B1 (en) * 2000-12-14 2010-10-19 Fusionone, Inc. Reverse proxy mechanism for retrieving electronic content associated with a local network
US6983318B2 (en) * 2001-01-22 2006-01-03 International Business Machines Corporation Cache management method and system for storing dynamic contents
US7107336B2 (en) * 2001-02-23 2006-09-12 International Business Machines Corporation Method and apparatus for enhanced server page execution
US8615566B1 (en) 2001-03-23 2013-12-24 Synchronoss Technologies, Inc. Apparatus and method for operational support of remote network systems
CA2342578A1 (en) * 2001-03-29 2002-09-29 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for security of a network server
US6931598B2 (en) * 2001-03-30 2005-08-16 Intel Corporation Dynamic web list display
US7398271B1 (en) * 2001-04-16 2008-07-08 Yahoo! Inc. Using network traffic logs for search enhancement
US7000008B2 (en) * 2001-04-16 2006-02-14 Sun Microsystems, Inc. Method, system, and program for providing data updates to a page including multiple regions of dynamic content
US6748386B1 (en) * 2001-04-24 2004-06-08 Nec Corporation System and method for automated construction of URL, cookie, and database query mapping
US6925515B2 (en) * 2001-05-07 2005-08-02 International Business Machines Corporation Producer/consumer locking system for efficient replication of file data
US6813633B2 (en) * 2001-06-19 2004-11-02 Foedero Technologies, Inc. Dynamic multi-level cache manager
JP2003006419A (ja) * 2001-06-22 2003-01-10 Seiko Epson Corp ネットワーク用情報管理システムおよび情報管理方法
US20030004998A1 (en) * 2001-06-29 2003-01-02 Chutney Technologies, Inc. Proxy-based acceleration of dynamically generated content
US6981029B1 (en) 2001-07-17 2005-12-27 Cisco Technology, Inc. System and method for processing a request for information in a network
US7054416B2 (en) * 2001-09-24 2006-05-30 Meyerson Robert F Modular multi-media communication management system
AUPR796701A0 (en) * 2001-09-27 2001-10-25 Plugged In Communications Pty Ltd Database query system and method
US6892277B1 (en) * 2001-09-28 2005-05-10 Lsi Logic Corporation System and method for optimizing remote data content distribution
US6708179B1 (en) * 2001-09-28 2004-03-16 Oracle International Corporation Incremental refresh of materialized views for many-to-many relationships
US6996694B1 (en) * 2001-10-24 2006-02-07 Oracle International Corporation Basing computer memory allocation for aggregate data types on data separate from a type definition
JP2003150594A (ja) * 2001-11-12 2003-05-23 Hitachi Ltd データウェアハウスシステム
US6769048B2 (en) * 2001-12-06 2004-07-27 Sun Microsystems, Inc. Cache synchronization method, system and apparatus for a distributed application and an object located in a client cache
US20030115346A1 (en) * 2001-12-13 2003-06-19 Mchenry Stephen T. Multi-proxy network edge cache system and methods
JP2003223378A (ja) * 2002-01-29 2003-08-08 Fujitsu Ltd コンテンツデリバリネットワークサービス方法及びシステム
US6826602B1 (en) * 2002-09-12 2004-11-30 Bellsouth Intellectual Property Corporation System and method for reverse content distribution
US6909721B2 (en) 2002-10-31 2005-06-21 Nokia Corporation Device detection and service discovery system and method for a mobile ad hoc communications network
WO2004046854A2 (en) * 2002-11-15 2004-06-03 Erick Von Schweber A method and apparatus for information surveying
JP4282312B2 (ja) * 2002-11-27 2009-06-17 富士通株式会社 Ｗｅｂサーバ、Ｊａｖａサーブレットの機能を有するＷｅｂサーバ、およびコンピュータプログラム
US20040109011A1 (en) * 2002-12-10 2004-06-10 International Business Machines Corporation Method, apparatus, and program for automatic client side refresh of advanced web pages
US7188216B1 (en) 2002-12-13 2007-03-06 Vignette Corporation Method and system for an extensible caching framework
US8312222B1 (en) * 2002-12-13 2012-11-13 Open Text, S.A. Event-driven regeneration of pages for web-based applications
US8463998B1 (en) 2002-12-13 2013-06-11 Open Text S.A. System and method for managing page variations in a page delivery cache
US7860820B1 (en) 2005-05-31 2010-12-28 Vignette Software, LLC System using content generator for dynamically regenerating one or more fragments of web page based on notification of content change
US8380932B1 (en) 2002-12-13 2013-02-19 Open Text S.A. Contextual regeneration of pages for web-based applications
US7360025B1 (en) * 2002-12-13 2008-04-15 O'connell Conleth Method and system for automatic cache management
US8924411B2 (en) 2005-05-31 2014-12-30 Open Text S.A. System and method for the dynamic provisioning of static content
US7818506B1 (en) * 2002-12-13 2010-10-19 Vignette Software Llc Method and system for cache management
US7624173B2 (en) * 2003-02-10 2009-11-24 International Business Machines Corporation Method and system for classifying content and prioritizing web site content issues
US20040162822A1 (en) * 2003-02-13 2004-08-19 Khachatur Papanyan Method and apparatus for converting in-line database queries to stored procedures
US7814413B2 (en) * 2003-04-17 2010-10-12 Oracle International Corporation System and method for controlling web pages
US7917483B2 (en) * 2003-04-24 2011-03-29 Affini, Inc. Search engine and method with improved relevancy, scope, and timeliness
US20040230744A1 (en) * 2003-05-17 2004-11-18 Teh Jin Teik Cache content protocol for a content data delivery system
US7765196B2 (en) * 2003-06-23 2010-07-27 Dell Products L.P. Method and apparatus for web cache using database triggers
US7624126B2 (en) * 2003-06-25 2009-11-24 Microsoft Corporation Registering for and retrieving database table change information that can be used to invalidate cache entries
EP1652048A4 (en) 2003-07-21 2009-04-15 Fusionone Inc ORDERING NEWS MANAGEMENT SYSTEM
US8238696B2 (en) 2003-08-21 2012-08-07 Microsoft Corporation Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system
US8131739B2 (en) 2003-08-21 2012-03-06 Microsoft Corporation Systems and methods for interfacing application programs with an item-based storage platform
US8166101B2 (en) 2003-08-21 2012-04-24 Microsoft Corporation Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US7590643B2 (en) * 2003-08-21 2009-09-15 Microsoft Corporation Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
US20050058109A1 (en) * 2003-09-16 2005-03-17 Jan-Erik Ekberg Mechanism for improving connection control in peer-to-peer ad-hoc networks
US7313120B2 (en) * 2003-09-16 2007-12-25 Nokia Corporation Application control in peer-to-peer ad-hoc communication networks
US7545941B2 (en) * 2003-09-16 2009-06-09 Nokia Corporation Method of initializing and using a security association for middleware based on physical proximity
US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
US7222117B1 (en) 2003-11-14 2007-05-22 Advent Software, Inc. Segmented global area database
US7509413B2 (en) * 2003-11-24 2009-03-24 International Business Machines Corporation Tool for displaying JMX monitoring information
US7433950B2 (en) * 2003-12-04 2008-10-07 International Business Machines Corporation Method and mechanism to multiplex multiple application server requests over a single database connection
US7421562B2 (en) * 2004-03-01 2008-09-02 Sybase, Inc. Database system providing methodology for extended memory support
US7451194B2 (en) * 2004-03-04 2008-11-11 International Business Machines Corporation Timely update of information displayed within a portal
US7263345B2 (en) * 2004-03-17 2007-08-28 Nokia Corporation System and method for remote service information
US20050210121A1 (en) * 2004-03-22 2005-09-22 Qualcomm Incorporated Satellite anticipatory bandwith acceleration
US9542076B1 (en) 2004-05-12 2017-01-10 Synchronoss Technologies, Inc. System for and method of updating a personal profile
US8495305B2 (en) * 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US8739274B2 (en) * 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
WO2006012610A2 (en) 2004-07-23 2006-02-02 Citrix Systems, Inc. Systems and methods for optimizing communications between network nodes
WO2006012612A1 (en) 2004-07-23 2006-02-02 Citrix Systems, Inc. A method and systems for securing remote access to private networks
US7693840B1 (en) * 2004-07-30 2010-04-06 Sprint Communications Company L.P. Method and system for distribution of common elements
US7836076B2 (en) * 2004-08-20 2010-11-16 Hewlett-Packard Development Company, L.P. Distributing content indices
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US7810089B2 (en) * 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
KR20070104566A (ko) * 2005-01-24 2007-10-26 사이트릭스 시스템스, 인크. 네트워크에서 동적으로 발생된 객체들의 캐싱을 수행하는시스템 및 방법
US7805422B2 (en) * 2005-02-28 2010-09-28 Microsoft Corporation Change notification query multiplexing
US7697894B2 (en) * 2005-03-01 2010-04-13 Nokia Corporation Method and system for tactile confirmation of service bookmarks
US7359674B2 (en) * 2005-05-10 2008-04-15 Nokia Corporation Content distribution & communication system for enhancing service distribution in short range radio environment
US9407608B2 (en) 2005-05-26 2016-08-02 Citrix Systems, Inc. Systems and methods for enhanced client side policy
US7756826B2 (en) 2006-06-30 2010-07-13 Citrix Systems, Inc. Method and systems for efficient delivery of previously stored content
US9621666B2 (en) 2005-05-26 2017-04-11 Citrix Systems, Inc. Systems and methods for enhanced delta compression
US7552117B2 (en) * 2005-05-26 2009-06-23 International Business Machines Corporation Using ontological relationships in a computer database
US8943304B2 (en) 2006-08-03 2015-01-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US9692725B2 (en) 2005-05-26 2017-06-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US20060268896A1 (en) * 2005-05-31 2006-11-30 Sakari Kotola System and method for services functionality
US20070005579A1 (en) * 2005-07-01 2007-01-04 Microsoft Corporation Query based synchronization
US20070067569A1 (en) * 2005-09-21 2007-03-22 Cisco Technology, Inc. Method and system for communicating validation information to a web cache
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US8122365B2 (en) * 2006-02-23 2012-02-21 Infosys Technologies, Ltd. System and method for dynamic creation and customization of a user interface in a web service environment
US20070203973A1 (en) * 2006-02-28 2007-08-30 Microsoft Corporation Fuzzing Requests And Responses Using A Proxy
JP4852326B2 (ja) * 2006-03-09 2012-01-11 株式会社野村総合研究所 サーバ装置
US20080059544A1 (en) * 2006-06-09 2008-03-06 Rick Rahim System and method for providing secure third party website histories
US7478118B2 (en) * 2006-06-29 2009-01-13 Research In Motion Limited Method and apparatus for synchronizing of databases connected by wireless interface
US8498961B2 (en) * 2006-07-13 2013-07-30 International Business Machines Corporation On-demand replication in a content management system
US7917507B2 (en) * 2007-02-12 2011-03-29 Microsoft Corporation Web data usage platform
US8429185B2 (en) 2007-02-12 2013-04-23 Microsoft Corporation Using structured data for online research
US20080155392A1 (en) * 2007-03-02 2008-06-26 Marengo Intellectual Property Ltd. Integrity Checker for Web Browser Document
US20080228864A1 (en) * 2007-03-12 2008-09-18 Robert Plamondon Systems and methods for prefetching non-cacheable content for compression history
US7809818B2 (en) * 2007-03-12 2010-10-05 Citrix Systems, Inc. Systems and method of using HTTP head command for prefetching
US7720936B2 (en) 2007-03-12 2010-05-18 Citrix Systems, Inc. Systems and methods of freshening and prefreshening a DNS cache
US8701010B2 (en) 2007-03-12 2014-04-15 Citrix Systems, Inc. Systems and methods of using the refresh button to determine freshness policy
US8037126B2 (en) 2007-03-12 2011-10-11 Citrix Systems, Inc. Systems and methods of dynamically checking freshness of cached objects based on link status
US8103783B2 (en) 2007-03-12 2012-01-24 Citrix Systems, Inc. Systems and methods of providing security and reliability to proxy caches
US7584294B2 (en) * 2007-03-12 2009-09-01 Citrix Systems, Inc. Systems and methods for prefetching objects for caching using QOS
US8074028B2 (en) 2007-03-12 2011-12-06 Citrix Systems, Inc. Systems and methods of providing a multi-tier cache
US8504775B2 (en) 2007-03-12 2013-08-06 Citrix Systems, Inc Systems and methods of prefreshening cached objects based on user's current web page
US7783757B2 (en) 2007-03-12 2010-08-24 Citrix Systems, Inc. Systems and methods of revalidating cached objects in parallel with request for object
US8489740B2 (en) * 2007-05-18 2013-07-16 Red Hat, Inc. Method and an apparatus to generate message authentication codes at a proxy server for validating a web session
US8452882B2 (en) * 2007-05-18 2013-05-28 Red Hat, Inc. Method and an apparatus to validate a web session in a proxy server
US8290986B2 (en) * 2007-06-27 2012-10-16 Yahoo! Inc. Determining quality measures for web objects based on searcher behavior
US7925694B2 (en) 2007-10-19 2011-04-12 Citrix Systems, Inc. Systems and methods for managing cookies via HTTP content layer
US20090132954A1 (en) * 2007-11-20 2009-05-21 Honeywell International Inc. Apparatus and method for isolating problems in content loaded into a human-machine interface application
US8181111B1 (en) 2007-12-31 2012-05-15 Synchronoss Technologies, Inc. System and method for providing social context to digital activity
US20090182707A1 (en) * 2008-01-10 2009-07-16 Dbix Corporation Database changeset management system and method
WO2009094657A1 (en) 2008-01-26 2009-07-30 Citrix Systems, Inc. Systems and methods for fine grain policy driven cookie proxying
US9418094B2 (en) * 2008-02-13 2016-08-16 Oracle International Corporation Method and apparatus for performing multi-stage table updates
US8180854B2 (en) * 2008-05-29 2012-05-15 Red Hat, Inc. Aspect services
US7881304B2 (en) * 2008-05-29 2011-02-01 Red Hat, Inc. Using distributed aspects to reorder online application workflows
US8103607B2 (en) * 2008-05-29 2012-01-24 Red Hat, Inc. System comprising a proxy server including a rules engine, a remote application server, and an aspect server for executing aspect services remotely
US8312384B2 (en) * 2008-06-11 2012-11-13 Honeywell International Inc. Apparatus and method for fault-tolerant presentation of multiple graphical displays in a process control system
US8244608B2 (en) * 2008-07-28 2012-08-14 Autodesk, Inc. Takeoff list palette for guiding semi-automatic quantity takeoff from computer aided design drawings
US8041893B1 (en) 2008-09-09 2011-10-18 Vignette Software Llc System and method for managing large filesystem-based caches
GB2465773A (en) * 2008-11-27 2010-06-02 Symbian Software Ltd Data Storage and Access
US8380930B2 (en) * 2009-01-06 2013-02-19 Disney Enterprises, Inc. Refreshing cached data based on content identifier map
US8458217B1 (en) 2009-08-24 2013-06-04 Advent Software, Inc. Instantly built information space (IBIS)
US8543608B2 (en) * 2009-09-10 2013-09-24 Oracle International Corporation Handling of expired web pages
US20110099185A1 (en) * 2009-10-28 2011-04-28 Yahoo! Inc. System for Querying and Consuming Web-Based Data and Associated Methods
US8407238B2 (en) * 2009-10-28 2013-03-26 Yahoo! Inc. System and methods for enabling arbitrary developer code consumption of web-based data
US8255006B1 (en) 2009-11-10 2012-08-28 Fusionone, Inc. Event dependent notification system and method
US8745639B2 (en) * 2009-12-31 2014-06-03 Cbs Interactive Inc. Controller and method to build a combined web page using data retrieved from multiple APIS
US20110302186A1 (en) * 2010-06-04 2011-12-08 Miguel Angel Pallares Lopez Method and Apparatus for Query Reformulation with Latency Preservation
US8898181B2 (en) * 2010-06-22 2014-11-25 Microsoft Corporation Subscription for integrating external data from external system
US8943428B2 (en) 2010-11-01 2015-01-27 Synchronoss Technologies, Inc. System for and method of field mapping
WO2012059816A2 (en) * 2010-11-04 2012-05-10 Conprox Ab Method and apparatus for handling digital objects in a communication network
US9600350B2 (en) * 2011-06-16 2017-03-21 Vmware, Inc. Delivery of a user interface using hypertext transfer protocol
US8510807B1 (en) 2011-08-16 2013-08-13 Edgecast Networks, Inc. Real-time granular statistical reporting for distributed platforms
US9549045B2 (en) 2011-08-29 2017-01-17 Vmware, Inc. Sharing remote sessions of a user interface and/or graphics of a computer
US9514242B2 (en) 2011-08-29 2016-12-06 Vmware, Inc. Presenting dynamically changing images in a limited rendering environment
US8769350B1 (en) 2011-09-20 2014-07-01 Advent Software, Inc. Multi-writer in-memory non-copying database (MIND) system and method
US8635229B2 (en) * 2011-10-18 2014-01-21 International Business Machines Corporation Sequenced query processing in data processing system
US8655873B2 (en) * 2011-10-28 2014-02-18 Geofeedr, Inc. System and method for aggregating and distributing geotagged content
US8332349B1 (en) 2012-01-06 2012-12-11 Advent Software, Inc. Asynchronous acid event-driven data processing using audit trail tools for transaction systems
US10984337B2 (en) * 2012-02-29 2021-04-20 Microsoft Technology Licensing, Llc Context-based search query formation
US10776383B2 (en) * 2012-05-31 2020-09-15 International Business Machines Corporation Automatic replication of ambiguous data based on a point system
US8825635B2 (en) * 2012-08-10 2014-09-02 Microsoft Corporation Automatic verification of data sources
US9122766B2 (en) 2012-09-06 2015-09-01 Microsoft Technology Licensing, Llc Replacement time based caching for providing server-hosted content
US9756109B2 (en) * 2012-11-12 2017-09-05 Webgines Communications Inc Architecture, system and method for dynamically providing digital content via a reference image
US20140149392A1 (en) * 2012-11-28 2014-05-29 Microsoft Corporation Unified search result service and cache update
US8655983B1 (en) 2012-12-07 2014-02-18 Geofeedr, Inc. System and method for location monitoring based on organized geofeeds
US8639767B1 (en) 2012-12-07 2014-01-28 Geofeedr, Inc. System and method for generating and managing geofeed-based alerts
US8850531B1 (en) 2013-03-07 2014-09-30 Geofeedia, Inc. System and method for targeted messaging, workflow management, and digital rights management for geofeeds
US9307353B2 (en) 2013-03-07 2016-04-05 Geofeedia, Inc. System and method for differentially processing a location input for content providers that use different location input formats
US8612533B1 (en) 2013-03-07 2013-12-17 Geofeedr, Inc. System and method for creating and managing geofeeds
US8862589B2 (en) 2013-03-15 2014-10-14 Geofeedia, Inc. System and method for predicting a geographic origin of content and accuracy of geotags related to content obtained from social media and other content providers
US9811797B2 (en) * 2013-03-15 2017-11-07 Sap Se Transportation connection cache for dynamic network and route determination
US8849935B1 (en) 2013-03-15 2014-09-30 Geofeedia, Inc. Systems and method for generating three-dimensional geofeeds, orientation-based geofeeds, and geofeeds based on ambient conditions based on content provided by social media content providers
US9317600B2 (en) 2013-03-15 2016-04-19 Geofeedia, Inc. View of a physical space augmented with social media content originating from a geo-location of the physical space
US9910895B2 (en) * 2013-06-07 2018-03-06 Apple Inc. Push subscriptions
US8788703B1 (en) 2013-08-05 2014-07-22 Iboss, Inc. Content caching
US8972513B2 (en) 2013-08-05 2015-03-03 Iboss, Inc. Content caching
US8886671B1 (en) 2013-08-14 2014-11-11 Advent Software, Inc. Multi-tenant in-memory database (MUTED) system and method
CN104424314B (zh) * 2013-09-06 2019-06-11 Sap欧洲公司 对列状表数据库的数据库操作
US9760897B2 (en) * 2013-09-21 2017-09-12 Oracle International Corporation Method and system for defining an offlinable view/controller graph
KR101595797B1 (ko) * 2014-05-12 2016-02-22 네이버 주식회사 지도 서비스를 제공하기 위한 방법과 시스템, 그리고 기록 매체 및 파일 배포 시스템
US9690760B2 (en) 2014-05-15 2017-06-27 International Business Machines Corporation Bidirectional hyperlink synchronization for managing hypertexts in social media and public data repository
EP3796665A1 (en) * 2014-05-22 2021-03-24 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
RU2608668C2 (ru) * 2014-07-30 2017-01-23 Общество С Ограниченной Ответственностью "Яндекс" Система и способ управления и организации кэша веб-браузера для обеспечения автономного просмотра
CN105786879A (zh) * 2014-12-22 2016-07-20 广州市动景计算机科技有限公司 隔离页面Cookie的方法及装置
US10313468B2 (en) 2015-06-16 2019-06-04 Comcast Cable Communications, Llc Caching of metadata objects
US9485318B1 (en) 2015-07-29 2016-11-01 Geofeedia, Inc. System and method for identifying influential social media and providing location-based alerts
CN106990975B (zh) * 2016-01-21 2021-07-23 斑马智行网络(香港)有限公司 一种应用热部署方法、装置和系统
US9591047B1 (en) * 2016-04-11 2017-03-07 Level 3 Communications, Llc Invalidation in a content delivery network (CDN)
US10489381B2 (en) * 2017-04-13 2019-11-26 Sap Se Adaptive metadata refreshing
US11650961B2 (en) * 2019-02-04 2023-05-16 Red Hat, Inc. Managing replica unavailability in a distributed file system
US11074315B2 (en) * 2019-07-02 2021-07-27 Bby Solutions, Inc. Edge cache static asset optimization
CN112861031B (zh) * 2019-11-27 2024-04-02 北京金山云网络技术有限公司 Cdn中url刷新方法、装置、设备以及cdn节点

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5951643A (en) * 1997-10-06 1999-09-14 Ncr Corporation Mechanism for dependably organizing and managing information for web synchronization and tracking among multiple browsers
US5951652A (en) * 1997-10-06 1999-09-14 Ncr Corporation Dependable data element synchronization mechanism
US6035332A (en) * 1997-10-06 2000-03-07 Ncr Corporation Method for monitoring user interactions with web pages from web server using data and command lists for maintaining information visited and issued by participants
US5954798A (en) * 1997-10-06 1999-09-21 Ncr Corporation Mechanism for dependably managing web synchronization and tracking operations among multiple browsers
US5941957A (en) * 1997-10-06 1999-08-24 Ncr Corporation Dependable web page synchronization mechanism
JP2000020385A (ja) * 1998-07-07 2000-01-21 Hitachi Ltd データ検索システムにおけるデータキャッシュ方法
CA2360891A1 (en) * 1999-01-28 2000-08-03 Webspective Software, Inc Web server content replication
US6490575B1 (en) * 1999-12-06 2002-12-03 International Business Machines Corporation Distributed network search engine
US6591266B1 (en) * 2000-07-14 2003-07-08 Nec Corporation System and method for intelligent caching and refresh of dynamically generated and static web content

Also Published As

Publication number Publication date
US6591266B1 (en) 2003-07-08
JP2002032261A (ja) 2002-01-31

Similar Documents

Publication Publication Date Title
JP3620448B2 (ja) 動的に作られかつ静的であるウェブコンテントの知的キャッシュとリフレッシュのためのシステムと方法
EP1581886B1 (en) A transparent edge-of-network data cache
US7228318B2 (en) System and methods for invalidation to enable caching of dynamically generated content
JP4593793B2 (ja) 問合せ可能なダイナミック・キャッシュを有するウェブサーバ
US6832222B1 (en) Technique for ensuring authorized access to the content of dynamic web pages stored in a system cache
US10296629B2 (en) Server supporting a consistent client-side cache
Pitoura et al. Scalable processing of read-only transactions in broadcast push
US9697253B2 (en) Consistent client-side cache
US6424966B1 (en) Synchronizing crawler with notification source
Deshpande et al. Cache-and-query for wide area sensor databases
US7343412B1 (en) Method for maintaining and managing dynamic web pages stored in a system cache and referenced objects cached in other data stores
WO2001040949A1 (en) Dynamic caches with miss tables
KR20040005816A (ko) 캐싱된 웹 콘텐츠의 풍부한 웹 서버 활동 데이터 수집
CN111581232B (zh) 一种基于elk的慢sql实时分析方法及系统
Liu et al. Information monitoring on the web: a scalable solution
CN113490933A (zh) 分布式数据处理
Pandrangi WebVigiL: Adaptive fetching and user-profile-based change detection of HTML pages
CA2249059C (en) Caching of distributed dynamic sql statements in a multiple node rdbms
Ramanath et al. DIASPORA: A highly distributed web-query processing system
Haritsa The Web is the database
Chakravarthy WEBVIGIL: ADAPTIVE FETCHING AND USER-PROFILE BASED CHANGE DETECTION OF HTML PAGES
Hsiung et al. Issues and Evaluations of Caching Solutions for VVeb Application Acceleration
Myllymaki et al. Database Support for Web Service Caching
Krishnamurthy et al. Change Management in Web Database Systems
Tolle Enabling Wireless Context Sources

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040615

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040816

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20041026

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20041108

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20071126

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081126

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081126

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091126

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091126

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101126

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111126

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111126

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121126

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121126

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131126

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees