CN102368256B

CN102368256B - 基于用户意图提供建议

Info

Publication number: CN102368256B
Application number: CN201110296643.1A
Authority: CN
Inventors: A.加夫里尔斯库
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2010-09-30
Filing date: 2011-09-30
Publication date: 2015-08-19
Anticipated expiration: 2031-09-30
Also published as: CN102368256A; US20120084248A1

Abstract

在这里公开用于例如根据移动设备的用户的意图实时提供按优先顺序排列的建议给用户的一种或多种技术和/或系统。用户惯例通过识别诸如用于旅行、数据消费、通信等的多个历史用户模式来识别。使用来自一个或多个传感器的实时上下文数据，识别用于用户的实时上下文，诸如用户当前正在干什么或他们周围正在发生什么。通过比较用户惯例与用于用户的实时上下文来确定用户的意图，并根据意图诸如在移动设备显示器上为用户按优先顺序排列建议。

Description

基于用户意图提供建议

背景技术

在计算环境中，预测用户的行为能够给商务添加实用性，并给用户提供好处。例如，当在线用户把包括搜索项的查询输入在线搜索引擎中时，搜索引擎时常将试图（例如，基于这些项和其它信息）预测用户正在搜索什么，并给用户提供相关的搜索结果以及相关的广告、宣传和/或商业优惠券。进一步，用户行为预测能够用于规划给用户的资源分配（例如，服务器和系统来适应交通）和/或信息供应（例如，根据规划的路线，在GPS系统上提供交通信息或即将来临的吸引力/商务）。

发明内容

提供这个发明内容部分来以简化形式介绍概念的选择，其中这些概念在下面的具体实施方式部分中进一步进行描述。这个发明内容部分不打算来标识所请求保护的主题的关键因素或基本特征，也不打算用于限制所请求保护的主题的范围。

试图预测用户的行为往往可能是有问题的，因为人可能是特别不可预测的。进一步，当利用预测来提供相关的结果（例如，信息、数据、建议的活动、任务等等）时，有可能不相关的结果可能不能良好地被接收，尤其是在向用户建议这些结果而没有针对它们的用户提示（例如，在用户的移动电话上接收宣传、广告或甚至建议的活动和任务）时。当前的和以前的系统和技术是有缺陷的，这是因为它们试图预料用户接下来将干什么或其预定成就可能是什么。这些系统和技术常常无法给用户提供相关的信息或建议，因为人类行为时常是不可预测的，并可能最终由于不相关信息的泛滥而使用户受挫。

因此，公开一种或多种技术和/或系统，其识别用户的规则模式(pattern)，并利用用户的规则模式来识别意图，以便把（例如，在移动设备上）呈现给用户的信息按优先顺序排列。虽然人类行为在任何特定时刻时常是不可预测的，但是对于具有高度预测性的某些活动（例如，旅行、电话使用、数据使用）能够导出人类模式。例如，在每小时的基础上，某个人的行踪的真正不确定性小于两个位置。这些高度可预测的模式能够用于识别意图并将对于用户的建议按优先顺序排列。

在用于基于移动设备的用户的意图实时给用户提供按优先顺序排列的建议的一个实施例中，用户的惯例(routine)通过识别多个历史用户模式来识别。进一步，用于用户的实时上下文使用来自一个或多个传感器的实时上下文数据来识别。通过比较惯例与实时上下文，确定用户的意图。此外，根据意图按优先顺序排列对于用户的建议（例如，建议的活动、任务和信息）。

为了实现上述的和相关的目标，以下的描述和附图阐述某些说明方面和实现方式。这些指示其中可以利用一个或多个方面的各种方式中的仅仅几种方式。从结合附图考虑的以下详细描述中，本公开内容的其它方面、优点和新颖的特征将变得显而易见。

附图说明

图1是用于基于移动设备的用户的意图实时向用户提供按优先顺序排列的建议的示例方法的流程图。

图2是说明其中可以实现在这里描述的一种或多种技术的示例实施例的流程图。

图3是其中可以实现在这里描述的一种或多种技术和/或系统的示例实施例的图解。

图4是用于基于移动设备的用户的意图实时向用户提供按优先顺序排列的建议的示例系统的组件组。

图5是说明其中可以实现在这里描述的一种或多种系统的示例实施例的组件组。

图6是包括被配置成体现在这里阐述的一个或多个规定（provision）的处理器可执行指令的示例计算机可读介质的图解。

图7说明其中可以实现在这里阐述的一个或多个规定的示例计算环境。

具体实施方式

现在参照附图来描述所请求保护的主题，其中相同的参考数字用于在全文指示相同的元素。在以下的描述中，为了解释目的，阐述许多具体的细节，以便提供所请求保护的主题的透彻理解。然而，以下可能是显而易见的：所请求保护的主题可以在没有这些具体细节的情况下被实践。在其他的实例中，结构和设备以框图形式被显示，以便有助于描述所请求保护的主题。

