CN101589427A

CN101589427A - 语音应用程序装备和记入

Info

Publication number: CN101589427A
Application number: CNA200680021784XA
Authority: CN
Inventors: S·F·波特
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-06-30
Filing date: 2006-06-07
Publication date: 2009-11-25
Also published as: EP1899851A2; MX2007015186A; US20070006082A1; WO2007005185A2; WO2007005185A3; EP1899851A4; JP2009500722A; KR20080040644A

Abstract

根据任务来定义语音启用应用程序。由于执行了该语音启用应用程序，指示任务完成的信息和/或与回合数据相关的信息相对于任务是可记录的。

Description

语音应用程序装备和记入

背景技术

以下讨论仅为了提供概括的背景信息，并非旨在用作协助确定所作权利要求的主题的范围。

人们在日常活动中越来越多地使用诸如个人数字助理(PDA)的小型计算设备、设备和便携式电话。随着现在微处理器可用于运行这些设备的处理能力的增加，这些设备的功能也在增加，并且在某些情况下结合。例如，现在许多可携带电话可用于访问和浏览因特网，以及可用于存储诸如地址、电话号码等个人信息。

由于使用这些计算设备的频率增加，因此需要为用户提供简便的界面用于将信息输入到计算设备中。然而，由于期望将这些设备保持尽可能小以便于携带它们，将字母表的所有字母作为独立按键的常规键盘一般是不可能的，因为计算设备外壳上可用的有限表面区域。即使不说小型计算设备的示例，存在对于为所有类型的计算设备提供更为便利的表面的兴趣。

为了解决这个问题，对于使用声音或语音来无论在本地计算设备上，通过局域网还是通过诸如因特网的广域网访问信息越来越感兴趣并且得到越来越多的采用。使用语音识别，对话交互通常在用户和计算设备之间实施。用户一般音频地和/或视频地接收信息，而音频地响应以提示或发出命令。然而，通常期望在开发期间或运用应用程序之后确定其性能。具体地，期望确定用户对应用程序的使用和/或成功率。有了这样的信息，开发者会能够对应用程序进行“调整”(即作出调节)以便于更好地满足应用程序的用户的需要。例如，标识出应用程序和用户的对话中最可能发生问题的部分会是有用的。这样，对话的这些部分可以被调节以减少混淆。

记录或记入应用程序和用户之间的交互数据用于测量应用程序的性能。然而，一般地，记入应用程序交互数据会遭受以下缺陷中的任何一个或其组合，例如：(1)产生数据是麻烦的，即应用程序开发者必须在代码中的各个位置装备(即，定义和实施用于记入***数据的一组消息)应用程序，用于获取正确的数据以供分析和调整；(2)装备过程一般用特定于应用程序的方式完成，且在不同的应用程序之间不可移动；以及(3)交互日志数据是有限的值，除非应用手动抄写处理(和/或其他明确的人为干涉)，这注释了用户意向的带有较为丰富的信息的数据。

发明内容

提供本概述用于以简化的形式引入一些概念，这在以下具体实施方式中将做进一步的描述。本概述并非旨在所作权利要去的主题的关键特征和基本特征，它也并非旨在用作有助于确定所作权利要求的主题的范围。

根据任务来定义语音启用应用程序。由于执行了语音启用应用程序，指示完成任务的信息和/或与回合数据相关的信息相对于任务是可记录的。

指示完成任务的信息被称为对话数据。该数据量化完成任务的成功或失败。此外，对话数据可以包括若任务不成功或失败的原因，或者若成功有多种可能的原因则该对话数据可以包括成功的原因。附加数据可以包括用于指示是否用户没有提供响应或者语音识别器不能识别出该表达的进展数据。也可以记录输入字段值的列表或者其经改变的状况。

回合数据包括与应用程序的直接交互，并且基于应用程序提供的提示或者基于与用户响应或缺少这种响应相关的应用程序提示换言之即基于提示/响应交换，来组织(当不期望响应时)。相应地，可记录的三种数据范围包括：与应用程序提供的提示相关的信息，其中包括提示目的；用户提供的响应，其中包括响应目的；以及***确定的识别结果。

附图说明

图1是计算设备操作环境的第一实施例的平面图。

图2是图1的计算设备的框图。

图3是通用计算机的框图。

图4是客户机/服务器***的体系结果的框图。

图5是示出用客户端标记提供识别和音频提示的方法的框图。

图6是示出联合控件的框图。

图7是创建语音启用应用程序的方法的流程图。

图8是执行语音启用应用程序的方法的流程图。

具体实施方式

在描述语音应用程序装备和记入以及用于实现它们的方法之前，概括地描述可用在语音应用程序中的计算设备会是有用的。现在参考图1，在30处示出了数据管理设备的示例性形式(PIM、PDA等)。然而，期望在本申请中所描述的概念也可以使用以下讨论的其他计算设备来实现，具体地，那些具有有限表面区域用于输入按钮的计算设备等。例如，电话和/或数据管理设备也可以得益于本申请中所描述的概念。相对于现有的便携式个人信息管理设备和其他便携式电子设备，这种设备具有增强的用途，且这种设备的功能和小型尺寸更有可能促进用户一直携带设备。相应地，并非旨在将此处所描述的本申请的范围受限于示例性数据管理或本申请所示的PIM设备、电话或计算机的公开。

数据管理移动设备30的示例性形式在图1中示出。移动设备30包括外壳32并具有包括显示器34的用户界面，它使用触敏显示屏幕结合书写笔33。书写笔33用于在指定的坐标处按下或接触显示器34以选择区域，或选择性地移动指针的开始位置，或者否则的话诸如通过手势或手写提供命令信息。或者或此外，一个或多个按钮35可以包括在设备30上以供导航。此外，也可以提供诸如滚轮、滚筒等其他输入机制。然而，应该注意本发明并非旨在受限于这些输入机制的形式。例如，另一种输入形式可以包括诸如通过计算机视觉的视频输入。

现在参考图2，框图示出了包括移动设备30的功能组件。中央处理但愿(CPU)50实现软件控制功能。CPU 50耦合到显示器34使得依照出现在显示器34上的控制软件来生成文本和图形图标。扬声器43可以耦合到CPU 50，该CPU 50通常带有数模转换器59用于提供音频输出。下载或由用户输入到移动设备30的数据存储在非易失性读/写随机存取存储器存储54中，该存储双向地耦合到CPU 50上。随机存取存储器(RAM)54提供对由CPU 50执行的指令的易失性存储，以及对诸如寄存器值等临时数据的存储。配置选项和其他变量的默认值存储在只读存储器(ROM)58中。ROM 58也可用于存储设备的操作***软件，用于控制移动设备30的基本功能以及其他操作***内核功能(例如将软件组件载入到RAM 54中)。

