CN107683486A - 用户事件的具有个人影响性的改变 - Google Patents

Abstract

在一些实现中，传感器提供反映由所述传感器检测的用户活动的传感器数据。事件分析器基于惯例相关方面为对与用户相关联的事件的改变而生成影响得分，所述惯例相关方面由与用户相关联的一个或多个用户惯例模型生成。一个或多个用户惯例模型至少部分基于包括传感器数据的交互数据而被训练。影响得分可以通过关于惯例相关方面分析事件属性来生成。基于确定由改变引起的在一个或多个事件属性与惯例相关方面之间的偏差水平的差异，以及基于事件的时间与参考时间的比较，来生成影响得分。影响得分可以用于确定对事件的哪些改变对于用户来说是重要的。

Description

用户事件的具有个人影响性的改变

背景技术

自动日历软件可以采用电子邮件或其他机制来邀请一个或多个用户参加事件或会议。更为传统的示例包括和Lotus然而，基于云的服务和/或集成到手机中的服务可以作为较新的示例。活动或会议的示例包括传统的面对面会议、电话会议、视频会议和在线群聊。在一些情况下，为了安排会议，组织者可以使用服务来向一个或多个被邀请者发送邀请。邀请通常指示一个或多个事件属性，诸如会议的日期和时间、会议的位置、会议是否重复发生或会议将何时重复发生以及评论，该一个或多个事件属性可以由组织者设置。该服务通常跟踪被邀请者的回复，诸如被邀请者接受、拒绝、暂时接受还是提出新的时间。基于响应，服务可以诸如通过维护事件的参加者(例如，计划参加者)列表来更新或设置一个或多个事件属性。此外，服务可以自动地将会议作为日历事件或条目添加到每个用户的个人日历中。用户可以使用一个或多个安排服务来规划和/或接收很多不同事件的邀请，并且可以在其日历中具有很多条目。

通常，事件的一个或多个事件属性可以在由原始组织者或另一用户初始设置之后，由一个或多个用户修改(属性可以被添加、改变或移除)。某些改变可能造成威胁，打乱事件计划参加者中一些计划参加者的生活。然而，对于其他参加者而言，这些改变可能更为重要，并且他们可以在事件发生之前花些时间调整计划或根据该改变为事件做好准备。作为一个示例，当事件的安排位置改变时，某些参加者可能需要调整他们的旅行安排以便参加事件。然而，一些用户可能并未注意到这些重大的改变，使他们无法做好准备，或者可能在没有足够的时间来调整改变时才注意到。这会导致需要用户经常检查其事件的更新，以便被通知到，从而可能消耗用户设备的电池寿命以及消耗服务器资源和带宽。而且，重要的改变可能被埋没在不重要的改变中，从而造成用户因需要延长的时间来选择重要的改变而消耗大量的这些资源。

发明内容

提供本“发明内容”以便以简化的形式来介绍一些精选概念，这些概念将在下面的“具体实施方式”中进一步描述。本发明内容并非旨在识别所要求保护的主题的关键特征或基本特征，也非旨在孤立地用于帮助确定所要求保护的主题的范围。

本公开的实现针对的是用于检测对用户具有个人影响的用户计划事件的改变的系统和方法。事件的改变可以对应于关于事件的一个或多个事件属性的改变，包括添加、移除或修改事件属性。在各种实现中，基于由改变而引起的事件对于用户的异常性的差异，结合用户被通知该改变的紧急性，来量化事件的改变对于用户的影响。可以使用事件的改变的影响，来确定是否向用户通知改变，和/或何时向用户通知改变。在这样做时，可以使事件的具有显著影响的改变被用户注意到，从而使得能够以适当方式向用户自动地通知这些改变。因此，用户可以有时间适当地为改变做好准备以减少其经常具有破坏性的性质，而无需必手动搜索和监测事件的更新。

在某些方面中，事件的异常性可以关于用户生活的各种习惯方面而被评估，以便指示事件在何种程度上打破或符合用户惯例。因此，由事件的改变而引起的事件的异常性的差异可以指示事件打破或符合用户惯例的程度的改变。

在一些情况下，各种因素可以被并入事件的整体异常性。每个因素可以代表关于事件的异常性的相应方面，并且可以组合以量化事件的整体异常性。例如，每个因素可以对应于事件的一组事件属性(一个或多个)与用户的一组惯例相关方面(一个或多个)之间的偏差的相应水平。示例性因素包括基于通勤的因素、基于睡眠的因素、基于位置或地点的访问因素、以及基于亲密度的因素。

在各种实现中，可以关于这些因素中的一个或多个和/或关于事件的总体异常性，来评估事件的改变的影响。因此，系统可以潜在地访问关于事件的各个事件属性和/或其组合的改变的影响。因此，在一些情况下，系统可以确定事件的哪些改变方面具有足够的影响性，从而需要引起用户的注意。

附图说明

以下参考附图来详细描述本发明的各方面，在附图中：

图1是适于实现本发明的各方面的示例操作环境的框图；

图2是示出适于实现本发明的各方面的示例计算架构的视图；

图3是示出适于实现本发明的各方面的示例计算架构的视图；

图4A示出了根据本发明的各方面的向用户显示的示例性服务内容；

图4B示出了根据本发明的各方面的向用户显示的示例性服务内容；

图5示出了根据本发明的实现的方法的流程图；

图6示出了根据本发明的实现的方法的流程图；

图7示出了根据本发明的实现的方法的流程图；以及

图8是适于实现本发明的实现的示例性计算环境的框图。

具体实施方式

在本公开中对本发明的各方面的主题进行具体描述，以满足法定要求。然而，描述本身并非旨在限制该专利的范围。相反，发明人已经预期到，所要求保护的主题也可以以其他方式来实施，以便结合其他现有技术或未来技术来包括与本文中所描述的那些步骤不同的步骤或这些步骤的组合。此外，虽然术语“步骤”和/或“块”在本公开中可以用于表示所采用的方法的不同元件，但是这些术语不应当被解释为暗示在本公开中公开的各个步骤之间的任何特定顺序，除非和除了明确地描述了各个步骤的顺序。

本公开中描述的技术的各个方面通常涉及系统、方法和计算机存储介质，其用于除了其他以外还至少部分基于反映由一个或多个传感器检测的用户活动的传感器数据(“交互数据”)，使用用于用户的惯例模型来推理与特定用户的行为模式或惯例相关方面。如本公开中使用的，“用户惯例模型”是一种概率机器学习结构，其通过根据定义惯例相关特征之间或者惯例相关特征与惯例相关推理之间的逻辑关系的规则、框架或机器学习算法(“惯例相关逻辑”)对特征、属性或变量(“惯例相关特征”)进行评估，来推理或预测与特定用户的行为模式相关联的惯例相关方面(“惯例相关方面”)。在一些实现中，惯例相关逻辑进一步定义用于确定与惯例相关推理(诸如置信度得分、方差度量、中心趋势值、概率分布函数等)相关联的各种度量、得分或值的过程、处理或操作。

本公开中所使用的“惯例相关推理”描述了提供对特定用户的行为模式的附加洞察的推理、估计或近似。因此，惯例相关推理使得能够识别更加接近地反映特定用户的行为在未来的时间可能会是什么的一个或多个惯例相关方面。通过使用与先前感测交互数据相关联的数据而被训练的用户惯例模型，评估(或分析)从与当前感测交互数据相关联的数据中导出的一个或多个惯例相关特征，来确定惯例相关推理。在一些实现中，惯例相关推理被用于生成或更新与特定用户相关联的惯例相关简档，以便提供针对特定用户的行为模式而被个性化的时间敏感推荐。

术语“服务”在本公开中被广泛地使用，以指代可以被实现为一个或多个计算机应用、服务或例程(诸如在移动设备或云上运行的app等)的几乎任何应用或自动化技术，如本公开中进一步描述的那样。类似地，术语“推荐”在本公开中广泛地使用，以指代由服务提供的任何推荐、特征、动作、操作、通知、功能和/或其他实用程序。术语“逻辑”包括用于执行任务的任何物理和有形功能。例如，流程图中所示的每个操作可以对应于用于执行该操作的逻辑部件。操作可以使用例如在计算机设备上运行的软件、硬件(例如，芯片实现的逻辑功能)等和/或其任何组合来执行。当由计算设备实现时，逻辑部件表示而是作为计算系统的物理部分被实现的电气部件。

本公开的实现针对的是用于检测对用户具有个人影响的用户事件的改变的系统和方法。事件的改变可以对应于事件的一个或多个事件属性的改变，包括添加、移除或修改事件属性。在各种实现中，基于由改变而引起的事件对于用户的异常性的差异，结合用户被通知该改变的紧急性，来量化事件的改变对用户的影响。可以针对用户日常生活中什么是惯常和期望的情况来评估异常。因此，当事件的一个或多个方面变得或多或少异常时，用户对事件的期望可能改变。在本公开的各个方面中，这些改变期望的概念与事件的改变对于用户的紧急性的概念相关联。以这种方式，可以确定并且向用户呈现事件的最重要改变，和/或可以确定向用户呈现改变的适当方式或时间。

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

在未示出的其他部件中，示例操作环境100包括多个用户设备，诸如用户设备102a和102b至102n；多个数据源，诸如数据源104a和104b至104n；服务器106；和网络110。应当理解，图1所示的操作环境100是一个适合的操作环境的示例。例如，图1所示的每个部件可以经由诸如结合图8描述的计算设备800等任何类型的计算设备来实现。这些部件可以经由网络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可以是本公开中关于图8所描述的类型的计算设备。作为示例而并非限制，用户设备可以被实现为个人计算机(PC)、膝上型计算机、移动装置或移动设备、智能电话、平板计算机、智能手表、可穿戴计算机、个人数字助理(PDA)、MP3播放器、全球定位系统(GPS)或设备、视频播放器、手持通信设备、游戏设备或系统、娱乐系统、车载计算机系统、嵌入式系统控制器、遥控器、家电、消费电子设备、工作站或这些示出设备的任何组合、或任何其他适合设备。

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

操作环境100可以与适于实现本发明的实施例并且总体上被指示为系统200的图2所示示例性计算系统架构的部件一起使用。系统200仅表示适于实现本发明的各方面的示例性计算系统。除了所示出的那些或作为其替代，可以使用其他布置和元件，并且为了清楚起见，可以完全省略一些元件。此外，与操作环境100一样，本公开中描述的很多元件是可以被实现为分立或分布式部件或者与其他部件结合实现并且以任何适合组合和位置来实现的功能实体。在未示出的其他部件中，系统200通常包括用于基于交互数据来推理特定用户的惯例相关方面的部件。系统200包括诸如数据收集部件215、存储装置220、惯例模型引擎240、惯例推理引擎250和推荐引擎260等的部件，所有这些部件都经由网络110而通信地耦合。

在一些实现中，由系统200的部件执行的功能与一个或多个个人助理应用、服务或例程相关联。特别地，这样的应用、服务或例程可以在一个或多个用户设备(诸如用户设备102a)上操作，服务器(诸如服务器106)可以分布在一个或多个用户设备和服务器上，或者在云上实现。此外，在一些实现中，系统200的这些部件可以分布在包括云中的一个或多个服务器(诸如服务器106)和客户端设备(诸如用户设备102a)的网络上，或者可以驻留在诸如用户设备102a等的用户设备上。与操作环境100一样，本公开中描述的一些部件可以被实现为一组编译的计算机指令、计算机函数、程序模块、计算机软件服务、或者在诸如结合图8描述的计算设备800等的一个或多个计算机系统上执行的处理的布置。

例如，这些部件、由这些部件执行的功能、或由这些部件执行的服务可以在计算系统的适当的抽象层(诸如操作系统层、应用层、硬件层等)上实现。替代地或另外地，这些部件的功能和/或本公开中描述的本发明的实现可以至少部分地由一个或多个硬件逻辑部件来执行。可以使用的示例性类型的硬件逻辑部件包括现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)复杂可编程逻辑器件(CPLD)等。另外，尽管本公开中针对示例系统200中所示的特定部件来描述功能，但是可以预期，在一些实现中，这些部件的功能可以在其他部件上共享或分布。

