JP5100637B2 - アプリケーション・サーバにおいてクライアント関連情報を処理する方法及び装置 - Google Patents

Description

本発明は、概して、テレコミュニケーション（通信）・ネットワークに接続されたアプリケーション・サーバにおいてクライアント関連情報を処理する方法及び装置に係る。本発明は、特に、アプリケーション・サーバにクライアント状態が保持される場合に、信号量を減少させることに関する。

３Ｇモバイル技術の出現とともに、マルチメディア・コンテンツを通信するために、新たなパケットベースの通信技術が開発された。例えば、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ（汎用パケット無線サービス））およびＷＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（広帯域符号分割多元接続））技術は、伝統的な回線交換型の音声コールに加えて、イメージ、テキスト、ドキュメント、アニメーション、オーディオ・ファイル、ビデオ・ファイル等を示すデータのパケット交換通信を含む無線マルチメディア電話サービスをサポートする。ここで、“マルチメディア・コンテンツ”という用語は、パケット交換トランスポートの手段により通信されるあらゆるデータを示すのに使用する。

最近、ＩＰマルチメディア・サブシステム（ＩＭＳ）と呼ばれるネットワーク・アーキテクチャが、パケット・ドメインにおいてモバイル・クライアントに対してマルチメディア・サービスを提供するために、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって開かれた規格として開発された。概略的に説明すると、ＩＭＳは、多かれ少なかれアクセス技術に独立に、特定サービスの限定セットに基本的に限定されない、ＩＰトランスポート・ベースのサービスを可能にするプラットフォームである。

セッション・セットアップのための仕様は、パケット交換ロジック上でセッションを確立し、変更し、終了させるアプリケーション層コントロール（信号）プロトコルである“ＳＩＰ”（規格ＩＥＴＦ ＲＦＣ ３２６１等によるＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（セッション開始プロトコル））に規定されている。

図１は、ＩＭＳサービス・ネットワークの手段によって、マルチメディア・サービスを提供する基本ネットワーク構成を概略的に示す。この図は、非常に簡略化されており、本発明の内容を理解するのに役立つネットワーク・ノドを選択して示してあるだけである。コーリング（発呼側）・モバイル・端末Ａは、第１の無線アクセス・ネットワーク１００に接続されており、第２無線アクセス・ネットワーク１０２に接続されたコールド（被呼側）・モバイル・端末Ｂと、一つまたはそれ以上のマルチメディア・サービスを含む通信セッションＢにおいて通信する。このような通信のほか、端末Ａは、例えば、音楽、映画、ゲームのようなマルチメディア・コンテンツを提供するコンテンツ・サーバ、固定端末、またはコンピュータと通信できる。

ＩＭＳネットワーク１０４は、第１無線アクセス・ネットワーク１００に接続され、ユーザによって開始された、端末Ａに関するセッションを処理する。事実、ＩＭＳネットワーク１０４は、端末Ａのユーザからのあらゆるサービス・リクエストまたはデータを受け処理する。この図において、対応するＩＭＳネットワーク１０６は、端末Ｂのためにセッションを取り扱い、二つのＩＭＳネットワーク１０４および１０６は、異なるオペレータによって制御されていることもある。同様に、ＩＭＳネットワーク１０６は、端末Ｂのユーザからのあらゆるサービス・リクエストまたはデータを受信して処理する。このような構成にするのではなく、端末ＡおよびＢが、同一のアクセス・ネットワークに接続されおよび／または同一のＩＭＳネットワークに属していてもよいのはもちろんである。

図示されたセッションＳは、ＩＭＳネットワーク１０４中の端末Ａに割り当てられたＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（サービング・呼セッション制御機能部））と呼ばれるノード１０８によって管理され、使用されるマルチメディア・サービスは、アプリケーション・サーバ１１０によってイネーブルされ、実行される。基本的に、Ｓ−ＣＳＣＦノード１０８は、端末Ａ向けのアプリケーション・サーバ１１０のためのプロキシとして働き、破線矢印で示されているように、端末ＡからのＳＩＰメッセージを、端末ＢのＩＭＳネットワーク１０６に送信する。さらに、主データベース・エレメントであるＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ（ホーム加入者サーバ））１１２は、サービス情報とともに、クライアントのためのサービスを実行するためにフェッチすることが必要となる、加入者データ、確認データ及びサービス・データなどの情報を記憶する。典型例においては、Ｓ−ＣＳＣＦノード１０８は、ＨＳＳ１１２中の“ｔｒｉｇｇｅｒｓ（トリガー）”によって決められたように、端末Ａによって要求されたサービスをどのアプリケーション・サーバ１１０が処理するのかを決定するために、ＨＳＳ１１２からの情報をフェッチする。

Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（インテロゲーティング呼セッション制御機能部））と呼ばれるノード１１４は、他のＩＭＳネットワーク、この場合はネットワーク１０６に接続され、他のＩＭＳネットワークからのＳＩＰメッセージのためのゲートウェイとして作用する。Ｉ−ＣＳＣＦ１１４は、別の破線によって示されているように、端末ＢのＩＭＳネットワーク１０６からのＳＩＰメッセージを受信する。Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（プロキシ・呼セッション制御機能部））と呼ばれる別のノード１１６は、例えばネットワーク１００のようなあらゆるアクセス・ネットワークからＩＭＳネットワーク１０４に向けたエントリー・ポイントとして作用し、クライアントとＩＭＳネットワーク１０４との間の全ての信号の流れは、Ｐ−ＣＳＣＦ１１６を通る。

