JP6509061B2 - 着信制御装置、着信制御方法、通信システム、及びプログラム - Google Patents

Description

本発明は、ＶｏＩＰ通信技術に関連するものであり、特に、Ｐｕｓｈ通知を利用してＶｏＩＰ通信を行う技術に関連するものである。

近年、スマートフォン等の端末にインストールすることで、ＳＩＰによる呼制御を行ってＶｏＩＰ通信を可能とするアプリケーションが普及してきている。ここでは、当該アプリケーションを搭載した端末をＶｏＩＰ端末と呼ぶ。また、当該アプリケーションをＶｏＩＰアプリと呼ぶ。

ＶｏＩＰ端末がＳＩＰを利用してＶｏＩＰ通信を行う場合、ＳＩＰサーバからの着信信号を受信するためにはＶｏＩＰアプリを常に立ち上げておく必要がある。

また、ＶｏＩＰ端末とＳＩＰサーバ間にはＮＡＴが備えられている場合が多く、ＶｏＩＰ端末とＳＩＰサーバ間で定期的に通信を行わなければ、ＮＡＴのポートマッピングが失われ、ＮＡＴを経由した着信ができなくなる。

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

上記のとおり、一般に、ＶｏＩＰ端末を着信可能とするためには、（１）ＶｏＩＰアプリを常に立ち上げておくとともに、（２）ＶｏＩＰ端末から定期的にＳＩＰサーバに対して通信を行う必要がある。

（１）の点に関し、ＯＳや管理系アプリケーションがＶｏＩＰアプリを終了する場合があり、また、着信が必要な度にＶｏＩＰアプリが起動しているか利用者が確認する必要があるといったことから、利便性向上の点からＶｏＩＰアプリが起動していなくても着信を可能とすることが求められている。

また、（２）の点に関しては、ＶｏＩＰアプリによる定期的な通信によって、バッテリー消耗が行われてしまうため、接続維持のための通信を削減することが求められている。

本発明は上記の点に鑑みてなされたものであり、ＶｏＩＰ通信を行うユーザ端末において、ＶｏＩＰアプリが起動していなくても着信を可能とするとともに、バッテリー消費を削減することを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、
前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該ユーザ端末の識別情報を含み、前記着信制御装置を宛先とする発信信号を受信した場合に、当該識別情報に基づいて、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と、
着信通知を受信した前記ユーザ端末から登録信号を受信した場合に、前記ユーザ端末を宛先とする発信信号を送信する発信信号送信手段と
を備えることを特徴とする着信制御装置が提供される。

また、本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、
前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求する手段と、
前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と
を備えることを特徴とする着信制御装置が提供される。

また、本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置が実行する着信制御方法であって、
前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該ユーザ端末の識別情報を含み、前記着信制御装置を宛先とする発信信号を受信した場合に、当該識別情報に基づいて、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求ステップと、
着信通知を受信した前記ユーザ端末から登録信号を受信した場合に、前記ユーザ端末を宛先とする発信信号を送信する発信信号送信ステップと
を備えることを特徴とする着信制御方法が提供される。

また、本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置が実行する着信制御方法であって、
前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求するステップと、
前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求ステップと
を備えることを特徴とする着信制御方法が提供される。

また、本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムであって、
前記着信制御装置は、
前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求する手段と、
前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と
を備えることを特徴とする通信システムが提供される。

本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末において、ＶｏＩＰアプリが起動していなくても着信を可能とするとともに、バッテリー消費を削減することを可能とする技術が提供される。

本発明の実施の形態に係る通信システムの全体構成図である。 第１の実施の形態においてユーザ端末１００への着信時の動作概要を説明するための図である。 Ｐｕｓｈ着信サーバ１０の機能構成図である。 ユーザ端末１００の機能構成図である。 第１の実施の形態におけるＰｕｓｈ着信可能とするための準備手順を示すシーケンス図である。 第１の実施の形態における着信時の手順を示すシーケンス図である。 Ｐｕｓｈ通知後にタイムアウトが生じる場合の手順を示すシーケンス図である。 着信拒否動作の手順を示すシーケンス図である。 第２の実施の形態においてユーザ端末１００への着信時の動作概要を説明するための図である。 第２の実施の形態におけるＰｕｓｈ着信可能とするための準備手順を示すシーケンス図である。 第２の実施の形態における着信時の手順を示すシーケンス図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（実施の形態の概要）
近年、ＯＳの標準的な仕組みによって、インターネット上のサーバからＯＳが提供するインターネット上のサービスを用いてアプリケーションに情報を通知する仕組みが提供されている。当該サービスを提供するサーバをＰｕｓｈサーバ、通知する仕組みをＰｕｓｈ通知機構と呼ぶことにする。

Ｐｕｓｈ通知機構では、端末でアプリケーションを立ち上げていなくても、端末（におけるＯＳ）がＰｕｓｈサーバに対して端末のＩＰアドレスを通知する。結果的にＰｕｓｈサーバはＰｕｓｈ通知機構に対応している各端末にインターネット上からメッセージを送信することが可能となる。このＰｕｓｈ通知機構では、Ｐｕｓｈサーバと端末間にＮＡＴがある場合でも、端末にメッセージを送信できる。

本実施の形態では、Ｐｕｓｈ通知機構を利用することにより、ＶｏＩＰアプリを常に立ち上げておく必要性を解消している。また、Ｐｕｓｈ通知機構では、Ｐｕｓｈサーバと端末間にＮＡＴがある場合でも、ＮＡＴ越えを行ってメッセージ通知が可能なため、従来技術におけるＮＡＴ透過維持のためのバッテリー消費が抑制される。以下、本発明の実施の形態を詳細に説明する。

（システム全体構成）
図１に、本発明の実施の形態（第１、第２の実施の形態に共通）に係る通信システムの全体構成図を示す。図１に示すように、本実施の形態に係る通信システムは、Ｐｕｓｈ着信サーバ１０、ＳＩＰサーバ２０、Ｐｕｓｈサーバ３０、ユーザ端末１００、２００が、ネットワーク３００に接続された構成を備える。

後に詳細に説明するように、第１の実施の形態では、Ｐｕｓｈ着信サーバ１０は、ＳＩＰサーバ２０に対する別のＳＩＰサーバに相当するサーバであり、ＳＩＰサーバ２０から転送されてきた発信信号（ＩＮＶＩＴＥ）を受信したときに、Ｐｕｓｈサーバ３０に対してＰｕｓｈ通知要求を送信する等の機能を備える。また、第２の実施の形態では、Ｐｕｓｈ着信サーバ１０はＳＩＰサーバ２０に対してイベント登録を行い、ＳＩＰサーバ２０からイベントを受信した場合に、Ｐｕｓｈサーバ３０に対してＰｕｓｈ通知要求を送信する等の機能を備える。各実施の形態におけるＰｕｓｈ着信サーバ１０の機能詳細については後述する。

ＳＩＰサーバ２０は、ＩＰ電話サービス等で用いられるＳＩＰ信号の中継等を行うサーバである。

Ｐｕｓｈサーバ３０は、Ｐｕｓｈ通知サービスにおいて用いられているサーバであり、外部サーバからの要求に基づいて、ユーザ端末にＰｕｓｈ通知を行う。なお、Ｐｕｓｈ通知とは、スマートフォン等のユーザ端末において、アプリケーションを起動していなくとも、当該ユーザ端末に通知を送り、例えば、ユーザ端末において、情報表示、アプリケーションの起動等の制御を行うことを可能とする仕組みである。Ｐｕｓｈ通知サービスとしては種々のサービスが提供されているが、本発明を適用できるＰｕｓｈ通知サービスは特定のサービスに限定されない。