数据收集部件215通常负责从诸如图1的数据源104a和104b至104n等一个或多个数据源来获取、访问或接收(并且在一些情况下也识别)交互数据。例如，可以从与一个用户相关联或在一些情况下与多个用户相关联的多个用户设备(诸如图1的用户设备102a和102b到102n)接收交互数据。以这种方式，可以接收来自用户所使用的多个用户设备(例如，用户的移动电话、笔记本电脑、平板电脑等)的特定用户的用户活动以作为交互数据。交互数据可以由数据收集部件215接收、获取或访问，并且可选地累积、重新编排格式和/或组合，并且存储在诸如存储装置220等一个或多个数据存储器中。例如，交互数据可以存储在用户简档230中或与用户简档230相关联，如本公开中描述的。因此，一个或多个数据存储器可以可用于惯例模型引擎240、惯例推理引擎250和推荐引擎260。在一些实现中，数据收集部件215被配置为针对单个用户累积反映由一个或多个传感器检测的用户活动的交互数据(“源于个人的交互数据”)。在一些实现中，数据收集部件215被配置为针对多个用户累积与用户来源交互相关联的交互数据(“源于众人的交互数据”)。在一些实现中，任何个人标识数据(即，特别标识特定用户的交互数据)并非是从具有交互数据的一个或多个数据源上传的，没有被永久地存储，和/或不可用于惯例模型引擎240、惯例推理引擎250和/或推荐引擎260。

交互数据可以从各种来源接收，其中数据可以以各种格式可用。例如，在一些实现中，由数据收集部件215累积的用户数据经由与用户设备(诸如用户设备102a和/或与用户相关联的其他设备)、服务器(诸如服务器106)、和/或其他计算设备相关联的一个或多个传感器来接收。如本公开中使用的，传感器可以包括用于感测、检测或以其他方式从数据源(例如，图1的数据源104a)获得诸如用户数据等信息的函数、例程、部件或其组合，并且可以被实施为硬件、软件或两者。

作为示例而并非限制，用户数据可以包括从一个或多个传感器感测或确定的数据(本公开中被称为“传感器数据”)，诸如移动设备的位置信息、智能电话数据(诸如电话状态、收费数据、日期/时间、或从智能手机得到的其他信息)、包括在多于一个用户设备上发生的用户活动的用户活动信息(例如：app使用情况；在线活动；搜索；诸如自动语音识别等的语音数据；活动日志；包括呼叫、文本、即时消息和电子邮件的通信数据；网站帖子；与通信事件相关联的其他用户数据；等等)、用户历史、会话日志、应用数据、联系人数据、日历和时间表数据、通知数据、社交网络数据、新闻(包括搜索引擎或社交网络上的流行或趋势项目)、在线游戏数据、电子商务活动(包括来自诸如帐户、或Xbox等在线帐户的数据)、用户帐户数据(其可以包括来自与个人助理应用或服务相关的用户偏好或设置的数据)、家庭传感器数据、电器数据、全球定位系统(GPS)数据、车辆信号数据、交通数据、天气数据(包括预报)、可穿戴设备数据、其他用户设备数据(其可以包括例如设备设置、简档、诸如Wi-Fi网络数据或配置数据等网络连接、关于型号、固件或设备的数据、设备配对，诸如在用户具有与蓝牙耳机配对的移动电话时)、陀螺仪数据、加速计数据、支付或信用卡使用数据(其可以包括来自用户的PayPal帐户的信息)、购买历史数据(诸如来自用户的Amazon.com或eBay帐户的信息)、可以由传感器(或其他检测器)部件感测或以其他方式检测的其他传感器数据(包括从与用户相关联的传感器部件得到的数据(包括位置、运动、方向、位置、用户访问、用户活动、网络访问、用户设备充电、或能够由一个或多个传感器部件提供的其他数据))、基于其他数据导出的数据(例如，可以从Wi-Fi、蜂窝网络或IP地址数据导出的位置数据)、以及如本文描述可以被感测或确定的几乎任何其他数据源。

在某些方面中，可以在用户信号中提供用户数据。用户信号可以是来自相应数据源的用户数据的馈送。例如，用户信号可以来自智能电话、家庭传感器设备、GPS设备(例如，用于位置坐标)、车辆传感器设备、可穿戴设备、用户设备、陀螺仪传感器、加速度传感器、日历服务、电子邮件帐户、信用卡帐户或其他数据源。在一些实现中，数据收集部件215连续地、周期性地或根据需要接收或访问数据。

通常，存储装置220被配置为存储在本公开中描述的本发明的实现中所使用的计算机指令(例如，软件程序指令、例程或服务)和/或模型。在一些实现中，存储装置220还存储经由系统200的各种部件接收的信息或数据，并且向系统200的各个部件提供对该信息或数据的访问。例如，存储装置220可以存储这样的信息或数据以作为交互数据、与关于数据收集部件215所描述的任何用户数据相关联的描述信息、交互数据、推理数据、交互数据集、源于众人的数据集、源于个人的数据集、用户惯例模型、惯例相关推理、惯例相关简档、和一个或多个用户简档(例如，用户简档230)。在一种实现中，存储装置220包括数据存储器(或计算机数据存储器)。此外，尽管被示出为单个数据存储部件，但是存储装置220可以被实现为一个或多个数据存储器，或者可以位于云中。

示例性用户简档230包括与特定用户或者在一些实现中与一组或一种类别的用户相关联的信息。如图2所示，用户简档230包括诸如以下的信息：用户属性数据231、交互数据集233、用户惯例模型235和惯例相关简档237。存储在用户简档230中的信息可以可用于示例性系统200的其他部件。

用户属性数据231包括与特定用户相关联的任何特性、特征或属性。在一些实现中，用户属性数据231包括与人口统计数据、位置数据、职业数据、教育数据等相关的信息。例如，人口统计数据包括诸如年龄、性别、国籍、宗教信仰、种族等信息。作为另一示例，位置数据包括诸如以下用于特定用户的信息：当前物理位置、工作位置、家庭位置、预计的未来位置等。在一些实现中，类似位置数据可以可用于与特定用户相关联的一个或多个用户设备或者一个或多个个体(例如，朋友、家人等)。可以以各种方式从用户获取用户属性数据231。在一些实现中，由用户经由以下关于图8的计算设备800描述的任何输入设备将用户属性数据231提交给系统200(例如，以显示方式)。在一些实现中，用户属性数据231从以下信息编辑的：由用户作为向应用注册用户简档的部分而提交的用户数据；社交媒体简档构建；人口普查登记；等等。在一些实现中，用户属性数据231从与用户相关联的一个或多个报告来获取，诸如信用报告；背景报告；就业报告等等。

交互数据集233广泛地涉及使用与用于训练、测试和/或验证用户惯例模型235的先前感测交互数据相关联的任何数据来填充的任何数据集。在一些实现中，用户惯例模型235可以是被配置为通过评估与当前感测交互数据相关联的数据来确定惯例相关推理的机器学习的概率推理模型。惯例相关简档237可以包括针对特定用户的一个或多个惯例相关方面的信息。惯例相关简档237可以使用通过使用用户惯例模型235评估当前感测交互数据而确定的惯例相关推理来初始化和/或更新。作为示例，对于睡眠相关惯例，惯例相关方面可以包括特定用户的睡眠模式的以下方面中的一个或多个：就寝时间、睡醒时间、就寝时间范围、睡醒时间范围、睡眠持续时间等。惯例相关简档237的惯例相关方面可以根据任何已知的概率机器学习模型输出来表示。例如，惯例相关方面可以被表示为在中心趋势度量(例如，平均值、中值或模式)和方差度量(例如，范围、标准偏差或方差)方面来描述特定对象的统计分布。下面将针对惯例模型引擎240描述与交互数据集233、用户惯例模型235和惯例相关简档237相关的进一步的细节。

惯例模型引擎240通常被适配为与存储装置220协作来填充交互数据集233，并且使用这些交互数据集233来训练用户惯例模型235。由惯例模型引擎240训练的用户惯例模型235使得惯例推理引擎250能够推理(或预测)针对特定用户的惯例相关方面。如示例性系统200所示，惯例模型引擎240包括数据集预处理器241、交互数据集编译器243和惯例模型训练器245。

在源于众人的数据集被用来填充交互数据集233的实现中，数据集预处理器241可以被配置为使用用户属性数据231来创建用户属性过滤器。在这些实现中，在某种意义上，可以通过选择与特定用户更相关的先前感测交互数据以便用于训练用户惯例模型而针对特定用户预先定制用户惯例模型235。数据集预处理器241通过在用与交互数据集233相关联的先前感测交互数据来填充交互数据集233之前，对源于众人的数据集应用至少一个用户属性过滤器，来实现对用户惯例模型235的这样的预先定制。在一些实现中，用户属性过滤器是基于从与用户简档230相关联的用户属性数据231所获取的数据。在一些实现中，用户属性过滤器可以基于经由以下关于图8的计算设备800描述的任何输入设备而从用户获取的数据。

例如，用户位置过滤器可以被应用于源于众人的数据集，以排除在与特定用户相距预定距离范围之外的与用户相关联的先前感测交互数据。作为另一示例，用户人口统计过滤器可以应用于源于众人的数据集，以仅包括与下述用户相关联的先前感测交互数据，所述用户与特定用户具有共同的至少一个人口统计特性(例如，年龄、收入、文化身份、性别等)。在另一示例中，将用户职业过滤器被应用于源于众人的数据集，以仅包括与下述用户相关联的先前感测交互数据，所述用户与特定用户共同具有至少一个职业特性(例如，职业、行业、经验水平等)。

交互数据集编译器243被配置为使用从数据收集部件215、存储装置220和/或惯例推理引擎250接收的先前感测交互数据来填充、编译或构建交互数据集233。在一些实现中，交互数据集233用反映由一个或多个传感器检测的特定用户的活动的源于个人的数据被填充。在一些实现中，交互数据集233用反映由一个或多个传感器检测的多个用户的活动的源于众人的交互数据被填充。在一些实现中，交互数据集233用与先前感测交互数据相关联的描述数据被填充，诸如时间/日期戳、元数据标签、地理位置数据等。在一些实现中，交互数据集用解释数据被填充，如以下关于推理评估器253更详细地讨论的那样。

惯例模型训练器245的实现可以被配置为通过分析交互数据集233来训练用户惯例模型(例如，用户惯例模型235)，以识别惯例相关特征、惯例相关逻辑、以及在一些实现中的惯例相关权重。如以上讨论的那样，在一些实现中，用户惯例模型235包括被配置为通过评估与当前感测交互数据相关联的数据来确定惯例相关推理的机器学习概率推理模型。因此，用户惯例模型235可以提供本领域技术人员已知的任何机器学习技术来训练。

惯例相关特征可以由惯例模型训练器245基于结合数据收集部件215描述的用户数据、与这样的用户数据相关联的描述信息以及由推理评估器253提供的解释数据的任何组合来识别。在一些实现中，惯例相关特征通过惯例模型训练器245识别交互数据集233中的数据与特定用户的惯例之间的模式来识别。例如，惯例模型训练器245可以使用诸如相关门限(正或负)等预定统计门限来识别这样的模式。预定统计门限可以反映所标识的惯例相关特征之间的关系、或者惯例相关特征与特定用户的惯例的各个方面之间的关系。

在一些实现中，惯例相关特征利用用户信号，所述用户信号提供来自与用户相关联的数据源(例如，用户设备)的交互数据的馈送。在这些实现中，交互数据的馈送可以以任何粒度级别来提供，包括：连续地，周期性地(例如，每分钟、每5分钟、每小时、每2小时等)，或者在用户信号转换逻辑状态时(例如，从关闭到打开、从高到低等)。提供交互数据的馈送的用户信号可以从与客户端侧、服务器侧、在云中或其任何组中的应用或设备相关联的传感器来接收。

惯例模型训练器245还被配置为确定用于用户惯例模型的惯例相关逻辑，所述惯例相关逻辑将与交互数据相关联的数据映射到惯例相关特征并且定义了惯例相关特征之间和/或惯例相关特征与惯例相关推理之间的逻辑关系。在一些实现中，惯例相关逻辑还定义用于确定与惯例相关推理相关联的各种度量、得分或值的过程、处理或操作，所述度量、得分或值诸如是置信度得分、方差度量、中心趋势值、概率分布函数等。

