JP2016149616A - 音声通信システム、通信制御サーバ、通信端末、及びプログラム - Google Patents

Abstract

【課題】通信端末間で音声通信を行う際に、通信端末での消費電力を抑制する。
【解決手段】通信制御サーバ２０は、発信元端末１１から発呼要求を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、発信元端末１１と、発信先端末１と、の間で交換する際に使用する一意のキーを生成し、該生成したキーをプッシュ通知で発信先端末１に通知すると共に、発信元端末１１にキーを送信する。発信元端末１１及び発信先端末１は、キーを用いて、制御メッセージを、発信元端末１１と発信先端末１との間で交換し、発信元端末１１と発信先端末１との間で音声通信を行う際に必要な情報を取得する。
【選択図】図４

Description

本発明は、端末間で音声通信を行う技術に関する。

従来から、SIP（Session Initiation Protocol）を用いて通信端末間で音声通信を行う技術がある。例えば、特許文献１（特開２００９−２９０４５０号公報）には、SIPを用いて通信端末間で音声通信を実現する技術について開示されている。

特開２００９−２９０４５０号公報

特許文献１のように、SIPを用いて通信端末間で音声通信を行う場合には、通信端末は、通信端末の起動時に、SUBSCRIBEメッセージをSIPサーバに送信し、SIPサーバと接続しておく必要がある。そして、音声通信のセッションを確立するための制御メッセージをSIPサーバを介して通信端末間でやりとりすることになる。制御メッセージとしては、セッションの開始要求であるINVITEメッセージなどがあげられる。

しかし、通信端末の起動時に、SUBSCRIBEメッセージをSIPサーバに送信し、通信端末をSIPサーバに接続しておくと、通信端末において電力を消費してしまうことになる。スマートフォンや、ウェアラブル端末等の通信端末は、一般的に電池容量が少ないため、通信端末において無駄に電力を消費してしまうことは好ましくない。

本発明の目的は、通信端末間で音声通信を行う際に、通信端末での消費電力を抑制することである。

本発明にかかる音声通信システムは、
複数の通信端末と、前記通信端末同士の通信を制御する通信制御サーバと、を有し、
前記通信制御サーバは、
発信元の通信端末である発信元端末から発呼要求を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、前記発信元端末と、発信先の通信端末である発信先端末と、の間で交換する際に使用する一意のキーを生成し、該生成したキーをプッシュ通知で前記発信先端末に通知すると共に、前記発信元端末に前記キーを送信し、
前記発信元端末及び前記発信先端末は、
前記キーを用いて、前記制御メッセージを、前記発信元端末と前記発信先端末との間で交換し、前記発信元端末と前記発信先端末との間で音声通信を行う際に必要な情報を取得する、ことを特徴とする。

本発明によれば、通信端末間で音声通信を行う際に、通信端末での消費電力を抑制することができる。

本実施形態の音声通信システムのシステム構成例を示す図である。 ユーザＤＢ３０の小型通信端末１のユーザ情報リストのデータ構成例を示す図である。 本実施形態の音声通信システムの処理動作例を示す第１の図である。 本実施形態の音声通信システムの処理動作例を示す第２の図である。 本実施形態の音声通信システムの処理動作例を示す第３の図である。 本実施形態の音声通信システムの処理動作例を示す第４の図である。 音声通信システムのシステム構成の変形例及び処理動作例を示す図である。 ユーザＤＢ３０の通話可否リストのデータ構成例を示す図である。

（本発明の一態様にかかる音声通信システムの概要）
まず、図１、図４を参照しながら、本発明の一態様にかかる音声通信システムの概要について説明する。図１は、本発明の一態様にかかる音声通信システムのシステム構成例を示す。図４は、本発明の一態様にかかる音声通信システムの処理動作例を示す。

本発明の一態様にかかる音声通信システムは、図１に示すように、複数の通信端末１、１１、１２、１３と、通信端末同士の通信を制御する通信制御サーバ２０と、を有して構成する。通信端末は、図１に示す小型通信端末１、第１〜第３の通信端末１１〜１３等を意味する。

通信制御サーバ２０は、図４に示すように、発信元端末１１から発呼要求（ステップA1）を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、発信元端末１１と、発信先端末１と、の間で交換する際に使用する一意のキーを生成し、該生成したキーをプッシュ通知で発信先端末１に通知する（ステップA5）と共に、発信元端末１１にキーを送信する（ステップA6）。これにより、発信元端末１１及び発信先端末１は、通信制御サーバ２０からキーを取得することになる。

発信元端末１１及び発信先端末１は、通信制御サーバ２０から取得したキーを用いて、音声通信のセッションを確立するための制御メッセージを、発信元端末１１と発信先端末１との間で交換し、発信元端末１１と発信先端末１との間で音声通信を行う際に必要な情報を取得する（ステップA9〜A18）。

本発明の一態様にかかる音声通信システムでは、発信先端末１は、プッシュ通知でキーを取得した段階で、そのキーを用いて、発信元端末１１と制御メッセージを交換し、発信元端末１１と発信先端末１との間で音声通信を行う際に必要な情報を取得することになる。このため、発信先端末１での消費電力を抑制することができる。

特許文献１のようにSIPを用いて通信端末間で音声通信を行う場合、通信端末はSIPサーバと接続しておく必要があり、通信端末において電力を消費してしまうことになる。

これに対し、本発明の一態様にかかる音声通信システムにおいては、発信先端末１は、プッシュ通知によりキーを取得した段階で、発信元端末１１と制御メッセージを交換するため、発信先端末１での消費電力を抑制することができる。従って、本発明の一態様にかかる音声通信システムは、通信端末間で音声通信を行う際に、通信端末での消費電力を抑制することができる。以下、添付図面を参照しながら、本発明の一態様にかかる音声通信システムについて詳細に説明する。

＜音声通信システムのシステム構成例＞
まず、図１を参照しながら、本実施形態の音声通信システムのシステム構成例について説明する。図１は、本実施形態の音声通信システムのシステム構成例を示す図である。

