CN101365156A - 获取用户联系人信息的方法和系统 - Google Patents

Abstract

本发明实施例提供了获取用户联系人信息的方法，通过在媒体和消息网络存储单元和网络联系人列表单元之间设置直接接口或应用服务器，实现了媒体和消息网络存储与网络联系人列表关于用户联系人信息的获取和同步。本发明实施例还提供了获取用户联系人信息的系统。本发明实施例通过媒体和消息网络存储单元与网络联系人列表单元之间关于用户联系人信息的获取和同步，解决了用户联系人信息的获取范围受限于用户终端中信息存储量和稳定性较差的问题。同时，提高了网络资源的利用率，改善了用户查阅媒体和消息的体验。

Description

获取用户联系人信息的方法和系统

技术领域

本发明涉及通信技术领域，尤其涉及获取用户联系人信息的方法和系统。

背景技术

目前，为了更加充分的利用网络资源，共享更加丰富的多媒体数据以及消息，多媒体业务以及消息业务推出了多媒体数据(包括各种即时消息)的网络存储功能。

相关运营商在GSM SMS(Short Message Service，短消息业务)网络改造课题中，也提出了短消息网络存储的应用需求，主要目的有以下几点：

1.解决终端存储能力有限，且存储容易受损的问题；

2.为短消息存储内容的多用户共享提供条件，拓展短消息业务空间；

3.利于开发与现有业务系统(如网络邮箱业务)进行交互的新方法。

因此，在网络侧进行改造的GSM网络中，新增了短消息增值业务数据中心(DCS，Data Center for Short Message Service)，用于保存用户功能详细签约数据，提供面向终端用户的主被叫业务的增值业务设置，如短消息呼转、短消息过滤、短消息回执，以及短消息网络存储等。

图1为现有技术的短消息网络存储业务流程示意图，如图所示为被叫移动用户(MS，Mobile Subscriber)在本地的业务流程情况，包括如下步骤：

步骤101：主叫MS发送Submit_sm消息给主叫归属短消息业务中心(SMSC，Short Message Service Center)。

步骤102：该SMSC发送预回送应答消息Submit_Ack给主叫用户。

步骤103：该SMSC发送业务查询消息Deliver_sm给本地DCS。

步骤104：该DCS发送应答消息Deliver_Ack给该SMSC。

如果主被叫不含有业务信息，则该SMSC进行消息的正常下发、计费，并生成话单；如果主被叫含有业务信息，则继续进行步骤105至步骤110。

步骤105：该DCS发送消息前传通知Deliver_sm给该SMSC。

步骤106：该SMSC将接收到的该消息前传通知下发给被叫MS。

步骤107：被叫MS发送应答消息Deliver_Ack给该SMSC。

步骤108：该SMSC发送应答消息Deliver_Ack给上述DCS。

步骤109：该DCS发送含有下发状态标志的MO(Message Originate)消息给本地DSC数据库，将该主叫MS的提交消息保存到该主叫MS的短消息发送箱中。

步骤110：该DCS发送含有下发状态标志的MT(Message Terminate)消息给本地DSC数据库，将该主叫MS的提交消息保存到该被叫MS的短消息接收箱中。

由上述步骤可见，在现有技术方案中，主叫MS和被叫MS能够通过本地DSC实现了短消息的网络存储。

然而，传统的短消息业务中，短消息本身并不包含电话号码和IP地址以外的用户标识信息(例如用户姓名)的对应关系，而该业务也不要求建立端到端的业务路径，因而不可能将短消息携带的用户地址信息进行扩展，例如，采用SMPP_3.4协议的短消息所携带的发送方和接收方地址信息是最大为21个字节的地址字符串，其格式为数字电话号码或者IP地址(例如“aaa.bbb.ccc.ddd”)。这就意味着，以这种传统短消息业务为基础的短消息网络存储是无法通过短消息本身获得除电话号码和IP地址以外的用户标识信息的。

