CN112019683B - 来自应用程序的提醒 - Google Patents

Abstract

本公开的实施方案涉及基于来自应用程序的信息生成提醒，等等。例如，可接收第一消息并且可识别确认。可从所述第一消息和/或所述确认检测到识别要执行的动作和对应于所述动作的触发物的信息。在一些情况下，可至少部分地基于所述动作和所述触发物来生成提醒。然后可检测到对应于所述触发物的事件，并且可至少部分地基于检测到所述触发物来呈现所生成的提醒。

Description

来自应用程序的提醒

相关申请的交叉引用

本申请要求2019年4月30日提交的名称为“SIRI REMINDERS FOUND IN APPS.”的美国非临时申请16/426,565号的权益，其全部内容以引用方式并入本文。

背景技术

当今移动设备的用户依赖于那些设备来执行大量省时和组织任务。虽然从历史上看，移动电话的主要目的是给他人打电话，后来是发送电子消息，但如今的电话预计功能更多。当今的大多数移动设备可管理用户的日历，提供行车路线，甚至提醒用户执行用户原本可能已忘记的现实世界活动。例如，一些活动和/或事件可能不适用于用户的日历。另外，用户可能会忘记可帮助其记得执行各种任务的信息。因此，就提醒用户活动而言，移动电话仍然存在各种挑战。

发明内容

本公开的实施方案可提供用于至少部分地基于在设备应用程序中识别的信息来生成提醒的系统、方法和计算机可读介质。

在一些实施方案中，公开了一种计算机实现的方法。该方法可包括由计算设备从第二计算设备接收第一文本信息。该方法可包括由计算设备确定第一文本信息识别物理对象和要对物理对象执行的动作。该方法可包括由计算设备接收第二文本信息，第二文本信息是对第一文本信息的响应。该方法可包括由计算设备确定该响应是否识别对要对物理对象执行的动作的确认。该方法可包括由计算设备识别是第一文本信息还是第二文本信息识别包括时间或位置中的至少一者的触发物。该方法可包括：根据确定确认和触发物已被验证：由计算设备生成对应于要执行的动作的提醒对象；由所述计算设备呈现与所述提醒对象对应的提醒选择用户界面元素；并且根据确定提醒选择用户界面元素被选择，在检测到事件时由计算设备呈现表示提醒对象的提醒通知。

在一些实施方案中，该事件包括时间的发生、计算设备离开位置、计算设备确定用户将要离开位置、计算设备到达位置或计算设备确定用户将要到达位置中的至少一者。

在一些实施方案中，该方法可包括至少部分地基于物理对象、动作或触发物中的至少一者来生成用于提醒对象的标题，并且其中通知或提醒通知中的至少一者包括该标题。该方法可包括根据确定提醒选择用户界面未被选择：至少部分地基于所确定的时间、检测到计算设备离开位置、检测到计算设备到达该位置或检测到计算设备处于第二计算设备的阈值距离内来将提醒选择用户界面元素呈现在提醒用户界面中的至少一者中。在一些实施方案中，对确认和触发物的验证包括执行决策引擎以确定用于确认和触发物的准确度的置信度得分。

在一些实施方案中，至少部分地基于被配置为分析第一文本信息和第二文本信息的机器学习模型来确定确认、触发物、物理对象和动作。在一些实施方案中，第一文本信息与对应于第二设备的第一账户相关联。在一些实施方案中，第二文本信息经由计算设备的输入设备接收并且与对应于用户的第二账户相关联。

在一些实施方案中，公开了一种用户设备。该用户设备可包括被配置为存储计算机可执行指令的存储器和被配置为访问存储器并执行计算机可执行指令以执行操作的处理器。该操作可包括从第二设备接收第一消息，在用户设备处识别对第一消息的确认，从第一消息或第二消息中的至少一者检测识别要执行的动作和对应于动作的触发物的信息，至少部分地基于动作和触发物生成要呈现给用户设备的用户的提醒，检测对应于触发物的事件，以及至少部分地基于检测到触发物而在用户设备的显示器上呈现对应于动作的所生成的提醒。

在一些实施方案中，处理器被进一步配置为执行计算机可执行指令以在显示器的用户界面上至少呈现被配置为使得用户能够接受所生成的提醒的接受提示。在一些实施方案中，处理器被进一步配置为执行计算机可执行指令以经由接受提示至少接收对提醒的接受的选择，并且其中事件的检测和提醒的呈现至少部分地基于对接受提示的选择。在一些实施方案中，处理器被进一步配置为执行计算机可执行指令以至少部分地基于用户不接受该接受提示来在显示器的第二用户界面中至少呈现第二接受提示，并且其中第二界面包括多个其他提醒。在一些实施方案中，事件的检测和提醒的呈现至少部分地基于对第二接受提示的选择。在一些实施方案中，该多个其他提醒包括其他未接受的提醒。在一些实施方案中，第一消息识别要对其执行动作的对象，并且/或者触发物识别时间和日期、用户设备的到达位置或用户设备的离开位置。

在一些实施方案中，公开了一种计算机可读存储介质。该计算机可读存储介质可存储计算机可执行指令，该计算机可执行指令在由用户设备的一个或多个处理器执行时，将该一个或多个处理器配置为执行操作。该操作可包括由用户设备接收识别对象、要对对象执行的动作和与对象和动作对应的触发物的数字会话的文本。该操作还可包括至少部分地基于文本来确定数字会话的至少一部分包括确认。该操作还可包括至少部分地基于动作和触发物来生成要呈现给用户设备的用户的提醒。该操作还可包括检测与触发物对应的事件。在一些实施方案中，该操作还可包括至少部分地基于检测到触发物而在用户设备的显示器上呈现对应于动作的所生成的提醒。

在一些实施方案中，至少部分地基于在动词白名单上识别到动作来生成提醒。在一些实施方案中，经由用户设备的即时消息应用程序来接收数字会话。在一些实施方案中，通过使用机器学习模型处理数字会话的文本来确定确认。

附图说明

将参考附图来描述根据本公开的各种实施方案，其中：

图1示出了根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性环境；

图2示出了根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性流程；

图3示出了根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的另一示例性流程；

图4示出了根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的另一示例性流程；

图5示出了根据至少一个实施方案的被配置为至少部分地基于在设备应用程序中识别的信息来生成提醒的设备的示例性架构；

图6是示出根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性过程的流程图；

图7是示出根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性过程的另一流程图；以及

图8是示出根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性过程的另一流程图。

具体实施方式

在以下描述中，将描述各种实施方案。为了解释的目的，阐述了很多具体配置和细节以便提供对实施方案的彻底理解。然而，对本领域的技术人员也将显而易见的是，这些实施方案可在没有这些具体细节的情况下被实施。此外，可省略或简化熟知的特征以防止对本文所述的实施方案造成混淆。

