本申请一般地涉及会话系统，并特别涉及一种用以在网络连接的 设备、服务器和应用程序之间自动及协同共享会话功能/资源的系统和 方法。

传统的会话系统(即，单纯具有语音I/O的系统或者具有语音I/O 的多模式系统)一般地被限于个人计算机(PC)和具有合适结构和足 够处理能力的本地机器。另一方面，对于电话技术应用，会话系统通 常位于一服务器上(例如，IVR服务器)并可以经由传统电话和蜂窝 电话而能访问。尽管这种会话系统变得更为流行，有代表性的是所有 的会话处理或者在客户机端或者在服务器端执行(即，所有的配置或 者是完全本地的或者是完全客户机/服务器式)。

随着普及计算的出现，期望数十亿计的低资源客户设备(例如， 个人数据助理PDA，智能电话等)将被连网在一起。由于客户设备尺 寸的减小和用户所期望这种设备所执行任务的复杂性的增加，传统的 图形用户界面在这种小型的用户设备上不切实际，所以用户界面成为 一个关键性的问题。因此，期望会话系统将作为用户界面的主要单元 来提供纯语音/音频I/O或带有语音/音频I/O的多模式I/O。

从而，在便携式客户设备上，语音嵌入的会话应用正得到发展并 进入成熟。不幸的是，由于资源有限，预期这种客户设备可能不能执 行复杂的会话服务，例如语音识别(尤其是当词汇量非常大或特殊或 者需要领域特定/应用特定的语言模型或语法时)、NLU(自然语言理 解)、NLG(自然语言产生)、TTS(文本到语音合成)、音频捕捉和压缩 /解压缩、重放、对话产生、对话管理、说话者识别、主题识别、音频 /多媒体索引和查找等。例如一个设备的存储器和CPU(和其他资源) 的限制可以限制这种设备能提供的会话能力。

此外，即使一已联网设备功能足够强大(在CPU和存储器方面) 以便执行所有这些会话任务，但该设备可能没有合适的会话资源(例 如，引擎)或者会话主目(argument，即被引擎用到的数据文件)(例 如，语法、语言模型、词汇表文件、语法分析、标记、声纹和TTS规 则等)来执行合适的任务。确实，一些会话功能可能太特殊而适于特 定的服务，因此要求仅能从网络上的其它设备或者机器才可得到的后 端信息。例如，因为用来产生对话需要的整组会话主目或者功能(例 如语法分析器、标记器、翻译器等)或者需要很大数量的存储器来存 储(在客户设备上不能得到)或者太广泛(依据通信带宽)以至于不 能传递到客户机端，所以一个客户设备上的NLU和NLG服务典型地需 要服务器端支持。这个问题在多语种应用时被进一步加重，当一个客 户设备或者本地应用程序没有足够的存储器或者处理能力来存储和处 理这些主目，这些主目是需要的，以便按多语种来处理语音和执行会 话功能。代之，用户必须手动连接到远程的服务器上来执行这种任务。

同时，与客户机和服务器间的分布式结构和分布式处理有关的问 题需要新的会话连网方法。这种方法包含了通信量和分布在网络上的 资源的管理，以保证参与该网络上会话交互的每一个用户的合适的对 话流。

因而，允许一个有有限资源的网络设备自动利用连网资源、以一 种对用户来说自动的和透明的方式来执行复杂的会话任务的系统和方 法是非常需要的。

本发明针对一种在网络连接的服务器和设备(和它们相应的应用 程序)之间提供自动的和协同的共享会话资源的系统和方法。根据本 发明的一个实施例，系统包含多个连网的服务器、设备和/或应用程序， 通过使用会话网络协议(或者方法)传达消息，使得相互之间“明白 会话”，协议自动地允许每一明白会话的网络设备自动地并以协同和同 步的方式共享会话资源，以便通过某一网络设备之一的界面来提供一 个无缝的会话界面。

根据本发明的一个方面，一个提供自动的和协同的共享会话资源 的系统，包含：

一个网络，它包含至少第一和第二网络设备；

这第一和第二网络设备每个包含

一组会话资源；

一个对话管理器用以管理会话并执行调用来请求会话服务；以及

一使用会话协议在整个网络上传达消息的通信栈，在此通过会话 协议传达的消息在第一和第二设备的对话管理器之间建立协同的网络 通信，以自动地共享第一和第二网络设备成组的会话资源，当需要时， 去执行它们各自请求的会话服务。

本发明允许一个低资源的客户设备透明地本地执行简单的任务， 又以二进制或模拟方式与一具有更复杂会话能力的服务器(或者别的 设备)相连接透明地执行复杂任务。服务器端的功能(例如语音识别) 可以通过一个常规的IP网络或者LAN网络，也可以经由传统的电话线 路或包交换网络数字传输，或者在无线网络上经由任何传统的无线数 据协议而能被执行。

有利的是，本发明在任何有限CPU、存储器和处理能力(也含有 限的会话资源)的设备(如盛行的嵌入式设备)上提供一完全成熟的 会话用户界面，这使利用低资源的客户设备不需要下载，例如来自一 网络服务器所必需的会话主目，便可提供复杂的会话服务。本地能力 允许用户利用本地设备而不需请求连接，例如无线电话供应商的外部 覆盖。同时，持续连接的花费也减小，并且当持续连接丢失时恢复的 难度能够减轻。

在接下来的优选实施例的详细描述中，本发明的这些和其他方面、 特征及优点将会被描述并变得明了。

图1是根据本发明的一个实施例在连网的设备之间通过自动的和 协同的共享会话资源来提供会话服务的一个系统框图；

图2是根据本发明的一个方面在连网的设备之间通过自动的和协 同的共享会话资源来提供会话服务的一个方法流程图；

图3是根据本发明的另一个方面在连网的设备之间通过自动的和 协同的共享会话资源来提供会话服务的一个方法流程图；

图4是根据本发明采用会话浏览器的另一个实施例提供会话服务 的分布式系统的一个框图；以及

图5是根据本发明采用会话浏览器的另一个实施例提供会话服务 的分布式系统的一个框图。

