以下、実施例を図面を用いて説明する。PBXで内線交換や各種PBX機能サービスを1重化で運用しているシステムにおいて、PBXの障害又は故障発生時等の通信不可状態において、冗長化しバックアップするシステムに関する。
図1は、実施例1の通信システムの構成を示す説明図である。
実施例1の通信システムは、PSTN端末10、PSTN21、PSTN22、データ通信網30、モバイルキャリア網40、複数の拠点55(55−1、55−2)、複数の携帯情報端末70(70−1、70−2)、及びクラウドPBX80を含む。また、拠点55−1は、PBX50−1及び内線端末60−1を含み、拠点55−2は、PBX50−2及び内線端末60−2を含む。
PSTN端末10は、PSTN21に接続し、PSTN21に接続される他端末との間で音声通話を行うアナログ電話機等のPSTN(Public Switched Telephone Network:公衆電話網)端末である。PSTN21及びPSTN22は、PSTN端末を収容し、PSTN相互間の呼制御及び相互内線通話等の各種電話サービスを提供するPSTNである。
さらに、PSTN21に接続されるPBX50が故障した際、PBX50への着信には、応答がされない。このため、実施例1のPSTN21は、一般的なPSTNにおいて提供される無応答転送サービスを提供し、PBX50が故障時に、PBX50への着信をクラウドPBXへ転送する。
また、PSTN22は、収容するPSTN端末(図示なし)と、モバイルキャリア網40の収容する携帯情報端末70との間の音声通信を可能とする網変換の機能を有する。
データ通信網30は、データ通信端末を収容し、データ通信端末相互間のデータ通信を提供するデータ通信網である。ここで、データ通信端末とは、PBX50及びクラウドPBX80である。
データ通信網30は、例えば、IP(Internet Protocol)プロトコルを用いてデータ通信を行うIPネットワークである。本実施例のデータ通信網30は、クラウドPBX80が行うPBXのヘルスチェックを行うためのヘルスチェック情報とその応答情報のデータとを伝送する。
モバイルキャリア網40は、携帯情報端末70を収容し、携帯情報端末70相互間の呼制御及び相互通話、並びに、携帯情報端末70間のメール送受信等の、電話・データ通信サービスを無線により提供するモバイルキャリア網である。
拠点55は、例えば、企業ビル又は官公庁庁舎などであり、PSTN21による通信サービスを提供される拠点である。図1に示す拠点55は、拠点55−1及び拠点55−2の二つであるが、三つ以上の複数の拠点55が実施例1の通信システムに含まれてもよい。
PBX50は、拠点55に設置され、内線端末60及びPSTN21回線を収容し、内線相互通話及び外線−内線通話等の各種構内交換機機能サービスを提供するPBX50である。図1に示す拠点55は、各々1台のPBX50を有するが、複数のPBX50を有してもよい。
なお、以下の実施例1及び実施例2において、主に、PBX50が障害又は故障により通信不可となった場合の処理について説明するが、PBX50が障害又は故障以外のいかなる理由において通信不可となる場合も、実施例1及び実施例2の処理が実行されてもよい。例えば、定期的なメンテナンス期間中に、明示的にPBX50が通信不可とされている場合にも、実施例1及び実施例2が適用されてよい。
内線端末60は、拠点55に設置される構内電話である。内線端末60−1は、PBX50−1と接続し、内線端末60−2は、PBX50−2と接続される。内線端末60は、PBX50に接続される他の内線端末60との音声通話、及び、PSTN21を介してPSTN端末10との音声通話を行うデジタル多機能電話機等である。
携帯情報端末70は、モバイルキャリア網40に収容され、モバイルキャリア網40に接続されている他の携帯情報端末70との間で音声通話及びメール伝送等のデータ通信を行う。
携帯情報端末70−1を携帯する使用者と、内線端末60−1が割り当てられた使用者とは同じである。携帯情報端末70−1は、PBX50−1が障害又は故障等の通信不可状態の場合、PSTN端末10から内線端末60−1への着信を、PSTN21を迂回して受け付ける。
携帯情報端末70−2を携帯する使用者と、内線端末60−2が割り当てられた使用者とは同じである。携帯情報端末70−2は、PBX50−2が障害又は故障の場合、PSTN端末10から内線端末60−2への着信を、PSTN21を迂回して受け付ける。
クラウドPBX80は、プロセッサ、メモリ及びネットワークインタフェースを有する少なくとも一つの計算機である。クラウドPBX80は、PBX50と同じく、通話を転送する機能を有する。
クラウドPBX80は、各拠点55に設置されるPBX50へヘルスチェック情報を送信しその応答の有無で、PBX50が障害又は故障であるかどうかのチェックを行う。PBX50が障害又は故障である場合に、クラウドPBX80は、PBX50を介して内線端末60に向けた着信を、受け付ける。
そして、クラウドPBX80は、PBX50に向けて発信したPSTN端末10から着信先の内線番号情報を取得する。そして、予め設定される番号変換情報92によって、取得した内線番号の内線端末60に対応した携帯情報端末70へ発信を行うことで、PSTN21から障害又は故障したPBX50への着信を、モバイルキャリア網40を迂回して携帯情報端末70に着信させることができる。
図2は、実施例1のクラウドPBX80の物理的な構成を示すブロック図である。
クラウドPBX80は、呼制御部81、番号変換情報用メモリ82、音声交換部83、データIF部84、電話回線IF部85及び電話帳バックアップ用メモリ86を有する。
呼制御部81は、例えば、CPU(中央演算処理装置)等のプロセッサ87、並びに、プログラム及びデータを保持するメモリ88を有する。
番号変換情報用メモリ82は、バックアップの対象PBX50と、そのPBX50が障害又は故障状態である際にそのPBX50へ着信した呼が転送される際に、クラウドPBX80に通知される着信電話番号、そのPBX50の内線番号、及び、その内線番号の内線端末60に割り当てられた利用者が利用する携帯情報端末70の携帯電話番号が、各々対応づけた番号変換情報92を保持するメモリである。
音声交換部83は、呼制御部81からの指示のもとに各回線IF部間の音声情報の交換を行う。
データIF部84は、データ通信網30とのインタフェースであり、呼制御部81とPBX50間のヘルスチェック情報の送受信を行う。
電話回線IF部85は、PSTN21及びPSTN22とのインタフェースであり、呼制御部81とPSTN間の呼制御情報の送受信、及び音声交換部83とPSTN21及びPSTN22間の音声情報の送受信を行う。
電話帳バックアップ用メモリ86は、各拠点のPBX50が保持する電話帳データをバックアップするメモリである。電話帳バックアップ用メモリ86は、後述する実施例2において用いられる。このため、実施例1のみを実行する場合、クラウドPBX80は電話帳バックアップ用メモリ86を有する必要はない。
図3は、実施例1のクラウドPBX80の機能部を示すブロック図である。
呼制御部81のメモリは、呼制御機能部91、PBX故障監視機能部93、データIF制御機能部94、及び、電話回線IF制御機能部95を実行するためのプログラムを保持する。
呼制御機能部91は、電話回線IF部85を介してPSTN21及びPSTN22と呼制御情報を送受信し、番号変換情報92に従った呼制御を行う。
また、呼制御機能部91は、番号変換情報用メモリ82を介して、各内線番号と対応づけされた電話帳情報の送受信を行う。また、その呼制御情報を元に、音声交換部83へ各電話回線IF部85間の音声交換を指示する。
さらに、呼制御機能部91は、PBX故障監視機能部93から送信されたPBX50への故障監視結果が、PBX50が故障していることを示し、かつ、電話回線IF制御機能部95から着信情報が有った場合に、内線番号の入力を要求するガイダンスを、PBX50を介してPSTN端末10に送信する。
そして、呼制御機能部91は、内線番号をPSTN端末10から取得した後に、その内線番号を番号変換情報92に照らし合わせ、対応する携帯情報端末70への発信、及び各内線番号と対応づけされた電話帳情報の送受信を行う。
番号変換情報92は、バックアップの対象であるPBX50と、PBX50が障害又は故障状態であるためにPBX50から転送されてくる呼の着信電話番号(すなわち、PBX50の電話番号)と、PBX50に接続される内線端末60の内線番号と、内線端末60が割り当てられた利用者が携帯する携帯情報端末70の携帯電話番号とが、各々対応づけた情報である。
PBX故障監視機能部93は、データIF制御機能部94を介して、PBX50とヘルスチェック情報の送受信を行い、PBX50が故障しているか否かを監視し、その結果を呼制御機能部91へ伝える。
データIF制御機能部94は、データIF部84を制御し、PBX故障監視機能とPBX間のヘルスチェック情報の伝達を行う。
電話回線IF制御機能部95は、電話回線IF部85を制御し、呼制御機能部91とPSTN21及びPSTN22間の呼制御情報の伝達、及び、音声交換部83とPSTN21及びPSTN22間の音声情報のパス開閉機能を行う。
電話帳バックアップ情報96は、各拠点のPBX50が保持する電話帳データのバックアップである。電話帳バックアップ情報96は、後述する実施例2において用いられる。このため、実施例1のみを実行する場合、クラウドPBX80は電話帳バックアップ情報96を有する必要はない。
図4は、実施例1の携帯情報端末70の物理的な構成を示すブロック図である。
携帯情報端末70は、アンテナ部71、通信インタフェース72、入出力部73、プロセッサ74及びメモリ75を有する。
アンテナ部71は、モバイルキャリア網40の基地局(不図示)と無線によって通信するためのアンテナである。通信IF72は、アンテナ部71を介して信号を送受信するためのインタフェースである。
入出力部73は、ディスプレイ及びスピーカー等の出力部、若しくは、ダイヤルキー及びマイク等の入力部を含む。また、入出力部73は、例えばタッチパネルであってもよい。
プロセッサ74は、例えばCPU等の演算装置である。メモリ75は、データ及びプログラムを保持する。プロセッサ74は、メモリ75を用いてプログラムを実行することによって、携帯情報端末70の機能を実現する。
携帯情報端末70のプロセッサ74は、プログラムによって実装されたアプリケーションを実行することによって機能を実装する。メモリ75は、情報登録アプリ76を有する。また、後述する実施例2において、メモリ75は、バックアップアプリ77を有する。
情報登録アプリ76は、利用者の指示に従い、クラウドPBX80の番号変換情報92に内線番号を登録する。バックアップアプリ77は、クラウドPBX80から送信された情報をディスプレイに表示する。実施例1におけるメモリ75は、バックアップアプリ77を有しなくてもよい。
図5は、実施例1の番号変換情報92を示す説明図である。
番号変換情報92は、項番920、対象PBX921、着信電話番号922、内線番号923、携帯電話番号924、及び、メールアドレス926を含む。項番920は、番号変換情報92のエントリを一意に示す番号である。
対象PBX921は、クラウドPBX80によるバックアップが行われるPBX50を示す。着信電話番号922は、対象PBX921が示すPBX50への着信がクラウドPBX80に転送される際、転送元として通知されるPBX50の電話番号を示す。
内線番号923は、対象PBX921のPBX50に接続される内線端末60の内線番号を示す。携帯電話番号924は、内線番号923の内線端末60に割り当てられた利用者が携帯する携帯情報端末70の携帯電話番号を示す。
メールアドレス926は、携帯電話番号924の携帯情報端末70のメールアドレスを示す。クラウドPBX80がヘルスチェックによりPBX50を障害又は故障と判断した際に、クラウドPBX80は携帯情報端末70にメールにて障害又は故障通知を行い、クラウドPBX80がヘルスチェックによりPBXの復旧と判断した際に、クラウドPBX80は携帯情報端末70にメールにて復旧通知を行う。
番号変換情報92の、項番920、対象PBX921、着信電話番号922、内線番号923、携帯電話番号924及びメールアドレス926は、保守者等によってあらかじめ設定されてもよい。また、内線番号923と携帯電話番号924とメールアドレス926とは、後述の処理によって、携帯情報端末70の利用者によって設定されてもよい。
図6は、実施例1のPBX50のバックアップ処理の開始時を示すシーケンス図である。
クラウドPBX80のPBX故障監視機能部93は、PBX50−1へデータ通信網30を経由してヘルスチェック情報を、定期的又は保守者等の指示に従い送信し(S100)、PBX50−1はクラウドPBX80へそのヘルスチェック情報に対する応答を送信する(S101)。クラウドPBX80の呼制御機能部91は、その応答を受信した場合、PBX50−1が障害又は故障状態ではなく正常に稼働していると判断する。
しかし、クラウドPBX80のPBX故障監視機能部93がPBX50−1へヘルスチェック情報を送信したが(S103)、PBX50−1が障害又は故障状態である(S102)ことにより、そのヘルスチェック情報に対する応答が出来ない(S104)場合、クラウドPBX80のPBX故障監視機能部93は、ヘルスチェック情報に対する応答がないため、PBX50−1が障害又は故障であるであると判断する(S107)。
S107の後、呼制御機能部91は、PBX50−1をバックアップする処理を開始する(S108)。PBX50−1をバックアップする処理とは、後述のPBX50−1への着信を、携帯情報端末70へ転送する処理である。
なお、クラウドPBX80のPBX故障監視機能部93がヘルスチェックを行い、PBX50の障害又は故障と判断した場合にのみ、そのPBX50へのバックアップ処理を開始するのは、クラウドPBX80が最小限の呼制御リソースである一方で、多くのPBX50のバックアップを行うため、バックアップ処理に必要なコストを低減するためである。そのため、クラウドPBX80の呼制御リソースに制限が無い場合、PBX故障監視機能部93は、ヘルスチェックを実行しなくともよい。
また、実施例1におけるヘルスチェックの方法は、専用のデータ通信網30を用いたデータ通信によって行われる方法であるが、モバイルキャリア網40を用いたデータ通信を用いる方法でも良いし、ヘルスチェック情報を変復調した信号を、PSTN21を介して送受信する方法でも良い。
S108の後、クラウドPBX80の呼制御機能部91は、番号変換情報92を参照し、ヘルスチェックに応答がなかったPBX50−1(以降、バックアップ対象のPBX50−1)の内線端末60に対応するすべての携帯情報端末70に、障害又は故障通知するメールを送信する(S117)。
なお、メールにて、障害又は故障を通知するのは、PBX50−1への着信がPBX50−1を介さず、迂回して携帯情報端末70−1へ着信する状態であることを携帯情報端末70−1の利用者へ予め通知し認識してもらうためである。PBX50−1への着信が迂回して携帯情報端末70−1へ着信する状態であることを携帯情報端末70−1の利用者が認識する必要が無い場合、呼制御機能部91は、本障害又は故障通知を実行しなくともよい。
一方、PSTN端末10から発信し、PSTN21を介して、障害又は故障したPBX50−1に着信があると(S105)、PBX50−1は障害又は故障で有るためにその着信に対し着信応答動作をすることが出来ない(S106)。
このため、PSTN21は予めサービス契約してある無応答転送サービスにより、PSTN端末10からPBX50−1への着信呼をクラウドPBX80へ転送する(S109)。
なお、ここでPSTN21は、既存の無応答転送サービスを用いるとしたが、PSTN21が、応答ができないPBX50−1への着信をクラウドPBX80に転送する技術であれば、いかなる方法が用いられてもよい。
例えば、データ通信網30に監視端末が設置され、この監視端末がPBX50−1の障害等を検知し、障害等が発生したPBX50への着信を転送する指示をPSTN21に出してもよい。そしてPSTN21は、指示に従い、PBX50−1への着信をクラウドPBX80に転送してもよい。
S108の後、クラウドPBX80の呼制御機能部91は、着信があった場合、その着信電話番号を予め設定されている番号変換情報92の着信電話番号922に照らし合わせ、着信が、番号変換情報92に登録される着信であるか否かを判定する。そして、番号変換情報92に登録される着信である場合、PBX50−1の障害又は故障によって着信されたと判断する。
呼制御機能部91は、PBX50−1の障害又は故障によって着信されたものと判断した場合にのみ応答を行い(S118)、PBX50−1が障害又は故障したため、クラウドPBX80がバックアップ装置として動作している旨の故障音声ガイダンスを、PSTN端末10に対し送出する(S119)。
なお、故障音声ガイダンスを送出するのは、PSTN端末10の発信者に対し、PBX50−1が障害又は故障し、クラウドPBX80がバックアップ装置として動作していることを認識させるためであり、PSTN端末10の発信者が、このような認識を持たなくてよい場合、クラウドPBX80は、故障音声ガイダンスを送出しなくともよい。
S119の後、クラウドPBX80の呼制御機能部91は、正常動作時のPBX50−1と同様に、PSTN端末10に対して、通話したい内線番号を要求する(S110)。そして、呼制御機能部91は、PSTN端末10から送信される内線番号を取得する(S111)。実施例1では、ダイレクトインラインの着信形態について記述しているが、ダイヤルインやダイレクトインダイヤルなどの他の着信形態時も同様である。
S111の後、クラウドPBX80の呼制御機能部91は、番号変換情報92を参照し、対象PBX921がバックアップ対象のPBX50を示し、内線番号923が取得した内線番号を示すエントリの携帯電話番号924を抽出する(S112)。
なお、呼制御機能部91は、PSTN21から転送された着信呼が、バックアップ対象のPBX50が通信不可であるために転送されたものであることを、着信呼が転送されてきた回線、又は、着信呼に付加される識別子等によって判別してもよい。
呼制御機能部91は、抽出した携帯電話番号924を用いて、モバイルキャリア網40を介して、携帯情報端末70−1へ着信を入れ呼び出しを行う(S113)。そして、呼制御機能部91は、PSTN端末10に呼出中音を送出する(S114)。
なお、クラウドPBX80が携帯情報端末70−1へ着信を入れるために使用するPSTN22におけるPSTN回線を予め決めておき、携帯情報端末70−1へそのPSTN回線の電話番号を電話帳登録しておく。これにより、携帯情報端末70−1は、障害又は故障したPBX50への着信が、クラウドPBX80を迂回してきた着信であるか、それ以外の通常の携帯情報端末70−1への着信かを応答前に判別できる。
S113の後、携帯情報端末70−1では、着信に対して応答を行い(S115)、PSTN端末10と携帯情報端末70−1との音声通信を実現する(S116)。
なお、上記においては、一つの内線番号への着信に対して、一つの携帯情報端末70−1へ着信を入れ呼び出しを行っている。しかし、呼制御機能部91は、一般的にPBX50で実現できるグループ呼び出しの着信形態と同様に、一つの内線番号に対して複数の携帯情報端末70を呼び出してもよい。具体的には、番号変換情報92が、一つの内線番号に対応した携帯電話番号を複数保持することにより、呼制御機能部91は、一つの内線番号への着信に対して、複数台の携帯情報端末70へ着信を入れ、呼び出しを行ってもよい。
図7は、実施例1のバックアップ開始時のクラウドPBX80の処理を示すフローチャートである。
まず初めに、クラウドPBX80のPBX故障監視機能部93は、PBX50−1に対してヘルスチェック情報の送信を行う(S200)。S200は、図6に示すS100及びS103に相当する。
S200の後、PBX故障監視機能部93は、PBX50−1からのヘルスチェック情報に対する応答を、所定の時間経過するまでに検出するか否かを判定する(S201)。所定の時間待ち、ヘルスチェック情報に対する応答を検出した場合(図6に示すS101に対応)、PBX故障監視機能部93は、PBX50が正常稼働していると判断し、S200に戻る。そして、PBX故障監視機能部93は、定期的にS200のヘルスチェック情報を送信し、その応答を検出する。
一方、所定の時間が経過しても、ヘルスチェック情報に対する応答を検出できない場合(図6に示すS104に対応)、PBX故障監視機能部93は、呼制御機能部91に応答が検出されないことを通知する。そして、呼制御機能部91は、PBX故障監視機能部93から応答が検出されないことを通知された場合、PBX50−1が障害又は故障であると判断し(図6に示すS107に対応)、PBX50−1へのバックアップを開始する(S202:図6に示すS108に対応)。
そして、呼制御機能部91は、番号変換情報92の対象PBX921、及びメールアドレス926に基づいて、バックアップ対象のPBX50−1に対応するすべての携帯情報端末70に対し、障害又は故障を通知するメールを送信する(S203)。
S203の後、呼制御機能部91は、PSTN21からの着信を検出するか否かを判定し(S204)、着信が検出されない場合、S204に戻り、継続して着信するかを監視する。着信が検出された場合、その着信の着信電話番号を番号変換情報92に照らし合わせ、障害又は故障したPBX50−1に対応した着信電話番号であるか否かを判定する(S205)。
障害又は故障したPBX50−1に対応した着信電話番号である場合呼制御機能部91は、次のステップ(S206)へ移行するが、一方、障害又は故障したPBX50−1に対応した着信電話番号でない場合、S204に戻り、継続的に着信の監視を行う。
クラウドPBX80の呼制御機能部91は、着信が、障害又は故障したPBX50−1に対応した着信電話番号であった場合、その着信に対し応答を行い(図6に示すS118に対応)、PBX50−1が障害又は故障し、クラウドPBX80がバックアップ装置として動作している旨の故障音声ガイダンスを、PSTN端末10に対し送出する(S214:図6に示すS119に対応)。
S214の後、呼制御機能部91は、PSTN端末10に対し、通話したい内線番号を要求し(S206:図6に示すS110に対応)、内線番号を取得する(S207:図6に示すS111に対応)。この内線番号を要求する方法は、音声ガイダンス又は特殊トーン等を送出する方法を用いてもよい。
S207の後、呼制御機能部91は、番号変換情報92を参照し、取得した内線番号が、バックアップ対象のPBX50−1を示すエントリの内線番号923に含まれるか否かを判定する(S208)。バックアップ対象のPBX50−1を示すエントリの内線番号923に含まれない場合、呼制御機能部91は、S204に戻り、継続的に着信検出監視を行う。
一方、バックアップ対象のPBX50−1を示すエントリの内線番号923に含まれる場合、呼制御機能部91は、取得した内線番号に対応した携帯電話番号を番号変換情報92の携帯電話番号924から抽出し(図6に示すS112に対応)、抽出した携帯電話番号へ発信する。これによって、呼制御機能部91は、携帯情報端末70−1を呼び出す(S209:図6に示すS113に対応)。
S209の後、呼制御機能部91は、携帯情報端末70−1からの応答の検出監視を開始する(S210)。所定の時間応答が検出されない場合、呼制御機能部91は、S210に戻り、継続して応答の検出監視を行う。一方、応答を検出した場合、呼制御機能部91は、PSTN端末10と携帯情報端末70−1とを通話させるための相互通信処理を行う(S211:図6に示すS116に対応)。
S211の後、呼制御機能部91は、PSTN端末10又は携帯情報端末70−1の切断を検出するか否か判定する(S212)。切断が検出されない場合、呼制御機能部91は、S212に戻り、継続して切断検出監視を行う。一方、PSTN端末10及び携帯情報端末70−1のいずれかの切断を検出した場合、呼制御機能部91は、PSTN端末10と携帯情報端末70−1との通話を切断するための切断処理を行い(S213)、S204へリターンする。
図8は、実施例1のバックアップ終了時の処理を示すシーケンス図である。
図8は、図6に示す処理の後の処理を示す。図8に示すシーケンスの開始時において、バックアップ中のクラウドPBX80が呼処理することによって、PSTN端末10と携帯情報端末70−1とは通話中である(S300)。一方で、クラウドPBX80のPBX故障監視機能部93は、S104の後もヘルスチェックを継続する。
PBX50−1が障害又は故障状態から正常状態に復旧した場合、クラウドPBX80のPBX故障監視機能部93は、PBX50−1に対して継続していたヘルスチェック情報(S301)に対する応答を受信する(S302)。これにより、呼制御機能部91は、PBX50−1が復旧したと判断し(S303)、番号変換情報92を参照し、PBX50−1の内線電話に対応するすべての携帯情報端末70に、復旧を通知するメールを送信する(S304)。
なお、メールにて、復旧を通知するのは、PBX50−1への着信が迂回して携帯情報端末70−1へ着信する状態でなくなったことを携帯情報端末70−1の利用者へ通知し認識してもらうためである。このため、利用者がこのような認識を有する必要が無い場合、呼制御機能部91は、S304を実行しなくともよい。
しかし、クラウドPBX80の呼制御機能部91は、S303においてPBX50−1が復旧したと判断した段階で、即時バックアップを終了させず、S300の通話呼を継続させる(S305)。これは、PSTN端末10又は携帯情報端末70による切断以外の要因で、通信を切断するべきではないためである。
S305の後、クラウドPBX80の呼制御機能部91は、S305の通話呼の切断監視を開始する(S306)。PSTN端末10及び携帯情報端末70−1のいずれか一方が切断し(S307)、その切断信号(S308)を検出した場合、もう一方に切断を促す終話音を送出する(S309)。そして、もう一方も切断した後(S310)、呼制御機能部91は、もう一方の切断信号(S311)を検出すると通話呼を終了させる。
この切断監視、及び、切断処理は、図7に示すS212及びS213においても実行される。
最後に、クラウドPBX80の呼制御機能部91は、バックアップ中のクラウドPBX80により呼処理された通話呼すべての終了を確認し、バックアップ処理を終了する。
図9は、実施例1のバックアップ終了時のクラウドPBX80の処理を示すフローチャートである。
バックアップ中のクラウドPBX80のPBX故障監視機能部93は、PBX50−1に対して継続的にヘルスチェック情報を送信し(S400)、PBX50−1からヘルスチェック情報に対する応答の監視を行う。具体的には、PBX50−1から送信されるヘルスチェック情報への応答を検出したか否かを判定する(S401)。PBX50−1からヘルスチェック情報に対する応答が無い場合、PBX故障監視機能部93は、S400に戻り、ヘルスチェック情報の送信を継続する。
PBX50−1からヘルスチェック情報に対する応答があった場合、呼制御機能部91は、PBX50−1が復旧したと判断する(S402)。そして、呼制御機能部91は、番号変換情報92を参照し、バックアップ対象のPBX50−1に対応するすべての携帯電話番号924を抽出し、抽出した携帯電話番号924を用いて携帯情報端末70に対して復旧を通知するメールを送信する(S403)。
S403の後、クラウドPBX80の呼制御機能部91は、バックアップ中のクラウドPBX80により呼処理された通話呼があるか否かを判定する(S404)。通話呼が無い場合、呼制御機能部91は、即時バックアップを終了する(S407)。一方で、通話呼が有る場合、呼制御機能部91は、その通話呼の切断検出監視を開始し、切断を検出したか否かを判定する(S405)。切断が検出されない場合、呼制御機能部91は、S405に戻り、継続して切断検出監視を行う。
一方、PSTN端末10及び携帯情報端末70−1のいずれかによる切断を検出した場合、呼制御機能部91は、PSTN端末10と携帯情報端末70−1との通話を切断するための切断処理を行う(S406)。呼制御機能部91は、バックアップ中のクラウドPBX80により呼処理された通話呼すべての終了を確認した後、バックアップを終了する(S407)。
図10は、実施例1の携帯情報端末70−1の利用者が携帯情報端末70−1を用いて、番号変換情報92の登録を行う処理を示すシーケンス図である。
本登録処理の前提条件として、保守者等は、クラウドPBX80のパックアップ対象であるPBX50毎に一意な、情報登録用PSTN回線と暗証番号とをあらかじめ定め、クラウドPBX80に登録する。また、携帯情報端末70の利用者は、情報登録用PSTN回線に発信するための電話番号と、自らに割り当てられた内線端末60が接続されるPBX50の電話番号と、暗証番号とを保持する。これにより、クラウドPBX80の呼制御機能部91は、携帯情報端末70の利用者による番号変換情報92の更新を許可することができる。
まず初めに、携帯情報端末70−1の利用者(以下、利用者)は、情報登録アプリ76を起動する。情報登録アプリ76は、起動した場合、クラウドPBX80へ携帯情報端末70−1の電話番号を通知する発信者番号通知機能を有効に設定する(S500)。次に、情報登録アプリ76は、自らの携帯情報端末70−1に割り当てられた内線端末60−1が接続するPBX50−1に定められた一意の情報登録用PSTN回線に対して発信を行う(S501)。
S501における発信には、利用者に割り当てられた内線端末60が接続するPBX50の識別子又は着信電話番号と、発信元の電話番号(すなわち携帯情報端末70−1の電話番号)とが、情報として含まれる。
クラウドPBX80の呼制御機能部91は、情報登録用PSTN回線を介して着信があった場合、その着信に応答する(S502)。呼制御機能部91は、携帯情報端末70−1に対し、暗証番号の送信を促す暗証番号音声ガイダンスを送出する(S503)。
S503の後、携帯情報端末70−1の情報登録アプリ76は、暗証番号音声ガイダンスを、例えばスピーカーから出力する。そして、利用者が携帯情報端末70−1のダイヤルボタンを押下することによって、情報登録アプリ76は暗証番号を取得する。そして、情報登録アプリ76は、取得した暗証番号をクラウドPBX80に送信する(S504)。
クラウドPBX80の呼制御機能部91は、受信した暗証番号と、情報登録用PSTN回線に対応してあらかじめ定められている暗証番号とを比較する(S505)。比較の結果、両者が不一致であった場合、呼制御機能部91は、携帯情報端末70−1との通信を切断し(S510)、登録動作を終了する。
一方、比較の結果、両者の暗証番号が一致した場合、呼制御機能部91は、携帯情報端末70−1に対し、内線番号の送信を促す内線番号音声ガイダンスを送出する(S506)。なお、S503〜S505の一連の暗証番号認証を行うのは、番号変換情報92の更新において、高度なセキュリティを確保するためである。このため、番号変換情報92の更新に、高度なセキュリティを確保する必要が無い場合は、S503〜S505の一連の暗証番号認証が実行されなくてもよい。
S506の後、携帯情報端末70−1の情報登録アプリ76は、内線番号音声ガイダンスを、例えばスピーカー等から出力する。携帯情報端末70−1の利用者は、携帯情報端末70−1のダイヤルボタンを押下し、携帯情報端末70−1と対応づける内線端末60−1の内線番号を、入力する。そして、情報登録アプリ76は、入力された内線番号をクラウドPBX80に送信する(S507)。
クラウドPBX80の呼制御機能部91は、S507までの処理において取得した情報が対応するように、番号変換情報92に登録する(S508)。
具体的には、S508におけるクラウドPBX80の呼制御機能部91は、S501が着信した情報登録用PSTN回線に割り当てられたPBX50を示す識別子又は電話番号を、対象PBX921又は着信電話番号922に格納する。また、S507において受信した内線番号を、内線番号923に格納する。また、S501の着信時に受信した発信元の電話番号を、携帯電話番号924に格納する。
その後、クラウドPBX80の呼制御機能部91は、登録成功音声ガイダンスを、携帯情報端末70−1に送出し(S509)、情報登録回線を切断し(S510)、登録処理を終了する。
S509の後、携帯情報端末70−1の情報登録アプリ76は、受信した登録成功音声ガイダンスを出力する。また、情報登録アプリ76は、必要に応じて、発信者番号通知機能を無効に設定する。
クラウドPBX80内の番号変換情報92は、上記以外に、保守者等がクラウドPBX80に対して、直接シリアル伝送もしくはIPパケット通信を利用して登録する方法によって更新されてもよい。また、保守者又はPBX50の利用者が、電話機操作、シリアル伝送、又は、IPパケット通信を利用して、PBX50−1に番号変換情報92を登録し、PBX50−1が、データ通信網30等のライフチェック経路を利用して、クラウドPBX80へ番号変換情報92を登録してもよい。
なお、上記実施例の方法及び代替方法は、内線端末60の内線番号と携帯情報端末70−1の携帯電話番号とを対応づけした情報の登録方法を記載したが、内線端末60の内線番号と携帯情報端末70−1のメールアドレスを対応づけた情報の登録方法も同様の方法で実行可能である。
図11は、実施例1の携帯情報端末70に送信される故障通知711を示す説明図である。
図11は、クラウドPBX80がヘルスチェックによりPBX50を障害又は故障と判断した際に、S118においてクラウドPBX80が携帯情報端末70−1に送信する障害又は故障通知711の表示内容の一例である。S304において送信された復旧通知も、図11に示す形式と同様の形式である。
故障通知711には、PBX50において障害等が発生したこと、障害等が発生した時刻、及び、バックアップ処理が開始したことを示す内容が含まれる。携帯情報端末70のバックアップアプリ77は、ディスプレイに故障通知711を表示する。
図12は、実施例1のクラウドPBX80がバックアップ中に、携帯情報端末70−1からの発信された際の処理を示すシーケンス図である。
図12に示す処理は、携帯情報端末70−1からPBX50−1の外線電話(PSTN21に接続する電話端末)であるPSTN端末10へ発信する処理である。図12に示す処理は、図6に示すS117の後に実行される。
なお、本発信処理の前提条件として、保守者は、PBX50毎に一意なバックアップ発信用PSTN回線を、クラウドPBX80及び携帯情報端末70間に登録しておき、そのバックアップ発信用PSTN回線に、一般的なPSTNがサービスを行っている着信課金サービスを利用する契約を行い、着信課金電話番号を付与しておく。
まず初めに、PBX50−1が障害又は故障状態であると認識している携帯情報端末70−1の利用者は、着信課金電話番号へ発信を行う。そして、携帯情報端末70−1から、バックアップ発信用PSTN回線を介して着信を受けた場合、PSTN22は、着信課金サービスを利用し、着信課金電話番号に対応付けしたクラウドPBX80宛てのバックアップ発信用PSTN回線に発信を行う(S600)。
バックアップ発信用PSTN回線を介して着信を受けた場合、クラウドPBX80は、応答を行い(S601)、電話番号の送信を促す発信要求音声ガイダンスを、携帯情報端末70−1に送出する(S602)。S602の後、携帯情報端末70−1は、例えば"0"発信に代表される外線発信を識別するダイヤル(外線発信識別ダイヤル)を送信する(S603)。
S603の後、携帯情報端末70−1は、PSTN端末10の電話番号ダイヤルを、バックアップ発信用PSTN回線を介して送信する(S604)。S604の後、クラウドPBX80の呼制御機能部91は、携帯情報端末70−1から受信したPSTN端末10の電話番号ダイヤルを元に、PSTN21を介して、PSTN端末10へ着信を入れる(S605)。そして、クラウドPBX80の呼制御機能部91は、携帯情報端末70−1に対して呼出し中音を送出する(S606)。
S605の後、PSTN端末10は、着信に対して応答を行い(S607)、PSTN端末10と携帯情報端末70−1との音声通信が行われる(S608)。
上記の通り、着信課金サービスを利用することにより、携帯情報端末70−1の発信でも、携帯情報端末70−1には課金されず、クラウドPBX80に課金されるため、携帯情報端末70−1をPBX50−1の内線端末60−2を利用する場合と同様に無課金で使用することが可能である。
なお、上記は、携帯情報端末70−1からPBX50−1の外線電話(PSTN21に接続する電話端末)であるPSTN端末10へ発信する場合を記載したが、携帯情報端末70−1からPBX50−1の内線端末60への発信も同様に実現可能である。具体的には、クラウドPBX80が、S601の応答を実行し、携帯情報端末70−1から内線電話ダイヤルを受信した後に、番号変換情報92を参照し、着信したバックアップ発信用PSTN回線と受信した内線電話ダイヤルから割り当てられた携帯情報端末70を識別し発信を行う。
実施例1によれば、PBX50とPSTN21を介して接続されるクラウドPBX80が、PBX50が障害又は故障時にPBX50のバックアップを行うことによって、拠点55に設置されたPBX50のバックアップを行うことができる。このため、拠点55にPBX50の冗長機能を設置する必要がなく、低コストによりPBX50のバックアップを実現することができる。
また、クラウドPBX80は、複数のPBX50のバックアップを行うことができるため、拠点55に設置されたPBX50の一つ一つに代替PBXを設置する必要がない。このため、低コストによりPBX50のバックアップを実現することができる。
実施例1は、PBX50停止による通話不可時間の最小化に焦点を置いており、故障前と同等の機能を補償していない。具体的には、実施例1の通信システムは、着信した際に相手の番号を表示するナンバーディスプレイ機能、発信時の電話帳の閲覧機能などを提供することが出来ない。このため、利用者が、PBX50の正常時と同様のサービスをPBX50の故障時に利用できないという課題がある。
図13は、実施例2の通信システムの構成を示す説明図である。
実施例2の通信システムは、実施例1の通信システムと同じく、PSTN端末10、PSTN21、PSTN22、データ通信網30、モバイルキャリア網40、複数の拠点55(55−1、55−2)、複数の携帯情報端末70(70−1、70−2)、及びクラウドPBX80を含む。
実施例2の拠点55−1は、実施例1と同じく、PBX50−1及び内線端末60−1を含み、実施例2の拠点55−2は、実施例1と同じく、PBX50−2及び内線端末60−2を含む。また、図13は、拠点55−1に含まれる内線端末60−3を示し、拠点55−2に含まれる内線端末60−4を示す。
実施例1と実施例2との相違点は、実施例2の通信システムが、情報端末90を有する点と、クラウドPBX80が電話帳バックアップ情報96とを用いる点である。
情報端末90は、モバイルキャリア網40に接続し、モバイルキャリア網40に接続されている他端末との間で音声通話を行う携帯端末である。
図14は、実施例2の番号変換情報92及び電話帳バックアップ情報96を示す説明図である。
実施例2の番号変換情報92は、実施例1の番号変換情報92の内容と、電話帳925とを含む。電話帳925は、電話帳バックアップ情報96のリンクを含む。電話帳バックアップ情報96は、内線番号923の内線端末60に登録される電話帳の内容を含む。
電話帳バックアップ情報96は、電話帳ID960、利用者名961、電話番号962及び内線番号963を含む。電話帳ID960は、電話帳データの識別子を示し、電話帳925に含まれる値に対応する。電話帳ID960は、対象PBX921及び内線番号923の組み合わせに対して一意の識別子を含む。
利用者名961は、PSTN端末10、携帯情報端末70及び情報端末90のいずれかの利用者の氏名又は名称等の情報を示す。電話番号962は、PSTN端末10又は携帯情報端末70に割り当てられた電話番号を示す。
内線番号963は、内線端末60の内線番号を示す。電話帳データを保持する内線端末60が、自らが設置される拠点55内の他の内線端末60の内線番号を保持する場合、内線番号963に他の内線端末60の内線番号が格納される。
クラウドPBX80は、各拠点55のPBX50が持つ内線端末60ごとの電話帳データを、ヘルスチェック時にバックアップする。具体的には、クラウドPBX80は、収集した電話帳データを、クラウドPBX80内の電話帳バックアップ情報96に格納する。そして、PBX50が障害又は故障時に携帯情報端末70−1のアプリ動作により、電話帳が呼び出された場合、クラウドPBX80は、携帯情報端末70−1の番号と対応した電話帳データを、携帯情報端末70−1に表示させる。
なお、電話帳バックアップ情報96は、前述の利用者名961及び電話番号962以外に、PSTN端末10、携帯情報端末70及び情報端末90の利用者に関するいかなる情報も含んでよい。例えば、利用者の所属、及び、住所などを含んでもよい。
図15は、実施例2のPBX50のバックアップ処理の開始時を示すシーケンス図である。
図15に示す処理は、図6に示す処理と同じく、PBX50−1が故障又は障害中に、PSTN端末10からPBX50−1に着信があった場合の処理を示す。図15に示す処理は、図6に示す処理の他に、携帯情報端末70−1がアプリケーションを起動する処理を含む。これによってナンバーディスプレイ機能が、携帯情報端末70−1に追加される。下記の説明では、図6の説明にて述べた箇所は省略する。
PBX50−1のバックアップを開始した後(S108)、呼制御機能部91は、携帯情報端末70−1に、バックアップアプリ77の起動の許可を送信する(S1100)。S1100の後、携帯情報端末70−1のバックアップアプリ77が起動する(S1101)。
S106の後、PSTN21は、実施例1におけるS109に加えて、発信者であるPSTN端末10の電話番号を含む着信呼を、クラウドPBX80に転送する(S1109)。
さらに、PSTN端末10より内線番号を取得した後(S111)、呼制御機能部91は、取得した内線番号が、バックアップ対象のPBX50−1を示すエントリの内線番号923に含まれるか否かを判定する。含む場合、呼制御機能部91は、取得した内線番号に対応する電話帳925の電話帳データを、番号変換情報92から抽出する。そして、呼制御機能部91は、抽出した電話帳データの電話番号962と、S1109において転送された着信呼に含まれる発信者番号とを照合させることによって、発信者の情報(利用者名961等)を検索する(S1102)。
S1102の後、呼制御機能部91は、番号変換情報92を参照し、対象PBX921がバックアップ対象のPBX50を示し、内線番号923がPSTN端末10から取得した内線番号を示すエントリの携帯電話番号924を抽出する(S112)。
S1102における検索の結果、抽出した電話帳データに発信者番号(本実施例ではPSTN端末10の電話番号)が登録されている場合、呼制御機能部91は、電話帳データに登録される利用者名961等の発信者情報を、携帯情報端末70−1のバックアップアプリ77に送信する。ここで、呼制御機能部91は、S112において抽出した携帯電話番号924に従って、携帯情報端末70−1に発信者情報を送信する。
また、S1102における検索の結果、抽出した電話帳データに発信者番号が登録されていない場合、呼制御機能部91は、発信者番号のみを発信者情報として携帯情報端末70−1のバックアップアプリ77に送信する(S1103)。S1103の後、呼制御機能部91は、抽出した携帯電話番号924を用いて、モバイルキャリア網40を介して、携帯情報端末70−1へ着信を入れ呼び出しを行う(S113)。
S1103の後、バックアップアプリ77は、発信者情報をディスプレイに表示する(S1104)。クラウドPBX80が発信者情報を携帯情報端末70に提供することにより、内線端末60に実現されていたものと同等のナンバーディスプレイ機能を、携帯情報端末70に提供することができる。
図16は、実施例2のバックアップ開始時のクラウドPBX80の処理を示すフローチャートである。
実施例2の通信システムは、携帯情報端末70がバックアップアプリ77を実行することによって、携帯情報端末70がナンバーディスプレイ機能を有する。下記の説明では、図7の説明にて述べた箇所は省略する。
S202の後、クラウドPBX80の呼制御機能部91は、携帯情報端末70−1にバックアップアプリ77の起動の許可を送信する(S1200)。S1200の後、S203が実行される。
S204において着信が検出された場合、呼制御機能部91は、バックアップアプリ77からの着信であるか否かを判定する(S1201)。呼制御機能部91は、着信した携帯電話番号が番号変換情報92の携帯電話番号924に登録されている場合、着信がバックアップアプリ77からであると判定する。
S1201の処理は、例えば、携帯情報端末70−1の利用者が、内線端末60−3を割り当てられた利用者と通話することを目的に、携帯情報端末70−1のバックアップアプリ77から、内線端末60−3宛ての発信をクラウドPBX80に送信した場合に実行される。このため、バックアップアプリ77からの着信には、携帯情報端末70が属するPBX50と通話したい内線番号とを示す情報が含まれる。
バックアップアプリ77からの着信の場合、呼制御機能部91は、故障ガイダンスの携帯情報端末70への送出(S214に相当)、及び、内線番号の携帯情報端末70への要求(S206に相当)を省略し、S207を実行する。S207において、呼制御機能部91は、着信又は送信された情報から内線番号を取得する。
呼制御機能部91は、取得した内線番号が、バックアップ対象のPBX50−1を示すエントリの内線番号923に含まれるか否かを判定する(S208)。取得した内線番号がバックアップ対象のPBX50−1を示すエントリに含まれない場合、呼制御機能部91は、S204に戻り着信を待つ。
取得した内線番号がバックアップ対象のPBX50−1を示すエントリに含まれる場合、呼制御機能部91は、取得した内線番号と対応した電話帳データを電話帳925から抽出する。そして、呼制御機能部91は、抽出した電話帳データの利用者名961の番号を検索する(S1202:図15に示すS1102に対応)。
呼制御機能部91は、抽出した電話帳データに発信者(携帯情報端末70−1又はPSTN端末10)の番号が登録されているか否かを判定し(S1203)、登録されている場合、登録されている利用者名961などの発信者情報を、着信先の携帯情報端末70のバックアップアプリ77に送信する(S1204)。
また、呼制御機能部91は、電話帳に発信者の番号が登録されていない場合、内線番号に対応する携帯電話番号のみを、着信先の携帯情報端末70のバックアップアプリ77に送信する(S1205)。S1204及びS1205は、図15に示すS1103に対応する。S1205の後、呼制御機能部91は、S209を実行する。
これによって、携帯情報端末70を利用する者は、PBX50が故障時にも、内線番号によって他の携帯情報端末70に発信することができる。
次に、実施例2のバックアップ終了時の処理のシーケンスを説明する。実施例2のバックアップ終了時のシーケンスは、実施例1における図8のシーケンスと同様であるが、以下に相違点を記載する。
実施例2のクラウドPBX80の呼制御機能部91は、クラウドPBX80がPBX50−1の復旧を確認し(S303)、PSTN端末10又は携帯情報端末70−1の一方が切断し(S307)、その切断信号を検出した後(S308)、バックアップ対象のPBX50に対応する携帯情報端末70すべてにアプリ終了命令を送信する。
そして、アプリ終了命令を受けた携帯情報端末70−1は、アプリの起動許可を受信するまでアプリの停止を行う。
さらに、実施例2のバックアップ終了時のクラウドPBX80の処理のフローチャートの相違点を以下に示す。実施例2のバックアップ終了時のフローチャートは、実施例1における図9のフローチャートと同様であるが、以下に相違点を記載する。
クラウドPBX80の呼制御機能部91は、S404において、バックアップ動作中のクラウドPBX80により呼処理された通話呼の有無の監視を開始した後、通話呼が無いと判定された場合、又は、通話呼の切断検出を確認し(S405)、切断処理を行った(S406)後、アプリ終了命令をすべての携帯情報端末70に送信する。
そして、バックアップ対象のPBX50に対応するすべての携帯情報端末70に、アプリ終了命令を送信した後、呼制御機能部91は、S407を実行する。
図17は、実施例2の携帯情報端末70から他の携帯情報端末70を呼び出す処理を示すシーケンス図である。
図17に示す処理は、PBX50−1が故障又は障害中であり、携帯情報端末70−1が携帯情報端末70−3を呼び出す際の処理を示す。このため、図17に示すS100〜S104、S107、S108、S1100、S117及びS1101は、図15に示すS100〜S104、S107、S108、S1100、S117及びS1101と同じである。
携帯情報端末70−1のバックアップアプリ77が起動した後、携帯情報端末70−1の利用者は、バックアップアプリ77が提供する電話帳モード、又は、番号入力モードを選択する。図17に示す処理において利用者は、電話帳モードを起動する(S1500)。
電話帳モードが起動された場合、バックアップアプリ77は、クラウドPBX80に携帯情報端末70−1に対応する内線端末60の電話帳を呼び出すように指示する(S1501)。S1501における指示には、携帯情報端末70−1の電話番号、又は、携帯情報端末70−1に対応する内線端末60及びPBX50−1を示す情報が含まれる。
呼出を指示された場合、呼制御機能部91は、番号変換情報92と呼出しに含まれる番号とを照合することによって、携帯情報端末70−1に対応する電話帳データを抽出する(S1502)。電話帳データを抽出できた場合、呼制御機能部91は、対応する電話帳データを携帯情報端末70−1に送信する(S1503)。
携帯情報端末70−1のバックアップアプリ77は、送信された電話帳データを表示する(S1906)。利用者は、表示された電話帳データから発信先を選択する(S1504)。図17に示す例において、利用者は、内線端末60−3の内線番号(内線番号963)を発信先として選択する。
S1501〜S1503及びS1906により、クラウドPBX80から携帯情報端末70に電話帳データが送信される。これによって、携帯情報端末70に、内線端末60と同等の電話帳の閲覧機能を提供することができる。
携帯情報端末70−1のバックアップアプリ77は、クラウドPBX80へ発信先の呼出を行う(S1505)。ここで、バックアップアプリ77は、S1504における選択に基づいて、発信先の内線端末60の内線番号を呼出しに含め、さらに、携帯情報端末70−1の携帯電話番号を発信者番号として呼出しに含める。また、S1505における呼出しには、携帯情報端末70−1が対応する内線端末60が接続するPBX50−1の識別子も含まれる。
S1505によって、呼制御機能部91は、発信先の内線番号を取得する。これは、図16に示すS207に相当する。
S1505の後、呼制御機能部91は、S1505の呼出しにより取得したPBX50の識別子が対象PBX921に含まれるエントリに、S1505の呼出しにより取得した内線番号を含む内線番号923のエントリが含まれるか否かを判定する(図16に示すS208に対応)。
含まれる場合、呼制御機能部91は、S1505の呼出しにより取得した内線番号及びPBX50の識別子に対応する電話帳925の電話帳データを、番号変換情報92から抽出する。ここで抽出される電話帳データは、携帯情報端末70−3が保持する電話帳データである。
そして、呼制御機能部91は、抽出した電話帳データの電話番号962と、S1505の呼出しに含まれる発信者番号とを照合させることによって、発信者情報(利用者名961等)を検索する(S1102)。ここで検索される発信者情報は、携帯情報端末70−1の情報である。
S1102の後、呼制御機能部91は、S112を実行し、内線番号から着信の宛先(携帯情報端末70−3)の携帯電話番号924を特定する。
S112の後、S1102において電話帳に発信者の内線番号(本実施例では内線端末60−1)が検索できた場合、呼制御機能部91は、登録されている名前などの発信者情報を携帯情報端末70−3のバックアップアプリ77に送信する。また、電話帳に発信者の番号が登録されていない場合、内線番号のみを発信者情報として、着信の宛先である携帯情報端末70−3のバックアップアプリ77に送信する(S1103)。
S1103の後、S113が実行される。バックアップアプリ77は、発信者情報を受信した後に着信を受信した場合、発信者情報と、着信があったこととをディスプレイに表示する。
発信者情報をS113における呼出しの前に送信することによって、携帯情報端末70に対応する内線端末60が有するすべての電話帳データを携帯情報端末70に送信しなくても、ナンバーディスプレイ機能を提供できる。図17に示すS113以降の処理は、図15に示すS113以降の処理と同じである。
図18は、実施例2の発信時にバックアップアプリ77を使用した時の携帯情報端末70の処理を示すフローチャートである。
携帯情報端末70−1は、クラウドPBX80よりアプリ起動許可を受信したか否か判定する(S1600)。アプリ起動の許可を受信しない場合、PBX50−1が正常動作していると判別し、携帯情報端末70−1はバックアップアプリ77を起動せず、S1600を繰り返す。一方で、アプリ起動の許可を受信した場合、PBX50−1が障害又は故障等の異常動作と判別し、携帯情報端末70−1はバックアップアプリ77を起動する(S1601)。
S1600の後、バックアップアプリ77は、利用者によるモードの選択を受け付ける。そして、受け付けたモードが、電話帳モードであるか、番号入力モードであるかを判定する(S1602)。
利用者が電話帳モードを選択した場合、バックアップアプリ77は、携帯情報端末70−1のディスプレイに電話帳モードを示す画面を表示し、電話帳モードを起動する(S1603:図17に示すS1500に対応)。そして、バックアップアプリ77は、番号変換情報92に登録される携帯情報端末70−1に対応する内線端末60−1の電話帳を、クラウドPBX80から呼び出し、携帯情報端末70−1のディスプレイに表示する(S1604:図17に示すS1501、S1503及びS1906に相当)。
利用者は、呼び出した電話帳から発信先を選択する(S1605:図17に示すS1504に相当)。これによって、クラウドPBX80を経由して指定の宛先を呼び出す(S1608:図17に示すS1505に相当)。
一方で、利用者が番号入力モードを選択した場合、バックアップアプリ77は、携帯情報端末70−1のディスプレイに番号入力モードを示す画面を表示し、番号入力モードを起動する(S1606)。ここで、バックアップアプリ77は、番号の入力を要求する画面を表示する。利用者は、番号入力要求に対し、宛先の内線番号を入力する(S1607)。S1607において宛先の内線番号を入力されることで、バックアップアプリ77は、クラウドPBX80を経由して指定の宛先を呼び出す(S1608)。
ここで、内線番号ではない、通常の外線番号によって発信する場合、バックアップアプリ77は、利用者が入力する指定の番号を受け付ける。これによって、バックアップアプリ77は、指定の番号を受け付けた場合、クラウドPBX80に宛先の呼び出しを指示せず、PSTN22を介した通常の通話を行う。
S1608の後、バックアップアプリ77は、宛先の応答を検出した場合(S1609)、相互通信(通話開始)処理を行う(S1610)。バックアップアプリ77は、携帯情報端末70−1又は宛先の携帯情報端末70による切断を検出した場合(S1611)、切断処理(S1612)を行い、相互通信(通話開始)を終了する。
図19は、実施例2のPSTN端末10及び携帯情報端末70以外の情報端末90から呼び出された場合の携帯情報端末70−1の処理を示すシーケンス図である。
図19に示す処理は、PBX50−1が故障又は障害中であり、情報端末90が携帯情報端末70−1を呼び出す際の処理を示す。このため、図19に示すS100〜S104、S107、S108、S1100、S117及びS1101は、図15に示すS100〜S104、S107、S108、S1100、S117及びS1101と同じである。
情報端末90は、携帯情報端末70に割り当てられた携帯電話番号を用いて、携帯情報端末70を呼び出す(S1700)。携帯情報端末70−1のバックアップアプリ77は、着信がクラウドPBX80を経由した着信でないため、携帯情報端末70−1に割り当てられた携帯電話番号に通常の着信があったと判定する(S1701)。
なお、クラウドPBX80を経由した着信には、クラウドPBX80を示す識別子が含まれるため、バックアップアプリ77は、着信にクラウドPBX80を示す識別子が含まれる場合、着信がクラウドPBX80を経由した着信であると判定する。
S1701の後、携帯情報端末70−1のバックアップアプリ77は、通常着信動作に沿い、携帯情報端末70−1があらかじめ有する電話帳と発信元番号とを照合し、発信者情報の表示を行う(S1702)。そして、携帯情報端末70−1のバックアップアプリ77は、情報端末90に応答し(S1151)、情報端末90と相互に通信する(S1161)。
図20は、実施例2の着信時にバックアップアプリ77を使用した時の携帯情報端末70−1の処理を示すフローチャートである。
携帯情報端末70−1は、クラウドPBX80よりアプリ起動許可を受信したか否か判定する(S1800)。アプリ起動の許可を受信しない場合、PBX50−1が正常動作していると判別し、携帯情報端末70−1はバックアップアプリ77を起動せず、S1800を繰り返す。一方で、アプリ起動の許可を受信した場合、PBX50−1が障害又は故障等の異常動作と判別し、携帯情報端末70−1はバックアップアプリ77を起動する(S1801:図19に示すS1101に相当)。
なお、S1800及びS1801は、図18に示すS1600及びS1601と同じである。このため、バックアップアプリ77は、S1600及びS1601の後、S1602と並行して、S1802を実行してもよい。
バックアップアプリ77を起動した後、着信を検出したか否か判定する(着信の検出監視)(S1802)。着信を検出した場合、初めにクラウドPBX80からの着信か否かを判別する。判別は、クラウドPBX80の番号から着信したか否かで行う(S1803)。
クラウドPBX80からの着信の場合、バックアップアプリ77は、着信が、故障したPBX50−1から転送されたものであると判別し(S1804)、クラウドPBX80から発信者情報を受信する(S1805)。そして、バックアップアプリ77は、受信した発信者情報を表示(S1806)して着信する。
ここで、バックアップアプリ77は、発信者情報と、クラウドPBX80を経由した着信であること(すなわち、PBX50のバックアップ中であること)とを表示してもよい。これにより、利用者は、PBX50のバックアップによる着信であるか、通常の着信であるかを認識することができる。
一方で、クラウドPBX80からの着信ではない場合、バックアップアプリ77は、携帯情報端末70−1に割り当てられた携帯電話番号への着信と判別する(S1807:図19に示すS1701に相当)。そして、バックアップアプリ77は、携帯情報端末70−1があらかじめ有するナンバーディスプレイ機能を用いて、あらかじめ有する電話帳と発信元番号とを照合し、抽出した発信者情報を表示(S1808:図19に示すS1702に対応)して着信する。
そして、利用者がバックアップアプリ77を介して着信に対して応答し(S1809:図19に示すS1151に対応)、バックアップアプリ77は、相互通信(通話開始)処理を行う(S1810:図19に示すS1161に対応)。バックアップアプリ77は、携帯情報端末70−1又は相手の端末による切断を検出した場合(S1811)、切断処理を行い(S1812)、相互通信(通話開始)を終了する。
図21は、実施例2の電話帳データの定期バックアップと故障時のバックアップアプリ77の処理を示すシーケンス図である。
図21に示す処理において、まず、クラウドPBX80に番号変換情報92が登録される(S1900)。S1900において、番号変換情報92には、内線端末60−1及び携帯情報端末70−1と、内線端末60−3及び携帯情報端末70−3とが、対応して登録される。
登録される方法は、実施例1の図10に示す処理によって登録されてもよいし、クラウドPBX80の保守者によって登録されてもよい。
一方で、内線端末60−1及び内線端末60−3の各々には、利用者によって電話帳データが登録される(S1901)。S1901の後、内線端末60−1及び内線端末60−3は、登録された電話帳データをPBX50−1へ送信する(S1902)。
各内線端末60の電話帳データを受信した場合、PBX50−1は、受信した電話帳データを一時的に保存する(S1903)。そして、クラウドPBX80によるヘルスチェック処理の際(S100、S101)、PBX50−1は、保存した電話帳データをクラウドPBX80に送信する(S1904)。
PBX50−1から電話帳データを受信した場合、クラウドPBX80の呼制御機能部91は、電話帳バックアップ用メモリ86の電話帳バックアップ情報96に、受信した電話帳データを内線端末60ごとに識別子を付して保存する(S1905)。また、S1905において、呼制御機能部91は、番号変換情報92の電話帳925に、電話帳データに付された識別子を格納する。
PBX50が、クラウドPBX80によるヘルスチェックの際に電話帳データをクラウドPBX80に送信することによって、クラウドPBX80は、最新の電話帳データを保持することができる。
S1905の後、PBX50−1において故障又は障害が発生した場合(S102)、図17に示すS103、S104、S107、S108、S1100、S117、S1101、S1500〜S1503及びS1906が実行される。S1906の後、利用者から発信先を入力された場合、図17におけるS1504以降が実行される(S1171)。
図22は、実施例2の発信の際にバックアップアプリ77が表示する画面2001を示す説明図である。
図22に示す画面2001は、バックアップアプリ77によって携帯情報端末70のディスプレイに表示される。例えば、利用者が発信をバックアップアプリ77に発信を指示した場合、バックアップアプリ77は画面2001を表示する。
画面2001は、電話帳モードアイコン2002及び番号入力モードアイコン2003を含む。電話帳モードアイコン2002を利用者が操作した場合、図17に示すS1500、図18に示すS1603、及び、図21に示すS1500が実行される。
番号入力モードアイコン2003を利用者が操作した場合、図18に示すS1606が実行される。
図23は、実施例2の着信の際にバックアップアプリ77が表示する画面2004を示す説明図である。
図23に示す画面2004は、バックアップアプリ77によって携帯情報端末70のディスプレイに表示される。画面2004は、図15に示すS1104、図16に示すS1204及びS1205、図17に示すS1104、並びに、図20に示すS1806において表示される。
画面2004は、発信者情報2005、応答アイコン2006及び拒否アイコン2007を含む。発信者情報2005には、クラウドPBX80を経由した着信であること、及び、発信者情報が表示される。ここで、発信者情報とは、図17においては、発信者である携帯情報端末70−1を示す名称又は内線番号である。
応答アイコン2006は、利用者が着信に応答する場合に操作されるアイコンである。また、拒否アイコン2007は、利用者が着信を拒否する場合に操作されるアイコンである。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各構成、機能、処理部、処理手順等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、又はファイル等の情報は、メモリ、ハードディスク若しくはSSD(Solid State Drive)等の記録装置、又は、ICカード、SDカード若しくはDVD等の記録媒体に置くことができる。
また、制御線又は情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線又は情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されている。