CN1224894C

CN1224894C - 应用程序对话管理方法与对话管理器和仲裁器接口装置

Info

Publication number: CN1224894C
Application number: CNB028045874A
Authority: CN
Inventors: 丹尼尔·M·考夫曼; 拉法·A·霍斯; 简·克雷蒂斯特; 史蒂芬·H·梅斯; 瑟维尔瓦玛莱·V·拉曼
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-06-29
Filing date: 2002-06-27
Publication date: 2005-10-26
Anticipated expiration: 2022-06-27
Also published as: WO2003003193A1; JP2005503609A; ATE483200T1; IL159565A0; US6839896B2; IL159565A; EP1410171A1; EP1410171A4; EP1410171B1; DE60237825D1; JP3943543B2; US20030005174A1; CN1491382A

Abstract

本发明涉及在多模式和/或多通道环境中通过用于自动对话管理和多个会话应用之间的仲裁的协议提供会话计算的系统和方法，以及支持这种协议的架构。DMAF(会话管理器和仲裁器外观)包括允许在多个应用程序中间，以及各个子对话之间的相同应用程序内进行仲裁的分层DMA体系结构。最高层DMA(30)实例(或根DMA实例或rDMA)在多个应用程序(31、32)之间进行仲裁。每个应用程序(31、32)创建DMA的至少一个实例以管理其主对话。例如，应用程序(31)创建DMA实例(33)，而应用程序(32)创建DMA实例(34)。这些DMA实例(33、34)(或“应用程序DMA实例”或“aDMA”)是最高层DMA实例(30)的“儿子”。可以进一步扩充分层体系结构以创建指定aDMA的新实例(例如在应用程序的子对话内)。例如，产生aDMA(33)的新aDMA实例(35、36)以管理子对话。这些aDMA实例(35、36)是管理应用程序(31)的主对话的aDMA(33)的“儿子”。

Description

应用程序对话管理方法与对话管理器和仲裁器接口装置

技术领域

本发明涉及提供会话计算的系统和方法，尤其涉及在多个会话(多模式)应用程序中间提供对话管理和自动仲裁的协议，和支持该协议的体系结构。

背景技术

计算世界正演变到数十亿互连客户与强力信息服务器通信的时代。实际上，这个千年的特点是可以使用多种信息设备，这些信息设备使普遍的信息访问成为已接受的生活现实。这种向数十亿分散设备通过互联网、无线网络或自发网络(例如蓝牙和Jini)互连的局面的演变彻底变革了人-机交互的基础原理。在不久的将来，个人信息设备会提供普遍的访问，从而使人们具有使用多数适于个人当前需要和能力的交互模式在任何地方和任意时刻产生、操作和交换任何信息的能力。这种设备包含类似的接入设备，例如传统电话、蜂窝电话、智能电话、袖珍管理器、PDA和PCS，并且在被其用来与用户通信的接口外设方面具有广泛的多样性。

信息可用性的增加，以及可被每个用户用来操作这种信息的计算能力的提高相应产生了增加人-机通信带宽的伴随需求。在任意规定时间通过多种设备(均被设计成适合个人的具体需要和能力)访问信息的能力必然意味着这些交互应当挖掘所有可用输入和输出(I/O)模式的潜力，以便最大化人-机通信的带宽。实际上，用户会要求这种多模式交互，以便最大程度地方便其在免手动、免观看环境中与信息设备的交互。

当前的基础设施没有被构造成跨越多种会话应用和架构提供无缝、多模式的访问。实际上，虽然可以使用接入设备通过通信网络从服务器访问极多的信息(例如，专用网络上的的可用个人信息和公司信息，以及可通过诸如互联网的全局计算机网络访问的公共信息)，然而这种信息的可用性会受到用户为得到这种信息而与其交互的客户/接入设备或平台专用软件应用的模式的限制。

然而随着会话系统越来越广泛的应用，必须应对新的技术挑战和限制。例如，即使在支持各种会话应用的共存的当前架构中，在没有大量修改应用程序的编程模型和执行应用程序的平台的情况下，不能实现在所有模式，尤其是带歧义模式(例如语音)上从一个应用程序到另一个应用程序的自然转移。例如，对于从一个应用程序切换到其它应用程序的语音应用程序，需要定义显式(或预建)语法。于是，在不了解平台上已经安装的应用程序的情况下，不能以自动方式执行这种系统中的仲裁。

此外，使用当前技术开发会话应用不仅需要知道应用程序的目标和应当如何定义与用户的交互，而且需要知道各种其它接口和现有应用程序外部的模块，例如(i)到输入和输出设备(电话接口、话筒、Web浏览器、palm导航显示器)的连接；(ii)到各种引擎(语音识别、自然语言理解、语音合成和可能的语言生成)的连接；(iii)资源和网络管理；和(iv)多模式应用程序的各种模式之间的同步。

因此，需要在多个会话(多模式)应用程序中间提供对话管理和自动仲裁的系统，和支持这种体系结构的协议。

发明内容

本发明涉及通过用于自动对话管理和多个会话应用之间的仲裁的协议提供会话计算的系统和方法，以及支持这种协议的架构。

在本发明一个方面，对话管理器和仲裁器DMA接口装置包括：

根DMA，用于在多个应用程序中间进行仲裁以针对指定用户输入事件确定活跃应用程序；和

多个应用程序DMA，用于在应用程序内的多个子对话中间进行仲裁，以确定管理与用户输入关联的子对话的目标应用程序DMA，其中至少一个应用程序DMA与每个应用程序相关联。DMA接口最好包括层次树结构，其中使用自底向上方案通过DMA接口执行仲裁。根DMA和应用程序DMA在层次树体系结构中工作，其中树的根是根DMA。当应用程序被启动时，应用程序创建应用程序DMA以管理应用程序的主对话。这个应用程序DMA在根DMA上注册并且变成根DMA的″儿子″。应用程序可以被编程为实例化应用程序DMA的一或多个实例以管理子对话，所述实例变成当初始启动应用程序时创建的aDMA的″儿子″。最好在分立的线程中创建″儿子″应用程序DMA。

在本发明的另一方面，管理一或多个应用程序的对话的方法包括的步骤有：

实例化包括层次树结构的对话管理器和仲裁器DMA接口，层次树结构包括根DMA和一或多个应用程序DMA；

由根DMA向应用程序DMA发送有关用户输入事件的通知；

由应用程序DMA得到用户输入事件的符号表示；

由应用程序DMA调用执行符号表示的上下文解析的应用程序方法；

由应用程序DMA从应用程序接收查询，其中查询包括上下文解析的结果；

由DMA接口根据应用程序DMA接收的查询确定应用程序DMA当前是否活跃；和

如果确定应用程序DMA当前活跃，由应用程序DMA启动与查询关联的回调函数。

在本发明的另一个方面，提供了用于多模式输入/输出管理的系统和方法。当将向用户提供消息/应答时，I/O管理器产生具有一或多个模式的消息。I/O管理器使用任务管理器驱动输出生成以产生抽象输出事件。I/O管理器将抽象输出事件转换成一或多个模式以便提供给用户。

通过以下结合附图对优选实施例进行的详细描述可以理解本发明的这些和其它方面、特性和优点。

附图说明

图1是基于本发明实施例、用于提供会话计算的系统的高层模块图；

图2是基于本发明实施例、用于提供会话计算的系统的高层模块图；

图3是基于本发明实施例的分层DMA(会话管理器和仲裁器)的模块图；

图4是使用基于本发明实施例的DMA结构提供对话管理和仲裁的示例性方法的模块图；

图5的图例图解了由基于本发明实施例的DMA维护的信息；

图6的图例图解了使用基于本发明实施例的DMA的会话计算系统；

图7A、7B、7C和7D是基于本发明的一个方面、提供对话管理和仲裁的方法的流程图；

图8是基于本发明实施例、用于提供多模式输入/输出管理系统和方法的模块图；

图9是基于本发明实施例的多模式输入/输出管理器的输入/输出代理的模块图；而

图10是基于本发明实施例的语音门户的模块图。

具体实施方式

这里使用的术语″会话″和会话计算″是指用户和机器之间，以及具有不同模式(I/O能力)的设备或平台之间的无缝多模式对话(信息交换)，其中无论接入设备/通道的I/O能力如何，最好使用开放式可互操作的通信协议和标准，以及将应用数据内容(层次3)和企业逻辑(层次2)与用户交互和用户操纵的数据模型分离的会话编程模型(例如基于会话原语的标记语言)。会话计算使人和机器象人-到-人对话那样自然地进行对话。

此外，术语″会话应用程序″是指支持应用程序内的，和跨越独立开发的应用的多模式自由流程交互(例如混合主动对话)的应用程序，其中最好使用短期和长期上下文(包含前面的输入和输出)以消除歧义和理解用户的意图。会话应用最好使用NLU(自然语言理解)。

多模式交互对话包括诸如语音(例如通过VoiceXML编写的)、可视(GUI)(例如HTML(超文本标记语言))、受限GUI(例如WML(无线标记语言)、CHTML(紧凑HTML)、HDML(手持设备标记语言))和这些模式的组合(例如语音和GUI)的模式。另外，每个模式(或模式组合)可以被实现成全NL(自然语言)用户接口，从而产生通用会话用户界面(CUI)。应当理解，虽然上述例子是说明性的，然而可以根据本发明通过命令式的方式或说明式和命令式编程的任何组合对任何模式进行编程。

