JP2008527761A - リレー通信を検知する方法、システム及びソフトウェア - Google Patents

Abstract

潜在的リレー・デバイスがリレー・デバイスであるか否かを決定するための方法、装置、及びコンピュータにより読取り可能なコードを提供する。いくつかの実施形態において、第１情報エレメントと第２情報エレメントは、潜在的リレー・デバイスにより受信される。潜在的リレー・デバイスは第２情報エレメントのオリジナル・ソースである。潜在的リレー・デバイスがリレー・デバイスであるか否かを決定するためには、第１情報エレメントのオリジナル・ソースの特徴と、潜在的リレー・デバイスの特徴が、単一のデバイスに関連する可能性の低い特徴であるか否かが決定される必要がある。一実施形態において、本発明のシステムは、情報エレメント・レシーバと特徴不適合性解析器を備える。或いは、本発明のシステムは、特徴発見モジュール、パラメータ取得器、及び特徴データベースを備える。

Description

本発明は、リレー通信を検知するための方法、装置及びコンピュータにより読み取り可能なコードに関する。

リレー・デバイスは一般的に多くの通信メディアや通信環境に用いられる。特に、インターネット上で用いられることが多い。リレー・デバイスは、送信側から通信情報を受け取り受信側へその通信情報を送信する通信デバイスである。
リレー・デバイスは、送信側と受信側とが直接的に通信できない場合に用いられることがある。或いは、通信性能を高めるために或いは様々な用途におけるセキュリティ保持機能を向上させるために用いられる。

例えば、機密性を保持する必要のある環境（例えば、プライベート・コーポレート・データ・ネットワーク）にいるユーザは、公衆に利用可能なインターネット上のＨＴＴＰサーバへ直接的に接続することを禁止されていることがある（文書のＲＦＣシリーズについての情報について、ＲＦＣ２６１６を参照のこと。また、http://www.rfc-editor.orgのＲＦＣエディタのウェブサイトを参照のこと）。
このような場合、ＨＴＴＰプロキシサーバがセキュアネットワークにインストールされ、外部のＨＴＴＰサーバに接続可能とされる。ユーザは、プロキシを用いて、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスを外部のＨＴＴＰサーバから中継若しくは外部のＨＴＴＰサーバへ向けて中継する。
この実施例において、ＨＴＴＰプロキシサーバがリレー・デバイスになる。

他の実施形態において、小さなネットワーク（例えばホーム・ネットワーク）上のユーザは、ＳＯＣＫＳプロキシ（ＲＦＣ１９２８を参照）を用いて、多数のパーソナル・コンピュータからインターネットに接続する。パーソナル・コンピュータは、単一のＩＰアドレス（ＲＦＣ７９１を参照）で１つのネットワーク接続を利用する。
この実施例においてＳＯＣＫＳプロキシがリレー・デバイスになる。

他の実施形態において、いくつかのＨＴＴＰプロキシがキャッシュ・プロキシとして働く。これは、ＨＴＴＰプロキシが受け取った内容のローカルコピーを格納し、ローカル・ストレージから同一の内容に対するリクエストを提供することにより行われる。このようにして、キャッシュ・プロキシはリモート・サーバへ送信されたリクエストの数を低減させる。
他の実施例において、ＨＴＴＰプロキシが、コンテント・フィルタリング・プロキシとして働く。これは、好ましくないコンテンツへのユーザのアクセスを拒否することにより行われる。

これらの通常の使用に加えて、リレー・デバイスはしばしば、悪用の目的で用いられる。
例えば、悪意のユーザ（アタッカ）は、リレー・デバイスを用いて、アタッカ自身の真のＩＰアドレスを隠蔽する。ＩＰアドレスは、インターネット・サービス・プロバイダ（ISP: Internet Service Provider）の記録を調べることにより、アタッカの識別情報を曝すために用いられる。これにより、アタックがあった時間に誰がＩＰアドレスを用いたか明らかになる。アタックされたインターネット利用者が通信記録を見ても、リレー・デバイスのＩＰアドレスから通信記録が生じているので、アタッカは匿名性を維持し続け、アタックに対する罰（例えば、アタッカがＩＳＰアカウントを失うことや逮捕されること）を受けることはほとんどない。このような技術は、ハッカ、詐欺師やペテン師により、しばしば用いられる。

アタッカは一度にいくつかのリレー・デバイスを用いることもある。これは、１つのリレー・デバイスに、他のもう１つのリレー・デバイスなどを接続するように指示し、最後のリレー・デバイスに目標に接続するように指示することにより行われる。これにより、最後のリレー・デバイスの操作者がアタック時に用いられたＩＰアドレスを提供することを求められたときに、アタッカ自身は保護されることになる。

他の実施例において、アタッカは、多数のリレー・デバイスを用いて、多数の異なるユーザにより通信が行われたような錯覚状態を作り出す。アタッカはこの技術を用いて、悪用防止システム（Anti-Abuseシステム）を回避する。悪用防止システムは、アタッカが行う潜在的に悪用の可能性が高い動作の速度（例えば、一定時間に生じた動作回数）に基づいてＩＰアドレスをブロックする。
例えば、多くのオンライン・サービスはパスワードを用いてユーザ識別を行う。このようなオンライン・サービスは、何度かのログイン動作が失敗した後にＩＰアドレスをブロックする。これにより、ブルートフォース攻撃を防ぐ。ブルートフォース攻撃の間、アタッカは、成功裏にログインできるまで異なる数多くのパスワードを試しパスワードを復活させようと試みる。

他の実施例において、多くのオンライン・サービスが、個人情報へのディレクトリへのアクセスを提供する。クエリの速度が一定量を超えるならば、このようなオンライン・サービスはＩＰアドレスをブロックする。これにより、アタッカが大量の個人情報を入手しようとする試みを妨げる。このような技術は、スパム（非請求電子メッセージ）を送りつける悪用的操作に対しても用いられる。

他の実施例において、高いボリュームのメッセージを送信するＩＰアドレスをアンチスパム・システムがブロックする。
他の実施例において、ユーザがオンライン広告を見るたびに（或いはクリックするたびに）支払いを受けるウェブサイトが存在する。このような場合に、オンライン広告を出す企業は、同一のＩＰアドレスからの広告視聴（或いは広告へのクリック）を無視する。これにより、詐欺師が見せかけの広告視聴或いはクリックをすることを防止する。
多数のリレー・デバイスを用いることで、詐欺師はこれらの防御策を回避することが可能である。

他の実施例において、アタッカは、リレー・デバイスを用いて、アタッカ自身が異なる地理的位置に存在するかのような錯覚状態を作り出す。オンライン・クレジットカードの関連詐欺の試みが、多くの場合、米国以外の国からのものであるので、多くの米国のオンライン取引者は外国のクレジットカードの使用を受け付けない。或いは外国への製品の輸送を認めない。
詐欺師は、米国のクレジットカードを用いて、米国内の共犯者に商品を輸送させることで上記の防御策を打ち破る。

ＩＰアドレスの地理的位置は、IP geo-locationサービスにより報告される。例えば、このようなサービスは、Quova, Inc.（米国カリフォルニア州マウンテンビュー）により提供されるGeoPointといったものを例示できる（米国特許第６，６８４，２５０号明細書及び米国特許第６，７５７，７４０号明細書参照）。このＩＰアドレスの地理的位置がオーダにおける１つの住所或いは複数の住所と一致しない場合（例えば、ＩＰアドレスがインドネシアであるにもかかわらず、クレジットカードの請求書送付先住所が米国である場合）には、取引者はオーダを拒絶することが可能である。
詐欺師は、許容される地理的位置に存するリレー・デバイスを用いることで、上記の防御策を打ち破ることができる。

適切に設計されたリレー・デバイスは、アクセス制御機構を実装することができ、これにより、認証されたユーザにのみアクセス可能となるが、多くのリレー・デバイスは地球規模でアクセス可能であり（オープンプロキシとしてこのようなリレー・デバイスは知られている）、アタッカにより悪用される。
ある場面においては、オープンプロキシがハードウェア・デバイスの一部として出荷されたり、ソフトウェアの一部として出荷されたり或いはオーナが知らないうちにインストールされることに起因して作り出される。或いは、アドミニストレータが誤った仕様で或いは不注意にリレー・デバイスを設計し、認証を受けていないソースからの通信情報を中継するようにしてしまうことにより作り出されることもある。
他の場面においては、コンピュータのオーナの認可を受けることなく、オープンプロキシが悪意を持ってインストールされることもある。例えば、コンピュータのオーナに「トロイの木馬」を送りつけること、コンピュータウィルスによるものやコンピュータ内を手動でハッキングすることを例示できる（ハッキングは、誤作動やコンピュータを制御するための設計のミスを利用する操作である）。

リレー・デバイス、特に、地球規模でアクセス可能なリレー・デバイスはしばしば悪意の目的で用いられるので、多くのオンライン・サービス・プロバイダ及びオンライン取引者は、悪意を持ったものとしてリレー・デバイスを介した通信情報を取扱う。
例えば、多くのＳＭＴＰサーバ（ＲＦＣ８２１を参照）は、リレー・デバイスを介したＥメールを拒否する。また多くのＩＲＣサーバ（ＲＦＣ２８１０を参照）は、リレー・デバイスを介して接続するユーザを拒否する。またいくつかのインターネット取引者は、リレー・デバイスを介したオーダを受け付けない。

米国特許第６，６８４，２５０号明細書 米国特許第６，７５７，７４０号明細書

リレー・デバイスを介して通信が中継されたものであるか否かを決定する現状における方法は、通信のソースＩＰアドレスがリレー・デバイスに特有のものであるか否かを調査することに基づく（リレー・デバイスが、中継された通信において、リレー・デバイス自身のＩＰアドレスを報告することを仮定している）。

このような方法の１つが、ＨＴＴＰ通信がリレー・デバイスに特有のＨＴＴＰヘッダを含むか否かを調査することである。このようなヘッダの例として、「X-Forwarded-For」、「X-Originating-IP」、「Via」、「X-Cache」及び「Client-IP」を挙げることができる。この方法は、中継されたプロトコルがＨＴＴＰでないときに用いることが出来ないという点で限界がある。また、全てのリレー・デバイスがこのようなヘッダを報告するわけではないという点でも限界がある。特に、中継がＨＴＴＰより下の水準で実行される場合（ＳＯＣＫＳプロキシを用いた場合や、HTTP CONNECTメソッド（ＲＦＣ２８１７を参照）を用いる場合には、リレー・デバイスはヘッダを報告しない）。

他の方法は、ソースＩＰアドレスへ戻る接続を試みることである（逆方向の接続を作り出す）。この方法は、合意されたプロトコル（Agreed Upon Protocol）を用いる。このプロトコルはリレー・デバイスにはほとんどの場合実装されない。例えば、多くのＩＲＣサーバは、識別プロトコル（ＲＦＣ１４１３を参照）を用いてソースＩＰアドレスへ戻る接続を構築しようとする。ほとんどのＩＲＣクライアントは識別プロトコルを実装している。リレー・デバイスは識別プロトコルを実装していないので、ソースＩＰアドレスへ戻る接続が成功したとの表示をソースＩＰアドレスから受け取った場合には（例えば、ＳＹＮ及びＡＣＫコントロール・フラグを備えるＴＣＰセグメントを例示することができる。ＴＣＰの説明については、ＲＦＣ７９３を参照）、通信が中継されていないものであることを意味するものとなる。
この方法では、プロバイダ及びユーザが逆方向の接続を用いるプロトコルについて合意をしなければならない点で限界がある。したがって、サービス・プロバイダは、全てのユーザに対して、合意されたプロトコルを用いて接続を作り出さなければならず、全てのユーザはそのような接続を可能とするサーバを操作しなければならない。

他の方法として、プロトコル及びリレー・デバイスに一般的に用いられているポート・ナンバ（例えば、SOCKS on TCP port 1080やHTTP on TCP port 8080）を用いて、逆方向の接続を作り出し、通信の中継を試みる手法を挙げることができる。ほとんどのユーザは、地球規模でアクセス可能な通信リレーをユーザのコンピュータ上で操作していないので、中継の試みが成功した場合には、ユーザがリレー・デバイスを使用している可能性が高いことが分かる。
この方法は、サービス・プロバイダが全てのユーザに対して逆方向の接続を作り出さなければならない点で限界がある。また、多数の逆方向の接続を行うために、出来る限りのリレー・デバイス設計の重要な部分（ポート）を網羅する必要があるという点でも限界がある。またこの方法では、多数の逆方向の接続を作り出す必要があることからリソースを浪費する操作を要し、またこのような操作は非倫理的、悪用的或いは問題の多い手法となる可能性がある。

現状の手法の限界を軽減する試みとして、オンライン・サービス・プロバイダは互いに、リレー・デバイスに関する情報を分かち合っている。例えば、サービス・プロバイダは、しばしばデータベース（ブラックリストとして知られる）を検索する。このデータベースには、地球規模でアクセス可能な通信リレーの様々な通信パラメータが載せられている。このパラメータは他のサービス・プロバイダにより発見されたものや、データベースのオペレータにより発見されたものが含まれる。サービス・プロバイダは、任意のソースＩＰアドレスがリストに載っているか否かをチェックすることが可能である。このようなデータベースとして、Mail Abuse Prevention System LLC（米国カリフォルニア州サンノゼ）が管理するMAPS Open Proxy Stopperを例示することができる。これらデータベースは、通信パラメータをリストアップするための方法に限界があり、また、常に最新の情報であるとは限らないという点で限界がある。
したがって、通信がリレー・デバイスを介して行われたものであるか否かを決定する効率的な方法の必要性は明らかである。

本出願は、まず、潜在的リレー・デバイスから受け取った情報エレメントがリレー・デバイスを介して中継されたものであるか否かを決定する方法を開示する。開示される方法、即ち、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備える。潜在的リレー・デバイスは、第２の情報エレメントのオリジナル・ソースである。

いくつかの実施形態において、開示される方法は、第１の情報エレメントのオリジナル・ソースの特徴と潜在的リレー・デバイスの情報が単一のデバイスに関連しない特徴であるか否かを決定する段階を更に備える。
いくつかの実施形態において、開示される方法は更に、第１の情報エレメントのオリジナル・ソースの特徴と潜在的リレー・デバイスの特徴が単一のデバイスを現わすものでないことの特徴であるか否かを決定する段階を備える。

受け取った情報エレメントが中継されたものであるか否かを決定することに対してトランスミッタと情報エレメントのオリジナル・ソースのいくつかの特徴が非常に有用であることが本明細書に開示される。受け取った情報エレメントが中継されたものであるか否かを検知するのに有用なトランスミッタ及び情報エレメントのオリジナル・ソースの特徴は、デバイスのコンフィギュレーションの状態、デバイスの通信性能、関連するDNSリクエストの特徴及びレイテンシ・パラメータ、例えば、トランスミッタ及び／又は情報エレメントのオリジナル・ソースへのラウンド・トリップ・タイムを挙げることができるがこれに限られるものではない。

ある実施形態において、第２の情報エレメントは、リレー・デバイスのうち１つのクラスにあるリレー・デバイスが中継しない種類の情報エレメントである。
ある実施形態において、第１の情報エレメントは、リレー・デバイスのうち１つのクラスにあるリレー・デバイスが中継しない種類の情報エレメントである。
本発明の実施形態に関連するリレー・デバイスのクラスの例として、SOCKSプロキシ、GETメソッド及び／又はCONNECTメソッドを用いたHTTPプロキシを含むHTTPプロキシ、ＩＰルータ及びネットワーク・アドレス・トランスレーション・デバイスを挙げることができるが、これに限られるものではない。

第１の情報エレメント及び／又は第２の情報エレメントが通信の一部であり、通信が、IP、TCP、ICMP、DNS、HTTP、SMTP、TLS及びSSLからなる群から選択される。
いくつかの実施形態においては、第１の情報エレメント及び第２の情報エレメントが単一の通信の一部である。

いくつかの実施形態において、第１の情報エレメント及び第２の情報エレメントが、プロトコル・スタックの互いに異なる２つの層内に送信される。
いくつかの実施形態において、潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、第１の情報エレメントのオリジナル・ソースの特徴を発見する段階と、潜在的リレー・デバイスの特徴を発見する段階からなる。
いくつかの実施形態において、潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が更に、第１の情報エレメントのオリジナル・ソースの特徴を潜在的リレー・デバイスの特徴と比較する段階を備える。

