CN102279948A

CN102279948A - 联系人信息的合并与重复解决

Info

Publication number: CN102279948A
Application number: CN2011101648643A
Authority: CN
Inventors: A·古普塔; C·科怀恩; N·P·博贝德; S·文卡特斯艾; Y·田
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2010-06-10
Filing date: 2011-06-09
Publication date: 2011-12-14
Anticipated expiration: 2031-06-09
Also published as: US20110307455A1; US8417696B2; CN102279948B

Abstract

本发明揭示了联系人信息的合并与重复解决。通过使用联系人对象并将联系人对象汇聚为联系人模型来实现跨平台的联系人信息的合并与重复的解决。可获取来自内部和/或外部数据存储的联系人数据，并为来自各联系人存储的每个联系人创建联系人对象。通过汇聚来自跨多个联系人存储的联系人对象的联系人数据可为每个联系人实体创建一个联系人模型。汇聚可包括通过通信***类型的加权、联系人信息类型的排序及类似方法的重复解决。联系人模型可基于联系人对象的变化动态更新。

Description

联系人信息的合并与重复解决

技术领域

本发明涉及联系人信息技术，尤其涉及联系人信息的合并与重复解决方案。

背景技术

现代通信***使得用户在例如企业电子邮箱、个人电子邮箱、社交网络交流等各种***中拥有多种身份。这些***的每一个可基于对交换信息的自动处理和/或手工输入来生成联系人列表。不同通信***中联系人信息的结构和内容基于它们的基础结构而有所不同。因此，一个用户可能拥有同一联系人的多条联系人信息，这些多条联系人信息存储在与它们相关联的各通信***中。

通信应用程序正变得越来越多地为用户提供对多种通信***的访问。

例如，电子邮箱交换应用程序可被配置为从多个***为用户收发电子邮件，并自动管理用户的身份。

因为各通信***往往有各自的联系人存储，在使用多个通信客户机的同时管理多个联系人存储，对用户来说是一个挑战。保留多个联系人存储的一些问题包括：管理同步、跨多个平台同步、为多个联系人存储更新联系人信息内容以及管理重复的联系人信息。

发明内容

提供本发明内容是为了以简化的形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

各实施例致力于实现跨平台联系人信息的合并与重复的解决。获取来自内部和/或外部数据存储的联系人数据，为来自各联系人存储的每个联系人创建联系人对象。接下来，通过汇聚来自跨所述联系人存储的联系人对象的联系人数据可为每个联系人实体创建一个联系人模型。汇聚可包括通过通信***类型的加权、联系人信息类型的排列及类似方法的重复解决。联系人模型可基于所述联系人对象的变化动态更新。

通过阅读下面的详细描述并参考相关联的附图，这些及其他特点和优点将变得显而易见。可以理解，前述一般描述和以下详细描述均仅是说明性的，且不限制所要求保护的各方面。

附图说明

图1是示出一个示例通信***的图示，其中可实现用于管理联系人信息的各实施例；

图2是示出一个基本示例***的概念图，用于跨不同***实现联系人信息的合并与重复解决；

图3示出增强通信***中的主要组件和动作，根据各实施例该增强通信***便于联系人信息的合并与重复解决的实现；

图4示出根据各实施例如何通过使用***中的示例用户界面将不同的联系人信息合并入单一的联系人模型中；

图5是可实现根据各实施例的***的联网环境；

图6是可实现各实施例的示例计算操作环境的框图；以及

图7示出根据各实施例的增强通信***中管理联系人信息的过程的逻辑流程图。

具体实施方式

正如以上简要描述的，跨平台联系人信息的合并与重复解决可通过为来自与用户相关联的数据存储的每个联系人创建联系人对象，并且使用如加权通信***类型或者排序联系人信息类型的汇聚方法将同一联系人实体的多个联系人对象汇聚为一个联系人模型来实现。在以下详细描述中，参考了构成了详细描述的一部分并作为说明示出了各具体实施例或示例的附图。可组合些方面，可利用其他方面，并且可以在不背离本发明的精神或范围的前提下做出结构上的改变。以下详细描述从而不取限定性含义，且本发明的范围由所附权利要求书及其等效实施方式来定义。

