JP4815480B2 - 通信システム - Google Patents

Description

本発明は通信システムに関し、より詳細には通信システムにおけるプレゼンスサービスの提供に関する。

今日、多様な通信システムが用いられ、ユーザ装置又は/及びシステムと結びついている他のノードのような、2つもしくはそれ以上のエンティティ間の通信を可能としている。

ユーザ端末または他のノードのために無線通信を証明している通信システムは既知である。無線システムの1つの例は公衆陸上移動通信ネットワーク（PLMN）である。PLMNは、一般的に、無線基地局（BTS）または類似したアクセスエンティティが、無線インターフェースによって移動局（MS）のようなユーザ装置（UE）のために働くセルラネットワークである。通常、通信のために必要な装置の動作は、互いに接続しているであろう1つ以上の制御エンティティによって制御される。PLMNを他のネットワークに接続するために、1つ以上のゲートウェイノードが用意される。そのような他のネットワークの例は、他のセルラネットワーク、公衆交換電話網（PSTN）やIP（インターネットプロトコル）ベースのネットワークのようなパケット交換データネットワークである。ユーザ装置と通信システムの他の要素との間の通信は、適当な通信プロトコルに基づいており、それは通信がシステムで取り扱われる間の「規則」を定めている。

現在の第三世代（3G）無線システムでは、モバイルユーザのための色々な通信サービスを処理する様々なサーバが定義されている。これらはCSCFとして知られている通話状態制御機能を提供するサーバを含んでいる。制御機能は、加入者管理サーバ（Home Subscriber Server， HSS）や様々なアプリケーションサーバによるアプリケーションなどのエンティティによって提供される場合がある。一般的に、HSSはユーザのプロファイルを恒久的に格納しており、認証の際に用いられる。例えば、第3世代パートナーシッププロジェクト（3GPP）によって策定された3Gアーキテクチャの第5版では、これらのエンティティは、IPマルチメディアサブシステム（IMS）に位置していることが見出される。

IMSネットワークは、従来の音声電話通信とマルチメディアサービスの両方に対応するIPベースのネットワークをサポートする、3Gアーキテクチャのハブに位置するかもしれない。3GPPは、セッション開始プロトコル（Session Initiation Protocol， SIP）を、3Gネットワークの中心的なセッション・シグナリングプロトコルとして選択した。SIPはインターネット・エンジニアリング・タスク・フォース（IETF）によって開発された。関心がある者は、SIPの視点からのIMSネットワークの基本的な動作が記述されている3GPP仕様書24.229（題名は"IP Multimedia Call Control Protocol based on SIP and SDP"）を、http://www.3gpp.org/ftp/Specs/Latest-drafts/24229-201.zipから見つけることができる。SIPは、発信地から送られる全てのメッセージについて、到達地から送信メッセージの受信を確認する関連応答があるという意味で、リクエスト/レスポンス型のプロトコルである。（承認ACKメッセージは、レスポンスが送られない特別の場合である。）

例えば、3Gのネットワークでは、ユーザが最初に彼の携帯端末のスイッチを入れるとき、彼は端末を完全に接続させる前に彼のユーザIDまたはアドレスをネットワークに登録しなければならない。これは端末からIMSまで、ユーザアドレスの詳細が含まれるSIP"REGISTER"メッセージを送ることによってなされる。IMSはこの情報を受信し、そしてこの文脈において"登録"と言い表されるサービング通話状態制御機能（S-CSCF）を用いてこの情報を処理する。REGISTERメッセージは、例えば、sip： mikko.lonnfors＠sonera.comというエイリアスを端末のIPアドレスにマッピングするなど、ユーザのエイリアスと連絡先アドレスとの間のマッピングを提供するためだけに用いられる。IMSは、SIPに従って適当な承認メッセージ（例えば"200 OK"メッセージ）を送ることにより、登録を承認する。以前の登録が終了したか終了しそうなとき、あるいは、ユーザの状態に変化がありそうなときは、いつでも次の登録が行なわれる（re-REGISTER）。
ユーザがもう一人のユーザと、音声通話やメッセージングセッションなどの新たなセッションを開始したいと望むとき、セッションネゴシエーションはSIPの下で遂行される。（メッセージ、すなわちSIP MESSAGEを送る別の方法があり、その場合はセッションの確立は必要とされない。）

