JP5701844B2 - 通信システム、データセンタ装置及びデータセンタ装置で使用される制御方法 - Google Patents

Description

本発明の実施形態は、例えばＩＰ(Internet Protocol)電話システムといった通信システム、データセンタ装置及びデータセンタ装置で使用される制御方法に関する。

近年、ＬＡＮ（Local Area Network）やインターネットといったＩＰ(Internet Protocol)網を介して、双方向に画像や音声をパケットデータとして、リアルタイムに送受信するＩＰ電話システムが普及している。このＩＰ電話システムでは、例えば企業または個人（ユーザ）ごとにそれぞれＩＰ電話サーバを設置し、各ＩＰ電話サーバごとにＩＰ電話端末を登録できるようになっている。このようなＩＰ電話システムでは、内線間通信や外線発着信を行えることは勿論のこと、ＩＰ網を経由したＩＰ電話サーバ間での内線通信や外線発着信を行うことができる。

特開２０１１−１５０４８０号公報 特開２００６−３２５０３８号公報 特開２００９−２５９２０６号公報

ところで、各企業またはユーザは、ＩＰ電話サーバを購入して使用する場合、その時点で必要な機能を備えたＩＰ電話サーバを選択するようにしている。しかし、使用開始後において、人員の増加や業務内容の変化等に応じてＩＰ電話サーバの機能を追加する必要が生じたり、また不要な機能を削除する必要が生じることがある。また、各企業またはユーザごとに、ＩＰ電話サーバの台数を追加または削減する必要が生じることがある。

しかしながら、直ちに機能の追加または削除や、ＩＰ電話サーバの増設や削減等は、各企業または各ユーザ側の負担が大きい。

本発明の目的は、ユーザの費用負担の軽減を可能とするとともに、ユーザにおけるＩＰ電話サーバの保守管理を不要とした上で、しかもユーザに対し通信サービスの提供を簡易な構成で行うことが可能な通信システム、データセンタ装置及びデータセンタ装置で使用される制御方法を提供することにある。

実施形態によれば通信システムは、それぞれ通信端末を備えた複数のユーザ装置と、これら複数のユーザ装置に対し通信ネットワークを介して接続され、前記複数のユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供するデータセンタ装置とを備える。データセンタ装置は、処理部と、記憶部と、制御部とを備える。処理部は、通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のコンテナを有する。記憶部は、ユーザ装置を識別するユーザＩＤを記憶する。制御部は、ユーザ装置から通信機能の使用要求を受信するとき、複数のコンテナのうちの少なくとも１つを使用して通信サービスを提供する。

第１の実施形態における通信システムの概略構成図。 第１の実施形態における仮想化ホストサーバの機能構成を示す図。 上記図１に示したユーザデータベースの記憶内容の一例を示す図。 第１の実施形態におけるAdminコンテナ、CPコンテナ、電話会議コンテナ、Web会議コンテナの割り当て方式を示す図。 第１の実施形態において、例えばＩＰ電話端末が目的とするＣＰコンテナに収容されるまでのＣＰコンテナの制御手順を示すフローチャート。 第１の実施形態において、ＩＰ電話端末と公衆網上の電話端末との間で通信接続を行なう手順を示すシーケンス図。 第１の実施形態において、ＩＰ電話端末と仮想化ホストサーバとの間で登録先変更処理を行う動作を示すシーケンス図。 第１の実施形態において、ＣＰコンテナに障害が発生した際のＩＰ電話端末とＣＰコンテナとの間における通信切替動作を示すシーケンス図。 第２の実施形態における仮想化ホストサーバ、電話会議サーバ及びウェブ会議サーバの具体的構成を示す図。 第３の実施形態として、顧客の増加に伴い、例えば空きの仮想化ホストサーバにＡｄｍｉｎコンテナ及びＣＰコンテナを設定する際のユーザサイトと、プロビジョニングサーバと、仮想化ホストサーバとの間における動作を示すシーケンス図。 第３の実施形態において、仮想化ホストサーバからＣＰコンテナを削除する際のユーザサイトと、プロビジョニングサーバと、仮想化ホストサーバとの間における動作を示すシーケンス図。 第４の実施形態において、データセンタに障害が発生した際のＩＰ電話端末と他のデータセンタとの間における通信切替動作を示すシーケンス図。 第５の実施形態における通信システムの概略構成図。 第５の実施形態において、データセンタとユーザサイトのＩＰ電話サーバとの連携動作を示すシーケンス図。 第６の実施形態において、ユーザサイトのＩＰ電話サーバに障害が発生した際のＩＰ電話端末とＩＰ電話サーバとＣＰコンテナとの間における通信切替動作を示すシーケンス図。 第７の実施形態において、ＩＰ電話端末とＩＰ電話サーバとデータセンタとの間で登録先変更処理を行う動作を示すシーケンス図。 第８の実施形態において、ＩＰ電話端末とデータセンタとＩＰ電話サーバとの間で登録先変更処理を行う動作を示すシーケンス図。

以下、実施の形態について、図面を参照して説明する。

（第１の実施形態）
第１の実施形態は、電話機能、電話会議機能、及びウェブ会議機能を実現するためのサーバを顧客または顧客群とする企業内に設けるのではなく、クラウド上のサーバである仮想化ホストサーバに割り当てるようにして、電話機能等を実現できるようにするシステムである。

顧客は、例えば電話サービス会社との仲介業務を行うディーラと契約しているユーザ単位である。顧客群は、ディーラとそのディーラと契約している顧客とをまとめた単位である。

図１は、この第１の実施形態における通信システムの概略構成図であり、ＵＳ１〜ＵＳｍはユーザサイト、クラウド上に設けられるＤＣ１〜ＤＣｉ（ｉは自然数）はデータセンタ、ＴＳＰは電話サービスプロバイダをそれぞれ示している。ここで、データセンタＤＣ１〜ＤＣｉは、情報処理サービスを提供するデータセンタである。また、電話サービスプロバイダＴＳＰは、データセンタＤＣ１〜ＤＣｉのコンピュータリソースを使って、顧客に電話サービスを提供する。保守業者ＭＴは、電話サービスプロバイダＴＳＰと契約し、電話サービスを利用する顧客を集め、電話サービスプロバイダＴＳＰのサービスを受けるための仲介業務を行う。保守業者ＭＴは、上記仲介の他に、客先ネットワークの構築や、ＩＰ電話機、ゲートウェイの設置、顧客の要求に応じたデータ設定を行う。

ここで、電話サービスプロバイダＴＳＰとユーザを管理する保守業者ＭＴは、必ずしも別会社である必要はなく、同一会社であっても問題はない。

まず、ユーザサイトについては、ユーザサイトＵＳ１〜ＵＳｍのうち、ユーザサイトＵＳ１を代表して説明する。ユーザサイトＵＳ１は、ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎと、パーソナル・コンピュータＰＣと、ルータＲＴとを備えている。これらは、ＬＡＮ１を介して相互に接続している。このＬＡＮ１には、ゲートウェイＧＷ１が接続されている。なお、ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎは、通話処理機能と映像等のメディア情報処理機能とを備えている電話機で、パーソナル・コンピュータ（ＰＣ）に電話機能を実現するソフトウェアをインストールしたソフトフォンでもよい。ゲートウェイＧＷ１は、ＬＡＮ１とアナログ電話網等の公衆網ＮＷ１との間を接続するもので、ＬＡＮ１と公衆網ＮＷ１との間における通信プロトコル及び信号フォーマットの変換機能とを備えている。

ルータＲＴは、インターネットＩＮＷに接続され、このインターネットＩＮＷからさらにデータセンタＤＣ１〜ＤＣｉに接続される。ここでは、データセンタＤＣ１を代表として説明する。

電話サービスプロバイダＴＳＰは、ディーラ管理、ユーザ管理、ライセンス管理、及びＩＰ電話機、ネットワーク機器の受発注を管理する機能を有する。また、電話サービスプロバイダＴＳＰは、遠隔地からの保守を行うための機能を有する。

データセンタＤＣ１は、クラウド上に設けられたデータセンタである。データセンタＤＣ１は、インターネット等の通信網を介して、既存の公衆ＩＰ電話網ＮＷ２と接続されている。さらに、他社のデータセンタＤＣ２〜ＤＣｉと相互に通話可能となる。また、データセンタＤＣ１は、仮想化ホストサーバ(HW Node:ハードウェアノード)Ｎ１〜Ｎｐ（ｐは自然数）と、電話会議サーバＣＳＶ１と、ウェブ会議サーバＣＳＶ２と、運用支援サーバＣＳＶ３と、課金管理サーバＣＳＶ４と、プロビジョニングサーバＣＳＶ５と、ルータＣＲＴ１〜ＣＲＴｑ（ｑは自然数）と、ユーザデータベースＤＢとを備え、これらをＬＡＮ２を介して相互に接続している。ルータＣＲＴ１〜ＣＲＴｑは、インターネットＩＮＷに接続され、このインターネットＩＮＷからさらにユーザサイトＵＳ１〜ＵＳｍに接続される。なお、仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１、ウェブ会議サーバＣＳＶ２、運用支援サーバＣＳＶ３、課金管理サーバＣＳＶ４、プロビジョニングサーバＣＳＶ５は、物理的に独立している必要はなく、複数の役割りを物理的には１台のサーバで兼ねてもよい。また、仮想化されたリソースとして適用されるため、電話会議サーバＣＳＶ１と、ウェブ会議サーバＣＳＶ２と、運用支援サーバＣＳＶ３と、課金管理サーバＣＳＶ４と、プロビショニングサーバＣＳＶ５のそれぞれの物理的なサーバ構成は、複数のサーバから構成されていてもよい。

アプライアンス型ＩＰ電話サーバをそのまま仮想化して動作させた場合、仮想化に必要な計算機リソース(CPU使用量、メモリ使用量、ディスク使用量)が大きく、単純計算ではアプライアンス型ＩＰ電話サーバの仕様×台数分が必要となる。そのため仮想化しても１台の物理サーバで数台〜１０台程度の台数しか動作させることができない。

そこで、本第１の実施形態では、一般的なアプライアンス型ＩＰ電話サーバの機能を主に、通話機能、電話会議機能、ウェブ会議機能、および運用管理機能に分割する。そして、通話機能は仮想化ホストサーバＮ１〜Ｎｐの各ＣＰコンテナに収容する。また、運用管理機能は、仮想化ホストサーバＮ１〜ＮｐのAdminコンテナに集約する。また、電話会議機能は、データセンタ内に仮想化ホストサーバＮ１〜Ｎｐから分離して設けられた電話会議サーバに集約される。更に、ウェブ会議機能は、データセンタ内に仮想化ホストサーバＮ１〜Ｎｐから分離して設けられたＷｅｂ会議サーバに集約されて構成されている。ここで、電話会議機能とウェブ会議機能は、３者以上の接続を実現するもので、発呼や着呼という電話の基本機能を行うＣＰコンテナと分離し、複数のＣＰコンテナの共通リソースとして使用することで、流用効率を上げている。

図２は、上記仮想化ホストサーバＮ１〜Ｎｐの具体的構成を示す図である。

仮想化ホストサーバＮ１〜Ｎｐは、契約を結んだ上記ユーザサイトＵＳ１のＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ相互間及びこれらＩＰ電話端末ＩＰＴ１〜ＩＰＴｎと公衆網ＮＷ１の加入者線との間を交換接続する通話機能を基本機能として実現するための仮想サーバである。

ところで、上記仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１及びウェブ会議サーバＣＳＶ２は、各ユーザサイトＵＳ１〜ＵＳｍに配置される一般のアプライアンス型ＩＰ電話サーバの機能を分割して、クラウド上のデータセンタＤＣ１に実現したものである。

ここで、１台の仮想化ホストサーバＮ１内は、その上で仮想サーバが複数動作できるようにするための仮想環境が構築されている。仮想サーバには、機能や容量に応じて、１つまたは複数のＡｄｍｉｎコンテナ、ＣＰコンテナが設けられる。

