JP2004342069A - データ・キャッシュ方法およびデータ・キャッシュ装置 - Google Patents

Abstract

【課題】キャッシュデータの不必要な更新を必要とせずに信頼できるデータをもたらすキャッシュシステムを提供する。
【解決手段】第１のアプリケーションから受信し第２のアプリケーションに送るべきデータ・ストリームをキャッシュ内に格納して、第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目を生成する。また、クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目時間記録を生成する。第２のアプリケーションからの要求に対応してクライアント・キャッシュ項目のクライアント・キャッシュ項目時間記録を評価し、第２のアプリケーションがその情報を要求する前に第２のアプリケーションからの要求のクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成された場合、要求に応答してクライアント・キャッシュ項目を第２のアプリケーションに供給する。
【選択図】図２

Description

本発明は、キャッシュ構造および方法に関する。具体的には、本発明は、一方のコンピュータがクライアント・アプリケーションを稼働させ、他方のコンピュータがサーバ・アプリケーションを稼働させている２台のコンピュータ間の低速通信または無線通信リンクを介した通信を有するシステム内で有用なキャッシュ構造および方法に関する。

最近、「情報スーパーハイウェイ」に関して宣伝され、重要視されていることにより、マスコミュニケーション媒体としてのインターネットがますます知られ、受け入れられるようになってきた。複数のネットワークにまたがる通信と対話のための実現可能な媒体としてインターネットがこのように広く認識されるようになったことにより、コンピュータ・ネットワーク間の対話のためのインターネット標準化プロトコルに基づく大規模なユーザ基盤も確立されている。

インターネットのパラダイムは、インターネット・クライアント（ブラウザ）がインターネット・サーバと通信するクライアント−サーバ関係のパラダイムである。インターネットへのアクセスを拡大するために、クライアントとサーバが使用する通信プロトコルと言語が標準化されるようになった。これらのプロトコルには、クライアントとサーバの間の通信に使用される通信プロトコルであるハイパーテキスト転送プロトコル（ＨＴＴＰ）と、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）がある。ＴＣＰ／ＩＰのＴＣＰ部分は、コンピュータ間またはアプリケーション間の通信のためのトランスポート固有のプロトコルである。クライアントとサーバが通信する言語も標準化されており、これはハイパーテキスト・マークアップ言語（ＨＴＭＬ）と呼ばれる。これらのプロトコルと言語は機械から独立しており、コネクションレスの最善のプロトコルを使用して情報を送信し、各トランザクションは完全に自己完結している。したがって、たとえば、クライアントからの各メッセージにはブラウザの機能に関する情報が含まれ、通信を完結させるために他のどの通信からも独立している。クライアントとサーバの間の通信のこの自己完結性は「ステートレス」通信と呼ばれることがあり、これは所与の通信のためにクライアントとサーバの間で伝送しなければならないデータの量を増大させる。

ワールド・ワイド・ウェブのクライアント／サーバ・アプリケーションの関連では、ユーザ・インタフェースとして機能するウェブ・ブラウザがクライアントであろう。ウェブ・ブラウザは適切なウェブ・サーバにユーザ要求を送り、ウェブ・サーバから返されたＨＴＭＬデータのフォーマットと表示を行う。また、ウェブ・ブラウザはＨＴＭＬデータを評価して、ブラウザが発行する後続のブラウザ要求を必要とすることになるハイパーリンク・ステートメントがＨＴＭＬデータに埋め込まれていないかどうかを判断する。ウェブ・サーバはクライアントのためのサーバの役割を果たし、ウェブ・ブラウザ要求を処理し、要求された応答をＨＴＴＰデータ・ストリームのＨＴＭＬデータ部分として返す。

典型的なワールド・ワイド・ウェブ通信の例として、ウェブ・ブラウザがウェブ・サーバに対して「ホーム・ページ」を求める要求を出す事例を用いて、ＨＴＴＰとＨＴＭＬとＴＣＰとウェブ・ブラウザとウェブ・サーバとの間の基本的な関係を例示する。ウェブ・ブラウザのユーザが特定のウェブ・サイトに対して情報を要求すると、ウェブ・ブラウザはウェブ・サーバに所望のウェブ・サイト（この例では「ホーム・ページ」）のユニバーサル・リソース・ロケータ（ＵＲＬ）を指定する「ｇｅｔ」要求を送ることによって、ウェブ・サーバの通信を開始する。ＵＲＬはウェブ・サイトのアドレスの役割を果たし、インターネット全体を通じて固有である。次にウェブ・サーバは、ＵＲＬで指定されたホーム・ページに対応するＨＴＭＬデータを入手してウェブ・ブラウザに供給する。この操作には、インターネット・ウェブ・サーバによるインターネット上での通信がさらに必要となったり、ブラウザが接続しているローカル・ネットワーク内にあるサーバをＵＲＬによって指定する必要がある場合がある。次にウェブ・ブラウザはウェブ・サーバからＨＴＴＰデータ・ストリームとして受け取ったＨＴＭＬデータを評価して、アイコンやイメージなどのハイパーリンクが埋め込まれていないかどうかを調べ、そのようなハイパーリンクがある場合は、そのハイパーリンクのＵＲＬを指定する要求を出して、指定されたデータを入手する。このデータはホーム・ページに組み込まれ、ユーザに対して表示されることになる。この単純な例でわかるように、ウェブ・ブラウザによる１つのユーザ入力要求の結果、ユーザ要求に対応するＨＴＭＬデータの受信に応答してウェブ・ブラウザが自動的に複数の追加の要求を行うことになる。

インターネット・ベースのシステムの基本的な通信構造を第１図に示す。第１図では、ウェブ・ブラウザ１０が通信リンク１５を介してウェブ・サーバ２０と通信する。この通信リンクは典型的にはローカル・エリア・ネットワーク接続、ワイド・エリア・ネットワーク接続、電話回線による接続、またはその組合せである。ウェブ・ブラウザ１０はＴＣＰ／ＩＰを使用してウェブ・サーバ２０と通信する。インターネット通信では一般に、ウェブ・ブラウザは、ウェブ・ブラウザとウェブ・サーバの間のＴＣＰ／ＩＰリンクを介してウェブ・ブラウザとウェブ・サーバの間で伝送される汎用通信プロトコルＨＴＴＰを使用して、ウェブ・サーバと通信する。ウェブ・ブラウザ１０とウェブ・サーバ２０の間で伝送される実データは前述のＨＴＴＰデータ・オブジェクト（たとえばＨＴＭＬデータ）である。ウェブ・サーバ２０はいくつかのウェブ・ブラウザからウェブ・ブラウザ通信を受け取り、それらを適切なサーバにルーティングするプロキシとすることもできる。

ウェブ・ブラウザ／ウェブ・サーバと、それらの共通の情報とトランスポート・プロトコルであるＨＴＭＬとＨＴＴＰの普及によって、ウェブ技法が情報へのネットワーク・アクセスのための汎用インタフェースとして急速に受け入れられるようになった。さらに、ウェブ・ブラウザとウェブ・サーバの間の通信のためのプロトコルと言語が標準化されているため、ユーザがネットワーク情報にアクセスするためのウェブ・ブラウザとしてＮｅｔｓｃａｐｅ ＮａｖｉｇａｔｏｒＴＭ、ＮＣＳＡ、ＭｏｓａｉｃＴＭ、ＷｅｂＥｘｐｌｏｒｅｒＴＭ、または他のどのブラウザを使用するかを問わず、通信プロトコルおよび言語は同じになる。したがって、ウェブ・ブラウザの大規模なインストール済みユーザ基盤と、インタフェースの接続性と、ＨＴＴＰ定義の共通ゲートウェイ・インタフェース（ＣＧＩ）を使用したウェブ・アプリケーション・サーバの作成の容易さとが組合わさって、ウェブ技法を大規模なクラスの書式ベース・アプリケーションにとってきわめて魅力的なものにしている。

インタフェースの普及と受け入れの拡大と同時に、移動体コンピューティングも普及している。ラップトップ、ノートブック、パーソナル・ディジタル／通信アシスタント（ＰＤＡ／ＰＣＡ）およびその他の携帯用装置の使用によって、無線通信の需要が増大している。しかし、無線ワイド・エリア・ネットワーク、セルラ通信、およびパケット無線には、ウェブの環境で使用した場合に共通の制約がある。１バイト当たりの高い通信コストと、遅い応答時間と、低帯域幅と、信頼性のなさはすべて、ワールド・ワイド・ウェブのステートレス通信プロトコルに無線技法を使用するのを阻害している。また、ウェブ・プロトコルはステートレスであるため、１要求当たりのデータ量と無線接続を介して伝送される通信要求の数は、通信が自己完結型でない場合に必要となる量と数よりも大きい。したがって、無線技法またはいずれかの低速通信技法をウェブ技法と組み合わせることは、ウェブ技法の汎用的性質の強さによって無線技法の弱点がさらにひどくなるため実際的ではないと思われる。

ウェブ・クライアント／サーバ環境内で無線通信を使用する欠点の他に、従来のキャッシュ技法はまた、用途がごく限られている。ウェブ・サーバから受信したキャッシュ・データをリフレッシュすると、ウェブ環境内で使用したときに信頼性およびアベイラビリティの問題が起こる。例えば、ウェブ・ブラウザの新しいインスタンスを開始するたびにキャッシュ・データをリフレッシュする場合、その情報がウェブ・ブラウザの特定のインスタンス中に使用されなければ、多数の不必要なブラウザ要求が発生する。キャッシュ・データをリフレッシュしない場合、キャッシュ内のデータは信頼できなくなる。

上記の制限事項に関して、本発明の１つの目的は、キャッシュ・データの不必要な更新を必要とせずに信頼できるデータをもたらすキャッシュ・システムを提供することである。

本発明の追加の目的は、ウェブ・ブラウザ／サーバ環境内で使用できるキャッシュ構造を提供することである。

本発明の他の目的は、ウェブ・ブラウザ・アプリケーションまたはウェブ・サーバ・アプリケーションを修正する必要なしに低速通信または無線通信システム内で既存の通信プロトコルおよび言語に適合できるようにすることである。

本発明の追加の目的は、ウェブ・ブラウザとウェブ・サーバの間で必要な通信の量を少なくし、それにより通信システムのパフォーマンスを向上させるキャッシュ方法を提供することである。

上記その他の目的に関して、本発明は、第１のアプリケーションから受信し、第２のアプリケーションからの要求に応答して第２のアプリケーションに送るべきデータをキャッシュする方法を提供する。本方法は、第１のアプリケーションから受信しかつ第２のアプリケーションに送るべきデータ・ストリームをキャッシュ内に格納して、第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目を生成するステップを含む。また、クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目時間記録を生成する。要求に対応するクライアント・キャッシュ項目が存在するかどうかを判定するために、第２のアプリケーションからの要求を検査する。要求に対応するクライアント・キャッシュ項目が存在する場合、第２のアプリケーションがその情報を要求する前に第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するために、第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目のクライアント・キャッシュ項目時間記録を評価する。第２のアプリケーションがその情報を要求する前にクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成された場合、要求に応答してクライアント・キャッシュ項目を第２のアプリケーションに供給する。本発明の代替実施形態では、第２のアプリケーションの複数のインスタンス間でクライアント・キャッシュ項目を維持する。

本発明の他の実施形態では、第１のアプリケーションは第１のコンピュータ内に常駐し、第２のアプリケーションは第２のコンピュータ内に常駐し、第１のアプリケーションと第２のアプリケーションは、さらに外部通信リンクを介して互いに通信する。この代替実施形態では、本発明は、第２のアプリケーションからの要求に応答して、第１のアプリケーションからのデータ・ストリームを第１のコンピュータ内に常駐するキャッシュ内に格納して、サーバ要求キャッシュ項目を生成する。要求に対応するサーバ要求キャッシュ項目が前にキャッシュ内に格納されていたかどうかを判定するために、第２のアプリケーションが発生した要求を評価する。次いで、第２のアプリケーションからの要求に対応するサーバ要求キャッシュ項目を外部通信リンクを介して第２のコンピュータ内に常駐する第２のアプリケーションに送る。

本発明の追加の代替実施形態では、第１のコンピュータは、第１のコンピュータがその要求を受信する前に、第２のアプリケーションからの要求に対応するサーバ要求キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定する。サーバ要求キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成された場合、第２のアプリケーションからの要求に対応するサーバ要求キャッシュ項目を第２のコンピュータに送る。

本発明の代替実施形態はまた、要求に対応するサーバ・キャッシュ項目と同一である第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目が存在するかどうかを判定するステップを含む。第１のコンピュータが第２のアプリケーションからの要求を受信した時間と、第２のアプリケーションからの要求に対応するサーバ要求キャッシュ項目が生成された時間との間の時間間隔を計算して、項目エージ・データをもたらす。第２のアプリケーションからの要求に対応するサーバ・キャッシュ項目の項目エージ・データを第２のコンピュータ内に常駐する第２のアプリケーションに送信し、第１のコンピュータから受信した項目エージ・データを第２のコンピュータの現在時間から減じることによって、第２のアプリケーションからの要求に対応するクライアント・キャッシュ項目時間記録を更新する。

本発明の追加の実施形態では、第２のアプリケーションはウェブ・ブラウザであり、第１のアプリケーションはウェブ・サーバであり、他の実施形態では、第１のコンピュータと第２のコンピュータは無線通信リンクを介して通信する。

当業者ならわかるように、本発明の前述の態様は装置またはコンピュータ可読プログラム手段としても提供することができる。

以下に、本発明の好ましい実施例が図示されている添付図面を参照しながら本発明について詳述する。しかし、本発明は多くの異なる態様で実施することができ、本明細書に記載の実施例に限定されるものと解釈してはならない。これらの実施例は、本開示を綿密かつ十全なものとし、本発明の範囲を当業者に完全に伝えるために示すものである。全体を通じて同様の番号は同様の要素を指す。