ユーザ端末１００、２００は、各種アプリケーションを実行できるスマートフォン等の端末である。本実施の形態では、ユーザ端末１００、２００には、ネットワーク３００上でＶｏＩＰ通信を行うためのアプリケーションを搭載し、当該アプリケーションの機能により、ＳＩＰ信号による呼接続処理、及び音声通信等を行うことが可能である。ユーザ端末１００、２００は同じ機能を有するが、本実施の形態では、主にユーザ端末１００が着信側、ユーザ端末２００が発信側であるとしている。以下、上記のアプリケーションを「ＶｏＩＰアプリ」と呼ぶ。

ネットワーク３００は、ＶｏＩＰ通信可能なネットワークであり、例えば、インターネットとプライベートネットワークとがＮＡＴを介して接続された構成を有する。

なお、ＳＩＰサーバ２０を通信制御装置と称し、Ｐｕｓｈ着信サーバ１０を着信制御装置と称し、Ｐｕｓｈサーバ３０を着信通知装置と称してもよい。また、電話番号を「識別情報」と称してもよい。

（第１の実施の形態）
まず、第１の実施の形態について説明する。ここでは、ユーザ端末１００の電話番号を電話番号Ａとし、ユーザ端末２００の電話番号を電話番号Ｂとする。また、第１の実施の形態では、ＳＩＰサーバ２０は、発信元のユーザ端末２００から受信した発信信号をＰｕｓｈ着信サーバ１０に転送する動作を行うが、そのときに宛先とするＰｕｓｈ着信サーバ１０の電話番号を電話番号Ｃとする。

＜動作概要＞
図２を参照して、第１の実施の形態において、ユーザ端末２００からユーザ端末１００に対して着信がなされる際の動作概要を説明する。以下の説明では、着信先のユーザ端末１００におけるＶｏＩＰアプリが起動していない状態であるとする。より詳細な動作については後にシーケンス図を参照して説明する。

ユーザ端末２００において、ユーザ端末１００に対する発信操作が行われると、宛先として電話番号Ａを指定した発信信号（具体的にはＩＮＶＩＴＥ信号）がＳＩＰサーバ２０に送信される（ステップＳ１）。ＳＩＰサーバ２０において、ユーザ端末１００（電話番号Ａ）のＲＥＧＩＳＴＥＲ情報があれば発信信号をユーザ端末１００に送信するが、ここでは、ＲＥＧＩＳＴＥＲ情報の有効期限が切れており、ＲＥＧＩＳＴＥＲ情報がなく、発信信号をユーザ端末１００に送信できないと判断する。すると、ＳＩＰサーバ２０は、Ｐｕｓｈ着信サーバ１０（電話番号Ｃ）宛てに発信信号を転送する（ステップＳ２）。

発信信号を受信したＰｕｓｈ着信サーバ１０は、Ｐｕｓｈサーバ３０に対して、ユーザ端末１００へのＰｕｓｈ通知を要求するＰｕｓｈ通知要求を送信する（ステップＳ３）。Ｐｕｓｈ通知要求を受信したＰｕｓｈサーバ３０は、ユーザ端末１００に対してＰｕｓｈ通知を行う（ステップＳ４）。

前述したように、ユーザ端末１００においてＶｏＩＰアプリが起動していないため、Ｐｕｓｈ通知を受信したユーザ端末１００は、当該Ｐｕｓｈ通知をトリガとして、ＶｏＩＰアプリを起動し、当該ＶｏＩＰアプリの機能により、Ｐｕｓｈ着信サーバ１０に接続し、ＳＩＰにおける登録（ＲＥＧＩＳＴＥＲ）を行う（ステップＳ５）。

Ｐｕｓｈ着信サーバ１０は、ステップＳ２で受信していた、ユーザ端末２００を送信元とする発信信号をユーザ端末１００に送信する（ステップＳ６）。発信信号を受信したユーザ端末１００は、応答を返し、応答がユーザ端末２００に到達する（ステップＳ７〜Ｓ９）。これにより、ユーザ端末１００とユーザ端末２００との間に音声セッションが確立され、音声通信が行われる。

＜装置構成＞
次に、第１の実施の形態に係るＰｕｓｈ着信サーバ１０と、ユーザ端末１００の機能構成について説明する。後述するように、第２の実施の形態におけるＰｕｓｈ着信サーバ１０とユーザ端末１００のブロック構成自体は第１の実施の形態と同じであるため、ここでは、第２の実施の形態における機能の概要についても説明する。

図３に、Ｐｕｓｈ着信サーバ１０の機能構成図を示す。図３に示すように、Ｐｕｓｈ着信サーバ１０は、対ＳＩＰサーバ通信処理部１１、対ユーザ端末通信処理部１２、Ｐｕｓｈ通知要求処理部１３、設定情報格納部１４を有する。なお、図３は、Ｐｕｓｈ着信サーバ１０において本発明の実施の形態に特に関連する機能部のみを示すものである。また、図３に示す機能構成は一例に過ぎない。本発明の実施の形態で説明する動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

対ＳＩＰサーバ通信処理部１１は、ＳＩＰサーバ２０との間の通信に関わる処理を行う。特に第１の実施の形態では、認証処理、ＳＩＰ信号の送受信、着信履歴管理等を行う。また、第２の実施の形態では、対ＳＩＰサーバ通信処理部１１は、イベント登録要求の送信、着信イベントの受信等を行う。

対ユーザ端末通信処理部１２は、ユーザ端末１００との間の通信に関わる処理を行う。特に第１の実施の形態では、対ユーザ端末通信処理部１２は、ＳＩＰ信号の送受信、設定情報の登録処理等を行う。第２の実施の形態では、ＳＩＰ信号の送受信は行わず、設定情報の登録処理等を行う。

Ｐｕｓｈ通知要求処理部１３は、第１及び第２の実施の形態において、Ｐｕｓｈサーバ３０に対するＰｕｓｈ通知要求の送信処理、タイマ管理等を行う。また、第１及び第２の実施の形態において、設定情報格納部１４には、ユーザ端末１００から受信した設定情報や着信履歴が格納される。

第１及び第２の実施の形態に係るＰｕｓｈ着信サーバ１０は、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、Ｐｕｓｈ着信サーバ１０が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、Ｐｕｓｈ着信サーバ１０で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

図４に、ユーザ端末１００の機能構成図を示す。図４に示すように、ユーザ端末１００は、Ｐｕｓｈ通知処理部１０１、着信設定処理部１０２、音声通信処理部１０３を備える。なお、図４は、ユーザ端末１００において本発明の実施の形態に特に関連する機能部のみを示すものである。また、図４に示す機能構成は一例に過ぎない。本発明の実施の形態で説明する動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

Ｐｕｓｈ通知処理部１０１は、Ｐｕｓｈサーバ３０との間で通信を行って、Ｐｕｓｈ用ＩＤを取得したり、Ｐｕｓｈ通知を受信して、ＶｏＩＰアプリの起動／着信処理指示等を行う。着信設定処理部１０２は、Ｐｕｓｈ着信を要求するために、Ｐｕｓｈ着信サーバ１０に対して設定情報を送信する等の処理を行う。音声通信処理部１０３は、Ｐｕｓｈ着信サーバ１０／ＳＩＰサーバ２０との接続、登録処理を含むＳＩＰ呼制御、音声通信機能等を含む。