本发明涉及通过用于自动对话管理和多个会话应用之间的仲裁的协议提供会话计算的系统和方法，以及支持这种协议的架构。图1是图解基于本发明实施例、用于提供会话计算的系统的高层模块图。该系统包括会话应用程序架构(CAF)11，会话应用程序架构包括一组允许开发会话应用程序的协作部件。例如，CAF 11包括与各种引擎接口并且开放其基础功能的部件。CAF 11包括为设备提供必要I/O抽象的部件，其中所述部件被配置在所述设备上。此外，如下所述，该系统包括DMAF(会话管理器和仲裁器外观)，其中根据本发明，DMAF提供会话应用程序和CAF 11之间的接口。

CAF 11最好通过将应用内容(企业逻辑和后端接入)与用户交互分离来支持会话计算编程模型。例如在2000年4月6日提交、标题为″用于多模式浏览和会话标记语言实现的方法和系统(Methods andSystems For Multi-Modal Browsing and Implementation of AConversational Markup Language)″的美国专利申请09/544,823中描述了交互式编程模型的优选实施例，该申请同样得到转让，并且这里完整地参考引用了该专利申请。

会话应用程序平台(CAP)10包括CAF 11的实现，该实现也将CAF 11需要的系统服务12绑定到具体的本地操作系统。在一个通过Java实现CAF 11并且其服务被绑定到Java虚拟机13(和可能的附加本地OS服务)的最优实施例中，CAF 11的这种实现在这里被称作会话虚拟机(CVM)。应当理解，虽然最好通过Java实现本发明，然而其它操作系统、平台或虚拟机也可以被用来实现这里根据本发明的指导和范围描述的系统和方法。

在1999年10月1日提交、标题为″通过会话虚拟机的会话计算(ConverSational Computing Via Conversational Virtual Machine)″(在美国国家阶段提交并且分配了美国序号09/806,565)的国际申请PCT/US99/22927中描述了CVM和对应会话协议的优选实施例，该申请同样得到转让，并且这里完整地参考引用了该专利申请。上述国际申请PCT/US99/22927描述了CVM(会话虚拟机)的各种体系结构，所述CVM为应用程序开发者开放会话API(应用程序接口)、会话协议和会话基础类，并且提供了内核层，所述内核层负责通过管理对话及上下文、会话引擎和资源来实现会话计算，并且在具有不同会话能力的平台和设备上实现会话协议/通信，以提供通用CUI(对话用户界面)。CVM可以被实现成独立的OS(操作系统)，或在传统OS或RTOS(实时操作系统)的顶层运行的平台或内核，从而能够为传统平台和应用程序提供向后兼容。

在本发明的一个最优实施例中，CAP 10和CAF 11包括在上述国际申请PCT/US99/22927中描述的部件、API和功能(并且使用其中描述的协议)。更具体地，本发明的优选实施例是在例如用于实现DMAF(会话管理器和仲裁器外观)的优选部件和协议方面对国际申请PCT/US99/22927的扩展，其中所述DMAF介入会话应用程序和CAF11之间的交互。DMAF是为应用程序开发者提供指向基础CAF部件的单独标准连接的API。DMAF提供应用程序和CAF的其它部件之间的桥接，从而使应用程序开发者不知道(i)任何基础CAF部件，(ii)引擎提供商如何将其引擎和设备挂到平台上，或(iii)这些CAF部件和引擎所在的位置。因此，DMAF有助于减轻开发工作量，提高多个引擎的互操作性，并且促进可分布的体系结构。此外，DMAF没有对针对其建立的应用程序的数量、域或模式作出假设。于是，基于本发明的DMAF在任何会话应用程序上均是可重用的。

现在参照图2，一个高层模块图图解了使用基于本发明实施例的DMAF提供会话计算的系统。系统包括CVM 14，CVM 14包括多个外部接口。外部接口包括DMAF 16，DMAF 16为会话应用程序15和会话应用程序开发人员提供接口。另外，I/O接口18为传统I/O设备17提供接口，I/O设备17包括例如键盘、鼠标、触摸屏、键盘、用于捕捉语音I/O(音频输入/音频输出)的音频子系统等等。I/O API 18提供设备抽象、I/O抽象和UI抽象，并且根据使用的I/O模式提供模式相关呈现。下面描述I/O管理器的优选实施例。

此外，引擎接口20提供核心会话引擎19(例如语音识别、NL分析、NLU、NLG、TTS和语音压缩/解压缩引擎)与使用它们的应用程序之间的接口。引擎API 20提供与本地或远程的核心引擎进行通信的协议。引擎接口20最好使用JSAPI(Java语音API)21和这种API的扩展。

如上所述，本发明涉及实现DMAF(会话管理器和仲裁器外观)的优选实施例和协议。在下面对优选实施例的描述中，假定在会话虚拟机(CVM)内实现DMAF，虽然可以在提供一或多个应用程序上的对话管理的任何平台中实现基于本发明的DMAF。此外，虽然CVM包括各种部件(如这里和上述国际申请PCT/US99/22927中描述的)，然而这里只详细描述那些包括DMAF和涉及I/O管理的CVM部件。此外，还描述被DMA部件用来与应用程序和各种其它CVM部件通信的DMA部件。

基于本发明的DMAF 16提供多个会话功能。这些功能包含：

(i)为会话应用程序提供挂在CAP(CVM)上的标准方式；

(ii)在平台上安装的多个会话应用程序之间进行仲裁；

(iii)在与相同应用程序关联的多个子对话之间进行仲裁；和

(iv)存储和管理应用程序信息。

为了提供这些功能，DMAF 16最好包括一组可以被应用程序开发者用来在CVM平台14上安装和启动其会话应用程序的接口。此外，DMAF 16包括一组接口，其中应用程序开发者通过该组接口可以访问架构提供的仲裁和对话管理设施。

通常，为了管理一或多个会话应用程序，CVM实例化多个会话管理器和仲裁器(DMA)，所述会话管理器和仲裁器执行在子对话管理器中间管理对话和进行仲裁的组合功能。为了执行这些管理和仲裁功能，应用程序开发者通过DMA句柄使用DMAF。一旦会话应用程序被初始化和启动，针对主对话创建DMA实例并且使DMA实例与应用程序关联。在应用程序执行期间，相关的DMA会管理用户输入，向适当的处理级段传递用户输入，并且最终为应用程序提供机会，以便处理从所述处理的各个级段得到的、根据用户意图的符号表示。

为了解释用户意图，应用程序可以使用DMA得到附加信息，例如NLU返回的命令，事务历史库，当前上下文等等。这种解释的结果被回送到DMA。一旦完成仲裁，并且当应用程序的DMA产生了平台上运行的所有应用程序中间的最可能解释时，DMA会启动处理这种解释的应用程序方法。

DMA也会通过向适当部件传递这些方法的输出来管理该输出，其中所述适当部件使用类似于用于输入处理(如下所述)的算法串的算法串进行处理，以控制适当引擎的应答处理和生成。在处理之后，按照应用程序的要求产生输出应答并且最终向用户提供输出应答。应当理解，解释用户意图的处理可以由CVM或其它为此目的而设计的部件的对话管理功能来执行。此外，这种处理可以由平台提供，或者被提供成另一个应用程序(与由应用程序提供商提供的方式相反)。

以下讨论概括了用于实现本发明的对话管理和仲裁协议的优选机构。通常，本发明提供了各种机构以用于(i)在平台上安装会话应用程序，(ii)允许应用程序开发者使用DMAF部件，和(iii)允许DMAF与其它CVM部件通信。

初始化和安装机构

在一个最优实施例中，初始化和安装机构包括初始化CVM平台的机构，通过该机构将各个部件实例化并且使平台能够进行应用程序安装。此外，提供用于在CVM上安装会话应用程序的机构。提供另一个在CVM上运行应用程序的机构，利用该机构可以通过语音或GUI/命令行启动应用程序。此外，提供用于在CVM上安装和执行多个应用程序的机构，通过该机构产生最高层DMA，最高层DMA可以在平台上运行的多个应用程序中间进行仲裁，并且在必要时消除这些应用程序之间的歧义。下面提供这些初始化和安装机构的详细资料。

对话管理和仲裁机构

本发明提供了用于实现对话管理和仲裁的多个机构。提供用于创建新DMA实例的机构，其中通过该机构，当第一次启动指定应用程序时始终产生一个DMA实例，以便管理该应用程序的主对话。另外，可以(但不一定)为指定应用程序产生其它DMA实例以便管理与该应用程序关联的子对话。

此外，DMAF提供用于在子对话(如果存在)中间进行仲裁的机构，其中对于指定用户输入，仲裁机构通过该机构确定管理相关子对话和在必要时消除歧义的目标DMA实例。

另外，DMAF包括通过DMA向CVM传送应用程序属性的机构。这些应用程序可以是本地的，也可以被分布在不同设备或机器上。这些属性包含应用程序需要的资源，例如引擎资源(语音识别、NLU等等)；数据文件(例如NLU和语法对象)；用于输入处理的算法串(即处理用户输入所需的引擎的集合和顺序)。例如，如果用户输入包括讲话发声(语音命令)，算法串可以包括：前端+语音识别+NLU。如果用户输入是键入命令，则算法串可以仅仅是NLU，等等。