RAM 54也以类似于用PC上于存储应用程序的硬盘的功能用作代码的存储器。应该注意虽然非易失性存储器用于存储代码，但是可选地它也可以存储在不是用于代码执行的易失性存储器中。

无线信号可以通过耦合到CPU 50的无线收发机52由移动设备来发送/接收。也可以提供可选的通信接口60用于直接从计算机(例如台式计算机)或从有线网络(如果期望的话)下载数据。相应地，接口60可以包括各种形式的通信设备，例如红外线链接、调制解调器、网卡等。

移动设备30包括麦克风29以及模数(A/D)转换器37以及存储在存储器54中的可选的识别程序(语音、DTMF、手写、手势或计算机视觉)。通过示例，响应来自设备30的用户的音频信息、指令或命令，麦克风29提供语音信号，它由A/D转换器37数字化。语音识别程序可以对数字化语音信号执行标准化和/或特征提取功能，用于获取中间的语音识别结果。使用无线收发机52或通信接口60，语音数据可以发送给以下讨论的远程识别服务器204，并在图4的提示结构中示出。接着可以将识别结果返回给以供设备，用于在其上呈现(例如视频和/或音频)，并最后传送给网络服务器202(图4)，其中网络服务器202和移动设备30以客户机/服务器关系运作。类似的处理可用于其他形式的输入。例如，手写输入可以在设备上数字化，不管有无预先处理。如同语音数据，这种形式的数据可以发送给识别服务器204用于识别，其中识别结果接着被返回给设备30和/或网络服务器202中的至少一个。同样地，DTMP数据、手势数据和视频数据可以作类似的处理。取决于输入的形式，设备30(以及以下讨论的其他形式的客户机)会包括诸如摄像机等必要的硬件用于视频输入。

除了上述的便携式或移动计算设备之外，也应该理解本申请中所描述的概念可以用于诸如通用台式计算机的许多其他机算设备。例如，当诸如全文字数字键盘难以操作时，具有有限物理能力的用户可以将文本输入计算机或其他计算设备。

本发明也可用于许多其他通用或专用计算***、环境或配置。适用于本发明的公知的计算设备、环境和/或配置的示例包括，但不限于，无线或蜂窝电话、常规电话(没有任何屏幕)、个人计算机、服务器计算机、手持式或膝上型设备、多处理器***、基于多处理器的***、机顶盒、可编程消费电子设备、网络PC、微型机、大型机、包括任何上述***或设备的分布式计算环境等。

以下是对图3所示的通用计算机120的简要描述。然而，计算机120也仅是合适的计算环境的一个示例，并非旨在提出对本发明的使用和功能范围的任何限制。计算机120也不应被解释为对以下其中所示组件的任何一个或组合具有任何依赖或要求。

以下描述可以在由计算机执行的诸如程序模块的计算机可执行指令的一般语境中提供。一般而言，程序模块包括执行特定任务或实现具体抽象数据类型的例程、程序、对象、组件、数据结构等。本申请中所描述的示例性实施例可以在分布式计算环境中实现，其中由通过通信网络链接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以同时位于包括存储器存储设备的本地和远程计算机存储介质中。借助附图，以下描述了程序和模块执行的任务。本领域的技术人员可以将描述和附图实现为处理器可执行指令，所述指令可以写在任何形式的计算机可读介质上。

参照图3，计算机120的组件可包括，但不限于，处理单元140、***存储器150以及将包括***存储器在内的各种***组件耦合到处理单元140的***总线141。***总线141可能是若干总线结构类型中的任何一种，包括存储器总线或存储器控制器、***总线、以及使用多种总线体系结构的任一种的局部总线。作为示例，而非限制，这些体系结构包括工业标准体系结构(ISA)总线、通用串行总线(USB)、微信道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线和***部件互连(PCI)总线(也称为Mezzanine总线)。计算机120通常包括各种计算机可读介质。计算机可读介质可以是能被计算机120访问的任何可用介质，并包括易失性和非易失性介质、可移动和不可移动介质。作为示例，而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以任何方法或技术实现、用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的易失性和非易失性介质、可移动和不可移动介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD ROM、数字化多功能光盘(DVD)或其它光盘存储器、磁盒、磁带、磁盘存储器或其它磁性存储设备、或任何其它可用于存储所需信息并可由计算机120访问的介质。

通信介质通常在诸如载波或其它传输机制的已调制数据信号中体现为计算机可读指令、数据结构、程序模块、或其它数据，且包括任何信息输送介质。术语“已调制数据信号”意指以在信号中编码信息的方式设置或改变其一个或多个特征的信号。作为示例，而非限制，通信介质包括诸如有线网络或直线连接的有线介质，和诸如声学、射频(RF)、红外线和其它无线介质的无线介质。以上任何介质的组合也应包括在计算机可读介质的范围中。

***存储器150包括诸如只读存储器(ROM)151和随机存取存储器(RAM)152的易失性和/或非易失性存储器形式的计算机存储介质。包含有助于如起动时在计算机120内元件间传送信息的基本例程的基本输入/输出***(BIOS)153通常存储在ROM 151中。RAM 152通常包含可被处理单元140立即访问和/或当时正***作的数据和/或程序模块。作为示例，而非限制，图3示出了操作***154、应用程序155、其它程序模块156、和程序数据157。

计算机120还可包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅作为示例，图3示出了读取和写入不可移动、非易失性磁性介质的硬盘驱动器161，读取和写入可移动、非易失性磁盘172的磁盘驱动器171，读取和写入可移动、非易失性光盘176，诸如CD-ROM或其它光学介质的光盘驱动器175。其它也在示例性操作环境中使用的可移动/不可移动、易失性/非易失性计算机存储介质包括，但不限于，如磁带盒、闪存卡、数字化多功能光盘、数字化录像带、固态RAM、固态ROM等等。硬盘驱动器161通常通过诸如接口160的不可移动存储器接口与***总线141连接，而磁盘驱动器171和光盘驱动器175通常通过诸如接口170的可移动存储器接口与***总线141连接。

如上所述并如图3所示的驱动器及其相关联的计算机存储介质为计算机120提供计算机可读指令、数据结构、程序模块、和其它数据的存储。在图3中，例如，硬盘驱动器161被示为存储操作***164、应用程序165、其它程序模块166、和程序数据167。注意这些组件可以与操作***154、应用程序155、其它程序模块156、和程序数据157相同或不同。在此给予操作***164、应用程序165、其它程序模块166、和程序数据167的不同编号至少说明它们是不同的副本。

用户可通过诸如键盘182、麦克风183、以及诸如鼠标、跟踪球或触摸板等的定位装置181的输入设备向计算机120输入命令和信息。其它输入装置(未示出)可包括游戏杆、游戏垫、卫星接收天线、扫描仪等等。这些和其它输入设备常常通过与***总线耦合的用户输入接口180与处理单元140相连，但也可通过诸如并行端口、游戏端口或通用串行总线(USB)的其它接口和总线结构连接。监视器184或其它类型的显示设备也可通过诸如视频接口185的接口与***总线141相连。除监视器以外，计算机还可包括诸如麦克风187和打印机186的其它***输出设备，它们通过输出***接口188相连。