ユーザ端末１００に関し、上記のような基本的な処理内容に関しては、第１及び第２の実施の形態において同じであるが、詳細な処理内容については異なる。

なお、第１の実施の形態（第２の実施の形態も同様）では、Ｐｕｓｈ通知処理部１０１は、コンピュータの構成を備えるユーザ端末１００のＯＳに含まれる機能であり、着信設定処理部１０２と音声通信処理部１０３はＶｏＩＰアプリに対応することを想定しているが、このような構成区分に限られるわけではない。例えば、Ｐｕｓｈ通知処理部１０１、着信設定処理部１０２、音声通信処理部１０３がＶｏＩＰアプリに対応する機能部であってもよい。

第１の実施の形態（第２の実施の形態も同様）に係るユーザ端末１００は、コンピュータ（携帯電話機やスマートフォン等を含む）に、本発明の実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、ユーザ端末１００が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、ユーザ端末１００で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

＜通信システムの動作例＞
次に、第１の実施の形態における各種の動作例をシーケンス図等を参照しながら説明する。なお、以下で示すシーケンスは、処理内容を分かり易く示すために、実際の信号のやりとりの中の主要なやりとりを示すものである。

＜＜準備手順＞＞
図５を参照して、第１の実施の形態においてＰｕｓｈ通知による着信を可能とするための準備手順を説明する。

まず、例えば、ユーザ端末１００において最初にＶｏＩＰアプリを起動する（もしくはインストールする）タイミングで、ユーザ端末１００はＰｕｓｈサーバ３０にアクセスし、Ｐｕｓｈサーバ３０からＰｕｓｈ用ＩＤを受信し、メモリ等に記憶手段に格納する（ステップＳ１０１）。当該Ｐｕｓｈ用ＩＤは、Ｐｕｓｈサーバ３０において、ユーザ端末１００（ＶｏＩＰアプリ）を識別可能なＩＤであり、Ｐｕｓｈサーバ３０は、当該Ｐｕｓｈ用ＩＤを含むＰｕｓｈ通知要求を受信した場合に、当該Ｐｕｓｈ用ＩＤに対応するユーザ装置１００にＰｕｓｈ通知を送ることができる。Ｐｕｓｈ通知は、Ｐｕｓｈサーバ３０とユーザ端末１００間にＮＡＴが存在するネットワークでも送信できる仕組みになっている。Ｐｕｓｈ用ＩＤは、ユーザ端末１００を識別するＩＤであるから、端末識別情報と称してもよい。

次に、ユーザ端末１００は、Ｐｕｓｈ着信要求としての設定情報をＰｕｓｈ着信サーバ１０に送信する（ステップＳ１０２）。設定情報には、電話番号Ａ、ユーザＩＤ、パスワード、及びステップＳ１０１で取得したＰｕｓｈ用ＩＤが含まれる。ユーザＩＤは「ＳＩＰ−ＩＤ」と呼んでもよい。

上記の電話番号Ａ、ユーザＩＤ、及びパスワードは、例えばユーザがＩＰ電話サービスを利用する際に、サービス提供側から割り当てられたものである。すなわち、ＶｏＩＰアプリを起動しているユーザ端末１００は、当該電話番号Ａ、ユーザＩＤ、及びパスワードを用いてＳＩＰサーバ２０を介した通常の発信、着信、通話を行うことができる。本実施の形態では、ＳＩＰサーバ２０がこれらの情報を保持しており、ＳＩＰサーバ２０は、ユーザＩＤ、及びパスワードによりユーザ端末１００の認証を行うことが可能である。なお、ユーザＩＤ、及びパスワードを認証情報と称してもよい。

設定情報を受信したＰｕｓｈ着信サーバ１０は、ＳＩＰサーバ２０に対して、ステップＳ１０２で受信した電話番号Ａ、ユーザＩＤ、パスワードを含むＲＥＧＩＳＴＥＲ信号を送信する（ステップＳ１０３）。このＲＥＧＩＳＴＥＲ信号の送信は、ＳＩＰサーバ２０にユーザ端末１００の認証を行わせるためのものである。従って、Ｐｕｓｈ着信サーバ１０は、ステップＳ１０３において、電話番号Ａ、ユーザＩＤ、及びパスワードを、ＳＩＰ信号以外の信号で送信してもよい。また、送信する情報に電話番号Ａを含まないこととしてもよい。

ＲＥＧＩＳＴＥＲ信号を受信したＳＩＰサーバ２０は、受信したユーザＩＤとパスワードが、登録されているユーザＩＤとパスワードと同じかどうかをチェックすることで、ユーザ端末１００の認証を行う（ステップＳ１０４）。

ステップＳ１０４での認証に成功したものとすると、ＳＩＰサーバ２０は、正常であることを示す応答をＰｕｓｈ着信サーバ１０に送信する（ステップＳ１０５）。Ｐｕｓｈ着信サーバ１０は、この正常応答を受信したことにより、ステップＳ１０２で受信した設定情報は正しいものであると判断し、電話番号Ａ、ユーザＩＤ、パスワード、及びＰｕｓｈ用ＩＤを設定情報格納部１４に格納する。そして、Ｐｕｓｈ着信サーバ１０は、設定情報を正常に格納したことを示す応答をユーザ端末１００に送信する（ステップＳ１０６）。

ステップＳ１０４での認証に失敗した場合、ＳＩＰサーバ２０は、認証に失敗したことを示す応答をＰｕｓｈ着信サーバ１０に送信し、Ｐｕｓｈ着信サーバ１０は、この失敗応答を受信したことにより、ステップＳ１０２で受信した設定情報は正しくないものであると判断し、設定情報の格納を行わずに、格納に失敗したことを示す応答をユーザ端末１００に送信する。

＜＜着信時の手順＞＞
次に、図６を参照して、第１の実施の形態においてユーザ端末２００からユーザ端末１００への着信が行われる場合の手順を説明する。図６の前提として、図５に示した準備手順が既に行われているものとする。また、ＳＩＰサーバ２０において、以下で説明する動作を実行する機能（プログラム等）が備えられているもとする。図６には、右側に、ユーザ端末１００の状態が示されており、そこに示すように、最初はユーザ端末１００においてＶｏＩＰアプリは起動していない。

発信側のユーザ端末２００において、ユーザ端末１００の電話番号Ａを入力し、発信ボタンを押下する等の発信操作が行われることで、ユーザ端末２００からＩＮＶＩＴＥ信号が送信される（ステップＳ２０１）。

ＩＮＶＩＴＥ信号を受信したＳＩＰサーバ２０において、ユーザ端末１００のＲＥＧＩＳＴＥＲ情報（電話番号ＡとＩＰアドレスの対応情報）があれば、ＳＩＰサーバ２０は、当該情報に基づいてユーザ端末１００宛てに当該ＩＮＶＩＴＥ信号を送信する動作を実行する。しかし、ＩＮＶＩＴＥ信号を送信できたとしても現時点でユーザ端末１００におけるＶｏＩＰアプリが未起動であるため、ユーザ端末１００はＩＮＶＩＴＥ信号を解釈できず、応答を返さない。また、ユーザ端末１００のＲＥＧＩＳＴＥＲ情報がない場合、ＳＩＰサーバ２０は、ユーザ端末１００宛てに当該ＩＮＶＩＴＥ信号を送信する動作を行わない（行うことができない）。

