CN117099077A - 具有用户视图上下文和多模态输入支持的支持语音助手的客户端应用 - Google Patents

Abstract

在本文中所讨论的各种实施例使得客户端应用能够与语音助手大量集成，以便经由语音助手功能执行与用户的语音话语相关联的命令，并且也无缝地引起客户端应用自动地执行本地功能作为执行所述语音话语的一部分。这样的大量集成也允许特定实施例支持来自用户的用于单个会话交互的多模态输入。以这种方式，替代或补充所述语音话语，执行客户端应用用户界面交互，诸如点击、触摸手势或者文本输入。

Description

具有用户视图上下文和多模态输入支持的支持语音助手的客 户端应用

背景技术

用户可以依赖于支持语音的数字助手(语音助手)来执行各种任务。例如，用户可以发出“唤醒词”，所述“唤醒词”触发启用智能扬声器或者支持语音助手的计算设备，以收听来自用户的语音话语。然后，用户可以发出语音话语，其可以包括语音命令，诸如执行任务(例如，播放特定歌曲或者启用家庭设备等)的自然语言请求。然后，智能扬声器(或者支持语音助手的计算设备)可以将所述命令传输给语音识别服务和/或技能服务，以根据其技能能力来执行所述命令。

尽管语音助手功能可以与特定的客户端应用(例如，定位地图应用或者电子邮件应用)一起使用，但是这样的语音助手功能通常位于操作系统的外壳中或者客户端应用的顶部。这意味着语音助手功能没有与客户端应用充分集成以便运行命令、执行请求或者以其他方式执行与语音话语相关联的操作，并且因此无法引起与客户端应用的有意义的交互，诸如通过在特定客户端应用用户界面处智能地切换页面、填充字段或者支持多模态输入(例如，语音和手动用户输入两者)。换言之，典型的语音助手功能不是原生地嵌入在客户端应用中以使得客户端应用能够根据语音话语和其他输入执行无缝动作。这样的常规的功能不仅对用户体验和用户界面能力产生负面影响，而且也不能准确地响应许多语音话语请求，并且对计算机资源消耗产生负面影响，以及其他缺点。

发明内容

提供本概要是为了以简化的形式引入概念的选择，这些概念在下文的详细描述中进一步描述。本概要并不旨在识别所要求保护的主题的关键特征或基本特征，也并不旨在孤立地用作确定所要求保护的主题的范围的辅助。

在本文中所讨论的各种实施例使得诸如通信应用(例如，电子邮件消息传递应用、在线会议应用、协作平台或者其他通信应用)的客户端应用能够与语音助手集成，以便经由语音助手功能执行用户的语音话语(例如，执行操作、请求或者执行与话语相关联的任务)，并且也无缝地使得客户端应用自动执行本机功能，作为执行语音话语的一部分。例如，一些实施例能够自动地并且智能地引起切换到用户希望或者需要执行预期任务或动作的图形用户界面页面，而且自动地并且智能地引起根据语音话语以信息来填充页面的特定字段。

在操作中，一些实施例用于接收客户端应用的第一实例(例如，页面或窗口)的语音话语数据和用户视图上下文(例如，当前被显示在用户屏幕上的数据)。至少部分地基于话语数据和用户视图上下文，各种实施例确定用户意图(例如，预测用户正在试图在客户端应用内完成的用户界面任务)。例如，语音话语可以是“向Jane发送聊天消息”。Jane的全名(例如，Jane Doe)或者用户标识符可以在客户端应用的第一实例处指示，或者Jane的联系信息可以以其他方式被客户端应用辨别。因为在语音话语中引用了词语“聊天消息”，并且因为客户端应用知道用户正在指代的是哪个Jane，所以语音助手可以使得客户端应用自动地从第一实例(例如，日历页面)切换到同一客户端应用内的第二实例(例如，聊天页面)，以执行用户的预期任务。响应于确定用户意图，各种实施例使得客户端应用在客户端应用的第一实例(或者另一实例)处自动地填充数据，其中，对数据的填充至少部分地基于执行用户的语音话语。例如，使用上文的例示说明，实施例能够预测用户意图是切换到在用户与Jane Doe之间的私人会话消息或线程的聊天页面，并且利用用户想要发送给Jane Doe的消息来自动地填充聊天页面的消息字段。该功能在用户体验、用户界面能力、准确性以及计算资源消耗方面改进了现有的语音助手技术，如在本文中更详细描述的。

在本文中所讨论的一些实施例使得语音助手和客户端应用能够支持来自用户的用于单个会话交互的多模态输入(例如，语音话语、触摸手势、鼠标点击、文本输入等)。以这种方式，替代地或者除了语音话语之外执行客户端应用用户界面任务。例如，如果两个输入是冲突的(例如，用户说了“否”但是点击了“是”)，则一些实施例能够接收用户在用户界面处已经参与手动输入(例如，触摸手势或者鼠标点击)的指示，并且然后根据哪一个在较晚的时间被接收，而使得客户端应用仅响应手动输入或语音话语。该功能改善了自然的人-计算机交互和用户导航体验，如在本文中更详细描述的。

附图说明

下文参考随附的附图详细描述本发明，其中：

图1是图示了适于实现本公开的各方面的示例性操作环境的框图；

图2是描绘适于实现本公开的各方面的示例性计算架构的框图；

图3是根据本公开的一些实施例的用于至少部分地基于用户视图上下文来执行客户端语音话语请求的示例性系统的框图；

图4A是图示了根据本公开的一些实施例的如何使用用户视图上下文来初始化用于预测用户意图的数据结构的示意图；

图4B是图示了根据本公开的一些实施例的至少部分地基于用户视图上下文如何执行语音话语的示意图；

图5是根据本公开的一些实施例的示例性网络图的示意图；

图6A-6B是根据本公开的一些实施例的与语音话语有关的用户界面的截屏或页面；

图7A-7H是根据本公开的一些实施例的与各种语音话语有关的用户界面的截屏或页面；

图8描绘了根据本公开的一些实施例的通过填充客户端应用的特定实例来执行用户的语音命令的示例性过程流程；

图9描绘了根据本公开的一些实施例的通过确定用户意图来使得客户端应用执行语音话语的示例性过程流程；

图10是图示了根据本公开的一些实施例的如何处理多模态请求的序列图；

图11是图示了根据本公开的一些实施例的如何经由回叫功能提交语音话语请求的序列图；

图12是图示了根据本公开的一些实施例的如何经由回叫功能来处理多模态请求的序列图；

图13是根据本公开的一些实施例的两个数据结构的示意图，其图示了客户端和一个或多个服务器如何处理来自用户的不同类型的输入；

图14是根据本公开的一些实施例的用于回滚会话状态的示例性图形数据结构的示意图；

图15是图示了根据本公开的一些实施例的如何从用户角度处理多模态输入的示意图；

图16是图示根据本公开的一些实施例的如何从用户角度处理多模态输入的示意图；

图17是根据本公开的一些实施例的用于选择性地响应多个输入中的仅一个输入的示例性过程的流程图；

图18是根据本公开的一些实施例的用于选择性地响应多个输入中的仅一个输入的示例性过程的流程图；以及

图19是适于在实现在本文中所描述的一些实施例中使用的示例性计算设备的框图。

具体实施方式

本公开的各方面的主题在本文中被具体描述以满足法定要求。然而，描述本身并不旨在限制本专利的范围。相反，发明人已经考虑到，所要求保护的主题也可以结合其他当前或未来技术以其他方式体现，以包括不同的步骤或步骤的组合，这些步骤类似于在本文中所描述的步骤。此外，尽管术语“步骤”和/或“框”在本文中可以用于表示所采用的方法的不同元素，但是术语不应当被解释为暗示在本文中所公开的各种步骤之中或之间的任何特定顺序，除非明确描述了各个步骤的顺序。在本文中所描述的每种方法可以包括可以使用硬件、固件和/或软件的任意组合来执行的计算过程。例如，各种功能可以由运行被存储在存储器中的指令的处理器来执行。所述方法也可以被体现为被存储在计算机存储介质上的计算机可用指令。这些方法可以由独立应用、服务或托管服务(独立或与另一托管服务组合)或者另一产品的插件来提供，等等。

如在本文中所描述的，现有的智能助手技术没有充分地与客户端应用集成以便通过引起与客户端应用的有意义的交互来执行语音话语。例如，与电子通信和/或会议应用一起使用的一些智能助手技术使用按键通话功能(例如，麦克风按钮)来执行向通信接收者和/或会议参与者发送消息的用户请求。为了执行用户语音话语请求，这些技术在客户端应用上渲染用户界面弹出屏幕或者其他用户界面元素，其中，用户界面元素包含用于执行请求的结果(例如，消息已经被发送的指示)。然而，这样的用户界面元素是智能助手画布的一部分(而不是客户端应用画布的一部分)。另外地，这样的消息不被自动地插入到底层客户端应用的任何字段或页面(例如，聊天页面)中。例如，常规智能助手可以使用单独的服务或者应用来发送消息，而不是按照用户意图使用客户端应用的功能。这样的常规技术不能够捕获用户的全部任务和/或通信，因为没有由客户端应用维护的消息的历史。此外，这些智能助手技术不能够引起任何其他客户端应用功能，诸如向通信添加文件、更新草稿通信或者其他任务、智能地切换页面等。换言之，这些技术提供了“单发(single shot)”响应，以通过语音助手管理的单独用户界面元素执行用户的话语，但是不会导致底层客户端应用的任何额外功能。这可能使得用户在客户端应用处执行不必要的手动用户输入和导航步骤，诸如将消息输入到电子会议客户端应用的聊天字段中。这对用户体验产生负面影响，因为用户必须费力地执行这些手动用户输入。

其他现有的语音助手技术(诸如与定位地图服务一起使用的那些技术)提供快捷功能，以将用户带到特定的客户端应用页面，作为执行语音话语请求的一部分。快捷方式指示在应用工作流的特定页面处向应用的“切换(handoff)”。然而，在切换之后，这些语音助手技术或客户端应用不自动地执行其他功能，并且用户仅自己手动地完成任务。这与上文所描述的其他语音助手技术的“单发”问题相似。例如，在切换之后，这些技术无法使得在客户端应用处自动地填充任意特定字段来帮助执行语音话语请求。这同样使得用户在客户端应用处执行不必要的手动用户输入和导航步骤，这对用户体验有负面影响，因为用户在切换之后必须费力地输入额外信息(例如，在下一个加油站之后添加一站)。

现有的语音助手技术也未能考虑特定客户端应用的用户视图上下文(例如，关于当前打开的窗口的信息)，以便确定语音话音的用户意图来执行所述语音话语。例如，使用电子邮件应用，用户可以打开窗口，在其中填充了“to”字段，所述字段已经包括姓名“JohnDoe”。然后，用户可以发出例如“添加他的经理”的语音话语命令。现有技术可以例如查看被存储在计算机存储器中的预定用户简档，以查看John Doe的经理是谁，或者使用先前用户语音话语的上下文。然而，由于这些技术不使用当前打开的窗口的上下文，因此其例如将无法基于窗口中的信息直接利用额外的“Jane Doe”姓名(即，John Doe的经理)来填充“to”字段。此外，提供额外的用户视图上下文以确定用户意图有助于执行语音话语的更好的准确性。例如，使用上文的例示说明，现有的技术可能基于声明“发送标记消息”的先前语音话语来不准确地执行语音话语“添加他的经理”，而不识别用户已经转移到新的上下文。因此，现有的技术可以预测“他的”(在消息“添加他的经理”中)指代的是Mark(而不是John doe)，并且因此不准确地返回Mark的经理，而不是正确地返回John doe的经理。在没有用户当前正在做什么的上下文或者用户的当前视图的情况下，语音助手可能不准确地确定用户的意图，导致用户沮丧。

现有的语音助手技术也消耗不必要的量的计算资源，诸如分组生成成本和磁盘I/O。如上文所描述的，因为现有的语音助手技术没有与客户端应用充分地集成，所以其要求用户手动地执行过多的输入，诸如退出语音助手用户界面画布、钻到其他客户端应用页面以完成与语音话语相关联的任务(例如，切换到聊天窗口)、填充字段、发送查询等。在特定情况下，诸如关于基于web的应用，对于这些用户输入，客户端应用发送必须重复地遍历计算机网络的消息，这导致过多的分组生成成本并且对计算机网络通信产生不利影响。例如，每当用户发出查询(例如，HTTP请求)时，在TCP/IP和其他协议网络中的分组内通常利用报头信息或者其他元数据来补充查询的内容或有效载荷。因此，当该功能乘以完全完成语音话语请求所需的所有手动输入和/或如上文所描述地解决用户意图的不准确尝试时，通过重复地生成该数据并且在计算机网络上多次发送该数据，存在吞吐量和延时成本。以相似的方式，存在磁盘I/O成本(例如，在非易失性磁盘上的过多物理读/写头移动)，因为每当用户输入该信息(诸如填充各种字段)时，计算系统常常必须联系存储设备以执行读或写操作，这是耗时的、容易出错的，并且最终会磨损诸如读/写头的组件。

现有的语音助手技术也难以或者不能够支持多模态输入(例如，语音、触摸、鼠标点击)而用户不会出错并且具有可预测性。这是因为可能接收到冲突的输入，并且对于用户而言，可能不清楚哪些输入被处理了。例如，语音助手可能会说：“您确定想要开灯吗？”用户可能会说：“是的”，但是随后不久点击表示“否”的用户界面按钮。现有的技术试图通过将虚拟助手锁定到单个模态来解决该问题。例如，使用上文的例示说明，现有的虚拟助手将通过执行“是”请求来将虚拟助手锁定到语音，因为用户使用语音输入开始了对话会话，或者首先经由语音输入回答“是”。另外，由于用户陈述了与语音的交互，因此现有的虚拟助手可能仅收听语音话语，而忽略其他用户界面模态。然后，用户将无法为相同的会话执行手动用户输入，诸如触摸、点击等。

本公开的各种实施例提供了对这些技术问题以及如在本文中所描述的其他问题的一种或多种技术解决方案。在操作中，本公开的各种实施例涉及在客户端应用的第一实例(例如，页面或窗口)处接收话语数据和用户视图上下文(例如，当前被显示在用户屏幕上的数据)。例如，在通信和/或会议客户端应用(例如，MICROSOFT OUTLOOK、MICROSOFTTEAMS)的日历页面上，客户端应用可以首先检测“语音助手…向Jane发送我可能迟到的聊天消息”的语音话语。响应地，实施例可以自动地提取在日历页面(例如，用户视图上下文)处的一些或全部信息，因为其在用户屏幕上被打开。日历页面可以包括若干会议的列表，在其中突出显示了第一会议。至少部分地基于话语数据和用户视图上下文，各种实施例确定用户意图(例如，预测用户正在试图在客户端应用内完成的用户界面任务)。例如，各种实施例可以确定，因为在日历页面处突出显示了第一会议，所以用户正在参考第一会议。并且，由于在语音话语中引用了词语“聊天消息”，因此用户意图是在同一会议应用中自动地从日历页面切换到聊天页面。此外，实施例能够通过例如遍历网络图或者其他数据结构和/或确定在日历页面上已经引用了Jane，将Jane与姓氏和/或用户标识符映射并且向她发送消息，来确定用户正在引用哪个“Jane”。

响应于确定所述用户意图，各种实施例使得客户端应用在客户应用的第一实例(或者另一实例)处自动地填充数据，其中，对数据的填充至少部分地基于执行用户的语音话语。例如，使用上文的例示说明，实施例能够预测所述用户意图是切换到具有在用户与Jane Doe之间的私人对话线程的聊天页面，并且自动地填充聊天页面内“我将迟到”的消息字段。因此，一些实施例使得从日历页面到私人聊天页面的自动切换，并且至少部分地基于用户视图上下文来自动地填充具有文本“我将迟到”的消息字段。

在进一步的操作中，一些实施例经由客户端应用接收话语数据，其中，所述话语数据对应于用户的语音话语。例如，所述语音话语可以是“设置下午4点的警报”。特定实施例也接收用户在客户端应用的用户界面处进行手动用户输入的指示。例如，所述手动用户输入可以是对用户界面元素的点击，诸如指示将警报设置为下午4:30而不是下午4:00的下拉菜单标识符。一些实施例可以确定在较晚的时间接收到哪种模态或输入，并且基于此，使得客户端应用仅响应语音话语或手动用户输入。例如，一些实施例确定手动用户输入是相对于话语数据在较晚的时间接收到的，并且至少部分地基于该确定，使得客户端应用仅响应手动用户输入(并且因此避免响应语音话语)。

