通信系统中的好友预订的存在体授权的制作方法

专利名称：通信系统中的好友预订的存在体授权的制作方法
技术领域：
本发明一般涉及通信系统、装置、软件和方法，并且更具体地说，涉及通信系统中用于授权用户接收与另一用户有关的信息的机制和技术。
背景技术：
在过去的数年内，日常通信中使用移动和陆线/有线线路计算装置的兴趣一直在增大。台式计算机、工作站和其它有线线路计算机当前允许用户例如经电子邮件、视频会议和即时消息传递(IM)进行通信。例如移动电话、手持式计算机、个人数字助理(PDA)等移动装置也允许用户经电子邮件、视频会议、頂等进行通信。移动电话一直以来通常用作话音通信装置，但通过技术进步，最近已证明它们是用于传递数据、图形等的有效装置。随着对跨不同平台的无缝通信的用户需求增大，无线和陆线技术继续合并成更统一的通信系统。
许多通信应用允许实现在与有线线路和无线电话通信相关联的传统话音通信范围之外的实时或近实时通信。聊天会话、即时消息传递、短消息服务(SMS)、视频会议是几个此类通信手段。许多这些类型的通信预期变得越来越通用，特别是由于无线装置和连续技术突破的激增。为实现此类技术，“存在”技术用于确定位置、通信的意愿及与实时或近实时通信有关的其它参数。存在技术一般指有利于定位和标识到此类通信链路的一个或多个端点的应用和服务。例如，如果无线手持式装置的第一用户打算启动与第二頂用户的頂会话，则存在服务可用于呈现第二用户的接收IM消息的意愿。存在服务是第三代(3G)无线网络的组成部分，并且打算跨多种不同的通信装置采用。可在存在服务器或相关联系统创建存在信息。存在信息可以是传达潜在用户与其它用户进行通信的能力和意愿的状况指示符。存在服务器可提供存在信息以分发到其它用户，以便传达用户进行通信的可用性。存在信息在许多通信服务中使用，如頂和基于IP的话音通信的最近实现。更具体地说，用户客户端可公布存在状态以指示其当前通信状况。此公布的状态向想联系用户的其它方通知其通信的可用性和意愿。存在的一种使用是在頂客户端上显示指示符图标，例如，带有易于传达的含意的图形符号的选择和每个状态的对应文本描述的列表。这类似于固定电话的“挂机”或“摘机”状态。关于用户可用性的常见状态是“自由聊天”、“忙”等。此类状态跨不同现代即时消息传递客户端以许多变化形式存在。然而，标准支持可用于存在信息的附加存在属性的丰富选择，如用户心情、位置或自由文本状况。存在服务一般实现为接受、存储和分发存在信息的网络服务。存在服务例如可实现为单个服务器，或者可具有涉及多个服务器和代理的内部结构。在保持到单个存在服务的逻辑连接性的同时，可存在重定向和代理的复杂模式。此外，存在服务可实现为在存在体与观看者之间的直接通信，即，不要求服务器。可在存在服务体系结构中实现多个实体。这些实体之一称为“存在体”，它是提供存在信息的实体。另一实体是存在服务器，它接收来自存在体的存在信息。“观看者”是对存在信息感兴趣的实体。可由存在服务器收集和利用存在信息(例如，位置、在某个时间或与某些用户进行通信的意愿等)，存在服务器可通知对某些存在信息感兴趣的经授权观看者。观看者应用可在有线线路和/或无线终端中实现以从存在服务器获得有关其它用户的存在信息。这可以由存在服务器发出到观看者的通知的形式出现。到用户/观看者的目标用户/装置已变得可用的通知可作为完整或部分存在信息发送。换而言之，有能够与存在信息的整体相关联的多个不同存在信息片段。以类似于存在信息和相关联结构的方式，有关于用户的位置信息和位置服务器。位置信息可包括地理位置信息。存在技术已在许多不同类型的网络中实现，包括为通信使用会话启动协议(SIP)的那些网络，如依照IP多媒体子系统(MS)标准操作的网络。在IETF RFC 3863中描述基本SIP存在XML PIDF文档，并且在IETF RFC 3856中定义基本SIP存在事件包。这些RFC 描述观看者能够如何使用SIP信令预订存在体的存在信息。一旦观看者已得到存在体的授权(例如，使用presence, watcherinfo事件包,如IETF RFC 3857中所述的),存在信息的更改便将经SIP通知观看者。通知包含附在PIDF XML文档中的存在信息。与存在体相关联的观看者列表被包括在观看者信息XML文档中。存在体预订其自己的观看者信息XML文档的presence, watcher info事件。此预订由存在系统自动授权。在新观看者向存在体请求预订时，它被添加到观看者信息文档的未决部分，并且将此更改通知存在体。存在体现在能够授权(即，允许或拒绝)新观看者。在OMA/IMS中，XCAP用于编辑存在授权文档。一旦授权完成，新观看者便取得查看最新存在信息(如果预订仍在活动状态，或者在发出新预订请求时)，即，如包括存在体的最新信息的存在通知被发送到观看者。今天因特网上的主导无线服务提供商(WSP)有社区和社交网络(例如，Facebook,MySpace, Yahoo、MSN及Google)。在这些因特网社区中已经建立存在，其中不同解决方案用于不同社区。许多因特网社区的一个重要方面是通过查找具有共同兴趣的人或者通过查找是您本身知道的人的朋友的人来扩展其自己的网络的能力。成功的社交网络提供几种方式来扩展您的网络和与新的人交互。扩展您的网络的此能力是此类社交网络的一个重要方面，并且在所谓的“病毒营销”中用于在朋友之间扩散营销消息，并且在人们添加新朋友时将消息扩散地更广。然而，必须小心处理人们的社交网络信息。人们想扩展其社交网络，但也想控制关于在其社交网络中散发的信息的隐私和安全性。因此，扩展社交网络的此能力也需要结合适当的安全性和隐私机制。在MS网络的上下文中考虑此社交网络功能性，MS为受管理的多媒体管理提供安全性和QoS能力。MS主要用于交换存在信息和在用户之间建立多媒体会话。另外，MS网络能够用于在网络服务器与用户之间建立会话。这使得頂S网络对因特网WSP是宝贵的，其中，MS经例如基于HTTP的接口(如RESTful或PARLAY-X)向WSP显露。MS存在技术能够如何用于支持WSP网站的两个示例包括(1)使得网站的用户能够查看其它用户的存在并提供在IMS.存在服务器中托管的存在引擎以推送内容到用户；以及(2)使得用户能够预订内容订源(content feed),并经存在机制将内容更新通知此类用户。
然而，MS (3GPP/0MA)指定系统内的存在使用是基于上述IETF RFC。因此，虽然在MS中可以有用于存在体的存在事件包的许多观看者，但一般情况下只有presence,watcherinfo事件包的一个观看者一即存在体本身。换而言之,根据标准,仅用户能够看到与他们相关联的其它用户的列表，即，仅用户能够看到其自己的经授权观看者的列表。这意味着没有为IMS定义会例如基于来自其它人的存在列表的信息，使得用户能够扩展其“好友”或“朋友”列表的机制。因此，在因特网网站上如此成功的社交网络和病毒效应在今天的IMS存在系统中不受支持。相应地，会希望提供用于基于存在的应用的避免上述问题和缺陷的装置、系统和方法。更具体地说，会希望提供在存在体中使能好友预订的机制，其中此类机制优选采用为用户提供他们所需求的充分安全性和隐私的授权技术。