本発明の内容を理解するために、ここでＩ−ＣＳＣＦおよびＰ−ＣＳＣＦの種々の機能を説明する必要はない。もちろん、ＩＭＳネットワーク１０４は、別のＳ−ＣＳＣＦノードやアプリケーション・サーバのような多くの他のノードおよびファンクションを含むが、簡略化のためにここでは示されていない。基本的に、ＩＭＳネットワーク１０６は、ネットワーク１０４と同じタイプのノードを含む。図示されたアプリケーション・サーバ１１０は、一つまたはそれ以上の特定のマルチメディア・サービスを提供するように構成できる。

ＩＭＳネットワークの手段によって使用できる重要なサービスの２つの例は、セッションを制御するためにＳＩＰシグナリングを使用して実行される、“Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ（インスタント・メッセージング）”（ＩＭ）と“Ｐｒｅｓｅｎｃｅ（プレゼンス）”サービスである。インスタント・メッセージングは、例えば、テキスト、絵、ロゴ、オーディオ／ビデオ・クリップを含む、端末間での比較的短いメッセージの、“ｎｅａｒ ｒｅａｌ−ｔｉｍｅ（リアルタイムに近い）”状態、すなわち短い遅延での送信を含む。これに関連させて、“プレゼンス”は、基本的に、クライアントの動的で変更しうる状態のプロフィールであり、プレゼンス・サービスは、基本的に、クライアントの“プレゼンス・データ”の公表を含む。これは、プレゼンス・データを他のユーザが利用できるようにするためであり、プレゼンス・データは他のサービスの制御に使用できる。プレゼンス・データは、基本的に、何らかの予め定めた観点で、クライアントおよびその装置の状態を定義するものである。従って、“プレゼンス”という用語は、ここでは、非常に広い意味であり、例えば、以下の“クライアント”状態は、プレゼンス・データを作りあげる（ｍａｋｅ ｕｐ）ことをいう。
−パーソナル状態、例えば、手が空いている、忙しい、会議中、休暇等
−端末状態、例えば、スイッチ・オン／オフ、話し中、圏外等
−クライアント／端末の地理的位置
−端末能力、例えば、ＳＭＳ、ＭＭＳ、チャット、ＩＭ、ビデオ等に対する機能性
−端末選択、例えばコール転送、言語等
−他のクライアント情報、例えば、興味、職業、個人の特徴、気分、ロゴ、現在の気分に応じたロゴ等
これらの情報、またはこれらから選択された一部分は、クライアントがそのプレゼンス・データを変更すると、クライアントまたはネットワークから受信したいわゆる“ｐｕｂｌｉｃａｔｉｏｎ ｏｆ ｅｖｅｎｔｓ（イベントの公表）”に基づいて、ＩＭＳネットワーク中のアプリケーション・サーバに記憶される。あるサービスによれば、クライアントは、ユーザのリストに従って、一人またはそれ以上の他のユーザについて選択されたプレゼンス・データにもサブスクライブ（監視を開始すること）できる。典型例においては、このようなプレゼンス状態の監視の開始もまた、ＩＭＳネットワークのアプリケーション・サーバによって実行される。

“ＳＩＰ ＰＵＢＬＩＳＨ（ＳＩＰ公表）”と呼ばれるＳＩＰメッセージは、一般的に、クライアント、というよりはむしろ“Ｕｓｅｒ Ａｇｅｎｔ Ｃｌｉｅｎｔ（ユーザ・エージェント・クライアント）（ＵＡＣ）”によって、ＩＭＳネットワーク中のアプリケーション・サーバにダイナミック・データをアップロードするのに使用される。プレゼンス状態を示すデータの送信は、ＰｏＣ、ＩＭ、およびプレゼンス・サービスのような、この目的のためのあらゆるサービスによって使用される。“ＳＩＰ ＳＵＢＳＣＲＩＢＥ（ＳＩＰサブスクライブ）”と呼ばれる別のＳＩＰメッセージは、アプリケーション・サーバによって処理される、他のクライアントのダイナミック・データをサブスクライブするのに使用される。ここで、“クライアント状態”という用語は、ときどきＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ（生存時間））と呼ばれる予め定めた満了期間によって定められた限定された期間は、アプリケーション・サーバ中のクライアント関連情報を維持することを示す。このようなクライアント関連情報は、公表されたクライアント・データ、または他のユーザのデータに対するクライアントのサブクリプションに関連する。しかしながら、これらのサービス、特にプレゼンス・サービスでは、クライアントからＩＭＳネットワークに多量のデータが送信されることになる。

