JP2001514468A - 世界的通信ネットワークを管理し市場価格情報を表示する方法及びシステム - Google Patents

Abstract

(57)【要約】 通信伝送を効率的な手法で、柔軟に経路指定するシステム及び方法が開示される。サービスプロバイダは、第１の位置（２）から第２の位置（４）まで通信を経路指定するためのコスト及びサービスパラメータデータを含む情報を集中サーバ（５６）へ提出する国際ゲートウェイスイッチ（２２−２８）に接続される。サーバノードは、提出されたレート情報の全てを受信し、それを評価し、そしてその情報から、通信スイッチングネットワーク内の何れか２つの位置間に伝送を接続する効率的な経路を含むレートテーブルデータベースを生成する。サービス要求者は、サービス要求を集中サーバノードへ提出する。サーバノードは要求者の要求に合致する効率的なルートを識別し、ブローカーは通信時間をサービスプロバイダからサービス要求者へ販売する。システムは、支援している通信ルートに関する市場価格情報を、将来の販売者及び購買者に対して表示することもできる。

Description

【発明の詳細な説明】

【０００１】 （関連特許出願） 本願は、1997年９月11日付米国特許出願第08/927,443号、及び1997年８月29日
付米国特許出願第08/920,567号の部分継続であり、これらの両特許出願は本明細
書に参照として採り入れられている。

【０００２】 （発明の背景） 長距離電話呼出しのコストは、普通は被呼加入者ではなく、起呼加入者によっ
て支払われる。典型的に呼出しの支払いは、そのサービスを発したキャリヤによ
って直接的に、または起呼者のローカル電話サービスプロバイダのエージェンシ
ーを通しての何れかで、起呼加入者から徴収される。従って、発信キャリヤによ
ってサービスされている第１の位置から、異なる終端キャリヤによってサービス
されている第２の位置まである呼出しが行われた場合、発信キャリヤによって起
呼加入者から徴収された収益の若干を終端キャリヤと分配するような規約をもう
けなけらばならない。

【０００３】 国際電話呼出しの場合、この収益配分は、従来から精算協定を使用して達成し
てきた。典型的に精算協定は、国間の呼出しの接続コストに関係付けられた会計
（アカウンティング）レートを確立し、２つの国の間でこの会計レートをどのよ
うに分割するかを指定している。この分割は、典型的には50−50である。

【０００４】 例えば、米国のキャリヤ及び海外のキャリヤが毎分１ドルの会計レートで、50
−50の収益分割を取り決めたものとする。この協定により、米国のキャリヤは接
続時間の１分毎に50セントを、海外のキャリヤによってサービスされている被呼
位置に支払わなければならない。反対に、海外のキャリは、米国のキャリヤによ
って終端される呼出しの接続時間の１分毎に50セントを支払わなければならない
。

【０００５】 しかしながら、良く知られているように、取り決められた会計レートは国際的
な呼出しを完了させる実際のコストよりもかなり高いことが多い。例えば、本明
細書が参照として採り入れているFrieden, Accounting Rates : The Business o
f International Telecommunications and the Incentive to Cheat, 43 Federa
l Communications Law Journal 111, 117を参照されたい。この理由から、及び 米国から出て行く呼出しボリュームの方が、多くの外国からの入ってくる呼出し
ボリュームよりも遙かに多いので、米国のキャリヤは海外のキャリヤに対して大
きい出支払いを行う。多くの場合、これらの料金は最終的にはレート支払い者に
渡される。

【０００６】 この支払いの不平衡は、海外のキャリヤがそれらの制御の下に、米国への私的
電話回線を介して米国へ入るトラフィックを経路指定する場合に悪化する。この
ようにすると、海外のキャリヤはそれらの国から米国への呼出しに対する高い会
計レートでの精算を支払うことを避けながら、米国のキャリヤから高い会計レー
トでの精算を受け取ることができる。海外のキャリヤはその母国における独占者
であるので、米国のキャリヤは、米国から出るトラフィックをその海外のキャリ
ヤを通して経路指定することを余儀なくされている。更に海外のキャリヤは、精
算協定内にこのような挙動を禁止する契約条項が明記されているにも拘わらず、
米国へ入るトラフィックに関してこれらの代替の安価な経路を使用することが多
い。

【０００７】 呼出しトラフィックを経路再指定するように世界的ネットワークを再構成する
のにはかなりの時間及び費用を必要とすることから、今日まで米国のキャリヤは
このような支払いの不平衡を甘受することを余儀なくされ、海外のキャリヤによ
る契約不履行に応答する直接的な方法を有していない。厄介な再構成プロセスが
私的回線を通して米国へ入るトラフィックを経路指定する機会を外国のキャリヤ
に与え、それ以外にも米国のキャリヤから報復される恐れなく、精算収支を成長
させている。

【０００８】 より一般的に言えば、この融通のきかない経路指定構造は、電話サービスプロ
バイダが世界的規模の電話レートの変動の恩恵を受けることを妨害している。消
費者に節約を渡すように、レート変化に応答して動的に経路指定するための方法
を提供することが望ましいであろう。また、電話接続帯域幅のブロックを動的に
売買する手段を電話会社に提供する要望も存在している。

【０００９】 国際的な競争の場においてだけではなく、通信の分野における競争を可能にす
るようにどのような国内市場においても、接続ルートを柔軟に割当て、接続帯域
幅を相応に売買する能力に対する要望が存在している。

【００１０】 （発明の概要） 本発明は、効率的な手法で、通信伝送を柔軟に経路指定するシステム及び方法
を提供する。好ましい実施の形態においては、サービスプロバイダは、第１の位
置から第２の位置までの通信を経路指定するためのコスト及びサービスパラメー
タデータからなる情報を集中サーバノードへ提出する。サーバノードは提出され
た全てのレート情報を受信し、それを評価し、そしてこの情報から、伝送を通信
スイッチングネットワーク内の何れか２つの位置の間で接続するための通路を効
率的に経路指定することを含むレートテーブルデータベースを生成する。サーバ
はそのレートテーブルデータベースを、価格、ネットワーク利用率、戻りトラフ
ィックボリューム、その他のような１つまたはそれ以上のパラメータに対して実
質的に最適化するようにプログラムすることができる。

【００１１】 サービス要求者は、サービス要求を集中サーバノードに提出する。サーバノー
ドは要求者の要求に合致する効率的なルートを識別し、ブローカーは通信（また
は、接続）時間をサービスプロバイダからこれらのサービス要求者に販売する。
接続時間は、取引（例えば、呼出し）の度毎に購入することも、または大きいブ
ロックで購入することもできる。サービス要求は、サービス要求者におけるシス
テム管理者によって手動で、またはそのサービス要求者に関連する遠隔通信ノー
ドによって自動的に提出することができる。遠隔通信ノードは、現在のボリュー
ムを動的に監視し、接続時間に対する実際の、または予測される要求に基づいて
通信時間または帯域幅を売買するようにプログラムすることができる。

【００１２】 サーバノードは、キャリヤの確認、危険管理、金融取引、精算、及び契約管理
を含むネットワークの全ての面、及びネットワークの異なる位置を接続する物理
的リンクの追跡を管理する。

【００１３】 キャリヤが世界的ネットワークを通して購入したあるルートを介して通信（例
えば、音声呼出し）を確立することを望む場合、キャリヤは監視をローカル遠隔
通信ノードに渡し、該ノードはそのキャリヤが購入した接続時間にわたって１つ
の経路を介して伝送を確立する。代替として、通信を行う接続時間は伝送の時点
に購入することができる。

【００１４】 必要な場合、ある入通信取引が異なる位置への通過であり、そのスイッチの位
置で終端するものではないことを経路内のスイッチに通知するために、システム
は特定のＳＳ７コード、Ｃ７コード、Ｃ５コード、ＩＮコード、または他のデー
タメッセージ（または、経路内のいろいろなスイッチ及びゲートウェイの技術的
能力に基づいて、上述したコードの組合わせ）を使用する。このようにすると、
スイッチは終端トラフィックと通過トラフィックとを区別することができ、精算
協定の会計レートを呼出すことなく通過トラフィックのレートをセットすること
が可能になる。

【００１５】 好ましい実施の形態においては、システムは支援している通信ルートに関連す
る市場価格情報を、将来の接続時間の販売者及び購入者に対して表示することが
できる。この表示は、顧客のＰＣ上で走るＪａｖａアプレットによって生成され
たストリ−ミングバナーの形状であることが好ましい。

【００１６】 以上に好ましい実施の形態を起呼電話機及び被呼電話機に関して説明したが、
本発明は電話機ユーザ設備の全ての手法を使用して実現できることを理解された
い。この電話機ユーザ設備は、限定するものではないが、例えば、応答マシン、
ファックスマシン、ビデオ会議装置、ローカルスイッチ（例えば、ホテルまたは
オフィスにおけるような）、音声合成／認識装置、ダイヤラー、応答サービス、
及びコンピュータを含むことができる。

【００１７】 更に、以上に若干の好ましい実施の形態を主として起呼電話機から被呼電話機
までの音声電話呼出しに関連して説明したが、本発明の世界的ネットワークは、
限定するものではないが、例えば、データ伝送、ＩＰ、ＡＴＭ、ＦＲ上の音声、
及び仮想ネットを含む全てのクラスの接続を包含できることを理解されたい。更
に、伝送は、異なる伝送技術を使用する起呼脚からなる通路を介して経路指定す
ることができる。

【００１８】 上述した本発明の概要は、以下の添付図面に基づく詳細な説明からより良く理
解されよう。

【００１９】 （好ましい実施の形態の詳細な説明） 図１Ａは、本発明の世界的ネットワークを実施するのに適する、例えば電話シ
ステムアーキテクチャであることができる通信システムアーキテクチャを示して
いる。図１Ａに示すように、このアーキテクチャは好ましくは起呼電話機２を含
み、該電話機２から起呼加入者は被呼電話機４への電話呼出しを行うことができ
る。起呼電話機２は、回線８によって略示してあるＩＳＤＮのような加入者回線
または別の接続によってローカル電話ネットワーク６に接続されている。ローカ
ル電話ネットワーク６及び回線８は共に、典型的には起呼者のローカル電話サー
ビスプロバイダによって所有され、維持されている。被呼電話機４も同様に、回
線１２によって略示してある加入者回線または別の接続によってローカル電話ネ
ットワーク１０に接続されている。ローカル電話ネットワーク１０及び回線１２
は共に、典型的には被呼側のローカル電話サービスプロバイダによって所有され
、維持されている。

【００２０】 図１Ａには、典型的に長距離キャリヤによって維持されている発信料金スイッ
チ１４も示されている。発信料金スイッチ１４は、好ましくは信号回線及び伝送
回線（一緒に回線１６によって略示してある）の両者を介して、ローカル電話ネ
ットワーク６に接続されている。信号回線は、例えばＳＳ７ネットワークの一部
を形成することができる。伝送回線は、ローカル電話ネットワーク６と発信料金
スイッチ１４との間で音声及びデータ伝送を伝える。

【００２１】 図１Ａには、典型的に被呼加入者の長距離プロバイダによって維持されている
終端料金スイッチ１８も示されている。終端料金スイッチ１８は、信号回線及び
伝送（一緒に回線２０によって略示してある）の両者を介して、ローカル電話ネ
ットワーク１０に接続されている。信号回線は、例えばＳＳ７ネットワークの一
部を形成することができる。伝送回線は、ローカル電話ネットワーク１０と発信
料金スイッチ１８との間で音声及びデータ伝送を伝える。

【００２２】 システムアーキテクチャは発信国際ゲートウェイスイッチ２２をも含み、該ス
イッチ２２は起呼電話機２から配置された海外呼出しを経路指定し、伝える。発
信国際ゲートウェイスイッチ２２は、終端国際ゲートスイッチ２４並びに通過国
国際ゲートウェイスイッチ２６、２８を含む国際ゲートウェイスイッチの世界的
ネットワークの一部を形成している。国際ゲートウェイネットワーク内の各ゲー
トウェイ対は、好ましくは信号回線及び伝送回線（一緒に回線３０−３８によっ
て略示してある）によってリンクされている。

【００２３】 明らかに、国際ゲートウェイスイッチ、料金スイッチ（終端または発信）、及
び特定位置におけるローカルネットワークは、その位置の規則環境に依存して同
一の、または異なる企業実体によって所有され、維持されている。

