CN110869952A - 用于电子设备的自动化动作的方法 - Google Patents

Abstract

一种用于动作自动化的方法，包括使用电子设备基于域信息来确定动作。获取与动作相关联的活动模式。对于每个活动模式，确定候选动作规则。每个候选动作规则指定动作发生时的一个或更多个前提条件。从多个候选动作规则中确定用于动作自动化的一个或更多个优选的候选动作规则。

Description

用于电子设备的自动化动作的方法

技术领域

一个或更多个实施例总体上涉及智能设备自动化，尤其涉及确定个性化的动作自动化。

背景技术

现代智能手机和无处不在的计算系统从用户那里收集了大量的情景数据。得益于规则提供给用户的可理解性和控制力，由IFTTT(If-This-Then-That)平台所普及的条件动作规则是一种使用户自动执行频繁重复任务或接收智能提醒的流行方法。IFTTT系统的主要缺点是，它们给用户带来了手动指定动作规则的负担。

发明内容

问题的解决方案

一个或更多个实施例总体上涉及确定动作自动化的优选规则。在一个实施例中，方法包括使用电子设备基于域信息来确定动作。获取与动作相关联的活动模式。对于每个活动模式，确定候选动作规则。每个候选动作规则指定了动作发生时的一个或更多个前提条件。从多个候选动作规则中确定用于所述动作自动化的一个或更多个优选的候选动作规则。

在另一实施例中，一种电子设备包括存储指令的存储器。至少一个处理器执行包括进程的指令，该进程被配置为：基于域信息来确定动作，获取与所述动作相关联的多个活动模式，对于每个活动模式来提取候选动作规则，其中每个候选动作规则指定了所述动作发生时的一个或更多个前提条件，以及从多个候选动作规则中确定用于所述动作自动化的一个或更多个优选的候选动作规则。

在一个实施例中，一种非暂时性处理器可读介质包括程序，该程序在被处理器执行时执行一种方法，该方法包括使用电子设备基于域信息来确定动作。获取与所述动作相关联的多个活动模式。对于每个活动模式，提取候选动作规则。每个候选动作规则指定了所述动作发生时的一个或更多个前提条件。从多个候选动作规则中确定用于所述动作自动化的一个或更多个优选的候选动作规则。

结合附图，一个或更多个实施例的上述和其他方面以及优点将从以下详细描述中变得显而易见，通过示例的方式图示了一个或更多个实施例的原理。

附图说明

为了更全面地理解实施例的性质和优点以及优选的使用方式，应参考以下结合附图理解的详细描述，其中：

图1示出了根据一些实施例的通信系统的示意图；

图2示出了根据一些实施例的包括电子设备的系统的架构的框图，该电子设备包括规则选择器处理应用；

图3示出了根据一些实施例的规则选择器处理流程；

图4示出了根据一些实施例的在规则选择器处理中使用的规则选择度量的示例表；

图5示出了根据一些实施例的规则选择的减少和推荐；

图6示出了根据一些实施例的跨群体的示例通用规则的表；

图7示出了根据一些实施例的用于添加规则的示例界面；

图8示出了根据一些实施例的用于已保存的规则的示例界面；

图9示出了根据一些实施例的用于修改规则的示例界面；

图10示出了根据一些实施例的用于示例性用户的智能电视(TV)规则的示例表；

图11示出了根据一些实施例的用于示例性用户的情景驱动规则的示例表；

图12A至图12C示出了根据一些实施例的用于规则设置、规则调用和个性化提醒的智能设备使用情况；

图13A至图13B示出了根据一些实施例的用于通过得出复杂的个性化规则来自动化用户动作的智能设备使用情况；

图14A至图14C示出了根据一些实施例的用于预测用户动作和情景动作卡/快捷方式的呈现的智能设备使用情况；

图15示出了根据一些实施例的用于确定动作自动化的优选规则的进程的框图；

图16是示出信息处理系统的高级框图，该信息处理系统包括实现一个或更多个实施例的计算系统。

具体实施方式

以下描述是为了说明一个或更多个实施例的一般原理的目的，而不意味着限制本文所要求的发明构思。此外，在此描述的特定特征可以在各种可能的组合和排列的每一个中与其他描述的特征结合使用。除非本文另有明确定义，否则应给予所有术语以最广泛的解释，包括来自说明书的隐含的含义以及本领域技术人员所理解的和/或如字典、专著等所定义的含义。

应当指出，“至少一个”一词是指随后的元素的一项或更多项。例如，“a、b、c或其组合中的至少一个”可以分别解释为单独的“a”、“b”或“c”；或“a”和“b”组合在一起，或“b”和“c”组合在一起；“a”和“c”组合在一起；或“a”、“b”和“c”组合在一起。

一个或更多个实施例提供了确定动作自动化的优选规则。一些实施例包括一种方法，该方法包括使用电子设备基于域信息来确定动作。获取与动作相关联的活动模式。对于每个活动模式，确定候选动作规则。每个候选动作规则指定动作发生时的一个或更多个前提条件。从用于动作自动化的多个候选动作规则中确定一个或更多个优选的候选动作规则。

在一些实施例中，通过设计和实现规则选择器处理来解决如何向智能手机用户呈现规则的小子集并允许智能手机用户交互式地选择动作规则的问题，该规则选择器处理是为智能手机(或功能类似的智能设备)用户从呈现给用户的一小组汇总规则中提供用于浏览、修改和选择动作规则的交互式规则选择工具。

在一些实施例中，规则选择器处理自动建议规则，并为用户提供选择和修改建议的规则。现代无处不在的计算系统(例如智能手机、可穿戴设备和智能TV)从用户那里收集了大量的情景信息。例如，智能手机收集用户情景，诸如用户的日常活动(用餐、通勤、锻炼等)、设备活动(诸如，所用的应用、执行的应用动作、短信服务(SMS)和呼叫日志)以及用户的各种粒度的语义场所(诸如家庭、工作、咖啡馆、隔间或客厅)。情景数据可以通过多种方式丰富用户体验，诸如向用户呈现最相关的给出当前情景的应用，基于用户情景推荐事件或内容，甚至通过利用当前情景来提高语音助手的功能。情景识别也可以通过允许用户指定情景感知的条件动作规则来丰富用户体验。通常，条件动作规则的形式为：“如果满足某些情景前提条件，请执行一些设备动作”。在商业上，条件动作规则已由IFTTT(If-This-Then-That)实现，IFTTT是一个免费平台，允许用户跨流行的手机平台以及在诸如智能家居自动化、智能手机动作自动化和提醒以及甚至汽车的任务自动化等各种领域方面指定和执行条件动作规则。IFTTT规则允许用户在适当的情景中明确地频繁地自动执行重复的任务或接收智能提醒和通知。

自动执行设备动作或显示提醒的本质方法是将问题表达为用户行为预测问题。例如，如果预测用户将音量设置为高置信度静音，则使智能手机静音或提醒用户这样做。IFTTT规则在一部分用户中普及的主要原因是，它们在发生动作自动化或提醒的情况下为最终用户提供了更多控制和透明度，从而使他们可以根据需要添加和删除规则。但是，IFTTT完全依赖最终用户来指定他们希望自动执行的规则。这给用户增加了负担，使得用户基于他们个人行为模式的记忆来仔细指定他们自己的规则。可替代地，拥有普通人的典型动作规则库并不总是有用的，因为针对每个个体发现的绝大多数动作规则都是高度个性化的。应该注意的是，即使对于在多个规则之间共享的通用动作，在样本用户之间共享的这些通用动作的唯一规则的比例也很低。在一个实验中，显示了714个唯一规则用于用户之间通常共享的动作，但是这些唯一规则中只有59个也由所有用户共享。因此，推荐的绝大多数规则应该是适用于特定用户的个性化规则，这强烈激发了对个性化和交互式规则选择界面的需求。在一些实施例中，规则选择器处理通过自动挖掘并向用户呈现一小组汇总的动作规则，并使用户能够通过规则选择界面交互地选择动作规则，从而解决了常规问题。

在一些实施例中，规则选择器处理为条件动作规则选择提供了完整的端到端接口，该接口：(i)收集与用户相关联的情景数据，(ii)挖掘并选择少量候选条件动作规则以最大化规则的重要性并减轻规则的冗余性，并且(iii)提供处理以允许最终用户浏览、修改和选择他们想在日常生活中自动执行的已挖掘的条件动作规则。例如，规则选择器处理可以在用户处于隔间时提供用于为智能手机充电的智能提醒，而其他规则选择器处理可以提供另一规则，该另一规则基于用户的行为模式在智能手机上自动执行音乐播放列表。一些实施例提供对共现(co-occurrence)的条件动作规则的选择。