本公开的实施方案涉及至少部分地基于在设备应用程序中识别的信息来生成提醒，等等。在一些示例中，提醒可提醒用户要对对象(例如，物理对象、虚拟对象等)执行的任务或动作。如本文所用，“任务”或“动作”可包括要由用户执行的任何合适的活动。另外，“提醒”可包括任何合适形式的任何合适的电子递送机构(例如，警报、警示、电子邮件、通知(例如，推送)、徽章等)。本文提供的示例和此类示例的上下文旨在用于说明性目的，而不是限制本公开的范围。

在一些实施方案中，第一用户可访问电子设备(例如，第一用户的设备，诸如智能电话、膝上型电脑等)的应用程序。该应用可以是即时消息应用程序(例如，用于发送/接收文本消息、即时消息等)或多个用户可与其通信的任何其他类型的应用程序(例如，管理用户之间的电话会话的应用程序)。使用该应用程序，第一用户可与一个或多个其他用户通信(例如，文本会话)。作为通信的一部分，其他用户中的一者可要求第一用户(例如，对对象)执行动作。如果第一用户确认其将经由应用程序执行动作，则可生成提醒和/或提醒建议(例如，提醒选择用户界面元素)。提醒建议可被接受，并且/或者提醒自身可由用户来配置。提醒建议也可被忽略或以其他方式被拒绝，在这种情况下，该建议可稍后呈现。在任何情况下，可通过呈现通知(例如，提醒用户界面元素)来提醒用户动作、对象和/或触发物。该提醒可由在会话中识别的触发物来提示。另外，可利用来自其他通信应用程序的信息来生成提醒和/或提醒建议。

例如，第一用户可利用作为在其电子设备(例如，智能电话)上操作的应用程序的一部分来提供的用户界面。在用户界面内，第一用户可与另一用户通信。作为会话的一部分，另一用户可向第一用户询问关于对对象执行动作的问题。例如，另一用户可要求第一用户“购买牛奶”，并且第一用户可响应“ok”，这表示其将执行该操作。根据本文所述的实施方案，可基于至少在确认之后的问题的组合来生成提醒(例如，提醒对象)。提醒自身可最终在适当的时间/位置触发通知。另外，可生成提醒建议(例如，以用户界面元素的形式)，并且提醒建议可被呈现给第一用户以供其接受或拒绝。在一些示例中，可在确认中检测到触发物(例如，如果提醒语句为“您可以购买一些牛奶吗？”，并且响应是“我会在晚上买一些”或“我会在下班之后买一些”)。

在一些示例中，可基于会话的各种参数来生成提醒和/或提醒建议。例如，可仅基于来自另一用户的初始问题，基于问题和确认，并且/或者基于触发物被识别来生成提醒和/或提醒建议。在一些情况下，触发物可包括日期和/或时间、到达位置或离开位置。可支持的位置包括“家”、“工作场所”、“学校”或其他感兴趣位置(LOI)。LOI可包括已被保存到用户帐户或用户定期访问的任何位置(例如，如果用户定期在特定杂货店购物，则该杂货店(和/或位置)可被保存为该用户的LOI)。所需的参数越多，提醒将适当准确的可能性就越大。因此，在一个具体实施中，可能需要以下参数以便生成提醒和/或建议：问题、确认和触发物。在该具体示例中，如果没有这三个参数，将无法生成提醒。应当理解，可由用户设备自身，与用户设备通信的服务器计算机，或这两者的任何合适组合提供先前功能或以下功能中的任一者。

一旦已生成并接受提醒，则可向用户呈现通知(例如，提醒用户界面元素)以提醒用户执行动作。可至少部分地基于检测到触发物来呈现提醒，其中在会话中检测到该触发物。例如，如果上述示例性会话识别时间或位置，则该时间的发生或到达/离开该位置将触发提醒。例如，如果其他用户询问第一用户“您可以在下班之后购买一些牛奶吗？”，则当第一用户离开其工作位置时，将触发通知(例如，提醒)。在这种情况下，第一用户离开工作场所的发生将是触发物。

下文将相对于至少图1至图8进一步讨论此类概念。

图1示出了根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性环境100。在一些示例中，一个或多个用户设备(例如，移动设备102和移动设备104)可由通过一个或多个网络110彼此通信的一个或多个相应用户(例如，用户106和用户108)控制。在一些示例中，网络110上的通信信号可由一个或多个服务提供方计算机112(例如，蜂窝服务或互联网服务提供方(ISP))来管理(例如，接收、处理和/或发送)。另外，尽管本文所公开的大多数实施方案和功能参考在一个或多个用户设备上执行处理来描述，但任何和/或所有处理可替代性地由一个或多个服务提供方计算机112执行。

在一些示例中，用户设备104可被配置为具有提醒/建议模块114。提醒/建议模块114可以是用户设备104的操作系统(OS)的一部分，或者可以是独立的应用程序。在任一种情况下，提醒/建议模块114均可被配置为实现用于至少部分地基于在设备应用程序中识别的信息来生成提醒的一个或多个软件模块。如将进一步详细描述的，提醒/建议模块114可实现机器学习模块116和/或决策引擎118。机器学习模块116可被配置为检测和/或推断来自用户106和用户108之间的会话内的某些属性，并且可能够作出关于潜在提醒的建议。机器学习模块116的输出可由决策引擎118处理，以便验证属性并作出关于是否生成提醒的确定。如果决策引擎118验证了属性并且确定应当生成提醒，则决策引擎118还可生成提醒和/或提醒建议。然而，在一些示例中，一旦决策引擎118生成提醒(例如，提醒对象)，则单独的建议模块可负责提醒建议。

在至少一个具体示例中，用户106可准备第一消息120并通过网络110将该第一消息发送至用户设备104。用户设备104的即时消息应用程序可在用户界面(UI)上的122处呈现第一消息120。响应于该消息，用户108可利用第二消息124进行响应。可通过网络110发送第二消息124以供用户设备102显示；然而，基本上同时，可在UI中的126处显示该第二消息。在该示例中，第一消息120是“嘿，Sam，您可以在下午6点取一下巨人游戏的门票吗？”。作为响应，第二消息124是“可以！”。如下文将更详细地讨论的，该对话包括a)问题(例如，“您可以取一下门票吗？”)、b)对象(例如，“门票”)、c)动作(例如，“取一下”)、d)触发物(例如，“在下午6点”)和e)确认(例如，“可以！”)。在一些示例中，为了生成提醒，可能需要这些元素中的每一者。至少部分地基于机器学习模型116和决策引擎118的输出，可生成提醒建议128并将该提醒建议呈现在UI上以供用户接受或拒绝。在这种情况下，提醒建议128陈述了提醒的标题“在下午6点取一下巨人游戏的门票”，以及“添加到提醒”的建议。根据用户是接受还是拒绝提醒建议128，提醒/建议模块114可存储提醒并在下午6点通知用户，或者存储提醒建议128以稍后向用户呈现(例如，当用户106和用户108再次通信时并且/或者当用户106和用户108在物理上彼此接近时)。

