CN1794634A - 一种呈现业务***及发布和获取呈现信息的方法 - Google Patents

Abstract

本发明公开了一种呈现业务***，包括：呈现服务器，用于接收、存储和分发呈现信息，呈现信息包括呈现体客户端发布的呈现信息和应用服务器发布的呈现信息；呈现客户端，用于向所述呈现服务器发布呈现体的呈现信息，或者用于接收所述呈现服务器下发的呈现信息；应用服务器，用于提供应用服务，并收集用户信息，将其作为用户的呈现信息发布到呈现服务器。本发明还公开了一种应用服务器、发布和获得用户信息的方法。根据本发明，可发布呈现体用户在应用服务器上的各种用户信息到呈现业务中，观察体客户端可获得呈现体用户在应用服务器上的各种用户信息，拓展了呈现信息的提供源。另外，即使呈现体客户端不运行时，也能够提供有关呈现体的用户信息。

Description

一种呈现业务***及发布和获取呈现信息的方法

技术领域

本发明涉及互联网领域和无线通信领域，特别是涉及一种应用服务器、呈现业务***及发布和获取呈现信息的方法。

背景技术

呈现业务(PRESENCE SERVICE)是一种用于搜集和分发呈现信息(PRESENCE INFORMATION)的通信业务，目前通常和即时消息业务(INSTANT MESSAGE SERVICE)一起提供，当然呈现业务也可以单独提供，或者和其他业务如网络游戏结合。因特网工程任务组IETF、开放移动联盟OMA等国际标准组织都已经初步制订了呈现业务的相应标准规范，正在不断完善之中。本发明中主要使用RFC 2778中的术语，将向呈现业务提供呈现信息的称为呈现体(PRESENTITY)，向呈现业务请求呈现信息的称为观察体(WATCHER)。呈现业务的用户可以是自然人或非自然人，即呈现体和观察体都可以对应自然人或非自然人。

现有呈现业务***的***结构图，如图1所示。从图中可见现有***包括：

呈现服务器，以及与其相连的呈现客户端，呈现客户端包括呈现体客户端和观察体客户端。所述呈现体客户端包括：呈现体和呈现体用户代理(PRESENCE USER AGENT)。所述观察体客户端包括：观察体和观察体用户代理(WATCHER USER AGENT)。

在呈现体或观察体所在呈现客户端和呈现服务器之间通过呈现协议(PRESENCE PROTOCOL)传送呈现信息。

所述呈现体用户代理作为呈现体用户与***交互的装置，所述呈现体通过呈现体用户代理向呈现服务器发布呈现信息。

所述观察体用户代理作为观察体用户与***交互的装置，所述观察体通过观察体用户代理接收呈现服务器发送来的呈现信息。

在现有技术中，由于都是由呈现体客户端将用户的呈现信息发布给呈现服务器，使得呈现信息仅包括可由呈现体客户端发布各种状态信息，如网络状态信息(如在线、离线)、应用状态信息(如闲置或激活)和用户状态信息(如可用或忙)，而不包括用户与某些应用服务之间的各种状态信息。

然而，在实际应用中，观察体客户端往往还想获取呈现体用户在各种应用服务器上的各种状态信息，如游戏信息、浏览网页信息，观看影视信息，商务活动信息等等，以便更深层地了解对方的爱好和需求，从而便于寻找好友或合作伙伴。另外，亲朋好友之间甚至陌生人都有关注对方具体行为的需求，而用户也希望将一些其在应用服务器上的用户状态信息发布出去使其他人可以及时获知，如用户希望其他人获知自己正在应用服务器上玩的游戏或正在看的电影等信息，以便有相同爱好的人与自己交流。还有，现有呈现业务中，一般呈现体用户只有运行呈现体客户端才能提供和更新用户的呈现信息，呈现信息提供源具有很大的局限性，因为很多时候即使用户未运行呈现体客户端，仍可能有提供呈现信息的需求。

因此，解决上述需求是呈现业务中急待解决的问题之一。

发明内容

本发明的目的是提供一种呈现业务***，可使观察体客户端在呈现业务中获得呈现体用户在应用服务器上的各种用户信息。本发明的另一个目的是提供一种发布和获取呈现信息的方法，可发布呈现体用户在应用服务器上的用户信息到呈现业务中，和观察体客户端在呈现业务中获得呈现体用户在应用服务器上的用户信息。本发明的另一个目的是提供一种应用服务器，可收集应用服务器上的用户信息，并将用户信息作为呈现信息发布到呈现服务器。

本发明的目的是通过下述方案实现的。

本发明提供了一种呈现业务***，包括：

呈现服务器，用于接收、存储和分发呈现信息，呈现信息包括呈现体客户端发布的呈现信息和应用服务器发布的呈现信息；

呈现客户端，用于向所述呈现服务器发布呈现体的呈现信息，或者用于接收所述呈现服务器下发的呈现信息；

应用服务器，用于提供应用服务，并收集用户信息，将其作为用户的呈现信息发布到呈现服务器。

所述应用服务器包括：

用户信息收集器，用于收集用户信息，将其作为用户的呈现信息发布到呈现服务器；

存储器，用于存储用户信息。

所述应用服务器还包括业务容器，用于执行应用服务的业务逻辑，并存储用户与应用服务相关的实时用户信息；

用户信息收集器从存储器和业务容器中收集呈现体用户与应用服务相关的用户信息，将其作为用户的呈现信息发布到呈现服务器。

所述应用服务器还包括过滤器，用于对向呈现服务器发布的呈现信息进行过滤。

