(57)【特許請求の範囲】
【請求項１】
あるネットワークについてユーザーが利用可能な複数のアクセスポイントのうちの１つを選択して該ネットワークにユーザー端末を接続するアクセスポイント選択接続システムであって、ルーティング情報提供センターと、端末接続装置とからなり、前記ルーティング情報提供センターと端末接続装置との間の通信をＩＳＤＮ回線のＤチャネルパケットサービス等の論理多重可能な回線を用いて行うアクセスポイント選択接続システムにおいて、
端末接続装置は、
ユーザー端末から宛先アドレスを含む接続要求を受信した時、これをユーザーよりの通信相手のアドレスを含む問い合わせ要求としてルーティング情報提供センターへ送るとともにユーザー端末に仮アクセスポイントのアドレスを返す手段と、
ルーティング情報提供センターから選択されたアクセスポイントのアドレスの応答を受け、該選択されたアクセスポイントを介してユーザー端末をネットワークへ接続する手段と、
接続したアクセスポイントのアドレスと前記仮アクセスポイントのアドレスとの変換を行う手段とを備えた
ことを特徴とするアクセスポイント選択接続システム。
【請求項２】
ユーザー端末から前記選択されたアクセスポイントまでの回線が話中等で接続不能な場合、問い合わせ要求を再度、ルーティング情報提供センターへ送って応答を受け、接続可となるまでこれを繰り返すことを特徴とする請求項１記載のアクセスポイント選択接続システム。
【請求項３】
端末接続装置は、ユーザー端末上に実装されるソフトウェアもしくはハードウェアあるいはユーザー端末に接続されるターミナルアダプタまたはルーター上に実装されるソフトウェアもしくはハードウェアによって実現されることを特徴とする請求項１または２記載のアクセスポイント選択接続システム。
【請求項４】
ユーザーが利用可能な複数のアクセスポイントとは、該ユーザーが契約済みの２以上のインターネットサービスプロバイダーのそれぞれにおける少なくとも１つのアクセスポイント、もしくは該ユーザーが契約済みの１つのインターネットサービスプロバイダーにおける複数のアクセスポイントであることを特徴とする請求項１乃至３いずれか記載のアクセスポイント選択接続システム。
【請求項５】
あるネットワークについてユーザーが利用可能な複数のアクセスポイントのうちの１つを選択して該ネットワークにユーザー端末を接続するアクセスポイント選択接続システムのプログラムを記録した記憶媒体であって、
前記プログラムはコンピュータに読み取られた時、該コンピュータに、
ユーザー端末から宛先アドレスを含む接続要求を受信した時、これをユーザーよりの通信相手のアドレスを含む問い合わせ要求としてルーティング情報提供センターへ送るとともにユーザー端末に仮アクセスポイントのアドレスを返す手段と、
ルーティング情報提供センターから選択されたアクセスポイントのアドレスの応答を受け、該選択されたアクセスポイントを介してユーザー端末をネットワークへ接続する手段と、
接続したアクセスポイントのアドレスと前記仮アクセスポイントのアドレスとの変換を行う手段とを備えた端末接続装置を実現する
ことを特徴とするアクセスポイント選択接続システムのプログラムを記録した記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、あるネットワークへの接続に際し、該ネットワークについてユーザーが利用可能な複数のアクセスポイントのうち、該ネットワークにおける通信相手（着信先）までの混雑状況や前記複数のアクセスポイントへの回線の状況に応じて、最適なアクセスポイントを選択して接続するアクセスポイント選択接続システム及びそのプログラムを記録した記憶媒体に関するものである。
【０００２】
【従来の技術】
現在、ユーザーがインターネットへダイヤルアップ接続して特定のドメインへアクセスしようとする場合、ユーザーは契約しているインターネット接続事業者（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ：ＩＳＰ）（以下、プロバイダーと略す。）まで（もしくはそのアクセスポイントまで）電話回線を介して接続し、その後、ドメインネーム（アドレス）を指定することによりインターネットを介して特定のドメインにアクセスしていた。
【０００３】
また、会社等のイントラネットへのダイヤルアップ接続についても、ユーザーはそのアクセスポイントまで電話回線を介して接続し、その後、目的のサーバー等のネーム（アドレス）を指定することによりインターネットを介してイントラネット内の目的のサーバー等にアクセスしていた。
【０００４】
【発明が解決しようとする課題】
しかし、アクセスポイントより先のネットワークの混雑状況や、アクセスポイントまでの電話回線（アクセス回線）自体の状況（話中か空きか等）については、ユーザーが実際に接続を行うもしくは接続動作を行うまで知ることができなかった。このため、従来は、ユーザーが複数のプロバイダーと契約しているような場合や複数のアクセスポイントの電話番号を知っている場合でも、少なくとも一度は接続もしくは接続動作を行い、転送速度が遅いことや話中であることを認識してからでなければ、プロバイダーやアクセスポイントの電話番号を変えて接続し直すこともできず、煩雑な操作を強いられるとともに、一度接続してからの切り替えではその分、余計なコストがかかるという問題があった。
【０００５】
また、プロバイダーについてみると、各方面に太い回線を所有する大規模なプロバイダーの寡占状態が進み、小規模なプロバイダーは特定の方面にのみ太い回線を所有している等の特色があってもシェアの獲得が難しく、淘汰されつつあるという問題があった。
【０００６】
さらにまた、大規模なプロバイダーでは話中率を減らすために設備投資を最繁時に合わせて行い、市内や隣接地域に複数のアクセスポイントを設けている場合があるが、前述したようにアクセスポイントの変更にはユーザー側の煩雑な操作が必要であるため、ユーザーに効率的に利用させることが難しく、結果として設備の利用率の低下を招いていた。
【０００７】
本発明の目的は、ユーザーに煩雑な操作や余分なコストの負担を強いることなく、該ユーザーが利用可能な複数のアクセスポイントのうちの最適なアクセスポイントを選択してネットワークへの接続を可能とするアクセスポイント選択接続システム及びそのプログラムを記録した記憶媒体を提供することにある。
【０００８】
【課題を解決するための手段】
本発明では、前記目的を達成するため、あるネットワークについてユーザーが利用可能な複数のアクセスポイントのうちの１つを選択して該ネットワークにユーザー端末を接続するアクセスポイント選択接続システムであって、ネットワーク上の各アクセスポイント、サーバー、ドメイン、ノード等のアドレス及びこれらの間の混雑状況等を定期的に収集し蓄積しておき、ユーザーよりの通信相手のアドレスを含む問い合わせ要求に対して、前記蓄積情報を基に各アクセスポイントと通信相手とを結ぶルート及びスループットを予測し、これに従ってユーザーが利用可能な複数のアクセスポイントのうちで最適なアクセスポイントを選択して応答するルーティング情報提供センターと、ユーザー端末から宛先アドレスを含む接続要求を受信した時、ユーザーよりの通信相手のアドレスを含む問い合わせ要求として前記ルーティング情報提供センターへ送り、該ルーティング情報提供センターからの応答を受け、前記選択されたアクセスポイントを介してユーザー端末をネットワークへ接続する端末接続装置とからなり、前記ルーティング情報提供センターと端末接続装置との間の通信をＩＳＤＮ回線のＤチャネルパケットサービス等の論理多重可能な回線を用いて行うことを特徴とする。
【０００９】
本発明によれば、実際の接続以前に最適なアクセスポイントを認識することができるので、従来、通信途中に転送速度が遅いことに気づいて別のアクセスポイントへ接続し直した場合のように無駄なコストをかけることがなく、また、実際の接続は端末接続装置によって行うことができるので、ユーザーに煩雑な操作を強いることがない。
【００１０】
【発明の実施の形態】
図１は本発明をインターネットに適用した場合のシステム全体の概要を示すものである。
【００１１】
本システム（Ｅｎｄ  Ｐｏｉｎｔ  Ｒｏｕｔｉｎｇ：以下、ＥＰＲと略す。）は、大きく分けて、ネットワーク（インターネット）１に対してユーザーが利用可能な複数のアクセスポイント（契約済みのプロバイダーＡ，Ｂ，Ｃ）のいずれかを選択してユーザー端末２を接続する端末接続装置３と、インターネット１上の各プロバイダー、サーバー、ノード等のアドレスや混雑状況を収集し、各プロバイダーからインターネット１を介してユーザーの通信相手（サーバーａまたはｂ）にアクセスするルート及びスループットを予測し、最適なプロバイダーを選択して端末接続装置３に通知するルーティング情報提供センター４とからなっており、これらの間の通信はＩＳＤＮ回線のＤチャネルパケットサービス等の論理多重可能な回線を用いて行われる。
【００１２】
端末接続装置３（以下、単に接続装置と称す。）は、後述するように、
１．ユーザー端末２にそのＯＳ配下で動くソフトウェアもしくはハードウェアを実装する、
２．ユーザー端末２のシリアルインタフェース等に接続されるターミナルアダプタ（ＴＡ）にソフトウェアもしくはハードウェアを追加する、
３．ユーザー端末２にＬＡＮ接続されるダイヤルアップ等のＷＡＮ接続ルーターにソフトウェアもしくはハードウェア（既存で実装されているアドレス変換（Ｎｅｔｗｏｒｋ  Ａｄｒｅｓｓ  Ｔｒａｎｓｌａｔｅｒ：ＮＡＴ）機能を流用することにより新規追加分をなるべく少なくして）を追加する、
ことによって実現される。
【００１３】
どの手法によっても、ユーザー端末２におけるユーザーインターフェースやアプリケーションに与える影響を最小限とするために、端末（もしくはそのアプリケーション）２に対する代理応答及び接続後のアドレス変換機能を装備し、ルーティング情報提供センター（以下、単にセンターと称す。）４との接続を意識させない仕組みとする。
【００１４】
接続装置３における動作の概要を、ユーザー端末（もしくはそのアプリケーション）２、センター３及びプロバイダーとのやりとりを含めて図２に示す。
【００１５】
（１）  接続装置３はユーザー端末２から、接続要求（宛先アドレスやＵＲＬ等）を受け取ると、ユーザー端末２側にダミー（仮）のアクセスポイントのアドレスを含む接続中応答を返すとともに、センター４へＤチャネルパケット等を使って接続し、前記情報を含む問い合わせ要求を行う。
【００１６】
（２）  接続装置３はセンター４から、契約済みのプロバイダー中で最適なプロバイダー（アクセスポイント：接続先）のアドレス（電話番号）や速度情報を含む問い合わせ結果の応答を受け取る。
【００１７】
なお、この際、予めデータベースに登録・蓄積したおいた契約済みのプロバイダーに関する情報等の設定情報等と前記結果応答とを比較処理して、受け取った応答が適切かどうかを判定するようにしても良い。
【００１８】
（３）  接続装置３は前記選択されたプロバイダーのアドレスに対しＢチャネル等による実際の回線接続を行い、接続が確立したら通常の通信と同じようにユーザー端末２に接続完了を通知する。
【００１９】
回線接続では、Ｂチャネルのように占有するチャネル、あるいはＤチャネルのように論理多重可能な回線を用いて、取得した情報を基にアクセスポイントとの接続を行う。
【００２０】
（４）  以後、接続装置３はプロバイダーを介したユーザー端末２と通信相手との間の実際のデータ通信を中継することになるが、この際、仮のアクセスポイントと実際のアクセスポイント（プロバイダー）とのアドレス変換を行う。
【００２１】
アクセスポイントのアドレスが動的に変更される場合、通常であればユーザー端末上のアプリケーションは再立ち上げ等が必要になるが、本発明では、これまで１対Ｎの接続のために用いられたＮＡＴ（アドレス変換機能）を、通常のターミナルアダプタやユーザー端末上のソフトウェア等の１対１向けのものに実装することにより、ユーザー端末上のユーザーインターフェースでは意識せずに使用可能とした。
【００２２】
次に、接続装置３の構成例について説明する。ここでは、主にＩＳＤＮ回線を用いた例を示すが、ＦＲ（フレームリレー）やＡＴＭ等の接続装置でも、Ｄチャネルの代わりに低速な論理パスを設け、情報に応じて１本の物理回線内の複数の接続先に対する論理パス等を制御することで同様の効果を得ることができる。
【００２３】
図３は接続装置の実施の形態の一例、ここではユーザー端末上に実装されるソフトウェアで実現した例を示すもので、図中、２０は端末接続装置を組み込んだユーザー端末、３０は通常のＴＡである。
【００２４】
ユーザー端末２０は、既存のアプリケーション２１、既存のソケット２２、既存のネットワークプロトコル（ＴＣＰ／ＩＰ等）２３、既存のネットワークドライバ（ＰＰＰ／ＮＤＩＳ等）２４、既存のハードウェアドライバ（シリアル／ＬＡＮ等）２５、ＥＰＲ用ソケット２６、ＮＡＴ機能部２７及びＥＰＲ制御ドライバ２８を備えており、また、ＴＡ３０は、既存機能部３１及び設定情報ＤＢ（データベース）３２を備えている（但し、本発明に関係しない部分は省略してある。）。なお、図中、実線矢印はＩＰ接続確立前の制御情報、点線矢印はＩＰ接続確立後の制御情報、二重線矢印は接続確立後のデータの流れをそれぞれ示している。
【００２５】
既存のアプリケーション２１は、ＩＰアドレスやＵＲＬ等のリクエストをソケット２６に対して要求する。ソケット２６は、アプリケーション２１に対して、接続中の状態を返し、ＥＰＲ制御ドライバ２８へＩＰアドレスやＵＲＬ等のリクエスト情報を提供する。ＮＡＴ機能部２７はダミーのＩＰアドレスを割り当て、ＩＳＤＮ回線側で割り当てられたＩＰアドレスとの相互変換を行い、アプリケーションやドライバ側にダイアルアップ自体を意識させない。
【００２６】
ＥＰＲ制御ドライバ２８は、ＴＡ等の接続状態を監視し、接続されていない／繋ぎ変えても良い設定の場合、ソケット２６を経由してアプリケーション２１から宛先ＩＰアドレス等を取得し、センター側へ問い合わせを行い、応答を解読し、最適なアクセスポイントへＤチャネルまたはＢチャネルでＰＰＰ／ＩＰ接続を行う。また、ＮＡＴ機能を使用せず、ドライバ２４，２５間で直接データをやりとりする場合、各プロバイダーによって割り当てられる接続先の電話番号／ＩＰアドレスを既存のドライバ２４に通知・認識させ、ＩＰアドレスを変更させる（なお、この際、現在のＰＰＰドライバのようにＩＰアドレスの変更も認識できる場合はＰＰＰドライバに対して動的に接続先の電話番号の変更を通知するだけで良い。）。
【００２７】
ＴＡ３０の既存機能部３１は、接続時の制御、応答、非同期／同期ＰＰＰ変換等の定型的な処理も行うが、基本的には回線側とシリアルインターフェース（Ｉ／Ｆ）等との間のデータ中継を行う。設定情報ＤＢ（データベース）３２は、予め登録されたユーザー名（ＩＤ）、パスワード等を蓄積している。
【００２８】
図４は端末接続装置の実施の形態の他の例、ここではユーザー端末のシリアルインタフェース等に接続されるターミナルアダプタにソフトウェアもしくはハードウェアを追加実装して実現した例を示すもので、図中、４０は端末接続装置を組み込んだターミナルアダプタである。
【００２９】
ターミナルアダプタ４０は、既存機能部４１、設定情報ＤＢ（データベース）４２、端末制御機能部４３、ＮＡＴ機能部４４、ＰＰＰ／ＩＰ−シリアル変換部４５及びＥＰＲ制御機能部４６を備えている（但し、本発明に関係しない部分は省略してある。）。
【００３０】
既存機能部４１は、接続時の制御、応答、非同期／同期ＰＰＰ変換等の定型的な処理も行うが、基本的には回線側とシリアルインターフェース（Ｉ／Ｆ）等との間のデータ中継を行う。設定情報ＤＢ（データベース）４２は、予め登録されたユーザー名、パスワード等とともに、予め登録されたセンター、契約済みのプロバイダー及びそのアクセスポイントの電話番号等を蓄積している。
【００３１】
端末制御機能部４３は、既存機能部４１を介して送られてきたユーザー端末からの接続要求に対してダミーの接続完了応答を返すとともに、ＮＡＴ機能部４４にダミーのＩＰアドレスを割り当てる。ＮＡＴ機能部４４は、ＩＳＤＮ回線側で割り当てられたＩＰアドレスとシリアル側に割り当てたダミーのＩＰアドレスとの相互変換を行う。
【００３２】
ＥＰＲ制御機能部４６は、ＮＡＴ機能部４４を利用して宛先ＩＰアドレスを取得し、センター側へ問い合わせを行い、応答を解読し、最適なアクセスポイントへＤチャネルまたはＢチャネルでＰＰＰ／ＩＰ接続を行う。
【００３３】
ユーザー端末２は、通常のものであり、ＴＡ４０に対してシリアルインターフェース等を介してＡＴコマンド等で発呼等の制御を行い、接続確立後はデータを全て解読し、ＩＰとして処理を行う。
【００３４】
図５は端末接続装置の実施の形態のさらに他の例、ここではユーザー端末にＬＡＮ接続されるＮＡＴ機能付きのルーターにソフトウェアもしくはハードウェアを追加実装して実現した例を示すもので、図中、５０は端末接続装置を組み込んだルーターである。
【００３５】
ルーター５０は、既存のＬＡＮ側インタフェース（Ｉ／Ｆ）５１、既存のルーティング機能部５２、既存のＴＡ機能部５３、既存のＮＡＴ機能部５４、設定情報ＤＢ（データベース）５５及びＥＰＲ制御機能部５６を備えている（但し、本発明に関係しない部分は省略してある。）。なお、図中、実線矢印はＩＰ接続確立前の制御情報、二重線矢印は接続確立後のデータの流れ、点線矢印はＥＰＲ対応で追加される情報の流れをそれぞれ示している。
【００３６】
ルーティング機能部５２は、通常のルーターとして機能する場合、ＩＰルーティング等の機能、ルーティング情報の制御、宛先に応じたダイヤルアップ先の制御（ＤＤＲ）機能等を果たす。ＴＡ機能部５３は、接続時の制御、応答、非同期／同期ＰＰＰ変換等の定型的な処理も行うが、基本的には回線側プロトコルの解釈／制御を行う。ＮＡＴ機能部５４は、クライアント（ユーザー）から受信したパケットのＩＰ／ＴＣＰ／ＵＤＰヘッダを解釈し、外部への要求である場合、要求元ＩＰアドレスを自身のＷＡＮ側Ｉ／Ｆに割り当てられたアドレスに変換してＷＡＮ側へ送出し、ＷＡＮ側から受信したパケットは、受信したポート番号等を基にＬＡＮ側のリクエスト元を判別し、ＬＡＮ側端末宛てのパケットとして宛先アドレスを変換してＬＡＮ側へ送出する。
【００３７】
設定情報ＤＢ（データベース）５５は、予め登録された各ユーザー名、パスワード等とともに、予め登録されたセンター、契約済みのプロバイダー及びそのアクセスポイントの電話番号等を蓄積している。ＥＰＲ制御機能部５６は、ＮＡＴ機能部５４を利用して宛先ＩＰアドレスを取得し、センター側へ問い合わせを行い、応答を解読し、最適なアクセスポイントへＤチャネルまたはＢチャネルでＰＰＰ／ＩＰ接続を行う。
【００３８】
どの実装方法でも、過去の問い合わせ結果を蓄積／統計処理して、センターに問い合わせを行わずに、ある程度の判断を行うようにすることもできる。この場合、記憶容量や処理能力の関係でユーザー端末上にソフトウェアで実装する方が有利となる。
【００３９】
また、宛先までの回線速度のみを基準とし、頻繁に最新情報にする必要がないユーザーには、ルーティング情報をファイル化し、ユーザー端末やＴＡにダウンロードしてローカル処理で判断を行うようにしても良い。
【００４０】
これら２種類の処理と、センターへの問い合わせを効率的に組み合わせることで、エンドユーザーは必要以上のコストをかけずに本システムのメリットを享受できる。
【００４１】
ここで、接続装置とセンターとの間でやりとりするメッセージは、ごく単純、かつ短いものでなければ、レスポンスやセンターの負荷に悪影響を及ぼすこととなる。また、通信料が定額制でない状況でサービスを開始する場合、なるべく情報量を少なくする必要がある。さらに、１アカウントで複数の機器に設定されても判別できないという不正を防ぐために、発番による認証を行う必要がある（この情報はＬＡＰＤのフレーム内に記述されているので不要）。
【００４２】
従って、接続装置とセンターとの間でやりとりするメッセージの項目としては、最低でも、
（リクエスト）接続装置→センター
ユーザーＩＤ、パスワード、シーケンスＩＤ：端末ユニーク、リクエスト種別：通常／再送等……、ＵＲＬ／ＩＰアドレス種別、データ（ＵＲＬ／ＩＰアドレス）
（応答）センター→接続装置
リクエストシーケンスＩＤ、回答種別：正常／判定不能／その他……、回答内容：ユーザーが登録したプロバイダーＩＤ（数字）
が必要と考えることができる。
【００４３】
上記のデータで成立するには、ユーザーはサービスに入会する際に、プロバイダー名（コード化しておく）と、自分のＴＡ／ルーター内でマッピングするためのＩＤ（数字４桁程度）を最低限登録し、自端末／ＴＡ／ルーターには、センタの番号、プロバイダーＩＤと対応するアクセスポイントの電話番号を登録する必要がある。
【００４４】
前述では、ユーザーが使用するプロバイダーを全て登録する（コード化する）ことが前提となっているが、実際に数千、数万とあるプロバイダーに対する情報をセンターが実地調査する事は不可能に近い。また、１つのプロバイダーの複数のアクセスポイントから選択したい場合は判別できない。その他、会社経由のアクセス等の手段を持っている場合は、それらを比較対象にすることが上記のインターフェースでは不可能である。
【００４５】
そこで、応答コードを
回答内容：ユーザーが登録したプロバイダー＋アクセスポイントＩＤ（数字）
から、
回答内容：ユーザーが登録したプロバイダー＋アクセスポイントＩＤ（数字）＋（予想されるスループット（ｋｂｉｔ／ｓ）×アクセス回線使用率）
に変更することにより、ＴＡ側に「１０ｋｂｉｔ／ｓ以下の回答が来たら会社経由にする」、「センターでサポートしていないけど契約しているプロバイダーは大体これぐらいの速度」等の設定で、本システムを利用可能とすることができる。
【００４６】
図６はルーティング情報提供センターの実施の形態の一例、ここではインターネット接続向けサービスに対応した例を示すもので、図中、６１はレスポンス調査エージェントサーバー、６２はＤＢ（データベース）／エンジンサーバー、６３は通信サーバー、６４はユーザー管理サーバー、６５は管理端末である。
【００４７】
レスポンス調査エージェントサーバー６１は、インターネット上の各アクセスポイント、サーバー、ドメイン、ノード等のアドレスをインターネット上の管理装置から定期的に調査し、また、インターネット上の各アクセスポイント、サーバー、ドメイン、ノード等間の混雑（トラフィック）状況等をインターネット上の機器から定期的に調査する機能を有する。なお、ここではどれくらいの頻度で、どこまでの階層を調査するかの兼ね合いを資源や負荷の状態を勘案して調整することが重要となる。
【００４８】
ＤＢ（データベース）／エンジンサーバー６２は、トラフィック情報・ネットワーク構成情報ＤＢ、ユーザー管理ＤＢ及び課金・決済情報ＤＢとともに、ルート選択エンジン（メインエンジン）を有し、通信サーバーからの問い合わせに対する回答を行う。
【００４９】
通信サーバー６３は、Ｄチャネルパケットを利用して、ユーザー端末からの調査（問い合わせ）要求を受け付け、ＤＢサーバーへ中継し、また、中継サーバーからの応答をユーザー端末へ送出する。ユーザー管理サーバー６４は、Ｗｅｂ上での登録（オンラインサインアップ）及び各種エントリー変更を受け付ける必要があるので、これの受付・処理を行う。変更内容はＤＢサーバーへ反映される。
【００５０】
管理端末６５は、手動によるユーザー登録（管理）、各種の統計処理、課金・決済情報作成等を行う（保守サーバーの監視／サービス制御等の機能を、ここに実装しても良い。）。
【００５１】
図７は本発明システムにおけるルーティング情報提供センターの動作の概要を示すものである。
【００５２】
（１）  通信サーバー６３がユーザー端末から調査（問い合わせ）要求を受け取り、ＤＢ／エンジンサーバ６２に宛先アドレスやＵＲＬ等の要求情報及び発信者番号を送ると、ＤＢ／エンジンサーバ６２はユーザー管理ＤＢに蓄積したユーザー情報により認証する。
【００５３】
（２）  ＤＢ／エンジンサーバ６２はトラフィック情報・ネットワーク構成情報ＤＢに蓄積した情報によりルート及びスループットを予測し、最適なプロバイダー（ルート）を選択し、通信サーバー６３を介してユーザー端末側へ応答させる。
【００５４】
（３）  また、ＤＢ／エンジンサーバ６２は課金・決済情報ＤＢに蓄積した課金情報を基に該当ユーザーへの課金処理を行う。
【００５５】
（４）  レスポンス調査エージェントサーバー６１は、ＤＢ／エンジンサーバ６２から所定のスケジュール及び調査対象を含むアドレス及び混雑状況の調査要求を受け、インターネット上を調査し、その結果をＤＢ／エンジンサーバ６２のトラフィック情報・ネットワーク構成情報ＤＢに反映させる。
【００５６】
（５）  ユーザー管理サーバー６４は、ＤＢ／エンジンサーバ６２のユーザー管理ＤＢ及び課金・決済情報ＤＢに蓄積した情報を基に、ユーザー認証、利用状況／料金等の情報照会を処理するとともに、ユーザー登録／変更等の受付処理の結果をユーザー管理ＤＢに反映する。
【００５７】
また、図８はルーティング情報提供センターの実施の形態の他の例、ここでは単一プロバイダー内／企業向けに対応した例を示す。図中、６１’はレスポンス調査エージェントサーバーであり、ネットワーク上の各アクセスポイント、サーバー、ノード等のアドレスをネットワーク上の管理装置から定期的に調査し、また、ネットワーク上の各アクセスポイント、サーバー、ノード等間の混雑（トラフィック）状況等をネットワーク上の機器から定期的に調査する機能を有する。
【００５８】
また、６２’はＤＢ（データベース）／エンジンサーバーであり、課金・決済情報ＤＢを持たない点を除いて図６のＤＢ（データベース）／エンジンサーバー６２とほぼ同様である。また、６５’は管理端末であり、課金・決済情報作成を行わない点を除いて図６の管理端末６５とほぼ同様である。また、通信サーバー６３及びユーザー管理サーバー６４は図６のものとほぼ同様である。
【００５９】
なお、本センターの動作は、課金処理等がない点を除いて図７で説明したものとほぼ同様である。
【００６０】
単一のプロバイダー内や、会社等のリモートアクセスに対して適用する場合は、アクセスサーバーの回線の使用状況等をＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）のＭＩＢ（Ｍｅｓｓａｇｅ  Ｉｎｆｏｍａｔｉｏｎ  Ｂａｓｅ）から取得すれば良いが、インターネット側の混雑状況についての計測方法については、ｐｉｎｇによる方法では限界がある。
【００６１】
そこで、インターネット上のルーターがＳＮＭＰエージェントであることを利用して、インターフェースの回線種別・速度やトラフィックを取得することが可能である。
【００６２】
この情報と、契約しているプロバイダーから、ある程度の宛先にＴｒａｃｅ  Ｒｏｕｔｅを行えばルーティング情報（経路設定）も知ることができるので、センター側ではスタティックな情報として、「回線の太さ入りインターネット地図」を作成することが可能である。言い換えれば、ＳＮＭＰの必要な情報を全て取得することにより、Ｔｒａｃｅ  ＲｏｕｔｅではＲｏｕｎｄ  Ｔｒｉｐ以外の情報は不要となり、さらにＴｒａｃｅ  Ｒｏｕｔｅで通過する経路以外の経路情報も取得して導き出すことが可能となる。
【００６３】
上記に対して、時間的なパラメーターによる混雑等を重みづけ要素として定期的に計測し、付加することで、より正確な情報とすることが可能である。この手段では、全ドメインを定期的に巡回する方法に比べて、処理及びネットワークへの負荷を少なくすることができる。
【００６４】
当然、インターネットも経路や回線は常に変動しているので、１度調査して終わりにはならない。全ドメインが１０００万だとすると、１秒に１回ＩＣＭＰでＴｒａｃｅ  Ｒｏｕｔｅを行っても３ヶ月以上かかる。このため、問い合わせの頻度から順位を付けておき、よく問い合わせが来るところは優先的に調査を行うという仕組みを設けることで効率化できる。
【００６５】
例として、１件でも問い合わせが来れば１ヶ月以内に再調査、週に１０件以上来たら１週間以内に再調査、日に１０件以上なら翌日に再調査、１時間に１０件以上なら１時間以内に再調査等のスケジューリングを行う。
【００６６】
また、調査の結果、レスポンスが帰ってこないところに対する評価をどうするかも課題となる（輻輳／コリジョンによるパケットロストは除く。）。
【００６７】
ここで、ポイントとなるのは、「インターネット地図」をどのように効率的な形でＤＢに格納し、利用するか（数値表現化）ということである。
【００６８】
宛先アドレスを使用して、ルーティング情報系テーブルから使用されるであろうルートを決定し、論理ボトルネック速度をノードマップ系テーブルから取得する。
【００６９】
これを、ユーザーが登録しているプロバイダーについて算出し、レスポンス時間や回線使用率、また、ノードがアクセスサーバーの場合は回線話中率を重要視したパラメータを加える等を行って比較し、予想速度を算出する。
【００７０】
前述したセンター側でトラヒックを取得し、速度情報を予測する手段についてさらに詳細に説明する。
【００７１】
従来、トラフィック及び経路を測定する機器は、宛先と送信元に対で設置するか、送信元と宛先の経路上にエージェントとしてモニタする機器を設置することが前提となっているが、本発明では、入口の違うユーザーからの問い合わせに対応するため、ユーザーと宛先との間の経路上にないセンターから各種の情報を取得し、これを元にユーザーから宛先までの経路と混雑状況を予測する。
１．ＳＭＮＰエージェントとなっているインターネット上のルーターに対してｇｅｔを行い、インターフェース数、インターフェースタイプ、回線速度、ルーティングテーブルのリスト等を取得する。
２．ＩｎｔｅｒＮＩＣやＪＰＮＩＣ等のドメイン管理組織から、ドメイン一覧を入手する。これは、公開されており、匿名ＦＴＰで自動的に入手可能である。これを取得し、前日との差分を抽出する。
３．新規に追加された各ドメインのサーバー（例えば、一般的にはｗｗｗ．？？？？．ｃｏ．ｊｐ等は大抵存在する）に対して既知の手段である、ｔｒａｃｅ  ｒｏｕｔｅでセンターからそれぞれのドメインまでの経路を探索すると同時に、Ｒｏｕｎｄ  Ｔｒｉｐを測定する。
４．これらを合わせると、以下のようなデータベースができあがり、端末からのリクエスト情報から、経路とボトルネック回線部分、予測される遅延や混雑状況が導き出される。
【００７２】
【表１】
0003558908.tif 000002
【００７３】
実際のインターネットでは、上記のように複雑なネットワークによって構成されており、どの経路を通過するかは、それぞれのルーターに設定されているルーティングテーブルによって決定される。従って、端末から宛先は、ＲｏｕｔｅｒＡ→ＲｏｕｔｅｒＣ→ＲｏｕｔｅｒＥという経路を通過するとは限らない。また、端末から宛先までの経路が一意に決定されたとしても、その経路上にない装置からは通常、トラフィックや混雑状況の計測はできない。
【００７４】
そこで、ｔｒａｃｅ  ｒｏｕｔｅを用いて、センターから各ドメイン（宛先）までの経路を取得し、その間のネットワーク機器（Ｒｏｕｔｅｒ）のアドレスを入手する。
【００７５】
（例）
宛先１……ＲｏｕｔｅｒＦ（１０．１０．２６．１）→ＲｏｕｔｅｒＢ（１０．１０．２１．１）→ＲｏｕｔｅｒＤ（１０．１０．２３．１）→ＲｏｕｔｅｒＥ（１０．１０．２４．１）→宛先１（１０．２０．１．１）
宛先２……ＲｏｕｔｅｒＦ（１０．１０．２６．１）→ＲｏｕｔｅｒＢ（１０．１０．２１．１）→ＲｏｕｔｅｒＤ（１０．１０．２３．１）→宛先２（１０．２０．２．１）
また、センターからプロバイダーのアクセス装置までの経路も同様に入手できる。
【００７６】
（例）アクセスサーバー……ＲｏｕｔｅｒＦ（１０．１０．２６．１）→ＲｏｕｔｅｒＡ（１０．１０．２０．１）→アクセスサーバー（１０．１０．１０．１）
これと同時に、各ルーター等の間の遅延時間が取得できる。情報を整理すると以下のようになる（／＝なし、＊＝不明、−＝接続無し）。
【００７７】
【表２】
0003558908.tif 000003
【００７８】
上記の結果から、不明な部分はＲｏｕｔｅｒＡ←→ＲｏｕｔｅｒＢ、ＲｏｕｔｅｒＢ←→ＲｏｕｔｅｒＣである。
【００７９】
このような状態で空白となる部分が発生するが、センター側で複数の異なるプロバイダー等のアクセスポイントを利用契約しておくことで、同一の宛先に対しても異なる経路を経由させることが可能となり、この結果、得た情報によって大部分を埋めることが可能となる。
【００８０】
宛先１へアクセスする場合の経路が下記の２通りある場合、端末がアクセスするアクセスサーバーは次のようにして選択される。
【００８１】
経路１：アクセスサーバー１→ＲｏｕｔｅｒＡ→ＲｏｕｔｅｒＣ→ＲｏｕｔｅｒＥ→宛先１
経路２：アクセスサーバー２→ＲｏｕｔｅｒＢ→ＲｏｕｔｅｒＤ→ＲｏｕｔｅｒＥ→宛先１
前述したルーター間延滞時間より、経路１は５ｍｓ＋５ｍｓ＋５ｍｓ＝１５ｍｓとなり、経路２は５ｍｓ＋１０ｍｓ＋３５ｍｓ＝５０ｍｓとなる。これにより、経路１を選択した方がより早くアクセスすることが可能であるため、センターはアクセスサーバー１への接続をユーザー端末に通知する。
【００８２】
センター側で必要なＤＢの構成は、主として以下のようなものがある。物理的な配置は負荷等を考慮して分散しても良い。
・トラフィック情報キャッシュテーブル
（リクエストに応じて検索されたトラフィック情報に重み付けを行って一定期間キャッシュする。）
ＵＲＬ、ＩＰアドレス、スループット、プロバイダー通番、アクセスポイント番号、作成日時、生存時間、レスポンス時間、論理ボトルネック速度、アクセス回数
・トラフィック情報レスポンステーブル
（エージェントサーバーから一定のノードまでのレスポンスを測定し、蓄積する。）
プロバイダー通番、アクセスポイント番号、宛先ノード通番、レスポンス時間、計測日時、被参照回数
・ノードマップ管理テーブル
ノード通番、ノード名、インターフェース数、ノード種別
・ノードマップ回線情報テーブル
ノード通番、インターフェース通番、インターフェースＩＰアドレス、回線速度、回線使用率
・ルーティング情報管理テーブル
ノード通番、Ｄｉｓｔｎａｔｉｏｎ数、ルーティングプロトコル種別（Ｓｔａｔｉｃ、ＢＧＰ、ＲＩＰ、ＩＧＲＰ、……複合）
・ルーティング情報テーブル
ノード通番、Ｄｉｓｔｎａｔｉｏｎアドレス、Ｃｏｓｔ／Ｍｅｔｒｉｃ種別、Ｃｏｓｔ／Ｍｅｔｒｉｃ値
・プロバイダー情報テーブル
プロバイダーＩＤ、プロバイダー名、ドメイン名、アクセスポイント数、補正係数
・プロバイダーアクセスポイントテーブル
プロバイダー通番、アクセスポイント番号、名称、電話番号、アクセスサーバーノード番号、補正係数
・ユーザー情報テーブル
ユーザーＩＤ、ユーザーステータス、その他ユーザー情報（住所、氏名、決済情報等）
・ユーザー課金テーブル
ユーザーＩＤ、対象日、利用回数
・ユーザー決済テーブル
ユーザーＩＤ、対象年月、利用回数、金額、補正金額、決済ステータス
・ユーザー登録情報テーブル
ユーザーＩＤ、（対象プロバイダーＩＤ、対象アクセスポイント番号）×ｎ
（対象とする接続先数を限定しない場合、テーブル数は複数となる）
・ユーザー認証テーブル
ユーザーＩＤ、登録電話番号、パスワード
・課金管理テーブル
基本料金、問い合わせ単価
・月別課金管理テーブル
補正金額
この他、プロバイダー毎や宛先毎等の問い合わせ状況を集計する統計管理テーブルや、システム／サービスのステータスを有するシステム管理テーブル、エージェントサーバーのスケジューリングを行うエージェント制御テーブル等がある。
【００８３】
【発明の効果】
以上説明したように、本発明によれば、
・エンドユーザーから見たスループットが向上する、
・エンドユーザーは、接続してから遅いことに気付いて接続先を変える場合、最低で１０円のコストがかかっていたが、この仕組みならば、パケットの料金＋サービス料金＝数円／回のコストで確実に速度の出る接続先を選択することができる、
・インターネット全体の負荷を分散できる、
・小規模プロバイダーが活躍できる分野を創出できる、
・ルーティング情報提供センターを設立して事業化できる、
・複数プロバイダーを束ねた形での契約形態を提供することで、ユーザーからは１契約で効率的な接続を行うことができ、プロバイダー側では回線や設備の効率的な利用、溢れることで失っていた顧客と接続料金を得ることができる、
・話中等で混雑時の利用を諦めていたユーザーが接続可能となることによって、トラフィック収入の増加を見込める、
等である。
【００８４】
また、複数のプロバイダーだけではなく、単一プロバイダーや、会社でのリモートアクセスでも、アクセス回線の話中状況やトラフィックに応じた応答をセンターが返す仕組みとすれば適用可能であり、特に大規模プロバイダーでは計画的かつ効率的な設備投資及び運用が可能となる。
【００８５】
さらに本発明はＩＳＤＮのＤチャネルパケットだけではなく、Ｂチャネルパケットや、ＡＴＭ、ＦＲ等の多重化が可能なサービスに対しても適用可能である。
【図面の簡単な説明】
【図１】本発明のシステム全体の概要図
【図２】本発明システムにおける端末接続装置の動作の概要を示すシーケンス図
【図３】端末接続装置の実施の形態の一例を示す構成図
【図４】端末接続装置の実施の形態の他の例を示す構成図
【図５】端末接続装置の実施の形態のさらに他の例を示す構成図
【図６】ルーティング情報提供センターの実施の形態の一例を示す構成図
【図７】本発明システムにおけるルーティング情報提供センターの動作の概要を示すシーケンス図
【図８】ルーティング情報提供センターの実施の形態の他の例を示す構成図
【符号の説明】
１：インターネット、２，２０：ユーザー端末、３：端末接続装置、４：ルーティング情報提供センター、２１：アプリケーション、２２：ソケット、２３：ネットワークプロトコル、２４：ネットワークドライバ、２５：ハードウェアドライバ、２６：ＥＰＲ用ソケット、２７：ＮＡＴ機能部、２８：ＥＰＲ制御ドライバ、３０，４０：ターミナルアダプタ、３１，４１：既存機能部、３２，４２：設定情報ＤＢ、４３：端末制御機能部、４４：ＮＡＴ機能部、４５：ＰＰＰ／ＩＰ−シリアル変換部、４６：ＥＰＲ制御機能部、５０：ルーター、５１：ＬＡＮ側インタフェース（Ｉ／Ｆ）、５２：ルーティング機能部、５３：ＴＡ機能部、５４：ＮＡＴ機能部、５５：設定情報ＤＢ（データベース）、５６：ＥＰＲ制御機能部、６１，６１’：レスポンス調査エージェントサーバー、６２，６２’：ＤＢ（データベース）／エンジンサーバー、６３：通信サーバー、６４：ユーザー管理サーバー、６５，６５’：管理端末。
【図１】
0003558908.tif 000004
【図２】
0003558908.tif 000005
【図３】
0003558908.tif 000006
【図４】
0003558908.tif 000007
【図５】
0003558908.tif 000008
【図６】
0003558908.tif 000009
【図７】
0003558908.tif 000010
【図８】
0003558908.tif 000011