JP2011507069A

JP2011507069A - プレゼンスメッセージのサイズを縮小する方法

Info

Publication number: JP2011507069A
Application number: JP2010536877A
Authority: JP
Inventors: アンデシュリンドグレン，; クリステルボベルイ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-12-04
Filing date: 2007-12-04
Publication date: 2011-03-03
Anticipated expiration: 2027-12-04
Also published as: CN101889426B; EP2218243A4; HK1150695A1; EP2218243B1; EP2218243A1; US9591129B2; US20100274844A1; CA2706966A1; JP4995970B2; CN101889426A; WO2009072942A1

Abstract

通信ネットワークにおいて、情報交換サービスに関連するメッセージを配信する方法。２つのエンティティ間で配信されることになるメッセージについて、データコンテンツがすでに着信エンティティに配信されたのかどうかを判断するために、問い合わせが行われる。データコンテンツがまだ第２のエンティティに配信されていない場合、メッセージは、そのまま第２のエンティティへ送信され、他方、メッセージは修正され、その修正されたメッセージが、データコンテンツを識別するデータ識別子を含むけれどもデータコンテンツを含まないようにされる。次いで、修正されたメッセージは、着信エンティティへ送信され、データ識別子は、メッセージの送信の成功が検証（確認）された時、関連のデータコンテンツと一緒にキャッシュされる。提案するバージョニングメカニズムによって、サイズが縮小されたメッセージの送信が可能になる。

Description

本発明は、一般に、例えば、クライアントとサーバとの間で、またはその逆に通信される、例えばＳＩＰメッセージのようなメッセージのサイズを縮小するための方法および装置に関する。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動通信ネットワーク上でＩＰマルチメディアサービスを提供するために第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって定義された技術である。ＩＭＳは、セッション開始プロトコル（ＳＩＰ）を利用して、ユーザエンティティ間の、あるいは、ユーザエンティティあるいはクライアントとサーバとの間の呼もしくはセッションをセットアップして制御する。ＳＩＰはユーザ間のプロトコルとして作成されたのだが、ＩＭＳは、オペレータ各社およびサービスプロバイダ各社が、サービスに対するユーザアクセスを制御し、それに応じてユーザに課金することを可能にする。３ＧＰＰアーキテクチャは、ＩＭＳにおいて多様なユーザエンティティにサービスを提供する、多様なタイプの呼セッション制御機能（ＣＳＣＦ）を定義する。

ＩＭＳクライアントＡが別のＩＭＳクライアントＢに関する最新情報を保持することを望む状況は数多く存在するが、クライアントＢは、そうするためのアクセス許可をクライアントＡに前もって与えておく。ＩＥＴＦＳＩＭＰＬＥ（ＳＩＰＩｎｓｔａｎｔＭｅｓｓａｇｉｎｇａｎｄＰｒｅｓｅｎｃｅＬｅｖｅｒａｇｉｎｇＥｘｔｅｎｓｉｏｎｓ）技術に基づくＰｒｅｓｅｎｃｅＳｅｒｖｉｃｅ（プレゼンスサービス）は、ＳＩＰイベント通知の枠組みの上に構築された特殊なアプリケーションである。このタイプのサービスによって、ユーザは、到達可能性と、利用可能性と、別のユーザが通信を行う意思を持っているということとについて情報を得ることが可能になる。プレゼンスサービスは、多様なユーザがオンラインで接続しているか否かを、そして、オンラインユーザがアイドル状態であるかビジーであるかを示すのに用いられてもよい。またプレゼンスサービスは、通信手段の詳細と、各通信手段の各能力とを明らかにしてもよい。プレゼンス情報を提供している人は、典型的にはプレセンスエンティティまたはプレゼンティティと呼ばれる。所与のプレゼンティティは、クライアントとして動作する１つ以上のエンティティを有してもよく、それらは、典型的にはプレゼンスユーザエージェント（ＰＵＡ）とも呼ばれていて、最新のプレゼンス情報、すなわち、例えばステータス、能力および／または、通信アドレスといったプレゼンティティの特性を特徴付ける属性のセットを、プレゼンスサービスを購読ユーザに提供するサーバに対して供給することができる。

図１は、先行技術によってプレゼンスサービスを提供するように構成されたＳＩＰプレゼンスアーキテクチャの例示的なシナリオを略示する図である。ＩＭＳネットワーク１００において、３つのクライアント１０１乃至１０３は、例えばＩＭＳ端末と、ラップトップと、および／またはデスクトップコンピュータとのいずれであってもよいが、各々がプレゼンティティ１０４についての情報の断片をローカルに記憶する。別のクライアントが、プレゼンティティ１０４についての別の情報を保持してもよいし、同じ情報を保持してもよい。ＩＭＳ端末が、例えば、プレゼンティティ１０４の登録ステータスについての情報を保持し、他方、ラップトップが、プレゼンティティ１０４がログオンされているか否かに関する情報を保持していてもよい。加えて、例えばプレゼンティティがテレビ会議に参加できるか、および／または現時点で音声呼の受信を望むかどうかといった、より豊富なプレゼンス情報をクライアントが保持してもよい。すべてのプレゼンティティクライアント１０１乃至１０３が、それらの各々の情報の断片をプレゼンスサーバ１０５へ送信し、それによって、すべての情報が収集されて、プレゼンティティ１０４のプレゼンスの全体像が得られる。また、図１は２人のユーザ１０６と１０７とを示しているが、それらは典型的にはウォッチャーと呼ばれ、各々がそれぞれのエンティティ１０８および１０９を備えており、そしてその場合、各エンティティはそれぞれのウォッチャークライアントとして動作し、それを介してそれぞれのユーザ１０６および１０７が、リストの中で、すなわちプレゼンティティのプレゼンスリストの中で指定される特定のプレゼンティティまたは複数のプレゼンティティのプレゼンス情報を購読(subscribe)してもよい。プレゼンスサーバ１０５は、それぞれのプレゼンティティのプレゼンス情報に変化が生じた時、すなわち、プレゼンティティが新たなプレゼンス情報をプレゼンスサーバ１０５に対してＳＩＰＰＵＢＬＩＳＨ要求を介して配信した時、発行された情報をそれぞれの１人以上のウォッチャーに対してＳＩＰＮＯＴＩＦＹ要求のかたちで配信することによって、すべての購読するウォッチャーに通知する。

現行のＳＩＭＰＬＥに基づいた解決策では、プレゼンスデータに変化が生じる度に、プレゼンスサーバが、すべてのデータを含む新たな通知、またはデータの一部（すなわち部分的通知）を送信する必要がある。そのような通知は、プレゼンスデータが以前の通知の中でそれぞれのウォッチャーにすでに配信されたか否かに関らず、送信されなければならない。

プレゼンスサーバからウォッチャーへ送信される通知の多くは、例えば、あるサービスについての「開放(open)」または「閉鎖(closed)」のような、１つのデータの単なるトグリングであるため、２つのエンティティ間ですでに配信された多量のデータが、無線インタフェースで送信される。部分的通知の場合でさえ、そのサイズは相当大きい。

加えて、同じデータコンテンツを繰り返し送信するには、複雑な機能性が必要となり、通知を作成するサーバにおいても、受信した通知をそれぞれ処理し、処理したコンテンツに基づいて最終結果を作成する必要のあるウォッチャーにおいても、費用のかかる処理をさせることになる。

