实现计算机电话接口的自动呼叫分配的制作方法

专利名称：实现计算机电话接口的自动呼叫分配的制作方法
技术领域：
本发明涉及计算机电话集成(Computer Telephony Integration，CTI)，更具体地说，涉及一种改进的自动呼叫分配器(Automatic CallDistributor，ACD)，其能够通过将CTI应用程序与软件ACD串行地级联起来以利用具有少许或没有智能的交换机实现ACD能力。
背景技术：
ACD能力最近已经变成大部分呼叫中心环境的一个标准部分。ACD涉及接收相对大量的呼叫，并且根据各种算法将它们分配到代理(agent)和/或自动设备以进行服务和处理。
在更近的系统中，通过将特定的呼叫与特定的代理进行匹配来优化呼叫分配功能是公知的。例如，到信用卡服务公司的呼叫可以基于电话号码被归类到指示呼叫者是“黄金”成员还是“白金”成员的几个组之一。然后，依据呼入的呼叫被归类的组，将该呼叫放入几个不同队列中的一个，从而具有最高成员级别的呼叫者将更快地被服务。
在当前的ACD技术中存在许多对呼叫者的经历进行优化的其它例子。例如，呼叫者可能被匹配到说特定语音、熟悉特定的问题等专门的服务代理。大部分系统也提供这样的功能能够根据呼叫号码标识或者诸如账号的其他用户输入来确定呼入呼叫者的身份。这样的步骤允许系统用关于顾客账户的具体信息来检索数据库记录，并且在连接呼叫者与代理之前将这样的数据库记录显示给代理。
前面所述的以及其他的ACD能力要求相当程度的智能以顾客为前提内建于交换设置中。图1示出了现有技术的系统的高度抽象化的示意图，该系统用于实现前面所述系统的示例性实施例。服务器101代表传统的ACD平台，该平台包括排队能力、呼叫转发和呼叫路由、允许按名称转发呼叫的名录(directory)信息以及其他类似的项目。
通信链路102是全功能的CTI链路，其将由103表示的业务应用程序服务器(business application server)连接到传统的ACD平台101。例如，这样的CTI链路可以使用ECMA标准协议进行操作。应用程序服务器103通常包含软件来执行标准的业务呼叫中心功能，例如订单录入。应用程序服务器103也可以包含顾客信息数据库，以在分配呼叫时由代理使用。
在图1的设置中，应用程序服务器103可以调用和控制ACD平台101中存在的特征的鲁棒集。但是，ACD平台101一般是专有且相对昂贵的系统，但具有较少的灵活性。编写作为应用程序103的软件的应用程序开发者必须假定全套ACD能力在ACD平台101都是可用的。因此，如果企业仅仅具有基本的交换环境，而没有全套的ACD能力，图1的设置将不能工作，这是因为在没有ACD能力的传统交换环境中，基本功能对于满足一般的应用程序103的需求是不够的。
图2描述了一种更先进的用于实现ACD能力的现有技术的系统。在图2中，以框201示出电话环境，与图1的现有的设置不同，它不包含ACD能力。相反，电话环境201可以是例如PBX的基本交换系统。在较新的环境中，电话环境可以改由分组电话网络组成，因此可以在会话启动协议(Session Initiation Protocol，SIP)环境中包括H.323看门程序(gatekeeper)、代理(proxy)或通路(pass-through)服务器。将应用程序计算机连接到这两个分组电话环境的技术在本发明的受让人所拥有的美国专利No.6,201,805以及审查中的申请Nos.10/092,832中进行了说明。
在图2的设置中，电话环境201仅包括基本交换功能，例如基于输入的电话号码在特定的设备或端口之间连接呼叫。电话环境201通常不包含“智能”，因此不能够基于用户的名字进行呼叫路由、对呼叫进行排队、将呼叫与顾客数据库的记录进行匹配等。这些功能一般是任何ACD系统的一部分，因此必须是在控制电话环境201的基本功能的软件中分别实现。
将上述更进一步，排队和分配软件203通过链路204发出适当的基本呼叫控制命令到电话环境中，以使电话环境201执行所要求的基本交换功能以完成ACD系统的功能。CTI应用程序服务器202运行单独的业务应用程序(例如，订单录入)，这常常是独立于排队和分配软件203而编写的。如果CTI应用程序服务器202提供CTI呼叫控制功能，这通常被安排来仅仅提供对于电话环境201可用的基本CTI功能，而不是在排队和分配软件203中实现的全套ACD功能。
图2中的系统允许通过编写另外的软件203来将非智能的交换机(例如，201)用作ACD系统。但是，顾客的业务应用程序202并不具有对包括软件203中所实现功能的组合系统的全局视角，并且不能够利用排队和分配软件203中的ACD能力。此外，因为交换机201仅能够理解和实现比如连接和断开呼叫、发出呼叫完成事件等非常基本的功能集合，所以业务应用程序202仅能够发出基本命令到交换机201。没有基于身份或技能的呼叫路由、排队等是可用的。这使得应用程序开发和呼叫流的设计更加困难和麻烦。
因此，现有技术一般在两种竞争需求之间折衷。图1的设置允许业务应用程序103使用完整并鲁棒的呼叫控制命令集合，并且可以完全控制呼叫通过ACD系统的方式。但是，需要智能、复杂并且经常是专有的ACD平台101。另一方面，图2的设置允许ACD能力被实现为对非智能交换机或其他电话环境接口的补充。但是，业务应用程序和ACD软件常常是独立的，因此业务应用程序不具有对组合系统的完全控制，并且不能利用完整并鲁棒的呼叫控制功能集合。


