CN101335634B

CN101335634B - 提供联系人信息的方法、系统及网络设备

Info

Publication number: CN101335634B
Application number: CN2007101295490A
Authority: CN
Inventors: 宋雪飞; 孙谦; 彭程晖
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-06-29
Filing date: 2007-06-29
Publication date: 2011-12-28
Anticipated expiration: 2027-06-29
Also published as: CN101335634A

Abstract

本发明涉及通信技术领域，公开了提供联系人信息的方法、系统及网络设备，其中方法包括：接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；生成与订阅请求消息一对应的订阅请求消息二，将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；若收到来自所联系人信息服务器的所述联系人信息变化的消息，向用户设备信息文件中记录的UE发送所述变化后的联系人信息，用户设备信息文件与公共用户标识对应，用户设备信息文件记录有归属于用户的所有通过注册的用户设备信息；本发明还提供了对应的系统即网络设备，使用本发明可以使用户只需要在一个UE上发送订阅请求，就可以在多个UE上收到通知消息。

Description

提供联系人信息的方法、系统及网络设备

技术领域

本发明涉及通信技术领域，具体涉及提供联系人信息的方法、系统及网络设备。

背景技术

在很多情况下，用户需要获取其联系人的一些相关信息，如联系人的呈现信息、联系人的使用偏好信息等，从而使用户在获取了联系人的相关信息后可以进行相应的操作；但是联系人的相关信息是会改变的，因而用户希望在联系人的相关信息发生改变时，能够尽快获得联系人改变后的相关信息。订阅通知机制就是这样一种解决异步通知问题的有效方法，其基本思想是这样的：用户可以向网络上的一个服务器订阅联系人的相关信息，当联系人的相关信息发生改变时，服务器可以向用户发送相应的通知消息。

目前，订阅通知机制在会话初始协议(SIP：Session Initiation Protocol)服务中有着广泛的应用，例如，在呈现业务中，观察者可以通过订阅通知机制获得呈现体的呈现信息；为了支持订阅通知机制，SIP进行了相应的扩展，定义了会话初始协议订阅(SIP SUBSCRIBE)方法和会话初始协议通知(SIPNOTIFY)方法，在SIP中，订阅通知机制的过程是这样的：

订阅者向通知者发送一个订阅请求消息；订阅请求消息中包括订阅者的相关信息，以及订阅者想订阅的联系人的信息和订阅者想订阅的具体的信息类型；

通知者在收到订阅请求消息后，向订阅者返回一个确认订阅请求的确认消息；

通知者在得知订阅者想订阅的联系人的信息发生改变时，向订阅者发送一个通知消息，该通知消息包括相应的改变后的联系人信息；

订阅者在收到改变后的信息后，向通知者返回一个确认信息；

在实际应用中，订阅者通过某个用户设备(UE：User Equipment)上的用户代理(UA：User Agent)订阅了通知者的呈现信息后，通知就会发送到该UE的UA上。即使当多个UE使用了用户的同一个统一资源标识符(URI：Unified Resource Identify)向网络注册时，如果用户只使用了其中的一个UE订阅了信息，那么通知消息只会发送到该UE上，而不会发送到其他的UE，如果用户想在其他的UE上也能够收到通知消息，则需要在其他的UE上也订阅通知者的呈现信息。

在实现本发明的过程中，发明人发现现有的技术方案至少存在如下缺陷：如果用户需要在每个UE上都收到通知消息，则需要在每个UE上都订阅通知者的呈现信息，增加了用户的处理负担，给用户带来了不必要的麻烦，并且，在UE上发送订阅请求后，UE会定期的发送刷新订阅请求，因而如果每个UE都发送了订阅请求，刷新订阅请求的数量将会非常多，从而造成有限网络资源的极大浪费。

发明内容

本发明实施例的目的是提供一种提供联系人信息的方法、系统及网络设备，使用本发明实施例提供的技术方案，可以使用户只需要在一个UE上发送订阅请求，就可以在多个UE上收到通知消息。

本发明实施例的目的是通过以下技术方案实现的：

本发明实施例提供了一种提供联系人信息的方法，包括：

接收订阅联系人信息的订阅请求消息一，所述订阅请求消息一包括用户的公共用户标识；

生成与所述订阅请求消息一对应的订阅请求消息二，将所述订阅请求消息二发送至与所述联系人信息对应的联系人信息服务器；

若收到来自所述联系人信息服务器的所述联系人信息变化的消息，向用户设备信息文件中记录的用户设备发送所述变化后的联系人信息，所述用户设备信息文件与所述公共用户标识对应，所述用户设备信息文件记录有归属于所述用户的所有通过注册的用户设备信息。

本发明实施例还提供了一种网络设备，包括：

订阅请求消息接收单元，用于接收订阅联系人信息的订阅请求消息一，所述订阅请求消息一包括用户的公共用户标识；

订阅请求消息生成单元，用于生成与所述订阅请求消息一对应的订阅请求消息二；

订阅请求消息发送单元，用于将所述订阅请求消息二发送至与所述联系人信息对应的联系人信息服务器；

联系人信息接收单元，用于接收来自所述联系人信息服务器的所述联系人信息变化的消息；

联系人信息发送单元，用于向用户设备信息文件中记录的用户设备发送所述变化后的联系人信息，所述用户设备信息文件与所述公共用户标识对应，所述用户设备信息文件记录有归属于所述用户的所有通过注册的用户设备信息。

相应的，本发明实施例提供了一种提供联系人信息的系统，包括：

网络设备，接收订阅联系人信息的订阅请求消息一，所述订阅请求消息一包括用户的公共用户标识；生成与所述订阅请求消息一对应的订阅请求消息二，并发送所述订阅请求消息二；

与所述联系人信息对应的联系人信息服务器，用于接收所述订阅请求消息二；若所述联系人信息发生变化，发送变化后的所述联系人信息；

所述网络设备，还用于接收所述变化后的联系人信息；查找所述公共用户标识对应的用户设备，向所述用户设备发送所述变化后的联系人信息。

从本发明实施例提供的以上技术方案可以看出，由于用户或业务服务器只需要发送一次订阅请求消息一，在网络实体发送变化后的联系人信息时，根据用户的URI，向经过注册的归属于该URI的UE返回变化后的联系人信息，从而使用户只需要发送一次订阅请求消息一就可以从多个UE上收取变化后的联系人信息，从而不会给用户带来较大的处理负担；并且，由于只有一个UE或一个业务服务器发送了订阅请求消息，因而刷新订阅请求也只有一个UE或一个业务服务器需要发送，所以刷新订阅请求的数量也是有限的，从而不会过多的占用网络资源。