在一些实施例中，规则选择器处理为智能手机用户提供了利用通过对移动情景数据进行模式挖掘而发现的候选规则来创建个性化条件动作规则的能力。为了减少从用户行为模式生成的大量候选规则，实现了规则选择器处理，以基于四个规则选择度量来选择最重要的条件动作规则，这些度量对于智能手机用户而言很容易解释：一个规则冗余度量(总动作范围)，以及三个规则重要性度量(置信度、间隔计数和情景特定性)。

在一些实施例中，规则选择器处理提供交互式规则探索和选择，该交互式规则探索和选择基于调整规则选择度量、关注规则的选择以及如果必要时在决定将规则纳入日常生活之前对规则的修改，为智能手机用户提供浏览所挖掘的条件动作规则的不同集合。可以将规则选择器处理应用于来自智能家居、TV收视率和数字健康监控的公共情景数据集，以在这些领域中实现自动化。

在一些实施例中，推荐的每个动作规则具有以下形式：(前提条件->动作)，其中前提条件可以是以下模式类型的任意组合：共现，当A、B和C一起出现时，执行动作D(例如，在星期六上午、晴天并且温度>20℃时，提醒我去跑步)；序列，在依次执行A、B和C之后，执行动作D(例如，在关闭卧室灯后，将手机设置为振动，将智能手机连接至充电器，而后播放手机上的“睡眠”播放列表)；周期性和时间性，我最后执行动作A、B和C后N分钟，请执行动作B(例如，到达办公室两个小时后，提醒我从送餐服务订购食物)。

在一些实施例中，基于同时优化四个规则度量，可以将成千上万个候选条件动作规则按动作汇总为一小组4-5个条件动作规则。

1)：平均规则置信度：对于每个动作规则，规则置信度定义为在满足前提条件时用户将要执行目标动作的似然率。即，规则置信度是条件概率P(动作|前提条件)。优选推荐规则置信度高的规则，即用户更有可能执行自动化的目标动作。例如，如果用户在通勤回家的时间中仅有50％的时间播放Bollywood播放列表，则规则{通勤回家}->播放音乐应用Bollywood播放列表，对于规则自动化来说是一个糟糕的选择。但是，如果用户在通勤回家的时间中有95％的时间播放自己喜欢的新闻，则规则{通勤回家}->播放我喜欢的新闻标题是规则自动化的更好选择。

2):平均规则特异性：对于每个动作规则，规则特异性定义为动作规则中前提条件的特定程度。期望选择具有高度特异性并且具有尽可能具体的规则以提高自动动作的时机的有效性。即，规则特异性是先验概率(1-P(前提条件))的倒数。例如，{“在家”}的前提条件不是很明确，并且特异性很低，因为它发生的频率很高，并且具有较高的先验概率(较低的先验倒数)。另一方面，{“在厨房”、“烹饪早餐”}的前提条件具有很高的特异性，因为它每天上午最多只出现一次。即，{“在厨房”、“烹饪早餐”}的先验概率的倒数很高。

3):总动作范围：对于我们推荐的条件动作规则集，总动作范围是规则集涵盖的不同目标用户动作的百分比。例如，如果推荐两个规则来提醒电池充电：{在办公室中，电池电量不足50％}和{在办公室中，上午10点至11点之间}是一个糟糕的选择，因为它仅涵盖50％的用户充电动作。但是，如果推荐以下两个电池充电提醒动作规则：{在办公室，电池电量<50％}和{在家里，电池电量<25％}，这是一个更好的选择，因为它涵盖了95％的用户充电动作。

4):规则数量：希望在对上述三个度量最大化的同时，最小化推荐给用户的规则数量。期望向最终用户推荐尽可能少的规则，以在动作自动化方面最大程度地提高用户便利性，并在建议和启用规则时最小化用户中断。

在一些实施例中，最大化总动作范围同时最小化所生成的规则的数量对于确保通过条件动作规则将动作自动化的效用最大化给最终用户是重要的，同时最小化由于过多规则建议引起的用户烦恼。规则选择器处理向最终用户推荐一小组条件动作规则，以自动执行任何目标动作，同时优化以下四个度量：最大化动作范围；最小化规则数量，以最小化由于过多规则建议引起的用户烦恼；最大化规则置信度；以及最大化规则的特异性。与常规规则汇总不同的是，所有常规工作都集中在最大程度地提高单个规则重要性度量和/或汇总规则所涵盖的模式总数(模式范围)上。现有的工作都没有集中于最大化所生成的汇总规则所涵盖的用户目标动作的总数(总动作范围)。实施例的一个优点是，与集中在最大化图案范围上的传统工作相比，被汇总的规则涵盖的总动作被最大化，这确保了所生成的条件动作规则显着提高了最终用户在自动化动作中的便利性。

图1是根据一个实施例的通信系统10的示意图。通信系统10可以包括发起传出通信操作的通信设备(发射设备12)和通信网络110，发射设备12可以使用该通信设备来发起和进行与通信网络110内的其他通信设备的通信操作。例如，通信系统10可以包括从发射设备12(接收设备11)接收通信操作的通信设备。尽管通信系统10可以包括多个发射设备12和接收设备11，但是为了简化附图，在图1中每种仅示出了一个设备。

可用于创建通信网络的任何合适的电路、设备、系统或它们的组合(例如，包括通信塔和电信服务器的无线通信基础设施)可以用于创建通信网络110。通信网络110能够使用任何合适的通信协议来提供通信。在一些实施例中，通信网络110可以支持例如传统电话线、有线电视、Wi-Fi(例如，IEEE802.11协议)、

高频系统(例如，900MHz、2.4GHz和5.6GHz通信系统)、红外线、其它相对本地化的无线通信协议或它们任意组合。在一些实施例中，通信网络110可以支持无线和蜂窝电话以及个人电子邮件设备(例如，

)使用的协议。这样的协议可以包括例如GSM、GSM加EDGE、CDMA、四频和其他蜂窝协议。在另一个示例中，远距离通信协议可以包括Wi-Fi和用于使用VOIP、LAN、WAN或其他基于TCP-IP的通信协议发出或接收呼叫的协议。当位于通信网络110内时，发射设备12和接收设备11可以在诸如路径13的双向通信路径上或者在两个单向通信路径上进行通信。发射设备12和接收设备11都能够启动通信操作并接收已启动的通信操作。

发射设备12和接收设备11可以包括用于发射和接收通信的操作的任何合适的设备。例如，发射设备12和接收设备11可以包括但不限于智能手机、移动电话设备、电视系统、照相机、便携式摄像机、具有音频视频功能的设备、平板电脑、可穿戴设备、智能家电、智能相框，以及能够进行无线通信(借助或不借助无线支持附件系统)或通过有线路径(例如使用传统电话线)进行通信的任何其他设备。通信操作可以包括任何适当形式的通信，包括例如数据和控制信息、语音通信(例如电话呼叫)、数据通信(例如电子邮件、文本消息、媒体消息)、视频通信或它们的组合(例如，视频会议)。

图2示出了架构系统100的功能框图，该架构系统100可以用于确定使用电子设备120(例如，智能手机、移动电话设备、电视(TV)系统、照相机、便携式摄像机、具有音频视频功能的设备、平板电脑、平板设备、可穿戴设备、智能家电、智能相框、智能灯具等))的动作自动化的个性化优选规则。发射设备12(图1)和接收设备11都可以包括电子设备120的一些或全部特征。在一个实施例中，电子设备120可以包括显示器121、麦克风122、音频输出123、输入机构124、通信电路125、控制电路126、照相机128、规则选择器处理应用129(用于对电子设备120或与云或服务器130组合地进行如本文中所讨论的规则选择器处理)，并且与通信电路125进行通信以与云或服务器130获得/提供该规则选择器处理的信息；并且可以包括但不限于以下所述的示例和实施例的任何处理以及任何其他合适的组件。在一个实施例中，提供了应用1-N 127，并且可以从云或服务器130、通信网络110等获得应用，其中N是等于或大于1的正整数。

在一个实施例中，音频输出123、显示器121、输入机构124、通信电路125和麦克风122采用的所有应用可以由控制电路126互连和管理。在一个示例中，可以将能够将音乐发送到其他调音设备的手持音乐播放器合并到电子设备120中。

