分布式呼叫中心环境中的本地存活的制作方法

随着云和分布式计算模式变得日益普通，在呼叫中心领域提供这些模式有很大的潜力。呼叫中心利用不同资源完成各种支持任务。这种资源包括具有不同专长或技能的呼叫中心代理、用于处理电话呼叫、电子邮件和其他交互的计算和语音资源以及本领域中常用的其他信息和通信技术(ICT)。

用于大企业的普通呼叫中心部署包括具有分布在不同地理位置上的几个分支站点的一个或多个数据中心。包括计算资源和数据库的主要的呼叫中心资源被托管在数据中心处。每个分支站点都通过数据通信网络连接到数据中心，而且包括本地资源，例如本地媒体资源、本地PBX、网页服务器和类似资源。

有些情况会导致本地分支丢失和数据中心的通信。在这些情况下，会希望本地分支在本地存活，并且在不访问位于数据中心处的资源的情况下继续提供呼叫中心服务。

在其他情况下，数据中心和/或本地分支可能由于请求太多而超负荷。在这样的情况中，如果这些其他站点具有超额容量，则会希望从其他呼叫中心站点获得额外的容量。

技术实现要素：

根据一个实施例，本发明涉及一种用于分布式呼叫中心环境中的本地存活的系统和方法。第一呼叫中心节点中的第一处理器接收用于交互的第一请求。第一处理器响应于用于交互的请求将第一消息传送到第二呼叫中心节点。第一消息被配置为调用与第二呼叫中心节点关联的第一资源，以用于通过第一资源处理交互。第一处理器监测与第二呼叫中心节点的连接。第一处理器接收用于交互的第二请求，并且还判定是否缺少与第二呼叫中心节点的连接。响应于判定缺少与第二呼叫中心节点的连接，第一处理器阻止向第二呼叫中心节点传送第二消息。根据一个实施例，第二消息用于调用与第二呼叫中心节点关联的第二资源，用于通过第二资源处理交互。

根据本发明的一个实施例，第一或第二资源是与第二呼叫中心节点关联的媒体服务器的媒体端口。交互可以是语音呼叫，交互处理可以是在语音呼叫期间播放媒体。

根据本发明的一个实施例，第一或第二消息是对媒体服务的请求。

根据本发明的一个实施例，响应于判定是否缺少与第二呼叫中心节点的连接，通过第一呼叫中心节点提供的本地资源处理交互。

根据本发明的一个实施例，第一处理器向在对等网络中连接到第一节点的对等节点传送指示第一呼叫中心节点的本地资源的容量的第三消息。第三消息可以用于请求额外容量，并且响应于第三消息，对等节点可以提供所请求的额外容量。向第一呼叫中心节点提供额外容量可以包括经由对等节点处的本地资源由对等节点处理第一处理器接收的第二交互。

根据本发明的一个实施例，响应于判定缺少与第二呼叫中心节点的连接，与第二呼叫中心节点关联的呼叫中心代理被提示要重新登录到第一呼叫中心节点。

本发明的实施例还涉及一种用于分布式呼叫中心环境中的资源共享的系统和方法。第一呼叫中心节点监测与第一呼叫中心节点关联的资源的使用，并检测高于第一阈值的资源的使用。第一呼叫中心节点识别具有空闲容量的第二呼叫中心节点。第一呼叫中心节点通过对等网络连接到第二呼叫中心资源节点。第一呼叫中心节点将第一呼叫中心节点接收的交互路由到第二呼叫中心节点，用以通过与第二呼叫中心节点关联的资源处理交互。

根据本发明的一个实施例，与第一或第二呼叫中心节点关联的资源是分别由第一和第二媒体服务器提供的资源。

根据本发明的一个实施例，交互是语音呼叫，交互的处理是在语音呼叫期间播放媒体。

根据本发明的一个实施例，在交互期间，在提供交互式语音应答服务时播放媒体。

根据本发明的一个实施例，与第一和第二呼叫中心节点关联的资源是呼叫中心代理。

根据本发明的一个实施例，响应于检测到高于第一阈值的资源的使用，第一呼叫中心节点通过对等网络向第二呼叫中心节点传送第一消息。第一消息可以指示与第一呼叫中心节点关联的资源的第一类型容量。第一呼叫中心节点通过对等网络从第二呼叫中心节点接收指示与第二呼叫中心节点关联的资源的空闲容量的第二消息。第一呼叫中心节点将交互路由到第二呼叫中心节点是响应于接收到第二消息。

根据本发明的一个实施例，第一呼叫中心节点检测低于第二阈值的资源的使用，并响应于检测到低于第二阈值的资源的使用通过对等网络向第二呼叫中心节点传送第三消息。第三消息指示与第一呼叫中心节点关联的资源的空闲容量。第一呼叫中心节点从第二呼叫中心节点接收被第二呼叫中心节点转发的交互。第一呼叫中心通过与第一呼叫中心节点关联的资源中特定的一个处理所转发的交互。

根据本发明的一个实施例，第一呼叫中心节点检测高于第二阈值的资源的使用，并响应于检测到高于第二阈值的资源的使用通过对等网络向第二呼叫中心节点传送第四消息。响应于第四消息，第二呼叫中心节点阻止了向第一呼叫中心节点转发新的交互。

本领域的技术人员应该理解，本发明的实施例允许呼叫中心站点本地存活，并在不能访问位于中心站点处的资源时提供呼叫中心服务。呼叫中心节点还可以在对等网络中相互连接，从而允许超负荷的节点从具有空闲容量的其他节点接收容量。在这方面，通过呼叫中心站点和部署可以让资源得以有效使用。与超负荷呼叫中心的资源共享还有助于超负荷呼叫中心维护和/或改进它的服务水平。资源共享可以在同一个(分布式)呼叫中心中、横过不同的呼叫中心和/或类似位置。

通过下文的具体介绍、所附权利要求和附图，可以理解本发明的上述和其他的方面的优点和特性。当然，本发明的实际范围由所附权利要求限定。

附图说明

图1是根据本发明的一个实施例的分布式呼叫中心系统的方框图；

图2是特定的呼叫中心资源的各种容量状态的概念布局图；

图3是根据本发明的一个实施例的具有呼叫中心(CC)节点的呼叫中心站点的更详细的示意性方框图；

图4是根据本发明的一个实施例的在CC节点间交换的示例性消息的消息图，其中CC节点A达到空闲容量，CC节点B达到超负荷容量；

图5是在CC节点间交换的示例性消息的消息图，对于特定的资源来说，CC节点B从超负荷状态转为额定状态；

图6是根据本发明的一个实施例的当CC节点A收回它与CC节点B共享的空闲容量时在CC节点间交换的示例性消息的消息图；

图7是根据本发明的一个实施例的包括主节点的分布式呼叫中心系统的示意性方框图；

图8A是根据本发明的一个实施例的在CC节点和注册节点之间交换的示例性消息的消息图；

图8B是根据本发明的一个实施例的通过OAuth协议在另一个节点(资源拥有者)拥有的资源服务器中认证客户(请求节点)使用资源的消息图；

图9是根据本发明的一个实施例的在CC节点和注册节点之间交换的示例性消息的消息图，其中CC节点X被CC节点中的一个拒绝访问联盟；

图10是根据本发明的一个实施例的用于监测和判定特定资源的容量或资源类型的进程的流程图；

图11是根据本发明的一个实施例的在企业部署中的分布式呼叫中心系统的方框图；

图12A-12B是根据本发明的一个实施例的在分支CC节点和数据中心之间交换的用于启用本地存活的示例性消息的消息图；

图13是根据本发明的一个实施例的在跨企业部署中的分布式呼叫中心系统的方框图；

图14是根据本发明的一个实施例的在云部署中的分布式呼叫中心系统的方框图；

图15是根据本发明的一个实施例的云部署方框图，其中在常规操作期间，呼叫中心服务由CC云节点提供；

图16是根据本发明的一个实施例的描绘了缺少到CC云节点的连接而导致预置节点在本地存活模式下工作的云部署的方框图；

图17A是根据本发明的一个实施例的计算设备的方框图；

图17B是根据本发明的一个实施例的计算设备的方框图；

图17C是根据本发明的一个实施例的计算设备的方框图；

图17D是根据本发明的一个实施例的计算设备的方框图；以及

图17E是根据本发明的一个实施例的包括几个计算设备的网络环境的方框图。

具体实施方式

在通常的术语中，本发明的实施例涉及用于分布式呼叫中心环境中的本地易存活性和资源共享的系统和方法。在这一点上，呼叫中心节点通过分布式网络体系结构(例如，对等(P2P)网络)连接到另一个呼叫中心节点。呼叫中心节点可以被描述为具有硬件、软件和网络容量的计算机节点，以为终端顾客提供呼叫中心服务，并且通过P2P网络与其他计算机节点通信。根据一个实施例，每个呼叫中心节点被托管在可以脱离其他呼叫中心站点自主工作的呼叫中心站点处。呼叫中心站点可以是指包括呼叫中心节点的各部件以及其他呼叫中心设备的物理地理位置，或者使物理呼叫中心设备可以分布在不同物理位置、但一起工作以形成虚拟呼叫中心站点的虚拟位置。根据此实施例，每个呼叫中心站点都具有呼叫中心资源(或与呼叫中心资源相关联)，例如代理、媒体资源、计算资源和类似资源，所述呼叫中心资源可以用于处理到达呼叫中心站点的请求。请求通常可以是用于呼叫中心顾客发起交互的请求。在各实施例中，术语交互通常用于指使用任何通信信道的任何实时和非实时交互，所述通信信道包括但不限于电话呼叫(PSTN、VoIP、移动电话呼叫)、电子邮件、语音邮件(通过电子邮件的语音邮件)、网页协作、视频、聊天、屏幕共享、文本消息、社交媒体消息、网页实时通信(例如，WebRTC呼叫)和类似信道。

根据一个实施例，呼叫中心站点中的一个或多个可以连接到中心站点，例如托管呼叫中心资源中的一个或多个的中央数据中心。在使用的时候，中心站点可以和相关联的呼叫中心站点共同工作以处理用于呼叫中心的交互。根据一个实施例，尽管到中心站点的连接丢失，但仍然可以提供呼叫中心服务。连接丢失可以是由于到中心站点的通信链接失败和/或中心站点托管的一个或多个节点失败。其他原因可以是停电、人为错误(例如，错配置)和类似原因。

