説明

ジオインテリジェントトランフィックレポーター

【課題】インターネットトラフィックに関するリアルタイム情報を提供するシステムと方法とを提供すること。
【解決手段】トラフィックレポータがネットワーク内のトラフィック条件に関するリアルタイム情報を収集し、トラフィックマネージャへトラフィックレポートを送出する。トラフィックレポータはネットワークを分析し、ネットワークを介して分散されたトラフィックマネージャおよびアナライザからネットワーク情報の収集も行う。これらのトラフィックレポートはネットワーク状態に関するリアルタイム情報を提供して、トラフィックマネージャが、信頼性の高い、最も高速な方法でネットワークトラフィックのルート指定を行うことができるようにする。

【発明の詳細な説明】
【技術分野】
【0001】
(発明の分野)
本発明は、インターネットトラフィックのルート指定を行うシステムと方法とに関し、特に、ノードとリンクの地理上の所在位置、距離、ノードでの利用可能な帯域幅、接続スピード、利用可能なリソース、並びに、ノードまたはリンクの状態に関する情報などのインターネットトラフィックに関するリアルタイム情報を提供するシステムと方法とに関する。
【背景技術】
【0002】
(背景)
インターネットは相互に接続されたコンピュータネットワークからなるネットワークから構成されている。これらコンピュータの各々は、ピリオドすなわちドットにより分離された一連の4つの数から成るIPアドレスを有し、これらの4つの数の各々は、インターネット内でコンピュータの一意のアドレスを一括して表す8ビットの整数である。インターネットはパケット交換ネットワークであるため、インターネット上で或る宛先へルート指定されたデータファイルは複数のパケットに分割され、その宛先へ別々に送信される。個々のパケットには、特に、データファイルの或る部分および宛先を示すIPアドレスが含まれる。
【0003】
宛先を示すIPアドレスは、正しい宛先へ向けてパケットのルート指定を行う際に有用ではあるが、一般の人にとってあまりわかりやすいものではない。1グループの4つの8ビット数自体は、宛先に関して何も明らかにしていないし、示唆するものでもないため、ほとんどの人は宛先のIPアドレスを記憶することを難しく感じる。IPアドレスの利用時のこの欠点を克服する結果としてドメイン名が形成された。ドメイン名は2または3以上の部分から構成され、この部分はピリオドによって分離された単語である場合が多い。ドメイン名を形成する単語、数字またはその他の記号は、宛先の識別番号を示したり、少なくとも宛先の識別番号を示唆したりする場合が多いため、ドメイン名がアドレスを入力する標準的方法になっており、IPアドレスに比べて覚え易い。ドメイン名の入力後、ドメインネームサーバ(DNS)はある特定のIPアドレスにドメイン名を分析する。したがって、例えば、インターネットサーフィンをしていたある人がブラウザプログラムの中へウェブサイト用の特定のドメイン名を入力すると、ブラウザはまず正しいIPアドレスで着信するDNSについて照会を行う。
【0004】
IPアドレスが良好に機能して、インターネットで正しいアドレスへパケットを配信している間、IPアドレスは宛先の地域別アドレスに関する有用情報を送信しない。さらに、ドメイン名は、時として、正確にまたは不正確にこのような位置を示唆することがあるとはいえ、地理上の所在位置を必ずしも示すものでさえない。IPアドレスまたはドメイン名と地理上の所在位置との間のリンクが存在しないという状況は国内および国外の双方について当てはまることである。例えば、国別のトップレベルのドメイン形式では、米国については.us、英国については.uk等が指定されている。したがって、これらの拡張子を参照することにより、コンピュータが配置されている国を少なくとも決定できる場合が多い。しかし、これらの拡張子はひとを欺く可能性がある場合が多く、不正確である場合もある。例えば、.mdドメインはモルドバ共和国に割り当てられているが、米国では医学博士にきわめて人気がある。したがって、ドメイン名はコンピュータの地理上の所在位置について或る一面を示唆することができる一方で、ドメイン名とIPアドレスとが有用な地理情報を何ら送信しない場合も多い。
【0005】
地理上の所在位置に加えて、IPアドレスとドメイン名は、コンピュータまたはコンピュータネットワークを使用している個人や会社に関する情報をほとんど伝えるものではない。その結果、訪問者が、自分の本当のIDを明らかにすることなく、ウェブサイトへ行き、ファイルを転送し、または電子メールを送信する可能性がある。しかし、上記匿名性は多くのウェブサイトが望むカウンタを動かすものである。例えば、広告を目的とする場合、広告と関連する商品またはサービスについて最適化された選択マーケットグループへ個々の広告対象ターゲットを絞ることが望ましい。個人またはグループの関心に一致する、あるいはこの関心対象と密接に関連する製品またはサービスと関連する広告はより効果のあるものとなり、したがって、広告主にとってはサイトへのすべての訪問者へやみくもに送出される広告に比べるとさらに貴重なものとなる。
【0006】
広告収入を増やして、販売を増やしたいという願望にしばしば突き動かされて、多くのサイトが現在それらサイトへの訪問者のプロファイリング(profiling)を行っている。訪問者のプロファイリングを行うために、ウェブサイトはサイトを通じてその訪問者のトラフィック履歴をまずモニタし、様々なグループの訪問者の振舞いパターンを検出する。ウェブサイトは、或るグループの訪問者が特別の関心対象を含むページまたは一連のページを要求していることを推論できるようになる。当該グループ内の個人が要求した次のページ用の広告を選択すると場合、ウェブサイトは個人またはグループの推論された関心対象と関連する広告にターゲットを絞ることができる。したがって、ウェブサイトにおける別の訪問者の振舞いに基づいてウェブサイトの中を通る訪問者のトラフィックがマップされ、分析される。したがって、ウェブサイトの訪問者に関してできるかぎり多くの情報を得る際に多くのウェブサイトを関心対象として、それらのウェブサイトの利益の増加を図ることが意図される。
【0007】
インターネットユーザに関してさらに多くの情報を知りたいという要望はユーザのプライバシに関する懸念により抑えられる。例えば、クッキの利用は多くの訪問者にとって好ましくないものである。実際に、下院へ法案が提出されており、また、上院でもクッキあるいはデジタルIDタグの使用を規制する法案が提出されている。ユーザ用コンピュータにクッキを設けることにより、企業は、多数のウェブサイトにわたって訪問者を追跡し、それによって訪問者の関心対象を示唆することが可能となる。多くの企業がクッキおよびその他のプロファイリング手法を有益なものであると思っているが、プロファイリング技法は社会全般から広範な承認を勝ち得ていない。
【0008】
プライバシとプロファイリング間での競合する利害関係についての特に多くを物語る例として、ニューヨークのダブルクリック社(ニューヨーク州)が個人の氏名と住所を個人のそれぞれのIPアドレスと結びつけた場合の例がある。ダブルクリック社の行動に対する反応には、電子プライバシ情報センタによる連邦通商委員会(FTC)への告訴手続きと、訪問者の閲覧習慣の追跡は本質的に権利の侵害であるという多くのプライバシ擁護からの激しい抗議の噴出とが含まれた。したがって、たとえ、インターネットにおける個人の正確な追跡が技術的に可能なものであったとしても、企業は、訪問者のプロファイルを行いたいという願望と匿名のままでいたいという訪問者の権利との注意深いバランスをとる必要がある。
【0009】
インターネットユーザについてさらに多くの情報を知る際の困難として、インターネットユーザがアメリカオンライン(AOL)などの専用ネットワークの一部である場合、さらに複雑な問題が生じる。AOL並びに他の専用ネットワークは、メンバーユーザとインターネット間のプロキシサーバを操作することにより中継ネットワークとして機能している。プロキシサーバは、メンバーからなる私的共同体の形成を助け、インターネット上で生じる可能性がある何らかの侵害的照会からメンバーを遮断し、保護するものである。この保護と遮断の一部として、これら専用ネットワークの多くは専用ネットワーク内のみで
のルート指定用の第1の組のIPアドレスをそのメンバーに割り当て、インターネット上などの、専用ネットワークの外のエンティティに対してこれらのIPアドレスを明らかにしない。メンバーと交信するためには、専用ネットワークの外側のエンティティはメンバーに対して直接アクセスを行わないで、代わりにプロキシサーバを介する必要がある。当業者には明らかなように、専用ネットワークのメンバーに関する情報のプロファイリングおよび違った形での上記情報の収集は、プロキシサーバが存在するためにさらにずっと困難なものとなる可能性がある。
【0010】
コンテンツのターゲットをユーザにしぼることを目的として、インターネットユーザについてさらに多くの情報を知ることに加えて、ユーザと宛先とについての情報がユーザの要求するルート指定時に役立つ可能性がある。インターネットの場合、ユーザの要求はパケットに分割され、これらのパケットはノードからノードへルート指定された後、最終的にパケットは意図された宛先に達する。次いで、これらのパケットは再構成されて、元の要求が形成される。この推移の最中にパケットは異なるルートをとる場合があり、パケットのいくつかが脱落する場合がある。ノードは通常最小回数のノードまたはホップの通過によって宛先へのパケットの送信を試みる。個々のノードは、パケットの受信後、パケットの発送時に或る待ち時間を有するため、ホップ回数を最小化することにより、待ち時間が最小化される。宛先がどこに位置するかに関する情報を用いて、ノードは、たとえ多数のホップが含まれるものであってもより直接的なルート選択を行うことができる。
【0011】
Leinwandらに付与された米国特許第6,130,890号は、本願明細書で参照により援用される特許であるが、この特許に、データパケットのルート指定を最適化する方法およびシステムについての記載がある。この特許で、国と国との間の国際間のリンクの多くが頻繁に高度の過負荷状態になり、これらのリンクが利用される結果、たとえ最も少ないホップ回数を含むものであっても、より長い遅延が生じる可能性がある旨の記載がある。この特許に記載の方法は、インターネット番号アメリカン・レジストリ(American Registry Internet Numbers)(“ARIN”)、リソースIPヨーロッパ(Reseaux IP Europeans)(“RIPE”)、および、アジア・パシフィックネットワーク情報センタ(Asia−Pacific Network Information Center)(“APNIC”)を介して行われているような、個々のASで保守管理さている情報の利用に関わるものである。これらの組織に照会を行うことにより、システム個々の自律システム(AS)に関する国別情報を取得し、ASをそれらの国別記号と対応づけることができる。次いで、宛先と関連する国との直接のリンクを選択することによりパケットのルート指定を行うことができる。
【0012】
Leinwandらの特許で開示されたシステムと方法は、インターネットトラフィックのルート指定の最適化における限定された成功を提供するものである。以上説明したように、Leinwandらの特許はインターネットトラフィックの国別レベルのルート指定について記載するものではあるが、1国内におけるルート指定の実行方法について記載するものではない。米国内で発信するインターネットトラフィックの多くは、米国内の宛先へ向けられるものであるため、Leinwandらの特許に記載の方法およびシステムにはほとんど利点がない。さらに、ASと関連する情報は、ASの地理上の所在位置を正確に特定するものではない。国別情報は、ASが現実に位置している国以外の異なる国をリストするものであってもよいし、さらに、上記特許にされているように、2以上の国に関するASをリストするものであってもよい。必ずしも正確であるとはかぎらないことに加えて、AS情報に対する信頼はおそらく長期間については役に立たないかもしれない。AS番号用として確保された空間は、インターネットの爆発的成長と共に急速に空乏されている。AS番号が空乏した場合、上記特許に記載の方法を用いてその後利用されるASの地理上の所在位置の決定ができなくなるかもしれない。
【発明の開示】
【発明が解決しようとする課題】
【0013】
したがって、さらに効率的にかつ効果的にインターネットトラフィックのルート指定を行う改善されたシステムと方法とに対する要望が存在する。
【課題を解決するための手段】
【0014】
(概要)
本発明は、地理上の所在位置情報に基づいてネットワークトラフィックのルート指定を行うシステムと方法とを提供することにより上記問題を処理するものである。本発明の1つの態様によれば、上記方法には、ネットワークトラフィックを受信し、ネットワークの知的機能(intelligence)に基づいて上記ネットワークトラフィックを送るステップが含まれる。この知的機能には、トラフィックマネージャによるネットワークトラフィックの効率的かつ効果的なルート指定を可能にするデータが含まれる。上記知的機能には、トラフィック用宛先の地理上の所在位置と、トラフィックのソースの地理上の所在位置と、上記ソースにおいて利用可能な帯域幅と、宛先または中間ノードと、ノード間でのリンクの接続スピードまたは上記ソースにおける接続スピードと、異なる宛先における負荷と、ネットワークエレメントの信頼性と、が含まれる(但しこれらに限定されるものではない)。好ましい実施形態では、1組のアナライザがネットワークを通じて配分され、知的機能の収集が行われる。或いは、ネットワークから、または、別のシステムから直接知的機能を収集してもよい。
【0015】
好ましい実施形態に基づくトラフィックマネージャにより、知的機能がネットワークのマップに記憶される。このマップは、ネットワークの中を通って宛先またはソースまでのルート指定を決定することにより、ソースに関する地理情報並びに宛先と共にポピュレートされる。本発明の方法には、ソースと宛先間のルート内に含まれる任意の中間ホストのいずれかの地理上の所在位置を導き出すステップと、ルートと任意の中間ホストの地理上の所在位置とを分析するステップと、次いで、ソースと宛先の地理上の所在位置を決定するステップとが含まれる。この地理情報が確かめられた後、地理情報はマップに記憶される。
【0016】
本発明に基づくこの好ましいシステムはwhoisを実行して、IPアドレスまたはドメイン名を所有する組織を決定する。この所有者のアドレスによってはある地理上の所在位置についての何らかの示唆が提供されるが、決定的なものではない。ルート追跡(traceroute)を行って宛先までのルートを取得し、データベースにおいて地理的にルートのマッピングを行う。信頼レベルが、ルートに沿ったホストまたはノードについての情報に基づいて地理上の所在位置に割り当てられる。システムはトップレベルのドメイン7とドメイン名の中の実際の単語とを考慮に入れることができる。ネットワーク内のどこでも、DNSサービスの一部などのトラフィックマネージャを利用して、所望のIPアドレスへあるいは或るサイトに在る所望のコンテンツサーバへのHTTPリダイレクトとして、ユーザの要求を転送することができる。
【0017】
別の態様によれば、システムと方法は、ネットワークに関するリアルタイム情報とトラフィック条件とを取得するトラフィックレポータに関する。トラフィックレポータはトラフィックマネージャへトラフィックレポートを送信し、これらのトラフィックレポートはネットワークを通じて分散される。トラフィックマネージャは、特定の宛先へのルーティング情報の提供時に、上記リアルタイム情報を利用する。トラフィックレポータは、この情報を取得するためにネットワークの分析を行い、トラフィックマネージャ自身を通じてあるいはアナライザを通じるなどの手段によって別のソースからも情報を受信する。トラフィックレポータは、トラフィックマネージャへのこれらのトラフィックレポートの提供
時に何らかの自由裁量を利用して、トラフィック条件の著しい変化が発生したとき、トラフィックマネージャのみが受信、更新あるいは報告を行うようにする。
【0018】
トラフィックマネージャはトラフィックレポータからトラフィックレポートを受信し、これらのトラフィックレポートに基づいてルーティング指示を出力する。トラフィックマネージャは、通常のトラフィック条件のデータベースの保守管理を行い、トラフィックレポータが作成した任意のトラフィックレポートのモニタを行う。ルーティング指示の決定時に、トラフィックマネージャは、デフォルトの組のデータとして通常のトラフィック条件のデータベースを利用するが、最適のルーティング指示で着信する前に、任意の関係するトラフィックレポートのチェックも行う。トラフィックマネージャはローカルトラフィック条件もモニタし、トラフィックマネージャがトラフィックレポータへ発生を報告するべき程度までこれらの条件が通常の条件から逸れた時期を決定する。したがって、トラフィックマネージャは、トラフィック条件に関する情報を含む、最も最新のかつ正確なネットワークに関する情報の保守管理を行う際にトラフィックレポータを補助するものである。
【0019】
本明細書の一部に組み入れられ、本明細書の一部を形成する添付図面は、本発明の原理を開示する説明と共に、本発明の好ましい実施形態を例示するものである。
詳細な説明
次に、本発明の好ましい実施形態について詳細に言及する。本発明を限定するものではない、上記実施形態の実施例が添付図面に例示される。
【0020】
I. 地理上の所在位置の収集、決定および配信
1つの態様によれば、本発明はインターネットユーザが地理的にどこに位置する傾向があるかを特定するデータの収集、決定および配信を行うシステムと方法とに関する。インターネット上のアドレス指定方法(インターネットプロトコル(IP)アドレス)によって、世界中の任意の場所に配置されている任意の範囲のアドレスが処理されるため、任意の所定のマシーンまたはホストの実際の所在位置を決定することは簡単なタスクではない。
【0021】
A.地理上の所在位置データの収集
地理情報収集システム10が図1に図示されている。システム10は種々のインターネットルート指定用ツールを利用して、新たなターゲットホスト34のような、新しく発見されたインターネットホストの有望な配置を発見する際に補助を行うシステムである。特にシステム10は、ターゲットホスト34の地理上の所在位置を決定する際に、ホストとして知られているプログラム、nslookup、ping、tracerouteおよびwhoisを好適に利用する。本発明が上記プログラムに限定されるものではなく、同じ機能または類似の機能を提供する別のプログラムやシステムを利用するものであってもよいことを理解されたい。したがって、本発明は、地理上の所在位置を決定したり、IPアドレスの地理上の所在位置の確認に役立つ別の情報を提供したりする任意のシステムまたは方法を利用するものであってもよい。
【0022】
特に、nslookup、ping、tracerouteおよびwhoisは最適の情報ソースを提供するものである。pingとtracerouteの処理については、http://www.ietf.org/rfc/rfc2151.txtで入手可能なコメント(RFC)第2151号に対するインターネットエンジニアリングタスクフォース(IETF)要求で説明されている。また、nslookup(実際にはDNSルックアップ)については、http://www.ietf.org/rfclrfc2535.txtで入手可能なIETF RFC第2535号で説明されている。さらに、whoisについては、http://www.ietforg/rfc/rfc0954
.txtで入手可能なIETF RFC第954号で説明されている。ホスト、nslookup、ping、traceroute並びにwhoisの各々についての簡単な説明を以下に示す。これらコマンドの処理について説明を行う際、ソースホストとは、システム10が稼動しているマシーンを意味し、ターゲットホストとは、ターゲットホスト34などの、システム10のために探索を受けるマシーンを意味する。これらのコマンドについてのさらに詳細な説明は、UNIX(登録商標)システムで、RFC仕様またはマニュアルページを介して入手可能である。
【0023】
ホストは、ターゲットドメインのDNSサーバに対して照会を行い、ドメイン名に関する情報を収集する。例えば、“−l”オプションを用いた場合、“digitalenvoy.net”はdigitalenvoy.netの接尾辞を含むシステム10のすべてのホスト名を示すことになる。
【0024】
nslookupは、DNSルックアップシステムを用いてIPアドレスのホスト名への変換もしくは逆の変換も同様に行うコマンドである。
【0025】
pingは、ホストがオンラインになっていて、処理を行うことができるかどうかを調べる要求をターゲットホストへ送信するコマンドである。pingを用いて、ターゲットホストの状態を照会するためにとるべきルートを保存することも可能ではあるが、これは完全には信頼性の高いものであるとは言えない場合が多い。
【0026】
tracerouteはターゲットホストに達するためにとるべき正確なルートを決定するように設計される。tracerouteを利用して、現存しないまたは非オンラインのターゲットホストマシーンへの部分的ルートを決定することが可能である。このケースでは、ルートは或る一定ポイントまでトレースされ、そのポイント以降は、ターゲットホストへ向かう別の進行状態を保存することはできなくなる。tracerouteがシステム10へ出力した報告によって、ソースホストからターゲットホストまでに遭遇した個々のホストのIPアドレスが与えられる。tracerouteは、個々のホストが、上記のように構成されている場合、DNSを利用して遭遇した個々のホストに対してホスト名を与えることもできる。
【0027】
whoisは、インターネット上のサーバに対して照会を行い、ドメイン名またはIPアドレスのブロックに関連する情報の取得を行うことができる。
【0028】
システム10に対する処理の望ましい方法100について図1と2を参照しながら以下説明する。102でシステム10は希望する地理上の所在位置を表す新たなアドレスを受信する。システム10は、そのデータベース20の中に現在含まれていないか、再検証を必要とする新たなターゲットホストを受け入れる。システム10は、IPアドレスとホスト名の双方の提供が可能ではあるが、IPアドレスまたはホスト名のうちの一方だけを必要とする。103で、システム10はIPアドレスとホスト名の検証を行うことが望ましい。ただし、この検証は必ずしも行わなくてもよい。システム10はnslookupを利用して、ホスト名またはIPアドレスを取得し、これら複数の情報の双方が正しいことを検証する。次に、104で、システム10はターゲットホスト34がオンラインになっていて、処理を行うことが可能で、かつ、pingを介してこの機能を達成することが望ましいかどうかの判定を行う。ホスト34がオンラインになっていない場合、システム10は、後で分析を行うために、システム10の構成時の優先順位に応じてIPアドレスの再照会を行うことができる。
【0029】
106で、システム10はドメイン名の所有権を決定する。好適には、システム10が、whoisを利用して、実際にIPアドレスを所有する組織を決定することが望ましい
。この組織のアドレスは必ずしもIPアドレスの位置であるとはかぎらないが、この情報は、地理的に1つの位置にある場合が多いIPブロックを有するさらに小さな組織用として役に立つかもしれない。次いで、107で、システム10はターゲットホスト34に達するためにとられたルートを決定する。好適には、システム10がターゲットホスト34上でルート追跡を利用することが望ましい。108で、システム10はターゲットホスト34へのルートをとり、このルートを分析して、記憶済み位置データベース20に対する地理上の対応づけを行う。中間ホスト32などの、ターゲットホストへ通じるいずれかのホストが、データベース20に含まれていなかった場合、システム10は当該ホストの位置に関する決定を行う。
【0030】
次いで、109で、ターゲットホストの位置に関する決定が行われ、発見された新たなホストとターゲットホスト34とへ通じるホストの信頼レベルに基づいて、0〜100の信頼レベルが上記決定に対して割り当てられる。次いで、すべての新たなホストおよびこれらホストのそれぞれの地理上の所在位置が110でデータベース20に追加される。
【0031】
ホスト名が、国別トップレベルのドメイン形式(.us、.uk、など)のものである場合、システム10は国およびおそらく州、または県並びに発信元の都市に対する対応づけをまず行う。しかし、アドレスの発信が予想されることがドメインにより示されている場所からアドレスが発信していない場合、システム10はさらにIPアドレス用のインターネットルートの対応づけを行う必要がある。上記の例で論じられているように、.mdドメインはモルドバ共和国に割り当てられてはいるが、このドメインは米国では医学博士にきわめて人気のあるドメインである。したがって、システム10は、地理上の所在位置の決定時に国別トップレベルのドメイン形式に完全に依拠することはできない。
【0032】
方法100により、システム10は、国、州、および、ターゲットホスト34の発信元の都市の決定が可能となり、データベースでのエントリに対する信頼レベルの割当てを行うことが可能となる。この信頼レベルは以下の方法で割り当てられる。ダイアラを用いて、インターネットサービスプロバイダによりダイアルアップモデムプール(これについては以下でさらに詳細に説明する)に割り当てられたIPアドレス空間を決定するケースでは、入力される信頼レベルは100である。別の信頼レベルは近傍のエントリに基づいている。2つの同じ位置のエントリが未知のエントリを取り囲んでいる場合、その未知のエントリには同じ位置のエントリの平均信頼レベルが与えられる。例えば、単にwhoisによって決定された位置は35の信頼レベルを受けることが考えられる。
【0033】
一例として、ホスト“digitalenvoy.net”に対するサンプル探索について以下説明する。まず、システム10は102でターゲットホスト“digitalenvoy.net”を受信し、103で名称についてDNSルックアップを行う。コマンドnslookupはシステム10に対して以下を返す:

> nslookup digitalenvoy.net
名称:digitalenvoy.net
アドレス:209.153.199.15

次いで、104でシステム10はマシーンでpingを実行し、pingはシステム10に対して、ターゲットホスト34がオンラインになっていて、処理が可能かどうかを教える。“−c l”オプションは、pingに1つのパケットの送信のみを命じる。このオプションによって、確認が著しくスピードアップされる。pingはシステム10に対して以下を返す:

> ping−c1 digitalenvoy.net
ping digitalenvoy.net (209.153.199.15): 56 データバイト
209.1 53.199.15から64バイト:icmp seq=0 ttl=241 time=120.4 ms

−−− digitalenvoy.net ping 統計 −−−
1パケット送信済、1パケット受信済、0%パケット紛失
ラウンドトリップ min/avg/max=120.4/120.4/120.4 ms

次にシステム10は、106で“digitalenvoy.net”でwhoisを実行する。本例では、登録者がジョージア州にいることがwhoisによってシステム10に通知される。
【0034】

> whois digitalenvoy.net
登録者:
何某(DIGITALENVOY−DOM)
1234 住所 通り
アトランタ、ジョージア州33333
米国
ドメイン名:DIGTTALENVOY.NET
管理上の連絡先:
何某(SO0000) some@one.net
+1 404 555 5555
技術上の連絡先:
myDNS Support (MS311−ORG) support@MYDNS.COM
+1 (206) 374.2143
課金上の連絡先:
何某(SO0000) some@one.net
+1 404 555 5555

レコードの最後の更新日:1999年4月14日
レコードの作成日:1999年4月14日
データベースの最後の更新日:1999年4月22日 11:06:22 EDT

リスト順ドメインサーバ

NS1.MYDOMAIN.COM 209.153.199.2
NS2.MYDOMAIN.COM 209.153.199.3
NS3.MYDOMAIN.COM 209.153.199.4
NS4.MYDOMAIN.COM 209.153.199.5

107でシステム10はターゲットホスト34でルート追跡を実行する。“digitalenvoy.net”のtracerouteはシステム10に対して以下を返す:

> traceroute digitalenvoy.net
digitalenvoy.net(209.153.199.15)に対するtraceroute、最大30ホップ、40バイトパケット
1 130.207.47.1 (130.207.47.1) 6.269 ms 2.287 ms 4.027 ms
2 gatewayl−rtr.gatech.edu (130.207.244.1) 1.703 ms 1.672 ms 1.928 ms
3 fl−0.atlanta2−cr99.bbnplanet.net (192.221 26.2) 3.296 ms 3.051 ms 2.910 ms
4 fl−0.atlanta2−br2.bbnplanet.net (4.0.2.90) 3.000 ms 3.617 ms 3.632 ms
5 s4−0−0.atlantal−br2.bbnplanet.net (4.0.1.149) 4.076 ms s8−1−0.atlantal−br2.bbnplanet.net (4.0.2.157) 4.761 ms 4.740 ms6 h5−1−0.paloalto−br2.bbnplanet.net (4.0.3.142) 72.385 ms 71.635 ms 69.482 ms
7 p2−0.paloalto−nbr2.bbnplanet.net {4.0.2.197) 82.580 ms 83.476 ms 82.987 ms
8 p4−0.sanjosel−nbrl.bbnplanet.net (4.0.1.2) 79.299 ms 78.139 ms 80.416 ms
9 p1−0−0.sanjosel−br2.bbnplanet.net (4.0.1.82) 78.918 ms 78.406 ms 79.217 ms
10 NSanjose−core0.nap.net (207.112.242.253) 80.031 ms 78.506 ms 122.622 ms
11 NSeattlel−core0.nap.net (207.112.247.138) 115.104 ms 112.868 ms 114.678 ms
12 sea atm0.starcom−accesspoint.net (207.112.243.254) 112.639 ms 327.223 ms 173.847 ms
13 van−atm10.l0.starcom.net (209.153.195.49) 118.899 ms 116.603 ms 114.036 ms
14 hume.worldway.net (209.153.199.15) 118.098 ms * 114.571 ms

データベース20に記憶された地理上の所在位置を参照後、システム10は以下のように上記ホップを分析する:
【0035】
【表1】

上記エントリがデータベース20に含まれていること、および、確認のために或る人によるチェックを受けたことがあることを示す信頼レベル99がシステム10により割り当てられる。本発明の別の態様に基づいてアナリストなどの人が確認を行う場合があるが、
確認は、人工的知能システムあるいは他の任意の好適な追加システム、モジュール、デバイス、プログラム、エンティティなどにより行われる場合もある。システム10は、インターネットサービスプロバイダ(ISP)により確認された地理情報用として信頼レベル100を確保する。ISPは地理に対するIPアドレスの実際の対応付けをシステム10に提供することになる。また、ダイヤル呼出しISPを介してシステム10を用いて収集されたデータには、地理とPアドレス間での明確に限定された接続に起因して100の信頼レベルが与えられる。システム10がターゲットホスト34などの新たなターゲットホストを探索するとき、中間ホスト32などの上記ホストの多くは、繰り返し通過され、ISPによる確認やシステム分析による検証を受けない限り、これらホストの地理上の所在位置の信頼レベルは最大99まで上昇することになる。ホスト32の地理上の所在位置の個々の連続的確認に伴う設定量による方法などの複数の方法で上記信頼レベルを上げることが可能である。
【0036】
システム10は、ホストの地理上の所在位置に関して妥当な推測へ通じる共通の命名規定を利用する。例えば、そのホスト名の最初の部分に“sanjose”を含む任意のホストは、おそらくカリフォルニア州のサンホセに位置するか、カリフォルニア州のサンホセに在るシステムと接続されている。これらのルールのセットはデータベース20へのエントリとしてシステム10に実現される。データベース20は、変形された名称に対応する都市、国、地方、州などのような地理上の所在位置をリストするルックアップテーブルを含むものであってもよい。したがって、データベース20は、Sanfrancisco、SanfranおよびSfranciscoなどの、すべてカリフォルニア州の同じ都市サンフランシスコを表す複数のリストを含むことも可能である。
【0037】
しばしば1ブロックのIPアドレスが割り当てられ、組織に対して副次的に割り当てられる。例えば、ターゲットアドレス209.153.199.15を含むIPブロックを照会することができる。
【0038】

> whois 209.153.I99.15@whois.arin.net
[ whois. arin.net]
Starcom International Optics Corp. (NETBLK−STARCOM97) STARCOM97
209.153.192.0 − 209.153.255.255
WORLDWAY HOLDINGS INC. (NETBLK−WWAY−NET−01) WWAY−NET−01
209.153.199.0 − 209.153.199.255

この照会の結果から、システム10は、209.153.192.0から209.153.255.255までの大きなブロックがStarcom International Optics Corp.に割り当てられている旨を決定する。このブロック内で、Starcomによって、ワールトウェイホールディング社に対して209.153.199.0〜209.153.199.255ブロックが割り当てられている。このブロック(NETBLK−WWAY−NET−01)をさらに照会することにより、収集システム10はこの組織がどこに存在するかについて洞察を行う。このケースでは、下記に示すように当該組織はブリティッシュコロンビア州、バンクーバーに存在する。
【0039】

> whois NETBLK−WWAY−NET−01@whois.arin.net [whois.arin.net]
WORLDWAY HOLDINGS INC. (NETBLK−WWAY−NET−
01)
1336 West 15th Street
North Vancouver, BC V7L 2S8
CA

Netname: WWAY−NET−01
Netblock: 209.153.199.0 − 209.153.199.255

Coordinator:
WORLDWAY DNS (WD171−ORG−ARIN) dns@WO
RLDWAY.COM
+1 (604) 608.2997

ドメインシステム逆マッピングは下記で提供される:

NS1.MYDNS.COM 209.153.199.2
NS2.MYDNS.COM 209.153.199.3

トレースとIPブロックアドレス情報の組み合わせを用いて、収集システム10は、“digitalenvoy.net”がブリティッシュコロンビア州、バンクーバーに位置することにかなり確信を持つことができる。収集システム10が、人間を介在することなく自動的方法を用いてこのホストを“発見した”ため、システム10によって、該システムへ導かれるホストの信頼レベルよりもわずかに低い信頼レベルが好適に割り当てられる。また、システム10は、この組織と割り当てられたIPアドレスのサブブロックとに対応する地理上の所在位置が同じであるとは仮定していない。というのは、実際のIPアドレスが別の物理的位置にある場合があるからである。地理上の所在位置は簡単に異なる位置に変えることができる。というのは、IPブロックは要求する組織に割り当てられ、そのIPブロックがどこで使用されるかについての指示は何ら求められていないからである。
【0040】
ISPから地理上の所在位置を取得する方法111について図3を参照しながら以下説明する。112で収集システム10はISP用のアクセス番号を取得する。好ましい実施形態におけるアクセス番号はダイアルアップ番号であり、ISPとのアカウントを確立するなどの任意の適切な方法でこのアクセス番号を取得することができる。次に、113で、収集システム10はアクセス番号のうちの1つの番号を用いてISPと接続する。収集システム10がISPと通信を確立すると、ISPは、114で収集システム10が検出したIPアドレスを収集システム10に割り当てる。
【0041】
次いで、115の収集システム10は、サンプルターゲットホストへのルートを決定し、ルート追跡によってこのルートを好適に決定する。tracerouteの基礎並びにルートの最終宛先を形成する正確なターゲットホストは重要なものではないため、任意の適切なホストを使用することができる。116で、収集システム10はtracerouteが取得したルートを分析して、ISPと関連づけられたホストの所在位置を決定する。したがって、tracerouteにおける次のホップの地理上の所在位置を決定するために収集システム10は逆方向に調査を行う。117で、収集システム10はデータベース20に分析結果を記憶する。
【0042】
方法111を用いて、収集システム10はISPの補助によりIPアドレスを取得することができる。収集システム10がダイアルアップを行い、ISPとの接続を行うため、
収集システム10はISPにかかる負荷を軽減するような方法で好適に方法111を実行する。例えば、収集システム10は、夜間などのISPのオフピーク時間中に方法111を実行することができる。また、収集システム10は、10分間隔でISPとの接続を確立するなどのような、特定のISPと接続している周波数の制御を行うことができる。
【0043】
C.地理上の所在位置データの決定
図4を参照すると、別の態様によれば、本発明は収集システム10が作成したデータベース20を利用する地域別の決定システム30に関するものである。決定システム10は、地理上の所在位置に対する要求、および、ターゲットホスト34などの探索対象ホストのIPアドレスまたはホスト名に基づく要求を受け取る。地理情報の要求者40は、インターネット7を通じて、あるいは、別の何らかのネットワークを介して行われる対話型ネットワークセッションで、決定システム30に対する要求を出し、決定システム30からその応答を受け取る。収集システム10、データベース20および決定システム30はまとめて収集並びに決定システム50と考えることができる。
【0044】
決定システム30のための望ましい処理方法120について図5を参照しながら以下説明する。122で、システム30はエンティティの地理上の所在位置を求める要求を受け取り、上述のようにIPアドレスとドメイン名の一方もしくは双方を受け取る。123で、決定システム30は、情報がすでに取得されたものであるかどうかを調べるためにチェックを行いながら、与えられたデータを求めて地理上の所在位置用データベース20を探索する。123でIPアドレスを探索する場合、システム30はデータベース20内の同一の正確なIPアドレスリストか、当該IPアドレスを含むデータベース20内にリストされている1つの範囲またはブロック範囲のIPアドレスかのいずれかの発見も試みる。探索されているIPアドレスが或るブロックのアドレスの範囲内に在れば、決定システム30はそのIPアドレスを一致アドレスと考え、125で情報が検索され、126で地理情報が要求者40へ配信される。124でこの情報がデータベース20において入手できなかった場合、127で、システム30は要求者40に当該情報が既知のものではない旨を通知する。次いで、128で、システム30は未知のIPアドレスの地理上の所在位置を決定し、データベース20にこの結果を記憶する。125で、地理上の所在位置が未知であると宣言する代わりに、システム30は地理情報を決定して、要求者40へその情報を提供することも可能である。
【0045】
決定システム30はデータベース20内のIPアドレスと、ドメイン名との双方を探索する。単一のIPアドレスが複数のドメイン名を含む場合があるため、決定システム30は当該ドメイン名に近似する一致を探索する。例えば、ホスト名を探索するとき、システム30はデータベース20へのエントリに対してパターン一致を実行する。同じIPアドレスを示唆する一致が発見されたとき、決定システム30は当該エントリ用の地理データを要求者40へ返す。
【0046】
要求者40がIPアドレスとドメイン名の双方を与えた場合、曖昧さが生じる場合もあり、これら2つのピースのデータは異なるホストおよび異なる地理上の所在位置へ通じる。双方のデータピースが地理的に正確には一致しない場合、システム30は、最適の信頼レベルを表す情報によって好適に応答する。別例の場合ように、システム30は要求者40が定義したように応答してもよい。いくつかのオプションとして、決定システム30はデータが一致し、相互に整合したときにのみ報告を行うようにしてもよいし、矛盾する結果が生じた場合に情報を提供するようにしてもよいし、IPアドレスのみに基づいて地理情報を提供するようにしてもよいし、ホスト名のみに基づいて地理情報を提供するようにしてもよいし、あるいは、代わりに、アドレスとホスト名とが一致する度合に基づいて最善の推測を提供するようにしてもよい。
【0047】
要求者40が決定システム30へ送る要求のサンプル形式は下記のように与えられ、この場合、探索はホスト“digitalenvoy.net”に対して行われ、太字体の項目は地域別決定システム30からの応答である。
【0048】

server.digitalenvoy.netと接続中...
;digitalenvoy.net;
vancouver;british columbia;can;99;

この要求形式と決定システム30の出力形式は、アプリケーションに応じるものであってもよいこと、また、決して上記に示した例に限定されるものではないことは言うまでもない。
【0049】
D.地理上の所在位置データの配信
図6と図7を参照しながら、地理上の所在位置情報を配信するシステムについて以下説明する。図6に図示の第1の態様によれば、IPアドレスとドメイン名に関する地理情報が収集され、本システム50により決定される。ウェブサイト60はその訪問者の地理上の所在位置を望むことができ、収集並びに決定システム50からこの情報を知りたいと思う。ウェブサイト60は、ユーザ5の地理情報を取得するために、或るページと位置ターゲッタ64とを求めるユーザ5からの要求を受信するウェブサーバ62を備える。
【0050】
図7を参照しながら、図6に図示のネットワークの処理の望ましい方法130について以下説明する。132で、ウェブサーバ62はウェブページに対するユーザ5からの要求を受信する。133で、ウェブサーバ62は位置ターゲッタ64に照会を行い、次いで、該位置ターゲッタ64は、134で、収集並びに決定システム50にユーザの地理上の所在位置を照会する。好適には、位置ターゲッタ64がインターネット7を介して収集並びに決定システム50へ照会を送信することが望ましい。しかし、位置ターゲッタ64は、収集並びに決定システム50との直接接続を通じて、あるいは、別のネットワークを通じて行う別のルート指定によって上記照会の送信を行ってもよい。上述のように、収集並びに決定システム50はターゲットホストのIPアドレス、ホスト名、あるいはこれら双方を受け付け、次いでウェブサイト60が指定した形式でホストの地理上の所在位置を返信する。135で、位置ターゲッタは136で収集並びに決定システム50から地理上の所在位置を取得し、ユーザ5へ転送する情報が選択され、次いで、137でユーザ5へ転送される。この情報は、ユーザ5の地理上の所在位置に基づいて位置ターゲッタにより好適に選択される。或いは、位置ターゲッタ64は、ウェブサーバ62へ地理情報を転送してもよい。次いで、ウェブサーバ62は適正な情報を選択して、この情報をユーザ5へ転送する。以下さらに詳細に論じるように、地理上の所在位置は、どのようなコンテンツをユーザへ転送するか、もし何か存在する場合、どのような広告(コンテンツタイプ)をユーザ5へ転送するか、および/またはそのコンテンツの範囲に関係するものであってもよい。
【0051】
図8に示す別のオプションとして、ウェブサイト60は、ユーザ5に関する地理情報を記憶するローカルデータベース66と関連するものであってもよい。図9を参照すると、望ましい処理方法140は142でユーザ5から要求を受信するウェブサーバ62から始まる。143で、ウェブサーバ62は地理上の所在位置情報を位置ターゲッタ64’に照会する。図6と7の位置ターゲッタ64の処理130とは異なり、次に位置ターゲッタ64’はまず所望の地理情報に関連するローカルデータベース66のチェックを行う。所在位置情報がデータベース66内に存在しない場合、145で位置ターゲッタ64’は収集並びに決定システム50と関連するデータベース20に照会を行う。
【0052】
位置ターゲッタ64’が146で地理情報を取得した後、データベース66からローカルに行われるか、データベース20を通じて中央で行われるかのいずれかの方法で、ユーザ5の地理上の所在位置に基づいて所望の情報が選択される。上述のように、ここでも再び、位置ターゲッタ64’またはウェブサーバ62により上記選択処理を実行してもよい。いずれのイベントでも、148で選択情報がユーザ5へ転送される。
【0053】
位置ターゲッタ64と位置ターゲッタ64’の双方の場合、位置ターゲッタは地理上の所在位置照会の結果に基づいてHTMLコードを出力するように構成してもよい。HTMLコードベースのこの結果は、ウェブサイト60がユーザ5の所在位置に基づいて動的ウェブページを転送する場合、特に有用である。しかし、位置ターゲッタ64と位置ターゲッタ64’の出力はHTMLコードに限定されるものではなく、JPEG、GIFなどのような任意のタイプのコンテンツまたは出力を包含するものであることを理解されたい。
【0054】
ホスト“digitalenvoy.net”に対するサンプル探索をここで示す(太字体の項目は位置ターゲッタ64または64’からの応答である)。
【0055】