【００２４】 発信国際ゲートウェイスイッチ２２は、好ましくは信号回線及び伝送回線（回
線４０によって略示してある）を介して発信料金スイッチ１４に接続されている
。同様に、終端国際ゲートウェイスイッチ２２は、好ましくは信号回線及び伝送
回線（回線４２によって略示してある）を介して終端料金スイッチ１８に接続さ
れている。信号回線は、例えばＳＳ７ネットワークの一部を形成することができ
る。伝送回線は、２つの国際ゲートウェイスイッチとそれらの関連料金スイッチ
との間で音声及びデータ伝送を伝える。

【００２５】 図１Ａには、４つの国際ゲートウェイスイッチ（２２−２８）だけが示されて
いるが、当業者ならば、ここに開示しているアーキテクチャがどのような数のゲ
ートウェイに関しても一般化できることは理解されよう。また、当業者ならば、
発信、終端、または通過としてのゲートウェイの状態が、ＳＳ７信号ネットワー
クまたは所有権を主張できる信号方式プロトコルに従って伝送されるデータメッ
セージのような他のデータメッセージによって決定されることも理解されよう。
更に、当業者ならば、異なる通信プロバイダを有する国内市場における類似ネッ
トワークアーキテクチャの構造も理解できよう。

【００２６】 システムアーキテクチャは、遠隔通信ノード４４−４８のネットワークを更に
含んでいる。ネットワーク内の各ノードは、国際ゲートウェイスイッチ２２−２
８の１つに組合わせることができ、またデータ回線５０−５４を介してその関連
国際ゲートウェイスイッチに接続することができる。代替として、遠隔通信ノー
ドは、例えばノード４９のような国際ゲートウェイスイッチを組み入れることが
できる。詳細を後述するように、ノード４４−４９は、ゲートウェイネットワー
クと共存していてゲートウェイネットワークを介して伝えられた若干の呼出しの
経路指定を管理するオーバレイネットワークを含む。

【００２７】 図１Ｂに示すように、各ノード４４−４９には、好ましくは以下のものが設け
られている。 キャリヤ自身のコストデータベース９９（そのノードに関連している各キャリ
ヤ毎に１つ）。これは、あるキャリヤが潜在的発信位置から潜在的終端位置まで
ある呼出しを接続する内部コストに関する情報を格納している。 他に対して公開された価格データベース９８（そのノードに関連している各キ
ャリヤ毎に１つ）。これは、潜在的発信位置から潜在的終端位置まで接続するた
めに、あるキャリヤが公開した価格を格納している。 世界的ネットワークコストデータベース９７。これは、潜在的発信位置から潜
在的終端位置まで接続するためのいろいろなルートのコストに関する情報を格納
している。詳細を後述するように、この情報は、図１Ａのサーバノード５６によ
って受信される。

【００２８】 その他に、ノード４４−４９には、好ましくは以下のものが更に設けられてい
る。 相互接続データベース９６（そのノードに関連している各キャリヤ毎に１つ）
。これは、あるキャリヤによって維持されている物理的伝送設備、それらの設備
が支援する技術（例えば、音声、ＡＴＭ、インターネット等）、及びそのキャリ
ヤの設備が相互接続される他のキャリヤの名前及び位置に関する情報を格納して
いる。この情報は、世界的ネットワークの使用可能な物理的相互接続をマップす
るためにシステムによって使用される。

【００２９】 ノード４４−４９には、ビジネス・ルールデータベース９５（そのノードに関
連している各キャリヤ毎に１つ）も設けられている。これは、ビジネスルールを
格納しているが、その目的に関しては後述する。

【００３０】 遠隔通信ノードネットワークは、サーバノード５６をも含む。図１Ａには単一
のノードとして示されているが、サーバノード５６は、代わりとして、分散した
サーバのネットワークであることができる。分散ネットワークの構成要素は、ノ
ード４４−４８内に組み入れることができる。遠隔通信ノードネットワーク内の
各ノード４４−４８は、それぞれデータ回線５８−６２によってサーバノード５
６に接続されている。好ましくは、各データ回線は少なくとも64Ｋｂ／ｓの帯域
幅を有している。詳細は後述するように、サーバノード５６はレート及び可能経
路指定情報を格納し、そのネットワークを介して伝送される呼出しのための費用
効率的な経路を決定する。またサーバノード５６は、取引をクリアし、オーバレ
イ遠隔通信ノードネットワークによって管理されている全ての呼出しの経路指定
を調整する。呼出し経路指定は、要求中のキャリヤによって提出されたサービス
要求に指定されているパラメータに基づいて決定される。

【００３１】 図２に示すように、サーバノード５６は３つのステップ、即ち(1)レート情報 を収集するステップ、(2)収集した情報を評価するステップ、及び(3)収集した情
報及びネットワークトポロジマップから、国際ゲートウェイネットワーク内の各
スイッチ対毎の費用効率的な経路を含むレート・テーブルを生成するステップに
よって、国際ゲートウェイネットワークを介して接続される呼出しのための費用
効率的な経路を決定する。

【００３２】 ステップ(1)において、システムは世界中の国際キャリヤからレート情報を収 集する。レート情報の各記録は、第１の位置から第２の位置までの呼出しを経路
指定するためにキャリヤによって賦課される価格、並びに呼出しボリューム容量
、及び伝送の品質、信頼性、及び安全性のようなサービスに関連する詳細、法的
制約（例えば、終端制約）、ダイアル後遅延（ＰＤＤ）、サービスの型（例えば
、音声、ファックス、データ、ビデオ）、及びリンクにおいて使用されている技
術（例えば、ＩＳＤＮ、ＡＴＭ）を含む。

【００３３】 好ましくは、キャリヤは、サーバノード５６によって維持されているワールド
・ワイド・ウェブサイトにおいてアクセスできるテンプレート３００を介してレ
ート情報を入力する。代替として、スイッチ２、２６、及び２８のような国際ゲ
ートウェイスイッチを所有し、維持しているか、またはノード４４−４８を所有
し、維持しているキャリヤは、遠隔通信ノード４４−４８を介してレート情報を
サーバノード５６へ伝送することができる。図３Ａは、このようなテンプレート
の１つの適当な配列を示している。図３Ａに示すように、テンプレートは提供す
るサービスに関する情報を入力するための複数のフィールドを含んでいる。例え
ば、これらのフィールドは次のものを含むことができる。 キャリヤ名フィールド３０２、 キャリヤ識別番号フィールド３０４、 パスワードフィールド３０６、 提出日フィールド３０８、 品質フィールド３１０（接続に関する品質を格納）、 からフィールド３１２（提供されるサービスの発信位置を格納）、 へフィールド３１４（提供されるサービスの宛先位置を格納。これは、もしそ
のサービスがその国内の何処においても利用可能であれば国コードの形状を取る
ことができ、もしそのサービスがその国内の特定領域だけに利用可能であれば国
及び領域コードの形状を取ることができ、またはもしそのサービスが特定の被呼
電話機だけに提供されるのであれば全宛先番号の形状を取ることができる）、 使用可能時間フィールド３１８（ある価格で使用できる時間を分／月で格納）
、 回路数フィールド３２０（そのキャリヤが処理できる最大並行呼出し数を格納
）、 価格フィールド３２２、 動作時間フィールド３２４（購入した接続時間を使用できる動作の時間を格納
）。

【００３４】 更に、好ましくは、テンプレートは以下のフィールドを含むことができる。 サービスの型フィールド（例えば、音声、ファックス、データ、ビデオのよう
な提供されるサービスの型）、 ダイアル後遅延（ＰＤＤ）フィールド、 まで有効フィールド（それまで提供が開かれている日付を格納）、 法的制約フィールド（接続時間の使用に影響し得る法的制約に関する情報を格
納）、 支払い期限フィールド（そのプロバイダによって要求される何等かの特別な支
払い期限を格納）、 圧縮レベルフィールド（伝送に使用される最大圧縮レベルを格納）、 設備の型フィールド（そのサービスプロバイダが使用している設備の型を格納
）、 信号方式・互換性フィールド（そのプロバイダが取扱うことができる信号方式
プロトコル、例えばＳＳ７、ＩＮを格納）、 最大待ち時間フィールド（この文脈における待ち時間とは、ルータにおける輻
輳に起因する遅延である）。

【００３５】 また、テンプレートは、好ましくは以下のフィールドを更に含む。 ローカル終端を行うか？フィールド、 精算を行うか？フィールド、 私的回線を介するか？フィールド、 契約の長さフィールド、 衛星を介するか？フィールド、 終端オプション？フィールド。 これらのフィールドの目的は後述する。

【００３６】 当業者ならば、上述したフィールドのリストは、テンプレート３００が含むこ
とができるフィールドの単なる例に過ぎないことが理解されよう。テンプレート
３００は、プロバイダのキャリヤと要求者のキャリヤとの間の経路の決定及び仲
介取引を行う際にサーバノード５６を援助する付加的な、または異なる情報のた
めのフィールドを含むことができる。

【００３７】 好ましい実施の形態においては、３つのレベルのパスワードがサーバによって
発行される。第１レベルのパスワードは、そのパスワード保持者が公開されたレ
ートにアクセスすることは許すが、そのパスワード保持者がサーバを介して時間
を売買することは許さない。第２レベルパスワードは、そのパスワード保持者が
サーバを介して接続時間を買うことは許すが、売ることは許さない。第３レベル
パスワードは、サーバを介して接続時間を売買する権利をそのパスワード保持者
に与える。従って、テンプレート３００を提出するキャリヤは、第３レベルのパ
スワードを所有することが要求される。

【００３８】 好ましい実施の形態においては、単一のテンプレート上にリストされている全
てのルートは、同一の品質のものである。即ち、例えば図３Ａに示すように、各
テンプレートには、好ましくは１つだけの品質フィールドが設けられている。異
なる品質の付加的なルートを提供しようとしているキャリヤは、異なるテンプレ
ート上でそのようにするであろう。また、単一のテンプレート上にリストされて
いる全てのルートは、好ましくは同一のサービスの型のためのものである。

【００３９】 同様に、好ましい実施の形態においては、単一のテンプレート上にリストされ
ている全てのルートは、同一の発信位置からである。従って、例えば図３Ａに示
すように、各テンプレートには、好ましくは単一の発信位置フィールド３１２が
設けられている。付加的な発信位置からの接続を提供しようとしているキャリヤ
は、異なるテンプレート上でそのようにするであろう。

【００４０】 図３Ａに示すように、テンプレート３００は、キャリヤによってリストされた
各ルート毎に、２つまたはそれ以上の使用可能時間フィールド、回路数フィール
ド、価格フィールド、及び動作時間フィールドを含むことができる。これらによ
り、キャリヤは日及び週の異なる時刻におけるサービスの価格を異ならせること
ができる。それは、多くのキャリヤが保証された価格スケールを使用することに
も繋がる。保証された価格スケールにおいては、ある容量（例えば、30万分／月
）までの接続時間に賦課されるレートが、その容量以上の接続時間のレートとは
異なる。

【００４１】 例えば、図３Ａに示すように、あるキャリヤは、米国からアルバニア（国コー
ド３５５）のKorce（市コード８２４）までのサービスのために１つより多くの 価格をリストすることができる。例えば、30万分／月を購入する場合、キャリヤ
は、月曜日から金曜日までの、及び土曜日及び日曜日の12時から午後６時までの
呼出しに対しては62.5セント／分を請求することができる。これに対して、月曜
日から金曜日までの午後８時から午前０時まで、及び土曜日及び日曜日の午前５
時から午後６時までの呼出しに対しては59.8セント／分を請求することができる
。

【００４２】 図３Ａには、キャリヤへテンプレート３００を伝送する前にサーバノード５６
によって充填される取引開始日付フィールドも示されている。この日付は、テン
プレート上に入力された接続時間が世界的ネットワークによって売りに出される
開始日を反映している。テンプレート３００上に注記されているように、販売者
は取引開始日付に先立つある所定時間量（例えば、３日）の間レート情報を提出
することを要求される。これは、詳細を後述するように、受信したレート情報を
処理し、それからレートテーブルを生成する時間をサーバノード５６に与える。