まず、ＣＰコンテナは、電話機能としての基本機能である通話機能、ボイスメール機能、緊急通話機能などを有する。仮想サーバが提供するリソースの容量や運用方法にもよるが、従来のアプライアンス型ＩＰ電話サーバの１台分の端末間の接続設定機能を１つのＣＰコンテナに収容すると管理が容易になる。もちろん、ＣＰコンテナの収容方法は、これに限られない。

運用管理機能はAdminコンテナに集約する。Adminコンテナは、ＣＰコンテナの設定およびライセンス管理、電話会議、ウェブ会議の設定など、保守・管理機能を有する。Adminコンテナは、従来のアプライアンス型ＩＰ電話サーバに設けられていた保守・運用機能を集約して収容したもので、１つのコンテナで複数のＣＰコンテナ、つまりユーザサイトＵＳ１〜ＵＳｍの保守・管理を可能とする。

電話会議サーバＣＳＶ１は、契約を結んだ上記ユーザサイトＵＳ１のＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ間の音声による会議接続を行う機能を有する。電話会議サーバＣＶ１は、電話会議機能を有し、複数のＣＰコンテナに会議用リソースを提供する共通リソースサーバとして使用する。

ウェブ会議サーバＣＳＶ２は、契約を結んだ上記ユーザサイトＵＳ１のＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ間の映像等のメディアを用いた会議接続を行う機能を有する。ウェブ会議サーバＣＳＶ２は、ウェブ会議機能を有し、複数のＣＰコンテナに会議用リソースを提供する共通リソースサーバとして使用する。

図１に戻って、運用支援サーバＣＳＶ３は、ユーザデータベースＤＢに基づいて、仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１及びウェブ会議サーバＣＳＶ２の監視、障害検出、保守、アラーム発報、一括ログ収集、一括データバックアップ、プログラム更新、ＩＰ電話端末のファームウェア更新、ＱＯＳモニタ等を自動的に実行する機能を有する。さらに、自動化のためのインベントリ情報をデータベース管理する機能も有している。

課金管理サーバＣＳＶ４は、ユーザの電話機能の使用量により従量課金する機能を有し、電話サービスプロバイダＴＳＰからユーザ情報を取得し、ユーザに対して課金処理を行う。

プロビジョニングサーバＣＳＶ５は、電話サービスプロバイダＴＳＰからユーザが購入したライセンス情報を取得し、購入ライセンス数に応じて通話機能、電話会議機能、ウェブ会議機能のリソースを割り当てる機能を有する。具体的には、通話機能についてはライセンス数に応じた数のＩＰ電話端末（ＩＰＴ）、ＩＰトランク回線を割り当てる。また、ライセンスを取得したユーザに応じて、電話会議機能及びウェブ会議機能、または電話会議サーバ、ウェブ会議サーバの使用可否を設定する。

さらに、データセンタＤＣ１には、電話サービスポータルサイトＣＳＶ６が設けられる。電話サービスポータルサイトＣＳＶ６は、見積もり作成機能、発注書作成機能、Ａｄｍｉｎコンテナへのリンク機能、見積もり確定機能を備える。見積もり作成機能は、保守業者ＭＴにてユーザの要求を元に、必要な機器、数量、サービスが入力されると、見積もり金額を算出する。この状態で、保守業者ＭＴにて「ｓｕｂｍｉｔ」ボタンが押されると、見積もりを確定し、ユーザに見積もり確認のメールを送信する。

発注書作成機能は、保守業者ＭＴにてユーザの見積もり確定により、電話サービスプロバイダＴＳＰへの発注がなされると（「ｓｕｂｍｉｔ」ボタンが押されると）、電話サービスプロバイダＴＳＰへライセンス発行要求を送信し、ＩＰ電話機、ルータ、ゲートウェイ等の発注指示を送信する。そして、発注書作成機能は、プロビショニングサーバＣＳＶ５に対し、ＣＰコンテナ生成指示を送信する。このとき、内線数、外線数、会議チャンネル数を通知する。

Ａｄｍｉｎコンテナへのリンク機能は、保守コンソールを開くためのリンクである。見積もり確定機能は、保守業者ＭＴが作成した見積もりに対して認証し、ユーザが「ｓｕｂｍｉｔ」ボタンを押すことで、保守業者ＭＴへ見積もり確認メールを送信する。

インターネットＩＮＷ上の保守業者ＭＴは、電話サービスポータルサイトＣＳＶ６を使用して、見積もりの作成、電話サービスプロバイダＴＳＰへの発注依頼を行う。ユーザサイトＵＳ１〜ＵＳｍは、電話サービスポータルサイトＣＳＶ６を使用して、見積もり、認証を行う。

さらに、電話サービスプロバイダＴＳＰには、ライセンス管理サーバＣＳＶ８、受発注システムＣＳＶ９及びユーザ管理サーバＣＳＶ１０が接続される。これらライセンス管理サーバＣＳＶ８、受発注システムＣＳＶ９及びユーザ管理サーバＣＳＶ１０は、ルータＤＲＴを介してインターネットＩＮＷに接続される。

図３は、プロビジョニングサーバＣＳＶ５に設けられる、ユーザデータベースＤＢである。このユーザデータベースＤＢには、各ユーザごとに割り当てられた個別識別番号（ユーザＩＤ）に対応付けて、ユーザに割り当てられたＩＰアドレス、後述するがユーザの設定リソース（設定可能なリソースも含む）、ユーザに付与された秘密情報としての機器識別番号、認証情報としてのパスワード、ログイン中のＩＰ電話端末ＩＰＴ１，ＩＰＴ２、ログイン中のＩＰ電話端末ＩＰＴ１，ＩＰＴ２のシリアルナンバーがそれぞれ記憶されている。ここで、設定リソースの例としては、通話機能、ボイスメール機能、緊急通話機能、電話会議機能、ウェブ会議機能等が挙げられる。

また、運用支援サーバＣＳＶ３、課金管理サーバＣＳＶ４及びプロビジョニングサーバＣＳＶ５は、例えばインターネットＩＮＷを介して電話サービスプロバイダＴＳＰに接続される。

次に、データセンタの仮想化構成と、ディーラやユーザとの対応関係について、説明する。

図４は、保守業者ＭＴ（図中ディーラと表記）とユーザとの関係を、Ａｄｍｉｎコンテナ、ＣＰコンテナ、電話会議リソース、ｗｅｂ会議リソースとの関係に対比させた図である。図４において、それぞれのディーラには、１つのＡｄｍｉｎコンテナが割り当てられている。

あるディーラは、複数のユーザを管理するため、１つのＡｄｍｉｎコンテナは複数のＣＰコンテナとの関連を有する。

ユーザサイトＵＳ１〜ＵＳｍには、ＣＰコンテナが割り当てられている。例えば１０台の内線端末がある場合は、１つのＣＰコンテナに１０台の端末を収容して使用することになる。

次に、上記構成における動作について説明する。
（ユーザシステムの登録）
まず、ユーザが本実施形態のシステムを利用するためには、ディーラが商談を行う。商談では、ディーラがユーザから、必要な内線端末数、外線数や、付加機能（電話会議機能、ウェブ会議機能等）を使用するかを質問することで、見積もりを作成する。ユーザシステムの見積もりは、保守業者ＭＴが電話サービスプロバイダＴＳＰの運営する電話サービスポータルサイトＣＳＶ６の見積もり作成機能を使用して作成する。

保守業者ＭＴが見積もり内容を入力し、登録操作を行うことで、例えばメールサーバＭＳＶからユーザサイトＵＳ１へ電子メールが送信される。送信メールには、ユーザが電話サービスポータルサイトＣＳＶ６の見積もり確定ページへアクセスするためのユーザＩＤとパスワード、ｗｅｂページのリンク先が記載されている。そして、ユーザはこのリンク先をクリックすることで電話ポータルサイトＣＳＶ６の見積もり確定ページへと導かれ、見積もりの詳細（機器の数量、月額の使用料金、初期手数料）を確認し、希望する内容であれば、承認ボタンを押すことで、見積もりが確定する。

ユーザが見積もりを確定することで、保守事業者ＭＴにメールサーバＭＳＶから電子メールが送信され、これにより保守業者ＭＴは見積もりが確定したことを知る。

保守事業者ＭＴは電話サービスポータルサイトＣＳＶ６の発注書作成ページを開く。この発注書作成ページには、ユーザの見積もり承認を受けた内容が示されており、保守事業者が発注要求ボタンを押すことで、以下の発注処理がスタートする。

見積もり発注サーバＣＳＶ７から電話サービスプロバイダＴＳＰのライセンス管理サーバＣＳＶ８にライセンス発行要求が送信される（図１（１））。すると、ライセンス管理サーバＣＳＶ８から見積もり発注サーバＣＳＶ７へ、ライセンス情報が送信される（図１（２））。

見積もり発注サーバＣＳＶ７から電話サービスプロバイダＴＳＰのＩＰ電話機、ルータ、ゲートウェイ等の受発注システムＣＳＶ９に発注を行う（図１（３））。ユーザ管理サーバＣＳＶ１０は、上記受発注から在庫の存在状況を確認した上で、発注結果を見積もり発注サーバＣＳＶ７へ送信する（図１（４））。見積もり発注サーバＣＳＶ７は、電話サービスポータルサイトＣＳＶ６の発注結果表示ページの発注結果欄に表示し、保守業者ＭＴに対し発注が完了したか、在庫不足による納品待ちを知らせる。

見積もり発注サーバＣＳＶ７は、プロビジョニングサーバＣＳＶ５に対して、ユーザシステムのデータ設定要求を送信する。データ設定要求を受けたプロビジョニングサーバＣＳＶ５は、ハードウェアノードの中からＣＰコンテナまたは、Ａｄｍｉｎコンテナの収容数の最も少ないハードウェアノードを選択し、そのハードウェアノードに対して、以下の順で処理を行う。

（１）仮想サーバを生成する。
（２）仮想サーバ上にＣＰコンテナソフトウェアを展開する。
（３）アプリケーションソフトウェアを起動する。
（４）運用データ（基本機能を動作させるためのデフォルトデータ）を設定する。
（５）ライセンス管理サーバＣＳＶ８から発行されたライセンス情報を適用する。

そして、プロビジョニングサーバＣＳＶ５は、電話会議機能やウェブ会議機能の使用可否の設定も行う。

このような設定が完了することで、ユーザが通話機能、電話会議機能またはウェブ会議機能を使用できるようになる。

（ログイン動作）
図５は、例えばＩＰ電話端末ＩＰＴ１が目的とするＣＰコンテナに収容されるまでのＣＰコンテナの制御手順を示すフローチャートである。

ユーザは、ＩＰ電話端末ＩＰＴ１を目的のＣＰコンテナに収容するために必要な準備として、電話サービスポータルサイトＣＳＶ６のＩＰＴ端末登録ページを開いてユーザのシステムＩＤ（コンテナＩＤ）とＩＰ電話端末ＩＰＴ１に割り当てられたシリアルナンバーを登録する。このデータはプロビジョニングサーバＣＳＶ５のユーザデータベースＤＢに登録される。通常、保守業者が設置作業の一部として請け負う。

ユーザは、ＩＰ電話端末を収容するネットワークにＤＨＣＰサーバを配置し、ＩＰ電話端末ＩＰＴ１のＩＰアドレスとＤＮＳサーバのＩＰアドレスを返すよう設定しておく。

上記の事前準備がなされた状態で、ネットワークにＩＰ電話端末を接続すると、ＩＰ電話端末ＩＰＴ１はＤＨＣＰサーバからＩＰアドレスを取得し、自端末のＩＰアドレスとする。また、ＤＨＣＰサーバから、ＤＮＳサーバのＩＰアドレスを取得する。

ここで、収容先のＣＰコンテナを探す必要があるか否かを判定するために、工場出荷時のデータが残っているかどうかを確認する。ＩＰ電話端末の内線番号がブランク、接続先ＣＰコンテナのＩＰアドレスが０．０．０．０を示していることで、工場出荷状態と判断する。