附图说明

图1为本发明实施例中UE注册过程的流程图；

图2为本发明实施例提供的用户设备信息文件的结构图；

图3为本发明实施例中提供联系人信息的方法实施例一的流程图；

图4为本发明实施例中提供联系人信息的方法实施例二的流程图；

图5为本发明实施例中提供联系人信息的方法实施例三的流程图；

图6为本发明实施例中提供联系人信息的方法实施例四的流程图；

图7为本发明实施例中提供联系人信息的方法实施例五的信令流程图；

图8为本发明实施例中提供联系人信息的方法实施例六的信令流程图；

图9为本发明实施例中网络设备实施例一的结构图；

图10为本发明实施例中网络设备实施例二的结构图；

图11为本发明实施例中网络设备实施例三的结构图；

图12为本发明实施例中网络设备实施例四的结构图；

图13为本发明实施例中网络设备实施例五的结构图；

图14为本发明实施例中提供联系人信息的系统实施例一的结构图。

具体实施方式

为使本发明的目的、技术方案、及优点更加清楚明白，以下参照附图并举实施例，对本发明进一步详细说明。

先介绍本发明实施例提供的UE注册的过程，如图1所示，包括：

步骤101、接收UE的注册通知消息；该注册通知消息包括UE归属的用户公共用户标识；

用户一般会有多个UE，当用户需要通过一个UE去接收网络状态时，则需要先将该UE在网络注册；网络一般都会给用户分配一个公共用户标识，在实际应用中，该公共用户标识可以是URI，在网络中，URI就可以唯一的标识该用户，因而在将该用户的UE进行注册时，要附带该用户的URI，以此标识该UE是归属于该URI的用户；

步骤102、判断注册通知消息的类型；如果是初始注册通知消息，进入步骤103；如果是去注册通知消息，进入步骤106；

当没有经过注册的UE需要注册时，就发送初始注册通知消息，触发网络侧对其注册；而当需要将经过注册的UE解除注册时，则发送去注册通知消息，触发网络侧解除对该UE的注册；在实际应用中，经过注册的UE还要定期的发送刷新注册通知消息，刷新注册通知消息并不会触发网络侧做任何实际操作，刷新注册通知消息的作用是通知网络侧该UE的注册仍然有效，相应的，如果长时间没有收到一个UE的刷新注册消息，则可以对该UE做解除注册处理。

步骤103、判断与URI对应的用户设备信息文件是否存在；如果是，进入步骤104；如果否，进入步骤105；

如果对应于步骤101所述的URI的UE是第一次注册，则与该URI对应的设备信息文件是不会存在的，因而在添加UE的信息之前要对是否存在对应的用户设备信息文件进行判断；

步骤104、在已经存在的用户设备信息文件中添加UE的信息；结束；

步骤105、创建包括该UE的信息的用户设备信息文件；结束；

步骤106、从用户设备信息文件中删除UE的信息；

在实际应用中，如果用户设备信息文件中没有任何UE的信息，可以将该用户设备信息文件删除，从而降低系统负荷，进而提高系统效率。

图2描述了本发明实施例提供的用户设备信息文件的结构，如图2所示，用户设备信息文件201包括用户的URI以及UE信息，其中UE信息还包括用来标识与URI绑定的网络地址的唯一标识，业务服务器可以根据这个唯一标识查找并修改相应的信息；与URI绑定的网络地址信息；与URI绑定的网络地址的状态信息，其值可以为激活或终止，在向多个UE发送联系人信息时，可以根据所述网络地址的状态信息只向状态为激活的UE发送联系人信息，该项为可选项。

在介绍本发明实施例提供的提供联系人信息的方法前，先介绍一下融合地址簿：

融合地址簿是网络设备所提供的一项功能，包括用户设备信息文件以及联系人地址簿，其作用就相当于用户在网络侧的联系人列表，包括用户联系人的一些静态和动态的信息，其中静态信息包括联系人的联系方式、联系人显示名、联系人的个人信息、联系人的爱好等，动态信息包括联系人的呈现信息、联系人的偏好设置、联系人的通信能力等。

以下开始介绍本发明实施例提供的提供联系人信息的方法，如图3所示，提供联系人信息的方法实施例一包括：

步骤301、接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

订阅请求消息一可以来自用户设备即UE，也可以来自业务服务器；当来自UE时，是由用户通过UE主动发送的；当来自业务服务器时，业务服务器是根据用户的用户服务设置信息触发的，用户预先设置一个触发信息，当满足触发信息的条件时就会触发业务服务器发送订阅请求消息一；其中，前述的用户服务设置信息一般情况下保存在业务服务器中，包含一些设置信息，如与融合地址簿相关的设置信息等；

订阅请求消息一包括URI，订阅的联系人的信息可以发送到该URI对应的UE，URI在订阅请求消息一的消息体中传输；其中，联系人的信息可以包括联系人的呈现信息、联系人的用户偏好信息中的一种或几种的组合；

与刷新注册请求相应的，也有刷新订阅请求，刷新订阅请求也可以起到告知服务器订阅请求有效的作用；

步骤302、生成与订阅请求消息一对应的订阅请求消息二；

订阅请求消息二的接收方标识采用订阅请求消息一中所述的URI，因而可以在收到订阅通知后，根据接收方标识中的所述URI查找到对应的UE；

订阅请求消息二是与订阅请求消息一对应的，若订阅请求消息一为一次订阅请求消息，则订阅请求消息二也为一次订阅请求消息；若订阅请求消息一为长期订阅请求消息，相应的订阅请求消息二也为长期订阅请求消息；

进一步，还可以在订阅请求消息二中设置过滤器，因为用户可能只需要订阅某一大类消息中的一种消息，此时在订阅请求消息二中设置过滤器可以确保只返回该种消息，从而可以减少网络流量；

步骤303、将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

根据订阅的联系人信息的不同，订阅请求消息二发送至的联系人信息服务器也不一样，其中，用户信息服务器可以是呈现业务服务器和用户设置偏好服务器等；若订阅的是联系人的呈现信息，则订阅请求消息二发送至呈现业务服务器；若订阅的是联系人的偏好设置信息，则订阅请求消息二发送至用户偏好设置服务器；相应的，如果订阅的是其他的联系人信息，则将订阅请求消息二发送至相应的联系人信息服务器；