虽然在结合在个人计算机上的操作***上运行的应用程序执行的程序模块的一般上下文中描述了各实施方式，但是本领域技术人员会认识到各方面也可以结合其他程序模块实现。

一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构和其他类型的结构。此外，如本领域技术人员理解的，各实施例可以用其他计算机***配置来实施，包括手持式设备、多处理器***、基于微处理器或可编程消费者电子产品、小型计算机、大型计算机以及类似计算设备。各实施例还能在任务由通过通信网络链接的远程处理设备来执行的分布式计算环境中实现。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备中。

各实施例可被实现为计算机实现的过程(方法)、计算***、或者如计算机程序产品或计算机可读介质等制品。计算机程序产品可以是计算机***可读并且编码包括用于使得计算机或计算***执行示例过程的指令的计算机程序的计算机存储介质。例如，计算机可读存储介质可经由易失性计算机存储器、非易失性存储器、硬盘驱动器、闪存驱动器、软盘或紧致盘和类似介质中的一个或多个来实现。

本说明书中，术语“服务器”一般指通常在联网环境中执行一个或多个软件程序的计算设备。然而，服务器还可被实现为视作网络上的服务器的、在一个或多个计算设备上执行的虚拟服务器(软件程序)。类似的，“客户机”是指能够访问通信***的计算设备，或者运行于计算设备上使用户能访问如社交网络服务、电子邮箱交换服务及类似服务的应用程序。关于这些技术和示例操作的更多细节在以下提供。

参考图1，示出了可实现各实施例的示例通信***的示图100。例如统一通信***的增强通信***为订阅者提供便于多模通信的能力。尽管这类***可集成多模通信中如联系人信息管理的各方面，但订阅者还可能参与到如社交网络***、其它电子邮箱***及类似***的其它***中。因此，增强通信***可为跨多种平台合并(与重复解决)与一订阅者关联的联系人信息提供合适的平台。统一通信***是具有能够提供给订阅者各种各样的能力和服务的现代通信***的示例。统一通信***是便于即时通讯、在场、音频-视频会议、web会议功能和类似功能的实时通信***。

在统一通信(“UC”)***中，如示图100中示出的***，用户可经由作为该UC***的客户端设备的各种终端设备(102、104)来进行通信。各客户端设备都能够执行用于语音通信、视频通信、即时通讯、应用程序共享、数据共享等的一个或多个通信应用程序。除其高级功能之外，终端设备还可通过外部连接，如通过PBX 124到公共交换电话网(PSTN)，来方便传统电话呼叫。终端设备可包括任何类型的智能电话、蜂窝电话、执行通信应用程序的任何计算设备、智能汽车控制台以及具有附加功能的高级电话设备。此外，UC***的订阅者可使用一个以上终端设备和/或通信应用程序以方便与其他订阅者进行各种模式的通信。终端设备可还包括通过有线或无线方式(例如，USB连接、蓝牙

连接等)与其耦合的不同外设，以方便通信的不同方面。

UC网络110包括执行不同任务的多个服务器。例如，UC服务器114提供注册、在场和路由功能。路由功能使该***能够基于默认和/或用户设置的策略来将对一用户的呼叫路由到分配给该用户的客户端设备中的任一个。例如，如果用户不能通过常规电话被找到，则该呼叫可被转发到用户的蜂窝电话，并且如果没有接听则可以利用多个语音邮件选项。因为终端设备可以处理附加通信模式，所以UC服务器114可以通过访问服务器112提供对这些附加通信模式(例如即时通讯、视频通信等)的访问。访问服务器112位于周边网络中并且以附加通信模式之一允许与其他用户通过UC网络110的连接。UC服务器114可包括执行上述功能的组合的服务器，或仅提供特定功能的专用服务器。例如，提供在场功能的家庭服务器、提供路由功能的路由服务器、权利管理服务器等。类似地，访问服务器112可提供多个功能，例如防火墙保护和连接，或仅是专用功能。

