(57)【特許請求の範囲】
【請求項１】
パケットデータネットワーク上で相互接続された少なくとも第１および第２のＷｅｂキャッシュを含み、各ＷｅｂキャッシュはどちらかのＷｅｂキャッシュに接続される複数のクライアント端末によって検索可能なＷｅｂオブジェクトを記憶し、前記第１および第２のＷｅｂキャッシュに記憶される前記Ｗｅｂオブジェクトは前記パケットネットワーク上に接続されたＷｅｂサーバから受け取られるＷｅｂオブジェクトのコピーであるシステムにおいて、
前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関する識別情報に対する要求を示す前記第１Ｗｅｂキャッシュからの第１信号を、前記第２Ｗｅｂキャッシュで受信するステップと、
前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関して要求された前記識別情報を提供する第２信号を、前記第２Ｗｅｂキャッシュから前記第１Ｗｅｂキャッシュへ送信するステップと、を含む方法。
【請求項２】
請求項１に記載の方法であって、
前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関する前記識別情報の受信に応答して、前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトのコピーに対する前記第１Ｗｅｂキャッシュからの要求を、前記第２Ｗｅｂキャッシュで受信するステップと、
前記第２Ｗｅｂキャッシュ中のＷｅｂオブジェクトのコピーに対する前記要求に応答して、前記要求されたＷｅｂオブジェクトのコピーを前記第１Ｗｅｂキャッシュに与えるステップと、をさらに含む方法。
【請求項３】
請求項１に記載の方法において、前記第１信号は、前記第１Ｗｅｂキャッシュまたは前記第２Ｗｅｂキャッシュのいずれかに接続されたクライアント端末によるＷｅｂオブジェクトのコピーの要求とは非同期で受信される方法。
【請求項４】
請求項１に記載の方法において、前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関して要求された前記識別情報は、前記第２Ｗｅｂキャッシュに記憶されているＷｅｂオブジェクトの識別に関する情報を含む方法。
【請求項５】
請求項１に記載の方法において、前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関して要求された前記識別情報は、前記第２Ｗｅｂキャッシュ中でＷｅｂオブジェクトが修正された時間に関する情報を含む方法。
【請求項６】
請求項５に記載の方法において、前記第２Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関して要求された前記識別情報は、前記第２Ｗｅｂキャッシュ中のＷｅｂオブジェクトのサイズに関する情報をさらに含む方法。
【請求項７】
請求項１に記載の方法において、前記第２信号は、Ｗｅｂオブジェクトが前記第２Ｗｅｂキャッシュ中で修正されると送信される方法。
【請求項８】
請求項１に記載の方法において、前記第２信号は、定期的に送信される方法。
【請求項９】
請求項１に記載の方法において、前記第１信号は、前記第１Ｗｅｂキャッシュ中で修正されたＷｅｂオブジェクト組に関する情報を含み、前記第２信号は、前記第２Ｗｅｂキャッシュ中で修正されたＷｅｂオブジェクト組に関する情報を含む方法。
【請求項１０】
請求項９に記載の方法において、
前記第１Ｗｅｂキャッシュ中で修正されたＷｅｂオブジェクトに関する前記第１信号に含まれる情報に応答して、前記第１Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関して前記第２Ｗｅｂキャッシュに記憶された状態情報を更新するステップを含み、
前記第２信号に含まれる情報は、前記第１Ｗｅｂキャッシュに記憶されたＷｅｂオブジェクトに関する前記更新された状態情報に従って、前記第１Ｗｅｂキャッシュ中で修正された後に前記第２Ｗｅｂキャッシュ中で修正された前記第２Ｗｅｂキャッシュ中のＷｅｂオブジェクトに関する情報を含む方法。
【発明の詳細な説明】
【０００１】
【関連出願との関係】
本発明は本出願と同日である１９９６年１０月１８日付で出願され現在審査中の米国特許出願第０８／７３３，４８６号（発明者は本願と同じアントニオ  デシモン及びサンディープ  サイバル）に記載された内容と関連する。
【０００２】
【発明の属する技術分野】
本発明は、データ通信およびコンピュータネットワーク技術に関し、より特定的には、インターネット等のパケットデータネットワーク上でキャッシュ間でデジタル情報を転送する技術に関する。
【０００３】
【従来の技術】
インターネットに接続されたサーバからクライアント端子がＷｅｂオブジェクトを検索する、クライアント端末とＷｅｂサーバとの間のワールド・ワイド・ウェブ（ＷＷＷ）上でのトランザクションでは、通常、クライアント端末はインターネット・アクセス・サービス・プロバイダ（ＩＡＳＰ）を介してインターネットにアクセスする。オブジェクトには、１頁以上のテキスト情報、画像、音声クリップ、映像クリップ、ＪＡＶＡアプレットもしくはその他のソフトウェア、またはこれらを任意に組み合わせたものが含まれる。またはインターネットを通じてクライアント端末にデジタル送信可能なものであればどのようなものでもよい。本明細書で用いる「オブジェクト」とは、このような情報すべてをさす。ＩＡＳＰネットワーク内に配置されるキャッシュは、このようなＷｅｂオブジェクトをクライアント端末によってサーバから検索する際のトランザクション媒介として機能する。特に、もっとも単純な形式においては、ＩＡＳＰ内のキャッシュは、サーバからオブジェクトを要求しているクライアント端末へオブジェクトが移動する場合、検索したオブジェクトのコピーをキャッシュ自身のために保存する。このキャッシュ動作はユーザには見えないので、通常の状況下では、オブジェクトがサーバから取り出されてクライアント端末へ届けられるのと同時に実行されるこのコピー動作によって重大な遅れは生じない。
【０００４】
ＩＡＳＰネットワーク内のキャッシュの利点は、キャッシュが記憶するオブジェクト群に対する要求を引き続き満足させることができ、オブジェクトを発生するサーバからインターネット上でオブジェクトを検索する必要をなくすことである。これによりユーザの知覚するオブジェクトへのアクセス遅延を低減し、さらにＩＡＳＰネットワークをインターネットに接続するリンクの帯域幅を節約することができる。図１は先行技術のネットワークのブロック図である。同図では、１０１および１０２等の複数のクライアント端末がＩＡＳＰ１０４内のキャッシュ１０３に接続される。キャッシュ１０３はインターネット１０６に接続されるサーバ１０５に接続される。サーバ１０５からのオブジェクトがクライアント１０１によって最初に検索される際に、そのオブジェクトをキャッシュ１０３に記憶することにより、その後、同じオブジェクトに対するクライアント１０１、またはＩＡＳＰ１０４内のキャッシュ１０３に接続されたクライアント１０２等の他のクライアントからのリクエストに、キャッシュ１０３から直接応えることができる。ＩＡＳＰ１０４はまた、キャッシュ１０７等の第２のまたはそれ以上のキャッシュを含むことが多い。このようなキャッシュは、同じＩＡＳＰに接続される１０８，１０９等の他のクライアントに対処できる。この第２のキャッシュ１０７、またはＩＡＳＰ１０４内の他のキャッシュ（図示せず）に記憶されるオブジェクトは、キャッシュ同士が互いに通信しあう場合は、第１のキャッシュ１０３に接続されたクライアント群に対処できる。
【０００５】
一般に、先行技術では、あるオブジェクトに対する要求を受信した場合、要求発信元のクライアントに接続するキャッシュ以外のキャッシュ上でオブジェクトを見つけるには、ある特定のオブジェクトに対する要求が出された時点で、直接問い合わせによって行われる。つまり、クライアントからの要求をそのクライアントに接続しているキャッシュでは満足できないときはいつでも、複数の要求を該キャッシュの近隣のキャッシュ群に送り、所望のオブジェクトのコピーがそれらのキャッシュのメモリに記憶されていないかどうか問い合わせる。
【０００６】
【発明が解決しようとする課題】
複数のキャッシュに問い合わせを行い、回答を待ち、その後、該当するオブジェクトを保有するキャッシュからオブジェクトのコピーをダウンロードするか、または近隣キャッシュで該当するオブジェクトが見つからない場合は、オブジェクトの元サーバからオブジェクトのコピーを検索するという一連のステップのために、要求発信元のユーザが許容できない遅延が検索過程に生じる場合がある。さらに、あるオブジェクトに対する各要求に応答する際に、近隣のすべてのキャッシュ群にリクエストを洪水のように送信するのは、キャッシュのコンピュータ資源を枯渇させるだけでなく、ネットワークの帯域幅の無駄遣いでもある。またさらに、近隣のキャッシュに存在するオブジェクトのコピーは、オブジェクトが生成されるサーバでのその時点でのオブジェクトとは異なるかもしれない。このことは、サーバ中のオブジェクトに対する最初の要求が出され、該オブジェクトのコピーが近隣のキャッシュに記憶されて以降に、サーバ中のオブジェクトは修正されるときに生じる。従って、要求応答キャッシュから発信キャッシュに対して利用可能なオブジェクトは現在のものではなく、サーバに現存するオブジェクトの無効または更新前のバージョンである可能性があり、該オブジェクトを要求発信元のクライアントに供給するには不適当な場合がある。
【０００７】
【課題を解決するための手段】
本発明では、キャッシュは、その近隣のキャッシュがどのようなオブジェクトを保有するかについての情報、および該オブジェクトについてのその他の情報、例えばオブジェクトが近隣のキャッシュ中で修正された時間、オブジェクトの内容の種類、およびオブジェクトのサイズ等を供給する。後者の情報はディスク容量の割付け計画に有用である。この情報収集プロセスは、近隣のキャッシュからの実際のオブジェクト検索、またはオブジェクトの最新バージョンを保有するサーバからの実際のオブジェクト検索とは異なり、オブジェクトに対する任意のクライアントからのリクエストとは同期せずに行われる。
【０００８】
Ｗｅｂキャッシュ群は、保有するＷｅｂオブジェクトに関して、様々なメカニズムによって互いに更新しあう。第１のメカニズムでは、要求キャッシュは応答キャッシュに対して、応答キャッシュ中である日時以降に更新されたすべてのオブジェクトまたはオブジェクトの一部についての情報を問い合わせる。本明細書で使用する「修正された」という用語は、ある時間以降にキャッシュ中で更新または作成されたオブジェクトを含む。第２のメカニズムでは、応答キャッシュは要求キャッシュに対して、要求キャッシュが以前に興味を示したことのあるオブジェクトの修正についての情報を定期的に知らせる。第３および第４のより知的なメカニズムでは、近隣のキャッシュは該キャッシュに以前に送られたメッセージに基づいて、他のキャッシュが保有するオブジェクトについての状態情報を維持する。特に第３のメカニズムでは、各キャッシュは通信相手すべての近隣キャッシュ中のオブジェクトについての状態情報を維持する。第４のメカニズムは、多数の同胞キャッシュが存在し、各同胞キャッシュが互いのキャッシュの内容に興味がある場合に適用可能である。各キャッシュが他のキャッシュの内容について収集した情報は、その後、そのキャッシュ自身の内容とともに、任意のキャッシュに送られたメッセージのコンパイルに使用される。
【０００９】
【発明の実施の形態】
上述のように、本発明は、どのようなオブジェクトがキャッシュ中にあるのかについてＷｅｂキャッシュ同士が互いに更新しあうメカニズムである。更新通知は、修正されたＷｅｂオブジェクトを実際に送信するのとは異なる。一般に、通知される情報には、受信キャッシュがその情報から近隣のキャッシュ中にどのようなＷｅｂオブジェクトが記憶されるているかを判断できる情報だけでなく、近隣のキャッシュ中のオブジェクトが最後に修正された時間などの情報も含まれる。また任意で、要求キャッシュに有用な情報、例えば要求キャッシュがそのディスク容量の割付けを計画できるようにするために、オブジェクトのバイト単位のサイズやオブジェクトの内容などが含まれる場合もある。
【００１０】
キャッシュに記憶されるオブジェクトに関する情報の転送に関与する２つのキャッシュを識別するために、以後、近隣のキャッシュの内容についての情報を求めるキャッシュを要求キャッシュ（ＲＱＣ）、記憶内容についての情報を送信する近隣キャッシュを応答キャッシュ（ＲＳＣ）と称する。本発明のメカニズムは、あるキャッシュ群はＲＱＣとしてのみ機能し、その他のキャッシュ群はＲＳＣとしてのみ機能する環境で動作できる。具体的に階層トポロジーにおいては、下位のキャッシュは情報の要求だけを行い、上位のキャッシュは応答だけを行う状況を考えることができる。「上位」とは、インターネットへのリンクが最上位レベルにあり、かつＷｅｂクライアントすなわちブラウザが最下位レベルにあるという意味で用いる。もっとも一般的な商業用ブラウザは、同じ場所に配置されたキャッシュをもつ。このようなクライアントキャッシュは、一般的には常にＲＱＣであるが、近隣ブラウザが他のブラウザのプライベートキャッシュを「見る」許可をもつ場合は、ＲＳＣとしても機能する。
【００１１】
図２はＲＱＣ主導型通知のメカニズムを示す。このメカニズムでは、ＲＱＣ２０１は、ＲＳＣ２０３に記憶され、かつ所定の日時以降にＲＳＣ２０３で更新された、またはＲＳＣ２０３にとって新規であるすべてもしくは一部のオブジェクトを知らせるように、ＲＳＣ２０３に要求する。上述したように、オブジェクトに関して用いる「ある日時以降に修正された」という表現は、所定の日時以降にＲＳＣにとって新規であるオブジェクト、およびその日時以降に更新されたオブジェクトをさす。要求中のＵＲＬのアドレスリストは、それぞれＵＲＬのついたオブジェクト群を含む場合もあるし、またはＵＲＬ同士がアドレスを共用する全オブジェクトをワイルドカード記号を用いて表す、一定のＵＲＬ範囲内の複数のオブジェクトを含む場合もある。すでに述べたように、この要求はＲＳＣ２０３に以前に記憶されていた既存オブジェクトの更新に関する情報、およびＲＳＣ２０３に新たに加えられたオブジェクトの両方に関する情報を含みうる。要求２０２は、それ以降に修正が行われたかどうかを示す日付（”ｉｆ  ｍｏｄｉｆｉｅｄ  ｓｉｎｃｅ”ｄａｔｅ、以後「ＩＭＳ日付」と称する）を含み、オブジェクトがＩＭＳ日付以降にキャッシュ中で修正された、または新たに加えられた場合のみ、オブジェクトに関する情報が要求されることをＲＳＣに知らせる。
【００１２】
要求２０２に応答して、ＲＳＣ２０３は、記載されたＵＲＬ群をチェックして、オブジェクトがキャッシュ中でＩＭＳ日付以降に実際に修正されたかどうかを判断する。これに対する応答２０４は、ＩＭＳ日付以降にＲＳＣ中で最後に修正されたＵＲＬ群と、該ＵＲＬ群の修正時間とのリストである。また、この情報は、要求されたＵＲＬオブジェクトのサイズや、オブジェクトに関する他の情報、例えばオブジェクト内容の種類を含みうる。ＲＱＣ２０１はこの応答を解読し、要求したＵＲＬに関して入手した情報を用いて、特にどのＵＲＬをダウンロードしたいかを決定する。実際には、このダウンロード動作は、ＲＱＣ自身の規則に従ってＲＱＣだけで行ってもよいし、またはＲＱＣ２０１に接続しているユーザによって、そのオブジェクトに対する実際の要求に応答した後で行ってもよい。いずれにしてもＲＱＣがＵＲＬ、ｕｒｌの付いたオブジェクトの検索を行うことを決定した場合、ＲＱＣは支配的なワールド・ワイド・ウェブ・インターネット・プロトコルであるハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して、ＵＲＬ、ｕｒｌの付いたオブジェクトを入手（ＧＥＴ）する要求２０５を出す。ＲＳＣ２０３は、そのＧＥＴ要求に応答して、ＲＳＣ２０３が記憶しているＵＲＬ、ｕｒｌ付きオブジェクト本体のコピーを含む応答２０６をＲＱＣ２０１に送り返す。
【００１３】
図３は、ＲＳＣがＲＱＣに対して、ＲＱＣが以前に興味を示したオブジェクトの変更について定期的に頻繁に通知する、ＲＳＣ主導型の方式で用いるメカニズムを示す。第１モードでは、修正されたオブジェクトについての情報が定期的にＲＳＣに送信される。第２モードでは、要求されたオブジェクトが実際にＲＱＣ中で更新または新規作成されると常に、情報が送られる。これら両方のモードは共存可能である。第２モードでは、ＲＱＣ３０１はまず、ある範囲のＵＲＬ群に対するイベントの更新についてのリクエスト３０２をＲＳＣ３０３に登録する。ＲＳＣ３０３はこのリクエストを登録し、確認３０４をＲＱＣ３０１に送り返す。登録完了後、ＲＳＣ３０３は、登録されたＵＲＬのうちのどれか１つが修正されると常に、更新メッセージをＲＱＣ３０１に送信する。これに従って、ＵＲＬ、ｕｒｌ１が修正されると、このオブジェクトについての情報を含むメッセージ３０５がＲＱＣ３０１に送信される。これに応答して、ＲＱＣ３０１は、ＨＴＴＰ／１．０プロトコルを使用してｕｒｌ１を入手（ＧＥＴ）する要求３０６を出すことを決定してもよい。または、あるＵＲＬが修正されたという情報メッセージに応答して、ＲＱＣ３０１はそのＵＲＬをダウンロードしないことを決定してもよい。これに従って、図３に示すように、ＵＲＬ、ｕｒｌ２が修正され、このＵＲＬ、ｕｒｌ２についての更新メッセージ３０７がＲＱＣ３０１に送信される場合、ＲＱＣは修正後のｕｒｌ２のダウンロード要求を出さないことを決定する。そして、ＵＲＬ、ｕｒｌ３が修正され、そのメッセージがＲＱＣ３０１に送信される場合、ＲＱＣは修正後のオブジェクトをダウンロードする要求を出す。
【００１４】
Ｗｅｂオブジェクトそのものの代わりに、単に通知メッセージを送信するという本発明の動機は、２つある。第一に、ＲＱＣのシステムにＷｅｂオブジェクト自体をコピーするスペースが残っていない場合でも、キャッシュ・コヒーレンシー（キャッシュ整合）が可能なことである。これはユーザ要求とは同期せずに行われ、かつ要求に対する結果として行われるのではないので、キャッシュは他のキャッシュが何を保有しているかを前もって知ることができ、このためユーザが知覚するような遅延を（近隣キャッシュへの無意味な問い合わせを制限することによって）抑制し、またネットワークやキャッシュ資源の節約もできる。第二に、本発明は、オブジェクトの修正時間に関する情報と、オブジェクト自体の内容に関する情報とを、論理上、分離できる。このためキャッシュは、オブジェクトをダウンロードする前に、どのオブジェクトをリフレッシュまたは格納したいのかを選択できる。キャッシュが保有する情報は、オブジェクトの他の側面、例えばバイト単位のサイズ等を含みうるので、キャッシュはオブジェクトをダウンロードする前に十分に準備できる。例えば、オブジェクトのサイズが非常に大きい場合、キャッシュは記憶容量が足りないためそのオブジェクトのダウンロードは行わないことを選択してもよい。
【００１５】
近隣キャッシュに記憶されているＷｅｂオブジェクトについての情報を交換した後、新規または修正されたＷｅｂオブジェクトを、複数部分からなるメッセージ、ＫｅｅｐＡｌｉｖｅ接続、圧縮、その他の方法を用いて、個々にまたはバッチ単位で検索できる。
【００１６】
上述したように、所定の日時以降にキャッシュで更新された文書は、オブジェクトが発生したサーバではなく該キャッシュでのアクティビティに関するものである。従って、時間ｔ１以降にキャッシュで修正された文書は、時間ｔ２＜ｔ１でサーバにおいて修正されているかもしれない。
【００１７】
図３のＲＳＣ主導型メカニズムでは、ＲＳＣはＲＱＣに対して、ＲＳＣがそのキャッシュに保有する、先行時刻にＲＳＣがＲＱＣに送った最後のメッセージ以降にＲＳＣのキャッシュで修正または新規作成された全オブジェクトに関する情報を定期的に頻繁に送信する。このメカニズムを拡張して、ＲＱＣのキャッシュに記憶された、先行時刻にＲＱＣがＲＳＣと最後に交信して以降に修正された全オブジェクトのリストを含む別のメッセージを送り返すことによって、ＲＱＣがＲＳＣに対して自動的に応答するようにもできる。このように組み合わせたメカニズムは図３のメカニズムと似ているが、ただし近隣キャッシュが要求キャッシュにも応答キャッシュにもなれる点が異なる。このようなメカニズムでは、各応答中における要求は不明瞭になる。このように「要求」と「応答」との差がはっきりしなくなるため、以後、代わりに「メッセージ」という用語を使用する。
【００１８】
次に、これまで説明したものより知的なメカニズムも可能である。この場合、キャッシュは受け取ったメッセージに一部基づいて、他のキャッシュが何を保有するかについての状態情報を維持する。この状態情報が利用可能になると、送受信されるメッセージがより合理化される。具体的には、オブジェクトのより最近のまたは同時期のバージョンを保有することが以前のメッセージからわかっている近隣キャッシュに対して、あるキャッシュにおいて更新したオブジェクトについてのメッセージを送信するのは無意味である。図４に示すこの第３のメカニズムは、キャッシュがＲＱＣ、ＲＳＣどちらとしても機能できるキャッシュ間でのみ実行可能である。このメカニズムは、ＩＡＳＰ内の同胞キャッシュが全キャッシュにおけるすべての修正オブジェクトについて知りたい場合に適用するように特に設計されたものである。このメカニズムでは、各キャッシュは近隣キャッシュが何を保有するかについての状態情報を維持しなければならないが、特に各キャッシュ中のオブジェクト数が多い場合はオーバヘッド通信を大幅に削減できる。
【００１９】
図４のメカニズムでは、キャッシュ４０１は近隣キャッシュ４０２に、ＵＲＬに関する情報を含むメッセージ４０３を送信する。このメッセージを受け取ると、キャッシュ４０２は近隣のキャッシュ４０１について蓄積した状態情報を更新する。キャッシュ４０２はその後、キャッシュ４０１について保有している状態情報に基づき、キャッシュ４０１が保有するものより新しい、修正されたＵＲＬの組に関する情報を含むメッセージ４０４を送信する。キャッシュ４０１がメッセージ４０４を受け取ると、キャッシュ４０１がキャッシュ４０２について持っている状態情報が更新され、この状態情報に基づき、キャッシュ４０２が保有するものより新しいＵＲＬに関する情報がメッセージ４０５でキャッシュ４０２に送られる。このアルゴリズムはキャッシュ４０１−４０２間で互いにメッセージを受け取るごとに繰り返される。
【００２０】
このメカニズムでは、各キャッシュは通信を行う相手である各近隣キャッシュについての状態情報を（テーブルとして）維持する。各テーブルは、本質的には、キャッシュでの修正時間つきのＵＲＬのリストである。従って、リスト中の各項目は、２項からなる（ｕｒｌi，ｔi）の形式となる。ここでｔiはＵＲＬ、ｕｒｌiで特定されるオブジェクトの修正時間を表す。ただし、キャッシュが保有するものより新しい、ｔi以降の修正時間をもつ文書が元のサーバ／サイトに存在するかもしれない。従ってこのテーブルは、近隣キャッシュが発行したメッセージから構築した知識に基づいて、近隣キャッシュが保有する一番最近の文書を掲載しただけのものである。
【００２１】
このテーブルの更新方法は次の通りである。近隣キャッシュからの各メッセージは、関連の修正時間つきのＵＲＬリストを含む。各項目（ｕｒｌ，ｔ）ごとに次の動作を行う。まず（ｕｒｌi，ｔi）を表へのエントリとする。ｕｒｌ＝ｕｒｌiならば、テーブル中で（ｕｒｌi，ｔi）を（ｕｒｌ，ｔ）と置き換える。もし近隣キャッシュが保有するＵＲＬがそのキャッシュから削除されていても、ｔを負の値に設定した状態（ＵＲＬが削除されていることを示す）で、そのＵＲＬも送信する。キャッシュ中に記憶される新たな（つまり近隣キャッシュへの最後の応答以降の）ＵＲＬのリストが、２項からなる（ｕｒｌx，ｔx）の形式の組から構成されるとする。各ＵＲＬは、ｕｒｌx＝ｕｒｌiかつｔx＜＝ｔiでないかぎり、応答メッセージ中に送られる。つまり、キャッシュｉについて（ｕｒｌi，ｔi）で示すテーブルが、キャッシュｉが同時期またはより最近のバージョンの文書を保有すると示さない場合は、（ｕｒｌx，ｔx）を送信する。
【００２２】
図４で説明したメカニズムは、多数の同胞キャッシュが存在し、各キャッシュが互いの内容に興味をもつＩＡＳＰの場合には、より合理化できる。図５に示すこのようなメカニズムでは、キャッシュ自身の内容に加えて、キャッシュが他のキャッシュの内容に関して収集した情報も任意のキャッシュへのメッセージをコンパイルする際に利用される。このメカニズムでは、各キャッシュは他のキャッシュとの間で直接メッセージのやりとりはしないため、オーバヘッドをさらに低減できる。また、各同胞キャッシュごとの状態を別個に維持するのではなく、キャッシュ動作システム全体について１つの状態を維持するだけでよい。全キャッシュの状態情報の和は、全キャッシュ動作システムの状態よりかなり大きい。理論上は、直接または間接にキャッシュの組が接続されている限り、このメカニズムはすべてのキャッシュに情報を正確に分散できる。グラフ理論上は、キャッシュ間の通信チャネルがキャッシュ群を「ツリー状」に結合している限り、このメカニズムは機能できる。キャッシュおよび通信チャネルの故障を防止し、エンドツーエンド通信遅延を低減するには、「２接続」または「３接続」ツリーがより適切である。「ｋ−接続」ツリ−とは、もしそのリンクのうち任意の（ｋ−１）のリンクが破壊された場合でも、ノードの組は接続されたままであることを示す。
【００２３】
このメカニズムは、他のキャッシュについての情報をそのメッセージ中に分散するため、キャッシュ間で送信されるメッセージは、上述のメカニズムで使用される２項形式から３項目、つまり（ｕｒｌi，ｔi，ｃi）の形式に拡張する必要がある。ここでｃiはｕｒｌiで示されるオブジェクトを実際に記憶しているキャッシュを表し、ｔiは上記と同じくオブジェクトｕｒｌiの修正時間を表す。複数のキャッシュが同時期のオブジェクトを保有する場合、３項中の最後の項はそれだけで一組のキャッシュ群を表す。図５では、キャッシュ５０１または５０２からの（ｕｒｌ，ｔ，ｃ）の形式の項目リストからなるメッセージ（５０３または５０４）が他方のキャッシュに届く度に、ｕｒｌ＝ｕｒｌiかつｔ＞ｔiならば、状態テーブル中で（ｕｒｌi，ｔi，ｃi）を（ｕｒｌ，ｔ，ｃ）と置き換える。ただし、ｕｒｌ＝ｕｒｌiかつｔ＝ｔiならば、もしｃが組ｃi中にまだ存在していなければ、ｃを組ｃiに追加する。あるキャッシュが知っている新しい（つまり近隣キャッシュへの最後の応答以後の）ＵＲＬ群のリストが、３項からなる（ｕｒｌx，ｔx，ｃx）の形式の組からできているとする。各ＵＲＬは、ｃx∈ｃiでなければ、応答メッセージ中に送られる。こうして図５に示すように、近隣キャッシュから修正されたＵＲＬの組を受け取ったことに応答して、その近隣キャッシュに送られるメッセージは、応答の宛先である近隣キャッシュがＵＲＬの最新バージョンを保有していなければ、キャッシュ動作システム上で新規なＵＲＬのリストとなる。
【００２４】
これまで説明してきたメカニズム群は様々な方法で実現可能である。ＲＱＣ主導型メカニズムの実現に利用可能な方法を以下に説明する。このメカニズムは、ＣＯＮＴＥＮＴＳと呼ばれる新しい方法をハイパーテキスト転送プロトコル（ＨＴＴＰ）に対して定義することによって実現される。また、ＨＴＴＰの外部で別個のプロトコル・スイートを使用する他の設計も可能である。
【００２５】
図６はＲＱＣ６０１とＲＳＣ６０２との間のＲＱＣ主導型通知モード用のプロトコルメカニズムを示す。ある特定のＵＲＬ群についての情報を要求するＲＳＣへの要求では、要求行のＨＴＴＰ／１．０およびＨＴＴＰ／１．１構文は次のようになる。
【００２６】
要求行＝方法  ＳＰ（スペース）  要求ＵＲＬ  ＳＰ  ＨＴＴＰバージョン  ＣＲＬＦ（復帰改行）
また、要求ＵＲＬについての構文は、次のようになる。
【００２７】
要求ＵＲＬ＝"*"｜ＵＲＬ絶対値｜ａｂｓパス
この構文ではＵＲＬの完全な組を表すことはできない。従って、要求ＵＲＬとして"*"が選択され、これはこの要求が稼働中のキャッシュまたはＲＳＣの全内容に関係することを偶然にデフォルトで示す。従って、要求行は次のようになる。
【００２８】
要求行＝”ＣＯＮＴＥＮＴＳ”ＳＰ"*"ＳＰ  ＨＴＴＰバージョン  ＣＲＬＦ
要求のヘッダ中のＩＭＳフィールドは、ＩＭＳフィールドによって特定される日時以降に発生した内容変更だけに興味があることを示すために使用される。このフィールドは、ＧＥＴ方法で通常使用されるのとは異なる方法で使用される。ＧＥＴ方法では、ＩＭＳフィールドは、実際の修正時間がＩＭＳフィールドより最近である場合だけに、文書に興味があることを特定する。これに対してここでは、ＩＭＳフィールドは文書がＩＭＳ時間以降にキャッシュで修正されている場合のみに、該文書に対する興味があることを示すのに使用される。Ｒａｎｇｅフィールドは、興味のあるＵＲＬの特定に使用される。このフィールドは、その構文がＨＴＴＰ／１．１中ではまだ特定されていないが、このフィールドによってすべての通常の表現が表せれば望ましい。このフィールドで不十分な場合は、新たなフィールドの作成が必要となる。ＲＱＣがいくつかの選択したＨＴＭＬページだけ、例えばニューヨークタイムズのスポーツ欄を除く全ＨＴＭＬページ、およびルーブルのＪＰＥＧ画像に興味がある場合、Ｒａｎｇｅフィールドを用いてその組み合わせを特定できることが望まれる。最後に、興味を示すＵＲＬに対してキャッシュが適用しようとする他の制約を特定するために、Ｕｎｌｅｓｓフィールドが使用される。また、ａｐｐｌｉｃａｔｉｏｎ／ｗｗｗ−ｃｏｎｔｅｎｔｓとして記載される新しいアプリケーションタイプも、応答キャッシュが送り返す応答の支援に使用される。
【００２９】
図６のリクエスト６０３では、要求行は次のように表すことができる。
【００３０】
ＣＯＮＴＥＮＳ*ＨＴＴＰ／１．０
ここでＣＯＮＴＥＮＴＳはＵＲＬのリストを要求する方法、"*"はこの方法がプロトコルによって制御されることを表し、ＨＴＴＰ／１．０はそのプロトコルを表す。この行の次にＣＲＬＦが続く。その次の行は以下のようになる。
【００３１】
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｗｗｗ−ｃｏｎｔｅｎｔｓ
この行は、定義されたアプリケーションに従ってＲＳＣがＲＱＣに応答を送れば、ＲＱＣはその応答を理解できることを意味する。その次の行は以下のようになる。
【００３２】
Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ：Ｓａｔ，２９  Ｏｃｔ  １９９６
１９：４３：３１ＧＭＴ
これは、１９９６年１０月２９日土曜日の１９時４３分３１秒ＧＭＴ以降に変更されたＵＲＬだけに興味があることを表す。そして最終行は次のようになる。
【００３３】
Ｒａｎｇｅ：ｈｔｔｐ：／／ｗｗｗ．ｎｙｔｉｍｅｓ．ｃｏｍ／*
これは、興味のあるＵＲＬの範囲を表し、"*"は”ｗｗｗ．ｎｙｔｉｍｅｓ．ｃｏｍ”のすべてのオブジェクトに興味があることを指す。
【００３４】
ＲＱＣへの応答はある特定のフォーマットに従わなければならない。フォーマットの定義はプロトコル内で行うのではなく、ＲＳＣによって特定する。ただしフォーマット定義自体は特定の構文を持つ必要がある。内容ファイルのフォーマットは、シーケンスＬＦ（改行）またはＣＲＬＦのいずれかで終了するＡＳＣＩＩ文字を含む行シーケンスを含む。内容ファイル生成器は、それを実行するプラットフォームについての行終了規約に従わなければならない。各行は、指令またはエントリ（の一部）のどちらかを含みうる。エントリは１つのＨＴＴＰオブジェクトに関する一連のフィールドからなる。あるフィールドがある特定のエントリ中で使用されない場合、”−”によって除外されたフィールドを示す。指令はバージョンに関する情報、およびそれに続くオブジェクトのヘッダフィールドに関する情報を与える。＃記号で始まる行は指令を含む。以下の指令は次のように定義される。
【００３５】
−Version:＜integer＞.＜integer＞
使用される拡張ログフォーマットのバージョン。
【００３６】
−Syntax:[＜specifier＞...]
ログに記録されたフィールドを特定する。列ＳＰおよびＣＲＬＦは
特別の意味を持つ。
【００３７】
−Remark:＜text＞
情報をコメントする。このフィールド中に記録されるデータは
分析ツールによって無視すること。
【００３８】
指令ＶｅｒｓｉｏｎおよびＳｙｎｔａｘは必須である。Ｓｙｎｔａｘ指令は複数回現れる場合があるが、このときすべてのエントリは、そのエントリの上方にありかつもっとも近いＳｙｎｔａｘ指令に従うことになっている。Ｓｙｎｔａｘ指令は各エントリのフィールドに記録されたデータを指定する。
【００３９】
応答メッセージ６０４では、”２０１  Ｏ．Ｋ．”という行は、要求が理解され、有効な応答が返されることを示す。次行のＣｏｎｔｅｎｔ−Ｔｙｐｅは、ある一定の構文をもつ、単なるテキストではない性質の特別な文書が続くことを意味する。指令＃Ｖｅｒｓｉｏｎは、構文のタイプ、つまりバージョン１．０を定義する。指令＃Ｓｙｎｔａｘ：Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ  ＣＲＬＦ  ＵＲＬＳＰ  Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈは、この指令に続くのは、最後に修正された日付のフォーマットをもち、次行で、ＲＳＣ６０２で修正されたＵＲＬのあとに、スペース、その後にバイト単位のオブジェクトのサイズが続く。こうして、応答６０４は２つのオブジェクトが要求６０３に合致することを示す。第一のオブジェクトのＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｎｙｔｉｍｅｓ．ｃｏｍ．／ｉｎｄｅｘ．ｈｔｍｌであり、１９９６年１０月２９日土曜日の１０時５４分２秒ＧＭＴにＲＳＣ６０２で最後に修正され、長さ５７５バイトである。第二のオブジェクトのＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｎｙｔｉｍｅｓ．ｃｏｍ／ｉｎｆｏ／ｔｅｘｔｐａｔｈ．ｈｔｍｌであり、１９９６年１０月２９日土曜日の１９時５６分３４秒ＧＭＴにＲＳＣ６０２で最後に修正され、長さ４０９６バイトである。
【００４０】
ＲＱＣ６０１は応答６０４を受け取り、ＲＳＣ６０２からどのオブジェクトを入手（ＧＥＴ）するかを選択する。こうして、図６に示すように、ＲＱＣ６０１はＲＳＣ６０２からｈｔｔｐ：／／ｗｗｗ．ｎｙｔｉｍｅｓ．ｃｏｍ／ｉｎｆｏ／ｔｅｘｔｐａｔｈ．ｈｔｍｌ  ＨＴＴＰ／１．０を入手するために、要求６０５を発行する。この後、ＲＳＣ６０２は、そのオブジェクト本体をＲＱＣ６０１に送ってその要求を満たす。
【００４１】
以上、ＩＡＳＰ内部の近隣キャッシュについて説明してきたが、本発明は、Ｗｅｂブラウザ上のキャッシュに記憶されるオブジェクトについての情報交換、またはＷｅｂブラウザ上とＩＡＳＰ内のキャッシュとの間、または任意の位置内もしく任意の位置間で互いに通信可能なキャッシュ間での情報交換に使用することができる。
【００４２】
上記の実施形態は本発明の原理を例示したものである。従って、当業者によって本発明の精神および範囲内で他の実施形態を考案することができると考える。
【図面の簡単な説明】
【図１】  クライアント端末とインターネット内のサーバとを相互接続する、インターネット・アクセス・サービス・プロバイダ内で接続された２つのキャッシュを示す先行技術のネットワークのブロック図である。
【図２】  本発明の要求キャッシュ主導型通知メカニズムに従う、要求キャッシュと応答キャッシュとの時間軸に沿ったやりとりを示す図である。
【図３】  本発明の応答キャッシュ主導型通知メカニズムに従う、要求キャッシュと応答キャッシュとの時間軸に沿ったやりとりを示す図である。
【図４】  通信相手の他の近隣の各キャッシュに対してそれぞれ別途に状態情報を維持する、２つのキャッシュ間のやりとりを示す図である。
【図５】  各キャッシュがキャッシュ動作システム全体に対して１つの状態情報を維持する、２つのキャッシュ間のやりとりを示す図である。
【図６】  本発明に従う要求キャッシュ主導型メカニズムの一実施形態についての、要求キャッシュと応答キャッシュとの間のメッセージのやりとりを示す図である。
【符号の説明】
２０１  要求キャッシュ、２０２，２０５  要求、２０３  応答キャッシュ、２０４，２０６  応答。
【図１】
0003968119.tif 000002
【図２】
0003968119.tif 000003
【図３】
0003968119.tif 000004
【図４】
0003968119.tif 000005
【図５】
0003968119.tif 000006
【図６】
0003968119.tif 000007