【００４３】 上述したように、テンプレートは、図３Ａには示されていない付加的なフィー
ルドを含むことができる。例えば、テンプレート３００は、キャリヤがフィール
ド３１４内に格納されている位置における呼出しのローカル終端を行うことがで
きるのか否かを表すブール値を格納するフィールドであるローカル終端を行うか
？を含むことができる。ローカル終端は、幾つかの理由から不可能であり得る。
例えば、終端がローカル規則によって禁止されているかも知れないし、またはキ
ャリヤが特定の位置における呼出しを終端させるのに必要な設備を有していない
かも知れない。

【００４４】 テンプレート３００は、精算を行うか？フィールド（ブール値）を含むことも
できる。若干のキャリヤは、終端国との精算協定が呼出されるような手法で呼出
しを経路指定することを法律によって要求されている。精算協定は、ある呼出し
が公衆交換電話回線網（ＰＳＴＮ）を介して伝送される時には呼出されるが、私
的回線またはデータ回線を介して経路指定されている場合には呼出されない。従
って、サービスプロバイダが提供する特定のルートが精算をトリガするのか否か
を確立することは、サーバにとって重要であり得る。

【００４５】 テンプレート３００は、私的回線を介してか？フィールド（ブール値）をも含
むことができる。詳細は後述するように、このフィールドによってサーバノード
５６は、私的回線を使用するルートの接続時間を購入することを欲しないキャリ
ヤを順応させることができる。

【００４６】 テンプレート３００は、精算を介してか？フィールド（ブール値）をも含むこ
とができる。上述したように、サーバノード５６は、１つより多くのキャリヤに
よって提供されるサービスを組合わせ、第１の位置から第２の位置までの呼出し
ルートを作成することができる。公知のように、あるルート内に２つの衛星リン
クを使用する接続の品質及びダイヤル後遅延は受け入れ難いことが多い。このフ
ィールドによってサーバノード５６は、衛星リンクに頼るサービスを識別し、起
呼位置を被呼位置に接続するために１つより多くの衛星リンクを使用する経路を
回避することができる。

【００４７】 テンプレート３００は、終端オプションフィールドをも含むことができる。例
えば、キャリヤは、終端オプションとしてファックスバイパス能力を提供するこ
とができる。ファックスバイパスは、ファックス伝送のコストを実質的に減少さ
せるための１つの方法を提供する。典型的には、ファックス伝送は、高い会計レ
ートで精算される電話回線を介して送られる。ファックスバイパスでは、ルート
内のノードはファックス伝送のファックストーンを認識し、その呼出しをデータ
回線を介して再経路指定する。このようにすると、ファックスはかなり低減され
たコストで伝送することができる。更に、当業者には明らかなように、ＩＰ上の
音声のような他の終端オプションをリストすることができる。

【００４８】 キャリヤによって賦課される価格は、提供される通信サービスに依存させるこ
とができる。例えば、キャリヤは音声呼出しに対しては第１のレートで、また音
声メール、会議、ページング、ｅメールアクセス、インターネットアクセス、フ
ァックス検索、ファックス伝送、ＰＰＰアクセス、ユニバーサルパーソナルアシ
スタント（汎用メールボックス）のようなサービスを受ける呼出しに対しては他
のレートでの接続時間を提供することができる。更に、いろいろなレベルの音声
サービス、例えば専用回線及びＩＳＤＮ回線を設けることができる。

【００４９】 システムは、いろいろなクラスの呼出しを第１の位置から第２の位置まで経路
指定するためのコスト及びサービスパラメータに関するレート情報を世界中のキ
ャリヤから収集した後に、図２のステップ(2)へ進む。ステップ(2)においては、
システムは受信した情報、特に伝送品質及び信頼性のようなサービス関連情報を
評価し、与えられたパラメータの精度を決定する。サーバノード５６は遠隔通信
取引のためのクリアリングハウスとして動作するから、サーバノード５６から時
間を購入するキャリヤが、サーバノード５６の公開されたサービスパラメータを
信頼することが重要である。従って、サーバノード５６は、キャリヤから受信し
たサービスパラメータ情報を独立的に評価し、各パラメータ（例えば、品質）に
“Ａ”、“Ｂ”、“Ｃ”等のレーティングを割当てる。この評価は、先にサーバ
ノード５６に格納したキャリヤのサービスに関する情報に基づく。サーバは、割
当てられたパラメータを、例えば特定のキャリヤの履歴的信頼性のようないろい
ろな要件に基づいてアップグレードまたはダウングレードすることができる。例
えば、もしそのサーバが一般的に衛星接続に対して“Ｂ”信頼性レーティングを
割当てるものとすれば、もし特定の衛星接続が履歴的により高レベルの信頼性を
呈していれば、その衛星接続に“Ａ”レーティングを割当てることができる。

【００５０】 ステップ(3)において、サーバノード５６は、遠隔通信ノードネットワーク内 の何れか２つの位置をいろいろなルートを介して接続するコストをリストしてい
る収集されたレート情報、及び各ルートに関連するサービスパラメータからレー
トテーブルを導出する。好ましくは、サーバノード５６は、世界的ネットワーク
が提供することができる各クラスのサービス（例えば、音声、データ、ビデオ会
議、等）毎に別個のレートテーブルを導出する。次いでこの情報は、サーバノー
ド５６内に位置するレートテーブルデータベース内に格納される。図４は、いろ
いろなルートに対して異なるキャリヤが賦課するレートを表すレート／テーブル
データベース４００内の若干のデータのための１つの可能な配列を示す例である
。

【００５１】 本明細書がその全文を参照している本出願人の係属出願第08/811,071号に開示
されているように、発信位置から終端位置までの呼出しは、各々が呼出し経路内
の２つの位置をブリッジしている幾つかの呼出し脚からなる呼出し経路を介して
接続できることは理解されよう。更に、上記出願に記載されているように、各脚
は順方向または逆方向の何れにも完了させることができる。従って、レートテー
ブルデータベース４００内に格納される決定された経路は、世界中のキャリヤが
提供するサービスを組合わせることによって形成されることが多い。

【００５２】 例えば、もし第１のキャリヤが米国から英国まで第１の価格で提供するサーバ
ノード５６に１つのテンプレートを提出し、第２のキャリヤが英国からドイツま
で第２の価格で提供するサーバノード５６に１つのテンプレートを提出すれば、
サーバノード５６はこれら２つを組合わせ、第１の価格と第２の価格との合計に
等しい価格で米国からドイツまでのルートとしてこの組合わせを提供することが
できる。

【００５３】 あるルートのための関連サービスパラメータ情報は、提出されたレート情報並
びにあるルートに割当てられた１つのパラメータに影響され得る他の要因の両者
を斟酌する。例えば、１つのルートは２つの“Ａ”品質脚からなることができる
が、２脚呼出しを確立する際の実質的な遅延のために、組合わせ内の２つの脚は
“Ａ”品質接続を構成しないことがあり得る。

【００５４】 また、応用の待ち時間が、呼出しにとって重要なパラメータを決定する上で大
きく影響することに注目されたい。即ち、例えば、音声呼出しにとって重要なパ
ラメータは、例えばファックスを伝送するためのパラメータとは異なる。

【００５５】 前記本出願人の係属出願第08/811,071号に更に記載されているように、ネット
ワーク内の何れか２つのノード間の考え得る経路の合計数は、ノードの数が増加
するにつれて急激に増加する。従って、遠隔通信ノードネットワーク内の遠隔通
信ノードの数が小さくない限り、ネットワーク内の何れか２つのノードを接続す
る各潜在ルート毎に経路指定情報を決定し、格納することは実際的ではない。し
かしながら、当業者には明白なように、レートテーブルエントリを計算して格納
する必要があるルートの数は、幾つかの理由から管理可能な数に保持することが
できる。

【００５６】 第１に、理論的に可能なルートの数は極めて多いが、多くのルートは法的な制
約、または他の制約のためにレートテーブル計算から直ちに排除することができ
る。例えば、ローカル規則が、私的回線を介して発信されたトラフィックの終端
、またはローカルゲートウェイスイッチを通るものを除くトラフィックの終端の
ような若干の取引を禁止しているかも知れない。これらの呼出しルートのための
レートテーブルは計算し、格納する必要はない。

【００５７】 更に、当業者には明白なように、ネットワーク内の２つのノードを接続する合
理的な程度の精度を有し、費用効率的なルートを識別するための発見的（ヒュー
リスティック）技術が存在している。これらの公知の発見的技術を使用すると、
システムは、合理的な数の費用効率的な経路を選択し、これらの各経路に関連す
るコスト及びサービスパラメータを計算し、格納することができる。

【００５８】 更に、当分野においては公知のように、これらの発見的技術を使用して、他の
パラメータに対しては制約を賦課するが、１つのパラメータに対してほぼ最適な
ルートを見出すことができる。即ち、例えば、これらの発見的技術は、幾つかの
品質または安全性レベルの各々毎に最も費用効率的なルートを識別することがで
きる。

【００５９】 例えば、システムは、各限定されたレベルの品質及びサービス毎にノードの各
対を接続する５つ（または、予測されるトラフィックボリュームに依存して、そ
れ以上）のコストを計算することができる。これらの５つのルートは価格に従っ
てランク付けされ、サーバノード５６におけるレートテーブルデータベース４０
０内に格納される。また取引がなされ、ルートが充填されるにつれて、システム
はネットワークの新しい状態を与えられた付加的なルートを決定することができ
る。

【００６０】 更に、本明細書がその全文を参照している本出願人の係属出願第08/727,681号
の開示によれば、経路は各脚が異なる技術を使用する幾つかの呼出し脚で構成す
ることができる。例えば、経路は公衆交換電話回線網（ＰＳＴＮ）上を伝送され
る第１の脚と、インターネット上を伝送される第２の脚と、ＡＴＭ上で伝送され
る第３の脚とからなることができる。上記係属出願第08/727,681号に記載されて
いるように、異なる技術の呼出し脚は、たとえ経路の若干の中間脚が起呼加入者
とも被呼加入者とも両立不能な技術からなっていても、起呼加入者と被呼加入者
との間の端末相互接続を与えるように透過的にリンクすることができる。

【００６１】 レートテーブルが計算され、レートテーブルデータベース４００内に格納され
た後は、そのデータベースのコピーを遠隔通信ノードネットワーク内の各ノード
４４−４９へ伝送することができる。代替として、各ノードはサーバノード５６
によって計算されたレートテーブルの部分集合だけを、要求して受信することが
できる。例えば、米国内のノードは、米国から発信するルートに関係のあるレー
トテーブルだけを受信することができる。

【００６２】 更新されたレートテーブルは、好ましくは例えば週２回のように、定期的にシ
ステムによって生成される。代替として、もしシステムのコンピュータハードウ
ェア及びソフトウェアの速度及び能力が許すならば、レートテーブル生成はより
屡々遂行することができる。事実、十分な計算能力があれば、ネットワーク内の
レートまたはサービスパラメータが変化する度毎に、システムはそのレートテー
ブルを更新することができる。

【００６３】 サーバノード５６は、キャリヤが遠隔位置までの接続時間のブロックを購入す
ることを、または伝送の度毎に接続時間を購入することを許可する。この能力に
おいては、サーバノード５６は、接続サービスを販売したいプロバイダのキャリ
ヤと、接続サービスを購入したい要求中のキャリヤとの間の取引をクリアするた
めのクリアリングハウスとして動作する。本発明のこの面は、キャリヤが最低の
利用可能な価格で帯域幅を購入できる接続レートのための自由市場を促進する。
以下に、本発明の取引クリアリング面に関して２つの例について説明する。第１
の例は、キャリヤによる接続時間のブロックの購入と、購入した接続時間の一部
を使用する呼出しの接続である。この第１の例を説明するために、図５及び６Ａ
−Ｃを参照する。第２の例は、呼出しの度毎の接続時間の購入である。

【００６４】 第１の例の説明から始める。米国のキャリヤが、９月の１月間に１千万分だけ
ドイツまでの“Ａ”レベル品質及び“Ｂ”レベル信頼性接続時間を23セント／分
より高くない価格で購入したいものとする。ステップ５０２において、米国のキ
ャリヤはサーバノード５６を用いて購入要求を配置し、上記期間中にドイツまで
の接続時間を１千万分購入することを要求する。