在一个实施例中，音频输出123可以包括用于向电子设备120的用户提供音频的任何合适的音频组件。例如，音频输出123可以包括电子设备120中内置的一个或更多个扬声器(例如，单声道或立体声扬声器)。在一些实施例中，音频输出123可以包括远距离地耦接到电子设备120的音频组件。例如，音频输出123可以包括耳麦、耳机或耳塞，其可以通过电线(例如，通过插孔耦接到电子设备120)耦接到通信设备或无线地(例如，

耳机或

耳麦)耦接到通信设备。

在一个实施例中，显示器121可以包括用于提供用户可见的显示器的任何合适的屏幕或投影系统。例如，显示器121可以包括合并入电子设备120中的屏幕(例如，LCD屏幕、LED屏幕、OLED屏幕等)。作为另一示例，显示器121可以包括可移动显示器或投影系统，用于在远离电子设备120(例如，视频投影仪)的表面上提供显示内容。显示器121可用于在控制电路126的指导下显示内容(例如，与通信操作有关的信息或与可用媒体选择有关的信息)。

在一个实施例中，输入机构124可以是用于向电子设备120提供用户输入或指令的任何合适的机构或用户界面。输入机构124可以采取多种形式，例如按钮、小键盘、拨盘、点击轮、鼠标、视觉指示器、遥控器、一个或更多个传感器(例如，相机或视觉传感器、光传感器、接近传感器等)或触摸屏。输入机构124可以包括多点触摸显示屏。

在一个实施例中，通信电路125可以是可操作地连接到通信网络(例如，图1的通信网络110)并且将通信操作和媒体内容从电子设备120传输到通信网络内的其他设备的任何合适的通信电路。通信电路125可以用于使用如下任何合适的通信协议来与通信网络进行接口连接：例如Wi-Fi(例如，IEEE 802.11协议)、

高频系统(例如，900MHz、2.4GHz和5.6GHz通信系统)、红外、GSM、GSM加EDGE、CDMA、四频和其他蜂窝协议、VOIP、TCP-IP或任何其他合适的协议。

在一些实施例中，通信电路125可以用于使用任何合适的通信协议来创建通信网络。例如，通信电路125可以使用短距离通信协议来创建短距离通信网络以连接到其他通信设备。例如，通信电路125可以用于使用

协议创建本地通信网络，以将电子设备120与

耳机耦接。

在一个实施例中，控制电路126可以用于控制电子设备120的动作和性能。控制电路126可以包括例如处理器、总线(例如，用于将指令向电子设备120的其他组件发送)、存储器(memory)，存储设备(storage)或用于控制电子设备120的动作的任何其他合适的组件。在一些实施例中，处理器可以驱动显示器并处理从用户界面接收的输入。存储器和存储设备可以包括例如高速缓存、闪存、ROM和/或RAM/DRAM。在一些实施例中，存储器可以专用于存储固件(例如，用于诸如操作系统、用户界面功能和处理器功能的设备应用)。在一些实施例中，存储器可以用于存储与其他设备相关的信息，利用该其它设备电子设备120执行通信操作(例如，保存与通信操作相关的联系信息或存储与用户选择的不同媒体类型和媒体项目相关的信息)。

在一个实施例中，控制电路126可以用于执行在电子设备120上实现的一个或更多个应用的动作。可以实现任何合适数量或类型的应用。尽管下面的讨论将列举不同的应用，但是应当理解的是，一些或所有应用可以组合成一个或更多个应用。例如，电子设备120可以包括应用1-N 127，其包括但不限于：自动语音识别(ASR)应用、OCR应用、对话应用、地图应用、媒体应用(例如QuickTime、MobileMusic.app或MobileVideo.app)、社交网络应用(例如

等)、日历应用(例如，用于管理事件、预约等的日历)、互联网浏览应用等。在一些实施例中，电子设备120可以包括一个或更多个可操作用于执行通信操作的应用。例如，电子设备120可以包括消息应用、电子邮件应用、语音邮件应用、即时消息应用(例如，用于聊天)、视频会议应用、传真应用或任何其他合适的应用来执行任何适当的通信操作。

在一些实施例中，电子设备120可以包括麦克风122。例如，电子设备120可以包括麦克风122，以允许用户在通信操作期间发送用于应用1-N 127的语音控制或导航的音频(例如，语音音频)，或者将其作为建立通信操作的方法或使用物理用户界面的替代方法。麦克风122可以合并入电子设备120中，或者可以远距离耦接到电子设备120。例如，麦克风122可以合并入有线耳机中，麦克风122可以合并入无线耳机中，麦克风122可以合并入遥控设备中等等。

在一个实施例中，相机模块128包括一个或更多个相机设备，该相机设备包括用于捕获静止和视频图像的功能，编辑功能，用于发送、共享照片/视频等的通信互操作性等。

在一个实施例中，电子设备120可以包括适合于执行通信操作的任何其他组件。例如，电子设备120可以包括用于耦接到主机设备、辅助输入机构(例如，开启/关闭开关)或任何其他合适的组件的电源、端口或接口。

图3示出了根据一些实施例的可由规则选择器处理应用129实现的规则选择器处理流程300。规则选择器处理的输入分为两类：用户的背景情况情景310和想要选择条件动作规则的目标用户动作320。根据时间330，将间隔分为例如上午、下午和晚上。示出了期望的动作320，例如，给电话充电、观看

给妈妈打电话、查看

等。示出了选择325，其沿着指示时间330的线是可选择的。规则选择器处理的频繁间隔项集挖掘340挖掘频繁间隔情景项集，以限制条件动作规则的可能的前提条件集合。内容驱动候选动作规则生成350处理生成高质量的候选条件动作规则。这里的难点之一是定义正确的规则选择度量，以过滤除低质量的规则。规则选择器处理的规则挖掘器规则汇总360将潜在的数百个候选规则汇总为一小组条件动作规则370，以供最终用户选择。

在一些实施例中，规则选择器处理有两组输入，情景310和动作320。情景310(C)的集合，每个情景c_i∈C具有唯一的情景描述符c_i ^d(例如在家、上午或通勤)，并且在检测到该情景为真时包含一系列时间间隔c_i ^T。情景包括情境状态指示器，例如用户的语义场所、一天中的时间段或用户的活动。例如，表示用户在家的情景c1表示如下：

c₁＝{c₁ ^d＝At Home,c₁ ^T＝[2017:Nov:1:(12:23AM-11:05AM),2017:Nov:1:(7:02PM-8:04PM),...]}。

在一些实施例中，第二输入是一组动作320(A)。每个动作aj∈A具有唯一的动作描述符a_j ^d(例如查看

或给手机充电)，并在用户启动该动作时包含一系列时间戳a_j ^T。规则选择器处理挖掘关于用户执行的动作320的规则来作为输入情景310的功能。必须注意，与以间隔表示的情景310不同，用户动作320由瞬时时间戳表示，以便挖掘关于何时由用户发起动作的规则。例如，表示用户执行“开始充电”动作的动作a3表示如下：

a₃＝{a₃ ^d＝Begin Charging,a₃ ^T＝[2017:Nov:1:(10AM),2017:Nov:1:(5:45PM),...]}。

在一些实施例中，基于输入情景310和动作320，规则选择器处理生成表示用户执行特定动作的情景的共现条件条件动作规则的小排名列表。每个动作规则r定义为：{c₁ ^d,...,c_k ^d}→{a^d}，其中每个c_i∈C^d是情景描述符，而a^d∈A^d是该规则预测的目标动作描述符。集合{c₁ ^d,...,c_k ^d}被称为规则的前提条件。动作规则表明，只要所有情景描述符{c₁ ^d,...,c_k ^d}同时为真，则用户频繁执行具有高似然率的动作ad。例如，动作规则{在隔间中，在工作日中午5-6点之间，在办公室中，电池电量<50％}→{开始充电}表示当前提规则中所有五个情景描述符中都同时为真时用户可能开始为手机充电。

在一些实施例中，频繁情景项集挖掘340处理使用频繁项集挖掘发现一组频繁情景项集F。频繁情景项集f∈F定义为C中频繁共存的情景子集。与情景本身的定义类似，每个频繁情景项集f具有：(i)是情景描述符C^d的子集的描述符f d，以及(ii)时间间隔f^T的序列，其指示当f^d中的情景描述符在输入情景310数据中同时出现时的连续时间间隔。举例来说，当观看电视、“在家”、“上午”和“连接到家庭Wi-Fi”的四个情景同时发生时，会观察到一段时间。如果这四个情景在输入情景310数据集上经常同时出现，则发现频繁情景项集f₁∈F具有与C中的原子情景相似的以下属性：

