CN102741813A - 自动回叫提醒 - Google Patents

Abstract

由一种安排提供呼叫提醒功能，所述安排可以与启用网络的通信设备一起操作，其中回复电话呼叫的提醒可以在呼叫事件发生以后以自动方式生成。当呼叫事件发生时，在该设备的用户界面（“UI”）上显示创建该呼叫与用户的日程安排应用之间的链接的选项。如果用户选择该选项，则将回叫任务添加到用户的由日程安排应用维护的任务列表，并且生成进行该回叫的提醒并且然后将在未来时间将其显示在该UI上。该提醒包括相关呼叫信息并且还包括使得用户能够通过UI拨打该回叫的按钮（即“单击回叫”）。

Description

自动回叫提醒

背景

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

尽管大多数用户都感激这样提高的连通性和访问能力的利益，但是电话可能在不方便的时间响铃。例如，用户可能在会面中，出席演出或体育赛事，驾驶汽车，或者参与用户不期望被打扰的其他一些活动。但是如果用户选择不接听呼叫，则常常可能难以记得要回复该呼叫。而且当用户记得要进行回叫时，不总是能方便地访问要呼叫的相关电话号码。例如，用户可能必须人工地浏览传入呼叫日志以找出要回叫的呼叫者和电话号码。

提供本背景来介绍以下概述和详细描述的简要上下文。本背景不旨在帮助确定所要求保护的主题的范围，也不旨在被看作将所要求保护的主题限于解决以上所提出的问题或缺点中的任一个或全部的实现。

概述

通过一种布置提供了呼叫提醒功能，该布置能够与诸如移动电话之类的启用网络的通信设备一起操作，其中可以以自动方式在诸如下列呼叫事件发生以后生成回复呼叫的提醒：传入呼叫、被拒绝的呼叫、呼叫等待、错过的呼叫、短时间的呼叫（即未达到所设置的最小时长的呼叫）等等。当这样的呼叫事件发生时，在设备的用户界面（“UI”）上显示创建该呼叫与用户的日程安排之间的链接的选项，所述日程安排例如可以由日程安排应用来维护。

如果用户选择该选项，则可以将回叫任务添加到用户的由日程安排应用支持的任务列表（即“待办（to do）”列表），并且设置进行该回叫的提醒并将未来时间将该提醒显示在UI上。例如，可以在预定义的时间（比如30分钟以后、下一天等等）、或者在用户的日程安排中的空闲时间段时提供提醒。该提醒包括相关呼叫信息（例如呼叫方的姓名、最后一个传入呼叫的电话号码、日期/时间）并且包括使得用户能够通过UI进行呼叫的按钮或类似控制元素（即“单击”呼叫）。

在各个说明性实施例中，由如下的应用来提供呼叫提醒功能：该应用可以作为通信设备上的胖客户端运行或者可替代地作为瘦客户端运行，所述瘦客户端在该设备与在设备的远程运行的服务器之间例如通过实现为网络上的服务“云”来分割应用代码的存储和执行。呼叫提醒应用将展示UI，所述UI使得用户能够设置偏好（例如设置哪些类型的呼叫事件将触发呼叫提醒应用、设置在应用启动以前的响铃次数、指定预定义的时间间隔等等）和其他缺省应用行为。该UI还可以使得用户能够在发生合格呼叫事件以后触发应用时完成各个呼叫处理选项。

呼叫提醒应用通常使用监视呼叫事件的监听器在后台运行。当合格呼叫事件发生时，该应用被触发并且将取出和存储诸如元数据之类的呼叫信息（例如呼叫者的电话号码、呼叫的日期/时间）和匹配的联系人信息（例如呼叫者的姓名/昵称、电话号码关联－工作、移动、家庭等等）。显示UI上的通知以向用户提供为该呼叫者添加回叫的选项。如果用户选择该选项，则呼叫提醒应用在日程安排应用所展示的API（应用编程接口）处调用各个函数，并且传递合适的参数以创建回叫任务以及设置提醒。