アプリケーションサーバ（AS）は、IMSを通じてインスタントメッセージングやプレゼンス、ローカル交通情報、会議施設などのサービスを提供することができる。ASは、IMSネットワークの中に、またはその外にあるかもしれない。一般的に、サポートされるサービスが第三者によって提供されるとき、ASは外部にある。

状態情報の1つの特定の例は、プレゼンス情報である。プレゼンスサービスに加入しているユーザまたはアプリケーションサーバは、他のユーザの機能や対応可能性を判断することができる。（他のプレゼンス特徴や属性の中でも、例えば呼び出しに応答できるかなどであり、これは機器やサービスプロバイダに依存する。）しかしながら、SIPをサポートしているシステムでは、プレゼンスは様々な形を呈することができ、例えば「オフィスにいて全ての電話に対応可能」「家にいるので私用電話のみ対応」「電話中（又は少なくともそのように表示）」などであることができる。従ってプレゼンス情報は、ユーザが他のユーザに電話をかけようとする前に、そのユーザが対応しうるか否かを確かめることを可能にする。プレゼンスサービスは単に対応可能/不可能のような情報以上のものを提供することができる。それは視覚的、アニメ、音の要素を含むことができ、またゲームセッションに関連することなど、様々な事項を記述することができる。

このプレゼンスサービスは、OMA 8（オープンモバイルアライアンス（www.openmobilealliance.org））、3GPP及びIETFで標準化されつつあり、ますます注目を集めている。将来、プレゼンスに対応したアプリケーションの数が増加することが予想されている。アプリケーションの数が増えるにつれ、それはプレゼンス情報の量も増やす。受信端末の視点からは、情報の増加はプレゼンス情報をどのように取り扱うかという問題を投げかける。例えば、プレゼンス情報のどの部分がどのアプリケーションにとって重要なのか、などの問題である。端末は1つ又はそれ以上のアプリケーションを走らせているかもしれない。例えば、端末は動的な電話帳アプリケーションとゲームアプリケーションを走らせることができる。

現在のIETFと3GPPのモデルでは、タプル構造が使われている。タプルは"ランダムな"TUPLE IDを持ち、それは何の意味をも持っておらず、例えばそれはタプルの目的を記述するために用いることはできない。各々のタプルでは、いくつかの属性があることができる。さらに、別々のタプルが、同じ名前を持つ属性であるが、送信又は受信アプリケーションに応じて異なって使われたり解釈されたりするように意図される属性を有することもある。例えば、プレゼンス情報は2つのタプル（1つはゲームのため、もう1つは動的な電話帳（DPB）のため）を含むことができ、これら各々のタプルは状態フィールドを含むことができる。動的な電話帳は、応答可能、不明、応答不能、という状態値を認識するようにデザインされ、ゲームは、発射、死、一時停止、負け、という状態値を認識するようにデザインされることができる。この例から分かるように、状態フィールドが正しい意味を持つことになっているならば、状態フィールドは適切なアプリケーションに届けられなければならない。これは、端末が2つ以上のアプリケーションを備えているときに問題となる。また、受信端末が1つのアプリケーションしか備えていなくとも、送信端末や情報を提供する側（プレゼンティティ、Presentity）が複数である場合に問題となる。上記の例におけるデータが、例えばDPBしか備えていない端末に送られたとしたら、受信端末はどちらのタプルがDPBアプリケーションに使われるためのものなのかを判断することができなくてはならない。