如果短消息网络存储没有额外的手动更新和维护用户联系人地址本功能，那么，用户通过网络存储重新获取的短消息中，发送方和接收方标识将是用户难以识别的电话号码或者IP地址，无法满足一般用户需求。还有一些用户仅需要使用网络存储查看短消息的收发情况，再选择短消息发送、邮件发送、语音呼叫，或者媒体发送的操作，这种情况下，用户标识信息难以识别的问题将极大的降低通信业务的质量和客户体验满意度。

鉴于终端存储能力有限，存储容易受损等问题，业界已考虑提供电话本的网络存储功能。用户可以通过管理网络联系人列表、进行群组划分、用户设置等操作。实现用户本地电话本的网络存储有以下几种方法：

1.通过终端与PC机的硬件接口，将联系人列表(Contact list)文件传至PC机，再由PC机将其按照统一格式上传至网络侧；

2.通过无线传送，将保存在终端上的本地电话本进行消息格式转化后，将转化获得的消息，例如彩信(MMS，Multimedia Message Service)、短消息，或者名片(profile)，传递到网络侧，并采用一定的更新策略；

3.网络侧根据用户的业务信息，例如语音呼叫、SIP(Session InitiationProtocol，会话发起协议)消息的发送等，来收集联系人列表，以及电话号码、IP地址、SIP地址与用户姓名的对应关系等信息。当然，由于短消息本身不能携带用户地址信息以外的更多用户标识信息，因此这种方法暂时还不适用于短消息业务。

由上可见，网络联系人列表的内容具有可扩展性，也已经有相应的实现方案，因此，通过电话本的网络存储功能来丰富和辅助短消息的网络存储功能是可行的。

目前，开放移动联盟(OMA，Open Mobile Alliance)的新课题——融合消息业务(CPM，Converged IP Message)的系统架构也提供CPM消息网络存储(Message Network Storage)的功能。

图2为现有技术的CPM网络架构模型示意图，如图2所示，该架构提供了媒体和消息网络存储(Media & Message Storage)功能单元，其主要功能单元及在架构中的作用如下：

CPM会话服务器(CPM Conversation Server)单元，作为CPM网络中对CPM业务进行处理的业务服务器。该单元通过与业务支撑组件(Supporting Enables)之间的接口，来使用各种网络中提供的已有的业务能力单元；通过与CPM用户喜好功能(CPM User Preference)单元之间的接口，来获取CPM用户保存在网络中的有关喜好等的设置信息；通过与第三方应用(Third Party Application)之间的接口，来CPM用户与第三方应用的互通。该单元还分别与媒体和消息存储单元、融合地址本(ConvergedAddress Book)单元有直接接口。此外，通过SIP/IP核心(SIP/IP Core)单元的转换，CPM会话服务器单元可以与CPM客户端(CPM Client)、远端CPM网络(Remote CPM Environment)进行通信。

互通功能(Interworking Function)单元，作为连接CPM会话服务器与非CPM消息业务的功能单元，一方面负责接收来自CPM会话服务器的消息，并将该消息转换为与其接口的非CPM消息业务支持的协议格式，例如SMS、MMS、IMPS、EMAIL等，再发送到相应的消息网络中；另一方面，负责接收来自与其接口的非CPM业务(Non-CPM Service)网络的消息，并将该消息转换为CPM消息，再发送给CPM会话服务器。

媒体和消息存储单元，作为CPM用户放置在网络中的存储数据库，既可以从CPM客户端收集需保存的媒体和消息，又可以根据CPM用户的指示为其他CPM用户开放权限，提供媒体和消息的访问或者下载。其他CPM用户对该CPM用户的媒体和消息存储内容的使用是通过CPM会话服务器实现的。

融合地址本(Converged Address Book)单元，分别与CPM会话服务器、CPM客户端、业务支撑组件有直接接口，是保存融合CPM用户各个终端上的地址信息的功能单元。该单元是CPM架构中网络联系人列表的对应实体。

由上可见，CPM网络架构模型是CPM业务实现的一个高层功能性框架，该架构能够提供CPM消息的网络存储功能，而该功能的实现也需要该架构与现有消息系统互通；相应的，现有消息系统中的短消息、彩信等媒体和消息也需要能够在CPM架构中进行正常的网络存储，即呈现给用户容易识别的，更加丰富的联系人信息，例如短消息发送方的用户名称，Email地址等。然而，现有技术中还没有解决上述问题的技术手段和方案。

