CN103596119A - 用于基于语音的机器到机器通信的方法及设备 - Google Patents

Abstract

本发明提供了一种用于基于语音的机器到机器通信的方法及设备。一种***包括处理器，所述处理器被构造通过无线电话与处理器进行通信而建立的连接，经由语音呼叫与远程服务器进行通信。处理器还被构造为使用说出的、基于人类语言的通信来通过语音信道传送和接收数据和指令。处理器还被构造为利用标准化语音来动态地形成、发送和解释命令和数据，所述命令和数据包括预定义的***命令和与一个或多个***命令相关的由用户动态地输入的变量两者。

Description

用于基于语音的机器到机器通信的方法及设备

技术领域

示意性实施例总体上涉及用于基于语音的机器到机器通信的方法及设备。

背景技术

车载式信息娱乐服务已经在过去的十年内大量扩展，并且现在通常可以在车辆移动的同时将车辆计算机连接至远程服务器。可通过这些类型的连接，可在移动、无线连接的环境下发送和接收数据、车辆信息和远程***呼叫。

尽管车辆***能够进行远程通信，但一般需要某种形式的信号传输来与远程源进行通信。即，车辆***一般不具有嵌入式通信能力，而是依赖于例如用户无线装置来向远程源传输信号或传输来自于远程源的信号。

在一个示例中，可使用用户的蜂窝电话。通过用户数据计划或话上数据将数据从车辆***发送至用户的电话、再至远程源，并且通过相同路径回传。

然而，话上数据解决方案可能是私有性质的而且昂贵。必须采取一定的措施来保持数据完整并确保兼容性，而且数据传输的性质可能导致相对低的数据速率。使用用户数据计划的数据连接趋于更快，但该数据连接受限于用户电话确实具有数据计划的情况，并且可能还需要装置上的本地应用程序来管理数据会话。

发明内容

在第一示意性实施例中，一种***包括处理器，被构造通过无线电话与处理器进行通信而建立的连接，经由语音呼叫与远程服务器进行通信。处理器还被构造为使用说出的、基于人类语言的通信来通过语音信道传送和接收数据和指令。处理器还被构造为利用标准化语音来动态地形成、发送和解释命令和数据，所述命令和数据包括预定义的***命令和与一个或多个***命令相关的由用户动态地输入的变量两者。

在第二示意性实施例中，一种计算机实现方法包括通过无线电话与车辆处理器进行通信而建立的连接，经由语音呼叫与远程服务器进行通信。方法还包括使用说出的、基于人类语言的通信来通过语音信道传送和接收数据和指令。此外，方法还包括利用标准化语音来动态地形成、发送和解释命令和数据，所述命令和数据包括预定义的***命令和与一个或多个***命令相关的由用户动态地输入的变量两者。

至少一个命令与导航请求相关。

至少一个用户输入的变量包括地址。

所述方法还包括：将用户输入的地址分解为单独的字符并且单独说出所述字符从而形成用户输入的地址。

至少一个命令与警报通知相关。

所述方法还包括：发送安全验证信息。

所述方法还包括：将多个用于发送的命令以及附随的数据放入队列，并且当满足一个或多个队列发送条件时发送所述命令。

所述一个或多个条件包括满队列。

所述一个或多个条件包括一天中的与电话所有者的通话时长为不受限制的使用时长相应的时间。

在第三示意性实施例中，一种存储有当被车辆计算机***的处理器执行时引起处理器执行方法的指令的有形的计算机可读的存储介质，所述方法包括：通过无线电话与处理器进行通信而建立的连接，经由语音呼叫与远程服务器进行通。方法还包括使用说出的、基于人类语言的通信来通过语音信道传送和接收数据和指令。此外，方法还包括利用标准化语音来动态地形成、发送和解释命令和数据，所述命令和数据包括预定义的***命令和与一个或多个***命令相关的由用户动态地输入的变量两者。

附图说明

图1示出车辆计算机***的示意性示例；

图2示出语音-数据通信会话的示意性示例；

图3示出语音-数据通信会话的另一示意性示例；

图4示出消息队列会话示例；

图5示出警报传输的示例；

图6示出交通方向信息（TDI）会话的示意性示例。