次に、ＩＰ電話端末ＩＰＴ１において、ユーザは、収容先ＣＰコンテナのＩＰアドレスを得るために、プロビジョニングサーバＣＳＶ５に対し、ＣＰコンテナのＩＰアドレス取得を要求する。このとき、ＩＰ電話端末ＩＰＴ１は、プロビジョニングサーバＣＳＶ５のＩＰアドレスを得るために、プロビジョニングサーバＣＳＶ５のホスト名を用いてＤＮＳアドレスを解決することで、ＩＰアドレスを得る。

プロビジョニングサーバＣＳＶ５は、ＩＰ電話端末ＩＰＴ１からＣＰコンテナのＩＰアドレス取得要求を受けると、ユーザデータベースＤＢから該当するシリアルナンバーを持ったＩＰＴ内線を探し出し、その端末を収容するＣＰコンテナのＩＰアドレスを導出し、これをＣＰコンテナのＩＰアドレス応答メッセージに含めてＩＰ電話端末ＩＰＴ１へ送り返す。

ＩＰ電話端末ＩＰＴ１は、取得したＣＰコンテナのＩＰアドレスを自身で記憶し、それを使ってＣＰコンテナと通信し収容手続きを行う。まず、ＣＰコンテナは、ＩＰ電話端末ＩＰＴ１からログイン要求が到来すると（ステップＳＴ５ａ−１），ユーザに内線番号の入力を促す（ステップＳＴ５ａ−２）。ユーザは、ＩＰ電話端末ＩＰＴ１のダイヤルパッドを操作して内線番号を入力し、入力完了ボタンを押す。

次に、ＩＰ電話端末ＩＰＴ１は、ユーザーにパスワードの入力を促す。パスワードの入力を終了すると、内線番号とパスワードをＩＰ電話端末ＩＰＴ１内部のメモリに記憶し、登録要求メッセージに内線番号とパスワードを含めてＣＰコンテナに送信する。

ＣＰコンテナは、登録要求メッセージを受信すると（ステップＳＴ５ａ−３）、内線番号が正しいか否かをチェックし（ステップＳＴ５ｂ）、正しくなければ（ＮＧ）、エラーメッセージをＩＰ電話端末ＩＰＴ１に返送し（ステップＳＴ５ｃ）、正しければ（ＯＫ）、当該内線番号がすでに使用状態でないか否かをチェックする（ステップＳＴ５ｄ）。ここで、当該内線端末が未使用状態であれば（ＯＫ）、ＣＰコンテナは、パスワードをチェックし（ステップＳＴ５ｅ）、パスワードが正しければ（ＯＫ）、パスワードをユーザデータベースＤＢのパスワードフィールドに記憶し、ログインを許可し登録許可メッセージをＩＰ電話端末ＩＰＴ１へ返す（ステップＳＴ５ｆ）。

登録許可メッセージを受信したＩＰ電話端末ＩＰＴ１は、ログイン状態となり以降ユーザの操作により、ＣＰコンテナと通信を行い、ログイン状態つまり呼制御サービスが提供可能な状態となる。

（通話動作）
図６は、例えばＩＰ電話端末ＩＰＴ１と公衆網ＮＷ１上の電話端末ＴＴ１との間で通信接続を行なう手順を示すシーケンス図である。

いま例えば、ログイン中のＩＰ電話端末ＩＰＴ１においてユーザが、ＩＰ電話端末ＩＰＴ１から他の外部電話端末ＴＴ１に対し発信操作を行なったとする（図６（１））。そうするとＩＰ電話端末ＩＰＴ１のオフフック信号は、ＩＰ電話端末ＩＰＴ１を収容するＣＰコンテナ（ＣＰ１）へ送信される。

このオフフック信号は、ＣＰコンテナ（ＣＰ１）上で処理される。ここでは、ＩＰ電話端末ＩＰＴ１が空き状態からのオフフック操作であるので発信処理が起動され、ＩＰ電話端末ＩＰＴ１に対する発信処理が実行される。

そして、このＣＰコンテナ（ＣＰ１）からＩＰ電話端末ＩＰＴ１へダイヤルトーン送出を指示する信号が送信される。また、ＣＰコンテナ（ＣＰ１）は、ＩＰ電話端末ＩＰＴ１からのダイヤル操作を受け取る状態になる。

この状態で、ダイヤルトーンを確認したＩＰ電話端末ＩＰＴ１のユーザがダイヤル操作を行なうと、ダイヤル信号はＣＰコンテナ（ＣＰ１）に通知され、ダイヤル分析処理される。ＩＰ電話端末ＩＰＴ１のダイヤルが連続操作される毎に、ＣＰコンテナ（ＣＰ１）において、ダイヤル分析が繰り返され、方路（外線トランク）が決定するまでダイヤル分析を続ける。

方路（外線トランク）が決定すると、ＣＰコンテナ（ＣＰ１）からＳＩＰ公衆網ＮＷ１に対して発信メッセージが送信される。発信メッセージは、ゲートウェイＧＷ１を経由してＳＩＰ公衆網ＮＷ１へと転送される（図６（２））。ＳＩＰ公衆網ＮＷ１では、加入者からの発信メッセージを適切に処理し、他方の加入者端末ＴＴ１を呼び出すために、呼び出しメッセージを送信する。呼び出しメッセージを受信した加入者端末ＴＴ１は、着信鳴動する（図６（３））。呼び出しに対し加入者端末ＴＴ１が応答すると（図６（４））、応答メッセージがＳＩＰ公衆網ＮＷ１に送信される。ＳＩＰ公衆網ＮＷ１は、発信側加入者に対して、応答メッセージを送信する。応答メッセージは、ゲートウェイＧＷ１を経由して、データセンタＤＣ１内のＣＰコンテナ（ＣＰ１）へ送信される。

ＣＰコンテナ（ＣＰ１）は、発信元のＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１との間の通信パスを接続するための処理を実行する（図６（５））。かくして、ＩＰ電話端末ＩＰＴ１のユーザは加入者端末ＴＴ１のユーザとの間で通話を行なうことが可能となる。

次に、ＩＰ電話端末ＩＰＴ１においてユーザが加入者端末ＴＴ１との通話中に、ＩＰ電話端末ＩＰＴ２を会議通話に加える操作を行った場合のＣＰコンテナ（ＣＰ１）内の電話会議メディアリソースの使用方法を説明する。

ＩＰ電話端末ＩＰＴ１のユーザがＩＰ電話端末ＩＰＴ１の会議ボタンを操作することで、その操作がＣＰコンテナ（ＣＰ１）に通知される。会議ボタン操作を検出したＣＰコンテナ（ＣＰ１）はＩＰ電話端末ＩＰＴ１の音声ストリームを切断する指示をＩＰ電話端末ＩＰＴ１に送信するとともに、同じくＩＰ電話端末ＩＰＴ１に対してダイヤルトーンを生成する制御信号を送信する。

さらに、ＣＰコンテナ（ＣＰ１）は、電話会議機能からメディアリソースを１チャネル捕捉し（Ch-i）、そのチャネルに対して保留音を再生し、再生した音声ストリームをＳＩＰ公衆網ＮＷ１のCh-Xに対して流す指示を行う。以上により、加入者端末ＴＴ１は保留音を聴取する。

ＩＰ電話端末ＩＰＴ１のユーザはダイヤルトーンを聞いた後、会議メンバーを呼び出すためにダイヤルを操作する。ダイヤル操作は、ＣＰコンテナ（ＣＰ１）に通知され、会議メンバーを特定したところでメンバー（ここではＩＰ電話端末ＩＰＴ２）を呼び出す。

ＩＰ電話端末ＩＰＴ２が呼び出しに応答すると、ＣＰコンテナ（ＣＰ１）はＩＰ電話端末ＩＰＴ１とＩＰ電話端末ＩＰＴ２との間の音声ストリームを形成する。この状態から、ＩＰ電話端末ＩＰＴ１のユーザが会議ボタンを操作すると、ＣＰコンテナ（ＣＰ１）はまず、メディアリソース（Ch-i）に保留音の停止を指示し、メディアリソース（Ch-i）を開放する。

次に、ＣＰコンテナ（ＣＰ１）は、電話会議機能から会議メンバー数分のメディアリソース（ここでは３チャネル）を捕捉する。ＣＰコンテナ（ＣＰ１）はメディアリソース（Ch-i,j,k）に対して会議接続を指示し、メディアリソース（Ch-i）とＩＰ電話端末ＩＰＴ１との間で音声ストリームを形成するよう指示し、メディアリソース（Ch-j）とＩＰ電話端末ＩＰＴ２との間で音声ストリームを形成するよう指示し、メディアリソース（Ch-k）とＳＩＰ公衆網ＮＷ１のリソース（Ch-X）との間で音声ストリームを形成するよう指示する。これにより、外部ユーザの加入者端末ＴＴ１を交えた３者会議を構成する。

会議メンバーの終話操作により、ＣＰコンテナ（ＣＰ１）はメディアリソース（Ch-i,j,k）を開放し、音声ストリームを切断する。

（トラフィック増減に伴うＣＰコンテナの移動）
図７は、ＩＰ電話端末ＩＰＴ１と仮想化ホストサーバとの間で登録先変更処理を行う動作を示すシーケンス図である。

いま、ＩＰ電話端末ＩＰＴ１は、仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）に登録されているとする。この状態において、運用支援サーバＣＳＶ３は、仮想化ホストサーバＮ１〜Ｎｐの負荷を定期的に計測する（図７（１））。また、運用支援サーバＣＳＶ３は、ＣＰコンテナの負荷を定期的に計測する（図７（２）。

ここで、運用支援サーバＣＳＶ３は、仮想化ホストサーバＮ１の負荷が閾値を超えたと判断したとき（図７（３））、当該仮想化ホストサーバＮ１に収容するＣＰコンテナ（ＣＰ１〜ＣＰ３）の中でもっとも負荷の低いＣＰコンテナから順に移動リストに登録する（図７（４））。

以後、運用支援サーバＣＳＶ３は夜間負荷の下がる時間帯に、移動リストに登録されたＣＰコンテナがあれば、そのＣＰコンテナに通話中呼がないか、保守作業が行われていないかをチェックし（図７（５））、いずれもなければ、当該ＣＰコンテナの運用データをバックアップする。そして、運用支援サーバＣＳＶ３は最頻負荷のもっとも低い仮想化ホストサーバＮ１８へＣＰコンテナを作成し（図７（６））、先にバックアップした運用データを復元する。

仮想化ホストサーバＮ１８のＣＰコンテナは、運用データの復元が完了すると（図７（７））、運用支援サーバＣＳＶ３に対し完了の旨を通知する（図７（８））。運用支援サーバＣＳＶ３は、ＣＰコンテナのデータ復元が完了したところで、移動後のＣＰコンテナのホスト名と実ＩＰアドレスの関係をＤＮＳサーバに登録する（図７（９））。

運用支援サーバＣＳＶ３は、移動したＣＰコンテナに収容するＩＰ電話端末ＩＰＴ１〜ＩＰＴｎのすべてに対し、登録変更通知を送り、変更後のＣＰコンテナに再登録するよう促す（図７（１０））。

登録変更通知を受信したＩＰ電話端末ＩＰＴ１は、移動後のＣＰコンテナに対して、再登録要求を送信する（図７（１１））。仮想化ホストサーバＮ１８のＣＰコンテナは、再登録要求のあったＩＰ電話端末ＩＰＴ１に対し登録を行って、応答をＩＰ電話端末ＩＰＴ１に返送する（図７（１２））。

運用支援サーバＣＳＶ３は、移動リストから当該ＣＰコンテナを削除し、移動リストにＣＰコンテナがなくなるまで繰り返す（図７（１３））。

これにより、ＩＰ電話端末ＩＰＴ１は、移動後のＣＰコンテナに登録された状態となる（図７（１４））。

