CN102469144B - 实现多个系统通讯录数据融合的方法及系统 - Google Patents

Abstract

本发明公开一种实现多个系统通讯录数据融合的方法及系统，包括：设置保存有统一通讯录的统一通讯录平台系统；对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；在统一通讯录平台系统接收业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则结束流程；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据下发到其他业务系统。通过本发明能够有效的融合各个应用系统以及用户终端中存储的个人通讯录数据，实现个人通讯录和企业通讯录的整合。

Description

实现多个系统通讯录数据融合的方法及系统

技术领域

本发明涉及系统间数据同步技术，特别是指一种实现多个系统通讯录数据融合的方法及统一通讯录平台系统。

背景技术

随着通信助理类应用及个人手持终端的发展，个人通讯录数据越来越多的被认为分散到各个孤立的终端(如：手机、PDA等)及应用(如：邮箱、办公系统等)中，从而形成了大量各自独立、无法互通的数据孤岛。同时不同类型的、针对不同用户群的应用分别保存了一部分的个人通信录，如针对企业的办公系统保存了企业员工的企业通信录(同事)，而个人助理、PIM等应用则保存了个人的个人通信录。过于分散的数据为用户使用各通讯录相关应用时造成了极大的不便，同时各个应用及终端间无法完成数据同步，也造成了用户无法完全掌握自己的通讯录数据。

目前，业界成熟通用的通讯录同步技术主要有两种：SyncML(Synchronization Markup Language)及ActiveSync。这两种通讯录同步技术分别由Open Mobile Alliance及微软公司制定，其主要局限在于：

现有的这两种技术主要应用均是为了完成手持移动终端与PC(个人电脑)或互联网服务之间的数据同步工作，仅能实现一对一的数据同步，无法对多个应用间的数据进行同步和融合。

通过SyncML和ActiveSync发起的同步过程中的双方是客户端和服务器的关系，数据以某一方为准，而当用于应用系统间数据同步时，难以保证数据安全性。

SyncML和ActiveSync均要求遵循统一的特定通讯录格式，超出该格式的数据将无法完成同步。但是目前现存大量应用的通讯录数据格式无法完全转换为其规定的统一格式。

发明内容

有鉴于此，本发明的目的在于提出一种实现多个系统通讯录数据融合的方法及统一通讯录平台系统，能够有效的融合各个应用系统以及用户终端中存储的个人通讯录数据，实现个人通讯录和企业通讯录的整合。

基于上述目的本发明提供的一种实现多个系统通讯录数据融合的方法，包括：

设置保存有统一通讯录的统一通讯录平台系统；

对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；

在统一通讯录平台系统接收业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则结束流程；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据下发到其他业务系统。

可选的，该方法将帐号对应的联系人基础信息存储在一数据库横表中，将通讯录联系人的详细信息保存在另一数据库纵表中；

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个业务系统数据字段与统一通讯录的属性名之间的对应关系。

可选的，该方法如果所述通讯录数据上报请求所请求的为新增或者删除现有通讯录数据，则统一通讯录平台系统直接对现有通讯录数据执行相应的操作；

如果所述通讯录数据上报请求所请求的为对现有通讯录数据进行修改，则将该上报请求中的通讯录数据与现有通讯录数据进行字段合并，保存合并后的数据，对无法合并的进行冲突控制处理。

可选的，该方法所述字段合并处理过程，包括如下步骤：

步骤601，对于通讯录数据中的一个字段f，判断当前上行通讯录数据中的该字段f与统一通讯录平台系统中当前保存的通讯录数据中对应的字段f是否相同，即是否CurVer.f＝NewVer.f，如果是，则直接进入步骤603；否则进入步骤602；

步骤602，判断当前上行的通讯录数据中的所述字段f与统一通讯录平台系统中对应的历史版本中的字段f是否相同，即是否CurVer.f＝HisVer.f，如果是，则进入步骤603；否则，进入步骤604；

步骤603，对统一通讯录平台系统中的数据不作更新，以CurVer.f为准，将NewVer.f修改为CurVer.f，然后直接进入步骤607；

步骤604，判断统一通讯录平台系统中当前保存的通讯录数据版本中的f字段f与历史版本中的f字段是否相同，即是否CurVer.f＝HisVer.f，如果是，则进入步骤605；否则，进入步骤606；

步骤605，对统一通讯录平台系统中数据的f字段以当前上行通讯录数据中的f字段为准，进行更新，即保留NewVer.f值不变，进入步骤607；

步骤606，标记该字段f的上行存在冲突，结束字段合并流程；

步骤607，判断是否还有没进行合并处理的字段，如果是，则返回步骤601对下一个字段执行以上步骤，否则，结束字段合并流程；