f₁＝{f₁ ^d＝{At Home,Watch TV,Morning,Connected to Home Wi-Fi},f^T＝[2017:Nov:1:(9:03AM-9:40AM),2017:Nov:2:(8:45AM-9:34AM),...]}。为了计算频繁情景项集，在一个实施例中，频繁情景项集挖掘340以1秒的规则间隔对输入情景310数据进行采样。应该注意的是，采样间隔不影响处理的结果，而只需要小于情景改变的粒度即可。在每个时间样本t，频繁情景项集挖掘340创建共现情景篮子(basket)，该共现情景篮子包含其时间间隔在时间t出现的所有情景描述符cd∈C。频繁情景项集挖掘340创建包含了在输入情景数据上的所有时间步的篮子的共现情景篮子B的列表。例如，图3中表示的情景的输入情景篮子如下：[{在家，看电视，上午，已连接到家庭Wi-Fi}，{在家，看电视，上午，已连接到家庭Wi-Fi}，...{上午在家上下班}，...，{办公室，下午，工作，在隔间Wi-Fi场所}，...]。在一些实施例中，此步骤的目标是发现所有频繁子集

使得情景项集f的出现频率比输入情景篮子B中的支持阈值高。通常，支持阈值表示为篮子|B|的数量的百分比。例如，支持阈值1％将会发现在输入情景310数据中至少发生时间的1％的频繁情景项集。为了从输入篮子B中挖掘频繁的情景项集，在一个实施例中，使用了加权项集挖掘方法。由于移动情景数据的连续间隔性质，加权项集挖掘非常适合这种类型的在输入情景篮子中具有很高的冗余度的情景310数据集。

在一些实施例中，挖掘频繁情景项集F的原因是，频繁项集f∈F充当在后续处理中挖掘出的条件动作规则中的前提条件。特别地，对于由规则选择器处理输出的每个动作规则{c₁ ^d,...,c_k ^d}→{a^d}，{c₁ ^d,...,c_k ^d}中的情景描述符集对应于频繁事件的描述符fd项集f∈F。通过首先挖掘频繁情景项集，仅在前提条件是频繁项集f∈F的那些规则中搜索候选条件动作规则，而不考虑情景C的所有可能的2^|C|子集作为潜在的前提条件。直观的是，如果规则前提条件未在F中出现，则动作规则在用户的生活中不会经常出现，因此不值得选择作为提醒或任务自动化的动作规则。

在一些实施例中，与例如模式挖掘应用处理相比，规则选择器处理生成条件动作规则的方式不同。在模式挖掘应用中，条件动作规则是通过在输入篮子中添加情景和动作来得出的。这在计算条件动作规则的置信度时会产生问题，因为与长期情景(例如在家)相比，诸如应用使用之类的动作的频率要低得多。相反，规则选择器处理显式地分隔情景间隔和用户动作，并且仅在输入篮子中包括情景间隔。然后，通过搜索候选规则得出条件动作规则，这些候选规则具有频繁的情景项集作为前提条件，而动作作为后置条件，并且满足以下定义的规则选择度量标准。在一些实施例中，规则选择器处理为每个动作产生少于七个条件动作规则的小集合，以供最终用户选择。相反，常规的模式挖掘处理每个动作产生数百个模式，并且没有解决最终用户进行规则汇总或规则选择的问题。

图4示出了根据一些实施例的在规则选择器处理中使用的规则选择度量的示例表400。表400包括规则(选择)度量410、适用性420和定义430。在一些实施例中，对于规则度量410，从可能规则f→a生成每个动作a∈A的最终条件动作规则R(a)，其中f∈F是任何频繁的情景项集。为了选择|F|的子集对于每个动作a的可能条件动作规则，下面定义四个规则度量410。在选择用于提醒或自动化的条件动作规则时，基于智能手机用户的共同关注点来设计规则量度410。

在一些实施例中，当前提条件频繁情景项集f中的情景描述符为真时，规则置信度的第一规则度量410测量用户执行动作a的似然率。更准确地说，如表400所示，规则置信度衡量的是f^T中时间间隔的比例，其中f^T包含来自a^T的动作a的某些实例。与常规模式挖掘处理不同，常规模式挖掘处理基于单个篮子来测量规则置信度；在一些实施例中，使用情景前提条件的时间间隔来测量规则置信度，从而解决了常规模式挖掘中情景间隔持续时间和用户动作的不平衡问题。例如，考虑动作规则：f₁＝{In Cubicle,Between 5-6PM,Weekday,InOffice,Battery Level<50％}→{Begin Charging}。在例如一个月的数据收集期间，假设规则rr1中的前提条件频繁情景项f为f d＝{在隔间,在下午5-6点之间,工作日,在办公室,电池电量<50％}每个工作日发生20次唯一的间隔；即，|fT|＝20。如果用户在这20个间隔中有15个是在为她的手机充电，则规则置信度被测量为75％。规则置信度是用户对规则进行排名和选择时的重要因素。用户对规则置信度的偏好中观察到的合理可变性取决于用户和动作。对于提醒应用，某些用户并不介意65-75％的较低置信度值，尤其是对于他们希望改变的习惯(例如，记得在工作时为手机充电)时。另一方面，用户希望对动作自动化有很高的信心，以避免出现意外行为。

在一些实施例中，情景特异性的规则度量410测量频繁项集f中的前提条件情景在时间上如何精确。如表400所示，其中出现f的时间性篮子

的数量越少，情景特异性越高。即，较高的情景特异性与频繁的情景项集相关联，这些频繁项集在相对较短的持续时间内发生。例如，考虑动作规则r1＝{工作日}→{开始充电}。前提条件频繁项集f(fd＝工作日)将在5个工作日中的B中每7个篮子中的5个发生。因此，该规则的情景特异性仅为28.57％。另一方面，假设该间隔每天重复一整小时，则动作规则的前提条件r2＝{InCubicle,Between 5-6PM,Weekday,In Office,Battery Level<50％}→{开始充电}每24个篮子中最多有一个发生；因此，该规则的情景特异性更高，为95.83％。在一些实施例中，由于用户在最相关的时间和情景中希望提醒，并且在提醒不适当时不希望被打扰，情景特异性是用户选择规则时最重要的度量之一。例如，与在工作日的随机时间从规则r1发出的提醒相比，用户宁愿从上述规则r2收到充电提醒。

在一些实施例中，用户在选择规则时的另一个重要考虑因素是规则发生时唯一实例的数量。间隔计数测量发生动作a时来自f^T子集的唯一时间间隔的数量。向用户显示间隔计数时，将其标准化为每周的间隔计数。再次针对该度量，可以根据目标动作找到用户优选的可变性。对于诸如为用户频繁执行的智能手机充电之类的动作，在选择规则时用户优选每周较高的间隔计数。对于用户每周仅执行一次或两次的诸如从送餐服务订购的动作，用户可以忍受每周更少的间隔计数。

在一些实施例中，总动作范围的规则量度410测量被规则选择器处理建议用于动作a的规则集合R(a)所涵盖的动作a的实例的比例。与上面讨论的其他三个度量不同，总动作范围适用于一组规则而不是单个规则，并且在呈现给用户之前比较不同的规则集很有用。更正式地，如表400所示，总动作范围衡量aT中动作实例在某些前提条件频繁情景项集间隔f^T中出现的比例，其中f→a是R(a)中包括的一个规则。为了说明动作范围的概念，请考虑三个条件动作规则：

r1＝{In Cubicle,Between 5-6PM,Weekday,In Office,Battery Level<50％}→{Begin Charging}

r2＝{Weekday,Evening,Battery Level<50％}→{Begin Charging}

r3＝{At Home,Late Night}→{Begin Charging}

这些规则中的每一个都涵盖了与集合aT不同的动作实例子集。例如，假设规则r₁涵盖了用户为手机充电的15个实例，规则r₂涵盖了22个唯一的实例；这两个规则的总动作范围是两组分别具有15和22个动作实例的联合。由于这两个规则都与晚上为手机充电有关，因此可以发现这两个规则的并集仅涵盖用户为她的手机充电的23个唯一实例。另一方面，规则r2和r3涵盖了更多样化的电话充电方案，即在家中的晚上和深夜充电方式；因此这些规则一起可以涵盖例如40个用户为她的手机充电的实例。因此，规则集{r2,r3}的总动作范围高于规则集{r1,r2}的活动范围。动作范围是最终用户选择规则的有用因素。由于动作范围在所显示的规则集中实施了某种多样性，因此用户有更多机会选择各种条件动作规则(例如为家庭和工作收取提醒)和/或获取更多情景前提条件示例以定义自己的条件规则。