以上のように、仮想化ホストサーバＮ１〜Ｎｐ内の最頻負荷を考慮しながらＣＰコンテナを再配置することで、ユーザの契約では推測できない使用頻度を、実際の運用を行うことでトラフィックを知り、負荷の低いＣＰコンテナを移動すること、かつ、呼の存在や保守状態を確認することでユーザに対し運用に影響がなく安全な移動が可能となる。

（通信中にＣＰコンテナに障害が発生した際の通信切替動作）
図８は、ＣＰコンテナに障害が発生した際のＩＰ電話端末ＩＰＴ１とＣＰコンテナとの間における通信切替動作を示すシーケンス図である。

ここで、ＩＰ電話端末ＩＰＴ１のユーザがスタンバイサービスを希望する場合、運用支援サーバＣＳＶ３はスタンバイ用のＣＰコンテナ（ＣＰ２）を生成し、運用データをＣＰコンテナＣＰ２にダウンロードしておく（図８（０１））。

いま、内線端末としてのＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間で仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）を介して通話が行われているものとする（図８（１））。この状態で、ＩＰ電話端末ＩＰＴ１はＣＰコンテナ（ＣＰ１）の障害監視を行っている。障害監視の手法としては、通信中に仮想化ホストサーバＮ１のAdminコンテナ（Admin１）でＣＰコンテナ（ＣＰ１）の障害を検出し、この検出結果を受信できるか否かを監視するものが用いられる。

さて、この状態でＣＰコンテナ（ＣＰ１）において障害が発生し、この障害の発生がＩＰ電話端末ＩＰＴ１で検出されたとする（図８（２））。そうするとＩＰ電話端末ＩＰＴ１は、仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ２）に通信を転送させるべく、ＣＰコンテナ（ＣＰ２）へ接続要求信号を送信する（図８（３））。

これに対しＣＰコンテナ（ＣＰ２）は、ＩＰ電話端末ＩＰＴ１から接続要求信号を受信すると、ＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間の通信を引き継ぐ処理を開始する。そして、ＣＰコンテナ（ＣＰ２）はＩＰ電話端末ＩＰＴ１に対し接続受付信号を送信する（図８（４））。このときこの接続受付信号には、通信の引き継ぎが成功したことを示す情報、例えば「正常」が、解放理由として挿入される。ＩＰ電話端末ＩＰＴ１はこの情報により通信が正しく引き継がれた旨を認識できる。

かくして、ＣＰコンテナ（ＣＰ１）からＣＰコンテナ（ＣＰ２）に切り替わり、以後ＣＰコンテナ（ＣＰ２）を介してＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間で引き続き通話が可能となる。

なお、上記では、同一の仮想化ホストサーバＮ１に生成されたＣＰコンテナ（ＣＰ２）に通信サービスを引き継ぐ例について説明したが、別の仮想化ホストサーバＮ２のＣＰコンテナ（ＣＰ４）に通信サービスを引き継ぐようにしてもよい。

以上のように上記第１の実施形態では、複数のユーザサイトＵＳ１〜ＵＳｍをインターネットＩＮＷを介してデータセンタＤＣ１に収容するようにし、各ユーザサイトＵＳ１〜ＵＳｍそれぞれに通常備えられるアプライアンス型ＩＰ電話サーバを、データセンタＤＣ１に既に備えられる仮想化ホストサーバＮ１〜Ｎｐにより共用するようにしている。そして、複数台の仮想化ホストサーバＮ１〜Ｎｐを複数のＣＰコンテナに分割して、ＣＰコンテナ（ＣＰ１）をユーザサイトＵＳ１専用に割り当て、ＣＰコンテナ（ＣＰ２）をユーザサイトＵＳ２専用に割り当てるようにし、ユーザサイトＵＳ１，ＵＳ２に対しＣＰコンテナ（ＣＰ１）、（ＣＰ２）によりインターネットＩＮＷを介して任意の通信サービスを提供するようにしている。

従って、各ユーザサイトＵＳ１〜ＵＳｍには専用のアプライアンス型ＩＰ電話サーバが不要となり、またアプライアンス型ＩＰ電話サーバのメンテナンスのために保守サービス担当者の出張及び手作業が一切不要となり、これにより設備費用を低減できる。一方、データセンタＤＣ１にとっては、ユーザサイトＵＳ１〜ＵＳｍごとに専用のサーバを別途用意する必要がなく、これにより簡易な構成で、かつ安価なデータセンタＤＣ１を提供することができる。さらに、データセンタＤＣ１にとっては、仮想化ホストサーバＮ１〜Ｎｐを複数のＣＰコンテナに分割することにより、通話機能に特化したＣＰＵ使用量、メモリ使用量、ディスク使用量を小さくすることができる。

また、上記第１の実施形態によれば、１台の仮想化ホストサーバＮ１に登録されているユーザサイトＵＳ１，ＵＳ２のトラフィックが増えた場合、例えば空いている仮想化ホストサーバＮ１８にユーザサイトＵＳ１，ＵＳ２を登録させることにより、仮想化ホストサーバＮ１の処理負担を軽減できる。また、仮想化ホストサーバＮ１に登録されているユーザサイトＵＳ１による使用量が少ない場合、ユーザサイトＵＳ１を例えば仮想化ホストサーバＮ２に統合して登録することにより、動作不要な仮想化ホストサーバＮ１を作ることができ、この仮想化ホストサーバＮ１を省電力モードに変更することで、データセンタＤＣ１全体の消費電力を低減できる。

さらに、上記第１の実施形態によれば、ＣＰコンテナ（ＣＰ１）に障害が発生して通信サービスの継続が不可能になった場合でも、ユーザサイトＵＳ１に対して正常なＣＰコンテナ（ＣＰ２）により通信サービスの提供が継続される。

（第２の実施形態）
第２の実施形態は、電話会議機能及びウェブ会議機能を専用のサーバにより動作させるようにしたものである。

図９は、第２の実施形態における仮想化ホストサーバＮ１〜Ｎｐ、電話会議サーバＣＳＶ１及びウェブ会議サーバＣＳＶ２の具体的構成を示す図である。

１台の仮想化ホストサーバＮ１内に仮想環境があり、その上で仮想サーバーが複数動作する。ここで、電話会議サーバＣＳＶ１は仮想化せず実サーバで動作させる。電話会議サーバＣＳＶ１は、電話会議機能を有し、複数のＣＰコンテナから共有可能である。電話会議サーバーは複数台存在可である。

ウェブ会議サーバＣＳＶ２も仮想化せず実サーバで動作させる。ウェブ会議サーバＣＳＶ２は、ウェブ会議機能を有し、複数のＣＰコンテナから共有可能である。ウェブ会議サーバＣＳＶ２は複数台存在可である。

先の第１の実施形態では、電話会議機能やウェブ会議機能は、ＣＰコンテナ内に存在していた。本第４の実施形態では、電話会議機能（以下、電話会議アプリケーションと称する）やウェブ会議機能（以下、ウェブ会議アプリケーションと称する）を呼制御アプリケーションから独立して構成できるよう、以下のようにしている。

（１）会議制御用のインターフェースをＩＰネットワーク上のメッセージ通信を使うよう、かつ会議参加メンバーのＩＰエンドポイントとの音声パケットの通信を電話会議アプリケーションが主体となって制御する。
（２）会議回線数は電話会議アプリケーションが管理し、呼制御アプリケーションが電話会議アプリケーションから必要な会議回線数を取得要求する。
（３）電話会議アプリケーションの会議回線最大数には制限を設けずに、電話会議アプリケーションを搭載するサーバハードウェアの処理能力により回線数の上限を変更できる。

電話会議サーバＣＳＶ１は、電話会議機能を専用に提供するサーバである。先の第１の実施形態の場合に比べ、本第２の実施形態では、サーバの処理能力を強化し、電話会議サーバＣＳＶ１が提供する会議回線数を増やしている。この構成により、以下の効果が得られる。

（１）ＣＰコンテナから電話会議アプリケーションを取り除くことで、コンテナのファイルシステム容量を減らすことができ、仮想化ホストサーバＮ１〜Ｎｐ内のＣＰコンテナの集積率を向上できる。

（２）ＣＰコンテナから電話会議アプリケーションを取り除くことで、処理能力を消費する音声処理を排除でき、仮想化ホストサーバＮ１〜Ｎｐ内のＣＰコンテナの集積率を向上できる。

（３）電話会議アプリケーションは、ユーザの使用形態、業務形態により会議回線の消費量が異なることから、ＣＰコンテナ間で融通すること、つまり専用サーバで処理することで、仮想化ホストサーバＮ１〜Ｎｐ全体で必要な会議回線数を減らすことが可能。これが、必要なサーバ数の低減（運用コストの低減）につながる。

次に、上記構成における動作について説明する。

いま、例えばＩＰ電話端末ＩＰＴ１においてユーザが、加入者端末ＴＴ１との通話中に、ＩＰ電話端末ＩＰＴ２を会議通話に加える操作を行ったとする。すると、その操作がＣＰコンテナ（ＣＰ１）に通知される。会議ボタン操作を検出したＣＰコンテナ（ＣＰ１）はＩＰ電話端末ＩＰＴ１の音声ストリームを切断する指示をＩＰ電話端末ＩＰＴ１に送信するとともに、同じくＩＰ電話端末ＩＰＴ１に対してダイヤルトーンを生成する制御信号を送信する。

さらに、ＣＰコンテナ（ＣＰ１）は、電話会議サーバＣＳＶ１からメディアリソースを１チャネル捕捉し（Ch-i）、そのチャネルに対して保留音を再生し、再生した音声ストリームをＳＩＰ公衆網ＮＷ１のCh-Xに対して流す指示を行う。以上により、加入者端末ＴＴ１は保留音を聴取する。

ＩＰ電話端末ＩＰＴ１のユーザはダイヤルトーンを聞いた後、会議メンバーを呼び出すためにダイヤルを操作する。ダイヤル操作は、ＣＰコンテナ（ＣＰ１）に通知され、会議メンバーを特定したところでメンバー（ここではＩＰ電話端末ＩＰＴ２）を呼び出す。

ＩＰ電話端末ＩＰＴ２が呼び出しに応答すると、ＣＰコンテナ（ＣＰ１）はＩＰ電話端末ＩＰＴ１とＩＰ電話端末ＩＰＴ２との間の音声ストリームを形成する。この状態から、ＩＰ電話端末ＩＰＴ１のユーザが会議ボタンを操作すると、ＣＰコンテナ（ＣＰ１）はまず、メディアリソース（Ch-i）に保留音の停止を指示し、メディアリソース（Ch-i）を開放する。

次に、ＣＰコンテナ（ＣＰ１）は、電話会議サーバＣＳＶ１から会議メンバー数分のメディアリソース（ここでは３チャネル）を捕捉する。ＣＰコンテナ（ＣＰ１）はメディアリソース（Ch-i,j,k）に対して会議接続を指示し、メディアリソース（Ch-i）とＩＰ電話端末ＩＰＴ１との間で音声ストリームを形成するよう指示し、メディアリソース（Ch-j）とＩＰ電話端末ＩＰＴ２との間で音声ストリームを形成するよう指示し、メディアリソース（Ch-k）とＳＩＰ公衆網ＮＷ１のリソース（Ch-X）との間で音声ストリームを形成するよう指示する。これにより、外部ユーザの加入者端末ＴＴ１を交えた３者会議を構成する。

会議メンバーの終話操作により、ＣＰコンテナ（ＣＰ１）はメディアリソース（Ch-i,j,k）を開放し、音声ストリームを切断する。

以上のように上記第２の実施形態によれば、先の第１の実施形態と同様な作用効果を得ることができ、例えば電話会議機能が設定された電話会議サーバＣＳＶ１、ウェブ会議機能が設定されたウェブ会議サーバＣＳＶ２を、複数のユーザサイトＵＳ１〜ＵＳｍで共有することができるので、データセンタＤＣ１全体としてサーバの必要台数を減らすことができる。