本実施形態の音声通信システムは、小型通信端末１、第１〜第３の通信端末１１〜１３、通信制御サーバ２０、ユーザＤＢ３０を有して構成している。小型通信端末１、第１〜第３の通信端末１１〜１３、通信制御サーバ２０、ユーザＤＢ３０は、ネットワークＮＷに接続可能になっている。ネットワークＮＷは、有線、無線を問わずあらゆる通信形態が適用可能である。図１に示す音声通信システムは、第１〜第３の通信端末１１〜１３を有して構成しているが、通信端末の数は特に限定せず、任意の数で構成することが可能である。また、ユーザＤＢ３０は、通信制御サーバ２０に実装されていても良い。

本実施形態の音声通信システムは、例えば、小型通信端末１を小学生等の子供が携帯し、第１〜第３の通信端末１１〜１３を子供と密接に関係する関係者が携帯する。そして、小型通信端末１と、第１〜第３の通信端末１１〜１３と、の間でメッセージのやりとりをし、子供と関係者とのコミュニケーションの向上を図ることを可能にしている。子供の関係者としては、子供の父母、兄、姉、祖父母等の近親者があげられる。

小型通信端末１は、ネットワークＮＷを介して通信が可能な装置である。小型通信端末１は、制御部２、記憶部３、表示部４を有して構成する。制御部２は、小型通信端末１を統括して制御する。記憶部３は、各種情報を記憶する。表示部４は、各種情報を表示する。小型通信端末１は、子供が携帯して使用するため、簡易な操作で通信を行うことが可能な構成になっている。小型通信端末１は、例えば、腕時計型、ペンダント型、キーホルダー型、メガネ型、リング型などの子供が身に付けて携帯し易い形状で構成する。

第１〜第３の通信端末１１〜１３は、ネットワークＮＷを介して通信が可能な装置であり、例えば、パソコン、タブレット、スマートフォンなどの通信機能を有する各種端末が該当する。第１〜第３の通信端末１１〜１３は、制御部１１１〜１３１、記憶部１１２〜１３２、表示部１１３〜１３３を有して構成する。制御部１１１〜１３１は、通信端末１１〜１３を統括して制御する。記憶部１１２〜１３２は、各種情報を記憶する。表示部１１３〜１３３は、各種情報を表示する。

通信制御サーバ２０は、小型通信端末１と、第１〜第３の通信端末１１〜１３と、の間の通信を制御するアプリケーションサーバである。通信制御サーバ２０は、制御部２１、認証部２２、ＭＱ部２３、ＰＵＳＨ通知部２４を有して構成する。認証部２２、ＭＱ部２３は、それぞれ複数有して構成しても良い。

制御部２１は、通信制御サーバ２０を統括して制御する。認証部２２は、ユーザＤＢ３０に記憶されているユーザ情報を基にユーザ認証を行う。ＭＱ部２３は、メッセージキューであり、端末同士のセッションを確立するための制御メッセージを転送する。ＰＵＳＨ通知部２４は、端末にＰＵＳＨ通知する。

ユーザＤＢ３０は、ユーザ認証を行う際に使用するユーザ情報を管理する。ユーザＤＢ３０は、例えば、図２に示す小型通信端末１のユーザ情報リストのように、第１〜第３の通信端末１１〜１３を一意に識別する第１〜第３端末識別子と、小型通信端末１を一意に識別する第１小型端末識別子と、を紐付けてリストとして記憶している。そして、第１小型端末識別子と紐付けられた第１〜第３端末識別子の通信端末１１〜１３のみが小型通信端末１と通信を行うことを可能にしている。図２では、登録Ｎｏ「０」に第１小型端末識別子が登録されている。また、登録Ｎｏ「１」〜「３」に第１〜第３端末識別子が登録されている。第１小型端末識別子は、小型通信端末１を一意に識別する識別子である。第１端末識別子は、第１の通信端末１１を一意に識別する識別子である。第２端末識別子は、第２の通信端末１２を一意に識別する識別子である。第３端末識別子は、第３の通信端末１３を一意に識別する識別子である。本実施形態で使用する端末識別子や、小型端末識別子は、端末を一意に識別することが可能な情報であればあらゆる情報が適用可能である。例えば、小型通信端末１と第１〜第３の通信端末１１〜１３との通信専用に通信サービス企業や通信制御サーバ２０から割り振られた電話番号などを用いることが可能である。また、通信端末固有のＩＭＥＩ、ＭＡＣアドレス、通信端末を使用するユーザＩＤ、端末に搭載されるＳＩＭに対応する電話番号などを用いることも可能である。

また、ユーザＤＢ３０には、図２に示すように、第１小型端末識別子や第１〜第３端末識別子に紐付けてユーザネーム、画像データ、ユーザ色データ等のユーザ情報がリストに記憶されている。ユーザネームは、小型通信端末１や第１〜第３の通信端末１１〜１３を使用するユーザを特定するための名称データである。画像データは、ユーザを特定するためのイメージ画像である。画像データは、写真データ、イラストデータ等を使用することができる。ユーザ色データは、ユーザを特定するための色データである。通信制御サーバ２０は、ユーザＤＢ３０に登録される個々のユーザネーム、画像データ、ユーザ色データが個々のユーザを特定し易いように、重複した情報がユーザＤＢ３０に登録されないように監視しても良い。図２では、第１小型端末識別子に紐付けてユーザネーム「妹」、画像データ「imouto.JPG」、ユーザ色データ「赤」がユーザＤＢ３０に登録されている。また、第１端末識別子に紐付けてユーザネーム「ママ」、画像データ「mama.JPG」、ユーザ色データ「ピンク」がユーザＤＢ３０に登録されている。また、第２端末識別子に紐付けてユーザネーム「パパ」、ユーザ色データ「青」がユーザＤＢ３０に登録されている。また、第３端末識別子に紐付けてユーザネーム「姉」、画像データ「ane.JPG」、ユーザ色データ「黄」がユーザＤＢ３０に登録されている。「＊」は、未登録状態を意味する。図２では、登録Ｎｏ「０」に小型端末識別子を登録し、登録Ｎｏ「１」〜「５」に端末識別子を登録するようになっている。本実施形態では、ユーザＤＢ３０に登録された登録Ｎｏ「０」の小型端末識別子の端末と、登録Ｎｏ「１」〜「５」の端末識別子の端末と、が通信制御サーバ２０を介して通信を行うことが可能となっている。なお、図２に示す情報は、１つの小型通信端末専用のリストであり、個々の小型通信端末毎に図２に示すリストをユーザＤＢ３０で管理する。なお、図２に示すリストは一例であり、リストに登録できる端末識別子は、登録Ｎｏ「１」〜「５」の５つに限定せず、任意の数の端末識別子を登録するようにすることが可能である。

