CN105227636A - 用于实施发布处理的系统和方法 - Google Patents

Abstract

所提供的是虑及了通过使用发布授权规则来实施发布委托的系统和方法，其中呈现体可以允许诸如发布者之类的另一个实体代表该呈现体来发布与该呈现体相关联的存在信息。此外在这里还为服务供应商例如提供了用于限制允许呈现体发布的存在信息的能力。因此，在规则与除了将被发布存在信息的呈现体之外的其他用户(具有身份)相匹配时的情况下，则可以实施发布委托。其中根据所述发布内容规则发布明确规定的存在元素。此外，在规则与呈现体的身份相匹配时的那些情况下，那么服务供应商可以对所允许的存在信息进行限制。

Description

用于实施发布处理的系统和方法

本申请是申请号为：200880126762.9、申请日为2008年12月16日的、题为“用于实施发布处理的系统和方法”的中国专利申请的分案申请。

技术领域

本发明主要涉及存在服务。更特别地，本发明涉及的是发布授权策略和/或用于提供被许可的存在信息的发布委托和限制的规则。

背景技术

本章节旨在为权利要求中阐述的发明提供背景或上下文。这里的描述可以包括那些能够推行的概念，而不必是先前已经构思或推行的概念。因此，除非在这里另有指示，否则本章节描述的内容不是本申请的说明书和权利要求的现有技术，并且并不因为其包含于本章节中而被认为是现有技术。

开放移动联盟(OMA)是一个共同开发在移动产业中使用的开放性标准的标准机构。OMA帮助创建了能够彼此协作的业务使能器(serviceenabler)，以便跨越国家、运营商和移动终端来进行工作，这一点是由市场需求驱动的。为了扩展移动市场，支持开放移动联盟的公司致力于协助进行快速广阔地开发和部署各种新的增强型移动信息、通信和娱乐服务。

OMA是当前正在开发的存在和XML文档管理(SDM)服务，该服务基于会话发起协议(SIP)以及由国际工程任务组(IETF)针对即时消息收发和呈现扩展的SIP(SIMPLE)工作组开发的可扩展标记语言(XML)配置访问协议(XCAP)。

存在服务可以是指接受、存储和分发存在信息的网络服务和系统，其中该存在信息会受到各种控制。此外，目前已经为存在信息的收集和分发规定了需求，例如用于发布、订阅、通知等等的方法，以及可以包含在存在信息中的内容的类型，如通信意愿，设备状态等。例如，存在信息指的是涉及特定呈现体的动态信息集合。该信息例如可以包括用以指示通信伙伴的通信能力和意愿的状态指示符。此外，存在服务还可以与很多其他的服务或使能器相联系。

如上所述，目前已经为存在服务规定了一些需求，并且其中至少有一些需求是在OMASIMPLEPresence2.0RequirementsDocument(OMASIMPLE存在2.0需求文献)中列举的。在OMASIMPLEPresence2.0RequirementsDocument中，定义了一个必须具有下列需求的使能器：

当前，常规的存在服务包括对订阅进行处理的授权策略，其被称为存在授权规则。这些存在授权规则描述的是任何允许订阅(或被阻止订阅)特定呈现体的存在信息的授权观察者。

存在发布委托被视为是OMASIMPLEPresence2.0用以允许用户和/或应用代表其他用户来执行存在信息发布的一个重要特征。例如，秘书可以代表他的/她的老板来发布存在信息，或者驻留在用户计算机上的日历应用可以代表用户来发布用户的存在信息。

在OMASIMPLEPresenceTechnicalSpecification(TS)2.0和OMASIMPLEPresenceExtensibleMarkupLanguageDocumentManagement(XDM)TS2.0(OMASIMPLE存在扩展标识语言文档管理(XDM)TS2.0)中规定了有关用于订阅的存在授权规则的细节。如在OMASIMPLEPresenceTS2.0文献中描述的那样，存在授权规则包括订阅授权规则和存在内容规则。订阅授权规则确定的是如何处理引入的订阅，而存在内容规则确定的则是将哪些以及什么样的存在信息散布给依照适用的订阅授权规则而被接受的观察者。