現在のところ、各々のアプリケーションが個々のタプルをチェックしてその状態値がそのアプリケーションにとって意味を持つかを調べる以外、情報を正しいアプリケーションに渡すためのメカニズムはない。言い換えると、試行錯誤アプローチが採用されている。しかしながら、これは情報の正しさに関して不確実性をもたらす。なぜなら、ある場合には、ある属性について値が同じだったとしても、間違ったアプリケーションによって誤って解釈されるかもしれないからである。この1つの例は次の通りである。送信端末はDPBとIM（インスタントメッセージング）アプリケーションを備えている。送信端末は、DPBを「終了」に、IMを「開始」になるように状態値をセットする。この例では、両方のアプリケーションが状態値として「開始」と「終了」だけを使うだろう。ここでもし受信端末がIMアプリケーションしか備えておらず、そしてDPBとIMの状態値を受信したらどうどうなるだろう。受信端末が最初の状態値であるDPBでやってみようとすれば、受信端末はそれを理解し、IMアプリケーションを通じて、プレゼンティティ（情報を発信する側、Presentity）の端末は終了したとユーザに表示するだろう。実はそれが開始したにも関わらず。

ユーザが他の1つのユーザプレゼンス情報を得たいと欲するところで、そのユーザはプレゼンスサーバからデータ（つまりプレゼンス情報）を減らすためにフィルタを含めることができると提唱された。これらのフィルタはそのユーザが興味のある部分だけを含むようにプレゼンスサーバからデータを減らすことができる。

タプル識別子がプレゼンス情報を要求する側（ウオッチャー、Watcher）によってフィルタリングの基準として用いられるというアプローチも、承認がタプル識別子に基づくというアプローチにも、両方とも多くの不都合がある。例えば、プレゼンス情報を要求されている側のユーザが4つのタプル（T1、T2、T3、T4）を有し、あるウオッチャーはT2とT3にしか興味がないとする。するとそのウオッチャーは、タプルT2とT3のみ彼に通知されるようなフィルタをセットする。プレゼンス情報を要求されている側のユーザは、何かの理由で、全てのタプルに関心を持つ特定のウオッチャーに異なる値を提示することを始めるかもしれない。そこでプレゼンス情報を要求されている側のユーザは、新しいタプルT5、T6、T7、T8を作り、新しいアクセスリストを作る。そのアクセスリストはウオッチャーがタプルT5-T8を見ることを許可するが、タプルT1-T4を見ることは許可しない。しかし先程のウオッチャーはタプル識別子に基づいてフィルタをセットしており、それはタプルが彼に提供されないことを意味する。これは不都合である。

フィルタリングでタプル識別子を用いることのもう1つの不都合は次のようなことである。通常、プレゼンティティは、特定のウオッチャーが他のウオッチャーと同じ程度に詳細な情報を得ることを許されていないということを、ウオッチャーに知って欲しくない。また、異なるウオッチャーグループに与えられる情報が、他のウオッチャーグループに与えられる情報と、少し又は全く異なるということも知って欲しくない。

詳細の程度が異なる情報がウオッチャーに提供されることから、フィルタのセッティングがウオッチャーの承認情報が変わる度に変わるというのは不都合である。これは、フィルタリングが一意のタプル識別子に基づく場合に問題となるだろう。
3GPP仕様書24.229（IP Multimedia Call Control Protocol based on SIP and SDP）、http://www.3gpp.org/ftp/Specs/Latest-drafts/24229-201.zip

本発明の実施態様は、上記の1又はいくつかの問題を克服しようとするものである。本発明の第1の側面によれば、プレゼンス情報が結びついている少なくとも1つのユーザを備え、前記プレゼンス情報は複数の部分を有し、少なくとも1つの前記複数の部分は前記少なくとも1つの部分が用いられるアプリケーションを識別する情報を有する通信システムが提供される。

本発明の第2の側面によれば、通信システムであって、関連するユーザのためのプレゼンス情報を提供するステップであって、前記プレゼンス情報は複数の部分を有し、少なくとも1つの前記複数の部分は前記少なくとも1つの部分が用いられるアプリケーションを識別する情報を有するステップと、少なくとも1つのエンティティが前記複数の部分の少なくとも1つを取得するステップであって、前記少なくとも1つのエンティティは少なくとも1つのエンティティアプリケーションを有し、該少なくとも1つのエンティティは、前記少なくとも1つのエンティティアプリケーションを識別する情報を有する該複数の部分を取得するステップとを備える通信方法が提供される。

