(57)【要約】本発明は移動メッセージング及びプレゼンス・サービスに関する。本発明の1つの態様によれば、移動メッセージング・システムのクライアント装置は、属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する。プレゼンス属性を受信するクライアント装置は、受信した属性中の修飾子パラメータに応じて前記受信したプレゼンス属性を処理する。本発明の別の態様は、同じ役割のプレゼンス集合の全体または一部に加入する権利を有するメンバの関連する許可グループを有する役割内で単一のプレゼンス集合中の名称、属性及び値を有するプレゼンス項目をどのように組み立て格納するかを示すことである。
2004532478.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも1つのクライアント装置とサーバとを備える移動メッセージング・システムであって、
前記クライアント装置が、プレゼンス情報をプレゼンス属性として前記サーバに送信する手段と、プレゼンス属性を前記サーバから受信する手段とを備え、前記プレゼンス情報が、属性名称によって識別される複数のプレゼンス属性種類によって分類され、
前記サーバが、前記受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段を備える移動メッセージング・システムにおいて、
前記クライアント装置が、修飾子をプレゼンス属性に追加する手段であって、前記修飾子が前記の属性の使用を指定する1つかそれ以上のパラメータを含む手段を備え、
前記クライアント装置が、前記の受信した属性中の前記修飾子パラメータに応じて前記受信したプレゼンス属性を処理する手段を備えることを特徴とする移動メッセージング・システム。
【請求項２】
前記クライアント装置が、前記修飾子中で前記属性の表示設定を指定する手段を備え、
前記クライアント装置が、前記修飾子に基づいて前記受信した属性を提示する手段を備えることを特徴とする、請求項1に記載のシステム。
【請求項３】
前記クライアント装置が、前記修飾子中で前記属性のアドレス指定先となるアプリケーションを指定する手段を備え、
前記クライアント装置が、前記受信した属性を前記修飾子によって指示されるアプリケーションにアドレス指定する手段を備えることを特徴とする、請求項1に記載のシステム。
【請求項４】
前記サーバが、前記修飾子に基づいて前記属性を1つかそれ以上のクライアント装置に送信すべきかどうかを決定する手段を備えることを特徴とする、請求項1〜3の何れか一項に記載のシステム。
【請求項５】
少なくとも1つのクライアント装置とサーバとを備える移動メッセージング・システムであって、
前記クライアント装置が、プレゼンス情報をプレゼンス属性として前記サーバに送信する手段と、プレゼンス属性を前記サーバから受信する手段とを備え、前記プレゼンス情報が、属性名称によって識別される複数のプレゼンス属性種類によって分類され、
前記サーバが、受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段を備える移動メッセージング・システムにおいて、
前記クライアント装置が、オーソライザと、属性名称と、修飾子との組合せによって識別されるプレゼンス情報属性を構成する手段であって、前記オーソライザが前記属性を維持する責任を負う主体を指定し前記修飾子が前記属性の使用を指定する手段を備え、
前記サーバが、受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、前記受信した属性の識別子の組合せが前記すでに格納された属性のものと同一であれば前記すでに格納された属性を前記受信した属性によって置換し、そうでなければ前記受信した属性を追加する手段を備え、
前記クライアント装置が、受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、前記受信した属性の識別子の組合せが前記すでに格納された属性のものと同一であれば前記すでに格納された属性を前記受信した属性によって置換し、そうでなければ前記受信した属性を追加する手段を備えることを特徴とする移動メッセージング・システム。
【請求項６】
前記クライアント装置から前記サーバによって受信した前記プレゼンス属性が、プレゼンス・グループに関連する発行者ユーザに応じてデータベース中に格納されることを特徴とする、請求項1〜5の何れか一項に記載の移動メッセージング・システム。
【請求項７】
各プレゼンス属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項1〜6の何れか一項に記載の移動メッセージング・システム。
【請求項８】
前記属性名称要素が、前記属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする、請求項7に記載の移動メッセージング・システム。
【請求項９】
プレゼンス集合が、単一のプレゼンス・グループに関連する発行者ユーザの単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする、請求項1〜8の何れか一項に記載の移動メッセージング・システム。
【請求項１０】
前記クライアント装置のユーザが発行者として前記クライアント装置または1つより多い発行者役割で1つより多いクライアント装置を使用できることを特徴とする、請求項9に記載の移動メッセージング・システム。
【請求項１１】
移動メッセージング・システムのための移動クライアント装置であって、
属性名称によって識別される複数のプレゼンス属性種類によって分類されるプレゼンス情報をプレゼンス属性としてサーバに送信する手段を備える移動クライアント装置において、
前記属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する手段をさらに備えることを特徴とする移動クライアント装置。
【請求項１２】
移動メッセージング・システムのための移動クライアント装置であって、プレゼンス属性をサーバから受信する手段を備え、前記のプレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類される移動クライアント装置において、
修飾子をプレゼンス属性に追加する手段であって、前記修飾子が前記属性の使用を指定する1つかそれ以上のパラメータを備える手段と、
前記受信した属性中の前記の修飾子パラメータに応じて前記の受信したプレゼンス属性を処理する手段とをさらに備えることを特徴とする移動クライアント装置。
【請求項１３】
移動メッセージング・システムのための移動クライアント装置であって、プレゼンス情報をプレゼンス属性としてサーバに送信する手段と、
プレゼンス属性を前記サーバから受信する手段であって、前記プレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類される手段とを備える移動クライアント装置において、
オーソライザと、属性名称と、修飾子との組合せによって識別されるプレゼンス情報属性を構成する手段であって、前記オーソライザが前記属性を維持する責任を負う主体を指定し前記修飾子が前記属性の使用を指定する手段と、
受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、
前記受信した属性の識別子の組合せがすでに格納された属性のものと同一であれば前記すでに格納された属性を前記受信した属性によって置換し、そうでなければ前記受信した属性を追加する手段とをさらに備えることを特徴とする移動クライアント装置。
【請求項１４】
各プレゼンス属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項11〜13の何れか一項に記載の移動クライアント装置。
【請求項１５】
前記属性名称要素が、前記属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする、請求項14に記載の移動クライアント装置。
【請求項１６】
プレゼンス集合が、単一のプレゼンス・グループに関連する発行者ユーザの単一の発行者役割に属する1つかそれ以上のプレゼンス属性を備えることを特徴とする、請求項11〜15の何れか一項に記載の移動クライアント装置。
【請求項１７】
前記移動クライアント装置のユーザが発行者として前記クライアント装置または1つより多い発行者役割で1つより多いクライアント装置を使用できることを特徴とする、請求項16に記載の移動クライアント装置。
【請求項１８】
移動メッセージング・システムのためのサーバであって、前記サーバが、受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段を備え、前記プレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類されるサーバにおいて、
受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、
前記受信した属性の識別子の組合せが前記すでに格納された属性のものと同一であれば前記すでに格納された属性を前記受信した属性によって置換し、そうでなければ前記受信した属性を追加する手段とを備えることを特徴とするサーバ。
【請求項１９】
クライアント装置から前記サーバによって受信した前記プレゼンス属性が、プレゼンス・グループに関連する発行者ユーザに応じてデータベース中に格納されることを特徴とする、請求項18に記載のサーバ。
【請求項２０】
各プレゼンス属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項18または19に記載のサーバ。
【請求項２１】
前記属性名称要素が、該属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする、請求項20に記載のサーバ。
【請求項２２】
プレゼンス集合が、単一のプレゼンス・グループに関連する発行者ユーザの単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする、請求項18〜21の何れか一項に記載のサーバ。
【請求項２３】
前記サーバと通信し発行者の役目を果たすクライアント装置のユーザが、該クライアント装置または1つより多い発行者役割で1つより多いクライアント装置を使用できることを特徴とする、請求項22に記載のサーバ。
【請求項２４】
プレゼンス・システムであって、
プレゼンス・ユーザが発行者または加入者として前記のシステムと対話できるようにする少なくとも1つのプレゼンス・クライアントを有する少なくとも1つの物理装置と、
関連するプレゼンス・グループに応じて加入者によってアクセスするため発行者の属性のプレゼンス集合の有効な値を維持するサーバとを備えるプレゼンス・システム。
【請求項２５】
各属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項24に記載のプレゼンス・システム。
【請求項２６】
前記属性名称要素が、属性の使用法に関連する情報を有する修飾子を含むことを特徴とする、請求項25に記載のプレゼンス・システム。
【請求項２７】
前記属性名称要素が、該属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする、請求項26に記載のプレゼンス・システム。
【請求項２８】
プレゼンス集合が、単一のプレゼンス・グループに関連する単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする、請求項24〜27の何れか一項に記載のプレゼンス・システム。
【請求項２９】
前記システムと対話する前記ユーザが発行者として前記プレゼンス・クライアントまたは1つより多い発行者役割で1つより多いプレゼンス・クライアントを使用できることを特徴とする、請求項28に記載のプレゼンス・システム。
【請求項３０】
各属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項28に記載のプレゼンス・システム。
【請求項３１】
前記少なくとも1つの物理装置が移動物理装置であることを特徴とする、請求項24〜30の何れか一項に記載のプレゼンス・システム。
【請求項３２】
物理装置中に格納するためコンピュータ可読媒体中に組み込まれたコンピュータ・プログラムにおいて、
前記のプログラムが、関連する少なくとも1つのプレゼンス・グループに応じて1つかそれ以上の加入者によってアクセスするための属性の少なくとも1つのプレゼンス集合の発行者としてプレゼンス・ユーザがプレゼンス・システムと対話できるようにするプレゼンス・クライアント・プログラムであることを特徴とするコンピュータ・プログラム。
【請求項３３】
前記プログラムが、加入者がメンバであるプレゼンス・グループに関連する属性の少なくとも1つの集合への前記加入者としてプレゼンス・ユーザが前記プレゼンス・システムと対話できるようにすることを特徴とする、請求項32に記載のプレゼンス・クライアント・プログラム。
【請求項３４】
各属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項32または33に記載のプレゼンス・クライアント・プログラム。
【請求項３５】
前記属性名称要素が、属性の使用法に関連する情報を有する修飾子を含むことを特徴とする、請求項34に記載のプレゼンス・クライアント・プログラム。
【請求項３６】
前記属性名称要素が、該属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする、請求項35に記載のプレゼンス・クライアント・プログラム。
【請求項３７】
プレゼンス集合が、単一のプレゼンス・グループに関連する単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする、請求項32〜36の何れか一項に記載のプレゼンス・クライアント・プログラム。
【請求項３８】
前記のシステムと対話する前記のユーザが発行者として前記プレゼンス・クライアント・プログラムまたは1つより多い発行者役割で1つより多いプレゼンス・クライアント・プログラムを使用できることを特徴とする、請求項37に記載のプレゼンス・クライアント・プログラム。
【請求項３９】
各属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項37に記載のプレゼンス・クライアント・プログラム。
【請求項４０】
前記物理装置が移動物理装置であることを特徴とする、請求項32〜39の何れか一項に記載のプレゼンス・クライアント・プログラム。
【請求項４１】
内部に格納されたコンピュータ可読媒体中に組み込まれたコンピュータ・プログラムを有する物理装置において、前記のプログラムが、請求項32〜40の何れか一項に記載のプレゼンス・クライアント・プログラムであることを特徴とする物理装置。
【請求項４２】
物理装置に格納されるためにコンピュータ可読媒体中に組み込まれたデータ構造において、
該データ構造が、プレゼンス集合に関連するプレゼンス・グループに応じて加入者によってアクセスするため1つかそれ以上の発行者の属性の前記プレゼンス集合の有効な値を格納するプレゼンス・データベースであることを特徴とするデータ構造。
【請求項４３】
各属性が、属性名称要素及び属性値を含む項目の一部であることを特徴とする、請求項42に記載のデータ構造。
【請求項４４】
前記属性名称要素が、属性の使用法に関連する情報を有する修飾子を含むことを特徴とする、請求項43に記載のデータ構造。
【請求項４５】
前記属性名称要素が、該属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする、請求項44に記載のデータ構造。
【請求項４６】
プレゼンス集合が、単一のプレゼンス・グループに関連する単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする、請求項42〜45の何れか一項に記載のデータ構造。
【請求項４７】
前記物理装置と対話するユーザが発行者として、1つより多い発行者役割を発行するために前記データ構造を使用でき、各役割が別個のプレゼンス・グループに関連する別個のプレゼンス集合を有することを特徴とする、請求項42〜46の何れか一項に記載のデータ構造。
【請求項４８】
前記物理装置が移動装置であることを特徴とする、請求項42〜47の何れか一項に記載のデータ構造。
【請求項４９】
内部に格納されたコンピュータ可読媒体中に組み込まれたデータ構造を有する物理装置において、前記データ構造が、請求項42〜48の何れか一項に記載のプレゼンス・データ構造であることを特徴とする物理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおけるメッセージングに関し、特に、移動インスタント・メッセージング及びプレゼンス・サービスにおけるプレゼンス属性に関する。
【０００２】
インスタント・メッセージング・サービスは、エンドユーザに、高速で対話形の、主としてテキストによる通信を行う手段を提供する。インスタント・メッセージングの有用性は、ユーザのチャット・パートナーまたは「友人」のオンライン状態及び利用可能性を追跡すると共にその状態または利用可能性の変化をユーザに通知するサービスの追加によって大きく向上する。この種のサービスは「プレゼンス・サービス」と呼ばれる。一般に、プレゼンスは様々な手段を介してインスタント・メッセージング・サービスに接続されたユーザまたはクライアントに関する様々な動的情報を含むものと考えられる。この情報の例は、通信するユーザの到達可能性、利用可能性及び位置である。インスタント・メッセージングとプレゼンス・サービスの組合せはインスタント・メッセージング及びプレゼンス・サービス(IMPS)と呼ばれる。この種のサービスは有線インターネット・ユーザには利用可能であったが、有線ユーザと移動ユーザとの間の相互接続性は達成されていなかった。
【０００３】
ワイヤレス・ビレッジ(Wireless Village)・イニシアティブは移動インスタント・メッセージング及びプレゼンス・サービスについての仕様を規定するため設立された。ワイヤレス・ビレッジのインスタント・メッセージング及びプレゼンス・サービス(IMPS)には、プレゼンス、インスタント・メッセージング、グループ及び共有内容という4つの主要な機能が含まれる。共有内容によってユーザとオペレータとは、自分たちが画像、音楽及び他のマルチメディア内容を掲示することのできる固有の記憶領域を設定し、IMまたはチャット・セッションで他の個人及びグループと共有することができる。ワイヤレス・ビレッジ・イニシアティブによって、オペレータとエンドユーザとの両方がグループを生成し管理できるようになる。プレゼンスはワイヤレス・ビレッジ・イニシアティブにとって主要な実現技術である。インターネットによる既存のインスタント・メッセージング・サービスでは、プレゼンスの値は普通、ユーザがアクセスできる状態、不在、通信したくない、等といった非常に簡単なものである。こうした値が所定の値の集合から選択される。ワイヤレス・ビレッジの移動IMPSソリューションに関する白書「ワイヤレス・ビレッジ、移動IMPSイニシアティブ:白書(「Wireless Village,The Mobile IMPS Initiative:White Paper」)」2001年4月26日付が出版されている。既存の移動端末は、個人の状態をデスクトップ・コンピュータより正確に反映する個人ツールと考えられる。ユーザ及び移動端末から得られる情報の広範さを考慮すると、プレゼンス情報のドメインを予想することは非常に困難である。従って、新しい種類のプレゼンス情報を容易に使用及び追加することのできる機構を開発する必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、すでに決定されたプレゼンス属性の他に新しいプレゼンス属性を生成するソリューションを提供することである。
【０００５】
本発明の別の目的は、クライアントが使用するプレゼンス属性をどのように編成し格納するかを示すことである。
【課題を解決するための手段】
【０００６】
本発明の第1の態様によれば、移動メッセージング・システムのクライアント装置は、属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する。プレゼンス属性を受信するクライアント装置は、受信した属性中の修飾子パラメータに応じて受信したプレゼンス属性を処理する。プレゼンス属性はあるユーザ及び/またはクライアント装置に関するプレゼンス情報を記述するデータの集まりであり、そのプレゼンス情報は他のユーザを対象としたものである。また、プレゼンス情報はクライアント装置間のマシン同士の通信に関する情報を含んでもよい。
【０００７】
さらに、本発明の第1の態様によれば、少なくとも1つのクライアント装置とサーバとを備える移動メッセージング・システムであって、クライアント装置がプレゼンス情報をプレゼンス属性としてサーバに送信する手段とプレゼンス属性をサーバから受信する手段とを備え、そのプレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類され、サーバが受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段を備える移動メッセージング・システムは、クライアント装置が属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する手段を備え、クライアント装置が受信した属性中の修飾子パラメータに応じて受信したプレゼンス属性を処理する手段を備えることを特徴とする。
【０００８】
本発明の第2の態様によれば、クライアント装置は、オーソライザ(authorizer)、属性名称及び修飾子の組合せによって識別されるプレゼンス情報属性を構成し、その際オーソライザが属性の維持に責任を負う主体を指定し、修飾子が属性の使用を指定する。プレゼンス属性を受信すると、サーバ及びクライアント装置は、受信した属性と同じ識別子を含むすでに格納された属性を探索する。受信した属性の識別子の組合せがすでに格納された属性のものと同一であれば、すでに格納された属性を受信した属性によって置換する。そうでなければ、以前の属性を置換せずに受信した属性を追加する。
【０００９】
さらに、本発明の第2の態様によれば、少なくとも1つのクライアント装置とサーバとを備える移動メッセージング・システムであって、クライアント装置がプレゼンス情報をプレゼンス属性としてサーバに送信する手段とプレゼンス属性をサーバから受信する手段とを備え、プレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類され、サーバが受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段を備える移動メッセージング・システムは、クライアント装置が、オーソライザ、属性名称及び修飾子の組合せによって識別されるプレゼンス情報属性を構成し、オーソライザが属性の維持を担当する主体を指定し修飾子が属性の使用を指定し、サーバが、受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、受信した属性の識別子の組合せがすでに格納された属性のものと同一であればすでに格納された属性を受信した属性によって置換しそうでなければ受信した属性を追加する手段とを備え、クライアント装置が、受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、受信した属性の識別子の組合せがすでに格納された属性のものと同一であればすでに格納された属性を受信した属性によって置換しそうでなければ受信した属性を追加する手段とを備えることを特徴とする。
【００１０】
さらに、本発明の第1及び第2の態様によれば、本システムは、クライアント装置が、属性の提示設定を修飾子中で指定する手段を備え、クライアント装置が、修飾子に基づいて受信した属性を提示する手段を備えることを特徴とする。
【００１１】
またさらに、本発明の第1及び第2の態様によれば、本システムは、クライアント装置が、属性のアドレス指定先となるべきアプリケーションを修飾子中で指定する手段を備え、クライアント装置が、受信した属性を修飾子によって示されるアプリケーションにアドレス指定する手段を備えることを特徴とする。
【００１２】
またさらに、本発明の第1及び第2の態様によれば、本システムは、サーバが、修飾子に基づいて属性を1つかそれ以上のクライアント装置に送信すべきかを決定する手段を備えることを特徴とする。
【００１３】
さらに、本発明の第1及び第2の態様によれば、本システムは、クライアント装置からサーバによって受信されたプレゼンス属性が、プレゼンス・グループに関連する発行者ユーザに応じてデータベースに格納されることを特徴とする。
【００１４】
またさらに、本発明の第1及び第2の態様によれば、本システムは、各プレゼンス属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする。属性名称要素は、属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含んでもよい。
【００１５】
またさらに、本発明の第1及び第2の態様によれば、本システムは、プレゼンス集合が、単一のプレゼンス・グループに関連する発行者ユーザの単一の発行者役割(publisher role)に属する1つかそれ以上の属性を備えることを特徴とする。
【００１６】
またさらに、本発明の第1及び第2の態様によれば、移動メッセージング・システムは、クライアント装置のユーザが発行者としてそのクライアント装置または1つより多い発行者役割における1つより多いクライアント装置を使用できることを特徴とする。
【００１７】
本発明の第3の態様によれば、移動メッセージング・システムのための移動クライアント装置であって、そのクライアント装置がプレゼンス情報をプレゼンス属性としてサーバに送信する手段を備え、そのプレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類される移動クライアント装置は、そのクライアント装置がさらに、属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する手段を備えることを特徴とする。
【００１８】
本発明の第4の態様によれば、移動メッセージング・システムのための移動クライアント装置であって、そのクライアント装置がプレゼンス属性をサーバから受信する手段を備え、そのプレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類される移動クライアント装置は、そのクライアント装置がさらに、属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する手段と、受信した属性中の修飾子パラメータに応じて受信したプレゼンス属性を処理する手段とを備えることを特徴とする。
【００１９】
本発明の第5の態様によれば、移動メッセージング・システムのための移動クライアント装置であって、そのクライアント装置が、プレゼンス情報をプレゼンス属性としてサーバに送信する手段と、プレゼンス属性をサーバから受信する手段とを備え、そのプレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類される移動クライアント装置は、そのクライアント装置がさらに、オーソライザ、属性名称及び修飾子の組合せによって識別されるプレゼンス情報属性を構成する手段であって、オーソライザが属性の維持に責任を負う主体を指定し、修飾子が属性の使用を指定する手段と、受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、受信した属性の識別子の組合せがすでに格納された属性のものと同一であればすでに格納された属性を受信した属性によって置換しそうでなければ受信した属性を追加する手段とを備えることを特徴とする。
【００２０】
さらに、本発明の第3、第4及び第5の態様によれば、本移動クライアント装置は、各プレゼンス属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする。属性名称要素は、属性名称要素及び属性値を一意に保持する責任を負う権限を示する権限文字列を含んでもよい。
【００２１】
さらに、本発明の第3、第4及び第5の態様によれば、本移動クライアント装置は、プレゼンス集合が、単一のプレゼンス・グループに関連する発行者ユーザの単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする。
【００２２】
またさらに、本発明の第3、第4及び第5の態様によれば、本移動クライアント装置は、クライアント装置のユーザが発行者としてそのクライアント装置または1つより多い発行者役割における1つより多いクライアント装置を使用できることを特徴とする。
【００２３】
本発明の第6の態様によれば、移動メッセージング・システムのためのサーバであって、そのサーバが受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段を備え、そのプレゼンス情報が属性名称によって識別される複数のプレゼンス属性種類によって分類されるサーバは、そのサーバがさらに、受信した属性と同じ識別子を含むすでに格納された属性を探索する手段と、受信した属性の識別子の組合せがすでに格納された属性のものと同一であればすでに格納された属性を受信した属性によって置換しそうでなければ受信した属性を追加する手段とを備えることを特徴とする。
【００２４】
さらに、本発明の第6の態様によれば、本サーバは、クライアント装置からサーバによって受信されたプレゼンス属性が、プレゼンス・グループに関連する発行者ユーザに応じてデータベース中に格納されることを特徴とする。
【００２５】
またさらに、本発明の第6の態様によれば、本サーバは、各プレゼンス属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする。属性名称要素は、属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含んでもよい。
【００２６】
またさらに、本発明の第6の態様によれば、本サーバは、プレゼンス集合が、単一のプレゼンス・グループに関連する発行者ユーザの単一の発行者役割に属する1つかそれ以上のプレゼンス属性を備えることを特徴とする。サーバと通信し発行者の役目を果たすクライアント装置のユーザはそのクライアント装置または1つより多い発行者役割における1つより多いクライアント装置を使用できる。
【００２７】
本発明の第7の態様によれば、プレゼンス・システムは、プレゼンス・ユーザが発行者または加入者としてシステムと対話できるようにする少なくとも1つのプレゼンス・クライアントを有する少なくとも1つの物理装置と、関連するプレゼンス・グループに応じて加入者がアクセスする発行者の属性のプレゼンス集合の有効な値を維持するサーバとを備える。
【００２８】
さらに、本発明の第7の態様によれば、プレゼンス・システムは、各属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする。属性名称要素は、属性の使用に関する情報を有する修飾子を含んでもよい。属性名称要素は、属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含んでもよい。
【００２９】
またさらに、本発明の第7の態様によれば、本プレゼンス・システムは、プレゼンス集合が、単一のプレゼンス・グループに関連する単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする。発行者としてシステムと対話するユーザは、プレゼンス・クライアントまたは1つより多い発行者役割における1つより多いプレゼンス・クライアントを使用できる。各属性は、属性名称要素及び属性値を含む項目の一部であってもよい。
【００３０】
またさらに、本発明の第7の態様によれば、少なくとも1つの物理装置は移動物理装置である。
【００３１】
本発明の第8の態様によれば、物理装置に格納するためコンピュータ可読媒体内に組み込まれたコンピュータ・プログラムは、そのプログラムが、関連する少なくとも1つのプレゼンス・グループに応じて1つかそれ以上の加入者がアクセスする属性の少なくとも1つのプレゼンス集合の発行者としてプレゼンス・ユーザがプレゼンス・システムと対話できるようにするプレゼンス・クライアント・プログラムであることを特徴とする。
【００３２】
さらに、本発明の第8の態様によれば、本プレゼンス・クライアント・プログラムは、このプログラムが、加入者がメンバであるプレゼンス・グループに関連する属性の少なくとも1つの集合への加入者としてプレゼンス・ユーザがプレゼンス・システムと対話できるようにすることを特徴とする。
【００３３】
またさらに、本発明の第8の態様によれば、本プレゼンス・クライアント・プログラムは、各属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする。属性名称要素は属性の使用に関する情報を有する修飾子を含んでもよい。
【００３４】
さらに、本発明の第8の態様によれば、本プレゼンス・クライアント・プログラムは、属性名称要素が属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含むことを特徴とする。
【００３５】
またさらに、本発明の第8の態様によれば、本プレゼンス・クライアント・プログラムは、プレゼンス集合が、単一のプレゼンス・グループに関連する単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする。システムと対話するユーザは発行者としてプレゼンス・クライアント・プログラムまたは1つより多い発行者役割における1つより多いプレゼンス・クライアント・プログラムを使用できる。各属性は、属性名称要素及び属性値を含む項目の一部であってもよい。
【００３６】
またさらに、本発明の第8の態様によれば、本プレゼンス・クライアント・プログラムは、物理装置が移動物理装置であることを特徴とする。
【００３７】
本発明の第9の態様によれば、内部に格納されたコンピュータ可読媒体中に組み込まれたコンピュータ・プログラムを有する物理装置は、そのプログラムが本発明の第8の態様に従うプレゼンス・クライアント・プログラムであることを特徴とする。
【００３８】
本発明の第10の態様によれば、物理装置中に格納するためコンピュータ可読媒体に組み込まれたデータ構造は、そのデータ構造が、プレゼンス集合に関連するプレゼンス・グループに応じて加入者がアクセスするため1つかそれ以上の発行者の属性のプレゼンス集合の有効な値を格納するプレゼンス・データベースであることを特徴とする。
【００３９】
さらに、本発明の第10の態様によれば、データ構造は、各属性が属性名称要素及び属性値を含む項目の一部であることを特徴とする。属性名称要素は、属性の使用に関する情報を有する修飾子を含んでもよい。属性名称要素は、属性名称要素及び属性値を一意に保持する責任を負う権限を示す権限文字列を含んでもよい。
【００４０】
またさらに、本発明の第10の態様によれば、プレゼンス集合は、単一のプレゼンス・グループに関連する単一の発行者役割に属する1つかそれ以上の属性を備えることを特徴とする。
【００４１】
またさらに、本発明の第10の態様によれば、データ構造は、物理装置と対話するユーザが発行者として1つより多い発行者役割を発行するためデータ構造を使用することができ、各役割は別個のプレゼンス・グループに関連する別個のプレゼンス集合を有することを特徴とする。
【００４２】
またさらに、本発明の第10の態様によれば、データ構造は、物理装置が移動装置であることを特徴とする。
【００４３】
本発明の第11の態様によれば、内部に格納されたコンピュータ可読媒体中に組み込まれたデータ構造を有する物理装置は、そのデータ構造が本発明の第10の態様に従うプレゼンス・データベースであることを特徴とする。
【発明の効果】
【００４４】
本発明の利点は、修飾子を追加することによって所定のプレゼンス属性の調整が可能なことである。修飾子を使用して新しい属性を追加してもよい(修飾子を伴う属性は一意に識別できる、すなわち属性名称が同じだが修飾子のない属性と機能的に分離できるため)。すなわち、例えばユーザまたはアプリケーション開発者は、所定の種類に制限されることなく、自分たちの要求に最も適合するかまたは現在の実際の状態を記述する新しいプレゼンス属性を容易に決定できる。修飾子によってプレゼンス情報の送信者(所有者)は受信クライアント装置でプレゼンス情報をどのように使用するかを指定できるようになるので、修飾子を使用することによって別の利点がもたらされる。
【００４５】
本発明の1つの実施例では、属性のアドレス指定先となるアプリケーションは修飾子で指定される。受信された属性は修飾子で示されたアプリケーションにアドレス指定される。本実施例のさらなる利点は、送信側クライアント装置は使用されるアプリケーションを規定してもよく、それによってあるプレゼンス情報をあるアプリケーションに送るため修飾子を使用してもよいということである。
【００４６】
本発明の別の利点は、同じ役割のプレゼンス集合の全体または一部に加入する権利を有するメンバの関連する許可グループを有する役割内で単一のプレゼンス集合中の名前、属性及び値によってどのようにプレゼンス項目を組み立てるかを示すことである。
【００４７】
以下、本発明は好適実施例により添付の図面を参照してさらに詳細に説明される。
【発明を実施するための最良の形態】
【００４８】
図1は、移動IMPSシステムを示す。いくつかの移動クライアント(MC)は移動ネットワークMNWと場合によっては1つかそれ以上の中間ネットワークONWとを介してIMPSサーバSに接続される。典型的には中間ネットワークとしてインターネットが使用されるので、非移動クライアントCがIMPSシステムによるサービスを提供されることもある。IMPSサーバSは、プレゼンス・サービスに関して、プレゼンス情報を所有する発行側クライアントのためのホーム・サービス要素である発行者サーバPSと、加入側または要求側クライアントのためのホームである加入者サーバSSというサーバ要素に機能的に分割できる。従って、クライアントMCは両方のサーバからサービスを提供される。すなわち、MCはPSに対してそのプレゼンス情報を更新して発行側クライアントの役目を果たし、その一方で、加入者サーバSSから、他のクライアントに関するプレゼンス情報をプレゼンス属性として要求し受信する。サーバPSは、プレゼンス情報に関するユーザの発行上の選択に基づいてプレゼンス・データを維持しその分配を管理する。SS及びPSの機能は1つの物理サーバ装置上で実行してもよくまた複数のサーバ装置に分配してもよい。
【００４９】
この説明はプレゼンス関連サービス機能に主眼を置いていることに注意されたい。他の重要な移動IMPSサービス機能としてメッセージング機能、ユーザ・グループ管理機能、内容管理機能、加入者管理機能、及びクライアント機能がある。移動IMPSサービスはこうしたサービス機能を使用することによってもたらされる。例えば、クライアントMCはいくつかのユーザ・グループに属してもよく、サーバSはグループのメンバ構成を管理し、インスタント・メッセージングを処理し、グループのメンバ間でプレゼンス情報を配信する。また、サーバの1つの重要な役割は情報フローの制御である。すなわち、サーバは、例えばプレゼンスまたは他の情報のうち、「友人」のグループのメンバに配信してよいものと、「仕事の同僚」のグループのメンバに配信してよいものと、また任意のクライアントに公開してよいものとを規定する、ユーザの選択に基づくフィルタを有してもよい。
【００５０】
様々なトランスポート層プロトコルが使用可能であり、典型的にはIPプロトコルを使用してネットワーク層サービスを提供する。様々な下位層伝送プロトコルを使用してもよい。移動ネットワークMNWは、GSMサービスをサポートするセルラ・ネットワーク、GPRSサービス(汎用パケット無線サービス)をサポートするネットワーク、UMTSネットワーク(ユニバーサル移動通信システム)のような第3世代移動通信ネットワーク、無線ローカルエリア・ネットワークWLANまたは私設ネットワークといった任意の無線ネットワークでよい。また、ブルートゥース(BluetoothTM)通信のような短距離赤外線または無線接続を、MCとサーバSとの間の通信経路の一部として使用してもよい。移動クライアント装置MCは、例えば移動局、PDA装置、または無線モデムを備えているかまたはそれに接続されたラップトップ・コンピュータでもよい。移動IMPSメッセージは、例えば回線交換データ呼、パケット交換データ伝送コンテキスト、SMSまたはMMS(マルチメディア・メッセージング・サービス)といったメッセージング・サービスを使用して転送すればよい。図2は、プレゼンス属性の使用法を示す。移動クライアントMCは、発行すべき1つかそれ以上のプレゼンス属性を決定すると(201)、発行者サーバPSに対してプレゼンス属性の更新を行う(202)、すなわち、1つかそれ以上のプレゼンス属性を発行する。プレゼンス属性の決定(201)は、何らかのプレゼンス情報が変更された時、自動的にかまたはユーザの意志によって、クライアントが移動IMPSサーバとの論理移動IMPSセッションを確立する時なされる。例えば、段階201は、所定の時間、データの時点で自動的に開始してもよく、移動クライアントMCでのユーザ・プロファイルの変更によって開始してもよい。クライアントMC(A)は、サーバSSの移動IMPSサービスにアクセスする時、別のクライアント(B)のプレゼンス情報を要求してもよい(203)。加入者サーバSSは発行者サーバPS(クライアントAの)からのこの情報を要求する(204)。これが発行の選択(クライアントBの)によって許可されると、PSは1つかそれ以上のプレゼンス属性をSSに送信する(205)。クライアントBが発行の選択を設定することで、要求された情報の一部の(クライアントA宛、または一般的な)送信を阻止することが可能である。また、クライアントがSSのサービスとの論理接続を確立する時、SSはユーザの選択(Aの)に基づいてプレゼンス情報を自動的に要求してもよい(204)。SSはプレゼンス属性を受信側クライアントMC(A)に転送する(206)。
【００５１】
加入者サーバSS(及び発行サーバPS)は典型的には変更されていないクライアントに対してクライアントに起源を有するプレゼンス属性を送信する。しかし、サーバPSに実装された内容適応機構が存在することもある。内容適応は、受信側クライアントのクライアント機能と調和するような形でプレゼンス属性を変更するという課題を扱う。クライアントからの要求に対する応答としてプレゼンス情報を送信することに加えて、発行の選択に応じてプレゼンス情報を利用可能なクライアントMC(サービスに論理的に接続された)に送りつけることも可能である。この送りつけるやり方のプレゼンス通知は、発行者サーバが発行者クライアントから更新を受信する場合、発行者サーバが属性値の変化を検出する場合、または値を更新する実装に特有の内部トリガによりといった3つの機構によってトリガすればよい。
【００５２】
従って、クライアントMCは、PSに対して1つかそれ以上のプレゼンス属性を更新し、SSからプレゼンス属性を受信及び処理し(207)、少なくとも1つのプレゼンス属性から得たプレゼンス情報をユーザに提示するよう構成されている。MCは好適には、プレゼンス属性を伝えるために使用される更新メッセージ中の新しいプレゼンス属性値が受信される(またはクライアントが移動IMPSセッションを終了する)までプレゼンス情報(プレゼンス属性値)を格納する。さらに、後でより詳細に示されるように、クライアント装置は自動的に受信したプレゼンス情報を利用してその機能をしかるべく調整してもよい。図2に示されるシグナリングに加えて、プレゼンス属性を要求側クライアントに送信する前に、プレゼンス情報の発行者から許可を要求してもよい。図2は、例えばメッセージ202の後でサーバが応答しうる状態メッセージを示していない。
クライアント起源のプレゼンス属性とは、値フィールドが発行側クライアントによって満たされたものである。サーバ起源のプレゼンス属性とは、値フィールドが発行者サーバによって満たされたものである。プレゼンス属性のある部分がクライアントによって満たされ残りの部分が発行者サーバによって満たされている場合、そのプレゼンス属性はクライアント-サーバ起源である。本発明の好適実施例によれば、ユーザまたは組織は所定の集合の属性の他に新しいプレゼンス属性を規定してもよい。プレゼンス属性は以下の種類に分類できる。
-クライアント状態:通信するためのクライアント装置の利用可能性を記述するプレゼンス属性。例えば、ネットワークの到達可能性、GPRS接続、オン/オフ状態、オペレータ。従って、移動IMPSサービスにおけるこれらの属性は、非移動クライアント装置のために使用されるIMPSのものとは大きく異なっている。
-ユーザ状態:通信するためのユーザの利用可能性を記述するプレゼンス属性。例えば、準備完了、会議中、手が離せない、不在、電話中、チャット中、就寝中。
-地域情報:ユーザのいる地域の環境を記述するプレゼンス属性。例えば、現地時間、騒々しい/静かな環境、室内、室外、例えば、地理的位置、訪問先PLMN、都市/通り、施設といったユーザの所在地。例えば、移動クライアントの正確な位置は地域情報属性について直接得られ、利用可能性状態(会議中、夏季別荘に滞在中、等)は移動クライアントMCのユーザ・プロファイル設定を介して容易に得られる。
-個人状態:個人ユーザ状態を記述する様々な個人属性。例えば、気分、個人の関心及び意図。
-クライアント機能:様々な通信手段、様々な媒体種類、及び様々な特徴をサポートするクライアント装置の機能を記述するプレゼンス属性。
-ユーザ属性:クライアント装置またはユーザが自己のテキスト・プレゼンス値及び外部値に対する参照を規定できるようにするプレゼンス属性。
-拡張プレゼンス情報:ベンダ特定であるかまたはサービス・プロバイダが動的に規定する非標準プレゼンス属性であるが、それにもかかわらず標準プレゼンス・サーバを通じて伝える必要があるもの。
すなわち、移動クライアント装置及び実際のユーザについて様々なプレゼンス属性が存在しうる。例えば、ユーザをメッセージを受信できるものとして規定せず、ユーザのクライアント装置をオンラインになっているものとして規定してもよい。また、SMSがベアラとして使用されている場合、ユーザはメッセージを受信することはできるがオンラインではないものとして規定してもよい。
【００５３】
プレゼンス属性の一般構造及び識別
表1はプレゼンス属性の一般構造を記述する。プレゼンス属性は一般に識別子部分と複数の値フィールドとを備えている。Reqフィールドはその要素が必須Mか、随意選択Oか、または条件付きCかを決定する。属性情報はXMLフォーマット(拡張可能マークアップ言語)である。
【００５４】
【表１】
2004532478.tif 000003
【００５５】
NameSpec要素の下位要素を表2に記述する。
【００５６】
【表２】
2004532478.tif 000004
【００５７】
属性の名称は「Name」という情報要素によって与えられる文字列である。Name情報要素は表3で規定されるフォーマット中の全てのプレゼンス属性について規定される。
【００５８】
【表３】
2004532478.tif 000005
【００５９】
Qualifier要素のフォーマットを表4に示す。
【００６０】
【表４】
2004532478.tif 000006
【００６１】
Qualifier要素を使用して、属性使用の範囲を指定する。修飾子は特に、新しい属性を追加するか、またはプレゼンス情報の送信者(発行者)が受信側クライアント装置でプレゼンス情報をどのように使用すべきかを指定できるようにする、という2つの目的のために使用できる。すなわち、修飾子文字列は、受信側クライアント装置における1つかそれ以上のアプリケーションについてのパラメータとして使用してもよい。
【００６２】
例えば、発行者が自分の正確な所在地(例えば通りの番地)を知るのは一部のユーザだけ(グループAと呼ぶ)に制限し、他のユーザ(グループBと呼ぶ)にはより大まかな住所(例えば都市名だけ)を知らせるようにしたい場合、発行者は都市名を含めた位置属性をグループBに対して発行すればよい。グループAに対しては、発行者はQualifier(例えば「私の親友」といった)を位置属性に添付する。これによって事実上、Qualifier「私の親友」を持った新しい属性が生成される。次に発行者はこの新しい属性に通りの名称を含め、それをグループAに対して発行する。属性が異なっているので、サーバPSは両者の値を区別することができる。また、ある人物がグループAとBとの両方に属する場合、この人物のクライアント装置はこれらの2つの属性を区別するよう設定できる。クライアント装置は、ユーザが起動したグループに応じて属性を提示(及び場合によっては利用)するよう設定してもよい。ありうるQualifierの値はクライアント及びサービス・プロバイダが事前割当してもよく、またユーザ(発行者)が動的に割当てもよい。また、サービス・プロバイダは動的に割当てられるQualifierの値の数を制限してもよい。
【００６３】
権限要素は属性とその内容を一意に保持する責任を負う主体を決定する。これは属性拡張機構に関する。
【００６４】
【表５】
2004532478.tif 000007
所定のプレゼンス属性が変更されずに使用されている場合、Authority文字列は省略できる。Qualifier文字列を使用してもAuthority要素の使用を必要とする属性は変更されない。Qualifier文字列は、新しい属性(新しいName)を導入する時か、または新しい値フィールドをすでに指定された属性に追加する時使用しなければならない。どちらの場合でも、属性は新しいものとみなされAuthorityはこの新しい属性を維持する責任を負う。
一般に、値フィールド名称は属性内で一意でなければならない。すなわち、新しい値フィールドを既存の属性に導入することは、その属性を規定した主体によって設定された規則によって処理されなければならない。新しい値フィールドを追加することによって古い属性は新しいものに変換される。新旧の属性を共存させるため、Authorityフィールドのプレゼンスはこのことをシグナリングしなければならない。また、出資者が公開維持のため属性を開放することもありうる。この種の属性はIANA(インターネット・アサインド・ナンバー・オーソリティ)のような適切な公共機関によって登録され、やはりAuthorityフィールドでシグナリングされる。この場合、任意の出資者は、Authorityフィールドを変更する必要なしに属性についての追加値フィールドを登録してもよい。サーバ(PS、SS)は、値フィールドの意味が理解できない時でも、属性から値フィールドを除去しない。クライアントMCは属性中の理解できない値フィールドは全て無視する。
【００６５】
属性は要素NameSpecによって識別され一意とされる。図3は、NameSpec要素及び修飾子の使用の例を示す。クライアント装置MC1のある属性について修飾子が決定される(301)。ユーザが修飾子を決定することも、クライアント装置MCがそれを決定することもありうる。望ましいユーザ・グループを指定し、受信側クライアント装置(MC2)でのプレゼンス情報の提示方法を決定し、あるいはそうでなければ受信側クライアント装置MC2による属性の使用方法を指定するために修飾子を使用してもよい。修飾子を決定する際移動クライアントMCのユーザ・プロファイルを利用できる。例えば、MC1は現在のプロファイル(例えば会議中)、カレンダー・エントリ(会議は12:00に終了)及び現地時間に基づいてプレゼンス属性を構成する。修飾子を使用することによって、プレゼンス属性は受信側クライアントMC2にとって有用な情報を含むよう容易に変更できる。属性はサーバPSに送信される(302)。
【００６６】
PSは受信した属性のNameSpec要素を格納された属性と比較する(303)。PSはまずAuthority文字列を互いに比較する。Authority文字列を含まない属性はAuthority文字列を含むいかなる属性とも異なっている。次に、属性名称を比較する。最後にQualifier文字列を比較する。Qualifier文字列を含まない属性はQualifier文字列を有するいかなる属性とも異なっている。2つの属性が同じなのは、これら3つの比較が全て同じ結果を出した時だけである。すなわち、修飾子を有する受信した属性を、同じ属性名称を有するが異なった修飾子を有する属性と機能的に分離することが可能である。
【００６７】
発行サーバPSはこの種の比較を行い、受信した属性の値フィールドは何れかの既存のプレゼンス情報を置換するものか、またその属性はMC2のプレゼンス情報記憶装置に追加すべき新しいものかを決定する。この比較に基づいて、PSは受信した属性中の情報を格納する(303)。前記受信した属性の全ての識別子がすでに格納された属性のものと同じであれば、PSはすでに格納された属性の前のプレゼンス情報を前記受信した属性のプレゼンス情報によって置換する。そうでなければ、PSは、前の情報を置換せず、前記受信した属性のプレゼンス情報を追加する。PSはその属性を少なくとも1つのクライアント装置MC2に送信する(304)(自動的に、またはMC2からの要求に応じて送りつける)。1つの実施例によれば、修飾子は属性の送り先となるグループを決定する。さらに、例えば電話帳の私用連絡先と公用連絡先でプレゼンス情報の提示方法を変えるため、修飾子を使用してもよい。すなわち、PSは修飾子に基づいて受信側クライアント装置を決定してもよい。動的電話帳サービスのサービス機能は、まずクライアント状態属性、ユーザ状態属性及び個人状態属性をさらに十分に以下で説明した後に説明する。
【００６８】
また、受信側クライアントは、PSの場合と同様の比較を行った(305)後で、受信したプレゼンス属性を格納する必要の有無、またその方法を決定する。プレゼンス属性のこの種の３つから成る識別によって、プレゼンス属性の非常に柔軟な使用、管理、及び生成が可能になる。
【００６９】
修飾子を使用してクライアント装置MC2における属性の使用を指定する多くの方法が存在する。典型的には、クライアント装置MCは複数のアプリケーションをサポートできる。第1の実施例によれば、クライアント装置MC1は使用すべきアプリケーションを指定する修飾子を追加する。アプリケーションとは一般に、例えばポート番号によって識別できる任意のアプリケーション・エンティティを指す。このアプリケーションはクライアント装置MC1で属性のプレゼンス情報を処理したものと同じものでもよく、別のアプリケーションでもよい。受信側クライアント装置MC2は受信した属性を修飾子が指示するアプリケーションにアドレス指定する(305)。例えば、修飾子を使用して、同じプレゼンス情報を電話帳アプリケーションとゲーム・アプリケーションとに送信してもよい。これらのアプリケーションはプレゼンス情報を異なった形で使用しうるので、アプリケーションの必要に応じて属性を正確に調整することも可能である。
【００７０】
第2の実施例によれば、クライアント装置MC1は属性の提示を指定する修飾子を追加する。受信側クライアント装置MC2は、その修飾子に基づいて受信した属性を提示する(305)。修飾子は、例えば、情報全てをユーザに示すべきか否か、又は情報のどの部分を示すべきかを決定してもよい。また、修飾子は、色、フォント等の様々なユーザ・インタフェース設定を決定してもよい。すなわち、MC2のUIは修飾子中の設定に基づいて設定される(305)。
【００７１】
クライアント状態属性
好適実施例によれば、移動クライアントMCは、移動クライアントMCの現在の伝送機能を記述するプレゼンス属性を利用する。この種の属性の構造を表6に示す。この属性は、モデム属性と呼ばれ、移動ベアラを取り扱うユーザ端末部分または機能に関するプレゼンス情報を提供する。
【００７２】
【表６】
2004532478.tif 000008
【００７３】
【表７】
2004532478.tif 000009
【００７４】
表8に示されるStatus値フィールドは移動モデムの状態を示す。
【００７５】
【表８】
2004532478.tif 000010
【００７６】
Status値フィールドはモデムの電源が入っているか否かを示す。好適実施例によれば、プレゼンス属性には、好適には属性の必須Status値フィールド中にあるDIS指示が含まれる。属性中にDISが設定されると、その属性中で与えられた全ての値は無効になる。従って、受信側移動クライアントMCはその属性の値フィールドを無視することができる。また、そのプレゼンス属性の前の値も削除される(及びゼロにされる)。すなわち、DIS指示を有するが他の値フィールドのない属性を送信するのが効果的である。この種の属性が必要とする空間は非常に小さいので、無線インタフェース上の必要な帯域幅を節約できる。特にユーザ属性を記述する属性の場合、このことは特に有用である。
【００７７】
再び表7を参照すると、モデム属性のCommAddr値フィールドにはモデム(MC)の通信アドレスが含まれる。これは、通信手段と連絡先アドレスという2つの部分を含む。手段部分は、サポートされる通信方法、特に、モデムがパケット交換(PS)データ、回線交換(CS)データまたは音声、SMSまたはMMSのどれをサポートするかに関する情報を伝える。連絡先部分にはアドレス、例えばMSISDN番号が含まれる。
【００７８】
CS_Status値フィールドは、モデムの回線交換状態(登録または未登録)を示す。PS_Status値フィールドは、モデムのパケット交換状態(接続または未接続)を示す。RoamingStatus値フィールドはホームPLMN(公衆陸上移動ネットワーク)と、場合によってはモデムが現在ローミングしているPLMNとを示す。CS_CallStatus値フィールドはCSベアラの着信呼状態(データまたは音声、アクティブまたは非アクティブ)を提供する。モデムが多重呼機能をサポートする場合、モデム属性はこうした着信呼状態のリストを有してもよい。PDP_Context Status値フィールドには、QoS(サービス品質)情報のようなPDP(パケット・データ・プロトコル)コンテキストに関する情報が含まれる。
【００７９】
上記の例に加えて、移動クライアントの伝送機能に関する他の情報を伝えるためにモデム値フィールドを使用してもよい。第1の例では、移動クライアントの最大ビットレートがMode(モード)属性で配信される。従って、受信側クライアント装置は最大ビット速度を越えないように伝送速度を設定できる。第2の例では、クライアント装置は、データ・ファイルをクライアント装置に送信する時パケット交換伝送モードだけを使用するべきかを決定する。第3の例は、ローミング装置がある種の通信だけを可能にする(例えば、音声呼だけを許可し、データ・ファイルは送信しない)よう命令するものである。
【００８０】
ユーザ状態属性
1つの好適実施例によれば、ある活動に参加しようというユーザの意欲に関する属性が規定される。活動はこのAvailability属性に属する値フィールドによって指定される。表9は、Availability属性に関する構造を示す。
【００８１】
【表９】
2004532478.tif 000011
表10は、Availability属性の値フィールドを記述する。
【００８２】
【表１０】
2004532478.tif 000012
【００８３】
表11に示される状態値フィールドは利用可能性情報の状態を示す。
【００８４】
【表１１】
2004532478.tif 000013
【００８５】
Status値フィールドは利用可能性情報の発行が可能か否かを示す。すでに説明したように、DIS指示を使用してAvailability属性の値を無効化してもよい。例えば、サーバPSは、移動クライアントMCが移動IMPSセッションを終了した後で、DIS指示を伴う利用可能性属性を送信してもよい。また、クライアントへの接続が突然途絶えた時この種のメッセージを送信してもよい。従って、受信側移動クライアントは、もはや移動IMPSシステム中に存在しないユーザ及びクライアント装置に関する全ての利用可能性情報を削除できる。
【００８６】
表10のCommAvail値フィールドは、ユーザが何らかの形態の遠隔通信に参加する意向であるかを示す。PhoneAvail値フィールドは、ユーザが電話呼に参加する意向であるかを示す。SMSAvail値フィールドは、ユーザがSMS交換に参加する意向であるかを示す。MMSAvail値フィールドは、ユーザがMMS(マルチメディア・メッセージング・サービス)交換に参加する意向であるかを示す。IMAvail値フィールドは、ユーザがIM(インスタント・メッセージング)交換に参加する意向であるかを示す。EmailAvail値フィールドは、ユーザが電子メール交換に参加する意向であるかを示す。
【００８７】
Image値フィールドに関する構造を表12に示す。
【００８８】
【表１２】
2004532478.tif 000014
【００８９】
この値フィールドは、Status、TextまたはImageフィールド以外のAvailability属性中の値フィールドの何れにも画像を関連付ける。ContainedImage値フィールドには画像が含まれるが画像のサイズまたはフォーマットは制限されることがある。ReferredImage値フィールドには関連する画像を有するリソースへのURLが含まれる。ValueField値フィールドは、画像が関連付けられる値フィールドを規定する。例えば、発行者は、DISCの意味に関する画像意味情報を伝えるため、現在「DISC」という値を有する値フィールドPhoneAvailに画像を関連付けてもよい(例えば、ユーザが電話を利用できるだけに制限されていることを意味する)。画像フィールドは、この属性中で多数のインスタンスを有してもよい。この値フィールドが属性中に含まれる時はいつでも、その目標値も同じ属性中に含まれなければならない。この関連付けは目標値フィールドが有効である限りにおいてのみ有効である。目標値フィールドが更新または無効化されると、この属性への古い関連付けがもしあれば、受信側クライアントによって破棄されなければならない。
【００９０】
Text値フィールドに関する構造を表13に示す。
【００９１】
【表１３】
2004532478.tif 000015
【００９２】
Text値フィールドは、Status、ImageまたはTextフィールド以外のAvailability属性中の値フィールドの何れにもテキスト文字列を関連付ける。Text値フィールドには、ContainedText中のテキスト文字列とValueField中の関連する値フィールドの名称とが含まれる。ContainedText要素中のテキストのサイズは制限されることがある。例えば、発行者は、NAVLの意味に関する追加意味情報を伝えるため、現在「NAVL」という値を有する値フィールドPhoneAvailにテキストを関連付けてもよい(例えば、「14:00まで会議中」)。テキスト値フィールドはこの属性中で多数のインスタンスを有してもよく、すなわち、同じテキストが多数の値フィールドに関連付けられることもある。この値フィールドが属性中に含まれる時はいつでも、その目標値フィールドも同じ属性中に含まれなければならない。この関連付けは目標値フィールドが有効である限りに置いてのみ有効である。目標値フィールドが更新または無効化されると、この値フィールドへの古い関連付けがもしあれば、この値フィールドは受信側クライアントによって破棄されなければならない。画像及びテキストは自動的にプレゼンス属性に追加されることもある。
【００９３】
個人状態属性
PersonalStatus属性は、発行者の個人状態を示す。選択項目と詳細はこの属性に属する値フィールドによって指定される。表14はPersonalStatusに関する属性構造を示す。
【００９４】
【表１４】
2004532478.tif 000016
【００９５】
表15は、PersonalStatus属性の値フィールドを示す。
【００９６】
【表１５】
2004532478.tif 000017
【００９７】
表16に示される状態値フィールドはPersonalStatus情報の状態を示す。
【００９８】
【表１６】
2004532478.tif 000018
【００９９】
このフィールドは、この情報の発行が可能か否かを示す。PersonalStatus属性と共にDIS指示を使用してもよい。
【０１００】
Text値フィールドは自由なテキスト形式で発行者の状態を示す。Mood値フィールドは発行者の気分を示す。Time値フィールドは発行者の現地時間を提供する。
【０１０１】
好適実施例によれば、PersonalStatus属性中で画像を利用してもよい。表12ですでに示されたように、Image値フィールドはある画像をStatusまたはImageフィールド以外のこの属性中の値フィールドの何れにも関連付ける。例えば、IN_LOVEの意味に関する画像意味情報を伝えるため、現在「IN_LOVE」という値を有する値フィールドMoodに画像を関連付けてもよい。このImage値フィールドは、Availability属性についてすでに示されたのと同様の方法で使用すればよい。
【０１０２】
本発明は、既存のクライアント装置及びサーバ中で実現できる。それらは全て、上記で説明した本発明の機能を実現可能なプロセッサ及びメモリを有している。コンピュータ・プログラムは内部または外部メモリからサーバまたはクライアント装置のプロセッサにロードすればよく、それをプロセッサ中で実行すれば、本発明の機能を実現する手段を与えることになる。また、ハードウェア実装またはソフトウェアとハードウェア実装との組合せを使用してもよい。
【０１０３】
図4は、本発明による、サーバ404と通信するクライアント装置402を示す。クライアント装置は、図1の1つかそれ以上の移動クライアントまたは非移動クライアント、または図2及び図3に示された任意の他の移動クライアントと同様のものでよい。同様に、サーバ404は図1に示されたサーバまたは図2及び図3に示された任意の他のサーバと同様のものでよい。クライアント装置402には、プレゼンス情報をプレゼンス属性として信号線路408上のサーバに送信または要求する手段406が含まれる。プレゼンス情報の送信は、例えば、プレゼンス属性がMC1からPSに送信される図3のステップ302か、または、プレゼンス属性がMCによって更新されPSに送信される図2のステップ202に対応する。線路408上でプレゼンス情報を要求することは、MCがSSからプレゼンス属性を要求する図2のステップ203に相当する。線路408上のクライアント装置402からサーバ404への送信は、図1に示された、移動クライアント(MC)から移動ネットワーク(MNW)を通じ中間ネットワークONWを介してIMPSサーバに至る伝送経路と同様のものでもよい。又は、これは非移動クライアントCから中間ネットワークONWを介してサーバSに至る経路と同様のものでもよい。もちろん、他の経路も考えられ、本発明は使用される物理媒体または物理媒体の組合せの経路に依存しない。また、クライアント装置402には、信号線路412上のサーバ404からプレゼンス属性を受信する手段が含まれる。このプレゼンス情報は、属性名称によって識別される複数のプレゼンス属性種類によって分類される。
【０１０４】
サーバ404には、属性を受信/送信し、受信したプレゼンス属性に基づいてプレゼンス情報を維持する手段414が含まれる。
【０１０５】
本発明によれば、クライアント装置402にはさらに、修飾子をプレゼンス属性に追加する手段416が含まれ、その際修飾子は属性の使用を指定する1つかそれ以上のパラメータを備えている。追加された修飾子は信号線路418上で提供され、手段406によって線路408上でサーバ404に送信される。これは、線路422上でアプリケーション424から受信された命令に応じてプレゼンス属性を決定する手段420を介して行ってもよい。また、アプリケーションは、プレゼンス属性を要求するための手段420を利用してもよい。どちらの場合でも、信号は線路426上で手段420から、線路408上でプレゼンス属性を送信または要求する手段406に提供すればよい。例えば、図2のステップ202によりプレゼンス属性を更新する際に手段416が修飾子を追加した場合、線路408上の信号には、属性の使用を指定する1つかそれ以上のパラメータを有する修飾子を伴うプレゼンス属性が含まれる。
【０１０６】
線路412上でサーバ404から着信したプレゼンス属性に対処するため、クライアント装置402にはまた、受信した属性中の修飾子パラメータに応じて線路412上でサーバ404から受信したプレゼンス属性を処理する手段428が含まれる。線路412上の受信プレゼンス属性は手段410によって受信され、線路430上で受信した属性を処理する手段428に対して提供されればよい。処理の後、手段428は線路432上でアプリケーション424に対して信号を提供すればよく、信号はアプリケーション424によってさらに使用される。
【０１０７】
修飾子を追加する手段416は、サーバ404から属性を受信したクライアントが提示設定に基づいて属性を提示できるように、属性の修飾子に提示設定を指定する手段434を含んでもよい。その結果、図4のクライアント装置402のようなクライアント装置には、他のクライアント装置によって指定され線路412上でサーバ404から受信された修飾子に基づいて受信した属性を提示する手段436が含まれる。
【０１０８】
同様に、手段416には、サーバ404に送信される修飾子中で、受信側クライアントにおいて属性のアドレス指定先となるアプリケーションを指定する手段438が含まれる。クライアント装置402が属性のアドレス指定先となるアプリケーションを指定する修飾子を受信する場合、線路430上で受信した属性を解釈し受信した属性を修飾子が指示するアプリケーションにアドレス指定する手段440を有する。
【０１０９】
ここでサーバ404をさらに詳細に検討すると、サーバ中のプレゼンス・データベースのプレゼンス・グループによって指定された1つかそれ以上のクライアント装置に属性を送信するかどうかを修飾子に基づいて決定する手段444を含んでもよい。このような決定は、線路446上で許可を提供する手段448から与えられた許可に応じて行ってもよい。修飾子及び許可によって属性を1つかそれ以上のクライアント装置に送信するよう指示されたならば、サーバ404は、例えばクライアント402または同様の装置に対して適切な場合それを行う。
【０１１０】
特定のクライアント向けのプレゼンス属性が、サーバにとって既知の情報によればクライアントの機能に適合しないこともありうる。このような情報は例えば、線路450上の手段444によって、クライアントの機能に合うようプレゼンス属性を変更する手段452に提供すればよい。変更された属性は線路450上の手段444に戻せばよい。他方、プレゼンス属性が「一方的に送りつける」方式で提供される場合、変更されたプレゼンス属性を線路454上で手段456に提供すればよく、手段456は変更されたプレゼンス属性を対象クライアントまたは1つより多いクライアントに必要に応じて送りつける適切なステップを取ることができる。これは例えば線路458上で手段444に対して信号してもよい。
【０１１１】
認識されるように、図4に示される機能ブロックは、当業者に周知の個別ハードウェア、専用集積回路、マイクロコントローラ、ソフトウェア、ファームウェア等を使用して実行すればよい。さらに、図面中で別個の機能ブロックに属する機能は分離されている必要はなく、機能を他の機能ブロックに自由に追加またはそこから削除することによって他のブロックに組み込むことができる。同様に、機能ブロック間の協調関係をその順序や相互関係について変更し、同時に上記で言及された同じ最終結果を実行してもよい。また、やはり認識されるように、本発明によれば、図4に示されたクライアント装置及びサーバ装置の細部は図示されたものと同様の他の形態を取ってもよい。本発明の他の態様は、類似しているが同一ではない形で示してもよい。
【０１１２】
例えば、図5はサーバ装置504と通信するクライアント装置502を示すが、そこでは図4の手段420と同様の手段506は、プレゼンス情報をプレゼンス属性として線路508上で、図4のサーバ404内の手段414と同様の、サーバ504内のプレゼンス属性を受信し維持する手段510に送信する。同様に、クライアント装置502は、サーバ504の手段510から線路514上でプレゼンス情報を示すプレゼンス属性を受信する手段512を含んでもよい。図4のクライアント装置402の手段420及び416と同様、図5のクライアント装置502は、オーソライザ、属性名称及び修飾子の組合せによって識別されるプレゼンス情報属性を構成する手段516を含んでもよく、その際オーソライザは属性の維持に責任を負う主体を指定し、修飾子は属性の使用を指定する。上記のように構成された属性は、線路508上でサーバ504に送信するために図示されるように線路518上で手段506に提供されてもよい。サーバ504は、線路522上で手段510から受信した上記のように構成された属性に応答して、許可、属性名称及び修飾子の同じ組合せを含む、すでに格納された属性を探索する手段520を含んでもよい。受信した属性の識別子の組合せが、すでに格納された属性、例えば記憶手段524中に格納されたものと同一であれば、受信した属性を使用して、信号線路526上のすでに格納された属性を置換する。この方法で、属性パラメータが変化した場合、更新されたパラメータが記憶手段524中に格納されるようになる。そうでなければ、受信した属性は新しい属性として記憶手段に追加される。この機能は上記で説明したように手段520で実行してもよく、また完全に独立した手段528で実行してもよいが、この手段528は線路530上で手段520から受信属性を受信し、識別子の組合せが同じであればすでに格納された属性を受信した属性によって置換し、そうでなければそれ自体と記憶手段524との間の接続線路532上で受信した属性を追加するものである。
【０１１３】
クライアント装置502には上記で説明したのと同様の機能が含まれ、そのことは例えば、線路542上で手段512から着信属性を受信し、受信した属性と同じ識別子を含む、すでに格納された属性を探索する手段540と、受信した属性の識別子の組合せがすでに格納された属性のものと同一であればすでに格納された属性を受信した属性によって置換する手段542とによって示される。そうでなければ、受信した属性は記憶手段544に追加される。探索手段540は手段542を内部に含んでもよく、またそれらは図示されるように独立したものでもよい。後者の場合、信号線路546は手段540から手段542に対して受信した属性に関する属性情報を提供する。記憶手段544は、線路548上で属性を置換または追加する手段542と双方向通信し、線路550上ですでに格納された属性を探索する手段540と双方向通信してもよい。
【０１１４】
上記で言及したように、ここで本発明の動的電話帳サービス実施例のためのサービス機能を説明する。動的電話帳サービスはリッチコール(rich call)・サービスと考えてもよい。これは「電話をかける前に」B当事者のプレゼンス情報をA当事者に示す機能を充実させるため有用である。この場合、B当事者は1つかそれ以上のユーザ電話帳エントリである。プレゼンス情報は、(1)クライアントの利用可能性、(2)ユーザの利用可能性、(3)現地の条件、(4)個人の状態、(5)クライアントの機能、(6)ユーザの属性、及び(7)拡張プレゼンス・サービスといった、上記で言及したのと同じカテゴリに分割できる。
【０１１５】
概念上、プレゼンス・システムは、図6に示されるように、プレゼンス・クライアント602、604、606と、プレゼンス・ユーザ608、610、612と、プレゼンス・ユーザ役割614、616、618、620、622、624と、プレゼンス・プロキシ626と、プレゼンス・サーバ628、630からなる。プレゼンス・クライアントはユーザがプレゼンス・システムと対話できるようにするソフトウェアまたはプログラムである。ユーザはプレゼンス・クライアントを使用してプレゼンス・システムと対話する人物である。例えば移動送受話器またはPCのような物理装置632、634は、1つのプレゼンス・クライアント・インスタンス606を有してもよいが、特殊な場合には、多数のプレゼンス・クライアント・インスタンス602、604を有してもよい。プレゼンス・クライアントは単一のユーザによって所有される。ユーザは1つより多いクライアントを有してもよいが、こうしたクライアントは通常異なった装置に置かれる。
【０１１６】
ユーザ608、610、612は概念上発行者と加入者とに分類される。発行者はプレゼンス情報の発信者である。加入者はプレゼンス情報の受信者である。ユーザは、自分自身のプレゼンス情報の発行者であると同時にある他の発行者のプレゼンス情報の加入者であってもよい。ユーザは1つかそれ以上の役割を有してもよい。発行者役割は、プレゼンス集合と呼ばれるプレゼンス値の集合に関連付けられる。同じユーザの2つの異なるプレゼンス集合のプレゼンス値は互いに独立しており異なる役割に関連付けられる。加入者役割は、同一の発行者役割のプレゼンス情報、すなわち同じプレゼンス集合の論理受信者である。
【０１１７】
プレゼンス・プロキシ626は随意選択のネットワーク要素でありプレゼンス・サービスの拡張性を改善する。プロキシは、発行者からサーバに向かうアップリンク方向か、またはサーバから加入者に向かうダウンリンク方向に伝わる異なったプレゼンス集合のプレゼンス値を一時的に格納する。クライアントがオンラインになる時、プロキシは現在のプレゼンス情報によってクライアントを更新すればよい。また、発行者が新しいプレゼンス値をサーバに送信する時、プロキシはプロキシによって登録された全ての加入者クライアントを更新すればよい。プロキシは現在の値を一時的にだけキャッシュできる。プレゼンス情報が発行者から到来しても、プロキシは、このプレゼンス情報の全ての更新が同じプロキシ経由で行われていると想定することはできない。プロキシがプレゼンス集合に関連する加入者グループを知らない場合、プロキシはこの情報をサーバから要求すればよい。
【０１１８】
プレゼンス・サーバ628、630は、各プレゼンス集合に関連するグループに関する有効なプレゼンス値と情報を維持するネットワーク要素である。サーバは直接またはプロキシを通じてプレゼンス・クライアントと通信する。サーバは、プロキシによってキャッシュされたプレゼンス値の有効期間についてプロキシに通知する。有効期間が切れると、プロキシは値を破棄するか、またはサーバからリフレッシュしなければならない。サーバは、プレゼンス値が変化する頻度を監視することによって、プレゼンスの項目毎に有効期間を割当てる。有効期間は動的であり、すなわちプレゼンス項目の有効期間中に変化してもよい。
【０１１９】
プレゼンス・サーバは、図6に示されるように、他のプレゼンス・サーバともプレゼンス情報を交換する。例えば、発行者と加入者とが管理上異なったプレゼンス・サーバに属する場合、プレゼンス情報は両方のサーバを通らなければならない。サーバの互換性がない場合、一方または両方のサーバにゲートウェイ機能が存在する必要がある。
【０１２０】
図7は、本発明によるプレゼンス・データベース702の構造を示す。1つのプレゼンス項目704は、名称708、属性710及び値712といった3つのプロパティを有する。プレゼンス集合714は1つまたはそれ以上のプレゼンス項目からなる。プレゼンス集合714はユーザの1つの役割716に属する。1つの役割に対して1つより多いプレゼンス集合は存在できない。さらに、1つの役割716に属する1つの許可グループ718が存在する。許可グループは、同じ役割のプレゼンス集合の全体または一部に加入する権利を有するメンバからなる。
【０１２１】
プレゼンス集合中の項目704、720、…、722は一意であり、すなわち互いに区別できる。項目は主として名称によって互いに区別される。プレゼンス集合が同じ名称を有する2つかそれ以上の項目を含む場合、各項目にははそれらの項目のIDを伝える属性がなければならない。グループ718のメンバ724、726、…、728は一意である。同じ発行者734の異なった役割716、730、…、732における異なったプレゼンス集合は同じ名称またはIDを有する項目を含んでもよい。異なったグループも同様に同じメンバを含んでもよい。
【０１２２】
役割716は、役割ID、グループIDまたはプレゼンス集合IDによって識別すればよい。例えば、グループIDはサービス・プロバイダによって割当ててもよく、サービス・プロバイダ・ドメイン内で一意である。従って、プレゼンス・データベース中の個々の要素をアドレス指定するため以下のIDが必要になる。
GroupID;ItemName
【０１２３】
プレゼンス集合が同じ名称を有する1つより多い項目を含む場合、ItemNameにはItemID属性を割当てなければならない。
【０１２４】
UserID、DeviceID及びClientIDといったIDは必要ないことに注意されたい。
【０１２５】
A.        典型的プレゼンス・プロトコル
A.1.0     未加入のプレゼンス(図8)
ユーザのプレゼンス情報は、例えば図2のステップ203、204、205、206で提示されたメッセージの流れによって示されるように問い合わせを発行するか、図9の場合のように加入してプレゼンス項目を受信するか、または図8に示されるようにプレゼンス項目を獲得するかによってメッセージ・サービスとは別個に獲得しなければならない。
【０１２６】
プレゼンス・サービスのユーザは、任意の適切な時点で、図8に示されるようにプレゼンスの更新メッセージを送信することによって、プレゼンス・サーバ中の自分のプレゼンス情報を更新すればよい。すでに言及したように、ユーザは、図8に示されるように、プレゼンスの獲得メッセージを発行してある他のユーザのプレゼンス情報を要求してもよい。プレゼンス情報は要求したユーザに返送される。
【０１２７】
発行者は自分のプレゼンス情報を部分的にだけ更新してもよい。同様に、ユーザは部分的なプレゼンス情報だけを要求してもよい。
【０１２８】
ユーザが要求されたプレゼンス情報に対して許可を有さない場合、空の内容がユーザに送信される。
【０１２９】
ある所定のユーザに対するプレゼンス情報の許可は、プレゼンス集合に対応するグループにそのユーザを含めることによってなされる。このことは以下、「プレゼンス・データベースの管理」と題された部分で説明される。
【０１３０】
A.1.1         UpdatePresence
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID, GroupID, Presence)
属性:なし
使用法:このプリミティブ(primitive)は、プレゼンス・サーバ上の1つかそれ以上のプレゼンス項目の値を更新する。更新すべきプレゼンス項目はPresenceという情報要素で伝送される。所定のGroupIDについてサーバ中に存在しない項目がPresence中に存在する場合、サーバはこの新しい項目のために記憶装置を割当て、このメッセージの内容をコピーする。そうでなければ、サーバは古い値を新しい値によって置換する。
【０１３１】
内容にはUserIDまたはPublisherIDは必要ない。発行者とUpdatePresenceプリミティブを含むXML文書との間の関連付けは認証プロトコルで行われる。
【０１３２】
A.1.2         TransactionID
内容モデル:(#PCDATA)
属性:なし
使用法:これはクライアントからサーバへの要求をサーバからクライアントへの対応する応答に関連付ける一意の識別子である。クライアントは、第1の応答を得る前に1つより多い要求をサーバに送信していてもよい。第1の応答は必ずしも第1の要求に関連するものではない。従って、要求と応答とを互いに関連付ける機構が必要である。典型的には、TransactionIDはシーケンス番号である。これは要求においてクライアントによって割当てられ、応答でサーバによって使用される。
【０１３３】
A.1.3         GroupID
内容モデル:(#PCDATA)
属性:なし
使用法:このIDはサービス・プロバイダ・ドメイン内で許可グループとプレゼンス集合とを含む発行者役割を一意に識別する。これはプレゼンス・サービス・プロバイダによって割当てられる。
【０１３４】
A.1.4         UpdateStatus
方向:プレゼンス・サーバ→プレゼンス・クライアント
内容モデル(TransactionID,StatusCode)
属性:なし
使用法:このプリミティブは、クライアントのUpdatePresence要求に対するプレゼンス・サーバからの応答である。StatusCodeは、サポートしない、新しい割当て、成功、失敗といった値を有してもよい。
【０１３５】
A.1.5         GetPresence
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,((GroupID,PresenceNames?)*)|PresenceNames?)
属性:なし
使用法:このプリミティブは、プレゼンス・サーバからプレゼンス情報を要求するために使用される。ゼロまたはそれ以上のGroupIDが存在しうる。各GroupIDについて、随意選択のPresenceNamesが結合されうる。GroupIDが使用されない場合、要求範囲はユーザがメンバである全てのグループとなる。サーバは、認証プロトコルによって要求を出したユーザのIDを要求に関連付ける。PresenceNamesは後でこの文書中で規定される。これは、値の要求先である名称によってプレゼンス項目のリストを作成する。これは随意選択である。これはGroupIDと結合されてもよく、GroupIDのリストが作成されていない場合単独でもよい。GroupIDと結合されると、サーバは所定のグループに対するプレゼンス項目の探索を制限する。存在しない場合、全てのプレゼンス項目の値が要求される。
【０１３６】
A.1.6         PresenceItems
方向:プレゼンス・サーバ→プレゼンス・クライアント
内容モデル(TransactionID,StatusCode,(GroupID,Presence)*)
属性:なし
使用法:このプリミティブは、要求されたプレゼンス項目と要求の結果状態とのリストを供給する。要素Presenceは所定のGroupIDに対応するプレゼンス集合であり、後で本明細書で規定される。StatusCodeは、許可されない、項目が利用できない、成功、失敗といった値を有してもよい。
【０１３７】
A.2.0         加入済のプレゼンス(図9)
プレゼンス情報を配信するもう1つの機構は誰かのプレゼンス情報に加入することである。メッセージの流れを図9に提示する。
要求を出すユーザはプレゼンス加入メッセージA.2.1をプレゼンス・サーバに送信し、誰かのプレゼンス情報に加入する。
プレゼンス情報の加入が完了すると、要求を出したユーザは、最初に、また他の当事者がプレゼンス情報を更新した時は常に新しいプレゼンス情報A.2.2を受信する。
要求を出したユーザが、それ以上プレゼンス情報を受信したくない場合、プレゼンス情報の加入の取消しを行えばよい(A.2)。代りに、プレゼンス情報はある期間だけ加入してもよく、その場合加入取消しメッセージは必要ない。
要求を出したユーザは、プレゼンス情報のうち、自分が獲得する許可を得ている部分だけに加入できる。
【０１３８】
A.2.1         SubsPresence
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,SubsPeriod?,((GroupID,PresenceNames?)*)|PresenceNames?)
属性:なし
使用法:このプリミティブは、加入者が許可されている発行者役割からのプレゼンス情報に加入するために使用される。随意選択のGroupIDが加入する発行者役割を指定する。GroupIDがない場合、加入者が許可されている全ての役割に加入する。各GroupIDを、加入した項目をPresenceNamesに列挙したグループ内に制限するPressenceNamesに関連付けてもよい。随意選択のSubsPeriodは加入期間の長さを指定する。これがない場合、加入は対応するUnsubsPresenceプリミティブが呼び出されるか、またはサービス・プロバイダが加入を終了するまで継続する。PresenceNamesは許可された集合から加入したプレゼンス項目を指定する。これがない場合、プレゼンス集合(GroupID)内のユーザが許可を有する全てのプレゼンス項目に加入する。GroupIDなしで単独で使用される場合、許可された全てのグループから指名された項目に加入する。PresenceNamesは後で本明細書で規定される。
加入者の身元は認証プロトコルで発見される。
【０１３９】
A.2.2         SubsPeriod
内容モデル:(#PCDATA)
属性:なし
使用法:これは加入期間の長さを規定する。時間単位はTBDである。代りに、この内容は加入が終了する日付を示してもよい。
【０１４０】
A.2.3         PushPresence
方向:プレゼンス・サーバ→プレゼンス・クライアント
内容モデル:(GroupID,Presence)+
属性:なし
使用法:このプリミティブは、発行者によって変更された加入したプレゼンス項目をユーザに送りつける。GroupIDは役割を識別する。
【０１４１】
A.2.4         UnsubsPresence
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,((GroupID,PresenceNames?)*)|PresenceNames?)
属性:なし
使用法:このプリミティブは、プレゼンス情報の加入を取消すために使用される。加入の終了は所定のグループだけに制限してもよく、さらにあるプレゼンス項目だけに制限してもよい。GroupIDが与えられない場合、加入の終了を全てのグループ中の指名されたプレゼンス項目だけに制限することが可能である。GroupIDとPresenceNamesが与えられない場合、ユーザの加入全体が終了する。
【０１４２】
A.2.5         SubsStatus
方向:プレゼンス・サーバ→プレゼンス・クライアント
内容モデル:(TransactionID,StatusCode,(GroupID,PresenceNames)*)
属性:なし
使用法:このプリミティブは、加入の取消し動作に対してStatusCodeを返送し、まだ加入しているプレゼンス項目とグループのリストを作成する。StatusCodeは、サポートしない、存在しない項目、未加入の項目、成功、失敗といった値を有してもよい。
【０１４３】
A.3.0         プレゼンス・データベースの管理
プレゼンス・ユーザは、プレゼンス・サーバで自分のユーザ・グループとプレゼンス集合とを管理してもよい。
ユーザ・グループとプレゼンス集合とを含む役割をCreatePresGroup(プレゼンス・グループの生成)メッセージA.3.1を使用して生成する。プレゼンス・サーバは、要求された動作の状態と生成されたグループのIDを示すPresGroupStatusメッセージA.3.6によって応答する。PresenceInfoメッセージA.3.7がメンバが獲得または加入することを許可されるプレゼンス項目を示すグループのメンバに送信される。
プレゼンス・ユーザは、GetPresGroupStatusメッセージA.3.8によってグループ情報を要求してもよい。グループ情報の要求はグループの所有者に制限される。
ユーザ・グループを所有するプレゼンス・ユーザはグループのメンバまたはプレゼンス集合のプレゼンス項目を追加または削除してもよい。
発行者はDeletePresGroupメッセージによってグループの削除を送信してもよい。
【０１４４】
A.3.1         CreatePresGroup
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,MemberList, Presence)
属性:なし
使用法:このプリミティブは、プレゼンス・サーバで役割を生成するようサーバに要求する。許可グループはmemberlist中のメンバを含み、プレゼンス集合はPresence中に含まれる。
【０１４５】
A.3.2         MemberList
内容モデル:(MemberDescription)+
属性:なし
使用法:メンバのリスト。記述はユーザに起源を有する。
【０１４６】
A.3.3         MemberDescription
内容モデル:(UserOriginatedMD?, ServerOriginatedMD?)
属性:なし
使用法:ユーザ起源部分はユーザが見たメンバの記述である。サーバ起源部分はサーバ・データベース中に格納されたメンバの記述である。
【０１４７】
A.3.4         UserOriginatedMD
内容モデル:(#PCDATA)
属性:なし
使用法:これは人物を識別するユーザ起源の手段である。これは名称、対象人物の電話の1つのMSISDN、電子メール・アドレス、SIPアドレス等でよい。また、それらの組合せでもよい。この記述のデータ・フォーマットは本明細書の範囲内ではないが、vCardのような周知のフォーマットを使用すればよい。
【０１４８】
A.3.5         ServerOriginatedMD
内容モデル:(#PCDATA)
属性:なし
使用法:これは人物を識別するサーバ起源の手段である。これは名称、対象人物の電話の1つのMSISDN、電子メール・アドレス、SIPアドレス等でよい。また、サーバ・データベースに格納されたそれらの組合せでもよい。この記述のデータ・フォーマットは本明細書の範囲内ではないが、vCardのような周知のフォーマットを使用すればよい。
【０１４９】
A.3.6         PresGroupStatus
方向:プレゼンス・サーバ→プレゼンス・クライアント
内容モデル:(TransactionID,StatusCode,(GroupID,MemberList,PresenceNames)*)
属性:なし
使用法:このプリミティブは、現在存在する発行者役割のGroupIDをその役割に関するグループ・メンバ及びプレゼンス項目名と共に返送する。サーバは、その動作が成功した場合、新しい役割に関する新しいGroupIDを割当てている。サーバはmemberlistのサーバ起源部分を満たしている。これによって発行者は、グループが正しいメンバを含んでいることを検証できる。サーバは、ユーザ起源部分中にすでに存在するレベル、または人物を一意に識別するために必要なレベルを越えてmemberlist中にどのような機密または個人情報も提供すべきではない。これはTBDである。StatusCodeは、サポートしない、未知のメンバ、未知のプレゼンス項目、成功、失敗といった値を獲得しうる。
【０１５０】
A.3.7         PresenceInfo
方向:プレゼンス・サーバ→プレゼンス・クライアント
内容モデル:(GroupID,Presence?)+
属性:なし
使用法:このプリミティブは、新しいプレゼンス項目を許可グループに定期的に配送する。このメッセージは、加入及び未加入両方の、所定の許可グループの全てのプレゼンス項目を含む。このメッセージは、グループのメンバ構成が変更された場合新しいメンバに送信され、新しいプレゼンス項目が追加された場合グループの全てのメンバに送信される。このメッセージは、GroupIDに関連するプレゼンス集合(Presence)が存在しないようにして削除されたグループ・メンバに送信される。
【０１５１】
A.3.8         GetPresGroupStatus
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,GroupID*)
属性:なし
使用法：このプリミティブは、サーバからのPresGroupStatusメッセージを要求する。ユーザは自分自身のグループからだけ情報を要求してよい。GroupIDは情報を所定のグループに制限する。GroupIDが存在しない場合、状態は要求者が所有する全てのグループから戻される。
【０１５２】
A.3.9         AddMembers
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,(GroupID,MemberList)+)
属性:なし
使用法:このプリミティブは、指名されたメンバを所定のグループに追加するようサーバに要求する。
【０１５３】
A.3.10        RemoveMembers
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,(GroupID,MemberList)+)
属性:なし
使用法:このプリミティブは、指名されたメンバを所定のグループから削除するようサーバに要求する。MemberListにはサーバ起源情報が満たされる。
【０１５４】
A.3.11        DeletePresGroup
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,GroupID*)
属性:なし
使用法:このプリミティブは、1つかそれ以上の発行者役割を削除するようサーバに要求する。GroupIDは削除すべき役割を識別する。GroupIDが与えられない場合、全ての発行者役割を削除する。
【０１５５】
A.3.12        AddPresence
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,(GroupID,Presence)+)
属性:なし
このプリミティブは、所定のプレゼンス項目を所定の役割に追加するようサーバに要求する。
【０１５６】
A.3.13        RemovePresence
方向:プレゼンス・クライアント→プレゼンス・サーバ
内容モデル:(TransactionID,(GroupID,Presence?)+)
属性:なし
使用法:このプリミティブは、所定のプレゼンス項目を所定の役割から削除するようサーバに要求する。GroupIDに関連するPresence要素がない場合、全てのプレゼンス項目が役割から削除される。
【０１５７】
A.3.14        動的クライアント変更
発行者または加入者は自分のクライアントをいつでも変更してよい。典型的にはクライアント装置も変更される。まれには、ユーザは同じ装置でクライアントのインスタンスだけを変更することもある。新しい装置がTEで古い装置がMTであってもよく、またその逆であってもよい。また新しいMTに変更することも可能である。クライアントの変更は、ユーザに自分のプレゼンス・データを古いクライアントから新しいクライアントにコピーまたは同期することを要求する。発行者の場合、所定のクライアントについて静的で同期集合中に含まれないあるクライアント特有のプレゼンス・データがあることもある。同期は局所的に行ってもよく、ネットワーク支援型であってもよい。何れの場合でも、既存の同期プロトコルを使用すればよい。これはプレゼンスプロトコルの範囲外である。
【０１５８】
加入者クライアント変更によってもたらされるもう1つの問題は、新しいクライアントのレジストリを、プレゼンス関連送りつけ型メッセージを受信するアクティブ・クライアントにすることである。レジストリは、
-ユーザが同じ装置で新しいクライアントを起動する(自動)か、
-ユーザのSIMが新しい装置に変更される(自動)か、
-ユーザは新しい装置中に別のSIMを有しているが、新しい装置だけの電源が入っている(半自動)か、または
-ユーザは新しい装置中に別のSIMを有しており、新しい装置と古い装置との両方の電源が入っている(手動)か、
に応じて、自動(ユーザの確認は必要ない)、半自動(ユーザの確認が必要)または手動(ユーザはレジストリを起動しなければならない)で行えばよい。
全ての場合で、レジストリは下位レベル・プロトコルによって処理すればよい。例えば、SIPプロトコルがプレゼンス文書用に選択されたトランスポート・プロトコルである場合、レジストリについてもこのプロトコルを使用すればよい。
【０１５９】
A.4.0         プレゼンス・プロトコル用DTD
【０１６０】
【表１７】
2004532478.tif 000019
【０１６１】
【表１８】
2004532478.tif 000020
【０１６２】
【表１９】
2004532478.tif 000021
【０１６３】
B.            典型的プレゼンス内容フォーマット
上記で述べたように、プレゼンス内容は以下のクラスに分割できる。
クライアントの利用可能性:通信に対するクライアントの利用可能性を記述するプレゼンス属性、例えば、ネットワークの到達可能性、GPRS接続、オン/オフ状態。
ユーザの利用可能性:通信に対するユーザの利用可能性を記述するプレゼンス属性、例えば、準備完了、会議中、手が離せない、不在、電話中、チャット中、就寝中、等。
地域条件:ユーザの地域環境を記述するプレゼンス属性、例えば、現地時間、騒騒しい/静かな環境、室内、室外、例えば、地理的位置、訪問先PLMN、都市/通り、施設といったユーザの所在地。
個人状態:個人ユーザ状態を記述する様々な個人属性。例えば、気分、個人の関心及び目的。
クライアント機能:例えば、様々な通信手段、様々な媒体種類、及び様々な機能をサポートするクライアントの機能を記述するプレゼンス属性。
ユーザ属性:クライアントまたはユーザが自分自身のテキスト・プレゼンス値及び外部値に対する参照を規定できるようにするプレゼンス属性。
拡張プレゼンス・サービス:サービス・プロバイダが動的に規定する非標準プレゼンス属性であるが、それにもかかわらず標準プレゼンス・サーバ及びプロキシを通じて伝える必要があるもの。
【０１６４】
B.1.           設計の目標
プレゼンス通信の大部分は、プレゼンス項目の値部分の変更を加入者に送信することである。1つの値だけが変更されることも多い。転送されるデータの量を最小化するため、設計の目標は、プレゼンス項目の階層表示をできる限り平坦に保持することである。このため、プレゼンス項目は、上記で説明したプレゼンス・クラスに従って詳しく調べられる。その代りに、クラスはプレゼンス項目中で随意選択属性として与えられてもよい。
【０１６５】
D.2           共通属性
プレゼンス要素は多様な属性を含むが、その大部分は任意のプレゼンス項目中で使用してよい。
【０１６６】
D.2.1         Version
内容構文(content syntax):NMTOKENS
必須(mandatory):はい
使用法:これはプレゼンス内容フォーマットのバージョンを示す。
【０１６７】
D.2.2         Class
内容構文:NMTOKEN
必須:いいえ
使用法:これは属性が属するクラスを示す。
とりうる値は、CLIENT_AVAILABILITY、USER_AVAILABILITY、LOCAL_CONDITIONS、PERSONAL_STATUS、CLIENT_CAPABILITIES、USER_ATTRIBUTES、EXT_PRES_SERVICEである。
【０１６８】
D.2.3         ID
内容構文:PUBIDLITERAL
必須:いいえ
使用法:これは指名されたプレゼンス項目についての固有のIDである。これはクライアントによって割当てられる。
【０１６９】
D.2.4         Cacheability
内容構文:NMTOKEN
必須:いいえ
使用法:これはプレゼンス項目がプロキシによってキャッシュできるか否かを示す。とりうる値はYES、NOである。これはクライアントによって割当てられる。この属性がない場合、NOの値が想定される。
【０１７０】
D.2.5         ValidityPeriod
内容構文:NMTOKEN
必須:いいえ
使用法:これはキャッシュされたプレゼンス項目の有効期間である。この値は時間(単位:秒)である。これはプレゼンス・サーバによって割当てられる。
【０１７１】
D.2.6         DeviceName
内容構文:NMTOKEN
必須:いいえ
使用法:これはクライアント装置の名前である。これはクライアントによって割当てられる。
【０１７２】
D.2.7         Accuracy
内容構文:NMTOKEN
必須:いいえ
使用法:これは位置決め装置の精度である。これはメートル単位で示される。
【０１７３】
D.2.8         ImageType
内容構文:NMTOKEN
必須:いいえ
使用法:これは画像の内容符号化である。とりうる値はJPEG、GIF、BMPである。
【０１７４】
D.2.9         SoundType
内容構文:NMTOKEN
必須:いいえ
使用法:これは音声を符号化するために使用される音声コーデックの種類である。とりうる値はAMR、EFR、MP3、AAC、MIDIである。
【０１７５】
D.2.10        ExtRef
内容構文:PUBIDLITERAL
必須:いいえ
使用法:これは外部参照を示すURLである。
【０１７６】
D.2.11        ExtRefChange
内容構文:NMTOKEN
必須:いいえ
使用法:これは、外部参照が変更されたことを示す。とりうる値はYES、NOである。
【０１７７】
D.2.12        ContentChange
内容構文:NMTOKEN
必須:いいえ
使用法:これは内容値の変更を示す0〜255のカウンタである。サーバまたはプロキシは最新の32の値の内容を格納してもよい(但ししなくてもよい)。最新の32の値の中の2つの内容について同じ値があればそれは同じ内容に対応する。
【０１７８】
D.3           クライアントの利用可能性
D.3.1         DeviceOn
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod、DeviceName
使用法:これはユーザ端末のオン/オフ状態を示す。発行者は、グループ管理メッセージを使用することによって、この項目をサーバ中の役割に追加する。その後、値部分がネットワークによって維持される。ユーザは自分のプレゼンス情報中に1つより多い端末を有してもよい。この場合、ID属性の使用は必須である。この内容は「ON」または「OFF」の値を有しうる。ユーザの端末がオンであるがネットワーク到達範囲外である場合、ネットワークはこの項目について「OFF」の値を割当てる。
【０１７９】
D.3.2         DeviceRoaming
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod、DeviceName
使用法:これは、発行者が訪問先のネットワークでローミング中であることを加入者に示す。ユーザは自分のプレゼンス情報中に1つより多い端末を有してもよい。この場合、ID属性の使用は必須である。この内容は「ON」または「OFF」の値を有しうる。
【０１８０】
D.3.3         NetworkType
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod、DeviceName
使用法:これは発行者が現在接続している移動ネットワークの種類を示す。この内容は「2G」 、「3G-99」、「3G-R4」または「3G-R5」といった値をとりうる。ユーザは自分のプレゼンス情報中に1つより多い端末を有してもよい。この場合、ID属性の使用は必須である。
【０１８１】
D.4           ユーザの利用可能性
D.4.1         UserStatus
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これは、発行者が容認するのに同意する邪魔の程度について発行者の現在の状態を示す。「availabie」、「silent」、「in-car」、「busy」といった値が規定される。
【０１８２】
D.4.2         PreferredContact
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これは発行者の現在の好適な連絡方法が何かを示す。「PHONE」、「VOICE_MESSAGE」「MESSAGE」、「MAIL」、「NO_CONTACT」といった値が規定される。
【０１８３】
D.4.3         PreferredDefaults
内容モデル:((TimePeriod, PrefCont)*)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これは発行者がプレゼンス・サーバに送信しうるプレゼンス・メタ情報である。この情報は他のプレゼンス情報同様役割に関連するが、この項目は加入者には利用できない。その代わり、これは「PreferredContact」要素の値を制御する。これは、所定期間のデフォルトの好適連絡方法を指定する。ユーザが指定する期間は重なってもよく、またある期間が他の期間を完全に含んでもよい。サーバは、所定の期間が満了するとPreferredDefaultsに応じてPreferredContact要素の値を変更する。但しこれは、ユーザがPreferredContactの値を直接変更することを阻止するものではない。また、ユーザがPreferredContactの値を直接変更することは、期間が満了した時にサーバがそれを再度変更することを阻止するものでもない。ユーザは、内容が空のこの要素をサーバに送信することによって、デフォルト機構を削除してもよい。
【０１８４】
D.4.4         TimePeriod
内容モデル:(PeriodStart, PeriodEnd, RepetitionPeriod?, PeriodPrecedence)
属性:なし
使用法:これは、期間の開始、例えば開始時間、期間の終了、例えば終了時間、反復期間、例えば「DAY」及び期間の優先順位を記述する。
【０１８５】
D.4.5         PeriodStart
内容モデル:(#PCDATA)
属性:なし
使用法:これは開始期間である。これはTime、Time-DayofWeek、Time-DayofMonthまたは完全な日付でよい。
【０１８６】
D.4.6         PeriodEnd
内容モデル:(#PCDATA)
属性:なし
使用法:これは開始期間である。これはTime、Time-DayofWeek、Time-DayofMonthまたは完全な日付でよい。分離の度合いはPeriodStartと同じでなければならない。
【０１８７】
D.4.7         RepetitionPeriod
内容モデル:(#PCDATA)
属性:なし
使用法:これは開始-終了の反復期間を示す。これは「DAY」、「WEEK」、「MONTH」の値のうちの1つでなければならない。この要素が期間の記述中に含まれない場合、反復は適用されないものと想定される。
【０１８８】
D.4.8         PeriodPrecedence
内容モデル:(#PCDATA)
属性:なし
使用法:この要素は重なり合う期間の間の衝突を解決する。これは0と9の間の数値を有しうる。数字0が最高の優先順位である。2つかそれ以上の期間が重なり合っている場合、サーバは最高の優先順位値に関連付けられた希望連絡方法を取る。
【０１８９】
D.4.9         PrefCont
内容モデル:(#PCDATA)
属性:なし
使用法:これは、発行者にとっての期間に関連付けられたデフォルトの好適な連絡方法が何かを示す。これは、「PreferredContact」要素と同じ値を有しうる。
【０１９０】
D.5           地域条件
D.5.1         LocalTime
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これは発行者の現地時間を示す。
【０１９１】
D.5.2         MeasuredLocation
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod、Accuracy
使用法:これはクライアント装置の測定位置を示す。測定はセンサによるもの(例えばGPS)またはネットワークによるものまたは両者の組合せでよい。Accuracyは、その方法によって達成される平均位置決め精度を示す。この内容には少なくとも横方向位置(x及びy座標)が含まれるが、垂直位置を含んでもよい。サービス・プロバイダが以下説明する「ConvertedLocation」をサポートする場合、このMeasuredLocationはサービス・プロバイダの変換処理、例えば地図照合のための入力情報となりうる。
【０１９２】
D.5.3         ConvertedLocation
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:この情報は典型的にはサービス・プロバイダ起源であるが、発行者起源であってもよい。これは、通りの名前のような人間に理解可能なテキスト形式で示されたユーザの位置を示す。この情報は、測定された位置を、例えば地図照合によってこの形式に変換することによって得られる。
【０１９３】
D.5.4         StatedLocation
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これは、発行者自身が表明した発行者の位置である。この内容は短いテキスト文字列である。
【０１９４】
D.5.5         UserEnvironment
内容モデル:(EnvAttributes+)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これはユーザに関するいくつかの環境属性を示す。
【０１９５】
D.5.6         EnvAttributes
内容モデル:(#PCDATA)
属性:なし
使用法:規定される属性は、「INDOOR」、「OUTDOOR」、「QUIET」、「NOISY」、「ALONE」、「IN_GROUP」である。
【０１９６】
D.6           個人状態
D.6.1         StatusText
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これはユーザが書いてもよい短いテキスト(約30文字)である。
【０１９７】
D.6.2         StatusImage
内容モデル:(#CDATA)
属性:Class、ID、Cacheability、ValidityPeriod、ImageType
使用法:これはユーザが自分の状態情報に添付してもよい画像である。これは、例えばbase64である転送符号化形式のXML内容で伝送される。ImageType属性は、画像の内容符号化、例えばjpegを記述する。
【０１９８】
D.6.3         StatusSound
内容モデル:(#CDATA)
属性:Class、ID、Cacheability、ValidityPeriod、SoundType
使用法:これはユーザが自分の状態情報に添付してもよい短い(約5〜30秒の)音声クリップである。これは、例えばbase64である転送符号化形式のXML内容で伝送される。SoundType属性は、音声の内容符号化、例えばAMR、MP3、AAC、MIDI等を記述する。
【０１９９】
D.7           クライアント機能
プレゼンスのコンテキストでのクライアント機能とは、様々な種類の人間対人間の通信のためのクライアントのホストとなる装置の機能を意味する。これは、アプリケーション・ソフトウェアがクライアント装置の既存のハードウェア及びソフトウェア機能を最大限に利用できるようにする場合とは大きく異なるさらに簡単な問題である。
人間対人間の通信のクラスは、メッセージング、電子メール、音声呼及びマルチメディア呼である。特に、プレゼンスは通信クラスから除外される。プレゼンスの目的は他者に通信手段及び他のユーザ属性を知らせることであって双方向通信自体ではない。このため、プレゼンス情報を分類するために「Client Capability」という用語を使用することはやや紛らわしい面がある。
クライアント機能はネットワーク機能で調べられる。これは例えば、発行者がビデオ呼機能を有しているのは、発行者のクライアント装置がその機能を有し、かつ発行者が現在ローミングしているネットワークがこの機能をサポートする時だけである、という意味である。このため、クライアント機能情報は動的である。
【０２００】
D.7.1         MessagingCapabilities
内容モデル:(MessType*)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これはクライアント装置の動的メッセージング機能リストを示す。リストが空であるのは、メッセージング機能が現在存在しないことを示す。
【０２０１】
D.7.2         MessType
内容モデル:(#PCDATA)
属性:なし
使用法:これはクライアント装置のメッセージング機能の種類を示す。内容は、「SMS」、「MMS」または「X-メッセージ・アプリケーション名」のうちの1つでよい。メッセージ・アプリケーション名のフィールドは、装置特有のメッセージング方法、例えばスマート・メッセージングである。
【０２０２】
D.7.3         EmailClient
内容モデル:(EmailClientType*)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これはクライアント装置の動的電子メール機能を示す。リストが空であるのは、電子メール機能が現在存在しないことを示す。
【０２０３】
D.7.4         EmailClientType
内容モデル:(#PCDATA)
属性:なし
使用法:これはクライアント装置の電子メール・クライアントの種類を示す。内容は、「SMTP」、「POP3」、「IMAP4」または「X-mail application name」のうちの1つでよい。クライアント・ソフトウェアはメール・プロトコル名自体をユーザに提供すべきではない。その代わり、クライアント・ソフトウェアはユーザ装置の電子メール環境を理解し、この電子メール環境の範囲内でプロトコル名を解釈すべきである。また、ユーザに提示される情報はユーザにとって有意であるべきである。
【０２０４】
D.7.5         VoiceCallCapability
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これはクライアント装置の動的音声呼機能を示す。内容は、「NONE」、「VOICE_CALL」、「RICH_VOICE_CALL」のうちの1つである。
【０２０５】
D.7.6         MultimediaCallCapabilities
内容モデル:(MMCap*)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これはユーザの動的単方向及び双方向通信機能を示す。リストが空であるのは機能が現在存在しないことを示す。
【０２０６】
D.7.7         MMCap
内容モデル:(#PCDATA)
属性:なし
使用法:これはマルチメディア呼機能の種類を示す。これは、「UPLINK_VIDEO_STREAMING」、「DOWNLINK_VIDEO_STREAMING」、「VIDEO_CALL」、「RICH_VIDEO_CALL」のうちの1つでよい。
【０２０７】
D.8           ユーザ属性
このクラスはユーザ規定及びクライアント特有両方のプレゼンス・データを含む。
【０２０８】
D.8.1         UserPresenceItem
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod、ExtRef、ExtRefChange
使用法:これはユーザが固有のプレゼンス項目を規定する手段を示す。同じ役割について1つより多いユーザ指定プレゼンス項目が規定される場合、ID属性の使用が必須である。内容は短いテキストでよい。随意選択の属性ExtRefはこのプレゼンス項目が参照する外部オブジェクトのURLである。このURLは、プレゼンス項目のXML文書を伝える多くの部分に分かれたMIMEの別の部分を参照してもよく、また外部オブジェクトへの参照でもよい。随意選択の属性ExtRefChangeを使用して、外部オブジェクトが変更されたことを加入者に示してもよい。
【０２０９】
D.8.2         ClientTypeRequest
内容モデル:(EMPTY)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:これは発行者が加入者のクライアント種類を要求するために使用する専用の要素である。発行者がこの要素をある役割に関するプレゼンス・データに含める場合、サーバは、PushPresenceメッセージと共にプレゼンス情報の全ての加入者にこれを送信する。これは、随意選択で、非加入者が特定のプレゼンス項目を要求するために使用するPresenceItemsメッセージ中に含まれてもよい。この要素はPresenceInfoメッセージでは定期的に配送されない。これは加入できるプレゼンス要素ではない。プレゼンス・サーバは、最初にこの項目を加入者に送信した後で、周期的にこの項目をその後のPushPresenceメッセージに含め、全ての加入者クライアントが確実にこの項目を有するようにしてもよい。
クライアントは、この項目を受信すると、自分のクライアント種類をプレゼンス・サーバに送信する。さらに、この項目がクライアントに格納されたプレゼンス情報である場合、クライアントは起動する都度その種類をサーバに送信すべきである。
発行者が自分の加入者のクライアント種類を知る別の方法は、発行者が加入者となってクライアント種類を申し込むことであろう。しかしこれは異なったビジネスモデルである。発行者は必ずしも自分自身の加入者のうちのひとりになりたいとは限らない。この要素によって発行者は、発行者とプレゼンス・サービス・プロバイダとの間の既存の契約上の枠組の中でクライアント種類を得ることができる。さらに、この方法によって、加入者クライアントは自分の種類をサーバに送信するよう義務付けられる。発行者が加入モデルを使用してクライアント種類を獲得している場合、この情報を発行者に対して許可するかどうかは加入者の自由である。
【０２１０】
D.8.3         ClientType
内容モデル:(ClientName、ClientManufacturer、ClientVersion)
属性:Class、ID、Cacheability、ValidityPeriod
使用法:加入者クライアント種類の知識は、プレゼンス集合に対するクライアント特有の拡張を可能にするために発行者が使用する。加入者クライアントが拡張項目を復号できない場合、発行者がこうした拡張項目を使用する意味はない。
加入者クライアントは、UpdatePresenceメッセージを使用してクライアント種類情報をプレゼンス・サーバに送信する。メッセージで使用されるGroupIDは発行者の役割に属し、加入者自身の役割には属さない。これは、ユーザがプレゼンス情報の更新を許可されているのは自分自身の役割だけであるという一般原則の例外である。プレゼンス・サーバは、PushPresenceメッセージを使用してこの要素の情報を発行者に送信する。使用されるGroupIDは発行者役割に属する。発行者の視点から言うと、発行者は自分自身のプレゼンス集合からプレゼンス情報を得る。
発行者は自分自身のクライアント種類を自分のプレゼンス集合に含めてもよい。その場合この情報は他のプレゼンス情報と同様に処理され、プレゼンス・サーバまたは加入者クライアントでの特殊な挙動を含まない。
【０２１１】
D.8.4         ClientName
内容モデル:(#PCDATA)
属性:なし
使用法:この要素はプレゼンス・クライアント・アプリケーションの名称を示す。
【０２１２】
D.8.5         ClientManufacture
内容モデル:(#PCDATA)
属性:なし
使用法：この要素はプレゼンス・クライアント製造業者の名称を示す。
【０２１３】
D.8.6         ClientVersion
内容モデル:(#PCDATA)
属性:なし
使用法:この要素はクライアント・アプリケーションのバージョンを示す。
【０２１４】
D.8.7         ClientPresenceItem
内容モデル:(ClientType、CliPresItem)
属性:Class、ID、Cacheability、ValidityPeriod、ContentChange
使用法:この要素は発行者のクライアント・アプリケーション特有のプレゼンス項目である。ClientTypeは発行者のプレゼンス・クライアントのクライアント種類である。この要素の一部として使用される場合、ClientType項目中では属性は使用されない。発行者が1つより多いクライアント特有のプレゼンス項目を規定する場合、ID属性の使用が必須である。随意選択の属性ContentChangeは0から255までのカウンタである。これは、使用される場合、プレゼンス項目の内容が変更される都度1つ増える。これは、プレゼンス・サーバに、非標準プレゼンス項目の内容の変更を検出する代替手段を提供する。プレゼンス・サーバにとって別の代替案は、この項目が同じID属性と共にサーバに送信される都度内容が変更されると想定することであろう。サーバは、ContentChange属性がクライアントによって使用されていない場合このような挙動を取る。同じID属性を有する2つの項目がContentChange中で同じカウンタ値を有する場合、これら2つの項目の内容は同一である。
【０２１５】
D.8.8         CliPresItem
内容モデル:(#PCDATA)
属性:なし
使用法:この要素はクライアント特有のプレゼンス拡張である。その構文及び構造はクライアントには既知だがネットワーク要素には知られていないと想定される。
【０２１６】
D.9           拡張プレゼンス・サービス
拡張プレゼンス・サービス・クラスは、サービス・プロバイダ特有の拡張をプレゼンス・サービスに提供するようになっている。クライアント・アプリケーション特有の拡張と同様、拡張を復号できる必要があるのはサービスの端点(すなわち、発行者と加入者クライアント)だけである。プレゼンス・サーバが拡張機能を理解することもありうるが、それはこの明細書によって義務付けられるわけではない。クライアント特有の拡張の方法とこの方法との間の相違は、サービス・プロバイダが制御するクライアントは標準プレゼンス項目を実装する必要がないことである。プレゼンス項目はサービス・プロバイダによって完全に規定されており、ユーザ装置をホストとするクライアントを新しい機能によって更新する手段が存在すると想定する。1つの可能な更新方法は無線によるソフトウェア・ダウンロードである。新しい種類のプレゼンス項目を生成する場合、サービス・プロバイダはこの新しい種類のプレゼンス項目をサポートするよう既存のクライアントを更新する必要がある。サービス・プロバイダが制御するクライアントは、標準プレゼンス・クライアント経由ではなく直接プレゼンス・サーバと通信する。標準プレゼンス・クライアントはこのクラスの全ての要素を無視する。
拡張プレゼンス・サービスは主としてこのクラスの要素を使用する。標準プレゼンス要素の規定を使用することも可能である。これは標準プレゼンス・プロトコルを使用する。
【０２１７】
D.9.1         ExtPresence
内容モデル:(#PCDATA)
属性:Class、ID、Cacheability、ValidityPeriod、ContentChange
使用法:この機構によって1つより多いプレゼンス項目が規定される場合ID属性の使用は必須である。随意選択のContentChange属性もこの要素について利用可能である。コンテンツの構文及び表示は本明細書の範囲外である。プレゼンス・サーバとプロキシによって、コンテンツはこの要素を含むXML文書と同じ多くの部分に分れたMIME中で伝えられるオブジェクトを参照できるようになる。
【０２１８】
D.10           プレゼンス内容フォーマット用DTD
【０２１９】
【表２０】
2004532478.tif 000022
【０２２０】
【表２１】
2004532478.tif 000023
【０２２１】
【表２２】
2004532478.tif 000024
【０２２２】
【表２３】
2004532478.tif 000025
【０２２３】
【表２４】
2004532478.tif 000026
【０２２４】
【表２５】
2004532478.tif 000027
【０２２５】
【表２６】
2004532478.tif 000028
【０２２６】
【表２７】
2004532478.tif 000029
【０２２７】
D.11           PresenceNames用DTD
PresenceNames用DTDは、プレゼンス項目名と属性だけが含まれていること以外はプレゼンス用のものと同じである。プレゼンス値は使用されない。
【０２２８】
【表２８】
2004532478.tif 000030
【０２２９】
【表２９】
2004532478.tif 000031
【０２３０】
【表３０】
2004532478.tif 000032
【０２３１】
【表３１】
2004532478.tif 000033
【０２３２】
【表３２】
2004532478.tif 000034
【０２３３】
【表３３】
2004532478.tif 000035
【０２３４】
【表３４】
2004532478.tif 000036
【０２３５】
【表３５】
2004532478.tif 000037
【０２３６】
当業者に明らかなように、技術の進歩に伴って、本発明の概念は多くの異なった方法で実現できる。従って、本発明とその実施例は上記の例に制限されず、添付の請求項の範囲と精神において変化しうる。
【図面の簡単な説明】
【０２３７】
【図１】図1は、移動IMPSシステムを説明するブロック図を示す図である。
【図２】図2は、プレゼンス属性の送信を説明するシグナリング図を示す図である。
【図３】図3は、修飾子の使用法を説明するシグナリング図を示す図である。
【図４】図4は、本発明による、少なくとも1つのクライアント装置とサーバとを備える移動メッセージング・システムの1つの実施例を示す図である。
【図５】図5は、本発明による、少なくとも1つのクライアント装置とサーバとを備える移動メッセージング・システムの別の実施例を示す図である。
【図６】図6は、本発明によるプレゼンスの構成を示す図である。
【図７】図7は、本発明によるプレゼンス・データベースを示す図である。
【図８】図8は、本発明による未加入プレゼンスの流れ図を示す図である。
【図９】図9は、本発明によるプレゼンス情報の加入済配信を示す図である。
【図１０】図10は、本発明によるユーザ・グループとプレゼンス集合との管理を示す図である。
【図２】
2004532478.tif 000038
【図３】
2004532478.tif 000039
【図４】
2004532478.tif 000040
【図５】
2004532478.tif 000041
【図６】
2004532478.tif 000042
【図７】
2004532478.tif 000043
【図８】
2004532478.tif 000044
【図９】
2004532478.tif 000045
【図１０】
2004532478.tif 000046
【国際公開パンフレット】
2004532478.tif 000047
2004532478.tif 000048
2004532478.tif 000049
2004532478.tif 000050
2004532478.tif 000051
2004532478.tif 000052
2004532478.tif 000053
2004532478.tif 000054
2004532478.tif 000055
2004532478.tif 000056
2004532478.tif 000057
2004532478.tif 000058
2004532478.tif 000059
2004532478.tif 000060
2004532478.tif 000061
2004532478.tif 000062
2004532478.tif 000063
2004532478.tif 000064
2004532478.tif 000065
2004532478.tif 000066
2004532478.tif 000067
2004532478.tif 000068
2004532478.tif 000069
2004532478.tif 000070
2004532478.tif 000071
2004532478.tif 000072
2004532478.tif 000073
2004532478.tif 000074
2004532478.tif 000075
2004532478.tif 000076
2004532478.tif 000077
2004532478.tif 000078
2004532478.tif 000079
2004532478.tif 000080
2004532478.tif 000081
2004532478.tif 000082
2004532478.tif 000083
2004532478.tif 000084
2004532478.tif 000085
2004532478.tif 000086
2004532478.tif 000087
2004532478.tif 000088
2004532478.tif 000089
2004532478.tif 000090
2004532478.tif 000091
2004532478.tif 000092
2004532478.tif 000093
2004532478.tif 000094
2004532478.tif 000095
2004532478.tif 000096
2004532478.tif 000097
2004532478.tif 000098
2004532478.tif 000099
2004532478.tif 000100
2004532478.tif 000101
2004532478.tif 000102
2004532478.tif 000103
2004532478.tif 000104
2004532478.tif 000105
2004532478.tif 000106
2004532478.tif 000107
2004532478.tif 000108
2004532478.tif 000109
2004532478.tif 000110
2004532478.tif 000111
2004532478.tif 000112
2004532478.tif 000113
2004532478.tif 000114
2004532478.tif 000115
2004532478.tif 000116
2004532478.tif 000117
2004532478.tif 000118
2004532478.tif 000119
2004532478.tif 000120
2004532478.tif 000121
2004532478.tif 000122
2004532478.tif 000123
2004532478.tif 000124
2004532478.tif 000125
2004532478.tif 000126
2004532478.tif 000127
2004532478.tif 000128
2004532478.tif 000129
2004532478.tif 000130
2004532478.tif 000131
2004532478.tif 000132
2004532478.tif 000133
2004532478.tif 000134
2004532478.tif 000135
2004532478.tif 000136
2004532478.tif 000137
【国際調査報告】
2004532478.tif 000138
2004532478.tif 000139
2004532478.tif 000140