专利名称：话音处理系统的制作方法
该发明涉及用于支持一个或多个话音处理应用的话音处理系统。
话音处理系统广泛用于呼叫中心和其他环境用来管理与用户之间的交互操作，因此，降低用于服务用户询问的相对较贵的人工代理的数量，同时为呼叫者提供改善的呼叫响应。大多数被开发来用于这种情形的话音处理应用仍然主要基于相对简单的一组操作，包括给呼叫者一个提示(一般是一个问题，可能要求他们说明感兴趣的特殊服务)，这组操作还包括接收呼叫者响应这种提示的双音调多频按键(DTMF)输入，然后对应于呼叫者的选择进行一些操作。可能动作的例子包括给出提示来获得进一步的DTMF输入、记录来自呼叫者的话音消息、将呼叫者转移到另一个分机或传送一些信息给呼叫者，例如帐目结算或时间表信息(这可能要求话音处理系统与单独的计算机数据库进行信息交互)。以音频形式传送给呼叫者的提示和其他信息一般包括一个或多个预记录的音频段，这些音频段可以按需要被组合起来。
将会理解的是，在工业中已经发展了很多话音处理应用，包括进入和流出的应用。传统的话音处理应用的一个问题是，它们经常具有其特定的话音应用环境。这导致几个不好的结果，例如，将话音应用从一个话音处理系统移植到另外一个话音处理系统是很困难的。同时，很少有话音处理系统能在整个潜在操作范围上正确缩放(从处理几条线到几百条线)。这样，具有不同系统环境的用户就不能灵活配置一个可用于所有机器的单个话音处理应用。
特定的话音应用环境也使得话音处理应用难于与组织中的通常计算机商业系统相结合，此外，开发话音处理应用一般比较难而且很贵(因为编程人员必须了解具体的环境)。随着用于用户环境中的话音处理系统数量的快速增长，以及将话音处理应用和整个管理信息系统很好结合的需要，这些问题变的更加尖锐。
提交于97年9月19日的英国专利申请9719942.6描述了一种话音处理应用环境，该环境是基于面向对象(oo)的Java编程语言的。特别是，该文档描述了一组电话Java豆(即编程组件)的提供，可以利用标准的Java编程开发工具将这些Java豆(bean)很容易地集成到通常的商业应用中从而在任何平台上提供对电话功能的简单访问。Syntellect公司(见http//www.syntellect.com/vista.htm)也宣布了基于Java的话音处理结构。EP-A 658855描述了将多媒体装置集成到面向对象的环境中，用户进行的对音频对象的选取可以导致例如利用文本到语音转换装置的输出。
上面提到的英国专利申请的一个重要特征是使得话音处理系统的细节对应用透明，因此提供完全的平台独立性。为了在不需要将基本话音处理系统的某些知识链接到应用中，并因而使应用具有灵活性的情况下使得应用能够访问电话功能，而在应用和电话系统之间提供一个有效接口是很困难的。由于在这种环境中某些信息，例如日期和时间的处理方式不同，一个特殊的复杂化因素包括例如给出一个提示。
因此，本发明给出一种话音处理系统用来连接到至少一条电话线用于为一个或多个话音处理应用提供电话支持，该系统包括用于接收来自话音处理应用的媒体对象的装置，其中的媒体对象表示电话线上的期望输出；用于根据一个或多个标准将所述媒体对象加工成多个输出分量的装置；以及用来在电话线上输出所述输出分量的装置。
在优选实施方案中，所述的输出分量包括单个的话音段，用来将所述媒体对象加工成多个输出分量的所述装置包括用来根据一个或多个表示标准为所述媒体对象产生一组话音段的装置。
所用的表示标准一般可以由所述的话音处理应用指定、由话音处理系统自动确定(一般使用缺省值)，或者两者结合。所用规则的例子包括区域和表示类型。
这种方法提供了很大的灵活性，其灵活性在于不需要将例如区域或存在类型的信息硬编码到应用中，相反的是这些可以由缺省电话环境给出。这使得可以在不必预先知道它们将应用在哪个国家和语言的情况下开发该应用。此外，对于例如只有一个话音处理系统以两种不同的语言运行基本上相同的应用的情况，能够覆盖缺省值是很有价值的，其中的双语情况可能是由于从不同的国家访问而造成的。
本发明还给出一种操作话音处理系统来连接到至少一条电话线从而对一个或多个话音处理应用提供电话支持的方法，所述的方法包括以下步骤接收来自话音处理应用的媒体对象，所述媒体对象表示在电话线上的期望输出；根据一个或多个表示标准将所述媒体对象加工成多个输出分量；在电话线上输出所述输出分量。
在优选实施方案中，所述媒体对象通过远端请求被串形接收，因此使得话音应用可以存在于不同于话音处理系统的机器上。
本发明还给出一种话音处理复合体，该复合体包括许多主机，每个主机支持一个或多个话音应用，复合体中至少一台主机包括用来提供对多个电话线访问功能的电话硬件，所述的至少一台主机包括用于保持话音应用到电话线映射的装置；用于创建一个呼叫对象以响应在所述多个电话线中一条上的流入呼叫的装置；在所述话音应用到电话线映射的基础上确定与所述流入呼叫相关的话音应用的装置；用来向确定话音应用提供一个所述呼叫对象的识别器的装置；在所述呼叫对象中的响应来自所述确定话音应用而为所述流入呼叫提供电话功能的装置。
在优选实施方案中，确定的话音应用位于不同于呼叫对象的主机上，并通过远程方法请求来访问呼叫对象。当前能用来接收流入呼叫的应用将其自身与话音处理装置配套；如果在没有与任何应用配套的电话线上有一个流入呼叫，那麽将会开始一个缺省应用。
本发明还给出一种话音处理系统用来支持一个或多个话音应用，所述的话音处理系统包括用于提供对多个电话线进行访问的电话硬件；用于保持话音应用到电话线映射的装置；用于创建一个呼叫对象以响应所述多个电话线中一条上的流入呼叫的装置；在所述话音应用到电话线映射的基础上，确定一个与所述流入呼叫相关的话音应用的装置；用来向确定话音应用提供一个所述呼叫对象的识别器的装置；
在所述呼叫对象中的用于接收来自所述确定话音处理应用的媒体对象的装置，所述媒体对象表示在所述一条电话线上的期望输出；用来根据一个或多个表示(presentation)标准将所述媒体对象加工成多个输出分量的装置；用来在所述一条电话线上输出所述输出分量的装置。
本发明还给出一个话音处理系统用来连接到至少一条电话线用于为一个或多个话音处理应用提供电话功能，所述话音处理系统包括第一应用管理装置用来当话音处理系统初始化时开始一个第一话音处理应用，所述的应用管理装置为第一话音处理应用提供对所述电话功能的访问。
第二应用管理装置，该装置响应第二话音处理应用访问所述电话功能的要求而启动。
当试图将应用与电话功能的特性相区分时的一个困难在于将关于实际电话环境的信息提供给一般性应用。在优选实施方案中，这一点通过系统初始化时将配置信息提供给应用管理器来实现，然后应用可获得这些信息。这对于遵从话音处理环境的应用来说是很令人满意的，但是却不适用于某些应用，例如，电话功能仅仅是应用的一小部分或可能仅仅断断续续需要电话功能的情况。这样本发明的话音处理结构也允许这种应用创建它们自己的应用管理器(注意到在这种情况中，应用必须提供自己的关于所用电话源的信息，因为这不会作为初始化的一部分而被提供)。在优选实施方案中，这一点是通过使得所述第一和第二话音处理应用获得对电话功能的访问来实现的，其中的访问功能是通过应用管理器的一个静态接口实现的。
通过示例以及仅参考下述附图，该发明的一个优选实施方案将被详细描述。
图1表示话音处理复合体的整个结构；图2表示图1的复合体中的主机、节点、组和应用的结构；图3表示将电话支持提供给图1的话音处理复合体。
图4表示在图1的话音处理复合体中电话节点和话音处理软件之间的信息交互。
图5表示在图1的话音处理复合体中应用和电话节点之间的信息交互。
图1表示话音处理复合体(称为“复合体”)的整体结构，包括一个或多个被网络20连接的主机10。每个主机通常可以被看作一个工作站，而其中的网络可以是任何适当形式的网络，例如局域网(LAN)，广域网(WAN)等等。在优选实施方案中，通过网络20的通讯使用众所周知的TCP/IP协议，该协议是网间网、内部网和外部网等等的基础，并被大多数操作系统支持。应该理解的是，主机10因而可以按照期望的位置放置，可以与其它主机在一个房间内或分散于不同的大陆上。
每个主机支持一个或多个节点15。这里存在两种形式的节点，应用节点(AN)15A，该节点主要定义和控制话音处理应用，以及电话节点(TN)15B，该节点为应用节点提供电话服务。注意到应用节点只提供电话节点所提供服务的一个子组，并且电话节点也能支持应用，并因此使其自身成为一个应用节点(但是只有电话节点能提供电话服务)。
每个应用节点运行一个应用管理器用来支持一个或多个应用，这些应用可以被集中到组中。这在图2中被说明，其中(仅通过示例)主机10运行两个应用节点15A。第一应用节点支持两个组25，这两个组又分别包括两个和三个应用40。第二应用节点支持一个组，该组包括4个应用。注意到一个组可以包括相同应用的多个拷贝。组提供了一种用于控制多个应用的简单机制，特别是，用来在初始化时间开始多个应用的简单机制。此外，如下面将要详细描述的，节点也有可能支持不包括在组中的应用。
图3表示了包括电话硬件30的主机10的结构。这被用来与电话干线120接口，该干线通过一个专用交换机(PBX)130被连接到公共交换电话网(PSTN)140，(另外可选的是，电话硬件30可以直接连接到PSTN140)。干线120可以是数字的(一般为一个或多个T1/E1连接)，也可以是模拟的，支持几个电话信道到几百或更多的电话信道。电话硬件由话音处理软件50控制，该软件接受电话节点15B的命令。
在优选实施方案中，如在手册“DirectTalk/2通用信息和计划2.1”(参考GB354403-04)及所列出的其它手册中描述的那样，图3中示例系统的一个实现利用了商业IBM DirectTalk/2软件产品用做VRU软件50。在这种情况中，主机10包括一台IBM个人计算机，该计算机运行IBM OS/2 Warp V4操作系统，电话硬件可以是Dialog公司大量可选卡中的一种(例如D/41，D/81详情参考上述手册)。如在手册“AIX版的DirectTalk通用信息和计划2.1”(参考GC33-184000)和其它列出手册中描述的那样，图3中系统的另一个实现使用了略微修改后的AIX V2.1版的IBM DirectTalk/2软件产品用做VRU软件。在这种情况下，主机10包括一个运行IBM AIX V4.2操作系统的RS/6000工作站，电话硬件30包括一个RS/6000工作站中的数字主干适配器，该适配器被连接到一个外部数字主干处理器(9295)，该处理器又被连接到主干120(该硬件可以从IBM获得，并在上面参考手册中详细描述)。
返回到图1，每个主机还包括一个主机管理器55。此外，还有一个复合体管理器200，用于基于存储的配置信息205来控制整个复合体的操作。配置管理器210也被提供来如描述的那样插入/更新/删除配置信息205。注意到尽管复合体管理器被表示为位于复合体中的一个主机系统上，这不是实际必须的，相反复合体管理器可以位于另一个系统中(该系统不是复合体中的主机)。
在优选实施方案中图1的软件组件(主机管理器，电话节点，应用节点以及复合体管理器和配置管理器)都是Java程序，每个节点都工作在一个单独的Java虚拟机(JVM)上。因此，该结构可用于任何支持Java的系统上。如后面将要详细描述的，在节点中运行的应用一般由Java豆构成(Java豆是支持某种标准接口的Java组件，其中的标准接口使得它们可以利用通常的程序开发工具例如IBM公司的Visual Age for Java很容易地被集成到应用中去)。这里的应用利用Java远程接口(RMI)与电话节点通话；因此它对于应用和电话节点位于同一主机或不同主机的系统都是非常透明的。这里假设本发明的读者熟悉Java编程环境；更多关于该点的细节可以在“Java编程语言第二版”中找到，该书由Arnold和Gosling，Addison Wesley著，1998(ISBNO-201-21006-6)。
应该理解的是图1的中的特殊配置仅为示例而用，各种变化都是可能的。因此，最简单的配置可能包括一个主机，该主机包括一个电话节点运行一个或多个应用。在更复杂的方案中可以使用多个主机，每个有一个或多个节点。没有电话硬件的主机仅运行应用节点，而带有电话硬件的主机可以运行一个电话节点并且，如果需要还可以运行一个或多个应用节点(当前，电话节点必须位于其相关电话硬件相同的主机上，因为从电话节点到话音处理软件50的接口通常只能实际运行话音处理软件50的机器中开发。从长远的观点来看，这种限制可以被除去，并且不再要求电话节点要与其相关电话硬件位于同一个主机上)。注意到，在一个系统上运行两个或多个电话节点是可能的；通常，作为配置的一部分，这要求电话硬件的线路资源在不同电话节点之间分配，以便避免任何将来的冲突。该方法对于例如单主机系统是很理想的，其中，具有分配给它的大多数线路的第一电话节点表示产品设施(即，用来支持实际的商业操作)，而且有独立线路分配的第二电话节点可以提供开发和测试环境。
出于复合体内呼叫路由的目的，结合电话节点15B与话音处理软件50的接口，图4更详细的说明了其内部结构。因此用来处理呼叫的主要组件是系统呼叫路由器(SCR)315，该路由器主要负责将呼叫与应用联系起来，SCR与对话期间处理器320通讯，在一个实施方案中，该处理器通过一个C动态链接库(DLL)310与话音处理软件50接口。对话期间处理器使用Java自己的方法接口与CDLL通讯。对话期间处理器激活主要表示线路对象的对话期间对象312，这些对象执行关于该线路的操作，例如，通知呼叫到来，向外拨号，给出提示等等。
尽管SCR对于整个话音处理系统是通用的，而对话期间处理器以及其相关的对话期间对象对于电话节点使用的具体话音处理软件50来说是特定的。这样，当电话节点首次启动时，主机上硬件的正确对话期间处理器被激活。在优选实施方案中，话音处理软件包括DirectTalk/2，对话期间处理器通过CDLL与话音处理软件接口，而其中的CDLL又使用DirectTalk/2的标准C程序应用编程接口来访问期望的电话功能(如上面提到的手册中描述的)。如果话音处理软件包括用于AIX的DirectTalk，那麽电话节点通过一个TCP/IPSocket接口与话音处理软件接口(利用对话期间处理器和AIX版DirectTalk中的信道处理器之间的数据流，以及每个对话期间对象和相应信道处理之间的数据流-见US5367609和US5668854对AIX版DirectTalk结构的描述。注意在这种情况下不需要一个单独的CDLL)。
SCR的基本目的是将呼叫与应用链接起来，并且保持一个流入线路与应用之间(干线120包括多个电话线)的映射表。通常来说，在呼叫存在之前应用就已经运行了，并很好地与SCR配套(捆绑)在一起。因此，当接收到流入呼叫时，话音处理软件会通知对话期间对象312，该对象反过来又通知SCR。然后，SCR可以按照映射表将流入呼叫链接到适当的应用。
如果得不到指定的应用，或者没有为该线路指定应用，那麽SCR开始一个缺省应用。注意到当缺省应用开始后，系统马上会检查是否存在等待缺省应用处理的呼叫，如果是这样，则对SCR提出一个请求将应用与该呼叫捆绑起来，这保证了这些呼叫能快速传递给缺省应用，即使在呼叫真正被系统接收时，没有适当的应用正在运行时也是这样(可以按照上面描述的一般应用的相同方法在初始化时启动缺省应用的一个或多个拷贝)。
将输入呼叫与应用配套或捆绑一般包括给SCR一个请求并进入等待状态直到接收到一个流入呼叫(遵从可能的时间限制)。流出呼叫基本上以相同的方式处理，相似处在于应用仍然从SCR请求一个呼叫，然后等待直到可得到这样一个呼叫(应用可以明确它马上就需要一个流出呼叫，如果不能实现就返回失败)。
应用还可以执行一种转移或切换，将目前正在处理的呼叫返回给SCR，同时指定另一个呼叫应该被前送的应用。如果需要，第二应用也可以执行转移，并可多次执行。一旦完成了一次呼叫处理，应用会将该呼叫返回给SCR，然后SCR或者将该呼叫返回给此前它被转移过来的应用(如果在最初转移时要求的话)或者终止该呼叫(即，挂断电话)。
连接到SCR的是一个确认装置317，该装置的目的是尝试从误执行(或切断的应用)中回收电话资源。例如，由确认装置执行的一个过程是检查哪条电话线被分配给哪个应用，然后与该应用相关的应用管理器联系。如果这种联系没有成功(可能是电话节点与应用节点之间的网络20的失败)，那麽电话资源被恢复，因为在这种情况中应用不能很好地控制电话线的操作。
复合体的初始化如下所示。假定在每个主机10上都运行一个主机管理器55，并且同样地话音处理软件55也运行在包括电话硬件30的主机上。这些程序一直保持不被激活的状态直到被复合体管理器200激活，该管理器负责使复合体进入工作状态。这样复合体管理器会访问配置信息205，然后调用各个主机管理器中的合适方法，以便激活复合体(希望是主机管理器的标识和地址以及复合体管理器所须的其它信息可以从配置数据中获得)。这样每个主机接收表示其在系统中的名称和节点配置的信息。节点配置信息包括节点名称，哪一组应用将启动(应用组仅在初始化时启动；其后各应用必须各自启动)，节点中应用的电话节点的缺省主机和节点名称以及该节点是否为电话节点。如果实际情况就是这样(即节点为电话节点)，那麽节点配置信息还包括主干120中的哪一个电话信道被看作流入或流出信道(或任何一个)、各条线路或信道到应用之间的映射以及用于节点的缺省应用的名称。
根据相关的配置信息，每个主机管理器可以为它支持的每个节点开始一个应用管理器(一个应用管理器定义一个节点)。然后，应用管理器启动指定组中的应用，该应用被作为适当的应用与电话节点配套。到此为止，复合体已经可以工作了。
应用的一个重要特征是，它既支持被管理的应用也支持不被管理的应用。这样如同所描述的，应用实际上服从复合体管理器，或更普遍的，服从整个话音处理系统，这一点体现在该应用由复合体管理器初始化，并且与话音处理复合体同步，这些是所谓的被管理应用。
然而在某些情况中这是不理想的，因为应用可能远远大于仅仅一个话音处理应用，而且还执行许多其它的商业功能。作为一个例子，在选定时间，这种应用可能需要向外呼叫(可能发送传真)。图1的结构通过不被管理的应用来支持这一点。这些是最初存在于图1的结构之外的应用，但是仍然希望通过给电话节点适当的呼叫来访问并使用电话硬件。支持不被管理应用的方式将在下面详细描述。
如果现在考虑应用的信息，一组电话Java豆会被提供来使得话音处理功能可以很容易地结合到Java应用中，所提供的Java豆的主要类型如下所示电话使得应用执行简单的电话功能，即请求一个流入或流出呼叫并终止一个呼叫。
菜单允许话音处理菜单显示给呼叫者，包括一个或多个菜单项Java豆。
表使得话音处理表显示给呼叫者用于添表，包括一个或多个记录域Java豆，以及菜单，菜单项和其它所需的Java豆。
通知给呼叫者传递一个音频信息。
话音记录器记录来自呼叫者的音频信息。
媒体表示输出数据(一般为音频)，包括一些预定义的Java豆，比如音频日期，音频时间，音频货币，数字和提示(表示媒体对象序列)，而且还有DTMF序列，该序列给呼叫者发送指定的DTMF按键序列。
一种非常简单应用的操作将结合图5被详细讨论以说明话音处理系统的操作。该应用的目的是利用电话节点15B提供的电话服务回应一个呼叫，给呼叫者提出一个问题，收集一个或多个DTMF数字，然后终止该呼叫(例如，在电话轮询中记录基值)。这样如前面描述的，应用40最初由应用管理器500开始(最好的是，在图5中，这里描述的结构使得如果该应用还运行在这个节点中，那麽应用管理器500也位于电话节点15B中，或者应用管理器和应用可能形成一个独立于电话节点15B的节点)。
为了响应包括在应用中的电话对象405，应用首先询问应用管理器它使用的电话节点的位置(除非这已经被特意预先硬编码进应用中)。这种方法使得同样的应用可以被用于任何主机。然后，该应用如上面讨论的那样通过应用管理器将其自身捆绑到SCR315，并在映射到该应用的线路上等待流入呼叫。
该过程的一个重要方面是电话对象最初通过它的静态接口访问应用管理器，而不是通过一个直接方法呼叫。这一点的含义是，如果该系统当时没有运行任何应用管理器，系统会通过Java环境开始一个。因此，如上面提到的，这为不被管理的应用提供了一种机制来获得对话音处理系统的访问，其方式是通过使用一个电话Java豆来启动一个用于该目的的应用管理器。注意到，在这种可能性下，应用管理器并不包括某些配置信息，比如作为初始化过程的一部分一般从复合体管理器接收的缺省电话节点。因此，当电话Java豆向应用管理器呼叫时，电话Java豆必须知道并且为合适的电话节点提供完整地址。
应当理解，当被管理应用调用启动它的应用管理器的静态接口时，该应用管理器已经被说明了。在这些环境中，静态调用类似于对该对象方法的直接调用。
注意到，在产品应用被按照与系统一起提出的被管理应用处理，开发应用被按照不被管理的应用处理的情况下，通过相同接口既支持被管理又支持不被管理应用的功能提供了另一种支持同一系统上的产品应用及开发应用的机制，开发应用的情况仅在测试时周期性的进行。在这种情况中，当应用从开发变为产品的过程中，对应用仅需的修正是它将(一般)依赖于缺省电话节点，而不是使这一点在应用自身中被指定。
现在返回到图5的过程，一旦在特定线路上接收到一个呼叫，这一点由该线路的对话期间对象455通知对话期间处理器，该处理器首先创建一个呼叫上下文460。这表示一个呼叫对象，并可以与存在呼叫的线路的相关对话期间对象交互信息从而执行操作，例如给出提示，接收DTMF按键输入。然后，进程处理器呼叫SCR315来使应用注意到呼叫。这使得SCR通过应用管理器500将呼叫上下文对象460的标识返回到电话Java豆405(基本上作为到原始配套呼叫的一个返回码)，并构造一个连接项对象470，该对象后面被应用用于与呼叫内容460通话，并因此访问期望的电话功能。
在图5表示的示例应用中，电话Java豆405继之以记录域对象415。这样在电话Java豆已经接收到一个流入电话呼叫之后，它将事件对象430传送给记录域对象450，该事件对象包括到一个连接项470的参考。
记录域对象被选通来给呼叫者传送一些消息，在优选实施方案中，该消息包括3个分量，一个头，一个标签和一个脚注，每个分量表示记录域对象的一个特性450，并且在应用开发中与一个媒体对象Java豆或对象425相关(注意头和脚注是可选的)。这种媒体对象表示一个预记录的音频(话音)段，要产生的音频消息(例如日期和时间)，或者这些的组合(媒体对象也可以给出DTMF按键序列)。每个话音段都被分配一个名称和类别用于辩识。媒体类型对象也可以被提供来自涉及区域和组织(该记录域可以查询应用管理器没有明确的内容)的记录域对象的信息；在需要的地方可以采用缺省值。这些信息可以被用来，例如，确定适用于该组织的头话音段，因此使得应用(比如话音邮件)可以被或为各种组织很容易地定制并很容易地配置。区域的使用在下面详细描述。注意到同样的关于组织、区域等等的模板被结合其他Java豆使用，比如，通知、菜单等等。
然后，记录域对象利用连接项470在电话线上给出一个提示并通过呼叫上下文460上的RMI获得一个DTMF输入。作为该过程的一部分，记录域将其头，标签和脚注组合以应用到媒体对象中，然后被串行输出而且传递给呼叫上下文。
然后，呼叫上下文调用(即时的)媒体对象中的映射方法，该方法分析媒体对象以产生输出原语字符串。对于简单的话音段，通过参考由基本的话音处理软件50提供的适当的话音段而被标识，例如，大多数话音处理系统可能提供一个“Hello”作为预记录话音段，这将在不同系统中有一个不同的标识。本发明的话音应用环境提供一个独立于平台的话音段列表，这些话音段需要在该阶段如实际处理呼叫的电话节点15B所支持的那样映射到相应的实际话音段。这样该提示被映射为等价的话音段序列，该序列可以通过对话期间对象455被话音处理软件50送在线路上作为对该提示的响应，可以接收一个DTMF按键输入，该按键输入可以通过呼叫上下文和连接项被传送回记录域对象。如果需要，记录域项可以证实该输入(例如，证实呼叫者已经输入了正确数量的数字)，如果不能确认，则向呼叫者传送错误消息430，其方式与标鉴提供呼叫者原始提示的方式相同。一旦接收到一个正确的输入，控制转移到电话Java豆420，该Java豆给SCR一个返回呼叫以便终止电话呼叫，在这个阶段，应用也可能希望处理呼叫者输入，例如通过使用一个Java豆(没有给出)来将接收到的DTMF按键存储在数据库中。
如果我们更详细地考虑映射操作，这涉及媒体对象调用映射类中的方法(没有给出)；媒体对象将其自身传送给映射类。映射操作必须为媒体对象进行一些额外的处理，该媒体对象并不直接对应于简单的话音段原语，而是表示这些的组合。例如1232am的音频时间需要根据3个独立的话音段″12″，″32″，″am″组成(注意到，映射过程将为这些对象提供当前的日期/时间，除非特别确定了其他的值)。以同样的方式，每个提示Java豆将首先被分解成其组成媒体对象(话音段，音频日期等等)，然后分解成话音段原语。对于某些媒体Java豆可获得不同的类型。例如，对于音频时间，这可以用一个12小时时钟或一个24小时时钟表示。应用开发者因而可以指定该对象的类型，然后将确定映射类中的特殊方法调用来执行映射操作。
本发明还支持音频输出的特定区域解释，其中区域一般表示操作的语言和国家。区域可以作为对呼叫上下文相关请求的一部分而指定，或可以应用一个缺省值，该缺省值可以由呼叫上下文从Java环境中拾取，并在被呼叫上下文对象激活时作为参数传送给媒体对象。对于话音段的直接映射，区域可以被用做额外的识别器，这在开发多语应用时是很有用的。这样应用可能通过以3种EPO的官方语言(法语，德语，英语)来给出消息“欢迎到欧洲专利局”而开始，因此该语句会有对应于3种语言的3段录音，这些录音可以按同样的类型和名称来存储，但是在不同的区域(在这种情况中，应用需要正式为至少两种语言明确区域。)对于更复杂的对象，区域被用来确定被激励来执行映射操作的映射类。在优选实施方案中，每个映射类的与区域有关的确定名称有3个分量(即<xx>_<yy>_<zz>)其中，<xx>一般被用来明确语言，(例如英语)，<yy>表示国家(例如美国，这可以被用来得出语言的特定国家形式-例如美国英语)，<zz>用来明确进一步的局域变量，这后一选项表示应用开发者改变缺省的音频解释的一种简单机制。注意到作为音频映射方法的一部分，媒体对象先寻找一个映射类，可以匹配所有3个分量。如果找不到，那麽它会寻找一个简单确定了前两个分量的类，然后寻找一个简单确定了第一个分量的类，最后寻找一个不匹配任何分量的类。因此，即使没有确定任何与区域有关的行为，映射过程也尽可能的合理，而且反映了需要将应用从需要了解它将要工作的未来区域简化(因此，使得开发一个真正通用的应用)。
注意到，缺省方法可以从一个映射类变化到另一个，并依赖于区域。这使得，例如，音频日期在美国的格式不同于在英国的格式(月-日-年与日-月-年)。
尽管这里描述的实施方案主要集中于给出话音段和接收DTMF输入的基本话音处理操作，应该理解的是，这种话音处理系统可以被很容易地扩展来提供更先进的功能，如电话硬件支持的。例如，话音应用现在开始为输入和输出分别使用文本到语音(TTS)转换和话音识别。在前一种情况中，媒体类型对象可以指出映射过程是否应该用TTS(如果可以从电话节点获得)，是否有预记录格式的被请求话音段。同样地，记录域对象可以明确是否可以利用话音识别替代DTMF输入来收集其输入，并且呼叫上下文可以相应处理这种情况。
权利要求
1.连接到至少一条电话线用于为一个或多个话音处理应用提供电话支持的话音处理系统，该系统包括用于接收来自话音处理应用的媒体对象的装置，所述的媒体对象表示电话线上的期望输出；用于根据一个或多个表示标准将所述媒体对象加工成多个输出分量的装置；用来在电话线上输出所述输出分量的装置。
2.权利要求1的系统，其中至少一条表示标准由话音处理系统自动确定。
3.权利要求1的系统，其中至少一条表示标准由所述话音处理应用确定。
4.权利要求2的系统，其中至少一条表示标准由所述话音处理应用确定。
5.权利要求4的系统，其中如果所述的表示标准不是由所述的话音处理应用确定的话，话音处理系统自动地为至少一条表示标准给出一个缺省值。
6.任何前面权利要求的系统，其中所述一条或多条表示标准包括一个区域标准。
7.任何前面权利要求的系统，其中所述一条或多条标准包括一个类型标准。
8.任何前面权利要求的系统，其中所述输出分量包括单个的话音段。
9.权利要求8的系统，其中用来将所述媒体对象加工成多个输出分量的所述装置包括用来根据一条或多条表示标准为所述媒体对象产生一组话音段的装置。
10.操作连接到至少一条电话线用于为一个或多个话音处理应用提供电话支持的话音处理系统的方法，所述的方法包括接收来自话音处理应用的媒体对象，所述的媒体对象表示电话线上的期望输出；根据一个或多个表示标准将所述媒体对象加工成多个输出分量；在电话线上输出所述输出分量。
11.权利要求10的方法，其中所述的媒体对象通过远程方法请求来接收。
12.权利要求11的方法，其中所述的媒体对象以串形方式接收。
13.一种声音处理复合体，该复合体包括很多主机，每个主机都支持一个或多个话音应用，复合体中的至少一个主机包括用来提供对多条电话线访问的电话硬件，所述的至少一个主机包括用于保持话音应用到电话线映射的装置；用于创建一个呼叫对象以响应在所述多条电话线中一条上的流入呼叫的装置；在所述话音应用到电话线映射的基础上确定与所述流入呼叫相关的话音应用的装置；用来提供一个所述呼叫对象到确定话音应用的识别器的装置；在所述呼叫对象中的响应来自所述确定话音应用而为所述流入呼叫提供电话功能的装置。
14.权利要求13的话音处理复合体，其中所述确定的话音应用与呼叫对象不在一个主机上。
15.权利要求14的话音处理复合体，其中所述确定的话音应用通过远程方法请求来访问所述呼叫对象。
16.权利要求13-15的话音处理复合体，还包括用来将当前可用来接收流入呼叫的应用配套的装置。
17.权利要求16的话音处理复合体，还包括在没有配套应用的电话线上存在流入呼叫时开始一个缺省应用的装置。
18.用来支持一个或多个话音应用的话音处理系统，所述话音处理系统包括用于提供对多条电话线进行访问的电话硬件；用于保持话音应用到电话线映射的装置；用于创建一个呼叫对象以响应所述多条电话线中一条上的流入呼叫的装置；在所述话音应用到电话线映射的基础上，确定与所述流入呼叫相关的话音应用的装置；用来提供一个所述呼叫对象到确定话音应用的识别器的装置；在所述呼叫对象中的用于接收来自所述确定话音处理应用的媒体对象的装置，所述媒体对象表示在所述一条电话线上的期望输出；用来根据一个或多个表示标准将所述媒体对象加工成多个输出分量的装置；以及用来在所述一条电话线上输出所述输出分量的装置。
19.用来连接到至少一条电话线用于为一个或多个话音处理应用提供电话功能的话音处理系统，所述话音处理系统包括第一应用管理装置用来当话音处理系统初始化时开始一个或多个第一话音处理应用，所述的应用管理装置为所述一个或多个第一话音处理应用提供对所述电话功能的访问；第二应用管理装置，该装置响应第二话音处理应用的要求而启动以访问所述电话功能。
20.权利要求19的话音处理系统，其中所述第一和第二应用管理装置每一个都支持同样的静态接口，通过该接口，所述第一和第二话音处理应用获得对电话功能的访问。
全文摘要
一种有多个主机的话音处理复合体，每个主机支持一个或多个话音应用，至少复合体中一台主机包括用来提供对大量电话线访问功能的电话硬件。这种主机为复合体提供电话功能。这是经过保持话音应用到电话线映射并创建一个呼叫对象以响应其中一条电话线上的流入呼叫而实现的。然后，在该映射的基础上确定哪一个话音应用与流入呼叫相关，然后呼叫对象的一个标识被传送给确定的话音应用。因此，呼叫对象响应来自话音应用的请求用来为呼叫提供电话功能。
文档编号H04M3/50GK1239797SQ9910719
公开日1999年12月29日 申请日期1999年6月9日 优先权日1998年6月9日
发明者S·D·博尔曼, D·S·雷沙, 黄钰麟 申请人:国际商业机器公司