音频/视频(A/V)会议服务器118通过经由内部或外部网络方便音频和/或视频会议能力来提供这些能力。中介服务器116作为去往和来自例如PSTN或蜂窝网络等其他类型的网络的信令和媒体(例如，通过PBX124或来自蜂窝电话122的呼叫)的中介。中介服务器116还担当会话发起协议(SIP)用户代理。

在UC***中，用户可拥有一个或多个身份，该身份不必限于电话号码。取决于集成网络，该身份可采取任何形式，如电话号码、会话发起协议(SIP)统一资源标识符(URI)、或任何其他标识符。尽管在UC***中可以使用任何协议，但SIP是常用方法。

SIP是用于创建、修改和终止与一个或多个参与者的会话的应用层控制(信令)协议。该协议还可用于创建包括因特网电话呼叫、多媒体分发和多媒体会议的双方、多方或多播会话。SIP被设计成与底层传输层无关。

SIP客户机可使用传输控制协议(“TCP”)来连接到SIP服务器和其他SIP端点。SIP主要用于建立和拆卸语音或视频呼叫。然而，它可以在需要会话发起的任何应用中使用。这些应用包括事件订阅和通知、终端移动性等。语音和/或视频通信通常通过单独的会话协议，通常是实时传输协议(“RTP”)来完成。

联系人信息的合并与重复解决可由UC***中的一个或多个服务器，通过访问为各种通信服务存储联系人数据的网络内和网络外的数据源并获取联系人信息来实现。然后服务器可为每个获取的联系人创建多个联系人对象。接下来确定不同的联系人实体及其对应的联系人对象(每个联系人实体可对应有多个联系人对象)。为每个联系人实体汇聚所述联系人对象，解决重复信息冲突，并为每个联系人实体创建一个联系人模型。在检测到所述联系人对象中任意一个的变化时，所述模型可被动态更新，这样订阅者就能跨平台访问最新的联系人信息。

虽然图1中的示例***已被描述为具有例如中介服务器、A/V服务器和类似设备等专用组件，但各实施例不限于具有示例组件和配置的***。方便多模联系人信息管理的增强通信***可由采用更少或附加组件的其他***和配置来实现。此外，此类***不必是集成多种通信模式的增强通信***。通过使用此处描述的原理协调不同的通信模式间规则的实现，各实施例也可在显著方便不同通信模式的***中实现。

图2包括示出一个基本示例***的概念图200，用于跨不同***实现联系人信息的合并与重复解决。尽管根据各实施例的***可能包括例如在图1中示例性讨论过的多个服务器和服务，但图2仅显示那些与各实施例相关的。

订阅者236的联系人信息可首先基于来自各种源的信息(例如来自目录服务器246的组织联系人信息)进行计算。该信息通常是静态的，并可包括联系人的组织分层结构、功能分层结构、地址、电话号码、头衔及类似信息。由类似通信服务器242(例如与电子邮箱应用程序相关联的个人地址簿)、在场服务器244和社交网络服务器240的服务器保存的如各种地址簿的其他联系人存储，也可以被用作信息源。

所选信息可进行如上所述的处理，利用动态可更新的联系人模型通过任意一台客户机设备238为订阅者236提供汇聚后的联系人列表。此外，使第三方***能够访问联系人模型并提供“已合并的”联系人的动态汇聚视图。根据某些实施例，外部或第三方***可以使用预定义键值(例如SIP URI、电子邮箱地址、电话号码等)访问联系人模型并建立用户界面组件(例如联系人卡、联系人列表、搜索等)以使用户轻松查找、访问和编辑联系人信息。此类应用程序/设备可以决定显示汇聚后的联系人数据和/或来自特定存储的联系人数据。