本公开的各种实施例改善了现有的语音助手技术，因为其与客户端应用完全集成，以便通过引起与客户端应用的有意义的交互来执行语音话语(例如，执行操作、请求或者执行与话语相关联的任务)。例如，替代渲染作为语音助手画布的一部分的用户界面弹出屏幕或者其他非直观用户界面元素，一些实施例替代地在本机客户端应用本身内引起有意义的交互，诸如引起特定客户端应用页面的自动切换以及引起客户端应用内特定字段的自动填充。这比现有的技术的“单发”和“切换”解决方案明显更多，因为这些实施例在本机客户端应用本身内提供了增强的、直观的功能。以这种方式，即使语音助手功能可以是使用相对于客户端应用的远程服务(例如，语音到文本服务和语言理解服务)的单独功能，但是其被集成在客户端应用内，使得用户体验和用户界面具有用户熟悉的本机客户端应用用户界面的相同“外观和感觉”。因此，本公开的特定实施例改善了用户体验、用户效率和用户-计算机交互，以及其他优点。

以相似的方式，本公开的各种实施例通过减少完成或者执行语音话语所需的导航、钻进和手动输入的量来改善用户体验和用户界面。如上文所描述的，采用“单发”或“切换”解决方案的现有技术使得用户在客户端应用处执行不必要的手动用户输入和导航步骤，诸如将消息输入到电子会议客户端应用的聊天字段中。这对用户体验产生负面影响，因为用户必须费力地执行这些手动用户输入。然而，各种实施例自动地执行这些步骤，诸如基于现有技术未使用的新技术(例如，用户视图上下文)，自动地切换到聊天页面并且自动地利用有效载荷消息来填充特定字段。

本公开的各种实施例也改善了完成或者执行语音命令请求的准确性，因为其考虑了额外上下文，诸如用户视图上下文。与现有的语音助手技术不同，各种实施例考虑特定客户端应用的用户视图上下文，以便确定语音话语的用户意图以执行语音话语。例如，使用电子邮件应用，用户可以打开窗口，所述窗口具有已经包括姓名“John Doe”的填充的“to”字段。然后，用户可以发出例如“添加他的经理”的语音话语命令。例如，各种实施例将能够至少部分地基于在所显示的窗口中的信息，直接地导致利用额外的“Jane Doe”姓名(即，JohnDoe的经理)来填充“to”字段。提供额外的用户视图上下文以确定用户意图，通过识别用户当前正在做什么，使得用于执行语音话语的准确性更好。

本公开的各种实施例也改善了相对于现有技术的计算资源消耗。由于各种实施例与客户端应用充分地集成，因此其不需要用户手动地执行过多的输入，诸如退出语音助手控制的用户界面画布、钻到其他客户端应用页面以完成与语音话语相关联的任务(例如，切换到聊天窗口)、发送查询等。相反，这些实施例不依赖于位于客户端应用顶部的语音助手控制层，而是自动地提供数据。因此，当例如TCP/IP分组遍历网络时，由于在计算机网络上发送的数据较少，因此吞吐量和延时成本降低。以相似的方式，由于用户不必继续输入信息，诸如通过与语音助手控制的窗口交互、填充语音助手控制的窗口的各种字段等，因此没有那么多的盘I/O成本(例如，在非易失性盘上的多余物理读/写头移动)。因此，相对于现有技术，计算系统不必联系存储设备以多次执行读或写操作，这减少了I/O。

特定实施例也改善了现有的语音助手功能，因为其支持对用户无错误并且具有可预测性的多模态输入。这是因为这些实施例使用自动地处理不同用户输入的新规则，即使当这样的输入是冲突的时。一些实施例另外可视地指示处理了哪些用户输入。这样的可视指示或者使用新规则使得用户清楚地知道哪些输入被处理了。例如，使用上文的例示说明，其中，语音助手可能会说：“您确定想要开灯吗？”用户可能会说：“是的”，但是随后不久点击表示“否”的用户界面按钮。特定实施例确定相对于“是”输入在时间上最后接收到“否”输入，而不是将虚拟助手锁定到单个模态以仅执行“是”请求。基于指定响应在时间上最后输入的请求的规则(或者声明处理UI输入并且停用麦克风的规则)，特定实施例仅响应“否”输入(而不响应“是”输入)。针对冲突的输入的较晚或最后输入更有可能反映用户意图，因为其通常指示用户的想法发生了变化。这改善了自然的人-计算机交互，因为用户更好地指示哪些输入正在被处理，而处理那些输入的机器由于控制如何处理输入的新规则而不太可能经历错误，尤其是当这样的输入是冲突的时。与此相关，改善了用户导航和辅助，因为能够处理由用户所使用的全系列的模态输入(例如，语音、触摸、文本输入、点击)，而不是经由锁定功能仅处理一种。

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

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

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

用户设备102a和102b至102n能够是操作环境100的客户端侧上的客户端设备，而服务器106能够在操作环境100的服务器侧上。服务器106能够包括服务器侧软件，所述服务器侧软件被设计成与用户设备102a和102b至102n上的客户端软件协同工作，以便实现在本公开中所讨论的特征和功能的任意组合。提供操作环境100的这种划分是为了例示说明合适环境的一个示例，并且对于每个实现方式不要求服务器106与用户设备102a和102b至102n的任意组合保持为单独的实体。在一些实施例中，一个或多个服务器106表示云计算环境中的一个或多个节点。与各种实施例一致，云计算环境包括提供一个或多个云计算服务的基于网络的分布式数据处理系统。此外，云计算环境能够包括被设置在一个或多个数据中心内并且被配置为在一个或多个网络110上共享资源的许多计算机，数百个或数千个或者更多个计算机。

在一些实施例中，用户设备102a或服务器106可以包括一个或多个服务，所述一个或多个服务被配置为至少部分地基于用户视图上下文来帮助执行用户的语音话语。例如，这些(一个或多个)服务可以包括：理解语音命令的自然语言处理服务、播放用户已经请求的歌曲的音乐提供者服务、提供用户已经请求的当前天气条件的天气服务、提供用户已经请求的当前新闻的新闻服务、和/或响应于用户请求使得一个或多个家庭设备(例如，灯)启用的家庭设备启用服务。在各种情况下，每个服务可以对应于语音助手支持的特定技能。

在一些实施例中，用户设备102a或服务器106替代地或额外地包括一个或多个web服务器和/或应用服务器，以促进向被安装在用户设备102b上的浏览器输送web或在线内容。所述内容常常可以包括静态内容和动态内容。当诸如web浏览器的客户端应用经由URL或搜索项请求网站或web应用时，浏览器通常联系web服务器以请求静态内容或者网站或web应用的基本组件(例如，HTML页面、图像文件、视频文件等)。应用服务器通常提供web应用的任何动态部分或者web应用的业务逻辑部分。业务逻辑能够被描述为管理在用户设备与数据存储库(例如，数据库)之间的通信的功能。这样的功能能够包括业务规则或工作流(例如，指示条件if/then语句、while语句等以表示过程顺序的代码)。

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

数据源104a和104b至104n可以包括数据源和/或数据系统，其被配置为使数据可以用于结合图2所描述的操作环境100或系统200的各种组成部分中的任意一个。数据源104a至104n的示例可以是以下中的一项或多项：数据库、文件、数据结构或者其他数据存储库。数据源104a和104b至104n可以与用户设备102a和102b至102n和服务器106分开，或者可以被并入和/或集成到那些组件中的至少一个组件中。在一个实施例中，数据源104a至104n包括传感器(诸如传感器103a和107)，其可以被集成到用户设备102a、102b或102n或服务器106中或者与其相关联。

操作环境100能够用于实现如在图2中所描述的系统200的组件中的一个或多个组件，包括用于至少部分地基于用户视图上下文执行语音话语的支持语音到的应用的组件。操作环境100也能够用于实现结合图8和图9所描述的过程800和900的各方面以及结合图2-8所描述的任何其他功能。

现在参考图2，结合图1，提供了示出适于实现本公开的实施例的示例性计算系统架构的各方面的框图，并且通常被指定为系统200。通常，系统200的实施例通常负责至少部分地基于用户视图上下文来执行语音话语请求。系统200的特定实施例另外地或者替代地负责处理多模态输入。系统200并不旨在限制，并且仅表示合适的计算系统架构的一个示例。除了或者替代所示的那些布置和元素，能够使用其他布置和元素，并且为了清楚起见，可以完全省略一些元素。此外，与图1的操作环境100一样，在本文中所描述的元件中的许多元件是功能实体，其可以作为分立或分布式组件或者与其他组件结合实现，并且以任何合适的组合和位置来实现。例如，系统200的功能可以经由软件即服务(SAAS)模型，例如，云和/或基于web的服务来提供。在其他实施例中，系统200的功能可以经由客户端/服务器架构来实现。

系统200包括消费者应用204(在本文中也被称为“客户端应用”)、语音识别模块212、上下文理解模块218、呈现模块224、存储设备225、请求类型确定模块226、打断模块以及初始请求处理模块230，其中的每个经由(一个或多个)网络110通信地耦合。消费者应用204通常负责检测用户的一个或多个语音话语，从消费者应用的一个或多个实例提取用户视图信息，以及自动地填充应用的对应实例以执行语音话语请求(例如，执行操作或者执行与话语相关联的任务)。在系统200中所描绘的示例性消费者应用204包括语音话语检测器206、用户视图上下文信息提取器208以及用户意图-视图映射器210。

消费者应用204通常指代计算机应用或服务，诸如在线/云应用或者本地存储的应用，其消费或利用由系统200所确定的计算机对象或计算机资源。消费者应用的示例可以包括但不限于：用于促进会议或通信的计算机应用或服务；电子邮件、消息传递、聊天或打电话；项目管理；和/或日历或日程安排。例如，合适的消费者应用可以包括MICROSOFT TEAMS、MICROSOFT DYNAMICS和/或MICROSOFT OUTFOOK。

语音话语检测器206通常负责检测用户的一个或多个语音话语。“语音话语”可以包括从用户说出的词语(例如，“唤醒词”)、短语、句子、命令、请求和/或声音。在一些实施例中，所述语音话语是用作认证或授权(例如，关键词检测)的关键词或唤醒词，以触发组件(例如，音频应用编程界面(API))来发起对音频的记录以收听或检测音频输入。因此，响应于检测到关键词，消费者应用204能够启用逻辑麦克风，所述逻辑麦克风被配置为启用和/或编码高于阈值(例如，特定dB水平)的任何噪声。如下文更详细描述的，在一些实施例中，基于对用户界面元素(例如，mic图标)的用户选择来启用逻辑麦克风，所述用户界面元素指示用户意图参与语音助手。如在本文中所描述的编码指代数据被存储和/或传输的方式，其通常经由特定标准(例如，FLAC、LINEAR16、AMR或者其他标准)发生。编码使用频率响应和动态范围重构声音。重现频率的功能是“频率响应”，并且创建恰当响度或噪声水平的功能是“动态范围”。

在一些实施例中，音频API是被触发以启用音频收听功能的组件。音频API可以是处理和合成消费者应用204中的音频的消费者应用204的组件。在一些实施例中，音频API是经由W3草案标准在任何web应用中创建和处理声音的web音频API。例如，音频API能够包括音频增益控制(AGC)和回声消除(AEC)组件，这些组件调整麦克风水平并且放大音频以使通话清晰。音频API允许在执行中具有接近本机的音频质量。亦即，音频API允许类似于具有本机语音检测和编码功能的设备(例如，智能扬声器)的语音检测和编码能力。因此，在特定实施例中，在使用特定语音助手设备与在web上使用相同功能之间不需要极端的质量权衡。

在语音话语检测器206的例示性示例中，用户能够陈述“语音助手...邀请Jane到会议”，其中，“语音助手”是关键词语音话语，并且“邀请Jane到会议”是语音命令语音话语。响应于检测到关键词语音话语，触发组件(例如，音频API)。所述组件可以被配置为记录来自用户的给定语音命令。例如，能够启动逻辑麦克风或者其他功能来记录或收听声波。在接收到语音命令之后，并且至少部分地基于对组件的触发，可以额外地或者替代地对用户的语音命令(例如，“邀请Jane到会议”)进行编码。例如，当用户发出语音命令并且组件被触发时，消费者应用204响应地对语音命令进行编码。基于对语音命令的编码或接收，使得语音命令至少部分地被执行。亦即，为了进行编码或者进一步处理，在特定实施例中触发组件(例如，麦克风)。例如，消费者应用204能够基于触发组件和接收语音命令将经编码的语音命令传输给服务，然后从一个或多个服务(例如，语音识别模块212和上下文理解模块218)取得数据，以完成中语音命令中所指示的请求的执行，如在下文中更详细描述的。

用户视图信息提取器208通常负责提取或者确定消费者应用204的一个或多个实例和/或其他消费者应用的一个或多个其他实例的用户视图上下文。如在本文中所描述的“实例”可以指代用户界面或显示特征，诸如窗口(例如，弹出窗口)、应用页面(例如，ANDROID活动)、选项卡、对话框、窗格、按钮、字段、类似用户界面元素和/或可以由用户交互的任何其他显示特征。在一些实施例中，实例可以保持或包含值(例如，名称、地址、日期、文本或者其他值)或状态(例如，按钮的开或关、拨盘或滑块的设置)。如在本文中所描述的“用户视图上下文”指代至少一个消费者应用的一个或多个实例内的数据。在一些实施例中，当前打开一个或多个实例中的至少一个实例，使得其被显示在用户设备屏幕上(例如，弹出窗口)。在一些实施例中，一个或多个实例中的至少一个实例另外地或者替代地正在运行、不活动或者已经被渲染但不可见。例如，应用的第一页面能够利用覆盖第一页面一半的弹出窗口渲染，或者用户可能已经从所述应用的第一页面导航到所述应用的第二页面(或者导航到另一应用中的页面)，使得第一页面现在不活动或者不再可见。在这些实施例中，第一页面中的信息的部分(其可以是非活动的或者其可以被弹出窗口、第二页面或第二应用的页面覆盖)可以被包含在用户视图上下文中，即使其可能当前不可见或者是不活动的。在一些实施例中，一个或多个实例另外地或者替代地是在阈值时间段(例如，5分钟)内或者在用户会话(诸如相对连续的用户活动或者与用户-设备交互的持续时间)内由用户已经与其交互的那些实例。例如，用户视图上下文可以包括来自客户端应用的第一页面的信息，所述信息被渲染到用户设备，即使当前没有显示，因为例如第一页面在2分钟内已经关闭(例如，来自页面的数据不再被认为是用户视图上下文的阈值)。用户视图上下文能够另外地或者替代地指代当前正在运行的应用或实例的标识(例如，当前显示或者已经由用户打开但是未关闭)。

从用户角度来看，用户视图上下文能够是当前被显示给一个或多个计算机屏幕上的任意数据和/或在后台运行的任意数据，尽管其当前未显示。例如，应用页面可以具有由弹出窗口在视觉上屏蔽的第一数据。在一些实施例中，用户视图上下文包括弹出窗口和第一页面两者中的数据。在一些实施例中，用户视图上下文包括来自当前在后台运行或者在用户设备上可见的不同应用的数据。在一些实施例中，能够将用户视图上下文与应用或实例之外的上下文进行对比。例如，在一些实施例中，当前未查看或者未打开的特定应用页面或者在后台运行的应用页面可以不包括用户视图上下文。在一些实施例中，当前未打开或运行的任何消费者应用不包括用户视图上下文。在一些实施例中，在用户设备外部(例如，从服务器或传感器)获得的任何上下文不包括用户视图上下文。在一些实施例中，用户视图上下文信息提取器208被配置为从实例中提取特定值，诸如指示作为消费者应用的一部分的特定实例的身份的实例ID，并且进一步提取特定实例的字段和值，如下文更详细描述的。

用户视图上下文信息提取器208能够以任意合适的方式从客户端应用实例提取用户视图上下文。例如，在一些实施例中，用户视图上下文信息提取器208能够执行屏幕抓取和/或爬取(例如，爬取打开的浏览器中的所有选项卡)。屏幕抓取是从计算机屏幕上提取或复制人类可读数据的过程，以便能够将其用于其他目的。这样的视觉数据能够作为原始文本从诸如出现在计算设备桌面、消费者应用204本身(或者其他应用)和/或网站或浏览器上的文本或图像之类的屏幕上元素收集。在一些实施例中，屏幕抓取仅包括提取在计算机屏幕上可见的视觉自然语言数据，而不提取与这样的视觉数据相关联的元数据(例如，EXIF数据，诸如图像的分辨率值或者何时输入数据的时间戳)。

