JP6419477B2 - 交換機、及び、携帯端末 - Google Patents

Description

本発明は、交換機に関する。

ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ：回線交換機）の障害時におけるバックアップ構成として、ＰＢＸを冗長化してシステムを構成し、現用系ＰＢＸ故障時に予備系ＰＢＸに制御を切り替える事でサービス運用を継続することが一般的である。

現用系ＰＢＸ故障時にバックアップ制御を行う技術が提案されている（例えば、特許文献１参照）。この広報には「ＩＰ−ＰＢＸがＩＰ端末装置の全体データ管理及び制御を行い、個々のネットワークに配備されたバックアップ装置が、接続されたネットワーク内の各ＩＰ端末データを保持する。これにより、ＩＰ−ＰＢＸに異常が発生した場合に、バックアップ装置により該バックアップ装置が接続されたネットワーク内の接続管理が担保され、ネットワーク又はＩＰ−ＰＢＸに障害が発生し、ＩＰ−ＰＢＸによるＩＰ端末の制御が不可能になった場合に、一時的にＩＰ端末の制御をバックアップ装置側に移すことでＩＰ端末の運用再開を可能とし、停止時間の最小化を図る」と記載されている。

特開２００５−００６１２１号公報

しかしながら、ＰＢＸを冗長化してバックアップシステムを構成する場合、ＰＢＸが一つの拠点に複数個必要な為冗長化した分だけコスト高となる。またＰＢＸ機器自体が高価な為小さな拠点などでは冗長化構成をとらず１重化構成で運用しているケースも多い。１重化構成での運用においては、当然ＰＢＸ故障時にサービス運用ができず、ＰＢＸを復旧させるまでサービス停止状態が継続する。またＰＢＸ機器の保守サービス形態によっては故障復旧させるまで長時間となってしまう場合もある。

特許文献１においても正常時はＩＰ−ＰＢＸがサービスを提供し、ＩＰ−ＰＢＸ故障時に拠点毎に配備されたバックアップ装置に制御を移行するシステムであり、故障時しか動作させないこれら機器をバックアップ装置として各拠点に常時配備が必要となるため、コスト高となってしまうという課題もある。

また、１拠点しかない小さな企業の様な場合においては特許文献１の技術を用いた場合、コスト的に非常に不利となる。加えて特許文献１では、ＰＢＸ端末がＩＰ端末でなければバックアップできないシステム構成となっており、レガシーＰＢＸで制御しているアナログ電話機等のレガシー端末のサービス運用を継続することが難しいという課題もある。

上記課題を解決するために、本発明は、交換機であって、プロセッサ、メモリ及びネットワークインタフェースを備え、少なくとも一つの他の交換機とネットワークを介して接続され、前記他の交換機が収容する電話機と、前記電話機に対応する携帯端末との対応関係を示す変換情報、及び、前記電話機と通信する通信端末の電話番号と、前記電話番号に対応する情報とを含む電話帳データを、前記メモリに保持し、前記他の交換機が通信不可状態になった後、前記電話機を呼び出すため前記他の交換機に送信された信号を、前記ネットワークインタフェースを介して受け付けた場合、前記変換情報に基づいて、前記電話機に対応する前記携帯端末に呼出し信号を送信し、前記携帯端末から前記電話帳データの要求を受け付けた場合、前記要求を送信した携帯端末に対応する前記電話機が保持する電話帳データを、前記メモリに格納される電話帳データから抽出し、前記抽出した電話帳データを、前記携帯端末に送信し、前記抽出した電話帳データに含まれる電話番号の要求を、前記携帯端末から受け付ける。

本発明によれば、ＰＢＸによるサービス運用を低コストで継続できる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

実施例１の通信システムの構成を示す説明図である。 実施例１のクラウドＰＢＸの物理的な構成を示すブロック図である。 実施例１のクラウドＰＢＸの機能部を示すブロック図である。 実施例１の携帯情報端末の物理的な構成を示すブロック図である。 実施例１の番号変換情報を示す説明図である。 実施例１のＰＢＸのバックアップ処理の開始時を示すシーケンス図である。 実施例１のバックアップ開始時のクラウドＰＢＸの処理を示すフローチャートである。 実施例１のバックアップ終了時の処理を示すシーケンス図である。 実施例１のバックアップ終了時のクラウドＰＢＸの処理を示すフローチャートである。 実施例１の携帯情報端末の利用者が携帯情報端末を用いて、番号変換情報の登録を行う処理を示すシーケンス図である。 実施例１の携帯情報端末に送信される故障通知を示す説明図である。 実施例１のクラウドＰＢＸがバックアップ中に、携帯情報端末からの発信された際の処理を示すシーケンス図である。 実施例２の通信システムの構成を示す説明図である。 実施例２の番号変換情報及び電話帳バックアップ情報を示す説明図である。 実施例２のＰＢＸのバックアップ処理の開始時を示すシーケンス図である。 実施例２のバックアップ開始時のクラウドＰＢＸの処理を示すフローチャートである。 実施例２の携帯情報端末から他の携帯情報端末を呼び出す処理を示すシーケンス図である。 実施例２の発信時にバックアップアプリを使用した時の携帯情報端末の処理を示すフローチャートである。 実施例２のＰＳＴＮ端末及び携帯情報端末以外の情報端末から呼び出された場合の携帯情報端末の処理を示すシーケンス図である。 実施例２の着信時にバックアップアプリを使用した時の携帯情報端末の処理を示すフローチャートである。 実施例２の電話帳データの定期バックアップと故障時のバックアップアプリの処理を示すシーケンス図である。 実施例２の発信の際にバックアップアプリが表示する画面を示す説明図である。 実施例２の着信の際にバックアップアプリが表示する画面を示す説明図である。

以下、実施例を図面を用いて説明する。ＰＢＸで内線交換や各種ＰＢＸ機能サービスを１重化で運用しているシステムにおいて、ＰＢＸの障害又は故障発生時等の通信不可状態において、冗長化しバックアップするシステムに関する。

図１は、実施例１の通信システムの構成を示す説明図である。

実施例１の通信システムは、ＰＳＴＮ端末１０、ＰＳＴＮ２１、ＰＳＴＮ２２、データ通信網３０、モバイルキャリア網４０、複数の拠点５５（５５−１、５５−２）、複数の携帯情報端末７０（７０−１、７０−２）、及びクラウドＰＢＸ８０を含む。また、拠点５５−１は、ＰＢＸ５０−１及び内線端末６０−１を含み、拠点５５−２は、ＰＢＸ５０−２及び内線端末６０−２を含む。

ＰＳＴＮ端末１０は、ＰＳＴＮ２１に接続し、ＰＳＴＮ２１に接続される他端末との間で音声通話を行うアナログ電話機等のＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ：公衆電話網）端末である。ＰＳＴＮ２１及びＰＳＴＮ２２は、ＰＳＴＮ端末を収容し、ＰＳＴＮ相互間の呼制御及び相互内線通話等の各種電話サービスを提供するＰＳＴＮである。

さらに、ＰＳＴＮ２１に接続されるＰＢＸ５０が故障した際、ＰＢＸ５０への着信には、応答がされない。このため、実施例１のＰＳＴＮ２１は、一般的なＰＳＴＮにおいて提供される無応答転送サービスを提供し、ＰＢＸ５０が故障時に、ＰＢＸ５０への着信をクラウドＰＢＸへ転送する。

また、ＰＳＴＮ２２は、収容するＰＳＴＮ端末（図示なし）と、モバイルキャリア網４０の収容する携帯情報端末７０との間の音声通信を可能とする網変換の機能を有する。

データ通信網３０は、データ通信端末を収容し、データ通信端末相互間のデータ通信を提供するデータ通信網である。ここで、データ通信端末とは、ＰＢＸ５０及びクラウドＰＢＸ８０である。

データ通信網３０は、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プロトコルを用いてデータ通信を行うＩＰネットワークである。本実施例のデータ通信網３０は、クラウドＰＢＸ８０が行うＰＢＸのヘルスチェックを行うためのヘルスチェック情報とその応答情報のデータとを伝送する。

モバイルキャリア網４０は、携帯情報端末７０を収容し、携帯情報端末７０相互間の呼制御及び相互通話、並びに、携帯情報端末７０間のメール送受信等の、電話・データ通信サービスを無線により提供するモバイルキャリア網である。

拠点５５は、例えば、企業ビル又は官公庁庁舎などであり、ＰＳＴＮ２１による通信サービスを提供される拠点である。図１に示す拠点５５は、拠点５５−１及び拠点５５−２の二つであるが、三つ以上の複数の拠点５５が実施例１の通信システムに含まれてもよい。

ＰＢＸ５０は、拠点５５に設置され、内線端末６０及びＰＳＴＮ２１回線を収容し、内線相互通話及び外線−内線通話等の各種構内交換機機能サービスを提供するＰＢＸ５０である。図１に示す拠点５５は、各々１台のＰＢＸ５０を有するが、複数のＰＢＸ５０を有してもよい。

なお、以下の実施例１及び実施例２において、主に、ＰＢＸ５０が障害又は故障により通信不可となった場合の処理について説明するが、ＰＢＸ５０が障害又は故障以外のいかなる理由において通信不可となる場合も、実施例１及び実施例２の処理が実行されてもよい。例えば、定期的なメンテナンス期間中に、明示的にＰＢＸ５０が通信不可とされている場合にも、実施例１及び実施例２が適用されてよい。

内線端末６０は、拠点５５に設置される構内電話である。内線端末６０−１は、ＰＢＸ５０−１と接続し、内線端末６０−２は、ＰＢＸ５０−２と接続される。内線端末６０は、ＰＢＸ５０に接続される他の内線端末６０との音声通話、及び、ＰＳＴＮ２１を介してＰＳＴＮ端末１０との音声通話を行うデジタル多機能電話機等である。

携帯情報端末７０は、モバイルキャリア網４０に収容され、モバイルキャリア網４０に接続されている他の携帯情報端末７０との間で音声通話及びメール伝送等のデータ通信を行う。

携帯情報端末７０−１を携帯する使用者と、内線端末６０−１が割り当てられた使用者とは同じである。携帯情報端末７０−１は、ＰＢＸ５０−１が障害又は故障等の通信不可状態の場合、ＰＳＴＮ端末１０から内線端末６０−１への着信を、ＰＳＴＮ２１を迂回して受け付ける。

携帯情報端末７０−２を携帯する使用者と、内線端末６０−２が割り当てられた使用者とは同じである。携帯情報端末７０−２は、ＰＢＸ５０−２が障害又は故障の場合、ＰＳＴＮ端末１０から内線端末６０−２への着信を、ＰＳＴＮ２１を迂回して受け付ける。

