JP2016195318A - 通信システム、着信制御サーバ、ユーザ端末、着信制御方法、及びプログラム - Google Patents

Abstract

【課題】ユーザ端末がブラウザを用いてメディア通信を行う通信方式において、ブラウザを常に活性化しておかなくても着信を受けることを可能とする。【解決手段】通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて、前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信し、前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させる。【選択図】図１０

Description

本発明は、Ｐｕｓｈ通知を利用して音声通話等の着信を行う技術に関連するものである。

近年、スマートフォン等のユーザ端末にインストールすることで、音声通話を可能とする音声通話アプリケーション（以下、音声通話アプリと呼ぶ）が普及している。また、音声通話アプリを常に立ち上げておかなくても着信が可能となるような、プッシュ着信機能も利用され始めている。

一方、最近では、ＯＳ（オペレーティングシステム）やアプリストアの利用条件等に依存せず、Ｗｅｂブラウザ（以下、ブラウザ）上での様々なサービスを可能とするＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ−Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の技術が注目されている。当該技術の進展により、今後は、ＷｅｂＲＴＣによるブラウザ機能での音声通話も近い将来普及すると想定されている。

特開２０１４−３３６３号公報

ＷｅｂＲＴＣは、ユーザ端末におけるブラウザを用いてビデオ、音声、テキスト等のメディア通信をリアルタイムで行うことを可能とする技術である。

上記のようにＷｅｂＲＴＣではブラウザを用いることから、ユーザ端末においてブラウザが起動していなければ、ＷｅｂＲＴＣを用いたメディア通信を行うことができない。メディア通信を開始しようとする側（発信側）では、発信を行いたいときにブラウザを立ち上げれば済むが、着信側では、いつ着信するかわからないので、着信を受けるには常にブラウザを起動していなければならない。ブラウザが起動していなければ、着信を受けることはできない。また、ブラウザが起動していても、活性化（前面に表示）されていなければ着信を受けることができない。

しかし、スマートフォン等のユーザ端末においては通常、Ｗｅｂサイトを閲覧するときにしかブラウザを起動・活性化しないものであり、頻繁に来るとは限らない着信に対して常にブラウザを起動・活性化しておくことは現実的ではない。

本発明は、上記の点に鑑みてなされたものであり、ユーザ端末がブラウザを用いてメディア通信を行う通信方式において、ブラウザを常に活性化しておかなくても着信を受けることを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムであって、
前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信し、
前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させる
通信システムが提供される。

また、本発明の実施の形態によれば、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて実行される着信制御方法であって、
前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信するステップと、
前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させるステップと
を備える着信制御方法が提供される。

また、本発明の実施の形態によれば、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおける前記着信制御サーバであって、
着信ユーザ端末の登録情報を格納する登録情報格納手段と、
前記登録情報を用いて、前記着信ユーザ端末の代理として、前記通信制御サーバに対して登録要求を定期的に送信する手段と、
発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である前記着信ユーザ端末に対して着信通知を送信する手段と
を備える着信制御サーバが提供される。

また、本発明の実施の形態によれば、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて用いられるユーザ端末であって、
前記動作情報提供サーバにアクセスして動作情報を取得する機能を有する通信処理手段と、
発信ユーザ端末からの接続要求に基づいて前記着信制御サーバから送信された着信通知を受信したことに応じて、前記通信処理手段に対して前記動作情報提供サーバを示す接続先情報を通知する着信処理手段と、を備え、
前記通信処理手段は、前記接続先情報を用いて前記動作情報提供サーバにアクセスして前記動作情報を取得し、当該動作情報に基づいて前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行する
ユーザ端末が提供される。

ユーザ端末がブラウザを用いてメディア通信を行う通信方式において、ブラウザを常に活性化しておかなくても着信を受けることを可能とする技術が提供される。

本発明の実施の形態に係る通信システムの全体構成図である。 Ｐｕｓｈ着信サーバ１０の構成図である。 Ｐｕｓｈ着信サーバ１０の他の構成例を示す構成図である。 ユーザ端末１００の構成図である。 登録処理を説明するためのシーケンス図である。 登録処理を説明するためのシーケンス図である。 解除処理を説明するためのシーケンス図である。 解除処理を説明するためのシーケンス図である。 待ち受け処理を説明するためのシーケンス図である。 プロキシ型の着信処理を説明するためのシーケンス図である。 フォーキング型の着信処理を説明するためのシーケンス図である。 プロキシ型の発信処理を説明するためのシーケンス図である。 フォーキング型の発信処理を説明するためのシーケンス図である。 登録処理の変形例を説明するための図である。 プロキシ型の着信処理の変形例を説明するためのシーケンス図である。 フォーキング型の着信処理の変形例を説明するためのシーケンス図である。

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

例えば、以下の実施の形態では、ブラウザを用いる通信方式としてＷｅｂＲＴＣを例にとって説明しているが、本発明は、ＷｅｂＲＴＣ以外のブラウザを用いる通信方式にも適用可能である。なお、「ブラウザ」は、ＨＴＭＬ、ＷｅｂＲＴＣ等のメディア通信を解釈する機能を有するアプリケーション全般を含むものである。また、以下の実施の形態では、ユーザ端末間の通信の例として音声通信を例に挙げているが、本発明は音声通信に限らず、ビデオ通信、チャット、会議、テキスト通信、ファイル送信等のメディア通信全般に適用可能である。

（システム構成）
図１に、本発明の実施の形態に係る通信システムの全体構成図を示す。図１に示すように、本実施の形態に係る通信システムは、Ｐｕｓｈ着信サーバ１０、ＷｅｂＲＴＣサーバ２０、Ｐｕｓｈサーバ３０、Ｗｅｂサーバ４０を有し、これらがネットワーク３００に接続されている。また、ユーザ端末１００、２００が、ネットワーク３００に接続されている。なお、ＷｅｂＲＴＣサーバ２０、Ｐｕｓｈ着信サーバ１０、Ｗｅｂサーバ４０はそれぞれ、通信制御サーバ、着信制御サーバ、動作情報提供サーバと称してもよい。

