JP5006406B2 - クライアント・データの通知予約を処理する方法及び装置 - Google Patents

Description

本発明は、一般的にオブザーブド・クライアントのクライアント・データの通知予約を処理する方法及び装置に関するものである。特に、本発明は、ウォッチング・クライアントに対するクライアント・データの通知を、一時的に保留するために使用され得る。

第３世代移動端末の出現に伴って、無線によるマルチメディア通信に対応するために、ＩＰ（インターネット・プロトコル）を用いた新たなパケット通信技術が開発されている。例えば、ＧＰＲＳ（汎用パケット無線サービス）やＷＣＤＭＡ（広帯域符号分割多元接続）における通信プロトコルは、従来の回線交換の音声呼だけでなく、パケット交換のマルチメディア・サービスに対応している。

「ＩＰマルチメディア・サブシステム（ＩＭＳ）」と呼ばれるネットワーク・アーキティチャが、ＩＰ伝送に基づいて、マルチメディア・サービス及びセッションをパケット領域において扱う基盤として、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって開発されている。従って、何れかのタイプのアクセス・ネットワークに接続される、ＩＰを使用可能な何れかの端末が、マルチメディア・セッションを開始及び制御するために、ＩＭＳネットワークが使用され得る。ＩＭＳネットワークにおいては、セッションの処理のために「ＳＩＰ」（標準規格であるＩＥＴＦのＲＦＣ３２６１に準じたセッション開始プロトコル）と呼ばれるシグナリング・プロトコルが使用される。このため、「ＳＩＰを使用可能な」端末は、他の端末やサーバとの、ホームＩＭＳネットワークを用いたマルチメディア通信を開始及び終了するために、この標準規格を使用できる。

図１は、端末Ａを使用するクライアントにＩＭＳネットワーク１００でマルチメディア・サービスを提供する基本的なネットワーク構造の概略図である。この例において、端末Ａは、無線アクセス・ネットワーク１０２に接続された移動端末であり、ＩＭＳは、固定端末のためにも同様に使用され得る。ＩＭＳ端末は、一般的には多くの場合、「ユーザ装置（ＵＥ）」と言われる。

アクセス・ネットワーク１０２は、ＩＭＳネットワーク１００に接続され、端末Ａの「ホーム」ＩＭＳネットワークであり、そのため端末Ａに対するマルチメディア・サービスを処理する。基本的には、マルチメディア・サービスは、移動先のアクセス・ネットワークにおけるローミングの際にも、端末のＩＭＳホーム・ネットワークによって処理される。端末Ａのクライアントに対する何れのマルチメディア・セッション及びサービスも、ＩＭＳネットワーク１００における特定のセッション管理ノードによって制御される。今日における従来のＩＭＳアーキテクチャによれば、当該ノードには、Ｐ−ＣＳＣＦ（プロキシ呼セッション制御機能）ノード１０４、Ｓ−ＣＳＣＦ（在圏呼セッション制御機能）ノード１０６、及びＩ−ＣＳＣＦ（インテロゲーティング呼セッション制御機能）ノード１０８が含まれる。

簡単に説明すると、Ｐ−ＣＳＣＦノード１０４は、ネットワーク１０２を含むアクセス・ネットワークからＩＭＳネットワーク１００への、クライアントのためのエントリ・ポイントとして動作する。ＩＭＳネットワーク１００における複数のＳ−ＣＳＣＦノードは、動作中の異なる端末に割り当てられて、ＳＩＰシグナリングを用いてそれらのセッションを管理し、この例において、図示されたＳ−ＣＳＣＦノード１０６は、端末Ａに関するセッションを処理する。さらに、Ｉ−ＣＳＣＦノード１０８は、他のＩＭＳネットワーク１１０からのＳＩＰメッセージを基本的に受信するゲートウェイとして動作する。

ＩＭＳネットワーク１００はまた、異なるマルチメディア・サービスのための１以上のアプリケーション・サーバ１１２と、クライアントのための種々の加入者データ及び認証データが保存されたメイン・データベース・ノードＨＳＳ（ホーム加入者サーバ）１１４とを含む。ＩＭＳネットワーク１００において図示されたネットワーク要素の種々の機能は、一般的に技術的に周知であるが、本発明の背景を理解するために、ここでさらに説明する必要はない。

各アプリケーション・サーバ１１２は、例えば「インスタント・メッセージング（Instant Messaging）」（ＩＭ）、「携帯電話上のプッシュ・ツー・トーク」（ＰｏＣ）、及び「プレゼンス（Presence）」等の、１以上の特定のマルチメディア・サービスをサポートし、それらのサービスにおいては、ＳＩＰシグナリングが制御セッションに使用される。特に、プレゼンス・サービスは、基本的に、オブザーブド（observed）・クライアントに関連するデータを他のウォッチング（watching）・クライアントに対して利用可能とする。

本明細書では、「プレゼンス・データ」又は一般的に「クライアント・データ」という用語は、あらゆる観点において、クライアント及びその装置の状態又は状況に関する情報を表現するために使用される。簡単に説明すると、クライアントのプレゼンス・データは、一般的に「プレゼンス・サーバ」と言われるアプリケーション・サーバにおける記憶装置によって発行され、そのプレゼンス・データに通知予約を行う他のクライアントに対して提供され得る。当該プレゼンス・データは、以下の典型的なクライアントの状態について言及することがある。
・使用可能、取り込み中、会議中、休暇中等の、個人的な状態
・スイッチ入／切、使用中、圏外等の、端末の状態
・クライアント／端末の地理的な位置
・ＳＭＳ、ＭＭＳ、チャット、ＩＭ、ビデオ等の、端末の性能
・呼転送、言語等の、端末の選択
・趣味、職業、個人的特徴、気分、個人的なマーク、現在の気分に応じたマーク等の、他のクライアントの情報

クライアント用の何れかのプレゼンス・データが入力、更新、変更又は削除されるごとに、クライアント又はそれらのアクセス・ネットワークから受信される、いわゆる「クライアント・イベント」の発行に基づいて、この種類の情報は、ＩＭＳネットワークのプレゼンス・サーバに継続的に格納される。従って、クライアントは、ＩＭＳネットワークのアプリケーション・サーバによってやはり処理される１以上の他のクライアントの、選択されたプレゼンス・データに対しても通知予約を行ってもよい。

本明細書において、「クライアント」という用語は一般的に、ユーザ装置（又は通信端末）及びそのユーザを表すために用いられる。さらに、「ウォッチング・クライアント（watching client）」という用語は、プレゼンス・データを通知予約又は要求するクライアント（場合によっては、「ウォッチャ（Watcher）」とも称される。）を表し、また、「オブザーブド・クライアント（observed client）」という用語は、認可されたウォッチング・クライアントにおいて使用可能なプレゼンス・データを発行するクライアント（場合によっては、「プレゼンティティ（Presentity）」とも称される。）を表す。