将会了解到本发明可以被以不同形式的硬件、软件、固件、专用 处理器或者它们的组合实现。更可取地，本发明作为一个包含程序指 令的应用程序以软件实现，它们确实地嵌入在程序存储器设备上(例 如软盘、RAM、CDROM、ROM和闪存器)，并且可以被任何设备或者包含 合适结构的机器执行，如一个或者多个中央处理器(CPU)、一随机存 取存储器(RAM)和音频输入/输出(I/O)接口。

将会进一步了解，因为在附图中描述的组成系统的某些部件和方 法步骤优选以软件实现，系统组件之间的实际联系(或者处理步骤) 随本发明被编程的方式而可能不同。此间给出的说明，一个相关领域 的一般技术人员将能设想到本发明的这些和相似的实现方法或结构配 置。

现参看图1，框图阐明了根据本发明的一个具体范例在连网设备 之间通过自动的和协同的共享会话资源和会话主目(数据文件)来提 供会话服务的一个系统。该系统包含一本地客户设备100，客户设备 100包含一个声学前端101来处理音频/语音输入和输出由客户设备 100产生的音频/语音。例如，客户设备100可以是一个智能电话或任 何能处理语音的PDA(个人数字助理)。客户设备100还包含一个或者 多个本地会话引擎102用来处理声特征和/或由声学前端101产生和/ 或捕捉的波形并产生对话输出给用户。本地会话引擎102可以包含， 例如，一个嵌入式语音识别，一个说话者识别引擎，一个TTS引擎， 一个NLU和NLG引擎和一个音频捕捉和压缩/解压缩引擎及任何其它类 型的会话引擎。

客户设备100还包含一个本地对话管理器103它执行任务管理并 控制和协同一经由系统调用(API或者协议调用)请求的会话服务(或 者本地的或者经由网络设备)的执行，同时也管理本地的和与连网设 备的会话。更特别地，如下所详细描述的，对话管理器103确定是否 一个给定的会话服务将在客户100上本地地或者是在远程网络连接的 服务器(或者设备)上处理和执行。这个决定是基于如客户100的会 话能力和其它网络连接的设备能力的比较等因素，也基于为处理这一 请求的会话服务可能必需的可用资源和会话主目。其它因素包栝从连 网的设备接收结果时网络通信量和预期的延迟。对话管理器103执行 任务管理和资源管理任务，如装载管理和资源分配，同时也管理本地 会话引擎102和能处理语音的本地应用程序104之间的对话。

如图1的示例，客户设备100经由网络105与服务器106连网， 服务器106包含服务器应用程序109，也包含向客户设备100(或者任 何其它网络设备或者应用程序)在需要时提供会话服务的服务器会话 引擎107。和本地会话服务器引擎102一样，服务器引擎107可以包 含如一个嵌入式语音识别、一个TTS引擎、一个NLU和NLG引擎和一 个音频捕捉和压缩/解压缩引擎及任何其它类型的会话引擎。服务器 106包含一个服务器对话管理器108，服务器对话管理器108操作方式 和上面描述的本地对话管理器103相同。例如，服务器对话管理器108 确定是否一个从本地对话管理器103来的一个会话服务请求被服务器 106或者是远程网络连接的服务器或者设备处理和执行。此外，服务 器对话管理器108管理服务器会话引擎107和能处理语音的服务器应 用程序109之间的对话。

图1的系统进一步描述了客户设备100和远程服务器106被连网 到一个有会话引擎和/或能被客户100和服务器106在需要时存取的会 话主目的服务器110上。网络105可以是如因特网、LAN(局域网)、 公司内部网、PSTN(公共交换电话网)、或者无线网(经由RF(射频)、 或者IR(红外线)无线通信)。可以理解，尽管图1描述了一个客户 机/服务器系统，其中术语可以被擅长该技术的人理解，图1的系统可 以包含许多连网的服务器、设备和相互“明白会话”的应用程序来提 供自动的和协同的共享会话功能、主目和资源。如下文更详细的说明， 这种“明白会话”可以通过利用会话网络协议(或者方法)传输被各 自的对话管理器处理的消息来达到，使连网的设备以一种自动的和同 步的方式共享会话资源和功能。这种会话协同提供了一个无缝的会话 界面，通过网络设备之一的界面来访问远程服务器、设备和应用程序。

特别是，在连网设备之间提供会话协同来共享它们的会话功能、 资源和主目，每一连网设备利用会话协议(或者方法)传递消息来交 换关于它们会话能力和需求的信息。例如，如图1所示，客户设备100 包含一个利用会话协议112、会话发现、注册和协商协议113和语音 传输协议114(或者会话编码协议)用以传送和接收消息的通信栈111。 同样，服务器106包含一个服务器通信栈115，服务器通信栈115包 含会话协议116、会话发现、注册和协商协议117和语音传输协议118。 这些协议(方法)在同时递交的、名称为“Conversational Computing Via Conversational Virtual Machine”的专利申请(IBM Docket NO. Y0999-111p)中相对于CVM(会话虚拟机器)得以详细讨论，此专利 已一般转让，此处加以引用。

简单的说，会话协议112、116(或者说是在Y0999-111P中称为 “分布式会话协议”)是允许连网设备(例如，客户机100和服务器 106)或者应用程序与其它网络设备的对话管理器传输消息，以便注册 它们的会话状态、主目和上下文的协议(或者方法)。会话协议112、 116也允许设备交换其它信息如Java小应用程序、ActiveX构件和其 他可执行的编码，这些编码允许设备或者相关的应用程序来协调按照 如主/从或对等会话网络配置的这些设备之间的会话。分布式会话协议 112、116允许信息交换来协同包含多设备或者应用程序，包括主/从 会话网络、对等会话网络和匿名伙伴的会话。在连网设备之间利用分 布式会话协议可以交换的信息包含指向数据文件(主目)的指针、数 据文件和其他会话主目的传输(如果需要)、输入通知、输出事件和识 别结果、会话引擎API调用和结果、状态通知和上下文改变及其他系 统事件、注册更新：注册协商更新的握手信号：协商握手信号、及当 一请求的资源丢失时的发现更新。

