JP2003534721A - インターネット通信を監視する方法 - Google Patents

Abstract

(57)【要約】 ネットワーク通信ラインを追跡し或る与えられた端末のブラウザの活動状況のシミュレーションを行うためのネットワーク・プローブ端末。このプローブ端末は関連するリクエストを選別し或る与えられたＩＰアドレスに関して応答するために通信ラインを通して送られるＴＣＰ／ＩＰデータを監視する。これらのリクエストおよび応答を解析しそのタイプおよび内容に従って分類し、この解析に基づいてプローブ端末は与えられた端末のナビゲーション過程に関するすべての関連するデータ・トランザクションを識別する。プローブ端末は、与えられた端末のユーザーが見る実在のナビゲーションと同様なナビゲーションを提示するために、識別されたデータ・トランザクションの過程のシミュレーションを行う仮想的なブラウザを作動させる。

Description

【発明の詳細な説明】

【０００１】 （本発明の背景） 本発明は通過するデータを解析することによりネットワーク上の通信を監視お
よび傍受する方法およびシステムに関する。

【０００２】 現在のコンピュータ・ネットワークを通って膨大な量の通信が流れているが、
その全部が良質なものではない。従って大部分の場合或るネットワークの所有者
または管理者は、ネットワークを効果的に監視し安全を確保するために、リアル
タイムで追跡し「傍受」できることを考えている。このような傍受または監視は
、ネットワークにプローブを接続し、ネットワーク上の二つまたはそれ以上のノ
ード（例えばユーザーのワークステーション）の間を移動するデータを監視する
ことによって達成することができる。

【０００３】 二つのノードの間の通信が離散したパケットの形であるシステムにおいては、
ネットワークのプローブはデータのパケットを「読んで」パケットの発信元およ
び行先のアドレス、或いは該パケットのプロトコルに関するような情報を集める
ことができる。また、或る与えられた時間の間における或る型のプロトコルによ
る通信量の平均値または全体の量、或いは或るノードへまたは或るノードから送
られたパケットの総数のような統計的情報または関連情報を計算することができ
る。このような情報はリアルタイムでシステムの管理者へ報告されるか、または
後で解析を行うために保存することができる。

【０００４】 この方面においてこれまで種々の試みが既に行われてきた。例えば、米国イリ
ノイ州Ｌｉｎｃｏｌｎｓｈｉｒｅ ＩＩＩ．のＣｌｅａｒ Ｃｏｍｍｕｎｉｃａ
ｔｉｏｎ Ｃｏｒｐｏｒａｔｉｏｎから入手できるソフトウエア・プログラムの
Ｃｌｅａｒ Ｖｉｅｗ Ｎｅｔｗｏｒｋ Ｗｉｎｄｏｗは、同社によれば予測／
先見的な保守、情報処理機能をもつ根源原因解析（ｒｏｏｔ−ｃａｕｓｅ ａｎ
ａｌｙｓｉｓ）、品質保証付のレポートを提供する。しかしその出力はネットワ
ークの障害管理のために設計されており、これはネットワークのノードの間の通
信の中へ入り込んで行われる「傍受（ｔａｐｐｉｎｇ）」とは同じではない。即
ちＣｌｅａｒｖｉｅｗシステムは内容または特性に関しネットワーク中の二つの
ノードの間で送られるデータを監視することはできない。

【０００５】 米国カリフォルニア州、ＬｉｖｅｒｍｏｒｅのＬｉｖｅｒｍｏｒｅ Ｎａｔｉ
ｏｎａｌ Ｌａｂｏｒａｔｏｒｙは、ローカル・エリア・ネットワークを横切っ
て伝送されるデータ・パケットを「嗅ぎまわる」ことによって米国エネルギー省
のコンピュータを保護する一群のコンピュータ・プログラムを開発した。米国海
軍はこれらの一つの「ｉＷａｔｃｈ」というプログラムを使用し、米国国防総省
およびＮＡＳＡのコンピュータ・システムに侵入したと疑われているコンピュー
タ・ハッカーの通信を盗聴した。ｉＷａｔｃｈプログラムはネットワーク・プロ
ーブを使用してネットワーク上を流れるすべてのパケットを読み、次いでこの情
報を共通のデータベースに「保存」する。次に簡単なコンピュータ・プログラム
をつくって保存されたデータを読み取り、情報の予め定められた「関心がもたれ
る」部分だけを表示することができる。