发明内容

各种实施例创建并实施了存在服务中的发布授权规则，以便能将关联于呈现体的存在信息发布委托给代表该呈现体的发布者。各种实施例还提供了一种用于定义发布者如何在单次事务中了解策略内部的内容规则的系统和方法，从而在经由用于实际发布的SIP信令了解(部分)策略时避免不必要的和/或额外的事务。此外，服务供应商可以具有对允许呈现体发布的存在信息加以限制的能力。由此，在规则与除了将被发布存在信息的呈现体之外的用户(具有身份)相匹配时的情况下，则可以实施发布委托。

此外，在规则与呈现体的身份相匹配时的那些情况下，服务供应商同样可以限制所允许的存在信息。

本发明的各种实施例适用于几乎任何存在解决方案，包括因特网消息收发和存在服务(IMPS)(由OMA定义)，SIMPLE存在性，以及可扩展消息收发和存在协议(XMPP)(由因特网工程任务组(IETF)定义)。

从以下结合附图的详细描述中可以清楚了解本发明各种实施例的这些和其他优点、特征及其操作的组织和方式，其中相同的部件在如下所述的几个图中具有相同的数字。

附图说明

本发明的实施例是参考附图描述的，其中：

图1示出的是根据各种实施例的示例性存在服务架构；

图2示出的是描述了根据用于发布委托的各种实施例所执行的操作的流程图；

图3是可以实施本发明各种实施例的系统的概述图；

图4是可以结合本发明各种实施例的实施使用的电子设备的透视图；以及

图5是可以包含在图4的电子设备中的电路的示意表示。

具体实施方式

各种实施例提供的是通过使用发布授权规则来虑及发布委托的系统和方法，其中呈现体可以允许诸如发布者之类的另一个实体代表呈现体来发布与呈现体相关联的存在信息。此外，由于发布授权规则还可以包括用于呈现体自身的规则，因此，各种实施例还为服务供应商提供了对允许呈现体发布的存在信息进行限制的能力。由此，在规则与除了将被发布存在信息的呈现体之外的用户相匹配(具有身份)时的情况下，则可以实施发布委托。此外，在规则与呈现体的身份相匹配时的那些情况下，服务供应商同样可以限制所允许的存在信息。

对于上述发布授权规则来说，此类发布授权策略中的规则确定如何处理引入的发布(例如允许还是阻止)以及允许用户和/或应用发布的实际存在信息本身。可以在http://www.ietf.org/rfc/rfc3903.txt得到的因特网工程任务组(IETF)请求注解(RFC)3903描述了一种用于存在服务的PUBLISH(发布)方法。可以在http://www.ietf.org/rfc/rfc5025.txt得到的IETFRFC5025描述了一种用于处理订阅以及存在服务器可以做出的相关决定的框架。但是，这其中并未描述如何指示是否所发布的存在信息内的一些(或所有)存在信元因为一些原因(例如因为发布授权规则的内容策略)而无法被存在服务器接受。因此，即使定义了发布授权内容规则，也没有可供存在服务器向存在源表明所述存在源的哪些许可内容可被发布的已知协议或方法。此外，如何处理用于发布委托的发布授权也没有被描述。

所设想的一种用于解决上述问题的方法是在PUBLISH响应主体内部向存在源指示内容策略。例如，200(OK)响应可以表示接受所有发布内容，而包含消息主体的202(接受)响应则可以表示只有一部分存在信息得到授权。但是，IETFRFC3903明确表明PUBLISH响应主体是没有意义的，因此，实施所设想的这种用于指示内容策略的方法将会违反IETFRFC3903，或者需要对IETFRFC3903进行更新。此外，存在源只能知道与其当前正在发布的存在信息相关的一些局部策略，由此导致存在源要执行不必要的事务交换以发现内容策略的剩余部分。

