CN111656324B - 个性化的通知代理 - Google Patents

Abstract

本文描述的技术的方面针对用于提供个性化的通知管理的系统、方法和计算机存储介质以及其他。通知可以在接收时传送给用户，或者基于用户将在自呈现起的阈值经过时间内与通知进行交互的概率(如果通知被呈现的话)来排队等待后续处理。基于用户与类似的通知的过去的交互来确定概率。也可以考虑其他用户与通知的交互来确定概率。通知可以由通知代理管理。

Description

个性化的通知代理

背景技术

有时，人们接收通知很不方便。例如，当用户不方便回电话时，用户可以接收到未接呼叫的通知，并且因此该通知被解除。之后，在方便时，用户不记得进行响应，因为通知被解除了。此外，由于某些通知比其他通知更紧急，因此即使用户不那么方便进行响应，用户也可能期望由于这些通知的重要性而更早地被通知。

发明内容

提供本发明内容以便以简化的形式对下面在具体实施方式中进一步描述的概念的选择进行介绍。本发明内容不旨在标识要求保护的主题的关键特征或重要特征，也不旨在单独用于帮助确定要求保护的主题的范围。

本文描述的技术的方面针对用于提供个性化的通知管理的系统、方法和计算机存储介质以及其他。通知可以在接收时传送给用户，或者基于用户将在自呈现起的阈值经过时间内与通知进行交互的概率(如果通知被呈现的话)来排队等待后续处理。基于用户与类似的通知的过去的交互来确定概率。也可以考虑其他用户与通知的交互来确定概率。通知可以由通知代理管理。

通知代理是针对源自多个源(例如，应用、操作系统或服务)的通知的看守。通知代理接收通知、评估通知并且然后对通知采取动作。动作可以包括保持通知、删除通知以及呈现通知。通知代理可能无法处理设备上的所有通知功能。设备上的某些应用可能能够在不通过通知代理的情况下生成并输出通知。

可以通过监视用户数据来确定通知以及与这些通知的用户进行交互，并且可以根据用户数据来确定通知交互模式。关于通知的上下文信息也可以根据用户数据或根据用户数据确定的模式来确定，并且该上下文信息可以用于确定在某些上下文中与通知进行交互的概率。在一些方面，上下文信息还可以根据其他用户的用户数据(即，众包数据)来确定。在这些方面，数据可以以保留其他用户的隐私的方式来进行去标识或以其他方式使用。

另外地，可以基于所确定的用户模式和/或从与用户相关联的一个或多个用户设备(例如，智能电话)以及在某些实例中从与其他用户相关联的设备感测到的用户数据来预测该用户与通知进行交互的概率。例如，用户数据(例如，位置、时间、在线活动、(多个)日历或任何数量的其他用户数据)可以被收集并且用于确定针对与和通知进行交互相关的不同类型的活动的用户可用性模式、用户典型地如何响应于某些事件以及其他用户典型地如何响应。

附图说明

下面参考所附附图详细描述了本发明的方面，在附图中：

图1是适合于实现技术的方面的示例操作环境的框图；

图2是描绘适合于实现技术的方面的示例计算架构的图；

图3描绘了根据技术的方面的可以呈现给用户的通知内容的一个示例；

图4-6描绘了根据技术的方面的用于向用户提供个性化的通知内容的方法的流程图；以及

图7是适合用于实现技术的方面的示例性计算环境的框图。

具体实施方式

技术的方面的主题以本文的具体性来描述以满足法定要求。然而，说明书本身不旨在限制本专利的范围。而是，发明人已经设想了要求保护的主题也可以结合其他当前或未来的技术以其他方式来体现，以包括不同的步骤或与该文档中描述的步骤类似的步骤的组合。另外，尽管术语“步骤”和/或“框”可以在本文中用于意指所采用的方法的不同的元素，但是这些术语不应该被解释为暗示本文中公开的各个步骤之中或之间的任何特定的次序，除非并且除了各个步骤的次序被显式描述之外。

本文描述的技术的方面针对用于提供个性化的通知管理的系统、方法和计算机存储介质以及其他。通知可以在接收时传送给用户，或者基于用户将在自呈现起的阈值经过时间内与通知进行交互的概率(如果通知被呈现的话)来排队等待后续处理。基于用户与类似的通知的过去的交互来确定概率。也可以考虑其他用户与通知的交互来确定概率。通知可以由通知代理管理。

本文描述的技术的方面针对改进计算机如何将通知传送给用户以及其他。提供通知是计算机的用户计算机接口的功能。该接口可以是图形用户接口、音频用户接口或采取某种其他类型，例如，触觉。本发明通过更好地理解并利用指示用户是否将在给定时间点与给定通知进行交互的隐式用户输入信号来改进用户接口。

传统上，计算机可以通过由用户提供的手动指令来管理通知。例如，用户可以手动地设置是否以及何时可听声音将提醒用户已经接收到了电子邮件或文本。然而，这些设置不是非常精细，并且没有考虑实时用户信号。例如，用户的手动设置可以指示用户可在上午7:00至晚上11:00之间获得通知。实际上，用户在该时间期间响应通知的能力将变化。例如，用户在会议中可能无法响应通知。当前的通知管理过程不考虑用户的活动。

当前可用技术的结果是非常低效的通知过程，该通知过程在用户不太可能与通知进行交互的不合适的时间提供通知。然后，这些通知会被忘记，从而导致糟糕的用户体验。在其他情况下，计算设备需要重复不与其进行交互的通知，从而导致计算机资源的低效使用。仅在用户可能与通知进行交互时才呈现通知创建了更好的用户体验并且减少了重复的通知工作。

本文描述的技术的方面通过预测用户是否将与通知进行交互来对通知的传送进行自动加速或排队，从而提供了对计算机如何管理向用户传送通知的改进。例如，如果预测用户将对接收到的电子邮件进行响应，则在接收到电子邮件时通知(例如，指示电子邮件已经到达的可听声音)将被传送给用户。因此，改进了计算机向用户传送通知，因为与被预测为不会导致用户交互的通知相比，可能引起用户响应的通知被更快地传送给用户。

通知代理是针对源自多个源(例如，应用、操作系统或服务)的通知的看守。通知代理接收通知、评估通知并且然后对通知采取动作。动作可以包括保持通知、删除通知以及呈现通知。通知代理可能无法处理设备上的所有通知功能。设备上的某些应用可能能够在不通过通知代理的情况下生成并输出通知。

术语“通知事件”在本文中被宽泛地使用以包括由用户、应用或设备与电子通知相关联地采取(或未采取)的动作。通知可以是可听的、可见的、触觉的(例如，振动)或者这些与其他通信信道的组合。通知指代由与用户相关联的计算设备接收或发起的几乎任何通知，包括尝试的通知(例如，未接呼叫)、旨在针对用户的通知、代表用户发起的通知(例如，任务提醒)或用户可获得的通知。通知可以针对提醒、任务、公告或新闻项目(包括与用户相关的新闻，例如，本地或区域新闻、天气、交通或社交网络/社交媒体信息)。因此，通过示例而非限制的方式，通知事件可以与使用户意识到通信的工作相关，包括：语音/视频呼叫；电子邮件；SMS文本消息；即时消息；通知；社交媒体或社交网络新闻项目或通信(例如，推文、Facebook帖子或“喜欢”、邀请、新闻馈送项目)；与用户相关的新闻；用户可能处理或响应的任务；RSS馈送项目；网站和/或博客帖子、评论或更新；日历事件、提醒或通知；会议请求或邀请；包括游戏通知和消息的应用内通信(包括来自其他玩家的那些通知和消息)；等等。一些通知事件可以与实体(例如，联系人或企业，在某些实例中包括用户本人)相关联，或者与一类实体(例如，密友、同事、老板、家庭、用户访问过的企业场所等)相关联。通知可以通过通知的内容与实体相关联。例如，对已经接收到电子邮件的通知可以与电子邮件的发送者以及电子邮件的共同接收者相关联。通知还可以来自应用和系统功能，例如，从而让用户知道更新是可用的。