「ＳＩＰ＿ＰＵＢＬＩＳＨ」と呼ばれるＳＩＰメッセージは、一般的にオブザーブド・クライアントが、発行処理を目的としてプレゼンス・データをプレゼンス・サーバに送るために使用される。ＳＩＰ＿ＰＵＢＬＩＳＨメッセージは、４つの異なる場合、即ち、１）新たなデータを作成させる場合、２）データを「更新」（即ち、以前に作成されたデータが引き続き有効かを確認）する場合、３）データを修正する場合、及び４）もはや有効ではないデータを解除する場合において、基本的に使用される。

「ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ」と呼ばれるＳＩＰメッセージは、オブザーブド・クライアントのプレゼンス・データに対して通知予約をするために、ウォッチング・クライアントによって使用され、認可されたクライアントのみが当該データを受信する資格を与えられる。ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージは、多くの場合ＴＴＬ「有効期限」と称される、当該メッセージにセットされ得るタイムアウト変数によって定められるように、１回のみ又は複数回、プレゼンス・データを取得するために使用され得る。

ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージのタイムアウト変数が０に設定された場合、要求されたプレゼンス・データを含む通知は、１回だけ取得され、通知予約は、その後、直ちに解除される。当該タイムアウト変数が所定の期間＞０に設定された場合、ウォッチング・クライアントは、当該通知予約が期限切れとなるまで通知を受信する。また、通知は、例えば、定期的に若しくはデータが変更されるごとに「プッシュ（push）」型の機構を自動的に使用する要求により、又は「プル（pull）」型の機構を使用する要求により、受信される。

図２は、ウォッチング・クライアントであるユーザ装置Ａ、及びクライアントＢのために動作するプレゼンス・サーバ２００を含むＩＭＳネットワークに属するオブザーブド・クライアントであるユーザ装置Ｂを対象とした、プレゼンス・データを提供する現時点における従来の手順を示している。クライアントＢのプレゼンス・データは、プレゼンス・サーバ２００と結合したプレゼンス・データベース２０２において保持される。記載した手順は固定端末に対しても同様に適用され得るが、同図に示すように、クライアントＡ及びＢは移動端末で表現している。

最初のステップ２：１ａにおいて、一般的に、上述のように、オブザーブド・クライアントＢは、従来の手順に従ってＳＩＰ＿ＰＵＢＬＩＳＨメッセージをプレゼンス・サーバ２００に頻繁に送信することにより、プレゼンス・データを発行する。クライアントＢの一部のデータ、例えば、位置データや端末状態データは、クライアントＢのアクセス・ネットワーク（不図示）からも送信され得る。次のステップ２：１ｂにおいて、データベース２０２は、ステップ２：１ａのＳＩＰ＿ＰＵＢＬＩＳＨメッセージの受信に応じて適宜に更新される。ステップ２：１ａ及び２：１ｂは、一般的な手順に従って、バックグラウンドで継続する。

クライアントＡは、通知が受信され得るダイアログをプレゼンス・サーバと確立することにより、特定のプレゼンス・データを通知予約することができる。従って、ステップ２：２において、クライアントＡは、クライアントＢのプレゼンス・データに対する通知予約要求として、ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージを送信する。当該メッセージにおいて、所望の通知予約期間が当該ダイアログに対して指定される。上述のように、クライアントＡが、クライアントＢのプレゼンス・データを１回だけ受信しようとする場合（プル機構）、通知予約期間＝０であるが、クライアントＢが長期にわたってプレゼンス・データを受信しようとする場合（プッシュ機構）、通知予約期間＞０である。プレゼンス・サーバ２００は、その後、ステップ２：３においてクライアントＢのプレゼンス・データを読み出して、それを、ステップ２：４に示すように初期通知メッセージＳＩＰ＿ＮＯＴＩＦＹにおいてクライアントＡへ送信する。

破線の矢印で示すように、クライアントＡは、定期的な間隔で又はプレゼンス・データが変更されるごとに、所定の通知予約期間内に、さらなる場面でかかる通知を受信し得る。プレゼンス・サーバは、当該通知予約を保持するために必要となる通知予約期間の間中、所定のサーバ・リソースをも確保し、クライアントＢの所望のプレゼンス・データをクライアントＡに提供する。これには、通知を受信及び転送するための通信及びリソースの処理が含まれる。当該通知予約を延長又は「更新（refresh）」するために、クライアントＡは、当該通知予約時間が期限切れとなる直前に、さらなるＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージを送信することがあり、プレゼンス・サーバは、それにより当該通知予約及び関連するリソースを保持し続ける。

ウォッチング・クライアントは、複数のオブザーブド・クライアントのプレゼンス・データに通知予約を行うこともあり、それにより、ウォッチング・クライアントに対して送信される、更新されたプレゼンス・データ用に、多数の通知が頻繁に生じる。そのため、全てのオブザーブド・クライアント用の単一の通知をウォッチング・クライアントに送信するために、オブザーブド・クライアントからの通知を収集するための役割を果たすＲＬＳ（Resource List Server、リソース・リスト・サーバ）と呼ばれる情報配信サーバが提案されている。当該機構は、時には「エクスプローダ（exploder）」機能と呼ばれる。WO 2005/088949（テレフオンアクチーボラゲット エル エム エリクソンＡＢ）において、プッシュ／プル型機構を一体として使用することにより通知の数を減少させる別の解決手法が開示されている。

しかしながら、クライアント・ユーザが限られた期間中にプレゼンス通知を全く受信したくない場合、例えば、邪魔されたくない場合、セッション若しくは呼に掛かりきりの場合又はその他の場合、通知予約は解除されなければならない。当該通知を再開（レジューム）するために、その後当該通知予約は、再度作成、即ち、完全に新しい通知予約が作成されなければならない。当該手順について、図３のブロック図を参照して簡潔に説明する。図３は、ウォッチング・クライアントＡのＩＭＳネットワークにおけるＰ−ＣＳＣＦノード３０２及びＳ−ＣＳＣＦノード３０４とともに、ウォッチング・クライアントＡ、オブザーブド・クライアントＢ（図示せず）のプレゼンス・データを提供するプレゼンス・サーバ３００を含む。通知予約は、基本的に上述の図２で説明した方法で作成され、クライアントＡは、それに応じてクライアントＢのプレゼンス・データを含む通知を頻繁に受信する。

クライアントＡのユーザは、何らかの理由で、ある期間中に通知を保留することを決定しており、ユーザ端末における適当な入力コマンドを用いて当該通知予約を解除する。そのため、最初のステップ３：１において、クライアントＡは、継続中の通知予約を解除するために、例えば、ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ（期限＝０）等の、ＴＴＬ又は通知予約期間が０に設定された通知予約要求メッセージを、Ｐ−ＣＳＣＦノード３０２に対する現在のダイアログで送信する。次に、ステップ３：２において、Ｐ−ＣＳＣＦノード３０２は、当該通知予約要求メッセージをプレゼンス・サーバ３００に対してルーティングする。

次に、さらなるステップ３：３に示されているように、プレゼンス・サーバ３００は、当該通知予約を解除し、当該通知予約に確保されている全てのサーバ・リソースを解放する。図示していないが、サーバ３００は、当該時点でクライアントＡに対して最終的な通知を送信することもある。これは、当然、クライアントＢのこれ以上のプレゼンス通知が、クライアントＡに伝達されることはないことを意味している。