根据一个实施例，各种呼叫中心节点与其他每一个节点共享资源容量信息，使得超负荷的呼叫中心节点可以使用具有空闲容量的呼叫中心节点的资源。在某些情况下，共享资源的节点可以与不同的实体关联，举例来说，例如不同呼叫中心或不同部署(例如，与云部署共享资源的前提部署)。在这种方式中，可以在各种呼叫中心节点中有效使用资源。

图1是根据本发明的一个实施例的分布式呼叫中心系统的方框图。所述系统包括通过数据通信网络11(举例来说，例如广域网)互相连接的各种呼叫中心(CC)站点(还简称为呼叫中心)10a-10c(统称为10)。广域网可以是公用广域网，例如因特网、私人广域网或本领域惯用的任何其他网络，举例来说，例如MPLS(多协议物位交换)网。对于业务或公司来说，每个CC站点10可以是室内设施，以用于通过执行通过企业获得的与产品和服务相关的销售或服务功能为企业服务。在另一方面，CC站点可以是为一个或多个企业提供CC服务的第三方的站点。

根据一个示例性的实施例，每个CC站点都包括通过电话或其他通信机制启用传送服务的资源(例如，人员、计算机、电信设备和类似资源)。这些服务可以根据呼叫中心类型而不同，也可以包括顾客服务(例如，服务热线、紧急响应、订单接收等)、电话推销和类似服务。CC站点可以为单个企业或不同企业提供CC服务。在任一种情况下，根据一个实施例，每个CC站点10在没有中央数据中心的情况下脱离其他CC站点自主运行。在这方面，每个CC站点10维护它自己的代理组17a-17c(统称为17)并维护其他资源，用于处理与被提供呼叫中心服务的企业顾客的交互。虽然由CC站点维护的代理组依赖于代理的偏好，但是在某些情况下，例如根据分支失败或其他原因(例如，根据给代理安排的任务)，代理还可以从一个站点移动到另一个站点。

根据一个实施例，每个CC站点10托管配置有一个或多个CC资源的CC节点15a-15c(统称为15)。CC节点15可以是包括处理器和内存的计算设备，例如，举例来说关于图17A-17E说明的计算设备。CC节点15还可以配置在用于提供媒体连接的硬件和软件上。根据一个实施例，CC节点15通过使用对等(P2P)网络体系结构的广域网互相连接。在这一点上，相互连接的节点15(也称为“对等节点”)与没有这种通过集中服务器的数据和资源的其他相互连接的节点共享数据和资源。根据一个实施例，从另一个节点消耗资源的节点在不同时间可以是给该其他节点提供资源的节点。根据另一个实施例，为另一个节点消耗资源的节点不能和该其他节点共享它本身的资源。

其他分布式网络体系结构可以用来替代P2P网络体系结构。例如，使用客户端-服务器模型的体系结构可以用来替代P2P体系结构，其中客户(节点)被连接到中心服务器(中心控制器)且节点之间互不感知。

根据一个实施例，每个CC节点15在内部测量自己的资源容量并识别这种容量的状态。对于特定的资源，可以识别三种容量状态中的一种：1)额定；2)空闲；3)超负荷。

图2是特定的呼叫中心资源的不同容量状态的概念布局图。容量状态包括空闲状态90、额定状态92和超负荷状态94。当CC节点接收包括用于不同类型交互的请求的请求时，所述请求消耗CC节点内的各种资源。如果特定资源的消耗在预先配置的阈值之内，则资源容量状态被认为是额定状态92。根据一个实施例，额定容量被限定在下阈值96和上阈值98之间。只要特定资源的利用率/消耗在下阈值和上阈值之间，则当前的资源消耗水平就被认为是额定的；因此，资源被认为具有额定容量。

当特定资源的消耗高于上阈值98时，资源容量状态从额定状态转为超负荷状态94。在这点上，CC节点15可以从网络中的其他CC节点请求额外容量。

类似地，当CC节点15由于到该节点的请求很少而变得不活跃时，特定资源的消耗可能会下降到低于下阈值96。在这种情况中，资源的容量状态从额定状态92转为空闲状态90。在这点上，CC节点可以公布其额外容量，以允许已识别出自己处于超负荷状态的CC节点向有空闲容量的节点重新分配请求。

图3是根据本发明的一个实施例的CC节点15的更详细的示意方框图。CC节点包括各种呼叫中心服务器，例如SIP服务器12、路由服务器14、统计服务器16、媒体服务器18、交互服务器20、容量服务器22和类似服务器。根据一个实施例，服务器12-22被实现为部署在CC节点15中的软件部件。虽然不同服务器被描述成单独的功能单元，但本领域的技术人员在不脱离本发明精神的情况下，将会理解各种服务器的功能可以组合或集成到单个服务器中，或者进一步可以被再划分成其他单独的功能单元。

根据一个实施例，CC节点15还拥有大容量存储设备24，所述大容量存储设备可以采用本领域熟知的硬盘或磁盘阵列的形式。根据本发明的一个示例性实施例，例如当CC节点由中央数据中心托管时，大容量存储器设备24存储与代理数据(例如，代理配置文件、计划等)相关的一个或多个数据库、顾客数据(例如，顾客配置文件)、交互数据(例如，每个和顾客交互的细节，包含交互的原因、配置数据、暂停时间、处理时间等)和/或类似数据。根据一个实施例，一些数据(例如，顾客配置文件数据)可以由第三方数据库提供，例如第三方客户关系管理(CRM)数据库。根据后面的实施例，中央数据中心可以被认为是另一个节点/站点，但是具有中央数据中心的功能。举例来说，可以由外部服务提供第三方数据库。第三方数据库还可以被合并入呼叫中心核心功能，作为对那些核心功能的增强。

根据一个实施例，需要从呼叫中心接收服务的顾客、潜在的顾客或其他终端用户(统称为顾客)可以通过他们的终端用户设备(图中未显示)初始化到呼叫中心的入站呼叫。终端用户设备中的每一个都可以是本领域常用的通信设备，例如电话、无线电话、智能电话、个人计算机、电子平板和/或类似设备。操作终端用户设备的用户可以初始化、管理和响应电话呼叫、电子邮件、聊天、文字消息、网页-浏览会话和其他多媒体交互。

到终端用户设备的和从终端用户设备出的入站交互和出站交互可以根据正在使用的设备类型和调用的媒体信道类型穿过电话、移动电话和/或数据通信网络。例如，通信网络可以包括专用或公用交换电话网络(PSTN)34、广域网11和/或类似网络。通信网络14也可以包括无线载波网络，包括码分多址(CDMA)网络、全球移动通信系统(GSM)网络和/或本领域熟知的任何3G或4G网络。

根据一个示例性实施例，呼叫中心包括连接到PSTN网络34的媒体网关28，用以接收和传送终端用户和呼叫中心之间的电话呼叫。媒体网关28可以采用自动呼叫分配器、专用分支交换机(PBX)、基于IP的软件交换机和/或其他任何配置为接收源自因特网的呼叫和/或源自电话网络的呼叫的交换机或网关的形式。根据本发明的一个示例性实施例，媒体网关28连接到SIP(初始会话协议)服务器12，该SIP服务器例如可以作为媒体网关与呼叫中心的路由、监测和其他呼叫处理部件的其余部分之间的适配器或接口。虽然SIP用作服务器12遵循的示例协议，但本领域的技术人员应该理解任何非SIP的其他协议也可以用于处理顾客和呼叫中心之间的电话呼叫。根据一个实施例，各节点中的SIP服务器12通过数据链接彼此连接，以在到达一个节点的呼叫被传送到另一个节点的情况中允许将例如呼叫元数据从一个SIP服务器传送到另一个SIP服务器。

根据一个实施例，除电话交互之外的交互由企业服务器26接收，并转发到交互服务器20进行进一步处理。其他类型的交互可以包括例如电子邮件、语音邮件(通过电子邮件的语音邮件)、聊天、视频、文本消息、网页、共同浏览、社交媒体、网页实时通信(WebRTC)和类似交互。在这点上，企业服务器26可以采用电子邮件服务器、网页服务器和/或类似服务器的形式。根据一个实施例，视频和WebRTC呼叫由SIP服务器12而不是交互服务器20来处理。另外，根据一个实施例，中心交互服务器20为呼叫中心处理各种非电话交互。在其他实施例中还可以部署多个交互服务器。多个交互服务器还允许同时处理各种非电话交互。多个交互服务器还可以用作备份服务器，所述备份服务器在正常操作期间是被动的但当中心交互服务器宕机时则变为主动。这种方式还可以用于CC节点的其他部件，例如路由服务器14。

路由服务器14可以被配置为与SIP服务器12和/或交互服务器20一起工作，用于基于与特定路由点(例如，被叫号码)关联的路由策略将交互路由到呼叫中心目标。根据为路由点配置的路由策略的类型，为交互执行不同的选项、语音处理和路由。

媒体服务器18可以被配置为识别参数(例如，媒体服务器上可获得的媒体端口)以在顾客和呼叫中心目标之间建立语音会话。媒体服务器18还可以被配置为向顾客和/或代理传送媒体。例如，可以调用媒体服务器18以向主叫用户提供初始问候消息，提供交互语音应答(IVR)处理以获得基本顾客信息(例如，识别信息、呼叫原因等)。如果顾客或代理被置于保持状态，则可以调用媒体服务器18向处于保持状态的顾客或代理播放音乐。在另一示例中，如果顾客和代理之间的会话被记录，那么呼叫可以穿过媒体服务器，这样顾客和代理可以和媒体服务器进行三方会话，媒体服务器可以记录会话并将记录的会话存储在数据库中。

统计服务器16可以被配置为搜集、存储、分析和/或传送关于呼叫中心各种资源的数据。这些数据可以包括与代理可用性、平均处理时间、平均保持时间、总谈话时间、工作之外的时间、平均应答速度、服务水平统计、放弃率、忍耐率和类似的相关的数据。可以向订阅客户传送统计数据，例如，向路由服务器14传送代理状态和向报表应用程序传送实时统计。