图3示出增强通信***中的主要组件和动作的示图300，根据各实施例该增强通信***便于联系人信息的合并与重复解决的实现。各实施例的***可从各种源收集联系人信息。例如，第一联系人存储302可以是社交网络站点的联系人储存库。第二联系人存储304可以是例如电子邮箱应用程序地址簿的个人联系人储存库。第M联系人存储306可以是例如目录服务器的组织储存库。其他资源可以包括但不限于，在场服务器、集体数据库等。

从每个资源获取联系人数据作为联系人实体(例如个人、团队、非人类实体等)的元数据组。为各联系人存储中的每个联系人实体创建一个联系人对象，例如第一联系人对象310、第二联系人对象312、一直到第n联系人对象312。取决于他们的特定联系人存储的属性种类，联系人对象可以包括各种属性。例如，联系人对象可包括同时代表动态(例如在场、位置等)和静态(照片、显示姓名、电子邮箱地址、IM地址、电话号码等)信息的属性。每当添加、删除联系人和/或修改元数据，***就会从数据源收到通知。所述***基于所述通知更新其联系人对象。或者，所述***可以定期或者按需查询联系人存储以确定联系人信息的任何变化。

某些联系人对象可能相互重复。重复解决模块330可汇聚各联系人对象的信息，并为每个不同的联系人实体创建一个联系人模型。可通过两步处理来创建第一联系人模型340、第二联系人模型342、一直到第p联系人模型344。第一步，跨多个存储的重复联系人可以通过基于一个或多个属性或键值匹配联系人对象来解决。用于重复联系人解决的属性可包括显示姓名、电子邮箱地址、文本消息地址、电话号码及类似属性。根据某些实施例，所述属性可被分配权重，每个联系人对象的全部的加权因子可用于确定多个联系人对象是否代表同一个联系人实体。例如，***可为测试消息地址和电子邮箱地址分配权重。如果两个联系人条目具有相同的文本消息和电子邮箱地址，那么这两个条目代表同一实体的概率要高于仅电子邮箱地址匹配而文本消息地址不匹配的联系人条目。

通过应用后退逻辑和生成单一联系人模型来汇聚重复联系人的数据。对于每个联系人属性，后退逻辑可基于例如可靠性、最后修改时间及类似标准的因素对多个数据源进行排序。可以基于终端用户的需要、目标以及企业规则定制对多个数据源的排序。***随后选择排序最高的数据源的属性值。如果排序最高的数据源的属性值为空或不可用，那么***从排序下一数据源获取属性值；以此类推。类似的，两个数据源之间的冲突信息可通过排序***和/或创建附加属性来解决。例如，如果同一实体的两个联系人对象包括两个不同的电子邮箱地址，那么***可保留排序较高数据源中的地址，或者保留这两个地址并为排序较低的地址分配一个新创建的属性(例如“电子邮箱2”)。

重复解决模块330可利用对象属性排序数据存储320来存储和获取已排序的数据。此外，在引用的联系人对象中的任意一个有变化时或者在新的联系人对象被链接至联系人模型时，联系人模型会动态更新。每个联系人模型可被显示在包括显示器350、个人计算机352和蜂窝电话354的各种设备上。各联系人模型为各联系人实体提供联系人信息和来自多个联系人数据存储的汇聚信息。联系人模型可本地地存储在客户机上或者远程地存储在服务器上。缺少任何自动方案时，重复联系人对象的各个汇聚基于用户提示。

上述讨论过的情形、示例***、联系人信息或应用程序是用于说明目的。各实施例不限于这些示例。其他形式的联系人简档、联系人对象和模型可被用于以与此处描述的原理类似的方法实现联系人信息的管理。

图4示出根据各实施例如何通过使用***中的示例用户界面将不同的联系人信息合并入单一的联系人模型中。如图4所示，来自两个不同联系人数据存储的同一联系人实体的联系人信息可以以不同的方式显示(和存储)。联系人实体402可来自例如统一通信联系人卡的企业通信***数据存储，并包括关于联系人的静态和动态信息。联系人实体404包括具有更少属性的静态信息。此外，每个数据源中同一联系人的电话和传真号码是不同的。