【００６５】 好ましくは、キャリヤは、サーバノード５６によって維持されているワールド
・ワイド・ウェブサイトにおいてアクセスすることができるテンプレート３５０
を介して購入要求を入力する。代替として、スイッチ２、２６、及び２８のよう
な国際ゲートウェイスイッチを所有し、維持しているキャリヤは、遠隔通信ノー
ド４４−４８を介して購入要求をサーバノード５６へ伝送することができる。

【００６６】 図３Ｂは、このようなテンプレートのための１つの適当な配列を示している。
図３Ｂに示すように、テンプレートは、購入要求に関する情報を入力するための
複数のフィールドを含んでいる。好ましい実施の形態においては、テンプレート
３５０は以下のフィールドを含むことができる。 顧客識別番号フィールド３５２、 パスワードフィールド３５４、 発信位置フィールド３５６、 終端位置フィールド３５８、 ローカル終端を要求するか？フィールド３６０、 精算を要求するか？フィールド３６２、 動作時間フィールド３６４、 分の数フィールド３６６、 品質フィールド３６８、 最大ダイヤル後遅延（ＰＤＤ）フィールド３７０、 私的回線を許すか？フィールド３７２、 によって分類フィールド３７６、 契約の長さフィールド３７６、及び 受入れ可能なキャリヤフィールド３７８。

【００６７】 当業者には明白なように、上記フィールドのリストは、テンプレート３５０が
含むことができるフィールドを単に例示したに過ぎない。テンプレート３５０は
サーバノード５６が経路指定を決定し、プロバイダのキャリヤと要求者のキャリ
ヤとの間の取引を仲介するをの援助する何等かの情報のためのフィールドを含む
ことができる。

【００６８】 上述したように、若干のプロバイダサーバは、若干の呼出しに対するローカル
終端を行うことができない。ローカル終端を要求するか？フィールド３６０は、
要求者キャリヤが終端位置においてそれ自体でローカル終端を行うことができる
ことを、従って呼出しを被呼位置まで伝送する終端能力を有していないキャリヤ
を使用できることを指示するのを許容する。

【００６９】 上述したように、若干のプロバイダは、精算協定を呼出すような手法で呼出し
を終端させることを要求できる。 require-settlement?フィールド３６２はキャリアにその情報を提供させる。 number of minutesフィールド３６６は、キャリアが購入するのを望む分数を記 憶する。 maximum PDDフィールド３７０は、キャリアが呼び出している当事者を呼び出さ れた当事者に接続することを受け入れる気がある最大の秒数を記憶する。これは
、いくつかのルート、特に、多くの呼び出しレッグまたはサテライト・リンクを
備えるルートが他のルートよりも接続するのに長くかかるので、呼び出しに割り
当てられ得るルートに影響を及ぼす可能性がある。

【００７０】 上記のように、いくつかのキャリアは、専用回線を経由して送信競れることにな
っている呼び出しを望まない可能性がある。allow private line?フィールド３ ７２は、リクエスティング・キャリアにこの情報を入力することを許す。 sort-ｂyフィールド３７４において、キャリアはサービス・パラメータに関する
テンプレートにおけるフィールドを重要性の順序でランク付けする。たとえば、
キャリアは、最も重要なフィールドとしてクオリティを、二番目に重要なフィー
ルドとしてmaximum PDDを、というようにランク付けを行い得る。下記のように 、リクエスティング・キャリアからのサービス・リクエストを正しく満たせない
ときには、サーバー・ノード５６はこの情報を使用する。 契約フィールド３７６の長さにおいて、キャリアは接続時間を買うことを望む所
望の月数を入力することができる。

【００７１】 acceptable carrierフィールド３７８においては、リクエスティング・キャリア
は、そのトラフィックのルートを決められることができるキャリアに制約をかけ
ることができる。たとえば、リクエスティング・キャリアは、サーバー・ノード
５６によってランク付けられたような或るパラメータ（たとえば、クオリティ）
に関してトップ５キャリアだけを経由してそのトラフィックを送信したいという
ことを要求することができる。他の例では、キャリアがオーバフロー・トラフィ
ックを支えるのに接続時間を購入する必要がある場合には、元々第三者に売られ
ていたそれ自身のネットワークについて時間を再販しないということを要求する
ことができる。

【００７２】 サーバー・ノード５６で購入オーダーを受けたとき、システムはステップ５０４
へ進み、そこにおいて、サーバー・ノード５６は、リクエスティング・キャリア
の要求を満たし、販売に利用できる接続時間を有するルートについて、昇順価格
順序でレート・テーブル・データベース４００を検索する。サーバー・ノード５
６は、利用できるキャパシティを持つルートを確認したときには、そのキャパシ
ティを割り当て、ステップ５０６に示すように、リクエスティング・キャリアの
購入リクエストを満たす。ステップ５０４〜５０６は、購入リクエストが満たさ
れるまで、または、リクエスティング・キャリアの要求を満たすすべての利用可
能ルートが、ステップ５０８、５１０に示すように否認されてしまうまで、繰り
返される。

【００７３】 たとえば、ここで、図６Ａが１０，０００，０００音声分についての購入リクエ
ストをリクエスティング・キャリアから受けた時点でのレート・テーブル・デー
タベース４００の一部の状態を表していると仮定する。この場合、サーバー・ノ
ード５６は、リクエスティング・キャリアの１０，０００，０００分リクエスト
を満たす際にステップ５０４〜５１０によって説明したループを３回完了するこ
とになる。３回目のループの終結で、最も安価なルートからの２，０００，００
０分のキャパシティ、次に安価なルートからの４，０００，０００分のキャパシ
ティおよび三番目に安価なルートからの４，０００，０００分のキャパシティが
割り当てられており、リクエスティング・キャリアの購入リクエストを満たして
いる。図６Ｂは、この図示例の終結でのレート・テーブル・データベース４００
の状態を表している。 ステップ５１２aにおいて、サーバー・ノード５６は、ルーティング経路に参加 しているあらゆるキャリアに割り当てられた接続時間ブロックにバイヤーがいる
ことをキャリアに知らせるデータ・メッセージを送る。 ステップ５１２ｂにお
いて、プロバイダ・キャリアは許可メッセージをサーバー・ノード５６に送り、
トランザクションを許可する。あるいは、サーバー・ノード５６は、キャリアに
よってグローバル・ネットワークに提出されたいかなる時間も販売するように予
め権限を与えられていてもよい。

【００７４】 ステップ５１２ｃにおいて、サーバー・ノード５６は、販売のために割り当てら
れた接続時間のブロックを売りに出している元のノード４４にサービス・オファ
ーを送信する。 ステップ５１２ｄにおいて、元のノード４４は受理メッセージ
をサーバー・ノード５６に送る。ステップ５１２ｅにおいて、サーバー・ノード
５６は、以下にもっと詳しく説明するように、トランザクションにおけるあらゆ
るキャリアのアカウント収支を調整してリクエスティング・キャリアへの割り当
てられた接続時間の転送およびプロバイダ・キャリアへの割り当てられた接続時
間のコストの転送に反映させることによってトランザクションをクリアし、そし
て、全当事者に確認メッセージを送信する。 これと対照的に、ここで、レート・テーブル・データベース４００が図６Ｃに示
すようなものであると仮定する。この場合、サーバー・ノード５６は、ステップ
５０４〜５１０によって説明したループを２回完了する。この間、最も安価なル
ートからの２，０００，０００分および２番目に安価なルートからの４，０００
，０００分が割り当てられ、リクエスティング・キャリアのリクエストを満たす
。しかしながら、図６Ｃの例において、アメリカおよびドイツを接続するすべて
の他のルートのコストは毎分２３セントを超える。したがって、２番目のループ
否認後、ステップ５１０は停止し、そして、システムはステップ５１４へ進む。

【００７５】 ステップ５１４において、サーバー・ノード５６はリクエスティング・キャリア
にデータ・メッセージを送り、そのリクエストが毎分２３セント以下で完全に満
たされ得ないことを知らせる。このメッセージは、また、リクエスティング・キ
ャリアに米国、ドイツ間の接続時間を確保するのに利用できる２番目にベストな
価格（たとえば、毎分２８セント）を提供する。ステップ５１６で示したように
、リクエスティング・キャリアは、３つの方法でサーバー・ノード５６からのメ
ッセージに応答することができる。まず、リクエスティング・キャリアは受理を
伝えることができ、この場合、サーバー・ノード５６は接続時間（毎分２８セン
トでの接続時間を含む）を割り当て、リクエスティング・キャリアの購入リクエ
ストを満たす（ステップ５１８）。ステップ５２０において、サーバー・ノード
５６は、ステップ５１２ａ-ｅに記載したと同様の方法でトランザクションをク リアする。

【００７６】 次に、リクエスティング・キャリアは否定を伝えることができる。この場合、
ステップ５２２で説明したように、サーバー・ノード５６はトランザクションを
キャンセルする。 ３番目に、リクエスティング・キャリアは、たとえ接続時間の量が元々要求し
たよりも少なくても、その価格要件を満たす利用可能な接続時間分を受け入れる
ことができる。この場合、サーバー・ノード５６は、ステップ５２４で説明した
ように、リクエスティング・キャリアの期間を満たす接続時間をリクエスティン
グ・キャリアに割り当てる。ステップ５２６において、サーバー・ノード５６は
、ステップ５１２a-ｅに記載したものと同様の方法でトランザクションをクリア
する。

【００７７】 サーバー・ノード５６は、本発明のグローバル・ネットワークを通して接続時
間を購入あるいは販売する各キャリアについて稼働アカウントを維持する。した
がって、ひとたびトランザクションの許可がサーバー・ノード５６によってリク
エスティング・キャリアに与えられていたならば、サーバー・ノード５６はその
リクエスティング・キャリアおよびプロバイダ・キャリアの収支を調節して、リ
クエスティング・キャリアによるプロバイダ・キャリアからのサービスの購入を
反映する。周期的（たとえば、毎月）に、サーバー・ノード５６は、負の収支を
持つキャリアに請求書を送り、正の収支を有するキャリアに支払書を転送する。
このようにして、サーバー・ノード５６は、すべてのアカウントの清算を管理す
る。サーバー・ノードは、また、トランザクションと関連した信用リスクを管理
する。これは、投資情報サービス会社と組み合わせて達成することができる。

【００７８】 １ブロックの接続時間を購入したキャリアが購入したキャパシティを使用でき
ないことが分かった場合、再販の時点での市場状況に応じて元々支払ったよりも
高いあるいは低いレートで（一度に１つのブロックあるいは１つコネクト・トラ
ンザクションとして）接続時間を再販することができる。サーバーは、また、接
続時間についての将来およびそれから派生する市場をサポートすることもできる
。キャリアは、また、ヘッジング技術を使用して大きい価格変動からそれ自体を
保護することができる。 当業者にはわかるように、１ブロックの通信時間の購
入することについて上記プロトコルを説明したが、他のプロトコルも代わりに使
用することができる。たとえば、キャリアは、或る価格を特定することなく特定
のサービス・パラメータ要件を満たす１ブロックの接続時間をリクエストするこ
とができる。この場合、サーバー・ノード５６は、リクエストされたサービス・
パラメータに最も近い最良の利用可能価格を持つ１つまたはそれ以上のルートを
経由して１ブロックの通信時間を識別し、このブロックをキャリアに売りに出す
ことができる。 以下に、本発明のグローバル・ネットワークの呼び出しルーティング動作の概要
を図７に関連して説明する。図７に示されるステージの各々を、図８〜１０と関
連してより詳しく説明する。

【００７９】 図７に示すように、好ましい実施例は呼び出し電話から被呼び出し電話への任
意の呼び出しをルートに載せる３ステップ・プロセスを使用する。 ステップ（
１）において、呼び出し電話２と元の国際ゲートウェイ・スイッチ２２との間の
接続が確立される。ステップ（２）において、システムはルーティング経路を割
り当て、呼び出しを呼び出された場所に接続する。ステップ（３）において、ル
ーティング経路が確立され、呼び出し中の当事者が呼び出された当事者に接続さ
れる。 以下、この３ステップ・プロセスを、初めの場所から最終場所への或る典型的な
呼び出しのためにルートを確保することを示す一例を用いて説明する。当業者に
はわかるように、この例は比較的単純なセットの潜在的な呼び出しルーティング
を示している。しかしながら、本発明者の同時係属出願（通し番号０８／８１１
０７１）に記載したように、初めの場所から最終位置への呼び出しは、多くの呼
び出しレッグを包含し、各レッグが１つの呼び出しルーティング経路における２
つの場所を橋渡ししている１つの呼び出しルーティング経路を経て接続すること
ができる。 さらに、この同時係属出願に教示してあるように、各レッグは、接
続時間の利用度およびリクエストされたサービス・タイプの利用度に基づいて、
順方向あるいは逆方向のいずれかで完了させることができる。