具体实施方式

根据需要，在此公开本发明的详细实施例；然而，应当理解，所公开的实施例仅为本发明的示例，其可以以多种替代形式实施。附图无需按比例绘制；可夸大或缩小一些特征以显示特定组件的细节。因此，此处所公开的具体结构和功能细节不应被解释为限制，而仅为教导本领域技术人员以多种形式实施本发明的代表性基础。

图1示出用于车辆31的基于车辆的计算机***1（VCS）的示例性框式拓扑图。这种基于车辆的计算机***1的示例为福特汽车公司所制造的SYNC***。设有基于车辆的计算机***的车辆可包含位于车辆中的可视前端界面4。如果所述界面设置有例如触摸敏感屏幕，则用户还可与所述界面交互。在另一示意性实施例中，通过按钮按压以及具有自动语音识别和语音合成的语音会话***来进行交互。

在图1中所示的示意性实施例1中，处理器3控制基于车辆的计算机***的操作的至少一部分。设在车辆中的处理器允许在车上处理命令和程序。此外，处理器连接至非永久性存储器5和永久性存储器7两者。在该示意性实施例中，非永久性存储器为随机存取存储器（RAM），而永久性存储器为硬盘驱动器（HDD）或闪存。

处理器还设有允许用户与处理器交互的多个不同的输入。在该示意性实施例中，设有麦克风29、辅助输入25（用于输入33）、通用串行总线（USB）输入23、GPS输入24和蓝牙输入15。还设有输入选择器51，以允许用户在各种输入之间互换。在对麦克风和辅助连接器的输入被传递至处理器之前，通过转换器27将所述输入从模拟信号转换为数字信号。尽管没有显示，但是与VCS通信的多个车辆组件和辅助组件可使用车辆网络（诸如但不限于控制器区域网络（CAN）总线）以向VCS（或其组件）传递数据或传递来自VCS（或其组件）的数据。

对***的输出可包括但不限于可视显示器4和扬声器13或立体声***输出。扬声器连接至放大器11并通过数字-模拟转换器9从处理器3接收其信号。还可分别沿19和21处所示的双向数据流产生至远程蓝牙装置（诸如个人导航装置（PDN）54）或USB装置（诸如车辆导航装置60）的输出。

在一个示意性实施例中，***1使用蓝牙收发器15与用户的移动装置53（例如，蜂窝电话、智能电话、个人数字助理（PDA）或具有无线远程网络连接能力的任何其它装置）进行通信17。移动装置随后可用于通过例如与蜂窝塔57的通信55来与车辆31外部的网络61进行通信59。在一些实施例中，蜂窝塔57可以为WiFi接入点。

信号14代表了移动装置和蓝牙收发器之间的示例性通信。

可通过按钮52或类似输入来指示移动装置53与蓝牙收发器15进行配对。因此，指示中央处理单元（CPU）车载蓝牙收发器将与移动装置中的蓝牙收发器进行配对。

可利用例如与移动装置53相关联的数据计划、话上数据或双音多频（DTMF）音调在CPU3和网络61之间传递数据。可选择地，可期望包括具有天线18的车载调制解调器63以便在语音频带上在CPU3和网络61之间对数据进行通信16。移动装置53随后能够通过例如与蜂窝塔57的通信55而被用来与车辆31之外的网络61进行通信59。在一些实施例中，调制解调器63可与蜂窝塔57建立通信20，以与网络61通信。作为非限制性示例，调制解调器63可以是USB蜂窝调制解调器并且通信20可以是蜂窝通信。

在一个示意性实施例中，处理器设有包括与调制解调器应用软件进行通信的API（应用编程接口）的操作***。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件，以完成与远程蓝牙收发器（诸如设在移动装置里的）的无线通信。蓝牙是IEEE802PAN（个人区域网）协议的子集。IEEE802LAN（局域网）协议包括WiFi并且与IEEE802PAN具有相当多的交叉功能。两者都适合于车辆内的无线通信。可以在所述领域使用的其它通信方式为自由空间光通信（诸如红外数据协议IrDA）和非标准的消费者红外IR协议。

