JPH11500250A - 差分化通信システム - Google Patents

Abstract

(57)【要約】 第１のコンピュータに常駐している第１のアプリケーションから第２のコンピュータに常駐している第２のアプリケーションへ、外部通信リンクによって伝送されるデータを少なくする方法、装置およびコンピュータ・プログラム・プロダクト。この方法、装置およびコンピュータ・プログラム・プロダクトは第２のアプリケーションからの要求に応じて第２のアプリケーションに与えられる第１のアプリケーションからのデータ・ストリームを第１のコンピュータに常駐しているキャッシュに格納して、サーバ・ベース・キャッシュ項目を作成し、また第２のコンピュータに常駐しているキャッシュに格納して、クライアント・ベース・キャッシュ項目を作成することを含んでいる。第２のアプリケーションからの要求に問い合わせを行って、問い合わせを受けた要求に対応するクライアント・ベース・キャッシュ項目が存在しているかどうか、および問い合わせを受けた要求に対応するサーバ・ベース・キャッシュ項目が存在しているかどうかを判断する。応答データ・ストリームをインタセプトしてから、外部通信リンク上での応答の伝送を行い、またサーバ・ベース・キャッシュ項目と比較して、インタセプトされた応答とサーバ・ベース・キャッシュ項目との間の差分に対応した差分データを与える。差分データを外部通信リンクによって送り、またクライアント・ベース・キャッシュ項目を差分データと組み合わせて、第２のアプリケーションに与えられる応答データ・ストリームを作成することによって応答データ・ストリームを再構成する第２のコンピュータによって取得する。

Description