基于用户惯例和关于用户的实时信息，可以设计出利用预测的用户意图来向用户呈现按优先顺序排列的建议的方法。图1是用于基于移动设备的用户的意图向用户实时提供按优先顺序排列的建议的示例方法100的流程图。该示例方法100开始于102并牵涉在104通过识别多个历史用户模式来识别用户的惯例。

在一个实施例中，用户模式能够包括涉及用于用户的历史上下文数据的信息，例如，其识别用户先前已从事什么事情。在一个实施例中，用户的历史旅行模式可以通过与时间相关跟踪和记录用户的位置（例如，在特定时间上的地图坐标）、诸如通过使用移动设备（例如，智能电话）的全球定位系统（GPS）功能来识别。这样，在这个示例中，用户的驾驶路线、通勤（commuting）路线和其它旅行活动能够被识别为旅行模式（例如，从星期一到星期五坐火车上下班，星期二和星期四在下班之后开车去足球场，每个星期天驾车到母亲家、教堂、随后返回到母亲家和回家）。

在另一示例中，识别用户历史模式能够包括：识别用户的数据消费模式。数据消费模式能够包括例如与时间（例如，一天中的时间和时间的长短）相关的用户访问、下载和上传什么类型和数量的数据。在一个实施例中，数据消费模式能够包括牵涉用户的移动设备的数据。即，例如，当用户访问因特网、执行搜索、浏览网站以及下载数据到其移动设备和从其移动设备上传数据时，可以匿名地跟踪和记录该数据。进一步，例如，使用/访问数据的一天中的时间和时间的长短能够被跟踪并被记录。这样，在这个示例中，数据消费的模式可以通过用户在历史上是如何从其移动设备中访问/使用数据来识别。

作为说明性示例，每个工作日早晨用户可能步行到火车站，以便搭乘通勤者火车去上班。在途中，他们在当地咖啡店停留，并随后在火车站登上火车。在等待火车和乘坐火车的同时，用户使用其移动设备来查看昨晚比赛的体育比分、阅读某些早间新闻、查看其电子邮件和更新其社交网状态。在午饭之前，用户使用其移动设备来查看其社交网络、在线查找本地午餐特价，然后步行到当地咖啡馆去吃午餐，在那儿他们得到更多的电子邮件和股票市场的消息。在下班之后，用户步行到火车站，以便赶火车回家，并在他们的移动设备上预订晚餐和电影。在这个示例中，用户的历史工作日旅行模式能够通过GPA来跟踪，并利用对于不同位置的时间和持续时间来记录；以及数据消费模式、连同一天中的时候和持续时间一起能够被匿名跟踪和记录。

在示例方法100中的106，用于用户的实时上下文能够使用从一个或多个传感器收集的实时上下文数据来识别。移动设备通常包括多个传感器，这些传感器能够对于设备的用户生成上下文数据。例如，大多数智能电话包括GPS跟踪器、时钟、用于跟踪数据使用和通信（例如，电话呼叫）的组件；某些智能电话包括加速计、位置传感器和其它传感器。进一步，传感器能够包括收集、跟踪、和/或记录对于用户的相关上下文信息的任何组件、应用和/或系统，诸如提供在用户的位置处的当前天气状况的馈送系统（feed）和/或监视一个或多个用户条件的一个或多个健康监视器（例如，心率监视器、血压计等）等。在一个实施例中，传感器可以与各种各样的与用户相关联的组件相关联和/或位于这些组件中。例如，传感器能够位于用户的鞋子（例如，跑鞋，以监视所采用的步伐、步数等）、衣服和/或所使用的和/或否则与用户相关联的其它设备中。作为另一示例，可以具有位于用户的交通工具（例如，汽车、自行车等）中的一个或多个传感器，并且交通工具能够与用户相关联，这允许用户模式和/或数据或信息被获得和/或被导出。

上下文数据能够包括通知关于用户的实时信息的任何数据。即，例如，实时上下文数据与在数据生成的时间用户正在做和/或经历什么有关。例如，如利用用户的智能电话上的GPS所指示的用户的当前位置可能表明他们在火车站，而这又可能具有相关联的天气条件状态，在他们的电话中的时钟指示当前的时间8 AM以及周历是星期二，而且用户的数据组件指示：用户当前正在其智能电话上观看体育比分。在这个示例中，上下文数据能够被组合成用于用户的实时上下文。

在示例方法100中的108，用户的意图通过比较惯例与实时上下文来确定。在一个实施例中，实时上下文的上下文数据能够相对于惯例的历史用户模式进行匹配。例如，火车站的位置连同时间和日期一起可以匹配早晨通勤旅行模式。进一步，用户观看体育比分也能够指示早晨通勤数据消费模式。因此，在这个示例中，可以指示用户正通勤去上班、正准备登上火车以便通勤去上班的用户意图。进一步，例如，用户可能接下来希望观看当前新闻、阅读电子邮件和更新其社交网状态。

在110，基于所确定的意图，按优先顺序排列对于用户的建议。建议能够包括信息、应用、活动和用户在诸如移动设备之类的计算设备上能够观看或与之交互的其它数据。例如，通过从模式中获悉用户的惯例，用户的意图能够被预测，并且用户的潜在需要能够被预料。这样，在这个示例中，在用户实际上可能需要时（如果不是之前的话），适当的任务、行动和信息能够以按优先顺序排列的方式被提供。