在一些实施例中，呼叫提醒应用可以查询日程安排应用以在用户的日程安排中自动找出可插入回叫提醒的空闲时间段（或者满足用户指定的其他规则的时间段）。可替代地，可以向用户提供选项来人工地浏览日历以找出用户选择的时间段。在其他实施例中，该提醒将被设置在预定义的时间，所述预定义的时间可以缺省地设置或者通过在通知时与UI的交互来设置。当达到回叫提醒的所设置时间时，该应用将通过设备上的UI显示提醒并且通常还显示所取出的呼叫信息。呼叫提醒应用还将显示按钮或其他控制元素来在被激活时实现单击回叫特征。

呼叫提醒应用向用户提供丰富的特征集，所述特征集提供了处理传入、被拒绝和错过的呼叫的便利和有益的替代方案。用户可以利用几次点击来保持为有组织的并且与语音通信保持为最新的，而不必人工地扫过呼叫记录以找出所需的信息。另外，呼叫提醒应用自动地与用户的在通信设备上运行的其他应用对接的能力有利地保证：用户体验为无缝的并且所生成的任务和提醒与用户的日程安排一致。

提供本概述以便以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图描述

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

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

图3示出了示例性的布置，其中移动电话可以与PC耦合以支持设备之间的数据同步，使得二者都具有最新的数据版本。

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

图5示出了呼叫提醒应用中的一组说明性功能组件以及呼叫提醒应用支持的各种说明性特征、功能和接口；

图6是可被呼叫提醒应用利用的用户偏好和缺省应用行为的说明性分类；

图7是可被呼叫提醒应用利用的呼叫处理选项的说明性分类；

图8是可以被呼叫提醒应用利用的说明性工作流的流程图；

图9－12示出了呼叫提醒应用支持的用户界面的各种说明性屏幕截图；

图13示出了说明性地被安排成诸如移动电话之类的启用网络设备上的瘦客户端的呼叫提醒应用；以及

图14示出了说明性的安排，其中呼叫提醒应用的某个功能由可操作地耦合到通信网络的服务提供者来支持。

具体实施方式

在附图中，相同的附图标记指示相同的要素，图1示出了说明性通信环境100，其中用户105_1…N以及呼叫者110_1，2...N可以使用相应的启用网络的设备115_1，2...N进行通信，启用网络的设备115_1，2...N每个都可操作地耦合到通信网络120。设备115可以包含各种设备和平台的任何一种，其支持语音通信，诸如移动电话、智能电话、PC、陆线电话，或其他适于用于通过网络的语音电话的移动或固定设备。在这个特定示例性实施例中，术语“用户”是指本呼叫提醒应用的如下用户：该用户从作出呼叫的称为“呼叫者”的人接收到电话呼叫。

在一个实施例中，本呼叫提醒应用被安排为在诸如下列移动设备上执行：移动电话、具有电话能力的个人数字助理、智能电话、或配置成基于Microsoft

CE的设备的能够作出或接收语音呼叫的其他便携式设备（以下统称为“移动电话”）。然而，本安排的原理还可以适于与使用其他操作系统的其他设备一起使用。例如，这样的操作系统可以包括Symbian、iPhone/Mac、Palm、Blackberry、Android、以及其他基于Linux或Unix的操作系统。还应当注意，在此所使用的术语“呼叫”意在指代包括下列各项的多种呼叫类型中的任何呼叫类型：语音呼叫、视频呼叫、多媒体呼叫、会议呼叫（例如多方间的语音/视频/多媒体呼叫）、消息收发、以及其他形式的通常实时或近实时地实施的通信。

用于促进用户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指示的PC 210之类的其他平台具有一般适用性。在该说明性实施例中，呼叫提醒应用205与由附图标记225统指的日程安排应用程序220和其他应用一起在移动电话115₁上执行。日程安排应用220可以例如嵌入在市售的软件中，比如微软公司的

的消息收发和协作客户端。然而，取决于给定使用场景的要求，还可使用单独地或组合地支持日程安排、日历和任务管理功能的其他类型的应用程序。这些项目例如可以包括Google Calendar、Apple Mac iCal、Mozilla Sunbird和Thunderbird/Lightning、Blackberry Calendar、Palm Month Planner等等。这些应用在一些情况下可以是基于web的。