> distributionprogram digitalenvoy.net
vancouver;british columbia;can;99;

各種オプションが作動するかしないに関わらず、出力形式と異なるものであってもよいは言うまでもない。
【0056】
システム50がおそらく間違った地理上の所在位置を選択した場合、エンドユーザ5は、システム50がエンドユーザ5を特定した場所と比較して異なる地理上の所在位置を選ぶことができる。この情報が位置ターゲッタ64または64’へ返送された場合、位置ターゲッタ64または64’は決定システム30へこの情報を渡し、決定システム30は後で分析するためにこの情報をデータベース20に記憶する。この情報は完全には信頼することができないものであるため、収集並びに決定システム50はこの情報を分析と検証とを行い、おそらく人間の介在を選ぶ必要がある。
【0057】
E.プロキシサーバを介する地理上の所在位置の決定
ターゲットホスト上で地理情報を提供する際の1つの難点として、キャッシュプロキシサーバと関連する場合が挙げられる。キャッシュプロキシは別のネットワーククライアントに代って要求を行い、将来の要求のためにその結果を保存する。この処理はネットワークからの出力帯域幅の必要量を減らすことになるため、多くのインターネットアクセスプロバイダのポピュラーな選択肢となっている。。例えば、図10に図示のように、ユーザ5はプロキシサーバ36と関連づけられる。
【0058】
場合によっては、このキャッシュが望ましくない場合がある。というのは、これらキャッシュ内部のデータが陳腐になっていることがあるからである。ページにキャシュ不能のマークをつけることができる機能を備えることによりウェブはこの問題を修正している。不都合なことに、これらのキャシュ不能ページに対する要求は、あたかもエンドユーザのコンピュータ5の代わりにプロキシサーバ36から着信しているかのように依然として見える。しかし、ユーザ5の地理情報は頻繁に要求されることが考えられる。
【0059】
プロキシサーバ36と関連するユーザ5の地理情報を決定する方法150について以下図11を参照しながら説明する。好ましい実施形態では、ユーザ5はネットワークに対する直接のルート指定が可能なアクセスを行う。例えばネットワークアドレス変換を利用するシステムは作動しない。というのは、アドレスがグローバルなインターネットの一部で
はないからである。また、プロキシサーバ36によって任意のポートを介するアクセスが可能になり、これにより、すべてのポートで直接アクセスをブロックする企業ファイアウォールは機能しないことになる。最後に、ユーザ5はJava(登録商標)アップレットまたは同等のこのような機能をサポートするブラウザを備える必要がある。
【0060】
図11を参照して、152で、ユーザ5は、図6または図8に示すウェブサーバ60などのウェブサーバ60に対する要求を開始する。153で、プロキシサーバ36によりHTTP要求が処理され、プロキシのキャッシュ内ではヒットが見られない。というのは、本システム用のページにキャシュ不能がマークされているからである。ユーザ5に代って、プロキシサーバ38はウェブサーバ60と接続し、153でURLを要求する。154で、ウェブサーバ60は、ローカルデータベース60、または、収集並びに決定システム50を備えたデータベース20のいずれかを介して要求を受け取り、この要求がプロキシサーバ36から着信することを決定し、次いで、タグ付きのウェブページを155で選択して、ユーザ5のIPアドレスの決定を可能にする。このウェブページには、エンドユーザ5のIPアドレスの決定に使用可能なJava(登録商標)アプレットで好適にタグ付けが行われる。ウェブサーバ60には、当該要求を行うための一意のアプレットパラメータータグが組み込まれ、プロキシサーバ36へドキュメントが返信される。次いで、プロキシサーバ36は156でこのドキュメントをユーザ5へ転送する。
【0061】
次いで、157で、ユーザ5のブラウザはJava(登録商標)アプレットを実行し、一意のパラメーター・タグに沿って通過する。デフォルトで、アプレットが、アプレットの発生元であるホストにアクセスする権利を有しているため、ユーザ5のブラウザ上のアプレットは、ポート5000(但しこれに限定されるものではない)などでクライアントウェブサーバ60に対する直接接続を開く。ウェブサーバ60は、別々のサーバープログラムなどを通して、ポート5000での接続をリスンし、ポート5000での接続を受け入れる。次いで、158でJava(登録商標)アプレットはウェブサーバ60へ一意のパラメーター・タグを返送する。接続が直接的であるため、159でウェブサーバ60はユーザ5用の正しいIPアドレスを決定することが可能となり、プロキシサーバ38から将来要求が着信したとき、ウェブサーバ60は、セッションタグを当該IPアドレスと関連づけることが可能となる。
【0062】
代替例として、155で、ウェブサーバ155はJava(登録商標)アプレットを含むウェブページをそのまま転送してもよい。上述の実施形態の場合と同様、Java(登録商標)アプレットを含むウェブページは156でプロキシサーバへ転送され、ユーザ5は157でウェブサーバ60と接続する。158では、ウェブサーバ60がロードするように命じたものでJava(登録商標)アプレットがユーザのブラウザを再ロードするという点で、本発明のこの実施形態に準拠するJava(登録商標)アプレットは上述のJava(登録商標)アプレットとは異なるものである。本発明のこの実施形態に準拠するJava(登録商標)アプレットは、複数の一意のパラメーター・タグを処理し、ソートする必要性を軽減する一意のパラメーター・タグと関連づけられるものではない。代わりに、本発明のこの態様の場合、Java(登録商標)アプレットがウェブサーバ60と接続したとき、159のウェブサーバ60はユーザ5のIPアドレスと地理上の所在位置とを決定するものである。
【0063】
II.インターネットの訪問者の地理上の所在位置に基づくインターネットサイトの特別仕立て
ウェブサイト60は、インターネットユーザ5の地理上の所在位置またはインターネット接続スピードに基づいてインターネットサイトの特別仕立てを行うことができる。ユーザ5がインターネットサイト60を訪問するとき、インターネットサイト60は、ローカルデータベース60または中央データベース20などのデータベースにインターネットを
利用して照会を行う。上記データベースは、その時、インターネットサイト60上のユーザの“ヒット”から導き出されるユーザのIPアドレスと別の関連情報とに基づいてユーザの地理上の所在位置および/またはインターネット接続スピードを返送する。この情報はルートからユーザ5のマシーンへ導き出されるものであってもよいし、ユーザ5のホスト名、SNMPを介するおよび/またはNTPを介するユーザのマシーン5へのルートに沿うホストであってもよい(但しこれらの技法に限定されるものではない)。この情報に基づいて、インターネットサイト60はユーザへ提示するコンテンツおよび/または広告の特別仕立てを行うことができる。この特別仕立ては、ユーザの所在位置に基づいてインターネットサイトの外国語をユーザの母国語へ変えたり、地理情報並びに別のデータベースから受信した他の情報に基づいてインターネットサイトで示す製品または広告を変えたり、あるいは要求のソースに基づいてアクセスを阻止したり(すなわち学校からの“アダルト”コンテンツサイト拒絶要求など)するステップを含むものであってもよい(但しこれらに限定されるものではない)。この特別仕立ては、ユーザ用としていくつかの別のスクリーンまたはサイトを備えることにより、また、ウェブサーバ62あるいは位置ターゲッタ64または64’にユーザの地理情報に基づいて適切な情報を動的に選択させることにより行うことができる。地理情報を分析して、潜在的インターネットサイトの広告主と外部のコンテンツプロバイダに対してサイトの効果的なマーケッティングを行ったり、あるいは、十分な帯域幅を持つユーザへメディアリッチなコンテンツを提供したりすることができる。
【0064】
特別仕立てを行う方法には、インターネットユーザのマシーン5へ戻るパス・ルートのトレーシングを行うステップが含まれる。このパス・ルートにおけるすべてのホストの所在位置が決定され、インターネットユーザのマシーンの所在位置の確率の決定が行われ、ホストに対してこのような情報を直接照会することにより(例えば、SNMPまたはNTPを用いることにより(但しこれらに限定されるわけではない))、インターネットユーザのマシーンとつながり、インターネットユーザのマシーンを備えるパス・ルートでのホスト(このホストの地理上の所在位置とリンクされていても、いなくてもよい)に関する別の情報が決定される。或いは、IPアドレスとホスト名とに関する情報を記憶する、更新可能な完全なデータベースが存在する。次いで、ユーザに関する情報が送信されることになる遠隔地のソースにより上記IPアドレスとホスト名とに照会することが可能となる。
【0065】
ウェブサイト60は、上記方法または処理から決定されるようなインターネットユーザ5の地理上の所在位置に基づいてインターネットコンテンツおよび/または広告を動的に変更する。ウェブサイト60は、ユーザ5がウェブサイト60にアクセスする結果としてデータベースが送信する情報に応じて、いくつかの予め設計された別のスクリーン、プレゼンテーション、またはミラーサイトのうちの1つを提示する。
【0066】
上述のように、ウェブサーバ62または位置ターゲッタ64または64’のいずれかの手段により、地理上の所在位置に基づいてユーザ5へ転送する適正な情報の選択を実行することができる。いずれの場合にせよ、ウェブサイトはインターネットコンテンツを動的に適合させ、このコンテンツの特別仕立てを行って、インターネットユーザ5の地理上の所在位置および/または接続スピードに基づいてインターネットユーザ5の要望に合わせるようにすることが可能である。
【0067】
別のオプションとして、ウェブサイト60は、インターネット広告を動的に適合させ、インターネットユーザの地理上の所在位置および/または接続スピードに基づいて特定のインターネットユーザをターゲットにするために上記インターネット広告の特別仕立てを行うことが可能である。さらに、ウェブサイト60は、インターネットコンテンツおよび/または広告を動的に適合させて、インターネットユーザ5の地理上の所在位置により決
定できるインターネットユーザ5の母国語への上記広告の特別仕立てを行うことが可能である。また、ウェブサイト60は、インターネットユーザの地理上の所在位置、IPアドレス、ホスト名および/または接続スピードに基づいて、インターネットサイト60や特定のウェブページに対するアクセスをサイト60上で選択的に可能にしたり、不能にしたりすることによりアクセスを制御することが可能である。別例として、ウェブサイトは、インターネットユーザ5による訪問を分析して、インターネットサイトのマーケティング時の補助となるインターネットユーザ5の地域別および/または接続スピードの低下を編集することができる。
【0068】
A.クレジットカードの不正使用
情報のターゲットをユーザに絞るための地理上の所在位置情報に併せて、ウェブサイト60または収集並びに決定システム50は、生じる可能性のあるオンラインクレジットカードの不正使用のケースを検出するメカニズムをウェブサイト所有者に提供することができる。ユーザ5が情報を入力して、オンライン注文を終了するとき、ユーザは出荷先と料金請求先と示す必要がある。一般に、この情報はユーザ5の物理的所在位置に対する有効性の確認とすることはできない。本発明を通じて、ウェブサイト60はユーザ5の地理上の所在位置を決定する。ユーザ5が、存在しないことが決定された所在位置を入力した場合、不正使用の原因である可能性がある。この状況は、その注文要求が合法的なものであるかどうかを判定するためにウェブサイト所有者によるフォローを必要とすることになる。
【0069】
B.トラフィック管理
クレジットカードの不正使用を検出するための地理情報の利用の他に、インターネット7上でのトラフィックの管理時に地理情報を利用することも可能である。例えば、図12(A)を参照すると、トラフィックマネージャ70にはそのユーザまたは訪問者5の地理情報を取得できるという利点がある。トラフィックマネージャ70は、ローカルデータベース60を採用してもよいし、図示してはいないが、収集並びに決定システム50と接続してもよい。トラフィックマネージャ70がユーザ5の地理上の所在位置を検出した後、トラフィックマネージャ70は、ウェブサーバA74またはウェブサーバB72などの最も望ましいウェブサーバへユーザ5の要求を送る。例えば、ユーザ5がアトランタにいる場合、トラフィックマネージャ70は、アトランタにベースを置くウェブサーバA74へユーザの要求を送ってもよい。一方、ユーザ5がサンフランシスコにいる場合、トラフィックマネージャ70は、サンフランシスコに配置されるウェブサーバB72へユーザ5を送ることになる。このようにして、トラフィックマネージャ70が中間ホスト間でのトラフィックを減らし、最も近いウェブサーバへトラフィックを送ることができる。
【0070】
最も効率的に最適サーバを決定して、ネットワーク上のユーザからの要求に対して応答するために、トラフィックマネージャ70は好適にインターネットのマップなどのネットワークマップ全体を含むことが望ましい。上記マップは、データベース60、インターネットユーザの地理上の所在位置と同じデータベース20または別個のデータベースに記憶してもよい。トラフィックマネージャ70が最も望ましいサーバへトラフィックのインテリジェントなルート指定を行うことができるように、ネットワークのこのマップにはネットワーク上のできるだけ多くの情報が理想的に含まれている。ネットワークに関する情報には、(1)ネットワーク内のルータ、スイッチ、ハブ、ホスト、および別のノード(まとめて“ノード”とする)と;(2)ノードの地理上の所在位置と;(3)個々のノードで利用可能な総帯域幅と;(3)個々のノードにおける利用可能な容量と;(4)ノード間でのトラフィックパターンと;(5)ノード間での待ち時間およびスピードと;(6)どのノードがクラッシュしたかや、どのリンクが保守管理を受けているかなどの、ノードとノード間自体でのリンクの健康状態または状態と;7)パフォーマンス並びに過去のパフォーマンス、現在のデータ、将来のイベントについての情報について考慮するモデル化
された予測パフォーマンスにおける毎日の、季節毎の、毎年のトレンドなどのネットワーク、ノード並びにリンクの履歴パフォーマンスおよび予測パフォーマンスと;が含まれる(但しこれらに限定されるものではない)。データベースに記憶された考え得る情報を示すこのリストは例示のリストにすぎないこと、並びに、このデータベースがすべての情報よりも少ない情報並びに別のピースのデータを含むことができることを理解されたい。
【0071】
当業者であれば理解できるように、任意の広いネットワーク用として、ネットワークの上記マップを持つ包括的なデータベースは急速に管理不能になる可能性があり、最適応答ソースの発見にはかなりの量の時間とリソースとを要することになる。上記理想的ルートの決定に費やされる時間によって、より迅速なサーバへトラフィックのルート指定を行うことにより実現される任意の利得の非常に簡単なオフセットが可能となる。実際的理由によって、トラフィックマネージャ70とデータベースとは、ネットワークの何らかの近似マッピングまたは部分的マッピングを行うことが望ましい。例えば、インターネットなどのネットワーク全体の完全なマップまたは半分完全なマップは最も関連のあるデータから形成することができる。これによってトラフィックマネージャ70はユーザに対して効率良く応答を転送することが可能となる。
【0072】
ネットワークに関する情報は任意の数の方法で取得することが可能である。基幹ネットワークとインフラストラクチャのマップを完成する1つの方法について図12(B)を参照しながら以下説明する。アナライザとして図示する1組のマシーンが、ホスト間の相互接続を分析し、収集済みの知的機能を1または2以上のデータベースに記憶するために配備されている。アナライザは任意のツールを利用して、ネットワーク用ツールtracerouteなどの知的機能を取得することができ、この知的機能には個々のホスト、並びに、個々のノードが備えている、別のノードとの直接リンクが含まれる。アナライザは、2つの相互に接続されたノード間での待ち時間を決定し、2つのノード間での相互接続のスピードを決定するtraceroute情報を受け取る。traceroute情報はユーザの地理上の所在位置を決定する分析の副産物であるため、収集システム、決定システム、または収集並びに決定システムはアナライザとして機能することができる。或いは、アナライザは別個のシステムまたはマシーンとして存在するものであってもよい。
【0073】
図12(B)に図示の例では、個々に自分のアドレスを持つ100名のユーザが単一のサーバ(マシーンA)と接続され、さらに、個々に自分のアドレスを持つ100名の別のユーザが単一のサーバ(マシーンC)と接続されている。ネットワークをモニタする際、アナライザはマシーンAがマシーンBへすべての要求を常に転送することを決定し、マシーンCが常にマシーンBへすべての要求を転送する。次いで、マシーンBは、常に、マシーンAからの要求、並びにマシーンCからの要求をマシーンDへ転送する。次いで、マシーンDは複数のルートを有し、このルートを通じてマシーンDはユーザ要求の送信が可能となる。マッピング時に、ネットワークは、AまたはCのいずれかと接続されたユーザからの任意の要求に対する応答をマシーンDを介してルート指定するため、アナライザはマシーンDのアドレスを有するものとして、マシーンAまたはC上の200名すべてのユーザの処理を行うことになる。マシーンA、B、Cの位置と相互の接続を分析する必要がなくなることにより、アナライザにとって、管理が可能な近似値に設定される問題が減ることになる。この分析は、ネットワーク上で効率的良くルート指定された情報を要求するすべてのアドレスに対して実行可能である。
【0074】
上述の例では、マシーンAとCとはそれらの要求のすべてをマシーンBへ転送し、マシーンBは要求のすべてをマシーンDへ転送した。その結果、アナライザは、ユーザがすべてマシーンDと接続されるモデルまで効果的かつ正確にこの組の相互接続を減らすことができた。しかし、実際には、マシーンAとCは、別のマシーンへまたは相互に何らかのトラフィックを送信してもよく、そして、マシーンBはマシーンD以外のマシーンへ何らか
のトラフィックを送信してもよい。それにもかかわらず、確率と統計とを通じて、アナライザは最も有望な進行パス・ルートを決定し、対応する近似またはネットワークの単純化を図ることができる。
【0075】
トラフィックマネージャ70は、アナライザを介する以外の方法でネットワーク上で知的機能を獲得することができる。例えば、ネットワークを形成する構成要素またはネットワークの管理者はノードとネットワーク全体とをモニタし、パフォーマンスデータをトラフィックマネージャ70へ出力することができる。また、トラフィックマネージャ70は、別のシステムを介するなどの手段で第三者から上記情報を取得し、上記知的機能を収集することが可能となる。
【0076】
上述のように、トラフィックマネージャ70は、ユーザとウェブサイトなどの発信元と宛先ポイントとの地理上の所在位置に基づいて、並びに、中間ノードの地理上の所在位置にも基づいてネットワーク上でトラフィックのルート指定を行うことができる。時として、ユーザの要求に応答するあるいはこの要求を処理するのに、ユーザに最も近いサーバまたはノードが必ずしも最適サーバに対応するとはかぎらないことがある。例えば、トラフィックは、クラッシュしたサーバやノード、追加の利用可能な帯域幅を持っていないサーバやノード、割り込みがかけられたまたは低速の中間ネットワークリンクを持つサーバやノードへは送られないことが望ましい。サーバまたはノードのクラッシュが生じたの場合、アナライザは継続的にすべてのサーバをモニタして、最適のパフォーマンスを提供することを保証する。低速のまたはダウンしたネットワークリンクの場合、アナライザは、どのサーバを利用するかの決定にインパクトを与える可能性があるすべてのリンクのモニタを行う。最後に、アナライザは、応答するサーバに対する利用可能な総帯域幅とユーザの接続スピードとを測定する。接続スピードに対するIPアドレスのマッピングの結果、ユーザが有する利用可能な帯域幅を知ることにより、トラフィックマネージャ70は、利用可能な十分な帯域幅を持つサーバへユーザを送り、当該ユーザを正しく調整することが可能となる。したがって、エンドポイントと中間ノードの地理上の所在位置について考慮はされるが、たとえ遠隔地に在るものであっても、別のサーバの方がより高速な、より好適な、あるいは、より信頼性の高いサービスを提供することが可能な場合、トラフィックマネージャ70は必ずしも最も近いサーバに対してトラフィックのルート指定を行うとはかぎらない。
【0077】
トラフィックマネージャ70はネットワーク内の任意の場所に配置することができる。1例として、トラフィックマネージャ70はDNSサービスと関連づけることができる。DNSサービスとして利用する場合、コンテンツプロバイダはDNSサービスとのインタフェースを行って、どのような条件と状況で特定のサーバへ特定ユーザを送るかを定義する。例えば、これらの条件は、ユーザの地理上の所在位置、ユーザのネットワークの所在位置、ユーザと利用可能なサーバ間の帯域幅と待ち時間、ユーザの利用可能な帯域幅、サーバの利用可能な帯域幅、1日の時刻に基づくものである。次いで、ユーザは、コンテンツプロバイダにより設定された判断基準に基づいて自分のプロファイルに最もよく適合するサーバへ送られる。すべての新たな要求が名称分解処理を受け、それによって要求時点に適正なサーバへユーザが送られるように、DNS応答は生存時間(TTL)0で送信されることになる。トラフィックマネージャ70をDSNサービスと関連づける本例では、ウェブサーバA74とウェブサーバB72とは同じウェブサイトと関連するミラー処理を施したウェブサーバを備えることができる。
【0078】
別の例として、トラフィックマネージャ70は、インターネット内でサーバまたはノードと関連して、リダイレクトを行うことができる。HTTPリダイレクトの本例では、ユーザをどこへ送るかを決定する際に同じ判断基準が用いられる。1つの相違点として、トラフィックマネージャ70が、コンテンツプロバイダなどのサイト用フロントエンドとし
て機能し、ユーザとの接触を行った後、このマシーンから適正なマシーンへユーザのリダイレクトを行うという点が挙げられる。DNSの例の場合と同様、トラフィックマネージャ70は、サーバ74と72における利用可能な帯域幅、サーバ74と72の接続スピード、地理上の所在位置、負荷バランス、などに基づいてリダイレクトを実行することができる。
【0079】
トラフィックマネージャ70は、個々のユーザアクセスを行うために上記分析を実行して正しいサーバを決定する。この一連の分析を行うことにより、ユーザは最適の可能なパフォーマンスを保証されることになる。
【0080】
C.トラフィックレポートと管理
上述のように、図12(A)と12(B)とを参照すると、トラフィックマネージャ70にはインターネットまたは別のネットワークに関する情報が含まれ、この情報には、ノードと、ノードの地理上の所在位置と、個々のノードにおける利用可能な総帯域幅と、個々のノードにおける利用可能な容量と、ノード間でのトラフィックパターンと、ノード間での待ち時間およびスピードと、ノードとノード間自体でのリンクの健康状態または状態と、ノード並びにリンクの履歴パフォーマンスと予測パフォーマンスと、に関する情報が含まれる。この情報は、ネットワークのマップなどの形で、トラフィックマネージャと関連するデータベースに記憶してもよい。また、上述のように、この情報は複数の方法で取得することができる。これらの方法には、トラフィックマネージャ70自体の努力による、あるいは、別のシステムによる、図12(B)に描かれているアナライザの利用が含まれる。
【0081】
また、上述のように、このネットワーク情報は複数の方法で利用することができる。例えば、最適のルートまたは最も効率的なルートによってトラフィックを送る際に上記情報を利用してもよい。ルートの選択時に、トラフィックマネージャ70は、発信元と宛先ポイントの地理上の所在位置、中間ノードの地理上の所在位置、種々のノードにおける利用可能な帯域幅、ノードの状態、などにおける係数・ファクタ・要因とすることができる。本質的に、トラフィックマネージャ70は、ネットワークに関する任意のまたはすべての情報、発信元または宛先ポイント、あるいは任意の中間ノードまたはネットワークを利用してトラフィックのルート指定を行うことが可能である。さらに、トラフィックマネージャ70は、1または2以上のノード、発信元または宛先ポイントに、あるいはDNSサービスの一部を含むネットワーク内の任意の場所に配置されたものであってもよい。
【0082】
トラフィックマネージャ70で利用可能な情報は通常のネットワークトラフィック条件を反映する。これらの条件は、過去1日、1週間、1月または1年などの期間にわたる平均値に基づくものであってもよい。図12(C)に図示のような本発明の1つの態様によれば、トラフィックレポータ79はリアルタイムトラフィック条件でトラフィックマネージャ70と交信を行う。トラフィックレポータ79は周期的なトラフィックレポートまたは時折のトラフィックレポートを好適にトラフィックマネージャへ送信して、当該トラフィックマネージャ70に対してネットワーク内でのトラフィック条件に関する更新を行う。さらに、トラフィックマネージャ70はローカルな条件をモニタし、トラフィックレポータ79に対する更新を行う。トラフィックレポータ79は、図12(B)を参照しながら説明したアナライザを介するなどの、トラフィックレポータ79自身またはトラフィックマネージャ70以外のソースから、トラフィック条件および別のネットワーク情報に関する情報を取得する。トラフィックレポータ79に関する追加の詳細情報およびトラフィックマネージャ70の動作について図12(D)と12(E)を参照しながら以下説明する。
【0083】
図12(D)を参照しながら、トラフィックマネージャ70の動作方法250について
以下説明する。252で、トラフィックマネージャ70は手元にある情報に基づいてルーティング指示を出力する。トラフィックマネージャ70は、図12(A)と12(B)を参照しながら上述したような任意の好適な方法でルーティング指示を出力する。例えば、トラフィックマネージャ70は、ネットワークのデータベースまたはマップを好適に有し、ネットワーク状態とトラフィックとに関する情報を有する。254で、トラフィックマネージャ70は、トラフィックレポータ79から受信報告があるかどうかを判定する。トラフィックレポートを受信していた場合、トラフィックマネージャ70は、256で最新のトラフィック条件を用いて自身のデータベースを更新する。
【0084】
258で、トラフィックマネージャ70は、自身のデータベースの保守管理中に通常のコースの処理でローカルトラフィック条件を好適にモニタする。260で、トラフィックマネージャ70が何らかの著しい変化を検出した場合、トラフィックマネージャ70はトラフィックレポータ79に対してこれらの変化について報告を行う。トラフィックマネージャ70は、現在のローカルトラフィック条件をデータベースに記憶された条件と比較して、上記の変化がいくつかの点で著しいものであるかどうかを判定する。トラフィックマネージャ70は、上記変化を何らかの変化に照らして、ある絶対値を超える変化に照らして、あるいは、上記変化が何らかの割合を上回った場合に著しいものであると判定することができる。次いで、トラフィックマネージャ70は、252で、そのデータベース内の情報に基づいてルーティング指示を出力し続ける。
【0085】
256でデータベースの更新と保守管理とを行う際に、トラフィックマネージャ70はネットワーク状態を示す何らかの履歴測定値を好適に有し、トラフィックレポート内の受信データの若干またはすべてをリアルタイムトラフィック条件として保存する。トラフィック条件の履歴測定値はトラフィック条件の決定時に、したがって、ルーティング指示の出力時にデフォルトにより利用される。トラフィックマネージャ70は、トラフィックレポータ79を介して提供されるリアルタイムトラフィック条件を好適に参照して、デフォルトのデータセットの利用時に例外が生じるかどうかの判定を行う。したがって、252におけるトラフィックマネージャ70は、データベースに記憶されたデフォルトデータを検査し、次いで、第2に、このデフォルトデータから導き出される予備のセットのルーティング指示の変更時に、トラフィックレポータ79から出される何らかのトラフィックレポートが特定の要求時に関係があるかどうか、あるいは、該トラフィックレポートが関係があるかどうかを見るために調べるという2段階の分析を実行する。
【0086】
図12(E)を参照しながらトラフィックレポータ79の動作方法280について以下説明する。282で、トラフィックレポータ79はトラフィックマネージャ70から任意のトラフィックレポートを受信する。上述のように、トラフィックマネージャ70により作成されたこれらのトラフィックレポートはトラフィックマネージャ70自体により検出されるローカルトラフィックのリアルタイムの変化に関連するものであってもよい。282で、トラフィックレポータ79は、アナライザなどの別のソースを介して、ネットワーク情報と、トラフィック条件70に関するその他の上記のような情報とを受信することができる。286で、トラフィックレポータ79はネットワーク上で自身の分析を実施して応答時間、トラフィックの輻輳状態、利用可能な帯域幅、利用可能な容量、トラフィックパターン、待ち時間とスピード、リンクまたはノードの健康状態または状態、などを決定する。ネットワークのデータベースまたはマップの更新時に、282または286で収集されたデータのすべては284で利用される。
【0087】
トラフィックレポータ79は、ネットワークでリアルタイム条件のデータベースの保守管理を行い、さらに、履歴測定値の何らかのバージョンの保守管理も好適に行う。288で、トラフィックレポータ79はリアルタイムトラフィック条件を履歴測定値と比較して、リアルタイムトラフィック条件が著しい変化を表しているかどうかの判定を行う。トラ
フィックマネージャ70の場合と同様、トラフィックレポータ79は、何らかの条件の変化、変化の絶対値、または変化の割合における検査を含めて、リアルタイム条件が複数の方法でニュースに値するものであるかどうかを判定することができる。リアルタイムトラフィック条件が重要なものである場合、トラフィックレポータ79はトラフィックマネージャ70へトラフィックレポートを送信し、その結果これらのレポートは最新のトラフィック条件という利点を有することができる。トラフィックレポートの送信時に、290で、トラフィックレポータ79は、トラフィックマネージャ70が配置されている地理上の領域へ特別に仕立てられたトラフィックレポートを送信することが可能となる。言い換えれば、トラフィックレポータ79は、トラフィックマネージャ70に関係のないネットワークの領域または部分に対してリアルタイムのトラフィックレポートを送信せずに、当該地理上の領域すなわちネットワークエリアと関連するトラフィックマネージャ70へトラフィックレポートを送信する。
【0088】
トラフィックマネージャ70にトラフィック条件をモニタさせ、トラフィック条件に関する報告を行わせる1つの利点として、さらに精密な事前評価をトラフィック条件から行うことができるという点が挙げられる。トラフィックマネージャ70の数に関して、および、ネットワークを通じるトラフィックマネージャ70の分散に関してトラフィック条件の精度と事前評価とは向上する。例えば、図12(C)はアラスカを除く米国大陸を通じて分散された7つのトラフィックマネージャ70を示す図である。この図では、トラフィックマネージャ70は、北東部、南東部、中西部、南西、北西部、西部並びにロッキー山脈地域などの異なる領域を通じて分散される。トラフィックマネージャ70のこの表示は単に一例にすぎない。実際には、トラフィックマネージャ70は領域に基づく方式よりも好適にポピュレートされる。トラフィックマネージャ70を単に上記領域レベルで分散するだけであれば、トラフィックレポータ79は、トラフィックマネージャ70から該レポータ79が個々のドメインの範囲内で受信することができる限定された情報量を含むことになる。多数のトラフィックマネージャ70を個々のドメインの範囲内に分散して、トラフィックレポータ79は、地理上の所在位置に関する、または、個々のドメイン内のさらに耳ざわりな音のする(granular)領域に関する補足情報から利益が得られるだけでなく、トラフィックマネージャ70からの報告の精度を保証するためにクロスチェックを行う能力も有している。したがって、トラフィックレポートを収集する際に、顧客のサイトと関連づけられたトラフィックマネージャがトラフィックレポータ79を補助していることを考慮して、さらに多くの顧客が上記トラフィックレポートに申し込んだとき、顧客は、有用でかつ正確な情報をトラフィックレポータ79から得ることができる。
【0089】
III.プロファイルサーバとプロファイル発見サーバ
上述のように、収集並びに決定システム50はユーザ5に関する地理情報を記憶し、ウェブサイト60または別の要求者40へこの情報を提供することができる。本発明の別の態様によれば、ウェブサイト60および別の要求者40からの要求に基づいて、ユーザ5の地理上の所在位置以外の情報が追跡される。図13を参照すると、プロファイルサーバ80はインターネットを介してウェブサイト60と接続され、さらに、プロファイル発見サーバ90と接続されている。このプロファイル発見サーバ90も、やはりインターネットを介したり、別のネットワーク接続を介したり、あるいは直接接続されていたりするものであってもよい。プロファイルサーバ80は、要求ハンドラ82、データベースサーバエンジン83およびデータベース84を備えている。以下の説明からさらに明らかになるように、データベース84には、地勢データベース84A、認証データベース84B、ネットワークスピードデータベース84C、プロファイルデータベース84D、およびインターフェースデータベース84Eが含まれる。プロファイル発見サーバ90には、発見エンジン92、プロファイラ93、およびデータベース94が含まれる。データベース94には、一般的なエリア名称データベース94A、広域エリア構造データベース94B、およびMACアドレス所有者データベース94Cが含まれる。
【0090】
A.プロファイラ
一般に、プロファイルサーバ80とプロファイル発見サーバ90とは、種々のウェブサイト60および別の要求者40とのインターネットユーザのインタラクションに基づいて、特定のIPアドレスに関する情報を収集するものである。この情報には、訪問されたウェブサイト60のタイプ、スポーツサイトなどのヒットしたページ、オークションサイト、ニュースサイト、eコマースサイト、地理情報、帯域幅情報、およびウェブサイト60で過ごした時間が含まれる(但しこれらに限定されるものではない)。この情報のすべてはデータベース84へ戻るネットワークでウェブサイト60から送出される。この情報はIPアドレスによって高性能データベース84に記憶され、訪問されたオンサイト60および個々のサイト60の範囲内で行われたアクションに基づいて、IPアドレスの精巧なプロファイルが形成される。このプロファイルは、所定のカテゴリに準じる一連の優先順位として、または、所定のカテゴリとは反対の一連の優先順位として記憶される。ウェブサイト60とユーザ5のブラウザ間でプロファイルの保守管理を行うためのインタラクションは必ずしも必要ではない。このプロファイリング方法は、非常に好ましくないものであることがユーザにより知られている何らかのクッキの利用を必要とするものではないことが重要である。ネットワークトポロジにより誘起される困難に起因してクッキは好ましいものではないが、クッキを用いて或るユーザ5のプライバシ問題点について注意深く考慮を払った後に、ユーザ5の追跡を行ってもよい。
【0091】
ユーザ5がネットワークでウェブサイト60にアクセスするとき、ユーザのIPアドレス60に関するプロファイルされた情報が、データベース84からウェブサイト60に在る位置ターゲッタ64または64’へ送信される。以上説明したように、位置ターゲッタ64または64’あるいはウェブサーバ62により、当該ユーザ5の詳細なプロファイルに基づいてウェブサイト60に予め設定された構成またはページをユーザ5に対して動的に示すことが可能となる。さらに、現時点のユーザ5の優先順位に対応するユーザ5の優先順位を用いて、現時点のユーザ5が閲覧することが望ましいようなコンテンツを予測することができる。プロファイルされた情報は以下のものを含むことも可能である(但しこれらに限定されるものではない):地理上の所在位置、インターネットとの接続スピード、ニュース、天候、スポーツ、娯楽、スポーツ商品、衣料商品、などのうちのいずれかに対する好き/嫌いの傾向。
【0092】
一例として、アリスとボブという名前の2人のユーザがいるとする。アリスはウェブサイト、www.somerandomsite.comを訪問する。このサイトは、server.digitalenvoy.netなどのプロファイルサーバ80に、アリスの発信地と彼女の好き/嫌いについて問い合わせる。データベース84はアリスについてのレコードを持っていないが、地勢データベース84Aから彼女がジョージア州アトランタから発信していることを知り、ウェブサイトにその趣旨を通知する。アリスの地理情報を利用して、ウェブサイトは、彼女の地理上の所在位置に関連する特別に仕立てられたウェブページをアリスに送信する。例えば、そのウェブページにはアトランタの天気予報やアトランタに関連するニュースの見出しが含まれる。アリスはウェブサイトの訪問を続けて、サイトから傘を購入し、次いで、彼女の訪問を終了する。ウェブサイトは、プロファイルサーバ80とデータベース84とにアリスがサイトから傘を購入したことを知らせる。次いで、ボブがサイトwww.somerandomsite.comを訪問する。サイトは再びserver.digitalenvoy.netなどのプロファイルサーバ80にボブに関する問い合わせを行う。サーバ80は、ボブに関する情報を求めてデータベース84を覗いて見るが、何も発見しない。しかし、サーバ80は地勢データベース84Aを再度覗いて見る。そして、ボブがジョージア州アトランタから発信していると判定する。また、アリスから部分的に収集され、プロファイルデータベース84Dに記憶されたデータに基づいて、プロファイルサーバ80はジョージア州アトランタの人々は傘を買
うのが好きであるかもしれないと推論する。サイトはボブの地理情報、並びに、アトランタの人々が傘を買う傾向を有するという事実を利用して、天候とニュースなどのアトランタ情報を持つウェブページと、傘を買うのはいかがですかという提案とをボブへ送信する。ボブが傘を買うと、サイトはサーバ80へこの情報を送信し、それによって傘を買うというアトランタ人のさらに大きい傾向が示される。
【0093】
さらに、IPアドレスがネットワークで以前にヒットしたいくつかのeコマースサイトとスポーツサイトとを含むこと、および、アドレスがカリフォルニアに位置することをプロファイルサーバ80内のプロファイルデータベース84Dに記憶されたプロファイルが示した場合、ウェブサイトは、カリフォルニア人が購入する頻度が高い、サーフィンボードなどの販売用スポーツ商品を示すように動的に特別に仕立てることができる。この方法は、eコマースと情報サイトとを用いてユーザに対してカスタマイズした経験をサポートするものである。
【0094】
ネットワーク内の、あるいは、ネットワーク外のウェブサイトに対して上記情報の編集を行うことができる。ネットワークの外側のウェブサイトは、一般にそのウェブサイトにヒットするユーザのプロファイルを発展させることができる。ウェブサイトのログファイルのチェックを行うことが可能であり、中央サーバに記憶されたプロファイル済みIPアドレス情報に対してIPアドレスを比較することが可能である。この比較により、ウェブサイトは、そのトラフィックを分析し、サイトにヒットするユーザの一般的プロファイルを決定することが可能となる。
【0095】
“陳腐になった”情報を除去するために、データベースサーバエンジン83は時折プロファイルサーバ80内のデータベース84のパージを行う。例えば、旅行に関する情報の調査に関心を持っているユーザ5はその旅行が終了した後にはおそらく当該旅行の販売促進を見続けたいとは思わない。データベース84のパージを行うことにより、古い優先順位が解除され、現在の関心と要望とによって更新される。
【0096】
B.コンテンツレジストリ
上記記載例に加えて、プロファイルサーバ80は、或るタイプの情報内容に対するエンドユーザの要望を登録するメカニズムをエンドユーザ5に設けて、サービスを受けることについてエンドユーザのシステムに許可あるいは不許可を与えることができる。この登録はIPアドレスに基づいて行われ、登録の権利にはアクセス権限が与えられ、IPアドレスは登録された所有者に限定される。これらの所有者はインターネットを介してプロファイルサーバ80にアクセスし、これら所有者のIPアドレス範囲に対してサービスを受けることを許可あるいは不許可にしたいと思うインターネットコンテンツの種別を特定する。特定のIPアドレスまたはアドレスのブロックによって受信が許可あるいは不許可にされたインターネットコンテンツの種別は、認証データベース84B内のプロファイルサーバ80により記憶される。ウェブサイト60などのインターネットコンテンツプロバイダは、プロファイルサーバ80に照会を行い、次いで、該プロファイルサーバ80は認証データベース84Bに照会を行い、上記IPアドレスレジストリに基づいて上記コンテンツプロバイダのコンテンツの受信を望むあるいは望まないユーザ5を特定する。
【0097】
例えば、学校はそのIP範囲を登録し、そのシステムへ送信された成人向けコンテンツを不許可にするようにプロファイルサーバ80に登録する。学校のIPの範囲内のマシーンから成人向けサイトへアクセスが行われると、成人向けサイトはプロファイルサーバ80を用いてチェックを行い、成人向けサイトが提供する当該コンテンツの当該IPアドレスへの送信が許可されていないことを知ることになる。成人向けコンテンツの代わりに、成人向けサイトは、当該サイト内のコンテンツのサービスをユーザのマシーンに対して行うことができない旨の通知をユーザに送信する。この一連のイベントにより、エンドIP
アドレス所有者は、彼らが制御するマシーンに対して配信とサービスとが行われるコンテンツの制御を行うことが可能となる。
【0098】
C.帯域幅レジストリ
ユーザ5へ送信するコンテンツ量を決定する際、プロファイルサーバ80に依拠することが望ましい。ウェブサイト60は、ある特定のユーザに対して利用可能な帯域幅を動的に決定し、プロファイルサーバ80へこの情報を出力し、ネットワークのスピードデータベース84Cの中にこの情報を記憶する。さらに、ウェブサイト60は、ある特定のユーザ5がウェブサイト60からパケットをダウンロードできるレートとスピードとをチェックし、ウェブサイト60によって、ウェブサイト64からエンドユーザ5への利用可能な帯域幅が決定される。エンドユーザ5へのパス・ルート上で、または、ユーザ5の端末装置との最後のリンクにおいて、ウェブサイト60で輻輳状態が生じた場合、ウェブサイト60は当該ユーザ5に対して利用可能な帯域幅に限度を設ける。この情報に基づいて、ウェブサイト60はユーザ60へ送信される情報量を動的に減らすことが可能となり、その結果、ユーザ5が感知するダウンロード時間が増加する。帯域幅情報はプロファイルサーバ80へ好適に送信され、ネットワークのスピードデータベース84Cに記憶される結果、必ずしも帯域幅自体の測定を行う必要なく、ネットワーク内の別のサイト60がこの帯域幅情報の利点を持つことになる。
【0099】
“陳腐になった”帯域幅情報を除去するために、データベースサーバエンジン83は時折ネットワークスピードデータベース84C内の情報のパージを行う。例えば、ウェブサイト60とユーザ5間の輻輳状態は通常持続することはない。
【0100】
D.インタフェースレジストリ
ウェブサイト60は、ユーザ5がウェブサイト60を閲覧しなければならないようにインタフェースを動的に決定できることが望ましい。このユーザインタフェース情報は、登録処理によってデータベース84Eに配置してもよいし、ISPから取得してもよいし、あるいは別の方法で検出または発見してもよい。個人用情報機器(PDA)のユーザには、PDAの限定された記憶容量に適合するように、限られた画像のウェブサイト60、あるいは、画像を伴わないウェブサイト60が示される。
【0101】
ウェブサイト60は、ユーザ5がアクセスする時期についてプロファイルサーバ80に照会する。次いで、プロファイルサーバ80は、インターフェースデータベース84Eに照会を行い、入手可能であれば、特定のIPアドレスと関連するタイプのインタフェースを検索する。プロファイルサーバ80は、データベース84Eの中にすべてのユーザを記憶し、ユーザ5が備えているディスプレイインタフェースについてウェブサイト60に通知する。この情報に基づいて、ウェブサイト60はユーザ5へ送信する情報の特別仕立てを行う。
【0102】
E.処理方法
図14(A)と14(B)とを参照しながらプロファイルサーバ80並びにプロファイル発見サーバ90のための望ましい処理方法160について以下説明する。162で、プロファイルサーバ80に対して照会すべきIPアドレスまたはホスト名が与えられる。163で、プロファイルサーバ80によって、情報を受信するアクセス権限が要求者に与えられているかどうかが判定され、アクセス権限が与えられていなければ、166で、要求者に対して当該情報が未知である旨が告げられる。163で要求者にアクセス権限が与えられているかどうかに関する問合せが好適に実行され、プロファイルサーバ80とプロファイル発見サーバ90とに対するアクセスに対して料金が支払われた当該エンティティのみがデータを取得することになる。要求者に対してアクセス権限が与えられている場合、164におけるプロファイルサーバはアドレスのプロファイルが既知のものであるかどう
かを判定する。当該アドレス用のプロファイルが既知のものであれば、プロファイルサーバ80は165で要求者へ要求された情報を送信し、既知のものでなければ、プロファイルサーバ80は166で要求者に情報が未知である旨を通知する。
【0103】
プロファイルサーバ80にとって未知の情報である場合、プロファイルサーバ80は167でプロファイル発見サーバ90へ情報を渡す。168で、プロファイル発見サーバはアドレスに対するルートを決定し、169で、プロファイルサーバ80からのルートのすべてのホストに関する情報を取得し、次いで、170で、任意の未知のホストがルート内に残されているかどうかを決定する。未知のホストがルート内に残されていれば、171で、プロファイル発見サーバ90はエラー条件を返信し、オペレータに通知する。
【0104】
ルートに残された個々のホスト名に対して、172でプロファイル発見サーバ90は次に未知のホストに対するホスト名が存在するかどうかを判定する。存在すれば、173でプロファイル発見サーバが一般的ホスト名命名規定および/または地球規模の国ベースの命名規定に基づいて所在位置の決定を試みる。174でプロファイル発見サーバ90はホストがNTPの照会に応答するかどうかをチェックし、応答すれば175で、NTP応答に基づいて時間帯の決定を試みる。176で、プロファイル発見サーバ90はホストがSNMPの照会に対して応答するかどうかをチェックし、応答すれば177で、公衆SNMP応答に基づいて、所在位置と、マシーンの種別と、接続スピードとの決定を試みる。次に、178で、プロファイル発見サーバ90は、ホストがMACアドレスを持っているかどうかをチェックし、該アドレスを持っていれば、所定のMACアドレス委任に基づいてマシーンの種別と、接続スピードとの決定を試みる。
【0105】
180で、何らかの追加の未知のホストが存在するかどうかがプロファイル発見サーバ90によって判定される。追加の未知のホストが存在すれば、プロファイル発見サーバ90は172へ戻り、ホスト名が利用可能であるかどうかをチェックする。未知のホストが存在しない場合、プロファイル発見サーバ90は、181で情報を内挿して、任意の残りの情報を決定し、182で、将来再査するために内挿済みデータのフラグを行い、次いで183で、すべての発見され、内挿されたデータをプロファイルサーバ80で保存する。
【0106】
IV.専用ネットワーク内での地理上の所在位置の決定
本発明の第2の実施形態に準拠するネットワークについて図15を参照しながら以下説明する。このネットワークはインターネット7などの外部ネットワーク7と内部ネットワーク9との双方を備える。外部IPアドレスと対をなす内部IPアドレスがネットワーク内の個々のマシーンに設けられるように内部ネットワーク9は構成される。内部ネットワーク9内でのすべてのトラフィックとデータのトランスポートとが内部IPアドレスを介して行われるのに対して、インターネット7から出たり、入ったりするように、ネットワークの外側へ出て行ったり、ネットワークの外側から入って来たりするように方向づけられたいずれのトラフィックの外部IPアドレスも利用される。このタイプのネットワーク9では、最低でも、ユーザ5とプロキシサーバ36あるいはインターネット7とつながる別のインタフェースが対をなす内部IPと外部IPとを認知して、内部ネットワーク9をトラフィックが貫通できるようにする必要がある。この専用ネットワークは、商用エンティティのLANやWANなどの専用ネットワークを備えるものであってもよいし、あるいは、AOLのネットワークなどのような半専用ネットワークであってもよい。
【0107】
このネットワーク9では、内部ネットワーク9がトラフィックを内部IPアドレスへトランスポートする方法を知っている限り、任意の特定の外部IPアドレスは任意の内部IPアドレスと任意に対をなすことができる。内部ネットワーク9が内部IPアドレスと外部IPアドレス間の対応関係を認知している限り、外部アドレス内部での任意のマッピング方法の採用が可能である。
【0108】
外部アドレスが任意のものであってもよいため、ネットワーク9の外部アドレスに基づいてユーザ5の地理上の所在位置を決定しようとする際、このネットワーク9は固有の問題を提示することになる。例えば、このネットワークアーキテクチャの結果として、ユーザ5とつながるネットワークのトレースを試みる人は誰も、プロキシサーバ36からの1つのホップアウェィとしてユーザのIPアドレスを見ること、及び、内部ネットワーク9内のいずれの中間ルータも見ることはないという点が挙げられる。内部ネットワーク9内でトレースができないというこの事実が当該ネットワーク9上でのユーザ5の地理上の所在位置の決定を挫折させる場合がある。というのは、すべてのユーザ5がプロキシサーバ36の所在位置に位置するように見えるからである。
【0109】
本発明によれば、このタイプのネットワーク9の範囲内でユーザ5の地理上の所在位置を決定するために、内部ネットワーク9は一般に安定していなければならない。言い換えれば、内部ネットワーク9内での番号付け方式は時間と共に大きく変化するものであってはならない。通常、このタイプのネットワーク9内で効率のよい情報ルートの指定を行うために、内部IPアドレスが一定ポイントに存在するように割り当てられ、その結果内部ネットワーク9全体が情報ルートの内部IPアドレスへの指定方法を認知することになる。そうでない場合、内部アドレスの所在位置に関して内部ネットワーク9を通じて現在進行中の方法で通知が行われる。これらの継続する“通知”はネットワークの不必要なオーバヘッドを誘起することになる。
【0110】
本発明のこの実施形態によれば、ネットワーク9は内部サーバ99を備え、この内部サーバ99は、内部ネットワーク9内のユーザ5からの要求に対してサービスを提供する1つのマシーンまたは1組のマシーンを備えるものであってもよい。一般に、内部サーバ99は、情報に対する要求を受け入れ、ユーザ5などの要求側マシーンの内部IPアドレスを正確に特定する。要求側マシーンの内部IPアドレスを正確に特定ができることにより、内部サーバ99は、要求側マシーンの内部IPアドレスを当該内部IPアドレスの地理上の所在位置とマップして、要求側マシーンの地理上の所在位置の正確な特定を図る。
【0111】
内部ネットワーク9内のユーザ5の地理上の所在位置の決定方法200について図16を参照しながら以下説明する。202で、内部IPアドレスINTERNALと外部IPアドレスIP EXTERNALとを備えたユーザ5は内部ネットワーク9の外側のサーバからの情報を要求する。203で、プロキシサーバ36は要求を受け取り、ユーザの外部IPアドレスと共にウェブサイト60へ上記要求を転送する。ウェブサイト60は、この要求が専用内部ネットワークから出されたものであると204で判定する。205で、ユーザ5のEXTERNAL IPに基づいて、ウェブサイト60は、ユーザ5の地理上の所在位置を発見する際に補助を行う内部サーバ99がネットワーク9内に存在し、この内部サーバ99へユーザ5をリダイレクトすると判定する。したがって、このリダイレクトの結果、ユーザ5は内部サーバ99へ情報要求を送信する。206で、内部サーバ99は、ユーザ5からの要求を調べ、その要求がウェブサイト60からリダイレクトされたものであると判定する。内部サーバ99は、ヘッダ内に含まれる参照URLを通じて、あるいは別の方法で、リダイレクトのURLなどの、内部サーバ99から要求された情報に基づいてこのリダイレクトを検出することができる。
【0112】
207で、内部サーバ99はユーザ5の地理上の所在位置を決定する。内部サーバ99は本発明に基づく方法によってユーザ5の地理上の所在位置を決定することができる。内部IPアドレスを知るとすぐに、内部サーバ99は専用IPアドレスと地理上の所在位置間のマッピングを有するデータベース内のルックアップを実行する。ユーザ登録によってデータベースを引き出すことができ、ネットワークのプロバイダあるいは別の何らかのエンティティによりこのデータベースの保守管理をすることができる。したがって、内部サ
ーバ99は、このデータベースに照会を行って、ネットワーク9内の任意のユーザ5の地理上の所在位置を取得することができる。
【0113】
内部サーバ99は別の方法でユーザ5に関する地理上の所在位置情報を取得することができる。例えば、内部サーバ99はネットワーク9内のユーザへのルートを取得し、中間ホストの地理上の所在位置を導き出し、次いで、ルートを分析して、ホストまたはユーザ5の地理上の所在位置を決定することができる。別の例として、内部サーバ99はネットワーク9内のデータベースから上記地理上の所在位置を直接取得することができる。個々のユーザの地理上の所在位置を有するデータベースの保守管理は、ネットワーク9内の範囲内のプロキシサーバ36により、内部サーバ99によりあるいは別の何らかのマシーンにより行うことができる。したがって内部サーバ99は、ユーザの地理上の所在位置に対する要求への応答時におよび/またはユーザ5のために地理上の所在位置のユーザ5自身のデータベースの構成時に上記データベースに照会を行うことができる。さらに別の例として、内部サーバ5は図3を参照して説明した方法111を利用してもよい。例えば、上記データのすべてを供給するネットワーク9のプロバイダとの関係を通じてこのデータベースの記入を行うようにしてもよい。このデータベースは、ネットワークプロバイダのダイアルイン・ポイント・オブ・プレゼンス(POP)のすべての自動ダイヤル呼出しを行うことにより、および、どの専用IPアドレスが個々のダイアルインPOPで使用されているかを判定することにより、少なくとも部分的に得られたたものであってもよい。このようにして、内部サーバ99はそのIP#INTERNALアドレスと地理上の所在位置マッピングとに基づいてユーザ5の地理上の所在位置を決定することが可能となる。
【0114】
208で、内部サーバ99は、ユーザ5の地理上の所在位置に関する情報を追加してウェブサイト60へ戻るユーザ5のリダイレクトを行う。クッキの利用によって、あるいは、複数の方法によってURLの符号化を行うことによりウェブサイトへ上記地理情報を送信してもよい。上述のように、ウェブサイト60は、ユーザ5の地理情報に基づいてユーザ5への転送情報を調整することができる。ウェブサイト60は、ユーザ5に対してこのような情報を提示する前にコンテンツ、広告などの特別仕立てを行うものであってもよい。方法200は、ユーザ5からの介在を必要とせずに、すべてのリダイレクションと分析とを自動的に行う。また、専用IPアドレスの地理上の所在位置を決定する方法200は個々のユーザのIPアドレスを決定する方法とは全く関係がない。
【0115】
図15と16を参照しながら以上説明したように、専用ネットワーク9内のユーザ5からの要求はプロキシサーバ36を介してウェブサイト60へ送信され、次いで、ウェブサイト60は、上記要求が専用ネットワーク9内から発信したかどうかを判定する。内部サーバに対して要求のリダイレクトを行う代替方法220について図17と18を参照しながら以下説明する。221で、ユーザ5は要求を開始し、この要求はプロキシサーバ36へ渡され、このプロキシサーバ36はまず、DNSサーバ8に対して問合せを送信して、上記要求と関連するIPアドレスの取得を図る。一般に、DNSサーバ8はドメイン名の問合せを受信し、IPアドレスの返送によりこれらの問合せを分析する。しかし、本発明の場合、223で、DNSサーバ8はユーザ5からの上記問合せに関連するIPアドレスに対して厳しいルックアップを実行せず、代わりに、その問合せが専用ネットワーク9内から発信したかものかどうかの判定をまず行う。上記問合せが専用ネットワーク9内で発信したものでなかった場合、225で、外部サーバ50用のIPアドレスを返送することによりDNSサーバ8は上記問合せを分析する。ユーザ5は外部サーバ50へ送られ、外部サーバ50は226でユーザ5の地理上の所在位置を決定し、地理上の所在位置情報と共にウェブサーバ60へユーザ5をリダイレクトする。234で、ウェブサーバ60は、上述の方法のような、無数の方法のうちの任意の1つの方法で地理上の所在位置情報を利用する。
【0116】
上記問合せが確かに専用ネットワーク9内で発信したものであるとDNSサーバ8が230で判定した場合、DNSサーバ8は内部サーバ99用のIPアドレスを返送することによりこの問合せを分析する。この結果、DNSサーバ8によって外部サーバへ送られる代わりにユーザ5は内部サーバ99へ送られることになる。内部サーバ99は231でユーザ5の地理上の所在位置を決定すし、232で地理上の所在位置情報と共にウェブサーバ60へユーザ5をリダイレクトして、ウェブサーバ60が234でこの情報を利用できるようにする。この結果、本発明の場合、プロキシサーバ36からウェブサーバ60へ、次いで、内部サーバ99へユーザ5を送る代りに、方法220は、DNSサーバ8がユーザ5のリダイレクトを行うことによるさらに直接的かつ効率的な方法となる。
【0117】
本発明の上述の好ましい実施形態についての説明は、専ら例示と説明とを目的とするものであり、網羅的であること、あるいは、開示された正確な形態に本発明を限定することを意図するものではない。上述の教示を考慮して多くの改変と変更を行うことが可能である。
【0118】
本発明の例示の態様では、ユーザ5はパーソナルコンピュータ(PC)により表されている。当業者には理解できるように、ユーザはPCを介する以外にも多数の方法でネットワークにアクセスすることができる。例えば、ユーザは、移動電話、個人用情報機器(PDA)、ラップトップコンピュータ、デジタルTV、ウェブTVおよびその他のTV製品を利用してもよい。本発明は、これらのタイプの製品と共に利用することが可能であり、新たな製品並びに新しいブランド品、モデル、規格あるいは既存製品の変形された形を適合することができる。
【0119】
任意のタイプの製品または装置に加えて、ユーザ5は効果的で、適切な方法でネットワークにアクセスすることができる。言うまでもなく、ネットワークは情報を受信する製品によって変わるものであるが、上記ネットワークにとして、AMPS、PCS、GSM、NAMPS、USDC、CDPD、IS−95、GSC、POCSAG、FLEX、DCS−1900、PACS、MIRS、e−TACS、NMT、C−450、ERMES、CD2、DECT、DCS−1800、JTACS、PDC、NTT、NTACS、NEC、PHS、または通信衛星システムが挙げられる(但しこれらに限定されるものではない)。ラップトップコンピュータの場合、ネットワークは、セルラデジタルパケットデータ(CDPD)ネットワーク、その他の任意のパケットデジタルまたはアナログネットワーク、回線交換型デジタルまたはアナログデータネットワーク、無線ATMまたはフレームリレーネットワーク、EDGE、CDMAONE、または一般パケット無線サービス(GPRS)ネットワークを含むものであってもよい。TV製品の場合、ネットワークはインターネット、同軸ケーブルネットワーク、ハイブリッド型ファイバ同軸ケーブルシステム、ファイバ配信ネットワーク、通信衛星システム、地上波無線放送ネットワーク、無線ネットワークまたは赤外線ネットワークを含むものであってもよい。移動電話とラップトップコンピュータへ、並びに、他の無線装置へ情報を配信する同じタイプのネットワークは、PDAへ情報を配信することも可能である。同様に、TV製品へ情報を配信する同じタイプのネットワークはデスクトップ型コンピュータへ情報を配信するものであってもよい。製品と関連する上述のタイプのネットワークが、単なる例示にすぎないこと、並びに、その他の既存のネットワーク並びに将来開発されるネットワークを採用してもよいこと、さらに、本発明がこれらのネットワークを含むものであってもよいことを理解されたい。
【0120】
上述のように、ウェブページに対するユーザ要求に対する場合と同様、インターネットトラフィックルートの指定時に本発明を利用してもよい。したがって、ユーザ5により送出される要求がワールドワイドウェブを介して送信されるhtmlページに対する要求を含むのに対して、本発明に基づくトラフィックマネージャは、ルート指定時に、あるいは
、別のタイプのネットワークトラフィックの送信時に使用することが可能である。例えば、これらの要求は、HTMLだけでなくXML、WAP、HDMLおよび別のプロトコルも含むものであってもよい。さらに、本発明は、ある何らかの人間による入力またはアクションに応じて生成される要求、あるいは、システムまたは装置により自動的に生成されるような、人間の活動をまったく含まない要求も含むものである。したがって、本発明を用いてルート指定が可能なトラフィックにはネットワークにより運ばれたり、あるいは、ネットワークの利用と関連したりする任意のタイプのトラフィックが含まれる。
【0121】
IPアドレスが4つの8ビット整数により表されるIPv4技術を示す例を用いて本発明について説明した。本発明は単にIPv4だけに限定されるものではく、別のアドレス指定方式に関しても利用可能である。例えば、IPアドレスが一連の6個の数によって表されるIPv6技術と共に本発明を利用してもよい。
【0122】
本発明の原理、並びに、これら原理の実際の適用を説明するために、上記実施形態を選び、説明して、他の当業者が本発明と種々の実施形態とを利用できるように図った。また、特定の利用に適するような種々の変更についても熟慮した。
【図面の簡単な説明】
【0123】
【図1】図1は、本発明の好ましい実施形態に準拠する収集システムを備えたネットワークのブロック図である。
【図2】図2は、図1の収集システムの好ましい処理方法を描くフローチャートである。
【図3】図3は、インターネットサービスプロバイダ(ISP)を介する地理情報の好ましい取得方法を描くフローチャートである。
【図4】図4は、本発明の好ましい実施形態に準拠する収集システムと決定システムとを備えたネットワークのブロック図である。
【図5】図5は、収集並びに決定システムのための好ましい作動方法を描くフローチャートである。
【図6】図6は、収集並びに決定システムと接続された位置ターゲッタを使用するウェブサーバのブロック図である。
【図7】図7は、図6のウェブサーバと位置ターゲッタの好ましい処理方法を描くフローチャートである。
【図8】図8は、ローカルな地理データベース並びに収集および決定システムへのアクセスを行う位置ターゲッタを使用するウェブサーバのブロック図である。
【図9】図9は、図8のウェブサーバと位置ターゲッタの好ましい処理方法を描くフローチャートである。
【図10】図10は、プロキシサーバを通じてユーザからの地理上の所在位置情報の収集を描くネットワークのブロック図である。
【図11】図11は、プロキシサーバを通じて地理情報を収集する好ましい処理方法を描くフローチャートである。
【図12A】図12(A)は、本発明の好ましい実施形態に準拠するトラフィックマネージャのブロック図である。
【図12B】図12(B)は、アナライザとネットワークトラフィックのネットワーク図である。
【図12C】図12(C)は、トラフィックレポータを含む、本発明の別の態様に準拠するネットワーク図である。
【図12D】図12(D)は、トラフィックマネージャの処理フローチャートである。
【図12E】図12(E)は、トラフィックレポータの処理フローチャートである。
【図13】図13は、本発明の好ましい実施形態に準拠するプロファイルサーバとプロファイル発見サーバとを備えたネットワークのブロック図である。
【図14A】図14(A)は、図13のプロファイルサーバとプロファイル発見サーバの好ましい処理方法を描くフローチャートである。
【図14B】図14(B)は、図13のプロファイルサーバとプロファイル発見サーバの好ましい処理方法を描くフローチャートである。
【図15】図15は、本発明の第2の実施形態に準拠する収集システムを備えたネットワークのブロック図である。
【図16】図16は、図15の収集システムの好ましい処理方法を描くフローチャートである。
【図17】図17は、本発明の第3の実施形態に準拠する収集システムとDNSサーバとを備えたネットワークのブロック図である。
【図18】図18は、本発明の別の実施形態に準拠するドメイン名問合せを分析する方法を描くフローチャートである。

