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

Description

【０００１】
（本発明の背景）
本発明は通過するデータを解析することによりネットワーク上の通信を監視および傍受する方法およびシステムに関する。
【０００２】
現在のコンピュータ・ネットワークを通って膨大な量の通信が流れているが、その全部が良質なものではない。従って大部分の場合或るネットワークの所有者または管理者は、ネットワークを効果的に監視し安全を確保するために、リアルタイムで追跡し「傍受」できることを考えている。このような傍受または監視は、ネットワークにプローブを接続し、ネットワーク上の二つまたはそれ以上のノード（例えばユーザーのワークステーション）の間を移動するデータを監視することによって達成することができる。
【０００３】
二つのノードの間の通信が離散したパケットの形であるシステムにおいては、ネットワークのプローブはデータのパケットを「読んで」パケットの発信元および行先のアドレス、或いは該パケットのプロトコルに関するような情報を集めることができる。また、或る与えられた時間の間における或る型のプロトコルによる通信量の平均値または全体の量、或いは或るノードへまたは或るノードから送られたパケットの総数のような統計的情報または関連情報を計算することができる。このような情報はリアルタイムでシステムの管理者へ報告されるか、または後で解析を行うために保存することができる。
【０００４】
この方面においてこれまで種々の試みが既に行われてきた。例えば、米国イリノイ州Ｌｉｎｃｏｌｎｓｈｉｒｅ ＩＩＩ．のＣｌｅａｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｒｐｏｒａｔｉｏｎから入手できるソフトウエア・プログラムのＣｌｅａｒ Ｖｉｅｗ Ｎｅｔｗｏｒｋ Ｗｉｎｄｏｗは、同社によれば予測／先見的な保守、情報処理機能をもつ根源原因解析（ｒｏｏｔ−ｃａｕｓｅ ａｎａｌｙｓｉｓ）、品質保証付のレポートを提供する。しかしその出力はネットワークの障害管理のために設計されており、これはネットワークのノードの間の通信の中へ入り込んで行われる「傍受（ｔａｐｐｉｎｇ）」とは同じではない。即ちＣｌｅａｒｖｉｅｗシステムは内容または特性に関しネットワーク中の二つのノードの間で送られるデータを監視することはできない。
【０００５】
米国カリフォルニア州、ＬｉｖｅｒｍｏｒｅのＬｉｖｅｒｍｏｒｅ Ｎａｔｉｏｎａｌ Ｌａｂｏｒａｔｏｒｙは、ローカル・エリア・ネットワークを横切って伝送されるデータ・パケットを「嗅ぎまわる」ことによって米国エネルギー省のコンピュータを保護する一群のコンピュータ・プログラムを開発した。米国海軍はこれらの一つの「ｉＷａｔｃｈ」というプログラムを使用し、米国国防総省およびＮＡＳＡのコンピュータ・システムに侵入したと疑われているコンピュータ・ハッカーの通信を盗聴した。ｉＷａｔｃｈプログラムはネットワーク・プローブを使用してネットワーク上を流れるすべてのパケットを読み、次いでこの情報を共通のデータベースに「保存」する。次に簡単なコンピュータ・プログラムをつくって保存されたデータを読み取り、情報の予め定められた「関心がもたれる」部分だけを表示することができる。
【０００６】
関心がもたれる情報の部分が見出だされると、保存されたデータを再走査し、「関心がもたれる」部分の両側にある文字の特定な数を報告する。次にこれらの関心がもたれる文字を検討し、メッセージの内容を決定し、以後の監視活動の指針として使用する。
【０００７】
このシステムはユーザーの活動状況の履歴分析に限られ、すべてのユーザー活動について完全な傍受はできず、またユーザーがコンピュータ間を渉って移動する活動の完全なシミュレーションを行うこともできない。
【０００８】
連続的な信頼性のある追跡を行う際には次のような三つの主要な問題に遭遇する。
【０００９】
（ａ）個別的なブラウザではウエッブ・サーバに対して行われる活動がすべて報告されるものではない。例えばブラウザがそのブラウザのキャッシュ・メモリー空間或いはプロキシ・サーバからウエッブ・ページをロード（転送）した場合、ブラウザは「遠くの」ウエッブ・サーバにはサイバースペースのオートストレード（ａｕｔｏｓｔｒａｄｅ）を通してリクエスト信号を送らない。
【００１０】
（ｂ）一つの製造業者のウエッブ・ブラウザによって或る特性を実行するように設計されたアプリケーション・プログラムは通常他の業者によってつくられたものと相容性をもっていない。何故ならブラウザのインターフェースの機構はそれぞれ異なっており特有であるからである。
【００１１】
（ｃ）個々のブラウザはウエッブ・サーバに対し非体系的な順序でリクエストを送り出す。換言すれば与えられたウエッブ・サーバに関し前のリクエストは次のリクエストに関して何の関係ももっていない。リクエストを処理する際ウエッブ・サイトはこれら一連のリクエストに対して何の制御も行わない。
【００１２】
これらの問題を克服する試みにおいて、米国特許５，９５１，６４３号にはウエッブの同期化に対する情報を信頼性をもって組織化して管理し、また多くの消費者のブラウザを追跡する機構が記載されている。
【００１３】
しかしその解決法は、「傍受」され、好意的に協調し、明示された用途をもってホストに接続することに同意した、確認されたユーザーの活動状況の追跡に限られている。
【００１４】
本発明の主な目的は、ネットワーク通信供給業者がそのネットワークに接続したどのユーザーに対しても傍受できる監視および管理方法およびそのシステムを提供することである。
【００１５】
本発明の他の目的は、ネットワーク通信供給業者がリアルタイムでネットワークで通信中のすべてのユーザーの活動状況を監視できる傍受の方法を提供することである。
【００１６】
本発明のさらに他の目的はウエッブ・サイトの所有者がそのウエッブ・サイトに接続しているユーザーを監視し傍受できるようにすることである。
【００１７】
（本発明の概要）
従って本発明によれば、或る与えられた端末のブラウザ（「本来のブラウザ」）の活動状況のシミュレーションを行うネットワーク・プローブ端末（「端末エージェント」）によってネットワークの通信ラインを追跡する方法において、該方法は通信ラインを通って送られるＴＣＰ／ＩＰデータ・パケットを追跡し、与えられたＩＰアドレスに関連したＴＣＰ／ＩＰデータ・パケット（「識別されたデータ・パケット」）を選択し、識別されたデータ・パケットから新しい接続に対する現在のリクエスト（「本来のリクエスト」）を選択し、識別されたデータ・パケットから新しいアドレスを示す現在のウエッブ・ページの構成要素（「新しいナビゲーション要素」）を選択し、この新しいナビゲーション要素を二つの範疇、即ち埋め込まれたオブジェクトまたはフレーム（「偽値をもつ新しい構成要素」）およびハイパーリンク（「真値をもつ新しい構成要素」）に分割し、本来のリクエストを分割して真値をもつものとして新しい構成要素に合致する本来のリクエスト或いはどの新しい構成要素とも一致せず且つＨＴＴＰまたはＰＯＳＴタイプに属する本来のリクエストを「一番目のリクエスト」として、また偽値をもつ構成要素に合致した本来のリクエストを「二番目のリクエスト」として分類し、識別されたデータ・パケットから一番目のリクエストに関連したＨＴＭＬデータ・ファイル（それぞれの一番目の応答」）を選択し、それぞれの二番目の応答に従って「仮想的な」二番目の応答を生成し、識別されたデータ・パケットから二番目の仮想的な応答に関連した応答（「それぞれの二番目の応答」）を選択し、このそれぞれの二番目の応答に従って端末エージェント上でウエッブ・ページを提示するシミュレーションを行うことを特徴とする方法が提供される。
【００１８】
本発明のこれらのおよび他の特徴および利点は、添付図面を参照し単に例示の目的で下記に行われる本発明の若干の好適具体化例の詳細な説明によって明らかになるであろう。
【００１９】
（好適具体化例の詳細な説明）
図１を参照すれば、端末０１、０２・・・は同じ通信ラインに連結され、この通信ラインは内部ネットワーク（「イントラネット」）または外部ネットワーク、例えばインターネットとして使用されるものとしよう。本発明に従えば、規定されたネットワーク・プローブ（以後端末エージェントと呼ぶ）をデータ通信ラインに連結するように提案される。或はまた端末０１、０２等および端末エージェントはこれを異なったデータ通信ラインにに接続するか、または異なったローカル・ネットワークに配置することができる。
【００２０】
端末エージェントの操作の一般的な図式を図２に示す。
【００２１】
端末エージェントは通信ラインを通るすべてのデータ・フレームに解放されている。データ・フレームは端末の間を伝送される情報またはインターネット・サーバにのような外部の発信源への外部データの送信に関する情報を含んでいることができる。
【００２２】
さらに、このデータ通信ラインの「所有者」、例えばＩＳＰ（インターネット・プロバイダー）または私的機関のネットワークの所有者は、或る端末がインターネット・サーフィングを行った場合、その実際の通信活動をリアルタイムで監視することに関心をもっていると仮定しよう。
【００２３】
端末エージェントの操作はＴＣＰ／ＩＰデータ・パケットを追跡するためにデータ・フレームを先ず解析することである。図３に示すように、データの解析は異なったプロトコル階層構造（インターネット・プロトコルのＲＧＣ ０７９３参照）に従って、即ち先ずローカル・ネットワークのプロトコルを解析し、次いで外部データの伝送（「ゲートウエイ・レベル」）を選別し、次にインターネット・プロトコル（ＩＰ）のデータ・フレームを識別し、最後に「ホスト・レベル」のＴＣＰ（「伝送制御プロトコル」）のデータ・パケットを検出する方法で行う。
【００２４】
データ・パケットのＩＰ ＨＥＡＤＥＲを解析する際、リクエストを出した端末およびメッセージの転送先のＩＰアドレスを識別する。通信ラインの所有者はこのＩＰアドレスをユーザーの端末と容易に関連付けることができる。しかる後他のすべての関連のないデータ・パケットを選別して除去し、以後の処理は一つの選択された端末のデータ（以後識別されたデータ・パケットと呼ぶ）の伝送に限定される。
【００２５】
識別されたデータ・パケットはさらにＲＦＣ ０７９仕様によって解析され、データ通信ポートの完全な管理と制御ができるようにする。
【００２６】
通常のブラウザ、例えばインターネット・エクスプローラのようなＴＣＰデータ通信ポートを管理する公知の手順に従えば、ブラウザを操作する端末はすべてのデータ伝送の本来の発信元である。例えばＹＡＨＯＯ！のホームページにリクエストをしたとしよう。このリクエストはネットワークを通じてＹＡＨＯＯ！のサーバへ送られる。それに応答してサーバはウエッブのｙａｈｏｏのホームページの構成要素に関するすべての情報を含むＨＴＭＬデータを送ってくる。従ってブラウザは新しい通信の「仮想」ポートを開くことによってウエッブ・ページのすべての構成要素を受け取るための新しいリクエストを送り、この場合各ポートは同じウエッブ・ページの異なった構成要素を伝送するのに使用される。すべてのデータのリクエストおよびそれぞれの応答に対して解放されている「部外者」の端末は、最初の「一番目の」リクエスト、例えば完全なＹＡＨＯＯ！のホームページに対するリクエストと、その構成要素を受け取るための「二番目の」リクエストとを区別することはできない。「部外者」のプローブ端末によって本来のブラウザの活動状況のシミュレーションを行うためには、一番目のリクエストをそのまま識別することが重要である。
【００２７】
図４は一番目のリクエストを二番目のリクエストと区別する方法を示す。一番目のリクエストはユーザーが新しいＵＲＬを入力し、ハイパーリンクを選択するなどの種々の操作からつくられる。従って同じものを検出するためには同じＩＰアドレスに送られた前の情報を解析しなければならない。端末が受け取ったウエッブ・ページのすべての新しい移行要素（ブラウザを新しい場所に向かわせる）は、そのタイプに従って保存され、この際すべての埋め込まれたオブジェクト、フレーム等は「偽」の要素としてマークが付けられ、ハイパーリンクには「真」の要素のマークが付けられる。すべてのデータは後で使用するために入力バッファー応答データベースに保存される。
【００２８】
ＴＣＰの解析に従って新しい接続に対するリクエストが識別された場合、入力応答バッファーの中でそれぞれのナビゲーション要素（ＲＮＣ）に従ってこのリクエストを調べる。ＲＮＣに「偽」のマークが付けられている場合このリクエストは無視される。ＲＮＣに「真」のマークが付いている場合には、このリクエストを一番目として分類する。そうではなくて該リクエストに関するＲＣＮが存在しない場合には、接続のタイプを識別しなければならない。接続がＨＴＭＬタイプまたは「ＰＯＳＴ」タイプの場合には、これを一番目のリクエストとして分類する。
【００２９】
端末の活動状況を調べ監視するためには、すべての「本来の」ブラウザの活動状況を再構築しなければならない。この目的に対しては「仮想的な」ブラウザを使うことが示唆されている。この仮想的なブラウザは、リアルタイムでウエッブ・ページをインターネットからダウンロードする「実在の」ブラウザのすべての能力をもっている。しかし、インターネット・サーバに対して実際のデータの交換は全く行わず、本来の「実在の」ブラウザの活動のシミュレーションを行うだけであるという点においてそのインターネットとの接続は仮想的である。
【００３０】
仮想的なブラウザの第１の機能を図５に示す。このブラウザは「実在の」ブラウザのすべての一番目のリクエストを受け取る。これらの一番目のリクエストおよびそれぞれに対するインターネットからの一番目の応答を解析し、通常のブラウザ操作に従って処理を行う。二番目の仮想的なリクエスト（通常のブラウザにおいてウエッブ・ページの構成要素をダウンロードする過程を完了するのに使用される）の結果は、通常のようにインターネットを通じて適当なサーバへ直接送られずに、仮想的な「二番目の」リクエストのバッファー・データベースに保存される。
【００３１】
仮想的なブラウザの接続は「実在の」接続ではないが、ポートの接続を開き制御するすべてのＴＣＰプロトコルの管理は、あたかもその接続が「実在の」接続であるかのように端末エージェントによって処理される。
【００３２】
仮想的なブラウザにおいてシミュレーションを行いウエッブ・ページを提供する最終的な過程をさらに図６に示す。通信ラインを通って入ってくるすべての本来の二番目の応答を分析し、入力応答バッファー・データベースに保存する。仮想的なリクエストを、到着順に入力応答バッファー・データベースに保存されたそれぞれの二番目の応答と比較する。それぞれの二番目の応答が既にバッファーの中に存在している場合、これらの応答は仮想的なブラウザに送られ、（通常のブラウザ操作に従って）処理され、それぞれのウエッブ・ページの構成要素の仮想的な図を提供する。その結果端末エージェントは、本来の端末によって行われるように、リアルタイムでインターネットのウエッブ・ページをダウンロードする正確な過程のシミュレーションを行う。
【００３３】
それぞれの応答が入力応答バッファー・データベースの中に現れない場合には、本来のローカル・キャッシュの活動状況を推論する。該仮想的なリクエストに関し本来のローカル・キャッシュを使用しなかった場合、本来の二番目のそれぞれの応答が到着するまでそれをバッファー・データベースの中に保留にしておく。そうでなくてこの応答に関し実在のローカル・キャッシュを使用した場合には、仮想的なブラウザのローカル・キャッシュを調べ、ローカル・キャッシュの中にそれぞれの二番目の応答が存在する場合には、それぞれの応答を仮想的なブラウザに送り、上記のようにして処理する。仮想的なキャッシュの中にそれぞれの応答が存在しない場合には、次の二つの方法がとられる。その一つ、端末エージェントの「受動的な」態様に従えば、「見つからない」応答を見つけようとする動作はなされず、ウエッブ・ページの構成要素が実在の端末に現れる代わりに端末エージェントに「エラー」メッセージが現れる。この態様に従えば、実在の端末でのシミュレーションは完了せず、傍受の活動は検出できない。他の「能動的な」態様に従えば、端末エージェントはウエッブ・ページのサーバに対し、「見つからない」という応答を出すことを要求する。この態様では端末エージェントは実在の端末の活動のさらに正確な図を提供することができるが、傍受の活動を検出できるもっと経験を積んだ端末のユーザーにとってそれ追跡可能である。
【００３４】
本発明を実装する他の態様に従えば、関連するウエッブ・ページ・パケットを傍受するばかりでなく、例えばｅ−メールまたはチャットのような関連したメッセージ・データを傍受することが提案される。このような傍受を可能にするには、ウエッブ・ページをリクエストする以外のネットワークを通じてメッセージを送りまた受け取るために、要求に応じて上記と同じ方法および原理を適用する。このようなリクエストおよびそれぞれの応答を解析する方法は効率が高い。何故ならば定義によりこのような情報は常に新しいのでキャッシュ・メモリーの活動状況をチェックする必要がないからである。
【００３５】
最後に、上記の具体化例はインターネットの通信環境に向けられたものであることを理解されたい。しかし本発明は広い態様において一般にコンピュータ化された通信網、例えば衛星ネットワーク、携帯電話ネットワーク、その他にも同様に適用することができる。
【００３６】
上記の説明は多くの仕様を含んでいるが、これらは本発明の範囲を制限するものではなく、好適な具体化例の例示であると考えるべきである。当業界の専門家は本発明の範囲内に入る他の可能な変形を考えることができるであろう。従って本発明の範囲は例示された具体化例によってではなく、添付特許請求の範囲およびその正当な同等事項によって決定されなければならない。
【図面の簡単な説明】
【図１】 本発明を実装できる典型的なネットワークの形態を示す図。
【図２】 端末エージェントの操作図式。
【図３】 ＴＣＰ／ＩＰデータ・パケットを追跡し識別する過程。
【図４】 ＴＣＰ／ＩＰリクエストを分類する流れ図。
【図５】 仮想的な二番目のＴＣＰ／ＩＰリクエストを生成するシミュレーションの流れ図。
【図６】 本物のブラウザの活動状況のシミュレーションを行う過程の流れ図。

Claims (18)

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

Images