【０００６】 関心がもたれる情報の部分が見出だされると、保存されたデータを再走査し、
「関心がもたれる」部分の両側にある文字の特定な数を報告する。次にこれらの
関心がもたれる文字を検討し、メッセージの内容を決定し、以後の監視活動の指
針として使用する。

【０００７】 このシステムはユーザーの活動状況の履歴分析に限られ、すべてのユーザー活
動について完全な傍受はできず、またユーザーがコンピュータ間を渉って移動す
る活動の完全なシミュレーションを行うこともできない。

【０００８】 連続的な信頼性のある追跡を行う際には次のような三つの主要な問題に遭遇す
る。

【０００９】 （ａ）個別的なブラウザではウエッブ・サーバに対して行われる活動がすべて
報告されるものではない。例えばブラウザがそのブラウザのキャッシュ・メモリ
ー空間或いはプロキシ・サーバからウエッブ・ページをロード（転送）した場合
、ブラウザは「遠くの」ウエッブ・サーバにはサイバースペースのオートストレ
ード（ａｕｔｏｓｔｒａｄｅ）を通してリクエスト信号を送らない。

【００１０】 （ｂ）一つの製造業者のウエッブ・ブラウザによって或る特性を実行するよう
に設計されたアプリケーション・プログラムは通常他の業者によってつくられた
ものと相容性をもっていない。何故ならブラウザのインターフェースの機構はそ
れぞれ異なっており特有であるからである。

【００１１】 （ｃ）個々のブラウザはウエッブ・サーバに対し非体系的な順序でリクエスト
を送り出す。換言すれば与えられたウエッブ・サーバに関し前のリクエストは次
のリクエストに関して何の関係ももっていない。リクエストを処理する際ウエッ
ブ・サイトはこれら一連のリクエストに対して何の制御も行わない。

【００１２】 これらの問題を克服する試みにおいて、米国特許５，９５１，６４３号にはウ
エッブの同期化に対する情報を信頼性をもって組織化して管理し、また多くの消
費者のブラウザを追跡する機構が記載されている。

【００１３】 しかしその解決法は、「傍受」され、好意的に協調し、明示された用途をもっ
てホストに接続することに同意した、確認されたユーザーの活動状況の追跡に限
られている。

【００１４】 本発明の主な目的は、ネットワーク通信供給業者がそのネットワークに接続し
たどのユーザーに対しても傍受できる監視および管理方法およびそのシステムを
提供することである。

【００１５】 本発明の他の目的は、ネットワーク通信供給業者がリアルタイムでネットワー
クで通信中のすべてのユーザーの活動状況を監視できる傍受の方法を提供するこ
とである。

【００１６】 本発明のさらに他の目的はウエッブ・サイトの所有者がそのウエッブ・サイト
に接続しているユーザーを監視し傍受できるようにすることである。

【００１７】 （本発明の概要） 従って本発明によれば、或る与えられた端末のブラウザ（「本来のブラウザ」
）の活動状況のシミュレーションを行うネットワーク・プローブ端末（「端末エ
ージェント」）によってネットワークの通信ラインを追跡する方法において、該
方法は通信ラインを通って送られるＴＣＰ／ＩＰデータ・パケットを追跡し、与
えられたＩＰアドレスに関連したＴＣＰ／ＩＰデータ・パケット（「識別された
データ・パケット」）を選択し、識別されたデータ・パケットから新しい接続に
対する現在のリクエスト（「本来のリクエスト」）を選択し、識別されたデータ
・パケットから新しいアドレスを示す現在のウエッブ・ページの構成要素（「新
しいナビゲーション要素」）を選択し、この新しいナビゲーション要素を二つの
範疇、即ち埋め込まれたオブジェクトまたはフレーム（「偽値をもつ新しい構成
要素」）およびハイパーリンク（「真値をもつ新しい構成要素」）に分割し、本
来のリクエストを分割して真値をもつものとして新しい構成要素に合致する本来
のリクエスト或いはどの新しい構成要素とも一致せず且つＨＴＴＰまたはＰＯＳ
Ｔタイプに属する本来のリクエストを「一番目のリクエスト」として、また偽値
をもつ構成要素に合致した本来のリクエストを「二番目のリクエスト」として分
類し、識別されたデータ・パケットから一番目のリクエストに関連したＨＴＭＬ
データ・ファイル（それぞれの一番目の応答」）を選択し、それぞれの二番目の
応答に従って「仮想的な」二番目の応答を生成し、識別されたデータ・パケット
から二番目の仮想的な応答に関連した応答（「それぞれの二番目の応答」）を選
択し、このそれぞれの二番目の応答に従って端末エージェント上でウエッブ・ペ
ージを提示するシミュレーションを行うことを特徴とする方法が提供される。