本例では、ＳＩＰサーバ２０は、上記のように、ＩＮＶＩＴＥ信号を送信しても所定時間以上応答がない、もしくは、ＩＮＶＩＴＥ信号をユーザ端末１００宛てに送信できないことを検出する。この事象を検出したＳＩＰサーバ２０は、当該ＩＮＶＩＴＥ信号をＰｕｓｈ着信サーバ１０に転送する（ステップＳ２０２）。ここでは、ＳＩＰサーバ２０は、ＩＮＶＩＴＥ信号の宛先（ｔｏ）を電話番号Ａから電話番号Ｃに変換し、宛先が電話番号Ｃとなった当該ＩＮＶＩＴＥ信号を送信する。

当該ＩＮＶＩＴＥ信号には、最終的な宛先は電話番号Ａであることを示す情報が含まれる。例えば、ＩＮＶＩＴＥ信号の中に、上記電話番号Ｃの他に、明示的に、「宛先：電話番号Ａ」の情報を含める。

このように明示的に「宛先：電話番号Ａ」を含めることの他、電話番号Ｃを電話番号Ａと対応付けられた電話番号として設定することとしてもよい。この場合は、暗黙的にＩＮＶＩＴＥ信号の中に「宛先：電話番号Ａ」が含まれている。この場合、例えば、外部のサーバに、ユーザ端末の電話番号と、当該電話番号に対応付けられたＰｕｓｈ着信サーバ１０の電話番号とを登録しておき、ＳＩＰサーバ２０は、ＩＮＶＩＴＥ信号をユーザ端末に送信できない場合に、当該サーバから、当該ユーザ端末に対応するＰｕｓｈ着信サーバ１０の電話番号を取得し、当該電話番号を宛先としてＩＮＶＩＴＥ信号を送信する。この方式において、Ｐｕｓｈ着信サーバ１０では、ＩＮＶＩＴＥ信号の宛先の電話番号に対応するユーザ端末の電話番号を上記サーバから取得して、Ｐｕｓｈ通知要求送信等にために使用する。

また、電話番号Ｃとして、宛先の電話番号（ここでは電話番号Ａ）に、予め定められたプレフィックスを付加した電話番号を用いてもよい。例えば、「Ｐｒｅｆｉｘ＋０５０−Ａ」のような電話番号を用いる。この場合、当該プレフィックスの付いた電話番号を宛先とするＩＮＶＩＴＥ信号は、Ｐｕｓｈ着信サーバ１０に転送される。

当該プレフィックス付きの電話番号を宛先とするＩＮＶＩＴＥ信号を受信したＰｕｓｈ着信サーバ１０は、宛先となっている電話番号からプレフィックスを除くことで、最終的な宛先のユーザ端末１００の電話番号Ａを取得できる。

なお、ＩＮＶＩＴＥ信号には、宛先の電話番号Ｃとともに、発信元の電話番号Ｂも含まれている。

ステップＳ２０２によりＩＮＶＩＴＥ信号を受信したＰｕｓｈ着信サーバ１０は、上述した方法でＩＮＶＩＴＥ信号から当初の宛先である電話番号Ａを取得し、当該電話番号Ａ（ユーザ端末１００）へのＰｕｓｈ通知を要求するＰｕｓｈ通知要求をＰｕｓｈサーバ３０に送信する（ステップＳ２０３）。このＰｕｓｈ要求通知には、設定情報格納部１４から抽出した電話番号Ａに対応するＰｕｓｈ用ＩＤと、発信元の電話番号Ｂと、Ｐｕｓｈ着信サーバ１０のＩＰアドレスと、Ｐｕｓｈ着信サーバ１０が着信（ＩＮＶＩＴＥ信号）を受けた時刻（Ｐｕｓｈ着信サーバ着信時刻と呼ぶ）が含まれる。ただし、Ｐｕｓｈ用ＩＤ以外は、含めることは必須ではなく、Ｐｕｓｈ用ＩＤのみでも着信を行うことは可能である。本例では、全て含むものとする。

一方、ステップＳ２０２でＩＮＶＩＴＥ信号を受信したＰｕｓｈ着信サーバ１０は、１００ｔｒｙｉｎｇ応答をＳＩＰサーバ２０に返し、１００ｔｒｙｉｎｇ応答はユーザ端末２００に送られる（ステップ２２１、２２２）。

ただし、１００ｔｒｙｉｎｇ応答では、着信側のユーザ端末１００でＶｏＩＰアプリが起動して着信処理を開始するまでの間、発信側のユーザ端末２００は無音となる。そこで、ステップＳ２２１、Ｓ２２２において括弧内に示したように、１００ｔｒｙｉｎｇ応答に代えて、１８０ｒｉｎｇｉｎｇ応答送信、ガイダンス送信の制御等を行うこととしてもよい。１８０ｒｉｎｇｉｎｇ応答、ガイダンス等を送信することで、発信側のユーザ端末２００のユーザは、発信後、すぐに呼び出し音等を聞くことができ、無音状態を回避できる。

ステップＳ２０３でＰｕｓｈ通知要求を受信したＰｕｓｈサーバ３０は、Ｐｕｓｈ通知要求に含まれるＰｕｓｈ用ＩＤに対応する宛先であるユーザ端末１００にＰｕｓｈ通知を送信する（ステップＳ２０４）。本例では、Ｐｕｓｈ通知には、電話番号Ｂと、Ｐｕｓｈ着信サーバ１０のＩＰアドレスと、Ｐｕｓｈ着信サーバ着信時刻が含まれる。

Ｐｕｓｈ通知を受信したユーザ端末１００では、当該Ｐｕｓｈ通知をトリガとしてＶｏＩＰアプリが起動する。そして、ユーザ装置１００は、Ｐｕｓｈ着信サーバ１０と接続し（ＴＣＰ接続）、ＲＥＧＩＳＴＥＲ信号（電話番号Ａ、ユーザＩＤ、パスワード含む）を送信する（ステップＳ２０５）。ユーザ端末１００から見てＰｕｓｈ着信サーバ１０はＳＩＰサーバの役割を持ち、上記ＲＥＧＩＳＴＥＲの処理により、Ｐｕｓｈ着信サーバ１０には、ユーザ端末１００への宛先ＩＰアドレスと電話番号Ａとが対応付けて格納され、ユーザ端末１００宛てのＩＮＶＩＴＥ信号のユーザ端末１００への転送が可能になる。

上記の処理において、ユーザ端末１００は、Ｐｕｓｈ通知に含まれる電話番号Ｂ（あるいは電話番号Ｂに対応する名前）を表示することで、誰から着信があったのかを知ることができる。また、ユーザ端末１００は、Ｐｕｓｈ通知に含まれるＰｕｓｈ着信サーバ１０のＩＰアドレスをＰｕｓｈ着信サーバ１０への接続に使用する。これにより、アドレス解決等の処理を省くことができ、迅速にＰｕｓｈ着信サーバ１０への接続を行うことができる。

また、ユーザ端末１００は、Ｐｕｓｈ通知に含まれるＰｕｓｈ着信サーバ着信時刻と、現在時刻とを比較し、Ｐｕｓｈ着信サーバ着信時刻が現在時刻よりも所定の閾値時間以上前である場合には、Ｐｕｓｈ着信サーバ１０への接続を行わない（着信動作を行わない）こととしてもよい。Ｐｕｓｈサーバ３０の状態によっては、Ｐｕｓｈ通知のユーザ端末１００への送信が遅れる可能性があり、大きくＰｕｓｈ通知が遅れた場合には、発信側は発信を中止している可能性が高いためである。