第３図ないし第１２図と第１５図ないし第２１図は、本発明による方法およびシステムを示すフローチャートである。フローチャートの各ブロックと、フローチャートのブロックの組合せは、コンピュータ・プログラム命令によって実施することができることがわかるであろう。これらのコンピュータ・プログラム命令は、コンピュータまたはその他のプログラム式装置にロードし、それによってコンピュータまたはその他のプログラム式装置上で実行される命令がフローチャートの１つまたは複数のブロックに指定されている機能を実施する手段を生じさせるように機械を作り出すことができる。これらのコンピュータ・プログラム命令を、コンピュータまたはその他のプログラム式装置に対して特定の方式で機能するように指示することができるコンピュータ可読メモリに格納し、それによってコンピュータ可読メモリに格納された命令がフローチャートの１つまたは複数のブロックに指定されている機能を実施する命令手段を含む製品を作り出すようにすることができる。また、コンピュータ・プログラム命令をコンピュータまたはその他のプログラム式装置にロードして、コンピュータまたはその他のプログラム式装置上で一連の操作ステップが行われるようにし、コンピュータまたはその他のプログラム式装置上で実行される命令がフローチャートの１つまたは複数のブロックに指定されている機能を実施するステップを提供するようにコンピュータ実施プロセスを作り出すこともできる。

したがって、フローチャートのブロックは、指定された機能を実行する手段の組合せと、指定された機能を実行するステップの組合せとに対応する。また、フローチャートの各ブロックと、フローチャートのブロックの組合せは、指定された機能またはステップを実行する特定用途向けハードウェア・ベースのコンピュータ・システムによって、または特定用途向けハードウェアとコンピュータ命令の組合せによって実施することができることがわかるであろう。

第２図に、本発明の一実施例を示す。第２図に示すように、ウェブ・ブラウザ１０はクライアント側インタセプト・モジュール３０と通信する。ウェブ・サーバ２０はサーバ側インタセプト・モジュール４０と通信する。次にクライアント側インタセプト・モジュール３０が通信リンク３５を介してサーバ側インタセプト・モジュール４０と通信する。ウェブ・ブラウザ１０とクライアント側インタセプト・モジュール３０は、第１のコンピュータ５に組み込むことができる。サーバ側インタセプト・モジュール４０とウェブ・サーバ２０は第２のコンピュータ６に組み込むことができる。第１のコンピュータ５と第２のコンピュータ６は外部通信リンク３５を介して通信する。

ウェブ・ブラウザ１０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）とハイパーテキスト・マークアップ言語（ＨＴＭＬ）を使用して、やはりＨＴＴＰとＨＴＭＬを使用するインターネット・ウェブ・サーバ２０と通信するインターネット・ウェブ・ブラウザであることが好ましい。動作中、ウェブ・ブラウザ１０はＨＴＴＰデータ・ストリームを出力し、それがクライアント側インタセプト・モジュール３０によってインタセプトされる。クライアント側インタセプト・モジュール３０によるＨＴＴＰデータ・ストリームのインタセプトは、クライアント側インタセプト・モジュール３０が１２７．０．０．１のようなネットワーク番号１２７を有するＩＰアドレスにあるＴＣＰ／ＩＰループバック機構を使用して行うことができる。次に、クライアント側インタセプト・モジュール３０はＨＴＴＰデータ・ストリームをクライアント／サーバ固有プロトコルに変換または変形し、そのクライアント／サーバ固有データ・ストリームを外部通信リンク３５に送る。サーバ側インタセプト・モジュール４０はこのクライアント／サーバ固有データ・ストリームを受け取り、ウェブ・ブラウザ発信通信に対応する元のＨＴＴＰデータ・ストリームを再構築する。この再構築されたＨＴＴＰデータ・ストリームは次にウェブ・サーバ２０に転送される。ウェブ・サーバ２０はインターネット・ウェブ・サーバの通常の方式でＨＴＴＰデータ・ストリームに応答する。当業者ならわかるように、ウェブ・サーバ２０は複数のブラウザがインターネットに接続することができるようにするプロキシとすることもできる。

たとえば特定のＵＲＬホーム・ページを求めるブラウザ要求に応答してウェブ・サーバ２０がウェブ・ブラウザ１０に送る情報を受け取ると、ウェブ・サーバ２０はウェブ・ブラウザ１０に送る通信に対応するＨＴＴＰデータ・ストリームを出力する。このウェブ・サーバ発信通信はサーバ側インタセプト・モジュール４０によってインタセプトされ、クライアント／サーバ固有データ・ストリームに変換される。次に、ウェブ・サーバ発信通信に対応するクライアント／サーバ固有データ・ストリームは外部通信リンク３５で第２のコンピュータから第１のコンピュータに送られる。このクライアント／サーバ固有データ・ストリームをクライアント側インタセプト・モジュール３０が受け取り、ウェブ・サーバ発信通信に対応するＨＴＴＰデータ・ストリームが再構築され、ウェブ・ブラウザ１０に供給される。

本発明の特定の実施例では、外部通信リンク３５は無線通信リンクである。その場合、ユーザにとって受容可能なシステム・パフォーマンスを得るために、外部通信リンク３５を介する通信量を、通信リンク３５を介して伝送しなければならない通信の頻度と情報量の両方について減らすことが望ましい。したがって、本発明はキャッシング技法と、差分計算技法と、プロトコル縮小技法とを使用して、外部通信リンク３５を介する必要通信量を最小限にする。これらの技法は、ＨＴＴＰのステートレスまたは確率論的プロトコルを、クライアントおよびサーバに固有の情報を使用するクライアント／サーバ固有プロトコルに変換して通信の量と頻度を減らすことによって実現される。

本発明について、単一のウェブ・ブラウザ・アプリケーションと単一のウェブ・サーバ・アプリケーションに関して説明するが、当業者ならわかるように、本発明の利便および利点は、単一のウェブ・サーバに関連づけられた複数のウェブ・ブラウザを使用した場合にも得ることができる。したがって、本発明の方法、装置、およびプログラム製品は、各ブラウザがクライアント側インタセプト・モジュールと通信する複数のブラウザと共に使用することもでき、その場合それらのクライアント側インタセプト・モジュールはウェブ・サーバまたはウェブ・プロキシのサーバ側インタセプト・モジュールと通信することになる。

本発明の一実施例では、クライアント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール４０の両方がキャッシュ格納機能を有する。第１のコンピュータにあるクライアント・キャッシュには、ウェブ・ブラウザ発信通信に応答してウェブ・ブラウザが受け取るＨＴＴＰデータ・ストリームが格納される。第２のコンピュータにあるサーバ・キャッシュには、ブラウザ発信通信に応答してウェブ・サーバから受け取るＨＴＴＰデータ・ストリームが格納される。

当業者ならわかるように、第１のコンピュータまたは第２のコンピュータにあるキャッシュは、コンピュータの特定のハードウェア構成に基づく任意の容量とすることができる。これらのキャッシュには、各通信について、通信のＵＲＬ、巡回冗長検査（ＣＲＣ）などの通信内容に基づく固有識別子、キャッシュ項目の作成またはリフレッシュが行われた時刻を示すデータ格納時刻（ＳＤＴ）、および通信のデータを含む情報が格納される。したがって、キャッシュに格納されている各通信についてキャッシュ項目のディレクトリを作成することができる。さらに、所与のハードウェア構成で使用可能な資源は限られているため、第１のコンピュータおよび第２のコンピュータにあるキャッシュを維持するために当業者に周知の任意の数のキャッシング技法を使用することができる。したがって、たとえば、新しい項目の追加によってユーザ定義キャッシュサイズを超える場合、キャッシュは最も古いディレクトリ項目を無効化し、無効化された項目の代わりに新しい項目を追加することができる。さらに、ウェブ・ブラウザ・アプリケーションまたはウェブ・サーバ・アプリケーションの複数のインスタンスにわたって、あるいは第１または第２のコンピュータの電源投入サイクルについてさえもキャッシュ項目を維持して持続キャッシュを作成することができる。

以下に、クライアント側インタセプタ・モジュール３０とサーバ側インタセプト・モジュール４０の動作を示すフローチャートである第３図ないし第６図を参照しながら本発明の一態様によるキャッシング構造について説明する。

具体的に第３図を参照すると、ブロック１００はクライアント側インタセプト・モジュール３０がウェブ・ブラウザ１０から要求を受け取ったことを示している。この要求は、ＨＴＴＰデータ・ストリームの形式をとることができる。ブロック１０５に示すように、クライアント側インタセプト・モジュール３０は着信した要求のユニフォーム・リソース・ロケータ（ＵＲＬ）を検査する。クライアント側インタセプト・モジュール３０はＵＲＬから、ウェブ・ブラウザ発信要求に対応する情報が前に第１のコンピュータにある第１のクライアント・キャッシュに格納されているかどうかを判断する。

ＵＲＬに対応する情報が前にクライアント・キャッシュに格納されていなかった場合、ブロック１０６に示す操作がクライアント側インタセプト・モジュールによって行われる。クライアント側インタセプト・モジュール３０は外部通信リンク３５でサーバ側インタセプト・モジュール４０に要求を送る。

しかし、ブロック１０５に示すようにウェブ・ブラウザ発信通信に問い合わせたときに、ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目が存在する場合、最も単純な実施例では、その情報がＨＴＴＰデータ・ストリームとしてウェブ・ブラウザに供給される。しかし、第３図に示すように、本発明の好ましい実施例は、ウェブ・ブラウザ発信通信に対応するキャッシュ項目に対して本明細書でコヒーレンシ間隔検査と呼ぶ操作を行う。この操作は第３図のブロック１１０に示されている。

クライアント側インタセプト・モジュールのコヒーレンシ間隔はユーザ定義とすることができ、キャッシュ項目が陳腐化し、存在はしていてもウェブ・サーバに対してウェブ・ブラウザ発信通信に対応する情報を要求することによって最新化しなければならなくなるまでのキャッシュ項目が存在することができる時間の長さである。ブロック１１０に示すコヒーレンシ間隔検査は、現在日時をウェブ・ブラウザ発信通信に対応するキャッシュ項目のＳＤＴとユーザによって指定されたコヒーレンシ間隔との和と比較することによって行うことができる。現在日時がこの和より大きい場合、ウェブ・ブラウザ発信通信に対応するキャッシュ内に格納されている情報は陳腐化しており、ブロック１１０の「Ｎｏ」に分岐する。しかし、現在日時がＳＤＴにユーザ定義コヒーレンシ間隔を足した和よりも小さい場合は、ブロック１１０で「Ｙｅｓ」に分岐し、ブロック１１１に示すように、そのキャッシュ項目がＨＴＴＰデータ・ストリームとしてブラウザに供給される。したがって、第３図のブロック１００でクライアント側インタセプト・モジュール３０が受け取ったブラウザ発信通信が完了する。

ブロック１１０に示すコヒーレンシ間隔検査によって、第１のコンピュータにあるキャッシュ項目が陳腐化していると判断された場合、サーバ側インタセプト・モジュール４０に対して要求を行い、第２のコンピュータにあるキャッシュ項目のコヒーレンシを検査する。この操作は第３図のブロック１１２に示されている。これは、外部通信リンク３５を介してサーバ側インタセプト・モジュール４０に、特定のクライアント側インタセプト・モジュール３０のコヒーレンシ間隔と、ウェブ・ブラウザ１０によって発信されたＨＴＴＰ要求と、ウェブ・ブラウザ発信通信のＵＲＬに対応するクライアント・キャッシュの内容を示す固有の標識を供給することによって行われる。好ましい実施例では、この固有の標識はキャッシュ項目の巡回冗長検査（ＣＲＣ）である。

次に第５図を参照すると、外部通信リンク３５を介してクライアント側インタセプト・モジュール３０から受け取った情報に応答したサーバ側インタセプト・モジュール操作が示されている。サーバ側インタセプト・モジュール４０がクライアント側インタセプト・モジュールから要求を受け取ると、サーバ側インタセプト・モジュール４０は所定のクライアント・コヒーレンシ時間間隔と、クライアント・キャッシュ項目のＣＲＣ値と、ウェブ・ブラウザによって発信されたＨＴＴＰ要求を受け取る。この情報の受信は、第５図のブロック１２０に示されている。

クライアント側インタセプト・モジュール３０から情報を受け取った後、サーバ側インタセプト・モジュール４０は第２のコンピュータにあるそのサーバ・キャッシュを検査して、ウェブ・ブラウザによって発信されたＨＴＴＰ要求のＵＲＬに対応するサーバ・キャッシュ項目が存在するかどうかを判断する。ブロック１２５に示すようにウェブ・ブラウザ発信通信に問い合わせた後、サーバ側インタセプト・モジュール４０が、ウェブ・ブラウザ発信通信によって要求された情報に対応するキャッシュ項目が存在すると判断した場合、ブロック１２５で「Ｙｅｓ」分岐をとる。次に、サーバ側インタセプト・モジュール４０はＳＳＩモジュール４０の現在日時を、ウェブ・ブラウザ発信通信によって要求された情報に対応するサーバ・キャッシュ項目のＳＤＴとクライアント側インタセプト・モジュールから受け取った所定のクライアント・コヒーレンシ時間間隔との和と比較する。

現在日時がサーバ・キャッシュ項目のＳＤＴとコヒーレンシ間隔との和より小さい場合、第５図のブロック１３０の「Ｙｅｓ」経路をとる。次にサーバ側インタセプト・モジュール４０はサーバ・キャッシュ項目のＣＲＣとクライアント・キャッシュのＣＲＣとを比較して、その２つのキャッシュ項目が同じかどうかを判断する。２つのキャッシュ項目が同じ場合、ブロック１３５の「Ｙｅｓ」分岐をとり、ブロック１３６に示すように、「コヒーレント」応答がクライアント側インタセプト・モジュール３０に送られる。

ブロック１３５の条件で、ＣＲＣが等しくないと判断された場合、クライアント・キャッシュに入っている情報とサーバ・キャッシュに入っている情報は同じでなく、ブロック１３７に示すようにサーバ側インタセプト・モジュールは外部通信リンクを介して第１のコンピュータにサーバ・キャッシュ項目を送る。サーバ・キャッシュ項目をクライアント側インタセプト・モジュール３０に送信する際に、サーバ側インタセプト・モジュールはその項目を、サーバ・キャッシュ項目のＣＲＣと、サーバ・キャッシュ項目データと、サーバ・キャッシュ項目のエージとを含むクライアント固有通信プロトコルに変換する。サーバ・キャッシュ項目のエージは、現行日時からキャッシュ項目のＳＤＴを引くことによって計算する。

第５図に関して最後に、ＳＤＴに所定のクライアント・コヒーレンシ時間間隔を足した和が現在日時よりも小さいか、またはウェブ・ブラウザ発信通信のＵＲＬに対応する項目がない場合、それぞれブロック１３０の「Ｎｏ」経路またはブロック１２５の「Ｎｏ」経路がとられる。したがって、ブロック１２６の操作が行われ、サーバ側インタセプト・モジュール４０がサーバにウェブ・ブラウザ発信通信をＨＴＴＰデータ・ストリームとして送ることになる。サーバ側インタセプト・モジュール４０がウェブ・ブラウザ発信通信をサーバにＨＴＴＰデータ・ストリームとして送らなければならない場合、サーバ側インタセプト・モジュール４０は第６図の操作を実行する。