提供另一个机构以便当一或多个应用程序属性改变时通知DMA(和可能的其它CVM部件)。例如，应当将应用程序属性的改变通知到任务管理器(是CVM部件)。如下所述，任务管理器是这样的CVM部件，该CVM部件与会话引擎通信，于是需要知道用户输入的算法串，并且当这种串被修改时，使得任务管理器可以实例化和使用用于处理这种用户输入的适当引擎。

此外，DMAF最好包括向DMA传送命令注册表的机构。命令注册表将查询映射到回调函数。应用程序从指定DMA接收用户意图的符号表示。在上下文解析之后，应用程序产生用户意图的解释。这种解释在这里被称作″查询″。回调函数包括与用户意图的解释关联的应用程序方法。于是，接收查询的DMA会启动与之关联的方法。应用程序开发者可以在任何时候更新命令注册表。

DMAF提供的另一个功能是维护和更新针对用户输入产生的事件列表的机构。这些事件包含例如输入通知、NLU结果、产生的查询、回调应答等等。此外，提供用于维护和更新在整个指定会话上执行的任务的列表的机构。任务包括执行某个动作所需的更多用户输入中的一个。所以，对于每个任务，维护针对每个用户输入产生的事件的子集。

DMAF还包括为应用程序开发者提供事务历史库，以存储和检索他们能够在其应用程序中使用的信息的机构。这种信息由应用程序开发者决定，并且意味着在应用程序开发者可以利用的(例如在撤消和重复动作中可以利用的)更具语义的层次上对事件进行分组。虽然优选实施例假定应用程序开发者指定存储和检索哪些信息，然而这里可以实现用于自动进行和管理这些判决的任何适当技术(例如额外的历史库/上下文/元信息管理器，CVM的服务，或通过另一个应用程序)。

另外，DMAF还包括与应用程序协作以消除用户输入事件的歧义(例如根据预期历史记录、当前状态等等验证来自NLU结果的结果)的机构。在一个实施例中，通过提供对DMA维护的各个记录(bookkeeping)容器的访问来执行协作。接着应用程序可以执行上下文解析并且向DMA实例返回所得到的查询。如上所述，在示例性实施例中，由应用程序执行上下文解析(并且由应用程序开发者对上下文解析进行编程)。但是可以一般性地提供上下文解析，或者由另一个服务、管理器或CVM为其具体提供应用程序，或者由另一个应用程序提供。

此外，DMAF包括一种机构，其中一旦(根据仲裁探索算法)确定指定DMA实例确实是用户输入的目标，该机构根据最高得分的查询结果启动适当的应用程序方法。

听写机构

DMAF最好包括用于提供听写的多个机构。在听写会话期间，提供允许DMA(负责听写应用程序)通知顶层DMA只向该DMA发送所有用户输入通知的机构。提供这种听写功能的优选机构如下所述。

最好提供通知方法，该方法被DMA用来向顶层DMA通知该DMA正开始听写，并且使顶层DMA只向该DMA发送所有用户输入通知。此外，最好提供通知机构以便终止听写并且恢复针对所有DMA的输入通知。在一个实施例中，用户会具体通过GUI输入或语音命令停止听写。当用户终止听写时，管理听写应用程序的DMA将此终止通知顶层DMA，并且顶层DMA接着会恢复向所有注册的应用程序发送用户输入。

另一个涉及听写的机构包括当用户请求停止听写时保证听写模式的应用程序放弃输入控制的方法。该方法是优选的，以便防止独占资源的应用程序不允许平台上的其它应用程序接收用户输入。

在另一个实施例中，平台(服务或其它应用程序)可以提供附加机构以便自动确定听写的开始和结束。这里的指导会包括与该实施例关联的DMA和应用程序。

上下文解析机构

DMAF还包括提供上下文解析的多个机构。最好基于当前状态、历史记录和焦点的上下文解析可用于消除查询的歧义。例如，通过在DMA中提供的各个历史库中搜索事件并且发现最后使用的姓名为″Mary″，可以消除″打开她的邮件″形式的输入的歧义(其中代词“她”是指用户最后与之对话的个人)。如果可以发现这种关联，则先前含有歧义的命令open_mail(发送方＝她)变成了无歧义的命令open_mail(发送方＝Mary)。这个无歧义命令接着可以被发送到后端应用程序，或得到处理，其中不需要其它歧义消除对话。

然而这个关联处理需要解释应用程序信息的能力。然而最好尽可能保持DMA的一般性，但仍然允许DMA的能力足够进行上下文解析。

为了提供这种上下文解析功能，DMAF提供由DMA实现的各种方法。DMA实现的一个方法允许DMA在各个历史库中维护和管理应用程序信息，并且为应用程序开发者提供对这种历史库的访问。另一个方法实现安全机构，其中需要这种安全机构以保证指定应用程序修改或访问仅涉及指定应用程序的事件，并且保存容器的完整性。因此，用户或应用程序开发者可以指定能够与其它应用程序共享的信息，和应当仅与指定应用程序共享的信息。各种方法可用于标识这种针对指定信息或信息类型的友员、公共和私有应用程序，以及相应应当使用的安全或共享策略。

另一个方法为应用程序提供一或多个上下文解析器协议。优选的上下文解析器策略不会被详细讨论。然而与所使用的方法相独立地，所得到的DMAF在本发明的指导内。这些方法可以由CVM、应用程序开发者或其它应用程序提供。它们也可以被看作是DMA的一部分，或者在DMA外部。应用程序开发者可以使用DMAF提供的方法中的任何一个，或者自己实现。

DMA体系结构

本发明提供了允许DMA实例彼此通信的机构。实际上，在一个最优实施例中，为了在多个应用程序上或各个子对话之间的相同应用程序内提供仲裁，最好实现分层DMA体系结构。

根据加载的应用程序的安全设置，不同应用程序能或不能在其相应aDMA之间交换信息(上下文、用户输入或用户输入等等)。当在极端情况下应用程序不能共享信息时(例如由于它们是由不同提供商提供的，并且涉及敏感信息)，则会需要约束对友员应用程序的仲裁。为了从焦点在一个友员应用程序簇上的状态切换到另一个簇，需要针对平台的显式命令以执行这种切换。以往的上下文可能被丢失。这类似于如下所述用于听写的机构。

现在参照图3，一个模块图图解了通过基于本发明实施例的DMAF实现的分层DMA结构。在这个实施例中，最高层DMA 30实例在CVM平台上安装的多个应用程序31和32之间进行仲裁。这里，最高层DMA实例被称作″根DMA实例″或″rDMA″。每个应用程序31和32创建DMA的至少一个实例以管理其主对话。例如，应用程序31创建DMA实例33，而应用程序32创建DMA实例34。这些DMA实例33和34是最高层DMA实例30的″儿子″。这里，针对具体应用程序创建的DMA实例被称作″应用程序DMA实例″或″aDMA″。可以进一步扩充图3中描述的分层体系结构以创建指定aDMA的新实例(例如在应用程序的子对话内)。例如，产生aDMA 33的新aDMA实例35和36以管理子对话。这些aDMA实例35和36是管理应用程序31的主对话的aDMA33的″儿子″。

于是在图3中，rDMA 30位于树的顶部，它在平台上安装的所有应用程序中间进行仲裁。管理指定应用程序的主对话的aDMA是rDMA的″儿子″。所有针对应用程序创建的后续aDMA变成管理主对话的aDMA的后代。

为了接受对话管理服务，应用程序必须在rDMA 30上注册以得到aDMA句柄。最好在启动应用程序时进行注册。图3的体系结构中的rDMA 30提供多个服务。例如，rDMA 30维护有关所有注册的aDMA的列表，并且跟踪注册aDMA中的活跃aDMA。活跃aDMA是当前″在焦点上″的aDMA。在一个实施例中，每个对话轮次最多只有一个活跃aDMA。在DMAF支持一个用户输入的多个动作的另一个实施例中，每个对话轮次可以有不止一个活跃DMA。

此外，rDMA 30使I/O通知事件与用户输入关联，并且在历史库中跟踪它们。rDMA 30跟踪焦点变化，并且跟踪被″儿子″推入历史库的事件。aDMA推入事件的操作最好作为普通记录的一部分。另外，如果特定的″儿子″有请求，rDMA 30为″儿子″拉出其历史库中存储的事件。例如在歧义消除的情况下，″儿子″aDMA可以请求其父亲(在这种情况下为rDMA)为其″儿子″拉出某些可能在歧义消除中使用的信息。根据每个″儿子″，即应用程序或子对话设定的安全设置，rDMA可以接受或拒绝提供这种信息。可以在安装时提供安全设置，或者安全设置随时间动态演变。可以通过针对每个会话应用程序的DMAF接口设置这些属性。当应用程序拒绝共享时，需要来自用户的显式焦点切换命令。

在rDMA和aDMA之间交换各种信息。这种信息包含例如：(i)用于在rDMA上注册/解除注册aDMA的信息；(ii)被发送到注册的aDMA的I/O通知事件；(iii)rDMA从其所有″儿子″aDMA接收的最高计分查询，用于在aDMA中间进行仲裁以决定哪个aDMA当前活跃；(iv)被发送到活跃aDMA以继续操作I/O事务处理的通知(和并行的，被发送到非活跃aDMA以便不继续处理的通知)；(v)上下文或焦点变化的确认；(vi)请求下一个提示，或者rDMA可以请求其″儿子″aDMA将属性发送到NLG(自然语言生成)引擎以便构造提示；和(vii)为″儿子″拉出其历史库中存储的信息。