作为说明性示例，惯例能够帮助识别何时用户购买食品杂货。在这个示例中，当上下文识别用户正在遵循这个正常惯例时，能够提前提供并按优先顺序排列（例如，利用至用户的位置）对于来自若干食品杂货商店的优惠券提供的建议。这样，用户能够提前计划去哪里购物，而不是在商店中的同时接收优惠券。

作为另一说明性例子，惯例能够帮助识别用户通常在工作日何时醒来。在这个示例中，电子邮件和社交网业务的建议概要可以基于用户的数据消费模式来提供，由与该用户具有更紧密关系的人按优先顺序进行排列。新闻和事件的概要能够提供给用户，基于用户的数据消费模式按优先顺序进行排列，并与上下文数据进行匹配。例如，如果交通是特别繁忙的或天气是恶劣的(例如，导致更长的通勤时间)，则这个新闻能够基于意图和上下文连同体育比分和认为适当的其它信息一起按优先顺序进行排列。类似地，例如，如果是工作日并且预料更长的通勤时间，则用户的设备能够发出警报声来更早地唤醒用户。

在按优先顺序排列对于用户的建议之后，示例方法100在112结束。

图2是说明其中可以实现在这里描述的一种或多种技术的示例实施例200的流程图。在202，传感器250能够提供用来收集用户模式的信息。在一个实施例中，用户模式能够包括用户旅行模式。如上所述，用户旅行模式能够包括用户旅行的位置以及用户出现在这些位置上的时间（例如，何时和多长时间）。在一个实施例中，例如，这些位置和时间能够以区分特定旅行模式——诸如早晨通勤，晚上通勤，到商店、朋友、父母的旅程，常规事件或恰好待在家中、学校或工作——的方式进行组织。

在一个实施例中，用户模式能够包括用户数据消费模式。如上所述，用户数据消费模式能够包括由用户诸如在他们的移动设备上观看、访问、下载和/或上传的数据。在这个实施例中，用户的网站访问、搜索、社交联网等能够与一天中的时间和位置相关进行监视，以便利用一天中的时间、位置和/或源来导出有关用户如何消费数据的模式。进一步，用户数据消费模式能够包括用户访问/观看数据的时间（例如，何时、多长时间、多频繁）。数据的类型和相关联的时间能够以区分特定的数据消费模式例如醒来、通勤、在工作、午饭时间、晚上、周末等的方式进行组织。

在一个实施例中，用户模式能够包括用户通信模式。例如，用户可以使用他们的移动设备发出与接收电话呼叫、发送与接收电子邮件和文本、和/或进行在线聊天。在这个实施例中，例如，与时间和位置相关的电话使用、消息传送和社交网络使用能够导出关于用户与谁通信以及他们如何通信的模式。与通信的类型相关联的信息、连同通信的相关联的时间、持续时间和/或规则性一起能够被匿名收集。在一个实施例中，通信类型和时间能够以便于区分特定的通信模式例如类似于上述的数据消费模式的方式进行组织。

在一个实施例中，用户模式能够包括用户活动模式。用户活动模式可以包括通过监视例如用户的日程表、电话呼叫活动、多媒体使用和/或信用卡活动来识别的活动，以导出与一天中的时间和/或位置相关联的、用户所从事的活动的模式。例如，用户可能收听音乐、下载音乐或文件、去参加会议、在线购物或在商店购物、在线或通过通信与人交互、或关闭他们的通信设备（例如，诸如在睡觉时，免打扰）。在一个实施例中，用户活动类型和时间能够以便于区分特定的活动模式的方式进行组织。进一步，用户可以输入关于特定活动（例如，在旅行时或在某一位置上）的信息，并且例如，可以从传感器250中收集时间和/或位置。

在一个实施例中，信用卡和/或其它付费相关的活动能够与用户相关（例如，相对于购物而言）。作为说明性示例，用户可以使用电话进行付费来参与零售机构类型的购物活动。例如，用户可以被设置来诸如通过利用在电话上运行的支付应用、使用其移动电话来付款，其中例如该电话使用特定的RF信号组件来匹配芯片嵌入的信用卡。类似地，该电话能够与特定的账户相关联，并且在该电话上的应用允许在零售位置从那个账户中提取钱款来支付。在另一实施例中，例如，可以（例如，由用户）启用一个或多个在线服务，以便数据挖掘一个或多个用户指定的账户的信用和/或借记报表，以确定例如有关购物模式的信息。将意识到，除了零售购物模式之外，也能够跟踪在线购物模式。

在一个实施例中，用户模式能够包括用户简档信息。例如，用户可以注册在线服务，诸如头版在线发射平台、社交联网服务或收集用户信息的某一其它网站。在一个实施例中，能够收集来自用户简档的信息，诸如年龄、性别和其它潜在相关的信息，以便导出用户简档模式。进一步，电子邮件帐户信息可以被收集来例如识别用户从中发送/接收电子邮件的工作地点或学校。例如，这个信息能够与旅行模式和/或本地目录相交，以便潜在地识别用户简档模式信息，诸如他们的家、工作、学校所在的地方。