このようにして、本明細書で説明される実施形態において、オペレーティング・システムといったコンフィギュレーションの状態のパラメータが、第１の情報エレメント及び潜在的リレー・デバイス両方に対して決定される。情報パケットのオリジナル・ソースと潜在的リレー・デバイスの間でコンフィギュレーションの状態のパラメータに不一致が発見されると、このことは、単一の装置でないことを表し、潜在的リレー・デバイスがオリジナル・ソースのデバイスと同一のデバイスでないということが推定される。これにより、潜在的リレー・デバイスが、オリジナル・ソースのデバイスと別個のリレー・デバイスであることが推定される。

いくつかの実施形態において、本発明に係る方法は、第１の情報エレメントのオリジナル・ソースの特徴を指し示すパラメータを得る段階と、潜在的リレー・デバイスの特徴を指し示すパラメータを得る段階を備える。
このようにして、第１の情報エレメントのソースと潜在的リレー・デバイスの特徴の知識を得る必要性がなくなる。特定の実施形態において、潜在的リレー・デバイスと第１の情報エレメントのソースの間の潜在時間の差（Differential Latency）が得られ、個々のレイテンシを得る必要性を生じない。

いくつかの実施形態において、本発明に係る方法は、第１の情報エレメントのオリジナル・ソースの特徴と潜在的リレー・デバイスの特徴との間の関係を指し示すパラメータを得る段階を備える。
いくつかの実施形態において、潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が更に、第１の情報エレメントのオリジナル・ソースの特徴と潜在的リレー・デバイスの特徴の間の関係を指し示すパラメータの解析を行う段階を備える。
いくつかの実施形態において、パラメータが、第１の情報エレメントと第２の情報エレメントのうち少なくとも一方から得られる。
いくつかの実施形態において、本発明に係る方法は更に、第１の情報エレメントのオリジナル・ソースとリレー・デバイスのうち少なくとも一方へ送出方向の通信を送る段階と、第１の情報エレメントのオリジナル・ソースと潜在的リレー・デバイスのうち少なくとも一方から第３の情報エレメントを受け取る段階を備える。
いくつかの実施形態において、本発明に係る方法は更に、第３の情報エレメントから、第１の情報エレメントのオリジナル・ソースと潜在的リレー・デバイスのうち少なくとも一方の特徴に関連した情報を引き出す。
いくつかの実施形態において、本発明に係る方法は更に、第３の情報エレメントのオリジナル・ソースが第１の情報エレメントのオリジナル・ソースであることを確認する段階を備える。
いくつかの実施形態において、本発明に係る方法は更に、第３の情報エレメントのオリジナル・ソースが潜在的リレー・デバイスであることを確認する段階を備える。

一実施形態の例において、第１の情報エレメントと第２の情報エレメントを受け取った後に、HTTPレスポンスとピングが通信のソースであると主張されるソースに戻される。直前にリレー・デバイスが存するか否かにかかわらず、HTTPレスポンスは、リレー・デバイスにより中継され、通信のオリジナル・ソースへ向かい、第３の情報エレメントに戻る。対照的に、リレー・デバイスは、ピングに応答し、ピングを第１情報エレメントのオリジナル・ソースに送ることはない。このようにして、広範囲のレイテンシの差異がリレー・デバイスの存在を指し示すことになる。

いくつかの実施形態において、本発明に係る方法は更に、潜在的リレー・デバイスから第３の情報エレメントを受け取る段階と、第３の情報エレメントから潜在的リレー・デバイスに関連する情報を引き出す段階を備える。
いくつかの実施形態において、本発明に係る方法は更に、第１の情報エレメントのソースから第３の情報エレメントを受け取る段階と、第３の情報エレメントから第１の情報エレメントのソースの特徴に関連する情報を引き出す段階を備える。
いくつかの実施形態において、第１の通信のソースの特徴と潜在的リレー・デバイスの特徴のうち少なくとも一方が、コンフィギュレーションの状態に関連した特徴である。
一例として、コンフィギュレーションの状態に関連する特徴は、オペレーティング・システムの種別、オペレーティング・システムのバージョン、ソフトウェアの種別、HTTPクライアントの種別、HTTPサーバの種別、SMTPクライアントの種別、SMTPサーバの種別、時間設定、クロック設定及びタイムゾーンの設定を挙げることができるが、これに限られるものではない。

いくつかの実施形態において、第１の情報エレメントのオリジナル・ソースの特徴と、前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、コンフィギュレーションの状態に関連する前記特徴を指し示すパラメータを調査する段階を備える。
一例として、このようなパラメータに、HTTPユーザ・エージェント・ヘッダ、RFC822・Ｘメイラ・ヘッダ、RFC822レシーブド・ヘッダ、RFC822日付ヘッダ、プロトコル実装様式、TCP/IPスタック・フィンガプリント、IPアドレス、TCPポート、TCPイニシャル・シーケンス・ナンバ及びTCPイニシャル・ウィンドウ、WHOISレコード、リバースDNSレコード及び肯定応答情報のレイトを挙げることができるが、これに限られるものではない。

いくつかの実施形態において、第１の情報エレメントのソースの特徴と潜在的リレー・デバイスの特徴のうち少なくとも一方が通信性能に関連する。
いくつかの実施形態において、通信性能に関連する特徴が、測定された通信性能、測定された相対的通信性能及び推定される通信性能からなる群から選択される。
いくつかの実施形態において、通信性能に関連する特徴が、通信のレイテンシ、受入方向の通信のレイテンシ、送出方向の通信のレイテンシ、通信レイト、受入方向の通信レイト、送出方向の通信レイト、受入方向の最大通信レイト及び送出方向の最大通信レイトからなる群から選択される。
いくつかの実施形態において、第１の情報エレメントのオリジナル・ソースの特徴と、潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、通信性能に関連する特徴を指し示すパラメータを調査する段階を備える。
いくつかの実施形態において、パラメータが、情報エレメントの受領時間、情報エレメントの送信時間、ラウンド・トリップ・タイム、ラウンド・トリップ・タイムのギャップ、IPアドレス、WHOISレコード、リバースDNSレコード及び肯定応答情報のレイトからなる群から選択される。
いくつかの実施形態において、ラウンド・トリップ・タイムのギャップが大きければ大きいほど、リレー・デバイスが悪意の目的で使用されている可能性が高いことを指し示すものとされる。
いくつかの実施形態において、第１の情報エレメントのソースの特徴と、潜在的リレー・デバイスの特徴のうち少なくとも一方がサブ・ネットワーク、ネットワーク・アドミニストレータ及び地理的位置からなる群から選択される。
いくつかの実施形態において、第１の情報エレメントのオリジナル・ソースの特徴と、潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、第１の通信のソースの特徴と、第２の通信のソースの特徴のうち少なくとも一方を指し示すパラメータを調査する段階を備え、パラメータが、HTTPユーザ・エージェント・ヘッダ、RFC822・Ｘメイラ・ヘッダ、RFC822レシーブド・ヘッダ、RFC822日付ヘッダ、IPアドレス、WHOISレコード及びリバースDNSレコードからなる群から選択される。

本出願は、更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、潜在的リレー・デバイスは第２の情報エレメントのオリジナル・ソースである。更に、第１の情報エレメントと第２の情報エレメントのうち少なくとも一方のコンフィギュレーションの状態を解析する段階を備え、このコンフィギュレーションの状態が、オペレーティング・システムの種別、オペレーティング・システムのバージョン、ソフトウェアの種別、HTTPクライアントの種別、HTTPサーバの種別、SMTPクライアントの種別、SMTPサーバの種別、時間設定、クロック設定及びタイムゾーンの設定からなる群から選択される。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、潜在的リレー・デバイスは第２の情報エレメントのオリジナル・ソースである。更に、この方法は、第１の情報エレメントと第２の情報エレメントのうち少なくとも一方のオリジナル・ソースの通信性能に関連する特徴を解析する段階を備える。
いくつかの実施形態において、通信性能に関連する特徴が、通信のレイテンシ、受入方向の通信のレイテンシ、送出方向の通信のレイテンシ、通信のラウンド・トリップ・タイム、通信レイト、受入方向の通信レイト、送出方向の通信レイト、受入方向の最大通信レイト及び送出方向の最大通信レイトからなる群から選択される。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、メッセージを潜在的リレー・デバイスに送り、メッセージを最終的に受領する潜在的リレー・デバイスが送出方向のDNSリクエストを送信し、送出方向のDNSリクエストから、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する段階を備える。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、潜在的リレー・デバイスが、第２の情報エレメントのオリジナル・ソースである。更にこの方法は、潜在的リレー・デバイスへのラウンド・トリップ・タイムが、第１の情報エレメントのオリジナル・ソースへのラウンド・トリップ・タイムと比べて有意な差異が存するか否かをチェックする段階を備える。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、潜在的リレー・デバイスが、第２の情報エレメントのオリジナル・ソースである。この方法は更に、潜在的リレー・デバイスのオペレーティング・システムが第１の情報エレメントのオリジナル・ソースのオペレーティング・システムと相違するか否かをチェックする段階を備える。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、潜在的リレー・デバイスが、第２の情報エレメントのオリジナル・ソースである。この方法は更に、潜在的リレー・デバイスの位置が第１の情報エレメントの位置と相違するか否かをチェックする段階を備える。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、潜在的リレー・デバイスが、第２の情報エレメントのオリジナル・ソースである。この方法は更に、潜在的リレー・デバイスのアドミニストレータが第１の情報エレメントのオリジナル・ソースのアドミニストレータと相違するか否かをチェックする段階を備える。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法を開示する。開示される方法は、第１の情報エレメントのオリジナル・ソースの特徴と潜在的リレー・デバイスの特徴が単一のデバイスに関連しないことを示す特徴であるか否かをチェックする段階を備える。潜在的リレー・デバイスは、第１の情報エレメント及び第２の情報エレメントのトランスミッタである。潜在的リレー・デバイスは第２の情報エレメントのオリジナル・ソースである。単一のデバイスに関連しないことを示す特徴であると決定された場合には、潜在的リレー・デバイスはリレー・デバイスである。

本発明は、受け取った情報がリレー・デバイスにより中継されたものであるか否かを決定する方法を開示する。開示される方法は、受信した情報エレメントから、通信性能測定方法を決定する段階と、この決定する段階の結果から、受け取った情報がリレー・デバイスにより中継されたものであるか否かを指し示す出力を作り出す段階を備える。

本発明は、受け取った情報がリレー・デバイスにより中継されたものであるか否かを決定する方法を開示する。開示される方法は、受け取った情報エレメントから通信性能を指し示すパラメータを決定する段階と、この決定する段階の結果から、受信した情報がリレー・デバイスにより中継されたか否かを指し示す出力を作り出す段階を備える。

決定された通信性能測定方法の一例として、モニタされるホストとの通信のレイテンシ、モニタされるホストとの通信の受入方向のレイテンシ、モニタされるホストとの通信の送出方向のレイテンシ、通信レイト、受入方向の通信レイト、送出方向の通信レイト、受入方向の最大通信レイト及び送出方向の最大通信レイトを挙げることができるが、これに限られるものではない。

本出願は更に、潜在的リレー・デバイスがリレー・デバイスであるか否かを決定するシステムを開示する。
いくつかの実施形態において、開示されるシステムは、情報エレメント・レシーバを備え、情報エレメント・レシーバは、情報ソース・デバイス及び潜在的リレー・デバイスを含む複数のデバイスから情報エレメントを受け取る。更にこのシステムは、特徴不適合性解析器を備え、特徴不適合性解析器は、情報ソース・デバイスの特徴と潜在的リレー・デバイスの特徴が単一のデバイスに関連しない特徴であるか否かを決定する。
いくつかの実施形態において、開示されるシステムは更に、特徴発見モジュールを更に備え、特徴発見モジュールが、情報ソース・デバイスの特徴と潜在的リレー・デバイスの特徴からなる群から選択される少なくとも１つの特徴を発見する。
必要に応じて、情報エレメント・レシーバが、更に、モニタされるホストから情報エレメントを受け取るように形成される。
必要に応じて、送出方向の情報エレメント用の送受信端末を更に備える。

いくつかの実施形態において、システムは、パラメータ取得器を更に備え、パラメータ取得器が、情報ソース・デバイスの特徴を指し示すパラメータ、潜在的リレー・デバイスの特徴を指し示すパラメータ及び情報ソース・デバイスの特徴とリレー・デバイスの特徴が単一のデバイスに関連しないことを示す特徴であるか否かを指し示すパラメータからなる群から選択される少なくとも１つのパラメータを取得することを特徴とする。
いくつかの実施形態において、特徴データベースを更に備え、特徴データベースが特徴の対とデータのマップを格納し、データが、特徴の対が不適合性を示す特徴であるか否かを指し示す。
これらの実施形態及び更なる実施形態が以下に示す説明並びに実施形態から明らかになる。

以下、本発明並びに本発明を実用化する方法を理解するために、好適な実施形態が以下に図面を参照しつつ示されるが、以下に示す例は本発明を何ら限定するものではない。

本発明について説明する前に、本明細書中で用いる用語の定義を明らかにすることが本発明を理解するために役立つと思われる。

本明細書中において、「通信（communication）」とは、少なくとも１つの情報エレメントを２つのデバイス間で転送することを示す。例えば、１つのデバイスから別のデバイスにインターネット上で転送されるＩＰパケットは１つの通信である。他の例としては、インターネット上でＨＴＴＰクライアントからＨＴＴＰサーバに転送されるＨＴＴＰリクエストは１つの通信である。１若しくはそれ以上の通信が１若しくはそれ以上の他の通信に転送される。一方の情報がもう一方の情報を包含してなる通信の群は、「プロトコル・スタック（Protocol Stack）」と呼ばれる。例えば、ＨＴＴＰプロトコルによる通信（すなわち、ＨＴＴＰリクエスト或いはレスポンス）は、ＴＣＰプロトコルによる通信（すなわち、ＴＣＰ接続）に包含され、更にＴＣＰプロトコルによる通信がＩＰプロトコルによる通信（すなわち、１もしくはそれ以上のＩＰデータグラム）に包含される。

本明細書中において、「情報エレメントのオリジナル・ソース（original source）」とは、情報エレメントを送信したデバイスを示すのであって、他のデバイスからの情報エレメントを中継するデバイスを示すものではない。

本明細書において、「トランスミッタ（transmitter）」とは、情報エレメントを送信したデバイスを示す。トランスミッタが送信する情報エレメントは、他のデバイスから中継された情報エレメントを含む。情報エレメントがデバイスから受信されるとき、このデバイスは該情報エレメントのトランスミッタである。

本明細書中において、「特徴（feature）」とは、デバイスに関する任意の情報であって、２つの異なるデバイス間で異なる情報を示す。

本発明の実施形態として、データネットワークを介して「情報エレメント」を受信及び／又は送信する例を説明する。いくつかの実施形態において、情報エレメントは通信プロトコルを用いて伝達される。データネットワークを介して情報エレメントを伝達するための通信プロトコルとして、例えばＨＴＴＰ、ＳＭＴＰ、ＤＮＳ（RFC 1034を参照）、ＳＳＬ／ＴＬＳ（RFC 2246を参照）、ＴＣＰ、ＵＤＰ（RFC 768を参照）、ＩＰ、及びＩＣＭＰ（RFC 792を参照）が挙げられるが、これらには限定されない。