“被忽略的通知”可以指代用户尚未与其进行交互、响应、处理或以其他方式解决的通知，例如，未接呼叫或未发起的呼叫、未响应的电子邮件、未确认的通知或提醒、未解决的任务、未解决的请求、未解决的社交媒体项(例如，与用户相关的标签、推文、新闻馈送帖子或类似事件)等。与通知事件的交互可以对应于一个或多个用户响应或与解决通知原因相关联的活动，例如，完成呼叫或回电话、完成任务、起草电子邮件、确认新的项目通知或社交媒体帖子、安排预约或者购买周年纪念日礼物。通过标识未解决的事件，可以基于未解决的事件的上下文和用户行为来向用户提供内容(例如，服务内容)，以便针对用户定制内容或使内容个性化。

因此，在高级别处，在一方面，从一个或多个数据源接收用户数据。可以通过利用与用户相关联的(多个)用户设备上的一个或多个传感器收集用户数据来接收用户数据，如本文所描述的。结合图2的组件214进一步描述的用户数据的示例可以包括用户的(多个)移动设备的位置信息、用户活动信息(例如，应用使用、在线活动、搜索、呼叫)、应用数据、联系人数据、日历和社交网络数据或者由用户设备或其他计算设备可以感测到或确定的用户数据的几乎任何其他源。

可以通过监视用户数据来确定通知以及与这些通知的用户进行交互，并且可以根据用户数据来确定通知交互模式。关于通知的上下文信息也可以根据用户数据或根据用户数据确定的模式来确定，并且该上下文信息可以用于确定在某些上下文中与通知进行交互的概率。在一些方面，上下文信息还可以根据其他用户的用户数据(即，众包数据)来确定。在这些方面，数据可以以保留其他用户的隐私的方式来进行去标识或以其他方式使用。

另外地，可以基于所确定的用户模式和/或从与用户相关联的一个或多个用户设备(例如，智能电话)以及在某些实例中从与其他用户相关联的设备感测到的用户数据来预测该用户与通知进行交互的概率。例如，用户数据(例如，位置、时间、在线活动、(多个)日历或任何数量的其他用户数据)可以被收集并且用于确定针对与和通知进行交互相关的不同类型的活动的用户可用性模式、用户典型地如何响应于某些事件以及其他用户典型地如何响应。

另外，技术的某些方面可以由个人助理应用或服务执行，该个人助理应用或服务可以实现为一个或多个计算机应用、服务或例程，例如，在本文进一步描述的移动设备或云中运行的应用。

现在转向图1，提供了示出在其中可以采用本公开的方面的操作环境100的框图。应该理解的是，本文描述的这种布置和其他布置仅作为示例阐述。其他布置和元件(例如，机器、接口、功能、次序和功能组等)可以在这些示出的布置和元件之外或替代这些布置和元件来使用，并且为了清楚起见，可以完全省略一些元件。此外，本文描述的元件中的许多元件是功能实体，这些元件可以实现为分立或分布式组件，或者结合其他组件来实现，以及在任何合适的组合和位置中实现。本文中被描述为由一个或多个实体执行的各种功能可以由硬件、固件和/或软件来执行。例如，一些功能可以由执行存储在存储器中的指令的处理器来执行。

在未示出的其他组件中，示例操作环境100包括：多个用户设备(例如，用户设备102a和102b至102n)；多个数据源(例如，数据源104a和104b至104n)；服务器106；以及网络110。应该理解的是，图1中示出的环境100是一个合适的操作环境的示例。图1中示出的组件中的每个组件可以经由任何类型的计算设备(例如，结合图7描述的计算设备700)来实现。这些组件可以经由网络110彼此通信，网络110可以包括但不限于一个或多个局域网(LAN)和/或广域网(WAN)。在示例性实现方式中，网络110包括互联网和/或蜂窝网络，以及各种可能的公共和/或专用网络中的任一种。

应该理解的是，在本公开的范围内，可以在操作环境100内采用任何数量的用户设备、服务器和数据源。每个用户设备、服务器和数据源可以包括单个设备或者在分布式环境中协作的多个设备。例如，服务器106可以经由布置在共同提供本文描述的功能的分布式环境中的多个设备来提供。另外地，未示出的其他组件也可以包括在分布式环境内。

用户设备102a和102b至102n可以是操作环境100的客户端侧上的客户端设备，而服务器106可以在操作环境100的服务器侧上。服务器106可以包括服务器侧软件，该服务器侧软件被设计为结合用户设备102a和102b至102n上的客户端侧软件工作，以便实现本公开中讨论的特征和功能的任何组合。提供操作环境100中的这种划分以示出合适环境的一个示例，并且针对每个实现方式，不要求服务器106以及用户设备102a和102b至102n的任何组合保持为单独的实体。

用户设备102a和102b至102n可以包括能够由用户使用的任何类型的计算设备。例如，在一方面，用户设备102a至102n可以是本文关于图7描述的计算设备的类型。通过示例而非限制的方式，用户设备可以体现为个人计算机(PC)、膝上型计算机、移动装置或移动设备、智能电话、平板计算机、智能手表、可穿戴计算机、个人数字助理设备(PDA)、MP3播放器、全球定位系统(GPS)或设备、视频播放器、手持通信设备、游戏设备或系统、娱乐系统、车辆计算机系统、嵌入式系统控制器、遥控器、电器、消费者电子设备、工作站，或者这些所描述的设备的任何组合，或者可以在其中呈现通知的任何其他合适的设备。

数据源104a和104b至104n可以包括数据源和/或数据系统，数据源和/或数据系统被配置为使数据可用于操作环境100的各个组成部分中的任一个，或者可用于结合图2描述的系统200。(例如，在一方面，一个或多个数据源104a至104n向图2的用户数据收集组件214提供用户数据(或使用户数据可供访问))。数据源104a和104b至104n可以与用户设备102a和102b至102n以及服务器106分离，或者可以并入和/或集成到这些组件中的至少一个中。在一方面，数据源104a至104n中的一个或多个包括一个或多个传感器，这些传感器可以集成到(多个)用户设备102a、102b或102n或服务器106中的一个或多个中或与其相关联。结合图2的用户数据收集组件214还描述了由数据源104a至104n提供的感测到的用户数据的示例。

可以利用操作环境100来实现图2中描述的系统200的组件中的一个或多个，包括用于收集用户数据、监视通知事件、生成通知内容和/或向用户呈现通知和相关内容的组件。现在参考图2，利用图1，提供了示出适合用于实现技术的方面并且总体上表示为系统200的示例计算系统架构的方面的框图。系统200仅表示合适的计算系统架构的一个示例。其他布置和元件可以在这些示出的布置和元件之外或替代这些布置和元件来使用，并且为了清楚起见，可以完全省略一些元件。此外，如同操作环境100，本文描述的元件中的许多元件是功能实体，这些元件可以实现为分立或分布式组件，或者结合其他组件来实现，以及在任何合适的组合和位置中实现。

示例系统200包括结合图1描述的网络110，并且该网络110通信地耦合系统200的组件，这些组件包括用户数据收集组件214、通知监视器280、通知代理260、呈现组件218以及存储装置225。通知监视器280(包括其组件282、284和286)、通知代理260(包括其组件262、264、266和268)、用户数据收集组件214以及呈现组件218可以体现为编译的计算机指令或功能的集合、程序模块、计算机软件服务或在一个或多个计算机系统(例如，结合图7描述的计算设备700)上执行的处理的布置。

在一方面，由系统200的组件执行的功能与一个或多个个人助理应用、服务或例程相关联。具体地，这样的应用、服务或例程可以在一个或多个用户设备(例如，用户设备102a)、服务器(例如，服务器106)上操作，可以跨一个或多个用户设备和服务器分布，或者在云中实现。此外，在一些方面，系统200的这些组件可以跨网络分布，该网络包括云中的一个或多个服务器(例如，服务器106)和客户端设备(例如，用户设备102a)，或者可以驻留在用户设备(例如，用户设备102a)上。此外，这些组件、由这些组件执行的功能或由这些组件执行的服务可以在合适的(多个)抽象层(例如，(多个)计算系统的操作系统层、应用层、硬件层等)处实现。可替代地或另外地，这些组件的功能和/或本文描述的技术的方面可以至少部分地由一个或多个硬件逻辑组件来执行。可以使用的硬件逻辑组件的说明性类型包括例如但不限于：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、应用专用标准产品(ASSP)、片上系统系统(SOC)、复杂可编程逻辑器件(CPLD)等。另外地，尽管本文中关于示例系统200中示出的特定组件描述了功能，但是可以设想，在一些方面，这些组件的功能可以跨其他组件共享或分布。