【発明の詳細な説明】 差分化通信システム 発明の分野 本発明は異なるコンピュータに常駐しているウェブ・ブラウザとウェブ・サー バなどのアプリケーションの間の通信方法に関する。詳細にいうと、本発明は２ 台のコンピュータの間の外部通信リンクによる通信を区別する方法に関する。 発明の背景 最近、「情報スーパーハイウェイ」に関して宣伝され、重要視されていること により、マスコミュニケーション媒体としてのインターネットがますます知られ 、受け入れられるようになってきた。複数のネットワークにまたがる通信と対話 のための実現可能な媒体としてインターネットがこのように広く認識されるよう になったことにより、コンピュータ・ネットワーク間の対話のためのインターネ ット標準化プロトコルに基づく大規模なユーザ基盤も確立されている。 インターネットのパラダイムは、インターネット・クライアント（ブラウザ） がインターネット・サーバと通信するクライアント−サーバ関係のパラダイムで ある。インターネットへのアクセスを拡大するために、クライアントとサーバが 使用する通信プロトコルと言語が標準化されるようになった。 これらのプロトコルには、クライアントとサーバの間の通信に使用される通信プ ロトコルであるハイパーテキスト転送プロトコル（ＨＴＴＰ）と、伝送制御プロ トコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）がある。ＴＣＰ／ＩＰの ＴＣＰ部分は、コンピュータ間またはアプリケーション間の通信のためのトラン スポート固有のプロトコルである。クライアントとサーバが通信する言語も標準 化されており、これはハイパーテキスト・マークアップ言語（ＨＴＭＬ）と呼ば れる。これらのプロトコルと言語は機械から独立しており、コネクションレスの 最善のプロトコルを使用して情報を送信し、各トランザクションは完全に自己完 結している。したがって、たとえば、クライアントからの各メッセージにはブラ ウザの機能に関する情報が含まれ、通信を完結させるために他のどの通信からも 独立している。クライアントとサーバの間の通信のこの自己完結性は「ステート レス」通信と呼ばれることがあり、これは所与の通信のためにクライアントとサ ーバの間で伝送しなければならないデータの量を増大させる。 ワールド・ワイド・ウェブのクライアント／サーバ・アプリケーションの関連 では、ユーザ・インタフェースとして機能するウェブ・ブラウザがクライアント であろう。ウェブ・ブラウザは適切なウェブ・サーバにユーザ要求を送り、ウェ ブ・サーバから返されたＨＴＭＬデータのフォーマットと表示を行う。また、ウ ェブ・ブラウザはＨＴＭＬデータを評価して、ブラウザが発行する後続のブラウ ザ要求を必要とする ことになるハイパーリンク・ステートメントがＨＴＭＬデータに埋め込まれてい ないかどうかを判断する。ウェブ・サーバはクライアントのためのサーバの役割 を果たし、ウェブ・ブラウザ要求を処理し、要求された応答をＨＴＴＰデータ・ ストリームのＨＴＭＬデータ部分として返す。 典型的なワールド・ワイド・ウェブ通信の例として、ウェブ・ブラウザがウェ ブ・サーバに対して「ホーム・ページ」を求める要求を出す事例を用いて、ＨＴ ＴＰとＨＴＭＬとＴＣＰとウェブ・ブラウザとウェブ・サーバとの間の基本的な 関係を例示する。ウェブ・ブラウザのユーザが特定のウェブ・サイトに対して情 報を要求すると、ウェブ・ブラウザはウェブ・サーバに所望のウェブ・サイト（ この例では「ホーム・ページ」）のユニバーサル・リソース・ロケータ（ＵＲＬ ）を指定する「ｇｅｔ」要求を送ることによって、ウェブ・サーバの通信を開始 する。ＵＲＬはウェブ・サイトのアドレスの役割を果たし、インターネット全体 を通じて固有である。次にウェブ・サーバは、ＵＲＬで指定されたホーム・ペー ジに対応するＨＴＭＬデータを入手してウェブ・ブラウザに供給する。この操作 には、インターネット・ウェブ・サーバによるインターネット上での通信がさら に必要となったり、ブラウザが接続しているローカル・ネットワーク内にあるサ ーバをＵＲＬによって指定する必要がある場合がある。次にウェブ・ブラウザは ウェブ・サーバからＨＴＴＰデータ・ストリームとして受け取ったＨＴＭＬデー タを評価して、アイコ ンやイメージなどのハイパーリンクが埋め込まれていないかどうかを調べ、その ようなハイパーリンクがある場合は、そのハイパーリンクのＵＲＬを指定する要 求を出して、指定されたデータを入手する。このデータはホーム・ページに組み 込まれ、ユーザに対して表示されることになる。この単純な例でわかるように、 ウェブ・ブラウザによる１つのユーザ入力要求の結果、ユーザ要求に対応するＨ ＴＭＬデータの受信に応答してウェブ・ブラウザが自動的に複数の追加の要求を 行うことになる。 インターネット・ベースのシステムの基本的な通信構造を第１図に示す。第１ 図では、ウェブ・ブラウザ１０が通信リンク１５を介してウェブ・サーバ２０と 通信する。この通信リンクは典型的にはローカル・エリア・ネットワーク接続、 ワイド・エリア・ネットワーク接続、電話回線による接続、またはその組合せで ある。ウェブ・ブラウザ１０はＴＣＰ／ＩＰを使用してウェブ・サーバ２０と通 信する。インターネット通信では一般に、ウェブ・ブラウザは、ウェブ・ブラウ ザとウェブ・サーバの間のＴＣＰ／ＩＰリンクを介してウェブ・ブラウザとウェ ブ・サーバの間で伝送される汎用通信プロトコルＨＴＴＰを使用して、ウェブ・ サーバと通信する。ウェブ・ブラウザ１０とウェブ・サーバ２０の間で伝送され る実データは前述のＨＴＴＰデータ・オブジェクト（たとえばＨＴＭＬデータ） である。ウェブ・サーバ２０はいくつかのウェブ・ブラウザからウェブ・ブラウ ザ通信を受け取り、 それらを適切なサーバにルーティングするプロキシとすることもできる。 ウェブ・ブラウザ／ウェブ・サーバと、それらの共通の情報とトランスポート ・プロトコルであるＨＴＭＬとＨＴＴＰの普及によって、ウェブ技法が情報への ネットワーク・アクセスのための汎用インタフェースとして急速に受け入れられ るようになった。さらに、ウェブ・ブラウザとウェブ・サーバの間の通信のため のプロトコルと言語が標準化されているため、ユーザがネットワーク情報にアク セスするためのウェブ・ブラウザとしてＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ ＴＭ、ＮＣＳＡ、ＭｏｓａｉｃＴＭ、ＷｅｂＥｘｐｌｏｒｅｒＴＭ、または他の どのブラウザを使用するかを問わず、通信プロトコルおよび言語は同じになる。 したがって、ウェブ・ブラウザの大規模なインストール済みユーザ基盤と、イン タフェースの接続性と、ＨＴＴＰ定義の共通ゲートウェイ・インタフェース（Ｃ ＧＩ）を使用したウェブ・アプリケーション・サーバの作成の容易さとが組合わ さって、ウェブ技法を大規模なクラスの書式ベース・アプリケーションにとって きわめて魅力的なものにしている。 インタフェースの普及と受け入れの拡大と同時に、移動体コンピューティング も普及している。ラップトップ、ノートブック、パーソナル・ディジタル／通信 アシスタント（ＰＤＡ／ＰＣＡ）およびその他の携帯用装置の使用によって、無 線通信の需要が増大している。しかし、無線ワイド・エリア ・ネットワーク、セルラ通信、およびパケット無線には、ウェブの環境で使用し た場合に共通の制約がある。１バイト当たりの高い通信コストと、遅い応答時間 と、低帯域幅と、信頼性のなさはすべて、ワールド・ワイド・ウェブのステート レス通信プロトコルに無線技法を使用するのを阻害している。また、ウェブ・プ ロトコルはステートレスであるため、１要求当たりのデータ量と無線接続を介し て伝送される通信要求の数は、通信が自己完結型でない場合に必要となる量と数 よりも大きい。したがって、無線技法またはいずれかの低速通信技法をウェブ技 法と組み合わせることは、ウェブ技法の汎用的性質の強さによって無線技法の弱 点がさらにひどくなるため実際的ではないと思われる。 発明の目的と概要 上記の制限事項に関して、本発明の１つの目的は、アプリケーション間のデー タ転送のオーバヘッドの量を少なくする通信システムを提供することである。 本発明の追加の目的は、ウェブ・ブラウザ／サーバ環境内で使用できる通信シ ステムを提供することである。 本発明の他の目的は、ウェブ・ブラウザ・アプリケーションまたはウェブ・サ ーバ・アプリケーションを修正する必要なしに低速通信または無線通信システム 内で既存の通信プロトコルおよび言語に適合できるようにすることである。 本発明の追加の目的は、ウェブ・ブラウザとウェブ・サー バの間で必要とされる通信の量を少なくし、それにより通信システムのパフォー マンスを向上させる通信システムを提供することである。 上記その他の目的に関して、本発明は、通信リンクを介して第１のコンピュー タ内に常駐する第１のアプリケーションから第２のコンピュータ内に常駐する第 ２のアプリケーションまで送信されるデータを少なくする方法を提供する。デー タは、外部通信リンクを介して第１のコンピュータから第２のコンピュータまで 送信される。本発明の一態様は第１のコンピュータに常駐しているキャッシュ内 の第２のアプリケーションからの要求に応答して第２のアプリケーションに与え られる第１のアプリケーションからのデータ・ストリームを格納して、サーバ・ ベース・キャッシュ項目を作成することを含んでいる。第２のアプリケーション からの要求に応じて第２のアプリケーションに与えられるデータ・ストリームも 、クライアント・ベース・キャッシュ項目を作成するために第２のコンピュータ に常駐しているキャッシュに格納される。第２のアプリケーションからの要求を 評価して、問い合わせを受けた要求に対応するクライアント・ベース・キャッシ ュ項目が存在していて、クライアント・ベース書式を与えるかどうかを判定する 。第２のアプリケーションからの要求にも問い合わせを行って、問い合わせを受 けた要求に対応するサーバ・ベース・キャッシュ項目が存在していて、サーバ・ ベース書式を与えるかどうかを判定する。第２のアプリケーシ ョンからの問い合わせを受けた要求に応じて第１のアプリケーションが発信した 応答に対応するデータ・ストリームをインタセプトしてから、外部通信リンク上 での応答の伝送を行い、またサーバ・ベース書式と比較して、インタセプトされ た応答とサーバ・ベース書式との間の差に対応する差分データを与える。差分デ ータは外部通信リンクによって第２のコンピュータへ送られ、第１のコンピュー タが送信した外部通信リンクによって伝送される差分データが外部通信リンクか ら取得される。第１のアプリケーションからの通信に対応した応答データ・スト リームが、クライアント・ベース書式を外部通信リンクから受信した差分データ と組み合わせて、インタセプトされた応答に対応する応答データ・ストリームを 作成することにより、外部通信リンクから受信したクライアント／サーバ固有デ ータ・ストリームから再構成される。インタセプトされた応答に対応する再構成 されたデータ・ストリームは、第２のアプリケーションに与えられる。 本発明の他の態様において、第２のコンピュータはサーバ・ベース書式がクラ イアント・ベース書式と同一であるかどうかを判定し、サーバ・ベース書式がク ライアント・ベース書式と同一でない場合には、サーバ・ベース書式と差分デー タとが外部通信リンクによって第２のコンピュータへ伝送される。第１のアプリ ケーションからの応答に対応するインタセプトされた応答データ・ストリームが 次いで、外部通信リンクから受信したサーバ・ベース書式を外部通信リンクから 受信した差分データと組み合わせて、インタセプトされた応答に対応するデータ ・ストリームを作成することにより再構成される。問い合わせを受けた要求に対 応するクライアント・ベース書式も受信したサーバ・ベース書式を問い合わせを 受けた要求に対応するクライアント・ベース・キャッシュ項目として格納するこ とによって更新される。 本発明のサーバ・リベース態様において、第１のコンピュータはサーバ・ベー ス書式とインタセプトされた応答の間の差が事前定義差分閾値よりも大きいかど うか判定する。サーバ・ベース書式とインタセプトされた応答との間の差が、事 前定義差分閾値よりも大きい場合には、問い合わせを受けた要求に対応するサー バ・ベース書式が、第１のアプリケーションから受信したインタセプトされた応 答データ・ストリームを、インタセプトされた要求に対応するサーバ・ベース・ キャッシュ項目として格納することによって更新される。この場合、比較は更新 されたサーバ・ベース書式を利用する。 本発明の他の実施の形態においては、第２のアプリケーションからの要求に対 応する複数のサーバ・ベース・キャッシュ項目が維持される。第２のアプリケー ションからの要求に問い合わせを行って、複数のサーバ・ベース・キャッシュ項 目が第２のアプリケーションからの要求に対応して存在していて、複数のサーバ ・ベース書式を与えるかどうかを判定する。第１のコンピュータは複数のサーバ ・ベース書式の１つがクライアント・ベース書式と同一であるかどうかを判定し 、 複数のサーバ・ベース書式の１つがクライアント・ベース書式と同一である場合 には、クライアント・ベース書式と同一である、複数のサーバ・ベース書式の１ つを利用する。 本発明のさらに他の実施の形態は、第２のアプリケーションからの要求に応じ て、第１のアプリケーションからのデータ・ストリームによって、サーバ・キャ ッシュ項目を更新することを含んでいる。第２のアプリケーションからの要求に 対応しており、かつ連続したサーバ・キャッシュ項目の間の差を表している複数 の差分データ・セットを、アーカイブ差分データを与えるために維持する。複数 のＣＲＣ項目も維持し、複数のＣＲＣ項目の各々が複数の差分データ・セットの １つと関連づけられ、差分データ・セットが導かれたサーバ・ベース書式を一意 に識別する。複数の差分データ・セットとＣＲＣとが第２のアプリケーションか らの要求に対応して存在しており、しかも複数のＣＲＣの１つがクライアント・ ベース書式と同一であるサーバ・ベース書式に対応している場合には、クライア ント・ベース書式に対応しているＣＲＣに対応するアーカイブ差分データ、連続 したアーカイブ差分データ・セット、現行サーバ・ベース書式に関して計算され た差分データ、および第１のアプリケーションからの応答が外部通信リンクを通 して第２のコンピュータへ送られる。外部通信リンクから受信したデータ・スト リームから、第１のアプリケーションからの通信に対応している応答データ・ス トリームを、クライアント・ベース書式を外部通信リンクか ら受信した差分データと逐次組み合わせて、インタセプトされた応答に対応する 応答データ・ストリームを作成することによって再構成する。第２のアプリケー ションからの要求に対応したクライアント・キャッシュ項目も、再構成したデー タ・ストリームによって更新される。 本発明の他の実施の形態において、第１のアプリケーションはウェブ・サーバ を含んでおり、第２のアプリケーションはウェブ・ブラウザを含んでいる。また 、外部通信リンクは無線通信リンクを含んでいる。さらに、他の実施の形態はＣ ＧＩ要求を含んでいるウェブ・ブラウザからの要求を含んでいる。 当業者ならわかるように、本発明の前述の態様は装置またはコンピュータ可読 プログラム手段としても提供することができる。 図面の簡単な説明 第１図は、典型的なウェブ・ブラウザ／ウェブ・サーバ・システムを示すブロ ック図である。 第２図は、クライアント・インタセプトとサーバ・インタセプトを使用する本 発明の一実施態様によるウェブ・ブラウザ／ウェブ・サーバ・システムを示すブ ロック図である。 第３図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい 実施例において、クライアント側インタセプト・モジュールによって行われる操 作を図示する流れ図 である。 第４図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい 実施例において、クライアント側インタセプト・モジュールによって行われる操 作を図示する流れ図である。 第５図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい 実施例において、サーバ側インタセプト・モジュールによって行われる操作を図 示する流れ図である。 第６図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい 実施例において、サーバ側インタセプト・モジュールによって行われる操作を図 示する流れ図である。 第７図は、差分計算データ転送システムを実施する本発明の好ましい実施例に おいて、クライアント側インタセプト・モジュールによって行われる操作を図示 する流れ図である。 第８図は、差分計算データ転送システムを実施する本発明の好ましい実施例に おいて、クライアント側インタセプト・モジュールによって行われる操作を図示 する流れ図である。 第９図は、差分計算データ転送システムを実施する本発明の好ましい実施例に おいて、サーバ側インタセプト・モジュールによって行われる操作を図示する流 れ図である。 第１０図（集合的に第１０図を形成する第１０Ａ図および第１０Ｂ図から構成 される）は、差分計算転送システムを実施する本発明の好ましい実施例において 、サーバ側インタセプト・モジュールによって行われる操作を図示する流れ図で ある。 第１１図は、仮想ソケットを使用する本発明の一態様を示すブロック図である 。 第１２図は、仮想ソケットを使用する本発明の一実施例による、クライアント 側インタセプト・モジュールとサーバ側インタセプト・モジュールを示すブロッ ク図である。 第１３図（集合的に第１３図を形成する第１３Ａ図および第１３Ｂ図から構成 される）は、仮想ソケットを使用する本発明の一実施例による、クライアント側 インタセプト・モジュールまたはサーバ側インタセプト・モジュールのソケット ・マネージャによって行われる操作を図示する流れ図である。 第１４図は、仮想ソケットを使用する本発明の一実施例において、クライアン ト側インタセプト機能によって行われる操作を図示する流れ図である。 第１５図は、仮想ソケットを使用する本発明の一実施例において、サーバ側イ ンタセプト機能によって行われる操作を図示する流れ図である。 第１６−１図は、仮想ソケットを使用する本発明の一実施例による、仮想作成 操作を図示する流れ図である。 第１６−２図は、仮想ソケットを使用する本発明の一実施例による仮想送信操 作を図示する流れ図である。 第１６−３図は、仮想ソケットを使用する本発明の一実施例による仮想受信操 作を図示する流れ図である。 第１６−４図は、仮想ソケットを使用する本発明の一実施 例による仮想選択操作を図示する流れ図である。 第１７−１図は、仮想ソケットを使用する本発明の一実施例による仮想フラッ シュ操作を図示する流れ図である。 第１７−２図は、仮想ソケットを使用する本発明の一実施例による仮想クロー ズ操作を図示する流れ図である。 詳細な説明 以下に、本発明の好ましい実施例が図示されている添付図面を参照しながら本 発明について詳述する。しかし、本発明は多くの異なる態様で実施することがで き、本明細書に記載の実施例に限定されるものと解釈してはならない。これらの 実施例は、本開示を綿密かつ十全なものとし、本発明の範囲を当業者に完全に伝 えるために示すものである。全体を通じて同様の番号は同様の要素を指す。 第３図ないし第１０図と第１３図ないし第１７−２図は、本発明による方法お よびシステムを示すフローチャートである。フローチャートの各ブロックと、フ ローチャートのブロックの組合せは、コンピュータ・プログラム命令によって実 施することができることがわかるであろう。これらのコンピュータ・プログラム 命令は、コンピュータまたはその他のプログラム式装置にロードし、それによっ てコンピュータまたはその他のプログラム式装置上で実行される命令がフローチ ャートの１つまたは複数のブロックに指定されている機能を実施する手段を生じ させるように機械を作り出すことができ る。これらのコンピュータ・プログラム命令を、コンピュータまたはその他のプ ログラム式装置に対して特定の方式で機能するように指示することができるコン ピュータ可読メモリに格納し、それによってコンピュータ可読メモリに格納され た命令がフローチャートの１つまたは複数のブロックに指定されている機能を実 施する命令手段を含む製品を作り出すようにすることができる。また、コンピュ ータ・プログラム命令をコンピュータまたはその他のプログラム式装置にロード して、コンピュータまたはその他のプログラム式装置上で一連の操作ステップが 行われるようにし、コンピュータまたはその他のプログラム式装置上で実行され る命令がフローチャートの１つまたは複数のブロックに指定されている機能を実 施するステップを提供するようにコンピュータ実施プロセスを作り出すこともで きる。 したがって、フローチャートのブロックは、指定された機能を実行する手段の 組合せと、指定された機能を実行するステップの組合せとに対応する。また、フ ローチャートの各ブロックと、フローチャートのブロックの組合せは、指定され た機能またはステップを実行する特定用途向けハードウェア・ベースのコンピュ ータ・システムによって、または特定用途向けハードウェアとコンピュータ命令 の組合せによって実施することができることがわかるであろう。 第２図に、本発明の一実施例を示す。第２図に示すように、ウェブ・ブラウザ １０はクライアント側インタセプト・モジ ュール３０と通信する。ウェブ・サーバ２０はサーバ側インタセプト・モジュー ル４０と通信する。次にクライアント側インタセプト・モジュール３０が通信リ ンク３５を介してサーバ側インタセプト・モジュール４０と通信する。ウェブ・ ブラウザ１０とクライアント側インタセプト・モジュール３０は、第１のコンピ ュータ５に組み込むことができる。サーバ側インタセプト・モジュール４０とウ ェブ・サーバ２０は第２のコンピュータ６に組み込むことができる。第１のコン ピュータ５と第２のコンピュータ６は外部通信リンク３５を介して通信する。 ウェブ・ブラウザ１０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）とハ イパーテキスト・マークアップ言語（ＨＴＭＬ）を使用して、やはりＨＴＴＰと ＨＴＭＬを使用するインターネット・ウェブ・サーバ２０と通信するインターネ ット・ウェブ・ブラウザであることが好ましい。動作中、ウェブ・ブラウザ１０ はＨＴＴＰデータ・ストリームを出力し、それがクライアント側インタセプト・ モジュール３０によってインタセプトされる。クライアント側インタセプト・モ ジュール３０によるＨＴＴＰデータ・ストリームのインタセプトは、クライアン ト側インタセプト・モジュール３０が１２７．０．０．１のようなネットワーク 番号１２７を有するＩＰアドレスにあるＴＣＰ／ＩＰループバック機構を使用し て行うことができる。次に、クライアント側インタセプト・モジュール３０はＨ ＴＴＰデータ・ストリームをクライアント ／サーバ固有プロトコルに変換または変形し、そのクライアント／サーバ固有デ ータ・ストリームを外部通信リンク３５に送る。サーバ側インタセプト・モジュ ール４０はこのクライアント／サーバ固有データ・ストリームを受け取り、ウェ ブ・ブラウザ発信通信に対応する元のＨＴＴＰデータ・ストリームを再構築する 。この再構築されたＨＴＴＰデータ・ストリームは次にウェブ・サーバ２０に転 送される。ウェブ・サーバ２０はインターネット・ウェブ・サーバの通常の方式 でＨＴＴＰデータ・ストリームに応答する。当業者ならわかるように、ウェブ・ サーバ２０は複数のブラウザがインターネットに接続することができるようにす るプロキシとすることもできる。 たとえば特定のＵＲＬホーム・ページを求めるブラウザ要求に応答してウェブ ・サーバ２０がウェブ・ブラウザ１０に送る情報を受け取ると、ウェブ・サーバ ２０はウェブ・ブラウザ１０に送る通信に対応するＨＴＴＰデータ・ストリーム を出力する。このウェブ・サーバ発信通信はサーバ側インタセプト・モジュール ４０によってインタセプトされ、クライアント／サーバ固有データ・ストリーム に変換される。次に、ウェブ・サーバ発信通信に対応するクライアント／サーバ 固有データ・ストリームは外部通信リンク３５で第２のコンピュータから第１の コンピュータに送られる。このクライアント／サーバ固有データ・ストリームを クライアント側インタセプト・モジュール３０が受け取り、ウェブ・サーバ発信 通 信に対応するＨＴＴＰデータ・ストリームが再構築され、ウェブ・ブラウザ１０ に供給される。 本発明の特定の実施例では、外部通信リンク３５は無線通信リンクである。そ の場合、ユーザにとって受容可能なシステム・パフォーマンスを得るために、外 部通信リンク３５を介する通信量を、通信リンク３５を介して伝送しなければな らない通信の頻度と情報量の両方について減らすことが望ましい。したがって、 本発明はキャッシング技法と、差分計算技法と、プロトコル縮小技法とを使用し て、外部通信リンク３５を介する必要通信量を最小限にする。これらの技法は、 ＨＴＴＰのステートレスまたは確率論的プロトコルを、クライアントおよびサー バに固有の情報を使用するクライアント／サーバ固有プロトコルに変換して通信 の量と頻度を減らすことによって実現される。 本発明について、単一のウェブ・ブラウザ・アプリケーションと単一のウェブ ・サーバ・アプリケーションに関して説明するが、当業者ならわかるように、本 発明の利便および利点は、単一のウェブ・サーバに関連づけられた複数のウェブ ・ブラウザを使用した場合にも得ることができる。したがって、本発明の方法、 装置、およびプログラム製品は、各ブラウザがクライアント側インタセプト・モ ジュールと通信する複数のブラウザと共に使用することもでき、その場合それら のクライアント側インタセプト・モジュールはウェブ・サーバまたはウェブ・プ ロキシのサーバ側インタセプト・モジュ ールと通信することになる。 本発明の一実施例では、クライアント側インタセプト・モジュール３０とサー バ側インタセプト・モジュール４０の朗報がキャッシュ格納機能を有する。第１ のコンピュータにあるクライアント・キャッシュには、ウェブ・ブラウザ発信通 信に応答してウェブ・ブラウザが受け取るＨＴＴＰデータ・ストリームが格納さ れる。第２のコンピュータにあるサーバ・キャッシュには、ブラウザ発信通信に 応答してウェブ・サーバから受け取るＨＴＴＰデータ・ストリームが格納される 。 当業者ならわかるように、第１のコンピュータまたは第２のコンピュータにあ るキャッシュは、コンピュータの特定のハードウェア構成に基づく任意の容量と することができる。これらのキャッシュには、各通信について、通信のＵＲＬ、 巡回冗長検査（ＣＲＣ）などの通信内容に基づく固有識別子、キャッシュ項目の 作成またはリフレッシュが行われた時刻を示すデータ格納時刻（ＳＤＴ）、およ び通信のデータを含む情報が格納される。したがって、キャッシュに格納されて いる各通信についてキャッシュ項目のディレクトリを作成することができる。さ らに、所与のハードウェア構成で使用可能な資源は限られているため、第１のコ ンピュータおよび第２のコンピュータにあるキャッシュを維持するために当業者 に周知の任意の数のキャッシング技法を使用することができる。したがって、た とえば、新しい項目の追加によってユーザ定義キャッシュサイズを超える場合、 キャッシュは最も古いデ ィレクトリ項目を無効化し、無効化された項目の代わりに新しい項目を追加する ことができる。さらに、ウェブ・ブラウザ・アプリケーションまたはウェブ・サ ーバ・アプリケーションの複数のインスタンスにわたって、あるいは第１または 第２のコンピュータの電源投入サイクルについてさえもキャッシュ項目を維持し て持続キャッシュを作成することができる。 以下に、クライアント側インタセプタ・モジュール３０とサーバ側インタセプ ト・モジュール４０の動作を示すフローチャートである第３図ないし第６図を参 照しながら本発明の一態様によるキャッシング構造について説明する。 具体的に第３図を参照すると、ブロック１００はクライアント側インタセプト ・モジュール３０がウェブ・ブラウザ１０から要求を受け取ったことを示してい る。この要求は、ＨＴＴＰデータ・ストリームの書式をとることができる。ブロ ック１０５に示すように、クライアント側インタセプト・モジュール３０は着信 した要求のユニフォーム・リソース・ロケータ（ＵＲＬ）を検査する。クライア ント側インタセプト・モジュール３０はＵＲＬから、ウェブ・ブラウザ発信要求 に対応する情報が前に第１のコンピュータにある第１のクライアント・キャッシ ュに格納されているかどうかを判断する。 ＵＲＬに対応する情報が前にクライアント・キャッシュに格納されていなかっ た場合、ブロック１０６に示す操作がクライアント側インタセプト・モジュール によって行われる。 クライアント側インタセプト・モジュール３０は外部通信リンク３５でサーバ側 インタセプト・モジュール４０に要求を送る。 しかし、ブロック１０５に示すようにウェブ・ブラウザ発信通信に問い合わせ たときに、ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目 が存在する場合、最も単純な実施例では、その情報がＨＴＴＰデータ・ストリー ムとしてウェブ・ブラウザに供給される。しかし、第３図に示すように、本発明 の好ましい実施例は、ウェブ・ブラウザ発信通信に対応するキャッシュ項目に対 して本明細書でコヒーレンシ間隔検査と呼ぶ操作を行う。この操作は第３図のブ ロック１１０に示されている。 クライアント側インタセプト・モジュールのコヒーレンシ間隔はユーザ定義と することができ、キャッシュ項目が陳腐化し、存在はしていてもウェブ・サーバ に対してウェブ・ブラウザ発信通信に対応する情報を要求することによって最新 化しなければならなくなるまでのキャッシュ項目が存在することができる時間の 長さである。ブロック１１０に示すコヒーレンシ間隔検査は、現在日時をウェブ ・ブラウザ発信通信に対応するキャッシュ項目のＳＤＴとユーザによって指定さ れたコヒーレンシ間隔との和と比較することによって行うことができる。現在日 時がこの和より大きい場合、ウェブ・ブラウザ発信通信に対応するキャッシュ内 に格納されている情報は陳腐化しており、ブロック１１０の「Ｎｏ」に分岐する 。 しかし、現在日時がＳＤＴにユーザ定義コヒーレンシ間隔を足した和よりも小さ い場合は、ブロック１１０で「Ｙｅｓ」に分岐し、ブロック１１１に示すように 、そのキャッシュ項目がＨＴＴＰデータ・ストリームとしてブラウザに供給され る。したがって、第３図のブロック１００でクライアント側インタセプト・モジ ュール３０が受け取ったブラウザ発信通信が完了する。 ブロック１１０に示すコヒーレンシ間隔検査によって、第１のコンピュータに あるキャッシュ項目が陳腐化していると判断された場合、サーバ側インタセプト ・モジュール４０に対して要求を行い、第２のコンピュータにあるキャッシュ項 目のコヒーレンシを検査する。この操作は第３図のブロック１１２に示されてい る。これは、外部通信リンク３５を介してサーバ側インタセプト・モジュール４ ０に、特定のクライアント側インタセプト・モジュール３０のコヒーレンシ間隔 と、ウェブ・ブラウザ１０によって発信されたＨＴＴＰ要求と、ウェブ・ブラウ ザ発信通信のＵＲＬに対応するクライアント・キャッシュの内容を示す固有の標 識を供給することによって行われる。好ましい実施例では、この固有の標識はキ ャッシュ項目の巡回冗長検査（ＣＲＣ）である。 次に第５図を参照すると、外部通信リンク３５を介してクライアント側インタ セプト・モジュール３０から受け取った情報に応答したサーバ側インタセプト・ モジュール操作が示されている。サーバ側インタセプト・モジュール４０がクラ イアント側インタセプト・モジュールから要求を受け取ると、サーバ側インタセ プト・モジュール４０は所定のクライアント・コヒーレンシ時間間隔と、クライ アント・キャッシュ項目のＣＲＣ値と、ウェブ・ブラウザによって発信されたＨ ＴＴＰ要求を受け取る。この情報の受信は、第５図のブロック１２０に示されて いる。 クライアント側インタセプト・モジュール３０から情報を受け取った後、サー バ側インタセプト・モジュール４０は第２のコンピュータにあるそのサーバ・キ ャッシュを検査して、ウェブ・ブラウザによって発信されたＨＴＴＰ要求のＵＲ Ｌに対応するサーバ・キャッシュ項目が存在するかどうかを判断する。ブロック １２５に示すようにウェブ・ブラウザ発信通信に問い合わせた後、サーバ側イン タセプト・モジュール４０が、ウェブ・ブラウザ発信通信によって要求された情 報に対応するキャッシュ項目が存在すると判断した場合、ブロック１２５で「Ｙ ｅｓ」分岐をとる。次に、サーバ側インタセプト・モジュール４０はＳＳＩモジ ュール４０の現在日時を、ウェブ・ブラウザ発信通信によって要求された情報に 対応するサーバ・キャッシュ項目のＳＤＴとクライアント側インタセプト・モジ ュールから受け取った所定のクライアント・コヒーレンシ時間間隔との和と比較 する。 現在日時がサーバ・キャッシュ項目のＳＤＴとコヒーレンシ間隔との和より小 さい場合、第５図のブロック１３０の「Ｙｅｓ」経路をとる。次にサーバ側イン タセプト・モジュ ール４０はサーバ・キャッシュ項目のＣＲＣとクライアント・キャッシュのＣＲ Ｃとを比較して、その２つのキャッシュ項目が同じかどうかを判断する。２つの キャッシュ項目が同じ場合、ブロック１３５の「Ｙｅｓ」分岐をとり、ブロック １３６に示すように、「コヒーレント」応答がクライアント側インタセプト・モ ジュール３０に送られる。 ブロック１３５の条件で、ＣＲＣが等しくないと判断された場合、クライアン ト・キャッシュに入っている情報とサーバ・キャッシュに入っている情報は同じ でなく、ブロック１３７に示すようにサーバ側インタセプト・モジュールは外部 通信リンクを介して第１のコンピュータにサーバ・キャッシュ項目を送る。サー バ・キャッシュ項目をクライアント側インタセプト・モジュール３０に送信する 際に、サーバ側インタセプト・モジュールはその項目を、サーバ・キャッシュ項 目のＣＲＣと、サーバ・キャッシュ項目データと、サーバ・キャッシュ項目のエ ージとを含むクライアント固有通信プロトコルに変換する。サーバ・キャッシュ 項目のエージは、現行日時からキャッシュ項目のＳＤＴを引くことによって計算 する。 第５図に関して最後に、ＳＤＴに所定のクライアント・コヒーレンシ時間間隔 を足した和が現在日時よりも小さいか、またはウェブ・ブラウザ発信通信のＵＲ Ｌに対応する項目がない場合、それぞれブロック１３０の「Ｎｏ」経路またはブ ロック１２５の「Ｎｏ」経路がとられる。したがって、ブロ ック１２６の操作が行われ、サーバ側インタセプト・モジュール４０がサーバに ウェブ・ブラウザ発信通信をＨＴＴＰデータ・ストリームとして送ることになる 。サーバ側インタセプト・モジュール４０がウェブ・ブラウザ発信通信をサーバ にＨＴＴＰデータ・ストリームとして送らなければならない場合、サーバ側イン タセプト・モジュール４０は第６図の操作を実行する。 第６図のブロック１４０に示すように、ウェブ・ブラウザ発信通信に応答して 、サーバ側インタセプト・モジュールがウェブ・サーバ２０からＨＴＴＰデータ ・ストリームを受け取る。ＨＴＴＰデータ・ストリームを受け取ると、サーバ側 インタセプト・モジュール４０はＨＴＴＰデータ・ストリームのＣＲＣを計算し 、ＨＴＴＰデータ・ストリームを一時的に格納する。次に、ブロック１４５に示 すように、サーバ側インタセプト・モジュールはＨＴＴＰデータ・ストリームに 問い合わせて、ＨＴＴＰデータ・ストリームのＵＲＬに対応するサーバ・キャッ シュ項目が存在するかどうかを判断する。そのような項目が存在しない場合、ブ ロック１４５の「Ｙｅｓ」経路が実行される。次にサーバ側インタセプト・モジ ュール４０は、ブロック１５０に示すように、ウェブ・サーバ２０から受け取っ たＨＴＴＰデータ・ストリームの最も最近に計算されたＣＲＣを、ウェブ・サー バ発信応答通信のＵＲＬに対応するサーバ・キャッシュ項目のＣＲＣと比較する 。ＣＲＣが同じ場合、ブロック１５０の「Ｙｅｓ」分岐が行わ れる。サーバ側インタセプト・モジュール４０はブロック１５１に示すようにサ ーバ・キャッシュ項目のＳＤＴ項目を更新し、ブロック１５２に示すようにウェ ブ・サーバ２０によって受信されたＨＴＴＰデータ・ストリームを一時格納域か ら除去する。 ＣＲＣ比較の結果によって、サーバ・キャッシュ項目がウェブ・サーバ２０か ら受け取ったＨＴＴＰデータ・ストリームと異なることが示された場合、ブロッ ク１５０の「Ｎｏ」経路が行われる。サーバ側インタセプト・モジュール４０は ブロック１５３に示すようにサーバ・キャッシュから既存のデータを除去し、次 にブロック１５４に示すようにより新しい方の情報によってサーバ・キャッシュ を更新する。ブロック１５４に示すように、この更新にはサーバ・キャッシュに ウェブ・サーバ通信のＣＲＣを格納するステップと、キャッシュ項目の一部とし て現在日時をキャッシュ項目のＳＤＴとして格納するステップと、ＨＴＴＰデー タ・ストリームを格納するステップとが含まれる。サーバ・キャッシュ項目を更 新するかどうか、またはサーバ・キャッシュ項目がウェブ・サーバ２０から受け 取ったＨＴＴＰデータ・ストリームと同じであることが判明したかどうかを問わ ず、いずれの場合もサーバ側インタセプト・モジュールは次にサーバ・キャッシ ュ項目がウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目と 同じかどうかを判断する。この操作をブロック１５５に示す。 サーバ側インタセプト・モジュール４０が、ウェブ・サーバ２０から受け取っ た応答に対応するキャッシュ項目が存在しないと判断した場合、ブロック１４５ の「Ｎｏ」経路がとられる。ブロック１４６に示すように、ウェブ・サーバから の応答のＵＲＬを格納し、ウェブ・サーバからの応答のＣＲＣを格納し、ＨＴＴ Ｐデータ・ストリームを格納し、ＳＤＴとして現在日時を格納することによって 、サーバ・キャッシュ項目が作成される。ウェブ・ブラウザ発信通信に対応する キャッシュ項目を作成した後、サーバ側インタセプト・モジュール４０は次に、 ブロック１５５に示すように、再度、このサーバ・キャッシュ項目のＣＲＣを対 応するクライアント・キャッシュのＣＲＣと比較する。 サーバ・キャッシュ項目とクライアント・キャッシュ項目との比較の結果によ って、キャッシュ項目が同じであることがわかった場合、ブロック１５５の「Ｙ ｅｓ」分岐がとられ、ブロック１５６の操作が行われる。ブロック１５６に示す ように、サーバ側インタセプト・モジュール４０がクライアント側インタセプト ・モジュール３０に応答を送る。サーバ側インタセプト・モジュール４０は、ク ライアント側インタセプト・モジュールにコヒーレント応答を送り、ゼロのエー ジを送ることによって、サーバ要求キャッシュ項目をクライアント／サーバ固有 データ・ストリームに変形する。 サーバ側インタセプト・モジュール４０が、クライアント・キャッシュ項目が ウェブ・ブラウザ発信通信に対応するサ ーバ・キャッシュ項目と同じではないと判断した場合、ブロック１５５の「Ｎｏ 」分岐がとられ、ブロック１５７の操作が行われる。ブロック１５７に示すよう に、サーバ側インタセプト・モジュール４０は、サーバ・キャッシュ項目をクラ イアント／サーバ固有データ・ストリームに変換または変形する。このデータ・ ストリームには、サーバ・キャッシュ項目のＣＲＣと、サーバ・キャッシュ項目 ＨＴＴＰデータ・ストリームと、キャッシュ項目のゼロに設定されたエージとが 含まれる。このクライアント／サーバ固有通信は次に外部通信リンク３５を介し てクライアント側インタセプト・モジュール３０に送信される。 サーバ側インタセプト・モジュールから通信を受け取ったときのクライアント 側インタセプト・モジュール３０の機能について、第４図を参照しながら以下に 説明する。ブロック１６０に示すように、クライアント側インタセプト・モジュ ール３０は外部通信リンク３５を介して送信されたクライアント／サーバ固有デ ータ・ストリームを受信または入手する。クライアント側インタセプト・モジュ ールは次に、ブロック１６５に示すように、サーバ側インタセプト・モジュール ４０からどのようなタイプの応答を受け取ったかを判断する。サーバ側インタセ プト・モジュール４０が、クライアントがクライアント・キャッシュ項目がコヒ ーレントであること、すなわちサーバ・キャッシュ項目とクライアント・キャッ シュ項目が同じであることを示している場合、ブロック１６６ に示す操作が行われる。ブロック１６６に示すように、クライアント側インタセ プト・モジュール３０は、現在日時とサーバ側インタセプト・モジュール４０か ら受け取ったエージとの差を使用してウェブ・ブラウザ発信通信に対応するクラ イアント・キャッシュ項目のＳＤＴを更新する。したがって、本発明は、第１の コンピュータ５と第２のコンピュータ６の２つのクロックの同期をとらずに、第 １のコンピュータのキャッシュ項目のコヒーレンシ時間を更新して第２のコンピ ュータの新しい方のデータを反映させたことになる。ウェブ・ブラウザ発信通信 に対応するクライアント・キャッシュ項目のＳＤＴを更新した後、クライアント 側インタセプト・モジュール３０はクライアント・キャッシュ項目をウェブ・ブ ラウザ１０にＨＴＴＰデータ・ストリームとして転送する。この操作をブロック １７４に示す。 しかし、クライアント側インタセプト・モジュール３０が応答のタイプがデー タまたはデータ・ストリーム応答であると判断した場合は、ブロック１６５から 「ストリーム」経路をとり、ブロック１６７の操作が行われる。クライアント側 インタセプト・モジュール３０はＨＴＴＰデータ・ストリームを受け取り、その データを一時的に格納する。次に、第４図のブロック１７０に示すように、クラ イアント側インタセプト・モジュール３０は、ウェブ・ブラウザ発信通信に対応 するキャッシュ項目が存在するかどうかを判断する。キャッシュ項目が存在する 場合、ブロック１７０の「Ｙｅｓ」経路 をとって、ブロック１７１に示すように、既存のキャッシュ項目がフラッシュさ れる。クライアント側インタセプト・モジュールは次に、サーバ側インタセプト ・モジュール４０から受け取ったＨＴＴＰデータ・ストリームのＣＲＣを格納し 、現在日時とサーバ側インタセプト・モジュール４０から受け取ったエージとの 差をＳＤＴとして格納し、ＨＴＴＰデータ・ストリームを格納することによって 、ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目を更新す る。この操作をブロック１７２に示す。 ウェブ・ブラウザ発信通信に対応するキャッシュ項目が存在しない場合、ブロ ック１７０の「Ｎｏ」経路が取られる。ブロック１７３に示す操作を行うことに よってクライアント・キャッシュ項目が作成される。ブロック１７３に示すよう に、クライアント側インタセプト・モジュール３０は、サーバ側インタセプト・ モジュール４０から受け取ったＨＴＴＰデータ・ストリームのＵＲＬを格納し、 サーバ側インタセプト・モジュール４０から受け取ったＨＴＴＰデータ・ストリ ームのＣＲＣを格納し、ＨＴＴＰデータ・ストリームを格納することによって、 クライアント・キャッシュ項目を作成する。また、クライアント側インタセプト ・モジュール３０は、サーバ側インタセプト・モジュール４０から外部通信リン ク３５を介して受け取ったエージＳＤＴを現在日時から引くことによって、ＳＤ Ｔを更新または格納する。 しかし、ブロック１６６、１７２、１７３のいずれの操作 によってクライアント・キャッシュ項目が作成されるかを問わず、クライアント 側インタセプト・モジュールはクライアント・キャッシュ項目をＨＴＴＰデータ ・ストリームとしてウェブ・ブラウザ１０に転送または供給する。これらの操作 は第４図のブロック１７４に示されている。 当業者ならわかるように、クライアント・キャッシュとサーバ・キャッシュは 、メモリによって、またはハード・ディスク、読書きＣＤ−ＲＯＭ、光ディスク 、その他の格納技法などの大容量格納装置によって実装することができる。さら に、当業者ならわかるように、クライアント側インタセプト・モジュールとサー バ側インタセプト・モジュールは、ソフトウェア、ハードウェア、またはその組 合せによって実装することができる。 特定の第１または第２のコンピュータにあるキャッシュについて言及したが、 当業者ならわかるように、本発明の利点は、キャッシュが第１のコンピュータに ではなく、単に外部通信リンクの第１のコンピュータと同じ側にある場合でも得 られる。したがって、ハードウェア・キャッシュをクライアント・キャッシュと して機能する第１のコンピュータの外部に実装し、高速通信によって第１のコン ピュータに接続することもでき、しかもその場合でも、キャッシュが外部通信リ ンクの第１のコンピュータと同じ側にある限り、本発明の利点が得られる。 本発明の他の実施例では、サーバ側インタセプト・モジュ ール４０は、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームの コピーを維持せず、単にその通信のディレクトリ項目を維持するに過ぎない。こ のディレクトリ項目には、通信のＵＲＬと、ＨＴＴＰデータ・ストリームのため に計算されたＣＲＣと、ＨＴＴＰデータ・ストリームをウェブ・サーバから受け 取った時刻と、その通信のＳＤＴとが含まれ、このＳＤＴはＣＲＣを計算した時 刻に設定することができる。このような場合、クライアント側インタセプト・モ ジュール３０はサーバ側インタセプト・モジュール４０に対して、サーバ側イン タセプト・モジュールがＣＲＣとＳＤＴを維持していたＵＲＬに対応する通信を 求める要求を送り、、次にサーバ側インタセプト・モジュール３０はクライアン ト側インタセプト・モジュール３０から受け取ったＣＲＣを検査して、それが指 定されたＵＲＬの最新のＨＴＴＰデータ・ストリームに対応しているかどうかを 判断する。一致している場合、クライアント側インタセプト・モジュールにコヒ ーレント応答が送られる。一致していない場合、サーバ側インタセプト・モジュ ールは、クライアント側インタセプト・モジュールから受け取ったＨＴＴＰデー タ・ストリームをウェブ・サーバ２０に送り、ウェブ・サーバ２０から受け取っ た応答をクライアント側インタセプト・モジュール３０に返す。 第７図、第８図、第９図、および第１０図に、本発明の他の態様においてクラ イアント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール ４０によって行われ る操作を示す。この態様は、差分計算を使用して、外部通信リンク３５を介して 伝送されるデータを削減する。第７図を参照すると、ブロック２００にクライア ント側インタセプト・モジュール３０によるウェブ・ブラウザ１０からのＨＴＴ Ｐ要求の受信が示されている。ブロック２０５に示すように、クライアント側イ ンタセプト・モジュール３０はウェブ・ブラウザ１０からのインタセプトしたＨ ＴＴＰ要求に問い合わせて、その要求が共通ゲートウェイ・インタフェース（Ｃ ＧＩ）に送るものかどうかを判断する。要求が共通ゲート・インタフェースに送 るものでない場合、クライアント側インタセプト・モジュール３０は、第３図な いし第６図に示し、第７図のブロック２０６に図示するように、その要求をサー バ側インタセプト・モジュールに渡す。 しかし、ウェブ・ブラウザ発信通信がＣＧＩ要求に対応する場合、ブロック２ ０５の「Ｙｅｓ」経路がとられる。ブロック２１０に示すように、クライアント ／サーバ・インタセプト・モジュール３０は、対応するＣＧＩ要求に応答して前 にウェブ・ブラウザに供給されていたＨＴＴＰデータ・ストリームに対応するク ライアント・ベース・キャッシュ項目が存在するかどうかを判断する。このＣＧ Ｉ要求の問い合わせは、ウェブ・ブラウザ発信通信のＵＲＬをクライアント・ベ ース・キャッシュに格納されているＵＲＬと比較することによって行うことがで きる。 クライアント・ベース・キャッシュは、所与のＵＲＬにつ いてウェブ・ブラウザ１０に供給するクライアント側インタセプト・モジュール ３０が受信した最初のＨＴＴＰデータ・ストリームを格納することによって初期 設定することができる。このベース・キャッシュ項目は、ウェブ・ブラウザ１０ の多くのインスタンスまたはセッションにわたって維持することができる。クラ イアント・ベース・キャッシュ項目は、第７図、第８図、第９図、および第１０ 図に示すように更新することができる。ウェブ・ブラウザ発信通信のＵＲＬに対 応するクライアント・ベース・キャッシュ項目が存在する場合、第７図のブロッ ク２１１に示すように、外部通信リンク３５を介してサーバ側インタセプト・モ ジュール４０に送るＣＲＣが、クライアント・ベース・キャッシュ項目のＣＲＣ に等しく設定される。クライアント・ベース・キャッシュ項目がない場合、第７ 図のブロック２１０から「Ｎｏ」経路をとり、外部通信リンク３５を介してサー バ側インタセプト・モジュール４０に送る要求のＣＲＣがナルにされる。この操 作は第７図のブロック２１２に示されている。 ブロック２１３に、ＣＧＩ要求を外部通信リンクを介してサーバ側インタセプ ト・モジュール４０に送る操作を示す。ブロック２１３に示すように、クライア ント側インタセプト・モジュール３０がＨＴＴＰ要求と要求ＣＲＣを送る。要求 ＣＲＣは、ＣＧＩ要求のＵＲＬのクライアント・ベース・キャッシュ項目が存在 しない場合にはナルに設定されており、クライアント・ベース・キャッシュ項目 が存在する場合には その項目のＣＲＣに設定されている。したがって、クライアント側インタセプト ・モジュールは、ＣＧＩ要求をクライアント／サーバ固有プロトコルに変換し、 そのクライアント／サーバ固有通信を外部通信リンクを介して送信して、サーバ 側インタセプト・モジュール４０が受信するようにしたことになる。 ＣＧＩ要求を受け取るときのサーバ側インタセプト・モジュールの動作を第９ 図に示す。サーバ側インタセプト・モジュール４０によるＣＧＩ要求の受信がブ ロック２２０に示されている。サーバ側インタセプト・モジュール４０はＣＧＩ 要求を受け取ると、ＣＲＣ値とＨＴＴＰ要求のコピーを保存する。ブロック２２ １に示すように、サーバ側インタセプト・モジュール４０はＨＴＴＰ要求をウェ ブ・サーバ２０に渡す。 第１０図のブロック２３０に示すように、サーバ側インタセプト・モジュール ４０がウェブ・ブラウザ発信通信またはＣＧＩ要求に対応するＨＴＴＰ要求に対 する応答を受け取るとき、サーバ側インタセプト・モジュール４０はこの応答を ＨＴＴＰデータ・ストリームとして受け取る。ブロック２３０に示すように、サ ーバ側インタセプト・モジュール４０は、ＨＴＴＰデータ・ストリームを保存し 、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームのＣＲＣ値を 計算する。また、サーバ側インタセプト・モジュール４０は、差分値をナルにし て差分データを初期設定する。次に、ブロ ック２３５に示すように、サーバ側インタセプト・モジュールは、ウェブ・サー バ発信通信として受け取った応答がＣＧＩ要求に対する応答であるかどうかを判 断する。答えが否定の場合、第１０図のブロック２３５から「Ｎｏ」経路をとり 、ブロック２３６の操作を実行して、ＨＴＴＰデータ・ストリームがクライアン ト側インタセプト・モジュールに送る。ブロック２３６に示すように、この操作 には第３図ないし第６図で説明したキャッシング操作が必要な場合がある。ブロ ック２３０で受け取った応答がＣＧＩに対する応答の場合、ブロック２３５の「 Ｙｅｓ」経路をとり、サーバ側インタセプト・モジュールは次に、ブロック２４ ０に示すように、ＣＧＩ応答のサーバ・ベース・キャッシュ項目が存在するかど うかを判断する。 サーバ側インタセプト・モジュール４０がＣＧＩ要求に対する応答を初めて受 け取ったとき、サーバ・ベース・キャッシュ項目を作成することができる。この 場合、ブロック２４０に示す条件の結果によって、ブロック２４０から「Ｎｏ」 経路がとられる。次に、サーバ側インタセプト・モジュール４０は、ＣＧＩのＵ ＲＬと、ＣＧＩ要求に対する応答のＨＴＴＰデータ・ストリームと、ＨＴＴＰデ ータ・ストリームのＣＲＣとを格納することによって、サーバ・ベース・キャッ シュ項目を作成する。この操作をブロック２４１に示す。第３図ないし第６図で 説明したコヒーレント・キャッシュとの互換性を持たせるために、サーバ・ベー ス・キャッシュ項目 にはＳＤＴも組み込むことができる。本明細書では、サーバＣＧＩベース書式と いう用語を使用して、ウェブ・ブラウザ１０から受け取ったＣＧＩ要求に対応す るサーバ・ベース・キャッシュ項目を指す。 ＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目がある場合、ブロック ２４０の「Ｙｅｓ」経路がとられる。サーバ側インタセプト・モジュールはサー バ・ベース・キャッシュ項目のＣＲＣを、ウェブ・サーバ２０から受け取った応 答のＣＲＣと比較する。これらの操作を第１０図のブロック２４５に示す。ＣＲ Ｃが同じ場合、サーバ側インタセプト・モジュールは、サーバ・ベース・キャッ シュ項目のＣＲＣがクライアント・ベース・キャッシュ項目のＣＲＣに対応する かどうかを判断する。この２つのＣＲＣ値が同じ場合、クライアント・ベース・ キャッシュ項目と、サーバ・ベース・キャッシュ項目と、ウェブ・サーバ２０か ら受け取った応答のすべてがＨＴＴＰデータ・ストリームに入れられる。サーバ ・ベース・キャッシュ項目とクライアント・ベース・キャッシュ項目との比較を ブロック２５０に示す。 ２つのベース・キャッシュ項目が同じ場合、サーバ側インタセプト・モジュー ルはベース・キャッシュ項目をクライアント側インタセプト・モジュール３０に 送る必要がなく、したがって、ブロック２５１に示すように、クライアント側イ ンタセプト・モジュール３０に送るＨＴＴＰデータ・ストリーム・データをナル にする。次に、ブロック２５２に示すよ うに、サーバ側インタセプト・モジュール４０は、ＣＧＩ要求に対応するサーバ ・ベース・キャッシュに格納されているＨＴＴＰデータ・ストリームのＣＲＣと 、ナルにしたＨＴＴＰデータ・ストリームと、ナルにした差分データとを送信し て、ＣＧＩ要求がクライアント・ベース・キャッシュ項目と同じであったことを 示すことによって、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリ ームをクライアント／サーバ固有通信プロトコルに変換する。 ブロック２４５に戻って、ＣＧＩ要求に対応するサーバ・ベース・キャッシュ 項目のＣＲＣが、ウェブ・ブラウザによって発信されたＣＧＩ要求に応答してウ ェブ・サーバから受け取った応答のＣＲＣと異なる場合、ブロック２４５から「 Ｎｏ」経路がとられる。次に、サーバ側インタセプト・モジュール４０はブロッ ク２４６に示す操作を行う。サーバ側インタセプト・モジュール４０は、インタ セプトしたＣＧＩ応答を、インタセプトしたＣＧＩに対応するサーバ・ベース・ キャッシュ項目すなわちサーバＣＧＩベース書式と比較する。このインタセプト したＣＧＩ応答とサーバＣＧＩベース書式との比較によって、インタセプトした ＣＧＩ応答とサーバＣＧＩベース書式との差分に対応するＣＧＩ差分データが得 られる。 差分計算は、ベース書式と修正済み書式との間の差分を求める当業者に周知の 任意の方法で行うことができる。本発明で使用するのに適した差分計算の一方法 は、コピーターズ （Coppieters）による″Cross-Platform Binary Diff″（Dr．Dobb's Journal １９９５年５月号３２〜３６ページ）に記載されており、その開示は参照により 、その全部が記載されているかのように本明細書に組み込まれる。差分データを 求める際に使用することができるその他の方法には、″IBM Technical Disclosu re Bulletin（Vol.22，No.8A、１９８０年１月）に記載されている方法が含まれ 、これも参照によりその全部が記載されているかのように本明細書に組み込まれ る。次に、ブロック２４７に示すように、サーバ側インタセプト・モジュール４ ０はサーバＣＧＩベース書式が更新を必要とするかどうかを判断する。この判断 は、インタセプトされたＣＧＩ応答とサーバＣＧＩベース書式との平均差分デー タが所定のしきい値を超えているかどうかを判断することによって行うことがで きる。ＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目を更新する必要が あるかどうかを判断する他の方法には、第３図ないし第６図で説明したような時 間コヒーレンシ方式や、ベース変更を行って新しいベース・キャッシュ項目を作 成すればシステム・パフォーマンスが向上するほど差分データが増加したかどう かを判断する当業者に周知のその他の方法が含まれる。 サーバのベース変更計算が不要な場合、ブロック２４７から「Ｎｏ」経路がと られ、サーバ側インタセプト・モジュール４０はブロック２５０の操作を行って 、クライアント・ベース・キャッシュ項目のＣＲＣがサーバ・ベース・キャッシ ュ項目のＣＲＣと同じかどうか、またはサーバＣＧＩベース書式が、ウェブ・ブ ラウザ発信通信のその特定のＣＧＩ要求に対応するサーバとクライアントのベー ス・キャッシュ項目であるクライアントＣＧＩベース書式と同じかどうかを判断 する。ベース書式が同じ場合、クライアントはベース変更を行う必要がなく、ブ ロック２５１に示すようにＨＴＴＰデータ・ストリーム情報がナルにされる。次 に、サーバ側インタセプト・モジュール４０は、ＣＧＩ要求に対応するサーバ・ ベース・キャッシュ項目のＣＲＣ（すなわちサーバＣＧＩベース書式のＣＲＣ） を送り、ベース・データに対応するナルにしたＨＴＴＰデータ・ストリームを送 り、ブロック２４６で求めた差分データを送ることによって、クライアント側イ ンタセプト・モジュール３０に差分応答を送る。これらの操作は第１０図のブロ ック２５２として示されている。 サーバ側インタセプト・モジュール４０が、クライアントＣＧＩベース書式と サーバＣＧＩベース書式のＣＲＳが同じでないと判断した場合、クライアントの ベース変更計算を行う必要がある。クライアントのベース変更操作は、クライア ント側インタセプト・モジュール３０にサーバＣＧＩベース書式を送るステップ を含む。この操作を行うために、サーバ側インタセプト・モジュールはクライア ント側インタセプト・モジュール３０に送るＨＴＴＰデータ・ストリーム・デー タを、サーバＣＧＩベース書式と等しく設定する。この操作をブロック２５３に 示す。次に、サーバ側インタセプト・モ ジュール４０は、ブロック２５２に示すように、サーバＣＧＩベース書式のＣＲ Ｃと、サーバＣＧＩベース書式に対応するＨＴＴＰデータ・ストリーム・データ を送信し、ＣＧＩベース書式とウェブ・サーバから受け取った応答との差分デー タを送信することによって、ウェブ・サーバから受け取ったＨＴＴＰデータ・ス トリームをクライアント／サーバ固有プロトコルに変換する。次にこの情報を外 部通信リンク３５を介してクライアント側インタセプト・モジュール３０に送る 。 ブロック２４７に戻って、サーバのベース変更が必要な場合、ブロック２４７ から「Ｙｅｓ」経路がとられる。ブロック２４８に示すように、サーバ側インタ セプト・モジュールは、ウェブ・サーバから受け取ったＨＴＴＰデータ・ストリ ームを使用してブラウザ発信通信に対応するサーバ・ベース・キャッシュを更新 する。応答のＣＲＣも更新され、ＣＧＩ差分データがナルにされる。次に、サー バ側インタセプト・モジュールは、ブロック２５０に示すように新しいサーバ側 キャッシュ項目のＣＲＣを比較し、前述のようにこの転送を完了する。 サーバ側インタセプト・モジュール４０から応答を受け取ったときのクライア ント側インタセプト・モジュールの操作を第８図に示す。クライアント側インタ セプト・モジュール３０によるサーバ側インタセプト・モジュール４０からの応 答の受信は、ブロック２６０に示されている。ブロック２６５に示すように、ク ライアント側インタセプト・モジュール ３０は、応答がＣＧＩ要求に対する応答かどうかを判断する。応答がＣＧＩ要求 に対する応答ではない場合、クライアント側インタセプト・モジュールはブロッ ク２６７の操作を行う。この操作には、第３図ないし第６図に示すキャッシュ操 作を組み込むことができる。しかし、応答がＣＧＩ要求に対する応答の場合、ブ ロック２６５から「Ｙｅｓ」経路がとられる。クライアント側インタセプト・モ ジュール３０は、外部通信リンクを介して送信されたクライアント／サーバ固有 データ・ストリームから入手した、ＨＴＴＰデータ・ストリーム・データと、差 分データと、ＣＲＣとを保管する。これらの操作は第８図のブロック２６６に示 されている。 次に、クライアント側インタセプト・モジュール３０は、ＣＧＩベース書式を 含むインタセプトされたＣＧＩ要求に対応するクライアント・ベース・キャッシ ュ項目が存在するかどうかを判断する。この問い合わせはブロック２７０に示さ れており、ＨＴＴＰ要求またはＨＴＴＰ応答のＵＲＬを調べることによって行う ことができる。クライアントＣＧＩベース書式が存在する場合、ブロック２７０ から「Ｙｅｓ」経路がとられる。次に、ブロック２７５に示すように、クライア ント側インタセプト・モジュール３０は外部通信リンクを介して受け取ったＣＲ Ｃを、クライアントＣＧＩベース書式のＣＲＣと比較する。ＣＲＣが異なる場合 、ブロック２７５から「Ｎｏ」経路がとられ、クライアントは、ウェブ・ブラウ ザ発信通信にのＣＧＩ要求のＵＲＬに対応するクライアント ・ベース・キャッシュ項目を、外部通信リンク３５を介してサーバ側インタセプ ト・モジュール４０から受け取ったＨＴＴＰデータ・ストリーム・データに置き 換えてＣＧＩベース書式を更新することによって、ベース変更を行う。クライア ント・ベース・キャッシュ項目も、ＨＴＴＰデータ・ストリームのＣＲＣを基準 にして更新される。これらの操作は第８図のブロック２７６に示されている。 外部通信リンク３５を介して受け取ったＣＲＣがＧＧＩベース書式と同じ場合 、サーバ側インタセプタ・モジュール・サーバＣＧＩベース書式は、クライアン ト側インタセプト・モジュール・クライアントＣＧＩベース書式と同じであり、 ブロック２７５の「Ｙｅｓ」経路がとられる。 ベース書式が同じであるかクライアントをベース変更するかを問わず、クライ アント側インタセプタ・モジュール３０によってブロック２７７に示す操作が行 われる。ブロック２７７は、クライアント側インタセプタ・モジュール３０が、 クライアントＣＧＩベース書式を外部通信リンク３５を介して受け取ったＣＧＩ 差分データと比較して、インタセプトしたＣＧＩ応答に対応するＨＴＴＰデータ ・ストリームを作成することによって、外部通信リンク３５を介して受け取った クライアント／サーバ固有データ・ストリームから、ウェブ・サーバ２０から受 け取った通信に対応するＨＴＴＰデータ・ストリームを再構築する操作を示す。 ブロック２７８に示すように、この応答は次にＨＴＴＰデータ・ストリームとし てウェブ・ブラウザ１０に供給される。 クライアントにＣＧＩ要求のＵＲＬに対応するＣＧＩベース書式が存在しない 場合、第８図のブロック２７０から「Ｎｏ」経路がとられる。ブロック２７１に 示すように、クライアント側インタセプト・モジュール３０は、ＵＲＬと、サー バ側インタセプト・モジュール４０から外部通信リンクを介して受信したＨＴＴ Ｐデータ・ストリームのＣＲＣと、実ＨＴＴＰデータ・ストリーム・データとを 格納することによってＣＧＩ要求のＵＲＬに対応するクライアント・ベース・キ ャッシュ項目を作成する。この情報を格納することによって、インタセプトされ たＣＧＩ要求に対応するクライアント・ベース・キャッシュ項目が作成され、し たがってクライアントＣＧＩベース書式が作成される。次に、クライアント側イ ンタセプト・モジュールは、クライアントＣＧＩベース書式をＣＧＩ差分データ （ナル化されていることがある）と結合またはマージすることによって、ＨＴＴ Ｐデータ・ストリームを再構築することでブロック２７７の操作を行う。 本発明の差分計算技法は非ＣＧＩデータにも適用可能である。その場合、サー バ側インタセプト・モジュール４０は、ウェブ・サーバに接続されているウェブ ・ブラウザのクライアント側インタセプト・モジュールが異なるベース書式を持 っている可能性を見込んで、複数の世代のサーバ・ベース・キャッシュ項目を維 持する必要がある。その場合、サーバ側インタセプト・モジュールは、一致する ものが得られるまで、 クライアント側インタセプト・モジュールから受け取ったＣＲＣを各世代のサー バ・ベース書式のＣＲＣと比較する。その際、サーバ側インタセプト・モジュー ル４０は、任意選択でクライアント側インタセプト・モジュール３０のベース変 更を行うか、または単にクライアント側インタセプト・モジュール３０に差分デ ータを供給することができる。したがって、本明細書でＣＧＩ要求に関して説明 した差分計算方法は、どのようなＨＴＴＰ要求および応答にも等しく適用可能で ある。 複数の世代のベース書式を維持する上述のシステムでは、非ＣＧＩ要求につい て差分計算を使用することができるが、この方法はメモリまたは格納域を多用し 、前述のキャッシング機能が十分に活用されない。メモリまたは格納域必要量を 少なくし、前述のキャッシング方法を活用するために、非ＣＧＩ要求に差分計算 を使用する以下の好ましい方法を使用することできる。この好ましい実施態様で は、サーバ側インタセプト・モジュールは、要求に対応するサーバ・ベース書式 とウェブ・サーバからの応答のＨＴＴＰデータ・ストリームとの差分を計算する 。次に、ベース書式をウェブ・サーバからの新しい応答で置き換えることによっ て、サーバ・ベース書式を更新する。これにはベース書式のＣＲＣの更新も含ま れる。しかし、古いＣＲＣを廃棄するのではなく、前のベース書式のＣＲＣは差 分データとして格納する。次に、前の世代の差分データとＣＲＣを、非ＣＧＩ要 求に対応するクライ アント・ベースのＣＲＣに基づいて選択的にクライアント側インタセプト・モジ ュールに送る。 非ＣＧＩ差分計算方法の一例として、サーバ側インタセプト・モジュールが非 ＣＧＩ要求を受け取った場合、その要求には非ＣＧＩ要求のＵＲＬに対応するク ライアント側インタセプト・モジュールにあるベース書式のＣＲＣも付随してい ることになる。サーバ側インタセプト・モジュールは、ウェブ・サーバから応答 を受け取ると、その応答のＣＲＣを計算する。次に、サーバ側インタセプト・モ ジュールは応答とＵＲＬのサーバ・ベース書式との差分を計算し、その差分デー タを保管する。サーバ側インタセプト・モジュールは、応答データを使用してサ ーバ・ベース書式を更新し、前のベース書式のＣＲＣと、応答と古いベース書式 との間の差分データとをアーカイブする。次に、サーバ側インタセプト・モジュ ールは、クライアント・ベース書式のＣＲＣをサーバ・ベース書式のＣＲＣおよ び格納またはアーカイブされているＣＲＣと比較し、一致しているものがあるか どうかを判断する。一致が見つからない場合、その応答は単にクライアント側イ ンタセプト・モジュールに送られる。 一致が見つかった場合、一致するＣＲＣに対応する差分データと、それ以降の 、現行差分データを含む現行差分データまでの差分データがクライアント側イン タセプト・モジュールに送られる。クライアント側インタセプト・モジュールは 、その差分データをクライアント・ベース書式に適用して応答 を再構築する。したがって、３世代古いベース書式のＣＲＣについてＣＲＣ一致 があった場合、３セットの差分データがクライアント側インタセプト・モジュー ルに送られることになり、３セットの連続した差分データをクライアント・ベー ス書式に適用することによって、応答の構築が行われることになる。しかし、応 答を再構築するのに必要な差分データ・セットの数が多すぎるかまたは差分デー タ・セットの大きさが大き過ぎて、実応答を送信した方がデータ転送が少なくて 済む場合、サーバ側インタセプト・モジュールは応答自体を送信することができ る。いずれにしても、応答の再構築または受信の後、クライアント側インタセプ ト・モジュールは、要求のＵＲＬのクライアント・ベース書式を応答データによ って更新し、ＣＲＣを要求のＣＲＣで更新する。クライアント・ベース書式は特 定のＵＲＬについて応答を受信するたびに更新されるため、非ＣＧＩ要求に対し て差分計算を使用した場合、上述のクライアント・キャッシュをクライアント・ ベース書式のキャッシュとして使用することができ、それによってクライアント ・ベース書式の別個のキャッシュを不要にすることができる。 本発明の他の態様では、ＨＴＴＰなどのステートレス通信プロトコルの冗長性 に基づいて、通信をさらに節約することができる。そのようなプロトコルでは、 クライアントは通信を開始するたびにクライアント自体に関する情報をサーバに 送信する。同様に、サーバは応答を出すたびにサーバ自体に 関する特定の情報をクライアントに伝達する。 本発明の一実施例では、第１のコンピュータ５は第２のコンピュータ６に、第 １のコンピュータの事前定義特性に対応するコンピュータ固有情報を伝達する。 第２のコンピュータはこのコンピュータ固有情報を格納する。次に、第１のコン ピュータはそれ以降のウェブ・ブラウザ発信通信からそのコンピュータ固有情報 を除去してから外部通信リンク３５で送信する。第２のコンピュータ６は、外部 通信リンク３５を介して受信したそれ以降の通信と格納しているコンピュータ固 有情報とを組み合わせてＨＴＴＰデータ・ストリームを作成することによって、 元のウェブ・ブラウザ発信通信を再構築する。 ウェブ・ブラウザによって発信される通信からコンピュータ固有情報を除去す るほかに、このコンピュータ固有情報をウェブ・サーバによって発信される通信 からも除去することができる。その場合、第２図の第２のコンピュータ６は第１ のコンピュータ５に外部通信リンク３５を介して、第２のコンピュータ６の事前 定義特性に対応するコンピュータ固有情報を供給する。第１のコンピュータ５は そのコンピュータ固有情報を格納して、サーバ・ヘッダ情報を備える。その後の 通信の時には、第２のコンピュータ６はウェブ・サーバ発信通信からコンピュー タ固有情報を除去し、ウェブ・サーバ発信通信の残りの部分を外部通信リンク３ ５で送信する。第１のコンピュータ５は外部通信リンクでその通信を受信し、サ ーバ・ヘッダ情報を外部通信リンクを介して受信したクライアント／サーバ固有 データ・ストリームと結合してＨＴＴＰデータ・ストリームを作成することによ って、元のウェブ・サーバ発信通信を再構築する。どちらの場合も、操作が第１ のコンピュータ５と第２のコンピュータ６のどちらで行われるかに応じて、コン ピュータ固有情報を取り除き、その情報を格納してサーバ・ヘッダ情報またはク ライアント・ヘッダ情報を作成する操作がクライアント側インタセプト・モジュ ール３０またはサーバ側インタセプト・モジュール４０によって行われる。 本発明の一実施例では、ウェブ・ブラウザ１０は伝送制御プロトコル／インタ ーネット・プロトコル（ＴＣＰ／ＩＰ）を使用してクライアント側インタセプト ・モジュール３０と通信する。ＴＣＰは、外部通信リンク３５を介したクライア ント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール４０ との間の通信にも使用することができる。最後に、ＴＣＰはサーバ側インタセプ ト・モジュール４０とウェブ・サーバ２０との間の通信にも使用することができ る。ＴＣＰは本発明のシステムを構成する様々な構成要素間の通信に使用するこ とができるが、ＨＴＴＰプロトコルは外部通信リンクを介した通信にとって最も 効率的な手段を提供するものではない。外部通信リンク３５のパフォーマンスを 向上させるために、本発明の一実施例は本明細書で「仮想ソケット」と呼ぶもの を作成する。これは、ウェブ・ブラウザとク ライアント側インタセプト・モジュール３０の間の接続と、サーバ側インタセプ ト・モジュール４０とウェブ・サーバ２０との間の接続に使用される。これらの 仮想ソケットの動作について、第１１図ないし第１７図を参照しながら以下に説 明する。 第１１図は、仮想ソケットを使用する本発明の１つの可能な実施態様を示すブ ロック図である。第１１図に示すように、第１のコンピュータ５と第２のコンピ ュータ６は外部通信リンク３５を介して接続されている。ウェブ・ブラウザ１０ は、ウェブ・ブラウザ１０をクライアント側インタセプト・モジュール３０と接 続する複数の実ソケットを有する。第１１図に示すように、第１の実ソケットは ウェブ・ブラウザ１０上に６５ａとして図示され、それに対応するソケットはク ライアント側インタセプト・モジュール３０上の６５ｂである。この第１の実ソ ケットは、それを介してウェブ・ブラウザ１０がクライアント側インタセプト・ モジュール３０に対してさらに接続を要求するＴＣＰソケットである。 ウェブ・ブラウザ１０が新しいＴＣＰ接続を要求すると、実ソケット６５ａを 介して通信が行われ、それが実ソケット６５ｂによって受信される。次にクライ アント側インタセプト・モジュール３０は、ウェブ・ブラウザ１０との通信のた めに別の実ソケットを作成する。第１１図に示すように、ウェブ・ブラウザ１０ 上で複数の実ソケットが作成され、それに対応する実ソケットがクライアント側 インタセプト・モジ ュール３０上で作成される。これらの実ソケットは、ウェブ・ブラウザ１０上の ６０ａ〜６４ａおよびクライアント側インタセプト・モジュール３０上の６０ｂ 〜６４ｂとして図示されている。これらの実ソケットは、ウェブ・ブラウザ１０ がそれを介してクライアント側インタセプト・モジュール３０と通信するための 手段である。実ソケット６０ａ〜６４ａおよび６０ｂ〜６４ｂを作成した後、こ れらのソケットを介した通信を多重化して実ソケット３６ａに送り、実ソケット ３６ａはクライアント側インタセプト・モジュール３０に外部通信リンク３５へ のアクセスを提供する。実ソケット３６ａおよび３６ｂはコンピュータ５の実ソ ケット３７ａを介してコンピュータ６の実ソケット３７ｂに要求を送るときに作 成される。実ソケット３７ｂが接続要求を受け取ると、実ソケット３６ａおよび ３６ｂが作成される。ソケット３７ａおよび３７ｂは、クライアント側インタセ プト・モジュールとサーバ側インタセプト・モジュールとの間の通信のための最 初の実ソケットとして機能し、ソケット３６ａおよび３６ｂによって示されてい るこの２つのモジュールの間の接続を確立するためにのみ使用することができる 。これらの実ソケットのそれぞれは標準ＴＣＰ／ＩＰプロトコルの下で動作する 。第２のコンピュータ６が外部通信リンク３５を介して通信を受信するとき、そ れらの通信は実ソケット３６ｂで受信される。次にサーバ側インタセプト・モジ ュール４０は、ソケット３６ｂで受信した通信を多重化解除し、それらをウェブ ・ サーバ２０に送信するために適切なソケットに供給する。したがって、たとえば 、特定のＵＲＬに対して情報を要求するためのソケット６０ａからソケット６０ ｂまでの通信は、ソケット３６ａ上に多重化され、ソケット３６ｂによって受信 され、サーバ側インタセプト・モジュール４０によって多重化解除され、ソケッ ト６０ｃからウェブ・サーバ２０上のソケット６０ｄに送られることになる。同 様に、ソケット６１ａを介して行われる通信はソケット６１ｂによって受信され 、クライアント側インタセプト・モジュール３０によって多重化され、ソケット ３６ａからソケット３６ｂに送られ、そこでサーバ側インタセプト・モジュール ４０がその通信を多重化解除してソケット６１ｃからソケット６１ｄに送る。し たがって、ソケット６０ａと６０ｂ、６１ａと６１ｂ、６２ａと６２ｂ、６３ａ と６３ｂ、６４ａと６４ｂを介した通信は、サーバ側インタセプト・モジュール ４０とウェブ・サーバ２０との間のソケット６０ｃと６０ｄ、６１ｃと６１ｄ、 ６２ｃと６２ｄ、６３ｃと６３ｄ、および６４ｃと６４ｄのうちのそれぞれの対 応するソケットを介して送信される。 同様に、ウェブ・サーバ２０によるウェブ・ブラウザ１０からの要求に対する 応答も、ウェブ・サーバ２０をサーバ側インタセプト・モジュール４０に接続す るソケットを介して送られ、外部通信リンク３５を介してクライアント側インタ セプト・モジュール３０に送られた後、ウェブ・ブラウザ１０に送られる。した がって、たとえばウェブ・サーバ２０に よって発信された応答はソケット６０ｄから６０ｃを介して送られ、サーバ側イ ンタセプト・モジュール４０によってソケット３６ｂに多重化され、そこから外 部通信リンク３５を介してソケット３６ａに送られる。次にクライアント側イン タセプト・モジュール３０がその通信を多重化解除し、それをソケット６０ｂに 送り、それがウェブ・ブラウザ１０上のソケット６０ａに送られる。ウェブ・ブ ラウザ１０またはウェブ・サーバ２０が使用する各ソケットについて同様の通信 経路が確立される。当業者ならわかるように、本発明についてウェブ・ブラウザ １０とウェブ・サーバ２０との間の４ソケット通信に関して説明したが、ウェブ ・ブラウザ１０とウェブ・サーバ２０との間の通信アクセスを実現するために任 意の数のソケットを開くことができる。 第１２図は、クライアント側インタセプト・モジュール３０とサーバ側インタ セプト・モジュール４０における仮想ソケット・システムの実施例を示すブロッ ク図である。これらのモジュールの外部で、クライアント側インタセプト・モジ ュール３０とウェブ・ブラウザ１０およびサーバ側インタセプト・モジュール４ ０とウェブ・サーバ２０の間の実ソケットが、通常のＴＣＰ／ＩＰソケットとし て機能する。したがって、仮想ソケットの使用はウェブ・ブラウザ１０およびウ ェブ・サーバ２０には透過である。 第１２図のブロック図と第１３図ないし第１７図の流れ図を参照しながら本発 明の特定の実施例について説明する。第 １３図は、第１２図にブロック６８として図示されているソケット・マネージャ のフローチャートである。第１３図を参照すると、ブロック３００はクライアン ト側インタセプト・モジュール３０の実ソケット・マネージャ６８の作成を示し ている。実ソケット・マネージャ６８が作成された後、実ソケット・マネージャ は第１２図にソケット６５ｂとして図示されている第１の実ソケットを作成する 。この第１の実ソケットの作成は第１３図のブロック３０１として示されている 。第１の実ソケット６５ｂを作成した後、クライアント側インタセプト・モジュ ール３０内にあるソケット・マネージャ６８（本明細書ではクライアント・ソケ ット・マネージャとも呼ぶ）は、第１３図のブロック３０２に示すように、第１ の実ソケット６５ｂ上での事象を待つ。第１の実ソケット６５ｂ上で事象を受け 取ると、第１３図のブロック３０５に示すように実ソケット・マネージャ６８は その事象を検査し、その検査に基づいて５通りの経路のうちの１つをとる。 第１の実ソケット６５ｂで受信した通信要求に応答して実ソケットが作成され た場合は、第１３図のブロック３０５から３０６までの経路に示すように、実ソ ケット・マネージャ６８はその実ソケットを実事象リストに追加する。次に、実 ソケット・マネージャはブロック３０７に示すようにシンプレックス仮想ソケッ トを作成する。クライアント側インタセプト・モジュールの場合、実ソケット・ マネージャは、第１３図のブロック３０８に示すように、作成された仮想ソケッ トについてクライアント側インタセプト・モジュールの機能を実行するアプリケ ーション機能を開始する。 本明細書では、「シンプレックス・ソケット」または「シンプレックス仮想ソ ケット」という用語は、単一のソケットまたは単一のアプリケーションに直接接 続するソケットを指す。本明細書では、「マルチプレックス・ソケット」とは他 の複数のソケットに接続するソケットを指す。したがって、マルチプレックス・ ソケットは、多重化または多重化解除機能を実行し、シンプレックス・ソケット は１対１接続を行う。したがって、たとえば、第１３図のブロック３０６から３ ０８までの機能を実行する際、クライアント・ソケット・マネージャ６８は第１ の実ソケット６５ｂが受信した第１の接続要求に応答して、実ソケット６０ｂ、 シンプレックス仮想ソケット７０を作成し、アプリケーション８０のクライアン ト側インタセプト機能を開始することになる。実ソケットが作成されたその後の 事象の場合も同様に、実ソケット・マネージャは実ソケット６１ｂ、６２ｂ、６ ３ｂ、または６４ｂとシンプレックス仮想ソケット７１、７２、７３、または７ ４を作成し、第１２図でブロック８１、８２、８３、または８４として図示され ている、作成された実ソケットおよび仮想ソケットに対応するＣＳＩ機能を開始 する。 以下に、クライアント側インタセプト機能の操作について、第１２図に示す実 ソケット６０ｂとシンプレックス仮想ソケット７０とクライアント側インタセプ ト機能８０とを参照し ながら説明する。第１４図のブロック３２５はクライアント側インタセプト機能 ８０の作成を示している。作成されると、クライアント側インタセプト機能８０ はブロック３２６に示すようにシンプレックス仮想ソケット７０上の事象を待つ 。この待機操作は、第１６−４図に示す仮想選択機能を実行することによって行 われる。事象を受け取ると、ブロック３３０に示すようにその事象が検査される 。事象が仮想ソケット閉鎖である場合、第１４図のブロック３４９に示すように クライアント側インタセプト機能８０はシンプレックス仮想ソケット７０を削除 し、ブロック３５０に示すように終了する。 事象がデータの受信である場合、ブロック３３０からブロック３３１への経路 がとられ、クライアント側インタセプト機能８０は第１６−３図を参照しながら 説明する仮想受信操作を実行することによって、シンプレックス仮想ソケット７ ０からブラウザ発信通信を受け取る。次に、クライアント側インタセプト機能は 前述のクライアント側インタセプト・モジュールの機能（たとえば第３図および 第７図を参照）を実行する。これはブロック３３２に示されている。次にクライ アント側インタセプト機能８０は、クライアント側インタセプト・モジュール３ ０内の実ソケット３６ａに接続されるマルチプレックス仮想ソケット９０を作成 する。実ソケット３６ａはサーバ側インタセプト・モジュール４０上の実ソケッ ト３６ｂに接続される。マルチプレックス仮想ソケットの作成は、第１４図のブ ロック３３３に示されており、本明細書 で第１６−１図を参照しながら説明する仮想作成操作を実行することによって行 われる。ブロック３３４は、ウェブ・ブラウザ発信通信のためにクライアント側 インタセプト機能８０が実行された後で、実ソケット６０ｂとシンプレックス仮 想ソケット７０を介してウェブ・ブラウザから受け取った情報を送信する操作を 示す。この通信は、第１６−２図を参照しながら説明する仮想送信操作を実行す ることによってマルチプレックス仮想ソケット９０の待ち行列に入れられる。ク ライアント側インタセプト機能８０は、要求をマルチプレックス仮想ソケット９ ０の待ち行列に入れた後、第１４図のブロック３３５に示すようにマルチプレッ クス仮想ソケット９０の待ち行列に入れられているデータをフラッシュし、次に ブロック３３６に示すようにマルチプレックス仮想ソケット上の事象を待つ。仮 想フラッシュ機能は、第１７−１図を参照しながら説明する仮想フラッシュ操作 を実行することによって行われ、マルチプレックス仮想ソケット待ち行列からデ ータを取り出してそのデータを実ソケット３６ａに供給する。待機機能は、第１ ６−４図に示す仮想選択機能を実行することによって行うことができる。この時 点で、クライアント側インタセプト・モジュールはウェブ・ブラウザ発信通信を インタセプトし、その通信を外部通信リンク３５を介してサーバ側インタセプト ・モジュールに送信し終わったことになる。 第１３図に戻ると、サーバ側インタセプト・モジュール４０またはクライアン ト側インタセプト・モジュール３０にお けるソケット・マネージャのフローチャートが示されている。第１２図のブロッ ク６９に示すように、サーバ側インタセプト・モジュール内の実ソケット・マネ ージャ、すなわちサーバ・ソケット・マネージャは、ブロック６８に示すクライ アント・ソケット・マネージャと同じ機能を実行する。ブロック３０１に示すよ うに、第１の実ソケットを作成する際、サーバ側インタセプト・モジュール３０ は、サーバ側インタセプト・モジュール４０に関連づけられたクライアント側イ ンタセプト・モジュール３０からのソケットの要求を受け取る「周知のポート」 ３７ｂを作成する。サーバ側インタセプト・モジュール４０の実ソケット３６ｂ 上で実事象が発生すると、ブロック３０５に示すようにその事象が検査される。 この場合、この事象は実ソケット３６ａからのデータの受信であり、したがって 第１３図のブロック３０５からブロック３２０までの経路がとられる。実ソケッ ト３６ｂ上で受信したデータが検査され、この例ではデータはクライアント側イ ンタセプト・モジュールによって送信されたウェブ・ブラウザ発信通信であるた め、サーバ側インタセプト・モジュール４０において新しい仮想ソケットを作成 しなければならない。したがって、第１３図のブロック３２０からブロック３２ １への経路がとられる。次にサーバ・ソケット・マネージャ６９は、第１３図の ブロック３２１、ブロック３２２、ブロック３２３、およびブロック３２４に示 す操作を行う。サーバ・ソケット・マネージャ６９はブロック３２１に示すよう に マルチプレックス仮想ソケット９５を作成し、ブロック３２２に示すようにマル チプレックス・ソケット活動タイマをキャンセルし、第１３図のブロック３２３ と第１２図のブロック８５に示すサーバ側インタセプト機能のアプリケーション を開始する。実ソケット３６ｂで受け取ったデータは次にマルチプレックス仮想 ソケット９５の待ち行列に入れられ、仮想事象が通知される。 ブロック３２３に示すサーバ側インタセプト機能の作成は、第１５図のブロッ ク３６０に示されている。サーバ側インタセプト機能８５の作成後、この機能は 、クライアント側インタセプト・モジュール３０から送信され、ウェブ・ブラウ ザ発信通信に対応するデータを、マルチプレックス仮想ソケット９５から受け取 る。この操作は第１５図のブロック３６１に示されている。クライアント側イン タセプト・モジュールからデータを受け取った後、サーバ側インタセプト機能８ ５は、そのデータを、サーバ側インタセプト・モジュールについて前述したよう に処理する。このサーバ側機能の実行はブロック３６２に示されている（たとえ ば第５図および第９図を参照）。情報を処理した後、サーバ側インタセプト機能 ８５は仮想作成を行うことによってシンプレックス仮想ソケット７５を作成する 。この操作については本明細書で第１６−１図を参照しながら説明する。この操 作は第１５図のブロック３６３に示されている。次に、サーバ側インタセプト機 能８５は、仮想送信を行うことによって、ブロック３６４に示 すようにウェブ・ブラウザ発信通信をシンプレックス仮想ソケット７５に送る。 仮想送信の操作については本明細書で第１６−２図を参照しながら説明する。次 に、サーバ側インタセプト機能８５は、仮想フラッシュを行ってシンプレックス 仮想ソケット７５の待ち行列に入っているデータをソケット６０ｃにフラッシュ し、シンプレックス仮想ソケット７５上の事象を待つ。仮想フラッシュ操作につ いては本明細書で第１７−１図を参照しながら説明する。この送信操作とフラッ シュ操作は第１５図のブロック３６４および３６５に示されている。待機操作は 、第１６−４図で説明されている仮想選択機能を実行することによって行うこと ができる。サーバ側インタセプト機能８５がシンプレックス仮想ソケット７５を 作成したとき、対応する実ソケット６０ｃも作成されている。サーバ側インタセ プト機能８５は、ウェブ・ブラウザ発信通信をシンプレックス仮想ソケット７５ に送信することによって、ウェブ・ブラウザ発信通信をウェブ・サーバに転送し た。 サーバ側インタセプト・モジュール４０が実ソケット６０ｃ上でウェブ・サー バからの応答を受信すると、実事象が発生し、サーバ・ソケット・マネージャ６ ９は第１３図のブロック３０２を終了して、ブロック３０５に示すように実ソケ ット６０ｃ上で発生した事象を検査する。この事例の場合、これは既存の仮想ソ ケットのデータであり、第１３図のブロック３２０からブロック３２４までの経 路がとられる。実ソケット６０ｃ上で受信したデータは仮想ソケット７５の待ち 行列に入れられ、仮想事象が通知される。仮想事象が通知されると、サーバ側イ ンタセプト機能８５は第１５図のブロック３６６を終了し、ブロック３７０に示 すようにその事象を検査する。事象がソケット閉鎖である場合、エラー条件が発 生し、第１５図のブロック３７５に示すように応答としてエラー・メッセージが 作成される。しかし、事象がデータの受信の場合は、ブロック３７０からブロッ ク３７１への経路をとり、サーバ側インタセプト機能８５は、第１６−３図を参 照しながら説明するように仮想受信を実行して、ブロック３７１に示すようにシ ンプレックス仮想ソケット７５から応答を入手する。次にサーバ側インタセプト 機能８５は、ブロック３７２に示し、第１７−２図を参照しながら説明するよう に、シンプレックス仮想ソケット７５の仮想閉鎖を実行し、サーバ側インタセプ ト・モジュールに関して前述し、ブロック３７３に示すように、その応答を処理 する（たとえば第６図および第１０図を参照）。 第１５図のブロック３７０の終了経路がブロック３７５へのエラー経路である かブロック３７１へのデータ経路であるかを問わず、ブロック３７４でシンプレ ックス仮想ソケット７５が削除される。次にサーバ側インタセプト機能は、ブロ ック３７６に示すようにマルチプレックス仮想ソケット９５への仮想送信操作を 行ってウェブ・サーバ発信通信をクライアント側インタセプト・モジュール３０ に送信する。サーバ側インタセプト機能８５は次に、仮想フラッシュ操作を行っ て、マルチプレックス仮想ソケット９５の待ち行列に入っているデータをフラッ シュする。これらの操作はブロック３７７に示されている。次にサーバ側インタ セプト機能８５は、第１５図のブロック３７８に示すように仮想閉鎖操作を行っ てマルチプレックス仮想ソケット９５を閉じる。最後に、サーバ側インタセプト 機能８５は、ブロック３７９および３８０に示すようにマルチプレックス仮想ソ ケットを削除して終了する。 サーバ側インタセプト機能は、マルチプレックス仮想ソケット９５への仮想送 信操作とフラッシュ操作を行う。これらの操作によって、実ソケット３６ａ上で 事象がトリガされ、クライアント・ソケット・マネージャ６８はブロック３０２ を終了し、ブロック３０５に示すように事象を検査する。これは実ソケット３６ ａでデータを受信し、第１３図のブロック３０５からブロック３２０までの経路 がとられ、データがマルチプレックス仮想ソケット９０の待ち行列に入れられる ためである。したがって、実ソケット３６ａが外部通信リンク３５を介して実ソ ケット３６ｂからウェブ・サーバ応答を受け取ると、その情報が多重化解除され 、マルチプレックス仮想ソケットに供給される。データの受信によって、第１３ 図のブロック３２４に示すように仮想事象が発生し、第１４図のブロック３３６ が終了してクライアント側インタセプト機能８０は第１４図のブロック３４０に 示すようにその事象を検査することになる。 事象がソケット閉鎖応答である場合、第１４図のブロック３４０からブロック ３４５への経路をとり、クライアント側インタセプト機能８０はエラー・メッセ ージ応答を作成して第１４図のブロック３４４に進む。この例の場合のように事 象がデータ受信の場合、第１４図のブロック３４０からブロック３４１の経路を とり、クライアント側インタセプト機能８０は仮想受信操作を行ってマルチプレ ックス仮想ソケット９０から応答を受信する。この受信操作は第１４図のブロッ ク３４１に示されている。マルチプレックス仮想ソケット９０からデータを受信 した後、クライアント側インタセプト機能８０はブロック３４２に示すように仮 想閉鎖操作を行ってマルチプレックス仮想ソケット９０を閉じる。次にクライア ント側インタセプト機能８０は、ブロック３４３に示すように、クライアント側 インタセプト・モジュールに関して前述したように応答を処理する（たとえば第 ４図および第８図を参照）。 ブロック３４０を終了してどちらの経路をとる場合も、ブロック３４４の操作 が行われる。クライアント側インタセプト機能８０は、ブロック３４４に示すよ うにマルチプレックス仮想ソケットを削除し、次にブロック３４６に示すように 仮想送信操作を行ってシンプレックス仮想ソケット７０を介してブラウザに応答 を送信する。この仮想送信操作が完了すると、クライアント側インタセプト機能 ８０はブロック３４７に示すように仮想フラッシュ操作を行ってシンプレックス 仮想ソケットの待ち行列に入っているデータを実ソケット６０ｂにフラッシュし 、次にブロック３４８に示すように仮想閉鎖操作を行ってシンプレックス仮想ソ ケットを閉じる。クライアント側インタセプト機能のシンプレックス仮想ソケッ トを閉じた後、第１４図のブロック３４９および３５０に示すようにシンプレッ クス仮想ソケットが削除され、クライアント側インタセプト機能は終了する。 当業者ならわかるように、本発明についてシンプレックス仮想ソケットおよび マルチプレックス仮想ソケットとクライアント側インタセプト機能およびサーバ 側インタセプト機能の１つの特定のインスタンスに関して説明したが、単一のク ライアント側インタセプト・モジュールまたはサーバ側インタセプト・モジュー ル内でこれらの機能を複数作成することができる。したがって、本発明によるク ライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールは 、クライアント側インタセプト・モジュール３０とサーバ側インタセプト・モジ ュール４０との間にＴＣＰ／ＩＰ接続を作成し、次に、そのＴＣＰ／ＩＰ接続を 維持しながらそのＴＣＰ／ＩＰ接続上で複数のウェブ・ブラウザ発信通信または ウェブ・サーバ発信通信を多重化することができる。 クライアント・ソケット・マネージャとサーバ・ソケット・マネージャの残り の機能は、第１６−１図ないし第１６−４図と第１７−１図および第１７−２図 を参照すれば最もよく理解できよう。これらの図では、第１４図および第１５図 のフローチャートに示されているように仮想作成、仮想送信、仮想受信、仮想選 択、仮想フラッシュ、または仮想閉鎖操作を実行するときに、クライアント側イ ンタセプト・モジュールおよびサーバ側インタセプト・モジュールによって行わ れる操作が説明されている。第１４図のブロック３３３および第１５図のブロッ ク３６３に示すような仮想作成操作を行う場合、第１６−１図のブロック４００ から始まる操作を行う。ブロック４０５に示すように、ソケット・マネージャは 、実ソケットが必要かどうかを判断する。作成操作によって既存の実ソケットに 接続するマルチプレックス仮想ソケットを作成する場合などのように、実ソケッ トがすでに存在する場合は、ブロック４０５から「Ｎｏ」経路をとり、ブロック ４０９に示すようにその仮想ソケットが実ソケットに接続される。しかし、実ソ ケットが必要な場合は、ブロック４０５から「Ｙｅｓ」経路をとる。ブロック４ ０６に示すように実ソケットを作成する。次に、第１３図のブロック３０２に示 す監視のために、ブロック４０８に示すようにその実ソケットを事象リストに追 加する。実ソケットを作成し、接続を確立した後、ブロック４０９に示すように 仮想ソケットを実ソケットに接続し、ブロック４１０に示すように作成操作が完 了する。 第１４図のブロック３３４および３４６または第１５図のブロック３６４およ び３７６に示す仮想送信操作を行う場合、第１６−２図のブロック４２０から始 まる操作が行われる。 ブロック４２７に示すようにデータが仮想ソケット待ち行列に加えられ、完了す ると、送信操作はブロック４２８に示すように終了する。 第１４図のブロック３３１および３４１と第１５図のブロック３６１および３ ７１に示す仮想受信操作は、第１６−３図のブロック４３０から始まる操作を行 うことによって行われる。ブロック４３５に示すように、仮想ソケット待ち行列 を調べて仮想ソケット待ち行列に何かデータが入っているか判断する。仮想ソケ ット待ち行列にデータがある場合、ブロック４３５の「Ｙｅｓ」経路をとり、ブ ロック４３６に示すように受信操作を呼び出した機能にそのデータが返される。 仮想ソケット待ち行列にデータがなく、ソケットに閉鎖のマークが付けられてい ない場合、決定ブロック４４０の「Ｎｏ」経路をとり、ブロック４４１に示すよ うに何も返されない。しかし、待ち行列にデータがなく、ソケットに閉鎖のマー クが付けられている場合、ブロック４４０の「Ｙｅｓ」経路をとり、ブロック４ ４２に示すようにソケットに閉鎖のマークが付けられて、ブロック４４３に示す ように、受信を要求する操作にソケット閉鎖応答が返される。 第１４図のブロック３２６および３３６と第１５図のブロック３６６で行われ る仮想選択操作は、第１６−４図のブロック４４５から始まる操作を実行するこ とによって行われる。ブロック４４６に示すように、まず、選択された仮想ソケ ットについてデータまたは仮想閉鎖操作が保留状態になってい ないかどうかを判断する。保留状態のデータまたは仮想閉鎖がない場合、ブロッ ク４４６の「Ｎｏ」経路をとり、プロセスはブロック４４７に示すように選択さ れた仮想ソケット上の仮想ソケットを待ち、そのような事象を受け取った後でブ ロック４４８に示すように終了する。選択された仮想ソケットについてデータま たは仮想閉鎖が保留状態になっている場合、仮想事象がすでに発生しており、ブ ロック４４６の「Ｙｅｓ」経路をとって、ブロック４４８に示すようにプロセス が終了する。 第１４図のブロック３３５および３４７と第１５図のブロック３６５および３ ７７で言及した仮想フラッシュ操作は、第１７−１図のブロック４５０から始ま る操作を実行することによって行われる。仮想フラッシュ操作が呼び出されると 、決定ブロック４５５に示すように、フラッシュする仮想ソケット待ち行列にデ ータが入っているかどうかを調べる。仮想ソケット待ち行列にデータが入ってい ない場合、ブロック４５５の「Ｎｏ」経路が示すようにフラッシュ操作は単に終 了して呼出し側機能に戻る。しかし、待ち行列にデータが入っている場合、ブロ ック４５５の「Ｙｅｓ」経路をとり、ブロック４６０に示すようにその仮想ソケ ット待ち行列がマルチプレックス・ソケットのものであるかどうかを判断する。 マルチプレックス・ソケットである場合は、ブロック４６１に示すようにソケッ トの固有識別子と転送中のデータ量を示す３バイトから成るソケット・ヘッダが 実ソケット・バッファ に加えられる。マルチプレックス・ソケットであるかシンプレックス・ソケット であるかを問わず、いずれの場合もブロック４６２に示すように実ソケットのた めのデータが実ソケット・バッファに移される。実ソケット・バッファがいっぱ いの場合、ブロック４６５の「Ｙｅｓ」経路をとり、ブロック４６６に示すよう に実ソケット・バッファからデータが実ソケットに送られる。実バッファがいっ ぱいになっていない場合は、ブロック４６５の「Ｎｏ」経路をとる。次に、仮想 フラッシュ機能は、他のいずれかのマルチプレックス仮想ソケット待ち行列に実 ソケットに送るべき他のデータがあるかどうかを判断する。答えが肯定の場合、 ブロック４７０の「Ｙｅｓ」経路をとり、実ソケット・バッファ内のデータは、 他の仮想ソケット待ち行列の１つをフラッシュするために仮想フラッシュ操作が 再び呼び出されるまで送られない。他のデータがない場合、または他のマルチプ レックス仮想ソケットからデータを付加した後は、ブロック４６６の操作を行い 、実ソケットバッファ内のデータを実ソケットに送る。仮想フラッシュ操作を呼 び出した機能に対応する仮想ソケット待ち行列内のすべてのデータが実ソケット に送られた後、ブロック４６７に示すように仮想フラッシュ操作は終了する。 第１４図のブロック３４２および３４８と第１５図のブロック３７２および３ ７８に示す仮想閉鎖操作は、第１７−２図のブロック４８０から始まる操作を実 行することによって行われる。仮想閉鎖操作が呼び出されると、まずブロック４ ８５に示すようにその仮想閉鎖がマルチプレックス仮想ソケットの閉鎖であるか どうかを判断する。マルチプレックス仮想ソケットである場合、ブロック４８５ の「Ｙｅｓ」経路をとり、仮想ソケット待ち行列に「閉鎖」操作標識が付加され る。仮想閉鎖がマルチプレックス仮想ソケットの閉鎖であるか否かを問わず、ブ ロック４８７に示すように仮想閉鎖操作によって仮想フラッシュ操作が呼び出さ れ、ブロック４８８に示すように実ソケットとの接続を断つ。次に、ブロック４ ９０に示すように仮想閉鎖がシンプレックス仮想ソケットの閉鎖であるかどうか を調べ、そうでない場合は「Ｎｏ」経路をとってブロック４９５に進む。閉鎖は マルチプレックス仮想ソケットの閉鎖であるため、ブロック４９５でそれが最後 のマルチプレックス仮想ソケットであるかどうかを判断し、最後のマルチプレッ クス仮想ソケットである場合は、ブロック４９６に示すようにマルチプレックス 活動タイマをセットする。最後のマルチプレックス仮想ソケットでない場合は、 ブロック４９６をスキップする。 ブロック４９０に戻って、仮想閉鎖がシンプレックス仮想ソケットの閉鎖であ る場合、ブロック４９１に示すようにそれに対応する実ソケットを事象リストか ら除去し、ブロック４９２に示すように実ソケットを閉鎖し、削除する。ソケッ トがシンプレックスとマルチプレックスのどちらの仮想ソケットであるかを問わ ず、ブロック４９７に示すようにその仮想ソケットに閉鎖のマークを付け、ブロ ック４９８で閉鎖操 作は終了する。 次に、第１６−１図ないし第１６−４図および第１７−１図ないし第１７−２ 図に関連する第１３図について説明する。実事象が発生すると、第１３図のブロ ック３０２を終了し、ソケット・マネージャは事象がどのように生成されたかに 基づいてその事象を調べる。事象が第１７−２図のブロック４９６で設定された マルチプレックス・ソケット活動タイマのタイム・アウトである場合、第１３図 のブロック３０５からブロック３１２までの経路がとられる。第１３図に示すよ うに、次にソケット・マネージャによってブロック３１２および３１３の操作が 行われ、マルチプレックス実ソケットが閉じられ、クライアント側インタセプト ・モジュールをサーバ側インタセプト・モジュールに接続するソケットに対応す るマルチプレックス実ソケットが削除される。その後、ソケット・マネージャは 次の実事象を待つ。ブロック３２２に示すように、このマルチプレックス事象タ イマはマルチプレックス仮想ソケットの作成によってリセットされる。 実ソケット上で発生した事象が、ウェブ・サーバがウェブ・サーバとサーバ側 インタセプト・モジュールとの間のソケット接続に対する閉鎖操作を行う場合な どの実ソケット閉鎖である場合、第１３図のブロック３０５からブロック３０９ への経路がとられる。ソケット・マネージャはブロック３０９に示すように実事 象リストからその実ソケットを除去し、ブロック３１０に示すように１つの仮想 ソケット（または複 数のマルチプレックス・ソケットの場合は複数の仮想ソケット）をその１つの実 ソケットまたは複数の実ソケットから切断する。次に、ソケット・マネージャは その仮想ソケットに閉鎖のマークを付け、仮想事象を通知する。この操作はブロ ック３１１に示されており、仮想ソケット待ち行列からすべてのデータが空にさ れると、仮想ソケットは閉じる。仮想ソケットに閉鎖のマークを付けた後、決定 ブロック３１５に示すようにソケット・マネージャは閉じる実ソケットがシンプ レックス・ソケットであるかどうかを判断する。閉じる実ソケットがシンプレッ クス・ソケットである場合、ブロック３１６に示すようにその実ソケットを閉じ 、削除する。次にソケット・マネージャはブロック３０２に示すように次の実事 象を待つ。 閉じるソケットがシンプレックス実ソケットではない場合、ブロック３１５の 「Ｎｏ」経路をとり、ソケット・マネージャは次の実事象を待つ。したがって、 マルチプレックス実ソケット、すなわちクライアント側インタセプト・モジュー ルとサーバ側インタセプト・モジュールとを接続するソケットを、マルチプレッ クス・ソケット活動タイマのタイムアウトのみによって閉じることができる。こ れによって、ユーザ指定の所定時間の間、クライアント側インタセプト・モジュ ールとサーバ側インタセプト・モジュールとの間の接続を、モジュール間の最後 の通信が行われた後でも維持することができる。マルチプレックス・ソケット活 動タイマのタイムアウ トの前にブラウザからその後の接続要求があった場合、クライアント側インタセ プト・モジュールとサーバ側インタセプト・モジュールとの間に接続を再確立せ ずに通信を行うことができ、それによってそのような接続を再確立するオーバー ヘッドが不要になる。 第１３図で説明する最後の経路は、実事象が発生し、その事象が第１２図の１ つまたは複数のマルチプレックス実ソケット３６ａまたは３６ｂ上でのデータの 受信である場合である。マルチプレックス実ソケット上でデータを受信すると、 そのデータは検査され、第１７−２図のブロック４８６で仮想待ち行列に付加さ れるもののようにデータに閉鎖操作標識が含まれている場合は、仮想閉鎖操作が 行われ、ブロック３２０からブロック３１０への経路がとられる。ソケット・マ ネージャは、ブロック３１０に示すように実ソケット上で受信したデータで識別 されたマルチプレックス仮想ソケットを実ソケットから切断し、次にブロック３ １１に示すように仮想ソケットに「閉鎖」のマークを付け、仮想事象を通知する 。この閉鎖はマルチプレックス仮想ソケットの閉鎖であるため、ブロック３１５ から「Ｎｏ」経路がとられ、ブロック３０２に示すようにソケット・マネージャ は別の実事象を待つ。 第１３図ないし第１７図で説明されている操作を行うことによって、本発明の 特定の態様は外部通信リンクを介して第１のコンピュータと第２のコンピュータ との間に持続的接続を確立する。この持続的接続は、すべてのウェブ・ブラウザ 発信通信が完了するまで維持され、持続的接続が維持されている間に複数のウェ ブ・ブラウザ発信通信がインタセプトされ、外部通信リンクに多重化されて送ら れる。次にクライアント／サーバ固有データ・ストリームを多重化解除して複数 のＨＴＴＰデータ・ストリームを作成し、その複数のＨＴＴＰデータ・ストリー ムをウェブ・サーバに供給することができる。また、持続的接続は、すべてのウ ェブ・サーバ発信通信がインタセプト完了するまで維持される。持続的接続が維 持されている間に、複数のウェブ・サーバ発信通信がインタセプトされ、外部通 信リンクに多重化されて送られる。さらに、クライアント／サーバ固有データ・ ストリームを多重化解除して複数のＨＴＴＰデータ・ストリーを作成し、その複 数のＨＴＴＰデータ・ストリームをウェブ・サーバに供給することができる。 図面および本明細書では、本発明の典型的な好ましい実施例を開示し、特定の 用語を使用したが、これらの用語は総称および説明のためものに過ぎず、請求の 範囲に記載されている本発明の範囲を限定するためのものではない。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｇ０６Ｆ 17/30 Ｇ０６Ｆ 15/40 ３１０Ｆ (72)発明者 オーセル、バロン、コーネリュース アメリカ合衆国ノースカロライナ州チャペ ル・ヒル、ケンシングトン・ドライブ 702 (72)発明者 リンドクイスト、デヴィッド、ブルース アメリカ合衆国ノースカロライナ州ラレ ー、レイク・スプリングス・コート 4001 【要約の続き】 またサーバ・ベース・キャッシュ項目と比較して、イン タセプトされた応答とサーバ・ベース・キャッシュ項目 との間の差分に対応した差分データを与える。差分デー タを外部通信リンクによって送り、またクライアント・ ベース・キャッシュ項目を差分データと組み合わせて、 第２のアプリケーションに与えられる応答データ・スト リームを作成することによって応答データ・ストリーム を再構成する第２のコンピュータによって取得する。

