融合地址本的方法及融合地址本服务器

暂无

融合地址本的方法及融合地址本服务器\n技术领域\n[0001] 本发明涉及通信技术，尤其涉及融合地址本的方法及融合地址本服务器。\n背景技术\n[0002] 随着移动通信技术和计算机技术的发展，人们可以通过移动通信终端、计算机将联系人的联系方式记录在移动通信终端上或计算机的存储介质上。\n[0003] 一般来说，人们可以使用地址本记录联系人的联系方式。地址本是一种记录联系人联系方式的列表。地址本方便了人与人之间的通信与沟通，其功能和容量也随着移动通信业务的丰富而不断增强和增加，例如，地址本可以提供联系人的呈现信息、联系人的群组和分类等功能。随着移动通信业务的发展，运营商也在网络上为用户保存相应的地址本，以便用户无论使用什么样的终端，都可以从网络上获取联系人的信息。例如现有的个人信息管理(PIM，Personal Information Management)业务提供的对个人信息进行管理的业务、呈现业务提供的共享XML文档管理(SHARE XDM，Share XMLDocument Management)等。\n[0004] 但是，现有的保存在网络上的地址本的功能比较单一，保存的信息有限，这样，提供给用户的信息就会很有限。例如，PIM业务提供的是在网络上提供用户个人信息的备份、同步、更新、管理功能，没有呈现信息，而且保存的联系人的信息只能由地址本的归属人更新，而不能随联系人的信息更新而自动更新。再例如，现有的呈现使能地址本只提供联系人的姓名和在线状态等，如果用户希望地址本能够展现更多有用的信息，例如联系人的终端能力、业务能力、个人偏好等信息，则无法实现。\n[0005] 为使提供给用户的地址本信息更加丰富，一种方法是用户终端的呈现业务客户端和共享XML文档管理客户端分别与呈现服务器和共享XML文档管理服务器进行交互，分别获得联系人的信息后，用户终端可以将呈现业务信息及联系人的信息展现给用户。\n[0006] 但是，发明人仔细研究后发现，网络侧虽然能够向客户端提供联系人的更多的信息，但由于这些信息的格式并不完全相同，所以有些信息都是相互独立的，这样，客户端展现给用户的也是相互独立的信息，所以会影响用户对地址本信息的体验。\n发明内容\n[0007] 本发明实施例要解决的技术问题在于提供一种融合地址本的方法、提供联系人信息的方法、管理联系人信息的方法、融合地址本(CAB Server，Converged Address Book Server)服务器、融合地址本系统及客户端，以尽量不因为展现给用户的联系人的信息都是独立的形式，而影响用户对地址本信息的体验。\n[0008] 为解决上述技术问题，本发明实施例提供一种网络侧融合地址本的方法，包括：获得用户的联系人的静态信息和动态信息，其中，所述静态信息为在规定的时间内不发生变化的信息，所述动态信息为在规定的时间内发生变化的信息；融合联系人的静态信息和动态信息；将融合后的联系人的信息提供给用户使用的所有或部分终端。\n[0009] 本发明实施例提供一种融合地址本服务器，包括：信息获得单元，用于获得用户的联系人的静态信息和动态信息，其中，所述静态信息为在规定的时间内不发生变化的信息，所述动态信息为在规定的时间内发生变化的信息；信息融合单元，用于融合信息获得单元获得的联系人的静态信息和动态信息；信息提供单元，用于将信息融合单元融合后的联系人的信息提供给用户使用的所有或部分终端。\n[0010] 本发明实施例提供一种融合地址本系统，包括：融合地址本服务器，用于融合联系人的静态信息和动态信息，当客户端请求提供联系人的信息时，向所述客户端提供融合后的联系人的信息，并根据所述客户端管理联系人信息的请求，对联系人的信息进行管理；至少一个业务服务器，用于当所述融合地址本服务器需要联系人的静态信息及动态信息和/或需要用户的个人信息时，向所述融合地址本服务器提供联系人的静态信息及动态信息和/或提供用户的个人信息。\n[0011] 在本发明的实施例中，由于网络侧存储或提供给用户的联系人信息都是融合了联系人的静态信息和动态信息，所以，避免了静态信息和动态信息以独立的形式展现给用户，从而不会影响用户对地址本信息的体验。\n附图说明\n[0012] 图1A为本发明实施例的一种网络侧融合地址本的方法流程图；\n[0013] 图1B为本发明实施例的一种融合地址本服务器的结构示意图；\n[0014] 图1C为本发明实施例的一种融合地址本客户端的结构示意图；\n[0015] 图2为本发明的呈现业务网络结构的第一优选示意图；\n[0016] 图3为本发明实施例的融合地址本服务器的结构示意图；\n[0017] 图4为本发明实施例的存储单元保存的信息示意图；\n[0018] 图5为本发明实施例的融合地址本服务器向终端更新信息的流程图；\n[0019] 图6为本发明第一方法实施例的流程图；\n[0020] 图7为本发明实施例的用户订阅远端的联系人的信息时远端进行相关处理的第一流程图；\n[0021] 图8为本发明的呈现业务网络结构的第二优选示意图；\n[0022] 图9为本发明第二方法实施例的流程图；\n[0023] 图10为本发明实施例的用户订阅远端的联系人的信息时远端进行相关处理的第二流程图；\n[0024] 图11为本发明的呈现业务网络结构的第三优选示意图；\n[0025] 图12为本发明第三方法实施例的流程图；\n[0026] 图13为本发明实施例的用户订阅远端的联系人的信息时远端进行相关处理的第三流程图。\n具体实施方式\n[0027] 首先介绍本发明实施例的一种网络侧融合地址本的方法。如图1A所示，包括：步骤S101：获得用户的联系人的静态信息和动态信息，其中，所述静态信息为在规定的时间内不发生变化的信息，所述动态信息为在规定的时间内发生变化的信息；步骤S102：融合联系人的静态信息和动态信息；步骤S103：将融合后的联系人的信息提供给用户使用的所有或部分终端。\n[0028] 融合后的一个联系人的信息可以是一条记录形式的联系人信息。\n[0029] 在实际应用中，可以将联系人的静态信息和动态信息融合为XML文档管理(XDM)形式，这样，保存的融合后的联系人的信息就是XDM形式的联系人的信息。\n[0030] XDM的联系人列表可以包括联系人的至少一种静态信息和至少一种动态信息。也就是说，可以将现有技术中的XDM的联系人列表进行扩展，增加一些属性。XDM的用户个人信息可以包括用户的一种静态信息和至少一种动态信息。\n[0031] 可以从本归属域的至少一个业务服务器或所述联系人所在归属域的至少一个业务服务器获得所述联系人的静态信息和动态信息。所述业务服务器可以为呈现服务器(Presence Server)、XDM服务器、共享偏好信息服务器、即时消息和呈现服务器或设备信息演进(DPE，Device Profile Evolution)服务器。\n[0032] 上面提到的静态信息可以包括下述至少一种信息：联系人的地址信息；联系人的联系方式信息。上面提到的动态信息可以包括下述至少一种信息：联系人的呈现信息；联系人的业务能力信息；联系人的终端能力信息；联系人的偏好信息。\n[0033] 向所述用户使用的终端提供的融合后的联系人的信息可以是符合用户需求的所述联系人的信息。符合用户需求例如是符合用户偏好、符合用户的终端能力或符合用户的业务能力。\n[0034] 融合联系人的静态信息和动态信息之后、将融合后的联系人的信息提供给用户使用的所有或部分终端之前，还可以保存融合后的联系人的信息。\n[0035] 将融合后的联系人的信息提供给用户使用的所有或部分终端之后，还可以获得用户管理联系人的信息的请求；根据所述请求，对联系人的信息进行管理，所述联系人的信息融合了所述联系人的静态信息和动态信息。\n[0036] 所述请求可以为增加新的联系人的信息的请求，对联系人的信息进行管理具体可以包括：如果所述新的联系人是本归属域的用户，且订阅所述新的联系人的信息时，需要得到所述新的联系人的同意，则向所述新的联系人使用的终端发出确认请求；如果所述新的联系人同意订阅，则建立用户与所述新的联系人之间的订阅关系。\n[0037] 所述请求可以为增加新的联系人的信息的请求，对联系人的信息进行管理具体可以包括：如果所述新的联系人是其他归属域的用户，且订阅所述新的联系人的信息时，需要得到所述新的联系人的同意，则向所述新的联系人所在归属域的管理联系人信息的服务器发出订阅请求，再由管理联系人信息的服务器向所述新的联系人使用的终端发出确认请求；如果所述新的联系人同意订阅，则建立用户与所述新的联系人之间的订阅关系。\n[0038] 所述请求可以为增加新的联系人的信息的请求，所述请求携带有所述新的联系人的信息，对联系人的信息进行管理具体可以包括：保存所述新的联系人的信息。\n[0039] 所述请求可以为增加新的联系人的信息的请求，获得用户管理联系人的信息的请求之后、对联系人的信息进行管理之前，还可以获得所述新的联系人的静态信息和动态信息。\n[0040] 获得所述新的联系人的静态信息和动态信息具体由下述方式来实现：从本归属域的至少一个业务服务器或所述联系人所在归属域的至少一个业务服务器获得所述联系人的静态信息和动态信息。\n[0041] 所述请求可以为删除联系人的信息的请求，对联系人的信息进行管理具体可以包括：删除所述需要删除的联系人的信息。\n[0042] 对联系人的信息进行管理还可以包括：如果所述需要删除的联系人为本归属域的用户且已建立用户与所述需要删除的联系人之间的订阅关系，则解除所述订阅关系。\n[0043] 对联系人的信息进行管理还可以包括：如果所述需要删除的联系人是其他归属域的用户且已向所述需要删除的联系人发出过订阅请求，则向所述需要删除的联系人所在归属域的管理联系人信息的服务器发出去订阅请求。\n[0044] 所述请求可以为修改联系人的信息的请求，所述请求携带修改的内容，对联系人的信息进行管理具体为：修改所述联系人的信息。\n[0045] 对联系人的信息进行管理之后，还可以将管理后的联系人的信息同步给至少一个业务服务器或用户使用的所有或部分终端。\n[0046] 上述方法实施例可以由多种形式的装置实现，其中的一种融合地址本服务器如图\n1B所示，包括：信息获得单元101B，用于获得用户的联系人的静态信息和动态信息，其中，所述静态信息为在规定的时间内不发生变化的信息，所述动态信息为在规定的时间内发生变化的信息；信息融合单元102B，用于融合信息获得单元101B获得的联系人的静态信息和动态信息；信息提供单元103B，用于将信息融合单元102B融合后的联系人的信息提供给用户使用的所有或部分终端。融合地址本服务器还可以包括信息保存单元104B，用于保存信息融合单元102B融合后的联系人的信息。\n[0047] 融合地址本服务器还可以包括：请求获得单元，用于在所述信息提供单元将信息融合单元融合后的联系人的信息提供给用户使用的所有或部分终端之后，获得用户管理联系人的信息的请求；信息管理单元，用于根据所述请求，对联系人的信息进行管理，所述联系人的信息融合了所述联系人的静态信息和动态信息。\n[0048] 所述请求可以为增加新的联系人的信息的请求，所述信息管理单元可以包括：请求发出单元，用于如果所述新的联系人是本归属域的用户，且订阅所述新的联系人的信息时，需要得到所述新的联系人的同意，则向所述新的联系人使用的终端发出确认请求；订阅关系处理单元，用于如果所述新的联系人同意订阅，则建立用户与所述新的联系人之间的订阅关系。\n[0049] 所述请求可以为增加新的联系人的信息的请求，所述信息管理单元可以包括：请求发出单元，用于如果所述新的联系人是其他归属域的用户，且订阅所述新的联系人的信息时，需要得到所述新的联系人的同意，则向所述新的联系人所在归属域的管理联系人信息的服务器发出订阅请求，再由管理联系人信息的服务器向所述新的联系人使用的终端发出确认请求；订阅关系处理单元，用于如果所述新的联系人同意订阅，则建立用户与所述新的联系人之间的订阅关系。\n[0050] 所述请求可以为增加新的联系人的信息的请求，所述信息获得单元在所述请求获得单元获得用户管理联系人的信息的请求之后、所述信息管理单元对联系人的信息进行管理之前，还可以获得所述新的联系人的不同类型的信息。\n[0051] 所述请求可以为删除联系人的信息的请求，所述信息管理单元可以包括：订阅关系处理单元，用于如果所述需要删除的联系人为本归属域的用户且已建立用户与所述需要删除的联系人之间的订阅关系，则解除所述订阅关系；请求发出单元，用于如果所述需要删除的联系人是其他归属域的用户且已向所述需要删除的联系人发出过订阅请求，则向所述需要删除的联系人所在归属域的管理联系人信息的服务器发出去订阅请求。\n[0052] 融合地址本服务器还可以包括信息同步单元，用于在所述信息管理单元对联系人的信息进行管理之后，将管理后的联系人的信息同步给至少一个业务服务器或用户使用的所有或部分终端。\n[0053] 上述融合地址本服务器可以应用于使用融合地址本服务器的任何一个通信系统中，对此，本发明实施例还提供一种融合地址本系统，包括：融合地址本服务器，用于融合联系人的静态信息和动态信息，当客户端请求提供联系人的信息时，向所述客户端提供融合后的联系人的信息，并根据所述客户端管理联系人信息的请求，对联系人的信息进行管理；\n至少一个业务服务器，用于当所述融合地址本服务器需要联系人的静态信息及动态信息和/或需要用户的个人信息时，向所述融合地址本服务器提供联系人的静态信息及动态信息和/或提供用户的个人信息。所述业务服务器可以为呈现服务器、XDM服务器、共享偏好信息服务器、即时消息和呈现服务器或DPE服务器。\n[0054] 本发明实施例还提供了一种融合地址本客户端，如图1C所示，包括：联系人信息获得单元101C，用于获得网络侧提供的联系人信息，所述联系人信息融合了联系人的静态信息和动态信息，其中，所述静态信息为在规定的时间内不发生变化的信息，所述动态信息为在规定的时间内发生变化的信息；联系人信息保存单元102C，用于保存所述联系人信息获得单元101C获得的联系人信息。\n[0055] 融合地址本客户端还可以包括请求单元103C，用于在所述联系人信息获得单元\n101C获得联系人信息后，向网络侧请求管理联系人信息。\n[0056] 请求管理联系人信息具体可以为：增加新的联系人的信息、删除联系人的信息或修改联系人的信息。\n[0057] 下面详细介绍本发明的几个优选实施例。\n[0058] 图2为本发明的呈现业务网络结构的第一优选示意图。\n[0059] 在这个优选结构中，融合地址本服务器202融合了地址本的联系人列表、群组列表、用户偏好、终端能力、用户的呈现业务等信息。融合地址本服务器202是一个独立的实体，即，与呈现服务器(Presence Server)205和共享XML文档管理服务器(Share XML Document Management Server)203都是相互独立的实体。其中，融合地址本服务器202保持与共享XML文档管理服务器203的同步更新，融合地址本客户端(CAB Client)201融合了呈现业务的客户端功能，并可以通过融合地址本服务器202定购联系人的呈现业务信息。\n[0060] 同样，融合地址本服务器202’也是一个独立的实体，即，与呈现服务器205’和共享XML文档管理服务器203’都是相互独立的实体。其中，融合地址本服务器202’保持与共享XML文档管理服务器203’的同步更新，融合地址本客户端201’融合了呈现业务的客户端功能，并可以通过融合地址本服务器202’定购联系人的呈现业务信息。融合地址本客户端201和201’只需定制联系人的融合地址本信息，即可获取联系人的呈现业务等信息。\n[0061] 为描述方便，这里将融合地址本客户端201、融合地址本服务器202、共享XML文档管理服务器203、呈现用户代理(PUA，Presence User Agent)客户端204及呈现服务器205作为观察者(Watcher)归属域中的实体，即，订阅呈现信息的用户所在的域中的实体，将融合地址本客户端201’、融合地址本服务器202’、共享XML文档管理服务器203’、呈现用户代理客户端204’及呈现服务器205’作为呈现者(Presentity)归属域中的实体，即，发布呈现信息的用户所在的域中的实体。观察者可以通过融合地址本客户端201向融合地址本服务器202定制某个联系人的信息，还可以通过呈现用户代理客户端204发布给呈现服务器\n205。同样，呈现者可以通过融合地址本客户端201’向融合地址本服务器202’定制某个联系人的信息，还可以通过呈现用户代理客户端204’发布给呈现服务器205’。\n[0062] 当观察者通过融合地址本客户端201向融合地址本服务器202定制某个联系人的信息时，如果该联系人恰好是图2所示的呈现者，则融合地址本服务器202会向融合地址本服务器202’发送定制请求。融合地址本服务器202’再将该请求发送到融合地址本客户端\n201’。融合地址本客户端201’确认该请求后，融合地址本服务器202’将确定应答转发给融合地址本服务器202。融合地址本服务器202再将确定应答转发给融合地址本客户端201。\n融合地址本服务器202为观察者保存该联系人的相关联系信息，当该联系人的信息有更新时，融合地址本服务器202’将更新后的信息发送到融合地址本服务器202，融合地址本服务器202再将更新后的信息同步到融合地址本客户端201。\n[0063] 融合地址本服务器202包括图3所示的几个功能单元。如图3所示，管理单元\n2021是一个具有综合管理功能的单元，例如，管理单元2021可以处理所接收到的消息和数据，并将消息和数据发送到其他合适的功能单元进行处理，管理单元2021也可以协调其他功能单元之间的工作。聚合单元2022(可以相当于图1B所示的信息融合单元102B)可以获取用户的个人信息(例如profile信息)，并聚合来自例如呈现服务器205等其他网络实体的信息，聚合单元2022也可以将用户的个人信息提供给管理单元2021，还可以将用户的个人信息同步给其他网络实体。存储单元2023(可以相当于图1B所示的信息保存单元\n104B)可以获得管理单元2021提供的用户的个人信息，并将个人信息进行保存，存储单元\n2023也可以为用户保存网络地址本信息，网络地址本信息可以包括联系人的信息。过滤单元2024可以根据用户的偏好和用户终端能力，过滤或适配存储单元2023下发给融合地址本客户端201的地址本信息，过滤单元2024也可以过滤其他网络实体发来的信息。接收和发送单元2025(可以相当于图1B所示的融合信息获得单元101B和信息提供单元103B)可以接收和发送数据及消息，具体的，既可以接收和发送与融合地址本客户端201之间的数据及消息，也可以接收和发送与融合地址本服务器202’之间的数据及消息。\n[0064] 存储单元2023保存的信息如图4所示，保存的信息可以包括两个部分，一部分是用户的个人信息，例如呈现业务信息、偏好及Profile信息等，另一部分是用户的网络地址本信息，网络地址本信息中的每个联系人的信息可以包括两部分内容，即，用户输入的联系人的信息和从联系人归属域获得的联系人的信息。个人信息和网络地址本信息可以采用扩展标签语言(XML，Extensible Markup Language)格式，也可以采用vCard格式，如果采用vCard格式，则由于多数终端都支持vCard格式，所以可以与多数终端支持的vCard格式相兼容，另外，即使融合地址本服务器202支持vCard格式，但也可以以XML格式保存，这样，在接收融合地址本客户端201上报的地址信息时，也能够识别vCard格式的数据。另外，由于存储单元2023需要保存包括个人信息，所以，网络地址本的扩展标签语言属性信息需要包括现有的XML文档管理业务中的个人信息及呈现业务信息中相关的元素信息，例如，用户的偏好、终端能力、网络能力等，因此，本发明的网络地址本比现有的vCard格式所定义的属性要多。存储单元2023将个人信息同步到终端时，过滤单元2024需要对相关的信息进行过滤和适配。\n[0065] 融合地址本服务器202’的结构可以参照融合地址本服务器202的结构，这里不再赘述。\n[0066] 当某个或某些联系人的信息发生变化时，例如，当用户在地址本上添加了联系人时，或者修改了地址本上的某个或某些联系人的相应信息时，融合地址本服务器可以更新自身及观察者的所有终端保存的该联系人的信息。具体流程如图5所示，包括：\n[0067] 步骤S501：融合地址本服务器获得更新融合地址本的信息的请求。更新融合地址本的信息可以是指更新某个或某些联系人的信息。\n[0068] 步骤S502：保存更新后的融合地址本的信息。\n[0069] 步骤S503：判断是否需要从其他业务引擎获得联系人的相关信息，如果是，则转步骤S504，否则，转步骤S506。业务引擎可以是联系人归属域的融合地址本服务器、呈现服务器或共享XML文档管理服务器等实体。\n[0070] 步骤S504：判断其他业务引擎是否允许获得联系人的相关信息，如果是，转步骤S505，否则，转步骤S506。\n[0071] 步骤S505：从其他业务引擎获得联系人的相关信息，并将获得的信息融合到自身存储的信息中，转步骤S506。例如，如果原来是按序存储的联系人的信息，那么在更新某个联系人的信息后，也需要重新按序存储联系人的信息。\n[0072] 步骤S506：向观察者的所有终端发送更新后的信息。\n[0073] 下面再以图6及图7所示的信令流程图，对涉及的相关流程进行详细说明。\n[0074] 如图6所示，步骤S601-S608是有关融合地址本服务器为每个用户聚合其个人信息的流程，具体如下：\n[0075] 步骤S601：融合地址本服务器中的管理单元从共享XML文档管理服务器获得用户的自身信息，当然，融合地址本服务器也可以通过用户输入信息的方式获得用户的自身信息。\n[0076] 步骤S602：融合地址本服务器中的管理单元获得用户的自身信息后，向共享XML文档管理服务器返回应答。\n[0077] 步骤S603：融合地址本服务器中的管理单元向呈现服务器订阅某个联系人的呈现业务信息，具体可以使用订阅(SUBSCRIBE)消息。\n[0078] 步骤S604：呈现服务器针对收到的订阅消息进行响应(200OK)。\n[0079] 步骤S605：呈现服务器向融合地址本服务器中的管理单元提供该联系人的呈现业务信息，具体可以使用通知(NOTIFY)消息。\n[0080] 步骤S606：融合地址本服务器中的管理单元针对收到的通知消息进行响应(200OK)。\n[0081] 步骤S607：融合地址本服务器中的管理单元将该联系人的呈现业务信息存储到融合地址本服务器中的存储单元中，具体可以使用存储(PUT)消息。\n[0082] 步骤S608：存储单元针对存储消息进行响应(200OK)。\n[0083] 步骤S609-S619是有关用户增加联系人的流程，具体如下：\n[0084] 步骤S609：融合地址本客户端将用户增加的联系人的信息提供给融合地址本服务器中的管理单元，这里的联系人的信息可以是联系人的个人信息，例如是联系人的基本信息。\n[0085] 步骤S610：融合地址本服务器中的管理单元向融合地址本客户端询问是否需要订阅该联系人的信息。\n[0086] 步骤S611：如果用户需要订阅该联系人的信息，则融合地址本客户端向融合地址本服务器中的管理单元返回订阅确认。\n[0087] 步骤S612：融合地址本服务器中的管理单元向该联系人发出订阅请求，并获得订阅确认。如果该联系人与用户属于同一个域，则融合地址本服务器中的管理单元可以直接向该联系人的融合地址本客户端发出订阅请求；如果该联系人与用户属于不同的域，则融合地址本服务器中的管理单元需要向该联系人的融合地址本服务器发出订阅请求，再由该联系人的融合地址本服务器将订阅请求转发给该联系人的融合地址本客户端。\n[0088] 步骤S613：如果订阅成功，融合地址本服务器中的管理单元向融合地址本客户端返回订阅成功。\n[0089] 步骤S614：融合地址本服务器中的管理单元将该联系人的信息存储到融合地址本服务器中的存储单元中，具体可以使用存储(PUT)消息。这里的该联系人的信息的内容可以比步骤S609提到的联系人的信息的内容丰富一些，例如这里的信息可以包括该联系人的呈现业务信息。\n[0090] 步骤S615：存储单元针对存储消息进行响应(200OK)。\n[0091] 步骤S616：融合地址本服务器中的管理单元将该联系人的信息同步到共享XML文档管理服务器。\n[0092] 步骤S617：共享XML文档管理服务器收到该联系人的信息后，返回确认消息。\n[0093] 步骤S618：融合地址本服务器中的管理单元周期性的向融合地址本客户端发送该联系人的最新信息，具体可以使用信息发布(SIP PUBLISH)消息。\n[0094] 步骤S619：融合地址本客户端针对信息发布消息进行响应(200OK)。\n[0095] 步骤S620-S624是有关用户更新自身信息的流程，具体如下：\n[0096] 步骤S620：融合地址本客户端向呈现服务器发送更新后的用户信息，具体可以使用信息发布(SIP PUBLISH)消息。\n[0097] 步骤S621：呈现服务器针对信息发布消息进行响应(200OK)。\n[0098] 步骤S622：呈现服务器向融合地址本服务器中的管理单元提供更新后的用户信息，具体可以使用通知(NOTIFY)消息。\n[0099] 步骤S623：融合地址本服务器中的管理单元针对通知消息进行响应(200OK)。\n[0100] 步骤S624：融合地址本服务器中的管理单元将获得的更新后的用户信息保存到存储单元中，并将更新后的用户信息提供给订阅了用户信息的其他用户。\n[0101] 图7所示的流程是有关用户订阅其他域(在这个流程中称为远端)的联系人的信息时远端进行相关处理的流程。具体的，如图7所示，包括：\n[0102] 步骤S701：用户归属的融合地址本服务器向远端融合地址本服务器的管理单元请求订阅某个联系人的信息。\n[0103] 步骤S702：远端融合地址本服务器中的管理单元向该联系人的融合地址本客户端请求订阅该联系人的信息，具体可以使用确认请求消息。\n[0104] 步骤S703：该联系人的融合地址本客户端向远端融合地址本服务器中的管理单元针对订阅请求返回应答，具体可以使用确认应答消息。\n[0105] 步骤S704：远端融合地址本服务器中的管理单元针对步骤S701的订阅请求进行响应(200OK)。\n[0106] 步骤S705：远端融合地址本服务器中的管理单元向呈现服务器获得该联系人的呈现业务信息，具体可以使用订阅(SUBSCRIBE)消息。\n[0107] 步骤S706：呈现服务器针对收到的订阅消息进行响应(200OK)。\n[0108] 步骤S707：呈现服务器向远端融合地址本服务器中的管理单元提供该联系人的呈现业务信息，具体可以使用通知(NOTIFY)消息。\n[0109] 步骤S708：远端融合地址本服务器中的管理单元针对通知消息进行响应(200OK)。\n[0110] 步骤S709：远端融合地址本服务器中的管理单元向共享XML文档管理服务器请求获得该联系人的个人信息，具体可以使用获取(GET)消息。\n[0111] 步骤S710：共享XML文档管理服务器针对收到的获取消息进行响应(200OK)。\n[0112] 步骤S711：远端融合地址本服务器中的管理单元将从呈现服务器和共享XML文档管理服务器获得的信息进行融合处理。\n[0113] 步骤S712：远端融合地址本服务器中的管理单元将融合后的信息存储到远端融合地址本服务器中的存储单元，具体可以使用存储(PUT)消息。\n[0114] 步骤S713：存储单元针对收到的存储消息进行响应(200OK)。\n[0115] 步骤S714：当有需要时，远端融合地址本服务器中的管理单元向远端融合地址本服务器中的存储单元请求获得需要的信息，具体可以使用获取(GET)消息。\n[0116] 步骤S715：存储单元针对收到的获取消息进行响应(200OK)。\n[0117] 步骤S716：远端融合地址本服务器中的管理单元向用户归属的融合地址本服务器发送携带联系人信息的通知(NOTIFY)消息。\n[0118] 步骤S717：用户归属的融合地址本服务器针对收到的通知消息进行响应(200OK)。\n[0119] 需要说明的是，执行步骤S704之后，如果远端融合地址本服务器中的管理单元已经将该联系人的信息融合到存储单元中，并且已经获得了需要的信息，则步骤S705-S713可以省略。\n[0120] 另外需要说明的是，在图7所示的流程中，远端融合地址本服务器中的管理单元需要将不同类型的信息融合，之后再将融合后的信息存储到远端融合地址本服务器中的存储单元，或者说，远端融合地址本服务器中的存储单元存储了多种类型的信息。在实际应用中，远端融合地址本服务器中的存储单元也可以只保存联系人的相对静态的信息，例如联系人的姓名、地址或电话号码等。如果远端融合地址本服务器只保存联系人的相对静态的信息，则在需要联系人的信息时，远端融合地址本服务器中的管理单元可以融合业务服务器提供的联系人的相对动态的信息及存储单元存储的联系人的相对静态的信息，生成融合后的联系人的信息。\n[0121] 上述图2-图7所示的实施例都是基于图2所示的第一优选结构进行说明的，在实际应用中，融合地址本服务器的功能完全可以集成在呈现服务器或共享XML文档管理服务器中。\n[0122] 图8即为融合地址本服务器的功能集成在共享XML文档管理服务器时的呈现业务网络结构的示意图。如图8所示，融合地址本客户端801融合了呈现业务的客户端功能，还融合了XML文档管理服务器客户端的功能。融合地址本服务器802融合了XML文档管理服务器的功能，并能为融合地址本客户端801提供呈现业务的定购服务，其保存了每个联系人的信息及用户自身的属性信息，其中也可以包括呈现业务的信息，其能够与呈现服务器\n805之间保持信息的同步。融合地址本服务器802可以包括管理单元、共享XDM单元及共享偏好信息单元等信息单元，其中，共享XDM单元可以存储联系人的列表(List)信息、用户或联系人的群组(Group)信息以及用户的Profile信息，共享偏好信息单元可以存储用户或联系人的偏好信息。管理单元可以将用户的地址本保存到共享列表单元及共享群组单元中，这里的共享列表不同于PAG标准中的共享列表，它是一个扩展的列表，能够兼容Vcard格式的联系人信息并可以包含呈现业务等信息。用户的个人信息可以保存到共享群组单元中，个人profile信息也不同于PAG标准中的共享群组，其能够融合来自呈现业务、个人偏好等信息。融合地址本服务器802也可以包括过滤单元，用于根据用户的偏好、终端能力等信息，对地址本等相关信息进行过滤。\n[0123] 同样，融合地址本客户端801’融合了呈现业务的客户端功能，还融合了XML文档管理服务器客户端的功能。融合地址本服务器802’融合了XML文档管理服务器的功能，并能为融合地址本客户端801’提供呈现业务的定购服务，其保存了每个联系人的信息及用户自身的属性信息，其中也可以包括呈现业务的信息，其能够与呈现服务器805’之间保持信息的同步。融合地址本服务器802’可以包括管理单元、共享XDM单元及共享偏好信息单元等信息单元，其中，共享XDM单元可以存储联系人的列表信息、用户或联系人的群组信息以及用户的Profile信息，共享偏好信息单元可以存储用户或联系人的偏好信息。管理单元可以将用户的地址本保存到共享列表单元及共享群组单元中，这里的共享列表不同于PAG标准中的共享列表，它是一个扩展的列表，能够兼容Vcard格式的联系人信息并可以包含呈现业务等信息。用户的个人信息可以保存到共享群组单元中，个人profile信息也不同于PAG标准中的共享群组，其能够融合来自呈现业务、个人偏好等信息。融合地址本服务器\n802’也可以包括过滤单元，用于根据用户的偏好、终端能力等信息，对地址本等相关信息进行过滤。\n[0124] 图8所涉及的具体流程如图9所示。\n[0125] 步骤S901-S906是有关融合地址本服务器为用户聚合其呈现信息的流程，具体如下：\n[0126] 步骤S901：融合地址本服务器中的管理单元向呈现服务器订阅呈现业务信息，具体可以使用订阅(SUBSCRIBE)消息。\n[0127] 步骤S902：呈现服务器针对收到的订阅消息进行响应(200OK)。\n[0128] 步骤S903：呈现服务器向融合地址本服务器中的管理单元提供呈现业务信息，具体可以使用通知(NOTIFY)消息。\n[0129] 步骤S904：融合地址本服务器中的管理单元针对收到的通知消息进行响应(200OK)。\n[0130] 步骤S905：融合地址本服务器中的管理单元将呈现业务信息存储到存储单元(假设联系人的信息、呈现业务信息、用户个人信息等相关信息都存储到这个存储单元)中。步骤S906：存储单元针对存储消息进行响应(200OK)。\n[0131] 步骤S907-S917是有关用户增加联系人的流程，具体如下：\n[0132] 步骤S907：融合地址本客户端将用户增加的联系人的信息提供给融合地址本服务器中的管理单元，这里的联系人的信息可以是联系人的个人信息，例如是联系人的基本信息。\n[0133] 步骤S908：融合地址本服务器中的管理单元向融合地址本客户端询问是否需要订阅该联系人的信息。\n[0134] 步骤S909：如果用户需要订阅该联系人的信息，则融合地址本客户端向融合地址本服务器中的管理单元返回订阅确认。\n[0135] 步骤S910：融合地址本服务器中的管理单元向该联系人发出订阅请求，并获得订阅确认。如果该联系人与用户属于同一个域，则融合地址本服务器中的管理单元可以直接向该联系人的融合地址本客户端发出订阅请求；如果该联系人与用户属于不同的域，则融合地址本服务器中的管理单元需要向该联系人的融合地址本服务器发出订阅请求，再由该联系人的融合地址本服务器将订阅请求转发给该联系人的融合地址本客户端。\n[0136] 步骤S911：如果订阅成功，融合地址本服务器中的管理单元向融合地址本客户端返回订阅成功。\n[0137] 步骤S912：融合地址本服务器中的管理单元将该联系人的信息存储到融合地址本服务器中的存储单元中，具体可以使用存储(PUT)消息。这里的该联系人的信息的内容可以比步骤S907提到的联系人的信息的内容丰富一些，例如这里的信息可以包括该联系人的呈现业务信息。当然，融合地址本服务器中的管理单元也可以只将用户输入的信息存储到融合地址本服务器中的存储单元中。\n[0138] 步骤S913：存储单元针对存储消息进行响应(200OK)。\n[0139] 步骤S914：如果用户设置了与该用户的其他业务系统的地址本同步的功能，则融合地址本服务器中的管理单元将该联系人的信息同步到其他业务系统，例如即时消息和呈现服务器(IMPS，Instant Messaging and PresenceService)。\n[0140] 步骤S915：即时消息和呈现服务器收到该联系人的信息后，返回确认消息。\n[0141] 步骤S916：融合地址本服务器中的管理单元周期性的向融合地址本客户端发送该联系人的最新信息，具体可以使用信息发布(SIP PUBLISH)消息。\n[0142] 步骤S917：融合地址本客户端针对信息发布消息进行响应(200OK)。\n[0143] 步骤S918-S922是有关用户更新自身信息的流程，具体如下：\n[0144] 步骤S918：融合地址本客户端向呈现服务器发送更新后的用户信息，具体可以使用信息发布(SIP PUBLISH)消息。\n[0145] 步骤S919：呈现服务器针对信息发布消息进行响应(200OK)。\n[0146] 步骤S920：呈现服务器向融合地址本服务器中的管理单元提供更新后的用户信息，具体可以使用通知(NOTIFY)消息。\n[0147] 步骤S921：融合地址本服务器中的管理单元针对通知消息进行响应(200OK)。\n[0148] 步骤S922：融合地址本服务器中的管理单元将获得的更新后的用户信息保存到存储单元中，并将更新后的用户信息提供给订阅了用户信息的其他用户。\n[0149] 需要说明的是，在步骤S905中，融合地址本服务器中的管理单元也可以不将呈现业务信息存储到存储单元，而是当需要将呈现信息提供给订阅呈现信息的请求人时，融合地址本服务器中的管理单元从呈现服务器获得呈现业务信息，在将呈现业务信息与其他信息融合后，提供给订阅方。\n[0150] 图10是有关用户订阅其他域(在这个流程中称为远端)的联系人的信息时远端进行相关处理的流程图。具体的，如图10所示，包括：\n[0151] 步骤S1001：用户归属的融合地址本服务器向远端融合地址本服务器的管理单元请求订阅某个联系人的信息。\n[0152] 步骤S1002：远端融合地址本服务器中的管理单元向该联系人的融合地址本客户端请求订阅该联系人的信息，具体可以使用确认请求消息。\n[0153] 步骤S1003：该联系人的融合地址本客户端向远端融合地址本服务器中的管理单元针对订阅请求返回应答，具体可以使用确认应答消息。\n[0154] 步骤S1004：远端融合地址本服务器中的管理单元针对步骤S1001的订阅请求进行响应(200OK)。\n[0155] 步骤S1005：远端融合地址本服务器中的管理单元向呈现服务器获得该联系人的呈现业务信息，具体可以使用订阅(SUBSCRIBE)消息。\n[0156] 步骤S1006：呈现服务器针对收到的订阅消息进行响应(200OK)。\n[0157] 步骤S1007：呈现服务器向远端融合地址本服务器中的管理单元提供该联系人的呈现业务信息，具体可以使用通知(NOTIFY)消息。\n[0158] 步骤S1008：远端融合地址本服务器中的管理单元针对通知消息进行响应(200OK)。\n[0159] 步骤S1009：远端融合地址本服务器中的管理单元将该联系人的呈现业务信息存储到远端融合地址本服务器中的存储单元，具体可以使用存储(PUT)消息。\n[0160] 步骤S1010：存储单元针对收到的存储消息进行响应(200OK)。\n[0161] 步骤S1011：当有需要时，远端融合地址本服务器中的管理单元向远端融合地址本服务器中的存储单元请求获得需要的信息，具体可以使用获取(GET)消息。\n[0162] 步骤S1012：存储单元针对收到的获取消息进行响应(200OK)。\n[0163] 步骤S1013：远端融合地址本服务器中的管理单元向用户归属的融合地址本服务器发送携带联系人信息的通知(Notify)消息。\n[0164] 步骤S1014：用户归属的融合地址本服务器针对收到的通知消息进行响应(200OK)。\n[0165] 需要说明的是，如果远端融合地址本服务器中的存储单元只保存了联系人的相对静态的信息，则当需要联系人的信息时，远端融合地址本服务器中的管理单元可以融合业务服务器提供的联系人的相对动态的信息及联系人的相对静态的信息，生成融合后的联系人的信息。\n[0166] 图11为本发明的呈现业务网络结构的第三优选示意图。\n[0167] 在这个优选结构中，融合地址本客户端1101融合了呈现业务的客户端功能，还融合了XML文档管理服务器客户端的功能，其与图2所示的融合地址本客户端201之间最主要的区别是，融合地址本客户端1101融合了呈现用户代理客户端的功能，即，用户可以通过融合地址本客户端1101发布呈现信息。融合地址本服务器1102可以从共享XML文档管理服务器1103、呈现服务器1105及共享偏好信息服务器1106等网络实体获得联系人的信息、呈现业务信息以及用户的个人信息等信息，并将获得的信息进行融合。融合地址本服务器1102可以包括管理单元及存储单元，管理单元可以获得信息，并将获得的信息保存到存储单元中，当然，如有需要时，管理单元也可以从存储单元中提取需要的数据。\n[0168] 同样，融合地址本客户端1101’融合了呈现业务的客户端功能，还融合了XML文档管理服务器客户端的功能，其与图2所示的融合地址本客户端201’之间最主要的区别是，融合地址本客户端1101’融合了呈现用户代理客户端的功能，即，用户可以通过融合地址本客户端1101’发布呈现信息。融合地址本服务器1102’可以从共享XML文档管理服务器1103’、呈现服务器1105’及共享偏好信息服务器1106’等网络实体获得联系人的信息、呈现业务信息以及用户的个人信息等信息，并将获得的信息进行融合。融合地址本服务器\n1102’可以包括管理单元及存储单元，管理单元可以获得信息，并将获得的信息保存到存储单元中，当然，如有需要时，管理单元也可以从存储单元中提取需要的数据。\n[0169] 需要说明的是，融合地址本服务器1102和1102’可以只具有融合功能，即，融合地址本服务器1102和1102’可以只保存用户的个人信息和/或用户输入的信息，而不保存融合后的联系人的信息，当需要联系人的信息时，融合地址本服务器1102和1102’再从业务服务器获得需要的信息，之后再将这些信息融合，生成融合后的联系人的信息。\n[0170] 图11涉及的相关流程具体如图12所示。\n[0171] 步骤S1201-S1210是有关融合地址本服务器为用户融合联系人信息的流程，具体如下：\n[0172] 步骤S1201：融合地址本客户端向融合地址本服务器中的管理单元发出同步请求，即，融合地址本客户端需要获得某个联系人的信息。\n[0173] 步骤S1202：融合地址本服务器中的管理单元向呈现服务器订阅某个联系人的呈现业务信息，具体可以使用订阅(SUBSCRIBE)消息。\n[0174] 步骤S1203：呈现服务器针对收到的订阅消息进行响应(200OK)。\n[0175] 步骤S1204：呈现服务器向融合地址本服务器中的管理单元提供该联系人的呈现业务信息，具体可以使用通知(NOTIFY)消息。\n[0176] 步骤S1205：融合地址本服务器中的管理单元针对收到的通知消息进行响应(200OK)。\n[0177] 步骤S1206：融合地址本服务器中的管理单元从共享XML文档管理服务器获得该联系人的个人信息，具体可以使用获取(GET)消息。\n[0178] 步骤S1207：共享XML文档管理服务器针对收到的获取消息进行响应(200OK)。\n[0179] 步骤S1208：融合地址本服务器中的管理单元从融合地址本服务器中的存储单元中获得该联系人的其他信息，具体可以使用获取(GET)消息，其中，该联系人的其他信息可以是指呈现服务器和共享XML文档管理服务器没有提供的关于该联系人的信息。\n[0180] 步骤S1209：融合地址本服务器中的存储单元针对收到的获取消息进行响应(200OK)。\n[0181] 步骤S1210：融合地址本服务器中的管理单元将获得的该联系人的信息融合后，向融合地址本客户端返回同步应答，即，将融合后的信息提供给融合地址本客户端。\n[0182] 步骤S1211-S1223是用户增加联系人后的相关流程。\n[0183] 步骤S1211：融合地址本客户端向融合地址本服务器中的管理单元发出更新请求，即，融合地址本客户端增加了一个新的联系人，向融合地址本服务器中的管理单元同步新的联系人的信息。其中，融合地址本客户端同步的新的联系人的信息可以是新的联系人的一部分信息，例如包括用户自己为新的联系人增加的描述信息。\n[0184] 步骤S1212：融合地址本服务器中的管理单元向融合地址本客户端询问是否需要订阅该联系人的信息。\n[0185] 步骤S1213：如果用户需要订阅该联系人的信息，则融合地址本客户端向融合地址本服务器中的管理单元返回订阅确认。\n[0186] 步骤S1214：融合地址本服务器中的管理单元向该联系人发出订阅请求，并获得订阅确认。如果该联系人与用户属于同一个域，则融合地址本服务器中的管理单元可以直接向该联系人的融合地址本客户端发出订阅请求；如果该联系人与用户属于不同的域，则融合地址本服务器中的管理单元需要向该联系人的融合地址本服务器发出订阅请求，再由该联系人的融合地址本服务器将订阅请求转发给该联系人的融合地址本客户端。\n[0187] 步骤S1215：如果订阅成功，融合地址本服务器中的管理单元向融合地址本客户端返回订阅成功。\n[0188] 步骤S1216：如果融合地址本客户端同步的信息中包括对新的联系人增加的描述信息，则融合地址本服务器将该描述信息存储到融合地址本服务器中的存储单元中，具体可以使用存储(PUT)消息。\n[0189] 步骤S1217：存储单元针对存储消息进行响应(200OK)。\n[0190] 步骤S1218：融合地址本服务器中的管理单元将新的联系人的信息提供给共享XML文档管理服务器的共享列表单元中，共享列表单元中的内容可以包括融合地址本服务器提供的所有信息，具体可以使用存储(PUT)消息。\n[0191] 步骤S1219：共享XML文档管理服务器针对存储消息进行响应(200OK)。\n[0192] 步骤S1220：融合地址本服务器中的管理单元将新的联系人的信息同步到其他业务系统，例如即时消息和呈现服务器，在同步过程中，可以进行相应属性的适配和格式的修改。\n[0193] 步骤S1221：即时消息和呈现服务器收到新的联系人的信息后，向融合地址本服务器中的管理单元返回确认应答。\n[0194] 步骤S1222：融合地址本服务器中的管理单元周期性的向融合地址本客户端发送该联系人的最新信息，具体可以使用信息发布(SIP PUBLISH)消息。\n[0195] 步骤S1223：融合地址本客户端针对信息发布消息进行响应(200OK)。\n[0196] 步骤S1224-S1228是有关用户更新自身信息的流程，具体如下：\n[0197] 步骤S1224：融合地址本客户端向呈现服务器发送更新后的用户信息，具体可以使用信息发布(SIP PUBLISH)消息。\n[0198] 步骤S1225：呈现服务器针对信息发布消息进行响应(200OK)。\n[0199] 步骤S1226：呈现服务器向融合地址本服务器中的管理单元提供更新后的用户信息，具体可以使用通知(NOTIFY)消息。\n[0200] 步骤S1227：融合地址本服务器中的管理单元针对通知消息进行响应(200OK)。\n[0201] 步骤S1228：融合地址本服务器中的管理单元将获得的更新后的用户信息保存到存储单元中，并将更新后的用户信息提供给订阅了用户信息的其他用户。\n[0202] 图13是有关用户订阅其他域(在这个流程中称为远端)的联系人的信息时远端进行相关处理的流程图。具体的，如图13所示，包括：\n[0203] 步骤S1301：用户归属的融合地址本服务器向远端融合地址本服务器的管理单元请求订阅某个联系人的信息。\n[0204] 步骤S1302：远端融合地址本服务器中的管理单元向该联系人的融合地址本客户端请求订阅该联系人的信息，具体可以使用确认请求消息。\n[0205] 步骤S1303：该联系人的融合地址本客户端向远端融合地址本服务器中的管理单元针对订阅请求返回应答，具体可以使用确认应答消息。\n[0206] 步骤S1304：远端融合地址本服务器中的管理单元针对步骤S1001的订阅请求进行响应(200OK)。\n[0207] 步骤S1305：远端融合地址本服务器中的管理单元向呈现服务器获得该联系人的呈现业务信息，具体可以使用订阅(SUBSCRIBE)消息。\n[0208] 步骤S1306：呈现服务器针对收到的订阅消息进行响应(200OK)。\n[0209] 步骤S1307：呈现服务器向远端融合地址本服务器中的管理单元提供该联系人的呈现业务信息，具体可以使用通知(NOTIFY)消息。\n[0210] 步骤S1308：远端融合地址本服务器中的管理单元针对通知消息进行响应(200OK)。\n[0211] 步骤S1309：远端融合地址本服务器中的管理单元向共享XML文档管理服务器请求获得该联系人的个人信息，具体可以使用获取(GET)消息。\n[0212] 步骤S1310：共享XML文档管理服务器针对收到的获取消息进行响应(200OK)。\n[0213] 步骤S1311：远端融合地址本服务器中的管理单元将从呈现服务器和共享XML文档管理服务器获得的信息进行融合处理。\n[0214] 步骤S1312：远端融合地址本服务器中的管理单元向用户归属的融合地址本服务器发送携带联系人信息的通知(NOTIFY)消息。\n[0215] 步骤S1313：用户归属的融合地址本服务器针对收到的通知消息进行响应(200OK)。\n[0216] 上面提到过，终端可以融合现有技术的多个终端的功能。另外，终端也可以融合联系人的信息。例如，终端上可以设置一个用户界面接口，通过接口可以调用呈现业务客户端(Presence Client)功能、XDM服务器客户端的功能及设备管理客户端功能，实现融合地址本服务，其中，现有的共享列表信息和共享群组经过扩展后，可以保存用户的联系人和群组信息，而相应的共享个人Profile保存个人信息，用户的界面接口实现对这些信息的融合处理，界面可以将融合后的信息展现给用户。当用户对联系人列表做修改时，界面接口可以询问用户是否定购联系人的信息，如果需要定购，则终端向该联系人的呈现服务器、XDM服务器等业务服务器定购联系人的动态信息和静态信息。终端可以将融合后的联系人的信息保存到网络侧，或者仅将联系人的最基本的信息保存到网络侧，当终端接入网络侧时，可以直接定购联系人的信息。另外，当用户选择不定购联系人的信息时，终端可以只将用户输入的联系人的信息保存到联系人列表中。\n[0217] 在本发明的实施例中，由于联系人的静态信息和动态信息都是融合在一起的，所以，网络侧提供给用户的联系人的信息是一种格式的信息，而不是多种格式的不同信息，这样就不会因为展现给用户的联系人的信息都是独立的形式，而影响用户对地址本信息的体验。\n[0218] 在本发明的实施例中，网络侧可以将用户的联系人的信息都同步给用户的所有终端，这样，用户的所有终端保存的联系人的信息都是一致的，或者说，无论用户使用哪个终端查看地址本，查到的地址本信息都是一致的。同时，网络侧在无须每个终端都请求订阅联系人的信息的前提下，就可以将用户的联系人的信息都同步给用户的所有终端，避免了所有终端为订阅联系人的信息而导致产生的终端与网络侧交互的大量消息，从而节省了网络资源。\n[0219] 在本发明的实施例中，网络侧可以根据终端的能力信息或用户偏好等信息，向每个终端提供过滤后的联系人的信息，所以可以符合终端本身的能力要求及满足用户的需求。\n[0220] 在本发明的实施例中，网络侧可以融合联系人的静态信息和动态信息，这样，提供给用户的不是联系人的单一的信息，而是包含了丰富内容的信息，满足了用户日益增长的获取丰富信息的心理需求。\n[0221] 本发明实施例可以应用在移动通信网络、Internet网络上开展的使用地址本进行联系的通信业务，例如消息业务，移动通信网络包括2G、2.5G、未来的3G以及多媒体子域等网络。\n[0222] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。