従って、公表されたクライアント・データ、または要求されたデータ・サブスクリプションは、公表されたデータまたはデータ・サブスクリプションが時間満了時に無効になる満了期間を持たなければならない。クライアントが、満了期間を提供しないときには、アプリケーション・サーバが、デフォルトの満了期間、プレゼンスの場合典型例では１時間、を使用する。現在のサービス実装においては、ならびにＩＥＴＦ、３ＧＰＰおよびＯＭＡといった異なる規格によれば、データ公表またはサブスクリプションは、例えデータ／サブスクリプションが変更されなくても、このデータ／サブスクリプションをアプリケーション・サーバ中に有効に維持するために、頻繁にリフレッシュされなければならない。

次に、公表されたクライアント関連データをアプリケーション・サーバ中に維持するための従来の手順を、図２に示されたブロック図を参照して説明する。クライアント・端末２００が、そのユーザによってパワー・オンされ、現在、他の端末、ならびに上述のＩＭＳネットワークのようなマルチメディア・サービス・ネットワーク２０２と通信するために、アクセス・ネットワーク（図示せず）と接続されているものとする。サービス・ネットワーク２０２は、例えば、図１に示されたＩＭＳネットワークによれば、他のノードおよびコンポーネントのほか、“レジストレーション（登録）・ユニット”２０４、アプリケーション・サーバ２０６、およびＨＳＳ２０８を含む。従って、レジストレーション・ユニット２０４は、上述のＳ−ＣＳＣＦノードとすることができ、サービス・ネットワーク２０２に対するクライアントのレジストレーションを実行する。ここでは、最初にアクセス・ネットワークにアクセスされたとき、端末がＩＰを介して通信できるように、一時的ＩＰアドレスが端末に割り当てられる。

第１ステップ２：１において、端末２００は、サービス・ネットワーク２０２中でアクティブ・端末として登録されるように、レジストレーション・ユニット２０４にレジストレーション・リクエスト・メッセージを送信する。次に、従来のルーチンによれば、ステップ２：２に示されているように、端末はＨＳＳ２０８中に登録される。その後、端末は、破線矢印２：３により概略的に示されているように、“ｒｅ−ｒｅｇｉｓｔｅｒ（再登録）”メッセージあるいは同様のものをレジストレーション・ユニット２０４に頻繁に送って、レジストレーションをリフレッシュしなければならない。典型例においては、レジストレーションを維持するために、再登録メッセージは、３０−６０分毎に送信しなければならない。

この進行中のルーチンのどこかの時点で、端末２００は、ステップ２：４に示されているように、クライアント・データ公表メッセージ、例えばＳＩＰ ＰＵＢＬＩＳＨメッセージを、アプリケーション・サーバ２０６に送信する。そして、アプリケーション・サーバ２０６は、新たなクライアント・データを記憶し、これを、例えば３０分または１時間にセットされるタイムアウト期間の間、有効に維持する。一般に、クライアント・データ公表メッセージは、公表されたデータが有効の間アプリケーション・サーバ２０６中で“クライアント状態”のアクティベーション（活性化）を生じさせる。アプリケーション・サーバ２０６中で、このクライアント状態すなわち公表されたデータを維持するには、破線矢印２：５により概略的に示されているように、端末は、例えデータが変更されていなくても、タイムアウト期間が経過する前に、“ｒｅ−ｐｕｂｌｉｓｈ（再公表）”メッセージを頻繁に送信することにより、公表されたデータをリフレッシュしなければならない。もし、クライアントが、ネットワーク１０４中に多数の種々のアクティブ・クライアント状態を有していれば、上述のリフレッシュ・メッセージを送信する負担は大きなものとなる。

端末２００が電源オフされると、ステップ２：６に示されているように、“ｄｅ−ｒｅｇｉｓｔｅｒ（登録抹消）”メッセージが、レジストレーション・ユニット２０４に送信される。典型例においては、図示されていないが、端末は、公表されたデータをインアクティベート（非活性化）するために、アプリケーション・サーバ２０６に、“ｄｅ−ｐｕｂｌｉｓｈ（公表解除）”メッセージを送信しなければならない。そうしないと、端末が電源オフされているにもかかわらず、公表されたデータは、最後の再公表メッセージが送信されてからタイムアウト期間が経過するまで、アプリケーション・サーバ２０６中に有効に残存することになる。これは、クライアントがログオフした後、ＴＴＬが経過するまで、不適切なアクティブ・クライアント状態を生じさせることになる。これを生じさせる例としては、端末２００が例えば電池切れで無線接続を失って、公表解除メッセージを送信できなくなってしまった場合をあげることができる。

クライアントが他のクライアントのデータに対してサブスクリプション・リクエストを送信するときにも、上述のように、基本的に同じ手順が使用される。この場合、ステップ２：４のメッセージは、例えばＳＩＰ ＳＵＢＳＣＲＩＢＥのようなサブスクリプション・リクエスト・メッセージであり、アプリケーション・サーバ２０６中に別のクライアント状態のアクティベーションを生じさせる。さらに、ステップ２：５のリフレッシュ・メッセージは、このクライアント状態を維持するために繰り返し送信される“ｒｅ−ｓｕｂｓｃｒｉｂｅ（再加入）”メッセージである。しかしながら、後述するように、クライアントの端末２００が繰り返し再公表および／または再サブスクライブ・メッセージを送信することには問題がある。

