Telephonic communications – Audio message storage – retrieval – or synthesis – Voice message synthesis
Reexamination Certificate
2000-01-20
2004-04-20
Foster, Roland (Department: 2748)
Telephonic communications
Audio message storage, retrieval, or synthesis
Voice message synthesis
C379S088250, C379S088270
Reexamination Certificate
active
06724864
ABSTRACT:
FIELD OF THE INVENTION
The present invention is directed to a method and apparatus for processing prompt streams in a telephony system and, more specifically, to a method and apparatus for processing prompt streams including computer program instructions.
DESCRIPTION OF THE RELATED ART
A variety of automated systems have been developed that interact with people over the telephone. For example, commercial services exist that provide automated stock quotes and other financial information over the telephone. Such telephony systems implement a sequence of dialogs between a person (the “user”) on one end of the telephone connection, and the automated telephony system on the other end of the telephone connection. The telephony system plays audio output to the user. This output may, for example, consist of recorded announcements, tones or other generated sounds, or synthesized speech generated by a “text-to-speech” engine. A single unit of such audio output is referred to as a “prompt.” The automated system conveys information to the user by “playing” a sequence of prompts (referred to as a “prompt stream”) in an appropriate order. For example, to convey the sentence “A message was received from John Smith at 10:15 today,” the system might play the following prompts in order: (1) a recording of the words “A message was received from,” (2) synthesized speech for the name “John Smith” generated by a text-to-speech engine, (3) a recording of the word “at,” (4) a recording of the word “ten,” (5) a recording of the word “fifteen,” and (6) a recording of the word “today.”
The user is typically allowed to respond to the telephony system in any of a variety of ways, such as by pressing one or more DTMF (touch tone) keys, by hanging up, by flashing the telephone switchhook, or, in a system that is capable of speech recognition, by speaking or making other noises that are recognizable by the system. The user may also do nothing, leading to what is referred to as a “timeout.” In a typical interaction, the dialog implemented by the telephony system consists of alternating actions by the user and the system; e.g., the system plays a prompt stream, the user responds, the system plays another prompt stream based on the user's response, and so forth, until either the user or the system terminates the dialog by hanging up. Note that in some cases a hang up by the user may not be voluntary, such as when a cellular phone connection is unexpectedly dropped due to interference or some other problem with the connection.
Some telephony systems allow the user to interrupt the system's audio output. Such an interruption is referred to as “barge-in” (also referred to as “cut-through”). This feature may be used to provide a more user-friendly interface. For example, a user who is already familiar with the operation of the telephony system can barge-in on the prompt stream to respond without waiting for the prompt stream to complete, making dialogs complete more quickly and feel more natural to the user. Some telephony systems allow barge-in to be turned on or off by the system or by the user as desired. Some systems allow the user to barge-in with DTMF but not with voice input. Hang up by the user while a prompt stream is playing is also typically considered to be a form of barge-in.
Conventional automated telephony systems are typically controlled by software that is designed to operate in accordance with the “prompt queue” model. In such a model, the application program that controls the telephony system sequentially stores prompts in a prompt queue (a first-in first-out list). The telephony system typically provides a software interface through which the application program can manage the prompt queue. The software interface typically provides a variety of methods for adding prompts to the prompt queue. For example, the interface typically allows the application to supply a text string to be added to the prompt queue, in which case a text-to-speech engine converts the text string into a digital audio stream that is added to the prompt queue in the form of an audio file. The interface may also allow the application program to supply an audio file to be added directly to the prompt queue. Regardless of the method that the application program uses to add prompts to the prompt queue, all prompts stored in the prompt queue are typically stored in the form of audio files suitable for playback to the user. The telephony system's software interface also typically provides a method for playing the prompts in the prompt stream. The application program uses this method to sequentially play the prompts in the prompt queue. The prompts are played to the user over the telephone and removed from the prompt queue as they are being played.
The prompt queue model provides a simple interface to the telephony system that makes it easy for the application program to generate and play prompts to the user. The application programmer who develops an application program according to the prompt queue model need not know how the underlying components, such as the text-to-speech engine and the speech recognition engine, work. Rather, the application programmer need merely know how to use some straightforward commands for manipulating the prompt queue (e.g., commands to add prompts to the prompt queue) and for causing the prompts in the prompt queue to be played to the user. The telephony system's software interface shields the application program (and the application programmer) from communication with low-level components such as the text-to-speech engine, the speech recognition engine, and the audio hardware.
Conventional systems using the prompt queue model, however, have a number of problems, some of which result at least in part from the abstraction provided by the prompt queue model. For example, in such a system, it is difficult to design an application program to perform an action at a predetermined time during playing of the prompt stream to the user. Once an application program instructs the telephony system to play the prompts in a prompt queue, the telephony system plays the prompts without further intervention from the application program. Furthermore, the telephony system does not provide the application program with any information about the time at which a particular prompt in the prompt queue is played to the user. It is therefore difficult for the application program to determine precisely when a particular word, for example, in the prompt stream is being played. This can make it difficult for the application program to perform an action that must be performed at a particular time while the prompt stream is playing. One reason for this difficulty is that, as described above, the application program can provide prompts in the form of text strings which are converted into audio by a text-to-speech engine. Once the text in such prompts is converted to speech, the application program does not have any information about the temporal position of particular words within the prompt.
Similarly, it is difficult to design application programs for such systems which can accurately and reliably determine when an event occurred during playing of a prompt stream. For example, it is difficult to design application programs that can accurately and reliably determine when a user barged in with input (such as a DTMF keypress) during playing of a prompt stream. Furthermore, even if the application program is provided with the time at which barge-in occurred, it may be difficult for the application program to determine which prompt was being played at the time of barge-in.
More generally, it is difficult to guarantee that application programs in such systems will perform as desired in the face of the wide variety of asynchronous interactions that may occur between the prompt stream, the user, and external events. Such asynchronous events include, for example, any events that occur at unpredictable times, such as barge-in or the arrival of a new e-mail message addressed to the user. For example, in many cases where ba
Denenberg Larwrence A.
Franklin Daniel L.
Gildea Stephen P.
Neuberger Marc J.
Ottenheimer Daniel E.
Comverse Inc.
Foster Roland
Wolf Greenfield & Sacks P.C.
LandOfFree
Active prompts does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Active prompts, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Active prompts will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3249454