（第３の実施形態）
（顧客群の増加に伴うＣＰコンテナの追加）
ここで、ディーラ１はユーザサイトＵＳ１を管理し、ディーラ２はユーザサイトＵＳ２，ＵＳ３を管理し、ディーラ３はユーザサイトＵＳ４〜ＵＳ１２を管理しているものとする。さらに、契約する新たな顧客がこれから増える場合、クラウド上のデータセンタＤＣ１を運営する例えば電話サービスプロバイダＴＳＰは、新たなディーラ４に保守作業委託を行う必要がある。

図１０は、顧客の増加に伴い、例えば空きの仮想化ホストサーバＮ４にＡｄｍｉｎコンテナ（Admin 4）及びＣＰコンテナを設定する際のユーザサイトＵＳ１３と、プロビジョニングサーバＣＳＶ５と、仮想化ホストサーバＮ４との間における動作を示すシーケンス図である。

クラウド上のデータセンタＤＣ１を運営する例えば電話サービスプロバイダＴＳＰは、空いている仮想化ホストサーバを検出し、例えば空きの仮想化ホストサーバＮ４にＡｄｍｉｎコンテナ（Admin 4）を設定する（図１０（１））。そして、電話サービスプロバイダＴＳＰは、新たに契約する顧客（ユーザ）が購入希望するライセンスを、Ａｄｍｉｎコンテナ（Admin 4）を所有するディーラに販売委託する。

ユーザサイトＵＳ１３のユーザは、Ａｄｍｉｎコンテナ（Admin 4）を所有するディーラと保守契約してライセンスを購入する（図１０（２））。

ディーラは、ユーザとの契約内容に応じて、ユーザサイトＵＳ１３のパーソナル・コンピュータを操作し、契約したユーザの個別識別番号、ユーザに割り当てられたＩＰアドレス、ユーザが希望する設定リソース（設定可能なリソースも含む）、ユーザに付与された機器識別番号、パスワードを含む登録要求をクラウド上のデータセンタＤＣ１のプロビジョニングサーバＣＳＶ５へ送信する（図１０（３））。

データセンタＤＣ１のプロビジョニングサーバＣＳＶ５は、ユーザサイトＵＳ１３から登録要求を受信すると、登録要求に含まれるユーザの個別識別番号、ＩＰアドレス、ユーザが希望する設定リソース、機器識別番号、パスワードを、ユーザデータベースＤＢに登録する（図１０（４））。

ユーザサイトＵＳ１３の操作に対応して、データセンタＤＣ１のプロビジョニングサーバＣＳＶ５は、仮想化ホストサーバＮ４のＡｄｍｉｎコンテナ（Admin 4）を制御して、必要なＣＰコンテナ（ＣＰ１３）を仮想化ホストサーバＮ４上に生成する（図１０（５））。また、電話会議機能やウェブ会議機能の使用可否の設定も行う。

仮想化ホストサーバＮ４は、ＣＰコンテナ（ＣＰ１３）の設定処理が終了すると、設定処理が正常に終了した旨の応答をプロビジョニングサーバＣＳＶ５に返送する（図１０（６））。プロビジョニングサーバＣＳＶ５は、上記設定処理が正常に終了した旨の応答を受信すると、ユーザサイトＵＳ１３のパーソナル・コンピュータへ上記設定処理が正常に終了した旨の応答を送信する（図１０（７））。

かくして、ユーザサイトＵＳ１３のユーザは、クラウド上のデータセンタＤＣ１内のＣＰコンテナ（ＣＰ１３）を使用可能となる。

さらに、ユーザサイトＵ１４のユーザは、Ａｄｍｉｎコンテナ（Admin 4）を所有するディーラと契約してライセンスを購入したとする。すると、ディーラは、ユーザとの契約内容に応じて、ユーザサイトＵＳ１４のパーソナル・コンピュータを操作し、契約したユーザの情報をユーザデータベースＤＢに登録する。

ユーザサイトＵＳ１４の操作に対応して、データセンタＤＣ１のプロビジョニングサーバＣＳＶ５は、仮想化ホストサーバＮ４のＡｄｍｉｎコンテナ（Admin 4）を制御して、必要なＣＰコンテナ（ＣＰ１４）を仮想化ホストサーバＮ４に生成する。

一方、仮想化ホストサーバＮ４がＣＰコンテナ（ＣＰ１３）〜（ＣＰ１６）で埋まってしまったとする。この状態で、例えばユーザサイトＵ１７のユーザが、Ａｄｍｉｎコンテナ（Admin 4）を所有するディーラと契約してライセンスを購入したとする。すると、ディーラは、ユーザとの契約内容に応じて、ユーザサイトＵＳ１７のパーソナル・コンピュータを操作し、契約したユーザの情報をユーザデータベースＤＢに登録する。

ユーザサイトＵＳ１７の操作に対応して、データセンタＤＣ１のプロビジョニングサーバＣＳＶ５は、仮想化ホストサーバＮ４のＡｄｍｉｎコンテナ（Admin 4）を制御して、必要なＣＰコンテナ（ＣＰ１７）を空いている仮想化ホストサーバＮ５に生成する。

（顧客群の減少に伴うＣＰコンテナの削減）
図１１は、仮想化ホストサーバＮ３からＣＰコンテナ（ＣＰ１２）を削除する際のユーザサイトＵＳ１２と、プロビジョニングサーバＣＳＶ５と、仮想化ホストサーバＮ３との間における動作を示すシーケンス図である。

ユーザサイトＵＳ１２のユーザは、Ａｄｍｉｎコンテナ（Admin 3）を所有するディーラとの契約を解除したとする（図１１（１））。

ディーラは、ユーザとの契約内容に応じて、ユーザサイトＵＳ１２のパーソナル・コンピュータを操作し、契約したユーザの個別識別番号を含む登録解除要求をクラウド上のデータセンタＤＣ１のプロビジョニングサーバＣＳＶ５へ送信する（図１１（２））。

データセンタＤＣ１のプロビジョニングサーバＣＳＶ５は、ユーザサイトＵＳ１２から登録解除要求を受信すると、登録解除要求に含まれるユーザの個別識別番号に対応するユーザの情報をユーザデータベースＤＢから削除する（図１１（３））。

ユーザサイトＵＳ１２の操作に対応して、データセンタＤＣ１のプロビジョニングサーバＣＳＶ５は、仮想化ホストサーバＮ３のＡｄｍｉｎコンテナ（Admin 3）を制御して、必要なＣＰコンテナ（ＣＰ１２）を仮想化ホストサーバＮ３から削除する（図１１（４））。また、電話会議機能やウェブ会議機能が設定されている場合には、電話会議機能やウェブ会議機能の設定も解除する。

仮想化ホストサーバＮ３は、ＣＰコンテナ（ＣＰ１２）の削除処理が終了すると、削除処理が正常に終了した旨の応答をプロビジョニングサーバＣＳＶ５に返送する（図１１（５））。プロビジョニングサーバＣＳＶ５は、上記削除処理が正常に終了した旨の応答を受信すると、ユーザサイトＵＳ１２のパーソナル・コンピュータへ上記設定処理が正常に終了した旨の応答を送信する（図１１（６））。

かくして、ユーザサイトＵＳ１２のユーザは、クラウド上のデータセンタＤＣ１内のＣＰコンテナ（ＣＰ１２）を使用不可能となる。

以上のように上記第３の実施形態によれば、ユーザサイトが増加した場合には、増加した分だけＣＰコンテナを仮想化ホストサーバＮ１〜Ｎｐ上に設定し、ユーザサイトＵＳ１〜ＵＳｍが減少した場合には、減少したユーザサイトに対応するＣＰコンテナを、仮想化ホストサーバＮ１〜Ｎｐ上から削除するだけでよいので、専用のサーバを新たに購入したり、使用中のサーバを破棄したりする必要がなく、これにより設備投資にかかる費用は軽減される。

（第４の実施形態）
第４の実施形態は、データセンタに障害が発生した場合に、他の正常なデータセンタにより通信を継続するようにしたものである。

（通信中にデータセンタに障害が発生した際の通信切替動作）
図１２は、データセンタに障害が発生した際のＩＰ電話端末ＩＰＴ１と他のデータセンタとの間における通信切替動作を示すシーケンス図である。

ここで、ＩＰ電話端末ＩＰＴ１のユーザがスタンバイサービスを希望する場合、データセンタＤＣ１の運用支援サーバＣＳＶ３はスタンバイ用のＣＰコンテナを生成するために必要な制御情報を生成し、データセンタＤＣ２へインターネット等の通信網を介して制御情報及び運用データを送信する（図１２（０１））。上記制御情報には、ＩＰ電話端末ＩＰＴ１の内線番号及びＩＰアドレス、使用許可されている機能等が含まれる。データセンタＤＣ２は、上記制御情報及び運用データを受信すると、上記制御情報に基づいて、仮想化ホストサーバにＣＰコンテナを生成し、当該ＣＰコンテナに上記運用データをセットしておく（図１２（０２））。

いま、内線端末としてのＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間で仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）を介して通話が行われているものとする（図１２（１））。この状態で、ＩＰ電話端末ＩＰＴ１はＣＰコンテナ（ＣＰ１）を含むデータセンタＤＣ１の障害監視を行っている。

さて、この状態でデータセンタＤＣ１において障害が発生し、この障害の発生がＩＰ電話端末ＩＰＴ１で検出されたとする（図１２（２））。そうするとＩＰ電話端末ＩＰＴ１は、データセンタＤＣ２のＣＰコンテナに通信を転送させるべく、データセンタＤＣ２のＣＰコンテナへ接続要求信号を送信する（図１２（３））。

これに対しデータセンタＤＣ２のＣＰコンテナは、ＩＰ電話端末ＩＰＴ１から接続要求信号を受信すると、ＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間の通信を引き継ぐ処理を開始する。そして、データセンタＤＣ２のＣＰコンテナはＩＰ電話端末ＩＰＴ１に対し接続受付信号を送信する（図１２（４））。このときこの接続受付信号には、通信の引き継ぎが成功したことを示す情報、例えば「正常」が、解放理由として挿入される。ＩＰ電話端末ＩＰＴ１はこの情報により通信が正しく引き継がれた旨を認識できる。

かくして、データセンタＤＣ１のＣＰコンテナ（ＣＰ１）からデータセンタＤＣ２のＣＰコンテナに切り替わり、以後データセンタＤＣ２のＣＰコンテナを介してＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間で引き続き通話が可能となる。

以上のように上記第４の実施形態によれば、データセンタＤＣ１に障害が発生して通信サービスの継続が不可能になった場合でも、ユーザサイトＵＳ１に対して正常なデータセンタＤＣ２により通信サービスの提供が継続される。

（第５の実施形態）
第５の実施形態は、ユーザサイトがアプライアンス型ＩＰ電話サーバを備えている場合に、クラウド上のデータセンタと、ユーザサイトのアプライアンス型ＩＰ電話サーバと連携して通信サービスを提供するようにしたものである。本第５の実施形態では、最も基本的な機能である通話機能は、ユーザサイトに設けられたアプライアンス型ＩＰ電話サーバを使用し、通話機能以外の機能である、例えば電話会議サービス等、使用頻度が高くない付加機能については、クラウド上のデータセンタのサーバを使用するものである。

図１３は、この第５の実施形態における通信システムの概略構成図である。図１３において、上記図１と同一部分には同一符号を付して、詳細な説明を省略する。

ユーザサイトについては、ユーザサイトＵＳ１〜ＵＳｍのうち、ユーザサイトＵＳ１を代表して説明する。ユーザサイトＵＳ１は、アプライアンス型ＩＰ電話サーバ（以下、ＩＰ電話サーバと称する）ＡＳＶ１を備えている。ＩＰ電話サーバＡＳＶ１は、ＩＰ電話端末ＩＰＴ１〜ＩＰＴｎ相互間及びこれらＩＰ電話端末ＩＰＴ１〜ＩＰＴｎと公衆網ＮＷ１または他のユーザサイトＵＳ２〜ＵＳｍとの間で、例えばＳＩＰ（Session Initiation Protocol）に従ってセッションを確立する交換制御機能を備える。そして、セッション確立後は、発信側と着信側の電話端末間でピアツーピア接続によりＲＴＰパケットを送受信することで、音声通信を行なう。