クラウドＰＢＸ８０は、プロセッサ、メモリ及びネットワークインタフェースを有する少なくとも一つの計算機である。クラウドＰＢＸ８０は、ＰＢＸ５０と同じく、通話を転送する機能を有する。

クラウドＰＢＸ８０は、各拠点５５に設置されるＰＢＸ５０へヘルスチェック情報を送信しその応答の有無で、ＰＢＸ５０が障害又は故障であるかどうかのチェックを行う。ＰＢＸ５０が障害又は故障である場合に、クラウドＰＢＸ８０は、ＰＢＸ５０を介して内線端末６０に向けた着信を、受け付ける。

そして、クラウドＰＢＸ８０は、ＰＢＸ５０に向けて発信したＰＳＴＮ端末１０から着信先の内線番号情報を取得する。そして、予め設定される番号変換情報９２によって、取得した内線番号の内線端末６０に対応した携帯情報端末７０へ発信を行うことで、ＰＳＴＮ２１から障害又は故障したＰＢＸ５０への着信を、モバイルキャリア網４０を迂回して携帯情報端末７０に着信させることができる。

図２は、実施例１のクラウドＰＢＸ８０の物理的な構成を示すブロック図である。

クラウドＰＢＸ８０は、呼制御部８１、番号変換情報用メモリ８２、音声交換部８３、データＩＦ部８４、電話回線ＩＦ部８５及び電話帳バックアップ用メモリ８６を有する。

呼制御部８１は、例えば、ＣＰＵ（中央演算処理装置）等のプロセッサ８７、並びに、プログラム及びデータを保持するメモリ８８を有する。

番号変換情報用メモリ８２は、バックアップの対象ＰＢＸ５０と、そのＰＢＸ５０が障害又は故障状態である際にそのＰＢＸ５０へ着信した呼が転送される際に、クラウドＰＢＸ８０に通知される着信電話番号、そのＰＢＸ５０の内線番号、及び、その内線番号の内線端末６０に割り当てられた利用者が利用する携帯情報端末７０の携帯電話番号が、各々対応づけた番号変換情報９２を保持するメモリである。

音声交換部８３は、呼制御部８１からの指示のもとに各回線ＩＦ部間の音声情報の交換を行う。

データＩＦ部８４は、データ通信網３０とのインタフェースであり、呼制御部８１とＰＢＸ５０間のヘルスチェック情報の送受信を行う。

電話回線ＩＦ部８５は、ＰＳＴＮ２１及びＰＳＴＮ２２とのインタフェースであり、呼制御部８１とＰＳＴＮ間の呼制御情報の送受信、及び音声交換部８３とＰＳＴＮ２１及びＰＳＴＮ２２間の音声情報の送受信を行う。

電話帳バックアップ用メモリ８６は、各拠点のＰＢＸ５０が保持する電話帳データをバックアップするメモリである。電話帳バックアップ用メモリ８６は、後述する実施例２において用いられる。このため、実施例１のみを実行する場合、クラウドＰＢＸ８０は電話帳バックアップ用メモリ８６を有する必要はない。

図３は、実施例１のクラウドＰＢＸ８０の機能部を示すブロック図である。

呼制御部８１のメモリは、呼制御機能部９１、ＰＢＸ故障監視機能部９３、データＩＦ制御機能部９４、及び、電話回線ＩＦ制御機能部９５を実行するためのプログラムを保持する。

呼制御機能部９１は、電話回線ＩＦ部８５を介してＰＳＴＮ２１及びＰＳＴＮ２２と呼制御情報を送受信し、番号変換情報９２に従った呼制御を行う。

また、呼制御機能部９１は、番号変換情報用メモリ８２を介して、各内線番号と対応づけされた電話帳情報の送受信を行う。また、その呼制御情報を元に、音声交換部８３へ各電話回線ＩＦ部８５間の音声交換を指示する。

さらに、呼制御機能部９１は、ＰＢＸ故障監視機能部９３から送信されたＰＢＸ５０への故障監視結果が、ＰＢＸ５０が故障していることを示し、かつ、電話回線ＩＦ制御機能部９５から着信情報が有った場合に、内線番号の入力を要求するガイダンスを、ＰＢＸ５０を介してＰＳＴＮ端末１０に送信する。

そして、呼制御機能部９１は、内線番号をＰＳＴＮ端末１０から取得した後に、その内線番号を番号変換情報９２に照らし合わせ、対応する携帯情報端末７０への発信、及び各内線番号と対応づけされた電話帳情報の送受信を行う。

番号変換情報９２は、バックアップの対象であるＰＢＸ５０と、ＰＢＸ５０が障害又は故障状態であるためにＰＢＸ５０から転送されてくる呼の着信電話番号（すなわち、ＰＢＸ５０の電話番号）と、ＰＢＸ５０に接続される内線端末６０の内線番号と、内線端末６０が割り当てられた利用者が携帯する携帯情報端末７０の携帯電話番号とが、各々対応づけた情報である。

ＰＢＸ故障監視機能部９３は、データＩＦ制御機能部９４を介して、ＰＢＸ５０とヘルスチェック情報の送受信を行い、ＰＢＸ５０が故障しているか否かを監視し、その結果を呼制御機能部９１へ伝える。

データＩＦ制御機能部９４は、データＩＦ部８４を制御し、ＰＢＸ故障監視機能とＰＢＸ間のヘルスチェック情報の伝達を行う。

電話回線ＩＦ制御機能部９５は、電話回線ＩＦ部８５を制御し、呼制御機能部９１とＰＳＴＮ２１及びＰＳＴＮ２２間の呼制御情報の伝達、及び、音声交換部８３とＰＳＴＮ２１及びＰＳＴＮ２２間の音声情報のパス開閉機能を行う。

電話帳バックアップ情報９６は、各拠点のＰＢＸ５０が保持する電話帳データのバックアップである。電話帳バックアップ情報９６は、後述する実施例２において用いられる。このため、実施例１のみを実行する場合、クラウドＰＢＸ８０は電話帳バックアップ情報９６を有する必要はない。

図４は、実施例１の携帯情報端末７０の物理的な構成を示すブロック図である。

携帯情報端末７０は、アンテナ部７１、通信インタフェース７２、入出力部７３、プロセッサ７４及びメモリ７５を有する。

アンテナ部７１は、モバイルキャリア網４０の基地局（不図示）と無線によって通信するためのアンテナである。通信ＩＦ７２は、アンテナ部７１を介して信号を送受信するためのインタフェースである。

入出力部７３は、ディスプレイ及びスピーカー等の出力部、若しくは、ダイヤルキー及びマイク等の入力部を含む。また、入出力部７３は、例えばタッチパネルであってもよい。

プロセッサ７４は、例えばＣＰＵ等の演算装置である。メモリ７５は、データ及びプログラムを保持する。プロセッサ７４は、メモリ７５を用いてプログラムを実行することによって、携帯情報端末７０の機能を実現する。

携帯情報端末７０のプロセッサ７４は、プログラムによって実装されたアプリケーションを実行することによって機能を実装する。メモリ７５は、情報登録アプリ７６を有する。また、後述する実施例２において、メモリ７５は、バックアップアプリ７７を有する。

情報登録アプリ７６は、利用者の指示に従い、クラウドＰＢＸ８０の番号変換情報９２に内線番号を登録する。バックアップアプリ７７は、クラウドＰＢＸ８０から送信された情報をディスプレイに表示する。実施例１におけるメモリ７５は、バックアップアプリ７７を有しなくてもよい。

図５は、実施例１の番号変換情報９２を示す説明図である。

番号変換情報９２は、項番９２０、対象ＰＢＸ９２１、着信電話番号９２２、内線番号９２３、携帯電話番号９２４、及び、メールアドレス９２６を含む。項番９２０は、番号変換情報９２のエントリを一意に示す番号である。

対象ＰＢＸ９２１は、クラウドＰＢＸ８０によるバックアップが行われるＰＢＸ５０を示す。着信電話番号９２２は、対象ＰＢＸ９２１が示すＰＢＸ５０への着信がクラウドＰＢＸ８０に転送される際、転送元として通知されるＰＢＸ５０の電話番号を示す。

内線番号９２３は、対象ＰＢＸ９２１のＰＢＸ５０に接続される内線端末６０の内線番号を示す。携帯電話番号９２４は、内線番号９２３の内線端末６０に割り当てられた利用者が携帯する携帯情報端末７０の携帯電話番号を示す。

メールアドレス９２６は、携帯電話番号９２４の携帯情報端末７０のメールアドレスを示す。クラウドＰＢＸ８０がヘルスチェックによりＰＢＸ５０を障害又は故障と判断した際に、クラウドＰＢＸ８０は携帯情報端末７０にメールにて障害又は故障通知を行い、クラウドＰＢＸ８０がヘルスチェックによりＰＢＸの復旧と判断した際に、クラウドＰＢＸ８０は携帯情報端末７０にメールにて復旧通知を行う。

番号変換情報９２の、項番９２０、対象ＰＢＸ９２１、着信電話番号９２２、内線番号９２３、携帯電話番号９２４及びメールアドレス９２６は、保守者等によってあらかじめ設定されてもよい。また、内線番号９２３と携帯電話番号９２４とメールアドレス９２６とは、後述の処理によって、携帯情報端末７０の利用者によって設定されてもよい。

図６は、実施例１のＰＢＸ５０のバックアップ処理の開始時を示すシーケンス図である。

クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３は、ＰＢＸ５０−１へデータ通信網３０を経由してヘルスチェック情報を、定期的又は保守者等の指示に従い送信し（Ｓ１００）、ＰＢＸ５０−１はクラウドＰＢＸ８０へそのヘルスチェック情報に対する応答を送信する（Ｓ１０１）。クラウドＰＢＸ８０の呼制御機能部９１は、その応答を受信した場合、ＰＢＸ５０−１が障害又は故障状態ではなく正常に稼働していると判断する。

しかし、クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３がＰＢＸ５０−１へヘルスチェック情報を送信したが（Ｓ１０３）、ＰＢＸ５０−１が障害又は故障状態である（Ｓ１０２）ことにより、そのヘルスチェック情報に対する応答が出来ない（Ｓ１０４）場合、クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３は、ヘルスチェック情報に対する応答がないため、ＰＢＸ５０−１が障害又は故障であるであると判断する（Ｓ１０７）。