图5示出了根据一些实施例的规则选择的减少和推荐。在一些实施例中，规则选择器处理首先通过对三个规则(选择)度量410(图4)进行阈值处理来消除大部分规则，然后汇总规则以消除冗余并使动作范围最大化。如图3所示，候选规则生成350的目的是从每个动作的条件动作规则所有可能的|F|的集合中生成高质量的候选条件动作规则。为了为每个动作a生成高质量的候选规则，在一些实施例中，仅从F中选择满足上述三个规则选择度量上的最小阈值的可能条件动作规则的子集：置信度、情景特异性和间隔计数。图5示出了针对示例用户的候选规则生成器350所减少的规则数量以及“开始充电”的目标动作。最初有1981个可能的条件动作规则510用于开始充电，其中目标动作在来自F的频繁情景项集中至少发生一次。候选规则生成350处理对三个规则选择度量应用最小阈值以将高质量的数量候选规则减小至仅202个条件动作规则520。规则选择器处理将置信度、情景特定性和间隔计数这三个质量度量视为独立参数，最终用户可以通过设置最小阈值来对该独立参数进行控制。总动作范围的第四个度量被视为用户无法真正控制的因变量，并且是规则汇总360处理试图尽可能最大化的优化度量。其背后的原因是，用户可能最关心控制情景特异性以及独立地间隔计数。如果用户对规则选择器处理所提供的动作范围不满意，他们自然地会尝试降低自变量度量(例如间隔计数)的阈值参数，以查看是否生成更多规则来涵盖更多用户的动作。

候选规则生成中的关键挑战是为三个规则选择度量中的每一个确定阈值参数。在一些实施例中，下面描述的规则选择器用户界面向最终用户提供控制每个度量的阈值参数。这背后的理由是，有可能无法对每个满足所有用户度量的单个阈值设置；例如，对于开始充电事件，一些用户可以选择间隔计数较低的规则，而其他用户可以选择每周具有较高置信度和间隔计数的规则。即使对于单个用户，用户也可能会为不同的目标动作选择不同的阈值设置。例如，开始充电动作的间隔时间数较高，而

动作的订单的每周间隔时间数较低。

在一些实施例中，规则汇总360(图3)处理的目标是生成少数多样的条件动作规则以呈现给用户，以最大化总动作范围和消除规则冗余为目标。规则汇总360处理消除了条件动作规则中的大量冗余，并生成了一小组条件动作规则，这些条件动作规则涵盖了候选规则所涵盖的所有动作实例。对于图5中的开始充电示例，将202个候选条件动作规则520汇总为5个规则530的较小集合，这些规则涵盖了最初由较大202个规则集520涵盖的所有81％的用户充电动作。考虑由候选规则生成350(图3)处理生成的、针对动作a∈A的一组高质量候选条件动作规则R(a)。假设这些条件动作规则涵盖a的动作实例的子集

规则汇总360处理的目标是查找更小的、汇总的规则集合R(a)，其涵盖R(a)所涵盖的动作实例aT的尽可能多的可能集合。由于R(a)中的每个规则涵盖aT中动作实例的不同子集，并且目标是查找规则

的子集(该子集涵盖aT所涵盖的尽可能多的动作实例)，因此优化问题减少到找到集合的不确定性多项式时间(NP)-完全问题。为了解决该NP-完全问题，在一些实施例中，利用了众所周知的贪婪解决方案，该贪婪解决方案将规则递增地添加到R(a)，其中在每个处理步骤中，所涵盖的规则涵盖了所添加的aTi中最大数量的未发现动作实例，如果通过添加新规则无法涵盖所有未发现的动作实例，则不再添加规则。贪婪解决方案显示在下面的算法1中，并在O(n²)中，其中n＝|R(a)|输入到规则汇总算法的高质量候选条件动作规则的数量；蛮力方法将需要O(2ⁿ)极高的时间复杂度来分析所有2n个可能的规则子集，以查看哪些子集具有较高的动作范围。在下面的算法1中，

计算集合R中规则的总动作范围；在一些实施例中，为包含该规则所涵盖的动作实例的每个规则维护查找字典，从而允许有效地计算任何规则集R的动作范围。

算法1:规则选择器处理的规则汇总360处理

输入：用于动作a的候选条件动作规则集R(a)

输出：汇总的条件动作规则集

1Set summarized rule set R(a)＝{}

while|R(a)|>0do

2select rule

such that

r＝arg max

coverage(r∪R(a))

if coverage(r∪R(a))＝coverage(R(a))then

3break

4end

5add rule r to set

remove rule r from set R(a)

6end

7Output summarized rule set R(a).

规则汇总是规则选择器处理中处理的另一个重要部分。与其向用户呈现50-100条候选条件动作规则，不如将其汇总为少于10条来呈现各种多样的条件动作规则，这些条件动作规则通常捕获候选规则涵盖的所有动作实例。与大量冗余候选规则相比，用户浏览多样的、汇总的条件动作规则更容易，也更有帮助。此外，如果用户实际希望的规则之一作为冗余规则被删除了，则用户可以使用下面讨论的规则修改用户界面通过规则选择器处理轻松修改紧密相关的规则输出，以满足他们的需求。

在一些实施例中，使用瘦移动客户端和云/服务器130架构在规则选择器处理应用129(图2)中实现规则选择器处理。移动情景和动作数据记录在智能手机上，并由移动设备定期上传到云/服务器130数据库。在云/服务器130上，基于记录的原始传感器数据执行进一步的情景(包括诸如Wi-Fi场所、重要语义场所以及诸如通勤之类的活动)推断。然后，规则选择器处理在情景/动作数据日志上在云/服务器130上运行以生成汇总的条件动作规则。下面讨论了规则探索如何为用户提供浏览、修改和选择条件动作规则的用户界面详细信息。在一些实施例中，规则选择器处理可以被实现为Java jar库，完全在移动设备120(图2)上运行规则选择器处理是可能的。

为了分析规则选择器的处理性能，收集了移动用户情景和动作。下面列出了收集的移动动作和情景的列表。使用两个不同的移动用户数据集进行分析。基于从200个选择性智能手机用户收集的数据，规则选择器处理的在线、定量性能方面各收集了100天。数据收集工具用于为较小的一组智能手机用户收集以下所示的相同情景和动作。收集的情景的列表包括：语义的场所：家庭/工作/重要位置ID，Wi-Fi场所：在隔间/Wi-Fi场所ID，时间间隔：时间段(上午，下午，...)，工作日/周末，星期几，一天中的小时(0-23)，电池电量：离散成多个箱(bin)(0-25％，25-50％，0-50％等)，活动：使用Android活动识别API所获得的、在家中和办公室通勤(作为附加活动)以及已连接的Wi-Fi网络的SSID名称。收集的动作的列表以及用户选择规则的列表包括应用使用情况：启动的应用名称，呼叫动作：呼叫的匿名联系人ID，SMS动作：已发消息的联系人的匿名ID，以及开始充电：为手机充电动作。在上面的情景和动作列表中，需要注意的是，可以使用API记录许多情景和所有动作。下面是规则选择器处理从原始传感器数据中推断出的三个主要情景：讨论了Wi-Fi场所、重要的语义场所以及通勤活动。

使用Wi-Fi扫描相似性度量，检测Wi-Fi场所的出入口，然后将每次Wi-Fi场所访问聚集到一组重要的Wi-Fi场所的通用集合。为了解决该方法的一些性能缺陷，将联合Tanimoto Wi-Fi距离度量标准替换为交叉Tanimoto距离；相交距离度量仅在两次Wi-Fi扫描中的公共MAC地址之间计算Tanimoto距离，从而减少了由于缺少MAC地址而引起的场所簇(cluster)错误。同样，利用活动识别API推断出的空闲活动可将空闲间隔内的所有Wi-Fi扫描强制执行为同一Wi-Fi场所的一部分；这种启发式方法进一步提高了Wi-Fi场所检测的准确性。对于检测到的每个Wi-Fi场所，场所ID将用作规则挖掘中的情景。通过将Wi-Fi场所标记为隔间来作为情景，在该Wi-Fi场所中用户每天在工作在隔间时花费最多时间。