次に上記構成における動作について説明する。
まず、ユーザが本第５の実施形態のシステムを利用するためには、保守業者を介して電話サービスプロバイダとの契約を行う。契約の内容は、電話会議機能、ウェブ会議機能の使用について、契約を行うことで、ライセンスを受ける。ここで、通常は、ユーザの電話会議、ウェブ会議の使用頻度により必要な回線数を契約する。

ディーラは、ユーザとの契約内容に応じて、ユーザサイトＵＳ１を操作し、契約したユーザの登録を行う。

ユーザサイトＵＳ１の操作に対応して、データセンタＤＣ１のプロビジョニングサーバＣＳＶ５が、仮想化ノードのＡｄｍｉｎコンテナを制御して、電話会議機能やウェブ会議機能の使用可否の設定も行う。なお、ユーザサイトＵＳ１の保守については、プロビジョニングサーバＣＳＶ５は行わず、保守業者ＭＴが手動で設定する。

このような設定が完了することで、ユーザがクラウド上のデータセンタＤＣ１の電話会議機能またはウェブ会議機能を使用できるようになる。

図１４は、ＩＰ電話端末ＩＰＴ１においてユーザが加入者端末ＴＴ１との通話中に、ＩＰ電話端末ＩＰＴ２を会議通話に加える操作を行った場合のデータセンタＤＣ１とユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１との連携動作を示すシーケンス図である。

ＩＰ電話端末ＩＰＴ１においてユーザが加入者端末ＴＴ１との通話中であるとする（図１４（１））。ＩＰ電話端末ＩＰＴ１のユーザが会議ボタンを操作することで（図１４（２））、その操作がＩＰ電話サーバＡＳＶ１に通知される（図１４（３））。会議ボタン操作を検出したＩＰ電話サーバＡＳＶ１は、ＩＰ電話端末ＩＰＴ１の音声ストリームを切断する指示をＩＰ電話端末ＩＰＴ１に送信するとともに、同じくＩＰ電話端末ＩＰＴ１に対してダイヤルトーンを生成する制御信号を送信する。

さらに、ＩＰ電話サーバＡＳＶ１は、電話会議サーバＣＳＶ１に対しメディアリソース捕捉要求を送信して（図１４（４））、電話会議サーバＣＳＶ１からメディアリソースを１チャネル捕捉し（Ch-q）（図１４（５））、メディアリソースチャネル（Ch-q）に対する保留音送出指示を送信する（図１４（６））。

電話会議サーバＣＳＶ１は、チャネル（Ch-q）に対して保留音を再生し、再生した音声ストリームをＳＩＰ公衆網ＮＷ１のチャネル（Ch-q）に対して流す指示を行う（図１４（７））。以上により、加入者端末ＴＴ１は保留音を聴取する。

ＩＰ電話端末ＩＰＴ１のユーザはダイヤルトーンを聞いた後、会議メンバーを呼び出すためにダイヤルを操作する（図１４（８））。ダイヤル操作はＩＰ電話サーバＡＳＶ１に通知され、会議メンバーを特定したところでメンバー（ここではＩＰ電話端末ＩＰＴ２）に着信鳴動送出指示を送信して（図１４（９））、ＩＰ電話端末ＩＰＴ２を呼び出す（図１４（１０））。

ＩＰ電話端末ＩＰＴ２のユーザが呼び出しに応答すると、ＩＰ電話端末ＩＰＴ２はＩＰ電話サーバＡＳＶ１に対し応答を返送する（図１４（１１））。ＩＰ電話サーバＡＳＶ１は、ＩＰ電話端末ＩＰＴ１に対し通話指示を送信するとともに（図１４（１２））、ＩＰ電話端末ＩＰＴ２に対し通話指示を送信し（図１４（１３））、ＩＰ電話端末ＩＰＴ１とＩＰ電話端末ＩＰＴ２との間の音声ストリームを形成する（図１４（１４））。

この状態から、ＩＰ電話端末ＩＰＴ１のユーザが会議ボタンを操作すると（図１４（１５））、その操作がＩＰ電話サーバＡＳＶ１に通知される（図１４（１６））。ＩＰ電話サーバＡＳＶ１はまず、メディアリソース（Ch-q）に保留音の停止を指示し（図１４（１７））、メディアリソース（Ch-q）を開放する。

次に、ＩＰ電話サーバＡＳＶ１は、電話会議サーバＣＳＶ１に対しメディアリソース捕捉要求を送信し（図１４（１８））、電話会議サーバＣＳＶ１から会議メンバー数分のメディアリソース（ここでは３チャネル）を捕捉する（図１４（１９））。そして、ＩＰ電話サーバＡＳＶ１は、メディアリソース（Ch-i）とＩＰ電話端末ＩＰＴ１との間で音声ストリームを形成するよう指示し（図１４（２０））、メディアリソース（Ch-j）とＳＩＰ公衆網ＮＷ１のリソース（Ch-X）との間で音声ストリームを形成するよう指示し（図１４（２１））、メディアリソース（Ch-k）とＩＰ電話端末ＩＰＴ２との間で音声ストリームを形成するよう指示する（図１４（２２））。これにより、外部ユーザの加入者端末ＴＴ１を交えた３者会議を構成する。

会議メンバーの終話操作により、ＩＰ電話サーバＡＳＶ１はメディアリソース（Ch-i,j,k）を開放し、音声ストリームを切断する。

さらに、ＩＰ電話端末ＩＰＴ１においてユーザが、加入者端末ＴＴ１との通話中に、ＩＰ電話端末ＩＰＴ２を映像やデータ等を使用した会議通話に加える操作を行ったとする。その操作がＩＰ電話サーバＡＳＶ１に通知される。会議ボタン操作を検出したＩＰ電話サーバＡＳＶ１は、ＩＰ電話端末ＩＰＴ１の音声ストリームを切断する指示をＩＰ電話端末ＩＰＴ１に送信するとともに、同じくＩＰ電話端末ＩＰＴ１に対してダイヤルトーンを生成する制御信号を送信する。

さらに、ＩＰ電話サーバＡＳＶ１は、ウェブ会議サーバＣＳＶ２に対しメディアリソース捕捉要求を送信して、ウェブ会議サーバＣＳＶ２からメディアリソースを１チャネル捕捉し（Ch-q）、メディアリソースチャネル（Ch-q）に対する保留音送出指示を送信する。

ウェブ電話会議サーバＣＳＶ２は、チャネル（Ch-q）に対して保留音を再生し、再生した音声ストリームをＳＩＰ公衆網ＮＷ１のチャネル（Ch-q）に対して流す指示を行い、加入者端末ＴＴ１のユーザに保留音を聴取させる。

ＩＰ電話端末ＩＰＴ１のユーザはダイヤルトーンを聞いた後、会議メンバーを呼び出すためにダイヤルを操作する。ダイヤル操作はＩＰ電話サーバＡＳＶ１に通知され、会議メンバーを特定したところでメンバー（ここではＩＰ電話端末ＩＰＴ２）に着信鳴動送出指示を送信して、ＩＰ電話端末ＩＰＴ２を呼び出す。

ＩＰ電話端末ＩＰＴ２のユーザが呼び出しに応答すると、ＩＰ電話端末ＩＰＴ２はＩＰ電話サーバＡＳＶ１に対し応答を返送する。ＩＰ電話サーバＡＳＶ１は、ＩＰ電話端末ＩＰＴ１に対し通話指示を送信するとともに、ＩＰ電話端末ＩＰＴ２に対し通話指示を送信し、ＩＰ電話端末ＩＰＴ１とＩＰ電話端末ＩＰＴ２との間の音声ストリームを形成する。

この状態から、ＩＰ電話端末ＩＰＴ１のユーザが会議ボタンを操作すると、その操作がＩＰ電話サーバＡＳＶ１に通知される。ＩＰ電話サーバＡＳＶ１はまず、メディアリソース（Ch-q）に保留音の停止を指示し、メディアリソース（Ch-q）を開放する。

次に、ＩＰ電話サーバＡＳＶ１は、ウェブ会議サーバＣＳＶ２に対しメディアリソース捕捉要求を送信し、ウェブ会議サーバＣＳＶ２から会議メンバー数分のメディアリソース（ここでは３チャネル）を捕捉する。そして、ＩＰ電話サーバＡＳＶ１は、メディアリソース（Ch-i）とＩＰ電話端末ＩＰＴ１との間でメディアストリームを形成するよう指示し、メディアリソース（Ch-j）とＳＩＰ公衆網ＮＷ１のリソース（Ch-X）との間でメディアストリームを形成するよう指示し、メディアリソース（Ch-k）とＩＰ電話端末ＩＰＴ２との間でメディアストリームを形成するよう指示する。これにより、外部ユーザの加入者端末ＴＴ１を交えた３者会議を構成する。

以上のように上記第５の実施形態では、ユーザサイトＵＳ１において、通話機能を使用する場合に、ユーザサイトＵＳ１に備えられるＩＰ電話サーバＡＳＶ１を利用し、電話会議機能やウェブ会議機能を使用する場合には、クラウド上のデータセンタＤＣ１の電話会議機能やウェブ会議機能を利用するというように、クラウド上のデータセンタＤＣ１に頼らずにユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１で分担して通信サービスを実行することが可能となり、これにより会議アプリケーションやＷｅｂアプリケーションなどはＣＰＵやメモリ等のサーバのリソースを使用する機能を追加したい場合、ユーザのハードウェアリソースを変更することなく機能を追加することを可能となる。初期投資に当てはめると、将来の機能追加を見込んで、高価なハードウェアリソースを用意する必要がなくなる。

また、上記第５の実施形態では、ユーザサイトＵＳ１において、通話機能を使用する場合に、クラウド上のデータセンタＤＣ１のＣＰコンテナを利用し、電話会議機能やウェブ会議機能を使用する場合には、ユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１の電話会議機能やウェブ会議機能を利用することもできる。

（第６の実施形態）
第６の実施形態では、ＩＰ電話サーバが故障した場合に、クラウド上のデータセンタＤＣ１に接続し直して通信サービスを継続するものである。この場合、ユーザは、予め保守業者を介して、電話サービスプロバイダとの間で契約をしておく。

図１５は、ユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１に障害が発生した際のＩＰ電話端末ＩＰＴ１とＩＰ電話サーバＡＳＶ１とＣＰコンテナとの間における通信切替動作を示すシーケンス図である。

ここで、ＩＰ電話端末ＩＰＴ１のユーザがスタンバイサービスを希望する場合、運用支援サーバＣＳＶ３はスタンバイ用のＣＰコンテナ（ＣＰ１）を生成し、運用データをＣＰコンテナＣＰ１にダウンロードしておく（図１５（０１））。

いま、内線端末としてのＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間でＩＰ電話サーバＡＳＶ１を介して通話が行われているものとする（図１５（１））。この状態で、ＩＰ電話端末ＩＰＴ１はＩＰ電話サーバＡＳＶ１の障害監視を行っている。障害監視の手法としては、ＩＰ電話サーバＡＳＶ１からの周期的な信号を受信できるか否かを監視するものが用いられる。

さて、この状態でＩＰ電話サーバＡＳＶ１において障害が発生し、この障害の発生がＩＰ電話端末ＩＰＴ１で検出されたとする（図１５（２））。そうするとＩＰ電話端末ＩＰＴ１は、クラウド上のデータセンタＤＣ１の仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）に通信を転送させるべく、データセンタＤＣ１のＣＰコンテナ（ＣＰ１）へ接続要求信号を送信する（図１５（３））。

