JP2015154360A - 着信制御装置、着信制御方法、及びプログラム - Google Patents

Abstract

【課題】ＶｏＩＰ通信を行うユーザ端末において、ＶｏＩＰアプリが起動していなくても着信を可能とし、バッテリー消費を削減する。
【解決手段】ユーザ端末、通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置において、前記ユーザ端末の通信識別情報と、当該ユーザ端末の端末識別情報とを格納する設定情報格納手段と、前記通信制御装置から、宛先として前記通信識別情報を指定した着信要求を受信し、前記設定情報格納手段から前記通信識別情報に対応する端末識別情報を抽出して、当該端末識別情報を含む着信通知要求を前記着信通知装置に送信する着信通知要求手段と、を備え、前記着信通知要求を受信した前記着信通知装置により、前記ユーザ端末に対して着信を知らせる着信通知が送信されるように構成する。
【選択図】図２

Description

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

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

インターネット上にあるＶｏＩＰ端末がＳＩＰを利用してＶｏＩＰ通信を行う場合、通信の安定性等から、トランスポートレイヤプロトコルとしてＴＣＰを使うことが一般的である。以降、ＳＩＰにおいてＴＣＰを使う場合、ＳＩＰ／ＴＣＰと表記することにする。

ＶｏＩＰ端末は、ＮＡＴ配下のネットワークで用いられる場合が多い。つまり、ＶｏＩＰ端末とＳＩＰサーバ間にはＮＡＴが備えられている場合が多く、そのような場合、ＶｏＩＰ端末とＳＩＰサーバ間で定期的に通信を行わなければ、ＮＡＴのポートマッピングが失われ、ＮＡＴを経由した着信ができなくなる。従って、ＳＩＰ／ＴＣＰを活用してＶｏＩＰ端末を着信可能とするためには、ＶｏＩＰアプリを常に立ち上げておくとともに、ＶｏＩＰ端末からＳＩＰサーバに対して、定期的なデータ通信を行うことが必要である。

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

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

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

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

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

本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、
前記ユーザ端末の通信識別情報と、当該ユーザ端末の端末識別情報とを格納する設定情報格納手段と、
前記通信制御装置から、宛先として前記通信識別情報を指定した着信要求を受信し、前記設定情報格納手段から前記通信識別情報に対応する端末識別情報を抽出して、当該端末識別情報を含む着信通知要求を前記着信通知装置に送信する着信通知要求手段と、を備え、
前記着信通知要求を受信した前記着信通知装置により、前記ユーザ端末に対して着信を知らせる着信通知が送信される着信制御装置が提供される。

また、本発明の実施の形態によれば、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置が実行する着信制御方法であって、
前記ユーザ端末の通信識別情報と、当該ユーザ端末の端末識別情報とを含む設定情報を前記ユーザ端末から受信し、設定情報格納手段に格納するステップと、
前記通信制御装置から、宛先として前記通信識別情報を指定した着信要求を受信し、前記設定情報格納手段から前記通信識別情報に対応する端末識別情報を抽出して、当該端末識別情報を含む着信通知要求を前記着信通知装置に送信するステップと、を備え、
前記着信通知要求を受信した前記着信通知装置により、前記ユーザ端末に対して着信を知らせる着信通知が送信される着信制御方法が提供される。

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

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

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

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

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

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

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

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

Ｐｕｓｈ着信サーバ１０は、本発明に係る装置であり、これをＰｕｓｈゲートウェイ装置と称してもよい。Ｐｕｓｈ着信サーバ１０は、Ｂ２ＢＵＡ機能を有し、ＳＩＰサーバ２０に対してＵＡとして接続され、ＳＩＰサーバ２０から発信信号（ＩＮＶＩＴＥ）を受信したときに、Ｐｕｓｈサーバ３０に対してＰｕｓｈ通知要求を送信する等の機能を備える。Ｐｕｓｈ着信サーバ１０の機能詳細については後述する。

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

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

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

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

なお、ＳＩＰサーバ２０を通信制御装置と称し、プッシュ着信サーバ１０を着信制御装置と称し、Ｐｕｓｈサーバ３０を着信通知装置と称してもよい。

図２を参照して、本実施の形態に係る通信システムにおいて、ユーザ端末２００からユーザ端末１００に対して着信がなされる際の動作概要を説明する。なお、より詳細な動作については後にシーケンス図を参照して説明する。