現在のソリューションにおいては、次に述べる理由により、クライアントは、公表されたデータまたはデータ・サブスクリプションを極めて頻繁にリフレッシュするか、公表されたデータのための満了期間を増大させなければならない。まず、アプリケーション・サーバ中のクライアント状態を最新のものに維持するために、例えば公表されたデータまたはデータ・サブスクリプション等のクライアント状態のための満了期間は、一般に短いことが望ましく、その結果、公表されたものを極めて頻繁にリフレッシュする必要がある。満了期間を短くする主な理由は、また、クライアントがデータの状態を変更するために公表解除または登録抹消メッセージを送信することなくシャット・ダウンされたのか、あるいはサブスクリプションが“オフ”にされたのかという情報を、アプリケーション・サーバ２０６が取得していないという事実である。そして、クライアント状態が無駄に維持され、不必要な通知が、それらを受信できず他のクライアントのデータに対するアクティブなサブスクリプションを依然として有している端末に対して、ＴＴＬが経過するまで、頻繁に送信されることになる。

第２に、このような動作は、使用されるアクセス・ネットワークだけでなく、サービス・ネットワーク２０２にも非常に大きな負荷をかけることになる。ＩＭＳの場合には、通常、無線アクセスに基づいて非常に大きな負荷がかかることになる。さらに、モバイル・クライアントの場合、上述のステップ２：５において、再公表または再サブスクライブ・メッセージを頻繁に送信すると、端末の電池を減少させ、貴重な無線帯域を消費することになる。従って、信号負荷に関してはクライアント状態に対する満了期間を比較的に長くすることが好ましい。従って、上述した従来のソリューションにおいては、アプリケーション・サーバ中のクライアント状態のための満了期間は、必然的に、これらの矛盾するファクタの妥協点に設定されることになる。

本発明の目的は、上述した問題の少なくともいくつかに対処することである。具体的には、本発明の目的は、アプリケーション・サーバ中においてアクティブなクライアント状態を有するクライアントからの信号負荷を低減できるようにすることにある。本発明の別の目的は、アプリケーション・サーバ中のクライアント関連情報を、最小の信号メッセージを使用して最新のものに保持できるようにすることにある。

本発明の上記目的および他の目的は、テレコミュニケーション・ネットワークにレジストレーションしたクライアントのために、上記テレコミュニケーション・ネットワークに接続されたアプリケーション・サーバにおいてクライアント関連情報を処理する方法および装置において、独立項に記載された内容によって達成される。本方法においては、まず、上記アプリケーション・サーバにおいて管理されているクライアント状態をアクティブにするための上記クライアントからのメッセージが受信される。そして、レジストレーション・イベント、すなわち上記クライアントのレジストレーションを変更させることになるイベントがモニターされる。ある時点において、上記クライアントに関するレジストレーション・イベント通知が受信され、上記受信したレジストレーション・イベント通知に応じて、上記クライアント状態がアップデート（更新）される。

上記クライアントから受信した上記メッセージは、クライアント・データの公表、クライアント・データのためのサブクリプション・リクエストを含むことができ、またはセッション開始メッセージ、例えばＳＩＰ ＩＮＶＩＴＥ（ＳＩＰセッション確立要求）とすることができる。上記レジストレーション・イベントをモニターすることは、レジストレーション・イベントのためのサブスクリプションを作成することを含むことができ、あるいは、第三者のレジストレーション・イベントがモニター（監視）される。

上記受信したレジストレーション・イベント通知は、上記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションがインアクティベートされたことを示す。上記クライアントのレジストレーションは、上記クライアントから登録抹消メッセージを受信したときに、インアクティベートされてもよい。典型例においては、上記サービス・ネットワークに対する上記クライアントのレジストレーションの有効期間が限定されており、上記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションが、上記レジストレーション有効期間が経過したときに、インアクティベートされる。好ましくは、上記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションのインアクティベートされたことに応じて、上記アプリケーション・サーバにおける上記クライアント状態がインアクティベートされる。

典型例においては、また、上記アプリケーション・サーバにおけるクライアント状態の有効期間が限定されており、好ましくは、クライアント状態の有効の満了期間が、レジストレーション有効の満了期間よりかなり長く設定される。例えば、クライアント状態が有効とされている満了期間は、上記レジストレーション有効の満了期間の少なくとも１０倍に設定される。

上記テレコミュニケーション・ネットワークは、ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークとすることができ、この場合、上記レジストレーション・イベント通知は、上記ＩＭＳネットワークに対する上記クライアントのレジストレーションを処理するサービング・呼セッション逝去機能（Ｓ−ＣＳＣＦ）ノードから受信される。また、この場合、セッション開始プロトコル（ＳＩＰ）が、クライアントとのメッセージの通信に使用される。

また、テレコミュニケーション・ネットワークにレジストレーションしたクライアントのために、上記テレコミュニケーション・ネットワークに接続されたアプリケーション・サーバにおいてクライアント関連情報を処理する装置が提供される。この装置は、上記アプリケーション・サーバにおけるクライアント状態をアクティブにするクライアントからのメッセージを受信する手段と、レジストレーション・イベント、すなわち上記クライアントのレジストレーションが変更されるときのイベントをモニターする手段と、上記クライアントに関するレジストレーション・イベント通知を受信する手段と、上記受信したレジストレーション・イベント通知に応じて、上記クライアント状態をアップデートする手段とを含む。

