专利名称：在基于存在服务中的服务器侧管理好友列表的方法和装置的制作方法
技术领域：
本发明涉及支持基于存在的服务的通信系统，特别涉及用于集中管理好友列表的方法和装置，所述好友列表即用于在所述服务中的存在使能应用的、通过所述系统进行交互的用户(好友)的联系列表。
最好，但不是绝对，本发明是为了管理可以被移动通信系统的用户使用的存在使能应用的好友列表。
背景技术：
基于存在的服务是多年来已被有线线路互联网用户使用的服务，特别是与即时消息服务有关，以便允许即时消息服务的用户随时了解他们的通信方的在线状态、有效性、位置等，并且被告知通信方的情况的变化。
在由IETF(互联网工程任务组)的M.DAY等人于2000年2月所公开的文件RFC 2778“A Model for Presence and Instant Messaging(存在及即时消息的模型)”，以及M.DAY等人的文件RFC 2779“Instance Messaging/PresenceProtocol Requirements(即时消息/存在协议请求)”中公开了IM&P(即时消息和存在)服务的基本特性。所述文件在IETF网站http//www.ietf.org/rfc.html可以得到。
当前这种类型的服务也打算用于无线环境中，不同的组织已经开发或正在开发用于这样的环境的存在服务的规范/建议。这里可以提到的是由无线村(Wireless Village，WV)发起的开放移动联盟(Open Mobile Alliance，OMA)，以及IETF的SIMPLE(用于即时消息和存在作用扩展[Instant Messaging andPresence Leveraging Extension]的SIP[Session initiation Protocol，会话启动协议])和XMPP(扩展即时消息和存在协议)；PAM(Presence and AvailablilityManagement，存在和可用性管理)论坛；在IMS(IP[Internet Protocol，互联网协议]多媒体子系统)体系结构中的具有存在服务(Presence Services)的3GPP(第3代项目合作)。
目前，除了即时消息，为了固定和无线网络，还开发了一些其它使用存在信息(也称为存在使能的应用)的应用。为了娱乐和信息的目的，网络操作者以及服务提供者通过越来越多地寻求交互式多媒体服务，来试图捕捉终端用户的兴趣。
提供所述的服务通常会使在特定时间和在一段时期内分享相同的兴趣的人相互联系，也就是在创建的组或者其成员随时间变化的虚拟社区(动态社区)中。一个典型的例子可以是互动游戏，其中参与者通过淘汰过程从一个游戏阶段或级别到达另一个阶段或级别，在淘汰过程中他们挑战其他的参与者在这样的情况下，虚拟社区会包括处于游戏中的给定阶段的参与者。当创建这样类型的虚拟社区时，就出现了管理社区成员的联系列表的问题，以便适当地应对成员的变化。
迄今，好友列表被理解为单纯的联系列表或地址簿，它们由用户通过添加已知用户(姓名和地址已知的好友)或可以从目录服务器联系到的未知好友，来直接建立和维护。这样的联系列表可以存储在用户设备(例如移动电话、PC)中，也可以存储在网络服务器中。在后一种情况下，适合的协议将允许用户管理和检索存储在服务器中的联系列表。
这样的协议的例子有IETF(见J.Rosenborg所作的互联网草案draft-ietf-simple-xcap-2，“Extensible Markup Language(XML)ConfigurationAccess Protocol(XCAP)，(可扩展标记语言(XML)配置访问协议(XCAP))”，可以在上述IETF网站得到)提出的XCAP[Extensible Markup Language(XML)Configuration Access Protocol，(可扩展标记语言(XML)配置访问协议))协议和OMA(见可以在http//www.openmobilealliance.org得到的文件OMA-IMPS-WV-CSP-V1_2-20030117-D)的CSP(Client-Server Protocol，客户-服务器协议)。特别是后者公开了一种方式，其中所谓的组服务(见文件OMA-IMPS-WV-CSP-Arch-V1_2-20030117-D)的用户能够借助适合的消息对组进行创建和管理。
已知的解决方案不适合动态的环境，因为它们不具有任何用于在服务器和用户之间保持联盟的特性。用户必须周期性地查询服务器，看集中存储的好友列表是否发生了改变。这将会在网络上产生许多消息交换，而当该网络是移动网络的情况下，就会导致无线资源的浪费，如果用户必须更新几个列表，则这会是一个相当漫长和枯燥的操作。
本发明为此提供了一个解决方案。
发明内容
本发明的第一方面提供了一种管理在由通信系统支持的存在使能应用中的联系列表的方法，存在使能应用是其中用户形成随时间变化的虚拟社区的类型的应用，社区中的用户为了应用的目的而进行暂时地交互，存在使能应用具有在用户设备上的客户侧和在存在使能网络中的服务器侧。该方法包括下面步骤-用户在应用的服务器侧进行注册，以提供所述虚拟社区的候选者；-在存在使能网络中的好友列表管理单元中，从候选者中创建每个虚拟社区的成员的至少一个好友列表；-由列表管理单元将至少一个好友列表通知给列表成员的用户设备中的客户单元；-在每一个接收到列表的成员的用户设备上显示所通知的列表。
本发明还以供了一种用于实施该方法的装置，其包括-所述存在使能网络中的列表管理单元，从在存在使能网络中的应用服务器进行了注册的用户中，创建社区成员(好友)的特定于应用的列表，并且当出现需求时，将列表自动地通知其成员；-每个用户的设备上的列表客户单元，接收由列表管理单元提供的列表，并与应用的客户侧合作以在用户设备上显示所通知的列表。
本发明还提供了支持该方法并包括所述装置的通信系统。
现在参考附图通过非限定性的示例给出本发明的优选实施例，其中-图1示出根据应用到移动通信系统中的本发明装置的第一实施例的示意图；-图2示出根据本发明装置的第二实施例的简化示意图；-图3示出本发明的一般流程图；-图4示出本发明的示例应用的服务器侧动态好友列表和用户侧列表的直观图；-图5至图8示出根据本发明装置的服务器侧部件的操作的流程图；以及-图9和图10示出根据本发明的装置，在两个不同的配置中的用户侧部件的操作的流程图。
具体实施例方式
本发明涉及在应用服务器(例如SIP应用服务器)或一般网络服务器上运行的应用。其实例有多方/互动式游戏，或者一般是要求一个用户(好友)与其他用户进行暂时地交互的多方应用。当好友随时间变化时可以应用本发明，以便用户管理多个“动态”联系列表(动态好友列表，DBL)。
通过使用本发明，考虑到用户隐私权，为应用提供了一种能够管理动态虚拟社区的工具。每个虚拟社区都可以被看作一个组，从该组中导出若干好友列表(BL)。管理包括创建、修改和删除列表，最后但非最不重要的，当应用需要时，将列表自动地分发给成员。这样的虚拟社区的每个成员都将在专用的BL上看到其他成员。社区成员(因而好友列表成员)并不是由每个终端用户定义的，而是可能由应用在与存在相关的标准(过滤标准)的基础上确定的，例如按照基于公布的存在和可用性信息的条件定义的(这里“可用性”表示可被相同应用的所有其他用户获得的自愿性，并且也可以根据用户的位置)。例如，过滤标准可以是状态等于“在线”，而位置等于“城市A”。换句话说，应用能够要求，只有在特定存在状态和/或位置的终端用户被包括在给出的好友列表中。
根据允许用户进入虚拟社区的标准，确定了两种类型的DBL-具有固定的好友的DBL(封闭的DBL)列表中的好友是在列表创建时已经注册的所有用户，并且他们不发生变化(但是可以创建新的列表)；-具有变化的好友的DBL(开放的DBL)根据过滤标准，好友进入和离开该列表，并且在列表创建之后可以被添加和去除。
对递送列表到好友的模态(递送标准)，应用还能够应用基于存在和可用性的标准例如，可以一旦好友上线和/或如果好友在一个给定的位置就提供列表。
终端用户(即好友)得益于DBL的性能，但是他们对DBL功能性的控制仅仅是间接的这使用户免于处理与他们决定预定的每一个不同的应用相关的所有联系。终端用户只需要对所选择的应用进行注册/注销，然后他们将被通知与应用相关联的联系列表。对于隐私方面，当进行注册时，除了他们的身份之外，终端用户还将提供一个或多个别名然后实际的身份将只被服务/应用管理者所知，而只有别名将被显示在其他用户的终端上。用户将能够为在给出的服务中、他们是其成员的每个虚拟社区定义一个或多个别名。
动态好友列表(Dynamic Buddy List)需要在服务器和客户(用户)侧都得到支持，根据本发明的装置包括在服务器侧的第一部件，称为DBL管理器(DBLM)，以及在每个用户的设备上的、在客户侧的称为DBL客户(DBLC)的部件(例如，移动电话、个人计算机、个人数字助理……)。
服务器侧部件DBLM，如上所述，可能地根据与存在和/或可用性有关的标准，负责用于特定服务好友列表的动态创建、更新和删除。DBLM还负责将列表递送到终端用户。并且，递送也可以用与存在和/或可用性有关的标准来规范。为了它的操作，DBLM必须与应用的服务器侧以及与存在服务器合作。
客户侧部件DBLC负责显示好友列表，如果需要，这包括显示所有好友列表成员的存在状态，并且负责使列表与来自网络(即，来自DBLM)的更新保持一致(align with)。对于这样的操作，DBLC必须与应用的客户侧合作。
现在参考图1和图2描述实施本发明装置的两个实施例。描述涉及在无线通信网络中的本发明的应用，诸如在第3代移动网络中。
在图1中，附图标记UE表示用户设备，例如移动电话或PDA(个人数字助理)，而附图标记PEN指示存在使能的网络，即管理基于存在的服务的网络，而基于存在的服务能够被用户终端UE通过移动通信网络访问，所述移动通信网络在这里图示地表示为无线接入网络RAN、服务GPRS(General Packet RadioService，通用分组无线服务)支持节点SGSN和网关GPRS支持节点GGSN。
用户设备UE存储用户访问的存在使能的应用的客户侧(客户应用CA)，并且配备有动态好友列表性能的客户侧部件DBLC。
在网络PEN中，我们已经示出了应用服务器AS和MPM块，应用服务器AS包含存在使能应用的服务器侧部件，而MPM块包括为移动通信网络的用户组管理用户存在和可用性所需的单元。为此，PMP包括存在服务器PS，以及组和列表管理服务器GLMS。执行MPM功能的单元是商业上可得到的，一个实例是Siemens AG(西门子股份公司)的移动存在管理器。在这样的情况下，GLMS块实施联系顾问管理功能。在本发明的这个实施例中，动态好友列表性能的服务器侧部件DBLM也是MPM的一部分。即使为了清楚的缘故，DBLM被表示为一个独立的单元，与PS和GLMS相连，但其也可以在PS中作为GLMS的一个扩展来实施，或者在GLMS中，或者也可以作为执行经典的存在服务器和组管理器的一部分功能的单元。
在DBLM和DBLC之间的通信(即，通知列表)可以通过使用SIP/SIMPLE或者任何其他适用于存在服务的协议来进行，诸如上述WV-CSP。应当注意，移动存在管理器服从所有涉及在说明书介绍中提及的移动网络的存在服务的标准/规范。
假设使用SIP/SIMPLE，在DBLC和DBLM之间的交互可以-基于由DBLM发送到DBLC的SIP MESSAGE/INFO请求(被动客户情形)-或基于对于新的事件，即模板包(例如，动态好友列表)的SIP SUBSCRIBE请求，所述新的事件定义在由DBLC发送到DBLM的“存在”事件包，以及随后从DBLM发送到DBLC的SIP NOTIFY消息中(主动客户情形)。在这样的情形下，DBLC可以指定对哪种类型的通知感兴趣，以及多久该通知将被发送。
在在SIP MESSAGE/INFO消息体中递送动态好友列表的情况下，SIP请求需要由所有的SIP消息标题、或由所有的内容类型来标示，以便由客户作为DBL更新来识别。在在存在事件包中递送DBL的情况下，事件标题用于鉴别进入的消息。
DBLM和PS之间的交互可以基于内部接口。
DBLM和服务器侧应用之间的交互可以基于任何下面为本领域的技术人员所熟知的协议-W3C的SOAP(简单对象访问协议)，SOAP是一种通过在XML(可扩展标记语言)中编码一些信息来传送HTTP消息的协议；这个协议的细节在网站http//www.w3.org/TR/soap12可以得到；-RMI(远程方法指示)，RMI是一种允许驻存在不同的机器中的应用之间进行通信的应用；-HTTP/XCAP或者PAM标准的扩展。
在MPM中，存在服务器PS应当支持由管理者定义的特定于应用存在属性的定义。那些属性应当提供两项信息，也就是对于特定应用的可被获得的自愿性(即，对那个应用的可用性/不可用性)，以及在可用性的情况下，为那个应用所公布的别名。
网络PEN还包括被委托进行会话控制(如CSCF＝Call Session ControlFunction，调用会话控制功能)、认证、交互工作等的单元，以及被委托进行存储关于存在服务用户的数据的单元(如HSS＝Home Subscriber Server，本地订户服务器)。所述单元未被示出，因为他们并不影响对本发明的理解。
图2表示本发明的第二实施例，其中DBLM被结合在应用服务器AS中。在图2中，用相同的附图标记表示与图1中相同的部件。为了简单的缘故，将UE连接到PEN的移动网络单元不再示出。在这样一个实施例中，DBLM必须通过如SIMPLE、WV-CSP或PAM与传统存在服务器PS进行交互，并且担任对于存在信息的监视器。在服务器侧应用和DBLM之间的交互是基于所有的基于Java/RMI的API(应用程序接口)，或基于PAM接口的扩展。这样的选择将尤其取决于所述应用和DBLM是否位于相同或不同的机器中。
应当注意目前第一实施例看来是最优实施例，因为将DBLM和PS结合在同一个单元中，使得更有效地访问存在信息。
图3是本发明的方法的一般流程图。第一步操作(步骤11)是用户对应用进行注册。在执行注册过程中，用户必须提供一个或多个别名(均涉及同一个URI)，并且只有别名将被其他成员看到。注册之后，用户是被接入的那个应用的虚拟社区的候选者。新用户和用户的别名的注册被应用通信到DBLM。
在注册之后，该应用基于注册的用户创建虚拟社区(步骤12)。该社区的成员的别名与好友URL一起被包括在DBLM中该应用的动态好友列表中。
对于社区的创建，该应用可以定义对于特定应用的过滤标准，用于从候选者中选择实际的成员。如上所述，过滤标准一般与存在信息有关，例如它们可以参考应用的用户的存在状态或可用性(在上面指明的最普通的意义下)。在这样的情况下，用户宣告他/她的可用性(步骤13)，并且在这样做时，用户侧部件DBLC将在宣告这样的可用性的存在文件中公布别名。
当要创建一个开放列表时，应用过滤标准。根据应用定义的过滤标准，通过插入/删除联系，所得DBL可以在任意时刻被更新。过滤标准被由DBLM应用。如果没有定义过滤标准，则可以在候选者，即注册用户的基础上，由应用直接创建虚拟社区。在这种情况下，应用创建一个封闭的DBL。一个封闭的DBL不能通过插入/删除联系来修改，但是如果需要可以创建新的DBL。在这种情况下并没有考虑与存在服务器的交互，除非对于可能的递送标准的评价。
在虚拟社区创建/修改之后，创建的/更新的DBL被递送(“通知”，步骤14)到终端用户。该应用能够定义特定应用的递送标准，即将更新消息递送给终端用户的策略。递送标准由PS/GLMS应用。并且，递送标准也可以与存在信息相关，例如与可用性相关。在没有定义特定应用的标准的情况下(默认递送标准)，后者一旦被创建(或者被修改，如果是开放的列表)，则将列表递送到包括在DBL中的所有好友。
除了列表，还可以另外传送通知消息、关于好友的特定应用的信息例如，在互动式游戏的情况下，所述消息能够传送参与者的游戏成绩。
如图4所示，当将列表通知给用户时，目的好友被从该列表中去除，以便该目的好友的别名不会出现在用户终端上显示的本地列表上。
对注册应用的描述也用于从该列表中删除一个用户当用户要求被删除时，该信息被应用传输到DBLM，该DBLM更新该列表(或者如果原来的列表是一个封闭的列表，则定义一个新的列表)并将更新的/新的列表发送给用户。
为了更好地说明该方法，将参考表示DBLM创建封闭的和开放的好友列表、删除封闭的好友列表、和向开放的列表添加用户/从开放的列表删除用户的操作的图5至图8的流程图，以及参考表示DBLC分别对于主动或被动客户配置的操作的图9和图10的流程图。
参考图5，在创建具有所有注册用户的列表(步骤101)之后，如上所述，有两个可能的选择根据默认标准(在流程图中表示为“空”标准)进行递送，或已经设定的特定服务的递送标准。在第一种情形，DBLM将列表发送给在DBL中的所有好友(步骤103)，然后操作结束。如果已经设定了递送标准，则将列表保存在本地存储器中(步骤105)，为了被通知在该列表中的所有好友的确定的存在事件，由DBLM对PS进行预定(步骤106)。然后DBLM等待来自PS的通知。但接收到关于好友的通知时(步骤107的“是”输出)，则存储好友状态(步骤108)。然后DBLM检查(步骤109)是否满足了递送标准(例如，用户对于特定应用是可用的)。在否定的情况下，处理返回到等待另一个通知；在肯定的情况下，好友列表实际上被递送到好友(步骤110)。然后处理返回到等待通知。
参考图6，开放列表的创建过程开始于创建候选者的列表(步骤201)，将该列表存储在本地存储器中(步骤202)。针对候选者的选择设定过滤标准(例如可用性)。因此，与步骤106到108(图5)类似，对PS进行预定(步骤203)，等待来自PS的通知(步骤204)，并且当通知到达时存储好友状态(步骤205)。在步骤206，检查对于那个好友是否满足过滤标准。在否定的情况下，处理返回等待另一个通知；在肯定的情况下，用户实际上被包括在好友列表中(步骤207)。然后，在步骤208创建递送列表，并且所有的好友都满足递送标准(基于步骤204的通知)，然后该列表被递送给在递送列表中的好友(步骤209)。然后处理返回到等待通知。
参考图7，删除过程开始于将空白列表发送给列表中的所有好友(步骤201)，以消除客户侧的列表。其后，如果递送标准为空(检查302的“是”输出)，则过程结束。如果递送标准不为空，因此列表已经被本地保存并进行对PS的预定(见图5)，取消预定(步骤303)，并且从存储器删除列表(步骤304)。过程结束。
对开放好友列表的取消也执行类似的程序。
图8表示开放好友列表的更新。在新注册的情况下，用户被添加到候选者列表(步骤402)，对于那个好友预定PS(步骤403)。接下来的步骤404至409对应于图6的步骤204至209，因而不需要进一步的讨论。在用户取消他/她的注册的情况下，从候选者列表中删除该用户(步骤410)。然后，如果该用户满足递送标准，向该用户发送空白列表(步骤411)并取消对PS的预定(步骤412)。然后，检查该用户是否被包括在好友列表中(步骤413)，并且，如果是肯定的情况下，该列表被更新(或者如果用户是仅有的一个，则删除该列表)。然后，建立递送列表，并且将更新的好友列表发送到在递送列表中的好友(步骤414、415)。当然，如果该用户没有在好友列表中，则检查413的结果是否定的，过程结束。
参考图9，主动客户首先在DBL管理中预定特定事件(步骤501)，由此设定标准用于从DBLM接收通知。当预定时，当来自DBLM的通知到达时(步骤502)，对DBL更新消息的“预定”属性进行检查(步骤503)。这一属性规定了是否请求了对于其它好友的存在文件的预定。如果该属性为真，则进行预定(步骤504)，之后SBLC将该列表递送到客户应用(步骤505)，以便将该列表显示在终端上。在递送之后，开始等待新的通知。请注意在步骤505，如果DBL是空的(即，请求了列表删除)，则SBLC将取消对PS的预定(unsubscribe)。
参考图10，在被动客户的情况下，当接收到DBL时(步骤601)，DBLC执行与上面步骤503至505相同的步骤602至604。然而，在递送之后，过程结束。
上面的描述清楚地示出了动态好友列表的服务器侧管理，其克服了如OMA提出的传统好友列表以及传统联系和组管理功能性的限制。所提出的解决方案特别具有以下优点
-使得用户不再需要保持更新的好友列表；-为服务器侧应用/服务提供了一个工具，用于管理特定应用的好友列表，包括好友列表创建、删除，以及将好友列表分配给终端用户；-对终端用户隐藏好友列表成员的真实身份，他们只通过它们的别名被识别，因而满足了隐私要求；-允许服务器侧应用/服务为好友列表中的每个好友提供可选信息。
显然地，上述描述是通过非限定性的示例给出的，并且在不脱离本发明的范围的情况下，能够进行变化和修改。
权利要求
1.一种管理在由通信系统支持的存在使能应用中的好友列表的方法，所述存在使能应用具有在用户设备(UE)上的客户侧(CA)和在可由用户通过通信系统访问的存在使能网络(PEN)中的服务器侧(AS)，所述存在使能应用是其中该应用的用户(好友)形成随时间变化的虚拟社区类型的应用，该社区中的用户为了应用的目的而进行暂时地交互，该方法的特征在于具有以下步骤-用户在该应用的服务器侧(AS)进行注册，以提供对所述虚拟社区的候选者；-在所述存在使能网络(PEN)中的好友列表管理单元(DBLM)中，从候选者创建每个虚拟社区的成员的至少一个好友列表；-由列表管理单元(DBLM)将所述至少一个好友列表通知给列表成员的用户设备(UE)的客户单元(DBLC)；和-在每个接收到通知的列表的成员的用户设备(UE)上显示该列表。
2.如权利要求1所述的方法，其特征在于，所述注册阶段包括由用户将至少一个特定于应用的别名身份通信给该应用的服务器侧(AS)，以及所述创建阶段包括将每个好友的别名身份，而不是真实身份，保存在好友列表中。
3.如权利要求2所述的方法，其特征在于，所述注册阶段包括由用户将该用户想要成为成员的每个虚拟社区的一个或多个别名身份通信给该应用的服务器侧(AS)。
4.如权利要求1所述的方法，其特征在于，所述创建阶段包括创建封闭的好友列表或开放的好友列表，所述封闭的好友列表具有包括所有已注册到该应用的用户的固定人数的候选者，而所述开放的好友列表则包括满足特定于应用的过滤标准的候选者。
5.如权利要求4所述的方法，其特征在于，所述创建阶段包括当候选者的人数出现变化时，创建新的封闭的好友列表。
6.如权利要求4所述的方法，其特征在于，所述创建阶段包括基于所述过滤标准，通过添加/删除成员来更新所创建的开放列表。
7.如上述权利要求中任一项所述的方法，其特征在于，所述通知阶段包括将好友列表递送给满足递送标准的好友。
8.如权利要求7所述的方法，其特征在于，所述递送标准为默认递送标准，以及所述通知阶段包括一旦创建或更新了列表，就将好友列表递送给该列表中的所有好友。
9.如权利要求3、6或7所述的方法，其特征在于，所述过滤标准和所述递送标准与用户的存在信息相关，并且该方法包括列表管理单元(DBLM)预定所有候选者的存在信息。
10.如权利要求9所述的方法，其特征在于，所述存在信息与用户状态和/或用户对于特定于应用和/或用户位置的可用性有关。
11.如权利要求7至10中任一项所述的方法，其特征在于，所述通知阶段包括当相同的目的成员被递送给列表成员时，从该列表中删除该目的成员。
12.如权利要求1所述的方法，其特征在于，所述显示阶段包括在每个用户的用户设备上显示关于列表中其他成员的存在信息。
13.如权利要求1所述的方法，其特征在于，该方法还包括通过以下步骤来删除好友列表-由列表管理单元(DBLM)向所有列表成员发送空白好友列表，以使客户单元(DBLC)消除它们的本地好友列表；-在列表管理单元(DBLM)中删除保存在其中的好友列表。
14.一种用于管理由通信系统支持的存在使能的应用中的好友列表的装置，所述存在使能应用具有在用户设备(UE)上的客户侧(CA)和在可由用户通过通信系统访问的存在使能的网络(PEN)中的服务器侧(AS)，所述存在使能应用是其中该应用的用户(好友)形成随时间变化的虚拟社区的类型的应用，而所述社区中的用户为了应用的目的而进行暂时地交互，该装置的特征在于其包括-所述存在使能的网络(PEN)中的列表管理单元(DBLM)，用于从已经利用该存在使能的网络(PEN)中的应用服务器(AS)对所述应用进行了注册的用户中，创建特定于应用的社区成员(好友)的列表，并且在需要时将所述列表自动地通知其成员；-每个用户设备上的列表客户单元(DBLC)，用于从所述列表管理单元(DBLM)接收一个或多个列表，并与该应用的客户侧合作，以在所述用户设备(UE)上显示所通知的列表。
15.如权利要求14所述的装置，其特征在于，所述列表管理单元(DBLM)通过将成员的别名身份保存在所述列表中来创建列表，当好友注册到应用时用所述别名身份通信。
16.如权利要求14或15所述的装置，其特征在于，所述列表管理单元(DBLM)创建封闭的好友列表或开放的好友列表，所述封闭的好友列表具有包括所有已经注册到应用的用户的固定人数的候选者，而所述开放的好友列表包括满足特定于应用的过滤标准的候选者。
17.如权利要求16所述的装置，其特征在于，所述列表管理单元(DBLM)在候选者的人数出现变化时，创建新的封闭的好友列表。
18.如权利要求16所述的装置，其特征在于，所述列表管理单元(DBLM)基于所述过滤标准，通过添加/删除成员来更新所创建的列表。
19.如权利要求18所述的装置，其特征在于，所述列表管理单元(DBLM)将好友列表递送给满足递送标准的好友。
20.如权利要求19所述的装置，其特征在于，所述递送标准为默认递送标准，并且一旦创建了列表，所述列表管理单元(DBLM)就将好友列表递送给该列表中的所有好友。
21.如权利要求16或19所述的装置，其特征在于，所述过滤标准和所述递送标准与用户的存在信息相关，以及所述列表管理单元(DBLM)利用所述存在使能网络(PEN)中的存在服务器(PS)预定所有候选者的存在信息。
22.如权利要求21所述的装置，其特征在于，所述存在信息与用户状态和/或用户对于特定应用和/或用户位置的可用性有关。
23.如权利要求14所述的装置，其特征在于，所述列表管理单元(DBLM)在将目的成员递送给列表成员时，从该列表中删除该目的成员，并且每个客户单元(DBLC)显示包含该列表中其他好友的别名身份的本地好友列表。
24.如权利要求14所述的装置，其特征在于，所述列表客户单元(DBLC)被配置为主动配置或被动配置，在主动配置中，其可以预定涉及与好友列表管理有关的特定事件的通知，而在被动配置中，其接收如由所述列表管理单元(DBLM)确定的通知。
25.如权利要求24所述的装置，其特征在于，所述列表客户单元(DBLC)利用在所述存在使能网络(PEN)中的存在服务器(PS)预定其他好友的存在信息，并与本地列表一起显示所述存在信息。
26.如权利要求14所述的装置，其特征在于，所述通信系统是移动通信系统。
27.如权利要求26所述的装置，其特征在于，所述列表管理单元(DBLM)与用于管理移动系统用户的存在信息的单元(MPM)中的存在服务器(PS)一起实施，所述存在服务器(PS)与所述存在信息管理单元属于所述存在使能网络(PEN)。
28.如权利要求26所述的装置，其特征在于，所述列表管理单元(DBLM)在应用服务器(AS)中实施，并且借助其在其中担当监视器的存在协议，与在所述存在使能网络(PEN)中的存在服务器进行交互。
29.一种支持存在使能的应用的通信系统，所述存在使能的应用具有在用户设备(UE)上的客户侧(CA)和在连接到所述通信系统的存在使能网络(PEN)中的服务器侧(AS)，所述存在使能的应用是其中该应用的用户(好友)形成随时间变化的虚拟社区的类型的应用，而所述社区中的用户为了应用的目的而进行暂时地交互，该系统的特征在于，所述应用的好友列表在服务器侧利用如权利要求1至13中任何一项所述的方法进行管理。
30.一种支持存在使能的应用的通信系统，所述存在使能的应用具有在用户设备(UE)上的客户侧(CA)和在连接到所述通信系统的存在使能网络(PEN)中的服务器侧(AS)，所述存在使能的应用是其中该应用的用户(好友)形成随时间变化的虚拟社区的类型的应用，而所述社区中的用户为了应用的目的而进行暂时地交互，该系统特征在于，其包括用于执行如权利要求14至28中任何一项所述的在服务器侧管理所述应用的好友列表的装置(DBLM、DBLC)。
31.如权利要求29或30所述的通信系统，其特征在于，该通信系统是移动通信系统。
全文摘要
本发明涉及在通信系统支持的存在使能应用中服务器侧管理联系列表的方法和装置，存在使能应用具有用户设备(UE)上的客户侧(CA)和在可由用户经通信系统访问的存在使能网络(PEN)的服务器侧(AS)，这种应用是其中其用户形成随时间变化的虚拟社区的类型的应用，其中用户为了应用的目的进行暂时交互。该方法包括用户在应用的服务器侧(AS)注册，以提供虚拟社区的候选者；在存在使能网络(PEN)的好友列表管理单元(DBLM)中，从候选者中创建虚拟社区的成员列表(“好友列表”)；由列表管理单元将好友列表通知给社区成员用户设备(UE)中的客户单元(DBLC)；并在每个接收通知列表成员的用户设备(UE)上显示列表。
文档编号H04L29/00GK1684422SQ20051006726
公开日2005年10月19日 申请日期2005年4月14日 优先权日2004年4月14日
发明者多纳特拉·布莱奥塔, 乔范纳·德曾 申请人:西门子移动通讯公司