步骤304、若从联系人信息服务器收到联系人信息变化的消息，则向用户设备信息文件中记录的UE发送变化后的联系人信息；其中，用户设备信息文件与URI对应，用户设备信息文件记录有归属于该URI的所有已经注册的用户的设备信息；

当联系人信息服务器收到了订阅请求消息二后，若订阅请求消息二订阅的联系人信息发生变化，则所述联系人信息服务器会发送联系人信息发生变化的通知消息，一般情况下，该通知消息会附带变化后的联系人信息及URI信息，该通知消息直接发送给发送订阅请求消息二的网络实体；该网络实体收到通知消息后，就会查找与该URI对应的用户设备信息文件，根据该用户设备信息文件中记录的UE信息向相应的UE发送该变化后的联系人信息；

从上可知，本实施例中，用户或业务服务器只需要发送一次订阅请求消息一，在网络实体发送变化后的联系人信息时，根据用户的URI，向经过注册的归属于该URI的UE返回变化后的联系人信息，从而使用户只需要发送一次订阅请求消息一就可以从多个UE上收取变化后的联系人信息，从而不会给用户带来较大的处理负担；并且，由于只有一个UE或业务服务器发送了订阅请求消息，因而刷新订阅请求也只有一个UE或业务服务器需要发送，所以刷新订阅请求的数量也是有限的，从而不会过多的占用网络资源。

如图4所示，本发明实施例中提供联系人信息的方法实施例二包括：

步骤401、接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

步骤402、生成与订阅请求消息一对应的订阅请求消息二；

步骤403、将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

步骤404、收到来自联系人信息服务器的联系人信息变化的消息；

步骤405、判断用户设备信息文件中记录的UE的状态是否为激活；若是，进入步骤406；若否，结束流程；

在UE向网络侧注册后，即用户设备信息文件中记录了UE的信息后，如果一段时间内没有收到该UE的刷新注册请求，除了直接解除对该UE的注册外，还可以先将该UE的状态改为未激活状态，只有当该UE在未激活状态一段时间后网络侧仍然没有收到刷新注册请求才对该UE解除注册；从而可以避免直接对该UE解除注册，使用户需要重新注册，不会给用户带来过多的麻烦；

步骤406、向状态为激活的UE发送变化后的联系人信息；

从上可知，本方法实施例二与方法实施例一相比进一步包括了对UE的状态是否激活进行判断的过程，并只向状态为激活的UE发送变化后的联系人信息，从而可以减少需要发送的信息量，不仅可以减少对有限网络资源的占用，还降低了对该网络实体的系统资源的占用；同时，因为状态为未激活的UE并不会接收变化后的联系人信息，因而不会对用户造成影响。

如图5所示，本发明实施例中提供联系人信息的方法实施例三包括：

步骤501、接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

步骤502、生成与订阅请求消息一对应的订阅请求消息二；

步骤503、将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

步骤504、收到来自联系人信息服务器的联系人信息变化的消息；

步骤505、判断设备信息文件中记录的UE是否设置为接收变化后的联系人信息；若是，进入步骤506；若否，结束流程；

虽然用户向网络侧注册了多个UE，但是用户可能并不需要在每个UE上都接收变化后的联系人信息，因而可以设置某些UE不接收变化后的联系人信息，因而不仅可以满足用户的需要，还可以减少发送联系人信息时对有限网络资源的占用；此设置的默认值为接收，用户可以对该设置进行修改；具体的修改方法根据具体的实现方式不同可以采取不同的方法，例如，以融合地址簿为例，当融合地址簿采用可扩展标记语言(XML：Extensible MarkupLanguage)文档管理服务器(XDMS：XML Document Management Server)的方式实现时，可以使用XML配置访问协议(XCAP：XML ConfigurationAccess Protocol)的PUT方法进行修改。

步骤506、判断设置为接收变化后的联系人信息的UE的状态是否为激活；若是，进入步骤507；若否，结束流程；

步骤507、向状态为激活的UE发送变化后的联系人信息；

从上可知，本方法实施例三与方法实施例二相比进一步包括了判断UE是否接收变化后的联系人信息的步骤，并只向设置为接收变化后的联系人信息的UE发送变化后的联系人信息，从而可以减少需要发送的信息量，不仅可以减少对有限网络资源的占用，还降低了对该网络实体的系统资源的占用；同时，因为用户并不需要在设置为不接收联系人信息的UE接收变化后的联系人信息，因而不会对用户造成影响。

假设一个用户的URI下注册了两个UE，即用户设备信息文件中记录了两个UE，分别是UE1和UE2，方法流程如图6所示，本发明实施例中提供联系人信息的方法实施例四包括如下步骤，其中联系人信息保存在联系人信息文档中：

步骤601、接收来自UE1的订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

步骤602、触发归属于该URI的UE2订阅联系人信息文档的更新，该联系人信息文档包括UE1订阅的联系人信息；

UE2的信息在用户设备信息文件中有记录，在实际应用中，根据具体的实现方式不同，具体的触发方法也不同，例如，当采用SIP协议时，可以使用REFER参考方法触发用户设备信息文件上的其他设备订阅融合地址簿上联系人信息文档的变化；

步骤603、生成与订阅请求消息一对应的订阅请求消息二；

步骤604、将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

步骤605、收到来自联系人信息服务器的联系人信息变化的消息，更新联系人信息文档；

在实际应用中，因为网络侧会保存每个联系人的信息，例如前述的融合地址簿，当然也可能是其他的实现相似功能的功能实体，其中，联系人信息保存在联系人信息文档中，因而需要更新联系人信息文档，前述的实施例一、实施例二和实施例三在实际应用中也会有更新联系人信息文档这个步骤；

步骤606、向UE1发送变化后的联系人信息；

因为是UE1主动向网络侧订阅联系人信息，所以采用与UE1所采用的订阅方式相对应的方式向UE1发送变化后的联系人信息；

步骤607、向UE2发送联系人信息文档更新的通知；

UE2是被动的向网络侧订阅联系人信息文档的更新，而这个订阅方式可能与UE1所采用的订阅方式不同，因而网络侧根据UE2而所采用的订阅方式，采用相应的通知方式通知UE2联系人信息文档的更新；