在另一实施例中，移动装置53包括用于语音频带或宽带数据通信的调制解调器。在话上数据的实施例中，当正在传输数据期间移动装置的拥有者可对装置说话时，可执行已知为频分复用的技术。在其它时间，当拥有者没有使用所述装置时，数据传输可使用整个带宽（在一个示例中为300Hz至3.4kHz）。尽管频分复用对于车辆与因特网之间的模拟蜂窝通信而言可能是常见的并且仍在使用，但其已经很大程度上被针对数字蜂窝通信的码域多址（CDMA）、时域多址（TDMA）、空域多址（SDMA）的混合体所替代。这些都是ITU IMT-2000（3G）兼容的标准，并且为静止或者行走的用户提供高达2mbs的数据率以及为在移动的车辆内的用户提供高达385kbs的数据率。3G标准现正被为在车辆内的用户提供100mbs的数据率以及为静止的用户提供1gbs的数据率的IMT（国际移动通信）高级（4G）所替代。如果用户拥有与移动装置关联的数据计划，则所述数据计划可允许宽带传输且***可使用宽得多的带宽（加速数据传送）。在又一实施例中，移动装置53被安装至车辆31的蜂窝通信装置（未显示）所替代。在又一实施例中，移动装置（ND）53可为能够通过例如（而非限制）802.11g网络（即WiFi）或WiMax网络进行通信的无线局域网（LAN）装置。

在一个实施例中，输入数据可经由话上数据或数据计划穿过移动装置、穿过车载蓝牙收发器、并进入车辆的内部处理器3。例如，在某些临时数据的情况下，数据可存储在HDD或其它存储介质7上，直至不再需要所述数据的时候。

其它可与车辆进行交互的源包括：具有例如USB连接56和/或天线58的个人导航装置54，具有USB62或其它连接的车辆导航装置60，车载GPS装置24，或者与网络61连接的远程导航***（未显示）。USB是一类串行网络协议中的一种。IEEE1394（火线^TM（苹果）、i.LINK^TM（索尼）和Lynx^TM（德州仪器））、EIA（电子工业协会）串行协议、IEEE1284（并口）、S/PDIF（索尼/飞利浦数字互连格式）和USB-IF（USB应用者论坛）形成了装置-装置串行标准的骨干。多数协议可实施为用于电通信或光通信。

此外，CPU能与各种其它的辅助装置65进行通信。这些装置可通过无线连接67或有线连接69来连接。辅助装置65可包括但不限于个人多媒体播放器、无线医疗装置、便携式计算机等。

此外或可选择地，CPU可使用例如WiFi（IEEE803.11）71收发器而连接至基于车辆的无线路由器73。这能允许CPU在本地路由器73的范围内连接到远程网络。

除了具有通过位于车辆中的车辆计算机***执行的示例性处理之外，在一些实施例中，还可以通过与车辆计算机***通信的计算机***来执行示例性处理。这样的***可包括但不限于无线装置（例如但不限于，移动电话）或者经由无线装置连接的远程计算机***（例如但不限于，服务器）。总体上，这些***可被称为与车辆相关联的计算机***（VACS）。在特定的实施例中，VACS的特定组件可根据***的特定实施而执行处理的特定部分。通过示例并且是非限制的方式，如果处理具有利用配对的无线装置发送或者接收信息的步骤，则很可能无线装置不执行所述处理，因为所述无线装置不会与自身进行信息的“发送和接收”。本领域的普通技术人员将理解何时不适合对给定解决方案应用特定的VACS。在所有解决方案中，预期至少位于车辆中的车辆计算机***（VCS）自身能够执行示例性处理。

目前，某些远程信息处理方案利用与远程服务器进行通信的多种方法来获取信息和服务。这些通信一般在车辆计算机***（VCS）（诸如但不限于上述示例性***）和一个或多个远程数据提供商之间。可通过将车辆中的无线装置有线或无线地连接到VCS来建立通信。这些通信通常以话上数据的形式（其利用无线装置的语音信道来传输数据）或以数据计划使用的形式（其使用无线装置的数据计划）来进行。