所述的冲突控制处理过程，包括如下步骤：

步骤701，按照步骤601-607的方法比较NewVer、CurVer与HisVer三个记录中每一个字段的内容，进行字段合并；

步骤702，如果字段合并产生冲突，则生成冲突记录：保持同步服务器上的版本记录不变，将NewVer转换为新增联系人操作，新增一个联系人记录，将其shared字段设置为非共享，并为其生成一个冲突通知记录和一个下行通知记录；

步骤703，如果字段合并没有发现字段内容更改，无需更新；

步骤704，如果字段合并发现字段内容更改，但未产生冲突，则合并得到一个最终的联系人记录并更新为当前记录，该记录的版本在原来的基础上增1；

步骤705，冲突记录在数据下行时由同步服务器发送给同步方，同步方可根据业务需求处理冲突记录，完成通讯录数据同步的冲突控制。

可选的，该方法所述判断该上报请求中的通讯录数据是否与现有通讯录数据一致的过程包括：统一通讯录平台系统判断发送通讯录数据上报请求的业务系统是否与上次请求更新的业务系统相同，如果是，则判定为一致；否则，继续判断该上报请求的通讯录数据的版本号与当前统一通讯录平台系统中通讯录数据的版本号是否相同，如果是，则判定为一致，否则判定为不一致。

可选的，该方法所述统一通讯录平台系统将更新后的通讯录数据下发到其他业务系统的过程包括：所述统一通讯录平台系统向其他业务系统发送通讯录数据下行通知；收到该下行通知的业务服务器调用下行接口从统一通讯录平台系统获取更新的通讯录数据；业务服务器更新本地通讯录数据和版本号，调用下行反馈接口，将更新处理结果发送给所述统一通讯录平台系统；所述统一通讯录平台系统向所有业务系统发送同步通知。

可选的，该方法所述统一通讯录平台系统将更新后的通讯录数据下发到其他业务系统后进一步包括：业务系统完成通讯录数据更新后，通过通讯录数据上报请求将更新的通讯录数据上报到统一通讯录平台系统。

基于上述目的，本发明提供的一种实现多个系统通讯录数据融合的统一通讯录平台系统，包括：

接口适配单元，用于提供与各业务系统耦合；

数据存储单元，用于保存通讯录数据，对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；

应用管理单元，用于在通过所述接口适配单元接收到业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则不作处理；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据通过接口适配单元下发到其他业务系统。

可选的，该系统所述数据存储单元中，将帐号对应的联系人基础信息存储在一数据库横表中，将通讯录联系人的详细信息保存在另一数据库纵表中；

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个业务系统数据字段与统一通讯录的属性名之间的对应关系。

可选的，该系统如果所述通讯录数据上报请求所请求的为新增或者删除现有通讯录数据，则所述应用管理单元直接对现有通讯录数据执行相应的操作；

如果所述通讯录数据上报请求所请求的为对现有通讯录数据进行修改，则所述应用管理单元将该上报请求中的通讯录数据与现有通讯录数据进行字段合并，保存合并后的数据，对无法合并的进行冲突控制处理。

可选的，该系统所述应用管理单元中还包括：

安全控制模块，用于通过SSL加密，保障数据通信的安全；

通讯录管理模块，用于管理维护统一通信录平台内的通信录数据，检测数据的可靠性，保证数据可用性；

用户关系管理模块，用于维护个人用户与企业用户之间的所属关系，使得个人用户可以通过接口查询所属企业的企业通信录数据；

应用管理模块，用于管理接入统一通信录平台的各个业务系统，确保各个业务系统只能同步和修改自己的数据。

可选的，该系统所述业务系统包括应用系统和移动终端，所述接口适配单元与移动终端之间通过SyncML协议实现通信；所述接口适配单元与应用系统之间通过自适应同步接口协议实现通信。

可选的，在该系统中包括多个由所述数据存储单元和应用管理单元组成的节点，通讯录数据分散存储在不同的数据存储单元中；

所述接口适配单元中包括分发服务器和接口服务器，接口服务器接收业务系统发送的通讯录数据上报请求后，发送给分发服务器，分发服务器通过Hash算法进行二次路由后，发送到对应节点的应用管理单元进行处理。

从上面所述可以看出，本发明提供的实现多个系统通讯录数据融合的方法及系统，通过构建统一通讯录平台系统，为各个应用平台提供相应的数据接口方式实现各个应用间的数据融合和数据同步，形成一套集通信录读取、维护、优化等功能的完整解决方案。通过采用灵活和扩展的数据模型及高效可变的接口通信协议，有效地融合各个应用系统以及用户手持终端中存储的个人通讯录数据，实现个人通讯录和企业通讯录的整合，使得用户在所有的终端和应用系统中获得统一的数据体验。