本発明の目的は、上で概要を述べた問題のうちの少なくとも一部に対処することである。特に、本発明の目的は、通信ネットワークにおいてクライアントとサーバとの間で、またはその逆に送信される何らかのメッセージのサイズを概して減少させることができるソリューションを提供することである。

これらの目的は、他の目的と一緒に、添付の独立請求項に従う方法およびエンティティを使用することにより達成可能である。

一態様によれば、本発明は、第１のエンティティと第２のエンティティとの間の情報交換サービスに関連するメッセージを通信ネットワークにおいて配信する方法を提供する。最初に、情報交換サービスに関連しデータコンテンツとバージョニングの要求とを含むメッセージが第１のエンティティにおいて処理される。バージョニングは選択可能なメカニズムとして定義され、メッセージのデータコンテンツの各バージョンに対して各バージョンを識別するデータ識別子を関連付けるように構成される。次に第１のエンティティは受信したメッセージに対して問い合せを行い、データコンテンツが以前の送信において第２のエンティティへ既に配信されているか否かを判定する。データコンテンツが第２のエンティティへ既に配信されていると判定された場合、メッセージは第２のエンティティへ送信される際に変更されないままである。しかしながら、データコンテンツが第２のエンティティへ既に配信されているということが分かった場合、データ識別子を含むがデータコンテンツを含まない修正されたメッセージが代わりに、第２のエンティティへ送信される。

第１の実施形態によれば、第１のエンティティはサーバであり、第２のエンティティはクライアントである。

典型的には、第１のエンティティは受信されるメッセージを実行する前に、情報交換サービスの要求を第２のエンティティから受信する。ここで、要求はバージョニングが必要とされるという指標を含む。メッセージは、クライアントからサーバへ送信されるＳＩＰ通知であってもよい。

第２の実施形態によれば、第１のエンティティは代わりにクライアントであり、第２のエンティティはサーバである。そのような実施形態では、メッセージは代わりにＳＩＰ発行であってもよい。

提案される判定ステップは、各データコンテンツが第２のエンティティへ既に配信されているか否かを判定するために、第１のエンティティのキャッシュに問い合わせるステップを含んでもよい。

一態様によれば、データ識別子は第１のエンティティにおいてメッセージに挿入される。

他の態様によれば、データ識別子は代わりに第２のエンティティから提供される。

第２のエンティティから提供されるデータ識別子は、メッセージの配信の成功を示す応答メッセージの中で第１のエンティティへ提供されてもよい。

他の態様によれば、本発明は、情報交換サービスに関連するメッセージを第１のエンティティにおいて扱う、通信ネットワークにおける方法を提供する。ここで、メッセージは第２のエンティティから第１のエンティティへ配信される。

最初に、第１のエンティティは、要求された情報交換サービスに関連するメッセージを受信する。ここで、メッセージはバージョニングの要求を含む。第１のエンティティにおいて、バージョニングを要求するメッセージがデータコンテンツを含むか否かが判定される。メッセージがデータコンテンツを含むと分かった場合、データコンテンツに関連付けられるデータ識別子が第１のエンティティによって取得され、データコンテンツはデータ識別子と共に格納される。

しかしながら、メッセージがデータコンテンツを含まない場合、メッセージから取得されるデータ識別子に関連付けられたデータコンテンツが代わりにメッセージに与えられる。各データコンテンツが取得されると、メッセージはそれに従って処理され得る。

第１の実施形態によれば、第１のエンティティはクライアントであり、第２のエンティティはサーバである。そのようなシナリオでは、メッセージはＳＩＰ通知であってもよい。

一態様によれば、上述した受信ステップの実行に先立って、情報交換サービスの要求であってバージョニングが必要とされるということを示す要求が第２のエンティティへ転送される。

第２の実施形態によれば、第１のエンティティは代わりにサーバであり、他方、第２のエンティティはクライアントである。そのような場合、メッセージは代わりにＳＩＰ発行であってもよい。

一態様によれば、データ識別子は第１のエンティティから取得される。ここで、データ識別子は、メッセージが成功裏に配信されたということを示す応答メッセージの中で第１のエンティティから第２のエンティティへ転送されてもよい。

更に他の態様によれば、データ識別子は代わりにメッセージから取得されてもよく、データメッセージは第２のエンティティにおいてメッセージに挿入される。

他の態様によれば、メッセージが第２のエンティティへ成功裏に配信されたということ、そしてデータコンテンツおよび関連付けられたデータが第２のエンティティの別のキャッシュに格納されたということを確認する応答メッセージの受信に引き続いて、データコンテンツおよび関連付けられたデータ識別子が第１のエンティティのキャッシュに格納される。

一態様によれば、最初の応答メッセージが、第２のエンティティのキャッシュの全容量の指標を含む。

他の態様によれば、各応答メッセージが代わりに、第２のエンティティのキャッシュの残り容量の指標を含んでもよい。データ識別子は、バージョン番号であってもよいし、一意のＩＤであってもよいし、Ｅｔａｇであってもよい。

他の態様によれば、情報交換サービスに関連するメッセージを第２のエンティティへ配信する第１のエンティティが提供される。処理ユニットは、データコンテンツとバージョニングの要求とを含み要求された情報交換サービスに関連するメッセージを処理するように構成される。バージョニングユニットは、データコンテンツが既にクライアントへ配信されている否かを判定するように構成される。データコンテンツがまだクライアントへ配信されていないことが分かった場合、メッセージは、通信ユニットからクライアントへ変更されずに送信されることになる。しかしながら、データコンテンツが既に第２のエンティティへ配信されていると判定された場合、データ識別子を含むがデータコンテンツを含まない修正されたメッセージが代わりにクライアントへ送信されることになる。

第１の実施形態によれば、第１のエンティティはサーバであり、他方、第２のエンティティはクライアントである。

一態様によれば、通信ユニットはまた、情報交換サービスの要求であってバージョニングが必要とされるということを示す要求を第２のエンティティから受信する受信機も含んでもよい。

更に他の態様によれば、バージョニングユニットは、キャッシュに問い合わせることにより、データコンテンツが既に第１のエンティティへ配信されているか否かを判定するように構成されてもよい。

第２の実施形態によれば、第１のエンティティは代わりにクライアントであり、他方、第２のエンティティはサーバである。

他の態様によれば、情報交換サービスに関連するメッセージを扱う第１のエンティティが提供される。ここで、メッセージは第２のエンティティから受信される。第１のエンティティは、第２のエンティティからメッセージを受信する通信ユニットを備える。ここで、メッセージはバージョニングの要求を含む。エンティティはまた、メッセージがデータコンテンツを含むか否かを判定するバージョニングユニットを備える。バージョニングユニットは、メッセージがデータコンテンツを含む場合、データコンテンツに関連付けられるデータ識別子を取得し、関連付けられるデータ識別子と共にデータコンテンツをキャッシュするように構成される。しかしながら、メッセージがデータコンテンツを含まない場合、バージョニングユニットは、関連付けられるデータ識別子をメッセージから取得した後に、格納されたデータコンテンツをメッセージに与えるように構成される。第１のエンティティはまた、メッセージを処理する処理ユニットを備える。

一実施形態によれば、第１のエンティティはサーバであり、第２のエンティティはクライアントである。

一態様によれば、第１のエンティティの通信ユニットはまた、情報交換サービスの要求であってバージョニングが必要とされるということを示す要求を第２のエンティティへ転送する送信機も含んでもよい。