【００８０】 本出願を本発明者の同時係属出願０８／８１１０７１と一緒に考慮したとき、
当業者であれば、各々が順方向、逆方向の両方で多くの呼び出しレッグを含む所
望の呼び出しルーティングに本発明の教示をどのように適用できるかは理解でき
よう。 以下、図示の呼び出しルーティング例を図１Ａに関連して説明する。図
１Ａを参照して、ここでは、呼び出す中の電話２から被呼び出し電話４までの呼
び出しの発信地が米国であり、発信料金スイッチ１４および発信国際ゲートウェ
イ・スイッチ２２がＡＴ＆Ｔ（ＴＭ）によって所有され、維持されていると仮定
する。さらに、呼び出しの最終地がドイツ国であり、終端料金スイッチ１８およ
び終端国際ゲートウェイ・スイッチ２４が独占業者であるドイツ電話会社によっ
て所有され、維持されていると仮定する。さらにまた、国際ゲートウェイ・スイ
ッチ２８が英国（Ｕ．Ｋ．）にあり、ブリティッュ・テレコム（ＴＭ）（ＢＴ）
によって操作されていると仮定する。 最後に、国際ゲートウェイ・スイッチ２
６がベルギー国にあり、Ｂｅｌｇａｃｏｍ（ＴＭ）（ベルギーのキャリア）によ
って操作されていると仮定する。

【００８１】 さらに、図５と関連して先に説明した購入済みの接続時間の１０，０００，０
００分がＡＴ＆Ｔの国際ゲートウェイ・スイッチ２２をドイツ電話会社の国際ゲ
ートウェイ・スイッチ２４に接続する３本のルーティング経路間で分けられると
仮定する。図１Ａを参照して、第１のルーティング経路は、ライン３２を経由し
て呼び出しをドイツ国際ゲートウェイ・スイッチ２４に直接接続する。第２のル
ーティング経路は、Ｕ．Ｋ．の国際ゲートウェイ・スイッチ２８およびライン３
４、３８を経て呼び出しを国際ゲートウェイ・スイッチ２４に接続する。 第３
のルーティング経路は、ベルギーにある国際ゲートウェイ・スイッチ２６および
ライン３０、３６を経て呼び出しを国際ゲートウェイ・スイッチ２４に接続する
。

【００８２】 以下、図７に示すプロセスのステップ（１）を図８に示すフローチャートと関連
して説明する。 図８を参照して、ステップ８０２において、呼び出し者は呼び
出し電話２から被呼び出し電話４の電話番号にダイヤルする。ダイヤルされた番
号は、代表的には、この呼び出しが国際電話呼び出しであることを示すプレフィ
ックス（たとえば、０１１）を含むことになる。ダイヤルされた番号は、さらに
、呼び出しを行っている海外の場所を表す国名コード（たとえば、ドイツの場合
４９）および地域コード（ミュンヘンの場合８９）を含む。ローカル電話網６は
、海外呼び出しを認識し、呼び出し側長距離キャリアにこれらの呼び出しを送る
ようにプログラムされている。

【００８３】 したがって、ステップ８０４において、ローカル電話網６は、ライン１６を経
由して発信側料金スイッチ１４へ、呼び出しに関する適切なＳＳ７通知情報を送
信する。こうして、管理が発信側料金スイッチ１４に渡される。 同時に、ステ
ップ８０６において、ローカル電話網６は、ローカル・ネットワーク送信ライン
を通して或る経路を創作し、呼び出し電話２と発信側料金スイッチ１４との間の
接続を確立する。 通知情報から、発信側料金スイッチ１４はこの呼び出しが海外呼び出しであるこ
とを認識し、それを発信側国際ゲートウェイ・スイッチ２２に送る。特に、ステ
ップ８０８において、発信側料金スイッチ１４は発信側国際ゲートウェイ・スイ
ッチ２２に適切なＳＳ７通知情報を送信し、それによって、管理をスイッチ２２
へ移す。同時に、ステップ８１０において、長距離ネットワークはその送信ライ
ンを通して或る経路を創作し、呼び出し側電話２と発信側国際ゲートウェイ・ス
イッチ２２と接続を確立する。 したがって、上述したように、ステップ（１）では、送信接続が呼び出し側電話
２と発信側国際ゲートウェイ・スイッチ２２との間に確立され、呼び出しの管理
が発信側国際ゲートウェイ・スイッチ２２に渡される。 ステップ（２）におい
て、システムは呼び出し側電話２から被呼び出し電話４への呼び出しルートを割
り当てる。以下、図９に示すフローチャートと関連してステップ（２）をさらに
詳しく説明する。

【００８４】 図９を参照して、ステップ９０２において、発信側国際ゲートウェイ・スイッチ
２２は、呼び出された場所がグローバル・ネットワークを通して呼び出しを発送
することができるものであるかどうかを決定する。決定ステップ９０２がそれを
失敗した場合には、国際ゲートウェイ・スイッチ２２は、ステップ９０４に示す
ように、呼び出された場所に接続するための代替手段を使用する。あるいは、決
定ステップ９０２が成功した場合には、国際ゲートウェイ・スイッチ２２は、ス
テップ９０６に示すように、管理を発信側遠距離通信ノード４４に渡し、呼び出
しを最終地へ送る。

【００８５】 ステップ９０８において、ノード４４は発信側キャリアが接続時間を購入した
ルーティング経路をメモリから検索する。図１Ｂと関連して上述したように、ノ
ード４４はいくつかのデータベース９９〜９７を備えており、これらのデータベ
ースが、呼び出しを被呼び出し場所に接続するためのネットワーク・コスト、公
共コストおよびグローバル・ネットワーク・コストに関する情報を記憶している
。したがって、決定ステップ９０９において、ノード４４はデータベース９９〜
９７から検索した種々のコストを比較し、それ自体のネットワーク接続を経由し
てあるいはグローバル・ネットワークを通して購入されたルートを経由して呼び
出しを送るべきかどうかを決定する。

【００８６】 決定ステップ９０９は、トラフィックを搬送するのにどのルートを選ぶべきかを
決定するのに非常に複雑なビジネス・ルールを適用する手順を取り入れることが
できる。たとえば、ノード４４は、そのルートのコストが呼び出しを接続するネ
ットワーク・コストの９０％より大きくない限り、グローバル・ネットワーク・
ルートを通して呼び出しを送るようにプログラムすることができる。

【００８７】 決定ステップ９０９が失敗した場合、システムは代わりのルートを通して呼び出
しを接続することを続ける。しかしながら、決定ステップ９０９が成功した場合
には、システムはステップ９１０へ進み、そこにおいて、ノード４４は、グロー
バル・ネットワークを通して購入したルーティング経路のうち最初のものを識別
し、接続時間を利用して呼び出し電話４からの呼び出しを被呼び出し電話４にこ
のルーティング経路を通して接続することができるかどうかを決定する。 この
決定は、ルーティング・リクエストをサーバー・ノード５６に伝えることによっ
てなされる。サーバー・ノード５６は、呼び出しを搬送するポートの有効性に関
して経路内の各ノードについて問い合わせる。接続時間が利用できる場合には、
サーバー・ノードはそのエフェクトについてのメッセージをノード４４に送り、
システムはステップ（３）へ進む。ここで、呼び出しは、以下に説明するように
、ルーティング経路を通して接続される。 さもなければ、ノード４４はステップ９１０に戻り、ルーティング経路の２番
目を識別し、呼び出し側電話２から被呼び出し電話４へ呼び出しを接続するのに
接続時間を利用できるかどうかを決定する。 ステップ９１０は、利用できる接続時間を有するルーティング経路が識別され
るかまたはキャリアが購入したすべてのルートが否認されるまで繰り返される（
ステップ９１２）。 ステップ９１２が失敗した場合（すなわち、利用できる接続時間を有するルー
ティング経路がまったくない場合）には、システムはステップ９１４に進み、そ
こにおいて、管理がゲートウェイ２２へ戻される。このゲートウェイは、代表的
には、通常の清算ルートまたは他のオーバフロー・ルートのような代替ルートを
経て呼び出しを送ることができる。 他のいかなるルートも利用できない場合には、呼び出し側電話２が送られ、す
べての回路がビジーであることをメッセージが呼び出し者に知らせると共に、呼
び出し者にその呼び出しを後で再び行うかどうかを尋ねる。

【００８８】 ひとたび利用できる接続時間を有するルートが識別されたならば、システムは
図７のステップ（３）へ進む。そこにおいて、識別されたルートが確立され、呼
び出し者が被呼び出し当事者に接続される。 以下、図７のステップ（３）を図
１０と関連して詳しく説明する。 発明の背景において先に説明したように、新しい呼び出しルーティングを確立す
るのに要求される冗長な契約交渉および物理的な再構築のために、国際ゲートウ
ェイ・ネットワークを経て呼び出しをコスト効率よくかつ動的に送るのに日時を
付けることが不可能だったのである。再構築なしでは、国際ゲートウェイ・スイ
ッチは、入来トランジット・トラフィックから入来終端トラフィックを区別した
り、人間の干渉なしに大急ぎで送り直したりすることができなかったのである。
その結果、すべての入来トラフィックが、終端トラフィックとして、高い清算合
意アカウンティング・レートまで処理されるか、あるいは、容易に修正すること
ができない現存の予め協議された契約に基づくことになっていたのである。さら
に詳細に以下に説明するように、本発明は従来技術のこの欠点を克服するもので
あり、トランジット・トラフィックおよび終端トラフィックのダイナミック・ル
ーティングをゲートウェイあるいは任意他のネットワークのゲートウェイ・スイ
ッチに行えるようにしている。

【００８９】 この例のために、ここで、図７のステップ（２）においてなされるルーティング
決定が、呼び出し側電話２から被呼び出し電話４への呼び出しをＵ．Ｋ．の国際
ゲートウェイ・スイッチ２８を経由して送らなければならないこととなっている
と仮定する。 次いで、システムは図１０に示すフローチャートのステップ１００２へ進む。こ
のステップ１００２において、ＡＴ＆Ｔの国際ゲートウェイ・スイッチ２２はト
ランザクション経路を確立し、ルーティング、シグナリング、接続すべき適切な
ポートおよび使用すべき宛先番号に関する、ノード４４からの指示に基づいて、
呼び出しを国際ゲートウェイ・スイッチ２８に送る。 同時に、ステップ１００
４において、ノード４４はライン３４を通してＳＳ７（またはＣ７または他の適
当なプロトコル）メッセージを国際ゲートウェイ・スイッチ２８に送信する。

【００９０】 Ｃ７メッセージは、呼び出しがＵ．Ｋ．で終端ではないこと（すなわち、呼び
出しがトランジットであること）国際ゲートウェイ・スイッチ２８に知らせ、ス
イッチ２８にこの呼び出しの管理を遠距離通信ノード４８に渡すように命令する
るコードを含んでいる。 呼び出しがトランジット呼び出しであることを国際ゲートウェイ・スイッチ２８
に知らせるのに用いられるこの特別なＣ７コードは、ゲートウェイ・スイッチが
Ｃ７コードをトランジット呼び出しを示すものとして認識するように構成されて
いる限り、重要ではない。しかしながら、現在、このタスクを達成するための少
なくとも２つの潜在的なコードが考えられている。まず、システムは、Ｃ７メッ
セージの一部として伝えられるダイヤル番号へのプレフィックスとしてＵ．Ｋ．
に存在しない架空の地域コードを使用することができる。また、この目的のため
に特別な国名コードを使用することができる。国際ゲートウェイ・スイッチ２８
が架空の地域コードを見たとき、それは直ちに呼び出しをトランジット呼び出し
と認め、ノード４８に管理を渡す。あるいは、新しいクラスのサービス・コード
を定義して、それをＣ７メッセージの一部として送信してもよい。Ｕ．Ｋ．ゲー
トウェイ・スイッチは、このサービス・コードを認識し、呼び出しをトランジッ
ト呼び出しと確認する。また、いくつかの遠距離通信ノードは地点コードを獲得
し、したがって、上記コードのうちの１つを使用することなく、ゲートウェイに
トラフィックをノードに送らせることができる。いずれにしても、システムはス
テップ１００６へ進み、そこにおいて、国際ゲートウェイ・スイッチ２８がノー
ド４８に呼び出しの管理を渡す。ステップ１００８において、ノード４８はドイ
ツの被呼び出し電話４の電話番号への呼び出しを国際ゲートウェイ・スイッチ２
８経由によって開始する。ノード４８は、この呼び出しがＳＳ７ネットワークを
通してあるいはライン６２を経由してドイツに送られるべきであることを知らさ
れるとよい。