继续图2，用户数据收集组件214通常负责从一个或多个数据源(例如，图1的数据源104a和104b至104n)访问或接收(在某些情况下还标识)用户数据。在一些方面，可以采用用户数据收集组件214来促进一个或多个用户的用户数据(包括众包数据)的累积，以供通知监视器280和通知代理260使用。数据可以由数据收集组件214接收(或访问)，并且可选地进行累积、重新格式化和/或组合，并且存储在一个或多个数据存储(例如，存储装置225)中，在该数据存储中，数据可以对通知监视器280和通知代理260是可用的。例如，用户数据可以被存储在用户简档240中或与用户简档240相关联，如本文所描述的。

可以从各种源接收用户数据，在该源中数据可以以各种格式获得。例如，在一些方面，经由用户数据收集组件214接收到的用户数据可以经由一个或多个传感器来确定，这些传感器可以在一个或多个用户设备(例如，用户设备102a)、服务器(例如，服务器106)和/或其他计算设备上或与其相关联。如本文所使用的，传感器可以包括用于感测、检测或以其他方式从数据源104a获得信息(例如，用户数据)的功能、例程、组件或其组合，并且可以被体现为硬件、软件或这二者。用户数据可以包括：从一个或多个传感器感测到或确定的数据(在本文中被称为传感器数据)，例如，(多个)移动设备的位置信息、智能电话数据(例如，电话状态、充电数据、日期/时间或来自智能电话的其他信息)、包括在多于一个用户设备上发生的用户活动的用户活动信息(例如：应用使用；在线活动；搜索；语音数据，例如，自动语音识别；活动日志；通信数据，包括电话、文本、即时消息和电子邮件；网站帖子；与事件相关联的其他用户数据；等等)、用户历史、会话日志、应用数据、联系人数据、日历和时间表数据、通知数据、社交网络数据、新闻(包括搜索引擎或社交网络上的流行或热门项目)、在线游戏数据、电子商务活动(包括来自诸如或/>之类的在线帐户的数据)、(多个)用户帐户数据(其可以包括来自与个人助理应用或服务相关联的用户偏好或设置的数据)、家用传感器数据、电器数据、全球定位系统(GPS)数据、车辆信号数据、交通数据、天气数据(包括预报)、可穿戴设备数据、其他用户设备数据(其可以包括设备设置、简档、网络连接(例如，Wi-Fi网络数据)或配置数据、关于型号、固件或装置、设备配对(例如，用户将电话与例如蓝牙耳机配对的情况)的数据)、陀螺仪数据、加速度计数据、支付或信用卡使用数据(其可以包括来自用户的PayPal帐户的信息)、购买历史记录数据(例如，来自用户的Amazon.com或eBay帐户的信息)；传感器(或其他检测器)组件可以感测到或以其他方式检测到的其他传感器数据，包括来自与用户相关联的传感器组件的数据(包括位置、运动、定向、方位、用户访问、用户活动、网络访问、用户设备充电或能够由一个或多个传感器组件提供的其他数据)；基于其他数据得出的数据(例如，可以来自Wi-Fi、蜂窝网络或IP地址数据的位置数据)；以及可以如本文所描述地被感测到或确定的数据的几乎任何其他源。在一些方面，可以在用户信号中提供用户数据。用户信号可以是来自对应的数据源的用户数据的馈送。例如，用户信号可以来自智能电话、家庭传感器设备，GPS设备(例如，用于位置坐标)、车辆传感器设备、可穿戴设备、用户设备、陀螺仪传感器、加速度计传感器、日历服务、电子邮件帐户、信用卡帐户或者其他数据源。在一些方面，用户数据收集组件214持续地、周期性地或根据需要接收或访问数据。

通知监视器280通常负责监视通知和相关信息，以便描述通知事件。例如，如先前所描述的，可以通过监视用户数据(包括从用户数据收集组件214接收到的数据)来确定通知事件以及与通知的用户进行交互，并且由此可以确定通知交互模式，并且基于该模式来预测未来的交互概率。在一些方面，通知监视器280分析跨多个计算设备或云中的通知事件和相关信息。

如示例系统200中示出的，通知监视器280包括通知事件构建器282、交互检测器284和上下文信息提取器286。通知监视器280构建通知事件记录，可以对该通知事件记录进行分析以确定用户对未来通知进行响应的概率。通知监视器280在通知被呈现时收集相关的上下文信息，确定用户是否与通知进行了交互，并且在事件记录中将通知描述、交互以及上下文数据进行关联。在一些方面，通知监视器280和/或其子组件中的一个或多个可以根据接收到的用户数据来确定解释性数据。解释性数据与由通知监视器280的子组件用于解释用户数据的数据相对应。例如，解释性数据可以用于向用户数据提供上下文，该上下文可以支持子组件做出的确定或推断。此外，预期通知监视器280以及其子组件的方面可以使用用户数据和/或用户数据与解释性数据的组合以用于实现本文描述的子组件的目标。

通知事件构建器282构建通知事件，该通知事件记录关于通知的细节以及响应于接收通知而采取的用户的动作。这些事件用于训练模型，以计算针对未来事件的用户特定的响应概率。每次向用户呈现通知时，都可以构建通知事件。单独的通知事件可以描述呈现给用户的通知的单个实例。一旦构建了事件，就可以将事件存储在计算机存储器中以供后续分析。通知事件包括对通知的描述、当通知被呈现时用户的上下文以及用户是与通知进行了交互还是忽略通知。

事件记录描述了通知的特征。通知特征可以包括通知信道。示例通知包括锁屏通知、徽章通知、可听通知、振动通知以及其他通知。通知功能可以包括生成了该通知的应用。用户可以对不同的通知不同地表现或反应。通知可以与实体或一类实体(例如，密友、同事、老板、家庭、用户经常出入的企业(例如，银行)等)相关联。通知功能可以包括与通知相关联的人。例如，呼叫通知可以与进行呼叫的人相关联。

通常，通知交互检测器284负责确定用户是否与通知进行了交互。如所提到的，技术的目标是在用户将与通知进行交互时呈现通知。用于确定用户何时将与未来通知进行交互的构建块是对用户如何与先前的通知进行交互的记录。通过分析与在用户被呈现通知之后发生的事件和用户活动相对应的(从用户数据收集组件214接收到的)用户数据来确定交互信息。在一些方面，通知交互检测器284从呈现组件218接收数据，该数据可以包括与用户已经意识到的通知的用户交互。例如，呈现组件218可以提供关于以下各项的信息：用户是否选定了通知、是否悬停在通知上或是否与通知进行了眼神接触(例如，在可用时使用凝视检测)。通知交互检测器284还可以从上下文信息提取器286接收关于所监视的通知的上下文信息。

通知交互检测器284结合所监视的通知来对该信息进行分析，并且确定用户是否与通知进行了交互。通知交互可以通过交互的直接证据或间接交互来检测。间接交互可以包括在多个用户设备上发生的活动。

当用户直接参与通知时(例如，当用户点击通知时)，发生与通知的交互的直接观察。点击是通知交互的示例。

本文描述的技术的方面还检测与通知的间接交互。间接交互是响应于通知而发生的，但并不直接与该通知一起发生。例如，响应于从某人接收到文本消息的通知而呼叫该人可以是与该通知的间接交互。仅呼叫某人可能不足以成为交互。例如，呼叫可能需要在自收到通知起的阈值时间内发生。该阈值可以被编辑地设置。类似地，响应于某人呼叫的通知而呼叫该人也是交互，尽管该交互并不直接与该通知一起发生，并且不通过与该通知无关的通信信道发生。

在一些方面，交互检测器284使用来自(多个)用户账户/活动数据248的信息以用于监视与用户相关的社交网络活动。交互检测器284还可以响应于通知监视器280检测到的事件来监视用户活动。在这样做时，交互检测器284的一些方面基于用户活动来确定用户可能尚未解决通知或可能尚未与通知进行交互。例如，在用户活动指示用户尚未访问社交媒体帐户的情况下，或者在用户(或其他用户)典型地以用户活动某种模式对类似的通知做出响应或做出反应，但这种用户活动尚未由交互检测器284检测到的情况下，然后可以确定用户可能尚未与该通知进行交互。