本(分布式)会话协议也包含对话管理器(DM)协议，此协议允 许对话管理器去分配服务、行为和会话应用、I/O和引擎API如在IBM Docket NO.Y0999-111P中所描述的。例如，DM协议允下列信息被交 换：(1)DM体系结构注册(例如，每一DM可以是本地DM的汇集)；(2) 与元信息关联的指针(用户、设备能力、应用需求等)；(3)DM网络 拓扑协商(例如，主/从、对等)；(4)数据文件(会话主目)如果可 用，即，如果引擎被利用则被一个主DM控制；(5)I/O事件通知，如 用户输入、输出到多个用户以传输到引擎和/或加到上下文；(6)识别 事件通知；(7)传输被处理的输入从引擎到一主DM；(8)传输主DM 的职责到注册的DM；(9)DM处理结果事件；(10)DM异常；(11)可 信度和模糊性结果的传输，建议的反馈和输出，建议的期望状态，建 议的操作，建议的上下文改变，建议的新的对话状态；(12)通知决定， 上下文更新，动作更新，状态更新等；(13)完成、失败或者被中断动 作通知；(14)上下文改变通知；和/或者(15)由于动作引起的数据 文件、上下文和状态的更新。

例如，在主一从网络配置中在任何时候仅仅连网设备之一驱动会 话。特别是，主设备(即主设备的对话管理器)管理和协调网络设备 间的会话并决定哪一设备来执行给定的会话服务或功能。这个决定可 以基于每一设备或者应用程序提供的关于它们会话能力的信息。这个 决定也可以基于主设备决定那一个从设备(具备所需的会话能力)能 最佳地执行给定的会话功能。例如，主设备可以要求多个从设备来执 行语音识别并提供结果给主设备。主设备然后选择最佳的结果。可以 理解这里在语音识别水平上所描述的是分布式对话管理器之间在DM (对话管理器)协议水平上的机制(如在Y0999-111P中所描述)。确 实，当在多个对话管理器之间发生对话时，主设备将获得每一对话管 理器结果得分的度量，从而作出决定看好哪一个对话管理器继续进行 输入，不但要根据语音识别的准确性，并且也要根据对话(含意)、上 下文和历史，也考虑其他项目，如用户的优先选择、历史和应用的偏 好。

在对等连接中，每一设备将试图确定自己能执行的功能并记录一 个请求去执行之。可接受到任务的设备将执行这个任务然后对其执行 性能评分。然后依据它们的评分设备协商哪一个设备将执行这个任务。

在一个实施例中，分布式会话协议112、116经由RMI(远程方法 调用)和RPC(远程过程请求)系统调用，以完成应用程序和整个网 络上不同会话引擎之间的调用来实现。行内人都知道，RPC是允许一 个应用通过网络从另一个应用请求一个服务的协议。同样地，RMI是 在分布式网络上对象可以交互的一种方法。RMI允许一个或者多个对 象随同请求被传递。此外，信息也可以被存储在一个对象中，该对象 经由CORBA或者DCOM被交换，或者以说明性的方式呈现(例如经由 XML)。如在上面插入的专利申请IBM Docket NO.Y0999-111P中所讨 论，会话协议(方法)(或者分布式协议)可以被用来经由会话API在 会话应用和CVM命外壳之间或者经由会话引擎API在CVM和会话引擎 之间获得由一个CVM(会话虚拟机器)外壳支持的会话功能的分布式 实现。会话引擎API是核心引擎和应用程序之间的界面，通过这个界 面和协议与核心引擎(本地的或者连网的)通信。会话API提供一个 API层来挂钩或者发展明白会话的应用，包括建立会话用户界面的基 础类和组件。

同样地，根据本发明一对话管理器可经由API与应用程序和引擎 (本地的或者连网的)通信。通过这种方式，一对话管理器可以对来 自所有远程过程的结果和回调起作用(对远程引擎和应用程序的过程 调用)，如同它是一个本地的应用，以至于，例如，在应用和资源(本 地的或者连网的)之间仲裁、区分优先次序和确定激活的应用，以及 确定那一个结果认为是有效的。

会话发现、注册和协商协议113、117是被用作“发现”本地的或 者网络的明白会话的系统(即“讲”会话协议的应用程序或者设备) 的网络协议(或者方法)。注册协议允许设备或者应用程序注册它们的 会话功能、状态和主目。协商协议允许设备协商主-从、对等或者匿名 伙伴网络。

在一个实施例中，发现协议实现一个“广播和收听”方法来触发 一个从其它“广播和收听”设备来的反应。这能允许如网络动态地和 自发地创建(例如下面讨论的蓝牙和Hopping网络)。在另一个实施例 中，一个缺省的服务器(可能是主设备)装置可以被利用它注册不同 网络设备的“地址”。在这个实施例中，发现总计网络上与服务器通信 的各个设备来核对注册的设备列表，以便确定那些设备与这些设备连 接。经由发现协议交换的信息包括如下：(1)握手信号的广播请求或 者收听请求；(2)设备标识符交换；(3)第一次注册时的句柄/指针交 换；和(4)第一次协商时的句柄交换。

在实现注册协议的一个实施例中依据连接，设备可以以一预定的 协议(例如，TTS英文、任何文本、语音识别、500字+FSG语法、无 说话者识别等)通过交换一组标志或一设备特性对象来交换关于它们 会话能力的信息。同样，应用程序可以交换引擎需求列表。通过一个 主/从网络配置，主对话管理器可以编辑所有列表并使功能和需要与会 话能力相匹配。在没有主设备(对话管理器)的情况下，一个普通服 务器可以被用来传输会话信息到网络上每一个机器或者设备。注册协 议允许以下信息被交换：(1)能力和装载消息包括定义和更新事件； (2)引擎资源(是否一个给定设备包括NLU、DM、MLG、TTS、说话者 识别、语音识别压缩、编码、存储等)；(3)I/O能力；(4)CPU、存 储器和装载能力；(5)数据文件类型(范围指定、字典、语言模型、 语种等)；(6)网络地址和特征；(7)关于用户的信息(定义和更新事 件)；用户对设备、应用或对话的偏好；(9)用户化；(10)用户经验； (11)帮助；(12)每一应用(和应用状态)(定义和更新事件)的能 力需求；(13)CUI服务和行为的元信息(帮助文件、编目、会话优先 权等)(定义和更新事件、一般通过指向表格的指针)；(14)协议握手； 和/或(15)拓扑协商。