在示例实施例200中的206，识别用户惯例。在一个实施例中，识别用户惯例包括:在208，组合多个历史用户模式中的至少一些，以便识别一个或多个历史用户意图252。在一个实施例中，能够在所需的时间周期从传感器250收集信息，以提供一个或多个历史用户模式。来自所需的时间周期的这些模式可以被组合，以导出用户惯例。例如，在移动设备中的加速计、GPS和时钟能够被用来识别旅行模式，这些模式能够与通过监视上个月（例如，所需的时间周期）的用户的日程表、电话呼叫、多媒体使用和信用卡活动而导出的活动模式进行组合，以识别例如在夏季期间用户在何时和在何地购物的惯例（例如，历史用户意图252）。

在204，能够从一个或多个传感器250收集实时数据。实时数据能够包括在所需的时间（例如，当数据被请求时）用于用户的上下文数据。例如，实时上下文数据能够帮助识别在任何特定的时刻相对于用户正在发生什么。传感器250尤其能够指示用户的当前位置（例如，GPS）、当前时间（例如，时钟）、对于用户的当前活动（例如，加速计、电话监视器、光传感器、计步器）、对于用户的环境条件（温度计、天气传感器、来自在线网站的天气数据）、用户距所需位置的接近度（例如，GPS、测绘数据、测距监视器）和/或用户条件（例如，健康监视器）。

在210，对于用户识别实时上下文，其能够包括利用诸如从传感器250接收的实时上下文数据。在一个实施例中，如上所述，实时上下文数据能够指示用户的位置、对于用户的位置的当前时间、对于用户的活动、对于用户的位置的一个或多个环境条件、用户距所需位置的接近度和/或用户的条件。

在212，实时上下文数据能够被组合，以识别潜在的用户意图254。潜在的用户意图能够包括一个或多个上下文数据，其提供例如用户当前正在做什么的指示。作为说明性示例，时钟可以指示现在是星期四的下午5:30，并且用户的位置、活动和接近度可以指示他们正在沿着通勤者火车路线向他们的家行进。在这个示例中，潜在的用户意图254能够包括这种信息（例如，位置、时间、活动和接近度）的组合。

在214，例如，通过比较惯例与用于用户的上下文，能够识别可能的用户意图。在216，比较惯例与实时上下文能够包括：比较一个或多个历史用户意图252与一个或多个潜在用户意图254，以识别可能的用户意图。进一步，在一个实施例中，通过组合一个或多个历史用户模式与实时上下文数据以识别用户意图，能够确定用户的意图。

作为说明性例子，潜在的用户意图254的元素（例如，位置、时间、活动、接近度、环境条件和/或用户条件）能够与一个或多个历史用户意图252相比较，以识别最接近的匹配。例如，包括星期四的下午 5:30的当前时间以及指示用户正沿着通勤者火车路线向他们的家行进的位置、活动和接近度的潜在的用户意图可以提供与指示用户正从工作通勤到家的历史用户意图（例如，基于一个或多个历史用户模式）最接近的匹配。在一个实施例中，通过比较可以识别一个以上的可能的用户意图（例如，在216）。

在示例实施例200的218，使用用户惯例和实时上下文，能够识别与该意图相关联的建议。建议能够包括建议的任务、活动、信息、内容或甚至提醒。作为说明性示例，用户惯例能够有助于根据用户在过去已完成的事情（例如，观看的内容、去过的地方、购买的物品、进行的活动）来识别建议。在这个示例中，其中用户在其通勤去上班期间一般查看新闻、社交网消息和电子邮件，和/或在他们从工作回家的途中打电话、计划晚上事件和检查股票，这个信息能够用于识别建议（例如，建议收看新闻、打电话等等）。

在一个实施例中，识别建议能够包括识别：用户以前执行的任务（例如，打电话）；用户以前进行的活动（例如，去杂货店）；用户以前查看的数据的类型（例如，体育比分）；用户以前与之交互的数据的类型（例如，在线应用，诸如游戏）；被用户标识为感兴趣领域的建议（例如，在用户简档中，诸如足球训练）。在这个实施例中，建议能够根据例如早晨的新闻项目等等的上下文信息从这些模式中的任何一个或多个模式进行识别。

在示例实施例200的220，能够确定用于用户意图的概率。在一个实施例中，确定意图的概率能够包括：确定将意图与对于用户优选的意图相匹配的可能性。例如，多个潜在的用户意图能够相对于包括历史用户意图的数据库进行匹配，并且各自潜在的用户意图能够与基于匹配准则（例如，使用将来自潜在意图的元素与历史意图数据库相匹配的概率算法）的概率相关联。