更に他の態様によれば、バージョニングユニットはキャッシュに接続されている。ここで、バージョニングユニットは、メッセージの配信または受信の成功に応えて、データコンテンツおよび関連するデータ識別子をキャッシュするように構成される。

次に、本発明について、例示的な実施形態を使って、添付の図面を参照しながら詳細に記述しよう。
先行技術によるＳＩＰプレゼンスアーキテクチャの基本的な概要を示す図である。一実施形態による、クライアントとサーバとの間のプレゼンス発行の概略フロー図である。別の実施形態による、クライアントとサーバとの間のプレゼンス発行の概略フロー図である。一実施形態による、サーバとクライアントとの間のプレゼンス通知の概略フロー図である。一実施形態による、プレゼンスデータのキャッシングの概略図である。一実施形態による、最新データコンテンツをサーバに提供するように構成されたクライアントの概略図である。一実施形態による、最新データコンテンツを管理するように構成されたサーバの概略図である。一実施形態による、受信された最新データコンテンツを処理するように構成されたクライアントの概略図である。

典型的には、例えばプレゼンスサービスのようなＩＭＳサービスの場合、すでに以前に同じデータコンテンツを、すなわち、発行や通知のような以前の要求の中で受信した各エンティティに対して、大量のデータが配信される。本書の範囲は、以前に同じ情報がすでに送信エンティティから受信エンティティへ配信されていた場合には、送信エンティティが、データコンテンツ、例えばプレゼンス情報を、送信エンティティから受信エンティティへ送信することを回避できるようにするメカニズムを提供することである。

プレゼンスサービスを管理するプレセンスサーバから送信される多量の通知は、以前に送信された通知と同じプレゼンス情報を搬送しているのだから、どのプレゼンス情報がプレゼンティティにとって現在有効であるかをプレゼンスサーバに指摘することが可能なら、通知サイズは大幅に縮小するであろう。また、プレゼンティティとプレゼンスサーバとの間の通信についても、少なくとも発行のサイズを一部縮小することを目的とした、対応するメカニズムがあれば、望ましいであろう。

上記の諸問題に取り組むメカニズムが、例えばＥｔａｇ、バージョン番号または一意の識別子を搬送するデータ識別子を、例えば通知または発行のようなＳＩＰメッセージに含めることによって達成されてもよい。新たなメッセージが同じサーバまたはクライアントに対して送信されることになる場合であって、そして、ＳＩＰメッセージを介して転送されることになるデータコンテンツが、送信端でキャッシュに問い合わせた後で、以前のＳＩＰメッセージの中で送信されたデータコンテンツと同一であると分かる場合にはいつでも、その新たなメッセージはデータ識別子を含んでいるだけであり、それによって、すでに配信されたデータコンテンツを再度送信することが回避される。これは、送信エンティティが、以前のメッセージの中でそのエンティティから配信されたデータコンテンツを把握すると同時に、それぞれのデータコンテンツに関連するデータ識別子についても把握する必要があることを意味する。

次に、提案するバージョニングメカニズムをもっと明確に理解することを目的として、図２乃至図４を参照しながら図解するプレゼンスサービスを実行するという文脈で、提案するバージョニングメカニズムを例示しよう。図２および図３は、プレゼンティティとして動作していて、サーバ（この場合はプレゼンティティサーバ）に最新の発行を提供しているクライアントと、サーバとの間で、バージョニングがどのように実行されうるかを、２つの別の実施形態によって図解する図である。図４は、１つ以上のクライアントに通知を提供するサーバと、ウォッチャーとして動作していて、サーバから通知を受信するクライアントとの間で実施可能な、対応するバージョニングメカニズムを実現するやり方を図解する図である。

話を簡単にするために、本書内のすべての例は、２つのエンティティ間で、すなわち、クライアントとサーバとの間で（例えばプレゼンティティとプレゼンスサーバとの間で）、あるいは、プレゼンスサーバとウォッチャーとの間で、実行されるバージョニングについて記述することに限定される。しかし、ここで理解されるべきだが、記述するバージョニングメカニズムは、バージョニングがプレゼンティティからプレゼンスサーバおよび着信ウォッチャーまでずっと適用可能であるような、サービスの実行に関与する複数のエンティティ間にも適用可能であってもよい。また、理解されるべきだが、記述するバージョニングメカニズムは、プレゼンスサービス情報の配信だけを処理することに限定されるのではなく、いかなるタイプのサービス情報の配信にも限定されない。特に、記述する実施形態のいずれかによるバージョニングは、冗長なデータコンテンツの送信を減らすために、詳細には、対話しているエンティティ間で送信される必要があるデータコンテンツの量を減らすために必要な他の実装にも適用可能であろう。

図２は、プレゼンスサービスに関連する発行の実行に関係する例示的なシグナリング、すなわち、サーバに発行を提供するプレゼンティティとして動作しているクライアント２００と、プレゼンティティサーバとして動作しているサーバ２０１との間のシグナリングのシナリオを図解する図である。図２を参照しながら記述する実施形態は、既存のＥｔａｇを用いることによってバージョニングを提供する１つのやり方、すなわち、送信されるプレゼンス情報の多様なバージョンを識別する目的でもＥｔａｇを使用するやり方である。

関連のプレゼンス情報、すなわち、サーバ２０１へ配信されることになる、本書でＤ１と識別されるデータコンテンツを有するクライアント２００がバージョニングを有効にしてもよいが、それはそのようなメカニズムが両方のエンティティによってサポートされることを条件とする。発行は、典型的には、発行要求として、すなわち、ＳＩＰＰＵＢＬＩＳＨ要求として提供されるメッセージとして、エンティティ間で配信される。従って発行要求は、通常のデータコンテンツＤ１に加えて、バージョニングについての要求を、例えば「バージョニングが必要」として、含んでもよい。

第１のステップ２：１において、クライアント２００が、発行を処理し、そして、ＳＩＰＰＵＢＬＩＳＨ要求として配信された発行のデータコンテンツＤ１が、以前の要求の中でサーバに送信されたかどうかキャッシュに問い合わせる。しかし、データコンテンツＤ１がサーバ２０１へ送信されることになるのはこれが初めてなので、Ｄ１と同じデータコンテンツは、キャッシュの中には発見できない。従ってＳＩＰＰＵＢＬＩＳＨ要求は、次のステップ２：２でそのままサーバへ送信される。ＳＩＰＰＵＢＬＩＳＨ要求に応じて、次のステップ２：３で、バージョニングをサポートしているサーバは、データコンテンツＤ１を識別するために用いるデータ識別子「ｘ」を生成して割り当て、このデータおよび関連するデータ識別子「ｘ」をキャッシュに記憶するかまたはキャッシュする。一実施形態によると、データ識別子は、既存のＥｔａｇであってもよく、それが、その従来の用途に加えて、記述するバージョニングのために用いられてもよい。ここで、サーバ２０１は、ＳＩＰＰＵＢＬＩＳＨ要求を従来の手順に従って処理することができる。

次に、サーバ２０１は、バージョニングがサポートされて実行されたという指標を含めて、ＳＩＰＰＵＢＬＩＳＨ要求の受信が成功したことを、例えば２００ＯＫのような応答メッセージを生成することによってクライアント２００に示す。応答メッセージは、データ識別子「ｘ」と、例えば「バージョニングが行われた(versioning done)」こととを備え、そして、次のステップ２：４でクライアントへ送信される。クライアントが２００ＯＫ応答メッセージを受信した後、データ識別子「ｘ」は、次のステップ２：５で示すように、データコンテンツＤ１と一緒にキャッシュされる。