第６図のブロック１４０に示すように、ウェブ・ブラウザ発信通信に応答して、サーバ側インタセプト・モジュールがウェブ・サーバ２０からＨＴＴＰデータ・ストリームを受け取る。ＨＴＴＰデータ・ストリームを受け取ると、サーバ側インタセプト・モジュール４０はＨＴＴＰデータ・ストリームのＣＲＣを計算し、ＨＴＴＰデータ・ストリームを一時的に格納する。次に、ブロック１４５に示すように、サーバ側インタセプト・モジュールはＨＴＴＰデータ・ストリームに問い合わせて、ＨＴＴＰデータ・ストリームのＵＲＬに対応するサーバ・キャッシュ項目が存在するかどうかを判断する。そのような項目が存在しない場合、ブロック１４５の「Ｙｅｓ」経路が実行される。次にサーバ側インタセプト・モジュール４０は、ブロック１５０に示すように、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームの最も最近に計算されたＣＲＣを、ウェブ・サーバ発信応答通信のＵＲＬに対応するサーバ・キャッシュ項目のＣＲＣと比較する。ＣＲＣが同じ場合、ブロック１５０の「Ｙｅｓ」分岐が行われる。サーバ側インタセプト・モジュール４０はブロック１５１に示すようにサーバ・キャッシュ項目のＳＤＴ項目を更新し、ブロック１５２に示すようにウェブ・サーバ２０によって受信されたＨＴＴＰデータ・ストリームを一時格納域から除去する。

ＣＲＣ比較の結果によって、サーバ・キャッシュ項目がウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームと異なることが示された場合、ブロック１５０の「Ｎｏ」経路が行われる。サーバ側インタセプト・モジュール４０はブロック１５３に示すようにサーバ・キャッシュから既存のデータを除去し、次にブロック１５４に示すようにより新しい方の情報によってサーバ・キャッシュを更新する。ブロック１５４に示すように、この更新にはサーバ・キャッシュにウェブ・サーバ通信のＣＲＣを格納するステップと、キャッシュ項目の一部として現在日時をキャッシュ項目のＳＤＴとして格納するステップと、ＨＴＴＰデータ・ストリームを格納するステップとが含まれる。サーバ・キャッシュ項目を更新するかどうか、またはサーバ・キャッシュ項目がウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームと同じであることが判明したかどうかを問わず、いずれの場合もサーバ側インタセプト・モジュールは次にサーバ・キャッシュ項目がウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目と同じかどうかを判断する。この操作をブロック１５５に示す。

サーバ側インタセプト・モジュール４０が、ウェブ・サーバ２０から受け取った応答に対応するキャッシュ項目が存在しないと判断した場合、ブロック１４５の「Ｎｏ」経路がとられる。ブロック１４６に示すように、ウェブ・サーバからの応答のＵＲＬを格納し、ウェブ・サーバからの応答のＣＲＣを格納し、ＨＴＴＰデータ・ストリームを格納し、ＳＤＴとして現在日時を格納することによって、サーバ・キャッシュ項目が作成される。ウェブ・ブラウザ発信通信に対応するキャッシュ項目を作成した後、サーバ側インタセプト・モジュール４０は次に、ブロック１５５に示すように、再度、このサーバ・キャッシュ項目のＣＲＣを対応するクライアント・キャッシュのＣＲＣと比較する。

サーバ・キャッシュ項目とクライアント・キャッシュ項目との比較の結果によって、キャッシュ項目が同じであることがわかった場合、ブロック１５５の「Ｙｅｓ」分岐がとられ、ブロック１５６の操作が行われる。ブロック１５６に示すように、サーバ側インタセプト・モジュール４０がクライアント側インタセプト・モジュール３０に応答を送る。サーバ側インタセプト・モジュール４０は、クライアント側インタセプト・モジュールにコヒーレント応答を送り、ゼロのエージを送ることによって、サーバ要求キャッシュ項目をクライアント／サーバ固有データ・ストリームに変形する。

サーバ側インタセプト・モジュール４０が、クライアント・キャッシュ項目がウェブ・ブラウザ発信通信に対応するサーバ・キャッシュ項目と同じではないと判断した場合、ブロック１５５の「Ｎｏ」分岐がとられ、ブロック１５７の操作が行われる。ブロック１５７に示すように、サーバ側インタセプト・モジュール４０は、サーバ・キャッシュ項目をクライアント／サーバ固有データ・ストリームに変換または変形する。このデータ・ストリームには、サーバ・キャッシュ項目のＣＲＣと、サーバ・キャッシュ項目ＨＴＴＰデータ・ストリームと、キャッシュ項目のゼロに設定されたエージとが含まれる。このクライアント／サーバ固有通信は次に外部通信リンク３５を介してクライアント側インタセプト・モジュール３０に送信される。

サーバ側インタセプト・モジュールから通信を受け取ったときのクライアント側インタセプト・モジュール３０の機能について、第４図を参照しながら以下に説明する。ブロック１６０に示すように、クライアント側インタセプト・モジュール３０は外部通信リンク３５を介して送信されたクライアント／サーバ固有データ・ストリームを受信または入手する。クライアント側インタセプト・モジュールは次に、ブロック１６５に示すように、サーバ側インタセプト・モジュール４０からどのようなタイプの応答を受け取ったかを判断する。サーバ側インタセプト・モジュール４０が、クライアントがクライアント・キャッシュ項目がコヒーレントであること、すなわちサーバ・キャッシュ項目とクライアント・キャッシュ項目が同じであることを示している場合、ブロック１６６に示す操作が行われる。ブロック１６６に示すように、クライアント側インタセプト・モジュール３０は、現在日時とサーバ側インタセプト・モジュール４０から受け取ったエージとの差を使用してウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目のＳＤＴを更新する。したがって、本発明は、第１のコンピュータ５と第２のコンピュータ６の２つのクロックの同期をとらずに、第１のコンピュータのキャッシュ項目のコヒーレンシ時間を更新して第２のコンピュータの新しい方のデータを反映させたことになる。ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目のＳＤＴを更新した後、クライアント側インタセプト・モジュール３０はクライアント・キャッシュ項目をウェブ・ブラウザ１０にＨＴＴＰデータ・ストリームとして転送する。この操作をブロック１７４に示す。

しかし、クライアント側インタセプト・モジュール３０が応答のタイプがデータまたはデータ・ストリーム応答であると判断した場合は、ブロック１６５から「ストリーム」経路をとり、ブロック１６７の操作が行われる。クライアント側インタセプト・モジュール３０はＨＴＴＰデータ・ストリームを受け取り、そのデータを一時的に格納する。次に、第４図のブロック１７０に示すように、クライアント側インタセプト・モジュール３０は、ウェブ・ブラウザ発信通信に対応するキャッシュ項目が存在するかどうかを判断する。キャッシュ項目が存在する場合、ブロック１７０の「Ｙｅｓ」経路をとって、ブロック１７１に示すように、既存のキャッシュ項目がフラッシュされる。クライアント側インタセプト・モジュールは次に、サーバ側インタセプト・モジュール４０から受け取ったＨＴＴＰデータ・ストリームのＣＲＣを格納し、現在日時とサーバ側インタセプト・モジュール４０から受け取ったエージとの差をＳＤＴとして格納し、ＨＴＴＰデータ・ストリームを格納することによって、ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目を更新する。この操作をブロック１７２に示す。

ウェブ・ブラウザ発信通信に対応するキャッシュ項目が存在しない場合、ブロック１７０の「Ｎｏ」経路が取られる。ブロック１７３に示す操作を行うことによってクライアント・キャッシュ項目が作成される。ブロック１７３に示すように、クライアント側インタセプト・モジュール３０は、サーバ側インタセプト・モジュール４０から受け取ったＨＴＴＰデータ・ストリームのＵＲＬを格納し、サーバ側インタセプト・モジュール４０から受け取ったＨＴＴＰデータ・ストリームのＣＲＣを格納し、ＨＴＴＰデータ・ストリームを格納することによって、クライアント・キャッシュ項目を作成する。また、クライアント側インタセプト・モジュール３０は、サーバ側インタセプト・モジュール４０から外部通信リンク３５を介して受け取ったエージＳＤＴを現在日時から引くことによって、ＳＤＴを更新または格納する。

しかし、ブロック１６６、１７２、１７３のいずれの操作によってクライアント・キャッシュ項目が作成されるかを問わず、クライアント側インタセプト・モジュールはクライアント・キャッシュ項目をＨＴＴＰデータ・ストリームとしてウェブ・ブラウザ１０に転送または供給する。これらの操作は第４図のブロック１７４に示されている。

当業者ならわかるように、クライアント・キャッシュとサーバ・キャッシュは、メモリによって、またはハード・ディスク、読書きＣＤ−ＲＯＭ、光ディスク、その他の格納技法などの大容量格納装置によって実装することができる。さらに、当業者ならわかるように、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールは、ソフトウェア、ハードウェア、またはその組合せによって実装することができる。

特定の第１または第２のコンピュータにあるキャッシュについて言及したが、当業者ならわかるように、本発明の利点は、キャッシュが第１のコンピュータにではなく、単に外部通信リンクの第１のコンピュータと同じ側にある場合でも得られる。したがって、ハードウェア・キャッシュをクライアント・キャッシュとして機能する第１のコンピュータの外部に実装し、高速通信によって第１のコンピュータに接続することもでき、しかもその場合でも、キャッシュが外部通信リンクの第１のコンピュータと同じ側にある限り、本発明の利点が得られる。

本発明の他の実施例では、サーバ側インタセプト・モジュール４０は、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームのコピーを維持せず、単にその通信のディレクトリ項目を維持するに過ぎない。このディレクトリ項目には、通信のＵＲＬと、ＨＴＴＰデータ・ストリームのために計算されたＣＲＣと、ＨＴＴＰデータ・ストリームをウェブ・サーバから受け取った時刻と、その通信のＳＤＴとが含まれ、このＳＤＴはＣＲＣを計算した時刻に設定することができる。このような場合、クライアント側インタセプト・モジュール３０はサーバ側インタセプト・モジュール４０に対して、サーバ側インタセプト・モジュールがＣＲＣとＳＤＴを維持していたＵＲＬに対応する通信を求める要求を送り、次にサーバ側インタセプト・モジュール３０はクライアント側インタセプト・モジュール３０から受け取ったＣＲＣを検査して、それが指定されたＵＲＬの最新のＨＴＴＰデータ・ストリームに対応しているかどうかを判断する。一致している場合、クライアント側インタセプト・モジュールにコヒーレント応答が送られる。一致していない場合、サーバ側インタセプト・モジュールは、クライアント側インタセプト・モジュールから受け取ったＨＴＴＰデータ・ストリームをウェブ・サーバ２０に送り、ウェブ・サーバ２０から受け取った応答をクライアント側インタセプト・モジュール３０に返す。

第７図、第８図、第９図、第１０図、第１１図および第１２図に、本発明の他の態様においてクライアント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール４０によって行われる操作を示す。この態様は、差分計算を使用して、外部通信リンク３５を介して伝送されるデータを削減する。第７図を参照すると、ブロック２００にクライアント側インタセプト・モジュール３０によるウェブ・ブラウザ１０からのＨＴＴＰ要求の受信が示されている。ブロック２０５に示すように、クライアント側インタセプト・モジュール３０はウェブ・ブラウザ１０からのインタセプトしたＨＴＴＰ要求に問い合わせて、その要求が共通ゲートウェイ・インタフェース（ＣＧＩ）に送るものかどうかを判断する。要求が共通ゲート・インタフェースに送るものでない場合、クライアント側インタセプト・モジュール３０は、第３図ないし第６図に示し、第７図のブロック２０６に図示するように、その要求をサーバ側インタセプト・モジュールに渡す。

しかし、ウェブ・ブラウザ発信通信がＣＧＩ要求に対応する場合、ブロック２０５の「Ｙｅｓ」経路がとられる。ブロック２１０に示すように、クライアント／サーバ・インタセプト・モジュール３０は、対応するＣＧＩ要求に応答して前にウェブ・ブラウザに供給されていたＨＴＴＰデータ・ストリームに対応するクライアント・ベース・キャッシュ項目が存在するかどうかを判断する。このＣＧＩ要求の問い合わせは、ウェブ・ブラウザ発信通信のＵＲＬをクライアント・ベース・キャッシュに格納されているＵＲＬと比較することによって行うことができる。

クライアント・ベース・キャッシュは、所与のＵＲＬについてウェブ・ブラウザ１０に供給するクライアント側インタセプト・モジュール３０が受信した最初のＨＴＴＰデータ・ストリームを格納することによって初期設定することができる。このベース・キャッシュ項目は、ウェブ・ブラウザ１０の多くのインスタンスまたはセッションにわたって維持することができる。クライアント・ベース・キャッシュ項目は、第７図、第８図、第９図、第１０図、第１１図および第１２図に示すように更新することができる。ウェブ・ブラウザ発信通信のＵＲＬに対応するクライアント・ベース・キャッシュ項目が存在する場合、第７図のブロック２１１に示すように、外部通信リンク３５を介してサーバ側インタセプト・モジュール４０に送るＣＲＣが、クライアント・ベース・キャッシュ項目のＣＲＣに等しく設定される。クライアント・ベース・キャッシュ項目がない場合、第７図のブロック２１０から「Ｎｏ」経路をとり、外部通信リンク３５を介してサーバ側インタセプト・モジュール４０に送る要求のＣＲＣがナルにされる。この操作は第７図のブロック２１２に示されている。

ブロック２１３に、ＣＧＩ要求を外部通信リンクを介してサーバ側インタセプト・モジュール４０に送る操作を示す。ブロック２１３に示すように、クライアント側インタセプト・モジュール３０がＨＴＴＰ要求と要求ＣＲＣを送る。要求ＣＲＣは、ＣＧＩ要求のＵＲＬのクライアント・ベース・キャッシュ項目が存在しない場合にはナルに設定されており、クライアント・ベース・キャッシュ項目が存在する場合にはその項目のＣＲＣに設定されている。したがって、クライアント側インタセプト・モジュールは、ＣＧＩ要求をクライアント／サーバ固有プロトコルに変換し、そのクライアント／サーバ固有通信を外部通信リンクを介して送信して、サーバ側インタセプト・モジュール４０が受信するようにしたことになる。

