用于实施发布处理的系统和方法
【专利说明】
[0001] 本申请是申请号为：200880126762. 9、申请日为2008年12月16日的、题为"用于 实施发布处理的系统和方法"的中国专利申请的分案申请。
技术领域
[0002] 本发明主要涉及存在服务。更特别地，本发明涉及的是发布授权策略和/或用于 提供被许可的存在信息的发布委托和限制的规则。
【背景技术】
[0003] 本章节旨在为权利要求中阐述的发明提供背景或上下文。这里的描述可以包括那 些能够推行的概念，而不必是先前已经构思或推行的概念。因此，除非在这里另有指示，否 则本章节描述的内容不是本申请的说明书和权利要求的现有技术，并且并不因为其包含于 本章节中而被认为是现有技术。
[0004] 开放移动联盟（0MA)是一个共同开发在移动产业中使用的开放性标准的标准机 构。0ΜΑ帮助创建了能够彼此协作的业务使能器（service enabler)，以便跨越国家、运营 商和移动终端来进行工作，这一点是由市场需求驱动的。为了扩展移动市场，支持开放移动 联盟的公司致力于协助进行快速广阔地开发和部署各种新的增强型移动信息、通信和娱乐 服务。
[0005] 0ΜΑ是当前正在开发的存在和XML文档管理（SDM)服务，该服务基于会话发起协 议（SIP)以及由国际工程任务组（IETF)针对即时消息收发和呈现扩展的SIP(S頂PLE)工 作组开发的可扩展标记语言（XML)配置访问协议（XCAP)。
[0006] 存在服务可以是指接受、存储和分发存在信息的网络服务和系统，其中该存在信 息会受到各种控制。此外，目前已经为存在信息的收集和分发规定了需求，例如用于发布、 订阅、通知等等的方法，以及可以包含在存在信息中的内容的类型，如通信意愿，设备状态 等。例如，存在信息指的是涉及特定呈现体的动态信息集合。该信息例如可以包括用以指 示通信伙伴的通信能力和意愿的状态指示符。此外，存在服务还可以与很多其他的服务或 使能器相联系。
[0007] 如上所述，目前已经为存在服务规定了一些需求，并且其中至少有一些需求是在 OMA SIMPLE Presence 2. ORequirements Document (OMA SIMPLE 存在 2.0 需求文献）中列 举的。在 OMA SIMPLE Presence 2. ORequirements Document 中，定义了一个必须具有下列 需求的使能器：
[0008]
[0009] 当前，常规的存在服务包括对订阅进行处理的授权策略，其被称为存在授权规则。 这些存在授权规则描述的是任何允许订阅（或被阻止订阅）特定呈现体的存在信息的授权 观察者。
[0010] 存在发布委托被视为是OMA S頂PLE Presence 2. 0用以允许用户和/或应用代表 其他用户来执行存在信息发布的一个重要特征。例如，秘书可以代表他的/她的老板来发 布存在信息，或者驻留在用户计算机上的日历应用可以代表用户来发布用户的存在信息。
[0011] 在 OMA S頂PLE Presence Technical Specification (TS) 2.0 和 OMA S頂PLE Presence Extensible Markup Language Document Management(XDM)TS 2. 0(OMA SIMPLE 存在扩展标识语言文档管理（XDM)TS2.0)中规定了有关用于订阅的存在授权规则的细节。 如在OMA S頂PLE Presence TS 2.0文献中描述的那样，存在授权规则包括订阅授权规则和 存在内容规则。订阅授权规则确定的是如何处理引入的订阅，而存在内容规则确定的则是 将哪些以及什么样的存在信息散布给依照适用的订阅授权规则而被接受的观察者。
【发明内容】
[0012] 各种实施例创建并实施了存在服务中的发布授权规则，以便能将关联于呈现体的 存在信息发布委托给代表该呈现体的发布者。各种实施例还提供了一种用于定义发布者如 何在单次事务中了解策略内部的内容规则的系统和方法，从而在经由用于实际发布的SIP 信令了解（部分）策略时避免不必要的和/或额外的事务。此外，服务供应商可以具有对 允许呈现体发布的存在信息加以限制的能力。由此，在规则与除了将被发布存在信息的呈 现体之外的用户（具有身份）相匹配时的情况下，则可以实施发布委托。
[0013] 此外，在规则与呈现体的身份相匹配时的那些情况下，服务供应商同样可以限制 所允许的存在信息。
[0014] 本发明的各种实施例适用于几乎任何存在解决方案，包括因特网消息收发和存在 服务aMPS)(由0ΜΑ定义），S頂PLE存在性，以及可扩展消息收发和存在协议（XMPP)(由因 特网工程任务组（IETF)定义）。
[0015] 从以下结合附图的详细描述中可以清楚了解本发明各种实施例的这些和其他优 点、特征及其操作的组织和方式，其中相同的部件在如下所述的几个图中具有相同的数字。
【附图说明】
[0016] 本发明的实施例是参考附图描述的，其中：
[0017] 图1示出的是根据各种实施例的示例性存在服务架构；
[0018] 图2示出的是描述了根据用于发布委托的各种实施例所执行的操作的流程图；
[0019] 图3是可以实施本发明各种实施例的系统的概述图；
[0020] 图4是可以结合本发明各种实施例的实施使用的电子设备的透视图；以及
[0021] 图5是可以包含在图4的电子设备中的电路的示意表示。
【具体实施方式】
[0022] 各种实施例提供的是通过使用发布授权规则来虑及发布委托的系统和方法，其中 呈现体可以允许诸如发布者之类的另一个实体代表呈现体来发布与呈现体相关联的存在 信息。此外，由于发布授权规则还可以包括用于呈现体自身的规则，因此，各种实施例还为 服务供应商提供了对允许呈现体发布的存在信息进行限制的能力。由此，在规则与除了将 被发布存在信息的呈现体之外的用户相匹配（具有身份）时的情况下，则可以实施发布委 托。此外，在规则与呈现体的身份相匹配时的那些情况下，服务供应商同样可以限制所允许 的存在彳目息。
[0023] 对于上述发布授权规则来说，此类发布授权策略中的规则确定如何处理引入的 发布（例如允许还是阻止）以及允许用户和/或应用发布的实际存在信息本身。可以 在http://www. ietf.org/rfc/rfc3903.txt得到的因特网工程任务组（IETF)请求注解 (RFC) 3903描述了一种用于存在服务的PUBLISH(发布）方法。可以在http://WWW· ietf. org/rfc/rfc5025. txt得到的IETF RFC 5025描述了一种用于处理订阅以及存在服务器可 以做出的相关决定的框架。但是，这其中并未描述如何指示是否所发布的存在信息内的一 些（或所有）存在信元因为一些原因（例如因为发布授权规则的内容策略）而无法被存在 服务器接受。因此，即使定义了发布授权内容规则，也没有可供存在服务器向存在源表明所 述存在源的哪些许可内容可被发布的已知协议或方法。此外，如何处理用于发布委托的发 布授权也没有被描述。
[0024] 所设想的一种用于解决上述问题的方法是在PUBLISH响应主体内部向存在源指 示内容策略。例如，200(0K)响应可以表示接受所有发布内容，而包含消息主体的202(接 受）响应则可以表示只有一部分存在信息得到授权。但是，IETF RFC 3903明确表明 PUBLISH响应主体是没有意义的，因此，实施所设想的这种用于指示内容策略的方法将会违 反IETF RFC 3903,或者需要对IETF RFC 3903进行更新。此外，存在源只能知道与其当前 正在发布的存在信息相关的一些局部策略，由此导致存在源要执行不必要的事务交换以发 现内容策略的剩余部分。
[0025] 此外，不必要的事务交换还有潜在地导致重复地借助于发布响应来传送相同的策 略规则。因此，存在源可能永远都无法完全了解相关的内容策略，取而代之的是，该存在源 会重复地尝试进行发布，并且如果发布成功，则根据存在服务器的答复来自己收集策略中 的策略规则。同样，这样的处理会在存在服务器中导致不必要的业务量和逻辑以构造策略 文档。
[0026] 图1示出了一个示例性的存在服务架构100。呈现体110包括具有与之关联的存 在信息的逻辑实体，例如人、特定服务等等。与呈现体110相关联的存在信息可以来自或者