容量服务器22可以被配置为监测CC站点的各资源的容量，提供容量信息给例如P2P网络的一个或多个其他节点。根据各种资源的容量状态，容量服务器22还可以被配置为如果一个或多个资源超负荷，那么就请求额外容量，或者如果有空闲容量就提供额外容量。容量服务器22可以被配置成保持追踪与其他节点共享的资源，以便可以对资源的使用收费。在这点上，传统的计费和/或记账功能可以被包括在容量服务器中。虽然容量服务器22被描述为功能独立的单元，但本领域的技术人员可以理解其他服务器可以执行容量服务器的功能，所述其他服务器例如为路由服务器14或者可以被配置为控制例如媒体服务器的占用率的另一个资源管理者(未显示)。

CC节点可以包括本领域熟知的其他服务器。例如，CC节点可以包括配置服务器，所述配置服务器用于配置各种服务器和本领域技术人员能领会的呼叫中心其他方面功能。CC节点还可以包括被配置为根据统计服务器16提供的统计数据提供实时报表的一个或多个报表服务器。

根据一个实施例，媒体网关28接收电话呼叫，并调用SIP服务器12做进一步处理。为了将呼叫路由给合适的目标，SIP服务器12调用路由服务器14(例如，通过发送事件消息)以用于检索路由策略。如果呼叫被路由给呼叫中心代理，则路由服务器14识别合适的代理以用于路由呼叫。合适的代理的选择可以基于例如路由服务器14部署的路由策略，进一步还可以基于与代理的可用性、技能和例如统计服务器16提供的其他路由参数有关的信息。

路由服务器14使用呼叫被路由到的代理上的信息向SIP服务器12发信号。在这点上，SIP服务器12传送一个或多个SIP消息，以建立顾客终端设备和代理设备30a-30c(统称为30)之间的连接。在大容量存储设备24中收集的关于主叫者的信息和/或主叫者的历史信息还可以被提供给代理设备以帮助代理更好地为呼叫服务。在这点上，每个代理设备30可以包括适用于常规电话呼叫、VoIP呼叫和类似呼叫的电话。代理设备30还可以包括用于与呼叫中心的一个或多个服务器通信、执行与呼叫中心操作相关联的数据处理和通过语音和其他多媒体通信机制与顾客接口的计算机。

根据一个实施例，如果没有可用的代理来处理呼叫，那么当呼叫被保持时，可以调用媒体服务器18以用于播放不同类型的媒体(例如，音乐)。媒体服务器18还可以被配置为提供表示在代理变为可用于处理呼叫之前顾客不得不等待多长时间的消息。根据一个实施例，如果在当前CC站点处没有可用的代理，那么可以调用其他CC站点处的代理来处理呼叫

根据本发明的一个示例性实施例，路由服务器14被加强了用于管理分配给代理的后台/离线活动的功能。这些活动可以包括例如响应电子邮件、响应信件、致力于训练研讨会或者任何不需要与顾客实时通信的其他活动。一旦分配给代理，则活动就可以被推送给该代理，或者可以在代理的工作框32a-32c(统称为32)中表现为代理要完成的任务。可以通过本领域所熟知的任何数据结构来实现代理的工作框，所述数据结构例如为链表、数组和/或类似数据结构。工作框可以被维护在例如每个代理设备30的缓存中。

图4是根据本发明的一个实施例的在CC节点15之间交换的示例性消息的消息方框图。在图4的视图中，对于容量状态被监测的一个或多个资源来说，当CC节点A 15a达到空闲容量和CC节点B 15b达到超负荷状态时交换消息。各种公知的消息协议中的任何一种都可以用于通过广域网交换消息。

在常规操作期间，来自不同外部资源(例如，顾客)50的请求(例如，电话呼叫、电子邮件和其他交互)在活动100中由相应节点15a、15b、15c接收。在通常的多站点呼叫中心环境中，顾客通常不能挑选呼叫最初发往的特定站点。但是中心逻辑，例如SCP(服务控制点)判定转发呼叫到哪个站点。

在活动102中，CC节点A 15a检测一个或多个资源的空闲容量，在活动104和105中，CC节点A 15a向CC节点B和C 15b、15c发送空闲容量消息。空闲容量消息可以识别例如CC节点A 15a可以提供的空闲容量的类型。例如，如果节点A 15a具有空闲代理，则与空闲代理关联的特定类型的技能可以随同空闲容量消息提供。

在活动108中，CC节点B 15b接收另一个呼叫中心请求，在活动110中，CC节点B检测到处理新请求所需的资源处于超负荷状态。在活动112中，假定CC节点A 15a已经发信号说明该节点具有空闲容量，CC节点B 15b传送对容量的请求。对容量的请求可以识别例如所请求的容量的类型。例如，如果请求的容量是用于具有特定类型技能的代理，那么请求的技能在请求消息中被识别出来。假设CC节点A 15a仍具有空闲容量，那么该节点在活动114中提供OK信号，并且在活动116中，CC节点B重新将CC请求路由到CC节点A 15a以进行处理。语音呼叫的重路由例如可以在用于相互交换SIP消息的两个节点中调用SIP服务器。根据一个实施例，服务器类型的空闲的这种“借用”可以调用CC节点A以连接到CC节点B的资源。例如，在一个实施例中，CC节点A执行CC节点B的路由策略和/或计算对CC节点B的统计。

根据一个实施例，CC节点A和/或CC节点B处的容量服务器可以被配置有逻辑，以保持追踪由CC节点B从CC节点A借用的资源量，然后对CC节点B使用这种资源编制账单。

当超负荷的CC节点向其他节点重新分配请求时，所述节点最后会落回到额定容量状态，所述节点在所述额定容量状态下释放借用的资源。根据一个实施例，资源的借用和/或释放可以是基于合约的。例如，CC节点可以在一定时间段内借用资源并为这些资源付费，而不用考虑资源的实际使用，并且当所述时间段期满时，借用的资源被自动释放。

根据一个实施例，特定请求的重路由或转移使用与其相关联的标准协议。例如，对于IVR和语音呼叫交互，可以采用SIP转移机制从一个CC节点将交互转移到另一个节点。例如，转移可以通过REFER或re-INVITE SIP消息完成。另外，每个CC节点可以包括适当配置的边缘设备，以在呼叫中心站点之间启动语音业务的成功转移。这样的边缘设备可以是例如传统的会话边界控制器。其他交互，例如电子邮件和社交活动，可以使用诸如HTTP/REST、IMAP、POP3、SMTP、XMPP的协议或者本领域所熟知的任何其他协议，以在节点之间发送与这种交互关联的请求。

根据一个实施例，从一个CC节点到另一个CC节点的请求的转移或重路由包括转移与交互相关的数据。这些数据可以是例如关于顾客的数据和关于顾客过去交互的信息，所述数据和所述信息可以被保持在特定CC节点托管的大容量存储设备24中。数据转移可能需要使用带有HTTP请求的JSON(JavaScript对象表示法)。在一个实施例中，可以通过数据库复制在节点之间共享数据。根据一个实施例，Cassandra数据节点用于存储和共享数据。根据一个实施例，专用协议，举例来说，例如Genesys ISCC(Inter-S i te Ca l l Contro)还可以用于在SIP服务器之间直接转移数据。

图5是对于特定资源，CC节点B 15b从超负荷状态转到额定状态时CC节点15间交换的示例性消息的消息框图。当CC节点B 15b仍处于超负荷状态时，所述节点在活动200中接收CC请求。在活动202中，CC节点B 15b通过传送例如SIP REFER或re-INVITE消息将请求重新路由到CC节点A 15a。

在活动204中，CC节点B 15b检测超负荷的CC资源的额定状态，并且在活动206中，CC节点B向CC节点A 15a传送消息，以释放CC节点A使用的用来处理来自CC节点B的重路由请求的资源。

在活动208中，如果有的话，则CC节点A 15a完成当前来自CC节点B的请求的处理。

在活动210和213中，CC节点B 15b通知其资源的额定容量状态的其他节点15a、15b。

在活动216中，CC节点B 15b接收新的CC请求。假定CC节点B相对于用于处理新请求的资源来说仍然具有其额定容量，那么在活动218中，CC节点B在其额定容量下使用该资源处理请求。

参考CC节点A 15a提供其空闲容量处理超负荷CC节点B 15b转发的请求的情况，CC节点A除了接收CC节点B转发的请求外还继续接收它自己的CC请求。根据一个实施例，如果CC节点15a自己的需求消耗它已经共享的空闲容量，则所述节点就收回其资源。根据一个实施例，回收会需要通过使用资源的当前CC节点来批准。

图6是根据本发明一个实施例的当CC节点A 15a收回它已经共享给CC节点B 15b的空闲容量时CC节点间交换的示例性消息的消息框图。

在活动250和252中，超负荷的CC节点B 15b接收CC请求，将请求重路由到具有空闲容量的CC节点A 15a。

在活动254中，CC节点A 15a从外部资源50中的一个接收新的CC请求。

在活动256中，CC节点A 15a检测到它从空闲容量状态转为额定容量状态，并且在活动258中向CC节点B传送消息以收回共享的容量。根据一个实施例，如果正在监测的资源的消耗高于下阈值96(图2)，那么CC节点A可以从空闲容量状态转为额定状态。

在活动260中，CC节点B向CC节点A传回确认，阻止向CC节点A传送新的交互/请求。如果CC节点B仍然在超负荷状态下工作，那么CC节点B可以试图寻求其他具有空闲容量的对等节点，新请求可以重路由给这些节点。根据一个实施例，如果CC节点A按约定继续提供它的资源，则如果它的容量状态由额定转为超负荷，那么CC节点A可以尝试寻找其他具有空闲容量的对等节点。这可以通过发送类似于关于图4所讨论的消息的消息来实现，而不是由已表明具有空闲容量的一个或多个节点完成。如果没有其他这样的节点可用，则CC节点B(或节点A)可以根据各种标准机制中的一种处理新请求，标准机制包括例如将请求放在保持状态直到容量变得可用为止，从而将请求重新路由到不在超负荷状态下工作的CC节点B中的二级资源，和/或类似情况。在后一个示例中，如果特定资源(例如，具有特定技能级别的代理)被识别为处理外部请求的优先资源，而优先资源处于超负荷状态，那么CC节点B可以配置成扩展资源池，以便包括技能级别低(例如，技能级别3)的代理，直到特定资源转回到它的额定容量为止。