用户意图-视图映射器210通常负责经由数据结构(例如，散列映射)映射从上下文理解模块218和/或其他服务转移的结果有效载荷值，以便填充消费者应用204的对应实例以执行语音话语，如下文更详细描述的。如通篇所讨论的，为了执行一个或多个语音话语，本公开的各种实施例，诸如消费者应用204，在(一个或多个)网络110上传输经编码的(一个或多个)语音话语和/或用户视图上下文。响应地，与一个或多个服务相关联的一个或多个计算设备或组件(例如，语音识别模块212和/或上下文理解模块218)能够处理(一个或多个)语音话语并且取决于所支持的技能来取回信息。如在本文中所描述的，“技能”或“能力”指代用于执行语音话语的语音助手的特定能力类别。例如，第一语音助手技能能够是播放来自第一提供商的音乐，第二技能能够是提供天气预报，第三技能能够是回答问题，第四技能能够是启用家庭设备(例如，灯)。用户通常在语音助手执行语音命令之前定义语音助手执行的技能的至少一部分(例如，经由支付费用和经由应用输入技能请求)。因此，语音助手通常不执行语音命令，除非语音助手支持能够执行语音命令的技能，或者如果不能够识别特定技能，则可以从用户请求更多信息。

在由一个或多个服务处理的经编码的语音命令的示例性说明中，所述经编码的语音命令能够被传送给解释用户的自然语言语音命令的自然语言处理(NLP)服务(例如，上下文理解模块218)。响应地，所述服务(和/或用户设备)能够将请求传送给另一服务(例如，音乐服务)以帮助执行语音命令，然后将有效载荷传送(或者引起传输)回用户设备和/或其他计算设备(例如，web服务器)，其使得或者引起请求被执行。在说明性示例中，已经打开电子邮件web应用(例如，消费者应用204)的用户能够通过说：“嘿，语音助手…提出我昨天下午1点与2点之间发送的每封电子邮件”而发出语音命令。用户可能正在寻找特定的电子邮件。该语音命令能够由消费者应用204编码并且传输到NLP服务和托管所显示的web页面或web应用的web服务器和/或应用服务器。所述web服务器和/或应用服务器然后能够引起或者使得消费者应用204能够基于用户意图-视图映射器210在用户设备内显示下午1点与2点之间的电子邮件，如下文更详细描述的。

语音识别模块212通常负责将来自消费者应用204(或者包括消费者应用204的用户设备)的语音或音频数据(例如，经由语音话语检测器206检测到的)转换为对应的自然语言文本(例如，经由语音到文本功能)。语音识别模块212包括实体识别模块214和语音到文本转换模块216。实体识别模块214通常负责识别用于语音识别的实体。在一些实施例中，实体表示在命名实体识别(NER)中所确定的对象。在一些实施例中，语音识别模块212将经由语音话语检测器检测到的经编码的音频作为输入，并且产生自然语言文本的输出，如语音到文本转换模块216所执行的。因此，例如，消费者应用能够编程地调用语音识别模块212(和/或其他服务)或者与其通信，以便触发语音识别模块212。

NER是一种信息抽取技术，其将自然语言中的元素或者“实体”识别并且分类到预定义的类别中。可以在对应的标记或标签中指示这样的预定义的类别。在各种实施例中，NER因此将非结构化数据变换为结构化的数据，并且因此机器可读取并且能用于处理。实体能够是例如人名、特定组织、特定地点、特定时间、特定数量、特定货币价值、特定百分比等。类似地，对应的标记或标签能够是“人员”、“组织”、“位置”、“时间”等。

在说明性示例中，用户可以发出说“语音助手，告诉Rhonda等待”的语音话语。根据各种实施例，NER功能能够如下标记该项目标题“告诉[请求]”“Rhonda[姓名]”“去往[x]”“等待”[不采取进一步的动作；消息有效载荷]。在各种实施例中，[x]标记是计算机的机器可读指示符，以移除这样的术语来进一步处理(例如，将其作为输入放入到分类器或单词嵌入)。在一些实施例中，实体在诸如网络图或者其他图结构的数据结构中被指示或者确定，如下文更详细描述的。

语音到文本转换模块216通常负责将音频语音(例如，经由实体识别模块214处理)转换为文本。在一些实施例中，这样的功能经由声学模型和/或语言模型发生。声学模型将音频转换成小的声学单元，这些声学单元与语言中日常使用的声音相匹配。语言模型将声学单元转换为词语和短语，并且分析词语之间的关系以确定要使用哪些单词。在一些实施例中，语音到文本转换模块216使用高斯混合模型(GMM)和/或隐马尔可夫模型(HMM)来检测音频语音并且将其转换为文本。语音到文本(也被称为语音识别)能够将音频流实时转录为文本。

在一些实施例中，语音到文本转换模块216将语音记录的音频分解成个体声音，使用算法(例如，GMM或HMM)分析每个声音以找到适合该语言的最可能的词语，并且将那些声音转录成文本。在一些实施例中，语音到文本转换模块216使用NLP模型(例如，GPT-3、BERT、XLNET或者其他NLP模型)和/或深度学习神经网络来执行其功能。NLP是计算机从人类语言中分析、理解和推导意义的一种方法。这意味着语音到文本转换模块216将语音分解成其能够解释的位，将其转换成数字格式，并且分析内容片段。

上下文理解模块218通常负责确定或者预测用户发出的语音话语的用户意图。如在本文中所描述的“用户意图”指代用户正在试图经由语音话语来完成的一个或多个动作或任务。在一些实施例中，用户意图替代地或者另外地指代用户试图在客户端应用内完成的特定用户界面任务。在一些实施例中，上下文理解模块218将由语音到文本模块216提供的输出文本和经由用户视图上下文信息提取器208提供的用户视图上下文作为输入，并且输出用户意图。因此，语音识别模块212和/或消费者应用204能够编程地调用上下文理解模块218或者与上下文理解模块218通信，这触发了上下文理解模块218的功能。

在一些实施例中，上下文理解模块218表示或者包括一个或多个语言理解模型或服务，以理解语音话语的语义含义(或者用户意图)。这样的理解能够包括使用基于NLP的功能或模型，诸如WORD2VEC、BERT、RoBERTa和/或类似的功能或模型。例如，上下文理解模块218能够包括解析和串联组件，其根据内容令牌化和断开字符序列(例如，句子、词语、短语等)，并且将其他字符序列(例如，语义相似的词语)和/或标记(例如，词性)连接到令牌化的字符序列。在一些实施例中，连接的字符序列是NLP组件或库的一部分，其中，每个内容被解析为其词语，并且一些或每个词语被标记有词性标识符。

在各种实施例中，“令牌化”或解析对应于将内容分段成词语、句子、符号、字符序列和/或内容的其他元素的计算机实现的过程。“句法”或句法性质指代内容的字符序列的结构(相对于语义或意义)，诸如句子的结构。这能够包括用于分析消息的规则集，诸如词语和/或词性(POS)顺序。例如，对于句子“女孩高兴地跳了起来”，句法可能对应于词序，其中，结构是主语-动词-副词(或者主语、动词、宾语或类似的结构)。在各种实施例中，标记消息元素的POS。

在一些实施例中，NLP导出半结构化或非结构化数据(例如，图像文件中的数据，博客、帖子、网站中的数据，分类器模型的文本描述，或者其他数据源)的语义和句法内容。这与分析“结构化”数据(诸如数据库中的数据)形成对比。NLP能够被配置为解析内容以确定语义上下文(例如，通过相互对照和对照训练数据分析内容中的每个词语来确定词语的含义)和语法上下文(例如，管理给定语言中的句子的结构的规则集)。NLP被配置为识别与数据集的一个或多个部分相关联的关键字、上下文信息和元数据标记。在特定实施例中，NLP分析被包含在数据集中的概要信息、关键字、文本描述，并且使用存在于该信息中的句法和语义元素来识别文本的语义意义。所述句法和语义元素能够包括诸如词频、词义、文本字体、斜体、超链接、专名、名词短语、词性(例如，名词、副词、形容词等)和/或周围词语的上下文的信息。其他句法和语义元素也是可能的。

上下文理解模块218包括用户视图上下文模块222。用户视图上下文模块222通常负责基于由用户视图上下文信息提取器208提取的信息来确定或预测用户视图上下文。在一些实施例中，用户设备通过(一个或多个)网络110传输由用户视图上下文信息提取器208提取的数据，以便例如确定用户当前正在查看哪些实例以及存在于那些实例内的数据，以便帮助上下文理解模块218确定总体用户意图。例如，如果用户视图上下文模块222获得用户当前打开电子邮件应用的窗口的信息，其中，所述窗口具有填充有“John Doe”的“to”字段，并且用户额外地发出了说“将Jake添加到消息中”的语音话语，则上下文理解模块218能够基于当前用户视图中的信息来推断用户意图利用Jake的电子邮件来填充“to”字段。

在一些实施例中，响应于上下文理解模块218确定用户意图，其通过(一个或多个)网络110将客户端动作请求和结果有效载荷传输到包括消费者应用204的用户设备，使得消费者应用204能够响应地填充适当的字段和/或切换到适当的实例，以便执行语音话语请求。“客户端动作请求”是针对消费者应用的特定请求，以利用结果有效载荷填充特定实例和/或执行某个特定动作(例如，切换页面或实例、向下滚动等)。“结果有效载荷”是基于语音话语返回到客户端的值。例如，如果语音话语是向John发送特定消息的请求，那么结果有效载荷可能包括实际消息。

在一些实施例中，上下文理解模块218从用户视图上下文之外的额外源确定用户意图。例如，上下文理解模块218能够使用电子邮件消息、聊天、来自用户设备的文本消息、过去的会议转录、示出不同信息集之间关系的数据结构(例如，网络图)等。

呈现模块224通常负责向用户呈现内容和相关信息。呈现模块224可以包括用户设备上、跨多个用户设备或云中的一个或多个应用或服务。例如，在一个实施例中，呈现模块224管理跨与用户相关联的多个用户设备向用户呈现内容。基于内容逻辑、设备特征、相关联的逻辑中心、推断的用户的逻辑位置和/或其他用户数据，呈现模块224可以确定在哪个(些)用户设备上呈现内容以及呈现的上下文，诸如如何呈现和/或何时呈现内容(或者以何种格式和多少内容，这能够依赖于用户设备或上下文)。具体地，在一些实施例中，呈现模块224将内容逻辑应用于设备特征、相关联的逻辑中心、推断的逻辑位置或者感测到的用户数据，以确定内容呈现的各方面。

在一些实施例中，呈现模块224生成与消费者应用204相关联的用户界面特征。这样的特征能够包括界面元素(诸如图形按钮、滑块、菜单、音频提示、警报、警告、振动、弹出窗口、通知栏或状态栏项、应用内通知或者用于与用户界面的其他相似特征)、查询、实例和/或提示。

示例性系统200也包括存储设备225。存储设备225通常存储包括在本文中所描述的技术的实施例中所使用的数据、计算机指令(例如，软件程序指令、例程或服务)、数据结构和/或模型的信息。通过示例而非限制，被包含在存储设备225中的数据以及任何用户数据通常可以通篇被称为数据。可以从传感器(在本文中被称为传感器数据)感测或确定任何这样的数据，诸如(一个或多个)移动设备的位置信息、智能电话数据(诸如电话状态、充电数据、日期/时间或者从智能电话导出的其他信息)、用户活动信息(例如：应用使用；在线活动；搜索；语音数据，诸如自动语音识别；活动日志；通信数据，包括电话、文本、即时消息和电子邮件；网站帖子；与事件相关联的其他记录；或者其他活动相关信息)，包括在多于一个用户设备上发生的用户活动、用户历史、会话日志、应用数据、联系人数据、记录数据、通知数据、社交网络数据、新闻(包括搜索引擎或社交网络上的流行或趋势项)、家庭传感器数据、家电数据、全球定位系统(GPS)数据、车辆信号数据、交通数据、天气数据(包括预报)、可穿戴设备数据、其他用户设备数据(其可以包括设备设置、简档、诸如Wi-Fi网络数据之类的网络连接，或者配置数据、关于型号、固件或设备、设备配对的数据，诸如在用户具有与蓝牙耳机配对的移动电话的情况下)、陀螺仪数据、加速度计数据、可以由传感器(或者其他检测器)组件感测或者以其他方式检测的其他传感器数据，包括从与用户相关联的传感器组件导出的数据(包括位置、运动、取向、位置、用户访问、用户活动、网络访问、用户设备计费，或者能够由传感器组件提供的其他数据)，基于其他数据(例如，能够从Wi-Fi、蜂窝网络或IP地址数据导出的位置数据)导出的数据，以及可以如在本文中所描述地感测或确定的几乎任何其他数据源。在一些方面中，可以在用户信号中提供日期或信息(例如，所请求的内容)。用户信号能够是来自对应数据源的各种数据的馈送。例如，用户信号可以来自智能电话、家庭传感器设备、GPS设备(例如，用于位置坐标)、车辆-传感器设备、可穿戴设备、用户设备、陀螺仪传感器、加速度计传感器、日历服务、电子邮件账户、信用卡账户或者其他数据源。存储设备225的一些实施例可以在其上存储包括规则、条件、关联、分类模型和其他标准的计算机逻辑(未示出)，以执行系统200的任何组件、模块、分析器、生成器和/或引擎的功能。

继续图2，系统200也包括请求类型确定模块226。请求类型确定模块226通常负责确定与特定模态、手动用户输入和/或客户端应用相关联的请求类型。在一些实施例中，请求类型确定模块226表示技能服务执行的功能。并且基于被处理或预期的请求的类型，特定实施例专门响应于语音话语或者手动用户输入。例如，特定请求类型在其已经开始处理时更难逆转或撤消，并且因此特定实施例实现在已经检测到这样的请求时处理这些请求的规则，而不管随后的冲突的输入如何。例如，语音助手可能发出语音话语说“您确定要将此电子邮件发送给Victoria吗？”用户可能会说“是”，但是随后不久在用户界面处点击“否”。请求类型确定模块226可以确定回答该问题所需的请求类型是“电子邮件发送”请求。然而，对于电子邮件发送请求，如果电子邮件已经发送，则不可能遵守“否”输入。因此，请求类型输送模块226可以查询指导响应哪个输入的规则集(例如，在存储设备225中)。例如，基于请求类型是“电子邮件发送”请求，可能有仅遵循第一接收到的或输入的请求的规则。因此，在这种情况下，请求处理模块230将忽略用户的第二输入(即，“否”输入)并且仅响应“是”输入。另外，在一些实施例中，初始请求处理模块230能够发出(或者导致在用户界面上呈现)短语“我已经发送了您的电子邮件”。这向用户给出“是”输入被执行而“否”输入未被执行的指示。

第一输入被遵循或响应的不同类型的请求类型的其他示例是交易请求。例如，交易请求可以包括点击按钮或者发出语音话语以支付项目或预订功能，诸如预订酒店或租车。在这些情况下，当交易在预订或购买过程中已经超过特定阈值时，就不可能逆转后续的和冲突的输入。因此，当期望或发出特定类型的请求时，特定实施例仅执行初始输入而不执行任何后续输入。

对特定请求类型的检测可以以任何适当的方式进行。例如，数据结构(例如，查找表或散列表)可以在同一记录中列出特定请求类型的关键ID，并且然后列出对应的规则。以这种方式，实施例能够将在请求中传递的请求类型ID与在数据结构中找到的请求ID进行匹配，并且然后实现对应的规则。例如，当用户发出语音话语或手动用户界面请求时，能够将请求类型ID从客户端应用传递到托管数据结构的一个或多个后端服务器，以便实现对应的规则。在说明性示例中，用户可以发出语音话语说“购买项目X”。响应地，特定实施例能够编码语音话语并且将请求ID类型传递为例如“交易请求”。这样的ID能够针对具有相同请求ID的数据结构运行，并且可以读取对应的规则，诸如“立即执行请求”(由此不允许处理随后的请求)。在这些实施例中，客户端应用能够具有利用交易请求类型ID标记或补充消息的特定功能，所述交易请求类型ID能够基于客户端应用本身，或者基于用户输入的语音话语或手动用户输入的类型。以这种方式，客户端应用能够具有其自己的映射逻辑，其将(例如，经由NLP或查找功能)用户输入映射到请求类型。

打断模块228通常负责执行或者响应用户的最后或最近的输入(以及避免执行或响应用户的(一个或多个)先前输入)。这通常发生在存在多个冲突和同时的输入的情况下，如在本文中所描述的。实现所述打断模块在同步客户端和服务器状态方面提出了挑战。取决于网络计时，例如，当用户提供第二输入时，(一个或多个)服务器可能已经处理了第一输入和改变的状态。在打断模块228的说明性示例中，用户可以发出陈述“播放艺术家B的歌曲A”的语音话语但是在阈值时间(例如，2秒)内点击指示播放艺术家B的歌曲C的用户界面按钮。因为相对于语音话语，用户界面按钮点击在较晚的时间发生，所以特定实施例响应于用户界面按钮(而不是语音话语)。因此，与歌曲A相反，特定实施例返回歌曲C。用于处理冲突的模态请求的各种数据结构和功能将在下文更详细地描述。