本実施形態の小型通信端末１は、ユーザＤＢ３０に登録された図２に示す情報を記憶部３に記憶することになる。記憶部３に記憶する図２に示す各種情報は、小型通信端末１を操作して登録するのではなく、通信制御サーバ２０から受信して記憶部３に登録することになる。小型通信端末１の制御部２は、記憶部３に端末識別子に紐付けて記憶されたユーザネーム、画像データ、ユーザ色データ等のユーザ情報を用いて、端末識別子の通信端末を使用するユーザに対応する各種画面を生成し、表示部４に表示する。例えば、小型通信端末１が第１の通信端末１１と通信を行う場合は、記憶部３に第１端末識別子に紐付けて記憶されたユーザネーム「ママ」、画像データ「mama.JPG」、ユーザ色データ「ピンク」等のユーザ情報を用いて、第１端末識別子の通信端末１１を使用するユーザに対応する各種画面を生成し、表示部４に表示することになる。このため、小型通信端末１の表示部４には、ユーザネーム「ママ」、画像データ「mama.JPG」、ユーザ色データ「ピンク」等の情報が表示されるため、小型通信端末１を操作するユーザは、第１の通信端末１１のユーザを容易に把握することができる。そして、小型通信端末１のユーザは、表示部４に表示された各種画面を操作して、第１の通信端末１１と通信を行うことになる。各種画面を生成する際にユーザ情報の他に必要なデータは、記憶部３に記憶しておき、制御部２は、各種画面を生成する際に、適宜、記憶部３から必要なデータも読み出して、各種画面を生成する。

また、本実施形態の第１〜第３の通信端末１１〜１３も小型通信端末１と同様に、ユーザＤＢ３０に登録された図２に示す情報を記憶部１１２〜１３２に記憶することになる。記憶部１１２〜１３２に記憶する図２に示す各種情報は、通信端末１１〜１３を操作して記憶部１１２〜１３２に登録しても良く、通信制御サーバ２０から受信して記憶部１１２〜１３２に登録しても良い。第１〜第３の通信端末１１〜１３の制御部１１１〜１３１は、小型通信端末１と同様に、記憶部１１２〜１３２に端末識別子に紐付けて記憶されたユーザネーム、画像データ、ユーザ色データ等のユーザ情報を用いて、端末識別子の通信端末を使用するユーザに対応する各種画面を生成し、表示部１１３〜１３３に表示する。

＜音声通信システムの処理動作例＞
次に、図３〜図５を参照しながら、本実施形態の音声通信システムの処理動作例について説明する。図３は、ユーザＤＢ３０に端末識別子やユーザ情報を登録する処理動作例を示している。端末識別子やユーザ情報の登録は、小型通信端末１の通信を管理する１つの通信端末からのみ可能になっており、本実施形態では、管理者の使用する第１の通信端末１１のみが端末識別子やユーザ情報の登録を可能にしている。図４は、発呼処理、着呼処理の処理動作例を示す。図５は、終話処理の処理動作例を示す。本実施形態の音声通信システムを構成する小型通信端末１や第１〜第３の通信端末１１〜１３は、以下の処理動作を行うための通信アプリがインストールされており、その通信アプリを起動して図３〜図５に示す処理動作を行うことになる。

＜ユーザ情報の登録処理動作例＞
まず、図３を参照しながら、ユーザ情報の登録処理動作例について説明する。

まず、管理者の使用する第１の通信端末１１の通信アプリは、通信制御サーバ２０に接続し、本実施形態の音声通信システムのサービスを使用するためのユーザ登録を行う（ステップS1）。ユーザ登録としては、管理者を特定するためのユーザＩＤやパスワード等をユーザＤＢ３０に登録する。また、小型通信端末１の第１小型端末識別子と、第１の通信端末１１の第１端末識別子と、を紐付けてユーザＤＢ３０のリストに登録する（ステップS2）。これにより、通信制御サーバ２０の制御部２１は、小型通信端末１の第１小型端末識別子と、第１の通信端末１１の第１端末識別子と、を紐付けてユーザＤＢ３０のリストに登録して管理することができる（ステップS3）。

次に、第１の通信端末１１の通信アプリは、小型通信端末１と通信を行う第１〜第３の通信端末１１〜１３のユーザ情報の登録処理を行う（ステップS4）。通信制御サーバ２０の制御部２１は、第１の通信端末１１の第１端末識別子が第１小型端末識別子に紐付けてユーザＤＢ３０にリストとして登録されているため、第１の通信端末１１の登録処理を許可する。第１の通信端末１１の登録処理が許可されると、第１の通信端末１１の通信アプリは、第１の通信端末１１を使用する管理者のユーザネーム、画像データ、ユーザ色データ等のユーザ情報をユーザＤＢ３０のリストに登録する。このリストは、小型通信端末１専用のリストであり、登録処理が許可された第１の通信端末１１のみが小型通信端末１専用のリストの設定変更を行うことが可能になっている。また、第１の通信端末１１の通信アプリは、小型通信端末１を使用するユーザのユーザネーム、画像データ、ユーザ色データ等のユーザ情報をユーザＤＢ３０のリストに登録する。また、小型通信端末１と通信を行う第２の通信端末１１の第２端末識別子、第２の通信端末１１を使用するユーザのユーザネーム、画像データ、ユーザ色データ等のユーザ情報をユーザＤＢ３０のリストに登録する。また、小型通信端末１と通信を行う第３の通信端末１３の第３端末識別子、第３の通信端末１３を使用するユーザのユーザネーム、画像データ、ユーザ色データ等のユーザ情報をユーザＤＢ３０のリストに登録する。これにより、通信制御サーバ２０の制御部２１は、図２に示すように、小型通信端末１と通信を行う第１〜第３の通信端末１１〜１３のユーザ情報をユーザＤＢ３０のリストに登録して管理することができる（ステップS5）。