图2是根据至少一个实施方案的用于实现提醒生成技术的示例性流程200，其中用于对对象执行动作的触发物是日期/时间。应当理解，流程200可包括比图2中所示的操作更多或更少的操作，并且这些操作(例如，图2中所示的操作)可以任何合适的顺序执行。流程200的操作可由图1的用户设备104、或被配置为提供此类功能的服务器计算机(例如，图1的服务提供方计算机112)、或这两者的任何合适组合执行。

流程200可在202处开始，其中用户设备104可接收包括用于用户设备104的用户对对象执行动作的请求(例如，问题)的消息。在该示例中，请求是“嘿，Sam，您可以在下午6点取一下巨人游戏的门票吗？”。在该请求中，对象是“门票”，并且动作是“取”。另外，虽然并非所有请求均可包括触发物，但该请求包括触发物，该触发物指示将在“下午6点”采取该动作。因此，如果要向用户提供提醒，则提醒应当是在下午6点或至少在下午6点之前的某个时间(例如，5点等)提供。在204处，用户设备104可被配置为接收确认，在该示例中，用户已回答“可以！”。并非所有响应均将为确认，例如，如果用户回答“不行”或“我没法儿去”，或不能肯定地确认同意或接受请求的任何响应。此外，无论使用的确认语言为何种类型，所公开的技术均可能够确定确认。例如，“当然可以”、“没问题”、“行”、“好的”，或者甚至是表情符号，诸如示出大拇指向上手势(“拇指翘起”)的图像等。在一些示例中，图1的机器学习模型116和/或决策引擎118可能够确定响应是否为确认。

在206处，至少部分地基于接收到请求和确认，用户设备104可生成提醒，并且该提醒可至少部分地基于触发物和确认。例如，在一些情况下，触发物和确认可为生成提醒的最低要求。这样，系统可相当地确定提醒将是有帮助的并且不会造成困扰。另外，生成提醒需要最小参数集可减少所需的处理周期的数量并且/或者增加用户设备104的电池寿命；否则，可能会生成太多提醒(例如，冗余和/或不需要的提醒)。虽然图2中未示出，但在206处，用户设备104还可生成用于提醒的标题。在该示例中，由于检测到触发物是时间，该时间将在提醒的标题中列出。在208处，可在UI中呈现包括提醒标题的提醒建议210。提醒建议210的标题包括对象、动作和触发物。在一些情况下，触发物可为时间，并且系统可假设该时间是当天的时间。然而，如果请求单独包括日期或包括日期和时间，则系统将触发物设置为与请求中的日期对应的时间，或简单地设置为日期(例如，用户在那天醒来后早晨的第一件事，等等)。另外，在一些示例中，触发物可以不是请求的一部分，但相反是回复的一部分。例如，如果请求是“嘿，山姆，您可以取一下巨人游戏的门票吗？”，并且响应是“当然可以，我会在下午6点去取的。”，则将在206处生成相同的提醒。此外，在一些示例中，请求或响应可指示触发物是一天中的通用时间(例如，上午、下午、傍晚、晚上等)。在这种情况下，系统可推断用于提醒和/或提醒建议210的时间，并且用户可在接受提醒之后修改所建议的时间。

在212处，如果用户选择提醒建议210，则提醒建议UI元素可改变以呈现使用户能够接受或拒绝提醒建议210的选择/拒绝UI元素。在一些示例中，一旦接受提醒建议210，则用户还可能够配置提醒(例如，提醒对象)。这样，用户可指示应在触发物发生之前何时提供提醒通知(例如，是应当在触发物时间(此处为下午6点)还是应当在触发物时间之前的某个时间(例如，触发物时间前10分钟、30分钟、60分钟等)处提供通知)。在其他示例中，这可基于用户的位置和当前时间自动进行配置。例如，如果用户位于需要一小时才能到达对象的位置处(例如，在这种情况下为巨人游戏的售票处)，则通知可在触发物时间之前一小时自动呈现，从而给予用户足够的时间来及时到达该位置以执行动作。一旦被接受，提醒可被存储并且可经由提醒UI来访问，其中可呈现其他已接受的提醒。在提醒UI中，可取消或进一步配置已接受的提醒。一旦被接受和/或配置，提醒可至少部分地基于触发物的发生而被呈现给用户。

另选地，如果用户拒绝提醒建议210，提醒对象仍可被存储，但仅可在提醒建议UI中或提醒UI的未列出已接受提醒的另一部分中访问该提醒对象。另外，在一些示例中，如果提醒建议210被拒绝，则系统可被配置为再次提供提醒建议210，至少直到触发物发生或随后接受。这样，如果用户打算接受提醒，但忘记选择或在选择UI上选择了错误选项，则用户将具有另一次接受的机会。因此，用户可具有接受提醒(例如，待处理提醒建议)的各种机会，而不是仅经由图2的提醒建议210接受提醒。例如，如果用户正在与发送初始请求的用户通信(或在物理上接近)，则可再次(或仅在那时)呈现提醒建议210。又如，当用户正在访问能够出售巨人游戏门票的网站时，当用户接近体育场时，并且/或者当用户正在与其他人讨论巨人游戏时，可呈现提醒建议210。因此，各方(例如，其他用户)、对象、位置、时间等均可以是用于提示系统第一次或(如果第一次未接受提醒建议210，则)第二次提供提醒建议210的辅助触发物触发物。

图3是根据至少一个实施方案的用于实现提醒生成技术的与图2的流程200类似的示例性流程300。然而，在该示例中，消息是注释而不是请求，并且用于对对象执行动作的触发物是到达位置，而不是时间。类似于流程200，应当理解，流程300可包括比图3中所示的操作更多或更少的操作，并且这些操作(例如，图3中所示的操作)可以任何合适的顺序执行。流程300的操作可由图1的用户设备104、或被配置为提供此类功能的服务器计算机(例如，图1的服务提供方计算机112)、或这两者的任何合适组合执行。

流程300可在302处开始，其中用户设备104可接收包括用于和/或关于用户设备104的用户对对象执行动作的注释的消息。在该示例中，消息是“当您到家时，别忘记把垃圾带出来”。在该消息中，对象是“垃圾”，动作是“带出来”。另外，在这种情况下，触发物是位置“家”。由于触发物是位置，因此系统将需要确定该位置是到达位置还是离开位置。此处，由于注释注明“当您到......时”，因此该位置是到达位置。因此，如果要向用户提供提醒，则应当在用户设备104的位置与用户的家匹配时提供提醒通知。在304处，用户设备104可接收确认，在该示例中，用户已回答“好的”。如所指出的，并非所有响应均将为确认。