在体系结构200中支持应用程序205、220和225的是操作系统230和硬件层235。在该示例性实施例中，操作系统230尤其适于在资源有限的设备上操作。硬件层235向操作系统230和其上的应用程序205、220和225提供移动电话115₁上所实现的硬件（比如计算机或机器可读存储介质、处理器等等）的抽象。体系结构200还提供UI 240来支持用户交互性并方便了有效的用户体验，并且将通常被具体化为图形用户界面。

诸如移动电话之类的便携式平台通常配备有同步能力以便提供用于例如在基于Windows的PC与便携式平台（如上所述，其可以为基于Windows CE的）之间同步数据的过程。使用时间戳和用户偏好，同步过程跟踪两个设备上的数据改变，并且然后传输合适的数据，使得每个机器都具有最新的版本。过期或不想要的数据通常被丢弃。在用户通常将一次使用一个设备但是想要使两个设备都将数据、文件、联系人、任务、提醒、日程安排等等保持为最新的条件下，这样的同步能力常常是便利的。例如，用户可以在他或她的移动电话和PC二者上保持任务列表和联系人信息（例如朋友、同事、家人等等的地址、电话号码等等），并且想要确保：使用移动电话对任务列表作出的改变将反映在PC上。

如图3所示，移动电话115₁使用电缆连接310耦合到用户的PC 305，所述电缆连接310采用串行或USB（通用串行总线）协议。连通性还可以使用无线连接（例如无线以太网）或红外（例如IrDA－红外数据协会）来实现。通常，如所示那样利用具有在每个设备上运行的组件的数据同步应用来将电话数据315与PC数据320。

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

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

如图5所示，该特定示例性实施例中的功能模块可以至少部分地通过计算机可执行代码来实现，所述代码被写入到部署在移动电话115₁上的一个或多个存储介质上，并且通过电话的硬件中包含的一个或多个处理器来执行。因此在这一点上，所示的安排可以被看作“胖客户端”，因为功能组件实现的代码基本上整体在移动电话115₁上执行，以便提供按设计的用户体验和应用程序行为。在可替换的实现中，功能组件以分布式计算安排的形式来配置，且移动电话115₁上的代码可以从瘦客户端执行。该替代方案在图13和14予以示出，并且在伴随这些附图的说明书部分中予以描述。

如所示那样，呼叫提醒应用205通过如下方式来支持用户体验：适应用户偏好520₁；在呼叫事件发生时提供呼叫处理选项520₂；在合适的时间利用“单击”回叫特征来启动提醒530₃；以及提供为了满足给定使用场景可能需要的其他用户体验520_N。用户偏好和呼叫处理选项在下面对图6和7的描述中予以更详细描述。

呼叫提醒应用205也可以和在移动电话115₁上执行的其他应用程序交互。在该特定的示例性实施例中，呼叫提醒应用205通常与日程安排应用220交互以便创建任务和提醒。然而，也可以以在此讨论的类似的方式使用与其他应用程序的交互。在许多使用场景中，呼叫提醒应用205将实现诸如下列查询来标识出用户的与呼叫事件相关联的联系人：查询联系人列表525₁；查询日历功能以找出用户日常安排中的无安排的时间段525₂；创建用户的任务列表中的任务525₃；设置和更新提醒525₄；以及支持为了支持在此所述的特征可能需要的各种其他交互525_N。

呼叫提醒应用205一般将应用业务逻辑和规则来实现应用程序的所期望的行为，这由附图标记530来指示。业务逻辑和规则的应用通常响应于接收到由监听器410监视到的呼叫事件来实现各种例程、进程和工作流以支持上述用户体验。

呼叫提醒应用205还支持各种数据处理功能，包括接收呼叫事件535₁以及诸如呼叫元数据之类的相关联信息535₂。在一些情况下，呼叫提醒应用205通常在临时或持久基础上存储呼叫数据、以及存储用户偏好和使用历史535₃。其他数据处理也可如附图标记535_N所指示的那样来执行，以满足给定使用场景的需要。