【００９１】 ステップ１０１０において、国際ゲートウェイ・スイッチ２８はドイツの国際ゲ
ートウェイ・スイッチ２４に呼び出しを搬送する送信経路を確立する。同時に、
ステップ１０１２において、国際ゲートウェイ・スイッチ２８は、国際ゲートウ
ェイ・スイッチ２４にドイツで終了するための入来呼び出しを知らせるＣ７通知
メッセージを送信する。ステップ１０１４において、国際ゲートウェイ・スイッ
チ２４は、終端料金スイッチ１８およびローカル・ネットワーク１０を通して呼
び出しを被呼び出し電話４に送り、呼び出し当事者と被呼び出し当事者との接続
を確立する。

【００９２】 呼び出しが終了したとき、ルーティング経路内のすべての参加ノードがサーバー
・ノード５６にデータ・メッセージを送信し、呼び出しの長さを含む呼び出しの
詳細を知らせる。サーバー・ノード５６はこの情報を使用して、このルーティン
グ経路に参加したあらゆるキャリアのためのアカウント収支をアップデートする
。 本発明者の同時係属出願０８／８１１０７１に記載したように、システムの
速度は、ルーティング経路の２つ以上の呼び出しレッグの同時確立を同期化する
ことによって高めることができる。したがって、上記の図示実施例においては、
ステップのいくつかは、Ｕ．Ｓ．からＵ．Ｋ．まで、そして、Ｕ．Ｋ．からドイ
ツまでの送信経路を確立することのように並列で実施され、システムの速度を高
めている。たとえば、呼び出しを送るリクエストまたは指示を受けた際、Ｕ．Ｋ
．ノードは、トランクがドイツへ呼び出しを送るのに利用できるかどうか、また
、被呼び出し電話４のような宛先を利用できるかどうかを確かめることができる
。

【００９３】 上記のゲートウェイ・スイッチがIＮコンパチブルであるとき、サーバー・ノー ド５６がこの事実を知って、ノード４４に知らせる点に留意する必要がある。次
いで、ノード４４は、ＳＳ７またはＣ７よりもむしろIＮ通知を使用してＵ．Ｋ ．ゲートウェイと直接対話することができる。この場合、ノード４４はＵ．Ｋ．
ノード４８と対話する必要はない。さらに、ノード４４は、たとえば、被呼び出
し電話４がオフフックであるかどうか決定するために直接ゲートウェイ２４と連
絡するためにIＮ通知を使用することができる。 より一般的には、本開示を本発明者の同時係属出願通し番号０８／７２８６７０
（これの全体を参考資料としてここに援用する）と組み合わせて考えたとき、本
発明が外部の通信ネットワークにデータ通知を与えて呼び出しの効果的なルーテ
ィングを容易にするのにデータ・ラインを使用することは認識されよう。明らか
なように、外部データ通知を必要とする程度は、本発明のオーバレイ・ネットワ
ークを作動させるのに必要なデータ・メッセージを搬送するネットワーク通知能
力に依存する。 上記の第１図示実施例においては、リクエスティング・キャリ
アは、１ブロックの接続時間を購入した。あるいは、接続時間の購入は呼び出し
毎基準にあってもよい。以下、このようなトランザクションを例示している第２
の例を図１１Ａ〜Ｂと関連して説明する。

【００９４】 図１１Ａ〜Ｂに示すように、システムは呼び出し毎接続トランザクションをクリ
アするのに１４ステップ・プロトコルを使用する。ステップ１１０１において、
呼び出しがゲートウェイ２２で受信されたとき、このゲートウェイはノード４４
に呼び出し管理を渡す。ステップ１１０２において、ノード４４はサービス・リ
クエストを少なくとも１つのサーバー・ノード５６に伝える。この図示実施例の
目的のために、ここで、ノード４４がリクエストを１台のサーバー・ノード５６
のみに伝えるものと仮定する。しかしながら、以下により詳細に説明するように
、ノード４４は複数のサーバー・ノード５６にサービス・リクエストを伝えても
よく、各ノードが、異なったパラメータ（たとえば、価格またはネットワーク使
用）について最適化されてもよい。 ステップ１１０３において、サーバー・ノード５６は、このリクエストを処理し
、そして、サーバー・ノード５６の最適化優先権を与えられるリクエスティング
・ノードの要求に最も適うルーティング経路を識別する。たとえば、ここでサー
バー・ノード５６が価格によってルートを最適化するようにプログラムされてい
ると仮定すると、サーバー・ノード５６は、がそうするそのサーバーを仮定する
ことは、ノード４４のサービス・パラメータ要件に適った最も安価なルーティン
グ経路を識別することになろう。 ステップ１１０４において、サーバー・ノー
ド５６は、識別されたルートの詳細を含むサービス・オファーをノード４４に送
信する。 決定ステップ１１０５において、ノード４４はこのオファーを、呼び
出し側電話２から被呼び出し電話４へ呼び出しを接続するのに使用されるかもし
れない他の潜在的なルートと比較する。この決定は、リクエスティング・キャリ
アによってノード４４に供給されるかなり複雑なビジネス・ルールに基づいたも
のであってもよい。たとえば、図１Ｂと関連して先に説明したように、ノード４
４はネットワーク・コスト・データベースを備えており、これはゲートウェイ２
２からの呼び出しを被呼び出し場所に接続するキャリア内部コストを記憶する。
ノード４４は、ネットワーク自体の呼び出しを完了させることについての内部コ
ストよりも１０％未満高価である場合にのみ、サーバー・ノード５６からオファ
ーを受け付けるようにプログラムすることができる。 決定ステップ１１０５が失敗した場合には、ノード４４は拒否メッセージをサー
バー・ノード５６に送る。これがプロトコルを終了させる。 さもなければ、決
定ステップ１１０５が成功した場合には、システムはステップ１１０６へ進み、
そこにおいて、ノード４４が受理をサーバー・ノード５６に伝える。

【００９５】 ステップ１１０７において、サーバー・ノード５６は、データ・メッセージをル
ーティング経路のあらゆるノードに送り、呼び出しを接続するサービスを要求す
る。ステップ１１０８において、経路内のノードは、サービスを提供することに
同意し、サーバー・ノード５６にそのエフェクトについてのデータ・メッセージ
を送信する。 ステップ１１０９において、サーバー・ノード５６は、ルーティング経路の確立
から生じた財政的なトランザクションを仲介する。ステップ１１０９の一部とし
て、サーバー・ノード５６はリクエスティング・キャリアの信用限度の一部を予
約して呼び出しコストをカバーする。予約されたドル量は、呼び出しがどれくら
い続いたかの評価に基づいて選ばれる。この評価は、呼び出し長さの履歴に基づ
いたものであってもよい。

【００９６】 ステップ１１１０において、サーバー・ノード５６は確認メッセージをノード４
４に送り、識別されたルーティング経路についての接続時間の購入を確かめる。
メッセージは、また、好ましくは、呼び出しを送る経由とすべきゲートウェイ２
２上のポートにかかわる情報ならびに呼び出しを被呼び出し場所に完全に送るの
に必要な目的地番号および他のサービス・データを含む。 ステップ１１１１に
おいて、呼び出しの終結で、ルーティング経路の各ノードは、好ましくは呼び出
しの長さを含むとよいトランザクション終了メッセージをサーバー・ノード５６
に送る。 ステップ１１１２において、サーバー・ノード５６は、ルーティング
に参加しているすべてのキャリアおよびノード・オペレータのアカウント収支を
調整して呼び出しのコストに反映させる。ステップ１１１３において、サーバー
・ノード５６は、正の収支を持つ当事者に支払書を、負の収支を持つ当事者に請
求書を送ることによってすべてのキャリアおよびノード・オペレータのアカウン
トを精算する。ステップ１１１３は、周期的に（たとえば毎月）、実行すること
ができる。 ステップ１１１４において、サーバー・ノード５６はキャパシティ
をアップデートして呼び出しを搬送するのに使用されたポートが今やクリアであ
り、呼び出しを搬送するのに使用されたネットワーク時の分数を記録することを
反映する。

【００９７】 ノードは、また、依頼キャリアによってそのローカル・ノードに提出されたかな
り複雑なビジネス・ルールに基づいてルーティング決定を行うこともできる。 たとえば、ここで、オーバフロー・トラフィックのための接続時間を必要としな
い限り、コストがそれ自体のコストよりも２０％下である場合に、キャリアがグ
ローバル・ネットワークを通して接続時間を購入することのみを望んでいると仮
定する。このビジネス基準は、そのローカル・ノードに送られ得、このノードが
送信されてきたビジネス基準に従ってサーバー・ノード５６によって提案された
ルートを評価することになる。しかしながら、一般に、サーバー・ノード５６は
、たとえば以下に説明するように、ノード５６が価格よりもむしろキャパシティ
を最適化する閉ネットワークにいない限り、システムがこれら所有者ビジネス基
準にアクセスすることはない。先に延べたように、上記の実施例では、発信ノー
ド４４はサーバー・ノード５６と連絡したものとして示してあり、このノードが
単一のルート情報源および単一の通信キャパシティ交換を構成していた。しかし
ながら、他の実施例においては、いくつかのサーバーを使用し、これらのサーバ
ーが上記と同じあるいは同様の方法でノード４４と連絡してもよい。このような
他の実施例においては、各ノード４４〜４９は、１つまたは複数のサーバーに接
続されるであろう。多サーバー実施例において、各サーバー・ノード５６は、特
定のパラメータあるいは特定セットのパラメータに従って潜在的なルーティング
経路をランク付けすることができる。たとえば、いくつかのサーバーは、価格に
よってルートをランク付けすることができる。他のサーバーは、ネットワーク使
用度を最大にするように設計した要領でルートをランク付けすることができる。
所与の会社は、１台のサーバーまたは複数のサーバーについてのその通信キャパ
シティをオファーすることができる。各サーバーが異なった優先度に従ってルー
トをランク付けすることができるので、発信側ノードからの特定のサービス問い
合わせがサーバー・ノード５６の各々からの異なった提案ルートを生じることに
なるかも知れない。 したがって、複数のサーバー・ノード５６に接続した発信
側ノード（たとえば、ノード４４）は、異なったサーバー・ノード５６によって
提案され得るいくつかのルートの中からどのルートを選択すべきかについて決定
するための選択ルールを記憶しなければならない。