所述的应用服务器还包括压缩器，用于压缩发往呈现服务器的用户信息；

所述的呈现服务器还包括解压器，用于对收到的用户信息进行解压。

在所述的应用服务器和所述的呈现服务器之间还包括一个开放业务接入网关，用于向应用服务器提供应用程序接口使其与呈现服务器进行通信。

所述的***还包括可扩展标志语言文件管理服务器，用于存储授权规则文件，向应用服务器和呈现服务器提供呈现体用户的授权规则。

本发明还提供了一种发布呈现信息的方法，包括：

A、呈现体用户在应用服务器上登记呈现业务；

B、应用服务器收集用户信息；

C、应用服务器将收集的信息作为用户的呈现信息发布到呈现服务器。

所述的步骤A具体包括：

A1、呈现体用户向应用服务器发送登记呈现请求；

A2、应用服务器将登记请求转发给呈现服务器；

A3、呈现服务器向呈现客户端发送确认消息并将呈现客户端返回的确认结果转发给应用服务器；

A4、应用服务器记录相应的登记结果。

所述的登记呈现请求包括统一资源标识和呈现业务密码。

所述的步骤A还包括：在应用服务器上设置授权列表和授权范围，以便应用服务器根据授权列表和授权范围将用户信息发给呈现服务器。

所述的步骤A还包括：在应用服务器上设置过滤条件，以便应用服务器根据过滤条件将过滤后的用户信息发给呈现服务器。

所述的步骤A还包括：

进行响应式授权或预设式授权的步骤。

所述的步骤B具体包括：

B1、应用服务器将静态用户信息存放在存储器中；

B2、应用服务器将实时用户信息存放在业务容器中；

B3、用户信息收集器从存储器和业务容器中收集静态用户信息和实时用户信息。

所述步骤B3中用户信息收集器根据预定的时间间隔定时从存储器和业务容器中收集用户信息。

所述的步骤B具体包括：应用服务器根据呈现体用户设置的授权范围收集用户信息。

所述的步骤B具体包括：应用服务器在呈现体用户登录后或正在使用应用服务时收集呈现体用户的用户信息。

所述的步骤C具体包括：应用服务器以主动发布方式或请求发布方式向呈现服务器发布用户信息。

所述的步骤C具体包括：应用服务器通过开放业务接入网关向呈现服务器发布用户信息。

所述的步骤C具体包括：应用服务器向呈现服务器批量发布用户信息。

所述的步骤C具体包括：

C1、应用服务器向呈现服务器发布用户信息前先对所述的用户信息进行压缩；

C2、呈现服务器对收到的用户信息解压后再进行用户信息的更新处理。

本发明还提供了一种获取呈现信息的方法，包括：

D、观察体客户端向呈现服务器发送获取呈现信息请求；

E、呈现服务器根据所述获取呈现信息请求通知应用服务器收集呈现体的用户信息，应用服务器将收集的用户信息作为呈现信息发布至呈现服务器；

F、呈现服务器将呈现体的用户信息发给观察体客户端。

所述的步骤E还包括：应用服务器根据呈现体用户设置的授权规则收集用户信息，并将用户信息作为呈现信息发布至呈现服务器。

所述的获取呈现信息请求包括过滤条件。

所述的步骤E具体包括：应用服务器根据过滤条件收集呈现体的用户信息。

本发明还提供了一种应用服务器，包括：存储器，用于存储用户信息；用户信息收集器，用于收集用户信息，并将收集的用户信息作为用户的呈现信息发布到呈现服务器。

所述的应用服务器还包括：

业务容器，用于执行应用服务的业务逻辑，并存储用户与应用服务相关的实时用户信息，用户信息收集器从存储器和业务容器中收集呈现体用户与应用服务相关的用户信息，将其作为用户的呈现信息发布到呈现服务器。

所述的应用服务器还包括：

过滤器，用于对向呈现服务器发布的呈现信息进行过滤。

所述应用服务器还包括：

压缩器，用于压缩发往呈现服务器的用户信息。

因此，根据本发明，可发布呈现体用户在应用服务器上的各种用户信息到呈现业务中，观察体客户端可获得呈现体用户在应用服务器上的各种用户信息，拓展了呈现信息的提供源以及提供方式。另外，即使呈现体客户端不运行时，也能够发布及获取有关呈现体的用户信息。

附图说明

图1示出了现有技术的呈现业务***的示意图；

图2示出了本发明的呈现业务***的示意图；

图3示出了本发明的应用服务器的示意图；

图4示出了根据本发明发布和获取呈现信息的流程图；

图5示出了在应用服务器上登记呈现业务的流程图；

图6示出了在应用服务器上修改呈现业务的流程图；

图7示出了本发明在网络游戏中的应用场景；

图8示出了呈现信息的变化更新的示意；

图9示出了授权机制例一的流程图；

图10示出了授权机制例二的流程图；

图11示出了对应授权机制例一的获取呈现信息的流程图；

图12示出了对应授权机制例二的获取呈现信息的流程图；

图13示出了授权列表；

图14示出了另一种授权列表；

图15示出了授权列表的变化示意图。

具体实施方式

为了便于本领域一般技术人员理解和实现本发明，现结合附图描述本发明的实施例。

本发明提供了一种呈现业务***，如图2所示，本发明的呈现业务***包括呈现服务器、呈现客户端和应用服务器，此处的呈现客户端为观察体客户端。下面参照附图详细描述本发明的呈现业务***。