然而，每个现有方案都具有一些潜在的缺点。话上数据可能需要使用第三方提供商，其可能包括固定花费和使用率两者。随着时间的推移，这些使用率会在量上累积而对车辆拥有者或OEM（原始设备制造商）服务提供商造成高额花费。此外，与DOV（话上数据）关联的数据率可能低于其它解决方案，因此可能有必要扩展电话的使用，或者作为替代，可能需要开发针对数据传输和服务的低数据使用解决方案。

另一方面，与无线装置相关联的数据计划具有比DOV选项高得多的数据率。然而，这种形式的数据传输需要用户电话具有与其关联的数据计划。这可能为没有激活或可用的数据计划的用户带来问题。此外，在一些实施中，所述处理可能需要在电话上运行的本地应用程序来管理数据会话。

提出了数据传输的第三选项。尽管不一定优于上述解决方案，但所述选项在可用于连接的多个无线装置之间提供有用的兼容性、合理的数据传递和服务使用。在经提议的选项中，车辆计算机***将利用预定义的语音来通过电话音频连接与远程服务器进行交谈。使用真正的语音而并非话上数据来在远程服务器和VCS之间来回传递信息。

通过使用预定义的语音（而不是例如用户语音或随机电子语音），***可确保针对准确的数据传送和命令识别的高度的兼容性。此外，在至少某些情况下，识别功能可确保通过电话进行的语音通过被“授权”（即，实际的预编程的语音）。尽管预编程的语音当然可能被伪造，但任何不与预编程的语音的特定特征相匹配的语音至少可被当作试图获得对***的访问的不正当企图而被淘汰。

图2示出语音-数据通信会话的示意性示例。在此示意性示例中，如上所述，车辆计算机***利用语音命令选项来传递数据并交换命令和数据。在此示例中，VCS将使用连接的无线装置来建立至已知服务器的电话呼叫（201）。例如，号码可以是被编程为接收传入的语音命令呼叫的安全号码。

在此示意性示例中，一旦拨出呼叫，服务器就将应答（203）并且准备接收传入的语音命令。在此示例中，服务器开始监听命令，但是服务器也可首先指示VCS如何进行应答。例如，在至少一个模型中，服务器可首先向VCS请求一些信息来验证呼叫实体的资格或者建立其它安全协议。

在此处示出的示意性示例中，VCS将在合适的时间说出一个或多个命令，以及处理所述命令所需要的任何数据（205）。例如而并非限制，处理可说出“方向”并且随后提供方向所需的信息，所述信息包括（例如而并非限制）车辆位置（坐标）、车速、行驶方向和期望的目的地。

在接收适当的命令并完成任何需要的验证后，服务器可随后利用合适的软件对命令和/或传入的数据进行解码（207）。尽管可能使用语音识别软件，但由于在请求（即，计算机产生的预定语音）的全部情况中，相对于必须对随机计算机语音或用户语音进行解码和解释，扬声器是普通的，因此处理可利用相对简单的语音识别软件。这可以满足一定程度的数据传输的完整性和准确性的一定保证。

一旦已经对命令和数据进行了解码，服务器随后就可处理传入的命令（209）。在某些情况下，所述命令可以是对来自服务器的数据的请求或者需要服务器和VCS之间的某种程度的交互。在这些情况下，可在服务器和VCS之间利用语音来进行通信，或者在其它情况下利用语音和其它选项的组合来进行通信。

在示出的示例中，例如，从服务器将至少一个数据中继回VCS。在这种情况下，服务器利用相似的语音生成器以类似于数据从VCS被发送至服务器的方式回答VCS（211）。VCS随后可接收传入的数据并且使用类似的解码软件来处理回复（213）。随后可继续将这一处理进行数次，直到在两个实体之间传输了全部必需的数据。

图3示出语音-数据通信会话的另一示意性示例。尽管同图2中的示例相似，但此实施例显示了一些高级命令处理和安全特征。在某些情况下，可能需要在VCS和服务器之间传递例如但不限于方向和信息、非标准信息。虽然用于“得到方向”的命令和基本位置坐标的标准化可能足够简单，但是其它地址和位置的实际名称可能不能被放入标准词表（vocabulary）内。在这种情况下，处理可能需要为远程服务器拼出数据元素，从而确保正确的数据传递。