图6是可被呼叫提醒应用利用的用户偏好和缺省呼叫提醒应用行为的说明性分类600。该附图中所示的用户偏好和缺省应用行为是说明性的，并且在许多给定使用场景中被利用的特定用户偏好和行为可能不同于在此所示和所述的情况。

常常可以预期的是，用户在首次设置呼叫提醒应用205时会设置偏好以便制定：应用在缺省情况下（即在应用启动的随后实例期间）将作出何种行为。然而，呼叫提醒应用通常被配置为使得缺省能够在任何时间被改变。如图6所示，用户可以选择在呼叫事件发生以后将启动呼叫提醒应用205的呼叫事件（这由附图标记600₁来指示）。呼叫事件例如可以包括：到移动电话115₁的传入呼叫；在电话被使用时的传入呼叫（即“呼叫等待”）；被用户拒绝的呼叫；错过的呼叫；用户关闭响铃器时的呼叫（例如通过按下“无声”或静音按钮）；等等。

另外，在一些实施方式中，被用户接听但时长短（其中“短”可以是任意值、或者在一些情况下由用户设置）的呼叫也可以被认为是将触发回叫提醒的呼叫事件。例如，按照推测，持续10秒或更短的呼叫可以短得足以保证晚些时间的附加对话（即用户可能接听该呼叫并说：“我现在不方便说话，但我会晚些给你回电”）。在这样的实施方式中，可以任选地向用户提供选项来设置将触发呼叫提醒应用的启动的最小呼叫时长（600₂）。

用户可以选择回叫提醒被设置为预定义的时间（600₃）。如果该选项被选择，则通常可以向用户提供通过从多个设置菜单选择进行选取或者设置特定指来设置预定义时间的能力（600₄）。例如，用户可以将回叫提醒设置为在呼叫事件发生以后的某个数目的分钟、小时、天等等时启动。

可替代地，用户可以将回叫提醒设置为被设成用户的日程安排中的空闲时间段（600₅）。在一些实例中，缺省应用行为可以是：呼叫提醒被插入到用户日程安排中的第一可用空闲时间段中。在其他情况下，可以向用户提供指定选择标准的选项（600₆）。例如，回叫提醒可以被插入到某个时间以后（即呼叫提醒将仅在正常工作时间后的傍晚启动）或者在某些天（例如周末）的第一可用时间段中。在一些实施方式中，所期望的可能是，使得用户能够向所生成的任务和/或回叫提醒分配优先级，并且时间段选择可以基于优先级的确定。

通常可以使得用户能够设置随着传入呼叫发生的在呼叫提醒应用启动以前的响铃次数（600₇）。设置较大的响铃次数将意味着，用户将具有更多时间在应用启动以前以便利的方式处理传入呼叫（即接听呼叫、拒绝呼叫等等），并且向用户提供生成任务和回叫提醒的选项。还可以向用户展示为了满足给定使用场景的需求可能需要的其他用户偏好和缺省应用行为设定（600_N）。

图7是在合格的呼叫事件（其中呼叫事件在其通过缺省行为或者通过被用户选择而触发呼叫提醒应用时被认为是“合格”的）发生以后可以被呼叫提醒应用利用的呼叫处理选项的说明性分类700。该附图中所示的呼叫处理选项是说明性的，并且在任何给定使用场景中被利用的特定选型可能不同于在此所示和所述的情况。在一些实施方式中所期望的可能是，使得用户能够设置在给定呼叫事件被处理时回叫提醒被启动的时间，而不是依靠缺省时间或者在事件之前通过用户偏好选择的时间。

因此，可以向用户提供选项来将回叫提醒设置为在呼叫事件以后的预定义的时间间隔启动（其由附图标记700₁来指示）、以及指定该时间间隔（即分钟/小时/天等等的数据）（700₂）。可替代地，用户可以指定：回叫提醒设置被插入到用户的日程安排中的空闲时间段中（700₃）。在这种情况下，可以给用户实现从日程安排应用中浏览他或她的日历（700₄）的能力以对合适的时间段进行定位。