上記装置は、さらに、クライアント・データの公表を含む上記クライアントからの上記メッセージを受信する手段と、クライアント・データのためのサブクリプション・リクエストを含む上記クライアントからの上記メッセージを受信する手段と、上記クライアントからの前記メッセージを、セッション開始メッセージ、例えばＳＩＰ ＩＮＶＩＴＥとして受信する手段を含むことができる。上記レジストレーション・イベントをモニターする手段は、レジストレーション・イベントのためのサブスクリプションを作り出すように、または第三者のレジストレーション・イベントをモニターするように構成することができる。

上記装置は、上記サービス・ネットワークに対するクライアントのレジストレーションがインアクティベートされたことを示すレジストレーション・イベント通知を受信する手段を、さらに含むことができる。上記サービス・ネットワークに対するクライアントのレジストレーションは、上記クライアントから登録抹消メッセージを受信したときに、インアクティベートすることができる。典型例においては、上記サービス・ネットワークに対する上記クライアントのレジストレーションの有効期間が限定されており、上記サービス・ネットワークに対するクライアントのレジストレーションは、上記レジストレーション有効期間が経過したときに、インアクティベートすることができる。

上記装置は、上記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションの上記インアクティベーションに応じて、上記クライアント状態をインアクティベートする手段を、さらに含むことができる。典型例においては、上記アプリケーション・サーバにおけるクライアント状態有効期間が限定されており、上記装置は、クライアント状態の有効の満了期間を、レジストレーション有効の満了期間よりかなり長く設定する手段を、さらに含むことができ、好ましくは、上記クライアント状態の有効の満了期間を、上記レジストレーション有効の満了期間の少なくとも１０倍に設定する手段を含むことができる。

典型例においては、上記テレコミュニケーション・ネットワークは、ＩＭＳネットワークとすることができ、この場合、上記レジストレーション・イベント通知は、上記ＩＭＳネットワークに対する上記クライアントのレジストレーションを処理するＳ−ＣＳＣＦノードから受信される。また、この場合、ＳＩＰが、クライアントとのメッセージの通信に使用される。

さらに別の特徴および利点は、以下の詳細説明で説明する。

基本的に、本ソリューションは、既存のルーチン、すなわち、クライアントが、例えば上述した図２のステップ２：３において説明したように、レジストレーション・ユニットに再登録メッセージを送信し、また、例えば公表されたデータまたはデータ・サブスクリプションに対する、アプリケーション・サーバ中のあらゆるクライアント状態を“リフレッシュ”するルーチンを利用することができる。クライアントのレジストレーションをリフレッシュすることに加えて、クライアントがアプリケーション・サーバに特定の再公表および再サブスクライブ・メッセージを頻繁に送信することなく、公表されたデータまたはデータ・サブスクリプションが自動的にリフレッシュされる。

次に、本ソリューションの一実施例について、図３に示されたブロック図を参照して説明する。図３では、図２の対応エレメントには、同一の参照番号が付されている。また、手順の最初の部分は、図２に関連して説明したのと基本的に同じである。端末２００は、第１ステップ３：１において、レジストレーション・リクエスト・メッセージを送信し、該端末は、次のステップ３：２において、ＨＳＳ２０８に登録される。さらに、ステップ３：３に示されているように、この登録を“ａｌｉｖｅ（アライブ）”にし（生かしておき）有効に保つために、端末が再登録メッセージを頻繁に送信することが依然として必要である。

進行中の手順のある時点において、端末２００は、ステップ３：４に示されているように、アプリケーション・サーバ２０６にメッセージを送信する。これにより、一般に、アプリケーション・サーバ中のクライアント状態のアクティベーションを生じさせる。上述のように、このメッセージは、典型例においては、クライアント・データ公表メッセージまたはデータ・サブスクリプション・リクエスト・メッセージであるが、セッションが長時間アクティブに維持されていれば、例えばＳＩＰ ＩＮＶＩＴＥのようなセッッション開始メッセージということもあり得る。そして、アプリケーション・サーバ２０６は、典型例においては、公表されたデータまたはデータに対するサブスクリプションに関するあるクライアント関連情報を含むクライアント状態を維持する。

しかしながら、アプリケーション・サーバ２０６中にこのクライアント状態を維持するのにリフレッシュ・メッセージを頻繁に送信することを回避するために、アプリケーション・サーバ２０６は、クライアントのレジストレーションに関連するレジストレーション・イベントのモニターを開始する。この例では、アプリケーション・サーバ２０６は、ステップ３：５において、レジストレーション・イベントに対するサブスクリプション・リクエストを、レジストレーション・ユニット２０４に送信する。このようにする代わりに、第三者のレジストレーション・イベントをモニターすることもできる。

この説明において、“レジストレーション・イベント”という用語は、クライアント・レジストレーションが変更されるときに、この例においては、レジストレーション・ユニット２０４によって取り扱われるあらゆるイベントのことをいう。一つの重要なレジストレーション・イベントは、上述した図２のステップ２：６に示されているように、クライアントが登録抹消メッセージを送信したときのものであり、これにより、クライアントのレジストレーションは、サービス・ネットワーク２０２中でインアクティベートされる。クライアントのレジストレーションは、例えば、無線コンタクトの消失や電池が空になったために、直近のタイムアウト期間にリフレッシュ用の再登録メッセージを受信しなかった場合にも、インアクティベートされる。