此外，不必要的事务交换还有潜在地导致重复地借助于发布响应来传送相同的策略规则。因此，存在源可能永远都无法完全了解相关的内容策略，取而代之的是，该存在源会重复地尝试进行发布，并且如果发布成功，则根据存在服务器的答复来自己收集策略中的策略规则。同样，这样的处理会在存在服务器中导致不必要的业务量和逻辑以构造策略文档。

图1示出了一个示例性的存在服务架构100。呈现体110包括具有与之关联的存在信息的逻辑实体，例如人、特定服务等等。与呈现体110相关联的存在信息可以来自或者由一个或多个存在源120组成。换句话说，存在源120“发布”存在信息。例如，存在源120可以包括存在用户代理，充当存在代理的网元，诸如公司日历之类的应用等等，作为替换，该存在源120也可处于移动终端之中。

存在服务器130是网络100的另一个逻辑实体，它接收来自存在源120的存在信息，同时它例如还会将接收到的存在信息实例转换成可使用的格式。换言之，存在服务器130处理来自一个或多个与呈现体相关联的存在源的发布。发布可以包括刷新存在信息，替换存在信息，或者移除存在信息。处理所述发布可以是指在转换了存在信息之后将其转发给观察者140。观察者140可以是指网络100中从存在服务那里请求有关任何一个或多个呈现体110的存在信息且可唯一识别的任何实体。观察者140可以借助“订阅”来请求存在信息，其中所述订阅可以是指由存在服务保持的、关于将被告知一个或多个呈现体110的存在信息变化的订户请求的信息。应该指出的是，订户可以是指请求存在服务向其告知一个或多个呈现体110的存在信息变化的观察者140。

考虑到一致性并且为了简单起见，较为有利的是使涉及发布委托的任何发布授权规则都与用于订阅的存在授权规则具有相同或等效的格式。

在可以从http://www.ietf.org/rfc/rfc4745.txt得到的IETFRFC4745中定义了一种用来创建用以访问应用专用数据的授权策略的框架。由此，借助于使用与在IETFRFC4745中描述并在OMASIMPLEPresenceXDMTS2.0中扩展的公共策略结构相应的方式形成的发布授权规则，各种实施例可以实施存在发布委托以及存在信息限制。

根据各种实施例的每一个发布授权规则都可以包含一系列<rule>(规则)元素，其中每一个规则都包括至少三个部分：“条件”元素，“行为”元素以及“变换”元素。条件元素可以规定那些借以将规则应用于存在服务器处理的条件。行为元素可以向存在服务器指示其应该采取的行动。变换元素指示存在服务器执行的操作，例如允许发布存在源发布的已授权存在信息。

各种实施例提供了<pub-handling>(发布-处理)元素，该元素规定的是由存在服务器做出且与任何<rule>元素的<action>(动作)子元素相关联的发布授权决定。应该指出的是，根据各种实施例，值“block(阻止)”和“allow(许可)”在发布授权规则中是有意义的。对值“allow”来说，存在服务器接受所提出的发布并返回200(OK)响应。对值“block”来说，存在服务器拒绝所提出的发布，并且返回403(禁止)响应。