在一些实现中，采用置信度得分来量化与惯例相关简档相关联的一个或多个惯例相关方面将如何准确地反映用户的惯例的置信度。在这些实现中，置信度得分可以与惯例相关简档总体、惯例相关简档的特定惯例相关方面、和/或与惯例相关简档的特定惯例相关方面相关联的一个或多个度量(例如，方差度量、中心趋势度量等)相关联。换言之，置信度得分是指示被预测的惯例相关方面与用户实际惯例一致的可能性的相关联概率或置信度。在一些实现中，服务在为用户提供时间敏感推荐时，以各种方式诸如门限，来使用置信度得分。

在使用惯例相关权重的实现中，惯例模型训练器245还可以被配置为向惯例关联特征分配至少一个惯例相关权重。惯例相关权重可以通过分析用于训练用户惯例模型235的交互数据集233来确定。惯例相关权重反映相应惯例相关特征在确定惯例相关推理(预测其可能性)时的相对统计重要性。这样的惯例相关权重可以由惯例模型训练器245向与用户惯例模型相关联的一个或多个惯例相关特征分配。

尽管图2将惯例模型引擎240示出为单独的部件，但是本领域技术人员将认识到，惯例模型引擎240或其任何子部件可以与诸如交互数据收集部件、分析工具、用户设备、web服务器等另一部件集成。在一些实现中，惯例模型引擎240被实现为惯例推理引擎250或类似地被设计为生成惯例相关简档的其他部件的一部分。在一些实现中，惯例模型引擎240被实现为网络服务器、混合硬件/软件部件的一部分，或者被实现为在传统个人计算机上运行的正在用于使用交互数据来推理用户睡眠模式的惯例相关方面的软件模块。

通常，惯例推理引擎250被配置为通过使用先前感测交互数据训练的用户惯例模型来分析当前感测交互数据，来推理惯例相关方面。如示例性系统200所示，惯例推理引擎250包括特征预处理器251、推理评估器253、数据分析部件255和异常值检测器257。

特征预处理器251被配置为映射与交互数据相关联的数据，以生成由惯例模型训练器245识别的惯例相关特征，以便由数据分析部件255分析。由特征预处理器251生成的惯例相关特征可以包括与本公开中讨论的交互数据相关联的任何数据。在一些实现中，特征预处理器251还被配置为将与交互数据相关联的数据转换成适当的格式，以便映射到惯例相关特征，如由惯例模型训练器245规定的那样。例如，与交互数据相关联的数据可以作为模拟数据或数字数据被接收，其被提供作为任何数目的数据类型，包括：矩阵；矢量；以及标量。在该示例中，特征预处理器251将这样的数据转换为相应惯例相关特征的适当格式，以便可由数据分析部件255使用。

在一些实现中，特征预处理器251可以将来自单个数据源的与当前感测交互数据相关联的数据映射到单个惯例相关特征。例如，特征预处理器251可以将来自在特定用户的智能电话上运行的闹钟应用的当前感测交互数据映射到单个惯例相关特征。在该示例中，惯例模型训练器245确定特定用户经常在睡醒之后不久便停用智能电话上的闹钟应用。

在一些实现中，特征预处理器251可以将来自多个数据源的与当前感测交互数据相关联的数据映射到单个惯例相关特征。例如，特征预处理器251可以将来自由特定用户正在与之交互的远程服务器所托管的新闻网站的和来自特定用户正在使用以与新闻网站交互的用户设备的当前感测交互数据映射到单个惯例相关特征。在该示例中，描述数据可以是与从用户设备接收的交互数据相关联的设备标识符的形式。在该示例中，惯例模型训练器245确定特定用户在临睡前在平板计算设备上阅读新闻网站上的新闻文章。而如果特定用户在早上准备上班的同时在智能手机上与新闻网站交互，则从同一新闻网站收集的交互数据不能用于推理特定用户的就寝时间。

推理评估器253可以被配置为从感测的交互数据中提取解释数据，并且将提取的解释数据提供给存储装置220以供系统200的其他部件使用。解释数据通常对应于下述任何信息，这些信息通过描述获取交互数据时在用户、设备和/或应用周围的环境来向由系统200利用的任何交互数据提供上下文。换言之，解释数据提供感测的交互数据的背景信息，背景信息使得与否则系统200不知道周围环境的情况下将可能的情况相比，系统200能够识别交互数据集233中的更多的模式。

解释数据的示例包括：当时执行的任务，诸如军事储备训练、导致用户早起慢跑的试图减轻体重；关于时间重要性的信息，诸如生日、节假日、周年纪念、一年中的季节、特别事件、假期、最近事件之间的关联；关于地理意义的信息，诸如工作地点/家庭位置、位置的改变(例如，从一个城市移动到另一城市，或从一个时区移动到另一时区)、度假目的地；或者向系统提供对感知交互数据周围环境的更高层次的了解的任何其他信息。

数据分析部件255通常被配置为在用户惯例模型中来针对惯例相关特征实施由惯例模型引擎240提供的惯例相关逻辑，所述惯例相关特征包括与来自特征预处理器251的交互数据相关联的数据。通过针对关于惯例相关特征实施惯例相关逻辑，数据分析部件255能够确定惯例相关推理以及与惯例相关推理相关联的各种度量、得分或统计信息，诸如置信度得分、方差度量、中心趋势值、概率分布函数等。与存储装置220协作，数据分析部件255还可以被配置为使用惯例相关推理以及从当前感测交互数据确定的与惯例相关推理相关联的各种度量、得分或统计信息，来更新(或初始化)与特定用户相关联的惯例相关简档。

异常值检测器257可以被配置为使用预定截止值来识别足以构成统计异常值的、偏离先前确定的惯例相关推理的惯例相关推理，(“异常值推理”)。例如，可以根据已知的统计异常检测方法建立预定截止值，诸如：基于模糊逻辑的异常值检测；基于聚类分析的异常值检测；基于密度的技术或任何其他已知的统计异常检测度量。在一些实现中，异常值检测器257使用预定截止值来将惯例相关推理与同特定惯例相关简档相关联的先前确定的惯例相关推理相比较。

在一些实现中，与惯例相关推理相关联的数据被异常值检测器257识别为统计异常值，并且被存储在本公开中被称为“异常值数据集”的交互数据集中。例如，这样的数据可以包括所确定的惯例相关推理、用于确定惯例相关推理的任何惯例相关特征、或者在确定该惯例相关推理的规定时间内获取的任何当前感测交互数据。在一些实现中，异常值数据集被用于根据本公开中所公开的任何实现来训练用户惯例模型。在这些实现中，可以使用异常值数据集来在训练用户惯例模型时代替并且替代交互数据集的部分和/或与交互数据集合并，这些用户惯例模型本公开中被称为“替代用户惯例模型”。在一些实现中，使用替代用户惯例模型确定的惯例相关推理被用于生成惯例相关简档(在本公开中被称为“替代惯例相关简档”)。在这些实现中，可以基于由惯例模型引擎240确定的用于训练其相应的替代用户惯例模型的数据集内的一些共性，使用替代简档标签来识别替代惯例相关简档。

例如，如果惯例模型引擎240确定用于训练替代用户惯例模型的异常值数据集包括与特定地理位置(例如，以色列、欧洲、墨西哥的度假屋等)相关联的交互数据。在该示例中，可以使用指定特定地理位置的替代简档标签，来识别利用使用该替代用户惯例模型确定的惯例相关推理所生成的替代惯例相关简档。因此，该示例的替代惯例相关简档可以包括特定于该特定地理位置的特定用户的惯例相关方面。例如，在墨西哥度假时，与在他们家里工作时相比特定用户可以醒来更早。

作为另一示例，惯例模型引擎240确定用于训练替代用户惯例模型的异常值数据集包括与特定时间段(例如，平日/周末、夏季/冬季、每个月的特定周末等)相关联的交互数据。在该示例中，可以使用指定特定时间段的替代简档标签，来标识利用使用该替代用户惯例模型确定的惯例相关推理所生成的替代惯例相关简档。因此，该示例的替代惯例相关简档可以包括特定于特定时间段的特定用户的惯例相关方面。例如，特定用户可能在军事储备单位中，这导致在与军事储备单位进行训练的当月的特定周末，与他们在家里进行周末放松时相比特定用户醒来更早。

推荐引擎260被配置为接收对于特定用户的惯例相关方面的请求，使用与特定用户相关联的惯例相关简档来识别所请求的惯例相关方面，并且将所标识的惯例相关方面提供给提交请求的应用、服务或设备。在一些实现中，推荐引擎260可以被实现为应用编程接口(“API”)。如图2所示，推荐引擎260包括客户端侧服务接口261、服务器侧服务接口263和基于云的服务接口265。

客户端侧服务接口261被配置为接收来自直接向特定用户提供时间敏感推荐的客户端侧推荐应用或服务的请求。作为示例，所接收的请求可以源自于在特定用户的智能电话上运行的应用，诸如个人助理应用或通信应用。在另一示例中，请求可以源自于通信地耦合到致动器的控制器，所述致动器与具有由特定用户使用的自动化能力的任何客户端侧设备、机器或电器相关联。

服务器侧服务接口263被配置为从可以被托管在向用户提供推荐的第三方设备上的服务器侧应用或服务接收请求。例如，所接收的请求可以源自于服务器，该服务器托管提供与社交媒体、交通、天气、新闻等相关的商业或信息服务的网站。在一些实现中，可以从与下述惯例推理引擎相关联的推荐引擎接收请求，所述惯例推理引擎与另一用户(例如，特定用户的家庭成员、朋友等)相关联。类似地，基于云的服务接口265被配置为从任何基于云的应用或服务接收请求。

可选地，特定用户的惯例相关方面的惯例相关的预测可以使用当前感测交互数据和使用先前感测交互数据训练的用户惯例模型来确定。交互数据集可以使用先前感测交互数据来填充。先前感测交互数据可以在其在存储的数据集中被积累之前，从交互数据收集部件(例如，图2的数据收集部件215)接收。在一些情况下，先前感测交互数据从存储的数据集中检索，存储的数据集包括关于数据收集部件215描述的任何交互数据。例如，存储的数据集可以包括来自个人数据集的与特定用户相关联的累积的先前感测交互数据。在另一示例中，存储的数据集可以包括来自源于众人的数据集的、与多个用户相关联的累积的先前感测交互数据。在另一示例中，存储的数据集可以包括来自个人数据集、源于众人的数据集或其组合的累积的先前感测交互数据。

在使用源于众人的数据集的实现中，可以在填充交互数据集之前，对从源于众人的数据集中检索到的先前感测交互数据执行预处理。这样的预处理可以包括噪声滤波、异常值数据的移除和/或丢失数据的处理。在使用源于众人的数据集的实现中，预处理可以包括基于用户属性(例如，图2的用户属性数据231)使用一个或多个过滤器来从源于众人的数据集中过滤先前感测交互数据。当被使用时，一个或多个过滤器将具有用户属性的从用户接收的先前感测交互数据，与不具有用户属性的从用户接收的先前感测交互数据分离。因此，可以在交互数据集中包括或从中排除过滤后的先前感测交互数据，以提供通常为了训练、测试和/或验证用户惯例模型而定制的先前感测交互数据。

可以使用填充的交互数据集来训练、测试和/或验证用户惯例模型。如以上讨论的，通过识别交互数据集中的一个或多个惯例相关特征，使用任何已知的机器学习技术来训练用户惯例模型。在一些实现中，通过利用初始值填充惯例相关简档，来生成针对特定用户的惯例相关简档，所述初始值使用填充的交互数据集中的先前感测交互数据来确定。在这些实现中，与这样的惯例相关简档相关联的置信度得分被赋予最小值(例如，0、1％、0.02等)。例如，可以通过用惯例相关方面的初始值填充惯例相关简档，来生成针对特定用户的惯例相关简档。或者，可以使用任何编号系统或其组合来向该示例中针对惯例相关方面的初始值分配置信度得分。