図１は、本発明のいくつかの実施形態にしたがって、リレー検知システム（１０２）が動作する環境を示す。いくつかの実施形態においては、リレー検知システム（Relay Detection System ＲＤＳ）(１０２）は、インターネット（１００）を介して情報ソース・デバイス（Information Source Device ＩＳＤ）（１０４）から伝達される情報エレメントを受信する。

いくつかの例において、モニタされるホスト（Monitored Host ＭＨ）（１１０）に情報エレメントを送信するために、ＩＳＤ（１０４）はまずリレー・デバイス（Relay Device ＲＤ）（１０８）に情報エレメントを送信する。ＲＤ（１０８）は、情報エレメントを受信した後、受信した情報エレメントをＭＨ（１１０）に中継する。これらの例では、中継される情報エレメントは、パス（１２２）として示されるように、情報ソース・デバイス（１０４）からモニタされるホスト（１１０）に中継される。

若しくは、ＩＳＤ（１０４）はリレー・デバイス（１０８）を用いずに、モニタされるホスト（１１０）に情報エレメントを送信する。この場合、パス（１２０）に示されるように、情報エレメントはＲＤ（１０８）を通過することがない。

ＭＨ（１１０）に送信される情報エレメントが、ＲＤ（１０８）を介して送信されるか否かを特定することが望ましい。

本発明の発明者は、ＭＨ（１１０）に送信される情報エレメントがＲＤ（１０８）を介して送信されるか否かを決定するための改良された方法、装置、及びコンピュータにより読取り可能なソフトウェアを考案した。いくつかの実施形態において、この決定する段階は、ＲＤＳ（１０２）により実行される。ＲＤＳ（１０２）は、ＭＨ（１１０）により受信される少なくとも１つの通信をモニタするとともに、通信がＲＤ（１０８）を用いてＭＨ（１１０）に送信されるか否かについての決定を試みる。本明細書中において、「モニタ」とは、通信を受信する行為をさす。このとき、受信される通信はモニタを行うデバイスから送信されるか、或いは該デバイスに送信される。

本発明においては任意の種類のリレー・デバイスを使用可能である。リレー・デバイスの種類の例としては、SOCKSプロキシ（RFC 1928参照）、GETメソッドとともに用いられるHTTPプロキシ（RFC 2616参照）、CONNECTメソッドとともに用いられるHTTPプロキシ（RFC 2817参照）、IPルータ（RFC 1812参照）、NATデバイス（RFC 2663参照）が挙げられるがこれらには限定されない。

ＩＳＤ（１０４）は任意のデータネットワーク（例えばインターネット（１００））を介して他のデバイスと通信するデバイスである。いくつかの実施形態において、ＩＳＤ（１０４）は一人の人間、或いは複数の人間により操作される。いくつかの実施形態において、ＩＳＤ（１０４）は自動的に動作する。いくつかの実施形態において、ＩＳＤ（１０４）は人間の行動を模擬しながら自動的に動作する。ＩＳＤの例としては、ＨＴＭＬブラウザ（例えばMicrosoft Internet Explorer）を実行するコンピュータ（ＨＴＭＬについての説明は、Ｗ３Ｃウェブサイト（http://www.w3.org/TR/html）のＨＴＭＬSpecificationを参照。）、ＩＲＣクライアントを実行するコンピュータ、ＳＭＴＰクライアントを実行するコンピュータ、ＸＨＴＭＬブラウザを実行する携帯電話が挙げられるが、これらには限定されない。ＭＨ（１１０）は任意のデータネットワーク（例えば、インターネット（１００））を介して他のデバイスと通信するデバイスである。一つの実施形態においては、モニタされるホスト（１１０）はサーバである。適切なモニタされるホスト（１１０）の例として、ＨＴＴＰサーバ、ＳＳＬ／ＴＬＳサーバ、ＳＭＴＰサーバ、ファイル・サーバ、テルネット・サーバ、ＦＴＰサーバ、ＳＳＨサーバ、ＤＮＳサーバ、及びＩＲＣサーバが挙げられるがこれらには限定されない。ＭＨ（１１０）の用途の例として、オンライン取引者をホストする、オンライン広告サービスを実行する、及び電子メールを受信するなどの用途が挙げられるがこれらには限定されない。

いくつかの実施形態において、ＲＤＳ（１０２）はＭＨ（１１０）から送信される情報エレメント及び／又はＭＨ（１１０）に送信される情報エレメントをモニタする。ＲＤＳ（１０２）が更に、ＲＤ（１０８）及び／又はＩＳＤ（１０４）と通信してもよい。或いはＲＤＳ（１０２）は更にＲＤＳ（１０２）から送信される情報エレメント及び／又はＲＤＳ（１０２）に送信される情報エレメントをモニタしてもよい。

ＲＤＳ（１０２）、ＩＳＤ（１０４）、ＲＤ（１０８）、及びＭＨ（１１０）のそれぞれは、ハードウェア、ソフトウェア、或いはこれらの組み合わせのいずれであってもよい。ＲＤＳ（１０２）、ＩＳＤ（１０４）、ＲＤ（１０８）、及びＭＨ（１１０）は、同一のチリ的位置又は異なる地理的位置に位置しても、或いは同一デバイスの構成要素であってもよい。

説明を簡単にするために、本明細書中で説明される環境は１つの情報ソース・デバイスと、１つのリレー・デバイスを含む。実際には、インターネット（１００）に接続された多くの情報ソース・デバイスが存在する。これら情報ソース・デバイスは、同じくインターネット（１００）に接続された複数のリレー・デバイスの１つのリレー・デバイスを使用してもよいし、使用しなくてもよい。本発明の目的は、情報ソース・デバイスがリレー・デバイスを使用しない一般的な場合と、情報ソース・デバイスがリレー・デバイスを使用する一般的な場合を区別することである。本明細書中で説明される環境の実際の環境（例えば、インターネット或いはその他のネットワーク）への外挿は、当業者の技術範囲内であることが理解できる。

図２Ａを参照する。本発明のいくつかの実施形態にしたがうと、ＲＤＳ（１０２）はＭＨ（１１０）へ送信される情報エレメントを受信する。この場合の潜在的リレー・デバイス（１５０）（Potential Relay Device ＰＲＤ）は情報エレメントのトランスミッタであってよく、必ずしも全ての或いは特定の情報エレメントのオリジナル・ソースである必要はない。いくつかの実施形態によると、潜在的リレー・デバイス（Potential Relay Device ＰＲＤ）（１５０）がどのようなデバイスであるかは不明であり、ＲＤ（１０８）又はＩＳＤ（１０４）のいずれであってもよい。

本発明のいくつかの実施形態によると、ＰＲＤ（１５０）がＲＤ（１０８）或いはＩＤ（１０４）のいずれであるかを決定するための方法、装置、コンピュータ可読ソフトウェアが提供される。

図２Ｂは、本発明のいくつかの実施形態においてＲＤＳ（１０２）により受信される情報エレメントのオリジナル・ソースを示す図である。第１情報エレメントと第２情報エレメントがＲＤＳ（１０２）により受信される。いくつかの実施形態によると、ＰＲ（１５０）は第２情報エレメントのオリジナル・ソースである。したがって第２情報エレメントを非リレー情報エレメント（Non-relayed Information Element ＮＲＩＥ）と呼ぶこともできる。一方で、ＩＳＤ（１０４）は第１情報エレメントのオリジナル・ソースであるから、第１情報エレメントを潜在的リレー情報エレメント（Potentially Relayed Information Element ＰＲＩＥ）と呼ぶこともできる。したがって、ＰＲＤ（１５０）がＩＤ（１０４）であるならば、ＰＲＤ（１５０）はＰＲＩＥのオリジナル・ソースである。ＰＲＤ（１５０）がＲＤ（１０８）であるならば、ＰＲＤ（１５０）はＰＲＩＥのオリジナル・ソースではない。

例えば、ＮＲＩＥはある特定の種類のリレー・デバイスにより中継されない種類の情報エレメントである。したがって、第２情報エレメントがその種類のリレー・デバイスにより実際に中継されないことが確認される。例えば、標準的なＨＴＴＰプロキシ（ＣＯＮＮＥＣＴ或いはＧＥＴメソッドのいずれかを用いる）はＩＣＭＰメッセージを中継しない。よって、ＲＤ（１０８）がその種類のプロキシであるならば、ＲＤ（１０８）はＩＣＭＰメッセージのトランスミッタであり、ＩＣＭＰメッセージはＮＲＩＥであることが確認される。

本発明のいくつかの実施形態によると、ＩＳＤ（１０４）の特徴とＰＲＤ（１５０）の特徴は、同一のデバイスに関連付けにくい特徴である（不適合性特徴）。或る特徴がデバイスに関連付けられているというためには、その特徴がその特定のデバイスに関する情報でなければならない。

いくつかの実施形態においては、ＩＳＤ（１０４）の特徴はＰＲＩＥのコンテンツに由来する。或いは、ＩＳＤ（１０４）の特徴は、下記の他の特徴に由来する。いくつかの実施形態においては、ＰＲＤ（１５０）の特徴はＮＲＩＥのコンテンツに由来する。或いは、ＰＲＤ（１５０）の特徴は、下記の他の特徴に由来する。

本発明において、ＰＲＤ（１５０）の特徴、或いはＩＳＤ（１０４）の特徴を実際に取得することは必ずしも必要ではない。以下で説明するいくつかの実施形態においては、ＲＤＳ（１０２）は、或る複数の特徴のうちいずれかの特徴或いは全ての特徴を探し出すことなく、これら特徴が不適合性特徴であるか否かを決定できる。不適合性特徴が存在するならば、ＩＳＤ（１０４）とＰＲＤ（１５０）が異なるデバイスである（即ちＰＲＤ（１５０）がＲＤ（１０８）である）可能性が増大する。一方で、不適合性特徴が存在しないならば、ＩＳＤ（１０４）とＰＲＤ（１５０）が同一のデバイスである（即ちＰＲＤ（１５０）がＲＤ（１０８）ではない）可能性が増大する。

図２ＣはＰＲＤ（１５０）がＩＳＤ（１０４）である場合を示す図である。この場合、第１情報エレメント（ＩＳＤ（１０４））のオリジナル・ソースが第２情報エレメント（ＰＲＤ（１５０））のオリジナル・ソースと同一のデバイスであることがわかる。よって、潜在的リレー・デバイス（１５０）がＩＳＤ（１０４）であって、リレー・デバイス（１０８）ではないと結論される。また、ＰＲＩＥがリレー・デバイス（１０８）により中継されなかったと結論される。

図２ＤはＰＲＤ（１５０）とＩＳＤ（１０４）が異なるデバイスである別の場合を示す図である。この場合、第１情報エレメント（ＩＳＤ（１０４））のオリジナル・ソースが第２情報エレメント（ＰＲＤ（１５０））のオリジナル・ソースと異なるデバイスであることがわかる。したがってＰＲＩＥはＰＲＤ（１５０）とは異なるオリジナル・ソースを有し、ＰＲＩＥはＰＲＤ（１５０）により中継されていないと結論される。即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）であると結論される。

本明細書中において、「特徴」とは少なくとも１つの特徴を示す。よって２つ以上の特徴の組み合わせは特徴として定義される。

本明細書中において、「ＩＳＤ特徴」は第１情報エレメントのオリジナル・ソース（即ちＰＲＩＥのソース。この場合ＩＳＤ（１０４））の特徴である。一方で、「ＰＲＤ特徴」は第２情報エレメントのオリジナル・ソース（即ちＮＲＩＥのソース。この場合ＰＲＤ（１５０））の特徴である。ＩＳＤ特徴、ＰＲＤ特徴、これら特徴の発見方法、これら特徴を用いてＩＤ（１０４）がＰＲＤ（１５０）と異なるデバイスであるか否かを決定する方法を以下で説明する。

上述のごとく、ＮＲＩＥがＲＤ（１０８）により中継されなかったことを確認するための１つの方法は、ＮＲＩＥとして、ＲＤ（１０８）が属する特定種類のリレー・デバイスにより中継されないことが分かっている種類の情報エレメントを選択することである。例えば、特定のＳＯＣＫＳプロキシは、ＨＴＴＰ通信を中継するが、ＴＣＰ通信は中継しない。ＲＤ（１０８）がＳＯＣＫＳプロキシである場合、ＲＤ（１０８）はＩＳＤ（１０４）と一のＴＣＰ接続を維持し、ＭＨ（１１０）と別の異なる一のＴＣＰ接続を維持するとともに、一のＴＣＰ接続から他のＴＣＰ接続へＨＴＴＰ通信を中継する。したがっていくつかの実施形態においては、ＰＲＩＥは中継される可能性のあるＨＴＴＰ通信の一部をなし、ＮＲＩＥは中継されないＴＣＰ通信の一部をなす。

いくつかの実施形態において、第１及び第２情報エレメント（ＮＲＩＥ及びＰＲＩＥ）は、１つの通信のプロトコル・スタック上の２つの異なるレイヤの一部をなす。したがって、或る特定の場合では、１つのＨＴＴＰがＴＣＰ通信を介して送信され、第１非リレー情報エレメントはこの通信ＴＣＰレイヤの一部をなす一方で、第２の中継される可能性のある情報エレメントはこの通信のＨＴＴＰレイヤの一部をなす。若しくは、第１及び第２エレメントは２つの異なる通信の一部をなす。

しかしながら、或る場合には、リレー・デバイス（１０８）の種類が、リレー検知システム（１０２）に必ずしも知られている必要はない。いくつかの実施形態において、本発明の方法は、特定の種類のリレー・デバイスを評価する或いはターゲットにする選択的段階と、リレー・デバイスの潜在的な種別が、ターゲットとされるリレー・デバイスの種別であるという仮定に基づいてこの方法を実行する段階とを明白に必要とする。

いくつかの実施形態においては、本発明の方法は、異なる組のＮＲＩＥ及びＰＲＩＥに対して繰り返される。このとき各組は、少なくとも１種類のリレー・デバイスを検知するために役立つ。

一般的に、いくつかの実施形態においては、本発明の方法が連続して或いは並行して複数回繰り返されてもよい。この場合、潜在的リレー・デバイスがリレー・デバイスである最終的な確率は、この方法を繰り返し実行した結果を何らかの方法で総計したものから求められる。いくつかの実施形態においては、総計を求める段階は、平均、加重平均、最小値、最大値、或いは総計結果を特徴付けるための任意の他の方法を得る段階からなる。

（通信レイテンシの利用）
本発明の一つの実施形態において、ＩＳＤ特徴はＩＳＤ（１０４）とＭＨ（１１０）との間の通信におけるレイテンシとなるように選択される。一方でＰＲＤ特徴はＰＲＤ（１５０）とＭＨ（１１０）との間の通信におけるレイテンシである。一つのデバイスから他のデバイスまでのレイテンシは通常比較的一定であるから、同一のデバイスが著しく異なる２つのレイテンシを示す可能性は低い。したがって、ＩＳＤ（１０４）のレイテンシと、ＰＲＤ（１５０）のレイテンシが著しく異なるならば、ＰＲＤ（１５０）とＩＳＤ（１０４）は異なるデバイスである可能性が比較的高い（即ちＰＲＤ（１５０）がリレー・デバイス（１０８）であり、ＰＲＩＥは中継される）。同様にＩＳＤ（１０４）のレイテンシとＰＲＤ（１５０）のレイテンシが類似しているならば、ＰＲＤ（１５０）とＩＳＤ（１０４）は同一のデバイスである（即ちＰＲＩＥは中継されなかった）。

本明細書中において「レイテンシ（latency）」とは、通信の送信と受信の間の時差を示す。

レイテンシは、様々な原因から生じる。１つの原因は電気信号或いは電磁波が通信のパス上の２点間の距離を伝達するために必要な時間である（例えば、電気ケーブル内の電気信号、光ファイバ内の光、マイクロ波中継装置内のマイクロ波など）。別の原因としては、情報が通信回線上を伝達するために必要な時間である（例えば１５００バイトが４８０キロバイト／秒（kbps）の通信回線を介して完全に伝達されるには、２５ミリ秒（ｍｓ）必要である。更に別の原因としては、多くのデータネットワークで用いられる蓄積転送方式である。蓄積転送方式では、通信の単位（例えば、パケット或いはセル）は、一の中間ネットワーク・エレメントに完全に受信された後にのみ、このエレメントから次のエレメントへ転送される。更に別の原因として、ネットワーク内のスイッチング・エレメントのバッファでの通信における遅延である（例えば、通信回線が通信を伝送する過程にあるとき、回線が開くまでの間、新たな通信はバッファ内に記憶される）。更に別の原因は、特定の通信の処理（例えばルーティング決定、暗号化、解読、圧縮、或いは再圧縮）に掛かる時間である。

通信は１つのデバイスから送信され、異なるデバイスにより受信されるから、通常レイテンシを測定するより、ラウンド・トリップ・タイム（RoundTrip Time ＲＴＴ）を測定するほうが容易である。ＲＴＴはＭＨ（１１０）から送出方向の通信（outgoing communication ＯＣ）が送信されてから、ＭＨ（１１０）により受入方向の通信（incoming communication ＩＣ）が受信されるまでに経過する時間である。ＩＣはＯＣが受信された直後に送信される。したがってＲＴＴはＯＣのレイテンシと、ＩＣのレイテンシの合計となる。例えば、ＩＣＭＰエコー・メカニズムを用いるとき（ＲＦＣ７９２を参照）、ＲＴＴはエコー・メッセージの送信か、エコー・リプライ・メッセージの受信までに経過する時間である。

図４Ａは、ＲＤ（１０８）が用いられる場合のＩＳＤ（１０４）とＭＨ（１１０）の間の通信のレイテンシを示す。
Ｔ１はＭＨ（１１０）からＲＤ（１０８）までの通信のレイテンシである。
Ｔ２はＲＤ（１０８）からＩＳＤ（１０４）までの通信のレイテンシである。
Ｔ３はＩＳＤ（１０４）からＲＤ（１０８）までの通信のレイテンシである。
Ｔ４はＲＤ（１０８）からＭＨ（１１０）までの通信のレイテンシである。

図４Ｂは、ＲＤ（１０８）が用いられない場合のＩＳＤ（１０４）とＭＨ（１１０）の間の通信のレイテンシを示す。
Ｔ５はＭＨ（１１０）からＩＳＤ（１０４）までの通信のレイテンシである。
Ｔ６はＩＳＤ（１０４）からＭＨ（１１０）までの通信のレイテンシである。

本明細書中において、「ＩＳＤ ＲＴＴ」とは、ＭＨ（１１０）とＩＳＤ（１０４）の間の通信のラウンド・トリップ・タイムを示す。

本明細書中において、「ＰＲＤ ＲＴＴ」とは、ＭＨ（１１０）とＰＲＤ（１５０）の間の通信のラウンド・トリップ・タイムを示す。

本明細書中において、「ＲＴＴギャップ（RTT gap）」とは、ＩＳＤ ＲＴＴとＰＲＤ ＲＴＴの間の差を示す。

ＰＲＤ（１５０）がＲＤ（１０８）であるとき（即ち、ＰＲＩＥが中継されるとき）、ＩＳＤ ＲＴＴのラウンド・トリップ・タイムは、ＰＲＤ ＲＴＴよりも長くなければならない。特に、ＰＲＤ ＲＴＴがＴ１＋Ｔ４（ＭＨ（１１０）とＲＤ（１０８）の間のＲＴＴ）に等しく、ＩＳＤ ＲＴＴはＴ１＋Ｔ２＋Ｔ３＋Ｔ４（ＭＨ（１１０）とＲＤ（１０８）の間のＲＴＴとＲＤ（１０８）とＩＳＤ（１０４）の間のＲＴＴの合計）に等しい。ＲＴＴギャップはＰＲＤ（１５０）（即ちＲＤ（１０８））とＩＳＤ（１０４）の間のＲＴＴ（即ちＴ２＋Ｔ３）と等しい。

しかしながら、ＰＲＤ（１５０）がＩＳＤ（１０４）である（即ちＰＲＩＥが中継されない）ならば、ＩＳＤ ＲＴＴとＰＲＤ ＲＴＴはいずれも、Ｔ５＋Ｔ６（ＭＨ（１１０）とＩＳＤ（１０４）の間のＲＴＴ）に等しい。したがってＲＴＴギャップは０に近い値をとる。

例えば、ＩＳＤ ＲＴＴが６４０ミリ秒でＰＲＤ ＲＴＴが１３０ミリ秒である場合、ＩＳＤ ＲＴＴが１３３ミリ秒であり、ＰＲＤ（１５０）がリレー・デバイス（１０８）でＰＲＤ ＲＴＴが１３０ミリ秒である場合より、ＰＲＩＥが中継されている可能性が高い。

ＰＲＤ（１５０）がＩＳＤ（１０４）である場合においても、ＩＳＤ ＲＴＴとＰＲＤ ＲＴＴの間に幾分の差が生じる。これは、それぞれの通信が異なるネットワーク遅延を受けるからである。しかしながら、実際には多くの場合、リレー・デバイスを用いるときのＲＴＴギャップは、リレー・デバイスを用いない場合のＲＴＴギャップよりも顕著に大きい。

ＲＴＴギャップを測定しているとき、ＲＤＳ（１０２）は２つの特徴比較を効果的に実行している。第１の比較では、ＩＳＤ（１０４）からＭＨ（１１０）への通信のレイテンシを、ＰＲＤ（１５０）からＭＨ（１１０）への通信のレイテンシと比較する。第２の比較では、ＭＨ（１１０）からＩＤ（１０４）への通信のレイテンシを、ＭＨ（１１０）からＰＲＤ（１５０）への通信と比較する。どちらのレイテンシも、中継された通信の場合のほうが、中継されない通信の場合よりも大きい。即ちＲＴＴギャップ（２つのレイテンシの差の合計）は中継された通信の場合のほうが、中継されない通信の場合より大きくなるはずである。

一つの実施形態において、ＲＤ（１０８）はＳＯＣＫＳプロキシであり、ＩＳＤ（１０４）はＨＴＴＰクライアントであり、ＭＨ（１１０）はＨＴＴＰサーバである。この場合、ＲＤＳ（１０２）は、ＨＴＴＰ通信（ＰＲＩＥ）のＲＴＴを測定することにより、ＩＳＤ ＲＴＴを取得し、ＴＣＰ通信（ＮＲＩＥ）のＲＴＴを測定することにより、ＰＲＤ ＲＴＴを取得する。

別の実施形態において、ＲＤ（１０８）はＣＯＮＮＥＣＴメソッドを用いるＨＴＴＰプロキシであり、ＩＳＤ（１０４）はＳＭＴＰクライアントであり、ＭＨ（１１０）はＳＭＴＰサーバである。この場合、ＲＤＳ（１０２）は、ＳＭＴＰ通信（ＰＲＩＥ）のＲＴＴを測定することにより、ＩＳＤ ＲＴＴを取得する。ＲＤＳ（１０２）はその後ＩＣＭＰエコー・メッセージを、ＴＣＰ接続（ＮＲＩＥ）のソースＩＰアドレスに送信する。ＴＣＰ接続において、ＳＭＴＰ通信が受信される。ＲＤＳ（１０２）は次に、ＩＣＭＰエコー・リプライ・メッセージを受信する。ＰＲＤ ＲＴＴは２つのＩＣＭＰメッセージ（下記で説明するように、ＩＣＭＰエコー・リプライ・メッセージのオリジナル・ソースはＰＲＤ（１５０）である）の間の時間間隔である。

以下、様々な種類の通信のＲＴＴを測定する方法を説明する。

ＲＴＴギャップはリレー・デバイスの様々な利用法を識別する上でも便利である。性能やセキュリティー上の理由から、正規のユーザは通常、近接するリレー・デバイス（例えば同一のコーポレート・ネットワーク上のデバイス）を使用する。この場合、ＲＴＴギャップは小さくなる。一方で、悪意のユーザはしばしば、遠隔のリレー・デバイス（例えば他の国のデバイス）を使用する。この場合、ＲＴＴギャップは大きくなる。したがってＲＴＴギャップが大きいことは、リレー・デバイスが悪意の目的で使用されていることを指し示す。この方法は、悪意のユーザが遠隔のリレー・デバイスを使用することを回避できない場合に、特に効果的である。例えば、インドネシアの詐欺師が、自分が米国にいるように見せかけたいと思えば、遠隔のリレー・デバイスを使用しなければならない。他にも、全てのリレーのＲＴＴギャップが短くなければならないならば、スパムする者が多数のリレーを使用することは非常に難しくなる。

（ＲＴＴの測定）
正確にＲＴＴを測定するためには、ＯＣの受信と同時に直ちにＩＣが送信されなければならない。このことはいくつかの方法で実行できる。

いくつかのプロトコルを実装することにより、いくつかの通信における即時のレスポンスが可能になる。例えば、ＴＣＰ３方向ハンドシェイク（TCP three-way handshake）において、ＳＹＮコントロール・フラッグを含む関連するセグメント（ＳＹＮセグメント）を受信すると同時に、ＳＹＮ及びＡＣＫコントロール・フラッグを含むセグメント（ＳＹＮ−ＡＣＫセグメント）が、直ちに送信されなければならない。このような場合のＲＴＴは、ＳＹＮセグメント（ＯＣ）の送信とＳＹＮ−ＡＣＫセグメント（ＩＣ）の受信の間の時間間隔である。

他の場合には、プロトコルの実装により即時レスポンスが可能にならないこともある。しかしながらこの場合、通信をハンドルするプリケーションが即時のレスポンスを生み出すことが期待できる。例えば、ＨＴＴＰクライアントは通常、ＨＴＴＰ「３０２」レスポンスを受信すると同時に直ちにＨＴＴＰリクエストを生み出す。他の実施例では、ＨＴＭＬブラウザは通常、ＨＴＭＬページ内に（例えばＨＴＭＬ＜img＞タグを用いて）第１の埋め込みイメージを受信すると同時に、ＨＴＴＰリクエストを生み出す。他の実施例では、ＳＳＬ／ＴＬＳレイヤが、ＴＣＰ ＳＹＮ−ＡＣＫセグメントを受信すると同時に直ちにClientHelloメッセージを送信する。このメッセージはＴＣＰ接続が確立されたことを指し示す。他の実施例では、ＳＭＴＰクライアントは通常、以前の「ＭＡＩＬ」コマンド（ＲＦＣ８２１を参照）に対する「２５０」レスポンスを受信すると同時に直ちに「ＲＣＰＴ」コマンドを送信する。他の実施例では、ＩＲＣクライアントは通常、ＩＲＣサーバから「ＰＩＮＧ」メッセージを受信すると同時に直ちに「ＰＯＮＧ」メッセージを送信する。

他の場合には、即時レスポンスを生み出すために、人的相互作用が用いられる。例えば、ユーザはゲームを提供され、そのゲームにおいてユーザは、スクリーン上に信号が見えると同時に直ちにキーボードのキーを押す。信号はＯＣが受信されたときに表示され、ユーザが応答したときにＩＣが送信される。

短期間にＲＴＴ測定を複数回行うと、互いに異なる結果が出ることがある。これには、ネットワーク輻輳の相違とその他のパラメータの相違が原因となっている。したがって、可能ならば複数回のＲＴＴ測定を行うことが推奨される。更に、ＲＴＴが電気信号又は電磁信号が全ルートを伝達するのに必要な時間を下回ることはないから、通常、複数のＲＴＴ測定値のうち最も低い値を使用すると、正確且つ信頼できる結果が得られる。

悪意のユーザは、ＯＣを受信する前にＩＣを送信することがある。このようにするとＲＤＳ（１０２）がＲＴＴを誤って短く計算する。したがって、ＯＣ内に機密情報（機密情報とは、その機密を事前に知らない人或いはデバイスには、容易に取得できない情報である）を挿入し、この機密情報（或いはこれから派生した情報）がＩＣに含まれることを要求することが推奨される。このようにすると、ＯＣに含まれる機密情報を受信する前にＩＣを送信することを防止できる。例えば上記したＨＴＴＰ「３０２」レスポンスは、ＨＴＴＰクライアントを、機密を含むＵＲＬにリダイレクトする。ＨＴＴＰクライアントはその後、そのＵＲＬに対するＨＴＴＰリクエストを生み出し、それによりこの同一の機密を送信し返す。他の実施例では、ＴＣＰ ＳＹＮ−ＡＣＫセグメント（ＯＣ）が機密のイニシャル・シーケンス・ナンバ（Initial Sequence Number）を含み、ＡＣＫコントロール・フラグを含むＴＣＰセグメント（ＴＣＰ ＡＣＫセグメント、ＩＣ）が肯定応答ナンバ（Acknowledgement Number）を含む。肯定応答ナンバは、イニシャル・シーケンス・ナンバから派生したナンバである。他の実施例では、ＩＣＭＰエコー・メッセージ（ＯＣ）が機密識別子、シーケンス・ナンバ、或いはシーケンス・データを含み、ＩＣＭＰエコー・リプライ・メッセージ（ＩＣ）は同一の機密を含む。

ＲＴＴを計算するとき、ＲＤＳ（１０２）はＭＨ（１１０）から送信される通信もモニタしなければならない（ＭＨ（１１０）により受信される通信に限らない）。これにより、ＯＣのそれぞれが送信される時間を検知する。しかしながら、ＩＳＤ（１０４）へのＯＣとＰＲＤ（１５０）へのＯＣが同時に送信されることが分かっている場合、この要件を無視してもよい。このような場合、ＲＴＴは不明であるが、ＲＴＴギャップは計算可能である。このときのＲＴＴギャップは、それぞれのＩＣが到着する時間の時差に等しい。例えば、ＰＲＩＥがＳＳＬ／ＴＬＳで、ＮＲＩＥがＴＣＰであるならば、ＭＨ（１１０）により送信されるＴＣＰ ＳＹＮ−ＡＣＫセグメントはこのようなＯＣであり、ＲＴＴギャップは対応するＴＣＰ ＡＣＫセグメントの受信と、ＳＳＬ／ＴＬＳClient Hello メッセージの受信との間の時間間隔である。

ＭＨ（１１０）がＯＣを送信しないならば、ＯＣはＲＤＳ（１０２）によっても送信可能であるから、ＲＤＳ（１０２）が自らＯＣを送信する必要がある。例えば、ＲＤＳ（１０２）は、ウェブサイト（ＭＨ（１１０））からのＨＴＴＰ通信及びウェブサイトへのＨＴＴＰ通信をモニタしている。ＰＲＩＥのＲＴＴを測定するためには、上述のように、ＲＤＳ（１０２）はＭＨ（１１０）により受信されるＨＴＴＰリクエストのいくつかに対して、ＨＴＴＰ「３０２」レスポンスを提供する。この例では、ＲＤＳ（１０２）がＭＨ（１１０）にインストールされたソフトウェア・モジュールであって、ＭＨ（１１０）に送信されたＨＴＴＰ通信に応答可能でなければならない。

レイテンシ或いはＲＴＴの測定を行う実施形態において、ＩＳＤ ＲＴＴとＰＲＤ ＲＴＴの間に有意な差異が存することをチェックすることが推奨される。これらＲＴＴの間に有意な差異が存するといえるのは、これらＲＴＴの間の差異が同一のデバイスを用いた通信に対するＲＴＴ測定を行うときに滅多に起こることがない差異であるときである。この文書を作成している時点では、適度に安定したインターネット環境における２つのデバイスの間のＲＴＴの差は、数秒のタイム・フレーム内では５０ミリ秒以下である。一方、中継される通信のＲＴＴギャップは通常、１００ミリ秒を超える。したがって、いくつかの実施形態において、「有意な差異が存する」とは、「６０ミリ秒以上」の差異が存することを示す。別のいくつかの実施形態において、「有意な差異が存する」とは、「８０ミリ秒以上」の差異が存することを示す。別のいくつかの実施形態において、「有意な差異が存する」とは、例えば「１００ミリ秒以上」の差異が存することを示す。

いくつかの実施形態において、デバイスへのＲＴＴを直接測定することはできないが、そのデバイスについて既知の他の情報に基づいてＲＴＴを見積ることができる。このような情報として、地理的位置、ＩＰアドレスのリバースＤＮＳレコード（即ちホスト・ネーム・トランスレーションに対するホスト・アドレス）、及び／又はそのＩＰアドレスのWHOISレコード（WHOISサービスに関する情報については、http://www.arin.netのAmerica Registry for internet Numbersウェブサイトを参照。）が挙げられる。例えば、ＭＨ（１１０）が米国ニューヨーク州ニューヨーク市に位置し、IP geo-location サービスがＰＲＤ（１５０）が米国カリフォルニア州ロサンゼルスに位置することを指し示しており、且つテキスト「dsl」がＰＲＤ（１５０）のＩＰアドレスのリバースＤＮＳレコード内に存在して、このテキスト「dsl」がデジタル・サブスクライバ・ライン（Digital Subscriber Line ＤＳＬ）（ＤＳＬに関する情報については、http://www.dslforum.org）DSL Forumウェブサイトを参照。）であることを示すならば、ＲＤＳ（１０２）はＭＨ（１１０）とＰＲＤ（１５０）の間のＲＴＴが６５乃至８５ミリ秒の範囲内であると見積もることができる。これは、ニューヨーク市とロサンゼルスの間のインターネット上のＲＴＴが通常５５ミリ秒であることが分かっており、ＤＳＬが通常ＲＴＴに１０乃至３０ミリ秒付加することが分かっているからである。

（デバイスのコンフィギュレーション状態の利用）
本発明の別の実施形態において、ＩＳＤ特徴とＰＲＤ特徴のそれぞれは、ＩＳＤ（１０４）とＰＲＤ（１５０）のコンフィギュレーションの状態である。本明細書中において、「コンフィギュレーションの状態」とは、デバイスのハードウェアとソフトウェア、及びこれらハードウェア及びソフトウェアがカスタマイズされる方法を示す。

ＩＳＤ特徴とＰＲＤ特徴が、単一のデバイスに関連するものでないコンフィギュレーションの状態であるならば、ＰＲＤ（１５０）とＩＳＤ（１０４）が互いに異なるデバイスである（即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）であり、ＰＲＩＥは中継される）可能性が比較的高い。

同様に、ＩＳＤ特徴とＰＲＤ特徴が単一のデバイスに関連するコンフィギュレーションの状態であるならば、ＰＲＤ（１５０）とＩＳＤ（１０４）は同一のデバイスである（即ち、ＰＲＩＥは中継されなかった）可能性が比較的高い。

デバイスのコンフィギュレーション状態を通信から検知する方法としていくつかの方法が知られている。１つの方法は、通信内においてデバイスにより提供された明示的コンフィギュレーション情報を使用する方法である。例えば、ＨＴＴＰクライアントは通常、ＨＴＴＰリクエストのそれぞれに、「ユーザ・エージェント（User-Agent）」ヘッダを備える。このヘッダは、オペレーティング・システムの種別やバージョン、ＨＴＴＰクライアントの種別やバージョン、及びデバイスにインストールされた追加的ソフトウェアに関する情報を提供する。電子メールアプリケーションはＲＦＣ８２２「Ｘメイラ」ヘッダ内に同様の情報をもたらし、電子メールサーバはこのような情報をＲＦＣ８２２「レシーブド」ヘッダ内にもたらし、ＨＴＴＰサーバは通常、ＨＴＴＰレスポンス内に「サーバ」ヘッダを備える。このヘッダは、ＨＴＴＰサーバの種別及びバージョンに関する情報をもたらす。

別の方法は、デバイスのコンフィギュレーション状態を、デバイスが様々な通信プロトコルを実装する方法から推測する方法である。一般に普及したネットワーク・アドミニストレーション・ツール「Nmap」として、この方法を実施する多数の実施方法が利用できる。Ｎmapについては、「Remote OS detection via TCP/IP Stack Fingerprinting」（Nmapのデベロッパによる記事。http://www.insecure.org/nmap/nmap-fingerprinting-article.htmlにおいて利用可能）に詳述されている。例えば、この記事は、ＴＣＰ実装により選択されたイニシャル・ウィンドウを検査することを提案している。これは互いに異なるオペレーティング・システムは異なる数字を選ぶからである。この記事は調査されたデバイスが通信に応答していることを仮定しているが、この方法はデバイスにより開始される通信にも適用可能である（具体的な内容は異なることもある）。

この実施形態の一実施例として、ＲＤ（１０８）がＳＯＣＫＳプロキシであるならば、ＲＤＳ（１０２）はＨＴＴＰリクエスト（ＰＲＩＥ）をモニタし、このＨＴＴＰリクエストは、「ユーザ・エージェント：Mozilla/4.0（適合性。ＭＳＩＥ６．０、WindowsＮＴ５．０）」とのヘッダを備える。このヘッダはオペレーティング・システムがMicrosoft Windows（登録商標） 2000であることを指し示す。ＨＴＴＰリクエストは、イニシャル・ウィンドウ５８４０を備えていたＴＣＰ接続（ＮＲＩＥ）を介して送信される。このことは、他のオペレーティング・システム（特にRed Hat Enterprise Linux）に典型的にみられる。１つのデバイスが同時に２つのオペレーティング・システムを実行することはできないから、ＲＤＳ（１０２）はＩＳＤ（１０４）とＰＲＤ（１５０）が互いに異なるデバイスである（即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）であり、ＨＴＴＰリクエストはリレーされていた）ことを決定する。この例において、ＩＳＤ特徴は、ＩＳＤ（１０４）がMicrosoft Windows（登録商標） 2000オペレーティング・システムであるという情報であり、ＰＲＤ特徴は、ＰＲＤ（１５０）がRed Hat Enterprise Linuxオペレーティング・システムを実行するという情報である。

この実施形態の別の例において、ＲＤ（１０８）はＣＯＮＮＥＣＴメソッドを用いたＨＴＴＰプロキシであり、ＲＤＳ（１０２）は「Mozilla/5.0（Macintosh; U; PPC Mac OS X; en）AppleWebKit/124（GeckoのようなKHTML）Safari/125」とのヘッダを備えるＨＴＴＰリクエスト（ＰＲＩＥ）をモニタする。このヘッダは、オペレーティング・システムがApple Mac OS Xであることを指し示す。ＨＴＴＰリクエストはＴＣＰ接続（ＮＲＩＥ）を介して送信される。ＲＤＳ（１０２）はＴＣＰ接続のソースＩＰアドレスのポート（８０）と接続し、ＨＴＴＰリクエストを送信する。ＲＤＳ（１０２）はその後、「Sever: Microsoft-IIS/5.0」とのヘッダを含むＨＴＴＰレスポンスを受信する（上述のごとく、このＨＴＴＰレスポンスのオリジナル・ソースはＰＲＤ（１５０）である）。Microsoft IISサーバは、Apple Mac OS Xオペレーティング・システムを実行しないことが分かっているから、ＲＤＳ（１０２）はＩＳＤ（１０４）とＰＲＤ（１５０）が互いに異なるデバイスである（即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）であり、ＩＳＤ（１０４）からのＨＴＴＰリクエストは中継されていなかった）ことを決定する。この例において、ＩＳＤ特徴はＩＳＤ（１０４）がApple Mac OS Xオペレーティング・システムを実行するという情報であり、ＰＲＤ特徴はＰＲＤ（１５０）がMicrosoft IISサーバを実行するという情報である。

いくつかの場合、情報エレメントのオリジナル・ソースにＯＣを送信することが必要である。ＯＣはオリジナル・ソースにＩＣを返信させる。このＩＣはオリジナル・ソースのコンフィギュレーションの決定に用いられる。上記したＨＴＴＰ「サーバ」ヘッダが用いられる例において、ＲＤＳ（１０２）からＰＲＤ（１５０）へ送信されるＨＴＴＰリクエストはＯＣであり、ＨＴＴＰレスポンスはＩＣである。ＯＣが情報エレメントのオリジナル・ソースへ送信されることされることを確認する方法と、情報エレメントのオリジナル・ソースによりＩＣが受信されることを確認する方法は、以下で説明する。

（位置、サブネットワーク、或いはアドミニストレータに関する情報の利用）
本発明の別の実施形態において、ＩＳＤ特徴とＰＲＤ特徴はそれぞれ、ＩＳＤ（１０４）とＰＲＤ（１５０）の位置、サブネットワーク、及び／又はアドミニストレータである。本明細書中において、「位置（location）」とは、デバイスの地理的位置を示す。「サブネットワーク（sub−network）」とは、ネットワーク・トポロジにおいてこのデバイスに近接するデバイスのグループを示す。「アドミニストレータ（administrator）」とはこのデバイスをネットワーク（例えばインターネット）に接続するオーガニゼーションを示す。デバイスの位置の例として、「米国ニューヨーク州ニューヨーク市」或いは「北緯３２度５分、東経３４度４６分」が挙げられる。デバイスのサブネットワークの例として、「ＩＰアドレスが1.2.3.4であるデバイスと同一のローカル・エリア・ネットワーク・セグメント上にある全てのデバイス」が挙げられる。デバイスのアドミニストレータの例として、「米国ジョージア州アトランタのEarthloink, Inc.」が挙げられる。Earthlink, Inc.は、インターネット・サービス・プロバイダで、ユーザをインターネットに有料で接続する。アドミニストレータの別の例として、米国ニュージャージー州プリンストンのGeneral Electric Companyが挙げられる。この企業では、業務上必要なときに従業員の一部をインターネットに接続する。

単一のデバイスが同時に２つの互いに異なる位置、サブネットワーク、或いはアドミニストレータを有する可能性は低い。したがってＩＳＤ（１０４）はＰＲＤ（１５０）と異なる位置及び／又は異なるサブネットワーク上にあり、及び／又は異なるアドミニストレータを備えることがあかる。よってＩＳＤ（１０４）とＰＲＤ（１５０）は互いに異なるデバイスである（ＰＲＩＥが中継されていた）可能性が比較的高い。同様にＩＳＤ（１０４）とＰＲＤ（１５０）が同一の位置及び／又は同一のサブネットワーク上にあり、及び／又は同一のアドミニストレータを備えるならば、ＰＲＤ（１５０）とＩＳＤ（１０４）は同一のデバイスである（即ちＰＲＩＥは中継されていなかった）可能性が比較的高い。

一実施例において、ＲＤ（１０８）はＳＯＣＫＳプロキシであり、ＩＳＤ（１０４）はＳＭＴＰクライアントであり、ＭＨ（１１０）はＳＭＴＰサーバである。この場合、ＲＤＳ（１０２）は、ＴＣＰセッション（ＮＲＩＥ）のソースＩＰアドレスと、ＩＰgeo-locationサービスを用いて、ＰＲＤ（１５０）の位置を見積る。ＲＤＳ（１０２）はその後、ＳＭＴＰ通信（ＰＲＩＥ）内でレポートされるＲＦＣ８２２「日付（Date）」ヘッダを用いて、ＩＳＤ（１０４）の位置を見積る。「日付」ヘッダは、時間（「wall clock」）とＩＳＤ（１０４）の時間帯状態を指し示す。したがって「日付」ヘッダは、ＲＤＳ（１０２）の位置を指し示す（何故ならば、デバイスは通常、現地時間と現地の時間帯に合わされているからである）。２つの位置が一致しない場合（例えばgeo-locationサービスが、ＰＲＤ（１０２）がニューヨーク市に位置することを指し示し、ＩＳＤ（１０４）の時間帯がGMT＋7であるとき）、ＲＤＳ（１０２）は、ＰＲＤ（１５０）とＩＳＤ（１５０）が互いに異なるデバイスである（即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）であり、ＳＭＴＰ通信が中継されていた）と決定する。

ＳＭＴＰ通信の「日付」ヘッダを利用する方法以外に、ＰＲＤ（１５０）の位置を見積る方法として、以下の方法が挙げられるが、これらには限定されない。（ａ）IPアドレスのＷＨＯＩＳレコードをチェックする方法。ＷＨＯＩＳレコード内に与えられたアドレスはＰＲＤ（１５０）の位置に比較的近い可能性がある（ｂ）IPアドレスのリバースＤＮＳレコードをチェックする方法。例えば、レコードが「.fr」で終わるならばＰＲＤ（１５０）はフランスにある可能性が高い。

ＳＭＴＰ通信の「日付」ヘッダを利用する方法以外に、ＩＳＤ（１０４）の位置を見積る別の方法として、以下の方法が挙げられるが、これらには限定されない。（ａ）（ＰＲＩＥがＳＭＴＰである場合）ＳＭＴＰ内でレポートされた最新のＲＦＣ「レシーブド」ヘッダをチェックする。このヘッダは、ＩＳＤ（１０４）により使用されたＳＭＴＰサーバの時間帯状態を含み、この時間帯はＩＳＤ（１０４）自体の時間帯としばしば同一である。（ｂ）（ＰＲＩＥがＨＴＴＰである場合）「Accept-Language」ＨＴＴＰヘッダをチェックする。このヘッダはＩＳＤ（１０４）によりサポートされる言語を指し示す（例えば、「Accept-Language: ru」とのヘッダは、ＩＳＤ（１０４）がロシア語のコンテンツをサポートすることを指し示す。したがって、ＩＳＤ（１０４）がロシアにある可能性が比較的高い。（ｃ）ＩＳＤ（１０４）におけるイベントによりトリガされた別の通信（以下ＩＳＤトリガ通信という）のソースの位置をチェックする。この方法については以下で詳しく説明するが、この方法には、上記したＰＲＤ（１５０）の位置を見積もる方法を適宜用いる。

他の実施形態において、ＲＤ（１０８）はＴＣＰを中継しない（即ち、ＴＣＰがＮＲＩＥ）種類のリレー・デバイスに属し、ＲＤ（１０２）はＴＣＰセッションのソースＩＰアドレスを用いてＰＲＤ（１５０）のサブネットワークを見積る。このことは、IPアドレスに関連付けられたWHOISレコード、リバースDNSレコード、或いはルーティング・データベース・レコードを検索することにより行われる（ルーティング・データベースに関する情報については、http://www.radb.netのRADbウェブサイトを参照）。また、同一のサブネットワーク内のデバイスは通常、同一のルータを介してインターネット（１００）に接続するから、このことは「Time Exceeded」ＩＣＭＰメッセージを用いて、ＰＲＤ（１５０）に近接するルータを探し出すことにより行われてもよい。このメッセージは、Unix（登録商標） utility traceroute（或いは同様のMicrosoft Windows（登録商標） utility tracert）より行われるように、ＩＰパケットに応じて小さなTime-to-Live値とともに送信される。ＲＤＳ（１０２）はその後、ＩＳＤ（１０４）のサブネットワークを見積る。以下で詳しく説明するように、このことは、ＩＳＤトリガ通信のソースのサブネットワークをチェックすることにより行われる。このとき、ＰＲＤ（１５０）のサブネットワークを見積るために用られる上記した方法を用いる。２つのサブネットワークが一致しない（例えば、デバイスのWHOISレコードにおけるサブネットワークの名前が互いに異なるか、或いはデバイスが共通の近接するルータを持たない）ならば、ＲＤＳ（１０２）は、ＰＲＤ（１５０）とＩＳＤ（１０４）が互いに異なるデバイスである（即ち、ＰＲＤ（１５０）はリレー・デバイス（１０８）であり、ＰＲＩＥは中継されていた）と決定する。

別の実施形態においては、ＲＤ（１０８）はＴＣＰをリレーしない（即ち、ＴＣＰはＮＲＩＥ）種類のリレー・デバイスであり、ＲＤＳ（１０２）はＴＣＰセッションのソースＩＰアドレスを用いてＰＲＤ（１５０）のアドミニストレータを見積る。アドミニストレータを見積る方法の例として以下の方法が挙げられるが、これらには限定されない。（ａ）このＩＰアドレスに関連するWHOISレコードを検索する。（このレコード内に与えられるオーガニゼーション・ネームがアドミニストレータである可能性が高い）（ｂ）このＩＰアドレスに関連するリバースＤＮＳレコードを検索する。（例えば、レコードが「cox.net」で終わるならば、アドミニストレータは「米国ジョージア州アトランタのCox Communications」である可能性が高い。（ｃ）このＩＰアドレスに関連するリバースＤＮＳレコード内の第２レベル・ドメインと関連したWHOISレコードを検索する（ｄ）このＩＰアドレスと関連するルーティング・データベース・レコードを検索する。
ＲＤＳ（１０２）はその後、ＩＳＤ（１０４）のアドミニストレータを見積る。ＩＳＤ（１０４）のアドミニストレータを見積る方法の例として以下の方法が挙げられるが、これらには限定されない。（ａ）（ＰＲＩＥがＨＴＴＰである場合）ＨＴＴＰヘッダ「ユーザ・エージェント」をチェックする。このヘッダはアドミニストレータに関する情報を含むことがある。例えば、「AOL 9.0」とのテキストを含む「ユーザ・エージェント」ヘッダは、ＩＳＤ（１０４）にインストールされたＨＴＭＬブラウザが米国バージニア州ダレスのAmerica Online, Inc.（ＡＯＬ）により提供されたものであることを指し示す。多くのインターネット・ユーザは、それを介してインターネットに接続しているオーガニゼーションと同一のオーガニゼーションから、ＨＴＭＬブラウザを受け取る。このことにより、ＩＳＤ（１０４）がＡＯＬを介してインターネットに接続している（即ち、ＡＯＬがアドミニストレータである）可能性が高まる。別の例として、「Cox High Speed Internet Customer」とのテキストは、ブラウザが米国ジョージア州アトランタのCox Communications, Incにより提供されたことを示す。（ｂ）（ＰＲＩＥがＳＭＴＰである場合）ＲＦＣ８２２「オーガニゼーション」ヘッダをチェックする。このヘッダは、アドミニストレータに関する情報を含むことがある。（ｃ）ＩＳＤトリガ通信のソースＩＰアドレスのアドミニストレータをチェックする。以下で詳しく説明するように、このとき、上記したＰＲＤ（１５０）のアドミニストレータを見積るための方法を適宜用いる。

（ＩＳＤトリガ通信）
ＩＳＤ（１０４）に関する情報はＩＳＤ（１０４）に対して通信を送信するようにトリガすることにより発見される。このような通信を「ＩＳＤトリガ通信（ISD Triggered Communication）」という。

ＩＳＤ（１０４）のＩＰアドレスを明らかにするＩＳＤトリガ通信の例は、国際公開第ＷＯ０２／０８８５３号公報に開示される。この公報の開示内容は参照により本明細書中に組み込まれる。ＩＳＤ（１０４）のＩＰアドレスを受信した後、ＲＤＳ（１０２）は上記した方法を用いて、ＩＳＤ（１０４）の位置、サブネットワーク、及びアドミニストレータを探し出す。ＲＤＳ（１０２）はその後、ＩＳＤ（１０４）の位置、サブネットワーク、及びアドミニストレータと、ＰＲＤ（１５０）の位置、サブネットワーク、及びアドミニストレータを比較して、ＩＳＤ（１０４）とＰＲＤ（１５０）が互いに異なるデバイスであるか否かを決定する。若しくは、ＲＤＳ（１０２）は、ＩＳＤ（１０４）のＩＰアドレスとＰＲＤ（１５０）のＩＰアドレスを直接比較する。ＩＳＤ（１０４）のＩＰアドレスとＰＲＤ（１５０）のＩＰアドレスが異なるならば、ＩＳＤ（１０４）がＰＲＤ（１５０）と異なるデバイスである（即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）であり、ＰＲＩＥは中継されていた）可能性が比較的高い。

他のトリガ通信の例として、ＤＮＳリクエストが挙げられる。いくつかの場合、ＩＳＤ（１０４）は、ＰＲＩＥと関連したＤＮＳリクエストを送信して、ホストネームをＩＰアドレスに変換する。ＩＳＤ（１０４）はＤＮＳリクエストを、ＤＮＳサーバに送信する。このサーバは、ＩＳＤ（１０４）がこのサーバを使用するように定められているサーバである。ＩＳＤ（１０４）のＤＮＳサーバはその後、ＤＮＳリクエストを上記の所定のホストネームのための信頼のあるＤＮＳサーバに送信する。ＲＤＳ（１０２）がモニタするＤＮＳリクエストは、ＩＳＤ（１０４）がこのサーバを使用するように定められているＤＮＳサーバから受信されるが、ＩＳＤ（１０４）はＤＮＳリクエストに含まれる情報エレメントのうち少なくとも１つの情報エレメントのオリジナル・ソースである。米国特許出願第ＵＳ２００２０１６８３１号は、参照により本明細書中に組み込まれるが、この出願は、デバイスにＤＮＳリクエストを生み出させる方法と、そのＤＮＳリクエストを、該ＤＮＳリクエストを生み出したデバイスの特徴と関連付ける方法を開示している。ＤＮＳリクエストを、関連するＰＲＩＥと関連付ける１つの方法は、信頼のあるＤＮＳサーバにホストネームの変換のためのリクエストごとに異なるＩＰアドレスで応答させるとともに、どのＤＮＳリクエストがどのＩＰアドレスを応答として受け取ったかについてのレコードを保持させる方法である。ＰＲＩＥがＩＰアドレスのうち１つのアドレスで受信されると、関連するＤＮＳリクエストがレコードから検索される。

ＤＮＳリクエストをＩＳＤ（１０４）のＤＮＳサーバから受信した後、ＲＤＳ（１０２）は上記の方法を用いてＲＤＳ（１０２）の位置、サブネットワーク、アドミニストレータを探し出す。性能と経済上の理由から、インターネットに接続される多くのデバイスは、同様の位置にあるとともに同一のサブネットワーク上にあり、或いは同一のアドミニストレータにより運営されるＤＮＳサーバを使用するように設定される。したがって、ＲＤＳ（１０２）はＰＲＤ（１５０）の位置、サブネットワーク、或いはアドミニストレータと、ＩＳＤ（１０４）のＤＮＳサーバの位置、サブネットワーク、或いはアドミニストレータをそれぞれ比較できる。これらが一致しないならば、ＰＲＤ（１５０）はＩＳＤ（１０４）と異なるデバイスである（即ち、ＰＲＩＥは中継されている）可能性が高い。

（最大通信レイトの使用）
本発明の別の実施形態において、ＰＲＤ（１５０）とＩＳＤ（１０４）の最大通信レイト（maximum communication rate ＭＣＲ）を用いて、ＰＲＤ（１５０）とＩＳＤ（１０４）が同一のデバイスであるか否かを決定する。ＭＣＲとは、一定期間内にデバイスが受信可能な最大情報量（受入方向のＭＣＲ）或いは送信可能な最大情報量（送出方向のＭＣＲ）のことをいう。「１秒当たりのビット数（Bits per Second（bps））」がＭＣＲを測定する一般的な単位である。例えば、いくつかのＤＳＬ回線では、受入方向のＭＣＲは１５０万ｂｐｓ（Ｍｂｐｓ）であり、送出方向のＭＣＲは９万６千ｂｐｓ（ｋｂｐｓ）である。

ＰＲＤ（１５０）のＭＣＲがＩＳＤ（１０４）のＭＣＲと異なるならば、ＩＳＤ（１０４）がＰＲＤ（１５０）と異なるデバイスである（即ちＰＲＩＥが中継されている）可能性が高い。

この実施形態の一つの例において、ＲＤ（１０８）はインターネット（１００）に、受入方向のＭＣＲが１．５Ｍｂｐｓ、送出方向のＭＣＲが９６ｋｂｐｓのＤＳＬ回線上で接続する。ＭＨ（１１０）からＩＳＤ（１０４）に中継される通信は、ＲＤ（１０８）の受入方向のインターフェースを通った後、ＲＤ（１０８）の送出方向のインターフェースを通って伝送される。よって、ＩＳＤ（１０４）の受入方向のＭＣＲが、ＲＤ（１０８）の送出方向のＭＣＲ（９６ｋｂｐｓ）を超えることはない。したがって、ＰＲＤ（１５０）の受入方向のＭＣＲは１．５Ｍｂｐｓであるのに対して、ＩＳＤ（１０４）の受入方向のＭＣＲは９６ｋｂｐｓ以下である。

この実施形態の別の例において、ＲＤ（１０８）はインターネット（１００）に、受入方向と送出方向の両方向において２０Ｍｂｐｓで接続する。ＩＳＤ（１０４）はインターネット（１００）に、受入方向のＭＣＲが１．５Ｍｂｐｓ、送出方向のＭＣＲが９６ｋｂｐｓのＤＳＬ回線を介して接続する。したがって、ＰＲＤ（１５０）の受入方向のＭＣＲは２０Ｍｂｐｓであるのに対してＩＳＤ（１０４）の受入方向のＭＣＲは１．５Ｍｂｐｓであり、ＰＲＤ（１５０）の送出方向のＭＣＲは２０Ｍｂｐｓであるのに対してＩＳＤ（１０４）の送出方向のＭＣＲは９６ｋｂｐｓである。

（ＭＣＲの検知）
本発明のいくつかの実施形態によると、ＩＳＤ（１０４）のＭＣＲがＰＲＤ（１５０）のＭＣＲと異なるか否かについてのチェックは、それぞれのＭＣＲを検知してそれらを比較することにより行われる。ＭＣＲを検知する一つの方法は、自動的に最大可能な通信レイトに調節するプロトコル（例えばＴＣＰ）を用いてデバイスへ情報を送信する或いはデバイスから情報を受信し、このときの通信レイトを観察することである。ＭＣＲを調節するためのＴＣＰに用いられるメカニズムの一部については、「JACOBSON, V. Congestion avoidance and control. In Proceedings of SIGCOMM '88 (Stanford, CA, 1988年8月), ACM」とこの記事の参考文献に説明されている。

デバイスの受入方向の通信レイトを観察する別の方法は、このデバイスから受信される受信確認をモニタする段階を備える。例えば、デバイスはＴＣＰ接続上で情報を受信し、このデバイスが成功裡に受信した情報の量を適宜送信する。3,000,000バイトを受信したとの確認を受取り、その２０秒後に3,250,000バイトを受信したとの確認を受取ったとすると、このデバイスが12,500バイト／秒（100,000ビット／秒と等しい）で情報を受取ることを示す。別の例において、上記のごとく、ＨＴＭＬブラウザは、ＨＴＭＬページ内に（例えばＨＴＭＬ＜img＞tagを用いて）第１の埋め込みイメージを受取ると同時に直ちに通常ＨＴＴＰリクエストを生み出す。埋め込みイメージのタグが1,000,000バイトのオフセットに位置するＨＴＭＬページを送信開始してから４０秒後にＨＴＴＰリクエストを受取ると、デバイスは25,000バイト／秒の速度で情報を受信している。25,000バイト／秒は、200,000ビット／秒に等しく、このデバイスの受入方向のＭＣＲは２００ｋｂｐｓである。この測定ではＨＴＭＬページの頭の送信と、ＨＴＴＰリクエストの受信を比較するから、少なくとも１ラウンド・トリップ・タイムが測定値に加わる。よって測定が不正確となる可能性がある。ラウンド・トリップ・タイムを測定して、計測された時間からこのラウンド・トリップ・タイムを減ずることにより、更に正確な結果が得られる。

ＲＤ（１０８）は通常、ＭＨ（１１０）とＩＳＤ（１０４）の間の中継された通信をバッファリングする。バッファとは一時的なストレージであり、ＲＤ（１０８）は、受信する通信をこのバッファに書き込み、送信する通信をこのバッファから読み取る。バッファに空き容量があるとき、ＲＤ（１０８）は、その受入方向のＭＣＲレイトで通信を受取ることができる。バッファが一杯であるとき、ＲＤ（１０８）はバッファを空にできる速度（即ちＲＤ（１０８）がバッファから通信を送信できる速度）で、通信を受取ることができる。したがって、バッファに空き容量があるときには、ＭＨ（１１０）からＲＤ（１０８）への通信レイトの測定値はＲＤ（１０８）の受入方向のＭＣＲを示し、バッファが一杯であるときには、ＭＨ（１１０）からＲＤ（１０８）への通信レイトの測定値はＩＳＤ（１０４）の受入方向のＭＣＲを示す。ＩＳＤ（１０４）の受入方向のＭＣＲがＲＤ（１０８）の受入方向のＭＣＲより小さいと、バッファが一杯になる。例えば、ＲＤ（１０８）が100,000バイトのサイズのバッファを備え、ＲＤ（１０８）の受入方向ＭＣＲが１．５Ｍｂｐｓ、ＩＳＤ（１０４）の受入方向ＭＣＲが９６ｋｂｐｓであるならば、バッファは１．４０４Ｍｂｐｓの速度で埋められていく。この速度では、約０．５７秒でバッファが一杯になる。この例では、最初の０．５７秒間は通信速度の測定値は１．５Ｍｂｐｓである。この速度は、ＲＤ（１０８）の受入方向ＭＣＲを示す。最初の０．５７秒を経過後には、通信速度の測定値は９６ｋｂｐｓとなる。この速度はＩＳＤ（１０４）の受入方向ＭＣＲを示す。

したがって、ＰＲＤ（１５０）がＲＤ（１０８）である場合、バッファが一杯になる前には、ＰＲＤ（１５０）の受入方向ＭＣＲがＰＲＤ（１５０）の受入方向の通信速度により示され、バッファが一杯になった後には、ＩＳＤ（１０４）の受入方向ＭＣＲがＰＲＤ（１５０）の受入方向の通信速度により示される。

ＰＲＤ（１５０）がＩＳＤ（１０４）であるとき、このバッファは存在しないから、ＰＲＤ（１５０）の受入方向の通信速度は変化せず、ＩＳＤ（１０４）の受入方向ＭＣＲに等しい速度を維持する。

したがって、ＲＤ（１０８）のバッファが一杯になるまでは、ＰＲＤ（１５０）の受入方向ＭＣＲはＰＲＤ（１５０）の受入方向の通信速度と等しい。ＲＤ（１０８）のバッファが一杯になった後は、ＩＳＤ（１０４）の受入方向ＭＣＲはＰＲＤ（１５０）の受入方向の通信速度と等しい。

したがって、ＲＤＳ（１０２）は、ＲＤ（１０８）のバッファが一杯になる前後のＰＲＤ（１５０）の受入方向の通信速度を比較することにより、ＰＲＤ（１５０）がリレー・デバイス（１０８）であるか否かを決定できる。

多くの場合、ＲＤ（１０８）からＭＨ（１１０）までの通信速度は、ＩＤ（１０４）の送出方向ＭＣＲを超えることはない。これは、ＲＤ（１０８）はＩＳＤ（１０４）から受信した情報のみをＭＨ（１１０）に送信するのであって、ＲＤ（１０８）が独自に有意な量の情報を生み出すことが通常ないからである。しかしながら上述のごとく、ＲＤ（１０８）はＳＤ（１０４）とＭＨ（１１０）の間の通信をバッファリングするから、ＲＤ（１０８）の送出方向ＭＣＲを以下のように計測することが可能である。いくつかのプロトコルは「フロー制御（flow control）」メカニズムを含む。このメカニズムは、情報を受信するデバイスが、情報を送信するデバイスに、いつ新たな情報の送信を停止し、いつ送信を再開するかについて信号を送ることを可能にする。例えば、ＴＣＰにおいて、受信側デバイスが「ウィンドウ」値ゼロのＡＣＫセグメントを送信すると、受信側デバイスは通常、新たな情報の送信を停止する。送信側デバイスが、正の「ウィンドウ」値を有するＡＣＫセグメントを受取るまで、新たな情報の送信は停止される。「フロー制御」メカニズムが、ＭＨ（１１０）或いはＲＤＳ（１０２）により、ＲＤ（１０８）に対して信号を送り、新たな情報の送信を停止させるために用いられてもよい。このようにすると、ＲＤ（１０８）がＩＳＤ（１０４）から情報を受信し続ける一方で、ＭＨ（１１０）に対して情報を送信することがないから、ＲＤ（１０８）のバッファは情報により埋められることになる。その後、ＭＨ（１１０）或いはＲＤＳ（１０２）は「フロー制御」メカニズムを用いてＲＤ（１０８）に信号を送り、新たな情報の送信を再開させる。このときＲＤ（１０８）は、そのローカル・バッファが空になるまでこのバッファから情報を送信するから、通信速度の測定値はＲＤ（１０８）の送出方向ＭＣＲを示す。

本発明のいくつかの実施形態によると、ＩＳＤ（１０４）のＭＣＲがＰＲＤ（１５０）のＭＣＲと異なるか否かのチェックは、ＰＲＤ（１５０）内のバッファが一杯か空かいずれの状態であるかを示す指標を検知することにより行われる。例えば上述のごとく、ＩＳＤ（１０４）の受入方向ＭＣＲがＰＲＤ（１５０）の受入方向ＭＣＲより小さいと、ＲＤ（１０８）内のバッファは一杯になる。他の例では、上述のごとく、ＩＳＤ（１０４）の送出方向ＭＣＲがＰＲＤ（１５０）の送出方向ＭＣＲより小さいと、ＲＤ（１０８）のバッファは空となる。いくつかのプロトコルは、デバイスがそのデバイスのバッファの容量、或いはその派生値を、他のデバイスに対して知らせることを可能にする。この情報はデバイスのバッファが一杯になる途中或いは空になる途中のいずれであるかを推定するために用いられる。例えば、ＴＣＰにおいて、デバイスは、送信するＡＣＫセグメント全ての「ウィンドウ」ヘッダ内において、受取る予定の情報量を通知する。「ウィンドウ」ヘッダの値の変化は、デバイスのバッファの容量の変化を反映している。「ウィンドウ」値の増加は、バッファが空にされる途中であることを示し、「ウィンドウ」値の減少はバッファが一杯にされる途中であることを示す。

したがって、「ウィンドウ」値の減少は、ＰＲＤ（１５０）の受入方向ＭＣＲがＩＳＤ（１０４）の受入方向ＭＣＲより大きいこと、つまりＰＲＤ（１５０）とＩＳＤ（１０４）が互いに異なるデバイスである（即ち、ＰＲＤ（１５０）がリレー・デバイス（１０８）である）ことを直接的に示す。

ＭＣＲを検知する別の方法は、含まれる情報量のみが異なる２つの通信のレイテンシを測定して、２つのレイテンシ間の差からＭＣＲを計算する方法である。上述のごとく、通信が通信回線を介して伝達するために必要な時間は、その通信に含まれる情報量に比例する。したがって、ＭＣＲはこれら２つの通信の情報量の間の差を、これら２つの通信のレイテンシの差で除算した値に等しい。

この方法を、レイテンシではなくＲＴＴの測定とともに用いてもよい。例えば、ショート・エコー・メッセージ（例えば６４バイト）を備えるＩＣＭＰエコー・メカニズムのＲＴＴと、ロング・エコー・メッセージ（例えば１５００バイト）のＲＴＴを用いてデバイスのＭＣＲを検知する。ＩＣＭＰエコーの例におけるように、受入方向及び送出方向の通信が同じ量の情報を含むならば、ＲＴＴメソッドはデバイスの受入方向ＭＣＲと送出方向のＭＣＲの結合した測定値を提供する。この限界を克服する１つの方法は、ただ１つの受入方向及び送出方向の通信が大量の情報を含むプロトコルを用いてＲＴＴを測定することである。これにより、他の通信のレイテンシがＲＴＴに占める割合が減少し、第１の通信のレイテンシにより近い測定値が得られる。例えば、閉じられたポートに送信されたＴＣＰ ＳＹＮセグメントは通常、ＲＳＴフラッグを含むセグメント（ＲＳＴセグメント）をトリガする。一方で、ＳＹＮ セグメントのサイズはこのセグメントのセンダにより選択される。ＲＳＴセグメントのサイズは一般的に小さい（例えば４０バイト）。

ＭＣＲを検知する別の方法は、ＭＣＲをそのデバイスについて既知の他の情報から推定する方法である。例えば、デバイスのＩＰアドレスのリバースＤＮＳ内にテキスト「dsl」が発見されれば、そのデバイスはＤＳＬ回線である可能性が高い。ＤＳＬ回線は通常、受入方向のＭＣＲが５００乃至２５００ｋｂｐｓ、送出方向のＭＣＲが６４乃至２５６ｋｂｐｓである。別の例では、ＰＲＤ（１５０）のアドミニストレータがＡＯＬであると分かれば、ＰＲＤ（１５０）はボイス・モデム・ダイアルアップ（voice modem dial-up）回線を介して接続されている可能性が高い。これは、ボイス・モデム・ダイアルアップ回線が、ＡＯＬにより提示される接続のうち主要な接続であるからである。ボイス・モデム・ダイアルアップ回線は一般的に、受入方向ＭＣＲが５６ｋｂｐｓ以下、送出方向ＭＣＲが３３ｋｂｐｓ以下である。

（２つのデバイスによる同一のリレー・デバイスの使用）
本発明の他の実施形態において、ＲＤＳ（１０２）は、２つの情報エレメントのオリジナル・ソースが２つの互いに異なるデバイスであることを決定することにより、ＰＲＤ（１５０）がリレー・デバイス（１０８）であることを検知する。このとき、オリジナル・ソースのうち一方が、ＰＲＤ（１５０）である必要はない。

この実施形態において、ＲＤＳ（１０２）は次の２つの場合を区別することを試みる。
図５Ａは第１の場合を表すダイアグラムを示す。第１の場合において、ＩＳＤ（１０４）は２つの情報エレメントＰＲＩＥ１及びＰＲＩＥ２を、ＲＤ（１０８）を用いることなく直接ＭＨ（１１０）へ送信する。これら２つの情報エレメントは、ＲＤ（１０８）が中継可能な種類の情報エレメントである。
図５Ｂは第２の場合を表すダイアグラムを示す。第２の場合において、２つの互いに異なるデバイスＩＳＤ（１０４）及びＩＳＤ２（１０６）のそれぞれは、情報エレメントをＭＨ（１１０）へ送信する。これら情報エレメントは、ＲＤ（１０８）により中継される情報エレメントである。

ＲＤＳ（１０２）は次の２つの場合を区別する。
ＲＤＳ（１０２）はＭＨ（１１０）の通信をモニタし、したがってＲＤ（１０８）から２つの潜在的に中継された情報エレメント（ＰＲＩＥ１及びＰＲＩＥ２）を受信する。ＲＤＳ（１０２）はその後、ＰＲＩＥ１のオリジナル・ソース（ＰＲＩＥ１−ソース）の特徴（ＰＲＩＥ１−特徴）と、ＰＲＩＥ２のオリジナル・ソース（ＰＲＩＥ２−ソース）の特徴（ＰＲＩＥ２−特徴）が、不適合性の特徴であるか否かをチェックする。ＰＲＩＥ１−特徴とＰＲＩＥ２−特徴が不適合性特徴であるならば、ＰＲＩＥ１のオリジナル・ソースと、ＰＲＩＥ２のオリジナル・ソースが互いに異なるデバイスである可能性が高い。即ち、ＰＲＩＥ１とＰＲＩＥ２が中継された第２の場合である可能性が高い。

説明を簡潔にするために、この実施形態を３つのデバイスを用いて説明する。３つのデバイスのうち２つのデバイスは、リレー・デバイスを用いる。実際には、多数のデバイスがインターネット（１００）に接続し、それらデバイスには、複数のリレー・デバイスを用いるデバイスと、用いないデバイスがある。これら複数のリレー・デバイスもまた、インターネット（１００）に接続する。より一般的にいうと、この実施形態では、潜在的リレー・デバイスから受信される少なくとも２つの潜在的に中継された情報エレメントの少なくとも２つのオリジナル・ソースが、不適合性特徴を有すると決定することにより、潜在的リレー・デバイスがリレー・デバイスであることを検知する。定義上、単一のデバイスが不適合性特徴を有する可能性は低いから、２つのオリジナル・ソースは互いに異なるデバイスである可能性が高い。したがって、少なくとも１つのオリジナル・ソースが潜在的リレー・デバイスではない。つまり、この情報ソースからの情報エレメントは、中継されており、潜在的リレー・デバイスはリレー・デバイスである。

特徴が不適合性特徴であるか否かを決定するための上記した方法は全て、必要な変更を加えた上で、この実施形態にも適用できる。例えば、ＲＤＳ（１０２）は、ＰＲＩＥ１とＰＲＩＥ２に提供されるＨＴＴＰ「ユーザ・エージェント」ヘッダを比較する。これらのヘッダが異なるオペレーティング・システムを指し示しているならば、ＲＤＳ（１０２）はＩＳＤ（１０４）とＩＳＤ２（１０６）が互いに異なるデバイスであり、したがってＰＲＤ（１５０）がリレー・デバイス（１０８）であると決定する。他の例では、ＲＤＳ（１０２）はＰＲＩＥ１−ソースとの通信のＲＴＴと、ＰＲＩＥ２−ソースとの通信のＲＴＴの間に有意な差異が存することを検知する。この場合ＲＴＴのそれぞれは、（ａ）ＲＤ（１０８）とＭＨ（１１０）の間のＲＴＴと、（ｂ）それぞれのオリジナル・ソースとＲＤ（１０８）の間のＲＴＴの合計と等しい。したがって、この場合のＲＴＴギャップは（ｃ）ＰＲＩＥ１−ソースとＲＤ（１０８）の間のＲＴＴと、（ｄ）ＰＲＩＥ２−ソースとＲＤ（１０８）の間のＲＴＴの差となる。２つのＲＴＴの間に有意な差異が存在しない場合にも、ＲＤＳ（１０２）がＲＴＴギャップを検知できる場合もある。

（オリジナル・ソースとの通信の確認）
本発明のいくつかの実施形態において、デバイスの特徴に関する情報は、１若しくはそれ以上の新たな通信から取得されるのであって、オリジナルの通信或いはＮＲＩＥ及び／又はＰＲＩＥに含まれる通信から取得されるのではない。このような新たな通信を使用可能とするためには、これら通信がＰＲＩＥ及び／又はＮＲＩＥのオリジナル・ソースとの通信であることを確認しなければならない。

米国特許出願第２００４０２４３８３２号公報は、その内容の全てが参照として本明細書中に組み込まれるが、この公報は、２つのネットワーク・メッセージが同一の送信元から発信されたと決定するためのいくつかの方法を開示している。これら方法は、情報エレメント或いは通信ではなくメッセージを参照し、オリジナル・ソースではなく送信元を参照するが、当業者であれば、この公報に開示される方法の大部分が、同一のオリジナル・ソースから送信された２つの情報エレメントの検知にも適用可能であることが理解できる。

一つの実施形態において、同一のソースＩＰアドレスとともに受信された、或いは同一の目的地ＩＰアドレスに送信されたＩＣＭＰパケット及びＴＣＰ／ＩＰパケットは、同一のデバイスとの通信とみなすことができる。

他の実施形態において、１つのＴＣＰ接続に属する受入方向のＴＣＰ／ＩＰパケットは、同一のデバイスからのパケットとみなすことができる。

他の実施形態において、ＨＴＴＰプロトコルにしたがってＨＴＴＰリクエストに続いて送信されたＨＴＴＰレスポンスは、ＨＴＴＰリクエストのソースとの通信とみなすことができる。

（システム）
図３は、本発明の一実施形態に係るリレー検知システム（１０２）のコンポーネントを示す。
情報エレメント・レシーバ（３０）はＭＨ（１１０）が受信する通信をモニタする。情報エレメント・レシーバ（３０）はまた、ＭＨ（１１０）が送信する通信も潜在的にモニタする。情報エレメント・レシーバ（３０）はまた、送出方向の通信センダ（３６）が送信する通信も潜在的にモニタする。

特徴不適合性解析器（３４）はＩＳＤ特徴とＰＲＤ特徴が不適合性特徴であるか否かを決定する。
選択的な構成である特徴発見モジュール（３２）はＩＳＤ特徴及び／又はＰＲＤ特徴を発見する。
選択的な構成である送出方向通信センダ（３６）は１若しくはそれ以上の送出方向の通信を送信する。
選択的な構成であるパラメータ解析器（３８）は１若しくはそれ以上のパラメータを取得する。これらパラメータは、（ａ）ＩＳＤ特徴、（ｂ）ＰＲＤ特徴、及び／又は（ｃ）ＩＳＤ特徴とＰＲＤ特徴が不適合性特徴であるか否かを指し示す。
選択的な構成である特徴データベース（４０）は、特徴の対のリストと、それら特徴が不適合性特徴であるか否かに関する情報を含む。例えば、特徴データベース（４０）は、ＨＴＭＬクライアントが各オペレーティング・システムによりサポートされているディスクリプションを含む。

（その他の雑多な事項）
いくつかの実施形態において、本発明は、本明細書中に開示される特徴或いはパラメータを任意の組み合わせで用いて、潜在的リレー・デバイスがリレー・デバイスであるか否か、及び／又は受信された情報エレメントがリレー・デバイスにより中継されているか否かを決定する。

上記のいくつかの実施形態において、ＩＳＤ特徴及び／又はＰＲＤ特徴は、レイテンシ及び／又は通信速度に関連付けられた。当業者であれば、このような場合は、ＩＳＤ特徴及び／又はＰＲＤ特徴が通信速度に関連付けられるようなより一般的な場合を特殊化したものであることが理解できる。

通信性能とは、通信のスピード（speed）、速度（rate）、時間、効率などを表す全てのパラメータのことをいう。

２つの特徴が不適合性特徴であるか否かを決定する過程において、ＲＤＳ（１０２）はそれぞれの特徴が発見された時間を考慮しなければならない。例えば、２つの特徴が午前９：０５と午前１０：０５に等しいウォール・クロック・コンフィギュレーションであり、第２の特徴は第１の特徴からちょうど１時間後に発見されたならば、２つの特徴を不適合性特徴とみなすことができない。これは、発見時間の差が直接特徴の差を説明しているからである。しかしながら、この２つの特徴がほぼ同時刻に発見された場合にも、これら特徴が不適合性特徴とみなされることがある。他の例において、第１の特徴が９００ミリ秒というＲＴＴ測定値で、第２の特徴が９４０ミリ秒というＲＴＴであり、第１の特徴が第２の特徴から２４時間後に発見されたならば、これら特徴は必ずしも不適合性特徴とはいえない。これは、ネットワーク・トポロジの変化によりこの差が生じたかもしれないからである。しかしながら、これら２つの特徴が同じ１００ミリ秒間に発見されたならば、トポロジの変化の可能性は低く、これら特徴が不適合性特徴である可能性が高い。

特徴がほぼ同時に発見されたならば、ＲＤＳ（１０２）はこれらの特徴が同時に同一のデバイスに関連している可能性が低いものとみなす。

本発明の新規な開示事項の多くが、本明細書中に開示された実施形態を参照して説明されてきた。しかしながら、この種の実施形態は、本明細書中で開示される新規な事項の多くの利点の一部の例を示すにすぎない。一般的に、本明細書中の記載事項は、本発明の請求の範囲に記載の発明を必ずしも限定するものではない。更に、いくつかの記載は、本発明の一部の特徴には該当するが、その他の特徴には該当しない。

本発明の特定の実施形態を説明してきたが、当業者であれば、広い意味で本発明の範囲を離れることなく変更や改変を行うことが可能であることが理解できる。したがって、本発明の請求の範囲には、本発明の要旨及び範囲内にあるこれらの変更や改変が含まれるものとする。

いくつかの実施形態において、「可能性が低い（unlikely）」とは、最大４０％の可能性があることをいう。
他の実施形態において、この可能性は最大３０％である。
他の実施形態において、この可能性は最大２０％である。
他の実施形態において、この可能性は最大１０％である。
他の実施形態において、この可能性は最大５％である。
他の実施形態において、この可能性は最大１％である。
他の実施形態において、この可能性は最大１／２％である。
同様に、「可能性の高い（likely）」イベントとは、確率１００％から、「可能性の低い」イベントが起こる可能性を差し引いた確率で起こるイベントをいう。

いくつかの実施形態において、「単一の（single）」デバイスとは、物理的に１つであるデバイスのことをいう。しかしながら、当該技術分野において、データネットワークに接続された電子デバイス（例えば、リレー・デバイス、モニタされるホスト、及び情報ソース・デバイス）はしばしば、複数の物理的に別個のデバイスの集合からなる。このようなデバイスの集合は、データネットワーク及び／又はデータネットワーク上のデバイスに対して、自らを「単一の」デバイスとして提示する。したがって、本明細書中において、「単一の」デバイスとは、物理的に１つのデバイスと、自らを単一のデバイスとして提示するように論理的に設定された物理的に複数のデバイスの両方を示す。

いくつかの実施形態において、本明細書中の「異なる（different）」位置とは、異なる国に位置する場所を示す。
いくつかの実施形態において、本明細書中の「異なる（different）」位置とは、異なる州に位置する場所を示す。
いくつかの実施形態において、本明細書中の「異なる（different）」位置とは、異なる地域（province）に位置する場所を示す。
いくつかの実施形態において、本明細書中の「異なる（different）」位置とは、異なる大陸に位置する場所を示す。
いくつかの実施形態において、本明細書中の「異なる（different）」位置とは、異なる時間帯に位置する場所を示す。
いくつかの実施形態において、本明細書中の「異なる（different）」位置とは、１００キロメートル以上、２００キロメートル以上、１０００キロメートル以上、或いは２５００キロメートル以上離れた場所を示す。

本発明の実施形態に従ってリレー検知システムを操作する環境を示す図である。 情報エレメントをリレー検知システムに送る潜在的リレー・デバイスのダイアグラムを示す。 本発明のいくつかの実施形態に従うダイアグラムであり、リレー検知システムにより受信された情報エレメントのオリジナル・ソースのダイアグラムを示す。 潜在的リレー・デバイスが情報ソース・デバイスである場合のダイアグラムを示す。 潜在的リレー・デバイスと情報ソース・デバイスが別個のデバイスである場合のダイアグラムを示す。 本発明のいくつかの実施形態に従うシステムを示す図である。 リレー・デバイスが用いられる場合において、情報ソース・デバイス及びモニタされるホストの間の通信のレイテンシを示す図である。 リレー・デバイスが用いられない場合において、情報ソース・デバイス及びモニタされるホストの間の通信のレイテンシを示す図である。 情報ソース・デバイスが２つの情報エレメント（潜在的に中継された情報エレメント１及び潜在的に中継された情報エレメント２）を、リレー・デバイスを用いることなしに、直接にモニタされるホストへ送る場合を示すダイアグラムである。 ２つの異なるデバイス（情報ソース・デバイス及び情報ソース・デバイス２）それぞれが情報エレメントをモニタされるホストに送り、両情報エレメントがリレー・デバイスにより中継される場合のダイアグラムを示す。

Claims (50)

1. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、該方法は、
   （ａ）前記潜在的リレー・デバイスからの第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスが前記第２情報エレメントのオリジナル・ソースであり、
   （ｂ）更に、前記第１の情報エレメントのオリジナル・ソースの特徴と、前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階を備え、
   前記決定する段階において、単一のデバイスに関連するものでないとの結果が指し示されると、前記潜在的リレー・デバイスがリレー・デバイスであるという決定をすることを特徴とする方法。
2. 前記第２の情報エレメントが、リレー・デバイスのうち１つのクラスにあるリレー・デバイスが中継しない種類の情報エレメントであることを特徴とする請求項１記載の方法。
3. リレー・デバイスの前記クラスが、SOCKSプロキシ、GETメソッドを用いたHTTPプロキシ、CONNECTメソッドを用いたHTTPプロキシ、ＩＰルータ及びネットワーク・アドレス・トランスレーション・デバイスからなる群から選択されることを特徴とする請求項２記載の方法。
4. 前記第２の情報エレメントが通信の一部であり、該通信が、IP、TCP、ICMP、DNS、HTTP、SMTP、TLS及びSSLからなる群から選択される種類の通信であることを特徴とする請求項１記載の方法。
5. 前記第１の情報エレメントが通信の一部であり、該通信が、IP、TCP、ICMP、DNS、HTTP、SMTP、TLS及びSSLからなる群から選択される種類の通信であることを特徴とする請求項１記載の方法。
6. 前記第１の情報エレメント及び前記第２の情報エレメントが単一の通信の一部であることを特徴とする請求項１記載の方法。
7. 前記第１の情報エレメント及び前記第２の情報エレメントが、プロトコル・スタックの互いに異なる２つの層内に送信されることを特徴とする請求項６記載の方法。
8. 前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、
   （ｉ）前記第１の情報エレメントのオリジナル・ソースの特徴を発見する段階と、
   （ｉｉ）前記潜在的リレー・デバイスの特徴を発見する段階からなることを特徴とする請求項１記載の方法。
9. 前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が更に、
   （ｉｉｉ）前記第１の情報エレメントのオリジナル・ソースの特徴を前記潜在的リレー・デバイスの特徴と比較する段階を備えることを特徴とする請求項８記載の方法。
10. （ｃ）前記第１の情報エレメントのオリジナル・ソースの前記特徴を指し示すパラメータを得る段階と、
    （ｄ）前記潜在的リレー・デバイスの前記特徴を指し示すパラメータを得る段階を備えることを特徴とする請求項８記載の方法。
11. 前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が更に、
    （ｉｉｉ）前記第１の情報エレメントのオリジナル・ソースの前記特徴と前記潜在的リレー・デバイスの前記特徴のうち少なくとも一方を発見する時間を考慮する段階を備えることを特徴とする請求項８記載の方法。
12. （ｃ）前記第１の情報エレメントの前記オリジナル・ソースの前記特徴と前記潜在的リレー・デバイスの特徴との間の関係を指し示すパラメータを得る段階を備えることを特徴とする請求項１記載の方法。
13. 前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が更に、前記第１の情報エレメントの前記オリジナル・ソースの前記特徴と前記潜在的リレー・デバイスの前記特徴の間の関係を指し示す前記パラメータの解析を行う段階を備えることを特徴とする請求項１２記載の方法。
14. 前記パラメータが、前記第１の情報エレメントと前記第２の情報エレメントのうち少なくとも一方から得られることを特徴とする請求項１２記載の方法。
15. （ｃ）前記第１の情報エレメントの前記オリジナル・ソースと前記リレー・デバイスのうち少なくとも一方へ送出方向の通信を送る段階と、
    （ｄ）前記第１の情報エレメントの前記オリジナル・ソースと前記潜在的リレー・デバイスのうち前記少なくとも一方から第３の情報エレメントを受け取る段階を備えることを特徴とする請求項１記載の方法。
16. 前記第３の情報エレメントから、前記第１の情報エレメントの前記オリジナル・ソースと前記潜在的リレー・デバイスのうち前記少なくとも一方の特徴に関連した情報を引き出すことを特徴とする請求項１５記載の方法。
17. （ｉｉｉ）前記第３の情報エレメントのオリジナル・ソースが前記第１の情報エレメントの前記オリジナル・ソースであることを確認する段階を備えることを特徴とする請求項１５記載の方法。
18. 前記第３の情報エレメントのオリジナル・ソースが前記潜在的リレー・デバイスであることを確認する段階を備えることを特徴とする請求項１５記載の方法。
19. 前記第３の情報エレメントが、ICMPメッセージ、ICMPエコー・リプライ・メッセージ、DNSクエリ、HTTPリクエスト、HTTPレスポンス、HTTPサーバヘッダ、ＩＰアドレス、TCPポート、TCPイニシャル・シーケンス・ナンバ、TCPイニシャル・ウィンドウ、WHOISレコード及びリバースDNSレコードからなる群から選択されることを特徴とする請求項１５記載の方法。
20. 前記第１の情報エレメントのオリジナル・ソースの前記特徴と前記潜在的リレー・デバイスの前記特徴のうち少なくとも一方がコンフィギュレーションの状態に関連した特徴であることを特徴とする請求項１記載の方法。
21. 前記コンフィギュレーションの状態に関連した特徴が、オペレーティング・システムの種別、オペレーティング・システムのバージョン、ソフトウェアの種別、HTTPクライアントの種別、HTTPサーバの種別、SMTPクライアントの種別、SMTPサーバの種別、時間設定、クロック設定及びタイムゾーンの設定からなる群から選択されることを特徴とする請求項２０記載の方法。
22. 前記第１の情報エレメントのオリジナル・ソースの特徴と、前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、コンフィギュレーションの状態に関連する前記特徴を指し示すパラメータを調査する段階を備えることを特徴とする請求項２１記載の方法。
23. 前記パラメータが、HTTPユーザ・エージェント・ヘッダ、RFC822・Ｘメイラ・ヘッダ、RFC822レシーブド・ヘッダ、RFC822日付ヘッダ、プロトコル実装様式、TCP/IPスタック・フィンガプリント、IPアドレス、TCPポート、TCPイニシャル・シーケンス・ナンバ及びTCPイニシャル・ウィンドウからなる群から選択されることを特徴とする請求項２１記載の方法。
24. 前記第１の情報エレメントのソースの前記特徴と前記潜在的リレー・デバイスの前記特徴のうち少なくとも一方が通信性能に関連する特徴であることを特徴とする請求項１記載の方法。
25. 通信性能に関連する前記特徴が、測定された通信性能、測定された相対的通信性能及び推定される通信性能からなる群から選択されることを特徴とする請求項２４記載の方法。
26. 通信性能に関連する前記特徴が、通信のレイテンシ、受入方向の通信のレイテンシ、送出方向の通信のレイテンシ、通信のラウンド・トリップ・タイム、通信レイト、受入方向の通信レイト、送出方向の通信レイト、最大通信レイト、受入方向の最大通信レイト及び送出方向の最大通信レイトからなる群から選択されることを特徴とする請求項２４記載の方法。
27. 前記第１の情報エレメントのオリジナル・ソースの特徴と、前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、通信性能に関連する特徴を指し示すパラメータを調査する段階を備えることを特徴とする請求項２４記載の方法。
28. 前記パラメータが、情報エレメントの受領時間、情報エレメントの送信時間、ラウンド・トリップ・タイム、ラウンド・トリップ・タイムのギャップ、IPアドレス、WHOISレコード、リバースDNSレコード及び肯定応答情報のレイトからなる群から選択されることを特徴とする請求項２７記載の方法。
29. ラウンド・トリップ・タイムのギャップが大きければ大きいほど、リレー・デバイスが悪意の目的で使用されている可能性が高いことを指し示すことを特徴とする請求項２８記載の方法。
30. 通信性能に関連する前記特徴が、前記第１の通信の前記オリジナル・ソースと前記潜在的リレー・デバイスのうち少なくとも一方についての情報から見積もられることを特徴とする請求項２４記載の方法。
31. 前記第１の通信の前記オリジナル・ソースと前記潜在的リレー・デバイスのうち少なくとも一方についての前記情報がデバイスの位置、デバイスのホスト・ネーム及びデバイスのアドミニストレータからなる群から選択されることを特徴とする請求項３０記載の方法。
32. 前記第１の情報エレメントの前記オリジナル・ソースの前記特徴と、前記潜在的リレー・デバイスの前記特徴のうち少なくとも一方がサブ・ネットワーク、アドミニストレータ及び位置からなる群から選択されることを特徴とする請求項１記載の方法。
33. 前記第１の情報エレメントのオリジナル・ソースの特徴と、前記潜在的リレー・デバイスの特徴が単一のデバイスに関連するものでないことの特徴であるか否かを決定する段階が、前記第１の通信のソースの前記特徴と、前記第２の通信のソースの前記特徴のうち少なくとも一方を指し示すパラメータを調査する段階を備え、
    該パラメータが、HTTPユーザ・エージェント・ヘッダ、RFC822・Ｘメイラ・ヘッダ、RFC822レシーブド・ヘッダ、RFC822日付ヘッダ、IPアドレス、WHOISレコード及びリバースDNSレコードからなる群から選択されることを特徴とする請求項３２記載の方法。
34. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスは前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）更に、前記第１の情報エレメントと前記第２の情報エレメントのうち少なくとも一方のコンフィギュレーションの状態を解析する段階を備え、該コンフィギュレーションの状態が、オペレーティング・システムの種別、オペレーティング・システムのバージョン、ソフトウェアの種別、HTTPクライアントの種別、HTTPサーバの種別、SMTPクライアントの種別、SMTPサーバの種別、時間設定、クロック設定及びタイムゾーンの設定からなる群から選択されることを特徴とする方法。
35. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスは前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）更に、前記第１の情報エレメントと前記第２の情報エレメントのうち少なくとも一方のオリジナル・ソースの通信性能の関連する特徴を解析する段階を備えることを特徴とする方法。
36. 通信性能に関連する前記特徴が、通信のレイテンシ、受入方向の通信のレイテンシ、送出方向の通信のレイテンシ、通信のラウンド・トリップ・タイム、通信レイト、受入方向の通信レイト、送出方向の通信レイト、最大通信レイト、受入方向の最大通信レイト及び送出方向の最大通信レイトからなる群から選択されることを特徴とする請求項３５記載の方法。
37. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）情報ソース・デバイスにメッセージを送信するとともに、前記情報ソース・デバイスにDNSリクエストを送信させる段階と、
    （ｂ）前記DNSリクエストから、前記潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する段階からなることを特徴とする方法。
38. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階と、
    （ｂ）前記第１の情報エレメントのオリジナル・ソースの特徴と、前記第２の情報エレメントのオリジナル・ソースの特徴が単一のデバイスに関連しない特徴であるか否かを決定する段階からなり、
    前記決定する段階において、単一のデバイスに関連しない特徴であると決定された場合には前記潜在的リレー・デバイスがリレー・デバイスであることを意味することを特徴とする方法。
39. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスが、前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）更に、前記潜在的リレー・デバイスへのラウンド・トリップ・タイムが、前記第１の情報エレメントのオリジナル・ソースへのラウンド・トリップ・タイムと比べて有意な差異が存するか否かをチェックする段階を備えることを特徴とする方法。
40. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスが、前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）更に、前記潜在的リレー・デバイスのオペレーティング・システムが前記第１の情報エレメントのオリジナル・ソースのオペレーティング・システムと相違するか否かをチェックする段階を備えることを特徴とする方法。
41. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスが、前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）更に、前記潜在的リレー・デバイスの位置が前記第１の情報エレメントの位置と相違するか否かをチェックする段階を備えることを特徴とする方法。
42. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）前記潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階を備え、前記潜在的リレー・デバイスが、前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）更に、前記潜在的リレー・デバイスのアドミニストレータが前記第１の情報エレメントのオリジナル・ソースのアドミニストレータと相違するか否かをチェックする段階を備えることを特徴とする方法。
43. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定する方法であって、
    （ａ）第１の情報エレメントのオリジナル・ソースの特徴と前記潜在的リレー・デバイスの特徴が単一のデバイスに関連しない特徴であるか否かを決定する段階を備え、
    前記潜在的リレー・デバイスが、前記第２の情報エレメントのトランスミッタであり、
    前記決定する段階の結果が単一のデバイスに関連しない特徴であるというものであるならば、前記潜在的リレー・デバイスがリレー・デバイスを指し示しているものとすることを特徴とする方法。
44. 潜在的リレー・デバイスがリレー・デバイスであるか否かを決定するシステムであって、該システムは、
    （ａ）情報エレメント・レシーバを備え、該情報エレメント・レシーバは、情報ソース・デバイス及び潜在的リレー・デバイスを含む複数のデバイスから情報エレメントを受け取り、
    （ｂ）前記システムは、特徴不適合性解析器を備え、該特徴不適合性解析器は、前記情報ソース・デバイスの特徴と前記潜在的リレー・デバイスの特徴が単一のデバイスに関連しない特徴であるか否かを決定することを特徴とするシステム。
45. （ｃ）特徴発見モジュールを更に備え、該特徴発見モジュールが、前記情報ソース・デバイスの特徴と前記潜在的リレー・デバイスの特徴からなる群から選択される少なくとも１つの特徴を発見することを特徴とする請求項４４記載のシステム。
46. 前記情報エレメント・レシーバが、更に、モニタされるホストから情報エレメントを受け取るように形成されることを特徴とする請求項４４記載のシステム。
47. （ｃ）送出方向の情報エレメント用の送受信端末を更に備えることを特徴とする請求項４４記載のシステム。
48. （ｃ）パラメータ取得器を更に備え、該パラメータ取得器が、情報ソース・デバイスの特徴を指し示すパラメータ、前記潜在的リレー・デバイスの特徴を指し示すパラメータ、及び情報ソース・デバイスの特徴と前記リレー・デバイスの特徴が単一のデバイスに関連しないことを示す特徴であるか否かを指し示すパラメータからなる群から選択される少なくとも１つのパラメータを取得することを特徴とする請求項４４記載のシステム。
49. （ｃ）特徴データベースを更に備え、該特徴データベースが特徴の対とデータのマップを格納し、該データが、前記特徴の対が不適合性を示す特徴であるか否かを指し示すことを特徴とする請求項４４記載のシステム。
50. コンピュータにより読み取り可能な記録メディアに記録されるコンピュータ・ソフトウェアであって、該ソフトウェアが、
    （ａ）潜在的リレー・デバイスから第１の情報エレメントと第２の情報エレメントを受け取る段階をコンピュータに指示し、前記潜在的リレー・デバイスは前記第２の情報エレメントのオリジナル・ソースであり、
    （ｂ）前記ソフトウェアは更に、前記第１の情報エレメントのオリジナル・ソースの特徴と前記潜在的リレー・デバイスの特徴が単一のデバイスに関連しない特徴であるか否かを決定する段階をコンピュータに指示し、
    前記決定する段階において、単一のデバイスに関連しない特徴であるとの決定がなされるならば、前記潜在的リレー・デバイスがリレー・デバイスであることを指し示すことを特徴とするソフトウェア。
    

Images