在这个示例中，匹配更多元素的那些潜在用户意图能够被分配更高的概率。例如，在春季和初夏期间，每个星期六的早晨用户往往开车去当地公园进行足球训练，并且上下文数据表明：在用户通常将去足球训练的大约相同的时间，用户当前正离开他们的家。然而，在这天，上下文数据表明：用户位置当前正遭受大雷雨。通常，当天气处在这种状况中时，用户去当地咖啡店，并进行在线来社交等等。因此，足球训练意图和咖啡店意图可能具有高概率，但根据相对于历史模式的匹配准则，咖啡店可能具有更高的概率。

在222，按照意图的各自概率，将与意图相关联的建议按优先顺序排列。在一个实施例中，将建议按优先顺序排列能够包括：将建议的用户任务、建议的用户活动、建议的供用户观看的数据、和/或建议的用户能够与之交互的数据等等按优先顺序排列。诸如通过在用户的移动设备（例如，智能电话）的屏幕上进行显示，随后能够使得按优先顺序排列的建议256可用于用户。

例如，如图3所示，用于用户的设备的开始页302能够包括按优先顺序排列的建议304的列表。按优先顺序排列的建议304可以包括：建议的新闻概要、相关的社交网络更新、本地电影院的电影时间、交通更新、或基于用户意图按优先顺序排列的其它建议。在一个实施例中，用户可以选择建议之一即S-1，以及用户可以被引导到用于该建议的页面306。作为示例，页面（例如，306）可以打开已根据用户意图按优先顺序排列的电子邮件的新的概要（例如，相关的发送者、相对于时间的重要主题和用户的位置）。

在一个实施例中，使用来自实时上下文的信息能够对惯例进行更新，以识别更新的用户模式。用户意图可能不是固定的决定，例如，用户意图可以随时间而不断变化。在一个实施例中，上下文信息能够利用传感器（例如，图2的250）来收集，并被用来更新历史用户模式和/或潜在用户意图。在这个实施例中，更新的用户模式能够用来更新用户历史意图。这些更新的历史意图能够与来自更新的上下文的更新的潜在意图进行比较，以便例如为用户提供更新的意图。

可以设计出一种系统，其利用用户意图来根据用户惯例和关于用户的实时信息识别并向用户呈现按优先顺序排列的建议。图4是用于根据移动设备的用户的意图实时给用户提供按优先顺序排列的建议的示例系统400的组件图。处理器408处理用于系统400的数据。用户惯例识别组件402识别与诸如由传感器450提供的上下文数据相关联的多个用户模式452。

用户上下文识别组件404使用来自多个传感器450的实时上下文数据来识别用于用户的上下文454。用户意图确定组件406使用处理器408来组合用户模式452与上下文454，以便实时识别用户意图456。优先化组件410根据意图456将用户建议458按优先顺序排列，从而提供按优先顺序排列的建议，例如，诸如用于在用户的移动设备上呈现。

图5是说明其中可以实现在这里描述的一种或多种系统的示例实施例500的组件组。呈现组件520能够在移动设备550上向用户呈现按优先顺序排列的用户建议560。在一个实施例中，呈现组件520包括用户任务呈现组件524，其根据意图558向用户呈现按优先顺序排列的任务。例如，如图3所示，用户可以从启动屏幕302移到任务呈现屏幕316。在这个示例中，任务建议能够根据多个用户模式和上下文数据来按优先顺序排列。

例如，当天可能是星期二，并且用户具有所呈现的建议任务318，其包括在牛排馆（Steakhouse）供二个人享用的正餐。在一个实施例中，用户可以选择该任务，以便例如在线进行预订。作为另一示例，连同数据消费模式（例如，在线搜索意大利）和通信模式（到意大利的电话呼叫和/或电子邮件）一起，用户的日程表可能已指示即将到来的意大利之旅，例如，所建议的任务可以包括进行机票预订和膳宿安排。

在一个实施例中，呈现组件520能够包括用户数据呈现组件526，其根据意图呈现按优先顺序排列的数据，以供用户使用。例如，如图3所示，用户可以从启动屏幕302移到数据呈现屏幕308。在这个示例中，根据用户意图558，数据呈现屏幕308能够包括在导航到该屏幕时对用户而言感兴趣的信息。例如，用户通常可能查阅前几天的股票市场310，其能够根据有关股票的用户以前的数据消费模式按优先顺序排列；以及用户通常可能观看涉及其通勤的新闻312，诸如本地交通、本地新闻等等，这些也能够根据用户历史模式按优先顺序排列。

在一个实施例中，呈现组件520能够包括选择组件522，其能够允许用户选择建议，以便用户进一步使用。例如，如上所述并且如图3所示，启动屏幕302能够包括对于用户的按优先顺序排列的建议304，用户可以选择这些建议并与之交互306，诸如导航到网站、电子邮件帐户、社交网络314或其它建议的任务、活动、数据等等。