その後、クライアントＡのユーザがプレゼンス通知予約を再度作成したくなった場合には、次のステップ３：４において、新たなダイアログがサーバ２００と確立されなければならず、例えば、ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ（期限＞０）のように、新たな通知予約要求メッセージがＰ−ＣＳＣＦノード３０２に送信される。次に、続くステップ３：５において、当該通知予約を再度作成するために、Ｐ−ＣＳＣＦノード３０２は、当該通知予約要求メッセージを、当該要求に与えられたＳ−ＣＳＣＦノード３０４へルーティングする。Ｓ−ＣＳＣＦノード３０４は、完全に新しい通知要求を目的としたものである当該要求を、正しい宛先へルーティングすることが必要とされることに注意すべきである。従って、さらなるステップ３：６において、Ｓ−ＣＳＣＦノード３０４は、クライアントＡの当該通知予約要求メッセージをプレゼンス・サーバ３００へルーティングする。プレゼンス・サーバ３００は、このように、クライアントＡのために新たな通知予約を作成する。これには、当該通知予約に必要とされる種々のサーバ・リソースを確保するだけでなく、クライアントＡがクライアントＢのプレゼンス・データを受信する権限を与えられているか否かを確認することが含まれる。

図４は、ウォッチング・クライアントＡがＲＬＳノード４００を用いて複数のオブザーブド・クライアントＢ、Ｃ、Ｄ...のプレゼンス・データに対して通知予約する際の同様の手順を示している。図４のブロック図は、ウォッチング・クライアントＡのＩＭＳネットワークにおいて、Ｐ−ＣＳＣＦノード３０２及びＳ−ＣＳＣＦノード３０４を同様に含む。さらに、オブザーブド・クライアントＢ、Ｃ、Ｄ...上のプレゼンス・データをそれぞれ提供する、複数のプレゼンス・サーバ４０２が図示されている。クライアントＡは、作成されたＲＬＳ通知予約を用いて、ＲＬＳノード４００からオブザーブド・クライアントのプレゼンス・データを含む通知を頻繁に受信するものとしている。ＲＬＳノード４００は、オブザーブド・クライアントのそれぞれについて、プレゼンス・サーバ４０２と、個別のバックエンド（back-end）の通知予約をも作成している。

最初のステップ４：１において、クライアントＡは、当該通知を一時的に保留することを決定し、また、Ｐ−ＣＳＣＦノード３０２との既存のダイアログ内で、解除ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ要求（期限＝０）を送信することにより、ＲＬＳ通知予約を解除する。ステップ４：２において、Ｐ−ＣＳＣＦは、当該要求をＲＬＳノード４００へルーティングする。ステップ４：３において示すように、ＲＬＳは、１０−１００個の範囲の可能性があるプレゼンス・サーバ４０２と、全ての既存のバックエンド通知予約を直ちに解除しなければならず、また、このため、各プレゼンス・サーバの通知予約について、既存のダイアログ内で、解除ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ要求（期限＝０）を送信する。ＲＬＳノードは、当然ながら、プレゼンス・サーバ４０２からさらなる通知をその後に受信することはない。

次のステップ４：４において、クライアントＡは、遅かれ早かれ通知予約を再度作成することを決定し、初期ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ要求（期限＞０）をＰ−ＣＳＣＦ３０２へ送信する。続くステップ４：５において、Ｐ−ＣＳＣＦは、それに応じて、当該要求において指し示されるリソースを処理するＳ−ＣＳＣＦ３０４へ、当該要求をルーティングする。次のステップ４：６において、Ｓ−ＣＳＣＦは、次に、クライアントＡ用のＲＬＳ通知予約を作成するために、当該リクエストをＲＬＳノード４００へルーティングする。

さらなるステップ４：７において、ＲＬＳノード４００は、初期ＲＬＳ通知予約によって指し示されている各プレゼンス・サーバ４０２用の、バックエンド通知予約（予め定められた又はアドホックのことがある）を直ちに作成し、当該プレゼンス・サーバの通知予約に関する初期ＳＩＰ＿ＳＵＢＳＣＲＩＢＥ要求を、Ｓ−ＣＳＣＦノード３０４に対して送信する。最後に、ステップ４：８において、Ｓ−ＣＳＣＦノード３０４は、それぞれの通知予約を有効にするために、通知予約要求を各プレゼンス・サーバ４０２へルーティングする。

通知を保留するために通知予約を解除する、上述した従来の解決手法においては、異なるネットワーク・ノード及び要素の間で様々なメッセージが伝達されなければならないため、このようにプレゼンス通知予約を解除し、再作成するためには、相当な取り組みとシグナリングとが必要とされ、待ち時間をも招く。当該通知予約を保留するためにそれまでのダイアログを解放してしまっているため、通知予約の再作成は、ウォッチング・クライアントとプレゼンス・サーバとの間で新たなダイアログが確立されることをさらに必要とする。

さらに、休止（サスペンド）期間中に生じるいかなるクライアントの発行及びプレゼンスの更新も、ウォッチャに対して決して通知されることはない。特に、複数のオブザーブド・クライアントに対する通知予約のためにＲＬＳが使用される場合には、それらのクライアントの異なるプレゼンス・サーバは、ＲＬＳに対して通知を継続的に送信するが、現行の解決手法ではそれらの通知は失われる。従って、ウォッチング・クライアントに対するプレゼンス又はクライアント・データを含む通知を一時的に保留する場合に、上述した問題を回避又は少なくとも軽減することが望ましいだろう。

本発明の目的は、以上に概説した問題に対処することである。特に、本発明の目的は、１以上のオブザーブド・クライアントに関するクライアント又はプレゼンス・データを含む通知を一時的に保留するために必要なシグナリング及びメッセージ数を一般に低減可能な解決手法を提供することである。

これらの目的及びその他の目的は、添付する独立請求項による方法及び装置を使用することによって得られるであろう。

一実施形態によれば、本発明は、ウォッチング・クライアントのユーザ装置によって実行される、少なくとも１つのオブザーブド・クライアントのクライアント・データを含む通知を保留する方法を提供する。ウォッチング・クライアントは、クライアント・データ・サーバから当該通知を受信するための継続中の通知予約を有する。通知予約休止トリガが受信されると、当該通知予約を保持し続ける間に、クライアント・データ通知を一時的に保留することを指示する通知予約休止メッセージが、クライアント・データ・サーバへ送信される。その後、通知予約再開トリガが受信されると、クライアント・データ通知が再び配信することを指示する通知予約再開メッセージが、クライアント・データ・サーバへ送信される。クライアント・データ通知は、その後、通知予約に従って通常どおり受信される。

バッファリングされたクライアント・データ通知は、休止期間中にクライアント・データ・サーバによってバッファリングされた後に、通知予約再開メッセージに応じて、遡及的に受信されてもよい。

クライアント・データ通知は、複数のオブザーブド・クライアントに関連してもよく、また、クライアント・データ・サーバは、複数のオブザーブド・クライアントと関連する複数のクライアント・データ・サーバからクライアント・データ通知を受信するクライアント・データ集約サーバであってもよい。