从纬度/经度位置数据流中检测重要场所是无处不在的计算社区中一个经过广泛研究的主题。在一些实施例中，该算法基于GPS日志来检测位置访问，然后将各个位置访问聚集到重要的位置簇中。规则选择器处理仅保留用户在其中花费至少五分钟的位置簇。选择五分钟作为下限，以检测用户仅在短时间停留的潜在重要场所(例如上午的咖啡店)。每个非空距离簇都分配有唯一的重要位置ID，并用作规则挖掘的情景。为了处理丢失和过时的位置数据，将Wi-Fi场所检测算法的结果与使用GPS日志的重要语义场所检测相融合。由于如今的大多数位置都具有附近的Wi-Fi网络，因此该方法解决了许多数据问题，这些问题否则将仅使用GPS数据破坏重要的位置检测。将数据聚集到重要位置后，将使用基于启发式的方法确定家庭和办公室位置。所使用的假设是，用户在晚上花费大量时间的位置是他们的家庭位置，而他们在工作日在上午8点至下午6点之间花费大量时间的位置是他们的办公室位置。另外，事实(Factual)用于在语义可用的商户标签(例如

或

)上标记非办公场所和非住宅场所。

使用上述重要语义场所检测处理，在一些实施例中使用了用户何时通勤的推断。通勤检测基于以下两条信息：1)从

活动识别API获得的车载活动识别数据，以及2)通过重大语义场所检测推断出的家庭和办公室位置。为了识别通勤，使用启发式方法如下：如果上次观察到的位置是家，并且是工作日的上午，则将活动分类为通勤上班；如果上次观察到的位置是办公室，并且是工作日的晚上，则将活动分类为通勤回家。

在一些实施例中，在规则选择器处理中，未将单个阈值分配给规则置信度、情景特异性和间隔计数的三个独立的规则选择度量。相反，提供用户使用用户界面选择每个参数阈值。由于期望非专家用户充分探索可能的参数阈值的空间是不合理的，因此在某些实施例中，为三个度量中的每个度量提供了三个方便的阈值设置(低、中和高)，如下表I所示。低、中和高的阈值设置是基于在样本主体的要求之下与样本主体的初步讨论来理解的，并基于由每个阈值设置的规则选择器处理所生成的规则集的经验差异来选择的。避免了阈值过高或过低而无法产生任何规则或对最终用户有用的规则。

【表1】

在一些实施例中，给定表I中的3个参数和阈值设置，用户可以探索27种可能的参数组合。基于候选规则的数量和规则选择器处理生成的最终汇总规则，分析这些参数阈值的影响。表II显示了三种代表性参数设置的规则数量：对于同一样本用户，所有阈值分别设置为低、中和高。在示例分析中，需注意的是，每个动作有2000多个可能的规则。在一些实施例中，规则生成将智能手机用户关心的规则选择度量阈值显着地减少可能的规则到一组高质量候选规则。对于低设置和中设置，可以观察到候选规则的数量仍然太大(分别为469和45)，无法分别呈现给最终用户。在一些实施例中，规则选择器处理将这些候选规则汇总为少于十个规则以呈现给用户。

【表2】

表III提供了评估了样本数据集中200个样本智能手机用户中，规则选择器处理对所有参数的中设置的动作范围最大化的程度。平均而言，每个用户有20条具有高质量候选规则的动作，平均每个操作有66条候选规则。这些候选规则涵盖了用户唯一动作实例的74.5％。规则选择器处理只能在6-7条规则中涵盖66条规则所涵盖的所有动作实例；样本用户高度赞赏这一点，因为他们能够浏览并从数量少得多的各种条件动作规则集中进行选择。

【表3】

规则类型	有规则的动作数	每个动作的规则数	动作总范围
				可能的规则	119	226	100％
高质量的候选规则	20	66	74.5％

图6示出了根据一些实施例的跨群体的示例通用规则的表600。在表600中，随着共享动作和规则的用户群体的百分比变化，分析了通用动作和通用规则的数量。总体而言，可以观察到样本用户之间几乎没有通用的动作和规则。例如，当仅查看20％的用户时，可以观察到样本用户中具有高质量规则的通用动作从258个动作显着下降到仅11个动作。结果，跨用户共享的通用规则数量也大大减少。总体而言，观察到只有4条规则适用于50％以上的用户，只有15条规则适用于30％以上的用户。

图7示出了根据一些实施例的用于添加规则的示例界面700。在一些实施例中，规则选择器处理包括基于网络的用户界面700，其允许用户浏览所生成的汇总规则，根据需要修改规则并保存用于自动化的条件动作规则的最终列表。在一些实施例中，界面700可以包括用户选择710、动作选择720、参数选择730以及确定的规则740的显示。界面700允许用户通过首先选择目标动作(例如，开始充电、从送餐服务订购等)以及用于三个规则选择度量的阈值参数(即，低、中和高)来获取汇总规则。如表I所示，阈值选择可以被限制为三个预定义的值，以使非专业用户的探索变得容易。在选择阈值设置之后，用户可以选择通过各种参数组合获取规则，并通过界面700将其添加到每个动作的规则列表中，通过界面900(图9)查看为每个动作保存的规则列表，并在通过接口1000保存之前(如有必要)修改规则(图10)。修改界面1000允许用户去除前提条件中的情景并根据需要添加新的情景。此外，探索记录了各种用户操作，包括：所选择的用于获取和浏览规则的参数值；保存了哪些规则；以及如果修改了规则，则包括原始和修改后的规则版本。

图8示出了根据一些实施例的用于保存的规则的示例界面800。界面800可以包括用户选择810、动作选择820和获取规则选择830。

图9示出了根据一些实施例的用于规则修改的示例界面900。界面900可以包括选择情景条件910和添加新条件920的屏幕。

在一些实施例中，依据个人偏好和目标动作，为用户分配不同的优先级给各个规则选择度量。用户可以依据操作选择参数设置，并可以修改规则以根据其需求和目标进行调整。在某些实施例中，可以使用细粒度的情景来提高规则的实用性。

应当指出，用户通常希望将规则用于(i)提醒(例如充电提醒)、(ii)推荐(例如来自送餐服务的餐厅推荐)和(iii)通知(例如，来自社交媒体应用的低优先级通知)。这些应用有助于防止负面的用户体验，例如电池电量低的手机。实际上，样本用户始终将电池充电提醒评估为有用或非常有用。另外，用户抱怨他们是如何最终关闭了某些应用的通知，因为这些应用在错误的情况下在错误的时间发送了超载的消息。更多的基于规则的智能通知方法可以将某些应用的通知限制在某些相关情景中，例如在工作日(P07)上午8点至下午6点以外的社交媒体应用通知以及仅在星期五晚上和星期六上午(P01)提供

建议，从而解决此问题。一些实施例为重要的应用提供了有意义的快捷方式。例如，在驾驶时能够访问地图应用非常重要。类似地，用户在工作中吃午餐时可能希望使用简单的视频应用快捷方式。应该围绕上述三个使用情况设计基于规则的助手，但仍应具有灵活性以允许将来出来的使用情况集。

图10示出了根据一些实施例的用于示例性用户的智能TV规则的示例表1000。在一些实施例中，规则选择器处理可以应用于诸如智能电视系统的智能设备。可以为例如喜爱的节目、诸如新闻的子流派、频道等建立提醒规则。可以为何时显示针对某些流派(例如，电影、情景喜剧等)的推荐建立规则。表1000包括示例目标动作1010和汇总规则1020。为录制节目(例如，从机顶盒)可以设置其他规则。可以针对各种目标动作(例如观看电影、新闻或特定频道或电影类型)生成汇总规则。这样的规则在允许观众自动执行其电视动作或接收基于其行为模式的关于他们可能感兴趣的当前观看内容的模式感知推荐方面非常有用。

图11示出了根据一些实施例的用于示例性用户的情景驱动规则的示例表1100。在一些实施例中，可以针对不同的相关情景来个性化TV用户界面。可以预测用户动作，并且可以在适当的情景中提供动作快捷方式。可以基于预测的用户操作来推荐内容(例如，针对情景喜剧与电影的推荐)。如图所示，表1100包括示例输入情景间隔1110和相关动作1120。

图12A至图12C示出了根据一些实施例的用于规则设置、规则调用和个性化提醒的智能设备(例如，电子设备120)示例使用情况。图12A示出了基于以下模式的示例显示建议1210：当电池少于50％时，用户通常在3-4PM之间在办公室隔间中对其设备充电。推荐规则1220将基于建议1210中指示的使用模式。在一些实施例中，一旦用户接受建议的条件动作规则，则当满足条件时，智能设备1200可以执行自动化动作或将自动化动作传达给另一设备，以使该设备执行动作。

图12B显示了基于建议规则1220的示例显示提醒1211并指示电池电量不足50％，并且用户在办公室中的隔间中3-4:30-PM之间应为手机充电基于调用的规则1221。