各ユーザ端末は、各種アプリケーションを実行できるスマートフォン等の端末である。本実施の形態では、ユーザ端末１００、２００には、ＷｅｂＲＴＣに対応したブラウザが搭載されている。また、ユーザ端末１００、２００には、Ｐｕｓｈサーバ３０からＰｕｓｈ通知を受信し、当該Ｐｕｓｈ通知に含まれるＷｅｂサーバ３０の情報（ＵＲＬ）をブラウザに通知する機能を備える。

Ｐｕｓｈ着信サーバ１０は、ユーザ端末の代わりにＷｅｂＲＴＣサーバ２０のクライアントとして機能し、ＷｅｂＲＴＣサーバ２０からユーザ端末への着信を受けた場合には、当該ユーザ端末にＰｕｓｈサーバ３０経由でＰｕｓｈ通知を送信する等の機能を備える。ユーザ端末１００（２００）及びＰｕｓｈ着信サーバ１０の機能の詳細については後述する。

ＷｅｂＲＴＣサーバ２０は、ＷｅｂＲＴＣによりユーザ端末間を接続するための制御信号等の送受信制御を行う。また、ＷｅｂＲＴＣによる端末間の接続では、ＮＡＴ越え等のためにＳＴＵＮサーバ、ＴＵＲＮサーバ等が用いられるが、ＷｅｂＲＴＣサーバ２０がＳＴＵＮサーバ及びＴＵＲＮサーバの機能を含んでもよい。また、ＷｅｂＲＴＣサーバ２０が音声等のメディアの中継機能を含んでもよい。

本実施の形態では、ユーザ端末間を接続するための制御信号のプロトコルとして、ＳＩＰをベースとしたプロトコルを使用することを想定しているが、制御信号のプロトコルはＳＩＰに限られず、他のプロトコルを使用することも可能である。

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

Ｗｅｂサーバ４０は、ユーザ端末からの接続（リクエスト）を受けて、当該ユーザ端末に対してＨＴＭＬファイルをダウンロードするサーバである。当該ＨＴＭＬファイルはユーザ端末のブラウザ上で動作し、ユーザ端末上でＷｅｂページの表示を行う。また、ＨＴＭＬファイルには、ＷｅｂＲＴＣのクライアント動作規定（スクリプト等のプログラム）が記述されており、ブラウザにより当該記述内容（動作情報）が解釈されることにより、ユーザ端末はＷｅｂＲＴＣのプロトコルに従った制御信号の送受信等を行う。

ネットワーク３００は、例えば、インターネット、プライベートネットワーク、インターネットとプライベートネットワークとが接続されたネットワーク等である。

（Ｐｕｓｈ着信サーバ１０の構成）
次に、Ｐｕｓｈ着信サーバ１０の構成例を図２、図３を参照して説明する。図２に示す例は、ユーザ端末１００への着信後における制御信号のＷｅｂＲＴＣサーバ２０−ユーザ端末１００間でのやりとりをＰｕｓｈ着信サーバ１０がプロキシとして中継する場合の構成である。

図２に示す例において、Ｐｕｓｈ着信サーバ１０は、対ＷｅｂＲＴＣサーバ通信処理部１１、対ユーザ端末通信処理部１２、Ｐｕｓｈ通知要求処理部１３、登録情報格納部１４を有する。

対ＷｅｂＲＴＣサーバ通信処理部１１は、ＷｅｂＲＴＣサーバ２０との間の制御信号の送受信等を行う。対ＷｅｂＲＴＣサーバ通信処理部１１は、ＷｅｂＲＴＣサーバ２０との間でメディア信号の送受信を行ってもよい。

対ユーザ端末通信処理部１２は、ユーザ端末との間の制御信号の送受信等を行う。対ユーザ端末通信処理部１２は、ユーザ端末との間でメディア信号の送受信を行ってもよい。

Ｐｕｓｈ通知要求処理部１３は、対ＷｅｂＲＴＣサーバ通信処理部１１により受信した接続要求（例：ＩＮＶＩＴＥ）に基づき、Ｐｕｓｈサーバ３０にＰｕｓｈ通知要求を送信する。また、登録情報格納部１４には、ユーザ端末１００から受信した登録情報が格納される。なお、Ｐｕｓｈ着信サーバ１０がＰｕｓｈサーバ３０にＰｕｓｈ通知要求を送信することは、Ｐｕｓｈ着信サーバ１０が宛先のユーザ端末に対してＰｕｓｈ通知を送信することと実質的に同じことである。

図３は、ユーザ端末１００への着信後における制御信号が、Ｐｕｓｈ着信サーバ１０を介さずに、ＷｅｂＲＴＣサーバ２０−ユーザ端末１００間でやりとりされる場合の構成である。図３に示すように、対ユーザ端末通信処理部１２が備えられていない点が図２に示す構成と異なる。

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

また、Ｐｕｓｈ着信サーバ１０が、ＷｅｂＲＴＣサーバ２０、Ｗｅｂサーバ４０、Ｐｕｓｈサーバ３０のうちの１つ又は複数の機能を含むこととしてもよい。
（ユーザ端末１００の構成）
次に、ユーザ端末１００の構成例を図４を参照して説明する。ユーザ端末１００とユーザ端末２００は同じ構成を有するため、ここでは代表としてユーザ端末１００について説明する。

ユーザ端末１００は、着信アプリケーション１０１とブラウザ１０２を含む。前述したように、ユーザ端末１００は例えばスマートフォンであり、ＣＰＵ、メモリ、通信ＩＦ、操作、表示部（タッチパネル）等のハードウェアを含む。

着信アプリケーション１０１（以下、着信アプリ１０１）は、上記ハードウェアと協調して着信処理部１１０として機能する。また、ブラウザ１０２は、上記ハードウェアと協調して通信処理部１２０、メディア処理部１３０として機能する。