本発明の第3の側面によれば、通信システムのユーザであって、前記ユーザは関連するプレゼンス情報を有し、前記プレゼンス情報は複数の部分を有し、前記ユーザは前記少なくとも1つの部分が用いられるアプリケーションを識別する情報を含む少なくとも1つの前記複数の部分を提供するように構成される、ユーザが提供される。

本発明の第4の側面によれば、通信システムのエンティティであって、ユーザに関連するプレゼンス情報の少なくとも1つの部分を取得するための少なくとも1つのアプリケーション取得手段を備え、該少なくとも1つの部分はアプリケーションを識別する情報を有し、該取得手段は前記少なくとも1つのアプリケーションを識別する情報を備える該少なくとも部分を取得するように構成される、エンティティが提供される。

本発明の実施例で可能な非常に静的なフィルタリング設定は、フィルタが特定のサーバの中（例えばプレゼンスリストケースの中）に格納されている場合や、予めそのような場合に特に有効である。

本発明の実施例は、異なるウオッチャーが利用可能な情報には異なるレベルの情報（又は全く違った情報）があるという事実をウオッチャーから隠すことができる。

本発明の実施例は、フィルタリング設定やいくつかの他の機能性に影響を与えることなく承認を変えることを可能とする。それらはプレゼンス情報要素により多くの意味的なものを与えることにより、承認から切り離されうる。

本発明の実施例は、"意味を持たない"識別情報についての要求に基礎を置く代わりに、意味的に理解しうる情報を要求する可能性をウオッチャーに与えることができる。

本発明や、本発明がどのように実施されうるのかを理解するために、単なる例示であるが添付図面が参照される。

まず始めに図1を参照する。図1は、UMTS（欧州での第3世代移動通信システムの呼称、Universal Mobile Telecommunications System）の下で動作する典型的な第3世代（3G）無線通信システムである。このシステムのハブはIPマルチメディアサブシステム（IMS）ネットワーク100であり、2つやそれ以上のユーザ間の（又はユーザとアプリケーションサーバ等のネットワーク要素との間の）通話や全ての種類のセッションをルーティングする。ユーザの例として、携帯端末111，ラップトップ112，パーソナルデスクトップアシスタント113，公衆交換電話網（PSTN）電話131，コンピュータ端末123，アプリケーションサーバ121及びアプリケーションサーバ122がある。IMSはこれらの通話を取り扱うためにIPベースのネットワークを使用する。通話には音声通話とマルチメディア通話を含むかもしれない。

IMSネットワークは、3Gのシステムの中で、ユーザ111，112，113及びPSTN13のような他のネットワークと、外部のIPベースネットワーク120との間のゲートウェイとして効果的に働く。携帯端末とIMSネットワークの他のユーザとの間のシグナリングや、IMSネットワーク内でのシグナリングは、セッション開始プロトコル（Session Initiation Protocol， SIP）の下で行なわれる。以下、メッセージへの全ての言及は、特に明記しない限りSIPメッセージであり、大文字で示される。本発明の好ましい実施例はSIPに関して記述されるが、本発明の他の実施形態は非SIP環境で実装されることができることは理解されるべきである。

次に、本発明の実施態様の略図を表す図2と3が参照される。図2は送信端末と受信端末12を示す。送信端末10は受信端末にプレゼンス情報を提供するように構成される。プレゼンスサーバ14が提供される。プレゼンスサーバ14と送信端末は、ときおりプレゼンティティ（Presentity）と称される。プレゼンスサーバ14は受信端末12に要求されたプレゼンス情報を提供する。プレゼンスサーバ14は送信端末からプレゼンス情報を受け取る。プレゼンスサーバ14と受信端末との間の接続と同様に、送信端末10とプレゼンスサーバ14との間の接続は、図示されないネットワーク要素またはエンティティを通してなされるだろうことは理解されねばならない。

