Abstract:
The Web customer contact system is based on distributed execution of service logic programs that can be dynamically altered based on changing business needs. The distributed and dynamic program modification makes the Web customer contact system scalable and customization to the most demanding business operation needs. For example, existing workflow based GUI programming tool, which only support centralized specification, down load and execution of routing rules for incoming calls in a contact center. The new system WCC system can allow user to specify a set of service logic program (SLP) can be dynamically attached to any distributed “addressable entities” in the WCC system. The addressable entities can be a user, an agent, an email box, a work group, IVR system, or a department web site. The addressable entities can be located anywhere that can be reached by internet address (an URL or other types of identities). The SLP associated with the addressable entities can be dynamically downloaded from the “home” location of the SLP. The SLP allows a business to define the way of handling customer&#39;s messages such as call, chat and email in a flexible and programmable way using an open specification interface such as, XML technology.

Description:
BACKGROUND AND SUMMARY OF THE INVENTION 
   The present invention relates generally to telephone call routing systems and internet server systems. More particularly, the invention relates to a system and method that digitally associates telephony and internet content, allowing calls to be routed among selected calling and receiving parties, enabling the parties to communicate over the telephone network while simultaneously accessing concurrent internet content. 
   Anyone who has interacted with a complex automated telephone attendant system, voicemail system, or automated help desk system knows well the shortcomings of current technology. The user may be prompted for certain information that is used to route the user&#39;s call to the proper telephone extension or help desk agent. For example, a user may be prompted to input his or her account number into an automated banking system, in order to verify that the user has an account and to then route the user&#39;s call to the proper department. Unfortunately, current systems do not have a mechanism to retain the user-entered data (e.g., account number) after the call is transferred. Thus the officer or help desk agent receiving the routed call must again ask the user to repeat the previously entered information. Depending on the complexity of the sequence of routing operations, the user may be asked to enter his or her account number several times during the process. 
   Now that the internet is readily available to most people, many elect to bypass the conventional telephone-based help desk system by seeking assistance via web-based internet sources. Recognizing that many users will visit a company web site first, before placing a telephone call to receive personal assistance, many companies have constructed their web sites to provide answers to the most commonly sought questions. Banking systems, for example, allow the user to enter his or her account number along with a password and then view the current state of the user&#39;s account. While internet-based resources do eliminate some of the problems associated with telephone-based, voice-prompted systems, there are still times when a user simply needs to talk to a real person. 
   Currently, after the user has researched his or her question through the information available on the company&#39;s web site, the user may desire to call a help desk or customer service department to obtain further information from a human agent. Because there is no link between web page and telephone call, the agent has no way of knowing what information the user has already obtained via the internet, nor does the agent know what information the user has provided via the internet when answering the user&#39;s call. Thus the agent must ask the caller to repeat pertinent information, including what web page the user is viewing or has viewed, in order to handle the user&#39;s request. If the agent needs to refer the caller to another agent or another department, chances are good that the caller will need to repeat the same information again, as conventional systems do not capture and forward the state of the transaction carried out thus far. 
   The present invention addresses these problems through a system that associates internet content data and telephony data so that information provided by a user through a web site will automatically be associated with the user&#39;s telephone call. Even if the call is routed to a succession of different agents, all information previously gathered through the internet or through a telephone-based interactive response system will be maintained. The system is quite flexible. It even allows the help desk agent or attendant to provide internet information back to the caller. Thus the agent can cause the user&#39;s browser to display a different web page or different media content without requiring the user to take any overt action. If the appropriate agent is not available to handle a user&#39;s call when the user first requests it, the system has a callback scheduling module that will initiate a telephone call to the user when an agent is available and the system will automatically place both user and agents&#39; internet web screens in synchronism when the user answers the call. In this way the user and the agent can efficiently conduct business without the need to repeat information that was previously supplied. 
   Although the system is well-suited for centralized helpdesk environments, there is no restriction that all agents must be physically located in a given premises. Indeed, the agent can physically reside anywhere he or she has access to a telephone network and suitable internet connection. Moreover, while the presently preferred embodiment is designed to support voiced communication over a conventional telephone network, the invention can readily be extended to voiced communication and video conferencing information over a computer network using IP packets or the like. 
   The present invention provides a novel Web customer contact system based on distributed execution of service logic programs that can be dynamically altered based on changing business needs. The distributed and dynamic program modification makes the Web customer contact system scalable and customization to the most demanding business operation needs. For example, existing workflow based GUI programming tool, which only support centralized specification, down load and execution of routing rules for incoming calls in a contact center. The new system WCC system can allow user to specify a set of service logic program (SLP) can be dynamically attached to any distributed “addressable entities” in the WCC system. The addressable entities can be a user, an agent, an email box, a work group, IVR system, or a department web site. The addressable entities can be located anywhere that can be reached by internet address (an URL or other types of identities). The SLP associated with the addressable entities can be dynamically downloaded from the “home” location of the SLP. The SLP allows a business to define the way of handling customer&#39;s messages such as call, chat and email in a flexible and programmable way using an open specification interface such as, XML technology. 
   According to another aspect of the invention, the web-content aware automatic call transfer system comprises an automated call dispatch server that is adapted for coupling to a computer network. The server has an associated telephony interface that is adapted for coupling to a telephone network. This telephone network could be a conventional circuit-switched network or a packet-switched computer network. The automated call dispatch server has an associated call model data structure that represents communications between parties as call objects. The call objects are capable of associating both internet content data and telephony data. The automated call dispatch server has an associated routing manager that is adapted for routing calls between a first party and a second party, using the call objects. In this way, the server enables the first and second parties to communicate over the telephone network while simultaneously accessing concurrent internet content. 
   For a more complete understanding of the invention, its objects and advantages, refer to the following specification and to the accompanying drawings. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a system block diagram illustrating one implementation of the invention; 
       FIG. 2  is a block diagram illustrating the presently preferred architecture of the automated call dispatching system; 
       FIG. 3  is an object diagram illustrating the presently preferred automated call dispatching server components, including the server applications, data model and queues; 
       FIG. 4  is a detailed block diagram of the Call Model used by the automated call dispatching server; 
       FIG. 5  is an object diagram illustrating how events are sent between client application and server application; 
       FIGS. 6A–6D  comprise a series of call model object diagrams showing how a call is set up within the automated call dispatching server; 
       FIG. 7  is a sequence diagram showing the message flow between an interactive voice response system and the automated call dispatching system; 
       FIG. 8  is a sequence diagram illustrating message flow inside the automated call dispatching server when a new call comes in; and 
       FIG. 9  is a sequence diagram illustrating message flow inside the automated call dispatching server when an agent is available to handle a new incoming call; 
       FIG. 10  is a block diagram illustrating a conventional distributed database engine, useful for understanding how the present invention differs; 
       FIG. 11  is a block diagram illustrating the Web Hyperlink Dictionary (WHD) that manages URLs and properties of URLs in accordance with the present invention; 
       FIG. 12  is a block diagram illustrating one example of how SLPs may be utilized in accordance with the present invention. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   Overview of Exemplary System 
   Before presenting a detailed description of the automatic call transfer system an overview will be presented to illustrate how the system may be used in a commercial application. The system is based on an automated call dispatch (ACD) architecture that supports a set of distributed service logic programs (SLPs) in accordance with the present invention. A more complete description of a presently preferred ACD architecture and of the SLP technology is provided below, following the present basic discussion of the automatic call transfer system featured in  FIG. 1 . 
     FIG. 1  illustrates an exemplary application in which both internet content data and telephony data are administered by the automated call dispatch (ACD) server. The illustrated embodiment shows how a typical help desk application or sales support application would be implemented using the invention. The end user has access to a computer  10  that is connected to a computer network such as the internet  12 . Computer  10  includes suitable software such as a web browser so that internet content can be displayed in the web browser screen  14 . The user also has a telephone  16  connected to suitable telephone network  18 . Although a separate telephone  16  has been illustrated here, the invention can also be implemented using internet-based telephony. In such an embodiment the user would communicate by voice (and also optionally by video conferencing) using the computer  10 . The user&#39;s voice is digitized and transmitted as packets over internet  12 . 
   The help desk or sales support office may have one or more help desks or sales agents, each provided with computer equipment and telephones.  FIG. 1  shows two agent work stations, which each include a computer terminal  20   a  and  20   b  and a telephone handset  22   a  and  22   b . The telephone handsets are connected to a private branch exchange (PBX) telephone system  24 . The PBX telephone system  24  is suitably connected to the telephone network  18 , allowing it to place and receive calls over the telephone network. 
   The help center or sales support center also includes an automated call dispatch (ACD) server  26 . The ACD server is connected to the computer terminals  20   a  and  20   b  and also to the PBX telephone system  24 . Much of the functionality of the call transfer system resides in the ACD server. Details of the server are provided below. 
   For purposes of illustration it will be assumed that the help desk or sales support center is maintained by an enterprise that also has a public web site. Web server  30  is illustrated in  FIG. 1  to provide this functionality. Web server  30  serves web pages and other internet content data to users&#39; computer terminals, such as computer  10  via internet  12 . As will be more fully explained, the web server  30  is provided with a small servlet  32  which allows the web server to interface with the ACD server  26 . The servlet  32  is a small executable program installed on web server  30  to allow information passed to the web server  30  to be suitably forwarded on to the ACD server  26  for call transfer purposes. For example, if the user operating computer  10  inputs his or her telephone number to request a call back from an available sales agent, the information provided in response to a web page served by web server  30  is captured by the servlet  32  and forwarded to the ACD server  26 . The ACD server  26  receives the user&#39;s telephone number from the servlet and then uses it to initiate a call back to the user when an available agent is free. In the presently preferred embodiment the servlet  32  is capable of supporting a wide variety of different features which require user-supplied information to be transferred to the ACD server. In this regard, the call back feature is but one example. 
   The Automated Call Dispatch (ACD) Architecture 
     FIG. 2  shows the ACD architecture of a presently preferred embodiment. A layered architecture is used, in which each layer is represented as a rectangular box. The topmost layer is the graphical user interface presentation layer  40 . This layer actually resides within the browser application software of the various parties that will use the system. The user graphical user interface (GUI)  42  dictates what an end user, such as the user of computer  10  in  FIG. 1 , will see in his or her browser window when accessing the web site hosted by web server  30  ( FIG. 1 ). The agent GUI  44  controls what each help desk agent or sales support agent will see in his or her browser window when using the system. Thus agent GUI  44  controls what appears in the browser displays of computer terminals  20   a  and  20   b . Other graphical user interfaces are possible. Illustrated in  FIG. 2  is an administrator GUI  46  and a supervisor GUI  48 . The administrator GUI  46  might be used, for example, to change settings in the system software associated with web server  30  and ACD server  26 . The supervisor GUI  48  might be used, for example, by supervisors responsible for managing the help desk agents or sales support agents. 
   The next layer below the GUI presentation layer  40  is application interface layer  42 . It is in this layer that the web server servlet  32  is preferably placed. As illustrated, the servlet  32  is capable of communicating with any of the graphical user interfaces found within the GUI presentation layer  40 . Also found within application interface layer  42  is a server application agent  46 . The server application agent performs the primary interface function of connecting all users (through their associated GUIs) to the server application layer  48 . A corresponding client application agent  50 , residing in the server application layer  48 , provides the other end of the link. The preferred embodiments are based on multithreaded code in which each incoming or outgoing call is represented as a thread. 
   The server application layer  48  includes additional manager modules that provide different services for the underlying data model layer  52 . These managers include a routing manager  54 , an agent queue manager  56  and a call queue manager  58 . The routing manager is responsible for all call routing operations. The details of this manager are provided below. The agent queue manager and the call queue manager are responsible for respectively handling the list of agents that are available to handle an incoming call and the list of incoming calls waiting to be handled. Routing manager  54  receives incoming calls from the call queue manager  58  and assigns them to the appropriate agent as provided by the agent queue manager  56 . The call routing function can be quite sophisticated, if desired. Because an incoming call may have associated with it a particular set of data obtained through previous interactive response or through web page input, the routing manager  54  has the ability to assign an incoming call to a selected agent that is appropriate for the nature of the incoming call. Best, an inquiry from a user regarding television sets would be routed automatically to an agent who handles that product line. An incoming call for a credit application would be routed to a different agent in the financial department. 
   At the core of the preferred embodiment is the ACD call model and its associated queues, depicted at  60 . As will be more fully explained, the call model is an object-oriented model that combines internet content data and telephony data, keeping an association between both so that when a call is routed all previously obtained context information is routed with the call. 
   The presently preferred implementation interfaces with both telephony and internet media platforms. Thus the presently preferred ACD architecture includes a telephony and media platform layer  62  with its associated telephony and media interface module  64 . This layer provides the physical connectivity interface with the telephone network and with the internet or computer network. 
   The application interface layer  42 , server application layer  48  and data model layer  52  are preferably implemented using persistent storage as indicated diagrammatically at  66 . 
   Because the user, agents, administrator and supervisor will all access the ACD system remotely in the preferred embodiments, the ACD architecture can be further divided into client side applications and server side applications. The client side applications include the GUIs in the GUI presentation layer  40 . The server side applications comprise all of the applications and modules of the remaining layers. 
     FIG. 3  shows the ACD server architecture in greater detail. The client application (which could be implementing any of the GUIs illustrated in  FIG. 2 ) is shown in  FIG. 3  at  70 . It communicates using TCP/IP protocol or other suitable network protocol. The communication link can be implemented using HTTP, IPP, or the like, to specify the Uniform Resource Locator (URL) of the ACD server. As illustrated in  FIG. 3 , the client application  70  communicates with the client application agent  50  (a component of the server application layer  48  of  FIG. 2 ). The client application  70  also communicates with the web server servlet  32  which may be deployed on the web server  30  ( FIG. 1 ). 
   The client application agent  50  communicates with an ACD provider module  72  that is part of the call model  60  of the data model layer  52 . The call queue manager  58 , routing manager  54  and agent queue manager  56  also communicate with this ACD provider. The ACD provider&#39;s primary function is to maintain each call as a thread. The ACD provider instantiates threads for representing each call from a main thread  74  that has been diagrammatically illustrated in the server application layer  48 . The main thread is the starting point of the server application. It controls the other ACD server application threads as well as the call model  60 . The main thread has the ability to shut down modules and restart them. This gives the system the ability to perform run time updates of any of the modules making up the system. 
   The ACD provider module  72  maintains records in persistent storage of the addresses and terminal identification data of each party participating in a call. These address and terminal components of the call model are illustrated at  74  and  76 , respectively. 
   To support internet web-based applications on the server side, the main thread can instantiate a web application thread. Web server servlet  32  sends requests to the web application thread through the IPP channel. Through the same channel, the web application thread sends information back to servlet  32 . Servlet  32  then presents the information to the user&#39;s browser. This allows the system to pass content to the user&#39;s browser, thereby opening up interesting possibilities for interactive exchange. An agent at the help desk center or sales support office could, for example, cause information to be sent to an end user&#39;s web browser. Thus the agent could show the end user additional web content or multimedia content in response to a user&#39;s inquiry. A user interested in DVD players might be taken to a different web page where a particular model is described. The agent is able to control such action through the servlet functionality. 
   The routing application is one of the main functions of the ACD server. The ACD server takes calls from telephone, web or internet protocol terminal, and then finds an agent who can answer the call in the event the calling party wants to talk with an agent in person. The routing application identifies a suitable agent for each call based on predefined routing logic. Each agent has certain assigned duties and responsibilities, which are known to the routing application. Depending on the context of the user&#39;s call (which is determined through prior interaction with the user) the routing application selects an available agent who has the necessary qualifications to handle that type of inquiry. 
   Most of the time, management of the call center can be handled remotely by a supervisor or administrator with the help of the ACD client side application. On the server side, a client application controller thread responds to instructions from the supervisor or administrator and to send event and command messages to other client applications in response to the supervisor or administrator&#39;s instructions. Communication between the client and server applications takes place over a suitable communication channel. In the presently preferred embodiments the TCP socket and IPP mechanisms are used for this purpose. The client application can also communicate with a server application through the HTTP channel. In other words, client applications can send a request to a web server on the server side to invoke a servlet. The servlet then communicates with the web application thread inside the server application. The web application thread processes the request and sends the results back. Web push technology can be used to return messages back to the client asynchronously. 
   As noted above, one embodiment of the invention provides a call back feature whereby the user is able to enter his or her telephone number into a field on a web page and the system will then call that person back, at the number provided, once an appropriate agent is available. This feature is implemented using a call back scheduling module that is part of the ACD server application. The call back scheduling module maintains a call back queue which sends a call request to the ACD call model. 
   In the preferred embodiments all communication between modules is done through the ACD call model. The call model provides a common data structure for all ACD server application threads. Basically, when one application threads wants to send an event notification to another application thread, it first changes the state of the call model object and then generates the event message. Thereafter, it invokes an event-listener state on the call model object to pass the event to the other application thread.  FIG. 4  illustrates how such inter module communication occurs within the ACD call model. In  FIG. 4  logical relationships among modules are shown in solid connecting lines. Event-listener operations are shown in dot-dash lines and per call communications are shown in dotted lines. The routing manager  54  listens for events from a number of the entities within the ACD call model, namely: the call center call object  80 , ACD manager connection object  82 , ACD connection object  84 , terminal connection object  86 , ACD manager address object  88 , and ACD address object  90 . The call queue manager  58  and the agent queue manager  56  also listen for events disseminated by the ACD address object  90 . 
     FIGS. 6A through 6D  illustrate how the ACD call model supports call routing. Referring to  FIG. 6A , the routing manager instantiates a call object  100  associated with a thread dedicated to the incoming call. The call object in turn associates a connection object  102  that is associated with the caller address  104  and an ACD connection object  106  that is associated with the ACD address  108 . The ACD address may be a direct dial extension within the PBX system  24  ( FIG. 1 ). Note that at this point the routing manager has established a connection relationship between the incoming caller and the ACD server system. 
   Next, as illustrated in  FIG. 6B , the routing manager  54  causes call object  100  to associate a connection object  110  that is associated with an interactive voice response system address  112 . The interactive voice response system may be used to elicit information from the caller, so that the system can appropriately route the call to the proper agent. Of course, the attachment of an interactive voice response system at this point is merely intended to illustrate one way of operating the invention. If, for example, the incoming call does not require interactive voice response services, then the routing manager would connect to other resources instead. 
   An example of such resource is shown in  FIG. 6C . In  FIG. 6C  it is assumed that the interactive voice response session has finished and that the user is to be temporarily placed on hold while an appropriate agent can be identified and connected. The routing manager causes call object  100  to attach connection object  114  which is associated with the address  116  of a music system. Thus the incoming caller is entertained by a musical program while the routing is in process. 
   When an agent is available the agent queue manager  56  ( FIG. 4 ) notifies the routing manager and a connection object  118  with knowledge of the agent&#39;s address  120  is associated with call object  100 . This places the caller and agent in communication with one another, not only through the telephony channel but also through any web-based resources that the parties are using. The ACD connection object stores web-related resource information, such as information gathered via the servlet  32 . In this way, the agent who picks up the incoming call has access to all information supplied by the caller through interaction over the web. Likewise, the agent has access to all information supplied by the caller during interaction with the interactive voice response system. 
   To further understand how the interaction transpires, refer to  FIGS. 7 ,  8  and  9 .  FIG. 7  shows the message flow between the interactive voice response system and the ACD system. Specifically,  FIG. 7  shows the sequence of messages that are passed among the following entities:
         Telephony/media platform  150  (via the telephony media interface  64  of  FIG. 2 )   ACD address and queues  152  (see ACD address object  90  of  FIG. 4 )   Call queue manager  58  (see also  FIG. 4 )   Routing manager  54  (see also  FIGS. 2 ,  4  and  6 A–D)   ACD call model  60  (see also  FIG. 2 )   Interactive voice response system  154 .
 