该系统的示例实施例500包括上下文数据捕获组件528，其能够从多个传感器552接收上下文数据。上下文数据捕获组件528能够提供上下文数据给用户上下文识别组件404，例如，以便在确定用户上下文556时使用。在一个实施例中，传感器552能够包括：全球定位服务（GPS）传感器；位置感测组件（例如，RFID）；加速计；时钟；在线用户代理组件（例如，浏览器）；电子邮件组件；电话组件；用户简档数据库组件；测绘组件；一个或多个环境感测组件（例如，气象站、在线气象数据）；和/或基于用户的个人感测组件（例如，检测在线用户、用户进行的关于上下文信息的输入、心率监视器等等的存在）。将意识到：传感器不限于这些实施例或示例，并且预料到：本领域技术人员可以设计能够用于收集关于用户的上下文信息的备用传感器。

用户情景生成组件530能够为用户生成日常惯例情景，以供用户惯例识别组件402使用。在一个实施例中，用户情景生成组件530能够利用从传感器收集的信息来识别和/或生成情景。作为示例，这些情景能够用于帮助识别用户意图558、用户建议562并且例如根据概率将建议560按优先顺序排列。所生成的情景能够包括早晨情景，其包括从用户起床时到用户离开家时的时间，例如，从正好在用户起床之前直至他们出发去上班为止的时间（例如，对于那些上第三班的用户而言，这种情形在早晨可能不发生）。

所生成的情景能够包括：通勤情景，其包括用户正在旅行时的时间，诸如乘汽车或通勤者交通工具往来于工作或学校；以及日间情景，其包括其间用户从事工作或上学惯例的时间（例如，或任何其它日间相关的活动，诸如如果用户没有按惯例前往工作或学校地点）。进一步，所生成的情景能够包括：午餐时间情景，其包括其间用户参与午餐时间活动的时间（例如，和/或休息时间活动）；以及晚上情景，其包括从用户到家直至用户入睡时的时间。另外，所生成的情景能够包括周末情景，其包括用户一天或多天没有从事工作或上学的时间（例如，在周末，或在用户在周末工作时的一周期间，或甚至在休假期间）。

用户惯例更新组件532使用诸如来自传感器552的上下文信息来更新用于用户的一个或多个模式554。在一个实施例中，用户意图可以例如仅在特定的时刻被识别，并且用户意图可以根据用户上下文和更新的模式随时间改变。在一个实施例中，实时上下文信息能够由传感器552收集，并被用来更新用户模式554，这又能够更新用户意图558。在这个实施例中，更新的用户模式554能够被用户意图确定组件406用于例如通过将它们与实时用户上下文556进行比较来更新用户意图558。

例如，如果用户开始新的通勤模式（例如，基于新的路线开通、从汽车转换到火车、新的工作时刻表等等）、换工作、搬到新的家、或甚至当活动改变时，用户惯例更新组件532例如能够根据由传感器提供的上下文信息来识别更新的模式。作为说明性示例，用户（例如，或用户的孩子）可以在春季和夏季踢英式足球，并在夏末和秋季转换到橄榄球。在这个示例中，旅行模式、时序、位置等等的转换能够用来导出更新的用户模式，以便被用来实时提供适当的建议。即，能够根据用户的不断发展的模式和/或行为不断地进行调整。

还一个实施例牵涉计算机可读介质，其包括处理器可执行指令，这些处理器可执行指令被配置成实现在这里提出的技术中的一种或多种技术。在图6中说明可以以这些方式设计的示例的计算机可读介质，其中实现方式600包括计算机可读介质608（例如，CD-R、DVD-R或硬盘驱动的大浅盘），其中编码的计算机可读数据606在该计算机可读介质上。这个计算机可读数据606又包括一组计算机指令604，其被配置成按照在这里阐述的一个或多个原理操作。在一个这样的实施例602中，例如，处理器可执行指令604可以被配置成执行诸如图1的示例方法100之类的方法。在另一个这样的实施例中，例如，处理器可执行指令604可以被配置成实现诸如图4的示例系统400之类的系统。本领域技术人员可以设计出许多这样的计算机可读介质，其被配置成按照在这里提出的技术操作。

虽然以结构特征和/或方法动作特定的语言描述了主题，但是将明白：在所附的权利要求书中定义的主题不一定限于以上描述的特定的特征或动作。相反，以上描述的特定的特征或动作被公开为实现这些权利要求的示例形式。

如在这个申请中所使用的，术语“组件”、“模块”、“系统”、“接口”等等一般打算表示计算机相关的实体，或硬件、硬件与软件的组合、软件、或执行中的软件。例如，组件可以是但不限于是：在处理器上运行的处理、处理器、对象、可执行文件、执行的线程、程序和/或计算机。作为示例，在控制器上运行的应用和控制器能够是组件。一个或多个组件可以驻留在处理和/或执行的线程内，并且组件可以定位在一个计算机上和/或被分布在两个或多个计算机之间。

而且，所请求保护的主题可以使用标准编程和/或工程技术被实现为方法、设备或制造品，以产生软件、固件、硬件或其任何组合，从而控制计算机来实现所公开的主题。如在这里使用的术语“制造品”打算包括从任何计算机可读设备、载体或媒体中可访问的计算机程序。当然，本领域技术人员将认识到：可以对这种配置进行许多修改，而不背离所请求保护的主题的范围或精神。

