来自用户联系人的联系人列表的自动化呼叫者标识符

摘要

本文描述了来自用户联系人的联系人列表的自动化呼叫者标识符。当用户的通信设备接收到来自未被标识的发送者的呼叫或消息时，呼叫者标识符应用程序启动基于文本的消息收发应用程序，使之向该用户的联系人发送包括与该用户接收到的呼叫或消息相关联的元数据的不可见基于文本的消息。当该不可见的消息被该用户的联系人之一的移动电话接收到时，搜索该联系人的联系人列表。如果所提供的元数据位于联系人列表中，则将联系人详情或联系卡通过第二个不可见的消息发回给该用户的移动电话。当接收到该第二不可见的消息时，呼叫者标识符应用程序使得一些或全部联系人详情被显示在该用户的移动电话上或另外以任何适合的方式呈现给该用户。

说明书

本发明专利申请是申请人于2011年2月16日提交的、申请号为 201110043186.5的、发明名称为“来自用户联系人的联系人列表的自动化呼叫 者标识符”的发明专利申请的分案申请。

技术领域

本发明涉及通信网络技术，尤其涉及来自用户联系人的联系人列表的自动 化呼叫者标识符。

背景技术

现代通信网络已向用户提供了大量的特征和功能，其使得与朋友、家庭、 同事，以及其他人保持联系容易、方便，且便宜。各种各样的设备，诸如移动 电话、智能电话、个人计算机（PC），以及其他启用网络的设备是可用的，这 使得用户在网上冲浪以访问信息和娱乐的资源，发送电子邮件和即时消息，以 及使用语音呼叫与其他用户通信。此外，随着无线基础结构扩大了其范围，并 且随着设备变得功能丰富、更小、而且更便携，用户实际上可以在任何时间及 任何地点被联系到。

当大多数用户理解如此加强的连接性（其常常导致大量呼叫和消息的接收 竞争用户的注意力）的益处时，如果呼入者的姓名可以在接收到呼叫或消息时 被呈现给用户将是有帮助的。这样的特征可以通过检查与传入呼叫或消息关联 的元数据，诸如发送者的电话号码，来提供。可以将该元数据与该用户的联系 人列表中的数据对比，且如果找到匹配，则在移动电话的显示器上向该用户呈 现发送者的姓名。作为移动电话提供的加强的连接性的结果，用户越来越频繁 地接收到来自其姓名没有被包含在该用户的联系人列表中的未被标识的发送 者的呼叫或消息。即使没有被包含在该用户的联系人列表中，如果这些未被标 识的发送者中的越多发送者可以在接收到呼叫或消息时被自动标识，则对于用 户将是有帮助的。

提供本背景技术来介绍以下发明内容和具体实施方式的简要上下文。本背 景技术不旨在帮助确定所要求保护的主题的范围，也不旨在被看作将所要求保 护的主题限于解决以上所提出的问题或缺点中的任一个或全部的实现。

发明内容

如前所述，一些用户，特别是企业用户，可在他们的移动电话上接收到来 自各种发送者的许多呼叫或消息，这些发送者中的一些可以从该用户联系人列 表中被标识，而这些发送者中的其他发送者不能被标识。虽然用户可能接收到 来自没有被包含在该用户联系人列表中的未被标识的发送者的呼叫或消息，但 是这样的发送者有时可能被包含在该用户的一个或多个联系人的联系人列表 中。在一个实施例中，为了利用该用户的联系人的联系人列表中可用的信息， 该用户的电子通信设备，如移动电话等，包含用于标识未被标识的发送者的呼 叫者标识符应用程序。呼叫者标识符应用程序被配置为搜索驻留在该用户的通 信设备上的联系人列表。如果发送者的姓名或其他标识符未被找到，则呼叫者 标识符应用程序也被配置为，确定是否可从驻留在被包含在该用户的联系人列 表中的那些联系人的通信设备上的联系人列表得到该未被标识的发送者的身 份，并读取该发送者的身份以便其可被呈现给该用户。