在活动262中，收回其空闲容量的CC节点A完成由CC节点B 15b对当前请求的处理，但是拒绝新的请求。

随着网络增长，向所有节点发布容量消息和其他事件可能不是最优的。根据一个实施例，在P2P网络中，代替所有节点都向所有其他节点发布事件，指定一个或多个节点为主节点。除了用作普通CC节点外，主节点可以具有向P2P网络中的其他参与节点分配空闲容量和超负荷容量消息的额外责任。根据网络的规模，可以指定多个主节点。这样，执行消息分配任务时单个节点不会超负荷。

根据一个实施例，为了分发消息，可以为主节点配置另外的智能。所述另外的智能可以包括例如预测逻辑，所述预测逻辑用于根据从各节点接收的历史事件预测消耗模式。例如，经常从额定容量状态变为空闲容量状态的节点可以不是被再分配请求的理想节点。另外，向对等节点提供空闲媒体资源前，主节点可以被配置为计算节点之间额外的网络带宽消耗和潜在的语音质量恶化程度。主节点还可以具有从具有空闲容量的节点中根据节点其他属性进行选择的智能，其他属性例如是与具有超负荷容量的节点的地理位置有关的节点的地理位置。例如，对具有超负荷容量的节点来说，本地的具有空闲容量的节点可以优于另一个地理位置距离更远的具有空闲容量的节点。在另一个示例中，在具有超负荷容量的各种节点以及具有空闲容量的有限数量的节点的情况下，与具有空闲容量的节点有关的超负荷节点(例如，两个节点都是同一企业的一部分，加入同一数据中心，等等)可以在与具有空闲容量的节点没有特定关系的超负荷节点(例如，与不同的企业关联的节点)之前得到服务。

图7是根据本发明一个实施例的包括主节点15d的分布式呼叫中心系统的示意性方框图。在图7的示意性实施例中，当CC节点A检测到空闲容量时，所述节点将空闲容量消息300发信号给主节点15d。主节点15d还从其他节点接收通知302，例如CC节点B 15b。在这个示例中，来自CC节点B的消息表明超负荷容量。消息被CC主节点15d解释为对额外容量的请求。在一个实施例中，来自CC节点B的消息包括对额外容量的明确请求。

主节点15d通过消息304向具有空闲容量的节点(例如，CC节点A 15a)转发对额外容量的请求。根据一个实施例，至具有空闲容量的节点的消息304包括请求空闲容量的节点的标识，例如CC节点B。然后CC节点A直接和CC节点B通信(或通过主节点间接通信)，以传送表明其将向CC节点B提供额外容量的消息306。作为所述消息的响应，CC节点B通过(多个)消息308重新将请求路由给CC节点A，就像上面关于图4讨论的那样。

根据一个实施例，任何具有足够CPU、内存和网络带宽的CC节点都可以是成为主节点的候选。在一个实施例中，主节点的选择是随机的或半随机的，并且可以考虑或可以不考虑CPU、内存和网络带宽因素。主节点还可以根据其他因素指定，举例来说，例如地理上的考虑。例如，可以指定在美国中部的CC节点为主节点，以处理美国内的对等节点的消息分发任务。可以指定在欧洲中部的CC节点为另一个主节点，以用于处理欧洲内的对等节点的消息分发任务。随着对等节点网络的增长，可以分配或重新分配主节点。

根据一个实施例，当CC节点加入P2P网络时，CC节点的配置设置识别主节点的IP地址，CC节点通过所述IP地址与主节点通信。在另一个实施例中，加入P2P网络的CC节点可以首先连接到注册服务器(未显示)以接收主节点的IP地址。

根据一个实施例，容量监测和发消息的职责由CC节点15中包括的容量服务器22(图2)处理。如果CC节点还是主节点，则可以为容量服务器22配置额外的逻辑，用来根据例如预测结果和负载平衡因素来识别容量请求要被转发到哪些节点。

根据一个实施例，容量服务器22被配置成监测可用于和其他节点共享的一组资源。在一个示例中，被监测和共享的资源包括呼叫中心工作成员(例如，代理)和媒体资源(例如，用于IVR交互)。当然，本领域技术人员所理解的CC节点的其他资源也可以被监测和共享，举例来说，例如自动回应(例如，自动回应进来的电子邮件)的计算能力、报表资源(例如，报表服务器)和类似的。

容量服务器22可以被配置成监测任何粒度级别上的资源，举例说根据CC节点配置设置确定的粒度级别。例如，容量服务器22可以被编程以根据代理技能集合(例如，语言、产品规格、业务范围)、地理位置和类似因素来监测代理资源。可以相对静态的资源信息，例如与代理相关的信息，可以使用本领域熟知的缓存机制被CC节点(或者至少是主节点)共享。另外，在多个呼叫中心共享例如云环境中的资源的多租户环境中，资源的监测可以基于逐个租户的。

关于可以共享给其他CC节点的媒体资源，根据一个实施例，这样的媒体资源被绑定到媒体服务器18。可以调用媒体服务器18处理使用IVR的请求。根据一个实施例，媒体服务器18提供对IVR的音频提示。还可以为其他能力调用媒体服务器18，举例来说，例如管理会议呼叫、提供呼叫记录、播放暂停音乐和其他能力。

当提供媒体服务时，媒体服务器18的媒体端口被消耗。为了确定媒体端口的容量状态，并因此确定媒体服务器18的容量，容量服务器22可以被配置成监测例如在请求首先被路由到IVR的实施例中该请求的进入速率。还可以计算在IVR中的平均时间。根据一个实施例，如果监测的请求的进入速率和/或在IVR中的平均时间超过预测的进入速率和/或时间一定的量，则容量服务器可以被配置成推断出媒体资源处于超负荷状态。另一方面，如果监测的请求的进入速率和/或在IVR中的平均时间低于预测的进入速率和/或时间一定的量，则容量服务器可以推断出媒体资源处于空闲状态。如果监测的请求的进入速率和/或在IVR中的平均时间在特定的上边界和下边界内等于预测的进入速率和/或时间，则媒体资源可以被认为处于额定状态。

CPU功率还被媒体服务器18在提供媒体服务时消耗。根据一个实施例，节点可以具有多个CPU，每个CPU专用于一个或多个服务。例如，媒体服务器18可以具有它自己专用的CPU。CPU功率的消耗可以被监测和与CPU消耗的期望量进行比较，以用来判定CPU功率是额定、空闲或超负荷的。在具有空闲CPU功率的情况下，超出部分可以共享给其他已经表明它们自己的CPU功率超负荷使用的进行同一类型服务的节点。

根据一个实施例，由于执行响应于进入请求的自动处理，举例来说，例如回应进入的电子邮件自动传送回复的电子邮件，也可以消耗CPU功率。在一个节点具有空闲CPU功率的情况下，这种空闲CPU功率会变得对超负荷使用CPU的节点来说可以使用。例如，要求自动处理的请求可以被自动转发到具有空闲CPU功率的节点，以由该节点进行处理。在另一个实施例中，具有超负荷CPU功率的节点可以实例化为它自己的服务器中的一个用于在具有空闲CPU功率的节点上执行自动处理。

对于代理，容量服务器可以被配置成监测登录的代理的数量和它们的使用情况。使用情况可以基于进入请求的数量、包括所需服务时间和/或其他Erlang度量的通信负载、和使用的或将要使用的为请求服务的代理的数量。例如，根据在特定预测时间段期间预测有10个传入呼叫，呼叫中心可以确定要使用10个代理来处理呼叫，因此为呼叫中心配备10个代理。只要在预测的时间段中呼叫中心经受的呼叫量在10左右(例如，在7个呼叫与10个呼叫之间)，容量服务器22就可以判定代理资源的使用是额定的。然而，在预测的时间段期间，如果呼叫量跌落到低于特定数值，举例来说，例如7以下，则容量服务器22可以判定具有超额的代理容量。在预测的时间段期间，如果呼叫量增长超过特定数值，举例来说，例如高于13，则容量服务器22可以判定具有超负荷的代理容量。根据这个示例，如果对于预测时间段实际的呼叫量是5，则容量服务器22可以判定2个代理可用于共享。在另一个实施例中，容量服务器22可以判定不再忙于处理呼叫的所有5个代理都可以用来共享。

容量服务器22可以被配置成考虑影响代理使用的其他因素，举例来说，例如请求路由到哪里(基于路由策略)、与可用代理的技能相比为了进入的请求需要什么技能、以及代理忙于呼叫的时间比例和类似因素。例如，如果需要技能集X的呼叫的当前呼叫量是五，而且当前有五个处于空闲不在处理呼叫的代理，那么如果五个代理都没有技能集X来处理呼叫，则对于具有技能集X的代理来说，容量服务器仍然可以判定节点处于超负荷容量下。同样的规则也可以适用于与入站呼叫有关的需要在特定地理位置的代理的呼叫。本领域技术人员能够理解，监测代理资源的粒度越细(例如，技能的因子分解(factoring))，越好共享合适的代理资源。

根据一个实施例，容量服务器22可以被配置有用于预测不同呼叫中心量度的一个或多个预测模型。预测也可以由其他服务器或系统完成，举例来说，例如职工管理系统。根据一个实施例，预测模型还可以用于预测期望的交互量、代理占有率、放弃率、平均保持时间、和/或本领域技术人员所掌握的其他呼叫中心量度。预测信息可以用于判定一个或多个呼叫中心资源的容量状态，和/或用于预测什么时候特定资源的容量可以从一个容量状态转换为另一个容量状态。例如，职工管理工具可以提供趋势信息、预测潜在的请求增长(例如，因为假日季节而增长的请求)。计划信息也可以被包括在预测中。例如，知道具有特定技能的其他代理被规划在下一个变换开始时启动，也会影响容量状态。

本领域的技术人员能够理解，预测模型可以基于历史趋势、统计分析、排队系统理论和类似因素，并且可以使用公知的算法，举例来说，例如Erlang A、B或C公式。