在实际应用中，UE2的数量可能会有多个，因为UE1主动订阅了联系人信息，网络侧会单独的向UE1发送变化后的联系人信息，因而在向UE2发送联系人信息文档更新的通知时，不用向UE1发送；

在本实施例中，UE可以接收网络侧的触发信息，被动的订阅联系人信息文档的更新，从而使UE可以做好接收联系人信息更新的通知的准备，从而可以提高UE的处理效率，因而可以满足用户的需要。

图7是本发明实施例中提供联系人信息的方法实施例五的信令流程图，在该实施例中：用户有两个UE分别为UE1和UE2，并使用用户的同一个SIPURI向融合网际协议(IP：Internet Protocol)消息(CPM：Converged IPMessaging)业务引擎注册，CPM业务引擎收到注册请求完成注册过程后将UE1和UE2的设备信息更新到融合地址簿(CAB：Converged Address Book)的设备列表中，当用户使用UE1通过CAB订阅了某个联系人的服务能力或用户偏好后，CAB根据设备列表将来自呈现服务器或用户偏好设置服务器的信息更新到用户的UE2中，具体过程如下：

步骤701、用户使用UE1向CPM业务引擎注册；

具体过程为：(1)用户使用UE1通过SIP REGISTER请求向IP多媒体子系统(IMS：IP Multimedia Subsystem)网络的服务呼叫会话控制功能(S-CSCF：Serving Call Session Control Function)注册；(2)注册成功，S-CSCF向UE1返回200 ok的成功响应；(3)S-CSCF根据初始过滤规则(IFC)向CPM业务引擎发起注册；(4)注册成功，CPM业务引擎向S-CSCF返回200 ok的成功响应；(5)S-CSCF根据CPM业务引擎订阅的注册事件，向CPM业务引擎发送通知消息；(6)CPM业务引擎收到通知后返回200 ok的成功响应；

进一步，以XML实现方式为例，第(5)步中通知消息体包括如下信息：

</contact>

步骤702、CPM业务引擎向CAB写UE1的信息；

具体过程为：CPM业务引擎根据通知消息体中<contact>元素的“state”属性值和“event”属性值判断用户是初次注册，获得与用户的公共SIP URI绑定的contact地址(例如：sip：1.8.27.2.1618.27.2.56：5060)，并通过XCAP协议的PUT方法将此信息添加到保存在CAB中用户的设备列表中；使用XCAP协议的PUT方法在CAB中创建用户的设备信息文件的消息实例可以包括<deviceinfo>元素，具体如下：

<deviceinfo xmlns＝″urn:ietf:params:xml:ns:device-lists″

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>

</contact>

</deviceinfo>

<deviceinfo>元素是设备信息文件的根元素，表示这个文件描述的是设备信息，<deviceinfo>根元素包含一个<devicelist>和一个或多个<contact>元素，其中<devicelist>元素有一个必选的aor属性，其值为用户的公共SIP URI，用来表示此设备列表属于哪一个用户，<contact>元素用来表示用户所使用设备当前的contact地址，他包含两个属性，分别为id属性和state属性，其中id属性用来唯一的标识这个contact地址其值与CPM业务引擎收到的注册事件通知消息体中<contact>元素的id属性值一致，state属性用来表示这个contact地址的注册状态，其值可以是：active、terminated，此外，<contact>元素还包含一个<uri>子元素，其值为一个SIP URI，即用户UE1的当前contact地址；优选的，还可以包含指示某个设备是否接收联系人信息变化的设置信息；

进一步，CPM业务引擎根据通知消息的消息体中的内容判断如何处理的过程如下：

如果收到的通知消息中<contact>元素的“state”属性值为“active”，并且“event”属性的值为“register”或“created”，则用户的此次注册为初始注册，CPM业务引擎通过XCAP协议的PUT方法向CAB中的用户设备信息文件中添加与用户的公共SIP URI绑定的contact地址信息和id属性，如果在CAB中，用户的设备信息文件不存在，则创建包含与用户的公共SIP URI绑定的contact地址信息和id属性的设备信息文件；

如果收到的通知消息中<contact>元素的“state”属性值为“active”，并且“event”属性的值为“refreshed”或“shortened”，则用户的注册为刷新注册，不需要更改CAB中用户设备信息文件的内容；

如果收到的通知消息中<contact>元素的“state”属性值为“terminated”，则用户的此次注册为去注册请求，CPM业务引擎通过XCAP协议的DELETE方法删除用户设备信息文件中<contact>元素的id属性值与此通知消息中的<contact>元素的id属性值相同的<contact>元素及其子元素，或将此<contact>元素的“state”属性值改为“terminated”；

步骤703、创建成功，CAB向CPM业务引擎返回成功响应，该成功响应可以为201 Created消息；

步骤704、用户使用UE2向CPM业务引擎注册；

用户使用与前述步骤701相同的公共SIP URI(sip；user1example.com)通过UE2向CPM业务服务引擎注册，具体的过程如步骤701所描述；

步骤705、CPM业务引擎向CAB写UE2的信息；

CPM业务引擎根据通知中的信息，获得UE2的contact地址：sip：1.8.27.2.1728.27.2.56：5060(CPM业务引擎从通知消息中获取与用户的公共SIP URI绑定的UE2的contact地址的方法与步骤2所述的方法相同)，并通过XCAP协议的PUT方法将此信息添加到保存在CAB中用户的设备列表中，进一步，还可以包含指示某个设备是否接收联系人信息变化的设置信息；

步骤706、创建成功，CAB向CPM业务引擎返回成功响应；

步骤707、用户通过UE1发起订阅联系人呈现信息和用户偏好信息的请求，该请求作为订阅请求消息一；

一种使用SIP协议订阅(SUBSCRIBE)方法描述订阅请求消息一的具体实例如下：

SUBSCRIBE sip:cabexample.com SIP/2.0

Via:SIP/2.0/TCP ue1.example.com；branch＝z9hG4bKwYb6QREiCL

Max-Forwards:70

To:cab<sip:cabexample.com>

From:<sip:user1example.com>；tag＝ie4hbb8t

Call-ID:cdB34qLToCterminal.example.com

CSeq:1SUBSCRIBE

Contact:<sip:ue1.example.com>

Content-Type:application/res-lists+xml

Event:contactinfo

Expires:7200