用户惯例模型包括惯例相关逻辑，其定义用于通过评估与当前感测交互数据相关联的数据来确定惯例相关推理的逻辑框架。在一些实现中，惯例相关逻辑包括以下概率规则类型中的一个或多个：预测规则、排序规则、聚类规则或分类规则。惯例相关逻辑通过以下方式定义逻辑框架：将与当前感测交互数据相关联的数据映射到一个或多个惯例相关特征中的每个；规定一个或多个惯例相关特征之间的关系以使用与当前感测交互数据相关联的数据来确定惯例相关推理；并且在一些实现中，向至少一个惯例相关特征分配惯例相关权重。基于特定惯例相关特征在确定惯例相关推理(例如，预测其可能性)时的相对重要性，来向特定的惯例相关特征分配惯例相关权重。因此，可以使用用户惯例模型以及所确定的其惯例相关推理，来生成或更新针对特定用户的惯例相关简档。

可以经由与用户设备相关联的一个或多个传感器来接收当前感测交互数据，并且可以通过根据与用户惯例模型相关联的惯例相关逻辑评估与该当前感测交互数据相关联的数据，来确定惯例相关推理。在实现中，与该当前感测交互数据相关联的数据包括以下之中的一个或多个：从传感器接收的原始交互数据、与原始交互数据相关联的描述信息、从原始交互数据和/或描述信息确定的推理数据、或其任何组合。如结合图2的惯例推理引擎250所讨论的那样，在实现中，取决于用于确定特定的惯例相关推理的惯例相关逻辑的类型，诸如自然分类标签、概率分布函数、预期结果、结果得分等，可以以各种格式来呈现惯例相关推理。

可以使用惯例相关推理来更新或初始化针对特定用户的惯例相关简档。在并未使用初始值来生成惯例相关简档的实现中，可以将惯例相关推理用作初始化值来初始化惯例相关简档。在通过使用初始值填充惯例相关简档来生成惯例相关简档的实现中，其中所述初始值使用填充的交互数据集中的先前感测交互数据来确定，可以使惯例相关推理可以与相应的初始值一致。在这些实现中，通过替换、平均、加权平均、内插、外插等，来使惯例相关推理与相应的初始值一致。在分配置信度得分的这些实现中，根据本公开中描述的任何实现，可以自先前值而增加置信度得分。

在接收到对于特定用户的一个或多个惯例相关方面的请求的情况下，可以为特定用户提供一个或多个惯例相关方面。响应于接收到该请求，可以使用与特定用户相关联的惯例相关简档来识别一个或多个惯例相关方面。惯例相关简档根据本公开中描述的任何实施例，诸如以上描述的那些实施例，使用交互数据来生成。生成惯例相关简档的进一步的细节与图2的惯例推理引擎250相关地提供。可以向提交请求的设备、应用或服务提供一个或多个惯例相关方面。

已经描述了根据本公开的一些实现的用于生成用户的惯例的惯例相关方面的可选架构和各种方法，图3是示出根据本公开的一些实现的适于分析用户的事件的示例性计算架构的视图。图3示出了事件分析器366，其被配置为基于用户的惯例的惯例相关方面和事件的事件属性来分析用户的一个或多个事件。通过关于惯例相关方面来分析用户的事件，事件分析器366可以访问关于用户日常生活中什么是惯常和预期的有效事件。

事件分析器366包括异常性分析器366A和紧急性分析器366B作为其子部件。尽管异常性分析器366A和紧急性分析器366B在图3中被示出为分立部件，但是其至少一些部分可以可选地在功能上集成。事件分析器366被配置为在异常性和紧急性方面分析事件的改变的影响。具体地，当对诸如事件382a等事件进行一个或多个改变时，事件分析器366利用异常性分析器366A来量化关于由改变引起的对用户的异常性的差异的改变的影响。通过这种方式，该影响可以指示哪些改变对于特定用户来说是整体重要且值得注意的。

事件分析器366利用紧急性分析器366B来量化向用户通知改变的紧急性，使得所述影响可以用于指示什么改变当前对于特定用户来说重要且值得注意的。因此，可以使用该影响，以使得可以确定并且向用户呈现事件的最重要的改变，和/或可以确定向用户呈现改变的适当方式或时间。

在一些实现中，异常性分析器366A将由事件的改变引起的对用户的异常性的差异量化为异常性差异得分。可选地，通过组合或比较改变之前与事件相对应的初始异常性得分和与改变之后与事件相对应的更新异常性得分，可以相对于事件的改变来确定异常性差异得分。例如，可以通过将初始和更新异常性得分其中之一从初始和更新异常性得分中的另一个中减去，来计算异常性差异得分。可以理解，异常性差异得分可以是因素特定的，或者是诸如整个事件等多个因素的综合得分。在各种实现中，计算的绝对值被用作异常性差异得分。然而，在其他实现中，可以基于对事件的改变来更直接地计算异常性差异得分。

如本公开中使用的那样，异常性得分量化了在一个或多个事件(例如，单个事件)的一个或多个事件属性与一个或多个用户(例如，单个用户)的一个或多个建模惯例的一个或多个惯例相关方面之间的偏差水平。在异常性得分基于事件的多个因素或方面的情况下，每个因素(也被称为因素度量)可以量化在至少一个事件属性与至少一个建模的惯例的惯例相关方面中的至少一个之间的相应偏差水平。针对事件的因素或方面的异常性得分也可以被称为因素得分。可以组合多个因素得分来量化事件的总体或综合异常，例如作为整体或综合异常性得分。在一些情况下，在组合这些因素时，可以给不同的因素分配不同的权重来确定整体或综合异常性得分。例如，在计算异常性得分时，可以将因素得分乘以权重值。至少一些权重值可以是机器学习的和/或可以针对用户而被个性化。

异常性差异得分可以量化由一个或多个事件的改变(即，改变的大小)所引起的、在一个或多个事件的一个或多个事件属性与一个或多个用户的一个或多个建模惯例的一个或多个惯例相关方面之间的偏差水平的改变或差异。应当理解，可以针对每个因素和/或整体事件计算异常性差异得分，其可以基于相应的异常性得分。

另外，在各种实现中，紧急性分析器366B将用户被通知改变的紧急性量化为紧急性得分。可以为每个因素和/或整体事件生成紧急性得分。在各种实现中，用户被通知事件改变的紧急性是基于事件的时间(例如，开始时间、结束时间或其间的时间)。例如，紧急性得分可以基于在事件被安排在改变后发生之前的时间量。在事件之前的时间量可以从可用于事件分析器366的当前时间(诸如从服务器或用户设备)、基于异常性得分呈现内容的预测或预定时间或另一参考时间来测量。时间更接近参考时间的事件对紧急性的贡献可以比距离参考时间较远的事件更高。在这些情况下，时间可以以如下方式作为因素被计入事件的紧急性中：与事件被安排发生的时间成比例，其中即将发生的事件的紧急性被评估为比时间较远的事件更为紧急。因此，例如，如果一个事件还有三个小时才发生，则该事件的改变通常可以被认为比该事件还有一周才发生的情况下更加紧急且更有影响性。

紧急性因素的另一示例是用户是否是事件的组织者。例如，在用户已经组织了该事件的情况下，让该用户意识到事件的改变可能更为紧急。紧急性因素的另一示例是基于事件的一个或多个参加者的重要性。例如，通过分析用户与一个或多个参加者之间的关系，事件分析器366可以确定紧急性较高。事件分析器366可以计算出，紧急性越高，则对于用户的所确定的关系的重要性水平也越高(例如，单独地或在整体上)。因此，例如，与在事件的参加者与用户在公司中都处于相似职位的情况下相比，在参加者是用户工作所在公司的CEO的情况下事件的改变可以被认为更加紧急。

紧急性得分可以被进一步用作在基于影响得分的内容将被呈现时或者当检测到改变时用户的当前位置或期望/预测位置的因素。影响事件的紧急性得分可以基于在用户的参考位置与事件的位置之间的距离。与更接近参考位置的事件相比，位置距参考位置较远的事件对紧急性的影响可能更大。

事件分析器366可操作以将由事件的改变引起的异常性的差异与通知用户关于改变的紧急性进行组合，以便确定改变的影响。在采用单独异常性差异得分和紧急性得分的实现中，可以根据至少将异常性差异得分(例如，总体得分或因素特定的得分)与相应紧急性得分相乘、或以其他方式加权或组合，来计算影响得分。在一些实现中，如上所述，异常性差异得分和紧急性得分并非是单独计算的。然而，采用单独得分可以降低调整紧急性和异常性的复杂性。

在一些情况下，事件分析器366分析关于特定用户(诸如事件的任何参加者)的异常和所得到的影响。另外地或替代地，事件分析器366可以基于对于多个用户(诸如事件的每个参加者)的整体异常和影响来进行评估。在一个示例性方法中，可以分别评估影响以为每个特定用户生成影响得分，该影响得分可以被组合成整体影响得分(例如，使用平均值)。作为另一示例，对影响得分有贡献的得分可以被综合以作为针对多个参加者生成影响得分的一部分。

作为示例，图3示出了诸如图2中的具有相关联的用户简档230的用户之一等用户的事件382。如本公开中使用的那样，用户的事件可以指代与用户相关联的事件。例如，用户可以是事件的参加者和/或组织者。在一些情况下，可以使用诸如日历应用等安排软件来生成事件。在各种实现中，可以在生成事件的同时(例如，当用户正在向安排服务输入事件属性时)，在生成事件之后(例如，在事件属性相对于该事件被留存或保存之后)，和/或在事件的一个或多个事件属性改变之后，来分析事件的异常。当事件发生改变时，可以单独和/或共同地分析任何改变的异常性和/或影响。

在各种实现中，可以使用自动日历软件来生成事件，自动日历软件采用电子邮件或其他机制来邀请一个或多个用户参加事件或会议的。更加传统的示例包括和Lotus然而，主要基于云的服务和/或集成到移动电话中的服务可以作为较新的示例。例如，这样的应用通常作为操作系统的库存或默认应用而被提供，诸如移动操作系统，包括各种版本的Phone、Android^TM或iOS^TM，或桌面操作系统，诸如各种版本的或Mac然而，这些应用也可以由第三方提供给操作系统提供商。此外，事件可以跨平台和/或跨应用被计划和/或分析。作为示例，可以采用Google Sync和/或Yahoo Sync将日历事件导入Windows Phone日历中。事件382可以是任何前述事件的示例，并且每个包括一个或多个事件属性，诸如事件382a的事件属性378。

在一些情况下，为了安排会议，组织者可以使用服务向一个或多个被邀请者发送邀请。邀请通常指示一个或多个事件属性，诸如事件属性378，诸如会议的日期和时间、会议的位置、会议是否重复发生或会议将在何时重复发生、和评论，该一个或多个事件属性可以由组织者或另一用户设定。该服务通常跟踪被邀请者的响应，诸如被邀请者接受、拒绝、暂时接受还是提出新的时间或地点。基于响应，服务可以诸如通过维护事件的参加者(例如，计划参加者)列表来更新或设置一个或多个事件属性。此外，服务可以自动地将会议作为日历事件或条目添加到每个用户的个人日历中。通常，一个或多个事件属性可以在由原始组织者或另一用户初始设置之后，由一个或多个用户修改(或者属性可以由一个或多个添加或移除)。

因此，在各种实现中，事件的至少一些事件属性可以对应于由一个或多个用户(诸如由参加者之一和/或事件的组织者)在计划、安排或改变事件时输入的信息。然而，在一些实现中，可以推理事件的至少一个事件属性。此外，在一些情况下，至少一个事件本身可以被推理为存在和/或对该事件的改变和/或其事件属性。这些推理可以使用图2的系统200进行。例如，事件本身可以是用户惯例的部分，并且事件属性可以是与惯例相关方面。关于图3中的事件382a示出了事件的事件属性的示例。示例性事件属性包括开始时间384、结束时间386、持续时间388、位置390、参加者392、组织者394和重复发生396。然而，并非所有事件属性都可以被包括在本公开的各种实现中，并且在本公开的各种实现中可以采用其他事件属性。此外，应当理解，开始时间384、结束时间386和持续时间388中的任何两个可以被用于导出另一个。

开始时间384对应于事件382a的计划或预期的开始时间，结束时间386对应于事件382a的计划或预期的结束时间，持续时间388对应于事件382a的计划或预期的持续时间，位置390对应于要发生事件382a的计划或预期的位置，参加者392对应于预期或计划出席事件382a的一组人或联系人，组织者394对应于事件382a的组织者，并且重复发生396对应于事件382a是否为重复事件而不是一次性事件的指示符。在本示例中，事件382a对应于与用户相关联的事件条目(例如，在日历服务或应用中)。然而，在其他情况下，事件382a可以对应于正在计划或生成的事件，并且可能并未显式地与特定用户相关联。