由上述公开的技术方案可知，现有技术的缺陷在于缺少媒体和消息网络存储和网络联系人列表中用户联系人信息的关联方法，用户对短消息等业务的体验较差。同时，网络资源的利用率较低，新业务的出现将进一步增加网络负荷和操作复杂度。

发明内容

有鉴于此，本发明的目的在于提供获取用户联系人信息的方法和系统，从而实现媒体和消息网络存储与网络联系人列表之间用户联系人信息的获取和同步。

本发明实施例提供一种获取用户联系人信息的方法，包括以下步骤：

媒体和消息网络存储单元和网络联系人列表单元之间设置直接接口；

所述媒体和消息网络存储单元或网络联系人列表单元通过所述直接接口获取所述用户联系人信息。

本发明另一实施例提供一种获取用户联系人信息的方法，包括以下步骤：

在媒体和消息网络存储单元和网络联系人列表单元之间设置应用服务器；

所述媒体和消息网络存储单元或网络联系人列表单元通过所述应用服务器获取所述用户联系人信息。

本发明另一实施例提供一种获取用户联系人信息的系统，该系统包括：

媒体和消息网络存储单元，用于向网络联系人列表单元发起用户联系人信息的查询；

所述网络联系人列表单元，用于将所述用户联系人信息反馈给所述媒体和消息网络存储单元。

本发明另一实施例提供一种获取用户联系人信息的系统，该系统包括：

媒体和消息网络存储单元，用于向应用服务器单元发送用户联系人信息的查询请求消息；

网络联系人列表单元，用于将携带所述用户联系人信息的反馈消息发送给所述应用服务器单元；

应用服务器单元，用于发送所述查询请求消息给所述网络联系人列表单元，以及发送所述反馈消息给所述媒体和消息网络存储单元。

本发明实施例通过媒体和消息网络存储单元与网络联系人列表单元之间关于用户联系人信息的获取和同步，解决了用户联系人信息的获取范围受限于用户终端中信息存储量和稳定性较差的问题。同时，提高了网络资源的利用率，改善了用户查阅媒体和消息的体验。

附图说明

图1为现有技术的短消息网络存储业务流程示意图；

图2为现有技术的CPM网络架构模型示意图；

图3为本发明实施例的直接接口示意图；

图4为本发明实施例一的示意图；

图5为本发明实施例二的示意图；

图6为本发明实施例三的示意图；

图7为本发明实施例的通过应用服务器实现用户联系人信息获取的示意图；

图8为本发明实施例四的示意图；

图9为本发明实施例五的示意图；

图10为本发明实施例六的示意图；

图11为本发明实施例七的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图3为本发明实施例的直接接口示意图。如图3所示，建立媒体和消息网络存储单元与网络联系人列表单元之间的直接接口，并定义该接口为直接接口X1，本发明实施例可以通过该接口保证上述两个单元关于用户联系人信息的获取和同步。

图4为本发明实施例一的示意图，本实施例通过移动数据同步化(SyncML，Synchronization Markup Language)协议实现媒体和消息网络存储单元与网络联系人列表单元之间关于用户联系人信息的同步。SyncML协议的数据表示法定义了一个基于可扩展标记语言(XML，Extensible MarkupLanguage)的文件类型定义，基于这样的类型定义，可以表示所有同步中所需的信息。SyncML的数据格式由一套服务器客户端都能解释的消息来定义，这些消息被描述成有组织的XML文档。

如图4所示，媒体和消息存储单元的应用程序A需要与网络联系人列表单元的应用程序B进行数据同步。如果将应用程序A作为数据同步的服务器，应用程序B作为客户端，那么，应用程序B至应用程序A的单向数据同步实现过程如下：

首先，应用程序A与应用程序B通过直接接口X2建立连接，且应用程序A和应用程序B遵循同一协议，例如HTTP。