【特許請求の範囲】
【請求項1】
ネットワークトラフィックに関する情報を提供する方法であって、
ネットワークを介して移動するトラフィックに関するリアルタイム情報を取得することと、
履歴ネットワークトラフィックに関する履歴データのデータベースを維持することと、
前記履歴ネットワークトラフィックに関する前記履歴データを前記トラフィックに関する前記リアルタイム情報と比較することと、
前記履歴データと、前記トラフィックに関する前記リアルタイム情報との間の変化が著しいものであるかどうかを判定することと、
前記リアルタイム情報に基づいて、前記ネットワークトラフィックの著しい変化を含むトラフィックレポートを作成することと、
前記トラフィックレポートを少なくとも1つのエンティティに送信し、それによって、前記エンティティが前記ネットワークを介してルーティング指示を導出することができるようにし、前記エンティティがネットワークトラフィックに関する前記リアルタイム情報に対する著しい変化に対して応答できるようにすることと
を含む方法。
【請求項2】
前記ネットワークトラフィックに関するリアルタイム情報を取得することは、ネットワークトラフィックを分析することを含む、請求項1に記載の方法。
【請求項3】
前記ネットワークトラフィックに関するリアルタイム情報を取得することは、別のシステムから前記リアルタイム情報を受け取ることを含む、請求項1に記載の方法。
【請求項4】
前記リアルタイム情報を受け取ることは、前記1つのエンティティから前記リアルタイム情報を受け取ることを含む、請求項3に記載の方法。
【請求項5】
変化が著しいものであるかどうかを判定することは、前記履歴データのうちの少なくともいくつかの履歴データのいずれかの変化に基づいて、前記変化が著しいものであると結論することを含む、請求項1に記載の方法。
【請求項6】
変化が著しいものであるかどうかを判定することは、前記履歴データからの変化の大きさに基づいて、前記変化が著しいものであると結論することを含む、請求項1に記載の方法。
【請求項7】
変化が著しいものであるかどうかを判定することは、前記変化が所定の割合を上回った場合に、前記変化が著しいものであると結論することを含む、請求項1に記載の方法。
【請求項8】
前記トラフィックレポートを送信することは、前記ネットワークを通して複数のロケーションに前記トラフィックレポートを送信することを含む、請求項1に記載の方法。
【請求項9】
前記トラフィックレポートを送信することは、インターネットを介して前記トラフィックレポートを送信することを含む、請求項1に記載の方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12A】
image rotate

【図12B】
image rotate

【図12C】
image rotate

【図12D】
image rotate

【図12E】
image rotate

【図13】
image rotate

【図14A】
image rotate

【図14B】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate


【公開番号】特開2009−27743(P2009−27743A)
【公開日】平成21年2月5日(2009.2.5)
【国際特許分類】
【出願番号】特願2008−238735(P2008−238735)
【出願日】平成20年9月17日(2008.9.17)
【分割の表示】特願2003−581434(P2003−581434)の分割
【原出願日】平成15年3月17日(2003.3.17)
【出願人】(504359787)デジタル エンボイ, インコーポレイテッド (9)
【Fターム(参考)】