在一些实施方式中所期望的可能是，在合格的呼叫事件发生以后向用户展示选项来给任务或回叫提醒设置优先级或者附加其他某个属性（700₅）。例如，可以为回叫提醒或任务确定比用户的日程安排上的其他提醒或任务更高的优先级，或者向回叫提醒或任务赋予较低优先级，使得回复的电话呼叫是在一天结束时用户需要处理的最后一件事。

以类似于回叫提醒的方式，呼叫提醒应用205可以被配置为使得用户可以在他或她的任务列表中添加回叫任务以作为在合格的呼叫事件发生以后所展示的呼叫处理选项（700₆）。另外，可以向用户提供将其他信息或笔记添加到回叫任务的机会（700₇）。例如，用户可能想要用指示呼叫的主题的笔记或者用其他相关信息（例如“关于即将到来的班级重聚给Bill回电”）来注释回叫任务。还可以向用户展示为了满足给定使用场景的需求可能需要的其他呼叫处理选项（700_N）。

图8是可以被呼叫提醒应用205利用的说明性工作流800的流程图。该工作流开始于框805，在该框805，监听器410等待合格的呼叫事件的发生（说明性的合格呼叫事件的列表由图8中的附图标记810来指示）。在判定框815，当这样的呼叫事件发生时，应用205将取出诸如呼叫者的标识和呼叫号码之类的相关呼叫数据以供通过UI与提示“为该呼叫者添加回叫任务”一起显示。如果用户指示“否”，则工作流控制返回到框805。如果用户指示“是”，则在判定框820，如果针对该呼叫者已经存在回叫任务，则将把呼叫数据（比如最后一个呼叫的日期和时间）添加到已有任务，并且将在框825更新已有提醒，并且工作流控制返回到框805。

如果还不存在回叫任务，则控制传递到框830或框840（在那里，如虚线所指示的那样，通常将实现所述过程之一或另一而不是二者）。在框830，呼叫提醒应用205查询日程安排应用220以找出合适的时间段来设置回叫提醒。在框835，呼叫提醒应用205将把回叫提醒调度为在预定义的时间发生。在框840，呼叫提醒应用205创建新任务并且设置提醒，其中任一或二者可以被添加到由日程安排应用220维护的用户任务列表和日程安排。然后，工作流控制返回到框805。

图9－12示出了呼叫提醒应用支持的UI的各种说明性屏幕截图。图9示出了在移动电话115₁处接收到传入呼叫905时该UI的说明性屏幕截图900。在该示例中，显示包括呼叫者的电话号码910和身份915的呼叫数据。在该示例中，呼叫处理由移动电话115₁上运行的应用程序以通常的方式实现，它将传入呼叫数据和该用户的联系人列表进行比较，以获取并显示呼叫者的身份。在可替代的实施方式中，这样的呼叫处理功能可以由本呼叫提醒应用205来处理。

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

根据本安排的原理，图10示出了在由合格呼叫事件905触发呼叫提醒应用205启动以后显示提示1005时的UI的示例性屏幕截图1000。提示1005向用户询问：是否应当为该呼叫者生成回叫任务和相关联的提醒。如上所述，在一个实施例中，呼叫提醒应用可以在与传入呼叫905相关联的所设置的次数的响铃完成以后启动。当显示提示1005时，按钮1010和1015也被显示以使得用户能够实现回叫呼叫处理以按照期望设置任务和提醒（或者不设置任务和提醒）。

图11示出了示例性屏幕截图1100，该屏幕截图示出了针对错过呼叫1105的合格呼叫事件的呼叫处理。当这样的事件发生时，支持例程呼叫处理任务的应用通常将显示错过呼叫的号码1110、呼叫者的身份1115、以及错过呼叫的日期和事件1120。可替代地，呼叫提醒应用205可以取出该呼叫数据并将其显示在UI上。如所示那样，呼叫提醒应用205将显示提示1125，所述提醒1125向呼叫者询问：是否应当为该呼叫者生成相关联的提醒的回叫任务。当在UI上显示提示1125时，按钮1130和1135也被显示以使得用户能够实现回叫处理以按照期望设置任务和提醒（或者不设置任务和提醒）。