具体具备如下优点和效果：

1)可以实现多个应用系统间通讯录数据的同步，使得各个应用系统的用户能够得到统一的数据体验。

2)可以对用户的个人通讯录数据与企业通讯录数据进行融合，使得用户可以在同一界面中同时访问自己个人和企业通讯录。

3)通过采用可扩展的数据模型，使得不同的应用系统间数据可以有效整合并同步。

4)通过采用可扩展和可剪裁的同步接口协议，兼容了各个应用系统数据模型的差异，保证了所有应用系统提交数据的安全性，同时也大幅度减少了数据传输量，提高了系统响应速度。

5)通过分布式架构来保证统一通讯录平台系统的事务处理能力。

附图说明

图1为本发明实施例帐号数据存储结构示意图；

图2为本发明实施例联系人数据存储结构示意图；

图3为本发明实施例实现多个系统通讯录数据融合方法的流程示意图；

图4为本发明实施例统一通讯录平台系统结构示意图；

图5为本发明实施例统一通讯录平台系统部署结构示意图；

图6为本发明实施例字段合并处理过程的流程示意图；

图7为本发明实施例冲突控制处理过程的流程示意图。

具体实施方式

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

本发明提供的一种实现多个系统通讯录数据融合的方法，主要包括：

设置保存有统一通讯录的统一通讯录平台系统；

对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；

在统一通讯录平台系统接收业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则结束流程；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据下发到其他业务系统。

作为一个实施例，所述通讯录数据可划分为帐号数据和联系人数据，通过帐号数据可以索引到每个联系人的联系人数据。

作为一个实施例，将帐号对应的联系人基础信息存储在一数据库横表中，将通讯录联系人的详细信息保存在另一数据库纵表中；

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个业务系统数据字段与统一通讯录的属性名之间的对应关系。

在数据同步的流程中：

作为一个实施例，如果所述通讯录数据上报请求所请求的为新增或者删除现有通讯录数据，则统一通讯录平台系统直接对现有通讯录数据执行相应的操作；

如果所述通讯录数据上报请求所请求的为对现有通讯录数据进行修改，则将该上报请求中的通讯录数据与现有通讯录数据进行字段合并，保存合并后的数据，对无法合并的进行冲突控制处理。

作为一个实施例，所述判断该上报请求中的通讯录数据是否与现有通讯录数据一致的过程包括：统一通讯录平台系统判断发送通讯录数据上报请求的业务系统是否与上次请求更新的业务系统相同，如果是，则判定为一致；否则，继续判断该上报请求的通讯录数据的版本号与当前统一通讯录平台系统中通讯录数据的版本号是否相同，如果是，则判定为一致，否则判定为不一致。

作为一个实施例，所述统一通讯录平台系统将更新后的通讯录数据下发到其他业务系统的过程包括：所述统一通讯录平台系统向其他业务系统发送通讯录数据下行通知；收到该下行通知的业务服务器调用下行接口从统一通讯录平台系统获取更新的通讯录数据；业务服务器更新本地通讯录数据和版本号，调用下行反馈接口，将更新处理结果发送给所述统一通讯录平台系统；所述统一通讯录平台系统向所有业务系统发送同步通知。

作为一个实施例，所述统一通讯录平台系统将更新后的通讯录数据下发到其他业务系统后进一步包括：业务系统完成通讯录数据更新后，通过通讯录数据上报请求将更新的通讯录数据上报到统一通讯录平台系统。

其中，所述业务系统既可以是企业用户等的应用系统，也可以是个人的移动终端等设备，所述接口适配单元与移动终端之间通过SyncML协议实现通信；所述接口适配单元与应用系统之间通过自适应同步接口协议实现通信。

参见图1所示，为保存有帐号数据的帐号表的示例。

在该实施例中，帐号数据以横表形式存放在数据库中，个人帐号与企业帐号分表存放，并形成个人帐号表和企业帐号表。个人帐号表中的个人帐号与企业帐号表中的企业帐号的关系存放于另外一张数据库表中，用于对应个人与企业的关联关系。

通过对个人和企业帐号进行关联，可以将不同类型应用之间的数据进行融合，使得个人用户在使用任意应用时均可以同时访问到自己的公司通讯录和个人通讯录。

参见图2所示，为保存联系人数据的联系人数据表的示例。