その後、本書ではデータコンテンツＤ２と表示するプレゼンス情報を備えた新たなＳＩＰＰＵＢＬＩＳＨ要求が、プレゼンティティによってクライアント２００に提供される。発行は、クライアントによって処理され、キャッシュをチェックすることによって問い合わせが行われ、この場合もまた、データコンテンツＤ２がサーバに対してまだ発行されていないことが、クライアント２００のキャッシュをチェックすることによって判断される。この手順は、次のステップ２：７でサーバ２０１への要求を送信するのに先立って、ステップ２：６で実行される。

その後のステップ２：８において、サーバは、ＳＩＰＰＵＢＬＩＳＨ要求について問い合わせを行い、そして、バージョニングが必要とされていることを検証（確認）し、従って、データコンテンツＤ２に関連するもう１つのデータ識別子「ｙ」がサーバによって取得される。次いでデータ識別子「ｙ」が、関連のデータコンテンツＤ２と一緒にサーバ２０１でキャッシュされ、そして、サーバ２０１はＳＩＰＰＵＢＬＩＳＨ要求を従来のやり方で処理することができる。必要なバージョニングの手順の実行の成功を含めて、データコンテンツＤ２について実行されたＳＩＰＰＵＢＬＩＳＨ要求の受信が完了したことが、ステップ２：９で示すように、２００ＯＫ応答メッセージのかたちでクライアントに対して検証される。次いで、ステップ２：５と類似しているが、データ識別子「ｙ」とデータコンテンツＤ２とが、次のステップ２：１０でクライアント２００によってキャッシュされる。

再度、クライアント２００が、プレゼンティティからプレゼンス情報を受信する。しかし、今度は、挿入されるプレゼンス情報は、すでに送信されたデータコンテンツ、すなわちデータコンテンツＤ１と同一であることが分かる。キャッシュでのチェック手順によって、データコンテンツＤ１がすでにクライアントのキャッシュ内に存在することが明らかになるので、Ｄ１に関連するデータ識別子だけを、すなわち、キャッシュから検索されたデータ識別子「ｘ」だけを含み、データコンテンツを含まないような修正されたＳＩＰＰＵＢＬＩＳＨ要求が、サーバへ送信されるであろう。この手順は、ステップ２：１１で実行され、そして、通常のＳＩＰＰＵＢＬＩＳＨ要求に比べてサイズが縮小されたＳＩＰＰＵＢＬＩＳＨ要求が、次のステップ２：１２でサーバへ送信されるであろう。

次のステップ２：１３で、サーバは、ＳＩＰＰＵＢＬＩＳＨ要求がデータ識別子「ｘ」だけを含むことを認識し、従って、データ識別子「ｘ」とリンクされうるデータコンテンツが記憶されているかどうかを判断するために、キャッシュに問い合わせが行われるであろう。キャッシュ内で見つかれば、データコンテンツＤ１が、従来のやり方でサーバ２０１によって処理される前にＳＩＰＰＵＢＬＩＳＨ要求に追加される。サーバは、ステップ２：１４で示すように、２００ＯＫ応答メッセージをクライアントに送信することによって、クライアント２００に対してバージョニングの成功を検証する。しかし、期待されたデータコンテンツがキャッシュの中に見つからない場合には、サーバ２０１は、代わりに、再送信を要求することによって応答するであろう。そのような再送信は、データ識別子と関連のデータコンテンツとを両方含む、完全なＳＩＰＰＵＢＬＩＳＨ要求であろうし、それは、従来の発行処理のためにプロセッサへ転送される発行の中にデータコンテンツが挿入される前に、受信した時点で適宜キャッシュすることが可能である。

上記のように、一旦プレゼンス情報がサーバ２０１に配信されると、かつ、適用可能である場合にバージョニングの実行が成功すると、検索されたデータコンテンツがさらにサーバ２０１によって処理されることができ、すなわち、データコンテンツが１人以上のウォッチャーに、従来のよく知られているプレゼンスサービス手順にすべて従って、通知として配信されることができる。

バージョニングがいつ必要なのかをサーバ２０１へ送信される要求の中に示すことによって、提案するバージョニングメカニズムが、要求に応じてそれぞれ有効にされたり、無効にされたりしてもよく、それによって、それぞれの情報交換サービスが、バージョニングを無効にして従来のやり方でサービスを実行させ、必要な場合だけに、またはそれよりは持続的に、バージョニングを用いてもよい。あるいは、バージョニングが、例えばプレゼンスサーバとウォッチャーとの間で有効とされ、他方、プレゼンティティとプレゼンスサーバとの間で無効とされてもよく、その逆も同様である。

別の実施形態によって、データ識別子がサーバではなくクライアントですでに生成されることを特徴とする代替のバージョニングメカニズムが導入されてもよい。ここで図３を参照しながら、そのようなメカニズムを示す例示的なシナリオについて記述しよう。

最初に、ステップ３：１で、データコンテンツＤ１が以前にサーバ３０１へ送信されたかどうかを判断することを目的として、プレゼンティティによって開始されてデータコンテンツＤ１として配信される、バージョニングおよびプレゼンスデータを求める要求を含むＳＩＰＰＵＢＬＩＳＨ要求が、処理されて、クライアント３００のキャッシュに対してチェックされる。データコンテンツＤ１がサーバ３０１へ送信されるのはこれが初めてなので、対応するデータコンテンツは、キャッシュの中には見当たらない。結果として、クライアント３００で生成され、クライアント３００によって挿入されたデータ識別子「ｘ」が、ＳＩＰＰＵＢＬＩＳＨ要求に与えられる。次いでＳＩＰＰＵＢＬＩＳＨ要求は、その後のステップ３：２でサーバ３０１へ送信される。

サーバ３０１では、バージョニングが必要であるということが判断され、従って、ＳＩＰＰＵＢＬＩＳＨを受信するのに続いて、データコンテンツＤ１およびデータ識別子「ｘ」がキャッシュされる。これをステップ３：３で示す。ステップ３：４で示すように、２００ＯＫ応答メッセージを使って、受信とバージョニングの成功がクライアントに対して検証される。また、次のステップ３：５で、２００ＯＫ応答メッセージに応じて、クライアント３００のキャッシュ内でデータ識別子「ｘ」と一緒にクライアントがデータコンテンツＤ１をキャッシュする。

ステップ３：６乃至３：１０において、データコンテンツＤ２として配信されるプレゼンスデータの別の設定について、対応する手順が繰り返され、そして、対応するやり方で、データコンテンツＤ２に関連する別のデータ識別子「ｙ」が導出され、Ｄ２と一緒に、ＳＩＰＰＵＢＬＩＳＨ要求の中に挿入される。