Ｓ１０７の後、呼制御機能部９１は、ＰＢＸ５０−１をバックアップする処理を開始する（Ｓ１０８）。ＰＢＸ５０−１をバックアップする処理とは、後述のＰＢＸ５０−１への着信を、携帯情報端末７０へ転送する処理である。

なお、クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３がヘルスチェックを行い、ＰＢＸ５０の障害又は故障と判断した場合にのみ、そのＰＢＸ５０へのバックアップ処理を開始するのは、クラウドＰＢＸ８０が最小限の呼制御リソースである一方で、多くのＰＢＸ５０のバックアップを行うため、バックアップ処理に必要なコストを低減するためである。そのため、クラウドＰＢＸ８０の呼制御リソースに制限が無い場合、ＰＢＸ故障監視機能部９３は、ヘルスチェックを実行しなくともよい。

また、実施例１におけるヘルスチェックの方法は、専用のデータ通信網３０を用いたデータ通信によって行われる方法であるが、モバイルキャリア網４０を用いたデータ通信を用いる方法でも良いし、ヘルスチェック情報を変復調した信号を、ＰＳＴＮ２１を介して送受信する方法でも良い。

Ｓ１０８の後、クラウドＰＢＸ８０の呼制御機能部９１は、番号変換情報９２を参照し、ヘルスチェックに応答がなかったＰＢＸ５０−１（以降、バックアップ対象のＰＢＸ５０−１）の内線端末６０に対応するすべての携帯情報端末７０に、障害又は故障通知するメールを送信する（Ｓ１１７）。

なお、メールにて、障害又は故障を通知するのは、ＰＢＸ５０−１への着信がＰＢＸ５０−１を介さず、迂回して携帯情報端末７０−１へ着信する状態であることを携帯情報端末７０−１の利用者へ予め通知し認識してもらうためである。ＰＢＸ５０−１への着信が迂回して携帯情報端末７０−１へ着信する状態であることを携帯情報端末７０−１の利用者が認識する必要が無い場合、呼制御機能部９１は、本障害又は故障通知を実行しなくともよい。

一方、ＰＳＴＮ端末１０から発信し、ＰＳＴＮ２１を介して、障害又は故障したＰＢＸ５０−１に着信があると（Ｓ１０５）、ＰＢＸ５０−１は障害又は故障で有るためにその着信に対し着信応答動作をすることが出来ない（Ｓ１０６）。

このため、ＰＳＴＮ２１は予めサービス契約してある無応答転送サービスにより、ＰＳＴＮ端末１０からＰＢＸ５０−１への着信呼をクラウドＰＢＸ８０へ転送する（Ｓ１０９）。

なお、ここでＰＳＴＮ２１は、既存の無応答転送サービスを用いるとしたが、ＰＳＴＮ２１が、応答ができないＰＢＸ５０−１への着信をクラウドＰＢＸ８０に転送する技術であれば、いかなる方法が用いられてもよい。

例えば、データ通信網３０に監視端末が設置され、この監視端末がＰＢＸ５０−１の障害等を検知し、障害等が発生したＰＢＸ５０への着信を転送する指示をＰＳＴＮ２１に出してもよい。そしてＰＳＴＮ２１は、指示に従い、ＰＢＸ５０−１への着信をクラウドＰＢＸ８０に転送してもよい。

Ｓ１０８の後、クラウドＰＢＸ８０の呼制御機能部９１は、着信があった場合、その着信電話番号を予め設定されている番号変換情報９２の着信電話番号９２２に照らし合わせ、着信が、番号変換情報９２に登録される着信であるか否かを判定する。そして、番号変換情報９２に登録される着信である場合、ＰＢＸ５０−１の障害又は故障によって着信されたと判断する。

呼制御機能部９１は、ＰＢＸ５０−１の障害又は故障によって着信されたものと判断した場合にのみ応答を行い（Ｓ１１８）、ＰＢＸ５０−１が障害又は故障したため、クラウドＰＢＸ８０がバックアップ装置として動作している旨の故障音声ガイダンスを、ＰＳＴＮ端末１０に対し送出する（Ｓ１１９）。

なお、故障音声ガイダンスを送出するのは、ＰＳＴＮ端末１０の発信者に対し、ＰＢＸ５０−１が障害又は故障し、クラウドＰＢＸ８０がバックアップ装置として動作していることを認識させるためであり、ＰＳＴＮ端末１０の発信者が、このような認識を持たなくてよい場合、クラウドＰＢＸ８０は、故障音声ガイダンスを送出しなくともよい。

Ｓ１１９の後、クラウドＰＢＸ８０の呼制御機能部９１は、正常動作時のＰＢＸ５０−１と同様に、ＰＳＴＮ端末１０に対して、通話したい内線番号を要求する（Ｓ１１０）。そして、呼制御機能部９１は、ＰＳＴＮ端末１０から送信される内線番号を取得する（Ｓ１１１）。実施例１では、ダイレクトインラインの着信形態について記述しているが、ダイヤルインやダイレクトインダイヤルなどの他の着信形態時も同様である。

Ｓ１１１の後、クラウドＰＢＸ８０の呼制御機能部９１は、番号変換情報９２を参照し、対象ＰＢＸ９２１がバックアップ対象のＰＢＸ５０を示し、内線番号９２３が取得した内線番号を示すエントリの携帯電話番号９２４を抽出する（Ｓ１１２）。

なお、呼制御機能部９１は、ＰＳＴＮ２１から転送された着信呼が、バックアップ対象のＰＢＸ５０が通信不可であるために転送されたものであることを、着信呼が転送されてきた回線、又は、着信呼に付加される識別子等によって判別してもよい。

呼制御機能部９１は、抽出した携帯電話番号９２４を用いて、モバイルキャリア網４０を介して、携帯情報端末７０−１へ着信を入れ呼び出しを行う（Ｓ１１３）。そして、呼制御機能部９１は、ＰＳＴＮ端末１０に呼出中音を送出する（Ｓ１１４）。

なお、クラウドＰＢＸ８０が携帯情報端末７０−１へ着信を入れるために使用するＰＳＴＮ２２におけるＰＳＴＮ回線を予め決めておき、携帯情報端末７０−１へそのＰＳＴＮ回線の電話番号を電話帳登録しておく。これにより、携帯情報端末７０−１は、障害又は故障したＰＢＸ５０への着信が、クラウドＰＢＸ８０を迂回してきた着信であるか、それ以外の通常の携帯情報端末７０−１への着信かを応答前に判別できる。

Ｓ１１３の後、携帯情報端末７０−１では、着信に対して応答を行い（Ｓ１１５）、ＰＳＴＮ端末１０と携帯情報端末７０−１との音声通信を実現する（Ｓ１１６）。

なお、上記においては、一つの内線番号への着信に対して、一つの携帯情報端末７０−１へ着信を入れ呼び出しを行っている。しかし、呼制御機能部９１は、一般的にＰＢＸ５０で実現できるグループ呼び出しの着信形態と同様に、一つの内線番号に対して複数の携帯情報端末７０を呼び出してもよい。具体的には、番号変換情報９２が、一つの内線番号に対応した携帯電話番号を複数保持することにより、呼制御機能部９１は、一つの内線番号への着信に対して、複数台の携帯情報端末７０へ着信を入れ、呼び出しを行ってもよい。

図７は、実施例１のバックアップ開始時のクラウドＰＢＸ８０の処理を示すフローチャートである。

まず初めに、クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３は、ＰＢＸ５０−１に対してヘルスチェック情報の送信を行う（Ｓ２００）。Ｓ２００は、図６に示すＳ１００及びＳ１０３に相当する。

Ｓ２００の後、ＰＢＸ故障監視機能部９３は、ＰＢＸ５０−１からのヘルスチェック情報に対する応答を、所定の時間経過するまでに検出するか否かを判定する（Ｓ２０１）。所定の時間待ち、ヘルスチェック情報に対する応答を検出した場合（図６に示すＳ１０１に対応）、ＰＢＸ故障監視機能部９３は、ＰＢＸ５０が正常稼働していると判断し、Ｓ２００に戻る。そして、ＰＢＸ故障監視機能部９３は、定期的にＳ２００のヘルスチェック情報を送信し、その応答を検出する。

一方、所定の時間が経過しても、ヘルスチェック情報に対する応答を検出できない場合（図６に示すＳ１０４に対応）、ＰＢＸ故障監視機能部９３は、呼制御機能部９１に応答が検出されないことを通知する。そして、呼制御機能部９１は、ＰＢＸ故障監視機能部９３から応答が検出されないことを通知された場合、ＰＢＸ５０−１が障害又は故障であると判断し（図６に示すＳ１０７に対応）、ＰＢＸ５０−１へのバックアップを開始する（Ｓ２０２：図６に示すＳ１０８に対応）。

そして、呼制御機能部９１は、番号変換情報９２の対象ＰＢＸ９２１、及びメールアドレス９２６に基づいて、バックアップ対象のＰＢＸ５０−１に対応するすべての携帯情報端末７０に対し、障害又は故障を通知するメールを送信する（Ｓ２０３）。

Ｓ２０３の後、呼制御機能部９１は、ＰＳＴＮ２１からの着信を検出するか否かを判定し（Ｓ２０４）、着信が検出されない場合、Ｓ２０４に戻り、継続して着信するかを監視する。着信が検出された場合、その着信の着信電話番号を番号変換情報９２に照らし合わせ、障害又は故障したＰＢＸ５０−１に対応した着信電話番号であるか否かを判定する（Ｓ２０５）。

障害又は故障したＰＢＸ５０−１に対応した着信電話番号である場合呼制御機能部９１は、次のステップ（Ｓ２０６）へ移行するが、一方、障害又は故障したＰＢＸ５０−１に対応した着信電話番号でない場合、Ｓ２０４に戻り、継続的に着信の監視を行う。

クラウドＰＢＸ８０の呼制御機能部９１は、着信が、障害又は故障したＰＢＸ５０−１に対応した着信電話番号であった場合、その着信に対し応答を行い（図６に示すＳ１１８に対応）、ＰＢＸ５０−１が障害又は故障し、クラウドＰＢＸ８０がバックアップ装置として動作している旨の故障音声ガイダンスを、ＰＳＴＮ端末１０に対し送出する（Ｓ２１４：図６に示すＳ１１９に対応）。

Ｓ２１４の後、呼制御機能部９１は、ＰＳＴＮ端末１０に対し、通話したい内線番号を要求し（Ｓ２０６：図６に示すＳ１１０に対応）、内線番号を取得する（Ｓ２０７：図６に示すＳ１１１に対応）。この内線番号を要求する方法は、音声ガイダンス又は特殊トーン等を送出する方法を用いてもよい。