在一特定实施例中，当在该用户的通信设备上接收到来自未被标识的发送 者的呼叫或消息时，该呼叫者标识符应用程序启动基于文本的消息收发应用程 序，并使之向该用户的联系人发送“不可见”基于文本的消息。该消息包括与 该用户接收到的呼叫或消息相关联的元数据（例如电话号码）。该不可见SMS 消息是短消息，其头部以特定方式编程，使得接收方移动电话知晓对该消息的 接收，且该接收方移动电话不显示可被用户察觉的行为。当该不可见消息被该 用户的联系人之一的移动电话上的对应的呼叫者标识符应用程序接收到时，该 应用程序搜索该联系人在他或她的联系人应用程序中维护的联系人列表。如果 提供给该联系人移动电话的元数据位于联系人列表中，则联系人详情（例如姓 名）或联系卡（如果可用）在第二不可见SMS消息中被发回给该用户的移动 电话。当接收到该第二不可见SMS消息时，呼叫者标识符应用程序使得一些 或全部联系人详情被显示在该用户的移动电话上或以任何适合的方式呈现给 该用户。以此方式，该用户的联系人列表被有效地扩展，以包括他或她的联系 人的联系人列表，其可被自动搜索而无需所参与的各方的任何一方的介入。

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

附图说明

图1示出了说明性通信环境，在其中，设备的用户和呼叫者可通过使用诸 如移动电话、PC，和陆线电话等启用网络的设备来进行通信；

图2示出了包括呼叫者标识符应用程序的说明性体系结构，其可以被实现 在诸如移动电话的启用网络的通信设备上；

图3示出了在启用网络的设备上运行的各种功能组件之间使用的说明性接 口；

图4示出了呼叫者标识符应用程序中的一组说明性功能组件以及呼叫者标 识符应用程序支持的各种说明性特征、功能，和接口；

图5是可以被驻留在第一启用网络的电子设备上的呼叫者标识符应用程序 使用的说明性工作流的流程图；

图6-8示出了呼叫者标识符应用程序支持的用户界面的各种说明性屏幕截 图。

具体实施方式

在其中相同的附图标记指示相同的要素的附图中，图1示出了说明性通信 环境100，其中用户105_1…N以及呼叫者110_1,2…N可以使用各自的启用网络的设 备115_1,2…N进行通信，启用网络的设备115_1,2…N的每一个可操作地耦合到通信 网络120。设备115可以包含各种设备和平台的任何一种，其支持语音通信， 诸如移动电话、智能电话、PC、陆线电话，或其他适于用于通过网络的语音电 话的移动或固定设备。在这个特定示例性实施例中，术语“用户”是指从此处 将被称为“发送者”的人那里接收电话呼叫、SMS消息等的当前呼叫者标识符 应用程序的用户。

在一个实施例中，当前呼叫者标识符应用程序被安排成在移动设备上执 行，这些移动设备诸如移动电话、可用作电话的个人数字助理、智能电话，或 配置为基于Microsoft的设备的能够发出或接收语音呼叫的其他 便携设备（以下统称为“移动电话”）。然而，当前安排的原则也可以被适用 于与其他设备一起使用，该其他设备使用，例如，诸如Android^tm操作系统等其 他操作系统。

用于方便用户105和呼叫者110之间的通信的通信网络120可以包括如图 1所示的一个或多个网络类型的诸部分，包括移动电话网络125、移动数据网 络130、公共交换电话网135，以及互联网140。因此，例如，给定呼叫者110 可以使用传统电话呼叫给定用户105，其中呼叫通过公共交换电话网135和移 动电话网络125两者的部分来承载。可替换地，另一呼叫者110可以使用配备 有VOIP（网际协议话音）能力的PC呼叫用户105，其中呼叫通过互联网140 和移动电话网络125来承载。事实上，可以根据需要使用各种网络类型的组合 或单个网络来传输给定电话呼叫。

通信环境100中也支持服务提供者145。可以在使用场景中使用服务提供 者145，其中当前呼叫者标识符应用程序功能的部分被分布到一个或多个外部、 位于远程位置的服务器。

这样的使用场景在以下伴随附图13和14的文本中更详细地描述。

图2示出了用于方便当前安排的主功能组件的说明性体系结构200，包括 可以实现在诸如上述移动电话115₁等启用网络的通信设备上的呼叫者标识符 应用程序205。尽管图2中示出的体系结构200是特别适用移动电话115₁的， 但可期望它示出的基本原理对其他平台诸如，例如，虚线215指示的PC210， 具有一般适用性。在该说明性实施例中，呼叫者标识符应用程序205与联系人 应用程序220，SMS应用程序250，以及如附图标记225所共同指示的其他应 用程序一起在移动电话115₁上执行。维护诸如朋友、同事、家庭等的地址、电 话号码等的联系信息的联系人应用程序220，可以被包含在提供除维护联系人 外的其他功能的应用程序中。例如，经常在日程安排应用程序中维护联系人列 表，日程安排应用程序通常单独地或组合地支持日程安排、日历，和任务管理 功能。这样的联系人或日程安排应用程序可以被嵌入在，例如，可商用的软件 中，诸如微软公司的的消息收发和协作客户机。

