(57)【要約】【課題】  予め定めたサービスの利用料金形態に従い、利用状況に合わせてサービス利用者に請求する料金を管理すること。【解決手段】  接続元となるユーザ端末Ａ２ａは、通話時に専用の３ＰＣＣ連携アプリケーション３の操作により、３ＰＣＣ連携サーバ１に３ＰＣＣによる通話開始を要求する。３ＰＣＣ連携サーバ１は、これから通話を行う二者の３ＰＣＣ連携アプリケーション３から受信する通話可否状態に基づき３ＰＣＣを開始する。通話可否状態は、３ＰＣＣ連携アプリケーション３が有する通話可否判定テーブル従って、端末の各種状態によって判断される。また、３ＰＣＣ連携サーバ１は、ＩＰ電話サービスプロバイダＮ２ａ、Ｎ２ｂからの通話料金を記憶するテーブルを有することで、３ＰＣＣサービス利用者の利用状況に合わせてサービス利用者に料金を請求する。【選択図】  図８
2016103706.tif 000002
【特許請求の範囲】
【請求項１】
通信システムであって、
第１の端末の第１のサービスプロバイダと、
第２の端末の第２のサービスプロバイダと、
前記第１のサービスプロバイダと前記第２のサービスプロバイダに接続されるサーバと
を備え、
前記サーバは、
制御部と、
通話毎に、前記サーバから見た通話相手または発呼先の電話番号と、通話料金とを有する請求金額情報を記憶する請求金額テーブルと、
端末毎に請求する金額を合計金額テーブルと、
を有し、
前記第１の端末と前記第２の端末とが通話中のときに前記第１の端末が通話を切断すると、前記第１のサービスプロバイダは、第１の通話料金を含む第１のメッセージを前記サーバに送信し、
前記サーバの前記制御部は、前記第１の通話料金および前記サーバから見た通話相手または発呼先である前記第１の端末の電話番号を前記請求金額テーブルに記憶し、前記第２のサービスプロバイダを介して前記第２の端末に対して第２のメッセージを送信し、
前記第２のサービスプロバイダは、前記第２の端末からの応答により、第２の通話料金を含む第３のメッセージを前記サーバに送信し、
前記サーバの前記制御部は、前記第２の通話料金および前記サーバから見た通話相手または発呼先である前記第２の端末の電話番号を前記請求金額テーブルに記憶し、前記第１のサービスプロバイダを介して前記第１の端末に対して第４のメッセージを送信して、前記第１の端末と前記第２の端末との間の通話を終了し、
前記サーバの前記制御部は、前記請求金額テーブルを参照し、前記第１の通話料金と前記第２の通話料金との合計金額を、予め定められた前記第１の端末または前記第２の端末を請求先として求め、または、前記第１の端末と前記第２の端末に予め定められた割合で割り当てた割当て金額を、前記第１の端末および前記第２の端末を請求先として求め、端末毎に前記合計金額または前記割当て金額を前記合計金額テーブルに記憶する
通信システム。
【請求項２】
請求項１に記載の通信システムであって、
前記請求金額テーブルの請求金額情報は、さらに、通話開始時刻、通話終了時刻を含み、
前記サーバの前記制御部は、前記第１のサービスプロバイダまたは前記第２のサービスプロバイダから受信した前記第１のメッセージおよび／または前記第３のメッセージに含まれる通話開始時刻、通話終了時刻を、さらに前記請求金額テーブルに記憶すること、
または、
前記サーバの前記制御部は、前記第１のサービスプロバイダまたは前記第２のサービスプロバイダから受信した前記第１のメッセージまたは前記第３のメッセージに、通話開始時刻、通話終了時刻が設定されていない場合は、通話が開始された時刻またはセッション確立の確認を示すメッセージの受信時刻、通話の終了した時刻または前記第１のメッセージを受信した時刻を、さらに前記請求金額テーブルに記憶すること、
を特徴とする通信システム。
【請求項３】
請求項１に記載の通信システムであって、
前記サーバの前記制御部は、接続元の前記第１の端末の通話開始により、接続先の前記第２の端末の電話番号と前記第１の端末の電話番号を受信すると、接続先の前記第２の端末に対して通話状態を問合せ、前記第２の端末から通話状態を受信し、
前記サーバの前記制御部は、接続元の前記第１の端末に対して通話状態を問合せ、前記第１の端末から通話状態を受信し、
前記サーバの前記制御部は、接続元の前記第１の端末と接続先の前記第２の端末の両端末の通話状態が「空き」であった場合には、接続元と接続先の２者間の接続制御を開始する
ことを特徴とする通信システム。
【請求項４】
請求項３に記載の通信システムであって、
前記サーバの前記制御部は、
接続元の前記第１の端末と接続先の前記第２の端末が通話可能状態であることを確認し、２者間の前記接続制御を開始すると、
前記サーバと接続先の前記第２の端末とのセッション確立し、
前記サーバと接続元の前記第１の端末とのセッション確立し、
接続元の前記第１の端末と接続先の前記第２の端末間で通話を開始する
ことを特徴とする通信システム。
【請求項５】
請求項３に記載の通信システムであって、
前記第１の端末および前記第２の端末は、
通話状態情報、表示状態情報、操作情報、センサ情報のいずれかひとつまたは複数を含む条件に対して、通話可能判定を記憶した通話可否判定テーブルを備え、
前記通話可否判定テーブルを参照して、通話可否を判定し、前記サーバに通話状態を通知し、
前記サーバの前記制御部は、
接続元電話番号と、接続先電話番号と、前記第１の端末および前記第２の端末からの前記通知による接続元通話状態および接続先通話状態とを対応付けて記憶する監視端末情報テーブルを備え、
接続元電話番号と、接続先電話番号と、接続元通話状態と、接続先通話状態を前記監視端末状態テーブルに記憶し、前記監視端末情報テーブルを参照した結果により、前記第２の端末間で通話を開始する
ことを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに係り、特に、一般的な公衆網上の電話利用に対する利便性の高い電話システム、サーバ、電話端末および／またはアプリケーション等を含む通信システムに関する。
【背景技術】
【０００２】
公衆網上に配置された交換装置による電話機間での通信では、発信者の電話機から発呼された呼出信号を着信者の電話機が着信可能な場合にだけ、両者の電話機が接続され通信が開始されるようになっており、着信者が話中であった場合、発信者側は再度問い合わせを行う必要がある。
【０００３】
このため、着信者の電話機が話中や無応答である場合には、発信者は、通常は、再発呼する必要がある。このときの再発呼操作の負担を軽減するため、自動登録によって着信者の電話機から発信者の電話機へ呼び返しをする機能が利用されている。  
【０００４】
ＮＴＴ東日本／西日本が提供する「空いたらお知らせ１５９」サービス（Ｈｔｔｐ：／／ｗｗｗ．ｎｔｔ−ｅａｓｔ．ｃｏ．ｊｐ／ｓｈｏｐ／ａｎｎａｉ／１５９−ｋ．ｈｔｍｌ）は、着信者の電話機が着信可能となったときに、その旨を発信者に通知するものであり、発信者はこのサービスを受けるために発呼毎に登録操作をしなければならず、また通知を受けた後は再発呼する必要があり操作負担をまねく場合があった。また、再発呼した場合であっても、その再発呼したタイミングでは、着信不可能となっている場合や、着信出来たとしても電話機の近くに人が居らず、結局通話が出来ない可能性も否定は出来ない。
【０００５】
そこで、折り返し電話サービスシステムでは、発信者に対して再発呼操作を不要にする技術が開示されている（例えば、特許文献１）。
【０００６】
また、通話する二者と異なる第三者が発呼することにより二者間の接続を可能とする技術として、３ＰＣＣ（３ｒｄ    Ｐａｒｔｙ  Ｃａｌｌ  Ｃｏｎｔｒｏｌ）がある（例えば、特許文献２）。３ＰＣＣでは、第三者となる３ＰＣＣサーバが通話する二者に対して発呼する。二者間を接続する際、３ＰＣＣサーバと一者目の接続が完了してから、３ＰＣＣサーバと二者目の接続を行うようにする事が出来るため、３ＰＣＣサーバと二者目の接続を行う際には、必ず一者目の接続が完了しており、再発呼操作の手間を軽減する事が可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−３０５５９５号公報
【特許文献２】特開２０１０−２１３０２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述の「空いたらお知らせ１５９」サービスや折り返し電話サービスなどを利用する場合でも、接続可能かどうかは最初に発呼してみるまで分からないという課題がある。
また、３ＰＣＣでは、第三者である３ＰＣＣサーバが各サービスプロバイダを介して、通話する二者に対してそれぞれ発呼するため、一つの通話に対して各サービスプロバイダ毎の通話料金（例えば、二倍の通話料金）がかかり、その通話料金は、例えばＳＩＰサーバを保有しているサービスプロバイダのそれぞれの側に請求される。そこで、発呼側と着呼側の各サービスプロバイダによる別々の通話料金が発生し、本来通話を依頼した第三者である３ＰＣＣサーバに対してかかった通話料金を的確に請求出来ない場合があるという課題がある。特許文献２は、その点に関して考慮されていない。
本発明は、以上の点に鑑み、予め定めたサービスの利用料金形態に従い、利用状況に合わせてサービス利用者に請求する料金を管理することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の解決手段によると、
通信システムであって、
第１の端末の第１のサービスプロバイダと、
第２の端末の第２のサービスプロバイダと、
前記第１のサービスプロバイダと前記第２のサービスプロバイダに接続されるサーバと
を備え、
前記サーバは、
制御部と、
通話毎に、前記サーバから見た通話相手または発呼先の電話番号と、通話料金とを有する請求金額情報を記憶する請求金額テーブルと、
端末毎に請求する金額を合計金額テーブルと、
を有し、
前記第１の端末と前記第２の端末とが通話中のときに前記第１の端末が通話を切断すると、前記第１のサービスプロバイダは、第１の通話料金を含む第１のメッセージを前記サーバに送信し、
前記サーバの前記制御部は、前記第１の通話料金および前記サーバから見た通話相手または発呼先である前記第１の端末の電話番号を前記請求金額テーブルに記憶し、前記第２のサービスプロバイダを介して前記第２の端末に対して第２のメッセージを送信し、
前記第２のサービスプロバイダは、前記第２の端末からの応答により、第２の通話料金を含む第３のメッセージを前記サーバに送信し、
前記サーバの前記制御部は、前記第２の通話料金および前記サーバから見た通話相手または発呼先である前記第２の端末の電話番号を前記請求金額テーブルに記憶し、前記第１のサービスプロバイダを介して前記第１の端末に対して第４のメッセージを送信して、前記第１の端末と前記第２の端末との間の通話を終了し、
前記サーバの前記制御部は、前記請求金額テーブルを参照し、前記第１の通話料金と前記第２の通話料金との合計金額を、予め定められた前記第１の端末または前記第２の端末を請求先として求め、または、前記第１の端末と前記第２の端末に予め定められた割合で割り当てた割当て金額を、前記第１の端末および前記第２の端末を請求先として求め、端末毎に前記合計金額または前記割当て金額を前記合計金額テーブルに記憶する
通信システムが提供される。
【発明の効果】
【００１０】
本発明によると、予め定めたサービスの利用料金形態に従い、利用状況に合わせてサービス利用者に請求する料金を管理することができる。
【図面の簡単な説明】
【００１１】
【図１】本システムの構成例を示す説明図である。
【図２】３ＰＣＣ連携サーバ１の構成例を示す説明図である。
【図３】監視端末情報テーブル１１１１の構成例を示す説明図である。
【図４】請求金額テーブル１１０６の構成例を示す説明図である。
【図５】端末Ａ２ａおよび端末Ｂ２ｂの構成例を示す説明図である。
【図６】通話状態テーブル２０１２の構成例を示す説明図である。
【図７−１】端末Ａ２ａおよび端末Ｂ２ｂの状態監視の方法を説明するフローチャートである。
【図７−２】３ＰＣＣサービス開始の動作を説明するシーケンス図である。
【図８】３ＰＣＣサービスにおける通話料金請求を説明する説明図である。
【図９−１】通話可否判定テーブルの構成例を示す説明図（１／２）である。
【図９−２】通話可否判定テーブルの構成例を示す説明図（１／２）である。
【図１０】請求金額情報取得時の動作を説明するフロー図である。
【図１１】通話切断時の動作を説明するシーケンス図である。
【図１２】合計金額テーブル１１１２の説明図である。
【発明を実施するための形態】
【００１２】
Ａ．概要
接続元となるユーザは、通話時に専用の３ＰＣＣ連携アプリケーションの操作により、３ＰＣＣ連携サーバに３ＰＣＣによる通話開始を要求する。３ＰＣＣ連携サーバは、これから通話を行う二者の３ＰＣＣ連携アプリケーションから受信する通話可否状態に基づき３ＰＣＣを開始する。通話可否状態は、３ＰＣＣ連携アプリケーションが有する通話可否判定テーブルに従って、端末の各種状態によって判断される。
また、３ＰＣＣ連携サーバは、ＩＰ電話サービスプロバイダからの通話料金を記憶するテーブルを有することで、３ＰＣＣサービス利用者の利用状況に合わせてサービス利用者に料金を請求する。
【００１３】
Ｂ．実施の形態
図１は、第１の実施の形態の通信網の構成例を示す説明図である。
本システムは、例えば、３ＰＣＣ連携サーバ１、端末Ａ２ａ、端末Ｂ２ｂ、ＩＰ電話サービスプロバイダーＮ２ａおよびＩＰ電話サービスプロバイダーＮ２ｂとを備える。３ＰＣＣ連携サーバ１は、例えば、インターネット  Ｎ１に設置される。３ＰＣＣ連携アプリケーション３ａおよび３ＰＣＣ連携アプリケーション３ｂ（以下、総称として３ＰＣＣ連携アプリケーション３と呼ぶ場合がある。）は、例えば、端末Ａ２ａおよび端末Ｂ２ｂにそれぞれインストールされる。端末Ａ２ａはＩＰ電話サービスプロバイダＮ２ａおよびインターネットＮ１を介して３ＰＣＣ連携サーバ１に接続する。同様に、端末Ｂ２ｂはＩＰ電話サービスプロバイダＮ２ｂおよびインターネットＮ１を介して３ＰＣＣ連携サーバ１に接続する。ここで、ＩＰ電話サービスプロバイダＮ２ａとＩＰ電話サービスプロバイダＮ２ｂは、同じＩＰ電話サービスプロバイダであっても良い。勿論、３ＰＣＣ連携サーバ１がインターネット  Ｎ１に接続する際に、インターネット・サービス・プロバイダ経由で接続する場合もありえる。また、端末Ａ２ａは、後述する実施の形態では、一例として通話を要求する側であり、且つ最終的には二者間通話を行う一端末であるが、通話を要求する側の端末と、二者間通話を行う一端末に分離して、２つの端末で構成しても良い。つまり、通話を要求する機能と、二者間通話を行う一端末の通話機能を分離して、２つの端末として構成してもよい。また、通常ＩＰ電話サービスプロバイダはそのシステムの中にＳＩＰサーバを有しており、そのＳＩＰサーバを介してＩＰ電話サービスを実施しているが、その構成やシーケンスは公知または周知のものを使用することができ、後述の説明では省略している。
【００１４】
図２は、３ＰＣＣ連携サーバ１の構成例を示す説明図である。
【００１５】
３ＰＣＣ連携サーバ１は、例えば、プロセッサ（以下、ＣＰＵ）１００１とインタフェース（以下、ＩＦ）１００３ａおよび１００３ｂと、メモリ１００４を備える。メモリ１００４は、３ＰＣＣ連携サーバ制御部  １１０１と、３ＰＣＣモジュール部１１０２と、空き情報取得モジュール部１１０３と、メディアストリーム制御部１１０４と、ＳＩＰ制御部１１０５と、請求金額テーブル１１０６とを有する。ここで、３ＰＣＣ連携サーバ制御部  １１０１は３ＰＣＣ連携サーバ１上で本実施の形態の全体の制御行う構成、３ＰＣＣモジュール部１１０２は３ＰＣＣ連携サーバ制御部  １１０１の指示によりＳＩＰ制御部１１０５に対して３ＰＣＣの通信制御を行う構成、メディアストリーム制御部１１０４はＳＩＰのセッション制御でセッション確立（呼の確立）後に２つの端末と３ＰＣＣ連携サーバ１の間の音声や画像のメディアストリームを仲介する構成、ＳＩＰ制御部１１０５は一般にＳＩＰサーバと呼ばれＳＩＰを使って２つの端末と３ＰＣＣ連携サーバ１の間のセッションを確立する構成、をそれぞれ備える。空き情報取得モジュール部１１０３は、監視端末情報テーブル１１１１、合計金額テーブル１１１２を有する。空き情報取得モジュール部１１０３は、端末から空き情報を取得し、監視端末情報テーブル１１１１の接続元通話状態（後述図３、１１２４）と、接続先通話状態（後述図３、１１２５）を設定する。請求金額テーブル１１０６は、通話終了時にＩＰ電話サービスプロバイダからの請求金額を記憶する構成である（後述図４）。ＩＦ  １００３ａ／ｂは、回線１００２ａ／ｂを介してインターネットＮ１と通信するためのインタフェースである。ここで、３ＰＣＣモジュール部１１０２、メディアストリーム制御部１１０４、ＳＩＰ制御部１１０５は、他の構成と物理的に分離された別サーバまたは制御部として、または、それぞれの構成が適当に組み合わされた別サーバや制御部または一体型サーバや制御部として、構成されてもよい。
【００１６】
図４は、請求金額テーブル１１０６の構成例を示す説明図である。
【００１７】
請求金額テーブル１１０６は、通話開始時刻４００１と、通話終了時刻４００２と、発呼先４００３と、通話料金４００４とを有する請求金額情報を記憶する。例えば、ひとつの通話に対して、１列目に３ＰＣＣ連携サーバ１と発呼元端末との間の請求金額情報が記憶され、２列目に３ＰＣＣ連携サーバ１と発呼先端末との間の請求金額情報が記憶される。このテーブルに、通話開始時刻４００１として通話が開始された時刻（後述のＳＩＰ（２００  ＯＫ  ＡｏｒＢ）の受信時刻）、通話終了時刻４００２として通話の終了した時刻（ＳＩＰ（ＢＹＥ）を受信した時刻）、発呼先４００３として３ＰＣＣ連携サーバ１が発呼した先の電話番号と、通話料金４００４としてＩＰ電話サービスプロバイダＮ２ａまたはＩＰ電話サービスプロバイダＮ２ｂから請求された通話料金が記録される。ここで、通話開始時刻４００１と、通話終了時刻４００２とは、ＳＩＰセッションの終了メッセージＢＹＥに通話が開始された時刻、通話の終了した時刻が含まれている場合は、その情報を設定しても良い。
【００１８】
図３は、監視端末情報テーブル１１１１の構成例を示す説明図である。
【００１９】
監視端末情報テーブル１１１１は、接続元端末および接続先端末に関するパラメータが記憶される。監視端末情報は、例えば、ＩＤ  １１２１と、接続元電話番号１１２２と、接続先電話番号１１２３と、接続元通話状態１１２４と、接続先通話状態１１２５と、問合せ回数１１２６を含む。例えば、接続元通話状態１１２４と、接続先通話状態１１２５は、通話状態として、空き、話中の状態を保持する。
【００２０】
図５は、端末Ａ２ａおよび端末Ｂ２ｂの構成例を示す説明図である。
【００２１】
端末Ａ２ａおよび端末Ｂ２ｂは、例えば３ＰＣＣ連携アプリケーション３と、表示部２００２と、ＳＩＰ制御部２００３と、通信インタフェース（以下、通信ＩＦ）２００４と、操作部２００５と、センサ部２００６を有する。３ＰＣＣ連携アプリケーション３は、３ＰＣＣ連携アプリケーション制御部２０１１と、通話状態テーブル２０１２と、通話可否判定テーブル２０１３とを有する。３ＰＣＣ連携アプリケーション制御部２０１１は、本実施の形態の端末側の全体制御を行う構成であり、ＳＩＰ制御部２００３を制御してＳＩＰの通信を行うと共に、通話状態情報、操作情報、センサ部２００６の情報等に応じて通話可否判定を行い、通話状態テーブル２０１２を更新する。操作部２００５は、ユーザが操作するマンマシンインタフェースを有する（例えば、タッチセンサ２０２１と、物理スイッチ２０２２等）。センサ部２００６は、ユーザや端末内部、端末周辺の情報を取得するセンサを有する（例えば、画像センサ（カメラ）２０３１と、マイク２０３２と、温度センサ２０３３と、加速度センサ２０３４等）。
【００２２】
図６は、通話状態テーブル２０１２の構成例を示す説明図である。
【００２３】
通話状態テーブル２０１２は、端末の通話状態に関するパラメータが記憶される。このパラメータとしては、例えば、通話状態２１０１のように、空き、話中の状態が記憶される。
【００２４】
図７−１および図７−２は、本実施の形態の動作を説明するフローチャートである。
【００２５】
以下、図７−１および図７−２に従って本実施の形態の手順を説明する。
【００２６】
図７−１および図７−２は、第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図である。
【００２７】
３ＰＣＣ連携アプリケーションによる３ＰＣＣサービスまでの流れは、以下の（ａ）〜（ｄ）となる。
（ａ）接続元端末Ａ２ａと接続先端末Ｂ２ｂが通話可能状態であることを確認。
（ｂ）３ＰＣＣ連携サーバ１と接続先端末Ｂ２ｂとのセッション確立。
（ｃ）３ＰＣＣ連携サーバ１と接続元端末Ａ２ａとのセッション確立。
（ｄ）接続元端末Ａ２ａと接続先端末Ｂ２ｂ間で通話。
【００２８】
以下、シーケンス図およびフローチャートに従って本実施の形態の手順を説明する。ここで、３ＰＣＣ連携サーバ１の処理フローは主に３ＰＣＣ連携サーバ制御部  １１０１で処理され、接続元端末Ａ２ａと接続先端末Ｂ２ｂの処理フローは、３ＰＣＣ連携アプリケーション制御部２０１１で処理される。
【００２９】
接続元のユーザは、端末Ａ２ａにインストールされた３ＰＣＣ連携アプリケーション３を操作し、接続先となる端末Ｂ２ｂを指定して通話開始ボタンを押下することにより、３ＰＣＣ連携サーバ１に３ＰＣＣの開始が依頼される。その後、図７−１に従い、接続先端末Ｂ２ｂと接続元端末Ａ２ａの通話可能状態が監視される。接続先端末Ｂ２ｂと接続元端末Ａ２ａがいずれも通話可能であった場合、図７−２に従い、３ＰＣＣによる通話が開始される。
【００３０】
通話開始ボタン押下（３００１）により、３ＰＣＣ連携サーバ１に対して接続先端末Ｂ２ｂの電話番号と接続元端末Ａ２ａの電話番号が送信される（３００２）。３ＰＣＣ連携サーバ１は、この３ＰＣＣ接続に対し、予め定められた手順（例えば、シーケンシャル、ランダム等）によりＩＤを発行し、ＩＤおよび接続先端末Ｂ２ｂの電話番号と接続元端末Ａ２ａの電話番号を監視端末情報テーブル１１１１に記憶する（３００３）。
【００３１】
続いて、３ＰＣＣ連携サーバ１は、接続先端末Ｂ２ｂに対して通話状態を問合せる（３００４）。通話状態問い合わせを受信した接続先端末Ｂ２ｂは通話可否判定テーブル２０１３に従って自端末の通話状態を取得し、３ＰＣＣ連携サーバ１に対して通話状態を応答する（３００５、３００６、３００７）。なお、通話可否判定テーブル２０１３は、通話状態情報、操作情報、センサ情報等に応じて通話可否を判定するためのテーブルであり、詳細は後述する。３ＰＣＣ連携サーバ１は、受信した通話状態を監視端末情報テーブル１１１１の接続先通話状態（１１２３）に記憶する（３００８）。
【００３２】
同様にして、３ＰＣＣ連携サーバ１は、接続先端末Ａ２ａに対して通話状態を問合せる（３００９）。通話状態問い合わせを受信した接続元端末Ｂ２ｂは、通話可否判定テーブル２０１３に従って自端末の通話状態を取得し、３ＰＣＣ連携サーバ１に対して通話状態を応答する（３０１０、３０１１、３０１２）。３ＰＣＣサーバ１は、受信した通話状態を監視端末情報テーブル１１１１の接続元通話状態（１１２４）部に記憶する（３０１３）。
【００３３】
接続元端末Ａ２ａと接続先端末Ａ２ｂの両方の通話状態が「空き」であった場合には（３０１４）、３ＰＣＣ連携サーバ制御部１１０１は、接続元と接続先の２者間の３ＰＣＣ制御を実施する。例えば、自身に対してＳＯＡＰ（ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（接続元，接続先））を送信することによる接続要求を実施してもよい。一方、いずれかの通話状態が「空き」でなかった場合（３０１４）、３ＰＣＣ連携サーバ制御部１１０１は、処理３００４に戻って処理を実行する。
【００３４】
つぎに、図７−２を参照して説明する。
３ＰＣＣを開始後、３ＰＣＣ連携サーバ制御部１１０１は、端末Ｂ２ｂに対する発信要求（Ｂ）をＳＩＰ制御部１１０５に送信する（Ｓ１−１）。
【００３５】
ＳＩＰ制御部１１０５は、発信要求（Ｂ）に含まれるＴｏ  ＵＲＩに従い、ＩＮＶＩＴＥメッセージ（Ｂ）を端末Ｂ２ｂに送信する（Ｓ１−２）。端末Ｂ２ｂは、ＩＮＶＩＴＥメッセージ（Ｂ）を受信し、受信したＩＮＶＩＴＥメッセージ（Ｂ）のｓｅｎｄ  ＳＤＰ情報に含まれる３ＰＣＣ連携サーバ１のＩＰアドレスとポート番号を適宜の記憶部に記憶する。記憶されたＩＰアドレスとポート番号は、例えばメディアストリームの送信の際に用いられる。また、端末Ｂ２ｂは、自身のＩＰアドレスとポート番号を含むｒｅｃｖ  ＳＤＰ情報を生成し、生成したＳＤＰ情報を含むＳＩＰの２００  ＯＫ（Ｂ）を３ＰＣＣ連携サーバ１に送信する（Ｓ１−３）。３ＰＣＣ連携サーバ１のＳＩＰ制御部１１０５は、２００  ＯＫ（Ｂ）を受信し、ＳＩＰのＡＣＫ（Ｂ）を端末Ｂ２ｂに送信する（Ｓ１−４）。
【００３６】
ＳＩＰ制御部１１０５は、応答通知（Ｂ）を３ＰＣＣ連携サーバ制御部１１０１および／またはＰＣＣモジュール部１１０２に送信する（Ｓ１−５）。
【００３７】
また、３ＰＣＣモジュール部１１０２は、生成したｓｅｓｓｉｏｎＩＤと、３ＰＣＣ連携サーバ１のＩＰアドレスおよびポート番号と、受信したｒｅｃｖ  ＳＤＰ情報に含まれる端末Ｂ２ｂのＩＰアドレスおよびポート番号とをメディアストリーム制御部１１０４に送信する。
【００３８】
さらに、３ＰＣＣモジュール部１１０２は、擬似ＲＢＴ送信要求をメディアストリーム制御部１１０４に送信する（Ｓ２）。メディアストリーム制御部１１０４は、擬似ＲＢＴ送信要求を受信すると、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）に従い、擬似ＲＢＴを端末Ｂ２ｂに送信する（Ｓ３）。メディアストリーム制御部（１１０４）は、例えば相手を呼び出し中である旨のアナウンスや適宜の音楽等を擬似ＲＢＴとして用いてもよい。本実施の形態では、端末Ｂ２ｂとのセッションの確立が完了し、端末Ａ２ａとのセッションの確立を開始している段階で、端末Ｂ２ｂが無音状態となることを防ぐ。なお、この擬似ＲＢＴは、後述する停止要求があるまで送信し続けることができる。
【００３９】
次に、３ＰＣＣ連携サーバ１は、端末Ａ２ａとのセッションを確立する。
【００４０】
３ＰＣＣ連携サーバ制御部１１０１は、端末Ａ２ａに対する発信要求（Ａ）をＳＩＰ制御部１１０５に送信する（Ｓ４−１）。
【００４１】
ＳＩＰ制御部１１０５は、発信要求（Ａ）に含まれるＴｏ  ＵＲＩに従い、ＩＮＶＩＴＥメッセージ（Ａ）を端末Ａ２ａに送信する（Ｓ４−２）。
【００４２】
端末Ａ２ａは、ＩＮＶＩＴＥメッセージ（Ａ）を受信し、受信したＩＮＶＩＴＥメッセージ（Ａ）のｓｅｎｄ  ＳＤＰ情報に含まれる３ＰＣＣ連携サーバ１のＩＰアドレスとポート番号を適宜の記憶部に記憶する。また、端末Ａ２ａは、自身のＩＰアドレスとポート番号を含むｒｅｃｖ  ＳＤＰ情報を生成し、生成したｒｅｃｖ  ＳＤＰ情報を含む２００  ＯＫ（Ａ）を３ＰＣＣ連携サーバ１に送信する（４−３）。３ＰＣＣ連携サーバ１のＳＩＰ制御部１１０５は、２００  ＯＫ（Ａ）を受信し、ＡＣＫ（Ａ）を端末Ａ２ａに送信する（Ｓ４−４）。
【００４３】
ＳＩＰ制御部１１０５は、応答通知（Ａ）を３ＰＣＣ連携サーバ制御部１１０１および／または３ＰＣＣモジュール部１１０２に送信する（Ｓ４−５）。
【００４４】
３ＰＣＣモジュール部１１０２は、擬似ＲＢＴ停止要求をメディアストリーム制御部１１０４に送信する（Ｓ５）。メディアストリーム制御部１１０４は、擬似ＲＢＴ停止要求に従い擬似ＲＢＴの送信を停止する。
【００４５】
３ＰＣＣ連携サーバ１は、端末Ｂ２ｂと端末Ａ２ａとの間でメディアストリーム転送を開始する（Ｓ６〜Ｓ９）。
【００４６】
図８および図１１は、３ＰＣＣサービスにおける通話料金請求の例を示す説明図およびシーケンス図である。
【００４７】
例えば、端末Ａ２ａと端末Ｂ２ｂが３ＰＣＣサービスによる通話中から、端末Ａ２ａが通話を切断すると、ＩＰ電話サービスプロバイダＮ２ａに対してＳＩＰのＢＹＥメッセージが送信される（Ｓ１０）。その後、ＩＰ電話サービスプロバイダＮ２ａは、通話料金情報を生成し、例えば、通話開始時刻、通話終了時刻、通話料金情報を含んだＳＩＰのＢＹＥメッセージを３ＰＣＣ連携サーバ１に送信する（Ｓ１１）。
３ＰＣＣ連携サーバ１のＳＩＰ制御部１１０５は、ＢＹＥメッセージを受信すると、３ＰＣＣ連携サーバ制御部１１０１に対し、請求金額情報取得要求を送信する（Ｓ１２）。３ＰＣＣ連携サーバ制御部１１０１は、ＳＩＰ制御部１１０５が受信した通話開始時刻、通話終了時刻、通話料金情報および３ＰＣＣ連携サーバ１から見た通話相手（発呼先）の電話番号（この例では、端末Ｂ２ｂの電話番号）を請求金額テーブル１１０６に記憶する。ここで、通話開始時刻、通話終了時刻がＢＹＥメッセージに設定されていない場合は、通話が開始された時刻（前述のＳＩＰ（２００  ＯＫ  ＡｏｒＢ）の受信時刻）、通話の終了した時刻（ＳＩＰ（ＢＹＥ）を受信した時刻）を設定するようにしてもよい。
【００４８】
続けて、ＳＩＰ制御部１１０５は、ＩＰ電話サービスプロバイダＮ２ｂに対して、例えば、通話開始時刻、通話終了時刻、通話料金情報を含んだＳＩＰのＢＹＥメッセージを送信する（Ｓ１３）。その後、ＩＰ電話サービスプロバイダＮ２ｂは、端末Ｂ２ｂに対してＳＩＰのＢＹＥメッセージを送信する（Ｓ１４）。端末Ｂ２ｂは、ＩＰ電話サービスプロバイダＮ２ｂに対してＳＩＰの２００  ＯＫメッセージを送信する（Ｓ１５）。その後、ＩＰ電話サービスプロバイダＮ２ｂは、例えば、通話開始時刻、通話終了時刻、通話料金情報を含んだＳＩＰの２００  ＯＫメッセージを３ＰＣＣ連携サーバ１に送信する（Ｓ１６）。３ＰＣＣ連携サーバ１のＳＩＰ制御部１１０５は、２００  ＯＫメッセージを受信すると、３ＰＣＣ連携サーバ制御部１１０１に対し、請求金額情報取得要求を送信する（Ｓ１７）。
【００４９】
つぎに、ＳＩＰ制御部１１０５は、ＢＹＥメッセージを受信するとＩＰ電話サービスプロバイダＮ２ａに対してＳＩＰの２００  ＯＫメッセージを送信する（Ｓ１８）。その後、ＩＰ電話サービスプロバイダＮ２ａは、端末Ａ２ａに対してＳＩＰの２００  ＯＫメッセージを送信し、通話終了となる（Ｓ１９）。
【００５０】
図１０は、請求金額情報取得時の動作を説明するフロー図である。
３ＰＣＣ連携サーバ制御部１１０１は、通話開始時刻、通話終了時刻、通話料金情報がＢＹＥメッセージまたは２００  ＯＫメッセージに設定されている場合（３１０２：ＹＥＳ）、ＳＩＰ制御部１１０５からの請求金額情報取得要求を受信すると、請求金額情報取得要求の契機となったＳＩＰメッセージより請求金額情報を抽出する（３１０３）。ＳＩＰ３ＰＣＣ連携サーバ制御部１１０１は、受信した通話開始時刻、通話終了時刻、通話料金情報および３ＰＣＣ連携サーバ１から見た通話相手（発呼先）の電話番号を含む請求金額情報を請求金額テーブル１１０６に記憶する（３１０６）。ここで「通話相手（発呼先）」とは、上述の例では、図１１、Ｓ１２に対しては接続元端末Ａ２ａ、図１１、Ｓ１７に対しては接続先端末Ｂ２ｂである。一方、通話開始時刻、通話終了時刻がＢＹＥメッセージに設定されていない場合は（３１０２：Ｎｏ）、３ＰＣＣ連携サーバ制御部１１０１は、通話が開始された時刻（前述のＳＩＰ（２００  ＯＫ  ＡｏｒＢ）の受信時刻）、通話の終了した時刻（ＳＩＰ（ＢＹＥ）を受信した時刻）を設定し、通話料金を算出する（例えば通話開始時刻と通話終了時刻から通話料金を算出してもよい）（３１０４、３１０５）。その後、３ＰＣＣ連携サーバ制御部１１０１は、取得した請求金額情報を請求金額テーブル１１０６に記憶する（３１０６）。
【００５１】
３ＰＣＣサービスでは一つの通話に対して二つの発呼が生じるため、上記のように、ＳＩＰ制御部１１０５を有する３ＰＣＣ連携サーバ１の所有者に二通話分の通話料が請求されてしまう課題がある。
【００５２】
そこで、第一の実施の形態では、３ＰＣＣサービスを利用する端末毎に、請求金額テーブル１１０６によって請求金額を管理する。例えば、毎月の３ＰＣＣサービスを利用した通話の通話料と３ＰＣＣサービス基本料を端末の所有者に請求する事が可能となる。
３ＰＣＣ連携サーバ制御部１１０１は、請求金額テーブル１１０６を参照して、ひとつの通話に対する請求先と請求合計額を求める（３１０７）。さらに、３ＰＣＣ連携サーバ制御部１１０１は、ひとつの通話に対する各端末（請求先電話番号）と請求合計額を合計金額テーブル１１１２に加算および／または記憶する。
【００５３】
図１２は、合計金額テーブル１１１２の説明図である。
３ＰＣＣ連携サーバ１は、３ＰＣＣ連携サーバ制御部１１０１により請求金額テーブル１１０６を参照して、ひとつの通話に対する、２つの発呼（列）の合計や、接続元毎の合計や接続先毎の合計などの予め定めた計算により請求合計額を求め、請求合計額を予め定められた請求先（端末電話番号）に請求したり、予め定めた割合で複数の請求先（端末電話番号）に請求することができる。請求合計額を接続元に請求するか、接続先に請求するか、両者で折半・分配するかは予め定められたサービスの設定次第とすることができる。すなわち、一例としては、図４の請求金額テーブル１１０６のように、ひとつの通話に対して接続先の端末（例、端末Ａ２ａ、端末Ｂ２ｂ）ごとに、２つの通話が各列に対応して記憶されている場合、３ＰＣＣ連携サーバ制御部１１０１は、その通話料金４００４を合計して（この例では、１２＋１０＝２２）、例えば接続元端末（例、端末Ａ２ａ）に請求合計額として請求するように、図１２に示したように合計金額テーブル１１１２に記憶することができる。なお、３ＰＣＣ連携サーバ制御部１１０１は、図１２に示したような合計金額テーブル１１１２を用いて、端末電話番号ごとにひとつのエントリを記憶するようにし、端末電話番号ごとに複数通話の合計金額を加算するようにしてもよい。
【００５４】
図９−１及び図９−２は、通話可否判定テーブル２０１３の構成例を示す説明図である。
【００５５】
通話可能判定テーブル２０１３は、この例では、「通話状態でないこと」９００１と、「端末およびディスプレイがスリープ状態になっていないこと」９００２と、「タッチパネルおよび物理ボタンによる入力が一定期間内に行われていること」９００３と、「加速度センサが反応していること」９００４と、「温度センサが一定以上の温度を検出していること」９００５と、「画像センサの輝度が一定以上の明るさであること」９００６と、「画像センサがユーザの顔を認識していること」９００７と、を含む条件に応じて通話可能判定９００８が予め記憶される。なお、各条件の内容や数、通話可能判定の可否等は適宜設定することができる。
【００５６】
通話可能判定９００８は、例えば、以下の（ｅ）〜（ｇ）の条件により設定される。
（ｅ）「通話状態でないこと」９００１が○、かつ、「端末およびディスプレイがスリープ状態になっていないこと」９００２と「タッチパネルおよび物理ボタンによる入力が一定期間内に行われていること」９００３が○であれば、通話可能判定は○。
（ｆ）「端末およびディスプレイがスリープ状態になっていないこと」９００２もしくは「タッチパネルおよび物理ボタンによる入力が一定期間内に行われていること」９００３が×の場合、「加速度センサが反応していること」９００４もしくは「画像センサがユーザの顔を認識していること」９００７が○であれば、通話可能判定は○。
（ｇ）「端末およびディスプレイがスリープ状態になっていないこと」９００２と「タッチパネルおよび物理ボタンによる入力が一定期間内に行われていること」９００３がいずれも×の場合、「加速度センサが反応していること」９００４と「画像センサがユーザの顔を認識していること」９００がともに○であれば、通話可能判定は○。
【００５７】
３ＰＣＣ連携アプリケーション３は、３ＰＣＣ連携サーバ１からの通話状態の問合せ（３００４、３００９）を受信すると、インストールされた端末の通話可否を端末搭載の各センサ情報によって「通話状態でないこと」９００１〜「画像センサがユーザの顔を認識していること」９００７に対応するを取得する。３ＰＣＣ連携アプリケーション３は、通話可否判定テーブル２０１３による判定の結果により通話可否を判定する。判定結果は、通話可否判定９００８例えば、通話可能判定が○の場合は空き、×の場合は話中となる。
【００５８】
Ｃ．本実施の形態の効果
本実施の形態によると、端末の通話可否状態を監視、判断することにより、通話を行う両者がともに空き状態となった場合にのみ接続可能となる。そのため、接続元ユーザの操作負担を少なく抑えることが可能である。
また、本実施の形態によると３ＰＣＣサービス利用者の利用状況に合わせてサービス利用者に料金を請求出来る効果を奏する。
【００５９】
Ｄ．付記
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれている。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【００６０】
１  ３ＰＣＣ連携サーバ  
２ａ  端末Ａ
２ｂ  端末Ｂ
３  ３ＰＣＣ連携  アプリケーション  
１００１  ＣＰＵ
１００３ａ  ＩＦ
１００３ｂ  ＩＦ
１００４  メモリ
１１０１  ３ＰＣＣ連携サーバ制御部
１１０２  ３ＰＣＣモジュール部  
１１０３  空き情報取得モジュール部  
１１０４  メディアストリーム制御部
１１０５  ＳＩＰ制御部
１１０６  請求金額テーブル
１１１１  監視端末情報テーブル  
１１１２  合計金額テーブル
１１２１  ＩＤ
１１２２  接続元電話番号
１１２３  接続先電話番号
１１２４  接続元通話状態
１１２５  接続先通話状態
１１２６  問合せ回数
２００１  ３ＰＣＣ連携アプリケーション
２００２  表示部
２００３  ＳＩＰ制御部
２００４  通信ＩＦ
２００５  操作部
２００６  センサ部
２０１１  ３ＰＣＣ連携アプリケーション制御部
２０１２  通話状態テーブル
２０１３  通話可否判定テーブル
２０２１  タッチセンサ
２０２２  物理スイッチ
２０３１  画像センサ（カメラ）
２０３２  マイク
２０３３  温度センサ
２０３４  加速度センサ
２１０１  通話状態
４００１  通話開始時刻
４００２  通話終了時刻
４００３  発呼先
４００４  通話料金
９００１  通話状態でないこと
９００２  端末およびディスプレイがスリープ状態になっていないこと
９００３  タッチパネルおよび物理ボタンによる入力が一定期間内に行われていること
９００４  加速度センサが反応していること
９００５  温度センサが一定以上の温度を検出していること
９００６  画像センサの輝度が一定以上の明るさであること
９００７  画像センサがユーザの顔を認識していること
９００８  通話可能判定
【図１】
2016103706.tif 000003
【図２】
2016103706.tif 000004
【図３】
2016103706.tif 000005
【図４】
2016103706.tif 000006
【図５】
2016103706.tif 000007
【図６】
2016103706.tif 000008
【図７−１】
2016103706.tif 000009
【図７−２】
2016103706.tif 000010
【図８】
2016103706.tif 000011
【図９−１】
2016103706.tif 000012
【図９−２】
2016103706.tif 000013
【図１０】
2016103706.tif 000014
【図１１】
2016103706.tif 000015
【図１２】
2016103706.tif 000016