Ｓ２０７の後、呼制御機能部９１は、番号変換情報９２を参照し、取得した内線番号が、バックアップ対象のＰＢＸ５０−１を示すエントリの内線番号９２３に含まれるか否かを判定する（Ｓ２０８）。バックアップ対象のＰＢＸ５０−１を示すエントリの内線番号９２３に含まれない場合、呼制御機能部９１は、Ｓ２０４に戻り、継続的に着信検出監視を行う。

一方、バックアップ対象のＰＢＸ５０−１を示すエントリの内線番号９２３に含まれる場合、呼制御機能部９１は、取得した内線番号に対応した携帯電話番号を番号変換情報９２の携帯電話番号９２４から抽出し（図６に示すＳ１１２に対応）、抽出した携帯電話番号へ発信する。これによって、呼制御機能部９１は、携帯情報端末７０−１を呼び出す（Ｓ２０９：図６に示すＳ１１３に対応）。

Ｓ２０９の後、呼制御機能部９１は、携帯情報端末７０−１からの応答の検出監視を開始する（Ｓ２１０）。所定の時間応答が検出されない場合、呼制御機能部９１は、Ｓ２１０に戻り、継続して応答の検出監視を行う。一方、応答を検出した場合、呼制御機能部９１は、ＰＳＴＮ端末１０と携帯情報端末７０−１とを通話させるための相互通信処理を行う（Ｓ２１１：図６に示すＳ１１６に対応）。

Ｓ２１１の後、呼制御機能部９１は、ＰＳＴＮ端末１０又は携帯情報端末７０−１の切断を検出するか否か判定する（Ｓ２１２）。切断が検出されない場合、呼制御機能部９１は、Ｓ２１２に戻り、継続して切断検出監視を行う。一方、ＰＳＴＮ端末１０及び携帯情報端末７０−１のいずれかの切断を検出した場合、呼制御機能部９１は、ＰＳＴＮ端末１０と携帯情報端末７０−１との通話を切断するための切断処理を行い（Ｓ２１３）、Ｓ２０４へリターンする。

図８は、実施例１のバックアップ終了時の処理を示すシーケンス図である。

図８は、図６に示す処理の後の処理を示す。図８に示すシーケンスの開始時において、バックアップ中のクラウドＰＢＸ８０が呼処理することによって、ＰＳＴＮ端末１０と携帯情報端末７０−１とは通話中である（Ｓ３００）。一方で、クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３は、Ｓ１０４の後もヘルスチェックを継続する。

ＰＢＸ５０−１が障害又は故障状態から正常状態に復旧した場合、クラウドＰＢＸ８０のＰＢＸ故障監視機能部９３は、ＰＢＸ５０−１に対して継続していたヘルスチェック情報（Ｓ３０１）に対する応答を受信する（Ｓ３０２）。これにより、呼制御機能部９１は、ＰＢＸ５０−１が復旧したと判断し（Ｓ３０３）、番号変換情報９２を参照し、ＰＢＸ５０−１の内線電話に対応するすべての携帯情報端末７０に、復旧を通知するメールを送信する（Ｓ３０４）。

なお、メールにて、復旧を通知するのは、ＰＢＸ５０−１への着信が迂回して携帯情報端末７０−１へ着信する状態でなくなったことを携帯情報端末７０−１の利用者へ通知し認識してもらうためである。このため、利用者がこのような認識を有する必要が無い場合、呼制御機能部９１は、Ｓ３０４を実行しなくともよい。

しかし、クラウドＰＢＸ８０の呼制御機能部９１は、Ｓ３０３においてＰＢＸ５０−１が復旧したと判断した段階で、即時バックアップを終了させず、Ｓ３００の通話呼を継続させる（Ｓ３０５）。これは、ＰＳＴＮ端末１０又は携帯情報端末７０による切断以外の要因で、通信を切断するべきではないためである。

Ｓ３０５の後、クラウドＰＢＸ８０の呼制御機能部９１は、Ｓ３０５の通話呼の切断監視を開始する（Ｓ３０６）。ＰＳＴＮ端末１０及び携帯情報端末７０−１のいずれか一方が切断し（Ｓ３０７）、その切断信号（Ｓ３０８）を検出した場合、もう一方に切断を促す終話音を送出する（Ｓ３０９）。そして、もう一方も切断した後（Ｓ３１０）、呼制御機能部９１は、もう一方の切断信号（Ｓ３１１）を検出すると通話呼を終了させる。

この切断監視、及び、切断処理は、図７に示すＳ２１２及びＳ２１３においても実行される。

最後に、クラウドＰＢＸ８０の呼制御機能部９１は、バックアップ中のクラウドＰＢＸ８０により呼処理された通話呼すべての終了を確認し、バックアップ処理を終了する。

図９は、実施例１のバックアップ終了時のクラウドＰＢＸ８０の処理を示すフローチャートである。

バックアップ中のクラウドＰＢＸ８０のＰＢＸ故障監視機能部９３は、ＰＢＸ５０−１に対して継続的にヘルスチェック情報を送信し（Ｓ４００）、ＰＢＸ５０−１からヘルスチェック情報に対する応答の監視を行う。具体的には、ＰＢＸ５０−１から送信されるヘルスチェック情報への応答を検出したか否かを判定する（Ｓ４０１）。ＰＢＸ５０−１からヘルスチェック情報に対する応答が無い場合、ＰＢＸ故障監視機能部９３は、Ｓ４００に戻り、ヘルスチェック情報の送信を継続する。

ＰＢＸ５０−１からヘルスチェック情報に対する応答があった場合、呼制御機能部９１は、ＰＢＸ５０−１が復旧したと判断する（Ｓ４０２）。そして、呼制御機能部９１は、番号変換情報９２を参照し、バックアップ対象のＰＢＸ５０−１に対応するすべての携帯電話番号９２４を抽出し、抽出した携帯電話番号９２４を用いて携帯情報端末７０に対して復旧を通知するメールを送信する（Ｓ４０３）。

Ｓ４０３の後、クラウドＰＢＸ８０の呼制御機能部９１は、バックアップ中のクラウドＰＢＸ８０により呼処理された通話呼があるか否かを判定する（Ｓ４０４）。通話呼が無い場合、呼制御機能部９１は、即時バックアップを終了する（Ｓ４０７）。一方で、通話呼が有る場合、呼制御機能部９１は、その通話呼の切断検出監視を開始し、切断を検出したか否かを判定する（Ｓ４０５）。切断が検出されない場合、呼制御機能部９１は、Ｓ４０５に戻り、継続して切断検出監視を行う。

一方、ＰＳＴＮ端末１０及び携帯情報端末７０−１のいずれかによる切断を検出した場合、呼制御機能部９１は、ＰＳＴＮ端末１０と携帯情報端末７０−１との通話を切断するための切断処理を行う（Ｓ４０６）。呼制御機能部９１は、バックアップ中のクラウドＰＢＸ８０により呼処理された通話呼すべての終了を確認した後、バックアップを終了する（Ｓ４０７）。

図１０は、実施例１の携帯情報端末７０−１の利用者が携帯情報端末７０−１を用いて、番号変換情報９２の登録を行う処理を示すシーケンス図である。

本登録処理の前提条件として、保守者等は、クラウドＰＢＸ８０のパックアップ対象であるＰＢＸ５０毎に一意な、情報登録用ＰＳＴＮ回線と暗証番号とをあらかじめ定め、クラウドＰＢＸ８０に登録する。また、携帯情報端末７０の利用者は、情報登録用ＰＳＴＮ回線に発信するための電話番号と、自らに割り当てられた内線端末６０が接続されるＰＢＸ５０の電話番号と、暗証番号とを保持する。これにより、クラウドＰＢＸ８０の呼制御機能部９１は、携帯情報端末７０の利用者による番号変換情報９２の更新を許可することができる。

まず初めに、携帯情報端末７０−１の利用者（以下、利用者）は、情報登録アプリ７６を起動する。情報登録アプリ７６は、起動した場合、クラウドＰＢＸ８０へ携帯情報端末７０−１の電話番号を通知する発信者番号通知機能を有効に設定する（Ｓ５００）。次に、情報登録アプリ７６は、自らの携帯情報端末７０−１に割り当てられた内線端末６０−１が接続するＰＢＸ５０−１に定められた一意の情報登録用ＰＳＴＮ回線に対して発信を行う（Ｓ５０１）。

Ｓ５０１における発信には、利用者に割り当てられた内線端末６０が接続するＰＢＸ５０の識別子又は着信電話番号と、発信元の電話番号（すなわち携帯情報端末７０−１の電話番号）とが、情報として含まれる。

クラウドＰＢＸ８０の呼制御機能部９１は、情報登録用ＰＳＴＮ回線を介して着信があった場合、その着信に応答する（Ｓ５０２）。呼制御機能部９１は、携帯情報端末７０−１に対し、暗証番号の送信を促す暗証番号音声ガイダンスを送出する（Ｓ５０３）。

Ｓ５０３の後、携帯情報端末７０−１の情報登録アプリ７６は、暗証番号音声ガイダンスを、例えばスピーカーから出力する。そして、利用者が携帯情報端末７０−１のダイヤルボタンを押下することによって、情報登録アプリ７６は暗証番号を取得する。そして、情報登録アプリ７６は、取得した暗証番号をクラウドＰＢＸ８０に送信する（Ｓ５０４）。

クラウドＰＢＸ８０の呼制御機能部９１は、受信した暗証番号と、情報登録用ＰＳＴＮ回線に対応してあらかじめ定められている暗証番号とを比較する（Ｓ５０５）。比較の結果、両者が不一致であった場合、呼制御機能部９１は、携帯情報端末７０−１との通信を切断し（Ｓ５１０）、登録動作を終了する。

一方、比較の結果、両者の暗証番号が一致した場合、呼制御機能部９１は、携帯情報端末７０−１に対し、内線番号の送信を促す内線番号音声ガイダンスを送出する（Ｓ５０６）。なお、Ｓ５０３〜Ｓ５０５の一連の暗証番号認証を行うのは、番号変換情報９２の更新において、高度なセキュリティを確保するためである。このため、番号変換情報９２の更新に、高度なセキュリティを確保する必要が無い場合は、Ｓ５０３〜Ｓ５０５の一連の暗証番号認証が実行されなくてもよい。

Ｓ５０６の後、携帯情報端末７０−１の情報登録アプリ７６は、内線番号音声ガイダンスを、例えばスピーカー等から出力する。携帯情報端末７０−１の利用者は、携帯情報端末７０−１のダイヤルボタンを押下し、携帯情報端末７０−１と対応づける内線端末６０−１の内線番号を、入力する。そして、情報登録アプリ７６は、入力された内線番号をクラウドＰＢＸ８０に送信する（Ｓ５０７）。