SMS应用程序250支持在许多通信设备上可用的短消息服务，它准许在移 动电话、其他手持式设备、计算机、以及甚至标准陆线电话之间发送短消息（也 被称为文本消息）。无线网络一般使用短消息服务中心（SMSC）来实现SMS， 该短消息服务中心担当用于中继短消息的存储-转发系统。消息存储在网络中直 到目的地通信设备变得可用，因此无论语音呼叫是否正在进行中，最终用户都 可在任何时间接收或发送SMS消息。代替SMS应用程序，可以采用其他基于 文本的消息接发应用程序。这样的应用程序能以其他格式发送基于文本的消 息，包括，例如，由3GPP（第三代伙伴项目）开发的用于在移动电话和其他 形式的无线信息设备之间发送多媒体通信的多媒体消息接发服务所支持的 MMS消息。可以采用的其他类型的基于文本的消息可以基于任何中介技术（诸 如EMS(增强的消息服务)）及其变体，诸如收费SMS，以及这些服务的任何将 来的增强和发展。

在体系结构200中支持应用程序205、220和225的是操作系统230和硬 件层235。在该示例性实施例中，操作系统230尤其适于在资源有限的设备上 操作，并且可包括，例如，Microsoft硬件层235向操作系统 230和其上的应用程序205、220和225提供设备115₁上所实现的物理硬件的 抽象。例如，这样的物理硬件通常包括处理器（例如中央处理器或“CPU”）、 诸如只读存储器（“ROM”）和随机存取存储器（“RAM”）等系统存储器、 总线结构、外围系统、驱动器、显示设备、用户控件和界面等。该硬件也可以 包括用于存储计算机可执行指令（即代码）的存储介质，包括可移动介质/不可 移动介质两者或其一，诸如磁性和光学介质、固态存储器，和其他传统介质。 体系结构200还提供UI240来支持用户交互性并方便了有效的用户体验，并且 将通常被具体化为图形用户界面。

图3示出了在移动电话115₁上运行的各种功能组件上实现的几个说明性接 口。呼叫者标识符应用程序205通常通过API415向操作系统230注册听者410， 以便监视移动电话115₁上的呼叫活动。呼叫者标识符应用程序205也通常通过 分别由其他应用程序所展示的API来与在移动电话115₁上执行的其他应用程序 进行交互。例如，如图3所示，通过联系人日程安排应用程序220展示的代表 性API420使得呼叫者标识符应用程序205能够调用各种函数、传递参数，以 及与日程安排应用程序220交换数据。类似地，通过SMS应用程序250展示 的代表性API425使得呼叫者标识符应用程序205能够调用各种函数、传递参 数，以及与SMS应用程序250交换数据。

如前所述，一些用户，特别是企业用户，可能在他们的移动电话上接收到 来自各种发送者的许多呼叫或消息，这些发送者中的一些可以从用户联系人列 表中被标识，而这些发送者中的其他发送者不能被标识。当这样的未被标识的 发送者可能没有包括在用户的联系人列表中时，他们有时可能被包括在该用户 的联系人的一个或多个的联系人列表中。即，发送者可以是这样一个人：他与 该用户的联系人之一比与该用户他或她本人具有更紧密的关联。这在诸如 Facebook，MySpace，LinkedIn等提供的社交网络服务的使用增长的情况下尤 为如此，这些社交网络服务方便了个人的已扩展社区的发展。

为了充分利用该用户的联系人的联系人列表上可用的信息，当接收到来自 未被标识的发送者的呼叫或消息时，呼叫者标识符应用程序205启动SMS应 用程序250并使之向用户的联系人发送“不可见”SMS消息。该SMS消息包 括与该用户接收到的呼叫或消息相关联的元数据（例如电话号码）。不可见SMS 消息是短消息，其头部以特定方式编程，以使得接收方移动电话知晓对该消息 的接收，且该接收方移动电话不显示可被用户察觉的行为。以不可见格式发送 SMS短消息的技术的一个示例在美国申请公开No.20060209740中示出。当该 不可见消息被该用户的联系人之一的移动电话上的对应的呼叫者标识符应用 程序接收到时，该应用程序搜索该联系人在他或她的联系人应用程序中维护的 联系人列表。如果提供给该联系人的移动电话的元数据位于联系人列表中，则 联系人详情（例如姓名）或联系卡（如果可用）在第二个不可见SMS消息中 被发回该用户的移动电话。当接收到该第二不可见SMS消息时，呼叫者标识 符应用程序205使得一些或全部联系人详情被显示在该用户的移动电话上或另 外以任何适合的方式呈现给该用户。以此方式，该用户的联系人列表被有效地 扩展，以包括他或她的联系人的联系人列表，其可被自动搜索而无需所涉及的 各方的任何一方的介入。

