用于处理客户端数据的方法和设备.pdf

本发明涉及用于当请求存在信息或客户端数据时向被观察客户端(B)传送诸如个人消息等等之类的附加信息的方法和设备。发出请求的客户端(A)在送往能够提供所请求的客户端数据的客户端数据服务器(202)的客户端数据请求中包括自由组成的附加信息片段(300a)。客户端数据服务器提取附加信息并将其插入送往被观察客户端的经扩展的客户端数据请求通知。此后，在被观察客户端处呈现附加信息，以使得用户能够在考虑所呈现的附加信息的情况下，针对发出请求的客户端做出授权决定。

1.  一种处理对被观察客户端(B)的客户端数据的请求的方法，在能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器(202)中执行，其中已经从被观察客户端接收到针对关于对获得客户端数据的任意未经授权尝试的通知的预订请求(3:1)，所述方法包括以下步骤：
-从初始未经授权的监视客户端(A)接收对被观察客户端的客户端数据的经扩展的请求(300，300a)，所述经扩展的客户端数据请求包含已经由监视客户端创建或选择的附加信息(300a)以在客户端数据请求中对他自己/她自己进行标识或呈现；
-在检测到所述监视客户端未经授权之后，从经扩展的客户端数据请求中提取所述附加信息，以及
-向被观察客户端发送关于监视客户端对获得客户端数据的未经授权尝试的经扩展的通知(302，300a)，所述经扩展的通知包含所提取的附加信息。

2.  根据权利要求1所述的方法，其中通过检查用于被观察客户端的规则数据库来检测监视客户端未经授权。

3.  根据权利要求1或2所述的方法，其中响应于所述经扩展的通知而从被观察客户端接收授权决定。

4.  根据权利要求3所述的方法，其中所接收的授权决定授权监视客户端接收所请求的客户端数据并且包括来自被观察客户端的附加消息，并且其中附加消息与所请求的客户端数据一起在经扩展的客户端数据通知中被发送至监视客户端。

5.  根据权利要求3所述的方法，其中所接收的授权决定授权监视客户端接收所请求的客户端数据，附加消息被从被观察客户端单独地接收，并且其中附加消息与所请求的客户端数据一起在经扩展的客户端数据通知中被发送至监视客户端。

6.  根据权利要求1-5中任一权利要求所述的方法，其中客户端数据服务器是存在服务器，经扩展的客户端数据请求是SIP预订消息，所述SIP预订消息将附加信息容纳在现有首部中、新首部中、或作为消息主体的一部分，并且关于未经授权的尝试的经扩展的通知是SIP通知消息，所述SIP通知消息将附加信息容纳在现有首部中、新首部中、或作为消息主体的一部分。

7.  根据权利要求1-6中任一权利要求所述的方法，其中附加信息包括以下任一项：文本字符串、图片、视频/音频剪辑以及到个人主页或可下载文件的链接。

8.  根据权利要求1-7中任一权利要求所述的方法，其中所接收的经扩展的客户端数据请求是根据多个被观察客户端的列表的对客户端数据的请求。

9.  根据权利要求8所述的方法，其中列表是由在客户端数据请求中所包括的列表标识符所指示的被观察客户端的自组列表或预定义列表，其中所述预定义列表被存储在XCAP服务器中并且由客户端数据服务器通过使用客户端数据请求中所包括的列表标识符来获取。

10.  根据权利要求8或9所述的方法，其中所接收的经扩展的客户端数据请求包括对列表中的每个被观察客户端而言有效的唯一附加信息片段、或者对列表中的所有被观察客户端而言都有效的全局附加信息片段。

11.  一种在客户端数据服务器(202)中的用于处理对被观察客户端(B)的客户端数据的请求的设备，所述客户端数据服务器能够为经授权的监视客户端提供被观察客户端的客户端数据，其中已经从被观察客户端接收到针对关于对获得客户端数据的任意未经授权尝试的通知的预订请求(3:1)，所述设备包括通信单元(704b)和逻辑单元(704a)，其中
-通信单元适于从初始未经授权的监视客户端(A)接收对被观察客户端的客户端数据的经扩展的请求(300，300a)，所述经扩展的客户端数据请求包含已经由监视客户端所创建或选择的附加信息(300a)以在客户端数据请求中对他自己/她自己进行标识或呈现，
-逻辑单元适于在检测到监视客户端未经授权之后从经扩展的客户端数据请求中提取附加信息，以及
-通信单元还适于向被观察客户端发送关于监视客户端对获得客户端数据的未经授权尝试的经扩展的通知(302，300a)，所述经扩展的通知包含所提取的附加信息。

12.  根据权利要求11所述的设备，其中逻辑单元还适于通过检查用于被观察客户端的规则数据库来检测监视客户端未经授权。

13.  根据权利要求11或12所述的设备，其中通信单元还适于响应于经扩展的通知而从被观察客户端接收授权决定。

14.  根据权利要求13所述的设备，其中所接收的授权决定授权监视客户端接收所请求的客户端数据并且包括来自被观察客户端的附加消息，并且其中通信单元还适于将附加消息与所请求的客户端数据一起在经扩展的客户端数据通知中发送至监视客户端。

15.  根据权利要求14所述的设备，其中所接收的授权决定授权监视客户端接收所请求的客户端数据，并且其中通信单元还适于单独地从被观察客户端接收附加消息，并且将附加消息与所请求的客户端数据一起在经扩展的客户端数据通知中发送至监视客户端。