クラウドＰＢＸ８０の呼制御機能部９１は、Ｓ５０７までの処理において取得した情報が対応するように、番号変換情報９２に登録する（Ｓ５０８）。

具体的には、Ｓ５０８におけるクラウドＰＢＸ８０の呼制御機能部９１は、Ｓ５０１が着信した情報登録用ＰＳＴＮ回線に割り当てられたＰＢＸ５０を示す識別子又は電話番号を、対象ＰＢＸ９２１又は着信電話番号９２２に格納する。また、Ｓ５０７において受信した内線番号を、内線番号９２３に格納する。また、Ｓ５０１の着信時に受信した発信元の電話番号を、携帯電話番号９２４に格納する。

その後、クラウドＰＢＸ８０の呼制御機能部９１は、登録成功音声ガイダンスを、携帯情報端末７０−１に送出し（Ｓ５０９）、情報登録回線を切断し（Ｓ５１０）、登録処理を終了する。

Ｓ５０９の後、携帯情報端末７０−１の情報登録アプリ７６は、受信した登録成功音声ガイダンスを出力する。また、情報登録アプリ７６は、必要に応じて、発信者番号通知機能を無効に設定する。

クラウドＰＢＸ８０内の番号変換情報９２は、上記以外に、保守者等がクラウドＰＢＸ８０に対して、直接シリアル伝送もしくはＩＰパケット通信を利用して登録する方法によって更新されてもよい。また、保守者又はＰＢＸ５０の利用者が、電話機操作、シリアル伝送、又は、ＩＰパケット通信を利用して、ＰＢＸ５０−１に番号変換情報９２を登録し、ＰＢＸ５０−１が、データ通信網３０等のライフチェック経路を利用して、クラウドＰＢＸ８０へ番号変換情報９２を登録してもよい。

なお、上記実施例の方法及び代替方法は、内線端末６０の内線番号と携帯情報端末７０−１の携帯電話番号とを対応づけした情報の登録方法を記載したが、内線端末６０の内線番号と携帯情報端末７０−１のメールアドレスを対応づけた情報の登録方法も同様の方法で実行可能である。

図１１は、実施例１の携帯情報端末７０に送信される故障通知７１１を示す説明図である。

図１１は、クラウドＰＢＸ８０がヘルスチェックによりＰＢＸ５０を障害又は故障と判断した際に、Ｓ１１８においてクラウドＰＢＸ８０が携帯情報端末７０−１に送信する障害又は故障通知７１１の表示内容の一例である。Ｓ３０４において送信された復旧通知も、図１１に示す形式と同様の形式である。

故障通知７１１には、ＰＢＸ５０において障害等が発生したこと、障害等が発生した時刻、及び、バックアップ処理が開始したことを示す内容が含まれる。携帯情報端末７０のバックアップアプリ７７は、ディスプレイに故障通知７１１を表示する。

図１２は、実施例１のクラウドＰＢＸ８０がバックアップ中に、携帯情報端末７０−１からの発信された際の処理を示すシーケンス図である。

図１２に示す処理は、携帯情報端末７０−１からＰＢＸ５０−１の外線電話（ＰＳＴＮ２１に接続する電話端末）であるＰＳＴＮ端末１０へ発信する処理である。図１２に示す処理は、図６に示すＳ１１７の後に実行される。

なお、本発信処理の前提条件として、保守者は、ＰＢＸ５０毎に一意なバックアップ発信用ＰＳＴＮ回線を、クラウドＰＢＸ８０及び携帯情報端末７０間に登録しておき、そのバックアップ発信用ＰＳＴＮ回線に、一般的なＰＳＴＮがサービスを行っている着信課金サービスを利用する契約を行い、着信課金電話番号を付与しておく。

まず初めに、ＰＢＸ５０−１が障害又は故障状態であると認識している携帯情報端末７０−１の利用者は、着信課金電話番号へ発信を行う。そして、携帯情報端末７０−１から、バックアップ発信用ＰＳＴＮ回線を介して着信を受けた場合、ＰＳＴＮ２２は、着信課金サービスを利用し、着信課金電話番号に対応付けしたクラウドＰＢＸ８０宛てのバックアップ発信用ＰＳＴＮ回線に発信を行う（Ｓ６００）。

バックアップ発信用ＰＳＴＮ回線を介して着信を受けた場合、クラウドＰＢＸ８０は、応答を行い（Ｓ６０１）、電話番号の送信を促す発信要求音声ガイダンスを、携帯情報端末７０−１に送出する（Ｓ６０２）。Ｓ６０２の後、携帯情報端末７０−１は、例えば"０"発信に代表される外線発信を識別するダイヤル（外線発信識別ダイヤル）を送信する（Ｓ６０３）。

Ｓ６０３の後、携帯情報端末７０−１は、ＰＳＴＮ端末１０の電話番号ダイヤルを、バックアップ発信用ＰＳＴＮ回線を介して送信する（Ｓ６０４）。Ｓ６０４の後、クラウドＰＢＸ８０の呼制御機能部９１は、携帯情報端末７０−１から受信したＰＳＴＮ端末１０の電話番号ダイヤルを元に、ＰＳＴＮ２１を介して、ＰＳＴＮ端末１０へ着信を入れる（Ｓ６０５）。そして、クラウドＰＢＸ８０の呼制御機能部９１は、携帯情報端末７０−１に対して呼出し中音を送出する（Ｓ６０６）。

Ｓ６０５の後、ＰＳＴＮ端末１０は、着信に対して応答を行い（Ｓ６０７）、ＰＳＴＮ端末１０と携帯情報端末７０−１との音声通信が行われる（Ｓ６０８）。

上記の通り、着信課金サービスを利用することにより、携帯情報端末７０−１の発信でも、携帯情報端末７０−１には課金されず、クラウドＰＢＸ８０に課金されるため、携帯情報端末７０−１をＰＢＸ５０−１の内線端末６０−２を利用する場合と同様に無課金で使用することが可能である。

なお、上記は、携帯情報端末７０−１からＰＢＸ５０−１の外線電話（ＰＳＴＮ２１に接続する電話端末）であるＰＳＴＮ端末１０へ発信する場合を記載したが、携帯情報端末７０−１からＰＢＸ５０−１の内線端末６０への発信も同様に実現可能である。具体的には、クラウドＰＢＸ８０が、Ｓ６０１の応答を実行し、携帯情報端末７０−１から内線電話ダイヤルを受信した後に、番号変換情報９２を参照し、着信したバックアップ発信用ＰＳＴＮ回線と受信した内線電話ダイヤルから割り当てられた携帯情報端末７０を識別し発信を行う。

実施例１によれば、ＰＢＸ５０とＰＳＴＮ２１を介して接続されるクラウドＰＢＸ８０が、ＰＢＸ５０が障害又は故障時にＰＢＸ５０のバックアップを行うことによって、拠点５５に設置されたＰＢＸ５０のバックアップを行うことができる。このため、拠点５５にＰＢＸ５０の冗長機能を設置する必要がなく、低コストによりＰＢＸ５０のバックアップを実現することができる。

また、クラウドＰＢＸ８０は、複数のＰＢＸ５０のバックアップを行うことができるため、拠点５５に設置されたＰＢＸ５０の一つ一つに代替ＰＢＸを設置する必要がない。このため、低コストによりＰＢＸ５０のバックアップを実現することができる。

実施例１は、ＰＢＸ５０停止による通話不可時間の最小化に焦点を置いており、故障前と同等の機能を補償していない。具体的には、実施例１の通信システムは、着信した際に相手の番号を表示するナンバーディスプレイ機能、発信時の電話帳の閲覧機能などを提供することが出来ない。このため、利用者が、ＰＢＸ５０の正常時と同様のサービスをＰＢＸ５０の故障時に利用できないという課題がある。

図１３は、実施例２の通信システムの構成を示す説明図である。

実施例２の通信システムは、実施例１の通信システムと同じく、ＰＳＴＮ端末１０、ＰＳＴＮ２１、ＰＳＴＮ２２、データ通信網３０、モバイルキャリア網４０、複数の拠点５５（５５−１、５５−２）、複数の携帯情報端末７０（７０−１、７０−２）、及びクラウドＰＢＸ８０を含む。

実施例２の拠点５５−１は、実施例１と同じく、ＰＢＸ５０−１及び内線端末６０−１を含み、実施例２の拠点５５−２は、実施例１と同じく、ＰＢＸ５０−２及び内線端末６０−２を含む。また、図１３は、拠点５５−１に含まれる内線端末６０−３を示し、拠点５５−２に含まれる内線端末６０−４を示す。

実施例１と実施例２との相違点は、実施例２の通信システムが、情報端末９０を有する点と、クラウドＰＢＸ８０が電話帳バックアップ情報９６とを用いる点である。

情報端末９０は、モバイルキャリア網４０に接続し、モバイルキャリア網４０に接続されている他端末との間で音声通話を行う携帯端末である。

図１４は、実施例２の番号変換情報９２及び電話帳バックアップ情報９６を示す説明図である。

実施例２の番号変換情報９２は、実施例１の番号変換情報９２の内容と、電話帳９２５とを含む。電話帳９２５は、電話帳バックアップ情報９６のリンクを含む。電話帳バックアップ情報９６は、内線番号９２３の内線端末６０に登録される電話帳の内容を含む。

電話帳バックアップ情報９６は、電話帳ＩＤ９６０、利用者名９６１、電話番号９６２及び内線番号９６３を含む。電話帳ＩＤ９６０は、電話帳データの識別子を示し、電話帳９２５に含まれる値に対応する。電話帳ＩＤ９６０は、対象ＰＢＸ９２１及び内線番号９２３の組み合わせに対して一意の識別子を含む。

利用者名９６１は、ＰＳＴＮ端末１０、携帯情報端末７０及び情報端末９０のいずれかの利用者の氏名又は名称等の情報を示す。電話番号９６２は、ＰＳＴＮ端末１０又は携帯情報端末７０に割り当てられた電話番号を示す。

内線番号９６３は、内線端末６０の内線番号を示す。電話帳データを保持する内線端末６０が、自らが設置される拠点５５内の他の内線端末６０の内線番号を保持する場合、内線番号９６３に他の内線端末６０の内線番号が格納される。