ユーザ端末２００において、ユーザ端末１００に対する発信操作が行われると、宛先として電話番号Ａを指定した発信信号（具体的にはＩＮＶＩＴＥ信号）がＳＩＰサーバ２０に送信される（ステップ１）。ＳＩＰサーバ２０では、電話番号Ａに対応する発信信号の転送先がＰｕｓｈ着信サーバ１０であるように登録がされているため、ＳＩＰサーバ２０は、発信信号をＰｕｓｈ着信サーバ１０に転送する（ステップ２）。

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

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

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

上記のように、本実施の形態では、Ｐｕｓｈ通信を利用してユーザ端末１００への着信を行うこととしている。

（装置構成）
次に、本実施の形態に係るＰｕｓｈ着信サーバ１０と、ユーザ端末１００の機能構成について説明する。

図３に、本実施の形態に係るＰｕｓｈ着信サーバ１０の機能構成図を示す。図３に示すように、Ｐｕｓｈ着信サーバ１０は、対ＳＩＰサーバ通信処理部１１、対ユーザ端末通信処理部１２、Ｐｕｓｈ通知要求処理部１３、設定情報格納部１４を有する。

対ＳＩＰサーバ通信処理部１１は、ＳＩＰサーバ２０との間の通信に関わる処理、ＳＩＰに基づく制御、登録処理、着信履歴管理等を行う。対ユーザ端末通信処理部１２は、ユーザ端末１００との間の通信に関わる処理、ＳＩＰに基づく制御、認証処理、登録処理等を行う。Ｐｕｓｈ通知要求処理部１３は、Ｐｕｓｈサーバ３０に対するＰｕｓｈ通知要求の送信処理、タイマ管理等を行う。また、設定情報格納部１４には、ユーザ端末１００から受信した設定情報や着信履歴が格納される。

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

図４に、本実施の形態に係るユーザ端末１００の機能構成図を示す。図４に示すように、ユーザ端末１００は、Ｐｕｓｈ通知処理部１０１、着信設定処理部１０２、音声通信処理部１０３を備える。

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

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

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

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

＜準備手順＞
図５を参照して、ユーザ端末１００においてＰｕｓｈ通知による着信を可能とするための準備のための手順を説明する。

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

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

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

設定情報を受信したＰｕｓｈ着信サーバ１０は、ＳＩＰサーバ２０に対して、ステップ１０２で受信した電話番号Ａ、ユーザＩＤ、パスワード、及びＰｕｓｈ着信サーバ１０のＩＰアドレスを含むＲＥＧＩＳＴＥＲ信号を送信する（ステップ１０３）。すなわち、Ｐｕｓｈ着信サーバ１０は、ユーザ端末１００に成り代わってＳＩＰのＲＥＧＩＳＴＥＲ（登録）を行う。この登録処理により、ＳＩＰサーバ２０は、電話番号Ａを宛先として指定したユーザ端末１００への着信呼をＰｕｓｈ着信サーバ１０のＩＰアドレス宛に転送することができる。なお、一般に、ＳＩＰのＲＥＧＩＳＴＥＲ処理では、宛先となるＩＰアドレスと名前（電話番号等）等がＳＩＰサーバに送られ、ＳＩＰサーバではこれらの情報を対応付けて登録することで、ＩＮＶＩＴＥ等のＳＩＰ信号の宛先への転送を可能としている。本実施の形態におけるＲＥＧＩＳＴＥＲ信号も同様の役割を持つ。

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

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

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

また、Ｐｕｓｈ着信サーバ１０は、ＳＩＰサーバ２０における登録状態を維持するために、ステップ１０３でのＲＥＧＩＳＴＥＲ信号と同様のＲＥＧＩＳＴＥＲ信号を定期的にＳＩＰサーバ２０に送信し、応答を受信する（ステップ１０７、１０８）。なお、例えば、ＲＥＧＩＳＴＥＲ信号の処理が連続してＸ回失敗した場合、ユーザＩＤ等の情報が有効でないとＰｕｓｈ着信サーバ１０は判断し、Ｐｕｓｈ着信サーバ１０はＲＥＧＩＳＴＥＲ信号の定期的送信を停止する。

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

発信側のユーザ端末２００において、ユーザ端末１００の電話番号Ａを入力し、発信ボタンを押下する等の発信操作が行われることで、ユーザ端末２００からＩＮＶＩＴＥ信号が送信される（ステップ２０１）。ＩＮＶＩＴＥ信号を受信したＳＩＰサーバ２０は、登録情報に基づき、電話番号Ａに対応する宛先であるＰｕｓｈ着信サーバ１０にＩＮＶＩＴＥ信号を転送する（ステップ２０２）。なお、ＩＮＶＩＴＥ信号には、宛先の電話番号Ａとともに、発信元の電話番号Ｂも含まれている。

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

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

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

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

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

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

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

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

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

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

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