当DMA为分布式DMA时，可以将上述信息加密。由于这种信息可以是非常敏感的，DMA客户端有可能不被信任。可以提供不同解决方案以解决这个问题。例如在一个实施例中，可以提供一种机构以便指定可以交换信息的友员应用程序和不能交换信息的非友员应用程序。友员应用程序可以由相同提供商开发。一个指定友好应用程序的机构包括通过数字证书进行的认证或其它认证机构。这意味着，虽然可以在应用程序内执行对话管理，然而应用程序间的仲裁被限制于友员应用程序。如上所述，到另一个友员应用程序组的切换最好需要用户的显式命令。例如，这是一个由用户明确指示(例如″切换到...″)或隐含(例如点击其它窗口)的到CVM的命令。哪些应用程序是友员应用程序以及哪些应用程序不是友员应用程序的决定依赖多个可以是静态或动态的条件(例如，有关当前应用程序、应用程序状态或其它包含用户偏好的外部因素的函数)。

另一个解决方案是使用可以证实其完整性的″密封″aDMA代码，并且与其″儿子″和父亲交换加密信息。术语″密封″意味着不通过其任何接口向外部暴露这个信息，并且在本地对其加密。当DMA内部执行所有解释、对话管理和上下文管理(通用或专用地)时，可以使用这个″密封″方案，使得其不必被传递到外部。

应当理解，可以实现其它解决方案。应当理解，无论实现什么解决方案，所得到的DMA均被本发明预见到。

rDMA最好使用自底向上方案在多个aDMA中间执行仲裁。对于这个方案，从rDMA向每个注册的aDMA″儿子″传递用户输入的通知，而aDMA″儿子″接着向相关的″儿子″传递用户输入。为了提高这个方案的效率，最好提供一个剪裁机构。在一个实施例中，用户输入被传递到在以往″i″个轮次已活跃(即，在焦点中)的所有注册aDMA，其中″i″是某个定义的数值。在不改变DMA体系结构和执行原理的情况下，可以使用任何剪裁训练的、优化的或探索式的方法(静态或动态的)。在下面讨论中，假定不执行剪裁，使得所有注册aDMA实际上均得到通知。

此外，用于提供仲裁的探索式、确定性或统计算法最好是可插入的。于是，当初始化架构时动态加载仲裁策略。安装CAF的开发人员最好可以安装其自己的仲裁策略。也可以由平台、CVM服务或外部应用程序提供仲裁算法。它们可以是通用的，或特定于加载的应用程序的。它们可以被看作是DMA的一部分，或者在DMA外部。

图4是用于提供对话管理和仲裁的示例性方法的模块图。更具体地，图4图解了3个应用程序的创建：(i)日历应用程序40；共用基金应用程序41和航班预定系统应用程序42。由rDMA 43管理全部应用程序40、41和42。对于共用基金应用程序41，产生一个aDMA 44以管理主对话，并且从aDMA 44实例化2个aDMA以处理用户访问子对话和共用基金交易子对话，即处理用户访问的子对话aDMA 45和处理共用基金交易的子对话aDMA 46。此外，进一步细分交易对话，使得分别通过2个不同的aDMA 47和48处理销售交易和购买交易。更具体地，通过aDMA 47管理交易对话下面用于处理共用基金销售的子对话，并且通过aDMA 46管理交易对话下面用于处理共用基金购买的子对话。

此外，在图4的示例性实施例中，日历应用程序40和航班预定应用程序42分别产生一个aDMA实例48和50以处理与对应应用程序关联的主对话。

DMA部件

以下讨论涉及DMA中被用于提供记录服务的优选部件。图5的图例根据本发明的实施例图解了rDMA和aDMA中被用于此目的的优选部件。在本发明的其它实施例中，可以排除或以不同方式组合这些部件，并且/或者可以在不影响DMA的原理的情况下引入其它部件。rDMA 60包括将注册″儿子″aDMA与aDMA所伺服的相关应用程序映射起来的注册表61。aDMA 65包括注册表66，注册表66被用来将″儿子″aDMA与它们伺服的子对话关联起来。rDMA 60还包括焦点历史库62，焦点历史库62存储在整个指定会话中活跃aDMA的记录。同样地，aDMA 65包括焦点历史库67，焦点历史库67存储在整个指定会话中的活跃″儿子″aDMA的记录。

另外，aDMA 65包括事务历史库，事务历史库为应用程序开发者提供了容器，其中应用程序开发者可以在容器中存储完成的事务处理。这些完成的事务处理可以组合成各种共享某种语义含义的任务。应当理解，在一个最优实施例中，事务历史库68中存储的信息完全由应用程序开发者决定。这个事务历史库68可以被应用程序用于例如编码″撤消″、″重复″、记忆、概括、动作。例如，为了编码″撤消″操作，应用程序可以使用事务历史库记录实现某个事务处理所采取的所有步骤。当用户希望″撤消″其最后的事务处理时，应用程序可以采取其已经针对该事务处理记录的任务列表，并且按照相反顺序撤消每个操作，于是恢复用户完成事务处理之前的应用程序状态。

此外，rDMA 60包括短期历史库存储63，短期历史库用于维护信息，例如(i)I/O通知事件，(ii)哪个aDMA接收I/O通知(再次假定所有注册的aDMA均会接收I/O通知事件，虽然在另一个使用剪裁机构的实施例中，只有注册aDMA的子集会得到通知，其中通过某种探索式的、训练的、确定性的或统计优化算法等等可以确定该子集：在使用探索式算法的情况下，维护接收I/O通知的注册aDMA列表)，(iii)哪个aDMA接收了″继续并执行任务″通知(即，该aDMA是当前的活跃aDMA)，(iv)输出请求通知以及哪个aDMA发送该通知，(v)当任务已经执行时aDMA发送的任务描述符(任务描述符包括针对指定任务产生的事件子集(参见aDMA中的LHT))。

aDMA 65包括短期历史库存储70，该短期历史库存储针对对话中的特定状态产生的所有事件。这种事件包括：(i)输入通知事件；(ii)任务管理器通知事件；(iii)NLU结果(或从引擎返回的任何结果)；(iv)上下文解析的结果(由应用程序传递这个结果--应用程序会访问LHT、STH、焦点历史库，并且确定什么是实际的查询。这会导致改变已经填充特征/数值对的列表。aDMA可通过应用程序上下文对象访问这个信息)；(v)回送到父DMA(可以是父aDMA，或者如果这个是主aDMA，则可以是rDMA)的查询；和(vi)焦点计算之后的父亲应答。

当回调函数返回时刷新短期历史库。在短期历史库包含的内容子集中放入描述符，并且将该子集推入如下所述的长期历史库。

rDMA 60还包括长期历史库64，长期历史库存储非活跃aDMA的任务描述符。也就是说，当对话终止时，STH中针对特定aDMA的任务描述符被转移到LTH。aDMA 65包括长期历史库70，该长期历史库存储导致执行任务的主要事件。短期历史库存储对话中每个状态的层次上的信息，而长期历史库会存储整个对话层次上的信息。因此，当任务已经完成并且对话处于新状态时，短期历史库中的事件子集会被推入长期历史库。这个事件子集可以被组合在描述符对象中，描述符对象则被标记上I/O事务ID并且被推入长期历史库。事件子集包括：(i)I/O输入通知事件；(ii)查询对象；和(iii)回调应答。

DMAF与CAF部件的交互

DMAF与CVM的其它部件配合工作。现在参照图6，一个模块图根据本发明的实施例图解了用于提供会话计算的系统。更具体地，图6的实施例图解了DMAF和其它CAF部件之间的接口。系统包括会话应用程序80、应用程序DMA 81、根DMA 82、I/O管理器83、任务管理器84、资源管理器87和多个会话引擎88，其中任务管理器84包括线程池管理器85和引擎管理器86。应用程序DMA 81，根DMA 82和相关接口包括DMAF。DMAF在会话应用程序80和其它CAF部件83、84、85、86、87和88之间提供接口。

I/O管理器83是与所有输入和输出设备接口的CAF部件。通过与DMAF的内部接口，I/O管理器83向rDMA 82发送输入通知事件，并且向用户提供通过rDMA 82发送的输出请求。更具体地，I/O管理器83执行以下功能：(i)向rDMA发送用户输入通知事件；(ii)从rDMA接收输出通知请求；(iii)当″儿子″耗用输入时从rDMA接收确认；和(iv)在提供输出之后向rDMA发送确认。于是，从rDMA的角度看，与I/O管理器的交互需要接收输入通知事件的方法和发送输出生成请求的方法。下面更详细地描述本发明用于提供I/O管理的优选实施例和协议。

此外，DMAF与任务管理器84通信，任务管理器84是通过引擎API与引擎88(例如ASR、NL等等)接口的CAF部件。任务管理器处理来自应用程序DMA 81的命令，以便例如初始化和配置引擎88，注册线程，组成提示，合成输出等等。任务管理器88包括2个部件--线程池管理器85和引擎管理器86。线程池管理器85负责跟踪平台创建的线程。在DMAF的上下文中，线程池管理器85管理当启动应用程序80时创建的主应用程序线程(与应用程序DMA 81关联)，以及当创建″儿子″aDMA以管理应用程序80的子对话时创建的所有线程。引擎管理器86充当与引擎API的主要接口。