在一方面，交互检测器284考虑用于类似通知的典型用户交互模式，以确定是否发生了用户交互。可以将用户响应交互模式与当前或近期的用户活动数据进行比较，以便确定用户是否已经与通知进行了交互(或可能进行了交互)。例如，在向用户呈现了指示他的周年纪念日在下周的日历(或任务)通知，并且用户数据(例如，用户的电子邮件或网站用户历史记录)指示用户在周年纪念日的日期在餐厅进行了预定的情况下，然后可以确定用户已经与通知进行了交互，并且因此通知代理260可以确定存在用户在未来将与在类似上下文中呈现的类似通知(例如，重要数据提醒)进行交互的可能性。

作为通过不同的通信信道与通知进行间接交互的另一示例，假设在与用户相关联的帐户上接收到电子邮件，并且与该电子邮件相关联的上下文信息指示该电子邮件来自用户的老板。膝上型计算机上会呈现已经接收到电子邮件的通知，但是未检测到与该通知的直接交互。用户数据指示该用户访问了他的电子邮件、被呈现在用户设备上的电子邮件(换言之，该用户可能已经阅读了来自他的老板的电子邮件)，但是该用户尚未回复该电子邮件。但是，用户数据还指示用户在访问电子邮件之后(通过他的智能电话)呼叫了他的老板。然后，可以通过对发生在两个不同设备上的这些动作进行梳理来确定用户可能已经与该通知进行了交互，从而表明当类似的通知在类似的上下文中呈现时，将与该通知进行交互。

作为又一示例，假设呈现了用户未接听呼叫的通知，并且与该呼叫相关联的上下文信息指示用户的妻子进行了呼叫。用户数据指示自未接听呼叫以来，用户尚未呼叫他的妻子或以其他方式进行电子通信。因此，该通知可以被分类为未交互的通知。

现在，进一步假设在发生未接呼叫时用户与他的妻子不在相同的位置(可以根据与用户相关联的用户设备(例如，智能电话)来确定位置)，但是现在用户的位置和妻子的位置是相同的；例如，两个人当前都位于家中。然后，可以确定通知事件(未接呼叫)不太可能被忽略，因为用户和他的妻子在一起在家中，并且很可能彼此通信。改变位置之间经过的时间也可以用作将通知分类为与其进行交互或被忽略的因素。

可以使用启发方法或机器分类器来确定是否发生了交互。在直接交互(例如，点击通知)的情况下，启发方法是足够的。可以设置规则或启发方法来检测点击、悬停、视觉接触或由计算机捕获的与通知的其他直接交互，并且在通知事件中记录肯定的交互。也可以记录交互的性质。规则也可以用于检测某些间接交互。例如，可以使用规则来确定当用户在接收到指示从实体接收到通信的通知时通过任何方式与实体进行通信时发生的交互。结果可以是与每个通知的交互的日志。

可以使用机器学习分类器来确定对是否发生了交互的确定。有监督学习过程是可能合适的一种类型的机器学习。有监督学习过程可以使用经标记的训练数据来对用户在接收到通知之后采取的作为与通知的交互的一系列动作进行分类。例如，可以将一系列动作(例如，电话呼叫、购买、会议邀请、文本、社交帖子以及相关的通知)映射为自变量和手动标签，从而指定有资格作为交互的动作的组合作为因变量。训练数据用于训练功能(不同的有监督学习过程可以使用不同的功能)，以将用户动作数据和通知描述映射到输出。以这种方式，功能应该将动作的组合分类为在给定训练数据中类似的动作数据和通知数据的情况下的期望的结果(即，交互)。可以对动作数据、交互数据和通知数据进行预处理，以适应可以用于在训练和使用两者期间向功能输入数据的模式。

通常，上下文信息提取器286负责确定与由通知监视器280监视的通知相关联的上下文信息，例如，与事件和用户相关的活动相关联的上下文特征或变量。上下文信息可以帮助解释当收到通知时用户正在做什么。例如，上下文信息可以包括当接收到通知时正在运行或用户正在与其进行交互的应用。可以根据由用户数据收集组件214提供的一个或多个用户的用户数据来确定上下文信息。例如，上下文信息提取器286在某些实例中接收用户数据、对数据进行解析并且标识并提取上下文特征或变量。在一些方面，变量被存储为与在事件之后的时间间隔内的事件、响应或用户活动相关联的上下文信息的相关集合(其可以指示用户响应)。

具体地，上下文信息提取器286的某些方面确定与事件、联系人实体(或实体，例如，在群组电子邮件的情况下)、围绕事件的用户活动以及当前用户活动相关的上下文信息。通过示例而非限制的方式，这可以包括上下文特征，例如，位置数据；时间、天和/或日期；通知的数量和/或频率；通知中的关键字(其可以用于确定)；关于与通知相关联的实体的上下文信息(例如，实体标识、与用户的关系、联系人实体(如果可确定的话)的位置、先前与用户联系的频率或级别)；包括与联系人实体的模式和历史的历史信息；(多个)通知的模式或类型；用户在事件发生时或可能对通知进行响应时在参与什么用户活动，以及用户参与与通知事件相关联的活动的时间、地点以及时长；或者可根据用户数据确定的任何其他变量，包括来自其他用户的用户数据。当通知指示从实体(例如，个人或企业)接收到社交帖子、电子邮件、文本、电话呼叫、语音邮件或其他内容时，通知可以与实体相关联。系统通知(例如，更新应用的请求)可以与应用发布者相关联。

在又一示例中，在某些实例中，可以使用来自一个或多个用户日历(例如，办公室日历、个人日历、社交媒体日历，或者甚至来自用户的家庭成员或朋友的日历)的日历信息来确定用户交互概率。技术的一些方面可以为用户构造补充日历或影子日历，以用于确定交互概率。具体地，在这些方面，补充日历或影子日历可以用于创建用户的交互概率模型。

在一方面，可以基于与设备的用户相关联的传感器数据来构造补充日历。例如，可以评估社交网络简档(例如，社交网络帖子、社交网络消息、指示用户的爱好或兴趣的用户简档)，以将用户的活动标识为特定的传感器数据。在另一示例中，可以评估用户设备的上下文，以将用户的活动标识为传感器数据(例如，设备位置可以指示用户在周二在足球场进行足球练习；设备位置登记可以指示用户在周日外出进行电影约会(例如，用户可以通过社交网络登记)；连通性状态(例如，Wi-Fi连通性)可以指示用户在家、在办公室或在咖啡馆；充电状态(例如，汽车充电状态)可以指示用户当前正在驾驶；设备上的假期行程文件可以指示用户将在一周后去度假；等等)。

可以认识到的是，在一些方面，可以评估各种各样的信息(例如，时间信息和/或位置信息)，以标识传感器数据和/或补充传感器数据(例如，用户的主要日历可以用于标识冲突和/或验证来自传感器数据的活动；可以针对诸如交通信息、天气或补充信息之类的实时数据来评估传感器数据，补充信息可以包括来自用户的社交媒体帐户、家人或朋友的社交媒体帐户、电子邮件、新闻和其他用户数据(例如，众包数据)的信息)。以这种方式，可以利用来自传感器数据的一个或多个条目(例如，基于推断的活动自动生成的条目)来构造补充日历。在一方面，补充日历可以与一个或多个日历(例如，用户的主要日历、家庭日历、社交网络日历等)合并以创建阴影日历，该阴影日历包括补充日历中的至少一些(例如，来自传感器数据的/从传感器数据推断的自动生成的条目)以及一个或多个日历中的至少一些(例如，由用户在主要日历内填充的用户条目)。可以基于补充日历和/或影子日历来标识安排冲突(例如，用户条目可以指示用户在周一上午9:00-9:30有工作会议，并且补充日历内的条目可以基于社交网络帖子指示用户将在周一上午9:15与朋友见面喝咖啡)。

继续图2，通知代理260通常负责生成并提供关于事件的通知内容，其中，可以将该通知内容作为个性化的通知提供给用户。在一方面，通知内容包括通知，该通知可以以用户用于解决未解决的事件的推荐动作的形式，并且还可以包括用于帮助用户解决事件的补充内容。如示例系统200中示出的，通知代理260包括应用接口262、概率引擎264、重新评分触发266以及通知队列268。