作为一个示例，预测可以包括为特定预测时段做出与交互量、超负荷和人员配备相关的预测。还可以根据例如期望的交互量做出关于特定资源的使用的预测。例如，可以根据预测的到呼叫中心的流量预测代理和/或媒体资源的占用率。

可以根据参数预测，例如根据每天的特定时间段、一周的特定天、事件、假日和类似因素。举例来说，促销或营销活动这样的事件可能导致可预测的交互量的峰值。其他事件可能导致可用资源的缩减。例如，预测模型可以预测出在超级杯那天呼叫会出问题的代理的特定数量。

在一个具体的示例中，如果在2013年4月18日上午9:00到9:15之间参与进来的有1000个呼叫，那么在这个时间段预测的交互量是1000。计算出来的处理1000个呼叫需要的预测的人员配备可以是例如100个代理。然而，如果预测10％的代理不能用于处理呼叫，那么预测的人员配置需求可以是111个代理，而不是100个。预测不能用的10％的代理可能是由于代理休假、呼叫失败、或者从事其他不能被认为是积极工作的例外情况，举例来说，例如培训、会议、中间休息、用餐和其他非工作状态，从而导致可以工作的代理的实际数量缩减。

在另外一个示例中，预测模型可以表明在每天特定时间段、一周的特定天、假期期间、响应具体事件和类似时刻，进入的呼叫增加或减少。例如，入站请求在周一上午11:00到下午2:00期间可以翻倍。这些信息可以用于例如决定空闲容量是否可以被另一个节点共享。例如，虽然在上午11:00之前CC节点可以以空闲容量操作，但预计到上午11点增长的请求，CC节点不能在上午10:30之后让这些容量对其他节点可用。

设置多站点呼叫中心的网络通常是复杂且耗时的，而且可能需要所有站点集成在一起这种方式。为了简化站点(或节点)的设置和配置，可以使用联盟模型，其中P2P网络被认为是代表联盟且CC节点被认为是联盟成员。

根据一个实施例，可以配置注册节点来处理每一个加入到网络中的对等节点的发现和认证。CC节点15中的任一个可以被指定为注册节点。例如，注册节点可以是运行在指定CC节点15、主节点15d或独立节点上的额外进程。根据一个实施例，注册节点可以与SIP注册节点相似，但也可以包括SIP注册节点没有提供的额外容量。

图8A是根据本发明一个实施例的在CC节点15a、15b和注册节点15e之间交换的示例性消息的消息图。在这个示例中，假定CC节点B 15b已经是联盟/P2P网络的一部分，而且通过注册节点15e注册。

在活动450中，需要加入P2P网络的CC节点A 15a传送用于通过注册节点15e注册的注册请求。根据一个实施例，注册节点15e可以通过HTTP协议访问各个CC节点。根据一个实施例，在每个节点中都配置有注册节点15e的地址，举例来说，例如在每个节点的配置设置中。还可以根据域名系统(DNS)发现能力获得注册节点15e的地址。

在活动452中，注册节点初始因为缺少授权拒绝了请求，并从CC节点A 15a请求认证。

在活动454中，CC节点A 15a通过适当的认证数据重新发送注册请求，并且注册节点15e根据认证数据继续对CC节点A进行认证。所述认证可以使用本领域人员所熟知的各种常用的授权机制进行，例如，包括基于凭据和证书的认证。本领域常用的OAuth协议也可以用于认证。

其他已经注册在联盟中的节点将被通告给新的对等节点。例如，在活动456中，消息可以随着在新的对等节点A上的信息被传送到CC节点B 15b。

在活动458中，注册节点15e接收新节点，并向所述节点发送联盟中的其他节点的地图。根据一个实施例，地图包括联盟中的一列注册节点和每个对等节点的IP地址。根据一个实施例，一旦被认证，节点A就是受信站点，并且可以与地图中的其他对等节点直接通信而不用重新认证。在这点上，当与对等节点通信时，可以向要使用的受信站点发布证书。

根据一个实施例，有一个对等节点不希望联盟接受新节点的情况。这可以发生在例如跨企业使用的情况中。

图8B是根据本发明一个实施例的用于通过OAuth协议认证客户(请求节点)以使用另一个节点(资源拥有者)拥有的资源服务器中的资源的消息图。在这点上，客户请求授权服务器授权使用资源拥有者的资源。授权服务器转发请求到资源拥有者并从资源拥有者接收同意信息。授权服务器向客户传送消息，从而通知它获得对资源的访问。客户和授权服务器然后交换消息以向客户提供访问令牌。从资源拥有者对资源的进一步请求和访问令牌一起被传送给资源服务器，如果验证完成，资源服务器就会提供所请求的资源。

图9是根据本发明一个实施例的在CC节点15a、15b、15x和注册节点15e之间交换的示例性消息的消息图，其中CC节点中的一个拒绝CC节点X 15x访问联盟。在这个示例中，假定CC节点A和B 15a、15b已经是联盟/P2P网络的一部分，并且通过注册节点15e注册。

在活动460中，期望加入P2P网络的CC节点X 15x传送注册请求。在活动462中，CC节点X 15x传送它的认证数据，在活动464中，CC节点X通过注册节点15e认证。

在活动466中，注册节点15e通知CC节点A 15a有个新的对等节点X，在活动468中CC节点A通过OK消息接受新的对等节点。

在活动470中，注册节点15e还通知CC节点B 15b有新的对等节点X，但在活动472中，节点B咨询受信站点后决定不接受新的对等节点。CC节点B不接受新节点的原因多种多样。例如，CC节点X可以与不同的企业相关联，或者可以位于不同的地理位置。

根据一个实施例，注册节点15e在联盟中接受新对等节点，这是因为联盟中的至少一个站点已经接受了所述新对等节点。然而，如果所有预注册节点都阻止新的对等节点，那么注册节点15e会拒绝注册请求。

在活动476中，注册节点然后保持追踪哪个节点已经同意参加联盟，并向CC节点X发送适当的地图。例如，CC节点X接收列有CC节点A和X、而没有CC节点B的地图。另一方面，CC节点B 15b接收列有CC节点A和B、而没有CC节点X的地图。

图10是根据本发明一个实施例的用于监测和判定特定资源的容量或资源类型(统称为“资源”)的进程的流程图。所述进程可以用软件例程来说明，软件例程根据存储在内存中的指令由微处理器执行。所述指令也可以存储在其他非易失性计算机可读介质中，例如CD-ROM、闪存驱动器或类似介质。本领域的技术人员还应该了解到所述例程可以通过硬件、固件(例如，通过ASIC)、或者软件、固件和/或硬件的任何组合来执行。此外，进程步骤的顺序不是固定的，但可以修改为任何本领域的技术人员能理解的期望顺序。

所述进程启动，并且在活动400中，容量服务器22监测标准，以用于判定是否要检查当前容量。举例来说，所述标准可以是设定的时间、经过一个时间段、用户调用的命令和/或类似标准。

一旦作出应该检查容量的判定，则在活动402中，容量服务器22计算或检测资源的当前消耗或使用情况。在这点上，如果代理资源要受到监测，那么容量服务器22与例如统计服务器16通信，以用于识别代理的占用率。占用信息可以像表明代理正在忙那样简单，或者也可以复杂到表明代理当前参与的特定类型活动(例如，入站语音、对外活动、电子邮件、聊天、后台工作、培训等)、活动利用的通信媒介(例如，语音、文本、电子邮件等)、在活动中代理参与时长和类似活动。容量服务器22还可以度量当前呼叫中心量度，举例来说，例如当前交互量。

在另一个示例中，如果要监测的资源是媒体服务器18上的媒体端口，那么容量服务器22可以确定当前正在使用的媒体端口的数量，而且根据一个实施例，还可以确定每个端口已经使用的时间量、当前交互量和类似量。在另一个示例中，如果要监测的资源是CPU使用率，则容量服务器22可以确定CPU消耗水平以及识别在给定时间每一个服务器12-22正在处理的请求的数量。

在活动404中，容量服务器22判定资源的容量状态是否是额定状态。在这点上，容量服务器22将预测的呼叫中心量度和/或计划的资源与在活动402中获得的当前量度进行比较。例如，如果当前交互量介于预测的交互量的下阈值96和上阈值98之间，和/或当前代理占用率介于预测的代理占用率的下阈值和上阈值之间，那么对于代理资源来说，呼叫中心可以被认为处于额定容量状态。在更多的具体示例中，如果预测的是以特定的时间间隔希望有40个到44个之间的呼叫需要被路由给代理，并且只检测到有42个呼叫，那么代理资源可以被认为具有额定容量。另外或代替度量交互量，如果预测代理占用率将在89％和97％之间，而且当前占用率是95％，那么代理资源可以被认为具有额定容量。

对于媒体服务器资源来说，如果在特定时间间隔期间，预测80％-90％的媒体端口会被使用，而且媒体端口的当前消耗是85％，那么媒体服务器可以被认为在额定容量下工作。

如果资源处在额定容量，那么在活动406中，容量服务器22设置资源的容量状态为额定容量状态。这种状态数据可以和资源的标识一起被保持在例如CC节点的内存中。

在活动408中，容量服务器22通过广域网11向一个或多个其他对等节点15传送额定容量消息。

再次参考活动404，如果容量服务器22判定资源的容量状态不是额定状态，那么在活动410中判定资源的容量状态是否是空闲容量。根据一个实施例，如果如活动402中计算的当前消耗低于下阈值96，那么资源的容量状态可以被认为处于空闲容量状态。在这种情况中，在活动412中，容量服务器22设置资源的容量状态处于空闲容量状态。

即使容量服务器22已经判定存在空闲容量，也还有很多原因使得它不愿意在此时间间隔同其他节点共享空闲容量。例如，预测模型可以表明虽然在当前时间间隔具有空闲容量，但预测到在下个时间间隔预计没有可用的这种空闲容量。这可以发生在例如在当前时间间隔期间一定数量的可用代理在下个时间间隔被安排休息或者在下个时间间隔预测到增加数量的交互的情况中。因此，在活动414中，容量服务器判定空闲资源是否被共享。

如果答案为是，那么在活动416中，容量服务器22通过广域网11向一个或多个其他对等节点15传送空闲容量消息。根据一个实施例，被报告为空闲的资源不包括根据合约已经从另一个节点借用的容量。在其他实施例中，被报告为空闲的资源可以包括根据合约借用的容量。然而，因为收回借用的空闲容量可能不容易，所以只要提供给其他节点使用，提供超额容量的节点可能需要从其他地方寻求空闲资源。

