(57)【要約】公開認可ルールの使用により公開委任を可能にするシステムおよび方法が提供される。プレゼンティティは、別のエンティティ、例えば、パブリッシャが、自身に代わって当該プレゼンティティに関連するプレゼンス情報を公開することを許可する。加えて、例えば、プレゼンティティが公開を許可されているプレゼンス情報を、サービスプロバイダが制限する能力が提供される。したがって、プレゼンス情報が公開されるプレゼンティティ以外の、（識別情報を有する）ユーザに、ルールが一致する場合、公開委任を達成することが可能である。さらに、許可されたプレゼンス情報に対するサービスプロバイダの制限も、プレゼンティティの識別情報にルールが一致する場合に提供することが可能である。【選択図】図２
2011513806.tif 000002
【特許請求の範囲】
【請求項１】
公開委任のための方法であって、
プレゼンティティのプレゼンス情報を、前記プレゼンティティまたは別のプレゼンティティの代わりに公開することの要求を受信することと、
公開認可ルールの適用に必要な条件が存在するか否かを判断することと、
前記条件が存在する場合、該条件に基づいて前記公開要求を許可するかブロックするかを判断することと、
前記公開要求を許可すると判断した場合、公開コンテンツルールに従って、前記プレゼンス情報を変換することと、
を含む、方法。
【請求項２】
前記要求は、前記プレゼンティティとは異なるパブリッシャ・エンティティから送信される、請求項１に記載の方法。
【請求項３】
前記条件は、前記公開認可ルールの条件要素で規定される、請求項１に記載の方法。
【請求項４】
前記公開要求を許可するかブロックするかを前記判断することは、前記公開認可ルールの実装要素に基づく決定にさらに基づく、請求項１に記載の方法。
【請求項５】
前記プレゼンティティの前記プレゼンス情報の前記変換は、前記公開認可ルールの変換要素で規定される、請求項１に記載の方法。
【請求項６】
前記変換要素は、前記プレゼンス情報を表すプレゼンスドキュメントのどのデータ要素について公開が許可されるかを制御するために前記公開コンテンツルールを記述する、請求項５に記載の方法。
【請求項７】
前記プレゼンティティの識別情報に関連するコンテンツルールを把握することをさらに含み、前記プレゼンティティの代わりに、プレゼンスソースが、前記プレゼンティティの前記プレゼンス情報を公開している、請求項６に記載の方法。
【請求項８】
前記プレゼンティティの前記プレゼンス情報を公開することの前記要求は、プレゼンスサーバにより受信される、請求項１に記載の方法。
【請求項９】
前記公開要求を前記ブロックすることは、ポリシーコンタクトヘッダフィールドを含む応答により、前記公開要求に応答することをさらに含む、請求項１に記載の方法。
【請求項１０】
前記ポリシーコンタクトヘッダフィールドは、前記公開認可ルールを含むドキュメントの統一資源識別子を示す、請求項９に記載の方法。
【請求項１１】
コンピュータ可読媒体上に具現化され、請求項１に記載のプロセスを実行するように構成されるコンピュータプログラム製品。
【請求項１２】
プロセッサと、前記プロセッサに通信可能に接続されるメモリユニットとを備え、前記メモリユニットが、
プレゼンティティのプレゼンス情報を、前記プレゼンティティまたは別のプレゼンティティの代わりに公開することの要求、すなわち公開委任の要求を、受信し処理するように構成されるコンピュータコードと、
公開認可ルールの適用に必要な条件が存在するか否かを判断するように構成されるコンピュータコードと、
前記条件が存在する場合、該条件に基づいて前記公開要求を許可するかブロックするかを判断するように構成されるコンピュータコードと、
前記公開要求を許可すると判断した場合、公開コンテンツルールに従って、前記プレゼンス情報を変換するように構成されるコンピュータコードと、
を格納する、装置。
【請求項１３】
前記要求は、前記プレゼンティティとは異なるパブリッシャ・エンティティから送信される、請求項１２に記載の装置。
【請求項１４】
前記条件は、前記公開認可ルールの条件要素で規定される、請求項１２に記載の装置。
【請求項１５】
前記公開要求を許可するかブロックするかを前記判断することは、前記公開認可ルールの実装要素に基づく決定にさらに基づく、請求項１２に記載の装置。
【請求項１６】
前記プレゼンティティの前記プレゼンス情報の前記変換は、前記公開認可ルールの変換要素で規定される、請求項１２に記載の装置。
【請求項１７】
前記変換要素は、前記プレゼンス情報を表すプレゼンスドキュメントのどのデータ要素について公開が許可されるかを制御するために前記公開コンテンツルールを記述する、請求項１６に記載の装置。
【請求項１８】
前記メモリユニットは、前記プレゼンティティの識別情報に関連するコンテンツルールを把握するように構成されるコンピュータコードをさらに含み、前記プレゼンティティの代わりに前記プレゼンティティの前記プレゼンス情報を公開している、請求項１７に記載の装置。
【請求項１９】
前記公開要求を前記ブロックすることは、ポリシーコンタクトヘッダフィールドを含む応答により、前記公開要求に応答することをさらに含む、請求項１２に記載の装置。
【請求項２０】
前記ポリシーコンタクトヘッダフィールドは、前記公開認可ルールを含むドキュメントの統一資源識別子を示す、請求項１９に記載の装置。
【請求項２１】
プレゼンティティのプレゼンス情報を、前記プレゼンティティまたは別のプレゼンティティの代わりに公開することの要求を受信する手段と、
公開認可ルールの適用に必要な条件が存在するか否かを判断する手段と、
前記条件が存在する場合、該条件に基づいて前記公開要求を許可するかブロックするかを判断する手段と、
前記公開要求を許可すると判断した場合、公開コンテンツルールに従って、前記プレゼンス情報を変換する手段と、
を備える、公開委任のためのシステム。
【請求項２２】
前記要求は、前記プレゼンティティとは異なるパブリッシャ・エンティティから送信される、請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、プレゼンスサービスに関する。より具体的には、本発明は、許可されたプレゼンス情報に対する公開の委任（delegation）と制限（restriction）とを規定する公開認可ポリシー（publication authorization policy）および／または公開認可ルール（publication authorization rule）に関する。
【背景】
【０００２】
本項は、請求項に列挙する発明の背景事情を提供することを意図する。本項における説明は、追求されてもよい概念を含んでもよいが、必ずしも過去に着想または追求された概念であるとは限らない。したがって、本明細書において別途明示されない限り、本項に説明するものは、本願明細書及び特許請求の範囲に対する従来技術ではなく、本項に含められているからといって直ちに従来技術であると考えてはならない。
【０００３】
オープンモバイルアライアンス（Open Mobile Alliance; OMA）は、モバイル業界で使用するオープン規格を共同で開発しようとする標準化団体である。OMAは、世界各国で稼働する相互運用サービスイネーブラ、オペレータ、モバイル端末の開発を支援し、市場の要求に応じて作業を行っている。モバイル市場を拡大するために、オープンモバイルアライアンスを支持する会社は、多種多様の新しい強化されたモバイル情報、通信、娯楽サービスの急速かつ幅広い開発・展開の支援に取り組んでいる。
【０００４】
OMAは、現在、プレゼンスサービスおよびXMLドキュメント管理（XML Document Management; （XDM）サービスを開発中である。これは、セッション初期プロトコル（Session Initiation Protocol; SIP）と、拡張可能マークアップ言語（Extensible Markup Language; XML）構成アクセスプロトコル（XML Configuration Access Protocol; XCAP）プロトコルとに基づいている。後者は、国際技術標準化タスクフォース（International Engineering Task Force; IETF）のインスタントメッセージおよびプレゼンス用のSIP拡張（SIP for Instant Messaging and Presence Leveraging Extensions; SIMPLE）作業グループにより開発されている。
【０００５】
プレゼンスサービスは、プレゼンス情報を受け入れ、格納し、配信するネットワークサービスまたはシステムを表すことがある。この場合、プレゼンス情報は、種々の制御を受ける可能性がある。また、プレゼンス情報の収集および配信について、例えば、公開、サブスクリプション、通知の方法について、ならびに通信意欲、機器状態等のプレゼンス情報に含まれ得るコンテンツの種類について、各種の要件が規定されている。プレゼンス情報は、例えば、特定のプレゼンティティに関する動的な情報のセットを指してもよい。このような情報は、例えば、通信パートナーの通信能力や、通信意欲を表す状態インジケータを含んでもよい。さらに、プレゼンスサービスは、多くの他のサービスやイネーブラとリンクされてもよい。
【０００６】
上述のように、プレゼンスサービスについて要件が特定されており、これらの要件のうちの少なくともいくつかは、OMA SIMPLE PRESENCE 2.0 Requirements Documentに列挙されている。OMA SIMPLE PRESENCE 2.0 Requirements Documentでは、イネーブラは、次の要件を有するものとして定義されている。
2011513806.tif 000003
2011513806.tif 000004
【０００７】
従来のプレゼンスサービスは、プレゼンス認可ルール（presence authorization rule）と呼ばれる、サブスクリプションを処理するための認可ポリシーを含む。このようなプレゼンス認可ルールは、特定のプレゼンティティのプレゼンス情報へのサブスクリプションを許可された（またはサブスクリプションが許可されない）、あるウォッチャについて記述する。
【０００８】
プレゼンス公開委任（presence publication delegation）は、ユーザやアプリケーションが、他のユーザに代わってプレゼンス情報の公開を実行することを許可する機能であり、OMA SIMPLE Presence 2.0の重要な特徴である。例えば、秘書が、上司の代わりにプレゼンス情報を公開することができ、またはユーザのコンピュータ上にあるカレンダーアプリケーションが、ユーザの代わりにユーザのプレゼンス情報を公開することができる。
【０００９】
サブスクリプションについてのプレゼンス認可ルールに関する詳細は、OMA SIMPLE Presence Technical Specification （TS） 2.0およびOMA SIMPLE Presence Extensible Markup Language Document Management （XDM） TS 2.0において説明されている。OMA SIMPLE Presence TS 2.0のドキュメントに説明されるように、プレゼンス認可ルールは、サブスクリプション認可ルール（subscription authorization rule）およびプレゼンスコンテンツルール（presence content rule）を含む。サブスクリプション認可ルールは、受信したサブスクリプションの取り扱い方法を定め、プレゼンスコンテンツルールは、適用可能なサブスクリプション認可ルールに基づいて受け入れられたウォッチャに何のまたはどのプレゼンス情報が伝達されるかを定める。
【発明の概要】
【００１０】
種々の実施形態は、プレゼンスサービスにおいて公開認可ルールを策定および施行し、プレゼンティティ（Presentity）に関連するプレゼンス情報の公開が、プレゼンティティの代わりにパブリッシャ（Publisher，公開要素）に委任されるようにする。また、種々の実施形態は、ポリシーにおけるコンテンツルールについて、パブリッシャが単一のトランザクションで把握する方法を定義するシステムおよび方法を提供する。このことにより、SIPシグナリングを介して実際の公開に使用するポリシーを（部分的に）把握する際に、不要なおよび／または過剰なトランザクションを回避することが可能となる。加えて、サービスプロバイダには、プレゼンティティが公開を許可されるプレゼンス情報を制限する能力が提供されうる。したがって、プレゼンス情報が公開されるプレゼンティティ以外の、（識別情報を有する）ユーザに、ルールが一致する場合、公開委任が行われうる。
【００１１】
さらに、プレゼンティティの識別情報にルールが一致する場合、許可されたプレゼンス情報に対するサービスプロバイダ制限も行われてもよい。
【００１２】
本発明の種々の実施形態は、（OMAにより規定される、）インターネットメッセージングおよびプレゼンスサービス（Internet Messaging and Presence Services; IMPS）、SIMPLEプレゼンス、ならびに拡張可能メッセージングおよびプレゼンスプロトコル（Extensible Messaging and Presence Protocol; XMPP）（インターネット技術標準化タスクフォース（Internet Engineering Task Force; IETF）により規定される）を含む、実質的にいかなるプレゼンスソリューションにも適用可能である。
【００１３】
本発明の種々の実施形態に関するこれらの利点および特徴ならびに他の利点および特徴と、その動作の機構および方式とは、添付の図面を併用して、以下の発明を実施するための形態により、より明らかとなる。添付の図面において、同一の要素は同一の符号を有する。
【図面の簡単な説明】
【００１４】
本発明の実施形態について、添付の図面を参照することによって説明する。
【図１】種々の実施形態に従う、例示的プレゼンスサービスアーキテクチャを図示する。
【図２】公開委任のための種々の実施形態に従い実行される処理を説明するフローチャートを図示する。
【図３】本発明の種々の実施形態が内部に実装されうるシステムの概略図である。
【図４】本発明の種々の実施形態の実装とともに使用可能な電子機器の斜視図である。
【図５】図４の電子機器に備えられうる回路の略図である。
【好適な実施形態の詳細な説明】
【００１５】
種々の実施形態は、公開認可ルールの使用により公開委任を可能にするシステムおよび方法を提供する。プレゼンティティは、別のエンティティ、例えば、パブリッシャが、自身に代わって当該プレゼンティティに関連するプレゼンス情報を公開することを許可する。加えて、種々の実施形態は、公開認可ルールがプレゼンティティ自体のルールも含んでもよいため、プレゼンティティが公開を許可されているプレゼンス情報を、サービスプロバイダが制限する能力を提供する。したがって、プレゼンス情報が公開されるプレゼンティティ以外の、（識別情報を有する）ユーザにルールが一致する場合に、公開委任が達成されてもよい。さらに、許可されたプレゼンス情報に対するサービスプロバイダの制限も、プレゼンティティの識別情報にルールが一致する場合に、達成されてもよい。
【００１６】
前述の公開認可ルールに関し、公開認可ポリシーにおけるルールは、受信する公開の取り扱い方法（例えば、許可またはブロック）を定め、また、ユーザやアプリケーションが公開を許可される実際のプレゼンス情報自体を判断する。インターネット技術標準化タスクフォース（Internet Engineering Task Force; IETF）のコメント要求（Request For Comments; RFC）3903（http://www.ietf.org/rfc/rfc3903.txtから入手可能である）は、プレゼンスサービスのPUBLISHメソッドについて説明している。IETFのRFC5025（http://www.ietf.org/rfc/rfc5025.txtから入手可能である）は、サブスクリプションを取り扱うためのフレームワークと、プレゼンスサーバが行ない得る関連の決定とについて説明している。
【００１７】
しかしながら、公開されたプレゼンス情報内の一部の（または全部の）プレゼンス情報要素が、何らかの理由により（例えば、公開認可ルールのコンテンツポリシーに起因して）プレゼンスサーバにより受け入れ不可能であることを示す方法については、何ら説明が存在しない。したがって、公開認可コンテンツルールが規定されるとしても、プレゼンスソースのうち許可されたコンテンツのどれが公開可能であるかを、プレゼンスサーバがプレゼンスソースに示し得る既知のプロトコルまたは方法が存在しない。さらに、公開委任のための公開認可を処理するための方法に関する説明が存在しない。 
【００１８】
上記問題を処理するためのために想定される方法の１つとして、PUBLISH応答（PUBLISH response）の本文内で、コンテンツポリシーをプレゼンスソースに示すことが挙げられる。例えば、200(OK)応答は、公開コンテンツの全てを受け入れることを表し、一方、メッセージボディを含む202(Accepted)応答は、プレゼンス情報の一部のみが認可されることを示し得る。しかし、PUBLISH応答における本文は意味を持たないため、コンテンツポリシーの標示に想定される方法を実装するのであれば、IETF RFC 3903に違反することになるか、またはIETF RFC 3903に対する更新が必要になることを、IETF RFC 3903は明らかに示している。加えて、プレゼンスソースは、公開中のプレゼンス情報に該当する一部の部分的なポリシーしか認識しないことになり、結果として、プレゼンスソースが残りの部分のコンテンツポリシーを発見するために、不必要なトランザクション交換を行わざるをえなくなる。
【００１９】
さらに、不必要なトランザクション交換により、公開応答を介して同一のポリシールールが繰り返し伝送されることも潜在的に生じうることになる。つまり、プレゼンスソースは、該当するコンテンツポリシーを完全に把握することができないので、代わりに公開を繰り返し試行し、成功すれば、プレゼンスサーバの返信に基づいて、複数のポリシールールから１つのポリシーを自分で組み上げる。前述のように、このようなプロセスは、ポリシードキュメントを構築するために、プレゼンスソースにおいて不必要なトラフィックやロジックを生ずる可能性がある。
【００２０】
図１は、例示的プレゼンスサービスアーキテクチャ100を図示する。プレゼンティティ110は、プレゼンティティに関連するプレゼンス情報を有する論理エンティティ、例えば、人、特定のサービス等を含む。プレゼンティティ110に関連するプレゼンス情報は、１つ以上のプレゼンスソース120から生じ得るか、または１つ以上のプレゼンスソース120により構築されてもよい。言い換えると、プレゼンスソース120は、プレゼンス情報を「公開」する。プレゼンスソース120は、例えば、プレゼンスユーザエージェント、プレゼンスエージェントとして動作するネットワーク要素、会社のカレンダー等のアプリケーション等を含んでもよく、または代替として、モバイル端末に搭載されていてもよい。
【００２１】
プレゼンスサーバ130は、プレゼンスソース120からプレゼンス情報を受信するとともに、例えば、受信したプレゼンス情報のインスタンスを使用可能なフォーマットに変換するネットワーク100の別の論理エンティティである。すなわち、プレゼンスサーバ130は、プレゼンティティに関連する１つ以上のプレゼンスソースからの公開を処理する。公開は、プレゼンス情報をリフレッシュすること、プレゼンス情報を置換すること、またはプレゼンス情報を削除することを含んでもよい。公開を処理することは、変換後にプレゼンス情報をウォッチャ140に転送することを指してもよい。ウォッチャ140は、ネットワーク100における任意の一意的に識別可能なエンティティであって、任意の１つ以上のプレゼンティティ110に関するプレゼンス情報をプレゼンスサービスから要求するエンティティを指してもよい。ウォッチャ140は、「サブスクリプション」を介してプレゼンス情報を要求してもよい。サブスクリプションは、プレゼンスサービスによって保持される、サブスクリプションを有する者の要求についての情報を表してもよい。この要求は、１つまたはそれ以上のプレゼンティティ110のプレゼンス情報に変更があった場合に通知されることの要求であることができる。サブスクリプションを有する者とは、ウォッチャ140であってもよいことに注意されたい。すなわち、ウォッチャ140が、１つまたはそれ以上のプレゼンティティ110のプレゼンス情報に変更があった場合に通知されることを要求した装置であってもよい。
【００２２】
一貫性および簡略化のために、公開委任に関連する任意の公開認可ルールが、サブスクリプションのためのプレゼンス認可ルールと類似または同等のフォーマットを有することが有利である。
【００２３】
アプリケーション特有のデータへのアクセスするための認可ポリシーを策定するためのフレームワークは、http://www.ietf.org/rfc/rfc4745.txtで入手可能なIETF RFC 4745に定義されている。ゆえに、種々の実施形態は、IETF RFC 4745において説明され、かつOMA SIMPLE Presence XDM TS 2.0において拡張される公開認可ルールを使用して、プレゼンス公開委任およびプレゼンス情報制限を実装してもよい。かかる公開認可ルールは、共通ポリシー構造に適合するように構成される。
【００２４】
種々の実施形態に従う公開認可ルールの各々は、<rule>要素のシーケンスを含む。各ルールは、少なくとも３つの部分、つまり、「条件（conditions）」要素、「アクション（actions）」要素、および「変換（transformations）」要素を含む。条件要素は、プレゼンスサーバ処理にルールを適用する条件を特定してもよい。アクション要素は、どのアクションを行なうべきかについてプレゼンスサーバに命令してもよい。変換要素は、プレゼンスサーバが実行するアクション、例えば、プレゼンスソースが公開を許可される認可されたプレゼンス情報を示す。
【００２５】
種々の実施形態は、プレゼンスサーバが行なう公開認可決定を特定する<pub-handling>要素を提供する。プレゼンスサーバは、<pub-handling>要素に、<rule>要素の<actions>子要素を関連付ける。種々の実施形態において、値「ブロック（block）」および「許可（allow）」が、公開認可ルールにおいて意味を有することに留意されたい。値「許可」について、プレゼンスサーバは、提案された公開を受け入れ、200(OK)応答を返送する。値「ブロック」では、プレゼンスサーバは、提案された公開を拒否し、403(Forbidden)応答を返送する。
【００２６】
図２は、プレゼンティティの代わりに別のパブリッシャによりプレゼンス情報を公開することを許可するために実行される例示的プロセスを図示するフローチャートである。加えて、これらの例示的プロセスを使用して、例えば、サービスプロバイダが、許可されたプレゼンス情報に一定の制限を適用することを望むシナリオを取り扱うことが可能である。
【００２７】
200において、プレゼンティティのプレゼンス情報の公開に関する要求が、パブリッシャから受信される（例えば、プレゼンスサーバにおいて）。これは、前記プレゼンティティまたは別のプレゼンティティの代わりに公開を行うことの要求である。
【００２８】
210において、プレゼンスサーバは、適用可能な公開認可ルールの<condition>要素に基づいて、公開認可ルールの適用に必要な適切な条件が存在するか否かを判断する。例えば、プレゼンスサーバがこれらの公開認可ルールを適用しうるように、パブリッシャの識別情報に一致する条件が存在するか否かが判断されてもよい。しかし、例えば、パブリッシャの識別情報に一致する条件が存在しない場合、デフォルトのアクションは、公開をブロックするとすることが可能である。さらに、プレゼンス情報の制限と呼ばれる公開認可ルールをプレゼンティティ自体に適用してもよいことに留意されたい。代替として、上述のように、公開認可ルールを別のプレゼンティティに適用してもよく、これは、委任（delegation）と呼ばれる。
【００２９】
220において、プレゼンスサーバは、公開認可ルールの<actions>要素に従って、条件に基づいてどのアクションを行なうべきかを判断し、条件が存在する場合、共通ポリシールールセットの組み合わせロジックに従ってルールを組み合わせ、変換と、結果として行うアクションを決定する。例えば、適用可能な<actions>要素は、公開が、230において許可されたかブロックされたかを決定するように、プレゼンスサーバに命令する。得られた結論が公開許可である場合、240において、プレゼンスサーバは、組み合わせられた変換（公開コンテンツルール）に基づいてプレゼンス情報を決定する。<transformations>要素は、公開されたプレゼンス情報をフィルタリングし、<transformations>要素の子要素により明示的に特定されたプレゼンス要素のみを許可するようにプレゼンスサーバに命令する。しかしながら、公開をブロックする決定が行なわれた場合、公開要求は完全に拒否され（250）、403（Forbidden）応答が送信される。
【００３０】
公開されたプレゼンス情報が許可され、公開されたプレゼンス情報が公開コンテンツルールに一致する場合、260において、200(OK)応答が送信される。代替として、270において、公開されたプレゼンス情報が公開コンテンツルールに（部分的または全体的に）一致しない場合、Policy-Contactヘッダフィールドを含む488(Not Acceptable Here)応答が送信される。このPolicy-Contactヘッダフィールドは、公開認可ルールドキュメントを示すURIを含む。
【００３１】
また、種々の実施形態において、公開認可ルールの<transformations>要素は、コンテンツルールを記述する。例えば、変換（transformations）の第１のグループによって、人、機器、サービスデータの要素を、これらの要素のためのいくつかの識別情報に基づいて公開することが可能になってもよい。変換（transformations）の別のグループによって、プレゼンスドキュメントにおける特定のデータ要素の公開が可能になってもよい。例えば、種々の実施形態によると、<allow-note>要素は、特定のパブリッシャによる<note>要素の公開を制御するように提供される。
【００３２】
また、種々の実施形態は、あるプレゼンティティの代わりにプレゼンスソースがプレゼンス情報を公開している場合、当該プレゼンティティの識別情報に関連する重要なコンテンツルールを前記プレゼンスソースが把握することを可能にするシステムおよび方法も提供する。すなわち、一致する公開認可ルール（例えば、パブリッシャの識別情報に一致する<identity>要素を含むルール）から組み合わせられた<transformations>要素を利用するため、名称が「A Framework for Session Initiation Protocol （SIP） Session Policies」であるdraft-ietf-sip-session-policy-framework-02覚書に提示される処理やSIP拡張の再利用が可能になる。
【００３３】
パブリッシャが、プレゼンティティにより認可されないプレゼンス要素を公開しようとしている場合、プレゼンスサーバは、Policy-Contactヘッダフィールドを含む488（Not Acceptable Here）応答により公開を拒否する。Policy-Contactヘッダフィールドは、例えば、種々の実施形態に従って策定された公開認可ルールを含むドキュメントの統一資源識別子（Uniform Resource Identifier; URI）を示すために利用される。ドキュメントはプレゼンスXDMSに格納しうることに留意されたい。
【００３４】
Policy-Contactヘッダフィールドを含む488（Not Acceptable Here）応答を受信した後、プレゼンスソースは、プレゼンスXDMSから公開認可ルールを取り出し、公開に適用可能なコンテンツルールを発見しようとする。プレゼンスXDMSは、そのプレゼンスソースの識別情報を、ルールの条件要素に存在する識別情報と照らし合わせ、一致するルールから組み合わせられた<transformations>要素のみを返送する。したがって、パブリッシャは、その特定のパブリッシャの識別情報に該当するポリシーのみを判別することが可能であるため、パブリッシャがポリシー全体を把握する可能性は回避される。プレゼンスXDMSからコンテンツルールの該当する部分を受信した後、プレゼンスソースは、発見された公開認可ルールにより認可される公開のために、適切なプレゼンスドキュメントを作成してもよい。さらに、任意の他のXDMドキュメントと同様に、プレゼンスソースは、XDM Core 2.0仕様書において説明されるように、ポリシードキュメントにおける変更にサブスクライブしてもよい。代替として、公開の試行が失敗するが、ポリシードキュメントのローカルコピー（例えばキャッシュしたコピー）によって、プレゼンスドキュメントが公開可能になる場合、プレゼンスソースは、最新の（例えば変更した）ドキュメントを取り出してもよい。
【００３５】
種々の実施形態は、プレゼンスサービスにおいて公開認可ルールを策定および施行するために使用されてもよい。加えて、種々の実施形態は、ポリシー内におけるコンテンツルールについてパブリッシャが単一のトランザクションで把握する方法を定義するシステムおよび方法を提供する。従って、実際の公開に使用する（部分的な）ポリシーを（SIPシグナリングを介して）発見する場合には、不要なおよび／または過剰なトランザクションは、回避される。すなわち、種々の実施形態によると、ポリシーのダウンロードは、SIPシグナリングから分離可能である。例えば、公開認可ルールドキュメントは、ポリシー情報をSIPシグナリングメッセージにピギーバックする代わりに、プレゼンスXDMSから入手可能であり、この場合、ポリシー情報の一部は、拒否される公開に該当する"不成功PUBLISH（unsuccessful PUBLISH）"トランザクション応答毎に含まれる。
【００３６】
種々の実施形態の上記サンプル実装の多くは、SIMPLEプレゼンス環境において説明される。しかしながら、当業者であれば、本発明の種々の実施形態が、他のプレゼンスソリューションにも適用可能であることを理解するであろう。
【００３７】
図３は、本発明の種々の実施形態が利用可能であり得るシステム10を示す。このシステムは、１つ以上のネットワークを介して通信し得る複数の通信機器を備える。システム10は、携帯電話機ネットワーク、無線ローカルエリアネットワーク（Local Area Network; LAN）、Bluetoothパーソナルエリアネットワーク、イーサネット（登録商標）LAN、トークンリングLAN、広域ネットワーク、インターネット等を含むが、これらに限定されない有線ネットワークまたは無線ネットワークの任意の組み合わせを含んでもよい。システム10は、有線・無線の両方の通信機器を含んでもよい。
【００３８】
例示のために、図３に示すシステム10は、携帯電話機ネットワーク11およびインターネット28を含む。インターネット28に対する接続性には、長距離無線接続、短距離無線接続、ならびに電話線、ケーブル線、電力線、およびその同等物を含むがこれらに限定されない、種々の有線接続が含まれうるが、これらに限定されない。
【００３９】
システム10の例示的通信機器には、電子機器12、携帯情報端末（personal digital assistant; PDA）および携帯電話機14の組み合わせ、PDA16、一体型メッセージング機器（Integrated Messaging Device; IMD）18、デスクトップ型コンピュータ20、ならびにノート型コンピュータ22等が含まれうるが、これらに限定されない。
【００４０】
通信機器は、固定型であってもよく、移動中の人々によって持ち運ばれるような携帯型であってもよい。また、通信機器は輸送手段に搭載されてもよい。この輸送手段は、自動車、トラック、タクシー、バス、電車、ボート、飛行機、自転車、バイク等を含んでもよく、またこれらに限定されない。通信機器の一部または全部は、呼やメッセージを送受信してもよく、また、無線接続25から基地局24を介してサービスプロバイダと通信してもよい。基地局24は、携帯電話機ネットワーク11とインターネット28と間の通信を可能にするネットワークサーバ26に接続されてもよい。システム10は、追加の通信機器や、異なるタイプの通信機器を含んでもよい。
【００４１】
通信機器は、種々の伝送技術を使用して通信してもよい。この通信技術には、符号分割多元接続（Code Division Multiple Access; CDMA）、モバイル通信のためのグローバルシステム（Global System for Mobile Communications; GSM）、ユニバーサルモバイル通信システム（Universal Mobile Telecommunications System; UMTS）、時分割多元接続（Time Division Multiple Access; TDMA）、周波数分割多元接続（Frequency Division Multiple Access; FDMA）、伝送制御プロトコル/インターネットプロトコル（Transmission Control Protocol/Internet Protocol; TCP/IP）、ショートメッセージサービス（Short Messaging Service; SMS）、マルチメディアメッセージサービス（Multimedia Messaging Service; MMS）、電子メール、インスタントメッセージサービス（Instant Messaging Service; IMS）、Bluetooth、IEEE 802.11等が含まれるが、これらに限定されない。本発明の種々の実施形態に関与する通信機器は、種々の媒体を使用して通信してもよく、かかる通信には、無線接続、赤外線接続、レーザ接続、ケーブル接続、およびこれらの同等技術が含まれてもよいが、これらに限定されない。
【００４２】
図４および図５は、本発明が実装されうる１つの代表的な電子機器12を示す。しかし、本発明が、ある特定のタイプの機器に限定されるようには意図されていないことを理解されたい。図４および図５の電子機器12は、ハウジング30、液晶ディスプレイ形式のディスプレイ32、キーパッド34、マイクロホン36、イヤホン38、バッテリ40、赤外線ポート42、アンテナ44、本発明の一実施形態に従うUICC形式のスマートカード46、カード読み取り器48、無線インターフェース回路52、コーデック回路54、制御器56、およびメモリ58を含む。個々の回路および要素は、全て、当技術分野において、例えば、ノキアの種類の携帯電話機において周知の型を有する。
【００４３】
本明細書において説明する種々の実施形態は、方法ステップまたはプロセスの一般的な内容において説明される。実施形態によっては、これらは、ネットワーク環境におけるコンピュータにより実行されるプログラムコード等の、コンピュータにより実行可能な命令を含むコンピュータ可読媒体において具現化されるコンピュータプログラムによって、実装されてもよい。当該コンピュータ可読媒体は、読み取り専用メモリ（Read Only Memory; ROM）、ランダムアクセスメモリ（Random Access Memory; RAM）、コンパクトディスク（compact disc; CD）、デジタル多用途ディスク（digital versatile disc; DVD）等を含むがこれらに限定されない着脱式および非着脱式ストレージ機器を含んでもよい。一般的に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、構成要素、データ構造等を含んでもよい。コンピュータにより実行可能な命令、関連のデータ構造、およびプログラムモジュールは、本明細書に開示する方法のステップを実行するためのプログラムコードの例を表す。特定の一連のこのような実行可能な命令または関連のデータ構造は、このようなステップまたはプロセスにおいて説明する機能を実装するための対応する動作の例を表す。
【００４４】
種々の実施形態は、ソフトウェア、ハードウェア、アプリケーションロジック、またはソフトウェア、ハードウェア、およびアプリケーションロジックの組み合わせにおいて実装されてもよい。ソフトウェア、アプリケーションロジック、および／またはハードウェアは、チップセット、モバイル機器、デスクトップ、ラップトップ、またはサーバ上に存在してもよい。種々の実施形態のソフトウェアおよびウェブ実装は、種々のデータベース検索ステップまたはプロセス、相関ステップまたはプロセス、比較ステップまたはプロセス、ならびに決定ステップまたはプロセスを達成するために、法則ベースのロジックおよび他のロジックを含む標準的なプログラミング技法により達成可能である。種々の実施形態は、ネットワーク要素またはモジュール内において全体的または部分的に実装されてもよい。本明細書および以下の請求項で使用する際、単語の「構成要素」および「モジュール」は、１つ以上の種類のソフトウェアコード、および／またはハードウェア実装、および／または手動入力を受け取るための装置を使用する実装を包含するように意図されることに留意されたい。
【００４５】
実施形態に関する前述の説明は、例示目的および説明目的のために提示されている。前述の説明は、包括的であるように、または開示される厳密な形式に本発明の実施形態を限定するようには意図されていない。また、上の教示を検討することにより修正や変形を行うことが可能であり、また、そのような修正や変形は、本発明の実施により得られるであろう。本明細書において論じられる実施形態は、種々の実施形態およびその実用的な用途に関する原理および性質を説明して、種々の実施形態における本発明および想定される特定の使用に適合する種々の修正を当業者が利用できるように、選択および説明されている。本明細書に説明する実施形態の特徴は、方法、装置、モジュール、システム、およびコンピュータプログラムの全ての可能な組み合わされ方で組み合わせられてもよい。
【図１】
2011513806.tif 000005
【図２】
2011513806.tif 000006
【図３】
2011513806.tif 000007
【図４】
2011513806.tif 000008
【図５】
2011513806.tif 000009
【手続補正書】
【提出日】平成22年7月30日(2010.7.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
装置のプロセッサが、コンピュータプログラムの命令に基づいて実行する方法であって、
プレゼンティティのプレゼンス情報を、前記プレゼンティティまたは別のプレゼンティティの代わりに公開することの要求を受信することと、
公開認可ルールの適用に必要な条件が存在するか否かを判断することと、
前記条件が存在する場合、該条件に基づいて前記公開要求を許可するかブロックするかを判断することと、
前記公開要求を許可すると判断した場合、公開コンテンツルールに従って、前記プレゼンス情報を変換することと、
を含む、方法。
【請求項２】
前記要求は、前記プレゼンティティとは異なるパブリッシャ・エンティティから送信される、請求項１に記載の方法。
【請求項３】
前記条件は、前記公開認可ルールの条件要素で規定される、請求項１または２に記載の方法。
【請求項４】
前記公開要求を許可するかブロックするかを前記判断することは、前記公開認可ルールの実装要素に基づく決定にさらに基づく、請求項１から３のいずれかに記載の方法。
【請求項５】
前記プレゼンティティの前記プレゼンス情報の前記変換は、前記公開認可ルールの変換要素で規定される、請求項１から４のいずれかに記載の方法。
【請求項６】
前記変換要素は、前記プレゼンス情報を表すプレゼンスドキュメントのどのデータ要素について公開が許可されるかを制御するために前記公開コンテンツルールを記述する、請求項５に記載の方法。
【請求項７】
前記プレゼンティティの識別情報に関連するコンテンツルールを把握することをさらに含み、前記プレゼンティティの代わりに、プレゼンスソースが、前記プレゼンティティの前記プレゼンス情報を公開している、請求項６に記載の方法。
【請求項８】
前記プレゼンティティの前記プレゼンス情報を公開することの前記要求は、プレゼンスサーバにより受信される、請求項１から７のいずれかに記載の方法。
【請求項９】
前記公開要求を前記ブロックすることは、ポリシーコンタクトヘッダフィールドを含む応答により、前記公開要求に応答することをさらに含む、請求項１から８のいずれかに記載の方法。
【請求項１０】
前記ポリシーコンタクトヘッダフィールドは、前記公開認可ルールを含むドキュメントの統一資源識別子を示す、請求項９に記載の方法。
【請求項１１】
装置のプロセッサに、請求項１から１０のいずれかに記載の方法を実行させうるように構成される、コンピュータプログラム。
【請求項１２】
プロセッサと、前記プロセッサに、請求項１から１０のいずれかに記載の方法を実行させうるように構成されるコンピュータプログラムを格納するメモリと、を備える装置。
【請求項１３】
プレゼンティティのプレゼンス情報を、前記プレゼンティティまたは別のプレゼンティティの代わりに公開することの要求を受信する手段と、
公開認可ルールの適用に必要な条件が存在するか否かを判断する手段と、
前記条件が存在する場合、該条件に基づいて前記公開要求を許可するかブロックするかを判断する手段と、
前記公開要求を許可すると判断した場合、公開コンテンツルールに従って、前記プレゼンス情報を変換する手段と、
を備える、公開委任のためのシステム。
【請求項１４】
前記要求は、前記プレゼンティティとは異なるパブリッシャ・エンティティから送信される、請求項１３に記載のシステム。
【請求項１５】
前記条件は、前記公開認可ルールの条件要素で規定される、請求項１３または１４に記載のシステム。
【請求項１６】
前記公開要求を許可するかブロックするかを前記判断することは、前記公開認可ルールの実装要素に基づく決定にさらに基づく、請求項１３から１５のいずれかに記載のシステム。
【請求項１７】
前記プレゼンティティの前記プレゼンス情報の前記変換は、前記公開認可ルールの変換要素で規定される、請求項１３から１６のいずれかに記載のシステム。
【請求項１８】
前記変換要素は、前記プレゼンス情報を表すプレゼンスドキュメントのどのデータ要素について公開が許可されるかを制御するために前記公開コンテンツルールを記述する、請求項１７に記載のシステム。
【請求項１９】
前記メモリユニットは、前記プレゼンティティの識別情報に関連するコンテンツルールを把握するように構成されるコンピュータコードをさらに含み、前記プレゼンティティの代わりに前記プレゼンティティの前記プレゼンス情報を公開している、請求項１８に記載のシステム。
【請求項２０】
前記公開要求を前記ブロックすることは、ポリシーコンタクトヘッダフィールドを含む応答により、前記公開要求に応答することをさらに含む、請求項１３から１９のいずれかに記載のシステム。
【請求項２１】
前記ポリシーコンタクトヘッダフィールドは、前記公開認可ルールを含むドキュメントの統一資源識別子を示す、請求項２０に記載のシステム。
【国際調査報告】
2011513806.tif 000010
2011513806.tif 000011
2011513806.tif 000012