16.  根据权利要求11-15中任一权利要求所述的设备，其中客户端数据服务器是存在服务器，对客户端数据的经扩展的请求是SIP预订消息，所述SIP预订消息将附加信息容纳在现有首部中、新首部中、或作为消息主体的一部分，并且关于未经授权的尝试的经扩展的通知是SIP通知消息，SIP通知消息将附加信息容纳在现有首部中、新首部中、或作为消息主体的一部分。

17.  根据权利要求11-16中任一权利要求所述的设备，其中附加信息包括以下任一项：文本字符串、图片、视频/音频剪辑以及到个人主页或可下载文件的链接。

18.  一种对被观察客户端(B)的客户端数据进行请求的方法，在初始未经授权的监视客户端(A)的用户设备中执行，所述方法包括以下步骤：
-创建对被观察客户端的客户端数据的经扩展的请求(300，300a)，所述经扩展的请求包含已经由监视客户端所创建或选择的附加信息(300a)以在客户端数据请求中对他自己/她自己进行标识或呈现，以及
-向能够为经授权的监视用户提供被观察客户端的客户端数据的客户端数据服务器(202)发送经扩展的客户端数据请求。

19.  根据权利要求18所述的方法，其中所创建的经扩展的客户端数据请求是SIP预订消息，所述SIP预订消息将附加信息容纳在现有首部中、新首部中、或作为消息主体的一部分，

20.  根据权利要求18或19所述的方法，其中经扩展的客户端数据请求是根据多个被观察客户端的列表的对客户端数据的请求。

21.  根据权利要求20所述的方法，其中列表是由在客户端数据请求中所包括的列表标识符所指示的被观察客户端的自组列表或预定义列表，其中所述预定义列表被存储在XCAP服务器中，并且由客户端数据服务器通过使用客户端数据请求中所包括的列表标识符来获取。

22.  根据权利要求20或21所述的方法，其中经扩展的客户端数据请求包括对列表中的每个被观察客户端而言有效的唯一附加信息片段、或者对列表中的所有被观察客户端而言都有效的全局附加信息片段。

23.  一种在初始未经授权的监视客户端(A)的用户设备中的用于对被观察客户端(B)的客户端数据做出请求的设备，所述设备包括逻辑单元(700b)和通信单元(700c)，其中：
-逻辑单元适于创建对被观察客户端的客户端数据的经扩展的请求(300，300a)，所述经扩展的请求包含已经由监视客户端所创建或选择的附加信息(300a)以在客户端数据请求中对他自己/她自己进行标识或呈现，以及
-通信单元适于向能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器(202)发送经扩展的客户端数据请求。

24.  一种处理来自初始未经授权的监视客户端(A)的、对客户端数据的请求的方法，在被观察客户端(B)的用户设备中执行，所述方法包括以下步骤：
-向能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器(202)发送针对关于对获得客户端数据的任意未经授权尝试的通知的预订请求(3:1)，
-从客户端数据服务器接收关于监视客户端的客户端数据请求的经扩展的通知(302，300a)，所述经扩展的通知包含已经由监视客户端所创建或选择的附加信息(300a)以在客户端数据请求中对他自己/她自己进行标识或呈现
-从经扩展的通知中提取附加信息，以及
-呈现所提取的附加信息。

25.  根据权利要求24所述的方法，其中所接收的经扩展的通知是SIP通知消息，所述SIP通知消息将附加信息容纳在现有首部中、新首部中、或作为消息主体的一部分，

26.  根据权利要求24或25所述的方法，其中授权决定被发送至客户端数据服务器以授权监视客户端接收所请求的客户端数据，所述授权决定包括从被观察客户端到监视客户端的附加消息。

27.  根据权利要求24或25所述的方法，其中授权决定被发送至客户端数据服务器以授权监视客户端接收所请求的客户端数据，并且到监视客户端的附加消息被单独发送至客户端数据服务器。

28.  一种在被观察客户端(B)的用户设备中的设备，用于处理来自于初始未经授权的监视客户端(A)的对客户端数据的请求，所述设备包括通信单元(702c)、逻辑单元(702b)和呈现单元(702a)，其中：
-通信单元适于向客户端数据服务器(202)发送针对关于对获得客户端数据的任意未经授权尝试的通知的预定请求(3:1)，所述客户端数据服务器(202)能够为经授权的客户端提供被观察客户端的客户端数据，并且通信单元适于从客户端数据服务器接收关于监视客户端的客户端数据请求的经扩展的通知(302、300a)，所述经扩展的通知包含已经由监视客户端所创建或选择的附加信息(300a)以在客户端数据请求中对他自己/她自己进行标识或呈现，
-逻辑单元适于从经扩展的通知中提取附加信息，并且
-呈现单元适于呈现所提取的附加信息。