ＣＧＩ要求を受け取るときのサーバ側インタセプト・モジュールの動作を第９図に示す。サーバ側インタセプト・モジュール４０によるＣＧＩ要求の受信がブロック２２０に示されている。サーバ側インタセプト・モジュール４０はＣＧＩ要求を受け取ると、ＣＲＣ値とＨＴＴＰ要求のコピーを保存する。ブロック２２１に示すように、サーバ側インタセプト・モジュール４０はＨＴＴＰ要求をウェブ・サーバ２０に渡す。

第１１図のブロック２３０に示すように、サーバ側インタセプト・モジュール４０がウェブ・ブラウザ発信通信またはＣＧＩ要求に対応するＨＴＴＰ要求に対する応答を受け取るとき、サーバ側インタセプト・モジュール４０はこの応答をＨＴＴＰデータ・ストリームとして受け取る。ブロック２３０に示すように、サーバ側インタセプト・モジュール４０は、ＨＴＴＰデータ・ストリームを保存し、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームのＣＲＣ値を計算する。また、サーバ側インタセプト・モジュール４０は、差分値をナルにして差分データを初期設定する。次に、ブロック２３５に示すように、サーバ側インタセプト・モジュールは、ウェブ・サーバ発信通信として受け取った応答がＣＧＩ要求に対する応答であるかどうかを判断する。答えが否定の場合、第１１図のブロック２３５から「Ｎｏ」経路をとり、ブロック２３６の操作を実行して、ＨＴＴＰデータ・ストリームがクライアント側インタセプト・モジュールに送る。ブロック２３６に示すように、この操作には第３図ないし第６図で説明したキャッシング操作が必要な場合がある。ブロック２３０で受け取った応答がＣＧＩに対する応答の場合、ブロック２３５の「Ｙｅｓ」経路をとり、サーバ側インタセプト・モジュールは次に、ブロック２４０に示すように、ＣＧＩ応答のサーバ・ベース・キャッシュ項目が存在するかどうかを判断する。

サーバ側インタセプト・モジュール４０がＣＧＩ要求に対する応答を初めて受け取ったとき、サーバ・ベース・キャッシュ項目を作成することができる。この場合、ブロック２４０に示す条件の結果によって、ブロック２４０から「Ｎｏ」経路がとられる。次に、サーバ側インタセプト・モジュール４０は、ＣＧＩのＵＲＬと、ＣＧＩ要求に対する応答のＨＴＴＰデータ・ストリームと、ＨＴＴＰデータ・ストリームのＣＲＣとを格納することによって、サーバ・ベース・キャッシュ項目を作成する。この操作をブロック２４１に示す。第３図ないし第６図で説明したコヒーレント・キャッシュとの互換性を持たせるために、サーバ・ベース・キャッシュ項目にはＳＤＴも組み込むことができる。本明細書では、サーバＣＧＩベース書式という用語を使用して、ウェブ・ブラウザ１０から受け取ったＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目を指す。

ＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目がある場合、ブロック２４０の「Ｙｅｓ」経路がとられる。サーバ側インタセプト・モジュールはサーバ・ベース・キャッシュ項目のＣＲＣを、ウェブ・サーバ２０から受け取った応答のＣＲＣと比較する。これらの操作を第１２図のブロック２４５に示す。ＣＲＣが同じ場合、サーバ側インタセプト・モジュールは、サーバ・ベース・キャッシュ項目のＣＲＣがクライアント・ベース・キャッシュ項目のＣＲＣに対応するかどうかを判断する。この２つのＣＲＣ値が同じ場合、クライアント・ベース・キャッシュ項目と、サーバ・ベース・キャッシュ項目と、ウェブ・サーバ２０から受け取った応答のすべてがＨＴＴＰデータ・ストリームに入れられる。サーバ・ベース・キャッシュ項目とクライアント・ベース・キャッシュ項目との比較をブロック２５０に示す。

２つのベース・キャッシュ項目が同じ場合、サーバ側インタセプト・モジュールはベース・キャッシュ項目をクライアント側インタセプト・モジュール３０に送る必要がなく、したがって、ブロック２５１に示すように、クライアント側インタセプト・モジュール３０に送るＨＴＴＰデータ・ストリーム・データをナルにする。次に、ブロック２５２に示すように、サーバ側インタセプト・モジュール４０は、ＣＧＩ要求に対応するサーバ・ベース・キャッシュに格納されているＨＴＴＰデータ・ストリームのＣＲＣと、ナルにしたＨＴＴＰデータ・ストリームと、ナルにした差分データとを送信して、ＣＧＩ要求がクライアント・ベース・キャッシュ項目と同じであったことを示すことによって、ウェブ・サーバ２０から受け取ったＨＴＴＰデータ・ストリームをクライアント／サーバ固有通信プロトコルに変換する。

ブロック２４５に戻って、ＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目のＣＲＣが、ウェブ・ブラウザによって発信されたＣＧＩ要求に応答してウェブ・サーバから受け取った応答のＣＲＣと異なる場合、ブロック２４５から「Ｎｏ」経路がとられる。次に、サーバ側インタセプト・モジュール４０はブロック２４６に示す操作を行う。サーバ側インタセプト・モジュール４０は、インタセプトしたＣＧＩ応答を、インタセプトしたＣＧＩに対応するサーバ・ベース・キャッシュ項目すなわちサーバＣＧＩベース書式と比較する。このインタセプトしたＣＧＩ応答とサーバＣＧＩベース書式との比較によって、インタセプトしたＣＧＩ応答とサーバＣＧＩベース書式との差分に対応するＣＧＩ差分データが得られる。

差分計算は、ベース書式と修正済み書式との間の差分を求める当業者に周知の任意の方法で行うことができる。本発明で使用するのに適した差分計算の一方法は、コピーターズ（Coppieters）による"Cross-Platform Binary Diff"（Dr. Dobb's Journal １９９５年５月号３２〜３６ページ）に記載されており、その開示は参照により、その全部が記載されているかのように本明細書に組み込まれる。差分データを求める際に使用することができるその他の方法には、"IBM Technical Disclosure Bulletin（Vol.22, No.8A、１９８０年１月）に記載されている方法が含まれ、これも参照によりその全部が記載されているかのように本明細書に組み込まれる。次に、ブロック２４７に示すように、サーバ側インタセプト・モジュール４０はサーバＣＧＩベース書式が更新を必要とするかどうかを判断する。この判断は、インタセプトされたＣＧＩ応答とサーバＣＧＩベース書式との平均差分データが所定のしきい値を超えているかどうかを判断することによって行うことができる。ＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目を更新する必要があるかどうかを判断する他の方法には、第３図ないし第６図で説明したような時間コヒーレンシ方式や、ベース変更を行って新しいベース・キャッシュ項目を作成すればシステム・パフォーマンスが向上するほど差分データが増加したかどうかを判断する当業者に周知のその他の方法が含まれる。

サーバのベース変更計算が不要な場合、ブロック２４７から「Ｎｏ」経路がとられ、サーバ側インタセプト・モジュール４０はブロック２５０の操作を行って、クライアント・ベース・キャッシュ項目のＣＲＣがサーバ・ベース・キャッシュ項目のＣＲＣと同じかどうか、またはサーバＣＧＩベース書式が、ウェブ・ブラウザ発信通信のその特定のＣＧＩ要求に対応するサーバとクライアントのベース・キャッシュ項目であるクライアントＣＧＩベース書式と同じかどうかを判断する。ベース書式が同じ場合、クライアントはベース変更を行う必要がなく、ブロック２５１に示すようにＨＴＴＰデータ・ストリーム情報がナルにされる。次に、サーバ側インタセプト・モジュール４０は、ＣＧＩ要求に対応するサーバ・ベース・キャッシュ項目のＣＲＣ（すなわちサーバＣＧＩベース書式のＣＲＣ）を送り、ベース・データに対応するナルにしたＨＴＴＰデータ・ストリームを送り、ブロック２４６で求めた差分データを送ることによって、クライアント側インタセプト・モジュール３０に差分応答を送る。これらの操作は第１２図のブロック２５２として示されている。

サーバ側インタセプト・モジュール４０が、クライアントＣＧＩベース書式とサーバＣＧＩベース書式のＣＲＳが同じでないと判断した場合、クライアントのベース変更計算を行う必要がある。クライアントのベース変更操作は、クライアント側インタセプト・モジュール３０にサーバＣＧＩベース書式を送るステップを含む。この操作を行うために、サーバ側インタセプト・モジュールはクライアント側インタセプト・モジュール３０に送るＨＴＴＰデータ・ストリーム・データを、サーバＣＧＩベース書式と等しく設定する。この操作をブロック２５３に示す。次に、サーバ側インタセプト・モジュール４０は、ブロック２５２に示すように、サーバＣＧＩベース書式のＣＲＣと、サーバＣＧＩベース書式に対応するＨＴＴＰデータ・ストリーム・データを送信し、ＣＧＩベース書式とウェブ・サーバから受け取った応答との差分データを送信することによって、ウェブ・サーバから受け取ったＨＴＴＰデータ・ストリームをクライアント／サーバ固有プロトコルに変換する。次にこの情報を外部通信リンク３５を介してクライアント側インタセプト・モジュール３０に送る。

ブロック２４７に戻って、サーバのベース変更が必要な場合、ブロック２４７から「Ｙｅｓ」経路がとられる。ブロック２４８に示すように、サーバ側インタセプト・モジュールは、ウェブ・サーバから受け取ったＨＴＴＰデータ・ストリームを使用してブラウザ発信通信に対応するサーバ・ベース・キャッシュを更新する。応答のＣＲＣも更新され、ＣＧＩ差分データがナルにされる。次に、サーバ側インタセプト・モジュールは、ブロック２５０に示すように新しいサーバ側キャッシュ項目のＣＲＣを比較し、前述のようにこの転送を完了する。

サーバ側インタセプト・モジュール４０から応答を受け取ったときのクライアント側インタセプト・モジュールの操作を第８図に示す。クライアント側インタセプト・モジュール３０によるサーバ側インタセプト・モジュール４０からの応答の受信は、ブロック２６０に示されている。ブロック２６５に示すように、クライアント側インタセプト・モジュール３０は、応答がＣＧＩ要求に対する応答かどうかを判断する。応答がＣＧＩ要求に対する応答ではない場合、クライアント側インタセプト・モジュールはブロック２６７の操作を行う。この操作には、第３図ないし第６図に示すキャッシュ操作を組み込むことができる。しかし、応答がＣＧＩ要求に対する応答の場合、ブロック２６５から「Ｙｅｓ」経路がとられる。クライアント側インタセプト・モジュール３０は、外部通信リンクを介して送信されたクライアント／サーバ固有データ・ストリームから入手した、ＨＴＴＰデータ・ストリーム・データと、差分データと、ＣＲＣとを保管する。これらの操作は第８図のブロック２６６に示されている。

次に、クライアント側インタセプト・モジュール３０は、ＣＧＩベース書式を含むインタセプトされたＣＧＩ要求に対応するクライアント・ベース・キャッシュ項目が存在するかどうかを判断する。この問い合わせはブロック２７０に示されており、ＨＴＴＰ要求またはＨＴＴＰ応答のＵＲＬを調べることによって行うことができる。クライアントＣＧＩベース書式が存在する場合、ブロック２７０から「Ｙｅｓ」経路がとられる。次に、ブロック２７５に示すように、クライアント側インタセプト・モジュール３０は外部通信リンクを介して受け取ったＣＲＣを、クライアントＣＧＩベース書式のＣＲＣと比較する。ＣＲＣが異なる場合、ブロック２７５から「Ｎｏ」経路がとられ、クライアントは、ウェブ・ブラウザ発信通信のＣＧＩ要求のＵＲＬに対応するクライアント・ベース・キャッシュ項目を、外部通信リンク３５を介してサーバ側インタセプト・モジュール４０から受け取ったＨＴＴＰデータ・ストリーム・データに置き換えてＣＧＩベース書式を更新することによって、ベース変更を行う。クライアント・ベース・キャッシュ項目も、ＨＴＴＰデータ・ストリームのＣＲＣを基準にして更新される。これらの操作は第８図のブロック２７６に示されている。

外部通信リンク３５を介して受け取ったＣＲＣがＧＧＩベース書式と同じ場合、サーバ側インタセプタ・モジュール・サーバＣＧＩベース書式は、クライアント側インタセプト・モジュール・クライアントＣＧＩベース書式と同じであり、ブロック２７５の「Ｙｅｓ」経路がとられる。

ベース書式が同じであるかクライアントをベース変更するかを問わず、クライアント側インタセプタ・モジュール３０によってブロック２７７に示す操作が行われる。ブロック２７７は、クライアント側インタセプタ・モジュール３０が、クライアントＣＧＩベース書式を外部通信リンク３５を介して受け取ったＣＧＩ差分データと比較して、インタセプトしたＣＧＩ応答に対応するＨＴＴＰデータ・ストリームを作成することによって、外部通信リンク３５を介して受け取ったクライアント／サーバ固有データ・ストリームから、ウェブ・サーバ２０から受け取った通信に対応するＨＴＴＰデータ・ストリームを再構築する操作を示す。ブロック２７８に示すように、この応答は次にＨＴＴＰデータ・ストリームとしてウェブ・ブラウザ１０に供給される。

クライアントにＣＧＩ要求のＵＲＬに対応するＣＧＩベース書式が存在しない場合、第８図のブロック２７０から「Ｎｏ」経路がとられる。ブロック２７１に示すように、クライアント側インタセプト・モジュール３０は、ＵＲＬと、サーバ側インタセプト・モジュール４０から外部通信リンクを介して受信したＨＴＴＰデータ・ストリームのＣＲＣと、実ＨＴＴＰデータ・ストリーム・データとを格納することによってＣＧＩ要求のＵＲＬに対応するクライアント・ベース・キャッシュ項目を作成する。この情報を格納することによって、インタセプトされたＣＧＩ要求に対応するクライアント・ベース・キャッシュ項目が作成され、したがってクライアントＣＧＩベース書式が作成される。次に、クライアント側インタセプト・モジュールは、クライアントＣＧＩベース書式をＣＧＩ差分データ（ナル化されていることがある）と結合またはマージすることによって、ＨＴＴＰデータ・ストリームを再構築することでブロック２７７の操作を行う。