引擎管理器86与资源管理器87协作，资源管理器87是CVM的另一个部件。虽然资源管理器87管理平台上的所有资源，然而在一个最优实施例中，资源管理器不与DMAF直接交互：它只指定任务管理器会访问的资源。

任务管理器84包括以下功能：(i)从aDMA接收用户输入通知事件；(ii)向aDMA发送引擎结果(例如NLU特征数值对、NLU分析树、自由文本等等)；(iii)从aDMA接收输出请求生成；(iv)向aDMA发送输出结果(例如提示)；和(v)通过线程池管理器管理线程。当DMA创建新线程时，线程自身在线程池管理器85上注册。线程池管理器85管理CVM部件创建的所有线程。

在一个最优实施例中，任务管理器84使用基于XML的编码方案在引擎88和对话管理架构之间交换信息。应当理解，优选XML编码定义了XML的简单方言(dialect)，其中XML可被扩展以便允许在必要时增加新信息项。使对话管理架构和引擎通过XML流进行通信还使得这个体系结构可自动分布，其中对话管理架构和引擎彼此视为XML编码流的生产者/消费者。可以通过XML编码(例如诸如SOAP的XML协议)交换控制交换，并且有时可以使用以下机构使控制交换与传入或传出音频或多媒体流同步：例如1999年10月1日提交的标题为″提供网络协同会话服务的系统和方法(System and Method ForProviding Network Coordinated Conversational Services)″的国际专利申请PCT/US99/22925中描述的机构，和2000年11月1日提交的标题为″通过传送、编码和控制会话协议进行会话联网(ConversationalNetworking Via Transport，Coding and Control ConversationalProtocols)″的美国专利申请09/703,574中描述的机构，所述专利申请均同样得到转让，并且这里参考引用了该专利申请。美国专利申请09/703,574描述了新颖的实时流协议(是RTP(实时协议)的扩展)，该协议提供了分布式设备/应用程序之间例如控制信息的实时交换。

与会话应用程序的DMA接口

下面的讨论描述了DMAF为会话开发人员开放的各种接口。从应用程序开发者的角度看，这些接口提供了与DMAF(和CVM)的完全交互。

在一个最优实施例中，使用DMAF实现会话命令解释应用程序(或″CVMshell″)，以便提供对CVM平台的访问。当在指定平台上安装CVM时，CVMshell应用程序被实例化。CVMshell最好是平台驻留的第一个应用程序。

CVMshell是提供多个优选功能的专用应用程序。例如，命令解释应用程序实例化所有的CVM部件。CVMshell提供″安装接口″，应用程序开发者必须实现该接口以便在CVM平台上安装其会话应用程序。CVMshell提供简单的命令行解释器，其中应用程序开发者通过该解释器可以本地或远程地向CVM下载其应用程序。另外，CVMshell提供一种接口，该接口允许用户通过命令行GUI和/或语音命令在平台上运行应用程序。

此外，CVMshell包括多个实例化诸如rDMA、I/O管理器、任务管理器(接着会实例化线程池管理器和引擎管理器模块)和资源管理器的部件的方法。最好提供类的″工厂″以便创建所有这些类的实例。

CVMshell提供若干功能，例如实例化命令解释程序属性类，以及用命令解释程序、数据文件和算法串的所有资源填充实例。此外，CVMshell创建命令注册表。当CVM上没有安装应用程序时，命令注册表为空，但是命令注册表最终被填充启动指定应用程序的命令列表，以及指向应用程序的对应记录。此外，CVMshell创建新的aDMA对象并且向其构造函数(会向该类加入aDMA和任务管理器以作为监听器)发送命令解释程序的属性类。

当CVMshell初始化时，所有对象会被实例化。CVMshell还包括向这些对象返回句柄的静态方法。

CVMshell提供的″安装接口″是允许应用程序开发者在平台上安装应用程序的接口。安装接口最好提供用于以下操作的方法：(i)指定应用程序名称和实现应用程序名称的类；(ii)产生可用于启动应用程序的命令列表；(iii)当这些命令被引擎理解时产生要启动的回调函数的列表；和(iv)指定可以启动应用程序的方式(GUI、命令行等等)。

当安装程序运行时，CVMshell的命令注册表会被应用程序提供的回调函数和命令填充。每当安装新应用程序时，会用新命令和回调函数扩充命令注册表。应当理解，如果2个应用程序使用一或多个相同的启动命令，安装接口会警告第二个应用程序：所选择的命令会覆盖前面的应用程序的启动命令。

DMAF还实现多个方法以允许与会话应用程序交互。更具体地，DMAF最好实现可被应用程序访问并且被用来实现以下功能的方法：(i)创建DMA，并且传递这种DMA应用程序属性，例如针对输入和输出处理规范的语法、语言模型、算法串(被传递到任务管理器)；(ii)填充命令注册表(在DMA中使用)，该注册表包括回调函数和相关查询；(iii)规定对话状态退出条件(在DMA中使用)；(iv)在DMA中存储和检索事务记录(这些记录有助于完成撤消、重复或概括动作(如果应用程序支持)，并且形成每个事务处理的事件组合由应用程序开发者决定)；和(v)访问DMA历史库以帮助上下文解析。

另外，会话应用程序实现多个允许与DMAF交互的方法。在一个最优实施例中，DMAF期望应用程序开发者至少实现一或多个方法，使得DMAF可以与应用程序通信。例如在一个实施例中，会话应用程序实现适当的方法以执行上下文解析。在这种实施例中，DMAF向上下文解析施加任何特定的协议，但是DMAF向方法和返回类型施加参数。例如在一个最优实施例中，contextResolver方法接受NLResult对象并且返回查询对象。

DMA信息流

下面描述一旦用户输入被捕捉并且发送到rDMA时DMA内部的信息流。在描述信息流之前，下面是DMA定义的优选内部类的列表及其用途。

-输入通知事件类：I/O管理器创建的输入通知事件，并且被发送到rDMA命令注册表类。

-命令注册表类：创建存储查询及其相关回调函数的表格。

-注册表类：创建存储DMA和针对其管理的应用程序/子对话的索引的表格。

-输入队列类：创建其中插入输入通知事件的队列。每个aDMA包括输入队列类，其中存储输入事件通知。当从其父亲接收到输入通知事件时，aDMA会向其所有″儿子″的输入队列插入输入通知事件，使得″儿子″可以开始处理用户输入。以自顶向下方式递归地进行这种通知，直到用户输入事件已经被通知到所有的DMA。

-NLU结果类：存储NL结果，置信度数值和与NLU处理相关的其它数据。

-查询类：存储上下文解析的结果。

-查询散列表类：其中插入查询的散列表。这是以DMA为关键字的散列表。每个DMA(关键字)均与从上下文解析得到的查询(数值)相关。这个散列表代表DMA的结果队列。

-短期历史库(STH)类：创建其中存储涉及单独用户输入的事件的堆栈。

-长期历史库(LTH)类：创建其中存储涉及特定任务的事件的堆栈。

-事务历史库(TRH)类：创建其中存储事务处理对象的堆栈。这些对象在应用程序开发者定义的语义层次上组合事件。

-焦点历史库(FB)类：创建其中跟踪当前焦点的堆栈。

图7A-7D包括的流程图图解了根据本发明的一个方面、用于提供对话管理和仲裁的方法。具体地，图7A-7D图解了DMA内的信息流，并且描述DMA如何处理用户输入，如何通过各种部件传递用户输入以进行处理，以及如何向应用程序返回用户意图的符号表示。以下算法还描述了一旦应用程序向DMA重发查询时，DMA如何管理回调函数的输出应答。

现在参照图7a，用户会通过例如语音或GUI使用适当命令启动一或多个会话应用程序(步骤100)。当应用程序被启动时，会为应用程序创建一或多个aDMA实例(步骤101)。如上所述，应用程序会产生至少一个aDMA实例(是根DMA的″儿子″)以便管理与应用程序相关的主对话。此外，根据应用程序被编程的方式，可以创建其它aDMA实例(是主aDMA的″儿子″)以管理子对话。应用程序会在rDMA上注册以便得到应用程序创建的aDMA实例的aDMA句柄(步骤102)。rDMA维护所有注册的aDMA的列表，其中注册允许应用程序从rDMA接收对话管理服务。如上所述，会话管理器和仲裁器体系结构可以支持多个应用程序。于是，以下讨论假定一或多个应用程序活跃。

一旦应用程序被初始化，系统会等待用户输入事件，例如语音命令或鼠标点击(步骤103)。当接收到用户输入事件(步骤103中的肯定结果)时，I/O管理器会向rDMA发送对应的用户输入通知事件(步骤104)。rDMA接着会从其输入队列中检索输入通知事件(步骤105)。如果指定应用程序的″退出″条件没有被满足(在步骤106中的否定确定)，并且如果输入通知事件不是″END_OF_INPUT″事件(在步骤107中的否定确定)，rDMA会在其STH(短期历史库)中存储输入通知事件(步骤108)，并且接着向所有注册的″儿子″的输入队列插入输入通知事件(109)。换言之，在一个实施例中，rDMA会向在rDMA上注册的每个主aDMA发送输入通知事件。通过使用自顶向下方案，每个主aDMA会向其后代aDMA实例(如果有)的输入队列插入输入通知事件，并且沿着层次树向下重复这个过程，直到全部aDMA实例均已经接收到输入通知事件(步骤110)。