これに対しＣＰコンテナ（ＣＰ１）は、ＩＰ電話端末ＩＰＴ１から接続要求信号を受信すると、ＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間の通信を引き継ぐ処理を開始する。そして、ＣＰコンテナ（ＣＰ１）はＩＰ電話端末ＩＰＴ１に対し接続受付信号を送信する（図１５（４））。このときこの接続受付信号には、通信の引き継ぎが成功したことを示す情報、例えば「正常」が、解放理由として挿入される。ＩＰ電話端末ＩＰＴ１はこの情報により通信が正しく引き継がれた旨を認識できる。

かくして、ユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１からＣＰコンテナ（ＣＰ１）に切り替わり、以後ＣＰコンテナ（ＣＰ１）を介してＩＰ電話端末ＩＰＴ１とＳＩＰ公衆網ＮＷ１上の加入者端末ＴＴ１との間で引き続き通話が可能となる。

以上のように、上記第６の実施形態によれば、ユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１に障害が発生して通信サービスの継続が不可能になった場合でも、ユーザサイトＵＳ１に対してクラウド上のデータセンタＤＣ１のＣＰコンテナ（ＣＰ１）により通信サービスの提供が継続される。

（第７の実施形態）
第７の実施形態では、ＩＰ電話サーバのトラフィックがしきい値を超えた場合に、クラウド上のデータセンタＤＣ１のＣＰコンテナを使用するものである。この場合、ユーザは、予め保守業者を介して、電話サービスプロバイダとの間で契約をしておく。この契約の内容は、必要な内線端末数、回線数や、付加機能（電話会議機能、ウェブ会議機能等）を使用するかについて、契約を行うことで、ライセンスを受ける。

（トラフィックに伴うＩＰ電話サーバからＣＰコンテナへの登録変更）
図１６は、ＩＰ電話端末ＩＰＴ１とＩＰ電話サーバＡＳＶ１とデータセンタＤＣ１との間で登録先変更処理を行う動作を示すシーケンス図である。

いま、ＩＰ電話端末ＩＰＴ１は、ＩＰ電話サーバＡＳＶ１に登録されているとする。この状態において、ＩＰ電話サーバＡＳＶ１は、トラフィックが閾値１を超えるか否かを監視しており（図１６（１））、トラフィックが閾値１を超えた場合に、予めデータ設定されているサービスクラスのＩＰ電話端末に対し、優先度の高いユーザはそのまま運用を継続し、優先度の低いユーザ（例えば、ＩＰ電話端末ＩＰＴ１）はクラウド上のデータセンタＤＣ１への再登録要求を通知する（図１６（２））。

ＩＰ電話サーバＡＳＶ１からの再登録要求の通知に対しＩＰ電話端末ＩＰＴ１の登録を行う際に、ＩＰ電話端末ＩＰＴ１のユーザはデータセンタＤＣ１を指定した発信操作を行なう（図１６（３））。すると、ＩＰ電話端末ＩＰＴ１は、データセンタＤＣ１宛ての登録要求を生成してこの要求をＩＰ電話サーバＡＳＶ１へ送信する（図１６（４））。

そして、ＩＰ電話サーバＡＳＶ１は登録要求を受信すると、データセンタＤＣ１へＩＰ電話端末ＩＰＴ１のＩＰアドレスを含む登録要求を通知する（図１６（５））。

この登録要求の通知に対しデータセンタＤＣ１の運用支援サーバＣＳＶ３が応答すると（図１６（６））、データセンタＤＣ１内の仮想化ホストサーバＮ１にＣＰコンテナ（ＣＰ１）が生成されるとともに、仮想化ホストサーバＮ１とＩＰ電話端末ＩＰＴ１との間にセッションが確立され、ＩＰ電話端末ＩＰＴ１のＩＰアドレスが仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）に登録される（図１６（７））。

また、ＩＰ電話サーバＡＳＶ１は、トラフィックが閾値１より小さい値である閾値２未満である場合に、登録されているＩＰ電話端末ＩＰＴ１に対し再登録要求を通知する。

ＩＰ電話サーバＡＳＶ１からの再登録要求の通知に対しＩＰ電話端末ＩＰＴ１の登録を行う際に、ＩＰ電話端末ＩＰＴ１のユーザはデータセンタＤＣ１を指定した発信操作を行なう。すると、ＩＰ電話端末ＩＰＴ１は、データセンタＤＣ１宛ての登録要求を生成してこの要求をＩＰ電話サーバＡＳＶ１へ送信する。

そして、ＩＰ電話サーバＡＳＶ１は登録要求を受信すると、データセンタＤＣ１へＩＰ電話端末ＩＰＴ１のＩＰアドレスを含む登録要求を通知する。

この登録要求の通知に対しデータセンタＤＣ１の運用支援サーバＣＳＶ３が応答すると、仮想化ホストサーバＮ１にＣＰコンテナ（ＣＰ１）が生成されるとともに、仮想化ホストサーバＮ１とＩＰ電話端末ＩＰＴ１との間にセッションが確立され、ＩＰ電話端末ＩＰＴ１のＩＰアドレスが仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）に登録される。

以上のように上記第７の実施形態によれば、ユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１のトラフィックが増えた場合、データセンタＤＣ１のＣＰコンテナ（ＣＰ１）にユーザサイトＵＳ１への通信サービスの提供を引き継ぐことにより、ＩＰ電話サーバＡＳＶ１の処理負担を軽減できる。また、ＩＰ電話サーバＡＳＶ１による使用量が少ない場合、ユーザサイトＵＳ１を例えばデータセンタＤＣ１のＣＰコンテナ（ＣＰ１）に登録することにより、ユーザサイトＵＳ１全体の消費電力を低減できる。さらに、データセンタＤＣ１側にとっては、ＩＰ電話サーバＡＳＶ１のトラフィックに応じて、ＣＰコンテナを自動的に増やすことができ、利便性が高まる。

（第８の実施形態）
第８の実施形態では、ユーザサイトのＩＰ電話サーバのトラフィックがしきい値以下となった場合に、クラウド上のデータセンタからユーザサイトのＩＰ電話サーバへ切り戻すものである。この場合、ユーザは、予め保守業者を介して、電話サービスプロバイダとの間で契約をしておく。

（トラフィックに伴うクラウド上のデータセンタからＩＰ電話サーバへの登録変更）
図１７は、ＩＰ電話端末ＩＰＴ１とデータセンタＤＣ１とＩＰ電話サーバＡＳＶ１との間で登録先変更処理を行う動作を示すシーケンス図である。

いま、ＩＰ電話端末ＩＰＴ１は、データセンタＤＣ１の仮想化ホストサーバＮ１のＣＰコンテナ（ＣＰ１）に登録されているとする。この状態において、ＩＰ電話サーバＡＳＶ１は、自己のトラフィックが閾値以下となるか否かを監視しており（図１７（１））、トラフィックが閾値以下になった場合に、登録されているＩＰ電話端末ＩＰＴ１に対し再登録要求を通知する（図１７（２））。

ＩＰ電話サーバＡＳＶ１からの再登録要求の通知に対しＩＰ電話端末ＩＰＴ１の登録を行う際に、ＩＰ電話端末ＩＰＴ１のユーザはＩＰ電話サーバＡＳＶ１への発信操作を行なう（図１７（３））。すると、ＩＰ電話端末ＩＰＴ１は、ＩＰ電話サーバＡＳＶ１宛ての登録要求を生成してこの要求をＩＰ電話サーバＡＳＶ１に送信する（図１７（４））。ＩＰ電話サーバＡＳＶ１は、データセンタＤＣ１へ登録要求を送信する（図１７（５））。

そして、データセンタＤＣ１は登録要求を受信すると、ＩＰ電話サーバＡＳＶ１へＩＰ電話端末ＩＰＴ１のＩＰアドレスを含む応答を通知する（図１７（６））。

この応答を受信すると、ＩＰ電話サーバＡＳＶ１は、ＩＰ電話端末ＩＰＴ１との間にセッションを確立し、ＩＰ電話端末ＩＰＴ１のＩＰアドレスを登録する（図１７（７））。

以上のように上記第８の実施形態によれば、ユーザサイトＵＳ１のＩＰ電話サーバのトラフィックがしきい値以下となった場合に、データセンタＤＣ１のＣＰコンテナ（ＣＰ１）に登録されていたＩＰ電話端末ＩＰＴ１を、ユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１に切り戻すことにより、仮想化ホストサーバＮ１の処理負担を軽減できる。また、仮想化ホストサーバＮ１に登録されているユーザサイトＵＳ１による使用量が少ない場合、ＩＰ電話端末ＩＰＴ１を例えばユーザサイトＵＳ１のＩＰ電話サーバＡＳＶ１に切り戻すことにより、動作不要な仮想化ホストサーバＮ１を作ることができ、データセンタＤＣ１全体の消費電力を低減できる。

（その他の実施形態）
その他の実施形態として、データセンタＤＣ１は、予め決められた条件に基づいて、例えばユーザサイトＵＳ１に配置されているＩＰ電話サーバに交換ソフトウェアを転送しセットすることで、ユーザサイトＵＳ１に対する通信サービスの提供を継続させることもできる。

このようにすれば、ユーザサイトＵＳ１がＩＰ電話サーバを備えている場合に、例えばデータセンタＤＣ１に障害が発生し、通信サービスの提供が困難となった場合でも、ユーザサイトＵＳ１で契約した通信機能に対応する交換ソフトウェアをインターネットＩＮＷを介して自己所有のＩＰ電話サーバにセットすることができ、この結果ユーザサイトＵＳ１に対して通信サービスの提供が継続される。なお、条件の判断として、トラフィックや日時等を用いるようにしてもよい。

さらに、上記各実施形態では、複数の仮想化ホストサーバＮ１〜Ｎｐを備える例について説明したが、１台の仮想化ホストサーバＮ１のみでもよい。この場合、仮想化ホストサーバＮ１に障害が発生したとしても、残りのサーバにＣＰコンテナを割り当てることもできる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１,２…ＬＡＮ、ＤＣ１〜ＤＣｉ…データセンタ、ＴＳＰ…電話サービスプロバイダ、ＵＳ１〜ＵＳｍ…ユーザサイト、ＩＰＴ１〜ＩＰＴｎ…ＩＰ電話端末、ＩＮＷ…インターネット、Ｎ１〜Ｎｐ…仮想化ホストサーバ、ＣＳＶ１…電話会議サーバ、ＣＳＶ２…ウェブ会議サーバ、ＣＳＶ３…運用支援サーバ、ＣＳＶ４…課金管理サーバ、ＣＳＶ５…プロビジョニングサーバ、ＣＳＶ６…電話サービスポータルサイト、ＣＳＶ７…見積もり発注サーバ、ＣＳＶ８…ライセンス管理サーバ、ＣＳＶ９…受発注システム、ＣＳＶ１０…ユーザ管理サーバ、ＭＴ…保守業者、ＤＢ…ユーザデータベース、ＣＰ１〜ＣＰ１２…ＣＰコンテナ、Ａｄｍｉｎ１〜Ａｄｍｉｎ３…Ａｄｍｉｎコンテナ、ＴＣ１…電話会議コンテナ、ＷＣ１…ウェブ会議コンテナ、ＡＳＶ１…ＩＰ電話サーバ。

Claims (39)

1. 通信端末としての少なくとも１つのユーザ装置と、
   前記ユーザ装置に対し通信ネットワークを介して接続され、前記ユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供するデータセンタ装置とを具備し、
   前記データセンタ装置は、
   前記ユーザ装置を識別するユーザＩＤを記憶する記憶部と、
   通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のＣＰコンテナを有する処理部と、
   前記ユーザ装置の保守を行う保守業者毎に設けられ、前記ユーザ装置から通信機能の使用要求を受信するとき、対応付けられた前記複数の前記ＣＰコンテナのうちの少なくとも１つを使用して通信サービスを提供するとともに、関連付けられたＣＰコンテナに対する保守管理を行うＡＤＭＩＮコンテナを有する制御部と
   を備える通信システム。
