(57)【要約】  本発明は、通信システムであって、プレゼンス情報が結びついている少なくとも１つのユーザと、前記少なくとも１つのユーザが結びついているプレゼンス情報が提供される少なくとも１つのエンティティとを備え、前記プレゼンス情報は複数の部分を有し、少なくとも１つの前記複数の部分は前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を有し、前記少なくとも１つのエンティティは少なくとも１つのエンティティアプリケーションを有し、前記少なくとも１つのエンティティは前記少なくとも１つのエンティティアプリケーションに用いられる前記少なくとも１つの部分を取得するために前記情報を用いる、通信システムに関する。
2006502641.tif 000002
【特許請求の範囲】
【請求項１】
通信システムであって、
プレゼンス情報が結びついている少なくとも１つのユーザと、前記少なくとも１つのユーザが結びついているプレゼンス情報が提供される少なくとも１つのエンティティとを備え、
前記プレゼンス情報は複数の部分を有し、少なくとも１つの前記複数の部分は前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を有し、
前記少なくとも１つのエンティティは少なくとも１つのエンティティアプリケーションを有し、前記少なくとも１つのエンティティは前記少なくとも１つのエンティティアプリケーションに用いられる前記少なくとも１つの部分を取得するために前記情報を用いる、通信システム
【請求項２】
前記少なくとも１つのエンティティは、前記情報の前記少なくとも１つの部分を受け取る手段を備える請求項に１記載のシステム。
【請求項３】
前記エンティティは、前記情報の前記少なくとも１つの部分を、該識別されたエンティティアプリケーションへ案内する手段を有する請求項２に記載のシステム。
【請求項４】
前記案内する手段はアプリケーションエンジンを備える請求項３に記載のシステム。
【請求項５】
前記エンティティはユーザである上記いずれかの請求項に記載のシステム。  
【請求項６】
前記エンティティは、エンティティからの要求に応じて前記情報の前記少なくとも１つの部分を受け取る、上記いずれかの請求項に記載のシステム。
【請求項７】
前記少なくとも１つのユーザは、少なくとも１つのアプリケーションを備える上記いずれかの請求項に記載のシステム。
【請求項８】
前記少なくとも１つのユーザは、プレゼンスエンジンを備える上記いずれかの請求項に記載のシステム。
【請求項９】
前記少なくとも１つのアプリケーションは、前記アプリケーションを識別する前記情報を前記プレゼンスエンジンに登録するように構成される、請求項８に記載のシステム。
【請求項１０】
前記少なくとも１つのアプリケーションと前記プレゼンスエンジンのうちの少なくとも１つは、前記識別する情報を少なくとも１つの部分に加えるように構成される、請求項８又は９に記載のシステム。
【請求項１１】
前記ユーザがユーザ装置を備える上記いずれかの請求項に記載のシステム。  
【請求項１２】
前記プレゼンス情報は、情報の次の部分のうちの少なくとも１つを備える：加入者の状態、ネットワークの状態、通信手段、連絡先アドレス、加入者提供ロケーション、ネットワーク提供ロケーション、テキスト、優先度、気分、好みの色。
【請求項１３】
セッション開始プロトコル（ＳＩＰ）に従って動作する上記いずれかの請求項に記載のシステム。
【請求項１４】
前記情報の部分がタプルを備える上記いずれかの請求項に記載のシステム。
【請求項１５】
前記タプルは、前記ユーザと、情報を識別する前記アプリケーションとを識別する情報を備える、請求項１４に記載のシステム。
【請求項１６】
前記エンティティは、前記エンティティの１つ以上のアプリケーションで処理される前記プレゼンス情報の１つ以上の部分だけを要求するように構成される、上記いずれかの請求項に記載のシステム。
【請求項１７】
前記プレゼンス情報の前記要求された部分だけを提供するためのフィルタリング手段が提供される請求項１６に記載のシステム。
【請求項１８】
前記フィルタリング手段は、サーバ、プレゼンスサーバ、前記少なくとも１つのユーザのうちの少なくとも１つで提供される請求項１７に記載のシステム。
【請求項１９】
前記少なくとも１つのエンティティは、前記プレゼンス情報をフィルタリングするために前記情報を用いるように構成される、上記いずれかの請求項に記載のシステム。
【請求項２０】
前記エンティティアプリケーションは、前記エンティティアプリケーションを識別する情報を有する前記プレゼンス情報の前記少なくとも１つの部分を処理するように構成される、上記いずれかの請求項に記載のシステム。
【請求項２１】
通信方法であって、
関連するユーザのためのプレゼンス情報を提供するステップであって、前記プレゼンス情報は複数の部分を有し、少なくとも１つの前記複数の部分は前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を有するステップと、
少なくとも１つのエンティティが前記複数の部分の少なくとも１つを取得するステップであって、前記少なくとも１つのエンティティは少なくとも１つのエンティティアプリケーションを有し、該少なくとも１つのエンティティは、前記少なくとも１つのエンティティアプリケーションを識別する情報を有する該複数の部分を取得するステップと、
を備える通信方法。
【請求項２２】
前記エンティティアプリケーションを識別する情報を備える該プレゼンス情報の前記少なくとも１つの部分を、前記少なくとも１つのエンティティアプリケーションで処理するステップを備える、請求項２１に記載のシステム。
【請求項２３】
通信システムのユーザであって、前記ユーザは関連するプレゼンス情報を有し、前記プレゼンス情報は複数の部分を有し、前記ユーザは前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を含む少なくとも１つの前記複数の部分を提供するように構成される、ユーザ。
【請求項２４】
通信システムのエンティティであって、ユーザに関連するプレゼンス情報の少なくとも１つの部分を取得するための少なくとも１つのアプリケーション取得手段を備え、該少なくとも１つの部分はアプリケーションを識別する情報を有し、該取得手段は前記少なくとも１つのアプリケーションを識別する情報を備える該少なくとも部分を取得するように構成される、エンティティ。
【請求項２５】
前記少なくとも１つの部分によって識別されるアプリケーションは、前記アプリケーションを識別する情報を備える該プレゼンス情報の少なくとも１つの部分を処理するように構成される、請求項２４に記載のエンティティ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システムに関し、より詳細には通信システムにおけるプレゼンスサービスの提供に関する。
【背景技術】
【０００２】
今日、多様な通信システムが用いられ、ユーザ装置又は／及びシステムと結びついている他のノードのような、２つもしくはそれ以上のエンティティ間の通信を可能としている。
【０００３】
ユーザ端末または他のノードのために無線通信を証明している通信システムは既知である。無線システムの１つの例は公衆陸上移動通信ネットワーク（ＰＬＭＮ）である。ＰＬＭＮは、一般的に、無線基地局（ＢＴＳ）または類似したアクセスエンティティが、無線インターフェースによって移動局（ＭＳ）のようなユーザ装置（ＵＥ）のために働くセルラネットワークである。通常、通信のために必要な装置の動作は、互いに接続しているであろう１つ以上の制御エンティティによって制御される。ＰＬＭＮを他のネットワークに接続するために、１つ以上のゲートウェイノードが用意される。そのような他のネットワークの例は、他のセルラネットワーク、公衆交換電話網（ＰＳＴＮ）やＩＰ（インターネットプロトコル）ベースのネットワークのようなパケット交換データネットワークである。ユーザ装置と通信システムの他の要素との間の通信は、適当な通信プロトコルに基づいており、それは通信がシステムで取り扱われる間の「規則」を定めている。
【０００４】
現在の第三世代（３Ｇ）無線システムでは、モバイルユーザのための色々な通信サービスを処理する様々なサーバが定義されている。これらはＣＳＣＦとして知られている通話状態制御機能を提供するサーバを含んでいる。制御機能は、加入者管理サーバ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ，  ＨＳＳ）や様々なアプリケーションサーバによるアプリケーションなどのエンティティによって提供される場合がある。一般的に、ＨＳＳはユーザのプロファイルを恒久的に格納しており、認証の際に用いられる。例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって策定された３Ｇアーキテクチャの第５版では、これらのエンティティは、ＩＰマルチメディアサブシステム（ＩＭＳ）に位置していることが見出される。
【０００５】
ＩＭＳネットワークは、従来の音声電話通信とマルチメディアサービスの両方に対応するＩＰベースのネットワークをサポートする、３Ｇアーキテクチャのハブに位置するかもしれない。３ＧＰＰは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ，  ＳＩＰ）を、３Ｇネットワークの中心的なセッション・シグナリングプロトコルとして選択した。ＳＩＰはインターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）によって開発された。関心がある者は、ＳＩＰの視点からのＩＭＳネットワークの基本的な動作が記述されている３ＧＰＰ仕様書２４．２２９（題名は“ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｃａｌｌ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ  ｂａｓｅｄ  ｏｎ  ＳＩＰ  ａｎｄ  ＳＤＰ”）を、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／Ｓｐｅｃｓ／Ｌａｔｅｓｔ−ｄｒａｆｔｓ／２４２２９−２０１．ｚｉｐから見つけることができる。ＳＩＰは、発信地から送られる全てのメッセージについて、到達地から送信メッセージの受信を確認する関連応答があるという意味で、リクエスト／レスポンス型のプロトコルである。（承認ＡＣＫメッセージは、レスポンスが送られない特別の場合である。）
【０００６】
例えば、３Ｇのネットワークでは、ユーザが最初に彼の携帯端末のスイッチを入れるとき、彼は端末を完全に接続させる前に彼のユーザＩＤまたはアドレスをネットワークに登録しなければならない。これは端末からＩＭＳまで、ユーザアドレスの詳細が含まれるＳＩＰ“ＲＥＧＩＳＴＥＲ”メッセージを送ることによってなされる。ＩＭＳはこの情報を受信し、そしてこの文脈において“登録”と言い表されるサービング通話状態制御機能（Ｓ−ＣＳＣＦ）を用いてこの情報を処理する。ＲＥＧＩＳＴＥＲメッセージは、例えば、ｓｉｐ：  ｍｉｋｋｏ．ｌｏｎｎｆｏｒｓ＠ｓｏｎｅｒａ．ｃｏｍというエイリアスを端末のＩＰアドレスにマッピングするなど、ユーザのエイリアスと連絡先アドレスとの間のマッピングを提供するためだけに用いられる。ＩＭＳは、ＳＩＰに従って適当な承認メッセージ（例えば“２００  ＯＫ”メッセージ）を送ることにより、登録を承認する。以前の登録が終了したか終了しそうなとき、あるいは、ユーザの状態に変化がありそうなときは、いつでも次の登録が行なわれる（ｒｅ−ＲＥＧＩＳＴＥＲ）。ユーザがもう一人のユーザと、音声通話やメッセージングセッションなどの新たなセッションを開始したいと望むとき、セッションネゴシエーションはＳＩＰの下で遂行される。（メッセージ、すなわちＳＩＰ  ＭＥＳＳＡＧＥを送る別の方法があり、その場合はセッションの確立は必要とされない。）
【０００７】
アプリケーションサーバ（ＡＳ）は、ＩＭＳを通じてインスタントメッセージングやプレゼンス、ローカル交通情報、会議施設などのサービスを提供することができる。ＡＳは、ＩＭＳネットワークの中に、またはその外にあるかもしれない。一般的に、サポートされるサービスが第三者によって提供されるとき、ＡＳは外部にある。
【０００８】
状態情報の１つの特定の例は、プレゼンス情報である。プレゼンスサービスに加入しているユーザまたはアプリケーションサーバは、他のユーザの機能や対応可能性を判断することができる。（他のプレゼンス特徴や属性の中でも、例えば呼び出しに応答できるかなどであり、これは機器やサービスプロバイダに依存する。）しかしながら、ＳＩＰをサポートしているシステムでは、プレゼンスは様々な形を呈することができ、例えば「オフィスにいて全ての電話に対応可能」「家にいるので私用電話のみ対応」「電話中（又は少なくともそのように表示）」などであることができる。従ってプレゼンス情報は、ユーザが他のユーザに電話をかけようとする前に、そのユーザが対応しうるか否かを確かめることを可能にする。プレゼンスサービスは単に対応可能／不可能のような情報以上のものを提供することができる。それは視覚的、アニメ、音の要素を含むことができ、またゲームセッションに関連することなど、様々な事項を記述することができる。
【０００９】
このプレゼンスサービスは、ＯＭＡ  ８（オープンモバイルアライアンス（ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ））、３ＧＰＰ及びＩＥＴＦで標準化されつつあり、ますます注目を集めている。将来、プレゼンスに対応したアプリケーションの数が増加することが予想されている。アプリケーションの数が増えるにつれ、それはプレゼンス情報の量も増やす。受信端末の視点からは、情報の増加はプレゼンス情報をどのように取り扱うかという問題を投げかける。例えば、プレゼンス情報のどの部分がどのアプリケーションにとって重要なのか、などの問題である。端末は１つ又はそれ以上のアプリケーションを走らせているかもしれない。例えば、端末は動的な電話帳アプリケーションとゲームアプリケーションを走らせることができる。
【００１０】
現在のＩＥＴＦと３ＧＰＰのモデルでは、タプル構造が使われている。タプルは“ランダムな”ＴＵＰＬＥ  ＩＤを持ち、それは何の意味をも持っておらず、例えばそれはタプルの目的を記述するために用いることはできない。各々のタプルでは、いくつかの属性があることができる。さらに、別々のタプルが、同じ名前を持つ属性であるが、送信又は受信アプリケーションに応じて異なって使われたり解釈されたりするように意図される属性を有することもある。例えば、プレゼンス情報は２つのタプル（１つはゲームのため、もう１つは動的な電話帳（ＤＰＢ）のため）を含むことができ、これら各々のタプルは状態フィールドを含むことができる。動的な電話帳は、応答可能、不明、応答不能、という状態値を認識するようにデザインされ、ゲームは、発射、死、一時停止、負け、という状態値を認識するようにデザインされることができる。この例から分かるように、状態フィールドが正しい意味を持つことになっているならば、状態フィールドは適切なアプリケーションに届けられなければならない。これは、端末が２つ以上のアプリケーションを備えているときに問題となる。また、受信端末が１つのアプリケーションしか備えていなくとも、送信端末や情報を提供する側（プレゼンティティ、Ｐｒｅｓｅｎｔｉｔｙ）が複数である場合に問題となる。上記の例におけるデータが、例えばＤＰＢしか備えていない端末に送られたとしたら、受信端末はどちらのタプルがＤＰＢアプリケーションに使われるためのものなのかを判断することができなくてはならない。
【００１１】
現在のところ、各々のアプリケーションが個々のタプルをチェックしてその状態値がそのアプリケーションにとって意味を持つかを調べる以外、情報を正しいアプリケーションに渡すためのメカニズムはない。言い換えると、試行錯誤アプローチが採用されている。しかしながら、これは情報の正しさに関して不確実性をもたらす。なぜなら、ある場合には、ある属性について値が同じだったとしても、間違ったアプリケーションによって誤って解釈されるかもしれないからである。この１つの例は次の通りである。送信端末はＤＰＢとＩＭ（インスタントメッセージング）アプリケーションを備えている。送信端末は、ＤＰＢを「終了」に、ＩＭを「開始」になるように状態値をセットする。この例では、両方のアプリケーションが状態値として「開始」と「終了」だけを使うだろう。ここでもし受信端末がＩＭアプリケーションしか備えておらず、そしてＤＰＢとＩＭの状態値を受信したらどうどうなるだろう。受信端末が最初の状態値であるＤＰＢでやってみようとすれば、受信端末はそれを理解し、ＩＭアプリケーションを通じて、プレゼンティティ（情報を発信する側、Ｐｒｅｓｅｎｔｉｔｙ）の端末は終了したとユーザに表示するだろう。実はそれが開始したにも関わらず。
【００１２】
ユーザが他の１つのユーザプレゼンス情報を得たいと欲するところで、そのユーザはプレゼンスサーバからデータ（つまりプレゼンス情報）を減らすためにフィルタを含めることができると提唱された。これらのフィルタはそのユーザが興味のある部分だけを含むようにプレゼンスサーバからデータを減らすことができる。
【００１３】
タプル識別子がプレゼンス情報を要求する側（ウオッチャー、Ｗａｔｃｈｅｒ）によってフィルタリングの基準として用いられるというアプローチも、承認がタプル識別子に基づくというアプローチにも、両方とも多くの不都合がある。例えば、プレゼンス情報を要求されている側のユーザが４つのタプル（Ｔ１、Ｔ２、Ｔ３、Ｔ４）を有し、あるウオッチャーはＴ２とＴ３にしか興味がないとする。するとそのウオッチャーは、タプルＴ２とＴ３のみ彼に通知されるようなフィルタをセットする。プレゼンス情報を要求されている側のユーザは、何かの理由で、全てのタプルに関心を持つ特定のウオッチャーに異なる値を提示することを始めるかもしれない。そこでプレゼンス情報を要求されている側のユーザは、新しいタプルＴ５、Ｔ６、Ｔ７、Ｔ８を作り、新しいアクセスリストを作る。そのアクセスリストはウオッチャーがタプルＴ５−Ｔ８を見ることを許可するが、タプルＴ１−Ｔ４を見ることは許可しない。しかし先程のウオッチャーはタプル識別子に基づいてフィルタをセットしており、それはタプルが彼に提供されないことを意味する。これは不都合である。
【００１４】
フィルタリングでタプル識別子を用いることのもう１つの不都合は次のようなことである。通常、プレゼンティティは、特定のウオッチャーが他のウオッチャーと同じ程度に詳細な情報を得ることを許されていないということを、ウオッチャーに知って欲しくない。また、異なるウオッチャーグループに与えられる情報が、他のウオッチャーグループに与えられる情報と、少し又は全く異なるということも知って欲しくない。
【００１５】
詳細の程度が異なる情報がウオッチャーに提供されることから、フィルタのセッティングがウオッチャーの承認情報が変わる度に変わるというのは不都合である。これは、フィルタリングが一意のタプル識別子に基づく場合に問題となるだろう。
【発明の開示】
【００１６】
本発明の実施態様は、上記の１又はいくつかの問題を克服しようとするものである。本発明の第１の側面によれば、プレゼンス情報が結びついている少なくとも１つのユーザを備え、前記プレゼンス情報は複数の部分を有し、少なくとも１つの前記複数の部分は前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を有する通信システムが提供される。
【００１７】
本発明の第２の側面によれば、通信システムであって、関連するユーザのためのプレゼンス情報を提供するステップであって、前記プレゼンス情報は複数の部分を有し、少なくとも１つの前記複数の部分は前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を有するステップと、少なくとも１つのエンティティが前記複数の部分の少なくとも１つを取得するステップであって、前記少なくとも１つのエンティティは少なくとも１つのエンティティアプリケーションを有し、該少なくとも１つのエンティティは、前記少なくとも１つのエンティティアプリケーションを識別する情報を有する該複数の部分を取得するステップとを備える通信方法が提供される。
【００１８】
本発明の第３の側面によれば、通信システムのユーザであって、前記ユーザは関連するプレゼンス情報を有し、前記プレゼンス情報は複数の部分を有し、前記ユーザは前記少なくとも１つの部分が用いられるアプリケーションを識別する情報を含む少なくとも１つの前記複数の部分を提供するように構成される、ユーザが提供される。
【００１９】
本発明の第４の側面によれば、通信システムのエンティティであって、ユーザに関連するプレゼンス情報の少なくとも１つの部分を取得するための少なくとも１つのアプリケーション取得手段を備え、該少なくとも１つの部分はアプリケーションを識別する情報を有し、該取得手段は前記少なくとも１つのアプリケーションを識別する情報を備える該少なくとも部分を取得するように構成される、エンティティが提供される。
【００２０】
本発明の実施例で可能な非常に静的なフィルタリング設定は、フィルタが特定のサーバの中（例えばプレゼンスリストケースの中）に格納されている場合や、予めそのような場合に特に有効である。
【００２１】
本発明の実施例は、異なるウオッチャーが利用可能な情報には異なるレベルの情報（又は全く違った情報）があるという事実をウオッチャーから隠すことができる。
【００２２】
本発明の実施例は、フィルタリング設定やいくつかの他の機能性に影響を与えることなく承認を変えることを可能とする。それらはプレゼンス情報要素により多くの意味的なものを与えることにより、承認から切り離されうる。
【００２３】
本発明の実施例は、“意味を持たない”識別情報についての要求に基礎を置く代わりに、意味的に理解しうる情報を要求する可能性をウオッチャーに与えることができる。
【発明を実施するための最良の形態】
【００２４】
本発明や、本発明がどのように実施されうるのかを理解するために、単なる例示であるが添付図面が参照される。
【００２５】
まず始めに図１を参照する。図１は、ＵＭＴＳ（欧州での第３世代移動通信システムの呼称、Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）の下で動作する典型的な第３世代（３Ｇ）無線通信システムである。このシステムのハブはＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク１００であり、２つやそれ以上のユーザ間の（又はユーザとアプリケーションサーバ等のネットワーク要素との間の）通話や全ての種類のセッションをルーティングする。ユーザの例として、携帯端末１１１，ラップトップ１１２，パーソナルデスクトップアシスタント１１３，公衆交換電話網（ＰＳＴＮ）電話１３１，コンピュータ端末１２３，アプリケーションサーバ１２１及びアプリケーションサーバ１２２がある。ＩＭＳはこれらの通話を取り扱うためにＩＰベースのネットワークを使用する。通話には音声通話とマルチメディア通話を含むかもしれない。
【００２６】
ＩＭＳネットワークは、３Ｇのシステムの中で、ユーザ１１１，１１２，１１３及びＰＳＴＮ１３のような他のネットワークと、外部のＩＰベースネットワーク１２０との間のゲートウェイとして効果的に働く。携帯端末とＩＭＳネットワークの他のユーザとの間のシグナリングや、ＩＭＳネットワーク内でのシグナリングは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ，  ＳＩＰ）の下で行なわれる。以下、メッセージへの全ての言及は、特に明記しない限りＳＩＰメッセージであり、大文字で示される。本発明の好ましい実施例はＳＩＰに関して記述されるが、本発明の他の実施形態は非ＳＩＰ環境で実装されることができることは理解されるべきである。
【００２７】
次に、本発明の実施態様の略図を表す図２と３が参照される。図２は送信端末と受信端末１２を示す。送信端末１０は受信端末にプレゼンス情報を提供するように構成される。プレゼンスサーバ１４が提供される。プレゼンスサーバ１４と送信端末は、ときおりプレゼンティティ（Ｐｒｅｓｅｎｔｉｔｙ）と称される。プレゼンスサーバ１４は受信端末１２に要求されたプレゼンス情報を提供する。プレゼンスサーバ１４は送信端末からプレゼンス情報を受け取る。プレゼンスサーバ１４と受信端末との間の接続と同様に、送信端末１０とプレゼンスサーバ１４との間の接続は、図示されないネットワーク要素またはエンティティを通してなされるだろうことは理解されねばならない。
【００２８】
本発明の実施例において、送信端末１０は、受信端末１２と恐らくプレゼンスサーバ１４がプレゼンス情報の異なる部分を識別して、それらを正しいアプリケーションへ届けることができるように、プレゼンス・タプルにマークをすべきである。送信端末１０は上に説明された如何なるユーザでもあることができ、ウオッチされているユーザ又はプレゼンティティ（Ｐｒｅｓｅｎｔｉｔｙ）と称される。受信端末１２も上に説明された如何なるユーザでもあることができ、ウオッチャー（Ｗａｔｃｈｅｒ）と証される。特に本発明の実施例において、語義に意味があるアプリケーション識別情報フィールドは、各々のタプルまたは少なくともいくつかのタプルで提供される。このフィールドは、アプリケーションＩＤフィールドと称される。情報は、識別証そのものでもよいし、識別証に関連する情報でもよい。送信アプリケーションは、アプリケーション特有の識別子をアプリケーション識別情報フィールドに挿入し、それは受信側で認識されうる。受信端末は、その端末の中で、アプリケーションＩＤフィールドによって識別されるアプリケーションにタプルを渡す。
【００２９】
これは、図３を参照して更に詳細に議論される。ステップ１において、送信端末中のアプリケーション１６ａと１６ｂと１６ｃは、その端末のプレゼンスエンジン１８にそれらのアプリケーション識別子を登録する。このステップの後、アプリケーションは情報を公開し始めることができる。すなわち、情報をプレゼンスサーバに送信する。（そして、ウオッチャーがプレゼンスへ加入していれば、プレゼンスサーバから受信端末へ送信する。）図３で示される例において、端末は３つのアプリケーションを有するものとして示されている。これは単なる例示であり、端末や他のユーザが有するアプリケーションの数は３つより多くも少なくもあることができる。
【００３０】
ステップ２において、各々のアプリケーション１６はプレゼンス情報を１つ以上のタプルを含む形で公開し、プレゼンスエンジンはアプリケーションＩＤを各々のタプルに付加する。その後、プレゼンスエンジン１８はプレゼンスサーバ１４に情報を送り届ける。他の実施態様では、アプリケーションがアプリケーションＩＤの付加をすることができる。
【００３１】
ステップ３において、受信端末１２のプレゼンスエンジン２０は、プレゼンスサーバ１４から新しいプレゼンス情報についてのＮＯＴＩＦＹメッセージを得る。アプリケーションＩＤ（これは各々のタプルで運ばれる）に従い、タプルはプレゼンスエンジンによって受信端末の対応するアプリケーション２２に送られる。または、各々のアプリケーションはタプルの全てを受け取ることができるが、正しくないアプリケーション識別子を有するいずれのタプルも無視する。
【００３２】
このように、全てのアプリケーションはそれぞれのアプリケーションＩＤを有することができる。例えばｇａｍｅ１，ｇａｍｅ２，ＳＭＳ，ＩＭ−１，ＩＭ−２，ｅ−ＭＡＩＬなど。もし２台の端末（１と２）が同じアプリケーション（例えばＩＭ−１）を備えているならば、そのアプリケーションについてアプリケーションＩＤは同じである。しかし、端末３が（例えば他のベンダーによって作られた）ＩＭ−２で識別されるアプリケーション有するなら、そのアプリケーションは端末１と２の中のＩＭ−１アプリケーションとは異なるアプリケーションＩＤを持つ。そのような場合、提供される属性が別のアプリケーションによって使われるかもしれないが、その属性やその値が正しく解釈されないことがあり得るかもしれないので、注意が必要である。この１つの例は、ＩＭに２つの異なるクライアントがある場合である。基本的機能性は同じであるかもしれず、従ってたとえどちらのアプリケーションが状態属性は解釈しても、それは有効かもしれないが、残りの属性は関連するかもしれないし全く関連しないかもしれない。
【００３３】
タプルがアプリケーション識別子を含むことから、効果的な（アプリケーションに個別の）フィルタリング能力を提供し、さらにタプルが用いられようとしている正しいアプリケーションを見つけることが可能である。
【００３４】
タプルには、ｄｒａｆｔ−ｉｍｐｐ−ｃｐｉｍ−ｐｉｄｆ−０５．ｔｘｔに示されるように一般的な構造がある。（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｉｍｐｐ−ｃｐｉｍ−ｐｉｄｆ−０５．ｔｘｔにリンクがある。）アプリケーションは、新しいＸＭＬ名前空間を定めることにより、「付加的な情報を含む」オプションを拡張することができる。ＸＭＬは拡張可能なマークアップ言語（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）である。（ＳＧＭＬに基づくワールド・ワイド・ウェブ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）のマークアップ言語で、ＨＴＭＬで強いられる制限を取り払うようにデザインされた。定義や要素の実行プラン、またそれらの内容をページが含むことを許す。）
異なるタプルがどのアプリケーションで使われるべきかを定める誰又は何は様々であることができる。これはアプリケーションのタイプに依存するであろう。いくつか又は全てのタプルは標準のフォーマット（例えば３ＧＰＰ標準で定められる標準属性）を持つように定められることができる。代わりに、又はそれに加え、アプリケーション開発者が彼ら自身のタプルを定めることも可能である。
【００３５】
一般に、１つのプレゼンティティが持つことのできるタプルについて、タプルや属性の数に限度はない。
【００３６】
アプリケーションＩＤを各々のタプルに付加するエンティティは、その情報を公開しているプレゼンスエンジン又はアプリケーションであることができる。本発明のある実施態様においては、アプリケーションＩＤが唯一のものであることが、その登録において必要とされるかもしれない。これは、アプリケーションＩＤが唯一のものであることが、語義的な意味を必要とする情報の他の集まりと同様に他のアプリケーションの中である場合であるかもしれない。
【００３７】
アプリケーションＩＤは、複数値のサポートとフィルタリングで使われるかもしれない。例えば、アプリケーションＩＤが、情報の異なる「正確さ」レベルを隠すために使われることができる。この場合はアプリケーションＩＤは唯一のものではない。意味を明解にするために説明すると、アプリケーション情報は、異なるアプリケーションが同じアプリケーションＩＤを使うべきではないという意味で、唯一のものである。しかし、同じアプリケーションＩＤは、プレゼンスサーバの中で異なるタプルに関連して何度も何度も提示されうる。タプルＩＤは唯一のものであるが、プレゼンティティのプレゼンス情報中の例えば２つ又は３つのタプルには、同じアプリケーションＩＤが存在する。それからアプリケーションＩＤはフィルタリングで使われることができる。すなわち、ウオッチャー（受信端末）は、ウオッチされているユーザ（プレゼンティティ）から全ての利用可能なプレゼンス情報を受け取らないように、フィルタを設定するかもしれない。このフィルタは、ウオッチャーが特定のアプリケーションのためのプレゼンス情報のみを受け取るために設定されるかもしれない。フィルタはあるプレゼンス情報やそれら２つの組み合わせをフィルタリングする。
【００３８】
例として、「ユーザ提供ロケーション」に関する全てのタプルが提供されるようにフィルタリングが選ばれているなら、次のようなタプルが（プレゼンティティからプレゼンスサーバに提供されていれば）ウオッチャーに提供される。
プレゼンティティ＝ＡＢＣ  
ＴＵＰＬＥ  １，  タプルＩＤ：ｘｙｚ３２２６，  アプリケーションＩＤ＝“ユーザ提供ロケーション”，  ユーザ提供ロケーション  ＝  タンペレ  
ＴＵＰＬＥ  ２，  タプルＩＤ：  ｘｙｂ３２９３，  アプリケーションＩＤ＝“ユーザ提供ロケーション”，  ユーザ提供ロケーション  ＝  ＨＯＭＥ  
ＴＵＰＬＥ  ３，  タプルＩＤ：  ｘｙａ３２８８，  アプリケーションＩＤ＝“ユーザ提供ロケーション”，  ユーザ提供ロケーション  ＝  ｘ座標，ｙ座標
図５を参照する。第１のプレゼンティティ３０がタプル１，２，３，４，５を提供している。各々のタプルはアプリケーションＩＤを持ち、タプル１と２はアプリケーションＩＤ“Ａ”、タプル３と４はアプリケーションＩＤ“Ｂ”、タプル５はアプリケーション“Ｃ”を持つ。ウオッチャー３２はアプリケーション“Ａ”のみを欲している。フィルタ３４はそこでタプルをフィルタリングし、ユーザ３２にタプル１と２のみを供給する。実際にはフィルタはプレゼンティティの一部、サーバ等の異なるエンティティの一部、ウオッチャー３２の一部でありうることは理解されねばならない。このように、アプリケーションＩＤはタプルをフィルタリングするために用いられる。
【００３９】
タプルは、異なるユーザを対象としているかもしれない。従って、タプル１，３，５はあるウオッチャーを対象とし、タプル２と５は他のウオッチャーを対象とするかもしれない。従ってウオッチャーはタプル１，３，５のみを“見る”ことができるかもしれない。従って、ウオッチャーがアプリケーション“Ａ”のタプルだけを欲する場合は、ウオッチャーはタプル１のみを供給されるだろう。フィルタ３４はこの更なるフィルタリングを提供する。本発明のある実施例においては、ウオッチャーが求めるタプルのみを得ることを確実にするため、独立のフィルタ又は指示手段が提供される。
【００４０】
利用可能なプレゼンス情報は、ウオッチャーグループによって異なることがあり得る。
【００４１】
本発明の実施態様は、アプリケーションが、その特定のアプリケーションがどんな情報を解釈でき理解できるのかをプレゼンス情報から簡単に認識することを可能とする。
【００４２】
本発明の実施態様では、フィルタリングを実行するとき、アプリケーション識別子がプレゼンスサーバに利用されうることは理解されねばならない。本発明のある実施態様では、オペレータ特有のアプリケーションが、やはりアプリケーションＩＤを利用するプレゼンスサーバに提供される。プレゼンスサーバは、例えばユーザがプレゼンスサーバへのアクセス権を与え、理解したタプルの中で、属性値を修正することができる。
【００４３】
本発明の実施態様はフィルタリングに用いられることができる。例えば、ウオッチャーは１つ以上の特定のアプリケーションに関するプレゼンス情報の一部だけを要求することができる。フィルタリングは、ウオッチされているプレゼンティティ（ユーザかプレゼンスサーバ）、ウオッチャー、又は他のいずれかのエンティティによって行なわれることができる。プレゼンス情報が特定のプレゼンティティから特定のウオッチャーへ提供されるとき、いつでも要求されるアプリケーションに従ってフィルタされるように、フィルタ情報は予め保管されていることができる。フィルタリングは、必要なアプリケーション、必要でないアプリケーション、又はこれらの技術の組み合わせを定めることができる。
【００４４】
上記のように、ウオッチャーは一般的に上で示したようなユーザである。“プレゼンティティ”は、そのユーザに関連しているユーザやプレゼンスサーバであることができる。プレゼンスサーバは、そのプレゼンスサーバに関連しているユーザのためにプレゼンス情報を格納する。実際には、各々のサーバには１つ以上のユーザが結びついていることは理解されねばならない。プレゼンスサーバは末端のデバイス（端末）に位置するかもしれない。
【００４５】
現在３ＧＰＰで定義されているプレゼンス情報は、次のような情報を含むことができる。（情報がこれらに限定されることはない。標準化作業のステージ１（必要条件グループ）からの要件は、可能なプレゼンスが拡張されるようにコンセプトを発展させることになっている。
【００４６】
加入者状態；  ネットワーク状態；  通信手段；  連絡先アドレス；  加入者提供ロケーション；  ネットワーク提供ロケーション；  テキスト；  優先度。
【００４７】
プレゼンスはまた、他にも気分や好みの色など情報を含むことができる。
【００４８】
本発明の実施例が、アプリケーション識別子と呼ばれる属性に限定されることはなく、似たような型の動作可能性を提供するいかなる属性にも提供できることは、理解されねばならない。
【００４９】
本発明の実施例はタプルの使用に限られていない。全てのシステムがプレゼンスドキュメントを構成するためにタプルを用いる訳ではなく、例えばワイヤレス・ビレッジ（Ｗｉｒｅｌｅｓｓ  Ｖｉｌｌａｇｅ）プレゼンスは、属性レベルでプレゼンス情報を取り扱い、このような場合はアプリケーションＩＤは各々別々の属性にリンクされる。
【００５０】
図４は、ＩＭＳネットワーク１００の概略図を示す。ＩＭＳは、いくつかの通話状態制御機能（ＣＳＣＦ）を含むいろいろな要素を含む。ＣＳＣＦは、ＩＥＴＦアーキテクチャにおけるＳＩＰサーバに等しい。
【００５１】
問い合わせＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ  ＣＳＣＦ，Ｉ−ＣＳＣＦ）２０１は、ＩＭＳネットワークで通話を終了するために使われる基本的なＩＭＳノードであり、ネットワークの末端で機能する。ここでは、それが外部のノードである携帯端末１０１，ＰＤＡ１１３，アプリケーションサーバ（ＡＳ）１２１と通信していることが示されている。携帯端末１０１やＰＤＡ１１３、アプリケーションサーバ（ＡＳ）１２１とＩ−ＣＳＣＦとの間の接続は直接ではないかもしれず、図１に示されるような、携帯端末のための携帯電話コアネットワーク１１０やアプリケーションサーバのためのインターネット１２０等の適当な中間ネットワークを経由した接続であるかもしれないことは、理解されるべきである。
【００５２】
ＨＳＳ２０２は、Ｉ−ＣＳＣＦとＳ−ＣＳＣＦ２０４との間のインターフェースとなる、集中ユーザデータベースであり、ＩＭＳの全てのユーザの情報を格納する。Ｉ−ＣＳＣＦは、新しいユーザの承認や、メッセージを外部要素からＳ−ＣＳＣＦまで送るための経路情報をＳ−ＣＳＣＦで検索するなどの機能を遂行するために、ＨＳＳを使う。
【００５３】
Ｓ−ＣＳＣＦは、ＩＭＳユーザに関連したサービスを開始することに対して責任を負うＩＭＳノードである。この例では、Ｓ−ＣＳＣＦもＩＭＳユーザのためにユーザ登録を処理する登録係の機能性を遂行する。プレゼンスサーバの機能性はアプリケーションサーバとして実装される。
【００５４】
図４の説明は単に略図であり、実際にはプロキシＣＳＣＦ（ｐｒｏｘｙ−ＣＳＣＦ，Ｐ−ＣＳＣＦ）など、別の要素が文から抜けていることは理解されねばならない。また、本発明の実施態様が図４に示されたもの以外のシステムにも使いうることは理解されねばならない。
【００５５】
色々なユーザのプレゼンス情報に登録するために、プレゼンスパッケージが用いられることができる。プレゼンスパッケージの語義は次のようなことを意味している。どんなユーザもプレゼンス情報のための登録メッセージをプレゼンスサーバに送ることができるが、もしそのようなプレゼンスパッケージが定義されていなければ、プレゼンスサーバはユーザがどのようなイベントを登録しようとしたのかを理解できないだろう。従って、プレゼンスパッケージはプレゼンスサーバで定められる必要がある。するとプレゼンスサーバは、プレゼンス情報を変化させる関連イベントのための登録メッセージを受信し認識することができる。プレゼンスサーバはプレゼンス状態にリンクされた状態を作り、プレゼンス情報に何らかの変化が起きると、それは反応や通知を行なう合図となる。
【００５６】
本発明の実施態様はＳＩＰを用いた３Ｇに関連して説明されたが、他の適当なシステムやインターフェースプロトコルも用いられうることは理解されねばならない。特に、本発明の実施態様は、ＩＥＴＦ仕様書に従うアプリケーションで用いられることができる。
【００５７】
更に、上に本発明の実施態様を例示的に説明したが、添付の特許請求の範囲に定められた本発明の範囲を逸脱せずに開示されたソリューションに対して適用しうる、いくつかのバリエーションや変形があることは、ここで注意しておかねばならない。
【図面の簡単な説明】
【００５８】
【図１】本発明が適用されうる通信システムを図示している。
【図２】本発明の実施例の概略を図示している。
【図３】更に詳細に図２の実施例を図示している。
【図４】図１のシステムのＩＭＳ一部を更に詳細に図示している。
【図５】本発明の実施例の概略を図示している。
【図１】
2006502641.tif 000003
【図２】
2006502641.tif 000004
【図３】
2006502641.tif 000005
【図４】
2006502641.tif 000006
【図５】
2006502641.tif 000007
【国際調査報告】
2006502641.tif 000008
2006502641.tif 000009
2006502641.tif 000010