ステップＳ２０５でＲＥＧＩＳＴＥＲ信号を受信したＰｕｓｈ着信サーバ１０は、ＲＥＧＩＳＴＥＲ信号に含まれるユーザＩＤとパスワードと、既に格納してある設定情報とを照合することで、ユーザ端末１００の認証を行う（ステップＳ２０６）。なお、ユーザ端末１００から受信したＲＥＧＩＳＴＥＲ信号をＳＩＰサーバ２０に転送することで、ＳＩＰサーバ２０に認証を行わせることも可能であるが、図６に示すとおり、Ｐｕｓｈ着信サーバ１０が認証を行うこととすることで、ＳＩＰサーバ２０に対するＲＥＧＩＳＴＥＲ信号の送信量を抑制することが可能となる。

図６に示す例では、ステップＳ２０６の認証に成功する。Ｐｕｓｈ着信サーバ１０は、正当であると判定されたユーザ端末１００に対して、ＩＮＶＩＴＥ信号を送信する（ステップＳ２０７）。ここでは、Ｐｕｓｈ着信サーバ１０は、ステップＳ２０２で受信したＩＮＶＩＴＥ信号における宛先を電話番号Ｃから電話番号Ａに変換し、当該変換後のＩＮＶＩＴＥ信号をユーザ端末１００に送信する。なお、もしもステップＳ２０６の認証が失敗した場合は、着信失敗となり、例えば、ユーザ端末２００に対してエラー、もしくはガイダンスが送られる。

ＩＮＶＩＴＥ信号を受信したユーザ端末１００は、１８０ｒｉｎｇｉｎｇ応答を返す（ステップＳ２０８）。１８０ｒｉｎｇｉｎｇ応答は、Ｐｕｓｈ着信サーバ１０及びＳＩＰサーバ２０を経由して発信元のユーザ端末２００に送信される。これにより、着信側で着信音が鳴動するとともに、発信側では呼び出し音が聞こえる。なお、ユーザ端末２００に対してガイダンスが流されてもよい。

ユーザ端末１００において、着信ボタンが押下される（＝受話器をとる）と、２００ ＯＫが返される（ステップＳ２１１〜Ｓ２１３）。これによりユーザ端末１００とユーザ端末２００との間で音声セッションが確立し、音声通信が行われる（ステップＳ２１４）。

＜＜Ｐｕｓｈ通知後にタイムアウトが生じる場合の手順＞＞
続いて、Ｐｕｓｈ通知後にタイムアウトが生じる場合の手順を図７のシーケンス図を参照して説明する。

Ｐｕｓｈサーバ３０からユーザ端末１００に対してＰｕｓｈ通知が送信された場合でも、例えばユーザ端末１００が圏外であるとか、電源断になっている場合等においては、ユーザ端末１００はＰｕｓｈ通知を受信しないので、ＶｏＩＰアプリの起動や着信処理が行われない。

つまり、図７に示すように、ユーザ端末２００から発信があり、ＩＮＶＩＴＥ信号がＰｕｓｈ着信サーバ１０に送信され（ステップＳ３０１、Ｓ３０２）、Ｐｕｓｈ通知要求がＰｕｓｈサーバ３０に送信され（ステップＳ３０３）、Ｐｕｓｈ通知がユーザ端末１００に送信される（ステップＳ３０４）。しかし、上記の圏外や電源断の状況では、ＶｏＩＰアプリが起動せず、ユーザ端末１００からＰｕｓｈ着信サーバ１０に対して何らの信号も返されない。このような状況では、ユーザ端末２００において無音（あるいは呼び出し音、ガイダンス）が長い時間継続されてしまう。

このような状況を想定し、Ｐｕｓｈ着信サーバ１０は、ユーザ端末１００へのＰｕｓｈ通知を要求するＰｕｓｈ通知要求を送信してからの所定の時間長を計測するタイマを備える。Ｐｕｓｈ着信サーバ１０は、Ｐｕｓｈ通知要求を送信してから、ユーザ端末１００からＲＥＧＩＳＴＥＲ信号等の信号を受信せずにタイマが満了した場合（図７のステップＳ３０５）に、エラー応答の送信、ガイダンスを流す制御等を行う（ステップＳ３０６、Ｓ３０７）。また、着信に関わるセッションを解放する。これにより、発信側では、着信ができないことを知ることができる。

なお、上記のタイムアウト処理は、前述したように、Ｐｕｓｈサーバ３０からユーザ端末１００へのＰｕｓｈ通知の送信が遅れた場合にも適用できる。

また、上記のように、ユーザ端末１００が圏外等にあり、Ｐｕｓｈ通知が届かない場合、着信があったもののユーザ端末１００には着信履歴が残らない。このような状況を想定し、本実施の形態では、Ｐｕｓｈ着信サーバ１０が着信履歴を格納する。そして、例えば、ユーザ端末１００におけるＶｏＩＰアプリの起動時に、ユーザ端末１００がＰｕｓｈ着信サーバ１０に着信履歴を要求し、Ｐｕｓｈ着信サーバ１０は、要求に応じて着信履歴をユーザ端末１００（ＶｏＩＰアプリ）に送信する。Ｐｕｓｈ着信サーバ１０から着信履歴を受信したユーザ端末１００は、当該着信履歴のうち、ユーザ端末１００に格納されていない着信履歴のみを追加で格納する。

＜＜着信拒否の手順＞＞
これまでに説明したとおり、Ｐｕｓｈ通知を利用することで、ユーザ端末１００におけるＶｏＩＰアプリの起動の有無に関わらず着信が可能である。従って、例えば、ＶｏＩＰアプリを起動しないことで着信を受けないようにする、といったことができない。そこで、本実施の形態では、図８に示す手順で、着信拒否を行うことを可能としている。

まず、ユーザ端末１００から着信拒否設定情報をＰｕｓｈ着信サーバ１０に送信する（ステップＳ４００）。Ｐｕｓｈ着信サーバ１０は着信拒否設定情報を設定情報格納部１４に格納する。着信拒否設定情報は、例えば、どの番号からの着信を何時から何時まで拒否するかを示す着信拒否時間・着信拒否番号情報である。

Ｐｕｓｈ着信サーバ１０が着信を受けると（ステップＳ４０１、Ｓ４０２）、発信元の番号及び現在時刻と着信拒否設定情報とを照合することで、当該着信が着信拒否の対象かどうかを判定する。本例では、着信拒否の対象であるものとし、Ｐｕｓｈ着信サーバ１０は着信拒否を決定する（ステップＳ４０３）。着信拒否を決定したＰｕｓｈ着信サーバ１０は、Ｐｕｓｈ通知要求を送信せず、エラー応答、ガイダンス等を送信する制御を行う（ステップＳ４０４、Ｓ４０５）。

なお、これまでは着信を説明したが、発信については、Ｐｕｓｈ着信サーバ１０を経由することなく、通常通りにＳＩＰサーバ２０を介して行うことができる。また、発信についても、Ｐｕｓｈ着信サーバ１０を経由して行うこととしてもよい。例えば、発信時、ユーザ端末１００は、Ｐｕｓｈ着信サーバ１０にＲＥＧＩＳＴＥＲ信号を送信してＲＥＧＩＳＴＥＲを行った後、ＩＮＶＩＴＥ信号をＰｕｓｈ着信サーバ１０経由でＳＩＰサーバ２０に送信することで、発信を行うことが可能である。