2. 前記制御部は、前記複数のコンテナで処理されているトラフィックが増えるとき、前記処理部または第１のサーバに生成された第１及び第２のコンテナを、前記第１のサーバとは異なる第２のサーバに移動させる請求項１記載の通信システム。
3. 前記制御部は、第１及び第２のユーザ装置のトラフィックが減少するとき、第１のサーバに生成された第１のコンテナと、第２のサーバに生成された第２のコンテナとを、前記第１及び第２のサーバのいずれか１つに統合させる請求項２記載の通信システム。
4. 前記制御部は、第１のユーザ装置に対応する第１のコンテナに障害が発生した場合に、前記第２のコンテナもしくは前記第１及び第２のコンテナとは別のコンテナにより前記第１のユーザ装置に対する通信サービスの提供を継続させる請求項１記載の通信システム。
5. 前記制御部は、前記複数のコンテナの少なくとも一部を、付加機能を実現するためのサーバに生成し、前記複数のユーザ装置で共有して使用させる請求項１記載の通信システム。
6. 前記制御部は、保守業者が増加したとき、増加した保守業者に対応するコンテナを、前記サーバ上に生成し前記複数のユーザ装置に対し並列に通信サービスを提供する請求項１記載の通信システム。
7. 前記制御部は、保守業者が減少したとき、減少した保守業者に対応するコンテナを、前記サーバ上から削除する請求項６記載の通信システム。
8. 前記制御部は、第１のユーザ装置に対応するコンテナに障害が発生した場合に、別のデータセンタ装置に前記第１のユーザ装置に対する通信サービスの提供を継続させる請求項１記載の通信システム。
9. 通信端末と呼制御機能を有するユーザ側サーバとを有する少なくとも１つのユーザ装置と、
   前記ユーザ装置に対し通信ネットワークを介して接続され、前記ユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供するデータセンタ装置とを具備し、
   前記データセンタ装置は、
   前記ユーザ装置を識別するユーザＩＤを記憶する記憶部と、
   通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のコンテナを有する処理部と、
   前記ユーザ装置から通信機能の使用要求を受信するとき、関連つけられた前記複数のコンテナのうちの少なくとも１つを使用して通信サービスを提供する制御部とを備え、
   前記通信サービスを実行するためのソフトウェア情報の少なくとも一部となるアプリケーションソフト情報を、前記ユーザ装置のサーバ側と前記データセンタ装置の処理部とを連携して動作させる通信システム。
10. 前記ユーザ装置のサーバと前記データセンタ装置の処理部の連携は、前記ユーザ装置のサーバ側で、通信端末間または通信端末と通信回線との間の交換処理に係わる通信機能を実行させ、前記データセンタ装置の処理部に付加機能を実行させる請求項９記載の通信システム。
11. 前記ユーザ装置のサーバと前記データセンタ装置の処理部の連携は、通常時に、ユーザ装置のサーバにより通信サービスを提供し、障害発生時に、前記データセンタ装置の処理部により通信サービスを提供する請求項９記載の通信システム。
12. 前記ユーザ装置のサーバと前記データセンタ装置の処理部の連携部は、前記ユーザ装置のトラヒックが閾値を超えた場合に、超えた値に対応して前記データセンタ装置のコンテナを使用する請求項９記載の通信システム。
13. 前記ユーザ装置のサーバと前記データセンタ装置の処理部の連携部は、前記ユーザ装置のトラヒックが閾値以下となった場合に、ユーザ装置のサーバに切り戻して通信サービスを提供する請求項９記載の通信システム。
14. 通信端末としての少なくとも１つのユーザ装置に対し通信ネットワークを介して接続され、前記ユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供するデータセンタ装置であって、
    前記ユーザ装置を識別するユーザＩＤを記憶する記憶部と、
    通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のＣＰコンテナを有する処理部と、
    前記ユーザ装置の保守を行う保守業者毎に設けられ、前記ユーザ装置から通信機能の使用要求を受信するとき、前記複数のコンテナのうちの少なくとも１つを使用して通信サービスを提供するとともに、関連付けられたＣＰコンテナに対する保守管理を行うＡＤＭＩＮコンテナとを備える制御部と
    を具備するデータセンタ装置。
15. 前記制御部は、前記複数のコンテナで処理されているトラフィックが増えるとき、前記処理部または第１のサーバに生成された第１及び第２のコンテナを、前記第１のサーバとは異なる第２のサーバに移動させる請求項１４記載のデータセンタ装置。
16. 前記制御部は、第１及び第２のユーザ装置のトラフィックが減少するとき、第１のサーバに生成された第１のコンテナと、第２のサーバに生成された第２のコンテナとを、前記第１及び第２のサーバのいずれか１つに統合させる請求項１４記載のデータセンタ装置。
17. 前記制御部は、第１のユーザ装置に対応する第１のコンテナに障害が発生した場合に、第２のコンテナもしくは前記第１及び第２のコンテナとは別のコンテナにより前記第１のユーザ装置に対する通信サービスの提供を継続させる請求項１４記載のデータセンタ装置。
18. 前記制御部は、前記複数のコンテナの少なくとも一部を、付加機能を実現するためのサーバに生成し、前記複数のユーザ装置で共有して使用させる請求項１４記載のデータセンタ装置。
19. 前記制御部は、保守業者が増加したとき、増加した保守業者に対応するコンテナを、前記サーバ上に生成し前記複数のユーザ装置に対し並列に通信サービスを提供する請求項１４記載のデータセンタ装置。
20. 前記制御部は、保守業者が減少したとき、減少した保守業者に対応するコンテナを、前記サーバ上から削除する請求項１９記載のデータセンタ装置。
21. 前記制御部は、第１のユーザ装置に対応するコンテナに障害が発生した場合に、別のデータセンタ装置に前記第１のユーザ装置に対する通信サービスの提供を継続させる請求項１４記載のデータセンタ装置。
22. 通信端末と呼制御機能を有するユーザ側サーバとを有する少なくとも１つのユーザ装置に対し通信ネットワークを介して接続され、前記ユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供するデータセンタ装置であって、
    通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のコンテナを有する処理部と、
    前記ユーザ装置を識別するユーザＩＤを記憶する記憶部と、
    前記ユーザ装置から通信機能の使用要求を受信するとき、前記複数のコンテナのうちの少なくとも１つを使用して通信サービスを提供する制御部とを具備し、
    前記通信サービスを実行するためのソフトウェア情報の少なくとも一部となるアプリケーションソフト情報を、前記ユーザ装置のサーバ側で、前記データセンタ装置の処理部と連携して動作させるデータセンタ装置。
23. 前記ユーザ装置のサーバと前記データセンタの処理部との連携動作は、前記ユーザ装置のサーバ側で、通信端末間または通信端末と通信回線との間の交換処理に係わる通信機能を実行させ、前記処理部に付加機能を実行させる請求項２２記載のデータセンタ装置。
24. 前記ユーザ装置のサーバと前記データセンタの処理部との連携動作は、通常時に、ユーザ装置のサーバにより通信サービスを提供し、障害発生時に、前記処理部により通信サービスを提供する請求項２２記載のデータセンタ装置。
25. 前記ユーザ装置のサーバと前記データセンタの処理部との連携動作は、前記ユーザ装置のトラヒックが閾値を超えた場合に、超えた値に対応する数のコンテナを使用する請求項２２記載のデータセンタ装置。
26. 前記ユーザ装置のサーバと前記データセンタの処理部との連携動作は、前記ユーザ装置のトラヒックが閾値以下となった場合に、ユーザ装置のサーバに切り戻して通信サービスを提供する請求項２２記載のデータセンタ装置。
27. 通信端末としてのユーザ装置に対し通信ネットワークを介して接続され、前記ユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供し、通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のコンテナを有する処理部を備えるデータセンタ装置で使用される制御方法において、
    前記ユーザ装置を識別するユーザＩＤをメモリに記憶し、
    前記ユーザ装置から通信機能の使用要求を受信するとき、前記複数のコンテナのうちの少なくとも１つを使用して通信サービスを提供するようにし、
    前記複数のコンテナとして、前記ユーザ装置に対する呼制御を行うＣＰコンテナと、前記ユーザ装置の保守管理を行う保守業者に割り当てられ、前記ＣＰコンテナに対する保守管理の制御を行うＡＤＭＩＮコンテナとを用意し、
    前記ＣＰコンテナを保守対象として前記ＡＤＭＩＮコンテナに関連付けしておき、前記ＡＤＭＩＮコンテナに関連付けされたＣＰコンテナに対する保守管理の制御を実行させる制御方法。
28. 前記通信サービスを提供することは、前記複数のコンテナで処理されているトラフィックが増えるとき、前記処理部または第１のサーバに生成された第１及び第２のコンテナを、前記第１のサーバとは異なる第２のサーバに移動させる請求項２７記載の制御方法。
29. 前記通信サービスを提供することは、第１及び第２のユーザ装置のトラフィックが減少するとき、第１のサーバに生成された前記第１のコンテナと、第２のサーバに生成された第２のコンテナとを、前記第１及び第２のサーバのいずれか１つに統合させる請求項２７記載の制御方法。
30. 前記通信サービスを提供することは、第１のユーザ装置に対応する第１のコンテナに障害が発生した場合に、第２のコンテナもしくは前記第１及び第２のコンテナとは別のコンテナにより前記第１のユーザ装置に対する通信サービスの提供を継続させる請求項２７記載の制御方法。
31. 前記通信サービスを提供することは、前記複数のコンテナの少なくとも一部を、付加機能を実現するためのサーバに生成し、前記複数のユーザ装置で共有して使用させる請求項２７記載の制御方法。
32. 前記通信サービスを提供することは、保守業者が増加したとき、増加した保守業者に対応するコンテナを、前記サーバ上に生成し前記複数のユーザ装置に対し並列に通信サービスを提供する請求項２７記載の制御方法。
33. 前記通信サービスを提供することは、保守業者が減少したとき、減少した保守業者に対応するコンテナを、前記サーバ上から削除する請求項２７記載の制御方法。
34. 前記通信サービスを提供することは、第１のユーザ装置に対応するコンテナに障害が発生した場合に、別のデータセンタ装置に前記第１のユーザ装置に対する通信サービスの提供を継続させる請求項２７記載の制御方法。
35. 通信端末としてのユーザ装置に対し通信ネットワークを介して接続され、前記ユーザ装置に対し通信端末間または通信端末と通信回線との間の交換処理に係わる任意の通信サービスを提供し、通信端末間または通信端末と通信回線との間の交換処理に係わる複数の通信機能を実行するための複数のコンテナを有する処理部を備えるデータセンタ装置で使用される制御方法において、
    前記ユーザ装置を識別するユーザＩＤをメモリに記憶し、
    前記ユーザ装置から通信機能の使用要求を受信するとき、前記複数のコンテナのうちの少なくとも１つを使用して通信サービスを提供するようにし、
    前記通信サービスを提供することは、前記ユーザ装置に設けられるサーバとが共存する場合に、前記通信サービスを実行するためのソフトウェア情報の少なくとも一部となるアプリケーションソフト情報を、前記ユーザ装置のサーバ側で、前記処理部と連携して動作させる制御方法。
36. 前記通信サービスを提供することは、前記ユーザ装置のサーバ側で、通信端末間または通信端末と通信回線との間の交換処理に係わる通信機能を実行させ、前記処理部に付加機能を実行させる請求項３５記載の制御方法。
37. 前記通信サービスを提供することは、通常時に、ユーザ装置のサーバにより通信サービスを提供し、障害発生時に、前記処理部により通信サービスを提供する請求項３５記載の制御方法。
38. 前記通信サービスを提供することは、前記ユーザ装置のトラヒックが閾値を超えた場合に、超えた値に対応する数のコンテナを使用する請求項３５記載の制御方法。
39. 前記通信サービスを提供することは、前記ユーザ装置のトラヒックが閾値以下となった場合に、ユーザ装置のサーバに切り戻して通信サービスを提供する請求項３５記載の制御方法。

Images