当应用程序B的网络联系人列表更新或者处理用户数据时，该应用程序B通过同步客户端代理(Sync Client Agent)向应用程序A发送数据同步操作请求。该请求经底层网络传输至应用程序A的同步服务器代理(SyncServer Agent)。该同步服务器代理负责控制应用程序A的同步引擎(SyncEngine)根据协议对该请求消息进行处理，并通过系统函数调用控制数据同步的实现。在数据同步过程中，同步协议适配器(SyncML Adapter)负责处理同步消息的连接、发送与接收。

本实施例中，媒体和消息网络存储单元中也保存了一个用户联系人信息的列表a(图中未示出)，以备媒体和消息网络存储单元的内部应用；该列表a中保存的用户联系人信息可以是网络联系人列表单元中用户联系人信息列表b(图中未示出)的子集。例如，上述列表b中保存中用户联系人的全部相关信息：电话号码/IP地址、用户姓名、用户E-mail地址、MSN账号、家庭电话、办公电话、传真号、所属的群组(家人、朋友、同事)等；而上述列表a中可以仅保存用户联系人的部分相关信息：电话号码/IP地址、用户姓名、用户E-mail地址。

与现有技术相比，本实施例中的网络联系人列表单元将更新的用户联系人信息通过直接接口同步至媒体和消息网络存储单元，从而使媒体和消息网络存储单元能够为用户提供更加丰富的用户联系人信息，例如，不再是无法识别的电话号码，而是便于识别的用户名称、E-mail地址等信息。

在应用程序B至应用程序A的单向数据同步情况下，用户可以为某种应用保存专属的用户联系人信息。例如，用户可以在媒体和消息网络存储单元的应用中保存用户昵称，或者修改其他用户联系人信息，而这些操作不会影响网络联系人列表单元中应用的用户联系人信息。

本领域的技术人员可以理解的，在应用程序A至应用程序B的单向数据同步的实现过程中，应用程序B将作为数据同步的服务器，而应用程序A将作为客户端，其实现过程与上述实施例相似，不再赘述。

在应用程序B到应用程序A的单向数据同步情况下，用户可以通过在应用程序B中进行用户联系人信息修改，实现对应用程序A中的用户联系人信息的间接修改。本领域的技术人员可以理解的，在应用程序A到应用程序B的单向数据同步情况下，用户可以通过在应用程序A中进行用户联系人信息修改，实现对应用程序B中的用户联系人信息的间接修改。

上述两种数据同步方法可以根据应用场景的不同而加以选择。例如，用户对应用程序A中的用户联系人信息进行修改后，系统向用户发出修改确认请求，以确定是否将此修改同步到应用程序B中。

图5为本发明实施例二的示意图，本实施例通过集成参考点(IRP，Integration Reference Point)协议实现媒体和消息网络存储单元与网络联系人列表单元之间关于用户联系人信息的获取。

如图5所示，媒体和消息网络存储单元中保存了用户联系人信息(UserContact Information)列表。当媒体和消息网络存储单元有新的存储消息时，首先进行用户联系人信息的单元内部查询。如果该查询失败，即用户联系人信息列表中没有该用户联系人信息，则执行如下步骤：

步骤501：媒体和消息网络存储单元通过网络查询接口X3主动向网络联系人列表单元发送集成参考点通知请求消息IRP Request，查询的关键字可以是电话号码或IP地址，该消息用于请求获取与关键字对应的用户联系人信息。

步骤502：网络联系人列表单元接收到该请求消息后，发送应答消息IRPCommand，该消息携带关键字对应的用户联系人信息，媒体和消息网络存储单元接收到该消息后，一方面将其显示在存储的媒体和消息的发送方/接收方标识中，另一方面将其保存在媒体和消息网络存储单元中的用户联系人信息单元中。

本实施例中，媒体和消息网络存储单元与网络联系人列表单元的数据获取过程可以由媒体和消息网络存储单元主动发起，也可以是网络联系人列表单元应媒体和消息网络存储单元的需求，提供相关信息的定时更新。此外，媒体和消息网络存储单元中的联系人信息列表可以是网络联系人列表单元中的联系人信息的子集。例如，网络联系人列表单元中保存用户联系人相关的所有信息：电话号码/IP地址、用户姓名、用户E-mail地址、MSN账号、家庭电话、办公电话、传真号、所属的群组(家人、朋友、同事)等；而媒体和消息网络存储单元中仅保存用户联系人相关的以下信息：电话号码/IP地址、用户姓名、用户E-mail地址。