在一些方面，通知代理260生成要呈现给用户的通知，该通知可以被提供给呈现组件218。可替代地，在其他方面，通知代理260生成通知内容并且将通知内容提供给呈现组件218，该呈现组件218基于通知内容中的通知逻辑和应用于通知逻辑的用户数据来确定如何(即，以哪种格式)呈现通知。在一些方面，结合呈现组件218操作的通知服务或应用确定或促进确定如何呈现通知。可以将与用户相关联的未决的所呈现的通知存储在用户简档240中，例如，存储在(多个)通知组件250中。此外，在一些方面，通知代理260、呈现组件218和/或通知服务或应用管理针对用户的未决通知，并且可以对呈现哪些通知进行优先级排序，例如下面所描述的。

通知代理260可以通过应用接口262从用户数据收集组件214和/或通知监视器280接收信息(其可以存储在与用户相关联的用户简档240中)。应用接口262可以从应用和服务接收通知以呈现给用户。在向用户呈现通知时，应用接口262可以向应用或服务提供呈现/响应状态。

通常，概率引擎264负责确定通知交互模式。在一些方面，可以通过监视与通知或对这些通知的用户交互相关的一个或多个变量来确定交互模式。这些所监视的变量可以根据结合用户数据收集组件214描述的、与通知相关联的用户数据(例如，位置、时间/天、与通知相关联的通信的(多个)发起者或(多个)接收者、通信类型(例如，呼叫、电子邮件、文本等)、用户设备数据等)来确定。

此外，在一些方面，概率引擎264使用众包数据或来自多个用户的数据来确定响应信息，该响应信息可以用于基于特定用户将与其他用户类似地做出反应的前提来确定针对特定用户的可能的交互模式。例如，可以基于这样的确定来确定交互概率：其他用户更有可能在晚上呼叫他们的朋友和家人，而白天在工作期间不太可能呼叫这些相同的实体。类似地，可以基于这样的确定来确定用户模式：其他用户典型地在最快的方便的时间回叫他们的配偶，但是即使不方便也尽快回叫他们的老板。可以使用这些通信模式作为输入来计算通知交互概率，以确定与这些通信中的一个通信相关联的通知是否可能导致来自用户的交互。

具体地，可以根据与通知事件相关的上下文数据来确定与通知交互相关联的变量，该上下文数据可以由上下文信息提取器286从用户数据中提取，如本文所描述的。因此，变量可以表示多个事件之间的上下文类似性。以这种方式，可以通过检测多个事件中共同的变量来标识模式。更具体地，可以将与第一通知事件相关联的变量与第二通知事件的变量相关，以标识用于确定可能的模式的共同变量。例如，在第一通知事件包括用户立即点击指示在周二下午3:30从标识为“Steve”的联系人接收到的文本的通知，并且用户立即点击指示在周三下午2:08从标识为“Steve”的联系人接收到的文本的通知的情况下，可以确定用户在工作日期间与来自Steve的文本通知进行交互的模式。在这种情况下，针对两个事件的共同变量包括相同的联系人实体(Steve)、相同的日期类型(工作日)、相同的时间分类(工作时间)以及相同的通信类型或模式(文本)。关于Steve的语义信息以及Steve与用户之间的关系可以用于扩展模式。例如，如果Steve是同事，则可以将模式从Steve推断到一类人(同事)。如果用户在工作日的工作时间期间迅速地响应来自其他同事的文本，则可以加强这种推断。

组成模式的事件实例被重复得越频繁，标识出的模式就变得越强大(即，更有可能发生或更可预测)。类似地，特定变量在重复时会变得与模式更紧密相关联。例如，假设每天下午5:00之后(下班之后)和在驾驶时，用户不会与关于从任何人接收到的通信的通知进行交互。尽管与通知相关的特定人员(即，发送文本或呼叫的联系人实体)会变化，但是由于用户在驾驶时反复忽略通知，因此存在事件模式。

交互模式不一定包括相同的通信模式。例如，一种模式可以是用户仅在非工作时间期间响应来自他的母亲的呼叫或电子邮件。

概率引擎264通过使用机器学习机制分析更新后的上下文信息，来计算针对通知中的每个通知的用户特定的交互概率，该机器学习机制是使用历史通知时间数据而被训练的。

在不同方面可以使用不同的机器学习过程，包括有监督学习过程(例如，决策树、随机森林、逻辑回归)、无监督学习(例如，先验算法、K均值)或强化学习。在每种情况下，上下文数据和通知描述是用于确定用户特定的交互概率的输入。本质上，用户特定的交互概率是在当前通知和上下文与用户和通知进行交互的先前通知事件之间类似性的测量。

这些机器学习方法中的每一个使用历史上下文数据、通知数据和交互数据来训练机器学习模型。如先前所描述的，可以将该数据收集为通知事件数据。在训练过程期间，不同类型的机器学习过程可以不同地使用历史数据。

有监督学习过程使用历史上下文数据和通知描述作为自变量，并且使用相关联的交互观察作为因变量。历史数据用于训练功能(不同的有监督学习过程可以使用不同的功能)，以将上下文数据和通知描述映射到输出。以这种方式，功能应该在给定类似的上下文数据和通知数据作为输入的情况下预测期望的结果(即，交互)。可以对上下文数据、交互数据和通知数据进行预处理，以适应可以用于在训练和使用两者期间向功能输入数据的模式。

一些学习方法通常试图基于类似特性来对人或物体进行聚类。这可能适合于经由从类似数据的推断而找到某种交互概率，例如，一个人可以以相同的方式与具有类似特性的通知进行交互。然后可以使用组特性(例如，系统通知、社交媒体通知)来确定用户将如何响应于来自尚未进行直接观察的实体的通知。学习方法可以使用上下文数据以将通知分类为类似于在类似的上下文中的其他通知。聚类可以帮助解决冷启动问题(没有与被评估的用户、应用或其他实体进行先前的交互)。例如，当将新用户添加到系统时，然后可以使用应用级特征和设备上下文特征而非用户特征来确定交互概率。设备当前可用的所有应用/服务的历史可以用于基于该应用/服务的所有用户与给定应用/服务的历史交互来预测新用户的交互。在评估新应用(而不是新用户)时，可以采取不同的方法。系统可以基于与相同类别的应用(例如，音乐应用、电子邮件应用)的所有用户先前的参与来对应用进行分类并预测通知参与。或者系统可以基于与相同类别的应用的相同用户的交互历史来预测与给定通知的用户参与。

技术还可以使用强化学习，该强化学习对机器进行训练以做出特定决策，例如，选择用户特定的交互概率。在强化学习中，机器使用历史数据通过试验和错误来训练自己。例如，在强化学习中，机器会因做出正确的决策而得到奖励，并且因做出错误的决策而受到惩罚。经强化的学习机器做出决策，并且然后对奖励/惩罚进行评估以使奖励最大化，并且基于该信息来更新特征的先验条件。然后，经强化的学习机器做出下一个决策。

尽管可以使用不同的机器学习过程(包括用于不同通知类型或数据环境的不同过程)，但是这些机器学习过程全部使用历史通知事件数据和当前上下文数据。

重新评分触发266检测使得通知队列268中的通知被重新评分的触发的发生。通过计算新的用户特定的交互概率，可以在随后的时间点重新评估通知队列268中的通知。概率可以随着上下文的改变而改变。在第一次计算时具有低概率的通知可以在下次进行计算时具有大于阈值的新的概率。

各种触发可以使得针对通知队列268中的一个或多个通知计算新的概率。触发可以包括接收针对评估的新的通知。触发可以包括自上次计算以来经过阈值时间量。触发可以基于改变的上下文，例如，到达新位置、结束会议、结束呼叫、打开新应用、关闭应用以及其他因素。在一方面，以规则的间隔评估上下文信息，并且将该上下文信息与触发标准进行比较。

通知队列268存储尚未被呈现给用户的通知。具有低于阈值的用户特定的交互概率的通知将保持在通知队列268中。通过计算新的用户特定的交互概率，可以在随后的时间点重新评估队列中的通知。概率可以随着上下文的改变而改变。在第一次计算时具有低概率的通知可以在下次进行计算时具有大于阈值的新的概率。