发明内容
以下示范实施例提供相对于现有存在系统、装置和方法的多个优点和益处，例如包括使得用户能够通过利用其与存在体的现有关系使得能够向其它存在体介绍他们，来在例如IMS/存在系统中扩展其联系人的可能性。有利的是，此类介绍能够以多种不同方式控 制以考虑用户的隐私顾虑。其它优点包括根据一些示范实施例的现有存在机制的再使用以提供使能此类介绍的好友信息。然而，本领域技术人员将理解，权利要求书不限于产生任何或所有这些优点或益处的那些实施例，并且视特殊实现而定，其它优点和益处可得以实现。根据一示范实施例，用于获得与通信网络中的存在体的好友相关联的好友数据的方法包括以下步骤在服务器将与存在体相关联的多个用户关联的信息存储为好友数据，在服务器接收来自观看者的对存在体的好友数据的请求，至少部分由服务器授权对好支数据的请求，以及由服务器将好友信息传送到观看者。根据另一示范实施例，服务器管理对与连接到包括该服务器的通信网络的存在体有关的好友数据的访问，数据由连接到通信网络的观看者访问，服务器包括存储器装置，配置成将与存在体相关联的多个用户关联的信息存储为好友数据；处理器，连接到存储器装置，配置成接收来自观看者的对存在体的好友数据的请求，并且至少部分授权对好友数据的请求；以及接口，配置成将好友信息传送到观看者。