【００１８】 本発明のこれらのおよび他の特徴および利点は、添付図面を参照し単に例示の
目的で下記に行われる本発明の若干の好適具体化例の詳細な説明によって明らか
になるであろう。

【００１９】 （好適具体化例の詳細な説明） 図１を参照すれば、端末０１、０２・・・は同じ通信ラインに連結され、この
通信ラインは内部ネットワーク（「イントラネット」）または外部ネットワーク
、例えばインターネットとして使用されるものとしよう。本発明に従えば、規定
されたネットワーク・プローブ（以後端末エージェントと呼ぶ）をデータ通信ラ
インに連結するように提案される。或はまた端末０１、０２等および端末エージ
ェントはこれを異なったデータ通信ラインにに接続するか、または異なったロー
カル・ネットワークに配置することができる。

【００２０】 端末エージェントの操作の一般的な図式を図２に示す。

【００２１】 端末エージェントは通信ラインを通るすべてのデータ・フレームに解放されて
いる。データ・フレームは端末の間を伝送される情報またはインターネット・サ
ーバにのような外部の発信源への外部データの送信に関する情報を含んでいるこ
とができる。

【００２２】 さらに、このデータ通信ラインの「所有者」、例えばＩＳＰ（インターネット
・プロバイダー）または私的機関のネットワークの所有者は、或る端末がインタ
ーネット・サーフィングを行った場合、その実際の通信活動をリアルタイムで監
視することに関心をもっていると仮定しよう。

【００２３】 端末エージェントの操作はＴＣＰ／ＩＰデータ・パケットを追跡するためにデ
ータ・フレームを先ず解析することである。図３に示すように、データの解析は
異なったプロトコル階層構造（インターネット・プロトコルのＲＧＣ ０７９３
参照）に従って、即ち先ずローカル・ネットワークのプロトコルを解析し、次い
で外部データの伝送（「ゲートウエイ・レベル」）を選別し、次にインターネッ
ト・プロトコル（ＩＰ）のデータ・フレームを識別し、最後に「ホスト・レベル
」のＴＣＰ（「伝送制御プロトコル」）のデータ・パケットを検出する方法で行
う。

【００２４】 データ・パケットのＩＰ ＨＥＡＤＥＲを解析する際、リクエストを出した端
末およびメッセージの転送先のＩＰアドレスを識別する。通信ラインの所有者は
このＩＰアドレスをユーザーの端末と容易に関連付けることができる。しかる後
他のすべての関連のないデータ・パケットを選別して除去し、以後の処理は一つ
の選択された端末のデータ（以後識別されたデータ・パケットと呼ぶ）の伝送に
限定される。

【００２５】 識別されたデータ・パケットはさらにＲＦＣ ０７９仕様によって解析され、
データ通信ポートの完全な管理と制御ができるようにする。

【００２６】 通常のブラウザ、例えばインターネット・エクスプローラのようなＴＣＰデー
タ通信ポートを管理する公知の手順に従えば、ブラウザを操作する端末はすべて
のデータ伝送の本来の発信元である。例えばＹＡＨＯＯ！のホームページにリク
エストをしたとしよう。このリクエストはネットワークを通じてＹＡＨＯＯ！の
サーバへ送られる。それに応答してサーバはウエッブのｙａｈｏｏのホームペー
ジの構成要素に関するすべての情報を含むＨＴＭＬデータを送ってくる。従って
ブラウザは新しい通信の「仮想」ポートを開くことによってウエッブ・ページの
すべての構成要素を受け取るための新しいリクエストを送り、この場合各ポート
は同じウエッブ・ページの異なった構成要素を伝送するのに使用される。すべて
のデータのリクエストおよびそれぞれの応答に対して解放されている「部外者」
の端末は、最初の「一番目の」リクエスト、例えば完全なＹＡＨＯＯ！のホーム
ページに対するリクエストと、その構成要素を受け取るための「二番目の」リク
エストとを区別することはできない。「部外者」のプローブ端末によって本来の
ブラウザの活動状況のシミュレーションを行うためには、一番目のリクエストを
そのまま識別することが重要である。