本発明の実施例において、送信端末10は、受信端末12と恐らくプレゼンスサーバ14がプレゼンス情報の異なる部分を識別して、それらを正しいアプリケーションへ届けることができるように、プレゼンス・タプルにマークをすべきである。送信端末10は上に説明された如何なるユーザでもあることができ、ウオッチされているユーザ又はプレゼンティティ（Presentity）と称される。受信端末12も上に説明された如何なるユーザでもあることができ、ウオッチャー（Watcher）と証される。特に本発明の実施例において、語義に意味があるアプリケーション識別情報フィールドは、各々のタプルまたは少なくともいくつかのタプルで提供される。このフィールドは、アプリケーションIDフィールドと称される。情報は、識別証そのものでもよいし、識別証に関連する情報でもよい。送信アプリケーションは、アプリケーション特有の識別子をアプリケーション識別情報フィールドに挿入し、それは受信側で認識されうる。受信端末は、その端末の中で、アプリケーションIDフィールドによって識別されるアプリケーションにタプルを渡す。

これは、図3を参照して更に詳細に議論される。ステップ1において、送信端末中のアプリケーション16aと16bと16cは、その端末のプレゼンスエンジン18にそれらのアプリケーション識別子を登録する。このステップの後、アプリケーションは情報を公開し始めることができる。すなわち、情報をプレゼンスサーバに送信する。（そして、ウオッチャーがプレゼンスへ加入していれば、プレゼンスサーバから受信端末へ送信する。）図3で示される例において、端末は3つのアプリケーションを有するものとして示されている。これは単なる例示であり、端末や他のユーザが有するアプリケーションの数は3つより多くも少なくもあることができる。

ステップ2において、各々のアプリケーション16はプレゼンス情報を1つ以上のタプルを含む形で公開し、プレゼンスエンジンはアプリケーションIDを各々のタプルに付加する。その後、プレゼンスエンジン18はプレゼンスサーバ14に情報を送り届ける。他の実施態様では、アプリケーションがアプリケーションIDの付加をすることができる。

ステップ3において、受信端末12のプレゼンスエンジン20は、プレゼンスサーバ14から新しいプレゼンス情報についてのNOTIFYメッセージを得る。アプリケーションID（これは各々のタプルで運ばれる）に従い、タプルはプレゼンスエンジンによって受信端末の対応するアプリケーション22に送られる。または、各々のアプリケーションはタプルの全てを受け取ることができるが、正しくないアプリケーション識別子を有するいずれのタプルも無視する。

このように、全てのアプリケーションはそれぞれのアプリケーションIDを有することができる。例えばgame1，game2，SMS，IM-1，IM-2，e-MAILなど。もし2台の端末（1と2）が同じアプリケーション（例えばIM-1）を備えているならば、そのアプリケーションについてアプリケーションIDは同じである。しかし、端末3が（例えば他のベンダーによって作られた）IM-2で識別されるアプリケーション有するなら、そのアプリケーションは端末1と2の中のIM-1アプリケーションとは異なるアプリケーションIDを持つ。そのような場合、提供される属性が別のアプリケーションによって使われるかもしれないが、その属性やその値が正しく解釈されないことがあり得るかもしれないので、注意が必要である。この1つの例は、IMに2つの異なるクライアントがある場合である。基本的機能性は同じであるかもしれず、従ってたとえどちらのアプリケーションが状態属性は解釈しても、それは有効かもしれないが、残りの属性は関連するかもしれないし全く関連しないかもしれない。

タプルがアプリケーション識別子を含むことから、効果的な（アプリケーションに個別の）フィルタリング能力を提供し、さらにタプルが用いられようとしている正しいアプリケーションを見つけることが可能である。

タプルには、draft-impp-cpim-pidf-05.txtに示されるように一般的な構造がある。（http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txtにリンクがある。）アプリケーションは、新しいXML名前空間を定めることにより、「付加的な情報を含む」オプションを拡張することができる。XMLは拡張可能なマークアップ言語（Extensible Markup Language）である。（SGMLに基づくワールド・ワイド・ウェブ（World Wide Web）のマークアップ言語で、HTMLで強いられる制限を取り払うようにデザインされた。定義や要素の実行プラン、またそれらの内容をページが含むことを許す。）
draft-impp-cpim-pidf-05.txt（http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt）

