JP2001508247A

JP2001508247A - 最小コスト・オンラインアクセスを実現する方法および装置

Info

Publication number: JP2001508247A
Application number: JP50706998A
Authority: JP
Inventors: ボナール，パトリック，ピー．; ジオラ，トム，ジェイ．; ハーマン，ウィリアム，シー．
Original assignee: WebTV Networks Inc
Current assignee: WebTV Networks Inc
Priority date: 1996-07-09
Filing date: 1997-07-03
Publication date: 2001-06-19
Anticipated expiration: 2017-07-03
Also published as: EP0920664B1; AU3667197A; JP4201837B2; US5862339A; WO1998004088A2; WO1998004088A3; EP0920664A4; EP0920664A2; DE69735540D1; DE69735540T2

Abstract

(57)【要約】インターネット・アクセスのためのアクセス要求を種々のオンライン・サービス・プロバイダの間でルーティング（ルート決定）するためのデータベース・セントラル・ルーティング装置が開示されている。この装置は、そこから選択されるインターネット・アクセス・プロバイダのアクセス電話番号に関するアルゴリズムのリストをもつセントラル・サーバを含んでいるのが一般的である。また、このセントラル・ルーティング装置はさらに、着信コールを特定してそのユーザがカストマであることを示すための自動電話番号識別装置を含んでいる。特定の電話番号に関するアルゴリズムをダウンロードしてユーザが種々のインターネット・アクセス・プロバイダにアクセスできるようにするアルゴリズム・ジェネレータも含まれている。このセントラル・ルーティング装置によれば、ユーザは複数のインターネット・アクセス・プロバイダの中から、そのプロバイダが利用可能であるかどうかに応じて選択することができる。時刻、任意の特定プロバイダの定常ピーク時間とオフピーク時間、アクセス時間、コンシューマ（消費者）であるか、ビジネスユーザであるかといったユーザのタイプなどの要因およびその他の要因は種々のインターネット・アクセス・プロバイダを効率よく利用するためのものである。

Description