任意の通知予約休止メッセージ及び通知予約再開メッセージは、それぞれ通知予約を休止又は再開することを示す特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージであってもよく、当該指示は、新たなヘッダに含まれているか、又はＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されている。

ＩＭＤネットワークが使用される場合、通知予約休止メッセージ及び通知予約再開メッセージは、クライアント・データ・サーバに対してさらにルーティングするために、ＩＭＳネットワークにおけるＰ−ＣＳＣＦノードに対して最初にルーティングされる。

休止期間中に、他の通知が受信されることを可能とする一方で、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみが保留されてもよい。

通知予約休止トリガは、ユーザの手動の入力コマンドとして受信されるか、又は、ユーザがセッション若しくは呼に掛かりきりの場合に又は予め設定された期間におけるユーザが使用中でない場合に、自動的に受信されてもよい。通知予約再開トリガもまた、ユーザの手動の入力コマンドとして受信されるか、又は、セッション若しくは呼が終了した場合に又は使用中でない期間の後にユーザが再び使用中となった場合に、自動的に受信されてもよい。

別の実施形態によれば、本発明は、上述の方法を実行する手段を備える、ウォッチング・クライアントのユーザ装置を提供する。

さらに別の実施形態によれば、本発明は、少なくとも１つのオブザーブド・クライアントのクライアント・データを含む、ウォッチング・クライアントに対する通知を保留する方法を提供し、当該方法は、当該通知を提供するクライアント・データ・サーバによって実行される。また、ウォッチング・クライアントは、クライアント・データ・サーバから当該通知を受信するための継続中の通知予約を有する。通知予約休止メッセージがウォッチング・クライアントから受信されると、クライアント・データ通知を提供するために必要となる通知予約及びサーバ・リソースが保持される間に、クライアント・データ通知が保留される。その後、通知予約再開メッセージがウォッチング・クライアントから受信されると、通知予約に従って、ウォッチング・クライアントに対してクライアント・データ通知が通常どおり送信される。

クライアント・データ通知は、好ましくは休止期間中にバッファリングされ、また、バッファリングされたクライアント・データ通知は、通知予約再開メッセージに応じて、ウォッチング・クライアントに対して遡及的に配信されてもよい。

他の通知が廃棄される一方で、休止期間の後に、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみが、遡及的に配信されてもよい。

クライアント・データ通知は、複数のオブザーブド・クライアントに関連してもよく、また、クライアント・データ・サーバは、個別のバックエンド通知予約に従って、複数のオブザーブド・クライアントと関連する複数のクライアント・データ・サーバから、クライアント・データ通知を受信するクライアント・データ集約サーバであってもよい。また、複数のクライアント・データ・サーバとのバックエンド通知予約の全て又は一部は、休止期間中に休止されてもよい。

休止期間中に、他の通知が受信されることを可能とする一方で、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみが保留されてもよい。

さらに別の実施形態によれば、本発明は、上述の方法を実行する手段を備える、クライアント・データ・サーバにおける装置を提供する。

本発明のさらなる特徴及びその効果は、以下の詳細な説明から理解され得る。

従来技術に係る、端末Ａにマルチメディア・サービスを提供可能なＩＭＳネットワークの概略図である。 従来技術に係る、オブザーブド・クライアントのプレゼンス・データを取得する従来の手順を示すブロック図である。 従来技術に係る、オブザーブド・クライアントのプレゼンス・データを含む通知を保留する従来の手順を示すブロック図である。 従来技術に係る、ＲＬＳノードを使用する複数のオブザーブド・クライアントのプレゼンス・データを含む通知を保留する従来の手順を示すブロック図である。 一実施形態に係る、オブザーブド・クライアントのクライアント・データを含む通知を保留する手順を示すフローチャートである。 別の実施形態に係る、ウォッチング・クライアントのユーザ装置によって実行される、オブザーブド・クライアントのクライアント・データを含む通知を保留する手順のフローチャートである。 さらに別の実施形態に係る、クライアント・データ・サーバによって実行される、オブザーブド・クライアントのクライアント・データを含む通知を保留する手順のフローチャートである。 さらに別の実施形態に係る、ＲＬＳノードを使用する複数のオブザーブド・クライアントのクライアント・データを含む通知を保留する手順を示すブロック図である。 さらなる実施形態に係る、１以上のオブザーブド・クライアントのクライアント・データを提供可能なウォッチング・クライアントのユーザ装置及びクライアント・データ・サーバを示すブロック図である。

典型的な実施形態を用いて及び添付の図面を参照して、本発明についてより詳細に説明する。簡潔に説明すると、本発明は、クライアント・データの通知予約の解除及び再作成を必要とせずに、ウォッチング・クライアントに対するクライアント又はプレゼンス・データを含む通知を一時的に保留するために使用され得る。休止期間の間、ウォッチング・クライアントに対して通知は送信されないものの、クライアント・データを提供するサーバにおける当該通知予約及び関連するリソースは、当該期間の間中、保持される。

休止期間を開始するために、ウォッチング・クライアントは、通知予約を一時的に休止することを指示する情報を含む休止メッセージを、クライアント・データ・サーバに対して送信する。その後、ウォッチング・クライアントは、休止されている通知予約を再開することを指示する情報を含む通知予約再開メッセージを送信し、クライアント・データ通知を再び配信することを可能とする。

保留中のクライアント・データ通知は何れも、クライアント・データ・サーバにおいてバッファリングされて、通知予約が再開されるとクライアントＡに対して「遡及的に」配信され得るか、又は休止期間の間に単に廃棄され得る。これらの選択肢は、例えば、異なるサブ情報を通知予約休止要求に含めることによって、又は予め設定された選択を用いて、クライアント・ユーザによって決定され得る。実際の通知予約は、通知を送信しないこととは別に、プレゼンス・サーバ又はクライアント・データ・サーバにおいて通常どおり保持されるとともに、休止期間中に通常の手順に従って期限切れとならないように更新されるであろう。

通知予約の休止は、例えば、邪魔されたくない場合等に、ユーザからの手動の入力コマンドを要因として生じ得る。あるいは、例えば、キーパッドを使用していない又はアドレス帳を検索していない等の、クライアントがセッション若しくは呼に掛かりきりの場合、又は予め設定された使用中でない期間にある場合に、端末自身によって自動的に生じ得る。同様にして、通知予約の再開も、当該ユーザ又は当該端末を要因として生じ得る。

以下の説明において、「プレゼンス・データ」という用語は、上述のように、利用可能な、又は「観察される（observed）」状態とされた任意のクライアント・データを表すために使用する。以下の実施形態ではプレゼンス・サービスについて一般的に説明しているが、本発明は、それらには限定されず、クライアント・データの通知予約機構を使用する任意のアプリケーション及びサービスに対して使用され得る。

さらに、以下の実施形態における「クライアント・データ・サーバ」は、例えば、図３及び図４でそれぞれ説明したようなプレゼンス・サーバ又はＲＬＳノードといった、認可されたウォッチング・クライアントに対して１以上のオブザーブド・クライアントの、要求されたクライアント・データを提供可能な任意のサーバであればよい。周知のＳＩＰメッセージにも言及するが、本発明はそれらに限定されることはない。