着信処理部１１０は、Ｐｕｓｈサーバ３０からＰｕｓｈ通知を受けたことを契機として、アクセス先のＵＲＬをブラウザ１０２に通知する。ここで、着信処理部１１０は、ブラウザ１０２が活性化していない場合は活性化させてからＵＲＬを通知する。当該ＵＲＬは、着信処理部１１０の記憶手段（メモリ等）に予め保持されていてもよいし、Ｐｕｓｈ通知に含まれていてもよい。ＵＲＬを予め保持する方法として、着信アプリ１０１に予めＵＲＬを設定しておく方法（つまり、ＵＲＬが設定された着信アプリを取得）や、着信処理部１１０がサービス提供会社からＵＲＬをダウンロードする方法等がある。

また、上記「活性化させる」とは、ブラウザ１０２が起動されていない状態から起動させて活性化させること、及び、起動されているがバックグラウンドにあり、活性化されていない状態から活性化させることを含む。

また、着信処理部１１０は、Ｐｕｓｈ通知に含まれる発信元ＩＤやメッセージ等をユーザ端末１００の表示部に表示する機能、Ｐｕｓｈ通知に含まれる発信元ＩＤと現在時刻（着信時刻）を記憶手段に格納することで、着信履歴を保持し、ユーザからの操作に応じて着信履歴を表示する機能を含む。なお、発信元ＩＤやメッセージ等は、着信が完了した後でも表示して見ることができる。

また、着信処理部１１０は、Ｗｅｂサーバ４０へのログイン操作を不要とするためのパスコード（パスフレーズ）を予め格納し、ＵＲＬとパスコードから認証情報付きＵＲＬを作成し、これをブラウザ１０２に通知することとしてもよい。認証情報付きＵＲＬは、例えばＵＲＬとパスコードを連結したものである。パスコードを予め保持する方法として、着信アプリ１０１に予めパスコードを設定しておく方法（つまり、パスコードが設定された着信アプリを取得）や、着信処理部１１０がサービス提供会社からパスコードを取得する方法等がある。

また、Ｐｕｓｈ着信サーバ１０で作成された認証情報付きＵＲＬを含むＰｕｓｈ通知を受信し、これをブラウザ１０２に通知してもよい。また、着信処理部１１０が予め認証情報付きＵＲＬを保持していることとしてもよい。

ブラウザ１０２における通信処理部１２０は、Ｗｅｂサーバ４０から受信するＨＴＭＬファイルに基づいて、制御信号／メディア信号の送受信を行う。メディア処理部１３０は、音声等のメディア信号の符号化／復号化、入出力等を行う。

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

以下、本実施の形態に係る通信システムの動作を各処理毎にシーケンス図を参照して説明する。

前述したように、以下で説明する本実施の形態のシグナリング処理は、ＳＩＰに基づいて行うことを想定しており、シグナリングメッセージにおいて括弧内にＳＩＰでのメッセージ例を示しているが、ＳＩＰを用いることは一例に過ぎない。

（登録処理）
まず、ユーザ端末１００からＷｅｂＲＴＣサーバ２０への登録を行う際の登録処理を説明する。本実施の形態においては、ユーザ端末１００のブラウザ１０２に対し、Ｐｕｓｈ着信を行わせるか否かの設定が可能である。

図５では、Ｐｕｓｈ着信なしの場合の登録処理をステップＳ１０１〜Ｓ１０４に示し、Ｐｕｓｈ着信がある場合の登録処理をステップＳ１０５〜Ｓ１１２に示している。

Ｐｕｓｈ着信なしの場合の登録処理のステップＳ１０１において、ユーザ端末１００はＷｅｂサーバ４０に接続し（ステップＳ１０１）、ＨＴＭＬファイルをダウンロードする（ステップＳ１０２）。なお、ステップＳ１０１の接続の際には、例えば、予めＩＤ／パスワードによる認証（ログイン）が行われる。

次に、ユーザ端末１００は登録要求（例：ＲＥＧＩＳＴＥＲ）をＷｅｂＲＴＣサーバ２０に送信する（ステップＳ１０３）。登録要求の送信は、例えば、ＨＴＭＬファイルを解析したブラウザにより自動的に行うこととしてもよいし、Ｗｅｂページ上でユーザが操作を行うことで実施してもよい。

登録要求のメッセージには、ＩＤ、パスワード、識別子（例：電話番号）が含まれる。ＩＤ／パスワードは、例えばＳＩＰ−ＩＤとパスワードであり、これらによりＷｅｂＲＴＣサーバ２０においてユーザ端末１００の認証が行われる。登録要求により、ＷｅｂＲＴＣサーバ２０において、ユーザ端末１００の識別子とアドレス（ＩＰアドレス等）とが登録される。登録に成功すると肯定応答（例：２００ＯＫ）が返される（ステップＳ１０４）。

次に、Ｐｕｓｈ着信を設定した場合の登録処理を説明する。ユーザ端末１００はＷｅｂサーバ４０に接続し（ステップＳ１０５）、ＨＴＭＬファイルをダウンロードする（ステップＳ１０６）。

次に、ユーザ端末１００は、登録処理要求をＷｅｂサーバ４０に送信し（ステップＳ１０７）、Ｗｅｂサーバ４０が当該登録処理要求をＰｕｓｈ着信サーバ１０に送信する（ステップＳ１０８）。当該登録処理要求には、前述したＩＤ、パスワード、及び識別子に加えて、Ｐｕｓｈ通信がＯＮであることを示す情報、及び、Ｗｅｂサーバ４０のＵＲＬが含まれる。当該ＵＲＬはＷｅｂサーバ４０において付加されたものである。当該ＵＲＬは、ユーザ端末１００への着信時に、Ｐｕｓｈ通知に含められてユーザ端末１００に通知される。ただし、ユーザ端末１００の着信処理部１０１に当該ＵＲＬが予め保持されている場合、当該ＵＲＬを登録処理要求に含めないこととしてもよい。

Ｐｕｓｈ着信サーバ１０は、ＩＤ、パスワード、識別子、Ｐｕｓｈ通知＝ＯＮ、ＵＲＬとを対応付けて登録情報格納部１４に格納する。