<？xml version＝″1.0″encoding＝″UTF-8″？>

<resource-lists xmlns＝″urn:ietf:params:xml:ns:cab-lists″

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>

<list>

</list>

</resource-lists>

上述订阅请求消息一的消息体为一个联系人列表，指明用户要订阅哪些联系人的联系信息，Request-URI的值为融合地址簿的SIP URI其Content-Type头字段值为application/res-lists+xml。

步骤708、订阅成功CAB向UE1返回200 ok的成功响应；

步骤709、CAB根据收到的订阅请求消息向呈现业务服务器订阅所述联系人(sip：billexample.com)的呈现信息，具体的通过发送订阅请求消息二向呈现业务服务器订阅；

在实际应用中，可以在订阅请求消息二中添加仅订阅联系人部分信息的过滤器，一种包含在订阅请求消息中，使用XML描述的过滤器的具体实例如下：

SUBSCRIBE sip:cabexample.com SIP/2.0

Via:SIP/2.0/TCP ue1.example.com；branch＝z9hG4bKwYb6QREiCL

Max-Forwards:70

To:cab<sip:cabexample.com>

From:<sip:user1example.com>；tag＝ie4hbb8t

Call-ID:cdB34qLToCterminal.example.com

CSeq:1SUBSCRIBE

Contact:<sip:ue1.example.com>

Content-Type:multipart/mixed；boundary＝unique-boundary-1

Event:contactinfo

Expires:7200

--unique-boundary-1

Content-Type:application/cab-lists+xml

……

<？xml version＝″1.0″encoding＝″UTF-8″？>

<resource-lists xmlns＝″urn:ietf:params:xml:ns:cab-lists″

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>

<list>

</list>

</resource-lists>

--unique-boundary-1

Content-Type:application/simple-filter+xml

Event:presence

……

<？xml version＝″1.0″encoding＝″UTF-8″？>

<filter-set xmlns＝″urn:ietf:params:xml:ns:simple-filter″>

<ns-bindings>

<ns-binding prefix＝″pidf″urn＝″urn:ietf:params:xml:ns:pidf″/>

<ns-binding prefix＝″rpid″

urn＝″urn:ietf:params:xml:ns:pidf:rpid-tuple″/>

</ns-bindings>

<what>

/pidf:presence/pidf:tuple[rpid:class＝″CPM″]/pidf:servcaps

</include>

</what>

</filter>

</filter-set>

--unique-boundary-1

上述SIP消息的Content-Type头字段值指示此SIP消息中包含两个消息体，一部分指明此SIP SUBSCRIBE请求要订阅哪些联系人的呈现信息，一部分指明订阅这些联系人的哪一部分呈现信息；其中，该过滤器可以是用户自己设置通过订阅请求消息一传送的，因为订阅请求消息一中有过滤器，所以需要在订阅请求消息二中设置同样的过滤器；该过滤器还可以是预先设置在CAB上的，当收到订阅请求消息一后，判断订阅请求消息一所订阅的联系人信息，如果符合预先设定的条件，则将该过滤器加到订阅请求消息二中；通过在订阅请求消息二中增加该过滤器，可以使联系人信息服务器仅返回该过滤器允许返回的联系人信息；

步骤710、订阅成功返回200 ok的成功响应；

步骤711、呈现业务服务器向CAB发送联系人呈现信息的通知；

呈现业务服务器可以通过SIP协议的NOTIFY方法向CAB发送SIP URI为sip：billexample.com的联系人的呈现信息；

步骤712、CAB收到联系人呈现信息的通知消息后向呈现业务服务器返回200 ok的成功响应，并根据收到的通知消息更新用户的联系人列表中标识为sip：billexample.com的联系人信息；

步骤713、CAB向用户偏好服务器订阅联系人的用户偏好信息，也是通过发送订阅请求消息二向用户偏好服务器订阅；

步骤714、订阅成功返回200 ok的成功响应；

步骤715、用户偏好服务器向CAB发送联系人的用户偏好通知，用户偏好服务器可以通过SIP协议NOTIFY通知方法向CAB发送此联系人的用户偏好信息；

步骤716、CAB向用户偏好服务器返回200 ok的成功响应，并根据收到的通知消息更新用户的联系人列表中标识为sip：billexample.com的联系人信息；

步骤717、CAB通过SIP协议的NOTIFY方法将步骤711和步骤715中消息发送给UE1；

步骤718、UE1收到消息后返回200 ok的成功响应；

步骤719、CAB解析用户设备信息文件，查找其他UE；本实施例中能够查到UE2；

步骤720、CAB将联系人信息的变化发送给UE2，具体的可以使用同步标记语言(SyncML：Synchronization Markup Language)技术，或使用SIP消息(MESSAGE)方法；

步骤721、UE2返回成功响应；

从上可知，本实施例中用户通过UE1向CAB发送订阅联系人信息的订阅请求，CAB在获知联系人信息更新后，除了向UE1发送联系人信息更新的通知，还向与UE1具有相同URI的UE2发送联系人信息更新的信息，从而使用户只需要发送一次订阅请求消息就可以从UE1和UE2上收取变化后的联系人信息，从而不会给用户带来较大的处理负担；并且，由于只有UE1发送了订阅请求消息，因而也只有UE1发送刷新订阅请求，所以刷新订阅请求的数量也是可以有限的，不会过多的占用有限的网络资源。

图8是本发明实施例中提供联系人信息的方法实施例六的信令流程图，在该实施例中：CPM业务引擎收到注册请求完成注册过程后将UE1和UE2的设备信息更新到CAB的设备列表中，当用户使用UE1通过CAB订阅了某个联系人的服务能力或用户偏好后，CAB根据用户设备信息文件触发UE2订阅融合地址簿上联系人信息文档的变化，融合地址簿收到所述联系人呈现信息或用户偏好信息变化的通知消息后更新此联系人的信息，然后向UE2发送融合地址簿上联系人信息文档变化的通知；具体过程如下：

步骤801、用户通过UE1根据本地联系人列表使用SIP协议的SUBSCRIBE方法向CAB发起订阅联系人信息的订阅请求，请求订阅联系人的服务能力信息和用户偏好信息，该订阅请求可以为订阅请求消息一；

步骤802、订阅成功CAB向UE1返回200 ok的成功响应；

步骤803、CAB根据收到的订阅请求消息向呈现业务服务器订阅联系人的服务能力；服务能力是呈现信息的一部分，所以向呈现业务服务器发订阅请求，该订阅请求为订阅请求消息二；

