Abstract:
An interaction router includes a computerized server executing a routing engine stored on a machine-readable medium, an interface at the server receiving information from an interaction switching element, the information regarding an interaction received at the switching element to be routed, an interface at the server to a wide area network (WAN), a function of the routing engine judging if one or more business-logic determinations are to be made to select a routing destination for the interaction, and a function for controlling the switch to route the interaction. If if one or more business-logic determinations are to be made, the routing engine requests the business-logic determination from a remote server over the WAN, and upon receiving the determination from the remote server, uses the determination in controlling the switching element to route the interaction.

Description:
CROSS-REFERENCED TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 12/340,937, filed on Dec. 22, 2008, the entire content of which is incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention is in the area of computer-telephony-integrated (CTI) telephone systems including Internet Protocol Network Telephony (IPNT) systems, and pertains particularly to a system and methods for improving the performance of complex interaction routing in a communication center. 
     2. Discussion of the State of the Art 
     Computer Telephony Integration (CTI) is well known and established in the art of telephony. Contact centers that employ state-of-art communications technologies practice interaction routing according to well developed software routines typically referred to as routing strategies. 
     Merging of pure telephone systems and computer networks has led to an evolution of transformation languages some of which are well known standards in the public domain and some of which are known to and are accessible to the inventor. Communication center extensible markup language (CCXML), and Voice Extensible Markup Language (VXML) are well known examples of languages used in expressing routing strategy that include expression of basic call control functions. 
     The inventor is aware of other XML-based languages used for expressing and executing interaction routing strategies in state-of-art communications centers (CC) where a typical CC application may include interactive voice response (IVR) scripts, intelligent routing strategies, various call control scenarios, agent scripting, statistical reporting, interaction workflow processing, agent level routing, customer profile-related routing, outbound call support, and multimedia interactions. XStrategy (XST) is known to the inventor and contains existing XML-based constructs but is enhanced through addition of newer constructs developed for more complex interaction routing environments. 
     An XML document enhanced with XST constructs has a file extension .sxml and may generally be defined as an (SXML) document. XST is used to specify call treatments, priorities, waiting time, timeouts and many other interaction states, variables, conditions, and commands. XST can be implemented as an extension of simple media control protocol (SMCP) known to the inventors for communicating call models represented in XML primitives or other low level descriptor languages. 
     XST can be used with a simple object application protocol (SOAP) or Xpath transport mechanisms in conjunction with back end data services as well as with Web service defined by Web Service Description Language (WSDL) or Web Service Flow Language (WSFL). It can be integrated into workflow management languages like Business Process Execution Language for Web Services (BPEL4WS) and XML Process Definition Language (XPDL). By tagging the existing scripts with an XST start tag, a predefined routine may be executed. 
     A tool known to the inventor as an interactive routing designer (IRD) is used to graphically construct XML-based routing strategies that are transformed into a more abstract interaction routing language (IRL) also known to the inventor. Extensible Style sheet Language Transformation (XSLT) may be used to transform XST directly to an abstract IRL or a valid subset of IRD XML. Exemplary XST sample scripts can be viewed in a U.S. patent specification entitled “Method for Implementing and Executing Communication Center Routing Strategies Represented in Extensible Markup Language” Ser. No. 11/317,105 Filed: Dec. 22, 2005. 
     Routing of customer interactions to customer service representatives is a critically important function of every state-of-art contact center. Traditional interaction routing is executed within a CC router in accordance with a routing logic expressed as an executable strategy. The flow of a routing strategy may be shaped or influenced by exiting states and rules relative to customer data, type of service, operational situation of contact center, business information, etc. 
     More complicated strategies contain sophisticated routines for accessing data from databases and manipulating or processing the accessed data. A byproduct of more complicated and intelligent routines is an increased difficulty in design and implementation of such routines. Deployment and actual runtime execution of these more complicated routing strategies also presents problems and challenges. For example, a typical intelligent routing strategy may occupy hundreds of pages represented in a complicated spaghetti-like graphical form. These routines are extremely error prone and face enormous qualification requirements from developers. 
     The IRD tool mentioned further above enables creation of sophisticated routing strategies aided by a graphics user interface (GUI) and a graphics regime. The IRD tool contains utilities for working with databases containing application and business data. However, the richness of language capability of the tool pales in comparison to traditional application programming languages like C, C++, C#, Java, etc. C#, or C-Sharp is a more recent C-based object oriented programming language developed by Microsoft™. The complexity of current state-of-art routing strategies subjects the host router to processes that substantially deviate from pure routing functions that the router is designed to perform. Execution of complex business calculations by the router often results in system overloads and resulting performance glitches. 
     Therefore what is needed in the art is a system and methods for improving the performance of interaction routing within a communication center. 
     SUMMARY OF THE INVENTION 
     The problem stated above is that sophisticated, intelligent routing strategies are desirable for routing interactions in a contact center, but many of the conventional regimens created for routing contact center interactions are difficult to design and execute and also create processing overloads or glitches in routing performance. The inventors therefore considered functional elements of a routing system looking for elements that exhibit complexity without creating processing problems that could potentially be harnessed to provide sophisticated intelligent routing but in a manner that would not contribute to programming errors, processing overloads, or glitches. 
     Every digital interaction routing system is driven by an application that includes a routing strategy one by-product of which is a constant hum of routing activity especially for a relatively large number of calls queued for service. Most such systems employ some interactive contact center application executed on a node having a processor and a router application running routing strategies for routing the calls. 
     The present inventors realized in an inventive moment that if, business-oriented logic and processing and pure routing logic and processing could be separated such that different dedicated processing resources and different design languages could be used to achieve a common goal of best fit determination of a destination resource for routing a particular event to, more sophisticated and intelligent overall strategies that are more efficiently executed and carried out might result. 
     The inventor therefore constructed a unique routing system for routing contact center events to available resources that allowed more complex and sophisticated tasks relative to business logic processing for destination matching or resource allocation and determination in routing to be performed on an application server and constrained the router application to executing and processing dynamic routing strategies created by the server that containing only pure routing logic. A significant improvement in the level of routing intelligence results with no impediment to processing efficiency at the router. 
     Accordingly, in one embodiment of the invention an interaction router is provided, comprising a computerized server executing a routing engine stored on a machine-readable medium, an interface at the server receiving information from an interaction switching element, the information regarding an interaction received at the switching element to be routed, an interface at the server to a wide area network (WAN), a function of the routing engine judging if one or more business-logic determinations are to be made to select a routing destination for the interaction, and a function for controlling the switch to route the interaction. If one or more business-logic determinations are to be made, the routing engine requests the business-logic determination from a remote server over the WAN, and upon receiving the determination from the remote server, uses the determination in controlling the switching element to route the interaction. 
     In one embodiment of the invention the business logic determination is requested through assertion of a universal resource locator (URL). Also in an embodiment more than one URL may be available for assertion, each URL pointing to a different portion of business logic at the remote server. Also in some embodiments the determination may be an executable strategy expressed in eXtensible markup language (XML). In this embodiment the XML strategy is parsed and executed at the interaction router. 
     In some embodiments the interaction switching element may be a computer telephony integrated (CTI) call switch. The WAN may be the Internet in many embodiments of the invention. The routing destination may be a live agent, a group of live agents or an automated treatment system. 
     In another aspect of the invention a method for routing an interaction received at an interaction switching element is provided, comprising the steps of (a) sending a request message to a remote server for a business logic determination; (b) at the remote server, processing any call data received against at least one rule to generate a business logic determination; (c) sending the business logic determination back to the interaction router; and (d) at the interaction router, parsing and executing the business logic determination to route the interaction. 
     In one embodiment of the method, in step (a), the remote server is an application server accessible by wide area network. Also in an embodiment the wide area network may be the Internet network. In some cases the business logic determination may be a machine readable and executable XML strategy. Also in an embodiment the request may sent as a result of the router invoking a URL during execution of a routing strategy. The XML strategy may be one of Xstrategy (XST), interactive routing designer (IRD) XML, or interaction routing language (IRL). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING FIGURES 
         FIG. 1  is an architectural overview of a telecommunications network that supports integration of business and pure routing logic in event routing. 
         FIG. 2  is an interaction flow chart illustrating interaction between nodes in event routing according to an embodiment of the present invention. 
         FIG. 3  is a process flow chart illustrating steps for routing an incoming event according to an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     The inventors provide a system and methods for improving the performance of interaction routing within a communication center. The system utilizes an external application server resource to assist in more complex business logic processing leaving pure routing logic for processing by a dedicated event router. The system and methods of the invention are described in the following embodiments. 
       FIG. 1  is an architectural overview of a telecommunications network  100  that supports integration of business and pure routing logic in event routing. Telecommunications network  100  includes the well-known public switched telephony network (PSTN)  101 , a wide area network (WAN)  102  labeled the Internet network in this example, and a contact center (CC)  103  also referred to in this specification as a communication center. 
     PSTN  101  is used in this example because of its high public access characteristic and geographic reach. Other telephone networks may also be represented without departing from the spirit and scope of the present invention such as private networks and wireless networks. A telephone switch  107  is illustrated within PSTN  101  at network level and is enhanced for computer telephony integration (CTI) by a CTI server  105  connected to the switch through a CTI link  104 . Telephone switch  107  is a private branch exchange switch in this embodiment but may be some other switch type such as automatic call distributer (ACD) or some other telephone switching unit without departing from the spirit and scope of the invention. 
     CTI server  105  provides intelligent peripheral services  106  to switch  107  such as transaction services (TS), and interactive voice response (IVR) services. Intelligent routing may be performed at network level through CTI enhancement of switch  107  at the network level. PBX  107  is connected by a telephone trunk  108  to a central office telephone switch  109  within communication center  103 . In this example, switch  109  is also a PBX switch. PBX  109  has connection to a local area network LAN  112  to which multiple agent computers belonging to agent stations  113  (1-n) are also connected. 
     PBX also has connection by way of internal telephone wiring  110  to a plurality of agent telephones provided at agent stations illustrated herein as agent stations  113  (1-n). Agents operating from stations  113  (1-n) may answer telephone calls incoming to PBX  109  using COST telephones or Internet protocol (IP) telephone applications resident on the respective agent computers. IP hand or headset telephones may also be provided and used for voice communications. 
     PBX  109 , like PBX  107  in PSTN  101 , is CTI enhanced by way of CTI server  114  connected to the switch within the call center by a CTI link  117 . CTI server  105  in the PSTN and CTI server  114  within contact center  103  are connected by a separate data network  111 . CTI server  114  is directly connected to LAN  112 . One purpose for CTI networking is that data about incoming call events can be solicited at switch  107  in the network and can then be routed to agents ahead of actual telephone call events giving agents time to prepare for interactions. Other current data held within the contact center may also be accessed and presented for agents ahead of or at least at the time of a telephone call the current data looked up and presented according to some routing strategy that may have required business logic execution. CTI server  114  may run instances of TS/IVR  106  and other agent level routing (ALR) routines used within the center but not at network level. 
     A CTI router  115  is logically illustrated in this example and is connected to LAN  112 . Router  115  may be a digital application running on a node such as a router application running on a computer, for example. CTI router  115  may be an application running on CTI server  114  instead of running on a separate machine. For purpose of discussion, router  115  is illustrated as a dedicated node connected to LAN  112  and to CTI server  114  by data link. Router  115  is responsible for executing routing strategy and determining routing destinations for all calls incoming at switch  109  and in some cases calls waiting at switch  107  through the CTI extension network. 
     A contact center application (CC/APP) is an application that automatically handles incoming events and allocates available contact center resources including live assistance to callers waiting in queue. In this example one or more CC/APPS are distributed to different processing resources within the center. In this example a main CC/APP  118   a  is illustrated on CTI server  114 . CC/APP  118   a  includes the main portion of the application that interfaces with callers waiting in queue at switch  109  for example. 
     A CC/APP written for a state-of-art contact center typically includes intelligent routing strategies that may be selected and executed depending on some processing of data, business state, caller state, or other variables or conditions associated to rules within the center. In this example router  115  includes a CC/APP  118   b  that performs only pure routing of events within the center upon a request message or routing request message sent to it by CTI server  114  running CC/APP  118   a  and thus contains only pure routing logics (PRL). 
     In a preferred embodiment, router  115  has a network connection  116  to Internet network  102  exemplified herein by an Internet backbone  123 . Internet  102  may be a private Internet segment or VPN maintained by the contact center for the purpose of provision of robust business processing and transaction capabilities over high-speed network. To this effect, an application/Web server  119  is provided on Internet network backbone  123  and is adapted to run CC applications over Hypertext Transfer Protocol (HTTP). Server  119  includes CC/APP (BOL)  118   c  which contains business oriented logic and task definitions for processing CC data to result and then determining routing strategy according to result. 
     APP server  119  is connected to a data network  120  which supports a rules base (RB)  121  and a data storage facility or database (DB)  122 . DB  122  may contain business data, customer data, payment information, or other business-type information and remains accessible to server  119 . APP server  119  is adapted to execute business oriented logic as a part of CC/APP  1183 . It is important to note herein that while CC/APP  118   a  and CC/APP  118   b  are designed with the same tool such as the Interactive Route Designer (IRD) tool, CC/APP  118   c  is designed using a more sophisticated and time tested server application programming language like C/C++, C#. 
     Router  115  is Internet protocol (IP) enabled and can issue an HTTP GET or POST to server  119 , which may then execute its own portion of the CC/APP BOL  118   b  corresponding to the requests sent by the router. Server  119  in includes a language generator (not illustrated) and a suitable vocabulary in XML constructs to enable the server to dynamically generate executable routing strategies based on computing that has been performed at the server. 
     In general when a call arrives at switch  109 , CTI server  114  executes an instance of main CC/APP to interact with the caller. When the executed CC/APP (main portion)  118   a  comes to a place in the process where a routing determination is to be made then it passes a route request to dedicated router  115 . Router  115  executes and runs a portion of the CC/APP ( 118   b ) that deals only with pure routing logic (PRL). Pure routing logic does not contain any complex processing of data or complex access or rule-based manipulation of data residing in databases. It only contains the strategies for routing the event to a destination. In some cases that is an automated system or a live agent and a more complex treatment is not required to accomplish successful routing of the event. 
     While CTI router  115  is running a pure routing logic portion of the CC/APP, it may occur in the PRL strategy a point defining a need for further more complex processing to better determine a final destination for an event or, in this case, a call. At such a point in the process, router  115  may send an HTTP request to APP server  119  to start CC/APP  118   c  and to perform some defined routine or a sequence of tasks that may require lookups of data from DB  122 , consultation in RB  121  and processing of accessed data to determine outcome or results. The associated business processing portion of the overall routing strategy is given a universal resource locator (URL) at application (Web) server  119 . The correct URL is embedded in the strategy executed in the router and invocation of the URL causes the HTTP channel to open between the router and the Web server. 
     Server  119  is adapted according to pre-defined business process workflow and definition to obtain enough information relative to current call campaign rules and stated need to generate, “on the fly”, an intelligent routing strategy formed as an XML-based executable instruction that may be generated in an XML-based markup and may be sent back to router  115 . The executable instruction also termed a strategy by the inventors plugs into the CC/APP  118   b  running on the router and is parsed and executed immediately upon receipt, also “on the fly”. 
     In a preferred embodiment CC/APP  118   c  residing on server  119  is constructed using a standard programming application language like C/C++, C#, Java. In this way the processes for complex execution and manipulation of data according to predefined business logics are performed on a different processing system than the one dedicated to event routing. The CC/APP is created for different processing environments, that is to say, a caller interaction and event routing environment and a business process environment. 
     Application server  119  is adapted as described further above to generate an XML-based routing strategy that includes the identification of the final destination agent, agent group, etc. that will handle the interaction. The router receives this strategy and immediately parses and executes the strategy in real time while the caller is waiting in queue. In one embodiment there may be more than one HTTP request sent from router  115  to server  119  and HTTP responses containing pure routing strategies from the server back to the router per event in queue. Workflow including multiple routing strategies may be integrated into the CC application process as long as the workflow has to do with routing and not unfamiliar data processing that would tax the router processor beyond something reasonable. 
     CC  103  includes an Internet protocol router (IPR)  124  connected to LAN  112  on one side and to Internet backbone  123  on the network side. IPR may server as a gateway for multimedia communications arriving into the center and being sent out from the center. CTI router  115  also has a network side connection to Internet backbone  123  and a center-side connection to LAN  112  and could also server as a digital router for routing email, messaging and other like events. In this example, CC hosted data and rules are contained in DB  122  and in RB  121  within the Internet cloud directly networked to sever  119 . However, a local server (LS)  125  may be provided and connected to LAN  112  and a DB  126  may be connected directly to the server. In one embodiment server  119  may have permission to access LS  125  and data stored in DB  126 . Business data, customer data, rules, and other critical data may be stored locally at the center but made accessible to the Web-based application server. 
     In one embodiment the system of the invention is enabled by an online third party provider that provides the added processing power of an application server and language generator to create and deliver executable routing strategies that result in much more efficiency in interaction routing at the contact center side. Critical business data required to create the strategies may be stored locally and mirrored to the service network (online) for faster access. The third party application server may also access data locally without departing from the spirit and scope of the present invention. 
     After CTI router  115  receives and executes a routing strategy it may send the routing path used to CTI server  114 , which may in turn send the path to CTI server  105  if the call event is to be routed from the point of PBX  107  instead of PBX  109 . 
       FIG. 2  is an interaction flow chart  200  illustrating interaction between nodes in event routing according to an embodiment of the present invention. Chart  200  is descriptive of a routing system including a PBX, CTI Server, a Router, an Application server, and a data base/rules base. 
     At step  201  an incoming event notification is sent from a PBX to a CTI-Server. The CTI-server executes a CC application and an interaction with the caller  202  ensues such as an IVR treatment for example. A processing point  203  comes up at the CTI server in the executed application at which some type of routing is required beyond what the CTI server can do. The CTI server sends a route request message to the router and the router acknowledges the request at step  204 . 
     The router then executes the routing strategy according to the request until a processing point  205  is reached in the application at which point additional information is required in order to determine a best destination for routing the event. At step  206  the router sends an HTTP request associated with universal resource locator (URL) to an application server and receives an acknowledgement of the sent request back. URLs are used to specify the portions of the business logic available to the application server that should be executed. Wherever the routing strategy requires processing of business oriented data a URL will be embedded that links the process to the appropriate business logic at the application sever on the Web. 
     The application server looks up data and/or rules from a database/rules base and receives data and/or rules for processing at step  207 . The application server processes data against one or more rules until it has some result. The application server also generates dynamic executable routing strategy that contains only pure routing constructs at a processing point  208 . The application server sends the strategy in the form of an XML document to the router in an HTTP server response and the server receives an acknowledgement from the router at step  209 . 
     At processing point  210 , the router executes and runs the routing strategy including allocating the required resources for handling the event. At step  211  the router sends the route used back to the CTI server and the CTI server acknowledges receipt of the route information. The CTI server sends instruction to the switch or queue to the PBX to route the event and the PBX acknowledges the instruction at step  212 . In this example all processing that is not dedicated to pure interaction routing is performed by the application server at processing point  208 . All of the business side processing and routing strategy generation that results is transparent to the call center side. The resulting routing strategies are plugged into the CC application at the router and are immediately executed. The overall result is that more complex and flexible interaction routing may occur in a manner that does not overload the routing system. Moreover, the router no longer has to check availability of resources for routing as that is performed by the application server as well. 
       FIG. 3  is a process flow chart illustrating steps  300  for routing an incoming event according to an embodiment of the present invention. At step  301  a call arrives at a PBX or other type of call center switch and notification of the event is passed to a CTI server. An instance of contact center application starts on the connected CTI server to begin interaction with the caller. Such interaction may include IVR treatment, contact center voice applications, etc. 
     At step  303  the contact center application determines if the call event can be disposed of via an automated treatment or not. If at step  303  an automated treatment can be used to dispose of the call then at step  305  the treatment is used to handle the call. This step may involve routing the call to the automated treatment node if the caller is not already engaged by the automated treatment node. An automated treatment may be any interactive process that does not require a live operator. After the treatment is administered at step  305  the process for that event may be terminated at step  314 . In this case no special business logic or processing was used in routing. It is possible in this path that a routing request message was not necessary so that the interaction router was not even involved with that specific event. 
     If the contact center application determines that the call event cannot be disposed of via an automated treatment, at step  304  the contact center application may request a routing strategy by passing a route request message to an interaction router. The router may then select and execute a routing strategy that contains only pure routing logic as an extended part of contact center application runtime. A distributive processing environment may exist where the router is actually supported by a processer separate from the processor supporting the CTI server. In one embodiment the router and CTI server are supported by the same processor. 
     Determination that an automated treatment cannot be used to handle the event could be determined by information provided to the application by the caller prior to that point in the process or other call data made available at the time. Depending on the nature of services and other possible factors, the contact center application running on the router in execution of a routing strategy may arrive at a point in the process where some external processing is required to determine a best treatment for the call. The contact center application portion running on the router may make this determination based on available call data at step  306 . 
     If at step  306  the application determines that no external processing is required to successfully route the call event then the router may route the event to any available contact center agent at step  307 . In this event only pure routing logic was executed and a simple route to an available agent is determined based on available call data. No complicated business data processing or rules consultation is performed and therefore, no third-party processing service is required. After the router connects the call to an available agent in step  307  the process may terminate for that event at step  314 . 
     If at step  306  it is determined that external processing is required in order to route the call event, at step  308  the router connects to a Web-based application server by invoking a URL embedded in the pure routing logic being executed at the router. To be clear, an existing routine executed at the router determines based on available call data or information solicited during interaction leading up to that point in the process that the event requires external processing. The URL then is a link between the point of process where this determination is made and the business logic portion of the distributed CC application that will be executed to fulfill the request. 
     In one embodiment the router request is an HTTP GET or POST message. At step  309  the CC application running at the Web-based application server executes the business logic targeted by URL in the request. The logic may include tasks for accessing databases, manipulating customer and business data, consulting business rules and so on. This business oriented logic can be created using any programming tools and languages available to the application server programmer. At step  310  the application server executing the target business logic accesses and processes the required data against pre-defined business rules to render some expected result. The logic may vary widely as may the exact processing sequence. 
     At step  311  the application server may generate a routing strategy using a markup language generator that renders the executable strategy in some form of extensible markup language. In one embodiment the form is interaction routing language (IRL). Other forms such as XStrategy (XST) or interactive routing designer (IRD) XML may also be used. The generated routing strategy is sent in a server HTTP response to the router at step  312 . The strategy plugs into the appropriate place in the interactive process and is immediately parsed and executed by the router as pure routing logic at step  313 . The process for that event may be terminated at step  314  after the resources for handling the event are allocated for the interaction. Of course the route is passed on to the CTI server which routes the interaction to the appropriate resource, which in this example is a live agent. 
     One with skill in the art of telephony routing will appreciate that rules for routing and data relied upon to help determine need may vary widely. Skill-based routing, statistical-based routing, predictive routing, historical-based routing, priority-based routing, trust-based routing and other intelligent routing techniques may be observed where external processing is required to make the correct or “best-fit” determination of a final destination for a particular call event. Moreover, the process is not limited to telephone interaction as a variant of this process may be applied to Web services and other electronic interaction media such as text messaging, interactive chat, and so on. In one embodiment XML-based routing strategies may be pre-defined strategies created on the Web. These strategies may be pushed into a routing application at a contact center to execute the strategy as a Web-based service. 
     One key benefit of the system of the invention is that the router may be dedicated to executing pure routing logic and therefore is improved in efficiency due to a lack of any requirement for processing any business or customer data or accessing any databases or rules bases. Another benefit to the system is that intelligent routing strategies can be generated (APP server) and executed (Router) on the fly by cooperating systems. Therefore dynamic flexibility exists for working with all kinds of conditions that may exist at the time of interactions. Routing logic can be made more sophisticated through design of the business portion of routing logic or business oriented logic (BOL) to execute on an application server. Development of the business portion of routing is not limited to router capability constraints. Performance level of the router will be increased by dedication the router to pure routing logic, which includes path and agent allocation. 
     It will be apparent to one with skill in the art that the distributive routing system of the invention may be provided using some or all of the mentioned features and components without departing from the spirit and scope of the present invention. It will also be apparent to the skilled artisan that the embodiments described above are exemplary of inventions that may have far greater scope than any of the singular descriptions. There may be many alterations made in the descriptions without departing from the spirit and scope of the present invention.