图1示出了实现自动呼叫分配(ACD)能力的第一示例性的现有技术设置；图2说明了实现ACD能力的另外的现有技术设置；图3是本发明示例性实施例的抽象性框图；图4示出了图3中所说明的ACD软件更详细的示意图；图5说明了由应用程序所发出的和由ACD和交换机所处理的复杂命令的流程图。
具体实施例方式
本发明公开了一种软件ACD，其能够使用分组电话环境或其他仅能够执行基本命令的非智能交换机工作。此外，所公开的软件ACD也可以直接连接到业务应用程序并且向业务应用程序提供全功能的CTI链路。通过该链路，业务应用程序有能力使用CTI命令和功能的鲁棒集，包括调用和控制电话环境的基本呼叫功能以及由所公开的软件ACD实现的增强ACD功能的命令。在本发明中，软件ACD被置于业务应用程序和交换机之间。该软件ACD包括这样的能力将一个或多个由业务应用程序发出的复杂命令翻译为一个或多个对应的基本命令，而这些基本命令能够由交换机或分组电话环境解码和执行。
在如图3所示的本发明的实施例中，软件ACD 302包括至少两个接口304和305。接口304是包括复杂CTI功能的鲁棒集的完整CTI协议接口。这样的接口可以根据ECMA或其他公知的标准被标准化，使得业务应用程序301好像被连接到如图1所示的传统ACD平台101一样，能够发出标准化的命令并请求功能。实际上，业务应用程序301可以仿佛通过链路102与传统ACD平台101进行通信一样被编写和构造。图3中所示的功能模块可以在相同的硬件或不同的硬件上实现。
除接口304外，“基本”接口305也由软件ACD 302给出。基本接口能够仅发出基本交换命令，例如拨打呼叫、应答呼叫、使呼叫等待、检测呼叫需要路由等。没有在基本电话环境外部所实现的其它逻辑，就不可能实现路由或排队。ACD 302必须首先将业务应用程序所需求的任何复杂功能转换为电话环境303所理解的基本命令序列。这样，如果排队功能是业务应用程序所期望的，那么它必须在ACD 302所产生的基本命令之外来建立，并被发送到电话环境303。为了完成该排队功能，ACD 302一般将使用适当的基本命令让所选择的呼叫处于等待状态，保留关于所有“等待(on hold)”中呼叫的状态的信息，并且再次使用适当的基本命令以适当的顺序完成这样的呼叫。使用多个这样的“基本”命令来实现“虚拟”排队功能，就可以允许应用程序301使用设计用于连接完整ACD平台的标准协议来进行操作，即使是使用了基本的、非智能的电话环境303。
接口304实现了与图1的接口102具有相似功能和命令的完整CTI链路。另一方面，接口305实现了与图2的接口204相似的命令。软件ACD302起着联络的作用，使用完全实现的CTI链路与应用程序服务器301进行通信，并且仅使用比如“建立呼叫”、“断开呼叫”等基本交换命令与交换机303进行通信。
接口304命令包括多种功能，例如对编址到虚拟路由点和队列的呼叫的管理和信令。通常与完整CTI链路相关联的其他功能包括识别和操纵代理的状态，其中，这样的代理由唯一而永久的虚拟名字来识别，而不是(或附加于)由它们有时所利用的电话设备的物理标识符来识别。更具体地说，完整CTI链路有能力指定某些代理对于接收任何呼叫都是无资格的，或仅对于接收特别的呼叫是有资格的。通常与完整CTI链路相关联的另一种功能就是将使物理电话设备与特定的ACD代理相关联。这允许对“乔”的呼叫被路由到乔就所在的任意特定台站，而不单单是路由到特定的电话号码。此外，完整CTI链路也能够以指定的方式处置到特定个体的呼叫，而不是以指定的方式处置到特定电话号码的呼叫。
相对比的是，与图2中接口204相似的基本接口305仅能够实现基本交换命令集，例如连接、断开、基于简单的电话号码等待和传送电话呼叫，以及检测呼叫是否要求由外部应用程序路由。尽管一些基本状态消息(例如，由于目标忙的呼叫失败)也能够被提取，但是在基本链路上没有可用的有关完整CTI实现方案所讨论的排队或其他高级别的功能。
软件ACD 302也包括可选接口306，用于向外部计算机系统报告关于ACD系统性能的统计信息。例如，这样的链路可以包括示出了呼叫持续时间和有关计费的其它信息的日志、质量参数、以及维护和维修系统所需的任何其它管理信息。接口306在各个系统之间可以互不相同，它的实现本身是可选的，对于实现本发明并非关键。
应用程序服务器301一般运行业务应用程序，在操作中它发出各种复杂的请求，例如基于“虚拟”队列或代理标识符的呼叫连接，以及呼叫路由和排队命令。ACD 302的基本功能是将这些复杂的呼叫连接、路由和排队功能分解为交换机303或其他电话环境能够执行的基本功能的序列。
ACD 302从业务应用程序301接收消息。在这样的接收后，如果ACD确定该业务应用程序已经发出了“基本的”(即，可以直接由交换机303执行的)功能和命令，那么该请求被简单地标注并被传送到交换机303。当软件ACD 302可能是出于例如从接口306向外报告它的目的而使用命令时，对这样的基本请求或命令不需要进行实质处理。
或者，如果该请求是针对完整CTI链路所支持的复杂功能而非交换机303能够执行的基本命令，则需要“翻译”。这所使用的翻译并不是要暗示在ACD的输入和输出消息之间存在一对一的关系。具体地说，在链路204上接收的单个复杂的功能或命令可能需要在接口305上发出一序列的基本功能和命令，并由交换机303执行。此外，来自应用程序服务器301的单个复杂命令可能要求在ACD 302和电话环境303之间交换状态消息和各种基本命令。单个复杂命令可以调用存储在ACD 302中的一个完整子程序。
关于接口305，ACD 302从交换机接收连续的状态消息，但是这样的消息不会立即被传送到业务应用程序301。相反，ACD使用所接收的基本消息来维护其关于交换机状态的知识。如果应用程序301要求控制基本交换功能，那么这样的基本消息可以以其初始形式被传送到业务应用程序301。此外，同样的那些基本消息以及其他没有被传送到应用程序301的基本消息的拷贝由ACD 302来使用，以构建状态以及包括业务应用程序301所理解的复杂功能消息的其它消息。这些复杂消息被传送到应用程序服务器301。
图4描述了图3中ACD 302更详细的图。图4的系统包括在ACD302内部用于实现上述功能的元件。应该注意，图4中所标出的功能框是逻辑上的，而非物理上的。所以，功能框中任何一个或多个可以用硬件或软件实现，这些功能框可以位于相同或不同的处理器上。
服务器接口410提供驱动程序软件和其他低级别的通信功能，用于对到图3中应用程序服务器301的链路进行操作。用于实现服务器接口410所需的基本通信驱动程序软件的技术在本领域中是公知的，并且随时随地可以得到。所以，就不在这里对它们进行详细说明了。
协议通路420是决策制定模块，其从服务器接口410接收命令，并且发送消息到服务器接口410。此外，协议通路420确定在传递消息到电话环境470之前是否需要翻译。如果在接口401上接收的命令是可以直接由交换机(例如，图3的交换机303)执行的基本命令，而且它也是排队和分配功能块440不需要知道的命令，那么只要将该命令通过接口402传递到电话环境470，而不用被改变。如果该命令是对与基本交换设备有关的状态消息的请求，那么将它通过接口407传送到功能块460，由功能块460标注后再传送到电话环境。否则，消息一定是对复杂ACD功能的请求，协议通路420将消息从接口403发送出去以用于进一步的处理。
排队和分配功能块440实现复杂的ACD功能，例如虚拟代理名称和呼叫排队。功能块440通过接口404接收复杂呼叫控制请求，将这些请求分解为多个基本呼叫控制指令，通过接口405发送这些基本指令，通过接口405接收响应，并通过接口404发送对初始的复杂请求的适当响应。
ACD接口450将来自以及到服务接口410的命令和消息翻译成“协议无关(Protocol Neutral)”的格式，使得它们能被功能块440轻易地处理。接口404上的消息具有与那些交叉接口403中的消息相同的信息，但是，用于任意特定CTI标准接口(例如，ECMA)的专用编码被去除了。
按照类似的方式，电话控制和监控功能块460进行操作，以从穿过接口406和407所接收的消息中剥除专用的编码，使得所述内容能通过接口405被传送到功能块440，并对从接口405接收并被发送给其他功能块的内容重新应用类似的编码。功能块460通过接口406发送命令到如图所示的电话环境，并从该电话环境中接收消息。功能块460通过接口407接收基本设备监控请求，并且通过同一接口用基本状态消息的序列做出响应。
如现有技术所公知的那样，接口430和470也包含基本的驱动程序软件，用于和特定的物理设备通信。
在操作中考虑以下应用程序，其想要通过使用图3中的基本交换机或其他电话环境303，结合图4中的ACD来实现通常的ACD功能，例如带呼叫分配的多个队列。命令通过全功能CTI接口被向下发送到服务器接口410，并被转发到协议通路420。协议通路420检查正被向下传递的具体命令，以确定这样的命令是不是能直接被交换机303执行的“基本命令”。如果该命令能够由交换机303直接执行，则将它传送通过电话环境接口470并发送给交换机来执行。
如果在协议通路420接收的命令是例如要求呼叫排队的复杂命令，那么过分简单化的非智能交换机303将不能执行这样的命令。相反，不得不由一系列到交换机的命令来建立排队功能，这些命令让各种呼叫处于等待状态，并通过将这些呼叫连接到用于和代理会话的适当的电话设备上，来指示交换机何时处理这些呼叫。
在这样的情形中，复杂命令通过ACD接口450被发送到排队和分配功能块440。接口404包含与通过接口403接收的初始复杂命令同样的信息，但是任何协议专用的格式化和其它信息都被去除了。排队和分配软件440包括用于保存ACD和电话环境元件的实时状态的数据存储，以及响应于特定的复杂命令而实施的所存储命令和子程序的序列。子程序让适当的基本命令被发送到电话环境接口470以由交换机执行。
注意，通过接口402和406在电话环境接口470所接收的基本命令被映射到物理设备和资源。因此，这些命令和消息是例如“建立到指定电话号码的呼叫”、“呼叫已经从指定电话设备断开”等内容。但是，应用程序服务器所发出的复杂命令常常可以包含虚拟设备的标记，例如用户名或队列。排队和分配软件440负责产生对于使交换机模拟全特征ACD的本地呼叫排队所必需的基本命令，以及负责将用户名翻译为用户所登录的物理设备。
通过利用被置于应用程序服务器301和电话环境303之间的ACD，应用程序服务器能够利用完整CTI命令的标准集合，同时能够利用基本的非智能交换机或较新的电话环境。此外，通过本发明所教导的设置，应用程序服务器能够同时发出关于基本模式和复杂模式功能和地址的CTI命令，该请求被正确地路由和处理。
所发出的基本命令被协议通路420直接传送通过的应用程序的例子是监控器命令，其中，应用程序期望监控特定的电话何时振铃。典型的“开始监控”命令将从应用程序发送到ACD 302，指定期望进行监控的电话的电话号码。这样的命令以标准化的形式，连同所附加的电话号码被传递通过ACD 302。协议通路420只是将所述命令传递到电话环境470，从而传送到交换机303。交换机303在对指定电话号码的呼叫到达时产生“呼叫振铃”消息。然后，该呼叫振铃消息未做修改就被传递通过功能块470、460、420和410到达应用程序服务器301。在这样相对简单的方案中，ACD不需要翻译或分解复杂命令为基本交换命令，因为原来的命令仅仅与基本设备和功能相关，所以可以由交换机303直接执行。
更复杂的情形示出在图5中的流程图中。图5的例子实现了用于监控呼叫的应用程序请求，该呼叫是由特定的代理，而不是由特定的电话号码接收的。
在更详细地说明图5的例子前，我们注意到ACD 302实际上可以并行地对被发送到应用程序服务器301以及从其接收的复杂命令和消息，以及对发送到同一应用程序服务器以及从其接收的、只是简单通过的基本命令和消息进行操作。由此，应用程序不需要在两种类型的请求之间进行区分，因为这里所公开的ACD 302对这种不同进行了自动处置。
转到图5，流程图从501开始。剩余的操作框包括要实现用于监控特定代理的电话的基本命令所需的功能。在所说明的典型例子中，代理负责从队列中按序列接收呼叫。从上下文中可以知道哪些步骤分别在交换机301、ACD 302或应用程序服务器303中操作。
在框502，队列由外部管理员来构造。使用在现有技术中可用的标准技术，管理员将向软件ACD发出命令来构造用于服务呼入电话呼叫的指定队列。在框503，选择和构造电话环境中的路由点，该路由点包括在电话环境中不对应于物理电话的虚拟电话号码。对路由点的电话号码的呼叫将使电话环境产生到ACD 302的信号，该信号将在ACD 302中触发后续的呼叫排队动作。
在框504，指定代理登录进入ACD 302，在框505，在这样的登录过程期间识别他所在的电话设备，还指示出从前面构造的队列中接受呼叫的能力。在代理登录后，ACD 302在框506向交换机303发出“开始监控”命令，指定在框505中所确定的代理的物理电话设备。
在操作期间，在框507，一方呼叫队列中的电话号码，并且在框503所定义的电话环境路由点处接收到该呼叫。作为在框506由ACD 302发出的“开始监控”命令的结果，在框508交换机303产生呼叫到达事件并将其发送到ACD 302，该事件指示呼叫已经到达特定的路由点。在框509，ACD 302发出基本呼叫路由命令，向交换机303通知这个特定呼叫应当被发送到的物理电话设备。(如果没有可用于该呼叫的物理电话设备，那么步骤509一直被延迟到这样的设备变为可用为止。)在框510，电话环境结束到该特定电话设备的呼叫，指示设备正在振铃的基本消息被电话环境发送到ACD 302。一旦接收到这样的消息，在框511，ACD 302通过表查找将振铃的电话映射到对应于该电话的特定代理。在框512，ACD 302将复杂消息发送到应用程序服务器301，指示该特定代理的电话正在振铃。
尽管应用程序服务器301和ACD 302之间的接口304能够请求特定的代理被监控，并且在代理的电话振铃时能够提供通知，但是交换机303并不了解特定的代理。相反，接口305仅仅交换与特定的电话何时振铃相关的信息和命令。在交换机303所理解的特定电话和应用服务器301所理解的特定代理之间的翻译将通过ACD 302进行。因此，应用程序将与交换机的基本命令隔离。
前面已经对本发明进行了说明，但是各种修改和添加对于本领域的普通技术人员是很清楚的。这里所给出的例子不是为了进行限制。
权利要求
1.一种装置，包括交换机，其响应于基本命令来交换呼叫，以及响应于交换所述呼叫来发送基本状态消息；自动呼叫分配器，用于将所述基本命令传送到所述交换机，以及用于接收所述基本状态消息，所述自动呼叫分配器也能够将所述基本命令和所述基本状态消息翻译为复杂的命令和状态消息，并通过所述复杂的命令和状态消息与外部应用程序相连接。
2.如权利要求1所述的装置，其中，所述应用程序计算机包括用于将所述复杂命令传送到所述自动呼叫分配器以及从所述自动呼叫分配器接收所述复杂状态消息的软件。
3.如权利要求2所述的装置，其中，所述自动呼叫分配器接收所述复杂命令，将所述复杂命令翻译为所述基本命令，并且将所述基本命令传送到所述交换机。
4.如权利要求3所述的装置，其中，所述基本命令是所述复杂命令的子集。
5.如权利要求4所述的装置，其中，所述自动呼叫分配器包括处理器，用于检查从所述应用程序接收的复杂命令、确定这样的复杂命令是否需要翻译为基本命令，以及无论是否被翻译，将所述复杂命令传送到所述交换机。
6.如权利要求5所述的装置，其中，所述自动呼叫分配器包括报告接口。
7.如权利要求6所述的装置，其中，所述自动呼叫分配器包括控制和监控接口。
8.一种方法，包括从软件应用程序发送命令到自动呼叫分配器，检查所述命令以确定所述命令是否在预定的电话环境能够对其进行操作的基本命令语言中，如果在其中，则将所述命令发送到所述交换机，如果不在其中，则将所述命令翻译为一个或多个所述电话环境能够对其进行操作的命令，然后将所述翻译后的命令发送到所述电话环境。
9.如权利要求8所述的方法，其中，所述自动呼叫分配器也被安排来对呼叫进行排队。
10.如权利要求8所述的方法，还包括通过分组电话环境交换呼叫。
11.如权利要求10所述的方法，包括通过看门程序交换呼叫。
12.如权利要求10所述的方法，还包括通过通路服务器交换呼叫。
13.一种用于实现自动呼叫分配器的装置，至少包括第一和第二接口，所述第一接口实现交换命令的基本集，并且被连接到交换机以使所述交换机执行所指定的操作，所述第二接口被连接到外部应用程序计算机，并且能够接受和处理复杂的命令，将所述复杂命令翻译为一个或多个交换命令，以及将所述交换命令发送到所述交换机。
14.如权利要求13所述的装置，包括计算机电话集成-自动呼叫分配器接口功能，用于在去除了在所述自动呼叫分配器和所述应用程序服务器之间所实现的某个协议专用的信息后，转发从应用程序服务器接收的消息。
15.如权利要求14所述的装置，还包括用于实施排队和分配软件的处理器。
16.一种制品或一组制品，包括在上面存储有指令的计算机可读介质，所述指令在被执行时，导致在软件自动呼叫分配器上从应用程序计算机接收命令，检查所述命令以确定它是否可以由所连接的电话环境直接执行，如果可以，则将所述命令传送到所述所连接的电话环境，如果不能，则将所述命令翻译为一个或多个基本命令并且将所述基本命令传送到所述电话环境。
17.如权利要求16所述的制品，其中，所述指令在被执行时，还导致响应于所述电话环境中的活动从所述电话环境中接收消息，确定所述消息是否需要被翻译，如果不需要，将所述消息转发到所述应用程序计算机，否则将所述消息翻译为一个或多个可以由所述应用程序计算机识别的消息，并且将所述翻译后的命令转发到所述应用程序计算机。
18.如权利要求17所述的制品，其中，所述命令中的至少一个导致将与个体相关联的标识符转换为与正被所述个体使用的电话设备相关联的电话号码，或者将所述电话号码转换为所述标识符。
19.如权利要求18所述的制品，其中，所述命令中的至少一个使所述自动呼叫分配器实现队列。
20.如权利要求19所述的制品，其中，所述命令实现路由。
全文摘要
本发明公开了一种软件ACD，其位于交换机或分组电话环境与运行呼叫处理应用程序的应用程序计算机之间。该ACD可以从应用程序计算机传递基本命令以由交换机或分组电话环境直接执行，或者响应于来自应用程序计算机的复杂命令，它可以产生一个或多个不同的命令以由交换机或电话环境执行。
文档编号H04M3/50GK1547843SQ03800616
公开日2004年11月17日 申请日期2003年8月19日 优先权日2002年8月19日
发明者唐纳德·芬尼, 卡尔·施特拉特迈耶, 唐纳德 芬尼, 施特拉特迈耶 申请人:英特尔公司