注册可以使用传统的通信协议如TCP/IP、TCP/IP29、X-10或者 CEBus和设备之间的套接口实现。设备利用一个分布式会话结构与它 们相关的会话引擎和对话管理器及它们的会话主目(例如，激活的词 汇表、语法和语言模型、语法分析和翻译/标记模型、声波纹、合成规 则、基本格式(发音规则)和声型)通信。这个信息或者以文件或者 以流的形式传递给对话管理器和会话引擎或者作为URL。此外，上下 文信息可以通过指示通路或者指到设备的上下文栈/历史，或控制器可 以访问和添加到其上下文栈的应用而能被传递。设备也传输关于它们 多模式I/O和UI能力(屏幕/无屏幕、音频入和出的能力、键盘等) 的信息。会话主目允许会话引擎基于当前状态和上下文估计NLU引擎 有关的新询问。

至于协商协议，依据各个网络设备的注册需求和能力，在协商期 间网络设备和应用程序可以对一给定的暂时性配置进行投票。如果一 个应用利用此配置(即拓扑)，则决定被自动地强加。否则它可以是请 求成为一个主设备或者从设备或者对等机。根据请求计数，一个优选 的配置被决定并与所有的设备和应用程序通信(保持在每个设备/应用 程序的可用资源表格中)。无论什么时候一个系统改变它的状态和需求 时，它将会与其它连网的对话管理器/资源通信来开始一个新的协商并 沟通新的状态和上下文信息。

语音传输协议114、118允许设备传送和接收压缩的语音或者本地 处理结果到/从网络上的其它设备和应用程序。会话引擎102、107更 适宜包括压缩/解压缩引擎用以传输时压缩语音(或者结果)和为了本 地处理对通过网络从另一设备或应用程序获得的压缩语音(或者结果) 进行解压缩。语音传输协议被在设备中执行的语音传输的客户机利用 来向/从其它连网设备、系统或者应用程序传送/接收被压缩的语音进 行处理。设备的语音传输客户机与压缩、解压缩和重建引擎联合操作， 利用合适的压缩硬件，处理通过网络传输的语音。语音编码器提供感 知可接受的或可理解的被压缩语音的重建和优化的会话性能(如，字 错率)。语音在各自的连网设备上利用声信号处理引擎(音频子系统) 和合适的音频硬件被捕捉(和转换成特征)。此外，压缩的语音文件格 式在处理语音的设备之间可以被传输和接收。特别是，语音传输协议 允许设备向/从网络上的其它设备和应用程序传输和接收压缩的语音 或本地的处理结果。在一个实施例中，当在一个传输设备和一个接收 设备之间握手处理后，一数据流(基于信息包)被发送到接收器。包 的头最好指出为编码此语音(或者结果)所利用的编码方案和编码主 目(即，抽样频率、特征特性、维数、前端应用的变换、前端的性质 等)。此外，纠错信息也可以被引入(例如，如果前一个包丢失或者延 迟，前一个包的最后特征矢量纠正差动解码器)或者合适的消息来恢 复(重发)这些丢失的包。

此外，对话管理器可以经由对话管理器协议或者DM协议通信。 (如在上面引用的IBM Docket No.Y0999-111P中所讨论的)。DM协 议可以被用来在多个对话管理器之间协商哪个对话管理器被激活，或 者哪个对话管理器应该接收该输入。因为在本实施例中，服务器资源 仅仅当被真正需要时被“轮询”，DM协议提供一种变化：本地对话管 理器进行一预先测试以决定是否此功能应该被远程执行。在有错误产 生或者存在疑惑的情况下，对话管理器可以等待本地引擎的推测并在 仍存有疑惑时决定轮询一服务器来比较。

因此，根据上面的讨论，应该明白网络协议提供在连网设备之间 的协同(或者一个协同界面)来共享会话服务和功能。术语协同界面 意味着一单个会话可以在不同的参加者(设备/应用程序)之间被把握， 如同它们都理解整个会话并合适地知道在任意给定的时间谁被访问。 每一会话系统的行为或者应用可以被对话管理器(例如，主-从模式中 的主设备)、应用(此应用可以确立谁是主、从或者对等)、系统对话 管理器(如果有)、组织和协商(在对等模式中)控制/管理，在合适 的系统上对用户透明地执行每一会话功能。对于一个客户设备上的用 户来说，提供了一个无缝的会话界面(即，所有的会话交互似乎是经 由一个单一的会话系统)，尽管某些会话功能、系统和资源可能被提供 几个连网的设备(例如，一蜂窝式电话、一呼机和一PDA)。

协同的会话系统的一个例子(上面描述的公开在前面引用的的IBM Docket No.Y0999-111P中)是称作UCA(通用会话设备)的远程控制。 UCA发现明白会话的设备。每个会话连接的设备将发送它的会话主目 (词汇表和语法)到UCA。UCA作为这种设备的主设备并且当一会话交 互随同用户结果成为一命令到此设备时将更新适当的设备。相反地， 依据命令的执行或者每次设备改变状态时，它将发送一个更新到远程 控制。一个没有其他会话能力(除了相应主目)的会话设备是那个被 称作“匿名伙伴”的。

在另一个实施例中，一个服务器或者基站，除音频捕捉压缩和由 远程控制(或UCA)执行的传送外可以执行所有的会话功能。远程控 制也可以提供一些UI给用户来通知他/她不同设备的状态。这可以经 由语音、GUI或者这些形式(或者其它)的任何会话的组合完成。

尽管会话网络拓扑可以与图1的系统联系起来使用，一个最优的 网络拓扑是提供一种自发的动态连网(即，在一定的通信范围内的设 备之间自发的建立的一网络)。这种自发的连网可以通过应用当前新兴 的例如描述在http://www.bluetooth.com上的“蓝牙”连网协议实现。 简单地说，蓝牙是给网络协议的一个代号，蓝牙网络协议提供特别的 无线网络的连通性。更特别的是，蓝牙是在一个特定的范围内的设备 (例如，智能电话、蜂窝式电话、呼机、PDA、便携式电脑、移动设备 等)之间在特定的范围内提供短程无线射频链路来动态地和自发地在 这样的设备之间建立一个网络(或是大家知道的“piconet”(微网))。 一个微网指的是在网络连接的剩余期间与在每个微网中扮演主设备的 一个结点以特殊方式连接的蓝牙允许设备(结点)的集合。两个或更 多的微网可以被网络连接以构成所谓的一个“scatternet”(分散网)。