再次参考活动410，如果容量服务器22判定资源的容量状态不是容量空闲状态，那么资源处于超负荷容量状态，其中资源的当前消耗高于上阈值98。因此，在活动418中，容量服务器22继续把容量状态设置为处于超负荷状态。

在活动420中，容量服务器22通过广域网11向一个或多个对等节点15传送超负荷容量消息。超负荷容量消息的传送还可以是有条件的。例如，如果借用的节点要为借用的资源付费，但是又没有为这些资源支付的预算，那么可以决定在找到支付资金之前不发送超负荷容量消息。

除了前边讨论过的、每个CC站点都自主应对其他CC站点的部署模型外，还有一些其他部署模型可能会受益于前文讨论过的P2P机制。这样的其他部署模型包括企业部署、跨企业部署和云部署。

图11是根据本发明的一个实施例的在企业部署中的分布式呼叫中心系统的方框图。在所示的实施例中，所述部署用于单个/同一企业。在这方面，数据中心由特定的企业托管以用于在为企业提供呼叫中心服务时提供大量的处理。然而，本领域的技术人员会理解部署也可以和多个企业相关联。根据图11的实施例，呼叫中心系统包括具有几个分支CC站点10d、10e的数据中心500。根据一个实施例，大多数的代理17d登录到数据中心500，而其他代理17e、17d登录到分支CC站点10d、10e，这经常是根据代理的地理位置进行的。数据中心还托管提供大量计算资源和数据库的一个或多个CC中心节点502。

每个分支CC站点10d、10e通过广域数据通信网络11连接到数据中心，并且除本地代理资源外还包括其他本地资源，举例来说，例如本地媒体资源、网络服务器和类似资源。这些其他的本地资源通过分支CC节点15f、15g提供。

根据一个实施例，数据中心500的CC中心节点502提供集中服务。例如，IVR服务可以被集中提供给所有交互，并随后路由到可用的代理。根据一个实施例，语音网络可以部署为使语音业务总是到达数据中心500。根据另一个实施例，路由策略可以建立在各个CC节点15f、15g上，以推送交互到数据中心500进行集中处理(例如，通过IVR)。

为了实现P2P机制，可能需要在数据中心处强制实施集中处理。例如，集中的IVR服务可以在数据中心500处提供，直至数据中心的IVR资源处于超负荷容量为止。在这个情况中，可以调用分支CC节点15f、15g提供的本地IVR资源以和数据中心500共享它的IVR资源。根据一个实施例，和数据中心500共享的本地IVR资源被配置为当客户在数据中心500处和IVR进行交互时给客户提供基本上相同的IVR经验。例如，在提供本地IVR服务时，本地媒体服务器检索和播放相同或相似的音频提示。

根据一个实施例，即使在分支CC节点15f、15g和数据中心500之间丢失通信，图11中的企业部署也能够提供用于分支CC站点10d、10e的本地易存活性。当分支CC站点10d、10e在本地存活模式下工作时，尽管到数据中心500的连接丢失，但仍然能够提供呼叫中心服务。本地存活可以有不同的原因：1)分支CC站点10d、10e和数据中心500之间的连接丢失，但这两个分支站点和数据中心是可以运营的；2)服务因为数据中心500不能工作而丢失；和3)部分连接或服务丢失(例如，只能用于语音，而不能用于电子邮件)。

根据一个实施例，当处于本地存活模式时，来自顾客的交互仍可以被接受并被路由到呼叫中心中的代理。与呼叫中心的代理的文本消息、电子邮件和聊天会话仍然是可以的。在一些实施例中，在本地存活期间，呼叫中心服务的质量或类型可以减少。例如，当到数据中心的连接丢失或数据中心不服务时，代理可能不能访问保持在数据中心500中的交互历史。

图12A-12B是根据本发明的一个实施例的在分支CC节点15f、15g和数据中心500之间交换的用于启用本地可存活性的示例性消息的消息图。

在常规操作期间，在活动510中，CC节点F 15f接收来自不同外部资源506的请求，包括交互请求，并且在活动512中转发这些请求到数据中心500进行处理。例如，所述请求可以是到达媒体网关28的电话交互请求。响应于接收请求，可以调用SIP服务器12以判定将请求转发给与数据中心500关联的IP地址以用于从数据中心接收集中服务。虽然为了简化将请求描述为正在被转发的请求，但本领域的技术人员应该理解请求的转发可能需要根据原始请求生成新的请求。

根据一个实施例，请求被转发到的IP地址可以例如是由CC中央节点502托管的SIP服务器和/或媒体服务器的IP地址。IP地址的识别例如可以通过路由服务器14响应于执行路由策略路由请求。例如，路由策略可以指明通过提供IVR处理首先处理所有电话交互。根据一个实施例，如果到数据中心的连接正常工作，则路由服务器24可以被配置成识别由CC中央节点托管的SIP服务器和/或媒体服务器的IP地址。路由服务器还可以通过名称识别CC中央节点，并且可以调用映射程序识别实际的IP地址。

在活动512中，CC节点F 15f将请求转发给数据中心500。这可以包括在CC节点F 15f和CC中央节点502之间交换SIP消息。SIP消息可以通过请求例如识别所请求的服务类型(例如，具体的媒体服务)。进一步地，可以在外部请求的发送者和数据中心处的资源之间建立语音连接(例如，使用RTP协议)。例如，如果数据中心要提供的服务是IVR处理，那么就在发送者的终端设备和由CC中央节点502托管的媒体服务器18上的端口之间建立语音连接。当然，数据中心也可以提供其他服务，举例来说，例如播放音乐、呼叫会议、呼叫记录和类似服务。数据中心可以提供的非语音服务可以包括对电子邮件、聊天、文本等的自动回应。数据中心还可以接收与配置更新、报表生成等有关的请求。

根据一个实施例，在提供集中服务时检索在由数据中心托管的大容量存储设备24中集中维护的数据。这些数据可以包括例如包括与顾客过去交互有关的数据的顾客数据。

在活动514、518和528中，CC节点F 15f继续检查是否可达到数据中心500，就像活动516中CC节点G所做的那样。可以使用本领域人员所理解的各种公知的机制中的任一种进行该判定，举例来说，例如Ping、SIP消息、HTTP、内部服务器连接控制和类似机制。本领域的技术人员应该理解，数据中心的有效性的检查可以与请求的接收和转发分开。例如，节点可以周期性地查验数据中心，以用于检查与数据中心的通信是否畅通。查验的频率可以根据需要智能调节。

如果在活动520中连接检查超时，而且数据中心500在设置的时段内没有返回响应，那么CC节点F 15f在活动522中转为本地存活模式并进一步在本地处理请求。缺少数据服务中心500的响应可能是因为数据中心全部或部分宕机(例如，一种媒体类型可以，而另一种不可以)。可选地，到CC节点F的连接可以全部或部分断掉(例如，一种媒体类型可以，而另一种不可以)。如果数据中心宕机，那么CC节点G 15g也会转为本地存活模式。如果只是到CC节点F的连接断了，那么CC节点G不能转为本地存活模式，除非它自己的连接断了。

根据一个实施例，CC节点F 15f转换为本地存活模式可以包括设置标识的容量服务器22，该标识指明它现在处于本地存活模式。另外，容量服务器还可以被配置成唤醒沉睡(备份)的可存活资源，举例来说，例如备用的交互服务器。

在活动524中，CC节点F从外部资源506接收CC请求。CC请求通常是要被转发到数据中心500的。在活动524中，响应于请求，SIP服务器12或路由服务器14判定本地存活模式标识是否已经设置。响应于正在设置的标识，SIP服务器阻止向数据中心500处的CC中心节点502转发请求。相反，在活动526中，CC节点F 15f在本地处理请求。在这点上，CC节点F处的SIP服务器可以将请求转发到被CC节点F 15托管的本地媒体服务器，以提供例如对请求的IVR处理、呼叫记录和/或类似操作。根据一个实施例，根据设置本地存活模式标识，路由服务器14可以识别本地媒体服务器的IP地址。识别出本地媒体服务器的IP地址来代替被CC中心节点托管的SIP服务器和/或媒体服务器的IP地址。根据一个实施例，当CC节点F处于本地存活模式时，所述节点可以与其他对等节点交换资源容量，举例来说，例如CC节点G 15g。在一个节点具有空闲容量而另一个节点需要额外容量的情况，CC节点F和CC节点G可以互相共享资源。

一旦数据中心连接恢复，如图12B的实施例中所述，则数据中心500在活动528中及时响应消息以检查连接。在活动530中，CC节点F 15f转换为常规模式。这可能需要例如不设置本地存活模式标识，让被唤醒的备用资源重回备用模式。在活动534中，CC节点F 15f将在活动532中接收的外部请求转发到数据中心500以用于由数据中心进行处理。

根据另一个实施例，与数据中心500中的CC中心节点502的通信丢失时，通过指定分支CC节点15f、15g作为用于数据中心操作的备用系统，才可能实现本地存活。根据本实施例，在常规操作期间，代理登录到CC中心节点502的SIP服务器12。分支CC节点15f、15g一直空闲，直到使数据中心500不能使用的事情发生为止。当这样的事情发生时，代理登录到指定的分支节点，无论是CC节点F 15f或CC节点G 15g都是如此。

根据一个实施例，通过安装在各自代理设备30中的应用程序(例如，桌面应用程序)，可以将通知发送给登录到数据中心的代理17d(图3)。例如，桌面应用程序可以被配置为向CC中心节点502传送心跳消息。在预先设置的超时时段内响应于没有心跳消息的应答，桌面应用程序可以被配置成在代理显示设备上显示消息，以通知代理缺少应答。该消息还可以进一步提示代理手动登录到分支CC节点15f或15g中的一个处的SIP服务器12。根据一个实施例，桌面应用程序可以被配置成在代理被指定到的分支CC节点(次级节点)上检索数据，以及提示代理登录到特定的分支CC节点。与代理相关联的次级节点上的数据可以从例如代理的配置文件记录中检索。