別のステップ３：１１において、クライアント３００が、発行するための新たなプレゼンスデータを含む新たなＳＩＰＰＵＢＬＩＳＨ要求を受信して処理する。キャッシュでのチェックによって、データコンテンツＤ１として表される新たなプレゼンスデータは、すでに送信され、キャッシュされたプレゼンスデータのバージョンと、すなわち、ステップ３：２で送信されたデータコンテンツと同一であることが明らかになることから、ＳＩＰＰＵＢＬＩＳＨ要求は修正され、そのデータコンテンツからリクエストが除去されて、データ識別子「ｘ」がリクエストに挿入され、この場合、データ識別子「ｘ」は、受信端で、すなわちサーバ３０１で、データコンテンツＤ１の識別子として用いられるであろう。ここで、限定されたサイズのＳＩＰＰＵＢＬＩＳＨ要求が、次のステップ３：１２でサーバへ送信されるであろう。

サーバ３０１では、データ識別子「ｘ」によって識別されるデータコンテンツが以前にキャッシュされたか否かがチェックされる。これは次のステップ３：１３で行われる。次いで最終ステップ３：１４で、ＳＩＰＰＵＢＬＩＳＨ要求の受信およびバージョニングの成功が、２００ＯＫ応答メッセージを使ってクライアント２００に示される。

前の実施形態に類似しているが、キャッシュ内に関連のプレゼンスデータが見つからなかった場合、結果として、プレゼンスデータと関連のデータ識別子とが両方共ＳＩＰＰＵＢＬＩＳＨ要求の中で送信されるような、発行要求の再送信を求める要求が行われるであろう。ここでプレゼンスデータは、キャッシュから検索されてＳＩＰＰＵＢＬＩＳＨ要求に追加されてもよく、次いで、それを、よく知られている発行処理手順に従って処理するために利用できるであろう。

現在、各プレゼンスサーバは、例えば、ＬｅａｓｔＲｅｃｅｎｔｌｙＵｓｅｄ（ＬＲＵ）アルゴリズムのような、何らかのキャッシングアルゴリズムを備えていて、キャッシュ内に記憶されるデータコンテンツのバージョンの数が所定の限度を超えないことを保証していることがある。ＬＲＵアルゴリズムは、サーバが処理できるバージョン数の最大限度に達しそうになる度に、直近の利用が最も少ないバージョンを把握してそれを削除する。

上記の諸実施形態に加えて、クライアントからサーバへ情報をプッシュすることを補うものとして、記述するバージョニングメカニズムかまたはいずれかの対応するメカニズムが、情報のポーリングにも適用可能であってもよい。

プレゼンスサービスでは典型的には、一定のプレゼンティティまたはプレゼンティティのグループに関連するプレゼンス情報を購読しているウォッチャーに対して、新たな関連する発行されたデータ識別子が、プレゼンスサーバでそれが利用可能になり次第、通知されるであろう。そのような通知は、典型的には、ＳＩＰＮＯＴＩＦＹ要求としてウォッチャーへ転送される。プレゼンスサーバからウォッチャーへ転送される通知を処理する場合にもバージョニングを導入することによって、プレゼンティティからプレゼンスサーバへ配信される発行を処理する場合よりも多くの容量が得られる。

次に、１つの実施形態によって、記述するバージョニングメカニズムを用いて、ウォッチャーとして動作するクライアントが、最新のプレゼンス情報を処理するために、プレゼンティティサーバとして動作するサーバとどのようにして対話しうるかを例示するシナリオについて、図４を参照しながら記述しよう。

特定のプレゼンティティ（図示せず）のプレゼンス情報を購読することを望むクライアント４０１が、第１のステップ４：１で示すようにＳＩＰＳＵＢＳＣＲＩＢＥ要求をサーバ４００に送信することによって、そのような購読を開始することができる。クライアント４０１は、バージョニングをサポートし、かつ、この機能を有効化する（アクティブにする）ことを望むのだから、例えば「バージョニングが必要」のような要求が、ＳＩＰＳＵＢＳＣＲＩＢＥ要求に追加される。また、サーバ４００もバージョニングをサポートしており、次のステップ４：２で２００ＯＫ応答メッセージをクライアント４０１に返信することによって応答する。

バージョニングを含めてプレゼンス情報の購読がサーバ４００によって一旦有効化（アクティブ）にされると、サーバは、それぞれのプレゼンティティのプレゼンスデータに変化が生じた時、クライアント４０１に通知するであろう。別のステップ４：３で、サーバは、クライアントへ配信されるプレゼンスデータを備えたＳＩＰＮＯＴＩＦＹ要求を受信して処理する。一旦サーバが、従来のプレゼンスサービス処理を実行することによって新たなプレゼンスデータを識別すると、データコンテンツ（この場合、発行を介して配信されたもの）に対する問い合わせが行われるであろう。この場合、バージョニングが必要であり、従って、これが、それぞれの通知の中で、例えば「バージョニングが必要」と示される。データコンテンツＤ１に加えて、ＳＩＰＮＯＴＩＦＹ要求も、関連のデータ識別子と共に提供されるが、そのデータ識別子は、前述したように、発行の場合に用いられたものと同じものであってもよいし、あるいは、サーバによって生成され、かつ、サーバでＳＩＰＮＯＴＩＦＹ要求に挿入される新たなデータ識別子であってもよい。発行の配信について述べた諸実施形態に類似しているが、データ識別子が、サーバ４００またはクライアント４０１のいずれか一方において、通知の中に提供されてもよい。この実施形態では、データ識別子は、サーバ４００で通知に提供される。ステップ４：４で、データコンテンツＤ１と関連のデータ識別子「ｘ」とを含むＳＩＰＮＯＴＩＦＹ要求が、クライアントへ送信される。

ＳＩＰＮＯＴＩＦＹ要求を受信すると、クライアント４０１は、次のステップ４：５で示すように、プレゼンスデータＤ１と関連のデータ識別子「ｘ」とをキャッシュする。この段階で、クライアントは、取得されたプレゼンスデータを従来のやり方で処理することができる。

次いでクライアント４０１は、次のステップ４：６で２００ＯＫ応答メッセージをサーバ４００へ送信することによって、バージョニングの成功も含めて、受信の成功を検証する。２００ＯＫ応答メッセージに応じて、サーバ４００は、別のステップ４：７で、データコンテンツＤ１と関連のデータ識別子「ｘ」とをキャッシュする。続きのステップ４：８乃至４：１２で、対応する通知手順が、関連のデータ識別子「ｙ」と一緒にクライアント４０１へ配信されるプレゼンスデータＤ２についても実行される。

別のステップ４：１３で、プレゼンティティからの発行の受信に応じて、新たな通知がサーバ４００で生成される。今回はデータコンテンツＤ１として識別されるプレゼンスデータを備えた新たなＳＩＰＮＯＴＩＦＹ要求が、ここでもやはりサーバ４００で識別される。しかし、今回は、プレゼンスデータの同一バージョンがキャッシュ内で見つかったため、データコンテンツＤ１がサーバ４００からクライアント４０１へすでに配信されたと判断される。結果として、クライアント４０１へ配信されることになるＳＩＰＮＯＴＩＦＹ要求は、データ識別子「ｘ」だけを含んでいて、プレゼンスデータを含まないであろうし、従って、要求には、そのデータコンテンツＤ１から要求を除去して、代わりにデータ識別子「ｘ」を要求の中に挿入するという修正が行われるであろう。次いで、減少されたサイズの通知が、次のステップ４：１４でクライアントへ送信される。