图2是示出了为了允许由另一发布者代表呈现体发布存在信息而执行的示例性处理的流程图。此外，这些示例性处理例如还可以用于处理服务供应商希望对许可的存在信息应用某些限制的情景。在200，从发布者那里接收(例如在存在服务器上)发布呈现体的存在信息的请求，其中所述发布要么代表的是该呈现体，要么代表的是另一个呈现体。在210，存在服务器根据适用发布授权规则的<condition>(条件)元素来确定是否存在需要应用该发布授权规则的恰当条件。举例来说，其可以确定是否存在于发布者的身份相匹配的条件，以使存在服务器应用这些发布授权规则。然而，例如，如果不存在与发布者的身份相匹配的条件，那么默认的行为可以是阻止发布。此外还应该指出的是，发布授权规则可以应用于呈现体本身，这被称为发布信息限制。作为替换，发布授权规则可以应用于如上所述的另一呈现体，这被称为委托。在220，按照发布授权规则的<action>元素，存在服务器根据条件来确定应该采取的行动，其中如果条件存在，则依照公共策略规则集合组合逻辑来组合规则，并且结合变换来确定最终的行动。例如，在230，适用的<actions>元素指示存在服务器确定所述发布应该是被允许和被阻止之一。如果到达的决定是允许发布，则在240存在服务器根据组合的变换(发布内容规则)来确定授权的存在信息。换言之，<transformations>(变换)元素指示存在服务器对已发布的存在信息进行过滤，并且只允许<transformations>元素的子元素明确规定的存在元素。但是如果做出的决定时阻止发布，那么在250将会立即拒绝发布请求，并且发送一个403(禁止)响应。在260，当允许已发布的存在信息并且已发布的存在信息与发布内容规则相匹配时，发送200(OK)响应。作为替换，在270，如果已发布的存在信息不与发布内容规则(部分或全部地)相匹配，则发送一个包含了Policy-Contact(策略-联系人)报头字段的488(在这里不可接受)响应，其中该Policy-Contact报头字段包括一个指向发布授权规则文档的URI。

此外，根据各种实施例，发布授权规则中的<transformations>元素描述了内容规则。例如，基于人员、设备和服务数据元素的一些标识信息，第一组变换可以顾及这些元素的发布。另一组变换可以顾及存在文档中的特定数据元素的发布。举个例子，根据各种实施例，提供了<allow-note>(允许-注释)来控制特定发布者发布<note>(注释)元素。

各种实施例还提供了允许存在源了解与该存在源代为发布存在信息的呈现体的存在身份相关联的相关内容规则的系统和方法。换言之，来自匹配发布授权规则的组合<transformations>元素(例如具有与发布者的身份相匹配的<identity>(身份)元素的规则)将被使用，从而虑及反复使用在名为“AFrameworkforSessionInitiationProtocol(SIP)SessionPolicies”的draft-ietf-sip-session-policy-framework-02备忘录中提出的行为和SIP扩展。

如果发布者正在发布未经呈现体授权的存在元素，那么存在服务器将会使用488(在这里不可接受)响应来拒绝该发布，其中该响应包含了一个Policy-Contact报头字段。该Policy-Contact报头字段被用于指向一个统一资源标识符(URI)，其中该URI例如是包含了依照各种实施例创建的发布授权规则的文档的URI。应该指出的是，该文档可以存储在存在XDMS中。

在接收到具有Policy-Contact报头字段的488(在这里不可接受)响应之后，存在源会从存在XDMS中取回发布授权规则，并且发现发布的适用内容规则。然后，该存在XDMS会将执行取回处理的存在源的身份与在规则的条件元素中给出的身份相匹配，并且仅仅从匹配规则中返回组合的<transformations>元素。由此，由于发布者只允许了解与特定发布者身份相关的策略，因此避免了发布者了解整个策略。在接收到来自存在XDMS的内容规则的相关部分之后，存在源可以创建一个用于发布且形式合法的存在文档，其中所述发布是得到已被发现的发布授权规则授权的。此外，与任何其他XDM文档一样，存在源可以像XDMCore2.0规范中描述的那样订阅策略文档变化。作为替换，如果发布尝试失败但是策略文档的本地(例如缓存)复制允许发布存在文档，那么存在源可以取回最新(例如已变化的)文档。

各种实施例可以用于在存在服务中创建和实施发布授权规则。此外，各种实施例提供了一种用于定义发布者如何在单次事务中了解策略内部的内容规则的系统和方法，从而在经由用于实际发布的SIP信令发现(部分)策略时避免不必要和/或额外的事务。换言之，根据各种实施例，策略下载可以与SIP信令分离。例如，发布授权规则文档可以从存在XDMS获取，而不是将策略信息捎带在SIP信令消息上，其中在与被拒绝的发布相关的每一条不成功的PUBLISH(发布)事务响应中都包含了一个策略信息。