また、第１の実施の形態におけるＰｕｓｈ着信サーバ１０は制御信号（ＳＩＰ信号等）だけを送受信可能とし、音声信号を送受信しないこととしてもよいし、音声信号も送受信可能に構成してもよい。Ｐｕｓｈ着信サーバ１０が音声信号を送受信する場合は、Ｐｕｓｈ着信サーバ１０〜ユーザ端末１００間において音声コーデック及びｐｔｉｍｅ（パケット送信間隔）等についてＰｕｓｈ着信サーバ１０〜ＳＩＰサーバ２０とは異なる情報に対応することが可能である。これによって、ＳＩＰサーバ２０の開発・変更なしにＰｕｓｈ着信サーバ１０〜ユーザ端末１００における音声コーデックに関わる追加、修正が可能となる。

（第２の実施の形態）
次に、第２の実施の形態について説明する。ここでも、ユーザ端末１００の電話番号を電話番号Ａとし、ユーザ端末２００の電話番号を電話番号Ｂとする。また、Ｐｕｓｈ着信サーバ１０の電話番号を電話番号Ｃとする。第２の実施の形態では、Ｐｕｓｈ着信サーバ１０は、制御信号（ＳＩＰ信号）と音声信号のいずれも終端しない。第２の実施の形態における通信システムの全体構成は第１の実施の形態と同じであり、図１に示したとおりである。また、第２の実施の形態におけるＰｕｓｈ着信サーバ１０とユーザ端末１００のブロック構成は第１の実施の形態と同じであり、図３、図４に示したとおりである。ただし、第２の実施の形態における各装置の動作は第１の実施の形態と異なる部分がある。以下では、基本的に、第１の実施の形態と異なる処理を詳細に説明する。第１の実施の形態と同じ処理については簡単に説明する。

＜動作概要＞
図９を参照して、第２の実施の形態において、ユーザ端末２００からユーザ端末１００に対して着信がなされる際の動作概要を説明する。以下の説明では、着信先のユーザ端末１００においてＶｏＩＰアプリはインストールされ、電話番号Ａ、ユーザＩＤ、パスワードが設定され、ＳＩＰサーバ２０を介した通常の着信、発信、通話を実行できることが確認されている。ただし、図９に示す処理では、最初にＶｏＩＰアプリは起動していないものとする。

ユーザ端末２００において、ユーザ端末１００に対する発信操作が行われると、宛先として電話番号Ａを指定した発信信号（具体的にはＩＮＶＩＴＥ信号）がＳＩＰサーバ２０に送信される（ステップＳ１１）。ＳＩＰサーバ２０において、ユーザ端末１００（電話番号Ａ）のＲＥＧＩＳＴＥＲ情報があれば発信信号をユーザ端末１００に送信するが、ここでは、ＲＥＧＩＳＴＥＲ情報の有効期限が切れており、ＲＥＧＩＳＴＥＲ情報がなく、発信信号をユーザ端末１００に送信できないと判断する。すると、ＳＩＰサーバ２０は、Ｐｕｓｈ着信サーバ１０（電話番号Ｃ）に着信イベントを送信する（ステップＳ１２）。この着信イベントには、電話番号Ｂ（ユーザ端末２００）を発信元とし、電話番号Ａ（ユーザ端末１００）を宛先とする発信がなされていることを示す情報が含まれる。つまり、着信イベントには「発信元：電話番号Ｂ、宛先：電話番号Ａ」の情報が含まれる。

着信イベントを受信したＰｕｓｈ着信サーバ１０は、電話番号Ａ（ユーザ端末１００）への着信があることを認識し、Ｐｕｓｈサーバ３０に対して、ユーザ端末１００へのＰｕｓｈ通知を要求するＰｕｓｈ通知要求を送信する（ステップＳ１３）。Ｐｕｓｈ通知要求を受信したＰｕｓｈサーバ３０は、ユーザ端末１００に対してＰｕｓｈ通知を行う（ステップＳ１４）。

ユーザ端末１００においてＶｏＩＰアプリが起動していないため、Ｐｕｓｈ通知を受信したユーザ端末１００は、当該Ｐｕｓｈ通知をトリガとして、ＶｏＩＰアプリを起動し、当該ＶｏＩＰアプリの機能により、ＳＩＰサーバ２０に接続し、ＳＩＰにおける登録（ＲＥＧＩＳＴＥＲ）を行う（ステップＳ１５）。

ＳＩＰサーバ２０は、ステップＳ１１で受信していた、ユーザ端末２００を送信元とする発信信号をユーザ端末１００に送信する（ステップＳ１６）。発信信号を受信したユーザ端末１００は、応答を返し、応答がユーザ端末２００に到達する（ステップＳ１７〜Ｓ１８）。これにより、ユーザ端末１００とユーザ端末２００との間に音声セッションが確立され、音声通信が行われる。

＜通信システムの動作例＞
次に、第２の実施の形態における動作例をシーケンス図を参照しながら説明する。なお、以下で示すシーケンスは、処理内容を分かり易く示すために、実際の信号のやりとりの中の主要なやりとりを示すものである。

＜＜準備手順＞＞
図１０を参照して、第２の実施の形態におけるＰｕｓｈ通知による着信を可能とするための準備手順を説明する。

まず、例えば、ユーザ端末１００において最初にＶｏＩＰアプリを起動する（もしくはインストールする）タイミングで、ユーザ端末１００はＰｕｓｈサーバ３０にアクセスし、Ｐｕｓｈサーバ３０からＰｕｓｈ用ＩＤを受信し、メモリ等に記憶手段に格納する（ステップＳ５０１）。

次に、ユーザ端末１００は、Ｐｕｓｈ着信要求としての設定情報をＰｕｓｈ着信サーバ１０に送信する（ステップＳ５０２）。設定情報には、電話番号Ａ、ＳＩＰサーバ２０の識別情報（例：ＳＩＰサーバ２０のＦＱＤＮ）、ステップＳ５０１で取得したＰｕｓｈ用ＩＤが含まれる。当該設定情報は設定情報格納部１４に格納される。

設定情報を受信したＰｕｓｈ着信サーバ１０は、ＳＩＰサーバ２０の識別情報を利用して、ＳＩＰサーバ２０に対して、電話番号Ａに関わるイベント登録要求を送信する（ステップＳ５０３）。このイベント登録要求は、ＳＩＰサーバ２０に対して、電話番号Ａを宛先とする発信信号を受信した場合に、Ｐｕｓｈ着信サーバ１０（電話番号Ｃ）に対して通知（イベント情報の送信）を行うことを要求する信号である。

イベント登録要求の信号としてＳＩＰ信号を用いる場合、例えば、電話番号Ａへの発信を受けた場合にイベント通知（ＮＯＴＩＦＹ）を行うことを要求するＳＵＢＳＣＲＩＢＥリクエストを使用することができる。なお、イベント登録要求の信号はＳＩＰ信号である必要はなく、どのような信号でもよい。

イベント登録要求を受信したＳＩＰサーバ２０は、受信したイベント登録要求に基づき、イベント（"電話番号Ａ宛ての発信信号を受信"を示す情報を含む）を登録（格納）する（ステップＳ５０４）。ＳＩＰサーバ２０は、正常に登録できたことを示す応答をＰｕｓｈ着信サーバ１０に送信する（ステップＳ５０５）。また、Ｐｕｓｈ着信サーバ１０は、正常に登録できたことを示す応答をユーザ端末１００に送信することとしてもよい（ステップＳ５０６）。