应当理解，可以使用其它方法向树中的aDMA发送输入通知事件。实际上如上所述，由于rDMA最好跟踪哪个注册aDMA是活跃的，可以使用剪裁方法，其中用户输入只被传递到那些在预定数量的对话轮次内已经活跃(″在焦点中″)的注册aDMA。本领域的技术人员可以想到用于向注册aDMA传递用户输入的其它协议。

现在参照图7B，每个aDMA会向任务管理器发送输入通知事件，并且阻塞后续向任务管理器的通知事件发送，直到接收到针对当前通知事件的应答(步骤111)。任务管理器接着会向任务管理器从其接收了用户输入通知事件的每个aDMA返回消息或结果集合(例如语音识别结果和NLU结果)(步骤112)。如果返回出错消息(步骤113的肯定结果)，则会相应处理错误(步骤114)。例如，如果从任务管理器返回出错消息，aDMA会将错误通知到应用程序。可以为错误分配不同的严重程度，并且aDMA可以根据严重程度决定忽略错误，向应用程序通知错误，和转移到下一个用户输入(例如返回到步骤103)，或者在严重程度较高的情况下退出应用程序。应用程序也可以提供各种机构以处理错误，或依赖平台服务(CVM)或其它应用程序处理错误，并且也可以提供错误恢复机构或差错处理对话。这些可以是专用或通用的。

另一方面，如果返回结果集合(步骤113的否定结果)，每个aDMA会在其对应的STH中存储结果(步骤115)。这个结果集合包括引擎产生的用户意图符号表示。每个aDMA会向其对应应用程序发送结果以进行上下文解析，并且阻塞向应用程序的后续结果传送，直到返回针对当前结果集合的查询(步骤116)。

应用程序会对相关aDMA接收的结果执行上下文解析，以产生查询(即用户意图的解释)。应当理解，上下文解析的过程在不同应用程序之间以及不同子对话的相同应用程序内有所不同。于是，每个aDMA接收的上下文解析结果(即查询)会有所不同。此外，在上下文解析过程期间，应用程序可以和aDMA协作以便得到由aDMA维护、用于消除查询歧义的附加信息，例如NLU返回的命令、事务历史库、当前上下文等等。

在上下文解析之后，应用程序会向每个aDMA返回所得到的查询。每个aDMA会在其STH中存储应用程序接收的查询(步骤116)。如上所述，也可以由模块(应用程序、CVM服务)或每个aDMA提供对话管理、用户意图理解和上下文解析的功能。

接着，通过使用自底向上方案，层次树中的每个父aDMA利用任何方法执行仲裁。在一个最优实施例中，适当的探索式算法被用来确定″胜出查询″(即最高计分的查询结果)。具体地，从树结构中的最低层次开始，每个父aDMA会等待其各个″儿子″aDMA向父亲的输出队列插入其″胜出″查询(步骤118)。注意，位于树中各个分支的底部的″儿子″aDMA不会执行仲裁，因为它们不是父亲(即，它们简单地向其父亲提供其查询(从应用程序接收))。

最好使用警告管理器在预定时间段之后触发超时，使得父aDMA不会无限期等待从各个″儿子″接收胜出查询。于是，如果预定等待时间段到期(步骤119中的肯定结果)，则发生超时(步骤120)。接着，父亲会杀死(忽视)在预定时间周期内没有应答以胜出查询的各个″儿子″aDMA，并且向相关应用程序发送出错消息(步骤121)。应当理解，在另一个实施例中，如果″儿子″在执行特别复杂的处理任务时向其父亲请求超时扩展，可以延伸超时。

父aDMA接着会对父亲从应用程序接收的查询和其输出队列中所有胜出查询(在等待期间由其″儿子″接收)进行仲裁，以确定父亲的层次上的胜出查询(步骤122)。参照图7C，父亲接着会在其STH中存储胜出查询和相关aDMA的标识(步骤123)。接着，父亲(是另一个父aDMA的″儿子″)会在其父aDMA的输出队列中插入胜出查询，并且阻塞向父亲的后续胜出查询传送，直到aDMA从父亲接收到相关的仲裁结果(步骤124)。

从分层DMA树的底部向顶部执行这个仲裁过程(步骤118-124)，直到根DMA从其″儿子″aDMA接收到胜出查询。根DMA接着会在其″儿子″接收(在预定等待时间段内)的所有胜出查询之间进行仲裁，以确定总的胜出查询。rDMA会产生最终仲裁结果，该仲裁结果包括总胜出查询和从其接收总胜出查询的″儿子″aDMA。

接着使用自顶向下方案，沿分层DMA树向下发送最终仲裁结果。具体地，根DMA会向其每个注册的″儿子″aDMA发送最终仲裁结果，而各个aDMA会在其STH中存储仲裁结果(步骤125)。各个父aDMA会检查从其父亲返回的仲裁结果，以确定用户输入的总胜出查询(与返回的仲裁结果相关)是否与先前通过父aDMA的仲裁而确定、存储(步骤123)在其STH中的胜出查询匹配(步骤126)。

如果父aDMA根据返回的仲裁结果确定其本身及其″儿子″aDMA均不是胜出方(步骤127的否定确定)，则父aDMA会清除其STH(步骤128)，并且接着通知其全部″儿子″aDMA：它们是失败者(步骤129)。另一方面，如果父aDMA确定总胜出查询与父亲管理的树分支内的aDMA相关(步骤127的肯定确定)，并且父亲不是胜出方，但其″儿子″中的一个是胜出方(步骤130的否定确定)，则父aDMA会向胜出″儿子″aDMA发送有关其是胜出方的通知，并且向其余″儿子″发送有关其是失败者的通知(步骤131)。父aDMA接着会清除其STH(步骤132)。

当aDMA确定其是胜出方(即，它提供了总胜出查询)时(步骤130的肯定确定)，aDMA会使用与应用程序相关的命令注册表(将查询映射到回调函数)，以确定与总胜出查询相关的回调函数(步骤133)。胜出aDMA接着会启动回调函数并且阻塞后续回调函数的启动，直到当前回调返回(步骤134)。

现在参照图7D，如果回调返回请求以产生输出应答(步骤135的肯定结果)，aDMA会向任务管理器发送generateOutputRequest并且阻塞进一步请求的发送，直到任务管理器返回当前请求的结果(步骤136)。如果任务管理器返回的结果不是″OUTPUT_REQUEST_GENERATED″消息(步骤137的否定结果)，则相应处理错误(步骤138)，例如象在前面针对输入处理错误描述的那样。另一方面，如果任务管理器返回″OUTPUT_REQUEST_GENERATED″消息(步骤137的肯定结果)，则胜出aDMA会向其父aDMA发送输出缓冲区的位置，而父aDMA将位置存储在STH中(步骤139)。接着沿树向上发送输出缓冲区位置到根DMA，根DMA则向I/O管理器发送输出缓冲区位置。

如果返回的回调表明应用程序(与胜出aDMA相关)正进入听写模式，则会相应处理听写过程。听写过程因应用程序的编程方式而有所不同。如上所述，应用程序的aDMA最好沿DMA树向上发送通知，以通知根DMA只向胜出aDMA发送所有用户输入通知。另外，应用程序最好提供终止听写并恢复向所有DMA发送输入通知的机构。在处理回调返回(步骤139或142)之后，或者在处理错误(步骤138或141)之后，产生事件描述，事件描述包括与输入通知事件相关的事件子集的描述(步骤143)。如上所述，事件子集包括例如I/O输入通知事件，查询对象和父亲的应答。当任务已经完成并且对话中的新状态开始时，胜出aDMA的STH中的事件子集会被推入其长期历史库(LTH)。事件子集可以被组合在描述符对象中，描述符对象则被标记上I/O事务ID并且被推入aDMA的LTH，而aDMA接着清除其STH(步骤144)。针对下一个相继用户输入重复这个DMA过程(返回到步骤103，图7A)。

I/O管理

现在详细描述I/O管理器和与rDMA的交互协议的优选实施例。应当理解，在本发明一个实施例中，由应用程序开发者解决I/O，并且CAF只控制引擎访问和仲裁。

在另一个实施例中，I/O管理器是CVM(CAF)的部件，因而使得应用程序开发者不必知道可以被用来与会话应用程序交互的设备/外设的细节。最好基于各种考虑构造本发明的I/O管理器，例如：

1.减轻编写工作量：应当为针对CAF编写应用程序的应用程序开发者提供将各种模式的应用程序挂在CAF上的机构。在一个实施例中，CAF可以包括用于所有模式的输入/输出管理器。在另一个实施例中，可以提供公共单元集合(例如焦点更新、文本字段值等等)和公共交换语言，使得CAF可以(从任何模式的管理器)提取其为完成所指定的任务(即仲裁，事件存储等等)所需的全部信息；

2.仲裁：含歧义的用户输入(例如语音，注视等等)应当被传递通过用于仲裁的rDMA层次结构。性质上没有歧义的用户输入模式(例如GUI，输入笔等等)通常不需要仲裁，因为用户输入所针对的领域是事先知道的；

3.记录用户交互和所有I/O事件：最好是，针对所有模式记录用户交互和I/O事件，并且该记录可被所有应用程序访问，不管用户输入和输出的模式如何；

4.访问基础引擎：对于用户输入(以及输出生成)需要访问引擎(例如语音识别、笔输入识别、TTS等等)的模式，需要用于向适当引擎发送用户输入(或输出事件)的机构；