従って、レジストレーション・ユニット２０４は、ステップ３：６において、クライアント２００から登録抹消メッセージを受信すれば、次のステップ３：７において、クライアントに関するレジストレーション・イベント通知を、アプリケーション・サーバ２０６に送信し、このクライアントは、サービス・ネットワーク２０２中でもはやアクティブに登録されていないことを、アプリケーション・サーバ２０６に伝える。レジストレーションがリフレッシュされずにタイムアウトしたときにも、同じレジストレーション・イベント通知を送信することができる。その結果、アプリケーション・サーバ２０６は、受信したレジストレーション・イベント通知に応答して、クライアント状態を最終的にアップデートすることができる。典型例においては、アプリケーション・サーバ２０６は、サービス・ネットワークに対するクライアントのレジストレーションのインアクティベーションに応じて、クライアント状態をインアクティベートする。

このソリューションにおいては、端末は、“リフレッシュ”メッセージを頻繁に送信することによって、公表されたデータをリフレッシュする必要はない。もちろん、端末は、公表されたデータが変更されたときには、ステップ３：４に示されているように、別の公表メッセージを送信することができる。アプリケーション・サーバ２０６は、クライアント状態をコントロールするのに、レジストレーション・ユニット２０４からのレジストレーション・イベント通知に依存できるので、クライアント状態の満了期間を、実際上、クライアント２００からリフレッシュ用の再公表または再サブスクライブ・メッセージを送信する必要がないほど非常に長く設定できる。好ましくは、クライアント状態に対する満了期間は、クライアント・レジストレーションの満了期間よりもかなり長く、１０倍以上に設定される。これにより、クライアントからの信号量は、非常に減少するとともに、アプリケーション・サーバに記憶されるクライアント関連情報は、常にアップデートされたものになる。

もちろん、クライアントは、クライアント状態をインアクティベートするために、図示していない、特定の公表解除またはサブスクライブ解除メッセージを、アプリケーション・サーバ２０６に送信することができるが、このことは、本発明のソリューションに影響を与えるものではない。

クライアント公表データに対する好ましい実施例による信号（シグナリング）手順の一例を、図４を参照して説明する。この図は、ＵＡＣ（Ｕｓｅｒ Ａｇｅｎｔ Ｃｌｉｅｎｔ（ユーザ・エージェント・クライアント））４００ａが、図３の対応エレメントと全て同一にできる、クライアント・端末、レジストレーション・ユニット４００ｂ、ＨＳＳ４００ｃおよびアプリケーション・サーバ４００ｄにおいて動作しているところを示す。この例においては、ＳＩＰ信号が、ＩＭＳネットワーク中で使用される。ＩＭＳネットワークにおいては、背景部分で説明しこの図では簡潔さを維持するために示していないが、クライアントに関する全ての信号は、実際には、基本的に、Ｐ−ＣＳＣＦノードで取り扱われる。

クライアントがその端末４００ａを始動させると、ユーザ・エージェント・クライアントＵＡＣが、第１ステップ４０２において、ＳＩＰ ＲＥＧＩＳＴＥＲ（ＳＩＰ登録）メッセージを、レジストレーション・ユニット４００ｂに送信し、“公表ユーザ識別情報，ＰＵＩ”をレジストレーション（登録）し、これを、端末に割り当てられたＩＰアドレスに対応付ける。これに応じて、ＵＡＣ４００ａは、ステップ４０４に概略的に示されているように、レジストレーション・ユニット４００ｂとＨＳＳ４００ｃとの間の信号のやり取りによって、ネットワークにレジストレーション（登録）される。クライアントのレジストレーションの確立後、ステップ４０６に示されているように、レジストレーション・ユニット４００ｂは、ＵＡＣ４００ａに、ＳＩＰ２００ＯＫメッセージを送信する。

ＵＡＣ４００ａは、また、レジストレーションを維持するために、図示しないリフレッシュ用のＲＥＧＩＳＴＥＲメッセージを、レジストレーション・ユニット４００ｂに送信する。レジストレーション・ユニット４００ｂは、レジストレーションをアクティブに維持し、タイマー機能を使用し、タイマー時間が満了したとき、登録されたＰＵＩが登録抹消されたと判断する。レジストレーションの期間が満了すると、そのＰＵＩは、そのデバイスに対する通信には利用できなくなる。さらに、ＵＡＣは、アプリケーション・サーバ４００ｄへのデータを生成し、変更し、削除しようと、一般にデータの公表と呼ばれることをしようとするとき、ＵＡＣは、新たなＰＵＢＬＩＳＨ（公表）メッセージを、アプリケーション・サーバ４００ｄに送信する。いくつかのＵＡＣが同一の端末を使用でき、それらのいずれもが、その特定のサービス・データを生成しまたは変更するために、ＰＵＢＬＩＳＨメッセージを送信することができる。

