专利名称：实时通信呼叫中心服务器的制作方法
技术领域：
本发明涉及在呼叫中心和一个或多个用户之间通过实时通信呼叫中心服务器进行资源配置的方法和系统，前述实时通信呼叫中心服务器适于通过处理用户通信内容，为用户通信选择路由。
背景技术：
呼叫中心为消费者和商家提供了至关重要的通信链路。在当前的呼叫中心系统中，消费者通过标准公共电话网电话呼叫该呼叫中心的主要免费号码，然后与交互式语音应答(IVR)系统交互，该交互式语音应答系统会推导出主叫意图。一般地，在等待一段时间之后，主叫被转接到适当的呼叫中心代理，由后者随后与消费者通话，解决他或她的请求。在基于双音多频(DTMF)的那些实现中，主叫可能不得不处理一系列不同的DTMF菜单，以最终确定他的意图。在这种缓慢而又麻烦的处理之后发现实际上并没有DTMF菜单项能够很好地体现他们的意图时，主叫很容易感到沮丧，而这种情况并不少见。在某些情况下，主叫可能会选择退出，他按下“0”键，与呼叫中心操作人员交谈，以便更为快捷和准确地表明他或她的意图，这使得呼叫中心操作员不得不花时间在这些呼叫上，从而导致额外的呼叫中心开支。在其它情况下，主叫可能会因客户服务和支持很差而感到沮丧，挂掉呼叫，不在该公司购买其它产品。
一般地，在等待人工呼叫中心代理接入时，主叫会听到呼叫保持音乐(MOH)。在某些情况下，用音频资料替代了MOH，或者在MOH之外还会有音频资料。例如，到机票预订中心的呼叫可能为主叫提供了事先录制的音频通告，给出了到不同目的地的特价航班，或者周末旅行特价。此外，如果用户在IVR提示之后，通过DTMF输入了他的飞行常客(frequent flyer)代码，呼叫中心给出的呼叫保持音频(AOH)信息可能是主叫的飞行常客总里程。此外，主叫可以接收描述呼叫中心代理是否可用，以及预期在呼叫队列中等待的时间的音频信息，典型的音频通知的一个例子是“请等待，你的呼叫将在大约5分钟内应答。”随着电话网络从传统电路交换公共电话网演进到分组交换话音和数据IP网络，基于话音/数据综合的新的通信形式将会出现。因此，需要下一代呼叫中心支持这些新的通信形式，新的呼叫中心应当利用这种话音/数据的综合，提供增强的客户服务。
最有前景的话音/数据综合协议之一是会话初始协议(SIP)。SIP被优化为用于在IP网络和用户之间有效地建立综合媒体交换会话的建立、变动和拆除的有效处理。SIP协议的详细细节在因特网工程任务组(IETF)请求注释(RFC)3261中给出。
市场上已经出现了不同类型的SIP客户端。目前，最为广泛应用的SIP客户端是微软视窗(TM)实时通信(RTC)信使(Messenger)，它嵌入在微软视窗XP(TM)操作系统中，可以从华盛顿州Redding的微软公司购买。微软视窗(TM)RTC信使目前可以下载并安装到已有的微软公司老视窗(TM)系统，包括视窗95(TM)，视窗98(TM)，视窗NT(TM)，以及视窗2000(TM)。微软视窗(TM)RTC信使集成的功能包括发送即时消息(IM)、文本交谈、查看和改变在场状态、创建好友清单、建立并终止基于IP的话音(VoIP)呼叫、收发基于IP的视频、交换文档以及屏幕共享。这里称集成有实时通信服务器的SIP通信客户端为RTC信使。此外，称在不同人之间的端到端应用中使用的SIP通信客户端为“好友”。
发明内容
本发明的若干实施方式包括呼叫中心和用户，或者后面实施例中的主叫之间资源配置的方法和系统，每个用户的用户接口能够处理比如在因特网上包括即时文本消息和话音传输的通信。总体上，该方法中用户通过用户接口发送第一通信到呼叫中心，其中该呼叫中心包括实时通信呼叫中心服务器，用于处理多个用户的即时文本消息，以及处理多个用户的话音传输。本发明的实时通信呼叫中心服务器确定每个接收的初始用户通信的用户目的地地址；向确定的每个用户地址发送询问通信，如果接收到对该询问通信的应答用户通信，该RTC服务器利用该用户通信确定需要发送给该用户的通信内容的数量和类型，发送给该用户确定数量和类型的通信内容。此外，该呼叫中心可以有一个或多个呼叫中心代理，也就是通过本发明的RTC呼叫中心服务器应答用户的呼叫人员。该RTC呼叫中心服务器可以分析用户的通信内容，基于诸如用户与资源中心的初始通信的目的之类的信息，RTC呼叫中心服务器可以建立路由状态。该路由状态可以包括话音通信可以转接到的最佳呼叫中心代理。
基于SIP的通信客户端目前广为被采用，尤其是基于视窗(TM)的操作系统。这些基于PC的客户端支持集成的通信能力，如在场信息、即时消息、文本交谈、基于IP的话音、基于IP的视频、文件传送以及屏幕共享。尽管这些客户端一般用于通过因特网的人们之间的端到端形式的通信，或者在公司LAN上公司员工之间的通信，本发明的若干实施方式中允许使用这些客户端与呼叫中心通信。
在本发明的若干实施方式中，通过实时通信呼叫中心服务器(RTC-CCS)来提供新呼叫中心服务的输送。RTC-CCS所提供的一种这样的服务是交互式会话应答(ISR)。ISR利用了主叫具有集成话音和即时消息(IM)能力的事实，基于在即时消息中用文本指示的主叫的意图，精确地为话音呼叫寻找路由。另一个示例性的服务是IM帮助(IMH)，其中主叫开始时话音呼叫呼叫中心，在可能升级到与人工呼叫中心代理交谈之前，从RTC-CCS接收一个或多个即时消息，这些消息包括文本、网页链接或文档。RTC-CCS所提供的其它服务包括多信道交互(MCI)、会话保持(SOH)以及呼叫中心好友(CCB)。CCB允许消费者在他的好友清单中加入呼叫中心，以及随后利用RTC信使的内置在场能力传输呼叫中心状态，和/或推断出的该消费者会感兴趣的其它信息。
RTC-CCS为主叫提供了重要服务，而不需要对呼叫中心作额外改动。但是，如果呼叫中心代理也用RTC信使来代替传统的PBX电话，或者在传统的PBX电话之外还有RTC信使，那么RTC-CCS提供额外服务，包括文档交换、基于IP的视频、屏幕共享、主叫和呼叫中心代理之间的即时消息。另一实施方式具有辅助开发集成的呼叫中心代理应用的RTC-CCS桌面工具箱。
ISR具有若干优点，一个是它通过简单的无格式文本输入，允许主叫直接明确他呼叫的意图，而不是通过复杂的一系列DTMF菜单。利用ISR，主叫可以容易地、快速并准确地表明他的意图，从而消除了成本高昂的操作人员介入。此外，增加了总体客户满意度-客户能够更好地明确他的意图，从而在为呼叫选择路由时，精确度得以提高。利用ISR，客户能够与最能够满足他需要的呼叫中心代理通话。
通过举例说明本发明，但本发明并不受限于这些附图，在附图中图1给出了本发明的示例性总体网络拓扑；图2给出了本发明的一个实施方式的示例性信号事件；图3A给出了本发明的交互式会话应答实施方式的示例性信号事件；图3B给出了本发明的另一交互式会话应答实施方式的示例性信号事件；图3C给出了本发明的另一交互式会话应答实施方式的示例性信号事件；
图4A给出了本发明的IM帮助实施方式的示例性信号事件；图4B给出了本发明的另一IM帮助实施方式的示例性信号事件；图5给出了本发明的多信道交互实施方式的示例性信号事件；图6给出了本发明的另一多信道交互实施方式的示例性信号事件；图7A给出了本发明的会话保持实施方式的示例性信号事件；图7B给出了本发明的另一会话保持实施方式的示例性信号事件；图8A给出了进行与本发明呼叫中心之间的VoIP通话的示例性图形用户接口窗口；图8B给出了用于开始与本发明的呼叫中心的VoIP通话的示例性图形用户接口窗口；图8C给出了用于本发明的呼叫中心好友和在场信息的示例性图形用户接口窗口；图8D给出了用于本发明的呼叫中心好友和在场信息的示例性图形用户接口窗口；图9给出了本发明的一种实施方式的示例性信号事件，前述实施方式中主叫和代理具有集成的客户端；图10进一步给出了本发明的一种实施方式的示例性信号事件，前述实施方式中主叫和代理具有集成的客户端；以及图11给出了本发明的一种实施方式的示例性信号事件，前述实施方式中主叫和代理具有集成的客户端，代理具有的CRM处理。
具体实施例方式
现代呼叫中心一般支持与消费者进行电邮交换，还可以允许呼叫中心代理和消费者同时浏览万维网。增强的呼叫中心还可以采用计算机电话集成(CTI)技术连接到它的专用交换分机(PBX)系统，从而智能地，或者至少更为精确地为每个来话寻找路由，将其接续到当时认为最佳的呼叫中心代理，并且自动向该代理提供主叫信息。该主叫信息从呼叫中心的数据库中检索得到，可以在应答代理的图形用户接口中以弹出窗口的形式显示。呼叫中心代理利用与话音呼叫相结合的客户关系管理(CRM)软件，有效接入并关联客户特定的数据库信息的能力，是提供好的客户服务的一个完整方面。
当消费者使用基于SIP的通信客户端，例如RTC信使，以及集成多个通信信道的其它类似的软件客户端，与呼叫中心交互，在与呼叫中心的交互过程中，除了它们的传统电话之外，主叫还能够利用集成的通信信道，例如文本、网页、话音和视频。在本发明的若干实施方式中，称为实时通信呼叫中心服务器(RTS-CCS)的实体允许资源中心，例如呼叫中心，将重要的新业务提供给使用基于SIP的通信客户端，例如RTC信使和其它类似软件客户端的消费者。RTC-CCS利用基于SIP的通信客户端的流行性、普遍性和内置特征来提供这些新服务。本发明描述了基于使用RTC-CCS的呼叫中心体系结构，以及它所支持的新呼叫中心服务。这些服务包括交互式会话应答(ISR)、IM帮助(IMH)、多信道交互(MCI)、会话保持(SOH)以及呼叫中心好友(CCB)。此外，因为呼叫中心代理还可以使用包含基于SIP的通信客户端，例如RTC信使的PC，下面公开支持RTC的呼叫中心代理的附加拓扑和特征。实时通信呼叫中心服务器可以是按照客户机/服务器模型的一个或多个具有一个或多个服务器应用的服务器或计算机。RTC-CCS的通信指令可以包含在一个或多个包括基于脚本或可执行的应用的通信模块中。同样，RTC-CCS的路由指令可以包含在一个或多个包括基于脚本或可执行的应用程序的路由模块中。
如图1所示，RTC-CCS包括一个基于CPU的服务器120，它位于呼叫中心局域网(LAN)150的边界上，其中边界最好具有至少一个路由器，以及最好一个防火墙151，防火墙151最好包括连接到因特网140的分组过滤路由器，连接到呼叫中心LAN 150的分组过滤路由器，以及插入在两个路由器之间的应用网关。该呼叫中心LAN路由器/防火墙151对公开本发明的若干实施方式而言是透明的，本领域的一般技术人员会认识到不需要对它进一步阐述。具有基于SIP的通信客户端，例如RTC信使和运行于他们个人计算机(PC)110上的其它类似软件客户端的用户，例如那些使用最新视窗(TM)操作系统的用户，适于通过他们的主叫RTC IM接口110联系使用RTC-CCS的呼叫中心。在与用户交互时，呼叫中心代理接口130可以采用各种不同类型的装置。这些装置包括PBX电话、执行CRM软件的PC、CTI应用程序、浏览器以及基于SIP的通信客户端，例如RTC信使和其它类似软件客户端。
在一种实施方式中，RTC-CCS充当中间设备服务器，在传统呼叫中心和使用RTC信使，或类似软件客户端的主叫之间提供一层，使得呼叫中心能够重用已有的PBX基础设施处理来自RTC信使或类似软件客户端的呼叫。在这种实施方式中，RTC-CCS提供了必要的翻译和转换功能，为主叫的基于VoIP(也就是基于SIP)的通信客户端与已有的，以前只处理来自公共电话交换网(PSTN)的话音呼叫的呼叫中心提供接口。
图2描述了RTC-CCS作为中间设备如何运作，其中以例子形式说明了具有传统基础设施(例如PBX222、PBX电话132、CTI客户端以及呼叫中心LAN 150)的呼叫中心和具有基于SIP的通信客户端，例如RTC信使的因特网用户之间的中间设备功能。主叫利用基于SIP的通信客户端作为接口110，用SIP INVITE消息(步骤201)经因特网140，经由RTC-CCS 120，向呼叫中心发出VoIP呼叫请求，RTC-CCS通过SIP OK信号(步骤202)通知它接受了该请求。RTC-CCS拨打一个电话呼叫到呼叫中心人工代理接口，本例中利用PBX CTI(步骤204)，从而导致PBX 222振铃呼叫中心代理130的PBX话机132(步骤205)。在该例中，采用CTI的RTC-CCS在呼叫中心代理的个人计算机134显示器上激活一个弹出窗口(步骤206)。RTC-CCS通过因特网或其它网络部分发送VoIP媒体到主叫，并从主叫接收VoIP媒体(步骤207)。RTC-CCS将话音媒体从IP转换到PBX数字格式，通过电话干线231向PBX发送，或从PBX接收话音媒体(步骤208)。该PBX通过数字线路240向呼叫中心代理的PBX电话132发送数字话音媒体和从呼叫中心接收数字话音媒体(步骤209)。该示例实施方式中中间设备的使用使得主叫能够使用新的客户端类型，例如RTC信使来访问呼叫中心的已有基础设施。在该示例实施方式中，RTC-CCS适于能够提供可视指示，例如弹出窗口。对客户数据库(未示出)的访问和索引可以利用SIPINVITE消息头中“From”来完成，而不是传统方法中PSTN所提供的主叫标识号码。
在优选实施方式中，RTC-CCS包括可选的CTI接口，从而能够与一种或多种类型的支持CTI的PBX互连。在一种异构的具有多个不同厂商的PBX的呼叫中心中，单个RTC-CCS服务器可以相应处理来自PSTN电话的呼叫和来自基于SIP的通信客户端的消息，将它们适当地寻路到任一PBX上的代理。
利用RTC-CCS充当中间设备层，呼叫中心继续向主叫提供与呼叫中心目前向在PSTN所支持连接中使用传统的话机或者RTC信使的主叫提供的服务集相同的服务集。但是，RTC-CCS的一个优势在于，它在处理简单话音呼叫之外，还提供了有用并且新的服务。RTC-CCS所提供的新服务综合利用了主叫RTC信使客户端或类似客户端的内置集成通信特征。
交互式会话应答图3A给出了这里称为交互式会话应答(ISR)的服务，在若干实施方式中，它源自RTC-CCS，并且是RTC-CCS的一部分。通过ISR，RTC-CCS利用了主叫的集成话音和即时消息(IM)能力。ISR根据主叫在联系呼叫中心时对其意图的文本描述，也就是即时消息(IM)体的文本内容，准确地为呼叫寻路。ISR扩展了间接寻求确定主叫意图的交互式语音应答(IVR)及其相关联的DTMF交互的传统方法。利用ISR，主叫直接地在与话音呼叫相关联的IM的内容中确定他的意图。
在图3A所描述的ISR的优选实施方式中，主叫在(步骤301)中向具有RTC-CCS的呼叫中心发起话音呼叫。RTC-CCS检查该初始话音呼叫，尤其是SIP INVITE(步骤302)头中的“From”和“Contact”字段，以确定发送IM的地址。RTC-CCS随后立即在(步骤303)中向主叫发送回请求主叫描述他的呼叫的意图和目的的询问通信IM，应答该呼叫。在优选实施方式中，主叫用自由格式IM应答响应RTC-CCS IM询问(步骤304)。RTC-CCS随后通过基于计算机的文本分析，理解和分析该IM响应，以最准确地推断出主叫请求，进而确定通信路由状态。基于对主叫文本响应的分析，RTC-CCS随后将呼叫寻路到最理想的代理(步骤305)。例如，ISR可以随后采用基于技能的路由和策略匹配方法，或者其它最合适技术来适当地为呼叫寻找路由。一旦被寻路，该呼叫以话音通话形式继续(步骤305)。在某些实施方式中，去和/或从呼叫中心代理的话音媒体经由已有的PBX话机，这种情况下，RTC-CCS最好进行VoIP转换，采用CTI与PBX交互。在另一种实施方式中，媒体保持VoIP格式，可以由RTC-CCS发送给呼叫中心代理的RTC信使或者类似客户端。
在可选的实施方式中，除了对主叫IM响应的计算机文本分析之外，RTC-CCS也采用其它基于策略的路由来适当地进行呼叫路由选择。例如，如果主叫发送回IM，例如“我的洗衣机，型号为350有问题。它漏水，我想与设备公司总裁说说这个事”，RTC-CCS会利用内容分析，以及已有的策略匹配，将呼叫转接到负责该设备公司型号350洗衣机的客户支持分部。尽管RTC-CCS推断出主叫的意图是与设备公司总裁讲讲设备指定类型和型号的产品支持和维修，但更高级的策略禁止将该请求直接转接给总裁，而是适当地将呼叫转接到客户支持部门。
作为选择，RTC-CCS可以将ISR和其它高级的呼叫路由处理结合，例如基于技能的路由，来适当为呼叫寻找路由。参照前一例子，可能目前没有可用的洗衣机型号350的代理，但具有洗衣机型号220和型号460技能的代理却可以提供服务。路由处理例如组合从ISR抽取的信息，然后确定具有型号220技能或型号460技能的代理是否最适合处理该次特定呼叫。
在优选实施例中，使用VoIP在主叫RTC信使或类似软件客户端，以及RTC-CCS之间交换话音媒体。RTC-CCS随后拨打呼叫中心代理的话机，将媒体从VoIP转换到PBX所使用的数字或模拟话音协议。在另一实施方式中，呼叫中心代理也可以具有VoIP客户端，例如RTC信使，所以在该实施方式中，不再需要媒体转换。下面描述呼叫中心操作的其它方面，其中该呼叫中心代理还使用VoIP SIP客户端，例如RTC信使。
在一些实施方式中，ISR采用本领域众所周知的计算机文本分析技术来确定话音主叫的内容。尽管在包含电邮分析以实现自动响应并将电邮转发给代理的应用中，这种文本分析技术在本领域中众所周知，但本发明的若干实施方式提供了计算机文本分析和话音呼叫的智能路由之间的关联。
在ISR的优选实施方式中，作为对RTC-CCS询问的响应，主叫在即时消息中明确其意图。此外，还有主叫通过非IM方法传送文本意图的其它实施方式。例如，在图3B中给出，RTC-CCS请求用户完成文本文档，其中明确呼叫的意图。ISR分析完成的文档的内容，将每个呼叫转接到最合适的代理。
作为选择，该文档可以最初由RTC-CCS转发给主叫，或者作为选择，该文档可以驻留在用户的接口设备中。该文档可选地可以包括其它信息，例如账号代码、客户信息、注册号、保修期以及类似信息。待完成的文档最好能够利用RTC信使或类似软件代理的内置文件交换能力推送给主叫，或者利用其它方式提供给主叫，例如页面下载或者事先存储在主叫的接口设备，例如个人电脑中。典型的例子是文档交换，前述文档不仅有主叫意图的文本信息，而且包含附加客户注册信息，例如客户地址，何时何地购买该项产品，以及客户可能购买其它产品的兴趣。文档中的信息随后可以用于为呼叫寻找路由，或者更新呼叫中心数据库，以便客户追踪、销售渠道分析以及类似处理。在图3B给出的ISR实施方式中，RTC-CCS IM包含文本提示和需要由主叫完成的文档(步骤303B)，随后主叫通过IM完成并返回由RTC-CCS转发给它的文本文档(步骤304B)。之后，在确定了通信路由状态之后，RTC-CCS分析提交的文档，使用事先描述的路由逻辑，将呼叫转接到最合适的代理(步骤305B)。
在图3C给出的另一示例性实施方式中，作为询问通信，从RTC-CCS的响应包括即时消息中的网页链接(步骤303C)。主叫点击链接，打开基于网页的表。主叫随后填充并提交该基于网页的表(步骤304C)，RTC-CCS随后利用该表确定通信路由状态，以准确地为呼叫选择路由(步骤305C)。这样，通过分析完成后的网页表的内容，呼叫被转接到最适当的代理。作为选择，网页表也可以在主叫接口设备上存储cookies，后者可以恢复为呼叫路由处理的一部分。
经由IM帮助的主叫辅助在图3A-3C给出的实施方式中，RTC-CCS通过向主叫发送单个询问来响应主叫，允许在将呼叫转接到人工呼叫中心代理之前，使得主叫能够通过IM、文档或网页表来明确他的意图。但是，当RTC-CCS确定了主叫的意图时，在某些情况下，可能不需要将呼叫转接到实际的人工代理。在这些实施方式中，RTC-CCS能够发送一个或多个即时消息，转发一个或多个文档，或者提出一个或多个网页链接，来提供所需的帮助。该RTC-CCS发明的这个可选方面这里称之为IM帮助(IMH)。
为了尽量减小人工呼叫中心资源的消耗，同时维持客户满意度，RTC-CCS首先寻求通过自动方式来解决主叫的需要，而不需要涉及人工呼叫中心代理。RTC-CCS提供IMH服务的处理的一个例子在图4A中给出。主叫通过例如从他的RTC信使发出INVITE，联系呼叫中心(步骤301)。RTC-CCS最好利用主叫SIP INVITE中的“Contact”来确定IM的目的地(步骤302)。RTC-CCS以询问通信回应主叫，通过IM提示或者请求主叫明确呼叫目的(步骤303)。在该例中，这通过IM完成，也可以通过下面描述的话音来完成。主叫以明确他的呼叫目的的IM回应(步骤304)。但是，在该实施例中，RTC-CCS120在推导通信路由状态后，确定不需要将话音呼叫转接到人工呼叫中心代理(步骤405)。在不满足转接到人工呼叫中心的条件时，RTC-CCS 120发送一个或多个附加IM，附上并转发文档，页面或HTML链接，或者RTC-CCS认为相关的其它基于文本的响应，自动为主叫提供帮助(步骤406)。在该步骤406中，为了满足主叫，可以提供任一或者所有这些IM。在某些情况下，RTC-CCS在没有直接涉及人工呼叫中心代理的单个自动事务处理中提供了所需的信息，满意的主叫终止了呼叫，如BYE传输所示(步骤407)。在图4B所示的其它情况下，可能需要在主叫和RTC-CCS之间进行附加交换；从用户发来消息(步骤407B)和发给用户消息的交换(步骤408)。在该例中，RTC-CCS 120自动介入与主叫之间的文本交谈(步骤408)，按照这种格式，RTC-CCS 120提出并交换一个或多个文档和网页链接，以满足主叫的意图，而不需要直接涉及人工呼叫中心代理。例如初始IM可能不会完全满足主叫的意图，在话音呼叫或者被升级转接给最适当的呼叫中心代理，或者被终止之前进行后续包含了附加的文本消息、HTML链接，和/或所附文档的IM交换。在某些情况下，这种多次交换是足够的，使满意的主叫终止了话音呼叫。另一些情况下，作为确定通信路由状态步骤的一部分，最好利用记分系统和预定条件，RTC-CCS 120推断出实际需要人工呼叫中心代理(步骤409)，根据该推断，RTC-CCS将呼叫适当地转接到最适合的人工代理(步骤410)。
在可能将话音呼叫升级之前，在同一会话中利用即时消息、文档交换和/或网页浏览的基于IM的自助服务，提供了一种框架，在该框架内由RTC-CCS 120提供IM帮助或IMH服务。这种服务利用了主叫RTC信使的集成的即时消息、文档交换和页面访问能力。IMH保存了呼叫中心人工代理资源，同时仍能满足主叫的需要。如果RTC-CCS 120推断出在IMH会话中一个或多个自动交换之后，主叫的需要仍然未满足，RTC-CCS会将话音呼叫转发给最适合的人工呼叫中心代理。呼叫路由处理最好基于消息304中的主叫意图的初始指定，或者基于交换的整个历史。相应地，RTC-CCS 120最好在可能将话音呼叫升级之前，在同一会话中利用即时消息、文档交换和/或网页浏览，进行基于IM的自助服务，以更好地分配示例性呼叫中心的资源，同时按照识别的意图为主叫提供有用的内容。
多信道交互在前面公开的实施方式中，RTC-CCS 120通过将呼叫转接到人工代理，以及RTC-CCS 120和主叫之间包含即时消息、文档和网页链接的非话音交换的交互，提供了呼叫中心的话音服务。在另外的实施方式中，RTC-CCS 120本身在会话中在音频传输中发言或者介入，并听主叫说话。在另外的实施方式中，RTC-CCS在前面描述的所有ISR和IHM服务中集成了语音，使得主叫利用话音和/或文本信道，与RTC-CCS 120交互，前述话音和/或文本信道最好已经内置在他的RTC信使客户端中。
在一个基本的例子中，接收到话音呼叫之后，RTC-CCS 120口头感谢用户拨打，随后发送给主叫一个即时消息，请求有关呼叫目的的更多的信息，然后口头要求主叫明确呼叫的目的，在主叫的IM响应之后，口头感谢该主叫。RTC-CCS 120对多个文本、文档交换和话音信道的使用这里称之为多信道交互(MCI)。
图5给出了RTC-CCS 120的MCI服务如何工作的一个例子。最初，主叫通过从他的RTC信使发出INVITE，联系呼叫中心(步骤301)。RTC-CCS 120利用主叫SIP INVITE中的“Contact”来确定IM的目的地(步骤302)。RTC-CCS随后以即时消息的形式发送询问通信给主叫，请求有关呼叫目的的更多信息(步骤503)。同时，作为选择，RTC-CCS也可以跟主叫交谈，礼貌地要求主叫(步骤503)提供必要的信息，使得能够对呼叫进行评定，从而可以转发给最可能提供服务的代理。用户最好发送即时消息，和/或与RTC-CCS交谈，或者同时利用这两种方式(步骤504)来回应。该用户随后在RTC-CCS确定通信路由状态步骤期间(步骤506)，可能在(步骤505)接收呼叫保持音乐，前述RTC-CCS确定通信路由状态步骤最好包括分析主叫IM和/或话音，确定文本、HTML链接或所附文档的最佳内容，同时由RTC-CCS 120在(步骤507)中交换一个或多个后续即时消息、文档或网页链接。RTC-CCS 120可以口头询问主叫(步骤508)，确定该材料是否令人满意，也可以倾听主叫的口头响应(步骤509)。通过这种方式，利用多个媒体信道的组合，改善用户的感受，使得主叫和呼叫中心之间的交互更令人满意，而不需要涉及人工呼叫中心代理。
前面提过，主叫和RTC-CCS 120之间的初始联系可以是话音呼叫，最好使用VoIP。但是，在本发明的另一方面，初始联系可以经由IM。在这种实施方式中，RTC-CCS提供了例如ISR、IMH和MCI服务的组合。
例如，图6给出的场景中，消费者最初通过IM联系呼叫中心(步骤601)。RTC-CCS 120利用即时消息头中的“From”和“Contact”字段(步骤602)，进行询问通信，并且RTC-CCS 120由此确定如何发送后续的SIP INVITE消息(步骤603)。如果消费者接受了SIPINVITE，并且在RTC-CCS 120推导通信路由状态的步骤中，确定不需要人工呼叫中心代理立即介入(步骤604)，RTC-CCS 120可以提供附加信息(步骤605)，随后作为RTC-CCS 120话音和IM交互处理的一部分(步骤606)，与主叫交谈，通过话音或文本，或者这两种方式请求有关主叫意图的附加信息(步骤607)，并例如倾听主叫(步骤608)。这样，对本发明的这种实施方式而言，RTC-CCS 120可以通过对主叫的或者SIP INVITE或者即时消息予以响应，从而发起呼叫中心的会话。
会话保持
RTC-CCS 120综合了向主叫发送呼叫保持音乐(MOH)或呼叫保持音频(AOH)信息。RTC-CCS不再只输送音乐或音频，而是能够利用客户具有集成的客户端，例如RTC信使，其能够支持多种信息信道的输送，输送即时消息、文档、即时消息中的网页链接、视频和音频。这种特定的RTC-CCS服务这里称为会话保持(SOH)。
图7A给出了RTC-CCS 120输送SOH功能的方式。SOH综合了传统的MOH和呼叫排队。在主叫等待某个代理提供服务时，RTC-CCS 120可以发送包括诸如文本、HTML链接、文档、音频片断、视频片断和音频视频片断等内容的附加IM。该信息可以包括广告、特价商品、个人账号状态、相关产品信息、预期等待时间信息以及类似信息。在该实施例中，当主叫联系呼叫中心(步骤301)时，RTC-CCS 120确定主叫接收IM的目的地(步骤302)，然后作为询问通信发送具有文本提示和需要由用户完成的文档的IM(步骤703)。主叫随后输入描述呼叫目的的信息(步骤704)，在完成并提交这些输入之后，作为确定通信路由状态的步骤的一部分，RTC-CCS 120开始执行路由决定，并最好基于主叫IM的内容和主叫完成的文档进行寻路(步骤707)，路由决定还可以包括已有的呼叫代理路由逻辑。但是，在该例中，不是立即将主叫连接到人工代理，而是由RTC-CCS 120分析主叫IM，利用呼叫中心策略来输送适当的会话内容，也就是，需要通信的内容信息的数量和类型，在主叫等待代理提供服务(步骤705)时，向主叫输送多媒体信息(步骤706)，这种多媒体信息可以包括包含文本、HTML、所附文档的IM，以及作为可选的多媒体内容的视频和音频片断。例如，在机票预定场景中，RTC-CCS 120输送一个短视频片断，该视频片断描述周末旅行特价，在IM中提供一个购买该特价机票的网页链接，和/或在即时消息中发送主叫的当前飞行常客的余额。RTC-CCS利用主叫RTC信使或类似客户端中所有的可用通信信道，向用户提供信息。最后，呼叫被转接到最合适的代理(步骤707)，之后，基于话音的通话开始(步骤708)。
在场消息本发明的若干实施方式中，提供了图形显示的组合，与打到呼叫中心的话音呼叫一起协力运作，向主叫提供呼叫中心状态、队列中预期等待时间的更新信息。RTC信使，以及类似的软件代理，支持利用非音频方式显示可用数据，这里称之为在场状态。在场信息利用SIP NOTIFY消息发送给RTC信使，SIP NOTIFY消息体中包含有在场数据。利用RTC信使的内置在场能力，显示一个或多个好友的可用性。每个好友的在线、出去午饭、或者其它状态都可以通过RTC信使GUI显示。
在本发明的一个实施方式中，RTC-CCS 120利用在场消息发送呼叫中心可用信息给RTC信使。图7B显示了事件的优选顺序。主叫联系RTC-CCS 120(步骤301)，RTC-CCS确定IM的目的地(步骤302)，以询问呼叫的形式发送IM，后者最好提示需要完成所附文档以明确呼叫的目的(步骤703)，或者在IM文本中请求给出主叫意图或该次呼叫的目的。主叫发送IM，描述了呼叫的目的(步骤704)，该IM可能包括完成的前面由RTC-CCS 120发送的文档。根据对主叫意图的分析(步骤705)，RTC-CCS 120发送(步骤706)IMH文档、文本交谈和与主叫交谈，参与SOH交换。最后，主叫一般开始等待可以提供服务的呼叫中心代理。作为确定通信路由状态步骤的一部分，RTC-CCS 120使用主叫SIP INVITE消息头中的“Contact”字段来确定在场NOTIFY消息的目的地(步骤707B)。RTC-CCS 120随后发送在场信息给主叫的客户端，描述预期等待时间(步骤708B)。之后，确定通信路由状态(步骤709)，其中作为确定通信路由状态步骤的一部分，路由可以基于IM的内容，文档内容和路由逻辑。因为状态信息，例如等待下一代理的时间也可以通过SIP/SIMPLE基于在场的通知消息发送，主叫的RTC信使不再指示简单的存在状态，例如在线、不可用以及类似信息，而是显示预期等待时间，例如如图8C所示，下面予以描述。
在图7B所示的本发明的示例性实施方式中，RTC-CCS 120利用在场消息，通知主叫呼叫中心的可用性信息以及RTC-CCS 120认为主叫在呼叫中心队列中的预期等待时间，其中通过图形RTC信使显示通知主叫。主叫RTC信使的内置显示能力使得它能够通过图形装置，而不是音频装置，或者在音频装置之外还有图形装置，来使用户及时得到通知和更新。例如在只有图形更新模式下，主叫能够着手做他的工作，而不需要听音频中断，偶尔察看图形显示就可以知道他在呼叫中心队列中的当前等待状态。RTC-CCS 120定期发送有关主叫情况的状态更新，隐含地告知他在队列中的前移。在一种示例性实施方式中，RTC-CCS 120每分钟发送附加的SIP NOTIFY在场消息，更新主叫的显示，其中每个SIP NOTIFY在场消息包括更新后的等待时间。
主叫可以以多种方法使用RTC信使来与具有RTC-CCS 120的呼叫中心进行初始联系。图8A-C中给出了与具有RTC-CCS 120的呼叫中心进行初始联系的两种示例性方法。图8A和8B给出了主叫用以联系具有RTC-CCS 120的呼叫中心的手工过程。在该示例性方法中，主叫使用他的RTC信使手工输入呼叫中心的完全有效域名。例如，如果主叫希望用RTC信使对“A Generic Computer Store”发出话音呼叫，他如下开始话音通话，即开始时从即时消息窗口中选择行动下拉菜单，在开始话音信箱窗口打开的情况下，主叫输入“agenericcomputerstore.com”，如图8B所示。在该第一方法中，用户也可以如上所述，向呼叫中心的RTC-CCS 120发送初始即时消息，联系呼叫中心。在该例中，主叫使用开始话音通话，或者例如发送即时消息菜单选项，随后输入呼叫中心的完全有效域名。在该示例性方法中，呼叫中心没有进入主叫的好友清单。
联系呼叫中心的第二方法这里称为呼叫中心好友(CCB)，并在图8C中给出。利用该方法，主叫最初将呼叫中心加入他的好友列表。该实施例中CCB项对应于完全呼叫中心。在该例中，RTC-CCS 120接受主叫的好友请求，并呈现在场状态。用户随后发起话音呼叫，或者发送即时消息给他的CCB，其方式与他针对人类好友的操作基本相同。加入到主叫好友列表中的呼叫中心有助于更为直接的访问。一个或多个呼叫中心，例如该例中那些商业计算机零售商或者夜间运送服务的呼叫中心，现在占用了主叫桌面的一部分，可以经由IM，例如单击鼠标进行呼叫或联系。此外，某些实施方式中的在场信道用于指示呼叫中心的可用性。
如上所述，作为选择，RTC-CCS可以发送其它在场状态信息给登记的客户端。例如，有关呼叫中心状态的信息被推送到用户，不管是否有初始、或者激发的用户呼叫到达该呼叫中心。图8C给出了RTC信使好友清单例子，更新的在场信息从具有RTC-CCS的两个呼叫中心发出。My-OvernightShipper-Buddy点的在场信息表明了尽管呼叫中心仍然运营，人工代理目前需要两分钟等待时间。类似地，agenericcomputerstore.com计算机支持的在场信息，Geri-Comp-Sup-Buddy，表明呼叫中心运营并且目前有可提供服务的呼叫中心代理。尽管目前没有涉及任何呼叫，消费者从OvernightShipper和A Generic Computer Store接收更新的在场信息。这个例子说明了主叫发起话音呼叫，或者发送即时消息给他的示例性呼叫中心好友“Overnight Shipper”和“A Generic Computer Store”，以及如上所述的接收IHM或SOH信息的图形接口。
经由在场消息的呼叫中心信息在任一特定时刻RTC-CCS选择发送给任一特定消费者哪种类型的在场信息需要在RTC-CCS中配置。例如，如果主叫向RTC-CCS发起了话音呼叫，作为选择，从RTC-CCS来的在场消息可以用于显示预期的等待时间，即使消费者没有发起呼叫，作为选择，RTC-CCS也可以通过在场通信信道发送销售信息、订单状态以及其他重要的呼叫中心数据。
图8D给出了在Overnight Shipping(通宵运送)的RTC-CCS和在A Generic Computer Store(通用计算机商店)的另一RTC-CCS如何利用在场消息，使得消费者即时了解包裹运送状态，以及客户化PC订单的状态。RTC-CCS利用在场通知消息发送其它重要状态信息。在这些例子中，消费者没有向Overnight Shipping或A GenericComputer Store发起话音呼叫，而是简单地将Overnight Shipping和A Generic Computer Store加入他的好友清单。RTC-CCS将相关信息推送给用户，而不需要向呼叫中心发起话音或即时消息呼叫。通过这种机制，呼叫中心在客户发起呼叫之前，提供重要的有用客户服务信息。
将CCB加入好友清单的一个好处是，即使没有发起呼叫，消费者也能够从呼叫中心的RTC-CCS接收个性化信息。该信息可以充当对消费者的提示，提示消费者之后要与呼叫中心进行即时消息或话音通信。
例如，消费者订购了笔记本，已经将“A Generic Computer Store”作为CCB加入。该消费者查看该信息，如图8D所示，想知道他笔记本PC的运送细节，以及是否仍可能购买更多的内存。该用户利用RTC信使，通过他的CCB与A Generic Computer Store建立联系。在该特定例子中，用户倾向于用即时消息与A Generic Computer Store开始初始联系。该用户与A Generic Computer Store的RTC-CCS之间相应的对话可以记录在对话框里。该用户首先通过即时消息与AGeneric Computer Store的RTC-CCS交互。客户，现在是主叫，可能会就他的未决笔记本订单问若干IM问题，然后才会升级到人工呼叫中心代理，由后者收集主叫追加购买所需的相关信息。但是，RTC-CCS并不是立即直接将该呼叫转接到人工代理，而是开始时寻求通过IMH来提供有关运送方法、笔记本内存需求的必要信息。当RTC-CCS确定现在需要用户与呼叫中心代理通话时，向用户的RTC信使发送话音INVITE，呼叫随后准确地被转接到精通笔记本处理内存销售的代理。利用主叫的IMH会话，经由转接到最佳呼叫中心代理的话音呼叫，RTC-CCS有助于在笔记本订单状态之间的平滑升级，在用户桌面上以在场状态形式示出。
具备SIP客户端的代理接口前面章节描述了RTC-CCS 120提供给具有集成客户端的主叫的重要服务。但是，当呼叫中心代理也具有集成客户端930时，在这些实施方式中，RTC-CCS提供了额外的特征和好处。图9给出了RTC-CCS呼叫中心体系结构，其中主叫和代理都有集成客户端，其步骤类似于前面描述的步骤，其中主叫进入与代理的通话。但是，在该实施方式中，话音现在作为VoIP，被发送给呼叫中心代理的集成客户端(步骤906)，而不是代理的PBX电话机。图9还说明了一个或多个呼叫中心代理也可以使用集成客户端来增加客户服务等级和满意度。例如，呼叫中心代理通过IM来提供客户相关的HTML链接、交换文档(步骤907)，并通过屏幕共享来提供远程支持(步骤908)。作为选择，呼叫中心代理也可以发送视频(步骤909)来提高个性化程度。在优选实施方式中，RTC-CCS 120用作这些交换的代理服务器。
图10进一步描述了RTC-CCS 120为VoIP SIP呼叫寻路的方式的细节。主叫向RTC-CCS 120发送INVITE(步骤1001A)，从RTC-CCS 120接收一个SIP OK(步骤1001B)，主叫随后以SIP ACK形式返回确认(步骤1001C)。作为询问通信的一部分，RTC-CCS 120发送一个IM(步骤303)，请求给出主叫的意图，最好接收的IM(步骤304)包含有足够的信息，从中可以识别出主叫的意图。在确定通信路由状态时(步骤1005)，RTC-CCS 120确定适当的呼叫中心代理，然后发出SIPINVITE(步骤1006A)，最好会话描述协议(SDP)明确主叫IP地址作为媒体源。呼叫中心代理利用“OK”应答该呼叫(步骤1006B)，以其IP地址C作为媒体源，接收确认(步骤1006C)。RTC-CCS 120向主叫重发SIPINVITE(步骤1007A)，通知主叫其媒体应当发送给呼叫中心代理IP地址C，随着OK(步骤1007B)和确认(步骤1007C)，通话开始，话音媒体从主叫首先到RTC-CCS120(步骤1008a)，然后到呼叫中心代理(步骤1008B)，以及从呼叫中心代理到主叫(步骤1009)。作为选择，RTC-CCS 120也可以进行进入媒体映射，从而阻塞进入呼叫中心的未授权的用户数据报(UDP)流。出于安全考虑，RTC-CCS还提供基于防火墙的进入媒体映射。会话也维持在RTC-CCS服务器上，从而可以得到呼叫中心的统计数据。RTC-CCS计算典型的呼叫中心统计数据，例如呼叫数量、平均呼叫时长、平均等待时间以及类似数据。RTC-CCS还计算衡量它所提供的新服务性能的统计数据。例如，计算的统计数据包括平均IMH交换数量、从IMH转变为话音的呼叫数量、即时消息的平均长度、请求CCB的主叫数量。RTC-CCS在某些实施例中还提供记录服务，记录整个联系过程，包括ISR和SOH交换，以及话音和视频。一些实施方式的RTC-CCS还提供下一代呼叫中心监视，由此其人工呼叫中心监视人员能够监控主叫和代理的交互，例如文本交谈或文档交换。
RTC-CCS有助于主叫和呼叫中心代理之间利用标准的RTC信使能力进行并行通信会话。例如，呼叫中心代理可以直接传送给主叫一个文档，例如帮助手册、产品手册或其它文件。主叫和代理也可以在话音通话的同时并行进行文本交谈。例如，作为选择，代理可以请求“请点击这个超文本链接以得到更多信息”，当发送包含该链接的IM给主叫时。呼叫中心代理可以可选地支持视频，以及RTC信使所支持的其它通信信道。这些信道包括屏幕共享、远程帮助、页面共同浏览、白板以及类似信道。虽然这些服务目前使用在因特网或企业LAN上的好友之间的端到端会话，但按照本发明的技术或步骤，这些业务可以应用于主叫和呼叫中心代理之间。
图11说明了本发明的优选实施方式，RTC-CCS 120向用户或主叫RTC IM接口110发送询问通信(步骤303)，根据接收到的信息，确定通信路由状态(步骤305)，最好使用CRM处理辅助呼叫中心代理1130与主叫的交互。CRM包也可以采用CTI，从而呼叫中心代理在应答呼叫时，可以从数据库中检索出客户信息，前述数据库以PSTN提供的主叫标识为索引，客户信息本可以从以主叫的SIPINVITE头中的“From”字段为索引的数据库中检索得到。也就是说，在优选实施方式中，呼叫中心代理使用集成RTC信使和CRM的单个软件应用，而不是两个单独的非集成应用。为了简化这种集成应用，称为RTC呼叫中心代理(RTC-CCA)的软件开发，图11中给出了RTC-CCS桌面工具的使用，该工具揭示了消息代理和RTC-CCS的功能。
本说明书中使用的描述本发明及其各种实施方式的文字不仅需要在普通意义上理解，而且应当理解为在普通意义之外，包含本说明书中结构、材料或行为的特定定义。因此，如果某个元素在本说明书上下文中理解为包含多于一种含义，那么在权利要求中它的出现必须理解为是一般性的，适于本说明书和文字本身所支持的各种可能的含义。
在不偏离这里公开的本发明及其若干实施例的精神和范围的前提下，本领域一般技术人员可以做出许多变化和改进。因此，必须理解，这里给出的实施方式只是为了举例说明，不应当理解为限制本发明，本发明由后续权利要求书定义。
权利要求
1.一种在呼叫中心和用户之间资源配置的方法，该用户的用户接口适于处理在网络部分上包括文本消息和话音传输的通信，该方法包括由该呼叫中心接收由该用户接口发出的第一通信，其中该呼叫中心包括实时通信呼叫中心服务器，适于处理多个用户的即时文本消息，以及处理多个用户的话音传输；以及由该实时通信呼叫中心服务器从该第一通信确定用户目的地地址；由该实时通信呼叫中心服务器向确定的用户地址发送询问通信；由该实时通信呼叫中心服务器接收对该询问通信的用户应答；以及基于对该询问通信的应答，确定该用户的通信路由状态。
2.根据权利要求1的方法，其中该呼叫中心还包括一个或多个呼叫中心代理。
3.根据权利要求2的方法，其中该确定通信路由状态的步骤还包括查询第一通信的内容以及对该询问通信的应答；以及根据该应答，确定最适合的该第一通信的内容，以及对一个或多个呼叫中心代理的询问通信的应答。
4.根据权利要求2的方法，还包括步骤按照该路由状态，将该用户转接到具有呼叫中心代理接口的一个或多个呼叫中心代理中的呼叫中心代理。
5.根据权利要求1的方法，还包括以下步骤由该实时通信呼叫中心服务器确定需要发送给该用户的至少一个通信中包含的内容的数量和类型；以及发送给该用户至少一个包含确定数量和类型的内容的通信。
6.一种在呼叫中心和至少一个用户之间的资源配置系统，每个用户的用户接口适于处理在网络部分上包括即时文本消息和话音传输的通信，该呼叫中心还包括适于处理包括多个用户的即时文本消息，以及多个用户的话音传输的用户通信的实时通信呼叫中心服务器；其中该实时通信呼叫中心服务器适于自动地确定每个接收的初始用户通信的用户目的地地址；向每个确定的用户地址发送询问通信；以及如果从至少一个用户接收到对该询问通信的应答通信，基于该应答确定需要发送给该用户的通信的内容的数量和类型，以及发送给该用户具有确定的数量和类型的通信内容。
7.根据权利要求6的系统，其中该通信中心还包括一个或多个呼叫中心代理。
8.根据权利要求7的系统，其中该通信中心确定资源代理路由状态。
9.根据权利要求8的系统，其中该通信中心按照该路由状态，将该用户转接到呼叫中心代理。
10.一种适于将呼叫中心的资源配置给至少一个具有地址的用户的服务器，该服务器包括通信模块，适于自动地向用户地址发送至少一个询问通信；以及向该用户发送至少一个根据对该询问通信的一个或多个用户应答确定的通信；以及路由模块，适于根据对至少一个询问通信的一个或多个用户应答，自动地将该用户转接到资源中心的资源。
全文摘要
具有处理用户即时文本消息和话音传输的实时通信(RTC)服务器的呼叫中心之间进行资源配置的方法和系统。该RTC服务器根据一个或多个即时文本消息交换的分析，确定该话音呼叫的适当路由目的地。在某些情况下，RTC服务器可以提供文档、包含HTML链接的即时消息和多媒体音频和视频，以期满足主叫而不需要将该话音呼叫转接到人工代理。RTC服务器还提供了会话保持、IM帮助、多信道交互和呼叫中心好友能力。
文档编号H04L12/54GK1697419SQ20041006158
公开日2005年11月16日 申请日期2004年12月27日 优先权日2003年12月26日
发明者迈克尔·S·温罗维茨 申请人:阿尔卡特公司