在一些实施例中，打断模块228在现有请求正在进行时接收请求，并且放弃或取消初始请求以处理传入的或最近的请求。在一些实施例中，客户端应用不向一个或多个服务器发送多个请求以执行所述请求。例如，如果在打断请求到达时请求正在飞向一个或多个服务器，则客户端应用可以在发送打断请求之前等待一个或多个服务器响应第一请求，即使用户可能在发送打断请求之前就已经参与了该请求。

初始请求处理模块230基于一个或多个规则仅响应或者执行初始请求(而不是后续请求)。例如，如上文所描述的，如果确定请求是交易请求类型，则特定实施例肯定地执行或者响应第一请求(例如，经由语音话语或手动用户输入请求)。在另一示例中，如果确定语音助手请求是“电子邮件发送”请求，则特定实施例可以肯定地响应或者执行电子邮件发送请求，并且避免响应任何后续的语音话语或手动用户界面动作。

图3是根据一些实施例的用于至少部分地基于用户视图上下文执行客户端语音话语请求的示例性系统300的框图。在一些实施例中，系统300的一个或多个组件表示或者被包含在图2的系统200的特定组件中。例如，在一些实施例中，客户端303被包含在消费者应用204中，语音识别服务313表示语音识别模块212，并且用户意图理解服务317表示上下文理解模块218。因此，这些组件可以包括与参考图2所描述的相同的功能。在一些实施例中，系统300的一些组件或者每个组件表示独立的软件组件、节点(例如，云计算节点)和/或服务器。例如，客户端303可以驻留在用户设备处。中间服务307可以驻留在第一云计算节点处，语音识别服务313可以驻留在第二云计算节点处，并且用户意图理解服务317可以驻留在第三云计算节点处。替代地，在一些实施例中，系统300的一些组件或每个组件表示驻留在同一主机中的软件模块。

根据示例性系统300的实施例，客户端303向中间服务307发送请求305。请求305包括话语数据(例如，由语音话语检测器206检测的音频编码的语音话语)和用户视图上下文(例如，如由用户视图上下文信息提取器208提取的)两者。中间服务307包括模块或机器，其能够用作在客户端303与语音识别服务313以及用户意图理解服务317之间的通信的中心点。具体而言，根据系统300的实施例，中间服务307将话语数据309(被包含在请求305中)转发给语音识别服务313。语音识别服务313将话语数据309作为输入，并且将音频话语数据309转换为自然语言文本(例如，在文档上)，其输出被称为语音到文本数据311。然后，语音识别服务313将语音到文本数据311传递给中间服务307。

响应地，中间服务307将语音到文本数据311与请求315中的用户视图上下文(被包含在请求305中)一起传递到用户意图理解服务317，以便确定或者预测与语音到文本数据311相关联的语音话语的用户意图。如上文所描述的，能够基于使用一个或多个NLP模型来确定文本数据中的语义，以及使用包括用户视图上下文的各种上下文源(例如，用户SMS文本消息、电子邮件线程、图结构等)，来确定这样的用户意图。

响应于确定或者预测所述用户意图，用户意图理解服务316生成客户端动作请求和结果有效载荷消息319并且将其发送回客户端303以执行请求305。尽管系统300指示用户意图理解服务317直接将消息319发送到客户端303，但是应当理解，在替代实施例中，用户意图理解服务317直接将消息319发送到中间服务307，并且然后，中间服务307将消息319转发到客户端303。在用户意图理解服务317和消息319的功能的说明性示例中，至少部分地基于当前显示用于第一日期的时隙窗口的用户设备和用户说“在对每个人都有效的时间安排会议”，用户意图理解服务317可以通过在自窗口打开以来在窗口处的打开时隙处填充会议来推断用户的意图是在打开时隙的第一日期安排会议。响应地，用户意图理解服务317可以发送客户端动作请求，以利用下午3点到下午4点的结果有效载荷来填充同一窗口的特定字段。

图4A是图示了根据一些实施例的如何使用用户视图上下文来初始化用于预测用户意图的数据结构的示意图。在一些实施例中，表400包括由图2的用户视图上下文信息提取器208提取的用户视图上下文和/或图的请求305。在一些实施例中，表402表示由图2的用户视图上下文模块222所使用的数据结构和/或图3的用户意图理解服务以用于确定或预测用户意图。在一些实施例中，表400和/或402表示或者包括特定数据结构。例如，表402可以表示查找表或者散列映射，其中，键是实例ID，并且值是“初始化值”。以这种方式，例如，能够通过将来自表400的实例ID键与表402中的实例ID键进行匹配来定位表402内的特定条目或记录。

表400表示用户视图上下文，并且包括实例ID属性、实例字段和值属性以及话语数据属性。实例ID属性指示用户视图上下文的实例的身份。例如，客户端应用可以包括工作流或者特定页面或活动，其中的每个能够取决于工作流(例如，页面被钻取到的顺序)以连续的数字来识别。在说明性示例中，主页或登陆页面能够被识别为实例ID 1，并且从主页或登陆页面导出的子页面能够被识别为实例ID 4，并且由于用户当前具有打开的实例ID 4，因此其被填充在表400的实例ID属性下方。

实例字段和值属性指示针对对应实例的每个字段以及每个字段的已填充值。例如，表400指示对于实例ID 4，存在“会议出席者”、“日期”、“时间”、“位置”和“描述”字段，其中，针对会议出席者的值是“John Doe”，针对“日期”的值是“2021年3月16日”，并且针对时间字段的值是“3-3:30”。每个填充的字段都指示用户已经填充了这些字段，或者这些字段已经由客户端应用自动地填充。在所图示的示例中，针对“位置”和“描述”字段的值为零(null)或空(例如，用户尚未对其填充)。因此，表400指示实例ID 4当前示出已经将会议设置为2021年3月16日的3-3:30，并且在所述字段中已经有一名出席者—John Doe。“话语数据”字段指示确切的语音话语是什么(例如，由语音话语检测器206检测到的)。话语数据字段具体指示所述话语是“添加他的经理”，这可以指示用户意图或客户端请求以将Jane Doe作为即将到来的会议的会议参与者填充到“会议出席者”字段，因为她是“他的”(即，JohnDoe的)经理。

表402表示用于确定或者预测用户意图的数据结构，并且包括实例ID属性和初始化值属性。表402的实例ID属性也识别实例ID，这些实例ID可以是或者可以不是用户视图上下文的一部分。换言之，在实施例中，表402可以表示作为客户端应用(和/或其他应用)的一部分的预定实例集，并且一些字段(例如，在初始化值中所指示的)最初包含空值或零值，因为其尚未接收到用户已经填充的值的指示。以这种方式，例如，用户视图上下文模块222具有关于在客户端应用中包含哪些实例以及属于每个实例的字段的预定信息，从而能够利用表400中所包含的值快速地填充字段。例如，响应于接收到表400，用户视图上下文模块222可以使用实例ID 4在表402处执行查找功能。响应于在表402处定位实例ID 4，用户视图上下文模块222能够填充或初始化对应的字段，如在表400的“字段和值”属性中所指示的。例如，表402内的“会议出席者”、“日期”和“时间”字段能够被填充相应的“John Doe”、“2021年3月16日”和“3-3:30”值。

尽管表402指示能够预定实例信息，但是应当理解，在一些实施例中，一个或多个实例不是预定的。例如，用户视图上下文能够包括打开的窗口、web浏览器或者能在屏幕上查看但是不是对应于表402的实例ID字段的客户端应用的一部分的其他客户端应用。在这些实施例中，表404可以额外地补充有或者表示复制或接收表400中所指示的一些或全部数据(包括字段)而不预先填充或预定任何实例或字段的任何数据结构。

图4B是根据一些实施例图示了如何至少部分地基于用户视图上下文来执行语音话语的示意图。在一些实施例中，表404表示图3的消息319和/或由图2的上下文理解模块218执行的功能。在一些实施例中，表406表示由用户意图-视图映射器210所使用的数据结构，用于通过根据语音话语或用户意图填充特定实例来执行语音话语。在一些实施例中，在图4B中所指示的功能和结构遵循在图4A中所指示的功能和结构。在一些实施例中，表404和/或406表示或者包括特定数据结构。例如，表406可以表示查找表或散列映射，其中，键是实例ID，并且值是“用户视图字段和值”属性。以这种方式，例如，能够通过将来自表404的实例ID键与表406中的实例ID键相匹配来定位表406中的特定条目或记录。

表404包括实例ID属性、客户端动作请求属性和结果有效载荷属性。实例ID属性指示需要对其执行客户端操作请求和结果有效负荷的实例的身份。客户端动作请求属性指示基于确定用户意图而对客户端应用执行一个或多个特定动作的命令。具体而言，如在表404中所指示的客户端动作请求是填充实例ID 4的“会议出席者”字段。“结果有效载荷”属性指示基于客户端动作请求和所确定或预测的用户意图而返回给客户端应用的特定值。具体而言，结果有效载荷是“Jane Doe”。因此，表404可以表示给客户端应用的消息或控制信号，以请求客户端应用在实例4处利用Jane Doe的结果有效载荷来填充会议出席者字段。

如上文关于图4A所描述的，所述话音数据请求可以是“添加他的经理”，其中，用户当前正查看实例ID4，其包括姓名“John Doe”。因此，上下文理解模块218能够确定，因为用户已经在实例ID4的“会议出席者”字段内填充了“John Doe”，并且其当前在用户的屏幕上，所以“他的”意图必须表示“John Doe”，而词语“添加”必须指代在John Doe的经理—JaneDoe来填充“会议出席者”字段的用户意图(例如，如经由网络图所确定的)。

表404内的信息被传递(例如，由上下文理解模块218)到客户端应用的用户设备，然后该用户设备响应地通过基于在表404中所指示的客户端动作请求和结果有效负荷利用“Jane Doe”值填充“会议出席者”字段来填充表406。响应于该填充，客户端应用自动视觉渲染(例如，在用户界面内)具有在实例ID 4中所指示的对应的“会议出席者”字段的“JaneDoe”值。因此，至少部分地响应于当实例ID 4被显示到用户的屏幕上时用户发出“添加他的经理”的语音话语请求，“Jane Doe”能够自动地被填充在对应的“会议出席者”字段中以执行用户的语音话语请求，这指示Jane Doe已经经由已经显示在用户屏幕上的特定字段被添加到会议中。

图5是根据一些实施例的示例性网络图500的示意图。在一些实施例中，网络图500是由上下文理解模块218用于帮助确定用户意图和/或实体识别模块214用于确定实体的结构。例如，在实施例中，网络图500包括图数据库，其可以被存储在包括单个数据库位置或分布式存储(例如，存储在云中)的存储设备225(图2)中。替代地或另外地，可以利用其他数据仓库或数据结构，诸如关于特定用户的信息的用户简档(例如，姓名、联系信息、(一个或多个)经理、组织图、职责或许可，或者关于用户的类似信息)，或者针对用户的数据的数据库(例如，用户的文件、电子邮件、会议、日历、用户活动历史、位置数据，或者关于用户的类似信息，可能要求用户同意的存储设备)。网络图是对象集合的图形表示或可视化，其中，一对对象通过链接或者“边”来连接。相互连接的对象由被称为“顶点”的点表示，并且连接顶点的链接被称为“边”。每个节点或顶点表示在一维、二维、三维(或者任何其他维度)空间中的特定位置。顶点是一条或多条边相交的点。边连接两个顶点。具体而言，网络图500(无向图)包括以下节点或顶点：502(表示John Doe)、504(表示Jane Doe)、506(表示应用A)、508(表示John Smith)和节点510(表示应用Y)。网络图500还包括边I、H、J-1、J-2和G-1、G-2、G-3、G-4。

网络图500具体而言示出了各种用户与应用之间的关系，诸如客户端应用。可以理解的是，这些节点仅仅是代表性的。这样，计算机资源可以替代地或另外地是用户已经填充的日历、用户所属的组、用户已经参与的聊天会话、用户已经发送或接收的文本消息等。在一些实施例中，边表示或者例示说明例如与特定应用的特定用户交互(例如，下载、共享、保存、修改或者任何其他读/写操作)和/或业务单元中的用户之间的关系。

将计算机资源表示为顶点允许用户以其他方式进行链接。例如，应用Y可以表示在组成员之间交换电子消息的组容器(例如，MICROSOFT TEAMS)。因此，网络图500可以例示说明哪些用户是同一组的成员。在另一说明性示例中，网络图500可以指示John Doe在第一次(由边J-l表示)下载应用A，并且在第二次(由边J-2表示)打开应用A。图500也可以图示出John Smith也下载了应用Y或者与应用Y交互，如由边I所表示的。在一些实施例中，边的数量表示两个节点之间的关系的强度。例如，G-1、G-2、G-3和G-4表示John Doe与Jane Doe之间的关系比应用A对John Doe更强，因为例如John Doe可以比应用A更多地与Jane Doe交互。替代地，在一些实施例中，单个边的粗细度指示关系强度的程度。例如，替代指示节点502和504之间的4条边，在这些节点之间可以存在比任何其他边更粗的单线，指示最强的关系。

总之，网络图500指示John Doe的经理是Jane Doe，John Doe已经与应用A交互了几次，John Smith是John Doe的团队或业务单元的成员，以及John Smith已经与应用Y交互。因此，网络图500提供了例如John Doe的最紧密连接的上下文，以便确定用户意图。例如，为了执行说“添加John Doe的经理”的语音话语，一些实施例在节点506处开始(因为John Doe在语音话语中被直接引用)，并且然后响应地“遍历”网络图500以在节点504处定位“经理”值。响应地，特定实施例然后读取经理值，其为“Jane Doe”，并且返回这样的值(例如，如在图4B的表404的结果有效载荷属性中所指示的)。在另一示例中，语音话语可以是“将John添加到会议中”。如果John Doe发出语音话语(例如，如由GMM或者其他语音检测组件检测到的)，响应地，实施例能够在节点502处开始，并且然后遍历网络图500，直到其找到“John Smith”，其可以是John Doe的阈值距离内的唯一John。因此，实施例能够基于网络图500内的信息来确定用户意图是利用John Smith的电子邮件来填充会议受邀者字段。

在各种实施例中，网络图500被用于确定用户意图，诸如确定语音话语指代的是谁或者是什么的最可能的候选(例如，当用户在语音话语中说“他的”或“她的”时，最可能的候选是特定的名称)。在一些实施例中，例如，通过选择被邀请到会议的每个人以及其N个最紧密的连接(例如，在特定距离阈值内的3个用户)来执行候选选择。在各种实施例中，基于使用网络图中的距离来确定紧密度。在一些实施例中，就网络图而言，“距离”对应于顶点U与顶点V之间的最短路径中的若干条边(或者边集)。在一些实施例中，如果存在连接两个顶点的多极路径，则最短路径被认为是在两个顶点之间的距离。因此，距离能够被定义为d(U,V)。例如，在节点502与节点506之间的距离是1(例如，因为在这些节点之间仅有1个边集J)，而节点502与节点510之间的距离是2(例如，因为在这些节点之间有两个不同的边集H和I)。

在一些实施例中，替代地仅基于距离来选择特定候选，而不管连接的实际数量(因此不是基于“N”个连接，如上文所描述的)。例如，一个或多个网络图规则可以指定选择位于节点502的距离4处或者在节点502的距离4内的所有顶点或用户作为候选。在这些实施例中，所有这些节点都将是被选择的候选，因为其位于到节点502的距离处或者在到节点502的距离内。

一些实施例通过选择交互最多的前N个节点(例如，如由顶点之间的边数所确定的)来另外地或替代地选择特定候选。一些实施例通过选择离网络图500中的至少一部分用户的“形心”最近的N个用户来替代地或另外地选择特定候选。在一些实施例中，“形心”指代的是对象集合的几何中心(例如，网络图500中的节点的平均位置)。

用于确定用户意图的每个候选能够基于在语音话语和/或诸如用户视图上下文的其他上下文中引用的内容而被额外地向下过滤到单个用户或者其他对象。例如，如果网络图500内的每个节点由于处在John Doe的阈值距离内而被选择作为针对用户意图的候选，则可以发生额外处理，诸如比较语音话语中的名称“他的”。因此，John Smith能够与“他的”在语义上更加相似(例如，经由WORD2VEC或BERT模型中的欧几里得或余弦距离)，因为最接近该阳性代词的最接近的特征向量是John Smith(相对于表示Jane Doe或者其他应用对象的特征向量)。

图6A描绘了根据一些实施例的与语音话语606相关的用户界面的示例性截屏602。在一些实施例中，截屏602表示导致经由呈现模块224显示的内容和/或作为图2的消费者应用204的一部分的内容。例如，在第一次，用户604发出包括“向Jaclyn发送我将迟到的聊天消息”的语音话语606。在一些实施例中，响应于接收到用户已经选择了按键通话麦克风按钮607的指示，被嵌入到对应应用中的音频API启用，以便拾取用户话语的音频。随后，用户发出语音话语606。替代地，在一些实施例中，用户604能够发出唤醒词语音话语以便触发音频API。