图4示出了包括呼叫者标识符应用程序205的一组说明性功能组件。该组 件包括用户体验层505、商业逻辑层510，以及数据层515。特别指出，图4所 示的功能组件仅仅是说明性的，且也可以根据给定环境的需求以各种组合使用 其他组件，并提供此处描述的特征和功能。呼叫者标识符应用程序205中的功 能组件通常被配置为支持各种特征、功能，和接口，包括支持用户体验，与其 他应用程序交互，应用逻辑和规则来实施所期望的应用程序行为，以及处理数 据，如附图标记520、525、530，和535分别指示的。

在图4的特定示例性实施例中的功能模块可以至少部分地通过计算机可执 行代码来实现，所述代码写在设置在移动电话115₁上的一个或多个存储介质 上，并且通过电话的硬件中包含的一个或多个处理器来执行。在这一点上，因 此，所示的安排可以被看作“胖客户机”，因为功能组件实现的代码基本上整 体在移动电话115₁上执行，以便提供按设计的用户体验和应用程序行为。在可 替换的实现中，功能组件以分布式计算安排的形式来配置，且移动电话115₁上的代码可以从瘦客户机执行。在这种情况下，功能组件以及相关联的代码执 行跨多个计算平台分布，这些计算平台包括移动电话115₁以及由如图1所示的 服务提供者145操作的一个或多个服务器。

如所示，呼叫者标识符应用程序205通过当接收到来自未被标识的发送者 的呼叫或消息时提供用户偏好520₁、管理许可520₂，以及其他用户体验520_N， 来支持用户体验520。例如，用户偏好可以包括这样的项，如选择应搜索其联 系人列表的特定联系人、应搜索他们的顺序，以及呈现这样的搜索的结果的方 式。许可可包括允许接收不可见SMS消息以便搜索该用户的联系人列表、选 择联系人列表中的其身份不应在响应来自其他用户的请求时被提供的特定个 人，以及每次作出查询时是否应该关于对将联系人信息释放给另一用户的许可 询问用户。例如，一些查询可以基于联系人组被自动授权。作为一个示例，这 样的主动授权可以允许该用户的全部同事搜索该用户的工作组中的联系人。

呼叫者标识符应用程序205也可以和在移动电话115₁上执行的其他应用程 序交互。在这特定的示例性实施例中，呼叫者标识符应用程序205通常与联系 人应用程序220和SMS应用程序250交互。然而，也可以以在此讨论的类似 的方式使用与其他应用程序的交互。在一些使用情况中，呼叫者标识符应用程 序205将实现查询，诸如查询联系人列表525₁以标识与呼叫事件关联的用户联 系人，并启动SMS或其他消息应用程序以生成要被发送到用户联系人525₂的不 可见SMS消息。呼叫标识符应用程序205也可以和其他应用程序等525_N进行交 互。

呼叫者标识符应用程序205通常应用商业逻辑和规则来实现所期望的应用 程序的行为，如附图标记530所指示的。商业逻辑和规则的应用通常响应于接 收到由听者410监视的传入或消息实现各种例程、进程，和工作流，以支持上 面讨论的用户体验。

呼叫者标识符应用程序205也支持各种数据处理功能，包括接收呼叫或消 息535₁以及诸如呼叫元数据535₂等相关联信息。在某些情况下，呼叫者标识 符应用程序205通常在临时或永久基础上存储呼叫数据，以及用户偏好和使用 历史535₃。其他数据处理也可如附图标记535_N所指示的那样来执行，以符合给 定使用环境的需要。

图5是可以被驻留在第一启用网络的电子设备上的呼叫者标识符应用程序 205使用的说明性工作流800的流程图。工作流始于块805，在那里，听者410 监视由电子设备通过通信网络接收到的来自发送者的传入呼叫或消息。接着， 在块810，驻留在第一电子设备上的呼叫标识符应用程序获取与传入呼叫或消 息相关联的元数据，并且在块815搜索与第一电子设备相关联的联系人的列表 以定位与该元数据相关联的给定个人。在判决块820，如果给定个人被定位， 则在块823，通常在第一电子设备的显示器上将该个人的姓名或其他标识符呈 现给第一电子设备的用户。另一方面，如果没有找到与该元数据相关联的个人， 则工作流控制传递到块825，在那里，呼叫者标识符应用程序205导致将第一 不可见基于文本的消息发送到与第一电子设备的联系人列表中包括的至少一 些个人相关联的其他电子设备。这可以例如经由通过API建立与驻留在电子设 备上的基于文本的应用程序的链接来实现，以便发送消息请求其他电子设备搜 索它们各自的联系人列表来寻找与该元数据关联的个人。如果在判决步骤830， 没有定位到个人，则进程在块833终止，否则，控制传递到块835，在那里， 于其上找到该个人的电子设备向第一电子设备发送包含该个人的身份（例如姓 名）的第二不可见基于文本的消息。最后，在块840，通常在第一电子设备的 显示器上将该个人的姓名或其他标识符呈现给第一电子设备的用户。

