Patent Publication Number: US-8532995-B2

Title: System and method for isolating and processing common dialog cues

Description:
PRIORITY INFORMATION 
     The present application is a continuation of U.S. patent application Ser. No. 11/246,604, filed Oct. 7, 2005. The contents of which is incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to speech recognition technology and in particular to isolating and processing common dialog cues without affecting a dialog application for which speech input is intended. 
     2. Introduction 
     In conventional speech dialog systems, an automatic speech recognizer (ASR) module may receive speech input from a user and may perform speech recognition of the speech input. The recognized speech may then be passed as text to a dialog application. The dialog application may analyze the input received from the ASR module to determine an action to take based on the input. If the action involves generating speech for outputting to the user such as, for example, prompts for additional user input, the dialog application may generate text and may pass the text to a text-to-speech (TTS) module, which may generate speech from the text for a user to hear. 
     When a new dialog application is designed, various conditions, such as, for example, error conditions, as well as other conditions, must be considered. Thus, the dialog application must be designed and implemented such that it can recover from the error conditions as well as properly handle the other conditions. Currently, design and implementation of dialog applications, which may perform complex error recovery processing as well as other processing, may be very complicated. 
     It would be desirable to be able to perform certain types of functions, such as recovery from error conditions, as well as other desirable functions, outside of the dialog application. By isolating the certain types of functions from the dialog application, dialog application design and implementation would become easier because the designers and implementers could focus their efforts on the application-specific functions without concern for the design or implementation of error recovery as well as the other desirable functions. 
     SUMMARY OF THE INVENTION 
     Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth herein. 
     In a first aspect of the invention, a method of isolating and processing common dialog cues is provided. Speech input is received at a speech recognition component and recognized output is produced. A common dialog cue from the received speech input or input from a second source is recognized. An action is performed corresponding to the recognized common dialog cue. The performing of the action includes sending a communication from the speech recognition component to the speech generation component while bypassing a dialog component. 
     In a second aspect of the invention, a system is provided. The system includes a speech recognition component configured to receive speech input and produce a recognition output, and a text-to-speech component. The speech recognition component is further configured to recognize a common dialog cue included within the speech input or within input from a second source, and perform an action corresponding to the recognized common dialog cue, the action including bypassing a speech dialog application to communicate with the text-to-speech component. 
     In a third aspect of the invention, a machine-readable medium having instructions for at least one processor recorded thereon is provided. The machine-readable medium includes instructions for receiving speech input at a speech recognition component and producing a recognized output, instructions for recognizing a common dialog cue from the received speech input or input from a second source, and instructions for performing an action corresponding to the recognized common dialog cue. The instructions for performing the action further include instructions for sending a communication from the speech recognition component to the speech generation component while bypassing a dialog application. 
     In a fourth aspect of the invention, a system is provided. The system includes means for receiving speech input at a speech recognition component and producing a recognized output, means for recognizing a common dialog cue from the received speech input or input from a second source, and means for performing an action corresponding to the recognized common dialog cue. The means for performing an action corresponding to the recognized common dialog cue further includes means for sending a communication from the speech recognition component to the speech generation component while bypassing a dialog application. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: 
         FIG. 1  illustrates an exemplary spoken dialog system consistent with principles of the invention; 
         FIG. 2  illustrates an exemplary system that may be used to implement one or more components of the system of  FIG. 1 ; 
         FIG. 3  is a high level flowchart that illustrates exemplary processing in implementations consistent with the principles of the invention; and 
         FIGS. 4-6  are flowcharts that illustrate exemplary processing in different implementations consistent with the principles of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Various embodiments of the invention are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention. 
     Exemplary Spoken Dialog System 
       FIG. 1  is a functional block diagram of an exemplary spoken dialog system  100  consistent with the principles of the invention. Spoken dialog system  100  may include an automatic speech recognition (ASR) module  102 , a spoken language understanding (SLU) module  104 , a dialog management (DM) module  106 , a spoken language generation (SLG) module  108 , a text-to-speech (TTS) module  110 , a common dialog cue (CDC) module  112  and a media server  114 . 
     Media server  114  may receive incoming speech input and may route the speech input such as, for example, incoming phone calls, to ASR module  102 . Media server  114  may include a voice XML interpreter and may receive output from ASR module  102  and may forward ASR module  102  output to SLU module  104 . Media server  114  may also receive SLG module  108  output and may forward SLG module  108  output to TTS module  110 . SLG module  108  output may be in a form of voice XML 
     ASR module  102  may analyze the speech input and may provide a transcription of the speech input as output. SLU module  104 , DM module  106  and SLG module  108  may be included in a dialog application. Typically SLU module  104  of the dialog application may receive the transcribed input from ASR module  102  via media server  114  and may use a natural language understanding model to analyze the group of words that are included in the transcribed input to derive a meaning from the input. DM module  106  of the dialog application may receive an indication of the meaning of the input speech as input and may determine an action, such as, for example, providing a spoken response, based on the input. SLG module  108  may generate a transcription of one or more words in response to the action provided by DM  106 . TTS module  110  may receive the transcription as input from SLG module  108  via media server  114  and may provide generated audible speech as output based on the transcribed speech. 
     Thus, the modules of system  100  may recognize speech input, such as speech utterances, may transcribe the speech input, may identify (or understand) the meaning of the transcribed speech, may determine an appropriate response to the speech input, may generate text of the appropriate response and from that text, generate audible “speech” from system  100 , which the user then hears. In this manner, the user can carry on a spoken dialog with system  100 . Those of ordinary skill in the art will understand the programming languages and means for generating and training ASR module  102  or any of the other modules in the spoken dialog system. Further, the modules of system  100  may operate independent of a full dialog system. For example, a computing device such as a smartphone (or any processing device having an audio processing capability, for example a PDA with audio and a WiFi network interface) may have an ASR module wherein a user may say “call mom” and the smartphone may act on the instruction without a “spoken dialog interaction”. 
     In exemplary spoken dialog system  100 , ASR module  102  may be closely tied to TTS module  110  via CDC module  112  such that ASR module  102  may send commands to TTS module  110  via CDC module  112  and may receive indications from TTS module  110  via CDC module  112 , as will become clear from a description of exemplary operation of system  100  appearing below in the specification. One advantage of having a closely tied ASR module  102  and TTS module  110  is that various conditions detected by ASR module  102  may be corrected without having to design the dialog application to detection and correct the various conditions. Further, prompting as well as other commands sent to the user by TTS module  110  from ASR module  102  may be performed with much less delay. Thus, recovery from certain conditions may occur much more quickly with less confusion to the user. 
       FIG. 2  illustrates an exemplary processing system  200  in which one or more of the components of system  100  may be implemented. Thus, system  100  may include at least one processing system, such as, for example, exemplary processing system  200 . System  200  may include a bus  210 , a processor  220 , a memory  230 , a read only memory (ROM)  240 , a storage device  250 , an input device  260 , an output device  270 , and a communication interface  280 . Bus  210  may permit communication among the components of system  200 . Processor  220  may include at least one conventional processor or microprocessor that interprets and executes instructions. Memory  230  may be a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor  220 . Memory  230  may also store temporary variables or other intermediate information used during execution of instructions by processor  220 . ROM  240  may include a conventional ROM device or another type of static storage device that stores static information and instructions for processor  220 . Storage device  250  may include any type of media, such as, for example, magnetic or optical recording media and its corresponding drive. 
     Input device  260  may include one or more conventional mechanisms that permit a user to input information to system  200 , such as a keyboard, a mouse, a pen, a microphone, etc. Output device  270  may include one or more conventional mechanisms that output information to the user, including a display, a printer, one or more speakers, or a medium, such as a memory, or a magnetic or optical disk and a corresponding disk drive. Communication interface  280  may include any transceiver-like mechanism that enables system  200  to communicate via a network. For example, communication interface  280  may include a modem, or an Ethernet interface for communicating via a local area network (LAN). Alternatively, communication interface  280  may include other mechanisms for communicating with other devices and/or systems via wired, wireless or optical connections. In some implementations of spoken dialog system  100 , communication interface  280  may not be included in processing system  200  when spoken dialog system  100  is implemented completely within a single processing system  200 . 
     System  200  may perform functions in response to processor  220  executing sequences of instructions contained in a computer-readable medium, such as, for example, memory  230 , a magnetic disk, or an optical disk. Such instructions may be read into memory  230  from another computer-readable medium, such as storage device  250 , or from a separate device via communication interface  280 . 
     Exemplary Implementations 
       FIG. 3  is a high level flowchart that illustrates an exemplary overview of a process that may be performed in implementations consistent with the principles of the invention. The process may begin with media server  114  forwarding received speech input to ASR module  102  (act  302 ). The speech input may be received via a microphone, via a landline or wireless telephone call, or via a number of methods. ASR module  102  may examine the received speech input to determine whether any common dialog cues are included in the input. In implementations consistent with the principles of the invention, the common dialog cues may include, for example, predetermined keywords, noise, or a change in predetermined properties of the speech input. In some implementations consistent with the principles of the invention, at least some of the input may come from another source, such as a telephone pad of a telephone, a computer keyboard or another device. 
     Next, ASR module  102  may determine whether the speech input, or alternatively, a second input, includes any common dialog cues (act  304 ). If no common cues are found, then ASR module  102  may pass the received speech input, via media server  114 , to the dialog application (act  310 ), which in one implementation may include SLU module  104 , DM module  106  and SLG module  108 . If one or more common dialog cues are found, then ASR module  102  may forward indications of the common dialog cues to CDC module  112  and may perform one or more actions corresponding the recognized dialog cues (act  306 ). Examples of common cues and actions will be provided with reference to  FIGS. 4 and 5 , below. 
     Next, ASR module  102 , may determine whether the speech input is to be passed to the dialog application (act  308 ). This determination is based on the particular action or actions that are to be performed. If ASR module  102  determines that it is to pass the speech input to the dialog application, then the speech input may be passed to the dialog application via media sever  114  (act  310 ). 
     ASR module  102  may then perform acts  302  through  310  repeatedly. 
       FIG. 4  is a more detailed flowchart of an exemplary ASR process consistent with the implementation described with respect to  FIG. 3 . The process may begin with activation of a dialog grammar GA (act  402 ). ASR module  102  may generate grammar GActive, which may be a union of grammar GA and grammar GC (a grammar of common dialog cues) (act  404 ). This would provide ASR module  102  with the ability to recognize speech for the dialog application as well as common dialog cues in the speech input. ASR module  102  may then receive speech input and perform speech recognition using the GActive grammar (act  406 ). 
     In this exemplary process, the common dialog cues in the speech input may include the phrases “hold on” and “I am back.” At this point, ASR module  102  may determine whether the speech input includes the phrase, “hold on” (act  408 ). If ASR module  102  determines that the phrase is not included in the speech input, then the recognized speech may be passed to the dialog application via media server  114  for normal processing (act  410 ) and ASR module  102  may receive additional speech input (act  406 ). 
     If ASR module  102  determines that the speech input includes the phrase “hold on” then ASR module  102  may release the GActive grammar and may activate the GC grammar (act  412 ). Using the GC grammar would typically be less resource intensive than using the GActive grammar Next. ASR module  102  may receive speech input (act  414 ). ASR module  102  may then determine whether the speech input includes “I am back” (act  416 ). If ASR module  102  determines that the speech input does not include “I am back” then the speech input may be discarded (act  418 ) and ASR module is ready to receive additional speech input (act  414 ). 
     If ASR module  102  determines that the speech input includes “I am back” then ASR module  102  may release grammar GC and may re-activate grammar GActive (act  420 ). ASR module  102  may again perform acts  406 - 420 . 
     Thus, the exemplary processing described above and in  FIG. 4  is for an implementation which provides a user an opportunity to temporarily stop sending input to the dialog application. This feature may be useful when the user must look up requested information, such as a credit card number. In such a situation, the user would simply say “hold on,” look up the credit card number, say “I am back”, and then say the credit card number. 
     In some implementations, after recognizing “hold on” in the speech input, ASR module  102  may send a pause command to TTS module  110 , via CDC module  112 , informing TTS module  110  to pause, stop prompting the user, and stop running a timeout timer, if any. The timeout timer may time a duration of a time interval from when a prompt is output by TTS module  110  to when ASR module  102  receives a speech input from the user. After ASR module  102  recognizes “I am back” in the speech input, ASR module  102  may send a second command to TTS module  110 , via media server  114 , to inform TTS module  110  to cause any stopped timeout timer to continue running or restart. Optionally, TTS module  110  may send an acknowledgement back to ASR module  102 , via media server  114 , to acknowledge receipt of a command sent to TTS module  110  from ASR module  102 . 
     One problem that may occur in spoken dialog systems is called false barge-in. False barge-in may occur when a user speaks in a noisy environment or when the user coughs or makes some other unintentional sound. In such a situation, a conventional spoken dialog system may assume that the noise or other unintentional sound is part of the input and may attempt to perform speech recognition on the noise. The speech recognizer may inform other components of the speech dialog system that an error occurred during the input and the system may attempt to prompt the user to repeat the input. However, due to several layers of software that may reside between the speech recognition function and the speech generation or text-to-speech function that produces a prompt for the user, a delay may occur between the detection of an input error and the prompting for the user to repeat the spoken input. This delay may cause the input and prompting functions to become out of step with one another, thereby causing confusion and frustration for the user. 
       FIG. 5  is a flowchart that illustrates an exemplary process in an implementation consistent with the principles of the invention that addresses the false barge-in problem. The process may start with ASR module  102  receiving speech input from a user via media server  114  (act  502 ). ASR module  102  may then stop TTS module  110  from outputting a prompt (act  504 ). In one implementation, this may be achieved by ASR module  102  sending a “stop prompt” indication to TTS module  110  via CDC module  112  while bypassing the dialog application. Next, ASR module may determine whether any noise is detected on the speech input (act  506 ). ASR module  102  in this embodiment is capable of detecting unintended noises, such as coughs or other noises. There are a number of ways in which this could be achieved including detecting a change in spectral density, language used, or other audio input characteristics. If ASR module  102  does not detect noise, then ASR module  102  may pass the recognized speech to a dialog application via media server  114  (act  508 ). 
     If ASR module  102  detects noise or another problem that makes the input speech somewhat unintelligible, then ASR module  102  may discard the noise or problem input and may send a “continue prompt” indication to TTS module  110  via CDC module  112 , bypassing the dialog application, to inform TTS module  110  to continue outputting the current prompt to the user (act  510 ). Thus, in a case in which noise is detected, the noise is discarded and the prompt continued, the user may hear a very brief interruption of a prompt. 
     In some implementations consistent with the principles of the invention, when a change in audio input characteristics suggests that the user or someone else was talking, but not talking to the dialog application, ASR module  102  may send an indication to TTS module  110  via CDC module, while bypassing the dialog application, to cause the TTS module  110  to output speech to the user, such as, for example, “Are you talking to me?” 
     In some implementations TTS module  110  may send an acknowledgment to ASR module  102  via CDC module  112  informing ASR module  102  of receipt of the message by TTS module  110 . 
     In the exemplary implementation discussed with reference to  FIG. 5 , noise may be treated as a common dialog cue with the corresponding action being a re-prompting of the user. Further, due to the tight coupling of ASR module  102  and TTS module  110  for handling common dialog cues, when ASR module  102  informs TTS module  110  to stop prompting or to continue prompting, TTS module  110  may perform the requested action with very little delay, thus eliminating a source of confusion and frustration to the user. 
     In another implementation consistent with the principles of the invention, when only a portion of a speech input is recognizable, a targeted re-prompt may be performed. For example, if a user speaks a portion of an account number, such as, for example,  908  and then coughs or shuffles paper, he may be re-prompted with, for example, “I heard  908 , please continue.” 
       FIG. 6  is a flowchart that illustrates exemplary processing in an implementation that includes targeted re-prompt. The process may begin with ASR module  102  receiving speech input via media server  114  (act  602 ). ASR module  102  may then send a “stop prompt” message to TTS module  110  via CDC module  112 , bypassing the dialog application (act  604 ). ASR module  102  may then determine whether noise was received (act  610 ). This may be performed using any of the methods previously described. If ASR module  102  does not detect noise, then ASR module  102  may pass the recognized speech input, in the form of text, to the dialog application via media server  114  (act  608 ). If ASR module  102  detects noise (act  606 ), then ASR module  102  may pass a message to TTS module  110  via CDC module  112 , bypassing the dialog application, to inform TTS module  110  to perform a targeted re-prompt (if a portion of the speech input was recognized) (act  610 ). TTS module  110  may then inform the user of what was recognized and may ask the user to continue providing input. ASR module  102  may save the input (act  612 ) and may repeat acts  602 - 612 . The saved recognized input and the recognized continued input may later be passed to the dialog application. 
     CONCLUSION 
     Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media. 
     Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps. 
     Those of skill in the art will appreciate that other embodiments of the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
     Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the invention are part of the scope of this invention. For example, hardwired logic may be used in implementations instead of processors, or one or more application specific integrated circuits (ASICs) may be used in implementations consistent with the principles of the invention. Further, implementations consistent with the principles of the invention may have more or fewer acts than as described, or may implement acts in a different order than as shown. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.