用于基于上下文的装置动作预测的方法和系统.pdf

本发明公开了用于基于上下文的装置动作预测的方法和系统。所描述的实施方式涉及自动地执行装置动作。一种实施方式可以获得上下文情境的上下文值。该实施方式可以使用决策引擎，基于上下文值来决定是否对计算装置执行动作。在决策引擎决定要执行动作的情况下，该实施方式可以对计算装置执行动作。该实施方式还可以使用与动作有关的反馈来更新决策引擎。作为具体示例，动作可以是在用户请求执行应用之前预先启动该应用。预先启动应用可以减少与在启动应用之前等待用户请求执行应用有关的应用延迟。

权利要求书一种方法（500），包括：
从一个或多个上下文情境（211,212,213,214,215,216）获得（503）一个或多个上下文值；
使用包括一个或多个决策规则（401,402,403）的决策引擎（221,222,223），基于所述一个或多个上下文值和所述一个或多个决策规则来决定（504）是否对计算装置（110,702,714）执行动作（231,232,233）；
在所述决策引擎决定要执行所述动作的情况下，对所述计算装置执行（505）所述动作；以及
使用与所述动作有关的反馈来更新（506）所述决策引擎的所述决策规则。
根据权利要求1所述的方法，其中，从所述计算装置上的物理传感器获得单个上下文值。
根据权利要求1所述的方法，其中，单个上下文值反映所述计算装置的用户的活动或其它计算装置上的其他用户的活动。
根据权利要求3所述的方法，所述活动包括所述用户在所述计算装置上执行应用。
根据权利要求3所述的方法，所述活动包括所述用户使用所述计算装置与另一个体通信。
根据权利要求1所述的方法，其中，单个上下文值反映所述计算装置的当前时间或当前位置。
一种系统，包括：
基于上下文的动作模块（111）；以及
计算装置（110,702,714），被配置成执行所述基于上下文的动作模块，
其中，所述基于上下文的动作模块被配置成：
在第一情况下：
获得上下文情境（211,212,213,214,215,216）的上下文值；
使用决策引擎（221,222,223）来基于所述上下文值决定不对所述计算装置执行动作（231,232,233）；以及
不对所述计算装置执行所述动作；
将与所述动作有关的反馈提供给所述决策引擎，其中，所述决策引擎被更新，以学习在所述上下文情境具有所述上下文值时执行所述动作；
在所述第一情况之后的第二情况下：
获得所述上下文情境的与在所述第一情况下获得的相同的上下文值；
使用更新后的决策引擎来基于所述相同的上下文值决定对所述计算装置执行所述动作；以及
对所述计算装置执行所述动作。
根据权利要求7所述的系统，其中，所述决策引擎包括决策树。
根据权利要求7所述的系统，其中，所述决策引擎包括贝叶斯分类器。
根据权利要求9所述的系统，其中，所述贝叶斯分类器是朴素贝叶斯分类器。