在一些实施例中，响应于对语音话语606的这种检测，在本文中所描述的各种组件执行其功能以便执行语音话语606。例如，响应于检测到语音话语606，用户视图上下文信息提取器208能够提取截屏602的一些或全部信息，例如，“日历”文本、“3月15日文本”、截屏602的实例ID，以及额外元数据，诸如实例ID所属的特定应用(例如，MICROSOFT TEAMS)ID，或者在该会话中可能最近被呈现给用户或者由用户交互的其他应用页面，如在本文中所描述的。响应地，消费者应用204能够编码语音话语606并且将其传送给语音识别模块212，以及将用户视图上下文(例如，被包含在截屏602中的信息)传送给上下文理解模块218，以便识别或理解语音话语606的语音并且确定或推断用户意图。基于检测到语音，在一些实施例中，标记609被提供给截屏602。基于确定、检测或者预测用户604的用户意图，特定实施例导致图6B内的截屏608和对应信息的显示。

图6B描绘了用户界面的示例性截屏608，提供所述用户界面是为了执行图6A的语音话语606。在一些实施例中，截屏608和602是作为单个消费者应用204(例如，被存储到单个用户设备(或者在单个用户设备上操作)的通信或电子会议应用)的一部分的移动页面或活动。例如，在示例性会话中，用户可以在消费者应用204的日历视图(例如，截屏602)内开始，并且基于执行或处理语音话语606，用户可以自动地被导航到消费者应用204的消息传递或电子邮件视图(例如，截屏608)。(尽管截屏608描绘了聊天消息传递视图，但是具有在诸如MICROSOFT OUTLOOK之类的通信应用内的截屏602和608的另一实施例(未示出)可以代替地将电子邮件视图描绘为截屏608。)以类似的方式，在本文中所描述的语音助手技术的一些实施例能够识别和促进与消费者应用204的不同模式的用户交互，诸如从发送电子邮件任务中的类似“识别收件人”的活动转换到撰写电子邮件正文任务的类似“听写”的动作。在其他实施例中，截屏608和602来自单独的应用，并且通过允许用户利用第二应用(例如，截屏608的应用)来完成在第一应用(例如，截屏602的应用)内发起的任务来演示跨应用(或者跨域)功能，如在本文中进一步描述的。例如，这样的功能允许用户经由MICROSOFT TEAMS(即，第二应用)从MICROSOFT OUTLOOK日历(即，第一应用)发送消息，如下文所描述的。

如在图6B中所图示的，响应于处理语音话语606，在字段610中自动地填充消息“我将迟到”。因此，在一些实施例中，执行语音话语606(或者由上下文理解模块218处理语音话语606，如在本文中所描述的)导致截屏602自动改变到截屏608，其可以是相同的应用，并且还基于确定或预测用户意图来自动地导致填充字段610。例如，返回参考图4B，一些实施例能够接收类似于表404的表，指示实例606(其具有特定ID)是特定电子会议应用的一部分。一些实施例(例如，上下文理解模块218)还能够映射语音话语606中的词语“聊天消息”与位于表406中的另一实例ID(例如，单独的聊天页面608)(例如，经由在表406中所指示的“聊天消息”与实例ID的名称之间的阈值内的特征向量距离)，并且另外地将结果有效载荷值(即，“我将迟到”)映射到特定字段610，因为这是用户在聊天截屏608中发送消息的方式。一些实施例还能够将词语Jaclyn(例如，经由在本文中所描述的网络图500)映射到特定的人“Jaclyn Smith”。因此，至少部分地基于这种组合信息的一些或全部，一些实施例能够预测用户意图是将页面从页面602改变到608(聊天页面)，并且利用结果有效载荷来填充字段610。

在本文中所描述的语音助手技术的一些实施例提供了用户能够通过其完成任务的灵活模态。例如，在一些实施例中，用户能够修改(例如，添加、删除或补充)对字段的这些自动填充，或者以其他方式手动地提供除了提供语音话语之外或者替代提供语音话语的输入。例如，在示例性截屏6B和7A至7H中，用户也可以手动地操作用户界面以添加会议出席者(或者移除自动提供的会议出席者)、改变会议时间、修改消息等。在这些实施例中，语音助手功能对用户所做的这些改变具有实时(或者接近实时)的可见性，并且随后能够经由用户语音命令促进进一步的动作。例如，用户能够手动地将会议出席者输入到页面上的字段中。实施例能够基于这些修改来确定用户视图上下文，诸如在页面处手动输入的会议出席者，并且随后执行语音话语，如在本文中所描述的。

在一些情况下，这些不同的模态是冲突的，或者是同时输入的。特定实施例并入了新规则来处理如在本文中所描述的这些情况。例如，用户604能够另外地或替代地在字段610处执行手动用户输入，诸如键入字符串“我应该准时”，这是冲突的输入。在这些实施例中，如关于图2所描述的组件，诸如关于请求类型确定模块226、打断模块228和/或初始请求处理模块230所描述的那些组件，能够执行其功能。例如，这样的手动用户输入请求可以被认为是“打断”请求，或者仅仅是用户已经参与手动用户输入的指示。因此，由于这样的手动用户输入是在对话期间或者相对于语音话语606在较晚的时间接收到的(或者完全接收到的)，所以特定实施例避免响应或者执行语音话语606，而是响应或者执行手动用户输入，使得显示字符串“我应该准时”而不是“我将迟到”。换言之，取消向Jaclyn发送聊天消息的语音话语请求，以允许用户执行他们自己的手动用户输入。

如上文所描述的，在一些实施例中，图6B表示语音助手功能能够支持跨应用或跨域场景的功能。例如，图6A可以表示日历应用的日历页面，而图6B可以表示完全不同的电子会议应用的聊天页面。例如，这些实施例能够允许用户从MICROSOFT OUTLOOK进行MICROSOFT TEAMS呼叫或聊天会话，或者类似地，向会议邀请上列出的一组出席者发送电子邮件(其可以利用第二应用来执行)(其可以经由第一应用或者第二应用的第二实例提供给用户)。

在一些实施例中，响应于接收到用户604已经选择发送按钮612(或者发出语音命令以“发送它”等)的指示，实施例随后使得聊天消息“我将迟到”显示在聊天消息614的下面。替代地，一些实施例自动地使得聊天消息“我将迟到”被发送并且显示在聊天消息614的下方(即，不需要用户已经选择按钮612的任何指示)。

图7A描绘了根据一些实施例的与语音话语704相关的用户界面的示例性截屏700。在一些实施例中，截屏700表示导致经由呈现模块226显示的内容和/或作为图2的消费者应用204的一部分的内容。例如，在第一次，用户702发出语音话语704“安排明天下午3:00与Jaclyn的会议”。在一些实施例中，响应于接收到用户已经选择了按键通话麦克风按钮706的指示，启用被嵌入到对应应用中的音频API以便拾取音频。随后，用户发出语音话语704。替代地，在一些实施例中，用户702能够发出唤醒词语音话语以便触发音频API。

在一些实施例中，响应于对语音话语704的该检测，在本文中所描述的各种组件执行其功能以便执行语音话语04。例如，响应于检测到语音话语704，用户视图上下文信息提取器208能够提取截屏700处的所有信息(例如，“3月15日”日期和所有时隙信息和时间可用性)。响应地，消费者应用204能够编码语音话语704并且将其传输到语音识别模块212，以及将用户视图上下文(例如，被包括在截屏700中的信息)传输到上下文理解模块218，以便识别语音并且确定或预测用户意图。并且基于确定、检测或预测用户702的用户意图，特定实施例导致显示截屏708和图7B内的对应信息。

图7B描绘了用户界面的示例性截屏708，提供所述用户界面是为了执行图7A的语音话语704。在一些实施例中，自动地确定和显示会议的标题、会议的描述或者其他会议信息(例如，基于用户意图和/或用户视图上下文，诸如在截屏708上所指示的会议出席者)。在一些实施例中，截屏700和708是作为被存储到单个用户设备的日历或电子邮件应用的一部分的移动页面或活动。如在图7B中所图示的，将“Jaclyn Smith”的额外信息填充到字段708-1，并且将时间信息存储到字段708-2(包括“3月16日”日期)，以便执行图7A的语音话语704。字段708-1可以指示会议出席者字段，其中，用户能够指定被邀请到会议的会议出席者。因此，诸如上下文理解模块218的一些实施例使得截屏700自动地改变为相同应用的截屏708，并且进一步自动地使得填充字段708-2和708-1。例如，返回参考图4B，实施例能够接收类似于表404的表，指示实例700(其具有特定ID)是特定日历应用的一部分。实施例(例如，上下文理解模块218)还能够映射语音话语708中的词语“安排会议”与位于表406中的另一实例ID(例如，单独的会议安排页面)(例如，经由在“安排会议”与作为“会议安排页面”的实例ID的名称之间的阈值内的特征向量距离)，并且另外地基于读为“3月15日”的用户视图上下文将语音话语704中的词语“明天”映射到3月16日。实施例也能够基于截屏700的用户视图上下文和/或其他用户可用性信息来确保下午3:00确实为会议开放。至少部分地基于该组合信息中的一些或全部，实施例能够预测用户意图是从页面700改变到页面708，并且响应地利用对应的信息来填充字段708-1和708-2，并且然后自动地填充这些字段。

在一些实施例中，响应于接收到用户702已经选择“预订”按钮708-3的指示(或者发出类似或对应的语音命令)，各种实施例最终安排会议。相反，响应于接收到用户已经选择“取消”按钮708-4(或者发出相似或对应的语音命令)的指示，各种实施例自动地从字段708-1和708-2中擦除数据和/或自动地使得用户返回到图7A的页面700。在这些实施例中，关于图2描述的组件，诸如关于请求类型确定模块226、打断模块228和/或初始请求处理模块230所描述的那些组件，能够执行其功能。例如，这样的手动用户输入请求可以被认为是“打断”请求，或者仅仅是用户已经参与手动用户输入的指示。因此，由于这样的手动用户输入是在对话期间或者在相对于语音话语703的较晚时间接收的(或者完全接收的)，因此特定实施例避免响应或者执行语音话语703，而是响应或者执行取消按钮708-4的手动用户输入，以便避免响应语音话语703。

图7C描绘了根据一些实施例的图7B的截屏708，除了用户702已经发出额外语音话语703。用户702可能希望邀请额外的人员到在图7B处用户安排的相同会议。因此，用户可以发出声明“添加Diego”的语音话语703。如在本文中所描述的，各种实施例随后能够检测语音话语703，从页面708提取用户视图上下文，执行语音识别并且确定用户意图，以便填充图7D的字段708-5。例如，上下文理解模块218能够将词语“添加”映射到具有值“Diego”的“填充字段708-5”的动作，因为Diego在语音话语703中被指示。这样的映射能够基于刚刚被填充的字段708-1和页面708上的词语“Jaclyn Smith”。例如，实施例能够遍历Jaclyn Smith的网络图，并且这里最近的连接能够是“Diego Garcia”。以这种方式，实施例知道语音话语703指代是哪个Diego，并且也能够响应地确定Diego Garcia的电子邮件地址，以便邀请Diego到会议。在一些实施例中，能够确定、更新或显示会议的标题、会议的描述或者其他会议信息(例如，基于诸如从新会议出席者指示的新用户意图和/或用户视图上下文)。

图7E描绘了根据一些实施例的图7D的截屏708，除了用户702已经发出了额外语音话语705。用户702可能希望邀请额外的人员到在图7B处用户安排的相同会议。因此，用户可以发出声明“也包括他的经理”的语音话语705。如在本文中所描述的，各种实施例随后能够检测语音话语705，从页面708提取用户视图上下文，执行语音识别并且确定用户意图，以便填充图7F的字段708-6。例如，上下文理解模块218能够将词语“包括”映射到“填充字段708-6”的动作，并且映射词语“他的”与“Diego Garcia”的值，因为Diego被包含在最近的命令中并且在图7E的用户视图上下文中被指示。这样的映射能够基于刚刚被填充的字段708-5。另外，特定实施例将词语“经理”映射到“Patricia Johnson”。例如，实施例能够遍历DiegoGarcia的网络图，并且他的被标记为“经理”的最近连接或节点能够是“PatriciaJohnson”。以这种方式，实施例确定Diego Garcia的经理是谁，并且也能够响应地确定Patricia Johnson的电子邮件地址以便邀请她到会议。

图7G描绘了根据一些实施例的图7F的截屏708，除了用户702已经发出额外语音话语707之外。用户702可能希望改变在图7B中用户安排的会议时间。因此，用户可以发出声明“将其移动到周三下午4:00”的语音话语707。如在本文中所描述的，各种实施例随后能够检测语音话语707，从页面708提取用户视图上下文，执行语音识别并且确定用户意图，以便填充图7H的字段708-7。例如，上下文理解模块218能够将语音话语707中的词语“将其移动”映射到以新的时间改变或填充字段708-7，因为用户当前已经打开图7G的页面708。另外，实施例能够基于当前在页面708上打开的读为“周二，3月16日”的页面708来将词语“周三”映射到下一天—周三，3月17日。换言之，用户意图能够是停留在相同的页面708上，并且基于语音话语707和图7G的页面708的用户视图上下文中所包含的数据，将会议时间改变到字段708-1处的周三，3月17日。

现在转向图8和图9，对于本公开的实施例，示例性地描绘了示例性过程800和900的各方面。过程800和900各自可以包括方法(有时在本文被称为方法800和方法900)，其可以被执行以实现在本文中所描述的许多示例性实施例。参考图8，根据一些实施例，示例性过程800提供了用于通过填充客户端应用的特定实例来执行用户的语音命令的方法。过程800(和/或在本文中所描述的任何功能(例如，示例性过程900))可以通过包括硬件(例如，电路、专用逻辑、可编程逻辑、微码等)、软件(例如，在处理器上运行以执行硬件模拟的指令)、固件或者其组合的处理逻辑来执行。尽管在本公开中所描述的特定框以特定的顺序以特定的数量被引用，但是应当理解，任何框可以与任何其他框基本平行或者在任何其他框之前或之后出现。此外，可能存在比所示的更多(或更少)的框。这样添加的框可以包括体现在本文中所描述的任何功能的框。如在本文中所描述的计算机实现的方法、系统(其包括具有至少一个处理器和至少一个计算机可读存储介质的至少一个计算设备)和/或计算机程序产品可以执行或者导致执行过程800和/或900或者在本文中所描述的任何其他功能。

在一些实施例中，过程800由用户设备(例如，图1的用户设备102a)或消费者应用(例如，图2的消费者应用204)来执行。在框802处，过程800渲染(例如，显示)客户端应用的第一实例。例如，返回参考图7A，客户端应用能够渲染截屏700。在框804处，过程800的特定实施例检测用户的用户动作。在一些实施例中，这样的用户动作包括手动用户计算机输入，诸如点击按钮(例如，如由图7A的按钮706所图示的按键通话按钮)。替代地，在一些实施例中，这样的用户动作是语音话语，诸如“唤醒词”。

在框806处，一些实施例发起对音频数据的记录。例如，响应于在框804处执行的检测操作，一些实施例触发被配置为记录音频数据的组件。结合图2中的语音话语检测器206提供框806的实施例的额外示例和细节(例如，启用音频API以收听音频或语音话语)。在框808处，一些实施例接收用户的语音话语。例如，返回参考图7A，客户端应用能够接收语音话语704。一些实施例额外地至少部分地基于对组件的触发对第一语音话语进行编码，如例如关于图2的语音话语检测器206所描述的。

在框810处，示例性过程800的实施例至少部分地基于第一实例的渲染和语音话语的接收来提取用户视图上下文。结合图2中的用户视图上下文信息提取器208提供了可以在框810处执行的操作的额外示例性实施例。在框812处，示例性过程800的实施例至少部分地基于用户视图上下文和语音话语来确定用户意图。在一些实施例中，框812包括(例如，由客户端303)传送或传输或引起传输用户视图上下文和语音话语(例如，到中间服务307、语音识别服务313和/或用户意图理解服务317)，以便确定用户意图。结合图2和图3描述可以在框812处执行的操作的示例性实施例。例如，参考图2，托管消费者应用204(即，客户端应用)的用户设备能够将用户视图上下文和检测到的语音话语传输给语音识别模块212和上下文理解模块218，以便确定语音话语的意图。

在框814处，至少部分地基于用户意图(和/或在框812处的传输)，一些实施例通过利用数据自动地填充第一实例或第二实例来执行语音话语。参考图6A至图7H描述可以在框814处执行的操作的示例性实施例，其中，可以向用户渲染特定页面并且填充特定值字段。