在306处，至少部分地基于接收到注释和确认，用户设备104可生成提醒，并且该提醒可至少部分地基于触发物和确认。类似于图1，在306处，用户设备104还可生成用于提醒的标题。在该示例中，由于检测到触发物是位置，该位置将在提醒标题中列出。在308处，可在UI中呈现包括提醒标题的提醒建议310。提醒建议310的标题包括对象、动作和触发物。

在312处，如果用户选择提醒建议310，则提醒建议UI元素可改变以呈现使用户能够接受或拒绝提醒建议310的选择/拒绝UI元素。在一些示例中，一旦接受提醒建议310，则用户还可能够配置提醒(例如，提醒对象)。这样，用户可指示应当在触发物之前何时提供提醒通知(例如，应当在触发物位置处(在这种情况下是“家”)还是在触发物发生之前的某个时间处(例如，基于用户位置和估计的行进时间，到家需要的时间或与家相距的距离)提供通知)。在其他示例中，这可基于用户的位置和当前时间自动进行配置。例如，如果用户位于需要一小时才能到达该位置(例如，在这种情况下是“家”)的位置处，则通知可在触发物发生前一小时自动呈现，从而在用户实际到达该位置之前给予用户一些提醒。一旦被接受，提醒可被存储并且可经由提醒UI来访问，其中可呈现其他已接受的提醒。在提醒UI中，可取消或进一步配置已接受的提醒。一旦被接受和/或配置，提醒可至少部分地基于触发物的发生而被呈现给用户。

另选地，如果用户拒绝提醒建议310，提醒对象仍可被存储，但仅可在提醒建议UI中或提醒UI的未列出已接受提醒的另一部分中访问该提醒对象。另外，在一些示例中，如果提醒建议310被拒绝，则系统可被配置为再次提供提醒建议310，至少直到触发物发生或随后接受。这样，如果用户打算接受提醒，但忘记选择或在选择UI上选择了错误选项，则用户将具有另一次接受的机会。因此，用户可具有接受提醒的各种机会，而不是仅经由图3的提醒建议310接受提醒。例如，如果用户正在与发送初始消息的用户通信(或在物理上接近)，则可再次(或仅在那时)呈现提醒建议310。

图4是根据至少一个实施方案的用于实现提醒生成技术的与图2的流程200和图3的流程300类似的示例性流程400。然而，在该示例中，用于对对象执行动作的触发物是离开位置。类似于流程200和流程300，应当理解，流程400可包括比图4中所示的操作更多或更少的操作，并且这些操作(例如，图4中所示的操作)可以任何合适的顺序执行。流程400的操作可由图1的用户设备104、或被配置为提供此类功能的服务器计算机(例如，图1的服务提供方计算机112)、或这两者的任何合适组合执行。

流程400可在402处开始，其中用户设备104可接收包括用于和/或关于用户设备104的用户对对象执行动作的注释的消息。在该示例中，消息为“在您离开办公室之后，去学校接一下女孩子们”。在该消息中，对象是“女孩”，动作是“接”。另外，在这种情况下，触发物是位置“办公室”。由于触发物是位置，因此系统将需要确定该位置是到达位置还是离开位置。此处，由于注释注明“在您离开......之后”，因此该位置是离开位置。因此，如果要向用户提供提醒，则应当在用户设备104的位置不再与用户的办公室/工作位置匹配时或者当用户设备104确定用户的位置不再与用户的办公室/工作位置匹配时(例如，用户设备104可能够检测到用户在其办公室，但不再基于用户设备104的地理定位能力，或者通过与用户穿戴的另一可穿戴设备通信)提供提醒通知。在404处，用户设备104可接收确认，在该示例中，用户已回答“可以”。如所指出的，并非所有响应均将为确认；然而，该系统可检测每个可能的确认响应。

在406处，至少部分地基于接收到注释和确认，用户设备104可生成提醒，并且该提醒可至少部分地基于触发物和确认。类似于图1和图2，在406处，用户设备104还可生成用于提醒的标题。在该示例中，由于检测到触发物是位置，该位置将在提醒标题中列出。在408处，可在UI中呈现包括提醒标题的提醒建议410。提醒建议410的标题包括对象、动作和触发物。

在412处，如果用户选择提醒建议410，则提醒建议UI元素可改变以呈现使用户能够接受或拒绝提醒建议410的选择/拒绝UI元素。在一些示例中，一旦接受提醒建议410，则用户还可能够配置提醒(例如，提醒对象)。这样，用户可指示应当在触发物发生之前何时提供提醒通知(例如，应当在确定用户处于触发物位置(在这种情况下是“工作场所”)处时，还是在触发物发生之后的某个时间(例如，基于用户位置和估计的行进时间，到办公室需要的时间或与办公室相距的距离)处提供通知)。一旦被接受，提醒可被存储并且可经由提醒UI来访问，其中可呈现其他已接受的提醒。在提醒UI中，可取消或进一步配置已接受的提醒。一旦被接受和/或配置，提醒可至少部分地基于触发物的发生而被呈现给用户。

图5示出了根据至少一个实施方案的用于至少部分地基于在设备应用程序中识别的信息来生成提醒的示例性架构500。在一些示例中，用户设备504的主进程(例如，OS 502)可被配置为实现一个或多个软件模块，例如，消息模块506、建议模块508和提醒模块510。在至少一个情况下，消息模块506被配置为接收和/或处理消息(例如，文本消息、电子邮件消息、即时消息等)，并且将该消息渲染/呈现在用户设备504的屏幕上。另外，消息模块506可将消息提供给建议模块508，如箭头510所示。在一些示例中，将消息模块506接收的每个消息发送至建议模块508。建议模块508可处理传入消息的有效载荷以确定是否应当建议提醒。因此，在一些情况下，建议模块508可实现机器学习模型510(例如，图1的机器学习模型116)和决策引擎512(例如，图1的决策引擎118)。

在一些示例中，提醒模块514负责管理所生成的提醒、所建议的提醒和所接受的提醒。因此，提醒模块514可仅存储提醒实例并呈现在提醒UI中。相反，建议模块508可负责生成提醒建议和提醒对象，并且还可负责生成用于呈现提醒建议和提醒警示(例如，通知)两者的UI元素。建议模块508可将一个或多个应用程序接口(API)调用到提醒模块514，以便在需要时准备好一个或多个UI元素。

当消息模块506接收到一个或多个消息时，消息模块506可对包括消息有效载荷的建议模块508进行API调用。如果建议模块508找到提醒，则可通过将提醒对象包括在“存在于应用程序”516列表中来将提醒对象写入到提醒模块514(例如，可以将生成的提醒标记有“存在于应用程序中”)。对于每个会话线程(例如，在用户设备504的用户与任何其他一个或多个个人用户(或用户组)之间)，可存在单个消息缓冲区。因此，对于单个会话，将存在单个消息缓冲区。