なお、上記の例では、最初にＶｏＩＰアプリが起動していない場合を説明したが、最初のＶｏＩＰアプリが起動している場合でも、同様に、Ｐｕｓｈ通知をトリガとして、着信処理が実行される。

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

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

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

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

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

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

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

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

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

＜着信方法切り替え手順＞
これまでに説明したＰｕｓｈ着信のためのＰｕｓｈサーバ３０は、インターネット上に存在するため、例えばユーザ端末１００がＶＰＮに接続している場合にはＰｕｓｈ着信を行うことができない。また、Ｐｕｓｈサーバ３０の状態によっては、確実な着信が期待できないことも想定される。一方、消費電力の観点やＶｏＩＰアプリを立ち上げていなくても着信できる観点からは、Ｐｕｓｈ着信が好ましい。

本実施の形態では、このような状況を想定し、Ｐｕｓｈ着信サーバ１０を経由しないＳＩＰ／ＴＣＰ着信とＰｕｓｈ着信との間をユーザ端末１００により切り替えることを可能としている。

まず、図９を参照してＳＩＰ／ＴＣＰ着信からＰｕｓｈ着信への切り替え手順を説明する。まず、ステップ５００において、ユーザ端末１００とＳＩＰサーバ２０はＳＩＰ／ＴＣＰで接続されており、この状態では、ＳＩＰサーバ２０からユーザ端末１００へのＳＩＰ／ＴＣＰでの着信が可能である。ここから、ユーザがＰｕｓｈ着信への切り替えを希望したものとする。

まず、例えばＶｏＩＰアプリが有する切り替え機能に対するユーザによる操作に基づき、ユーザ端末１００はＵＮ−ＲＥＧＩＳＴＥＲをＳＩＰサーバ２０に送信し、ＳＩＰサーバ２０におけるＵＮ−ＲＥＧＩＳＴＥＲ（登録解除）を行うとともに、ユーザ端末１００はＳＩＰサーバ２０との間のＳＩＰ／ＴＣＰコネクションを切断する（ステップ５０１）。これにより、ＳＩＰ／ＴＣＰによるＳＩＰサーバ２０からの着信を防ぐことができる。

次に、ユーザ端末１００は、図５のステップ１０２と同様に、設定情報（電話番号Ａ、ユーザＩＤ、パスワード、Ｐｕｓｈ用ＩＤ）をＰｕｓｈ着信サーバ１０に送信することでＰｕｓｈ着信要求を行う（ステップ５０２）。

図５で説明したとおり、Ｐｕｓｈ着信サーバ１０は、設定情報を格納するとともに、ＲＥＧＩＳＴＥＲ信号をＳＩＰサーバに送信する（ステップ５０３）。

上記の処理により、ＳＩＰサーバ２０からＰｕｓｈ着信サーバ１０経由によるＰｕｓｈ通知が可能となる。

次に、図１０を参照して、Ｐｕｓｈ着信からＳＩＰ／ＴＣＰ着信への切り替え手順を説明する。まず、最初に、ステップ６００として、Ｐｕｓｈ着信サーバ１０はＳＩＰサーバ２０に定期的にＲＥＧＩＳＴＥＲ信号を送信しており、Ｐｕｓｈ着信サーバ１０とＳＩＰサーバ２０間は接続状態にある。この時点では、Ｐｕｓｈ通知によるユーザ端末１００への着信が可能である。

ここで、ユーザがＰｕｓｈ着信からＳＩＰ／ＴＣＰ着信への切り替えを希望したものとする。例えばＶｏＩＰアプリが有する切り替え機能に対するユーザによる操作に基づき、ユーザ端末１００はＰｕｓｈ着信停止要求（ＵＮ−ＲＥＧＩＳＴＥＲ要求）をＰｕｓｈ着信サーバ１０に送信する（ステップ６０１）。ＵＮ−ＲＥＧＩＳＴＥＲ要求を受信したＰｕｓｈ着信サーバ１０は、ユーザ端末１００に関する設定情報を削除するとともに、ＵＮ−ＲＥＧＩＳＴＥＲ信号をＳＩＰサーバ２０に送信することで、ＳＩＰサーバ２０における登録も解除する（ステップ６０２）。

上記の処理により、ＳＩＰサーバ２０からＰｕｓｈ着信サーバ１０経由によるＰｕｓｈ通知を防止する。