根据各实施例的***使用包含在联系人数据中的属性为每个实体创建多个联系人对象。接着，***基于实体的姓名键值来匹配两个对象。***基于可靠性(企业数据源)、更新状态或类似标准为联系人实体402分配较高的排序位置。然后创建合并来自两个源的信息的联系人模型406，。匹配的属性保持不变。不重复的信息，例如联系人的办公室或位置，作为不同的属性包含在模型中。假如出现如电子邮箱地址或电话号码的冲突信息，可以采用排序较高的属性(例如电话号码)，或者同时保留这两个属性并为排序较低的属性(例如来自联系人实体404的电子邮箱地址)分配一个新的属性名。

图5是可实现各实施例的示例联网环境。提供包括联系人信息管理功能的通信服务的增强通信***可通过运行于一个或多个服务器518上的软件来实现，如托管服务。该***可以便于通过网络510的在例如智能电话513、膝上型计算机512、和台式计算机511(“客户机设备”)的各计算设备上的各客户端应用程序之间的通信。

正如以上讨论的，如UC服务的现代通信技术使得订阅者能够结合通信服务使用各种各样的计算设备和应用程序功能。这意味着订阅者可以使用一个或多个设备(例如普通电话、智能电话、计算机、智能汽车控制台等)以促进通信和具有多个联系人列表的多种通信服务。此类***中的联系人信息可被自动汇聚为单一的、最新的联系人列表，减少了用户为其使用的每项服务手动更新联系人信息的需要。

客户机设备511-513用于方便通信***订阅者之间多种模式的通信。一个或多个服务器518用于如上所述地管理联系人信息。联系人管理信息可存储在一个或多个数据存储(例如数据存储516)中，可由服务器518中的任意一个或由数据库服务器514进行管理。

网络510可包括服务器、客户机、因特网服务供应商以及通信介质的任何拓扑结构。根据各实施例的***可具有静态或动态拓扑结构。网络510可以包括如企业网络的安全网络、如无线开放网络的非安全网络、或者因特网。网络510还可通过诸如PSTN或蜂窝网络的其他网络来协调通信。网络510提供此处描述的节点之间的通信。作为示例而非限制，网络510可包括例如声学、RF、红外线和其他无线介质的无线介质。

可采用计算设备、应用程序、数据源和数据分发***的许多其它配置来实现具有联系人信息管理功能的通信***。此外，图5中所讨论的联网环境仅用于说明目的。各实施方式不限于示例应用程序、模块或过程。

图6及相关联的讨论旨在提供对其中可实现各实施例的合适计算环境的简要概括描述。参考图6，示出了根据各实施例如计算设备600的用于应用程序的示例计算操作环境的框图。在基本配置中，计算设备600可以是作为增强通信***一部分的联系人信息管理服务器并包括至少一个处理单元602和***存储器604。计算设备600还可包括协作执行程序的多个处理单元。取决于计算设备的确切配置和类型，***存储器604可以是易失性的(如RAM)、非易失性的(如ROM、闪存等)或是两者的某种组合。***存储器604通常包括适于控制平台操作的操作***605，例如来自华盛顿州雷德蒙市的微软公司的

操作***。***存储器604还可包括一个或多个软件应用程序，例如程序模块606、联系人管理应用程序622和重复解决模块624。

联系人管理应用程序622可以是便于通过客户端应用程序、服务器和其他设备之间的各种模态的通信的服务的一部分。重复解决模块624可以实现跨不同***的来自各种联系人数据存储的联系人信息的汇聚与重复解决。该基本配置在图6中由虚线608内的那些组件示出。