【００９８】 サーバーを選ぶ際の決定は、或るキャリアに特定の種々のビジネス・ファクタ
および状況に依存することができる。たとえば、いくつかのキャリアは、まず、
より低いトランザクション割増金を持っているサーバーでビジネスを処理するこ
とができるが、他のキャリアは売りに出されている高いボリュームの接続時間の
利用度について知られているサーバーを好むかも知れない。 当業者であれば理
解できるように、特定の選択はキャリアの特定のビジネス必要性に基づいてプロ
グラムすることができる。たとえば、或る種のキャリアは、１台の特定のサーバ
ーだけで利用可能である通信キャパシティを提供する会社との提携あるいは特別
なボリューム割引を有するかも知れない。このような場合、キャリアは、まず、
他のサーバーでキャパシティを購入する前に提携会社の接続をオファーする特定
のサーバーから通信キャパシティを購入しようと試みるかも知れない。別の例に
おいては、キャリアは、提携している或るサーバーによってオファーされた価格
が提携していない第２のサーバー・ノード５６から入手できる価格よりもたとえ
ば１０％大きい限り、この提携したサーバーから接続時間を購入することを好む
かも知れない。ノード４４は、キャリアによって供給されるこれらのビジネス・
ルールを実行するようにプログラムされる。 本発明は、また、ノード４４〜４
９を所有する、あるいは、これらのノードと関連するキャリアが１セットのビジ
ネス・ルールに従ってキャパシティを動的に制御できるようにする。本発明のこ
の局面に関して、もし或るノードが所与の宛先について先に購入した接続キャパ
シティの限度を超えるかあるいはそれに近いボリュームの呼び出しを受けたなら
ば、このノードは、この不測の要求を満たすために付加的な接続時間分を購入す
るリクエストを持ってサーバーとコンタクトすることができる。付加的なキャパ
シティは、呼び出しボリュームが或る特定の閾値に達したときに自動的にリクエ
ストされるか、あるいは、通信トラフィック状態をモニタしているシステム・オ
ペレータによってリクエストされ得る。 さらに、ノードは、実際の予期された
通信トラフィック状況に基づいてそのリソースを調整する能力を包含し得る。所
与の宛先に対する呼び出しトラフィック・ボリュームのトラックを保持し、リソ
ース利用データベースにおいて周期的に呼び出しボリュームの測定値を記憶する
ことは知られている。他の変数（たとえば、日時および曜日）と関連したネット
ワーク用途を表しているこのようなデータは、次の時間間隔（たとえば、次の時
間）中におけるキャパシティ利用度の合理的な予測を行うための基準となり得る
。 次に、予期された利用度使用が所望の利用レベルを上回る場合には、ノード
は、次の時間間隔についての付加的なキャパシティ（たとえば、宛先に対する接
続時間）を購入することになる。逆に、予測された利用度が所望レベルより低い
場合には、ノードは、次の販売時間中に過剰な分をオファーすることになる。

【００９９】 たとえば、所望の利用度が購入キャパシティの８０％である場合には、ノードは
、キャパシティを購入あるいは売り出して予期された利用度を８０％まで調節す
ることになる。 図１２はこの機能のフローチャートを示している。１２０１で、システムは、利
用データベースを参照することによって最新の利用度を確認し、１２０２で、最
新の利用度および他のファクタ、たとえば、日時、曜日に基づいて、次の期間、
たとえば、１時間にわたる予想利用度を予測する。１２０３で、或る期間にわた
る予期された利用度がおよそ所望の使用度と同じものである場合には、この実行
は次の期間まで停止する。（もちろん、先に説明したように、ボリュームが不意
に上昇した場合には、ノードはこのような状況に反応し、自動的にあるいはオペ
レータの指示によって付加的なキャパシティを購入しなければならない。） 予
期された利用度が著しく所望の利用度（テスト１２０４）から偏倚している場合
には、ノードはそれに応じて次の期間にわたって購入あるいは販売を続ける。も
し利用度が所望の利用度を上回ることが予測されるならば、予期された利用度が
所望のレベルとなるように、１２０５で、ノードは付加的なキャパシティを購入
する。同様に、利用度が所望レベルよりも低いと予測される場合には、１２０６
で、システムは予期された利用度を所望のレベルに持って行くために過剰なキャ
パシティを売りに出す。 所望の利用度は、ビジネス基準を取り入れた数式の形
をとることができる。単純な例として、付加的な接続時間の購入が或る価格より
上にない限り、あるいは過剰接続時間の販売が或る価格よりも下にない限り、ノ
ードに８０％のキャパシティで利用度を維持するように指示することができる。
ノードによって適用されるビジネス・ルールは、実質的に、上記の例よりも複雑
にしてもよいし、キャリアの望む任意のファクタを考慮してもよい。 好ましい
実施例において、システムは未来の接続時間の売り手あるいは買い手についての
市場価格情報を表示することができる。以下に説明するように、市場価格情報の
表示は、好ましくは、顧客側のクライアントＰＣ上で稼働しているＪａｖａアプ
レットによって生成されたストリーミング・バナーの形であってもよい。他の実
施例において、表示されるべき情報は、他の形式であってもよいし、この技術分
野では知られているような別のディスプレイ装置上に表示されてもよい。

【０１００】 図１３に示すように、この好ましい実施例においては、図１Ａに示すシステム・
アーキテクチャは、好ましくは、さらに、市場価格モニタ用サブシステム１３０
０を備えている。市場価格モニタ用サブシステム１３００の構造および動作を図
１４〜１８と関連して説明する。 図１４に示すように、好ましくは、市場価格
モニタ用サブシステム１３００は、通信リンク１３２０を通してサーバー・ノー
ド５６に接続したプロセッサ１３１０を包含する。それに加えて、市場価格モニ
タ用サブシステム１３００は、市場価格データベース１３３０および顧客データ
ベース１３４０を包含する。以下により詳しく説明するように、市場価格データ
ベース１３３０は、サーバー・ノード５６によって管理される通信ルートの市場
価格に関する情報を記憶する。顧客データベース１３４０は、市場価格情報の表
示を各顧客についてカスタマイズし得るように特定の顧客にとって重要であるル
ートのリストを保持する。サブシステム１３００は、通信リンク１３６０を介し
てウェブサーバ１３５０に接続している。ウェブサーバ１３５０は、通信リンク
１３２５によってサーバー・ノード５６に接続している。通信リンク１３２０、
１３２５、１３６０は、インターネットを経由して実現され得る。

【０１０１】 市場価格データベース１３３０の一部の好ましい実施例が図１５に示してある。
図１５に示すように、市場価格データベース１３３０は、好ましくは、サービス
がサーバー・ノード５６によって提供される各通信ルートのためのエントリ１５
１０を包含する。好ましい実施例において、或るルートを、それが接続する地理
学的場所、それが保証する品質およびサービスの定義済みレベルおよび接続時間
を利用し得る日時によって定義することができる。あるいは、ルートは付加的、
もっと少ないあるいは他のグループのパラメータによって定義してもよい。実例
として、テーブルは接続時間を利用できる曜日および接続時間を利用できる期間
（たとえば、１９９８年９月１日から１１月３０日）についてのフィールドを含
むことができる。それに加えて、テーブルは、購入に使える定義済みのルートに
ついて接続時間量を記憶している付加的なフィールドを包含し得る。したがって
、たとえば図１５に示すように、市場価格データベース１３３０は、米国、ドイ
ツを接続する。たとえば、しているはっきりしたルートのための１５１０および
グリニッチ標準時の午後１時から午後７時までの「Ａ」品質および「Ａ」セキュ
リティ・レベルをオファーする第１ルートならびにグリニッジ標準時の午後７時
から午前１時までの「Ａ」品質および「Ａ」セキュリティ・レベルをオファーす
る第２ルートを含む、別個のルートについて個別のエントリ１５１０を包含し得
る。このようなエントリの各々について、市場価格データベース１３３０は特有
の識別子１５２０と、ルートに対する市場価格を構成するようにプロセッサ１３
１０によって計算した市場価格１５３０とを記憶する。以下に説明するように、
プロセッサ１３１０はいくつかの技術のうちの１つを用いて市場価格を決定する
ことができる。 顧客データベース１３４０の一部の好ましい実施例が図１６に
示してある。図１６に示すように、顧客データベース１３４０は、サーバー・ノ
ード５６を経由して通信時間を購入あるいは販売するシステムの種々の顧客につ
いてエントリ１６１０を包含する。１つのエントリを有する各顧客について、顧
客データベース１３４０は、顧客にとって重要である可能性のある１つ以上のル
ートを記憶する。各顧客について記憶されたルートは、顧客の履歴購入パターン
によって決定され得る。あるいは、ウェブサーバ１３５０にログインしたときに
顧客にとって重要なルートを顧客が選んでもよい。したがって、たとえば、顧客
である「オーストリア・テレコミュニケーション」が、特に、フランス、オース
トリア間およびドイツ、オーストリア間の音声品質、高セキュリティ・ルーティ
ングに興味を持つかも知れない。その場合、顧客データベース１３４０は、それ
のオーストリア・テレコミュニケーション・エントリの一部としてこれらの重要
なルートを表す識別子６４３５および６９０８を記憶することになる。

【０１０２】 それに加えて、データベース１３４０は、好ましくは、顧客あるいはその中のエ
ントリを持たないシステムの潜在的な顧客に表示されるべきルートを表すルート
識別子を記憶するための１つ以上のデフォルト・エントリ１６２０を包含する。
好ましい実施例においては、各デフォルト・エントリを或る特定の場所と関連付
けし、以下に説明するように、顧客データベース１３４０のエントリを持たない
顧客に表示されるデフォルト・ルートを顧客の場所に基づいて選ぶことができる
ようにしている。別の好ましい実施例においては、デフォルト・ディスプレイは
、顧客にとって重要である取引活動における傾向、たとえば、価格または大きい
出来高あるいはこれら両方において重大な急変を経験しているルートに（顧客の
オプションとして）集中するようにしてもよい。

【０１０３】 作動中に、プロセッサ１３１０はサーバー・ノード５６によって仲介されるすべ
てのトランザクションをモニタする。そして、これらのモニタしたトランザクシ
ョンを基礎として、市場価格データベース１３３０に記憶された各定義済みのル
ートについての市場価格を決定する。先に説明したように、プロセッサ１３１０
は市場価格を決定するのに種々のほうほうのうちの１つを使用することができる
。好ましい実施例においては、或るルートについての市場価格は、そのルートを
定義するパラメータ（たとえば、地理的なルート、品質、セキュリティなど）を
含む最新のトランザクションについて支払った価格として決定され得る。プロセ
ッサ１３１０がサーバー・ノード５６によって仲介されるトランザクションを検
知するたびに、それは市場価格データベース１３３０内のルートについて記憶さ
れた市場価格をアップデートする。あるいは、或るルートについての市場価格は
、経過時間その他の期間にわたってサーバー・ノード５６によって仲介されたル
ートについての平均トランザクション価格として計算することができる。 顧客
または潜在的な顧客がウェブサーバ１３５０にログオンしたとき、ウェブサーバ
１３５０および市場価格モニタ用サブシステム１３００が協働して、図１７〜１
８と関連して以下に説明するように、サーバー・ノード５６によって保持されて
いるルートの選択にかかわっている最新市場情報を顧客に表示してもよい。 図
１７に示すように、ステップ１７０５において、顧客がウェブサーバ１３５０に
ログオンしたとき、ウェブサーバは、好ましくは顧客のIＤまたは顧客の場所あ るいはこれら両方を含むデータ・メッセージをプロセッサ１３１０に送る。ステ
ップ１７１０において、プロセッサ１３１０は顧客データベース１３４０を検索
して顧客がデータベース内にエントリを有するかどうか決定する。顧客がエント
リを有する場合には、プロセッサ１３１０は、メモリから、顧客にとって重要で
あるルートについてルート識別子を検索する（ステップ１７１５）。あるいは、
プロセッサ１３１０は、メモリから、先に説明したように、たとえば、顧客の場
所と関連したデフォルト・エントリあるいは顧客の関心が特に取引傾向にあるか
に基づき得る他のデフォルト・エントリからルート識別子を検索する（ステップ
１７２０）。あるいは、顧客にとって興味のあるルートに係わる情報を、顧客の
クライアントＰＣのブラウザ内にウェブサーバによって置かれたクッキーに記憶
させてもよい。

【０１０４】 ステップ１７２５において、プロセッサ１３１０は、市場価格データベース１３
３０から、識別されたルートについての市場価格およびルート・パラメータ（た
とえば、地理的なルート、品質レベル、セキュリティ・レベルおよび日時）を検
索し、ステップ１７３０において、通信リンク１３６０を経てこの情報をウェブ
サーバ１３５０に送信する。ステップ１７３５において、ウェブサーバ１３５０
は、クライアントＰＣ上に、顧客にとって関心のあるルートに係わる受信情報を
表示させる。あるいは、ルートを定義しているサブセットのパラメータに関する
受信情報の一部を表示してもよい。表示されるべきパラメータのサブセットは、
顧客によって定義されてもよい。