图12示出了示例性的屏幕截图1200，该屏幕截图示出了针对图11所示的错过呼叫1105的回叫提醒1205。如在时钟显示1210上所示那样，该特定回叫提醒是在呼叫被错过的那天晚些时候（2pm）被触发的。因此，2pm可能是由呼叫提醒应用205如上述那样自动选择的空闲时间段，或者是由用户在错过呼叫事件发生时完成各个呼叫处理选项时人工选择的。

呼叫提醒将包括由呼叫提醒应用205取出并且UI上显示的相关呼叫数据。在该示例性实施例中，呼叫数据包括呼叫者的号码1215、呼叫者的身份1220、以及最后一个呼叫的日期和时间1225。在回叫提醒中还包括有回叫提示1230，所述回叫提示1230使得用户能够利用对合适按钮1235或1240的点击来拨打回叫（或者不拨打回叫）。

图13示出了说明性地被安排成移动电话115₁上的瘦客户端1300的呼叫提醒应用205。在这种情况下，功能组件以及相关联的代码执行跨多个计算平台分布，这些计算平台例如包括移动电话115₁以及由如图1所示的服务提供者145操作的一个或多个服务器。服务提供者145通常将具有对图1的通信网络120的相关部分的访问，并且被安排为使用分布式或基于云的计算范例来支持所期望的用户体验和应用行为。

注意，当用在分布式计算环境中时，各个实施方式将在功能组件方面是显而易见的，并且因此可能与它们用在上述瘦客户端应用中的对应物具有一定程度的不同。如所示那样，通常仅用户体验层505将驻留在移动电话115₁上并且相关联的代码将本地地在移动电话115₁上执行。业务逻辑层510和数据层515将驻留在服务提供者服务器上并且相关联的代码将在云中执行。

图14示出了说明性的布置1400，其中呼叫提醒应用205的某个功能在被配置为移动电话115₁上的瘦客户端时由服务提供者145来支持，所述服务提供者145可操作地耦合到通信网络120。在该布置中，从呼叫者110₁向用户105₁的呼叫1405作为呼叫1410被转发或重新路由到服务提供者145。用于实现呼叫的重定向的特定方法可能因实施方式而异，并且还可能取决于附图提供者145与用户的电话服务载体之间商业关系。在一些情况下，用户105₁可以指示该载体将呼叫转发给服务提供者145，而在其他情况下，服务提供者145可以按照用户105₁与服务提供者145之间的协议代表用户实现呼叫重新路由。

服务提供者145将呼叫1415中继到用户105₁并且然后监听呼叫事件1420。这样的监视通常可以使用带外（“OOB”）信令来执行，所述带外信令例如通过移动数据网络来实现。在合适呼叫事件发生以后，服务提供者145将把包括提示（例如图10和11中的提示1005或1125）的通知1425发送给用户105₁以生成回叫提醒和任务。用户与由用户体验层505提供的UI之间的交互被捕捉为UI事件（1430），并且通常再次使用OOB信令被发送给服务提供者145。在合适时，服务提供者145可以建立到日程安排应用220的必要链接，并且作为响应发起回叫提醒和相关联的任务（1435），其然后被发送给移动电话115₁。

服务提供者145可以任选地例如使用因特网链接将呼叫数据1440（比如呼叫事件历史、呼叫日志等等）和回叫提醒和任务1445发送给用户的PC 1450。这样的任选功能有利地保证：提醒和任务在用户105₁所使用的多个平台间复制，而不需要上面在附图3中所述的对同步的确认行为。

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

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

Claims (15)

1.一个或多个包含指令的计算机可读存储介质，所述指令在部署在可操作地耦合到通信网络的电子设备中的一个或多个处理器执行时执行包括一种用于设置回叫提醒的方法，该方法包括下列步骤：

监视与在设备处从呼叫者接收到的呼叫相关联的呼叫事件，所述呼叫由所述通信网络来承载；