本発明の差分計算技法は非ＣＧＩデータにも適用可能である。その場合、サーバ側インタセプト・モジュール４０は、ウェブ・サーバに接続されているウェブ・ブラウザのクライアント側インタセプト・モジュールが異なるベース書式を持っている可能性を見込んで、複数の世代のサーバ・ベース・キャッシュ項目を維持する必要がある。その場合、サーバ側インタセプト・モジュールは、一致するものが得られるまで、クライアント側インタセプト・モジュールから受け取ったＣＲＣを各世代のサーバ・ベース書式のＣＲＣと比較する。その際、サーバ側インタセプト・モジュール４０は、任意選択でクライアント側インタセプト・モジュール３０のベース変更を行うか、または単にクライアント側インタセプト・モジュール３０に差分データを供給することができる。したがって、本明細書でＣＧＩ要求に関して説明した差分計算方法は、どのようなＨＴＴＰ要求および応答にも等しく適用可能である。

複数の世代のベース書式を維持する上述のシステムでは、非ＣＧＩ要求について差分計算を使用することができるが、この方法はメモリまたは格納域を多用し、前述のキャッシング機能が十分に活用されない。メモリまたは格納域必要量を少なくし、前述のキャッシング方法を活用するために、非ＣＧＩ要求に差分計算を使用する以下の好ましい方法を使用することできる。この好ましい実施態様では、サーバ側インタセプト・モジュールは、要求に対応するサーバ・ベース書式とウェブ・サーバからの応答のＨＴＴＰデータ・ストリームとの差分を計算する。次に、ベース書式をウェブ・サーバからの新しい応答で置き換えることによって、サーバ・ベース書式を更新する。これにはベース書式のＣＲＣの更新も含まれる。しかし、古いＣＲＣを廃棄するのではなく、前のベース書式のＣＲＣは差分データとして格納する。次に、前の世代の差分データとＣＲＣを、非ＣＧＩ要求に対応するクライアント・ベースのＣＲＣに基づいて選択的にクライアント側インタセプト・モジュールに送る。

非ＣＧＩ差分計算方法の一例として、サーバ側インタセプト・モジュールが非ＣＧＩ要求を受け取った場合、その要求には非ＣＧＩ要求のＵＲＬに対応するクライアント側インタセプト・モジュールにあるベース書式のＣＲＣも付随していることになる。サーバ側インタセプト・モジュールは、ウェブ・サーバから応答を受け取ると、その応答のＣＲＣを計算する。次に、サーバ側インタセプト・モジュールは応答とＵＲＬのサーバ・ベース書式との差分を計算し、その差分データを保管する。サーバ側インタセプト・モジュールは、応答データを使用してサーバ・ベース書式を更新し、前のベース書式のＣＲＣと、応答と古いベース書式との間の差分データとをアーカイブする。次に、サーバ側インタセプト・モジュールは、クライアント・ベース書式のＣＲＣをサーバ・ベース書式のＣＲＣおよび格納またはアーカイブされているＣＲＣと比較し、一致しているものがあるかどうかを判断する。一致が見つからない場合、その応答は単にクライアント側インタセプト・モジュールに送られる。

一致が見つかった場合、一致するＣＲＣに対応する差分データと、それ以降の、現行差分データを含む現行差分データまでの差分データがクライアント側インタセプト・モジュールに送られる。クライアント側インタセプト・モジュールは、その差分データをクライアント・ベース書式に適用して応答を再構築する。したがって、３世代古いベース書式のＣＲＣについてＣＲＣ一致があった場合、３セットの差分データがクライアント側インタセプト・モジュールに送られることになり、３セットの連続した差分データをクライアント・ベース書式に適用することによって、応答の構築が行われることになる。しかし、応答を再構築するのに必要な差分データ・セットの数が多すぎるかまたは差分データ・セットの大きさが大き過ぎて、実応答を送信した方がデータ転送が少なくて済む場合、サーバ側インタセプト・モジュールは応答自体を送信することができる。いずれにしても、応答の再構築または受信の後、クライアント側インタセプト・モジュールは、要求のＵＲＬのクライアント・ベース書式を応答データによって更新し、ＣＲＣを要求のＣＲＣで更新する。クライアント・ベース書式は特定のＵＲＬについて応答を受信するたびに更新されるため、非ＣＧＩ要求に対して差分計算を使用した場合、上述のクライアント・キャッシュをクライアント・ベース書式のキャッシュとして使用することができ、それによってクライアント・ベース書式の別個のキャッシュを不要にすることができる。

本発明の他の態様では、ＨＴＴＰなどのステートレス通信プロトコルの冗長性に基づいて、通信をさらに節約することができる。そのようなプロトコルでは、クライアントは通信を開始するたびにクライアント自体に関する情報をサーバに送信する。同様に、サーバは応答を出すたびにサーバ自体に関する特定の情報をクライアントに伝達する。

本発明の一実施例では、第１のコンピュータ５は第２のコンピュータ６に、第１のコンピュータの事前定義特性に対応するコンピュータ固有情報を伝達する。第２のコンピュータはこのコンピュータ固有情報を格納する。次に、第１のコンピュータはそれ以降のウェブ・ブラウザ発信通信からそのコンピュータ固有情報を除去してから外部通信リンク３５で送信する。第２のコンピュータ６は、外部通信リンク３５を介して受信したそれ以降の通信と格納しているコンピュータ固有情報とを組み合わせてＨＴＴＰデータ・ストリームを作成することによって、元のウェブ・ブラウザ発信通信を再構築する。

ウェブ・ブラウザによって発信される通信からコンピュータ固有情報を除去するほかに、このコンピュータ固有情報をウェブ・サーバによって発信される通信からも除去することができる。その場合、第２図の第２のコンピュータ６は第１のコンピュータ５に外部通信リンク３５を介して、第２のコンピュータ６の事前定義特性に対応するコンピュータ固有情報を供給する。第１のコンピュータ５はそのコンピュータ固有情報を格納して、サーバ・ヘッダ情報を備える。その後の通信の時には、第２のコンピュータ６はウェブ・サーバ発信通信からコンピュータ固有情報を除去し、ウェブ・サーバ発信通信の残りの部分を外部通信リンク３５で送信する。第１のコンピュータ５は外部通信リンクでその通信を受信し、サーバ・ヘッダ情報を外部通信リンクを介して受信したクライアント／サーバ固有データ・ストリームと結合してＨＴＴＰデータ・ストリームを作成することによって、元のウェブ・サーバ発信通信を再構築する。どちらの場合も、操作が第１のコンピュータ５と第２のコンピュータ６のどちらで行われるかに応じて、コンピュータ固有情報を取り除き、その情報を格納してサーバ・ヘッダ情報またはクライアント・ヘッダ情報を作成する操作がクライアント側インタセプト・モジュール３０またはサーバ側インタセプト・モジュール４０によって行われる。

本発明の一実施例では、ウェブ・ブラウザ１０は伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）を使用してクライアント側インタセプト・モジュール３０と通信する。ＴＣＰは、外部通信リンク３５を介したクライアント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール４０との間の通信にも使用することができる。最後に、ＴＣＰはサーバ側インタセプト・モジュール４０とウェブ・サーバ２０との間の通信にも使用することができる。ＴＣＰは本発明のシステムを構成する様々な構成要素間の通信に使用することができるが、ＨＴＴＰプロトコルは外部通信リンクを介した通信にとって最も効率的な手段を提供するものではない。外部通信リンク３５のパフォーマンスを向上させるために、本発明の一実施例は本明細書で「仮想ソケット」と呼ぶものを作成する。これは、ウェブ・ブラウザとクライアント側インタセプト・モジュール３０の間の接続と、サーバ側インタセプト・モジュール４０とウェブ・サーバ２０との間の接続に使用される。これらの仮想ソケットの動作について、第１３図ないし第２５図を参照しながら以下に説明する。

第１３図は、仮想ソケットを使用する本発明の１つの可能な実施態様を示すブロック図である。第１３図に示すように、第１のコンピュータ５と第２のコンピュータ６は外部通信リンク３５を介して接続されている。ウェブ・ブラウザ１０は、ウェブ・ブラウザ１０をクライアント側インタセプト・モジュール３０と接続する複数の実ソケットを有する。第１３図に示すように、第１の実ソケットはウェブ・ブラウザ１０上に６５ａとして図示され、それに対応するソケットはクライアント側インタセプト・モジュール３０上の６５ｂである。この第１の実ソケットは、それを介してウェブ・ブラウザ１０がクライアント側インタセプト・モジュール３０に対してさらに接続を要求するＴＣＰソケットである。

ウェブ・ブラウザ１０が新しいＴＣＰ接続を要求すると、実ソケット６５ａを介して通信が行われ、それが実ソケット６５ｂによって受信される。次にクライアント側インタセプト・モジュール３０は、ウェブ・ブラウザ１０との通信のために別の実ソケットを作成する。第１３図に示すように、ウェブ・ブラウザ１０上で複数の実ソケットが作成され、それに対応する実ソケットがクライアント側インタセプト・モジュール３０上で作成される。これらの実ソケットは、ウェブ・ブラウザ１０上の６０ａ〜６４ａおよびクライアント側インタセプト・モジュール３０上の６０ｂ〜６４ｂとして図示されている。これらの実ソケットは、ウェブ・ブラウザ１０がそれを介してクライアント側インタセプト・モジュール３０と通信するための手段である。実ソケット６０ａ〜６４ａおよび６０ｂ〜６４ｂを作成した後、これらのソケットを介した通信を多重化して実ソケット３６ａに送り、実ソケット３６ａはクライアント側インタセプト・モジュール３０に外部通信リンク３５へのアクセスを提供する。実ソケット３６ａおよび３６ｂはコンピュータ５の実ソケット３７ａを介してコンピュータ６の実ソケット３７ｂに要求を送るときに作成される。実ソケット３７ｂが接続要求を受け取ると、実ソケット３６ａおよび３６ｂが作成される。ソケット３７ａおよび３７ｂは、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとの間の通信のための最初の実ソケットとして機能し、ソケット３６ａおよび３６ｂによって示されているこの２つのモジュールの間の接続を確立するためにのみ使用することができる。これらの実ソケットのそれぞれは標準ＴＣＰ／ＩＰプロトコルの下で動作する。第２のコンピュータ６が外部通信リンク３５を介して通信を受信するとき、それらの通信は実ソケット３６ｂで受信される。次にサーバ側インタセプト・モジュール４０は、ソケット３６ｂで受信した通信を多重化解除し、それらをウェブ・サーバ２０に送信するために適切なソケットに供給する。したがって、たとえば、特定のＵＲＬに対して情報を要求するためのソケット６０ａからソケット６０ｂまでの通信は、ソケット３６ａ上に多重化され、ソケット３６ｂによって受信され、サーバ側インタセプト・モジュール４０によって多重化解除され、ソケット６０ｃからウェブ・サーバ２０上のソケット６０ｄに送られることになる。同様に、ソケット６１ａを介して行われる通信はソケット６１ｂによって受信され、クライアント側インタセプト・モジュール３０によって多重化され、ソケット３６ａからソケット３６ｂに送られ、そこでサーバ側インタセプト・モジュール４０がその通信を多重化解除してソケット６１ｃからソケット６１ｄに送る。したがって、ソケット６０ａと６０ｂ、６１ａと６１ｂ、６２ａと６２ｂ、６３ａと６３ｂ、６４ａと６４ｂを介した通信は、サーバ側インタセプト・モジュール４０とウェブ・サーバ２０との間のソケット６０ｃと６０ｄ、６１ｃと６１ｄ、６２ｃと６２ｄ、６３ｃと６３ｄ、および６４ｃと６４ｄのうちのそれぞれの対応するソケットを介して送信される。

同様に、ウェブ・サーバ２０によるウェブ・ブラウザ１０からの要求に対する応答も、ウェブ・サーバ２０をサーバ側インタセプト・モジュール４０に接続するソケットを介して送られ、外部通信リンク３５を介してクライアント側インタセプト・モジュール３０に送られた後、ウェブ・ブラウザ１０に送られる。したがって、たとえばウェブ・サーバ２０によって発信された応答はソケット６０ｄから６０ｃを介して送られ、サーバ側インタセプト・モジュール４０によってソケット３６ｂに多重化され、そこから外部通信リンク３５を介してソケット３６ａに送られる。次にクライアント側インタセプト・モジュール３０がその通信を多重化解除し、それをソケット６０ｂに送り、それがウェブ・ブラウザ１０上のソケット６０ａに送られる。ウェブ・ブラウザ１０またはウェブ・サーバ２０が使用する各ソケットについて同様の通信経路が確立される。当業者ならわかるように、本発明についてウェブ・ブラウザ１０とウェブ・サーバ２０との間の４ソケット通信に関して説明したが、ウェブ・ブラウザ１０とウェブ・サーバ２０との間の通信アクセスを実現するために任意の数のソケットを開くことができる。

第１４図は、クライアント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール４０における仮想ソケット・システムの実施例を示すブロック図である。これらのモジュールの外部で、クライアント側インタセプト・モジュール３０とウェブ・ブラウザ１０およびサーバ側インタセプト・モジュール４０とウェブ・サーバ２０の間の実ソケットが、通常のＴＣＰ／ＩＰソケットとして機能する。したがって、仮想ソケットの使用はウェブ・ブラウザ１０およびウェブ・サーバ２０には透過である。

第１４図のブロック図と第１５図ないし第２５図の流れ図を参照しながら本発明の特定の実施例について説明する。第１５図ないし第１７図は、第１４図にブロック６８として図示されているソケット・マネージャのフローチャートである。第１６図を参照すると、ブロック３００はクライアント側インタセプト・モジュール３０の実ソケット・マネージャ６８の作成を示している。実ソケット・マネージャ６８が作成された後、実ソケット・マネージャは第１４図にソケット６５ｂとして図示されている第１の実ソケットを作成する。この第１の実ソケットの作成は第１６図のブロック３０１として示されている。第１の実ソケット６５ｂを作成した後、クライアント側インタセプト・モジュール３０内にあるソケット・マネージャ６８（本明細書ではクライアント・ソケット・マネージャとも呼ぶ）は、第１６図のブロック３０２に示すように、第１の実ソケット６５ｂ上での事象を待つ。第１の実ソケット６５ｂ上で事象を受け取ると、第１６図のブロック３０５に示すように実ソケット・マネージャ６８はその事象を検査し、その検査に基づいて５通りの経路のうちの１つをとる。