上述实施例中用户联系人信息的数据同步方法仅是可能的实现协议举例。在实际应用中，运营商可以根据网络规划和业务模式选择对用户联系人信息单元中数据的内容进行扩充和有选择的进行同步，也可以根据用户的需求实现上述两个单元之间的用户联系人信息的动态获取，而不更改单元中的保存信息。

上述实施例的应用场景可以是，用户甲在海外出差期间通过Web网络读取其在网络上的短消息网络存储内容，得知用户乙给他的一个短消息，需要商量一个重要的度假计划。用户甲觉得国际长途太贵了，短消息也说不清楚，E-mail不便于实时交流，于是，用户甲通过查询用户乙的用户联系人信息，获得用户乙的MSN账号，经MSN实时交流，从而把度假的计划确定下来。这时，用户乙的MSN账号可以保存在用户甲的单元A中，也可以只是暂时应用户甲的请求呈现给用户甲，而不保存在用户甲的单元A中。

图6为本发明实施例三的示意图，本实施例与实施例二的区别在于，媒体和消息网络存储单元中没有用户联系人信息列表的存储。当媒体和消息网络存储单元有新的存储消息时，媒体和消息网络存储单元没有内部的用户联系人信息查询过程，而是直接通过网络查询接口X4发送携带查询关键字的集成参考点通知请求消息IRP Request给网络联系人列表单元，如步骤601所示。在步骤602中，网络联系人列表单元接收到该请求消息后，发送应答消息IRP Command，该消息携带上述查询关键字对应的用户联系人信息，媒体和消息网络存储单元接收到该消息后，并不保存该用户联系人信息，而是仅将其显示在媒体和消息网络存储的发送方/接收方标识中。

本实施例中，媒体和消息网络存储单元与网络联系人列表单元之间的数据获取是网络联系人列表单元至媒体和消息网络存储单元的单向的用户联系人信息数据获取，即用户可以在媒体和消息网络存储单元中编辑和更改用户联系人信息，例如将姓名改为“昵称+姓名”，这些操作不会影响到网络联系人列表单元中网络联系人列表的存储信息。

图7为本发明实施例的通过应用服务器实现用户联系人信息获取的示意图。如图7所示，媒体和消息网络存储单元通过应用服务器从网络联系人列表单元中获取用户联系人信息，从而保证媒体和消息网络存储单元中的媒体和消息网络存储能够呈现给用户更加丰富的用户联系人信息。上述应用服务器可以是CPM会话服务器，或者网络中处理网络联系人信息交互的专用应用服务器逻辑单元。

图8为本发明实施例四的示意图，本实施例利用CPM会话服务器作为应用服务器，媒体和消息网络存储通过该CPM会话服务器来获取融合地址本单元中的用户联系人信息，在SMS短消息中添加和更新了用户联系人信息后进行网络存储，因此，用户从网络存储中查看到该消息时，能够得到便于识别的用户信息显示，例如用户姓名等。

如图8所示，当CPM业务网络收到来自非CPM业务网络的SMS短消息时，执行以下步骤：

步骤801：互通功能单元接收到非CPM业务发出的SMS短消息，将其进行格式转换，生成CPM消息。

步骤802：该CPM消息经过SIP/IP核心单元发送至CPM会话服务器单元。

步骤803：CPM会话服务器单元接收到该CPM消息后，向融合地址本单元发起用户联系人信息查询。

步骤804：融合地址本单元将该消息对应的用户联系人信息反馈给CPM会话服务器单元。

例如，在步骤803中，CPM会话服务器单元可以发送集成参考点通知请求消息给融合地址本单元，查询的关键字可以是电话号码或者IP地址。在步骤804中，融合地址本单元接收到来自CPM会话服务器单元的请求后，发送回应消息IRP Command，并返回关键字对应的用户联系人信息。