以下では図５に示すブロック図におけるシグナリングの手順を参照して、一実施形態について説明する。同図には、ウォッチング・クライアントＡ、Ｐ−ＣＳＣＦ等のセッション制御ノード５００、及びオブザーブド・クライアントＢ（図示せず）のクライアント・データを提供可能なクライアント・データ・サーバ５０２が含まれる。通知予約は、クライアント・データの通知のために上述のように作成されており、それに応じて、クライアントＡは、継続中のダイアログにおいて、クライアント・データ・サーバ５０２からクライアントＢのプレゼンス・データを含む通知を受信する。図３の従来技術の手順とは対照的に、本実施形態においては、ＩＭＳネットワークが使用される場合に、新たな通知予約を作成するためにＳ−ＣＳＣＦノードを必要とすることはない。

最初に、クライアントＡのユーザは、使用端末における適当な手動の入力コマンドを要因として、通知予約を一時的に休止することを決定する。あるいは、例えば、セッション又は呼に掛かりきりである場合には、上述のように端末自身が自動的に通知予約の休止を生じさせてもよい。最初のステップ５：１は、休止トリガを示している。何れかの場合に、次のステップ５：２において、クライアントＡは、既存のダイアログ内で、セッション制御ノード５００に対して通知予約休止要求を送信する。ＩＭＳネットワークにおいては、通知予約休止要求は、通知予約を休止することを指示する特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージでもよい。当該指示は、新たなヘッダに含まれてもよいし、又はＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されてもよい。

この場合、上述のように、休止期間中に保持され続ける通知予約の更新の手順とは無関係であるため、休止メッセージにおいて通知予約の期限時間を具体的に提供する必要はない。しかしながら、実装に応じて、ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージの一般的な標準規格に従って、当該時点において休止メッセージで新たな有効期限期間＞０を提供することも可能である。

ステップ５：３において、セッション制御ノード５００は、次に、クライアント・データ・サーバ５０２に対する通知予約休止要求をルーティングする。その結果、サーバ５０２は、当分、クライアントＡに対して何らの通知も送信しないことにより、通知予約を休止するが、クライアントＢから受信される発行メッセージを登録するために、当該通知予約に対して確保した全てのサーバ・リソースを保持する。クライアントＡとクライアント・データ・サーバ５０２との間の既存のダイアログは、休止期間の間中、保持され続けることに留意すべきである。

それと同時に、ステップ５：４で示されているように、サーバ５００は、さもなければ当該通知予約によってクライアントＡに対して送信されるであろうクライアント・データ通知の何れをも、バッファリングすることが望ましい。あるいは、休止期間中、クライアント・データ通知を何れも単に廃棄してもよい。休止期間中における保留中のクライアント・データ通知の処理は、例えば、通知予約休止要求において指示されることにより、又はクライアントのパラメータとしてネットワークにおいて保存された、予め定められた選択に応じて、クライアント・ユーザによって決定されてもよい。

その後の何れかの時点で、クライアントＡは、再び通知予約を再開するが、これは、ユーザからの手動による別の入力コマンドを要因として、又は、例えば、セッション若しくは呼が終了した場合や、使用していない期間の後にユーザが使用を再開する場合に、端末自身によって自動的に生じ得る。さらなるステップ５：５に再開トリガを示す。ステップ５：６において、クライアントＡは、何れかの場合に、保持し続けられているダイアログ内で、通知予約再開要求をセッション制御ノード５００に対して送信する。

ＩＭＳネットワークにおいて、通知予約再開要求は、ステップ５：２の休止要求と同様に、通知予約を再開することを指示する特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージでもよい。このように、再開指示は、新たなヘッダに含まれてもよいし、又はＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されてもよい。

次のステップ５：７において、セッション制御ノード５００は、次に、通知予約が再開されるクライアント・データ・サーバ５０２に対して通知予約再開要求をルーティングする。それに対する応答において、最後のステップ５：８に示すように、サーバ５０２は、バッファリングされた全ての通知と、もしあれば、通常の手順に従って生じるさらなる通知とを同様に、クライアントＡに対して送信する。

図５の上述の手順は、異なる方法に修正し得る。例えば、特定のオブザーブド・クライアント及び／又は特定の通知イベント・タイプのような、一部の通知のみが休止期間中に保留される一方で、その他の通知がクライアントＡに対して配信されること可能にしてもよい。そのような選択的な通知の配信は、フィルタ機能又はそれと同種のものによって制御されてもよい。当該フィルタは、ステップ５：２の通知予約休止要求において特定されてもよく、クライアントＡの選択として、ネットワークにおいて予め定義されてもよい。さらに、休止期間の後に、バッファリングされた通知の一部のみを配信することが可能である一方で、例えば、特定のオブザーブド・クライアント及び／又は特定の通知イベント・タイプに関して、上記のように類似のフィルタ機能を用いて、他の通知は廃棄されてもよい。

図６では、別の実施形態に係る、ウォッチング・クライアントのユーザ装置によって実行される、オブザーブド・クライアントのクライアント・データを含む通知を保留する手順のフローチャートを示している。当該手順は、基本的に、クライアントＡに関して図５に示す例に対応する。従って、ウォッチング・クライアントは、１以上のオブザーブド・クライアントのクライアント・データを含む通知のための、継続中の通知予約を有し、通知を提供するクライアント・データ・サーバ又はＲＬＳとダイアログが確立されている。

最初のステップ６００において、通知を当分伝達しないことを指示する通知予約休止トリガが受信される。休止トリガは、ユーザから又はセッション若しくは呼の確立に応じて自動的に受信されてもよいし、あるいは、ユーザが予め設定された期間、使用していない場合に受信されてもよい。

次のステップ６０２において、通知予約休止メッセージは、通知を提供するクライアント・データ・サーバ又はＲＬＳに対して送信され、これは、図５に示すように、ＩＭＳネットワークにおける、例えばＰ−ＣＳＣＦ等のセッション制御ノード上でルーティングされてもよい。図５におけるステップ５：２に関して上述したように、通知予約休止メッセージは、ウォッチング・クライアントに対して通知を送信しないようにする指示を含む。

さらなるステップ６０４において、通知の伝達を再び再開することを指示する通知予約再開トリガが受信される。同様にして、当該再開トリガは、ユーザから又はセッション若しくは呼の終了に応じて自動的に受信されてもよく、あるいは、使用していない期間の後にユーザが使用中となった場合に受信されてもよい。その後、次のステップ６０６において、通知予約再開メッセージが、通知を提供するクライアント・データ・サーバ又はＲＬＳに対して送信される。当該メッセージは、図５におけるステップ５：６に関して上述したように、通知を再びウォッチング・クライアントに対して配信することを示す指示を含む。当該再開メッセージは、セッション制御ノード（例えば、Ｐ−ＣＳＣＦ等）上で同様にルーティングされてもよい。

最後の任意のステップ６０８において、当該通知が保留中か、又は通知のバッファリングがクライアント・データ・サーバ又はＲＬＳにおいて必要とされているかどうかに応じて、バッファリングされた通知は何れも受信され得る。図示されていないが、それに続く通常の通知の何れも同様に受信される。