图12C显示了基于用户模式和推荐规则1222的消息和提醒1212，该消息和提醒1212每当周日上午，天气晴朗，温度高于15℃，没有下雨的可能，提醒跑步。还可以显示每周汇总的步数、英里、卡路里等的指示1230。

图13A至图13B示出了根据一些实施例的用于通过得出复杂的个性化规则来自动化用户动作的智能设备1200使用情况。在图13A中，消息和查询1310向用户通知一种模式，即用户在关灯后在他们的卧室时播放“睡眠”播放列表，并且智能设备1200设置为振动，并建议设置制定一个规则，在满足情景时播放“睡眠”播放列表。在图13B中，另一条消息和查询1311通知用户，他们到家时总是在电视上投放

并在通勤回家时观看/收听

并建议设置该动作的自动投放。

图14A至图14C示出了根据一些实施例的用于预测用户动作和情景动作卡/快捷方式的呈现的智能设备1400(例如，图2的电子设备120)使用情况。图14A示出了工作日晚上的情景1410，并且用户在他们的隔间中。基于情景1410，规则选择器处理可以提供以下建议：推荐消息1420向朋友发送消息“乒乓球怎么样？”；推荐消息1430，以从

订购指定餐食；和/或推荐消息1440，以播放轻松的工作音乐。推荐消息1420、1430和1440中的每一个可以例如通过选择指示符箭头从智能设备1400被激活。用户可以通常设置一些推荐消息(例如，在某个时间播放睡眠音乐、给姐姐打电话、调暗灯光等)，并且UI可以进一步允许用户设置持续时间影响规则。

图14B示出了工作日晚上的情景1411，并且用户在他们的卧室中。基于情景1411，规则选择器处理可以提供以下内容：推荐消息1441播放睡眠音乐台；消息1450，询问是否修改闹钟设置；消息1460显示明天的日程表。例如，通过选择指示器箭头，可以从智能设备1400进一步探索或激活消息1441、1450和1460中的每一个。

图14C示出了星期六上午并且用户在家里的情景1412。基于情景1412，规则选择器处理可以提供示出健康状况摘要的以下消息1470；推荐消息1480，查询是否呼叫用户的姐姐；消息1490显示投资概要。可以例如通过选择指示箭头从智能设备1400进一步探索或激活消息1470、1480和1490。在一个实施例中，规则选择器处理可以基于应用/域的类型来调整规则置信度参数。

在一些实施例中，规则选择器处理可以应用于其他领域，例如来自两个领域(智能家居和智能电视)的公共情景数据集，以及应用于使用智能手机改善老年患者的移动性的临床研究数据。规则选择器处理可以基于智能家庭传感器数据生成个性化规则。假设信息是收集自居民R1和居民R2。可以将情景设置为智能家庭用户活动和房间占用，并且可以将动作设置为灯具使用情况、开/关门以及使用厨房的特定橱柜。在一个示例中，厨房橱柜2条目可以指示烹饪，并且主要在居民R2睡觉时在工作日下午由居民R2使用。当居民R1不在家里\工作或睡觉时，厨房灯可能被使用了，这可以强烈表明居民R2似乎更多地使用厨房准备饭菜。由智能家居事件生成的示例规则选择器处理规则可能会为智能设备提供高级功能。例如，了解有关R2在厨房的时间的规则可能有助于设置智能设备(例如，智能冰箱)何时应告知家庭食谱建议和膳食计划想法。作为另一个示例，用户模式可以用于为加热和照明系统设置自动时间表。在一些实施例中，规则选择器处理既确定针对单个用户的个性化规则，又确定针对多个用户的个性化规则，例如家庭中的用户，用户群(例如，“20-25岁之间的所有男性”等)或用于整个用户群的通用规则。对于每个域(例如，智能家居、医疗、智能电视等)，规则选择器处理可以选择条件动作规则，只要将来自每个域的数据表示为(i)一系列动作(例如“感兴趣的跑步”、“观看动作片”等)，以及(ii)每当执行每个动作时(例如，“在卧室”、“天气晴朗”、“星期五晚上”等)。

由于用户对动作的规则选择参数有不同的偏好，因此实时智能手机系统必须学习用户对参数的偏好，而又不会给用户带来太多的规则建议。在一些实施例中，可以实现用于规则选择的参数学习，并使用诸如主动学习或强化学习之类的杠杆技术。用户不仅会通过删除不必要的条件来修改规则，而且还会向这些规则添加新的情景。可以由一些实施例实现的另一方面是捕获与共现相反的动作序列的顺序规则。例如，用户可以在将链接发布到聊天之前使用应用查找潜在的餐馆。检查应用和发布链接的顺序会一直持续到对餐厅达成共识为止。通过学习此例程，基于规则的聊天客户端可以为应用提供有用的直接连接，从而使整个用户交互更加方便。通常，顺序模式挖掘在计算上是较耗费资源的共现挖掘，并且还会输出大量自动化的候选规则；这些因素使顺序规则汇总颇具挑战性。一些实施例可以实现周期性模式的使用情况，例如用于在特定商店或网站上购物的月度模式。一旦用户接受了规则，规则选择器处理就可以呈现通知用户挖掘模式中的重大变化的UI，并提示用户是更新规则还是维护规则。在一个示例实施例中，每当用户选择的规则无效时，因为规则不再反映用户的行为，所以就会通知用户。在这种情况下，会基于当前用户行为向用户提供删除规则或修改规则的建议。例如，用户选择一条规则来提醒她在星期六晚上打电话给她的父母。用户行为可能会随着时间而改变，并且用户会忽略该提醒，并在周日晚上频繁致电其父母。在这样的示例中，规则选择器处理通知用户建议她将“呼叫父母”提醒从星期六晚上更改为星期日晚上。

图15示出了根据一些实施例的用于确定动作自动化的优选规则的过程1500的框图。在框1510中，过程1500使用电子设备(例如，图2的电子设备120、图22的系统2200)，基于域(例如，智能手机、智能TV、智能家电、数字健康监测、TV收视率等)信息来确定动作。在框1520中，过程1500获取多个活动模式，该多个活动模式指示了用户以高似然率执行动作(例如，重复动作或与情境和/或条件相关联的动作等)的情况。在框1530中，过程1500规定针对每个活动模式来确定候选动作规则。在一个实施例中，每个活动模式仅确定一个候选动作规则。在一些实施例中，每个候选动作规则指定了动作发生时的一个或更多个前提条件(例如，基于时间、星期几、天气、位置/场所等)。在框1540中，过程1500从多个候选条件动作规则中确定用于动作自动化的一个或更多个优选的候选条件动作规则(例如，将所有或大多数候选规则汇总为候选规则的子集)。在框1550中，过程1500在电子设备上(例如，在图2的电子设备120的显示器上，通过扬声器、耳机等)提供执行动作自动化的建议，并且在电子设备上(例如，在电子设备120的显示器上，通过扬声器、耳机等)提供执行动作的自动化的提醒。在一些实施例中，所述一个或更多个优选候选规则被应用以执行所述动作的自动化。

在一些实施例中，在过程1500中，一个或更多个优选的候选条件动作规则包括导致动作以超过第一似然(例如，发生的概率等)阈值的概率发生的前提条件。一个或更多个前提条件可以与第一持续时间相关联，该第一持续时间在第二持续时间内出现的频率大于第二阈值(例如，诸如一个小时、两个小时等选择的或预定的持续时间)，并且小于第三阈值(例如，诸如三个小时、四个小时等另一个选择的或预定的持续时间)。

在一些实施例中，在过程1500中，一个或更多个优选的候选条件动作规则涵盖动作在第二持续时间内大于第四阈值的发生次数(例如，选择的或预定的动作发生次数等)。在一些实施例中，一个或更多个优选的候选条件动作规则的总数小于第五阈值(例如6、5等)。在一些实施例中，一个或更多个优选的候选条件动作规则是汇总所有候选条件动作规则的候选条件动作规则的子集。

图16是示出信息处理系统的高级框图，该信息处理系统包括实现一个或更多个实施例的计算系统。系统1600包括一个或更多个处理器1611(例如，ASIC、CPU等)，并且可以进一步包括电子显示设备1612(用于显示图形、文本和其他数据)、主存储器1613(例如，随机访问存储器(RAM)、高速缓存设备等)、存储设备1614(例如硬盘驱动器)、可移动存储设备1615(例如可移动存储驱动器、可移动存储器、磁带驱动器、光盘驱动器、已在其中存储计算机软件和/或数据的计算机可读介质)、用户界面设备1616(例如，键盘、触摸屏、小键盘、定点设备)和通信接口1617(例如，调制解调器、无线收发器(例如Wi-Fi，蜂窝网络))、网络接口(例如以太网卡、通信端口或PCMCIA插槽和卡)。