＜＜着信時の手順＞＞
次に、図１１を参照して、ユーザ端末２００からユーザ端末１００への着信が行われる場合の手順を説明する。図１１の前提として、図１０に示した準備手順が既に行われているものとする。第１の実施の形態と同様に、図１１には、右側に、ユーザ端末１００の状態が示されており、そこに示すように、最初はユーザ端末１００においてＶｏＩＰアプリは起動していない。

発信側のユーザ端末２００において、ユーザ端末１００の電話番号Ａを入力し、発信ボタンを押下する等の発信操作が行われることで、ユーザ端末２００からＩＮＶＩＴＥ信号が送信される（ステップＳ６０１）。

ＩＮＶＩＴＥ信号を受信したＳＩＰサーバ２０において、ユーザ端末１００のＲＥＧＩＳＴＥＲ情報（電話番号ＡとＩＰアドレスの対応情報）があれば、ＳＩＰサーバ２０は、当該情報に基づいてユーザ端末１００宛てに当該ＩＮＶＩＴＥ信号を送信する動作を実行する。しかし、ＩＮＶＩＴＥ信号を送信しても、現時点でユーザ端末１００におけるＶｏＩＰアプリが未起動であるため、ユーザ端末１００はＩＮＶＩＴＥ信号を解釈できず、応答を返さない。また、ユーザ端末１００のＲＥＧＩＳＴＥＲ情報がない場合、ＳＩＰサーバ２０は、ユーザ端末１００宛てに当該ＩＮＶＩＴＥ信号を送信する動作を行わない（行うことができない）。

本例では、ＳＩＰサーバ２０は、上記のように、ＩＮＶＩＴＥ信号を送信しても所定時間以上応答がない、もしくは、ＩＮＶＩＴＥ信号をユーザ端末１００宛てに送信できないことを検出する。この事象を検出したＳＩＰサーバ２０は、着信イベントをＰｕｓｈ着信サーバ１０に送信する（ステップＳ６０２）。

上記の着信イベントの信号には、電話番号Ｂ（ユーザ端末２００）を発信元とし、電話番号Ａ（ユーザ端末１００）を宛先とする発信があったこと（＝ＳＩＰサーバ２０がＩＮＶＩＴＥ信号を受信したこと）を示す情報が含まれている。前述したイベント登録要求がＳＵＢＳＣＲＩＢＥである場合、当該着信イベントの信号は、ＮＯＴＩＦＹである。なお、着信イベントの信号はＳＩＰ信号でなくてもよい。

ステップＳ６０２により着信イベントを受信したＰｕｓｈ着信サーバ１０は、着信イベントから、宛先である電話番号Ａを取得し、当該電話番号Ａ（ユーザ端末１００）へのＰｕｓｈ通知を要求するＰｕｓｈ通知要求をＰｕｓｈサーバ３０に送信する（ステップＳ６０３）。このＰｕｓｈ要求通知には、設定情報格納部１４から抽出した電話番号Ａに対応するＰｕｓｈ用ＩＤと、発信元の電話番号Ｂと、Ｐｕｓｈ着信サーバ着信時刻が含まれる。ただし、Ｐｕｓｈ用ＩＤ以外は、含めることは必須ではなく、Ｐｕｓｈ用ＩＤのみでも着信を行うことは可能である。本例では、全て含むものとする。

一方、ステップＳ６０２でＩＮＶＩＴＥ信号を受信したＰｕｓｈ着信サーバ１０は、１００ｔｒｙｉｎｇ応答をＳＩＰサーバ２０に返し、１００ｔｒｙｉｎｇ応答はユーザ端末２００に送られる（ステップ６２１、６２２）。

ただし、１００ｔｒｙｉｎｇ応答では、着信側のユーザ端末１００でＶｏＩＰアプリが起動して着信処理を開始するまでの間、発信側のユーザ端末２００は無音となる。そこで、ステップ６２１、６２２において括弧内に示したように、１００ｔｒｙｉｎｇ応答に代えて、１８０ｒｉｎｇｉｎｇ応答送信、ガイダンス送信の制御等を行うこととしてもよい。

また、図１１の例では、Ｐｕｓｈ着信サーバ１０から１００ｔｒｙｉｎｇ応答を送信しているが、Ｐｕｓｈ着信サーバ１０は１００ｔｒｙｉｎｇ応答を送信せず、ＳＩＰサーバ２０が１００ｔｒｙｉｎｇ応答を送信することとしてもよい。

ステップＳ６０３でＰｕｓｈ通知要求を受信したＰｕｓｈサーバ３０は、Ｐｕｓｈ通知要求に含まれるＰｕｓｈ用ＩＤに対応する宛先であるユーザ端末１００にＰｕｓｈ通知を送信する（ステップＳ６０４）。本例では、Ｐｕｓｈ通知には、電話番号Ｂと、Ｐｕｓｈ着信サーバ着信時刻が含まれる。

Ｐｕｓｈ通知を受信したユーザ端末１００では、当該Ｐｕｓｈ通知をトリガとしてＶｏＩＰアプリが起動する。そして、ユーザ装置１００は、ＳＩＰサーバ２０と接続し、ＲＥＧＩＳＴＥＲ信号（電話番号Ａ、ユーザＩＤ、パスワード含む）を送信する（ステップＳ６０５）。

上記の処理において、ユーザ端末１００は、Ｐｕｓｈ通知に含まれる電話番号Ｂ（あるいは電話番号Ｂに対応する名前）を表示することで、誰から着信があったのかを知ることができる。

また、ユーザ端末１００は、Ｐｕｓｈ通知に含まれるＰｕｓｈ着信サーバ着信時刻と、現在時刻とを比較し、Ｐｕｓｈ着信サーバ着信時刻が現在時刻よりも所定の閾値時間以上前である場合には、ＳＩＰサーバ２０への接続を行わない（着信動作を行わない）こととしてもよい。

ステップＳ６０５でＲＥＧＩＳＴＥＲ信号を受信したＳＩＰサーバ２０は、ユーザ端末１００に対して、ＩＮＶＩＴＥ信号を送信する（ステップＳ６０６）。ＳＩＰサーバ２０は、ステップＳ６０１で受信したＩＮＶＩＴＥ信号を保持しており、ステップＳ６０６でユーザ端末１００に送信する。

ＩＮＶＩＴＥ信号を受信したユーザ端末１００は、１８０ｒｉｎｇｉｎｇ応答を返す（ステップＳ６０７）。１８０ｒｉｎｇｉｎｇ応答は、ＳＩＰサーバ２０を経由して発信元のユーザ端末２００に送信される（ステップＳ６０８）。これにより、着信側で着信音が鳴動するとともに、発信側では呼び出し音が聞こえる。なお、ユーザ端末２００に対してガイダンスが流されてもよい。

ユーザ端末１００において、着信ボタンが押下される（＝受話器をとる）と、２００ ＯＫが返される（ステップＳ６０９〜Ｓ６１０）。これによりユーザ端末１００とユーザ端末２００との間で音声セッションが確立し、音声通信が行われる（ステップＳ６１１）。

第２の実施の形態においても、第１の実施の形態（図８）と同様にして、Ｐｕｓｈサーバ１０により着信拒否を行うことが可能である。また、図７に示したタイムアウト処理については、ＳＩＰサーバ２０がタイムアウトを検知することで実施することが可能である。