在该实施例中，为了兼容已有及将来各个应用和终端的通讯录格式，本实施例采用了可扩展的数据模型。通讯录中联系人的基础信息(包括联系人基本信息如姓名、性别、生日等，以及系统信息如联系人ID、所属帐号、共享设置等)存储在一张数据库横表中，联系人详细信息(如地址、电话等信息)存放在另外的一张数据库纵表中。个人帐号联系人数据与企业帐号联系人数据分表存放。上述生成的数据库横表和数据库纵表共同组成了图2所示的联系人表。

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个应用系统数据字段与统一通信录的属性名(Prop Name)之间的对应关系，具有共性(在多个应用系统中均存在)的属性在各个应用系统间同步，个性化数据(尽在某个应用系统中存在)则只有个别的应用系统进行同步。由于属性表可以不断扩展，因此可以满足所有应用系统在联系人数据模型方面的差异，从而解决了各个应用系统间数据模型差异过大导致的同步困难。

通过帐号表可以索引到联系人表，通过联系人表进而可以索引到联系人属性表。另外，为方便查找，帐号数据表也可以存储一些用户相关的资料，比如用户的姓名、性别等个人资料。

为了保证同步控制数据，作为一个实施例可以采用如下方式：

通讯录联系人记录的数据结构，用于保存当前的联系人记录信息。包含表示联系人基本信息的横向结构，其中包括了一个记录版本号字段，字段名定义为Version；一个记录最近一次更新该记录的系统编号，字段名定义为LastUpdateAppId；一个表示记录是否在多系统间共享的标识字段，记为shared。该结构还包含了表示联系人联系信息、扩展信息的可伸缩的纵向结构。

通讯录联系人历史记录的数据结构，用于保存一个联系人记录上一个版本的信息。包含表示联系人相关信息的若干字段；一个记录版本号字段，字段名定义为Version。

下行通知记录的数据结构，用于保存业务系统需要下行的通讯录数据记录。

数据同步接口协议：

由于各个应用系统的数据模型均不相同，因此本发明采用了可扩展和可剪裁的同步接口协议。接口可以采用JSON或XML等方式实现，以下论述以JSON+HTTP为例。提交的数据为一个JSON数据块，其中包含了操作请求类型、操作数据等。如下数据块为一个完整的新增联系人请求：{″cmd″:″Member_UL″，″parameter″:{″itemlist″:[{″birthday″:″2009-08-1715:36:00″，″source_user_id″:133xxxxxxx，″desc″:″″，″updatetime″:″2009-08-1715:36:21″，″version″:0，″fn″:″张三″，″optype″:1，″source_id″:1，″prop″:[{″prop_name″:1，″desc″:″工作电话1″，″prop_content″:″0203863xxxx″}，{″prop_name″:8，″desc″:″移动电话1″，″prop_content″:″131xxxxxxxx″}{″prop_name″:18，″desc″:″个人爱好″，″prop_content″:″电影″}]}]，″itemsize″:1，″appid″:″1″}}

该请求为appid为“1”的应用系统提交，目的在于为“133xxxxxxx”这个帐号增加一个名为“张三”的联系人，此人工作电话为“0203863xxxx”移动电话为“131xxxxxxxx”个人爱好为“电影”。统一通信录会在数据库中为“133xxxxxxx”这个帐号增加此联系人，同时会将这个联系人的信息通知其他应用系统。

如果appid为“2”的应用系统没有保存用户的个人爱好，但是保存了用户的家庭电话，则此请求变为：{″cmd″:″Member_UL″，″parameter″:{″itemlist″:[{″birthday″:″2009-08-1715:36:00″，″source_user_id″:133xxxxxxx，″desc″:″″，″updatetime″:″2009-08-1715:36:21″，″version″:0，″fn″:″张三″，″optype″:1，″source_id″:1，″prop″:[{″prop_name″:1，″desc″:″工作电话1″，″prop_content″:″0203863xxxx″}，{″prop_name″:8，″desc″:″移动电话1″，″prop_content″:″131xxxxxxxx″}{″prop_name″:5，″desc″:″家庭电话″，″prop_content″:″0208822xxxx″}]}]，″itemsize″:1，″appid″:″2″}}

在修改联系人数据时，应用系统仅提交本应用系统保存的数据，通过将内容制空来删除某属性的数据，如appid为1的应用系统提交一个修改请求：{″cmd″:″Member_UL″，″parameter″:{″itemlist″:[{″birthday″:″2009-08-1715:36:00″，″source_user_id″:133xxxxxxx，″desc″:″″，″updatetime″:″2009-08-1715:36:21″，″version″:0，″fn″:″张三″，″optype″:2，″source_id″:1，″prop″:[{″prop_name″:1，″desc″:″工作电话1″，″prop_content″:″0203554xxxx″}，{″prop_name″:18，″desc″:″个人爱好″，″prop_content″:″″}]}]，″itemsize″:1，″appid″:″1″}}