响应于检测到呼叫事件取出与所述呼叫相关联的呼叫数据，所述呼叫数据至少包括所述呼叫者的呼叫号码；

启动提示，所述提示向所述设备的用户提供可选择的选项以用于生成呼叫提醒；以及

链接到所述用户的日程安排，所述日程安排由运行在所述设备上的应用来运行，所述链接包括：定位所链接的日程安排中的空闲时间段以用于所述呼叫提醒。

2.如权利要求1所述的一个或多个计算机可读存储介质，其特征在于，该方法还包括响应于对所述选项的用户选择生成回叫提醒的步骤。

3.如权利要求1所述的一个或多个计算机可读存储介质，其特征在于，该方法还包括响应于所述链接步骤启动回叫提醒的步骤，所述回叫提醒被显示在由所述设备支持的UI（用户界面）上并且包括所述呼叫数据和用户可选择的控件，所述用户可选择的控件在驱动以后发起向所述呼叫者的回叫号码的回叫。

4.如权利要求3所述的一个或多个计算机可读存储介质，其特征在于，所述驱动包括在所述UI上单击。

5.如权利要求4所述的一个或多个计算机可读存储介质，其特征在于，该方法还包括访问由运行在所述设备上的应用维护的任务列表并且将回叫任务添加到所链接的任务列表的步骤。

6.如权利要求5所述的一个或多个计算机可读存储介质，其特征在于，所述日程安排和任务列表由在所述设备上运行的单个应用来维护。

7.如权利要求1所述的一个或多个计算机可读存储介质，其特征在于，所述呼叫事件包括下列各项之一：传入呼叫、被拒绝的呼叫、呼叫等待、错过的呼叫、或者未超过时长阈值的呼叫，所述时长阈值要么被设置成任意值、要么是用户可设置的。

8.如权利要求1所述的一个或多个计算机可读存储介质，其特征在于，所述呼叫数据还包括呼叫者身份、呼叫被接收的日期、或者呼叫被接收的时间。

9.如权利要求1所述的一个或多个计算机可读存储介质，其特征在于，还包括将UI展示给所述用户的步骤，所述UI包括一个或多个控制元素，所述一个或多个控制元素被安排用于以下之一：选择与回叫提醒相关联的偏好；或者在该方法的应用在所述设备上操作时配置所述应用。

10.一种移动电话，包括：

一个或多个处理器，所述一个或多个处理器用于执行机器可执行指令；以及

一个或多个用于存储所述机器可执行指令的机器可读存储介质，所述指令在被所述一个或多个处理器执行时实现：

a）呼叫事件监听器，所述呼叫事件监听器被安排为用于监听与在所述移动电话处从呼叫者接收的呼叫相关联的呼叫事件的发生；

b）数据处理器，所述数据处理器用于响应于检测到呼叫事件取出与所接收的呼叫相关联的呼叫数据，所述呼叫数据至少包括所述呼叫者的回叫号码；

c）处理逻辑，所述处理逻辑用于在呼叫事件发生时生成回叫提醒以及将所生成的回叫提醒链接到存储在所述移动电话上的日程安排或任务列表之一；以及

d）UI（用户界面），所述UI被安排为用于在显示设备上将所述回叫提醒显示给所述移动电话的用户以及提供控制设备，所述控制设备在被用户驱动时发起从所述移动电话到所述回叫号码的回复呼叫。

11.如权利要求10所述的移动电话，其特征在于，所述回叫提醒包括所取出的呼叫数据。

12.如权利要求10所述的移动电话，其特征在于，所述链接是通过API（应用编程接口）建立的。

13.如权利要求10所述的移动电话，其特征在于，将所述监听器向在所述电话上执行的操作系统注册。

14.如权利要求10所述的移动电话，其特征在于，所述UI还被安排为向用户展示选择合格的呼叫事件的控件，所述合格的呼叫事件的发生触发显示在所述显示设备上的提示以用于添加回叫任务或回叫提醒。

15.如权利要求10所述的移动电话，其特征在于，所述UI还被安排为向用户展示指定被所述处理逻辑考虑的偏好的控件。

Images