図７において、さらに別の実施形態に係る、クライアント・データ・サーバ又はそれと同様のものによって実行される、オブザーブド・クライアントのクライアント・データを含むウォッチング・クライアントに対する通知を保留する手順のフローチャートを示す。当該手順は、クライアントＡについて図５において示した例と基本的に一致し得るが、ＲＬＳノード、又は複数のオブザーブド・クライアントのエクスプローダとしての機能を果たす類似のものによっても実行され得る。さらに、ウォッチング・クライアントは、基本的に図６のフローチャートに従って機能する。このように、ウォッチング・クライアントは、１以上のオブザーブド・クライアントのクライアント・データを含む通知に対する継続中の通知予約を有するものとし、また、当該通知を提供する当該ウォッチング・クライアントとダイアログが確立されている。

最初のステップ７００において、図６のステップ６０２における通知予約休止メッセージが、ウォッチング・クライアントから受信される。次に、ステップ７０２において、それに応じて通知予約が休止されるが、解除はされず、ウォッチング・クライアントとの既存のダイアログも保持される。当然ながら、従来の解決手法とは対照的に、当該時点において最終的な通知は送信されない。

次の任意のステップ７０４に示すように、休止期間中、クライアントクライアント・データは、（複数の）オブザーブド・クライアントに関するクライアント・データ通知であって、後にウォッチング・クライアントに対する配信対象となる、保留中の通知としてバッファリングされ得る通知を、受信し続けてもよい。上述のように、休止期間中に通知がバッファリングされるべきか廃棄されるべきかという問題は、ウォッチング・クライアントの選択に従ってもよい。

さらなるステップ７０６において、その後のある時点で、図６のステップ６０６において通知予約再開メッセージがウォッチング・クライアントから受信される。その後それに応じて、最後のステップ７０８において、通知予約が再開される。さらに、通知のバッファリングがクライアント・データ・サーバ又はＲＬＳの何れで要求されているかに応じて、及びそのような通知が保留中である場合に、バッファリングされた任意の通知が、クライアントに対して状況に応じて送信される。最初の通知は、通常、通知を再開する場合に送信されることが望ましいだろう。図示されていないが、当然、それに続く通常の通知の何れも同様にクライアントに対して送信される。

本発明は、ウォッチング・クライアントが、複数のオブザーブド・クライアントのリストに従ってクライアント・データに対して通知予約する場合にも使用され得る。その場合、上述のように、ＲＬＳノード又はそれと同等のものが、集約した通知を提供するために使用される。

図８は、さらに別の実施形態に係る、クライアント・データ集約サーバ８００、及び例えばＰ−ＣＳＣＦノード等のセッション制御ノード８０２を使用する、複数のオブザーブド・クライアントのクライアント・データを含む通知を保留する手順を示すブロック図である。クライアント・データ集約サーバ８００は、上述のように、各クライアント・サーバ８０４からの通知に対する個別のバックエンド通知予約に基づいて、ＲＬＳノード又はエクスプローダと同様に、複数のオブザーブド・クライアントの、集約したクライアント・データ通知を提供することが可能である。クライアントＡは、それまでに作成された通知予約に従って、継続中のダイアログにおいて、当該集約サーバ８００から通知を受信する。さらに、図４の従来の手順とは対照的に、本実施形態においては、複数のクライアント・データ・サーバとの新たな通知予約を作成するために、ＩＭＳネットワークにおいてＳ−ＣＳＣＦノードを含むことを必要としない。

図８のいくつかのステップは、図５に示す手順のステップに対応するため、ここでは詳細な説明を繰り返す必要はない。図５のステップ５：１のように、最初のステップ８：１には、休止トリガを示す。それに対して、次のステップ８：２において、図５のステップ５：２のように、クライアントＡは、既存のダイアログ内で、通知予約休止要求をセッション制御ノード８０４に対して送信する。これは、ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージでもよい。次に、ステップ８：３において、セッション制御ノード８０２は、通知予約休止要求を集約サーバ８００に対してルーティングする。

サーバ８００は、次に、通知予約を休止するが、クライアントＡとの既存のダイアログ、及びクライアント・データ・サーバ８０４との全てのバックエンド通知予約と同様に、当該通知予約に対して確保した全てのサーバ・リソースを保持する。これは、概略のステップ８：４に示すように、バックエンド通知予約に従って、クライアント・データ・サーバ８０４から通知を受信し続けることを意味している。図５のステップ５：４のように、ステップ８：５において、休止期間中に、サーバ５００は、これらの通知をバッファリングしてもよく、または廃棄してもよい。あるいは、クライアント・データ集約サーバ８００は、休止期間中、クライアント・データ・サーバ８０４とのバックエンド通知予約の全て又は一部を休止してもよく、その結果、それらのクライアント・データ・サーバ８０４から通知は受信されなくなる。長い休止期間の場合、ウォッチング・クライアントＡ又はクライアント・データ集約サーバ８００は、バックエンド通知予約を休止することを決定してもよい。

ステップ８：６には、再開トリガを示しており、ステップ８：７において、クライアントＡは、既存のダイアログ内で通知予約再開要求をセッション制御ノード８０２に対して送信する。このように、これらはそれぞれ図５のステップ５：６及び５：７に完全に対応する。さらに、通知予約再開要求は、先の通知予約休止要求と同様に、図５に関して説明したＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージでもよい。

次に、さらなるステップ８：８において、セッション制御ノード８０２は、通知予約再開要求を集約サーバ８００に対してルーティングする。さらに、最後のステップ８：９において、サーバ８００は、バッファリングした通知をクライアントＡに対して送信し、もしあれば通常の手順によるさらなる通知も送信する。

図９は、さらなる実施形態に係る、１以上のオブザーブド・クライアント（図示せず）のクライアント・データを、ウォッチング・クライアントに対して提供する場合の、ウォッチング・クライアントＡのユーザ装置９００及びクライアント・データ・サーバ９０２をより詳細に示すブロック図である。同図における種々の構成要素は、論理的な機能部として示されているにすぎず、ハードウェア及びソフトウェアの任意の適当な組み合わせを用いて実装され得る。

ユーザ装置９００は、手動のユーザ入力コマンドに応じて、通知予約休止及び再開トリガを提供するユーザ入力部９００ａを含む。トリガ部９００ｂは、通知予約休止トリガを自動的に提供してもよい。ユーザ入力部９００ａは及びトリガ部９００ｂは、基本的に、図５のステップ５：１及び５：５、並びに図８のステップ８：１及び８：６についてそれぞれ説明したように動作する。

ユーザ装置９００は、上述のトリガに応じて通知予約休止メッセージ及び通知予約再開メッセージを作成するロジック部９００ｃを含む。通信部９００ｄは、作成された通知予約休止及び再開メッセージＳ、Ｒを、基本的に、図５のステップ５：２及び５：６、並びに図８のステップ８：２及び８：７についてそれぞれ説明したように、クライアント・データ・サーバ９０２に対して送信する。通信部９００ｄはまた、基本的に、図５のステップ５：８及び図８のステップ８：９についてそれぞれ説明したように、クライアント・データ・サーバ９０２から通知Ｎを受信する。