在此示意性示例中，如图2中的示例那样，处理首先拨出电话呼叫。在这种情况下，处理将利用某些形式的验证，并且因此在此示例中，处理首先说出启动命令（301），从而通知服务器验证协议可能即将传入。当然，作为替代，服务器可以请求此信息，或者在另一实施例中，如果验证“总是开启”，则可跳过此命令，由于验证序列稍后可自然地作为被传送的首个数据。

在此示例中，一旦通信已经建立并且启动命令已被处理，VCS随后就可说出可用作服务器的认证目的的可用于数据错误检查的校验和和/或其它合适的验证命令（303）。一旦传入的反馈已经被认证（在至少一种情况下会需要返回消息），VCS随后就可开始发送数据（305）。

在此示意性实施例中，由于VCS可能发送标准的命令或非标准的命令，因此处理将（在这种情况下，在VCS一侧）确定正被发送的短语、命令或数据元素是标准的还是非标准的（307）。如果词语是标准的词语/短语/元素，则处理将说出标准的词语（315）并且用信号通知词语或短语的结束（317）。在某些情况下，如果接收处理知道VCS何时结束说话，则所述处理可不必用信号通知词语或短语的结束。

在说出的短语并非标准的情况下，处理可将词语分解成独立的元素（例如而并非限制，字母和/或数字）（309）。例如，如果词语为“Nicole Ct.”，则处理可将词语分解为n-i-c-o-l-e<space>c-t并且随后用信号通知服务器词语或短语将被传入（311）。所述信号可以是仅仅指示流可能传入的简单信号，或者所述信号可包括例如指示预期多少字母/字符的一些标记（因此服务器得知数据何时完成）。一旦信号被发送，处理将说出字符（313），从而服务器可处理传入的非标准短语。

在此示例中，处理可具有将在一些初始发送完成后发送的额外的数据。如果这是319的情况，则处理可继续并且从VCS至服务器的额外的信息的通信可继续。如果没有更多的数据要发送，则处理可确定是否预期响应（321）。如果并不预期响应，则处理可结束发送（327）。

如果预期响应，例如，如果正在进行对话数据传输会话，则处理将等待从服务器接收响应（323）。随后，如果需要进一步的发送，则处理可发送继续对话所需要的信息（325）。否则，如果已经完成全部发送，则处理可结束。

图4示出消息队列会话示例。由于在此示例中将使用操作者的语音计划、中断呼叫能力并且可能使用通话计划时长来传输数据，因此可期望将非即时发送放入队列以便在一个有效负载中传递，或者例如在经过一定的时间后发送，从而不使用计划时长。

虽然特定的数据（例如方向请求）可能期望立即传输，但是可将诸如车辆统计信息或程序数据的其它信息推迟到可便宜地建立信道的时间。。在另一示例中，可保留数据直累积了整一分钟的数据包，使得分钟使用被优化，或者使用至少一些近似于此的方案（例如而并非限制，允许数据包延迟50秒）。

在此示意性示例中，处理将准备传输至服务器的消息（401）。所述准备可包括但不限于收集数据、确定非标准词语、确定发送长度和任何其它合适的准备。由于可能期望立即传输特定消息（403），因此处理可使用连接的电话来立即将那些信息传输至远程服务器（411）。然而在其他情况下，诸如但不限于上述情况，处理可将消息放入队列（405）。一旦消息已经排队，处理就可确定队列是否已满（407）（或者在其他情况下，根据其它原因确定是否适于发送）。

如果由于合适或者例如满消息队列而期望进行发送，则处理可封装用于发送的队列消息（409）并且进行发送（411）。如果由于某些原因而终止发送，则可保持队列以便在稍后的时间发送。某些消息可能仅仅在进行相同行程的情形下具有用处，并且如果例如由于没有可接受的发送条件的情况而在没有传输这些消息的情况下完成行程，则处理可在行程结束时从队列中去除这些消息。在其他情况下，可保留消息以便稍后在合适的时间发送。

图5示出警报发送的示例。这只是可涉及使用在此描述的示意性实施例的发送的一个示例。在这种情况下，可由于车辆安全***的激活而传输警报。在此示例中，处理开启语音呼叫（501）。由于袭击者可能不将电话连接至***来进行传输，因此可利用包括在车辆中的硬接线的电话来发送警报消息。