看得出，依照本发明任何自发的动态连网协议可以被实现。例如， 图1的网络拓扑可以依照在美国专利申请序列号No.09/198,378描 述的“hopping”通信网络实现，该专利申请1998年11月24日递交、 名称为“Automated Traffic Mapping”，此专利已一般转让，此处引 用以做参考。

现参看图2，图2是描述根据本发明的一个方面在连网设备之间 提供自动和协同共享会话功能的一种方法的流程图。特别是，图2进 一步详细描述了图1系统操作的一种方法。开始，用户发出一个口头 命令(或者否则发出一个询问)到本地客户设备，这个口头命令或询 问通过数字化或抽取数字化语音信号的相关特征而被预处理过(步骤 200)。作为选择，本地对话管理器可以接收从本地应用程序104传来 的请求产生合成语音(TTS)以输出到该用户(步骤200)。

(经由本地对话管理器103)决定本地处理是否可用(步骤201)， 例如，是否语音识别或者语音合成可在本地执行。对于这个决定可以 看出，本地对话管理器103可以明确地预先确定识别/合成必须在其上 发生的一个远程服务器，(例如，一IP地址对于套接口连接的、一URL 地址对于经由小服务程序(servlet)基于服务器登记，或者一电话号 码对于直接连接或连接到一个IVR的)。此外，本地设备没有可以利用 的资源或者主目来执行(或者有效地执行)一任务的确定，也可由对 话管理器103依据本地应用程序104的执行根据由该应用程序在头文 件中指示的资源需求而作出。另外，某些命令或者请求的功能可以引 起对话管理器自动地连接到一个远程服务器。例如，安全性应用程序 (如，说话者确认)可以自动地被切换到服务器端处理，所以声波纹 不被分配到客户机。再者，本地汽车导航系统可以利用电话或者基于 套接口的服务器能被自动地切换到远程服务器，以致于本地设备不必 存储大量的导航信息。

如果确定本地处理是可行的(肯定的确定在步骤201)，则处理将 经由本地引擎102在本地执行(步骤202)。另一方面，如果确定本地 处理是不可行的(否定的确定在步骤201)，那么相关的特征/波形/信 息被自动传输给一个远程网络连接的服务器(步骤204)(经由IP、 LAN、蓝牙、IR、RF或者经由电话或者IP电话)，在其中远程处理(例 如，语音识别/合成)被执行(步骤205)(可能与某个用户/服务器交 互)。

显然从本地客户机到远程网络连接的服务器的语音传输(反之亦 然)可以利用不同的技术实现。例如，可以当作文件、流或者信息包 流直接传送波形。另外，一个被压缩的波形可以利用传统的方法如 ADPCM和APC传输。而且，一个特征的流可以依据G.Ramaswamy等人 在“Compression Of Acoustic Features For Speech Recognition In Network Environments,”Vol.2,pp.977-980,Proc.ICASSP,1998 公开的方法传输，此处引入以供参考。此方法允许在接收端识别(语 音识别、说话者识别或者NLU)而不重建信号。此外，语音传输可以 利用任何编码方法或者基于压缩特征和音调估计的方案，允许语音信 号以足够可理解的质量和平滑舒缓的重放(用以重放、校正、进一步 人性处理、或者归档)而被重建。这种编码方案应该提供低到4kbits/s 和5kbits/s之间的数据率而不降低识别性能。其结果是以后端(服务 器)资源支持的的交互式交换，甚至通过无线调制解调器或者无线数 据链路，就可以实时执行。可以理解，利用相似的编码方案若要提供 非常高质量的重放，其它的方案必须被采用。另外，任何允许cepstra 特征和音调压缩、允许在服务器端识别(语音、说话者、NLU)且在接 收端没有退化并重建信号的方法可与本发明结合使用。此重建对于以 后从服务器的重放或者从客户机(若是本地存储)的重放和处理，为 随后的校对抄本、错误校正或者人的处理监控是有用的。可以理解任 何合适的压缩方案(编码协议)可以被利用。

可以理解，压缩或者编码方案(传送协议或编码协议)在不同的 设备之间可以不同。例如，从音频捕捉系统(客户机的)传送输入语 音到连网资源的编码可能不同于从连网资源(服务器)到音频输出(客 户机)用于传送输出语音(例如提示、重放或者TTS)的编码协议。 确实，在第一种情况下，编码应该被优化以在服务器端提供良好的识 别性能，回放的重建固然重要但并不引人注目地重要。当然比特率(压 缩率)是重要的。压缩率的折衷可在鲁棒性(错误率-特征失真)和知 觉质量之间作出调整以达到和保持一个目标比特率。同样，某些方案 可以被选择以给某些信道或者背景失真增加鲁棒性。另一方面，对于 后面的任务(输出信号)，应该为了可理解或者知觉质量和舒适性，或 者保持声音或音频某些特殊的特征而优化编码。经过本地处理(步骤 202)或远程处理(步骤205)后，一个关于该处理结果是否被接受的 决定(步骤203和206)被作出(经由本地对话管理器103或者服务 器对话管理器108)。如果确定处理的结果是不可接受的(否定决定在 步骤203和206)，则本地客户机或者远程服务器将自动地(经由IP、 LAN、蓝牙、IR、RF或者经由电话或者IP电话连接)转发该特征或者 波形给能执行这种处理的服务器(步骤204和步骤207)。例如，如果 这种结果是未知或者没有被识别或者是模糊不清(或者基于与每个资 源(本地的或服务器)的对话管理器相关的可信度度量)，则对语音识 别结果或NLU的拒绝可能发生。更可取的是，从本地的或者远程系统 到一个服务器系统的自动连接可以基于声音或者被返回的LM(语言模 型)得分的水平上，该得分由本地语音解码器应用如在美国专利申请 5,937,383,Ittycheriah等人、名称为“Apparatus and Methods For Speech Recognition Including Individual or Speaker Class Dependent Decoding History Caches For Fast Word Acceptance or Rejection”中所教导的技术，此专利已一般转让，此处引入以供参考 (例如，当这些得分被判定低于一个给定的阈值时远程服务器被连 接)。可以理解，估计可信度或识别说话和询问(在其期间或者对话以 后)的任何合适的度量或者方法可以被用来决定一个被会话系统获得 的结果是否可以接受(在这种情况下另一个系统被考虑)。