【発明の詳細な説明】最小コスト・オンラインアクセスを実現する方法および装置発明の背景１．発明の分野本発明はテレコミュニケーションの分野に属し、具体的には、ネットワーク・アドレスとユーザ基準（user criteria）情報をネットワーク・トランザクションのために使用することに関する。２．関連出願の相互参照本出願は、「ネットワーク・アドレス情報を使用してネットワーク・トランザクションのパフォーマンスを向上するための方法および装置(A Method and Appa ratus for Using Network Address Information to Improve the Performance o f Network Transactions)」という名称で１９９６年６月３日に出願された米国特許出願（出願番号）の一部継続出願である。また、本出願は以下の係属中の米国特許出願にも関連している。米国特許出願(発明の名称「リモートコントロールを使用してハイパテキスト・オブジェクト間のナビゲーションを可能にするＷｅｂブラウザ（Web Browser Al lowing Nagivation Between Hypertext Objects Using Remote Control）」、出願番号、年月日出願) 米国特許出願（発明の名称「ネットワーク内のドキュメントのプロキシングとコード変換を提供する方法および装置(Method and Apparatus for Providing Pr oxying and Transcoding of Documents in a Network)」、出願番号、年月日出願）米国特許出願（発明の名称「ネットワーク内のクライアントとサーバ間のコミュニケーションを管理する方法および装置(Method and Apparatus for Managing Communcation Between a Client and a Server in a Network)」、出願番号、年月日出願）上記米国出願は本願発明の被承継人に承継されている。３．関連技術の説明インターネット（the Internet）はコンピュータ・オペレータを他のオペレータだけでなく、種々のデータベースともネットワークで結ぶことを可能にする最新のコミュニケーション・システムである。これらのデータベースは大量の有用な情報を提供し、その情報の配布はインターネットの使用によって大幅に拡大されている。この最新ネットワークに参加するためには、インターネット・アクセス・プロバイダまたはNetcom、UUNet、AT&T Worldnet、America On-Lineなどのオンライン・サービス・プロバイダとアカウントを結ぶ；すなわち口座を作ることが必要である。ユーザにはアカウント番号と電話番号が与えられ(最初の番号が通話中である場合に備えてあるいは別のロケーションに移動した場合には代替電話番号が与えられる場合もある)、ユーザがその番号を自分のクライアント・ソフトウェアにタイプインすると、クライアント・ソフトウェアは入力された電話番号をダイヤルしてアクセス・プロバイダに接続している。長距離電話サービス・プロバイダと同様に、インターネット・アクセス・プロバイダは、異なる時間にシステムにアクセスしようとする非常に多数のカストマをルーティング（ルート決定）する問題に直面している。その結果、各プロバイダには、プロバイダの特定カストマ層の特徴であるピーク期間と、これに対応するオフピーク期間が起こっている。例えば、あるプロバイダがビジネス・カストマにサービスを提供している場合、そのプロバイダは通常の営業時間の間通話中になっている。他方、あるプロバイダがコンシューマにサービスを提供している場合、そのプロバイダは夜間や休日などの営業時間外で通話中になっている。これらの営業時間外と休日の間、コンシューマにサービスを提供するブロバイダはシステムを監視する要求を負担しなければならない場合もある。他方、営業時間の間、コンシューマにサービスを提供するプロバイダが十分に利用されないことがある。これに対して、ビジネス・プロバイダは通常の営業時間にピーク時間が起こり、営業時間外には十分に利用されていない。プロバイダのシステムのこのように矛盾した使い方のコストは、ユーザがピーク時間にシステムを使用するか、ピーク時間外にシステムを使用するかに関係なく、すべてのユーザ全体に及んでいる。さらに、システムがオーバロード（過負荷状態）したときアクセスが制限され、オーバロード状態のシステムにアクセスしようとしたときユーザは通話中信号で待たされることがある。以上の結果、アクセス・プロバイダは、モデムプール(modem pool)が十分に利用されていない期間を補填するためにそれに見合う費用をすべてのユーザに請求しなければならない。また、全国的規模のサービスを一定料率で全国各地に提供するアクセス・プロバイダの場合は、ユーザが混雑したエリアまたは隔離されたエリアでダイヤルしたとき負担するコストは、ユーザがそれほど混雑していないで、それほど隔離していないエリアでダイヤルしたときにプロバイダが負担するコストよりもはるかに大きくなることがある。従って、プロバイダは十分に利用されていないエリアではモデムプールの利用を最適化することができない。さらに、インターネット・アクセス・プロバイダが隔離されたエリアでピーク稼働時間をもたないときは、あるユーザがインターネット・アクセス・プロバイダに到達するために長距離サービスを受けようとすると、そのユーザは接続時間料金に長距離料金が加算されるため高いコストを負担せざるを得なくなる。従って、インターネット・アクセス・プロバイダのカストマを種々のインターネット・アクセス・プロバイダの間で効率よくルーティングして、インターネット・アクセスのコストを低減するだけでなく、インターネット・アクセス・プロバイダが提供するシステムの利用を最適化することも可能にするサービスまたは装置を提供するようにすると便利である。このことから理解されるように、本発明は有用で、エレガントな方法でこれを達成している。従来のコンピュータ・ネットワーク・プロトコルは所与のネットワーク・トポロジ内で動作することを目的としている。これらのプロトコルは多数の異なるノード構成を扱えるだけ十分にフレキシブルで、カストマがネットワークに追加または除かれたときトポロジの変化に対処できるだけ十分に強固になっている。従来のネットワークはフレキシビリティ（柔軟性）とモビリティ（移動性）を維持する必要があるために、特定の地理的ロケーションに特定する情報に頼っていない。これらのネットワーク・プロトコルは地域に依存しないことを利点と考えているのが通常である。米国の多くのエリアでは、電話ネットワークからの発信電話番号を判断することが可能になっている。発信者ID(Caller ID)や自動番号識別(Automatic Number Identification‐ANI)などの、電話ネットワーク・サービスは適当に装備された電話応答装置に発信者の電話番号を提供することができ、そのあと電話番号がその応答装置に結合されたサーバに転送されることが可能になっている。しかし、多くの発信地域(Calling area)では、発信者IDと自動番号識別は技術的理由か法律上の理由のため利用可能になっていない。このようなエリアでは、ユーザのエリアコード、場合によっては、発信地域（例えば、都市）を検証することが可能であっても、ケースによっては、識別がまったく不可能である場合がある。ユーザの電話番号を識別または検証する直接的方法がなくても、間接的方法を使用することができる。従って、特定のネットワーク・ノードまたはネットワーク・ユーザに関する情報を得るための従来の手段は、さまざまなものが利用可能になっている。この情報が利用可能であっても、従来のネットワーク・プロトコルには、この情報を得るための機能やこの情報を使用してネットワークのオペレーションを最適化するための機能が備わっていない。従って、ネットワーク・トランザクションを最適化するための改善された手段と方法が望まれている。発明の概要インターネット・アクセスのための着信アクセス要求を種々のオンライン・サービス・プロバイダの間でルーティング(ルート決定)するためのデータベース・セントラル・ルーティング装置が開示されている。この装置は、そこから選択されるインターネット・アクセス・プロバイダのアクセス電話番号に関するアルゴリズムのリストをもつセントラル・サーバを含んでいるのが一般的である。セントラル・ルーティング装置はさらに、着信コールを特定してユーザがカストマであることを識別するための自動電話番号識別子を含んでいる。特定の電話番号に関するアルゴリズムをダウンロードしてユーザが種々のインターネット・アクセス・プロバイダにアクセスできるようにするアルゴリズム・ジェネレータも含まれている。セントラル・ルーティング装置を使用すると、ユーザは複数のインターネット・アクセス・プロバイダの中から、そのプロバイダが利用可能かどうかに応じて選択することができる。時刻、任意の特定プロバイダの定常ピーク時間とオフピーク時間、アクセス時間、コンシューマであるか、ビジネスユーザであるかといったユーザのタイプなどの要因およびその他の要因は種々のインターネット・アクセス・プロバイダの利用を効率化するためのものである。本発明の上記およびその他の利点は、下述する好適実施例の詳しい説明の中で詳しく説明する。図面の簡単な説明本発明の特徴および利点は、添付図面を参照して以下に説明する本発明の好適実施例の詳細な説明の中で明らかにする。図１はテレビジョン・セットで使用されるモデムに実装されたときの本発明を示す図である。図２は統合ケーブル・モデムおよびデコーダで実現されたときの本発明を示す図である。図３はテレビジョン・セットに組み込まれたときの本発明を示す図である。図４はケーブル・モデムおよびビデオ入力で実現されたときの本発明を示す図である。図５はＩＳＤＮモデムで実現されたときの本発明を示す図である。図６は本発明のネットワーク構成を示す図である。図７は存在地点（ＰＯＰ）ノードをもつ本発明のネットワーク構成を示す図である。図８は本発明のＷｅｂＴＶクライアントの内部構造を示す図である。図９は本発明のプライベート・サーバの内部構造を示す図である。図１０は本発明のＷｅｂＴＶサーバの内部構造を示す図である。図１１乃至図１６は本発明の処理ロジック・フローを示す図である。図１７は本発明のネットワーク構成を示す図である。図１８は最小コスト・オンライン・アクセスを実現する方法の機能を示すフローチャートである。好適実施例の詳細な説明本発明は、ネットワーク・アドレス情報を使用してネットワーク・トランザクションのパフォーマンスを向上する装置と方法である。以下の詳しい説明では、本発明の理解を完璧なものにするために多数の具体的な詳細が示されている。しかし、この分野の精通者ならば理解されるように、これらの具体的な詳細を参考にしなくても、本発明を実施することが可能である。他の場合には、周知の構造、インタフェースおよびプロセスは詳細に示されていないが、これは本発明を不必要に不明確にするのを避けるためである。ＷｅｂＴＶ（商標）本発明の好ましい実施例は、標準テレビジョン・セットをディスプレイ装置として使用し、標準電話回線および／またはその他の居住地域コミュニケーション・ネットワークをネットワーク・トランスポート媒体として使用する低コスト・ネットワーク・インタフェース装置（ＷｅｂＴＶ(商標)）である。このネットワーク・インタフェース装置はさまざまな形態でシステムとして実現することが可能である。図１は、標準テレビジョンに設けられているジャックに挿入されるモデムとしてのネットワーク・装置を示している。図２は、統合ケーブル・モデムおよびデコーダが内蔵されている装置としてのネットワーク・インタフェース装置を示している。図３は、テレビジョン・セットに内蔵されている統合ユニットとしてのネットワーク・インタフェース装置を示している。図４は、内蔵ビデオ・インタフェースとケーブル・モデムを装備している装置としてのネットワーク・インタフェース装置を示している。図５は、内蔵ＩＳＤＮ（Integrated Service s Digital Network−統合サービス・ディジタル・ネットワーク）モデムを装備しているネットワーク・インタフェース装置を示している。いずれの場合も、本発明のネットワーク・インタフェース装置には、従来の電話ネットワークを利用してコミュニケーションを可能にする標準電話コネクションが用意されている。ケーブル・モデム機能をもつ構成では、電話ネットワーク上でのコミュニケーションに加えて、ケーブル・ネットワーク上でのコミュニケーションが可能になっている。ケーブル・ネットワークは標準電話ネットワークよりもはるかに高速であるのが代表的である(つまり、利用される帯域幅がはるかに大きい)。しかし、ケーブル・モデムは標準ＰＯＴＳ（Plain Old Telephone Services。この分野では公知である）電話モデムよりも高価であるのが代表的である。ＩＳＤＮ構成では、ネットワーク・インタフェース装置はＩＳＤＮモデムと標準ＰＯＴＳモデムを共に装備している。この場合も、ＩＳＤＮネットワークはＰＯＴＳ電話ネットワークよりも高速であるのが代表的であるが、現時点ではＩＳＤＮの方が高価である。好適実施例では、また以下の説明では、本発明はいつかの異種タイプのネットワークまたはネットワークの部分を中心に説明されている。具体的には、以下の定義では、好適実施例が動作する異種のネットワーク・タイプが明確にされている。これらの異種ネットワーク・タイプには、従来のＰＯＴＳ電話ネットワーク、インターネット（the Internet）ネットワーク、ワールドワイドウェブ（Worl d Wide Web‐WWW）ネットワーク、およびＷｅｂＴＶネットワークが含まれる。ＰＯＴＳ電話ネットワークは、クライアントを存在地点(point of presence‐PO P)ノードまたは、直接プライベート・サーバに接続する交換回線ネットワークである。ＰＯＰノードとプライベート・サーバはクライアントをインターネット・ネットワークに接続するが、インターネット・ネットワークは伝送制御プロトコル／インターネット・プロトコル（transmission control protocol/Internet p rotocol‐TCP/IP）を使用するパケット交換ネットワークである。ワールドワイドウェブ（ＷＷＷ）ネットワークはハイパテキスト転送プロトコル（hypertext transfer protocol‐HTTP）を使用し、インターネット・ネットワーク内に構築され、ハイパテキスト・マークアップ言語(hypertext mark-up language‐HTML) サーバによってサポートされている。ＷｅｂＴＶネットワークはＷＷＷネットワーク内で実施されるＨＴＴＰ準拠版プロトコルを使用し、１つまたは複数のＨＴＭＬサーバによってサポートされている。ＷｅｂＴＶネットワークはＷｅｂＴＶネットワーク・インタフェース装置をもつ各クライアントを他のＷｅｂＴＶクライアントとＷｅｂＴＶサービスとに接続している。ＷｅｂＴＶクライアントは、インターネットやワールドワイドウェブ（ＷＷＷ）などのネットワーク・コネクションの１つを経由して到着した情報を、ネットワーク・インタフェース装置およびそこに用意されているブラウザ・ソフトウェアを使用して、広域ネットワーク上でブラウズすることもできる。ＷｅｂＴＶブラウザはワールドワイドウェブを直接にブラウズする機能をもっているが、ＷｅｂＴＶネットワークは基本的インターネット・アクセス以上にサービスをいくつかの方法で改善している。ＷｅｂＴＶネットワーク・サービスは、ユーザ登録と電子メール（ｅメール）を含めてＷｅｂＴＶネットワーク上で提供されている。ＷｅｂＴＶネットワークは、遠く離れたＷＷＷサイトへのブラウジングを高速化し、ディレイをなくすことによってユーザ・サービスも改善している。さらに、ＷｅｂＴＶネットワークはＷｅｂＴＶクライアントの地理的エリアに合わせて調整（tailor）されたコンテンツを提供している(地域調整(geographic t ailoring))。このようにして、クライアントによる地方限定サービス(locallzed servlce)へのアクセスを向上している。ＷｅｂＴＶネットワーク・インタフェース装置はクライアントへの応答を調整することも、特定のクライアント要求に関係する該当ネットワーク媒体を効率よく利用することもできる。例えば、ハイコストのＩＳＤＮやケーブル・ネットワークは高データ転送率が要求されるとき使用することができ、他方、ローコストのＰＯＴＳ電話ネットワークは重要度の低いまたは低データ転送率のトランザクション用に使用することができる。ＷｅｂＴＶネットワークはＷｅｂＴＶネットワーク・インタフェース装置から記憶域をオフロード（offload）することもできるので、そのコストを低減化することができる。図６に示すように、本発明のＷｅｂＴＶネットワークの基本構成が示されている。各々が上述したＷｅｂＴＶネットワーク・インタフェース装置のようなネットワーク・インタフェース装置である、複数のＷｅｂＴＶクライアント６１０はインターネットおよびＷＷＷなどの従来ネットワーク・インフラストラクチャ６１２を通してＷｅｂＴＶサーバ６２０に結合されている。ＷｅｂＴＶサーバ６２０は標準ネットワーク接続コンピュータ・システム（例えば、Sun Microsystems 社のSparcStation）であり、本発明のネットワーク機能を実現しているソフトウェアはそこで実行されている。この機能については、以下で説明されている。図７に示すように、本発明のＷｅｂＴＶネットワークの基本構成の代替実施例が示されている。各々が上述したＷｅｂＴＶネットワーク・インタフェース装置のようなネットワーク・インタフェース装置である、複数のＷｅｂＴＶクライアント６１０は、この代替実施例では、複数の存在地点(point of presence‐POP) ノード７１０に結合されている。存在地点ノード７１０を使用すると、クライアント６１０は、ハイコストの直接コネクションでネットワーク６１２にアクセスするのではなく、ローカル・ノードからネットワーク６１２にアクセスすることができる。例えば、電話ネットワークでは、クライアント６１０は、ネットワーク６１２のノードに長距離コールを行うよりも、クライアント６１０のローカル発信地域内のローカルの存在地点ノード７１０（つまり、電話ネットワークではモデム）と電話コネクションを確立した方が安価になる。図７に示す構成では、クライアントはコスト利益が得られる。しかし、本発明はこの構成に拘束されものではない。むしろ、本発明は図６と図７に示すネットワーク構成で実現することも、他の同等ネットワーク構成で実現することも可能である。セキュリティ検証と認証目的のための自動番号識別（ＡＮＩ）の使用ＡＮＩはネットワーク・アクセスがどのロケーションから行われているかを検証するときの効率的なツールとなっている。例えば、ＷｅｂＴＶクライアント・ネットワーク・インタフェース装置６１０はＷｅｂＴＶネットワーク・サーバ６２０にアクセスして特定のサービス・タイプを要求することができる。事情によっては、クライアントのアイデンティ（ＩＤ）を検証してから要求サービスを実行することが必要になるか、あるいは望ましい場合がある。発信者IDおよび自動番号識別（ＡＮＩ）などの電話サービスは要求元クライアントの電話番号をＷｅｂＴＶサーバ６２０に渡すために使用できる。これはクライアント・ユーザから見えないように行うことができる。ＷｅｂＴＶサーバ６２０は要求元クライアントの電話番号を使用すると、要求元クライアントの電話番号をサーバ６２０に維持されている許可電話番号リストと比較することによって要求サービスの実行を許可することができる。要求元クライアントの電話番号がサーバ・リストにあれば、要求サービスはそのクライアントのために実行される。要求元クライアントの電話番号が要求サービスのサーバ・リストになければ、要求サービスが実行できないことがクライアントに通知される。ＡＮＩと発信者IDは不正ユーザによって偽造できないので、本発明のこの特徴を利用すると、ＷｅｂＴＶネットワークはネットワーク・トランザクションに対して高度のセキュリティを保証することができる。この認証機能は以下のセクションで詳しく説明されている。米国では、ＡＮＩが利用できないエリアは非常に少数である。このようなエリアでは、ＡＮＩが存在しないことが本発明のプライベート・サーバによって検出されると、電話番号の入力をユーザに促すようにクライアント・ソフトウェアに指示する。本発明はユーザが入力した電話番号の正確性を検証できないが、それにもかかわらず、本発明はユーザ入力の電話番号がＡＮＩがカバーするエリアからの電話番号でないことを検証することが可能である。別のテストを行って、クライアント・ネットワーク・インタフェース装置６１０の想定上の電話番号（ＡＮＩから得たか、ユーザ入力から得たかに関係なく）がおそらく正しいことを検証することができる。つまり、クライアント・ネットワーク・インタフェース装置６１０に置かれたクライアント・ソフトウェアはクライアント自身の想定上の電話番号をダイヤルするようにクライアントに指示することができる。ダイヤルした電話番号が通話中でなければ(つまり、リング信号または切断信号が検出された場合)、想定上のクライアント電話番号は正しいはずがない。ダイヤルした電話番号が通話中であれば、想定上のクライアント電話番号は、大部分の電話番号は時間の大半にわたって通話中でないので、おそらく正しいはずである。これらのテストを行うと、ＡＮＩサービスの有無に関係なく、通常レベルのクライアント電話番号のエリアの正当性が得られる。ＡＮＩが利用できないエリアが米国では非常に少数で、世界各国では大部分であっても、セキュア暗号キーを取得し、プライベート・サーバへのセキュア・ネットワークを通してセキュア・トランザクションを実行するための本発明のプロセスは依然として動作する。これらのエリアで失われている唯一の機能は、本発明によって提供され、以下で詳しく説明されている地理的ローカリティの自動検証である。次に、図８乃至図１５を参照して説明すると、ブロック図とフローチャートは本発明による好適実施例の認証機能を示している。まず、図８に示すように、ＷｅｂＴＶクライアント６１０と従来のネットワーク６１２の間のインタフェースが示されている。好適実施例では、ＷｅｂＴＶクライアント６１０はネットワーク・インタフェース８４０を通して直接コミュニケーション・チャネル８５２上で情報を送受信する。従来技術には、チャネル８５２のような、多数の従来コミュニケーション・チャネルが存在している。これらのコミュニケーション・チャネルとしては、モデム経由の従来ＰＯＴＳ電話回線、統合サービス・ディジタル・ネットワーク（ＩＳＤＮ）回線、専用ワイヤ回線または光ファイバ回線などがある。別の方法として、ＷｅｂＴＶクライアント６１０は存在地点ノード８１０を通して従来ネットワーク６１２に結合することもできる。前述したように、存在地点ノード８１０を使用すると、ＷｅｂＴＶクライアント６１０はローカルの存在地点ノード８１０を通して従来ネットワーク６１２とのインタフェースとなることができる。このようにすると、クライアント６１０と存在地点ノード８１０の間のコミュニケーション・チャネル８５４は直接チャネル８５２に接続するよりも安価なチャネルになることができる。どちらの構成においても、ＷｅｂＴＶクライアント６１０は従来ネットワーク６１２を通して情報を送受信することができる。インターネットなどの従来ネットワーク６１２の１つの特徴は、従来ネットワーク利用の伝送環境のセキュリティが相対的に劣ることである。従来ネットワーク６１２はセキュリティが劣る特徴をもっているため、機密を要するコミュニケーションや商業的トランザクション、そのほかに、セキュア環境を要求する情報またはトランザクションを生ずることができない。このような理由から、本発明では、特定のＷｅｂＴＶクライアントを認証し、ＷｅｂＴＶクライアント６１０とＷｅｂＴＶサーバ６２０の間でセキュアで機密のコミュニケーションを確立するための追加機能が追加されている。プライベート・サーバ８２０は本発明の好適実施例では、以下で詳しく説明するようにセキュア・ネットワーク環境を構築するために使用される。再び図８を参照して説明すると、同図に示すようにプライベート・サーバ８２０はセキュア通信回線８５８を通してクライアント６１０に結合されている。セキュア通信回線８５８は、直接ＰＯＴＳ電話回線コネクション、専用伝送回線、またはポイントツーポイント（２地点間）データ通信媒体を含めて、従来技術で採用されている、いくつかの従来セキュア通信技法のいずれかにすることができる。好適実施例では、ＷｅｂＴＶクライアント６１０とプライベート・サーバ８２０の間のセキュア・コミュニケーションは、プライベート・サーバ８２０とクライアント６１０の間の直接ポイントツーポイント通信リンクを確立する事前割当て（８００）電話番号の使用によって確立される。このようにすると、クライアント６１０とプライベート・サーバ８２０の間のセキュア・コミュニケーション環境が保証される。以下で説明する本発明の技法を使用すると、ＷｅｂＴＶクライアント６１０は最初にプライベート・サーバ８２０とのセキュア・コミュニケーションを確立しておき、そのあとで従来ネットワーク６１２を経由するセキュア・コミュニケーション環境を確立する。従来ネットワーク６１２とのセキュア・コミュニケーション環境を確立するために、ＷｅｂＴＶクライアント６１０はクライアントボックス識別子(client bo x identifier)８４２を含んでいる。クライアントボックス識別子８４２は電子的に読み取り可能なユニーク番号または英数字文字列であり、特定のＷｅｂＴＶクライアント・ユニット６１０は、この識別子で他のすべてと区別されている。ユニーク識別コードをエレクトロニック装置にインストールする方法は従来から周知である。ＷｅｂＴＶクライアント６１０は暗号キー記憶域エリア８４４とネットワーク・アドレス記憶域エリア８４６も含んでいる。記憶域エリア８４４と８４６は電子的に読み取り可能で、変更可能なメモリ・ロケーションであり、本発明の認証プロセス期間に使用される特定の情報アイテムを保管するために使用される。暗号キー記憶域エリア８４４はプライベート・サーバ８２０によって与えられ、従来ネットワーク６１２経由のコミュニケーションでクライアント６１０によって使用される暗号キーを保管するために使用される。ネットワーク・アドレス記憶域エリア８４６はＷｅｂＴＶクライアント６１０が現在置かれているネットワーク・アドレスを保管するために使用される。クライアント６１０とネットワーク６１２の間の電話リンクの場合には、クライアント・ネットワーク・アドレスはクライアント６１０がそこからコールしている電話番号を表している。暗号キー８４４とネットワーク・アドレス８４６はどちらも、バッテリバックアップのＣＭＯＳメモリ、フラッシュメモリ、ダイナミックランダムアクセスメモリ(ＤＲＡＭ)、またはスタティックランダムアクセスメモリ（ＳＲＡＭ）を含む、種々の従来メモリ手段に保管しておくことも可能である。次に、図９に示すように、認証のために使用されるプライベート・サーバ８２０（第１サーバ）の内部コンポーネントが示されている。プライベート・サーバ８２０はネットワーク・アドレス判断ロジック９１０を含んでいる。ネットワーク・アドレス判断ロジック９１０は、クライアント６１０がどのネットワーク・アドレスから通信しているかを判断するためにプライベート・サーバ８２０によって使用される。電話ネットワークの場合には、ネットワーク・アドレス判断ロジック９１０はクライアント６１０がどの電話番号からコールしているかを判断するための自動番号識別（ＡＮＩ）ロジックを含んでいる。ＡＮＩの使用はこの分野の精通者に周知である。プライベート・サーバ８２０はこの従来技法を新規で有用な方法で採用してネットワーク接続コンピュータ環境でクライアント６１０を認証している。従来のコンピュータ・システムとネットワークは、代表例として暗号キーの使用によってセキュア・トランザクションを提供している。従来のセキュア・トランザクションでは暗号キーの必要性が前提になっている。暗号キーを利用してオープン・チャネルでセキュア・トランザクションを実行するための多数の技法がこの分野では知られている(例えば、Rivest、Shamlr、Adleman（RSA）プロトコル、セキュア・ソケット・レイヤ(Secure Socket Layer‐SSL)プロトコルなど) 。しかし、これらの従来技法のすべては、クライアントとサーバの間で暗号キーを転送するためのセキュア・チャネルがないときは危険にさらされている。本発明では、セキュアＰＯＴＳまたはＩＳＤＮネットワークはクライアントとプライベートＰＯＴＳまたはＩＳＤＮサーバの間で暗号キーを安全かつ機密に転送できるセキュア・チャネルを提供している。そのあと、インセキュア・ネットワーク（つまり、インターネット、ＷＷＷ、またはその他の公衆インセキュア・ネットワーク）は、セキュア・ネットワーク上で以前に取得された暗号キーを使用してクライアントとサーバの間で通常のセキュア・データ・トランザンクションのために使用できる。セキュア・ネットワークを使用して暗号キーを取得しておき、そのあとでインセキュア・ネットワークでその暗号キーを使用する、このプロセスは従来技術の一部ではなく、本発明の認証プロセスの重要な部分となっている。図９に戻って説明すると、プライベート・サーバ８２０は暗号キー生成ロジックと記憶域９１２を含んでいる。クライアント８５８とプライベート・サーバ８２０の間のデータ通信回線８５８はプライベートでセキュアな通信回線であるので、プライベート・サーバ８２０はクライアント６１０のためにユニークな暗号キーを生成し、取得するためにクライアント６１０によって使用されることができる。特定のＷｅｂＴＶクライアント６１０のための暗号キーはロジック９１２によって生成され、その暗号キー生成の対象となったクライアント６１０のネットワーク・アドレスと一緒にストアされる。プライベート・サーバ８２０に置かれている存在地点ノード・ローカリティ判断ロジック９１４は、かかる情報をプライベート・サーバ８２０に要求するクライアント６１０に最も近い存在地点ノードを判断するために使用される。ロジック９１０によって判断されたクライアント・ネットワーク・アドレス情報を使用すると、存在地点ノード・ローカリティ判断ロジック９１４は内部存在地点リストにアクセスして、リスト上のどのノードが対応するクライアント・ネットワーク・アドレスに最も近いかを判断することができる。クライアント６１０とサーバ８２０の間の代表的トランザクションは図１１乃至図１５のフローチャートを参照して以下で詳しく説明する。次に、図１０を参照して説明すると、ＷｅｂＴＶサーバ６２０（第２サーバ）の内部コンポーネントが示されている。ＷｅｂＴＶサーバ６２０はデータ通信回線１０２０を介して従来ネットワーク６１２に結合されている。データ通信回線１０２０は、ディジタル電話リンク、ＩＳＤＮ回線、ケーブル・リンク、ワイヤレス（無線）伝送、その他に従来の種々手段のいずれかを含む、さまざまな従来ネットワーク・アクセス手段のいずれかを含んでいる。ＷｅｂＴＶサーバ６２０はＷｅｂＴＶクライアント６１０用にカスタマイズされた種々のサービスを提供する。しかし、重要なことは、クライアント６１０とＷｅｂＴＶサーバ６２０の間のトランザクションがセキュア・データ通信リンクであることである。これはネットワーク６１２のようなインセキュア・ネットワークでは、常に可能であるとは限らない。そのような理由から、ＷｅｂＴＶサーバ６２０はクライアント認証データ１０１０を提供している。クライアント認証データ１０１０は各特定クライアントに関連づけられたクライアント・ネットワーク・アドレスとクライアントボックス識別子を示す情報を表している。さらに、ＷｅｂＴＶサーバ６２０は各特定クライアントに関連づけられた暗号キーをクライアント暗号キー記憶域エリア１０１３に保存している。これらの情報アイテムはＷｅｂＴＶサーバ６２０にアクセスする各クライアントごとに保存されている。クライアントを認証するためにこの情報がどのように使用されるかは、図１１乃至図１５のフローチャートを参照して詳しく説明されている。ＷｅｂＴＶサーバ６２０はネットワーク地理的データ１０１２も保存している。多くの場合、特定のＷｅｂＴＶクライアント６１０の地理的ローカリティを判断するようにすると好都合である。クライアントの地理的ローカリティ情報を使用すると、特定のクライアントによって要求されるサービスをクライアント・ローカリティ情報に基づいて構成することが改善され、最適化される。ネットワーク地理的データは特定のクライアント・ネットワーク・アドレスを、対応する地理的ローカリティと関連づけた情報を表している。この情報がＷｅｂＴＶサーバ６２０によってどのように使用されるかは、図１１乃至図１５のフローチャートを参照して詳しく説明する。次に、図１１に示すように、フローチャートはＷｅｂＴＶクライアント６１０によって実行される処理を示している。図１１に示すロジックは従来のインセキュア・データ・ネットワークを利用してＷｅｂＴＶサーバ６２０とのセキュア・データ通信リンクを確立するためにクライアント６１０によって使用される。最初の処理ステップ１１１０で、クライアント６１０はパワーアップ初期化を実行する。次に、クライアント６１０はセキュア・ネットワーク回線８５８上でプライベート・サーバ８２０に接続される。クライアント６１０がプライベート・サーバ８２０に接続されると、クライアント６１０はクライアント６１０のクライアント・ネットワーク・アドレスを判断するようにプライベート・サーバ８２０に要求する。クライアントが自身のネットワーク・アドレスを判断することは常に可能であるとは限らないので、この情報はプライベート・サーバ８２０に要求しなければならない。クライアント６１０による従来ネットワーク６１２へのアクセスが標準ＰＯＴＳ電話ネットワークを使用して行われる場合は、プライベート・サーバ８２０は従来の自動番号識別（ＡＮＩ）機能を使用して、クライアント６１０がそこからコールしている電話番号を取得することができる。ＰＯＴＳ電話ネットワークの場合には、このクライアント電話番号はクライアントがそこからネットワークにアクセスしているクライアント・ネットワーク・アドレスを表している。プライベート・サーバ８２０がクライアント・ネットワーク・アドレスを取得すると、このクライアント・ネットワーク・アドレスはプライベート・サーバ８２０側にストアされ、および／または要求元クライアント６１０に送り返される。さらに、プライベート・サーバ８２０はクライアント６１０のために暗号キーを生成する。この暗号キーはその特定クライアントに固有のものであり、クライアント６１０とＷｅｂＴＶサーバ６２０の間の以後のデータ・コミュニケーションを暗号化するために使用される(処理ブロック１１１２)。次に、図１２に示すように、プライベート・サーバ８２０の処理ロジックが示されている。処理ブロック１２１０で、プライベート・サーバ８２０はクライアントのネットワーク・アドレスの判断とクライアントのための暗号キーの生成を求める要求をクライアント６１０から受信する。プライベート・サーバ８２０は処理ブロック１２１２で従来の技法を使用してクライアント・ネットワーク・アドレスを取得する。プライベート・サーバ８２０とクライアント６１０がＰＯＴＳ電話ネットワークで接続されている場合は、プライベート・サーバ８２０は従来の自動番号識別（ＡＮＩ）技法を使用してプライベート・サーバ８２０への電話コールが出されたクライアント電話番号を取得する。好適実施例では、プライベート・サーバ８２０は分かっている（８００）電話番号を提供するので、クライアント６１０はこの電話番号を使用してプライベート・サーバ８２０にアクセスできるようになっている。プライベート・サーバ８２０とのこのコネクションが行われると、プライベート・サーバ８２０のネットワーク・アドレス判断ロジック９１０は標準電話ＡＮＩ機能を使用して、電話コールを出したクライアント６１０の電話番号またはネットワーク・アドレスを判断する(処理ブロック１２１２)。処理ブロック１２１４で、プライベート・サーバ８２０は暗号キー記憶域９１２内の記憶ロケーションをチェックし、要求元クライアントの暗号キーがすでに判断されているかどうかを判断する。そうでなければ、その特定クライアントのための新規でユニークな暗号キーが従来技法を用いて暗号キー生成ロジック９１２によって生成される。クライアントのための、この新規に生成された暗号キーはそのあと暗号キー記憶域９１２にストアされる。処理ブロック１２１６で、クライアント・ネットワーク・アドレスはどの存在地点ノードがクライアントのネットワーク・アドレスにローカルであるかを判断するためにプライベート・サーバ８２０によって使用される。プライベート・サーバ８２０のポイントオブプレゼンス・ノード・ローカリティ判断ロジック９１４はどの存在地点ノードがクライアント・ネットワーク・アドレスの特定ブロックにローカルであるかを示す情報を含んでいる。存在地点ノード・ローカリティ判断ロジック９１４内のロジックは特定クライアント・ネットワーク・アドレスをクライアント・ネットワーク・アドレスのブロックと比較し、クライアント・ネットワーク・アドレスの対応するブロックにとってローカルである存在地点ノードを判断する。電話ネットワークの場合には、クライアント・ネットワーク・アドレスはエリアコードを含んでいるクライアント電話番号に対応している。ある場合には、クライアント・ネットワーク・アドレスと同じエリアコードをもつ存在地点・オードはクライアント・ネットワーク・アドレスにローカルである存在地点ノードを表している。他の場合には、存在地点ノードの電話番号が特定のクライアント・ネットワーク・アドレスにローカルであるか否かを定義している、他の情報を取得する必要がある。どちらの場合も、存在地点ノード電話番号とクライアント電話番号との関連づけを行う技法は従来から公知である。ロジック９１４を使用して、プライベート・サーバ８２０はクライアント・ネットワーク・アドレスで表されたクライアントのローカル発信地域に存在する存在地点ノードまたはモデムの電話番号を見つける(処理ブロック１２１６)。処理ブロック１２１８で、プライベート・サーバ８２０はクライアント・ネットワーク・アドレス、クライアント暗号キー、およびローカル・存在地点ノードのネットワーク・アドレスを示しているメッセージを要求元クライアントに返送する。この情報は、プライベート・サーバ８２０によって生成されたものか、取得されたものかに関係なく、処理ブロック１２１８でクライアント６１０に渡される。そのあと、プライベート・サーバによる処理は、図１２に示す終了ブロックを通して終了する。図１１に戻って説明すると、クライアント・ネットワーク・アドレスとクライアント暗号キーは上述したように、処理ブロック１１１２でプライベート・サーバ８２０からクライアントによって取得される。クライアント・ネットワーク・アドレスは、図８に示すネットワーク・アドレス記憶域エリア８４６にストアされる。プライベート・サーバ８２０から取得したクライアント暗号キーは図８に示す暗号キー記憶域エリア８４４にストアされる。クライアント・ネットワーク・アドレスとクライアント暗号キーは共に、それぞれセキュア・クライアント記憶域エリア８４６と８４４にストアされる(処理ブロック１１１４)。ローカル・存在地点ノードのネットワーク・アドレスは処理ブロック１１１６でプライベート・サーバ８２０からクライアント６１０によって取得される。ローカル・存在地点ノードのネットワーク・アドレスは図１２を参照して上述したようにプライベート・サーバ８２０によって判断される。処理ブロック１１１８で、クライアント６１０はプライベート・サーバ８２０から切り離される。クライアント６１０がクライアント・ネットワーク・アドレス、クライアント暗号キー、およびローカル・存在地点ノードのネットワーク・アドレスをプライベート・サーバから取得すると、プライベート・サーバ８２０とのコミュニケーションは必要でなくなる。従って、クライアント６１０はプライベート・サーバ８２０から切り離すことが可能になる。本発明のこの側面は、クライアント６１０がプライベート・サーバ８２０とのセキュア・コネクションを長時間維持しておく必要がないという点で利点となっている。クライアント６１０はプライベート・サーバ８２０によって特定されたローカル・存在地点ノードとのコネクションを確立する。ＰＯＴＳ電話ネットワークの場合には、クライアント６１０はローカル・存在地点ノードの電話番号をダイヤルし、ローカル・存在地点ノードのモデムとのデータ・コネクションを初期化する。処理ブロック１１２０で、クライアント６１０は、クライアント暗号キーを使用してインセキュア・ネットワーク回線１０２０上でＷｅｂＴＶサーバ６２０とのセキュア・コネクションを確立することにより、ローカル・存在地点ノードを通してＷｅｂＴＶサーバ６２０とのコネクションをオープンする。図１３と図１４はサーバ６２０側から見たときの、ＷｅｂＴＶサーバ６２０の処理ロジックを詳しく記載している。クライアント側では、クライアント６１０はブロック１１２０でＷｅｂＴＶサーバ６２０とのコネクションを要求し、その後、図１１に示す終了ブロックを通して終了する。次に、図１３に示すように、ＷｅｂＴＶサーバ６２０の処理ロジックが示されている。ブロック１３１０で、サーバ６２０はオープン・コネクションの要求をクライアント６１０から受信する。クライアント６１０とＷｅｂＴＶサーバ６２０の間のトランザクションはセキュア・トランザクションでなければならないので、ＷｅｂＴＶサーバ６２０はコネクション要求を送ってきたクライアントを認証する必要がある。クライアントから受信したクライアントボックス識別子とクライアント・ネットワーク・アドレスはクライアント６１０を認証するためにＷｅｂＴＶサーバ６２０によって使用できる。しかし、クライアント６１０から受信した暗号化メッセージを解読するためには、ＷｅｂＴＶサーバ６２０はクライアント暗号キーを取得する必要がある。このクライアント暗号キーはインセキュア・データ通信回線上でＷｅｂＴＶサーバ６２０に転送することはできない。ＷｅｂＴＶサーバ６２０はセキュア・ソースからクライアント暗号キーを取得しなければならない。好適実施例では、プライベート・サーバ８２０はクライアント暗号キーを取得するためのソースとしてＷｅｂＴＶユーザ６２０によって使用できる。クライアント６１０がプライベート・サーバ８２０とのコネクションを確立したのと同じように、ＷｅｂＴＶサーバ６２０はプライベート・サーバ８２０とのプライベートでセキュアなデータ通信回線を確立することができる。処理ブロック１３１１で、ＷｅｂＴＶサーバ６２０はセキュア・ネットワーク回線上でプライベート・サーバ８２０とのセキュア・コネクションをオープンし、オープン・コネクション要求の中でクライアントから受信したクライアントボックス識別子とクライアント・ネットワーク・アドレスを使用してクライアント暗号キーを取得する。次に、図１５に示すように、ＷｅｂＴＶサーバ６２０からの要求を処理するためのプライベート・サーバ８２０の処理ロジックがフローチャート形式で示されている。処理ブロック１５１０で、プライベート・サーバ８２０はクライアントボックス番号とクライアント・ネットワーク・アドレスで特定された特定クライアントに関連するクライアント暗号キーの要求をＷｅｂＴＶサーバ６２０から受信する。プライベート・サーバ８２０は最初に、要求元が確かにＷｅｂＴＶサーバにあることを、ＷｅｂＴＶサーバ６２０に関連づけられた事前定義パスコード（passcode）を使用して確かめる。次に、プライベート・サーバ８２０の暗号キー生成ロジック９１２はＷｅｂＴＶサーバ６２０から与えられたクライアントボックス番号とクライアント・ネットワーク・アドレスを使用して、特定されたクライアントのための暗号キーを取得する(処理ブロック１５１４)。特定されたクライアントがプライベート・サーバ８２０とのコネクションを以前に確立していれば、そのクライアントに関連づけられた暗号キーは暗号キー生成記憶域エリア９１２にストアされる。このクライアント暗号キーはプライベート・サーバ８２０によって記憶域エリア９１２から検索され、セキュア・メッセージでＷｅｂＴＶサーバ６２０に転送される(処理ブロック１５１８)。そのあと、プライベート・サーバによる処理は図１５に示す終了ブロックで終了する。図１３に戻って説明すると、処理ブロック１３１１で、ＷｅｂＴＶサーバ６２０はプライベート・サーバ８２０からクライアント暗号キーを取得している。ＷｅｂＴＶサーバ６２０はここでプライベート・サーバ８２０から切り離すことができる。ＷｅｂＴＶサーバ６２０は自身の暗号キー記憶域エリア１０１３を、プライベート・サーバ８２０から検索したクライアント暗号キーで更新する。処理ブロック１３１２で、ＷｅｂＴＶサーバ６２０はクライアントボックス識別子とクライアント・ネットワーク・アドレスを使用して要求元クライアントを認証する。クライアントボックス識別子とクライアント・ネットワーク・アドレスはＷｅｂＴＶサーバ６２０側のクライアント認証データ記憶域エリア１０１０にストアされているクライアント認証データと比較される。クライアントボックス識別子とクライアント・ネットワーク・アドレスを使用すると、特定のＷｅｂＴＶクライアントボックスが特定のネットワーク・アドレスで動作しているかどうかを確かめることができる。別のシステムで別の認証が必要であれば、パスワードまたはアカウントコードをクライアント６１０および／または特定のユーザに要求することもできる。この情報はすべて、ＷｅｂＴＶサーバ６２０側のクライアント認証データ記憶域エリア１０１０にストアし、管理することができる。クライアントボックス識別子とクライアント・ネットワーク・アドレスがクライアント認証データ記憶域エリア１０１０に見つかり、認証されていれば、処理ブロック１３１６でコネクションがクライアント６１０とＷｅｂＴＶサーバ６２０の間でオープンされる。そのあと、認証されたクライアントに対するＷｅｂＴＶサーバ６２０の処理は図１４にＡで示した個所から続行される。他方、クライアントが認証されていなければ、認証失敗を示すエラー・メッセージが要求元クライアントに戻される(処理ブロック１３１８)。その後、ＷｅｂＴＶサーバ６２０の処理は図１３に示す終了ブロックで終了する。クライアントからプライベート・サーバへのＡＮＩ検証コネクションは、存在地点ノードへのローカル・コールよりもコストがかかるのが代表的である(２０秒間でほぼ＄０．０２)。従って、ＡＮＩ検証を余り頻繁に行うことは費用効率的でない。しかし、次のときはＡＮＩ検証を行う価値がある。すなわち、１）クライアントボックス（つまり、ネットワーク・インタフェース装置）を初期起動するとき、２）クライアントボックスが別の電話番号に移動しなかったことを定期的に確かめるとき、または３）疑わしいアクティビティ（つまり、パスワード試みが何度も失敗した）がクライアントボックスで行われたとき、である。この分野の精通者ならば理解されるように、ここに教示されている検証プロセスは、いくつかの異なる状況で採用することが可能である。本発明の代替実施例では、ＷｅｂＴＶサーバ６２０とプライベート・サーバ８２０を１つにして同じコンピュータ・システムに置いておくことができる。この実施例では、クライアント暗号キーをやりとりするための、ＷｅｂＴＶサーバ６２０とプライベート・サーバ８２０の間のトランザクションは、クライアント暗号キーが同じシステム内にすでに置かれているので必要でなくなる。この場合、ＷｅｂＴＶサーバ６２０は結合サーバ・システムの暗号キー記憶域エリア９１２からクライアント暗号キーを検索するだけである。次に、図１４を参照して説明すると、ＷｅｂＴＶサーバ６２０の処理は認証されたクライアントに対してＡで示す個所から続行される。この場合、クライアント６１０とＷｅｂＴＶサーバ６２０の間のデータ・コミュニケーション・コネクションはすでにオープンされている。クライアント６１０とＷｅｂＴＶサーバ６２０は共に、上述した処理ステップで取得された共通暗号キーをもっているので、クライアント６１０とサーバ６２０の間のコミュニケーションは暗号化することができ、これにより、他の場合にはインセキュアなネットワーク・コネクション上でセキュアな通信回線が得られることになる。従って、クライアント６１０からの以後のサービス要求およびＷｅｂＴＶサーバ６２０からの対応する応答を暗号化できるので、セキュアなデータ・コミュニケーションが保証されることになる。図１４に示す処理ブロック１４１０で、暗号化サービス要求はクライアント６１０からＷｅｂＴＶサーバ６２０によって受信される。クライアント・ネットワーク・アドレスは、クライアント・サービス要求の一部として与えられるのが代表的である。クライアント・ネットワーク・アドレスはクライアントの論理的ネットワーク・ロケーションを表しているのが代表的であるが、ある種のネットワークでは、クライアント・ネットワーク・アドレスをクライアントの地理的ロケーションと関連づけることも可能である。例えば、ＰＯＴＳ電話ネットワークでは、クライアント・ネットワーク・アドレスはクライアントの電話番号で表されている。従来技術の使用により、電話番号は地理的ロケーションと関連付けることができる。エリアコードはクライアント電話番号の代表的コンポーネントである。エリアコードは電話ネットワークを管理する従来の電話会社で設定されている、明確に定義された地理的リージョン（地域）と関連づけられている。さらに、７桁電話番号の３桁プレフィックスはエリアコードで識別されたリージョン内の特定の地理的サブリージョンをさらに示している。７桁電話番号の残りの４桁は前記定義されたサブリージョン内の特定のロケーションをさらに定義している。この従来電話番号情報を使用すると、電話番号を特定の地理的ロケーションと関連づけるネットワーク地理的データのセットを生成することができる。この情報はＷｅｂＴＶサーバ６２０側のネットワーク地理的データ記憶域エリア１０１２にストアされる。電話ネットワーク以外のネットワーク環境では、クライアント・ネットワーク・アドレスおよび対応する地理的ロケーションの間の他の関連づけを定義して、ネットワーク地理的データ記憶域エリア１０１２にストアしておくことができる。クライアント６１０は、ＷｅｂＴＶサーバ６２０がクライアント６１０がどの地理的ローカリティからＷｅｂＴＶサーバ６２０と通信しているかを確かめることができるようにすると、いくつかの面で利点が得られる。例えば、種々のクライアント・サービス要求はそのサービス要求が出された地理的ローカリティに基づいて最適化することができる。例えば、ビジネス・トランザクションの場合には、クライアントはＷｅｂＴＶサーバ６２０を経由して商品を配達することを要求することがある。クライアントが配達要求を出した地理的ローカリティが分かっていれば、ＷｅｂＴＶサーバ６２０は要求元クライアントに地理的に最も近い配達ステーションを選択することができる。その他の場合には、ＷｅｂＴＶサーバ６２０によって提供される特定サービスはクライアントの地理的ロケーションに応じて異なる場合がある。例えば、クライアントは高データ転送率情報ストリームをクライアント・サイトに配送することを要求することがある。この高データ転送率情報ストリームはビデオストリーム、オーディオ・ストリーム、または他のコンテンツ中心の情報ストリームを表している場合がある。クライアント・ローカリティを取り巻く情報ストリームのインフラストラクチャに応じて、ＷｅｂＴＶサーバ６２０は最適情報ストリーム配送メカニズムを選択する場合がある。例えば、クライアントが要求を出そうとしている地理的ロケーションは統合サービス・ディジタル・ネットワーク（ＩＳＤＮ）サービスがそのロケーションで利用可能になっている場合がある。このような場合であれば、ＷｅｂＴＶサーバ６２０はＩＳＤＮネットワーク上での特定クライアントへの情報配送を自動的に構成することができる。他方、ケーブル・モデム・サービスがそのクライアント・ローカリティで利用可能になっていれば、代わりにＷｅｂＴＶサーバ６２０はケーブル・モデム・サービスを使用してハイレート情報をクライアント６１０に配送することも可能である。これらのオプションのどちらも、ネットワーク地理的データ記憶域エリア１０１２にストアされている特定クライアントに対応し、特定クライアント・ネットワーク・アドレスに関連づけられた地理的ローカリティ情報を使用すると、ＷｅｂＴＶサーバ６２０によって最適に選択することができる。電話ネットワークの場合には、サーバ６２０はクライアントがそのアドレス、電話番号、または他のタイプのローカリティ情報を指定していなくても、要求元クライアントの電話番号を使用してクライアントの地理的ロケーションを判断する。電話番号は、エリアコード・マップ・データベースなどの周知の技法を用いて地理的ロケーションに対応づけられている。要求元クライアントの電話番号を使用すると、サービス・プロバイダまたはＷｅｂＴＶサーバ６２０は、クライアントのロケーションに最も近い該当のサプライヤまたは倉庫を選択することができる。クライアントのロケーションが分かっていないと、非効率な配送シナリオになる可能性がある。例えば、クライアントは、同様の倉庫がクライアントのロケーションの近くに存在する場合でも、遠く離れた倉庫から商品を供給するサプライヤに商品を注文することが起こり得る。その他の場合には、サービス・プロバイダは提供されるサービスを、要求元クライアントの電話番号に基づいてカスタマイズすることができる。例えば、特定の地理的ロケーションに関連づけられた特定のメニュー・アイテムは、ＡＮＩが導入された要求元クライアントの電話番号に基づいて特定のクライアントのために提供することができる。別の例として、サービス・オファリング、オファリングの価格、またはオファリングの時間はＡＮＩの要求元クライアントの電話番号に基づいて変更することができる。図１４に戻って説明すると、クライアント・サービス要求がそのクライアントに関連する特定の地理的ロケーション用に最適化できる場合には、クライアント・ネットワーク・アドレスがブロック１４１４で取得される。このクライアント・ネットワーク・アドレスを使用して、ＷｅｂＴＶサーバ６２０はネットワーク地理的データにアクセスして対応するクライアント地理的ローカリティを判断する(処理ブロック１４１６)。このようにして取得したクライアント地理的ローカリティを使用すると、クライアント・サービス要求は処理ブロック１４１８で最適化することができる。そのあと、ＷｅｂＴＶサーバ６２０の処理は図１４に示す終了ブロックで終了する。判断ブロック１４１２で、サービス要求が地理的ローカリティに基づいて最適化できなければ、ＷｅｂＴＶサーバによるこの部分の処理は図１４に示す終了ブロックで終了する。本発明のＡＮＩプライベート・サーバの別の実施例では、プライベート・サーバ８２０は他の場合にはインセキュアであるトランザクションのセキュア部分を実行するために使用できる。例えば、ユーザはカタログ、プロダクト／サービス・リスティング、またはその他の取り引き情報をＷＷＷネットワーク上でインセキュア・トランザクションを通してブラウズすることがあるが、ユーザが購入を行ってクレジットカード番号、個人情報、または機密または個人所有情報を送信しようとするとき、クライアント６１０は図１１を参照して上述したように、ＷＷＷ（つまり、インセキュア・ネットワーク）から切り離され、セキュア・ネットワーク上でセキュア直接電話コールを通してプライベート・サーバ８２０にダイヤルする。プライベート・サーバ８２０はクライアント６１０のＡＮＩがクライアントボックスの期待電話番号に対応していることを確かめる。クライアント６１０のＡＮＩがクライアントボックスの期待電話番号に対応していなければ( 例えば、ハッカが有料（公衆）電話からトランザクションを偽造することを試みた場合)、プライベート・サーバ８２０はそのトランザクションを拒否する。逆に、クライアントＡＮＩがクライアントボックスの期待電話番号に対応していれば、そのクライアントは有効にされる。有効にされたクライアントは上述したように、セキュア・ネットワーク上でそのトランザクションのセキュア部分を実行し、トランザクションのセキュア部分が完了すると、インセキュア・ネットワークに戻るようにダイヤルする。本発明のＷｅｂＴＶネットワークで可能とされる地理的調整には、他にもいくつかの利点がある。特定のクライアントが地理的にどこにいるかを、クライアント・ロケーションを判断するためのＷｅｂＴＶネットワーク・インタフェース装置の手段を使用して知ることにより、クライアント要求に対するサーバ応答はクライアントの特定地理的ローカリティに合わせて調整することができる。例えば、従来のシステムは、クライアントがオンライン・サービスを使用して商品またはサービスを注文できるようにするネットワーク機能を備えている。しかし、これらの従来サーバはクライアントの地理的ロケーションに関係なく、同じようにすべてのクライアント要求に応答している。しかるに、本発明では、サーバは上述した装置およびプロセスを使用して判断されたクライアントの地理的ロケーションを知ることにより、その応答を特定のクライアントに合わせて調整する。例えば、第１の特定地理的ロケーションには、ＩＳＤＮとケーブル・モデムのハイスピード・データ・サービスが提供されている場合がある。別の第２特定地理的ロケーションには、ＩＳＤＮハイスピード・データ・サービスだけが提供されている場合がある。第１ロケーションにいるクライアントＡがＷｅｂＴＶサーバにハイスピード・データ・サービスを注文すると、ＩＳＤＮサービスとケーブル・モデム・サービスのどちらを選択するかがクライアントＡに提示される。第２ロケーションにいるクライアントＢがＷｅｂＴＶサーバにハイスピード・データ・サービスを注文すると、クライアントＢにはＩＳＤＮサービスだけが提供される。クライアントＡに対する応答とクライアントＢに対する応答にこのような違いが起こるのは、ＷｅｂＴＶサーバが要求元クライアントの地理的ロケーションを上述した技法を用いて判断できるためである。さらに、この例でクライアントＡとクライアントＢのどちらかが希望のサービスを選択したとき、ハイスピード・データ・サービスの要求はその特定クライアントの地理的ロケーションにとって最適なハイスピード・データ・サービス・プロバイダにルーティング（ルート決定）することができる。この場合も、この効率的ルーチングが可能であるのは、ＷｅｂＴＶサーバが要求元クライアントの地理的ロケーションを上述した技法を用いて判断できるためである。本発明によって可能とされる地理的調整には、いくつかの利点がある。要求元クライアントの地理的ロケーションが分かると、サーバは、すべての要求元クライアントに対して同じように応答するのではなく、特定のクライアントに合わせて該当の応答をカスタマイズすることができる。さらに、本発明のＷｅｂＴＶサーバは、そこに接続された音声コールとエラーを犯しやすい情報収集方法による、従来の商品とサービス注文方法を実効的に置き換えることができる。本発明によって提供されるクライアント地理的ロケーションの判断と使用が有利とされる理由はほかにもある。上述した技法を使用すると、クライアントはその地理的ロケーションをプライベート・サーバから取得することができる。そのあと、この地理的ロケーション情報はクライアントがトランザクションを行うことを望んでいる他のサーバに渡すことができる。これらの他のサーバまたはサードパーティ・サーバはＷｅｂＴＶネットワークまたはＷｅｂＴＶサーバから完全に独立している場合がある。従って、ＷｅｂＴＶプライベート・サーバを使用すると、いかなる独立ネットワーク・サービス・プロバイダから提供されるオンライン・サービスを最適化することができる。例えば、花屋やピザパーラなどの商店は、ネットワーク上で商品を注文するためのオンライン・サービスを提供することが可能になる。特定タイプのビジネスでは、地理的ロケーションが重要である場合がある。商品配送を必要とするビジネスの場合には、ピザパーラや花屋の例と同じように、クライアントの地理的ロケーションはクライアントへの配送を迅速化するために必要である。この場合には、本発明のプライベート・サーバはクライアントの地理的ローカリティをクライアントに提供する。そのあと、クライアントはこの情報を、サードパーティ・サーバとのトランザクションの一部としてサードパーティ・サーバに引き渡す。サードパーティ・サーバは、本発明のプライベート・サーバが介入していることに気づくことなく地理的ローカリティ情報を使用してクライアントとのトランザクションを最適化する。本発明のもう１つの利点は、ネットワーク接続のゲームプレイヤ間でリアルタイム・ゲームプレイを可能にすることである。まず、重要なことは２種類のリモート・マルチプレイヤ・ゲーム、つまり、１）「リアルタイム」または「ツイッチ (twitch)」ゲームと２）「非リアルタイム」ゲームとが、ここでは区別されていることである。ツイッチ・ゲームはプレイヤによるスプリット・セコンドゲーム制御を必要とし、恣意的なコミュニケーション・レイテンシまたはデイレイを許さないゲームである。ツイッチ・ゲームは最も人気のあるビデオゲームのカテゴリに属し、代表例として、すべてのトップテン・ゲームはツイッチゲームであり、そのようなゲームとしては、"Mortal Kombat"(商標)、"John Madden Football"( 商標)、"Sonic the Hedgehog"(商標)、および"Super Mario Brothers"（商標）がある。代表例として、ツイッチゲームはゲームがプレイ可能になるまでに（つまり、プレイヤのアクションがスクリーン上で効力をもつまでの時間）コミュニケーション・レイテンシが100ミリ秒以下であることが必要である。ツイッチゲームはコミュニケーション・レイテンシのディレイが変化するのを許さないのが通常である。非リアルタイム・ゲームはコミュニケーション・レイテンシが大きく、コミュニケーション・レイテンシが変化する場合でも、プレイが可能であるゲームである。このジャンルに属するゲームとしては、チェスやバックギャモンなどの「ストラテジ」ゲームがあるが、Activision（商標）社の"Return to Zork"（商標）およびSierra On-line（商標）社の"King's Quest"（商標）シリーズのようなアドベンチャゲームなどの、穏健なアクションゲームもある。AT&T ImagiNation N etwork（商標）はそのような非リアルタイム・ゲームを専門とするオンライン・サービスである。インターネットとＷＷＷは非リアルタイム・ゲームをプレイするためにも使用されている。マルチプレイヤ・ツイッチゲームが普及してくると、ImagiNation Network(商標)などのオンライン・サービスがそのゲームのユーザのためにツイッチゲームを提供するようになることは想像される。しかし、これらのサービスおよびインターネットやＷＷＷ上で実現されいる他のサービスは、そのようなゲームを提供していない。その理由は、現存公衆交換データ・ネットワークのアーキテクチャが与えられているとき、レイテンシを100ミリ秒(msec)以下にすることも、レイテンシを一定に保つことさえも不可能であるためである。現存ネットワーク・アーキテクチャでは、大きなレイテンシが起こっている( 予測不能なこともよくある)。コミュニケーション・チェイン内の各モデムが引き起こすレイテンシは２０または３０ミリ秒(msec)まで高くなっている(モデム・メーカおよびモデルによって変化している)。電話ネットワークはレイテンシを引き起こしている(ローカル発信地域内では最小であるが)。広域ネットワーク（ＷＡＮ）は予測不能なレイテンシを引き起こしている(ラウンドトリップが1.5 秒である)。さらに、オンライン・サービスのコンピュータ自身もレイテンシを引き起こし、これはアクティブユーザ数の増加と共に増加するのが代表的である。以上の結果、リモート・マルチプレイヤ・ツイッチゲームをプレイできるのは既存公衆アクセス・データ・ネットワークの大幅なオーバホール（莫大な資本投資が必要になる）を除き、あるゲームプレイヤを別のゲームプレイヤに結ぶ直接電話コネクションを通してだけである。その結果、オンライン・サービスおよびインターネットまたはＷＷＷベースのサービスは非リアルタイム・マルチプレイヤゲームのホストとなることに限定されている。インターネットおよびＷＷＷはレイテンシの問題があるため、リアルタイム・ゲームには不十分なネットワークであるが、インターネットおよびＷＷＷは同じゲームを一緒に同時にプレイすることを望んでいるリモート・プレイヤを一緒に対抗させるには都合のよいソースである。これは、インターネットが遍在するネットワークであるためである。従って、インターネットおよびＷＷＷまたは他の公衆ネットワーク・インフラストラクチャを使用して、リモート・ゲームプレイヤを対抗させ、ゲーム結果を通知するようにし、しかも、リアルタイム・ゲームを実際にプレイするときは別の低レイテンシ・ネットワークを使用するようにすると好都合である。リアルタイム・ネットワーク接続ゲームをプレイするときに起こるこの問題は従来技術では認識も、解決もされていない。本発明は以下に説明するように解決方法を提供している。上述したように、本発明はＷｅｂＴＶクライアント６１０を提供し、このクライアントが第１ネットワーク８５８上でプライベート・サーバ８２０とのセキュア・コミュニケーションを初期確立し、従来の第２ネットワーク６１２を通してセキュア・コミュニケーション環境を実質的に確立するようにしている。従って、第１ネットワークはパラメータを定義し、第２ネットワーク上でのコミュニケーションを可能にするために使用されている。この考え方はリアルタイム・ゲーム環境でも採用されている。しかし、リアルタイム・ゲームという意味では、ＷｅｂＴＶクライアント６１０は、インターネットやＷＷＷなどの非リアルタイム・ネットワーク上でＷｅｂＴＶサーバとのコネクションを初期確立して、プレイヤが同じゲームを同時にプレイすることを望んでいる別のリモート・プレイヤと対抗することを要求するようにしている。サーバが２人のネットワーク接続クライアントをネットワーク接続リアルタイム・ゲームの競技相手として対抗させると、２人の対抗クライアントは非リアルタイム・ネットワークから切り離され、ＷｅｂＴＶサーバから取得したネットワーク・アドレス情報を使用してリアルタイム・ネットワーク上で相互に接続される。このプロセスは図１６に詳しく示されている。次に、図１６に示すように、本発明のリアルタイム・ネットワーク・ゲーム・メカニズムが示されている。図１６において、フローチャートはネットワーク接続のリモート・クライアント対抗相手とリアルタイム・ゲームをプレイすることを望んでるＷｅｂＴＶクライアント１６によって実行される処理を示している。図１６に示すロジックは、クライアント６１０間の直接電話リンクなどのリアルタイム・データ・ネットワーク上で別のリモート・クライアント６１０とのリアルタイム・データ通信リンクを確立するためにローカル・クライアント６１０によって使用される。最初の処理ステップ１６１０で、ローカル・クライアント６１０はパワーアップ初期化を実行する。次に、ローカル・クライアント６１０は図８に示すように、存在地点ノード８１０を経由する非リアルタイム・ネットワーク回線８５６上で、直接的には回線８５２上でＷｅｂＴＶサーバ６２０と接続する(ブロック１６１２)。ローカル・クライアント６１０がＷｅｂＴＶサーバ６２０に接続されると、ローカル・クライアント６１０は、特定のリアルタイム・ゲームをプレイしたいことを以前にＷｅｂＴＶサーバ６２０に通知していた別のリモート・クライアントとローカル・クライアント６１０とを対抗させるようにＷｅｂＴＶサーバ６２０に要求する(ブロック１６１４)。ローカル・クライアント６１０はそのネットワーク・アドレスをＷｅｂＴＶサーバ６２０に与える。リモート・クライアント６１０はそのネットワーク・アドレスをすでにＷｅｂＴＶサーバ６２０に渡している。ＷｅｂＴＶサーバ６２０は、試合を行わせるための種々の情報アイテムを使用して２クライアントを対抗させる。この情報には、クライアントのネットワーク・アドレスで示されたクライアントの地理的ロケーション、プレイされるリアルタイム・ツイッチゲームの名称または種類、各クライアントの指定されたスキルレベル、その他の関連情報がある。ＷｅｂＴＶサーバがクライアント６１０を対抗させると、ＷｅｂＴＶサーバはその対抗相手のネットワーク・アドレスを各クライアントに通知する(ブロック１６１６)。それを受けて、各対抗クライアントはＷｅｂＴＶサーバから切り離され(ブロック１６１８)、対抗相手とのリンクをリアルタイム・ネットワーク上で確立する。好適実施例では、このリンクは直接電話回線を使用して確立することができ、各クライアントが与えるネットワーク・アドレスはその電話番号である。非常に低レイテンシの通信リンクを対抗クライアントの間で確立できるので、リアルタイム・ネットワーク接続ゲームのプレイが可能になる(ブロック１６２０)。この分野の精通者ならば理解されるように、クライアント・ゲームプレイヤが非リアルタイム・ネットワーク上で対抗された後、他の従来リアルタイム・ネットワーク・インフラストラクチャを使用して、実際のゲームプレイを実行させることも可能である。最小コスト・オンライン・アクセス次に、図１７を参照して、最小コスト・オンライン・アクセスを実現する装置について説明する。カストマ／ユーザ・システム１７１０はネットワーク・コネクタ１７１２、プロセッサ１７１４およびディスプレイ・ユニット１７１６を含んでいるのが一般的である。モデム・ライン１７１８を経由するネットワーク・コネクタ１７１２はネットワーク１７２０に接続され、カストマ／ユーザがＷＷＷサーバ１７２２にアクセスすることを可能にしている。複数のアクセス・プロバイダ１７２１はＷＷＷサーバ１７２２にアクセスしてカストマ／ユーザがＷＷＷサーバにアクセスできるように構成されている。一般的に、カストマ／ユーザはＷＷＷサーバとのリンクを提供するアクセス・プロバイダとアカウントを結んでいる。本発明の一実施例によれば、カストマ／ユーザは種々のアクセス・プロバイダの中から選択して、カストマ／ユーザとアクセス・プロバイダの両方に利益をもたすようにしている。代表例として、アクセス・プロバイダは特定クラスの人達に特定のサービスを提供している。例えば、あるアクセス・プロバイダは、一般的に通常の営業時間に営業している商業ビジネスにサービスを提供し、他のアクセス・プロバイダは一般的に夜間、週末および休日に働いているコンシューマにサービスを提供している。カストマが営業時間外にアクセス・プロバイダを利用できるようにするシステムはシステムの利用を最適化し、従って、特定のアクセス・プロバイダ・システムの使用を全時間にわたってバランスよくしている。カストマ側から見たとき、異なる時間に異なるアクセス・プロバイダを利用できることはサービスにアクセスするコストを大幅に低減することになる。従って、カストマは種々のアクセス・プロバイダにアクセスすることが可能になり、アクセス・プロバイダの方は、幅広いカストマ層に利用されることが可能になる。図１７に示すように、本発明によるセントラル・アクセッサ１７２４が示されている。サーバはモデム・ライン１７２６を介してカストマ／ユーザ１７１０に接続され、カストマ／ユーザからアクセス要求を受信するようになっている。自動番号識別ユニット１７２８は着信コールを受信し、上述したように着信電話番号でカストマ／ユーザを識別する。カストマ／ユーザはセントラル・アクセス・サーバとアカウントを結んでいるのが代表的である。セントラル・アクセス・サーバ１７２４はインターネット・アクセス・プロバイダ電話リスト１７３２とカストマ基準リスト１７３４の情報を含むデータ・リスト１７３０を保持している。これらのリストを組み合わせると、セントラル・アクセス・サーバは十分な情報を得て、カストマ／ユーザとアクセス・プロバイダ間の互換性を分析することができる。要求の時刻、曜日、休日、アクセス・プロバイダ間の通話中信号の発生、累積または予想接続時間、アクセス品質、パフォーマンスの信頼性などのカストマ／ユーザ基準およびその他の基準は、あるカストマにとって互換性のあるアクセス・プロバイダを見つけるために使用される。そのあと、インターネット・アクセス・プロバイダ情報はカストマ／ユーザ情報と比較され、互換性のある合致するものが見つけられる。次に、アルゴリズムがアルゴリズム・ジェネレータ１７３６で生成され、カストマ／ユーザ１７１０に配布され、モデム・ライン１７２６を経由してカストマ／ユーザ・プロセッサ１７１４に配布され、アクセス・プロバイダ１７２１を選択するためにカストマ／ユーザによって使用される。そのあと、プロセッサ１７１４はアルゴリズムをデコードし、ネットワーク１７２０を通してアクセス・プロバイダを選択する。そのあと、そのアクセス・プロバイダはカストマ／ユーザ１７１０がＷＷＷサーバ１７２２にアクセスできるようにする。次に図１８に示すように、図１７のネットワーク・システムに関連するセントラル・アクセス・サーバ１７２１の機能が示されている。最初のステージ１８４０で、カストマ／ユーザは図１７の電話回線またはモデム・ライン１７２６を介してセントラル・アクセス・サーバにアクセスし、アクセス・プロバイダに関する情報を検索する。次のステップ１８４２で、セントラル・アクセス・サーバはアクセス要求を受信し、上述したように従来の技法を用いて自動番号識別（ＡＮＩ）を使用してカストマを識別する。これを受けて、ステップ１８４４でセントラル・アクセス・サーバはカストマの識別に応じてカストマ基準リストにアクセスする。ステップ１８４６で、セントラル・アクセス・サーバはインターネット・アクセス・プロバイダ電話リストにアクセスし、異なるアクセス・プロバイダとカストマ／ユーザの間の互換性を分析する。合致するものおよび代替的に合致するものが見つかると、ステップ１８４８でセントラル・アクセス・サーバはアルゴリズム・ジェネレータ１７３６でアルゴリズムを生成し、それをカストマ／ユーザに配送し、カストマがカストマ基準および対応するアクセス・プロバイダ互換性に従ってインターネット・アクセス・プロバイダを選択できるようにする。ステップ１８５０で、カストマ／ユーザはアルゴリズムを受信し、そのアルゴリズムをデコードし、プロセッサ１７１４がステップ１８５２でアクセス・プロバイダを選択できるようにする。最後に、ステップ１８５４で、カストマ／ユーザはインターネット・アクセス・プロバイダに接続し、インターネットにアクセスする。ある実施例では、初期コネクションが行われると、クライアント・ソフトウェアは８００番号にダイヤルしてセントラル・アクセス・サーバと接続することができる。ＡＮＩを使用すると、サーバはＡＮＩで識別されたユーザの番号についてデータベース・チェックを行い、クライアント・ソフトウェアに２つのローカル電話番号を渡すことができる。一方のインターネット・アクセス・プロバイダのモデムプールに対する第１のローカル番号は営業時間アクセスにサービスを提供し、他方のインターネット・アクセス・プロバイダのモデムプールに対する第２のローカル番号は営業時間外クライアントにサービスを提供する。そのあと、サーバはクライアント・ソフトウェアで実行可能なアルゴリズムを送信することができる。そのあと、このクライアント・ソフトウェアは時刻と曜日をチェックすることになるが、このアルゴリズムを使用すると、互換性のあるアクセス・プロバイダを選択することができる。例えば、時刻が午前９時から午後５時までの間にあり、日がウィークデイであれば、アルゴリズムはビジネス・クライアントにサービスを提供するインターネット・アクセス・プロバイダをダイヤルアップするようにユーザに指示することになる。その他の場合は、ユーザはコンシューマ・ベースのシステムをダイヤルアップするように指示されることになる。休日であれば、アルゴリズムはそれに応じて行動することになる。このアルゴリズムを使用すると、ユーザは選択したアクセス・プロバイダへの回線が通話中である場合に代替番号をダイヤルアップすることもできる。このアルゴリズムは大量使用または少量使用ユーザのために有利な料率を提供するインターネット・アクセス・プロバイダを必要とするカストマのために使用することも可能である。例えば、ユーザがある月の接続時間量をある程度増加した後、セントラル・アクセス・サーバは大量使用ユーザにとってより安価な別のインターネット・アクセス・プロバイダにアクセスするようにユーザに指示することができる。同様に、ユーザが非常に少量使用ユーザであるのが代表的であれば、セントラル・アクセス・サーバは少量使用ユーザにとってより安価であるインターネット・アクセス・プロバイダにアクセスするようにユーザに指示することができる。別の実施例では、クライアント・ソフトウェアはその接続のたびにセントラル・アクセス・サーバに問い合わせて、新しい電話番号および新しいアクセス・プロバイダを選択するための新しいアルゴリズムを取得するように用意することも可能である。クライアントに別の電話番号をダイヤルするか、あるいは別のアカウント名でログインするように指示することも可能である。これは事情によっては非常に有利になる場合がある。例えば、あるインターネット・アクセス・プロバイダがあるアカウントに対してある時間数を提供していれば、セントラル・アクセス・プロバイダは、いつ、どのアカウント名で、どれだけの時間ログインさせるかをクライアントに指示することにより、複数のアカウントを共有するように複数のクライアントに指示することができる。このようにすると、セントラル・アクセス・プロバイダは、各アカウントを最大時間量まで利用できるようになる。AT&TおよびWorldNetが提供するもののように、フラットレート（一定料率）のアクセス権をもつアカウントの場合には、あるアカウントを１日２４時間使用し、複数のユーザで共有できるが、同時に２人以上のユーザで利用されることはない。別の実施例では、セントラル・アクセス・サーバとの初期コネクションが行われると、セントラル・アクセス・サーバはクライアントが隔離した地理的エリアにいるかを判断し、セントラル・アクセス・サーバはその地域で特に低料率を提供しているリージョナル・インターネット・アクセス・プロバイダをそのクライアントに提供する場合がある。例えば、全国的規模のインターネット・アクセス・プロバイダは時間当たりの料率が低く、存在地点（ＰＯＰｓ）と呼ばれる大規模なモデムプール・ネットワークを全米にわたってもっているが、カリフォルニア州South Lake Tahoeのような、特定の隔離エリアではＰＯＰをもっていない場合がある。この特定の隔離エリアにはローカル・インターネット・アクセス・プロバイダが存在する場合もあるが、規模の経済性が小さいために、ローカル・プロバイダは時間当たりの料率が高くなっている。セントラル・アクセス・サーバがクライアントがこの隔離エリアにいると判断したとき、全国的規模のインターネット・アクセス・プロバイダの方が時間当たりの料率が有利であっても、そのクライアントにローカル・インターネット・アクセス・プロバイダを指示することが可能である。そのあと、セントラル・アクセス・プロバイダはその特定カストマにどのアクセス・シナリオが最良であるかを判断することになる。従って、セントラル・アクセス・プロバイダはインターネット・アクセス・プロバイダ・サービスのコストだけでなく、代替インターネット・アクセス・プロバイダに到達するまでの電話コールのコストも考慮することによって、ユーザの費用を節減することができる。以上のように、ネットワーク・アドレス情報を使用してネットワーク・トランザクションのパフォーマンスを向上するための改良装置と方法について説明してきた。上述してきた具体的構成と方法は本発明の原理を例示したものにすぎない。この分野の精通者ならば理解されるように、本発明の範囲を逸脱しない限り形態および細部において種々変更が可能である。本発明は特定の実施例を参照して説明してきたが、本発明はその特定実施例に限定されるものではない。むしろ本発明が限定されるのは請求の範囲に記載されている本発明の範囲によってのみである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＣＺ，ＤＥ，ＤＥ，ＤＫ，ＤＫ，ＥＥ，ＥＥ，ＥＳ，ＦＩ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者ジオラ，トム，ジェイ. アメリカ合衆国 94025 カリフォルニア州メンロパークウッドランドアヴェニュ 893 (72)発明者ハーマン，ウィリアム，シー. アメリカ合衆国 94563 カリフォルニア州オリンダエルカミニト２【要約の続き】ネスユーザであるかといったユーザのタイプなどの要因およびその他の要因は種々のインターネット・アクセス・プロバイダを効率よく利用するためのものである。