步骤805：CPM会话服务器单元根据获取的用户联系人信息对CPM消息进行更新，并通过控制逻辑判断将该CPM消息存储到媒体和消息网络存储单元中。

由上述步骤可知，传统的SMS短消息经过一系列的转换和更新后，以CPM消息的格式存储在媒体和消息网络存储单元中，而且包含了更加容易识别的用户联系人信息。

本实施例的应用场景还可以是，正在浏览网络存储内容的用户可以通过向应用服务器发出查询网络联系人列表中某个用户更加丰富的信息来满足业务需要。例如，某用户甲阅读了网络存储中来自乙的短消息，却想给乙回复一个E-mail，这个时候，用户就需要获取乙的E-mail地址。

如图9所示为本发明实施例五的示意图，是通过应用服务器来获取用户联系人信息的一个场景。

应用服务器检测到新的媒体或消息的存储时，进一步检测该媒体或消息的格式是否合要求，例如，是否有媒体或消息发送方的具体用户名。如果应用服务器发现需要进一步获取用户联系人信息，则执行以下步骤：

步骤903：应用服务器向网络联系人列表单元发起用户联系人信息的查询。

步骤904：网络联系人列表单元向应用服务器返回用户联系人信息。

步骤905：应用服务器利用获取的用户联系人信息，对即将存入媒体和消息网络存储单元的媒体或消息进行更新，并将更新后的媒体或消息发送给媒体和消息网络存储单元。

步骤906：媒体和消息网络存储单元接收到更新后的媒体或消息后，发送反馈消息给应用服务器。

如图10所示为本发明实施例六的示意图。本实施例包括以下步骤：

步骤1001：用户终端将媒体和消息内容存储至媒体和消息网络存储单元。

步骤1002：媒体和消息网络存储单元首先进行用户联系人信息的单元内部查询，如果该查询失败，即向应用服务器发送查询请求消息，查询的关键字可以是电话号码或IP地址，该消息用于请求获取与关键字对应的用户联系人信息。

步骤1003：应用服务器将上述查询请求消息转发给网络联系人列表单元。

步骤1004：网络联系人列表单元将用户联系人信息反馈给应用服务器。

步骤1005：应用服务器将用户联系人信息转发给媒体和消息网络存储单元。媒体和消息网络存储单元将该用户联系人信息显示在存储的媒体和消息的发送方/接收方标识中，并将其保存在媒体和消息网络存储单元中的用户联系人信息单元中。

本实施例中，应用服务器可以是CPM会话服务器，或者网络中处理网络联系人信息交互的专用应用服务器逻辑单元。

图11为本发明实施例七的示意图，本实施例与实施例六的区别在于，媒体和消息网络存储单元中没有用户联系人信息列表的存储。当媒体和消息网络存储单元有新的存储消息时，媒体和消息网络存储单元没有内部的用户联系人信息查询过程，而是直接发送携带查询关键字的查询请求消息给应用服务器，如步骤1102所示。在步骤1105中，媒体和消息网络存储单元接收到应用服务器转发的用户联系人信息后，并不保存该用户联系人信息，而是仅将其显示在媒体和消息网络存储的发送方/接收方标识中。本实施例中的步骤1101、1103和1104与实施例六中的相应步骤1001、1003和1004相同，不再赘述。

本发明实施例八提供一种获取用户联系人信息的系统，该系统包括媒体和消息网络存储单元与网络联系人列表单元。其中，媒体和消息网络存储单元包括：消息发送模块，用于向网络联系人列表单元发送查询请求消息；消息接收模块，用于接收网络联系人列表单元的反馈消息。网络联系人列表单元包括：消息接收模块，用于接收媒体和消息网络存储单元的查询请求消息；信息查询模块，用于在该单元内部进行用户联系人信息的查询；消息发送模块，用于向媒体和消息网络存储单元发送携带用户联系人信息的反馈消息。

本发明实施例九提供一种获取用户联系人信息的系统。该系统与实施例七的区别在于，本实施例中的媒体和消息网络存储单元还包括信息更新模块，用于更新该单元中的用户联系人信息列表。