小型通信端末１と通信を行う第１〜第３の通信端末１１〜１３のユーザ情報の登録処理が完了すると、通信制御サーバ２０の制御部２１は、小型通信端末１や第１〜第３の通信端末１１〜１３の端末識別子やユーザ情報を小型通信端末１に送信し、小型通信端末１や第１〜第３の通信端末１１〜１３の端末識別子やユーザ情報を小型通信端末１の記憶部３に登録する（ステップS6）。これにより、小型通信端末１の記憶部３には、図２に示すように、小型通信端末１や第１〜第３の通信端末１１〜１３の端末識別子やユーザ情報が記憶されることになる。また、通信制御サーバ２０の制御部２１は、小型通信端末１や第１〜第３の通信端末１１〜１３の端末識別子やユーザ情報を第１〜第３の通信端末１１〜１３に送信し、小型通信端末１や第１〜第３の通信端末１１〜１３の端末識別子やユーザ情報を第１〜第３の通信端末１１〜１３の記憶部１１２〜１３２に登録する（ステップS7）。これにより、第１〜第３の通信端末１１〜１３の記憶部１１２〜１３２には、小型通信端末１や第１〜第３の通信端末１１〜１３の端末識別子やユーザ情報が記憶されることになる。なお、ステップS6、S7の処理は、小型通信端末１や第２、第３の通信端末１２、１３の通信アプリが通信制御サーバ２０に接続し、ユーザＤＢ３０のリストに登録された情報を取得するようにすることも可能である。この場合、小型通信端末１や第２、第３の通信端末１２、１３の通信アプリは、自身の端末識別子が登録されているリストの情報を取得することになる。

本実施形態の音声通信システムは、上述した図３に示す登録処理動作を行うことで、ユーザＤＢ３０には、第１小型端末識別子と第１〜第３端末識別子とが紐付けられてリストとして記憶されることになる。また、第１小型端末識別子と第１〜第３端末識別子とにユーザ情報が紐付けられてリストとして記憶されることになる。また、小型通信端末１の記憶部３には、第１小型端末識別子と第１〜第３端末識別子とにユーザ情報が紐付けられて記憶されることになる。また、第１〜第３の通信端末１１〜１３の記憶部１１２〜１３２には、第１小型端末識別子と第１〜第３端末識別子とにユーザ情報が紐付けられて記憶されることになる。これにより、端末識別子とユーザ情報とを用いて、第１〜第３の通信端末１１〜１３と、小型通信端末１と、の間でメッセージのやりとりを行うことが可能となる。

＜発呼処理、着呼処理の処理動作例＞
次に、図４を参照しながら、発呼処理、着呼処理の処理動作例について説明する。なお、以下の処理では、第１の通信端末１１を、発呼を開始する発信元端末とし、小型通信端末１を、発呼に応答する発信先端末として説明する。

まず、発信元端末１１の通信アプリは、ユーザにより発呼操作が行われると、発信元ＩＤと発信先ＩＤとを含む発呼要求を通信制御サーバ２０に送信する（ステップA1）。発信元ＩＤは、発信元端末１１を一意に特定する情報であり、記憶部１１２に記憶された図２に示す第１端末識別子を用いることになる。また、発信先ＩＤは、発信先端末１を一意に特定する情報であり、記憶部１１２に記憶された図２に示す第１小型端末識別子を用いることになる。

発呼要求を受信した通信制御サーバ２０の制御部２１は、発信元ＩＤと発信先ＩＤとの通話可否を問い合わせるためのユーザ認証要求を認証部２２に送信する（ステップA2）。

ユーザ認証要求を受信した認証部２２は、ユーザＤＢ３０を参照し、発信元ＩＤと発信先ＩＤとの組がユーザＤＢ３０に記憶されているか照合し、照合結果を制御部２１に返信する（ステップA3）。認証部２２は、発信元ＩＤと発信先ＩＤとの組がユーザＤＢ３０に記憶されている場合は、認証ＯＫを制御部２１に返信する。また、発信元ＩＤと発信先ＩＤとの組がユーザＤＢ３０に記憶されておらず照合できない場合は、認証ＮＧを制御部２１に返信する。本実施形態では、発信元ＩＤである第１端末識別子と、発信先ＩＤである第１小型端末識別子と、が紐付けられてユーザＤＢ３０のリストに記憶されているため、認証部２２は、発信元ＩＤと発信先ＩＤとの組がユーザＤＢ３０に記憶されていると判断し、認証ＯＫを制御部２１に返信する。

照合結果を受信した制御部２１は、認証ＯＫの場合は、発信元端末１１と発信先端末１とがＭＱ部２３を介して制御メッセージを交換する際に使用する一意の共通MQ Keyを生成する。共通MQ Keyは、制御メッセージをやりとりする端末同士を一意に識別するKeyである。共通MQ Keyの生成方法は、制御メッセージをやりとりする端末同士を一意に識別することが可能なkeyを生成することが可能であれば、あらゆる方法が適用可能である。例えば、乱数を用いて一意の共通MQ Keyをランダムに生成したり、発信元ＩＤと発信先ＩＤとの情報を用いて一意の共通MQ Keyを生成したりすることが可能である。なお、通信制御サーバ２０にＭＱ部２３が複数ある場合は、個々のＭＱ部２３を一意に特定するためのＭＱ部識別子を共通MQ Keyに含めて生成する。または、個々のＭＱ部２３を一意に特定するためのＭＱ部識別子を共通MQ Keyと紐付ける。

次に、制御部２１は、発信先ＩＤの端末である発信先端末１に対して共通MQ Keyを含む着信通知を通知するためのＰＵＳＨ通知依頼をＰＵＳＨ通知部２４に送信する（ステップA4）。

