专利名称：一种呈现信息的处理方法
技术领域：
本发明涉及互联网领域和无线通信领域呈现业务的实现，本发明尤其涉及一种呈现信息的处理方法。
背景技术：
呈现业务(PRESENCE SERVICE)，也称作存在业务，是一种搜集和分发呈现信息的通信业务。目前通常和即时消息业务(INSTANT MESSAGESERVICE)一起提供，当然呈现业务也可以单独提供，或者和其他业务如网络游戏业务结合。因特网工程任务组IETF、开放移动联盟OMA等国际标准组织都已经初步制订了呈现业务的相应标准规范，正在不断完善之中。呈现体可以是自然人，也可以是非自然人，呈现信息包括呈现体的在线/离线状态、通信方式等基本信息外，还包括心情，位置，活动等扩展信息，以及非自然人提供的增值业务信息如天气预报、电台或电视节目，交通状况等信息。在互联网工程组IETF给出的呈现信息的数据模型中，将呈现信息分为三部分，如图1所示，包括个人Person，业务Service，和设备Device，在呈现信息文档中分别对应的具体元素为个人<person>元素，业务<tuple>元素，设备<device>元素，这三种元素又都各自包含大量的子元素，如<person>元素可以包括活动<activities>，心情<mood>，状态图标<status-icon>，时区<time-offset>等子元素，具体可请参见IETF或OMA的相应标准规范。
目前商用的呈现业务基本都与即时消息业务集成在一起，如腾讯公司的QQ，微软公司的MSN等，这些商用的呈现业务中用户并不能使自己的同一个呈现信息元素向不同的观察者呈现不同的值，如对于一个具体的心情<mood>元素，用户希望对属于“朋友”组的联系人(也称作好友)呈现“happy”(愉快)的信息，而对于另外一个具体的联系人则同时呈现“lonely”(孤独)的信息。另外对于用户的状态信息如离线，在线等，用户也经常希望能够对不同的联系人显示不同的状态信息，以减少一些不想要的打扰。而实现同一个呈现信息元素同时向不同的观察者呈现不同的值，目前的呈现业务中尚无法支持这种机制。现有呈现业务中呈现信息的处理方法主要步骤包括101、呈现体发布呈现信息；102、呈现服务器接收呈现信息并存储；103、呈现服务器根据鉴权配置信息确定观察者允许获得的呈现信息；104、呈现服务器分发呈现信息给相应的观察者；105、观察者呈现接收到的呈现信息。
以上步骤中并无针对上述实现同一个呈现信息元素同时向不同的观察者呈现不同的值的机制做任何处理，由此可见，应该对目前的处理方法进行改进，以实现上述机制。
发明内容
本发明要解决的技术问题在于提出一种呈现信息的处理方法，以实现呈现业务中同一呈现体的同一个呈现信息元素可同时向不同的观察者呈现不同的值。
为解决上述问题，本发明提出的技术方案如下本发明提供了一种呈现信息的处理方法，包括步骤A、在呈现体对观察者的鉴权配置信息中记录观察者身份和类标识的关联关系；B、关联呈现信息与相应的类标识，呈现体发布呈现信息；C、呈现服务器接收并存储所述呈现信息，并根据类标识与观察者身份及呈现信息的关联关系确定观察者可获得的呈现信息，然后发送给观察者。
进一步，步骤C中呈现服务器接收到不同呈现信息源为同一呈现体发布的呈现信息之后，只在检查到其所包含的类标识元素具有相同的值或都没有包含类标识元素时才进行合并，否则不合并。
所述呈现信息包括个人<person>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述个人<person>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c11、呈现服务器检查两个个人<person>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果是则转步骤c12，否则不合并，结束处理。
c12、检查两个个人<person>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
所述呈现信息包括业务<tuple>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述业务<tuple>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c21、呈现服务器检查两个业务<tuple>元素的联系<contact>子元素是否具有相同的值，如果相同则转步骤c22，否则不合并，结束处理。
c22、检查两个业务<tuple>元素的业务描述<service-description>元素的子元素业务标识<service-id>元素和版本<version>元素是否具有相同的值，如果全部相同则转步骤c23，否则不合并，结束处理。
c23、检查两个业务<tuple>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果相同则转步骤c24，否则不合并，结束处理。
c24、检查两个业务<tuple>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
所述呈现服务器检查类标识<class>元素是否具有相同的值时，如果检查到类标识<class>元素的数量多于一个，则呈现服务器在确定所有的类标识<class>元素都完全对应相同时，才判定类标识<class>元素是否具有相同的值。
所述检查相同的元素是否具有不同的值之后，还包括步骤检查相同的元素是否具有不同的属性值，如果否，则进行合并，否则不合并，结束处理。
在呈现服务器合并处理的检查步骤中忽略描述<description>元素，在步骤c24中合并一个新发布到呈现服务器的业务<tuple>元素时，如果呈现服务器中已经存在的一个业务<tuple>元素中有描述<description>元素的值，则不改动已经存在的值，如果没有描述<description>元素的值，则向其增加新发布到呈现服务器的业务<tuple>元素中的描述<description>元素的值。
步骤A中，在呈现体对观察者的鉴权配置信息中还设置是否提供类标识的标志；步骤C中在所述发送给观察者的步骤之前还包括，呈现服务器根据所述鉴权配置信息中设置的是否提供类标识的标志删除或保留包含在呈现信息文档中类标识信息。
所述鉴权配置信息存储在呈现业务XDM服务器；步骤A中呈现体通过XCAP协议设置XDM服务器上的鉴权配置信息；呈现服务器通过XCAP协议或SIP协议获取XDM服务器上的鉴权配置信息。
所述的鉴权配置信息由权限规则组成，每个规则包括条件元素，动作元素和转换元素；在所述条件元素中指定观察者身份信息，在所述转换元素中指定相应的类标识信息。
如果一个呈现体的鉴权配置信息中存在多个权限规则，则呈现服务器将所有权限规则进行合并运算后确定观察者所对应的类标识。
所述鉴权配置信息中的观察者的身份标识引用资源列表URI，呈现服务器根据所引用的资源列表URI通过XCAP协议到共享列表XDM服务器获取资源列表URI所对应包含的观察者成员的URI。
步骤C中在所述发送给观察者的步骤之前还包括呈现服务器删除包含在呈现信息文档中类标识信息。
一种呈现信息的处理方法，该方法包括步骤D、呈现客户端发布使用类标识分组的呈现信息；E、呈现服务器根据所接收呈现信息中所述的类标识进行鉴权或过滤处理。
进一步，步骤D中所述的类标识是由呈现客户端设置的。
步骤D之前在呈现体对观察者的鉴权配置信息中记录观察者身份和类标识的关联关系。
步骤E中所述呈现服务器根据所接收呈现信息中所述的类标识进行鉴权的步骤具体包括呈现服务器根据呈现信息所对应的类标识以及鉴权配置信息中的关联关系确定观察者可获得的呈现信息，然后发送给观察者。
步骤D或E之前观察者发送的呈现信息订阅消息中包含对类标识的过滤信息，则步骤E中呈现服务器只将满足所述对类标识的过滤信息的呈现信息发送给观察者。
步骤E之前呈现服务器接收到不同呈现信息源为同一呈现体发布的呈现信息之后，只在检查到其所包含的类标识元素具有相同的值或都没有包含类标识元素时才进行合并，否则不合并。
所述呈现信息包括个人<person>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述个人<person>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c11、呈现服务器检查两个个人<person>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果是则转步骤c12，否则不合并，结束处理；c12、检查两个个人<person>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
所述呈现信息包括业务<tuple>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述业务<tuple>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c21、呈现服务器检查两个业务<tuple>元素的联系<contact>子元素是否具有相同的值，如果相同则转步骤c22，否则不合并，结束处理；c22、检查两个业务<tuple>元素的业务描述<service-description>元素的子元素业务标识<service-id>元素和版本<version>元素是否具有相同的值，如果全部相同则转步骤c23，否则不合并，结束处理；c23、检查两个业务<tuple>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果相同则转步骤c24，否则不合并，结束处理；c24、检查两个业务<tuple>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
步骤E之后还包括呈现服务器删除包含在呈现信息文档中类标识信息，然后发送给观察者。
本发明能够达到的有益效果如下本发明通过在呈现体对观察者的鉴权配置信息中，记录观察者身份和类标识的关联关系，并在呈现体发布呈现信息中使呈现信息与相应的类标识相关联，呈现服务器根据类标识与观察者身份及呈现信息的关联关系来确定观察者可获得的呈现信息，实现了同一呈现体的同一个呈现信息元素可同时向不同的观察者呈现不同的值。并且在呈现信息发送给观察者之前呈现服务器删除了包含在呈现信息文档中类标识信息，这考虑到了类标识信息也是呈现体的一种隐私信息，而且只对呈现体和呈现服务器有用，不必发送给观察者，这样保护了呈现体用户的隐私。另外在合并呈现信息元素时，检查了类标识信息是否完全相同，也避免了不合理的合并结果。总之通过本发明的方案，使呈现信息的提供方式更为灵活，提高了呈现业务的业务能力。
图1为呈现信息的数据模型图。
图2为本发明呈现信息处理的基本流程图。
图3为本发明呈现信息的合并处理流程图。
具体实施例方式
参照图2，该图是本发明呈现信息处理的基本流程图，包括如下步骤步骤S10，在呈现体对观察者的鉴权配置信息中，记录观察者身份和类标识的关联关系；步骤S11，关联待发布的呈现信息和相应的类标识，呈现体向呈现服务器发布呈现信息；步骤S12，呈现服务器接收并存储所述呈现信息，并根据类标识与观察者身份及呈现信息的关联关系确定观察者可获得的呈现信息，然后发送给观察者。
呈现体的鉴权配置信息通常逻辑上以XML(Extensible MarkupLanguage)格式存储在呈现业务XDM(XML Document Management)服务器，也可以直接存储在呈现服务器中，具体得可以使用关系数据库存储呈现体的鉴权配置信息。鉴权配置信息的具体内容为一个或多个规则组成信息集合，每个规则中又包含条件(conditions)元素，动作(actions)元素和转换(transformations)元素。其中在条件元素中指定观察者的身份标识，如设置观察者的统一资源标识符URI(如SIP URI，电话号码，电子邮件地址等)，或者观察者所属的域(domain)标识等，在动作元素中设置允许进行的处理类型，在转换元素中设置如何修改呈现给观察者的结果信息。
一个呈现体的鉴权配置信息具体举例如下<ruleset entity＝″someone@example.com″><rule id＝″1″>
<conditions><identity>
<id entity＝″user@example.com″/>
</identity></conditions>
<actions><sub-handling>allow</sub-handling></actions>
<transformations>
<provide-persons><class>friends</class></provide-persons>
</transformations>
</rule></ruleset>
上述鉴权配置信息中包含一个规则数据，呈现服务器在分发该呈现体的呈现信息之前解析该规则的内容确定身份标识为″user@example.com″的观察者被允许(allow)获取类(class)标识为friends的<person>元素。通过上述条件元素和转换元素即可关联观察者的身份标识和相应的类标识。
呈现体客户端通过XCAP(XML Configuration Access Protocol)协议创建、修改、删除、获取XDM服务器上的鉴权配置信息，呈现服务器也可以通过XCAP协议获取XDM服务器上的鉴权配置信息，用于对观察者获取呈现信息的请求进行鉴权，以及确定向哪些观察者发送呈现体的哪些呈现信息等。呈现服务器一旦获取到鉴权配置信息，可以缓存在本地以提高处理效率，并同时订阅鉴权配置信息的变化事件，当XDM服务器上被订阅的XML文档发生变化时，XDM服务器会将变化的信息通过会话初始SIP协议发送给呈现服务器，或者呈现服务器根据XDM服务器的变化通知消息通过XCAP协议获取最新的XML文档。
呈现体客户端使用会话初始协议SIP PUBLISH消息发布呈现信息，消息体正文中包含呈现信息文档内容，发布时将类标识作为某个呈现信息元素的子元素，通常是作为<person>元素、<tuple>元素或<device>元素的子元素，这样就在发布呈现信息之前关联了呈现信息和相应的类标识，即相当于用类标识将呈现信息进行了分组。当然类标识子元素<class>对这三种元素并不是必要的。呈现客户端发布使用类标识分组的呈现信息，关联类标识之后的呈现信息文档举例如下<presence entity＝″someone@example.com″>
<person id＝″1″>
<mood><happy/></mood>
<status-icon>http://example.com/friends.gif</status-icon>
<class>friends</class>
</person>
</presence>
上述呈现体″someone@example.com″发布的呈现信息文档中包含的<person>中设置了子元素<class>friends</class>，呈现服务器接收呈现信息文档并存储后，在向观察者发送呈现信息之前，先获取该呈现体的鉴权配置信息，解析该呈现体设置的规则数据，确定观察者对应的类标识，再根据类标识确定呈现信息文档中对应的呈现信息元素。
通过上述方法，可以实现向不同的观察者发送同一元素的不同值，如上述呈现信息文档中假定还包含一个对应类标识为enemies的<person>元素<person id＝″2″>
<mood><angry/></mood>
<status-icon>http://example.com/enemies.gif</status-icon>
<class>enemies</class>
</person>
相应的在上述鉴权配置信息中包含一个对应类标识为enemies的规则元素<rule id＝″2″>
<conditions><identity>
<id entity＝″badboy@example.com″/>
</identity></conditions>
<actions><sub-handling>allow</sub-handling></actions>
<transformations>
<provide-persons><class>enemies</class></provide-persons>
</transformations>
</rule>
呈现服务器根据鉴权配置信息和呈现信息文档，在向观察者分发呈现信息时，对于同一个具体的呈现信息元素如<mood>，观察者″badboy@example.com″会获得值angry，而观察者″user@example.com″会获得值happy，即相同的元素对于不同的观察者可呈现不同的值，这样大大提高了业务的呈现能力。
类标识<class>元素的值通常是由呈现体用户设置的容易理解的词汇，如friends等，实际上这个值指出了呈现体用户对观察者用户的分类倾向，因此很多时候呈现体用户不希望观察者用户获取到该信息，这本质上也属于用户的隐私信息。因此呈现服务器在根据鉴权配置信息确定向观察者发送的呈现信息内容后，要删除掉包含在<person>、<tuple>等元素中的类标识<class>元素，然后将不包含类标识<class>元素的呈现信息内容发送给观察者。
通过设置鉴权配置信息也可以实现禁止向观察者发送类标识<class>元素，在转换(transformations)元素中使用<provide-class>子元素作为控制标志来确定是否发送类标识<class>元素，<provide-class>子元素的值为逻辑布尔类型，为真TRUE时呈现服务器提供类标识<class>元素，为假FALSE时则不提供。另外呈现服务器对规则集的权限合并方式也有影响，如果呈现服务器的权限合并原则是为并集运算，即对规则中的权限进行逻辑或运算，例如如果对于同一个观察者，在一个规则数据中设置的是<provide-class>子元素的值为真TRUE，而另一个规则数据中对该观察者<provide-class>子元素的值为假FALSE，这样最终呈现服务器根据并集运算原则合并规则集的运算结果是<provide-class>子元素的值为真TRUE。具体举例如下
<rule id＝″3″>
<conditions><identity>
<id entity＝″badboy@example.com″/>
</identity></conditions>
<actions><sub-handling>allow</sub-handling></actions>
<transformations>
<provide-persons><class>enemies</class></provide-persons>
<provide-class>FALSE</provide-class>
</transformations>
</rule>
上述例子中，呈现服务器解析该规则数据后，根据<provide-class>FALSE</provide-class>确定不向观察者″badboy@example.com″发送类标识信息即<class>enemies</class>。在<identity>元素中可以包括多个观察者的身份标识，也可以引用资源列表的统一资源标识符URI，资源列表通常为用户定义的组，包含一些具体的成员URI，一般存储在共享列表XDM服务器中，如果在规则中引用了资源列表URI，则呈现服务器会根据所引用的资源列表URI通过XCAP协议到共享列表XDM服务器获取资源列表URI的具体成员的URI数据。
如果呈现服务器的权限合并原则是为交集运算，即对规则中的权限进行逻辑与运算，例如如果对于同一个观察者，在一个规则数据中设置的是<provide-class>子元素的值为真TRUE，而另一个规则数据中对该观察者<provide-class>子元素的值为假FALSE，这样最终呈现服务器根据并集运算原则合并规则集的运算结果是<provide-class>子元素的值为假FALSE。这种方式实际上可以更简单得实现向所有的观察者(或者大多数观察者)禁止提供类标识信息，具体的即在一个规则中设置限定所有的观察者都不能获得类标识信息，规则内容如下<rule id＝″4″>
<conditions><identity><any-identity/></identity></conditions>
<actions><sub-handling>allow</sub-handling></actions>
<transformations>
<provide-class>FALSE</provide-class>
</transformations>
</rule>
其中<any-identity/>表示所有的观察者，根据该规则设置的<provide-class>FALSE</provide-class>即禁止提供类标识信息，以及交集运算原则，即使在其他规则中没有禁止或直接允许提供类标识信息，呈现服务器也会禁止向所有观察者提供类标识信息。
实际应用中一个呈现体往往会对应多个呈现信息源，如一个用户的手机、电脑，以及运营商的通信网络中的物理实体(如归属位置寄存器HLR、应用服务器)等，这些呈现信息源都可以发布该呈现体的呈现信息，呈现服务器对来自不同呈现信息源的呈现信息要进行相应的编辑合成，在呈现服务器上为一个呈现体形成一份原始的呈现信息文档。由于类标识<class>元素影响了最终观察者所能获取到的呈现信息内容，因此在编辑合成是时应当考虑到类标识<class>元素的处理，而不能只进行简单的合并处理。如下两个<person>元素在合并后就会产生问题，假定呈现服务器上已经存在呈现体的一个<person>元素<person id＝″11″>
<overriding-willingness>
<basic>close</basic>
</overriding-willingness>
<mood>happy</mood>
</person>
上述<person>元素不包含类标识<class>元素，如果与另一个新收到的包含类标识<class>元素的<person>元素进行合并，例如与以下<person>元素合并<person id＝″22″>
<overriding-willingness>
<basic>close</basic>
</overriding-willingness>
<class>enemies</class>
</person>
则合并处理过程为首先忽略<person>元素的实例标识id，并将相同的元素仅保留一份，此例中<overriding-willingness>元素是相同的，如保留呈现服务器上已有的数据，而类标识<class>元素呈现服务器以前没有，则增加该元素，合并的结果为<person id＝″33″>
<overriding-willingness>
<basic>close</basic>
</overriding-willingness>
<mood>happy</mood>
<class>enemies</class>
</person>
如此呈现服务器上只存在一个对应类标识为enemies的<person>元素，而一个对应类标识不为enemies观察者，则就无法再获取到<person>元素了。
呈现服务器通常可以分别对<person>元素、<tuple>元素或<device>元素进行合并条件的检查和合并处理，最后三种元素构成原始的呈现信息文档，对类标识<class>元素的具体合并处理步骤以两个<tuple>元素的合并为例，如图3所示c21、呈现服务器检查两个<tuple>元素的<contact>子元素是否具有相同的值，如果相同则转步骤c22，否则不合并，结束处理。
c22、检查两个<tuple>元素的<service-description>元素的子元素<service-id>和<version>是否具有相同的值，如果全部相同则转步骤c23，否则不合并，结束处理。
c23、检查两个<tuple>元素的<class>元素是否具有相同的值，如果相同则转步骤c24，否则不合并，结束处理。如果一个<tuple>元素有<class>元素，而另一个没有，也不进行合并。如果两个<tuple>元素都没有<class>元素，呈现服务器也判定为属于<class>元素具有相同的值的情况，转步骤c24。
c24、检查两个<tuple>元素中其他的子元素是否存在冲突，即相同的元素具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
根据以上的处理，两个<tuple>元素中如果一个有<class>元素，而另一个没有<class>元素，这样的情况呈现服务器就不会进行合并处理。
当然当呈现信息文档分发到观察者客户端，最终将其呈现在客户端上时，应该进行相应的合并处理，否则观察者用户会得到不清楚甚至矛盾的呈现信息。由于呈现服务器一般不会把<class>元素发送给观察者，观察者客户端只会对没有<class>元素的<person>元素、<tuple>元素或<device>元素进行合并处理，如果没有冲突的直接简单合并即可，有冲突的(即相同元素有不同的值)可以以最新时间戳<timestamp>的元素为准。
另外在上述的步骤c22中，<service-description>元素还有一个<description>元素，这个元素是一段对该<tuple>对应业务的简单描述文字，有可能不同的呈现信息源发布的该元素的值会有一些描述上的差异，如字母大小写不同，标点符号不同等，因此不应当因为<description>元素不同就禁止<tuple>元素合并。即在上述呈现服务器的合并处理检查过程中可以忽略<description>元素，在步骤c24中合并一个新发布到呈现服务器的<tuple>元素时，如果呈现服务器中已经存在的一个<tuple>元素中有<description>元素值则不改动，如果没有<description>元素值，则向其增加新发布到呈现服务器的<tuple>元素中的<description>元素值。
步骤c24中提到的判定冲突的方式是相同的元素具有不同的值，实际上有些呈现信息的XML元素可能值相同，但是属性不同也是冲突的，因此在步骤c24中呈现服务器要在值相同时进一步判断其属性是否相同，如果不同也认为是冲突的情形不进行合并处理。
通常在呈现业务系统中每个<person>元素、<tuple>元素或<device>元素都只有零或一个<class>元素，但也有可能有些系统支持多个<class>元素，这会使系统可以提供更强的功能，如一个<person>元素有两个类标识<class>元素，<class>friends</class>和<class>colleagues</class>，则呈现服务器就可以向这两个类标识对应的观察者提供该<person>元素的信息，这使呈现信息的控制更加灵活。但这样在<person>等元素的合并处理时就会带来麻烦，如两个<person>元素进行合并时，呈现服务器检查到两个<person>元素具有一个相同的类标识如<class>friends</class>，而其中一个<person>元素还包含另外一个类标识如<class>colleagues</class>，具体内容如下<person id＝″111″>
<mood>happy</mood>
<class>friends</class>
</person>
另一个<person>元素<person id＝″222″>
<activities><breakfast/></activities>
<class>friends</class>
<class>colleagues</class>
</person>
上述两个元素合并之后得到<person id＝″333″>
<mood>happy</mood>
<activities><breakfast/></activities>
<class>friends</class>
<class>colleagues</class>
</person>
可以发现类标识为<class>colleagues</class>对应的观察者可以获得本来不该获得的信息<mood>happy</mood>，这样的合并是不合适的，因此呈现服务器合理的合并处理步骤以<person>元素为例c11、呈现服务器检查两个<person>元素的<class>元素是否具有完全相同的值，如果是则转步骤c12，否则不合并，结束处理。呈现服务器必须检查任何一个<person>元素中的<class>元素都可以在另一个<person>元素中找到相同的值，才判定两个<person>元素具有完全相同的<class>值。当然如果两个<person>元素都没有<class>元素，也判定两个<person>元素具有完全相同的<class>值。
c12、检查两个<person>元素中其他的子元素是否存在冲突，即相同的元素具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
当然除了上述的<tuple>元素和<person>元素外，同样对其他的包含类标识元素的呈现信息元素，在呈现服务器接收到不同呈现信息源为同一呈现体发布的呈现信息之后，只在检查到其所包含的类标识元素具有相同的值或都没有包含类标识元素时才进行合并，否则不合并。当然合并之前可能还会检查其他条件，通过类标识的检查只是合并的必要条件。
另外呈现服务器除了根据所接收呈现信息中所述的类标识进行鉴权之外，还可以进行过滤处理。观察者发送的呈现信息订阅消息中包含对类标识的过滤信息，呈现服务器在向该观察者分发呈现信息时，只将满足所述对类标识的过滤信息的呈现信息发送给观察者。订阅消息中的过滤信息举例如下<filter-set><filter id＝″1″uri＝″someone@example.com″>
<what><include>class＝″PoC″</include></what>
</filter></filter-set>
即在过滤集<filter-set>中定义的编号id为1的过滤信息中指定了只有包含类标识class＝″PoC″的元素才会被发送给观察者。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
权利要求
1.一种呈现信息的处理方法，其特征在于，该方法包括步骤A、在呈现体对观察者的鉴权配置信息中记录观察者身份和类标识的关联关系；B、关联呈现信息与相应的类标识，呈现体发布呈现信息；C、呈现服务器接收并存储所述呈现信息，并根据类标识与观察者身份及呈现信息的关联关系确定观察者可获得的呈现信息，然后发送给观察者。
2.根据权利要求1所述的方法，其特征在于，步骤C中呈现服务器接收到不同呈现信息源为同一呈现体发布的呈现信息之后，只在检查到其所包含的类标识元素具有相同的值或都没有包含类标识元素时才进行合并，否则不合并。
3.根据权利要求2所述的方法，其特征在于，所述呈现信息包括个人<person>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述个人<person>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c11、呈现服务器检查两个个人<person>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果是则转步骤c12，否则不合并，结束处理；c12、检查两个个人<person>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
4.根据权利要求2所述的方法，其特征在于，所述呈现信息包括业务<tuple>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述业务<tuple>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c21、呈现服务器检查两个业务<tuple>元素的联系<contact>子元素是否具有相同的值，如果相同则转步骤c22，否则不合并，结束处理；c22、检查两个业务<tuple>元素的业务描述<service-description>元素的子元素业务标识<service-id>元素和版本<version>元素是否具有相同的值，如果全部相同则转步骤c23，否则不合并，结束处理；c23、检查两个业务<tuple>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果相同则转步骤c24，否则不合并，结束处理；c24、检查两个业务<tuple>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
5.根据权利要求3或4所述的方法，其特征在于，所述呈现服务器检查类标识<class>元素是否具有相同的值时，如果检查到类标识<class>元素的数量多于一个，则呈现服务器在确定所有的类标识<class>元素都完全对应相同时，才判定类标识<class>元素是否具有相同的值。
6.根据权利要求3或4所述的方法，其特征在于，所述检查相同的元素是否具有不同的值之后，还包括步骤检查相同的元素是否具有不同的属性值，如果否，则进行合并，否则不合并，结束处理。
7.根据权利要求4所述的方法，其特征在于，在呈现服务器合并处理的检查步骤中忽略描述<description>元素，在步骤c24中合并一个新发布到呈现服务器的业务<tuple>元素时，如果呈现服务器中已经存在的一个业务<tuple>元素中有描述<description>元素的值，则不改动已经存在的值，如果没有描述<description>元素的值，则向其增加新发布到呈现服务器的业务<tuple>元素中的描述<description>元素的值。
8.根据权利要求1所述的方法，其特征在于，步骤A中，在呈现体对观察者的鉴权配置信息中还设置是否提供类标识的标志；步骤C中在所述发送给观察者的步骤之前还包括，呈现服务器根据所述鉴权配置信息中设置的是否提供类标识的标志删除或保留包含在呈现信息文档中类标识信息。
9.根据权利要求1所述的方法，其特征在于，所述鉴权配置信息存储在呈现业务XDM服务器；步骤A中呈现体通过XCAP协议设置XDM服务器上的鉴权配置信息；呈现服务器通过XCAP协议或SIP协议获取XDM服务器上的鉴权配置信息。
10.根据权利要求1所述的方法，其特征在于，所述的鉴权配置信息由权限规则组成，每个规则包括条件元素，动作元素和转换元素；在所述条件元素中指定观察者身份信息，在所述转换元素中指定相应的类标识信息。
11.根据权利要求10所述的方法，其特征在于，如果一个呈现体的鉴权配置信息中存在多个权限规则，则呈现服务器将所有权限规则进行合并运算后确定观察者所对应的类标识。
12.根据权利要求10或11所述的方法，其特征在于，所述鉴权配置信息中的观察者的身份标识引用资源列表URI，呈现服务器根据所引用的资源列表URI通过XCAP协议到共享列表XDM服务器获取资源列表URI所对应包含的观察者成员的URI。
13.根据权利要求1所述的方法，其特征在于，步骤C中在所述发送给观察者的步骤之前还包括呈现服务器删除包含在呈现信息文档中类标识信息。
14.一种呈现信息的处理方法，其特征在于，该方法包括步骤D、呈现客户端发布使用类标识分组的呈现信息；E、呈现服务器根据所接收呈现信息中所述的类标识进行鉴权或过滤处理。
15.根据权利要求14所述的方法，其特征在于，步骤D中所述的类标识是由呈现客户端设置的。
16.根据权利要求14所述的方法，其特征在于，步骤D之前在呈现体对观察者的鉴权配置信息中记录观察者身份和类标识的关联关系。
17.根据权利要求16所述的方法，其特征在于，步骤E中所述呈现服务器根据所接收呈现信息中所述的类标识进行鉴权的步骤具体包括呈现服务器根据呈现信息所对应的类标识以及鉴权配置信息中的关联关系确定观察者可获得的呈现信息，然后发送给观察者。
18.根据权利要求14所述的方法，其特征在于，步骤D或E之前观察者发送的呈现信息订阅消息中包含对类标识的过滤信息，则步骤E中呈现服务器只将满足所述对类标识的过滤信息的呈现信息发送给观察者。
19.根据权利要求14至18任一项所述的方法，其特征在于，步骤E之前呈现服务器接收到不同呈现信息源为同一呈现体发布的呈现信息之后，只在检查到其所包含的类标识元素具有相同的值或都没有包含类标识元素时才进行合并，否则不合并。
20.根据权利要求19所述的方法，其特征在于，所述呈现信息包括个人<person>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述个人<person>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c11、呈现服务器检查两个个人<person>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果是则转步骤c12，否则不合并，结束处理；c12、检查两个个人<person>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
21.根据权利要求19所述的方法，其特征在于，所述呈现信息包括业务<tuple>元素，步骤C中呈现服务器接收所述呈现信息之后，合并所接收的不同呈现信息源的所述业务<tuple>元素，然后再存储，所述类标识为<class>元素，合并的检查步骤包括c21、呈现服务器检查两个业务<tuple>元素的联系<contact>子元素是否具有相同的值，如果相同则转步骤c22，否则不合并，结束处理；c22、检查两个业务<tuple>元素的业务描述<service-description>元素的子元素业务标识<service-id>元素和版本<version>元素是否具有相同的值，如果全部相同则转步骤c23，否则不合并，结束处理；c23、检查两个业务<tuple>元素的类标识<class>元素是否具有相同的值或都没有包含类标识<class>元素，如果相同则转步骤c24，否则不合并，结束处理；c24、检查两个业务<tuple>元素中其他的子元素是否存在冲突，即检查相同的元素是否具有不同的值，如果不存在冲突则进行合并，否则不合并，结束处理。
22.根据权利要求14所述的方法，其特征在于，步骤E之后还包括呈现服务器删除包含在呈现信息文档中类标识信息，然后发送给观察者。
全文摘要
本发明公开了一种呈现信息的处理方法，通过在呈现体对观察者的鉴权配置信息中记录观察者身份和类标识的关联关系，并在呈现体发布呈现信息中使呈现信息与相应的类标识相关联，呈现服务器根据类标识与观察者身份及呈现信息的关联关系来确定观察者可获得的呈现信息，实现了同一呈现体的同一个呈现信息元素可同时向不同的观察者呈现不同的值。并且在呈现信息发送给观察者之前呈现服务器删除了包含在呈现信息文档中类标识信息，保护了呈现体的隐私信息。
文档编号H04L9/06GK101043469SQ20061008004
公开日2007年9月26日 申请日期2006年5月1日 优先权日2006年3月24日
发明者孙谦, 招扬, 彭程晖, 田林一, 鲍洪庆, 宋雪飞 申请人:华为技术有限公司