相似地对TTS，本地的和远程的对话管理器103、108可以检查一 个文本的复杂性来决定是否此TTS将被本地或者远程地执行。例如， 当一个字的发音规则不知道时或者当文本需要复杂的句法分析时TTS 将被远程执行。另一个例子是如果此TTS必须被用一个不同的口音、 方言或者一种不同的语种发音或者假定模仿某人特定的句子时。

当处理被远程执行后，结果被发送回本地客户机(步骤208)(经 由电话、IP地址、MAC(媒体存取控制)地址等)。很明显，输出(即， 给用户输出的语音)可以被本地地或者在服务器上合成。如果合成是 在服务器上进行，被合成的语音可以以压缩格式传输(利用上面讨论 的语音传输协议)给用户在本地解压缩。可以理解，编码方案可以和 用于从客户机到服务器传输语音特征的方案相同或者不同。作为选择， 例如，在另外的模拟PSTN线路上，用通过从客户机到服务器的电话呼 叫(回叫)建立的联接，语音可以通过服务器被直接“广播”。

最近的努力开始发展识别语音的合适的可信性度量。例如，在 “LVCSR Hub5 Workshop”,1996年4.29-5.1,MITAGS,MD，由NIST 和DARPA组织，提出不同的方法来把一个可信度级别加于一个字一个 可信度级别上。一个利用决策树的方法在字相关特征(训练说话的数 量、最小和平均三音素(triphone)事件、语言模型训练事件、音素 /lefemes数量、持续时间、声音得分(快速匹配或者精细匹配)、语 音非语音)，句子相关特征(信号噪音比、讲话速率估计：每秒钟的字 数或lefemes数或者元音数、语言模型提供句子的似然、似然率、每 帧规一化平均似然、语言模型中的三字母组事件)，上下文中的字特征 (语言模型中三字母组事件)及说话者外貌特征(口音、方言、性别、 年龄、讲话速率、身份、音频质量、SNR等…)上进行训练。对于此 树的每一个叶在训练数据上都计算了错误的概率。构造这样一个树的 算法被Breiman等人在“Classification and Regression Trees”,Chapman & Hal,1993中讨论过。识别方面，所有的或这些 特征中的一些在识别过程中被度量，并且对于每一个字，决策树走到 提供一个可信度级别的叶。此外，参考Neti等人的标题为“Word Based Confidenee Measure As A Guide For Stack Search In Speech Recognition”,ICASSP97，慕尼黑，德国，1997.4一文，描述了一完 全依靠IBM栈解码器返回的得分的方法(使用对数似然一实际上用的 是平均增量对数似然、精细匹配、快速匹配)。

在LVCSR处理中，使用通过线性回归的预测器估计可信度级别的 另一种方法被执行。被利用的预测器是字的持续时间、语言模型得分、 每一帧平均声音得分(最好得分)和NBEST列表中同顶部选择相同的 字的一部分。显然根据本发明的一个实施例，两种方法(经由决策树 度量的可信度级别和经由线性预测器度量的可信度级别)结合起来， 在任何转换处理中系统地提取可信度级别，并不局限于语音识别。

基于过去的改进和该领域的飞速发展，现在我们可以说对于几种 转换可以连系一个可信度值到正被转换的组件上，例如，从0到1,0 意味着无转换被执行，1意味着转换无疑，此处组件可以是要转换的 文本、短语、字和更一般地任何材料的逻辑块。如上描述的线性预测 器和决策树的结合是本发明优选采用的一种方法。确实，作为例子， 由说话者识别引擎返回的得分累计(快速匹配得分和精细匹配得分及 背景模型和同伴的得分)可以被用来构建可信度级别的一决策树和/ 或一线性预测器，这样说话者真正被正确鉴别。实际上，在说话者识 别的情况下，这个执行验证的总量与识别阶段获得的相等。

可以看出远程服务器可以发送信息例如TTS规则或者基本格式、 语法等给本地客户机以存储在高速缓存中，这样本地设备随后可以应 用这种信息本地处理类似的请求。因为本地设备由于缺乏所需要的资 源而不能执行某些任务，由服务器对话管理器108发送这种处理信息 给本地客户机的决定可以根据由本地设备在与远程服务器连接时关于 它的会话能力向远程服务器的注册(经由上面所讨论的注册协议)而 被作出。

显然本发明可以在这种情况下实现，此时由一设备(经由它的对 话管理器)执行的会话功能量，设备是不能提供必须的资源用于这些 功能的即时执行(例如，IVR有太多的被系统同时使用的端口)。因而， 对话管理器可以实现提供会话系统管理和装载管理，借此，在一个特 定的功能执行时对话管理器可以决定利用另一个会话系统来继续处理 被请求的功能。特别是，参看图3，开始，用户发出一个口头命令给 本地客户设备，它是被预处理过的，例如，被数字化和提取数字化信 号的相关的特征(步骤300)。作为另一种选择，本地对话管理器可以 从一本地应用程序104接收一请求来产生一个合成语音(TTS)输出给 用户(步骤300)。对话管理器将决定是否本地处理应该被执行(步骤 301)(例如，是否要语音识别、对话管理或者语音合成)。这个决定根 据的不仅是本地会话能力、主目和资源(如上面所讨论的)，而且也根 据由于网络交通拥塞网络引起的延迟与利用可用的但被约束的本地资 源(假定本地的和远程的设备可以执行相同的功能)执行此会话功能 可能引起的延迟相比较的评价。因而，例如，当命令和控制功能在本 地/通过网络受到威胁被延迟时可以远程地/本地地执行来减小延迟。 确实，可以掌握更长延迟的查询(例如，由于和后端功能相联合可以 适应延迟如因特网或视听查询)，可以在一个优化其资源或花费的系统 上执行。