異なるタプルがどのアプリケーションで使われるべきかを定める誰又は何は様々であることができる。これはアプリケーションのタイプに依存するであろう。いくつか又は全てのタプルは標準のフォーマット（例えば3GPP標準で定められる標準属性）を持つように定められることができる。代わりに、又はそれに加え、アプリケーション開発者が彼ら自身のタプルを定めることも可能である。

一般に、1つのプレゼンティティが持つことのできるタプルについて、タプルや属性の数に限度はない。

アプリケーションIDを各々のタプルに付加するエンティティは、その情報を公開しているプレゼンスエンジン又はアプリケーションであることができる。本発明のある実施態様においては、アプリケーションIDが唯一のものであることが、その登録において必要とされるかもしれない。これは、アプリケーションIDが唯一のものであることが、語義的な意味を必要とする情報の他の集まりと同様に他のアプリケーションの中である場合であるかもしれない。

アプリケーションIDは、複数値のサポートとフィルタリングで使われるかもしれない。例えば、アプリケーションIDが、情報の異なる「正確さ」レベルを隠すために使われることができる。この場合はアプリケーションIDは唯一のものではない。意味を明解にするために説明すると、アプリケーション情報は、異なるアプリケーションが同じアプリケーションIDを使うべきではないという意味で、唯一のものである。しかし、同じアプリケーションIDは、プレゼンスサーバの中で異なるタプルに関連して何度も何度も提示されうる。タプルIDは唯一のものであるが、プレゼンティティのプレゼンス情報中の例えば2つ又は3つのタプルには、同じアプリケーションIDが存在する。それからアプリケーションIDはフィルタリングで使われることができる。すなわち、ウオッチャー（受信端末）は、ウオッチされているユーザ（プレゼンティティ）から全ての利用可能なプレゼンス情報を受け取らないように、フィルタを設定するかもしれない。このフィルタは、ウオッチャーが特定のアプリケーションのためのプレゼンス情報のみを受け取るために設定されるかもしれない。フィルタはあるプレゼンス情報やそれら2つの組み合わせをフィルタリングする。

例として、「ユーザ提供ロケーション」に関する全てのタプルが提供されるようにフィルタリングが選ばれているなら、次のようなタプルが（プレゼンティティからプレゼンスサーバに提供されていれば）ウオッチャーに提供される。

プレゼンティティ＝ABC

TUPLE 1， タプルID：xyz3226， アプリケーションID＝"ユーザ提供ロケーション"， ユーザ提供ロケーション ＝ タンペレ

TUPLE 2， タプルID： xyb3293， アプリケーションID＝"ユーザ提供ロケーション"， ユーザ提供ロケーション ＝ HOME

TUPLE 3， タプルID： xya3288， アプリケーションID＝"ユーザ提供ロケーション"， ユーザ提供ロケーション ＝ x座標，y座標

図5を参照する。第1のプレゼンティティ30がタプル1，2，3，4，5を提供している。各々のタプルはアプリケーションIDを持ち、タプル1と2はアプリケーションID"A"、タプル3と4はアプリケーションID"B"、タプル5はアプリケーション"C"を持つ。ウオッチャー32はアプリケーション"A"のみを欲している。フィルタ34はそこでタプルをフィルタリングし、ユーザ32にタプル1と2のみを供給する。実際にはフィルタはプレゼンティティの一部、サーバ等の異なるエンティティの一部、ウオッチャー32の一部でありうることは理解されねばならない。このように、アプリケーションIDはタプルをフィルタリングするために用いられる。

タプルは、異なるユーザを対象としているかもしれない。従って、タプル1，3，5はあるウオッチャーを対象とし、タプル2と5は他のウオッチャーを対象とするかもしれない。従ってウオッチャーはタプル1，3，5のみを"見る"ことができるかもしれない。従って、ウオッチャーがアプリケーション"A"のタプルだけを欲する場合は、ウオッチャーはタプル1のみを供給されるだろう。フィルタ34はこの更なるフィルタリングを提供する。本発明のある実施例においては、ウオッチャーが求めるタプルのみを得ることを確実にするため、独立のフィルタ又は指示手段が提供される。