ＰＵＳＨ通知依頼を受信したＰＵＳＨ通知部２４は、そのＰＵＳＨ通知依頼を基に、共通MQ Keyを含む着信通知を発信先端末１にＰＵＳＨ通知する（ステップA5）。これにより、発信先端末１の通信アプリが共通MQ Keyを取得することになる。なお、ＰＵＳＨ通知が届く前に発信先端末１の通信アプリが起動していない場合は、ＰＵＳＨ通知が届いた際に通信アプリが起動し、通信アプリが共通MQ Keyを取得することになる。また、ＰＵＳＨ通知が届く前に通信アプリが既に起動していた場合は、ＰＵＳＨ通知が届いた際に通信アプリが共通MQ Keyを取得することになる。また、ＰＵＳＨ通知が届く前に通信アプリがバックグランドで既に起動していた場合も、ＰＵＳＨ通知が届いた際に通信アプリが共通MQ Keyを取得することになる。

制御部２１は、ＰＵＳＨ通知依頼をＰＵＳＨ通知部２４に送信した後に、発呼要求に対する返答として、同じ共通MQ Keyを含めた発呼ＯＫを発信元端末１１に送信する（ステップA6）。これにより、発信元端末１１の通信アプリが共通MQ Keyを取得することになる。

共通MQ Keyを取得した発信元端末１１、発信先端末１のそれぞれの通信アプリは、共通MQ Keyを用いて通信制御サーバ２０のＭＱ部２３に接続し（ステップA7、A8）、共通MQ KeyをＭＱ部２３に指定する。これにより、発信元端末１１、発信先端末１のそれぞれの通信アプリは、ＭＱ部２３に指定した共通MQ Keyを基に制御メッセージを交換することになる（ステップA9〜A18）。本実施形態では、発信元端末１１、発信先端末１のそれぞれの通信アプリは、MQTT（MQ Telemetry Transport）プロトコルを用いて制御メッセージを交換する。MQTTプロトコルは、パブリッシュ／サブスクライブ型のメッセージング・プロトコルである。パブリッシュ／サブスクライブ型のプロトコルでは、メッセージを送信する側をパブリッシャー、メッセージを受信する側をサブスクライバーという。そして、MQTTプロトコルを利用してメッセージのやりとりを行う場合は、パブリッシャーは、トピックを指定してＭＱ部２３にメッセージを送信し、送信されたメッセージは、ＭＱ部２３においてそのトピックに対してサブスクライブを指定していたサブスクライバーに配信される。このため、本実施形態の発信元端末１１、発信先端末１のそれぞれの通信アプリは、共通MQ Keyを上述したトピックとして用い、共通MQ KeyをＭＱ部２３に指定し、共通MQ KeyをＭＱ部２３に指定した端末同士だけがＭＱ部２３を介して制御メッセージを交換することができる。なお、ＭＱ部２３が複数ある場合は、制御メッセージにMQ部識別子が含まれることになるため、通信制御サーバ２０の制御部２１は、制御メッセージに含まれるMQ部識別子を基に、ＭＱ部２３を特定し、その特定したＭＱ部２３に共通MQ Keyを指定することになる。これにより、ＭＱ部２３が複数ある場合でも、発信元端末１１、発信先端末１のそれぞれの通信アプリは、共通MQ Keyを用いて特定のＭＱ部２３に接続し、ＭＱ部２３に共通MQ Keyを指定することができる（ステップA7、A8）。

発信元端末１１、発信先端末１のそれぞれの通信アプリが共通MQ Keyを通信制御サーバ２０に送信し、ＭＱ部２３に共通MQ Keyを指定し（ステップA7、A8）、発信元端末１１、発信先端末１の両方がＭＱ部２３を経由して制御メッセージを交換できる状態になった場合に、発信元端末１１の通信アプリは、共通MQ Keyを指定して、セッション開始要求であることを示すINVITEのメッセージをＭＱ部２３に送信する（ステップA9）。

ＭＱ部２３は、発信元端末１１からINVITEのメッセージを受信すると、発信元端末１１が指定した共通MQ Key に該当するサブスクライバーである発信先端末１にINVITEのメッセージを転送する（ステップA10）。これにより、発信先端末１の通信アプリは、発信元端末１１から送信されたINVITEのメッセージを取得することができる。INVITEのメッセージを取得した発信先端末１の通信アプリは、ユーザ呼び出しの出力を開始する。ユーザ呼び出しの出力方法としては、音、振動、光、画面表示などのあらゆる方法を用いることが可能である。また、発信先端末１の通信アプリは、共通MQ Keyを指定して、呼び出し中であることを示すRingingのメッセージをＭＱ部２３に送信する（ステップA11）。

ＭＱ部２３は、発信先端末１からRingingのメッセージを受信すると、発信先端末１が指定した共通MQ Key に該当するサブスクライバーである発信元端末１１にRingingのメッセージを転送する（ステップA12）。これにより、発信元端末１１の通信アプリは、発信先端末１から送信されたRingingのメッセージを取得することができる。Ringingのメッセージを取得した発信元端末１１の通信アプリは、呼び出し中であること示す出力を行う。呼び出し中であることを示す出力方法としては、音、振動、光り、画面表示などのあらゆる方法を用いることが可能である。

発信元端末１１および発信先端末１の通信アプリは、ユーザの受話を待つ間、通話を行うRTP（Real-time Transport Protocol）に必要なRTP情報を交換する（ステップA13〜A16）。RTPは、音声や映像をストリーミング再生するための伝送プロトコルである。RTP情報としては、例えば、UDPポート番号や音声パケットの暗号化Keyなどを交換する。

ステップA13〜A16のRTP情報の交換タイミングとしては、例えば、ステップA11、A12のRingingのメッセージと同時、または、ステップA11、A12のRingingのメッセージの送信後に行う。ただし、ステップA13〜A16のRTP情報の交換前に発信先端末１で受話操作が行われ、発信先端末１から発信元端末１１に200 OKのメッセージが送信されても、ステップA13〜A16のRTP情報の交換が完了するまで、ステップA19、A20の通話を開始することができない。このため、ステップA11、A12のRingingのメッセージの送信前にステップA13〜A16のRTP情報の交換を行うようにしても良い。

発信先端末１において受話アイコンがユーザによりタップされるなどの受話操作が行われた場合に、発信先端末１の通信アプリは、共通MQ Keyを指定して、受話したことを示す200 OKのメッセージをＭＱ部２３に送信する（ステップA17）。