また、ユーザ端末１００から送信される登録処理要求の中に、Ｐｕｓｈ用ＩＤが含まれ、当該ＩＤが他の登録情報とともにＰｕｓｈ着信サーバ１０において登録されてもよい。当該Ｐｕｓｈ用ＩＤは、Ｐｕｓｈサーバ３０がＰｕｓｈ通知の宛先を識別するためのＩＤである。Ｐｕｓｈサーバ３０は、当該ＩＤを含むＰｕｓｈ通知要求を受信したときに、当該ＩＤから識別される宛先にＰｕｓｈ通知を送信することができる。ただし、これは一例であり、他の方式でＰｕｓｈ通知の宛先を識別することとしてもよい。本実施の形態では、Ｐｕｓｈ通知要求にＰｕｓｈ用ＩＤが含まれ、これにより宛先を識別することとしている。なお、どのようにしてＰｕｓｈ通知を送信するかは、様々な方法が可能であり、Ｐｕｓｈ用ＩＤを用いることは一例に過ぎないため、以下では、Ｐｕｓｈ用ＩＤの記述は行っていない。

Ｐｕｓｈ着信サーバ１０は、ＩＤ、パスワード、及び識別子を含む登録要求（例：ＲＥＧＩＳＴＥＲ）をＷｅｂＲＴＣサーバ２０に送信する（ステップＳ１０９）。登録要求により、ＷｅｂＲＴＣサーバ２０において、ユーザ端末１００の識別子とアドレス（ＩＰアドレス等）とが登録される。登録に成功すると肯定応答（２００ＯＫ）が返される（ステップＳ１１０）。また、Ｐｕｓｈ着信サーバ１０から、登録が完了したことを示す登録通知が返される（ステップＳ１１１、Ｓ１１２）。

図５のステップＳ１０７〜Ｓ１１２に示す例は、Ｗｅｂサーバ４０を経由して登録処理を行う例であるが、ユーザ端末１００から、Ｗｅｂサーバ４０を経由せずに登録処理を行うこととしてもよい。その場合のシーケンス図を図６に示す。図６に示すように、ユーザ端末１００の着信アプリ１０１から登録処理要求が送信される（ステップＳ１５１）。Ｐｕｓｈ着信サーバ１０において登録情報が格納されるとともに、登録要求がＷｅＲＣＴサーバ２０に送信され（ステップＳ１５２）、肯定応答、登録通知の返信が行われる（ステップＳ１５３、Ｓ１５４）。

（解除処理）
次に、登録解除処理を説明する。前述したように、本実施の形態においては、ユーザ端末１００のブラウザに対し、Ｐｕｓｈ着信を行わせるか否かの設定が可能である。

図７では、Ｐｕｓｈ着信なしの場合の解除処理をステップＳ１６１〜Ｓ１６４に示し、Ｐｕｓｈ着信の設定がある場合の解除処理をステップＳ１６５〜Ｓ１７２に示している。

Ｐｕｓｈ着信なしの場合の解除処理のステップＳ１６１において、ユーザ端末１００はＷｅｂサーバ４０に接続し（ステップＳ１６１）、ＨＴＭＬファイルをダウンロードする（ステップＳ１６２）。

次に、ユーザ端末１００は解除要求（例：ＵＮ−ＲＥＧＩＳＴＥＲ）をＷｅｂＲＴＣサーバ２０に送信する（ステップＳ１６３）。解除要求により、ＷｅｂＲＴＣサーバ２０において、ユーザ端末１００の登録情報が解除され、肯定応答（例：２００ＯＫ）が返される（ステップＳ１６４）。

次に、Ｐｕｓｈ着信を設定した場合の解除処理を説明する。ユーザ端末１００はＷｅｂサーバ４０に接続し（ステップＳ１６５）、ＨＴＭＬファイルをダウンロードする（ステップＳ１６６）。

次に、ユーザ端末１００は、解除処理要求をＷｅｂサーバ４０に送信し（ステップＳ１６７）、Ｗｅｂサーバ４０が当該解除処理要求をＰｕｓｈ着信サーバ１０に送信する（ステップＳ１６８）。ユーザ端末１００から送信されてＰｕｓｈ着信サーバ１０に通知される解除処理要求には、ＩＤ、パスワード、及び識別子に加えて、Ｐｕｓｈ通知がＯＦＦであることを示す情報が含まれる。

Ｐｕｓｈ着信サーバ１０は、ユーザ端末１００に関する登録情報を解除（削除）し、ＩＤ、パスワード、及び識別子を含む解除要求をＷｅｂＲＴＣサーバ２０に送信する（ステップＳ１６９）。解除要求により、ＷｅｂＲＴＣサーバ２０において、ユーザ端末１００の登録情報が解除され、肯定応答（例：２００ＯＫ）が返される（ステップＳ１７０）。また、Ｐｕｓｈ着信サーバ１０から、解除が完了したことを示す解除通知が返される（ステップＳ１７１、Ｓ１７２）。

図７のステップＳ１６７〜Ｓ１７２に示す例は、Ｗｅｂサーバ４０を経由して解除処理を行う例であるが、ユーザ端末１００から、Ｗｅｂサーバ４０を経由せずに解除処理を行うこととしてもよい。その場合のシーケンス図を図８に示す。図８に示すように、ユーザ端末１００の着信アプリ１０１から解除処理要求が送信される（ステップＳ１８１）。Ｐｕｓｈ着信サーバ１０において登録情報が解除されるとともに、解除要求がＷｅＲＣＴサーバ２０に送信され（ステップＳ１８２）、肯定応答、登録通知の返信が行われる（ステップＳ１８３、Ｓ１８４）。

（待ち受け処理）
ＷｅｂＲＴＣサーバ２０においてユーザ端末１００の登録が行われた後、着信を待ち受けるためには、登録状態を維持しておくことが必要である。そのため、ＷｅｂＲＴＣサーバ２０に定期的に登録要求を送信する。これを待ち受け処理と呼ぶ。

図９に待ち受け処理のシーケンス図を示す。ステップＳ２０１〜Ｓ２０２はＰｕｓｈ着信設定なしの場合を示し、ステップＳ２０３〜Ｓ２０４は、Ｐｕｓｈ着信設定ありの場合を示す。