计算设备600可具有附加特征或功能。例如，计算设备600还可包括附加数据存储设备(可移动和/或不可移动)，例如磁盘、光盘或磁带。在图6中通过可移动存储609和不可移动存储610示出了这样的附加存储。计算机可读介质可包括以用于存储例如计算机可读指令、数据结构、程序模块或其它数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。***存储器604、可移动存储609和不可移动存储610都是计算机可读介质的示例。计算机存储介质包括但不限于，RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁存储设备、或能用于存储所需信息且能够由计算设备600访问的任何其他介质。任何这样的计算机可读介质都可以是计算设备600的一部分。计算设备600也可具有输入设备612，例如键盘、鼠标、笔、语音输入设备、触摸输入设备和类似输入设备。还可包括输出设备614，例如显示器、扬声器、打印机和其他类型的输出设备。这些设备在本领域中公知并且无需在此处详细讨论。

计算设备600还可包含允许该设备与其他设备618通信的通信连接616，例如通过分布式计算环境中的无线网络、卫星链接、蜂窝链接和类似机制。其他设备618可包括执行通信应用程序的计算机设备、其他目录或策略服务器和类似设备。通信连接616是通信介质的一个示例。通信介质包括计算机可读指令、数据结构、程序模块和已调制数据信号中的其他数据，例如载波或其它传输机制，并且包含任何信息传递介质。术语“已调制数据信号”指的是一个或多个特征以在信号中编码信息的方式被设定或更改的信号。作为示例而非限制，通信介质包括有线介质如有线网络或直接线连接，以及如声学、RF、红外及其他无线介质之类的无线介质。

各示例实施例还包括各种方法。这些方法可以用任何数量的方式，包括本文中所描述的结构来实现。一种此类方式是通过本文中描述的类型的设备的机器操作。

另一可任选方式是结合一个或多个人类操作者执行该方法的各个操作中的某一些来执行该方法的一个或多个操作。这些人类操作者无需彼此同在一处，而是其每一个可以仅与执行程序的一部分的机器同在一处。

图7根据各实施例示出了一管理联系人信息的过程700的逻辑流程图。过程700可作为便于多个联系人数据存储的通信***的部分来实现。

过程700始于操作710，确定与多个联系人相关联的多个数据存储。正如前面讨论过的，数据存储可以是社交网络储存库、本地储存库(例如电子邮箱地址簿)、组织目录和类似的。

在操作720，从所述数据存储中获取联系人简档。所述简档(或实体)可包括与各个联系人相关联的信息和属性。所述联系人简档中的属性可用于在操作730中填充联系人对象。

在操作740，可通过确定不同的联系人实体、一个或多个与所述不同的联系人实体相关联的联系人对象，以及解决重复信息冲突来汇聚重复的联系人对象。汇聚数据时可采用加权多个属性和排序多个数据源。在操作750，使用汇聚后的联系人对象为每个不同的联系人实体创建联系人模型。联系人模型代表跨多个联系人数据存储的不同的联系人简档。

包括在过程700内的各操作是出于说明目的。根据各实施例的联系人管理服务可以使用此处所述的各原理通过具有更少或附加步骤的相似过程、以及不同的操作次序来实现。

以上说明书、示例和数据提供了对各实施方式组成的制造和使用的全面描述。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求和各实施方式的示例形式而公开的。

Claims

1.一种至少部分地在计算设备中执行的用于管理联系人信息的方法，所述方法包括：

确定与多个联系人相关联的多个数据存储(710)；

从所述多个数据存储获取多个联系人简档(720)；以及

通过下述步骤为每个不同的联系人创建一个联系人模型(730)：

创建对应于每个联系人简档的联系人对象；

基于联系人属性确定重复的联系人对象；

基于所述数据存储的排序来汇聚所述重复的联系人对象(740)；以及

为每个汇聚后的联系人对象集合创建联系人模型(750)。

2.如权利要求1所述的方法，其中所述数据存储包括下面集合中的至少一个：社交网络目录(240)、自定义目录、个人目录(242)和组织目录(246)。