各种实施例的众多上述示例实施方式是在SIMPLE存在环境中描述的。但是，本领域技术人员将会理解，本发明的各种实施例同样适用于其他的存在解决方案。

图3显示了一个可以使用本发明的各种实施例的系统10，其中包括可以通过一个或多个网络通信的多个通信设备。系统10可以包括有线或无线网络的任何组合，这其中包括但不局限于移动电话网络、无线局域网(LAN)、蓝牙个域网、以太网LAN、令牌环LAN、广域网、因特网等等。系统10可以同时包括有线和无线通信设备。

作为示例，图3中示出的系统10包括移动电话网络11和因特网28。与因特网28的连接可以包括但不局限于长距无线连接、短距无线连接以及各种有线连接，其中所述有线连接包括但不局限于电话线、电缆线、电力线等等。

系统10的示例性通信设备可以包括但不局限于采用移动电话形式的电子设备12，个人数字助理(PDA)0与移动电话14的组合、PDA16、集成的消息收发设备(IMD)18、台式计算机20、笔记本计算机22等等。该通信设备可以是固定的或在被正在移动的个人携带时可以是移动的。通信设备还可以处于交通运输模式中，其中该模式包括但不局限于汽车、卡车、出租车、公共汽车、火车、船舶、飞机、自行车、摩托车等等。一些或所有通信设备可以发送和接收呼叫和消息，并且通过与基站24相连的无线连接25来与服务供应商通信。基站24可以与允许移动电话网络11与因特网28之间的通信的网络服务器26相连。该系统10还可以包括额外的通信设备以及各种类型的通信设备。

通信设备可以使用各种传输技术来进行通信，这其中包括但不局限于码分多址(CDMA)、全球移动通信系统(GSM)、通用移动电信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议/网际协议(TCP/IP)、短消息收发服务(SMS)、多媒体消息收发服务(MMS)、电子邮件、即时消息收发服务(IMS)、蓝牙、IEEE80.211等等。在实施本发明的各种实施例的过程中涉及的通信设备可以使用各种媒体来进行通信，这其中包括但不局限于无线电、红外、激光、线缆连接等等。

图4和图5显示了一个可以实施本发明的代表性电子设备12。但是应该理解，本发明并不意欲局限于某种特定类型的设备。图4和图5的电子设备12包括外壳30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、依照一个实施例的UICC形式的智能卡46、读卡器48、无线电接口电路52、编解码器电路54、控制器56以及存储器58。单个的电路和部件全都具有本领域已知的类型，例如在Nokia的移动电话范围中已知的类型。

这里描述的各种实施例是在通用的方法步骤或处理的上下文中描述，其中所述方法步骤或处理在一个实施例中可以由于一个计算机程序产品来执行，该计算机程序产品包含在计算机可读介质中，并且包含了由联网环境中的计算机执行的计算机可执行指令，例如程序代码。计算机可读介质可以包括可拆卸和不可拆卸存储设备，包括但不局限于只读存储器(ROM)、随机访问存储器(RAM)、压缩碟片(CD)、数字多用途碟片(DVD)等等。通常，程序模块可以包括执行特定任务或实施特定抽象数据类型的例程、程序、对象、组件、数据结构等等。与数据结构相关联的计算机可执行指令和程序模块代表了用于执行这里公开的方法步骤的程序代码的示例。这种可执行指令的特定序列或是相关联的数据结构代表了用于实施在这些步骤或处理中描述的功能的相应操作的示例。

各种实施例可以在软件，硬件，应用逻辑，或是软件、硬件与应用逻辑的组合中实施。软件、应用逻辑和/或硬件例如可以驻留在芯片组、移动设备、台式机、膝上型计算机或服务器上。各种实施例的软件和web实施方式可以使用标准的编程技术并且使用具有基于规则的逻辑以及用以完成各种数据库搜索步骤或处理、相关步骤或处理、比较步骤或处理以及决定步骤或处理的其他逻辑来完成。各种实施例还可以全部或部分在网络部件或模块内部实施。应该指出的是，这里以及后续权利要求书中使用的单词“组件”和“模块”旨在包含使用了一行或多行软件代码的实施方式、和/或硬件实施方式、和/或用于接收手动输入的设备。