クラウドＰＢＸ８０は、各拠点５５のＰＢＸ５０が持つ内線端末６０ごとの電話帳データを、ヘルスチェック時にバックアップする。具体的には、クラウドＰＢＸ８０は、収集した電話帳データを、クラウドＰＢＸ８０内の電話帳バックアップ情報９６に格納する。そして、ＰＢＸ５０が障害又は故障時に携帯情報端末７０−１のアプリ動作により、電話帳が呼び出された場合、クラウドＰＢＸ８０は、携帯情報端末７０−１の番号と対応した電話帳データを、携帯情報端末７０−１に表示させる。

なお、電話帳バックアップ情報９６は、前述の利用者名９６１及び電話番号９６２以外に、ＰＳＴＮ端末１０、携帯情報端末７０及び情報端末９０の利用者に関するいかなる情報も含んでよい。例えば、利用者の所属、及び、住所などを含んでもよい。

図１５は、実施例２のＰＢＸ５０のバックアップ処理の開始時を示すシーケンス図である。

図１５に示す処理は、図６に示す処理と同じく、ＰＢＸ５０−１が故障又は障害中に、ＰＳＴＮ端末１０からＰＢＸ５０−１に着信があった場合の処理を示す。図１５に示す処理は、図６に示す処理の他に、携帯情報端末７０−１がアプリケーションを起動する処理を含む。これによってナンバーディスプレイ機能が、携帯情報端末７０−１に追加される。下記の説明では、図６の説明にて述べた箇所は省略する。

ＰＢＸ５０−１のバックアップを開始した後（Ｓ１０８）、呼制御機能部９１は、携帯情報端末７０−１に、バックアップアプリ７７の起動の許可を送信する（Ｓ１１００）。Ｓ１１００の後、携帯情報端末７０−１のバックアップアプリ７７が起動する（Ｓ１１０１）。

Ｓ１０６の後、ＰＳＴＮ２１は、実施例１におけるＳ１０９に加えて、発信者であるＰＳＴＮ端末１０の電話番号を含む着信呼を、クラウドＰＢＸ８０に転送する（Ｓ１１０９）。

さらに、ＰＳＴＮ端末１０より内線番号を取得した後（Ｓ１１１）、呼制御機能部９１は、取得した内線番号が、バックアップ対象のＰＢＸ５０−１を示すエントリの内線番号９２３に含まれるか否かを判定する。含む場合、呼制御機能部９１は、取得した内線番号に対応する電話帳９２５の電話帳データを、番号変換情報９２から抽出する。そして、呼制御機能部９１は、抽出した電話帳データの電話番号９６２と、Ｓ１１０９において転送された着信呼に含まれる発信者番号とを照合させることによって、発信者の情報（利用者名９６１等）を検索する（Ｓ１１０２）。

Ｓ１１０２の後、呼制御機能部９１は、番号変換情報９２を参照し、対象ＰＢＸ９２１がバックアップ対象のＰＢＸ５０を示し、内線番号９２３がＰＳＴＮ端末１０から取得した内線番号を示すエントリの携帯電話番号９２４を抽出する（Ｓ１１２）。

Ｓ１１０２における検索の結果、抽出した電話帳データに発信者番号（本実施例ではＰＳＴＮ端末１０の電話番号）が登録されている場合、呼制御機能部９１は、電話帳データに登録される利用者名９６１等の発信者情報を、携帯情報端末７０−１のバックアップアプリ７７に送信する。ここで、呼制御機能部９１は、Ｓ１１２において抽出した携帯電話番号９２４に従って、携帯情報端末７０−１に発信者情報を送信する。

また、Ｓ１１０２における検索の結果、抽出した電話帳データに発信者番号が登録されていない場合、呼制御機能部９１は、発信者番号のみを発信者情報として携帯情報端末７０−１のバックアップアプリ７７に送信する（Ｓ１１０３）。Ｓ１１０３の後、呼制御機能部９１は、抽出した携帯電話番号９２４を用いて、モバイルキャリア網４０を介して、携帯情報端末７０−１へ着信を入れ呼び出しを行う（Ｓ１１３）。

Ｓ１１０３の後、バックアップアプリ７７は、発信者情報をディスプレイに表示する（Ｓ１１０４）。クラウドＰＢＸ８０が発信者情報を携帯情報端末７０に提供することにより、内線端末６０に実現されていたものと同等のナンバーディスプレイ機能を、携帯情報端末７０に提供することができる。

図１６は、実施例２のバックアップ開始時のクラウドＰＢＸ８０の処理を示すフローチャートである。

実施例２の通信システムは、携帯情報端末７０がバックアップアプリ７７を実行することによって、携帯情報端末７０がナンバーディスプレイ機能を有する。下記の説明では、図７の説明にて述べた箇所は省略する。

Ｓ２０２の後、クラウドＰＢＸ８０の呼制御機能部９１は、携帯情報端末７０−１にバックアップアプリ７７の起動の許可を送信する（Ｓ１２００）。Ｓ１２００の後、Ｓ２０３が実行される。

Ｓ２０４において着信が検出された場合、呼制御機能部９１は、バックアップアプリ７７からの着信であるか否かを判定する（Ｓ１２０１）。呼制御機能部９１は、着信した携帯電話番号が番号変換情報９２の携帯電話番号９２４に登録されている場合、着信がバックアップアプリ７７からであると判定する。

Ｓ１２０１の処理は、例えば、携帯情報端末７０−１の利用者が、内線端末６０−３を割り当てられた利用者と通話することを目的に、携帯情報端末７０−１のバックアップアプリ７７から、内線端末６０−３宛ての発信をクラウドＰＢＸ８０に送信した場合に実行される。このため、バックアップアプリ７７からの着信には、携帯情報端末７０が属するＰＢＸ５０と通話したい内線番号とを示す情報が含まれる。

バックアップアプリ７７からの着信の場合、呼制御機能部９１は、故障ガイダンスの携帯情報端末７０への送出（Ｓ２１４に相当）、及び、内線番号の携帯情報端末７０への要求（Ｓ２０６に相当）を省略し、Ｓ２０７を実行する。Ｓ２０７において、呼制御機能部９１は、着信又は送信された情報から内線番号を取得する。

呼制御機能部９１は、取得した内線番号が、バックアップ対象のＰＢＸ５０−１を示すエントリの内線番号９２３に含まれるか否かを判定する（Ｓ２０８）。取得した内線番号がバックアップ対象のＰＢＸ５０−１を示すエントリに含まれない場合、呼制御機能部９１は、Ｓ２０４に戻り着信を待つ。

取得した内線番号がバックアップ対象のＰＢＸ５０−１を示すエントリに含まれる場合、呼制御機能部９１は、取得した内線番号と対応した電話帳データを電話帳９２５から抽出する。そして、呼制御機能部９１は、抽出した電話帳データの利用者名９６１の番号を検索する（Ｓ１２０２：図１５に示すＳ１１０２に対応）。

呼制御機能部９１は、抽出した電話帳データに発信者（携帯情報端末７０−１又はＰＳＴＮ端末１０）の番号が登録されているか否かを判定し（Ｓ１２０３）、登録されている場合、登録されている利用者名９６１などの発信者情報を、着信先の携帯情報端末７０のバックアップアプリ７７に送信する（Ｓ１２０４）。

また、呼制御機能部９１は、電話帳に発信者の番号が登録されていない場合、内線番号に対応する携帯電話番号のみを、着信先の携帯情報端末７０のバックアップアプリ７７に送信する（Ｓ１２０５）。Ｓ１２０４及びＳ１２０５は、図１５に示すＳ１１０３に対応する。Ｓ１２０５の後、呼制御機能部９１は、Ｓ２０９を実行する。

これによって、携帯情報端末７０を利用する者は、ＰＢＸ５０が故障時にも、内線番号によって他の携帯情報端末７０に発信することができる。

次に、実施例２のバックアップ終了時の処理のシーケンスを説明する。実施例２のバックアップ終了時のシーケンスは、実施例１における図８のシーケンスと同様であるが、以下に相違点を記載する。

実施例２のクラウドＰＢＸ８０の呼制御機能部９１は、クラウドＰＢＸ８０がＰＢＸ５０−１の復旧を確認し（Ｓ３０３）、ＰＳＴＮ端末１０又は携帯情報端末７０−１の一方が切断し（Ｓ３０７）、その切断信号を検出した後（Ｓ３０８）、バックアップ対象のＰＢＸ５０に対応する携帯情報端末７０すべてにアプリ終了命令を送信する。

そして、アプリ終了命令を受けた携帯情報端末７０−１は、アプリの起動許可を受信するまでアプリの停止を行う。

さらに、実施例２のバックアップ終了時のクラウドＰＢＸ８０の処理のフローチャートの相違点を以下に示す。実施例２のバックアップ終了時のフローチャートは、実施例１における図９のフローチャートと同様であるが、以下に相違点を記載する。

クラウドＰＢＸ８０の呼制御機能部９１は、Ｓ４０４において、バックアップ動作中のクラウドＰＢＸ８０により呼処理された通話呼の有無の監視を開始した後、通話呼が無いと判定された場合、又は、通話呼の切断検出を確認し（Ｓ４０５）、切断処理を行った（Ｓ４０６）後、アプリ終了命令をすべての携帯情報端末７０に送信する。

そして、バックアップ対象のＰＢＸ５０に対応するすべての携帯情報端末７０に、アプリ終了命令を送信した後、呼制御機能部９１は、Ｓ４０７を実行する。

図１７は、実施例２の携帯情報端末７０から他の携帯情報端末７０を呼び出す処理を示すシーケンス図である。

図１７に示す処理は、ＰＢＸ５０−１が故障又は障害中であり、携帯情報端末７０−１が携帯情報端末７０−３を呼び出す際の処理を示す。このため、図１７に示すＳ１００〜Ｓ１０４、Ｓ１０７、Ｓ１０８、Ｓ１１００、Ｓ１１７及びＳ１１０１は、図１５に示すＳ１００〜Ｓ１０４、Ｓ１０７、Ｓ１０８、Ｓ１１００、Ｓ１１７及びＳ１１０１と同じである。

携帯情報端末７０−１のバックアップアプリ７７が起動した後、携帯情報端末７０−１の利用者は、バックアップアプリ７７が提供する電話帳モード、又は、番号入力モードを選択する。図１７に示す処理において利用者は、電話帳モードを起動する（Ｓ１５００）。

電話帳モードが起動された場合、バックアップアプリ７７は、クラウドＰＢＸ８０に携帯情報端末７０−１に対応する内線端末６０の電話帳を呼び出すように指示する（Ｓ１５０１）。Ｓ１５０１における指示には、携帯情報端末７０−１の電話番号、又は、携帯情報端末７０−１に対応する内線端末６０及びＰＢＸ５０−１を示す情報が含まれる。