事件的事件属性用于定义事件，并且可以捕获事件的各种异常性方面或特征。此外，修改、添加或移除这些事件属性可能会影响与事件关联的用户的生活。然而，事件属性通常缺乏关于属性在受到事件影响的人的生活中的重要性的上下文。因此，事件属性单独可能并不适合于正确地确定事件的异常性和事件属性改变的影响。在各种实现中，事件分析器366可以采用用户的惯例相关方面来提供事件属性的上下文，以便准确地确定用户的事件的异常性以及事件属性的改变对用户的所得到的影响。因此，异常和影响的概念可以针对用户的生活和日常行为而被个性化。

惯例相关方面的示例包括图3中的惯例相关方面368。惯例相关方面368包括从交互数据的用户模式中推理的信息。例如，在一些实现中，可以从图2的推荐引擎260向事件分析器366提供一个到所有惯例相关方面368。例如，可以使用客户端侧服务接口261、服务器侧服务接口263和/或基于云的服务接口265，来提供惯例相关方面368。在一些情况下，事件分析器366可以主动地请求来自推荐引擎260的信息。在其他情况下，可以以被动或主动的方式将信息提供给事件分析器366或者使其可用于事件分析器366。

可以从由惯例模型引擎240所跟踪、训练和分析的一个或多个相应惯例(例如，惯例模型)，来推理每个惯例相关方面。此外，每个惯例相关方面可以由惯例推理引擎250针对特定用户来推理或预测。特别地，特定用户可以对应于正在针对其确定异常性的事件的参加者。由事件分析器366采用的惯例相关方面可以包括与惯例相关推理相关联的各种度量、得分或值的任何组合，诸如置信度得分、方差度量、中心趋势值、概率分布函数等。事件分析器366可以处理惯例相关方面以推理对于用户的事件异常和/或由事件的改变所引起的异常性的差异。特别地，事件分析器366可以采用惯例相关方面和事件的事件属性，来表征事件的异常和事件的改变的影响。惯例相关方面的示例包括通勤相关方面370、睡眠相关方面372、位置访问相关方面374和亲密度相关方面376。

如以上指示的，可以为每个事件分配通过关于事件属性来分析用户惯例的惯例相关方面而生成的异常性得分。进一步如上所述，事件的改变对用户的影响可以基于关于事件属性的改变来分析用户惯例的惯例相关方面(例如，基于在改变之前和之后的异常性得分)。异常性可以基于各种因素，这些因素被组合以量化和表征事件的异常性。进一步如上所述，在一些情况下，单独地分析每个因素以针对因素生成相应的因素得分和/或异常性差异得分，每个因素可以表示用于分析事件的异常或事件的改变的影响的一个准则，并且可以对应于相应的因素度量。可以将各种得分进行组合，以生成异常性得分和/或总体异常性差异得分。以下关于因素得分来描述各种因素。然而应当理解的是，下面的考虑也适用于因素的异常性差异得分。

确定异常性的一个这样的因素可以基于用户的通勤模式。用户的通勤模式可以通过用户的一个或多个通勤相关惯例的通勤相关方面370来捕获，并且关于事件的一个或多个事件属性来分析。作为示例，能够对事件异常性有贡献的基于通勤的因素可以部分地基于事件与用户的一个或多个已知通勤之间的交叠(例如，由惯例模型引擎240建模的通勤)。对事件的整体异常性(例如，异常性得分)的贡献程度(例如，因素得分)可以基于事件与通勤之间的交叠量。例如，因素得分在事件与通勤之间没有交叠的情况下可以最小(例如，无贡献)，并且随着交叠量的增加而增加，使得贡献可以在完全交叠时最大。因此，作为具体示例，如果通勤时间是从上午9:15到上午10:00并且事件开始时间是上午9:45，其中持续时间为1小时，则该因素得分可以低于在事件开始时间为上午9:10的情况下的因素得分。

在一些实现中，基于通勤的因素可以基于指示事件的开始时间、结束时间和/或持续时间的事件属性来确定。此外，基于通勤的因素可以基于通勤的惯例相关方面，包括用户的建模通勤的开始时间和结束时间。可选地，基于通勤的因素还可以考虑开始时间和结束时间的方差度量(例如，标准偏差)。在考虑方差度量时，可以基于通勤的开始时间的方差和通勤的结束时间的方差来确定交叠量。例如，在确定交叠时，可以按照与开始时间相关联的方差度量(例如，一个标准偏差)来向前调整开始时间，并且可以按照与结束时间相关联的方差度量(例如，一个标准偏差)来向后调整结束时间。此外，可选地，与惯例相关方面相关联的置信度得分可以用于调整基于通勤的因素的程度，其中较低的置信度得分使得因素得分降低。

确定事件异常性的另一这样的因素可以基于用户的睡眠模式。用户的睡眠模式可以由用户的一个或多个睡眠相关惯例的睡眠相关方面372来捕获，并且关于事件的一个或多个事件属性来分析。作为示例，能够对事件异常性有贡献的基于睡眠的因素可以部分地基于事件与用户的一个或多个已知睡眠安排之间的交叠(例如，由惯例模型引擎240建模的睡眠安排)。对事件的整体异常性(例如，异常性得分)的贡献(例如，因素得分)可以基于事件与睡眠安排之间的交叠量。例如，因素得分可以在事件与睡眠安排之间没有交叠的情况下最小(例如，无贡献)，并且随着交叠量的增加而增加，使得贡献可以在完全交叠时最大。

在一些实现中，基于睡眠的因素可以基于指示事件的开始时间、结束时间和/或持续时间的事件属性来确定。此外，基于睡眠的因素可以基于睡眠安排的惯例相关方面，包括用户的建模的睡眠安排的开始时间(即就寝时间)和结束时间(即睡醒时间)。可选地，基于睡眠的因素还可以考虑开始时间和结束时间的方差度量(例如，标准偏差)。在考虑方差度量时，可以基于睡眠的开始时间的方差和睡眠的结束时间的方差来确定交叠量。例如，在确定交叠时，可以按照与开始时间相关联的方差度量(例如，一个标准偏差)来向前调整开始时间，并且可以按照与结束时间相关联的方差度量(例如，一个标准偏差)来向后调整结束时间。此外，可选地，与惯例相关方面相关联的置信度得分可以用于调整基于睡眠的因素的程度，其中较低的置信度得分使得因素得分降低。

确定事件异常性的再一这样的因素可以基于用户的位置访问模式。用户的位置访问模式可以由用户的一个或多个位置访问相关惯例的位置访问相关方面374来捕获，并且关于事件的一个或多个事件属性来分析。作为示例，能够对事件异常性有贡献的基于位置访问的因素可以部分地基于用户访问在事件的位置处或其附近的建模的位置或场所(例如，对由惯例模型引擎240建模的位置或场所的访问)的频率。

在一些实现中，事件分析器366被配置为基于在事件的位置与由惯例模型引擎240建模的一个或多个被访问场所或位置中的位置之间的比较，来确定基于位置访问的因素。例如，可以将该位置与一个或多个被访问位置相比较，并且基于位置访问的因素可以对应于事件的位置是被访问位置中的一个或多个的概率。在一些情况下，事件的位置距一个或多个被访问位置(例如，最接近的被访问位置)的位置越远，则因素得分越大。最小得分可以是事件的位置基本上位于被访问位置的位置处时，并且可以在与被访问位置相距一定距离(例如，预定距离)处增加到最大值。作为示例，所采用的位置每个均可包括用于确定距离的位置坐标，诸如经度和纬度，并且可以基于GPS坐标。因此，在事件用户的惯例访问场所或位置处或附近的情况下，可能不会关于位置访问相关因素而认为事件是特别异常的。

事件的位置可以是例如事件382a的事件属性的位置390。在一些情况下，事件分析器366在确定事件的异常性时使用的位置坐标在与事件相关联地存储的事件属性中是明确的或隐含的。例如，事件安排服务可以允许组织或用户明确地为会议室和/或其他资源提供经度和纬度。作为另一示例，位置390可以包括由诸如事件的参加者等用户输入或选择的地址。这样的地址可以与事件分析器366可以使用地理位置服务查找的位置坐标隐含地相关联。作为另一示例，可以从位置390推理位置坐标。例如，先前的事件或许已经使用了该会议位置或包括与当前位置的文本相对应的字符的文本。基于在先前事件期间从用户设备提取的位置坐标(和/或其他传感器数据)，事件分析器366可以推理出该位置坐标对应于当前事件的位置。

在一些实现中，事件分析器366基于事件向推荐引擎260提供时间。例如，开始时间、结束时间或开始和结束时间之间的时间可以被提供给推荐引擎260。基于时间，惯例推理引擎250可以预测用户的位置(例如，用户的位置)。例如，基于由与用户相关联地收集的时空数据点形成的模式，惯例推理引擎250可以提供位置访问相关方面374，其包括一个或多个位置和用户在给定时间(或时间范围)在该一个或多个位置处或附近的概率。事件分析器366可以选择与事件位置最接近的预测位置，并且基于事件位置到事件的距离来生成因素得分。这样的分析可以可选地将与位置的概率作为一个因素。例如，因素得分可以利用预测位置的概率而被加权。作为另一示例，在选择用于与事件的位置相比较的预测位置时，与不太可能的位置相比，更可能的位置可以以更大权重加权。

另外地或替代地，可以通过由事件分析器366使用基于事件的时间，将事件的位置提供给惯例推理引擎250并且接收预测用户将在该时间期间处于该位置的概率，来生成基于位置访问的因素。概率可以用于确定因素得分，例如，以使得更高的概率使关于因素的异常性降低。

以下提供惯例推理引擎250如何出于基于位置访问的因素的目的来预测用户的一个或多个位置的示例。然而，可以采用其他方法。在一些实现中，可以针对由改变分辨率的时间间隔来索引的相应位置，生成置信度得分或概率得分。对于时空数据点的时间戳(例如，位置坐标和相应的时间戳)，时间间隔的示例包括星期二上午9点、平日早上和星期三下午。在进行这样的确定时，时间间隔可以对应于由事件分析器366提供的事件的时间。置信度得分可以通过应用Dirchlet多项式模型并且计算每个周期直方图的后验预测分布来计算。在这样做时，针对特定直方图中每个分组(bin)的预测可以由下式给出：

其中K表示组数(the number of bin)，α₀是对先验知识的强度进行编码的参数，并且i*＝arg max_ix_i。因此，模式预测是对应于i^*的直方图的分组，并且其置信度由x_i ^*给出。作为示例，考虑直方图，其中早上＝3，下午＝4，晚上＝3。使用α₀＝10，模式预测是下午，并且置信度得分为根据各种实现，更多的观察导致增加的置信度得分，这表明增加了预测的置信度。作为示例，考虑直方图，其中早上＝3000，下午＝4000，晚上＝3000。使用类似的计算，置信度得分为

此外，在一些实现中，可以针对由时间戳的周期和数目来索引的相应跟踪变量来生成置信度得分。示例包括每周1次访问和每2周3次访问。使用高斯后验，可以为每个周期分辨率针对模式生成置信度得分，表示为j。这可以通过采用以下公式来实现：

其中

在上文中，σ²是样本方差，σ₀ ²和μ₀是公式的参数。可以通过采用大约时间戳预测的数目的固定间隔并且将累积密度计算为下式来计算置信度得分：

其中

作为示例，考虑以下观察：w₁ ⁽¹⁾＝10，w₂ ⁽¹⁾＝1，w₃ ⁽¹⁾＝10，w₄ ⁽¹⁾＝0，w₁ ⁽²⁾＝11，并且w₂ ⁽²⁾＝10。N⁽¹⁾＝4并且N⁽²⁾＝2。使用μ₀＝1并且σ₀ ²＝10，μ⁽¹⁾＝4.075并且conf₁＝0.25。另外，μ⁽²⁾＝10.31并且conf₂＝0.99。在上述示例中，尽管对于两个星期周期，较少时间戳可用，但是用户信号的减小方差导致模式存在的置信度增加。

在确定了模式存在或者模式的置信度得分足够高(例如，超过门限值)后，惯例推理引擎250可以生成推理，诸如识别用户日常访问的位置或地点。作为示例，可以通过将函数映射到形成模式(诸如高斯函数或钟形曲线)的时空数据的时间戳，来建立标准偏差。