呈现体用户所在的终端不需要运行呈现客户端，所述的终端可以是手机、计算机等，与应用服务器连接，呈现体用户使用终端登录应用服务器。在应用服务器中登记呈现业务，和设置授权规则策略等。

观察体客户端包括观察体和观察体用户代理，观察体用户代理作为观察体用户和***交互的平台；观察体用于接收呈现服务器发送来的呈现体的呈现信息。观察体客户端的观察体可分为查询体和订阅体：查询体仅简单的请求查询呈现体用户在应用服务器上的用户信息；而订阅体则订阅当呈现体用户所在应用服务器的用户信息(未来)变化时，能及时接收到更新的呈现信息。

根据本发明，本发明的呈现业务***还包括应用服务器，其连接在呈现体用户和呈现服务器之间。呈现体用户可在应用服务器登记呈现业务，当呈现体用户在应用服务器上登记呈现业务后，应用服务器会将已登录、正在使用应用服务的呈现体用户的用户信息作为用户的呈现信息发送到呈现服务器，如呈现体用户正在应用服务器上玩游戏，可将其实时用户信息和静态用户信息(如当前游戏名称，目前积分，昵称等)发送给呈现服务器；呈现服务器再将该呈现体用户的用户信息发送给观察体客户端的观察体，并经观察体用户代理最终告知观察体用户。值得一提的是，根据本发明，即使呈现体客户端不运行，应用服务器也可以将呈现体用户信息发送给观察体客户端。另外，为了进一步的控制呈现体用户在应用服务器上的用户信息的发布，即控制哪些观察体能获取哪些用户信息，可以在应用服务器上设置授权规则策略，应用服务器根据授权规则提供用户信息，可使用可扩展标志语言XML配置授权规则，如可用“identity”元素中包含的子元素指定授权的观察体的统一资源标识符URI：

 <identity><id entity＝″[email protected]″/></identity>

如上表示URI为“[email protected]”的观察体有权限获取呈现体用户在应用服务器上的用户信息，URI可以为多个，构成授权列表。类似的进一步可以用“provide-attribute”元素限定提供哪些用户信息，即授权范围，如：

<provide-attribute>

  <attribute name＝″game-name″/>

  <attribute name＝″score″/>

</provide-attribute>

如上表示授权范围为提供游戏名称和积分信息。授权列表和授权范围可以结合使用，即对一个授权列表对应设置其授权范围。

由于应用服务器可能有多个，可以将配置授权列表等授权规则策略的XML文件统一放在可扩展标志语言文件管理服务器(XDM Server)上，这样如授权列表就可以被各个应用服务器以及呈现服务器共享，不用在各服务器上重复设置。另外可统一由呈现服务器根据XDM服务器上的设置的授权规则确定呈现信息的访问权限，应用服务器不再对授权权限进行限定，只负责向呈现服务器发布用户信息即可。

如图3所示，所述应用服务器还包括用户信息收集器、存储器(如数据库)和业务容器，用户信息收集器分别与数据库和业务容器连接，可根据呈现客户端的授权权限(如授权列表或授权范围)获取用户信息，并将收集的用户信息存储在内存中。所述数据库用于存储较为稳定的用户信息，如用户的注册信息，待用户退出业务或到预定时间段时才由业务容器将用户信息更新到数据库中的信息。所述业务容器存储有当呈现体用户正在使用应用服务器的业务时的用户信息。当需要收集实时用户信息，用户信息收集器可访问和获取业务容器中的用户信息。目前呈现客户端更新呈现信息的方法是当检测到呈现信息改变后就将更新后的呈现信息发布到呈现服务器，但是对于应用服务器上的实时用户信息，其变化非常快，如游戏积分，游戏角色的位置坐标等信息，如果一发生变化就要向呈现服务器发布更新则会造成***负荷太大，因此对于实时用户信息可以设置更新间隔时间，如设置每间隔5分钟才更新发布一次，而不是实时进行更新。

另外应用服务器还可以进行批量发布，即每次向呈现服务器发布多个用户的用户信息，应用服务器侧设置一个压缩器，呈现服务器侧设置一个解压器，在应用服务器向呈现服务器发布用户信息前先用压缩器对要发布的用户信息进行压缩，呈现服务器侧的解压器对收到的用户信息解压后再由呈现服务器进行呈现信息的更新处理。这样大大提高了应用服务器与呈现服务器之间的通信效率。

应用服务器上的用户信息并不需要全部发布到呈现服务器，可以根据呈现信息的订阅情况进行选择性的发布，对未订阅的用户信息不进行主动发布，只在呈现服务器请求这些用户信息时才向其提供。观察体客户端发送的订阅请求中包含过滤条件，即指定要接收哪些呈现信息，过滤条件可以用XML设置，如：

<filter id＝″001″uri＝″sip：[email protected]″><what>

<include type＝″namespace″>urn：ietf：params：xml：ns：gamepidf</include>

<exclude>/gamepidf：realtime</exclude>

</what></filter>

如上观察体“sip：[email protected]”设置的过滤条件“filter”中用“include”元素设置了呈现信息要包含名称空间“gamepidf”中给出的属性，而“exclude”元素设置了不包含实时用户信息“realtime”下的属性。过滤条件被存放在XDM服务器或者应用服务器上，应用服务器上设置过滤器，对向呈现服务器发布的用户信息根据过滤条件进行过滤。除了指定要接收哪些呈现信息外，过滤条件还可以设置呈现信息的哪些变化需要通知观察体。这些条件满足时，即时应用服务器主要采用批量发布的方式发布呈现信息，也要立即单独发布该变化的呈现信息。如：