计算机120可以在使用与一台或多台远程计算机，诸如远程计算机194的逻辑连接的网络化环境中运行。远程计算机194可以是个人计算机、服务器、路由器、网络PC、对等装置或其它公共网络节点，而且通常包括上述与个人计算机120相关的许多或全部组件。图3中所描绘的逻辑连接包括局域网(LAN)191和广域网(WAN)193，但也可包括其它网络。这样的网络化环境在办公室、企业范围计算机网络、内联网和因特网上是常见的。

当用于LAN网络化环境中时，计算机120通过网络接口或适配器190与LAN191连接。当用于WAN网络化环境中时，计算机110通常包括调制解调器192或其它用于在诸如因特网的广域网193中建立通信的装置。可以是内置式或外置式的调制解调器192与***总线141通过用户输入接口180或其它适当机制连接。在网络化环境中，与计算机120相关的程序模块或其一部分可存储在远程存储器存储装置中。作为示例，而非限制，图3示出了驻留于远程计算机194中的远程应用程序195。应当理解，所示网络连接是示例性的，且也可以使用其它用于在计算机间建立通信连接的方法。

示例性实施例

图4示出了可以使用本申请所描述的概念的基于网络识别(这里例示为广域网)的体系结构200。然而，应该理解与远程组件的交互仅是一个实施例，因为包括识别器的语音应用程序可以用在具有这里所示的所有必须组件或模块的单个计算设备上。

一般地，存储在网络服务器202上的信息可以通过移动设备(在本申请中也表示具有根据输入形式所要求的显示器屏幕、麦克风、摄像机、触敏面板等其他形式的计算设备)或通过电话80来访问，在后一情况中，音频地或通过电话30生成的语调来请求信息，以响应按下的键，且其中来自网络服务器202的信息仅音频地提供回给用户。

在该示例性实施例中，无论信息是通过设备30还是使用语音识别的电话80获取的，体系结构200是统一的，单个识别服务器204可以支持任一操作模式。此外，体系结构200使用公知的标记语言(例如HTML、XHTML、cHTML、XML、WML等)的扩展来运作的。因此，存储在网络服务器202上的信息也可以使用在这些标记语言中发现的公知的GUI方法来访问。通过使用公知的标记语言的扩展，在网络服务器202上编辑变得简便，并且也可以方便地现有的遗留应用程序以包括语音或其他形式的识别。

一般地，设备30执行由网络服务器202提供的HTML+、脚本等。当需要语音识别时，举例而言，语音数据，可以是数字化的音频信号或者语音特征，其中如上所述音频信号由设备30作出了预先处理，被提供给识别服务器204，并带有在语音识别期间使用的语法或语言模型的指示。识别服务器204的实现可以采取多种形式，示出其中一种，但一般地包括识别器211。识别的结果被提供回设备30以用于本地呈现(如果期望或适当)。在通过识别和任何图形用户接口(如果使用)编译信息时，设备30将信息发送给服务器202以供进一步处理和接收进一步HTML脚本(如果需要)。

如图4所示，设备30、网络服务器202和识别服务器204一般地连接，并且通过网络205分别地可寻址，所述网络205在这里为诸如因特网的广域网。因此无需将任何这些设备在物理上置于彼此邻近的位置。具体地，网络服务器202无需包括识别服务器204。这样，网络服务器202上的编辑可以集中在它所想要的应用程序上，而作者无需知道识别服务器204的复杂性。识别服务器204而是可以被独立的设计并连接到网络205，并由此无需在网络服务器202处的进一步改变来更新和改进。如下所述，网络服务器202也可以包括可以动态地生成客户机端标记和脚本的编辑机制。在另一实施例中，网络服务器202、识别服务器204和客户机30可以根据实现机器的性能来组合。例如，如果客户机包括通用计算机，例如个人计算机，客户机可以包括识别服务器204。同样，如果期望，网络服务器202和识别服务器204可以被合并到单个机器中。

通过电话80访问网络服务器202包括将电话80连接到有线或无线电话网络208，接着将电话80连接到第三方网关210。网关210将电话80连接到电话语音浏览器212。电话语音浏览器212包括提供电话接口和语音浏览器216的媒体服务器214。与设备30一样，电话语音浏览器212从网络服务器202接收HTML脚本等。在一个实施例中，HTML脚本是与提供给设备30的HTML脚本类似的形式。这样，网络服务器202无需分别支持设备30和电话80，或者甚至分别支持标准GUI客户机。而是可以使用通用标记语言。此外，与设备30一样，通过网络205或通过专用线207例如使用TCP/IP将来自从语音浏览器216处将电话80发送的音频信号的语音识别提供给识别服务器204。网络服务器202、识别服务器204和电话语音浏览器212可以包含在任何适当的计算环境中，诸如图3所示的通用台式计算机。

然而，应该注意如果采用DTMF识别，这种识别的形式通常在媒体服务器214而非识别服务器204处执行。换而言之，DTMF语法会由媒体服务器214使用。

再参考图4，网络服务器202可以包括服务器端插件编辑工具或模块209(例如ASP、ASP+、微软公司的ASP.Net、JSP、Javabeans等)。服务器端内插模块209可以动态地生成客户机端标记，甚至是用于访问网络服务器202的客户机的类型的标记的特定形式。可以再客户机/服务器管理初始建立时，将客户机信息提供给网络服务器202，或者网络服务器202可以包括用于检测客户机设备的性能的模块或例程。这样，服务器端插件模块208可以为每个语音识别情况(即设备30仅通过麦克风的或多种形式的语音)生成客户机端标记。通过使用一致的客户机端模型，可以较大地简化许多不同客户端的应用编辑。

除了动态地生成客户机端标记之外，下述的高级对话模块可以被实现为存储在存储211中的服务器端控件，以供开发者用于应用编辑。一般地，高级对话模块211可以基于开发者所指定的参数动态地生成仅语音和多形式情况的客户机端标记和脚本。高级对话模块211可以包括参数，用于生成客户机端标记以符合开发者的需求。

客户机端标记的生成

如上所述，当从客户机设备30作出请求时，服务器端插件模块209输出客户机端标记。简而言之，服务器端插件模块209允许网站、由此应用程序和应用程序提供的服务被定义或构建。客户端插件模块209中的指令由编译代码组成。当网络请求到达网络服务器202时运新代码。服务器端插件模块209接着输出要发送给客户机端设备30的新的客户机端标记页面。如所公知的，这个过程通常称为呈现。服务器端插件模块209对提取和封装标记语言及由此客客户机端标记页面的代码的“控件”进行操作。这种提取和封装标记语言并在网络服务器202上操作的控件包括或等价于“小服务程序”或“服务器端插件”等。