本发明实施例十提供一种获取用户联系人信息的系统，该系统包括媒体和消息网络存储单元、网络联系人列表单元和应用服务器单元。其中，媒体和消息网络存储单元包括：消息发送模块，用于向应用服务器单元发送查询请求消息；消息接收模块，用于接收应用服务器单元的反馈消息。网络联系人列表单元包括：消息接收模块，用于接收应用服务器单元的查询请求消息；信息查询模块，用于在该单元内部进行用户联系人信息的查询；消息发送模块，用于向应用服务器单元发送携带用户联系人信息的反馈消息。应用服务器单元包括：第一消息接收模块，用于接收媒体和消息网络存储单元的查询请求消息；第一消息发送模块，用于向网络联系人列表单元发送查询请求消息，或者转发来自第一消息接收模块的查询请求消息；第二消息接收模块，用于接收网络联系人列表的反馈消息；第二消息发送模块，用于向媒体和消息网络存储单元发送反馈消息。

本发明实施例十一提供一种获取用户联系人信息的系统。该系统与实施例九的区别在于，本实施例中的媒体和消息网络存储单元还包括信息更新模块，用于更新该单元中的用户联系人信息列表。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (24)

1.一种获取用户联系人信息的方法，其特征在于，包括以下步骤：

在媒体和消息网络存储单元和网络联系人列表单元之间设置直接接口；

所述媒体和消息网络存储单元或网络联系人列表单元通过所述直接接口获取所述用户联系人信息。

2.根据权利要求1所述的方法，其特征在于，

所述网络联系人列表单元将更新的用户联系人信息通过所述直接接口同步至所述媒体和消息网络存储单元。

3.根据权利要求2所述的方法，其特征在于，

所述网络联系人列表单元更新或者处理用户数据时，通过同步客户端代理向所述媒体和消息网络存储单元发送数据同步请求；

所述数据同步请求经底层网络传输至所述媒体和消息网络存储单元的同步服务器代理单元；

所述同步服务器代理单元控制所述媒体和消息网络存储单元的同步引擎对所述数据同步请求进行处理。

4.根据权利要求1所述的方法，其特征在于，

所述媒体和消息网络存储单元对于所述用户联系人信息的修改或者更新通过所述直接接口同步至所述网络联系人列表单元。

5.根据权利要求1所述的方法，其特征在于，

所述媒体和消息网络存储单元通过所述直接接口向所述网络联系人列表单元发起用户联系人信息的查询；

所述网络联系人列表单元通过所述直接接口向所述媒体和消息网络存储单元反馈所述用户联系人信息。

6.根据权利要求5所述的方法，其特征在于，

所述媒体和消息网络存储单元将所述用户联系人信息的内容显示在所述媒体和消息网络存储单元中的媒体和消息中。

7.根据权利要求6所述的方法，其特征在于，

所述媒体和消息网络存储单元进一步包括用户联系人信息列表；

所述媒体和消息网络存储单元对所述用户联系人信息列表进行的内部查询失败后，发送用户联系人信息的查询请求消息给所述网络联系人列表单元；

所述媒体和消息网络存储单元收到所述网络联系人列表单元反馈的所述用户联系人信息后，将所述用户联系人信息的内容保存在所述用户联系人信息列表中。

8.根据权利要求5、6或7所述的方法，其特征在于，

所述查询的关键字是电话号码或者IP地址。

9.一种获取用户联系人信息的方法，其特征在于，包括以下步骤：

在媒体和消息网络存储单元和网络联系人列表单元之间设置应用服务器；

所述媒体和消息网络存储单元或网络联系人列表单元通过所述应用服务器获取所述用户联系人信息。

10.根据权利要求9所述的的方法，其特征在于，

所述应用服务器为融合消息业务会话服务器，或者网络中处理网络联系人信息交互的专用应用服务器逻辑单元。

11.根据权利要求9所述的方法，其特征在于，

所述应用服务器向所述网络联系人列表单元发起用户联系人信息的查询；