此外，万一网络连接暂时不可用或者缺乏网络资源，则所有可以 被本地执行的功能将被执行。其他功能可以被细分成可以以延期的模 式执行的功能(在以后连接时可被重新建立)以及不共存的功能。典 型的例子是更新地址薄、经由口述或者大体上的口述应答e-mail或者 消息。再者，最好应用程序可以决定是否该命令是本地的或者是延期 的。也可以考虑一种带有延期模式的对等，在此一延期模式管理器和 一本地引擎决定是否该功能是本地的或者是延期的。

再参看图3，如果对话管理器确定本地处理是合适的(肯定决定 在步骤301)，则对话管理器将分配必需的会话引擎给端口(步骤302)。 一旦此会话引擎被分配给该端口，如果会话引擎当前没有被最初分配 的端口所使用，则对话管理器可以分配那个引擎给其它端口(步骤303) (例如，当前说话者没有说话而只是在听)。当本地引擎再次被最初被 分配的端口所需要时，如果此本地端口不可得到，另一个可用的引擎 (本地或者在一个远程设备上)可以被利用(步骤304)。这种动态分 配过程与传统的装载管理大不相同，在传统的装载管理中对话管理器 决定并在功能调用的整个持续时间，分配会话引擎到每个端口。

不难看出管理和决定传输语音例如到一个网络服务器或者设备不 但可以根据系统管理/装载平衡的水平(通过客户机或者服务器上的对 话管理器)，而且还根据网络的通信量。例如，如果一个连接(特别是 在因特网上基于TCP/IP的网络连接)被认为是超载(步骤305)，则 基于通信量一个新的服务器或者设备被选择(步骤306)。这个决定可 以在传统协议如VoIP协议(因特网上的声音协议)顶端作出，象RSVP 协议(资源预订协议)一样，借此，当需要一个信道时，连接可以随 同相关质量服务的合适预订一起建立。否则，如上所述远程处理将被 执行(步骤307)并返回结果。

显然这里所描述的系统和方法可以实现以用于各种允许的语音和 会话应用程序。本发明对于满足在嵌入的和流行的计算世界的不断增 长的要求及NLU/NLG会话系统方面特别有用。然而，可以理解，本发 明可以为不同的应用而被发展，并不局限于嵌入式系统。下面作为范 例的实施例将说明本发明的优点。

例如，在智能电话上应用的商业可用嵌入式的姓名拨号器(例如， 一个具有PDA(个人数字助理)能力的无线电话)是一个典型的应用。 例如，假定客户设备100是一个具有姓名拨号器本地应用的智能电话。 用户将在智能电话的电子地址薄中本地存储一个所希望的姓名和地址 的表。然后用户可以发出一个命令如“dial first name last name (拨姓和名)at…可能的限定符(家庭、办公室、蜂窝式电话)”，通 过对命令的识别/理解(经由本地会话引擎102)，智能电话将自动地 拨地址薄中与此人相关的电话号码(经由本地应用程序104)。另一方 面，当发出的姓名不在地址薄中时(因而不被识别/理解)，但该姓名 存在于一个更大的公司的(或者公用的)目录中(如包含在远程服务 器106中)，则这个请求可以被(以特征或者波形)保存和传输给一个 远程服务器106来识别。然后拨号可以直接被远程服务器执行或者依 据通过远程服务器接收的合适信息，由智能电话来执行。作为替代， 在第一个情况下用户可以被连接到一个远程的服务器并建立一个对 话，或重新请求要拨号的姓名或者要求进一步的信息(在白页或者黄 页服务类型的情况下)。