ステップＳ２０１〜Ｓ２０２に示すように、Ｐｕｓｈ着信設定なしの場合は、ユーザ端末１００（ブラウザ）からＷｅｂＲＴＣサーバ２０に定期的に登録要求の送信が行われる。Ｐｕｓｈ着信設定ありの場合、ステップＳ２０３〜Ｓ２０４に示すように、Ｐｕｓｈ着信サーバ１０は、ユーザ端末１００の代理として、定期的に登録要求をＷｅｂＲＴＣサーバ２０に送信し、登録状態を維持する。

（プロキシ型の着信処理）
次に、ユーザ端末２００が発信を行い、ユーザ端末１００に着信する場合の処理を図１０を参照して説明する。図１０は、着信後に、Ｐｕｓｈ着信サーバ１０が、ＷｅｂＲＴＣサーバ２０とユーザ端末１００間の制御信号を中継するプロキシサーバとして機能する場合の処理例を示す図である。また、図１０では、ユーザ端末１００のブラウザ１０２によるＷｅｂサーバ４０への接続を分かり易くするために、ユーザ端末１００における着信アプリ１０１とブラウザ１０２とを分けて記載している。

発信側のユーザ端末２００において、例えば、Ｗｅｂサーバ４０から提供されるＷｅｂページ上で、ユーザ端末１００を接続先として選択する操作が行われることにより、ユーザ端末１００の識別子（電話番号等）を含む接続要求（例：ＩＮＶＩＴＥ）が送信される（ステップＳ３０１）。接続要求は、ＷｅｂＲＴＣサーバ２０を経由してＰｕｓｈ着信サーバ１０に送信される（ステップＳ３０２）。

Ｐｕｓｈ着信サーバ１０は、登録情報格納部１４に格納されている登録情報を参照し、接続要求で指定された識別子に対応するユーザ端末１００に対してＰｕｓｈ通知を要求するＰｕｓｈ通知要求をＰｕｓｈサーバ２０に送信する（ステップＳ３０３）。Ｐｕｓｈ通知要求には、発信元（ユーザ端末２００）を識別する識別子である発信元ＩＤ、及び、Ｗｅｂサーバ４０のＵＲＬ等が含まれる。なお、ユーザ端末１００の着信アプリ１０１が既にＵＲＬを有している場合、ここでＵＲＬを含めないこととしてもよい。また、Ｐｕｓｈ通知要求には、ＷｅｂＲＴＣサーバ２０等から提供されるチャットのプレゼンス情報が含まれていてもよい。

また、ステップＳ３０２で接続要求を受信したＰｕｓｈ着信サーバ１０は、ＷｅｂＲＴＣサーバ２０を介してユーザ端末２００に対して暫定応答（例：１００ｔｒｙｉｎｇ）を返す（ステップＳ３０８）。なお、暫定応答を返さないこととしてもよい。

Ｐｕｓｈサーバ３０は、Ｐｕｓｈ通知要求に基づいて、ユーザ端末１００の着信アプリ１０１に対してＰｕｓｈ通知を送信する（ステップＳ３０４）。Ｐｕｓｈ通知には、上記のとおりの発信元ＩＤ、ＵＲＬ等が含まれる。

Ｐｕｓｈ通知を受信したユーザ端末１００の着信アプリ１０１は、例えば、Ｐｕｓｈ通知に含まれる発信元ＩＤ（あるいは当該ＩＤに紐づけられた発信元ユーザのプロフィール）をユーザ端末１００の画面に表示する。また、着信アプリ１０１は、発信元ＩＤと現在時刻（着信時刻）を着信履歴としてメモリ等の記憶部に格納する。

そして、着信アプリ１０１は、ブラウザ１０２に対してＵＲＬを通知する（ステップＳ３０５）。このとき、例えば、ブラウザ１０２が起動していない場合、着信アプリ１０１は、ブラウザ１０２を起動してからＵＲＬを通知する。また、ブラウザ１０２が起動しているが、活性化されていない場合（前面にない場合）、ブラウザ１０２を活性化させてＵＲＬを通知する。

ＵＲＬの通知を受けたブラウザ１０２により、ユーザ端末１００は、当該ＵＲＬに対応するＷｅｂサーバ４０に接続し、ＨＴＭＬファイルをダウンロードする（ステップＳ３０６、Ｓ３０７）。ステップＳ３０６での接続の際に、必要に応じて、ＩＤ／パスワードを用いてＷｅｂサーバ４０へのログインを行う。

ステップＳ３０７でダウンロードしたＨＴＭＬファイルがブラウザ１０２上で実行されることにより、ユーザ端末１００は着信処理（着信に対する接続処理）を実行する。ここでは、ユーザ端末１００は、まず登録要求（例：ＲＥＧＩＳＴＥＲ）をＰｕｓｈ着信サーバ１０に送信し（ステップＳ３０９）、Ｐｕｓｈ着信サーバ１０は登録要求をＷｅｂＲＴＣサーバに送信する（ステップＳ３１０）。

上記登録要求には、ＩＤ／パスワードが含まれており、これにより、Ｐｕｓｈ着信サーバ１０、及びＷｅｂＲＴＣサーバ２０において、登録されたユーザ端末１００からの信号であることを確認する認証処理が行われる。ここでは認証に成功したものとする。

ＷｅｂＲＴＣサーバ２０から肯定応答がＰｕｓｈ着信サーバ１０に返され（ステップＳ３１１）、また、Ｐｕｓｈ着信サーバ１０から肯定応答がユーザ端末１００に返される（ステップＳ３１２）。

ステップＳ３１１で肯定応答を受信したＰｕｓｈ着信サーバ１０は、ステップＳ３１３において接続要求（例：ＩＮＶＩＴＥ）をユーザ端末１００に送信する。この接続要求は、ステップＳ３０２の登録要求に対応するもの（同じダイアログ）である。

接続要求を受信したユーザ端末１００では、例えば着信を知らせる音が鳴動し、ユーザが電話を受ける旨の操作を行うことで、肯定応答がＰｕｓｈ着信サーバ１０に送信される（ステップＳ３１４）。肯定応答は発信元のユーザ端末２００に転送される（ステップＳ３１５、Ｓ３１６）。