此请求的产生的结果是，统一通信录会修改“张三”这个联系人的数据，将工作电话1改为“0203554xxxx”，删除个人爱好的数据，但不会修改之前appid为1的业务系统提交的移动电话数据，也不会修改appid为2的业务系统提交的家庭电话数据。

通过可扩展和可剪裁的接口协议，可以兼容各个应用系统数据模型的差异，保证了所有应用系统提交数据的安全性，同时也大幅度减少了数据传输量，提高了系统响应速度。

在数据同步的流程中：

参见图3所示，以一个实施例详细描述通讯录同步处理流程。该流程可分为数据上行、数据下行以及下行反馈三个子流程，具体包含以下步骤：

定义当前上行的通讯录数据的版本为NewVer，统一通讯录平台当前保存的版本为CurVer，历史版本为HisVer。作为一个实施例所述HisVer是CurVer之前的一次版本。

步骤301，业务系统根据上行接口协议向统一通讯录平台系统发送通讯录数据上报请求，发起请求的业务系统编号记为appid。

步骤302，业务系统向统一通讯录平台系统传送需要更新的通讯录数据和当前通讯录数据的版本号。

步骤303，统一通讯录平台系统判断当前请求上行数据的发起者是否与上次更新数据的业务系统相同，即是否appid＝CurVer.LastUpdateAppId，如果当前上行数据的发起者与上次更新数据的是同一业务系统，则结束流程；否则进入步骤304。

步骤304，统一通讯录平台系统判断当前请求的上行数据版本号与本地当前保存的通讯录数据版本号是否相同，即NewVer版本号＝CurVer版本号，如果相同，则结束流程；否则进入步骤305。

步骤305，统一通讯录平台系统对于上行数据中的每一个联系人记录的新增、删除操作直接按新增、删除处理；对于联系人记录的修改操作，则统一通讯录平台系统比较三个版本NewVer、CurVer、HisVer的各个字段，尝试进行字段合并，保存合并后的数据。对于无法合并的记录，进行冲突控制处理。

步骤306，统一通讯录平台系统先将当前版本CurVer保存为HisVer，之后将NewVer保存为当前版本CurVer，版本号增1，并为编号不等于appid的业务系统分别生成一条下行通知记录。

步骤307，业务系统调用下行接口，发起数据下行请求，从该统一通讯录平台系统获取需要的通讯录数据。

步骤308，业务系统将获取到的通讯录数据更新到本地据，并将本地通讯录数据的版本号加1更新本地通讯录数据的版本号。

步骤309，业务系统发起下行反馈请求，对每一个下行记录的处理结果向统一通讯录平台系统进行反馈。

步骤310，统一通讯录平台系统根据保存的下行通知记录，向需要进行数据下行的业务系统发起同步通知。

作为一个实施例，本步骤是在统一通讯录平台系统等待本地所有通讯录数据的都同步完成以后，统一将步骤306中生成的各条下行通知记录下发到需要进行数据下行的业务系统。

步骤311，接收到同步通知的业务系统，向统一通讯录平台系统发送通讯录数据上报请求按步骤301-310与统一通讯录平台系统进行数据同步。

通过步骤311可以确保业务系统与统一通讯录平台系统中的通讯录数据保持同步。

上述步骤305中，所述的字段合并处理过程，参见图6所示，包括如下步骤：

步骤601，对于通讯录数据中的一个字段f，判断当前上行通讯录数据中的该字段f与统一通讯录平台系统中当前保存的通讯录数据中对应的字段f是否相同，即是否CurVer.f＝NewVer.f，如果是，则直接进入步骤603；否则进入步骤602。

步骤602，判断当前上行的通讯录数据中的所述字段f与统一通讯录平台系统中对应的历史版本中的字段f是否相同，即是否CurVer.f＝HisVer.f，如果是，则进入步骤603；否则，进入步骤604。

步骤603，对统一通讯录平台系统中的数据不作更新，以CurVer.f为准，将NewVer.f修改为CurVer.f，然后直接进入步骤607。

步骤604，判断统一通讯录平台系统中当前保存的通讯录数据版本中的f字段f与历史版本中的f字段是否相同，即是否CurVer.f＝HisVer.f，如果是，则进入步骤605；否则，进入步骤606。

步骤605，对统一通讯录平台系统中数据的f字段以当前上行通讯录数据中的f字段为准，进行更新，即保留NewVer.f值不变，进入步骤607。

步骤606，标记该字段f的上行存在冲突，结束字段合并流程。