5.同步：最好提供一种允许以互补方式使用多个模式的机构。例如，用户可以将鼠标移动到窗口并且说出一些话以便填充文本字段。于是，通过CAF的输入事件需要被加上时间标签(并加上来源标签)，并且反应同步；

6.可扩展性：本发明的CAF包括可扩展架构。于是，CAF(尤其是I/O管理)最好允许容易地将新模式引入架构；和

7.可分布性：CAF部件(例如I/O管理器)可以是分布式的。于是，I/O管理器应当能够处理来自各种来源和/或各种域和网络的用户交互，并且能够向不同设备或模式发送输出事件。

通常，基于本发明实施例的多模式I/O管理器以独立于输入模式的方式对用户输入进行抽象，并且发送这些抽象输入事件以便由CAFDMAF或其它CAF部件(或其它可能不涉及CAF的应用程序)进一步处理。如上所述，输入事件可以被标记其来源，以确定对事件进行的处理的性质(例如，事件是否应当被消除歧义等等)。另外，I/O管理器可以从CAF DMAF、其它CAF部件或可能不涉及CAF的其它应用程序接收抽象输出事件。I/O管理器将抽象输出事件转换成可被一或多个不同通道(设备、模式等等)理解和执行的命令，并且接着向适当通道发送转换的抽象事件。

图8图解了基于本发明实施例、用于提供多模式I/O管理的系统和方法。多模式I/O管理器包括中央I/O管理器200和多个I/O代理201、202(或″模式代理″)，所述I/O代理在操作中与中央I/O管理器200通信。应当理解，图中为了图解的目的示出了2个I/O代理，而多模式I/O管理器可以包括多于2个的I/O代理。中央I/O管理器200充当各种模式I/O代理201、202与CAF之间的中介。各个I/O代理201、202实现针对中央I/O管理器200的接口和其支持的特定设备的接口。各个I/O代理处理特定模式，并且负责通过模式所理解的API收集来自模式的事件。

更具体地，各个I/O代理201、202包括与中央管理器200通信的接口，以及与相应设备驱动程序201b、202b通信的接口201a、202a(例如GUI的可访问性API、浏览器的DOM、电话语音的电话API等等)。各个设备201c、202c包括在中央I/O管理器200上注册并且使用公共消息协议与中央I/O管理器200通信的相关I/O代理201、202。中央I/O管理器200处理与其它CVM部件的所有通信，于是将CVM平台与设备相关信息屏蔽开。

各个模式代理最好至少能够向中央I/O管理器200发送焦点更新(如果存在)。可以发送的所有其它事件最好留给模式代理或应用程序开发者决定。

这类似于发送与各个事件相关的ID标签。除ID标签之外，还可以使用其它机构，例如IP寻址或用于设备套接字或URI等等的其它地址。此外，CAF发送到中央I/O管理器200的输出事件包括目的地址(例如焦点或ID标签)。

公共交换协议最好被用于模式代理和中央I/O管理器200之间的通信，这允许各个模式代理发送：(i)焦点更新；(ii)输入通知事件(和相关信息，例如流位置等等)；(iii)已经封装在DMA的堆栈所存储的CAF历史记录中的事件；和(iv)输出通知/控制(和相关信息、例如流位置等等)。

各个I/O代理201、202在中央I/O管理器200上注册。在通信期间，向中央管理器200发送输入事件的I/O代理可以通知中央I/O管理器200输入事件需要引擎支持，从而指定如何从输入流提取数据。此外，接收输出事件的I/O代理可以请求引擎支持，从而指定应当如何提供输出数据。此外，I/O代理可以请求对输入事件仲裁(象针对语音的情况那样)，使得中央I/O管理器通过用于仲裁的rDMA层次结构发送输入通知事件。此外，I/O代理可以指定将输入/输出放在历史库中，在这种情况下中央I/O管理器200可以将特殊消息通知相关rDMA，或者直接与负责应用程序的DMA联系。此外，对于焦点更新，中央I/O管理器200向rDMA发送特殊通知以更新焦点，并且向适当DMA进行发送。

发送到中央I/O管理器200的所有事件最好被加上时间标签，使得可以实现来自多个模式的事件之间的同步。中央I/O管理器200与rDMA通信并且从各个I/O代理接收消息。当需要支持新模式时，需要针对该模式编写模式代理，并且接着在CAF的输入/输出管理器上注册模式代理自身。