上記のような制御信号の送受信を経て、ユーザ端末２００とユーザ端末１００との間で音声信号の送受信が可能となる。なお、図１０では、ＷｅｂＲＴＣサーバ２０が音声信号を中継する場合の例を示しているが、ネットワーク環境によっては、ユーザ端末１００とユーザ端末２００が直接に音声信号の通信を行うこととしてもよい。

（フォーキング型の着信処理）
次に、ユーザ端末２００が発信を行い、ユーザ端末１００に着信する場合において、着信後の制御信号のやりとりをＷｅｂＲＴＣサーバ２０とユーザ端末１００との間で直接に行う処理例を図１１を参照して説明する。図１１に示す例は、ＷｅｂＲＴＣサーバ２０が、複数の接続要求を並行して送信するのでフォーキング型と呼ぶ。図１１においても、ユーザ端末１００のブラウザ１０２によるＷｅｂサーバ４０への接続を分かり易くするために、ユーザ端末１００における着信アプリ１０１とブラウザ１０２とを分けて記載している。以下では、図１１の処理と同じ処理については簡潔に説明する。

発信側のユーザ端末２００は、ユーザ端末１００の識別子（電話番号等）を含む接続要求（例：ＩＮＶＩＴＥ）を送信する（ステップＳ３５１）。接続要求は、ＷｅｂＲＴＣサーバ２０を経由してＰｕｓｈ着信サーバ１０に送信される（ステップＳ３５２）。

Ｐｕｓｈ着信サーバ１０は、登録情報を参照し、接続要求で指定された識別子に対応するユーザ端末１００に対してＰｕｓｈ通知を要求するＰｕｓｈ通知要求をＰｕｓｈサーバ３０に送信する（ステップＳ３５３）。

また、ステップＳ３５２で接続要求を受信したＰｕｓｈ着信サーバ１０は、ＷｅｂＲＴＣサーバ２０を介してユーザ端末２００に対して暫定応答（例：１００ｔｒｙｉｎｇ）を返す（ステップＳ３５８）。なお、暫定応答を返さないこととしてもよい。

Ｐｕｓｈサーバ３０は、Ｐｕｓｈ通知要求に基づいて、ユーザ端末１００の着信アプリ１０１に対してＰｕｓｈ通知を送信する（ステップＳ３５４）。Ｐｕｓｈ通知には、上記のとおりの発信元ＩＤ、ＵＲＬ等が含まれる。

着信アプリ１０１は、ブラウザ１０２に対してＵＲＬを通知する（ステップＳ３５５）。ＵＲＬの通知を受けたブラウザ１０２により、ユーザ端末１００は、当該ＵＲＬに対応するＷｅｂサーバ４０に接続し、ＨＴＭＬファイルをダウンロードする（ステップＳ３５６、Ｓ３５７）。

ステップＳ３５７でダウンロードしたＨＴＭＬファイルがブラウザ１０２で実行されることにより、ユーザ端末１００は着信処理（着信に対する接続処理）を実行する。ここでは、ユーザ端末１００はまず登録要求（例：ＲＥＧＩＳＴＥＲ）をＷｅｂＲＴＣサーバ２０に送信する（ステップＳ３５９）。

上記登録要求には、ＩＤ／パスワードが含まれており、これにより、ＷｅｂＲＴＣサーバ２０において、登録されたユーザ端末１００からの信号であることを確認する認証処理が行われる。ここでは認証に成功したものとする。

ＷｅｂＲＴＣサーバ２０から肯定応答がユーザ端末１００に返される（ステップＳ３６０）。

続いて、ＷｅｂＲＴＣサーバ２０は、ユーザ端末１００に接続要求（例：ＩＮＶＩＴＥ）を送信する（ステップＳ３６１）。当該接続要求には、ステップＳ３５１の接続要求で通知された発信元の情報が含まれている。ただし、ステップＳ３５１での接続要求とはダイアログが異なる。

ステップＳ３６１で接続要求を受信したユーザ端末１００では、例えば着信を知らせる音が鳴動し、ユーザが電話を受ける旨の操作を行うことで、肯定応答がＷｅｂＲＴＣサーバ２０に送信される（ステップＳ３６２）。肯定応答は発信元のユーザ端末２００に転送される（ステップＳ３６３）。

一方、ステップＳ３５２でＷｅｂＲＴＣサーバ２０から接続要求を受信していたＰｕｓｈ着信サーバ１０は、タイムアウトエラー（例：４８０）をＷｅｂＲＴＣサーバ２０に返す（ステップＳ３６４）。

上記の制御信号の送受信を経て、ユーザ端末２００とユーザ端末１００との間で音声信号の送受信が可能となる。

（プロキシ型の発信処理）
次に、ユーザ端末１００が発信を行い、ユーザ端末２００に着信する場合の処理を図１２を参照して説明する。図１２は、Ｐｕｓｈ着信サーバ１０が、ＷｅｂＲＴＣサーバ２０とユーザ端末１００間の制御信号を中継するプロキシサーバとして機能する場合の処理例を示す図である。また、着信側はＰｕｓｈ通知の設定を行っていないものとする。

発信側のユーザ端末１００がＷｅｂサーバ４０に接続し（ステップＳ４０１）、ＨＴＭＬファイルをダウンロードする（ステップＳ４０２）。これにより、例えば、ユーザ端末１００に、着信先を選択可能な情報を含むＷｅｂページが表示される。当該Ｗｅｂページ上において、ユーザ端末２００を接続先として選択する操作が行われることにより、ユーザ端末２００の識別子（電話番号等）を含む接続要求（例：ＩＮＶＩＴＥ）が送信される（ステップＳ４０３）。接続要求は、Ｐｕｓｈ着信サーバ１０に送信される（ステップＳ４０３）。当該接続要求は、ＷｅｂＲＴＣサーバ２０を介してユーザ端末２００に転送される（ステップＳ４０５、Ｓ４０４）。また、ユーザ端末１００は肯定応答を受信する（ステップＳ４０６〜Ｓ４０８）。これにより音声信号の通信が可能となる。