【００２７】 図４は一番目のリクエストを二番目のリクエストと区別する方法を示す。一番
目のリクエストはユーザーが新しいＵＲＬを入力し、ハイパーリンクを選択する
などの種々の操作からつくられる。従って同じものを検出するためには同じＩＰ
アドレスに送られた前の情報を解析しなければならない。端末が受け取ったウエ
ッブ・ページのすべての新しい移行要素（ブラウザを新しい場所に向かわせる）
は、そのタイプに従って保存され、この際すべての埋め込まれたオブジェクト、
フレーム等は「偽」の要素としてマークが付けられ、ハイパーリンクには「真」
の要素のマークが付けられる。すべてのデータは後で使用するために入力バッフ
ァー応答データベースに保存される。

【００２８】 ＴＣＰの解析に従って新しい接続に対するリクエストが識別された場合、入力
応答バッファーの中でそれぞれのナビゲーション要素（ＲＮＣ）に従ってこのリ
クエストを調べる。ＲＮＣに「偽」のマークが付けられている場合このリクエス
トは無視される。ＲＮＣに「真」のマークが付いている場合には、このリクエス
トを一番目として分類する。そうではなくて該リクエストに関するＲＣＮが存在
しない場合には、接続のタイプを識別しなければならない。接続がＨＴＭＬタイ
プまたは「ＰＯＳＴ」タイプの場合には、これを一番目のリクエストとして分類
する。

【００２９】 端末の活動状況を調べ監視するためには、すべての「本来の」ブラウザの活動
状況を再構築しなければならない。この目的に対しては「仮想的な」ブラウザを
使うことが示唆されている。この仮想的なブラウザは、リアルタイムでウエッブ
・ページをインターネットからダウンロードする「実在の」ブラウザのすべての
能力をもっている。しかし、インターネット・サーバに対して実際のデータの交
換は全く行わず、本来の「実在の」ブラウザの活動のシミュレーションを行うだ
けであるという点においてそのインターネットとの接続は仮想的である。

【００３０】 仮想的なブラウザの第１の機能を図５に示す。このブラウザは「実在の」ブラ
ウザのすべての一番目のリクエストを受け取る。これらの一番目のリクエストお
よびそれぞれに対するインターネットからの一番目の応答を解析し、通常のブラ
ウザ操作に従って処理を行う。二番目の仮想的なリクエスト（通常のブラウザに
おいてウエッブ・ページの構成要素をダウンロードする過程を完了するのに使用
される）の結果は、通常のようにインターネットを通じて適当なサーバへ直接送
られずに、仮想的な「二番目の」リクエストのバッファー・データベースに保存
される。

【００３１】 仮想的なブラウザの接続は「実在の」接続ではないが、ポートの接続を開き制
御するすべてのＴＣＰプロトコルの管理は、あたかもその接続が「実在の」接続
であるかのように端末エージェントによって処理される。

【００３２】 仮想的なブラウザにおいてシミュレーションを行いウエッブ・ページを提供す
る最終的な過程をさらに図６に示す。通信ラインを通って入ってくるすべての本
来の二番目の応答を分析し、入力応答バッファー・データベースに保存する。仮
想的なリクエストを、到着順に入力応答バッファー・データベースに保存された
それぞれの二番目の応答と比較する。それぞれの二番目の応答が既にバッファー
の中に存在している場合、これらの応答は仮想的なブラウザに送られ、（通常の
ブラウザ操作に従って）処理され、それぞれのウエッブ・ページの構成要素の仮
想的な図を提供する。その結果端末エージェントは、本来の端末によって行われ
るように、リアルタイムでインターネットのウエッブ・ページをダウンロードす
る正確な過程のシミュレーションを行う。

