JP3506179B2 - 時間コヒーレント・キャッシュ・システム - Google Patents

Description

【発明の詳細な説明】 発明の分野 本発明は、キャッシュ構造および方法に関する。具体
的には、本発明は、一方のコンピュータがクライアント
・アプリケーションを稼動させ、他方のコンピュータが
サーバ・アプリケーションを稼動させている２台のコン
ピュータ間の低速通信または無線通信リンクを介した通
信を有するシステム内で有用なキャッシュ構造および方
法に関する。 発明の背景 最近、「情報スーパーハイウェイ」に関して宣伝さ
れ、重要視されていることにより、マスコミュニケーシ
ョン媒体としてのインターネットがますます知られ、受
け入れられるようになってきた。複数のネットワークに
またがる通信と対話のための実現可能な媒体としてイン
ターネットがこのように広く認識されるようになったこ
とにより、コンピュータ・ネットワーク間の対話のため
のインターネット標準化プロトコルに基づく大規模なユ
ーザ基盤も確立されている。 インターネットのパラダイムは、インターネット・ク
ライアント（ブラウザ）がインターネット・サーバと通
信するクライアント−サーバ関係のパラダイムである。
インターネットへのアクセスを拡大するために、クライ
アントとサーバが使用する通信プロトコルと言語が標準
化されるようになった。これらのプロトコルには、クラ
イアントとサーバの間の通信に使用される通信プロトコ
ルであるハイパーテキスト転送プロトコル（HTTP）と、
伝送制御プロトコル／インターネット・プロトコル（TC
P/IP）がある。TCP/IPのTCP部分は、コンピュータ間ま
たはアプリケーション間の通信のためのトランスポート
固有のプロトコルである。クライアントとサーバが通信
する言語も標準化されており、これはハイパーテキスト
・マークアップ言語（HTML）と呼ばれる。これらのプロ
トコルと言語は機械から独立しており、コネクションレ
スの最善のプロトコルを使用して情報を送信し、各トラ
ンザクションは完全に自己完結している。したがって、
たとえば、クライアントからの各メッセージにはブラウ
ザの機能に関する情報が含まれ、通信を完結させるため
に他のどの通信からも独立している。クライアントとサ
ーバの間の通信のこの自己完結性は「ステートレス」通
信と呼ばれることがあり、これは所与の通信のためにク
ライアントとサーバの間で伝送しなければならないデー
タの量を増大させる。 ワールド・ワイド・ウェブのクライアント／サーバ・
アプリケーションの関連では、ユーザ・インタフェース
として機能するウェブ・ブラウザがクライアントであろ
う。ウェブ・ブラウザは適切なウェブ・サーバにユーザ
要求を送り、ウェブ・サーバから返されたHTMLデータの
フォーマットと表示を行う。また、ウェブ・ブラウザは
HTMLデータを評価して、ブラウザが発行する後続のブラ
ウザ要求を必要とすることになるハイパーリンク・ステ
ートメントがHTMLデータに埋め込まれていないかどうか
を判断する。ウェブ・サーバはクライアントのためのサ
ーバの役割を果たし、ウェブ・ブラウザ要求を処理し、
要求された応答をHTTPデータ・ストリームのHTMLデータ
部分として返す。 典型的なワールド・ワイド・ウェブ通信の例として、
ウェブ・ブラウザがウェブ・サーバに対して「ホーム・
ページ」を求める要求を出す事例を用いて、HTTPとHTML
とTCPとウェブ・ブラウザとウェブ・サーバとの間の基
本的な関係を例示する。ウェブ・ブラウザのユーザが特
定のウェブ・サイトに対して情報を要求すると、ウェブ
・ブラウザはウェブ・サーバに所望のウェブ・サイト
（この例では「ホーム・ページ」）のユニバーサル・リ
ソース・ロケータ（URL）を指定する「get」要求を送る
ことによって、ウェブ・サーバの通信を開始する。URL
はウェブ・サイトのアドレスの役割を果たし、インター
ネット全体を通じて固有である。次にウェブ・サーバ
は、URLで指定されたホーム・ページに対応するHTMLデ
ータを入手してウェブ・ブラウザに供給する。この操作
には、インターネット・ウェブ・サーバによるインター
ネット上での通信がさらに必要となったり、ブラウザが
接続しているローカル・ネットワーク内にあるサーバを
URLによって指定する必要がある場合がある。次にウェ
ブ・ブラウザはウェブ・サーバからHTTPデータ・ストリ
ームとして受け取ったHTMLデータを評価して、アイコン
やイメージなどのハイパーリンクが埋め込まれていない
かどうかを調べ、そのようなハイパーリンクがある場合
は、そのハイパーリンクのURLを指定する要求を出し
て、指定されたデータを入手する。このデータはホーム
・ページに組み込まれ、ユーザに対して表示されること
になる。この単純な例でわかるように、ウェブ・ブラウ
ザによる１つのユーザ入力要求の結果、ユーザ要求に対
応するHTMLデータの受信に応答してウェブ・ブラウザが
自動的に複数の追加の要求を行うことになる。 インターネット・ベースのシステムの基本的な通信構
造を第１図に示す。第１図では、ウェブ・ブラウザ10が
通信リンク15を介してウェブ・サーバ20と通信する。こ
の通信リンクは典型的にはローカル・エリア・ネットワ
ーク接続、ワイド・エリア・ネットワーク接続、電話回
線による接続、またはその組合せである。ウェブ・ブラ
ウザ10はTCP/IPを使用してウェブ・サーバ20と通信す
る。インターネット通信では一般に、ウェブ・ブラウザ
は、ウェブ・ブラウザとウェブ・サーバの間のTCP/IPリ
ンクを介してウェブ・ブラウザとウェブ・サーバの間で
伝送される汎用通信プロトコルHTTPを使用して、ウェブ
・サーバと通信する。ウェブ・ブラウザ10とウェブ・サ
ーバ20の間で伝送される実データは前述のHTTPデータ・
オブジェクト（たとえばHTMLデータ）である。ウェブ・
サーバ20はいくつかのウェブ・ブラウザからウェブ・ブ
ラウザ通信を受け取り、それらを適切なサーバにルーテ
ィングするプロキシとすることもできる。 ウェブ・ブラウザ／ウェブ・サーバと、それらの共通
の情報とトランスポート・プロトコルであるHTMLとHTTP
の普及によって、ウェブ技法が情報へのネットワーク・
アクセスのための汎用インタフェースとして急速に受け
入れられるようになった。さらに、ウェブ・ブラウザと
ウェブ・サーバの間の通信のためのプロトコルと言語が
標準化されているため、ユーザがネットワーク情報にア
クセスするためのウェブ・ブラウザとしてNetscape Na
vigatorTM、NCSA、MosaicTM、WebExplorerTM、または他
のどのブラウザを使用するかを問わず、通信プロトコル
および言語は同じになる。したがって、ウェブ・ブラウ
ザの大規模なインストール済みユーザ基盤と、インタフ
ェースの接続性と、HTTP定義の共通ゲートウェイ・イン
タフェース（CGI）を使用したウェブ・アプリケーショ
ン・サーバの作成の容易さとが組合わさって、ウェブ技
法を大規模なクラスの書式ベース・アプリケーションに
とってきわめて魅力的なものにしている。 インタフェースの普及と受け入れの拡大と同時に、移
動体コンピューティングも普及している。ラップトッ
プ、ノートブック、パーソナル・ディジタル／通信アシ
スタント（PDA/PCA）およびその他の携帯用装置の使用
によって、無線通信の需要が増大している。しかし、無
線ワイド・エリア・ネットワーク、セルラ通信、および
パケット無線には、ウェブの環境で使用した場合に共通
の制約がある。１バイト当たりの高い通信コストと、遅
い応答時間と、低帯域幅と、信頼性のなさはすべて、ワ
ールド・ワイド・ウェブのステートレス通信プロトコル
に無線技法を使用するのを阻害している。また、ウェブ
・プロトコルはステートレスであるため、１要求当たり
のデータ量と無線接続を介して伝送される通信要求の数
は、通信が自己完結型でない場合に必要となる量と数よ
りも大きい。したがって、無線技法またはいずれかの低
速通信技法をウェブ技法と組み合わせることは、ウェブ
技法の汎用的性質の強さによって無線技法の弱点がさら
にひどくなるため実際的ではないと思われる。 ウェブ・クライアント／サーバ環境内で無線通信を使
用する欠点の他に、従来のキャッシュ技法はまた、用途
がごく限られている。ウェブ・サーバから受信したキャ
ッシュ・データをリフレッシュすると、ウェブ環境内で
使用したときに信頼性およびアベイラビリティの問題が
起こる。例えば、ウェブ・ブラウザの新しいインスタン
スを開始するたびにキャッシュ・データをリフレッシュ
する場合、その情報がウェブ・ブラウザの特定のインス
タンス中に使用されなければ、多数の不必要なブラウザ
要求が発生する。キャッシュ・データをリフレッシュし
ない場合、キャッシュ内のデータは信頼できなくなる。 発明の目的と概要 上記の制限事項に関して、本発明の１つの目的は、キ
ャッシュ・データの不必要な更新を必要とせずに信頼で
きるデータをもたらすキャッシュ・システムを提供する
ことである。 本発明の追加の目的は、ウェブ・ブラウザ／サーバ環
境内で使用できるキャッシュ構造を提供することであ
る。 本発明の他の目的は、ウェブ・ブラウザ・アプリケー
ションまたはウェブ・サーバ・アプリケーションを修正
する必要なしに低速通信または無線通信システム内で既
存の通信プロトコルおよび言語に適合できるようにする
ことである。 本発明の追加の目的は、ウェブ・ブラウザとウェブ・
サーバの間で必要な通信の量を少なくし、それにより通
信システムのパフォーマンスを向上させるキャッシュ方
法を提供することである。 上記その他の目的に関して、本発明は、第１のアプリ
ケーションから受信し、第２のアプリケーションからの
要求に応答して第２のアプリケーションに送るべきデー
タをキャッシュする方法を提供する。本方法は、第１の
アプリケーションから受信しかつ第２のアプリケーショ
ンに送るべきデータ・ストリームをキャッシュ内に格納
して、第２のアプリケーションからの要求に対応するク
ライアント・キャッシュ項目を生成するステップを含
む。また、クライアント・キャッシュ項目の生成時間を
格納して、クライアント・キャッシュ項目時間記録を生
成する。要求に対応するクライアント・キャッシュ項目
が存在するかどうかを判定するために、第２のアプリケ
ーションからの要求を検査する。要求に対応するクライ
アント・キャッシュ項目が存在する場合、第２のアプリ
ケーションがその情報を要求する前に第２のアプリケー
ションからの要求に対応するクライアント・キャッシュ
項目が所定のクライアント・コヒーレンシ時間間隔内に
生成されたかどうかを判定するために、第２のアプリケ
ーションからの要求に対応するクライアント・キャッシ
ュ項目のクライアント・キャッシュ項目時間記録を評価
する。第２のアプリケーションがその情報を要求する前
にクライアント・キャッシュ項目が所定のクライアント
・コヒーレンシ時間間隔内に生成された場合、要求に応
答してクライアント・キャッシュ項目を第２のアプリケ
ーションに供給する。本発明の代替実施形態では、第２
のアプリケーションの複数のインスタンス間でクライア
ント・キャッシュ項目を維持する。 本発明の他の実施形態では、第１のアプリケーション
は第１のコンピュータ内に常駐し、第２のアプリケーシ
ョンは第２のコンピュータ内に常駐し、第１のアプリケ
ーションと第２のアプリケーションは、さらに外部通信
リンクを介して互いに通信する。この代替実施形態で
は、本発明は、第２のアプリケーションからの要求に応
答して、第１のアプリケーションからのデータ・ストリ
ームを第１のコンピュータ内に常駐するキャッシュ内に
格納して、サーバ要求キャッシュ項目を生成する。要求
に対応するサーバ要求キャッシュ項目が前にキャッシュ
内に格納されていたかどうかを判定するために、第２の
アプリケーションが発生した要求を評価する。次いで、
第２のアプリケーションからの要求に対応するサーバ要
求キャッシュ項目を外部通信リンクを介して第２のコン
ピュータ内に常駐する第２のアプリケーションに送る。 本発明の追加の代替実施形態では、第１のコンピュー
タは、第１のコンピュータがその要求を受信する前に、
第２のアプリケーションからの要求に対応するサーバ要
求キャッシュ項目が所定のクライアント・コヒーレンシ
時間間隔内に生成されたかどうかを判定する。サーバ要
求キャッシュ項目が所定のクライアント・コヒーレンシ
時間間隔内に生成された場合、第２のアプリケーション
からの要求に対応するサーバ要求キャッシュ項目を第２
のコンピュータに送る。 本発明の代替実施形態はまた、要求に対応するサーバ
・キャッシュ項目と同一である第２のアプリケーション
からの要求に対応するクライアント・キャッシュ項目が
存在するかどうかを判定するステップを含む。第１のコ
ンピュータが第２のアプリケーションからの要求を受信
した時間と、第２のアプリケーションからの要求に対応
するサーバ要求キャッシュ項目が生成された時間との間
の時間間隔を計算して、項目エージ・データをもたら
す。第２のアプリケーションからの要求に対応するサー
バ・キャッシュ項目の項目エージ・データを第２のコン
ピュータ内に常駐する第２のアプリケーションに送信
し、第１のコンピュータから受信した項目エージ・デー
タを第２のコンピュータの現在時間から減じることによ
って、第２のアプリケーションからの要求に対応するク
ライアント・キャッシュ項目時間記録を更新する。 本発明の追加の実施形態では、第２のアプリケーショ
ンはウェブ・ブラウザであり、第１のアプリケーション
はウェブ・サーバであり、他の実施形態では、第１のコ
ンピュータと第２のコンピュータは無線通信リンクを介
して通信する。 当業者ならわかるように、本発明の前述の態様は装置
またはコンピュータ可読プログラム手段としても提供す
ることができる。 図面の簡単な説明 第１図は、典型的なウェブ・ブラウザ／ウェブ・サー
バ・システムを示すブロック図である。 第２図は、クライアント・インタセプトとサーバ・イ
ンタセプトを使用する本発明の一実施態様によるウェブ
・ブラウザ／ウェブ・サーバ・システムを示すブロック
図である。 第３図は、コヒーレント・キャッシュ・システムを実
施する本発明の好ましい実施例において、クライアント
側インタセプト・モジュールによって行われる操作を図
示する流れ図である。 第４図は、コヒーレント・キャッシュ・システムを実
施する本発明の好ましい実施例において、クライアント
側インタセプト・モジュールによって行われる操作を図
示する流れ図である。 第５図は、コヒーレント・キャッシュ・システムを実
施する本発明の好ましい実施例において、サーバ側イン
タセプト・モジュールによって行われる操作を図示する
流れ図である。 第６図は、コヒーレント・キャッシュ・システムを実
施する本発明の好ましい実施例において、サーバ側イン
タセプト・モジュールによって行われる操作を図示する
流れ図である。 第７図は、差分計算データ転送システムを実施する本
発明の好ましい実施例において、クライアント側インタ
セプト・モジュールによって行われる操作を図示する流
れ図である。 第８図は、差分計算データ転送システムを実施する本
発明の好ましい実施例において、クライアント側インタ
セプト・モジュールによって行われる操作を図示する流
れ図である。 第９図は、差分計算データ転送システムを実施する本
発明の好ましい実施例において、サーバ側インタセプト
・モジュールによって行われる操作を図示する流れ図で
ある。 第10図（集合的に第10図を形成する第10A図および第1
0B図から構成される）は、差分計算転送システムを実施
する本発明の好ましい実施例において、サーバ側インタ
セプト・モジュールによって行われる操作を図示する流
れ図である。 第11図は、仮想ソケットを使用する本発明の一態様を
示すブロック図である。 第12図は、仮想ソケットを使用する本発明の一実施例
による、クライアント側インタセプト・モジュールとサ
ーバ側インタセプト・モジュールを示すブロック図であ
る。 第13図（集合的に第13図を形成する第13A図および第1
3B図から構成される）は、仮想ソケットを使用する本発
明の一実施例による、クライアント側インタセプト・モ
ジュールまたはサーバ側インタセプト・モジュールのソ
ケット・マネージャによって行われる操作を図示する流
れ図である。 第14図は、仮想ソケットを使用する本発明の一実施例
において、クライアント側インタセプト機能によって行
われる操作を図示する流れ図である。 第15図は、仮想ソケットを使用する本発明の一実施例
において、サーバ側インタセプト機能によって行われる
操作を図示する流れ図である。 第16−１図は、仮想ソケットを使用する本発明の一実
施例による、仮想作成操作を図示する流れ図である。 第16−２図は、仮想ソケットを使用する本発明の一実
施例による仮想送信操作を図示する流れ図である。 第16−３図は、仮想ソケットを使用する本発明の一実
施例による仮想受信操作を図示する流れ図である。 第16−４図は、仮想ソケットを使用する本発明の一実
施例による仮想選択操作を図示する流れ図である。 第17−１図は、仮想ソケットを使用する本発明の一実
施例による仮想フラッシュ操作を図示する流れ図であ
る。 第17−２図は、仮想ソケットを使用する本発明の一実
施例による仮想クローズ操作を図示する流れ図である。 詳細な説明 以下に、本発明の好ましい実施例が図示されている添
付図面を参照しながら本発明について詳述する。しか
し、本発明は多くの異なる態様で実施することができ、
本明細書に記載の実施例に限定されるものと解釈しては
ならない。これらの実施例は、本開示を綿密かつ十全な
ものとし、本発明の範囲を当業者に完全に伝えるために
示すものである。全体を通じて同様の番号は同様の要素
を指す。 第３図ないし第10図と第13図ないし第17−２図は、本
発明による方法およびシステムを示すフローチャートで
ある。フローチャートの各ブロックと、フローチャート
のブロックの組合せは、コンピュータ・プログラム命令
によって実施することができることがわかるであろう。
これらのコンピュータ・プログラム命令は、コンピュー
タまたはその他のプログラム式装置にロードし、それに
よってコンピュータまたはその他のプログラム式装置上
で実行される命令がフローチャートの１つまたは複数の
ブロックに指定されている機能を実施する手段を生じさ
せるように機械を作り出すことができる。これらのコン
ピュータ・プログラム命令を、コンピュータまたはその
他のプログラム式装置に対して特定の方式で機能するよ
うに指示することができるコンピュータ可読メモリに格
納し、それによってコンピュータ可読メモリに格納され
た命令がフローチャートの１つまたは複数のブロックに
指定されている機能を実施する命令手段を含む製品を作
り出すようにすることができる。また、コンピュータ・
プログラム命令をコンピュータまたはその他のプログラ
ム式装置にロードして、コンピュータまたはその他のプ
ログラム式装置上で一連の操作ステップが行われるよう
にし、コンピュータまたはその他のプログラム式装置上
で実行される命令がフローチャートの１つまたは複数の
ブロックに指定されている機能を実施するステップを提
供するようにコンピュータ実施プロセスを作り出すこと
もできる。 したがって、フローチャートのブロックは、指定され
た機能を実行する手段の組合せと、指定された機能を実
行するステップの組合せとに対応する。また、フローチ
ャートの各ブロックと、フローチャートのブロックの組
合せは、指定された機能またはステップを実行する特定
用途向けハードウェア・ベースのコンピュータ・システ
ムによって、または特定用途向けハードウェアとコンピ
ュータ命令の組合せによって実施することができること
がわかるであろう。 第２図に、本発明の一実施例を示す。第２図に示すよ
うに、ウェブ・ブラウザ10はクライアント側インタセプ
ト・モジュール30と通信する。ウェブ・サーバ20はサー
バ側インタセプト・モジュール40と通信する。次にクラ
イアント側インタセプト・モジュール30が通信リンク35
を介してサーバ側インタセプト・モジュール40と通信す
る・ウェブ・ブラウザ10とクライアント側インタセプト
・モジュール30は、第１のコンピュータ５に組み込むこ
とができる。サーバ側インタセプト・モジュール40とウ
ェブ・サーバ20は第２のコンピュータ６に組み込むこと
ができる。第１のコンピュータ５と第２のコンピュータ
６は外部通信リンク35を介して通信する。 ウェブ・ブラウザ10は、ハイパーテキスト転送プロト
コル（HTTP）とハイパーテキスト・マークアップ言語
（HTML）を使用して、やはりHTTPとHTMLを使用するイン
ターネット・ウェブ・サーバ20と通信するインターネッ
ト・ウェブ・ブラウザであることが好ましい。動作中、
ウェブ・ブラウザ10はHTTPデータ・ストリームを出力
し、それがクライアント側インタセプト・モジュール30
によってインタセプトされる。クライアント側インタセ
プト・モジュール30によるHTTPデータ・ストリームのイ
ンタセプトは、クライアント側インタセプト・モジュー
ル30が127.0.0.1のようなネットワーク番号127を有する
IPアドレスにあるTCP/IPループバック機構を使用して行
うことができる。次に、クライアント側インタセプト・
モジュール30はHTTPデータ・ストリームをクライアント
／サーバ固有プロトコルに変換または変形し、そのクラ
イアント／サーバ固有データ・ストリームを外部通信リ
ンク35に送る。サーバ側インタセプト・モジュール40は
このクライアント／サーバ固有データ・ストリームを受
け取り、ウェブ・ブラウザ発信通信に対応する元のHTTP
データ・ストリームを再構築する。この再構築されたHT
TPデータ・ストリームは次にウェブ・サーバ20に転送さ
れる。ウェブ・サーバ20はインターネット・ウェブ・サ
ーバの通常の方式でHTTPデータ・ストリームに応答す
る。当業者ならわかるように、ウェブ・サーバ20は複数
のブラウザがインターネットに接続することができるよ
うにするプロキシとすることもできる。 たとえば特定のURLホーム・ページを求めるブラウザ
要求に応答してウェブ・サーバ20がウェブ・ブラウザ10
に送る情報を受け取ると、ウェブ・サーバ20はウェブ・
ブラウザ10に送る通信に対応するHTTPデータ・ストリー
ムを出力する。このウェブ・サーバ発信通信はサーバ側
インタセプト・モジュール40によってインタセプトさ
れ、クライアント／サーバ固有データ・ストリームに変
換される。次に、ウェブ・サーバ発信通信に対応するク
ライアント／サーバ固有データ・ストリームは外部通信
リンク35で第２のコンピュータから第１のコンピュータ
に送られる。このクライアント／サーバ固有データ・ス
トリームをクライアント側インタセプト・モジュール30
が受け取り、ウェブ・サーバ発信通信に対応するHTTPデ
ータ・ストリームが再構築され、ウェブ・ブラウザ10に
供給される。 本発明の特定の実施例では、外部通信リンク35は無線
通信リンクである。その場合、ユーザにとって受容可能
なシステム・パフォーマンスを得るために、外部通信リ
ンク35を介する通信量を、通信リンク35を介して伝送し
なければならない通信の頻度と情報量の両方について減
らすことが望ましい。したがって、本発明はキャッシン
グ技法と、差分計算技法と、プロトコル縮小技法とを使
用して、外部通信リンク35を介する必要通信量を最小限
にする。これらの技法は、HTTPのステートレスまたは確
率論的プロトコルを、クライアントおよびサーバに固有
の情報を使用するクライアント／サーバ固有プロトコル
に変換して通信の量と頻度を減らすことによって実現さ
れる。 本発明について、単一のウェブ・ブラウザ・アプリケ
ーションと単一のウェブ・サーバ・アプリケーションに
関して説明するが、当業者ならわかるように、本発明の
利便および利点は、単一のウェブ・サーバに関連づけら
れた複数のウェブ・ブラウザを使用した場合にも得るこ
とができる。したがって、本発明の方法、装置、および
プログラム製品は、各ブラウザがクライアント側インタ
セプト・モジュールと通信する複数のブラウザと共に使
用することもでき、その場合それらのクライアント側イ
ンタセプト・モジュールはウェブ・サーバまたはウェブ
・プロキシのサーバ側インタセプト・モジュールと通信
することになる。 本発明の一実施例では、クライアント側インタセプト
・モジュール30とサーバ側インタセプト・モジュール40
の朗報がキャッシュ格納機能を有する。第１のコンピュ
ータにあるクライアント・キャッシュには、ウェブ・ブ
ラウザ発信通信に応答してウェブ・ブラウザが受け取る
HTTPデータ・ストリームが格納される。第２のコンピュ
ータにあるサーバ・キャッシュには、ブラウザ発信通信
に応答してウェブ・サーバから受け取るHTTPデータ・ス
トリームが格納される。 当業者ならわかるように、第１のコンピュータまたは
第２のコンピュータにあるキャッシュは、コンピュータ
の特定のハードウェア構成に基づく任意の容量とするこ
とができる。これらのキャッシュには、各通信につい
て、通信のURL、巡回冗長検査（CRC）などの通信内容に
基づく固有識別子、キャッシュ項目の作成またはリフレ
ッシュが行われた時刻を示すデータ格納時刻（SDT）、
および通信のデータを含む情報が格納される。したがっ
て、キャッシュに格納されている各通信についてキャッ
シュ項目のディレクトリを作成することができる。さら
に、所与のハードウェア構成で使用可能な資源は限られ
ているため、第１のコンピュータおよび第２のコンピュ
ータにあるキャッシュを維持するために当業者に周知の
任意の数のキャッシング技法を使用することができる。
したがって、たとえば、新しい項目の追加によってユー
ザ定義キャッシュサイズを超える場合、キャッシュは最
も古いディレクトリ項目を無効化し、無効化された項目
の代わりに新しい項目を追加することができる。さら
に、ウェブ・ブラウザ・アプリケーションまたはウェブ
・サーバ・アプリケーションの複数のインスタンスにわ
たって、あるいは第１または第２のコンピュータの電源
投入サイクルについてさえもキャッシュ項目を維持して
持続キャッシュを作成することができる。 以下に、クライアント側インタセプタ・モジュール30
とサーバ側インタセプト・モジュール40の動作を示すフ
ローチャートである第３図ないし第６図を参照しながら
本発明の一態様によるキャッシング構造について説明す
る。 具体的に第３図を参照すると、ブロック100はクライ
アント側インタセプト・モジュール30がウェブ・ブラウ
ザ10から要求を受け取ったことを示している。この要求
は、HTTPデータ・ストリームの形式をとることができ
る。ブロック105に示すように、クライアント側インタ
セプト・モジュール30は着信した要求のユニフォーム・
リソース・ロケータ（URL）を検査する。クライアント
側インタセプト・モジュール30はURLから、ウェブ・ブ
ラウザ発信要求に対応する情報が前に第１のコンピュー
タにある第１のクライアント・キャッシュに格納されて
いるかどうかを判断する。 URLに対応する情報が前にクライアント・キャッシュ
に格納されていなかった場合、ブロック106に示す操作
がクライアント側インタセプト・モジュールによって行
われる。クライアント側インタセプト・モジュール30は
外部通信リンク35でサーバ側インタセプト・モジュール
40に要求を送る。 しかし、ブロック105に示すようにウェブ・ブラウザ
発信通信に問い合わせたときに、ウェブ・ブラウザ発信
通信に対応するクライアント・キャッシュ項目が存在す
る場合、最も単純な実施例では、その情報がHTTPデータ
・ストリームとしてウェブ・ブラウザに供給される。し
かし、第３図に示すように、本発明の好ましい実施例
は、ウェブ・ブラウザ発信通信に対応するキャッシュ項
目に対して本明細書でコヒーレンシ間隔検査と呼ぶ操作
を行う。この操作は第３図のブロック110に示されてい
る。 クライアント側インタセプト・モジュールのコヒーレ
ンシ間隔はユーザ定義とすることができ、キャッシュ項
目が陳腐化し、存在はしていてもウェブ・サーバに対し
てウェブ・ブラウザ発信通信に対応する情報を要求する
ことによって最新化しなければならなくなるまでのキャ
ッシュ項目が存在することができる時間の長さである。
ブロック110に示すコヒーレンシ間隔検査は、現在日時
をウェブ・ブラウザ発信通信に対応するキャッシュ項目
のSDTとユーザによって指定されたコヒーレンシ間隔と
の和と比較することによって行うことができる。現在日
時がこの和より大きい場合、ウェブ・ブラウザ発信通信
に対応するキャッシュ内に格納されている情報は陳腐化
しており、ブロック110の「No」に分岐する。しかし、
現在日時がSDTにユーザ定義コヒーレンシ間隔を足した
和よりも小さい場合は、ブロック110で「Yes」に分岐
し、ブロック111に示すように、そのキャッシュ項目がH
TTPデータ・ストリームとしてブラウザに供給される。
したがって、第３図のブロック100でクライアント側イ
ンタセプト・モジュール30が受け取ったブラウザ発信通
信が完了する。 ブロック110に示すコヒーレンシ間隔検査によって、
第１のコンピュータにあるキャッシュ項目が陳腐化して
いると判断された場合、サーバ側インタセプト・モジュ
ール40に対して要求を行い、第２のコンピュータにある
キャッシュ項目のコヒーレンシを検査する。この操作は
第３図のブロック112に示されている。これは、外部通
信リンク35を介してサーバ側インタセプト・モジュール
40に、特定のクライアント側インタセプト・モジュール
30のコヒーレンシ間隔と、ウェブ・ブラウザ10によって
発信されたHTTP要求と、ウェブ・ブラウザ発信通信のUR
Lに対応するクライアント・キャッシュの内容を示す固
有の標識を供給することによって行われる。好ましい実
施例では、この固有の標識はキャッシュ項目の巡回冗長
検査（CRC）である。 次に第５図を参照すると、外部通信リンク35を介して
クライアント側インタセプト・モジュール30から受け取
った情報に応答したサーバ側インタセプト・モジュール
操作が示されている。サーバ側インタセプト・モジュー
ル40がクライアント側インタセプト・モジュールから要
求を受け取ると、サーバ側インタセプト・モジュール40
は所定のクライアント・コヒーレンシ時間間隔と、クラ
イアント・キャッシュ項目のCRC値と、ウェブ・ブラウ
ザによって発信されたHTTP要求を受け取る。この情報の
受信は、第５図のブロック120に示されている。 クライアント側インタセプト・モジュール30から情報
を受け取った後、サーバ側インタセプト・モジュール40
は第２のコンピュータにあるそのサーバ・キャッシュを
検査して、ウェブ・ブラウザによって発信されたHTTP要
求のURLに対応するサーバ・キャッシュ項目が存在する
かどうかを判断する。ブロック125に示すようにウェブ
・ブラウザ発信通信に問い合わせた後、サーバ側インタ
セプト・モジュール40が、ウェブ・ブラウザ発信通信に
よって要求された情報に対応するキャッシュ項目が存在
すると判断した場合、ブロック125で「Yes」分岐をと
る。次に、サーバ側インタセプト・モジュール40はSSI
モジュール40の現在日時を、ウェブ・ブラウザ発信通信
によって要求された情報に対応するサーバ・キャッシュ
項目のSDTとクライアント側インタセプト・モジュール
から受け取った所定のクライアント・コヒーレンシ時間
間隔との和と比較する。 現在日時がサーバ・キャッシュ項目のSDTとコヒーレ
ンシ間隔との和より小さい場合、第５図のブロック130
の「Yes」経路をとる。次にサーバ側インタセプト・モ
ジュール40はサーバ・キャッシュ項目のCRCとクライア
ント・キャッシュのCRCとを比較して、その２つのキャ
ッシュ項目が同じかどうかを判断する。２つのキャッシ
ュ項目が同じ場合、ブロック135の「Yes」分岐をとり、
ブロック136に示すように、「コヒーレント」応答がク
ライアント側インタセプト・モジュール30に送られる。 ブロック135の条件で、CRCが等しくないと判断された
場合、クライアント・キャッシュに入っている情報とサ
ーバ・キャッシュに入っている情報は同じでなく、ブロ
ック137に示すようにサーバ側インタセプト・モジュー
ルは外部通信リンクを介して第１のコンピュータにサー
バ・キャッシュ項目を送る。サーバ・キャッシュ項目を
クライアント側インタセプト・モジュール30に送信する
際に、サーバ側インタセプト・モジュールはその項目
を、サーバ・キャッシュ項目のCRCと、サーバ・キャッ
シュ項目データと、サーバ・キャッシュ項目のエージと
を含むクライアント固有通信プロトコルに変換する。サ
ーバ・キャッシュ項目のエージは、現行日時からキャッ
シュ項目のSDTを引くことによって計算する。 第５図に関して最後に、SDTに所定のクライアント・
コヒーレンシ時間間隔を足した和が現在日時よりも小さ
いか、またはウェブ・ブラウザ発信通信のURLに対応す
る項目がない場合、それぞれブロック130の「No」経路
またはブロック125の「No」経路がとられる。したがっ
て、ブロック126の操作が行われ、サーバ側インタセプ
ト・モジュール40がサーバにウェブ・ブラウザ発信通信
をHTTPデータ・ストリームとして送ることになる。サー
バ側インタセプト・モジュール40がウェブ・ブラウザ発
信通信をサーバにHTTPデータ・ストリームとして送らな
ければならない場合、サーバ側インタセプト・モジュー
ル40は第６図の操作を実行する。 第６図のブロック140に示すように、ウェブ・ブラウ
ザ発信通信に応答して、サーバ側インタセプト・モジュ
ールがウェブ・サーバ20からHTTPデータ・ストリームを
受け取る。HTTPデータ・ストリームを受け取ると、サー
バ側インタセプト・モジュール40はHTTPデータ・ストリ
ームのCRCを計算し、HTTPデータ・ストリームを一時的
に格納する。次に、ブロック145に示すように、サーバ
側インタセプト・モジュールはHTTPデータ・ストリーム
に問い合わせて、HTTPデータ・ストリームのURLに対応
するサーバ・キャッシュ項目が存在するかどうかを判断
する。そのような項目が存在しない場合、ブロック145
の「Yes」経路が実行される。次にサーバ側インタセプ
ト・モジュール40は、ブロック150に示すように、ウェ
ブ・サーバ20から受け取ったHTTPデータ・ストリームの
最も最近に計算されたCRCを、ウェブ・サーバ発信応答
通信のURLに対応するサーバ・キャッシュ項目のCRCと比
較する。CRCが同じ場合、ブロック150の「Yes」分岐が
行われる。サーバ側インタセプト・モジュール40はブロ
ック151に示すようにサーバ・キャッシュ項目のSDT項目
を更新し、ブロック152に示すようにウェブ・サーバ20
によって受信されたHTTPデータ・ストリームを一時格納
域から除去する。 CRC比較の結果によって、サーバ・キャッシュ項目が
ウェブ・サーバ20から受け取ったHTTPデータ・ストリー
ムと異なることが示された場合、ブロック150の「No」
経路が行われる。サーバ側インタセプト・モジュール40
はブロック153に示すようにサーバ・キャッシュから既
存のデータを除去し、次にブロック154に示すようによ
り新しい方の情報によってサーバ・キャッシュを更新す
る。ブロック154に示すように、この更新にはサーバ・
キャッシュにウェブ・サーバ通信のCRCを格納するステ
ップと、キャッシュ項目の一部として現在日時をキャッ
シュ項目のSDTとして格納するステップと、HTTPデータ
・ストリームを格納するステップとが含まれる。サーバ
・キャッシュ項目を更新するかどうか、またはサーバ・
キャッシュ項目がウェブ・サーバ20から受け取ったHTTP
データ・ストリームと同じであることが判明したかどう
かを問わず、いずれの場合もサーバ側インタセプト・モ
ジュールは次にサーバ・キャッシュ項目がウェブ・ブラ
ウザ発信通信に対応するクライアント・キャッシュ項目
と同じかどうかを判断する。この操作をブロック155に
示す。 サーバ側インタセプト・モジュール40が、ウェブ・サ
ーバ20から受け取った応答に対応するキャッシュ項目が
存在しないと判断した場合、ブロック145の「No」経路
がとられる。ブロック146に示すように、ウェブ・サー
バからの応答のURLを格納し、ウェブ・サーバからの応
答のCRCを格納し、HTTPデータ・ストリームを格納し、S
DTとして現在日時を格納することによって、サーバ・キ
ャッシュ項目が作成される。ウェブ・ブラウザ発信通信
に対応するキャッシュ項目を作成した後、サーバ側イン
タセプト・モジュール40は次に、ブロック155に示すよ
うに、再度、このサーバ・キャッシュ項目のCRCを対応
するクライアント・キャッシュのCRCと比較する。 サーバ・キャッシュ項目とクライアント・キャッシュ
項目との比較の結果によって、キャッシュ項目が同じで
あることがわかった場合、ブロック155の「Yes」分岐が
とられ、ブロック156の操作が行われる。ブロック156に
示すように、サーバ側インタセプト・モジュール40がク
ライアント側インタセプト・モジュール30に応答を送
る。サーバ側インタセプト・モジュール40は、クライア
ント側インタセプト・モジュールにコヒーレント応答を
送り、ゼロのエージを送ることによって、サーバ要求キ
ャッシュ項目をクライアント／サーバ固有データ・スト
リームに変形する。 サーバ側インタセプト・モジュール40が、クライアン
ト・キャッシュ項目がウェブ・ブラウザ発信通信に対応
するサーバ・キャッシュ項目と同じではないと判断した
場合、ブロック155の「No」分岐がとられ、ブロック157
の操作が行われる。ブロック157に示すように、サーバ
側インタセプト・モジュール40は、サーバ・キャッシュ
項目をクライアント／サーバ固有データ・ストリームに
変換または変形する。このデータ・ストリームには、サ
ーバ・キャッシュ項目のCRCと、サーバ・キャッシュ項
目HTTPデータ・ストリームと、キャッシュ項目のゼロに
設定されたエージとが含まれる。このクライアント／サ
ーバ固有通信は次に外部通信リンク35を介してクライア
ント側インタセプト・モジュール30に送信される。 サーバ側インタセプト・モジュールから通信を受け取
ったときのクライアント側インタセプト・モジュール30
の機能について、第４図を参照しながら以下に説明す
る。ブロック160に示すように、クライアント側インタ
セプト・モジュール30は外部通信リンク35を介して送信
されたクライアント／サーバ固有データ・ストリームを
受信または入手する。クライアント側インタセプト・モ
ジュールは次に、ブロック165に示すように、サーバ側
インタセプト・モジュール40からどのようなタイプの応
答を受け取ったかを判断する。サーバ側インタセプト・
モジュール40が、クライアントがクライアント・キャッ
シュ項目がコヒーレントであること、すなわちサーバ・
キャッシュ項目とクライアント・キャッシュ項目が同じ
であることを示している場合、ブロック166に示す操作
が行われる。ブロック166に示すように、クライアント
側インタセプト・モジュール30は、現在日時とサーバ側
インタセプト・モジュール40から受け取ったエージとの
差を使用してウェブ・ブラウザ発信通信に対応するクラ
イアント・キャッシュ項目のSDTを更新する。したがっ
て、本発明は、第１のコンピュータ５と第２のコンピュ
ータ６の２つのクロックの同期をとらずに、第１のコン
ピュータのキャッシュ項目のコヒーレンシ時間を更新し
て第２のコンピュータの新しい方のデータを反映させた
ことになる。ウェブ・ブラウザ発信通信に対応するクラ
イアント・キャッシュ項目のSDTを更新した後、クライ
アント側インタセプト・モジュール30はクライアント・
キャッシュ項目をウェブ・ブラウザ10にHTTPデータ・ス
トリームとして転送する。この操作をブロック174に示
す。 しかし、クライアント側インタセプト・モジュール30
が応答のタイプがデータまたはデータ・ストリーム応答
であると判断した場合は、ブロック165から「ストリー
ム」経路をとり、ブロック167の操作が行われる。クラ
イアント側インタセプト・モジュール30はHTTPデータ・
ストリームを受け取り、そのデータを一時的に格納す
る。次に、第４図のブロック170に示すように、クライ
アント側インタセプト・モジュール30は、ウェブ・ブラ
ウザ発信通信に対応するキャッシュ項目が存在するかど
うかを判断する。キャッシュ項目が存在する場合、ブロ
ック170の「Yes」経路をとって、ブロック171に示すよ
うに、既存のキャッシュ項目がフラッシュされる。クラ
イアント側インタセプト・モジュールは次に、サーバ側
インタセプト・モジュール40から受け取ったHTTPデータ
・ストリームのCRCを格納し、現在日時とサーバ側イン
タセプト・モジュール40から受け取ったエージとの差を
SDTとして格納し、HTTPデータ・ストリームを格納する
ことによって、ウェブ・ブラウザ発信通信に対応するク
ライアント・キャッシュ項目を更新する。この操作をブ
ロック172に示す。 ウェブ・ブラウザ発信通信に対応するキャッシュ項目
が存在しない場合、ブロック170の「No」経路が取られ
る。ブロック173に示す操作を行うことによってクライ
アント・キャッシュ項目が作成される。ブロック173に
示すように、クライアント側インタセプト・モジュール
30は、サーバ側インタセプト・モジュール40から受け取
ったHTTPデータ・ストリームのURLを格納し、サーバ側
インタセプト・モジュール40から受け取ったHTTPデータ
・ストリームのCRCを格納し、HTTPデータ・ストリーム
を格納することによって、クライアント・キャッシュ項
目を作成する。また、クライアント側インタセプト・モ
ジュール30は、サーバ側インタセプト・モジュール40か
ら外部通信リンク35を介して受け取ったエージSDTを現
在日時から引くことによって、SDTを更新または格納す
る。 しかし、ブロック166、172、173のいずれの操作によ
ってクライアント・キャッシュ項目が作成されるかを問
わず、クライアント側インタセプト・モジュールはクラ
イアント・キャッシュ項目をHTTPデータ・ストリームと
してウェブ・ブラウザ10に転送または供給する。これら
の操作は第４図のブロック174に示されている。 当業者ならわかるように、クライアント・キャッシュ
とサーバ・キャッシュは、メモリによって、またはハー
ド・ディスク、読書きCD−ROM、光ディスク、その他の
格納技法などの大容量格納装置によって実装することが
できる。さらに、当業者ならわかるように、クライアン
ト側インタセプト・モジュールとサーバ側インタセプト
・モジュールは、ソフトウェア、ハードウェア、または
その組合せによって実装することができる。 特定の第１または第２のコンピュータにあるキャッシ
ュについて言及したが、当業者ならわかるように、本発
明の利点は、キャッシュが第１のコンピュータにではな
く、単に外部通信リンクの第１のコンピュータと同じ側
にある場合でも得られる。したがって、ハードウェア・
キャッシュをクライアント・キャッシュとして機能する
第１のコンピュータの外部に実装し、高速通信によって
第１のコンピュータに接続することもでき、しかもその
場合でも、キャッシュが外部通信リンクの第１のコンピ
ュータと同じ側にある限り、本発明の利点が得られる。 本発明の他の実施例では、サーバ側インタセプト・モ
ジュール40は、ウェブ・サーバ20から受け取ったHTTPデ
ータ・ストリームのコピーを維持せず、単にその通信の
ディレクトリ項目を維持するに過ぎない。このディレク
トリ項目には、通信のURLと、HTTPデータ・ストリーム
のために計算されたCRCと、HTTPデータ・ストリームを
ウェブ・サーバから受け取った時刻と、その通信のSDT
とが含まれ、このSDTはCRCを計算した時刻に設定するこ
とができる。このような場合、クライアント側インタセ
プト・モジュール30はサーバ側インタセプト・モジュー
ル40に対して、サーバ側インタセプト・モジュールがCR
CとSDTを維持していたURLに対応する通信を求める要求
を送り、、次にサーバ側インタセプト・モジュール30は
クライアント側インタセプト・モジュール30から受け取
ったCRCを検査して、それが指定されたURLの最新のHTTP
データ・ストリームに対応しているかどうかを判断す
る。一致している場合、クライアント側インタセプト・
モジュールにコヒーレント応答が送られる。一致してい
ない場合、サーバ側インタセプト・モジュールは、クラ
イアント側インタセプト・モジュールから受け取ったHT
TPデータ・ストリームをウェブ・サーバ20に送り、ウェ
ブ・サーバ20から受け取った応答をクライアント側イン
タセプト・モジュール30に返す。 第７図、第８図、第９図、および第10図に、本発明の
他の態様においてクライアント側インタセプト・モジュ
ール30とサーバ側インタセプト・モジュール40によって
行われる操作を示す。この態様は、差分計算を使用し
て、外部通信リンク35を介して伝送されるデータを削減
する。第７図を参照すると、ブロック200にクライアン
ト側インタセプト・モジュール30によるウェブ・ブラウ
ザ10からのHTTP要求の受信が示されている。ブロック20
5に示すように、クライアント側インタセプト・モジュ
ール30はウェブ・ブラウザ10からのインタセプトしたHT
TP要求に問い合わせて、その要求が共通ゲートウェイ・
インタフェース（CGI）に送るものかどうかを判断す
る。要求が共通ゲート・インタフェースに送るものでな
い場合、クライアント側インタセプト・モジュール30
は、第３図ないし第６図に示し、第７図のブロック206
に図示するように、その要求をサーバ側インタセプト・
モジュールに渡す。 しかし、ウェブ・ブラウザ発信通信がCGI要求に対応
する場合、ブロック205の「Yes」経路がとられる。ブロ
ック210に示すように、クライアント／サーバ・インタ
セプト・モジュール30は、対応するCGI要求に応答して
前にウェブ・ブラウザに供給されていたHTTPデータ・ス
トリームに対応するクライアント・ベース・キャッシュ
項目が存在するかどうかを判断する。このCGI要求の問
い合わせは、ウェブ・ブラウザ発信通信のURLをクライ
アント・ベース・キャッシュに格納されているURLと比
較することによって行うことができる。 クライアント・ベース・キャッシュは、所与のURLに
ついてウェブ・ブラウザ10に供給するクライアント側イ
ンタセプト・モジュール30が受信した最初のHTTPデータ
・ストリームを格納することによって初期設定すること
ができる。このベース・キャッシュ項目は、ウェブ・ブ
ラウザ10の多くのインスタンスまたはセッションにわた
って維持することができる。クライアント・ベース・キ
ャッシュ項目は、第７図、第８図、第９図、および第10
図に示すように更新することができる。ウェブ・ブラウ
ザ発信通信のURLに対応するクライアント・ベース・キ
ャッシュ項目が存在する場合、第７図のブロック211に
示すように、外部通信リンク35を介してサーバ側インタ
セプト・モジュール40に送るCRCが、クライアント・ベ
ース・キャッシュ項目のCRCに等しく設定される。クラ
イアント・ベース・キャッシュ項目がない場合、第７図
のブロック210から「No」経路をとり、外部通信リンク3
5を介してサーバ側インタセプト・モジュール40に送る
要求のCRCがナルにされる。この操作は第７図のブロッ
ク212に示されている。 ブロック213に、CGI要求を外部通信リンクを介してサ
ーバ側インタセプト・モジュール40に送る操作を示す。
ブロック213に示すように、クライアント側インタセプ
ト・モジュール30がHTTP要求と要求CRCを送る。要求CRC
は、CGI要求のURLのクライアント・ベース・キャッシュ
項目が存在しない場合にはナルに設定されており、クラ
イアント・ベース・キャッシュ項目が存在する場合には
その項目のCRCに設定されている。したがって、クライ
アント側インタセプト・モジュールは、CGI要求をクラ
イアント／サーバ固有プロトコルに変換し、そのクライ
アント／サーバ固有通信を外部通信リンクを介して送信
して、サーバ側インタセプト・モジュール40が受信する
ようにしたことになる。 CGI要求を受け取るときのサーバ側インタセプト・モ
ジュールの動作を第９図に示す。サーバ側インタセプト
・モジュール40によるCGI要求の受信がブロック220に示
されている。サーバ側インタセプト・モジュール40はCG
I要求を受け取ると、CRC値とHTTP要求のコピーを保存す
る。ブロック221に示すように、サーバ側インタセプト
・モジュール40はHTTP要求をウェブ・サーバ20に渡す。 第10図のブロック230に示すように、サーバ側インタ
セプト・モジュール40がウェブ・ブラウザ発信通信また
はCGI要求に対応するHTTP要求に対する応答を受け取る
とき、サーバ側インタセプト・モジュール40はこの応答
をHTTPデータ・ストリームとして受け取る。ブロック23
0に示すように、サーバ側インタセプト・モジュール40
は、HTTPデータ・ストリームを保存し、ウェブ・サーバ
20から受け取ったHTTPデータ・ストリームのCRC値を計
算する。また、サーバ側インタセプト・モジュール40
は、差分値をナルにして差分データを初期設定する。次
に、ブロック235に示すように、サーバ側インタセプト
・モジュールは、ウェブ・サーバ発信通信として受け取
った応答がCGI要求に対する応答であるかどうかを判断
する。答えが否定の場合、第10図のブロック235から「N
o」経路をとり、ブロック236の操作を実行して、HTTPデ
ータ・ストリームがクライアント側インタセプト・モジ
ュールに送る。ブロック236に示すように、この操作に
は第３図ないし第６図で説明したキャッシング操作が必
要な場合がある。ブロック230で受け取った応答がCGIに
対する応答の場合、ブロック235の「Yes」経路をとり、
サーバ側インタセプト・モジュールは次に、ブロック24
0に示すように、CGI応答のサーバ・ベース・キャッシュ
項目が存在するかどうかを判断する。 サーバ側インタセプト・モジュール40がCGI要求に対
する応答を初めて受け取ったとき、サーバ・ベース・キ
ャッシュ項目を作成することができる。この場合、ブロ
ック240に示す条件の結果によって、ブロック240から
「No」経路がとられる。次に、サーバ側インタセプト・
モジュール40は、CGIのURLと、CGI要求に対する応答のH
TTPデータ・ストリームと、HTTPデータ・ストリームのC
RCとを格納することによって、サーバ・ベース・キャッ
シュ項目を作成する。この操作をブロック241に示す。
第３図ないし第６図で説明したコヒーレント・キャッシ
ュとの互換性を持たせるために、サーバ・ベース・キャ
ッシュ項目にはSDTも組み込むことができる。本明細書
では、サーバCGIベース書式という用語を使用して、ウ
ェブ・ブラウザ10から受け取ったCGI要求に対応するサ
ーバ・ベース・キャッシュ項目を指す。 CGI要求に対応するサーバ・ベース・キャッシュ項目
がある場合、ブロック240の「Yes」経路がとられる。サ
ーバ側インタセプト・モジュールはサーバ・ベース・キ
ャッシュ項目のCRCを、ウェブ・サーバ20から受け取っ
た応答のCRCと比較する。これらの操作を第10図のブロ
ック245に示す。CRCが同じ場合、サーバ側インタセプト
・モジュールは、サーバ・ベース・キャッシュ項目のCR
Cがクライアント・ベース・キャッシュ項目のCRCに対応
するかどうかを判断する。この２つのCRC値が同じ場
合、クライアント・ベース・キャッシュ項目と、サーバ
・ベース・キャッシュ項目と、ウェブ・サーバ20から受
け取った応答のすべてがHTTPデータ・ストリームに入れ
られる。サーバ・ベース・キャッシュ項目とクライアン
ト・ベース・キャッシュ項目との比較をブロック250に
示す。 ２つのベース・キャッシュ項目が同じ場合、サーバ側
インタセプト・モジュールはベース・キャッシュ項目を
クライアント側インタセプト・モジュール30に送る必要
がなく、したがって、ブロック251に示すように、クラ
イアント側インタセプト・モジュール30に送るHTTPデー
タ・ストリーム・データをナルにする。次に、ブロック
252に示すように、サーバ側インタセプト・モジュール4
0は、CGI要求に対応するサーバ・ベース・キャッシュに
格納されているHTTPデータ・ストリームのCRCと、ナル
にしたHTTPデータ・ストリームと、ナルにした差分デー
タとを送信して、CGI要求がクライアント・ベース・キ
ャッシュ項目と同じであったことを示すことによって、
ウェブ・サーバ20から受け取ったHTTPデータ・ストリー
ムをクライアント／サーバ固有通信プロトコルに変換す
る。 ブロック245に戻って、CGI要求に対応するサーバ・ベ
ース・キャッシュ項目のCRCが、ウェブ・ブラウザによ
って発信されたCGI要求に応答してウェブ・サーバから
受け取った応答のCRCと異なる場合、ブロック245から
「No」経路がとられる。次に、サーバ側インタセプト・
モジュール40はブロック246に示す操作を行う。サーバ
側インタセプト・モジュール40は、インタセプトしたCG
I応答を、インタセプトしたCGIに対応するサーバ・ベー
ス・キャッシュ項目すなわちサーバCGIベース書式と比
較する。このインタセプトしたCGI応答とサーバCGIベー
ス書式との比較によって、インタセプトしたCGI応答と
サーバCGIベース書式との差分に対応するCGI差分データ
が得られる。 差分計算は、ベース書式と修正済み書式との間の差分
を求める当業者に周知の任意の方法で行うことができ
る。本発明で使用するのに適した差分計算の一方法は、
コピーターズ（Coppieters）による“Cross−Platform
Binary Diff"（Dr.Dobb's Journal 1995年５月号32〜3
6ページ）に記載されており、その開示は参照により、
その全部が記載されているかのように本明細書に組み込
まれる。差分データを求める際に使用することができる
その他の方法には、“IBM Technical Disclosure Bulle
tin（Vol.22,No.8A、1980年１月）に記載されている方
法が含まれ、これも参照によりその全部が記載されてい
るかのように本明細書に組み込まれる。次に、ブロック
247に示すように、サーバ側インタセプト・モジュール4
0はサーバCGIベース書式が更新を必要とするかどうかを
判断する。この判断は、インタセプトされたCGI応答と
サーバCGIベース書式との平均差分データが所定のしき
い値を超えているかどうかを判断することによって行う
ことができる。CGI要求に対応するサーバ・ベース・キ
ャッシュ項目を更新する必要があるかどうかを判断する
他の方法には、第３図ないし第６図で説明したような時
間コヒーレンシ方式や、ベース変更を行って新しいベー
ス・キャッシュ項目を作成すればシステム・パフォーマ
ンスが向上するほど差分データが増加したかどうかを判
断する当業者に周知のその他の方法が含まれる。 サーバのベース変更計算が不要な場合、ブロック247
から「No」経路がとられ、サーバ側インタセプト・モジ
ュール40はブロック250の操作を行って、クライアント
・ベース・キャッシュ項目のCRCがサーバ・ベース・キ
ャッシュ項目のCRCと同じかどうか、またはサーバCGIベ
ース書式が、ウェブ・ブラウザ発信通信のその特定のCG
I要求に対応するサーバとクライアントのベース・キャ
ッシュ項目であるクライアントCGIベース書式と同じか
どうかを判断する。ベース書式が同じ場合、クライアン
トはベース変更を行う必要がなく、ブロック251に示す
ようにHTTPデータ・ストリーム情報がナルにされる。次
に、サーバ側インタセプト・モジュール40は、CGI要求
に対応するサーバ・ベース・キャッシュ項目のCRC（す
なわちサーバCGIベース書式のCRC）を送り、ベース・デ
ータに対応するナルにしたHTTPデータ・ストリームを送
り、ブロック246で求めた差分データを送ることによっ
て、クライアント側インタセプト・モジュール30に差分
応答を送る。これらの操作は第10図のブロック252とし
て示されている。 サーバ側インタセプト・モジュール40が、クライアン
トCGIベース書式とサーバCGIベース書式のCRSが同じで
ないと判断した場合、クライアントのベース変更計算を
行う必要がある。クライアントのベース変更操作は、ク
ライアント側インタセプト・モジュール30にサーバCGI
ベース書式を送るステップを含む。この操作を行うため
に、サーバ側インタセプト・モジュールはクライアント
側インタセプト・モジュール30に送るHTTPデータ・スト
リーム・データを、サーバCGIベース書式と等しく設定
する。この操作をブロック253に示す。次に、サーバ側
インタセプト・モジュール40は、ブロック252に示すよ
うに、サーバCGIベース書式のCRCと、サーバCGIベース
書式に対応するHTTPデータ・ストリーム・データを送信
し、CGIベース書式とウェブ・サーバから受け取った応
答との差分データを送信することによって、ウェブ・サ
ーバから受け取ったHTTPデータ・ストリームをクライア
ント／サーバ固有プロトコルに変換する。次にこの情報
を外部通信リンク35を介してクライアント側インタセプ
ト・モジュール30に送る。 ブロック247に戻って、サーバのベース変更が必要な
場合、ブロック247から「Yes」経路がとられる。ブロッ
ク248に示すように、サーバ側インタセプト・モジュー
ルは、ウェブ・サーバから受け取ったHTTPデータ・スト
リームを使用してブラウザ発信通信に対応するサーバ・
ベース・キャッシュを更新する。応答のCRCも更新さ
れ、CGI差分データがナルにされる。次に、サーバ側イ
ンタセプト・モジュールは、ブロック250に示すように
新しいサーバ側キャッシュ項目のCRCを比較し、前述の
ようにこの転送を完了する。 サーバ側インタセプト・モジュール40から応答を受け
取ったときのクライアント側インタセプト・モジュール
の操作を第８図に示す。クライアント側インタセプト・
モジュール30によるサーバ側インタセプト・モジュール
40からの応答の受信は、ブロック260に示されている。
ブロック265に示すように、クライアント側インタセプ
ト・モジュール30は、応答がCGI要求に対する応答かど
うかを判断する。応答がCGI要求に対する応答ではない
場合、クライアント側インタセプト・モジュールはブロ
ック267の操作を行う。この操作には、第３図ないし第
６図に示すキャッシュ操作を組み込むことができる。し
かし、応答がCGI要求に対する応答の場合、ブロック265
から「Yes」経路がとられる。クライアント側インタセ
プト・モジュール30は、外部通信リンクを介して送信さ
れたクライアント／サーバ固有データ・ストリームから
入手した、HTTPデータ・ストリーム・データと、差分デ
ータと、CRCとを保管する。これらの操作は第８図のブ
ロック266に示されている。 次に、クライアント側インタセプト・モジュール30
は、CGIベース書式を含むインタセプトされたCGI要求に
対応するクライアント・ベース・キャッシュ項目が存在
するかどうかを判断する。この問い合わせはブロック27
0に示されており、HTTP要求またはHTTP応答のURLを調べ
ることによって行うことができる。クライアントCGIベ
ース書式が存在する場合、ブロック270から「Yes」経路
がとられる。次に、ブロック275に示すように、クライ
アント側インタセプト・モジュール30は外部通信リンク
を介して受け取ったCRCを、クライアントCGIベース書式
のCRCと比較する。CRCが異なる場合、ブロック275から
「No」経路がとられ、クライアントは、ウェブ・ブラウ
ザ発信通信にのCGI要求のURLに対応するクライアント・
ベース・キャッシュ項目を、外部通信リンク35を介して
サーバ側インタセプト・モジュール40から受け取ったHT
TPデータ・ストリーム・データに置き換えてCGIベース
書式を更新することによって、ベース変更を行う。クラ
イアント・ベース・キャッシュ項目も、HTTPデータ・ス
トリームのCRCを基準にして更新される。これらの操作
は第８図のブロック276に示されている。 外部通信リンク35を介して受け取ったCRCがCGIベース
書式と同じ場合、サーバ側インタセプタ・モジュール・
サーバCGIベース書式は、クライアント側インタセプト
・モジュール・クライアントCGIベース書式と同じであ
り、ブロック275の「Yes」経路がとられる。 ベース書式が同じであるかクライアントをベース変更
するかを問わず、クライアント側インタセプタ・モジュ
ール30によってブロック277に示す操作が行われる。ブ
ロック277は、クライアント側インタセプタ・モジュー
ル30が、クライアントCGIベース書式を外部通信リンク3
5を介して受け取ったCGI差分データと比較して、インタ
セプトしたCGI応答に対応するHTTPデータ・ストリーム
を作成することによって、外部通信リンク35を介して受
け取ったクライアント／サーバ固有データ・ストリーム
から、ウェブ・サーバ20から受け取った通信に対応する
HTTPデータ・ストリームを再構築する操作を示す。ブロ
ック278に示すように、この応答は次にHTTPデータ・ス
トリームとしてウェブ・ブラウザ10に供給される。 クライアントにCGI要求のURLに対応するCGIベース書
式が存在しない場合、第８図のブロック270から「No」
経路がとられる。ブロック271に示すように、クライア
ント側インタセプト・モジュール30は、URLと、サーバ
側インタセプト・モジュール40から外部通信リンクを介
して受信したHTTPデータ・ストリームのCRCと、実HTTP
データ・ストリーム・データとを格納することによって
CGI要求のURLに対応するクライアント・ベース・キャッ
シュ項目を作成する。この情報を格納することによっ
て、インタセプトされたCGI要求に対応するクライアン
ト・ベース・キャッシュ項目が作成され、したがってク
ライアントCGIベース書式が作成される。次に、クライ
アント側インタセプト・モジュールは、クライアントCG
Iベース書式をCGI差分データ（ナル化されていることが
ある）と結合またはマージすることによって、HTTPデー
タ・ストリームを再構築することでブロック277の操作
を行う。 本発明の差分計算技法は非CGIデータにも適用可能で
ある。その場合、サーバ側インタセプト・モジュール40
は、ウェブ・サーバに接続されているウェブ・ブラウザ
のクライアント側インタセプト・モジュールが異なるベ
ース書式を持っている可能性を見込んで、複数の世代の
サーバ・ベース・キャッシュ項目を維持する必要があ
る。その場合、サーバ側インタセプト・モジュールは、
一致するものが得られるまで、クライアント側インタセ
プト・モジュールから受け取ったCRCを各世代のサーバ
・ベース書式のCRCと比較する。その際、サーバ側イン
タセプト・モジュール40は、任意選択でクライアント側
インタセプト・モジュール30のベース変更を行うか、ま
たは単にクライアント側インタセプト・モジュール30に
差分データを供給することができる。したがって、本明
細書でCGI要求に関して説明した差分計算方法は、どの
ようなHTTP要求および応答にも等しく適用可能である。 複数の世代のベース書式を維持する上述のシステムで
は、非CGI要求について差分計算を使用することができ
るが、この方法はメモリまたは格納域を多用し、前述の
キャッシング機能が十分に活用されない。メモリまたは
格納域必要量を少なくし、前述のキャッシング方法を活
用するために、非CGI要求に差分計算を使用する以下の
好ましい方法を使用することできる。この好ましい実施
態様では、サーバ側インタセプト・モジュールは、要求
に対応するサーバ・ベース書式とウェブ・サーバからの
応答のHTTPデータ・ストリームとの差分を計算する。次
に、ベース書式をウェブ・サーバからの新しい応答で置
き換えることによって、サーバ・ベース書式を更新す
る。これにはベース書式のCRCの更新も含まれる。しか
し、古いCRCを廃棄するのではなく、前のベース書式のC
RCは差分データとして格納する。次に、前の世代の差分
データとCRCを、非CGI要求に対応するクライアント・ベ
ースのCRCに基づいて選択的にクライアント側インタセ
プト・モジュールに送る。 非CGI差分計算方法の一例として、サーバ側インタセ
プト・モジュールが非CGI要求を受け取った場合、その
要求には非CGI要求のURLに対応するクライアント側イン
タセプト・モジュールにあるベース書式のCRCも付随し
ていることになる。サーバ側インタセプト・モジュール
は、ウェブ・サーバから応答を受け取ると、その応答の
CRCを計算する。次に、サーバ側インタセプト・モジュ
ールは応答とURLのサーバ・ベース書式との差分を計算
し、その差分データを保管する。サーバ側インタセプト
・モジュールは、応答データを使用してサーバ・ベース
書式を更新し、前のベース書式のCRCと、応答と古いベ
ース書式との間の差分データとをアーカイブする。次
に、サーバ側インタセプト・モジュールは、クライアン
ト・ベース書式のCRCをサーバ・ベース書式のCRCおよび
格納またはアーカイブされているCRCと比較し、一致し
ているものがあるかどうかを判断する。一致が見つから
ない場合、その応答は単にクライアント側インタセプト
・モジュールに送られる。 一致が見つかった場合、一致するCRCに対応する差分
データと、それ以降の、現行差分データを含む現行差分
データまでの差分データがクライアント側インタセプト
・モジュールに送られる。クライアント側インタセプト
・モジュールは、その差分データをクライアント・ベー
ス書式に適用して応答を再構築する。したがって、３世
代古いベース書式のCRCについてCRC一致があった場合、
３セットの差分データがクライアント側インタセプト・
モジュールに送られることになり、３セットの連続した
差分データをクライアント・ベース書式に適用すること
によって、応答の構築が行われることになる。しかし、
応答を再構築するのに必要な差分データ・セットの数が
多すぎるかまたは差分データ・セットの大きさが大き過
ぎて、実応答を送信した方がデータ転送が少なくて済む
場合、サーバ側インタセプト・モジュールは応答自体を
送信することができる。いずれにしても、応答の再構築
または受信の後、クライアント側インタセプト・モジュ
ールは、要求のURLのクライアント・ベース書式を応答
データによって更新し、CRCを要求のCRCで更新する。ク
ライアント・ベース書式は特定のURLについて応答を受
信するたびに更新されるため、非CGI要求に対して差分
計算を使用した場合、上述のクライアント・キャッシュ
をクライアント・ベース書式のキャッシュとして使用す
ることができ、それによってクライアント・ベース書式
の別個のキャッシュを不要にすることができる。 本発明の他の態様では、HTTPなどのステートレス通信
プロトコルの冗長性に基づいて、通信をさらに節約する
ことができる。そのようなプロトコルでは、クライアン
トは通信を開始するたびにクライアント自体に関する情
報をサーバに送信する。同様に、サーバは応答を出すた
びにサーバ自体に関する特定の情報をクライアントに伝
達する。 本発明の一実施例では、第１のコンピュータ５は第２
のコンピュータ６に、第１のコンピュータの事前定義特
性に対応するコンピュータ固有情報を伝達する。第２の
コンピュータはこのコンピュータ固有情報を格納する。
次に、第１のコンピュータはそれ以降のウェブ・ブラウ
ザ発信通信からそのコンピュータ固有情報を除去してか
ら外部通信リンク35で発信する。第２のコンピュータ６
は、外部通信リンク35を介して受信したそれ以降の通信
と格納しているコンピュータ固有情報とを組み合わせて
HTTPデータ・ストリームを作成することによって、元の
ウェブ・ブラウザ発信通信を再構築する。 ウェブ・ブラウザによって発信される信号からコンピ
ュータ固有情報を除去するほかに、このコンピュータ固
有情報をウェブ・サーバによって発信される通信からも
除去することができる。その場合、第２図の第２のコン
ピュータ６は第１のコンピュータ５に外部通信リンク35
を介して、第２のコンピュータ６の事前定義特性に対応
するコンピュータ固有情報を供給する。第１のコンピュ
ータ５はそのコンピュータ固有情報を格納して、サーバ
・ヘッダ情報を備える。その後の通信の時には、第２の
コンピュータ６はウェブ・サーバ発信通信からコンピュ
ータ固有情報を除去し、ウェブ・サーバ発信通信の残り
の部分を外部通信リンク35で送信する。第１のコンピュ
ータ５は外部通信リンクでその通信を受信し、サーバ・
ヘッダ情報を外部通信リンクを介して受信したクライア
ント／サーバ固有データ・ストリームと結合してHTTPデ
ータ・ストリームを作成することによって、元のウェブ
・サーバ発信通信を再構築する。どちらの場合も、操作
が第１のコンピュータ５と第２のコンピュータ６のどち
らで行われるかに応じて、コンピュータ固有情報を取り
除き、その情報を格納してサーバ・ヘッダ情報またはク
ライアント・ヘッダ情報を作成する操作がクライアント
側インタセプト・モジュール30またはサーバ側インタセ
プト・モジュール40によって行われる。 本発明の一実施例では、ウェブ・ブラウザ10は伝送制
御プロトコル／インターネット・プロトコル（TCP/IP）
を使用してクライアント側インタセプト・モジュール30
と通信する。TCPは、外部通信リンク35を介したクライ
アント側インタセプト・モジュール30とサーバ側インタ
セプト・モジュール40との間の通信にも使用することが
できる。最後に、TCPはサーバ側インタセプト・モジュ
ール40とウェブ・サーバ20との間の通信にも使用するこ
とができる。TCPは本発明のシステムを構成する様々な
構成要素間の通信に使用することができるが、HTTPプロ
トコルは外部通信リンクを介した通信にとって最も効率
的な手段を提供するものではない。外部通信リンク35の
パフォーマンスを向上させるために、本発明の一実施例
は本明細書で「仮想ソケット」と呼ぶものを作成する。
これは、ウェブ・ブラウザとクライアント側インタセプ
ト・モジュール30の間の接続と、サーバ側インタセプト
・モジュール40とウェブ・サーバ20との間の接続に使用
される。これらの仮想ソケットの動作について、第11図
ないし第17図を参照しながら以下に説明する。 第11図は、仮想ソケットを使用する本発明の１つの可
能な実施態様を示すブロック図である。第11図に示すよ
うに、第１のコンピュータ５と第２のコンピュータ６は
外部通信リンク35を介して接続されている。ウェブ・ブ
ラウザ10は、ウェブ・ブラウザ10をクライアント側イン
タセプト・モジュール30と接続する複数の実ソケットを
有する。第11図に示すように、第１の実ソケットはウェ
ブ・ブラウザ10上に65aとして図示され、それに対応す
るソケットはクライアント側インタセプト・モジュール
30上の65bである。この第１の実ソケットは、それを介
してウェブ・ブラウザ10がクライアント側インタセプト
・モジュール30に対してさらに接続を要求するTCPソケ
ットである。 ウェブ・ブラウザ10が新しいTCP接続を要求すると、
実ソケット65aを介して通信が行われ、それが実ソケッ
ト65bによって受信される。次にクライアント側インタ
セプト・モジュール30は、ウェブ・ブラウザ10との通信
のために別の実ソケットを作成する。第11図に示すよう
に、ウェブ・ブラウザ10上で複数の実ソケットが作成さ
れ、それに対応する実ソケットがクライアント側インタ
セプト・モジュール30上で作成される。これらの実ソケ
ットは、ウェブ・ブラウザ10上の60a〜64aおよびクライ
アント側インタセプト・モジュール30上の60b〜64bとし
て図示されている。これらの実ソケットは、ウェブ・ブ
ラウザ10がそれを介してクライアント側インタセプト・
モジュール30と通信するための手段である。実ソケット
60a〜64aおよび60b〜64bを作成した後、これらのソケッ
トを介した通信を多重化して実ソケット36aに送り、実
ソケット36aはクライアント側インタセプト・モジュー
ル30に外部通信リンク35へのアクセスを提供する。実ソ
ケット36aおよび36bはコンピュータ５の実ソケット37a
を介してコンピュータ６の実ソケット37bに要求を送る
ときに作成される。実ソケット37bが接続要求を受け取
ると、実ソケット36aおよび36bが作成される。ソケット
37aおよび37bは、クライアント側インタセプト・モジュ
ールとサーバ側インタセプト・モジュールとの間の通信
のための最初の実ソケットとして機能し、ソケット36a
および36bによって示されているこの２つのモジュール
の間の接続を確立するためにのみ使用することができ
る。これらの実ソケットのそれぞれは標準TCP/IPプロト
コルの下で動作する。第２のコンピュータ６が外部通信
リンク35を介して通信を受信するとき、それらの通信は
実ソケット36bで受信される。次にサーバ側インタセプ
ト・モジュール40は、ソケット36bで受信した通信を多
重化解除し、それらをウェブ・サーバ20に送信するため
に適切なソケットに供給する。したがって、たとえば、
特定のURLに対して情報を要求するためのソケット60aか
らソケット60bまでの通信は、ソケット36a上に多重化さ
れ、ソケット36bによって受信され、サーバ側インタセ
プト・モジュール40によって多重化解除され、ソケット
60cからウェブ・サーバ20上のソケット60dに送られるこ
とになる。同様に、ソケット61aを介して行われる通信
はソケット61bによって受信され、クライアント側イン
タセプト・モジュール30によって多重化され、ソケット
36aからソケット36bに送られ、そこでサーバ側インタセ
プト・モジュール40がその通信を多重化解除してソケッ
ト61cからソケット61dに送る。したがって、ソケット60
aと60b、61aと61b、62aと62b、63aと63b、64aと64bを介
した通信は、サーバ側インタセプト・モジュール40とウ
ェブ・サーバ20との間のソケット60cと60d、61cと61d、
62cと62d、63cと63d、および64cと64dのうちのそれぞれ
の対応するソケットを介して送信される。 同様に、ウェブ・サーバ20によるウェブ・ブラウザ10
からの要求に対する応答も、ウェブ・サーバ20をサーバ
側インタセプト・モジュール40に接続するソケットを介
して送られ、外部通信リンク35を介してクライアント側
インタセプト・モジュール30に送られた後、ウェブ・ブ
ラウザ10に送られる。したがって、たとえばウェブ・サ
ーバ20によって発信された応答はソケット60dから60cを
介して送られ、サーバ側インタセプト・モジュール40に
よってソケット36bに多重化され、そこから外部通信リ
ンク35を介してソケット36aに送られる。次にクライア
ント側インタセプト・モジュール30がその通信を多重化
解除し、それをソケット60bに送り、それがウェブ・ブ
ラウザ10上のソケット60aに送られる。ウェブ・ブラウ
ザ10またはウェブ・サーバ20が使用する各ソケットにつ
いて同様の通信経路が確立される。当業者ならわかるよ
うに、本発明についてウェブ・ブラウザ10とウェブ・サ
ーバ20との間の４ソケット通信に関して説明したが、ウ
ェブ・ブラウザ10とウェブ・サーバ20との間の通信アク
セスを実現するために任意の数のソケットを開くことが
できる。 第12図は、クライアント側インタセプト・モジュール
30とサーバ側インタセプト・モジュール40における仮想
ソケット・システムの実施例を示すブロック図である。
これらのモジュールの外部で、クライアント側インタセ
プト・モジュール30とウェブ・ブラウザ10およびサーバ
側インタセプト・モジュール40とウェブ・サーバ20の間
の実ソケットが、通常のTCP/IPソケットとして機能す
る。したがって、仮想ソケットの使用はウェブ・ブラウ
ザ10およびウェブ・サーバ20には透過である。 第12図のブロック図と第13図ないし第17図の流れ図を
参照しながら本発明の特定の実施例について説明する。
第13図は、第12図にブロック68として図示されているソ
ケット・マネージャのフローチャートである。第13図を
参照すると、ブロック300はクライアント側インタセプ
ト・モジュール30の実ソケット・マネージャ68の作成を
示している。実ソケット・マネージャ68が作成された
後、実ソケット・マネージャは第12図にソケット65bと
して図示されている第１の実ソケットを作成する。この
第１の実ソケットの作成は第13図のブロック301として
示されている。第１の実ソケット65bを作成した後、ク
ライアント側インタセプト・モジュール30内にあるソケ
ット・マネージャ68（本明細書ではクライアント・ソケ
ット・マネージャとも呼ぶ）は、第13図のブロック302
に示すように、第１の実ソケット65b上での事象を持
つ。第１の実ソケット65b上で事象を受け取ると、第13
図のブロック305に示すように実ソケット・マネージャ6
8はその事象を検査し、その検査に基づいて５通りの経
路のうちの１つをとる。 第１の実ソケット65bで受信した通信要求に応答して
実ソケットが作成された場合は、第13図のブロック305
から306までの経路に示すように、実ソケット・マネー
ジャ68はその実ソケットを実事象リストに追加する。次
に、実ソケット・マネージャはブロック307に示すよう
にシンプレックス仮想ソケットを作成する。クライアン
ト側インタセプト・モジュールの場合、実ソケット・マ
ネージャは、第13図のブロック308に示すように、作成
された仮想ソケットについてクライアント側インタセプ
ト・モジュールの機能を実行するアプリケーション機能
を開始する。 本明細書では、「シンプレックス・ソケット」または
「シンプレックス仮想ソケット」という用語は、単一の
ソケットまたは単一のアプリケーションに直接接続する
ソケットを指す。本明細書では、「マルチプレックスソ
ケット」とは他の複数のソケットに接続するソケットを
指す。したがって、マルチプレックスソケットは、多重
化または多重化解除機能を実行し、シンプレックス・ソ
ケットは１対１接続を行う。したがって、たとえば、第
13図のブロック306から308までの機能を実行する際、ク
ライアント・ソケット・マネージャ68は第１の実ソケッ
ト65bが受信した第１の接続要求に応答して、実ソケッ
ト60b、シンプレックス仮想ソケット70を作成し、アプ
リケーション80のクライアント側インタセプト機能を開
始することになる。実ソケットが作成されたその後の事
象の場合も同様に、実ソケット・マネージャは実ソケッ
ト61b、62b、63b、または64bとシンプレックス仮想ソケ
ット71、72、73、または74を作成し、第12図でブロック
81、82、83、または84として図示されている、作成され
た実ソケットおよび仮想ソケットに対応するCSI機能を
開始する。 以下に、クライアント側インタセプト機能の操作につ
いて、第12図に示す実ソケット60bとシンプレックス仮
想ソケット70とクライアント側インタセプト機能80とを
参照しながら説明する。第14図のブロック325はクライ
アント側インタセプト機能80の作成を示している。作成
されると、クライアント側インタセプト機能80はブロッ
ク326に示すようにシンプレックス仮想ソケット70上の
事象を待つ。この待機操作は、第16−４図に示す仮想選
択機能を実行することによって行われる。事象を受け取
ると、ブロック330に示すようにその事象が検査され
る。事象が仮想ソケット閉鎖である場合、第14図のブロ
ック349に示すようにクライアント側インタセプト機能8
0はシンプレックス仮想ソケット70を削除し、ブロック3
50に示すように終了する。 事象がデータの受信である場合、ブロック330からブ
ロック331への経路がとられ、クライアント側インタセ
プト機能80は第16−３図を参照しながら説明する仮想受
信操作を実行することによって、シンプレックス仮想ソ
ケット70からブラウザ発信通信を受け取る。次に、クラ
イアント側インタセプト機能は前述のクライアント側イ
ンタセプト・モジュールの機能（たとえば第３図および
第７図を参照）を実行する。これはブロック332に示さ
れている。次にクライアント側インタセプト機能80は、
クライアント側インタセプト・モジュール30内の実ソケ
ット36aに接続されるマルチプレックス仮想ソケット90
を作成する。実ソケット36aはサーバ側インタセプト・
モジュール40上の実ソケット36bに接続される。マルチ
プレックス仮想ソケットの作成は、第14図のブロック33
3に示されており、本明細書で第16−１図を参照しなが
ら説明する仮想作成操作を実行することによって行われ
る。ブロック334は、ウェブ・ブラウザ発信通信のため
にクライアント側インタセプト機能80が実行された後
で、実ソケット60bとシンプレックス仮想ソケット70を
介してウェブ・ブラウザから受け取った情報を送信する
操作を示す。この通信は、第16−２図を参照しながら説
明する仮想送信操作を実行することによってマルチプレ
ックス仮想ソケット90の待ち行列に入れられる。クライ
アント側インタセプト機能80は、要求をマルチプレック
ス仮想ソケット90の待ち行列に入れた後、第14図のブロ
ック335に示すようにマルチプレックス仮想ソケット90
の待ち行列に入れられているデータをフラッシュし、次
にブロック336に示すようにマルチプレックス仮想ソケ
ット上の事象を待つ。仮想フラッシュ機能は、第17−１
図を参照しながら説明する仮想フラッシュ操作を実行す
ることによって行われ、マルチプレックス仮想ソケット
待ち行列からデータを取り出してそのデータを実ソケッ
ト36aに供給する。待機機能は、第16−４図に示す仮想
選択機能を実行することによって行うことができる。こ
の時点で、クライアント側インタセプト・モジュールは
ウェブ・ブラウザ発信通信をインタセプトし、その通信
を外部通信リンク35を介してサーバ側インタセプト・モ
ジュールに送信し終わったことになる。 第13図に戻ると、サーバ側インタセプト・モジュール
40またはクライアント側インタセプト・モジュール30に
おけるソケット・マネージャのフローチャートが示され
ている。第12図のブロック69に示すように、サーバ側イ
ンタセプト・モジュール内の実ソケット・マネージャ、
すなわちサーバ・ソケット・マネージャは、ブロック68
に示すクライアント・ソケット・マネージャと同じ機能
を実行する。ブロック301に示すように、第１の実ソケ
ットを作成する際、サーバ側インタセプト・モジュール
30は、サーバ側インタセプト・モジュール40に関連づけ
られたクライアント側インタセプト・モジュール30から
のソケットの要求を受け取る「周知のポート」37bを作
成する。サーバ側インタセプト・モジュール40の実ソケ
ット36b上で実事象が発生すると、ブロック305に示すよ
うにその事象が検査される。この場合、この事象は実ソ
ケット36aからのデータの受信であり、したがって第13
図のブロック305からブロック320までの経路がとられ
る。実ソケット36b上で受信したデータが検査され、こ
の例ではデータはクライアント側インタセプト・モジュ
ールによって送信されたウェブ・ブラウザ発信通信であ
るため、サーバ側インタセプト・モジュール40において
新しい仮想ソケットを作成しなければならない。したが
って、第13図のブロック320からブロック321への経路が
とられる。次にサーバ・ソケット・マネージャ69は、第
13図のブロック321、ブロック322、ブロック323、およ
びブロック324に示す操作を行う。サーバ・ソケット・
マネージャ69はブロック321に示すようにマルチプレッ
クス仮想ソケット95を作成し、ブロック322に示すよう
にマルチプレックスソケット活動タイマをキャンセル
し、第13図のブロック323と第12図のブロック85に示す
サーバ側インタセプト機能のアプリケーションを開始す
る。実ソケット36bで受け取ったデータは次にマルチプ
レックス仮想ソケット95の待ち行列に入れられ、仮想事
象が通知される。 ブロック323に示すサーバ側インタセプト機能の作成
は、第15図のブロック360に示されている。サーバ側イ
ンタセプト機能85の作成後、この機能は、クライアント
側インタセプト・モジュール30から送信され、ウェブ・
ブラウザ発信通信に対応するデータを、マルチプレック
ス仮想ソケット95から受け取る。この操作は第15図のブ
ロック361に示されている。クライアント側インタセプ
ト・モジュールからデータを受け取った後、サーバ側イ
ンタセプト機能85は、そのデータを、サーバ側インタセ
プト・モジュールについて前述したように処理する。こ
のサーバ側機能の実行はブロック362に示されている
（たとえば第５図および第９図を参照）。情報を処理し
た後、サーバ側インタセプト機能85は仮想作成を行うこ
とによってシンプレックス仮想ソケット75を作成する。
この操作については本明細書で第16−１図を参照しなが
ら説明する。この操作は第15図のブロック363に示され
ている。次に、サーバ側インタセプト機能85は、仮想送
信を行うことによって、ブロック364に示すようにウェ
ブ・ブラウザ発信通信をシンプレックス仮想ソケット75
に送る。仮想送信の操作については本明細書で第16−２
図を参照しながら説明する。次に、サーバ側インタセプ
ト機能85は、仮想フラッシュを行ってシンプレックス仮
想ソケット75の待ち行列に入っているデータをソケット
60cにフラッシュし、シンプレックス仮想ソケット75上
の事象を待つ。仮想フラッシュ操作については本明細書
で第17−１図を参照しながら説明する。この送信操作と
フラッシュ操作は第15図のブロック364および365に示さ
れている。待機操作は、第16−４図で説明されている仮
想選択機能を実行することによって行うことができる。
サーバ側インタセプト機能85がシンプレックス仮想ソケ
ット75を作成したとき、対応する実ソケット60cも作成
されている。サーバ側インタセプト機能85は、ウェブ・
ブラウザ発信通信をシンプレックス仮想ソケット75に送
信することによって、ウェブ・ブラウザ発信通信をウェ
ブ・サーバに転送した。 サーバ側インタセプト・モジュール40が実ソケット60
c上でウェブ・サーバからの応答を受信すると、実事象
が発生し、サーバ・ソケット・マネージャ69は第13図の
ブロック302を終了して、ブロック305に示すように実ソ
ケット60c上で発生した事象を検査する。この事例の場
合、これは既存の仮想ソケットのデータであり、第13図
のブロック320からブロック324までの経路がとられる。
実ソケット60c上で受信したデータは仮想ソケット75の
待ち行列に入れられ、仮想事象が通知される。仮想事象
が通知されると、サーバ側インタセプト機能85は第15図
のブロック366を終了し、ブロック370に示すようにその
事象を検査する。事象がソケット閉鎖である場合、エラ
ー条件が発生し、第15図のブロック375に示すように応
答としてエラー・メッセージが作成される。しかし、事
象がデータの受信の場合は、ブロック370からブロック3
71への経路をとり、サーバ側インタセプト機能85は、第
16−３図を参照しながら説明するように仮想受信を実行
して、ブロック371に示すようにシンプレックス仮想ソ
ケット75から応答を入手する。次にサーバ側インタセプ
ト機能85は、ブロック372に示し、第17−２図を参照し
ながら説明するように、シンプレックス仮想ソケット75
の仮想閉鎖を実行し、サーバ側インタセプト・モジュー
ルに関して前述し、ブロック373に示すように、その応
答を処理する（たとえば第６図および第10図を参照）。 第15図のブロック370の終了経路がブロック375へのエ
ラー経路であるかブロック371へのデータ経路であるか
を問わず、ブロック374でシンプレックス仮想ソケット7
5が削除される。次にサーバ側インタセプト機能は、ブ
ロック376に示すようにマルチプレックス仮想ソケット9
5への仮想送信操作を行ってウェブ・サーバ発信通信を
クライアント側インタセプト・モジュール30に送信す
る。サーバ側インタセプト機能85は次に、仮想フラッシ
ュ操作を行って、マルチプレックス仮想ソケット95の待
ち行列に入っているデータをフラッシュする。これらの
操作はブロック377に示されている。次にサーバ側イン
タセプト機能85は、第15図のブロック378に示すように
仮想閉鎖操作を行ってマルチプレックス仮想ソケット95
を閉じる。最後に、サーバ側インタセプト機能85は、ブ
ロック379および380に示すようにマルチプレックス仮想
ソケットを削除して終了する。 サーバ側インタセプト機能は、マルチプレックス仮想
ソケット95への仮想送信操作とフラッシュ操作を行う。
これらの操作によって、実ソケット36a上で事象がトリ
ガされ、クライアント・ソケット・マネージャ68はブロ
ック302を終了し、ブロック305に示すように事象を検査
する。これは実ソケット36aでデータを受信し、第13図
のブロック305からブロック320までの経路がとられ、デ
ータがマルチプレックス仮想ソケット90の待ち行列に入
れられるためである。したがって、実ソケット36aが外
部通信リンク35を介して実ソケット36bからウェブ・サ
ーバ応答を受け取ると、その情報が多重化解除され、マ
ルチプレックス仮想ソケットに供給される。データの受
信によって、第13図のブロック324に示すように仮想事
象が発生し、第14図のブロック336が終了してクライア
ント側インタセプト機能80は第14図のブロック340に示
すようにその事象を検査することになる。 事象がソケット閉鎖応答である場合、第14図のブロッ
ク340からブロック345への経路をとり、クライアント側
インタセプト機能80はエラー・メッセージ応答を作成し
て第14図のブロック344に進む。この例の場合のように
事象がデータ受信の場合、第14図のブロック340からブ
ロック341の経路をとり、クライアント側インタセプト
機能80は仮想受信操作を行ってマルチプレックス仮想ソ
ケット90から応答を受信する。この受信操作は第14図の
ブロック341に示されている。マルチプレックス仮想ソ
ケット90からデータを受信した後、クライアント側イン
タセプト機能80はブロック342に示すように仮想閉鎖操
作を行ってマルチプレックス仮想ソケット90を閉じる。
次にクライアント側インタセプト機能80は、ブロック34
3に示すように、クライアント側インタセプト・モジュ
ールに関して前述したように応答を処理する（たとえば
第４図および第８図を参照）。 ブロック340を終了してどちらの経路をとる場合も、
ブロック344の操作が行われる。クライアント側インタ
セプト機能80は、ブロック344に示すようにマルチプレ
ックス仮想ソケットを削除し、次にブロック346に示す
ように仮想送信操作を行ってシンプレックス仮想ソケッ
ト70を介してブラウザに応答を送信する。この仮想送信
操作が完了すると、クライアント側インタセプト機能80
はブロック347に示すように仮想フラッシュ操作を行っ
てシンプレックス仮想ソケットの待ち行列に入っている
データを実ソケット60bにフラッシュし、次にブロック3
48に示すように仮想閉鎖操作を行ってシンプレックス仮
想ソケットを閉じる。クライアント側インタセプト機能
のシンプレックス仮想ソケットを閉じた後、第14図のブ
ロック349および350に示すようにシンプレックス仮想ソ
ケットが削除され、クライアント側インタセプト機能は
終了する。 当業者ならわかるように、本発明についてシンプレッ
クス仮想ソケットおよびマルチプレックス仮想ソケット
とクライアント側インタセプト機能およびサーバ側イン
タセプト機能の１つの特定のインスタンスに関して説明
したが、単一のクライアント側インタセプト・モジュー
ルまたはサーバ側インタセプト・モジュール内でこれら
の機能を複数作成することができる。したがって、本発
明によるクライアント側インタセプト・モジュールとサ
ーバ側インタセプト・モジュールは、クライアント側イ
ンタセプト・モジュール30とサーバ側インタセプト・モ
ジュール40との間にTCP/IP接続を作成し、次に、そのTC
P/IP接続を維持しながらそのTCP/IP接続上で複数のウェ
ブ・ブラウザ発信通信またはウェブ・サーバ発信通信を
多重化することができる。 クライアント・ソケット・マネージャとサーバ・ソケ
ット・マネージャの残りの機能は、第16−１図ないし第
16−４図と第17−１図および第17−２図を参照すれば最
もよく理解できよう。これらの図では、第14図および第
15図のフローチャートに示されているように仮想作成、
仮想送信、仮想受信、仮想選択、仮想フラッシュ、また
は仮想閉鎖操作を実行するときに、クライアント側イン
タセプト・モジュールおよびサーバ側インタセプト・モ
ジュールによって行われる操作が説明されている。第14
図のブロック333および第15図のブロック363に示すよう
な仮想作成操作を行う場合、第16−１図のブロック400
から始まる操作を行う。ブロック405に示すように、ソ
ケット・マネージャは、実ソケットが必要かどうかを判
断する。作成操作によって既存の実ソケットに接続する
マルチプレックス仮想ソケットを作成する場合などのよ
うに、実ソケットがすでに存在する場合は、ブロック40
5から「No」経路をとり、ブロック409に示すようにその
仮想ソケットが実ソケットに接続される。しかし、実ソ
ケットが必要な場合は、ブロック405から「Yes」経路を
とる。ブロック406に示すように実ソケットを作成す
る。次に、第13図のブロック302に示す監視のために、
ブロック408に示すようにその実ソケットを事象リスト
に追加する。実ソケットを作成し、接続を確立した後、
ブロック409に示すように仮想ソケットを実ソケットに
接続し、ブロック410に示すように作成操作が完了す
る。 第14図のブロック334および346または第15図のブロッ
ク364および376に示す仮想送信操作を行う場合、第16−
２図のブロック420から始まる操作が行われる。ブロッ
ク427に示すようにデータが仮想ソケット待ち行列に加
えられ、完了すると、送信操作はブロック428に示すよ
うに終了する。 第14図のブロック331および341と第15図のブロック36
1および371に示す仮想受信操作は、第16−３図のブロッ
ク430から始まる操作を行うことによって行われる。ブ
ロック435に示すように、仮想ソケット待ち行列を調べ
て仮想ソケット待ち行列に何かデータが入っているか判
断する。仮想ソケット待ち行列にデータがある場合、ブ
ロック435の「Yes」経路をとり、ブロック436に示すよ
うに受信操作を呼び出した機能にそのデータが返され
る。仮想ソケット待ち行列にデータがなく、ソケットに
閉鎖のマークが付けられていない場合、決定ブロック44
0の「No」経路をとり、ブロック441に示すように何も返
されない。しかし、待ち行列にデータがなく、ソケット
に閉鎖のマークが付けられている場合、ブロック440の
「Yes」経路をとり、ブロック442に示すようにソケット
に閉鎖のマークが付けられて、ブロック443に示すよう
に、受信を要求する操作にソケット閉鎖応答が返され
る。 第14図のブロック326および336と第15図のブロック36
6で行われている仮想選択操作は、第16−４図のブロッ
ク445から始まる操作を実行することによって行われ
る。ブロック446に示すように、まず、選択された仮想
ソケットについてデータまたは仮想閉鎖操作が保留状態
になっていないかどうかを判断する。保留状態のデータ
または仮想閉鎖がない場合、ブロック446の「No」経路
をとり、プロセスはブロック447に示すように選択され
た仮想ソケット上の仮想ソケットを待ち、そのような事
象を受け取った後でブロック448に示すように終了す
る。選択された仮想ソケットについてデータまたは仮想
閉鎖が保留状態になっている場合、仮想事象がすでに発
生しており、ブロック446の「Yes」経路をとって、ブロ
ック448に示すようにプロセスが終了する。 第14図のブロック335および347と第15図のブロック36
5および377で言及した仮想フラッシュ操作は、第17−１
図のブロック450から始まる操作を実行することによっ
て行われる。仮想フラッシュ操作が呼び出されると、決
定ブロック455に示すように、フラッシュする仮想ソケ
ット待ち行列にデータが入っているかどうかを調べる。
仮想ソケット待ち行列にデータが入っていない場合、ブ
ロック455の「No」経路が示すようにフラッシュ操作は
単に終了して呼出し側機能に戻る。しかし、待ち行列に
データが入っている場合、ブロック455の「Yes」経路を
とり、ブロック460に示すようにその仮想ソケット待ち
行列がマルチプレックスソケットのものであるかどうか
を判断する。マルチプレックスソケットである場合は、
ブロック461に示すようにソケットの固有識別子と転送
中のデータ量を示す３バイトから成るソケット・ヘッダ
が実ソケット・バッファに加えられる。マルチプレック
スソケットであるかシンプレックス・ソケットであるか
を問わず、いずれの場合もブロック462に示すように実
ソケットのためのデータが実ソケット・バッファに移さ
れる。実ソケット・バッファがいっぱいの場合、ブロッ
ク465の「Yes」経路をとり、ブロック466に示すように
実ソケット・バッファからデータが実ソケットに送られ
る。実バッファがいっぱいになっていない場合は、ブロ
ック465の「No」経路をとる。次に、仮想フラッシュ機
能は、他のいずれかのマルチプレックス仮想ソケット待
ち行列に実ソケットに送るべき他のデータがあるかどう
かを判断する。答えが肯定の場合、ブロック470の「Ye
s」経路をとり、実ソケット・バッファ内のデータは、
他の仮想ソケット待ち行列の１つをフラッシュするため
に仮想フラッシュ操作が再び呼び出されるまで送られな
い。他のデータがない場合、または他のマルチプレック
ス仮想ソケットからデータを付加した後は、ブロック46
6の操作を行い、実ソケットバッファ内のデータを実ソ
ケットに送る。仮想フラッシュ操作を呼び出した機能に
対応する仮想ソケット待ち行列内のすべてのデータが実
ソケットに送られた後、ブロック467に示すように仮想
フラッシュ操作は終了する。 第14図のブロック342および348と第15図のブロック37
2および378に示す仮想閉鎖操作は、第17−２図のブロッ
ク480から始まる操作を実行することによって行われ
る。仮想閉鎖操作が呼び出されると、まずブロック485
に示すようにその仮想閉鎖がマルチプレックス仮想ソケ
ットの閉鎖であるかどうかを判断する。マルチプレック
ス仮想ソケットである場合、ブロック485の「Yes」経路
をとり、仮想ソケット待ち行列に「閉鎖」操作標識が付
加される。仮想閉鎖がマルチプレックス仮想ソケットの
閉鎖であるか否かを問わず、ブロック487に示すように
仮想閉鎖操作によって仮想フラッシュ操作が呼び出さ
れ、ブロック488に示すように実ソケットとの接続を断
つ。次に、ブロック490に示すように仮想閉鎖がシンプ
レックス仮想ソケットの閉鎖であるかどうかを調べ、そ
うでない場合は「No」経路をとってブロック495に進
む。閉鎖はマルチプレックス仮想ソケットの閉鎖である
ため、ブロック495でそれが最後のマルチプレックス仮
想ソケットであるかどうかを判断し、最後のマルチプレ
ックス仮想ソケットである場合は、ブロック496に示す
ようにマルチプレックス活動タイマをセットする。最後
のマルチプレックス仮想ソケットでない場合は、ブロッ
ク496をスキップする。 ブロック490に戻って、仮想閉鎖がシンプレックス仮
想ソケットの閉鎖である場合、ブロック491に示すよう
にそれに対応する実ソケットを事象リストから除去し、
ブロック492に示すように実ソケットを閉鎖し、削除す
る。ソケットがシンプレックスとマルチプレックスのど
ちらの仮想ソケットであるかを問わず、ブロック497に
示すようにその仮想ソケットに閉鎖のマークを付け、ブ
ロック498で閉鎖操作は終了する。 次に、第16−１図ないし第16−４図および第17−１図
ないし第17−２図に関連する第13図について説明する。
実事象が発生すると、第13図のブロック302を終了し、
ソケット・マネージャは事象がどのように生成されたか
に基づいてその事象を調べる。事象が第17−２図のブロ
ック496で設定されたマルチプレックスソケット活動タ
イマのタイム・アウトである場合、第13図のブロック30
5からブロック312までの経路がとられる。第13図に示す
ように、次にソケット・マネージャによってブロック31
2および313の操作が行われ、マルチプレックス実ソケッ
トが閉じられ、クライアント側インタセプト・モジュー
ルをサーバ側インタセプト・モジュールに接続するソケ
ットに対応するマルチプレックス実ソケットが削除され
る。その後、ソケット・マネージャは次の実事象を待
つ。ブロック322に示すように、このマルチプレックス
事象タイマはマルチプレックス仮想ソケットの作成によ
ってリセットされる。 実ソケット上で発生した事象が、ウェブ・サーバがウ
ェブ・サーバとサーバ側インタセプト・モジュールとの
間のソケット接続に対する閉鎖操作を行う場合などの実
ソケット閉鎖である場合、第13図のブロック305からブ
ロック309への経路がとられる。ソケット・マネージャ
はブロック309に示すように実事象リストからその実ソ
ケットを除去し、ブロック310に示すように１つの仮想
ソケット（または複数のマルチプレックスソケットの場
合は複数の仮想ソケット）をその１つの実ソケットまた
は複数の実ソケットから切断する。次に、ソケット・マ
ネージャはその仮想ソケットに閉鎖のマークを付け、仮
想事象を通知する。この操作はブロック311に示されて
おり、仮想ソケット待ち行列からすべてのデータが空に
されると、仮想ソケットは閉じる。仮想ソケットに閉鎖
のマークを付けた後、決定ブロック315に示すようにソ
ケット・マネージャは閉じる実ソケットがシンプレック
ス・ソケットであるかどうかを判断する。閉じる実ソケ
ットがシンプレックス・ソケットである場合、ブロック
316に示すようにその実ソケットを閉じ、削除する。次
にソケット・マネージャはブロック302に示すように次
の実事象を待つ。 閉じるソケットがシンプレックス実ソケットではない
場合、ブロック315の「No」経路をとり、ソケット・マ
ネージャは次の実事象を待つ。したがって、マルチプレ
ックス実ソケット、すなわちクライアント側インタセプ
ト・モジュールとサーバ側インタセプト・モジュールと
を接続するソケットを、マルチプレックスソケット活動
タイマのタイムアウトのみによって閉じることができ
る。これによって、ユーザ指定の所定時間の間、クライ
アント側インタセプト・モジュールとサーバ側インタセ
プト・モジュールとの間の接続を、モジュール間の最後
の通信が行われた後でも維持することができる。マルチ
プレックスソケット活動タイマのタイムアウトの前にブ
ラウザからその後の接続要求があった場合、クライアン
ト側インタセプト・モジュールとサーバ側インタセプト
・モジュールとの間に接続を再確立せずに通信を行うこ
とができ、それによってそのような接続を再確立するオ
ーバーヘッドが不要になる。 第13図で説明する最後の経路は、実事象が発生し、そ
の事象が第12図の１つまたは複数のマルチプレックス実
ソケット36aまたは36b上でのデータの受信である場合で
ある。マルチプレックス実ソケット上でデータを受信す
ると、そのデータは検査され、第17−２図のブロック48
6で仮想待ち行列に付加されるもののようにデータに閉
鎖操作標識が含まれている場合は、仮想閉鎖操作が行わ
れ、ブロック320からブロック310への経路がとられる。
ソケット・マネージャは、ブロック310に示すように実
ソケット上で受信したデータで識別されたマルチプレッ
クス仮想ソケットを実ソケットから切断し、次にブロッ
ク311に示すように仮想ソケットに「閉鎖」のマークを
付け、仮想事象を通知する。この閉鎖はマルチプレック
ス仮想ソケットの閉鎖であるため、ブロック315から「N
o」経路がとられ、ブロック302に示すようにソケット・
マネージャは別の実事象を待つ。 第13図ないし第17図で説明されている操作を行うこと
によって、本発明の特定の態様は外部通信リンクを介し
て第１のコンピュータと第２のコンピュータとの間に持
続的接続を確立する。この持続的接続は、すべてのウェ
ブ・ブラウザ発信通信が完了するまで維持され、持続的
接続が維持されている間に複数のウェブ・ブラウザ発信
通信がインタセプトされ、外部通信リンクに多重化され
て送られる。次にクライアント／サーバ固有データ・ス
トリームを多重化解除して複数のHTTPデータ・ストリー
ムを作成し、その複数のHTTPデータ・ストリームをウェ
ブ・サーバに供給することができる。また、持続的接続
は、すべてのウェブ・サーバ発信通信がインタセプト完
了するまで維持される。持続的接続が維持されている間
に、複数のウェブ・サーバ発信通信がインタセプトさ
れ、外部通信リンクに多重化されて送られる。さらに、
クライアント／サーバ固有データ・ストリームを多重化
解除して複数のHTTPデータ・ストリーを作成し、その複
数のHTTPデータ・ストリームをウェブ・サーバに供給す
ることができる。 図面および本明細書では、本発明の典型的な好ましい
実施例を開示し、特定の用語を使用したが、これらの用
語は総称および説明のためものに過ぎず、請求の範囲に
記載されている本発明の範囲を限定するためのものでは
ない。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ Ｇ０６Ｆ 17/30 １１０ Ｇ０６Ｆ 17/30 １１０Ｆ ４１９ ４１９Ｂ (72)発明者 オーセル、バロン、コーネリュース アメリカ合衆国 ノースカロライナ州 チャペル・ヒル、ケンシングトン・ドラ イブ 702 (72)発明者 リンドクイスト、デヴィッド、ブルース アメリカ合衆国 ノースカロライナ州 ラレー、レイク・スプリングス・コート (56)参考文献 小口 正人 外１名，広域ネットワー ク環境における情報分散メカニズムの一 検討，情報処理学会研究報告，日本，社 団法人情報処理学会，1996年 １月26 日，第96巻，第12号（96−ＤＰＳ− 74），ｐ．161−−166 川又 行雄，Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂサーバ構築技法，インターフェー ス，日本，ＣＱ出版社，1995年 ９月 １日，第21巻，第９号（通巻220号）, ｐ．151−−167 中村 眞，Ａｎ Ｉｎｔｒｏｄｕｃｔ ｉｏｎ ｔｏ Ｘ Ｗｉｎｄｏｗ Ｓｙ ｓｔｅｍ 55 ＬＢＸ，ＵＮＩＸ ＭＡ ＧＡＺＩＮＥ，日本，株式会社アスキ ー，1995年 ９月 １日，ＶＯｌ．10, Ｎｏ．９，ｐ．155−−158 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 G06F 13/00 G06F 17/30