步骤804、订阅成功返回200 ok的成功响应；

步骤805、呈现业务服务器向CAB发送联系人服务能力信息的通知；

步骤806、CAB收到联系人呈现信息的通知消息后向呈现业务服务器返回200 ok的成功响应；

步骤807、CAB向用户偏好服务器订阅联系人的用户偏好信息，具体的通过向用户偏好服务器发送订阅请求消息二订阅联系人的用户偏好信息；

步骤808、订阅成功返回200 ok的成功响应；

步骤809、用户偏好服务器向CAB发送联系人的用户偏好信息通知，用户偏好服务器可以通过SIP协议NOTIFY方法向CAB发送联系人的用户偏好信息；

步骤810、CAB向用户偏好服务器返回200 ok的成功响应；

步骤811、CAB使用REFER方法触发UE2订阅CAB上用户联系人信息文档的变化，RERFER消息的To头域值为与UE2绑定的IP地址，From头域值为CAB的SIP URI，Refer-to头域指明用户的联系人信息文档，其method参数为SUBSCRIBE，以指明UE2产生的动作，此RERFER消息采用XML实现的实例如下所示：

REFER sip:1.8.27.2.1728.27.2.56:5060SIP/2.0

Via:SIP/2.0/UDP cab.example.com；branch＝z9hG4bK2293940223

To:<sip:1.8.27.2.1728.27.2.56:5060>

From:<sip:cabexample.com>；tag＝193402342

Call-ID:898234234example.com

CSeq:93809823 REFER

Max-Forwards:70

Refer-To:sip:cabexample.com method＝SUBSCRIBE

Contact:sip:cabexample.com

Content-Length:0

其中在上述SIP消息的实例中可以在Refer-To头字段中指明UE2的订阅请求发送是发送到CAB的，在method参数值中指明UE2应发起SIPSUBSCRIBE消息；

步骤812、UE2返回202 Accepted响应；

步骤813、UE2向CAB发送NOTIFY消息；

步骤814、CAB向UE2返回200 ok的成功响应；

步骤815、UE2产生SUBSCRIBE请求消息订阅CAB上用户联系人信息文档的变化；

步骤816、订阅成功CAB向UE2返回200 ok的成功响应；

步骤817、CAB向UE2发送NOTIFY消息；

步骤818、UE2向CAB返回200 ok的成功响应；

步骤819、UE2向CAB发送订阅状态终止的通知消息；

步骤820、CAB向UE2返回200 ok的成功响应；

步骤821、CAB通过SIP协议的NOTIFY方法将步骤805和步骤809中的消息发送给UE1；

步骤822、UE1收到消息后返回200 ok的成功响应；

从上可知，本实施例中UE2接收CAB的触发信息，被动的订阅联系人信息文档的更新，从而使UE2在接收来自CAB的联系人信息更新的通知时，已经做好了接收该通知的准备，提高了UE2的处理速度，可以进一步满足用户的需要。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：

接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

生成与订阅请求消息一对应的订阅请求消息二，将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

若收到来自联系人信息服务器的所述联系人信息变化的消息，向用户设备信息文件中记录的UE发送变化后的联系人信息，用户设备信息文件与URI对应，用户设备信息文件记录有归属于用户的所有通过注册的UE信息；

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

本发明实施例还提供了一种网络设备，该网络设备可以实现前述的融合地址簿的功能，如图9所示，网络设备的实施例一包括：

订阅请求消息接收单元901，用于接收订阅联系人信息的订阅请求消息一，其中订阅请求消息一包括用户的URI；

订阅请求消息生成单元902，用于生成与订阅请求消息一对应的订阅请求消息二；

订阅请求消息发送单元903，用于将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

联系人信息接收单元904，用于接收来自联系人信息服务器的所述联系人信息变化的消息；

联系人信息发送单元905，用于向用户设备信息文件中记录的UE发送变化后的联系人信息，用户设备信息文件与URI对应，用户设备信息文件记录有归属于该用户的所有通过注册的UE信息；

从上可知，本实施例中，用户或业务服务器只需要发送一次订阅请求消息一，在网络实体发送变化后的联系人信息时，根据用户的URI，向经过注册的归属于该URI的UE返回变化后的联系人信息，从而使用户只需要发送一次订阅请求消息一就可以从多个UE上收取变化后的联系人信息，从而不会给用户带来较大的处理负担；并且，由于只有一个UE或业务服务器发送了订阅请求消息，因而刷新订阅请求也只有一个UE或业务服务器需要发送，所以刷新订阅请求的数量也是可以有限的，从而不会过多的占用有限的网络资源。

进一步，提供了网络设备的实施例二，如图10所示，包括：

订阅请求消息接收单元1001，用于接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

订阅请求消息生成单元1002，用于生成与订阅请求消息一对应的订阅请求消息二；

订阅请求消息发送单元1003，用于将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

联系人信息接收单元1004，用于接收来自联系人信息服务器的联系人信息变化的消息；

激活状态判断单元1005，用于在联系人信息接收单元接收联系人信息变化的消息后，判断用户设备信息文件中记录的UE的状态是否为激活；其中，用户设备信息文件与URI对应，用户设备信息文件记录有归属于用户的所有通过注册的UE信息；

联系人信息发送单元1006，用于向激活状态判断单元判断为激活的UE发送变化后的联系人信息；

从上可知，本实施例与网络设备实施例一相比进一步包括了对UE是否激活进行判断的激活状态判断单元，并只向状态为激活的UE发送变化后的联系人信息，从而可以减少需要发送的信息量，不仅可以减少对有限网络资源的占用，还降低了对向UE发送变化后的联系人信息的网络实体的系统资源占用；同时，因为状态为未激活的UE并不会接收变化后的联系人信息，因而不会对用户造成影响。

进一步，提供了网络设备的实施例三，如图11所示，包括：

订阅请求消息接收单元1101，用于接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

订阅请求消息生成单元1102，用于生成与订阅请求消息一对应的订阅请求消息二；

订阅请求消息发送单元1103，用于将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

联系人信息接收单元1104，用于接收来自联系人信息服务器的联系人信息变化的消息；