用于处理客户端数据的方法和设备
技术领域
本发明大体上涉及用于通过客户端数据服务器来处理被观察(observed)客户端的客户端数据的方法和设备。特别地，本发明能够被用于在请求或预订(subscribe)被观察客户端的客户端数据时，提供来自初始未被授权接收客户端数据的监视(watching)客户端的信息。
背景技术
随着3G移动电话的出现，使用IP(网际协议)的新的基于分组的通信技术已经发展成支持多媒体无线通信。例如，GPRS(通用分组无线业务)中的通信协议和WCDMA(宽带码分多址)支持分组交换的多媒体服务以及传统电路交换的语音呼叫。
基于IP传输，第三代合作伙伴计划(3GPP)已经把被称作“IP多媒体子系统”(IMS)的网络体系结构开发成为用于处理分组域中的多媒体服务和会话的平台。因而，IMS网络能够被用于为连接至任意类型接入网络的任意支持IP的(IP enabled)终端发起并控制多媒体会话。被称作“SIP”(根据标准IETF RFC 3261，会话发起协议)的信令协议通常被用于在IMS网络中处理会话。“支持SIP的”终端因而能够使用该标准来通过其归属IMS网络来发起和终止多媒体通信。
图1是基本网络结构的简化示意性图示，该基本网络结构用于通过IMS网络100为使用终端A的客户端提供多媒体服务。在该实例中，终端A是连接至无线电接入网络102的移动终端，并且在多媒体会话中与另一终端B进行通信，尽管IMS还能够被用于固定终端。可替换地，终端A可以与例如用于从其处下载某些多媒体内容的内容服务器的内容服务器等进行通信。IMS终端通常被称作“用户设备(UE)”。
接入网络102连接至IMS网络100，后者是终端A的“归属”IMS网络并且因此处理用于终端A的会话。另一类似的IMS网络104处理用于终端B的会话。基本上，即使当在访问接入网络中进行漫游时，多媒体服务也由终端的归属IMS网络来处理。在所示的实例中，终端A和B分别属于不同的IMS网络100和104，不过它们当然也可以属于相同的IMS网络。
所图示的会话由IMS网络100中的特定会话管理节点106来控制。根据传统IMS体系结构，这些节点通常包括S-CSCF(服务呼叫会话控制功能)、I-CSCF(询问呼叫会话控制功能)和P-CSCF(代理呼叫会话控制功能)。简而言之，P-CSCF节点担当从接入网络到IMS网络100的进入点，多个S-CSCF节点被分配给活动终端以通过使用SIP信令来处理它们的会话，并且I-CSCF节点担当用于来自其他IMS网络的SIP消息的网关。
IMS网络100还包括用于各种多媒体服务的一个或多个应用服务器108，和包含订户和鉴别数据的主数据库节点HSS(归属订户服务器)110。所示网络元件106-110的各种功能通常在现有技术中是已知的，此处没有必要对此进行进一步描述来理解本发明的上下文。
在该图中，通常根据SIP，粗双向箭头图示了两个终端A和B之间的有效载荷数据或“媒体”的通信，而细双向箭头图示了两个IMS网络100和104之间的各种控制消息的通信。每个应用服务器108支持一个或多个特定多媒体服务，诸如“即时消息接发(IM)”、“无线一键通(push-to-talk over cellular(PoC))”和“存在(presence)”，其中SIP信令被用于控制会话。特别地，存在服务基本上使与被观察客户端有关的数据对于其他监视客户端而言可用。
在本说明书中，术语“存在数据”或通常“客户端数据”用于表示关于客户端和他/她的设备在任意预定义方面的状态或情形的信息。简而言之，客户端的存在数据由通常被称作“存在服务器”的应用服务器处的存储装置来发布，所述存在数据能够被提供至预订该存在数据的其他客户端。存在数据可涉及以下示例性客户端状态：
-个人状态，例如，有空、忙碌、会议中、休假中等等。
-终端状态，例如，开/关，使用中，处于覆盖范围外等等。
-客户端/终端的地理位置；
-终端能力，例如用于SMS、MMS、聊天、IM、视频等等的功能。
-终端选择，例如呼叫转移、语言等等。
-其他客户端信息，例如兴趣、职业、个人特征、情绪、个人标志、随当前情绪而定的标志等等。
每当客户端的任意存在数据被引入、更新、改变或删除时，基于接收自客户端或它们的接入网络的所谓的“客户端事件”的发布，该类型的信息被继续存储在IMS网络中的存在服务器中。因而，客户还可以预订一个或多个其他客户端的选定存在数据，所述选定存在数据也由IMS网络中的应用服务器来处理。
在本说明书中，术语“客户端”将被用作通常表示用户设备(或终端)和其用户。此外，术语“监视客户端”表示预订或请求存在数据的客户端(有时也被称为“监视者”)，而术语“被观察客户端”表示发布可供经授权的监视客户端观察的存在数据(有时也被称为“存在性”)的客户端。
被观察用户通常使用被称作“SIP发布”的SIP消息来向存在服务器发送它们的存在数据以进行发布。监视用户使用另一被称作“SIP预订”的SIP消息来预订被观察客户端的存在数据。SIP发布消息基本上能够用在四种不同的情形中，即，1)发起新数据，2)“刷新”数据(即确认较早发起的数据继续有效)，3)修改数据以及4)终止不再有效的数据。SIP预订消息能够被用于仅获得存在数据一次或定期获得存在数据，这是由能够在该消息中设置的超时(time-out)参数来确定的。如果超时参数被设置为0，则具有所请求的存在数据的通知仅被获得一次，并且预订被立即终止。
为了获得对被观察客户端的存在数据的预订，被观察客户端必须授权监视客户端接收此类存在数据，这是通过专用于被观察客户端的存在规则来控制的。被称作XCAP的协议(XML配置接入协议)能够被用于引入、修改和删除存在规则数据库中的存在授权规则。
图2图示了用于获得对存在数据的预订的常规过程，其中涉及属于IMS网络200的监视客户端的用户设备A和被观察客户端的用户设备B，IMS网络200包括代理(act for)客户端B的存在服务器202。基于根据3GPP和IETF-SIMPLE的各种标准，所示过程对于OMA-PAG所定义的标准存在解决方案而言是有效的。如图中所示，由用户所操作的移动终端代表客户端A和B，不过所描述的过程也能够被应用于固定终端。假设客户端A初始未被授权接收客户端B的存在数据。
第一步骤2:1a概括地阐释了根据常规例程、被观察客户端通过向存在服务器202发送SIP发布消息来发布存在数据，如上所描述的那样。也能够从客户端B的接入网络发送用于客户端B的某些数据，例如位置和终端状态数据。在存在数据库204中保存用于客户端B的存在数据，并且步骤2:1b阐释了数据库204响应于接收步骤2:1a的SIP发布消息而进行更新。根据现行的例程，步骤2:1a和2:1b贯穿于该背景中。
客户端A现在想要获得客户端B的存在数据，但是必须被授权接收此类数据。因而，在步骤2:2中，标准SIP预订消息被发送至存在服务器202，作为对客户端B的存在数据的请求，这能够被表示为“SUBSCRIBE(Event package(事件包)＝presence，B)”。
当接收到SIP预订消息时，在后续步骤2:3中，存在服务器202通过检查数据库206中的存在规则来确定客户端A是否被授权接收数据。如果数据库206中的规则指示客户端A是“被允许的”，则具有被观察客户端B的当前存在信息的SIP通知(NOTIFY)被发送至监视客户端A，但是如果发现客户端A“被阻止”，则拒绝预订尝试。在该实例中，假设存在规则数据库206不包含用于客户端A的授权决定，于是存在服务器可以被配置成发送拒绝消息或仅仅忽略该请求。
此处所阐释的当前所开发的另一替换方案是客户端B已经在之前向存在服务器202发送了针对关于未经授权客户端对获得存在数据的任意尝试的信息的预订请求(未示出)，这能够被表示为“SUBSCRIBE(Event package＝presence.winfo，B)”。因而，在下一步骤2:4中，通过向客户端B发送SIP通知消息，存在服务器202通知客户端B：客户端A已经进行了预订尝试，这能够被表示为“NOTIFY(Eventpackage＝presence.winfo，A)”。通过如在步骤2:5中所指示的适当的终端输入命令，在接收到该通知后，客户端B能够决定客户端A是否应该被授权接收所请求的存在数据、或者可选地仅仅被授权接收其中的选定部分。
接下来，在后续的步骤2:6中，通过向存在服务器202发送针对客户端A的授权决定，客户端B对步骤2:4的通知做出响应，其可以在XCAP PUT消息中被发送。在步骤2:7中，授权决定可以是以下中的任一个：允许、拒绝、礼貌阻止等等，其被作为授权规则存储在存在规则数据库206中。如果客户端B只是忽略了步骤2:4的消息，则请求自然会被拒绝。
在该实例中，客户端B实际上允许客户端A接收他/她的存在数据。在步骤2:8中，存在服务器202因此最终向客户端A发送包含客户端B的有效存在数据的SIP通知，这能够被表示为“NOTIFY(Eventpackage＝presence，B)”。
通过就客户端A的预订尝试通知客户端B，如果客户端B允许该预订，则通过发送上述步骤2:2的初始标准SIP预订消息，能够很容易建立对存在数据的预订。尽管如此，步骤2:4的送往客户端B的SIP通知消息仅通过从步骤2:2的SIP预订消息得到的名称或网络地址来识别进行尝试的客户端A，进行接收的用户可能无法识别或理解所述名称或网络地址。例如，如果以“bengt.larsson@telia.com”的方式在指示名称的消息中给出客户端A的标识，如果已知则客户端B可能能够识别它，但是如果以“user1224@freeweb.com”等等的方式给出标识，则不会那么容易识别。
为了克服该限制，客户端A例如总是能够通过电话呼叫、SMS、电子邮件或其他消息接发机制而单独地联系客户端B以标识他自己/她自己并请求许可。尽管如此，该附加的通信会增加网络负担并且使所涉及的客户端负担额外的努力和成本。此外，被观察客户端可能不具有相同类型的消息接发客户端能力或者可能在其他方面不兼容。客户端B还可以对进入的消息施加接入限制以仅允许来自于已知客户端的消息，由此防止客户端A以这种方式进行通信(如果未知)。
发明内容
本发明的目的是解决上述问题。具体地，本发明的目的是提供一种解决方案，该解决方案避免了在试图获得关于被观察客户端的存在信息时对附加呼叫或消息接发的需要。可以通过使用根据所附独立权利要求的方法和设备来实现这些目的和其他目的。
根据本发明的一个方面，本发明提供了一种处理对被观察客户端的客户端数据的请求的方法，在能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器中执行。已经从被观察客户端接收到针对关于对获得客户端数据的任意未经授权尝试的通知的预订请求。在该方法中，从初始未经授权的监视客户端接收对被观察客户端的客户端数据的经扩展的请求，其中经扩展的客户端数据请求包含已经由监视客户端创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。在检测到监视客户端未经授权之后，从经扩展的客户端数据请求中提取附加信息，并且把关于监视客户端对获得客户端数据的未经授权尝试的经扩展的通知发送至被观察客户端，其中经扩展的通知包含所提取的附加信息。
附加信息可以包括文本字符串、图片、视频/音频剪辑、或到个人主页或可下载文件的链接。
响应于经扩展的通知，可以从被观察客户端接收到授权决定，该决定可以包括来自于被观察客户端的附加消息，此后，其与所请求的客户端数据一起在经扩展的客户端数据通知中被发送至监视客户端。可替换地，从被观察客户端单独接收的附加消息能够与所请求的客户端数据一起在经扩展的客户端数据通知中被发送至监视客户端。
所接收的经扩展的客户端数据请求可以是根据多个被观察用户的列表的对客户端数据的请求，并且可以包括对列表中的每个被观察客户端而言有效的唯一附加信息片段(unique pieces of additionalinformation)、或者对列表中的所有被观察客户端而言都有效的全局附加信息片段。
根据另一方面，本发明提供了一种客户端数据服务器中的设备，该设备用于根据上述客户端数据服务器方法处理对被观察客户端的客户端数据的请求。本发明的客户端数据服务器设备包括通信单元和逻辑单元。通信单元适于从初始未经授权的监视客户端接收对被观察客户端的客户端数据的经扩展的请求，其中经扩展的客户端数据请求包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。逻辑单元适于在检测到监视客户端未经授权之后从经扩展的客户端数据请求中提取附加信息。通信单元还适于向被观察客户端发送关于监视客户端对获得客户端数据的未经授权尝试的经扩展的通知，经扩展的通知包含所提取的附加信息。
根据又一方面，本发明提供了一种对被观察客户端的客户端数据进行请求的方法，在初始未经授权的监视客户端的用户设备中执行。在监视客户端方法中，创建对被观察客户端的客户端数据的经扩展的请求，该请求包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。此后，经扩展的客户端数据请求被发送至能够为经授权的监视用户提供被观察客户端的客户端数据的客户端数据服务器。
如上所述，经扩展的客户端数据请求可以是根据多个被观察用户的列表的对客户端数据的请求，并且经扩展的客户端数据请求可以包括对列表中的每个被观察客户端而言有效的唯一附加信息片段、或者对列表中的所有被观察客户端而言都有效的全局附加信息片段。
根据另一方面，本发明提供了一种初始未经授权的监视客户端的用户设备中的设备，该设备用于根据上述用户设备方法做出对被观察客户端的客户端数据的请求。本发明的用户设备包括逻辑单元和通信单元。逻辑单元适于创建对被观察客户端的客户端数据的经扩展的请求，该请求包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。通信单元适于向能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器发送经扩展的客户端数据请求。
根据另一方面，本发明还提供了一种处理来自于初始未经授权的监视客户端的、对客户端数据的请求的方法，在被观察客户端的用户设备中执行。在被观察客户端方法中，针对关于对获得客户端数据的任意未经授权尝试的通知的预订请求被发送至能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器。在此后的某时刻，从客户端数据服务器接收关于监视客户端的客户端数据请求的经扩展的通知，该通知包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。此后，从经扩展的通知中提取附加信息并将其呈现给被观察客户端用户。
根据又一方面，本发明还提供了一种在被观察客户端的用户设备中的、用于处理来自初始未经授权的监视客户端的对客户端数据的请求的设备，该设备包括通信单元、逻辑单元和呈现单元。通信单元适于向能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器发送针对关于对获得客户端数据的任意未经授权尝试的通知的预订请求。通信单元还适于从客户端数据服务器接收关于监视客户端的客户端数据请求的经扩展的通知，该通知包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。逻辑单元适于从经扩展的通知中提取附加信息，并且呈现单元适于呈现所提取的附加信息。
本发明使得被观察客户端处的用户能够在考虑所呈现的附加信息的情况下针对监视客户端做出授权决定。因此，相较于现有技术，可以更为容易地识别和评估未经授权的监视客户端。能够通过在不严重影响业务负载、也不需要额外网络资源的情况下使用现有标准机制来实施本发明。
在阅读以下详细描述之后，能够理解本发明的其他特征和其优势。
附图说明
下文将通过示例性实施例并参照附图来更为详细地描述本发明，其中：
图1是根据现有技术的包含两个终端和IMS网络的基本通信场景的示意图；
图2是图示根据现有技术的、用于获得被观察客户端的存在数据的常规过程的框图。
图3是图示根据一个实施例的、用于获得和提供被观察客户端的存在数据的过程的框图。
图4是根据另一实施例的、由客户端数据服务器所执行的用于处理对被观察客户端的客户端数据的请求的过程中的步骤的流程图。
图5是根据又一实施例的、由监视客户端的用户设备所执行的用于获得被观察客户端的客户端数据的过程中的步骤的流程图。
图6是根据又一实施例的、由被观察客户端的用户设备所执行的用于处理来自于监视客户端的对客户端数据的请求的过程中的步骤的流程图。
图7是图示根据其他实施例的监视客户端的用户设备、被观察客户端的用户设备、和能够提供被观察客户端的客户端数据的客户端数据服务器的框图。
具体实施方式
简而言之，本发明能够被用于在请求存在信息或客户端数据时、向被观察客户端传送诸如个人消息等等之类的附加信息，而不需要用于呼叫或消息接发的附加通信。发出请求的客户端能够把附加信息包括在对被观察客户端的客户端数据的“经扩展的”请求中，例如作为SIP预订消息，其被发送至能够提供所请求的客户端数据的客户端数据服务器。
附加信息可以是自由组成的文本字符串，诸如“Hi，this is Bob.Wemet at the pub last night.”。附加信息还可以包括由发出请求的客户端所创建或选择的任意其他信息，诸如图片、视频/音频剪辑、或到个人主页或可下载文件的链接。因而，客户端自由选择任意描述片段、标识或其他对象来组成客户端数据请求中的附加信息。
当客户端数据服务器接收到经扩展的客户端数据请求时，其中的附加信息被检测到并被提取以便插入在类似的“经扩展”的客户端数据请求通知，例如SIP通知消息，其被发送至被观察的客户端。此后，被观察客户端的用户设备(或终端)呈现附加信息以使得用户能够在考虑所呈现的附加信息的情况下针对发出请求的客户端做出授权决定。
因而，相较于仅仅接收常规通知中的名称或网络地址，用户于是将能够更为容易地识别和评估发出请求的客户端。此外，不需要额外的通信来传送附加信息。
根据下文中描述的机制，术语“存在数据”此处将用于表示可用的或“被观察”的任意客户端数据。此外，所描述的“客户端数据服务器”可以是能够为监视客户端提供被观察客户端的客户端数据的任意服务器或功能性实体，其也可被称作“通知者(notifier)”等等。
尽管以下实施例主要针对存在服务进行描述，但是本发明不限于此，而是能够针对使用客户端数据预订机制的任意应用和服务进行实施。此外，下文中所描述的存在服务器可以是能够为经授权的监视客户端提供所请求的客户端数据的任意服务器。
在以下描述中，将参考为公知的SIP消息，但是本发明一般不限于此。下文将针对图3中所示的框图中的信令过程描述一个实施例，对于发出请求的/监视客户端A、被观察客户端B、存在服务器202、存在数据库204和规则数据库206，该图使用与在图2相同的附图标记。
出于简化的目的，没有示出如图2中的步骤2:1a和2:2b中所示的为客户端B保存更新的存在数据的进行中的例程。在第一步骤3:1，客户端B向存在服务器202发送针对关于未经授权客户端对获得存在数据的任意尝试的信息的预订请求，这能够被表示为“SUBSCRIBE(Event package＝presence.winfo，B)”。
下一步骤3:2阐释了客户端A的用户通过将附加信息包括在存在数据请求中来创建对客户端B的存在数据的经扩展的请求。如果使用了SIP信令，则仅需要附加信息能够被容纳(accommodate)在SIP预订消息中，被容纳在现有首部中、或者是在新首部中、或者是作为消息主体的一部分。附加信息可以包含上文中示例性阐释的任意消息或描述。在后续步骤3:3中，具有附加信息300a的经扩展的存在数据请求300然后被发送到存在服务器202。
在接收到存在数据请求300时，在步骤3:4中，存在服务器202在存在规则数据库206中检查发出请求的客户端A是否被授权接收所请求的数据，并且没有在存在规则数据库206中找到针对客户端A的授权决定，因而未经授权。根据在步骤3:1中所接收到的针对关于对获得存在数据的未经授权尝试的信息的预订请求，因而存在服务器202不得不向客户端B报告客户端A的尝试。
在报告之前，存在服务器202从所接收到的存在数据请求300中提取附加信息300a，如下一步骤3:5中示意性阐释的那样。此后，在下一步骤3:6中，存在服务器202向客户端B发送包括附加信息300a的经扩展的存在请求通知302，其能够被表示为“NOTIFY(EVENTpackage＝presence.winfo，A)”。同样，如果使用了SIP信令，则仅需要附加信息300a能够被容纳在SIP通知消息中，被容纳在现有首部中、或者是在新首部中、或者作为消息主体的一部分。
在另一步骤3:7中，客户端B的用户设备(或终端)于是通过显示文本字符串、图片或指向主页或可下载文件的URL、或通过播放音频消息等等来相应地呈现附加信息300a。此后用户能够在考虑所呈现的附加信息的情况下决定是否对发出请求的客户端A进行授权。以这种方式，相较于仅仅接收可能不被识别的客户端标识，被观察客户端能够更为容易地识别和评估发出请求的客户端。
在接下来的步骤3:8中，客户端B现在能够通过向存在服务器202发送授权决定304而对存在请求通知302自由地进行响应。可选地，客户端B也可以将附加消息304a插入授权决定304，后者将在经扩展的存在通知中被发送至监视客户端A。客户端B也可以为不同类别的监视者预定义某些标准消息(诸如待定、允许、阻止、礼貌阻止等等)，这能够根据决定结果而被自动包括在授权决定304中。
类似于上述步骤2:6，可以在XCAP PUT消息中发送步骤3:8的授权决定304，如允许、拒绝、礼貌阻止等等中的任一项，这通常用于改变存在授权规则。一旦被存在服务器202接收到，在步骤3:9中，授权决定就被作为规则存储在存在规则数据库206中。如果客户端B仅忽略对存在请求通知302做出响应，则尽管该请求可一直保持直到由客户端A终止，但是客户端A当然不会被授权。
因而，也可以在数据库206中引入将客户端A标记为“被忽略”或“被拒绝”的规则。然而，在这个实例中，客户端B已经允许客户端A接收所请求的存在数据，该存在数据是在另一步骤3:10中从存在数据库204中获取的。
此后，在步骤3:11中，存在通知306最终被发送至客户端A，该通知包含客户端B的有效存在数据并且可选地还可以包括附加消息304a，其能够被表示为“NOTIFY(Event package＝presence，B)”。同样，如果使用了SIP信令，则仅需要附加消息304a能够被容纳在扩展的SIP通知消息中，被容纳在现有首部中、或者是在新首部中、或者是作为消息主体的一部分。此处为了简化，没有示出在将其与存在通知306一起发送之前从授权决定304中提取附加消息304a的步骤。
另一替换方案将是客户端B在进行中的信令对话中发送单独的SIP消息，以向客户端A传送个人消息。然后客户端B将在常规XCAP消息中发送允许客户端A监视客户端B的存在数据的授权决定，并且还向存在服务器202发送包含个人消息的单独SIP消息。当接收到“允许”的XCAP消息时，存在服务器202将会取得SIP消息中的个人消息并将其包括在送往客户端A的存在通知306中。
下文将针对图4中所示的流程图来描述根据另一实施例的用于处理对被观察客户端的存在数据的请求的过程。所描述的过程通常在能够为经授权的监视客户端提供被观察客户端的客户端数据的客户端数据服务器中执行，其可以是如上述实例中的存在服务器等等。在第一步骤400中，从被观察用户接收针对关于对获得被观察客户端的客户端数据的任意未经授权尝试的通知的预订请求(基本上对应于图3中的步骤3:1)。假设客户端数据服务器存储被观察客户端的数据，该数据能够根据请求而被提供给任意经授权的监视客户端。
在此后的某一时刻，在下一步骤402(基本上对应于图3中的步骤3:3)中，从监视客户端接收到对被观察客户端的客户端数据的请求。此后在步骤404中，在规则数据库等等中检查监视客户端是否被授权接收被观察客户端的此类客户端数据(基本上对应于图3中的步骤3:4)。
在这个时刻，在步骤404中，三种不同的结果基本上是可能的：首先，如果发现监视客户端是经过授权的(是)，则在步骤406a中，有效客户端数据被在常规通知中发送至监视客户端。第二，如果监视客户端在规则数据库中被登记为未经授权(否)，则在步骤406中拒绝客户端数据请求，这可能需要送往监视客户端的适当拒绝消息。
第三，如果没有在规则数据库中找到任何针对监视客户端的授权决定(无决定)，则在另一步骤408中，检查步骤402中所接收到的客户端数据请求中是否包括任何附加信息。如果没有，则在下一步骤410(基本上对应于图2中的步骤2:4)中，针对未经授权尝试的常规通知被发送至被观察客户端，因而仅仅包括通常在常规客户端数据请求中所给出的监视客户端的地址或名称，它在被接收时很可能无法为被观察客户端所识别。
尽管如此，如果确实在步骤402中所接收到的客户端数据请求中发现了附加信息，例如文本字符串、到主页的链接等等，则在另一步骤412(基本上对应于图3中的步骤3:5)中，从请求中提取附加信息以将其包括在针对未经授权尝试的通知中。最后，在最后所阐释的步骤414(基本上对应于图3中的步骤3:6)中，包括附加信息的经扩展的尝试通知被发送至被观察客户端。由此，被观察客户端能够考虑附加信息以识别和评估发出请求的客户端。
与图3类似，根据各种替换方案和选项，例如取决于被观察客户端怎样做出响应，如果有的话，该过程可从此处继续为：被观察客户端对步骤414的经扩展的尝试通知做出响应。
图5是根据又一实施例的、由监视客户端的用户设备所执行的用于获得被观察客户端的客户端数据的基本过程中的步骤的流程图。在第一步骤500中，响应于用于获得客户端数据的用户输入命令，包括附加信息的对被观察客户端的客户端数据的经扩展的请求被创建。附加信息已经由监视客户端所创建或选择以在客户端数据请求中向被观察客户端标识或呈现他自己/她自己。
在下一步骤502中，所创建的客户端数据请求被发送至客户端数据服务器，后者适于向任意经授权的监视客户端提供被观察客户端的客户端数据，其可以是存在服务器等等。
最后，在步骤504中，响应于步骤502中所发送的客户端数据请求，从客户端数据服务器接收所请求的客户端数据或拒绝。因而如果被观察客户端已经决定对监视客户端进行授权，则所请求的客户端数据被接收到，但是如果不是的话，则拒绝被接收到。
图6是根据由一实施例的、由被观察客户端的用户设备所执行的用于处理来自于监视客户端的对客户端数据的请求的基本过程中的步骤的流程图。在第一步骤600中，针对关于未经授权的客户端对获得客户端数据的任意尝试的信息的预订请求被发送(响应于用户命令)至客户端数据服务器，该客户端数据服务器适于向经授权的监视客户端提供被观察客户端的客户端数据。如上述实施例中那样，客户端数据服务器可以是存在服务器等等。
在下一步骤602中，在某一时刻接收到关于监视客户端的客户端数据请求的经扩展的通知，该通知包含已经被监视客户端包括在客户端数据请求中的附加信息。
最后，在步骤604中，从被观察客户端的经扩展的通知中提取附加信息并且通过用户设备对附加信息进行呈现。取决于格式，提取自经扩展的客户端数据请求通知的附加信息可以被可视和/或可听地呈现。
图7是图示根据其他实施例的初始未经授权的监视客户端A的用户设备700、被观察客户端B的用户设备702、和能够提供被观察客户端的客户端数据的客户端数据服务器704的框图。
监视客户端A的客户端设备700包括用于对被观察客户端B的客户端数据进行请求的设备，该设备基本上包括用户输入单元700a、逻辑单元700b和通信单元700c。用户输入单元700a被用于接收用户输入命令以用于创建客户端数据请求。
逻辑单元700b适于响应于用户输入单元700a所接收到的用户输入命令而创建对被观察客户端的客户端数据的经扩展的请求。经扩展的请求包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。通信单元702c适于向客户端数据服务器704发送经扩展的客户端数据请求R。
客户端数据服务器704包括用于在已经从被观察客户端接收到针对关于对获得客户端数据的未经授权尝试的通知的预订请求时处理对客户端数据的请求的设备，其基本上包括逻辑单元704a和通信单元704b。
通信单元704b适于从监视客户端A接收经扩展的客户端数据请求R。逻辑单元704a适于在通过检查用于被观察客户端B的规则数据库706而检测到监视客户端未经授权之后，从经扩展的客户端数据请求中提取附加信息。通信单元704b还适于向被观察客户端发送关于监视客户端对获得客户端数据的未经授权尝试的经扩展的通知N，所述经扩展的通知包含所提取的附加信息。
被观察客户端B的用户设备702包括用于处理来自监视客户端A的对客户端数据的请求的设备，其基本上包括呈现单元702a、逻辑单元702b和通信单元702c。
通信单元702c适于向客户端数据服务器704发送针对关于对获得客户端数据的任意未经授权尝试的通知的预定请求S，并且适于接收关于监视客户端的客户端数据请求的经扩展的通知N，所述经扩展的通知包含已经由监视客户端所创建或选择的附加信息以在客户端数据请求中对他自己/她自己进行标识或呈现。逻辑单元702b适于从经扩展的通知中提取附加信息，并且呈现单元702a适于呈现所提取的附加信息。
如果被观察客户端B决定授权监视客户端接收所请求的客户端数据，则逻辑单元704a能够从客户端数据库708中获取所请求的客户端数据，并且通信单元704b能够向监视客户端A发送所获取的客户端数据。
应当注意到，图7中所示的节点700、702和704中的不同元件是根据它们的逻辑功能来描述的，它们能够由本领域内的技术人员以任意适当方式通过各种硬件和软件来实施。
当监视客户端根据多个被观察客户端的列表来预订或请求客户端数据时，也可以使用本发明，其中使用用于客户端数据信息的相同的通知机制。尽管如此，列表预订是不同的，因为相同预订被用于多个被观察客户端。此后，可以从与列表中的各个被观察客户端相关联的多个客户端数据服务器获得客户端数据。
能够“自组(ad-hoc)”地创建列表预订，即，客户端列表被包括在预订请求的主体中。可替换地，能够根据预定义的客户端列表来创建列表预订，当客户端数据请求中包括列表标识符时，其能够被存储在XCAP服务器中并且由客户端数据服务器获取。
在两种情况下，可以在客户端数据请求中指定就每个被观察客户端而言的唯一附加信息、或对列表中的所有被观察客户端都有效的全局附加信息。如上述单独客户端数据请求的情况中那样，这能够通过将附加信息包括在请求中，或者在现有首部中、或者在附加首部中、或作为请求消息主体的一部分而被完成。
如果附加信息对于每个客户端而言是唯一的，则不同的附加信息片段必须被包括在请求中，其中每个附加信息片段指向特定的被观察客户端。在预定义的附加信息片段的情况下，它们能够被创建一次并且被存储在XCAP服务器中。然后所谓的资源列表服务器(RLS)能够被用于从客户端数据请求中提取不同的附加信息片段，以将其包括在指向各客户端的每个存在服务器的客户端数据请求或存在预订中。此后每个存在服务器将使用通过本发明所提供的机制。此外，如果使用全局消息，则其能够被创建一次并且被用于可被添加至列表的任何新的被观察客户端。
相较于根据现有技术仅使用常规通知中的名称和网络地址，通过在被观察客户端处呈现附加信息，可以更为容易地识别和评估发出请求的客户端。因而，被观察客户端处的用户能够在考虑所呈现的附加信息的情况下针对监视客户端做出授权决定。
此外，能够在不严重影响业务负载、也不需要任何额外的网络资源的情况下通过使用现有标准机制来实施本发明。如上所述，当预订单独的被观察客户端以及多个被观察客户端的列表时，能够使用本发明。通过将附加信息包含在客户端数据请求或存在请求中，没有必要在用于实现此功能的解决方案中协调任何独立的消息接发。
尽管已经针对特定示例性实施例对本发明进行了描述，但是本说明书总的来说仅意在阐释本发明的概念，而不应被看作限制本发明的范围，本发明的范围是由所附权利要求来限定的。在描述以上实施例时，尽管已经频繁使用IMS技术和SIP信令协议，但是基本上也可以使用用于实现上述功能和服务的任意其他标准和协议。