（フォーキング型の発信処理）
次に、ユーザ端末１００が発信を行い、ユーザ端末２００に着信する場合におけるフォーキング型の処理を図１３を参照して説明する。

発信側のユーザ端末１００がＷｅｂサーバ４０に接続し（ステップＳ４５１）、ＨＴＭＬファイルをダウンロードする（ステップＳ４５２）。ユーザ端末１００において、ユーザ端末２００を接続先として選択する操作が行われることにより、ユーザ端末２００の識別子（電話番号等）を含む接続要求（例：ＩＮＶＩＴＥ）が送信される（ステップＳ４５３）。接続要求は、ＷｅｂＲＴＣサーバ２０に届く（ステップＳ４５３）。当該接続要求は、ユーザ端末２００に転送される（ステップＳ４５４）。そして、ユーザ端末１００が肯定応答を受信する（ステップＳ４５５〜Ｓ４５６）ことにより、音声信号の通信が可能となる。

（Ｗｅｂサーバ接続時の認証操作を不要とする方式例）
図１０のステップＳ３０６におけるＷｅｂサーバ４０への接続時、及び図１１のステップＳ３５６におけるＷｅｂサーバ４０への接続時において、通常は、ＩＤ／パスワードによる認証（ログイン）操作が必要になる。しかし、着信時にユーザがＩＤ／パスワードの入力を行うとなると不便である。

そこで、この認証のための操作を不要とするために、Ｗｅｂサーバ４０への接続に用いるＵＲＬに認証情報を含め、当該ＵＲＬを用いてＷｅｂサーバ４０への接続を行うこととしてもよい。

図１４は、当該方式を用いる場合における登録処理の例を示す。ステップＳ１０８において、Ｗｅｂサーバ４０からＰｕｓｈ着信サーバ１０に送信される登録処理要求の中に、ＵＲＬとパスコードの両方が含まれる点が図５に示した登録処理要求と異なる。当該パスコードはＷｅｂサーバ４０も保持しており、Ｗｅｂサーバ４０は当該パスコードに基づき認証を実施することができる。なお、ユーザ端末１００の着信アプリ１０１にＵＲＬが予め設定される場合には、パスコードのみを含めることとしてもよい。また、パスコードをＰｕｓｈ着信サーバ１０が保持し、それをＰｕｓｈ着信サーバ１０からＷｅｂサーバ４０に通知し、Ｗｅｂサーバ４０が当該パスコードを保持することとしてもよい。

また、一例として、パスコードは、ＵＲＬと連結（ＣＯＮＣＡＴＥＮＡＴＥ）されることで「ＵＲＬパスコード」の形で通知されてもよい。つまり、これまでに説明した「ＵＲＬ」が「ＵＲＬパスコード」に置き換わった形で、通知、保持がなされてもよい。また、パスコードがＵＲＬのハッシュ値であってもよい。当該ハッシュ値は、Ｗｅｂサーバ４０のみがＵＲＬから導出できる値である。

図１５は、当該方式を用いる場合における着信処理（プロキシ型）の例を示す。以下、図１０と異なる点を説明する。

図１５に示す例において、Ｐｕｓｈ着信サーバ１０は、ＵＲＬとパスコードから、ＵＲＬ情報を作成し、当該ＵＲＬ情報をＰｕｓｈ通知要求に含めてＰｕｓｈサーバ３０に送信する（ステップＳ３０３）。当該ＵＲＬ情報は、例えば、ＵＲＬとパスコードを連結した情報であり、これを認証情報付きＵＲＬと呼んでもよい。Ｐｕｓｈサーバ３０は、認証情報付きＵＲＬを含むＰｕｓｈ通知を着信アプリ１０１に通知し、着信アプリ１０１は認証情報付きＵＲＬをブラウザ１０２に通知する（ステップＳ３０４、Ｓ３０５）。

ユーザ端末１００のブラウザ１０２は、認証情報付きＵＲＬを用いてＷｅｂサーバ４０にアクセスする（ステップＳ３０６）。Ｗｅｂサーバ４０は、ユーザ端末１００から受信する当該認証情報付きＵＲＬが、正しい情報であることを確認することで、ログイン操作を実施することなく、ＨＴＭＬファイルをダウンロードする（Ｓ３０７）。

図１６に示す着信処理（フォーキング型）において、ステップＳ３５３〜Ｓ３５７において、図１５のステップＳ３０３〜Ｓ３０７と同じ処理が実行される。

（実施の形態のまとめ）
以上、説明したように、本実施の形態により、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムであって、前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信し、前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させる通信システムが提供される。

前記着信制御サーバは、前記着信通知を受信した前記着信ユーザ端末と前記通信制御サーバとの間の制御信号の中継を行うこととしてもよいし、前記着信通知を受信した前記着信ユーザ端末と前記通信制御サーバとの間の制御信号の送受信は、前記着信制御サーバを介さずに実行されることとしてもよい。

前記着信制御サーバは、前記着信ユーザ端末の代理として、当該着信ユーザ端末の登録要求を前記通信制御サーバに対して定期的に送信するようにしてもよい。

前記着信通知は、例えば、前記動作情報提供サーバを示す接続先情報を含む。前記接続先情報は、前記動作情報提供サーバにおける認証情報を含みこととしてもよく、これにより、当該動作情報提供サーバは、前記接続先情報により前記着信ユーザ端末からアクセスを受けたときに、当該接続先情報を用いて前記着信ユーザ端末の認証を行う。

前記動作情報は、例えば、前記着信ユーザ端末にＷｅｂＲＴＣに基づく動作を実行させる情報である。

また、本実施の形態により、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて実行される着信制御方法であって、前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信するステップと、前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させるステップとを備える着信制御方法が提供される。

また、本実施の形態により、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおける前記着信制御サーバであって、着信ユーザ端末の登録情報を格納する登録情報格納手段と、前記登録情報を用いて、前記着信ユーザ端末の代理として、前記通信制御サーバに対して登録要求を定期的に送信する手段と、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である前記着信ユーザ端末に対して着信通知を送信する手段とを備える着信制御サーバが提供される。