クライアント４０１は、バージョンのみを備えたＳＩＰＮＯＴＩＦＹ要求を受信すると、データ識別子「ｘ」に関連するプレゼンスデータが本当に前の段階でキャッシュされたのかどうか判断することを目的として、キャッシュに問い合わせる。これはステップ４：５で行われたのだから、それぞれのプレゼンスデータ、すなわちデータコンテンツＤ１が、キャッシュから検索されて通知に追加される。これを、ステップ４：１５に示す。クライアント４０１は、次のステップ４：１６で２００ＯＫ応答メッセージをサーバ４００に送信して、バージョニングの成功を検証し、そしてここで、クライアント４０１は、記憶されたデータコンテンツＤ１を従来のやり方で処理することができる。

あるいは、データ識別子がサーバの代わりにクライアントでＳＩＰＮＯＴＩＦＹに提供されることを特徴とする、図２を参照しながら述べたのに対応する手順が、適用可能であってもよい。そのようなメカニズムは、例えばＥｔａｇを用いることに依存してもよい。

それに代わる実施形態では、クライアントが、サーバから最新の情報を受信すると、自分がどのくらいの数のデータコンテンツのバージョンを処理できるかをサーバに示してもよい。この情報は、要求に対する最初の応答メッセージの中でサーバ４００に提供することができる。あるいは、サーバによって送信される各応答メッセージが、クライアントがあとどの位の数のバージョンを処理できるかに関する指標を含んでもよい。データコンテンツのバージョンの数を制御するこれら２つの選択肢のいずれも、同時にクライアントによって処理され、キャッシュの中に記憶されるのだが、それらは、ＬＲＵアルゴリズムの補完として、あるいは代替として、実装され用いられてもよい。

従って、特定のデータ識別子を示すのに実際にどの値が選択されるかは、必ずしも重要ではない。例えば、サーバは、多様なクライアントに通知する時、同じ値を選択してもよく、その場合、データ識別子は、クライアントについて一意であれば、いかなるストリング（文字列）であってもよく、例えば、含まれるデータのハッシュ値であるか、または単純にサーバとクライアントとによって保持されるデータ識別子でもよいだろう。

提案するバージョニングメカニズムでは、要求の通信に関与する諸エンティティが、どのデータコンテンツ、例えばプレゼンスデータが、どのエンティティに送信されたかを把握することが必要である。

上記のように、これは、データコンテンツと関連のデータ識別子とを、送信エンティティと受信エンティティとの両方でキャッシングすることによって達成されてもよい。

図５は、一実施形態によって、そのようなキャッシングメカニズムが、どのようにして系統化されうるかを略示する図である。図は、１人のプレゼンティティ５００と２人のウォッチャー５０１、５０２についてキャッシングがどのようにして構成されうるかを図解する図であり、それらはすべて、上記の実施形態のいずれかによるバージョニングを有効にするように構成される。クライアント５００乃至５０２は、これもバージョニングを有効にするように構成されたプレゼンスサーバ５０３からの多様な情報交換サービスにアクセスしてもよい。ここで理解されるべきだが、図では、簡略化するために、それぞれのエンティティでの関連サービスの実行に必要な追加の機能性は省略されている。

プレゼンティティ５００は、プレゼンティティ５００によってサーバ５０３へ無事に送信されたデータコンテンツおよび関連のデータ識別子をキャッシングするためのキャッシュ５０４を備える。発行をサーバ５０３へ送信する時にキャッシングのために用いられるサブセクションを、５０５で表す。ウォッチャー５０１および５０２では、キャッシュ５０５および５０６のサブセクションを、それぞれ５０７、５０８で表す。サーバ５０３から通信を受信するウォッチャーが、受信したプレゼンスデータをそれぞれのデータ識別子と一緒にキャッシュして、データ識別子だけを含んでいる通知が受信された時には、それぞれのデータコンテンツを検索することを目的として、キャッシュに問い合わせを行う。サーバは、着信する要求をキャッシュするための、すなわち、クライアントから受信したプレゼンスデータコンテンツおよび発行に関連するデータ識別子をキャッシュするための、１つのキャッシュ５０９を備える。またサーバは、発信する要求をキャッシュするための、すなわち、着信クライアントへ送信されたプレゼンスデータコンテンツおよび発行に関連するデータ識別子をキャッシュするための、１つのキャッシュ５１０を備える。キャッシュ５０９のサブセクション５１１を用いて、プレゼンティティ５００から受信する情報が記憶され、他方、キャッシュ５１０は、対応するサブセクション５１２および５１３を有し、ここに、ウォッチャー５０１および５０２に関連するプレゼンスデータとデータ識別子とが、それぞれ記憶される。

次に、サーバおよびクライアントにおける記述する実施形態のいずれかによるバージョニングメカニズムを実行するための機能性を記述する例示的な実施形態について、図６乃至８を参照しながら記述しよう。ここで理解されるべきだが、以下のセクションで記述される構成は、純粋に論理的であり、そして、関連の機能性をノードで提供する記述されたユニットは、別の代替のやり方で実装することができる。加えて理解されるべきだが、簡略化するために、提案するバージョニング機能の実装の背後にあるメカニズムの理解に必要でない機能性は省略されている。

図６は、一実施形態によるクライアント６００、例えばプレゼンティティ、を描いているが、これはサーバ（図示せず）、例えばプレゼンスサーバに対してデータコンテンツ、例えばプレゼンス情報を配信するように構成される。クライアント６００は、従来の処理ユニット６０１を、典型的には追加の処理ユニットと共に備えていて、要求された情報交換サービスに関連する要求を処理するように構成される。

バージョニングが必要でありうる要求が従来の通信ユニット６０２を介して関連のサーバへ転送される前に、バージョニングユニット６０３によって要求への問い合わせが行われ、他方、バージョニングが不要な要求は、周知の手順によって処理されるであろう（すなわち、通信ユニット６０２へ直接転送され、次いで通信ユニット６０２が、要求をそれぞれのサーバへ従来のやり方で転送する）。バージョニングユニット６０３は、キャッシュ６０４に接続され、そこでデータコンテンツの完全バージョンと関連のデータ識別子とが、データコンテンツがサーバへ送信されて始めて、記憶される。一実施形態では、バージョニングユニットはまた、それぞれのデータコンテンツと関連することになるデータ識別子を提供するようにも構成される。代わりにサーバによってデータ識別子が提供される別の実施形態では、バージョニングユニットは、バージョニング手順実行の成功を含めて要求の受信の成功を検証する応答メッセージ、すなわち２００ＯＫ応答を受信するのに応じて、データコンテンツをキャッシュするように構成される。

サーバでのバージョニングを有効にするためには、サーバも適宜構成される必要がある。従って、次に、図７を参照しながら、サーバ、例えば上記の実施形態のいずれかによってバージョニングを提供するように構成されたプレゼンスサーバについて提示しよう。

図７のサーバ７００は、例えばプレゼンティティのようなクライアント（図示せず）と通信するための少なくとも１つの従来の通信ユニット７０１を備えており、例えば発行のようなメッセージとして転送される要求を介してサービス関連のデータコンテンツをサーバに提供する。また、サーバはウォッチャーと通信するように構成され、ウォッチャーは、別のタイプのメッセージ、例えば通知が、所定の規則および制約に従って、サーバから配信されることを予期してもよい。通信ユニット７０１は、クライアントから受信したメッセージ、例えば発行を、バージョニングユニット７０２に転送するように構成される。メッセージの中でバージョニングが要求されなかった場合、メッセージは従来の処理ユニット７０３に直接転送され、そこで、従来のやり方で処理されてもよい。発行を受信するのに応じて、１つ以上の通知が、サーバ７００に管理される関連の購読にすべて従って例えば生成されてもよい。バージョニングがサーバ７００によってサポートされる場合、バージョニングを求める要求を含むけれどもデータ識別子は含まない受信メッセージは、データ識別子を与えられるであろうし、それはメッセージに追加されて開始側のクライアントへ転送される。