呼出を指示された場合、呼制御機能部９１は、番号変換情報９２と呼出しに含まれる番号とを照合することによって、携帯情報端末７０−１に対応する電話帳データを抽出する（Ｓ１５０２）。電話帳データを抽出できた場合、呼制御機能部９１は、対応する電話帳データを携帯情報端末７０−１に送信する（Ｓ１５０３）。

携帯情報端末７０−１のバックアップアプリ７７は、送信された電話帳データを表示する（Ｓ１９０６）。利用者は、表示された電話帳データから発信先を選択する（Ｓ１５０４）。図１７に示す例において、利用者は、内線端末６０−３の内線番号（内線番号９６３）を発信先として選択する。

Ｓ１５０１〜Ｓ１５０３及びＳ１９０６により、クラウドＰＢＸ８０から携帯情報端末７０に電話帳データが送信される。これによって、携帯情報端末７０に、内線端末６０と同等の電話帳の閲覧機能を提供することができる。

携帯情報端末７０−１のバックアップアプリ７７は、クラウドＰＢＸ８０へ発信先の呼出を行う（Ｓ１５０５）。ここで、バックアップアプリ７７は、Ｓ１５０４における選択に基づいて、発信先の内線端末６０の内線番号を呼出しに含め、さらに、携帯情報端末７０−１の携帯電話番号を発信者番号として呼出しに含める。また、Ｓ１５０５における呼出しには、携帯情報端末７０−１が対応する内線端末６０が接続するＰＢＸ５０−１の識別子も含まれる。

Ｓ１５０５によって、呼制御機能部９１は、発信先の内線番号を取得する。これは、図１６に示すＳ２０７に相当する。

Ｓ１５０５の後、呼制御機能部９１は、Ｓ１５０５の呼出しにより取得したＰＢＸ５０の識別子が対象ＰＢＸ９２１に含まれるエントリに、Ｓ１５０５の呼出しにより取得した内線番号を含む内線番号９２３のエントリが含まれるか否かを判定する（図１６に示すＳ２０８に対応）。

含まれる場合、呼制御機能部９１は、Ｓ１５０５の呼出しにより取得した内線番号及びＰＢＸ５０の識別子に対応する電話帳９２５の電話帳データを、番号変換情報９２から抽出する。ここで抽出される電話帳データは、携帯情報端末７０−３が保持する電話帳データである。

そして、呼制御機能部９１は、抽出した電話帳データの電話番号９６２と、Ｓ１５０５の呼出しに含まれる発信者番号とを照合させることによって、発信者情報（利用者名９６１等）を検索する（Ｓ１１０２）。ここで検索される発信者情報は、携帯情報端末７０−１の情報である。

Ｓ１１０２の後、呼制御機能部９１は、Ｓ１１２を実行し、内線番号から着信の宛先（携帯情報端末７０−３）の携帯電話番号９２４を特定する。

Ｓ１１２の後、Ｓ１１０２において電話帳に発信者の内線番号（本実施例では内線端末６０−１）が検索できた場合、呼制御機能部９１は、登録されている名前などの発信者情報を携帯情報端末７０−３のバックアップアプリ７７に送信する。また、電話帳に発信者の番号が登録されていない場合、内線番号のみを発信者情報として、着信の宛先である携帯情報端末７０−３のバックアップアプリ７７に送信する（Ｓ１１０３）。

Ｓ１１０３の後、Ｓ１１３が実行される。バックアップアプリ７７は、発信者情報を受信した後に着信を受信した場合、発信者情報と、着信があったこととをディスプレイに表示する。

発信者情報をＳ１１３における呼出しの前に送信することによって、携帯情報端末７０に対応する内線端末６０が有するすべての電話帳データを携帯情報端末７０に送信しなくても、ナンバーディスプレイ機能を提供できる。図１７に示すＳ１１３以降の処理は、図１５に示すＳ１１３以降の処理と同じである。

図１８は、実施例２の発信時にバックアップアプリ７７を使用した時の携帯情報端末７０の処理を示すフローチャートである。

携帯情報端末７０−１は、クラウドＰＢＸ８０よりアプリ起動許可を受信したか否か判定する（Ｓ１６００）。アプリ起動の許可を受信しない場合、ＰＢＸ５０−１が正常動作していると判別し、携帯情報端末７０−１はバックアップアプリ７７を起動せず、Ｓ１６００を繰り返す。一方で、アプリ起動の許可を受信した場合、ＰＢＸ５０−１が障害又は故障等の異常動作と判別し、携帯情報端末７０−１はバックアップアプリ７７を起動する（Ｓ１６０１）。

Ｓ１６００の後、バックアップアプリ７７は、利用者によるモードの選択を受け付ける。そして、受け付けたモードが、電話帳モードであるか、番号入力モードであるかを判定する（Ｓ１６０２）。

利用者が電話帳モードを選択した場合、バックアップアプリ７７は、携帯情報端末７０−１のディスプレイに電話帳モードを示す画面を表示し、電話帳モードを起動する（Ｓ１６０３：図１７に示すＳ１５００に対応）。そして、バックアップアプリ７７は、番号変換情報９２に登録される携帯情報端末７０−１に対応する内線端末６０−１の電話帳を、クラウドＰＢＸ８０から呼び出し、携帯情報端末７０−１のディスプレイに表示する（Ｓ１６０４：図１７に示すＳ１５０１、Ｓ１５０３及びＳ１９０６に相当）。

利用者は、呼び出した電話帳から発信先を選択する（Ｓ１６０５：図１７に示すＳ１５０４に相当）。これによって、クラウドＰＢＸ８０を経由して指定の宛先を呼び出す（Ｓ１６０８：図１７に示すＳ１５０５に相当）。

一方で、利用者が番号入力モードを選択した場合、バックアップアプリ７７は、携帯情報端末７０−１のディスプレイに番号入力モードを示す画面を表示し、番号入力モードを起動する（Ｓ１６０６）。ここで、バックアップアプリ７７は、番号の入力を要求する画面を表示する。利用者は、番号入力要求に対し、宛先の内線番号を入力する（Ｓ１６０７）。Ｓ１６０７において宛先の内線番号を入力されることで、バックアップアプリ７７は、クラウドＰＢＸ８０を経由して指定の宛先を呼び出す（Ｓ１６０８）。

ここで、内線番号ではない、通常の外線番号によって発信する場合、バックアップアプリ７７は、利用者が入力する指定の番号を受け付ける。これによって、バックアップアプリ７７は、指定の番号を受け付けた場合、クラウドＰＢＸ８０に宛先の呼び出しを指示せず、ＰＳＴＮ２２を介した通常の通話を行う。

Ｓ１６０８の後、バックアップアプリ７７は、宛先の応答を検出した場合（Ｓ１６０９）、相互通信（通話開始）処理を行う（Ｓ１６１０）。バックアップアプリ７７は、携帯情報端末７０−１又は宛先の携帯情報端末７０による切断を検出した場合（Ｓ１６１１）、切断処理（Ｓ１６１２）を行い、相互通信（通話開始）を終了する。

図１９は、実施例２のＰＳＴＮ端末１０及び携帯情報端末７０以外の情報端末９０から呼び出された場合の携帯情報端末７０−１の処理を示すシーケンス図である。

図１９に示す処理は、ＰＢＸ５０−１が故障又は障害中であり、情報端末９０が携帯情報端末７０−１を呼び出す際の処理を示す。このため、図１９に示すＳ１００〜Ｓ１０４、Ｓ１０７、Ｓ１０８、Ｓ１１００、Ｓ１１７及びＳ１１０１は、図１５に示すＳ１００〜Ｓ１０４、Ｓ１０７、Ｓ１０８、Ｓ１１００、Ｓ１１７及びＳ１１０１と同じである。

情報端末９０は、携帯情報端末７０に割り当てられた携帯電話番号を用いて、携帯情報端末７０を呼び出す（Ｓ１７００）。携帯情報端末７０−１のバックアップアプリ７７は、着信がクラウドＰＢＸ８０を経由した着信でないため、携帯情報端末７０−１に割り当てられた携帯電話番号に通常の着信があったと判定する（Ｓ１７０１）。

なお、クラウドＰＢＸ８０を経由した着信には、クラウドＰＢＸ８０を示す識別子が含まれるため、バックアップアプリ７７は、着信にクラウドＰＢＸ８０を示す識別子が含まれる場合、着信がクラウドＰＢＸ８０を経由した着信であると判定する。

Ｓ１７０１の後、携帯情報端末７０−１のバックアップアプリ７７は、通常着信動作に沿い、携帯情報端末７０−１があらかじめ有する電話帳と発信元番号とを照合し、発信者情報の表示を行う（Ｓ１７０２）。そして、携帯情報端末７０−１のバックアップアプリ７７は、情報端末９０に応答し（Ｓ１１５１）、情報端末９０と相互に通信する（Ｓ１１６１）。

図２０は、実施例２の着信時にバックアップアプリ７７を使用した時の携帯情報端末７０−１の処理を示すフローチャートである。

携帯情報端末７０−１は、クラウドＰＢＸ８０よりアプリ起動許可を受信したか否か判定する（Ｓ１８００）。アプリ起動の許可を受信しない場合、ＰＢＸ５０−１が正常動作していると判別し、携帯情報端末７０−１はバックアップアプリ７７を起動せず、Ｓ１８００を繰り返す。一方で、アプリ起動の許可を受信した場合、ＰＢＸ５０−１が障害又は故障等の異常動作と判別し、携帯情報端末７０−１はバックアップアプリ７７を起動する（Ｓ１８０１：図１９に示すＳ１１０１に相当）。

なお、Ｓ１８００及びＳ１８０１は、図１８に示すＳ１６００及びＳ１６０１と同じである。このため、バックアップアプリ７７は、Ｓ１６００及びＳ１６０１の後、Ｓ１６０２と並行して、Ｓ１８０２を実行してもよい。

バックアップアプリ７７を起動した後、着信を検出したか否か判定する（着信の検出監視）（Ｓ１８０２）。着信を検出した場合、初めにクラウドＰＢＸ８０からの着信か否かを判別する。判別は、クラウドＰＢＸ８０の番号から着信したか否かで行う（Ｓ１８０３）。

クラウドＰＢＸ８０からの着信の場合、バックアップアプリ７７は、着信が、故障したＰＢＸ５０−１から転送されたものであると判別し（Ｓ１８０４）、クラウドＰＢＸ８０から発信者情報を受信する（Ｓ１８０５）。そして、バックアップアプリ７７は、受信した発信者情報を表示（Ｓ１８０６）して着信する。