步骤607，判断是否还有没进行合并处理的字段，如果是，则返回步骤601对下一个字段执行以上步骤，否则，结束字段合并流程。

上述步骤305中，所述的冲突控制处理过程，参见图7所示，包括如下步骤：

步骤701，按照步骤601-607的方法比较NewVer、CurVer与HisVer三个记录中每一个字段的内容，进行字段合并，具体可参见图6所示。

步骤702，判断字段合并是否产生冲突，如果字段合并产生冲突则进入步骤703，否则进入步骤704。

步骤703，生成冲突记录，保持同步服务器上的版本记录不变，将当前的NewVer转换为新增联系人并保存(其中该当前的NewVer是指经过步骤601-607处理后的)，新增一个联系人记录，将其shared字段设置为非共享，并为其生成一个冲突通知记录和一个下行通知记录。冲突记录在数据下行时由同步服务器发送给同步方，同步方可根据业务需求处理冲突记录，完成通讯录数据同步的冲突控制。

其中，作为一个实施例本步骤702可以接在上述步骤604之后。

步骤704，判断字段内容是否有更改，如果字段合并没有发现字段内容更改，无需更新。

步骤705，如果字段合并发现字段内容更改，但未产生冲突，则合并得到一个最终的联系人记录并更新为当前记录，该记录的版本在原来的基础上增1。

在本发明的另一方面，还提供了一种实现多个系统通讯录数据融合的统一通讯录平台系统，参见图4所示，包括：

接口适配单元，用于提供与各业务系统耦合；

数据存储单元，用于保存通讯录数据，对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；

应用管理单元，用于在通过所述接口适配单元接收到业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则不作处理；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据通过接口适配单元下发到其他业务系统。

作为一个实施例，所述数据存储单元中，将帐号对应的联系人基础信息存储在一数据库横表中，将通讯录联系人的详细信息保存在另一数据库纵表中；

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个业务系统数据字段与统一通讯录的属性名之间的对应关系。

作为一个实施例，如果所述通讯录数据上报请求所请求的为新增或者删除现有通讯录数据，则所述应用管理单元直接对现有通讯录数据执行相应的操作；

如果所述通讯录数据上报请求所请求的为对现有通讯录数据进行修改，则所述应用管理单元将该上报请求中的通讯录数据与现有通讯录数据进行字段合并，保存合并后的数据，对无法合并的进行冲突控制处理。

作为一个实施例，所述应用管理单元中还包括：

安全控制模块，通过SSL加密，保障数据通信的安全。

通讯录管理模块，管理维护统一通信录平台内的通信录数据，检测数据的可靠性，保证数据可用性。

用户关系管理模块，维护个人用户与企业用户之间的所属关系，使得个人用户可以通过接口查询所属企业的企业通信录数据。

应用管理模块，管理接入统一通信录平台的各个业务系统，确保各个业务系统只能同步和修改自己的数据。

作为一个实施例，所述业务系统包括业务系统和移动终端，所述接口适配单元与移动终端之间通过SyncML协议实现通信；所述接口适配单元与应用系统之间通过自适应同步接口协议实现通信。

为了实现终端与应用间的通讯录数据同步，本实施例在统一通讯录平台系统中基于SyncML协议构建了终端通讯录同步接口。移动终端与终端通讯录服务接口之间的通信协议为标准的SyncML协议。从而保证了终端与各个应用系统间的数据同步。

统一通讯录平台系统集中了所有通讯录相关应用的数据，形成一个统一的通讯录数据库。数据规模估算如下：

按500万个人用户和10万企业用户计算，平均每个个人拥有50条通讯录记录，一个企业拥有500条通讯录记录，则统一通讯录总数据量达到：

500×50+10×500＝30000万条

以通讯录年更新率30％计算，忙时8小时，则平均每秒钟处理请求：

(3×108×30％)/365/8/3600≈8.6个

鉴于统一通讯录平台系统需要处理海量的通讯录数据及各个应用系统大批量的数据操作请求，统一通讯录平台系统通过使用分布式架构来保证事务处理能力。

参见图5所示，为此，在该统一通讯录平台系统中将所述数据存储单元和应用管理单元组成为一个节点，整个系统可以由多个节点组成Node 0，Node 1……Node n，将通讯录数据分散存储在不同节点的数据存储单元中，较佳地可以平均分布在个节点中。

所述接口适配单元中包括分发服务器(Dispatcher)和接口服务器(Interface Server)，接口服务器接收业务系统发送的通讯录数据上报请求后，发送给分发服务器，分发服务器通过Hash算法进行二次路由后，发送到对应节点的应用管理单元进行处理。

统一通讯录平台系统规模可以通过不断扩展节点的方式得到平滑扩展，从而保证了系统的处理能力及容量。