示例系统200还包括呈现组件218，该呈现组件218通常负责基于由通知代理260确定的通知内容而向用户呈现通知和相关内容。呈现组件218可以包括在用户设备上、跨多个用户设备或在云中的一个或多个应用或服务。例如，在一方面，呈现组件218管理跨与该用户相关联的多个用户设备向用户呈现通知内容。

在一些方面，呈现组件218生成与通知相关联的用户接口特征。这种功能可以包括接口元素(例如，图形按钮、滑块、菜单、音频提示、提醒、警报、振动、弹出窗口、通知栏或状态栏项目、应用内通知或用于与用户对接的其他类似特征)、查询和提示。

如先前所描述的，在一些方面，结合呈现组件218操作的个人助理服务或应用确定何时以及如何呈现通知。在这些方面，通知内容可以被理解为针对何时以及如何呈现通知对呈现组件218(和/或个人助理服务或应用)的推荐，该通知内容可以由个人助理应用或呈现组件218覆写。

示例系统200还包括存储装置225。存储装置225通常存储包括在本文描述的技术的方面使用的数据、计算机指令(例如，软件程序指令、例程或服务)和/或模型的信息。在一方面，存储装置225包括数据存储(或计算机数据存储器)。此外，尽管被描绘为单个数据存储组件，但是存储装置225可以体现为一个或多个数据存储，或者可以在云中。

在一方面，存储装置225存储一个或多个用户简档240，在图2中说明性地提供了用户简档240的示例方面。示例用户简档240可以包括与特定用户或者在某些实例中与用户的类别相关联的信息。如所示的，用户简档240包括(多个)事件数据242、语义数据243、(多个)用户帐户和活动数据248以及(多个)未决通知250。用户简档240中存储的信息可以对示例系统200的例程或其他组件是可用的。语义数据243可以包括关于用户的信息，例如，家庭地址、家庭关系、工作关系和其他简档信息。

具体地，(多个)用户帐户和活动数据248可以包括关于下列各项的数据：用户电子邮件、文本、即时消息、呼叫和其他通信；社交网络帐户和数据，例如，新闻推送；在线活动；日历、预约或可能与确定未解决的事件相关的其他用户数据；用户可用性；以及重要性、紧迫性或通知逻辑。(多个)用户帐户和活动数据248的方面可以跨一个或多个数据库、知识图或数据结构来存储信息。

(多个)通知250通常包括关于与用户相关联的未决通知的数据，该数据可以包括与一个或多个未解决的事件相对应的通知内容。在一些方面，(多个)通知250包括与尚未被呈现给用户的通知或可能没有提供给用户的补充内容相对应的数据(此外，在一些方面，(多个)通知250还可以包括关于先前的未决通知的信息)。

现在转到图3，提供了通知代理的示例。最初，多个通知305由通知代理260接收。可以从客户端设备、服务或某些其他源上驻留的应用接收通知。如先前所描述的，通知代理260将通知概率指派给多个通知305中的每个通知。具有小于阈值的概率的通知存储在通知队列268中。如可以看出的，第一通知305A、第二通知305B和第N通知305C存储在通知队列268中。这些通知可以在发生重新评分触发时进行重新评估。

具有高于阈值概率的通知被传送到呈现组件218。呈现组件218根据通知的参数和任何通知逻辑来输出通知。在该示例中，在客户端显示设备310上提供弹出通知320。要求用户通过选择批准325或拒绝327来与通知进行交互。用户选择任一选项将是与通知进行直接交互的示例。一些通知不寻求直接交互，但是用户仍然可以解除该通知，选择该通知以打开相关应用，或者以其他方式直接与该通知进行交互。

现在转到图4，提供了示出用于提供用户个性化的通知管理的一种示例方法400的流程图。方法400以及本文描述的其他方法的每个框或步骤包括可以使用硬件、固件和/或软件的任何组合来执行的计算过程。例如，各种功能可以由执行存储在存储器中的指令的处理器来执行。该方法还可以体现为存储在计算机存储介质上的计算机可用指令。该方法可以由独立应用程序、服务或托管服务(独立的托管服务或与另一托管服务组合)或另一产品的插件(仅举几例)提供。

在步骤410处，在用于客户端设备的通知代理处从与客户端设备的用户相关联的多个应用接收多个通知。通知可以指定用于通知的一种或多种格式(即，可以如何向用户提供(多个)通知)以及通知呈现的时间。例如，日历应用可以将15分钟的警告通知传送给通知代理，从而指定用于呈现的时间。通知可以指定用于通信的信道，例如，锁屏信道、可听信道等。通知可以包括指定在不同电话状态下的不同信道的逻辑。例如，当电话处于睡眠模式时，信道可以是锁定屏幕，但是当电话在使用中时，信道可以是可听的。本文描述的技术的方面可以遵循信道指南，但是基于用户将响应于该通知的概率来确定何时或是否呈现该通知。

在步骤420处，访问描述用户的当前状态的上下文信息。上下文信息可以包括与用户活动相关联的上下文特征或变量，并且可以根据用户数据(或传感器数据)或根据用户数据确定的模式信息来确定。在一些方面，该上下文信息包括来自多个用户的用户数据。可以从与用户相关联的多个设备接收上下文信息。

在步骤430处，通过使用机器学习机制分析更新后的上下文数据，来计算针对通知中的每个通知的用户特定的交互概率，该机器学习机制是使用历史通知事件数据而被训练的。

在不同方面可以使用不同的机器学习过程，包括有监督学习过程(例如，决策树、随机森林、逻辑回归)、无监督学习(例如，先验算法、K均值)或强化学习。在每种情况下，上下文数据和通知描述是用于确定用户特定的交互概率的输入。本质上，用户特定的交互概率是在当前通知和上下文与用户和通知进行交互的先前通知事件之间类似性的测量。

这些机器学习方法中的每一个使用历史上下文数据、通知数据和交互数据来训练机器学习模型。如先前所描述的，可以将该数据收集为通知事件数据。在训练过程期间，不同类型的机器学习过程可以不同地使用历史数据。

有监督学习过程使用历史上下文数据和通知描述作为自变量，并且使用相关联的交互观察作为因变量。历史数据用于训练功能(不同的有监督学习过程可以使用不同的功能)，以将上下文数据和通知描述映射到输出。以这种方式，功能应该在给定类似的上下文数据和通知数据作为输入的情况下预测期望的结果(即，交互)。可以对上下文数据、交互数据和通知数据进行预处理，以适应可以用于在训练和使用两者期间向功能输入数据的模式。

一些学习方法通常试图基于类似特性来对人或物体进行聚类。这可能适合于经由从类似数据的推断而找到某种交互概率，例如，一个人可以以相同的方式与具有类似特性的通知进行交互。然后可以使用组特性(例如，系统通知、社交媒体通知)来确定用户将如何响应于来自尚未进行直接观察的实体的通知。学习方法可以使用上下文数据以将通知分类为类似于在类似的上下文中的其他通知。聚类可以帮助解决冷启动问题(没有与被评估的用户、应用或其他实体进行先前的交互)。例如，当将新用户添加到系统时，然后可以使用应用级特征和设备上下文特征而非用户特征来确定交互概率。设备当前可用的所有应用/服务的历史可以用于基于该应用/服务的所有用户与给定应用/服务的历史交互来预测新用户的交互。在评估新应用(而不是新用户)时，可以采取不同的方法。系统可以基于与相同类别的应用(例如，音乐应用、电子邮件应用)的所有用户先前的参与来对应用进行分类并预测通知参与。或者系统可以基于与相同类别的应用的相同用户的交互历史来预测与给定通知的用户参与。

技术还可以使用强化学习，该强化学习对机器进行训练以做出特定决策，例如，选择用户特定的交互概率。在强化学习中，机器使用历史数据通过试验和错误来训练自己。例如，在强化学习中，机器会因做出正确的决策而得到奖励，并且因做出错误的决策而受到惩罚。经强化的学习机器做出决策，并且然后对奖励/惩罚进行评估以使奖励最大化，并且基于该信息来更新特征的先验条件。然后，经强化的学习机器做出下一个决策。

尽管可以使用不同的机器学习过程(包括用于不同通知类型或数据环境的不同过程)，但是这些机器学习过程全部使用历史通知事件数据和当前上下文数据。