接收设置判断单元1105，用于在联系人信息接收单元接收联系人信息变化的消息后，判断用户设备信息文件中记录的UE是否设置为接收变化后的联系人信息；其中，用户设备信息文件与URI对应，用户设备信息文件记录有归属于用户的所有通过注册的UE信息；

激活状态判断单元1106，用于在接收设置判断单元判断UE设置为接收变化后的联系人信息时，判断UE的状态是否为激活；

联系人信息发送单元1107，用于向激活状态判断单元判断为激活，且设置为接收变化后的联系人信息的UE发送变化后的联系人信息；

从上可知，本实施例与网络设备实施例二相比进一步包括了判断UE是否接收变化后的联系人信息的接收设置判断单元，并只向设置为接收变化后的联系人信息的UE发送变化后的联系人信息，从而可以减少需要发送的信息量，不仅可以减少对有限网络资源的占用，还降低了对向UE发送变化后的联系人信息的网络实体的系统资源占用；同时，因为用户并不需要在设置为不接收联系人信息的UE接收变化后的联系人信息，因而不会对用户造成影响。

进一步，提供了网络设备的实施例四，如图12所示，包括：

订阅请求消息接收单元1201，用于接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

订阅请求消息生成单元1202，用于生成与订阅请求消息一对应的订阅请求消息二；

订阅请求消息发送单元1203，用于将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

联系人信息接收单元1204，用于接收来自联系人信息服务器的联系人信息变化的消息；

联系人信息发送单元1205，用于向用户设备信息文件中记录的UE发送变化后的联系人信息，用户设备信息文件与URI对应，用户设备信息文件记录有归属于用户的所有通过注册的UE信息；

联系人信息文档更新单元1206，用于在联系人信息接收单元接收联系人信息变化的消息后，更新包括联系人信息的联系人信息文档；

从上可知，本实施例与网络设备实施例一相比还包括更新联系人信息文档的联系人信息文档更新单元，通过对联系人信息文档的更新，可以保证网络侧保存的联系人信息与联系人的真实信息保持一致。

在实际应用中，网络设备在收到订阅请求后，可以触发发送订阅请求外的UE订阅联系人信息文档的更新，假设由UE1发送订阅请求，相应的提供了网络设备的实施例五，如图13所示，包括：

订阅请求消息接收单元1301，用于接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；

订阅请求消息生成单元1302，用于生成与订阅请求消息一对应的订阅请求消息二；

订阅请求发送单元1303，用于将订阅请求消息二发送至与联系人信息对应的联系人信息服务器；

联系人信息接收单元1304，用于接收来自联系人信息服务器的联系人信息变化的消息；

联系人信息文档更新单元1305，用于在联系人信息接收单元接收联系人信息变化的消息后，更新包括联系人信息的联系人信息文档；

触发单元1306，用于在订阅请求接收单元接收订阅请求消息一后，触发用户设备信息文件记录的UE中除UE1外的UE，订阅联系人信息文档的更新；

联系人信息发送单元1307，用于在订阅请求消息接收单元接收了订阅请求消息一后，向订阅了联系人信息文档更新的UE和发送订阅请求消息一的UE1，发送变化后的联系人信息；

在本实施例中，UE可以接收网络侧的触发信息，被动的订阅联系人信息文档的更新，从而使UE可以做好准备以接收联系人信息更新的通知，从而可以提高UE的处理效率，因而可以满足用户的需要。

本发明实施例进一步提供了提供联系人信息的系统，如图14所示，本发明实施例中提供联系人信息的系统实施例一包括：

网络设备1401，接收订阅联系人信息的订阅请求消息一，订阅请求消息一包括用户的URI；生成与订阅请求消息一对应的订阅请求消息二，并发送订阅请求消息二；

该网络设备可以使用本发明实施例中网络设备的实施例，具有融合地址簿的功能；

与联系人信息对应的联系人信息服务器1402，用于接收订阅请求消息二；若联系人信息发生变化，发送变化后的联系人信息；

其中，联系人信息服务器是提供联系人信息的服务器，根据用户所订阅的联系人信息的不同，对应的联系人信息服务器也不同，因为不同的联系人信息服务器提供不同的联系人信息，例如呈现业务服务器为用户提供联系人的呈现信息，用户偏好设置服务器为用户提供联系人的偏好设置服务，通用服务订阅服务器为用户提供联系人订阅何种增值服务的信息等；

网络设备1401，还用于接收变化后的联系人信息；查找与URI对应的UE，向UE发送变化后的联系人信息；

从上可知，本实施例中，网络设备只接收一次订阅请求消息一，在网络实体发送变化后的联系人信息时，根据用户的URI，向经过注册的归属于该URI的UE返回变化后的联系人信息，从而只需要发送一次订阅请求消息一就可以让用户从多个UE上收取变化后的联系人信息，从而不会给用户带来较大的处理负担；并且，由于只有一个UE或业务服务器发送了订阅请求消息，因而刷新订阅请求也只有一个UE或业务服务器需要发送，所以刷新订阅请求的数量也是可以有限的，从而不会过多的占用有限的网络资源。

本发明实施例进一步提供了提供联系人信息的系统实施例二，本实施例二与系统实施例一相比进一步包括：

至少一个UE，用于接收变化后的联系人信息；

在实际应用中，若网络设备具有融合地址簿的功能，为了保证用户能够通过UE对融合地址簿上的信息进行操作，因而UE与现有的UE相比会增加融合地址簿操作单元，通过融合地址簿操作单元，用户可以对融合地址簿上文件记录的联系人信息进行添加、删除、修改等操作；具体如何操作根据融合地址簿的实现方式不同而不同，例如，当融合地址簿采用XDMS方式现实时，融合地址簿客户端可以是XCAP客户端，当融合地址簿采用数据同步服务器实现时，融合地址簿客户端可以采用数据同步客户端实现。

其中，在本发明实施例的系统实施例一和二中，订阅请求消息一可以由用户通过UE发送，也可以由业务服务器发送；

若订阅请求消息一由业务服务器发送，本发明提供的系统实施例可以进一步包括发送订阅请求消息一的业务服务器。