此外，I/O代理可以是本地的，也可以分布在网络上。当为分布式时，许多协议可用于支持通信和注册。例如这里可以实现XML协议堆栈(例如SOAP(简单对象存取协议)，UDDI(通用描述、发现和集成)，WSDL(Web服务描述语言)等等)(例如参见http：//www.w3.org/2000/xp/)。此外，可以实现如上述国际专利申请PCT/US99/22925中描述的通信协议，以提供本地和远程应用程序之间的通信和注册。

这里可以实现基于本发明的I/O代理的各个实施例。例如，图9是基于本发明实施例的I/O代理的模块图。在图9的示例性实施例中，使用开放DOM(文档对象模型)(至少为二级)接口的现有浏览器实现的I/O代理。DOM协议是本领域已知的(HTTP：//www.w3.org/DOM/)。在2000年12月4日提交的美国临时专利申请60/251,085中公开了这里可以实现的模块化DOM多模式浏览器的优选实施例，该专利申请同样得到转让，并且这里参考引用了该专利申请。

更具体地，通过I/O管理器接口203和DOM接口204，I/O管理器200接收与充当I/O代理的注册浏览器205相关的I/O事件。通过更新浏览器205的状态和呈现的DOM命令，I/O管理器200可以修改和产生输出。这个方案的优点在于可以实现现有浏览器(假定它们至少符合DOM Level 2标准)。浏览器205还提供与相关I/O设备驱动程序206的高级接口，和对应的外设207。浏览器205也可以提供高层抽象，包含容易地预处理输入和输出的能力。例如，语音浏览器可以执行某种级别的语音识别，并且只向I/O管理器传递高层抽象的事件。因此，也可以在高层抽象上产生输出命令，从而提供例如文本-显示或提示，而不是实际绘制屏幕或窗口，或精细控制文本-语音引擎。

假定I/O代理包括GUI模式代理，I/O代理最好维护每个应用程序的注册表，其中注册表包括应用程序希望在CAF上注册的各个部件。对于注册表中的各个部件，GUI代理最好使用可访问性接口捕捉所需的事件。开发人员的应用程序部件会实现可访问性接口。

假定I/O代理包括多模式浏览器，浏览器模式代理最好被实现成模块，该模块使用DOM接口侦听某些事件，并且当这种事件出现时通知输入管理器。在多模式浏览器的情况下，当浏览器不支持精细流程对话时，不需要CAF。在这种实施例中，多模式I/O管理器在操作中连接在特定于传统模式的浏览器和多模式命令解释程序之间。当使用CAF时，多模式I/O管理器在操作中可以被连接到多模式命令解释程序或DMAF。当针对电话应用程序实现I/O代理时，电话模式I/O代理与现有电话API接口。

此外，通过使用相同的I/O管理器构思，可以根据传统VoiceXML浏览器建立VoiceXML DOM浏览器，其中管理器提供DOM接口，并且传统VoiceXML浏览器是语音代理。

应当理解，可以说明式地，命令式地，使用脚本或其任意组合来实现上述使用浏览器的实施例。例如，考虑使用Java的命令式情况，其中应用程序或applet符合本领域众所周知的Java可访问性类/实用程序(例如参见HTTP：//java.sun.com/products/jfc/#download-access)。象在DOM接口的情况中那样，Java可访问性实用程序包提供查找和查询Java虚拟机中运行的应用程序内的用户接口对象的支持辅助技术。它也支持在这些对象中安装″事件监听器″。实用程序提供说明如何允许辅助技术与Swing部件中建立的可访问性API支持进行交互的例子工具。通过捕捉事件并操纵用户接口单元，可以执行相同种类的I/O管理。也可以使用提供类似实用程序的其它程序包，例如ActiveX和DCOM。

可以将任何其他接口(DOM或可访问性)扩展到新的通道类型(例如语音、手写等等)。可以考虑提供类似功能或能力的其它接口或实用程序。当为分布式时，可以通过SOAP实现DOM(或DOM的结构)的远程控制。SOAP的优点在于程序调用更可能穿过防火墙和网关。当然，可以使用任何其他允许进行这些接口的远程控制的协议。

其它应用程序

应当理解，通过使用这里描述的所有或一部分特征和机构，可以通过各个方式实现其它实施例。例如考虑语音或会话门户，比如在2000年4月7日提交的标题为″根据需要提供会话浏览和多媒体广播的会话门户(A Conversational Portal For Providing ConversationalBrowsing and Multimedia Broadcast on Demand)″的美国专利申请09/545,078中描述的门户。图10中图解了基于本发明实施例的语音或会话门户。通过门户网关300访问语音门户。门户包括中央I/O管理器301，门户CAF 302(包含诸如rDMA和任务管理器的CAF部件)，门户浏览器303，和均使用相关aDMA 305、308与浏览器306、309的多个应用程序。多个引擎304、307、310被用于提供与对应应用程序相关的会话服务。

门户包括用户希望与之交互的各个应用程序的浏览器。对门户应用程序的访问可以基于电话号码(当通过门户提供时，最好是用于访问应用程序的号码)，或URL(由ISP或无线(会话、多信道或多模式)接入提供商的网关300截取)。用户可以与门户提供的不同应用程序交互，其中门户根据例如用户预订的应用程序列表，用户偏好或用户以往的历史记录，或简单地根据用户与门户的交互的演变结果提供所述应用程序。应当理解，不同应用程序和对应浏览器可以位于应用程序提供商的站点上，而不是由门户站点上的门户提供。

当应用程序浏览器306、309支持上下文管理和自由流程/混合主动方式时，各个浏览器或者在操作中连接到aDMA 305、308，或者包括aDMA 305、308。当浏览器只提供对基于语法的对话的支持时(例如当前VoiceXML 1.0(HTTP：//www.voiceXML.org)所支持的)，可以简化仲裁算法(例如探索式算法)和aDMA功能。因此，根据识别的文本和得分较高的语法，能够以较高的概率确定用户输入的接收方。当语法发生重叠时(例如应用程序具有当前焦点等等)，应当使用某些探索式算法。也可以直接对GUI通道(和通常情况下，因为焦点无歧义而不需要单独处理的通道)进行仲裁--其中用户点击的位置是焦点最可能位于的位置。当输入有歧义时，门户提供商可以使用门户rDMA302，并且可能通过门户浏览器303和门户CAF 302的aDMA提供高层服务。

在另一个实施例中，应用程序之间的切换受到限制，使得用户必须明确指示这种切换的浏览器(例如通过为针对其它应用程序的显式切换提供命令)。这种命令会由门户aDMA及其相关应用程序(识别这种指令)管理。例如，这种命令可以是特定命令或关键字：到financeXXX或travelXXX站点。这种机构基本上类似于如上所述用于进入提供应用程序内的听写模式的机构。

最终，基于安全原因，门户、用户和应用程序提供商可以如上所述决定接受或拒绝在支持的应用程序之间共享用户I/O(传入发声、传出发声)和上下文(短期和长期历史库)。

在示例性实施例中，使用例如美国专利申请09/703,574中描述的适当会话传送协议，可以向各个″活跃″浏览器(所有或唯一的当前共享处理的浏览器)传送音频(和其它可能的多模式或多模式事件)。

应当理解，可以通过各种形式的硬件、软件、固件、专用处理器或其组合来实现这里描述的系统和方法。具体地，本发明最好被实现成这样的应用程序，该应用程序包括被实际包含在程序存储设备(例如软磁盘、RAM、ROM、CD ROM等等)中，并且可被包括适当体系结构的任何设备或机器执行的程序指令。还应当理解，由于在附图中描述的某些组成系统部件和处理步骤最好通过软件实现，所以系统模块之间的连接和所述方法的逻辑流程会因编程本发明的方式而有所不同。根据这里提供的指导，本领域普通技术人员会能够想到本发明的这些和类似实现或结构。

虽然这里已经针对附图描述了说明性的实施例，但应当理解，本系统和方法不局限于这些详细的实施例，并且本领域的技术人员在不偏离本发明的范围和宗旨的前提下可以进行各种其他的改变和修改。所有这样的改变和修改均应当被包含在如所附权利要求书所定义的本发明的范围内。

Claims

1.管理一或多个应用程序的对话的方法，包括的步骤有：

由根DMA向应用程序DMA发送有关用户输入事件的通知；

由应用程序DMA得到用户输入事件的符号表示；

2.如权利要求1所述的方法，其中实例化DMA接口的步骤包括由应用程序在根DMA上注册以得到应用程序DMA句柄。

3.如权利要求2所述的方法，其中注册步骤包括注册算法串，所述算法串包括应用程序为处理用户输入所需的引擎的集合和顺序。

4.如权利要求1所述的方法，其中实例化DMA接口的步骤包括实例化用于管理应用程序主对话的主DMA，和实例化主DMA的用于管理应用程序的子对话的多个子实例。

5.如权利要求1所述的方法，其中确定应用程序DMA当前是否活跃的步骤包括：使用自底向上仲裁协议确定查询是否其它应用程序DMA接收的所有查询中间具有最高计分的查询的步骤。

6.如权利要求5所述的方法，其中根据应用程序注册的安全设置在友员应用程序之间执行仲裁。

7.如权利要求5所述的方法，其中使用自底向上仲裁协议的步骤包括：

由层次树中的各个父应用程序DMA在从作为父的子的应用程序DMA接收的查询之间进行仲裁；和

由根DMA在从根DMA的子应用程序DMA接收的查询之间进行仲裁，以确定是否存在总胜出查询。

8.如权利要求7所述的方法，还包括步骤：

由父DAM忽略在预定时间周期内不提供查询的子DMA；和

应子DMA的请求而扩展预定时间周期。

9.如权利要求7所述的方法，还包括步骤：

由根DMA产生仲裁结果，仲裁结果包括总胜出查询和相关的应用程序DMA；和

由各个父应用程序DMA向各个子应用程序DMA发送有关仲裁结果的通知。

10.如权利要求1所述的方法，其中启动回调函数的步骤包括使用命令注册表确定与查询关联的回调函数。

11.如权利要求1所述的方法，其中符号表示包括语音识别结果，自然语言理解结果及其组合中的一个。

12.如权利要求1所述的方法，还包括由DMA接口维护短期历史库的步骤，所述短期历史库包括与用户输入事件相关的事件。

13.如权利要求1所述的方法，还包括由DMA接口维护长期历史库的步骤，所述长期历史库包括与执行的任务相关的事件。

14.如权利要求1所述的方法，还包括由DMA接口维护焦点历史库的步骤，所述焦点历史库跟踪对话会话期间的活跃应用程序。

15.如权利要求1所述的方法，还包括在上下文解析期间在应用程序和应用程序DMA之间进行协作以消除相关查询的歧义的步骤。

16.如权利要求15所述的方法，还包括使用短期历史库，长期历史库，焦点历史库及其组合中的一个消除查询的歧义的步骤。

17.如权利要求1所述的方法，还包括在必须向用户提供一个消息的情况下产生具有适当模式的消息的步骤。

18.如权利要求17所述的方法，其中产生具有适当模式的消息的步骤包括由特定于模式的I/O代理将独立于模式的输出事件转换成特定于模式的输出事件。

19.如权利要求1所述的方法，其中如果回调函数包括听写模式，则通知根DMA向应用程序DMA发送所有输入事件。

20.如权利要求19所述的方法，还包括响应用户输入命令而终止听写模式的步骤。

21.一种对会话管理器和仲裁器DMA接口装置，包括：

多个应用程序DMA，用于在应用程序内的多个子对话中间进行仲裁，以确定管理与用户输入关联的子对话的目标应用程序DMA，其中至少一个应用程序DMA与每个应用程序相关联；

其中DMA接口包括层次树结构，并且DMA接口使用自底向上方案执行仲裁。

22.如权利要求21所述的DMA接口装置，其中在多模式平台中实现DMA接口。

23.如权利要求21所述的DMA接口装置，其中DMA接口存储和管理应用程序信息。

24.如权利要求21所述的DMA接口装置，其中各个根DMA和应用程序DMA维护针对指定用户输入产生的事件的列表。

25.如权利要求21所述的DMA接口装置，其中各个根DMA和应用程序DMA维护为一给定的对话已经执行了的任务的列表。

26.如权利要求21所述的DMA接口装置，还包括与应用程序协作以消除用户输入事件的歧义的机构。

27.如权利要求21所述的DMA接口装置，其中根DMA包括维护注册应用程序DMA的列表的注册表，并且根DMA跟踪当前活跃的注册应用程序DMA。

28.如权利要求21所述的DMA接口装置，其中根DMA与I/O管理器通信，I/O管理器将用户输入事件抽象成独立于模式的事件以便被DMA接口处理，并且I/O管理器将抽象输出事件转换成一或多个特定于模式的输出事件。

29.如权利要求28所述的DMA接口装置，其中I/O管理器包括中央I/O管理器和针对基础平台支持的各个模式的模式代理。

30.如权利要求29所述的DMA接口装置，其中中央I/O管理器使用基于XML的公共消息协议与各个模式代理通信。

31.如权利要求21所述的DMA接口装置，其中应用程序DMA与使用一或多个会话引擎的任务管理器通信，任务管理器包括跟踪与应用程序DMA相关的线程的线程池管理器，和与会话引擎API通信的引擎管理器。

32.如权利要求31所述的DMA接口装置，其中引擎管理器与资源管理器通信，资源管理器指定任务管理器所请求的资源。

33.如权利要求21所述的DMA接口装置，还包括根据一或多个应用程序注册的安全设置控制应用程序DMA之间的信息交换的安全机构。

34.如权利要求33所述的DMA接口装置，其中安全机构仅在友员应用程序中间提供仲裁。

35.如权利要求34所述的DMA接口装置，还包括在友员应用程序组之间切换仲裁功能的机构。

36.如权利要求33所述的DMA接口装置，其中安全机构包括数字证书认证。

37.如权利要求33所述的DMA接口装置，其中安全机构包括加密信息交换。

38.如权利要求21所述的DMA接口装置，包括可插式仲裁协议。

39.如权利要求38所述的DMA接口装置，其中所述可插式仲裁协议包括探索式算法、确定性算法和统计算法中的一个。

40.如权利要求21所述的DMA接口装置，其中在语音门户中使用DMA接口。

41.如权利要求40所述的DMA接口装置，其中各个应用程序包括与主应用程序DMA通信的应用程序浏览器。