在步骤440处，确定来自多个通知的通知的第一集合超过阈值交互概率。该阈值可以被编辑地设置。在一方面，从包括50％、60％、75％和90％的组中选择阈值。

在步骤450处，确定多个通知中的通知的第二集合不超过阈值交互概率。

在步骤460处，通知队列中的通知的第二集合被保持，并且直到稍后的时间才呈现给用户(如果呈现的话)。具有低于阈值的用户特定的交互概率的通知将保持在通知队列中。通过计算新的用户特定的交互概率，可以在随后的时间点重新评估队列中的通知。概率可以随着上下文的改变而改变。在第一次计算时具有低概率的通知可以在下次进行计算时具有大于阈值的新的概率。

各种触发可以使得针对通知队列中的一个或多个通知计算新的概率。触发可以包括接收针对评估的新的通知。触发可以包括自上次计算以来经过阈值时间量。触发可以基于改变的上下文，例如，到达新位置、结束会议、结束呼叫、打开新应用、关闭应用以及其他因素。在一方面，以规则的间隔评估上下文信息，并且将该上下文信息与触发标准进行比较。

在步骤470处，通过客户端设备向用户输出通知的第一集合。步骤470的一些方面还包括生成与通知相关联的用户接口特征。这种功能可以包括接口元素(例如，图形按钮、滑块、菜单、音频提示、提醒、警报、振动、弹出窗口、通知栏或状态栏项目、应用内通知或用于与用户对接的其他类似特征)、查询或提示。在一些方面，捕获对通知的用户响应或与所呈现的通知相关联的用户活动，以用于改进提供给用户的通知管理服务。结合图2中的呈现组件218和通知代理260以及结合图3描述的示例，提供了关于在步骤470中呈现通知的附加细节。

在一些情况下，仅在满足通知逻辑之后才输出通知。通知逻辑可以指定规则、条件、约束、时间(包括未来的时间或时间窗口)、关于其他通知的优先级和/或用于向用户通知未解决的事件的其他参数、要包括在通知中的内容以及指定或推荐用于呈现(多个)通知的格式的逻辑。例如，通知逻辑可以限制在某个时间段(例如，一天)期间呈现给用户的通知的数量。

现在转到图5，提供了示出用于在客户端设备上代理通知的一种示例方法500的流程图。方法500以及本文描述的其他方法的每个框或步骤包括可以使用硬件、固件和/或软件的任何组合来执行的计算过程。例如，各种功能可以由执行存储在存储器中的指令的处理器来执行。该方法还可以体现为存储在计算机存储介质上的计算机可用指令。该方法可以由独立应用程序、服务或托管服务(独立的托管服务或与另一托管服务组合)或另一产品的插件(仅举几例)提供。

在步骤510处，通过向机器学习机制提供针对用户的历史通知事件信息，来训练该机器学习机制计算针对通知的用户特定的交互概率。该通知事件信息包括描述用户响应于先前的通知呈现而采取的动作的用户交互信息。

例如，如果机器学习机制是有监督学习方法，则该有监督学习过程使用历史上下文数据和通知描述作为自变量，并且使用相关联的交互观察作为因变量。历史数据用于训练功能(不同的有监督学习过程可以使用不同的功能)，以将上下文数据和通知描述映射到输出。以这种方式，功能应该在给定类似的上下文数据和通知数据作为输入的情况下预测期望的结果(即，交互)。可以对上下文数据、交互数据和通知数据进行预处理，以适应可以用于在训练和使用两者期间向功能输入数据的模式。

在步骤520处，在训练被执行之后，将机器学习机制的经训练的版本存储在计算机存储装置中。代理可以驻留在客户端设备上，在这种情况下，机器学习机制可以存储在客户端设备上。训练可以在数据中心中发生，并且经训练的模型可以被传输到客户端设备并且被存储以供以后使用。

在步骤530处，通过向机器学习机制提供新的通知并且呈现针对用户的上下文信息，来计算针对新的通知的用户特定的交互概率。如先前所描述的，机器学习机制取当前的上下文作为输入来计算概率。本质上，当用户与类似的通知进行交互时，将当前的上下文与先前的上下文进行比较以得出交互概率。

在步骤540处，确定针对新的通知的用户特定的交互概率低于阈值概率。

在步骤550处，将新的通知存储在包括尚未被呈现给用户的一个或多个通知的通知队列中。可以在发生触发时计算针对通知队列中的通知的新的用户特定的交互概率，如先前所描述的。

现在转到图6，提供了示出用于在客户端设备上代理通知的一种示例方法600的流程图。方法600以及本文描述的其他方法的每个框或步骤包括可以使用硬件、固件和/或软件的任何组合来执行的计算过程。例如，各种功能可以由执行存储在存储器中的指令的处理器来执行。该方法还可以体现为存储在计算机存储介质上的计算机可用指令。该方法可以由独立应用程序、服务或托管服务(独立的托管服务或与另一托管服务组合)或另一产品的插件(仅举几例)提供。

在步骤610处，在当前时间检测通知重新排序事件。该事件触发对针对尚未被输出到用户的通知的用户特定的交互概率的计算。通过计算新的用户特定的交互概率，可以在随后的时间点重新评估队列中的通知。概率可以随着上下文的改变而改变。在第一次计算时具有低概率的通知可以在下次进行计算时具有大于阈值的新的概率。

各种重新排序事件或触发可以使得针对通知队列中的一个或多个通知计算新的概率。触发可以包括接收针对评估的新的通知。触发可以包括自上次计算以来经过阈值时间量。触发可以基于改变的上下文，例如，到达新位置、结束会议、结束呼叫、打开新应用、关闭应用以及其他因素。在一方面，以规则的间隔评估上下文信息，并且将该上下文信息与触发标准进行比较。

在步骤620处，访问描述用户在当前时间的状态的上下文数据。上下文信息可以包括与用户活动相关联的上下文特征或变量，并且可以根据用户数据(或传感器数据)或根据用户数据确定的模式信息来确定。在一些方面，该上下文信息包括来自多个用户的用户数据。可以从与用户相关联的多个设备接收上下文信息。

在步骤630处，通过使用机器学习机制分析上下文数据，来计算针对第一通知的新的交互概率，该机器学习机制是使用历史通知事件数据而被训练的，如先前所描述的。

在步骤640处，确定新的交互概率超过了阈值交互概率，如先前所描述的。

在步骤650处，通过客户端设备向用户输出单独的通知，如先前所描述的。

参考图7，计算设备700包括直接或间接地耦合以下设备的总线710：存储器712、一个或多个处理器714、一个或多个呈现组件716、一个或多个输入/输出(I/O)端口718、一个或多个I/O组件720以及说明性电源722。总线710表示一条或多条总线可以是什么(例如，地址总线、数据总线或其组合)。尽管为了清楚起见，用线示出了图7的各个块，但实际上，这些块表示逻辑的且不一定是实际的组件。例如，可以认为呈现组件(例如，显示设备)是I/O组件。而且，处理器具有存储器。本发明人认识到这是本领域的性质并且重申：图7的图示仅说明可以结合本技术的一个或多个方面使用的示例性计算设备。在如“工作站”、“服务器”、“膝上型计算机”、“手持设备”等之类的这种类别之间不进行区分，因为设想这些类别都在图7的范围内并且被称为“计算设备”。

计算设备700典型地包括各种计算机可读介质。计算机可读介质可以是可以由计算设备700访问的任何可用介质，并且包括易失性和非易失性介质、可移除和不可移除介质两者。通过示例而非限制的方式，计算机可读介质可以包括计算机存储介质和通信介质。

计算机存储介质包括以任何方法或技术实现的、用于存储诸如计算机可读指令、数据结构、程序模块或其他数据之类的信息的易失性和非易失性介质、可移除和不可移除介质两者。计算机存储介质包括但不限于：RAM、ROM、EEPROM、闪速存储器或其他存储器技术、CD-ROM、数字通用盘(DVD)或其他光盘存储装置、磁带盒、磁带、磁盘存储装置或其他磁存储设备或者可以用于存储期望的信息并且可以由计算设备700访问的任何其他介质。计算机存储介质不包括信号本身。