データ識別子が代わりにクライアントで提供される場合、バージョニングを求める要求とデータ識別子とを関連のデータコンテンツと一緒に含むメッセージが、代わりにバージョニングユニット７０２によって識別されるであろう。次いで、メッセージを処理ユニット７０３で処理して関連のメッセージ（例えば通知）を通信ユニット７０１へ配信するのに先立って、データコンテンツとデータ識別子とが、サーバの受信側専用の第１のキャッシュ７０４でキャッシュされる。バージョニングが必要であってデータ識別子が存在するが関連のデータが存在しない場合、すなわち、このデータコンテンツが以前にサーバに配信されていた場合、バージョニングユニット７０２は、代わりに、データ識別子に関連するデータコンテンツが実際に第１のキャッシュ７０４に記憶されているかどうか判断するために第１のキャッシュ７０４に問い合わせるように構成される。

例えば通知としてサーバからクライアントへ配信されることになるメッセージが、処理ユニット７０３からバージョニングユニット７０２に提供される。バージョニングを求める要求と、データ識別子と関連のデータコンテンツとを含んでいるメッセージは、バージョニングユニット７０２によってチェックされるであろうが、バージョニングユニット７０２は、サーバ７００の送信端専用の第２のキャッシュ７０５に問い合わせを行っている。各々のデータ識別子によって連結されるデータコンテンツが、第２のキャッシュ７０５の中で発見された場合、これは、現在のデータコンテンツが以前に各々のクライアントへ送信されたということを意味する。次いでバージョニングユニットが、メッセージのサイズを制限することを目的として、データコンテンツを除去することによってメッセージを修正する。しかし対応するデータコンテンツが、第２のキャッシュ７０５の中で発見できなかった場合、データコンテンツがクライアントへ送信されることになるのはこれが初めてであると判断され、従って、メッセージは、そのままで維持され、着信クライアントへ送信される時には、データコンテンツとバージョンとを両方搬送する。

次いで、データコンテンツと対応するデータ識別子とが、通信ユニット７０１へ転送され、そこから通知がそれぞれのクライアントへ送信され、そして、メッセージの受信およびバージョニングの成功を示す２００ＯＫ応答メッセージをクライアントから受信するのに応じて、データコンテンツと関連のデータ識別子とが、キャッシュ７０５でキャッシュされる。

前のステップ（すなわち発行の間）において、発行のバージョニングが必要であるのにバージョニングが実行されていないことをバージョニングユニットが発見した場合、あるいは、別のバージョニング手順が別のサーバ端で実行されることになっている場合、バージョニングユニットは、メッセージをクライアントに配信する前にメッセージにデータ識別子を与えるように構成される。データ識別子を搬送するがデータコンテンツは搬送していないメッセージに対して着信クライアントが否定応答で応答する場合、バージョニングユニット７０２は、新たなデータ識別子と、キャッシュ７０５から検索された関連のデータコンテンツとをどちらも備えた新たなメッセージを生成するように構成される。次いで、バージョニングユニット７０２は、新たなメッセージを、クライアントに送信するために通信ユニット７０１に転送する。

受信されたメッセージ、例えばサーバからの通知についてのバージョニングを有効にするように構成された、例えばウォッチャーのようなクライアントについては、すでに述べた。今度は、そのような修正されたクライアントについて、図８を参照しながら記述しよう。上述したもののようなサーバ（図示せず）によって配信されたメッセージが、クライアント８００の通信ユニット８０１によって受信され、バージョニングユニット８０２によって問い合わせが行われる。バージョニングを求める要求を含むけれどもデータ識別子は含まないメッセージを受信すると、バージョニングユニット８０２は、例えばＥｔａｇのようなデータ識別子を提供するように構成され、次いでデータ識別子は、関連するデータコンテンツと一緒にキャッシュ８０３でキャッシュされる。また、バージョニングユニット８０２は、データ識別子を含む応答メッセージをサーバに提供するように構成される。

しかし、メッセージがデータ識別子を含むけれどもデータコンテンツを含まない場合、バージョニングユニット８０２は、代わりに、それぞれのデータ識別子と一緒に記憶されたデータコンテンツについてキャッシュ８０３をチェックして、メッセージを従来通り処理する目的でメッセージが処理ユニット８０４へ転送される前に、メッセージにそれぞれの識別されたデータコンテンツを与えるように構成される。データ識別子と関連するデータコンテンツとを含むメッセージが、バージョニングユニット８０２によって適宜処理され、そして、データ識別子と関連するデータコンテンツとが、メッセージの受信およびバージョニングの成功に応じてキャッシュ８０３に記憶される。配信されたコンテンツがキャッシュされると、メッセージは処理ユニット８０４へ転送され、データコンテンツが処理される。

上記の実施形態のいずれかによるデータ処理に関与するノードが、標準の機能性に対する代替案として（すなわち、環境に応じて必要になった場合に）、または、標準の送信機能性と並行して、記述するバージョニングメカニズムのいずれか、または対応する解決策を用いるように構成されてもよい。

本発明について、特定の例示的な実施形態を参照しながら記述してきたが、本記述は一般に、発明の概念を例証することだけを意図しており、本発明の範囲を限定していると解釈されるべきではなく、本発明の範囲は、添付の請求項によって定義される。

Claims