【００３３】 それぞれの応答が入力応答バッファー・データベースの中に現れない場合には
、本来のローカル・キャッシュの活動状況を推論する。該仮想的なリクエストに
関し本来のローカル・キャッシュを使用しなかった場合、本来の二番目のそれぞ
れの応答が到着するまでそれをバッファー・データベースの中に保留にしておく
。そうでなくてこの応答に関し実在のローカル・キャッシュを使用した場合には
、仮想的なブラウザのローカル・キャッシュを調べ、ローカル・キャッシュの中
にそれぞれの二番目の応答が存在する場合には、それぞれの応答を仮想的なブラ
ウザに送り、上記のようにして処理する。仮想的なキャッシュの中にそれぞれの
応答が存在しない場合には、次の二つの方法がとられる。その一つ、端末エージ
ェントの「受動的な」態様に従えば、「見つからない」応答を見つけようとする
動作はなされず、ウエッブ・ページの構成要素が実在の端末に現れる代わりに端
末エージェントに「エラー」メッセージが現れる。この態様に従えば、実在の端
末でのシミュレーションは完了せず、傍受の活動は検出できない。他の「能動的
な」態様に従えば、端末エージェントはウエッブ・ページのサーバに対し、「見
つからない」という応答を出すことを要求する。この態様では端末エージェント
は実在の端末の活動のさらに正確な図を提供することができるが、傍受の活動を
検出できるもっと経験を積んだ端末のユーザーにとってそれ追跡可能である。

【００３４】 本発明を実装する他の態様に従えば、関連するウエッブ・ページ・パケットを
傍受するばかりでなく、例えばｅ−メールまたはチャットのような関連したメッ
セージ・データを傍受することが提案される。このような傍受を可能にするには
、ウエッブ・ページをリクエストする以外のネットワークを通じてメッセージを
送りまた受け取るために、要求に応じて上記と同じ方法および原理を適用する。
このようなリクエストおよびそれぞれの応答を解析する方法は効率が高い。何故
ならば定義によりこのような情報は常に新しいのでキャッシュ・メモリーの活動
状況をチェックする必要がないからである。

【００３５】 最後に、上記の具体化例はインターネットの通信環境に向けられたものである
ことを理解されたい。しかし本発明は広い態様において一般にコンピュータ化さ
れた通信網、例えば衛星ネットワーク、携帯電話ネットワーク、その他にも同様
に適用することができる。

【００３６】 上記の説明は多くの仕様を含んでいるが、これらは本発明の範囲を制限するも
のではなく、好適な具体化例の例示であると考えるべきである。当業界の専門家
は本発明の範囲内に入る他の可能な変形を考えることができるであろう。従って
本発明の範囲は例示された具体化例によってではなく、添付特許請求の範囲およ
びその正当な同等事項によって決定されなければならない。

【図面の簡単な説明】

【図１】 本発明を実装できる典型的なネットワークの形態を示す図。

【図２】 端末エージェントの操作図式。

【図３】 ＴＣＰ／ＩＰデータ・パケットを追跡し識別する過程。

【図４】 ＴＣＰ／ＩＰリクエストを分類する流れ図。

【図５】 仮想的な二番目のＴＣＰ／ＩＰリクエストを生成するシミュレーションの流れ
図。

【図６】 本物のブラウザの活動状況のシミュレーションを行う過程の流れ図。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ ，ＤＫ，ＤＭ，ＤＺ，ＥＣ，ＥＥ，ＥＳ，ＦＩ，ＧＢ， ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，Ｉ Ｎ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ， ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ， ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5K030 GA11 HA08 HB08 HC01 HC14 JA10 5K033 BA08 CC01 DA01 EA07

Claims (18)