そして、ユーザ端末１００は、ＳＩＰ／ＴＣＰコネクションをＳＩＰサーバ２０との間で形成し、ＲＥＧＩＳＴＥＲ信号を送信する（ステップ６０３）。この処理によって、ＳＩＰ／ＴＣＰによる着信が可能となる。

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

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

（実施の形態のまとめ、効果等）
以上、説明したように、本実施の形態では、ＶｏＩＰ通信を行うユーザ端末、ＶｏＩＰ通信の呼制御を行う通信制御装置、着信の通知制御を行う着信制御装置、及び前記ユーザ端末に対する着信通知を送信する着信通知装置を有する通信システムにおいて使用される前記着信制御装置であって、前記ユーザ端末の通信識別情報と、当該ユーザ端末の端末識別情報とを格納する設定情報格納手段と、前記通信制御装置から、宛先として前記通信識別情報を指定した着信要求を受信し、前記設定情報格納手段から前記通信識別情報に対応する端末識別情報を抽出して、当該端末識別情報を含む着信通知要求を前記着信通知装置に送信する着信通知要求手段と、を備え、前記着信通知要求を受信した前記着信通知装置により、前記ユーザ端末に対して着信を知らせる着信通知が送信されるように構成された着信制御装置が提供される。

着信制御装置は、前記ユーザ端末から前記通信識別情報と前記端末識別情報を含む設定情報を受信し、前記通信制御装置に対して、前記着信制御装置のアドレスと前記通信識別情報とを登録するための登録処理を実行する登録手段を備えてもよい。

前記設定情報には、前記ユーザ端末の認証情報が含まれており、前記登録手段は、前記登録処理において前記認証情報を前記通信制御装置に送信し、当該通信制御装置から当該認証情報に基づく認証結果を受信し、認証に成功している場合に、前記設定情報を前記設定情報格納手段に格納するように構成してもよい。

また、着信制御装置は、前記着信通知を受信した前記ユーザ端末から送信される登録信号を受信した後に、前記着信要求を前記ユーザ端末に送信する通信制御手段を備える。

前記着信通知要求手段が送信する着信通知要求には、前記着信制御装置のアドレスが含まれてもよく、前記ユーザ端末は、当該アドレスを含む着信通知を受信し、当該アドレスを用いて前記着信制御装置との接続を行うことができる。また、前記着信通知要求手段が送信する着信通知要求には、前記着信制御装置が前記着信要求を受信した時刻である着信時刻が含まれてもよく、前記ユーザ端末は、当該着信時刻を含む着信通知を受信し、当該着信時刻と現在時刻とに基づいて着信動作の要否を決定することができる。

また、本実施の形態により、上記着信制御装置の各手段として機能させるためのプログラムが提供される。

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

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

＜実施の形態の効果等＞
本実施の形態の技術によれば、上記の効果に加えて、下記のような利点もある。

Ｐｕｓｈ通知を用いてユーザ端末への着信を可能とするために、本実施の形態のようにＰｕｓｈ着信サーバ１０を設けない場合、ＳＩＰサーバを改造してＰｕｓｈ通知に対応させる必要がある。また、この場合、ＳＩＰサーバと着端末はＰｕｓｈ通知が成功した後は通常通りＳＩＰ／ＴＣＰの通信を行う必要があり、ＳＩＰサーバはＰｕｓｈ通知における状態、ＳＩＰ／ＴＣＰにおける状態という２つの状態を管理する必要がある。更に、ＶｏＩＰアプリのアップデートを未実施の利用者、Ｐｕｓｈ通知に対応していないサービス（ＶＰＮなど）、Ｐｕｓｈ通知をしたくない利用者等が存在するため、Ｐｕｓｈ通知が可能な状況であってもＳＩＰ／ＴＣＰの対応が必要である。

上記のように、本実施の形態の技術を用いない場合、ＳＩＰサーバに対する多大な改造が必要となってしまう。ＳＩＰサーバはスケーラビリティの観点から、機能は単純である必要があるが、上記のように多大な改造を行うと、この要求条件を満たすことができない。

他方、本実施の形態のように、Ｐｕｓｈ着信サーバ１０を導入する方式としたことで、ＳＩＰサーバ等の既存ＶｏＩＰシステムに対しての追加開発せずにＶｏＩＰアプリへの着信の手段としてＰｕｓｈ着信への対応を可能としている。そのため、ＳＩＰサーバに対してＰｕｓｈ着信に対する追加開発をするよりも、開発費用の抑制及び対応までの期間の短縮が期待できる。

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

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

Claims (10)

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

Images