ＭＱ部２３は、発信先端末１から200 OKのメッセージを受信すると、発信先端末１が指定した共通MQ Key に該当するサブスクライバーである発信元端末１１に200 OKのメッセージを転送する（ステップA18）。これにより、発信元端末１１の通信アプリは、発信先端末１から送信された200 OKのメッセージを取得することができる。発信元端末１１の通信アプリは、200 OKのメッセージを取得した場合に、発信元端末１１および発信先端末１の通信アプリは、RTPで音声パケットを端末間で直接送受信し、通話を開始することになる（ステップA19、A20）。

なお、上述した図４に示す処理動作において、ステップA14、ステップA16の処理でRTP情報を通信アプリが取得した際に、RTP情報を受信したことを示すメッセージを送信するようにしても良い。これにより、RTP情報を受信したことを示すメッセージを取得した通信アプリは、通話相手端末において通話準備が整ったことを確認することができる。

＜終話処理の処理動作例＞
次に、図５を参照しながら、終話処理の処理動作例について説明する。

発信先端末１または発信元端末１１においてユーザにより終話アイコンがタップされるなどの終話操作が行われた場合に、共通MQ Keyを指定して、セッション終了であることを示すByeのメッセージをＭＱ部２３に送信する（ステップB1）。図５では、発信元端末１１において終話操作が行われ、発信元端末１１の通信アプリが、共通MQ Keyを指定し、ByeのメッセージをＭＱ部２３に送信している（ステップB1）。

ＭＱ部２３は、発信元端末１１からByeのメッセージを受信すると、発信元端末１１が指定した共通MQ Key に該当するサブスクライバーである発信先端末１にByeのメッセージを転送する（ステップB2）。Byeのメッセージを取得した発信先端末１の通信アプリは、共通MQ Keyを指定し、200 OKのメッセージをＭＱ部２３に送信する（ステップB3）。

ＭＱ部２３は、発信先端末１から200 OKのメッセージを受信すると、発信先端末１が指定した共通MQ Key に該当するサブスクライバーである発信元端末１１に200 OKのメッセージを転送する（ステップB4）。発信元端末１１の通信アプリは、200 OKのメッセージを取得した場合に、発信元端末１１および発信先端末１の通信アプリは、音声パケット送信処理を終了し、終話を完了する。この時、発信元端末１１および発信先端末１の通信アプリは、通信制御サーバ２０から取得した共通MQ Keyを消去する。

＜本実施形態の音声通信システムの作用・効果＞
このように、本実施形態の音声通信システムは、通信制御サーバ２０は、図４に示すように、発信元端末１１の通信アプリから発呼要求（ステップA1）を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、発信元端末１１と、発信先端末１と、の間で交換する際に使用する一意の共通MQ Keyを生成し、該生成した共通MQ Keyをプッシュ通知で発信先端末１に通知する（ステップA5）と共に、発信元端末１１に共通MQ Keyを送信する（ステップA6）。これにより、発信元端末１１及び発信先端末１の通信アプリは、通信制御サーバ２０から共通MQ Keyを取得することになる。

発信元端末１１及び発信先端末１の通信アプリは、通信制御サーバ２０から取得した共通MQ Keyを用いて、音声通信のセッションを確立するための制御メッセージを、発信元端末１１と発信先端末１との間で交換し、発信元端末１１と発信先端末１との間で音声通信を行う際に必要な情報を取得する（A9〜A18）。

本実施形態の音声通信システムでは、発信先端末１の通信アプリは、プッシュ通知で共通MQ Keyを取得した段階で、その共通MQ Keyを用いて、発信元端末１１と制御メッセージを交換し、発信元端末１１と発信先端末１との間で音声通信を行う際に必要なRTP情報を取得することになる。このため、発信先端末１での消費電力を抑制することができる。

特許文献１のようにSIPを用いて通信端末間で音声通信を行う場合、通信端末はSIPサーバと接続しておく必要があり、通信端末において電力を消費してしまうことになる。

これに対し、本実施形態の音声通信システムにおいては、発信先端末１の通信アプリは、プッシュ通知により共通MQ Keyを取得した段階で、発信元端末１１と制御メッセージを交換し、発信元端末１１と発信先端末１との間で音声通信を行う際に必要なRTP情報を取得することになる。その結果、発信先端末１での消費電力を抑制することができる。従って、本実施形態の音声通信システムは、通信端末間で音声通信を行う際に、通信端末での消費電力を抑制することができる。小型通信端末１は、電池容量が少ないため、発信元端末が小型通信端末１の場合は、消費電力を抑制することができるため、効果的である。

また、本実施形態の音声通信システムは、通話を行う際に、ユーザ認証を行う際のメッセージのやりとり（ステップA1〜A6）と、セッションを確立する際の制御メッセージのやりとり（ステップA7〜A18）と、を各々分離独立して行い、ユーザ認証を行う際のメッセージのやりとり（ステップA1〜A6）と、セッションを確立する際の制御メッセージのやりとり（ステップA7〜A18）と、の一連のメッセージのやりとりを管理する必要がない。このため、通信制御サーバ２０での管理負担を軽減することができる。

また、本実施形態の音声通信システムにおいては、発信元端末１１と発信先端末１との通信アプリは、共通MQ Keyを用いてＭＱ部２３に制御メッセージを送信することで、発信元端末１１と発信先端末１との間で制御メッセージを交換するため、例えば、ネットワークの通信障害で制御メッセージの交換が一時的に途切れてしまっても、ネットワークの通信障害が直ぐに復旧した際に、制御メッセージの交換を継続して行うことができる。

また、本実施形態の通信制御サーバ２０は、発信元端末１１と発信先端末１との回線状態を管理しないため、例えば、発信元端末である第１の通信端末１１と、発信先端末である小型通信端末１と、が通話中に、発信元端末である第２の通信端末１２が図６に示すように発呼要求を行った場合は（ステップC1）、図４に示すステップA1〜A10と同様な処理を行い、発信先端末である小型通信端末１の通信アプリは、ステップC10でINVITEのメッセージを取得した際に、自端末が他の通信端末と通話中であるか否かを判断し、通話中である場合、共通MQ Keyを指定し、通話中であることを示すBusy HereのメッセージをＭＱ部２３に送信することになる（ステップC11）。