惯例推理引擎250还可以采用位置预测，其可以使用利用时间间隔而被索引的直方图模型来实现，如上所述。时间间隔由事件分析器366提供，如上所述。使用此时间，直方图模型可以应用于每个已知的地点或位置。这些地点中的每个地点可以产生估计在该时间处对该地点的访问中的一部分的概率：

量P(time＝t|Place＝p)是上述直方图模型。P(Place＝p)是在地点p的先验概率。时间t的分辨率从窄向宽被释放(例如，星期二上午9点＝>平日上午)，直到上述量超过门限，在该情况下，我们的模型预测地点p。在地点p对应于事件的位置的情况下，可以推理出事件关于位置并非是特别异常的，和/或由于是用户的预测位置，对应于地点p的位置或候选地点可以具有增加的置信度或概率得分。

确定事件异常性的另一因素可以基于用户的亲密度模式。在一些实现中，用户的亲密度模式可以由用户的一个或多个亲密度相关惯例的亲密度相关方面376来捕获，并且关于事件的一个或多个事件属性来分析。通过利用基于亲密度的因素，事件分析器366可以关于事件的参与者/参加者来评估事件的异常性。作为示例，能够对事件异常性有贡献的基于亲密度的因素可以部分地基于在用户与对应于联系人简档或用户的事件的一个或多个参加者之间的亲密度，其作为用户的一个或多个基于亲密度的惯例的部分(例如，用户与由惯例模型引擎240建模的联系人简档交互的模式)而被跟踪。

在一些实现中，事件分析器366向推荐引擎260提供事件的参加者的列表，诸如参加者392。推荐引擎260可以将列表提供给惯例推理引擎250，以用于针对参加者列表生成亲密度得分。可以向事件分析器366提供一个或多个亲密度得分，以用于生成用于基于亲密度的因素的因素得分。一个或多个亲密度得分可以是用于参加者列表的合计亲密度得分，或者作为示例，可以为每个参加者提供亲密度得分。亲密度得分对应于用户与一个或多个其他用户或联系人之间的量化的关联度。特别地，参加者可以被映射到由惯例模型引擎240针对用户所跟踪的一个或多个联系人条目。在一些情况下，联系人条目对应于用户的联系人簿中的条目，诸如用户的手机联系人和/或电子邮件联系人。每个联系人条目可以包括相应的名称、以及一个或多个街道地址、电子邮件地址、电话号码等。在一些情况下，参加者的列表可以包括参加者的联系人条目和/或其指示符，例如，在事件的参加者从与惯例模型引擎240共享的联系人簿来生成时。在其他情况下，惯例推理引擎250可以从诸如姓名、电子邮件地址等在参加者列表中提供的信息，来推理联系人。

用户与参加者之间的亲密度可以基于用户与同参加者相对应的联系人之间的各种被跟踪的交互。可以增加亲密度的交互的示例包括去往和/或来自该联系人的电子邮件、去往和/或来自该联系人的文本消息、去往和/或来自该联系人的电话呼叫、将用户与联系人相关联的其他传感器数据、以及上述中的任何一项的量。在一些情况下，亲密度可以基于其他事件或会议，诸如用户和联系人都是参加者的过去事件。此外，去往或来自与用户相关联的联系人的事件的邀请可以增加亲密度。在一些情况下，基于所检测的交互的新近性，对亲密度进行折算。例如，与不太接近的交互相比，更接近的交互可以在较大程度上增加亲密度。亲密度不必仅基于用户与联系人之间被检测或识别的交互。特别地，可以采用将用户与联系人相关联的信息。作为示例，可以使用包括用户和作为员工的客户的组织机构图。

在一些实现中，参加者的亲密度还基于上下文。例如，可以由事件分析器366提供从事件的标题和/或其他事件属性生成和/或提取的文本，使得能够关于由文本指示的上下文来评估亲密度。

可以基于一个或多个亲密度得分来生成基于亲密度的因素的因素得分。应当理解，可以采用各种方法。一般来说，较高的亲密度得分表明参加者对于用户来说不那么异常，从而导致对事件异常性的贡献较小。其他因素可以包括具有的亲密度得分超过对于用户具有低亲密度的门限值的参加者的数目。然而，在一些情况下，可以总计亲密度得分以生成因素得分，例如，作为亲密度得分的平均值。

除了用户的跟踪惯例的一个或多个惯例相关方面之外，事件分析器366可以使用一个或多个其他因素来调整异常性得分、紧急性得分和/或影响得分。一个这样的示例包括事件是否是重复发生事件。例如，重复发生396可以指示事件是重复发生事件。如本公开中使用的，重复发生事件对应于被安排多于一个时间段的事件，并且可以每周、每月或每天重复发生。在事件是重复发生事件的情况下，事件分析器366可以对异常性进行折算或以其他方式调整异常性得分或另一得分。基于非惯例的因素的另一示例包括用户是否是事件的组织者。例如，组织者394可以指示用户是事件的组织者。在用户是事件的组织者的情况下，事件分析器366可以调整异常性得分或另一得分。

另一基于非惯例的因素是事件的持续时间。例如，可以关于诸如事件382等与用户相关联的一个或多个附加或其他事件，来分析事件的持续时间，以确定持续时间是比那些事件的总计持续时间更长还是更短。例如，可以将事件的持续时间与事件的平均持续时间相比较。事件的持续时间越接近于平均持续时间，事件的持续时间越不可能使异常性得分或其他得分增加。在一些情况下，平均持续时间包括在事件发之后的一段时间内(诸如在接下来的两周内)的事件。时间段还可以包括一个或多个先前的事件，诸如前一天或两天的事件。此外，正在分析的事件的持续时间可以被包括在平均或总计持续时间内。平均持续时间不限于时间段，并且可以基于滚动平均值、或以其他方式说明历史事件持续时间。

上文已经描述了各种因素，其可以由事件分析器366组合，以确定事件的异常水平和/或由事件的改变引起的对用户的事件异常性的差异。异常可以基于异常度量和/或与紧急性度量相组合以形成影响度量的一个或多个因素度量，其可以用于相对于一个或多个用户来评估一个或多个改变对任何各种事件的影响。因此，可以将一个或多个改变的相对影响与同一事件内和/或多个事件之间的一个或多个其他改变的相对影响相比较。

如上所述，在各种实现中，基于由该改变引起的对用户的事件异常性的差异，结合向用户通知改变的紧急性，事件分析器366量化事件改变对用户的影响。在很多情况下，事件异常性的差异的大小(例如，上述绝对值)足以准确地反映改变的影响。然而，在一些情况下，即使改变对于用户来说非常重要，对于异常性的改变来说，该大小也可能较小。作为示例，假定事件382a的位置390最初处于由基于位置访问的因素或其他基于位置的因素而量化的异常位置。在位置390变为具有类似异常性的另一位置的情况下，该因素的大小将会很低，这可能导致大小和影响得分较低，即使其对于用户来说可能知道新位置是重要的，尤其是因为它是异常的。

因此，在一些实现中，可以调整改变的影响，以基于下面描述的各种方法中的任一种，来更准确地反映改变的影响。在一些方法中，该调整可以在针对事件的改变和/或其因素计算的影响得分中得以反映。另外，或者相反，一些方法可以检测并且将改变的某些条件映射为与影响得分本身分离的影响，例如在确定哪些改变应当被呈现给用户时。

在各种方法中，影响可以至少部分基于关于影响来分析的改变的初始异常性得分。在这样做时，可以制定影响度量，以确保改变之前和之后具有高度异常性的事件和/或其因素对影响仍然具有很大的贡献。作为示例，改变的异常性差异的大小可以乘以事件和/或关于影响分析的因素的初始异常性得分(或基于初始异常性得分的另一系数)。因此，与最初异常性低的事件或因素相比，对于最初异常性高的事件或因素，可能会使影响增加。在一些情况下，可以使用一个或多个门限值来应用这种影响的增强。例如，可以使用门限值来设置用于将增强应用于影响的边界条件。一个示例是在针对改变的初始和先前异常性得分都足够高的情况下应用增强。

在一些方法中，影响基于在事件改变之前和/或之后识别异常性的最高贡献因素来确定。这种方法可能特别适用于针对使用综合异常性得分对事件进行多重改变来确定影响的情况。作为示例，基于确定与该最高贡献因素相对应的一个或多个事件属性已经改变，和/或确定在改变之后最高贡献因素是不同的，可以应用对影响的增强。因此，例如在最高贡献因素与事件改变之前和之后的事件的基于位置的因素相对应的情况下，与位置保持相同的位置相比，可以在位置改变的情况下增强影响。作为另一示例，在最高贡献因素与事件改变之前的事件的基于位置的因素相对应并且与事件之后的基于亲密度的因素相对应的情况下，与最高贡献因素保持基于位置的因素(并且可能位置保持不变)相比，可以增强影响。因此可以理解，可以采用各种方法或其他方法的任何组合来调整差异的大小，以便识别事件的对真正具有影响性的改变。

在一些实现中，事件可以存储在存储装置380中，存储装置380可以与图2中的存储装置220相同或不同。在一些情况下，存储装置380位于诸如用户设备102a等用户设备上，或者以其他方式与用户相关联地存储。然而，存储装置380可以替代地位于诸如服务器106等服务器上，而用户设备可以保留被包括在存储装置380中的任何各种数据的一个或多个本地副本。可以从各种安排和事件跟踪服务对各种事件进行总计，诸如如上所述的那样。可以位于用户设备上的操作系统的服务或其他服务可以监听可能影响一个或多个事件的异常性的改变，诸如对现有事件、添加事件或移除事件的修改。基于检测到一个或多个改变，监听程序可以提供通知以致使事件分析器366更新事件的异常性得分和/或确定事件的改变的影响。

在一些情况下，当检测到改变时，监听程序可以致使诸如经由推荐引擎260而将改变上传到服务器，以便进一步处理。例如，事件分析器366可选地可以至少部分地被集成到位于服务器(例如，服务器106)中并且在用户设备外部的惯例推理引擎250中。因此，事件分析器366的至少一些功能可以是基于云的。然而，在其他实现中，事件分析器366的至少一些功能可以位于用户的正在分析事件的用户设备上。在一些情况下，事件的改变可以由事件分析器366定期评估，诸如以每天为周期。然而，可以以其他间隔来评估改变，诸如在每次检测到改变时和/或基于触发向用户呈现服务内容(例如，基于用户设备的UI中的用户动作、当前时间和/或其他准则)时。

在各种实现中，作为示例，用户可以通过与日历应用或服务进行交互，来使用诸如用户设备102a等用户设备来改变一个或多个事件的一个或多个事件属性。日历应用或服务或者另一应用或服务(例如，位于用户设备或云服务上)可以检测改变，并且通知消息可以被传送到服务器(例如，从用户设备或云服务)，诸如图1中的服务器106，以便处理改变。在一些实现中，通知消息包括对一个或多个事件做出的一个或多个改变。例如，通知消息可以指示哪个(哪些)事件的哪些事件属性发生改变、以及表示用于确定影响的那些改变的值(例如，事件属性的旧值和/或新值，和/或事件属性的增量值)。通知消息还可以指示事件被改变的时间。

在一些实现中，确定影响与提供通知消息的设备的通信是同步的。然而，在其他情况下，这个过程可以是异步的，这可以通过允许在发送通知消息之后关闭连接而不等待来自服务器的确认，来实现设备的功率节省。稍后可以例如通过成功消息来推送确认，该成功消息可以可选地包括一个或多个影响得分或其他指令或者可能导致用户设备重新发送通知消息的错误消息。在与用户设备进行通信的情况下，用户设备的电池寿命可以显著提高。

在一些实现中，事件分析器366可以针对多个事件和/或其因素的多个改变来确定影响。可以基于分配给一个或多个改变的一个或多个影响得分，将服务内容提供给与事件相关联的用户。影响得分的相对性质可以允许系统确定对事件的哪些改变被呈现给用户和/或用于向用户呈现改变的适合方式或时间。这可以通过提供避免向用户呈现相对微不足道的改变的准则，来改善系统的性能，并且可以进一步改善用户体验和界面。