第１の実ソケット６５ｂで受信した通信要求に応答して実ソケットが作成された場合は、第１６図のブロック３０５から３０６までの経路に示すように、実ソケット・マネージャ６８はその実ソケットを実事象リストに追加する。次に、実ソケット・マネージャはブロック３０７に示すようにシンプレックス仮想ソケットを作成する。クライアント側インタセプト・モジュールの場合、実ソケット・マネージャは、第１６図のブロック３０８に示すように、作成された仮想ソケットについてクライアント側インタセプト・モジュールの機能を実行するアプリケーション機能を開始する。

本明細書では、「シンプレックス・ソケット」または「シンプレックス仮想ソケット」という用語は、単一のソケットまたは単一のアプリケーションに直接接続するソケットを指す。本明細書では、「マルチプレックスソケット」とは他の複数のソケットに接続するソケットを指す。したがって、マルチプレックスソケットは、多重化または多重化解除機能を実行し、シンプレックス・ソケットは１対１接続を行う。したがって、たとえば、第１６図のブロック３０６から３０８までの機能を実行する際、クライアント・ソケット・マネージャ６８は第１の実ソケット６５ｂが受信した第１の接続要求に応答して、実ソケット６０ｂ、シンプレックス仮想ソケット７０を作成し、アプリケーション８０のクライアント側インタセプト機能を開始することになる。実ソケットが作成されたその後の事象の場合も同様に、実ソケット・マネージャは実ソケット６１ｂ、６２ｂ、６３ｂ、または６４ｂとシンプレックス仮想ソケット７１、７２、７３、または７４を作成し、第１４図でブロック８１、８２、８３、または８４として図示されている、作成された実ソケットおよび仮想ソケットに対応するＣＳＩ機能を開始する。

以下に、クライアント側インタセプト機能の操作について、第１４図に示す実ソケット６０ｂとシンプレックス仮想ソケット７０とクライアント側インタセプト機能８０とを参照しながら説明する。第１８図のブロック３２５はクライアント側インタセプト機能８０の作成を示している。作成されると、クライアント側インタセプト機能８０はブロック３２６に示すようにシンプレックス仮想ソケット７０上の事象を待つ。この待機操作は、第２３図に示す仮想選択機能を実行することによって行われる。事象を受け取ると、ブロック３３０に示すようにその事象が検査される。事象が仮想ソケット閉鎖である場合、第１８図のブロック３４９に示すようにクライアント側インタセプト機能８０はシンプレックス仮想ソケット７０を削除し、ブロック３５０に示すように終了する。

事象がデータの受信である場合、ブロック３３０からブロック３３１への経路がとられ、クライアント側インタセプト機能８０は第２２図を参照しながら説明する仮想受信操作を実行することによって、シンプレックス仮想ソケット７０からブラウザ発信通信を受け取る。次に、クライアント側インタセプト機能は前述のクライアント側インタセプト・モジュールの機能（たとえば第３図および第７図を参照）を実行する。これはブロック３３２に示されている。次にクライアント側インタセプト機能８０は、クライアント側インタセプト・モジュール３０内の実ソケット３６ａに接続されるマルチプレックス仮想ソケット９０を作成する。実ソケット３６ａはサーバ側インタセプト・モジュール４０上の実ソケット３６ｂに接続される。マルチプレックス仮想ソケットの作成は、第１８図のブロック３３３に示されており、本明細書で第２０図を参照しながら説明する仮想作成操作を実行することによって行われる。ブロック３３４は、ウェブ・ブラウザ発信通信のためにクライアント側インタセプト機能８０が実行された後で、実ソケット６０ｂとシンプレックス仮想ソケット７０を介してウェブ・ブラウザから受け取った情報を送信する操作を示す。この通信は、第２１図を参照しながら説明する仮想送信操作を実行することによってマルチプレックス仮想ソケット９０の待ち行列に入れられる。クライアント側インタセプト機能８０は、要求をマルチプレックス仮想ソケット９０の待ち行列に入れた後、第１８図のブロック３３５に示すようにマルチプレックス仮想ソケット９０の待ち行列に入れられているデータをフラッシュし、次にブロック３３６に示すようにマルチプレックス仮想ソケット上の事象を待つ。仮想フラッシュ機能は、第２４図を参照しながら説明する仮想フラッシュ操作を実行することによって行われ、マルチプレックス仮想ソケット待ち行列からデータを取り出してそのデータを実ソケット３６ａに供給する。待機機能は、第２３図に示す仮想選択機能を実行することによって行うことができる。この時点で、クライアント側インタセプト・モジュールはウェブ・ブラウザ発信通信をインタセプトし、その通信を外部通信リンク３５を介してサーバ側インタセプト・モジュールに送信し終わったことになる。

第１６図に戻ると、サーバ側インタセプト・モジュール４０またはクライアント側インタセプト・モジュール３０におけるソケット・マネージャのフローチャートが示されている。第１４図のブロック６９に示すように、サーバ側インタセプト・モジュール内の実ソケット・マネージャ、すなわちサーバ・ソケット・マネージャは、ブロック６８に示すクライアント・ソケット・マネージャと同じ機能を実行する。ブロック３０１に示すように、第１の実ソケットを作成する際、サーバ側インタセプト・モジュール３０は、サーバ側インタセプト・モジュール４０に関連づけられたクライアント側インタセプト・モジュール３０からのソケットの要求を受け取る「周知のポート」３７ｂを作成する。サーバ側インタセプト・モジュール４０の実ソケット３６ｂ上で実事象が発生すると、ブロック３０５に示すようにその事象が検査される。この場合、この事象は実ソケット３６ａからのデータの受信であり、したがって第１６図のブロック３０５からブロック３２０までの経路がとられる。実ソケット３６ｂ上で受信したデータが検査され、この例ではデータはクライアント側インタセプト・モジュールによって送信されたウェブ・ブラウザ発信通信であるため、サーバ側インタセプト・モジュール４０において新しい仮想ソケットを作成しなければならない。したがって、第１６図のブロック３２０からブロック３２１への経路がとられる。次にサーバ・ソケット・マネージャ６９は、第１７図のブロック３２１、ブロック３２２、ブロック３２３、およびブロック３２４に示す操作を行う。サーバ・ソケット・マネージャ６９はブロック３２１に示すようにマルチプレックス仮想ソケット９５を作成し、ブロック３２２に示すようにマルチプレックスソケット活動タイマをキャンセルし、第１７図のブロック３２３と第１４図のブロック８５に示すサーバ側インタセプト機能のアプリケーションを開始する。実ソケット３６ｂで受け取ったデータは次にマルチプレックス仮想ソケット９５の待ち行列に入れられ、仮想事象が通知される。

ブロック３２３に示すサーバ側インタセプト機能の作成は、第１９図のブロック３６０に示されている。サーバ側インタセプト機能８５の作成後、この機能は、クライアント側インタセプト・モジュール３０から送信され、ウェブ・ブラウザ発信通信に対応するデータを、マルチプレックス仮想ソケット９５から受け取る。この操作は第１９図のブロック３６１に示されている。クライアント側インタセプト・モジュールからデータを受け取った後、サーバ側インタセプト機能８５は、そのデータを、サーバ側インタセプト・モジュールについて前述したように処理する。このサーバ側機能の実行はブロック３６２に示されている（たとえば第５図および第９図を参照）。情報を処理した後、サーバ側インタセプト機能８５は仮想作成を行うことによってシンプレックス仮想ソケット７５を作成する。この操作については本明細書で第２０図を参照しながら説明する。この操作は第１９図のブロック３６３に示されている。次に、サーバ側インタセプト機能８５は、仮想送信を行うことによって、ブロック３６４に示すようにウェブ・ブラウザ発信通信をシンプレックス仮想ソケット７５に送る。仮想送信の操作については本明細書で第２１図を参照しながら説明する。次に、サーバ側インタセプト機能８５は、仮想フラッシュを行ってシンプレックス仮想ソケット７５の待ち行列に入っているデータをソケット６０ｃにフラッシュし、シンプレックス仮想ソケット７５上の事象を待つ。仮想フラッシュ操作については本明細書で第２４図を参照しながら説明する。この送信操作とフラッシュ操作は第１９図のブロック３６４および３６５に示されている。待機操作は、第２３図で説明されている仮想選択機能を実行することによって行うことができる。サーバ側インタセプト機能８５がシンプレックス仮想ソケット７５を作成したとき、対応する実ソケット６０ｃも作成されている。サーバ側インタセプト機能８５は、ウェブ・ブラウザ発信通信をシンプレックス仮想ソケット７５に送信することによって、ウェブ・ブラウザ発信通信をウェブ・サーバに転送した。

サーバ側インタセプト・モジュール４０が実ソケット６０ｃ上でウェブ・サーバからの応答を受信すると、実事象が発生し、サーバ・ソケット・マネージャ６９は第１６図のブロック３０２を終了して、ブロック３０５に示すように実ソケット６０ｃ上で発生した事象を検査する。この事例の場合、これは既存の仮想ソケットのデータであり、第１６図ないし第１７図のブロック３２０からブロック３２４までの経路がとられる。実ソケット６０ｃ上で受信したデータは仮想ソケット７５の待ち行列に入れられ、仮想事象が通知される。仮想事象が通知されると、サーバ側インタセプト機能８５は第１９図のブロック３６６を終了し、ブロック３７０に示すようにその事象を検査する。事象がソケット閉鎖である場合、エラー条件が発生し、第１９図のブロック３７５に示すように応答としてエラー・メッセージが作成される。しかし、事象がデータの受信の場合は、ブロック３７０からブロック３７１への経路をとり、サーバ側インタセプト機能８５は、第２２図を参照しながら説明するように仮想受信を実行して、ブロック３７１に示すようにシンプレックス仮想ソケット７５から応答を入手する。次にサーバ側インタセプト機能８５は、ブロック３７２に示し、第２５図を参照しながら説明するように、シンプレックス仮想ソケット７５の仮想閉鎖を実行し、サーバ側インタセプト・モジュールに関して前述し、ブロック３７３に示すように、その応答を処理する（たとえば第６図および第１０図ないし第１２図を参照）。

第１９図のブロック３７０の終了経路がブロック３７５へのエラー経路であるかブロック３７１へのデータ経路であるかを問わず、ブロック３７４でシンプレックス仮想ソケット７５が削除される。次にサーバ側インタセプト機能は、ブロック３７６に示すようにマルチプレックス仮想ソケット９５への仮想送信操作を行ってウェブ・サーバ発信通信をクライアント側インタセプト・モジュール３０に送信する。サーバ側インタセプト機能８５は次に、仮想フラッシュ操作を行って、マルチプレックス仮想ソケット９５の待ち行列に入っているデータをフラッシュする。これらの操作はブロック３７７に示されている。次にサーバ側インタセプト機能８５は、第１９図のブロック３７８に示すように仮想閉鎖操作を行ってマルチプレックス仮想ソケット９５を閉じる。最後に、サーバ側インタセプト機能８５は、ブロック３７９および３８０に示すようにマルチプレックス仮想ソケットを削除して終了する。

サーバ側インタセプト機能は、マルチプレックス仮想ソケット９５への仮想送信操作とフラッシュ操作を行う。これらの操作によって、実ソケット３６ａ上で事象がトリガされ、クライアント・ソケット・マネージャ６８はブロック３０２を終了し、ブロック３０５に示すように事象を検査する。これは実ソケット３６ａでデータを受信し、第１６図のブロック３０５からブロック３２０までの経路がとられ、データがマルチプレックス仮想ソケット９０の待ち行列に入れられるためである。したがって、実ソケット３６ａが外部通信リンク３５を介して実ソケット３６ｂからウェブ・サーバ応答を受け取ると、その情報が多重化解除され、マルチプレックス仮想ソケットに供給される。データの受信によって、第１７図のブロック３２４に示すように仮想事象が発生し、第１８図のブロック３３６が終了してクライアント側インタセプト機能８０は第１８図のブロック３４０に示すようにその事象を検査することになる。

事象がソケット閉鎖応答である場合、第１８図のブロック３４０からブロック３４５への経路をとり、クライアント側インタセプト機能８０はエラー・メッセージ応答を作成して第１８図のブロック３４４に進む。この例の場合のように事象がデータ受信の場合、第１８図のブロック３４０からブロック３４１の経路をとり、クライアント側インタセプト機能８０は仮想受信操作を行ってマルチプレックス仮想ソケット９０から応答を受信する。この受信操作は第１８図のブロック３４１に示されている。マルチプレックス仮想ソケット９０からデータを受信した後、クライアント側インタセプト機能８０はブロック３４２に示すように仮想閉鎖操作を行ってマルチプレックス仮想ソケット９０を閉じる。次にクライアント側インタセプト機能８０は、ブロック３４３に示すように、クライアント側インタセプト・モジュールに関して前述したように応答を処理する（たとえば第４図および第８図を参照）。

ブロック３４０を終了してどちらの経路をとる場合も、ブロック３４４の操作が行われる。クライアント側インタセプト機能８０は、ブロック３４４に示すようにマルチプレックス仮想ソケットを削除し、次にブロック３４６に示すように仮想送信操作を行ってシンプレックス仮想ソケット７０を介してブラウザに応答を送信する。この仮想送信操作が完了すると、クライアント側インタセプト機能８０はブロック３４７に示すように仮想フラッシュ操作を行ってシンプレックス仮想ソケットの待ち行列に入っているデータを実ソケット６０ｂにフラッシュし、次にブロック３４８に示すように仮想閉鎖操作を行ってシンプレックス仮想ソケットを閉じる。クライアント側インタセプト機能のシンプレックス仮想ソケットを閉じた後、第１８図のブロック３４９および３５０に示すようにシンプレックス仮想ソケットが削除され、クライアント側インタセプト機能は終了する。

当業者ならわかるように、本発明についてシンプレックス仮想ソケットおよびマルチプレックス仮想ソケットとクライアント側インタセプト機能およびサーバ側インタセプト機能の１つの特定のインスタンスに関して説明したが、単一のクライアント側インタセプト・モジュールまたはサーバ側インタセプト・モジュール内でこれらの機能を複数作成することができる。したがって、本発明によるクライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールは、クライアント側インタセプト・モジュール３０とサーバ側インタセプト・モジュール４０との間にＴＣＰ／ＩＰ接続を作成し、次に、そのＴＣＰ／ＩＰ接続を維持しながらそのＴＣＰ／ＩＰ接続上で複数のウェブ・ブラウザ発信通信またはウェブ・サーバ発信通信を多重化することができる。