<changed>/gamepidf：gameroom</changed>

表示当呈现信息gameroom属性发生变化时，应用服务器就要立即将更新的游戏室gameroom信息以及用户其他的呈现信息一起发送给呈现服务器。还可以进一步用“from”和“to”限定具体哪些值变化时才发布呈现信息：

<changed to＝″1000″>/gamepidf：score</changed>

表示当积分“score”信息超过1000时发布呈现信息。

在用户未登录应用服务器或未使用应用服务时，通常呈现信息没有变化，应用服务器没有必要向呈现服务器发布呈现信息。应用服务器保存登记了呈现业务并且已登录应用服务器或正在使用应用服务的用户列表，只针对该用户列表中的用户收集和发布呈现信息。

应用服务器通常与呈现服务器不位于同一网络中，如呈现服务器位于运营商的网络中，而应用服务器位于互联网中，应用服务器与呈现服务器不直接而是通过网关进行通信的。此处可在呈现业务***中设置Parlay/OSA开放业务接入网关，Parlay/OSA应用程序接口是由Parlay小组(http：//www.parlay.org/)定义的，OSA即开放式业务接口，在3GPP(第三代移动通信伙伴项目，http：//www.3gpp.org/)和3GPP2的移动业务体协结构中被引用，而Parlay就是OSA中的API部分，具体可参见相关的标准规范。应用服务器将收集的用户信息首先发布到Parlay/OSA网关，然后由Parlay/OSA网关将用户信息更新到呈现服务器上。一般Parlay/OSA网关同时还会提供访问通信网中其他业务或能力的接口，如位置业务，计费，呼叫控制等。

利用上述呈现业务***，本发明还提供了发布和获取呈现信息的方法，其基本思想是：呈现体用户在应用服务器上登记呈现业务，即委托授权应用服务器向呈现服务器发布用户信息；应用服务器收集呈现体用户的用户信息，并将其发布至呈现服务器，作为呈现体用户的呈现信息的一部分；呈现服务器将该呈现体用户的用户信息发送给观察体客户端。下面参照附图对本发明进行详细的描述。

如图4所示，在步骤1中，呈现体用户在应用服务器上登记呈现业务。

所述的应用服务器可以是提供各种内容的不同种类的应用服务器，如游戏服务器、流媒体服务器、电子商务服务器、网页服务器、聊天服务器等，这些应用服务器可提供相应的各种应用服务，如网络游戏、流媒体播放、电子商务、浏览网页、聊天等服务。

呈现体用户在应用服务器上登记呈现业务的时机既可以在注册时，也可以在应用过程中。在注册时，可使用应用服务器提供的注册页面，在应用过程中，可使用应用服务器提供的应用页面。通常呈现体用户在应用服务器上有相应的账号或标识，如呈现体的URI，应用服务器以此来识别用户，与账号或标识一起存储的还有用户的注册信息和业务信息，如用户的基本信息，计费信息，定制的服务特性等。登记呈现业务的用户在应用服务器上对应保存相应的标志信息，表示该用户要使用应用服务器的呈现业务能力，即通过应用服务器发布呈现信息。

为了确保呈现信息的安全性，当呈现体用户向应用服务器登记呈现业务时，可要求呈现体用户不仅要输入其呈现业务中对应的账号标识如URI，而且要输入相应密码，应用服务器通过呈现服务器确认鉴权后才属登记成功。另外，呈现业务的登记并非强制性，若用户不希望他人通过呈现业务观察其在应用服务器的用户信息，则可不必登记。为了更进一步确保用户信息的安全性，使呈现体用户的用户信息只允许某些人知道，或者使呈现体用户的用户信息只在特定的情况下允许他人获知，呈现体用户在应用服务器登记呈现业务之后，还可进一步在应用服务器上登记授权列表和授权范围，应用服务器根据授权列表和授权范围来判断向哪些人提供的呈现体用户的哪些用户信息。另外最终应用服务器可将授权列表和授权范围发送存放到XDM服务器或者呈现服务器上，以便各应用服务器和呈现服务器可以进行共享。

下面结合图5和图6描述呈现体用户在应用服务器上登记呈现业务的过程。

如图5所示，首先描述呈现体用户在注册时在应用服务器上登记呈现业务的过程。

为了实现在注册时呈现体用户在应用服务器上登记呈现业务，应用服务器可在注册页面中提供呈现业务登记项，以便呈现体用户在应用服务器上注册时登记呈现业务。在登记呈现业务时，呈现体用户须在呈现业务登记项上登记其呈现业务账号，如QQ账号、MSN账号，手机号码等，因为这些账号对应呈现体用户在呈现业务中唯一身份，以便其他用户识别并获取其呈现信息。

在步骤50中，当呈现体用户终端在某一网络游戏服务器上申请注册时，呈现体用户看到该网络游戏服务器的注册页面中提供了呈现业务登记项及其说明，呈现体用户决定使用该业务特性，并登记其呈现账号(516870210)和密码(******)。也可以不向应用服务器提供呈现业务的密码，而采用另一种方式进行认证，即应用服务器接到呈现体用户终端发送的登记请求后，向呈现服务器发送包含呈现账号的认证请求，呈现服务器向该呈现账号的呈现客户端或者呈现账号注册的手机号码发送确认消息，在得到确认后呈现服务器向应用服务器返回认证成功的消息，应用服务器记录登记结果，至此登记完成。

在步骤51中，呈现体用户在该网络游戏服务器上进一步登记授权列表和授权范围，不同应用服务器的授权范围的内容不同，例如，图13示出了网络游戏中用户信息的授权范围。

如图13所示，该授权范围包括两部分：静态用户信息、实时用户信息。在每个部分用户信息中还包括多项内容，如，静态用户信息部分中有如下内容选项：昵称、性别、积分、年龄、门派等；实时用户信息部分中有如下内容选项：位置、游戏时间、积分、生命值、心情等。在图13中，呈现体用户选择了发布昵称、性别、门派等静态用户信息，游戏时间、生命值等实时用户信息，应用服务器只收集呈现体用户选择要发布的用户信息。

在步骤52中，应用服务器向呈现服务器请求认证账号和密码。

在步骤53中，呈现服务器对呈现账号和密码进行认证。

在步骤54中，呈现服务器向应用服务器通知认证结果。

在步骤55中，应用服务器对认证结果进行登记处理，并向呈现体用户显示登记成功或失败的结果。

在步骤56中，应用服务器经呈现服务器向呈现体客户端发送登记成功或失败消息通知，这是一个可选的步骤。

以上描述了在注册时呈现体用户向应用服务器登记呈现业务的过程。当呈现体用户在应用服务器上进行操作时，也可通过应用界面向应用服务器登记呈现业务，或修改呈现业务信息。

为了呈现体用户在应用服务器上进行操作时登记或修改呈现业务。应用服务器在应用客户端的界面(例如游戏客户端的主界面)中可提供呈现业务登记选项，以便当呈现体用户需要修改呈现业务特性时(这里的修改包括建立和撤销)，可随时在呈现业务登记项中修改相关项目，如图6所示，下面详细描述在应用界面上修改呈现业务的过程，此处采用不向应用服务器提供呈现业务密码的方式进行认证。

在步骤61中，呈现体用户所在终端上的应用客户端向应用服务器发出登记或修改呈现业务请求，所述登记或修改呈现业务请求中包括呈现账号。应用客户端与呈现体客户端可以在同一个终端上。

在步骤62中，应用服务器确定呈现账号归属的呈现服务器。因为呈现服务器可能会有多个，如不同运营商的网络中都会有各自的至少一个呈现服务器，应用服务器上可保存呈现账号与呈现服务器的对应关系，如呈现账号为手机号码时一般以号段对应呈现服务器地址，应用服务器根据手机号码所在的号段确定其归属的呈现服务器。另一种方法是在步骤61中，应用客户端在登记呈现业务时即向用户提供选择用户所属的呈现业务提供商名称，应用服务器上预先存储有呈现业务提供商与呈现服务器地址的对应关系，应用服务器根据用户给出呈现业务提供商名称确定相应的呈现服务器；当然也可以在应用服务器上预先存储呈现业务提供商与其Parlay/OSA(开放业务接入)网关的对应关系，应用服务器调用相应Parlay/OSA网关的呈现业务接口与呈现服务器通信，由Parlay/OSA网关根据呈现账号确定其归属的呈现服务器。如果网络中只有一个呈现服务器则就可以不需要本步骤了。

在步骤63中，应用服务器向呈现服务器发送呈现账号请求认证。

在步骤64中，呈现服务器向呈现账号对应的呈现客户端发送认证确认通知消息。

在步骤65中，呈现客户端将认证确认处理的结果返回给呈现服务器。

在步骤66中，呈现服务器再通知应用服务器。

在步骤67中，应用服务器根据认证结果对呈现业务进行修改或登记处理，若认证成功，则应用服务器根据呈现体用户的请求修改呈现业务的项目，否则拒绝修改。

在步骤68中，应用服务器向应用客户端返回修改呈现业务成功或失败的结果。

通常只在用户第一次在应用服务器登记呈现业务时才需要进行认证，在后续的设置授权列表和授权范围以及取消呈现业务可以不再进行认证。当然也可以对每次呈现业务的操作都进行认证以增强安全性，例如，呈现体用户修改授权内容，于是进入游戏客户端主界面的呈现业务登记项，并需要输入呈现账号(516870210)；当呈现服务器经呈现客户端对呈现账号(516870210)认证后，可将授权范围设置为如图14所示用户信息：昵称、性别、等级、门派、位置等。

在图4的步骤2中，应用服务器收集呈现体用户的用户信息，并将其发布至呈现服务器，作为呈现体用户的呈现信息的一部分。

为了收集呈现体用户的用户信息，应用服务器中设置有用户信息收集器，该用户信息收集器可访问和调用数据库和业务容器中的呈现体用户信息。具体的说，用户信息收集器根据呈现体用户在登记呈现业务时设置的授权范围在应用服务器中定时或实时收集呈现体用户的用户信息。所述的呈现体用户是指被请求观看呈现信息的这类用户，该呈现体用户可以为多个，即可同时定时或实时收集多个呈现体用户的用户信息。

下面以游戏服务器为例说明收集呈现体用户的用户信息的过程，游戏服务器中的数据库是游戏***可持续和稳定运行的关键部件，其存储有静态用户信息，如等级、积分等；而业务容器中不仅装载和运行游戏，且存储有实时用户信息，待用户退出游戏时，业务容器将最新用户信息更新到数据库中。并且，游戏服务器中设置有用户信息收集器，该用户信息收集器可与数据库和业务容器连接，用户信息收集器可根据设置的授权范围获取呈现体用户的用户信息。这里还分两种情况：

第一种情况，呈现体用户正在运行游戏。因为数据库中的某些信息并非实时的(用户退出游戏时更新)。这时用户信息收集器应该收集游戏业务容器中的呈现体用户的用户信息，如实时积分，实时等级，实时生命值等；当然，若不需要实时信息，仍可以仅收集数据库中相关用户信息。

第二种情况，呈现体用户未运行游戏。这时，用户信息收集器仅需收集数据库中的呈现体用户的用户信息即可。

接下来，应用服务器将收集到的呈现体用户的用户信息发布至呈现服务器，发布的形式可为两种：

第一种发布方式：主动式发布。应用服务器将收集到的呈现体用户的用户信息作为呈现信息的一部分主动地发送给呈现服务器，这时应用服务器还可采取定时或实时发布；在主动式发布情况下，当观察体客户端需要呈现体用户的用户信息时，直接由呈现服务器提供即可。这里，呈现体用户是指被请求观看呈现信息的用户，该呈现体用户可以为多个，即应用服务器可同时发布多个呈现体用户的用户信息。例如，流媒体服务器将收集到的多个呈现体用户(1，2，3....N)的用户信息如正在播放的流媒体信息同时批量发布至呈现服务器。为提高发布效率，可采取主动式发布。

第二种发布方式：请求式发布。只有接收到呈现服务器请求的情况下，应用服务器才将收集到的呈现体用户的用户信息为呈现信息的一部分发送给呈现服务器；在请求式发布方式下，当观察体客户端需要呈现体用户的用户信息时，需要经呈现服务器请求应用服务器提供。例如，观察呈现体用户通过呈现体客户端想请求获得呈现体用户在游戏服务器上的用户信息(如游戏名称，游戏室等)，经呈现服务器将该请求发送给游戏服务器，游戏服务器将呈现体用户的用户信息发送给呈现服务器，呈现服务器发送给观察体客户端。

在图4的步骤3中，呈现服务器将呈现体用户的用户信息发送给观察体客户端。

如图7所示本发明在网络游戏中的应用场景。在步骤71中，用户A在网络游戏服务器上登记呈现业务，即委托网络游戏服务器发布其用户信息；在步骤72中，用户A设置授权规则策略，允许用户B获取自己的呈现信息，包括网络游戏服务器发布的用户信息；在步骤73中，用户A登录网络游戏服务器，并开始玩游戏；在步骤74中，网络游戏服务器收集用户信息如用户A所在的游戏服务器和游戏室，在步骤75中，将所收集的用户信息发布到呈现服务器上；在步骤76中，呈现服务器将用户信息通知用户B；在步骤77中，用户B则可以登录网络游戏服务器，进入用户A所在的游戏室与其一起玩游戏。

下面举例说明呈现信息的更新变化过程。

如图8所示，起初，应用服务器，呈现服务器和观察体客户端(观察体)上的呈现体用户的用户信息为P1；当呈现体用户在应用服务器的用户信息从P1变为P2时，应用服务器向呈现服务器发送最新的用户信息P2，呈现服务器将呈现体用户的用户信息从P1改为P2，并将修改后的用户信息P2发送给观察体客户端；最后，应用服务器、呈现服务器、观察体客户端的呈现体用户的用户信息均变为P2。

例如，呈现体用户正在运行网络游戏服务器上游戏，其刚登录时的初始用户信息为P1；经过一段时间后，网络游戏服务器收集到呈现体用户的用户信息变成P2，于是网络游戏服务器将该用户信息P2发布给呈现服务器，呈现服务器再将用户信息P2发送给观察体客户端。图15示出了由用户信息P1变化为用户信息P2。

另外，为了确保应用服务器的用户信息的安全隐私，根据本发明，还可设定权限控制为观察体客户端提供呈现体用户的用户信息，下面描述授权机制，分为响应式授权和预设式授权。

授权机制例一，响应式授权，当观察体客户端通过呈现服务器向应用服务器请求订阅观看呈现体用户在应用服务器上的用户信息时，应用服务器检测当前用户是否已经登录或正在使用应用服务，如果是则向应用客户端发送确认通知，否则由呈现服务器向呈现体客户端发送确认通知；应用客户端经应用服务器向呈现服务器返回，或呈现体客户端直接向呈现服务器返回是否允许观察体客户端接收呈现体用户在应用服务器的用户信息。不仅如此，还可以通过设置对该观察体提供哪些内容的用户信息。例如，仅允许该观察体客户端获取积分，等级，昵称信息，而无法获知其他信息，具体的可以将设置的授权范围与关联观察体的URI用XML文件记录下来，XML文件存放在应用服务器和呈现服务器上或独立的XDM服务器上。应用服务器根据XML文件中设定的授权范围(可能是多个授权范围的并集)收集所需的用户信息，定时主动发布到呈现服务器，由呈现服务器根据XML文件中的订阅授权记录将用户信息推送到授权的观察体客户端。下面参照图9描述授权机制一的过程。

在步骤91中，观察体客户端向呈现服务器发送订阅请求。

在步骤92中，呈现服务器向应用服务器转发订阅请求，应用服务器判断被订阅的呈现体用户是否已经登录或正在使用应用服务，若是，则执行步骤93：应用服务器向应用客户端发送订阅确认通知，应用客户端向应用服务器返回确认结果消息，应用服务器再通知呈现服务器确认结果；否则，执行步骤94：应用服务器向呈现服务器返回呈现体用户当前没有登录及没有使用应用服务的通知，呈现服务器向呈现体客户端发送订阅确认通知，呈现体客户端向呈现服务器返回确认结果消息。

在步骤95中，呈现服务器根据确认结果生成或修改包含订阅授权记录的XML文件。包含订阅授权记录的XML文件可以同步传送到XDM服务器和应用服务器上。另外如果存在XDM服务器，则在步骤93和步骤94中应用客户端或呈现体客户端都可以直接将确认结果以XML配置访问协议XCAP(XMLConfiguration Access Protocol)发送到XDM服务器即可。

授权机制例二，预设式授权，呈现体客户端预先设立授权列表和授权范围，然后将该其通过XCAP协议发送到XDM服务器中，当观察体客户端向呈现服务器请求获取呈现体用户在应用服务器上的用户信息时，由呈现服务器向XDM服务器获取相应的XML文件内容，根据授权列表和授权范围决定是否允许向观察体客户端提供呈现体用户的用户信息以及提供哪些用户信息，然后再向应用服务器请求获取呈现体用户的用户信息。如图10所示，下描述授权机制二的过程。

在步骤101中，呈现体客户端设置授权列表和授权范围并将其发送给XDM服务器。

在步骤102中，观察体客户端向呈现体服务器发送获取呈现体用户的用户信息的请求。

在步骤103中，呈现服务器向XDM服务器查询判断是否允许观察体客户端的请求和/或请求范围，若是，则执行步骤104：呈现服务器向观察体客户端发送授权的用户信息；否则，执行步骤105：呈现服务器向观察体客户端发送拒绝信息。

接下来假设呈现体用户已经在应用服务器上登记了呈现业务，并在授权机制例一的基础上，以订阅体获取订阅的呈现体用户在应用服务器上的用户信息为例，并参照图11所示，说明其消息流程，如图11所示。

在步骤111中，观察体客户端(订阅体)向呈现服务器发送订阅请求，即请求订阅呈现体用户在应用服务器上的用户信息。订阅请求中可以包含过滤条件，即指定订阅的信息内容，以及哪些信息改变时发送信息更新通知。

在步骤112中，呈现服务器将订阅请求转送给呈现体客户端。此处以由呈现体客户端对订阅请求进行确认为例，当然也可以由应用客户端对订阅请求进行确认。

在步骤113中，呈现体客户端决定是否许可订阅及订阅范围，并生成授权或拒绝消息。

在步骤114中，呈现体客户端将授权或拒绝消息发给呈现服务器。

在步骤115中，呈现服务器将授权或拒绝消息转发给观察体客户端。

若拒绝订阅请求，如匿名请求，则呈现体客户端通过呈现服务器将拒绝信息转送给观察体客户端。另外，呈现体客户端拒绝某些订阅体还可采用礼貌封禁方式，即表面上接收订阅请求而不提供任何内容，避免了彼此的尴尬。呈现服务器向观察体客户端返回订阅成功的消息，但并不向其发送呈现体的用户信息，然后结束本过程。

若接受授权订阅请求，则在步骤116中应用服务器收集呈现体用户的用户信息。

在步骤117中，在授权订阅基础上，若用户信息发生变化，应用服务器将变化的用户信息发给呈现服务器。

在步骤118中，呈现服务器根据授权将用户信息转送至观察体客户端。

另外，呈现体客户端和观察体客户端也可取消订阅呈现信息，订阅取消一般需通知订阅体。

接下来我们假设呈现体用户已经在应用服务器上登记了呈现业务，并在授权机制例二的基础上，以查询体请求查询呈现体用户在应用服务器上的用户信息为例，并参照图12所示，说明其消息流程：

在步骤121中，呈现体客户端将授权列表和授权范围发送给XDM服务器。

在步骤122中，观察体客户端(查询体)向呈现服务器发送对呈现体的查询请求，即请求查询呈现体用户在应用服务器上的用户信息。

在步骤123中，呈现服务器根据XDM服务器上呈现体客户端提供的授权列表判断是否允许查询及查询范围。

若拒绝查询请求，如陌生人的请求，则执行步骤125：呈现服务器将拒绝信息转送给观察体客户端，然后结束本过程。

若授权查询请求，则执行步骤124：呈现服务器将查询请求转送给应用服务器。

在步骤126中，应用服务器收集呈现体用户的用户信息。

在步骤127中，应用服务器将用户信息发给呈现服务器。

在步骤128中，呈现服务器将收到的用户信息转送至观察体客户端。

为了方便查询，可允许观察体客户端不指定具体的呈现体，而是在向呈现服务器发送的查询请求中包括检索条件，如用户信息中的游戏名称为“围棋”，呈现服务器检索满足上述条件的呈现体用户在游戏服务器上的用户列表发送给观察体客户端，便于观察体客户端寻找满足条件的用户，以进一步查询指定呈现体在应用服务器上的用户信息。

值得注意的是，应用服务器在可以在发布呈现体用户的用户信息的同时，附带将应用服务器的信息如广告信息作为呈现信息的一部分发布出去，如应用服务器的网址等，如此可以扩展应用服务器供应商推广其应用服务的渠道，让更多的人获知该应用服务器的信息，进而吸引更多的客户。

根据本发明，观察体客户端可获得更丰富的呈现信息，从而可了解呈现体用户的更多信息以及使用应用服务的信息。

虽然通过实施例描绘了本发明，但本领域普通技术人员知道，在不脱离本发明的精神和实质的情况下，就可使本发明有许多变形和变化，本发明的范围由所附的权利要求来限定。

Claims (29)

1、一种呈现业务***，其特征在于，包括：

呈现服务器，用于接收、存储和分发呈现信息，呈现信息包括呈现体客户端发布的呈现信息和应用服务器发布的呈现信息；

呈现客户端，用于向所述呈现服务器发布呈现体的呈现信息，或者用于接收所述呈现服务器下发的呈现信息；

应用服务器，用于提供应用服务，并收集用户信息，将其作为用户的呈现信息发布到呈现服务器。

2、如权利要求1所述的***，其特征在于，所述应用服务器包括：

用户信息收集器，用于收集用户信息，将其作为用户的呈现信息发布到呈现服务器；

存储器，用于存储用户信息。

3、如权利要求2所述的***，其特征在于，所述应用服务器还包括业务容器，用于执行应用服务的业务逻辑，并存储用户与应用服务相关的实时用户信息；

用户信息收集器从存储器和业务容器中收集呈现体用户与应用服务相关的用户信息，将其作为用户的呈现信息发布到呈现服务器。

4、如权利要求2所述的***，其特征在于，所述应用服务器还包括过滤器，用于对向呈现服务器发布的呈现信息进行过滤。

5、如权利要求1所述的***，其特征在于，所述的应用服务器还包括压缩器，用于压缩发往呈现服务器的用户信息；

所述的呈现服务器还包括解压器，用于对收到的用户信息进行解压。

6、如权利要求1所述的***，其特征在于，在所述的应用服务器和所述的呈现服务器之间还包括一个开放业务接入网关，用于向应用服务器提供应用程序接口使其与呈现服务器进行通信。

7、如权利要求1所述的***，其特征在于，所述的***还包括可扩展标志语言文件管理服务器，用于存储授权规则文件，向应用服务器和呈现服务器提供呈现体用户的授权规则。

8、一种发布呈现信息的方法，其特征在于，包括：

A、呈现体用户在应用服务器上登记呈现业务；

B、应用服务器收集用户信息；

C、应用服务器将收集的信息作为用户的呈现信息发布到呈现服务器。

9、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤A具体包括：

A1、呈现体用户向应用服务器发送登记呈现请求；

A2、应用服务器将登记请求转发给呈现服务器；

A3、呈现服务器向呈现客户端发送确认消息并将呈现客户端返回的确认结果转发给应用服务器；

A4、应用服务器记录相应的登记结果。

10、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的登记呈现请求包括统一资源标识和呈现业务密码。

11、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤A还包括：在应用服务器上设置授权列表和授权范围，以便应用服务器根据授权列表和授权范围将用户信息发给呈现服务器。

12、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤A还包括：在应用服务器上设置过滤条件，以便应用服务器根据过滤条件将过滤后的用户信息发给呈现服务器。

13、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤A还包括：

进行响应式授权或预设式授权的步骤。

14、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤B具体包括：

B1、应用服务器将静态用户信息存放在存储器中；

B2、应用服务器将实时用户信息存放在业务容器中；

B3、用户信息收集器从存储器和业务容器中收集静态用户信息和实时用户信息。

15、根据权利要求14所述的发布呈现信息的方法，其特征在于，所述步骤B3中用户信息收集器根据预定的时间间隔定时从存储器和业务容器中收集用户信息。

16、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤B具体包括：应用服务器根据呈现体用户设置的授权范围收集用户信息。

17、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤B具体包括：应用服务器在呈现体用户登录后或正在使用应用服务时收集呈现体用户的用户信息。

18、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤C具体包括：应用服务器以主动发布方式或请求发布方式向呈现服务器发布用户信息。

19、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤C具体包括：应用服务器通过开放业务接入网关向呈现服务器发布用户信息。

20、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤C具体包括：应用服务器向呈现服务器批量发布用户信息。

21、根据权利要求8所述的发布呈现信息的方法，其特征在于，所述的步骤C具体包括：

C1、应用服务器向呈现服务器发布用户信息前先对所述的用户信息进行压缩；

C2、呈现服务器对收到的用户信息解压后再进行用户信息的更新处理。

22、一种获取呈现信息的方法，其特征在于，包括：

D、观察体客户端向呈现服务器发送获取呈现信息请求；

E、呈现服务器根据所述获取呈现信息请求通知应用服务器收集呈现体的用户信息，应用服务器将收集的用户信息作为呈现信息发布至呈现服务器；

F、呈现服务器将呈现体的用户信息发给观察体客户端。

23、根据权利要求22所述的获取呈现信息的方法，其特征在于，所述的步骤E还包括：应用服务器根据呈现体用户设置的授权规则收集用户信息，并将用户信息作为呈现信息发布至呈现服务器。

24、根据权利要求22所述的获取呈现信息的方法，其特征在于，所述的获取呈现信息请求包括过滤条件。

25、根据权利要求24所述的获取呈现信息的方法，其特征在于，所述的步骤E具体包括：应用服务器根据过滤条件收集呈现体的用户信息。

26、一种应用服务器，包括存储器，用于存储用户信息，其特征在于，还包括：

用户信息收集器，用于收集用户信息，并将收集的用户信息作为用户的呈现信息发布到呈现服务器。

27、根据权利要求26所述的应用服务器，其特征在于，还包括：

业务容器，用于执行应用服务的业务逻辑，并存储用户与应用服务相关的实时用户信息，用户信息收集器从存储器和业务容器中收集呈现体用户与应用服务相关的用户信息，将其作为用户的呈现信息发布到呈现服务器。

28、如权利要求26或27所述的应用服务器，其特征在于，还包括：

过滤器，用于对向呈现服务器发布的呈现信息进行过滤。

29、如权利要求26或27或28所述的应用服务器，其特征在于，还包括：

压缩器，用于压缩发往呈现服务器的用户信息。

Images