Claims

【特許請求の範囲】 1. 少なくとも１つのユーザからの着信アクセス要求をルーティングするためのデータベース・セントラル・ルーティング装置であって、セントラル・サーバと、アクセスを要求するユーザをカストマとして識別するユーザ識別装置と、データベース・アクセス・プロバイダの電話番号に関するアルゴリズムを生成するように構成されたアルゴリズム・ジェネレータとを備え、前記セントラル・サーバはユーザ基準に従ってアルゴリズムをダウンロードするように構成されていることを特徴とするデータベース・セントラル・ルーティング装置。 2. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記ユーザ識別装置は自動電話番号識別装置であることを特徴とするデータベース・セントラル・ルーティング装置。 3. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記ユーザ識別装置はモデムプールのログイン・ルーチンであることを特徴とするデータベース・セントラル・ルーティング装置。 4. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記セントラル・サーバはユーザを識別し、前記ユーザ基準に関するアルゴリズムを生成するように構成されていることを特徴とするデータベース・セントラル・ルーティング装置。 5. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記基準は時刻、曜日、休日、通話中信号、累積接続時間、予想接続時間、アクセス品質、信頼性、存在地点のパフォーマンス、プロバイダのピーク時間、プロバイダのオフピーク時間、プロバイダの地理的ロケーションおよびユーザの地理的ロケーションを含むことを特徴とするデータベース・セントラル・ルーティング装置。 6. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記セントラル・サーバは前記データベース・アクセス・プロバイダの電話番号をユーザ基準に基づいてダウンロードするように構成されたサーバ・ソフトウェアを含んでいることを特徴とするデータベース・セントラル・ルーティング装置。 7. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記基準はユーザのロケーション、前記ユーザ・ロケーションにおけるデータベース・アクセス・プロバイダの利用可能性、前記データベース・アクセス・プロバイダのコスト、前記ユーザの予想使用パターン、前記データベース・アクセス・プロバイダの予想ダウンタイムおよび前記データベース・アクセス・プロバイダの停止スケジュールを含むことを特徴とするデータベース・セントラル・ルーティング装置。 8. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記アルゴリズム・ジェネレータは前記ユーザがデータベース・アクセス・プロバイダにログインするために使用する少なくとも１つのデータベース・アクセス・プロバイダ・アカウントを生成することを特徴とするデータベース・セントラル・ルーティング装置。 9. 請求項１に記載のデータベース・セントラル・ルーティング装置において、前記アルゴリズム・ジェネレータはどのデータベース・アクセス・プロバイダをどれだけの時間使用するかを判断するためのアルゴリズムを生成することを特徴とするデータベース・セントラル・ルーティング装置。 10．インターネット・アクセス・プロバイダとのコミュニケーションのためにユーザによるアクセス要求をルーティングする方法であって、前記ユーザはモデムに接続するためのネットワーク・コネクタと情報を処理するためのプロセッサをもち、前記方法は自動番号識別装置をもつセントラル・アクセス・サーバと、インターネット・アクセス・プロバイダ電話番号を収めているデータ・リストと、カストマ基準リストと、アルゴリズム・ジェネレータとを組み込んでいる方法において、前記ユーザからのアクセス要求をモデム・ラインを介してセントラル・アクセス・サーバによって受信し、前記ユーザを識別し、前記ユーザＩＤに応じて前記ユーザのカストマ基準にアクセスし、インターネット・アクセス・プロバイダ電話番号にアクセスし、前記ユーザに対して互換性のあるインターネット・アクセス・プロバイダを前記ユーザのカストマ基準を使用して判断し、少なくとも１つの互換性インターネット・アクセス・プロバイダ・アクセス番号を含んでいるアルゴリズムを生成し、および、前記アルゴリズムを前記モデム・ラインを経由して前記ユーザに送信することを備えることを特徴とする方法。