Abstract:
Methods and apparatus are provided for processing “on hold” commands in a call center. A communication dialog is processed by storing a checkpoint containing a context of the communication; monitoring the communication dialog for an “on-hold” condition; and suspending the communication dialog when the “on-hold” condition is detected The “on-hold” condition can be detected by monitoring telephony signaling. The communication dialog can optionally be returned to a restart point, such as a checkpoint, when the “on-hold” condition is detected. The communication dialog can be monitored for an “off-hold” condition and restarted from a checkpoint when the “off-hold” condition is detected. A resume context message can optionally be provided to the caller when the “off-hold” condition is detected.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to call centers or other call processing systems, and more particularly, to methods and apparatus for processing an “on hold” feature in a call center. 
     BACKGROUND OF THE INVENTION 
     Many companies employ contact centers, such as call centers, to provide an interface for exchanging information with customers. In many call center environments, a customer service representative initially queries a caller for information, such as an account number, credit card number, or the nature of the inquiry. The customer service representative may be a real person or a virtual agent that typically routes the call to the appropriate destination after collecting initial information. 
     For example, many call centers employ interactive voice response (IVR) systems, such as the CONVERSANT® System for Interactive Voice Response, commercially available from Avaya Inc., that provide callers with information in the form of recorded messages and to obtain information from callers using keypad or voice responses to recorded queries Ports on the IVR systems are often referred to as “automated agents” or “virtual agents.” Typically, a media server receives a call, obtains the appropriate Voice eXtensible Markup Language (VoiceXML) page (i.e, a script for the call) from a server and then executes the VoiceXML page for the caller. 
     Increasingly, customers are choosing alternate forms of contact into a business, such as a web-based contact over the Internet or another Internet Protocol (IP) network. For example, many customers call a contact center over the Internet using Voice Over IP (VoIP) communications. The form of contact selected by a customer, however, may impact the functionality that is available to the customer or the manner in which the communication is processed by the call center. A caller can place their telephone on hold while interacting with a voice dialog on an IVR system. With a traditional Plain Old Telephone Systems (POTS) type connection, for example, the telephone of the far end party does not receive any specific signaling when the near end party places the call on hold. Thus, when the far end is an IVR systems the IVR system has no way to know that the call has been placed on hold. Thus, following an “on hold” condition, the IVR system will continue processing the call as if the caller were still actively participating. The dialog may fail because the caller stops providing input and eventually the dialog could time-out or otherwise hang up. In addition, even if the caller returns to the IVR system prior to the call being dropped, the caller may not know what state the dialog is in because the caller has not heard the prompt and may not be able to continue. 
     VoIP protocols have changed the manner in which an “on hold” condition is processed. For VoIP protocols, such as the Session Initiation Protocol (SIP), the “on-hold” function can result in a renegotiation of the media for the call Typically, the party placing the call “on-hold” will re-INVITE the far end party with a session description protocol that disables the media streams. Optionally, the party placing the call “on-hold” could renegotiate a stream to a Real Time Streaming Protocol (RTSP) server that will play music-on-hold to the far end party. In any event, the far end party receives a positive indication of the call being placed “on-hold” 
     A need therefore exists for improved methods and apparatus for processing “on hold” commands in a call center. 
     SUMMARY OF THE INVENTION 
     Generally, methods and apparatus are provided for processing “on hold” commands in a call center According to one aspect of the invention, a communication dialog based on a predefined script is processed by storing a checkpoint containing a context of the communication; monitoring the communication dialog for an “on-hold” condition; and suspending the communication dialog when the “on-hold” condition is detected The “on-hold” condition can be detected by monitoring telephony signaling. The communication dialog can optionally be returned to a restart point when the “on-hold” condition is detected. The restart point may be, for example, a previous checkpoint. 
     Thereafter, the communication dialog can be monitored for an “off-hold” condition. The communication dialog can optionally be returned to a restart point when the “off-hold” condition is detected. The checkpoint can optionally be restored when the “off-hold” condition is detected In one variation, a resume context message is provided to the caller when the “off-hold” condition is detected. 
     A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a network environment in which the present invention can operate; 
         FIG. 2  is a flow chart of a conventional form interpretation process; 
         FIG. 3  is a flow chart of a form interpretation process that incorporates automatic checkpoint and recovery in accordance with the present invention; 
         FIG. 4  is a flow chart of a form interpretation process that incorporates programmatic checkpoint and recovery in accordance with the present invention; and 
         FIG. 5  illustrates a functional view of a checkpoint process incorporating features of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a network environment in which the present invention can operate. As shown in  FIG. 1 , a caller, employing a telephone  110 , places a telephone call to a call center  150  and is connected to a call center agent (not shown). The telephone  110  may be embodied as any device capable of establishing a voice connection over a network  120 , such as a conventional, cellular or IP telephone. The network  120  may be embodied as any private or public wired or wireless network, including the Public Switched Telephone Network, Private Branch Exchange switch, Internet, or cellular network, or some combination of the foregoing 
     As shown in  FIG. 1 , and discussed further below, the exemplary call center  150  includes one or more servers  160 . The exemplary server  160  includes a VoiceXML Form Interpreter  170  and a VoiceXML Checkpoint and Recovery Process  300 , discussed further below in conjunction with  FIG. 3 . It is noted that in an alternate implementation, the VoiceXML Form Interpreter  170  and a VoiceXML Checkpoint and Recovery Process  300  could be stored on a distributed agent workstation. Generally, the VoiceXML Form Interpreter  170  is an algorithm defined in Appendix C of the VXML 2.0 Specification. The form interpreter  170  defines how the interpreter should process a VXML file. As discussed hereinafter, the form interpreter  170  is typically divided into four phases, namely, (i) an initialization phase that loads the form and defined variables; (ii) a selection phase that selects the first eligible form item for execution; (iii) a collection phase that plays the prompts, as needed, and collects input from the caller; and (iv) a process phase that processes the result and executes any &lt;filled&gt; blocks. After the process phase, execution returns to the selection phase. If no form item is eligible to be visited, then the application is terminated. 
     As indicated above, under a VoIP protocol, the far end party, such as the call center  150  of  FIG. 1 , receives a positive indication of the call being placed “on-hold” by the near end caller  110 . According to one aspect of the present invention, an “on-hold” condition is detected, which triggers a suspension of the IVR dialog and a roll back to an appropriate restart point (e.g., a previous checkpoint). When the caller  110  takes the call off hold, the dialog would resume at the restart point. In one exemplary implementation, the voice dialog engine (such as VXML in the exemplary embodiment) is extended to “checkpoint” restart locations. The dialog state can be saved, for example, at the beginning of the execution of each “form item” in VXML The specific spot saved for roll-back will be dependent on the voice dialog language being used. The “on-hold” condition can be detected, for example, by examining the signaling. Upon detecting an “on-hold” condition, the disclosed method suspends the execution of the voice dialog on the IVR  150 . For VXML based dialogs, if currently in a form item, then the method will roll back to the beginning of that item (as previously saved). If outside of a form item, execution continues until the next form item is reached, and then the method waits. When the off-hold condition is detected, the voice dialog resumes at the point of the start of the form item. 
       FIG. 2  is a flow chart of a conventional form interpretation process  200 . As shown in  FIG. 2 , the form interpretation process  200  initially loads a page during step  210 . The page is initialized during step  220 , whereby the page is read and any variables on the page are initialized. During step  230 , the first item on the page is selected. If there are no further selectable items, then program control terminates. Otherwise, any prompts associated with the item are played during step  240  and any user input is collected. The collected input is processed during step  250  and the page is updated accordingly. 
     A test is performed during step  260  to determine if there are any other items to process on the current page. If it is determined during step  260  that there are additional items to process on the current page, then program control returns to step  230 . If, however, it is determined during step  260  that there are no additional items to process on the current page, then program control returns to step  210  to load a new page. 
     Automatic Checkpoint and Recovery 
       FIG. 3  is a flow chart of a form interpretation process  300  that incorporates automatic checkpoint and recovery in accordance with the present invention In the implementation shown in  FIG. 3 , the form interpreter  300  automatically performs the check pointing, without any input from the VXML programmer. As shown in  FIG. 3 , the form interpretation process  300  initially loads a page during step  310 . The page is initialized during step  320 , whereby the page is read and any variables on the page are initialized. 
     A checkpoint is performed during step  325  to save the context to a local or remote database  328 . In one exemplary embodiment, the checkpoint saves the ECMAscript context (generally, all variables and values) See, for example, Standard ECMA-262, ECMAScript Language Specification, 3rd edition (December 1999), http://www.ecma-international.org/publications/standards/Ecma-262 htm, incorporated by reference herein. 
     During step  330 , the first item on the page is selected. If there are no further selectable items, then program control terminates. Otherwise, any prompts associated with the item are played during step  340  and any user input is collected. The collected input is processed during step  350  and the page is updated accordingly 
     In one exemplary embodiment, a test is performed during step  345  to determine if an on-hold event is detected (such as a SIP suspend command). The test during step  345  can be performed continuously, periodically or at other intervals. If it is determined during step  345  that an on-hold event is detected, then the process  300  returns to the checkpoint  325  Thus, if the “on-hold” event is signaled by the telephony interface, then execution is stopped and the interpreter returns to the check point  325  prior to the selection phase  330 . The interpreter  300  waits for the “off-hold” signal from the telephony layer (such as a SIP resume command), then the “saved” ECMAscript context is restored from the database  328 . Lastly, the interpreter  300  can restart the execution with the select phase  330 . It is noted that the previously saved ECMAscript context remains saved until the next time the interpreter  300  performs a checkpoint  325  at the top of the loop. 
     A test is performed during step  360  to determine if there are any other items to process on the current page. If it is determined during step  360  that there are additional items to process on the current page, then program control returns to step  325 . If however, it is determined during step  360  that there are no additional items to process on the current page, then program control returns to step  310  to load a new page. 
     An application programmer can optionally set a system level property (resumeaudio) to provide a prompt that would be played back when the “off-hold” event has been received. This would be similar to the existing fetchaudio property. The interpreter  300  would play this prompt prior to re-entering the select phase  330  The intention is that the application programmer would provide a prompt that would remind the caller of what they were doing prior to putting the IVR system on-hold 
     Programmatic Checkpoint and Recovery 
     In a further variation of the present invention, the VXML application programmer can set specific check points via a language that would force the VXML interpreter to save the application context. According to another aspect of the present invention, the form interpreter is extended to recognize a new VXML language construct &lt;checkpoint&gt;. As discussed hereinafter, the &lt;checkpoint&gt; element would allow for child &lt;prompt&gt; elements that could be used to play a “resuming your dialog session” type prompt to the callers when the “off-hold” event is received. 
       FIG. 4  is a flow chart of a form interpretation process  400  that incorporates programmatic checkpoint and recovery in accordance with the present invention In the implementation shown in  FIG. 4 , the form interpreter  400  performs check pointing, as specified by the VXML programmer. As shown in  FIG. 4 , the form interpretation process  400  initially loads a page during step  410  The page is initialized during step  420 , whereby the page is read and any variables on the page are initialized. 
     During step  430 , the first item on the page is selected If there are no further selectable items, then program control terminates. Otherwise, a test is performed during step  432  to determine if the selected item indicates that a checkpoint should be performed. 
     If it is determined during step  432  that the selected item indicates that a checkpoint should be performed, then a checkpoint is performed during step  435  to save the context to a database  438 . If, however, it is determined during step  432  that the selected item does not indicate that a checkpoint should be performed then program control proceeds to step  440  where any prompts associated with the selected item are played and any user input is collected. The collected input is processed during step  450  and the page is updated accordingly. 
     In one exemplary embodiment, a test is performed during step  445  to determine if an on-hold event is detected. The test during step  445  can be performed continuously, periodically or at other intervals. If it is determined during step  445  that an on-hold event is detected, then the process  400  returns to the checkpoint  435 . The interpreter  400  waits for the “off-hold” signal from the telephony layer, then the “saved” ECMAscript context is restored from the database  438  Lastly, the interpreter  400  can restart the execution with the select phase  430 . It is noted that the previously saved ECMAscript context remains saved until the next time the interpreter  400  performs a checkpoint  435   
     A test is performed during step  460  to determine if there are any other items to process on the current page. If it is determined during step  460  that there are additional items to process on the current page, then program control returns to step  430 . If, however, it is determined during step  460  that there are no additional items to process on the current page, then program control returns to step  410  to load a new page. 
     Checkpoint Semantics 
     The &lt;checkpoint&gt; element can be at the document or form level. When at the document level, a checkpoint is created prior any processing of the VXML document (e.g., prior to the initialization phase.) If at the &lt;form&gt; level, the checkpoint is created at the point it is selected as part of the selection phase of the form interpreter. Form level checkpoints selected by the form interpreter are marked as visited All &lt;checkpoint&gt; elements save the ECMAscript context at the point they are executed. After the context has been saved, the form interpreter jumps back to the Select phase. 
     In an exemplary implementation, the check point is only the most recently saved context. There might be situations where (in the programmatic case), it might be useful to “name” the check points and have the ability to resume at a specific named check point. One possibility is a duration factor. So, suppose a person left the IVR on hold for 30 seconds, the most likely choice would be to resume at the most recent check point because the caller should still have the context of the dialog in their head. If on the other hand, the IVR was on hold for several minutes, then it might be useful to back up farther in the dialog to allow the caller to re-establish an understanding of the context of the dialog. 
       FIG. 5  illustrates a functional view of a checkpoint process  500  in accordance with the present invention. As shown in  FIG. 5 , if the checkpoint process  500  is entered at step  510  to save the context, the checkpoint process  500  will copy the ECMAScript context during step  520  to a context database  530  and then exit. If, however, the checkpoint process  500  is entered at step  550  from an on-hold event, a test is performed during step  560  to determine if an off-hold event is detected. Once it is determined during step  560  that an off-hold event is detected, then program control proceeds to step  570  to restore the ECMAScript context from the database  530  before exiting. 
     As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some or the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk. 
     The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network. 
     It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention. For example, in a POTS implementation, an on-hold condition can be detected indirectly by detecting “music-on-hold,” using a known technique.