クライアント・データ・サーバ９０２は、図８のステップ８：４に説明したように、クライアント自身若しくはそれらのネットワークから、又はバックエンド通知予約に基づいて、関連するクライアント・データ・サーバから、１以上のオブザーブド・クライアントに関するクライアント・データ通知Ｎを受信する、通知予約受信部９０２ａを含む。

クライアント・データ・サーバ９０２は、通知予約を休止及び再開し、及びウォッチング・クライアントに対するクライアント・データ通知を作成するロジック部９０２ｂをさらに含む。ロジック部９０２ｂはまた、基本的に、図５のステップ５：４及び図８のステップ８：５についてそれぞれ説明したように、必要とされる場合には、休止期間中に受信した通知Ｎをバッファ・メモリ９０２ｃに格納してもよい。

クライアント・サーバ９０２の通信部９０２ｄは、通知予約休止及び再開メッセージＳ、Ｒを、クライアントＡのユーザ装置９００から受信し、さらに、ロジック部９０２ｂは、それに応じて当該通知予約を制御する。通信部９０２ｄはまた、基本的に、図５のステップ５：８及び図８のステップ８：９についてそれぞれ説明したように、クライアント・データ通知をウォッチング・クライアントに対して配信する。

休止／再開機能を使用したいウォッチング・クライアントは、クライアント・データ・サーバが当該機能をサポートしているかを確かめる方法を必要とする。これは、以下に説明する３つの選択肢によって行うことができる。
１）クライアント・データ・サーバが、応答において、当該機能をサポートしているか否かを示すことができるように、ウォッチング・クライアントは、最初の通知予約要求において、休止／再開機能をサポートしていることを示してもよい。
２）クライアント・データ・サーバは、初期設定で、継続中のダイアログにおける通常の応答において、休止／再開機能をサポートしていることを示してもよい。
３）ウォッチング・クライアントは、通知予約休止要求を送信してもよく、クライアント・データ・サーバは、休止／再開機能をサポートしていない場合、その結果、完全な通知メッセージに加えて通常の応答を返す。クライアントは、その後、当該ダイアログにおける当該機能の使用を停止することができる。

本解決手法は、リアルタイムに端末で制御されるだけでなく、設定変更可能である。これは、ウォッチング・クライアントのユーザ又はその操作者は、クライアント・データ通知予約が一時的に休止される場合に、特定の場面又は期間の決定及び設定が可能であることを意味する。既存の通知予約を認識しているステイトフル（stateful）なプロキシ等の、ウォッチング・クライアントのアクセス・ネットワークにおける他の構成要素は、アクセス・ネットワークの一部が使用不可能である場合又は大きな負荷の影響下にある場合等、特定の場面又は期間において、通知予約を休止してもよい。

本発明は、通知予約を解除及び作成する必要なしに、通知予約を休止／再開するために使用され得るとともに、それにより、相当の取り組み及びシグナリング動作を抑制する。一般的に、以下の効果について言及し得る。
１）既存の標準規格の要求に対する小規模な拡張（例えば、新たなヘッダ又は既存のヘッダにおける特別なデータ）を有する、既存の機構を使用することにより、通知予約を一時的に休止することができる。休止／再開機能を実装するために、ウォッチング・クライアントのユーザ装置及びクライアント・データ・サーバを適合させる必要があるのみである。その結果、例えばＩＭＳコア等の、いかなる既存のプロキシも影響を受けない。
２）休止期間中に生成されている通知を喪失することなしに、休止を実行することができる。これは、例えばＲＬＳ等のエクスプローダ機能の場合に特に有用である。
３）本発明は、ネットワークにおいて送信される必要があるシグナリング・メッセージの量を低減可能である。これは、特にエクスプローダの場合に、性能を向上させることが可能であり、通知予約の再開の待ち時間を改善することが可能であることを意味する。背景のセクションにおいて概説した従来の手順に従って、１以上のクライアント・データの通知予約を解除及び再作成するための機能性が、ウォッチング・クライアント及びクライアント・データ・サーバにおいても、任意のステイトフルなプロキシにおいても必要とされることはないため、当該性能を、強化することもできる。

本発明について、特定の典型的な実施形態を参照して説明してきたが、本明細書は、発明の概念を説明することを一般的に意図しているのみであり、本発明の範囲を限定するものと解釈されるべきではない。当該範囲は、添付した特許請求の範囲によって定められる。本発明を実施するために適した他の標準規格及びプロトコルは、基本的に使用され得るが、上述の実施形態を説明する際には、ＩＭＳ技術及びＳＩＰシグナリング・プロトコルが、時に使用されている。

Claims (23)

1. クライアント・データ・サーバから通知を受信するための継続中の通知予約を有するウォッチング・クライアントのユーザ装置によって実行される、少なくとも１つのオブザーブド・クライアントのクライアント・データを含む前記通知を保留する方法であって、
   通知予約休止トリガを、前記ユーザがセッション若しくは呼に掛かりきりの場合に自動的に受信するステップと、
   前記通知予約を保持する間にクライアント・データ通知を一時的に保留することを指示する通知予約休止メッセージを、前記通知予約休止トリガに応じて、継続中の前記通知予約の期間に前記クライアント・データ・サーバに対して送信するステップと、
   通知予約再開トリガを、前記セッション若しくは呼が終了した場合に自動的に受信するステップと、
   休止した前記通知予約を再開することを指示し、クライアント・データ通知を再び配信することを可能とする通知予約再開メッセージを、前記通知予約再開トリガに応じて前記クライアント・データ・サーバに対して送信するステップと、
   前記通知予約に従ってクライアント・データ通知を受信するステップと
   を含むことを特徴とする方法。
2. バッファリングされたクライアント・データ通知は、
   休止期間中に前記クライアント・データ・サーバによってバッファリングされた後に、前記通知予約再開メッセージに応じて、遡及的に受信されることを特徴とする請求項１に記載の方法。
3. 前記クライアント・データ通知は、複数のオブザーブド・クライアントに関連し、
   前記クライアント・データ・サーバは、
   複数のオブザーブド・クライアントと関連する複数のクライアント・データ・サーバからクライアント・データ通知を受信するクライアント・データ集約サーバであることを特徴とする請求項１又は２に記載の方法。
4. 前記通知予約休止メッセージは、
   前記通知予約を休止することを示す特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージであり、
   当該指示は、新たなヘッダに含まれているか、又は前記ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されていることを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. 前記通知予約再開メッセージは、
   前記通知予約を再開することを示す特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージであり、
   当該指示は、新たなヘッダに含まれているか、又は前記ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されていることを特徴とする請求項１乃至４の何れか１項に記載の方法。
6. 前記通知予約休止メッセージ及び前記通知予約再開メッセージは、
   前記クライアント・データ・サーバに対してさらにルーティングするために、ＩＭＳネットワークにおけるＰ−ＣＳＣＦノードに対して最初にルーティングされることを特徴とする請求項１乃至５の何れか１項に記載の方法。