ここで、バックアップアプリ７７は、発信者情報と、クラウドＰＢＸ８０を経由した着信であること（すなわち、ＰＢＸ５０のバックアップ中であること）とを表示してもよい。これにより、利用者は、ＰＢＸ５０のバックアップによる着信であるか、通常の着信であるかを認識することができる。

一方で、クラウドＰＢＸ８０からの着信ではない場合、バックアップアプリ７７は、携帯情報端末７０−１に割り当てられた携帯電話番号への着信と判別する（Ｓ１８０７：図１９に示すＳ１７０１に相当）。そして、バックアップアプリ７７は、携帯情報端末７０−１があらかじめ有するナンバーディスプレイ機能を用いて、あらかじめ有する電話帳と発信元番号とを照合し、抽出した発信者情報を表示（Ｓ１８０８：図１９に示すＳ１７０２に対応）して着信する。

そして、利用者がバックアップアプリ７７を介して着信に対して応答し（Ｓ１８０９：図１９に示すＳ１１５１に対応）、バックアップアプリ７７は、相互通信（通話開始）処理を行う（Ｓ１８１０：図１９に示すＳ１１６１に対応）。バックアップアプリ７７は、携帯情報端末７０−１又は相手の端末による切断を検出した場合（Ｓ１８１１）、切断処理を行い（Ｓ１８１２）、相互通信（通話開始）を終了する。

図２１は、実施例２の電話帳データの定期バックアップと故障時のバックアップアプリ７７の処理を示すシーケンス図である。

図２１に示す処理において、まず、クラウドＰＢＸ８０に番号変換情報９２が登録される（Ｓ１９００）。Ｓ１９００において、番号変換情報９２には、内線端末６０−１及び携帯情報端末７０−１と、内線端末６０−３及び携帯情報端末７０−３とが、対応して登録される。

登録される方法は、実施例１の図１０に示す処理によって登録されてもよいし、クラウドＰＢＸ８０の保守者によって登録されてもよい。

一方で、内線端末６０−１及び内線端末６０−３の各々には、利用者によって電話帳データが登録される（Ｓ１９０１）。Ｓ１９０１の後、内線端末６０−１及び内線端末６０−３は、登録された電話帳データをＰＢＸ５０−１へ送信する（Ｓ１９０２）。

各内線端末６０の電話帳データを受信した場合、ＰＢＸ５０−１は、受信した電話帳データを一時的に保存する（Ｓ１９０３）。そして、クラウドＰＢＸ８０によるヘルスチェック処理の際（Ｓ１００、Ｓ１０１）、ＰＢＸ５０−１は、保存した電話帳データをクラウドＰＢＸ８０に送信する（Ｓ１９０４）。

ＰＢＸ５０−１から電話帳データを受信した場合、クラウドＰＢＸ８０の呼制御機能部９１は、電話帳バックアップ用メモリ８６の電話帳バックアップ情報９６に、受信した電話帳データを内線端末６０ごとに識別子を付して保存する（Ｓ１９０５）。また、Ｓ１９０５において、呼制御機能部９１は、番号変換情報９２の電話帳９２５に、電話帳データに付された識別子を格納する。

ＰＢＸ５０が、クラウドＰＢＸ８０によるヘルスチェックの際に電話帳データをクラウドＰＢＸ８０に送信することによって、クラウドＰＢＸ８０は、最新の電話帳データを保持することができる。

Ｓ１９０５の後、ＰＢＸ５０−１において故障又は障害が発生した場合（Ｓ１０２）、図１７に示すＳ１０３、Ｓ１０４、Ｓ１０７、Ｓ１０８、Ｓ１１００、Ｓ１１７、Ｓ１１０１、Ｓ１５００〜Ｓ１５０３及びＳ１９０６が実行される。Ｓ１９０６の後、利用者から発信先を入力された場合、図１７におけるＳ１５０４以降が実行される（Ｓ１１７１）。

図２２は、実施例２の発信の際にバックアップアプリ７７が表示する画面２００１を示す説明図である。

図２２に示す画面２００１は、バックアップアプリ７７によって携帯情報端末７０のディスプレイに表示される。例えば、利用者が発信をバックアップアプリ７７に発信を指示した場合、バックアップアプリ７７は画面２００１を表示する。

画面２００１は、電話帳モードアイコン２００２及び番号入力モードアイコン２００３を含む。電話帳モードアイコン２００２を利用者が操作した場合、図１７に示すＳ１５００、図１８に示すＳ１６０３、及び、図２１に示すＳ１５００が実行される。

番号入力モードアイコン２００３を利用者が操作した場合、図１８に示すＳ１６０６が実行される。

図２３は、実施例２の着信の際にバックアップアプリ７７が表示する画面２００４を示す説明図である。

図２３に示す画面２００４は、バックアップアプリ７７によって携帯情報端末７０のディスプレイに表示される。画面２００４は、図１５に示すＳ１１０４、図１６に示すＳ１２０４及びＳ１２０５、図１７に示すＳ１１０４、並びに、図２０に示すＳ１８０６において表示される。

画面２００４は、発信者情報２００５、応答アイコン２００６及び拒否アイコン２００７を含む。発信者情報２００５には、クラウドＰＢＸ８０を経由した着信であること、及び、発信者情報が表示される。ここで、発信者情報とは、図１７においては、発信者である携帯情報端末７０−１を示す名称又は内線番号である。

応答アイコン２００６は、利用者が着信に応答する場合に操作されるアイコンである。また、拒否アイコン２００７は、利用者が着信を拒否する場合に操作されるアイコンである。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手順等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、又はファイル等の情報は、メモリ、ハードディスク若しくはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、又は、ＩＣカード、ＳＤカード若しくはＤＶＤ等の記録媒体に置くことができる。

また、制御線又は情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線又は情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されている。

１０ ＰＳＴＮ端末
２１ ＰＳＴＮ
３０ データ通信網
４０ モバイルキャリア網
５０−１、５０−２ ＰＢＸ
６０−１、６０−２、６０−３、６０−４ 内線端末
７０−１、７０−２、７０−３、７０−４ 携帯情報端末
８０ クラウドＰＢＸ
９０ 情報端末

Claims (9)

1. 交換機であって、
   プロセッサ、メモリ及びネットワークインタフェースを備え、
   少なくとも一つの他の交換機とネットワークを介して接続され、
   前記他の交換機が収容する電話機と、前記電話機に対応する携帯端末との対応関係を示す変換情報、及び、前記電話機と通信する通信端末の電話番号と、前記電話番号に対応する情報とを含む電話帳データを、前記メモリに保持し、
   前記他の交換機が通信不可状態になった後、前記電話機を呼び出すため前記他の交換機に送信された信号を、前記ネットワークインタフェースを介して受け付けた場合、前記変換情報に基づいて、前記電話機に対応する前記携帯端末に呼出し信号を送信し、
   前記携帯端末から前記電話帳データの要求を受け付けた場合、前記要求を送信した携帯端末に対応する前記電話機が保持する電話帳データを、前記メモリに格納される電話帳データから抽出し、前記抽出した電話帳データを、前記携帯端末に送信し、
   前記抽出した電話帳データに含まれる電話番号の要求を、前記携帯端末から受け付けることを特徴とする交換機。
2. 請求項１に記載の交換機であって、
   前記受け付けた信号と前記電話帳データとに基づいて、前記受け付けた信号を送信した通信端末の電話番号に対応する情報を抽出し、
   前記抽出した通信端末の電話番号に対応する情報を、前記携帯端末に通知することを特徴とする交換機。
3. 請求項１に記載の交換機であって、
   前記他の交換機が通信できるか否かを判定するため、前記他の交換機から稼働状況を取得し、
   前記稼働状況を取得する際に、前記電話機が保持する電話帳データを、前記他の交換機を介して取得し、
   前記取得した電話帳データによって、前記メモリに格納される電話帳データを更新することを特徴とする交換機。
4. 請求項１に記載の交換機であって、
   前記他の交換機が通信できるか否かを判定し、
   前記他の交換機が通信不可状態であることを判定した場合、前記携帯端末に、前記他の交換機が通信不可であることを通知することを特徴とする交換機。
5. 請求項１に記載の交換機であって、
   前記他の交換機が通信できるか否かを判定し、
   前記他の交換機が通信不可状態であることを判定した場合、前記交換機から送信される信号を受信するためのアプリケーションプログラムを起動するように、前記携帯端末に指示することを特徴とする交換機。
6. 携帯端末であって、
   プロセッサ、メモリ、ディスプレイ、通信インタフェース及び入力インタフェースを備え、
   前記携帯端末に対応する電話機を収容する第１の交換機が通信不可状態である場合に前記電話機に向けた信号を受け付ける第２の交換機と、前記通信インタフェースを介して通信し、
   前記受け付けた信号を送信した通信端末の電話番号に対応する情報と、前記受け付けた信号に基づく呼出し信号とを前記第２の交換機から送信された場合、前記受け付けた信号を送信した通信端末の電話番号に対応する情報を、前記第１の交換機が通信不可状態である間の着信情報として、前記ディスプレイに表示し、
   前記呼出し信号へ応答するか否かを、前記入力インタフェースを介して受け付けることを特徴とする携帯端末。
7. 請求項６に記載の携帯端末であって、
   前記電話機が保持する電話帳データの読出し要求を、前記入力インタフェースを介して受け付け、
   前記読出し要求を受け付けた場合、前記第２の交換機へ、前記電話帳データを要求し、
   前記要求に従って前記第２の交換機から送信された電話帳データを、前記ディスプレイに表示することを特徴とする携帯端末。
8. 請求項６に記載の携帯端末であって、
   前記通信インタフェースを介して受信した情報が、前記第２の交換機から送信された情報であるか否かを判定し、
   前記通信インタフェースを介して受信した情報を、前記第２の交換機から送信された情報であるか否かを判別可能に、表示することを特徴とする携帯端末。
9. 請求項６に記載の携帯端末であって、
   前記メモリは、前記第２の交換機から送信される信号を受信するためのアプリケーションプログラムを保持し、
   前記第２の交換機からの指示に従って、前記アプリケーションプログラムを起動し、
   前記アプリケーションプログラムを用いて、前記受け付けた信号を送信した通信端末の電話番号に対応する情報を、前記第１の交換機が通信不可状態である間の着信情報として表示し、かつ、前記呼出し信号へ応答するか否かを前記入力インタフェースを介して受け付けることを特徴とする携帯端末。

Images