別のステップ４０８において、ＵＡＣ４００ａから、特定のＰＵＩのための初期ＳＩＰ ＰＵＢＬＩＳＨメッセージが、アプリケーション・サーバ４００ｄに送信される。これに応じて、アプリケーション・サーバ４００ｄは、ＰＵＩのレジストレーション状態のあらゆる変化が報知されるようにするために、ステップ４１０において、サブスクリプション・リクエスト，ＳＩＰ ＳＵＢＳＣＲＩＢＥ（ｒｅｇ．ＥＶＥＮＴ）を送信することにより、レジストレーション・イベントに対するサブスクリプションを開始する。このようにする代わりに、レジストレーション・ユニット４００ｂは、常にレジストレーション・イベントをアプリケーション・サーバ４００ｄに送信するために、第三者のレジストレーションを使用してもよい。

レジストレーション・ユニット４００ｂがレジストレーションＴＴＬに関連したタイムアウト機能を有するので、ＵＡＣにｒｅ−ＰＵＢＬＩＳＨ（再公表）メッセージを送信しなくても、アプリケーション・サーバ４００ｄは、いつＰＵＩが登録抹消されたかの情報を取得できる。レジストレーション・ユニット４００ｂとアプリケーション・サーバ４００ｄとの間のトラヒックを最小にするために、アプリケーション・サーバ４００ｄは、登録抹消イベントに対してサブスクライブするだけでよい。これは、アプリケーション・サーバ４００ｄがレジストレーション・リフレッシュ用のメッセージについて報知されるポイントがないからである。事実、アプリケーション・サーバ４００ｄは、公表されたデータのためのアクティブ・タイマーを備える必要は全くない。何故なら、アプリケーション・サーバ４００ｄは、登録抹消が生じると、レジストレーション・ユニット４００ｂによって知らされると信頼してよいからである。なお、ＵＡＣ４００ａは、公表されたデータが変更される必要があるときには、いつでも通常通り、オプションのステップ４１２として示されているように、ＰＵＢＬＩＳＨ（公表）メッセージをアプリケーション・サーバ４００ｄに送信することができる。

クライアントの端末が電源オフされると、ステップ４１４に示されているように、ＳＩＰ ＲＥＧＩＳＴＥＲ（ｏｆｆ）メッセージが、ＵＡＣ４００ａからレジストレーション・ユニット４００ｂに送信される。最終ステップ４１６において、レジストレーション・ユニット４００ｂがＳＩＰ ＮＯＴＩＦＹ（通知）（ｒｅｇ．Ｅｖｅｎｔ（ｏｆｆ））メッセージをアプリケーション・サーバ４００ｄに送信すると、公表されたデータは、無効化される。

本発明を、特定の実施例を参照して説明したが、上記説明は、発明概念を例示することを意図するだけであり、本発明の範囲を限定するものではない。本発明の範囲は、特許請求の範囲の記載によって決定される。

本発明が使用され得る基本的通信構成の概略を示す。 アプリケーション・サーバ中にクライアント・データを維持する従来の手順を示すブロック図である。 本発明の一実施例により、アプリケーション・サーバ中のクライアント関連情報を処理する手順を示すブロック図である。 本発明の別の実施例により、クライアント・データを維持する手順を示す信号図である。

Claims (28)

1. テレコミュニケーション・ネットワークのレジストレーション・ユニットにレジストレーションしたクライアントであって、このクライアントのレジストレーションを維持するために、１つまたはそれ以上の再登録メッセージを前記レジストレーション・ユニットに送信することが要求されるクライアントのために、前記テレコミュニケーション・ネットワークに接続されたアプリケーション・サーバにおいてクライアント関連情報を処理する方法であって、
   前記アプリケーション・サーバによって実行されるステップとして、
   前記再登録メッセージを用いてレジストレーションを維持されるクライアントであって、前記アプリケーション・サーバにおいてクライアント状態をアクティブにされる該クライアントからのメッセージを受信するステップと、
   前記レジストレーション・ユニットによって取り扱われるレジストレーション・イベントであって、前記クライアントのレジストレーションが変更されることになるイベントを、前記クライアント・レジストレーションが変更されるときのイベントに対する、前記レジストレーション・ユニットからの前記クライアントに関するレジストレーション・イベント通知を受信することで、モニターするステップと、
   前記受信したレジストレーション・イベント通知に応じて、前記クライアント状態をアップデートするステップと
   を含むことを特徴とする方法。