なお、第２の実施の形態において、Ｐｕｓｈ着信サーバ１０の機能をＳＩＰサーバ２０内に備えることとしてもよい。この場合、ＳＩＰサーバ２０が着信イベントを検知すると、ＳＩＰサーバ２０がＰｕｓｈ通知要求をＰｕｓｈサーバ３０に送信する。Ｐｕｓｈ着信サーバ１０の機能をＳＩＰサーバ２０内に備える場合、ＳＩＰサーバ２０を「Ｐｕｓｈ着信サーバ」と称してもよい。

ただし、実際のシステムでは、多数のＳＩＰサーバ２０が設置される。ＳＩＰサーバ２０とＰｕｓｈ着信サーバ１０を別々の装置とすることで、多数のＳＩＰサーバ２０のそれぞれにＰｕｓｈ着信サーバ１０の機能を入れる改造をすることなく、Ｐｕｓｈ着信に係る処理をＰｕｓｈ着信サーバ１０に集約することができる。

以上、第１、第２の実施の形態を説明したが、課題を解決するための手法として、Ｐｕｓｈ着信サーバ１０が、ユーザ端末１００に成り代わって、ユーザ端末１００のＲＥＧＩＳＴＥＲ信号をＳＩＰサーバ２０に送信する方式も考えられる。この方式でも、課題を解決できる。この方式では、Ｐｕｓｈ着信サーバ１０がユーザ端末毎のＲＥＧＩＳＴＥＲ信号をＳＩＰサーバ２０に定期的に送信するが、第１、第２の実施の形態では、このようなＲＥＧＩＳＴＥＲ信号の定期的送信を行う必要はない。

（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該ユーザ端末の識別情報を含み、前記着信制御装置を宛先とする発信信号を受信した場合に、当該識別情報に基づいて、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と、着信通知を受信した前記ユーザ端末から登録信号を受信した場合に、前記ユーザ端末を宛先とする発信信号を送信する発信信号送信手段とを備える着信制御装置が提供される。

上記の着信制御装置は、前記ユーザ端末から、前記識別情報と、前記ユーザ端末の認証情報と、前記着信通知装置において前記ユーザ端末を識別するために用いられる端末識別情報とを含む設定情報を受信した場合に、前記認証情報を前記通信制御装置に送信し、当該通信制御装置から当該認証情報に基づく認証結果を受信し、認証に成功している場合に、前記設定情報を記憶部に格納する設定手段を備えてもよい。

前記着信通知要求手段は、前記記憶部から、前記識別情報に対応する前記端末識別情報を取得し、当該端末識別情報を含む前記着信通知要求を前記着信通知装置に送信することとしてもよい。

また、本実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求する手段と、前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段とを備える着信制御装置が提供される。

上記の着信制御装置は、前記ユーザ端末から、当該ユーザ端末の識別情報と、前記着信通知装置において当該ユーザ端末を識別するために用いられる端末識別情報とを含む設定情報を受信し、当該設定情報を記憶部に格納する設定手段を備えてもよく、前記着信通知要求手段は、前記記憶部から、前記通知信号に含まれる前記ユーザ端末の識別情報に対応する前記端末識別情報を取得し、当該端末識別情報を含む前記着信通知要求を前記着信通知装置に送信することとしてもよい。

また、本実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記ユーザ端末であって、前記ユーザ端末の識別情報と前記通信制御装置の識別情報とを含む設定情報であって、前記通信制御装置に対するイベントの通知要求に使用される設定情報を前記着信制御装置に送信する設定情報送信手段と、前記イベントの発生に基づき前記ユーザ端末に対する着信通知要求を受信した前記着信通知装置から着信通知を受信し、当該着信通知を契機として、前記通信制御装置に登録信号を送信し、当該通信制御装置から前記イベントを発生させた発信信号を受信する通信制御手段とを備えるユーザ端末が提供される。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０ Ｐｕｓｈ着信サーバ
１１ 対ＳＩＰサーバ通信処理部
１２ 対ユーザ端末通信処理部
１３ Ｐｕｓｈ通知要求処理部
１４ 設定情報格納部
２０ ＳＩＰサーバ
３０ Ｐｕｓｈサーバ
１００、２００ ユーザ端末
３００ ネットワーク
１０１ Ｐｕｓｈ通知処理部
１０２ 着信設定処理部
１０３ 音声通信処理部

Claims (9)

1. ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、
   前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該ユーザ端末の識別情報を含み、前記着信制御装置を宛先とする発信信号を受信した場合に、当該識別情報に基づいて、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と、
   着信通知を受信した前記ユーザ端末から登録信号を受信した場合に、前記ユーザ端末を宛先とする発信信号を送信する発信信号送信手段と
   を備えることを特徴とする着信制御装置。
2. 前記ユーザ端末から、前記識別情報と、前記ユーザ端末の認証情報と、前記着信通知装置において前記ユーザ端末を識別するために用いられる端末識別情報とを含む設定情報を受信した場合に、前記認証情報を前記通信制御装置に送信し、当該通信制御装置から当該認証情報に基づく認証結果を受信し、認証に成功している場合に、前記設定情報を記憶部に格納する設定手段
   を備えることを特徴とする請求項１に記載の着信制御装置。
3. 前記着信通知要求手段は、前記記憶部から、前記識別情報に対応する前記端末識別情報を取得し、当該端末識別情報を含む前記着信通知要求を前記着信通知装置に送信する
   ことを特徴とする請求項２に記載の着信制御装置。
4. ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、
   前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求する手段と、
   前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と
   を備えることを特徴とする着信制御装置。
5. 前記ユーザ端末から、当該ユーザ端末の識別情報と、前記着信通知装置において当該ユーザ端末を識別するために用いられる端末識別情報とを含む設定情報を受信し、当該設定情報を記憶部に格納する設定手段を備え、
   前記着信通知要求手段は、前記記憶部から、前記通知信号に含まれる前記ユーザ端末の識別情報に対応する前記端末識別情報を取得し、当該端末識別情報を含む前記着信通知要求を前記着信通知装置に送信する
   ことを特徴とする請求項４に記載の着信制御装置。
6. ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置が実行する着信制御方法であって、
   前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該ユーザ端末の識別情報を含み、前記着信制御装置を宛先とする発信信号を受信した場合に、当該識別情報に基づいて、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求ステップと、
   着信通知を受信した前記ユーザ端末から登録信号を受信した場合に、前記ユーザ端末を宛先とする発信信号を送信する発信信号送信ステップと
   を備えることを特徴とする着信制御方法。
7. ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置が実行する着信制御方法であって、
   前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求するステップと、
   前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求ステップと
   を備えることを特徴とする着信制御方法。
8. コンピュータを、請求項１ないし５のうちいずれか１項に記載の着信制御装置の各手段として機能させるためのプログラム。
9. ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムであって、
   前記着信制御装置は、
   前記通信制御装置に対し、当該通信制御装置が前記ユーザ端末を宛先とする発信信号を受信したときに、当該発信信号を受信したことを前記着信制御装置に通知することを要求する手段と、
   前記ユーザ端末を宛先とする発信信号を受信した前記通信制御装置から、当該発信信号を受信したことを通知する通知信号を受信した場合に、前記ユーザ端末に対する着信通知要求を前記着信通知装置に送信する着信通知要求手段と
   を備えることを特徴とする通信システム。

Images