图7 和以下的讨论提供适当的计算环境的简要的一般性描述，以实现在这里阐述的一个或多个规定的实施例。图7的操作环境仅仅是适当的操作环境的一个示例，并且不打算对于操作环境的使用范围或功能性提议任何限制。示例计算设备包括但不限于个人计算机、服务器计算机、手持设备或膝上型设备、移动设备（诸如移动电话、个人数字助理（PDA）、媒体播放器等等）、多处理器系统、消费者电子设备、微型计算机、大型计算机、包括任何上述系统和设备的分布式计算环境等等。

虽然不是必需的，但是以由一个或多个计算设备执行的“计算机可读指令”的一般上下文来描述实施例。计算机可读指令可以经由计算机可读介质进行分发（在下面讨论）。计算机可读指令可以被实现为执行特定任务或实现特定抽象数据类型的程序模块，诸如功能、对象、应用编程接口（API）、数据结构等等。通常，计算机可读指令的功能性可以在各种环境中根据需要进行组合或分布。

图7说明包括被配置成实现在这里提供的一个或多个实施例的计算设备712的系统710的示例。在一种配置中，计算设备712包括至少一个处理单元716和存储器718。取决于计算设备的确切配置和类型，存储器718可以是易失性的（例如，诸如RAM）、非易失性的（例如，诸如ROM、快闪存储器等）或这二者的某些组合。这种配置在图7中利用虚线714来示意。

在其它实施例中，设备712能够包括附加的特征和/或功能性。例如，设备712也可以包括附加的（例如，可拆卸的和/或不可拆卸的）存储装置，包括但不限于磁存储装置、光学存储装置等等。这样的附加存储装置在图7中利用存储装置720来示意。在一个实施例中，用来实现在这里提供的一个或多个实施例的计算机可读指令可以是在存储装置720中。存储装置720也可以存储用来实现操作系统、应用程序等等的其它的计算机可读指令。例如，计算机可读指令可以被装在存储器718中，以便由处理单元716执行。

在这里使用的术语“计算机可读介质”包括计算机存储媒体。计算机存储媒体包括以任何方法或技术实现的、用于存储诸如计算机可读指令或其它数据的信息的易失性的和非易失性的、可拆卸的和不可拆卸的媒体。存储器718和存储装置720是计算机存储媒体的示例。计算机存储媒体包括但不限于RAM、ROM、EEPROM、快闪存储器或其它存储器技术、CD-ROM、数字通用盘（DVD）或其它光学存储装置、盒式磁带、磁带、磁盘存储装置或其它磁存储设备、或能够用来存储所需的信息并能够被设备712访问的任何其它介质。任何这样的计算机存储媒体可以是设备712的一部分。

设备712也可以包括通信连接 726，其允许设备712与其它设备通信。通信连接726可以包括但不限于调制解调器、网络接口卡（NIC）、集成网络接口、射频发射机/接收机、红外端口、USB连接或用于将计算设备712连接到其它计算设备的其它接口。通信连接726可以包括有线连接或无线连接。通信连接726可以发送和/或接收通信媒体。

术语“计算机可读介质”可以包括通信媒体。通信媒体通常在诸如载波或其它传输机制之类的“调制的数据信号”中体现计算机可读指令或其它数据，并且包括任何信息传递介质。术语“调制的数据信号”可以包括这样的信号，其具有以编码信号中的信息的方式进行设置或改变的一个或多个其特征。

设备712可以包括输入设备724，诸如键盘、鼠标、笔、话音输入设备、触摸输入设备、红外照相机、视频输入设备和/或任何其它输入设备。在设备712中也可以包括输出设备722，诸如一个或多个显示器、扬声器、打印机和/或任何其它输出设备。输入设备724和输出设备722可以经由有线连接、无线连接或其任何组合被连接到设备712。在一个实施例中，来自另一个计算设备的输入设备或输出设备可以被用作用于计算设备712的输入设备724或输出设备722。

计算设备712的组件可以通过诸如总线之类的各种互连进行连接。这样的互连可以包括外围组件互连（PCI），诸如PCI Express、通用串行总线（USB）、火线（IEEE 1394）、光学总线结构等等。在另一个实施例中，计算设备712的组件可以通过网络进行互连。例如，存储器718可以包括位于通过网络互连的不同物理位置上的多个物理存储器单元。

本领域技术人员将认识到：用来存储计算机可读指令的存储设备可以被分布在网络上。例如，经由网络728可接入的计算设备730可以存储计算机可读指令，以实现在这里提供的一个或多个实施例。计算设备712可以接入计算设备730并下载一部分或所有的计算机可读指令，以便执行。作为选择，计算设备712可以下载计算机可读指令的片段，如需要的话，或者某些指令可以在计算设备712上被执行，以及一些指令可以在计算设备730上被执行。