通信接口1617允许软件和数据通过Internet 1650、移动电子设备1651、服务器1652、网络1653等在计算机系统与外部设备之间传输。系统1600还包括前述设备1611至1617连接到的通信基础结构1618(例如，通信总线、交叉开关或网络)。

经由通信接口1617传送的信息可以是信号的形式，例如电子、电磁、光学或能够由通信接口1617经由携带信号的通信链路接收的其他信号，并且可以使用电线或电缆、光纤、电话线、蜂窝电话链路、射频(RF)链路和/或其他通信通道来实现。

在移动无线设备(例如，移动电话、平板电脑、可穿戴设备等)中一个或更多个实施例的一种实现中，系统1600还包括例如相机128(图2)的图像捕获设备1620以及例如麦克风122(图2)的音频捕获设备1619。系统1600还可包括应用处理或处理器，例如MMS 1621、SMS1622、电子邮件1623、社交网络接口(SNI)1624、音频/视频(AV)播放器1625、Web浏览器1626、图像捕获1627等。

在一个实施例中，系统1600包括规则选择器处理1630，其可以实现与关于规则选择器处理应用129(图2)所描述的类似的处理，并且用于以上关于图5至图10所述的处理。在一个实施例中，规则选择器处理1630连同操作系统1629可以被实现为驻留在系统1600的存储器中的可执行代码。在另一个实施例中，规则选择器处理1630可以以被设置在硬件、固件等中。

在一个实施例中，主存储器1613、存储设备1614和可移动存储设备1615各自单独地或以任何组合的形式，可以存储可以由一个或更多个处理器1611执行的上述实施例的指令。

本领域技术人员将知晓，上面描述的前述示例架构根据所述架构可以以许多方式来实施，例如被实施为供处理器执行的程序指令，实施为软件模块、微代码，实施为计算机可读介质上的计算机程序产品，实施为模拟/逻辑电路，实施为专用集成电路，实施为固件，实施为消费类电子设备、AV设备、无线/有线发送器、无线/有线接收器、网络、多媒体设备等。另外，所述架构的实施例可以采取整体硬件的实施例、整体软件的实施例或包含硬件和软件元素两者的实施例。

已经参考根据一个或更多个实施例的方法的流程图示意和/或框图、装置(系统)和计算机程序产品描述了各实施例。可以由计算机程序指令实施这样的示意/图中的每一个框或其组合。计算机程序指令在被提供给处理器时产生机器，使得经由处理器执行的指令创建用于实施流程图和/或框图中指定的功能/操作的装置。流程图/框图中的每一个框可以代表硬件和/或软件模块或逻辑，从而实施一个或更多个实施例。在可选的实施方式中，框中指明的功能可以不按在图中指明的顺序、同时地发生等。

术语“计算机程序介质”、“计算机可用介质”、“计算机可读介质”和“计算机程序产品”一般用于指代比如主要存储器(main memory)、辅助存储器(secondary memory)、可移除存储驱动器、安装在硬盘驱动器中的硬盘之类的介质。这些计算机程序产品是用于将软件提供给计算机系统的手段。计算机可读介质允许计算机系统从计算机可读介质读取数据、指令、消息或消息分组和其他计算机可读信息。计算机可读介质例如可以包括非易失性存储器，例如软盘、ROM、闪存、盘驱动器存储器(disk drive memory)、CD-ROM和其他永久性存储装置。它对于例如在计算机系统之间传输比如数据和计算机指令之类的信息来说是有用的。计算机程序指令可以被存储在计算机可读介质中，计算机可读介质可以指示计算机、其他可编程数据处理装置或其他设备以特定方式发挥功能，以使得存储在计算机可读介质中的指令产生一种产品，其包括实施在流程图中和/或框图的一个或更多个框中指定的功能/动作的指令。

代表本文的框图和/或流程图的计算机程序指令可以被加载到计算机、可编程数据处理装置或处理设备上，以使得在其上执行的一系列操作产生计算机实施的过程。计算机程序(即，计算机控制逻辑)被存储在主要存储器和/或辅助存储器中。计算机程序也可以经由通信接口来接收。这样的计算机程序在被执行时使得计算机系统执行本文讨论的一个或更多个实施例的特征。具体地，计算机程序在被执行时使得处理器和/或多核处理器执行计算机系统的特征。这样的计算机程序代表计算机系统的控制器。计算机程序产品包括可以由计算机系统读取并存储用于由计算机系统执行以执行一个或更多个实施例的方法的指令的有形存储介质。

尽管已经参考实施例的某些版本描述了实施例，然而其他版本也是可能的。因此，所附权利要求的精神和范围不应当受限于本文包含的优选版本的描述。

Claims (15)

1.一种用于动作自动化的方法，所述方法包括：

使用电子设备基于域信息来确定动作；

获取与所述动作相关联的多个活动模式；

对于每个活动模式，确定候选动作规则，其中每个候选动作规则指定了所述动作发生时的一个或更多个前提条件；以及

从多个候选动作规则中确定用于所述动作自动化的一个或更多个优选的候选动作规则。

2.根据权利要求1所述的用于动作自动化的方法，其中所述一个或更多个优选的候选动作规则包括导致所述动作以超过第一似然阈值的概率发生的一个或更多个前提条件。

3.根据权利要求1所述的用于动作自动化的方法，其中所述一个或更多个前提条件与第一持续时间相关联，所述第一持续时间在第二持续时间中的出现频率大于第二阈值且小于第三阈值。

4.根据权利要求3所述的用于动作自动化的方法，其中所述一个或更多个优选的候选动作规则涵盖在所述第二持续时间内所述动作的发生次数，该次数大于第四阈值。

5.根据权利要求1所述的用于动作自动化的方法，其中所述一个或更多个优选的候选动作规则的总数小于第五阈值。

6.根据权利要求1所述的用于动作自动化的方法，其中所述一个或更多个优选的候选动作规则包括汇总了所有候选动作规则的候选动作规则子集。

7.根据权利要求1所述的用于动作自动化的方法，所述方法还包括：

基于所述一个或更多个优选的候选动作规则，在所述电子设备上提供用于自动化所述动作的建议。

8.根据权利要求1所述的用于动作自动化的方法，所述方法还包括：

基于所述一个或更多个优选的候选动作规则，在所述电子设备上提供执行所述动作的自动化的提醒。

9.一种电子设备，所述电子设备包括：

存储器，所述存储器存储指令；以及

至少一个处理器，所述至少一个处理器执行包括进程的所述指令，所述进程被配置为：

基于域信息来确定动作；

获取与所述动作相关联的多个活动模式；

对于每个活动模式，提取候选动作规则，其中每个候选动作规则指定了所述动作发生时的一个或更多个前提条件；

从多个候选动作规则中确定用于所述动作自动化的一个或更多个优选的候选动作规则。

10.根据权利要求9所述的电子设备，其中所述一个或更多个优选的候选动作规则包括导致所述动作以超过第一似然阈值的概率发生的前提条件。

11.根据权利要求9所述的电子设备，其中所述一个或更多个前提条件与第一持续时间相关联，所述第一持续时间在第二持续时间中的出现频率大于第二阈值且小于第三阈值。

12.根据权利要求11所述的电子设备，其中所述一个或更多个优选的候选动作规则涵盖在所述第二持续时间内所述动作的发生次数，该次数大于第四阈值。

13.根据权利要求9所述的电子设备，其中：

所述一个或更多个优选的候选动作规则的总数小于第五阈值；以及

所述一个或更多个优选的候选动作规则包括汇总了所有候选动作规则的候选动作规则子集。

14.根据权利要求9所述的电子设备，其中所述处理器还被配置为：

基于所述一个或更多个优选的候选动作规则，在所述电子设备上提供用于自动化所述动作的建议；以及

基于所述一个或更多个优选的候选动作规则，在所述电子设备上提供执行所述动作的自动化的提醒。

15.一种非暂时性处理器可读介质，所述非暂时性处理器可读介质包括程序，所述程序在被处理器执行时执行一种方法，所述方法包括：

使用电子设备基于域信息来确定动作；

获取与所述动作相关联的多个活动模式；

对于每个活动模式，提取候选动作规则，其中每个候选动作规则指定了所述动作发生时的一个或更多个前提条件；以及

从多个候选动作规则中确定用于所述动作自动化的一个或更多个优选的候选动作规则。

Images