7. 休止期間中に、他の通知が受信されることを可能とする一方で、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみが保留されることを特徴とする請求項１乃至６の何れか１項に記載の方法。
8. ウォッチング・クライアントが、クライアント・データ・サーバから通知を受信するための継続中の通知予約を有する場合に、少なくとも１つのオブザーブド・クライアントのクライアント・データを含む前記通知を保留する前記ウォッチング・クライアントのユーザ装置であって、
   通知予約休止トリガを、前記ユーザがセッション若しくは呼に掛かりきりの場合に自動的に受信する手段と
   前記通知予約を保持する間にクライアント・データ通知を一時的に保留することを指示する通知予約休止メッセージを、前記通知予約休止トリガに応じて、継続中の前記通知予約の期間に前記クライアント・データ・サーバに対して送信する手段と、
   通知予約再開トリガを、前記セッション若しくは呼が終了した場合に自動的に受信する手段と、
   休止した前記通知予約を再開することを指示し、クライアント・データ通知を再び配信することを可能とする通知予約再開メッセージを、前記通知予約再開トリガに応じて前記クライアント・データ・サーバに対して送信する手段と、
   前記通知予約に従ってクライアント・データ通知を受信する手段と
   を備えることを特徴とするユーザ装置。
9. 少なくとも１つのオブザーブド・クライアントのクライアント・データを含む通知を提供するクライアント・データ・サーバによって実行される、前記クライアント・データ・サーバから前記通知を受信するための継続中の通知予約を有するウォッチング・クライアントに対する前記通知を保留する方法であって、
   前記通知予約を保持する間にクライアント・データ通知を一時的に保留することを指示する通知予約休止メッセージであって、前記ウォッチング・クライアントがセッション若しくは呼に掛かりきりの場合に前記ウォッチング・クライアントから自動的に送信される前記通知予約休止メッセージを、継続中の前記通知予約の期間に受信するステップと、
   前記クライアント・データ通知を提供するために必要となる前記通知予約及びサーバ・リソースを保持する間に、前記クライアント・データ通知を保留するステップと、
   クライアント・データ通知を再び配信することを指示する通知予約再開メッセージであって、前記セッション若しくは呼が終了した場合に前記ウォッチング・クライアントから自動的に送信される前記通知予約再開メッセージを受信するステップと、
   前記通知予約再開メッセージに応じて、前記通知予約に従って前記ウォッチング・クライアントに対してクライアント・データ通知を送信するステップと
   を含むことを特徴とする方法。
10. クライアント・データ通知は、休止期間中にバッファリングされ、
    バッファリングされた前記クライアント・データ通知は、前記通知予約再開メッセージに応じて、前記ウォッチング・クライアントに対して遡及的に配信されることを特徴とする請求項９に記載の方法。
11. 他の通知が廃棄される一方で、休止期間の後に、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみが、遡及的に配信されることを特徴とする請求項１０に記載の方法。
12. 前記クライアント・データ通知は、複数のオブザーブド・クライアントに関連し、
    前記クライアント・データ・サーバは、
    個別のバックエンド通知予約に従って、前記複数のオブザーブド・クライアントと関連する複数のクライアント・データ・サーバから、クライアント・データ通知を受信するクライアント・データ集約サーバであることを特徴とする請求項９乃至１１の何れか１項に記載の方法。
13. 前記複数のクライアント・データ・サーバとの前記バックエンド通知予約の全て又は一部は、休止期間中に休止されることを特徴とする請求項１２に記載の方法。
14. 受信された前記通知予約休止メッセージは、
    前記通知予約を休止することを示す特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージであり、
    当該指示は、新たなヘッダに含まれているか、又は前記ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されていることを特徴とする請求項９乃至１３の何れか１項に記載の方法。
15. 受信された前記通知予約再開メッセージは、
    前記通知予約を再開することを示す特定の指示を含むＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージであり、
    当該指示は、新たなヘッダに含まれているか、又は前記ＳＩＰ＿ＳＵＢＳＣＲＩＢＥメッセージにおける既存のヘッダに対して任意のパラメータとして付加されていることを特徴とする請求項９乃至１４の何れか１項に記載の方法。
16. 前記通知予約休止メッセージ及び前記通知予約再開メッセージは、
    前記ウォッチング・クライアントからのメッセージをルーティングする、ＩＭＳネットワークにおけるＰ−ＣＳＣＦノードから受信されることを特徴とする請求項９乃至１５の何れか１項に記載の方法。
17. 休止期間中に、他の通知が受信されることを可能とする一方で、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみが保留されることを特徴とする請求項９乃至１６の何れか１項に記載の方法。
18. 少なくとも１つのオブザーブド・クライアントのクライアント・データを含む通知を提供するクライアント・データ・サーバから前記通知を受信するための、継続中の通知予約をウォッチング・クライアントが有する場合に、前記ウォッチング・クライアントに対する前記通知を保留するクライアント・データ・サーバにおける装置であって、
    前記通知予約を保持する間にクライアント・データ通知を一時的に保留することを指示する通知予約休止メッセージであって、前記ウォッチング・クライアントがセッション若しくは呼に掛かりきりの場合に前記ウォッチング・クライアントから自動的に送信される前記通知予約休止メッセージを、継続中の前記通知予約の期間に受信する手段と、
    前記クライアント・データ通知を提供するために必要となる前記通知予約及びサーバ・リソースを保持する間に、前記クライアント・データ通知を保留する手段と、
    クライアント・データ通知を再び配信することを指示する通知予約再開メッセージであって、前記セッション若しくは呼が終了した場合に前記ウォッチング・クライアントから自動的に送信される前記通知予約再開メッセージを受信する手段と、
    前記通知予約再開メッセージに応じて、前記通知予約に従って前記ウォッチング・クライアントに対してクライアント・データ通知を送信する手段と
    を備えることを特徴とする装置。
19. クライアント・データ通知を、休止期間中にバッファリングする手段と、
    バッファリングされた前記クライアント・データ通知を、前記通知予約再開メッセージに応じて、前記ウォッチング・クライアントに対して遡及的に送信する手段と
    をさらに備えることを特徴とする請求項１８に記載の装置。
20. バッファリングされたクライアント・データ通知を送信する前記手段は、
    他の通知を廃棄する一方で、休止期間の後に、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみを、遡及的に送信することを特徴とする請求項１９に記載の装置。
21. 前記クライアント・データ通知は、複数のオブザーブド・クライアントに関連し、
    前記クライアント・データ・サーバは、
    個別のバックエンド通知予約に従って、前記複数のオブザーブド・クライアントと関連する複数のクライアント・データ・サーバから、クライアント・データ通知を受信するクライアント・データ集約サーバであることを特徴とする請求項１８乃至２０の何れか１項に記載の装置。
22. 前記クライアント・データ集約サーバは、
    休止期間中に、前記複数のクライアント・データ・サーバとの前記バックエンド通知予約の全て又は一部を休止することを特徴とする請求項２１に記載の装置。
23. 前記保留する手段は、
    休止期間中に、他の通知が受信されることを可能とする一方で、特定のオブザーブド・クライアント及び特定の通知イベント・タイプの少なくとも１つの通知のみを保留することを特徴とする請求項１８乃至２２の何れか１項に記載の装置。

Images