マルチテナント電話ネットワークのための方法およびシステム
マルチテナントの電話システムを操作させるための方法およびシステムであって：複数のユーザから受信したコールリクエストを蓄積するコールキューと；コールリクエストに対するコールセッションを確立する、拡張性と収縮性を有する電話リソースクラスターと；システムの容量要求を計算する解析システムと；電話リソースクラスターのスケーリングおよび操作を管理するリソースアロケーターと；コールセッションの電話通信チャネルとして使用される、複数の電話ネットワークチャネルと；を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
関連する出願のクロスリファレンス
この出願は、２００９年３月２日提出の「複数ユーザーのための電話ネットワークを提供する方法」との名称の米国仮出願番号６１／１５６，７５８号の利益、２００９年１０月７日提出の「マルチテナント電話ネットワークのための方法およびシステム」との名称の米国仮出願番号６１／２４９，４９３号の利益、および、２０１０年１月１９日提出の「マルチテナント電話ネットワークのための方法およびシステム」との名称の米国仮出願番号６１／２９６，２７０号の利益をクレームし、この参照により本願発明に組み込まれる。
【０００２】
この出願は、２００９年４月２日提出の「電話セッションを処理するためのシステムおよび方法」との名称の先行する出願番号１２／４１７，６３０号に関連する。
【０００３】
本発明は、一般的には電話の技術分野に関連し、特に、電話の技術分野における新規で有益なマルチテナント電話ネットワークに関するものである。
【背景技術】
【０００４】
電話ネットワークは、電話のセッションまたは接続のためのチャンネル構造を歴史的に使用している。このチャンネル構造は電話の歴史の中で創設されたもので；通話するために物理的に接続する必要がある物理的に有線の接続またはチャンネルである。チャンネルの概念は今なお現在でも使用されている。電話ネットワークの加入者は、基本的に、チャンネル毎に支払うことを通常要求される。構内交換機（ＰＢＸ）、コールセンター、または、同様の電話によるアプリケーションを利用しようとするユーザーは、通常サービスに加入し、それらの技術およびそれらの技術のみを利用可能とするチャンネルの固定された容量を有している。チャンネルの容量は契約の一部であるため、そのチャンネルの容量を超えることはできない（もし超えると通話または電話セッションが失敗する）。多くのアプリケーションでは、まれに全容量の使用状況を確認するので、ユーザーはしばしば一般的に使用されているよりも多くのチャンネルを支払う。
【０００５】
電話ネットワークのチャンネルを基本とする構造とは対照的に、ボイスオーバーインターネットプロトコル（ＶＯＩＰ）、インターネットに基づくアプリケーション、および、インターネットに基づく電話アプリケーションのような、パケットに基づくネットワークの改革が近年立ち上がってきた。電話の技術分野に訪れた新しい技術により、ハードウェアおよびソフトウェアの容量要求を取り扱うためのユニークなチャレンジがある。専用のハードウェアおよびソフトウェアは、しばしば、電話呼び出し中にタスクを実行し、あるいは、電話呼び出し者をインターネットに基づくアプリケーションに接続するための中間システムとしても動作する。電話システムは、通常、ウェブサイトに基づくアプリケーションよりもより高い性能を期待されている。ウェブサイトのユーザーは情報をロードしたり処理したりするのに時間がかかることを予想する一方、電話呼び出し者は電話中における遅延や反応しない通話にフラストレーションを示す。また、電話アプリケーションは、いまだに、拡張性に対し別のバリアを付加する、チャンネルに基づく電話システムに依存している。電話ネットワーク、および、現存する電話アプリケーションソフトウェアおよびハードウェアのアーキテクチャは、電話アプリケーション分野の増大する容量を制限する。そのため、電話の技術分野において、新規で有益なマルチテナント電話ネットワークを創設する必要がある。この発明はそのような新規で有益なシステムおよび方法を提供する。
【発明の概要】
【０００６】
本発明は、電話アプリケーションのためのマルチテナント電話ネットワークを提供するシステムおよび方法を提供する。本発明の一つの目的は、複数ユーザー環境において共用リソースの使用を取り扱うこと、および、容量の要求を満たすために動的にリソースを見積もることである。この目的の関連する効果は、各ユーザーが利用可能な明らかなリソースの数の全体がマルチテナント電話ネットワークを実行するために使用される実際のリソースの数よりも大きいことである。本発明の他の目的は、容量の要求を満たすように処理および記録のリソースを提供することにより、節電のために電源をオフとしたアプリケーションのための他の使用されていないリソースを開放することにより、あるいは、他の好適な機能により、電話プラットホームのリソースを効率的に使用することである。本発明の他の目的は、ユーザーのアプリケーションに対して透明な電話リソースのクラスターを使用することである。この透明性は、アプリケーションの操作が複数の電話サービスリソース間で配信されて異なるチャンネルに複数の電話セッションを含む状況にもかかわらず、好ましくは保存される。本発明のこれらの目的および他の目的は、マルチテナント電話ネットワークのためのシステム、マルチテナント電話ネットワークを操作する方法、動的電話ネットワークを操作する方法、および、電話ハードウェア間のコールを配信する方法を含む、本発明の好適な実施例によって達成され、それぞれは以下のセッションで記載される。
【図面の簡単な説明】
【０００７】
【図１】図１はマルチテナント電話ネットワークを操作する方法のための好適な実施例を示すフローチャートである。
【図２】図２はマルチテナント電話ネットワークのためのシステムの好適な実施例を示す線図である。
【図３】図３はマルチテナント電話ネットワークのためのシステムの好適な実施例を示す線図である。
【図４】図４はマルチテナント電話ネットワークのためのシステムの好適な実施例を示す線図である。
【図５】図５は着信転送のクラスターを使用する本発明の好適な実施例を示す線図である。
【図６】図６は動的電話ネットワークを操作する方法のための本発明の好適な実施例のフローチャートである。
【図７】図７は電話会議を実行する本発明の好適な実施例のフローチャートである。
【図８】図８は着信コールを受け取る本発明の好適な実施例のフローチャートである。
【発明を実施するための形態】
【０００８】
本発明の好適な実施例の以下の記載は、本発明をこれらの好適な実施例に限定することを意図しているものではなく、当業者がこの発明を作製して使用することを可能にすることを意図している。
【０００９】
１．マルチテナント電話ネットワークのためのシステム
図２−４に示すように、好適な実施例のシステム１００は、電話リソースクラスター１１０、呼び出しキュー１２０、解析システム１３０、リソースアロケーター１４０および複数の電話ネットワークチャンネル１５０を含む。電話リソース１１０のクラスターは、複数の割り付けられた電話ネットワークチャンネル１５２および／または複数のコールルーター、ロードバランサーのような複数の電話リソース１１２を好適には含み、さらにサービスアプリケーションを付加的に含む。システムはネットワークおよびシステムリソースの使用を配信して容量の要求に基づきシステムを動的に調整するよう機能する。
【００１０】
電話リソースクラスター１１０（または「クラスター」）は、少なくとも一つのリソースがユーザーによって要求された電話コールセッションを生成するために使用される、リソースの拡張性（拡大および／または収縮）集合として機能する。クラスター１１０は、好ましくは、処理および／または記録の要求を満たすよう動的に調整できる、ハードウェアおよび／またはソフトウェアの集合である。クラスター１１０は、好ましくは、ハードウェアの割付および使用の取り扱いがシステムによって内部で扱われる、外部装置に対するハードウェアおよび／またはソフトウェアのクラウドのように見える。図２に示されたある変形例において、電話リソースクラスター１１０は、好ましくは、コールセッションを確立すること、電話インストラクションをコール動作に変換すること、コールを収縮すること、またはコールを導くことのような、コールリクエストまたはコールセッションのための中間で処理するタスクを提供する機能を果たす、複数の電話リソース１１２である。図３に示された他の変形例において、電話リソースクラスター１１０は、好ましくは、割り付けられた電話ネットワークチャンネル１５２が、コールセッションに対し利用可能なチャンネルとして活性化されあるいは指定された割り付けられた電話ネットワークチャンネル１５２のチャンネルである、割り付けられた電話ネットワークチャンネル１５２に対する複数の接続である。
【００１１】
電話リソース１１２は、好ましくは、特定の電話処理タスクに対し供給されるソフトウェアまたはハードウェアリソースである。好ましくは、複数の電話リソース１１２が存在し、異なる専用のタスクを実行する複数のタイプの電話リソースとして存在することもできる。電話リソース１１２は、好ましくは、コンピュータ処理装置および／またはコンピュータ記憶装置を含む。電話リソース１１２は、物理的なハードウェア装置、仮想マシーン、ソフトウェアプログラム／ルーチン、および／または、電話リソース１１２の処理および記録操作を提供する如何なる好適な組合せとすることができる。ある場合には、電話リソース１１２は専用のハードウェアまたはソフトウェアを含むことができる。電話リソース１１２は処理能力またはデータストレージとして基本的な機能性をシェアしているため、電話リソース１１２のコアとなる機能性は、電話リソース１１２が異なる専用のタスクを実行するように、再供給される。リソースアロケーター１４０（およびより具体的にはロードバランサー１４２）は、好ましくは、電話リソース１１２を再供給し、リソースクラスター１１０の異なる部分として動作する。例えば、クラスターは複数のテキスト・トゥ・スピーチサービスおよび複数のコールルーターを含むが、ある時点で、達成されるテキスト・トゥ・スピーチ操作の数が減少し、電話アプリケーションの数が増加し、それによりテキスト・トゥ・スピーチサーバーは、好ましくは、コールルーチンとして再供給される。変形例において、複数の電話リソース１１２（すなわちクラスター１１０）が、好ましくは、複数のコールルーター１１４を含む。付加的にあるいは選択的に、クラスターは、メディア処理システム、転写システム、テキスト・トゥ・スピーチシステム、コールレコーダー、コールデータストレージなどの他のハードウェア装置やソフトウェアインスタンス、あるいは、適切なハードウェア（物理的装置または仮想マシーン）やソフトウェアを含む。クラスターのためのリソースアロケーター１４０は、好ましくは、タスク処理の配信および複数の電話リソース１１２の操作を取り扱うロードバランサー１４２を含む。また、クラスターは、複数のリソースを使用することの結果として発生する問題を協同して解くことができるサービスアプリケーションおよび／またはコールルーターネットワークを含むことができる。
【００１２】
複数のコールルーター１１４は、電話装置からコールを開始または受け取り、処理に関連する電話アプリケーションを提供する機能を果たす。好ましくは、コールルーターが、コールリクエストのソースであるアプリケーションサーバーに接続する。複数のコールルーター１１４は、好ましくは、容量の要求に従って調整することができるコールルーター１１４の動的な数である。上述したように、ほかの実施例において、複数のコールルーター１１４は、メディア処理システム、転写システム、テキスト・トゥ・スピーチシステムなどの他の好適な電話ハードウェアやソフトウェアリソース、または、電話アプリケーションで使用される他の特別なハードウェアやソフトウェアリソース、によって置き換えることができ、または、それらと組み合わせることができる。ある例において、複数の転写ハードウェアまたは仮想化されたリソースを、図５に示すように、電話コールを転写するためのコールルーターの位置で使用することができる。また、コールルーター１１４を、メディア処理システム、転写システム、テキスト・トゥ・スピーチシステムとして、あるいは、好適な処理のために、再供給することができ、同様に、いかなるプロセッサーもコールルーターとして機能するように再供給することができる。ハードウェアやソフトウェアのリソースの数を、付加的にあるいは選択的に、割り当てたりあるいは割り当てを解除することができ、それにより好適な組合せのリソースの望ましい数をいつでも操作することができる。ハードウェアインスタンスは、割り当てを解除する際、電源を切ること、エネルギーセービングモードに入ること、あるいは、好ましい状態に置かれることである。電話リソース１１２は、付加的にあるいは選択的に、（アマゾンによって運営されるエラスティック・コンピュート・クラウドのような外部パーティーによって運営される）クラウドコンピューティングプラットホーム上での仮想化されたリソースとして操作され得る。コールルーター１１４のような電話リソース１１２が割り当てを解除するとき、仮想化されたリソースを、クラウドコンピューティングプラットホームの他の顧客に与えたり、リソースの仮想化あるいは他の好適な処理を中止することで、ベンダーに戻すことができる。ソフトウェアインスタンスは、割り当てを解除する際、中止あるいは削除される。コールルーターのメディア処理システムに対する比のようなリソースの比は、調整されあるいは維持される。
【００１３】
コールルーター１１４は、好ましくは、電話交換網（ＰＳＴＮ）装置にＰＳＴＮネットワークを介して接続され、地上の通信線、携帯電話、衛星電話あるいは他の好適なＰＳＴＮ接続装置などのＰＳＴＮ接続装置から、あるいは、ボイスオーバーインターネットプロトコル（ＶＯＩＰ）電話、ＳＩＰ電話、スカイプ、Ｇトーク、他のインターネットでアドレス可能なボイス装置などの非ＰＳＴＮ装置から、コールを受け取りまたはコールを発生することができる。そのため、コールルーター１１２は、好適には、分散型の電話コントローラーの電話ネットワークへの接続を生成することができる。コールルーター１１２は、選択的にあるいは付加的に、ＳＭＳ（ショート・メッセージ・サービス）やＭＭＳ（マルチ・メディア・メッセージング）などの電話メッセージングとともに使用するためのメッセージルーターとして機能し、あるいは、そのようなメッセージルーターを含むことができる。コールルーター１１２は、好ましくは、メッセージングネットワークに接続され、ＳＭＳ／ＭＭＳネットワーク装置、携帯電話、コンピュータ、スマートフォン、あるいは、いかなる好適なＳＭＳ／ＭＭＳネットワーク装置から、メッセージを受け取ることができ、または、メッセージを送ることができる。コールルーター１１２は、また、テキストメッセージ、マルチメディアメッセージ、ｅメール、ファックスおよび他の好適なＰＳＴＮ互換性のあるコミュニケーションメッセージを送ったり受けたりすることができる。コールルーター１１２は、好ましくは、アプリケーションレイヤープロトコルを使用して、より好ましくは、ＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）やセキュアーＨＴＴＰＳ（ハイパーテキスト・トランスファー・プロトコル・セキュアー）プロトコルを使用して、アプリケーションサーバーとコミュニケーションすることができる。アプリケーションサーバーは、好ましくは、電話の相互作用のためのコールルーターによって使用される、電話アプリケーション、サウンドファイル、テキストファイル、データベース、および／または、好適なメディアリソースやファイルのホストとなる。コールルーター１１２は、また、コールルーターリソースを発生することができる。コールルーターリソースは、好ましくは、コールルーターＡＰＩを介してアプリケーションサーバーおよび（他のコールルーターなどの）他の装置によってアクセス可能である。コールルーターリソースは、コールルーターメタデータ、内部コールルーター状態、または、コールルーターによって使用された所定のリソース状態のアドレス可能な表現としての機能を果たす。例えば、コールルーター１１４はコールを記録し、コールルーターリソースとして記録を保存することができる。
【００１４】
また、好適な実施例としての電話リソースクラスター１１０は、各種のコールルーター１１４、ハードウェアリソース、および／または、ソフトウェアリソースを通って配信されたアプリケーションの機能性を調整するメッセージング要素として機能を果たすサービスアプリケーション１１６を含むことができる。サービスアプリケーション１１６は、好ましくは、アプリケーションの操作がクラスター１１０の各種のハードウェアおよびソフトウェアの間に配信されているため、アプリケーションの通常の操作が阻止された時に使用される、内部リソースである。サービスアプリケーション１１６は、好ましくは、メッセージが（他のコールルーター１１４などの）特定の目的地に供給される信頼性のあるメッセージングを提供する、メッセージングサービスである。サービスアプリケーション１１６は、選択的に、メッセージが受け取られたときメッセージを誰が受け取ったかを知ることなくメッセージをアナウンスする、放送メッセージングを提供することができる。第１の例として、ハングアップサービスアプリケーション１１６は、異なるコールルーター１１４におけるハンギングアップコールセッションを調整するために使用される。ハングアップサービスは、好ましくは、例えばアプリケーションが複数のナンバーをダイアルしたいが、コールの一つに答えると全ての答えなかったコールがハングアップする時、電話の発信をキャンセルするために、適切なコールルーター１１４とコミュニケーションをとるために使用される。第２の例として、多重入力サービスは、多数の電話装置からのコマンドを収集して入力することができる。そのため、デュアルトーンマルチ周波数（ＤＴＭＦ）の入力または音声コマンドは、いかなるコーラーによっても発生され、コールがクラスター内において多重コールルーター１１４を通して配信されたとしても、アプリケーションとコミュニケーションをとることができる。これは、電話会議においてアプリケーションを実現するために使用される。このようにして、電話アプリケーションは、クラスター内で配信される処理およびコールの取り扱いを積極的に説明する必要はなく、クラスターのハードウェアおよびソフトウェアのリソースは、好ましくは、内部サービスアプリケーション１１６のために外部アプリケーションに対して単一体のように見える。
【００１５】
また、好適な実施例の電話リソースクラスター１１０は、種々のコールルーター１１４の間のコミュニケーションおよびシンクロナイゼーションのレベルを許可するよう機能する、コールルーターネットワーク１１８を含むことができる。コールルーターネットワーク１１８は、付加的にあるいは選択的に、他のハードウェアまたはソフトウェアリソースに適用される。コールルーターネットワーク１１８は、好ましくは、シェアーしたリソースにアクセスするために、あるいは、コミュニケーションチャンネルとして、使用される。ある典型的なアプリケーションにおいて、インターネットプロトコル（ＶＯＩＰ）接続を介しての音声は、種々のコールルーターからの音声をミックスするためのコールルーターネットワーク１１８を通じて達成される。ＶＯＩＰ接続は、好ましくは、多重コールルーター１１４を通じて配信された電話会議を実行するために使用される。他の例として、コールルーターネットワーク１１８は、また、コールルーターからリアルタイムのインターネットオーディオストリームへと音声をストリーミングするために使用される。他の例として、コールルーターネットワーク１１８は、全てのルーターリソースにアクセスするためにコールルーターＡＰＩを使用する他の電話リソース１１２上のデータにアクセスするために使用される。サービスアプリケーション１１６およびコールルーターネットワーク１１８は、また、クラスター内で配信されたアプリケーションを同期させるために協同することができる。
【００１６】
好ましい実施例のコールキュー１２０は、コールリクエストのスタックを取り扱う機能を果たす。コールキュー１２０は、好ましくは、必要なリソースをサービスされないか割り当てられなかった外部へ送信されるコールリクエストのリストである。リクエストは、好ましくは、ネットワーク１５０の現在の容量および電話リソースクラスター１１０に対し好ましい料金でサービスされる。サービスされる料金は、選択的に、分散型電話コントローラー１４４の容量、電話リソースクラスター１１０、および／または、キュー１２０におけるリクエストの数に従って調整される。（電話アプリケーションによって実施される一例のような）コールリクエストは、好ましくは、容量が超過したときコールキュー１２０となり、あるいは、選択的に、全てのリクエストに対しコールキュー１２０とするか、他の好適な規則に基づいて行われる。
【００１７】
ある変形例において、アプリケーションは、好ましくは、ユーザーの限界、特に、インターコールリクエスト料金の限界（スロットル）および全体の限界（キャップ）と関連している。スロットルおよびキャップは、好ましくは、コールキューにおけるリクエストの位置を決定するために使用される。限界は、選択的に、アカウント、電話番号または好適な実体ある物に割り付けられる。電話メッセージ（すなわちＳＭＳまたはＭＭＳ）は、またコールキューとなるコールリクエストの一つの変形例である。入信および発信する電話メッセージは、好ましくは、入信したメッセージは入信したコールとは異なり即座の対応を必要としないため、キューされる。ＳＭＳメッセージは、好ましくは、リクエストがキューでサービスされた後に送られる。ＳＭＳメッセージおよび／またはＭＭＳメッセージは、選択的に、専用のメッセージキューによりキューされる。ＳＭＳメッセージは、リクエストにより変化する料金制限（スロットル）および全体の限界（キャップ）を有することができる。ユーザーからいかなる料金でも受け取られたリクエストは、好ましくは、スロットルに従ってコールキューにおいて時間間隔を有している。好ましくは、アプリケーションからのコールリクエスト間で実行されるキューが存在する。異なるユーザーのリクエストは、好ましくは、図６に示されるように、時差を持ってまたは交互にキュー状態にオーダーされるが、選択的に、ユーザーは、サービスプラン、先着順のポリシー、コールリクエストのタイプ、および／または、いかなる好適なポリシーに基づき優先順位を有することができる。キャップは、好ましくは、ユーザーが所定の時間内に行うことができるリクエストの総数上での制限である。ユーザーは、アプリケーションが電話ネットワーク１５０または電話リソースクラスター１１０の使用を常に不当に独占することを防止する機能を果たすコールキュー１２０の取り扱い、時間間隔、および／または、順序付けを制限する。また、アプリケーションは、出来るだけ早くあるいは将来のある時点で（例えば、ユーザーがコールまたは後のコールをスケジュールしている場合）、電話リソース１１２に対するアクセスをリクエストすることができる。付加的にあるいは選択的に、ユーザーの制限は、アプリケーションの必要性に従って調整されまたはセットされる。アプリケーションは、ユーザーのアプリケーションの特性または特徴に基づいた特別の要求を有する。ユーザーの制限は、好ましくは、ユーザーが選択する契約および／または価格決定モデルに従って、あるいは、他の好適な手段によって、セットされる。
【００１８】
他の変形例において、コールキュー１２０は一人のユーザーのリクエスト専用となる。この変形例において、好ましくは各ユーザーに対しコールキュー１２０を準備する。電話メッセージリクエストは、好ましくは、各電話番号に対しキューを有する。ユーザーのリクエストは、好ましくは、常に個別に割り当てられたキュー１２０に付加される。各キューは、好ましくは、（リソース限界、情報管理用限界などの）ユーザー毎の限界を考慮したスケジュールに従ってサービスされる（すなわち）待機解除される。言い換えれば、待機解除は、複数のコールキュー１２０の間で交互に起きる。また、個々に割り当てられたコールキューは、特定のリソースのためであり、キュー解除は、好ましくは、特定のリソースのキュー解除料金に従って起こる。キュー解除料金は、好ましくは、リソースの容量に関連するが、選択的に好適ないかなる基準にも基づくことができる。他のキューイングの変形例と同様に、キューイングは、他に、不規則に実施する、総当たりで実施する、公正なキューイングで実施する、重みを付けた公正なキューイングで実施する、および／または、いかなる好適な手順で実施する、などの好適なキューイング方法に従って起こる。アカウント／電話番号に基づくキューイングの他の例として、コールまたはメッセージのリクエストは、時間、優先順位、使用歴、または、他の好適な性状に基づいてキューされる。また、個人別に割り当てられたコールキュー（またはメッセージキュー）１２０の待機時間解除を調整するために使用されるコントロールキューがある。
【００１９】
上述したように、コールキュー１２０は電話メッセージ（例えばＳＭＳまたはＭＭＳメッセージ）を取り扱うための追加あるいは別のシステムを含むことができ、ＳＭＳメッセージは、好ましくは、サービス料金および制限について付加的な制限を有している。ＳＭＳメッセージは、好ましくは、各種のユーザーとの電話ネットワークアクセスをシェアするためにキューするだけでなく、料金を一人のユーザーからのＳＭＳメッセージがスパムとして認定されて料金限度になることを防ぐよう設定することが好ましい。電話メッセージのためのコールキュー１２０は、コントロールキューおよび電話番号キューの少なくとも２つのタイプのキューを含んでいる。電話番号キューは、好ましくは、ユーザーが送ろうとする電話メッセージに対する一人のユーザーの個人的なキューとしての機能を果たし、コントロールキューは、コールキュー１２０として上述した多数ユーザーのキューと実質的に近似した機能を果たす。個人に割り当てられたコールキュー１２０は、コントロールキュー無しで使用されることもでき、個人に割り当てられたコールキュー１２０は、電話番号のアカウントあるいは他の好適な割り当て方法に基づくこともできる。コントロールキューおよび電話番号キューは、好ましくは、特定のアプリケーションのためのメッセージのキューイングと複数のメッセージとを分離する機能を果たす。ＳＭＳメッセージ（テキスト）またはＭＭＳメッセージ（マルチメディア）のコンテンツは、好ましくは、直接的にコールキューに記憶されず、ＳＭＳメッセージのコンテンツに対するリファレンスを記憶することが好ましい。これはキューに対する負荷を減少させる機能を果たす。ＳＭＳ／ＭＭＳコンテンツは、好ましくは、キューされたリファレンスがサービスされた時に、記憶されアクセスされる。
【００２０】
キューポッパー１２２（例えばキュー解除装置）は、好ましくは、コールキューからのサービスのためにコールリクエストを選択する機能を果たすソフトウェアまたはハードウェアのメカニズムである。キューポッパー１２２は、好ましくは、好ましい料金でコールリクエストを選択するが、キューポッパー１２２は、その代わりに、容量または利用可能なリソースあるいはそれらの組合せに従ってコールリクエストを選択することもできる。付加的に、コールキュー１２０からのコールリクエストを同時に選択する機能を果たす複数のキューポッパー１２２が存在する。コールポッパー１２２の数は可変である。付加的あるいは特別のキューポッパー１２２を付加的なＳＭＳコールリクエストのために使用することもできる。コールキュー１２０、キューポッパー１２２、または、好適な組合せは、好ましくは、コールリクエストのスロットリング（あるいはサービス料金）をコントロールするために使用される。スロッティングは、電話番号ごとに、アカウントごとに（マルチテナントアプリケーションと同様に）、および／または、コール／メッセージ属性に従って、実行される。
【００２１】
好ましい実施例の解析システム１３０は、リソース要求を予測するためにシステムを解析する機能を果たす。解析システム１３０は、好ましくは、システムの複数の側面をモニターする。解析システム１３０は、ネットワークまたはハードウェアの操作レベルまたはトレンド（増加または減少）などの現在の容量；容量中の相関（例えばパターン検知）を見つけるために記録されたデータのような使用履歴；キューの長さおよびキューの入力待ち時間；アプリケーションの過去の使用からの履歴パターンなどのアプリケーションの解析；および／または任意の適切な側面、をモニターすることができる。必要な容量のパターンは、好ましくは、時刻、曜日、年間パターン、（あるユーザーに必要な容量が増加すると、他のユーザーに必要な容量の増加を示すなどの）使用パターン、コール位置、コールのコール時間、および／または、他の好適な指標に関連して見つかる。解析システム１３０は、好ましくは、電話ネットワークチャンネルに対する入信および発信容量の区別をする。解析システムは、好ましくは、リソースアロケーター１４０、分散型電話コントローラー１４４、負荷バランサー１４２、および／または、付加的なコールキュー１２０に対するデータを発生する。解析システムからの予測またはデータは、さらに、分散型コールコントローラーの容量のプロビジョニングのために、電話ネットワークの静的容量、コールルーターの数、クラスター内のハードウェアまたはソフトウェア、および／または、キューマネージメントのパラメータの容量のプランニングのために、使用される。解析システム１３０は、好ましくは、負荷の予測値および実証値を比較し、システムのリソースにおける変動を補正するために使用されるデータを提供する。
【００２２】
好ましい実施例におけるリソースアロケーター１４０は、電話クラスター１１０の操作を拡張および管理する機能を果たす。リソースアロケーター１４０は、付加的および好適に、クラスター１１０の電話リソース１１２を再供給し、新しい電話リソース１１２を割り当て、電話リソースおよび／または他の好適な割り当てプロセスを再割り当てする。リソースアロケーター１４０は、さらに、コールキューのプロビジョニングおよびシステムの他の装置をコントロールする。リソースアロケーター１４０は、好ましくは、リソースのプロビジョニングおよび操作を決定する際に解析システム１３０のデータを使用する。このリソースアロケーター１４０は、解析システム１３０からの情報を用いて、所望の電話リソース１１２の容量を予測することが好ましい。リソースアロケーター１４０は、好ましくは、どのくらいのハードウェア（物理的または仮想的）またはソフトウェアリソースが操作のために必要なのかを決定するために、予測した容量要求を使用し、リソースアロケーターは、好ましくは、必要に応じて電話リソース１１２（例えば、コールルーターおよび／または他のハードウェアまたはソフトウェアリソース）を、割り当てたり、再割り当てしたり、または、再供給する。リソースアロケーター１４０は、さらに、開始時間、操作コスト、または、特的の時間で割り当てられたリソースの数および比を決定する際の、ハードウェアおよびソフトウェアのリソースのパラメータを使用する。リソースアロケーター１４０は、また好ましくは、現在利用可能なリソースの量の経過をたどり、デキューアー、ロードバランサーなどを含む、他のシステムコンポーネントに利用可能なリソース利用可能性の情報を作り出す。そのようなリソース利用可能性の情報は、好ましくは、システムコンポーネントの操作を調整するために他のシステムコンポーネントによっても使用される。リソースアロケーター１５０は、好ましくは、リソースをモニターし、リアルタイムでリソースを再供給する。
【００２３】
好ましい実施例のリソースアロケーター１４０は、好ましくは、コールルーターおよび他のハードウェア内の処理タスクを配信する機能を果たすロードバランサー１４２を含む。好ましい実施例のロードバランサー１４２は、好ましくは、処理タスクの配信を最適化し、複数のコールルーター１１４は最適なレベルであるいは最適なレベルの近傍で操作される。コールルーター１１４の操作は、パフォーマンス、エネルギーコスト、および／または、いかなる好適な状態に対して最適化される。ロードバランサー１４２は、好ましくは、タスク（例えば、コールリクエスト／セッションのサービス）をタスクが生成されるようにコールルーター１４２（または電話リソース１１２）に割り当てる。タスクは、好ましくは、電話アプリケーションの操作であるが、コールリクエストまたはコールセッションとすることもできる。ある例において、１００個のコールルーター１１４は１００個の電話アプリケーションに対するコールルータータスクを提供する。第２の例において、１００個のコールルーター１１４は、それぞれ、１００人の参加者の電話会議アプリケーションのように、１つの電話アプリケーションと関連した単一のコールセッションを取り扱うことができる。リソースアロケーター１４０は、好ましくは、ロードバランサー１４２にシステムリソースの現在のステータス（リソースの負荷、リソースの数など）に関し通知を送る。ロード１４２は、リソースアロケーター１４０によって供給されるデータに基づき、ロードバランスされるアプリケーションの要求に適合する現在利用可能で動作中のリソースに対しリクエストを配信する。
【００２４】
好ましい実施例のリソースアロケーター１４０は、システムによる電話ネットワーク１５０の使用および操作をコントロールする機能を果たす分散型コールコントローラー１４４を含む。分散型コールコントローラーは、好ましくは、複数の電話リソースによって電話ネットワークチャンネル１５０のシェアーされた使用を取り扱う。分散型コールコントローラー１４４は、選択的には、多重ネットワークのプロバイダーまたはキャリアーが使用されたときには、多重電話ネットワークのサブセットとすることもできる。分散型コールコントローラー１４４の操作は、好ましくは、電話ネットワーク１５０の現在の容量リクエストに対し割り当てられたチャンネルの数を操作する機能を果たす。割り当てられたチャンネルは、好ましくは、使用中か使用のために準備されている利用可能な静的チャンネル容量内のチャンネルである。分散型コールコントローラーは、好ましくは、常に静的チャンネル容量未満または同じ容量を有している。分散型コールコントローラー１５０の容量は、好ましくは、電話ネットワークの多くのリソースをコールコントローラーに割り当てることによって増加し、分散型コールコントローラー１４４の容量は、好ましくは、電話ネットワークのリソースを再割り当てすることによって減少する。一例として、商品ハードウェアノードを、高容量要求の間電話ソフトウェアスタックを実行するために、電話ネットワークに付加することもできる。分散型コールコントローラー１４４は、好ましくは、望ましい容量要求を予想しまたは要求に応答するために、解析システム１３０を使用する。電話ネットワーク１５０は、また、コールを受信し、コールを発信し、その両者を個別に行うために使用できる、入信チャンネル、配信チャンネル、および、両方向通信チャンネルに分割される。電話ネットワーク１５０は、さらに、ＳＭＳまたはＭＭＳの入信および配信チャンネルを含むことができる。分散型コールコントローラー１４４は、好ましくは、予想した使用に従ってチャンネルのタイプの使用を取り扱う。両方向のチャンネルは、好ましくは、容量要求にフィレキシブルに対応するために使用される。一例において、入信コールロード多くなると予想されるときは、配信コールは、好ましくは、入信コールにに多くの容量をあてるように、配信チャンネルに向けられる。分散型コールコントローラー１４４は、また、ネットワークプロバイダーからの予約や契約に従って、割り当てられたチャンネルの数および使用を取り扱うことができる。チャンネルは、割り当てまたは再割り当て操作に使用され、大口価格のスレッシュホールドまたは他のネットワークのコンディションを満たすことを保証する。
【００２５】
チャンネル１５０の静的数を有する電話ネットワークは、好ましくは、ユーザーに電話ネットワークのアクセスを提供するための基本インフラである。電話セッションは、好ましくは、電話ネットワークを通じてコミュニケーションをとることができ、電話セッションは、好ましくは、電話音声セッションおよび／またはテキスト／メディアメッセージング（電話メッセージング）を含む。チャンネル静的数は、好ましくは、同時にサポートされる同時に生じる電話セッションまたはコールの全数である。チャンネルの数は、典型的には、特定のキャリアまたはネットワークに利用可能な相互接続の数によって制限される。電話ネットワーク１５０は、あるいは、複数のキャリアまたはネットワークプロバイダーまたは公衆電話交換網から構成することもできるが、複数のキャリアまたはネットワークは、好ましくは、１つの電話ネットワークとして扱われたり取り扱われたりする。チャンネルの静的数は、好ましくは、一時期のセット数（通常電話会社との契約に基づく）であり、その数は、好ましくは、十分な容量を提供するために十分大きい。チャンネルの静的数は、好ましくは、ネットワークの容量および他のネットワークと接続する電話ネットワークの能力を決定する。電話ネットワークの操作は、好ましくは、アプリケーションを電話ネットワークのチャンネルにアクセスさせることによって扱われる。電話ネットワークは、常に使用されない所定数のチャンネルを有している。ある変形例において、電話ネットワークは、また、未使用モードにおいて未使用のチャンネルを操作することができる。未使用モードは、完全または部分ハードウェアパワーダウンモード、ハードウェアスリープモード、（逆効果も与えずに好ましくは中断することができる重要でないユーザーにとっての）二次使用、および／または、他の好適な方法である。未使用モードは、操作コストを減少させる機能、および／または、未使用容量のユーティリティを最大化する機能、を果たす。電話ネットワークチャンネル１５０は、好ましくは、公衆交換電話網（ＰＳＴＮ）接続であるが、別の例として、セッション・イニシエーション・プロトコル（ＳＩＰ）トランクス、あるいは、電話装置との電話ネットワーク接続を創造するいかなる好適な装置でもある。
【００２６】
２．マルチテナント電話ネットワークを操作する方法
図１に示すように、好ましい実施例におけるマルチテナント電話ネットワークを操作する方法は、複数ユーザーの電話リソースＳ１１０に対するコールリクエストを多重化する工程、電話リソースＳ１３０を介してコールリクエストから第１のコールセッションを生成する工程、および、電話チャンネルＳ１４０に対する複数の付加的なコールセッションとそのコールセッションとを多重化する工程を含む。方法１００’は、リソースインテンシブな電話アプリケーションに対し、効果的で拡張可能なネットワークシステムを生成する機能を果たす。電話リソースは、好ましくは、電話リソースクラスターの部分である。電話リソースクラスターは、好ましくは、ネットワーク負荷の広いスペクトラムを扱う能力により、マルチテナント電話ネットワークを使用するために、操作コストを減少させて各種のアプリケーションの使用を許可する機能を果たす、即時キャパシティ要求を満たすよう増減する。さらに、方法１００’は、リソース（例えば電話リソース）をシェアーする種々のマルチユーザーの間に分配される、電話アプリケーションの操作を許可する機能を果たし、電話アプリケーションの特定の目的はマルチテナント電話ネットワークによって制限されない。好ましい実施例における方法１００’は、好ましくは、上述したシステムによって実行されるが、他の方法として、いかなる好適なシステムによっても実行することができる。
【００２７】
電話リソースに対する複数のユーザーのコールリクエストを多重化するステップＳ１１０は、複数のユーザー間における電話リソースの使用をシェアーする機能を果たす。単一の電話リソースは、好ましくは、複数のユーザー／アプリケーションの間でシェアーされる。多重化は、好ましくは、コールリクエストが交互に電話リソースに送られる、時分割多重の形態で起こる。時分割多重化は、好ましくは、完全なコールセッションまたはプロセスの完遂に基づく。言い換えると、ユーザーは、電話リソースを使用してコールセッションの生成およびアプリケーションの実行を交代に行う。例えば、第１の顧客が電話リソースによってサービスさえるコールリクエストを実行している場合、そのコールリクエストのコールセッションの完遂により、第２の顧客が同じ電話リソースによってサービスされるコールリクエストを行うことができる。コールリクエストは、好ましくは、ユーザーからより具体的には外部サーバー上に在駐する電話アプリケーションから、受け取られるが、別の例では、コールリクエストはいかなる好適なソースからも送られる。コールリクエストは、好ましくは、パケットに基づくコミュニケーションチャンネル、言い換えると、無指向性のコミュニケーションチャンネルを通って、受け取られる。変形例において、コールリクエストは、好ましくは、ＨＴＴＰまたはＨＴＴＰＳメッセージとして受け取られるが、他の例では、いかなる好適なアプリケーションコミュニケーションプロトコルを介して受け取られることもできる。ステップＳ１１０は、さらに、入信するコールリクエストをゲートコントロールするかそれに優先順位を付ける機能を果たす、ユーザーＳ１１２のコールリクエストをキューイングする工程を含む。コールキューは、好ましくは、外部へ送信されるリクエストのために使用され、一方内部で受信されるリクエストは、好ましくは、すぐに扱われる（さもなければ、コールセッションはたぶん失敗する）。あるいは、内部で受信されるコールは、全てのサービスに対し、再生された「鳴り響く」音とともに、キューすることができ、一方、コールは、全てをサービスされるようにキューの状態に待機する。キューは、しかしながら、ＳＭＳメッセージおよびＭＭＳメッセージのような電話メッセージは最初の試みで受け取られなければ再び送られるため、内部で受信される電話メッセージのために使用される。コールキューは、好ましくは、複数ユーザーからの継続中のコールリクエストのリストである。付加的なキューは、付加的にあるいは選択的に、電話メッセージのために使用される。コールリクエストは、好ましくは、リソースに対するアクセルのバランスを取るような方法で、キュー内で順番が付けられる。各ユーザー（例えば、アカウント、アプリケーションまたは電話番号）には、好ましくは、内部コールリクエストの制限（スロットル）および特定の時間内で成されるコールリクエストの最大数における制限（キャップ）を割り当てられる。コールリクエストは、好ましくは、電話リソースクラスターの現在の負荷に基づきコールを選択する装置（すなわち、キューポッパー）によって、特定の料金でのサービスのために選択される。キューは、上述したような任意の好適な変形例によって選択的に操作される。キューは各ユーザーまたは電話番号に割り当てられている。キューすることは、選択的に、ランダム、総当たり、規則に従ったキュー、重み付けした規則に従ったキュー、実際のリソースの使用に基づく、および／または、任意の好適な手順などの任意の好適なキューイングの方法論に基づいて起こる。ロードバランサーは、好適には、最も少ない容量の電話リソースにコールリクエストを割り当てる。ロードバランサーおよびコールリクエストのキューは、好適には、協同して、上述したようにロードを割り当てる。
【００２８】
追加のステップとして、方法１００’は、十分に多重化するための電話リソースへの通話要求を電話リソースクラスターの容量を拡張するために機能する、電話リソースクラスターＳ１２０のリソースの供給を含む。ステップＳ１２０は、電話リソースクラスターの既存の電話リソースを再供給し、電話リソースクラスターに追加のリソースを割り当て、および／または、電話リソースクラスターのリソース割り当てを解除し、および／または、リアルタイムにリソースのある型から別のリソースを再割り当てすること、を含む。電話リソースクラスターは、好ましくは、上記のようなさまざまな機能や操作を行う電話リソースを複数有している。例えば、電話リソースクラスターは、コールルーター、転送システム、メディア処理システム、および音声合成システムを複数含めることができる。電話リソースは、好ましくは、第一の目的のため、コンピュータのプロセッサおよび／またはストレージリソースで構成されている。Ｓ１２０の一部として、電話リソースクラスター、プロセッサおよび／またはストレージデバイスのリソースは、好ましくは、新しい第二の目的のために再供給される。例えば、テキストを音声に変換することは、より多くのコールが提供される必要があるタイミングでコールルーターとして機能するように再供給される。さらに、システムに新しいリソースを追加するおよび／または共有リソース環境の別の顧客からリソースを割り当てることを含むことができる、より多くのリソースが、割り当てられまたは再割り当てを解除することができる。リソースは、好ましくは、このようなクラウドホスティングプロバイダ（すなわち、ユーザーが仮想マシンのリソースを作成するためにマシンのイメージをブートできるようにサイズ変更可能な計算能力を提供するウェブサービス）などの複数テナントで共有、仮想化したコンピューティング環境で提供されるが、代わりに同じ場所にあるいか分散された物理マシンとすることもできる。例えば、多数のリソースがパワーダウン状態で稼動することもできる。さらに容量が必要とされている場合、リソースはオン／ブート（すなわち再割り当て）され、電話リソースクラスターの新しいリソースとして機能する。同様に、電話リソースクラスターが現在必要とされるより多くの容量を持っているときに、リソースは、パワーダウンするか、他の企業で使用するためのリソースのプールに戻る（すなわち、割り当て解除）、または、リソースの現在の使用を終了する任意の適切なアクションとすることができる。
【００２９】
さらに、ステップＳ１２０は、リアルタイムまたは差し迫ったキャパシティ要件でデータを収集するために機能する、リソースのキャパシティ要件Ｓ１２２を分析することを含むことができる。データは、容量要求に保存されている履歴、電話リソースクラスターの現在の負荷、アプリケーションの分析からのデータ、または容量要求を予測するの任意の適切なソースから、コールリクエストキューから、収集されることがある。コールリクエストキューからのデータには、保留中のコールリクエスト、コールリクエストの型または詳細、または任意の適切なキューに関連する情報などの情報を提供することできる。保存されている容量の履歴は、好ましくは日、週、または年を通じて、一時的なパターンのような容量パターンに洞察を提供する。電話リソースクラスターの現在の負荷は、好ましくは、電話リソースのリソースの現在の数、電話リソースの利用可能なリソースの数、リソースの種類の区分、割り当て解除されたリソースの数、電話のネットワークチャンネルの数などの情報を提供する。アプリケーションの分析データは、好ましくは、予想または予測された容量リクエスト上のユーザーの電話アプリケーションからのデータである。解析は、好ましくは、アプリケーションの操作で実行され、またはコールの数、コールのピーク時間、コールのタイプ（例えば、電話会議、ＳＭＳメッセージなど）のアプリケーションの予想される容量リクエストに関するユーザーから収集される。解析情報は、好ましくは、供給、割り当て、およびステップＳ１２０のリソースの割り当て解除を制御するために使用される。さらに、容量要求を分析した後、電話リソースクラスター、電話リソース、コールキュー、デキュー、リソースアロケーターなどのようなシステムの他の構成要素は、好ましくは、関連する分析情報として通知される。特定の分析情報は、特に構成要素に送信されることがある。例えば、ロードバランサーとデキューは、好ましくは、容量の情報に基づいて利用可能なリソースと調整する操作について通知される。
【００３０】
電話リソースを介してコールリクエストからの最初のコールのセッションを作成することを含むステップＳ１３０は、電話リソースを使用してコールセッションへのコールリクエストを変換するための機能を果たす。ステップＳ１３０は、好ましくは、追加の処理およびさらに特定のアプリケーションに固有の手順を含む。望ましい変形例では、コールルーターは、好ましくは、宛先の電話番号を識別するためのコールリクエストの電話命令を処理し、その後、ステップＳ１４０の一部として、宛先の電話番号への接続を確立する。転写のサーバは、録音を開始したり、コールセッションの会話を録音する準備をすることができる。
【００３１】
電話チャンネルへの複数の追加コールセッションで、コールセッションを多重化することを含むステップＳ１４０は、電話デバイスへの電話ネットワーク接続を確立する機能を果たす。電話チャンネルは、好ましくは、ＰＳＴＮ（公衆交換電話網）接続である。これは、ＰＳＴＮに接続するための物理的なワイヤーまたはいくつかのインタフェースのインフラストラクチャである。場合によっては、チャンネルの概念は、好ましくは、電話ネットワークにサブスクライブされたり、電話ネットワークから借りる。一つの変形例では、ＳＩＰ（セッション・イニシエーション・プロトコル）トランクは、電話ネットワークへのインターネットベースのゲートウェイとして使用される。多重化は、好ましくは、電話セッションが交互に電話チャンネルに接続される時分割多重化の形で発生する。時分割多重化は、好ましくは、完全な電話セッションの完了に基づく。例えば、特定のネットワークチャンネルは、先ず第１に、最初のユーザーのコールセッションのために利用され、呼び出しの完了時に、第２のコールセッションは２番目のユーザーのための特定のネットワークチャンネルを確立する。ステップＳ１４０の部分として、電話チャンネルは、さらに、電話チャンネルＳ１４２の供給を含む。この機能は、システムの利用可能な多数の電話ネットワークの容量を調整する。電話ネットワークへのゲートウェイを供給すること（例えば、ルーターまたはＳＩＰトランクを呼び出す）で、チャンネルまたはチャンネルへのゲートウェイを、割り当てまたは割り当て解除することができる。電話ネットワークチャンネルのそのようなスケーリングは、好ましくは、現在の電話ネットワークの容量要求に近い動作を可能とする。このようなスケーラビリティが使用されていない場合は、同時に使用できるチャンネルの数に制限を設定する。
【００３２】
３．動的な電話ネットワークを作動させる方法
図６に示すように、好ましい実施形態の電話ネットワークを提供する方法２００は、チャンネルＳ２１０の静的な数の電話ネットワークを操作する方法を含んでおり、複数のユーザーＳ２２０に電話ネットワークチャンネルへのアクセスを提供し、ユーザーが通常の操作Ｓ２３０を超える多数のチャンネルにアクセスできるようにチャンネルの使用状況を管理する。方法は、電話ネットワークのオペレータが、使用状況に基づくサービスの品質や信頼性を低下させることなく、複数のユーザーに高容量を提供できるようにする機能を果たす。この方法は、好ましくは、上述のものと実質的に同様のシステム上に実装されるが、任意の適切なシステムを代わりに使用することもできる。方法は、さらに、本明細書に記載の方法と組み合わせて使用することができる。方法２００は、さらに、ユーザーが操作に必要なチャンネルの数に関する特定の懸念なく、電話ネットワークを使用可能する機能を果たす。電話ネットワークのユーザーは、好ましくは、コールセンター、構内交換機（ＰＢＸ）、電話ツリー、電話アプリケーション、ＶＯＩＰサービス、ＳＭＳまたはＭＭＳサービス、および／または、任意の適切な電話アプリケーションなどの電話アプリケーションを操作する。電話ネットワークのオペレータは、好ましくは、電話プラットフォームプロバイダ（例えば、インターネット電話のプラットフォームのプロバイダー）などの電話サービスプロバイダー、電話会社（例えば、ＡＴ＆Ｔなどの電話ネットワークの所有者）、および／または、任意の適切なパーティーである。好ましい実施形態の変形例において、方法２００は、さらに、分散型コール制御、コールキュー、および／または、容量要求を評価する工程を含むことができる。
【００３３】
チャンネルの静的な数を有する電話ネットワークを操作することを含む、ステップＳ２１０は、電話ネットワークのアクセスをユーザーに提供するための基本インフラとなる機能を果たす。チャンネルの静的な数は、好ましくは、一度にサポートできる同時電話セッションまたはコールの合計数である。チャンネル数は、従来、特定のキャリアやネットワークへの利用可能な相互接続の数によって制限されている。電話ネットワークは、しかし、複数のキャリアやネットワークプロバイダまたは公衆交換電話網から構成されるが、複数のキャリアやネットワークは、好ましくは、１つの電話ネットワークとして管理され取り扱われる。チャンネルの静的な数は、好ましくは、時間の期間（通常は電話会社との契約に基づく）のために定められた数であり、その数は、好ましくは、十分な容量を提供するために十分な大きさである。チャンネルの静的な数は、好ましくは、ネットワークの容量や他のネットワークと接続する電話ネットワークの能力の指標となる。電話ネットワークの操作は、好ましくは、電話ネットワークのチャンネルへのアクセスをユーザーに提供することによって取り扱われる。電話ネットワークは、任意の時点で使用されていないチャンネルの指定された数を持つことができる。ある変形例では、電話ネットワークは、代わりに、使用されていないモードで未使用のチャンネルを操作することができる。未使用モードは、完全または部分的なハードウェアのパワーダウンモード、ハードウェアのスリープモード、二次利用（望ましい最小限の副作用で中断することができる非重要な用途のような）、および／または、任意の適切な方法となる。未使用モードは、操作のコストを削減し、および／または、未使用容量の効用を最大化する機能を果たす。
【００３４】
好ましい実施形態の追加の代替手段として、方法は、電話ネットワークＳ２１２のサブセットとして、分散型コールコントローラーでの操作が含まれる。複数のネットワークプロバイダやキャリアが使用されている場合、分散型コール制御は、代わりに、複数の電話ネットワークのサブセットとなる。分散型コールコントローラーの操作は、好ましくは、電話ネットワークの現在の容量要求についてチャンネルの割り当てられた数を操作する機能を果たす。分散型コールコントローラーは、好ましくは、任意の時点での静的なチャンネル容量として、より小さいまたは等しい容量を持っている。分散型コールコントローラーの容量は、好ましくは、コールコントローラーへの電話ネットワークのより多くのリソースを割り当てることによって増やすことができ、分散コールコントローラーの容量は、好ましくは、電話ネットワークのリソースの割り当てを解除することによって低減することができる。電話ネットワークへのアクセスは、好ましくは、仮想化されたハードウェアまたはソフトウェア（ルーターまたはＳＩＰトランクなどの呼び出し）によって促進される。電話ネットワークのより多くのリソースの割り当ては、さらに、電話ネットワークにアクセスするデバイスの仮想化が含まれる。例えば、ネットワークアクセスチャンネルの仮想化は、電話ネットワークにさらにアクセス容量を追加するために加えることができる。別の例として、市販のハードウェアノードは、高い容量要求の間に電話ソフトウェアスタックを実行するための電話ネットワークに追加される。
【００３５】
複数のユーザーに電話ネットワークへのチャンネルアクセスを提供することを含む、ステップＳ２２０は、複数の別のパーティーが電話ネットワークのチャンネルにアクセスすることを許可する機能を果たす。ユーザーは、好ましくは、電話ネットワークのオペレータのサービスに加入している。電話ネットワークのユーザーは、好ましくは、コールセンター、構内交換機（ＰＢＸ）、電話ツリー、対話型音声応答（ＩＶＲ）アプリケーション、インターネット電話アプリケーション、ＶＯＩＰサービス、および／または、任意の適切な電話アプリケーションなどの電話アプリケーションを操作している。ユーザーは、好ましくは、チャンネルの特定の数に基づいたサービスに加入しない。ユーザーの観点から、チャンネル数は、好ましくは、ユーザーのアプリケーションの操作に対して無限または無関係のポイントである。電話ネットワークがチャンネルごとに操作されている間、ユーザーは、好ましくは、１人あたりの使用量や時間の観点（例えば、価格設定および／またはアプリケーションの使用の観点を）表示される。電話ネットワークのオペレータは、好ましくは、電話ネットワーク（電話会社からのリースや運用コストの固定資本コスト）の操作に関連するコストをユーザーに対する変動費へ変換する。電話ネットワークへのアクセスは、好ましくは、操作され、リースされ、および／または、１人あたりのチャンネルによって電話会社（ＡＴ＆Ｔなど）からの契約となる。リース契約または契約は、代わりに、チャンネルごとの（容量）コストを最小限とし、好ましくは使用ごとまたは時間のコストごとを強調するように交渉され、あるいは、任意の適切なリース契約または契約を使用することができる。ユーザーは、好ましくは、使用量、毎分の時間間隔に対する均一料金、使用量および時間料金の組み合わせ、および／または、任意の適切な価格決定モデルによって支払う。
【００３６】
通常操作Ｓ１３０を超える多数のチャンネルへのユーザーアクセスを許可するようにチャンネルの使用を管理することを含む、ステップＳ２３０は、電話ネットワークの品質と信頼性が他のユーザーの利用状況によって影響を受けないことを確保しながら、ユーザーに高容量の利用可能性を提供する機能を果たす。複数のユーザーの個々のユーザーは、好ましくは、チャンネルの静的な数の複数のユーザー間で均等に分割するよりも大きい多数のチャンネルを使用することが許される。個々のユーザーが特定の時間に使用するチャンネルの最大数の合計は、好ましくは、チャンネルの静的な数よりも大きくなる。個々のユーザーがチャンネルの最大数のアクセスできる所定の時間は、好ましくは、他のユーザーからの電話ネットワーク上の要求が少ないときである。電話ネットワークおよび電話リソースクラスターの利用状況は、好ましくは、電話セッションの完了に基づく時間ベースの多重化である（すなわち、ユーザーがリソースとネットワークの使用を共有する）。簡単な例では、電話ネットワークは利用可能な１０チャンネルを持ち、５人のユーザーが存在する。一様に配信する場合、ユーザーはそれぞれの用途に利用可能な２チャンネルを持つが、一つの好ましい実施態様では、５人のすべてのユーザーが、他のユーザーがチャンネルを使用していないと仮定し、それぞれ最大１０チャンネルのアクセスを持つことができる。電話ネットワークの通常の使用中に、ユーザーは、依然として電話ネットワークのチャンネルの最大数にアクセスする能力を持っているが、コールリクエストは、好ましくは、コールキューが発したユーザーの制限のゲートとなる。上記の例を拡張する別の例では、分析は、４人のユーザーが特定の時点において２チャンネルを使用すると、最初の４人のユーザーのための能力、可用性を維持しながら、８チャンネルを５人目のユーザーが利用可能となることを示している。チャンネルの使用状況を管理することは、好ましくは、コールキューを管理し、ユーザーの制限を強制し、使用状況と容量要求を予測および／または分析し、分散型コールコントローラーの能力に基づいて容量を調整し、および／または、電話ネットワークのリソースを管理するための任意の適切な手順することなどにより、リソースの使用状況を取り扱うことを含む。分散型コールコントローラーの容量は、さらに、予測および解析によって制御されまたは影響を受け、ユーザーはさらに影響を受ける。
【００３７】
好ましい実施形態の方法は、さらに、複数のユーザーからの要求のコールキューＳ２３２を管理する工程を含むことができる。ステップＳ２３２は、ユーザーからのコールリクエストの処理を優先させる機能を果たす。コールキューは、好ましくは、電話ネットワークの制御アーキテクチャの一部として運営されているプログラムまたはハードウェア管理のスタックである。制御アーキテクチャは、好ましくは、複数のユーザーによる電話ネットワークと利用状況を操作する。コールキューは、好ましくは、電話ボイスセッションの要求、および／または、ＳＭＳ／ＭＭＳメッセージの要求を含む電話ネットワークによるサービスを待機するコールリクエストのリストである。リクエストは、ネットワーク、好ましくは、ネットワークの現在の容量に対し、および、各ユーザーに対し、適切な料金でサービスされる。サービス料金は、代わりに、分散型コールセンターの容量およびキュー内のリクエストの数に応じて調整される。容量が、超過するか、あるいは、すべてのリクエストのためのコールキューに置かれている場合、または、任意の適切なルールに基づいている場合、ユーザーのリクエストは、好ましくは、コールのキューに置かれる。ユーザーは、好ましくは、特定のユーザーの制限、特に：コールレートの制限（スロットル）と合計の制限（キャップ）に関連付けられている。スロットルとキャップは、好ましくは、コールキュー内のリクエストの位置を決定するために使用される。ユーザーからのリクエストは、好ましくは、スロットルに応じてコールキュー内で時間的に離間している。異なるユーザーのリクエストは、好ましくは、図６に示すように、階段状または交互にキュー内で順序付けされるが、代わりに、ユーザーは、サービスプラン、先着順セルフサービスポリシー、および／または、任意の適切なポリシーに基づいた優先権を持つことができる。キャップは、好ましくは、ユーザーが一定時間内に行うことができるリクエストの合計数の制限である。後続のリクエストは、好ましくは、キャップに応じて後の時間に対しスケジュールされているが、キャップを超えるリクエストを任意の適切な方法で処理されることもできる。例えば、ユーザーが１秒あたり１回のコールができ、ユーザーが１００コールをリクエストすると、それらは等しく次の１００秒においてスケジュールされる。このキャップは、コール／時間フレーム（１／秒）の数、または、キュー内のコール（１秒）の間に必要な待ち時間の数として記述することができることに注意すべきである。ユーザーは、ハンドリング、スペーシング、および／または、あるユーザーが不当に任意の時点で電話ネットワークの利用を支配することを防ぐように機能するコールキューのオーダリングを制限する。ＳＭＳ／ＭＭＳのメッセージリクエストの変形例において、個々のユーザーの料金は、ネットワークによるメッセージのフィルタリングを防ぐために考慮される。ＳＭＳ／ＭＭＳの変形例のために、リクエストは、さらに、制御キューと電話番号のキューでキューイングされる。ＳＭＳ／ＭＭＳメッセージの内容は、好ましくは、保存され、メッセージの内容への参照により、キューの負荷を軽減する機能がキューイングされる。複数のキャッシュサービスのポートまたはポインタが好ましく用いられる。サービスポートは、好ましくは、コールキューからのコールリクエストを動作させるための、ソフトウェアおよび／またはハードウェアの制御メカニズムである。サービスポートは、好ましくは、コールキューからリクエストを受け取り、電話ネットワークのチャンネルに対応するユーザーのアプリケーションまたはユーザーを接続する。サービスポートは、直接接続されるが、代わりに、前述のようにクラスター内のコールルーターなどのハードウェアまたはソフトウェアリソースとすることもできる。サービスポートは、好ましくは、着信コールのための容量を可能にするチャンネルの静的な数未満であるが、他の例として、サービスポートをチャンネルの静的な数に等しくすることもできる。電話ネットワークが１０００チャンネル存在する例では、５００のサービスのポートが存在する場合がある。これは、着信コールのために５００チャンネルをフリーにすることを意味する。さらに、ユーザーは、できるだけ早くまたは将来のある時点（例えば、ユーザーがコールまたは後の時間のためのコールをスケジュールする）での、電話リソースへのアクセスを要求することができる。キューポッパーは、好ましくは、サービスするコールキューからのコールを選択するための、ソフトウェアまたはハードウェアのメカニズムである。さらに、コールキューからコールを選択する複数のキューポッパーが存在する場合がある。加えてまたは代わりに、ユーザーの制限は、ユーザーのニーズに応じて調整または設定される。ユーザーは、ユーザーのアプリケーションの性質や特性に基づいた特定の要求を有する場合がある。ユーザーの制限は、好ましくは、ユーザーが選択した契約および／または価格設定に応じて、または、任意の適切な手段によって、設定される。
【００３８】
好ましい実施形態の方法は、さらに、分散型コールコントローラーＳ２３４に対する容量要求を予測する工程を含むことができる。ステップＳ２３４は、後で必要になった電話ネットワークチャンネルの数に相関する指標を評価する機能を果たす。キャパシティの予測は、好ましくは、プログラム的にまたは数学的に（パターンの検出または任意の適切なアルゴリズムを介して）現在および過去の情報を分析することによって達成されるが、任意の適切な方法を代わりに使用することもできる。容量ニーズのパターンは、好ましくは、時刻、曜日、年のパターン、利用パターン（１人のユーザー容量ニーズの増加が他のユーザーが容量ニーズの増加を示す場合など）、コール位置、コール通話時間、および／または、任意の適切な指標に関連して見つかる。ステップＳ２３４の予測は、さらに、リアルタイムの供給、供給の解除、および／または、分散型コールコントローラーや電話ネットワークの静的容量のプランニングキャパシティ要求のために使用することができる。
【００３９】
好ましい実施形態の方法は、さらに、コールキューＳ２３６の容量ニーズに反応させる工程を含めることができる。ステップＳ２３６は、現在の容量要求または近い将来予想される要求に対し分散型コールコントローラーを調整するために、コールキューと他の現在容量の指標を使用する機能を果たす。コールキューは、好ましくは、ソフトウェアを介して、または、コールキューの任意の適切な監視によって、評価される。キュー中に現在存在するコール数、電話ネットワークを現在使用しているユーザーの合計数、入信コール（キューされない）、ユーザーリクエストの頻度、および／または、電話ネットワークまたはコールキューの任意の適切な特性は、好ましくは、容量のニーズへのリアクションを引き起こす。リアクションは、好ましくは、現在の全体の容量のニーズに対するものであるが、あるいは個々のユーザーまたは任意の適切なパーティーの現在の容量ニーズに対するものとすることもできる。リアクションは、コールキュー（たとえば、コールキューのサービス料金またはオーダリング）の設定を調整し、ユーザー制限を変更し、分散型電話コントローラーの容量の調整すること、および／または、任意の好適なアクション、を含むことができる。一例において、コールキューは、現在の時刻の後１００秒の間にスケジュールされ、分散型コールコントローラーが予想される容量要求を収容する容量を増加させる。
【００４０】
好ましい実施形態の方法は、さらに、ユーザーの容量ニーズを分析して電話ネットワークの容量ニーズを予測するステップＳ２３８を含む。ステップＳ２３８は、電話ネットワークの総容量要求を決定するために個々の容量ニーズを検出するの機能を果たす。ユーザーの容量ニーズは、好ましくは、ユーザーの電話アプリケーションを分析することによって取得される。分析の部分は、好ましくは、個々のアプリケーションの容量ニーズを示す定期的なイベントを検知することを含む。このようなイベントの例は、発信者が番組の放送時間前後にコールする週刊テレビ番組に関連付けられたアプリケーションである。分析は、代替的または追加的に、個々のアプリケーションの典型的な通話時間を検出することが含まれる。他のアプリケーションが使用の長い期間（ユーザーが長い電話のツリーをナビゲートしなければならない場合など）を必要とする場合、いくつかのアプリケーションは時間の短い使用となる（短いメッセージが再生されている場合など）。さらに、アプリケーションの履歴が、最大、最小、および／または、平均の容量要求、リクエストの頻度、リクエストの期間、特定の時間の期間に送信されたＳＭＳメッセージの数、および／または、任意の適切コール特性などによって、使用パターンを決定するために使用されることがある。ユーザーの個々のアプリケーションの使用特性は、好ましくは、電話ネットワークの総使用特性および容量ニーズを決定するために、他のユーザーの利用特性と組み合わされる。好ましくは、アプリケーションのコードは、アプリケーションの機能および使用パターンを評価するために分析される。アプリケーションのコードまたは操作は、好ましくは、プログラム的に解析されるが、任意の適切な方法を用いてもよい。また、ユーザーおよび／または第２パーティーは、ユーザーのアプリケーションおよび／または電話サービスを特徴付けることができる。この特徴付けは、好ましくは、サインアップしながらユーザーによって実行され、そして好ましくは、使用頻度、使用回数、通話時間、および／または、アプリケーションの任意の適切な特性に対するユーザーの予測が含まれている。容量をそのアプリケーションの最上位にすべき場合、ユーザーはさらに優先順位を付けることができる。任意の適切なステップが、個々のアプリケーションを分析するために使用される。
【００４１】
好ましい実施形態の追加の代替手段として、方法は、分散型コールコントローラーの容量を調整することＳ２４０を含む。ステップＳ２４０は、適切に容量要求を処理するために、電話ネットワークのアクティブなチャンネル数を変更する機能を果たす。ステップＳ２４０は、好ましくは、分散型コールコントローラーを操作することを含む、ステップＳ２１２と組み合わせて使用される。分散型コールコントローラーの調整は、オペレータが提供する容量の利用可能量を調整する。容量は、好ましくは、電話ネットワークのチャンネルの使用状況の管理に基づいて調整される。容量は、より好ましくは、Ｓ２３４および／またはＳ２３６のステップの予測と分析に基づいて調整されるが、代わりに、ステップＳ２３２、ステップＳ２３８、および／または、任意の適切な理由と協力して調整される。より多くの容量が必要な場合、同時チャンネルを処理してより多くののチャンネルを提供できる、ＣＰＵ、ＲＡＭ、ＤＩＳＫ等のようなより多くのリソースが、好ましくは、分散型の電話コントローラーに割り当てられていて、反対に少ない容量が必要とされるとき、リソースは、好ましくは、分散電話コントローラーから切り離される。容量の調整は、好ましくは、予想または予測された容量を処理するために行われます。電話ネットワークの静的容量は、代替的または追加的に、調整される。電話ネットワークとして、容量は一般的に柔軟性がない。電話ネットワークの容量の調整は、好ましくは、長期的（例えば、一月の月額ベーで）な容量ニーズ（例えば、一月の月額ベースで）のために作られている。多かれ少なかれ容量のシステムに任意の適切な調整を代わりに使用することができる。
【００４２】
４．電話ハードウェア間のコールを配布する方法
図７−８に示されているように、好ましい実施形態の電話ハードウェア間でコールを配信する方法３００は、コールリクエストをキューするステップＳ３１０、ロードバランシングのコールルーターを選択するステップＳ３２０、および、コールを選択されたコールルーターに接続するステップＳ３３０を含む。方法は、電話アプリケーションで使用されるリソースの使用のバランスを取る機能を果たす。この方法は、好ましくは、上述のものと実質的に同様のシステム上に実装されているが、代わりに任意の適切なシステムを使用することもできる。
【００４３】
コールリクエストのキューイングを含む、ステップＳ３１０は、必要なリソースがコールを処理できるようになるまで、コールリクエストを管理する機能を果たす。コールリクエストは、好ましくは、電話アプリケーション、コールルーター、電話デバイス、および／または、コールリクエストの任意の適切なソースによって、インスタンス化される。コールリクエストは、さらに、ＳＭＳまたはＭＭＳメッセージの要求である。コールリクエストは、好ましくは、発信される。着信コールは、好ましくは、発信リクエストよりも多くの緊急のコールリクエストとして認識され、着信コールはキューに登録されないが、代わりに利用可能なリソースに直接渡すことができる。また、着信コールリクエスト（コールセッションをイニシエートする）がキューされるが、着信コールはより即時性があるので、それらは好ましくは優先順位付けされ、あるいは、システムが着信コールがフェールする時間よりも短いショートキューイング時間を持たなければならない。着信コールは、代わりに、キューの先頭付近に配置するか、または、コールリクエストの高い優先順位のために適切な別の規則に従ってキュー中に配置する。同様に、同期発信コールのリクエストが高い優先順位でキューイングされることもある。同期コールは、ユーザーが遅延を気にしなくなるアプリケーションによって開始された新しいコールとは対照的に、別の呼び出し者が続行することを頼るコールである。コールリクエストは、好ましくは、スロットル、キャップ、リアルタイム緊急性（優先度）および／または任意の適切な要因に基づいたルールに従ってキュー中に並んでいる。
【００４４】
ロードバランシングのコールルーターを選択することを含む、ステップＳ３２０は、好ましくは、電話リソースクラスターの動作を最適化するためにコールを処理するコールルーターを識別する機能を果たす。選択されたコールルーターは、一般的に、もっとも負荷の少ないコールルーターであるが、代わりに、コスト、エネルギー使用量、処理能力、および／または任意の適切な変数を最適化するように選択することもできる。ステップＳ３２０は、さらに、コールルーターに付加的あるいは選択的に、他のハードウェアまたはソフトウェアのリソースに適用される。電話リソースクラスターのコールルーターは、ハードウェアおよび／またはソフトウェアの仕様に応じて可変の容量と性能を持つことができる。複数のコールルーター間のばらつきは、好ましくは、コールルーターを選択する際に考慮される。上記のものと実質的に類似したロードバランサーは、好ましくは、ステップＳ３２０を実装する構成要素であり、ステップＳ３２０を介して、任意の適切なデバイスによって実行される。ロードバランサーは、好ましくは、クラスターのリソースの割り当ておよび割り当て解除をすることができ、そのためリソースはＳ３２０のサブステップとして割当ておよび／または割り当てを解除することができる。リソースアロケーターは、好ましくは、コールルーター、ハードウェアリソースおよび／またはソフトウェアリソースの割当ておよび割り当て解除を実行することができる。リソースは、好ましくは、現在のまたは予測された利用に基づいて、割り当てまたは割り当て解除をするが、リソースが、代わりに、他のリソースの機能として割り当てまたは割り当て解除することもできる。例えば、一つのメディアの処理リソースは、すべての５つのコールルーターに対し割り当てることができる（例えば、動作）。ロードバランシングのコールルーターの選定は、好ましくは、分析システムからのデータを使用している。その結果、ロードバランシングのコールルーターを選択するステップは、将来の時点で負荷をバランスするコールルーターを選択することを含む。
【００４５】
選択したコールルーターにコールを接続することを含む、ステップＳ３３０は、特定のリソースへのコールの制御を渡す機能を果たす。発信コールの場合は、コールルーターは、好ましくは、指定された電話番号に電話ネットワークを介して接続する。着信コールの場合は、コールルーターは、好ましくは、特定の電話アプリケーション；固定電話、携帯電話、衛星電話、または、その他の適切なＰＳＴＮに接続されたデバイスなどのＰＳＴＮに接続されたデバイス；ボイスオーバーインターネットプロトコル（ＶＯＩＰ）の電話機、ＳＩＰデバイス、スカイプ、Ｇｔａｌｋあるいは他のインターネットアドレス可能な音声デバイスなどの非ＰＳＴＮデバイス；および／または、着信コールの番号に関連付けられている任意の適切なデバイス；に接続する。
【００４６】
好ましい実施形態の方法は、さらに、共有アプリケーションＳ３４０を有するネットワーキングコールルーターが含まれる。ステップＳ３４０は、複数のコールルーター間の通信を可能にする機能を果たす。これは、好ましくは、アプリケーションの機能が複数のリソース（例えば、複数のコールルーター）を介して配信される状況で、有用である。ネットワークは、好ましくは、コールルーター間でリソース共有を許す。コールルーターのオーディオチャンネルは、さらに、コールルーター間でミックスされ共有される。ＶＯＩＰチャンネルは、好ましくは、異なるコールルーターの音声をブリッジングするためのネットワークを介して形成される。例えば、電話会議では、異なるコールルータから複数のコールセッションのオーディオをブリッジングするネットワークを使用することができる。
【００４７】
好ましい実施形態の方法は、さらに、アプリケーションをサービスアプリケーションとの同期させることＳ３５０を含む。サービスアプリケーションは、コールルータークラスター上で分散するアプリケーションを監視し、アプリケーションの動作を調整する機能を果たす。サービスアプリケーションは、さらに、コールーター間で状態情報を共有するために使用されることがある。サービスアプリケーションは、好ましくは、上記のようなハングアップサービスや複数入力サービスのような特的の機能を提供する。任意の適切なアプリケーションは、入力収集、マルチダイアリング、コールの分割、コールのマージおよび任意の好適な特徴のようなサービスアプリケーションによって実装される。任意の数のサービスアプリケーションを使用することができる。
【００４８】
当業者が、前回の詳細な説明から、および、図面とクレームから認識するるように、修正及び変更は、以下の特許請求の範囲に記載された本発明の範囲から逸脱することなく、本発明の好ましい態様に行うことができる。
【技術分野】
【０００１】
関連する出願のクロスリファレンス
この出願は、２００９年３月２日提出の「複数ユーザーのための電話ネットワークを提供する方法」との名称の米国仮出願番号６１／１５６，７５８号の利益、２００９年１０月７日提出の「マルチテナント電話ネットワークのための方法およびシステム」との名称の米国仮出願番号６１／２４９，４９３号の利益、および、２０１０年１月１９日提出の「マルチテナント電話ネットワークのための方法およびシステム」との名称の米国仮出願番号６１／２９６，２７０号の利益をクレームし、この参照により本願発明に組み込まれる。
【０００２】
この出願は、２００９年４月２日提出の「電話セッションを処理するためのシステムおよび方法」との名称の先行する出願番号１２／４１７，６３０号に関連する。
【０００３】
本発明は、一般的には電話の技術分野に関連し、特に、電話の技術分野における新規で有益なマルチテナント電話ネットワークに関するものである。
【背景技術】
【０００４】
電話ネットワークは、電話のセッションまたは接続のためのチャンネル構造を歴史的に使用している。このチャンネル構造は電話の歴史の中で創設されたもので；通話するために物理的に接続する必要がある物理的に有線の接続またはチャンネルである。チャンネルの概念は今なお現在でも使用されている。電話ネットワークの加入者は、基本的に、チャンネル毎に支払うことを通常要求される。構内交換機（ＰＢＸ）、コールセンター、または、同様の電話によるアプリケーションを利用しようとするユーザーは、通常サービスに加入し、それらの技術およびそれらの技術のみを利用可能とするチャンネルの固定された容量を有している。チャンネルの容量は契約の一部であるため、そのチャンネルの容量を超えることはできない（もし超えると通話または電話セッションが失敗する）。多くのアプリケーションでは、まれに全容量の使用状況を確認するので、ユーザーはしばしば一般的に使用されているよりも多くのチャンネルを支払う。
【０００５】
電話ネットワークのチャンネルを基本とする構造とは対照的に、ボイスオーバーインターネットプロトコル（ＶＯＩＰ）、インターネットに基づくアプリケーション、および、インターネットに基づく電話アプリケーションのような、パケットに基づくネットワークの改革が近年立ち上がってきた。電話の技術分野に訪れた新しい技術により、ハードウェアおよびソフトウェアの容量要求を取り扱うためのユニークなチャレンジがある。専用のハードウェアおよびソフトウェアは、しばしば、電話呼び出し中にタスクを実行し、あるいは、電話呼び出し者をインターネットに基づくアプリケーションに接続するための中間システムとしても動作する。電話システムは、通常、ウェブサイトに基づくアプリケーションよりもより高い性能を期待されている。ウェブサイトのユーザーは情報をロードしたり処理したりするのに時間がかかることを予想する一方、電話呼び出し者は電話中における遅延や反応しない通話にフラストレーションを示す。また、電話アプリケーションは、いまだに、拡張性に対し別のバリアを付加する、チャンネルに基づく電話システムに依存している。電話ネットワーク、および、現存する電話アプリケーションソフトウェアおよびハードウェアのアーキテクチャは、電話アプリケーション分野の増大する容量を制限する。そのため、電話の技術分野において、新規で有益なマルチテナント電話ネットワークを創設する必要がある。この発明はそのような新規で有益なシステムおよび方法を提供する。
【発明の概要】
【０００６】
本発明は、電話アプリケーションのためのマルチテナント電話ネットワークを提供するシステムおよび方法を提供する。本発明の一つの目的は、複数ユーザー環境において共用リソースの使用を取り扱うこと、および、容量の要求を満たすために動的にリソースを見積もることである。この目的の関連する効果は、各ユーザーが利用可能な明らかなリソースの数の全体がマルチテナント電話ネットワークを実行するために使用される実際のリソースの数よりも大きいことである。本発明の他の目的は、容量の要求を満たすように処理および記録のリソースを提供することにより、節電のために電源をオフとしたアプリケーションのための他の使用されていないリソースを開放することにより、あるいは、他の好適な機能により、電話プラットホームのリソースを効率的に使用することである。本発明の他の目的は、ユーザーのアプリケーションに対して透明な電話リソースのクラスターを使用することである。この透明性は、アプリケーションの操作が複数の電話サービスリソース間で配信されて異なるチャンネルに複数の電話セッションを含む状況にもかかわらず、好ましくは保存される。本発明のこれらの目的および他の目的は、マルチテナント電話ネットワークのためのシステム、マルチテナント電話ネットワークを操作する方法、動的電話ネットワークを操作する方法、および、電話ハードウェア間のコールを配信する方法を含む、本発明の好適な実施例によって達成され、それぞれは以下のセッションで記載される。
【図面の簡単な説明】
【０００７】
【図１】図１はマルチテナント電話ネットワークを操作する方法のための好適な実施例を示すフローチャートである。
【図２】図２はマルチテナント電話ネットワークのためのシステムの好適な実施例を示す線図である。
【図３】図３はマルチテナント電話ネットワークのためのシステムの好適な実施例を示す線図である。
【図４】図４はマルチテナント電話ネットワークのためのシステムの好適な実施例を示す線図である。
【図５】図５は着信転送のクラスターを使用する本発明の好適な実施例を示す線図である。
【図６】図６は動的電話ネットワークを操作する方法のための本発明の好適な実施例のフローチャートである。
【図７】図７は電話会議を実行する本発明の好適な実施例のフローチャートである。
【図８】図８は着信コールを受け取る本発明の好適な実施例のフローチャートである。
【発明を実施するための形態】
【０００８】
本発明の好適な実施例の以下の記載は、本発明をこれらの好適な実施例に限定することを意図しているものではなく、当業者がこの発明を作製して使用することを可能にすることを意図している。
【０００９】
１．マルチテナント電話ネットワークのためのシステム
図２−４に示すように、好適な実施例のシステム１００は、電話リソースクラスター１１０、呼び出しキュー１２０、解析システム１３０、リソースアロケーター１４０および複数の電話ネットワークチャンネル１５０を含む。電話リソース１１０のクラスターは、複数の割り付けられた電話ネットワークチャンネル１５２および／または複数のコールルーター、ロードバランサーのような複数の電話リソース１１２を好適には含み、さらにサービスアプリケーションを付加的に含む。システムはネットワークおよびシステムリソースの使用を配信して容量の要求に基づきシステムを動的に調整するよう機能する。
【００１０】
電話リソースクラスター１１０（または「クラスター」）は、少なくとも一つのリソースがユーザーによって要求された電話コールセッションを生成するために使用される、リソースの拡張性（拡大および／または収縮）集合として機能する。クラスター１１０は、好ましくは、処理および／または記録の要求を満たすよう動的に調整できる、ハードウェアおよび／またはソフトウェアの集合である。クラスター１１０は、好ましくは、ハードウェアの割付および使用の取り扱いがシステムによって内部で扱われる、外部装置に対するハードウェアおよび／またはソフトウェアのクラウドのように見える。図２に示されたある変形例において、電話リソースクラスター１１０は、好ましくは、コールセッションを確立すること、電話インストラクションをコール動作に変換すること、コールを収縮すること、またはコールを導くことのような、コールリクエストまたはコールセッションのための中間で処理するタスクを提供する機能を果たす、複数の電話リソース１１２である。図３に示された他の変形例において、電話リソースクラスター１１０は、好ましくは、割り付けられた電話ネットワークチャンネル１５２が、コールセッションに対し利用可能なチャンネルとして活性化されあるいは指定された割り付けられた電話ネットワークチャンネル１５２のチャンネルである、割り付けられた電話ネットワークチャンネル１５２に対する複数の接続である。
【００１１】
電話リソース１１２は、好ましくは、特定の電話処理タスクに対し供給されるソフトウェアまたはハードウェアリソースである。好ましくは、複数の電話リソース１１２が存在し、異なる専用のタスクを実行する複数のタイプの電話リソースとして存在することもできる。電話リソース１１２は、好ましくは、コンピュータ処理装置および／またはコンピュータ記憶装置を含む。電話リソース１１２は、物理的なハードウェア装置、仮想マシーン、ソフトウェアプログラム／ルーチン、および／または、電話リソース１１２の処理および記録操作を提供する如何なる好適な組合せとすることができる。ある場合には、電話リソース１１２は専用のハードウェアまたはソフトウェアを含むことができる。電話リソース１１２は処理能力またはデータストレージとして基本的な機能性をシェアしているため、電話リソース１１２のコアとなる機能性は、電話リソース１１２が異なる専用のタスクを実行するように、再供給される。リソースアロケーター１４０（およびより具体的にはロードバランサー１４２）は、好ましくは、電話リソース１１２を再供給し、リソースクラスター１１０の異なる部分として動作する。例えば、クラスターは複数のテキスト・トゥ・スピーチサービスおよび複数のコールルーターを含むが、ある時点で、達成されるテキスト・トゥ・スピーチ操作の数が減少し、電話アプリケーションの数が増加し、それによりテキスト・トゥ・スピーチサーバーは、好ましくは、コールルーチンとして再供給される。変形例において、複数の電話リソース１１２（すなわちクラスター１１０）が、好ましくは、複数のコールルーター１１４を含む。付加的にあるいは選択的に、クラスターは、メディア処理システム、転写システム、テキスト・トゥ・スピーチシステム、コールレコーダー、コールデータストレージなどの他のハードウェア装置やソフトウェアインスタンス、あるいは、適切なハードウェア（物理的装置または仮想マシーン）やソフトウェアを含む。クラスターのためのリソースアロケーター１４０は、好ましくは、タスク処理の配信および複数の電話リソース１１２の操作を取り扱うロードバランサー１４２を含む。また、クラスターは、複数のリソースを使用することの結果として発生する問題を協同して解くことができるサービスアプリケーションおよび／またはコールルーターネットワークを含むことができる。
【００１２】
複数のコールルーター１１４は、電話装置からコールを開始または受け取り、処理に関連する電話アプリケーションを提供する機能を果たす。好ましくは、コールルーターが、コールリクエストのソースであるアプリケーションサーバーに接続する。複数のコールルーター１１４は、好ましくは、容量の要求に従って調整することができるコールルーター１１４の動的な数である。上述したように、ほかの実施例において、複数のコールルーター１１４は、メディア処理システム、転写システム、テキスト・トゥ・スピーチシステムなどの他の好適な電話ハードウェアやソフトウェアリソース、または、電話アプリケーションで使用される他の特別なハードウェアやソフトウェアリソース、によって置き換えることができ、または、それらと組み合わせることができる。ある例において、複数の転写ハードウェアまたは仮想化されたリソースを、図５に示すように、電話コールを転写するためのコールルーターの位置で使用することができる。また、コールルーター１１４を、メディア処理システム、転写システム、テキスト・トゥ・スピーチシステムとして、あるいは、好適な処理のために、再供給することができ、同様に、いかなるプロセッサーもコールルーターとして機能するように再供給することができる。ハードウェアやソフトウェアのリソースの数を、付加的にあるいは選択的に、割り当てたりあるいは割り当てを解除することができ、それにより好適な組合せのリソースの望ましい数をいつでも操作することができる。ハードウェアインスタンスは、割り当てを解除する際、電源を切ること、エネルギーセービングモードに入ること、あるいは、好ましい状態に置かれることである。電話リソース１１２は、付加的にあるいは選択的に、（アマゾンによって運営されるエラスティック・コンピュート・クラウドのような外部パーティーによって運営される）クラウドコンピューティングプラットホーム上での仮想化されたリソースとして操作され得る。コールルーター１１４のような電話リソース１１２が割り当てを解除するとき、仮想化されたリソースを、クラウドコンピューティングプラットホームの他の顧客に与えたり、リソースの仮想化あるいは他の好適な処理を中止することで、ベンダーに戻すことができる。ソフトウェアインスタンスは、割り当てを解除する際、中止あるいは削除される。コールルーターのメディア処理システムに対する比のようなリソースの比は、調整されあるいは維持される。
【００１３】
コールルーター１１４は、好ましくは、電話交換網（ＰＳＴＮ）装置にＰＳＴＮネットワークを介して接続され、地上の通信線、携帯電話、衛星電話あるいは他の好適なＰＳＴＮ接続装置などのＰＳＴＮ接続装置から、あるいは、ボイスオーバーインターネットプロトコル（ＶＯＩＰ）電話、ＳＩＰ電話、スカイプ、Ｇトーク、他のインターネットでアドレス可能なボイス装置などの非ＰＳＴＮ装置から、コールを受け取りまたはコールを発生することができる。そのため、コールルーター１１２は、好適には、分散型の電話コントローラーの電話ネットワークへの接続を生成することができる。コールルーター１１２は、選択的にあるいは付加的に、ＳＭＳ（ショート・メッセージ・サービス）やＭＭＳ（マルチ・メディア・メッセージング）などの電話メッセージングとともに使用するためのメッセージルーターとして機能し、あるいは、そのようなメッセージルーターを含むことができる。コールルーター１１２は、好ましくは、メッセージングネットワークに接続され、ＳＭＳ／ＭＭＳネットワーク装置、携帯電話、コンピュータ、スマートフォン、あるいは、いかなる好適なＳＭＳ／ＭＭＳネットワーク装置から、メッセージを受け取ることができ、または、メッセージを送ることができる。コールルーター１１２は、また、テキストメッセージ、マルチメディアメッセージ、ｅメール、ファックスおよび他の好適なＰＳＴＮ互換性のあるコミュニケーションメッセージを送ったり受けたりすることができる。コールルーター１１２は、好ましくは、アプリケーションレイヤープロトコルを使用して、より好ましくは、ＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）やセキュアーＨＴＴＰＳ（ハイパーテキスト・トランスファー・プロトコル・セキュアー）プロトコルを使用して、アプリケーションサーバーとコミュニケーションすることができる。アプリケーションサーバーは、好ましくは、電話の相互作用のためのコールルーターによって使用される、電話アプリケーション、サウンドファイル、テキストファイル、データベース、および／または、好適なメディアリソースやファイルのホストとなる。コールルーター１１２は、また、コールルーターリソースを発生することができる。コールルーターリソースは、好ましくは、コールルーターＡＰＩを介してアプリケーションサーバーおよび（他のコールルーターなどの）他の装置によってアクセス可能である。コールルーターリソースは、コールルーターメタデータ、内部コールルーター状態、または、コールルーターによって使用された所定のリソース状態のアドレス可能な表現としての機能を果たす。例えば、コールルーター１１４はコールを記録し、コールルーターリソースとして記録を保存することができる。
【００１４】
また、好適な実施例としての電話リソースクラスター１１０は、各種のコールルーター１１４、ハードウェアリソース、および／または、ソフトウェアリソースを通って配信されたアプリケーションの機能性を調整するメッセージング要素として機能を果たすサービスアプリケーション１１６を含むことができる。サービスアプリケーション１１６は、好ましくは、アプリケーションの操作がクラスター１１０の各種のハードウェアおよびソフトウェアの間に配信されているため、アプリケーションの通常の操作が阻止された時に使用される、内部リソースである。サービスアプリケーション１１６は、好ましくは、メッセージが（他のコールルーター１１４などの）特定の目的地に供給される信頼性のあるメッセージングを提供する、メッセージングサービスである。サービスアプリケーション１１６は、選択的に、メッセージが受け取られたときメッセージを誰が受け取ったかを知ることなくメッセージをアナウンスする、放送メッセージングを提供することができる。第１の例として、ハングアップサービスアプリケーション１１６は、異なるコールルーター１１４におけるハンギングアップコールセッションを調整するために使用される。ハングアップサービスは、好ましくは、例えばアプリケーションが複数のナンバーをダイアルしたいが、コールの一つに答えると全ての答えなかったコールがハングアップする時、電話の発信をキャンセルするために、適切なコールルーター１１４とコミュニケーションをとるために使用される。第２の例として、多重入力サービスは、多数の電話装置からのコマンドを収集して入力することができる。そのため、デュアルトーンマルチ周波数（ＤＴＭＦ）の入力または音声コマンドは、いかなるコーラーによっても発生され、コールがクラスター内において多重コールルーター１１４を通して配信されたとしても、アプリケーションとコミュニケーションをとることができる。これは、電話会議においてアプリケーションを実現するために使用される。このようにして、電話アプリケーションは、クラスター内で配信される処理およびコールの取り扱いを積極的に説明する必要はなく、クラスターのハードウェアおよびソフトウェアのリソースは、好ましくは、内部サービスアプリケーション１１６のために外部アプリケーションに対して単一体のように見える。
【００１５】
また、好適な実施例の電話リソースクラスター１１０は、種々のコールルーター１１４の間のコミュニケーションおよびシンクロナイゼーションのレベルを許可するよう機能する、コールルーターネットワーク１１８を含むことができる。コールルーターネットワーク１１８は、付加的にあるいは選択的に、他のハードウェアまたはソフトウェアリソースに適用される。コールルーターネットワーク１１８は、好ましくは、シェアーしたリソースにアクセスするために、あるいは、コミュニケーションチャンネルとして、使用される。ある典型的なアプリケーションにおいて、インターネットプロトコル（ＶＯＩＰ）接続を介しての音声は、種々のコールルーターからの音声をミックスするためのコールルーターネットワーク１１８を通じて達成される。ＶＯＩＰ接続は、好ましくは、多重コールルーター１１４を通じて配信された電話会議を実行するために使用される。他の例として、コールルーターネットワーク１１８は、また、コールルーターからリアルタイムのインターネットオーディオストリームへと音声をストリーミングするために使用される。他の例として、コールルーターネットワーク１１８は、全てのルーターリソースにアクセスするためにコールルーターＡＰＩを使用する他の電話リソース１１２上のデータにアクセスするために使用される。サービスアプリケーション１１６およびコールルーターネットワーク１１８は、また、クラスター内で配信されたアプリケーションを同期させるために協同することができる。
【００１６】
好ましい実施例のコールキュー１２０は、コールリクエストのスタックを取り扱う機能を果たす。コールキュー１２０は、好ましくは、必要なリソースをサービスされないか割り当てられなかった外部へ送信されるコールリクエストのリストである。リクエストは、好ましくは、ネットワーク１５０の現在の容量および電話リソースクラスター１１０に対し好ましい料金でサービスされる。サービスされる料金は、選択的に、分散型電話コントローラー１４４の容量、電話リソースクラスター１１０、および／または、キュー１２０におけるリクエストの数に従って調整される。（電話アプリケーションによって実施される一例のような）コールリクエストは、好ましくは、容量が超過したときコールキュー１２０となり、あるいは、選択的に、全てのリクエストに対しコールキュー１２０とするか、他の好適な規則に基づいて行われる。
【００１７】
ある変形例において、アプリケーションは、好ましくは、ユーザーの限界、特に、インターコールリクエスト料金の限界（スロットル）および全体の限界（キャップ）と関連している。スロットルおよびキャップは、好ましくは、コールキューにおけるリクエストの位置を決定するために使用される。限界は、選択的に、アカウント、電話番号または好適な実体ある物に割り付けられる。電話メッセージ（すなわちＳＭＳまたはＭＭＳ）は、またコールキューとなるコールリクエストの一つの変形例である。入信および発信する電話メッセージは、好ましくは、入信したメッセージは入信したコールとは異なり即座の対応を必要としないため、キューされる。ＳＭＳメッセージは、好ましくは、リクエストがキューでサービスされた後に送られる。ＳＭＳメッセージおよび／またはＭＭＳメッセージは、選択的に、専用のメッセージキューによりキューされる。ＳＭＳメッセージは、リクエストにより変化する料金制限（スロットル）および全体の限界（キャップ）を有することができる。ユーザーからいかなる料金でも受け取られたリクエストは、好ましくは、スロットルに従ってコールキューにおいて時間間隔を有している。好ましくは、アプリケーションからのコールリクエスト間で実行されるキューが存在する。異なるユーザーのリクエストは、好ましくは、図６に示されるように、時差を持ってまたは交互にキュー状態にオーダーされるが、選択的に、ユーザーは、サービスプラン、先着順のポリシー、コールリクエストのタイプ、および／または、いかなる好適なポリシーに基づき優先順位を有することができる。キャップは、好ましくは、ユーザーが所定の時間内に行うことができるリクエストの総数上での制限である。ユーザーは、アプリケーションが電話ネットワーク１５０または電話リソースクラスター１１０の使用を常に不当に独占することを防止する機能を果たすコールキュー１２０の取り扱い、時間間隔、および／または、順序付けを制限する。また、アプリケーションは、出来るだけ早くあるいは将来のある時点で（例えば、ユーザーがコールまたは後のコールをスケジュールしている場合）、電話リソース１１２に対するアクセスをリクエストすることができる。付加的にあるいは選択的に、ユーザーの制限は、アプリケーションの必要性に従って調整されまたはセットされる。アプリケーションは、ユーザーのアプリケーションの特性または特徴に基づいた特別の要求を有する。ユーザーの制限は、好ましくは、ユーザーが選択する契約および／または価格決定モデルに従って、あるいは、他の好適な手段によって、セットされる。
【００１８】
他の変形例において、コールキュー１２０は一人のユーザーのリクエスト専用となる。この変形例において、好ましくは各ユーザーに対しコールキュー１２０を準備する。電話メッセージリクエストは、好ましくは、各電話番号に対しキューを有する。ユーザーのリクエストは、好ましくは、常に個別に割り当てられたキュー１２０に付加される。各キューは、好ましくは、（リソース限界、情報管理用限界などの）ユーザー毎の限界を考慮したスケジュールに従ってサービスされる（すなわち）待機解除される。言い換えれば、待機解除は、複数のコールキュー１２０の間で交互に起きる。また、個々に割り当てられたコールキューは、特定のリソースのためであり、キュー解除は、好ましくは、特定のリソースのキュー解除料金に従って起こる。キュー解除料金は、好ましくは、リソースの容量に関連するが、選択的に好適ないかなる基準にも基づくことができる。他のキューイングの変形例と同様に、キューイングは、他に、不規則に実施する、総当たりで実施する、公正なキューイングで実施する、重みを付けた公正なキューイングで実施する、および／または、いかなる好適な手順で実施する、などの好適なキューイング方法に従って起こる。アカウント／電話番号に基づくキューイングの他の例として、コールまたはメッセージのリクエストは、時間、優先順位、使用歴、または、他の好適な性状に基づいてキューされる。また、個人別に割り当てられたコールキュー（またはメッセージキュー）１２０の待機時間解除を調整するために使用されるコントロールキューがある。
【００１９】
上述したように、コールキュー１２０は電話メッセージ（例えばＳＭＳまたはＭＭＳメッセージ）を取り扱うための追加あるいは別のシステムを含むことができ、ＳＭＳメッセージは、好ましくは、サービス料金および制限について付加的な制限を有している。ＳＭＳメッセージは、好ましくは、各種のユーザーとの電話ネットワークアクセスをシェアするためにキューするだけでなく、料金を一人のユーザーからのＳＭＳメッセージがスパムとして認定されて料金限度になることを防ぐよう設定することが好ましい。電話メッセージのためのコールキュー１２０は、コントロールキューおよび電話番号キューの少なくとも２つのタイプのキューを含んでいる。電話番号キューは、好ましくは、ユーザーが送ろうとする電話メッセージに対する一人のユーザーの個人的なキューとしての機能を果たし、コントロールキューは、コールキュー１２０として上述した多数ユーザーのキューと実質的に近似した機能を果たす。個人に割り当てられたコールキュー１２０は、コントロールキュー無しで使用されることもでき、個人に割り当てられたコールキュー１２０は、電話番号のアカウントあるいは他の好適な割り当て方法に基づくこともできる。コントロールキューおよび電話番号キューは、好ましくは、特定のアプリケーションのためのメッセージのキューイングと複数のメッセージとを分離する機能を果たす。ＳＭＳメッセージ（テキスト）またはＭＭＳメッセージ（マルチメディア）のコンテンツは、好ましくは、直接的にコールキューに記憶されず、ＳＭＳメッセージのコンテンツに対するリファレンスを記憶することが好ましい。これはキューに対する負荷を減少させる機能を果たす。ＳＭＳ／ＭＭＳコンテンツは、好ましくは、キューされたリファレンスがサービスされた時に、記憶されアクセスされる。
【００２０】
キューポッパー１２２（例えばキュー解除装置）は、好ましくは、コールキューからのサービスのためにコールリクエストを選択する機能を果たすソフトウェアまたはハードウェアのメカニズムである。キューポッパー１２２は、好ましくは、好ましい料金でコールリクエストを選択するが、キューポッパー１２２は、その代わりに、容量または利用可能なリソースあるいはそれらの組合せに従ってコールリクエストを選択することもできる。付加的に、コールキュー１２０からのコールリクエストを同時に選択する機能を果たす複数のキューポッパー１２２が存在する。コールポッパー１２２の数は可変である。付加的あるいは特別のキューポッパー１２２を付加的なＳＭＳコールリクエストのために使用することもできる。コールキュー１２０、キューポッパー１２２、または、好適な組合せは、好ましくは、コールリクエストのスロットリング（あるいはサービス料金）をコントロールするために使用される。スロッティングは、電話番号ごとに、アカウントごとに（マルチテナントアプリケーションと同様に）、および／または、コール／メッセージ属性に従って、実行される。
【００２１】
好ましい実施例の解析システム１３０は、リソース要求を予測するためにシステムを解析する機能を果たす。解析システム１３０は、好ましくは、システムの複数の側面をモニターする。解析システム１３０は、ネットワークまたはハードウェアの操作レベルまたはトレンド（増加または減少）などの現在の容量；容量中の相関（例えばパターン検知）を見つけるために記録されたデータのような使用履歴；キューの長さおよびキューの入力待ち時間；アプリケーションの過去の使用からの履歴パターンなどのアプリケーションの解析；および／または任意の適切な側面、をモニターすることができる。必要な容量のパターンは、好ましくは、時刻、曜日、年間パターン、（あるユーザーに必要な容量が増加すると、他のユーザーに必要な容量の増加を示すなどの）使用パターン、コール位置、コールのコール時間、および／または、他の好適な指標に関連して見つかる。解析システム１３０は、好ましくは、電話ネットワークチャンネルに対する入信および発信容量の区別をする。解析システムは、好ましくは、リソースアロケーター１４０、分散型電話コントローラー１４４、負荷バランサー１４２、および／または、付加的なコールキュー１２０に対するデータを発生する。解析システムからの予測またはデータは、さらに、分散型コールコントローラーの容量のプロビジョニングのために、電話ネットワークの静的容量、コールルーターの数、クラスター内のハードウェアまたはソフトウェア、および／または、キューマネージメントのパラメータの容量のプランニングのために、使用される。解析システム１３０は、好ましくは、負荷の予測値および実証値を比較し、システムのリソースにおける変動を補正するために使用されるデータを提供する。
【００２２】
好ましい実施例におけるリソースアロケーター１４０は、電話クラスター１１０の操作を拡張および管理する機能を果たす。リソースアロケーター１４０は、付加的および好適に、クラスター１１０の電話リソース１１２を再供給し、新しい電話リソース１１２を割り当て、電話リソースおよび／または他の好適な割り当てプロセスを再割り当てする。リソースアロケーター１４０は、さらに、コールキューのプロビジョニングおよびシステムの他の装置をコントロールする。リソースアロケーター１４０は、好ましくは、リソースのプロビジョニングおよび操作を決定する際に解析システム１３０のデータを使用する。このリソースアロケーター１４０は、解析システム１３０からの情報を用いて、所望の電話リソース１１２の容量を予測することが好ましい。リソースアロケーター１４０は、好ましくは、どのくらいのハードウェア（物理的または仮想的）またはソフトウェアリソースが操作のために必要なのかを決定するために、予測した容量要求を使用し、リソースアロケーターは、好ましくは、必要に応じて電話リソース１１２（例えば、コールルーターおよび／または他のハードウェアまたはソフトウェアリソース）を、割り当てたり、再割り当てしたり、または、再供給する。リソースアロケーター１４０は、さらに、開始時間、操作コスト、または、特的の時間で割り当てられたリソースの数および比を決定する際の、ハードウェアおよびソフトウェアのリソースのパラメータを使用する。リソースアロケーター１４０は、また好ましくは、現在利用可能なリソースの量の経過をたどり、デキューアー、ロードバランサーなどを含む、他のシステムコンポーネントに利用可能なリソース利用可能性の情報を作り出す。そのようなリソース利用可能性の情報は、好ましくは、システムコンポーネントの操作を調整するために他のシステムコンポーネントによっても使用される。リソースアロケーター１５０は、好ましくは、リソースをモニターし、リアルタイムでリソースを再供給する。
【００２３】
好ましい実施例のリソースアロケーター１４０は、好ましくは、コールルーターおよび他のハードウェア内の処理タスクを配信する機能を果たすロードバランサー１４２を含む。好ましい実施例のロードバランサー１４２は、好ましくは、処理タスクの配信を最適化し、複数のコールルーター１１４は最適なレベルであるいは最適なレベルの近傍で操作される。コールルーター１１４の操作は、パフォーマンス、エネルギーコスト、および／または、いかなる好適な状態に対して最適化される。ロードバランサー１４２は、好ましくは、タスク（例えば、コールリクエスト／セッションのサービス）をタスクが生成されるようにコールルーター１４２（または電話リソース１１２）に割り当てる。タスクは、好ましくは、電話アプリケーションの操作であるが、コールリクエストまたはコールセッションとすることもできる。ある例において、１００個のコールルーター１１４は１００個の電話アプリケーションに対するコールルータータスクを提供する。第２の例において、１００個のコールルーター１１４は、それぞれ、１００人の参加者の電話会議アプリケーションのように、１つの電話アプリケーションと関連した単一のコールセッションを取り扱うことができる。リソースアロケーター１４０は、好ましくは、ロードバランサー１４２にシステムリソースの現在のステータス（リソースの負荷、リソースの数など）に関し通知を送る。ロード１４２は、リソースアロケーター１４０によって供給されるデータに基づき、ロードバランスされるアプリケーションの要求に適合する現在利用可能で動作中のリソースに対しリクエストを配信する。
【００２４】
好ましい実施例のリソースアロケーター１４０は、システムによる電話ネットワーク１５０の使用および操作をコントロールする機能を果たす分散型コールコントローラー１４４を含む。分散型コールコントローラーは、好ましくは、複数の電話リソースによって電話ネットワークチャンネル１５０のシェアーされた使用を取り扱う。分散型コールコントローラー１４４は、選択的には、多重ネットワークのプロバイダーまたはキャリアーが使用されたときには、多重電話ネットワークのサブセットとすることもできる。分散型コールコントローラー１４４の操作は、好ましくは、電話ネットワーク１５０の現在の容量リクエストに対し割り当てられたチャンネルの数を操作する機能を果たす。割り当てられたチャンネルは、好ましくは、使用中か使用のために準備されている利用可能な静的チャンネル容量内のチャンネルである。分散型コールコントローラーは、好ましくは、常に静的チャンネル容量未満または同じ容量を有している。分散型コールコントローラー１５０の容量は、好ましくは、電話ネットワークの多くのリソースをコールコントローラーに割り当てることによって増加し、分散型コールコントローラー１４４の容量は、好ましくは、電話ネットワークのリソースを再割り当てすることによって減少する。一例として、商品ハードウェアノードを、高容量要求の間電話ソフトウェアスタックを実行するために、電話ネットワークに付加することもできる。分散型コールコントローラー１４４は、好ましくは、望ましい容量要求を予想しまたは要求に応答するために、解析システム１３０を使用する。電話ネットワーク１５０は、また、コールを受信し、コールを発信し、その両者を個別に行うために使用できる、入信チャンネル、配信チャンネル、および、両方向通信チャンネルに分割される。電話ネットワーク１５０は、さらに、ＳＭＳまたはＭＭＳの入信および配信チャンネルを含むことができる。分散型コールコントローラー１４４は、好ましくは、予想した使用に従ってチャンネルのタイプの使用を取り扱う。両方向のチャンネルは、好ましくは、容量要求にフィレキシブルに対応するために使用される。一例において、入信コールロード多くなると予想されるときは、配信コールは、好ましくは、入信コールにに多くの容量をあてるように、配信チャンネルに向けられる。分散型コールコントローラー１４４は、また、ネットワークプロバイダーからの予約や契約に従って、割り当てられたチャンネルの数および使用を取り扱うことができる。チャンネルは、割り当てまたは再割り当て操作に使用され、大口価格のスレッシュホールドまたは他のネットワークのコンディションを満たすことを保証する。
【００２５】
チャンネル１５０の静的数を有する電話ネットワークは、好ましくは、ユーザーに電話ネットワークのアクセスを提供するための基本インフラである。電話セッションは、好ましくは、電話ネットワークを通じてコミュニケーションをとることができ、電話セッションは、好ましくは、電話音声セッションおよび／またはテキスト／メディアメッセージング（電話メッセージング）を含む。チャンネル静的数は、好ましくは、同時にサポートされる同時に生じる電話セッションまたはコールの全数である。チャンネルの数は、典型的には、特定のキャリアまたはネットワークに利用可能な相互接続の数によって制限される。電話ネットワーク１５０は、あるいは、複数のキャリアまたはネットワークプロバイダーまたは公衆電話交換網から構成することもできるが、複数のキャリアまたはネットワークは、好ましくは、１つの電話ネットワークとして扱われたり取り扱われたりする。チャンネルの静的数は、好ましくは、一時期のセット数（通常電話会社との契約に基づく）であり、その数は、好ましくは、十分な容量を提供するために十分大きい。チャンネルの静的数は、好ましくは、ネットワークの容量および他のネットワークと接続する電話ネットワークの能力を決定する。電話ネットワークの操作は、好ましくは、アプリケーションを電話ネットワークのチャンネルにアクセスさせることによって扱われる。電話ネットワークは、常に使用されない所定数のチャンネルを有している。ある変形例において、電話ネットワークは、また、未使用モードにおいて未使用のチャンネルを操作することができる。未使用モードは、完全または部分ハードウェアパワーダウンモード、ハードウェアスリープモード、（逆効果も与えずに好ましくは中断することができる重要でないユーザーにとっての）二次使用、および／または、他の好適な方法である。未使用モードは、操作コストを減少させる機能、および／または、未使用容量のユーティリティを最大化する機能、を果たす。電話ネットワークチャンネル１５０は、好ましくは、公衆交換電話網（ＰＳＴＮ）接続であるが、別の例として、セッション・イニシエーション・プロトコル（ＳＩＰ）トランクス、あるいは、電話装置との電話ネットワーク接続を創造するいかなる好適な装置でもある。
【００２６】
２．マルチテナント電話ネットワークを操作する方法
図１に示すように、好ましい実施例におけるマルチテナント電話ネットワークを操作する方法は、複数ユーザーの電話リソースＳ１１０に対するコールリクエストを多重化する工程、電話リソースＳ１３０を介してコールリクエストから第１のコールセッションを生成する工程、および、電話チャンネルＳ１４０に対する複数の付加的なコールセッションとそのコールセッションとを多重化する工程を含む。方法１００’は、リソースインテンシブな電話アプリケーションに対し、効果的で拡張可能なネットワークシステムを生成する機能を果たす。電話リソースは、好ましくは、電話リソースクラスターの部分である。電話リソースクラスターは、好ましくは、ネットワーク負荷の広いスペクトラムを扱う能力により、マルチテナント電話ネットワークを使用するために、操作コストを減少させて各種のアプリケーションの使用を許可する機能を果たす、即時キャパシティ要求を満たすよう増減する。さらに、方法１００’は、リソース（例えば電話リソース）をシェアーする種々のマルチユーザーの間に分配される、電話アプリケーションの操作を許可する機能を果たし、電話アプリケーションの特定の目的はマルチテナント電話ネットワークによって制限されない。好ましい実施例における方法１００’は、好ましくは、上述したシステムによって実行されるが、他の方法として、いかなる好適なシステムによっても実行することができる。
【００２７】
電話リソースに対する複数のユーザーのコールリクエストを多重化するステップＳ１１０は、複数のユーザー間における電話リソースの使用をシェアーする機能を果たす。単一の電話リソースは、好ましくは、複数のユーザー／アプリケーションの間でシェアーされる。多重化は、好ましくは、コールリクエストが交互に電話リソースに送られる、時分割多重の形態で起こる。時分割多重化は、好ましくは、完全なコールセッションまたはプロセスの完遂に基づく。言い換えると、ユーザーは、電話リソースを使用してコールセッションの生成およびアプリケーションの実行を交代に行う。例えば、第１の顧客が電話リソースによってサービスさえるコールリクエストを実行している場合、そのコールリクエストのコールセッションの完遂により、第２の顧客が同じ電話リソースによってサービスされるコールリクエストを行うことができる。コールリクエストは、好ましくは、ユーザーからより具体的には外部サーバー上に在駐する電話アプリケーションから、受け取られるが、別の例では、コールリクエストはいかなる好適なソースからも送られる。コールリクエストは、好ましくは、パケットに基づくコミュニケーションチャンネル、言い換えると、無指向性のコミュニケーションチャンネルを通って、受け取られる。変形例において、コールリクエストは、好ましくは、ＨＴＴＰまたはＨＴＴＰＳメッセージとして受け取られるが、他の例では、いかなる好適なアプリケーションコミュニケーションプロトコルを介して受け取られることもできる。ステップＳ１１０は、さらに、入信するコールリクエストをゲートコントロールするかそれに優先順位を付ける機能を果たす、ユーザーＳ１１２のコールリクエストをキューイングする工程を含む。コールキューは、好ましくは、外部へ送信されるリクエストのために使用され、一方内部で受信されるリクエストは、好ましくは、すぐに扱われる（さもなければ、コールセッションはたぶん失敗する）。あるいは、内部で受信されるコールは、全てのサービスに対し、再生された「鳴り響く」音とともに、キューすることができ、一方、コールは、全てをサービスされるようにキューの状態に待機する。キューは、しかしながら、ＳＭＳメッセージおよびＭＭＳメッセージのような電話メッセージは最初の試みで受け取られなければ再び送られるため、内部で受信される電話メッセージのために使用される。コールキューは、好ましくは、複数ユーザーからの継続中のコールリクエストのリストである。付加的なキューは、付加的にあるいは選択的に、電話メッセージのために使用される。コールリクエストは、好ましくは、リソースに対するアクセルのバランスを取るような方法で、キュー内で順番が付けられる。各ユーザー（例えば、アカウント、アプリケーションまたは電話番号）には、好ましくは、内部コールリクエストの制限（スロットル）および特定の時間内で成されるコールリクエストの最大数における制限（キャップ）を割り当てられる。コールリクエストは、好ましくは、電話リソースクラスターの現在の負荷に基づきコールを選択する装置（すなわち、キューポッパー）によって、特定の料金でのサービスのために選択される。キューは、上述したような任意の好適な変形例によって選択的に操作される。キューは各ユーザーまたは電話番号に割り当てられている。キューすることは、選択的に、ランダム、総当たり、規則に従ったキュー、重み付けした規則に従ったキュー、実際のリソースの使用に基づく、および／または、任意の好適な手順などの任意の好適なキューイングの方法論に基づいて起こる。ロードバランサーは、好適には、最も少ない容量の電話リソースにコールリクエストを割り当てる。ロードバランサーおよびコールリクエストのキューは、好適には、協同して、上述したようにロードを割り当てる。
【００２８】
追加のステップとして、方法１００’は、十分に多重化するための電話リソースへの通話要求を電話リソースクラスターの容量を拡張するために機能する、電話リソースクラスターＳ１２０のリソースの供給を含む。ステップＳ１２０は、電話リソースクラスターの既存の電話リソースを再供給し、電話リソースクラスターに追加のリソースを割り当て、および／または、電話リソースクラスターのリソース割り当てを解除し、および／または、リアルタイムにリソースのある型から別のリソースを再割り当てすること、を含む。電話リソースクラスターは、好ましくは、上記のようなさまざまな機能や操作を行う電話リソースを複数有している。例えば、電話リソースクラスターは、コールルーター、転送システム、メディア処理システム、および音声合成システムを複数含めることができる。電話リソースは、好ましくは、第一の目的のため、コンピュータのプロセッサおよび／またはストレージリソースで構成されている。Ｓ１２０の一部として、電話リソースクラスター、プロセッサおよび／またはストレージデバイスのリソースは、好ましくは、新しい第二の目的のために再供給される。例えば、テキストを音声に変換することは、より多くのコールが提供される必要があるタイミングでコールルーターとして機能するように再供給される。さらに、システムに新しいリソースを追加するおよび／または共有リソース環境の別の顧客からリソースを割り当てることを含むことができる、より多くのリソースが、割り当てられまたは再割り当てを解除することができる。リソースは、好ましくは、このようなクラウドホスティングプロバイダ（すなわち、ユーザーが仮想マシンのリソースを作成するためにマシンのイメージをブートできるようにサイズ変更可能な計算能力を提供するウェブサービス）などの複数テナントで共有、仮想化したコンピューティング環境で提供されるが、代わりに同じ場所にあるいか分散された物理マシンとすることもできる。例えば、多数のリソースがパワーダウン状態で稼動することもできる。さらに容量が必要とされている場合、リソースはオン／ブート（すなわち再割り当て）され、電話リソースクラスターの新しいリソースとして機能する。同様に、電話リソースクラスターが現在必要とされるより多くの容量を持っているときに、リソースは、パワーダウンするか、他の企業で使用するためのリソースのプールに戻る（すなわち、割り当て解除）、または、リソースの現在の使用を終了する任意の適切なアクションとすることができる。
【００２９】
さらに、ステップＳ１２０は、リアルタイムまたは差し迫ったキャパシティ要件でデータを収集するために機能する、リソースのキャパシティ要件Ｓ１２２を分析することを含むことができる。データは、容量要求に保存されている履歴、電話リソースクラスターの現在の負荷、アプリケーションの分析からのデータ、または容量要求を予測するの任意の適切なソースから、コールリクエストキューから、収集されることがある。コールリクエストキューからのデータには、保留中のコールリクエスト、コールリクエストの型または詳細、または任意の適切なキューに関連する情報などの情報を提供することできる。保存されている容量の履歴は、好ましくは日、週、または年を通じて、一時的なパターンのような容量パターンに洞察を提供する。電話リソースクラスターの現在の負荷は、好ましくは、電話リソースのリソースの現在の数、電話リソースの利用可能なリソースの数、リソースの種類の区分、割り当て解除されたリソースの数、電話のネットワークチャンネルの数などの情報を提供する。アプリケーションの分析データは、好ましくは、予想または予測された容量リクエスト上のユーザーの電話アプリケーションからのデータである。解析は、好ましくは、アプリケーションの操作で実行され、またはコールの数、コールのピーク時間、コールのタイプ（例えば、電話会議、ＳＭＳメッセージなど）のアプリケーションの予想される容量リクエストに関するユーザーから収集される。解析情報は、好ましくは、供給、割り当て、およびステップＳ１２０のリソースの割り当て解除を制御するために使用される。さらに、容量要求を分析した後、電話リソースクラスター、電話リソース、コールキュー、デキュー、リソースアロケーターなどのようなシステムの他の構成要素は、好ましくは、関連する分析情報として通知される。特定の分析情報は、特に構成要素に送信されることがある。例えば、ロードバランサーとデキューは、好ましくは、容量の情報に基づいて利用可能なリソースと調整する操作について通知される。
【００３０】
電話リソースを介してコールリクエストからの最初のコールのセッションを作成することを含むステップＳ１３０は、電話リソースを使用してコールセッションへのコールリクエストを変換するための機能を果たす。ステップＳ１３０は、好ましくは、追加の処理およびさらに特定のアプリケーションに固有の手順を含む。望ましい変形例では、コールルーターは、好ましくは、宛先の電話番号を識別するためのコールリクエストの電話命令を処理し、その後、ステップＳ１４０の一部として、宛先の電話番号への接続を確立する。転写のサーバは、録音を開始したり、コールセッションの会話を録音する準備をすることができる。
【００３１】
電話チャンネルへの複数の追加コールセッションで、コールセッションを多重化することを含むステップＳ１４０は、電話デバイスへの電話ネットワーク接続を確立する機能を果たす。電話チャンネルは、好ましくは、ＰＳＴＮ（公衆交換電話網）接続である。これは、ＰＳＴＮに接続するための物理的なワイヤーまたはいくつかのインタフェースのインフラストラクチャである。場合によっては、チャンネルの概念は、好ましくは、電話ネットワークにサブスクライブされたり、電話ネットワークから借りる。一つの変形例では、ＳＩＰ（セッション・イニシエーション・プロトコル）トランクは、電話ネットワークへのインターネットベースのゲートウェイとして使用される。多重化は、好ましくは、電話セッションが交互に電話チャンネルに接続される時分割多重化の形で発生する。時分割多重化は、好ましくは、完全な電話セッションの完了に基づく。例えば、特定のネットワークチャンネルは、先ず第１に、最初のユーザーのコールセッションのために利用され、呼び出しの完了時に、第２のコールセッションは２番目のユーザーのための特定のネットワークチャンネルを確立する。ステップＳ１４０の部分として、電話チャンネルは、さらに、電話チャンネルＳ１４２の供給を含む。この機能は、システムの利用可能な多数の電話ネットワークの容量を調整する。電話ネットワークへのゲートウェイを供給すること（例えば、ルーターまたはＳＩＰトランクを呼び出す）で、チャンネルまたはチャンネルへのゲートウェイを、割り当てまたは割り当て解除することができる。電話ネットワークチャンネルのそのようなスケーリングは、好ましくは、現在の電話ネットワークの容量要求に近い動作を可能とする。このようなスケーラビリティが使用されていない場合は、同時に使用できるチャンネルの数に制限を設定する。
【００３２】
３．動的な電話ネットワークを作動させる方法
図６に示すように、好ましい実施形態の電話ネットワークを提供する方法２００は、チャンネルＳ２１０の静的な数の電話ネットワークを操作する方法を含んでおり、複数のユーザーＳ２２０に電話ネットワークチャンネルへのアクセスを提供し、ユーザーが通常の操作Ｓ２３０を超える多数のチャンネルにアクセスできるようにチャンネルの使用状況を管理する。方法は、電話ネットワークのオペレータが、使用状況に基づくサービスの品質や信頼性を低下させることなく、複数のユーザーに高容量を提供できるようにする機能を果たす。この方法は、好ましくは、上述のものと実質的に同様のシステム上に実装されるが、任意の適切なシステムを代わりに使用することもできる。方法は、さらに、本明細書に記載の方法と組み合わせて使用することができる。方法２００は、さらに、ユーザーが操作に必要なチャンネルの数に関する特定の懸念なく、電話ネットワークを使用可能する機能を果たす。電話ネットワークのユーザーは、好ましくは、コールセンター、構内交換機（ＰＢＸ）、電話ツリー、電話アプリケーション、ＶＯＩＰサービス、ＳＭＳまたはＭＭＳサービス、および／または、任意の適切な電話アプリケーションなどの電話アプリケーションを操作する。電話ネットワークのオペレータは、好ましくは、電話プラットフォームプロバイダ（例えば、インターネット電話のプラットフォームのプロバイダー）などの電話サービスプロバイダー、電話会社（例えば、ＡＴ＆Ｔなどの電話ネットワークの所有者）、および／または、任意の適切なパーティーである。好ましい実施形態の変形例において、方法２００は、さらに、分散型コール制御、コールキュー、および／または、容量要求を評価する工程を含むことができる。
【００３３】
チャンネルの静的な数を有する電話ネットワークを操作することを含む、ステップＳ２１０は、電話ネットワークのアクセスをユーザーに提供するための基本インフラとなる機能を果たす。チャンネルの静的な数は、好ましくは、一度にサポートできる同時電話セッションまたはコールの合計数である。チャンネル数は、従来、特定のキャリアやネットワークへの利用可能な相互接続の数によって制限されている。電話ネットワークは、しかし、複数のキャリアやネットワークプロバイダまたは公衆交換電話網から構成されるが、複数のキャリアやネットワークは、好ましくは、１つの電話ネットワークとして管理され取り扱われる。チャンネルの静的な数は、好ましくは、時間の期間（通常は電話会社との契約に基づく）のために定められた数であり、その数は、好ましくは、十分な容量を提供するために十分な大きさである。チャンネルの静的な数は、好ましくは、ネットワークの容量や他のネットワークと接続する電話ネットワークの能力の指標となる。電話ネットワークの操作は、好ましくは、電話ネットワークのチャンネルへのアクセスをユーザーに提供することによって取り扱われる。電話ネットワークは、任意の時点で使用されていないチャンネルの指定された数を持つことができる。ある変形例では、電話ネットワークは、代わりに、使用されていないモードで未使用のチャンネルを操作することができる。未使用モードは、完全または部分的なハードウェアのパワーダウンモード、ハードウェアのスリープモード、二次利用（望ましい最小限の副作用で中断することができる非重要な用途のような）、および／または、任意の適切な方法となる。未使用モードは、操作のコストを削減し、および／または、未使用容量の効用を最大化する機能を果たす。
【００３４】
好ましい実施形態の追加の代替手段として、方法は、電話ネットワークＳ２１２のサブセットとして、分散型コールコントローラーでの操作が含まれる。複数のネットワークプロバイダやキャリアが使用されている場合、分散型コール制御は、代わりに、複数の電話ネットワークのサブセットとなる。分散型コールコントローラーの操作は、好ましくは、電話ネットワークの現在の容量要求についてチャンネルの割り当てられた数を操作する機能を果たす。分散型コールコントローラーは、好ましくは、任意の時点での静的なチャンネル容量として、より小さいまたは等しい容量を持っている。分散型コールコントローラーの容量は、好ましくは、コールコントローラーへの電話ネットワークのより多くのリソースを割り当てることによって増やすことができ、分散コールコントローラーの容量は、好ましくは、電話ネットワークのリソースの割り当てを解除することによって低減することができる。電話ネットワークへのアクセスは、好ましくは、仮想化されたハードウェアまたはソフトウェア（ルーターまたはＳＩＰトランクなどの呼び出し）によって促進される。電話ネットワークのより多くのリソースの割り当ては、さらに、電話ネットワークにアクセスするデバイスの仮想化が含まれる。例えば、ネットワークアクセスチャンネルの仮想化は、電話ネットワークにさらにアクセス容量を追加するために加えることができる。別の例として、市販のハードウェアノードは、高い容量要求の間に電話ソフトウェアスタックを実行するための電話ネットワークに追加される。
【００３５】
複数のユーザーに電話ネットワークへのチャンネルアクセスを提供することを含む、ステップＳ２２０は、複数の別のパーティーが電話ネットワークのチャンネルにアクセスすることを許可する機能を果たす。ユーザーは、好ましくは、電話ネットワークのオペレータのサービスに加入している。電話ネットワークのユーザーは、好ましくは、コールセンター、構内交換機（ＰＢＸ）、電話ツリー、対話型音声応答（ＩＶＲ）アプリケーション、インターネット電話アプリケーション、ＶＯＩＰサービス、および／または、任意の適切な電話アプリケーションなどの電話アプリケーションを操作している。ユーザーは、好ましくは、チャンネルの特定の数に基づいたサービスに加入しない。ユーザーの観点から、チャンネル数は、好ましくは、ユーザーのアプリケーションの操作に対して無限または無関係のポイントである。電話ネットワークがチャンネルごとに操作されている間、ユーザーは、好ましくは、１人あたりの使用量や時間の観点（例えば、価格設定および／またはアプリケーションの使用の観点を）表示される。電話ネットワークのオペレータは、好ましくは、電話ネットワーク（電話会社からのリースや運用コストの固定資本コスト）の操作に関連するコストをユーザーに対する変動費へ変換する。電話ネットワークへのアクセスは、好ましくは、操作され、リースされ、および／または、１人あたりのチャンネルによって電話会社（ＡＴ＆Ｔなど）からの契約となる。リース契約または契約は、代わりに、チャンネルごとの（容量）コストを最小限とし、好ましくは使用ごとまたは時間のコストごとを強調するように交渉され、あるいは、任意の適切なリース契約または契約を使用することができる。ユーザーは、好ましくは、使用量、毎分の時間間隔に対する均一料金、使用量および時間料金の組み合わせ、および／または、任意の適切な価格決定モデルによって支払う。
【００３６】
通常操作Ｓ１３０を超える多数のチャンネルへのユーザーアクセスを許可するようにチャンネルの使用を管理することを含む、ステップＳ２３０は、電話ネットワークの品質と信頼性が他のユーザーの利用状況によって影響を受けないことを確保しながら、ユーザーに高容量の利用可能性を提供する機能を果たす。複数のユーザーの個々のユーザーは、好ましくは、チャンネルの静的な数の複数のユーザー間で均等に分割するよりも大きい多数のチャンネルを使用することが許される。個々のユーザーが特定の時間に使用するチャンネルの最大数の合計は、好ましくは、チャンネルの静的な数よりも大きくなる。個々のユーザーがチャンネルの最大数のアクセスできる所定の時間は、好ましくは、他のユーザーからの電話ネットワーク上の要求が少ないときである。電話ネットワークおよび電話リソースクラスターの利用状況は、好ましくは、電話セッションの完了に基づく時間ベースの多重化である（すなわち、ユーザーがリソースとネットワークの使用を共有する）。簡単な例では、電話ネットワークは利用可能な１０チャンネルを持ち、５人のユーザーが存在する。一様に配信する場合、ユーザーはそれぞれの用途に利用可能な２チャンネルを持つが、一つの好ましい実施態様では、５人のすべてのユーザーが、他のユーザーがチャンネルを使用していないと仮定し、それぞれ最大１０チャンネルのアクセスを持つことができる。電話ネットワークの通常の使用中に、ユーザーは、依然として電話ネットワークのチャンネルの最大数にアクセスする能力を持っているが、コールリクエストは、好ましくは、コールキューが発したユーザーの制限のゲートとなる。上記の例を拡張する別の例では、分析は、４人のユーザーが特定の時点において２チャンネルを使用すると、最初の４人のユーザーのための能力、可用性を維持しながら、８チャンネルを５人目のユーザーが利用可能となることを示している。チャンネルの使用状況を管理することは、好ましくは、コールキューを管理し、ユーザーの制限を強制し、使用状況と容量要求を予測および／または分析し、分散型コールコントローラーの能力に基づいて容量を調整し、および／または、電話ネットワークのリソースを管理するための任意の適切な手順することなどにより、リソースの使用状況を取り扱うことを含む。分散型コールコントローラーの容量は、さらに、予測および解析によって制御されまたは影響を受け、ユーザーはさらに影響を受ける。
【００３７】
好ましい実施形態の方法は、さらに、複数のユーザーからの要求のコールキューＳ２３２を管理する工程を含むことができる。ステップＳ２３２は、ユーザーからのコールリクエストの処理を優先させる機能を果たす。コールキューは、好ましくは、電話ネットワークの制御アーキテクチャの一部として運営されているプログラムまたはハードウェア管理のスタックである。制御アーキテクチャは、好ましくは、複数のユーザーによる電話ネットワークと利用状況を操作する。コールキューは、好ましくは、電話ボイスセッションの要求、および／または、ＳＭＳ／ＭＭＳメッセージの要求を含む電話ネットワークによるサービスを待機するコールリクエストのリストである。リクエストは、ネットワーク、好ましくは、ネットワークの現在の容量に対し、および、各ユーザーに対し、適切な料金でサービスされる。サービス料金は、代わりに、分散型コールセンターの容量およびキュー内のリクエストの数に応じて調整される。容量が、超過するか、あるいは、すべてのリクエストのためのコールキューに置かれている場合、または、任意の適切なルールに基づいている場合、ユーザーのリクエストは、好ましくは、コールのキューに置かれる。ユーザーは、好ましくは、特定のユーザーの制限、特に：コールレートの制限（スロットル）と合計の制限（キャップ）に関連付けられている。スロットルとキャップは、好ましくは、コールキュー内のリクエストの位置を決定するために使用される。ユーザーからのリクエストは、好ましくは、スロットルに応じてコールキュー内で時間的に離間している。異なるユーザーのリクエストは、好ましくは、図６に示すように、階段状または交互にキュー内で順序付けされるが、代わりに、ユーザーは、サービスプラン、先着順セルフサービスポリシー、および／または、任意の適切なポリシーに基づいた優先権を持つことができる。キャップは、好ましくは、ユーザーが一定時間内に行うことができるリクエストの合計数の制限である。後続のリクエストは、好ましくは、キャップに応じて後の時間に対しスケジュールされているが、キャップを超えるリクエストを任意の適切な方法で処理されることもできる。例えば、ユーザーが１秒あたり１回のコールができ、ユーザーが１００コールをリクエストすると、それらは等しく次の１００秒においてスケジュールされる。このキャップは、コール／時間フレーム（１／秒）の数、または、キュー内のコール（１秒）の間に必要な待ち時間の数として記述することができることに注意すべきである。ユーザーは、ハンドリング、スペーシング、および／または、あるユーザーが不当に任意の時点で電話ネットワークの利用を支配することを防ぐように機能するコールキューのオーダリングを制限する。ＳＭＳ／ＭＭＳのメッセージリクエストの変形例において、個々のユーザーの料金は、ネットワークによるメッセージのフィルタリングを防ぐために考慮される。ＳＭＳ／ＭＭＳの変形例のために、リクエストは、さらに、制御キューと電話番号のキューでキューイングされる。ＳＭＳ／ＭＭＳメッセージの内容は、好ましくは、保存され、メッセージの内容への参照により、キューの負荷を軽減する機能がキューイングされる。複数のキャッシュサービスのポートまたはポインタが好ましく用いられる。サービスポートは、好ましくは、コールキューからのコールリクエストを動作させるための、ソフトウェアおよび／またはハードウェアの制御メカニズムである。サービスポートは、好ましくは、コールキューからリクエストを受け取り、電話ネットワークのチャンネルに対応するユーザーのアプリケーションまたはユーザーを接続する。サービスポートは、直接接続されるが、代わりに、前述のようにクラスター内のコールルーターなどのハードウェアまたはソフトウェアリソースとすることもできる。サービスポートは、好ましくは、着信コールのための容量を可能にするチャンネルの静的な数未満であるが、他の例として、サービスポートをチャンネルの静的な数に等しくすることもできる。電話ネットワークが１０００チャンネル存在する例では、５００のサービスのポートが存在する場合がある。これは、着信コールのために５００チャンネルをフリーにすることを意味する。さらに、ユーザーは、できるだけ早くまたは将来のある時点（例えば、ユーザーがコールまたは後の時間のためのコールをスケジュールする）での、電話リソースへのアクセスを要求することができる。キューポッパーは、好ましくは、サービスするコールキューからのコールを選択するための、ソフトウェアまたはハードウェアのメカニズムである。さらに、コールキューからコールを選択する複数のキューポッパーが存在する場合がある。加えてまたは代わりに、ユーザーの制限は、ユーザーのニーズに応じて調整または設定される。ユーザーは、ユーザーのアプリケーションの性質や特性に基づいた特定の要求を有する場合がある。ユーザーの制限は、好ましくは、ユーザーが選択した契約および／または価格設定に応じて、または、任意の適切な手段によって、設定される。
【００３８】
好ましい実施形態の方法は、さらに、分散型コールコントローラーＳ２３４に対する容量要求を予測する工程を含むことができる。ステップＳ２３４は、後で必要になった電話ネットワークチャンネルの数に相関する指標を評価する機能を果たす。キャパシティの予測は、好ましくは、プログラム的にまたは数学的に（パターンの検出または任意の適切なアルゴリズムを介して）現在および過去の情報を分析することによって達成されるが、任意の適切な方法を代わりに使用することもできる。容量ニーズのパターンは、好ましくは、時刻、曜日、年のパターン、利用パターン（１人のユーザー容量ニーズの増加が他のユーザーが容量ニーズの増加を示す場合など）、コール位置、コール通話時間、および／または、任意の適切な指標に関連して見つかる。ステップＳ２３４の予測は、さらに、リアルタイムの供給、供給の解除、および／または、分散型コールコントローラーや電話ネットワークの静的容量のプランニングキャパシティ要求のために使用することができる。
【００３９】
好ましい実施形態の方法は、さらに、コールキューＳ２３６の容量ニーズに反応させる工程を含めることができる。ステップＳ２３６は、現在の容量要求または近い将来予想される要求に対し分散型コールコントローラーを調整するために、コールキューと他の現在容量の指標を使用する機能を果たす。コールキューは、好ましくは、ソフトウェアを介して、または、コールキューの任意の適切な監視によって、評価される。キュー中に現在存在するコール数、電話ネットワークを現在使用しているユーザーの合計数、入信コール（キューされない）、ユーザーリクエストの頻度、および／または、電話ネットワークまたはコールキューの任意の適切な特性は、好ましくは、容量のニーズへのリアクションを引き起こす。リアクションは、好ましくは、現在の全体の容量のニーズに対するものであるが、あるいは個々のユーザーまたは任意の適切なパーティーの現在の容量ニーズに対するものとすることもできる。リアクションは、コールキュー（たとえば、コールキューのサービス料金またはオーダリング）の設定を調整し、ユーザー制限を変更し、分散型電話コントローラーの容量の調整すること、および／または、任意の好適なアクション、を含むことができる。一例において、コールキューは、現在の時刻の後１００秒の間にスケジュールされ、分散型コールコントローラーが予想される容量要求を収容する容量を増加させる。
【００４０】
好ましい実施形態の方法は、さらに、ユーザーの容量ニーズを分析して電話ネットワークの容量ニーズを予測するステップＳ２３８を含む。ステップＳ２３８は、電話ネットワークの総容量要求を決定するために個々の容量ニーズを検出するの機能を果たす。ユーザーの容量ニーズは、好ましくは、ユーザーの電話アプリケーションを分析することによって取得される。分析の部分は、好ましくは、個々のアプリケーションの容量ニーズを示す定期的なイベントを検知することを含む。このようなイベントの例は、発信者が番組の放送時間前後にコールする週刊テレビ番組に関連付けられたアプリケーションである。分析は、代替的または追加的に、個々のアプリケーションの典型的な通話時間を検出することが含まれる。他のアプリケーションが使用の長い期間（ユーザーが長い電話のツリーをナビゲートしなければならない場合など）を必要とする場合、いくつかのアプリケーションは時間の短い使用となる（短いメッセージが再生されている場合など）。さらに、アプリケーションの履歴が、最大、最小、および／または、平均の容量要求、リクエストの頻度、リクエストの期間、特定の時間の期間に送信されたＳＭＳメッセージの数、および／または、任意の適切コール特性などによって、使用パターンを決定するために使用されることがある。ユーザーの個々のアプリケーションの使用特性は、好ましくは、電話ネットワークの総使用特性および容量ニーズを決定するために、他のユーザーの利用特性と組み合わされる。好ましくは、アプリケーションのコードは、アプリケーションの機能および使用パターンを評価するために分析される。アプリケーションのコードまたは操作は、好ましくは、プログラム的に解析されるが、任意の適切な方法を用いてもよい。また、ユーザーおよび／または第２パーティーは、ユーザーのアプリケーションおよび／または電話サービスを特徴付けることができる。この特徴付けは、好ましくは、サインアップしながらユーザーによって実行され、そして好ましくは、使用頻度、使用回数、通話時間、および／または、アプリケーションの任意の適切な特性に対するユーザーの予測が含まれている。容量をそのアプリケーションの最上位にすべき場合、ユーザーはさらに優先順位を付けることができる。任意の適切なステップが、個々のアプリケーションを分析するために使用される。
【００４１】
好ましい実施形態の追加の代替手段として、方法は、分散型コールコントローラーの容量を調整することＳ２４０を含む。ステップＳ２４０は、適切に容量要求を処理するために、電話ネットワークのアクティブなチャンネル数を変更する機能を果たす。ステップＳ２４０は、好ましくは、分散型コールコントローラーを操作することを含む、ステップＳ２１２と組み合わせて使用される。分散型コールコントローラーの調整は、オペレータが提供する容量の利用可能量を調整する。容量は、好ましくは、電話ネットワークのチャンネルの使用状況の管理に基づいて調整される。容量は、より好ましくは、Ｓ２３４および／またはＳ２３６のステップの予測と分析に基づいて調整されるが、代わりに、ステップＳ２３２、ステップＳ２３８、および／または、任意の適切な理由と協力して調整される。より多くの容量が必要な場合、同時チャンネルを処理してより多くののチャンネルを提供できる、ＣＰＵ、ＲＡＭ、ＤＩＳＫ等のようなより多くのリソースが、好ましくは、分散型の電話コントローラーに割り当てられていて、反対に少ない容量が必要とされるとき、リソースは、好ましくは、分散電話コントローラーから切り離される。容量の調整は、好ましくは、予想または予測された容量を処理するために行われます。電話ネットワークの静的容量は、代替的または追加的に、調整される。電話ネットワークとして、容量は一般的に柔軟性がない。電話ネットワークの容量の調整は、好ましくは、長期的（例えば、一月の月額ベーで）な容量ニーズ（例えば、一月の月額ベースで）のために作られている。多かれ少なかれ容量のシステムに任意の適切な調整を代わりに使用することができる。
【００４２】
４．電話ハードウェア間のコールを配布する方法
図７−８に示されているように、好ましい実施形態の電話ハードウェア間でコールを配信する方法３００は、コールリクエストをキューするステップＳ３１０、ロードバランシングのコールルーターを選択するステップＳ３２０、および、コールを選択されたコールルーターに接続するステップＳ３３０を含む。方法は、電話アプリケーションで使用されるリソースの使用のバランスを取る機能を果たす。この方法は、好ましくは、上述のものと実質的に同様のシステム上に実装されているが、代わりに任意の適切なシステムを使用することもできる。
【００４３】
コールリクエストのキューイングを含む、ステップＳ３１０は、必要なリソースがコールを処理できるようになるまで、コールリクエストを管理する機能を果たす。コールリクエストは、好ましくは、電話アプリケーション、コールルーター、電話デバイス、および／または、コールリクエストの任意の適切なソースによって、インスタンス化される。コールリクエストは、さらに、ＳＭＳまたはＭＭＳメッセージの要求である。コールリクエストは、好ましくは、発信される。着信コールは、好ましくは、発信リクエストよりも多くの緊急のコールリクエストとして認識され、着信コールはキューに登録されないが、代わりに利用可能なリソースに直接渡すことができる。また、着信コールリクエスト（コールセッションをイニシエートする）がキューされるが、着信コールはより即時性があるので、それらは好ましくは優先順位付けされ、あるいは、システムが着信コールがフェールする時間よりも短いショートキューイング時間を持たなければならない。着信コールは、代わりに、キューの先頭付近に配置するか、または、コールリクエストの高い優先順位のために適切な別の規則に従ってキュー中に配置する。同様に、同期発信コールのリクエストが高い優先順位でキューイングされることもある。同期コールは、ユーザーが遅延を気にしなくなるアプリケーションによって開始された新しいコールとは対照的に、別の呼び出し者が続行することを頼るコールである。コールリクエストは、好ましくは、スロットル、キャップ、リアルタイム緊急性（優先度）および／または任意の適切な要因に基づいたルールに従ってキュー中に並んでいる。
【００４４】
ロードバランシングのコールルーターを選択することを含む、ステップＳ３２０は、好ましくは、電話リソースクラスターの動作を最適化するためにコールを処理するコールルーターを識別する機能を果たす。選択されたコールルーターは、一般的に、もっとも負荷の少ないコールルーターであるが、代わりに、コスト、エネルギー使用量、処理能力、および／または任意の適切な変数を最適化するように選択することもできる。ステップＳ３２０は、さらに、コールルーターに付加的あるいは選択的に、他のハードウェアまたはソフトウェアのリソースに適用される。電話リソースクラスターのコールルーターは、ハードウェアおよび／またはソフトウェアの仕様に応じて可変の容量と性能を持つことができる。複数のコールルーター間のばらつきは、好ましくは、コールルーターを選択する際に考慮される。上記のものと実質的に類似したロードバランサーは、好ましくは、ステップＳ３２０を実装する構成要素であり、ステップＳ３２０を介して、任意の適切なデバイスによって実行される。ロードバランサーは、好ましくは、クラスターのリソースの割り当ておよび割り当て解除をすることができ、そのためリソースはＳ３２０のサブステップとして割当ておよび／または割り当てを解除することができる。リソースアロケーターは、好ましくは、コールルーター、ハードウェアリソースおよび／またはソフトウェアリソースの割当ておよび割り当て解除を実行することができる。リソースは、好ましくは、現在のまたは予測された利用に基づいて、割り当てまたは割り当て解除をするが、リソースが、代わりに、他のリソースの機能として割り当てまたは割り当て解除することもできる。例えば、一つのメディアの処理リソースは、すべての５つのコールルーターに対し割り当てることができる（例えば、動作）。ロードバランシングのコールルーターの選定は、好ましくは、分析システムからのデータを使用している。その結果、ロードバランシングのコールルーターを選択するステップは、将来の時点で負荷をバランスするコールルーターを選択することを含む。
【００４５】
選択したコールルーターにコールを接続することを含む、ステップＳ３３０は、特定のリソースへのコールの制御を渡す機能を果たす。発信コールの場合は、コールルーターは、好ましくは、指定された電話番号に電話ネットワークを介して接続する。着信コールの場合は、コールルーターは、好ましくは、特定の電話アプリケーション；固定電話、携帯電話、衛星電話、または、その他の適切なＰＳＴＮに接続されたデバイスなどのＰＳＴＮに接続されたデバイス；ボイスオーバーインターネットプロトコル（ＶＯＩＰ）の電話機、ＳＩＰデバイス、スカイプ、Ｇｔａｌｋあるいは他のインターネットアドレス可能な音声デバイスなどの非ＰＳＴＮデバイス；および／または、着信コールの番号に関連付けられている任意の適切なデバイス；に接続する。
【００４６】
好ましい実施形態の方法は、さらに、共有アプリケーションＳ３４０を有するネットワーキングコールルーターが含まれる。ステップＳ３４０は、複数のコールルーター間の通信を可能にする機能を果たす。これは、好ましくは、アプリケーションの機能が複数のリソース（例えば、複数のコールルーター）を介して配信される状況で、有用である。ネットワークは、好ましくは、コールルーター間でリソース共有を許す。コールルーターのオーディオチャンネルは、さらに、コールルーター間でミックスされ共有される。ＶＯＩＰチャンネルは、好ましくは、異なるコールルーターの音声をブリッジングするためのネットワークを介して形成される。例えば、電話会議では、異なるコールルータから複数のコールセッションのオーディオをブリッジングするネットワークを使用することができる。
【００４７】
好ましい実施形態の方法は、さらに、アプリケーションをサービスアプリケーションとの同期させることＳ３５０を含む。サービスアプリケーションは、コールルータークラスター上で分散するアプリケーションを監視し、アプリケーションの動作を調整する機能を果たす。サービスアプリケーションは、さらに、コールーター間で状態情報を共有するために使用されることがある。サービスアプリケーションは、好ましくは、上記のようなハングアップサービスや複数入力サービスのような特的の機能を提供する。任意の適切なアプリケーションは、入力収集、マルチダイアリング、コールの分割、コールのマージおよび任意の好適な特徴のようなサービスアプリケーションによって実装される。任意の数のサービスアプリケーションを使用することができる。
【００４８】
当業者が、前回の詳細な説明から、および、図面とクレームから認識するるように、修正及び変更は、以下の特許請求の範囲に記載された本発明の範囲から逸脱することなく、本発明の好ましい態様に行うことができる。
【特許請求の範囲】
【請求項１】
マルチテナントの電話システムを操作するためのシステムであって：
・複数のユーザーから受信したコールリクエストを蓄積するコールキュー；
・コールリクエストのためのコールセッションを確立するスケーラブルな電話リソースクラスター；
・システムの容量要求を計算する解析システム；
・電話リソースクラスターのスケーリングと操作を管理するリソースアロケーター；および
・コールセッションの電話通信チャンネルとして使用される複数の電話ネットワークチャンネル、を備えることを特徴とするシステム。
【請求項２】
コールリクエストが、ユーザー間で要求される料金制限およびユーザーに対し指定された時間内にリクエストの最大数のユーザーキャップに応じて、コールキュー内で順序付けされている、請求項１に記載のシステム。
【請求項３】
解析システムが、容量要求を計算するためのコールキューデータを受信し、リソースアロケーターが、さらに、複数のコールキューの割り当てと操作を管理する、請求項２に記載のシステム。
【請求項４】
コールリクエストが電話アプリケーションから受け取られ、分析システムが、容量要求のための電話アプリケーションを分析し、過去の容量要求のデータにアクセスし、システムの容量要求を計算するために現在の容量負荷を監視する、請求項１に記載のシステム。
【請求項５】
コールキューが電話メッセージリクエストに対する追加のキューを含む、請求項１に記載のシステム。
【請求項６】
電話リソースクラスターが、複数の電話ネットワークチャンネルのサブセットである、複数の割り当てられた電話ネットワークチャンネルを含み、リソースアロケーターが、割り当てられた電話ネットワークチャンネルの数をスケーリングし、コールリクエストを割り当てられた電話ネットワークチャンネルのチャンネルに接続する分散型コールコントローラーを含む、請求項１に記載のシステム。
【請求項７】
電話リソースクラスターが複数の電話リソースを含む、請求項１に記載のシステム。
【請求項８】
複数の電話リソースが複数のコールルーターを含み、コールルーターが、電話ネットワークチャンネルを介して電話通信を行うとともに受け取り、アプリケーションのレイヤープロトコルを使用するユーザーのアプリケーションサーバーと通信する、請求項７に記載のシステム。
【請求項９】
少なくとも２つのコールルーター間のデータチャンネルであるコールルーターネットワークをさらに備える、請求項８に記載のシステム。
【請求項１０】
少なくとも２つのコールルータにおける少なくとも２つのコールセッションを含む、電話アプリケーションの操作を調整するサービスアプリケーションをさらに備える、請求項８に記載のシステム。
【請求項１１】
電話リソースクラスターが、複数の電話ネットワークチャンネルのサブセットである、複数の割り当てられた電話ネットワークチャネルを含み、リソースアロケーターが、割り当てられた電話ネットワークチャンネルの数をスケーリングし、コールリクエストを割り当てられた電話ネットワークチャンネルのチャンネルに接続する分散型コールコントローラーを含む、請求項８に記載のシステム。
【請求項１２】
電話ネットワークを操作するための方法であって：
・電話リソースへの複数のユーザーのコールリクエストを多重化し；
・電話リソースを介してコールリクエストから最初のコールセッションを作成し；
・電話チャンネルへの複数の追加コールセッションでコールセッションを多重化する；
ことを特徴とする方法。
【請求項１３】
電話ネットワークを提供する方法であって：
・チャンネルの静的な数で電話ネットワークを操作し；
・複数のユーザーに電話ネットワークへのアクセスを提供し；
・ユーザが通常の操作を超える多数のチャンネルにアクセスできるように、チャンネルの使用を管理する；
ことを特徴とする方法。
【請求項１４】
電話ハードウェア間にコールを配信するための方法であって：
・コールリクエストをキューイングし；
・ロードバランシングコールルーターを選択し；
・コールを選択されたコールルーターに接続する；
ことを特徴とする方法。
【請求項１】
マルチテナントの電話システムを操作するためのシステムであって：
・複数のユーザーから受信したコールリクエストを蓄積するコールキュー；
・コールリクエストのためのコールセッションを確立するスケーラブルな電話リソースクラスター；
・システムの容量要求を計算する解析システム；
・電話リソースクラスターのスケーリングと操作を管理するリソースアロケーター；および
・コールセッションの電話通信チャンネルとして使用される複数の電話ネットワークチャンネル、を備えることを特徴とするシステム。
【請求項２】
コールリクエストが、ユーザー間で要求される料金制限およびユーザーに対し指定された時間内にリクエストの最大数のユーザーキャップに応じて、コールキュー内で順序付けされている、請求項１に記載のシステム。
【請求項３】
解析システムが、容量要求を計算するためのコールキューデータを受信し、リソースアロケーターが、さらに、複数のコールキューの割り当てと操作を管理する、請求項２に記載のシステム。
【請求項４】
コールリクエストが電話アプリケーションから受け取られ、分析システムが、容量要求のための電話アプリケーションを分析し、過去の容量要求のデータにアクセスし、システムの容量要求を計算するために現在の容量負荷を監視する、請求項１に記載のシステム。
【請求項５】
コールキューが電話メッセージリクエストに対する追加のキューを含む、請求項１に記載のシステム。
【請求項６】
電話リソースクラスターが、複数の電話ネットワークチャンネルのサブセットである、複数の割り当てられた電話ネットワークチャンネルを含み、リソースアロケーターが、割り当てられた電話ネットワークチャンネルの数をスケーリングし、コールリクエストを割り当てられた電話ネットワークチャンネルのチャンネルに接続する分散型コールコントローラーを含む、請求項１に記載のシステム。
【請求項７】
電話リソースクラスターが複数の電話リソースを含む、請求項１に記載のシステム。
【請求項８】
複数の電話リソースが複数のコールルーターを含み、コールルーターが、電話ネットワークチャンネルを介して電話通信を行うとともに受け取り、アプリケーションのレイヤープロトコルを使用するユーザーのアプリケーションサーバーと通信する、請求項７に記載のシステム。
【請求項９】
少なくとも２つのコールルーター間のデータチャンネルであるコールルーターネットワークをさらに備える、請求項８に記載のシステム。
【請求項１０】
少なくとも２つのコールルータにおける少なくとも２つのコールセッションを含む、電話アプリケーションの操作を調整するサービスアプリケーションをさらに備える、請求項８に記載のシステム。
【請求項１１】
電話リソースクラスターが、複数の電話ネットワークチャンネルのサブセットである、複数の割り当てられた電話ネットワークチャネルを含み、リソースアロケーターが、割り当てられた電話ネットワークチャンネルの数をスケーリングし、コールリクエストを割り当てられた電話ネットワークチャンネルのチャンネルに接続する分散型コールコントローラーを含む、請求項８に記載のシステム。
【請求項１２】
電話ネットワークを操作するための方法であって：
・電話リソースへの複数のユーザーのコールリクエストを多重化し；
・電話リソースを介してコールリクエストから最初のコールセッションを作成し；
・電話チャンネルへの複数の追加コールセッションでコールセッションを多重化する；
ことを特徴とする方法。
【請求項１３】
電話ネットワークを提供する方法であって：
・チャンネルの静的な数で電話ネットワークを操作し；
・複数のユーザーに電話ネットワークへのアクセスを提供し；
・ユーザが通常の操作を超える多数のチャンネルにアクセスできるように、チャンネルの使用を管理する；
ことを特徴とする方法。
【請求項１４】
電話ハードウェア間にコールを配信するための方法であって：
・コールリクエストをキューイングし；
・ロードバランシングコールルーターを選択し；
・コールを選択されたコールルーターに接続する；
ことを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１２−５１９４５４（Ｐ２０１２−５１９４５４Ａ）
【公表日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願番号】特願２０１１−５５３０４７（Ｐ２０１１−５５３０４７）
【出願日】平成２２年３月２日（２０１０．３．２）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２５９４３
【国際公開番号】ＷＯ２０１０／１０１９３５
【国際公開日】平成２２年９月１０日（２０１０．９．１０）
【出願人】（５１１２１２２１７）トゥイリオ インコーポレイテッド (1)
【氏名又は名称原語表記】ＴＷＩＬＩＯ ＩＮＣ．
【Ｆターム（参考）】
【公表日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願日】平成２２年３月２日（２０１０．３．２）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２５９４３
【国際公開番号】ＷＯ２０１０／１０１９３５
【国際公開日】平成２２年９月１０日（２０１０．９．１０）
【出願人】（５１１２１２２１７）トゥイリオ インコーポレイテッド (1)
【氏名又は名称原語表記】ＴＷＩＬＩＯ ＩＮＣ．
【Ｆターム（参考）】
[ Back to top ]