统一通讯录平台系统中，所有的服务、数据均保证存在2份以上的实例，请求在多个实例中进行负载均衡，当任意一个实例出现故障后，系统会将请求自动路由到正常的实例上，从而保证了系统的高可用特性。

通过采用全文搜索引擎，保证了查询事务的高性能及高灵活性。

例如：中国电信某省已经根据本方案建设了统一通讯录平台系统，数据分布在6个节点上，每个节点使用一对(2个)服务实例，数据在这一对服务实例中保持两个拷贝，同时部署2台请求分发服务器(Dispatcher)及2台接口服务(Interface Server)一共16个服务实例，分布在4台PC服务器主机上，形成一个完整的分布式应用。

统一通讯录平台系统已经融合了该省的个人通信助理平台及企业总机平台通讯录数据，完成了个人通信录数据与企业通讯录数据的关联，已经拥有企业用户5万余户，个人用户超过600万户，并整合了手机通信录服务能力，为用户提供了从终端到应用的统一的通讯录数据体验。

统一通讯录平台系统正在对189邮箱、天翼live及综合办公等应用系统的通讯录数据进行整合，并对更多的手持终端进行适配，以期为更多的用户提供融合的通讯录服务。

应该注意，本发明可在软件和/或软件和硬件的组合中实现，例如用专用集成电路(ASIC)、通用计算机或其他硬件等同物来实现。在一个实施例中，模块或进程可被加载到存储器中并由处理器执行，以实现上述功能。这样，本发明的进程(包括相关联的数据结构)可被存储在计算机可读介质或载波上，例如RAM存储器、磁驱动或光驱动或磁盘等等。

所属领域的普通技术人员应当理解：以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种实现多个系统通讯录数据融合的方法，其特征在于，包括：

设置保存有统一通讯录的统一通讯录平台系统；

对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；其中，所述通讯录数据可划分为帐号数据和联系人数据，通过帐号数据可以索引到每个联系人的联系人数据；

在统一通讯录平台系统接收业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则结束流程；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据下发到其他业务系统。

2.根据权利要求1所述的方法，其特征在于，将帐号对应的联系人基础信息存储在一数据库横表中，将通讯录联系人的详细信息保存在另一数据库纵表中；

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个业务系统数据字段与统一通讯录的属性名之间的对应关系。

3.根据权利要求1所述的方法，其特征在于，如果所述通讯录数据上报请求所请求的为新增或者删除现有通讯录数据，则统一通讯录平台系统直接对现有通讯录数据执行相应的操作；

如果所述通讯录数据上报请求所请求的为对现有通讯录数据进行修改，则将该上报请求中的通讯录数据与现有通讯录数据进行字段合并，保存合并后的数据，对无法合并的进行冲突控制处理。

4.根据权利要求3所述的方法，其特征在于，所述字段合并处理过程，包括如下步骤：

步骤601，对于通讯录数据中的一个字段f，判断当前上行通讯录数据中的该字段f与统一通讯录平台系统中当前保存的通讯录数据中对应的字段f是否相同，即是否CurVer.f＝NewVer.f，如果是，则直接进入步骤603；否则进入步骤602；

步骤602，判断当前上行的通讯录数据中的所述字段f与统一通讯录平台系统中对应的历史版本中的字段f是否相同，即是否CurVer.f＝HisVer.f，如果是，则进入步骤603；否则，进入步骤604；

步骤603，对统一通讯录平台系统中的数据不作更新，以CurVer.f为准，将NewVer.f修改为CurVer.f，然后直接进入步骤607；

步骤604，判断统一通讯录平台系统中当前保存的通讯录数据版本中的f字段f与历史版本中的f字段是否相同，即是否CurVer.f＝HisVer.f，如果是，则进入步骤605；否则，进入步骤606；

步骤605，对统一通讯录平台系统中数据的f字段以当前上行通讯录数据中的f字段为准，进行更新，即保留NewVer.f值不变，进入步骤607；

步骤606，标记该字段f的上行存在冲突，结束字段合并流程；

步骤607，判断是否还有没进行合并处理的字段，如果是，则返回步骤601对下一个字段执行以上步骤，否则，结束字段合并流程；

所述的冲突控制处理过程，包括如下步骤：

步骤701，按照步骤601-607的方法比较NewVer、CurVer与HisVer三个记录中每一个字段的内容，进行字段合并；

步骤702，如果字段合并产生冲突，则生成冲突记录：保持同步服务器上的版本记录不变，将NewVer转换为新增联系人操作，新增一个联系人记录，将其shared字段设置为非共享，并为其生成一个冲突通知记录和一个下行通知记录；