Claims (1)

1. (57)【特許請求の範囲】 【請求項１】第１のアプリケーションから受信し、第２
   のアプリケーションからの要求に応答して第２のアプリ
   ケーションに送るべきデータをキャッシュする装置であ
   って、第１のアプリケーションが第１のコンピュータ内
   に常駐し、かつ第２のアプリケーションが第２のコンピ
   ュータ内に常駐し、かつ第１のアプリケーションと第２
   のアプリケーションがさらに外部通信リンクを介して互
   いに通信し、 第１のアプリケーションから受信し第２のアプリケーシ
   ョンに送るべきデータ・ストリームを第２のコンピュー
   タ内に常駐するキャッシュ内に格納して、第２のアプリ
   ケーションからの要求に対応するクライアント・キャッ
   シュ項目を生成する手段と、 クライアント・キャッシュ項目の生成時間を格納して、
   クライアント・キャッシュ項目時間記録を生成する手段
   と、 要求に対応するクライアント・キャッシュ項目が存在す
   るかどうかを判定するために、第２のアプリケーション
   からの要求を検査する手段と、 第２のアプリケーションがその情報を要求する前に第２
   のアプリケーションからの要求に対応するクライアント
   ・キャッシュ項目が前記第２のアプリケーションから供
   給されたクライアント・コヒーレンシ時間間隔内に生成
   されたかどうかを判定するために、第２のアプリケーシ
   ョンからの要求に対応するクライアント・キャッシュ項
   目のクライアント・キャッシュ項目時間記録を評価する
   手段と、 第２のアプリケーションがその情報を要求する前に第２
   のアプリケーションからの要求のクライアント・キャッ
   シュ項目が所定のクライアント・コヒーレンシ時間間隔
   内に生成されたと前記評価手段で判定した場合、要求に
   応答してクライアント・キャッシュ項目を外部通信リン
   クを介して第２のアプリケーションに供給する手段と、 第２のアプリケーションからの要求に応答して、第１の
   アプリケーションからのデータ・ストリームを第１のコ
   ンピュータ内に常駐するキャッシュ内に格納して、サー
   バ要求キャッシュ項目を生成する手段と、 要求に対応するサーバ要求キャッシュ項目が前に第２の
   コンピュータ内に常駐するキャッシュ内に格納されてい
   たかどうかを判定するために、第２のアプリケーション
   が発生した要求を検査する手段と、 第２のアプリケーションからの要求に対応するサーバ要
   求キャッシュ項目を外部通信リンクを介して第２のコン
   ピュータ内に常駐する第２のアプリケーションに送信す
   る手段とを含む装置。