说明书用于基于上下文的装置动作预测的方法和系统
技术领域
本申请一般地涉及基于上下文的装置动作预测，并且特别地涉及用于基于上下文的装置动作预测的方法和系统。
背景技术
应用软件可以取决于各种因素响应于用户输入而变化，这些因素包括应用是否是相对资源密集的，以及运行应用的装置的可用硬件资源是否足以满足应用的资源需求。例如，一些移动装置应用的起动延迟（startup latency）相对长，大约为10至15秒。由于与较旧的应用相比，较新的应用趋于需要更多的资源，因此该问题在较旧的硬件被用于执行较新的应用时特别尖锐。
一种用于减少应用起动延迟的一般方法是将应用加载到存储器中或者甚至在用户实际调用应用之前开始执行应用。然而，移动装置趋于是相对地资源受限的，并且将存储器或处理器资源分配给当前不使用的应用并不总是可接受的。实际上，在一些情况下，该方法可能通过加载不必要的数据和/或执行不必要的指令而不必要地耗尽电池电量。
发明内容
所描述的实施方式涉及自动地执行装置动作。一种实施方式被表现为如下一种技术，该技术可以包括从一个或多个上下文情境（contextor）获得一个或多个上下文值。该技术可以包括使用包括一个或多个决策规则的决策引擎，基于一个或多个上下文值和一个或多个决策规则来决定是否对计算装置执行动作。该技术还可以包括在决策引擎决定要执行动作的情况下对计算装置执行动作。该技术还可以包括使用与动作有关的反馈来更新决策引擎的决策规则。
另一实施方式被表现为如下一种技术，该技术可以包括基于一个或多个上下文值来识别要预先启动（prelaunch）的应用。该技术还可以包括预先启动应用以将该应用置于预先启动状态，以及接收与预先启动有关的反馈。
另一实施方式被表现为如下一种系统，该系统可以包括基于上下文的动作模块和计算装置。计算装置可以被配置成执行基于上下文的动作模块。基于上下文的动作模块可以被配置成在第一情况下：获得上下文情境的上下文值，使用决策引擎基于上下文值来决定不对计算装置执行动作，以及不对计算装置执行动作。基于上下文的动作模块还可以被配置成将与动作有关的反馈提供给决策引擎，并且决策引擎可以被更新，以学习在上下文情境具有上下文值时执行动作。基于上下文的动作模块还可以被配置成在第一情况之后的第二情况下：获得上下文情境的与在第一情况下获得的相同的上下文值，使用更新后的决策引擎基于相同的上下文值来决定对计算装置执行动作，以及对计算装置执行动作。
以上列出的示例旨在提供辅助读者的快速参考，并且不旨在限定本文中描述的概念的范围。
附图说明
附图示出了本专利中所传达的构思的实施方式。可以通过参考以下与附图相结合的描述而更容易地理解所示出的实施方式的特征。在可行的情况下，各个图中的相似的附图标记用于表示相似的元件。此外，每个附图标记的最左侧的数字表示首次介绍该附图标记的图和相关联的讨论。
图1示出了可以采用本构思的一些实施方式的示例性场景。
图2示出了根据本构思的一些实施方式的模块的示例性架构。
图3A和图3B示出了根据本构思的一些实施方式的示例性图形用户界面。
图4A、图4B和图4C示出了根据本构思的一些实施方式的示例性决策规则。
图5和图6示出了根据本构思的一些实施方式的示例性方法的流程图。
图7示出了根据本构思的一些实施方式的系统的示例。
具体实施方式
概况
本讨论涉及使得装置基于对装置的决策引擎可用的信息而自动地采取各种动作。例如，在一些实施方式中，在用户实际请求执行特定应用之前启动（launch）该特定应用。在一些情况下，在用户请求执行应用之前启动应用可以减少应用起动延迟并提供更令人满意的用户体验。由于移动装置趋于为相对地资源受限的，并且所公开的实施方式可能特别适合于在资源受限装置上的实施，因此，本文中提供的某些示例是关于移动装置而讨论的。然而，还可以对其它类型的计算装置（诸如膝上电脑、服务器等）执行所公开的实施方式。
通常，用户可通过使用例如鼠标、滚轮、触摸屏或其它输入方法来识别并且选择表示应用的图标、平铺显示（tile）或其它界面元素而请求执行应用。可以从桌面、菜单或其它界面中选择图标。为了本文档的目的，术语“启动”（launching）是通用术语，该通用术语包括通常响应于接收到执行应用的这种用户请求而发生的各种动作。例如，启动可以包括为应用分配存储器以及将应用从存储装置加载到所分配的存储器中。启动还可以包括执行加所载的应用代码，以执行可能与应用初始化有关的功能。例如，可以作为启动的一部分来执行从网络取回诸如网页、图像、视频等的数据的应用代码。诸如线程和/或处理的处理器资源也可以被分配作为启动应用的一部分。
从架构上，所公开的技术可以通过使用决策引擎来实现，该决策引擎将一个或多个“上下文情境”的值映射至不同的动作。一般来说，上下文情境提供可被决策引擎用于确定是否要采取特定动作（诸如启动应用）的状态信息。例如，一些上下文情境具有直接从移动装置上的一个或多个物理传感器（诸如加速计、光传感器、全球定位系统（“GPS”）、麦克风、时钟等）获得的或者从这一个或多个物理传感器以逻辑方式得到的值。其它上下文情境可以反映用户的活动，诸如请求特定应用、呼叫特定家庭成员、发送具有特定词的文本消息等。
为了本文档的目的，术语“上下文情境”（contextor）一般用于表示例如来自传感器、操作系统、单个应用等的对装置可用的信息源。术语“上下文值”用于指代单个上下文情境的值，并且可以包括直接值（例如，环境温度）或者以逻辑方式得到的值（例如，通过将温度转换成诸如冷、暖等的术语）。一般地，决策引擎可以学习对于一个或多个上下文情境的当前或历史上下文值（包括序列）要采取哪些动作。可以通过各种动作隐含地或明确地提供反馈，以改进决策引擎并借此学习用于特定上下文情境的特定上下文值，接着这些特定上下文值被用于触发特定动作。注意，决策引擎可以根据决策引擎决定自动地对用户采取特定动作的情况或者根据用户直接采取动作（即，没有决策引擎的参与）的情况进行学习。
一般来说，当前或历史上下文值可以用于训练单个决策引擎以及确定是否采取特定动作。除非特别另行指出，否则本文中所使用的术语“上下文值”可以指代特定上下文情境的当前值或历史值。在一些实施方式中，上下文情境日志用于存储随时间的上下文值的历史。此外，在一些情况下，也可以从上下文情境日志获得上下文值的特定序列并且由单个决策引擎来应用这些序列。上下文值序列的一个示例可以是应用使用模式，例如，用户可在特定序列中始终使用三个不同的应用。
动作的一个示例是上述的应用启动。术语“预先启动”在本文中用于指代在用户通过提供某种类型的装置输入而实际请求调用应用之前至少部分地启动该应用。例如，用户可能常常在结束与特定联系人的电话呼叫之后不久打开社交联网应用，例如以检查该人的社交联网简档以得到状态更新、图片、评论等。决策引擎可以学习在例如电话呼叫期间或在用户结束电话呼叫之后不久在用户实际请求执行社交联网应用之前预先启动该应用。一旦决策引擎学会了在适当情形下进行预先启动，则通过抢先为用户预先启动社交联网应用，用户就可在调用社交联网应用时经历相对少的延迟。在该情况下，电话日志上下文情境可以提供用于表示用户已通过电话与其对话的各个联系人的上下文值。在一些实施方式中，还通过电话日志上下文情境提供与呼叫有关的其它信息，例如，呼叫发生时的时间/天/日期、是Bob呼叫了用户还是用户呼叫了Bob、Bob和/或用户是用工作号码还是个人号码呼叫等。
动作的另一示例是自动地调整装置的铃声的音量。考虑如下用户：该用户常常在麦克风检测到的环境噪声相对高时增大其铃声的音量。决策引擎可以学习在麦克风检测到的环境噪声上下文情境的值在特定阈值以上时采取动作（增大铃声的音量）。决策引擎可以学习该环境噪声阈值，作为触发动作的特定上下文值。换言之，在环境噪声上下文情境提供的上下文值表示增大铃声音量是决策引擎要采取的适当动作的情形下，决策引擎可以抢先使得铃声音量增加而无需用户输入。随着时间，决策引擎可以学习（1）在高环境噪声情形下采取增大铃声音量的动作，（2）改进触发决策引擎采取该动作的环境噪声的量，以及（3）例如响应于环境噪声的不同水平和/或用户偏好而将特定音量水平调整得更高或更低。
如上所述，可以经由表示特定动作是否适当的反馈来训练决策引擎。因此，决策引擎可以在采取给定动作之后接收反馈，然后使用该反馈来改进决策引擎。考虑以上阐述的决策引擎增大铃声音量的示例。如果用户随后忽略呼叫或减小铃声音量，则这可能导致对决策引擎的负反馈。在启动上述社交联网应用的示例中，反馈可以表示在启动应用之后的预定时间量（例如，30秒）内用户是否实际决定提供用于启动社交联网应用的某种装置输入。如果是，则这一般可以被视为对决策引擎的“正”反馈，该“正”反馈增强了在用户呼叫特定家庭成员之后不久采取启动应用的动作的决策。替选地，如果用户没有在预定时间量内提供用于启动社交联网应用的装置输入，则这可以被视为对决策引擎的“负”反馈，该“负”反馈可以使得决策引擎减小在这些情形下预先启动社交联网应用的几率。
注意，在该示例中，应用不一定为决策引擎提供明确的反馈。更确切地说，反馈是隐式的，例如，应用不需要报告用户启动了或者没有启动应用。替代地，该信息可以由移动装置的操作系统来提供，其中决策引擎是操作系统的一部分。在其它情况下，可以由应用提供明确的反馈，例如，通过由应用发送到决策引擎的、用于表示决策引擎所采取的具体动作是否适当的数值或布尔值来提供这种反馈。作为明确的应用反馈的一个示例，应用可以通知决策引擎该应用花费了多长时间进行预加载。一般地，对于给定应用的相对长预加载时间表示该应用是预加载有益的应用，并且因此用作对应用启动决策引擎的正反馈。相反，相对短的预加载时间表示预加载该应用获得相对少的益处，并且因此用作对应用启动决策引擎的负反馈。
注意，甚至在上下文值用作对应用使用模式非常好或几乎完美的指示符时，上述应用反馈也可以是有用的。例如，即使一个或多个上下文情境表示在不久的将来用户将几乎肯定启动特定应用，如果加载应用通常发生得非常快以至于用户感知不到延迟，那么也只能获得非常少的益处。相反，即使一个或多个上下文情境仅提供用户将启动给定应用的相对不确定的表示，如果应用在未被预先启动的情况下花费很长时间来响应用户，那么预先启动应用仍然可能是值得的。
示例场景
图1示出了场景100，其中，上下文可以被用于抢先执行装置动作。场景100包括情况1和2，以下讨论每个情况。从情况1开始，示例场景100示出了在用户已请求启动特定应用（例如，上述社交联网应用）之后不久（例如，五秒）的移动装置110。例如，用户可能提供了表示应该启动应用的某种装置输入（经由键盘、口头命令、轨迹球、触摸屏等）。然而，应用可能会由于应用正在进行某种初始化处理（例如，从存储装置被加载到存储器、通过操作系统被切换到活跃应用上下文（处理或线程）中、试图通过网络取回数据等）而仍无法响应于用户命令。
然而，如图1中所示，移动装置110可以包括基于上下文的动作模块111，该基于上下文的动作模块111可以被配置成预先启动应用以减少用户感知到的延迟。一般地，基于上下文的动作模块111可以从移动装置获得上下文，例如，在情况1处表示移动装置被用于呼叫“Bob”的一个或多个上下文值。上下文值还可以表示在接收到启动社交联网应用的用户请求之前不久（例如，两分钟内）发起或接收呼叫。随着时间，基于上下文的动作模块111可以学习到预先启动社交联网应用是在用户呼叫了Bob或者从Bob接收到了呼叫之后要为用户采取的适当动作。因此，在情况2处，基于上下文的动作模块可以在用户实际请求社交联网应用之前启动该应用。因此，社交联网应用可被初始化，并且准备好在用户下次呼叫Bob时供用户使用。这大致在情况2处示出，其中，作为预先启动的一部分，社交联网应用已将一些图片下载到移动装置。
示例架构
图2示出了基于上下文的动作模块111的示例性架构。如图2中所示，基于上下文的动作模块111可以包括上下文管理器210、映射管理器220和动作管理器230。一般来说，上下文管理器210可以被配置成管理一个或多个上下文情境，这一个或多个上下文情境包括时间211、位置212、电话日志213、环境噪声214、环境光215、应用使用216等。对于时间211可从本地装置时钟和/或时间服务器获得上下文值，对于位置212可从GPS和/或蜂窝三角测量获得上下文值，对于电话日志213可从呼叫记录应用获得上下文值，对于环境噪声214可从本地装置麦克风获得上下文值，对于环境光215可从本地装置光传感器获得上下文值，而对于应用使用216可从操作系统获得上下文值。一般地，可以例如从传感器等在移动装置本地获得各个上下文值，并且在一些情况下，这些上下文值被存储在一个或多个本地上下文情境日志中。然而，在一些情况下，可以例如在服务器上远程地维护和存储上下文情境日志，并且由移动装置取回这些上下文情境日志以用于供基于上下文的动作模块使用。
也构思了图2中未示出的上下文情境的其它示例。一般地，可以由移动装置110的各种装置传感器和/或移动装置所保持的其它信息（诸如操作系统日志等）来提供其它上下文情境。如以下更详细地讨论的，上下文情境可以是例如经由图形用户界面（“GUI”）而可供用户选择的，该图形用户界面允许用户选择上下文管理器210使用哪些上下文情境。
此外，注意，开发者可以建立可被决策引擎用于执行动作的新上下文情境。例如，考虑将电子罗盘安装在移动装置上的第三方应用。可以在此时安装用于提供电子罗盘的值（例如，方位角或逻辑方向（北、西北等））的相应上下文情境。现有的决策引擎可以学习使用新安装的上下文情境来采取各种动作而无需进一步修改，例如，新上下文情境“插入”到由上下文管理器提供的现有框架。不管新的上下文情境是由移动装置的制造者、移动装置操作系统的开发者（“第一方”）还是第三方应用开发者提供的，情况都可以是这样的。
基于上下文的动作模块111还可以包括映射管理器220，映射管理器220可以被配置成将各个上下文情境提供的上下文值映射至相应动作。映射管理器220可以包括一个或多个被配置成执行映射的决策引擎，例如，应用或“app”启动决策引擎221、铃声音量决策引擎222和/或屏幕亮度决策引擎223。各个决策引擎可以使用不同的决策算法来实现，包括概率/统计/随机模型，经由机器学习技术进行在线或离线学习等。不管决策引擎的特定实现方式如何，其中实现的决策算法都可以确定是否采取特定动作。一般地，先前的装置动作和上下文值的历史可以用于随着时间训练决策引擎，以使得决策引擎学习以对用户有益的方式来改进各种装置动作的选择。先前的装置动作可以是决策引擎先前采取的装置动作（诸如预先启动应用），或者用户采取类似动作（诸如直接经由用户输入启动应用而无需决策引擎预先启动）的情况。如以上对于上下文情境所述的，第一方或第三方开发者也可以提供新决策引擎，这些新决策引擎直接插入到映射管理器，并且可以使用现有的上下文情境开始进行决策以执行各种动作。例如，装置可能来自制造者并具有朴素贝叶斯决策引擎，并且第三方开发者可以随后提供插入到映射管理器的、加时间窗的（time‑windowed）快速决策树（very fast decision tree）决策引擎。
动作管理器230可以被配置成对映射管理器220的决策引擎可采取的各种动作进行管理。例如，动作可以包括预先启动app动作231、调整铃声音量动作232和/或调整屏幕亮度动作233。一般来说，映射管理器所管理的每个决策引擎可以采取动作管理器所管理的动作中的一个或多个动作。在一些实施方式中，动作也可以是例如经由图形用户界面（“GUI”）而可被用户选择的，该图形用户界面允许用户选择动作管理器230所使用的动作。像上下文情境和决策引擎一样，动作也可以由第一方或第三方开发者独立地提供。例如，上述电子罗盘可以提供使得罗盘点亮的动作。随着时间，决策引擎可学习在特定时间、在低环境光下等为用户照亮罗盘。更一般地，新的动作可以被插入到动作管理器，以使得现有的决策引擎可以学习响应于现有的上下文情境而采取新近可用的动作。
在以下讨论中，既一般地描述了预先启动应用动作，又关于均可视为预先启动动作的一部分的各个特定子动作（例如，从存储器加载应用代码、执行代码等）描述了预先启动应用动作。另外，注意，术语“预先启动”在本文中一般用于表示在用户请求执行应用之前执行应用的至少部分启动。因此，预先启动执行应用的至少部分启动，以将应用置于预先启动状态（代码/数据已加载到存储器中、代码已执行等），以使得如果用户随后请求执行应用则可从预先启动状态执行应用。
另外，注意，在一些实施方式中，各个决策引擎可以采取多个动作，例如，预先启动的每个应用可以被构想为不同的动作。类似地，调整铃声音量可以被视为单个动作或包括数个动作，例如用于调高或调低音量的分开的动作。这对于调整屏幕亮度同样成立。
单个决策引擎是否采取特定动作是用作该决策引擎的输入的上下文情境的值的函数。随着时间，各个动作可以在决策引擎采取这些动作的任何时候来提供正反馈或负反馈。该反馈可以用于更新决策引擎以采取可能对装置的用户有用的动作，例如，通过自动地提高铃声的音量和/或为用户预先启动应用来进行。在图2中经由连接各个动作和决策引擎的双向箭头大致示出了从动作到决策引擎的反馈。
另外，注意，图2中所示的特定上下文情境、决策引擎和动作是示例性的，并且可以想到其它上下文情境、决策引擎和动作。例如，如上所述，上下文情境的值可以来自不同的传感器，诸如加速计、温度传感器、电子罗盘或GPS、光传感器、麦克风、摄像装置、射频识别（RFID）标签读数（使用例如近场通信）等以及网络可用性和链路质量。上下文情境还可以来自各种应用和/或来自移动装置110的操作系统，例如，操作系统可提供用于时间上下文情境的装置时钟。例如，移动装置110可以包括用于跟踪何时启动不同应用的操作系统，并且特定应用的启动可以用作上下文情境。具体地，一些应用可以是“触发”应用，“触发”应用用于例如在用户具有以特定序列请求应用的倾向时预先启动其它应用。用户行为（诸如登录到给定应用中、击键序列等）也可以用作上下文情境。
注意，给定上下文情境提供的上下文值可以是原始数据或者可以被提供到更高层级的决策引擎。例如，原始GPS数据可以由位置上下文情境转换成语义上更丰富的逻辑位置，例如，家、办公室、朋友家等。类似地，原始时钟数据可以由时间上下文情境转换成早晨、下午、晚上、夜间等。
决策引擎的适当决策算法的具体示例可以包括贝叶斯（例如，朴素贝叶斯）分类器、决策树（例如，快速决策树）、支持向量机（SVM）、隐式马尔科夫模型（HMM）、高斯混合模型（GMM）等。考虑将当前时刻和逻辑位置用作朴素贝叶斯决策引擎的上下文情境的简单情形。每当决策引擎观察到应用运行时，决策引擎都可以针对进行观察时的时刻而递增应用计数器c_x。决策引擎还可以递增表示进行观察的逻辑位置的另一计数器c_y。决策引擎还可以递增表示该应用已运行的总次数的、用于该应用的计数器Prior。当决策引擎决定了接下来要运行的应用时，决策引擎可以获得表示当前时刻的值c_x’和表示当前逻辑位置的值c_y’。然后，决策引擎可以为每个应用分配值c_x’＊c_y’*Prior，并且运行具有最高值的应用。
反馈如下进行：在进行预测之后，当用户实际启动应用时，决策引擎可以观察启动了哪个应用。然后，例如使用变量c_x、c_y和Prior来对于以上每个过程记录该信息。因此，如果用户先前已倾向于在同一时刻和/或在同一位置运行特定应用，则这将倾向于增加所分配的值，并且使得决策引擎在下次用户处于该位置和/或处于同一时刻时将更可能运行该应用。
在一个具体实施方式中，由于快速决策树具有相对低的运行期间开销（CPU和存储器利用）并且不需要离线训练，因此使用快速决策树。另外，由于这些决策树的加时间窗的实施方式易于适于用户行为的改变，因此，也可以使用这些实施方式。可以在Domingos等人所著的“Mining High‑Speed Data Streams”（KDD’00,Proceedings of the sixth ACM SIGKDD international conference on Knowledge discovery and data mining(pp.71‑80),2000,波士顿，MA:ACM Press）中找到关于快速决策树的更多细节。
一般来说，上下文情境和动作反馈的先前值可以被用于更新决策引擎。进而，随着决策引擎基于反馈进行学习，这可以使得决策引擎采取更适当的动作。在一些实现方式中，上下文值和动作反馈被“加窗”以使较旧的值被忽视（discount）。例如，加窗的贝叶斯算法或决策树可以仅使用上下文情境和反馈的相对近的（例如，过去的周、月、45天等）数据来训练决策引擎。这可以帮助决策引擎例如响应于用户行为的突然改变而更快速地学习。
在决策树的具体示例中，决策引擎可以迭代地将上下文值分割为映射至特定动作的值或值范围。决策树中的每个叶节点可以表示单个动作，并且上下文值被表示为用于分割的属性。随着时间，叶节点（动作）可以由测试节点取代，然后测试节点可以被分裂，以利用决策树学习新的规则。
另外，注意，所公开的架构允许各种动作与上下文情境之间的独立性。在某种意义上，动作和上下文情境“可插入”到图2中所示的架构中。换言之，可以添加新的上下文情境，因此决策引擎可以使用新的上下文情境来学习是否执行移动装置上已启用的某些动作。
例如，可以添加用于监视在移动装置的位置处的环境光的环境光传感器作为上下文情境。如果环境光趋于与某些装置动作相关，则特定决策引擎可以学习可响应于环境光的特定值而发起一个或多个现有动作。换言之，决策引擎可以学习基于新的上下文情境是否执行现有装置动作的新规则。
以下示例示出了上下文情境与动作之间的独立性的一个益处，其示出了上下文管理器210启用新上下文情境如何可以提供增强的用户满意度。考虑上面提到的在与其家庭成员Bob交谈之后不久常常打开社交联网应用的用户。该用户也可能习惯于每天早晨在从通常持续一个小时的晨跑返回时立即打开社交联网应用。如果只有电话呼叫上下文情境被启用而所有其它上下文情境都没有被启用，则应用启动决策引擎可学习在与Bob交谈之后在移动装置上预先启动社交联网app。然而，由于不存在时间敏感的上下文情境（诸如时间上下文情境或环境光上下文情境），因此决策引擎无法访问用于表示用户在早晨打开社交联网应用的倾向的上下文值。
由于在该示例中决策引擎没有适当的上下文情境来学习用户的习惯，因此决策引擎可能无法学习在用户从晨跑返回之前为用户预先启动社交联网应用。通过启用新的时间敏感的上下文情境（诸如当前装置时间或环境光传感器（例如，针对携带其装置跑步的用户）），现有的应用启动决策引擎可以学习在早晨的适当时间在移动装置上预先启动社交联网应用。正反馈可以增强该动作，例如，当用户实际在每个早晨请求执行社交联网应用时接收正反馈。
注意，环境光上下文情境和时间上下文情境不是严格对准的，例如，他们的关系在切换到夏令时或者从夏令时切换之后突然改变，或者在日出随着季节改变时随时间改变。在一些情况下，取决于用户的习惯，决策引擎可以学习使用一个或其它上下文情境。因此，决策引擎可学习使用时间上下文情境来为习惯在同一时间跑步而不管日出时间的用户预先启动社交联网应用。相反，决策引擎可学习使用环境光上下文情境来为习惯在日出时跑步而不管时钟时间的用户预先启动社交联网应用。
作为上下文情境/动作独立性可以如何有益的另一示例，考虑以下启用新动作以与现有决策引擎和现有上下文情境一起工作的示例。假设如下用户：该用户仅启用一个动作（预先启动社交联网应用），并且具有如上所述的用于装置时间和/或环境光的已启用的上下文情境。早晨的时间改变或环境光改变可以用作由决策引擎用于预先启动社交联网应用的上下文值。然而，用户还可能易于在每天晚上调低铃声音量，而在早晨在其醒来时忘记将铃声音量往回调高。通过启用调整铃声音量动作232，铃声音量决策引擎222可以学习在早晨的特定时间或在环境光在早晨增加时提高铃声音量。在该情况下，当（1）用户接听电话呼叫时或者（2）在调整之后没有减小铃声音量时，来自提高铃声音量的反馈可以被视为正的。另外，注意，铃声音量决策引擎可以学习在晚上的特定时间和/或当环境光减少时调低铃声音量。
在先前的示例中，结合环境光上下文情境来使用时间上下文情境可能是有益的。用户可能具有在白天期间将移动装置放在其口袋中的倾向。在该情况下，由于用户的口袋在白天是暗的，因此仅缺乏环境光可能不是减小音量的适当指示。通过还使用时间上下文情境，铃声音量决策引擎可以学习例如在（1）环境光相对低并且（2）当前时间相对晚（例如，8pm）时减小铃声音量的规则。
示例GUI
图3A和图3B分别示出了示例性图形用户界面（“GUI”）300和350。GUI 300可以允许用户选择性地启用/禁用一个或多个上下文情境，并且GUI 350可以允许用户选择性地启用/禁用一个或多个动作。例如，GUI300和/或350可以呈现在移动装置上，以允许用户选择在移动装置上启用哪些上下文情境和/或动作。一般来说，通过启用新的上下文情境，用户可以允许决策引擎在决定是否执行现有动作时使用由新的上下文情境提供的上下文值。类似地，通过启用新的动作，用户可以允许决策引擎基于由现有上下文情境提供的上下文值来确定是否执行新的动作。
关于图3A，用户可以通过从启用栏301选择相应的块来使用GUI 300启用各个上下文情境。当用户启用给定上下文情境时，相应块以“x”示出，否则被示出为空。因此，图3A示出了如下配置：用户已启用时间211和位置212，同时禁用电话日志213、环境噪声214、环境光215和应用使用216。
关于图3B，用户可以通过从启用栏351选择相应块而使用GUI350启用各个动作。当用户启用给定动作时，相应块以“x”示出，否则被示出为空。图3B示出了附加的复杂情况，由此用户可以单独地激活特定动作的子动作。这里，用户已整体启用了预先启动应用动作231，但是已特别禁用了电子邮件应用的预先启动，在图3B中以与预先启动电子邮件应用352对应的空块示出。因此，图3B示出了用户已启用了应用的预先启动和铃声的调整的配置。然而，用户已特别禁止预先启动应用决策引擎预先启动电子邮件应用，而非启用所有要预先启动的应用。更一般地，对于实现多个子动作的决策引擎，用户可以如上所述以逐个子动作为基础来启用/禁用具体的子动作。
示例决策规则
图4A、图4B和图4C示出了规则表400，规则表400是用于示出各种决策规则可以如何随时间改变或者被添加的示例性数据结构。在该示例中，规则表400示出了在数个决策引擎可在移动装置上随时间演进的情况下对这些决策引擎的组合规则。如以下更详细地讨论的，规则表400示出了在启用附加的上下文情境和动作时可以由app启动决策引擎221和铃声音量决策引擎222学习的决策规则。然而，注意，该规则表400仅出于示例性目的来示出启用上下文情境和动作可以如何导致新的或经更新的决策规则，并且不一定反映具体的决策引擎如何表示决策规则。更确切地说，各个决策引擎可以使用本文中提供的具体学习算法来表示决策规则，并且因此决策规则不一定需要在单独的表中被跟踪。例如，决策树分类器可以使用可随时间改变的树结构来表示决策规则，而朴素贝叶斯分类器可以使用可随时间改变的概率值来表示决策规则。
图4A示出了第一时间（例如，当用户启用了两个动作时）的规则表400，这两个动作即是如以上所指出的可以是预先启动应用动作的子动作的调整铃声音量和预先启动社交联网应用。如上所述，用户可使用诸如GUI 350的GUI来启用这些动作。此外，用户已启用了两个上下文情境，即分别为时间上下文情境211和电话日志上下文情境213。随着时间，铃声音量决策引擎可以学习在每天早晨8:00AM增大铃声音量。在图4A中，这被示出为规则401，规则401将调整铃声音量动作映射至8:00AM的上下文值。类似地，app启动决策引擎可以学习每当电话日志上下文情境表示用户刚刚与Bob进行了电话交谈的时候就预先启动社交联网应用。在图4A中，这被示出为规则402，规则402将“Bob”的电话日志上下文值映射至预先启动社交联网应用的动作。
图4B示出了第二时间（例如，在用户已启用了附加动作以预先启动电子邮件应用之后）的规则表400。如上所述，用户可使用诸如GUI 350的GUI来这么做。通过启用新的动作，应用启动决策引擎221可以随着时间学习用户倾向于在9:00AM之后不久在早晨启动其电子邮件应用。因此，预先启动应用决策引擎可以学习新规则403，新规则403将预先启动电子邮件应用动作映射至9:00AM的上下文值。
图4C示出了第三时间（例如，在用户启用了用于测量环境噪声的附加上下文情境之后）的规则表400。例如，环境噪声可由用户的移动装置上的麦克风来测量。由于用户已启用了新的上下文情境，因此调整铃声音量决策引擎可将规则401改进为取决于时间上下文情境和环境噪声上下文情境两者。具体地，在图4C中示出了规则401，以表示仅在环境噪声大于50dB的情况下在8:00AM之后调整铃声音量。如上所述，一些实施方式可以连续地改进要将铃声调整至的具体音量、在调整铃声音量之前存在多少环境噪声、针对环境噪声可以调整铃声音量的具体时间等。
为了在一定背景下给出以上示例，对图4C中所示的规则401的改进可反映如下使用模式：其中，用户在决策引擎自动增大了铃声音量时一般保持铃声音量为高，但是在环境噪声相对低时倾向于将铃声音量往回调低。因此，在环境噪声相对低的情形下，用户向决策引擎提供不适合自动增大铃声音量的隐式负反馈。
作为推动以上讨论的另外的视角，用户可能通常不晚于8:00AM在相对嘈杂的办公室中工作，但是在其休息日，在其家中背景噪声可能小得多。从用户的视角来看，可能甚至表现为移动装置已学习在用户在办公室中的日子增大铃声音量。然而，用户可能稍后发现如果其在8:00AM之后处于除工作之外的相对嘈杂的位置（例如，繁忙的餐馆），则移动装置也增大铃声音量。
然而，如上所述，位置也可以用作上下文情境。在以上提供的示例中，位置也可以是适当的上下文情境，铃声音量决策引擎可以根据该适当的上下文情境，例如通过学习当用户在其办公室时增大铃声音量以及当用户在家时调低铃声音量来学习与规则401类似的规则。
第一方法示例
图5示出了可以用于实现如以上所讨论的基于上下文的动作的示例性方法500。在一些实现方式中，方法500可以由移动装置110的基于上下文的动作模块111来执行。然而，如以下更多地讨论的，与方法500相关联的某些处理也可以被卸载至一个或多个其它装置，例如，一个或多个服务器。
在块501，启用一个或多个上下文情境。例如，上下文管理器210可以设置有一个或多个上下文情境，这一个或多个上下文情境是由移动装置110的制造者预先安装并启用的。在其它实施方式中，可以稍后例如通过经由软件或固件更新等安装附加的上下文情境来添加上下文情境。在另外的实施方式中，基于上下文的动作模块111被设置为可以由用户安装的后续市场软件（aftermarket software）。在另外的实施方式中，上下文管理器210可以允许用户或软件/固件更新以逐上下文情境为基础来安装各个上下文情境。此外，如上所述，一些实施方式允许用户例如使用GUI 300在其认为适当时打开和关闭（启用/禁用）各个上下文情境。
接下来，在块502，启用一个或多个动作。如以上关于上下文情境所讨论的，可以在制造时启用动作、将动作设置为软件/固件更新或安装的一部分、或者以逐动作为基础来单独地安装动作。类似地，在一些实施方式中，用户可以例如使用GUI 350按照其选择打开和关闭（启用/禁用）各个动作。
接下来，在块503，获得针对每个上下文情境的一个或多个上下文值。例如，可以从一个或多个传感器获得反映环境光或声音的值，可以获得当前装置时间，可以访问电话日志，可以通过与装置的操作系统通信来监视近来的应用行为，等等。
接下来，在块504，基于上下文情境的值进行决策。例如，一个或多个决策引擎可以实现上述决策算法，以将上下文情境的值映射至选择一个或多个动作。
接下来，在块505，执行所选择的一个或多个动作。例如，可以调高或调低铃声音量，可以预先启动一个或多个应用，等等。
接下来，在块506，使用动作反馈来更新决策引擎的决策规则。例如，如果动作包括启动应用，则当用户在启动之后的预定时间量内请求使用该应用时，反馈可以是正的，否则反馈则可以是负的。在调整铃声音量的情况下，当用户在预定时段内没有逆转该动作、或者在这样的时段内接听了一个或多个电话呼叫而没有调整铃声音量时，反馈可以视为正的。如果用户通过将铃声音量往回调低/调高来逆转该动作，则这可以视为负反馈。一般地，正反馈倾向于增强各个动作，以使得决策引擎将在上下文情境具有与获得正反馈时相同或相似的值时继续采取该动作。类似地，负反馈训练决策引擎在上下文情境具有与获得负反馈时相同或相似的值时不采取该动作。
还应注意，可以如图5中从块506反馈回到块503中的箭头所示那样，迭代地执行方法500以连续改进决策引擎。一般地，可以基于更近期的上下文值以及执行各种动作的更近期的情况来随时间迭代地执行块503至506。当启用新的上下文情境和/或新的动作时，块501和502可以分别用作方法500的入口点。另外，由于随时间来改进决策引擎，因此在一些情况下可能不采取特定动作，而在上下文值相同的后续情况下可能采取该特定动作。这是当决策引擎已经随着时间学习了针对该特定上下文值采取该动作时的情况。例如，在第一情况下，铃声音量决策引擎可能没有学习规则401，并且因此可能在8:00AM不调整铃声音量。在随后的第二情况下，铃声音量决策引擎可在学习了规则401之后在8:00AM调整铃声音量。类似地，决策引擎可以继续被改进，并且可最终学习例如当用户行为改变时等针对特定上下文值不采取特定动作。
第二方法示例
图6示出了示例性方法600，示例性方法600可以用于实现预先启动应用的基于上下文的动作。从概念上，方法600可以视为方法500的块505的具体示例。在一些实施方式中，可以由移动装置110的预先启动应用动作231来执行方法600。
在块601，识别用于预先启动的应用。例如，可以由应用启动决策引擎221来识别应用。在上述一个示例中，在用户刚刚完成了与其家庭成员Bob的呼叫的情况下，做出该决策以预先启动社交联网应用。注意，该示例描述了如何在移动装置的用户提供了请求执行社交联网应用的输入之前采取该动作。换言之，由于决策引擎预期用户可能在电话呼叫之后相对不久就请求该应用，因此做出该决策。
在一些实施方式中，决策引擎还可以在块601为应用设置一个或多个配置参数。例如，配置参数可以用于取决于用户正发送电子邮件的人而设置不同的电子邮件签名，例如，对于一些电子邮件为“Bob”而对于其它电子邮件为“Bobby”。作为另一示例，当用户在存在Wi‑fi的地理位置（例如，家中）时社交联网应用可以被配置用于相对高带宽的特征，并且当用户在仅蜂窝服务可用的地理位置（例如，在其汽车中）时可以被配置用于相对低带宽的特征。
接下来，在块602，可以撤回（evict）一个或多个其它应用。例如，如果正预先启动的应用需要特定量的处理器和/或存储器资源，则可以关闭一个或多个其它应用，以为正预先启动的应用释放资源。具体地，可以通过关闭其它应用来释放诸如线程或处理的处理器资源，可以释放存储器，和/或可以将其它应用的代码或数据从存储器转移到存储装置。可以使用各种方法来确定要撤回的应用，例如，当前正运行的最近最少使用的应用、随机选择的应用、预测方法和/或基于成本的方法等。撤回的应用可以采用“正常”关闭行为，诸如被移动到存储装置、解除分配存储器和/或处理器资源等。
在一些实施方式中，也可以由决策引擎响应于一个或多个上下文情境的值来选择撤回的应用，例如，决策引擎不仅可以学习要预先启动的应用，而且还可以基于上下文情境的值来学习要撤回的应用。在这样的实施方式中，应用启动决策引擎也可以被配置成对表示随时间已撤回哪些应用的上下文值进行跟踪。因此，应用启动决策引擎可以基于来自撤回各种应用的先前情况的反馈，学习在给定其它上下文情境的值的情况下适合于撤回哪些应用。
接下来，可以执行块603至605。一般地，块603至605与预先启动应用有关，以将应用置于预先启动状态。
在块603，可以将资源分配给正预先启动的应用。例如，应用可以从移动装置的操作系统请求存储器资源，并且可以将存储器资源分配给应用。类似地，作为块603的一部分，可以将处理器资源（例如，一个或多个线程或处理）分配给应用。
接下来，在块604，可以将应用代码和/或数据加载到存储器中。例如，可以从存储装置（例如，诸如FLASH或硬盘驱动器的非易失性存储器）取回包括可执行二进制代码的一个或多个应用模块，并将其加载到相对较快的易失性存储器（例如，RAM）中。应用所使用的各种数据（例如，图片、视频或其它类型的数据文件）也可从存储装置加载到存储器中。
接下来，在块605，所加载的应用代码可以在移动装置的一个或多个处理器上执行。例如，应用代码可以执行各种初始化步骤，诸如从网络下载数据（图片，视频等）、将用户登录到网络服务中等。对于游戏应用，块605可以包括下载一个或多个得分、连接到一个或多个对等实体或服务器（例如，多用户游戏）等。
接下来，在块606，可以接收动作反馈。在一些实施方式中，应用可以进行明确调用，以为决策引擎提供反馈，例如表示正反馈或负反馈的二进制（布尔）值或者更加细化的值（等级为1至10的整数等）。在其它实施方式中，没有使用来自应用的明确反馈。相反，决策引擎可以监视在预先启动之后的特定时间量内是否请求了预先启动的应用。例如，决策引擎可以将在预先启动的预定时间量（例如，两分钟）内使用应用视为正反馈，否则将反馈视为负反馈。
注意，可在不修改正预先启动的应用的代码的情况下来执行方法600。例如，应用启动决策引擎的输出可以被馈送到移动装置的操作系统的调度器（scheduler）。调度器可以简单地执行预先启动的应用，并且允许应用运行预定时间量（例如，15秒）。在该时间期间，应用代码可以简单地正常执行，以执行任意初始化步骤，不然这些初始化步骤原本将在用户明确地启动应用之后才执行。在预定时间量期满之后，操作系统调度器可以阻止进一步执行应用，直到用户明确地请求执行该应用为止。例如，操作系统可以允许应用（包括取得的数据）继续驻留在存储器中而不被撤回，但是停止在处理器上调度应用直到实际接收到用户请求为止。在很多情况下，该方法不要求对应用代码进行改变，并且可以通过混入决策引擎的决策来实现，而无需对应用或操作系统调度器进行进一步修改。
在其它实施方式中，应用代码可以提供用于预先启动目的的明确调用或“同步动作”。在这样的实现方式中，应用设计者可以决定适合于应用在被预先启动时执行的功能。在这样的实现方式中，由于取代“正常”起动过程而调用了同步动作，因此应用“知道”应用正被预先启动。该实施方式允许应用设计者将适合于预先启动目的的某些初始化功能分离到同步动作中。因此，通过提供同步动作，应用设计者可以控制在预先启动阶段期间执行什么应用功能以及控制什么应用功能被推迟直到用户明确请求执行应用。
附加示例
以上讨论的上下文情境、动作和决策引擎是示例性的并且被提供用于示出可以如何实现所公开的构思的具体示例。然而，可以想到同样与所公开的实施一致的多种附加使用情况。一般来说，可以通过启用不同类型的上下文情境、动作和决策引擎来提供附加功能。
例如，可以提供与具体的用户行为、情感、活动等有关的上下文情境。在一些实施方式中，用户可以通过表示其是否开心、生气、伤心等来明确地表示其情绪。在其它情况下，可例如根据声音的语调、在电子邮件通信中使用的词等来推断用户的情绪。（关于情绪研究的附加细节可以在http://affect.media.mit.edu/publications.php中找到）。例如如果这样的情绪上下文情境表示用户伤心，则由于用户在其伤心时不进行电话呼叫，因此铃声音量决策引擎可学习关掉电话响铃。作为另一示例，由于用户倾向于在其情绪相对好时参与社交联网活动，因此应用启动决策引擎可以学习例如在用户表示其开心时启动社交联网应用。
如上所述，用户的位置也可以用作上下文情境。在一些实现方式中，可以定义与物理位置（例如，GPS坐标）相关联的不同的逻辑位置。通过定义逻辑位置，即使用户换工作、搬到新家等，所学习的功能也保持一致。例如，如果用户换工作并且开始往返于新的物理工作场所，则用户可以将新的物理位置定义为“工作”的逻辑位置。因此，先前关于用户的旧工作场所学习的任何规则都可以保持不变，这是由于这些规则与“工作”的逻辑位置相关联，而非与不同工作场所的具体物理位置相关联。
作为逻辑位置的另一示例，“在餐/饮设施处”的通用概念可以每当用户的GPS坐标表示其在这样的设施处的时候用作逻辑位置。因此，如果用户习惯于每当其在任意类型的餐馆、小餐馆、咖啡厅等的时候都频繁地发送文本信息，则应用启动决策引擎可以学习打开文本消息发送应用。因此，“在餐/饮设施处”的逻辑位置可以与多个位置相关联，并且实际上甚至与用户先前没有携带移动装置去过的位置相关联。因此，移动装置可以基于用户所处的地点的类型而采取适当的动作（诸如，启动消息发送应用），甚至在用户先前未在该特定地点采取过该动作时也是如此。更确切地说，决策引擎可以基于用户在类似地点的先前动作而推断该动作。
上下文情境的另一示例可以与不同类型的移动有关。例如，当用户在行走时相对于在驾驶时，用户可能具有不同的习惯。作为具体示例，用户在驾驶时可能倾向于使用语音识别软件来准备电子邮件和/或文本消息，但是在行走时可能倾向于使用键盘来准备电子邮件和/或文本消息。一些实施方式可基于用户最近的移动（例如，相对速度等）来确定用户是在行走还是驾驶。因此，移动上下文情境可以提供诸如“行走”、“驾驶”、“骑自行车”、“静止”等的上下文值。在另外的实施方式中，移动上下文情境可以使用加速计来确定用户是在跳舞还是做其它原地活动。
作为另一示例，上下文情境可以与移动装置附近的个体有关。例如，如果用户和特定朋友、特定家庭成员等在一起，则用户可能倾向于以不同方式来使用其移动装置。在一些实施方式中，用户可能需要明确地识别其与谁在一起，但是在其它实施方式中，这可以由移动装置自动地来确定，例如，通过经由蓝牙识别其他个体的移动装置等来进行。考虑如下用户：该用户可能在与其孩子在一起时倾向于不进行任何电话呼叫，但是可能在与特定朋友在一起时总是接听其电话。在这样的实现方式中，铃声音量决策引擎可以学习在用户与其孩子在一起时调低铃声音量，但是在用户与该特定朋友在一起时不这样做。
同样如上所述，上下文情境可以反映移动装置上的一个或多个应用所提供的信息。例如，电子邮件应用可提供这样的上下文值，该上下文值表示用户已激活了“不在办公室”消息，或者表示用户具有表明用户当前正进行商务会议的约会日程表。作为又一示例，上下文情境可表示用户近来向特定人发送了电子邮件、在电子邮件的主题和/或正文中是否有特定词等。例如，如果用户接收到具有串“http://.....”的电子邮件，则决策引擎可例如在基于先前情况学习了该动作之后启动浏览器应用，其中在该先前情况下，用户点击了电子邮件中的超链接从而使得启动浏览器应用。
在一些实现方式中，可以由移动装置将上下文情境记录到时间“组块（chunk）”，例如，按小时、逐分钟、15分钟的块等，并且上下文值可以在上下文情境日志中处于针对每个时间组块的条目中。各个决策引擎可以更新针对每个时间组块的算法。在一些实施方式中，决策引擎更新的相对频率和/或相应时间组块的大小可以是用户可配置的。
上述各种动作（预先启动应用、调整铃声音量、调整屏幕亮度等）也是示例性的，并且还可以想到其它类型的动作。在一些实施方式中，移动装置可以自动地开机或关机、进入飞行模式等。在另外的实施方式中，各个决策引擎可以以探索形式学习装置动作。例如，决策引擎可以尝试新的动作，诸如为用户照亮电子罗盘，甚至在用户以前从未照亮过罗盘时也是如此。在这样的实施方式中，这可以帮助用户学习该用户甚至可能不知道的、其移动装置的某些特征。
作为另一示例，一些实施方式可以作为特定动作而遏制（throttle）后台服务。这可以具有为用户可能希望执行的其它应用释放计算资源（处理器周期和/或存储器）的效果。后台遏制决策引擎可学习在各种上下文值表示用户可能正使用资源密集应用时（例如，当用户在工作、在一天的特定时刻、在接收到具有特定类型的文件扩展的电子邮件之后等）遏制后台服务。
系统示例
图7示出了系统700的示例。示例系统700包括分别被示出为笔记本客户端装置702（1）和移动客户端装置702（2）的一个或多个客户端装置702。在该情况下，客户端装置702可以各自包括处理器704、存储器706、存储装置708、基于上下文的动作模块111、上下文情境日志710以及操作系统712。（后缀“（1）”用于表示这些模块出现在客户端装置702（1）上，并且后缀“（2）”用于表示出现在客户端装置702（2）上）。基于上下文的动作模块111可以一般被配置成执行以上关于图1至图6讨论的处理。上下文情境日志710可以包括针对启用的上下文情境随时间存储的各种上下文值、以及对在用户或决策引擎采取动作时所采取的特定动作的指示。
系统700还可以包括一个或多个服务器714。服务器714可以是也包括处理器704（3）、存储器706（3）和存储装置708（3）的计算装置。注意，后缀（3）用于表示处理器或存储装置出现在服务器714上。服务器714也可以包括基于上下文的动作模块111（3），并且也可以由服务器714上的基于上下文的动作模块111（3）来执行以上关于图1至图6所讨论的某些处理。在一个具体实施方式中，由服务器714上的基于上下文的动作模块111（3）来实现一个或多个决策引擎，而在各个客户端装置上采取动作本身。从一个视角来看，该实施方式可以将上下文管理器210和动作管理器230分布在客户端装置上而将映射管理器220分布在服务器上。
客户端装置702和服务器714可以通过一个或多个网络716来通信，网络716例如但不限于因特网。基于上下文的动作模块111可以被实现为软件、硬件和/或固件。处理器704可以执行计算机可读指令形式的数据以提供功能。数据和/或计算机可读指令可以存储在存储器706和/或存储装置708上。存储器和存储装置可以包括易失性或非易失性存储器、硬盘驱动器和/或光学存储装置（例如，CD、DVD等）等中的任意一个或多个。
在一些实施方式中，存储器706是具有相对低延迟的易失性存储器，而存储装置708是用于指令（代码）和数据的长期存储的非易失性存储器。在这样的实施方式中，存储装置708用于保留在计算装置处于供电循环时代码和/或数据的改变，并且这些改变从易失性存储器丢失。在这样的实施方式中，如以上关于方法600的块604所讨论的，预先启动应用可以包括从存储装置708取回一些或全部应用代码和/或数据以及将取回的应用代码或数据加载到存储器706中。通过在用户请求执行特定应用之前这样做，与需要在用户请求执行应用之后从存储装置取回应用代码和/或数据的情况相比，应用可以对用户呈现出更好的响应性。在一些情况下，对于读取和/或写入，存储器706可以比存储装置708显著地（例如，一个或多个量级）“更快”或者具有更低延迟。
另外，注意，基于上下文的动作模块111可以与操作系统712交互或者是操作系统712的一部分。在一些实施方式中，操作系统712提供用于调度各个应用以在处理器704上执行的调度器功能。在一些实施方式中，操作系统调度器例如在方法600的块603将诸如线程和/或处理的处理器资源分配给所调度的应用。
客户端装置702和服务器714还可以被配置成接收来自外部存储装置718的计算机可读指令的形式的数据和/或生成计算机可读指令的形式的数据。外部存储装置718的示例可以包括光学存储装置（例如，CD、DVD等）、硬盘驱动器和快闪存储装置（例如，记忆棒或存储卡）等。在一些情况下，本文中讨论的模块可以在装配期间或者至少在移交给用户之前安装在客户端装置或服务器上。在其它情形中，本文中讨论的模块可以在移交之后由用户安装，诸如可通过网络716和/或从外部存储装置718下载。本文中讨论的模块可以被表现作为独立应用、应用部分和/或计算装置的操作系统的部分。
本文中讨论的模块可以共同地实现以上关于图1至图6描述的功能。具体地，基于上下文的动作模块111可以被配置成执行方法500和/或600。值得注意的是，在一些情况下，客户端装置或服务器可以包括诸如在分布式环境中的多个计算装置或机器。在这样的配置中，方法500和/或600可以使用跨越多个计算装置或机器的分布式处理来实现。
如上所述，一些实施方式提供要在服务器714上执行的各种决策引擎。在这样的实施方式中，每个客户端装置可以分别保持本地上下文情境日志710（1）和710（2），该本地上下文情境日志710（1）和710（2）包括相应客户端装置上的各个上下文情境的上下文值以及在装置上采取的动作的历史。这些上下文情境日志可以被上传到服务器714，并且可以被组合作为上下文情境日志710（3）。
在这样的实施方式中，服务器上的决策引擎可以对多个用户的上下文情境日志执行学习。这在单个用户的上下文情境数据相对稀疏的情况下可能是特别有用的。在这样的实施方式中，单个决策引擎可以学习可适用于多个用户的规则。一个示例是上述的嵌入电子邮件的超链接示例，例如，可能多个不同的用户将在接收到电子邮件中某处具有串“http://.....”的电子邮件之后不久请求浏览器应用。更一般地，每个决策引擎可以被配置成挖掘在其他用户的其它装置上执行的动作和上下文情境日志。因此，决策引擎可以根据其他用户的上下文动作关系进行学习以改进用户的体验。在一些实施方式中，甚至可使用从其它用户的装置上的决策引擎获得的值来催化（seed）、初始化或者以其它方式修改决策引擎。然而，注意，替代地，本文中所述的所有处理（包括训练决策引擎）可以在单个客户端装置上本地执行，并且可以仅在特定于该客户端装置或用户的上下文情境日志上训练决策引擎。
本文中所使用的术语“计算机”、“客户端装置”、“服务器”和“计算装置”可以表示具有一定量的处理能力和/或存储能力的任意类型的装置。一般地，“移动装置”指代以适合于用户随身携带的形式因素实现的计算装置。处理能力可以由一个或多个处理器来提供，这一个或多个处理器可以执行计算机可读指令形式的数据以提供功能。
如上所述，计算机可读指令可以存储在存储装置和/或存储器装置上。存储装置和/或存储器装置可以在计算装置内部和/或外部。存储装置和/或存储器装置可以包括易失性或非易失性存储器、硬盘驱动器、快闪存储装置和/或光学存储装置（例如，CD、DVD等）等中的任意一个或多个。当在本文中使用时，术语“计算机可读介质”可以包括暂态和非暂态计算机可读指令。相比之下，术语“计算机可读存储介质”不包括暂态情况。计算机可读存储介质包括“计算机可读存储装置”。计算机可读存储装置的示例包括诸如RAM的易失性存储介质以及诸如硬盘驱动器、光盘和闪存等的非易失性存储介质。
计算装置的示例可以包括传统的计算装置，诸如个人计算机、蜂窝电话、智能电话、个人数字助理或者大量已形成的或仍待开发的类型的计算装置。此外，系统700的方面可以被表现在单个计算装置上或者分布于多个计算装置中。
结论
描述示例方法的顺序不旨在被解读为限制，并且可以以任何顺序组合任意数量的所描述的块或步骤，以实现这些方法或替选方法。此外，方法可以以适当的硬件、软件、固件或其组合来实现，以使得计算装置可以实现这些方法。在一种情况下，方法作为一组指令存储在一个或多个计算机可读存储介质上，以使得被一个或多个计算装置执行导致这一个或多个计算装置执行该方法。
尽管本文中讨论的技术、方法、装置、系统等是以特定于结构特征和/或方法逻辑动作的语言来描述的，但是应理解，所附权利要求中限定的主题不一定局限于所描述的具体特征或动作。相反，具体特征和动作被公开作为实现要求保护的方法、装置、系统等的示例性形式。
根据以上描述，作为示例而非限制，本公开提供了以下技术方案：
方案1．一种方法，包括：
从一个或多个上下文情境获得一个或多个上下文值；
使用包括一个或多个决策规则的决策引擎，基于所述一个或多个上下文值和所述一个或多个决策规则来决定是否对计算装置执行动作；
在所述决策引擎决定要执行所述动作的情况下，对所述计算装置执行所述动作；以及
使用与所述动作有关的反馈来更新所述决策引擎的所述决策规则。
方案2．根据方案1所述的方法，其中，从所述计算装置上的物理传感器获得单个上下文值。
方案3．根据方案1所述的方法，其中，单个上下文值反映所述计算装置的用户的活动或其它计算装置上的其他用户的活动。
方案4．根据方案3所述的方法，所述活动包括所述用户在所述计算装置上执行应用。
方案5．根据方案3所述的方法，所述活动包括所述用户使用所述计算装置与另一个体通信。
方案6．根据方案1所述的方法，其中，单个上下文值反映所述计算装置的当前时间或当前位置。
方案7．根据方案1所述的方法，还包括使用图形用户界面GUI启用所述动作，同时经由所述GUI保持至少一个其它动作被禁用。
方案8．根据方案1所述的方法，还包括使用图形用户界面GUI来启用单个上下文情境，同时经由所述GUI保持另一单个上下文情境被禁用。
方案9．一种方法，包括：
基于一个或多个上下文值识别要预先启动的应用；
预先启动所述应用以将所述应用置于预先启动状态中；以及
接收与所述预先启动有关的反馈。
方案10．根据方案9所述的方法，其中，所述反馈表示在预先启动所述应用之后的预定时间内用户是否请求执行所述应用。
方案11．根据方案9所述的方法，其中，所述预先启动包括：
将计算资源分配给所述应用；
将与所述应用相关联的至少一些应用代码从存储装置加载到存储器中；以及
执行所加载的应用代码。
方案12．根据方案11所述的方法，还包括：
从所述存储器撤回至少一个其它应用。
方案13．根据方案9所述的方法，还包括：
在预先启动所述应用之后接收用于执行所述应用的用户请求；
基于所述一个或多个上下文值调整所述应用的单个配置参数；以及
从所述预先启动状态执行所述应用，其中，所述预先启动状态反映调整后的单个配置参数。
方案14．一种系统，包括：
基于上下文的动作模块；以及
计算装置，被配置成执行所述基于上下文的动作模块，
其中，所述基于上下文的动作模块被配置成：
在第一情况下：
获得上下文情境的上下文值；
使用决策引擎来基于所述上下文值决定不对所述计算装置执行动作；以及
不对所述计算装置执行所述动作；
将与所述动作有关的反馈提供给所述决策引擎，其中，所述决策引擎被更新，以学习在所述上下文情境具有所述上下文值时执行所述动作；
在所述第一情况之后的第二情况下：
获得所述上下文情境的与在所述第一情况下获得的相同的上下文值；
使用更新后的决策引擎来基于所述相同的上下文值决定对所述计算装置执行所述动作；以及
对所述计算装置执行所述动作。
方案15．根据方案14所述的系统，其中，所述基于上下文的动作模块包括计算机可读指令，并且所述计算装置包括被配置成执行所述计算机可读指令的至少一个处理器。
方案16．根据方案14所述的系统，其中，所述基于上下文的动作模块跨越所述计算装置和服务器而分布，以使得由所述服务器来提供所述决策引擎并且在所述服务器上更新所述决策引擎。
方案17．根据方案14所述的系统，其中，所述决策引擎包括决策树。
方案18．根据方案17所述的系统，其中，所述决策树包括快速决策树。
方案19．根据方案14所述的系统，其中，所述决策引擎包括贝叶斯分类器。
方案20．根据方案19所述的系统，其中，所述贝叶斯分类器是朴素贝叶斯分类器。