步骤703，如果字段合并没有发现字段内容更改，无需更新；

步骤704，如果字段合并发现字段内容更改，但未产生冲突，则合并得到一个最终的联系人记录并更新为当前记录，该记录的版本在原来的基础上增1；

步骤705，冲突记录在数据下行时由同步服务器发送给同步方，同步方可根据业务需求处理冲突记录，完成通讯录数据同步的冲突控制。

5.根据权利要求1所述的方法，其特征在于，所述判断该上报请求中的通讯录数据是否与现有通讯录数据一致的过程包括：统一通讯录平台系统判断发送通讯录数据上报请求的业务系统是否与上次请求更新的业务系统相同，如果是，则判定为一致；否则，继续判断该上报请求的通讯录数据的版本号与当前统一通讯录平台系统中通讯录数据的版本号是否相同，如果是，则判定为一致，否则判定为不一致。

6.根据权利要求1所述的方法，其特征在于，所述统一通讯录平台系统将更新后的通讯录数据下发到其他业务系统的过程包括：所述统一通讯录平台系统向其他业务系统发送通讯录数据下行通知；收到该下行通知的业务服务器调用下行接口从统一通讯录平台系统获取更新的通讯录数据；业务服务器更新本地通讯录数据和版本号，调用下行反馈接口，将更新处理结果发送给所述统一通讯录平台系统；所述统一通讯录平台系统向所有业务系统发送同步通知。

7.根据权利要求1或5所述的方法，其特征在于，所述统一通讯录平台系统将更新后的通讯录数据下发到其他业务系统后进一步包括：业务系统完成通讯录数据更新后，通过通讯录数据上报请求将更新的通讯录数据上报到统一通讯录平台系统。

8.一种实现多个系统通讯录数据融合的统一通讯录平台系统，其特征在于，包括：

接口适配单元，用于提供与各业务系统耦合；

数据存储单元，用于保存通讯录数据，对通讯录数据中的个人帐号与企业帐号分别保存在不同的帐号表中，将个人帐号与企业帐号的对应关系保存在关系表中；其中，所述通讯录数据可划分为帐号数据和联系人数据，通过帐号数据可以索引到每个联系人的联系人数据；

应用管理单元，用于在通过所述接口适配单元接收到业务系统发送的通讯录数据上报请求后，判断该上报请求中的通讯录数据是否与本地现有通讯录数据一致，如果一致，则不作处理；如果不一致，则根据上报请求中的通讯录数据更新现有通讯录数据，将更新后的通讯录数据通过接口适配单元下发到其他业务系统。

9.根据权利要求8所述的系统，其特征在于，所述数据存储单元中，将帐号对应的联系人基础信息存储在一数据库横表中，将通讯录联系人的详细信息保存在另一数据库纵表中；

联系人属性存放在联系人属性表中，通过制定统一的属性规范，规定各个业务系统数据字段与统一通讯录的属性名之间的对应关系。

10.根据权利要求8所述的系统，其特征在于，如果所述通讯录数据上报请求所请求的为新增或者删除现有通讯录数据，则所述应用管理单元直接对现有通讯录数据执行相应的操作；

如果所述通讯录数据上报请求所请求的为对现有通讯录数据进行修改，则所述应用管理单元将该上报请求中的通讯录数据与现有通讯录数据进行字段合并，保存合并后的数据，对无法合并的进行冲突控制处理。

11.根据权利要求8所述的系统，其特征在于，所述应用管理单元中还包括：

安全控制模块，用于通过SSL加密，保障数据通信的安全；

通讯录管理模块，用于管理维护统一通讯录平台内的通讯录数据，检测数据的可靠性，保证数据可用性；

用户关系管理模块，用于维护个人用户与企业用户之间的所属关系，使得个人用户可以通过接口查询所属企业的企业通讯录数据；

应用管理模块，用于管理接入统一通讯录平台的各个业务系统，确保各个业务系统只能同步和修改自己的数据。

12.根据权利要求8所述的系统，其特征在于，所述业务系统包括应用系统和移动终端，所述接口适配单元与移动终端之间通过SyncML协议实现通信；所述接口适配单元与应用系统之间通过自适应同步接口协议实现通信。

13.根据权利要求8所述的系统，其特征在于，在该系统中包括多个由所述数据存储单元和应用管理单元组成的节点，通讯录数据分散存储在不同的数据存储单元中；

所述接口适配单元中包括分发服务器和接口服务器，接口服务器接收业务系统发送的通讯录数据上报请求后，发送给分发服务器，分发服务器通过Hash算法进行二次路由后，发送到对应节点的应用管理单元进行处理。