また、本実施の形態により、通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて用いられるユーザ端末であって、前記動作情報提供サーバにアクセスして動作情報を取得する機能を有する通信処理手段と、発信ユーザ端末からの接続要求に基づいて前記着信制御サーバから送信された着信通知を受信したことに応じて、前記通信処理手段に対して前記動作情報提供サーバを示す接続先情報を通知する着信処理手段と、を備え、前記通信処理手段は、前記接続先情報を用いて前記動作情報提供サーバにアクセスして前記動作情報を取得し、当該動作情報に基づいて前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行するユーザ端末が提供される。

前記着信処理手段は、前記着信通知に含まれる発信元の識別情報に基づいて、発信元の情報を表示することとしてもよい。また、前記着信処理手段は、前記発信元の識別情報と着信時刻とを着信履歴として記憶部に格納することとしてもよい。前記通信処理手段は、例えば、前記ユーザ端末におけるブラウザである。

（実施の形態の効果等）
本実施の形態に係る技術を用いることで、ユーザ端末は、ブラウザを立ち上げているか否か、スリープ状態か否かに関わらず、いつでも着信可能となる。また、本実施の形態における着信アプリは、は、事業者やサービスに依存しない汎用的なものを用意することができるため、サービスごとに着信アプリを用意する必要はないという利点がある。

また、着信時にログイン認証の操作を行うことなく、着信処理を実行することもでき、ユーザの利便性が向上する。また、着信アプリを使うことによって、Ｗｅｂサーバにアクセスする前に発信元の情報を画面表示することができ、また、着信履歴を閲覧することが可能となる。

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

１０ Ｐｕｓｈ着信サーバ
１１ 対ＷｅｂＲＴＣサーバ通信処理部
１２ 対ユーザ端末通信処理部
１３ Ｐｕｓｈ通知要求処理部
１４ 登録情報格納部
２０ ＷｅｂＲＴＣサーバ
３０ Ｐｕｓｈサーバ
４０ Ｗｅｂサーバ
１００、２００ ユーザ端末
１０１ 着信アプリケーション
１０２ ブラウザ
１１０ 着信処理部
１２０ 通信処理部
１３０ メディア処理部
３００ ネットワーク

Claims (15)

1. 通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムであって、
   前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信し、
   前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させる
   通信システム。
2. 前記着信制御サーバは、前記着信通知を受信した前記着信ユーザ端末と前記通信制御サーバとの間の制御信号の中継を行う
   請求項１に記載の通信システム。
3. 前記着信通知を受信した前記着信ユーザ端末と前記通信制御サーバとの間の制御信号の送受信は、前記着信制御サーバを介さずに実行される
   請求項１に記載の通信システム。
4. 前記着信制御サーバは、前記着信ユーザ端末の代理として、当該着信ユーザ端末の登録要求を前記通信制御サーバに対して定期的に送信する
   請求項１ないし３のうちいずれか１項に記載の通信システム。
5. 前記着信通知は、前記動作情報提供サーバを示す接続先情報を含む
   請求項１ないし４のうちいずれか１項に記載の通信システム。
6. 前記接続先情報は、前記動作情報提供サーバにおける認証情報を含み、当該動作情報提供サーバは、前記接続先情報により前記着信ユーザ端末からアクセスを受けたときに、当該接続先情報を用いて前記着信ユーザ端末の認証を行う
   請求項５に記載の通信システム。
7. 前記動作情報は、前記着信ユーザ端末にＷｅｂＲＴＣに基づく動作を実行させる情報である
   請求項１ないし６のうちいずれか１項に記載の通信システム。
8. 通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて実行される着信制御方法であって、
   前記着信制御サーバが、発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である着信ユーザ端末に対して着信通知を送信するステップと、
   前記動作情報提供サーバが、前記着信通知を受信した前記着信ユーザ端末からの要求に基づいて動作情報を前記着信ユーザ端末に送信し、前記着信ユーザ端末に前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行させるステップと
   を備える着信制御方法。
9. 通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおける前記着信制御サーバであって、
   着信ユーザ端末の登録情報を格納する登録情報格納手段と、
   前記登録情報を用いて、前記着信ユーザ端末の代理として、前記通信制御サーバに対して登録要求を定期的に送信する手段と、
   発信ユーザ端末からの接続要求を前記通信制御サーバから受信したことに応じて、当該接続要求の宛先である前記着信ユーザ端末に対して着信通知を送信する手段と
   を備える着信制御サーバ。
10. コンピュータを請求項９に記載の着信制御サーバにおける各手段として機能させるためのプログラム。
11. 通信制御サーバ、着信制御サーバ、及び動作情報提供サーバを有する通信システムにおいて用いられるユーザ端末であって、
    前記動作情報提供サーバにアクセスして動作情報を取得する機能を有する通信処理手段と、
    発信ユーザ端末からの接続要求に基づいて前記着信制御サーバから送信された着信通知を受信したことに応じて、前記通信処理手段に対して前記動作情報提供サーバを示す接続先情報を通知する着信処理手段と、を備え、
    前記通信処理手段は、前記接続先情報を用いて前記動作情報提供サーバにアクセスして前記動作情報を取得し、当該動作情報に基づいて前記発信ユーザ端末との間のメディア通信のための制御信号の送受信を実行する
    ユーザ端末。
12. 前記着信処理手段は、前記着信通知に含まれる発信元の識別情報に基づいて、発信元の情報を表示する
    請求項１１に記載のユーザ端末。
13. 前記着信処理手段は、前記発信元の識別情報と着信時刻とを着信履歴として記憶部に格納する
    請求項１２に記載のユーザ端末。
14. 前記通信処理手段は、前記ユーザ端末におけるブラウザである
    請求項１１ないし１３のうちいずれか１項に記載のユーザ端末。
15. コンピュータを、請求項１１ないし１４のうちいずれか１項に記載のユーザ端末における着信処理手段として機能させるためのプログラム。

Images