ＭＱ部２３は、発信先端末１からBusy Hereのメッセージを受信すると、発信先端末１が指定した共通MQ Key に該当するサブスクライバーである発信元端末１２にBusy Hereのメッセージを転送する（ステップC12）。これにより、発信元端末１２の通信アプリは、発信先端末１から送信されたBusy Hereのメッセージを取得し、発信先端末１が通話中であることを把握することになる。このように、本実施形態の通信制御サーバ２０は、発信元端末と発信先端末との回線状態を管理しないため、発信元端末と発信先端末との各々が相手端末に対して状態を通知することになる。

なお、上述した図６に示す処理動作例において、ステップC10でINVITEのメッセージを取得した際に、自端末が他の通信端末と通話中であるか否かを判断し、通話中でない場合、発信先端末１の通信アプリは、ユーザ呼び出しの出力を開始し、図４のステップＡ11と同様に、共通MQ Keyを指定して、呼び出し中であることを示すRingingのメッセージをＭＱ部２３に送信することになる。

なお、上述する実施形態は、本発明の好適な実施形態であり、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。

例えば、上述する実施形態では、通信制御サーバ２０がＰＵＳＨ通知部２４を有して構成する場合について説明した。しかし、ＰＵＳＨ通知部２４を他のサーバに設けるようにすることも可能である。例えば、スマフォＯＳを提供する企業が提供しているGCM（Google Cloud Messaging）サーバなどのシステムにＰＵＳＨ通知部２４を設けるようにすることも可能である。この場合は、図７に示すように、通信制御サーバ２０の制御部２１がGCMサーバ４０のＰＵＳＨ通知部２４にＰＵＳＨ通知依頼を送信することになる（ステップA4）。そして、GCMサーバ４０のＰＵＳＨ通知部２４は、ＰＵＳＨ通知依頼を受信した場合に、そのＰＵＳＨ通知依頼を基に、共通MQ Keyを含む着信通知を発信先端末１にＰＵＳＨ通知することになる（ステップA5）。これにより、発信先端末１の通信アプリが共通MQ Keyを取得することになる。

また、上述する実施形態では、管理者の所有する第１の通信端末１１のみが小型通信端末１専用のリストの設定変更を行うことを可能にしている。しかし、第１の通信端末１１が小型通信端末１と通信可能な通信端末１２、１３の端末識別子をリストに登録した場合は、そのリストに登録された端末識別子の通信端末１２、１３が通信制御サーバ２０に接続し、各々の通信端末１２、１３がユーザネーム、画像データ、ユーザ色データ等のユーザ情報をユーザＤＢ３０のリストに登録するようにすることも可能である。

また、上述する実施形態では、小型通信端末１を小学生等の子供が携帯し、第１〜第３の通信端末１１〜１３を子供と密接に関係する関係者が携帯し、子供と関係者とのコミュニケーションの向上を図ることを例に説明した。しかし、小型通信端末１を高齢者等が携帯し、第１〜第３の通信端末１１〜１３を高齢者等と密接に関係する関係者が携帯し、高齢者等と関係者とのコミュニケーションの向上を図ることも可能である。高齢者等と密接に関係する関係者としては、高齢者等の子供などがあげられる。

また、上述する実施形態では、認証部２２は、図２に示すユーザ情報を基にユーザ認証を行うようにしている。しかし、例えば、ユーザＤＢ３０に図８に示す通話可否リストのように、発信元ＩＤと発信先ＩＤとの組と、通話可否情報と、を紐付けて記憶し、発信元ＩＤと発信先ＩＤとの組と、通話可否情報と、を基にユーザ認証を行うようにすることも可能である。図８では、発信元ＩＤ、発信先ＩＤ、通話可否情報が対応付けて記憶している。発信元ＩＤは、発信元端末を一意に特定するための情報である。発信先ＩＤは、発信先端末を一意に特定するための情報である。通話可否情報は、通話の可否を特定するための情報である。通話可の場合は、通話を許可することになる（ユーザ認証ＯＫ）。通話否の場合は、通話を許可しないことになる（ユーザ認証ＮＧ）。この場合、認証部２２は、図８に示す情報を参照し、発信元ＩＤと発信先ＩＤとの組が通話可としてユーザＤＢ３０に記憶されている場合は、認証ＯＫと判定し、発信元ＩＤと発信先ＩＤとの組が通話否としてユーザＤＢ３０に記憶されていたり、発信元ＩＤと発信先ＩＤとの組がユーザＤＢ３０に記憶されていない場合に、認証ＮＧと判定することになる。

また、上述する実施形態では、小型通信端末１と、第１〜第３の通信端末１１〜１３と、の間で音声通信を行う場合について説明した。しかし、第１〜第３の通信端末１１〜１３同士で音声通信を行うことも可能である。

また、上述する実施形態では、通信端末は、MQTTを用いて制御メッセージを端末間で交換し、端末間で音声通信を行う際に必要な情報を取得する場合について説明した。しかし、MQTT以外のプロトコルであっても、メッセージキューを用いて制御メッセージを転送し、端末間で制御メッセージを交換し、端末間で音声通信を行う際に必要な情報を取得することが可能であれば、AMQP（Advanced Message Queuing Protocol）などの他のあらゆるプロトコルを用いることが可能である。

また、上述する実施形態では、ＭＱ部２３は、端末からメッセージを受信すると、端末が指定した共通MQ Keyに該当するサブスクライバーである相手端末にメッセージを転送するように説明した。ここで、ＭＱ部２３は、端末から受信したメッセージを保存しても良い。また、ＭＱ部２３が、端末から受信したメッセージを指定された共通MQ Key に対応付けて保存し、その後、相手端末が、取得した共通MQ Keyと同じ共通MQ Keyに対応付けられてＭＱ部２３に保存されているメッセージを所得するようにしてもよい。

また、上記実施形態の音声通信システムを構成する各装置における制御動作は、ハードウェア、ソフトウェア、あるいは、両者の複合構成を用いて実行することも可能である。

なお、ソフトウェアを用いて処理を実行する場合には、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれているコンピュータ内のメモリにインストールして実行させることが可能である。あるいは、各種処理が実行可能な汎用コンピュータ内のメモリにインストールして実行させることが可能である。