所述网络联系人列表单元通过所述应用服务器反馈所述用户联系人信息给所述媒体和消息网络存储单元。

12.根据权利要求9所述的方法，其特征在于，

所述媒体和消息网络存储单元通过所述应用服务器发送用户联系人信息的查询请求消息给所述网络联系人列表单元；

所述网络联系人列表单元通过所述应用服务器反馈所述用户联系人信息给所述媒体和消息网络存储单元。

13.根据权利要求12所述的方法，其特征在于，

所述媒体和消息网络存储单元将所述用户联系人信息的内容显示在所述媒体和消息网络存储单元中的媒体和消息中。

14.根据权利要求13所述的方法，其特征在于，

所述媒体和消息网络存储单元进一步包括用户联系人信息列表；

所述媒体和消息网络存储单元对所述用户联系人信息列表进行的内部查询失败后，发送用户联系人信息的查询请求消息给所述应用服务器；

所述应用服务器将所述查询请求消息转发给所述网络联系人列表单元；

所述网络联系人列表单元通过所述应用服务器反馈所述用户联系人信息给所述媒体和消息网络存储单元；

所述媒体和消息网络存储单元将所述用户联系人信息的内容保存在所述用户联系人信息列表中。

15.根据权利要求11、12、13或14所述的方法，其特征在于，

所述查询的关键字是电话号码或者IP地址。

16.一种获取用户联系人信息的系统，其特征在于，该系统包括：

媒体和消息网络存储单元，用于向网络联系人列表单元发起用户联系人信息的查询；

所述网络联系人列表单元，用于将所述用户联系人信息反馈给所述媒体和消息网络存储单元。

17.根据权利要求16所述的系统，其特征在于，所述媒体和消息网络存储单元包括：

消息发送模块，用于向所述网络联系人列表单元发送查询请求消息；

消息接收模块，用于接收所述网络联系人列表单元反馈的用户联系人信息。

18.根据权利要求16所述的系统，其特征在于，所述网络联系人列表单元包括：

消息接收模块，用于接收所述媒体和消息网络存储单元的所述查询请求消息；

信息查询模块，用于在所述网络联系人列表单元内部对所述用户联系人信息进行查询；

消息发送模块，用于向所述媒体和消息网络存储单元发送所述用户联系人信息。

19.根据权利要求16所述的系统，其特征在于，

所述媒体和消息网络存储单元进一步包括信息更新模块，用于更新所述媒体和消息网络存储单元中的用户联系人信息列表。

20.一种获取用户联系人信息的系统，其特征在于，该系统包括：

媒体和消息网络存储单元，用于向应用服务器单元发送用户联系人信息的查询请求消息；

网络联系人列表单元，用于将携带所述用户联系人信息的反馈消息发送给所述应用服务器单元；

应用服务器单元，用于发送所述查询请求消息给所述网络联系人列表单元，以及发送所述反馈消息给所述媒体和消息网络存储单元。

21.根据权利要求20所述的系统，其特征在于，所述媒体和消息网络存储单元包括：

消息发送模块，用于向所述应用服务器单元发送查询请求消息；

消息接收模块，用于接收所述应用服务器单元的反馈消息。

22.根据权利要求20所述的系统，其特征在于，

所述媒体和消息网络存储单元进一步包括信息更新模块，用于更新所述媒体和消息网络存储单元中的用户联系人信息列表。

23.根据权利要求20所述的系统，其特征在于，所述网络联系人列表单元包括：

消息接收模块，用于接收所述应用服务器单元的查询请求消息；

信息查询模块，用于在所述网络联系人列表单元内部对所述用户联系人信息进行查询；

消息发送模块，用于向所述应用服务器单元发送携带所述用户联系人信息的反馈消息。

24.根据权利要求20所述的系统，其特征在于，所述应用服务器单元包括：

第一消息接收模块，用于接收所述媒体和消息网络存储单元的查询请求消息；

第一消息发送模块，用于向所述网络联系人列表单元发送查询请求消息；

第二消息接收模块，用于接收所述网络联系人列表的反馈消息；

第二消息发送模块，用于向所述媒体和消息网络存储单元发送反馈消息。

Images