【０１０５】 好ましい実施例において、市場価格情報は、たとえば、クライアントＰＣ上でま
たは直接ウェブサーバ１３５０上で動作しているＪａｖａアプレットその他のソ
フトウェアによって生成されたストリーミング・バナーの形で顧客に表示される
。このようなストリーミング・バナーからなるウェブ・ページの例が図１８に示
してある。所望に応じて、ストリーミング・バナーは、顧客に対して同時に表示
される情報量を増やすために少なくとも２本のライン分の高さを有し得る。 好ましい実施例においては、ステップ１７４０に示すように、顧客がオンライン
にいる間に表示されたルートの価格が変わった場合には、プロセッサ１３１０は
アップデートされた市場価格情報をウェブサーバ１３５０に送り、このウェブサ
ーバは、ストリーミング・バナー内で適切なエントリをアップデートするように
クライアントＰＣ上にあるＪａｖａアプレットと連絡している。 好ましい実施
例において、顧客が表示された情報をクリックすることによって表示されたルー
トのうちの１つで接続時間を便利に購入することができる。その場合、システム
は、直接的に、テンプレートまたは他のグラフィック・インタフェースで顧客を
促し、購入あるいは販売しようとしている時間量、提示価格などをユーザに入力
させる。次に、システムは、上記の通りに、トランザクションを仲介して所望の
接続時間を購入あるいは販売する試みを続ける。

【０１０６】 本発明を特定の実施例と関連して説明してきたが、前述の説明を考慮すれば当業
者にとっては多数の代替、修正、変更が明らかであろう。 たとえば、主として
国際電話呼び出しと関連して説明してきたが、本発明は、また、１つの国の中に
設置したネットワークの効率を向上させるのにも適用可能である。 また、主と
して複数のキャリアからなる公共ネットワークと関連して説明してきたが、本発
明は、また、個人的なネットワークあるいは提携したキャリアによって維持され
る設備からなるネットワークを効率よく管理するのにも使用することができる。
これに関連して、サーバー・ノード５６は、単純な価格以外のパラメータに従っ
てルーティング経路をランク付けるようにプログラムされることが多い。たとえ
ば、ネットワークは、ネットワーク設備の利用度を最大にするように設計した方
法でルートをランク付けし、割り当てることができる。

【図面の簡単な説明】

【図１Ａ】 本発明の世界的ネットワークを実施するために適当な電話システムアーキテク
チャのブロック図である。

【図１Ｂ】 遠隔通信ノード及び関連データベースのブロック図である。

【図２】 費用効率的な経路を決定するために遂行されるステップを示す流れ図である。

【図３Ａ】 レート情報を入力するためのテンプレートの概要図である。

【図３Ｂ】 サービス要求を配置するためのテンプレートの概要図である。

【図４】 レートテーブルデータベースの概要図である。

【図５】 電話接続時間を仲介販売するために遂行されるステップを示す流れ図である。

【図６】 Ａ乃至Ｃは、電話接続時間取引のいろいろな点におけるレートテーブルデータ
ベース４００の状態例の概要図である。

【図７】 本発明の世界的ネットワークの呼出し経路指定動作を示す流れ図である。

【図８】 図７に示す呼出し経路指定動作の第１の部分を詳細に示す流れ図である。

【図９】 図７に示す呼出し経路指定動作の第２の部分を詳細に示す流れ図である。

【図１０】 図７に示す呼出し経路指定動作の第３の部分を詳細に示す流れ図である。

【図１１】 Ａ及びＢは、取引の度毎に接続時間を購入するためのプロトコルの流れ図であ
る。

【図１２】 利用可能な通信容量の遠隔通信ノードによる動的制御を示す流れ図である。

【図１３】 市場価格監視サブシステムを含む電話システムアーキテクチャのブロック図で
ある。

【図１４】 市場価格監視システムの好ましい実施の形態のブロック図である。

【図１５】 市場価格データベースの好ましい実施の形態の概要図である。

【図１６】 顧客データベースの好ましい実施の形態の概要図である。

【図１７】 Ａ及びＢは、市場価格監視サブシステムの動作面を示す流れ図である。

【図１８】 市場価格情報を顧客に対して表示するために適当なウェブページの例である。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０９／１２９，４１３ (32)優先日 平成10年８月５日(1998．8．5) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＨＲ ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ， ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，Ｌ Ｖ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ， ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，Ｕ Ｚ，ＶＮ，ＹＵ，ＺＷ 【要約の続き】

Claims (24)

【特許請求の範囲】
1. 【請求項１】 電話接続取引の世界的クリアリングを遂行する方法であっ
   て、 呼出しをネットワーク内の位置対の間で経路指定するコストに関するレート情
   報を１つまたはそれ以上のプロバイダのキャリヤから収集するステップを含み、 各キャリヤはメモリ内に格納されている勘定を有し、各勘定は収支を有してお
   り、 上記収集された情報を使用して、呼出しを第１の位置から第２の位置まで経路
   指定するための１つまたはそれ以上のルートを識別するステップを更に含み、 各識別されたルートは１つまたはそれ以上の呼出し脚からなり、各呼出し脚毎
   のサービスは上記プロバイダのキャリヤの１つによって提供され、 要求者のキャリヤからサービス要求を受信するステップを更に含み、 上記サービス要求は、上記第１の位置から第２の位置まで１つまたはそれ以上
   の呼出しの経路を要求し、各要求者のキャリヤはメモリ内に格納されている勘定
   を有し、各勘定は収支を有しており、 上記識別されたルートの１つまたはそれ以上に、上記１つまたはそれ以上の呼
   出しのための接続時間を割当てるステップと、 上記１つまたはそれ以上の呼出しを、上記割当てられた接続時間にわたって上
   記識別されたルートに接続するステップと、 上記１つまたはそれ以上の呼出しの第１の呼出しの終了を表す信号を受信する
   ステップと、 上記１つまたはそれ以上の呼出しの第１の呼出しを接続するために使用された
   上記識別されたルート内の上記呼出し脚の１つまたはそれ以上を提供する各プロ
   バイダのキャリヤの勘定収支を更新するステップと、 を更に含んでいることを特徴とする方法。
2. 【請求項２】 上記収集されたレート情報に関連するサービスパラメータ
   情報を収集するステップと、 上記識別されたルートを、上記サービスパラメータ情報に従って分類するステ
   ップと、 を更に含んでいることを特徴とする請求項１に記載の方法。
3. 【請求項３】 上記割当てステップは、上記識別されたルートの１つまた
   はそれ以上に対して、上記要求者・キャリヤの上記サービスパラメータ要求に従
   って上記１つまたはそれ以上の呼出しのための接続時間を割当てるステップを含
   んでいることを特徴とする請求項２に記載の方法。
4. 【請求項４】 世界的電話取引クリアリングシステムであって、 複数の電話スイッチからなる電話スイッチングネットワークと、 上記電話スイッチの関連する１つにそれぞれ組合わされている複数の遠隔通信
   ノードと、 上記各ノードに接続されているサーバノードと、 を備え、 上記サーバノードは、 上記電話スイッチングネットワーク内の電話スイッチ対を接続するルートに関
   するレート情報を格納しているデータベースと、 上記ノードの１つからの経路指定要求に応答して呼出し経路指定を許可する許
   可モジュールと、 を含んでいることを特徴とするシステム。
5. 【請求項５】 上記サーバノードは、レート情報を入力するためのテンプ
   レートを表すデータ構造を更に含んでいることを特徴とする請求項４に記載の装
   置。
6. 【請求項６】 上記ノードは、サービス要求を入力するためのテンプレー
   トを表すデータ構造を更に含んでいることを特徴とする請求項４に記載の装置。
7. 【請求項７】 １つの呼出しを起呼電話機ユーザ設備から被呼電話機ユー
   ザ設備まで経路指定する方法であって、 上記起呼電話機ユーザ設備から第１の電話スイッチまで上記呼出しのための第
   １の伝送通路を確立するステップと、 上記第２の電話スイッチによってサービスされている位置においては上記呼出
   しを終端させないことを指示する信号メッセージを、上記第１の電話スイッチか
   ら第２の電話スイッチまで信号回線を介して伝送するステップと、 上記第１の電話スイッチから第３の電話スイッチまで上記呼出しのための第２
   の伝送通路を確立するステップと、 上記第２の電話スイッチから上記第３の電話スイッチまで上記呼出しのための
   第３の伝送通路を確立するステップと、 上記第３の電話スイッチから上記被呼電話機ユーザ設備まで上記呼出しのため
   の第４の伝送通路を確立するステップと、 上記第１、第２、第３、及び第４の伝送通路を介して、上記起呼電話機ユーザ
   設備から上記被呼電話機ユーザ設備まで呼出しを接続するステップと、 を含んでいることを特徴とする方法。
8. 【請求項８】 上記信号メッセージは、仮想の領域コードからなっている
   ことを特徴とする請求項７に記載の方法。
9. 【請求項９】 上記信号メッセージは、上記呼出しが上記第２の電話スイ
   ッチによってサービスされている位置において終端されるものではないことを上
   記第２の電話スイッチまで輸送するように予め指定されているクラスのサービス
   コードからなってることを特徴とする請求項７に記載の方法。
10. 【請求項１０】 上記第１、第２、及び第３の電話スイッチは、国際ゲー
    トウェイスイッチであることを特徴とする請求項７に記載の方法。
11. 【請求項１１】 将来の購買者及び販売者に対して通信接続時間取引の市
    場価格を表示する方法であって、 接続時間を、１つまたはそれ以上のルート上の１つまたはそれ以上の呼出しに
    割当てるステップと、 上記１つまたはそれ以上の呼出しを、上記割当てられた接続時間にわたって識
    別されたルートに接続するステップと、 上記１つまたはそれ以上のルートの少なくとも１つのルートに関連する格納さ
    れた市場価格を、上記ルートを介して接続時間を購入するために支払った価格に
    従って更新するステップと、 上記格納された市場価格を、将来の購買者及び販売者に対して表示するステッ
    プと、 を含んでいることを特徴とする方法。
12. 【請求項１２】 上記格納された市場価格を、クライアントのＰＣ上に表
    示させるステップを更に含んでいることを特徴とする請求項１１に記載の方法。
13. 【請求項１３】 上記格納された市場価格を、ストリーミングバナーとし
    てクライアントのＰＣ上に表示させるステップを更に含んでいることを特徴とす
    る請求項１２に記載の方法。
14. 【請求項１４】 上記ストリーミングバナーは、２つまたはそれ以上の行
    の高さを有していることを特徴とする請求項１３に記載の方法。
15. 【請求項１５】 上記ストリーミングバナーは、上記表示された市場価格
    上をクリックすることによって上記少なくとも１つのルートに関するトレーディ
    ングセッションが開始されるように処理可能であることを特徴とする請求項１３
    に記載の方法。
16. 【請求項１６】 上記少なくとも１つのルートは、複数のパラメータによ
    って限定されることを特徴とする請求項１１に記載の方法。
17. 【請求項１７】 上記パラメータは、地理的なルートを含んでいることを
    特徴とする請求項１６に記載の方法。
18. 【請求項１８】 上記パラメータは、接続品質、接続の安全性、上記接続
    時間が有効であるその日の時間、及び上記接続が有効である歴期間の少なくとも
    １つを更に含んでいることを特徴とする請求項１７に記載の方法。
19. 【請求項１９】 上記市場価格は、上記少なくとも１つのルートを限定す
    るパラメータを含む最新の取引に対して支払われた価格として決定されることを
    特徴とする請求項１６に記載の方法。
20. 【請求項２０】 上記市場価格は、上記少なくとも１つのルートを限定す
    るパラメータを含む取引の所定の時間期間にわたる平均価格として決定されるこ
    とを特徴とする請求項１６に記載の方法。
21. 【請求項２１】 電話接続時間取引の市場価格を表示するシステムであっ
    て、 取引情報を受信するプロセッサと、 上記プロセッサに接続され、複数の各ルート毎の市場価格情報を格納している
    市場価格データベースと、 上記プロセッサに接続され、上記複数のルートに関する市場価格を上記プロセ
    ッサから受信するウェブサーバと、 上記ウェブサーバと共働して上記市場価格情報を表示するクライアントのＰＣ
    と、 を備えていることを特徴とするシステム。
22. 【請求項２２】 上記クライアントのＰＣは、上記市場価格情報を表示す
    るためのＪａｖａアプレットを備えていることを特徴とする請求項２１に記載の
    方法。
23. 【請求項２３】 上記クライアントのＰＣは、上記市場価格情報をストリ
    ーミングバナーの形状で表示することを特徴とする請求項２１に記載の方法。
24. 【請求項２４】 上記プロセッサに接続されている顧客データベースを更
    に備え、上記顧客データベースは少なくとも一人の顧客が関心を寄せている１つ
    またはそれ以上のルートの識別を格納していることを特徴とする請求項２１に記
    載の方法。