因此，例如，已经为一个或多个改变确定了一个或多个影响得分后，可以使用呈现部件398基于一个或多个影响得分向用户呈现内容(例如，内容399)。内容可以例如在用户设备102a和102b至102n的任何组合上被呈现。在这种能力下，呈现部件398可以采用事件的各种事件属性、改变的影响得分、事件的异常性得分、和/或用于生成那些得分的惯例相关方面以及其他数据中的任何一个。呈现部件398可以确定何时和/或如何向用户呈现内容。呈现部件398还可以确定向用户提供什么内容。

在一些实现中，事件分析器366可以生成与事件和/或其一个或多个因素的改变相对应的上下文信息。在一些情况下，生成上下文信息包括将一个或多个类别分配给一个或多个改变。具体地，事件分析器366可以将一个或多个预定类别分配给改变。作为一个示例，基于与改变相对应的影响得分超过门限值，可以将改变分类为具有影响性。可选地，这样的分类还可以考虑在改变之前和/或之后的事件的各种特征中的任何特征，以将特征和影响得分映射到各类别。特征的示例已经在上面进行了描述，并且包括改变的异常性得分增加、减少、还是保持与改变的结果基本相同。另一示例包括事件的改变引起的对异常性得分的改变的方向。在一些实现中，特别显著和/或紧急的改变可以被分类为具有高度影响性。例如，基于影响得分超过第一门限值，可以将改变分类为具有影响性，并且基于影响得分超过大于第一门限的第二门限，可以将改变分类为具有高度影响性。

作为分类的进一步的示例，分类可以指示影响得分和/或用于确定影响得分的一个或多个得分(例如，异常性得分)的最高贡献因素。例如，在用于确定综合异常性得分和/或综合异常性差异得分的各种因素中，其中一个因素可以是总体得分的最高贡献者。这个因素可以被分类为该得分的最高贡献因素。作为示例，只有事件的位置发生改变的情况下，基于位置的因素才可以被标识为对于针对改变的综合异常性差异得分的最高贡献因素。可以通过针对对得分有贡献的因素的贡献进行排名，来确定最高贡献因素的类别。可以使用类似的方法来对最低贡献因素进行分类，或以其他方式生成指示排名的类别。在一些情况下，类别可以表明最高贡献因素保持相同还是由于事件的相应改变而改变。从以上描述可以理解，可以在分配类别时分析很多因素及其条件，包括因素得分、异常性差异得分、事件属性和/或在确定得分时使用的惯例相关方面。

呈现部件398可以利用上下文信息来确定何时和/或如何向用户呈现内容和/或向用户呈现什么内容。例如，在一些情况下，呈现部件可以与基于相关联的影响得分而呈现的事件和/或其他内容相关联，向用户显示或以其他方式呈现最高贡献因素的指示符。注意，分类可以包括各种粒度级别。例如，最高贡献因素的指示还可以指示与因素的贡献相关联的更具体的方面或原因。作为示例，指示或分类可以不仅指示事件具有异常持续时间，而且还可以指示事件异常长或异常短。上下文信息的其他示例包括置信度得分、方差得分和用于生成异常性得分的其他信息。

在一些实现中，一个或多个分类可以与可以呈现给用户的内容和/或可由呈现部件398采取的一个或多个动作相关联。例如，每个分类可以具有不同的相关联的动作和/或内容的集合。这些集合中的很多集合可以针对的是使用户为所安排的事件做好准备，诸如通过向用户提供与事件对应的信息进行研究，或者提议提供帮助用户进行安排或改变安排(例如，已安排项目、已安排警报、旅行安排、提醒)，以方便用户参与事件或以其他方式管理事件的影响。

作为示例，基于影响得分足够高和/或被分类为具有高度影响性，可以以主动方式自动向用户呈现该改变，以快速通知用户该改变。该通知可以是可用于与用户相关联的一个或多个用户设备的消息的任何组合的形式。示例包括呼叫一个或多个用户设备，向与用户相关联的账户发送电子邮件，发送与用户相关联的电话号码的短信，和/或向一个或多个用户设备发送推送通知、吐司(toast)通知或其他提醒。

作为进一步的示例，某些分类可以对应于用于修改之前针对该事件进行的安排的界面。例如，在事件改变之前，系统可能诸如通过基于确定事件足够异常(例如，基于对应于事件的异常性得分)来帮助用户规划事件，而在先前已经呈现了一组动作。这组动作可以对应于异常性得分的因素，诸如最高贡献因素。呈现部件398可以检测到因素已经改变，并且基于检测到该改变，可以执行新的一组动作，诸如提议修改在规划未修改的事件时所做出的先前安排。

因此，例如，在因素是基于位置访问的因素的情况下，呈现部件398可以呈现提议重新安排在用户的会议之前和/或之后(例如，在用户日历中)所安排的旅行时间的内容。作为另一示例，呈现部件398可以呈现提议取消或重新安排用于用户的警报的内容。例如，基于该因素是指示事件的时间最初是在用户的典型睡醒时间之前或与其足够接近的基于睡眠的因素，警报可能已经初始地在用户的典型睡醒时间之前被设置。呈现部件398可以呈现如下内容，该内容提议取消警报，或提议诸如通过基于与该因素相对应的一个或多个事件属性的改变将警报移回到其原始时间而重新安排警报。另外，在上面的示例中，可以进行这些不同的计划或安排其中的任何一个，而不考虑先前基于改变的因素或类别所做出的安排。

在一些实现中，呈现部件398至少部分基于事件的影响得分来从与用户相关联的多个事件中选择要向用户呈现的一个或多个事件和/或事件的改变。例如，具有最高影响得分的一个或多个事件和/或改变可以被呈现给用户。如上所述，在一些情况下，可以由事件分析器366基于改变的影响得分超过门限值来将改变分类为具有影响性。一个或多个事件和/或改变(或其他内容)可以基于这些改变是否被分类为具有影响性来呈现给用户。

用于确定要向用户显示哪些事件、改变或其他内容的各种得分可以被合计成组合得分。可以通过组合得分对改变进行排序，并且可以选择改变、与其相对应的事件或与其相关联的其他内容中的一个或多个来进行显示(例如，最高评分改变或多个改变)。在一些情况下，内容只能在组合得分超过门限值的情况下被呈现。此外，对于一些呈现方式，在排序中考虑的事件可以针对在改变之后被分类为异常的事件。

现在参考图4A和4B，图4A和图4B示出了可以基于与用户相关联的一个或多个事件的一个或多个改变的影响得分而(例如，在诸如移动电话等用户设备上)向用户呈现的示例性内容。特别地，图4A和4B示出了内容400，其中的至少一些可以由呈现部件398基于影响得分来提供。图4A对应于内容400的简明视图，图4B对应于内容400的展开视图，所述内容可以基于点击或轻击内容400的窗格410来呈现，如图所示。内容400可以包括关于被安排用于用户的事件的概要报告。内容400包括用户的事件安排412。事件安排412指示覆盖预定时间段(诸如一天)的时间线格式的事件412a、412b和412c的开始和结束时间。在事件安排412中的事件中，仅对事件412a示出了附加细节。具体地，呈现部件398可以至少基于与事件412a、412b和412c相关联的影响得分，并且可选地基于诸如异常性得分等其他因素，来选择事件412a。事件412a与图标416相关联地示出，呈现部件398可以基于事件412a被分类为具有影响性和/或异常而选择性地显示该图标416。此外，内容400可以可选地包括改变指示符415，其指示针对该事件改变的一个或多个事件属性。在一些情况下，改变指示符415可以基于对事件的改变的最高贡献因素，或者基于影响得分。

作为示例，窗格410显示事件412a的事件属性，包括开始时间、结束时间和位置。图4B中的展开窗格418包括与事件相关联的附加内容，包括附加事件属性。例如，示出了来自与事件的参加者相关联的联系人条目的信息。与事件412a相关联地向用户呈现另外的各种可选择的动作。所示的示例包括响应动作、迟到动作和呼叫动作。可以基于事件的影响得分和/或异常性得分的分类和/或与事件相关联的类别，来呈现这些动作中的至少一个。与动作交互可以触发一个或多个相关联的界面以就该事件对用户进行辅助。因此，可以以各种方式辅助用户，以便更好地应对具有影响性的事件。

现在参考图5，图5示出了根据本发明的实现的用于分析用户的事件的方法500的流程图。在方框510处，方法500包括接收与对用户相关联的事件的改变的通知。例如，事件分析器366可以接收事件382a的一个或多个事件属性378已经改变的通知消息。可以通过事件差异数据375来捕获该改变，其中事件差异数据375可以指示或包括一个或多个事件属性的更新值，并且可以被包括在通知消息中。在一些情况下，通知消息来自诸如用户设备102a等用户设备。事件属性378的改变可以对应于事件属性(例如，其值)的添加、移除和/或修改。

在方框520处，方法500包括关于与用户相关的惯例相关方面，基于事件的事件属性来为改变生成影响得分。例如，事件分析器366可以通过确定由改变引起的、在一个或多个事件属性与惯例相关方面(例如，惯例相关方面368)之间的偏差水平的差异，并且基于事件的时间与参考时间的比较，来生成或确定影响得分。差异可以对应于异常性差异得分，并且比较可以产生紧急性得分，其可以与异常性差异得分组合以产生影响得分。

在方框530处，方法500包括基于影响得分来为用户生成服务内容。例如，呈现部件398可以至少部分基于为事件382a的改变而生成的影响得分，来生成内容399的至少部分(其可以对应于图4A和4B中的内容400)。服务内容可以基于影响得分与一个或多个其他影响得分相比的相对值来生成。

现在参考图6，图6示出了根据本发明的实现的用于分析用户的事件的方法600的流程图。在方框610，方法600包括识别与用户相关联地存储的事件的事件属性的改变。例如，事件分析器366可以基于事件差异数据375识别事件382a的事件属性378的改变。该识别可以响应于该改变的通知来执行，该改变的通知可以来自用户设备102a或另一设备。该改变可以被用户设备或另一设备检测到，从而导致通知被提供给事件分析器366。

在方框620处，方法600包括接收与用户相关联的惯例相关方面。例如，事件分析器366可以接收从与用户相关联的一个或多个用户惯例模型所生成的惯例相关方面368。一个或多个用户惯例模型可以至少部分基于包括反映由一个或多个传感器检测的用户活动的传感器数据的交互数据而被训练。

在方框630处，方法600包括将因素度量应用于改变，以针对因素度量生成影响得分。例如，事件分析器366可以将上述因素的任何组合或子集和/或其他因素，应用于在事件382中的事件382a的事件属性的改变。每个因素度量可以具有相应的影响得分，并且每个影响得分可以基于由改变引起的、在事件的一组事件属性与一组惯例相关方面之间的偏差水平的差异，并且基于事件的时间与参考时间的比较。可以针对每个影响得分使用相同的参考时间。

在方框640处，方法600包括基于影响得分的分析来选择因素度量的子集。例如，事件分析器366可以基于对因素度量中每个因素度量的影响得分的分析，来选择因素量度的子集。应当注意，在本公开中使用时，“集合”可以包括一个或多个成员或元件。类似地，“子集”可以包括一个或多个成员或元件。然而，应当注意，集合的子集意味着集合包括至少两个元素。

在方框650处，方法600包括基于所选择的因素度量子集来为用户生成服务内容。例如，事件分析器366可以至少部分基于所选择的因素度量子集，来为用户生成内容399(其可以对应于图4A和4B中的内容400)。

现在参考图7，图7示出了根据本发明的实现的用于分析用户的事件的方法700的流程图。在方框710处，方法700包括识别对与用户相关联的事件的事件属性的改变。例如，事件分析器366可以针对与用户相关联地存储的事件382(或在只有一些事件发生改变情况下是其子集)中的每个，基于每个事件的事件差异数据375识别事件的事件属性的改变。该识别可以响应于可以来自用户设备102a或另一设备的该改变的一个或多个通知来执行。特别是，针对有改变的每个事件可以使用一个通知，或者一个通知可以对应于多个事件。在一些情况下，通知是从不同的用户设备(诸如移动电话和个人计算机)接收的。这可能在用户改变第一用户设备上的第一事件和第二用户设备上的第二事件的情况下发生。