3.如权利要求1所述的方法，其中所述联系人简档(406)包括以下至少一个：动态联系人信息和静态联系人信息。

4.如权利要求3所述的方法，其中所述静态联系人信息(404)包括下面集合中的至少一个：姓名、地址、职位、机构、办公室、部门、会话发起协议SIP地址、照片、电子邮箱地址、即时消息IM地址和至少一个电话号码。

5.如权利要求1所述的方法，其中创建所述联系人对象还包括：

从每个联系人简档(406)获取至少一个联系人属性；以及

在所述联系人对象(310)中存储至少一个联系人属性。

6.如权利要求1所述的方法，其中响应于下面集合中的至少一个来更新所述联系人对象(310)：联系人简档的增加、联系人简档的删除、所述数据存储其中之一的联系人简档元数据的修改。

7.如权利要求1所述的方法，其中创建所述联系人模型还包括：

基于至少一个匹配的联系人属性确定重复的联系人对象(310、312、314)；以及

基于联系人属性(320)的已加权排序来选择匹配的联系人对象属性。

8.如权利要求1所述的方法，还包括：

将所述联系人模型存储在下述之一：客户机(350、352、354)和服务器。

9.一种用于管理联系人信息的通信***，所述***包括：

服务器(518)，被配置成：

跨与用户相关联的不同的通信服务确定与多个联系人实体相关联的多个数据存储(710)；

从所述多个数据存储获取所述多个联系人实体(720)；

通过下述步骤创建对应于不同的联系人实体的多个联系人模型(730)：

为每个联系人实体创建存储有属性的联系人对象；

基于一个或多个匹配的属性确定重复的联系人对象；

基于数据存储的已加权排序来汇聚重复的联系人对象(740)；以及

存储所述联系人模型以被用户访问。

10.如权利要求9所述的***，其中所述数据存储(302、304、306)基于下面集合中的至少一个排序：各通信服务的可靠性、各数据存储的更新状态和用户反馈。

11.如权利要求9所述的***，还包括用于提供与所述联系人实体至少一部分相关联的在场信息的在场服务器(244)，其中所述服务器还被配置为响应于下述之一来更新所述联系人模型：来自通信服务的与所述联系人实体之一相关联的变化通知，来自通信服务的与所述联系人实体之一相关联的查询响应，以及来自所述在场服务器的与所述联系人实体之一相关联的更新后的在场信息。

12.如权利要求9所述的***，其中汇聚重复的联系人对象(740)包括：

保留来自较高排序的数据存储的联系人对象的属性；

向来自较低排序的数据存储的联系人对象的不重复属性分配新属性；以及

移除来自较低排序的数据存储中联系人对象的相冲突的属性。

13.一种其上存储有用于管理联系人信息的指令的计算机可读存储介质，所述指令包括：

从所述多个数据存储获取所述多个联系人实体(720)；

为每个联系人实体创建存储有属性的联系人对象；

基于一个或多个已加权的匹配属性确定重复的联系人对象；

基于下面集合中的至少一个汇聚重复的联系人对象：各通信服务的可靠性、各数据存储的更新状态和用户反馈(740)；以及

存储所述联系人模型以被用户在下述之一处访问：服务器和与所述用户相关联的客户机。

14.如权利要求13所述的计算机可读存储介质，其中所述指令还包括允许如下服务：

使用包括下列至少之一的键值访问所述联系人模型(340、342、344)：电子邮箱地址、即时消息IM地址、电话号码和***生成的通用用户识别符GUID。

提供至少一个用户界面组件以允许用户查找、访问和编辑所述联系人模型；以及

显示以下之一：所述数据存储之一的所述联系人模型和所述联系人实体。

15.如权利要求13所述的计算机可读存储介质，其中所述指令还包括：

响应于下述之一更新所述联系人模型(340、342、344)：来自通信服务的联系人实体的变化通知，对来自所述数据存储(302、304、306)之一的联系人实体状态的查询的响应，以及来自在场服务器(244)的状态更新。