现在转向图9，根据本公开的一些实施例，提供了图示出用于通过确定用户意图使得客户端应用执行语音话语的示例性过程900的流程图。在一些实施例中，过程900由图2的上下文理解模块218来执行。在框903处，示例性过程900的实施例接收与客户端应用的第一实例相关联的话语数据和用户视图上下文。结合图2的上下文理解模块218和图3的用户意图理解服务317进一步描述可以在框903处执行的操作的示例性实施例。在一些实施例中，“话语数据”能够是在消息315(图3)中所指示的语音到文本数据。此外，用户视图上下文可以包括来自与用户相关联的客户端应用(例如，其在用户设备上打开)的第一实例的数据。

在框905处，过程900的实施例确定来自用户的语音话语的用户意图。所述确定可以至少部分地基于话语数据和用户视图上下文。结合图2和图6A至图7H的用户视图上下文模块222进一步描述在框905处执行的操作的示例性实施例。

在框907处，过程900的实施例使得客户端应用在第一实例或第二实例处自动地填充数据。在一些实施例中，在框907处执行的操作可以响应于从框905确定用户意图。对数据的填充能够至少部分地指示执行语音话语。关于图3或图6A至图7H(例如，图7B)的消息319进一步描述在框907处执行的操作的示例性实施例。在一些实施例中，框907(和/或图8的框814)还包括促进与不同应用模式的交互，例如，从发送电子邮件任务中的类似“识别收件人”的活动过渡到撰写电子邮件正文任务的类似“听写”的动作。

图10是图示了根据一些实施例的如何处理多模态请求的序列图。在一些实施例中，客户端1002表示或者包括关于图3的客户端303所描述的功能。另外，在一些实施例中，一个或多个服务器1003表示或者描述了关于图3的中间服务307、语音识别服务313和/或用户意图理解服务317的功能。

根据步骤1，客户端1002发送“最后看到的响应#1”标记以及语音话语请求的语音话语数据。如在本文中所描述的“最后看到的响应”指代表示客户端1002已经被处理(例如，执行或响应)的最后或最近的服务器响应或消息的ID。例如，如果客户端1002发送表示说“播放歌曲X”的用户请求的语音话语数据，则一个或多个服务器1003可以返回歌曲X，由此使得客户端1002播放歌曲X。响应地，客户端1002能够填充指示执行的最后或最近的服务器响应(即，“最后看到的响应”)的数据结构(例如，队列)。因此，下一次客户端1002发出第二请求时，如果客户端1002没有已经处理的其他服务器响应，则客户端1002能够向(一个或多个)服务器1003发送相同的最后看到的响应#1ID。

根据步骤2，在相同会话内(例如，在步骤1之后不久(例如，在3秒内))，客户端1002可以基于用户输入的手动用户界面以及相同的最后看到的响应ID#1发送额外UI输入请求，因为客户端1002尚未接收和处理来自(一个或多个)服务器1003的新响应。例如，用户可以通过触摸指示执行动作(例如，播放歌曲P)的请求的按钮来发出触摸手势请求。在一些实施例中，该新步骤2请求在相对于在步骤1处的语音话语请求的不同web套接字上生成或发送。以这种方式，能够跨不同的通信信道发送不同的用户输入，并且由相同的组件来处理。

根据步骤3，一个或多个服务器1003响应或者执行UI输入请求(例如，而不是语音话语数据请求)，以及传输响应ID#2。响应地，客户端1002响应或者执行UI输入，并且利用与由(一个或多个)服务器1003发送的“响应#2”消息相对应的“最后看到的响应#2”递增或填充数据结构。在说明性示例中，(一个或多个)服务器1003可以返回经由UI输入(例如，触摸手势)请求的歌曲P，并且在同一消息中包括响应#2ID，指示(一个或多个)服务器1003的特定响应的ID。响应地，客户端1002可以使得设备播放歌曲p(即，响应或者执行UI请求)，以及利用响应#2ID(即，最后看到的响应ID#2)递增队列数据结构，指示响应#2是客户端1102已经执行的最后的服务器响应。

在一些实施例中，客户端1002仅看到并且处理对最后请求的响应(例如，步骤2请求而不是步骤1请求)N。在一些实施例中，从请求1到N-1的所有(一个或多个)服务器1003响应被舍弃、取消和/或忽略。这是因为如果客户端1002没有忽略响应(例如，(一个或多个)服务器1003响应以执行步骤1的语音命令)，则后续请求的ID将改变。如果一个或多个服务器1003不响应请求N，则用户可能根本看不到任何响应。因此，在特定实施例中，一个或多个服务器1003总是响应请求N。在一些实例中，一个或多个服务器1003不能够知道给定请求n是否是请求N，直到队列中有针对相同请求ID的新请求n+1。在一些实施例中，n和n+1表示由客户端1002发送的请求序列，而不是由一个或多个服务器1003接收的请求序列。

图11是图示了根据一些实施例的如何经由回叫功能提交语音话语请求的序列图。在一些实施例中，客户端1102表示或者包括关于图10的客户端1102或图3的客户端303所描述的功能。另外，在一些实施例中，语音服务1103和/或代理1105表示或者包括关于图10的一个或多个服务器1003所描述的功能。在一些实施例中，语音服务1103表示或者包括关于语音识别服务313描述的功能。在一些实施例中，代理1105表示或者包括关于图3的用户意图理解服务317所描述的功能。

图11图示了仅语音交互和会话，其中，不允许用户基于客户端1102向语音服务传输回叫消息而做出额外的手动用户界面(即，“打断”请求)。各种实施例在提交到语音查询之前实现“回叫”消息，并且仅在成功回叫时提交到语音查询。在web套接字连接的整个生命周期中，客户端能够通过交换web套接字消息进行一个或多个请求(也被称为轮次)。根据步骤1107，客户端1102将语音话语编码为语音话语数据，以被传输到语音服务1103。根据步骤1109，语音服务1103识别语音话语数据并且发送对应的响应回叫(例如，图11中提到的“最后看到的响应”ID)。

根据步骤1111，客户端1102经由回叫操作来回叫语音服务1103。在图11中，用户没有打断或者以其他方式执行任何UI交互或手动用户输入。因此，客户端1102经由步骤1111发送“回叫”消息。响应于客户端在步骤1111发送回叫事件，客户端1102进入思考状态1113(例如，在用户已经参与用户动作(例如，唤醒词或麦克风激活)和语音话语命令之后处理请求)。在一些实施例中，当客户端1102进入到思考状态1113中时，通常不允许用户执行任何进一步的UI交互或手动用户输入。因此，代理1105通过响应回叫事件并且使得客户端1102执行语音话语来帮助执行语音话语请求。

在一些实施例中，图11和图12表示新的回叫功能。例如，这样的回叫功能能够通过一个或多个服务器1003使用以下算法在提交到语音查询或语音话语之前生成新响应来表示。如果特定请求导致沉默或不匹配，则返回空响应，这将防止UI锁定，并且当用户不经由语音交互时重新提示。如果响应结果是短语(例如，“您希望我设置什么提醒？”)，则一些实施例发送回叫动作，所述回叫动作具有嵌入在数据结构中的序列化结果，诸如在本文中所描述的cookie。在一些情况下，额外的回叫往返将给语音交互增加一些延时，但是不影响UI交互。

图12是图示了根据一些实施例的如何经由回叫功能来处理多模态请求的序列图。在一些实施例中，客户端1202表示或者包括关于图11和图10的客户端1102或1002或图3的客户端303所描述的功能。另外，在一些实施例中，语音服务1203和/或代理1205表示或者包括关于图10的一个或多个服务器1003所描述的功能。在一些实施例中，语音服务1203表示或者包括关于图3的语音识别服务313所描述的功能。在一些实施例中，代理1205表示或者包括关于图3的用户意图理解服务317所描述的功能。