本发明的另一种有用的应用涉及个人信息系统，例如商业可用的 PointCast(参见http://www.pointcast.com)，这个PointCast允许 用户根据预定的用户优先选择得到例如，股票报价、关于某一主题特 定的信息和关于此主题最近公布的信息。应用根据本发明构成的个人 信息系统，如果用户希望获得关于一股票(例如，IBM)或者一主题(例 如，预报在Kent的绿豆生产)的信息，则用户可以发出一个语音请求 给客户设备100。如果“IBM”是在本地词汇表(用户概况)中，则它 将立即被解码，用户得到最新报价，例如获得最近一次更新 (PointCast)。另一方面，如果用户关于“绿豆”的请求没有被本地 客户设备100理解，则该请求被作为特征流自动向前传递给(内容提 供者的)远程服务器106，在此处服务器可以投入更多的资源来解码 这种请求和检索相关信息(无论如何都得做)，然后传输这种信息给本 地系统。如果远程服务器遵循一“推销方法(push approach)”，则上 面这些在下次更新时就被完成(例如，PointCast)。

客户设备100也可以是一个允许使用语音的PVA(个人交通工具 助理)，用以提供如会话的汽车导航。例如，如果用户不想在此系统应 用CD-ROM(因为缺乏空间、能源要求、重量、成本、防震等)，用户 可以决定存储有限的信息，例如有关用户当前所处位置、用户最近所 处位置、及用户想出游的区域/位置的词表和地图。在这个例子中，无 论何时，当用户的请求与本地词表或者地图设置不匹配时，这个请求 可以被自动发送给一个远程服务器106，并解码(甚至以提示返回给 用户去缩小范围查找)来获得路线、地图(或者更新地图)下载到车 上。再者，这种操作(即使花费高代价的下载)对用户来说是基本上 透明的，仅开始需要本地道路。

此外，一个NLU/FSG系统可以根据本发明被设计，以便如果用户 的请求需要FSG(限定状态语法)，则该请求可以被本地执行，除非该 请求更复杂并处在蒙昧状态，因而需要向前传递给一个远程服务器来 识别。

公司的姓名-拨号器服务器提供另一种有意思的特点。一个公司为 它的雇员们保留一个电话号码的有效数据库。这个数据库总是最新的。 用户可以选择周期性地来使它本地的信息与公司数据库保持同步。这 是一个传统的概念。然而，当用户利用姓名拨号器并且需要经由TCP/IP 连接到服务器上时，此同步可以实现(在语音识别期间)，这样本地拨 号信息总被更新。同样，当用户请求导航到一个新的其信息没有包括 在用户本地地图中时，系统可以下载位于本地PVA上的声信息及用户 所希望出游地区的一组导航信息。

图1的系统也可以用会话浏览器系统实现，会话浏览器系统描述 于IBM Docket No.Y0998-392P，当前同此发明一起被递交，名称为 “Conversational Browser and Conversational System”，并已被一 般转让，引入此处以供参考，其中从一个内容提供器(服务器)传输 (并被会话浏览器处理)的CML(会话标记语言)页在概念上类似用 于可视显示的HTML(超文本标记语言)页，用来描述要被呈现给用户 的一个会话UI。在这个例子中，会话浏览器可以是客户设备100的本 地应用程序104和/或远程(IVR)服务器106中的服务器应用程序109。 可由内容提供者或应用开发者(或者代理/代码转换器)来决定用户应 该提供的一个给定的项目(例如，NLU，或FSG输入表单或经口授填充 一空表单)必须在服务器106上被识别，而不是提供所有的数据给客 户设备100在本地识别(因为此任务对于本地资源来说太复杂或者因 为通过网络必须发送太多的信息)。其实现是通过例如在一个CML文件 中提供一个URL(统一资源定位器)和标记来指示服务器其中一个处 理将发生，或者通过在CML页中装载一小应用程序、一Active X组 件或者一个捕捉音频的插件(或者它的任何变化)，实现可能的一些会 话功能，并为其它功能将其传输给其它设备(这是由页面的制作者作 出的典型的决定)。这个决定可以自动地被代码转换器和注册机制实 现，如在IBM Docket No.Y0998-392P中所描述，由此，浏览器向它 取出CML页的服务器明白地描述它的能力。当代码转换器另考虑浏览 器的能力并使内容适合这种能力时(这种能力即是所提到的会话代 理)，现在，根据浏览器的能力，代码转换器可以增加服务器的URL(s) 以重定向服务器。在这种情况下，被客户设备100收集到的语音可以 被作为一个波形(被压缩或者没有)或者作为特征流发送给远程服务 器106或者识别发生其上的网络服务器110(或者NLU/NLG)。然后识 别的结果可以被发送回客户设备100或者CML提供者服务器(远程服 务器106)来决定操作的下一个行动或者进一步处理。再者如上面所 述的，这可以被能直接结合资源/引擎/服务器的URL的应用程序决定 或者要被用来识别一个给定的输入、菜单表格或者对话的本地设备决 定。此外，本发明在一个CML页必须重放/合成声音或者文本对于本地 设备102的本地会话引擎102来说太复杂的情况下是有用的。太复杂 的部分可以作为特征流或者被压缩波形从任一个特定的服务器(这个 服务器可能是或者不是提供CML页的服务器)上得到。而且，对于多 语言系统，如果一个CML页包含一种不同的语种，则没有合适能力的 本地客户设备100可以请求一个远程服务器来执行按那种语言的会话 功能。

显然，会话协同可以在有会话浏览器的分布式应用中使用。例如， 参看图4，一个分布式系统有一个表示服务器400、一个引擎服务器 401、和一具有会话浏览器403的客户机402(如在上面参考Y0998-392P 中所讨论)。该浏览器403从表示服务器400接收CML的页并处理此 CML页。CML页可包含允许浏览器403决定发送语音到何处进行处理的 信息。一个语音服务器位于引擎服务器401上。假定CML页需要引擎 服务器401处理语音，浏览器403可以经由HTTP(或者套接口或者RMI) 与语音服务器联系(传输呼叫)来传输音频给语音服务器并发送合适 的数据文件指令和引擎呼叫。客户浏览器403被假定有一些本地处理 能力来执行语音处理(经由语音API和语音识别引擎405)。如上面提 到，在本地语音处理和服务器端语音处理之间的转移由从表示服务器 400接收到的CML页决定。这个决定可以被内容提供者编码或者适应 此设备(客户402决定它能执行此任务并把该任务发送给一个已知的 或者已被发现的服务器或者代码转换器)。

在图5，浏览器403位于被客户402存取的一个浏览器服务器404 上(浏览器服务器404在客户机402和表示服务器400之间充当中介 物)。再者，浏览器403决定是否执行本地或者服务器端的处理。如此 处所描述，音频是可以利用会话编码被传输。

本发明允许一个低资源客户设备透明地本地执行简单的任务，又 以二进制或模拟方式与一具有更复杂会话能力的服务器(或者别的设 备)相连接透明地执行复杂任务。服务器端功能(例如语音识别)可 以通过一个常规的IP网络或者LAN网络实现，也可以经由传统的电话 线路或包交换网络数字传输，或者在无线网络上经由任何传统的无线 数据协议而能被执行。模拟/数字连接实施例描述了至少两个方案。第 一，它是等价于一个调制解调器实现的二进制连接，所有的功能是数 据传递功能。此外，当一个服务器/分布式资源被包含时，系统可以调 用一个电话服务器作为资源，且声音在网络上被发送(而不是波形数 据或者它的变换如cepstra)。这一方案的一个例子是与本地语音识别 功能(姓名拨号器和数字拨号器)的一无线连接，此本地语音识别功 能经由一个常规的无线连接到一个具有IVR的电话服务器上来获取其 它功能，象语音浏览因特网、获得股票/共有基金报价和通过语音执行 金融交易。这种机制在今天可以利用现存的蜂窝式电话设备上装备一 些语音识别能力。

另外，不同的机制可以被利用来管理流通量和在网络上分布的资 源，以保证在网络上保持一合适的会话交互的对话流。这种机制包括： 会话协议(如上面所讨论的)，音频：RecoVC(识别兼容VoCoder)(允 许回放重建带有音调的编码协议)，应用程序和元信息：分布式应用协 议、发现、注册、协商、维护对话流的服务器负载管理、保持对话流 的流量平衡和路由选择、基于任务特征和能力需求及会话主目可用性 (数据文件)的引擎服务器选择，会话主目分配：存储、流量/路由选 择和高速缓存。

尽管图例的实施例在此参考附图已被描述，应该理解，本系统和 方法并不局限于这些刻板的实施例，在不脱离本发明的范围和精神的 情况下，技术上熟悉的人可作各种不同的改变和修改。所有这种改变 和修该都应包括在所附加的权利要求书中定义的范围内。

本申请基于1998年10月2日递交的第60/102,957号美国临时申 请和1999年1月27日递交的第60/117,595号美国临时中请。