所述各种原因包括但不限于乘员情绪、车辆速度、交通的密度、天气状况、其他车辆乘员等。因此，乘员被提供有拒绝询问的机会。但是，如果乘员希望响应该询问且仅在目前不能这样做，则乘员还被呈现有用于询问等待询问的选项。
[0050]这样一种用于呈现等待选项的方式是在示意性实施例中示出的示意性等待稍后功能的示例。等待稍后功能执行微交互，但解析驾驶员输入并在其被传送到微交互代码之前执行等待稍后命令。口头等待稍后命令包括但不限于:
[0051 ] I)等待(使用内置规则来确定什么等待)
[0052]2)等待一分钟
[0053]3)等待十分钟
[0054]4)等待在交叉路口停车
[0055]5)等待直到通过交叉路口为止
[0056]6)等待直到停车为止
[0057]7)等待信号灯关闭
[0058]8)等待转向变直
[0059]9)等待低的横向加速
[0060]10)等待直到我说“停止等待”为止[0061 ] 11)取消(不想等待该微交互)
[0062]12)等待直到我重新启动车辆为止
[0063]13)等待直到我结束谈话为止
[0064]14)等等
[0065]当驾驶员发出这些命令中的一个命令时，微交互被暂停。等待稍后功能监测车辆总线上、互联网上以及来自驾驶员的事件，并应用一组内置规则来确定微交互何时应恢复。规则的相对权重可从驾驶员交互中在线学习到。
[0066]在示意性实施例的另一方面中，嵌入式系统学习并追踪驾驶员发出“等待”命令的次数和场景的频率。此外，对微交互的交互相对重要性进行分类。当驾驶员定制的情形在微交互启动之前被检测到时，WUL随后被自动启用JUL随后针对提升的驾驶员注意力和便捷性来适时地提供微交互的传送。
[0067]口头命令可具有驾驶员与车辆之间的通信的其它模式中的相关命令。例如，驾驶员可做出相当于说“等待”的手势，或者可按压方向盘上或控制面板上的按钮，或者触摸触摸屏的区域。
[0068]例如:驾驶员在左转车道中等待，当车辆开始向前移动时启动协作(cooperative)加速。呼叫到达驾驶员的蜂窝电话上，且电话应用产生用于车辆计算机系统的电话呼叫微表达。系统直播使得正在播放的电台暂停，并说“来自你妈妈的电话呼叫，你希望接听吗?”
[0069]在没有等待稍后功能的情况下，驾驶员可能必须决定说是或不，但是在具有等待功能的情况下驾驶员说“等待”。等待稍后功能执行微交互的第四组件，其中，用信号通知电话应用以保持电话并随后使自身暂停。等待稍后功能执行内置规则，所述内置规则使其等待直到左转信号灯关闭5秒为止，随后恢复微表达的执行，所述微表达将控制转移到所述问题组件，并通知驾驶员“来自你妈妈的电话呼叫，你希望接听吗?”控制被转移到所述回答组件且驾驶员回答“是”，且控制被传递到所述执行组件，所述执行组件发信号通知电话应用来取消保持电话。驾驶员开始会话。
[0070]图4示出用于微交互延迟的示意性处理。针对在该图中描述的示意性实施例，应该注意的是，为了执行在此示出的示例性方法中的一些或全部的目的，通用处理器可暂时被用作专用处理器。当执行提供用于执行所述方法中的一些或全部步骤的指令的代码时，所述处理器可被临时改用作专用处理器，直到所述方法被完成时为止。在另一示例中，在适当程度上，根据预先配置的处理器运行的固件可使得所述处理器充当为了执行所述方法或所述方法的一些合理变型的目的而被提供的专用处理器。
[0071]在该示意性交互中，情境适合于交互呈现，所以在401，该处理开始微交互的交互部分(即，呈现问题并等待响应)。在403，如果驾驶员未发出“等待”命令，但是相反却对提出的问题进行响应，则在405，该处理将继续进行交互。由于交互可能实际上是一组交互，所以在407检查“等待”命令可能必须被重复多次，直到在409完成微交互为止。
[0072]例如，驾驶员可用“不”来对示例性“特价交易”问题进行响应。但如果这不是交互的结束，则驾驶员可能在此时不想完成交互，反而暂停交互，直到可以给出更多的时间来回答任何后续问题为止。例如，系统接下来可能会问“你想要停止接收来自McFoodles的优惠吗?”驾驶员可能必须考虑响应，因此可声明“等待直到车辆停止为止”，使得能够为回答给出更多思考。一旦车辆停止(用于传送的新的条件)，则该处理可继续交互，直到在409完成交互为止。然后，在411，任何适当的基于响应的结果(例如，指示停止传送McFoodles优惠)可被执行。
[0073]如上所述，在413，条件可作为等待命令的一部分而被包括。另一方面，无条件的诸如“等待”的命令可使得系统暂停预定的时间量。或者，在另一示例中，如果条件“等待直到车辆停止为止”总是相同的，则“等待”命令的接收可触发通常观测到的条件。
[0074]在该示例中，一旦在415条件被满足，则在417，该处理随后恢复，且在405，该处理、等待命令接收、暂停和恢复的操作可继续进行，直到完成微交互为止。
[0075]图5示出用于微交互状态延迟命令处理的示意性处理。针对在该图中描述的示意性实施例，应该注意的是，为了执行在此示出的示例性方法中的一些或全部的目的，通用处理器可暂时被用作专用处理器。当执行提供用于执行所述方法的一些或全部步骤的指令的代码时，所述处理器可被临时改用作专用处理器，直到所述方法被完成时为止。在另一示例中，在适当程度上，根据预先配置的处理器运行的固件可使得所述处理器充当为了执行所述方法或所述方法的一些合理变型的目的而被提供的专用处理器。
[0076]在该示意性示例中，该处理已在501接收到等待命令且在503接收到伴随条件。典型的等待响应将是“等待”或“等待直到X发生为止”。虽然有时驾驶员可能请求车辆未被编程以识别的条件，但是系统可被编程为接收和对任何数量的条件进行响应。在某些情况下，驾驶员可能仅仅希望在响应之前等待某一时间段。
[0077]如果在505命令需要简易定时器(例如，“等待10分钟”或“等待”)，则在507，该处理可进行到设置计时器，然后在时间已经过去时继续进行。计时器可被预先确定以与“等待”命令一起使用，或者，例如，定时器可以是基于观测的用户偏好(例如，“等待+计时器”版本的命令总是5分钟)。
[0078]另一方面，如果在509实际车辆状态或情境状态(例如，但不限于“等待直到我停车为止”或者“等待直到不下雨为止”)被设置，则在513，该处理可能必须监测一个或更多个与车辆关联的系统，以确定用于传送的状态或情境。例如，车辆速度可被监测以确定停车，雨传感器可被监测以确定雨的缺乏。一旦在515条件被满足，则在517，交互随后可被处理。
[0079]还可能出现的情况是，请求的条件未被识别，例如，“等待直到下一次日食为止”。在这种情况下，系统可请求识别的条件，或者，例如，系统可在511仅终止交互。在进一步的情况下，未识别的条件可被分配与简单的“等待”命令一样的默认条件。
[0080]图6示出用于延迟条件学习的示意性处理。针对在该图中描述的示意性实施例，应该注意的是，为了执行在此示出的示例性方法中的一些或全部的目的，通用处理器可暂时被用作专用处理器。当执行提供用于执行所述方法的一些或全部步骤的指令的代码时，所述处理器可被临时改用作专用处理器，直到所述方法被完成时为止。在另一示例中，在适当程度上，根据预先配置的处理器运行的固件可使得所述处理器充当为了执行所述方法或所述方法的一些合理变型的目的而被提供的专用处理器。
[0081]因为车辆计算系统能够进行基本“学习”，所以可期望学习在何种情况下发出何种等待命令，并且即使在缺少来自用户的任何指示的情况下预测性地启用这些等待命令。例如，如果在下雨时每当用户接收到微交互时，用户总是发出“等待直到不下雨”的命令，则系统可在情境另外适合于交互传送且在下雨时预测性地启用该等待命令。类似地，例如，用高的频率度发出“等待直到我离开高速公路为止”命令的用户可使得该等待命令被预测性地启用。
[0082]另一方面，特定微交互可基于严重性来忽略自动等待命令。例如，由于因为该消息是“极重要的”且如果需要的话则应该暂时由用户来专门忽略该消息，因此声明“你的车辆燃料不足，你想要查找最近的加油站吗”的交互可忽略自动等待命令设置。可使用已知技术来确定乘员存在，已知技术包括但不限于基于移动装置的乘员识别、驾驶行为的观测等。
[0083]在图6中示出的示意性处理中，处理器通过观测和记录“等待”命令的常用实例连同伴随的情境一起来执行“学习”。在该示例中，在601，“等待”命令在微交互的呈现之后被接收。
[0084]此外在该示例中，虽然这不是必要的，但是条件在603被接收。系统还能够追踪无条件(也被称为空条件)的简单“等待”命令，并应用(通常预定义的)标准等待这样的命令。在该示例中，在605，该处理通过记录微交互的类型开始。微交互可在类型上有很大不同，从电子优惠券和广告，到车辆设置调整