利用可能なプレゼンス情報は、ウオッチャーグループによって異なることがあり得る。

本発明の実施態様は、アプリケーションが、その特定のアプリケーションがどんな情報を解釈でき理解できるのかをプレゼンス情報から簡単に認識することを可能とする。

本発明の実施態様では、フィルタリングを実行するとき、アプリケーション識別子がプレゼンスサーバに利用されうることは理解されねばならない。本発明のある実施態様では、オペレータ特有のアプリケーションが、やはりアプリケーションIDを利用するプレゼンスサーバに提供される。プレゼンスサーバは、例えばユーザがプレゼンスサーバへのアクセス権を与え、理解したタプルの中で、属性値を修正することができる。

本発明の実施態様はフィルタリングに用いられることができる。例えば、ウオッチャーは1つ以上の特定のアプリケーションに関するプレゼンス情報の一部だけを要求することができる。フィルタリングは、ウオッチされているプレゼンティティ（ユーザかプレゼンスサーバ）、ウオッチャー、又は他のいずれかのエンティティによって行なわれることができる。プレゼンス情報が特定のプレゼンティティから特定のウオッチャーへ提供されるとき、いつでも要求されるアプリケーションに従ってフィルタされるように、フィルタ情報は予め保管されていることができる。フィルタリングは、必要なアプリケーション、必要でないアプリケーション、又はこれらの技術の組み合わせを定めることができる。

上記のように、ウオッチャーは一般的に上で示したようなユーザである。"プレゼンティティ"は、そのユーザに関連しているユーザやプレゼンスサーバであることができる。プレゼンスサーバは、そのプレゼンスサーバに関連しているユーザのためにプレゼンス情報を格納する。実際には、各々のサーバには1つ以上のユーザが結びついていることは理解されねばならない。プレゼンスサーバは末端のデバイス（端末）に位置するかもしれない。

現在3GPPで定義されているプレゼンス情報は、次のような情報を含むことができる。（情報がこれらに限定されることはない。標準化作業のステージ1（必要条件グループ）からの要件は、可能なプレゼンスが拡張されるようにコンセプトを発展させることになっている。

加入者状態； ネットワーク状態； 通信手段； 連絡先アドレス； 加入者提供ロケーション； ネットワーク提供ロケーション； テキスト； 優先度。

プレゼンスはまた、他にも気分や好みの色など情報を含むことができる。

本発明の実施例が、アプリケーション識別子と呼ばれる属性に限定されることはなく、似たような型の動作可能性を提供するいかなる属性にも提供できることは、理解されねばならない。

本発明の実施例はタプルの使用に限られていない。全てのシステムがプレゼンスドキュメントを構成するためにタプルを用いる訳ではなく、例えばワイヤレス・ビレッジ（Wireless Village）プレゼンスは、属性レベルでプレゼンス情報を取り扱い、このような場合はアプリケーションIDは各々別々の属性にリンクされる。

図4は、IMSネットワーク100の概略図を示す。IMSは、いくつかの通話状態制御機能（CSCF）を含むいろいろな要素を含む。CSCFは、IETFアーキテクチャにおけるSIPサーバに等しい。

問い合わせCSCF（Interrogating CSCF，I-CSCF）201は、IMSネットワークで通話を終了するために使われる基本的なIMSノードであり、ネットワークの末端で機能する。ここでは、それが外部のノードである携帯端末101，PDA113，アプリケーションサーバ（AS）121と通信していることが示されている。携帯端末101やPDA113、アプリケーションサーバ（AS）121とI-CSCFとの間の接続は直接ではないかもしれず、図1に示されるような、携帯端末のための携帯電話コアネットワーク110やアプリケーションサーバのためのインターネット120等の適当な中間ネットワークを経由した接続であるかもしれないことは、理解されるべきである。

HSS202は、I-CSCFとS-CSCF204との間のインターフェースとなる、集中ユーザデータベースであり、IMSの全てのユーザの情報を格納する。I-CSCFは、新しいユーザの承認や、メッセージを外部要素からS-CSCFまで送るための経路情報をS-CSCFで検索するなどの機能を遂行するために、HSSを使う。