クライアント・ソケット・マネージャとサーバ・ソケット・マネージャの残りの機能は、第２０図ないし第２３図と第２４図および第２５図を参照すれば最もよく理解できよう。これらの図では、第１８図および第１９図のフローチャートに示されているように仮想作成、仮想送信、仮想受信、仮想選択、仮想フラッシュ、または仮想閉鎖操作を実行するときに、クライアント側インタセプト・モジュールおよびサーバ側インタセプト・モジュールによって行われる操作が説明されている。第１８図のブロック３３３および第１９図のブロック３６３に示すような仮想作成操作を行う場合、第２０図のブロック４００から始まる操作を行う。ブロック４０５に示すように、ソケット・マネージャは、実ソケットが必要かどうかを判断する。作成操作によって既存の実ソケットに接続するマルチプレックス仮想ソケットを作成する場合などのように、実ソケットがすでに存在する場合は、ブロック４０５から「Ｎｏ」経路をとり、ブロック４０９に示すようにその仮想ソケットが実ソケットに接続される。しかし、実ソケットが必要な場合は、ブロック４０５から「Ｙｅｓ」経路をとる。ブロック４０６に示すように実ソケットを作成する。次に、第１６図のブロック３０２に示す監視のために、ブロック４０８に示すようにその実ソケットを事象リストに追加する。実ソケットを作成し、接続を確立した後、ブロック４０９に示すように仮想ソケットを実ソケットに接続し、ブロック４１０に示すように作成操作が完了する。

第１８図のブロック３３４および３４６または第１９図のブロック３６４および３７６に示す仮想送信操作を行う場合、第２１図のブロック４２０から始まる操作が行われる。ブロック４２７に示すようにデータが仮想ソケット待ち行列に加えられ、完了すると、送信操作はブロック４２８に示すように終了する。

第１８図のブロック３３１および３４１と第１９図のブロック３６１および３７１に示す仮想受信操作は、第２２図のブロック４３０から始まる操作を行うことによって行われる。ブロック４３５に示すように、仮想ソケット待ち行列を調べて仮想ソケット待ち行列に何かデータが入っているか判断する。仮想ソケット待ち行列にデータがある場合、ブロック４３５の「Ｙｅｓ」経路をとり、ブロック４３６に示すように受信操作を呼び出した機能にそのデータが返される。仮想ソケット待ち行列にデータがなく、ソケットに閉鎖のマークが付けられていない場合、決定ブロック４４０の「Ｎｏ」経路をとり、ブロック４４１に示すように何も返されない。しかし、待ち行列にデータがなく、ソケットに閉鎖のマークが付けられている場合、ブロック４４０の「Ｙｅｓ」経路をとり、ブロック４４２に示すようにソケットに閉鎖のマークが付けられて、ブロック４４３に示すように、受信を要求する操作にソケット閉鎖応答が返される。

第１８図のブロック３２６および３３６と第１９図のブロック３６６で行われる仮想選択操作は、第２３図のブロック４４５から始まる操作を実行することによって行われる。ブロック４４６に示すように、まず、選択された仮想ソケットについてデータまたは仮想閉鎖操作が保留状態になっていないかどうかを判断する。保留状態のデータまたは仮想閉鎖がない場合、ブロック４４６の「Ｎｏ」経路をとり、プロセスはブロック４４７に示すように選択された仮想ソケット上の仮想ソケットを待ち、そのような事象を受け取った後でブロック４４８に示すように終了する。選択された仮想ソケットについてデータまたは仮想閉鎖が保留状態になっている場合、仮想事象がすでに発生しており、ブロック４４６の「Ｙｅｓ」経路をとって、ブロック４４８に示すようにプロセスが終了する。

第１８図のブロック３３５および３４７と第１９図のブロック３６５および３７７で言及した仮想フラッシュ操作は、第２４図のブロック４５０から始まる操作を実行することによって行われる。仮想フラッシュ操作が呼び出されると、決定ブロック４５５に示すように、フラッシュする仮想ソケット待ち行列にデータが入っているかどうかを調べる。仮想ソケット待ち行列にデータが入っていない場合、ブロック４５５の「Ｎｏ」経路が示すようにフラッシュ操作は単に終了して呼出し側機能に戻る。しかし、待ち行列にデータが入っている場合、ブロック４５５の「Ｙｅｓ」経路をとり、ブロック４６０に示すようにその仮想ソケット待ち行列がマルチプレックスソケットのものであるかどうかを判断する。マルチプレックスソケットである場合は、ブロック４６１に示すようにソケットの固有識別子と転送中のデータ量を示す３バイトから成るソケット・ヘッダが実ソケット・バッファに加えられる。マルチプレックスソケットであるかシンプレックス・ソケットであるかを問わず、いずれの場合もブロック４６２に示すように実ソケットのためのデータが実ソケット・バッファに移される。実ソケット・バッファがいっぱいの場合、ブロック４６５の「Ｙｅｓ」経路をとり、ブロック４６６に示すように実ソケット・バッファからデータが実ソケットに送られる。実バッファがいっぱいになっていない場合は、ブロック４６５の「Ｎｏ」経路をとる。次に、仮想フラッシュ機能は、他のいずれかのマルチプレックス仮想ソケット待ち行列に実ソケットに送るべき他のデータがあるかどうかを判断する。答えが肯定の場合、ブロック４７０の「Ｙｅｓ」経路をとり、実ソケット・バッファ内のデータは、他の仮想ソケット待ち行列の１つをフラッシュするために仮想フラッシュ操作が再び呼び出されるまで送られない。他のデータがない場合、または他のマルチプレックス仮想ソケットからデータを付加した後は、ブロック４６６の操作を行い、実ソケットバッファ内のデータを実ソケットに送る。仮想フラッシュ操作を呼び出した機能に対応する仮想ソケット待ち行列内のすべてのデータが実ソケットに送られた後、ブロック４６７に示すように仮想フラッシュ操作は終了する。

第１８図のブロック３４２および３４８と第１９図のブロック３７２および３７８に示す仮想閉鎖操作は、第２５図のブロック４８０から始まる操作を実行することによって行われる。仮想閉鎖操作が呼び出されると、まずブロック４８５に示すようにその仮想閉鎖がマルチプレックス仮想ソケットの閉鎖であるかどうかを判断する。マルチプレックス仮想ソケットである場合、ブロック４８５の「Ｙｅｓ」経路をとり、仮想ソケット待ち行列に「閉鎖」操作標識が付加される。仮想閉鎖がマルチプレックス仮想ソケットの閉鎖であるか否かを問わず、ブロック４８７に示すように仮想閉鎖操作によって仮想フラッシュ操作が呼び出され、ブロック４８８に示すように実ソケットとの接続を断つ。次に、ブロック４９０に示すように仮想閉鎖がシンプレックス仮想ソケットの閉鎖であるかどうかを調べ、そうでない場合は「Ｎｏ」経路をとってブロック４９５に進む。閉鎖はマルチプレックス仮想ソケットの閉鎖であるため、ブロック４９５でそれが最後のマルチプレックス仮想ソケットであるかどうかを判断し、最後のマルチプレックス仮想ソケットである場合は、ブロック４９６に示すようにマルチプレックス活動タイマをセットする。最後のマルチプレックス仮想ソケットでない場合は、ブロック４９６をスキップする。

ブロック４９０に戻って、仮想閉鎖がシンプレックス仮想ソケットの閉鎖である場合、ブロック４９１に示すようにそれに対応する実ソケットを事象リストから除去し、ブロック４９２に示すように実ソケットを閉鎖し、削除する。ソケットがシンプレックスとマルチプレックスのどちらの仮想ソケットであるかを問わず、ブロック４９７に示すようにその仮想ソケットに閉鎖のマークを付け、ブロック４９８で閉鎖操作は終了する。

次に、第２０図ないし第２３図および第２４図ないし第２５図に関連する第１５図ないし第１７図について説明する。実事象が発生すると、第１６図のブロック３０２を終了し、ソケット・マネージャは事象がどのように生成されたかに基づいてその事象を調べる。事象が第２５図のブロック４９６で設定されたマルチプレックスソケット活動タイマのタイム・アウトである場合、第１６図のブロック３０５からブロック３１２までの経路がとられる。第１６図に示すように、次にソケット・マネージャによってブロック３１２および３１３の操作が行われ、マルチプレックス実ソケットが閉じられ、クライアント側インタセプト・モジュールをサーバ側インタセプト・モジュールに接続するソケットに対応するマルチプレックス実ソケットが削除される。その後、ソケット・マネージャは次の実事象を待つ。ブロック３２２に示すように、このマルチプレックス事象タイマはマルチプレックス仮想ソケットの作成によってリセットされる。

実ソケット上で発生した事象が、ウェブ・サーバがウェブ・サーバとサーバ側インタセプト・モジュールとの間のソケット接続に対する閉鎖操作を行う場合などの実ソケット閉鎖である場合、第１６図のブロック３０５からブロック３０９への経路がとられる。ソケット・マネージャはブロック３０９に示すように実事象リストからその実ソケットを除去し、ブロック３１０に示すように１つの仮想ソケット（または複数のマルチプレックスソケットの場合は複数の仮想ソケット）をその１つの実ソケットまたは複数の実ソケットから切断する。次に、ソケット・マネージャはその仮想ソケットに閉鎖のマークを付け、仮想事象を通知する。この操作はブロック３１１に示されており、仮想ソケット待ち行列からすべてのデータが空にされると、仮想ソケットは閉じる。仮想ソケットに閉鎖のマークを付けた後、決定ブロック３１５に示すようにソケット・マネージャは閉じる実ソケットがシンプレックス・ソケットであるかどうかを判断する。閉じる実ソケットがシンプレックス・ソケットである場合、ブロック３１６に示すようにその実ソケットを閉じ、削除する。次にソケット・マネージャはブロック３０２に示すように次の実事象を待つ。

閉じるソケットがシンプレックス実ソケットではない場合、ブロック３１５の「Ｎｏ」経路をとり、ソケット・マネージャは次の実事象を待つ。したがって、マルチプレックス実ソケット、すなわちクライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとを接続するソケットを、マルチプレックスソケット活動タイマのタイムアウトのみによって閉じることができる。これによって、ユーザ指定の所定時間の間、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとの間の接続を、モジュール間の最後の通信が行われた後でも維持することができる。マルチプレックスソケット活動タイマのタイムアウトの前にブラウザからその後の接続要求があった場合、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとの間に接続を再確立せずに通信を行うことができ、それによってそのような接続を再確立するオーバーヘッドが不要になる。

第１５図ないし第１７図で説明する最後の経路は、実事象が発生し、その事象が第１４図の１つまたは複数のマルチプレックス実ソケット３６ａまたは３６ｂ上でのデータの受信である場合である。マルチプレックス実ソケット上でデータを受信すると、そのデータは検査され、第２５図のブロック４８６で仮想待ち行列に付加されるもののようにデータに閉鎖操作標識が含まれている場合は、仮想閉鎖操作が行われ、ブロック３２０からブロック３１０への経路がとられる。ソケット・マネージャは、ブロック３１０に示すように実ソケット上で受信したデータで識別されたマルチプレックス仮想ソケットを実ソケットから切断し、次にブロック３１１に示すように仮想ソケットに「閉鎖」のマークを付け、仮想事象を通知する。この閉鎖はマルチプレックス仮想ソケットの閉鎖であるため、ブロック３１５から「Ｎｏ」経路がとられ、ブロック３０２に示すようにソケット・マネージャは別の実事象を待つ。

第１５図ないし第２５図で説明されている操作を行うことによって、本発明の特定の態様は外部通信リンクを介して第１のコンピュータと第２のコンピュータとの間に持続的接続を確立する。この持続的接続は、すべてのウェブ・ブラウザ発信通信が完了するまで維持され、持続的接続が維持されている間に複数のウェブ・ブラウザ発信通信がインタセプトされ、外部通信リンクに多重化されて送られる。次にクライアント／サーバ固有データ・ストリームを多重化解除して複数のＨＴＴＰデータ・ストリームを作成し、その複数のＨＴＴＰデータ・ストリームをウェブ・サーバに供給することができる。また、持続的接続は、すべてのウェブ・サーバ発信通信がインタセプト完了するまで維持される。持続的接続が維持されている間に、複数のウェブ・サーバ発信通信がインタセプトされ、外部通信リンクに多重化されて送られる。さらに、クライアント／サーバ固有データ・ストリームを多重化解除して複数のＨＴＴＰデータ・ストリーを作成し、その複数のＨＴＴＰデータ・ストリームをウェブ・サーバに供給することができる。

図面および本明細書では、本発明の典型的な好ましい実施例を開示し、特定の用語を使用したが、これらの用語は総称および説明のためものに過ぎず、請求の範囲に記載されている本発明の範囲を限定するためのものではない。

まとめとして、本発明の構成に関して以下の事項を開示する。