从上可知，使用本发明实施例提供的技术方案，用户或业务服务器只需要发送一次订阅请求消息一，在网络实体发送变化后的联系人信息时，根据用户的URI，向经过注册的归属于该URI的UE返回变化后的联系人信息，从而使用户只需要发送一次订阅请求消息一就可以从多个UE上收取变化后的联系人信息，从而不会给用户带来较大的处理负担；并且，由于只有一个UE或业务服务器发送了订阅请求消息，因而刷新订阅请求也只有一个UE或业务服务器需要发送，所以刷新订阅请求的数量也是可以有限的，从而不会过多的占用有限的网络资源；进一步，可以对UE是否激活进行判断，并只向状态为激活的UE发送变化后的联系人信息，从而可以减少需要发送的信息量，不仅可以减少对有限网络资源的占用，还降低了对向UE发送变化后的联系人信息的网络实体的系统资源占用；同时，因为状态为未激活的UE并不会接收变化后的联系人信息，因而不会对用户造成影响；进一步，还可以判断UE是否接收变化后的联系人信息，并只向设置为接收变化后的联系人信息的UE发送变化后的联系人信息，从而可以减少需要发送的信息量，不仅可以减少对有限网络资源的占用，还降低了对向UE发送变化后的联系人信息的网络实体的系统资源占用；同时，因为用户并不需要在设置为不接收联系人信息的UE接收变化后的联系人信息，因而不会对用户造成影响；在本发明实施例中，UE可以接收网络侧的出发信息，被动的订阅联系人信息文档的更新，从而使UE可以做好接收联系人信息更新的通知的准备，从而可以提高UE的处理效率，因而可以满足用户的需要。

以上对本发明实施例所提供的一种提供联系人信息的方法、系统及网络设备进行了详细介绍，以上实施例的说明只是用于帮助理解本发明的方法及其思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施例及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种提供联系人信息的方法，其特征在于，包括：

2.如权利要求1所述的提供联系人信息的方法，其特征在于，向用户设备信息文件中记录的用户设备发送变化后的所述联系人信息前进一步包括：

判断所述用户设备的状态是否为激活；

若是，进入向用户设备信息文件中记录的用户设备发送变化后的所述联系人信息的步骤。

3.如权利要求1所述的提供联系人信息的方法，其特征在于，向用户设备信息文件中记录的用户设备发送变化后的所述联系人信息前进一步包括：

判断所述用户设备是否设置为接收变化后的联系人信息；

4.如权利要求1至3任一所述的提供联系人信息的方法，其特征在于，进一步在所述订阅请求消息二中设置仅订阅联系人部分信息的过滤器；

来自所述联系人信息服务器的所述联系人信息变化的消息为所述联系人部分信息变化的消息。

5.如权利要求1至3任一所述的提供联系人信息的方法，其特征在于，所述联系人信息保存在联系人信息文档中，收到来自所述联系人信息服务器的所述联系人信息变化的消息后进一步包括：

更新包括所述联系人信息的所述联系人信息文档。

6.如权利要求1所述的提供联系人信息的方法，其特征在于，接收订阅联系人信息的订阅请求消息一后进一步包括：

触发所述用户设备信息文件记录的用户设备订阅所述联系人信息文档的更新；

所述向用户设备信息文件中记录的用户设备发送变化后的所述联系人信息具体为：

向所述订阅了所述联系人信息文档的更新的用户设备发送所述联系人信息文档更新的通知。

7.如权利要求6所述的提供联系人信息的方法，其特征在于，若所述订阅请求消息一由用户设备一发送，所述订阅了所述联系人信息文档的更新的用户设备不包括所述用户设备一。

8.如权利要求1所述的提供联系人信息的方法，其特征在于，所述用户设备在所述用户设备信息文件中注册具体为：

接收用户设备的注册通知消息，所述注册通知消息包括所述用户设备归属的用户的公共用户标识；

若所述注册通知消息为初始注册通知消息，判断与所述公共用户标识对应的用户设备信息文件是否存在，若是，在所述存在的用户设备信息文件中添加所述用户设备的信息；若否，创建包括所述用户设备的信息的用户设备信息文件；

若所述注册通知消息为去注册通知消息，从所述用户设备信息文件中删除所述用户设备的信息。

9.如权利要求8所述的提供联系人信息的方法，其特征在于，若删除了所述用户设备的信息的用户设备信息文件没有任何用户设备的信息，删除所述用户设备信息文件。

10.如权利要求1所述的提供联系人信息的方法，其特征在于，所述订阅请求消息一由用户设备发送、或由业务服务器根据用户的服务设置发送。

11.一种网络设备，其特征在于，包括：

12.如权利要求11所述的网络设备，其特征在于，还包括：

激活状态判断单元，用于判断所述用户设备信息文件中记录的用户设备的状态是否为激活；

所述联系人信息发送单元，用于向所述激活状态判断单元判断为激活的用户设备发送变化后的联系人信息。

13.如权利要求11所述的网络设备，其特征在于，还包括：

接收设置判断单元，用于判断所述用户设备信息文件中记录的用户设备是否设置为接收变化后的联系人信息；

所述联系人信息发送单元，用于向所述接收设置判断单元判断为设置为接收变化后的联系人信息的用户设备，发送变化后的联系人信息。

14.如权利要求11至13任一所述的网络设备，其特征在于，所述联系人信息保存在联系人信息文档中，该网络设备还包括：

联系人信息文档更新单元，用于在所述联系人信息接收单元接收所述联系人信息变化的消息后，更新包括所述联系人信息的联系人信息文档。

15.如权利要求14所述的网络设备，其特征在于，所述订阅请求消息一由用户设备一发送，所述网络设备还包括：

触发单元，用于触发所述用户设备信息文件记录的用户设备中除用户设备一外的用户设备，订阅所述联系人信息文档的更新；

所述联系人信息发送单元，用于向所述订阅了所述联系人信息文档更新的用户设备和所述用户设备一，发送变化后的联系人信息。

16.一种提供联系人信息的系统，其特征在于，包括：

所述网络设备，还用于接收所述变化后的联系人信息；查找所述公共用户标识对应的用户设备，向所述用户设备发送所述变化后的联系人信息，所述用户设备为与所述公共用户标识对应的用户设备信息文件中记录的归属于所述用户的所有通过注册的用户设备。

17.如权利要求16所述的提供联系人信息的系统，其特征在于，还包括：

至少一个用户设备，所述用户设备用于接收所述变化后的联系人信息。

18.如权利要求17所述的提供联系人信息的系统，其特征在于，所述订阅请求消息一由所述用户设备中的用户设备一发送。

19.如权利要求16或17所述的提供联系人信息的系统，其特征在于，还包括：

业务服务器，用于发送所述订阅请求消息一。