例えば、プログラムは、記録媒体としてのハードディスクやＲＯＭ（Read Only Memory）に予め記録しておくことが可能である。あるいは、プログラムは、リムーバブル記録媒体に一時的、あるいは、永続的に格納（記録）しておくことが可能である。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することが可能である。リムーバブル記録媒体は、磁気ディスク、半導体メモリなどの各種記録媒体があげられる。

なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールすることになる。また、ダウンロードサイトからコンピュータに無線転送することになる。また、ネットワークを介してコンピュータに有線で転送することになる。

プログラムの形態としては、クラウド等によるネット上のサーバからの利用もありえる。一部のプログラムのみをコンピュータに転送して利用する形態もありえる。

また、上記実施形態の音声通信システムを構成する各装置は、上記実施形態で説明した処理動作に従って時系列的に処理を実行するだけに限定するものでない。例えば、処理を実行する装置の処理能力、あるいは、必要に応じて並列的にあるいは個別に処理を実行するように構築することも可能である。

１ 小型通信端末
２ 制御部
３ 記憶部
４ 表示部
１１〜１３ 通信端末
１１１〜１３１ 制御部
１１２〜１３２ 記憶部
１１３〜１３３ 表示部
２０ 通信制御サーバ
２１ 制御部
２２ 認証部
２３ ＭＱ部
２４ ＰＵＳＨ通知部
３０ ユーザＤＢ
４０ ＧＣＭサーバ
ＮＷ ネットワーク

Claims (10)

1. 複数の通信端末と、前記通信端末同士の通信を制御する通信制御サーバと、を有し、
   前記通信制御サーバは、
   発信元の通信端末である発信元端末から発呼要求を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、前記発信元端末と、発信先の通信端末である発信先端末と、の間で交換する際に使用する一意のキーを生成し、該生成したキーをプッシュ通知で前記発信先端末に通知すると共に、前記発信元端末に前記キーを送信し、
   前記発信元端末及び前記発信先端末は、
   前記キーを用いて、前記制御メッセージを、前記発信元端末と前記発信先端末との間で交換し、前記発信元端末と前記発信先端末との間で音声通信を行う際に必要な情報を取得する、ことを特徴とする音声通信システム。
2. 前記通信制御サーバは、
   前記キーをプッシュ通知で前記発信先端末に通知するためのプッシュ通知依頼をプッシュ通知手段に送信し、前記プッシュ通知手段が前記キーをプッシュ通知で前記発信先端末に通知する、ことを特徴とする請求項１記載の音声通信システム。
3. 前記発信元端末及び前記発信先端末は、
   相手端末に送信する前記制御メッセージを、前記キーを用いてメッセージキューに送信し、前記メッセージキューから転送された前記制御メッセージを相手端末が取得し、前記発信元端末と前記発信先端末との間で音声通信を行う際に必要な情報を取得する、ことを特徴とする請求項１または２記載の音声通信システム。
4. 前記発信先端末は、
   前記メッセージキューからセッション開始要求を示す制御メッセージを取得した際に、他の通信端末と通話中か否か判断し、他の通信端末と通話中の場合は、通話中を示す制御メッセージを前記メッセージキューに送信する、
   こと特徴とする請求項３に記載の音声通信システム。
5. 前記発信先端末は、
   前記メッセージキューからセッション開始要求を示す制御メッセージを取得した際に、他の通信端末と通話中か否か判断し、通話中でない場合は、呼び出しの出力を開始し、呼び出し中であることを示す制御メッセージを前記メッセージキューに送信する、
   こと特徴とする請求項３または４記載の音声通信システム。
6. 前記発信元端末及び前記発信先端末は、
   パブリッシュ／サブスクライブ型のプロトコルを用いて前記制御メッセージの交換を行い、
   前記発信元端末及び前記発信先端末は、
   前記キーを前記メッセージキューに指定し、相手端末に送信する前記制御メッセージを、前記キーを指定して前記メッセージキューに送信し、
   前記メッセージキューは、
   前記制御メッセージを受信すると、指定した前記キーに該当するサブスクライバーである相手端末に前記制御メッセージを転送し、前記メッセージキューから転送された前記制御メッセージを相手端末が取得する、ことを特徴とする請求項３から５の何れか１項に記載の音声通信システム。
7. 通信端末同士の通信を制御する通信制御サーバであって、
   発信元の通信端末である発信元端末から発呼要求を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、前記発信元端末と、発信先の通信端末である発信先端末と、の間で交換する際に使用する一意のキーを生成し、該生成したキーをプッシュ通知で前記発信先端末に通知すると共に、前記発信元端末に前記キーを送信する、ことを特徴とする通信制御サーバ。
8. 音声通信のセッションを確立するための制御メッセージを、発信元の通信端末である発信元端末と、発信先の通信端末である発信先端末と、の間で交換する際に使用する一意のキーをプッシュ通知で通知された際に、前記キーを取得し、前記キーを用いて、前記制御メッセージを、前記発信元端末と前記発信先端末との間で交換し、前記発信元端末と前記発信先端末との間で音声通信を行う際に必要な情報を取得する、ことを特徴とする通信端末。
9. 発信元の通信端末である発信元端末から発呼要求を受け付けた場合に、音声通信のセッションを確立するための制御メッセージを、前記発信元端末と、発信先の通信端末である発信先端末と、の間で交換する際に使用する一意のキーを生成する処理と、
   該生成したキーをプッシュ通知で前記発信先端末に通知すると共に、前記発信元端末に前記キーを送信する処理と、をコンピュータに実行させることを特徴とするプログラム。
10. 音声通信のセッションを確立するための制御メッセージを、発信元の通信端末である発信元端末と、発信先の通信端末である発信先端末と、の間で交換する際に使用する一意のキーをプッシュ通知で通知された際に、前記キーを取得する処理と、
    前記キーを用いて、前記制御メッセージを、前記発信元端末と前記発信先端末との間で交換し、前記発信元端末と前記発信先端末との間で音声通信を行う際に必要な情報を取得する処理と、をコンピュータに実行させることを特徴とするプログラム。

Images