(57)【要約】トラフィックレポータがネットワーク内のトラフィック条件に関するリアルタイム情報を収集し、トラフィックマネージャへトラフィックレポートを送出する。トラフィックレポータはネットワークを分析し、ネットワークを介して分散されたトラフィックマネージャおよびアナライザからネットワーク情報の収集も行う。これらのトラフィックレポートはネットワーク状態に関するリアルタイム情報を提供して、トラフィックマネージャが、信頼性の高い、最も高速な方法でネットワークトラフィックのルート指定を行うことができるようにする。
2005522098.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークトラフィックに関する情報を提供する方法であって、
ネットワークを介してトラフィックに関するリアルタイム情報を取得するステップと、
履歴ネットワークトラフィックに関する履歴データのデータベースを保守管理するステップと、
前記履歴ネットワークトラフィックに関する前記履歴データを前記トラフィックに関する前記リアルタイム情報と比較するステップと、
前記履歴データと、前記トラフィックに関する前記リアルタイム情報との間の変化が著しいものであるかどうかを判定するステップと、
前記ネットワークトラフィックの前記著しい変化を含むトラフィックレポートを前記リアルタイム情報に基づいて作成するステップと、
前記トラフィックレポートを少なくとも１つのエンティティへ送信し、それによって前記エンティティが前記ネットワークを介してルーティング指示を導き出して、ネットワークトラフィックに関する前記リアルタイム情報に対する著しい変化に対して応答できるようにするステップと、を備える方法。
【請求項２】
前記ネットワークトラフィックに関するリアルタイム情報を取得するステップが、ネットワークトラフィックを分析するステップを備える請求項１に記載の方法。
【請求項３】
前記ネットワークトラフィックに関するリアルタイム情報を取得するステップが、別のシステムから前記リアルタイム情報を受け取るステップを備える請求項１に記載の方法。
【請求項４】
前記リアルタイム情報を受け取るステップが、前記１つのエンティティから前記リアルタイム情報を受け取るステップを備える請求項３に記載の方法。
【請求項５】
変化が著しいものであるかどうかを判定するステップが、前記変化が前記履歴データのうちの少なくともいくつかの履歴データのいずれかの変化に基づいて、著しいものであると結論するステップを備える請求項１に記載の方法。
【請求項６】
変化が著しいものであるかどうかを判定するステップが、前記変化が前記履歴データからの変化の大きさに基づいて著しいものであると結論するステップを備える請求項１に記載の方法。
【請求項７】
変化が著しいものであるかどうかを判定するステップが、或る所定の割合を上回った場合に、前記変化が著しいものであると結論するステップを備える請求項１に記載の方法。
【請求項８】
前記トラフィックレポートを送信するステップが、前記ネットワークを通して複数のロケーションへ前記トラフィックレポートを送信するステップを備える請求項１に記載の方法。
【請求項９】
前記トラフィックレポートを送信するステップが、前記インターネットを介して前記トラフィックレポートを送信するステップを備える請求項１に記載の方法。
【請求項１０】
ネットワークトラフィックのルート指定を行う方法であって、
前記ネットワークトラフィックを受け取るステップと、
前記ネットワークトラフィックの宛先を決定するステップと、
前記ネットワークと関連するソースまたは前記宛先のうちの一方で地理情報を取得するステップと、
履歴ネットワークトラフィックに関する履歴データのデータベースを保守管理するステップと、
前記ネットワークを介してトラフィックに関するリアルタイム情報を受け取るステップと、
前記ソースまたは宛先の地理上の所在位置と、前記履歴データと、前記トラフィックに関する前記リアルタイム情報とに基づいて、前記ネットワークを介して前記ネットワークトラフィックを所望の宛先へ送るステップと、を備える方法。
【請求項１１】
ネットワークトラフィックをモニタするステップをさらに備える請求項１０に記載の方法。
【請求項１２】
ネットワークトラフィックがローカルなネットワークトラフィックをモニタするステップを備える請求項１１に記載の方法。
【請求項１３】
モニタされるローカルトラフィックを履歴ネットワークトラフィックの前記履歴データと比較するステップをさらに備える請求項１１に記載の方法。
【請求項１４】
前記履歴データと前記リアルタイム情報間の変化が著しいものであるかどうかを判定するステップをさらに備える請求項１３に記載の方法。
【請求項１５】
前記リアルタイム情報の前記著しい変化を含むトラフィックレポートを送信するステップをさらに備える請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
本発明は、インターネットトラフィックのルート指定を行うシステムと方法とに関し、特に、ノードとリンクの地理上の所在位置、距離、ノードでの利用可能な帯域幅、接続スピード、利用可能なリソース、並びに、ノードまたはリンクの状態に関する情報などのインターネットトラフィックに関するリアルタイム情報を提供するシステムと方法とに関する。
【背景技術】
【０００２】
（背景）
インターネットは相互に接続されたコンピュータネットワークからなるネットワークから構成されている。これらコンピュータの各々は、ピリオドすなわちドットにより分離された一連の４つの数から成るＩＰアドレスを有し、これらの４つの数の各々は、インターネット内でコンピュータの一意のアドレスを一括して表す８ビットの整数である。インターネットはパケット交換ネットワークであるため、インターネット上で或る宛先へルート指定されたデータファイルは複数のパケットに分割され、その宛先へ別々に送信される。個々のパケットには、特に、データファイルの或る部分および宛先を示すＩＰアドレスが含まれる。
【０００３】
宛先を示すＩＰアドレスは、正しい宛先へ向けてパケットのルート指定を行う際に有用ではあるが、一般の人にとってあまりわかりやすいものではない。１グループの４つの８ビット数自体は、宛先に関して何も明らかにしていないし、示唆するものでもないため、ほとんどの人は宛先のＩＰアドレスを記憶することを難しく感じる。ＩＰアドレスの利用時のこの欠点を克服する結果としてドメイン名が形成された。ドメイン名は２または３以上の部分から構成され、この部分はピリオドによって分離された単語である場合が多い。ドメイン名を形成する単語、数字またはその他の記号は、宛先の識別番号を示したり、少なくとも宛先の識別番号を示唆したりする場合が多いため、ドメイン名がアドレスを入力する標準的方法になっており、ＩＰアドレスに比べて覚え易い。ドメイン名の入力後、ドメインネームサーバ（ＤＮＳ）はある特定のＩＰアドレスにドメイン名を分析する。したがって、例えば、インターネットサーフィンをしていたある人がブラウザプログラムの中へウェブサイト用の特定のドメイン名を入力すると、ブラウザはまず正しいＩＰアドレスで着信するＤＮＳについて照会を行う。
【０００４】
ＩＰアドレスが良好に機能して、インターネットで正しいアドレスへパケットを配信している間、ＩＰアドレスは宛先の地域別アドレスに関する有用情報を送信しない。さらに、ドメイン名は、時として、正確にまたは不正確にこのような位置を示唆することがあるとはいえ、地理上の所在位置を必ずしも示すものでさえない。ＩＰアドレスまたはドメイン名と地理上の所在位置との間のリンクが存在しないという状況は国内および国外の双方について当てはまることである。例えば、国別のトップレベルのドメイン形式では、米国については．ｕｓ、英国については．ｕｋ等が指定されている。したがって、これらの拡張子を参照することにより、コンピュータが配置されている国を少なくとも決定できる場合が多い。しかし、これらの拡張子はひとを欺く可能性がある場合が多く、不正確である場合もある。例えば、．ｍｄドメインはモルドバ共和国に割り当てられているが、米国では医学博士にきわめて人気がある。したがって、ドメイン名はコンピュータの地理上の所在位置について或る一面を示唆することができる一方で、ドメイン名とＩＰアドレスとが有用な地理情報を何ら送信しない場合も多い。
【０００５】
地理上の所在位置に加えて、ＩＰアドレスとドメイン名は、コンピュータまたはコンピュータネットワークを使用している個人や会社に関する情報をほとんど伝えるものではない。その結果、訪問者が、自分の本当のＩＤを明らかにすることなく、ウェブサイトへ行き、ファイルを転送し、または電子メールを送信する可能性がある。しかし、上記匿名性は多くのウェブサイトが望むカウンタを動かすものである。例えば、広告を目的とする場合、広告と関連する商品またはサービスについて最適化された選択マーケットグループへ個々の広告対象ターゲットを絞ることが望ましい。個人またはグループの関心に一致する、あるいはこの関心対象と密接に関連する製品またはサービスと関連する広告はより効果のあるものとなり、したがって、広告主にとってはサイトへのすべての訪問者へやみくもに送出される広告に比べるとさらに貴重なものとなる。
【０００６】
広告収入を増やして、販売を増やしたいという願望にしばしば突き動かされて、多くのサイトが現在それらサイトへの訪問者のプロファイリング（ｐｒｏｆｉｌｉｎｇ）を行っている。訪問者のプロファイリングを行うために、ウェブサイトはサイトを通じてその訪問者のトラフィック履歴をまずモニタし、様々なグループの訪問者の振舞いパターンを検出する。ウェブサイトは、或るグループの訪問者が特別の関心対象を含むページまたは一連のページを要求していることを推論できるようになる。当該グループ内の個人が要求した次のページ用の広告を選択すると場合、ウェブサイトは個人またはグループの推論された関心対象と関連する広告にターゲットを絞ることができる。したがって、ウェブサイトにおける別の訪問者の振舞いに基づいてウェブサイトの中を通る訪問者のトラフィックがマップされ、分析される。したがって、ウェブサイトの訪問者に関してできるかぎり多くの情報を得る際に多くのウェブサイトを関心対象として、それらのウェブサイトの利益の増加を図ることが意図される。
【０００７】
インターネットユーザに関してさらに多くの情報を知りたいという要望はユーザのプライバシに関する懸念により抑えられる。例えば、クッキの利用は多くの訪問者にとって好ましくないものである。実際に、下院へ法案が提出されており、また、上院でもクッキあるいはデジタルＩＤタグの使用を規制する法案が提出されている。ユーザ用コンピュータにクッキを設けることにより、企業は、多数のウェブサイトにわたって訪問者を追跡し、それによって訪問者の関心対象を示唆することが可能となる。多くの企業がクッキおよびその他のプロファイリング手法を有益なものであると思っているが、プロファイリング技法は社会全般から広範な承認を勝ち得ていない。
【０００８】
プライバシとプロファイリング間での競合する利害関係についての特に多くを物語る例として、ニューヨークのダブルクリック社（ニューヨーク州）が個人の氏名と住所を個人のそれぞれのＩＰアドレスと結びつけた場合の例がある。ダブルクリック社の行動に対する反応には、電子プライバシ情報センタによる連邦通商委員会（ＦＴＣ）への告訴手続きと、訪問者の閲覧習慣の追跡は本質的に権利の侵害であるという多くのプライバシ擁護からの激しい抗議の噴出とが含まれた。したがって、たとえ、インターネットにおける個人の正確な追跡が技術的に可能なものであったとしても、企業は、訪問者のプロファイルを行いたいという願望と匿名のままでいたいという訪問者の権利との注意深いバランスをとる必要がある。
【０００９】
インターネットユーザについてさらに多くの情報を知る際の困難として、インターネットユーザがアメリカオンライン（ＡＯＬ）などの専用ネットワークの一部である場合、さらに複雑な問題が生じる。ＡＯＬ並びに他の専用ネットワークは、メンバーユーザとインターネット間のプロキシサーバを操作することにより中継ネットワークとして機能している。プロキシサーバは、メンバーからなる私的共同体の形成を助け、インターネット上で生じる可能性がある何らかの侵害的照会からメンバーを遮断し、保護するものである。この保護と遮断の一部として、これら専用ネットワークの多くは専用ネットワーク内のみでのルート指定用の第１の組のＩＰアドレスをそのメンバーに割り当て、インターネット上などの、専用ネットワークの外のエンティティに対してこれらのＩＰアドレスを明らかにしない。メンバーと交信するためには、専用ネットワークの外側のエンティティはメンバーに対して直接アクセスを行わないで、代わりにプロキシサーバを介する必要がある。当業者には明らかなように、専用ネットワークのメンバーに関する情報のプロファイリングおよび違った形での上記情報の収集は、プロキシサーバが存在するためにさらにずっと困難なものとなる可能性がある。
【００１０】
コンテンツのターゲットをユーザにしぼることを目的として、インターネットユーザについてさらに多くの情報を知ることに加えて、ユーザと宛先とについての情報がユーザの要求するルート指定時に役立つ可能性がある。インターネットの場合、ユーザの要求はパケットに分割され、これらのパケットはノードからノードへルート指定された後、最終的にパケットは意図された宛先に達する。次いで、これらのパケットは再構成されて、元の要求が形成される。この推移の最中にパケットは異なるルートをとる場合があり、パケットのいくつかが脱落する場合がある。ノードは通常最小回数のノードまたはホップの通過によって宛先へのパケットの送信を試みる。個々のノードは、パケットの受信後、パケットの発送時に或る待ち時間を有するため、ホップ回数を最小化することにより、待ち時間が最小化される。宛先がどこに位置するかに関する情報を用いて、ノードは、たとえ多数のホップが含まれるものであってもより直接的なルート選択を行うことができる。
【００１１】
Ｌｅｉｎｗａｎｄらに付与された米国特許第６，１３０，８９０号は、本願明細書で参照により援用される特許であるが、この特許に、データパケットのルート指定を最適化する方法およびシステムについての記載がある。この特許で、国と国との間の国際間のリンクの多くが頻繁に高度の過負荷状態になり、これらのリンクが利用される結果、たとえ最も少ないホップ回数を含むものであっても、より長い遅延が生じる可能性がある旨の記載がある。この特許に記載の方法は、インターネット番号アメリカン・レジストリ（Ａｍｅｒｉｃａｎ  Ｒｅｇｉｓｔｒｙ  Ｉｎｔｅｒｎｅｔ  Ｎｕｍｂｅｒｓ）（“ＡＲＩＮ”）、リソースＩＰヨーロッパ（Ｒｅｓｅａｕｘ  ＩＰ  Ｅｕｒｏｐｅａｎｓ）（“ＲＩＰＥ”）、および、アジア・パシフィックネットワーク情報センタ（Ａｓｉａ−Ｐａｃｉｆｉｃ  Ｎｅｔｗｏｒｋ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｅｒ）（“ＡＰＮＩＣ”）を介して行われているような、個々のＡＳで保守管理さている情報の利用に関わるものである。これらの組織に照会を行うことにより、システム個々の自律システム（ＡＳ）に関する国別情報を取得し、ＡＳをそれらの国別記号と対応づけることができる。次いで、宛先と関連する国との直接のリンクを選択することによりパケットのルート指定を行うことができる。
【００１２】
Ｌｅｉｎｗａｎｄらの特許で開示されたシステムと方法は、インターネットトラフィックのルート指定の最適化における限定された成功を提供するものである。以上説明したように、Ｌｅｉｎｗａｎｄらの特許はインターネットトラフィックの国別レベルのルート指定について記載するものではあるが、１国内におけるルート指定の実行方法について記載するものではない。米国内で発信するインターネットトラフィックの多くは、米国内の宛先へ向けられるものであるため、Ｌｅｉｎｗａｎｄらの特許に記載の方法およびシステムにはほとんど利点がない。さらに、ＡＳと関連する情報は、ＡＳの地理上の所在位置を正確に特定するものではない。国別情報は、ＡＳが現実に位置している国以外の異なる国をリストするものであってもよいし、さらに、上記特許にされているように、２以上の国に関するＡＳをリストするものであってもよい。必ずしも正確であるとはかぎらないことに加えて、ＡＳ情報に対する信頼はおそらく長期間については役に立たないかもしれない。ＡＳ番号用として確保された空間は、インターネットの爆発的成長と共に急速に空乏されている。ＡＳ番号が空乏した場合、上記特許に記載の方法を用いてその後利用されるＡＳの地理上の所在位置の決定ができなくなるかもしれない。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
したがって、さらに効率的にかつ効果的にインターネットトラフィックのルート指定を行う改善されたシステムと方法とに対する要望が存在する。
【課題を解決するための手段】
【００１４】
（概要）
本発明は、地理上の所在位置情報に基づいてネットワークトラフィックのルート指定を行うシステムと方法とを提供することにより上記問題を処理するものである。本発明の１つの態様によれば、上記方法には、ネットワークトラフィックを受信し、ネットワークの知的機能（ｉｎｔｅｌｌｉｇｅｎｃｅ）に基づいて上記ネットワークトラフィックを送るステップが含まれる。この知的機能には、トラフィックマネージャによるネットワークトラフィックの効率的かつ効果的なルート指定を可能にするデータが含まれる。上記知的機能には、トラフィック用宛先の地理上の所在位置と、トラフィックのソースの地理上の所在位置と、上記ソースにおいて利用可能な帯域幅と、宛先または中間ノードと、ノード間でのリンクの接続スピードまたは上記ソースにおける接続スピードと、異なる宛先における負荷と、ネットワークエレメントの信頼性と、が含まれる（但しこれらに限定されるものではない）。好ましい実施形態では、１組のアナライザがネットワークを通じて配分され、知的機能の収集が行われる。或いは、ネットワークから、または、別のシステムから直接知的機能を収集してもよい。
【００１５】
好ましい実施形態に基づくトラフィックマネージャにより、知的機能がネットワークのマップに記憶される。このマップは、ネットワークの中を通って宛先またはソースまでのルート指定を決定することにより、ソースに関する地理情報並びに宛先と共にポピュレートされる。本発明の方法には、ソースと宛先間のルート内に含まれる任意の中間ホストのいずれかの地理上の所在位置を導き出すステップと、ルートと任意の中間ホストの地理上の所在位置とを分析するステップと、次いで、ソースと宛先の地理上の所在位置を決定するステップとが含まれる。この地理情報が確かめられた後、地理情報はマップに記憶される。
【００１６】
本発明に基づくこの好ましいシステムはｗｈｏｉｓを実行して、ＩＰアドレスまたはドメイン名を所有する組織を決定する。この所有者のアドレスによってはある地理上の所在位置についての何らかの示唆が提供されるが、決定的なものではない。ルート追跡（ｔｒａｃｅｒｏｕｔｅ）を行って宛先までのルートを取得し、データベースにおいて地理的にルートのマッピングを行う。信頼レベルが、ルートに沿ったホストまたはノードについての情報に基づいて地理上の所在位置に割り当てられる。システムはトップレベルのドメイン７とドメイン名の中の実際の単語とを考慮に入れることができる。ネットワーク内のどこでも、ＤＮＳサービスの一部などのトラフィックマネージャを利用して、所望のＩＰアドレスへあるいは或るサイトに在る所望のコンテンツサーバへのＨＴＴＰリダイレクトとして、ユーザの要求を転送することができる。
【００１７】
別の態様によれば、システムと方法は、ネットワークに関するリアルタイム情報とトラフィック条件とを取得するトラフィックレポータに関する。トラフィックレポータはトラフィックマネージャへトラフィックレポートを送信し、これらのトラフィックレポートはネットワークを通じて分散される。トラフィックマネージャは、特定の宛先へのルーティング情報の提供時に、上記リアルタイム情報を利用する。トラフィックレポータは、この情報を取得するためにネットワークの分析を行い、トラフィックマネージャ自身を通じてあるいはアナライザを通じるなどの手段によって別のソースからも情報を受信する。トラフィックレポータは、トラフィックマネージャへのこれらのトラフィックレポートの提供時に何らかの自由裁量を利用して、トラフィック条件の著しい変化が発生したとき、トラフィックマネージャのみが受信、更新あるいは報告を行うようにする。
【００１８】
トラフィックマネージャはトラフィックレポータからトラフィックレポートを受信し、これらのトラフィックレポートに基づいてルーティング指示を出力する。トラフィックマネージャは、通常のトラフィック条件のデータベースの保守管理を行い、トラフィックレポータが作成した任意のトラフィックレポートのモニタを行う。ルーティング指示の決定時に、トラフィックマネージャは、デフォルトの組のデータとして通常のトラフィック条件のデータベースを利用するが、最適のルーティング指示で着信する前に、任意の関係するトラフィックレポートのチェックも行う。トラフィックマネージャはローカルトラフィック条件もモニタし、トラフィックマネージャがトラフィックレポータへ発生を報告するべき程度までこれらの条件が通常の条件から逸れた時期を決定する。したがって、トラフィックマネージャは、トラフィック条件に関する情報を含む、最も最新のかつ正確なネットワークに関する情報の保守管理を行う際にトラフィックレポータを補助するものである。
【００１９】
本明細書の一部に組み入れられ、本明細書の一部を形成する添付図面は、本発明の原理を開示する説明と共に、本発明の好ましい実施形態を例示するものである。
詳細な説明
次に、本発明の好ましい実施形態について詳細に言及する。本発明を限定するものではない、上記実施形態の実施例が添付図面に例示される。
【００２０】
Ｉ．  地理上の所在位置の収集、決定および配信
１つの態様によれば、本発明はインターネットユーザが地理的にどこに位置する傾向があるかを特定するデータの収集、決定および配信を行うシステムと方法とに関する。インターネット上のアドレス指定方法（インターネットプロトコル（ＩＰ）アドレス）によって、世界中の任意の場所に配置されている任意の範囲のアドレスが処理されるため、任意の所定のマシーンまたはホストの実際の所在位置を決定することは簡単なタスクではない。
【００２１】
Ａ．地理上の所在位置データの収集
地理情報収集システム１０が図１に図示されている。システム１０は種々のインターネットルート指定用ツールを利用して、新たなターゲットホスト３４のような、新しく発見されたインターネットホストの有望な配置を発見する際に補助を行うシステムである。特にシステム１０は、ターゲットホスト３４の地理上の所在位置を決定する際に、ホストとして知られているプログラム、ｎｓｌｏｏｋｕｐ、ｐｉｎｇ、ｔｒａｃｅｒｏｕｔｅおよびｗｈｏｉｓを好適に利用する。本発明が上記プログラムに限定されるものではなく、同じ機能または類似の機能を提供する別のプログラムやシステムを利用するものであってもよいことを理解されたい。したがって、本発明は、地理上の所在位置を決定したり、ＩＰアドレスの地理上の所在位置の確認に役立つ別の情報を提供したりする任意のシステムまたは方法を利用するものであってもよい。
【００２２】
特に、ｎｓｌｏｏｋｕｐ、ｐｉｎｇ、ｔｒａｃｅｒｏｕｔｅおよびｗｈｏｉｓは最適の情報ソースを提供するものである。ｐｉｎｇとｔｒａｃｅｒｏｕｔｅの処理については、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２１５１．ｔｘｔで入手可能なコメント（ＲＦＣ）第２１５１号に対するインターネットエンジニアリングタスクフォース（ＩＥＴＦ）要求で説明されている。また、ｎｓｌｏｏｋｕｐ（実際にはＤＮＳルックアップ）については、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃｌｒｆｃ２５３５．ｔｘｔで入手可能なＩＥＴＦ  ＲＦＣ第２５３５号で説明されている。さらに、ｗｈｏｉｓについては、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆｏｒｇ／ｒｆｃ／ｒｆｃ０９５４．ｔｘｔで入手可能なＩＥＴＦ  ＲＦＣ第９５４号で説明されている。ホスト、ｎｓｌｏｏｋｕｐ、ｐｉｎｇ、ｔｒａｃｅｒｏｕｔｅ並びにｗｈｏｉｓの各々についての簡単な説明を以下に示す。これらコマンドの処理について説明を行う際、ソースホストとは、システム１０が稼動しているマシーンを意味し、ターゲットホストとは、ターゲットホスト３４などの、システム１０のために探索を受けるマシーンを意味する。これらのコマンドについてのさらに詳細な説明は、ＵＮＩＸ（登録商標）システムで、ＲＦＣ仕様またはマニュアルページを介して入手可能である。
【００２３】
ホストは、ターゲットドメインのＤＮＳサーバに対して照会を行い、ドメイン名に関する情報を収集する。例えば、“−ｌ”オプションを用いた場合、“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”はｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔの接尾辞を含むシステム１０のすべてのホスト名を示すことになる。
【００２４】
ｎｓｌｏｏｋｕｐは、ＤＮＳルックアップシステムを用いてＩＰアドレスのホスト名への変換もしくは逆の変換も同様に行うコマンドである。
【００２５】
ｐｉｎｇは、ホストがオンラインになっていて、処理を行うことができるかどうかを調べる要求をターゲットホストへ送信するコマンドである。ｐｉｎｇを用いて、ターゲットホストの状態を照会するためにとるべきルートを保存することも可能ではあるが、これは完全には信頼性の高いものであるとは言えない場合が多い。
【００２６】
ｔｒａｃｅｒｏｕｔｅはターゲットホストに達するためにとるべき正確なルートを決定するように設計される。ｔｒａｃｅｒｏｕｔｅを利用して、現存しないまたは非オンラインのターゲットホストマシーンへの部分的ルートを決定することが可能である。このケースでは、ルートは或る一定ポイントまでトレースされ、そのポイント以降は、ターゲットホストへ向かう別の進行状態を保存することはできなくなる。ｔｒａｃｅｒｏｕｔｅがシステム１０へ出力した報告によって、ソースホストからターゲットホストまでに遭遇した個々のホストのＩＰアドレスが与えられる。ｔｒａｃｅｒｏｕｔｅは、個々のホストが、上記のように構成されている場合、ＤＮＳを利用して遭遇した個々のホストに対してホスト名を与えることもできる。
【００２７】
ｗｈｏｉｓは、インターネット上のサーバに対して照会を行い、ドメイン名またはＩＰアドレスのブロックに関連する情報の取得を行うことができる。
【００２８】
システム１０に対する処理の望ましい方法１００について図１と２を参照しながら以下説明する。１０２でシステム１０は希望する地理上の所在位置を表す新たなアドレスを受信する。システム１０は、そのデータベース２０の中に現在含まれていないか、再検証を必要とする新たなターゲットホストを受け入れる。システム１０は、ＩＰアドレスとホスト名の双方の提供が可能ではあるが、ＩＰアドレスまたはホスト名のうちの一方だけを必要とする。１０３で、システム１０はＩＰアドレスとホスト名の検証を行うことが望ましい。ただし、この検証は必ずしも行わなくてもよい。システム１０はｎｓｌｏｏｋｕｐを利用して、ホスト名またはＩＰアドレスを取得し、これら複数の情報の双方が正しいことを検証する。次に、１０４で、システム１０はターゲットホスト３４がオンラインになっていて、処理を行うことが可能で、かつ、ｐｉｎｇを介してこの機能を達成することが望ましいかどうかの判定を行う。ホスト３４がオンラインになっていない場合、システム１０は、後で分析を行うために、システム１０の構成時の優先順位に応じてＩＰアドレスの再照会を行うことができる。
【００２９】
１０６で、システム１０はドメイン名の所有権を決定する。好適には、システム１０が、ｗｈｏｉｓを利用して、実際にＩＰアドレスを所有する組織を決定することが望ましい。この組織のアドレスは必ずしもＩＰアドレスの位置であるとはかぎらないが、この情報は、地理的に１つの位置にある場合が多いＩＰブロックを有するさらに小さな組織用として役に立つかもしれない。次いで、１０７で、システム１０はターゲットホスト３４に達するためにとられたルートを決定する。好適には、システム１０がターゲットホスト３４上でルート追跡を利用することが望ましい。１０８で、システム１０はターゲットホスト３４へのルートをとり、このルートを分析して、記憶済み位置データベース２０に対する地理上の対応づけを行う。中間ホスト３２などの、ターゲットホストへ通じるいずれかのホストが、データベース２０に含まれていなかった場合、システム１０は当該ホストの位置に関する決定を行う。
【００３０】
次いで、１０９で、ターゲットホストの位置に関する決定が行われ、発見された新たなホストとターゲットホスト３４とへ通じるホストの信頼レベルに基づいて、０〜１００の信頼レベルが上記決定に対して割り当てられる。次いで、すべての新たなホストおよびこれらホストのそれぞれの地理上の所在位置が１１０でデータベース２０に追加される。
【００３１】
ホスト名が、国別トップレベルのドメイン形式（．ｕｓ、．ｕｋ、など）のものである場合、システム１０は国およびおそらく州、または県並びに発信元の都市に対する対応づけをまず行う。しかし、アドレスの発信が予想されることがドメインにより示されている場所からアドレスが発信していない場合、システム１０はさらにＩＰアドレス用のインターネットルートの対応づけを行う必要がある。上記の例で論じられているように、．ｍｄドメインはモルドバ共和国に割り当てられてはいるが、このドメインは米国では医学博士にきわめて人気のあるドメインである。したがって、システム１０は、地理上の所在位置の決定時に国別トップレベルのドメイン形式に完全に依拠することはできない。
【００３２】
方法１００により、システム１０は、国、州、および、ターゲットホスト３４の発信元の都市の決定が可能となり、データベースでのエントリに対する信頼レベルの割当てを行うことが可能となる。この信頼レベルは以下の方法で割り当てられる。ダイアラを用いて、インターネットサービスプロバイダによりダイアルアップモデムプール（これについては以下でさらに詳細に説明する）に割り当てられたＩＰアドレス空間を決定するケースでは、入力される信頼レベルは１００である。別の信頼レベルは近傍のエントリに基づいている。２つの同じ位置のエントリが未知のエントリを取り囲んでいる場合、その未知のエントリには同じ位置のエントリの平均信頼レベルが与えられる。例えば、単にｗｈｏｉｓによって決定された位置は３５の信頼レベルを受けることが考えられる。
【００３３】
一例として、ホスト“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”に対するサンプル探索について以下説明する。まず、システム１０は１０２でターゲットホスト“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”を受信し、１０３で名称についてＤＮＳルックアップを行う。コマンドｎｓｌｏｏｋｕｐはシステム１０に対して以下を返す：
＞  ｎｓｌｏｏｋｕｐ  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ
名称：ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ
アドレス：２０９．１５３．１９９．１５
次いで、１０４でシステム１０はマシーンでｐｉｎｇを実行し、ｐｉｎｇはシステム１０に対して、ターゲットホスト３４がオンラインになっていて、処理が可能かどうかを教える。“−ｃ  ｌ”オプションは、ｐｉｎｇに１つのパケットの送信のみを命じる。このオプションによって、確認が著しくスピードアップされる。ｐｉｎｇはシステム１０に対して以下を返す：
＞  ｐｉｎｇ−ｃ１  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ
ｐｉｎｇ  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ  （２０９．１５３．１９９．１５）：  ５６  データバイト
２０９．１  ５３．１９９．１５から６４バイト：ｉｃｍｐ  ｓｅｑ＝０  ｔｔｌ＝２４１  ｔｉｍｅ＝１２０．４  ｍｓ
−−−  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ  ｐｉｎｇ  統計  −−−
１パケット送信済、１パケット受信済、０％パケット紛失
ラウンドトリップ  ｍｉｎ／ａｖｇ／ｍａｘ＝１２０．４／１２０．４／１２０．４  ｍｓ
次にシステム１０は、１０６で“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”でｗｈｏｉｓを実行する。本例では、登録者がジョージア州にいることがｗｈｏｉｓによってシステム１０に通知される。
【００３４】
＞  ｗｈｏｉｓ  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ
登録者：
何某（ＤＩＧＩＴＡＬＥＮＶＯＹ−ＤＯＭ）
１２３４  住所  通り
アトランタ、ジョージア州３３３３３
米国
ドメイン名：ＤＩＧＴＴＡＬＥＮＶＯＹ．ＮＥＴ
管理上の連絡先：
何某（ＳＯ００００）  ｓｏｍｅ＠ｏｎｅ．ｎｅｔ
＋１  ４０４  ５５５  ５５５５
技術上の連絡先：
ｍｙＤＮＳ  Ｓｕｐｐｏｒｔ  （ＭＳ３１１−ＯＲＧ）  ｓｕｐｐｏｒｔ＠ＭＹＤＮＳ．ＣＯＭ
＋１  （２０６）  ３７４．２１４３
課金上の連絡先：
何某（ＳＯ００００）  ｓｏｍｅ＠ｏｎｅ．ｎｅｔ
＋１  ４０４  ５５５  ５５５５
レコードの最後の更新日：１９９９年４月１４日
レコードの作成日：１９９９年４月１４日
データベースの最後の更新日：１９９９年４月２２日  １１：０６：２２  ＥＤＴ
リスト順ドメインサーバ
ＮＳ１．ＭＹＤＯＭＡＩＮ．ＣＯＭ   ２０９．１５３．１９９．２
ＮＳ２．ＭＹＤＯＭＡＩＮ．ＣＯＭ   ２０９．１５３．１９９．３
ＮＳ３．ＭＹＤＯＭＡＩＮ．ＣＯＭ   ２０９．１５３．１９９．４
ＮＳ４．ＭＹＤＯＭＡＩＮ．ＣＯＭ   ２０９．１５３．１９９．５
１０７でシステム１０はターゲットホスト３４でルート追跡を実行する。“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”のｔｒａｃｅｒｏｕｔｅはシステム１０に対して以下を返す：
＞  ｔｒａｃｅｒｏｕｔｅ  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ
ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ（２０９．１５３．１９９．１５）に対するｔｒａｃｅｒｏｕｔｅ、最大３０ホップ、４０バイトパケット
１  １３０．２０７．４７．１  （１３０．２０７．４７．１）  ６．２６９  ｍｓ  ２．２８７  ｍｓ  ４．０２７  ｍｓ
２  ｇａｔｅｗａｙｌ−ｒｔｒ．ｇａｔｅｃｈ．ｅｄｕ  （１３０．２０７．２４４．１）  １．７０３  ｍｓ  １．６７２  ｍｓ  １．９２８  ｍｓ
３  ｆｌ−０．ａｔｌａｎｔａ２−ｃｒ９９．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （１９２．２２１  ２６．２）  ３．２９６  ｍｓ  ３．０５１  ｍｓ  ２．９１０  ｍｓ
４  ｆｌ−０．ａｔｌａｎｔａ２−ｂｒ２．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （４．０．２．９０）  ３．０００  ｍｓ  ３．６１７  ｍｓ  ３．６３２  ｍｓ
５  ｓ４−０−０．ａｔｌａｎｔａｌ−ｂｒ２．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （４．０．１．１４９）  ４．０７６  ｍｓ  ｓ８−１−０．ａｔｌａｎｔａｌ−ｂｒ２．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （４．０．２．１５７）  ４．７６１  ｍｓ  ４．７４０  ｍｓ
６  ｈ５−１−０．ｐａｌｏａｌｔｏ−ｂｒ２．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （４．０．３．１４２）  ７２．３８５  ｍｓ  ７１．６３５  ｍｓ  ６９．４８２  ｍｓ
７  ｐ２−０．ｐａｌｏａｌｔｏ−ｎｂｒ２．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  ｛４．０．２．１９７）  ８２．５８０  ｍｓ  ８３．４７６  ｍｓ  ８２．９８７  ｍｓ
８  ｐ４−０．ｓａｎｊｏｓｅｌ−ｎｂｒｌ．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （４．０．１．２）  ７９．２９９  ｍｓ  ７８．１３９  ｍｓ  ８０．４１６  ｍｓ
９  ｐ１−０−０．ｓａｎｊｏｓｅｌ−ｂｒ２．ｂｂｎｐｌａｎｅｔ．ｎｅｔ  （４．０．１．８２）  ７８．９１８  ｍｓ  ７８．４０６  ｍｓ  ７９．２１７  ｍｓ
１０  ＮＳａｎｊｏｓｅ−ｃｏｒｅ０．ｎａｐ．ｎｅｔ  （２０７．１１２．２４２．２５３）  ８０．０３１  ｍｓ  ７８．５０６  ｍｓ  １２２．６２２  ｍｓ
１１  ＮＳｅａｔｔｌｅｌ−ｃｏｒｅ０．ｎａｐ．ｎｅｔ  （２０７．１１２．２４７．１３８）  １１５．１０４  ｍｓ  １１２．８６８  ｍｓ  １１４．６７８  ｍｓ
１２  ｓｅａ  ａｔｍ０．ｓｔａｒｃｏｍ−ａｃｃｅｓｓｐｏｉｎｔ．ｎｅｔ  （２０７．１１２．２４３．２５４）  １１２．６３９  ｍｓ  ３２７．２２３  ｍｓ  １７３．８４７  ｍｓ
１３  ｖａｎ−ａｔｍ１０．ｌ０．ｓｔａｒｃｏｍ．ｎｅｔ  （２０９．１５３．１９５．４９）  １１８．８９９  ｍｓ  １１６．６０３  ｍｓ  １１４．０３６  ｍｓ
１４  ｈｕｍｅ．ｗｏｒｌｄｗａｙ．ｎｅｔ  （２０９．１５３．１９９．１５）  １１８．０９８  ｍｓ  ＊  １１４．５７１  ｍｓ
データベース２０に記憶された地理上の所在位置を参照後、システム１０は以下のように上記ホップを分析する：
【００３５】
【表１】
2005522098.tif 000003
上記エントリがデータベース２０に含まれていること、および、確認のために或る人によるチェックを受けたことがあることを示す信頼レベル９９がシステム１０により割り当てられる。本発明の別の態様に基づいてアナリストなどの人が確認を行う場合があるが、確認は、人工的知能システムあるいは他の任意の好適な追加システム、モジュール、デバイス、プログラム、エンティティなどにより行われる場合もある。システム１０は、インターネットサービスプロバイダ（ＩＳＰ）により確認された地理情報用として信頼レベル１００を確保する。ＩＳＰは地理に対するＩＰアドレスの実際の対応付けをシステム１０に提供することになる。また、ダイヤル呼出しＩＳＰを介してシステム１０を用いて収集されたデータには、地理とＰアドレス間での明確に限定された接続に起因して１００の信頼レベルが与えられる。システム１０がターゲットホスト３４などの新たなターゲットホストを探索するとき、中間ホスト３２などの上記ホストの多くは、繰り返し通過され、ＩＳＰによる確認やシステム分析による検証を受けない限り、これらホストの地理上の所在位置の信頼レベルは最大９９まで上昇することになる。ホスト３２の地理上の所在位置の個々の連続的確認に伴う設定量による方法などの複数の方法で上記信頼レベルを上げることが可能である。
【００３６】
システム１０は、ホストの地理上の所在位置に関して妥当な推測へ通じる共通の命名規定を利用する。例えば、そのホスト名の最初の部分に“ｓａｎｊｏｓｅ”を含む任意のホストは、おそらくカリフォルニア州のサンホセに位置するか、カリフォルニア州のサンホセに在るシステムと接続されている。これらのルールのセットはデータベース２０へのエントリとしてシステム１０に実現される。データベース２０は、変形された名称に対応する都市、国、地方、州などのような地理上の所在位置をリストするルックアップテーブルを含むものであってもよい。したがって、データベース２０は、Ｓａｎｆｒａｎｃｉｓｃｏ、ＳａｎｆｒａｎおよびＳｆｒａｎｃｉｓｃｏなどの、すべてカリフォルニア州の同じ都市サンフランシスコを表す複数のリストを含むことも可能である。
【００３７】
しばしば１ブロックのＩＰアドレスが割り当てられ、組織に対して副次的に割り当てられる。例えば、ターゲットアドレス２０９．１５３．１９９．１５を含むＩＰブロックを照会することができる。
【００３８】
＞  ｗｈｏｉｓ  ２０９．１５３．Ｉ９９．１５＠ｗｈｏｉｓ．ａｒｉｎ．ｎｅｔ
［  ｗｈｏｉｓ．  ａｒｉｎ．ｎｅｔ］
Ｓｔａｒｃｏｍ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｐｔｉｃｓ  Ｃｏｒｐ．  （ＮＥＴＢＬＫ−ＳＴＡＲＣＯＭ９７）  ＳＴＡＲＣＯＭ９７
２０９．１５３．１９２．０  −  ２０９．１５３．２５５．２５５
ＷＯＲＬＤＷＡＹ  ＨＯＬＤＩＮＧＳ  ＩＮＣ．  （ＮＥＴＢＬＫ−ＷＷＡＹ−ＮＥＴ−０１）  ＷＷＡＹ−ＮＥＴ−０１
２０９．１５３．１９９．０  −  ２０９．１５３．１９９．２５５
この照会の結果から、システム１０は、２０９．１５３．１９２．０から２０９．１５３．２５５．２５５までの大きなブロックがＳｔａｒｃｏｍ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｐｔｉｃｓ  Ｃｏｒｐ．に割り当てられている旨を決定する。このブロック内で、Ｓｔａｒｃｏｍによって、ワールトウェイホールディング社に対して２０９．１５３．１９９．０〜２０９．１５３．１９９．２５５ブロックが割り当てられている。このブロック（ＮＥＴＢＬＫ−ＷＷＡＹ−ＮＥＴ−０１）をさらに照会することにより、収集システム１０はこの組織がどこに存在するかについて洞察を行う。このケースでは、下記に示すように当該組織はブリティッシュコロンビア州、バンクーバーに存在する。
【００３９】
＞  ｗｈｏｉｓ  ＮＥＴＢＬＫ−ＷＷＡＹ−ＮＥＴ−０１＠ｗｈｏｉｓ．ａｒｉｎ．ｎｅｔ  ［ｗｈｏｉｓ．ａｒｉｎ．ｎｅｔ］
ＷＯＲＬＤＷＡＹ  ＨＯＬＤＩＮＧＳ  ＩＮＣ．  （ＮＥＴＢＬＫ−ＷＷＡＹ−ＮＥＴ−０１）
１３３６  Ｗｅｓｔ  １５ｔｈ  Ｓｔｒｅｅｔ
Ｎｏｒｔｈ  Ｖａｎｃｏｕｖｅｒ，  ＢＣ  Ｖ７Ｌ  ２Ｓ８
ＣＡ
Ｎｅｔｎａｍｅ：  ＷＷＡＹ−ＮＥＴ−０１
Ｎｅｔｂｌｏｃｋ：  ２０９．１５３．１９９．０  −  ２０９．１５３．１９９．２５５
Ｃｏｏｒｄｉｎａｔｏｒ：
ＷＯＲＬＤＷＡＹ  ＤＮＳ  （ＷＤ１７１−ＯＲＧ−ＡＲＩＮ）  ｄｎｓ＠ＷＯＲＬＤＷＡＹ．ＣＯＭ
＋１  （６０４）  ６０８．２９９７
ドメインシステム逆マッピングは下記で提供される：
ＮＳ１．ＭＹＤＮＳ．ＣＯＭ  ２０９．１５３．１９９．２
ＮＳ２．ＭＹＤＮＳ．ＣＯＭ  ２０９．１５３．１９９．３
トレースとＩＰブロックアドレス情報の組み合わせを用いて、収集システム１０は、“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”がブリティッシュコロンビア州、バンクーバーに位置することにかなり確信を持つことができる。収集システム１０が、人間を介在することなく自動的方法を用いてこのホストを“発見した”ため、システム１０によって、該システムへ導かれるホストの信頼レベルよりもわずかに低い信頼レベルが好適に割り当てられる。また、システム１０は、この組織と割り当てられたＩＰアドレスのサブブロックとに対応する地理上の所在位置が同じであるとは仮定していない。というのは、実際のＩＰアドレスが別の物理的位置にある場合があるからである。地理上の所在位置は簡単に異なる位置に変えることができる。というのは、ＩＰブロックは要求する組織に割り当てられ、そのＩＰブロックがどこで使用されるかについての指示は何ら求められていないからである。
【００４０】
ＩＳＰから地理上の所在位置を取得する方法１１１について図３を参照しながら以下説明する。１１２で収集システム１０はＩＳＰ用のアクセス番号を取得する。好ましい実施形態におけるアクセス番号はダイアルアップ番号であり、ＩＳＰとのアカウントを確立するなどの任意の適切な方法でこのアクセス番号を取得することができる。次に、１１３で、収集システム１０はアクセス番号のうちの１つの番号を用いてＩＳＰと接続する。収集システム１０がＩＳＰと通信を確立すると、ＩＳＰは、１１４で収集システム１０が検出したＩＰアドレスを収集システム１０に割り当てる。
【００４１】
次いで、１１５の収集システム１０は、サンプルターゲットホストへのルートを決定し、ルート追跡によってこのルートを好適に決定する。ｔｒａｃｅｒｏｕｔｅの基礎並びにルートの最終宛先を形成する正確なターゲットホストは重要なものではないため、任意の適切なホストを使用することができる。１１６で、収集システム１０はｔｒａｃｅｒｏｕｔｅが取得したルートを分析して、ＩＳＰと関連づけられたホストの所在位置を決定する。したがって、ｔｒａｃｅｒｏｕｔｅにおける次のホップの地理上の所在位置を決定するために収集システム１０は逆方向に調査を行う。１１７で、収集システム１０はデータベース２０に分析結果を記憶する。
【００４２】
方法１１１を用いて、収集システム１０はＩＳＰの補助によりＩＰアドレスを取得することができる。収集システム１０がダイアルアップを行い、ＩＳＰとの接続を行うため、収集システム１０はＩＳＰにかかる負荷を軽減するような方法で好適に方法１１１を実行する。例えば、収集システム１０は、夜間などのＩＳＰのオフピーク時間中に方法１１１を実行することができる。また、収集システム１０は、１０分間隔でＩＳＰとの接続を確立するなどのような、特定のＩＳＰと接続している周波数の制御を行うことができる。
【００４３】
Ｃ．地理上の所在位置データの決定
図４を参照すると、別の態様によれば、本発明は収集システム１０が作成したデータベース２０を利用する地域別の決定システム３０に関するものである。決定システム１０は、地理上の所在位置に対する要求、および、ターゲットホスト３４などの探索対象ホストのＩＰアドレスまたはホスト名に基づく要求を受け取る。地理情報の要求者４０は、インターネット７を通じて、あるいは、別の何らかのネットワークを介して行われる対話型ネットワークセッションで、決定システム３０に対する要求を出し、決定システム３０からその応答を受け取る。収集システム１０、データベース２０および決定システム３０はまとめて収集並びに決定システム５０と考えることができる。
【００４４】
決定システム３０のための望ましい処理方法１２０について図５を参照しながら以下説明する。１２２で、システム３０はエンティティの地理上の所在位置を求める要求を受け取り、上述のようにＩＰアドレスとドメイン名の一方もしくは双方を受け取る。１２３で、決定システム３０は、情報がすでに取得されたものであるかどうかを調べるためにチェックを行いながら、与えられたデータを求めて地理上の所在位置用データベース２０を探索する。１２３でＩＰアドレスを探索する場合、システム３０はデータベース２０内の同一の正確なＩＰアドレスリストか、当該ＩＰアドレスを含むデータベース２０内にリストされている１つの範囲またはブロック範囲のＩＰアドレスかのいずれかの発見も試みる。探索されているＩＰアドレスが或るブロックのアドレスの範囲内に在れば、決定システム３０はそのＩＰアドレスを一致アドレスと考え、１２５で情報が検索され、１２６で地理情報が要求者４０へ配信される。１２４でこの情報がデータベース２０において入手できなかった場合、１２７で、システム３０は要求者４０に当該情報が既知のものではない旨を通知する。次いで、１２８で、システム３０は未知のＩＰアドレスの地理上の所在位置を決定し、データベース２０にこの結果を記憶する。１２５で、地理上の所在位置が未知であると宣言する代わりに、システム３０は地理情報を決定して、要求者４０へその情報を提供することも可能である。
【００４５】
決定システム３０はデータベース２０内のＩＰアドレスと、ドメイン名との双方を探索する。単一のＩＰアドレスが複数のドメイン名を含む場合があるため、決定システム３０は当該ドメイン名に近似する一致を探索する。例えば、ホスト名を探索するとき、システム３０はデータベース２０へのエントリに対してパターン一致を実行する。同じＩＰアドレスを示唆する一致が発見されたとき、決定システム３０は当該エントリ用の地理データを要求者４０へ返す。
【００４６】
要求者４０がＩＰアドレスとドメイン名の双方を与えた場合、曖昧さが生じる場合もあり、これら２つのピースのデータは異なるホストおよび異なる地理上の所在位置へ通じる。双方のデータピースが地理的に正確には一致しない場合、システム３０は、最適の信頼レベルを表す情報によって好適に応答する。別例の場合ように、システム３０は要求者４０が定義したように応答してもよい。いくつかのオプションとして、決定システム３０はデータが一致し、相互に整合したときにのみ報告を行うようにしてもよいし、矛盾する結果が生じた場合に情報を提供するようにしてもよいし、ＩＰアドレスのみに基づいて地理情報を提供するようにしてもよいし、ホスト名のみに基づいて地理情報を提供するようにしてもよいし、あるいは、代わりに、アドレスとホスト名とが一致する度合に基づいて最善の推測を提供するようにしてもよい。
【００４７】
要求者４０が決定システム３０へ送る要求のサンプル形式は下記のように与えられ、この場合、探索はホスト“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”に対して行われ、太字体の項目は地域別決定システム３０からの応答である。
【００４８】
ｓｅｒｖｅｒ．ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔと接続中．．．
；ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ；
ｖａｎｃｏｕｖｅｒ；ｂｒｉｔｉｓｈ  ｃｏｌｕｍｂｉａ；ｃａｎ；９９；
この要求形式と決定システム３０の出力形式は、アプリケーションに応じるものであってもよいこと、また、決して上記に示した例に限定されるものではないことは言うまでもない。
【００４９】
Ｄ．地理上の所在位置データの配信
図６と図７を参照しながら、地理上の所在位置情報を配信するシステムについて以下説明する。図６に図示の第１の態様によれば、ＩＰアドレスとドメイン名に関する地理情報が収集され、本システム５０により決定される。ウェブサイト６０はその訪問者の地理上の所在位置を望むことができ、収集並びに決定システム５０からこの情報を知りたいと思う。ウェブサイト６０は、ユーザ５の地理情報を取得するために、或るページと位置ターゲッタ６４とを求めるユーザ５からの要求を受信するウェブサーバ６２を備える。
【００５０】
図７を参照しながら、図６に図示のネットワークの処理の望ましい方法１３０について以下説明する。１３２で、ウェブサーバ６２はウェブページに対するユーザ５からの要求を受信する。１３３で、ウェブサーバ６２は位置ターゲッタ６４に照会を行い、次いで、該位置ターゲッタ６４は、１３４で、収集並びに決定システム５０にユーザの地理上の所在位置を照会する。好適には、位置ターゲッタ６４がインターネット７を介して収集並びに決定システム５０へ照会を送信することが望ましい。しかし、位置ターゲッタ６４は、収集並びに決定システム５０との直接接続を通じて、あるいは、別のネットワークを通じて行う別のルート指定によって上記照会の送信を行ってもよい。上述のように、収集並びに決定システム５０はターゲットホストのＩＰアドレス、ホスト名、あるいはこれら双方を受け付け、次いでウェブサイト６０が指定した形式でホストの地理上の所在位置を返信する。１３５で、位置ターゲッタは１３６で収集並びに決定システム５０から地理上の所在位置を取得し、ユーザ５へ転送する情報が選択され、次いで、１３７でユーザ５へ転送される。この情報は、ユーザ５の地理上の所在位置に基づいて位置ターゲッタにより好適に選択される。或いは、位置ターゲッタ６４は、ウェブサーバ６２へ地理情報を転送してもよい。次いで、ウェブサーバ６２は適正な情報を選択して、この情報をユーザ５へ転送する。以下さらに詳細に論じるように、地理上の所在位置は、どのようなコンテンツをユーザへ転送するか、もし何か存在する場合、どのような広告（コンテンツタイプ）をユーザ５へ転送するか、および／またはそのコンテンツの範囲に関係するものであってもよい。
【００５１】
図８に示す別のオプションとして、ウェブサイト６０は、ユーザ５に関する地理情報を記憶するローカルデータベース６６と関連するものであってもよい。図９を参照すると、望ましい処理方法１４０は１４２でユーザ５から要求を受信するウェブサーバ６２から始まる。１４３で、ウェブサーバ６２は地理上の所在位置情報を位置ターゲッタ６４’に照会する。図６と７の位置ターゲッタ６４の処理１３０とは異なり、次に位置ターゲッタ６４’はまず所望の地理情報に関連するローカルデータベース６６のチェックを行う。所在位置情報がデータベース６６内に存在しない場合、１４５で位置ターゲッタ６４’は収集並びに決定システム５０と関連するデータベース２０に照会を行う。
【００５２】
位置ターゲッタ６４’が１４６で地理情報を取得した後、データベース６６からローカルに行われるか、データベース２０を通じて中央で行われるかのいずれかの方法で、ユーザ５の地理上の所在位置に基づいて所望の情報が選択される。上述のように、ここでも再び、位置ターゲッタ６４’またはウェブサーバ６２により上記選択処理を実行してもよい。いずれのイベントでも、１４８で選択情報がユーザ５へ転送される。
【００５３】
位置ターゲッタ６４と位置ターゲッタ６４’の双方の場合、位置ターゲッタは地理上の所在位置照会の結果に基づいてＨＴＭＬコードを出力するように構成してもよい。ＨＴＭＬコードベースのこの結果は、ウェブサイト６０がユーザ５の所在位置に基づいて動的ウェブページを転送する場合、特に有用である。しかし、位置ターゲッタ６４と位置ターゲッタ６４’の出力はＨＴＭＬコードに限定されるものではなく、ＪＰＥＧ、ＧＩＦなどのような任意のタイプのコンテンツまたは出力を包含するものであることを理解されたい。
【００５４】
ホスト“ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ”に対するサンプル探索をここで示す（太字体の項目は位置ターゲッタ６４または６４’からの応答である）。
【００５５】
＞  ｄｉｓｔｒｉｂｕｔｉｏｎｐｒｏｇｒａｍ  ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔ
ｖａｎｃｏｕｖｅｒ；ｂｒｉｔｉｓｈ  ｃｏｌｕｍｂｉａ；ｃａｎ；９９；
各種オプションが作動するかしないに関わらず、出力形式と異なるものであってもよいは言うまでもない。
【００５６】
システム５０がおそらく間違った地理上の所在位置を選択した場合、エンドユーザ５は、システム５０がエンドユーザ５を特定した場所と比較して異なる地理上の所在位置を選ぶことができる。この情報が位置ターゲッタ６４または６４’へ返送された場合、位置ターゲッタ６４または６４’は決定システム３０へこの情報を渡し、決定システム３０は後で分析するためにこの情報をデータベース２０に記憶する。この情報は完全には信頼することができないものであるため、収集並びに決定システム５０はこの情報を分析と検証とを行い、おそらく人間の介在を選ぶ必要がある。
【００５７】
Ｅ．プロキシサーバを介する地理上の所在位置の決定
ターゲットホスト上で地理情報を提供する際の１つの難点として、キャッシュプロキシサーバと関連する場合が挙げられる。キャッシュプロキシは別のネットワーククライアントに代って要求を行い、将来の要求のためにその結果を保存する。この処理はネットワークからの出力帯域幅の必要量を減らすことになるため、多くのインターネットアクセスプロバイダのポピュラーな選択肢となっている。。例えば、図１０に図示のように、ユーザ５はプロキシサーバ３６と関連づけられる。
【００５８】
場合によっては、このキャッシュが望ましくない場合がある。というのは、これらキャッシュ内部のデータが陳腐になっていることがあるからである。ページにキャシュ不能のマークをつけることができる機能を備えることによりウェブはこの問題を修正している。不都合なことに、これらのキャシュ不能ページに対する要求は、あたかもエンドユーザのコンピュータ５の代わりにプロキシサーバ３６から着信しているかのように依然として見える。しかし、ユーザ５の地理情報は頻繁に要求されることが考えられる。
【００５９】
プロキシサーバ３６と関連するユーザ５の地理情報を決定する方法１５０について以下図１１を参照しながら説明する。好ましい実施形態では、ユーザ５はネットワークに対する直接のルート指定が可能なアクセスを行う。例えばネットワークアドレス変換を利用するシステムは作動しない。というのは、アドレスがグローバルなインターネットの一部ではないからである。また、プロキシサーバ３６によって任意のポートを介するアクセスが可能になり、これにより、すべてのポートで直接アクセスをブロックする企業ファイアウォールは機能しないことになる。最後に、ユーザ５はＪａｖａ（登録商標）アップレットまたは同等のこのような機能をサポートするブラウザを備える必要がある。
【００６０】
図１１を参照して、１５２で、ユーザ５は、図６または図８に示すウェブサーバ６０などのウェブサーバ６０に対する要求を開始する。１５３で、プロキシサーバ３６によりＨＴＴＰ要求が処理され、プロキシのキャッシュ内ではヒットが見られない。というのは、本システム用のページにキャシュ不能がマークされているからである。ユーザ５に代って、プロキシサーバ３８はウェブサーバ６０と接続し、１５３でＵＲＬを要求する。１５４で、ウェブサーバ６０は、ローカルデータベース６０、または、収集並びに決定システム５０を備えたデータベース２０のいずれかを介して要求を受け取り、この要求がプロキシサーバ３６から着信することを決定し、次いで、タグ付きのウェブページを１５５で選択して、ユーザ５のＩＰアドレスの決定を可能にする。このウェブページには、エンドユーザ５のＩＰアドレスの決定に使用可能なＪａｖａ（登録商標）アプレットで好適にタグ付けが行われる。ウェブサーバ６０には、当該要求を行うための一意のアプレットパラメータータグが組み込まれ、プロキシサーバ３６へドキュメントが返信される。次いで、プロキシサーバ３６は１５６でこのドキュメントをユーザ５へ転送する。
【００６１】
次いで、１５７で、ユーザ５のブラウザはＪａｖａ（登録商標）アプレットを実行し、一意のパラメーター・タグに沿って通過する。デフォルトで、アプレットが、アプレットの発生元であるホストにアクセスする権利を有しているため、ユーザ５のブラウザ上のアプレットは、ポート５０００（但しこれに限定されるものではない）などでクライアントウェブサーバ６０に対する直接接続を開く。ウェブサーバ６０は、別々のサーバープログラムなどを通して、ポート５０００での接続をリスンし、ポート５０００での接続を受け入れる。次いで、１５８でＪａｖａ（登録商標）アプレットはウェブサーバ６０へ一意のパラメーター・タグを返送する。接続が直接的であるため、１５９でウェブサーバ６０はユーザ５用の正しいＩＰアドレスを決定することが可能となり、プロキシサーバ３８から将来要求が着信したとき、ウェブサーバ６０は、セッションタグを当該ＩＰアドレスと関連づけることが可能となる。
【００６２】
代替例として、１５５で、ウェブサーバ１５５はＪａｖａ（登録商標）アプレットを含むウェブページをそのまま転送してもよい。上述の実施形態の場合と同様、Ｊａｖａ（登録商標）アプレットを含むウェブページは１５６でプロキシサーバへ転送され、ユーザ５は１５７でウェブサーバ６０と接続する。１５８では、ウェブサーバ６０がロードするように命じたものでＪａｖａ（登録商標）アプレットがユーザのブラウザを再ロードするという点で、本発明のこの実施形態に準拠するＪａｖａ（登録商標）アプレットは上述のＪａｖａ（登録商標）アプレットとは異なるものである。本発明のこの実施形態に準拠するＪａｖａ（登録商標）アプレットは、複数の一意のパラメーター・タグを処理し、ソートする必要性を軽減する一意のパラメーター・タグと関連づけられるものではない。代わりに、本発明のこの態様の場合、Ｊａｖａ（登録商標）アプレットがウェブサーバ６０と接続したとき、１５９のウェブサーバ６０はユーザ５のＩＰアドレスと地理上の所在位置とを決定するものである。
【００６３】
ＩＩ．インターネットの訪問者の地理上の所在位置に基づくインターネットサイトの特別仕立て
ウェブサイト６０は、インターネットユーザ５の地理上の所在位置またはインターネット接続スピードに基づいてインターネットサイトの特別仕立てを行うことができる。ユーザ５がインターネットサイト６０を訪問するとき、インターネットサイト６０は、ローカルデータベース６０または中央データベース２０などのデータベースにインターネットを利用して照会を行う。上記データベースは、その時、インターネットサイト６０上のユーザの“ヒット”から導き出されるユーザのＩＰアドレスと別の関連情報とに基づいてユーザの地理上の所在位置および／またはインターネット接続スピードを返送する。この情報はルートからユーザ５のマシーンへ導き出されるものであってもよいし、ユーザ５のホスト名、ＳＮＭＰを介するおよび／またはＮＴＰを介するユーザのマシーン５へのルートに沿うホストであってもよい（但しこれらの技法に限定されるものではない）。この情報に基づいて、インターネットサイト６０はユーザへ提示するコンテンツおよび／または広告の特別仕立てを行うことができる。この特別仕立ては、ユーザの所在位置に基づいてインターネットサイトの外国語をユーザの母国語へ変えたり、地理情報並びに別のデータベースから受信した他の情報に基づいてインターネットサイトで示す製品または広告を変えたり、あるいは要求のソースに基づいてアクセスを阻止したり（すなわち学校からの“アダルト”コンテンツサイト拒絶要求など）するステップを含むものであってもよい（但しこれらに限定されるものではない）。この特別仕立ては、ユーザ用としていくつかの別のスクリーンまたはサイトを備えることにより、また、ウェブサーバ６２あるいは位置ターゲッタ６４または６４’にユーザの地理情報に基づいて適切な情報を動的に選択させることにより行うことができる。地理情報を分析して、潜在的インターネットサイトの広告主と外部のコンテンツプロバイダに対してサイトの効果的なマーケッティングを行ったり、あるいは、十分な帯域幅を持つユーザへメディアリッチなコンテンツを提供したりすることができる。
【００６４】
特別仕立てを行う方法には、インターネットユーザのマシーン５へ戻るパス・ルートのトレーシングを行うステップが含まれる。このパス・ルートにおけるすべてのホストの所在位置が決定され、インターネットユーザのマシーンの所在位置の確率の決定が行われ、ホストに対してこのような情報を直接照会することにより（例えば、ＳＮＭＰまたはＮＴＰを用いることにより（但しこれらに限定されるわけではない））、インターネットユーザのマシーンとつながり、インターネットユーザのマシーンを備えるパス・ルートでのホスト（このホストの地理上の所在位置とリンクされていても、いなくてもよい）に関する別の情報が決定される。或いは、ＩＰアドレスとホスト名とに関する情報を記憶する、更新可能な完全なデータベースが存在する。次いで、ユーザに関する情報が送信されることになる遠隔地のソースにより上記ＩＰアドレスとホスト名とに照会することが可能となる。
【００６５】
ウェブサイト６０は、上記方法または処理から決定されるようなインターネットユーザ５の地理上の所在位置に基づいてインターネットコンテンツおよび／または広告を動的に変更する。ウェブサイト６０は、ユーザ５がウェブサイト６０にアクセスする結果としてデータベースが送信する情報に応じて、いくつかの予め設計された別のスクリーン、プレゼンテーション、またはミラーサイトのうちの１つを提示する。
【００６６】
上述のように、ウェブサーバ６２または位置ターゲッタ６４または６４’のいずれかの手段により、地理上の所在位置に基づいてユーザ５へ転送する適正な情報の選択を実行することができる。いずれの場合にせよ、ウェブサイトはインターネットコンテンツを動的に適合させ、このコンテンツの特別仕立てを行って、インターネットユーザ５の地理上の所在位置および／または接続スピードに基づいてインターネットユーザ５の要望に合わせるようにすることが可能である。
【００６７】
別のオプションとして、ウェブサイト６０は、インターネット広告を動的に適合させ、インターネットユーザの地理上の所在位置および／または接続スピードに基づいて特定のインターネットユーザをターゲットにするために上記インターネット広告の特別仕立てを行うことが可能である。さらに、ウェブサイト６０は、インターネットコンテンツおよび／または広告を動的に適合させて、インターネットユーザ５の地理上の所在位置により決定できるインターネットユーザ５の母国語への上記広告の特別仕立てを行うことが可能である。また、ウェブサイト６０は、インターネットユーザの地理上の所在位置、ＩＰアドレス、ホスト名および／または接続スピードに基づいて、インターネットサイト６０や特定のウェブページに対するアクセスをサイト６０上で選択的に可能にしたり、不能にしたりすることによりアクセスを制御することが可能である。別例として、ウェブサイトは、インターネットユーザ５による訪問を分析して、インターネットサイトのマーケティング時の補助となるインターネットユーザ５の地域別および／または接続スピードの低下を編集することができる。
【００６８】
Ａ．クレジットカードの不正使用
情報のターゲットをユーザに絞るための地理上の所在位置情報に併せて、ウェブサイト６０または収集並びに決定システム５０は、生じる可能性のあるオンラインクレジットカードの不正使用のケースを検出するメカニズムをウェブサイト所有者に提供することができる。ユーザ５が情報を入力して、オンライン注文を終了するとき、ユーザは出荷先と料金請求先と示す必要がある。一般に、この情報はユーザ５の物理的所在位置に対する有効性の確認とすることはできない。本発明を通じて、ウェブサイト６０はユーザ５の地理上の所在位置を決定する。ユーザ５が、存在しないことが決定された所在位置を入力した場合、不正使用の原因である可能性がある。この状況は、その注文要求が合法的なものであるかどうかを判定するためにウェブサイト所有者によるフォローを必要とすることになる。
【００６９】
Ｂ．トラフィック管理
クレジットカードの不正使用を検出するための地理情報の利用の他に、インターネット７上でのトラフィックの管理時に地理情報を利用することも可能である。例えば、図１２（Ａ）を参照すると、トラフィックマネージャ７０にはそのユーザまたは訪問者５の地理情報を取得できるという利点がある。トラフィックマネージャ７０は、ローカルデータベース６０を採用してもよいし、図示してはいないが、収集並びに決定システム５０と接続してもよい。トラフィックマネージャ７０がユーザ５の地理上の所在位置を検出した後、トラフィックマネージャ７０は、ウェブサーバＡ７４またはウェブサーバＢ７２などの最も望ましいウェブサーバへユーザ５の要求を送る。例えば、ユーザ５がアトランタにいる場合、トラフィックマネージャ７０は、アトランタにベースを置くウェブサーバＡ７４へユーザの要求を送ってもよい。一方、ユーザ５がサンフランシスコにいる場合、トラフィックマネージャ７０は、サンフランシスコに配置されるウェブサーバＢ７２へユーザ５を送ることになる。このようにして、トラフィックマネージャ７０が中間ホスト間でのトラフィックを減らし、最も近いウェブサーバへトラフィックを送ることができる。
【００７０】
最も効率的に最適サーバを決定して、ネットワーク上のユーザからの要求に対して応答するために、トラフィックマネージャ７０は好適にインターネットのマップなどのネットワークマップ全体を含むことが望ましい。上記マップは、データベース６０、インターネットユーザの地理上の所在位置と同じデータベース２０または別個のデータベースに記憶してもよい。トラフィックマネージャ７０が最も望ましいサーバへトラフィックのインテリジェントなルート指定を行うことができるように、ネットワークのこのマップにはネットワーク上のできるだけ多くの情報が理想的に含まれている。ネットワークに関する情報には、（１）ネットワーク内のルータ、スイッチ、ハブ、ホスト、および別のノード（まとめて“ノード”とする）と；（２）ノードの地理上の所在位置と；（３）個々のノードで利用可能な総帯域幅と；（３）個々のノードにおける利用可能な容量と；（４）ノード間でのトラフィックパターンと；（５）ノード間での待ち時間およびスピードと；（６）どのノードがクラッシュしたかや、どのリンクが保守管理を受けているかなどの、ノードとノード間自体でのリンクの健康状態または状態と；７）パフォーマンス並びに過去のパフォーマンス、現在のデータ、将来のイベントについての情報について考慮するモデル化された予測パフォーマンスにおける毎日の、季節毎の、毎年のトレンドなどのネットワーク、ノード並びにリンクの履歴パフォーマンスおよび予測パフォーマンスと；が含まれる（但しこれらに限定されるものではない）。データベースに記憶された考え得る情報を示すこのリストは例示のリストにすぎないこと、並びに、このデータベースがすべての情報よりも少ない情報並びに別のピースのデータを含むことができることを理解されたい。
【００７１】
当業者であれば理解できるように、任意の広いネットワーク用として、ネットワークの上記マップを持つ包括的なデータベースは急速に管理不能になる可能性があり、最適応答ソースの発見にはかなりの量の時間とリソースとを要することになる。上記理想的ルートの決定に費やされる時間によって、より迅速なサーバへトラフィックのルート指定を行うことにより実現される任意の利得の非常に簡単なオフセットが可能となる。実際的理由によって、トラフィックマネージャ７０とデータベースとは、ネットワークの何らかの近似マッピングまたは部分的マッピングを行うことが望ましい。例えば、インターネットなどのネットワーク全体の完全なマップまたは半分完全なマップは最も関連のあるデータから形成することができる。これによってトラフィックマネージャ７０はユーザに対して効率良く応答を転送することが可能となる。
【００７２】
ネットワークに関する情報は任意の数の方法で取得することが可能である。基幹ネットワークとインフラストラクチャのマップを完成する１つの方法について図１２（Ｂ）を参照しながら以下説明する。アナライザとして図示する１組のマシーンが、ホスト間の相互接続を分析し、収集済みの知的機能を１または２以上のデータベースに記憶するために配備されている。アナライザは任意のツールを利用して、ネットワーク用ツールｔｒａｃｅｒｏｕｔｅなどの知的機能を取得することができ、この知的機能には個々のホスト、並びに、個々のノードが備えている、別のノードとの直接リンクが含まれる。アナライザは、２つの相互に接続されたノード間での待ち時間を決定し、２つのノード間での相互接続のスピードを決定するｔｒａｃｅｒｏｕｔｅ情報を受け取る。ｔｒａｃｅｒｏｕｔｅ情報はユーザの地理上の所在位置を決定する分析の副産物であるため、収集システム、決定システム、または収集並びに決定システムはアナライザとして機能することができる。或いは、アナライザは別個のシステムまたはマシーンとして存在するものであってもよい。
【００７３】
図１２（Ｂ）に図示の例では、個々に自分のアドレスを持つ１００名のユーザが単一のサーバ（マシーンＡ）と接続され、さらに、個々に自分のアドレスを持つ１００名の別のユーザが単一のサーバ（マシーンＣ）と接続されている。ネットワークをモニタする際、アナライザはマシーンＡがマシーンＢへすべての要求を常に転送することを決定し、マシーンＣが常にマシーンＢへすべての要求を転送する。次いで、マシーンＢは、常に、マシーンＡからの要求、並びにマシーンＣからの要求をマシーンＤへ転送する。次いで、マシーンＤは複数のルートを有し、このルートを通じてマシーンＤはユーザ要求の送信が可能となる。マッピング時に、ネットワークは、ＡまたはＣのいずれかと接続されたユーザからの任意の要求に対する応答をマシーンＤを介してルート指定するため、アナライザはマシーンＤのアドレスを有するものとして、マシーンＡまたはＣ上の２００名すべてのユーザの処理を行うことになる。マシーンＡ、Ｂ、Ｃの位置と相互の接続を分析する必要がなくなることにより、アナライザにとって、管理が可能な近似値に設定される問題が減ることになる。この分析は、ネットワーク上で効率的良くルート指定された情報を要求するすべてのアドレスに対して実行可能である。
【００７４】
上述の例では、マシーンＡとＣとはそれらの要求のすべてをマシーンＢへ転送し、マシーンＢは要求のすべてをマシーンＤへ転送した。その結果、アナライザは、ユーザがすべてマシーンＤと接続されるモデルまで効果的かつ正確にこの組の相互接続を減らすことができた。しかし、実際には、マシーンＡとＣは、別のマシーンへまたは相互に何らかのトラフィックを送信してもよく、そして、マシーンＢはマシーンＤ以外のマシーンへ何らかのトラフィックを送信してもよい。それにもかかわらず、確率と統計とを通じて、アナライザは最も有望な進行パス・ルートを決定し、対応する近似またはネットワークの単純化を図ることができる。
【００７５】
トラフィックマネージャ７０は、アナライザを介する以外の方法でネットワーク上で知的機能を獲得することができる。例えば、ネットワークを形成する構成要素またはネットワークの管理者はノードとネットワーク全体とをモニタし、パフォーマンスデータをトラフィックマネージャ７０へ出力することができる。また、トラフィックマネージャ７０は、別のシステムを介するなどの手段で第三者から上記情報を取得し、上記知的機能を収集することが可能となる。
【００７６】
上述のように、トラフィックマネージャ７０は、ユーザとウェブサイトなどの発信元と宛先ポイントとの地理上の所在位置に基づいて、並びに、中間ノードの地理上の所在位置にも基づいてネットワーク上でトラフィックのルート指定を行うことができる。時として、ユーザの要求に応答するあるいはこの要求を処理するのに、ユーザに最も近いサーバまたはノードが必ずしも最適サーバに対応するとはかぎらないことがある。例えば、トラフィックは、クラッシュしたサーバやノード、追加の利用可能な帯域幅を持っていないサーバやノード、割り込みがかけられたまたは低速の中間ネットワークリンクを持つサーバやノードへは送られないことが望ましい。サーバまたはノードのクラッシュが生じたの場合、アナライザは継続的にすべてのサーバをモニタして、最適のパフォーマンスを提供することを保証する。低速のまたはダウンしたネットワークリンクの場合、アナライザは、どのサーバを利用するかの決定にインパクトを与える可能性があるすべてのリンクのモニタを行う。最後に、アナライザは、応答するサーバに対する利用可能な総帯域幅とユーザの接続スピードとを測定する。接続スピードに対するＩＰアドレスのマッピングの結果、ユーザが有する利用可能な帯域幅を知ることにより、トラフィックマネージャ７０は、利用可能な十分な帯域幅を持つサーバへユーザを送り、当該ユーザを正しく調整することが可能となる。したがって、エンドポイントと中間ノードの地理上の所在位置について考慮はされるが、たとえ遠隔地に在るものであっても、別のサーバの方がより高速な、より好適な、あるいは、より信頼性の高いサービスを提供することが可能な場合、トラフィックマネージャ７０は必ずしも最も近いサーバに対してトラフィックのルート指定を行うとはかぎらない。
【００７７】
トラフィックマネージャ７０はネットワーク内の任意の場所に配置することができる。１例として、トラフィックマネージャ７０はＤＮＳサービスと関連づけることができる。ＤＮＳサービスとして利用する場合、コンテンツプロバイダはＤＮＳサービスとのインタフェースを行って、どのような条件と状況で特定のサーバへ特定ユーザを送るかを定義する。例えば、これらの条件は、ユーザの地理上の所在位置、ユーザのネットワークの所在位置、ユーザと利用可能なサーバ間の帯域幅と待ち時間、ユーザの利用可能な帯域幅、サーバの利用可能な帯域幅、１日の時刻に基づくものである。次いで、ユーザは、コンテンツプロバイダにより設定された判断基準に基づいて自分のプロファイルに最もよく適合するサーバへ送られる。すべての新たな要求が名称分解処理を受け、それによって要求時点に適正なサーバへユーザが送られるように、ＤＮＳ応答は生存時間（ＴＴＬ）０で送信されることになる。トラフィックマネージャ７０をＤＳＮサービスと関連づける本例では、ウェブサーバＡ７４とウェブサーバＢ７２とは同じウェブサイトと関連するミラー処理を施したウェブサーバを備えることができる。
【００７８】
別の例として、トラフィックマネージャ７０は、インターネット内でサーバまたはノードと関連して、リダイレクトを行うことができる。ＨＴＴＰリダイレクトの本例では、ユーザをどこへ送るかを決定する際に同じ判断基準が用いられる。１つの相違点として、トラフィックマネージャ７０が、コンテンツプロバイダなどのサイト用フロントエンドとして機能し、ユーザとの接触を行った後、このマシーンから適正なマシーンへユーザのリダイレクトを行うという点が挙げられる。ＤＮＳの例の場合と同様、トラフィックマネージャ７０は、サーバ７４と７２における利用可能な帯域幅、サーバ７４と７２の接続スピード、地理上の所在位置、負荷バランス、などに基づいてリダイレクトを実行することができる。
【００７９】
トラフィックマネージャ７０は、個々のユーザアクセスを行うために上記分析を実行して正しいサーバを決定する。この一連の分析を行うことにより、ユーザは最適の可能なパフォーマンスを保証されることになる。
【００８０】
Ｃ．トラフィックレポートと管理
上述のように、図１２（Ａ）と１２（Ｂ）とを参照すると、トラフィックマネージャ７０にはインターネットまたは別のネットワークに関する情報が含まれ、この情報には、ノードと、ノードの地理上の所在位置と、個々のノードにおける利用可能な総帯域幅と、個々のノードにおける利用可能な容量と、ノード間でのトラフィックパターンと、ノード間での待ち時間およびスピードと、ノードとノード間自体でのリンクの健康状態または状態と、ノード並びにリンクの履歴パフォーマンスと予測パフォーマンスと、に関する情報が含まれる。この情報は、ネットワークのマップなどの形で、トラフィックマネージャと関連するデータベースに記憶してもよい。また、上述のように、この情報は複数の方法で取得することができる。これらの方法には、トラフィックマネージャ７０自体の努力による、あるいは、別のシステムによる、図１２（Ｂ）に描かれているアナライザの利用が含まれる。
【００８１】
また、上述のように、このネットワーク情報は複数の方法で利用することができる。例えば、最適のルートまたは最も効率的なルートによってトラフィックを送る際に上記情報を利用してもよい。ルートの選択時に、トラフィックマネージャ７０は、発信元と宛先ポイントの地理上の所在位置、中間ノードの地理上の所在位置、種々のノードにおける利用可能な帯域幅、ノードの状態、などにおける係数・ファクタ・要因とすることができる。本質的に、トラフィックマネージャ７０は、ネットワークに関する任意のまたはすべての情報、発信元または宛先ポイント、あるいは任意の中間ノードまたはネットワークを利用してトラフィックのルート指定を行うことが可能である。さらに、トラフィックマネージャ７０は、１または２以上のノード、発信元または宛先ポイントに、あるいはＤＮＳサービスの一部を含むネットワーク内の任意の場所に配置されたものであってもよい。
【００８２】
トラフィックマネージャ７０で利用可能な情報は通常のネットワークトラフィック条件を反映する。これらの条件は、過去１日、１週間、１月または１年などの期間にわたる平均値に基づくものであってもよい。図１２（Ｃ）に図示のような本発明の１つの態様によれば、トラフィックレポータ７９はリアルタイムトラフィック条件でトラフィックマネージャ７０と交信を行う。トラフィックレポータ７９は周期的なトラフィックレポートまたは時折のトラフィックレポートを好適にトラフィックマネージャへ送信して、当該トラフィックマネージャ７０に対してネットワーク内でのトラフィック条件に関する更新を行う。さらに、トラフィックマネージャ７０はローカルな条件をモニタし、トラフィックレポータ７９に対する更新を行う。トラフィックレポータ７９は、図１２（Ｂ）を参照しながら説明したアナライザを介するなどの、トラフィックレポータ７９自身またはトラフィックマネージャ７０以外のソースから、トラフィック条件および別のネットワーク情報に関する情報を取得する。トラフィックレポータ７９に関する追加の詳細情報およびトラフィックマネージャ７０の動作について図１２（Ｄ）と１２（Ｅ）を参照しながら以下説明する。
【００８３】
図１２（Ｄ）を参照しながら、トラフィックマネージャ７０の動作方法２５０について以下説明する。２５２で、トラフィックマネージャ７０は手元にある情報に基づいてルーティング指示を出力する。トラフィックマネージャ７０は、図１２（Ａ）と１２（Ｂ）を参照しながら上述したような任意の好適な方法でルーティング指示を出力する。例えば、トラフィックマネージャ７０は、ネットワークのデータベースまたはマップを好適に有し、ネットワーク状態とトラフィックとに関する情報を有する。２５４で、トラフィックマネージャ７０は、トラフィックレポータ７９から受信報告があるかどうかを判定する。トラフィックレポートを受信していた場合、トラフィックマネージャ７０は、２５６で最新のトラフィック条件を用いて自身のデータベースを更新する。
【００８４】
２５８で、トラフィックマネージャ７０は、自身のデータベースの保守管理中に通常のコースの処理でローカルトラフィック条件を好適にモニタする。２６０で、トラフィックマネージャ７０が何らかの著しい変化を検出した場合、トラフィックマネージャ７０はトラフィックレポータ７９に対してこれらの変化について報告を行う。トラフィックマネージャ７０は、現在のローカルトラフィック条件をデータベースに記憶された条件と比較して、上記の変化がいくつかの点で著しいものであるかどうかを判定する。トラフィックマネージャ７０は、上記変化を何らかの変化に照らして、ある絶対値を超える変化に照らして、あるいは、上記変化が何らかの割合を上回った場合に著しいものであると判定することができる。次いで、トラフィックマネージャ７０は、２５２で、そのデータベース内の情報に基づいてルーティング指示を出力し続ける。
【００８５】
２５６でデータベースの更新と保守管理とを行う際に、トラフィックマネージャ７０はネットワーク状態を示す何らかの履歴測定値を好適に有し、トラフィックレポート内の受信データの若干またはすべてをリアルタイムトラフィック条件として保存する。トラフィック条件の履歴測定値はトラフィック条件の決定時に、したがって、ルーティング指示の出力時にデフォルトにより利用される。トラフィックマネージャ７０は、トラフィックレポータ７９を介して提供されるリアルタイムトラフィック条件を好適に参照して、デフォルトのデータセットの利用時に例外が生じるかどうかの判定を行う。したがって、２５２におけるトラフィックマネージャ７０は、データベースに記憶されたデフォルトデータを検査し、次いで、第２に、このデフォルトデータから導き出される予備のセットのルーティング指示の変更時に、トラフィックレポータ７９から出される何らかのトラフィックレポートが特定の要求時に関係があるかどうか、あるいは、該トラフィックレポートが関係があるかどうかを見るために調べるという２段階の分析を実行する。
【００８６】
図１２（Ｅ）を参照しながらトラフィックレポータ７９の動作方法２８０について以下説明する。２８２で、トラフィックレポータ７９はトラフィックマネージャ７０から任意のトラフィックレポートを受信する。上述のように、トラフィックマネージャ７０により作成されたこれらのトラフィックレポートはトラフィックマネージャ７０自体により検出されるローカルトラフィックのリアルタイムの変化に関連するものであってもよい。２８２で、トラフィックレポータ７９は、アナライザなどの別のソースを介して、ネットワーク情報と、トラフィック条件７０に関するその他の上記のような情報とを受信することができる。２８６で、トラフィックレポータ７９はネットワーク上で自身の分析を実施して応答時間、トラフィックの輻輳状態、利用可能な帯域幅、利用可能な容量、トラフィックパターン、待ち時間とスピード、リンクまたはノードの健康状態または状態、などを決定する。ネットワークのデータベースまたはマップの更新時に、２８２または２８６で収集されたデータのすべては２８４で利用される。
【００８７】
トラフィックレポータ７９は、ネットワークでリアルタイム条件のデータベースの保守管理を行い、さらに、履歴測定値の何らかのバージョンの保守管理も好適に行う。２８８で、トラフィックレポータ７９はリアルタイムトラフィック条件を履歴測定値と比較して、リアルタイムトラフィック条件が著しい変化を表しているかどうかの判定を行う。トラフィックマネージャ７０の場合と同様、トラフィックレポータ７９は、何らかの条件の変化、変化の絶対値、または変化の割合における検査を含めて、リアルタイム条件が複数の方法でニュースに値するものであるかどうかを判定することができる。リアルタイムトラフィック条件が重要なものである場合、トラフィックレポータ７９はトラフィックマネージャ７０へトラフィックレポートを送信し、その結果これらのレポートは最新のトラフィック条件という利点を有することができる。トラフィックレポートの送信時に、２９０で、トラフィックレポータ７９は、トラフィックマネージャ７０が配置されている地理上の領域へ特別に仕立てられたトラフィックレポートを送信することが可能となる。言い換えれば、トラフィックレポータ７９は、トラフィックマネージャ７０に関係のないネットワークの領域または部分に対してリアルタイムのトラフィックレポートを送信せずに、当該地理上の領域すなわちネットワークエリアと関連するトラフィックマネージャ７０へトラフィックレポートを送信する。
【００８８】
トラフィックマネージャ７０にトラフィック条件をモニタさせ、トラフィック条件に関する報告を行わせる１つの利点として、さらに精密な事前評価をトラフィック条件から行うことができるという点が挙げられる。トラフィックマネージャ７０の数に関して、および、ネットワークを通じるトラフィックマネージャ７０の分散に関してトラフィック条件の精度と事前評価とは向上する。例えば、図１２（Ｃ）はアラスカを除く米国大陸を通じて分散された７つのトラフィックマネージャ７０を示す図である。この図では、トラフィックマネージャ７０は、北東部、南東部、中西部、南西、北西部、西部並びにロッキー山脈地域などの異なる領域を通じて分散される。トラフィックマネージャ７０のこの表示は単に一例にすぎない。実際には、トラフィックマネージャ７０は領域に基づく方式よりも好適にポピュレートされる。トラフィックマネージャ７０を単に上記領域レベルで分散するだけであれば、トラフィックレポータ７９は、トラフィックマネージャ７０から該レポータ７９が個々のドメインの範囲内で受信することができる限定された情報量を含むことになる。多数のトラフィックマネージャ７０を個々のドメインの範囲内に分散して、トラフィックレポータ７９は、地理上の所在位置に関する、または、個々のドメイン内のさらに耳ざわりな音のする（ｇｒａｎｕｌａｒ）領域に関する補足情報から利益が得られるだけでなく、トラフィックマネージャ７０からの報告の精度を保証するためにクロスチェックを行う能力も有している。したがって、トラフィックレポートを収集する際に、顧客のサイトと関連づけられたトラフィックマネージャがトラフィックレポータ７９を補助していることを考慮して、さらに多くの顧客が上記トラフィックレポートに申し込んだとき、顧客は、有用でかつ正確な情報をトラフィックレポータ７９から得ることができる。
【００８９】
ＩＩＩ．プロファイルサーバとプロファイル発見サーバ
上述のように、収集並びに決定システム５０はユーザ５に関する地理情報を記憶し、ウェブサイト６０または別の要求者４０へこの情報を提供することができる。本発明の別の態様によれば、ウェブサイト６０および別の要求者４０からの要求に基づいて、ユーザ５の地理上の所在位置以外の情報が追跡される。図１３を参照すると、プロファイルサーバ８０はインターネットを介してウェブサイト６０と接続され、さらに、プロファイル発見サーバ９０と接続されている。このプロファイル発見サーバ９０も、やはりインターネットを介したり、別のネットワーク接続を介したり、あるいは直接接続されていたりするものであってもよい。プロファイルサーバ８０は、要求ハンドラ８２、データベースサーバエンジン８３およびデータベース８４を備えている。以下の説明からさらに明らかになるように、データベース８４には、地勢データベース８４Ａ、認証データベース８４Ｂ、ネットワークスピードデータベース８４Ｃ、プロファイルデータベース８４Ｄ、およびインターフェースデータベース８４Ｅが含まれる。プロファイル発見サーバ９０には、発見エンジン９２、プロファイラ９３、およびデータベース９４が含まれる。データベース９４には、一般的なエリア名称データベース９４Ａ、広域エリア構造データベース９４Ｂ、およびＭＡＣアドレス所有者データベース９４Ｃが含まれる。
【００９０】
Ａ．プロファイラ
一般に、プロファイルサーバ８０とプロファイル発見サーバ９０とは、種々のウェブサイト６０および別の要求者４０とのインターネットユーザのインタラクションに基づいて、特定のＩＰアドレスに関する情報を収集するものである。この情報には、訪問されたウェブサイト６０のタイプ、スポーツサイトなどのヒットしたページ、オークションサイト、ニュースサイト、ｅコマースサイト、地理情報、帯域幅情報、およびウェブサイト６０で過ごした時間が含まれる（但しこれらに限定されるものではない）。この情報のすべてはデータベース８４へ戻るネットワークでウェブサイト６０から送出される。この情報はＩＰアドレスによって高性能データベース８４に記憶され、訪問されたオンサイト６０および個々のサイト６０の範囲内で行われたアクションに基づいて、ＩＰアドレスの精巧なプロファイルが形成される。このプロファイルは、所定のカテゴリに準じる一連の優先順位として、または、所定のカテゴリとは反対の一連の優先順位として記憶される。ウェブサイト６０とユーザ５のブラウザ間でプロファイルの保守管理を行うためのインタラクションは必ずしも必要ではない。このプロファイリング方法は、非常に好ましくないものであることがユーザにより知られている何らかのクッキの利用を必要とするものではないことが重要である。ネットワークトポロジにより誘起される困難に起因してクッキは好ましいものではないが、クッキを用いて或るユーザ５のプライバシ問題点について注意深く考慮を払った後に、ユーザ５の追跡を行ってもよい。
【００９１】
ユーザ５がネットワークでウェブサイト６０にアクセスするとき、ユーザのＩＰアドレス６０に関するプロファイルされた情報が、データベース８４からウェブサイト６０に在る位置ターゲッタ６４または６４’へ送信される。以上説明したように、位置ターゲッタ６４または６４’あるいはウェブサーバ６２により、当該ユーザ５の詳細なプロファイルに基づいてウェブサイト６０に予め設定された構成またはページをユーザ５に対して動的に示すことが可能となる。さらに、現時点のユーザ５の優先順位に対応するユーザ５の優先順位を用いて、現時点のユーザ５が閲覧することが望ましいようなコンテンツを予測することができる。プロファイルされた情報は以下のものを含むことも可能である（但しこれらに限定されるものではない）：地理上の所在位置、インターネットとの接続スピード、ニュース、天候、スポーツ、娯楽、スポーツ商品、衣料商品、などのうちのいずれかに対する好き／嫌いの傾向。
【００９２】
一例として、アリスとボブという名前の２人のユーザがいるとする。アリスはウェブサイト、ｗｗｗ．ｓｏｍｅｒａｎｄｏｍｓｉｔｅ．ｃｏｍを訪問する。このサイトは、ｓｅｒｖｅｒ．ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔなどのプロファイルサーバ８０に、アリスの発信地と彼女の好き／嫌いについて問い合わせる。データベース８４はアリスについてのレコードを持っていないが、地勢データベース８４Ａから彼女がジョージア州アトランタから発信していることを知り、ウェブサイトにその趣旨を通知する。アリスの地理情報を利用して、ウェブサイトは、彼女の地理上の所在位置に関連する特別に仕立てられたウェブページをアリスに送信する。例えば、そのウェブページにはアトランタの天気予報やアトランタに関連するニュースの見出しが含まれる。アリスはウェブサイトの訪問を続けて、サイトから傘を購入し、次いで、彼女の訪問を終了する。ウェブサイトは、プロファイルサーバ８０とデータベース８４とにアリスがサイトから傘を購入したことを知らせる。次いで、ボブがサイトｗｗｗ．ｓｏｍｅｒａｎｄｏｍｓｉｔｅ．ｃｏｍを訪問する。サイトは再びｓｅｒｖｅｒ．ｄｉｇｉｔａｌｅｎｖｏｙ．ｎｅｔなどのプロファイルサーバ８０にボブに関する問い合わせを行う。サーバ８０は、ボブに関する情報を求めてデータベース８４を覗いて見るが、何も発見しない。しかし、サーバ８０は地勢データベース８４Ａを再度覗いて見る。そして、ボブがジョージア州アトランタから発信していると判定する。また、アリスから部分的に収集され、プロファイルデータベース８４Ｄに記憶されたデータに基づいて、プロファイルサーバ８０はジョージア州アトランタの人々は傘を買うのが好きであるかもしれないと推論する。サイトはボブの地理情報、並びに、アトランタの人々が傘を買う傾向を有するという事実を利用して、天候とニュースなどのアトランタ情報を持つウェブページと、傘を買うのはいかがですかという提案とをボブへ送信する。ボブが傘を買うと、サイトはサーバ８０へこの情報を送信し、それによって傘を買うというアトランタ人のさらに大きい傾向が示される。
【００９３】
さらに、ＩＰアドレスがネットワークで以前にヒットしたいくつかのｅコマースサイトとスポーツサイトとを含むこと、および、アドレスがカリフォルニアに位置することをプロファイルサーバ８０内のプロファイルデータベース８４Ｄに記憶されたプロファイルが示した場合、ウェブサイトは、カリフォルニア人が購入する頻度が高い、サーフィンボードなどの販売用スポーツ商品を示すように動的に特別に仕立てることができる。この方法は、ｅコマースと情報サイトとを用いてユーザに対してカスタマイズした経験をサポートするものである。
【００９４】
ネットワーク内の、あるいは、ネットワーク外のウェブサイトに対して上記情報の編集を行うことができる。ネットワークの外側のウェブサイトは、一般にそのウェブサイトにヒットするユーザのプロファイルを発展させることができる。ウェブサイトのログファイルのチェックを行うことが可能であり、中央サーバに記憶されたプロファイル済みＩＰアドレス情報に対してＩＰアドレスを比較することが可能である。この比較により、ウェブサイトは、そのトラフィックを分析し、サイトにヒットするユーザの一般的プロファイルを決定することが可能となる。
【００９５】
“陳腐になった”情報を除去するために、データベースサーバエンジン８３は時折プロファイルサーバ８０内のデータベース８４のパージを行う。例えば、旅行に関する情報の調査に関心を持っているユーザ５はその旅行が終了した後にはおそらく当該旅行の販売促進を見続けたいとは思わない。データベース８４のパージを行うことにより、古い優先順位が解除され、現在の関心と要望とによって更新される。
【００９６】
Ｂ．コンテンツレジストリ
上記記載例に加えて、プロファイルサーバ８０は、或るタイプの情報内容に対するエンドユーザの要望を登録するメカニズムをエンドユーザ５に設けて、サービスを受けることについてエンドユーザのシステムに許可あるいは不許可を与えることができる。この登録はＩＰアドレスに基づいて行われ、登録の権利にはアクセス権限が与えられ、ＩＰアドレスは登録された所有者に限定される。これらの所有者はインターネットを介してプロファイルサーバ８０にアクセスし、これら所有者のＩＰアドレス範囲に対してサービスを受けることを許可あるいは不許可にしたいと思うインターネットコンテンツの種別を特定する。特定のＩＰアドレスまたはアドレスのブロックによって受信が許可あるいは不許可にされたインターネットコンテンツの種別は、認証データベース８４Ｂ内のプロファイルサーバ８０により記憶される。ウェブサイト６０などのインターネットコンテンツプロバイダは、プロファイルサーバ８０に照会を行い、次いで、該プロファイルサーバ８０は認証データベース８４Ｂに照会を行い、上記ＩＰアドレスレジストリに基づいて上記コンテンツプロバイダのコンテンツの受信を望むあるいは望まないユーザ５を特定する。
【００９７】
例えば、学校はそのＩＰ範囲を登録し、そのシステムへ送信された成人向けコンテンツを不許可にするようにプロファイルサーバ８０に登録する。学校のＩＰの範囲内のマシーンから成人向けサイトへアクセスが行われると、成人向けサイトはプロファイルサーバ８０を用いてチェックを行い、成人向けサイトが提供する当該コンテンツの当該ＩＰアドレスへの送信が許可されていないことを知ることになる。成人向けコンテンツの代わりに、成人向けサイトは、当該サイト内のコンテンツのサービスをユーザのマシーンに対して行うことができない旨の通知をユーザに送信する。この一連のイベントにより、エンドＩＰアドレス所有者は、彼らが制御するマシーンに対して配信とサービスとが行われるコンテンツの制御を行うことが可能となる。
【００９８】
Ｃ．帯域幅レジストリ
ユーザ５へ送信するコンテンツ量を決定する際、プロファイルサーバ８０に依拠することが望ましい。ウェブサイト６０は、ある特定のユーザに対して利用可能な帯域幅を動的に決定し、プロファイルサーバ８０へこの情報を出力し、ネットワークのスピードデータベース８４Ｃの中にこの情報を記憶する。さらに、ウェブサイト６０は、ある特定のユーザ５がウェブサイト６０からパケットをダウンロードできるレートとスピードとをチェックし、ウェブサイト６０によって、ウェブサイト６４からエンドユーザ５への利用可能な帯域幅が決定される。エンドユーザ５へのパス・ルート上で、または、ユーザ５の端末装置との最後のリンクにおいて、ウェブサイト６０で輻輳状態が生じた場合、ウェブサイト６０は当該ユーザ５に対して利用可能な帯域幅に限度を設ける。この情報に基づいて、ウェブサイト６０はユーザ６０へ送信される情報量を動的に減らすことが可能となり、その結果、ユーザ５が感知するダウンロード時間が増加する。帯域幅情報はプロファイルサーバ８０へ好適に送信され、ネットワークのスピードデータベース８４Ｃに記憶される結果、必ずしも帯域幅自体の測定を行う必要なく、ネットワーク内の別のサイト６０がこの帯域幅情報の利点を持つことになる。
【００９９】
“陳腐になった”帯域幅情報を除去するために、データベースサーバエンジン８３は時折ネットワークスピードデータベース８４Ｃ内の情報のパージを行う。例えば、ウェブサイト６０とユーザ５間の輻輳状態は通常持続することはない。
【０１００】
Ｄ．インタフェースレジストリ
ウェブサイト６０は、ユーザ５がウェブサイト６０を閲覧しなければならないようにインタフェースを動的に決定できることが望ましい。このユーザインタフェース情報は、登録処理によってデータベース８４Ｅに配置してもよいし、ＩＳＰから取得してもよいし、あるいは別の方法で検出または発見してもよい。個人用情報機器（ＰＤＡ）のユーザには、ＰＤＡの限定された記憶容量に適合するように、限られた画像のウェブサイト６０、あるいは、画像を伴わないウェブサイト６０が示される。
【０１０１】
ウェブサイト６０は、ユーザ５がアクセスする時期についてプロファイルサーバ８０に照会する。次いで、プロファイルサーバ８０は、インターフェースデータベース８４Ｅに照会を行い、入手可能であれば、特定のＩＰアドレスと関連するタイプのインタフェースを検索する。プロファイルサーバ８０は、データベース８４Ｅの中にすべてのユーザを記憶し、ユーザ５が備えているディスプレイインタフェースについてウェブサイト６０に通知する。この情報に基づいて、ウェブサイト６０はユーザ５へ送信する情報の特別仕立てを行う。
【０１０２】
Ｅ．処理方法
図１４（Ａ）と１４（Ｂ）とを参照しながらプロファイルサーバ８０並びにプロファイル発見サーバ９０のための望ましい処理方法１６０について以下説明する。１６２で、プロファイルサーバ８０に対して照会すべきＩＰアドレスまたはホスト名が与えられる。１６３で、プロファイルサーバ８０によって、情報を受信するアクセス権限が要求者に与えられているかどうかが判定され、アクセス権限が与えられていなければ、１６６で、要求者に対して当該情報が未知である旨が告げられる。１６３で要求者にアクセス権限が与えられているかどうかに関する問合せが好適に実行され、プロファイルサーバ８０とプロファイル発見サーバ９０とに対するアクセスに対して料金が支払われた当該エンティティのみがデータを取得することになる。要求者に対してアクセス権限が与えられている場合、１６４におけるプロファイルサーバはアドレスのプロファイルが既知のものであるかどうかを判定する。当該アドレス用のプロファイルが既知のものであれば、プロファイルサーバ８０は１６５で要求者へ要求された情報を送信し、既知のものでなければ、プロファイルサーバ８０は１６６で要求者に情報が未知である旨を通知する。
【０１０３】
プロファイルサーバ８０にとって未知の情報である場合、プロファイルサーバ８０は１６７でプロファイル発見サーバ９０へ情報を渡す。１６８で、プロファイル発見サーバはアドレスに対するルートを決定し、１６９で、プロファイルサーバ８０からのルートのすべてのホストに関する情報を取得し、次いで、１７０で、任意の未知のホストがルート内に残されているかどうかを決定する。未知のホストがルート内に残されていれば、１７１で、プロファイル発見サーバ９０はエラー条件を返信し、オペレータに通知する。
【０１０４】
ルートに残された個々のホスト名に対して、１７２でプロファイル発見サーバ９０は次に未知のホストに対するホスト名が存在するかどうかを判定する。存在すれば、１７３でプロファイル発見サーバが一般的ホスト名命名規定および／または地球規模の国ベースの命名規定に基づいて所在位置の決定を試みる。１７４でプロファイル発見サーバ９０はホストがＮＴＰの照会に応答するかどうかをチェックし、応答すれば１７５で、ＮＴＰ応答に基づいて時間帯の決定を試みる。１７６で、プロファイル発見サーバ９０はホストがＳＮＭＰの照会に対して応答するかどうかをチェックし、応答すれば１７７で、公衆ＳＮＭＰ応答に基づいて、所在位置と、マシーンの種別と、接続スピードとの決定を試みる。次に、１７８で、プロファイル発見サーバ９０は、ホストがＭＡＣアドレスを持っているかどうかをチェックし、該アドレスを持っていれば、所定のＭＡＣアドレス委任に基づいてマシーンの種別と、接続スピードとの決定を試みる。
【０１０５】
１８０で、何らかの追加の未知のホストが存在するかどうかがプロファイル発見サーバ９０によって判定される。追加の未知のホストが存在すれば、プロファイル発見サーバ９０は１７２へ戻り、ホスト名が利用可能であるかどうかをチェックする。未知のホストが存在しない場合、プロファイル発見サーバ９０は、１８１で情報を内挿して、任意の残りの情報を決定し、１８２で、将来再査するために内挿済みデータのフラグを行い、次いで１８３で、すべての発見され、内挿されたデータをプロファイルサーバ８０で保存する。
【０１０６】
ＩＶ．専用ネットワーク内での地理上の所在位置の決定
本発明の第２の実施形態に準拠するネットワークについて図１５を参照しながら以下説明する。このネットワークはインターネット７などの外部ネットワーク７と内部ネットワーク９との双方を備える。外部ＩＰアドレスと対をなす内部ＩＰアドレスがネットワーク内の個々のマシーンに設けられるように内部ネットワーク９は構成される。内部ネットワーク９内でのすべてのトラフィックとデータのトランスポートとが内部ＩＰアドレスを介して行われるのに対して、インターネット７から出たり、入ったりするように、ネットワークの外側へ出て行ったり、ネットワークの外側から入って来たりするように方向づけられたいずれのトラフィックの外部ＩＰアドレスも利用される。このタイプのネットワーク９では、最低でも、ユーザ５とプロキシサーバ３６あるいはインターネット７とつながる別のインタフェースが対をなす内部ＩＰと外部ＩＰとを認知して、内部ネットワーク９をトラフィックが貫通できるようにする必要がある。この専用ネットワークは、商用エンティティのＬＡＮやＷＡＮなどの専用ネットワークを備えるものであってもよいし、あるいは、ＡＯＬのネットワークなどのような半専用ネットワークであってもよい。
【０１０７】
このネットワーク９では、内部ネットワーク９がトラフィックを内部ＩＰアドレスへトランスポートする方法を知っている限り、任意の特定の外部ＩＰアドレスは任意の内部ＩＰアドレスと任意に対をなすことができる。内部ネットワーク９が内部ＩＰアドレスと外部ＩＰアドレス間の対応関係を認知している限り、外部アドレス内部での任意のマッピング方法の採用が可能である。
【０１０８】
外部アドレスが任意のものであってもよいため、ネットワーク９の外部アドレスに基づいてユーザ５の地理上の所在位置を決定しようとする際、このネットワーク９は固有の問題を提示することになる。例えば、このネットワークアーキテクチャの結果として、ユーザ５とつながるネットワークのトレースを試みる人は誰も、プロキシサーバ３６からの１つのホップアウェィとしてユーザのＩＰアドレスを見ること、及び、内部ネットワーク９内のいずれの中間ルータも見ることはないという点が挙げられる。内部ネットワーク９内でトレースができないというこの事実が当該ネットワーク９上でのユーザ５の地理上の所在位置の決定を挫折させる場合がある。というのは、すべてのユーザ５がプロキシサーバ３６の所在位置に位置するように見えるからである。
【０１０９】
本発明によれば、このタイプのネットワーク９の範囲内でユーザ５の地理上の所在位置を決定するために、内部ネットワーク９は一般に安定していなければならない。言い換えれば、内部ネットワーク９内での番号付け方式は時間と共に大きく変化するものであってはならない。通常、このタイプのネットワーク９内で効率のよい情報ルートの指定を行うために、内部ＩＰアドレスが一定ポイントに存在するように割り当てられ、その結果内部ネットワーク９全体が情報ルートの内部ＩＰアドレスへの指定方法を認知することになる。そうでない場合、内部アドレスの所在位置に関して内部ネットワーク９を通じて現在進行中の方法で通知が行われる。これらの継続する“通知”はネットワークの不必要なオーバヘッドを誘起することになる。
【０１１０】
本発明のこの実施形態によれば、ネットワーク９は内部サーバ９９を備え、この内部サーバ９９は、内部ネットワーク９内のユーザ５からの要求に対してサービスを提供する１つのマシーンまたは１組のマシーンを備えるものであってもよい。一般に、内部サーバ９９は、情報に対する要求を受け入れ、ユーザ５などの要求側マシーンの内部ＩＰアドレスを正確に特定する。要求側マシーンの内部ＩＰアドレスを正確に特定ができることにより、内部サーバ９９は、要求側マシーンの内部ＩＰアドレスを当該内部ＩＰアドレスの地理上の所在位置とマップして、要求側マシーンの地理上の所在位置の正確な特定を図る。
【０１１１】
内部ネットワーク９内のユーザ５の地理上の所在位置の決定方法２００について図１６を参照しながら以下説明する。２０２で、内部ＩＰアドレスＩＮＴＥＲＮＡＬと外部ＩＰアドレスＩＰ  ＥＸＴＥＲＮＡＬとを備えたユーザ５は内部ネットワーク９の外側のサーバからの情報を要求する。２０３で、プロキシサーバ３６は要求を受け取り、ユーザの外部ＩＰアドレスと共にウェブサイト６０へ上記要求を転送する。ウェブサイト６０は、この要求が専用内部ネットワークから出されたものであると２０４で判定する。２０５で、ユーザ５のＥＸＴＥＲＮＡＬ  ＩＰに基づいて、ウェブサイト６０は、ユーザ５の地理上の所在位置を発見する際に補助を行う内部サーバ９９がネットワーク９内に存在し、この内部サーバ９９へユーザ５をリダイレクトすると判定する。したがって、このリダイレクトの結果、ユーザ５は内部サーバ９９へ情報要求を送信する。２０６で、内部サーバ９９は、ユーザ５からの要求を調べ、その要求がウェブサイト６０からリダイレクトされたものであると判定する。内部サーバ９９は、ヘッダ内に含まれる参照ＵＲＬを通じて、あるいは別の方法で、リダイレクトのＵＲＬなどの、内部サーバ９９から要求された情報に基づいてこのリダイレクトを検出することができる。
【０１１２】
２０７で、内部サーバ９９はユーザ５の地理上の所在位置を決定する。内部サーバ９９は本発明に基づく方法によってユーザ５の地理上の所在位置を決定することができる。内部ＩＰアドレスを知るとすぐに、内部サーバ９９は専用ＩＰアドレスと地理上の所在位置間のマッピングを有するデータベース内のルックアップを実行する。ユーザ登録によってデータベースを引き出すことができ、ネットワークのプロバイダあるいは別の何らかのエンティティによりこのデータベースの保守管理をすることができる。したがって、内部サーバ９９は、このデータベースに照会を行って、ネットワーク９内の任意のユーザ５の地理上の所在位置を取得することができる。
【０１１３】
内部サーバ９９は別の方法でユーザ５に関する地理上の所在位置情報を取得することができる。例えば、内部サーバ９９はネットワーク９内のユーザへのルートを取得し、中間ホストの地理上の所在位置を導き出し、次いで、ルートを分析して、ホストまたはユーザ５の地理上の所在位置を決定することができる。別の例として、内部サーバ９９はネットワーク９内のデータベースから上記地理上の所在位置を直接取得することができる。個々のユーザの地理上の所在位置を有するデータベースの保守管理は、ネットワーク９内の範囲内のプロキシサーバ３６により、内部サーバ９９によりあるいは別の何らかのマシーンにより行うことができる。したがって内部サーバ９９は、ユーザの地理上の所在位置に対する要求への応答時におよび／またはユーザ５のために地理上の所在位置のユーザ５自身のデータベースの構成時に上記データベースに照会を行うことができる。さらに別の例として、内部サーバ５は図３を参照して説明した方法１１１を利用してもよい。例えば、上記データのすべてを供給するネットワーク９のプロバイダとの関係を通じてこのデータベースの記入を行うようにしてもよい。このデータベースは、ネットワークプロバイダのダイアルイン・ポイント・オブ・プレゼンス（ＰＯＰ）のすべての自動ダイヤル呼出しを行うことにより、および、どの専用ＩＰアドレスが個々のダイアルインＰＯＰで使用されているかを判定することにより、少なくとも部分的に得られたたものであってもよい。このようにして、内部サーバ９９はそのＩＰ＃ＩＮＴＥＲＮＡＬアドレスと地理上の所在位置マッピングとに基づいてユーザ５の地理上の所在位置を決定することが可能となる。
【０１１４】
２０８で、内部サーバ９９は、ユーザ５の地理上の所在位置に関する情報を追加してウェブサイト６０へ戻るユーザ５のリダイレクトを行う。クッキの利用によって、あるいは、複数の方法によってＵＲＬの符号化を行うことによりウェブサイトへ上記地理情報を送信してもよい。上述のように、ウェブサイト６０は、ユーザ５の地理情報に基づいてユーザ５への転送情報を調整することができる。ウェブサイト６０は、ユーザ５に対してこのような情報を提示する前にコンテンツ、広告などの特別仕立てを行うものであってもよい。方法２００は、ユーザ５からの介在を必要とせずに、すべてのリダイレクションと分析とを自動的に行う。また、専用ＩＰアドレスの地理上の所在位置を決定する方法２００は個々のユーザのＩＰアドレスを決定する方法とは全く関係がない。
【０１１５】
図１５と１６を参照しながら以上説明したように、専用ネットワーク９内のユーザ５からの要求はプロキシサーバ３６を介してウェブサイト６０へ送信され、次いで、ウェブサイト６０は、上記要求が専用ネットワーク９内から発信したかどうかを判定する。内部サーバに対して要求のリダイレクトを行う代替方法２２０について図１７と１８を参照しながら以下説明する。２２１で、ユーザ５は要求を開始し、この要求はプロキシサーバ３６へ渡され、このプロキシサーバ３６はまず、ＤＮＳサーバ８に対して問合せを送信して、上記要求と関連するＩＰアドレスの取得を図る。一般に、ＤＮＳサーバ８はドメイン名の問合せを受信し、ＩＰアドレスの返送によりこれらの問合せを分析する。しかし、本発明の場合、２２３で、ＤＮＳサーバ８はユーザ５からの上記問合せに関連するＩＰアドレスに対して厳しいルックアップを実行せず、代わりに、その問合せが専用ネットワーク９内から発信したかものかどうかの判定をまず行う。上記問合せが専用ネットワーク９内で発信したものでなかった場合、２２５で、外部サーバ５０用のＩＰアドレスを返送することによりＤＮＳサーバ８は上記問合せを分析する。ユーザ５は外部サーバ５０へ送られ、外部サーバ５０は２２６でユーザ５の地理上の所在位置を決定し、地理上の所在位置情報と共にウェブサーバ６０へユーザ５をリダイレクトする。２３４で、ウェブサーバ６０は、上述の方法のような、無数の方法のうちの任意の１つの方法で地理上の所在位置情報を利用する。
【０１１６】
上記問合せが確かに専用ネットワーク９内で発信したものであるとＤＮＳサーバ８が２３０で判定した場合、ＤＮＳサーバ８は内部サーバ９９用のＩＰアドレスを返送することによりこの問合せを分析する。この結果、ＤＮＳサーバ８によって外部サーバへ送られる代わりにユーザ５は内部サーバ９９へ送られることになる。内部サーバ９９は２３１でユーザ５の地理上の所在位置を決定すし、２３２で地理上の所在位置情報と共にウェブサーバ６０へユーザ５をリダイレクトして、ウェブサーバ６０が２３４でこの情報を利用できるようにする。この結果、本発明の場合、プロキシサーバ３６からウェブサーバ６０へ、次いで、内部サーバ９９へユーザ５を送る代りに、方法２２０は、ＤＮＳサーバ８がユーザ５のリダイレクトを行うことによるさらに直接的かつ効率的な方法となる。
【０１１７】
本発明の上述の好ましい実施形態についての説明は、専ら例示と説明とを目的とするものであり、網羅的であること、あるいは、開示された正確な形態に本発明を限定することを意図するものではない。上述の教示を考慮して多くの改変と変更を行うことが可能である。
【０１１８】
本発明の例示の態様では、ユーザ５はパーソナルコンピュータ（ＰＣ）により表されている。当業者には理解できるように、ユーザはＰＣを介する以外にも多数の方法でネットワークにアクセスすることができる。例えば、ユーザは、移動電話、個人用情報機器（ＰＤＡ）、ラップトップコンピュータ、デジタルＴＶ、ウェブＴＶおよびその他のＴＶ製品を利用してもよい。本発明は、これらのタイプの製品と共に利用することが可能であり、新たな製品並びに新しいブランド品、モデル、規格あるいは既存製品の変形された形を適合することができる。
【０１１９】
任意のタイプの製品または装置に加えて、ユーザ５は効果的で、適切な方法でネットワークにアクセスすることができる。言うまでもなく、ネットワークは情報を受信する製品によって変わるものであるが、上記ネットワークにとして、ＡＭＰＳ、ＰＣＳ、ＧＳＭ、ＮＡＭＰＳ、ＵＳＤＣ、ＣＤＰＤ、ＩＳ−９５、ＧＳＣ、ＰＯＣＳＡＧ、ＦＬＥＸ、ＤＣＳ−１９００、ＰＡＣＳ、ＭＩＲＳ、ｅ−ＴＡＣＳ、ＮＭＴ、Ｃ−４５０、ＥＲＭＥＳ、ＣＤ２、ＤＥＣＴ、ＤＣＳ−１８００、ＪＴＡＣＳ、ＰＤＣ、ＮＴＴ、ＮＴＡＣＳ、ＮＥＣ、ＰＨＳ、または通信衛星システムが挙げられる（但しこれらに限定されるものではない）。ラップトップコンピュータの場合、ネットワークは、セルラデジタルパケットデータ（ＣＤＰＤ）ネットワーク、その他の任意のパケットデジタルまたはアナログネットワーク、回線交換型デジタルまたはアナログデータネットワーク、無線ＡＴＭまたはフレームリレーネットワーク、ＥＤＧＥ、ＣＤＭＡＯＮＥ、または一般パケット無線サービス（ＧＰＲＳ）ネットワークを含むものであってもよい。ＴＶ製品の場合、ネットワークはインターネット、同軸ケーブルネットワーク、ハイブリッド型ファイバ同軸ケーブルシステム、ファイバ配信ネットワーク、通信衛星システム、地上波無線放送ネットワーク、無線ネットワークまたは赤外線ネットワークを含むものであってもよい。移動電話とラップトップコンピュータへ、並びに、他の無線装置へ情報を配信する同じタイプのネットワークは、ＰＤＡへ情報を配信することも可能である。同様に、ＴＶ製品へ情報を配信する同じタイプのネットワークはデスクトップ型コンピュータへ情報を配信するものであってもよい。製品と関連する上述のタイプのネットワークが、単なる例示にすぎないこと、並びに、その他の既存のネットワーク並びに将来開発されるネットワークを採用してもよいこと、さらに、本発明がこれらのネットワークを含むものであってもよいことを理解されたい。
【０１２０】
上述のように、ウェブページに対するユーザ要求に対する場合と同様、インターネットトラフィックルートの指定時に本発明を利用してもよい。したがって、ユーザ５により送出される要求がワールドワイドウェブを介して送信されるｈｔｍｌページに対する要求を含むのに対して、本発明に基づくトラフィックマネージャは、ルート指定時に、あるいは、別のタイプのネットワークトラフィックの送信時に使用することが可能である。例えば、これらの要求は、ＨＴＭＬだけでなくＸＭＬ、ＷＡＰ、ＨＤＭＬおよび別のプロトコルも含むものであってもよい。さらに、本発明は、ある何らかの人間による入力またはアクションに応じて生成される要求、あるいは、システムまたは装置により自動的に生成されるような、人間の活動をまったく含まない要求も含むものである。したがって、本発明を用いてルート指定が可能なトラフィックにはネットワークにより運ばれたり、あるいは、ネットワークの利用と関連したりする任意のタイプのトラフィックが含まれる。
【０１２１】
ＩＰアドレスが４つの８ビット整数により表されるＩＰｖ４技術を示す例を用いて本発明について説明した。本発明は単にＩＰｖ４だけに限定されるものではく、別のアドレス指定方式に関しても利用可能である。例えば、ＩＰアドレスが一連の６個の数によって表されるＩＰｖ６技術と共に本発明を利用してもよい。
【０１２２】
本発明の原理、並びに、これら原理の実際の適用を説明するために、上記実施形態を選び、説明して、他の当業者が本発明と種々の実施形態とを利用できるように図った。また、特定の利用に適するような種々の変更についても熟慮した。
【図面の簡単な説明】
【０１２３】
【図１】図１は、本発明の好ましい実施形態に準拠する収集システムを備えたネットワークのブロック図である。
【図２】図２は、図１の収集システムの好ましい処理方法を描くフローチャートである。
【図３】図３は、インターネットサービスプロバイダ（ＩＳＰ）を介する地理情報の好ましい取得方法を描くフローチャートである。
【図４】図４は、本発明の好ましい実施形態に準拠する収集システムと決定システムとを備えたネットワークのブロック図である。
【図５】図５は、収集並びに決定システムのための好ましい作動方法を描くフローチャートである。
【図６】図６は、収集並びに決定システムと接続された位置ターゲッタを使用するウェブサーバのブロック図である。
【図７】図７は、図６のウェブサーバと位置ターゲッタの好ましい処理方法を描くフローチャートである。
【図８】図８は、ローカルな地理データベース並びに収集および決定システムへのアクセスを行う位置ターゲッタを使用するウェブサーバのブロック図である。
【図９】図９は、図８のウェブサーバと位置ターゲッタの好ましい処理方法を描くフローチャートである。
【図１０】図１０は、プロキシサーバを通じてユーザからの地理上の所在位置情報の収集を描くネットワークのブロック図である。
【図１１】図１１は、プロキシサーバを通じて地理情報を収集する好ましい処理方法を描くフローチャートである。
【図１２Ａ】図１２（Ａ）は、本発明の好ましい実施形態に準拠するトラフィックマネージャのブロック図である。
【図１２Ｂ】図１２（Ｂ）は、アナライザとネットワークトラフィックのネットワーク図である。
【図１２Ｃ】図１２（Ｃ）は、トラフィックレポータを含む、本発明の別の態様に準拠するネットワーク図である。
【図１２Ｄ】図１２（Ｄ）は、トラフィックマネージャの処理フローチャートである。
【図１２Ｅ】図１２（Ｅ）は、トラフィックレポータの処理フローチャートである。
【図１３】図１３は、本発明の好ましい実施形態に準拠するプロファイルサーバとプロファイル発見サーバとを備えたネットワークのブロック図である。
【図１４Ａ】図１４（Ａ）は、図１３のプロファイルサーバとプロファイル発見サーバの好ましい処理方法を描くフローチャートである。
【図１４Ｂ】図１４（Ｂ）は、図１３のプロファイルサーバとプロファイル発見サーバの好ましい処理方法を描くフローチャートである。
【図１５】図１５は、本発明の第２の実施形態に準拠する収集システムを備えたネットワークのブロック図である。
【図１６】図１６は、図１５の収集システムの好ましい処理方法を描くフローチャートである。
【図１７】図１７は、本発明の第３の実施形態に準拠する収集システムとＤＮＳサーバとを備えたネットワークのブロック図である。
【図１８】図１８は、本発明の別の実施形態に準拠するドメイン名問合せを分析する方法を描くフローチャートである。
【図１】
2005522098.tif 000004
【図２】
2005522098.tif 000005
【図３】
2005522098.tif 000006
【図４】
2005522098.tif 000007
【図５】
2005522098.tif 000008
【図６】
2005522098.tif 000009
【図７】
2005522098.tif 000010
【図８】
2005522098.tif 000011
【図９】
2005522098.tif 000012
【図１０】
2005522098.tif 000013
【図１１】
2005522098.tif 000014
【図１２Ａ】
2005522098.tif 000015
【図１２Ｂ】
2005522098.tif 000016
【図１２Ｃ】
2005522098.tif 000017
【図１２Ｄ】
2005522098.tif 000018
【図１２Ｅ】
2005522098.tif 000019
【図１３】
2005522098.tif 000020
【図１４Ａ】
2005522098.tif 000021
【図１４Ｂ】
2005522098.tif 000022
【図１５】
2005522098.tif 000023
【図１６】
2005522098.tif 000024
【図１７】
2005522098.tif 000025
【図１８】
2005522098.tif 000026
【国際調査報告】
2005522098.tif 000027
2005522098.tif 000028
2005522098.tif 000029