图6-8示出了呼叫者标识符应用程序205可以支持的UI的一个示例的各种 说明性屏幕截图。当然，UI可以各种各样不同方式来配置，且不限于此处示出 的示例。图6示出了当在移动电话115₁接收到传入呼叫905时UI的示例性屏 幕截图900。在这个示例中，显示包括呼叫者的电话号码910和身份915（如 果知道）的呼叫数据。在这个示例中，呼叫处理由移动电话115₁上运行的应用 程序以通常的方式实现，它将传入呼叫数据和该用户的联系人列表进行比较， 以获取并显示呼叫者的身份。在可替换的实现中，这样的呼叫处理功能可以由 本呼叫者标识符应用程序205来处理。在任一情况下，在这个示例中，呼叫者 没有列在该用户的联系人列表中，因此该呼叫者的身份被定为未被标识或未 知。

通过与显示在UI上的“接听”或“拒绝”按钮920和925进行接口来向 用户提供用于或者接听传入呼叫或者拒绝接听的典型呼叫处理选项。取决于移 动电话115₁的硬件配置，可使用触敏图形图标、电话上的“软”键、或其他各 种传统控件来实现按钮920和925。

根据本安排的原则，图7示出了当在由传入呼叫905触发对呼叫者标识符 应用程序205的启动之际显示提示1005时的UI的示例性屏幕截图1000。提示 1005询问用户是否应该搜索他或她的联系人的联系人列表。在一些实施例中， 取决于已建立的用户偏好520₁，提示可以被消除且应用程序将自动开始搜索而 不提示用户。当显示提示1005时，按钮1010和1015也被显示以使得用户可 以按所期望的实现联系人搜索功能。

图8示出了示例性的屏幕截图1100，其示出了在呼叫者标识符应用程序 205已经执行了关于呼叫者电话号码的搜索并且已经在联系人之一的联系人列 表定位到该呼叫者之后的结果。当这样的呼叫者被定位时，呼叫者标识符应用 程序将显示该姓名1115以及从其联系人列表提供该姓名的联系人的姓名1120。

注意，为清晰且易于说明起见，在以上描述中，数据、应用程序以及诸如 操作系统等其它可执行应用程序组件被示为离散的块、框或其它元素，尽管可 以认识到并强调，这些应用程序和组件可在不同的时刻驻留在所使用的任何硬 件主机的不同存储、存储器或处理组件中，并由这些主机硬件中的一个或多个 处理器执行。

在上面描述的实现中，不可见文本消息被发送到该用户的联系人的移动电 话以标识呼入者。然而，在一些实现中，例如，不可见文本消息可以被发送到 可从诸如社交网络（例如Facebook）等其他数据源得到的该用户的联系人。这 样的源可以维护该用户的联系人以及那些联系人的联系人两者的电话号码，因 此提供可以被用于标识呼入者的另一信息源。除了社交网络，其他可用的数据 源包括邮件客户端，诸如Gmail、Microsoft 和Windows以此 方式，有效地创建了新社交网络，其包括该用户、该用户的联系人，以及该用 户的联系人的联系人。以此方式，该用户的移动设备中可用的联系人列表被从 自包含的闭合列表传送到个人的整个社交网络，该整个社交网络具有成长和扩 展到附加个人的能力。

上述技术通常可用于由各种制造商提供的各种各样不同的移动设备。然 而，通过一些移动设备，诸如搜索起源自该电话中，但是实 际上是使用基于云（例如web）的服务来执行的。具体地，的 用户被登记到应用程序（例如），其维护来自网络上所有源的用户 联系人。每当来自未被标识号码的呼叫被截获时，将在线执行搜索（在在线电 话的社交图之间）代替电话之间点对点的模式。即，搜索是在电话和云之间执行，其表示来自全部可能的社交网络的所有的用户联系人的聚集。此 外可以通过不仅搜索该用户自己的云也搜索他的联系人的相关联社 交网络来将搜索扩展到云。例如，来自Facebook的联系人将被由Facebook中 的搜索。

尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所 附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特 征和动作是作为实现权利要求的示例形式公开的。