根据一个实施例，到代理的消息可以是呼叫在指定的次级节点上的IVR应用程序的消息，以便将代理重新登录到次级节点。IVR应用程序可以被配置成在重登录过程中播放提示来引导代理。IVR应用程序捕获的数据接着可以被提供给在次级节点上的SIP服务器以完成重新登录的过程。

可选地，响应于检测到与CC中心节点502(主节点)的通信丢失，桌面应用程序可以被配置成自动将代理重登录到指定的次级节点。根据一个实施例，代理维护他或她用于到达代理的电话号码。

根据一个实施例，在广域网11和数据中心500和/或其他网络元件的边界处的会话边界控制器(未显示)还可以被配置为监测与CC中心节点502的连接。响应于检测到通信丢失，会话边界控制器(也可以称为边缘设备)可以被配置为自动将到CC中心节点502的入站电话通信转发到适当的CC分支节点15f、15g。识别恰当的CC分支节点15f、15g以向其转发入站电话通信可以根据例如在会话边界控制器处的配置设置进行判定。配置设置可以包括例如向其转发通信的恰当的SIP服务器12的IP地址。

根据一个实施例，当CC中心节点返回常规操作时，代理设备和其他网络元件，例如会话边界控制器，会继续监测以检测已恢复的与CC中心节点502的连接。响应于检测到恢复的连接，要提示代理重新登录到数据中心。根据一个实施例，自动退出消息可以被发送到分支CC节点15f、15g来断开所有代理的连接，从而强制代理重新登录到主节点。网络元件还可以停止电话通信到CC分支节点的重定向和代替目标请求回到数据中心500，使得适当的转换而不是突然断开当前的呼叫。

除上面关于图11-12B讨论的企业部署外，跨企业部署还可以从上面讨论的P2P机制中获益。

图13是根据本发明一个实施例的在跨企业部署中的分布式呼叫中心系统的方框图。除企业部署中体现的系统构成外，跨系统部署中的系统还包括通过可以类似于广域网11的广域网11a连接到数据中心500的外包站点550。例如，广域网11a可以是因特网或MPLS网络。

根据一个实施例，当代表数据中心500和分支CC站点10d、10e的呼叫中心端(premise)处的资源变得超负荷时，可以从外包站点550中获得额外的资源。外包站点550包括外包CC节点552，所述外包节点可以与前面实施例的CC节点15。根据一个实施例，外包站点550独立于与数据中心500和分支CC站点10d、10e相关联的企业。当外包CC节点552被联盟接收时，在外包站点550中的资源可以被用于共享给联盟中的其他对等成员。根据关于图9所讨论的机制，可以完成联盟接受外包CC节点552。例如，外包CC节点552可以通过类似于图9的注册节点15e的注册节点注册自己。如果联盟节点中的至少一个接受对等节点，那么外包CC节点的注册就会被接受。

根据一个实施例，虽然外包CC节点552被配置为向呼叫中心端提供额外容量，但外包节点不能推送自己的负载到呼叫中心端。

根据一个实施例，在各个CC节点之间共享资源时会引入额外的控制和约束。例如，如果外包服务多个企业，那么外部的外包节点552可能不会将请求发送回没有发起请求的企业。

根据一个实施例，通过广域网11a建立外包550和主企业数据中心500之间的连接，这样语音和HTTP业务就可以在公司之间互换。

根据一个实施例，外包拍卖行可以被设置为让他们的服务和资源对各公司都可用。公司可以根据他们的价格和可能的反馈或者外包的评论来选择外包。公司还可以在拍卖行发布他们的外包需求，各外包可以竞标。

一旦公司选定一个或多个外包，公司就可以通过主数据中心500设置其联盟/注册，以允许外包550加入他们的网络以用于上面讨论的超负荷服务。外包可以有两种契约模型(contract model)：1)基于交互量；和2)基于代理资源。在这两种情况下，外包都可以用于已限定的时间段。

图14是根据本发明一个实施例的云部署中的分布式呼叫中心系统的方框图。云部署包括如企业或跨企业部署一样通过广域网11连接到CC分支站点10d、10e的数据中心。另外，通过云站点600处的CC云节点602提供呼叫中心服务中的至少一些。在完整的云部署模型中，所有呼叫中心服务都是通过云站点600上的资源提供的。云站点600可以像软件即服务那样为多个呼叫中心提供这种服务。

在混合云部署模型中，一些呼叫中心服务通过数据中心和/或分支站点500、10d、10e处的资源提供，而其他服务通过云站点600上的资源提供。例如，入站业务可以被引导到云CC节点602以用于初始IVR处理，然后通过类似广域网11的广域网在数据链路604上被路由到预置代理。根据一个实施例，数据链路604横贯MPLS网络。

在另一个示例中，代理可以登录到CC云节点602，但是公司数据可以通过类似广域网11的广域网经由数据链路606从数据中心500中进行检索。举例来说，公司数据可以包括例如在顾客关系管理(CRM)数据库中维护的企业顾客的信息。在这方面，数据链路606可以是使用例如如本领域所熟知的安全数据通信协议提供的安全数据链路。

对于资源共享和本地易存活性，云节点602可以是P2P节点到CC中心节点502和/或分支CC节点15f、15g。根据一个实施例，大多数如果不是全部服务，那么大多数服务由预置资源通过CC中心节点502和/或CC分支节点15f、15g提供。根据该实施例，CC云节点602是备用节点，所述备用节点在预置资源处于超负荷容量状态和/或在紧急情况期间(例如，当到数据中心的连接丢失时)共享其资源。在这点上，云节点600可以被当作外包站点，类似于跨企业部署中的外包站点500。在这种情况中，代理和其他云CC资源不是必需的非受信商品，而是额外的公司资源。根据一个实施例，当分支CC站点15f、15g到数据中心500的连接丢失时，分支CC站点处的代理17e、17f可以登录到(手动或自动)云站点600处的CC云节点602。

根据另一个实施例，大多数如果不是所有呼叫中心服务，那么大多数服务都是由CC云节点602以及作为备用节点的预置节点提供的。

图15是根据本发明一个实施例的云部署的方框图，其中在常规操作期间，呼叫中心服务由CC云节点602提供。根据这个实施例，当CC云资源处于超负荷容量状态时和/或在紧急状态期间(例如，当到云节点的连接丢失时)，预置节点共享它们的资源。当云节点602正常工作时，代理612a-612c(统称为612)通过数据链路608登录到CC云节点602。根据一个实施例，数据链路608横贯广域网。

来自顾客610的电话呼叫也被路由到CC云节点602并通过CC云节点被连接到代理。根据一个实施例，特定的信息，举例来说，例如顾客信息，存储在数据中心500中并通过安全数据链路606进行检索。

图16是根据本发明一个实施例的说明到CC云节点的连接丢失而使得预置节点在本地存活模式下工作的云部署的方框图。根据本实施例，代理612使用的安装在代理设备30中的应用程序检测到CC云节点602的连接的丢失。在这种情况中，代理重新登录到数据中心500或相应的分支站点15f、15g。重登录可以用上面描述的关于其他本地存活实施例的方式完成。当然，顾客还可以注意到由于呼叫被重定向到不同的电话号码或提供不同电话号码供顾客拨打的消息而导致的连接丢失。

来自顾客610的请求被转发到预置节点(CC中心节点502或分支CC节点15f、15g)，直到至CC云节点的连接恢复为止。根据一个实施例，每个预置节点都作为其他节点的对等节点以用于互相共享资源。

根据部署和CC云节点602维护何种服务和信息，当预置节点在本地存活模式下工作时，到云节点的连接丢失可能意味着降低的功能级别。例如，如果CRM数据被保持在CC云节点602中，那么当在本地存活期间使用预置节点时，CRM数据可能不可用。当然，如果数据集中在数据中心500中，那么在本地存活期间，预置节点的功能可以和普通的云操作一样。

一旦云连接重新建立，代理612就可以重新登录到CC云节点602。如关于本地存活的上面实施例所述，在代理的桌面应用程序和/或通过每个节点本身的处理可以自动进行重登录程序。

在前面图中的各种服务器、控制器、交换机、网关、引擎和/或模块(统称为服务器)中的每一个都可以是运行在一个或多个计算设备1500(例如，图17A、图17B)中的一个或多个处理器上的进程或线程，从而执行计算机程序指令并与其他系统部件交互以用于执行这里描述的各种功能。计算机程序指令存储在内存中，从而可以在计算设备中使用标准内存设备(例如，随机存取存储器(RAM))来实现。计算机程序指令还可以存储在其他非易失性计算机可读介质中，例如CD-ROM、闪存驱动器或类似的介质。另外，本领域的技术人员应该了解到计算设备可以通过固件(例如，应用程序专用的集成电路)、硬件、或者软件、固件和硬件的组合来实现。本领域的技术人员也应该知道，在不脱离本发明的示例性实施例的范围的情况下，各种计算设备的功能可以组合或集成在单个的计算设备中，或者特定计算设备的功能可以分布在一个或多个其他计算设备上。服务器可以是软件模块，所述软件模块也可以简称为模块。呼叫中心中的模块组可以包括服务器和其他模块。

各个服务器可以在与呼叫中心的代理相同的物理位置处位于现场计算设备上，或者可以位于地理位置不同的非现场(或在云中)位置，例如在远程数据中心中，通过例如为因特网的网络连接到呼叫中心。另外，服务器中的一些可以在呼叫中心处位于现场计算设备上，而其他服务器可以位于非现场的计算设备中，或者提供具有冗余功能的服务器可以通过现场或非现场的计算设备提供以提供更好的容错能力。在本发明的一些实施例中，可以通过虚拟专网(VPN)提供和访问位于非现场计算设备上的服务器提供的功能，就像这些服务器在现场一样，或者可以使用软件即服务(SaaS)提供所述功能以通过因特网使用各种协议提供功能，例如通过使用编码的扩展标记语言(XML)编码或JavaScript对象标记(JSON)交换数据。