图12图示了与额外的手动用户界面“打断”输入相结合的语音交互。各种实施例在提交到语音查询之前实现“回叫”消息，并且仅在成功回叫时提交到语音查询。客户端1302可以允许用户在任何点“打断”或者执行一些手动用户输入动作，直到回叫动作被处理。在一些实施例中，如果发出回叫动作，则客户端1202开始新事件请求(例如，“最后看到的响应”)并且从语音请求中舍弃所有响应(例如，来自图11的(一个或多个)服务器1103的“响应#2”)。

根据步骤1207，打开麦克风，并且客户端1202可以对用户的语音话语进行编码以发送到语音服务1203。根据步骤1209，客户端1202接收用户已经执行手动用户输入或者已经以其他方式与UI交互(例如，对触摸屏按钮进行触摸)的指示。根据步骤1211，客户端1212进入思考状态。响应于客户端1202发送对应于打断的UI事件(即，步骤1212)，所述UI事件有效地充当回叫事件，客户端1212能够进入思考状态1211。在一些实施例中，在思考状态1211中，可能不允许用户执行进一步的UI交互。换言之，客户端1202例如可以不将来自客户端的任何手动用户输入传输或处理到语音服务1205。

根据步骤1213，经由步骤1207来自请求1的消息被舍弃(例如，因为打断请求相对于语音话语请求在时间上来得更晚)。随后，代理1205接收事件并且提交对应于执行与步骤1209相关联的请求的响应，以便响应手动用户输入。

在一些实施例中，当客户端1202发起新请求时，其进入“思考状态”。在一些实施例中，客户端1202确保在思考状态中，用户不被允许打断(例如，利用手动用户输入，诸如触摸)，而是延迟发送这样的请求，如在本文中所描述的。一些实施例清楚地指示收听关闭(麦克风被停用)并且按钮被禁用或隐藏。在思考状态下执行的UI交互可能导致不可预测的体验。在一些实施例中，客户端1202在执行响应或处理错误时转换出思考状态。

图13是根据一些实施例的两个数据结构1302和1303的示意图，其图示了客户端和一个或多个服务器如何处理来自用户的不同类型的输入。在一些实施例中，数据结构1302表示客户端1002、1102和/或1202用于执行其功能的数据结构。类似地，在一些实施例中，数据结构1303表示一个或多个服务器1003、语音服务1103/1203、代理1105、中间服务307、语音识别服务313和/或用户意图理解服务317用于执行其各自功能的数据结构。

客户端应用能够允许用户灵活地提供多个输入，并且表现得就像总是接受最后的输入一样。例如，在一些实施例中，如果客户端应用的麦克风被启用并且用户开始打字，则客户端应用关闭或停用麦克风以允许用户打字，从而不拾取和处理冲突的音频或者其他音频。在一些实施例中，从用户开始新的输入模态(例如，手动用户输入或语音)的时刻起，客户端应用舍弃来自(一个或多个)服务器的与旧输入相关联的任何未来响应。为了采用客户端与服务器之间的这种无缝通信来仅处理最后的输入，各种实施例采用数据结构1302和1303。

在一些实施例中，客户端应用存储或采用存储“最后看到的响应ID”的数据结构1302(例如，队列)。在特定实施例中，由客户端从一个或多个服务器接收的每个服务器响应或每个消息包含独有的“响应ID”(例如，数据结构1303的“响应ID”)，在本文也被称为“事件ID”。如果客户端处理服务器响应(例如，改变客户端应用页面或者利用值填充字段)，则客户端将利用该值更新“最后看到的响应ID”。在说明性示例中，用户可以发出语音话语来设置提醒。服务器可以响应地确定用户意图并且发送服务器响应以“利用带孩子去看足球比赛的提醒来填充字段X”(ID 1)。响应地，客户端应用可以通过利用带孩子去看足球比赛的提醒填充字段X来处理或响应这样的服务器响应。这样的处理触发客户端以利用例如ID l填充或递增数据结构1302(例如，匹配服务器响应ID)，因为客户端已经完成处理或执行服务器响应。

在一些实施例中，每个客户端请求(例如，语音话语或手动用户输入)包括“最后看到的响应ID”。例如，使用上文的例示说明，在客户端应用利用提醒填充字段X并且利用ID 1填充数据结构之后，客户端应用可以在相同的会话中接收另一用户输入，诸如指示设置提醒以带孩子们去棒球比赛(而不是足球比赛)的手动用户输入。响应地，客户端应用能够将该输入的指示以及服务器响应ID 1(即，“最后看到的响应”)传输给一个或多个服务器。

在一些实施例中，数据结构1302表示由客户端应用更新并且由一个或多个服务器使用的cookie。例如，服务器可以对每个响应生成独有的ID(即，“响应ID”)。在一些实施例中，当生成客户端响应时，一个或多个服务器附加“setCookie”动作，所述动作指示客户端在本地(例如，在数据结构1302内)存储服务器的响应ID。在一些实施例中，客户端将仅在处理响应时评估“setCookie”动作。在下一客户端请求时，一个或多个服务器可以检查客户端的cookie。

在一些实施例中，一个或多个服务器使用数据结构1302(例如，散列映射或查找表)以便将响应ID、会话状态和高速缓存的响应映射到彼此。在一些实施例中，数据结构1302表示多个数据结构。例如，第一数据结构能够将“响应ID”映射到“会话状态”，而第二数据结构能够将“响应ID”映射到“高速缓存的响应”。

在一些实施例中，一个或多个服务器存储或采用单个会话状态的多个版本。如在本文中所描述的“会话状态”指代与整个对话或会话的一部分相对应的时间点或事件。例如，会话状态能够对应于特定的服务器响应(例如，“响应ID”)，所述服务器响应已经由服务器响应于客户端请求而被传输，如下文更详细描述的。在该上下文中的“对话”或“会话”可以在客户端应用或语音助手识别语音话语或手动用户输入时开始，并且以客户端应用响应或者执行这样的语音话语或用户输入而结束。在一些实施例中，单个对话或会话的确定能够基于用户的输入之间的时间阈值。例如，如果用户通过发出语音话语“打开灯”来参与对话，但是在X秒内(例如，1、2或3秒)没有与UI交互，则UI交互可以被认为是单独的会话或对话。

另外地或替代地，在一些实施例中，单个对话或会话的确定能够基于输入之间的事件或者最后参与的输入类型。例如，如果用户发出“设置提醒”的语音话语，则一个或多个服务器不确定需要提醒用户哪些提醒。因此，由于这种不确定性，对话或会话可以继续，并且(一个或多个)服务器可以通过使得在UI处显示潜在提醒的列表来进行响应，在这一点上用户可以做出对应的选择。这样的对话或会话可以继续，直到一个或多个服务器处理并且引起对该请求的响应。

代替单个会话，一些实施例存储或采用“响应ID”到“会话状态”的映射，如在数据结构1303中所图示的。在一些实施例中，响应于接收客户端请求，一个或多个服务器加载对应于请求的“最后看到的响应”ID值的会话状态。例如，使用上文的例示说明，当服务器接收到设置提醒以带孩子去棒球比赛(而不是足球比赛，如用户最初所说)的UI请求时，一个或多个服务器加载对应于“最后看到的响应”ID 1的会话状态A，如由图13的箭头1305所指示的。以这种方式，一个或多个服务器将把会话状态回滚到过去的状态，并且让新的传入请求(例如，设置提醒带孩子去看棒球比赛的请求)再次通过其播放(例如，更新到被建模为图的会话状态，并且回滚到图中的先前节点，如下文更详细描述的)。这也允许客户端舍弃来自服务器的与旧输入或请求相关联的任何响应(例如，设置提醒带孩子去看足球的请求)。

如关于请求类型确定模块226和初始请求处理模块230所描述的，一些实施例确定请求是交易类型或者是特定类型的。一些实施例(诸如技能服务)经由标志通知一个或多个服务器请求类型是交易型，诸如购买物品。响应地，在一些实施例中，当会话转向基于确定类型是交易来创建交易轮次时，除了将响应发送到客户端之外，还高速缓存所述响应。例如，这在表1303中被图示出，其中，在“高速缓存的响应”属性下方有“是”标志，其指示对应于响应ID 2的响应已经被高速缓存。因此，如果将来的请求包含相同的响应ID，则一个或多个服务器将利用高速缓存的响应进行答复，而不是处理所述请求。这是因为特定操作(诸如向零售商转账的交易)可能是不可撤销的，并且因此响应最后的响应是徒劳的，发送第一高速缓存的响应更合适。以这种方式，在特定实施例中，第一客户端请求获胜，这与打断请求相反，如在本文中所描述的。

图14是根据一些实施例的用于回滚会话状态的示例性图数据结构1400的示意图。在一些实施例中，图结构1400表示被包含在数据结构1303中的数据，并且替代地或另外地被使用。如在本文中所描述的，特定实施例将会话状态回滚到过去状态，并且让新请求被执行。这由图结构1400(例如，无向图)建模，图结构1400能够双向地遍历图结构1400的不同节点和边，以便添加到或者回滚到表示会话状态的节点。

在一些实施例中，响应于接收到请求类型是交易或另一类型的信号或指示(例如，来自请求类型确定模块226)，特定实施例(例如，一个或多个服务器1003)将会话状态回滚到过去状态(图中的较早节点)，并且让新请求在该状态中播放。例如，关于图结构1400，对应于会话状态A的节点1402可以表示第一时间会话状态，对应于会话状态B的节点1408可以表示第二时间会话状态(在会话状态A之后)，以及对应于会话状态的节点1410可以表示第三时间会话状态(在会话状态B之后)。因此，例如，在对会话状态C与会话状态B之间的回滚进行建模可以包括经由边1409从节点1410遍历节点1408。

在一些实施例中，存在连接到表示会话状态的节点的其他边和节点，如由节点1404和1406所图示的。这样的节点能够表示与会话状态相关联的额外信息，诸如响应ID(例如，节点1404)和对应的响应是否被高速缓存(例如，节点1406)，如关于图13所描述的。以这种方式，特定实施例能够将会话状态映射到对应的响应ID和其是否已经被高速缓存以响应回客户端的指示。

图15是示出根据一些实施例的如何从用户角度处理多模态输入的示意图。图15具体图示了当用户发出语音话语但是随后执行冲突的用户界面请求(例如，“打断”请求)时如何处理对话或会话。在第一时间，用户1502发出唤醒词“语音助手”，并且然后发出“设置提醒”的语音话语。响应地，客户端应用或语音助手发出“我应该提醒您什么？”，并且然后保持麦克风通信信道打开以收听用户的回答。如在截屏1504中所图示的，客户端应用还可以响应地引起列表1506的显示，这指示推荐提醒集合(例如，基于学习用户经由机器学习模型已经设置的过去提醒)。此时，用户1502能够说出、键入或者触摸建议的提醒。用户1502还可以提供具有各种组合的多个输入。

响应于引起列表1506的显示的客户端应用，用户1502然后发出语音话语“洗碗”以选择特定提醒。当一个或多个服务器(例如，一个或多个服务器1003)正在处理该请求时，客户端应用和/或一个或多个服务器可以接收用户1502已经选择指示冲突的手动用户输入的用户界面元素的指示。例如，特定实施例能够接收用户1502已经选择了在UI元素1506-1中指示的“接我的孩子”提醒的指示。例如，用户1502可能忘记了他们已经设置了关于洗碗的提醒，但是需要设置接孩子的提醒。因此，用户1502可能希望撤销语音话语请求。因此，至少部分地基于接收到相对于“洗碗”的语音话语的最后或最近(例如，由客户端应用和/或服务器)接收到的UI元素1506-1的手动用户输入点击的指示，特定实施例执行或者回复对UI元素1506-1的UI点击，而不是“洗碗”的语音话语。为了更清楚地向用户1502指示处理了哪个输入，在特定实施例中，语音助手说出或者导致显示响应消息“我为您设置了接孩子的提醒”和/或“我忽略了为您设置洗碗的提醒...这是正确的吗？”

替代地或另外地，并且以相同的方式，特定实施例可以在接收到“洗碗”请求之后接收用户1502已经选择了“取消”按钮1510的指示。因此，基于接收到“取消”按钮1510在相对于“洗碗”语音话语的时间上最后或更晚地被输入或接收的指示，特定实施例响应或者执行对应的取消请求，以便删除或撤销洗碗的提醒。随后，特定实施例接收用户1502已经选择麦克风按钮1508的指示，从而用户1502能够发出正确提醒的语音话语(例如，替代经由截屏1504的UI选择一个)。

响应或者执行最后接收到的输入指示考虑若干种不同的输入组合。例如，用户1502可以发出语音话语，并且在说话时，在句子中间点击UI元素1506-1。在该示例中，特定实施例一旦或响应于接收到用户已经发出手动发布器输入请求的指示(例如，点击UI元素1506-1)就禁用麦克风。以这种方式，由于在接收到手动用户输入的指示之后输入或接收的所有语音话语数据被忽略，因此不太可能出现关于处理什么输入的错误消息或用户混淆。因此，在这些实施例中，一旦或响应于确定后一输入是UI元件1506-1的手动用户输入，特定实施例就禁用麦克风，而不管用户是否处于句子中间。

在一些实施例中，最近接收的输入不需要是手动用户输入，并且初始输入不需要是语音话语，但是能够接收反向输入。在这种情况下，一些实施例仅执行或者响应语音话语，并且排除响应手动用户输入，因为语音话语是最近接收或输入的。例如，参考图15，特定实施例可以发出语音助手请求“我应该提醒您什么？”特定实施例然后可以接收用户1502已经选择UI元素150-6-1以接他们的孩子的指示。随后，用户1502可以发出“洗碗”话语，并且特定实施例因此在相对于手动用户输入的较晚时间接收该请求。因此，至少部分地基于特定实施例接收到相对于UI元素1506-1的选择在时间上较晚接收到“洗碗”输入的指示，一些实施例响应或者执行“洗碗”输入而不是“接我的孩子”输入。

在一些情况下，用户可以执行两个或更多个冲突的手动用户输入或语音话语。一些实施例响应最近的输入。例如，如在图15中所图示的，特定实施例可以接收用户已经发出“洗碗”输入的指示，并且稍后接收用户已经选择UI元素1506-1的指示。如上文所描述的，通常特定实施例响应或者执行与UI元素1506-1的选择相关联的请求，因为其是相对于语音话语在较晚的时间输入或接收到的。然而，用户1502可以再次提供另一冲突的手动用户输入，诸如点击对应于“设置牙医预约”的用户界面元素，这也和与点击UI元素1506-1的另一手动用户输入相关联的“接我的孩子”提醒冲突。在这些实施例中，“设置牙医预约”将被响应或者执行，因为相对于“洗碗”语音话语输入和UI元素1506-1的用户选择，其在时间上是最后或更晚输入或接收到的。在本文中所描述的这些不同实施例之前，现有技术将生成不可预测的结果或错误消息，并且用户不清楚哪个输入被处理，如在本文中所描述的。

在一些实施例中，客户端应用响应于接收到用户已经参与特定输入的指示而停止讲话。例如，客户端应用可以参与语音提示“我应该提醒您什么”，如在图15中所图示的。然而，响应于在说出该短语时接收到用户1502已经点击用户界面元素1506-1的指示，一些实施例使得客户端应用停止讲话并且开始处理触摸(或者如果用户1502参与语音话语而不是点击1506-1，则处理用户1502的语音话语)。对用户1502而言，这样的说话的停止指示语音助手意识到用户1502知道基于对用户界面元素1506-1的点击来选择哪个提醒。因此，客户端应用不需要重复地询问用户他们希望被提醒什么。

图16是图示了根据一些实施例的如何从用户角度处理多模态输入的示意图。图16具体图示了当用户在截屏1602的用户界面上同时执行手动用户输入时如何处理对话或会话。如在本文中所描述的，特定实施例支持多模态体验，其中，允许用户说话并且与UI元素交互。例如，如在图16中所图示的客户端应用可以问问题“提醒你这一点？”，开始收听，并且在屏幕上示出各种按钮和测试框(例如，类似于图15的列表1506)。用户1604可以在字段1602-1中键入“洗碗”，同时说“有人接下电话吗？”在这种情况下，电话可能当前在响，并且用户1604可能正在与他们家中的另一人讲话，而不是客户端应用或语音助手。然而，因为语音助手的麦克风可能已经被启用(例如，经由先前的唤醒词)，所以其可以拾取并且编码该不相关的语音话语。在一些实施例中，当存在如在图16中所图示的不同类型的同时输入时，特定实施例响应于接收到用户已经执行手动用户输入的指示而停止语音流或停用麦克风。在图16中，例如，响应于接收到用户1604已经至少部分地开始输入该字符串的指示，特定实施例响应或者仅执行针对如在字段1602-1中所指示的“洗碗”的文本输入。在一些实施例中，即使在接收到用户已经开始手动用户输入的指示之后发出的语音话语片段也被忽略，从而仅响应或者执行手动用户输入请求。

在典型的语音助手SDK堆栈中，如果用户1604说话(或者在后台有语音)并且同时与UI交互，则结果通常是不可预测的。此外，用户1604将不知道处理哪个输入。因此，特定实施例支持具有基于新规则集的可预测结果的多模态体验，如上文所描述的。

图17是根据一些实施例的用于选择性地响应多个输入中的仅一个输入的示例性过程1700的流程图。在一些实施例中，过程1700表示服务器侧功能(例如，一个或多个服务器1003)和/或客户端功能(例如，客户端1002)。

根据框1702，经由客户端应用接收话语数据。所述话语数据可以与用户的语音话语相关联。在框1702的说明性示例中，返回参考图10，一个或多个服务器1003可以经由步骤1从客户端1002接收话语数据。在这样的接收之前，客户端应用能够执行各种操作。例如，如在本文中所描述的，客户端应用能够检测用户的第一用户动作，诸如唤醒词或者选择用户界面元素(例如，麦克风按钮1508)。响应地，客户端应用能够发起对音频数据的记录或者以其他方式捕获(或者接收)音频数据。至少部分地基于音频数据记录的发起，客户端应用能够对与用户相关联的语音话语进行编码和/或然后将语音话语传输到一个或多个服务器。

在一些实施例中，框1702包括或者随后确定语音话语与第一响应类型相关联。关于图1的请求类型确定模块226描述了这方面的示例。例如，在接收到语音话语数据时，特定实施例确定请求的类型是与购买一个或多个商品或服务相关联的交易请求。例如，中央服务器(例如，中间服务307)能够从技能服务接收请求类型是从电子市场购买商品的请求的信号。这样的确定能够用于输入的进一步下游处理，如下文更详细描述的。

根据框1704，特定实施例接收用户已经在客户端应用的用户界面处参与手动用户输入的指示(例如，传输信号或标志值)。在这些实施例中，客户端应用能够首先接收与用户相关联的手动用户输入，其中，手动用户输入在客户端应用的用户界面处执行。随后，这样的用户界面请求能够由一个或多个服务器传输和处理。关于图15描述了框1704的示例，其中，实施例能够接收用户已经选择用户界面元素1506-1或者取消按钮1510的指示。关于接收用户在图6B的字段610中键入的内容来描述这方面的进一步示例，其可能与语音话语606矛盾或冲突。关于图7B还描述了其他示例，其中，实施例能够接收用户已经选择取消按钮708-4的指示。

如在本文中所描述的“手动用户输入”能够是排除语音话语输入的任何合适的用户交互。例如，手动用户输入能够是用户手指的触摸手势。这样的“触摸手势”能够是或者包括触摸触摸屏上的逻辑用户界面按钮、划动手势(例如，移除/删除UI项)、或者其中用户移动他或她的手指以提供识别的输入的任何其他合适的手势(例如，手指的捏放以分别放大或缩小显示屏)。

在一些实施例中，这样的手动用户输入能够替代地或另外地是由所述用户输入的文本输入，例如，关于用户在图6B的字段610中键入的。在一些实施例中，这样的手动用户输入能够替代地或另外是用户指针点击(诸如鼠标)，例如，关于图15的用户界面元素1506-1的选择所图示的。

根据框1706，特定实施例(例如，一个或多个服务器1103)确定相对于语音话语是否在较晚的时间(或者更近的时间)接收到手动用户输入(和/或用户的输入)。例如，一个或多个服务器1003接收对应于图10的步骤1和2的传输请求，其中，一个或多个服务器1003以时间戳递增数据结构，指示一个或多个服务器1003何时接收到这样的请求以确定在时间上较晚接收到哪个请求。

根据框1708，如果手动用户输入是相对于语音话语在较晚的时间接收到的，则特定实施例使得客户端应用仅响应手动用户输入(并且避免响应语音话语)。关于图15描述了这方面的示例，其中，执行与用户界面元素1506-1的选择相对应的请求而不是来自用户1502的“洗碗”语音话语。一些实施例另外地或替代地基于手动用户输入的接收来停用麦克风(例如，不管接收不同输入的顺序如何)。并且响应于麦克风的停用以及手动用户输入的接收，特定实施例仅响应手动用户输入而不响应语音话语。关于图16描述了这方面的示例，其中，能够同时接收输入，但是在给定时间仅能处理一个。

根据框1710，特定实施例使得客户端应用仅响应对应于语音话语数据的语音话语(而不是手动用户输入)。如在本文中关于请求类型确定模块226和初始请求处理模块230所描述的，特定实施例确定所述语音话语是在接收到手动用户输入之前接收到(或者由用户输入)的。并且一些实施例至少部分地基于确定语音话语与第一请求类型(例如，交易类型)相关联和/或确定语音话语是在接收到手动用户输入之前接收到的来回答或响应所述语音话语，并且不回答或响应所述手动用户输入。类似地，一些实施例基于所述语音话语是相对于手动用户输入在较晚的时间接收到的来仅响应语音话语，从而排除对手动用户输入的响应。

在一些实施例中，关于图17描述的任何功能与在本文中所描述的任何其他功能相组合，诸如相对于图8的过程800和图9的补充900所描述的功能。例如，一些实施例在客户端应用处渲染第一实例。一些实施例检测用户的用户动作(例如，唤醒词或点击麦克风按钮)。一些实施例响应于所述检测而发起对音频数据的记录。至少部分地基于记录的发起，特定实施例对用户的语音话语进行编码。至少部分地基于第一实例内的信息，一些实施例从第一实例并且在客户端应用处提取用户视图上下文。至少部分地基于用户视图上下文和语音话语，特定实施例确定(或者导致确定)用户意图。至少部分地基于用户意图和语音话语是相对于手动用户输入在较晚的时间接收到的，特定实施例通过利用数据自动地填充客户端应用的第一实例或第二实例来响应语音话语(例如，而不是手动用户输入)。

然而，在一些实施例中，通过利用数据填充客户端应用的第一实例或第二实例来响应语音话语或手动用户输入中的一者或两者。例如，如果在同一会话中相对于语音话语在较晚的时间接收到手动用户输入(或者完全接收到)，则可以仅响应手动用户输入。在这些实施例中，能够在确定用户意图的任何时间或期间输入或接收手动用户输入。在一些实施例中，当在同一会话中相对于语音话语在较晚的时间接收到手动用户输入(或者完全接收到)时，基于与语音话语冲突(例如，经由NLP)或完全发生的手动用户输入，确定用户意图以包括取消或避免响应语音话语。然而，在一些实施例中，手动用户输入不与语音话语冲突，而是称赞或者添加/过滤额外请求(或者反之亦然)。在这些实例中，一些实施例处理这两个输入(例如，经由NLP)。例如，用户可以发出说“邀请John到会议”的语音话语。此后不久(例如，1秒钟之后)，用户可能忘记提到邀请Jane到会议。用户可以决定点击或者以其他方式执行手动用户输入，以请求邀请Jane到会议，而不是说出这一点。在这些实施例中，邀请不冲突，并且因此用户意图可以是添加这两个参与者。因此，一些实施例执行或响应这两个输入，而不是避免执行一个输入或另一个输入。

图18是根据一些实施例的用于选择性地响应多个输入中的仅一个输入的示例性过程1800的流程图。在一些实施例中，过程1800表示服务器侧功能(例如，一个或多个服务器1003)和/或客户端功能(例如，客户端1002)。

根据框1802，经由客户端应用接收话语数据。在一些实施例中，框1802包括关于图17的框1702所描述的功能。根据框1804，一些实施例接收用户已经在客户端应用的用户界面处参与手动用户输入的指示。在一些实施例中，框1804包括关于图17的框1704所描述的功能。

根据框1806，至少部分地基于所述指示，一些实施例导致对麦克风的停用或去激活，使得麦克风不记录或收听音频数据，或者不处理或响应经由麦克风接收的音频数据。关于图16描述了这方面的示例，其中，用户1604已经参与了对文件1602-1的“洗碗”字符串的手动用户输入。响应于检测到用户已经开始输入该字符串的实施例，特定实施例禁用麦克风，使得话语1606不被麦克风拾取。以这种方式，在执行客户端请求时出现错误的可能性更小。一些实施例另外地基于相对于手动用户输入在较早的时间发出或接收的语音话语，或者手动用户输入是相对于语音话语在较晚的时间发出或接收到的，来停用麦克风。

根据框1808，一些实施例至少部分地基于所述停用来使得客户端应用响应手动用户输入而避免响应语音话语。关于图16描述了这方面的示例，其中，语音助手避免响应语音话语1606，而是响应手动用户输入。

在描述了本公开的各种实施例之后，现在描述适于实现本公开的实施例的示例性计算环境。参考图19，提供了示例性计算设备1900，并且通常将其称为计算设备1900。计算设备1900仅是合适的计算环境的一个示例，而并不旨在建议对本公开的使用范围或功能的任何限制。计算设备1900也不应当被解释为具有与所图示的组件的任何一个或组合有关的任何依赖性或要求。

本公开的实施例可以是在计算机代码或机器可用指令的一般上下文中描述的，包括由计算机或者其他机器(诸如智能电话、平板PC、或者其他移动设备、服务器或客户端设备)执行的计算机可用或计算机可执行指令。通常，程序模块(包括例程、程序、对象、组件、数据结构等)指代执行特定任务或者实现特定抽象数据类型的代码。本公开的实施例可以在各种系统配置中实施，包括移动设备、消费者电子产品、通用计算机、更专业的计算设备等。本公开的实施例也可以在分布式计算环境中实践，其中，任务由通过通信网络链接的远程处理设备执行。在分布式计算环境中，程序模块可以位于本地和包括存储器存储设备的远程计算机存储介质中。

一些实施例可以包括端到端的基于软件的系统，所述系统能够在本文中所描述的系统组件内操作以操作计算机硬件来提供系统功能。在低层，硬件处理器可以执行从用于给定处理器的机器语言(也被称为机器代码或本机)指令集合中选择的指令。处理器识别本机指令并且执行对应的低层功能，例如与逻辑、控制和存储器操作相关。以机器代码编写的低层软件能够为高层软件提供更复杂的功能。因此，在一些实施例中，计算机可执行指令可以包括任何软件，包括用机器代码编写的低层软件、诸如应用软件的高级软件以及其任意组合。在这方面，系统组件能够管理资源并且为系统功能提供服务。本公开的实施例设想了其任何其他变体以及其组合。

参考图19，计算设备1900包括直接或间接地耦合以下设备的总线10：存储器12、一个或多个处理器14、一个或多个呈现组件16、一个或多个输入/输出(I/O)端口18、一个或多个I/O组件20和说明性电源22。总线10表示可以是一个或多个总线(诸如地址总线、数据总线或者其组合)。尽管图19的各个框为了清楚起见利用线条示出，但是实际上，这些框表示逻辑组件，而不一定是实际组件。例如，可以将诸如显示设备的呈现组件视为I/O组件。同样地，处理器具有存储器。本发明的发明人认识到这是本领域的本质，并且重申图19仅仅例示说明能够结合本公开的一个或多个实施例使用的示例性计算设备。在诸如“工作站”、“服务器”、“膝上型计算机”、“手持设备”或者其他计算设备等类别之间没有进行区分，因为所有这些都在图19关于“计算设备”的范围内。

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

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

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

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

在识别了在本文中所使用的各种组件之后，应当理解，在本公开的范围内，可以采用任何数量的组件和布置来实现所需的功能。例如，为了概念清楚起见，用线条示出了图中描绘的实施例中的组件。还可实施这些和其他组件的其他布置。例如，尽管一些组件被描述为单个组件，但是在本文中所描述的许多组件可以被实现为离散或分布式组件，或者与其他组件结合，并且以任何合适的组合和位置实现。一些元素可以完全省略。此外，在本文中描述为由一个或多个实体执行的各种功能可以由硬件、固件和/或软件来执行，如下所述。例如，各种功能可以由执行存储在存储器中的指令的处理器来执行。这样，除了所示的布置和元件之外或代替所示的布置和元件，还可以使用其他布置和元件(例如，机器、界面、功能、命令和功能的分组等)。

描述本公开的实施例的意图是说明性的而不是限制性的。上面段落中描述的实施例可以与具体描述的替代方案中的一个或多个相结合。具体地，在替代方案中，所要求保护的实施例可以包含对一个以上其他实施例的引用。所要求保护的实施例可以指定所要求保护的主题的进一步限制。对于本公开的读者来说，在阅读本公开之后并因为阅读本公开，替代实施例变得显而易见。在不背离以下权利要求的范围的情况下，可以完成实施前述的替代手段。某些特征和子组合是有用的，并且可以在不参考其他特征和子组合的情况下使用，并且在权利要求的范围内考虑到这些特征和子组合。

如在本文中所使用的，术语“集合”可以用于指对象(或元素)的有序(即，顺序)或无序(即，非顺序)集合，例如但不限于数据元素(例如，事件、事件集群等)。集合可以包括N个元素，其中N是任意非负整数。亦即，集合可以包括0、1、2、3、...N个对象和/或元素，其中N是没有上限的正整数。因此，如在本文中所使用的，集合可以是不包括元素的零集合(即，空集合)。集合可以只包括单个元素。在其他实施例中，集合可以包括明显大于一个、两个或三个元素的多个元素。如本文所用，术语“子集”是包含在另一集合中的集合。子集可以是但不要求是该子集包含在其中的另一集合的适当或严格子集。亦即，如果集合B是集合A的子集，那么在一些实施例中，集合B是集合A的适当或严格子集。在其他实施例中，集合B是集合A的子集，但不是集合A的适当或严格子集。

其他实施例

在一些实施例中，一种计算机化系统，诸如在上述任一实施例中所描述的计算机化系统，包括：至少一个计算机处理器；以及存储计算机可用指令的一个或多个计算机存储介质，所述计算机可用指令当由所述至少一个计算机处理器使用时使得所述至少一个计算机处理器执行操作。所述操作包括：检测用户的第一用户动作；并且在所述检测之后，捕获包括与所述用户相关联的语音话语的音频数据。所述操作还包括：经由用户界面接收与所述用户相关联的手动用户输入。所述操作还包括：至少部分地基于在较晚的时间接收到所述语音话语还是所述手动用户输入，仅响应所述语音话语或者仅响应所述手动用户输入，并且避免响应所述语音话语和所述手动用户输入两者。有利地，在本文中所描述的这些和其他实施例在计算机资源消耗(例如，CPU、存储器、I/O、网络延时)方面改善了计算机的操作方式。由于各种实施例与客户端应用充分集成，因此其不需要用户手动地执行过多的输入，诸如退出语音助手控制的用户界面画布、钻到其他客户端应用页面以完成与语音话语相关联的任务(例如，切换到聊天窗口)、发送查询等。相反，这些实施例并不依赖于位于客户端应用顶部的语音助手控制层，而是自动地提供数据。因此，当例如TCP/IP分组遍历网络时，由于在计算机网络上发送的数据较少，因此吞吐量和延时成本降低。以类似的方式，由于用户不必继续输入信息，诸如通过与语音助手控制的窗口交互、填充语音助手控制的窗口的各种字段等，因此没有那么多的磁盘I/O成本(例如，非易失性磁盘上的多余物理读/写磁头移动)。因此，相对于现有技术，计算系统不必到达存储设备以执行读或写操作的次数，这减少了I/O。

在计算机化系统的上述实施例的任意组合中，手动用户输入包括用户的触摸手势、用户的文本条目输入或者用户的指针点击。

在计算机化系统的上述实施例的任意组合中，用户动作包括以下中的至少一项：用户发出的唤醒词，以及与用户界面元素的交互。

在计算机化系统的上述实施例的任意组合中，所述操作还包括：确定所述语音话语与第一响应类型相关联；确定所述语音话语是在接收到所述手动用户输入之前接收到的；以及至少部分地基于确定所述语音话语与所述第一响应类型相关联以及确定所述语音话语是在接收到所述手动用户输入之前接收到的，引起对语音话语的响应并且避免响应所述手动用户输入。

在计算机化系统的上述实施例的任意组合中，所述操作还包括：利用标识符(ID)来标记响应类型，并且将ID高速缓存在计算机存储器中，其中，引起对所述语音话语的所述响应是基于被高速缓存在所述计算机存储器中的ID的。

在计算机化系统的上述实施例的任意组合中，所述操作还包括：相对于所述语音话语在较晚的时间接收所述手动用户输入；以及基于所述手动用户输入是相对于所述语音话语在较晚的时间接收到的，仅响应所述手动用户输入，并且避免响应所述语音话语。

在计算机化系统的上述实施例的任意组合中，所述操作还包括：基于接收到所述手动用户输入，停用麦克风；以及响应于停用所述麦克风并且基于接收到所述手动用户输入，仅响应所述手动用户输入。

在计算机化系统的上述实施例的任意组合中，所述操作还包括：相对于所述手动用户输入在较晚的时间接收所述语音话语；以及基于所述语音话语是相对于所述手动用户输入在较晚的时间接收到的，仅响应所述语音话语，其中，排除响应所述手动用户输入。

在计算机化系统的上述实施例的任意组合中，所述操作还包括：相对于所述手动用户输入在较晚的时间接收所述语音话语；确定与所述系统相关联的客户端应用的第一实例；至少部分地基于所述第一实例内的信息，从所述第一实例中并且在所述客户端应用处提取用户视图上下文；至少部分地基于所述用户视图上下文和所述语音话语，引起对用户意图的确定；以及至少部分地基于所述用户意图以及所述语音话语是相对于所述手动用户输入在较晚的时间接收到的，通过利用数据自动地填充所述客户端应用的所述第一实例或所述第二实例来响应所述语音话语。

在计算机化系统的上述实施例的任意组合中，确定所述用户意图包括：通过确定所述客户端应用的所述第一实例内的所述信息来确定所述用户正在试图在所述客户端应用内完成的可能的界面任务，其中，所述第一实例包括所述客户端应用的当前打开的页面或窗口。

在计算机化系统的上述实施例的任意组合中，自动地填充包括从所述第一实例自动地切换到所述第二实例以及利用所述数据自动地填充所述第二实例。

在计算机化系统的上述实施例的任意组合中，所述第一实例包括具有字段的页面或者具有字段的窗口，并且其中，自动地填充包括利用所述数据自动填充所述字段。

在计算机化系统的上述实施例的任意组合中，在所述第一实例处提取的所述信息当前正在经由所述用户界面显示。

在一些实施例中，提供了一种计算机实现的方法。所述方法包括：经由客户端应用接收话语数据，所述话语数据与用户的语音话语相关联。所述方法还包括：接收所述用户已经在所述客户端应用的用户界面处参与手动用户输入的指示。所述方法还包括：至少部分地基于所述用户已经参与所述手动用户输入的所述指示，引起对麦克风的停用，使得：所述麦克风避免捕获音频数据，或者不处理经由所述麦克风接收到的所述音频数据。所述方法还包括：至少部分地基于停用所述麦克风，引起所述客户端应用响应所述手动用户输入，并且避免响应所述语音话语。有利地，如在本文中所描述的，这些和其他实施例改善了现有的语音助手技术，因为其与客户端应用完全集成，以便通过引起与所述客户端应用的有意义的交互来执行语音话语(例如，执行操作、请求或者执行与话语相关联的任务)。

在计算机实现方法的上述实施例的任意组合中，所述手动用户输入包括以下中的至少一项：所述用户的触摸手势、所述用户的文本条目输入或者所述用户的指针点击。

在计算机实现方法的上述实施例的任意组合中，所述方法还包括：相对于所述语音话语在较晚的时间接收所述手动用户输入；以及进一步基于所述手动用户输入是相对于所述语音话语在较晚的时间接收到的，仅响应所述手动用户输入。

在计算机实现方法的上述实施例的任意组合中，所述方法还包括：至少部分地基于用户视图上下文和手动用户输入，来确定用户意图；以及至少部分地基于所述用户意图，通过利用数据填充所述客户端应用的第一实例来响应所述手动输入。

在计算机实现方法的上述实施例的任意组合中，所述第一实例是当前在所述客户端应用内呈现的页面或窗口。

在一些实施例中，提供一个或多个计算机存储介质。所述一个或多个计算机存储介质具有体现在其上的计算机可执行指令，所述计算机可执行指令当由一个或多个处理器运行时，使得所述一个或多个处理器执行方法。所述方法包括呈现客户端应用的第一实例。所述方法还包括检测用户的用户动作。所述方法还包括在所述检测之后，捕获包括与所述用户相关联的语音话语的音频数据。所述方法还包括至少部分地基于所述第一实例内的信息，从所述第一实例中提取用户视图上下文。所述方法还包括在所述客户端应用处接收与所述用户相关联的手动用户输入，所述手动用户输入在所述客户端应用的用户界面处执行。所述方法还包括使得所述用户视图上下文和所述语音话语传输到一个或多个服务。所述方法还包括通过利用数据填充所述客户端应用的第一实例或第二实例来响应所述语音话语和所述手动用户输入中的至少一项。有利地，这些实施例和其他实施例改善了现有的语音助手功能，因为其支持多模态输入而没有错误和对用户具有可预测性。这是因为这些实施例使用自动地处理不同用户输入的新规则，即使当这样的输入是冲突的。一些实施例另外可视地指示处理了哪些用户输入。这样的可视化的指示或使用所述新规则使得用户清楚地知道哪些输入被处理。

在一个或多个计算机存储介质的上述实施例的任意组合中，所述方法还包括：至少部分地基于接收到所述用户已经参与所述手动用户输入的指示，并且进一步基于所述一个或多个服务对用户意图的确定，仅响应所述手动用户输入；并且不响应语音话语。

Claims (15)

1.一种系统，包括：至少一个计算机处理器；以及存储计算机可用指令的一个或多个计算机存储介质，所述计算机可用指令当由所述至少一个计算机处理器使用时，使得所述至少一个计算机处理器执行包括以下的操作：检测用户的第一用户动作；在所述检测之后，捕获包括与所述用户相关联的语音话语的音频数据；经由用户界面接收与所述用户相关联的手动用户输入；以及至少部分地基于在较晚的时间接收到所述语音话语还是所述手动用户输入，仅响应所述语音话语或者仅响应所述手动用户输入，并且避免响应所述语音话语和所述手动用户输入两者。

2.根据权利要求1所述的系统，其中，所述手动用户输入包括所述用户的触摸手势、所述用户的文本条目输入或者所述用户的指针点击。

3.根据权利要求1所述的系统，其中，所述用户动作包括以下中的至少一项：由所述用户发出的唤醒词，和与所述用户界面的元素的交互。

4.根据权利要求1所述的系统，还包括：确定所述语音话语与第一响应类型相关联；确定所述语音话语是在接收到所述手动用户输入之前接收到的；以及至少部分地基于确定所述语音话语与所述第一响应类型相关联以及确定所述语音话语是在接收到所述手动用户输入之前接收到的，引起对所述语音话语的响应，并且避免响应所述手动用户输入。

5.根据权利要求4所述的系统，其中，所述操作还包括：利用标识符(ID)来标记所述响应类型，以及将所述ID高速缓存在计算机存储器中，其中，引起对所述语音话语的所述响应是基于被高速缓存在所述计算机存储器中的所述ID的。

6.根据权利要求1所述的系统，还包括：相对于所述语音话语在较晚的时间接收所述手动用户输入；以及基于所述手动用户输入是相对于所述语音话语在较晚的时间接收到的，仅响应所述手动用户输入，并且避免响应所述语音话语。

7.根据权利要求1所述的系统，还包括：基于接收到所述手动用户输入，停用麦克风；以及响应于停用所述麦克风并且基于接收到所述手动用户输入，仅响应所述手动用户输入。

8.根据权利要求1所述的系统，还包括：相对于所述手动用户输入在较晚的时间接收所述语音话语；以及基于所述语音话语是相对于所述手动用户输入在较晚的时间接收到的，仅响应所述语音话语，其中，排除响应所述手动用户输入。

9.根据权利要求1所述的系统，还包括：相对于所述手动用户输入在较晚的时间接收所述语音话语；确定与所述系统相关联的客户端应用的第一实例；至少部分地基于所述第一实例内的信息，从所述第一实例并且在所述客户端应用处提取用户视图上下文；至少部分地基于所述用户视图上下文和所述语音话语，引起对用户意图的确定；以及至少部分地基于所述用户意图以及所述语音话语是相对于所述手动用户输入在较晚的时间接收到的，通过利用数据自动地填充所述客户端应用的所述第一实例或第二实例来响应所述语音话语。

10.根据权利要求9所述的系统，其中，对所述用户意图的所述确定包括：通过确定所述客户端应用的所述第一实例内的所述信息来确定所述用户正在试图在所述客户端应用内完成的可能的界面任务，其中，所述第一实例包括所述客户端应用的当前打开的页面或窗口。

11.根据权利要求9所述的系统，其中，所述自动地填充包括从所述第一实例自动地切换到所述第二实例以及利用所述数据自动地填充所述第二实例。

12.根据权利要求9所述的系统，其中，所述第一实例包括具有字段的页面或者具有字段的窗口，并且其中，所述自动地填充包括利用所述数据自动地填充所述字段。

13.根据权利要求9所述的系统，其中，在所述第一实例处提取的所述信息当前正在经由所述用户界面显示。

14.一种计算机实现的方法，包括：经由客户端应用接收话语数据，所述话语数据与用户的语音话语相关联；接收所述用户已经在所述客户端应用的用户界面处参与手动用户输入的指示；至少部分地基于所述用户已经参与所述手动用户输入的所述指示，引起对麦克风的停用，使得：所述麦克风避免捕获音频数据，或者不处理经由所述麦克风接收到的所述音频数据；至少部分地基于对所述麦克风的所述停用，引起所述客户端应用响应所述手动用户输入，并且避免响应所述语音话语。

15.根据权利要求14所述的计算机实现的方法，其中，所述手动用户输入包括以下中的至少一项：所述用户的触摸手势、所述用户的文本条目输入以及所述用户的指针点击。