S-CSCFは、IMSユーザに関連したサービスを開始することに対して責任を負うIMSノードである。この例では、S-CSCFもIMSユーザのためにユーザ登録を処理する登録係の機能性を遂行する。プレゼンスサーバの機能性はアプリケーションサーバとして実装される。

図4の説明は単に略図であり、実際にはプロキシCSCF（proxy-CSCF，P-CSCF）など、別の要素が文から抜けていることは理解されねばならない。また、本発明の実施態様が図4に示されたもの以外のシステムにも使いうることは理解されねばならない。

色々なユーザのプレゼンス情報に登録するために、プレゼンスパッケージが用いられることができる。プレゼンスパッケージの語義は次のようなことを意味している。どんなユーザもプレゼンス情報のための登録メッセージをプレゼンスサーバに送ることができるが、もしそのようなプレゼンスパッケージが定義されていなければ、プレゼンスサーバはユーザがどのようなイベントを登録しようとしたのかを理解できないだろう。従って、プレゼンスパッケージはプレゼンスサーバで定められる必要がある。するとプレゼンスサーバは、プレゼンス情報を変化させる関連イベントのための登録メッセージを受信し認識することができる。プレゼンスサーバはプレゼンス状態にリンクされた状態を作り、プレゼンス情報に何らかの変化が起きると、それは反応や通知を行なう合図となる。

本発明の実施態様はSIPを用いた3Gに関連して説明されたが、他の適当なシステムやインターフェースプロトコルも用いられうることは理解されねばならない。特に、本発明の実施態様は、IETF仕様書に従うアプリケーションで用いられることができる。

更に、上に本発明の実施態様を例示的に説明したが、添付の特許請求の範囲に定められた本発明の範囲を逸脱せずに開示されたソリューションに対して適用しうる、いくつかのバリエーションや変形があることは、ここで注意しておかねばならない。

本発明が適用されうる通信システムを図示している。 本発明の実施例の概略を図示している。 更に詳細に図2の実施例を図示している。 図1のシステムのIMS一部を更に詳細に図示している。 本発明の実施例の概略を図示している。

符号の説明

10 送信端末
12 受信端末
14 プレゼンスサーバ
16 アプリケーション
18 プレゼンスエンジン
20 プレゼンスエンジン
22 アプリケーション
30 プレゼンティティ
32 ウオッチャー、ユーザ
34 フィルタ
100 ネットワーク
110 携帯電話コアネットワーク
111 携帯端末
112 ラップトップ
113 PDA
120 インターネット
121 アプリケーションサーバ
122 アプリケーションサーバ
123 コンピュータ端末
131 電話
201 I-CSCF
202 HSS
204 S-CSCF

Claims (30)

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. 一つ又はそれ以上のアプリケーションで処理されることになっている、前記プレゼンス情報の一つ又はそれ以上のサブセットを要求することを含む、請求項２４から２７のいずれかに記載の方法。
29. プレゼンス情報を提供するように構成される、コンピュータ実行可能な要素を含むコンピュータ読み取り可能な媒体であって、前記プレゼンス情報は複数のサブセットを含み、前記複数のサブセットの少なくとも一つは、該少なくとも一つのサブセットが用いられるアプリケーションを識別する情報を含む、コンピュータ読み取り可能な媒体。
30. 少なくとも１つのユーザに関連づけられたプレゼンス情報を利用するように構成された、コンピュータ実行可能な要素を含むコンピュータ読み取り可能な媒体であって、
    前記プレゼンス情報は複数のサブセットを含み、前記複数のサブセットの少なくとも一つは、該少なくとも一つのサブセットが用いられるアプリケーションを識別する情報を含み、
    前記コンピュータ実行可能な要素は、前記少なくとも１つのプリケーションのために前記プレゼンス情報の前記少なくとも１つのサブセットを取得するべく、前記アプリケーションを識別する情報を用いる、
    コンピュータ読み取り可能な媒体。