如所知的，现有技术的服务器端插件模块可以生成客户机端标记用于视频呈现和与客户机设备30交互。于2004年6月17日发布的美国专利申请公开号US 2004/0113908，题为“Web Server Controls for Web Enabled Recognitionand/or Audible Prompting(用于启用网络识别和/或音频提示的网络服务器控件”和于2004年11月18日发布的美国专利申请公开号US 2004/0230637A1，题为“Application Controls for Speech Enabled Recognition(用于启用语音识别的应用程序控件)”都详细描述了三种不同的方法，用于将服务器端插件模块209扩展成包括识别和音频提示扩展。虽然本发明的各方面可以用于所有这些方法的，以下将提供一种方法的简要描述用于解释示例性实施例。

参考图5，识别/音频提示控件306与视频控件302分离，但是被选择性地与之关联，如下所述。这样，控件306不会直接在视频控件302上构建，而是提供识别/音频提示允许，而无需重写视频控件302。如控件302的控件306使用库300。在该实施例中，库300包括视频和识别/音频提示标记信息。

这种方法具有重要的优势。首先，无需改变视频控件302的内容。第二，控件306可以形成单个模块，所述单个模块是一致的且无需依照启用语音的控件302的性质来改变。第三，语音启用过程，即明确地将控件306与视频控件302相关联，在设计时完全在开发者的控制之下，因为它是明确的和选择性的过程。这也使得视频控件的标记语言从诸如通过控件306生成的标记语言提供的识别或通过诸如键盘的常规输入设备的多个源接收输入值变得可能。简而言之，控件306可以被添加到服务器端插件模块209的视频标记页面的现有应用程序编辑页面中。控件36为客户机设备30的用户提供了新的形式的交互(即识别和/或音频提示)，而同时重新使用视频控件的应用程序逻辑和视频输入/输出性能。考虑到控件306可以与视频控件306相关联，视频控件306处应用程序逻辑可以被编码，下文中可以将控件306称为“联合控件306”，而可以将视频控件302称为“主控件302”。应该注意这些称谓仅是为了区分控件302和306而提供的，而非旨在用于限制。例如，联合控件306可以用于开发或编辑不包括视频呈现的网站，诸如仅音频的网站。在这种情况下，某些应用程序逻辑可以包含在联合控件逻辑中。

在图6中示出了示例性联合控件400组。在该实施例中，联合控件400一般包括QA控件402、命令控件404、比较验证器控件406、定制验证器控件408和语义图410。语义图410图表地示出，并包括认作为输入字段的语义项412，在视频域主控件402(例如HTML)和联合控件400的非视频识别域之间建立层。

QA控件402包括提示特性，使得提示控件执行输出控件的功能，即为人为对话提供“提示”客户机端标记，通常涉及预先录制的音频文件的播放，或用于文本-语音转换的文本，直接包括在标记中或经由URL引用的数据。同样地，输入控件具体化为QA控件402和命令控件404，也跟随人为对话，并包括提示特性(引用提示对象)和回答特性(引用至少一个回答对象)。QA控件402和命令控件404都将语法与来自客户机设备30的期望或可能的用户输入相关联。

此时，提供每个控件的简短描述会是有用的。

一般地，QA控件402通过所示的特性可以执行以下功能中的一个或多个：提供输出音频提示、收集输入数据、执行输入结果的可信度验证、允许确认输入数据以及协助控制网站处的对话流等。换而言之，QA控件402包含用作特定主题的控件的特性。

与其他控件一样，QA控件402在网络服务器202上执行，这意味着它是使用服务器端的标记形式(ASP、JSP等)在网站服务器所持有的应用程序开发网页上定义的，但是作为标记的不同形式输出到客户机设备30上。虽然在图6中示出，其中似乎QA控件是由所有的特性Prompt(提示)、Reco(记录)、Answer(回答)、ExtraAnswer(额外回答)和Confirm(确认)组成的，应该理解这些仅是选项，QA控件可以包括其中的一个或几个。

此时，根据应用程序情况来解释QA控件的使用会是有帮助的。参考图6和仅语音应用程序中，QA控件402可以用作对话中的问题和答案。问题可以由提示对象提供，而通过语法对象来定义语法，用于识别输入数据核对该输入的相关处理。回答特性使用回答对象将识别处的结果与语义图410中的语义项412相关联，它包含如何处理识别结果的信息。线414表示将QA控件402与语义图410及其上的语义项412相关联。许多语义项412个别地与视频或主控件302相关联，如线418所示，虽然一个或多个语义项412不会于视频控件相关联并且仅内部使用。在多种形式情况下，其中客户机设备30的用户会触及视频文本框，例如与“TapEvent”，视频提示不是必须的。例如，对于主控件包含具有视频文本的文本框，视频文本形成客户机设备的用户应该将什么输入响应的字段的指示的情况，相应的QA控件402可以有或没有诸如音频回放或文本-语音转换的相应提示，但会具有对应于期望值的语法用于识别，以及事件处理器，用于处理输入或处理诸如检测到的语音、未识别出的语音的其他识别器事件或在暂停时间发射的事件。

在另一实施例中，识别结果包括指示所识别出的结果是正确的可信度的可信度评估。也可以在回答对象中指定确认阀值，例如可信度阀值等于0.7。如果可信度高于相关联的阀值，就认为结果被确认。

也应该注意，此外或或者，为了指定语音识别的语法，QA控件和/或命令控件可以响应提示或问题来指定Dtmf(双音频调制频率)语法以识别电话键的激活。

此时，应该注意当填入语义图410的语义项412时，通过例如语音或Dtmf的识别，可采取几种行动。首先，可以发出或发射时间，指示值被“改变”。取决于是否满足可信度，可以发出或发射的另一事件包括指示响应的语义项已被确认的“确认”事件。这些事件用于控制对话。

确认特性也可以包括类似于上述有关回答特性描述的结构的回答对象(其中它与语义项412相关联)，并包括可信度阀值(如果期望)。确认特性并不旨在按照每个语义项来获取识别结果，而是确认已经获取的结果并从用户处确定所获取的结果是否正确。确认特性时用于表明先前获取的结果的值是否正确的回答对象的集合。包含QA的提示对象会查询这些项，并从相关联的语义项412处获取识别结果，并将其形成为问题，诸如“Did you say Seattle？”。如果用户使用诸如“Yes”的确定来响应，那么就发射确认事件。如果用户使用诸如“No”的否定来响应，就清楚相关联的语义项412。

确认特性也可以在向用户提供确认提示后接收修改。例如，响应确定提示“Did you say Seattle？”，用户用“San Francisco”或“No，San Francisco”来响应，在任一情况下，QA控件接收修改。有了通过回答对象正在确认哪个语义项的信息，就可以将语义项中的值替换成修正的值。也应该注意，如果期望，确认也可以包括在进一步的对信息的提示中，诸如“When did you want to go toSeattle？”，其中***提示包括对“Seattle”的确认以及对于出发时间的进一步提示。客户响应提供对目的地的修正会激活确认特性修正相关联的语义项，而仅有触发日期的提示暗示着对目的地的确认。

ExtraAnswer特性允许应用程序作者指定除了所作出的提示或查询之外用户可能提供的回答对象。例如，如果导向旅行的***提示用户目的城市，但是用户用指示“Seattle tomorrow”来响应，那么就恢复开始时提示用户的回答特性，并由此将目的城市“Seattle”与适当的语义项绑定，而ExtraAnswer特性可以将“Tomorrow”作为接下去的一天(假设***知道当天)来处理，并由此将这个结果与语义图中适当的语义项绑定。ExtraAnswer特性包括为用户也可能声明的可能的额外信息定义的一个或多个回答对象。在上述提供的示例中，也已经获取了出发日期的信息，***于是无需再为了这个信息来提示用户，假设可信度超过相应的可信度阀值。如果可信度没有超过相应的阀值，那么就激活适当的确认特性。

命令控件

命令控件404是通常再仅声音对话中的用户说话，就所提的问题一般具有语义输入，而是寻找协助或实现导航例如帮助、取消、重复等。命令控件404可包括提示特性，用于指定提示对象。此外，命令控件404不仅可用于指定语法(通过语法特性)和对识别相关联的处理(有点类似于没有将结果绑定到语义项的回答对象)，也可用于指定语境的‘范围’和类型。这允许对客户机端标记上全部或语境敏感行为的编辑。命令控件404允许诸如输入的其他类型，诸如“帮助”命令，或者允许客户机设备的用户导航到网站的其他选定区域。

比较验证器控件

比较验证器控件根据算子来比较两个值，并采取适当的动作。要比较的值可以是任何形式的，诸如整数、文本字符串等。比较验证器控件包括指示要验证的语义项的特性SematicItemtoValidate(要验证的语义项)。可用角年个要验证的语义项与常数或另一语义项作比较，其中常数或其他语义项有特性ValuetoCompare(要比较的值)和SematicItemtoValidate分别提供。与比较验证器相关联的其他参数或特性包括用于定义要作的比较的算子和定义值的类型(例如整数或语义项字符串)的类型.

如果与比较验证器控件相关联的验证失败，那么提示特性可以指定可以播放的提示对象，指示用户所获取的结果是错误的。如果在比较时验证失败，那么由SematicItemtoValidate定义的相关联的语义项被指示为空，这样使得***会为了正确的值再提示用户。然而，在错误的值会被用在向用户重复错误值的提示中，不清除语义图中相关联语义项的错误值会是有用的。取决于应用程序作者的期望，可以在相关联的语义项的值改变值时，或者在值已被确定时触发比较验证器控件。

定制验证器控件

定制验证器控件类似于比较验证器控件。特性SematicItemtoValidate指示要验证的语义项，而特性ClientValidationFunction(客户机验证函数)通过相关联的函数或脚本指定定制验证例程。无论验证是否失败，函数会提供布尔值“yes”或“no”，或者其等价。提示特性可以指定提示对象要提供对验证出错或失败的指示。取决于应用程序作者的期望，可以在相关联的语义项的值改变值时，或者在值已被确定时触发定制验证器控件。

控件执行算法

客户机端脚本或模块(本申请中称为“RunSpeech”)被客户机设备用于图6的控件。该脚本的目的是经由逻辑执行对话流，当它在客户机设备30上执行，即当由于该处所包含的值激活了属于控件的标记以供在客户机上执行时在脚本中指定。脚本允许在页面请求之间多个对话回合，由此对于诸如通过电话浏览器216的仅声音对话的控件特别有用。客户机端脚本RunSpeech以循环的方式在客户机设备30上执行，直至提交了完整的表格，或者否则是从客户机设备30请求新的页面。

一般地，在一个实施例中，算法通过输出语音和识别用户输入来生成对话回合。算法的总体逻辑如下地用于仅声音环境(应用于2004年6月17日公开的每个专利申请公开号US 2004/0113908，题为“Web Server Controls for WebEnabled Recognition and/or Audible Prompting”，用于上述未讨论的特性或参数)：

1.以语音索引排序找出第一个活动的(如下所定义的)QA、比较验证器或定制验证器控件。

2.如果没有活动的控件，就提交页面。

3.否则，运行控件。

QA在且仅在以下情况下被认为是活动的：

1.QA的ClientActivationFunction(客户机激活函数)或者不存在，或者返回真，并且

2.如果答案属性集合为非空，则回答组所指向的所有语义项的状态为空，或者

3.如果答案属性集合为空，则确认数组中至少一个语义项的状态为NeedsConfirmaiton(需要确认)。

然而，如果QA使得PlayOnce(播放一次)为真，且其提示成功地运行(达到OnComplete(完成))，那QA不会成为激活的候选项。

QA如下运行：

1.如果这是与先前的活动控件不同的控件，那么重置提示计数值。

2.递增提示计数值。

3.如果指定了PromptSelectFunction(提示选择函数)，则呼叫函数并将提示的inlinePrompt(内嵌提示)设置成返回的字符串。

4.如果Reco对象存在，则它开始。该Reco应该已包括任何活动的命令语法。

验证器(比较验证器或定制验证器)是活动的，如果：

1.SemanticItemToValidate还没有被该验证器验证，其值已被改变。

比较验证器如下运行：

1.依照验证器的算子，比较SemanticItemToCompare(要比较的语义项)或ValueToCompare(要比较的值)和SemanticItemToValidate的值。

2.如果测试返回失败，将SemanticItemToValidate的文本字段置空，并播放提示。

3.如果测试返回真，将SemanticItemToValidate标记为境该验证器验证。

定制验证器如下运行：

1.使用SemanticItemToValidate的值来呼叫ClientValidationFunction(客户机验证函数)。

2.如果函数返回错误，则清除语义项并播放提示，否则由该验证器验证。

命令在且仅在以下情况下被认为是活动的：

1.它在范围内，并且

2.在范围树的较低处没有相同类型的另一个命令。

在多种形式的情况下，逻辑被简化为以下算法：

1.等待触发事件-即用户轻拍控件；

2.收集期望回答；

3.监听输入；

4.将结果绑定到语义项，如果没有，则丢弃事件；

5.返回到1。

在多模式环境中，应该注意如果用户修正文本框或者其他与结果的视频表示相关联的的输入字段，则***可以将相关联的语义项更新为指示值已被确定。

在图6中所示的另一实施例中，提供呼叫控件407，使得应用程序作者能够创建处理电话业务的语音应用程序以及应用程序控件430，后者提供了在一种控件中包括各通用语音语境的方法。呼叫控件407和应用程序控件430对于实现本发明不是必须的，仅是为了完整性而提及。对每一个的进一步讨论在2004年6月17日发布的美国专利申请公开号US 2004/0113908，题为“WebServer Controls for Web Enabled Recognition and/or Audible Prompting(用于启用网络识别和/或音频提示的网络服务器控件”和于2004年11月18日发布的美国专利申请公开号US 2004/0230637A1，题为“Application Controls for SpeechEnabled Recognition(用于启用语音识别的应用程序控件)”中讨论。

记录用户交互数据

通过示例，使用上述结构，应用程序开发者能够开发语音启用应用程序。然而，本申请中所描述的各方面允许开发者记录或记入用户交互数据。

然而，应该理解本申请中所描述的各概念不限于上述用于提供对话模式的对话编辑结构，而是可以被应用到生成对话模块的任何编辑工具，诸如但不限于被实现为中间件、API(应用程序编程接口)等的那些，并且被配置成记录一些或全部以下描述的信息。此外，诸如电话应用程序的启用语音应用程序的功能性质和它们语音用户接口的细节可以在域和应用程序类型之间有较大的不同，由此任何启用的自动化记录一般仅是启发式的，而非确定性的。因此，对这个的实现可能是将自动记入事件特性实现为可覆盖默认值，而非不可改变的特性。然而对丰富信息的记入的简化和便利相对于依赖于手动和程序性编辑的***仍然是很大的进步。

在参考图4，由于为任何类型的用户执行应用程序(诸如但不限于经由移动设备30或经由电话80访问)，依照对话控件211执行启用语音应用程序的网络服务器202将用户交互记入数据记录在存储器217中。

一般地，应用程序不是专门定义或写作一组分级控件，这里通常例示为QA控件402结合命令控件404、应用程序控件430、呼叫控件407和验证器406和408，如所需的。分级定义了要完成的总体任务，以及为了完成总体任务的其的次任务。分级中级别的数目取决于应用程序的复杂程度。例如，应用程序可以总体地用于作出机票预定(即最高级的任务)，而两个主要次任务用于获取出发信息和到达信息。同样地，可以为获取出发信息和获取到达信息的主要次任务的每一个定义进一步的次任务，具体地，获取出发/到达机场信息、出发/到达时间等。这些次任务可能出现在它们包含任务的序列中。

一般地，记录两种类型的数据，任务/对话数据和回合数据。从任务/对话数据开始，该数据在日志中表示，应该按照任务和子任务来捕捉应用程序的分级和顺序结构。图7示出了用于创建应用程序的方法。在502处对话编辑工具允许按照嵌套或顺序的任务单元来编辑或定义对话，这样使得当开发者写语音启用应用程序时，作者一般会以模块化的方式写。即，会促使作者将单个会话集合成完成特定任务的集合，并且将单个任务集合成完整较高级别任务的集合。由于在设计时任务结构和进出单个任务的流是已知的，因此在步骤504处，启用对进出任务的入口和出口的记入(例如通过TaskStart(任务开始)和TaskComplete(任务完成)事件)，并且记入从用户处获取的用于由应用程序使用的输入字段的回合数据和值(在本申请中被例示为“语义项”)，用于提供对任务结构的顺序和/或分级的自动记入。这意味着对话流、获取的值和任务结构可以被明确地恢复并且从事件日志构建。应该注意分别示出了步骤502和504仅是为了解释目的，这些步骤的某些和全部特征可以用不同的顺序或同时执行。

这个数据也确定完成任何给定任务或次任务的成功、失败或其他(未知)状况。此外，任务/对话数据包括如果任务不成功或失败的原因，或者它完整状态未知的原因，或者如果适用后续的原因(如果对后续可能有多个原因)。其他数据可以包括指示如果用户没有提供响应或者语音识别器不能识别说话的进程数据。也可以记录输入字段值的列表或应用程序为了基于提示或用户响应或与它们相关联的值使用的存储位置或者其经改变的状态。

图8示出了用于执行语音启用应用程序的方法520。方法520包括在522处执行按照具有一个或多个回合的任务定义的语音启用应用程序。步骤524包括与任务、回合和语义项相关的记录信息。应该注意分别示出了步骤522和524仅是为了解释目的，这些步骤的某些和全部特征可以用不同的顺序或同时执行。

在一个实施例中，任务/对话数据包括所有或全部以下的信息：

任务/对话数据

名称：作者为任务/对话定义的字符串标识符，例如“getCreditCardInfo(获取***信息)”、“ConfirmTravel(确认旅行)”等。如果作者在设计时没有提供名称，就给出默认名称，例如Dialog1、Dialog2、DialogN......

父：包含对话的名称(为了从日志重建对话层级)

TaskStart(任务开始)：首次进入任务/对话时的时间戳

TaskComplete(任务完成)：推出任务/对话时的时间戳。对于任何打开的对话，在使用默认值关闭应用程序时总是应该发射、倒置(bottom-up)该事件(即在日志中不会有“打开-结束”对话)。

状态：任务/对话的完成状态，可由作者设置，基于对话的性能自动推断、或者基于作者定义的条件半自动地设置。在一个实施例中，默认值状态可以时“未设置”，其中后续值可以是以下之一：

成功

失败

未知

自动任务完整状态

在某些情况下，如上所述，可以从任务推出的性质使用合理的确定推断出任务的状态是成功、失败或未知中的哪一个。例如，由于出错或异常而结束的任务可以被自动地记入完成状态或失败。同样地，取消任务(例如其中对任务对象呼叫Cancel()方法)可以自动地记入失败的完成状态。类似地，由于达到了某一“出局”(例如以下讨论的MaxSilence或MaxNoReco)计数结束的任务会自动地记入失败的完成状态。

相反地，带有在该任务中遇到的回合的所有语义项(即应用程序的输入字段)，或者在设计时指定属于该任务的、具有基础(用户输入或从中获取的)值的自然结束的任务(即没有被取消)会被自动地记入成功的完成状态。

半自动任务完成

任务状态记入的部分自动也是有用的。对于给定的任务，作者可以在步骤502处指定或定义任务成功或失败的一组条件，如果满足，就确定在退出时的任何点上任务的状态。条件可以是程序性的(即foo＝＝’bar’)，或者更有用地，可以将条件简化使得作者只需要为每个任务指定一个或多个语义项(例如为departureCity和arrivalCity提供的值)，当那些语义项具有确定的值时***会自动记入成功，并且可选地，当那些语义项不具有确定的值时记入失败。

这个方面是有用的省时机制，因为它意味着任务状态记入无需在任务的每个推出点上被程序性地编码。而是只要最终用户退出任务时就自动地评估条件，并且确定和记入状态而无需额外的开发者代码。

原因：对话完成的原因，可以由作者设置，例如

命令-用户说出的命令，用于改变到对话的不同部分和命令的性质(即“取消”、“算子”“主菜单”等)；

userHangup(用户挂断)-用户挂断，或者用其他方式停止或放弃；

applicationError(应用程序出错)-发生应用程序出错

maxNoReco-达到不带识别的说话的最大次数

maxSilence-达到无声用户响应的最大次数

SemanticUpdate(语义更新)：

项：任何其值/状态有改变的语义项列表，包括新的值和响应的状态。一般地，该数据与以下所述的回合数据相关，其中对于每个对话回合(由应用程序/响应提示或用户对其的缺乏)，语义项值和/或状态中的一个或多个会改变。然而，在某些实例中，应用程序自身能够改变语义项。例如，如果应用程序不能验证诸如******的值，那么它自己可以清除该值，而无需基于对话回合。然而会记录这种改变。

回合数据包括与应用程序的直接交互，并且基于由应用程序提供的提示(当不期望响应时)、或者与用户响应或缺少它相关的应用程序提示来组织，换而言之，提示/响应交换或者用户提供的命令并非必须响应提示，或者至少是不期望是对提示的响应的响应。可以记录数据的三个区域包括与应用程序提供的提示相关的信息、用户提供的响应(可以是期望的或非期望的响应)以及***确定的识别结果。在一个实施例中，回合数据包括以下信息的一些或全部：

回合数据

配置

名称：作者定义的字符串标识符。如果作者在设计时没有提供名称，就给出默认名称；然而需要清楚地和一致地在相同对话/任务中的不同回合之间区分。可能的技术是基于提示的名称和类型。

类型：可以从与之相关联的语义项的性质推断出特定回合的目的的详细说明。在上述情况下，语义项通过回答、额外回答和确认的概念与回合相关联。

回合目的的示例包括：

请求新的确认(回合启用回答)

确认相关信息(接受/拒绝启用回合的确认)

给出信息声明(回合没有回答和确认)。

父：包含对话/任务的名称(为了从日志重建对话层级)。

语言：所使用的语言。

语音语法：与所使用的语音识别语法相关的信息。

DMTF语法：与使用的DMTF识别语法相关的信息。

阀值：用于拒绝值和/或确认值的可信度阀值

超时：允许提示后初始无声和用于确定响应的结束的结束无声时间段，以及认为声音模糊不清的时间段

提示

名称：可选，由于可以使用回合数据名称，可以不是必须的。

类型：对话模式可以包括多个预定义的提示类型，其中任何一个可以由应用程序选择，对它的使用允许记录***试图作什么来达到例如回合的目的。

提示类型的示例包括：

MainPrompt(主提示)-提出问题(或给出声明)

HelpPrompt(帮助提示)-提供帮助

RepeatPrompt(重复提示)-重复信息内容

NoRecognitionPrompt(无识别提示)-响应“无识别”

SilencePrompt(无声提示)-响应无声

EscalatedNoRecognitionPrompt(升级的无识别提示)-在多次尝试后响应“无识别”

EscalatedSilencePrompt(升级的无声提示)-在多次尝试后响应无声由于三种类型是预定义的，且在任何时候可用于选择，它们可以根据类型自动地记入，这自动地丰富了日志数据，使用给定提示的目的的概念达到回合的目的。

因此，提示类型与回合类型相结合-在对话编辑模式中它们都是编程基元，因此当应用程序遇到时被自动地记入-允许在日志中任一点***目的的丰富视图(rich view)。

语义项：提示有关的语义项(用于链接询问/确认循环等)。

对话模式使用语义项的概念，每个含有值和状态，用于简化对话流编辑。通过自动地记入每个语义项的改变值和状态，并将其与任务和用户/***移动信息组合，进一步丰富了日志。

回答/额外回答/确认模型将语义项链接到回合和由此的项。因此所知的是(且可以被自动地记入)，哪个语义项与哪个***移动和哪个用户移动相关，以及哪个有助于哪个任务。

提示的文本内容：例如“welcome(欢迎)”

闯入：提示时间开始/结束/之中

用户感知的等待时间：用户响应和播放下一提示之间的时间段。当***负荷较重时，时间段可能更长，这会使得用户困惑，因为用户可能相信应用程序没有响应。

TTS：真/假-用于生成提示的文本-语音。

提示完成时间：完成/切断提示的时间。

提示波文件：提供的实际提示。

用户输入：

模式：用户是否提供DTMF/语音

类型：用户是否提供命令，如果是，是什么类型的(例如帮助/重复等)，或者用户是否提供响应，如果是，是什么类型(答案/确认/拒绝)

对话模式将应用程序的语法的功能分类到不同类型的用户响应，即回答、接受、拒绝等，所述不同类型的用户响应指示用户提供响应的目的。这些类型可以直接被记入为***任务用户正试图完成事件的指示符。不同响应类型的示例如下：

回答-用户向请求值的问题提供回答。

额外回答-用户提供问题焦点之外的回答。

接受-用户确认信息。

拒绝-用户拒绝信息。

帮助命令-用户请求帮助。

重复命令-用户请求信息的重复。

其他命令-用户发出某些其他形式的命令(没有明确地归类，但是我们知道它不是任一上述类型)。

无声-用户没有说话(这有时被用作‘暗示接受’的形式)

由于这些类型与特定的语法相关联，只要用户说出任何与相应语法匹配的话，就可以自动地记入它们。许多***允许单个对话回合包括多种形式-例如在单个回合中接受多于一个项，或者回答一个项和接收另一个。

无声：如果检测到无声，相对于MaxSilence(最大无声)它是哪个数字或计数。

NoReco：如果没有检测到说话的识别，相对于MaxNoReco它是哪个数字或计数。

出错：如果发生出错，它是否会被应用程序或平台丢弃。

结果：

识别结果：***返回识别结果。通常，识别结果包括语义标记语言(SML)标签，用于经翻译的说话。此外，在适合的地方可以提供N-Best可选翻译和音频记录结果。

除了每个翻译之外：

没有SML标签的说话文本(如果提供语音)或者按键(如果提供DTMF)。

可信度：翻译的可信度。

语义映射：SML结果和语义项部分之间的链接。换而言之，来自SML结果中的哪个值会被置于哪个语义项中。

语法规则匹配：用户输入匹配语法中的哪条规则。

可信度：说话总体。

闯入：用户闯入的事件或空(如果没有出现闯入)。

识别波文件：实际记录的用户输入和指向它的指针。

总之，记入的用户交互数据允许将对话看作在感兴趣的某些字段中操作的任务的分级或顺序结构(例如形式字段或槽值)，并且任务中的每个对话回合记入有关形式字段(例如询问值、确认它、重复它等)的***目的(对话移动)以及语音识别器认为是用户目的的内容(例如提供值、拒绝它、寻求帮助等)。

使用该结构来实现实践优势。具体地，对***性能的分析得到改进，因为任务完成的成功或失败一般是明确的，因此很大地简化了报告的交易成功率，并且能更好地理解完成任务所采取的对话步骤的性质(因为在编辑时每个步骤背后的目的是已知的)。

由于其包含在对话编辑代码中的方式，实现这种形式的数据记入是简便的。这种装备的高级性质对于多种应用程序类型是普遍的，并且记入的实际细节在编辑时通过其集成到编辑工具中而在概念上或关于记入基元变得容易。由此促使应用程序作者使用任务/次任务模型来构造应用程序，并且指示任务之外的哪些转变指示成功完成，且它们无需明确地装备***/用户目的记入，因为那被构建到会话回合编辑模式中。

虽然以上参考特定实施例描述了主题，但是本领域的熟练技术人员应该认识到可以作出改变，其形式和细节不背离所附权利要求的精神和范围。

Claims

1.一种计算机实现方法(520)，用于记入在计算机***上执行的语音启用应用程序中的用户交互数据，所述方法包括：

在所述计算机***上执行根据任务而定义的语音启用应用程序(522)，其中一个任务涉及一个或多个回合，且其中一个回合包括以下中的至少一个：由所述语音启用应用程序提供给所述用户的提示以及提示/响应交换，所述提示/响应交换包括由所述语音启用应用程序提供给所述用户的提示和随后来自所述用户的响应；以及

记录用于指示以下至少两者的信息(524)：(a)在所述应用程序中执行的任务的完成，(b)与各个任务有关的相应回合的目的，以及(c)相对于来自用户的响应的识别而改变的、所述应用程序中所使用的值的指示。

2.如权利要求1所述的计算机实现方法(520)，其特征在于，执行所述语音启用应用程序(522)包括执行其中用分级结构定义任务的语音启用应用程序。

3.如权利要求1所述的计算机实现方法(520)，其特征在于，记录用于指示每个回合的目的的信息(524)包括记录所述回合的目的是否包括所述语音启用应用程序提出问题、确认回答、向用户提供帮助以及重复提示中的至少一种。

4.如权利要求1所述的计算机实现方法(520)，其特征在于，记录与各个任务有关的每一回合的相关信息(524)包括记录有关所述提示与哪个输入字段相关联的信息。

5.如权利要求1所述的计算机实现方法(520)，其特征在于，记录与各个任务有关的每一回合的相关信息(524)包括记录有关所述响应与哪个输入字段相关联的信息。

6.如权利要求1所述的计算机实现方法(520)，其特征在于，记录用于指示每个回合的目的的信息(524)包括记录所述回合的目的是否包括用户提供命令、提供回答、接受确认以及拒绝确认中的至少一种。

7.如权利要求1所述的计算机实现方法(520)，其特征在于，记录与各个任务有关的每一回合的相关信息(524)包括记录与所述语音启用应用程序提供的提示、用户响应于所述提示而提供的响应、以及语音识别器对所述响应的识别结果有关的信息。

8.如权利要求1所述的计算机实现方法(520)，其特征在于，记录用于指示任务完成的信息(524)包括记录用于指示成功、失败或未知的完成状态值之一的信息。

9.如权利要求1所述的计算机实现方法(520)，其特征在于，记录用于指示任务完成的信息(524)包括记录用于指示与任务有关的对话的完成原因的信息。

10.一种计算机可读介质，具有用于创建语音启用应用程序的指令，所述指令包括：

按照计算机***上分级结构中的任务来定义语音启用应用程序(502)；以及

实现用于指示任务完成的信息的记录(504)，所述任务相对于所述分级结构在所述应用程序中执行。

11.如权利要求10所述的计算机可读介质，其特征在于，定义(502)包括定义使用一个或多个回合的任务，其中一个回合包括以下中的至少一个：由所述语音启用应用程序提供给所述用户的提示，以及提示/响应交换，所述提示/响应交换包括由所述语音启用应用程序提供给所述用户的提示和随后来自所述用户的响应，且其中实现信息的记录包括实现用于指示与相应任务有关的一个或多个回合的信息的记录。

12.如权利要求10所述的计算机可读介质，其特征在于，实现与各个任务有关的每一回合的相关信息的记录(504)包括实现用于指示每一回合的目的的信息的记录。

13.如权利要求12所述的计算机可读介质，其特征在于，实现用于指示每一回合的目的的信息的记录(504)包括记录所述回合的目的是否包括所述语音启用应用程序提出问题、确认回答、向所述用户提供帮助、以及重复提示中的至少一种。

14.如权利要求12所述的计算机可读介质，其特征在于，实现用于指示每一回合的目的的信息的记录(504)包括实现记录所述回合的目的是否包括所述用户提供命令、提供回答、接受确认、以及拒绝确认中的至少一种。

15.如权利要求12所述的计算机可读介质，其特征在于，实现关于每一回合的信息的记录(504)包括实现与所述语音启用应用程序提供的提示、用户响应于所述提示而提供的响应、以及语音识别器对所述响应的识别结果有关的信息的记录。

16.如权利要求12所述的计算机可读介质，其特征在于，实现与各个任务有关的每一回合的相关信息的记录(504)包括实现有关所述提示与哪个输入字段相关联的信息的记录。

17.如权利要求12所述的计算机可读介质，其特征在于，实现与各个任务有关的每一回合的相关信息的记录(504)包括实现有关所述响应与哪个输入字段相关联的信息的记录。

18.一种计算机可读介质，具有用于创建语音启用应用程序的指令，所述指令包括：

按照计算机***上的任务来定义语音启用应用程序(502)，其中一个任务涉及一个或多个回合，且其中一个回合包括以下中的至少一个：由所述语音启用应用程序提供给所述用户的提示，以及提示/响应交换，所述提示/响应交换包括由所述语音启用应用程序提供给所述用户的提示和随后来自所述用户的响应；以及

实现在所述语音启用应用程序执行期间用于指示所述一个或多个回合中的每一个回合的用户和***目的、且与下列中的至少一种相关联的信息的记录(504)：(a)在所述应用程序中执行的任务的完成，以及(b)相对于来自用户的响应的识别而改变的所述应用程序中所使用的值的指示。

19.如权利要求18所述的计算机可读介质，其特征在于，实现用于指示任务完成的信息的记录(504)包括实现用于指示成功、失败或未知的完成状态值之一的信息的记录。

20.如权利要求19所述的计算机可读介质，其特征在于，实现信息的记录(504)包括：实现关于提示与哪个输入字段相关联的信息的记录，以及记录关于响应与哪个输入字段相关联的信息。