Each of the messages shown in  FIG. 7  represents an event message if it contains the designation Ev in the message name. The first four event messages  160 ,  162 ,  164  and  166  essentially communicate a request to the interactive voice response system  154  to play an enunciation message  168  requesting the user to enter a numeric value on the telephone key pad. The next event message  170  is the digit entered by the user. As illustrated, this digit is sent to the ACD call model  60 . The ACD call model  60  notifies the interactive voice response system that a digit has been received (message  172 ) and the interactive voice response system may either send out a further play enunciation to the user or it can signify (message  174 ) that the interactive session is done. This indication results in a cascade of messages that ultimately notify the ACD address and queues object  152  that the call is ready to be routed.
       

     FIG. 8  is a similar diagram illustrating how messages are passed within the ACD when a new call is processed after the interactive voice response session. As illustrated, messages are passed among the following entities:
         Agent queue manager  56  (see also  FIGS. 3 and 4 )   ACD address and agent queues  180  (see ACD address object  90  of  FIG. 4 )   Call queue manager  58  (see  FIG. 4 )   Routing manager  54  (see  FIGS. 2 and 4 ) ACD call model  60  and telephony media platform  150 .
 
The timeline of  FIG. 8  begins with a call ready to route message  182 , which is also the final message of the time line of  FIG. 7 . In response to this message the routing manager  54  gets the next available agent from the agent queue (message  184 ), get the call from the call queue (message  186 ) and then instruct the ACD call model  60  to implement the connection. More specifically, the routing manager  54  sends a message to the ACD call model which causes the agent to be connected to the call object (see  FIG. 6D ). The incoming caller is presumed to already be attached to the call object in this example, as was illustrated in the sequence of  FIGS. 6A–6D . In  FIG. 8  the actual connection of the call is signified by an event message  190 , which is sent from the telephony/media platform  150  to the call model. Thereafter, a cascade of messages are sent to tell the agent queue manager  56  that the selected agent is now handling the call and should therefore be removed from the queue. When the call ends, a similar message  200  is sent, causing the agent to be placed back in the queue.
       
     FIG. 9  shows a similar sequence of events that would occur when an agent is available to take a new call. In this case, a sequence of messages  202  are sent between the agent queue manager  56  and the ACD address and agent queues  180  prior to notifying the routing manager  54  that an agent is available to take the call (message  204 ). Thereafter, the exchange of messages is similar to that illustrated in  FIG. 8 . 
   Distributed Service Logic Programs (SLP) 
   There are various kinds of service logic programs (SLPs). The common feature of a SLP is that it can be created in any development tools and compiled into a software components that can be loaded and run in a host machine with a standard XML interface that defines the following typed interface:
         1. The SLP can be located anywhere in the internet. It has a URL and a property set describing the following properties.   2. SLP has a shared object service interface defining an event-condition-action table that can be dynamically updated. The interface can point to
           a. All the call object information dynamically created by the call processing system.   b. All the context information collected from the user or the system during the course of the call.   
           3. A GUI component that support the provisioning of the SLP parameters. The GUI component support the remote update of the SLP. It also support the tracking of SLPs that has been used by other entities. When there is a change to the SLP the other entities may be notified if the entity “subscribed to or is using the SLP”.   4. A set of system service interface for making calls, collect user information, and play media to the users.   5. A set of declarative rules or procedure based program that can communicate with external programs using structured messages such as XML.   6. SLP can be loaded and dynamically link to the SLP execution engine to implement the application logic.   7. SLP can be dynamically associated with an addressable entities. The association allows a call processing program to locate the reference to the SLP from the addressable entity. It also allows the SLP to find the call processing program from the addressable entities. It is assumed that the call processing entity has a reference to the addressable entities.       

   The dynamic loading of SLP is accomplished by a web based hyperlink dictionary (WHD). WHD keeps the location of SLPs that is used by the applications and has the knowledge of how to locate SLP. 
   Web-Centric Hyperlink Dictionary (WHD) 
   Conventional database systems provide data sharing capability for users to define and manipulate corporate information. Current Internet provides browsers and HTTP servers for sharing Web pages and common gateway interface programs. The scope of information sharing was extended to Web page sharing. In such an environment, the internet becomes the common protocol for distributed machines (IP terminals and Servers). On top of the IP protocols, HTTP becomes the most common protocol that is used by internet communities. Many of the new generation tools are transformed from enterprise or departmental centric computing environment to a totally distributed Web-centric environment. 
   Many vendors provide a Web-enabled wrapper over database systems to take advantage of the Web. However, these approaches are not suitable for truly distributed multimedia applications where users are basically distributed over Internet domains separated by firewalls. There are no easy and low cost methods to deliver information between users if the information is stored in conventional databases. Furthermore, because conventional databases use data storage and transport protocols developed before the invention of HTML and XML, a substantial amount of translation is needed to support multimedia display, encoding and storage. Refer to  FIG. 10  for a depiction of how conventional databases use data storage and transport protocols. 
   Based on the above observation, we propose a Web-centric data management scheme to support distributed internet multimedia applications. Illustrated in  FIG. 11 , the main function to be provided is a meta-database call Web Hyperlink Dictionary (WHD) that manages URLs and properties of the URL for multimedia objects. The WHD can provide efficient search and update capability to various HTML and XML encoded information. Furthermore, the WHD can provide direct manipulation of controllable internet appliances such as camera, telephone, and switches. WHD maintains all the control and linkage information needed to support the interactive ‘message based’ information exchange between active programs (agents) running in different machines either as client or as server. 
   Using the WHD, the WCC system support a unified contact center operation. For example, when a call, chat or email goes to the ACD system, ACD will check the service logic based on the destination address input from call, chat or email and system time. The service logic is preloaded to the system from our WHD. If the supervisor or administrator changes the service logic, the new service logic will be saved to WHD and updated information will be passed to whoever are interested in the change through Share Object Service. If the destination address does not have a service logic program associated with, ACD system will connect the signal with destination address such as call queue, email system, music and video. If the destination address has service logic, the ACD system will continue to execute the service logic until reach to end of points. 
   Unlike prior systems, the system of the present invention advantageously unifies the following entities:
         1. Multimedia message types: Chat, Web page, Form, Voice, and Video.   2. Virtual addressable entities: An addressable entities that can be an user, agent, supervisor, manager, administrator, group, department, company, and communities are all modeled as a virtual group of different size and can be linked in a hyper graph. The graph can be cyclic.   3. Unified contact rules: Time, space, preference, performance, security, and other routing control parameters are modeled as SLP and SLP is distributed by virtual groups. It can be based on any user definable rules for routing. For example, users can define the rules based upon the time when the message is received. Users can construct hierarchical addressable entities and specify business rules using SLP. The multimedia messages can be routed through the SLP hierarchy.   4. The rules can be defined interactively through user friendly user interface from any where any time. The modification of the rule can be verified and propagated to distributed locations where WCC is deployed to.       

   To better understand the capabilities of the present invention, the following will present examples of SLPs in use. Refer to  FIG. 12  when considering these examples. 
   Examples of SLP: 
   
       
       
         
           1. Multimedia Customer Interaction (MCI) SLP. The MCI SLP connects to a caller when all the agents are busy. The MCI SLP can collect the user input from an instant messaging channel, voice channel, and data channel. The MCI SLP can push Web pages, input form, video link, and other Web content to the caller. For example, a simple pseudo code of the script can be: “if the all agent is busy, play music at URL c:\\imaserver\\wav\\music 1 .wav” for the call.” And “If the all agent is busy, display message “All agents are busy now” for the Instant Message.” 
           2. Multi-level Call Routing SLP: The MCR SLP can route the call based on the information collected from the MCI SLP. The MCR SLP can route the call to next MCR SLP based on a set of rules specified in a set of executable software component linked by a script language. SLP can execute sequentially or in parallel. 
           3. Personal Assistance SLP: PA SLP supports advanced call control features such as routing calls based on contents of shopping cards or user input questions. PS SLP also provide the linkage to connect to external data and knowledge base to assist the agent in supporting and customers. 
         
       
     
  
   
     
       
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
             
           
             
           
         
             
                 
             
           
           
             
               The XML representation listed in the following are for 
             
             
               illustration purposes. 
             
             
               &lt;?xml version=“1.0”?&gt; 
             
             
               &lt;!DOCTYPE entity SYSTEM ‘http://127.0.0.1/whddir/slp/dtd/Entity.dtd’&gt; 
             
             
               &lt;entity id=“playMessage”xmlns:xlink=“http://www.w3.org/1999/xlink”&gt; 
             
             
                &lt;schema idref=“SlpPlayMessageSchema” 
             
             
               xlink:href=“/slp/acdslp/schema/SlpPlayMessageSchema.xml”/&gt; 
             
             
                &lt;property name=“handleLink” value=“playMessage”/&gt; 
             
             
                &lt;property name=“errorLink” value=“playMessage”/&gt; 
             
             
                &lt;property name=“message” value=“All agents are busy now”/&gt; 
             
             
                &lt;property name=“messageURI” 
             
             
                value=“c:\\imaserver\\wav\\music1.wav”/&gt; 
             
             
                &lt;property name=“interval” value=“20”/&gt; 
             
             
                &lt;property name=“duration” value=“20”/&gt; 
             
             
                &lt;property name=“repeat” value=“1”/&gt; 
             
             
               &lt;/entity&gt; 
             
             
               Record the user&#39;s input 
             
             
               &lt;?xml version =“1.0”?&gt; 
             
             
               &lt;!DOCTYPE entity SYSTEM 
             
             
               ‘http://192.168.1.113/whddir/slp/dtd/Entity.dtd’&gt; 
             
             
               &lt;entity id=“recordMessage61” 
             
             
               xmlns:xlink=“http://www.w3.org/1999/xlink”&gt; 
             
             
                &lt;schema idref=“RecordMessageSchema” 
             
             
               xlink:href=“/slp/ivr/schema/RecordMessageSchema.xml”/&gt; 
             
             
                &lt;property name=“handleLink” value=“disconnectCall61”/&gt; 
             
             
                &lt;property name=“errorLink” value=“slp_engine_stop”/&gt; 
             
             
                &lt;property name=“fileURI” value=“/whddir/slp/ivr/test6/rec61”/&gt; 
             
             
                &lt;property name=“duration” value=“60”/&gt; 
             
             
                &lt;property name=“signal” value=“#”/&gt; 
             
             
               &lt;/entity&gt; 
             
             
               Routing based on different media channel such voice, web and 
             
             
               instant message 
             
             
               &lt;?xml version =“1.0”?&gt; 
             
             
               &lt;!DOCTYPE entity SYSTEM 
             
             
               ‘http://192.168.1.113/whddir/slp/dtd/Entity.dtd’&gt; 
             
             
               &lt;entity id=“chooseMenuItemRoot9” 
             
             
               xmlns:xlink=“http://www.w3.org/1999/xlink”&gt; 
             
             
                &lt;schema idref=“ChooseMenuItemSchema” 
             
             
               xlink:href=“/slp/ivr/schema/ChooseMenuItemSchema.xml”/&gt; 
             
             
                &lt;property name=“unhandleLink” value=“playErrorMessage91”/&gt; 
             
             
                &lt;property name=“errorLink” value=“slp_engine_stop”/&gt; 
             
             
                &lt;property name=“timeoutLink” value=“playTimeoutMessage91”/&gt; 
             
             
                &lt;property name=“DTMF1Link” value=“collectInput91”/&gt; 
             
             
                &lt;property name=“WebLink” value=“collectUserWebInput”/&gt; 
             
             
                &lt;property name=“InstantMessage” value=“collectUserIMInput”/&gt; 
             
             
                &lt;property name=“timeout” value=“20”/&gt; 
             
             
                &lt;property name=“mscStreamURIs” 
             
             
               value=“/whddir/slp/ivr/Voice/rootMenu9.wav”/&gt; 
             
             
                &lt;property name=“IMmscStreamURIs” 
             
             
               value=“/whddir/slp/ivr/IM/rootMenu9.wav”/&gt; 
             
             
               &lt;/entity&gt; 
             
             
               Collect digits from Phone 
             
             
               &lt;?xml version =“1.0”?&gt; 
             
             
               &lt;!DOCTYPE entity SYSTEM 
             
             
               ‘http://192.168.1.113/whddir/slp/dtd/Entity.dtd’&gt; 
             
             
               &lt;entity id=“collectInput51” 
             
             
               xmlns:xlink=“http://www.w3.org/1999/xlink”&gt; 
             
             
                &lt;schema           idref=“CollectInputSchema” 
             
             
               xlink:href=“/slp/ivr/schema/CollectInputSchema.xml”/&gt; 
             
             
                &lt;property name=“handleLink” value=“disconnectCall51”/&gt; 
             
             
                &lt;property name=“unhandleLink” value=“playErrorMessage51”/&gt; 
             
             
                &lt;property name=“errorLink” value=“slp_engine_stop”/&gt; 
             
             
                &lt;property name=“timeoutLink” value=“playTimeoutMessage51”/&gt; 
             
             
                &lt;property name=“mscStreamURIs” 
             
             
               value=“/whddir/slp/ivr/test5/msg51.wav”/&gt; 
             
             
                &lt;property name=“initialTimeout” value=“10”/&gt; 
             
             
                &lt;property name=“interSigTimeout” value=“10”/&gt; 
             
             
                &lt;property name=“lastDigit” value=“0”/&gt; 
             
             
                &lt;property name=“maxLength” value=“9”/&gt; 
             
             
                &lt;property name=“field” value=“SSN”/&gt; 
             
             
               &lt;/entity&gt; 
             
             
               Schema for SLP play message 
             
             
               &lt;?xml version=“1.0”?&gt; 
             
             
               &lt;!DOCTYPE taskSchema SYSTEM 
             
             
               ‘http://127.0.0.1/whddir/slp/dtd/TaskSchema.dtd’&gt; 
             
             
               &lt;taskSchema&gt; 
             
             
                &lt;description&gt; 
             
           
        
         
             
                 
               &lt;abstract&gt;Play the message to customer&lt;/abstract&gt; 
             
             
                 
               &lt;licence href=“licence, html”/&gt; 
             
             
                 
               &lt;servletCondition&gt;2.1&lt;/servletCondition&gt; 
             
             
                 
               &lt;jspCondition&gt;1.1&lt;/jspCondition&gt; 
             
             
                 
               &lt;jvmCondition&gt;1.2&lt;/jvmCondition&gt; 
             
             
                 
               &lt;preCondition&gt; 
             
             
                 
               &lt;/preCondition&gt; 
             
             
                 
               &lt;postCondition&gt; 
             
             
                 
               &lt;/postCondition&gt; 
             
             
                 
                &lt;/description&gt; 
             
             
                 
                &lt;entitySchema&gt; 
             
             
                 
               &lt;bean 
             
           
        
         
             
                 
               class=“ima.wacd.SLP.bean.SendMessage”/&gt; 
             
           
        
         
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“handleLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“required” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“errorLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“required” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“message” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“messageURI” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“interval” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               fieid=“duration” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“repeat” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
                &lt;/entitySchema&gt; 
             
             
                 
               &lt;/taskSchema&gt; 
             
             
                 
               Schema for routing to different media channel 
             
             
                 
               &lt;?xml version=“1.0”?&gt; 
             
             
                 
               &lt;!DOCTYPE taskSchema SYSTEM 
             
             
                 
               ‘http://192.168.1.113/whddir/slp/dtd/TaskSchema.dtd’&gt; 
             
             
                 
               &lt;taskSchema&gt; 
             
             
                 
                &lt;description&gt; 
             
             
                 
               &lt;abstract&gt;Play a menu prompt, then take the branch based on user 
             
             
                 
               selection&lt;/abstract&gt; 
             
             
                 
               &lt;licence href=“licence.html”/&gt; 
             
             
                 
               &lt;servletCondition&gt;2.1&lt;/servletCondition&gt; 
             
             
                 
               &lt;jspCondition&gt;1.1&lt;/jspCondition&gt; 
             
             
                 
               &lt;jvmCondition&gt;1.2&lt;/jvmCondition&gt; 
             
             
                 
               &lt;preCondition&gt;&lt;/preCondition&gt; 
             
             
                 
               &lt;postCondition&gt;&lt;/postCondition&gt; 
             
             
                 
                &lt;/description&gt; 
             
             
                 
                &lt;entitySchema&gt; 
             
             
                 
               &lt;bean 
             
           
        
         
             
                 
               class=“ima.ivr.ChooseMenuItem”/&gt; 
             
           
        
         
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“errorLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“required” 
             
             
                 
               isBeanField=“true”&gt; 
             
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
             
                 
               field=“unhandleLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“required” 
             
             
                 
               isBean Field=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“timeoutLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“required” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“loopbackLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“maxLoopbacks” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBean Field=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“mscStreamURIs” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“required” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“timeout” 
             
             
                 
               role=“data” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“DTMF0Link” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“DTMF1Link” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“DTMF2Link” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               . . .  
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“DTMFStarLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“DTMFHashLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“WebLink” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
             
                 
               &lt;constrain 
             
           
        
         
             
                 
               field=“InstantMessage” 
             
             
                 
               role=“link” 
             
             
                 
               type=“string” 
             
             
                 
               availability=“implied” 
             
             
                 
               isBeanField=“true”&gt; 
             
           
        
         
             
                 
               &lt;/constrain&gt; 
             
           
        
         
             
                &lt;/entitySchema&gt; 
             
             
               &lt;/taskSchema&gt; 
             
             
                 
             
           
        
       
     
   
   From the foregoing it will be appreciated that the invention may be implemented as an object-oriented, agent-based server system. Although the presently preferred embodiments employ object oriented technology, the invention can be implemented in other ways without departing from the spirit of the invention as set forth in the appended claims.