2. 前記クライアントから受信した前記メッセージが、クライアント・データの公表を含むことを特徴とする請求項１に記載の方法。
3. 前記クライアントから受信した前記メッセージが、クライアント・データのためのサブクリプション・リクエストを含むことを特徴とする請求項１に記載の方法。
4. 前記クライアントから受信した前記メッセージが、セッション開始メッセージ、例えばＳＩＰ ＩＮＶＩＴＥであることを特徴とする請求項１に記載の方法。
5. 前記レジストレーション・イベントをモニターするステップが、レジストレーション・イベントのためのサブスクリプションを作成することを含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記レジストレーション・イベントをモニターするステップが、他のクライアントのレジストレーション・イベントをモニターすることを含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
7. 前記受信したレジストレーション・イベント通知が、前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションがインアクティベートされたことを示すことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションが、前記クライアントから登録抹消メッセージを受信したときに、インアクティベートされることを特徴とする請求項７に記載の方法。
9. 前記テレコミュニケーション・ネットワークに対する前記クライアントのレジストレーションの有効期間が限定されており、前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションが、前記レジストレーション有効期間が経過したときに、インアクティベートされることを特徴とする請求項７に記載の方法。
10. 前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションの前記インアクティベーションに応じて、前記アプリケーション・サーバにおける前記クライアント状態がインアクティベートされることを特徴とする請求項７乃至９のいずれか１項に記載の方法。
11. 前記アプリケーション・サーバにおけるクライアント状態の有効期間が限定されており、クライアント状態の有効の満了期間が、レジストレーション有効の満了期間よりかなり長く設定されていることを特徴とする請求項１０に記載の方法。
12. 前記クライアント状態の有効の満了期間が、前記レジストレーション有効の満了期間の少なくとも１０倍に設定されていることを特徴とする請求項１１に記載の方法。
13. 前記テレコミュニケーション・ネットワークが、ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであり、前記レジストレーション・イベント通知が、前記ＩＭＳネットワークに対する前記クライアントのレジストレーションを処理するサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）ノードから受信されることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. セッション開始プロトコル（ＳＩＰ）が、クライアントとのメッセージの通信に使用されることを特徴とする請求項１３に記載の方法。
15. テレコミュニケーション・ネットワークのレジストレーション・ユニットにレジストレーションしたクライアントであって、このクライアント・レジストレーションを維持するために、１つまたはそれ以上の再登録メッセージを前記レジストレーション・ユニットに送信することが要求されるクライアントのために、前記テレコミュニケーション・ネットワークに接続されたアプリケーション・サーバにおいてクライアント関連情報を処理する装置であって、
    前記再登録メッセージを用いてレジストレーションを維持されるクライアントであって、前記アプリケーション・サーバにおいてクライアント状態をアクティブにされる該クライアントからのメッセージを受信する手段と、
    前記レジストレーション・ユニットによって取り扱われるレジストレーション・イベントであって、前記クライアントのレジストレーションが変更されることになるイベントを、前記クライアント・レジストレーションが変更されることになるイベントに対する、前記レジストレーション・ユニットからの前記クライアントに関するレジストレーション・イベント通知を受信することで、モニターする手段と、
    前記受信したレジストレーション・イベント通知に応じて、前記クライアント状態をアップデートする手段と
    を含む装置。
16. クライアント・データの公表を含む前記クライアントからの前記メッセージを受信する手段を、さらに含むことを特徴とする請求項１５に記載の装置。
17. クライアント・データのためのサブクリプション・リクエストを含む前記クライアントからの前記メッセージを受信する手段を、さらに含むことを特徴とする請求項１５または１６に記載の装置。
18. 前記クライアントからの前記メッセージを、セッション開始メッセージ、例えばＳＩＰ ＩＮＶＩＴＥとして受信する手段を、さらに含むことを特徴とする請求項１５乃至１７のいずれか１項に記載の装置。
19. 前記レジストレーション・イベントをモニターする手段が、レジストレーション・イベントのためのサブスクリプションを作り出すように構成されていることを特徴とする請求項１５乃至１８のいずれか１項に記載の装置。
20. 前記レジストレーション・イベントをモニターする手段が、他のクライアントのレジストレーション・イベントをモニターするように構成されていることを特徴とする請求項１５乃至１９のいずれか１項に記載の装置。
21. 前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションがインアクティベートされたことを示すレジストレーション・イベント通知を受信する手段を、さらに含むことを特徴とする請求項１５乃至２０のいずれか１項に記載の装置。
22. 前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションが、前記クライアントから登録抹消メッセージを受信したときに、インアクティベートされることを特徴とする請求項２１に記載の装置。
23. 前記テレコミュニケーション・ネットワークに対する前記クライアントのレジストレーションの有効期間が限定されており、前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションが、前記レジストレーションの有効期間が経過したときに、インアクティベートされたことを特徴とする請求項２１に記載の装置。
24. 前記テレコミュニケーション・ネットワークに対するクライアントのレジストレーションの前記インアクティベーションに応じて、前記アプリケーション・サーバにおけるクライアント状態をインアクティベートする手段を、さらに含むことを特徴とする請求項２１乃至２３のいずれか１項に記載の装置。
25. 前記アプリケーション・サーバにおけるクライアント状態の有効期間が限定されており、さらに、クライアント状態の有効の満了期間を、レジストレーションの有効の満了期間よりかなり長く設定する手段を含むことを特徴とする請求項２４に記載の装置。
26. 前記クライアント状態の有効の満了期間を、前記レジストレーションの有効の満了期間の少なくとも１０倍に設定する手段を、さらに含むことを特徴とする請求項２５に記載の装置。
27. 前記テレコミュニケーション・ネットワークが、ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであり、前記レジストレーション・イベント通知が、前記ＩＭＳネットワークに対する前記クライアントのレジストレーションを処理するサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）ノードから受信されることを特徴とする請求項１５乃至２６のいずれか１項に記載の装置。
28. セッション開始プロトコル（ＳＩＰ）が、クライアントとのメッセージの通信に使用されることを特徴とする請求項２７に記載の装置。

Images