（１）第１のコンピュータ内に常駐する第１のアプリケーションから受信し、第２のコンピュータ内に常駐する第２のアプリケーションからの要求に応答して前記第２のアプリケーションに送るべきデータをキャッシュする方法であって、
前記第１のアプリケーションから受信し、かつ前記第２のアプリケーションに送るべきデータ・ストリームを第１のキャッシュ内に格納して、前記第２のアプリケーションからの前記要求に対応するクライアント・キャッシュ項目を生成するステップと、
前記クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目時間記録を生成するステップと、
前記第２のアプリケーションからの要求に応答して、前記第１のアプリケーションからの前記データ・ストリームを第２のキャッシュ内に格納して、サーバ要求キャッシュ項目を生成するステップと、
前記要求に対応する前記サーバ要求キャッシュ項目が前に前記第２のキャッシュ内に格納されていたかどうかを判定するために、前記第２のアプリケーションが発生し、かつ前記第１のアプリケーションにより受信される要求を検査するステップと、
前記第２のアプリケーションからの要求に対応し、前記要求に対応するサーバ要求キャッシュ項目と同じクライアント・キャッシュ項目が存在するかどうかを判定するステップと、
前記第２のアプリケーションからの前記要求を受信した時間と、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目が生成された時間との間の時間間隔を計算して、前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じ場合に、項目エージ・データを供給するステップと、
前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じでない場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を前記第２のアプリケーションに送信するステップと、
前記サーバ要求キャッシュ項目が前記クライアント・キャッシュ項目と同じ場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目の前記項目エージ・データを前記第２のアプリケーションに送信するステップとを含む方法。
（２）前記第２のアプリケーションの複数のインスタンス間でクライアント・キャッシュ項目を維持するステップをさらに含む、上記（１）に記載の方法。
（３）前記要求に対応するクライアント・キャッシュ項目が存在するかどうかを判定するために、前記第２のアプリケーションからの要求を検査するステップと、
前記第２のアプリケーションが情報を要求する前に、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するために、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目の前記クライアント・キャッシュ項目時間記録を評価するステップと、
前記評価するステップで、前記第２のアプリケーションが前記情報を要求する前に、前記第２のアプリケーションからの前記要求のクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたと判定した場合に、前記要求に応答して前記クライアント・キャッシュ項目を前記第２のアプリケーションに供給するステップとをさらに含む、上記（１）に記載の方法。
（４）前記第１のアプリケーションが前記要求を受信する前に、前記第２のアプリケーションからの前記要求に対応するサーバ要求キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するステップをさらに含み、
前記送信するステップが、前記サーバ要求キャッシュ項目が前記所定のクライアント・コヒーレンシ時間間隔内に生成されたと前記判定するステップで判定した場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を送信するステップを含む、上記（１）に記載の方法。
（５）前記第１のコンピュータから受信した前記項目エージ・データを前記第２のコンピュータの現在時間から減じることによって、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目時間記録を更新するステップをさらに含む、上記（１）に記載の方法。
（６）前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のアプリケーションがウェブ・サーバであることを特徴とする、上記（１）に記載の方法。
（７）前記第１のアプリケーションがウェブ・サーバであり、かつ前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のコンピュータと前記第２のコンピュータが無線通信リンクを介して通信することを特徴とする、上記（１）に記載の方法。
（８）第１のコンピュータ内に常駐する第１のアプリケーションから受信し、第２のコンピュータ内に常駐する第２のアプリケーションからの要求に応答して前記第２のアプリケーションに送るべきデータをキャッシュする装置であって、
前記第１のアプリケーションから受信し、かつ前記第２のアプリケーションに送るべきデータ・ストリームを第１のキャッシュ内に格納して、前記第２のアプリケーションからの前記要求に対応するクライアント・キャッシュ項目を生成する手段と、
前記クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目時間記録を生成する手段と、
前記第２のアプリケーションからの要求に応答して、前記第１のアプリケーションからの前記データ・ストリームを第２のキャッシュ内に格納して、サーバ要求キャッシュ項目を生成する手段と、
前記要求に対応する前記サーバ要求キャッシュ項目が前に前記第２のキャッシュ内に格納されていたかどうかを判定するために、前記第２のアプリケーションが発生した要求を検査する手段と、
前記第２のアプリケーションからの要求に対応し、前記要求に対応するサーバ要求キャッシュ項目と同じクライアント・キャッシュ項目が存在するかどうかを判定する手段と、
前記第１のアプリケーションが前記第２のアプリケーションからの前記要求を受信した時間と、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目が生成された時間との間の時間間隔を計算して、前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じ場合に、項目エージ・データを供給する手段と、
前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じでない場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を前記第２のアプリケーションに送信する手段と、
前記サーバ要求キャッシュ項目が前記クライアント・キャッシュ項目と同じ場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目の前記項目エージ・データを前記第２のアプリケーションに送信する手段とを含む装置。
（９）前記第２のアプリケーションの複数のインスタンス間でクライアント・キャッシュ項目を維持するステップをさらに含む、上記（８）に記載の装置。
（１０）前記要求に対応するクライアント・キャッシュ項目が存在するかどうかを判定するために、前記第２のアプリケーションからの要求を検査する手段と、
前記第２のアプリケーションが情報を要求する前に、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するために、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目の前記クライアント・キャッシュ項目時間記録を評価する手段と、
前記評価する手段が、前記第２のアプリケーションが前記情報を要求する前に、前記第２のアプリケーションからの前記要求のクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたと判定した場合に、前記要求に応答して前記クライアント・キャッシュ項目を前記第２のアプリケーションに供給する手段とをさらに含む、上記（８）に記載の装置。
（１１）前記第１のアプリケーションが前記要求を受信する前に、前記第２のアプリケーションからの前記要求に対応するサーバ要求キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定する手段をさらに含み、
前記送信する手段が、前記サーバ要求キャッシュ項目が前記所定のクライアント・コヒーレンシ時間間隔内に生成されたと前記判定する手段が判定した場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を送信する手段を含む、上記（８）に記載の装置。
（１２）前記第１のコンピュータから受信した前記項目エージ・データを前記第２のコンピュータの現在時間から減じることによって、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目時間記録を更新する手段をさらに含む、上記（８）に記載の装置。
（１３）前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のアプリケーションがウェブ・サーバであることを特徴とする、上記（８）に記載の装置。
（１４）前記第１のアプリケーションがウェブ・サーバであり、かつ前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のコンピュータと前記第２のコンピュータが無線通信リンクを介して通信することを特徴とする、上記（８）に記載の装置。

第１図は、典型的なウェブ・ブラウザ／ウェブ・サーバ・システムを示すブロック図である。 第２図は、クライアント・インタセプトとサーバ・インタセプトを使用する本発明の一実施態様によるウェブ・ブラウザ／ウェブ・サーバ・システムを示すブロック図である。 第３図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい実施例において、クライアント側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第４図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい実施例において、クライアント側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第５図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい実施例において、サーバ側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第６図は、コヒーレント・キャッシュ・システムを実施する本発明の好ましい実施例において、サーバ側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第７図は、差分計算データ転送システムを実施する本発明の好ましい実施例において、クライアント側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第８図は、差分計算データ転送システムを実施する本発明の好ましい実施例において、クライアント側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第９図は、差分計算データ転送システムを実施する本発明の好ましい実施例において、サーバ側インタセプト・モジュールによって行われる操作を図示する流れ図である。 第１０図は、差分計算転送システムを実施する本発明の好ましい実施例において、サーバ側インタセプト・モジュールによって行われる操作を図示する流れ図であり、第１１図および第１２図から構成されることを示す図である。 第１１図は、第１０図を構成する流れ図である。 第１２図は、第１０図を構成する流れ図である。 第１３図は、仮想ソケットを使用する本発明の一態様を示すブロック図である。 第１４図は、仮想ソケットを使用する本発明の一実施例による、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールを示すブロック図である。 第１５図は、仮想ソケットを使用する本発明の一実施例による、クライアント側インタセプト・モジュールまたはサーバ側インタセプト・モジュールのソケット・マネージャによって行われる操作を図示する流れ図であり、第１６図および第１７図から構成されることを示す図である。 第１６図は、第１５図を構成する流れ図である。 第１７図は、第１５図を構成する流れ図である。 第１８図は、仮想ソケットを使用する本発明の一実施例において、クライアント側インタセプト機能によって行われる操作を図示する流れ図である。 第１９図は、仮想ソケットを使用する本発明の一実施例において、サーバ側インタセプト機能によって行われる操作を図示する流れ図である。 第２０図は、仮想ソケットを使用する本発明の一実施例による、仮想作成操作を図示する流れ図である。 第２１図は、仮想ソケットを使用する本発明の一実施例による仮想送信操作を図示する流れ図である。 第２２図は、仮想ソケットを使用する本発明の一実施例による仮想受信操作を図示する流れ図である。 第２３図は、仮想ソケットを使用する本発明の一実施例による仮想選択操作を図示する流れ図である。 第２４図は、仮想ソケットを使用する本発明の一実施例による仮想フラッシュ操作を図示する流れ図である。 第２５図は、仮想ソケットを使用する本発明の一実施例による仮想クローズ操作を図示する流れ図である。

符号の説明

５ 第１のコンピュータ
６ 第２のコンピュータ
１０ ウェブ・ブラウザ
２０ ウェブ・サーバ
３０ クライアント側インタセプト・モジュール
３５ 外部通信リンク
４０ サーバ側インタセプト・モジュール

Claims (14)

1. 第１のコンピュータ内に常駐する第１のアプリケーションから受信し、第２のコンピュータ内に常駐する第２のアプリケーションからの要求に応答して前記第２のアプリケーションに送るべきデータをキャッシュする方法であって、
   前記第１のアプリケーションから受信し、かつ前記第２のアプリケーションに送るべきデータ・ストリームを第１のキャッシュ内に格納して、前記第２のアプリケーションからの前記要求に対応するクライアント・キャッシュ項目を生成するステップと、
   前記クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目時間記録を生成するステップと、
   前記第２のアプリケーションからの要求に応答して、前記第１のアプリケーションからの前記データ・ストリームを第２のキャッシュ内に格納して、サーバ要求キャッシュ項目を生成するステップと、
   前記要求に対応する前記サーバ要求キャッシュ項目が前に前記第２のキャッシュ内に格納されていたかどうかを判定するために、前記第２のアプリケーションが発生し、かつ前記第１のアプリケーションにより受信される要求を検査するステップと、
   前記第２のアプリケーションからの要求に対応し、前記要求に対応するサーバ要求キャッシュ項目と同じクライアント・キャッシュ項目が存在するかどうかを判定するステップと、
   前記第２のアプリケーションからの前記要求を受信した時間と、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目が生成された時間との間の時間間隔を計算して、前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じ場合に、項目エージ・データを供給するステップと、
   前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じでない場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を前記第２のアプリケーションに送信するステップと、
   前記サーバ要求キャッシュ項目が前記クライアント・キャッシュ項目と同じ場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目の前記項目エージ・データを前記第２のアプリケーションに送信するステップとを含む方法。
2. 前記第２のアプリケーションの複数のインスタンス間でクライアント・キャッシュ項目を維持するステップをさらに含む、請求項１に記載の方法。
3. 前記要求に対応するクライアント・キャッシュ項目が存在するかどうかを判定するために、前記第２のアプリケーションからの要求を検査するステップと、
   前記第２のアプリケーションが情報を要求する前に、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するために、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目の前記クライアント・キャッシュ項目時間記録を評価するステップと、
   前記評価するステップで、前記第２のアプリケーションが前記情報を要求する前に、前記第２のアプリケーションからの前記要求のクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたと判定した場合に、前記要求に応答して前記クライアント・キャッシュ項目を前記第２のアプリケーションに供給するステップとをさらに含む、請求項１に記載の方法。
4. 前記第１のアプリケーションが前記要求を受信する前に、前記第２のアプリケーションからの前記要求に対応するサーバ要求キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するステップをさらに含み、
   前記送信するステップが、前記サーバ要求キャッシュ項目が前記所定のクライアント・コヒーレンシ時間間隔内に生成されたと前記判定するステップで判定した場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を送信するステップを含む、請求項１に記載の方法。
5. 前記第１のコンピュータから受信した前記項目エージ・データを前記第２のコンピュータの現在時間から減じることによって、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目時間記録を更新するステップをさらに含む、請求項１に記載の方法。
6. 前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のアプリケーションがウェブ・サーバであることを特徴とする、請求項１に記載の方法。
7. 前記第１のアプリケーションがウェブ・サーバであり、かつ前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のコンピュータと前記第２のコンピュータが無線通信リンクを介して通信することを特徴とする、請求項１に記載の方法。
8. 第１のコンピュータ内に常駐する第１のアプリケーションから受信し、第２のコンピュータ内に常駐する第２のアプリケーションからの要求に応答して前記第２のアプリケーションに送るべきデータをキャッシュする装置であって、
   前記第１のアプリケーションから受信し、かつ前記第２のアプリケーションに送るべきデータ・ストリームを第１のキャッシュ内に格納して、前記第２のアプリケーションからの前記要求に対応するクライアント・キャッシュ項目を生成する手段と、
   前記クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目時間記録を生成する手段と、
   前記第２のアプリケーションからの要求に応答して、前記第１のアプリケーションからの前記データ・ストリームを第２のキャッシュ内に格納して、サーバ要求キャッシュ項目を生成する手段と、
   前記要求に対応する前記サーバ要求キャッシュ項目が前に前記第２のキャッシュ内に格納されていたかどうかを判定するために、前記第２のアプリケーションが発生した要求を検査する手段と、
   前記第２のアプリケーションからの要求に対応し、前記要求に対応するサーバ要求キャッシュ項目と同じクライアント・キャッシュ項目が存在するかどうかを判定する手段と、
   前記第１のアプリケーションが前記第２のアプリケーションからの前記要求を受信した時間と、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目が生成された時間との間の時間間隔を計算して、前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じ場合に、項目エージ・データを供給する手段と、
   前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じでない場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を前記第２のアプリケーションに送信する手段と、
   前記サーバ要求キャッシュ項目が前記クライアント・キャッシュ項目と同じ場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目の前記項目エージ・データを前記第２のアプリケーションに送信する手段とを含む装置。
9. 前記第２のアプリケーションの複数のインスタンス間でクライアント・キャッシュ項目を維持するステップをさらに含む、請求項８に記載の装置。
10. 前記要求に対応するクライアント・キャッシュ項目が存在するかどうかを判定するために、前記第２のアプリケーションからの要求を検査する手段と、
    前記第２のアプリケーションが情報を要求する前に、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定するために、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目の前記クライアント・キャッシュ項目時間記録を評価する手段と、
    前記評価する手段が、前記第２のアプリケーションが前記情報を要求する前に、前記第２のアプリケーションからの前記要求のクライアント・キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたと判定した場合に、前記要求に応答して前記クライアント・キャッシュ項目を前記第２のアプリケーションに供給する手段とをさらに含む、請求項８に記載の装置。
11. 前記第１のアプリケーションが前記要求を受信する前に、前記第２のアプリケーションからの前記要求に対応するサーバ要求キャッシュ項目が所定のクライアント・コヒーレンシ時間間隔内に生成されたかどうかを判定する手段をさらに含み、
    前記送信する手段が、前記サーバ要求キャッシュ項目が前記所定のクライアント・コヒーレンシ時間間隔内に生成されたと前記判定する手段が判定した場合に、前記第２のアプリケーションからの前記要求に対応する前記サーバ要求キャッシュ項目を送信する手段を含む、請求項８に記載の装置。
12. 前記第１のコンピュータから受信した前記項目エージ・データを前記第２のコンピュータの現在時間から減じることによって、前記第２のアプリケーションからの前記要求に対応する前記クライアント・キャッシュ項目時間記録を更新する手段をさらに含む、請求項８に記載の装置。
13. 前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のアプリケーションがウェブ・サーバであることを特徴とする、請求項８に記載の装置。
14. 前記第１のアプリケーションがウェブ・サーバであり、かつ前記第２のアプリケーションがウェブ・ブラウザであり、かつ前記第１のコンピュータと前記第２のコンピュータが無線通信リンクを介して通信することを特徴とする、請求項８に記載の装置。

Images