图17A和图17B描绘了本发明的示例性实施例中可以采用的计算设备1500的方框图。每个计算设备1500都包括中央处理单元1521和主内存单元1522。如图17A中所示，计算设备1500还可以包括存储设备1528、可移除介质接口1516、网络接口1518、输入/输出(I/O)控制器1523、一个或多个显示设备1530c、键盘1530a和指向装置1530b，例如鼠标。存储设备1528可以包括但不限于用于操作系统和软件的存储器。如图17B所示，每个计算设备1500还可以包括附加的可选元件，例如内存端口1503、桥接器1570、一个或多个附加的输入/输出设备1530d、1530e和与中央处理单元1521通信的缓存1540。输入/输出设备1530a、1530b、1530d和1530e在此可以共同使用附图标记1530来表示。

中央处理单元1521是响应和处理从主内存单元1522取来的指令的任何逻辑电路。例如，这可以在集成电路中实现，形式为微处理器、微控制器或者图形处理单元(GPU)，或者在场可编程门阵列(FPGA)或应用程序专用的集成电路(ASIC)中实现。主内存单元1522可以是能够存储数据并允许中央处理单元1521直接访问任何存储位置的一个或多个内存芯片。如图17A所示，中央处理单元1521通过系统总线1550与主内存1522通信。如图17B所示，中央处理单元1521还可以通过内存端口1503直接与主内存1522通信。

图17B显示了一个实施例，其中中央处理单元1521通过二级总线直接与缓存1540通信，二级总线有时也被称为后端总线。在其它实施例中，中央处理单元1521使用系统总线1550与缓存1540通信。缓存1540通常具有比主内存1522更快的响应时间。如图17A所示，中央处理单元1521通过局部系统总线1550与各种I/O设备1530通信。各种总线都可以用作局部系统总线1550，包括视频电子标准协会(VESA)局部总线(VLB)、工业标准体系结构(ISA)总线、扩展工业标准体系结构(EISA)总线、微信道体系结构(MCA)总线、外围组件互联(PCI)总线、PCI扩展(PCI-X)总线、快速PCI总线或网络用户总线(NuBus)。对于I/O设备是显示设备1530c的实施例中，中央处理单元1521可以通过高级图形端口(AGP)与显示设备1530c通信。图17B显示了计算机1500的一个实施例，其中中央处理单元1521直接与I/O设备1530e通信。图17B还示出了一个实施例，其中局部总线和直接通信被混合：中央处理单元1521使用局部系统总线1550与I/O设备1530d通信，同时直接和I/O设备1530e通信。

计算设备1500中可以存在各种各样的I/O设备1530。输入设备包括一个或多个键盘1530a、鼠标、触控板、轨迹球、扩音器和画板。输出设备包括视频显示设备1530c、扬声器和打印机。如图17A中所示，I/O控制器1523可以控制I/O设备。I/O控制器可以控制一个或多个I/O设备，例如键盘1530a和指向装置1530b，例如鼠标或光笔。

再次参照图17A，计算设备1500可以支持一个或多个可移除介质接口1516，例如软盘驱动器、CD-ROM驱动器、DVD-ROM驱动器、各种格式的磁带驱动器、USB端口、安全数字或COMPACT FLASH^TM存储卡端口、或者适合从只读介质读数据或从读写介质读写数据的其他任何设备。I/O设备1530可以是系统总线1550和可移除介质接口1516之间的桥接器。

举例来说，可移除介质接口1516可以用于安装软件和程序。计算设备1500可以还包括存储设备1528，例如一个或多个硬盘驱动器或硬盘驱动器阵列，用于存储操作系统和其他相关软件并用于存储应用软件程序。可选地，可移除介质接口1516还可以用作存储设备。例如，操作系统和软件可以由可启动介质(例如，可启动CD)运行。

在一些实施例中，计算设备1500可以包括多个显示设备1530c或连接到多个显示设备1530c，这些显示设备每一个可以是相同或不同的类别型和/或形式。因此，I/O设备1530和/或I/O控制器1523中的任何一个可以包括任何类型和/或形式的合适的硬件、软件或者硬件和软件的组合，以通过计算设备1500支持、实现或提供到多个显示设备1530c的连接和所述多个显示设备的使用。例如，计算设备1500可以包括任何类型和/或形式的视频适配器、视频卡、驱动器和/或库，以接口、通信、连接或用其他方式使用显示设备1530c。在一个实施例中，视频适配器可以包括多个连接器，以连接到多个显示设备1530c。在其他实施例中，计算设备1500可以包括多个视频适配器，每个视频适配器连接到显示设备1530c中的一个或多个。在一些实施例中，计算设备1500的操作系统的任何部分都可以被配置用于使用多个显示设备1530c。在其他实施例中，显示设备1530c中的一个或多个可以由通过网络例如连接到计算设备1500的一个或多个其它计算设备提供。这些实施例可以包括设计和构造成使用另外的计算设备的显示设备作为用于计算设备1500的第二显示设备1530c的任何类型的软件。本领域的技术人员应该知道和领会不同的方法和实施例中，计算设备1500可以配置为具有多个显示设备1530c。

图17A和17B所示类型的计算设备1500可以在操作系统的控制下操作，从而控制任务的计划和对系统资源的访问。计算设备1500可以运行任何操作系统、任何嵌入的操作系统、任何实时操作系统、任何开源操作系统、任何专有操作系统、用于移动计算设备的任何操作系统或者能够运行在计算设备上和执行此处所述的操作的任何其它操作系统。

计算设备1500可以是任何工作站、桌面计算机、膝上型电脑或笔记本电脑、服务器机器、掌上电脑、移动电话或其他便携式通信设备、媒体播放设备、游戏系统、移动计算设备或任何其他类型和/或形式的能够通信并具有足够的处理器能力和内存容量来执行这里所描述的操作的计算设备、电信设备或媒体设备。在一些实施例中，计算设备1500可以具有与该设备相容的不同的处理器、操作系统和输入设备。

在其他实施例中，计算设备1500是移动设备，例如启用Java的蜂窝电话或个人数字助手(PDA)、智能电话、数字音频播放器或便携式媒体播放器。在一些实施例中，计算设备1500包括设备的组合，例如与数字音频播放器或便携式媒体播放器相组合的移动电话。

如图17C所示，中央处理单元1521可以包括多个处理器P1、P2、P3、P4，并且可以提供用于同时执行指令或者同时在多于一个的数据块上执行一个指令的功能。在一些实施例中，计算设备1500可以包括具有单核或多核的并行处理器。在这些实施例中的一个中，计算设备1500是共享内存的并行设备，具有多个处理器和/或多个处理器核，从而能像访问单个的全局地址空间那样访问所有可用的内存。在这些实施例中的另一个中，计算设备1500是具有多个处理器的分布式内存并行设备，其中每个处理器只能访问本地内存。在这些实施例中的另一个实施例中，计算设备1500既有一些共享的内存，又有一些只可以被特定处理器或处理器的子集访问的内存。还是在这些实施例中的另外一个中，中央处理单元1521包括多核微处理器，该微处理器将两个或更多个独立的处理器组合成单个封装体，例如单个集成电路(IC)。在图17D所示的示例性实施例中，计算设备1500包括至少一个中央处理单元1521和至少一个图形处理单元1521′。

在一些实施例中，中央处理单元1521提供单个指令、多数据(SIMD)功能，例如同时在多条数据上执行单个指令。在其他的实施例中，中央处理单元1521中的多个处理器可以提供用于在多条数据上同时执行多个指令(MIMD)的功能。还是在其他实施例中，在单个设备中，中央处理单元1521可以使用任意组合的SIMD核和MIMD核。

计算设备可以是通过网络连接的多个机器中的一个，或者可以包括多个这样连接的机器。图17E显示一个例示性的网络环境。该网络环境包括通过一个或多个网络1504与一个或多个远程机器1506a、1506b、1506c(通常也称为(多个)服务器机器1506或(多个)远程机器1506)通信的一个或多个本地机器1502a、1502b(通常也称为(多个)本地机器1502、(多个)客户端1502、(多个)客户端节点1502、(多个)客户端机器1502、(多个)客户端计算机1502、(多个)客户端设备1502、(多个)端点1502或(多个)端点节点1502)。在一些实施例中，本地机器1502具有下面两个功能：作为客户端节点，寻求访问服务器机器提供的资源；作为服务器机器，为其他客户端1502a、1502b提供对托管资源的访问。虽然图17E中只显示两个客户端1502和三个服务器机器1506，但通常每一个可以具有任意数量。网络1504可以是例如为诸如公司互联网的私人网络的局域网(LAN)、城域网(MAN)或者例如为互联网或其他公共网络的广域网(WAN)或它们的组合。

计算设备1500可以包括网络接口1518，以通过各种连接与网络1504连接，所述各种连接包括但不限于标准电话线、局域网(LAN)或广域网(WAN)链路、宽带连接、无线连接或上述中的任何一个或全部的组合。可以使用各种通信协议建立连接。在一个实施例中，计算设备1500与其他计算设备1500通过任何类型和/或形式的网关或隧道协议通信，例如安全套接层(SSL)或传输层安全(TLS)。网络接口1518可以包括内置的网络适配器，例如网络接口卡，适用于将计算设备1500连接到能够通信和执行此处描述的操作的任何类型的网络。I/O设备1530可以是系统总线1550和外部通信总线之间的桥接器。

根据一个实施例，图17E的网络环境可以是虚拟网络环境，其中网络的各种部件都是虚拟化的。例如，各个机器1502可以是虚拟机，由运行在物理机器上基于软件的计算机实现。虚拟机可以共享同样的操作系统。在其他实施例中，可以在每个虚拟机实例上运行不同的操作系统。根据一个实施例，“管理程序”类型的虚拟机是通过运行在相同的主物理机器上的多个虚拟机实现的，每一个都好像它有自己的专用箱一样。当然，虚拟机还可以运行在不同的主物理机器上。

也会考虑其他类型的虚拟化，举例来说，例如网络(例如，通过软件定义网络(SDN))。诸如会话边界控制器的功能和其他类型功能的功能也可以被虚拟化，举例来说，例如通过网络功能虚拟化(NFV)。

在不脱离本发明精神和范围的情况下，申请人的本发明意在通过权利要求覆盖本发明所有已被本文选中而公开的使用和那些变形与更改。方式不同，出现在用户面前的模板细节就不相同。因此，本发明的实施例应该在所有方面被认为是说明性的而非限制性的，本发明的范围是由权利要求和他们的等效范围所指明的，而不是上述介绍的本发明的实施例。