Abstract:
The invention provides a method and system for indefinitely queuing telephone calls in a call center independent of the telephone instrument deployed in the call center. The system includes a plurality of call center telephones, an Automatic Call Distributor (ACD) connected to the call center agent telephones and a Computer-Telephony Integration (CTI) link connected with a multi-call handling (MCH) server having multiple call handling (MCH) application and a data repository. Call center technicians create a first new route point and a second new route point in the ACD using the ACD&#39;s configuration program. A client application running on the MCH server monitors telephone calls to the plurality of call center agent telephones through the CTI link. In response to a command from the client application of a call queue request for a call on a particular agent telephone, the MCH application running on the MCH server creates an index for the call, sets a timer for a duration less than the default call timeout period for the ACD, and directs the ACD to transfer the call in the first new route point. Prior to expiration of the default timeout period, the MCH application directs the ACD to transfer the call to the second new route point. The data repository retains the index for each call processed by the MCH application. Storing the unique index for each call allows the MCH application to keep track of each call and enable the MCH application to retrieve a particular call, providing the agent with the ability to selectively retrieve or discard parked calls. The invention is also applicable to robotic call servicing applications that need to park calls and retrieve them. In such embodiments, the MCH application receives instructions from the robotic application rather than the client application.

Description:
TECHNICAL FIELD 
     The invention relates generally to telephone call centers and more particularly to providing call center agents with the ability to handle multiple calls independent of the type of telephone set deployed at their workstations and to provide applications external to an automatic call distributor with the ability to queue calls without a practical limit on the number of calls queued. 
     BACKGROUND OF THE INVENTION 
     A typical call center includes a number of agents who field inbound telephone calls and place outbound telephone calls. The agent may place outbound sales calls or field inbound calls (such as 800 numbers) from potential customers. The agents are organized into groups, known as Skill/Split Hunt Groups. 
     A conventional call center typically comprises either an Automatic Call Distributor (ACD) or Personal Branch Exchange (PBX) which receives incoming calls through a Public Switched Telephone Network (PSTN) and routes the calls to a group of ACD agents having like skills, also known as an ACD Skill/Split Hunt Group, rather than to a specific agent. An ACD typically contains a superset of the functions provided by a PBX. Specialized telephones, known as ACD/PBX feature phones, interface with a specific manufacturer&#39;s ACD/PBX and provide the agents with an array of advanced telephony functions. ACD/PBX feature phones typically have configurable buttons for handling multiple calls. ACD/PBX feature phones often provide agents with the ability to handle multiple calls on a single telephone line, known as “multiple call appearances.” ACD/PBX feature phones may also provide agents with the ability to handle calls from multiple telephone lines on a single telephone instrument, known as “multiple line appearances.” Generally, if an agent only requires the ability to juggle multiple calls, he will have multiple call appearance buttons on his ACD/PBX feature phone. If the agent requires different phone lines for different business functions, then the agent will have on his ACD/PBX feature phone. An ACD/PBX feature phone may provide functions for both multiple call and line appearances. 
     In recent years, call center telephony has begun moving from proprietary ACD/PBX feature phones designed for a specific ACD/PBX to software-controlled telephony applications (Softphones) that can either co-exist with a proprietary ACD/PBX feature phone or can utilize telephone sets not necessarily designed for any particular ACD/PBX. A call center equipped with ACD/PBX proprietary feature phones typically costs three to four times as much as a call center equipped with Softphones associated with a non-proprietary phone. A conventional ACD/PBX call center requires not only a proprietary ACD/PBX feature phone, but also requires ACD/PBX interface line cards utilizing a proprietary protocol. Softphones provide a less expensive means for attaining many of the capabilities of an ACD/PBX feature phone while using only software in combination with a “plain-old-telephone set” (POTS) and an associated and less expensive line card. A Softphone call center equipped with POTSs is considerably less expensive to establish and to maintain with the latest upgrades than a call center configured with ACD/PBX feature phones. A Softphone has the added advantage that persons who are not permanent call center agents may be provisioned with call center telephone capabilities without the need for an expensive upgrade to an ACD/PBX feature phone. This feature may be especially attractive for seasonal businesses. Additionally, if a business replaces its ACD/PBX for a different manufacturer&#39;s model, it is likely that this business can retain their Softphone applications without modification. 
     The software-controlled application that drives a Softphone call center generally provides the agent with a graphical user interface (GUI) that replaces the function control buttons on an ACD/PBX feature phone used by the agent to control telephony functions. While interacting with a caller over the Softphone, the agent uses hot keys or an electronic mouse to select telephony functions on a workstation screen. A hot key is a keystroke or combination of keystrokes that sends a command to the computing system that provides the Softphone capability. Softphone telephony features emulate the feature buttons on an ACD/PBX feature phone and are supported via a Computer-Telephony Integration (CTI) link to the ACD or PBX. The CTI link allows the Softphone system to control telephone call handling operations in the ACD/PBX such as answering a call, making a call, transferring a call, and making a conference call, by sending requests and receiving event messages over the CTI link. An event message is an action or occurrence to which the Softphone may respond. Software client/server CTI Middleware products interface to the ACD/PBX proprietary CTI link and simplify the application programming interface (API) needed by the Softphone to communicate with the ACD/PBX. 
     FIG. 1 illustrates a conventional Softphone-configured call center. In this Softphone call center, an ACD  102  interfaces between client telephone calls  100  and agents  108   a  at an agent workstation  108 . The clients typically place telephone calls to the agents  108   a  via a Public Switched Telephone Network (PSTN). When a client telephone call  100  arrives at the ACD  102 , the call is received by an ACD route point  103 . PSTN calls are generally forwarded to a group of ACD agents  108   a  having like skills (the ACD Skill/Split Hunt Group) rather than to a specific one of the agents. The ACD  102  routes incoming calls through the ACD route point  103  which typically comprises a phone number in the numbering plan of the ACD  102  that works in conjunction with a call handling instructions script, referred to as a routing program  104 . An ACD object  105  controls the routing program  104  to enable customized call processing specifications in the ACD  102 . The routing program  104  tells the ACD&#39;s call processing software how to treat the client&#39;s call  100 . The routing program  104  typically includes at least one announcement and at least one queue statement. The queue statement directs the call to a specific ACD Skill/Split Hunt Group  106 . The ACD Skill/Split Hunt Group  106  has a single phone number, a Pilot Directory Number (Pilot DN)  107  that subsequently directs the client telephone call directly to one of the available agents  108   a  within the ACD Skill/Split Hunt Group  106 . 
     As shown in FIG. 1, the ACD  102  may have multiple route points  103 , multiple routing programs  104 , multiple ACD objects  105 , and multiple ACD Skill/Split Hunt Groups  106 . The discussion provided herein generally refers to a single set of ACD elements for ease of understanding, as the operations of multiple ACD elements may be extrapolated from the description of the operation of a single set of such elements. 
     Each agent workstation  108  has a telephone that receives calls directed to either of two numbers. The first number is the phone number for the telephone instrument itself at the agent workstation  108 , or the Phone Directory Number (Phone DN). The second number is a phone number corresponding to the agent  108   a , i.e., an Agent Directory Number (Agent DN). The Agent DN follows an individual call center agent. Thus, the agent  108   a  may switch from one agent workstation  108  to another agent workstation  108  and still retain the same Agent DN. If the agent  108   a  is not working on a particular day, or has not otherwise logged into the call center, then the Agent DN will not be active, and a party calling the Agent DN will receive a message to this effect. 
     A Call Control application server  110  communicates with the ACD  102  through a Computer Telephony Integration (CTI) link  109 . The Call Control application server  110  comprises a standard computing system, such as a PC, and a CTI server application which processes calling information for various agents  108   a  via their associated Softphone applications  111 . Each agent  108   a  typically has a terminal that provides a graphical user interface to the Softphone application  111 . The Softphone application  111  emulates many of the button functions of an ACD/PBX feature phone. For example, an agent  108   a  places a call on hold by using a hot key on the application  111 . Engaging the hot key causes the application  111  to send a command through the CTI link  109  to direct the ACD  102  to place the call in a holding state. Most CTI links support call hold of a single call, even in a Softphone system. 
     The Call Control application server  110  synchronizes the Softphone application  111  with the ACD  102  by sending event messages to the Softphone application  111  pertaining to the set of Agent DNs and Phone DNs that have been provided with the Softphone capability. The Call Control application server  110  services telephony commands from the Softphone application  111  to provide the agent  108   a  with a Softphone. In a typical configuration, each agent  108   a  has access to an individual copy of the Softphone application  111  at his or her workstation  108 . The Softphone application  111  servicing each agent workstation  108  may be run from the Call Control application server  110 , for example, in an internet browser-based implementation. The combination of the agent workstation  108  utilizing a POTS and the Softphone application  111  provides the agent  108   a  with many of the features available on more expensive ACD/PBX feature phones. 
     In a Softphone-equipped call center, such as the call center shown in FIG. 1, a client call  100  may reach an individual agent  108   a  in several different ways. The client call  100  may reach the agent  108   a  through the ACD route point  103 . This method of calling does not necessarily reach a specific agent  108   a  but instead reaches any available agent  108   a  in the ACD Skill/Split Hunt Group  106 . This method provides general calling but is unsuitable for reaching a specific one of the agents  108   a . A client call  100  may reach a specific agent  108   a  by placing a phone call to the Phone DN at the agent&#39;s workstation  108 . This method directs the call to a specific telephone instrument, whether the agent  108   a  is present or not. This method is often unfruitful for contacting a specific agent  108   a  because the agent may have moved to another workstation  108 , may be busy on another call, or may not otherwise be available. As more than one agent frequently occupies the same physical workstation associated with a Phone DN, call center management may also prefer that incoming calls not be routed through the Phone DN to avoid slowing the productivity of other call center agents who may answer calls directed to their Phone DNs that were intended for the call center agent who previously occupied that particular Phone DN. In another approach, the client call  100  reaches the agent  108   a  by using the Agent DN. This method allows the call to follow the agent  108   a  to the actual telephone instrument presently being used by the agent. The Agent DN constitutes a personal phone number for the agent  108   a  and returns a busy signal if the agent  108   a  is not logged into the ACD  102 . The Agent DN connects the call to the agent  108   a  if the agent is available when the call arrives. If the agent  108   a  is busy on another call, the caller hears a ringback tone until the agent is free. The ACD  102  typically generates an audible prompt which the agent  108   a  hears while on the other call. The agent  108   a  only hears the audible prompt when a call arrives at the workstation  108  from the Agent DN or the Phone DN. If no agent  108   a  is available in the ACD Skill/Split Hunt Group  106  when a call arrives, the ACD  102  simply queues the call, and the agent  108   a  hears nothing (because the call is not actually waiting for any particular agent). In some call centers, the ACD  102  may direct a light to flash at the agent workstation  108  when a call arrives through an Agent DN. The typical CTI link  109  does not provide an event message notifying a CTI-enabled application, such as the Softphone application  111 , about the waiting call. 
     Not all of the features provided in a call center equipped with ACD/PBX feature phones are available in a Softphone call center. For example, call center agents frequently need to handle multiple telephone calls at the same time, such as when an incoming call is directed to their Agent DN while the agent is already speaking with another caller, as discussed above. In addition, call center agents associated with a predictive dialer blending configuration need to park an outbound call associated with the predictive dialer in order for the agent to receive inbound calls. Using an ACD/PBX feature phone, a call center agent may handle multiple calls by creating a queue of calls that the agent may then selectively retrieve. A conventional ACD/PBX feature phone enables multiple call handling for an agent by providing Call Park and Call Pickup functions. Call Park provides an agent with the ability to park a call at a unique parking address, freeing the agent to take other inbound calls waiting in the ACD, make outbound calls, and perform other telephony operations. Call Pickup allows the agent to retrieve a specific call from its unique parking address and then resume the original phone conversation. For some ACDs using ACD/PBX feature phones, the agent can park only one call. For other ACDs, the agent may park a limited number of multiple calls. Depending on the ACD design, these calls may be either in a First-In First-Out (FIFO) queue of parked calls or they each may be at a unique parking address in a queue of parked calls. While parked, a caller typically hears either music, silence, or an appropriate message. Call Hold, another telephony feature, differs from Call Park in that Call Hold only allows an agent to place one phone call in a temporary state. When a caller is placed on hold, no calls waiting in the ACD are routed to the agent, and the agent may only make outgoing calls. 
     Softphone call centers presently have no capability for providing flexible, multiple call handling and queuing operations in a manner independent of the telephone instrument deployed in the call center. For example, the Lucent® Definity G3 ACD allows for one parked call, while the Northern Telecom Meridian ACD provides no Call Park facility via the proprietary ACD CTI link. Also, most Softphone applications are written in reliance upon third party CTI Middleware which serves as a higher level programming language access to the proprietary CTI link. The CTI Middleware generally do not provide for Call Park/Pickup. IBM CallPath, Dialogic CT-Connect and Genesys T-Server are exemplary CTI Middleware products. For this reason, existing Softphone call centers generally do not support the Call Park and Call Pickup functions provided by ACD/PBX feature phone installations. While Call Park and Call Pickup are useful call center features, they are also not typically supported by the CTI link. These features are also not typically supported by third party CTI Middleware, and if supported at all, support only one call per the aforementioned ACD limitation. Thus, even if the ACD/PBX deployed in a call center supports call queuing, call center agents may not be able to use Call Park and Call Pickup because the CTI link or third party CTI Middleware used by their call center does not support these features. 
     A Softphone application&#39;s requirements resemble those of a robotic call processing application. The primary difference is that the Softphone manages calls arriving at a specific Phone DN while a robotic application manages calls arriving at a specific route point DN. FIG. 2 shows a robotic application  211  communicating with the route point  103 . The robotic application  211  may communicate with both the route point  103 , the ACD Skill/Split Hunt Group  106 , and the Agent DN and the Phone DN at the agent&#39;s workstation  108 . Some robotic applications  211  may receive information from callers  100  and may, in some instances, handle a call in a manner much like that of a call center agent  108   a . As robotic technologies grow more sophisticated, robotic applications, such as robot application  211  , may even begin replacing many, or in some instances all call center agents  108   a , and may also replace many ACD capabilities such as those provided by routing programs  104  and ACD Skill/Split Hunt Group  106 . Robotic application  211  can therefore be considered a robotic call center agent having many similar needs to a human call center agent or as a robotic application that replaces many of the aforementioned ACD capabilities. The robotic application  211  may need to park calls and then route them to other agents or to other robotic resources such as an Interactive Voice Response (IVR) or voice mail. Accordingly, robotic applications have a need for similar Call Park/Call Pickup functions to those of a human call center agent. In many instances, robotic applications require capabilities beyond those required by human call center agents, such as handling many more calls than would a human agent. In other words, the robotic application  211  requires the capability to queue calls such that a specific call can be removed out of its order of arrival in comparison to the other queued calls and distributed to a call center resource. A call center resource can be either a call center agent or a call center robotic agent such as an IVR application or a voice mail application. For example, suppose a call arrives from a very high-valued caller  100  and the call needs to be queued in the ACD  102  to wait for an agent  108   a  with a specific set of skills to support this customer. Another example is that of a high value call that arrives at the ACD  102  and is delivered to an agent  108   a  ahead of previously queued calls because the call is associated with a high-valued customer, causing the other calls to continue waiting in a queue for service. A robotic application that supports such capabilities is popularly called “skills based routing” when agent skills are involved and “host based routing” when agent skills are not a criterion. Essentially, the same ACD limitations that thwart Call Park in Softphone applications also prevent robotic applications from providing high-value call distribution capabilities such as skills based routing. These limitations also prevent third parties from building high-value ACD call distribution functionality outside of the ACD without resorting to some form of adjunct hardware solution. Without a capability to queue a large number of calls and retrieve the calls in any order, a third party call routing application must essentially allow the ACD to retain control over the distribution of queued calls. 
     SUMMARY OF THE INVENTION 
     The invention provides a method and system for allowing a call center agent to queue with no practical limit a number of telephone calls indefinitely in a call center, regardless of the type of telephone instrument deployed in the call center. The invention also provides a method and system for allowing a call center robotic application to queue a virtually unlimited number of telephone calls indefinitely in a call center associated with an ACD route point. In the invention, a multiple-call handling (MCH) application in the Call Control application server utilizes one or more call route points within the ACD/PBX to queue agent-selected calls or robotic application-selected calls. When an agent, or robot application, indicates that a call should be queued, the MCH application in the Call Control application server instructs the ACD/PBX to transfer the call to a route point, which effectively provides a queue. If the ACD/PBX has a default routing timeout period for unassigned calls, then the MCH application instructs the ACD/PBX to transfer the queued call to a second route point in the ACD/PBX before the default routing occurs. If another default routing time period nears expiration while the call is still queued, then the MCH application in the Call Control application server instructs the ACD/PBX to transfer the call back to the first route point. The MCH application maintains a database of queued call records for locating specific queued calls, such as when an agent (or robot application) wishes to retrieve a queued call. The process of juggling a call from route point to route point may be continued indefinitely, although the invention further permits the setting of a maximum queuing period. Juggling calls from one route point to another avoids the default timeout mechanism for unassigned calls in many ACD/PBXs as well as limitations in the number of calls that can be queued at a route point. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     A preferred embodiment of the present invention will be described below relative to the following figures. Note that similar elements and steps in the figures have the same reference number. 
     FIG. 1 illustrates a conventional Softphone-configured call center. 
     FIG. 2 illustrates a conventional call center having a robotic call processing application 
     FIG. 3 depicts a call center configured for the Softphone environment provided by one embodiment of the present invention. 
     FIGS. 4A and 4B provide a flowchart illustrating multiple call handling according to an exemplary embodiment of the invention. 
     FIG. 5 illustrates commands and messages related to multiple call handling, according to one embodiment of the invention. 
     FIG. 6 provides additional description of the commands and messages that are sent between the various call center components of the one embodiment of the invention to provide multiple call handling. 
     FIG. 7 illustrates a typical display provided by an exemplary user interface of the invention to an agent, such as the agent of FIG.  3 . The user interface shows the calls that the agent has parked in the ACD/PBX which the agent may retrieve on an individual basis in any order. 
     FIG. 8 illustrates an embodiment of the invention in which a robotic call processing application may also direct calls to be queued in the new route points. 
     FIG. 9 illustrates one alternative embodiment of the present invention. 
     FIG. 10 illustrates yet another alternative embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The invention provides multiple call handling for each agent in a call center regardless of the telephone instrument at the agent&#39;s workstation. The invention also provides call queuing at each agent telephone in the call center with no practical limit on the number of calls queued. The invention further provides agent workstations with Call Park and Call Pickup functions through a computer program operating in conjunction with a Call Control system. The invention provides these features for call centers whether equipped with the ACD/PBX manufacturer&#39;s proprietary feature phones, Plain Old Telephone Sets (POTS), or ACD/PBX feature phones from a different manufacturer than the manufacturer of the call center&#39;s ACD/PBX. The invention further provides multiple call queuing via a CTI link even if the ACD/PBX and/or the CTI link and/or third party CTI Middleware do not provide this capability themselves. The invention provides call queuing and queued call retrieval for multiple calls at each agent&#39;s workstation, wherein each call has a unique address that allows the agent to select a particular queued call for retrieval, regardless of the order in which the calls were queued. 
     The invention further provides multiple call handling for each robotic application associated with a route point. The invention also provides call queuing at each route point in the call center with no practical limit on the number of calls queued. The invention further provides robotic applications with Call Park and Call Pickup functions through a computer program operating in conjunction with a Call Control application server. The invention also provides multiple call queuing for calls in robotic applications via a CTI link even if the ACD/PBX and/or the CTI link do not provide this capability themselves. The invention provides call queuing and queued call retrieval for multiple calls at a route point, wherein each call has a unique address that allows the robotic application to select a specific queued call for retrieval, regardless of the order in which the calls were queued. 
     The inventors of the present invention made the key discoveries behind the invention based upon their keen awareness of ACD/PBX design and operations. The inventors first analyzed the following limitations in the typical ACD/PBX. 
     The inventors knew that an ACD/PBX typically limits the number of undirected calls in a call center. An undirected call is a call not directed to an Agent DN or a Phone DN. The Lucent® Definity G3 System, for example, limits the number of undirected calls at any instant to 127. Thus, the inventors realized that their solution would need to minimize the number of call routing associations consumed by undirected queued calls. A typical ACD/PBX strives to direct each call to its ultimate destination, such as to an agent&#39;s telephone. To provide this functionality, the ACD/PBX maintains an open association list for undirected calls. The inventors understood that this list could be externally managed by a software application operating through the CTI link. 
     The inventors further recognized that some ACD/PBX&#39;s have a default routing timeout period that arises for all unrouted calls after a fixed time period. A call assigned to a particular route point will only remain at the route point for a limited period of time before the ACD/PBX automatically reroutes the call. For some ACD/PBXs, this default period may be as long as a minute while for other ACD/PBXs this period can be as short as three to four seconds. The default timeout period for ACD/PBXs represented another ACD/PBX limitation that the inventors knew they would have to overcome for some call center installations. 
     The inventors further recognized many similarities between an ACD/PBX having a Softphone application and a robotic application operating in conjunction with an ACD route point. As an example of the limited capabilities presently accorded robotic applications, a conventional ACD may permit a robotic application to queue calls at the route point in the ACD with which the robotic application is associated. However, some ACDs will allow a call to be queued at a call routing point for only 3-4 seconds, while other ACDs only allow for a limited number of such queued calls, and still other ACDs have limitations on the total number of such queued calls across all robotic applications. In general, an unlimited call queuing capability in full support of such robotic applications is not available in a conventional ACD. For example, the Lucent® Definity G3 allows a robotic application to queue calls for 999 seconds, but has a system-wide limitation for such calls of only 127 calls. The Northern Telecom Meridian ACD allows a robotic application to queue calls for only 3-4 seconds. Upon review of these limitations, the inventors further recognized that with a genuine capability to queue calls in an ACD and to retrieve these calls out-of-order, a third party could build very sophisticated call routing capabilities that far exceeded the capabilities of the ACD as provided by its manufacturer. 
     In deciding how to provide unlimited call queuing in a Softphone call center on a telephone-independent basis, the inventors were also aware that the prior art methods for providing a Call Hold function would be of no assistance to them. The inventors realized that a solution to this problem would require some type of an index linked to the queued call that could be used to distinguish one call from another. A held call in a typical ACD/PBX has no call identifier. Thus, a held call is only associated with either a particular telephone instrument or a particular agent. Moreover, a held call is never completely free of an agent&#39;s phone, as discussed above. Without a call index, multiple calls may not be queued and retrieved for the same agent. 
     The inventors further recognized that an ACD/PBX is a configurable device having control software that allows a variety of call directing devices to be configured to it. Because of the amount of information that must be individually tailored for each call center, ACD/PBXs include configuration tables that are administrated through a device commonly referred to as the ACD maintenance console. As a practical matter, setting up a call center requires entering site-specific information such as the Agent DNs for the agents within the call center and the Phone DNs for the call center telephones. The maintenance console also allows logical functions, like the Agent DNs, to be matched to physical functions, like the Phone DNs. The maintenance console also allows Agent DNs to be assigned to Skill/Split Hunt Groups, and the appropriate calling scripts to be developed for the ACD Skill/Split Hunt Groups. The maintenance console also allows a robot application to be associated with a route point. 
     Thus, the invention results from the inventors&#39; discovery that the configurable software that controls ACD&#39;s and PBX&#39;s may be directed to create an additional route point in the ACD/PBX and that a computer program external to the ACD/PBX can control the additional route point to provide multiple call queuing independent of the particular telephone instrument used in the call center. The inventors knew that this solution would sidestep the typical ACD/PBX&#39;s limitation on the number of undirected calls because placing the calls in a route point would not increase the number of calls in the open association list. 
     The inventors further discovered that the default timeout routing, for those ACD/PBXs having such a limit, could be avoided if a second new route point was created and an external computer program transferred the queued call from the first new route point to the second new route point before the timeout arose. In other words, the inventors discovered that they could direct the configurable software for an ACD/PBX to create a second new route point, and then a computer program external to the ACD/PBX could juggle a queued call back and forth between the new route points to thwart the ACD/PBX&#39;s default routing timeout period. 
     The inventors&#39; first new route point operates as follows. When a newly queued call arrives, the first new route point executes a route request to the external computer program controlling call queuing. The first new route point then waits for a redirection command from the external computer program while providing music or another appropriate message to the caller during the wait. A wait time should be established, such as two seconds, according to the default timeout period of the particular ACD/PBX deployed. If this wait time elapses, then the call is automatically routed for default call treatment, such as being re-queued to an agent Skill/Split Hunt Group. For some ACD/PBX systems, the adjunct routing step must be the first command in the first new route point and must be performed without any delay. Providing instructions in the first new route point for default call treatment provides a mechanism for disposing of queued calls in the event of a system failure that adversely affects the queuing of calls. For example, should the external computer program handling call queuing fail, the default call treatment will eventually empty the new route point of all queued calls. However, in the normal case, the computer program will send a call routing instruction to the new route point directing the newly queued call to another location prior to the expiration of the default timeout period. 
     The second new route point should be designed to perform as follows. First, the second new route point executes a waiting period of a few seconds with an optional treatment, such as providing music or another message. When the waiting period has elapsed, the call is routed back to the first new route point. 
     The inventors created an external computer program that monitors and controls queued calls in the new route points by sending messages through the CTI link. As discussed above, for those ACD/PBXs having a default timeout for undirected and/or unrouted calls, the external computer program avoids the default routing by rerouting a call from one new route point to another new route point prior to the expiration of the default timeout period. The external computer program also sends commands through the CTI link which enables selective dequeuing of calls as well as other instructions to the route points. 
     As discussed above, creating new route points in the ACD/PBX is a key step in performing one embodiment of the invention. Presently, ACDs and PBXs do not have standardized designs. Thus, creating the new route points requires knowledge of the design of the ACD or PBX used in the call center. A skilled artisan in the ACD/PBX arts is typically charged with such knowledge. However, to provide the fullest possible disclosure, a description will be provided below describing how to provide the new route points in one particular ACD. While this disclosure pertains to one particular ACD, the general principles of the invention pertain to all ACD/PBXs. 
     The following four tables describe the configuration of the two new route points for a specific ACD, the Lucent® Definity G3 switch (the Definity switch). The tables below appear as they would using the display capability provided by the Definity administration console. Lucent® terminology has been used in this description, and any terms not familiar to the skilled artisan may be referenced in the appropriate Lucent® technical literature. In a Definity switch, an ACD Vector is called a Vector Directory Number (VDN) and its associated script is called a Vector. The new route points needed for this embodiment of the invention consist of an ACD Vector (such as the ACD vector  105  shown in FIG. 1) and an associated Vector script (such as the vector script  104  shown in FIG.  1 ). 
     A first new route point has the name “First New Route Point” and consists of the VDN 20416, shown below in Table I. VDN 20416 invokes an associated program contained in Vector Number 43, shown below in Table II. While all of the settings in Table II are important, the programming steps contain the decision logic for holding a call and disposing of a call. The first step, “Step 01 (adjunct),” instructs the Vector program to send a notification of a call&#39;s arrival to the ACD CTI routing link 24187 when the call arrives. (Note: A multiple call handling (MCH) application, such as the MCH application 316 to be discussed with regard to FIG. 3 listens for these notifications.) The second step, “Step 02 (route-to),” instructs the Vector program to hold the call for 6 seconds while waiting for a response from the MCH application. The third step, “Step 03 (disconnect),” instructs the Vector program to disconnect the call without playing an announcement if the call is not routed by the MCH application within 6 seconds. 
     
       
         
               
             
               
               
               
             
           
               
                 TABLE I 
               
               
                   
               
               
                 Exemplary Definity VDN for First New Route Point 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 Extension: 
                 20416 
               
               
                   
                 Name: 
                 First New Route Point 
               
               
                   
                 Allow VDN Override? 
                 N 
               
               
                   
                 COR: 
                  1 
               
               
                   
                 TN: 
                  1 
               
               
                   
                 Vector Number: 
                 43 
               
               
                   
                 Measured: 
                 none 
               
               
                   
                 1 st  Skill: 
               
               
                   
                 2 nd  Skill: 
               
               
                   
                 3 rd  Skill: 
               
               
                   
                   
               
             
          
         
       
     
     
       
         
               
             
               
               
               
             
               
               
               
               
               
             
           
               
                 TABLE II 
               
             
             
               
                   
               
               
                 Exemplary Definity Vector for First New Route Point 
               
             
          
           
               
                 Vector 
                   
                   
               
               
                 Number: 43 
                 Name: First Park Vector 
               
               
                   
               
             
          
           
               
                 Basic? Y 
                 EAS? Y 
                 G3V4 
                 ANI/II- 
                 ASAI Routing? Y 
               
               
                   
                   
                 Enhanced? Y 
                 Digits? Y 
               
               
                 Prompting? Y 
                 LAI? Y 
                 G3V4 Adv 
                 INFO? N 
               
               
                   
                   
                 Route? Y 
               
               
                 01 adjunct 
                 routing link 24187 
               
               
                 02 route-to 
                 6 secs hearing ringback 
               
               
                 03 disconnect 
                 after announcement 
               
               
                   
                 none 
               
               
                 04 
               
               
                 05 
               
               
                 06 
               
               
                 07 
               
               
                 08 
               
               
                 09 
               
               
                 10 
               
               
                 11 
               
               
                   
               
             
          
         
       
     
     A second new route point has the name “Second New Route Point” and consists of the VDN 20415, shown below in Table III. VDN 20415 invokes an associated program contained in Vector Number 45, shown below in Table IV. While all of the settings in Table IV are important, the programming steps contain the decision logic for holding a call and disposing of a call. The first step, “Step 01 (wait-time),” instructs the Vector program to play a ringback to the calling party for 6 seconds when a call arrives. (Note: this is the normal ringback cycle for the Public Switched Telephone Network (PSTN)). The second step, “Step 02 (route-to),” instructs the Vector program to redirect the call to the First New Route Point. 
     
       
         
               
             
               
               
               
             
           
               
                 TABLE III 
               
               
                   
               
               
                 Exemplary Definity VDN for Second New Route Point 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 Extension: 
                 20415 
               
               
                   
                 Name: 
                 Second New Route Point 
               
               
                   
                 Allow VDN Override? 
                 n 
               
               
                   
                 COR: 
                  1 
               
               
                   
                 TN: 
                  1 
               
               
                   
                 Vector Number: 
                 45 
               
               
                   
                 Measured: 
                 none 
               
               
                   
                 1 st  Skill: 
               
               
                   
                 2 nd  Skill: 
               
               
                   
                 3 rd  Skill: 
               
               
                   
                   
               
             
          
         
       
     
     
       
         
               
             
               
               
               
             
               
               
               
               
               
             
           
               
                 TABLE IV 
               
             
             
               
                   
               
               
                 Exemplary Definity Vector for Second New Route Point 
               
             
          
           
               
                 Vector 
                   
                   
               
               
                 Number: 45 
                 Name: Second Park Vector 
               
               
                   
               
             
          
           
               
                 Basic? Y 
                 EAS? Y 
                 G3V4 Enhanced? Y 
                 ANI/II-Digits? Y 
                 ASAI 
               
               
                   
                   
                   
                   
                 Routing? Y 
               
               
                 Prompting? Y 
                 LAI? Y 
                 G3V4 Adv Route? Y 
                 CINFO? N 
               
               
                 01 wait-time 
                 6 secs hearing 
               
               
                   
                 ringback 
               
               
                 02 route-to 
                 number 20416 
                 with cov n if 
               
               
                   
                   
                 unconditionally 
               
               
                 03 
               
               
                 04 
               
               
                 05 
               
               
                 06 
               
               
                 07 
               
               
                 08 
               
               
                 09 
               
               
                 10 
               
               
                 11 
               
               
                   
               
             
          
         
       
     
     FIG. 3 depicts a call center configured for the Softphone environment provided by one embodiment of the invention. As shown in FIG. 3, the Softphone environment of FIG. 1 has been modified to include the additional functionality needed for an ACD/PBX that has both a limit on the number of undirected calls and a default routing timeout period. The ACD  102  has been modified to include a first new route point  312 , a first new routing program  313 , a second new route point  314 , and a second new routing program  315 . The ACD  102  may be modified to include these additional items in the manner described above, or by any appropriate manner for the particular brand of ACD equipment known to one skilled in the art of ACD/PBX operations and maintenance. As previously discussed, an ACD/PBX has a maintenance console that may be configured for particular calling arrangements and may be used to create new route points such as the first new route point  312  and the second new route point  314 . 
     As shown in FIG. 3, the Call Control application server  110  has been modified to include a multiple call handing (MCH) application  316 , an initialization file  317 , and a call database  318 . The initialization file  317  provides the proper configuration for the MCH application  316  and initializes the call database  318  to receive information from the MCH application. The call database  318  may be any data repository having a sufficient capacity to store all the calling data required of the MCH application  316 . 
     The first new route point  312 , following the instructions in the first new routing program  313 , notifies the MCH application  316  when a queued call arrives at the first new route point. The MCH application  316  then transfers the call to the second new route point  314  prior to the expiration of the ACD default timeout period. If the second new route point  314  still retains the queued call as the ACD default timeout period arrives a second time, then the second new route point  314 , following the instructions in the second new routing program  315 , transfers the call back to the first new route point  312  before the ACD default timeout expires. This process may occur over and over until the call has been queued longer than a configurable time period or until the agent enters a call deliver or call discard message to the Softphone application  111 . Of course, the transfer times set in the route points and in the MCH application  316  must be less than the ACD default timeout in order for the multiple call handling system to work as described. If a call deliver or call discard message arrives from the Softphone application  111 , then the MCH application  316  redirects the call accordingly. 
     The first new route point  312  retains the call for only a brief period of time before the MCH application  316  redirects the call to the second new route point  314  where the call also waits for only a brief time. Queuing the call in the new route points minimizes the number of call routing associations consumed by parked calls. Most ACDs have limitations on the number of undirected calls, which is overcome by these new route points. Using this solution, a given call never has an undirected status for more than a brief instant. Thus, this approach effectively increases by tenfold or more the limit of the ACD  102  for undirected calls. As discussed previously, some ACDs also redirect all unrouted calls after a certain period. The present invention overcomes this limitation within the ACD  102  through the described process of juggling calls back and forth between the first route point  312  and the second route point  314 . 
     The MCH application  316  processes service requests from the Softphone application  111  and event messages from the ACD  102 . These service requests include command messages, call disconnected messages, call redirected messages, and command response messages. The MCH application  316  essentially maintains a thread that services these requests and event messages as they arrive from the Call Control application server  110 . A thread is a process that is part of a larger process or program. 
     The Softphone application  111  queues, or parks, a call on the ACD  102  by transferring the call to the control of the MCH application  316  with an associated “call park” message. The MCH application  316  keeps the queued calls in a perpetual call processing state within the ACD  102  as discussed above although the state is terminable, as desired. The MCH application  316  responds to the call park message from the Softphone application  111  by sending a command through the CTI link  109  that transfers the call to the first new route point  312 , sending a park call response message to the Softphone application  111 , and by making an appropriate entry in the call database  318 . 
     An agent retrieves a parked call by selecting a specific parked call from the graphical user interface on the Softphone application  111 . This action directs the Softphone application  111  to send a call retrieval message to the MCH application  316 . The MCH application  316  responds by redirecting the parked call to the Agent DN of the workstation  108  of the requesting agent. 
     The Softphone application  111  may also direct the MCH application  316  to purge a parked call by sending a “drop call” message. The MCH application  316  responds to the Softphone application  111  with a call discard response and purges the call database  318  of the discarded call. The MCH application  316  redirects a discarded call to the Default DN of the ACD  102 . Thus, the discarded call is not necessarily disconnected from the call center but merely disassociated from a particular agent&#39;s workstation. 
     The MCH application  316  transfers any call for which it has received insufficient information to the timeout route point of the ACD  102  and logs the event in the call database  318 . The log may be forwarded to the Softphone application  111  or examined by the appropriate supervisory personnel. An abundance of such incomplete calls may signal an anomalous condition in the call center or in a particular piece of its equipment, such as the agent workstation  108 . 
     When a parked call is released, the MCH application  316  logs the call to a log file, such as a file called “Callpark.dat.” The information for each released call may include a Unique Call Index, the Agent DN, the Agent Phone DN, the parked time, the released time, and the release status. Depending on how the parked call is released, the released status can be: “delivered,” “discarded,” “caller hung up,” or “parked call timeout.” This log may also be examined by appropriate supervisory personnel to ensure that the multiple call handling system is functioning within expected parameters. 
     The MCH application  316  records the time each call is initially parked in the call database  318 . If a call has been parked longer than a configuration time period, the MCH application  316  redirects the call to the Default DN for the ACD  102 . The configurable time period may be adjusted in the MCH application  316  by appropriate call center supervisory personnel. 
     If a caller hangs up while a call is parked, the CTI link  109  notifies the MCH application  316  of this event through a call disconnected message. The MCH application  316  then sends a call disconnected message to the Softphone application  111 . The Softphone application  111  then notifies the agent  108   a  at the workstation  108  as appropriate. 
     The MCH application  316  provides a console utility for the graphical user interface of the Softphone application  111  to display a list of currently parked calls. The information for each parked call may include a unique call index, the Agent DN, the Agent Phone DN, and the time when the call was parked. FIG. 7 provides additional detail regarding the agent&#39;s user interface for multiple call handling. 
     The MCH application  316  processes several messages while parking and retrieving a call. Prior to parking a call, the Softphone application  111  sends a pre-park message to the MCH application  316 . This message typically has the form “REQUEST_TO_PARK,&lt;My AgentDN&gt;,&lt;My PhoneDN&gt;,&lt;Call Control application server assigned Call Id &gt;.” This message assures the Softphone application  111  that the MCH application  316  is active. Upon receiving the message, the MCH application  316  sends a response to the requesting Softphone application  111  having the format “OKAY_TO_PARK, &lt;AgentDN&gt;,&lt;Agent PhoneDN&gt;,&lt;Unique Call Index&gt;,” where the Unique Call Index is assigned by the MCH application  316 . If the requesting Softphone application  111  does not receive a timely response from the MCH application  316 , the Softphone application  111  makes the agent  108   a  aware that the MCH application  316  is not active and further informs the agent  108   a  that calls may not presently be parked. 
     Upon successful receipt of the “Okay to Park” message, the Softphone application  111  parks the call by sending the command “PARK_CALL, &lt;My AgentDN&gt;,&lt;My PhoneDN&gt;,&lt;Unique Call Index&gt;” to the MCH application  316 . The MCH application  316  then stores the calling information in the call database  318  to be retrieved by the associated Unique Call Index. The unique call index assigned by the MCH application  316  may be unique with respect to all the queued calls in the call center, and not merely unique to a particular agent&#39;s queued calls. Providing each queued call with a globally unique call index simplifies processing in the MCH application  316  because the MCH application  316  may communicate with the new route points using only the unique call index if necessary. In this approach, the Agent DN attached to the call then provides an error correction mechanism since the unique call index and its respective Agent DN should match in the call database  318 . 
     When queuing a call, the MCH application  316  directs the ACD  102 , through the CTI link  109 , to blind transfer the call from the telephone at the agent workstation  108  to the first new route point  312 . A blind transfer is a call transfer in which the transferor indicates a transfer location for a call without checking that the new transferred location is available. For example, in a conventional telephone system, a caller is typically placed on hold, then the transferor dials a phone number and hits a transfer button which initiates an automatic transfer of the call. A blind transfer contrasts with a supervised transfer in which the transferor actually verifies that the transferred number is available before the call is transferred. 
     Recalling the previous example using the Lucent® Definity G3 switch, the basic operation for this embodiment of the invention is as follows. A call enters the first new route point (VDN 20416) and a route request is sent from the ACD  102  to the MCH application  316  shown in FIG.  3 . If the MCH application  316  does not receive a Retrieve Parked Call or Drop Call command from the Softphone application  111  within six seconds, the call is redirected by the MCH application  316  to the second new route point (VDN  20415).  The second new route point introduces a six second wait and then routes the call back to the first new route point (VDN 20416). This process occurs repeatedly until either a Retrieve Parked Call or Drop Call command arrives from the Softphone application  111 . If a Retrieve Parked Call command occurs, the MCH application  316  redirects the call to the Phone DN or Agent DN as specified by the Softphone application  111  in the Retrieve Parked Call command. If a Drop Call command occurs, the MCH application  316  disconnects the specified parked call. 
     The number of undirected calls in the ACD  102  (the limit in the Definity switch is  127 ) only applies to those calls that are momentarily being redirected by the MCH application  316  between the two new route points or to a final destination DN. Queued calls sit in the first new route point with the adjunct route command for only a few hundred milliseconds and then the queued calls sit in the second new route point for 6 seconds. Using this programming, the duty cycle for MCH parking of a call is then approximately: 
     
       
           D =300 milliseconds in first new route point/6000 milliseconds in the second new route point=approximately 0.05 
       
     
     Therefore, each queued call only factors into the undirected call limit 5% of the time. Using a six-second timer in the second new route point allows the MCH application  316  routing association limit of  127  calls in the Definity switch. The timer in the second new route point can be extended to support higher numbers of parked calls. 
     FIGS. 4A and 4B provide a flowchart illustrating multiple call handling according to an exemplary embodiment of the invention. An agent  108   a  at an agent workstation  108  receives a call (step  401 ). The agent then decides to queue the call and makes an appropriate indication to Softphone application  111  (step  402 ). The agent may decide to queue a call for any one of a number of reasons, including an indication that another call is already waiting for him, such as a call sent directly to his Agent DN. 
     In response to the agent&#39;s request to queue a call, the Softphone application  111  determines if the multiple call handling application  316  is presently working (step  403 ). If the multiple call handling application is determined to not be functioning (step  404 ), such as indicated by a failure to respond to the Softphone application&#39;s query, then the Softphone application  111  sends a message to the agent  108   a  informing him that the multiple call handling application is not presently working (step  405 ). If the Softphone application  111  receives an indication that the multiple call handling application is functioning (step  404 ), then the Softphone application  111  sends a queue request to the multiple call handling application  316  (step  406 ). The MCH application applies a unique call index to the call for which call queuing has been requested and stores this calling information in the call database  318  (step  407 ). The MCH application  316  then sends a call queuing command through the CTI link  109  indicating that a blind transfer of the call at the agent&#39;s telephone should be made to the first new route point  312  (step  408 ). 
     If the MCH application  316  does not receive an indication that the call has been received at the first new route point  312  (step  409  of FIG.  4 B), then the MCH application sends an error message to the Softphone application  111  (step  410 ). The Softphone application  111  will then inform the agent in an appropriate manner. If confirmation is received that the call has been queued at the first new route point (step  409 ), then the MCH application  316  updates the call database  318  to indicate that the call has been queued (step  411 ). 
     The MCH application receives and responds to a call retrieval message from the Softphone application  111  (step  412 ). If such a call retrieval message has been received, then the MCH application  316  determines the present location for the requested call according to the call data in the call database  318  (step  413 ). The MCH application then transfers the call to the agent&#39;s telephone (step  414 ). 
     In the absence of a call retrieval message from the Softphone application  111  (step  412 ), the MCH application will transfer a queued call from the first new route point  312  to the second new route point  314  before the default timeout period for the ACD arises (step  415 ). The MCH application  316  will then update the call database  318  to indicate the present location of the queued call (step  416 ). The second new route point  314  will then transfer the call back to the first new route point  312  before the default timeout period arises for a second time (step  417 ). When this occurs, the MCH application  316  will then update the call database  318  to indicate the present location of the queued call (step  418 ). 
     Should a queued caller happen to hang up while the call is queued (step  419 ), then the MCH application  316  will update the call database  318  accordingly and notify the Softphone application  111  (step  420 ). Should a maximum call queuing time arise for a given queued call (step  421 ), then the MCH application will transfer the call to the Default DN for the ACD  102  and update the call database  318  accordingly (step  422 ). The MCH application  316  will also send a notification to the Softphone application  111  that the call has been queued for too long. 
     The process of routing calls between the first and second new route points  312  and  314  will continue until either a call retrieval message is received, the caller hangs up, or the maximum queuing period arises. 
     FIG. 5 illustrates commands and messages related to multiple call handling, according to one embodiment of the invention. As shown in FIG. 5, the Softphone application  111  sends a call park message to the MCH application  316 . The MCH application  316  then blind transfers the call to the first new route point  312  through the CTI link  109 . After the expiration of a predetermined time period less than the ACD&#39;s  102  default routing period for unassigned calls, the MCH application  316  initiates a redirect event that transfers the call to the second new route point  314 , if the call has not been otherwise retrieved by the agent. After a specified period of time less than the default routing period for the ACD  102 , the second new route point  314  then transfers the call back to the first new route point  312 . This process of transferring calls back and forth between the first new route point  312  and the second new route point  314  may reoccur indefinitely until terminated by one of a variety of events. 
     When the call arrives at the first new route point  312 , the MCH application  316  receives a “Call Redirected” message from the ACD  102 . The MCH application  316  associates this message with the other information it already has about the call, such as the Agent DN and a unique index number in the call database  318 . If the command is “Park Call,” the MCH application  316  changes the state of the call from “Park Call” to “Call Queued” and may then redirect the call to the second new route point  314  as discussed. This process effectively queues calls indefinitely for the Softphone application  111  and the call center agents  108   a.    
     FIG. 6 provides additional description of the commands and messages that are sent between the various call center components to provide multiple call handling. As shown in FIG. 6, the MCH application  316  may send the Softphone application  111  the messages Call Discarded, Timed Out, MCH Error, and Call Disconnected. The Softphone application  111  may send the MCH application  316  the commands Park Call, Retrieve Parked Call, and Drop Call. The MCH application  316  may send the second new route point  314  a Redirect command, and the first new route point  312  may send the MCH application  316  a Redirect Event message so that a parked call may be transferred before the end of the default timeout period for the ACD  102 . 
     When an agent wishes to resume a parked call, he indicates to the Softphone application  111  which parked call should be retrieved. To retrieve a call, the Softphone application  111  sends the command message “RETRIEVE_PARKED_CALL, &lt;My AgentDN&gt;,&lt;My PhoneDN&gt;,&lt;Unique Call Index&gt;” to the MCH application  316 . The MCH application  316  then references this information against the call data in the call database  318  to find the present location of the call, e.g., whether the call is in the first new route point  312  or the second new route point  314  or has been terminated. The MCH application  316  then sends a message through the CTI link  109  to blind transfer the call to the appropriate Agent DN. In other words, the call is delivered to the telephone of the agent  108   a.    
     If the agent  108   a  decides to drop a parked call, the agent sends an appropriate notification to the Softphone application  111  which in turn sends a “Drop Call” message to the MCH application  316 . The MCH application  316  then redirects the call to the default route point for the ACD  102 . The MCH application  316  then sends the Softphone application  111  a “Call Discarded” response message. This process allows the agent  108   a  to selectively discard calls. 
     The MCH application  316  sends the following autonomous call status messages to the Softphone application  111 . These autonomous messages are: Call Parked, Call Discarded, Call Disconnected, Timed Out, and MCH Error. The Call Parked and Call Discarded messages have been previously discussed. The Call Disconnected message arises when the caller hangs up. The Time Out message arises when the call has been queued past a configurable time period. The MCH error message arises when a failure occurs in the MCH application  316 . 
     FIG. 7 illustrates a typical display provided by an exemplary user interface of the present invention to an agent, such as the agent  108  of FIG.  3 . The user interface shows the calls that the agent has parked in the ACD/PBX which the agent may retrieve on an individual basis in any order. The Softphone application  111  presents this display to the agent based on information received from the MCH application  316 . As shown in FIG. 7, a graphical user interface  700  provides a parked call identification chart  701 . The parked call identification chart  701  includes the name of each parked caller, the time each call was parked, and the park duration for each call. As shown in the exemplary graphical user interface depicted in FIG. 7, the agent has parked six calls,  702 - 707 . The Softphone application  111  provides the agent with a utility that allows entry of the name of the parked caller. The park time and the park duration information may be automatically supplied using information provided by the messages sent between the desk top application  111  and the MCH application  316 . 
     The agent may retrieve a specific parked call by accessing a software radio button  708  displayed alongside each parked call such as the radio button displayed alongside the parked call  702 . In one embodiment, the agent may access the radio button  708  by using either a combination of hot keys or by clicking on the radio button  708  using the cursor of a mouse. In another embodiment, the agent may be provided with a touch-sensitive screen and may simply touch the radio button  708 . 
     By actuating the button  708 , the agent  108   a  initiates the retrieval of the parked call which will then become available to the agent at the agent&#39;s telephone. The agent may select any of the six parked calls  702 - 707  which have been previously parked. In addition, the agent may actuate the six parked call retrieval buttons  708  in any order. Thus, the agent does not necessarily have to retrieve the calls in the order in which they have been stored. 
     The agent  108   a  is also provided with a call drop button  709  which is provided alongside each of the parked calls, such as the call drop button provided alongside the parked call  702 . The call drop button  709  may be selectively actuated for any of the six parked calls  702 - 707 . For example, the agent could use the call drop button  709  associated with the caller listed as “irate.” Engaging the call drop button  709  initiates the return of the parked call to the Default DN for the ACD. Depending upon the type of call and the call center configuration, this may result in redirection of the call to the agent&#39;s Skill/Split Hunt Group or to some other destination. On the other hand, if the call was directed initially to the Agent DN or to the Phone DN at the agent&#39;s workstation, then actuating the call drop button  709  could be configured to result in the call being disconnected. 
     The embodiments of the invention discussed thus far have shown a Softphone application  111  having an associated GUI with which a human agent interacts to perform the various capabilities described. As previously discussed, embodiments of the invention are also applicable to robotic call processing applications associated with a route point. For example, the robot application  212  shown in FIG. 2 is associated with the route point  103 . 
     FIG. 8 illustrates an embodiment of the invention in which the robotic application  211  interacts with the previously described components of the present invention in a manner similar to that of the agent  108   a  and the Softphone application  111 . In this embodiment, the commands previously described as arriving at the MCH application  316  from the Softphone application  111  are replaced with commands arriving from the robotic application  211 . These commands would typically arrive at the MCH application  316  via the CTI link  109 . Likewise, when the robotic application  211  needs to retrieve a parked call from one of the new route points, the robotic application  211  sends a command to the MCH application  316  similar to that sent by the Softphone application  111  when retrieval of a parked call is desired. In all other respects, this alternative embodiment functions in a similar manner to the previously described embodiments of the invention. Moreover, the present invention may provide multiple call handling services for both robotic call processing applications and agent workstations at the same time, as the configurations are not mutually exclusive. 
     FIG. 9 illustrates an alternative embodiment of the invention. In this alternative embodiment, the ACD  102  does not have a default timeout routing period. Accordingly, a second new route point is no longer needed. As shown in FIG. 9, a call queuing capability is provided by a single new route point  912  having a routing program  913 . Calls may be queued in the new route point  912  by sending appropriate commands through the CTI link  109  from the MCH application  316 . 
     In this alternative embodiment, the new routing program  913  may contain a default routing instruction which will occur after a configurable period of time. Providing a default routing period allows the new route point  912  to be emptied of queued calls should an error occur in the MCH application  316 . As discussed above, the default timeout period for the ACD  102  provides a mechanism for emptying a route point should an error occur in the MCH application  316 . The new route point  912  could contain an instruction to default route queued calls after a time period that equals the maximum timeout period that was previously discussed with respect to the MCH application  316 . This approach would allow the queued calls to be emptied from the new route point  912  in the event of a failure of the MCH application  316 . In all other significant respects this alternative embodiment functions in the same manner as the previously discussed embodiment. 
     FIG. 10 illustrates yet another alternative embodiment of the present invention. In this embodiment of the invention, the ACD  102  contains no prohibitions which prevent a call from being redirected to the same route point from which it came. In other words, the ACD  102  allows a call to be rerouted to itself. As shown in FIG. 10, the ACD  102  is modified to include a new route point  1012  and a new routing program  1013 . The MCH application  316  sends a redirect command to the new route point  1012  in a time period less than that of the default timeout period for the ACD  102 . The redirect command transfers a queued call in the new route point  1012  back to the new route point  1012 , effectively starting the default routing period for this call over again. In all other aspects this embodiment functions in an identical manner to the previously described embodiments. 
     From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims. 
     While the present invention has been described with reference to preferred embodiments thereof, those skilled in the art will appreciate that various changes in form and detail may be made without departing from the intended scope of the present invention as defined in the appended claims. For example, the MCH application, the robotic call processing application, and the route points may differ from those shown in the figures or additional route points might be provided to support various additional functions such as playing a specific audible message to the user. Also, the Softphone application in addition to being interacted with by a human may also be interacted with by a robotic application. Moreover, the MCH application and the robotic call processing application may be run on different types of computing systems or on computing systems differing substantially from the computing network discussed herein. The MCH application and the robotic call processing application may each be provided in microcode in a hardware device in communication with the ACD, such as that provided on a computer chip or an application specific integrated circuit (ASIC). 
     In one exemplary alternative embodiment, the new route points, as well as the MCH application and the call database, may be provided as a plug-in device to the ACD. In this embodiment, a utility program could be run in the ACD maintenance console to appropriately configure the ACD for operations with the plug-in device. Such a device would operate in all significant respects in the same manner as the embodiment described herein. 
     In another embodiment of the invention, the MCH application may be merged into the Softphone application  111 . In this embodiment, the Softphone application  111  would send multiple call handling commands through the CTI link, such as the command to queue a call by performing a blind transfer to the new route point. 
     Although specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as will be recognized by those skilled in the relevant art. The teachings provided herein of the invention can be applied to other multiple call handling systems, not necessarily the exemplary multiple call handling system described above. Various exemplary computing systems, and accordingly, various other system configurations can be employed under the invention. 
     The embodiments of the invention disclosed herein have been discussed with regard to call center installations, such as those using large computing systems. However, the invention finds equal applicability in other computing systems, such as small, portable computerized systems and even de-centralized computing devices distributed in a network. 
     These and other changes can be made to the invention in light of the above detailed description. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but should be construed to include all distributed resource allocation systems that operate under the claims. Accordingly, the invention is not limited by the disclosure, but instead its scope is to be determined by the following claims.