【特許請求の範囲】
1. 【請求項１】 或る与えられた端末のブラウザ（「本来のブラウザ」）の活
   動状況のシミュレーションを行うネットワーク・プローブ端末（「端末エージェ
   ント」）によってネットワークの通信ラインの追跡を行う方法において、該方法
   は Ｉ．ネットワーク通信ラインにアクセスすること、 ＩＩ．通信ラインを通って送られるＴＣＰ／ＩＰデータ・パケットを追跡する
   こと、 ＩＩＩ．或る与えられたＩＰアドレスに関するＴＣＰ／ＩＰデータ・パケット
   （「識別されたデータ・パケット」）を選択すること、 ＩＶ．該識別されたデータ・パケットから新しい接続に対する現在のリクエス
   ト（「本来のリクエスト」）を選択すること、 Ｖ．識別されたデータ・パケットから新しいアドレスを示す現在のウエッブ・
   ページの構成要素（「新しいナビゲーション要素」）を選択すること、 ＶＩ．新しいナビゲーション要素を二つの範疇、即ち （ｆ１）埋め込まれたオブジェクトまたはフレーム（「偽値をもつ新しい構成
   要素」）および （ｆ２）ハイパーリンク（「真値をもつ新しい構成要素」）、 に分割すること、 ＶＩＩ．それぞれ下記の基準、即ち （ｇ１）新しい構成要素に対し真値をもつものとして合致する本来のリクエス
   ト、或いは新しい接続の構成要素と合致せず且つＨＴＴＰまたはＰＯＳＴタイプ
   に属する本来のリクエスト、 （ｇ２）偽値をもつ構成要素に合致する本来のリクエスト、或いは新しい接続
   の構成要素に合致せず且つＨＴＴＰまたはＰＯＳＴタイプに属さない本来のリク
   エスト、 に従って本来のリクエストを「一番目」または「二番目」のリクエストに分割す
   ること、 ＶＩＩＩ．識別されたデータ・パケットから一番目のリクエストに関するＨＴ
   ＭＬデータ・ファイル（「それぞれの一番目の応答」）を選択すること、 ＩＸ．それぞれの二番目の応答に従って「仮想的な」二番目のリクエストをつ
   くること、 Ｘ．識別されたデータ・パケットから二番目の仮想的なリクエストに関する応
   答（「それぞれの二番目の応答」）を選択すること、 ＸＩ．それぞれの二番目の応答に従い端末エージェント上でウエッブ・ページ
   を提示するシミュレーションを行うことを含むことを特徴とする方法。
2. 【請求項２】 さらに − それぞれの本来の応答に現在合致しない仮想的な二番目のリクエスト（「
   未回答の二番目のリクエスト」）を選択し、 − 本来のブラウザのローカル・キャッシュ（「本来のキャッシュ」）を未回
   答の二番目のリクエストに関して使用した場合には端末エージェントの内容の形
   のローカル・キャッシュ（仮想的なキャッシュ）を検索し、 − 仮想的なキャッシュがこのようなデータを含んでいる場合には、未回答の
   二番目のリクエストに関連するデータに従って端末エージェント上においてウエ
   ッブ・ページを提示するシミュレーションを行い、 − 仮想的なキャッシュが未回答の二番目のリクエストに関連したデータを含
   んでいない場合には、端末エージェントにおいてそれぞれの場所でエラー・メッ
   セージを表示する過程を含むことを特徴とする請求項１記載の方法。
3. 【請求項３】 さらに − 仮想的なキャッシュがデータを含んでいない場合には、未回答の二番目の
   リクエストに関するそれぞれのシミュレーションを行われた応答を受け取るため
   に通信ラインを介して適切なインターネット・サーバへ接続し、それを表示する
   過程を含むことを特徴とする請求項２記載の方法。
4. 【請求項４】 さらに − 識別されたデータ・パケットから例えばｅ−メールのようなネットワーク
   ・メッセージに関連するデータ（「メッセージ・データ」）を選択し、 − このメッセージ・データをテキスト・データ・ファイルに変換し、 − 端末エージェント上にテキスト・データ・ファイルを表示する過程を含む
   ことを特徴とする請求項１記載の方法。
5. 【請求項５】 ネットワークはローカル・エリア・ネットワーク（ＬＡＮ）
   であり、端末は延長された通信ラインに連結されていることを特徴とする請求項
   １記載の方法。
6. 【請求項６】 通信ラインは外部通信ライン、例えば電話線、ＩＺＤＮライ
   ン、光ファイバー・ラインであることを特徴とする請求項１記載の方法。
7. 【請求項７】 ネットワークはローカル・エリア・ネットワーク（ＬＡＮ）
   であり、端末エージェントは該与えられた端末とは異なった場所に置かれている
   ことを特徴とする請求項１記載の方法。
8. 【請求項８】 与えられたＩＰアドレスは通信ライン・プロバイダー（ＩＳ
   Ｐ）によって識別されることを特徴とする請求項１記載の方法。
9. 【請求項９】 与えられたＩＰアドレスは通信ラインの所有者によって識別
   されることを特徴とする請求項１記載の方法。
10. 【請求項１０】 与えられたＩＰアドレスはウエッブ・サイト・ビジターの
    アドレスであり、ウエッブ・サイトの所有者によって識別されることを特徴とす
    る請求項１記載の方法。