以上关于实施例的描述是出于例证和描述目的给出的。以上描述并不是穷举性的，或者没有将本发明实施例局限于所公开的准确形式，有鉴于上述教导或是可以从各种实施例的实践中获取的教导，各种修改和变更都是可行的。这里论述的实施例是为了说明各种实施例的原理和特性及其实践应用而被选择和描述的，以使本领域技术人员能够使用各种实施例中的发明以及具有与所设想的特定用途相适合的各种修改的发明。这里描述的实施例的特征可以采用方法、设备、模块、系统以及计算机程序产品的所有可能的组合方式来组合。

Claims (15)

1.一种用于发布委托的方法，包括：

接收代表另一个呈现体来发布所述呈现体的存在信息的请求；

确定是否存在需要应用发布授权规则的条件；

如果存在所述条件，则根据所述条件来确定允许还是阻止发布请求；以及

一旦确定允许所述发布请求，则根据发布内容规则来变换所述存在信息，其中根据所述发布内容规则发布明确规定的存在元素；

如果所述发布请求被阻止，则使用包含策略联系人报头字段的响应来响应所述发布请求，其中所述策略联系人报头字段指向包含所述发布授权规则的文档的统一资源标识符，使得所述呈现体仅被允许了解与所特定呈现体的身份相关的策略。

2.权利要求1的方法，其中所述请求从不同于所述呈现体的发布者实体发送。

3.权利要求1的方法，其中所述条件在所述发布授权规则的条件元素中定义。

4.权利要求1的方法，其中确定允许还是阻止所述发布请求进一步以基于所述发布授权规则中的动作元素的决定为基础。

5.权利要求1的方法，其中所述呈现体的所述存在信息的变换在所述发布授权规则的变换元素中定义。

6.权利要求5的方法，其中所述变换元素描述用于控制允许发布存在文档中的哪些数据元素的所述发布内容规则，并且其中所述存在文档代表所述存在信息。

7.权利要求6的方法，还包括：了解与所述呈现体的身份相关联的内容规则，存在源代表所述呈现体正在发布所述呈现体的所述存在信息。

8.权利要求1的方法，其中发布所述呈现体的所述存在信息的请求由存在服务器接收。

9.一种用于发布委托的设备，包括：

用于接收发布所述呈现体的存在信息的请求的装置，所述请求代表另一个呈现体；

用于确定是否存在需要应用发布授权规则的条件的装置；

用于在存在所述条件的情况下，根据所述条件来确定允许还是阻止发布请求的装置；

用于在确定允许所述发布请求时根据发布内容规则来变换所述存在信息的装置，其中根据所述发布内容规则发布明确规定的存在元素；以及

用于如果所述发布请求被阻止，则使用包含策略联系人报头字段的响应来响应所述发布请求的装置，其中所述策略联系人报头字段指向包含所述发布授权规则的文档的统一资源标识符，使得所述呈现体仅被允许了解与所特定呈现体的身份相关的策略。

10.如权利要求9所述的设备，其中所述请求从不同于所述呈现体的发布者实体发送。

11.如权利要求9所述的设备，其中所述条件在所述发布授权规则的条件元素中定义。

12.如权利要求9所述的设备，其中所述根据所述条件来确定允许还是阻止所述发布请求的装置进一步以基于所述发布授权规则中的动作元素的决定为基础。

13.如权利要求9所述的设备，其中所述呈现体的所述存在信息的变换在所述发布授权规则的变换元素中定义。

14.如权利要求13所述的设备，其中所述变换元素描述用于控制允许发布存在文档中的哪些数据元素的所述发布内容规则，并且其中所述存在文档代表所述存在信息。

15.如权利要求14所述的设备，还包括了解与所述呈现体的身份相关联的内容规则的装置，其中存在源代表所述呈现体发布所述呈现体的所述存在信息。