第１のエンティティ（２００，３００，４００）と第２のエンティティ（２０１，３０１，４０１）との間の情報交換サービスに関連するメッセージを通信ネットワークにおいて配信する方法であって、
前記方法は、前記第１のエンティティが、情報交換サービスに関連するメッセージを処理するステップ（２：１，３：１，４：３）を備え、当該メッセージはデータコンテンツとバージョニングの要求とを含み、バージョニングはメッセージのデータコンテンツの各バージョンに対して当該バージョンを識別するデータ識別子を関連付けることを含み、
前記方法は、
前記第１のエンティティが、前記データコンテンツが前記第２のエンティティへ既に配信されているか否かを判定するステップと、
前記データコンテンツが前記第２のエンティティへまだ配信されていない場合に、前記第１のエンティティが、前記メッセージを変更せずに前記第２のエンティティへ送信するステップ（２：２，３：２，４：４）と、
前記データコンテンツが前記第２のエンティティへ既に配信されている場合に、前記第１のエンティティが、データ識別子を含むがデータコンテンツを含まない修正されたメッセージを前記第２のエンティティへ送信するステップ（２：１２，３：１２，４：１４）と、
を備えることを特徴とする方法。
前記第１のエンティティはサーバであり、前記第２のエンティティはクライアントである
ことを特徴とする請求項１に記載の方法。
前記メッセージはＳＩＰ通知である
ことを特徴とする請求項２に記載の方法。
前記処理するステップに先立って、情報交換サービスの要求であってバージョニングが必要とされるということを示す要求を前記第２のエンティティから受信するステップ（４：１）
を更に備えることを特徴とする請求項３に記載の方法。
前記第１のエンティティはクライアントであり、前記第２のエンティティはサーバである
ことを特徴とする請求項１に記載の方法。
前記メッセージはＳＩＰ発行である
ことを特徴とする請求項５に記載の方法。
前記判定するステップは、キャッシュに問い合わせるステップを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
前記第１のエンティティにおいて前記データ識別子が前記メッセージに挿入される
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
前記データ識別子が前記第２のエンティティから提供される
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
前記データ識別子が、前記メッセージの配信の成功を示す応答メッセージの中で前記第１のエンティティへ提供される
ことを特徴とする請求項９に記載の方法。
情報交換サービスに関連するメッセージを第１のエンティティ（２０１，３０１，４０１）において扱う、通信ネットワークにおける方法であって、
前記メッセージは第２のエンティティ（２００，３００，４００）から前記第１のエンティティへ配信され、
前記方法は、要求された情報交換サービスに関連するメッセージを受信するステップ（２：２，３：２，４：４）を備え、当該メッセージはバージョニングの要求を含み、バージョニングはメッセージのデータコンテンツの各バージョンに対して当該バージョンを識別するデータ識別子を関連付けることを含み、
前記方法は、
前記メッセージがデータコンテンツを含むか否かを判定するステップ（２：３，３：３，４：５）と、
前記メッセージがデータコンテンツを含む場合に、前記データコンテンツに関連付けられるデータ識別子を取得し、当該データ識別子と共に当該データコンテンツを格納するステップと、
前記メッセージがデータコンテンツを含まない場合に、当該メッセージから取得されたデータ識別子に関連付けられて格納されているデータコンテンツを当該メッセージに与るステップと、
前記メッセージを処理するステップと、
を備えることを特徴とする方法。
前記第１のエンティティはクライアントであり、前記第２のエンティティはサーバである
ことを特徴とする請求項１１に記載の方法。
前記メッセージはＳＩＰ通知である
ことを特徴とする請求項１２に記載の方法。
前記受信するステップに先立って、情報交換サービスの要求であってバージョニングが必要とされるということを示す要求を前記第２のエンティティへ転送するステップ（４：１）
を更に備えることを特徴とする請求項１３に記載の方法。
前記第１のエンティティはサーバであり、前記第２のエンティティはクライアントである
ことを特徴とする請求項１１に記載の方法。
前記メッセージはＳＩＰ発行である
ことを特徴とする請求項１５に記載の方法。
前記取得するステップは、前記第１のエンティティから前記データ識別子を取得するステップを含む
ことを特徴とする請求項１１乃至１６のいずれか１項に記載の方法。
前記データ識別子が、前記メッセージの配信の成功を示す応答メッセージ（２：４）の中で前記第１のエンティティから前記第２のエンティティへ転送される
ことを特徴とする請求項１７に記載の方法。
前記取得するステップは、前記第２のエンティティにおいて前記メッセージに挿入された前記データ識別子を当該メッセージから取得するステップを含む
ことを特徴とする請求項１１乃至１６のいずれか１項に記載の方法。
前記メッセージの前記第２のエンティティへの配信が成功し前記メッセージが前記第２のエンティティのキャッシュに格納された（２：３）ということを確認する応答メッセージの受信に引き続いて、前記データコンテンツと前記関連付けられるデータ識別子とがキャッシュに格納される（２：５）
ことを特徴とする請求項１乃至１９のいずれか１項に記載の方法。
最初の応答メッセージが、前記第２のエンティティの前記キャッシュの全容量の指標を含む
ことを特徴とする請求項２０に記載の方法。
各応答メッセージが、前記第２のエンティティの前記キャッシュの残り容量の指標を含む
ことを特徴とする請求項２０に記載の方法。
前記データ識別子は、バージョン番号または一意のＩＤである
ことを特徴とする請求項１乃至２２のいずれか１項に記載の方法。
前記データ識別子は、Ｅｔａｇである
ことを特徴とする請求項１乃至２２のいずれか１項に記載の方法。
情報交換サービスに関連するメッセージを第２のエンティティへ配信する第１のエンティティ（６００，７００）であって、
要求された情報交換サービスに関連するメッセージを処理する処理ユニット（６０１，７０３）を備え、当該メッセージはデータコンテンツとバージョニングの要求とを含み、バージョニングはメッセージのデータコンテンツの各バージョンに対して当該バージョンを識別するデータ識別子を関連付けることを含み、
前記第１のエンティティは、
前記データコンテンツが前記第２のエンティティへ既に配信されているか否かを判定するバージョニングユニット（６０３，７０２）と、
前記データコンテンツが前記第２のエンティティへまだ配信されていない場合に、前記メッセージを変更せずに前記第２のエンティティへ送信し、前記データコンテンツが前記第２のエンティティへ既に配信されている場合に、データ識別子を含むがデータコンテンツを含まない修正されたメッセージを前記第２のエンティティへ送信する通信ユニット（６０２，７０１）と、
を備えることを特徴とする第１のエンティティ。
前記第１のエンティティはサーバであり、前記第２のエンティティはクライアントである
ことを特徴とする請求項２５に記載の第１のエンティティ。
情報交換サービスの要求であってバージョニングが必要とされるということを示す要求を前記第２のエンティティから受信する受信機
を更に備えることを特徴とする請求項２６に記載の第１のエンティティ。
前記バージョニングユニットは、前記データコンテンツが前記第２のエンティティへ既に配信されているか否かを判定するためにキャッシュ（６０４，７０４）に問い合わせるように構成される
ことを特徴とする請求項２６または２７に記載の第１のエンティティ。
前記第１のエンティティはクライアントであり、前記第２のエンティティはサーバである
ことを特徴とする請求項２５に記載の第１のエンティティ。
情報交換サービスに関連するメッセージを扱う第１のエンティティ（７００，８００）であって、
前記メッセージは第２のエンティティから受信され、
前記第１のエンティティは、前記第２のエンティティからメッセージを受信する通信ユニット（７０１，８０１）を備え、当該メッセージはバージョニングの要求を含み、バージョニングはメッセージのデータコンテンツの各バージョンに対して当該バージョンを識別するデータ識別子を関連付けることを含み、
前記第１のエンティティは、前記メッセージがデータコンテンツを含むか否かを判定するバージョニングユニット（７０２，８０２）を備え、
前記バージョニングユニットは、前記メッセージがデータコンテンツを含む場合に、前記データコンテンツに関連付けられるデータ識別子を取得して当該データ識別子と共に当該データコンテンツをキャッシュし、前記メッセージがデータコンテンツを含まない場合に、前記メッセージからデータ識別子を取得した後に当該データ識別子に関連付けられて格納されているデータコンテンツを前記メッセージに与えるように構成され、
前記第１のエンティティは、前記メッセージを処理する処理ユニット（７０３，８０４）を備える
ことを特徴とする第１のエンティティ。
前記バージョニングユニットはキャッシュ（７０５，８０３）に接続されており、
前記バージョニングユニットは、メッセージの配信または受信の成功に応えて、データコンテンツおよび関連するデータ識別子をキャッシュするように構成される
ことを特徴とする請求項３０に記載の第１のエンティティ。
前記第１のエンティティはサーバであり、前記第２のエンティティはクライアントである
ことを特徴とする請求項３０または３１に記載の第１のエンティティ。
前記第１のエンティティはクライアントであり、前記第２のエンティティはサーバである
ことを特徴とする請求項３０または３１に記載の第１のエンティティ。