11. 【請求項１１】 ネットワーク通信ラインを追跡し或る与えられた端末のブ
    ラウザ（「本来のブラウザ」）の活動状況のシミュレーションを行うネットワー
    ク・プローブ端末において、該端末は Ｉ．ネットワークの通信ラインにアクセスするための連結装置、 ＩＩ．該通信ラインを通じて送られるＴＣＰ／ＩＰデータ・パケットを追跡す
    るための監視装置、 ＩＩＩ．或る与えられたＩＰアドレスに関連するＴＣＰ／ＩＰデータ・パケッ
    ト（「識別されたデータ・パケット」）から新しい接続リクエスト（「本来のリ
    クエスト」）および新しいアドレス（「新しいナビゲーション要素」）を示すウ
    エッブ・ページを選択する第１の選別モジュール、 ＩＶ．新しいナビゲーション要素を次の二つの範疇、即ち （ｆ１）埋め込まれたオブジェクトまたはフレーム（「偽値をもつ新しい構成
    要素」） （ｆ２）ハイパーリンク（「真値をもつ新しい構成要素」） に分割するための第１分類装置、 Ｖ．本来のリクエストを下記の基準、即ち、それぞれ、 （ｇ１）真値をもつ新しい構成要素と合致する本来のリクエスト、或いはどの
    新しい接続の構成要素にも合致せずＨＴＴＰまたはＰＯＳＴタイプに属する本来
    のリクエスト、 （ｇ２）偽値の構成要素と合致する本来のリクエスト、或いはどの新しい連結
    要素にも合致せずＨＴＴＰまたはＰＯＳＴタイプに属さない本来のリクエスト、
    に従って「一番目」または「二番目」のリクエストに分割する第２の分類装置、 ＶＩ．識別されたデータ・パケットから一番目のリクエストに関連したＨＴＭ
    Ｌデータ・ファイル（「一番目」の応答」）を選択する分類モジュール、 ＶＩＩ．それぞれの二番目の応答に従って「仮想的な」二番目のリクエストを
    つくるためのリクエスト生成モジュール、 ＶＩＩＩ．識別されたデータ・パケットから二番目の仮想的なリクエストに関
    連した応答（「二番目」の応答」）を選択する第２の選別モジュール、 ＩＸ．二番目の応答に従って端末エージェント上でウエッブ・ページの提示の
    シミュレーションを行うための表示装置から成ることを特徴とするネットワーク
    ・プローブ端末。
12. 【請求項１２】 該選別モジュールは現在どの各々の本来の応答にも合致し
    ない仮想的な二番目のリクエスト（「未回答の二番目のリクエスト」）を選択す
    る装置を含んでいることを特徴とする請求項１１記載のネットワーク・プローブ
    端末。
13. 【請求項１３】 さらに、本来のブラウザのローカル・キャッシュ（「本来
    のキャッシュ」）が未回答の二番目のリクエストに対する応答に使用された場合
    、端末エージェントのローカル・キャッシュを作動させるためのキャッシュ・モ
    ジュールを含んでいることを特徴とする請求項１１記載のネットワーク・プロー
    ブ端末。
14. 【請求項１４】 さらに、仮想的なローカル・キャッシュがデータを含んで
    いない場合、通信ラインを介して適当なインターネット・サーバに接続し、未回
    答の二番目のリクエストに関するそれぞれのシミュレーションされた応答を受け
    取るための検索モジュールを含んでいることを特徴とする請求項１３記載のネッ
    トワーク・プローブ端末。
15. 【請求項１５】 さらに、例えばｅ−メールのようなネットワークのメッセ
    ージに関連する識別されたデータ・パケットのデータ（「メッセージ・データ」
    ）を選択し、このメッセージ・データをテキスト・データ・ファイルに変換し、
    このテキスト・データ・ファイルを端末に表示する電子メッセージ・モジュール
    を含んでいることを特徴とする請求項１１記載のネットワーク・プローブ端末。
16. 【請求項１６】 与えられたＩＰアドレスは通信ライン・プロバイダー（Ｉ
    ＳＰ）によって識別されることを特徴とする請求項１１記載のネットワーク・プ
    ローブ端末。
17. 【請求項１７】 与えられたＩＰアドレスは通信ラインの所有者によって識
    別されることを特徴とする請求項１１記載のネットワーク・プローブ端末。
18. 【請求項１８】 与えられたＩＰアドレスはウエッブ・サイト・ビジターの
    アドレスであり、ウエッブ・サイトの所有者によって識別されることを特徴とす
    る請求項１１記載のネットワーク・プローブ端末。