结合在说明书中并构成其一部分的附图示出一个或多个实施例，并与描述一起解释这些实施例。在图中
图I是包括用户装置和各种服务器的通信系统的示意 图2是描绘根据一示范实施例的用于传送好友数据到用户的方法的流程 图3示出根据一示范实施例的能够存储好友数据的数据结构；
图4是根据一示范实施例的包括用户装置和包括好友XDMS的各种服务器的通信系统的不意 图5是示出根据一示范实施例的从用户装置的角度的好友数据处理的流程 图6是根据一示范实施例的信令 图7是用户终端的示意图；以及图8是服务器的示意图。
具体实施例方式示范实施例的以下描述参照附图。不同图形中的相同参考标号标识相同或类似的单元。以下详细描述不限制本发明。而是，本发明的范围由随附权利要求书定义。为简明起见，关于在MS系统的上下文中论述的存在(presence)服务器的术语和结构论述以下实施例。然而，随后要论述的实施例并不限于这些系统，而是可应用到其它通信系统。说明书通篇对“一个实施例”或“一实施例”的引用意味着结合一实施例描述的特殊特征、结构或特性被包括在本发明的至少一个实施例中。因此，在说明书通篇各个位置出现的短语“在一个实施例中”或“在一实施例中”不一定全部指相同实施例。此外，特殊的特征、结构或特性可在一个或多个实施例中以任何适合的方式组合。为提供用于关于根据示范实施例的好友(buddy)机制的随后论述的某一上下文，最初论述系统的概述，系统包括存在体(presentity)、存在服务器和多个观看者，其中能够实现此类好友机制。如图I中所示，根据一示范实施例，使用存在数据的通用通信系统可 包括由存在体12和13表示的多个存在体1-n、存在服务器14、(可选)位置服务器16、存在XDMS服务器18和由观看者20和24表示的多个观看者l_n。存在服务器14、位置服务器16和XDMS服务器18可以是单个服务器22的一部分，或者可以实现为位于分开物理位置的分开服务器。存在服务器14、位置服务器16和存在XDMS服务器18可以相互直接通信，或者经如图I中所示的这些服务器之一进行通信。通信路径可以是有线线路或无线路径。存在体12、13和观看者20、24可与存在服务器14、位置服务器16和存在XDMS服务器18的每个服务器进行通信，或者可经单个端口(未示出)与单个服务器22进行通信。存在体12、13和观看者20、24与服务器的通信可以是有线线路或无线。例如由因特网任务工程组(IETF)和标准化规范来标准化“存在”的概念和相关联概念,通过引用结合于本文中的其完整内容可在http://www. ietf. org找到。使用存在的系统和方法能够在包括本文中所述网络的各种网络中找到，并且能够用于改进使用基于网络的地址簿的网络。可在存在服务器体系结构中实现多个实体。这些实体之一是存在体，它是提供存在信息的实体。另一实体是存在服务器，它接收来自存在体的存在信息。观看者是对存在信息(例如指示其它用户及其相应装置“在线”的信息和其它有关状况信息)感兴趣的实体。例如，可由存在服务器收集和利用位置、在某个时间或与某些用户进行通信的意愿、关于名片的信息等存在信息，存在服务器可通知对某些存在信息感兴趣的经授权“观看者”。观看者应用可在有线线路和/或无线终端中实现以从存在服务器获得有关其它用户的存在信息。这可以由存在服务器发出到观看者的通知的形式出现。存在实体可使用会话启动协议(SIP)作为存在协议，并且使用为SIP定义的通用事件通知框架，并且因此利用在存在规范中定义的SUBSCRIBE (预订)和NOTIFY (通知)方法。在存在系统中引入并且在RFC 3265中定义的事件包是基于存在代理器的概念，存在代理器是能够接受预订，存储预订状态和在有存在更改时生成通知的逻辑实体。该实体定义为逻辑实体，这是因为它可与另一实体共同驻留(co-resident)。存在用户代理器(PUA)操控用于存在体的存在信息。此操控能够是(如使用可扩展标记语言(XML)配置访问协议(XCAP) PUT消息来添加新联系人的)某一其它动作的副作用，或者能够通过例如使用SIP PUBLISH (公布)等存在文档的公布明确执行。用户可具有许多装置，如蜂窝电话和个人数字助理(PDA)，它们每个可独立生成用于存在体的总体存在信息的组件。PUA将数据推送入存在系统中，但在其之外，因为它们不接收SUBSCRIBE消息或发送NOTIFY消息。存在代理器(PA)是SIP用户代理器，它能够接收SUBSCRIBE请求，响应它们，以及生成存在状态更改的通知。存在代理器可知道存在体的存在状态。这意味着它具有对用于存在体的PUA操控的存在数据的访问权。PA也是支持存在事件包的通知方(如在RFC 3265中所定义的一样)。存在服务器是可充当存在代理器或用于SUBSCRIBE请求的代理服务器的物理实体。在充当PA时，它通过一些协议部件知晓存在体的存在信息。在充当代理时，SUBSCRIBE请求通过代理发送(proxied)到可充当PA的另一实体。在一实体(订户)想了解来自另一用户的存在信息时，它创建SUBSCRIBE请求。SUBSCRIBE请求像其它SIP请求一样沿SIP代理承载。在大多数情况下，它最终到达存在服务器，存在服务器可以生成请求的响应(在此 情况下，它充当用于存在体的存在代理器)，或者将它代理发送到(proxy it to)边缘存在服务器。如果边缘存在服务器处理预订，则它在充当用于存在体的存在代理器。无论是在存在服务器中还是在边缘存在服务器中的存在代理器，先鉴定预订，然后对它进行授权。如果授权，则返回OK响应。如果此次不能获得授权，则将预订视为“未决”，并且返回另一响应。在两种情况下，PA发送包含存在体和预订的状态的即刻NOTIFY消息。在存在体的状态更改时，PA生成到带有已授权预订的所有订户的包含那些状态更改的NOTIFY。预订本身状态的更改也能够触发NOTIFY请求，该状态在NOTIFY消息的预订状态报头字段中承载，并且一般会指示预订是活动的还是未决的。在许多通信应用(如基于IP的话音、即时消息传递和存在)中，网络服务器可在服务于请求的过程中访问每用户信息。此每用户信息可驻留在网络内，但可由最终用户自身管理，并且其管理能够通过包括万维网、无线手机或PC应用的多个访问点来执行。每用户信息有许多示例。一个示例是存在授权策略，它定义有关允许哪些观看者预订存在体以及允许他们访问什么信息的规则。另一示例是存在列表，存在列表是观看者希望得到其存在的用户列表。获得用于列表的存在信息的一种方式是预订表示该列表的资源。在此情况下，资源列表服务器(RLS)要求访问此列表以便处理对其的SIP SUBSCRIBE请求。获得用于列表上的用户的存在的另一种方式是让观看者单独向每个用户预订。在该情况下，让服务器存储列表是方便的，并且在客户端自举时，它从服务器获取列表。这会允许用户从不同客户端访问其资源列表。可用于操控此每用户数据的一种协议是XCAP。XCAP是一组用于将XML文档和文档组件映射到超文本传输协议(HTTP)统一资源标识符(URI)的惯例、一个资源的修改如何影响另一个资源的规则、数据验证约束及与访问那些资源相关联的授权策略。使用此结构，普通的HTTP原语可用于操控数据。利用XCAP的每个应用(应用指暗示数据和相关联语义集合的用例)指定一种应用用法。此应用用法为由应用使用的数据及其它信息片段定义XML模式。XCAP的一个任务是允许客户端读取，写入，修改，创建和删除该数据的片段。XCAP服务器充当用于XML文档集合的存储库。可以有为每个应用存储的文档。在每个应用内，有为每个用户存储的文档。每个用户可具有用于特殊应用的多个文档。为访问那些文档之一的某一组件，XCAP定义用于构建可用于引用该组件的URI的算法。组件指文档内的任何元素或属性。因此，由XCAP使用的HTTP URI指向文档，或比XML文档本身更细粒度的信息片段。遵循此处定义的命名惯例和验证约束的HTTP资源称为XCAP资源。由于XCAP资源也是HTTP资源，因此，能够使用HTTP方法访问它们。通过HTTP GET完成读取XCAP资源，通过HTTP PUT进行创建或修改一个XCAP资源，以及通过HTTP DELETE进行删除资源之一。借助于能够在支持和/或结合本文中所述示范实施例中使用的此存在背景，现在在下面描述根据示范实施例的好友机制的示例。根据一示范实施例，提供了使得例如观看者20能够请求访问它已经预订的存在体12的好友数据和允许存在体12授权观看者20具有对此好友数据(或其某一部分)的访问权的机制。根据此好友数据，用户然后能够联系其它用户，例如，以扩展他或她的联系人列表。IMS系统中用于将与存在体(一个用户)相关联的好友信息发送到观看者(另一用户)的通用方法在图2的流程图中示出，在此示例中，从存在体12和/或存在服务器22的 角度示出。也就是说，图2中所示的所有步骤能够由存在体12执行，所有步骤能够由存在服务器22执行，或者一个或多个步骤能够由每个执行。其中，在步骤200，建立/存储与存在体12相关联的用户(好友)列表，例如，包括观看者I. . . N的子集(或可能是完全集)。根据示范实施例，观看者20能够，例如，如步骤210所示通过发送请求好友信息的SIP消息到存在体12，预订此好友列表(或此好友列表的部分)以获得有关与存在体12相关联的用户的信息。然而，如在步骤220中所示，存在体12将先执行授权过程以确定是否授予请求(预订)用户对此好友信息的访问权。如果观看者12被授予访问一些或所有好友信息的授权，则存在体12将发送经授权的好友信息到预订用户。一旦已授权，便能够在预订基础上更新好友信息，例如，以类似于提供存在信息到预订用户所依据的方式。随后，此好友信息能够由预订用户用于例如扩展他或她的与IMS系统相关联的联系人列表。现在将更详细地描述图2中所示的每个步骤。根据示范实施例，从步骤200开始，存在体12将在例如列表或数据库等适合的数据结构中存储其好友信息，使得它能够使此类好友信息可用于经授权订户。好友信息例如能够存储在与存在体12相关联的存储器装置中，并且能够包括图3中所示的示范好友列表300中示出的一个或多个数据元素。下面相对于图7和8描述示范存储器装置。其中，数据结构(好友列表)300包括与列表中的每个好友相关联的一个或多个数据元素。例如，每个好友能够在好友列表中由以下一项或多项表示显示名称、可寻址名称和公共/私有指示符。根据一个示范实施例，在用户请求来自存在体12的好友信息，并且被授权接收此类数据时，存在体12可仅向该用户发送与其好友之一相关联的显示名称。显示名称如下所述可用于经存在体12请求与该好友进行联系，但不可由请求观看者用于直接联系好友。备选地，好友列表能够包括与列表300中的每个好友相关联的可寻址名称。可寻址名称能够由请求了好友信息的观看者用于直接联系好友，例如，询问该用户是否可添加他或她到观看者的存在列表，而不必通过存在体12进行介绍。好友列表300也可包括与列表中的每个好友相关联的公共/私有指示符。此指示符能够由好友及存在体12用于选择性地滤除不愿响应来自观看者20、24对好友信息的请求而共享其名称的一些好友。如果在好友列表300中使用，则好友信息的成功请求者会只接收列表中已标记为“公共”的那些用户的显示名称或可寻址名称。除为在好友列表中的每个用户存储的信息的类型和量外，根据示范实施例，选择在存在体12的好友列表中存储哪些用户的方式也可有所不同。根据示范实施例，有能够用作好友列表300的多个可能列表，并且这些列表通常能够编组成两个类别一静态列表和动态列表。在XDMS服务器18中保持有三种静态列表，它们分别描述1)存在体已授予观看它们的存在的许可的所有用户，2)存在体已阻止观看它们的存在的所有用户，以及3)所有已知用户(即，列表1+列表2)。存在服务器22中也保持有关于当前谁预订观看存在体12的动态列表。这些动态列表一般将保持静态列表上的用户的子集，其列出被允许观看的所有那些用户(即，被允许接收存在信息的用户)。例如，一个动态列表能够包括在线的那些活动观看者，即不包括被允许观看但当前不在观看的那些用户。当前在观看的那些用户的动态列表是观看者信息列表。根据各种示范实施例，这些列表中的任何一个用户或任何其它用户列表能够用作好友列表300。 在存储了好友列表信息并且使其可供使用(步骤200)后，存在体12和/或存在服务器22能够在步骤210例如从其已经预订的观看者20，24之一接收预订存在体12的好友信息的请求。如下面将相对于图4更详细所述，这例如能够由存在体12 (和/或存在服务器22)接收已由观看者20、24传送的请求好友信息的SIP消息(步骤210)来完成。在步骤20，存在体12和/或存在服务器22处理接收的好友信息请求以确定请求者是否被授权接收此类信息。根据示范实施例，这能够以多种不同方式来完成。例如，存在服务器22可先从观看者20、24接收请求，并且应用策略到请求。用于在存在服务器22授权好友列表彳目息请求的不范策略是确定请求观看者20、24是否是存在体12的好友(例如，列在存在XDMS 18中用于存在体12的允许列表上)。备选地，如果存在服务器22确定请求观看者20、24是其好友信息受到观看者20、24请求的存在体12的好友，则存在服务器22能够授权释放该存在体12的公共好友信息。也考虑了各种其它授权机制。例如，如果存在服务器22检测到在请求好友信息的观看者20、24不在观看者20、24请求其好友信息的存在体12的允许列表(或类似地在其阻止列表)中，则存在服务器22能够将对好友信息的请求作为存在预订请求对待。也就是说，在这些情况下，存在服务器22能够发送观看者信息通知到其好友信息受到请求的存在体12，以确定是否能够先证明请求的观看者20、24适合接收存在信息。在此示范实施例中，存在体12得到新预订请求的通知，即，因为存在体12的更改已被预订。假设为了此示例，存在体12决定接受观看者20、24成为其存在信息的订户的请求。在此情况下，存在体12编辑存在授权规则以同意请求，并且观看者20、24接收预订相关联用户列表的成功响应。根据另一示范实施例，存在服务器检测到观看者20、24在请求好友信息(而不是存在信息)，并且表现得好象此观看者20、24不在存在体12的允许列表中一样，并且因此发送观看者信息通知到存在体12，这是因为通常存在体12的更改已被预订，以及因此存在体12编辑存在授权规则以同意/拒绝请求。存在授权规则现在捕捉能够观看用于存在体12的存在信息的用户与能够观看存在体12的好友信息的用户之间的区别。从上面所述中将理解，至少一些示范实施例将导致接收来自存在体的数据的不同级别的授权，即，一些观看者20、24可被授权只接收存在信息，其它观看者20、24可被授权只接收好友信息，和/或一些观看者20、24可被授权接收与特殊存在体12相关联的两种类型的信息。因此，对于此类示范实施例，存在授权规则将捕捉例如在能够观看用于存在体12的存在数据的用户与能够观看存在体12的好友列表的用户之间的这些区别。对于其它示范实施例，这些不同的级别能够减少为一，例如，其中所有经授权观看者能够接收存在信息和好友息两者。虽然在前面的示范实施例中使用现有存在授权机制的修改版本和存在授权文档执行授权步骤220，但另一解决方案会是添加与存在解决方案分开但类似的新授权机制，例如，如图4中所示引入好友授权XDMS 400，其中，剩下的单元如上相对于图I所述般被编号并且操作。根据此示范实施例，观看者信息预订授权和存在授权机制能够再使用相同基本功能性，但使用不同的授权文档，即，使用存在授权文档和好友列表授权文档两者。根据一示范实施例的用于执行授权步骤220仍有的另一备选是让存在体12预订观看者信息的观看者信息，在此情况下，观看者20、24对观看者信息的预订会导致到该预订内的存在体12的通知。要在此示范实施例上进行扩展，考虑一般情况下用户A预订其自己的观看者信息，并且在用户B向用户A预订存在时，则用户A经观看者信息得知更改。然而，根据此示范实 施例，还希望用户B预订A的观看者信息，并且因此需要通知用户A的附加机制。一种用于提供此机制的选项是过载presence, winfo事件。在此类情况下，存在服务器配置成确定特殊SUBSCRIBE信号是来自用户B，并且然后它将通知用户A。根据一示范实施例的用于提供此机制的另一选择更明确地分开这些功能。在此第二种情况中，用户A预订观看者信息(即，以获得存在预订的通知)，并且用户A也预订新事件presence, winfowinfo (即，以获得好友信息预订的通知)。一旦授权完成，并且假设请求的观看者20、24被授权接收好友信息，则如步骤230所指示，该信息被输送到观看者20、24。如更早所提及的一样，输送到观看者20、24的实际好友信息能够因实现不同而变化或者甚至在提供不同级别的访问时基于观看者的访问级别在单个实现内变化。例如，输送的好友信息能够包括有关在存在体12的好友列表上的所有观看者的完全信息、完全信息但只对于允许分发其好友信息的那些观看者、完全信息但只是对于当前预订的观看者，或用于上面提及的观看者的任何群组的好友列表信息的子集，例如，信息的公共部分。根据示范实施例，并且也如上所述，此后一机制能够涉及使用新XML文档格式，该格式只提供观看者信息的公共元素，并且只给出用户显示名称而不是完全用户id。另外，只提供好友列表信息的公共部分能够实现为可配置机制，并且不要求新的用户管理机制。除从存在体12 (和/或存在服务器22)的角度考虑好友机制外，如图5的流程图中概括所示，其它示范实施例也从观看者20、24的角度考虑好友信息。其中，在步骤500，观看者20、24发送对好友信息的请求，并且随后在步骤510接收响应，例如，好友列表。在接收好友信息后，观看者20、24然后在步骤520决定使用好友信息联系存在体12的好友之一，例如，存在体13，例如以便观看者20、24扩展其朋友群组。根据示范实施例步骤520能够至少部分取决于在好友列表中接收的信息以多种不同方式执行。例如，假设观看者20决定它愿意与来自响应好友列表请求而接收的存在体12的好友列表的元素之一进行通信。目标用户被标识为存在体13，然而，观看者20只具有(它在步骤510中接收的)存在体13的显示名称，并且因此不能直接预订存在体13的存在信息。相应地，观看者20发送请求到存在体12，要求存在体12应请求存在体13允许观看者20预订其存在信息。存在体13能够同意或拒绝此请求，或者如果观看者20是存在体12的好友，则请求能够被自动授予。根据一个示范实施例，联系存在体12的好友的此功能性能够实现为从观看者20到存在体12的指示预订是专门针对存在体的预订请求。存在服务器22然后将请求中继到存在体13，指示例如请求是观看者20启动并由存在体12中继的第三方预订。根据另一示范实施例，能够使用REFER机制，其中，REFER消息由于观看者20的预订请求原因而发送到存在体13。作为仍有的另一备选，存在体12可向观看者20指示他或她允许预订(联系存在体13)，并且存在体13的完全id被返回到观看者20。观看者20然后能够使用存在体13的完全身份发送普通预订消息，并且存在体13能够同意或拒绝此预订。如上所述，一些示范实施例涉及例如在MS系统中的SIP信号的传送或接收，其有 利于对好友信息的请求、好友信息的授权和输送。相应地，现在将相对于图6描述根据一不范实施例的详细(但仍纯说明性)的信号图。其中，观看者20已经被授权观看存在体12，SP，接收有关存在体12的存在信息。观看者20现在想获得对存在体12的好友数据的访问权。图6的信令序列根据一个示范实施例示出观看者20如何从存在体12请求许可以具有对存在体12的好友数据的访问权，以及然后该观看者20如何随后请求预订存在体13 (存在体12的好友之一)的存在数据的许可。在此示例中，通过再使用通常用于供应存在信息的观看者信息列表，并应用新授权策略到该列表以确定获得好友信息的授权，来执行好友信息请求的授权。然而，其它授权机制是可能的并且考虑在内，其中的一些在上面已描述。从信号600开始，观看者200通过传送信号600到存在服务器22，来预订存在体12的好友数据。在此实施例中，信号600例示为SIP SUBSCRIBE (预订存在体12的观看者信息)信号，但其它类型的信号能够备选地用于请求好友信息。存在服务器22和XDMS 18或400例如，以上述方式之一，应用策略，如信令602所指示，并且决定经SIP NOTIFY信号604将请求继续传递到存在体12以便获得授权。在经到存在服务器22的SIP 200 OK消息606确认请求的接收后，存在体12编辑与存在/好友授权相关联的XDMS文档，以赋予其对观看者20接收好友信息的授权，并且通知XDMS 18或400，如XCAP信令608所示。存在服务器14收到通知，其然后经SIP 200 OK信号612确认原SIP SUBSCRIBE信号600，以及然后经信号614将好友信息通知观看者20。在此示例中，仅存在体12的好友信息的公共部分发送到观看者20，如上所述，公共部分包括有关存在体12的好友的基本信息，其中的一个条目是用于存在体13。假设在此示范情形中，观看者20想从存在体13获得存在信息。根据此示例，观看者20需要经存在体12的指引进行此操作，但如上所述，能够备选地使用其它机制。因此，观看者20经信号618请求存在体12经存在服务器指引他到存在体13，并请求观看者20能够预订存在体13的存在数据。在应用策略以确定观看者20是否被授权(信号620)后，存在体12经信号622将请求继续传递到存在体13，存在体13经信号624授权请求。与例如在信号614中作为所有或部分公共信息提供到观看者20的显示名称相反，到观看者20的响应信号626包括存在体13的完全身份。
观看者20然后经信号628预订存在体13的存在数据。在经信令630应用策略以确定此请求是否被授权后，存在服务器14然后经信号632将请求通知存在体13，经信号634确认该信号。存在体13借助于朝向XDMS 18或400的信令636编辑其XDMS文档，以赋予其对观看者的请求的授权，并且指示其对接收来自存在体13的存在信息的授权的响应信号然后经信号638和640发送到观看者20。可充当如结合示范实施例所述的存在体和/或观看者的终端可以是台式/个人计算机、工作站、大规模计算终端、无线终端或能够运行存在感知应用的任何其它计算装置。无线终端可包括诸如无线/蜂窝电话、个人数字助理(PDA)或其它无线手机及便携式计算装置的装置。移动终端可利用计算组件控制和管理常规装置活动以及示范实施例提供的功能性。硬件、固件、软件或其组合可用于执行本文档中所述的各种方法和技术。为了说明而不是限制，图7中示出如存在体或观看者等能够执行根据示范实施例的操作的代表性移动终端计算系统的一个示例。然而，应认识到的是，所述示范实施例的原理同样适用于标准计算系统。示范移动计算装置700可包括诸如微处理器、精简指令集计算机(RISC)或其它中 央处理模块等处理/控制单元702。处理单元702无需是单个装置，并且可包括一个或多个处理器。例如，处理单元702可包括主处理器和耦合成与主处理器通信的相关联从处理器。处理单元702可如存储装置/存储器704中可用的程序命令，控制移动终端的基本功能。因此，处理单元702可运行图2、3、5和6中所述的功能。更具体地说，存储装置/存储器704可包括用于执行移动终端上的功能和应用的操作系统和程序模块。例如，程序存储装置可包括以下各项中的一个或多个只读存储器(ROM)、闪存ROM、可编程和/或可擦除ROM、随机存取存储器(RAM)、订户接口模块(SIM)、无线接口模块(WIM)、智能卡或其它可装卸存储器装置等。程序模块和相关联特征也可经数据信号传送到移动计算装置700，如以电子方式经诸如因特网等网络下载。可在存储装置/存储器704中存储的程序之一是特定程序706。如前面所述，特定程序706可与好友服务器和/或存在服务器交互以获取和/或预订一个或多个存在体的存在信息和/或好友信息。特定程序706和相关联特征可以用通过处理器702可操作的软件和/或固件来实现。程序存储装置/存储器704也可用于存储数据708，如各种鉴定规则或与所述示范实施例相关联的其它数据。在一个示范实施例中，程序706和数据708存储在非易失性电可擦除可编程ROM (EEPROM)、闪存ROM等中，使得在移动终端700的电源关闭时
息不会丢失。处理器702也可耦合到与移动终端相关联的用户接口 710单元。移动终端的用户接口 710可例如包括诸如液晶显示器等显示器712、小键盘514、扬声器716及麦克风718。正如本领域所熟知的一样，这些和其它用户接口组件耦合到处理器702。小键盘714可包括用于执行包括拨号和运行指配到一个或多个键的操作等多种功能的字母数字键。备选地，可采用其它用户接口机制，如话音命令、开关、触摸垫/屏、使用定点装置的图形用户接口、轨迹球、操纵杆或任何其它用户接口机制。移动计算装置700还可包括数字信号处理器(DSP) 720。DSP 720可执行多种功能，包括模数(A/D)转换、数模(D/A)转换、语音编码/解码、加密/解密、检错和纠错、比特流转化、滤波等。一般耦合到天线724的收发器722可传送和接收与无线装置相关联的无线电信号。图7的移动计算布置700提供为可应用所述示范实施例的原理的计算环境的代表性示例。从本文提供的说明中，本领域技术人员将理解，本发明在多种其它当前已知和将来的移动和固定计算环境中同样适用。例如，特定应用706和相关联特征及数据708可以多种方式存储，可在多种处理装置上操作，并且可在具有附加、更少或不同支持电路和用户接口机制的移动装置中操作。要注意的是，所述示范实施例的原理同样适用于非移动终端，即陆线计算系统。存在服务器、存在和/或好友XDMS服务器或用于结合所述示范实施例提供存在和位置信息的其它系统可以是能够处理和传递存在信息的任何类型的计算装置。图8中示出了能够执行根据示范实施例的服务器的操作的代表性计算系统的示例。硬件、固件、软件或其组合可用于执行本文所述的各种步骤和操作。图8的计算结构800是可结合此类系统使用的一个示范计算结构。
适用于执行在示范实施例中所述活动的示范计算装置800可包括存在服务器或好友服务器或存在和/或好友XDMS服务器601。此类服务器801可包括耦合到随机存取存储器(RAM) 804和只读存储器(ROM) 806的中央处理器(CPU) 802。ROM 806也可以存储程序的其它类型的存储媒体，如可编程ROM (PROM)、可擦除PROM (EPROM)等。处理器802可通过输入/输出(I/O)电路808和总线810与其它内部和外部组件进行通信以提供控制信号及诸如此类。如软件和/或软硬件指令命令的一样，处理器802执行如技术领域熟知的多种功能。服务器801也可包括一个或多个数据存储装置，包括硬和软盘驱动器812、⑶-ROM驱动器814及能够读取和/或存储信息的其它硬件，如DVD等。在一个实施例中，用于执行上述步骤的软件可在CD-ROM 816、软盘818或能够以便携方式存储信息的其它形式的媒体上存储和分发。这些存储媒体可插入诸如⑶-ROM驱动器814、盘驱动器812等装置中并由其读取。服务器801可耦合到显示器820，其可以是任何类型的已知显示器或呈现屏幕，如IXD显示器、等离子显示器、阴极射线管(CRT)等。提供了用户输入接口 822，包括诸如鼠标、键盘、麦克风、触摸垫、触摸屏、话音识别系统等一个或多个用户接口机制。服务器801可经网络耦合到其它计算装置，如陆线和/或无线终端及相关联观看者应用。服务器可以是如诸如因特网828等全球区域网(GAN)中的更大网络配置的一部分，其允许最终连接到各种陆线和/或移动客户端/观看者装置。公开的示范实施例例如提供用于获得IMS系统中的某个用户或存在体的好友数据的用户终端、系统、方法和计算机程序产品。应理解，此描述不打算限制本发明。相反，示范实施例打算涵盖在如随附权利要求书定义的本发明的精神和范围中包括的备选、修改和等效。此外，在示范实施例的详细描述中，陈述了许多特定的细节以便提供对要求保护的发明的详尽理解。然而，本领域的技术人员会理解，在无此类特定细节的情况下可实践各种实施例。例如，虽然前面的示范实施例描述单组鉴定规则(例如，用于为用户生成好友数据和存在数据两者的鉴定特权的规则)能够根据一个示范实施例存储在存在数据管理服务器上，但将理解的是，存储单组规则的服务器的特殊名称和/或位置能够变化。例如，此服务器也能够称为“存在和好友授权规则服务器”。服务器无论其名称如何，能够专用于此类规则集的存储，或备选地也能够用于存储其它(例如，类似)数据。在后一情况中，服务器然后例如能够称为“基于内容的授权规则服务器”。为了此说明书的目的，术语“存在和好友授权规则服务器”将对可用于存储本文中所述规则集的所有此类服务器是通用的。虽然以特殊组合在实施例中描述所示示范实施例的特征和元素，但每个特征或元素能够单独使用而无实施例的其它特征和元素，或者以带有或无本文中公开的其它特征和 元素的各种组合来使用。本申请中提供的方法或流程图可用计算机可读存储介质中有形包含的计算机程序、软件或固件来实现以便由通用计算机或处理器运行。
权利要求
1.一种用于获得与通信网络中的存在体的好友相关联的好友数据的方法，所述方法包括 在服务器将与所述存在体相关联的多个用户关联的信息存储为所述好友数据； 在所述服务器接收来自观看者的对所述存在体的好友数据的请求； 至少部分由所述服务器授权对好友数据的所述请求；以及 由所述服务器传送所述好友信息到所述观看者。
2.如权利要求I所述的方法，其中在所述观看者请求所述好友数据时，所述观看者已经被授权接收与所述存在体相关联的存在信息。
3.如权利要求I所述的方法，其中所述好友数据包括标识另一存在体的信息，但所述信息不可用于直接联系所述另一存在体。
4.如权利要求3所述的方法，还包括 在所述服务器接收来自所述观看者的预订与所述另一存在体相关联的存在信息的请求；以及 由所述服务器将所述请求作为从所述存在体中继的消息转发到所述另一存在体。
5.如权利要求I所述的方法，其中所述好友数据包括标识另一存在体的信息，并且所述信息可用于直接联系所述另一存在体。
6.如权利要求5所述的方法，还包括 在所述服务器接收来自所述观看者的预订与所述另一存在体相关联的存在信息的请求；以及 由所述服务器将所述请求转发到所述另一存在体。
7.如权利要求I所述的方法，其中在所述服务器存储所述好友数据的所述步骤还包括 将用于每个所述用户的多个数据元素存储为所述好友数据，其中至少所述数据元素之一被指示为公共数据元素，并且至少所述数据元素之一被指示为私有数据元素。
8.如权利要求7所述的方法，其中传送所述好友数据的所述步骤还包括 只传送所述好友数据中被指示为公共数据元素的数据元素。
9.如权利要求I所述的方法，其中与多个用户相关联的所述存储信息是以下之一 与所述存在体相关联的当前预订存在用户的第一列表、允许用户的第二列表及与所述第一和第二列表不同的第三列表。
10.如权利要求I所述的方法，其中至少部分由所述服务器授权对好友信息的所述请求的所述步骤还包括 由所述服务器确定所述观看者是否是与所述存在体相关联的存在XDMS中的允许用户列表的一部分； 如果是，则发送请求到所述存在体，所述请求要求所述存在体授权所述好友数据的传送；以及 如果不是，则拒绝所述观看者获得所述好友数据的请求。
11.如权利要求I所述的方法，其中至少部分由所述服务器授权对好友信息的所述请求的所述步骤还包括 自动授权在所述好友数据中标识的观看者接收所述好友数据的公共元素。
12.如权利要求I所述的方法，其中授权的所述步骤使用存在XDMS服务器来授权对好友数据的所述请求。
13.如权利要求I所述的方法，其中授权的所述步骤使用与存在体XDMS服务器不同的好友XDMS服务器来授权对好友数据的所述请求。
14.一种服务器，管理对与连接到包括所述服务器的通信网络的存在体有关的好友数据的访问，所述数据由连接到所述通信网络的观看者访问，所述服务器包括 存储器装置，配置成将与所述存在体相关联的多个用户关联的信息存储为所述好友数据； 处理器，连接到所述存储器装置，配置成接收来自所述观看者的对所述存在体的好友数据的请求，并且至少部分授权对好友数据的所述请求；以及 接口，配置成将所述好友信息传送到所述观看者。
15.如权利要求14所述的服务器，其中在所述观看者请求所述好友数据时，所述观看者已经被授权接收与所述存在体相关联的存在信息。
16.如权利要求14所述的服务器，其中所述好友数据包括标识另一存在体的信息，但所述信息不可用于直接联系所述另一存在体。
17.如权利要求16所述的服务器，其中接口还配置成接收来自所述观看者的预订与所述另一存在体相关联的存在信息的请求，以及其中所述处理器还配置成将所述请求作为从所述存在体中继的消息转发到所述另一存在体。
18.如权利要求14所述的服务器，其中所述好友数据包括标识另一存在体的信息，并且所述信息可用于直接联系所述另一存在体。
19.如权利要求18所述的服务器，其中所述接口还配置成接收来自所述观看者的预订与所述另一存在体相关联的存在信息的请求，以及其中所述处理器还配置成将所述请求转发到所述另一存在体。
20.如权利要求14所述的服务器，其中所述存储器装置还配置成将用于每个所述用户的多个数据元素存储为所述好友数据，其中至少所述数据元素之一被指示为公共数据元素，并且至少所述数据元素之一被指示为私有数据元素。
21.如权利要求20所述的服务器，其中所述处理器和所述接口还配置成只传送所述好友数据中被指示为公共数据元素的数据元素。
22.如权利要求14所述的服务器，其中与多个用户相关联的所述存储信息是以下之一与所述存在体相关联的当前预订存在用户的第一列表、允许用户的第二列表及与所述第一和第二列表不同的第三列表。
23.如权利要求14所述的服务器，其中所述处理器还配置成通过以下操作来授权对好友信息的所述请求确定所述观看者是否为与所述存在体相关联的存在XDMS中的允许用户列表的一部分，并且如果是，则发送请求到所述存在体，所述请求要求所述存在体授权所述好友数据的传送，并且如果不是，则拒绝所述观看者获得所述好友数据的请求。
24.如权利要求14所述的服务器，其中所述处理器还配置成通过自动授权在所述好友数据中标识的观看者接收所述好友数据的公共元素，来授权对好友信息的所述请求。
25.如权利要求14所述的服务器，还包括配置成授权对好友数据的所述请求的存在XDMS服务器。
26.如权利要求14所述的服务器，还包括用于授权对好友数据的请求的好友XDMS服务器和用于授权对存在信息的请求的存在XDMS服务器。
全文摘要
用于访问与连接到包括服务器的通信网络的第一用户(存在体)有关的好友数据的服务器、计算机可读介质和方法，数据由连接到通信网络的第二用户(观看者)访问。方法包括在服务器将与存在体相关联的多个用户关联的信息存储为好友数据，在服务器接收来自观看者的对存在体的好友数据的请求，至少部分由服务器授权对好支数据的请求，以及由服务器将好友信息传送到观看者。
文档编号H04L12/58GK102783117SQ201080065124
公开日2012年11月14日 申请日期2010年3月3日 优先权日2010年3月3日
发明者C.博贝格, H.普齐比茨, J.鲍德温 申请人:瑞典爱立信有限公司