建议模块508被进一步配置为跟踪从消息模块506接收的消息的缓冲区。在一些情况下，消息缓冲区可包括图1的第一消息120和第二消息124。当识别要生成的提醒时，建议模块508可生成建议UI元素，或者可从提醒模块514请求建议UI元素。在任一种情况下，随后可将该建议UI元素发送回消息模块506以呈现在用户正使用的即时消息应用程序中。被发送回消息应用程序的建议UI由箭头514示出。另外，在一些情况下，消息模块506可向建议模块508询问建议模块508是否具有由箭头516所示的任何建议。

如所指出的，建议模块508被配置为具有机器学习模型510和决策引擎512。模型510可为双向机器学习模型(例如，双向长短期记忆(LSTM)网络模型)。在一些示例中，可训练模型以检测动作动词或对象核心的文本的范围。动作动词识别要执行的动作(例如，在消息中请求的动作)，并且对象核心识别要对其执行动作的事物。当模型处理消息文本时，该模型为范围添加注释，以识别消息的哪些字词对应于动作动词或对象核心。该模型还可检测触发物(例如，时间、离开位置或到达位置)。然后可将该信息映射到至少四个不同类别，这些类别包括但不限于：家、工作场所、学校等。模型然后可将这些触发物位置标记为这些类别中的一者，使得该信息可用于确定提醒和/或提醒的标题。可在用户的账户中查找工作场所、学校、家和LOI位置以确定对应于该类别的实际物理位置(例如，地址或GPS坐标)。另外，模型可检测消息文本中的实际地址，并将该地址用作触发物位置。

在一些情况下，模型还可为文本添加注释以识别该文本是提醒语句还是提醒问题。例如，模型可确定该语句是否仅仅是会话的一部分，或者是否是执行动作的实际请求(例如，“您可以取一下牛奶吗？”)或执行动作的建议(例如，“请取一下牛奶！”或“不要忘记取牛奶！”)。为了消除语句如“我将要去取牛奶”或“我已经取了牛奶”的歧义，这一点很重要，使得不会为将来不需要执行的动作生成提醒。该模型还被配置为识别对提醒语句的确认。在一些示例中，可利用多个示例来训练模型，然后将消息文本馈送到模型中。该模型还可通过以识别提醒语句的方式将消息文本的带注释部分拼接在一起来生成标题。

在一些情况下，模型可推断的类包括但不限于：动作动词(例如，基于动作相关的动词的白名单)、对象核心(例如，由模型预测的名词)、位置触发物(例如，识别“离开”或“进入”位置的字词)、位置(例如，家、工作场所、学校等)、到期时间(例如，数据检测器检测到的任何将来时间)和极性(例如，提醒语句，然后对其接受、拒绝或无响应(这可视为拒绝))。在一些情况下，可利用动词白名单来训练模型，以使模型能够检测哪些字词指示应当与提醒相关联的动作。当检测到到期时间时，模型可将该到期时间与会话中存在的多个时间区分开。一般来讲，将第二时间选择为到期时间。例如，在“我下午4点下班，您可以下午6点去接一下孩子吗？”的消息中，模型将确定用于提醒的到期时间是下午6点。这些确定识别消息文本的推断范围。