在这里提供实施例的各种操作。在一个实施例中，所描述的一个或多个操作可以构成存储在一个或多个计算机可读介质上的计算机可读指令，这些指令如果由计算设备执行的话将使得计算设备执行所描述的操作。描述这些操作中的一些或全部操作的顺序不应被解释为暗示：这些操作一定是顺序相关的。从这个说明书中获益的本领域技术人员将意识到替换的顺序安排。进一步，将明白，不是所有的操作都一定存在于在这里提供的每个实施例中。

而且，词“示例的”在这里用来表示用作示例、实例或示意。在这里描述为“示例的”任何方面或设计不一定被解释为比其它方面或设计有利。相反，词“示例的”的使用打算以具体的方式提出概念。正如在这个申请中所使用的，术语“或”打算表示包含的“或”，而不是排他的“或”。即，除非另外指明，或从上下文中清楚，否则“X利用A或B”打算表示任何的自然包容置换。即，如果X利用A；X利用B；或X利用A和B两者,则“X利用A或B”依据任何上述实例都被满足。另外，在这个申请和所附的权利要求书中使用的冠词“一”或“一个”通常可以被解释为表示“一个或多个”, 除非另外指明或从上下文中清楚是针对单数形式。

另外，虽然本公开内容已相对于一个或多个实现方式被显示或描述了，但是对于本领域技术人员而言，基于阅读和理解本说明书和附图，将发生等价的变更和修改。本公开内容包括所有这样的修改和变更，并且仅利用随后的权利要求书的范围来限制。特别是考虑到由上述的组件（例如，元素、资源等等）执行的各种功能，除非另有说明，用来描述这样的组件的术语打算对应于执行所描述的组件的规定功能（例如，功能上等价的）任何组件，尽管在结构上不等同于执行在本公开内容的在此示意的示例的实现方式中的功能的公开结构。另外，虽然本公开内容的特定特征可能已针对若干实现方式中的仅仅一种实现方式进行公开了，但是这样的特征可以与其它实现方式的一个或多个其它特征进行组合，其中这些其他实现方式对于任何给定的或特定的应用而言可能是所需的和有利的。而且，对于术语“包括”、“具有”、“有”、“带有”或其变型在详细描述或权利要求中使用的程度而言，这样的术语打算以类似于术语“包括” 的方式而是包括在内的。

Claims

1.一种用于根据移动设备的用户的意图实时提供按优先顺序排列的建议给用户的基于计算机的方法（100），包括：

利用来自一个或多个传感器的实时上下文数据，识别用于用户的实时上下文（106）；

基于实时上下文确定用户的意图（108）；

根据意图，将包括第一建议和第二建议的对于用户的建议按优先顺序排列（110）；

从用户接收对所述第一建议的选择，以及

响应于所述选择，提供根据意图对邮件按优先顺序排列的概要。

2.权利要求1的方法，利用实时上下文数据识别用于用户的实时上下文包括接收指示用户的位置的数据。

3.权利要求1的方法，利用实时上下文数据识别用于用户的实时上下文包括接收指示用户在一个位置的当前时间的数据。

4.权利要求1的方法，利用实时上下文数据识别用于用户的实时上下文包括接收指示用户在一个位置的一个或多个环境条件的数据。

5.权利要求1的方法，利用实时上下文数据来识别用于用户的实时上下文包括接收指示用户至所需位置的接近度。

6.权利要求1的方法，利用实时上下文数据识别用于用户的实时上下文包括接收指示用户的活动的数据。

7.权利要求1的方法，确定用户的意图包括：将一个或多个历史用户模式与至少一些实时上下文数据进行组合。

8.权利要求1的方法，将建议按优先顺序排列包括：

确定用于意图的概率，其中概率包括匹配对于用户的优选意图的可能性；和

根据所述概率，将建议按优先顺序排列。

9.权利要求1的方法，将建议按优先顺序排列包括将以下的一项或多项按优先顺序排列：

一个或多个建议的用户任务；

一个或多个建议的用户活动；

建议的用于用户观看的数据；以及

建议的用户能够与之交互的数据。

10.权利要求1的方法，利用实时上下文数据识别用于用户的实时上下文包括接收指示用户的条件的数据。

11.一种用于根据移动设备的用户的意图实时提供按优先顺序排列的建议给用户的系统（400），包括：

用户上下文识别组件（404），其被配置成使用来自多个传感器的实时上下文数据来识别用于用户的上下文，所述上下文根据交通或天气的至少之一指示超过阈值的通勤时间；

用户意图确定组件（406），其被配置成利用上下文来识别用户意图；以及

被配置成根据意图发出警报的组件。

12.权利要求11的系统，所述上下文根据交通指示超过阈值的通勤时间。

13.权利要求11的系统，包括上下文数据捕获组件，其被配置成从多个传感器接收上下文数据，其包括以下的一项或多项：

全球定位服务（GPS）传感器；

位置感测组件；

加速计；

时钟；

在线用户代理组件；

电子邮件组件；

电话组件；

用户简档数据库组件；

测绘组件；

一个或多个环境感测组件；以及

基于用户的个人感测组件。

14.权利要求11的系统，包括用户惯例更新组件，其被配置成使用上下文信息来更新一个或多个用于用户的模式。