在这种情况下，处理发送例如“静音警报”的命令（503）。该命令可向远程服务器指示车辆已经被盗并且通知服务器期待与车辆相关的额外信息。在这种情况下，处理将说出例如车辆识别码（VIN）（505）。可将VIN预编程在每个车辆的处理中或者例如可从***总线检索VIN。

另外，由于该通信与被盗的车辆相关，因此处理可包括诸如车辆的当前GPS位置的信息（509）。在此示例中，在说出实际坐标（507）之前说出词语“GPS位置”，因此服务器知道GPS坐标将传入。在警报呼叫正在进行的同时，可将当前基础上可能有用的信息（诸如GPS信息）重复数次，从而可对车辆进行准确跟踪。

此外，在此实施例中，处理可将与紧急联系人相关的信息发送至服务器。这可帮助当局追查车辆拥有者，并且将提醒车辆拥有者和/或紧急联系人。在此示例中，处理说出车辆拥有者或紧急联系人的地址（511）。另外，处理还将说出可能有用的联系人信息（513）。

尽管未显示，但远程服务器随后可联系车辆拥有者和/或在具有任何相关信息的情况下联系紧急联系人。此联系可提醒车辆拥有者或紧急联系人，从而避免误报和/或允许所有者或联系人跟进实际上被盗的车辆。

图6示出交通方向信息（TDI）会话的示意性示例。这是利用此处所详述的示意性实施例来执行的处理的另一示意性示例。在此示意性实施例中，处理在建立与远程服务器的通信后，可说出协议版本（601）。如果有方向请求和信息的不同的版本，则处理所使用的协议可通知服务器关于将使用哪个版本。在此示例中，一旦建立了协议，处理说出服务类型，在这种情况下服务类型即为与方向相关的命令（603）。

在建立了导航会话后，处理说出车辆纬度（605）和车辆经度（607），以帮助导航规划辅助车辆。所述信息与被说出的车辆行驶方向（609）和车辆速度（611）结合，允许远程服务器得知车辆目前位于哪里。此外，在方向被传回车辆之时，所述信息对于估计车辆将位于哪里会是有用的。

随后对远程服务器说出目的地（613），该远程服务器可使用所述目的地来建立用于发送至驾驶者的路径。处理随后可等待从远程服务器传入的指令（615）以及与这些传入的指令相关的任何数据（617）。

尽管上面描述了示例性实施例，但并不意图这些实施例描述本发明的所有可能形式。相反，说明书中使用的词语为描述性词语而非限制，并且应理解，可在不脱离本发明的精神和范围的情况下做出各种改变。此外，可组合各种执行实施例的特征以形成本发明进一步的实施例。

Claims (10)

1.一种***，包括：

一种处理器，被构造为：

通过无线电话与处理器进行通信而建立的连接，经由语音呼叫与远程服务器进行通信，

使用说出的、基于人类语言的通信来通过语音信道传送和接收数据和指令，

利用标准化语音来动态地形成、发送和解释命令和数据，所述命令和数据包括预定义的***命令和与一个或多个***命令相关的由用户动态地输入的变量两者。

2.如权利要求1所述的***，其中，至少一个命令与导航请求相关。

3.如权利要求2所述的***，其中，至少一个用户输入的变量包括地址。

4.如权利要求3所述的***，其中，处理器还被构造为将用户输入的地址分解为单独的字符并且单独说出所述字符从而形成用户输入的地址。

5.如权利要求1所述的***，其中，至少一个命令与警报通知相关。

6.如权利要求1所述的***，其中，处理器还被构造为发送安全验证信息。

7.如权利要求1所述的***，其中，处理器还被构造为将多个用于发送的命令以及附随的数据放入队列，并且当满足一个或多个队列发送条件时发送所述命令。

8.如权利要求7所述的***，其中，所述一个或多个条件包括满队列。

9.如权利要求7所述的***，其中，所述一个或多个条件包括一天中的与电话所有者的通话时长为不受限制的使用时长相应的时间。

10.如权利要求7所述的***，其中，所述一个或多个条件包括整一分钟或多分钟的预定义容限中的估计队列发送时间。

Images