(57)【特許請求の範囲】
【請求項１】
データネットワーク上のデータページの転送および表示方法であって、上記データネットワークはデータがページとして取り出され得るタイプのものであり、上記データネットワークは、上記データページが記憶される少なくとも１つのサーバと、上記少なくとも１つのサーバに接続されたゲートウェイと、有限速度のデータ接続により上記ゲートウェイに接続されたユーザステーションとを有しており、上記ユーザステーションは上記少なくとも１つのサーバから上記ページの１つを要求するような方法において、上記方法は、
上記少なくとも１つのサーバの１つから上記データページを取り出すために、上記ユーザステーションから上記ゲートウェイに要求を送るステップと、
上記データページの基礎バージョンを呼び出すステップと、
上記基礎バージョンが最新のものでないという判断に応答して、上記ユーザステーションへ転送するために上記少なくとも１つのサーバの１つから上記ゲートウェイへの上記データページの取り出しを開始するステップと、
上記要求に対する応答を上記ゲートウェイで受信した後、上記要求されたデータページとそのページの上記基礎バージョンとの差異を求めるステップと、
上記ユーザステーションに上記差異を送信するステップと、
上記基礎バージョンと上記差異との関数として上記データページを上記ユーザステーションにおいて計算するステップと、
上記計算されたページを上記ユーザステーションに表示するステップと、
上記差異を求めるステップおよび上記差異を送信するステップの効率測度を決定するステップと、
上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するのが効率的であると上記効率測度が示すときには、
上記呼び出すステップ、上記送信するステップ、および上記表示するステップを中止するステップと、
上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するステップと、
上記要求されたデータページを上記ユーザステーションに表示するステップと、
を備えていることを特徴とするデータネットワーク上のデータページの転送および表示方法。
【請求項２】
上記効率測度を決定するステップが、
上記差異が求められた後に、上記差異のサイズと上記基礎バージョンの未だ転送されていないすべての残存量の送信サイズとの関数として表される合成送信サイズを評価するステップと、
上記合成送信サイズと上記要求されたデータページの送信サイズとを比較するステップと、
上記要求されたデータページの送信サイズが上記合成送信サイズを超えている場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには非効率的であると判定し、上記要求されたデータページの送信サイズが上記合成送信サイズを超えていない場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには効率的であると判定するステップとを備えていることを特徴とする請求項１に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項３】
上記合成送信サイズおよび上記要求されたデータページの送信サイズのそれぞれが、送信の前に行われる圧縮に基づいて判断されることを特徴とする請求項２に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項４】
上記効率測度を決定するステップが、
上記要求されたデータページが上記ゲートウェイに受信された時点での、上記基礎バージョンが上記ユーザステーションへ転送された割合を判定するステップと、
上記基礎バージョンが転送された割合がしきい値率を超えている場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには非効率的であると判定し、上記要求されたデータページの送信サイズが上記合成送信サイズを超えていない場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには効率的であると判定するステップとを備えていることを特徴とする請求項１に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項５】
上記しきい値率が動的に決定されることを特徴とする請求項４に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項６】
上記しきい値率が上記有限速度に基づいて決定されることを特徴とする請求項５に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項７】
上記効率測度を決定するステップが、
上記要求されたデータページが上記ゲートウェイに受信された時点での、上記基礎バージョンが上記ユーザステーションへ転送された割合を判定するステップと、
上記基礎バージョンが転送された割合がしきい値率を超えている場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには非効率的であると判定するステップと、
上記要求されたデータページの送信サイズが上記合成送信サイズを超えていない場合には、
上記差異が求められた後に、上記差異のサイズと上記基礎バージョンの未だ転送されていないすべての残存量の送信サイズとの関数として表される合成送信サイズを評価するステップと、
上記合成送信サイズと上記要求されたデータページの送信サイズとを比較するステップと、
上記要求されたデータページの送信サイズが上記合成送信サイズを超えている場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには非効率的であると判定し、上記要求されたデータページの送信サイズが上記合成送信サイズを超えていない場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには効率的であると判定するステップとを備えていることを特徴とする請求項１に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項８】
上記合成送信サイズおよび上記要求されたデータページの送信サイズのそれぞれが、送信の前に行われる圧縮に基づいて判断されることを特徴とする請求項７に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項９】
上記しきい値率が動的に決定されることを特徴とする請求項７に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１０】
上記しきい値率が上記有限速度に基づいて決定されることを特徴とする請求項９に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１１】
データネットワーク上のデータページの転送および表示方法であって、上記データネットワークはデータがページとして取り出され得るタイプのものであり、上記データネットワークは、上記データページが記憶される少なくとも１つのサーバと、上記少なくとも１つのサーバに接続されたゲートウェイと、有限速度のデータ接続により上記ゲートウェイに接続されたユーザステーションとを有しており、上記ユーザステーションは上記少なくとも１つのサーバから上記ページの１つを要求するような方法において、上記方法は、
上記少なくとも１つのサーバの１つから上記データページを取り出すために、上記ユーザステーションから上記ゲートウェイに要求を送るステップと、
上記データページの基礎バージョンを呼び出すステップと、
上記基礎バージョンが最新のものでないという判断に応答して、上記ユーザステーションへ転送するために上記少なくとも１つのサーバの１つから上記ゲートウェイへの上記データページの取り出しを開始するステップと、
上記要求に対する応答を上記ゲートウェイで受信した後、上記要求されたデータページとそのページの上記基礎バージョンとの差異を求めるステップと、
上記ユーザステーションに上記差異を送信するステップと、
上記基礎バージョンと上記差異との関数として上記データページを上記ユーザステーションにおいて計算するステップと、
上記計算されたページを上記ユーザステーションに表示するステップと、
上記差異のサイズをしきい値と比較するステップと、
上記差異が上記しきい値を超えている場合に、
上記呼び出すステップ、上記送信するステップ、および上記表示するステップを中止するステップと、
上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するステップと、
上記要求されたデータページを上記ユーザステーションに表示するステップと、
を備えていることを特徴とするデータネットワーク上のデータページの転送および表示方法。
【請求項１２】
上記しきい値が動的に決定されることを特徴とする請求項１１に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１３】
上記しきい値が上記有限速度に基づいて決定されることを特徴とする請求項１２に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１４】
データネットワーク上のデータページの転送および表示方法であって、上記データネットワークはデータがページとして取り出され得るタイプのものであり、上記データネットワークは、上記データページが記憶される少なくとも１つのサーバと、上記少なくとも１つのサーバに接続されたゲートウェイと、有限速度のデータ接続により上記ゲートウェイに接続されたユーザステーションとを有しており、上記ユーザステーションは上記少なくとも１つのサーバから上記ページの１つを要求するような方法において、上記方法は、
上記少なくとも１つのサーバの１つから上記データページを取り出すために、上記ユーザステーションから上記ゲートウェイに要求を送るステップと、
上記データページの基礎バージョンを呼び出すステップと、
上記基礎バージョンが最新のものでないという判断に応答して、上記ユーザステーションへ転送するために上記少なくとも１つのサーバの１つから上記ゲートウェイへの上記データページの取り出しを開始するステップと、
上記要求に対する応答を上記ゲートウェイで受信した後、上記要求されたデータページとそのページの上記基礎バージョンとの差異を求めるステップと、
上記ユーザステーションに上記差異を送信するステップと、
上記基礎バージョンと上記差異との関数として上記データページを上記ユーザステーションにおいて計算するステップと、
上記計算されたページを上記ユーザステーションに表示するステップと、
を備え、
上記差異を求めるステップが、
上記少なくとも１つのサーバの１つからの上記データページの上記取り出しの完了を待つステップと、
上記取り出しを完了したデータページと上記ページの基礎バージョンとを比較するステップと、
を備えていることを特徴とするデータネットワーク上のデータページの転送および表示方法。
【請求項１５】
データネットワーク上のデータページの転送および表示方法であって、上記データネットワークはデータがページとして取り出され得るタイプのものであり、上記データネットワークは、上記データページが記憶される少なくとも１つのサーバと、上記少なくとも１つのサーバに接続されたゲートウェイと、有限速度のデータ接続により上記ゲートウェイに接続されたユーザステーションとを有しており、上記ユーザステーションは上記少なくとも１つのサーバから上記ページの１つを要求するような方法において、上記方法は、
上記少なくとも１つのサーバの１つから上記データページを取り出すために、上記ユーザステーションから上記ゲートウェイに要求を送るステップと、
上記データページの基礎バージョンを呼び出すステップと、
上記基礎バージョンが最新のものでないという判断に応答して、上記ユーザステーションへ転送するために上記少なくとも１つのサーバの１つから上記ゲートウェイへの上記データページの取り出しを開始するステップと、
上記要求に対する応答を上記ゲートウェイで受信した後、上記要求されたデータページとそのページの上記基礎バージョンとの差異を求めるステップと、
上記ユーザステーションに上記差異を送信するステップと、
上記基礎バージョンと上記差異との関数として上記データページを上記ユーザステーションにおいて計算するステップと、
上記計算されたページを上記ユーザステーションに表示するステップと、
を備え、
上記差異を求めるステップが、
上記少なくとも１つのサーバの１つからの上記データページの所定部分の取り出しの完了を待つステップと、
上記データページと上記基礎バージョンとの部分的差異を生成するために、上記データページの上記取り出された所定部分と上記データページの基礎バージョンとを比較するステップと、
上記データページの追加分の所定部分について、上記待つステップと上記比較するステップとを繰り返すステップとを備えていることを特徴とするデータネットワーク上のデータページの転送および表示方法。
【請求項１６】
上記部分的差異を生成する際に、
上記部分的差異のサイズと下限しきい値とを比較するステップと、
上記部分的差異の送信サイズが下限しきい値を超えている場合には、上記部分的差異を上記ユーザステーションに送信するステップと、
上記部分的差異の送信サイズが下限しきい値より小さい場合には、
上記部分的差異を保持するステップと、
上記データページとその上記基礎バージョンとの少なくとも１つの追加分の部分的差異を生成するために、上記データページの少なくとも１つの追加分の取り出された所定部分と上記データページの上記基礎バージョンとを比較するステップと、
上記少なくとも１つの追加分の部分的差異の送信サイズと上記保持された部分的差異の送信サイズとを、これらの合計が上記下限しきい値を超えるまで加算するステップと、
上記保持された部分的差異および上記少なくとも１つの追加分の部分的差異を上記ユーザステーションに送信するステップとを備えていることを特徴とする請求項１５に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１７】
上記部分的差異の送信サイズおよび上記少なくとも１つの追加分の部分的差異の送信サイズのそれぞれが、送信の前に行われる圧縮に基づいて判断されることを特徴とする請求項１６に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１８】
上記部分的差異のそれぞれの送信サイズを求めるステップと、
上記部分的差異のそれぞれを上記ユーザステーションに送信する際に、上記部分的差異の送信サイズと上記ユーザステーションに送信された上記部分的差異の累積送信サイズとを加算するステップと、
上記累積送信サイズと上限しきい値とを比較するステップと、
上記累積送信サイズが上記上限しきい値を超えている場合には、上記送信サイズを求めるステップを中止して上記データページを上記ユーザステーションに送信するステップとをさらに備えていることを特徴とする請求項１５に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項１９】
上記部分的差異の送信サイズおよび上記少なくとも１つの追加分の部分的差異の送信サイズのそれぞれが、送信の前に行われる圧縮に基づいて判断されることを特徴とする請求項１８に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項２０】
上記差異を求めるステップおよび上記差異を送信するステップの効率測度を決定するステップと、
上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するのが効率的であると上記効率測度が示すときには、
上記呼び出すステップ、上記送信するステップ、および上記表示するステップを中止するステップと、
上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するステップと、
上記要求されたデータページを上記ユーザステーションに表示するステップとをさらに備えていることを特徴とする請求項１５に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項２１】
上記効率測度を決定するステップが、
上記部分的差異のサイズが求められた後に、上記部分的差異のサイズと上記基礎バージョンの未だ転送されていないすべての残存量の送信サイズとの関数として表される合成送信サイズを評価するステップと、
上記合成送信サイズと上記要求されたデータページの送信サイズとを比較するステップと、
上記要求されたデータページの送信サイズが上記合成送信サイズを超えている場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには非効率的であると判定し、上記要求されたデータページの送信サイズが上記合成送信サイズを超えていない場合には、上記要求されたデータページの全体を上記ゲートウェイから上記ユーザステーションへ送信するには効率的であると判定するステップとを備えていることを特徴とする請求項２０に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項２２】
上記評価するステップが、上記部分的差異のサイズから、上記データページとその基礎バージョンとの差異を表すデータの全サイズを見積もるステップを備えていることを特徴とする請求項２１に記載のデータネットワーク上のデータページの転送および表示方法。
【請求項２３】
上記合成送信サイズおよび上記要求されたデータページの送信サイズのそれぞれが、送信の前に行われる圧縮に基づいて判断されることを特徴とする請求項２１に記載のデータネットワーク上のデータページの転送および表示方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、低速でネットワークに接続されたステーションにデータページを転送および表示するための方法に関する。より詳細には、本発明は、データページが要求された時刻からそのページが表示された時刻までの遅延時間を減少させるための方法に関する。
【０００２】
【従来の技術】
インターネットのようなデータネットワークにおいては、互いに高速接続されたサーバにデータが記憶されている。このようなネットワークは、インターネットで一般的なワールド・ワイド・ウェブ（World Wide Web）に用いられているハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）のようなプロトコルをサポートしており、かかるプロトコルにおいてはデータが「ページ（page）」として知られているフォーマットでユーザに送られる。ＨＴＴＰプロトコルでは、ユーザ・インターフェイス・ソフトウェア（「ブラウザ」として知られている）は、ページ中の重要部分を受け取るまではそのページを表示し始めることができず、言うまでもなくページの総てを受け取るまでそのページ全体を表示することができない。このような遅延は待ち時間（latency）と言われている。
【０００３】
【発明が解決しようとする課題】
残念ながら、多くのインターネットユーザは、モデムと通常の電話線とを用いて比較的低速でインターネットに接続している。最も速い市販の電話モデムであってもその速度は２８．８キロビット／秒（kbps）、あるいは場合により３３．６kbpsに制限されている。これにより、ワールド・ワイド・ウェブのページがユーザに送られてユーザのブラウザに表示され得る速度が制限される。さらに、大量のユーザ・トラフィック、特に同じサーバへの他のユーザによる大量のアクセスもまたワールド・ワイド・ウェブの見掛け上の速度を低下させる。その結果、多くのユーザはインターネット一般、特にワールド・ワイド・ウェブの低速さに不満を訴えている。実際のところ、ユーザが感じとる待時間の大部分は、本質的に非常に高速のネットワークであるべきものに相対的に低速で接続されること、およびそこへの大量のトラフィックの結果である。
【０００４】
現存するブラウザ・ソフトウェアは、ワールド・ワイド・ウェブのページを受信する際の遅延時間をなくすために種々の試みをしている。例えば、たいていのブラウザは受信したページをディスク・キャッシュ内に記憶するようにしている。もしユーザがあるページを要求してから短期間のうちにそのページを要求した場合、ブラウザはそのページをキャッシュから取り出す。しかしながら、ＨＴＴＰプロトコルの下では、例えば動的に生成されるページなどのある種のワールド・ワイド・ウェブのページはキャッシュされない場合がある。従って、現在のキャッシュ技術は待ち時間の問題を解決するには不十分である。
【０００５】
つまり、比較的高速のネットワークから比較的に低速接続でネットワークに接続されたユーザへデータページを送る際に起こるユーザに知覚される遅延を削減可能とすることが望ましい。
【０００６】
また、ブラウザのキャッシュ能力をより有効に利用可能とすることが望ましい。
【０００７】
そこで、本発明の目的は、比較的高速のネットワークから比較的に低速接続でネットワークに接続されたユーザへデータページを送る際に起こるユーザに知覚される遅延を削減することである。
【０００８】
また、本発明の別の目的は、ブラウザのキャッシュ能力をより有効に利用することである。
【０００９】
【課題を解決するための手段】
本発明によると、データがページフォーマットで取り出され得るような種類のデータネットワーク上にデータページを転送および表示するための方法が提供される。当該ネットワークは、データページが記憶される少なくとも１つのサーバと、サーバに接続されたゲートウェイと、有限速度をもつデータ接続によりゲートウェイに接続されたユーザステーションとを有している。ユーザステーションは、１つのサーバから１つのページを要求する。本発明の方法は、１つのサーバからデータページを取り出すために、ユーザステーションからゲートウェイに要求を送ることを含んでいる。この要求に応じて、データページの以前のバージョンが呼び出される。もし以前のバージョンが最新のものでないと判断されると、ユーザステーションに転送されるデータページの、サーバの１つからゲートウェイへの取り出しが開始される。要求に応じゲートウェイでの受信が終了すると、要求されたデータページと以前のバージョンのページとの差異が求められ、その差異がユーザステーションに送られる。ユーザステーションでは、前のバージョンと当該差異との関数としてデータページが計算される。そして、計算されたページがユーザステーションに表示される。
【００１０】
本発明の上記した目的や他の目的および利点などは、添付の図面を参照することにより、以下の実施の形態から明らかとなるであろう。なお、図面においては同様の部位には同様の符号を付している。
【００１１】
【発明の実施の形態】
本発明はネットワークデータの転送全般に適用可能であるが、これから説明するインターネットとりわけワールド・ワイド・ウェブにとって特に有益であり且つ好適である。ワールド・ワイド・ウェブのアーキテクチュアは、ユーザ接続のネットワーク・ゲートウェイ端部においてプロキシ（proxy）というアプリケーションを採用している。ワールド・ワイド・ウェブのブラウザソフトウェアはプロキシと交信するように設計されており、その結果、プロキシはブラウザの要求をネットワークサーバに中継して送り、１以上のページ形式の要求されたデータを返送する。本発明によると、以下において「ローカルプロキシ」という第２のプロキシが、ソフトウェアによってユーザのコンピュータに設けられることが好ましい。ユーザのブラウザソフトウェアがプロキシとのコンタクトを試みた場合、それはローカルプロキシに接続される。ブラウザ・ソフトウェアに関する限り、ブラウザが要望および要求したときには、ブラウザはプロキシに接続される。そして、ローカルプロキシは接続のネットワーク端部にあるプロキシ（以下、「リモートプロキシ」という）と交信する。
【００１２】
ローカルプロキシが存在することにより、ネットワークへの接続の見掛けの速度を高める種々の技術を用いることができる。ユーザのブラウザ・ソフトウェアを変更せずにこのような技術を採用してローカルプロキシを設計することも可能であるが、１以上のこのような技術をブラウザ・ソフトウェアに組み込むことによりローカルプロキシを効果的にブラウザ内に構築することができる。しかしながら、本発明は、ローカルプロキシソフトウェアを別に設けることにより既存のブラウザとともに用いることができる。
【００１３】
見掛け上の接続速度を高めるためにローカルプロキシとともに用い得る好適な技術は、現時点において、ユーザステーションにおける計算速度および計算能力がより高速での接続に比べてより容易に得られ且つより安価であるという事実に基づいている。つまり、本発明は、要求されたページのキャッシュされているバージョンを取り出すことと、その後、キャッシュされているバージョンと現在のバージョンとの差異だけをリモートプロキシからローカルプロキシへ送信することに基づいている。ユーザ・ステーションは、その比較的に高速で安価な計算手段を用いることにより、キャッシュされているバージョンと受信した差異データとから最新ページを再構築する。
【００１４】
上記の差異を計算するための好適な技術は、１９９４年１２月１４日に出願された係属中の米国特許出願番号08/355,889号に開示されており、その総ては本願の参考とされる。しかしながら、当業者に知られているまたは当業者が開発したその他の技術であっても用いることができる。
【００１５】
リモートプロキシがローカルプロキシに差異データを送ることができるようにするためには、リモートプロキシで一旦受信した最新ページと既にローカルプロキシにあるページのバージョンとを比較して差異データを計算する必要がある。そのために、リモートプロキシは、ローカルプロキシに既にあるページのバージョンを知っている必要がある。これは、いくつかの方法で実現することができる。
【００１６】
まず、リモートプロキシはそのページの少なくとも１つのバージョンを記憶していなければならない（もしユーザに要求されたページがそのリモートプロキシに接続されたいずれのユーザにも要求されたことがないものである場合、リモートプロキシが最新ページを総て受信するのを待ってそのページの総てが送信される。ただし、リモートプロキシが最新ページを総て受信する前にその送信を開始できる場合を除く）。
【００１７】
一実施の形態においては、ローカルプロキシはページをキャッシュし（ローカルプロキシが以前にそのページを要求したことがあるものと仮定する）、そして、データページの要求の一部として、既にキャッシュされているのがどのバージョンかを確認する。リモートプロキシは、特定のバージョンがキャッシュされていたかどうかを調べ、もしキャッシュされていれば、最新ページを受信してからそのバージョンを用いて差異を計算する。もしリモートプロキシがその特定のバージョンをキャッシュに持っていなかったときには、リモートプロキシがもっていたなかで最も最新のものに近いバージョンをローカルプロキシに送るとともに、最新バージョンの受信を待つ。
【００１８】
本実施の形態の変形例として、リモートプロキシがローカルプロキシにキャッシュされているバージョンをもっている可能性を高めるために、リモートプロキシはあるページのいくつかの異なるバージョンをキャッシュする。別の変形例では、ローカルプロキシはあるページの２以上のバージョンをキャッシュする。また、例えば、ローカルプロキシは、取り出される総てのページの最も最新のものに近いバージョンあるいはキャッシュするようにタグを付けられた総てのページをキャッシュするようにプログラムされることができる。この実施の形態では、ローカルプロキシによってキャッシュされるあるページにリモートプロキシがタグを付けることが好ましい。例えば、人気のあるニュースのページの正午のバージョンは常にキャッシュされ、後のバージョンが取り出されたとしても保持される（後のバージョンもキャッシュされる）。どちらかのプロキシにキャッシュされる量が増えると、リモートプロキシが最新ページを待つ間に転送されるデータ量が減少するが、一方または両方のプロキシにより大きな記憶容量が必要となる。しばしばコンテントプロバイダ（a content privider）またはネットワークサービスプロバイダと関連しているリモートプロキシの記憶容量をより大きくすることは容易であるが、通常家庭またはオフィスのパーソナルコンピュータにあるローカルプロキシの記憶容量を大きくするのにはコストがかかる。
【００１９】
リモートプロキシがコンテントプロバイダから最新ページを要求するとき、リモートプロキシがもつ最後のバージョンまたはローカルプロキシがもっているあるいはもっているべきであるとリモートプロキシが知っているバージョンの時刻以来そのページが変更されている場合のみ、リモートプロキシはそのページが送信されるように要求する。ＨＴＴＰプロトコルはこのような要求のためのコマンドを備えている。もしリモートプロキシが変更なしのメッセージを戻す場合、リモートプロキシはローカルプロキシが既にもっているページが最新のものである（以前にローカルプロキシがそのページをキャッシュしたため、または、ローカルプロキシがコンテントプロバイダのサーバからのレスポンスを待っている間にそのページを送信したため）というメッセージをローカルプロキシに送ることができ、ローカルプロキシは既に自身がもつページをブラウザに引き渡して表示させる。
【００２０】
一方、もしリモートプロキシがページの新しいバージョンを受け取った場合、リモートプロキシはその新しいバージョンを送るべきかあるいは差異データを計算してそれを送るべきかを判断しなければならない。この判断は、いくつかの要因に依存する。
【００２１】
もしローカルプロキシがそのページの以前のバージョンを既に持っていた場合（ローカルプロキシがそれをキャッシュしていたことにより、または、リモートプロキシが最新バージョンを待っている間にそれを送信したことにより）、新しいバージョン全体を送るべきかあるいは差異データを計算してそれを送るべきかを決定する最も重要な要因は、その新しいバージョンと差異データとの相対的なサイズである。つまり、リモートプロキシは差異データを計算し、そして差異データのサイズと新しいバージョンのサイズとを比較する。もし新しいバージョンが差異データよりも大きくなければ、リモートプロキシはこの新しいバージョンとともに、これは新しいバージョンであり、古いバージョンに基づく再構築は不要である旨のメッセージをローカルプロキシに送る。そして、ローカルプロキシはブラウザに新しいバージョンを渡してそれを表示させる。
【００２２】
もし新しいバージョンが差異データよりも大きい場合、リモートプロキシは新しいバージョンがどれ位大きいかに基づいて決定を行わなければならない。なぜならローカルプロキシが再構築を行うにはある程度の時間が必要であり、もし新しいデータが差異データと同じサイズまたは差異データよりも僅かに大きいのであれば、差異データよりも新しいバージョンを送信するほうが早くなる（ユーザがいつ要求されたページを見ることができるかという点から）。新しいバージョンが大きくなって、その新しいバージョンの送信の必要がなくなったか否かの判断は、リアルタイムで測定されてより多くの要因に依存してよく、その結果、新しいデータよりも差異データを送信する限度となる値のサイズは動的に計算される。しかしながら、もしその計算がユーザステーションのプロセッサ速度のようにリモートプロキシにより簡単に決定することができない変数に依存しているのであれば、新しいバージョンが差異データの約１２０％のサイズになるまではこれをそのままローカルプロキシに送ることができるとリモートプロキシが単純に仮定するようにしてもよい。
【００２３】
もしリモートプロキシがいまなお古い旧（stale）バージョンのページをローカルプロキシに送っているのに要求されたページがリモートプロキシに到着した場合、リモートプロキシは、旧バージョンを継続して送るか、または送信を中止して単に新しいバージョンのページ全部をおくるかを決定しなければならない。この決定も、新しいバージョンを送信するのにかかる時間と、旧バージョンを最後まで送り且つ差異データを送信するのにかかる時間との比較に依存する。新しいバージョンを送信するのに必要な時間は、そのサイズから知ることができ、また適当な統計的推量を用いて見積もることができる。同様にして、旧データの送信を完了するのに必要な時間も知ることができる。分からないのは差異データのサイズである。もし新しいバージョンのサイズが残りの旧データよりも小さければ、新しいバージョンが送られる。そうでない場合、差異データが旧ページのサイズのある平均値（好適な実施の形態では４０％である）であると仮定される。従って、もし旧データの４０％未満が既に送信されている（すなわち、６０％を超えるデータが残っている）場合、新しいバージョンを送信するために旧データの送信は中止してよい。逆に言うと、もし旧データが４０％を超えて既に送信されている（すなわち、６０％未満が残っている）場合、旧データの残りとそれに加えてさらに差異データを送信し続けるのは有効であろう。なぜなら、旧データの残りおよび差異データの合計は新しいバージョンよりもサイズが小さくなるであろうからである。
【００２４】
もちろん、もし旧データの送信が続けられ、差異データが計算された場合、差異データが４０％よりも大きく、上記決定が逆効果となってしまうであろうことが特定のリクエストについて判明するかもしれない。または、もし新しいバージョンを送ると決定した場合であっても、差異データが予期したよりも小さいことが分かるかもしれない。しかしながら、他のデータがない場合においては、ページサイズの４０％を差異データサイズのデフォルトのサイズとしておくことが平均して効果的であることが期待される。また、例えば、差異データのサイズを時間を追って包括的にまたは個々のページ（例えばＵＲＬにより）またはサーバについてたどり続け、その情報をデフォルトの差異データサイズを定期的に調節するために用いることも可能である。また、後述するように、差異データのサイズを段階的に（大至急に）見積もりまたは計算することも可能である。
【００２５】
いくつかのケースにおいては、まだ旧データを送っているときまたはその後において、差異データが非常に大きいため（差異データは理論的にはページのサイズよりも大きくなることがある）、旧データを送り続けるのが無意味であると判断される。その時点で、旧データと差異データとを送ると言う決定は取り消され、もしもまだ旧データの転送が続いていればそれが中止され、新しいページの全体が転送される。もしも差異データが新しいページよりもサイズが大きいのであれば、たとえ旧データの転送が完了していても新しいページの全体を送信することは意味のあることである。
【００２６】
上述した係属中の米国特許出願に記載された差異データの計算技術の好適な実施の形態では、別の効果（side-effect）として、オリジナルのページデータの圧縮バージョンを出力する。これにより、非圧縮バージョンの代わりにキャッシュに記憶され得る各ページの圧縮バージョンを得ることができ、そのために所定のキャッシュサイズにキャッシュされ得るページ数を増加させることができる。さらに、上記技術は、トータルでデータページの新しいバージョンよりもせいぜい数バイト以下大きい差異データを生成する。従って、もしこの好適な技術が用いられた場合、差異データの送信を中止しないことに対する不利益が存在しないので、差異データの送信を中止しなくてもよい。しかしながら、以下に述べる議論は、上記の好適な技術のように効果的でないものをも含んで、用いられ得るいかなる差異計算技術にも適用される。
【００２７】
ここまでの議論は、ユーザが既にキャッシュされているページと同じアドレスのページを要求することを仮定している。例えば、ワールド・ワイド・ウェブに関して言うと、同じＵＲＬ（Uniform Resouce Locator）をもつページである。しかし、本発明は、ページのアドレスが全く同一ではなく類似している場合であっても有益であることがある。なぜなら、これらアドレスには、ある可変領域が異なっても同一の静的コンテントが含まれることがあるからである。例えば、複数のページを含むワールド・ワイド・ウェブのサイトでは、多くのページが共通の特徴を持つ類似のレイアウトを有している。同様に、特定のサーチエンジンでの検索結果を含むページは、実質的に同じグラフィカルレイアウトを一般に有しており、ただテキストデータだけが検索結果ごとに異なるだけである。従って、もし特定のサーチエンジンへの検索がユーザによって開始されたならば、システムはローカルプロキシまたはリモートプロキシにあるそのキャッシュのいずれかから前もってそのサーチエンジンの総括ページまたはそのサーチエンジンから最後にキャッシュされた検索結果を取り出し、必要な差異データが上記いずれかから計算され得る。
【００２８】
このようなキャッシュされた検索結果の場所を見付けることは、ワールド・ワイド・ウェブの場合には難しいことではない。特定のサーチエンジンからのサーチ結果のＵＲＬは、通常共通の語幹（stem）を有している。すなわち、ＵＲＬの始めの部分は同じで、後の方は特定のサーチを特徴づけている。サーチ目的物（criteria）はしばしばＵＲＬ中において、通常語幹に続く "cgi-bin" という文字列の後に配置されている。システムは、これらの文字列をＵＲＬ中に発見したときに、そのＵＲＬが現在のＵＲＬと同じ語幹をもつ総てのページのキャッシュされているバージョンを捜し出すように設計され得る。キャッシュされたページからより広く同様のページを捜し出す他の技術としては、受信したデータと、そのデータと同じホストを起源とした同様のサイズを有するいずれかのキャッシュされたページとを比較するものがある。この場合、リモートプロキシは、どのページがどのローカルプロキシに送られたかの情報を得るようにしなければならないであろう。また、単にキャッシュされている総てのページを比較することもできるが、たまたま早期に類似のものが見つからなければ、単純に新しいページを送信するよりも長い時間を要することがある。
【００２９】
また、上述の議論では、リモートプロキシがページの新しいバージョン全体を受信するまで差異データが計算されないことが仮定されていた。しかしながら、本発明は、差異データを大至急、すなわち、新しいバージョンを受信しつつ連続して計算する可能性を含むものである。
【００３０】
例えば、任意のデータサイズが選択され、そのサイズがリモートプロキシに受信されるデータの各かたまり（chunk）が、キャッシュされているバージョンと比較されて差異データが抽出される。かたまりのサイズは、システムが僅かなサンプルから差異データを計算することがないほどに大きいが、システムのパフォーマンスに相違が生じるだけ頻繁に差異データを生成できるほどに小さい。
【００３１】
もしページの２つのバージョン間の差異がテキストの挿入だけであれば、周知の比較技術によりそれを検出することができ、そしてシステムは、各かたまりごとに差異データを送る必要なく、挿入コマンドとともに挿入されるべきデータを送る。同様に、もしページの２つのバージョン間の差異が削除だけであれば、システムは各かたまりごとに差異データを計算するのではなく、同じようなやり方でこれを処理する（例えば、削除（delete）コマンドを用いる）。
【００３２】
同様に、かかるシステムは、いつ差異データを送るかを決定することが可能であることが好ましい。もし特定のかたまりについての差異データが小さければ、それが生成されてからすぐに送ることには意味がなく、むしろ差異データが追加されるのを待ったほうがよいこともある。ローカルプロキシに送られる前に蓄積される差異データの量は、好適な実施の形態においては以下のようにして定めることができる。
【００３３】
ここで、生成されたが送信されていない差異データを含んで差異データの非送信バイト数をＤとする。また、送信されたか否かに拘わらず、生成された差異データの全バイト数をＤtotとする。また、すでに処理された新しいバージョンのバイト数をＣとする。また、オリジナルページのサイズをＳとする。さらに、下限値（下限しきい値）をＴsmallとし、上限値（上限しきい値）をＴlargeとする。
【００３４】
本実施の形態では、Ｔsmall＜Ｄ、且つ、Ｄtot＜Ｆ（Ｓ，Ｃ，Ｔlarge）となったときに蓄積された差異データを送信する。ここで、Ｆは、オリジナルページのサイズと、すでに処理されたデータのサイズと、上限値Ｔlargeとの関数である。関数Ｆは、差異データを送信してももはや利益がない時点についてのカットオフを生成する。このカットオフは、受信した累積バイト数をもとにすると、オリジナルファイルサイズの８０％（０．８Ｓ）でよい。また、これの代わりに、Ｓを無視して、Ｄtot＜０．８Ｃが満たされる限り差異データを送信するようにしてもよい。さらに、より複雑な関数を用いることもできる。
【００３５】
もしＤ＜Ｔsmallであれば、差異データは送信されない。そして、蓄積されたすべてのデータは、より多くの差異データが計算されるまで保持される。例えば、Ｔsmallは最大パケットサイズの１／２でよく、それ以下の量のデータを送るのは不経済である。
【００３６】
一方、もしＤtot≧Ｆ（Ｓ，Ｃ，Ｔlarge）であれば、すでに計算された差異データは大き過ぎるので、差異データの計算は中止される。そして、新しいページの全体が送信される。本実施の形態の「大至急」という性質と一致するように、システムがページ全体が到着するのを待ってページをローカルプロキシに送信することは好ましくなく、その代わりに、すでに受信しているだけのデータが送信され引き続き新しいページのデータが到着するにつれて送信される。なお、もし上述した差異計算技術の好適例が用いられた場合、差異データの送信を続けることが不利益になることはほとんどないことを記しておく。
【００３７】
さらに、新しいバージョンの推定サイズに基づいて、まだ計算されていない差異データを含み未送信の差異データの総量を調べるのが有効なことがある。未送信のデータ量は、既に計算されていて且つ未送信であるすべての差異データの量に、まだ計算されていない総ての差異データの量を加えたものとして見積もることができる。後者の値は、データページの以前のバージョンの全サイズと新しいバージョンの既に処理された部分のサイズとの相違量の関数として見積もることができる。
【００３８】
上述のように、差異データが大至急に計算される場合、送信中の旧データの量に差異データの量を加えたものと新しいページ全体を送る際に含まれるデータの量とを、大至急に、比較して計算または少なくとも見積もりしなければならない。旧データを送信し続けるかどうかの決定は、よりよい情報に基づいてなすことができる。これは、以下のようにしてなされる。
【００３９】
まず、ページのオリジナル（旧）バージョンのサイズをＡとする。また、ページの新しいバージョンのサイズをＢとする（もしＢが分かっていないならば、Ａに等しいと見積もりしてよい）。また、ページのオリジナルバージョンのうち既にローカルプロキシに送信された部分のサイズをＰA とする（そのページのオリジナルバージョンの全体が既に送信されている場合はＡに等しい）。同様に、ページの新しいバージョンのうち既にリモートプロキシが受信した部分のサイズをＰB とする。つまり、これらの変数すべては既知の値である。もし上述の好適な差異計算技術が用いられるのであれば、これらの変数は圧縮データを表していてもよいことを記しておく（上述のように、差異データを決定するための型通りの好適な実施の形態ではデータを圧縮する）。圧縮データについて明確に言及する場合、記号ＣXはｘで表される量の圧縮されたバージョンを表すために用いられる。
【００４０】
ここで、ページのオリジナルバージョンと新しいバージョンとの差異を表すデータのサイズをΔB,Aとする。また、新しいページの圧縮バージョンのサイズをＣB とする。これらの２つの変数は新しいバージョンをすべて受信したらすぐに分かるものである。また、ページのオリジナルバージョンと新しいバージョンのうちすでに受信した部分との差異を表すデータのサイズをΔＰB,Ａとする。この変数は、新しいバージョンのデータを部分的に受信したらすぐにわかるものである。
【００４１】
もしＰA＝Ａであれば、旧データの全体がすでに送信されており、差異データが計算されればこれを送信することができる。もしＰA＜Ａであれば、旧データはまだ送信途中であり、送信を中止してページの新しいバージョンを単純に送信するかどうかを決定しなければならない。上述のように、新しいバージョンを総て受信するまで差異データが計算されないときには、これは差異データの全サイズを見積もることができるかどうかで決まる。しかしながら、ここでは差異データが大至急に計算されるため、この見積もりはより正確に行うことができる。
【００４２】
すなわち、もし残っている旧データの量に見積もられた差異データのサイズを足し合わせたものが新しいバージョン（または圧縮が行われる好適な実施の形態においては圧縮された新しいバージョン）の見積もり総量より小さければ（以下の式が成り立てば）、旧データがそのまま送信されるのが好ましい。
ＣA−ＰｃA＋ΔB,A＜ＣB
【００４３】
もし差異データの全サイズがそのページの一部についての差異データに比例していると仮定すると（常にではないがしばしば真実である）、部分的な差異データが一回計算されると、差異データの全サイズは以下のように見積もることができる。
ΔB,A≒Ｂ * （（ΔＰB,Ａ）／ＰB）
例えば、もしページの新しいバージョンの前半分についての差異データのサイズがオリジナルページサイズの４分の１であれば、ページの新しいバージョンの差異データの全サイズはその２倍、つまりオリジナルページサイズの２分の１と見積もることができる。
【００４４】
もし圧縮が行われていれば、圧縮されたファイルサイズも見積もらなければならない。もしオリジナルバージョンが圧縮形式でローカルプロキシに送信されたならば、そのサイズＣA は分かっている。そして、圧縮された新しいバージョンのサイズＣB は以下のように見積もることができる。
ＣB≒Ｂ * （ＣA／Ａ）
また、一度得たページの部分圧縮バージョンのサイズから全ページの圧縮率を見積もることができる。
ＣB≒ＣｐB * （Ｂ／ＰB）
【００４５】
これらの見積もりを行うことにより、残っている旧データの送信を続けるべきか中止すべきかをいつでも決定することが可能である。また、ページの新しいバージョンをさらに受信したときに、見積もりは改良される。
【００４６】
図１は、本発明の方法を用いることができるシステム１０の概略的なブロック図を示している。ユーザステーション１１は、一般的にはブラウザソフトウェア１２が動作するパーソナルコンピュータである。ユーザステーション１１はローカルプロキシ・ソフトウェア１３をも動作させる。ローカルプロキシ・ソフトウェア１３は、もしネットワークサービスプロバイダ自身のシステムが本発明の方法を用いることができるのであれば、そのプロバイダによって提供されるのが一般的であろう。ユーザステーション１１は、低速のリンク１４（上述したように、好ましくはモデム）によってネットワークサービスプロバイダＰＯＰ（Point-of-Presence）１５に接続されている。ネットワークサービスプロバイダＰＯＰ１５は、好ましくはＴ１接続のような非常に高速の接続１７によりネットワーク１６（例えばインターネット）に接続されるのが好ましい。ネットワークサービスプロバイダＰＯＰ１５は、リモートプロキシ１５１（好ましくはソフトウェアとして存在する）を有するゲートウェイ・サーバ１５０を好ましくは含んでいる。リモートプロキシ１５１は、多くのユーザステーション１１（図示せず）のローカルプロキシ１３と交信する。上述したように、ローカルプロキシ１３の機能はブラウザ自身の中に組み込むことが可能であり、同様に、リモートプロキシの機能もゲートウェイサーバ１５０内に組み込むことが可能である。ＨＴＴＰプロトコルにより、ブラウザ（またはローカルプロキシ）は要求されたページのキャッシュされているバージョン（もしあれば）を識別することができ、もし新しいバージョンをもっているため関連するデータサイズ（下記参照）が分かっているサーバがそれに基づき適当であると判断すると、リモートプロキシが組み込まれたサーバは差異データを生成し且つそれを送信することができる。
【００４７】
ネットワーク１６は、他のネットワークサービスプロバイダＰＯＰとともに、コンテントサーバを有するコンテントプロバイダを含んでおり、ユーザはネットワークサービスプロバイダＰＯＰを通してコンテントサーバから情報を捜し出す。
【００４８】
ユーザのブラウザ１２は１つのプロキシと交信するように設計されている。既知のシステムでは、ブラウザ１２と交信するプロキシはリモートプロキシ１５１である。しかしながら、本発明においては、ユーザステーション１１はローカルプロキシ１３を有しており、ネットワークサービスプロバイダは本発明の方法に適合しているため、ブラウザ１２はローカルプロキシ１３と交信し、その結果としてリモートプロキシ１５１と交信する。ローカルプロキシ１３は、ブラウザ１２が通常プロキシから要求するであろうすべてのメッセージをブラウザ１２に送るようにされている。従って、ローカルプロキシ１３はブラウザ１２に対しては透明である。しかしながら、リモートプロキシ１５１が本発明の方法に適合しているときには、ローカルプロキシ１３はネットワークサービスプロバイダからのソフトウェアによって好ましくは生成されるためほとんど必然的にローカルプロキシ１３が存在することになり、ネットワークサービスプロバイダは自身のリモートプロキシ１５１が本発明に適合したものであればそのソフトウェアをおそらく提供するだけであって、ローカルプロキシ１３とリモートプロキシ１５１とは接続１４の見掛けの速度を増大させるようなやり方で交信することが可能となる。見掛けの速度の増大は多くのやり方で達成されるが、上述した方法を用いて達成するのが好ましい。この方法を図２〜図５に示し、以下で説明する。
【００４９】
ローカルプロキシ１３で実行されるプロセス２０の好適な実施の形態の機能が、図２および図３に示されている。
【００５０】
ステップ２１において、ローカルプロキシ１３は、特定のＵＲＬで識別されるページを取り出す旨の要求をブラウザ１２から受信する。テスト２２において、システムは、要求されたページがローカルにキャッシュされているかどうかを調べる。もしキャッシュされていれば、テスト２３において、システムは、キャッシュされているバージョンがまだ有効であるかどうかを調べる。このテストは、キャッシュされているデータに記録された有効期日を参照して行うことができる。その代わりとして、ブラウザは、キャッシュされているバージョンは使用できるものではなく、要求されたページはそのコンテントプロバイダから再読み込みしなければならないという指令を送るようにしてもよい。もしテスト２３でキャッシュされているバージョンが有効であると判断されると、ローカルプロキシ１３はステップ２４においてキャッシュされているバージョンをブラウザ１２に戻し、ステップ２５で本方法は終了する。
【００５１】
もしテスト２３で要求されたページのキャッシュされているバージョンがもはや有効でないと判断されると、ステップ２８において、要求されたページがリモートプロキシ１５１に要求される。この要求の一部として、リモートプロキシ１５１は、ローカルプロキシ１３が差異データを扱うことができ且つどのバージョンがローカルプロキシ１３にキャッシュされているかという通知をローカルプロキシ１３から受ける。そして、システムは、上記要求に応答したデータを受け取り且つそのデータを処理するのを待つステップ２７に進む。
【００５２】
もしテスト２２で要求されたページがキャッシュされていないと判断されると、ステップ２６においてそのページがリモートプロキシ１５１に要求される。この要求の一部として、リモートプロキシ１５１は、ローカルプロキシ１３が差異データを扱うことができるという通知をローカルプロキシ１３から受け、そしてシステムは上記要求に応答したデータを受け取り且つそのデータを処理するのを待つステップ２７に進む。
【００５３】
ステップ２７におけるレスポンスの処理は、図３に詳細に示されている。ＨＴＴＰレスポンスはＭＩＭＥ（Multipart Internet Mail Extensions の頭字語）として知られているプロトコルのもとで送信される。ＭＩＭＥプロトコルのもとでは、メッセージは単一部分メッセージまたは複数部分メッセージとなりうる。これに関連して、もしレスポンスが単一部分メッセージであれば、それは要求されたページの新しいバージョンであり、もしレスポンスが複数部分メッセージであれば、それは要求されたページの新しいバージョンかそのページの差異データあるいは旧バージョンのいずれかであってよい。複数部分メッセージのコンテントを識別する情報は、複数部分メッセージの最初の部分に存在する。従って、プロセス２７は、レスポンスがＭＩＭＥ複数部分メッセージであるかどうかをシステムが調べるテスト３０から始まる。もしＭＩＭＥ複数部分メッセージでなければ、それは新しいページであり、ステップ３１で新しいページがローカルプロキシ１３にキャッシュされ、そしてブラウザ１２に戻されて表示される。
【００５４】
もしテスト３０でレスポンスがＭＩＭＥ複数部分メッセージであると判断されると、テスト３２において、送信されたデータを同定するメッセージの最初の部分が要求されたページの旧バージョンであるかどうかをシステムが調べる。もし旧バージョンであれば、システムは、テスト３３において、旧データの送信が中止されるか（リモートプロキシが新しいページの全体が送信されるべきであると決定した場合）をモニタし続ける。もし中止されれば、残りの送信は要求されたページの新しいバージョンとなり、ステップ３１において新しいバージョンがローカルプロキシ１３にキャッシュされ、そしてブラウザ１２に戻されて表示される。もしテスト３３で旧データの送信が中止されなければ、ステップ３４で旧データがキャッシュされ、ステップ３５でシステムは同様に処理される差異データを待つ。
【００５５】
もしテスト３２でデータが旧バージョンのデータではないと認められると、それは差異データであることもあり、その可能性がテスト３６で調べられる。もしデータが差異データであれば、この差異データが要求されたページのキャッシュされているバージョンに加えられ（ステップ３７）、そしてそのページの新しいバージョンが生成され、それがステップ３１でローカルプロキシ１３にキャッシュされ、そしてブラウザ１２に戻されて表示される。もしテスト３６でデータが差異データではないと認められると、そのデータは新しいページ全体ということになり（レスポンスの複数部分性にもかかわらず）、ステップ３１においてローカルプロキシ１３にキャッシュされ、そしてブラウザ１２に戻されて表示される。
【００５６】
リモートプロキシ１５１で実行されるプロセス４０の好適な実施の形態の機能が、図４および図５に示されている。
【００５７】
プロセス４０は、特定のＵＲＬで識別される特定のページへのユーザステーション１１からの要求をリモートプロキシ１５１が受信するステップ４１から始まる。特定のユーザステーション１１がローカルプロキシ機能をイネーブルにしなくともよく、従ってプロセス４０はその可能性をも説明できるものであり且つ旧式のブラウザからの要求をも考慮したものであることが好ましいことを記しておく。
【００５８】
テスト４２において、リモートプロキシは要求されたページが自身のキャッシュ内にあるかどうかを調べる。もしキャッシュ内にあれば、テスト４３において、リモートプロキシはキャッシュされているバージョンが有効かどうかを調べる（例えば、有効期日／時間を参照して）。もしテスト４３でキャッシュされているバージョンが有効であるとされると、テスト４４でリモートプロキシは両方のプロキシ（すなわち、ローカルプロキシ１３とリモートプロキシ１５１）が同じバージョンをキャッシュしているかどうかを調べる。もし同じバージョンがキャッシュされているならば、ステップ４５において、リモートプロキシ１５１は、ページが変更されていないことをローカルプロキシ１３に通知し、そしてプロセス４０はステップ４６で終了する。もしテスト４４において両方のプロキシが同じバージョンをもっていないと判定されると（これはローカルプロキシが全く存在しない場合を含みうる）、ステップ４７でリモートプロキシ１５１はローカルプロキシ１３に新しいページを送り、プロセス４０はステップ４６で終了する。
【００５９】
もしテスト４２でリモートプロキシ１５１が要求されたページのバージョンを自身がキャッシュしていないと判断すると、ステップ４８において、リモートプロキシ１５１はネットワーク１６を介してコンテント・プロバイダにそのページを要求する。そして、ステップ４９において、リモートプロキシはそのコンテントの到着を待ってその処理を行う。
【００６０】
もしテスト４３において、キャッシュされているバージョンは期限切れまたはその他の理由で有効ではないとリモートプロキシが判断すると、リモートプロキシは、（１）リモートプロキシがネットワーク１６を介してコンテント・プロバイダにそのページを要求するステップ４８に進み、さらにリモートプロキシがそのコンテントの到着を待ってその処理を行うステップ４９に進み、同時に、（２）テスト４００で両方のプロキシに（ローカルプロキシがあるものと仮定する）同じものがキャッシュされているかを判定する。もしそうであれば、リモートプロキシ１５１は、ステップ４９において、要求されたコンテントの到着をもってそれを処理する。もしテスト４００で両方のプロキシに同じバージョンがキャッシュされている（これはローカルプロキシが全く存在しない場合を含みうる）とリモートプロキシが判定すると、テスト４０１において、ユーザステーションが差異データと旧データとを処理して新しいページを構築することが可能であるかどうかをリモートプロキシが判定する（プロセス２０のステップ２６および２８で説明したように、ローカルプロキシは自身が差異データを処理することができるか否かをリモートプロキシに通知し、そしてリモートプロキシはこのどちらのメッセージをローカルプロキシから受け取ったかに基づいてテスト４０１において判定を行う）。もし差異データを処理できるというメッセージを受け取っていれば、既に２つのプロキシがページの異なるバージョンをキャッシュしていることが分かっており、ステップ４０２において、リモートプロキシは自身がキャッシュしているバージョンをローカルプロキシに送信し（これにより、２つのプロキシは差異データを用いてページを構築すべく同じ出発点に立つことになる）、さらにステップ４９において、要求されたページの到着を待ってこれを処理する。もしテスト４０１でユーザステーションは差異データおよび旧データを処理して新しいページを構築することができないと判断されると（例えばローカルプロキシが存在しない場合）、リモートプロキシは単にステップ４９に進み、当のユーザステーションにその全部が送信されるべき新しいページの受信を待つ。
【００６１】
図５にその詳細を示すプロセス４９は、要求されたページをコンテント・プロバイダからネットワーク１６を経て受信するステップ５０から開始される。テスト５１において、リモートプロキシは、ユーザステーション１１が差異データを処理できるかどうかを判定するテストを行う。もし処理できないのであれば、ステップ５２において、リモートプロキシは新しいページの最新バージョンをキャッシュしてそれをユーザステーションに送信する。もしテスト５１でユーザステーションは差異データを処理できる（すなわち、ユーザステーションが本発明に従ったローカルプロキシを含んでいる）とリモートプロキシが判定すると、テスト５３において、両方のプロキシが同じバージョンをキャッシュしているか否かをリモートプロキシが（ローカルプロキシから送信されたデータに基づいて）判定する。もし同じバージョンをキャッシュしていれば、リモートプロキシは後述のテスト５８に進む。もしテスト５３で２つのプロキシが同じデータをキャッシュしていないとリモートプロキシが判定すると、リモートプロキシはテスト５４に進み、そこで旧データ（すなわち、リモートプロキシにキャッシュされていた以前のバージョンであって、ステップ５０において新しいバージョンが到着する前にローカルプロキシへの送信が開始されたもの）がいまなおローカルプロキシへの転送途中であるかをリモートプロキシが判定する。もし転送途中でない（すなわち、旧データの転送が既に完了している）と判定されると、リモートプロキシは後述のテスト５８に進む。もしテスト５４で旧データがまだ転送中であると判定されると、テスト５５において、リモートプロキシは、送信されずに残存している旧データの量がしきい値（例えば、上述したように旧バージョンのサイズの６０％）よりも大きいかどうかを判定する。もししきい値よりも大きければ、ステップ５６において、旧データの転送が中止され、リモートプロキシはステップ５２に進み、そこでリモートプロキシはページの最新バージョンをキャッシュしてそれをユーザステーションに転送する。もしテスト５５で残存する旧データの量がしきい値より小さい（すなわち、旧データのほとんどが送信済みである）とリモートプロキシが判定すると、ステップ５７において、リモートプロキシは旧データの転送を完了させ、テスト５８へと進む。
【００６２】
テスト５８において、このテストへのリモートプロキシの到達経路に拘わらず、リモートプロキシは、新しく受信したデータがキャッシュされているデータと異なるかどうかを判定する。この判定は、実際のファイルの比較または日付／時間スタンプの比較により行われる。その他、新しく受信したデータが、キャッシュされていたバージョンはまだ最新のものであるという旨のコンテント・プロバイダからの単なるメッセージであってもよい。もしこれらいずれかの方法で新しいデータがキャッシュされているデータと異ならないと判定されると、ステップ５９において、リモートプロキシはローカルプロキシにそこにキャッシュされているバージョンが最新のものである（ローカルプロキシが既にそのバージョンをキャッシュしていたか、またはローカルプロキシが前に行われたデータ転送でそのバージョンを受信したかのいずれか）旨を通知する。（新しいデータがキャッシュされているデータと同じであると判定する方法がコンテント・プロバイダからの「変更なし」というメッセージに依存している場合、上述のステップ５２において、最新バージョンの送信はキャッシュされているバージョンの送信を含んでおり、リモートプロキシがさらにキャッシュを続けることは実際にはステップ５２では必要ではないことを記しておく。）
【００６３】
もしテスト５８で新しいデータがキャッシュされているデータと異なると判定されると、ステップ５０３において、直接比較を行うことにより実際の差異が求められる。そしてリモートプロキシはテスト５００に進み、差異データのサイズがしきい値より小さいかどうかを判定する。上述したように、比較の方法の一つは差異データが新しいページそれ自身よりも小さいかどうかであるが、上述したように他の要因も考慮される。もしテスト５００で差異データのサイズがしきい値よりも小さいとされると、リモートプロキシはステップ５０１に進んで差異データをローカルプロキシに送信する。ローカルプロキシはその差異データを使って新しいページを再構築する（ステップ３７）。もしテスト５００で差異データのサイズがしきい値より小さくないとされると、リモートプロキシは差異データを送信するのは非効率的であると判断し、ステップ５０２に進んで単に新しいページをローカルプロキシに送信する。
【００６４】
図６はプロセス４９の変形例の一部を示しており、この例において差異データは上述したように大至急に計算され送信される。図６に示した部分的なプロセスは、図５のステップまたはテスト５０３、５００、５０１、および５０２に代わるものである。
【００６５】
まず、ステップ６５９において、新しいページデータの今までに受信した部分についての差異データが求められる。次に、テスト６０において、他に部分的差異データが保持されているかどうかが判定される（第１回目には常に答えはＮＯとなる）。もし他に部分的な差異データがなければ、テスト６１において、現在の部分的差異データのサイズが上述の送信の可否を決めるための下限値を超えているか否かが判定される。もし超えていなければ、テスト６２において、そのページの送信が完了したかが判定される。もし完了していなければ、ステップ６３において、部分的差異データは保持され他の以前に保持されている部分的差異データと共に蓄積され、ステップ６４において次の部分に進んでプロセスはステップ６５９に戻る。
【００６６】
もしテスト６１で現在の部分的差異データのサイズが送信の可否を決めるための下限値を超えていると判定された場合、またはテスト６２でそのページの送信が完了したと判断された場合（現在の部分的差異データはたとえ非常に小さくとも送信されなければならないことを意味する）、プロセスは後述するテスト６７に進む。
【００６７】
もしテスト６０で他に部分的差異データが保持されていると判定された場合、本方法はテスト６５に進み、保持されている部分的差異データと現在の部分的差異データの合計サイズが送信の可否を決めるための下限値を超えているかどうかが判定される。もし超えていなければ、テスト６６において、そのページの送信が完了したかどうかが判定される。もし完了していなければ、ステップ６３において、部分的差異データは保持され他の以前に保持されている部分的差異データと共に蓄積され、ステップ６４において次の部分に進んでプロセスはステップ６５９に戻る。
【００６８】
もしテスト６５で保持されている部分的差異データと現在の部分的差異データの合計サイズが送信の可否を決めるための下限値を超えていると判定された場合、またはテスト６６でそのページの送信が完了したかと判定された場合（現在の部分的差異データはたとえ非常に小さくとも送信されなければならないことを意味する）、プロセスはテスト６７へ進む。
【００６９】
テスト６７では、既に転送されたまたはこれから転送される部分的差異データの累積サイズが上述の上限値を超えていたかどうかが判定される。もし超えていれば、ステップ６８において部分的差異データの処理が中止され、新しいページデータがローカルプロキシに送信される。この送信は、リモートプロキシが新しいページの全体を受信してからまたはその一部をリモートプロキシが受信したときに部分的に行うようにしてもよい。このように上限値に達することにより部分的差異データの処理を中止するのは、非効率的である可能性が認められる。なぜなら、まだ計算されていない差異データの追加量が小さいかもしれないからであり、しかしそれを知る手段はなく、これについての技術を開発してもよい。
【００７０】
もしテスト６７で既に転送されたまたはこれから転送される部分的差異データの累積サイズが上限値を超えていないと判定されると、現在の部分的差異データおよび保持されている総ての部分的差異データはステップ６９においてローカルプロキシに送信される。そして、テスト６００において、そのページの送信が完了したか否かが判定され、完了している場合にはプロセスはステップ６０１で終了する。完了していない場合にはプロセスはステップ６４に進み次の部分が処理される。
【００７１】
本発明によると、キャッシュされたページはたとえ見掛け上の有効期限後であっても保持され且つキャッシュ不能のページであってもキャッシュされることは注意されるべきである。これは、以前のバージョンのデータを前もって送っておきそしてその後に差異データを送ることに基づくシステムでは、たとえ期限切れのバージョンであっても全くバージョンがないよりは好ましいからである。以前のバージョン（期限が切れているかどうかを問わない）と最新バージョンとの差異データが計算されうる限りにおいて、キャッシュされたデータの有効期限および「キャッシュ可能性能（cacheability）」は問題ではない。これは、キャッシュされているページが、取り出された最新ページに基づいて差異データを生成するためだけに用いられるという理由で許容されるものである。
【００７２】
【発明の効果】
以上説明したように、本発明によると、ブラウザのキャッシュ能力をある程度有効に利用することにより、相対的に高速のネットワークからそのネットワークに相対的に低速で接続されたユーザにデータページを送信する際に生じて知覚される遅延を削減することができる。なお、当業者は本発明を上述の実施の形態とは違ったやり方で実行できることを理解するであろうが、上記実施の形態は説明のために用いられたものであって本発明はそれに限定されるものではなく、本発明は特許請求の範囲のみによって限定されるものである。
【図面の簡単な説明】
【図１】  本発明の方法を用いることができるシステムの概略的なブロック図である。
【図２】  図１に示されたローカルプロキシによって実行される、本発明の方法の一部分のフロー図である。
【図３】  図２に示されたステップの１つを詳細に示すフロー図である。
【図４】  図１に示されたリモートプロキシによって実行される、本発明の方法の一部分のフロー図である。
【図５】  図４に示されたステップの１つを詳細に示すフロー図である。
【図６】  図４に示されたステップの１つの代替的な実施の形態を詳細に示すフロー図である。
【符号の説明】
１０  システム、１１  ユーザステーション、１２  ブラウザ、１３  ローカルプロキシ、１４  リンク、１５  ネットワーク・サービス・プロバイダ・ＰＯＰ、１６  ネットワーク、１７  高速接続、１５０  サーバ、１５１  リモートプロキシ。
【図１】
0004220000.tif 000002
【図２】
0004220000.tif 000003
【図３】
0004220000.tif 000004
【図４】
0004220000.tif 000005
【図５】
0004220000.tif 000006
【図６】
0004220000.tif 000007