在方框720处，方法700包括接收与用户相关联的惯例相关方面。例如，事件分析器366可以接收从与用户相关联的一个或多个用户惯例模型所生成的惯例相关方面。可以至少部分基于包括反映由一个或多个传感器检测的用户活动的传感器数据的交互数据，来训练一个或多个用户惯例模型。

在方框730，方法700包括关于与用户相关联的惯例相关方面，基于事件的事件属性来为每个事件生成影响得分。例如，事件分析器366可以通过关于惯例相关方面分析事件的事件属性的改变来为事件382中的每个事件生成至少一个影响得分，其中通过确定由改变引起的、在事件属性与惯例相关方面之间的偏差水平的差异，以及基于事件的时间与参考时间的比较，来生成影响得分。注意，可以为任何事件生成多个影响得分。此外，影响得分可以是总体影响得分、综合影响得分或因素影响得分(特定因素的影响得分)。

在方框740，方法700包括基于影响得分来致使与事件子集相对应的内容被呈现在用户的用户设备上。例如，事件分析器366可以基于事件382的子集中的至少一些的影响得分来引起与事件382的子集相对应的内容399(其可以对应于内容400或其部分)被呈现在用户的用户设备102a上。作为示例，可以在内容中显示事件的子集而不显示其他事件，或者可以使用图标、标签和/或其他标记将事件子集与其他事件区分开。

因此，已经描述了各个技术方面，其部分地涉及用于至少部分基于反映由一个或多个传感器检测的用户活动的传感器数据，来推理用户的事件异常性的系统和方法。应当理解，本公开中描述的实现的各种特征、子组合和修改是具有实用性的，并且可以在其他实现中被采用而不需参考其他特征或子组合。此外，示例方法中示出的步骤的次序和顺序并非意味着以任何方式限制本发明的范围，并且事实上，这些步骤可以在其实现内以各种不同的顺序发生。这样的改变及其组合也被认为在本发明的实现的范围内。

已经描述了本发明的各种实现，现在描述适于实现本发明的实现的示例性计算环境。参考图8，提供了示例性计算设备并且其总体上被称为计算设备800。计算设备800仅是适合计算环境的一个示例，并且并非旨在暗示对本发明的使用或功能的范围的任何限制。计算设备800也不应当被解释为具有与所示部件的任何一个或组合相关的任何依赖性或要求。

本发明的实现可以在计算机代码或机器可使用指令的一般上下文中描述，所述计算机代码或机器可使用指令包括由诸如个人数据助理、智能手机、平板电脑或其他手持设备等计算机或其他机器执行的计算机可用或计算机可执行指令，诸如程序模块。通常，包括例程、程序、对象、部件、数据结构等在内的程序模块是指执行特定任务或实现特定抽象数据类型的代码。本发明的实现可以在各种系统配置中实践，包括手持设备、消费电子设备、通用计算机、更专业的计算设备等。本发明的实现也可以在分布式计算环境中实现，其中任务由通过通信网络链接的远程处理设备来执行。在分布式计算环境中，程序模块可以位于包括存储器存储设备的本地和远程计算机存储介质两者中。

参考图8，计算设备800包括总线810，其直接或间接将以下设备耦合：存储器812、一个或多个处理器814、一个或多个呈现部件816、一个或多个输入/输出(I/O)端口818、一个或多个I/O部件820和示例性电源822。总线810表示可以是一个或多个总线的线路(诸如地址总线、数据总线或其组合)。尽管图8的各个方框为了清楚起见而用线条示出，但是实际上，这些方框表示逻辑部件而并非必然是实际部件。例如，可以将诸如显示设备等呈现部件视为I/O部件。另外，处理器具有存储器。本发明人认识到，这是本领域的本质，并且重申图8的视图示仅仅是对可以结合本发明的一个或多个实现来使用的示例性计算设备的说明。在诸如“工作站”、“服务器”、“笔记本电脑”、“手持设备”等之间并不进行区分，因为所有这些设备被预期包括在图8的范围内并且被指代为“计算设备”。

计算设备800通常包括各种计算机可读介质。计算机可读介质可以是可以由计算设备800访问的任何可用介质，并且包括易失性和非易失性介质、可移除和不可移除介质。作为示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术所实现的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪速存储器或其他存储器技术、CD-ROM、数字通用盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备或可以用于存储期望信息并且可以被计算设备800访问的任何其他介质。计算机存储介质本身不包括信号。通信介质通常实施计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制等调制数据信号中的其他数据，并且包括任何信息传递介质。术语“调制数据信号”是指下述信号，该信号的特征中的一个或多个特征以能够在信号中对信息进行编码的方式来设置或改变。作为示例而非限制，通信介质包括有线介质(诸如有线网络或直接有线连接)和无线介质(诸如声学、RF、红外和其他无线介质)。上述任一项的组合也应当被包括在计算机可读介质的范围内。

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

I/O端口818使得计算设备800能够在逻辑上耦合到其他设备，包括I/O部件820，其中一些可以被内置。说明性部件包括麦克风、操纵杆、游戏键盘、卫星天线、扫描仪、打印机、无线设备等。I/O部件820可以提供处理由用户生成的空气手势、语音或其他生理输入的自然用户界面(NUI)。在一些情况下，输入可以被传输到适当的网络元件用于进一步处理。NUI可以实现语音识别、触摸和手写笔识别、面部识别、生物识别、屏幕上和屏幕附近的手势识别、空中手势、头部和眼睛跟踪以及与计算设备800上的显示相关联的触摸识别的任何组合。计算设备800可以配备有用于手势检测和识别的深度相机，诸如立体相机系统、红外相机系统、RGB相机系统及其组合。另外，计算设备800可以配备有能够检测运动的加速度计或陀螺仪。可以将加速度计或陀螺仪的输出提供给计算设备800的显示器，以渲染沉浸式增强现实或虚拟现实。

计算设备800的一些实现可以包括一个或多个无线电824(或类似的无线通信部件)。无线电824传输和接收无线电或无线通信。计算设备800可以是被适配为在各种无线网络上接收通信和介质的无线终端。这样，计算设备800可以经由诸如码分多址(“CDMA”)、全球移动电话系统(“GSM”)或时分多址(“TDMA”)等无线协议与其他设备通信。无线电通信可以是近距离连接、远距离连接、或近距离和远距离无线电信连接的组合。当提到“近”和“远”类型的连接时，不是指两个设备之间的空间关系。相反，近距离和远距离通常被称为不同类别或类型的连接(即，主连接和次连接)。作为示例而非限制，近距离连接可以包括到提供对诸如使用802.11协议的WLAN连接等无线通信网络的接入的设备的连接(例如，移动热点)；到另一计算设备的蓝牙连接是近距离连接或近场通信连接的第二示例。作为示例而非限制，远距离连接可以包括使用CDMA、GPRS、GSM、TDMA和802.16协议中的一个或多个的连接。

在不脱离以下权利要求的范围的情况下，所示出的各种部件以及未示出的部件的很多不同布置是可能的。已经描述了本发明的实现，意图是说明性的而不是限制性的。对于本公开的读者而言，替代实现将在阅读之后变得显而易见。在不脱离以下权利要求的范围的情况下，可以完成实现上述内容的替代方式。某些特征和子组合是具有实用性的，并且可以在不参考其他特征和子组合的情况下使用，并且被预期包括在权利要求的范围内。

Claims (15)

1.一种计算机化的系统，包括：一个或多个传感器，被配置为提供反映由所述一个或多个传感器检测的用户活动的传感器数据；事件分析器，被配置为基于惯例相关方面来针对与用户相关联的事件的多个事件属性中的一个或多个事件属性的改变而生成影响得分，所述惯例相关方面由与所述用户相关联的一个或多个用户惯例模型来生成，所述一个或多个用户惯例模型至少部分基于包括所述传感器数据的交互数据而被训练；一个或多个处理器；以及存储计算机可用指令的一个或多个计算机存储介质，所述计算机可用指令在由所述一个或多个处理器使用时，引起所述一个或多个处理器执行操作，所述操作包括：使用所述事件分析器接收所述一个或多个事件属性的改变的通知；通过确定由所述改变引起的、在所述一个或多个事件属性与所述惯例相关方面之间的偏差水平的差异，并且基于所述事件的时间与参考时间的比较，来基于接收的所述通知生成所述影响得分；以及至少部分基于针对所述改变生成的所述影响得分来为所述用户生成服务内容。

2.根据权利要求1所述的计算机化的系统，其中所述惯例相关方面中的至少一个惯例相关方面是从至少一个通勤相关惯例模型而生成的通勤相关方面，所述至少一个通勤相关惯例模型基于检测所述传感器数据中的所述用户的通勤模式而被训练。

3.根据权利要求1所述的计算机化的系统，其中所述惯例相关方面中的至少一个惯例相关方面是从至少一个睡眠相关惯例模型生成的睡眠相关方面，所述至少一个睡眠相关惯例模型基于检测所述传感器数据中的所述用户的睡眠模式而被训练。

4.根据权利要求1所述的计算机化的系统，其中所述惯例相关方面中的至少一个惯例相关方面是从至少一个位置访问相关惯例模型生成的位置相关方面，所述至少一个位置访问相关惯例模型基于检测所述传感器数据中的所述用户的位置访问模式而被训练。

5.根据权利要求1所述的计算机化的系统，其中所述惯例相关方面中的至少一个惯例相关方面是从至少一个亲密度相关惯例模型生成的亲密度相关方面，所述至少一个亲密度相关惯例模型基于检测所述传感器数据中的所述用户相对于所述用户的一个或多个联系人的亲密度模式而被训练。

6.根据权利要求1所述的计算机化的系统，其中所述传感器数据包括在多于一个用户设备上发生的用户活动。

7.根据权利要求1所述的计算机化的系统，其中所述一个或多个事件属性包括所述事件的位置和所述事件的预定时间，并且所述影响得分至少部分基于所述用户在所述事件的时间或其附近在所述事件的位置处或其附近的概率，所述概率基于从所述传感器数据中提取的时空数据点被训练的所述一个或多个用户惯例模型中的至少一个用户惯例模型而被计算。

8.根据权利要求1所述的计算机化的系统，其中确定由所述改变引起的、在所述一个或多个事件属性与所述惯例相关方面之间的偏差水平的差异包括：确定所述改变之前在所述一个或多个事件属性与所述惯例相关方面之间的第一偏差水平；确定发生所述改变的情况下在所述一个或多个事件属性与所述惯例相关方面之间的第二偏差水平；以及使用所述第一偏差水平和所述第二偏差水平来计算所述偏差水平的差异。

9.根据权利要求1所述的计算机化的系统，其中至少部分基于针对所述改变生成的所述影响得分来为所述用户生成所述服务内容包括在与所述用户相关联的用户设备上自动向所述用户通知所述改变。

10.根据权利要求1所述的计算机化的系统，其中为所述用户生成所述服务内容包括基于所述影响得分超过门限值，来从多个预定义的显示方式中选择用于所述服务内容的显示方式。

11.根据权利要求1所述的计算机化的系统，其中所述事件对应于所述日历应用中的事件条目。

12.一种计算机化的方法，包括：识别与用户相关联地存储的事件的事件属性的改变；接收从与所述用户相关联的一个或多个用户惯例模型生成的惯例相关方面，所述一个或多个用户惯例模型至少部分基于包括传感器数据的交互数据而被训练，所述传感器数据反映由一个或多个传感器检测的用户活动；针对所述事件属性的改变应用因素度量，以生成影响得分，每个影响得分对应于相应的因素度量，并且每个影响得分基于由所述改变引起的、在所述事件的一组事件属性与一组惯例相关方面之间的偏差水平的差异，以及基于所述事件的时间与参考时间的比较；基于对所述因素度量中的每个因素度量的所述影响得分的分析，来选择所述因素度量的子集；以及至少部分基于所选择的所述因素度量的子集，来为所述用户生成服务内容。

13.根据权利要求12所述的计算机化的方法，其中因素度量基于具有所述因素度量的最高影响得分而被包括在所述因素度量的子集中。

14.根据权利要求12所述的计算机化的方法，还包括基于所述因素度量的所述影响得分，来向所述事件分配一个或多个类别，其中所述服务内容中的至少一些服务内容基于向所述事件分配的所述一个或多个类别而被预先确定。

15.根据权利要求12所述的计算机化的方法，其中所述事件对应于日历应用中的事件条目。