Claims (1)

1. 【特許請求の範囲】 １．第１のコンピュータに常駐している第１のアプリケーションから第２のコン ピュータに常駐している第２のアプリケーションへ、第１のコンピュータから第 ２のコンピュータへの外部通信リンクによって伝送されるデータを少なくする方 法において、 第２のアプリケーションからの要求に応じて第２のアプリケーションに与えら れる第１のアプリケーションからのデータ・ストリームを第１のコンピュータに 常駐しているキャッシュに格納して、サーバ・ベース・キャッシュ項目を作成す るステップと、 第２のアプリケーションからの要求に応じて第２のアプリケーションに与えら れるデータ・ストリームを第２のコンピュータに常駐しているキャッシュに格納 して、クライアント・ベース・キャッシュ項目を作成するステップと、 第２のアプリケーションからの要求を評価して、問い合わせを受けた要求に対 応するクライアント・ベース・キャッシュ項目が存在していて、クライアント・ ベース書式を与えるかどうかを判断するステップと、 第２のアプリケーションからの要求に問い合わせを行って、問い合わせを受け た要求に対応するサーバ・ベース・キャッシュ項目が存在していて、サーバ・ベ ース書式を与えるかどうかを判断するステップと、 第２のアプリケーションからの問い合わせを受けた要求に応じて第１のアプリ ケーションが発信した応答に対応するデータ・ストリームをインタセプトしてか ら、外部通信リンク上での応答の伝送を行うステップと、 インタセプトされた応答をサーバ・ベース書式と比較して、インタセプトされ た応答とサーバ・ベース書式との間の差分に対応した差分データを与えるステッ プと、 差分データを外部通信リンクによって第２のコンピュータへ送るステップと、 第１のコンピュータによって送られた、外部通信リンクによって伝送される差 分データを取得するステップと、 クライアント・ベース書式を外部通信リンクから受信した差分データと組み合 わせて、インタセプトされた応答に対応している応答データ・ストリームを作成 することにより、外部通信リンクから受信したクライアント／サーバ固有データ ・ストリームから、第１のアプリケーションからの通信に対応した応答データ・ ストリームを再構成するステップと、 インタセプトされた応答に対応する再構成したデータ・ストリームを第２のア プリケーションに与えるステップと を備えている方法。 ２．サーバ・ベース書式がクライアント・ベース書式と同一であるかどうかを判 定するステップをさらに含み、 前記送信ステップがサーバ・ベース書式を送信するステップと、前記判定ステ ップがサーバ・ベース書式がクライアン ト・ベース書式と同一ではないと判定した場合に、差分データを外部通信リンク によって第２のコンピュータへ送信するステップとを備えており、 前記再構成ステップが外部通信リンクによって受信したサーバ・ベース書式を 、外部通信リンクによって受信した差分データと組み合わせて、インタセプトさ れた応答に対応するデータ・ストリームを作成することにより、第１のアプリケ ーションからの応答に対応したインタセプトされた応答データを再構成し、 受信したサーバ・ベース書式を問い合わせを受けた要求に対応するクライアン ト・ベース・キャッシュ項目として格納することによって、問い合わせを受けた 要求に対応するクライアント・ベース書式を更新するステップを備えている、請 求項１に記載の方法。 ３．サーバ・ベース書式とインタセプトされた応答の間の差が事前定義差分閾値 よりも大きいかどうかを判定するステップと、 サーバ・ベース書式とインタセプトされた応答の間の差が事前定義差分閾値よ りも大きい場合に、インタセプトされた応答に対応するサーバ・ベース・キャッ シュ項目として第１のアプリケーションから受信したインタセプトされた応答の データ・ストリームを格納することによって問い合わせを受けた要求に対応する サーバ・ベース書式を更新するステップとをさらに備えており、 前記比較ステップと前記送信ステップとが更新されたサーバ・ベース書式を利 用する、請求項１に記載の方法。 ４．第２のアプリケーションからの要求に対応する複数のサーバ・ベース・キャ ッシュ項目を維持するステップをさらに含み、 前記問い合わせステップが複数のサーバ・ベース・キャッシュ項目が第２のア プリケーションからの要求に対応して存在していて、複数のサーバ・ベース書式 を提供するかどうかを判定し、 複数のサーバ・ベース書式の１つがクライアント・ベース書式と同一であるか どうかを判定するステップを備えており、 前記比較ステップが、複数のサーバ・ベース書式の１つがクライアント・ベー ス書式と同一であると前記判定ステップが判定した場合に、複数のサーバ・ベー ス書式のうちクライアント・ベース書式と同一のものである１つを利用する請求 項１に記載の方法。 ５．第２のアプリケーションからの要求に応じて第１のアプリケーションからの データ・ストリームによってサーバ・キャッシュ項目を更新するステップと、 第２のアプリケーションからの要求に対応しており、かつ連続するサーバ・キ ャッシュ項目間の差を表している複数の差分データ・セットを維持して、アーカ イブ差分データを提供するステップと、 前記複数の差分データ・セットの１つと関連づけられ、前 記差分データ・セットが導かれたサーバ・ベース書式を一意に識別する複数のＣ ＲＣ項目を維持するステップとをさらに含み、 前記問い合わせステップが複数の差分データ・セットとＣＲＣとが第２のアプ リケーションからの要求に対応して存在しているかどうかを判定し、 前記複数のＣＲＣの１つがクライアント・ベース書式と同一のものであるサー バ・ベース書式に対応しているかどうかを判定するステップを備えており、 前記送信ステップがクライアント・ベース書式に対応しているＣＲＣに対応し たアーカイブ差分データ、連続したアーカイブ差分データ・セット、および前記 比較ステップによって計算された差分データを外部通信リンクによって第２のコ ンピュータに送るステップを備えており、 前記再構成ステップがクライアント・ベース書式を外部通信リンクによって受 信した差分データと連続的に組み合わせて、インタセプトされた応答に対応する 応答データ・ストリームを作成することによって、外部通信リンクによって受信 したデータ・ストリームから第１のアプリケーションからの通信に対応した応答 データ・ストリームを再構成するステップを備えており、 第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目 を再構成したデータ・ストリームによって更新する、請求項１に記載の方法。 ６．第１のアプリケーションがウェブ・サーバを含み、かつ第２のアプリケーシ ョンがウェブ・ブラウザを含むことを特徴とする請求項１に記載の方法。 ７．外部通信リンクが無線通信リンクを含むことを特徴とする請求項１に記載の 方法。 ８．ウェブ・ブラウザからの要求がＣＧＩ要求を含んでいる、請求項６に記載の 方法。 ９．第１のコンピュータに常駐している第１のアプリケーションから第２のコン ピュータに常駐している第２のアプリケーションへ、第１のコンピュータから第 ２のコンピュータへの外部通信リンクによって伝送されるデータを少なくする装 置において、 第２のアプリケーションからの要求に応じて第２のアプリケーションに与えら れる第１のアプリケーションからのデータ・ストリームを第１のコンピュータに 常駐しているキャッシュに格納して、サーバ・ベース・キャッシュ項目を作成す る手段と、 第２のアプリケーションからの要求に応じて第２のアプリケーションに与えら れるデータ・ストリームを第２のコンピュータに常駐しているキャッシュに格納 して、クライアント・ベース・キャッシュ項目を作成する手段と、 第２のアプリケーションからの要求を評価して、問い合わせを受けた要求に対 応するクライアント・ベース・キャッシュ項目が存在していて、クライアント・ ベース書式を与える かどうかを判断する手段と、 第２のアプリケーションからの要求に問い合わせを行って、問い合わせを受け た要求に対応するサーバ・ベース・キャッシュ項目が存在していて、サーバ・ベ ース書式を与えるかどうかを判断する手段と、 第２のアプリケーションからの問い合わせを受けた要求に応じて第１のアプリ ケーションが発信した応答に対応するデータ・ストリームをインタセプトしてか ら、外部通信リンク上での応答の伝送を行う手段と、 インタセプトされた応答をサーバ・ベース書式と比較して、インタセプトされ た応答とサーバ・ベース書式との間の差分に対応した差分データを与える手段と 、 差分データを外部通信リンクによって第２のコンピュータへ送る手段と、第１ のコンピュータによって送られた、 外部通信リンクによって伝送される差分データを取得する手段と、 クライアント・ベース書式を外部通信リンクから受信した差分データと組み合 わせて、インタセプトされた応答に対応している応答データ・ストリームを作成 することにより、外部通信リンクから受信したクライアント／サーバ固有データ ・ストリームから、第１のアプリケーションからの通信に対応した応答データ・ ストリームを再構成する手段と、 インタセプトされた応答に対応する再構成したデータ・ストリームを第２のア プリケーションに与える手段と を備えている装置。 １０．サーバ・ベース書式がクライアント・ベース書式と同一であるかどうかを 判定する手段をさらに含み、 前記送信手段がサーバ・ベース書式を送信する手段と、前記判定手段がサーバ ・ベース書式がクライアント・ベース書式と同一ではないと判定した場合に、差 分データを外部通信リンクによって第２のコンピュータへ送信する手段とを備え ており、 前記再構成手段が外部通信リンクによって受信したサーバ・ベース書式を、外 部通信リンクによって受信した差分データと組み合わせて、インタセプトされた 応答に対応するデータ・ストリームを作成することにより、第１のアプリケーシ ョンからの応答に対応したインタセプトされた応答データ・ストリームを再構成 し、 受信したサーバ・ベース書式を問い合わせを受けた要求に対応するクライアン ト・ベース・キャッシュ項目として格納することによって、問い合わせを受けた 要求に対応するクライアント・ベース書式を更新する手段を備えている、請求項 ９に記載の装置。 １１．サーバ・ベース書式とインタセプトされた応答の間の差が事前定義差分閾 値よりも大きいかどうかを判定する手段と、 サーバ・ベース書式とインタセプトされた応答の間の差が事前定義差分閾値よ りも大きい場合に、インタセプトされた 要求に対応するサーバ・ベース・キャッシュ項目として第１のアプリケーション から受信したインタセプトされた応答のデータ・ストリームを格納することによ って問い合わせを受けた要求に対応するサーバ・ベース書式を更新する手段とを さらに備えており、 前記比較手段と前記送信手段とが更新されたサーバ・ベース書式を利用する、 請求項９に記載の装置。 １２．第２のアプリケーションからの要求に対応する複数のサーバ・ベース・キ ャッシュ項目を維持する手段をさらに含み、 前記問い合わせ手段が複数のサーバ・ベース・キャッシュ項目が第２のアプリ ケーションからの要求に対応して存在していて、複数のサーバ・ベース書式を提 供するかどうかを判定し、 複数のサーバ・ベース書式の１つがクライアント・ベース書式と同一であるか どうかを判定する手段を備えており、 前記比較手段が、複数のサーバ・ベース書式の１つがクライアント・ベース書 式と同一であると前記判定手段が判定した場合に、複数のサーバ・ベース書式の うちクライアント・ベース書式と同一のものである１つを利用する請求項９に記 載の装置。 １３．第２のアプリケーションからの要求に応じて第１のアプリケーションから のデータ・ストリームによってサーバ・キャッシュ項目を更新する手段と、 第２のアプリケーションからの要求に対応しており、かつ連続するサーバ・キ ャッシュ項目間の差を表している複数の差分データ・セットを維持して、アーカ イブ差分データを提供する手段と、 前記複数の差分データ・セットの１つと関連づけられ、前記差分データ・セッ トが導かれたサーバ・ベース書式を一意に識別する複数のＣＲＣ項目を維持する 手段とをさらに含み、 前記問い合わせ手段が複数の差分データ・セットとＣＲＣとが第２のアプリケ ーションからの要求に対応して存在しているかどうかを判定し、 前記複数のＣＲＣの１つがクライアント・ベース書式と同一のものであるサー バ・ベース書式に対応しているかどうかを判定する手段を備えており、 前記送信手段がクライアント・ベース書式に対応しているＣＲＣに対応したア ーカイブ差分データ、連続したアーカイブ差分データ・セット、および前記比較 ステップによって計算された差分データを外部通信リンクによって第２のコンピ ュータに送る手段を備えており、 前記再構成手段がクライアント・ベース書式を外部通信リンクによって受信し た差分データと連続的に組み合わせて、インタセプトされた応答に対応する応答 データ・ストリームを作成することによって、外部通信リンクによって受信した データ・ストリームから第１のアプリケーションからの通信に対応した応答デー タ・ストリームを再構成する手段を備え ており、 第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目 を再構成したデータ・ストリームによって更新する、請求項９に記載の装置。 １４．第１のアプリケーションがウェブ・サーバを含み、かつ第２のアプリケー ションがウェブ・ブラウザを含むことを特徴とする請求項９に記載の装置。 １５．外部通信リンクが無線通信リンクを含むことを特徴とする請求項９に記載 の装置。 １６．ウェブ・ブラウザからの要求がＣＧＩ要求を含んでいる、請求項１４に記 載の装置。 １７．第１のコンピュータに常駐している第１のアプリケーションから第２のコ ンピュータに常駐している第２のアプリケーションへ第２のアプリケーションか らの要求に応じて、第１のコンピュータから第２のコンピュータへの外部通信リ ンクによって伝送されるデータを少なくするコンピュータ・プログラム・プロダ クトにおいて、 コンピュータ可読プログラム・コード手段が内部に埋め込まれているコンピュ ータ可読格納媒体を備えており、前記コンピュータ可読プログラム・コード手段 が、 第２のアプリケーションからの要求に応じて第２のアプリケーションに与えら れる第１のアプリケーションからのデータ・ストリームを第１のコンピュータに 常駐しているキャッシュに格納して、サーバ・ベース・キャッシュ項目を作成す るコンピュータ可読プログラム・コード手段と、 第２のアプリケーションからの要求に応じて第２のアプリケーションに与えら れるデータ・ストリームを第２のコンピュータに常駐しているキャッシュに格納 して、クライアント・ベース・キャッシュ項目を作成するコンピュータ可読プロ グラム・コード手段と、 第２のアプリケーションからの要求を評価して、問い合わせを受けた要求に対 応するクライアント・ベース・キャッシュ項目が存在していて、クライアント・ ベース書式を与えるかどうかを判断するコンピュータ可読プログラム・コード手 段と、 第２のアプリケーションからの要求に問い合わせを行って、問い合わせを受け た要求に対応するサーバ・ベース・キャッシュ項目が存在していて、サーバ・ベ ース書式を与えるかどうかを判断するコンピュータ可読プログラム・コード手段 と、 第２のアプリケーションからの問い合わせを受けた要求に応じて第１のアプリ ケーションが発信した応答に対応するデータ・ストリームをインタセプトしてか ら、外部通信リンク上での応答の伝送を行うコンピュータ可読プログラム・コー ド手段と、 インタセプトされた応答をサーバ・ベース書式と比較して、インタセプトされ た応答とサーバ・ベース書式との間の差分に対応した差分データを与えるコンピ ュータ可読プログラム・コード手段と、 差分データを外部通信リンクによって第２のコンピュータへ送るコンピュータ 可読プログラム・コード手段と、 第１のコンピュータによって送られた、外部通信リンクによって伝送される差 分データを取得するコンピュータ可読プログラム・コード手段と、 クライアント・ベース書式を外部通信リンクから受信した差分データと組み合 わせて、インタセプトされた応答に対応している応答データ・ストリームを作成 することにより、外部通信リンクから受信したクライアント／サーバ固有データ ・ストリームから、第１のアプリケーションからの通信に対応した応答データ・ ストリームを再構成するコンピュータ可読プログラム・コード手段と、 インタセプトされた応答に対応する再構成したデータ・ストリームを第２のア プリケーションに与えるコンピュータ可読プログラム・コード手段と を備えているコンピュータ可読プログラム・プロダクト。 １８．サーバ・ベース書式がクライアント・ベース書式と同一であるかどうかを 判定するコンピュータ可読プログラム・コード手段をさらに含み、 前記送信用コンピュータ可読プログラム・コード手段がサーバ・ベース書式を 送信するコンピュータ可読プログラム・コード手段と、前記判定用コンピュータ 可読プログラム・コード手段がサーバ・ベース書式がクライアント・ベース書式 と同一ではないと判定した場合に、差分データを外部通信リ ンクによって第２のコンピュータへ送信するコンピュータ可読プログラム・コー ド手段とを備えており、 前記再構成用コンピュータ可読プログラム・コード手段が外部通信リンクによ って受信したサーバ・ベース書式を、外部通信リンクによって受信した差分デー タと組み合わせて、インタセプトされた応答に対応するデータ・ストリームを作 成することにより、第１のアプリケーションからの応答に対応したインタセプト された応答データを再構成し、 受信したサーバ・ベース書式を問い合わせを受けた要求に対応するクライアン ト・ベース・キャッシュ項目として格納することによって、問い合わせを受けた 要求に対応するクライアント・ベース書式を更新するコンピュータ可読プログラ ム・コード手段を備えている、請求項１７に記載のコンピュータ・プログラム・ プロダクト。 １９．サーバ・ベース書式とインタセプトされた応答の間の差が事前定義差分閾 値よりも大きいかどうかを判定するコンピュータ可読プログラム・コード手段と 、 サーバ・ベース書式とインタセプトされた応答の間の差が事前定義差分閾値よ りも大きい場合に、インタセプトされた応答に対応するサーバ・ベース・キャッ シュ項目として第１のアプリケーションから受信したインタセプトされた応答の データ・ストリームを格納することによって問い合わせを受けた要求に対応する サーバ・ベース書式を更新するコンピュータ可読プログラム・コード手段とをさ らに備えており、 前記比較用コンピュータ可読プログラム・コード手段と前記送信用コンピュー タ可読プログラム・コード手段とが更新されたサーバ・ベース書式を利用する、 請求項１７に記載のコンピュータ・プログラム・プロダクト。 ２０．第２のアプリケーションからの要求に対応する複数のサーバ・ベース・キ ャッシュ項目を維持するコンピュータ可読プログラム・コード手段をさらに含み 、 前記問い合わせ用コンピュータ可読プログラム・コード手段が複数のサーバ・ ベース・キャッシュ項目が第２のアプリケーションからの要求に対応して存在し ていて、複数のサーバ・ベース書式を提供するかどうかを判定し、 複数のサーバ・ベース書式の１つがクライアント・ベース書式と同一であるか どうかを判定するコンピュータ可読プログラム・コード手段を備えており、 前記比較用コンピュータ可読プログラム・コード手段が、複数のサーバ・ベー ス書式の１つがクライアント・ベース書式と同一であると前記判定用コンピュー タ可読プログラム・コード手段が判定した場合に、複数のサーバ・ベース書式の うちクライアント・ベース書式と同一のものである１つを利用する請求項１７に 記載のコンピュータ・プログラム・プロダクト。 ２１．第２のアプリケーションからの要求に応じて第１のアプリケーションから のデータ・ストリームによってサーバ・キャッシュ項目を更新するコンピュータ 可読プログラム・コ ード手段と、 第２のアプリケーションからの要求に対応しており、かつ連続するサーバ・キ ャッシュ項目間の差を表している複数の差分データ・セットを維持して、アーカ イブ差分データを提供するコンピュータ可読プログラム・コード手段と、 前記複数の差分データ・セットの１つと関連づけられ、前記差分データ・セッ トが導かれたサーバ・ベース書式を一意に識別する複数のＣＲＣ項目を維持する コンピュータ可読プログラム・コード手段とをさらに含み、 前記問い合わせ用コンピュータ可読プログラム・コード手段が複数の差分デー タ・セットとＣＲＣとが第２のアプリケーションからの要求に対応して存在して いるかどうかを判定し、 前記複数のＣＲＣの１つがクライアント・ベース書式と同一のものであるサー バ・ベース書式に対応しているかどうかを判定するコンピュータ可読プログラム ・コード手段を備えており、 前記送信用コンピュータ可読プログラム・コード手段がクライアント・ベース 書式に対応しているＣＲＣに対応したアーカイブ差分データ、連続したアーカイ ブ差分データ・セット、および前記比較用コンピュータ可読プログラム・コード 手段によって計算された差分データを外部通信リンクによって第２のコンピュー タに送るコンピュータ可読プログラム・コード手段を備えており、 前記再構成手段がクライアント・ベース書式を外部通信リンクによって受信し た差分データと連続的に組み合わせて、インタセプトされた応答に対応する応答 データ・ストリームを作成することによって、外部通信リンクによって受信した データ・ストリームから第１のアプリケーションからの通信に対応した応答デー タ・ストリームを再構成するコンピュータ可読プログラム・コード手段を備えて おり、 第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目 を再構成したデータ・ストリームによって更新する、請求項１７に記載のコンピ ュータ・プログラム・プロダクト。 ２２．第１のアプリケーションがウェブ・サーバを含んでおり、第２のアプリケ ーションがウェブ・ブラウザを含んでいる、請求項１７に記載のコンピュータ・ プログラム・プロダクト。 ２３．外部通信リンクが無線通信リンクを含んでいる、請求項１７に記載のコン ピュータ・プログラム・プロダクト。 ２４．ウェブ・ブラウザからの要求がＣＧＩ要求を含んでいる、請求項２２に記 載のコンピュータ・プログラム・プロダクト。