通信介质典型地体现为计算机可读指令、数据结构、程序模块或调制数据信号(例如，载波)或其他传输机制中的其他数据并且包括任何信息递送介质。术语“调制数据信号”意味着这样的信号：该信号具有其特性集合中的一个或多个特性或者以对信号中的信息进行编码的方式改变。通过示例而非限制的方式，通信介质包括诸如有线网络或直接有线连接之类的有线介质，以及诸如声学、RF、红外和其他无线介质之类的无线介质。上述各项中任一项的组合也应该包括在计算机可读介质的范围内。

存储器712包括以易失性和/或非易失性存储器形式的计算机存储介质。存储器可以是可移除的、不可移除的或其组合。示例性硬件设备包括固态存储器、硬盘驱动器、光盘驱动器等。计算设备700包括从诸如存储器712或I/O组件720之类的各个实体读取数据的一个或多个处理器714。(多个)呈现组件716向用户或其他设备呈现数据指示。示例性呈现组件包括显示设备、扬声器、打印组件、振动组件等。

I/O端口918允许计算设备900逻辑地耦合到包括I/O组件920的其他设备，这些设备中的一些设备可以是内置的。说明性组件包括麦克风、操纵杆、游戏手柄、碟形卫星天线、扫描仪、打印机、无线设备等。

I/O组件720可以提供自然用户接口(NUI)，该NUIU处理由用户生成的空中手势、语音或其他生理输入。在一些实例中，输入可以发送到合适的网络元件以用于进一步处理。NUI可以实现下列各项的任何组合：语音识别、触摸和手写笔识别、面部识别、生物计量识别、在屏幕上以及邻近屏幕的手势识别、空中手势、头部和眼睛跟踪以及与计算设备700上的显示相关联的触摸识别。计算设备700可以配备有深度相机(例如，立体相机系统、红外相机系统、RGB相机系统以及其组合)以用于手势检测和识别。另外地，计算设备700可以配备有实现对运动的检测的加速计或陀螺仪。加速计或陀螺仪的输出可以提供给计算设备700的显示器，以呈现融入式增强现实或虚拟现实。

计算设备700的一些方面可以包括一个或多个无线电724(或类似的无线通信组件)。无线电724发送并接收无线电或无线通信。计算设备700可以是适于通过各种无线网络来接收通信和介质的无线终端。计算设备700可以经由诸如码分多址(“CDMA”)、全球移动系统(“GSM”)或时分多址(“TDMA”)以及其他无线协议之类的无线协议来进行通信，以与其他设备通信。无线电通信可以是短程连接、远程连接，或者短程和远程无线电信连接两者的组合。当提及“短”和“远”连接类型时，不意味着指代两个设备之间的空间关系。相反，通常将短程和远程称为连接的不同类别或类型(即，主要连接和次要连接)。通过示例而非限制的方式，短程连接可以包括到设备(例如，移动热点)的连接，该设备提供对无线通信网络的访问(例如，使用802.11协议的WLAN连接)；到另一计算设备的蓝牙连接或者近场通信连接是短程连接的第二示例。通过示例而非限制的方式，远程连接可以包括使用CDMA、GPRS、GSM、TDMA和802.16协议中的一个或多个的连接。

在不脱离所附权利要求书的范围的情况下，所描绘的各个组件以及未示出的组件的许多不同布置是可能的。已经利用说明性而非限制性的意图对本技术的一些方面进行了描述。在阅读本公开之后以及由于阅读了本公开，替代方面将对本公开的读者变得显而易见。在不脱离所附权利要求书的范围的情况下，可以完成实现前述内容的替代手段。某些特征和子组合是有用的，并且可以在不参考其他特征和子组合的情况下采用，并且设想这些特征和子组合在权利要求书的范围内。

Claims (13)

1.一种用于在客户端设备上代理通知的方法，包括：

在用于客户端设备的通知代理处从与所述客户端设备的用户相关联的多个应用接收多个通知；

访问描述所述用户的当前状态的上下文数据；

将所述上下文数据传送到机器学习机制，所述机器学习机制是使用历史通知事件数据作为训练数据而训练的，其中，所述训练数据包括作为因变量的检测到的与所呈现的通知的用户交互、以及作为自变量的所呈现的通知的通知特性；

通过分析所述上下文数据，使用所述机器学习机制来计算针对所述多个通知中的每个通知的用户特定的交互概率，其中，当在所述通知代理处从所述多个应用接收到所述多个通知时，所述多个通知具有指定的通知信道，并且其中，通知的个体信道是由所述机器学习机制使用以计算所述用户特定的交互概率的输入；

确定所述多个通知中的通知的第一集合超过阈值交互概率；

确定所述多个通知中的通知的第二集合不超过所述阈值交互概率；

将所述通知的第二集合保持在通知队列中；

通过所述客户端设备向所述用户输出所述通知的第一集合；

检测重新排序事件，所述重新排序事件包括所述用户被安排参加的会议的结束；

访问描述所述用户的更新后的状态的更新后的上下文数据；

通过分析所述更新后的上下文数据，根据被保持在所述通知队列中的所述通知的第二集合来计算针对通知的新的交互概率；

根据所述通知的第二集合来确定通知的第三集合超过所述阈值交互概率；以及

通过所述客户端设备向所述用户输出所述通知的第三集合。

2.根据权利要求1所述的方法，其中，所述历史通知事件数据描述了所述用户与被传送给所述用户的通知的交互。

3.根据权利要求1所述的方法，其中，所述历史通知事件数据描述了多个用户与被传送给所述多个用户的通知的交互。

4.根据权利要求1所述的方法，还包括：在所述输出之前，确定在所述通知的第一集合中的通知量在一段时间段内小于阈值通知限制。

5.根据权利要求1所述的方法，其中，所述重新排序事件还包括在所述通知代理处接收新的通知。

6.根据权利要求1所述的方法，其中，所述重新排序事件还包括在所述输出之后经过的指定的时间量。

7.根据权利要求1所述的方法，还包括：

使用所述训练数据训练所述机器学习机制，以计算针对所述通知的所述用户特定的交互概率；以及

在进行所述训练后，将所述机器学习机制存储在计算机存储装置中。

8.一种用于在客户端设备上代理通知的方法，包括：

通过向机器学习机制提供针对用户的历史通知事件数据作为训练数据，来训练所述机器学习机制计算针对通知的用户特定的交互概率，其中，所述训练数据包括作为因变量的检测到的与所呈现的通知的用户交互、以及作为自变量的所呈现的通知的通知特性，其中，所述历史通知事件数据包括描述所述用户响应于先前的通知呈现而采取的动作的用户交互信息，其中，与在所述客户端设备上呈现的通知的用户交互是基于所述用户在与所述用户相关联的第二计算设备上采取与所述通知相关的动作而发生的；

在所述训练被执行之后，将所述机器学习机制的经训练的版本存储在计算机存储装置中；

向所述机器学习机制提供针对所述用户的新的通知和当前的上下文信息；

从所述机器学习机制接收针对所述新的通知的用户特定的交互概率，所述用户特定的交互概率是使用所述新的通知和所述当前的上下文信息作为输入而确定的；

确定针对所述新的通知的用户特定的交互概率高于阈值交互概率；

通过所述客户端设备上的用户界面输出所述新的通知；

检测重新排序事件，其包括检测重新定位事件；

访问描述所述用户的更新后的状态的更新后的上下文数据；

通过分析所述更新后的上下文数据来计算针对所述新的通知的新的交互概率；

确定针对所述新的通知的用户特定的新的交互概率超过所述阈值交互概率；以及

通过所述客户端设备向所述用户输出所述新的通知。

9.根据权利要求8所述的方法，其中，所述历史通知事件数据还描述了多个用户与被传送给所述多个用户的通知的交互。

10.根据权利要求8所述的方法，其中，所述阈值交互概率特定于第一通知信道，并且第二通知信道与不同的阈值交互概率相关联。

11.根据权利要求8所述的方法，其中，所述重新排序事件还包括接收附加的通知。

12.根据权利要求8所述的方法，其中，所述重新排序事件还包括所述用户被安排参加的会议的结束。

13.一种或多种计算机存储介质，其包括指令，当由计算设备执行时，所述指令使得所述计算设备执行根据权利要求8-12中的任一项所述的方法。