在一些示例中，可利用决策引擎512来分析模型510的输出(例如，推断的范围)并构造提醒对象。由决策引擎512作出的决策的示例包括但不限于：确保日期在将来，确保存在不多于一个的对象核心和动作动词(例如，这是对对象核心和动作动词的验证)，验证LOI，以及验证存在提醒语句和确认(例如，极性)。另外，决策引擎512可被配置为将推断的范围拼接在一起以形成用于提醒对象的标题，验证标题，验证动词在白名单上以及检测到的名词实际上是名词。在一个示例中，如果语句是“我今晚正在做意大利面，您能带一些调味汁吗？”，则决策引擎512可被配置成确定对象核心是“调味汁”而不是“意大利面”。在一些情况下，如果决策引擎512无法确定两个名词中的哪一个是对象，则决策引擎512可决定根本不生成提醒。另外，如果对象核心和动词看起来是乱序的(例如，“我们的牛奶快用完了，您能为我们争取一些时间吗？”，则即使对象在动词之前，决策引擎512也可确定对象是牛奶，然后翻转标题中的术语。在一些示例中，当缺少特定文本范围(例如，名词、动词等)时，决策引擎512可根本不推荐提醒。又如，如果模型检测到多个目标日期，则模型可仅选择一个目标日期(例如，根据需要，选择句子中的第二目标日期或最靠近对象的目标日期)。然而，在其他示例中，可确定准确度阈值，并且将生成具有高于阈值的范围的潜在提醒，同时将忽略低于阈值的潜在提醒。例如，如果检测到两个动作动词，则将不会达到准确度阈值，并且将不会生成/建议提醒。另外，在一些示例中，模型510可输出具有相应置信度得分的推断范围，并且引擎可仅分析高于阈值置信度得分的范围。

在一些示例中，一旦决策引擎确定生成提醒，则提醒建议UI元素可被呈现在用户正在与之交互的应用程序(例如，正用于会话的即时消息应用程序)内。该提醒建议UI元素可在用户通过确认来回复提醒语句之后立即被呈现。如果用户接受该建议，则提醒对象可被转发至提醒模块514，并且提醒UI元素将被列出在提醒应用程序的列出所有已接受提醒的部分中。然而，即使用户不经由提醒建议UI元素接受提醒(例如，用户拒绝该提醒或用户只是未接受该提醒)，仍可将提醒对象发送至提醒模块514。在这种情况下，可在提醒应用程序的单独部分(例如，提醒建议UI部分)中显示提醒建议，而不是在已接受提醒部分中显示提醒UI。然而，在一些示例中，一旦触发物到期(例如，触发物时间过去，已离开离开位置，或已到达到达位置)，则将不再在提醒建议UI部分中显示提醒建议，并且可删除提醒对象。此外，当用户尝试在提醒应用程序中添加新提醒时(例如，经由新的提醒添加UI部分)，可向用户显示未到期的提醒建议。在一些示例中，如果模型检测到两个问题仅具有一个确认，则决策引擎仍可生成提醒，并且在提醒配置期间要求用户选择要被执行动作的对象中的一者。类似地，如果提醒语句或确认中不包括触发物，则决策引擎512仍可生成提醒，并且在配置阶段期间提醒到期时询问用户。

在建议模块508的一个具体实施中，实现流水线，其中信息(例如，消息和其他消息信息)被处理。建议模块508可包括一个或多个数据解析器，其中可解析消息以得到联系人信息(例如，识别消息的用户的信息)、事件信息、位置信息、触发物信息等。在一些情况下，建议模块508还可包括可保持机器学习模型和决策引擎的提醒解析器。提醒解析器可位于流水线中其他数据解析器的下游。这样，从先前解析器处的消息中提取的信息可被提醒解析器重复使用。因此，不需要再次检测由一个或多个数据检测器检测到的信息。在一些示例中，数据检测器是能够检测消息中的字词何时包括可由一个或多个其他模块使用的数据的软件模型或算法。例如，包括日期、联系人姓名、位置等的文本均是包括有价值信息的字词。因此，数据检测器将能够识别该字词，将那些字词标记为包括信息，提取该信息，并且使该信息可用于其他模块(例如，建议模块508和/或提醒解析器)。因此，当由流水线的一个或多个数据解析器分析消息时，为了从消息的字词提取信息，提醒解析器然后可返回到该数据，而不必重新分析该字词并重新提取信息，从而缩短了用户设备504的宝贵处理周期并且甚至延长了该用户设备的电池寿命。

另外，在一些示例中，单独的应用程序或模块可被配置为检测消息中的日期和/或时间(例如，使用数据检测器)，并且由该日期和/或时间生成一个或多个事件。可生成这些事件以放置、存储、管理和/或呈现在日历应用程序中。在一些情况下，提醒解析器还可被配置为分析围绕日期的文本以生成用于事件的标题。可使用位于建议模块508中的提醒解析器的机器学习模型来生成标题。在该示例中，如果机器学习模型510不确定标题是否准确，则将不向事件/日历应用程序发送标题。然而，在该示例中，机器学习模型510可仅验证标题是否有意义，而不是验证由模型检查的用于生成提醒的其他元素(例如，确认和触发物)。

图6至图8是示出根据至少一个实施方案的用于实现用于从应用程序生成提醒的技术的各方面的示例性过程600至800的流程图。过程600至800可由图5的建议模块512或图1的提醒/建议模块114的一个或多个部件执行。过程600至800可以任何合适的顺序执行。应当理解，过程600至800可包括比图6至图8中所示的操作更多或更少的操作，并且这些操作可以任何合适的顺序执行。

过程600可在602处开始，其中方法(例如，由类似于图5的建议模块508的建议模块实现)可被配置为接收消息反馈(例如，来自类似于图5的消息模块506的即时消息应用程序)。作为附加示例，会话可以是使用蜂窝电话的语音/音频会话，并且即时消息应用程序可以是用于在设备之间传输和接收音频信号的软件。在该示例中，音频可被转录成文本，并且转录的文本可以是“接收”的会话。

在604处，建议模块508可通过检查一些要求来验证消息。例如，建议模块508可确定消息是否为群会话的一部分，消息是否为支持的语言(例如，英语或应用程序被配置为进行处理的另一语言)，以及消息是否具有适当的长度。如果这些要求中的任何一者未得到满足，则建议模块508可决定不处理该消息。另外，在一些示例中，消息可被处理为仅包括先前消息或两个消息(例如，来自两个用户中的每一者的一个消息)的小文本缓存。该文本缓存的验证可包括使用以下规则进行验证：先前的消息必须来自另一用户(例如，不是处理该消息的用户设备的帐户持有人(例如，用户设备502的用户))，当前消息必须来自帐户持有人(例如，用户设备502的用户)，先前消息必须包括与白名单动词匹配的动词，先前消息必须包括提醒语句(该步骤可由类似于图5的模型510的机器学习模型执行)，以及当前消息必须包括接受(例如，对提醒语句的确认)(该步骤也可由图5的模型510执行)。

在606处，模型510可被配置为在内容的表示上运行。在一些情况下，可对经验证的文本执行以下操作：对消息文本的内容进行屈折分类(例如，通过将相同字词的屈折形式或变体形式分组在一起来对字词进行分类)、在内容上运行词性标注器(例如，阅读文本并将词性分配给每个字词，例如，名词、动词、形容词等)，将动作动词注入到内容的表示中，以及将映射注入到表情符号或可将文本表示到内容表示中的其他图像中。一旦已生成表示，则模型510可在表示上运行，并且模型510的输出可被映射到输出表示。

在608处，可实现决策引擎(例如，图5的决策引擎512)以验证模型输出。在一些示例中，决策引擎512可被配置为在模型输出处查看两个消息，并将结果拼接在一起。决策引擎512还可通过查找动作动词和对象核心并将其组合来生成标题。另外，决策引擎512确保标题包含名词，解析到期日期(例如，是否不止一个到期日期已经过去)，解析到期位置，检查是否已经存在与正在考虑的提醒匹配的当前提醒(例如，为了避免重复，如果已存在一个提醒，则将不会为正在处理的消息生成提醒)。

在610处，过程600可在决策引擎生成提醒并将其添加到列表(例如，在图5的“存在于应用程序中”514)时结束，该列表可由被配置为管理和/或呈现用于提醒的UI元素的提醒应用程序(例如，图5的提醒模块512)消化。

图7是示出根据至少一个实施方案的用于实现用于从应用程序生成提醒的技术的各方面的另一示例性过程700的流程图。

过程700可在702处开始，在此处可接收第一文本信息。可从不同用户设备生成和接收第一文本信息，该不同的用户设备由与操作执行过程700的用户设备的用户不同的用户进行操作。

在704处，过程700可确定第一文本信息识别对象(例如，物理对象)和要对对象执行的动作。

在706处，过程700可接收第二文本信息(例如，对第一消息的响应)。可基于操作实现过程700的设备的用户的输入来接收或以其他方式识别第二文本信息。

在708处，过程700可确定第二文本信息是否为对在702处接收的第一文本信息的确认。

在710处，过程700可识别包括时间或位置的目标。触发物可识别提醒何时到期(例如，何时执行动作)和/或提醒应当何时到期。在一些示例中，触发物的存在是生成提醒的要求。

在712处，过程700可确定确认和触发物是否被验证。例如，决策引擎(例如，如本文所述)可分析机器学习模型的输出以验证是否应当生成提醒。如果在712处，确认和触发物未被验证，则过程700可返回至702以接收下一个文本信息。然而，如果确认和触发物被验证，则过程700可继续以在714处生成提醒。生成提醒可包括生成存储提醒的所有相关细节的提醒对象，这些相关细节包括文本范围、标签，以及与每个文本范围相关联的数据(例如，触发物位置信息等)。

在716处，可呈现提醒选择UI元素。提醒选择UI元素在本文中也被称为提醒建议。提醒选择UI元素可使得用户能够接受或拒绝提醒建议。

在718处，过程700可确定提醒选择UI元素是否被选择(例如，提醒建议是否被接受)。如果不是，则提醒建议可稍后在720处呈现，至少直到该提醒建议到期。然而，如果在718处提醒选择UI元素被接受，则在722处，过程700可至少部分地基于触发物的发生来呈现提醒(例如，通过提供尝试提醒用户对对象执行动作的警示或通知)。

图8是示出根据至少一个实施方案的用于实现用于从应用程序生成提醒的技术的各方面的另一示例性过程800的流程图。

过程800可在802处开始，在此处接收第一消息。

在804处，(例如，从第二消息)识别对第一消息的确认。

在806处，从包括第一消息和确认的会话内检测动作和触发物。

在808处，可至少部分地基于对象、动作和触发物来生成提醒。

在810处，检测对应于触发物的事件。例如，如果触发物是下午6点，并且将至少部分地基于该触发物的发生来呈现提醒，则下午6点为事件。

在812处，过程800可在至少部分地基于检测到对应于触发物的事件来呈现提醒时结束。

如上所述，本技术的一个方面在于收集和使用得自各种来源的数据，以从应用程序生成提醒。本公开预期，在一些情况下，这些所采集的数据可包括唯一地识别或可用于联系或定位特定人员的个人信息数据。此类个人信息数据可包括人口数据、基于位置的数据、电话号码、电子邮件地址、推特ID、家庭地址、出生日期或任何其他识别或个人信息。

本公开认识到在本发明技术中使用此类个人信息数据可用于使用户受益。例如，个人信息数据可用于递送更好的提醒。因此，使用此类个人信息数据使得用户能够在可有利于完成任务的时间并且以可有利于完成任务的方式接收提醒和/或通知。因此，本文所讨论的个人信息数据可有助于用户确保提醒被生成并且/或提示用户根据该特定用户的日程安排和日常活动来完成任务。

本公开设想负责采集、分析、公开、传输、存储或其他使用此类个人信息数据的实体将遵守既定的隐私政策和/或隐私实践。具体地，此类实体应当实行并坚持使用被公认为满足或超出对维护个人信息数据的隐私性和安全性的行业或政府要求的隐私政策和实践。此类政策应该能被用户方便地访问，并应随着数据的采集和/或使用变化而被更新。来自用户的个人信息应当被收集用于实体的合法且合理的用途，并且不在这些合法使用之外共享或出售。此外，应在收到用户知情同意后进行此类采集/共享。此外，此类实体应考虑采取任何必要步骤，保卫和保障对此类个人信息数据的访问，并确保有权访问个人信息数据的其他人遵守其隐私政策和流程。另外，这种实体可使其本身经受第三方评估以证明其遵守广泛接受的隐私政策和实践。此外，应当调整政策和实践，以便采集和/或访问的特定类型的个人信息数据，并适用于包括管辖范围的具体考虑的适用法律和标准。因此，在每个国家应为不同的个人数据类型保持不同的隐私实践。

不管前述情况如何，本公开还预期用户选择性地阻止使用或访问个人信息数据的实施方案。即本公开预期可提供硬件元件和/或软件元件，以防止或阻止对此类个人信息数据的访问。例如，就从应用程序生成提醒而言，本发明技术可被配置为在注册服务期间或之后任何时候允许用户选择“选择加入”或“选择退出”参与对个人信息数据(或其个人信息数据的一部分)的收集。又如，用户可选择不提供个人信息数据以用于生成提醒和/或通知的目的。又如，用户可选择限制保持个人信息数据的时间长度或完全禁止使用包括或利用个人信息的提醒和/或通知。除了提供“选择加入”和“选择退出”选项外，本公开设想提供与访问或使用个人信息相关的通知。例如，可在下载应用程序时向用户通知其个人信息数据将被访问，然后就在个人信息数据被应用程序访问之前再次提醒用户。

此外，本公开的目的是应管理和处理个人信息数据以最小化无意或未经授权访问或使用的风险。一旦不再需要数据，通过限制数据收集和删除数据可最小化风险。此外，并且当适用时，数据去标识能够被用于保护用户的隐私。可在适当时通过移除特定标识符(例如，出生日期等)、控制所存储数据的量或特异性(例如，在城市级别而不是在地址级别收集位置数据)、控制数据如何被存储(例如，在用户之间聚合数据)、和/或其他方法来促进去标识。

因此，虽然本公开广泛地覆盖了使用个人信息数据来实现一个或多个各种所公开的实施方案，但本公开还预期各种实施方案也可在无需访问此类个人信息数据的情况下被实现。即，本发明技术的各种实施方案不会由于缺少此类个人信息数据的全部或一部分而无法正常进行。例如，可通过基于非个人信息数据或绝对最低数量的个人信息(诸如与用户相关联的设备正请求的内容、对主动提醒引擎可用的其他非个人信息或公开可用的信息)推断偏好来生成并递送提醒。

说明书和附图应被视为具有例示性的而非限制性的意义。然而，显而易见的是，在不脱离权利要求中阐述的本公开的更广泛的实质和范围的情况下，可对其进行各种修改和改变。

其他变型形式在本公开的实质内。因此，尽管所公开的技术容易受到各种修改和另选构造的影响，但是其某些例示的实施方案在附图中示出并且已经在上面详细描述。然而，应当理解，并不旨在将本发明限制于所公开的一个或多个特定形式，相反，其目的在于覆盖落入由所附权利要求所限定的本发明的实质和范围内的所有修改、另选构造和等同形式。

在描述所公开的实施方案的上下文中(特别是在下面的权利要求书的上下文中)使用术语“一”和“一个”和“该”以及类似的指示词将被解释为覆盖单数和复数，除非另有说明或与上下文明显矛盾。除非另有说明，否则术语“包含”、“具有”、“包括”和“含有”应被解释为开放式术语(即，意思为“包括但不限于”)。术语“连接”被解释为即使有干预的东西，也被部分或全部地包含在内、附接或接合在一起。除非本文另有说明，否则本文中对数值范围的叙述仅仅旨在用作单独提及落入该范围内的每个单独值的简单方法，并且每个单独的值被并入说明书中，如同在本文中单独引用。本文所述的所有方法可以任何合适的顺序执行。除非另有声明，否则本文提供的任何和所有示例或示例性语言(例如，“诸如”)的使用仅仅旨在更好地说明本发明的实施方案，并且不会限制本发明的范围。说明书中的任何语言均不应被解释为指示任何未声明的元素对于本发明的实践是必不可少的。

除非另外特别说明，否则析取语言诸如短语“X、Y或Z中的至少一者”在上下文中旨在被理解为通常用于呈现项目、术语等，其可以是X、Y或Z，或它们的任何组合(例如，X、Y和/或Z)。因此，此类析取语言通常不旨在并且不应该暗示某些实施方案要求X中的至少一个、Y中的至少一个或者Z中的至少一个均各自存在。

本文描述了本公开的优选实施方案，该优选实施方案包括发明人已知的用于执行本发明的最佳模式。在阅读前面的描述之后，那些优选实施方案的变型形式对于本领域的普通技术人员来说可变得显而易见。发明人期望技术人员适当地采用此类变型形式，并且发明人旨在以不同于本文具体描述的方式来实践本技术。因此，如适用法律所允许的，这些技术包括所附权利要求中所述的主题的所有修改和等同形式。此外，除非在本文中另外指出或者明显与上下文矛盾，否则所公开的技术包含上述元素的所有可能变型形式的任何组合。

本文引用的所有参考文献，包括出版物、专利申请和专利，均据此以引用方式并入本文，正如每篇参考文献被单独且具体地指示为以引用方式并入并且在本文全文阐述。

Claims (20)

1.一种方法，包括：

由计算设备从第二计算设备接收第一文本信息；

由所述计算设备确定所述第一文本信息识别物理对象和要执行的动作；

由所述计算设备接收第二文本信息，所述第二文本信息是对所述第一文本信息的响应；

由所述计算设备确定所述响应是否识别对要执行的所述动作的确认；

由所述计算设备识别是所述第一文本信息还是所述第二文本信息识别包括位置的触发物，所述动作要在所述位置处被执行；以及

响应于确定所述响应识别出对要执行的所述动作的所述确认：

由所述计算设备在所述计算设备的提醒应用程序中存储对应于要执行的动作的提醒对象；

至少部分地基于所述动作要被执行的所述位置来确定触发提醒通知的呈现的事件，所述事件至少部分地基于用于从所述计算设备的位置行进到所述动作要被执行的所述位置的行进时间而被确定；以及

在检测到所述事件时由所述计算设备呈现表示所述提醒对象的所述提醒通知。

2.根据权利要求1所述的方法，其中所述事件包括行进到所述动作要被执行的所述位置的离开时间的发生，所述离开时间基于所述行进时间。

3.根据权利要求1或2所述的方法，还包括至少部分地基于所述动作或所述触发物中的至少一者来生成用于所述提醒对象的标题，并且其中所述提醒通知包括所述标题。

4.根据权利要求1或2所述的方法，还包括：至少部分地基于确定的时间、检测到所述计算设备离开位置、检测到所述计算设备或用户到达所述位置或检测到所述计算设备或用户正在所述第二计算设备或第二用户的阈值距离内，将所述提醒对象呈现在提醒用户界面中的至少一者中。

5.根据权利要求1或2所述的方法，还包括验证所述确认和所述触发物，其中验证所述确认和所述触发物包括执行决策引擎以确定用于所述确认和所述触发物的准确度的置信度得分。

6.根据权利要求1或2所述的方法，其中至少部分地基于被配置为分析所述第一文本信息和所述第二文本信息的受监督机器学习模型来确定所述确认、所述触发物和所述动作。

7.根据权利要求1或2所述的方法，其中所述第一文本信息与对应于所述第二计算设备的第一账户相关联。

8.根据权利要求1或2所述的方法，其中所述第二文本信息经由所述计算设备的输入设备接收并且与对应于所述计算设备的用户的第二账户相关联。

9.一种用户设备，包括：

存储器，所述存储器被配置为存储计算机可执行指令；和

处理器，所述处理器被配置为访问所述存储器并执行所述计算机可执行指令以至少执行以下操作：

从第二设备接收第一消息，所述第一消息识别要执行的动作；

在所述用户设备处识别对所述第一消息的确认；

从所述第一消息或所述确认中的至少一者检测识别所述动作的信息和对应于所述动作的触发物，其中所述触发物包括所述动作要被执行的位置；

响应于识别出所述确认和要被执行的所述动作：

在所述用户设备的提醒应用程序中存储提醒，所述提醒至少部分地基于所述动作和所述触发物而被生成；

检测对应于所述触发物的事件，所述事件至少部分地基于用于从计算设备的位置行进到所述动作要被执行的所述位置的行进时间；以及

至少部分地基于检测到所述事件，在所述用户设备的显示器上呈现对应于所述动作的所述提醒的通知。

10.根据权利要求9所述的用户设备，其中所述处理器被进一步配置为执行所述计算机可执行指令以在所述显示器的用户界面上至少呈现被配置为使得所述用户能够接受所生成的提醒的接受提示。

11.根据权利要求10所述的用户设备，其中所述处理器被进一步配置为执行所述计算机可执行指令以至少在所述显示器的用户界面中至少呈现接受提示，并且其中所述用户界面包括所述提醒应用程序的多个其他提醒。

12.根据权利要求11所述的用户设备，其中所述事件的所述检测和所述通知的所述呈现至少部分地基于所述提醒应用程序中的所述提醒的所述存储。

13.根据权利要求11所述的用户设备，其中所述多个其他提醒包括其他未接受的提醒。

14.根据权利要求9-13中任一项所述的用户设备，其中所述动作将在由所述第一消息识别的物理对象上执行。

15.根据权利要求9-13中任一项所述的用户设备，其中所述触发物识别时间和日期、所述用户设备的到达位置或所述用户设备的离开位置。

16.一种存储计算机可执行指令的计算机可读介质，所述计算机可执行指令在由用户设备的一个或多个处理器执行时，使得所述一个或多个处理器执行包括以下各项的操作：

由所述用户设备接收识别要执行的动作和对应于所述动作的触发物的数字会话的文本，其中所述触发物包括所述动作要被执行的位置；

至少部分地基于所述文本来确定所述数字会话的至少一部分包括确认；

响应于确定所述数字会话的所述至少一部分包括所述确认：

在所述用户设备的提醒应用程序中存储提醒，所述提醒至少部分地基于所述动作而被生成；

检测对应于所述触发物的事件，所述事件至少部分地基于用于从所述用户设备的位置行进到所述动作要被执行的所述位置的行进时间；以及

至少部分地基于检测到所述事件，在所述用户设备的显示器上呈现对应于所述动作的所述提醒的通知。

17.根据权利要求16所述的计算机可读介质，其中至少部分地还基于在动词白名单上识别所述动作来生成所述提醒。

18.根据权利要求16或17所述的计算机可读介质，其中经由所述用户设备的即时消息应用程序来接收所述数字会话。

19.根据权利要求16或17所述的计算机可读介质，其中通过使用机器学习模型处理所述数字会话的所述文本来确定所述确认。

20.一种装置，包括：

用于从第二计算设备接收第一文本信息的部件；

用于确定所述第一文本信息识别物理对象和要执行的动作的部件；

用于接收第二文本信息的部件，所述第二文本信息是对所述第一文本信息的响应；

用于确定所述响应是否识别对要执行的所述动作的确认的部件；

用于识别是所述第一文本信息还是所述第二文本信息识别包括位置的触发物的部件，所述动作要在所述位置处被执行；以及

用于响应于确定所述响应识别出对要执行的所述动作的所述确认，进行以下操作的部件：

在所述计算设备的提醒应用程序中存储对应于要执行的动作的提醒对象；

至少部分地基于所述动作要被执行的所述位置来确定触发提醒通知的呈现的事件，所述事件至少部分地基于用于从所述计算设备的位置行进到所述动作要被执行的所述位置的行进时间而被确定；以及

在检测到所述事件时呈现表示所述提醒对象的所述提醒通知。

Images