Interactive voice response systems with general-purpose blocks

Techniques for generating interactive voice response systems are provided. Multiple interconnected general-purpose blocks can be configured for a specific IVR application. Each general purpose block can include prompts and logic for receiving input. By utilizing general-purpose blocks, complex IVR applications can be quickly and efficiently generated. Additionally, IVR applications can be upgraded and maintained during run-time.

BACKGROUND OF THE INVENTION

The present invention relates to interactive voice response (IVR) systems. More particularly, the invention relates to interactive voice response systems that include multiple general-purpose blocks.

As technology advances, more and more functions that are traditionally performed by human beings are being performed by machines. As an example, receptionists were the standard at almost any level of business to answer phone calls and direct them to the intended recipient. However, today it is very common for machines to perform the functions of a receptionist. When one calls a number, a machine often prompts the caller with a number of choices, which the caller can select with the buttons of a touch tone phone.

The electronic receptionist described above is a simple example of an IVR system. IVR systems are increasingly becoming more and more complex and can perform functions including voice processing, fax processing, call switching, call management, and the like. As may be expected, the complexities of the IVR systems provide more flexibility but also make building and maintaining an IVR system much more difficult.

IVR systems can be created using scripting languages. A scripting language is a relatively simple programming language that is designed for a specific task. The logical flow of an IVR system can be defined using sequential statements of the scripting language (e.g., javascript). Typically, the script statements are compiled into a software application that runs the IVR system.

Although scripting languages can be fairly powerful, they have several drawbacks. Most scripting languages are designed to resemble programming languages in order to reduce the learning curve for script programmers. However, this makes it difficult for one who is not a programmer to create, modify and generally maintain the IVR system. Additionally, if the software application is compiled from a script program, the IVR system will have to be terminated or “brought down” in order to update the software application with any changes.

IVR systems can also be created by the use of graphical application generators. Application generators commonly include a library of predefined software modules represented by graphical icons that the user is able to select and connect in order to build the software application.FIG. 1shows an example of an application generator for building an IVR system. As shown, a window101includes multiple interconnected graphical icons, providing an application generated from the interconnected predefined modules.

A graphical icon103is the point in which the software application begins. A graphical icon105is a branch that allows the flow of execution to proceed along multiple paths. Taking the middle path, a graphical icon107allows the user to enter his or her personal identification number (PIN), which is verified at a graphical icon109. A message is played to the user at a graphical icon111and the software application exits at a graphical icon113.

The particular logic flow of the software application shown inFIG. 1is not as important as understanding how the application generator works. In general, a user selects a desired icon from an icon window115. The selected icon is displayed on the screen and the user is able to connect the icon to other graphical icons. Additionally, the user may be able to define the specific characteristics of an icon. For example, the user may be able to specify the conditions upon which the graphical icon105will branch to each of the possible branch options.

Although application generators make creating and maintaining IVR systems easier, they still can be difficult to master. For example, there are possibly over 50 graphical icons shown inFIG. 1, with each icon being designed for a specific purpose. Although the graphical image of the icons may aid the user's understanding of the function that is provided, it still may be difficult to fully master the power and capabilities provided. Additionally, once the application is configured, the application generator generates an executable software module that needs to be executed in order to have the application run and perform the functions the user has configured. If there is a change in the configuration, the application generator needs to generate the executable software module that executes the newly modified version of the application before the configuration change takes effect. However, in systems that require non-stop operation, it is not practical to terminate an old version of the application so that the newly modified version can be started. This can make it difficult to modify a running IVR system because the running software application may need to be brought down, in order to install the updated version.

SUMMARY OF THE INVENTION

The present invention provides innovative techniques for creating and maintaining IVR systems. In general, an IVR system can include multiple general-purpose blocks, where each general-purpose block can be configured to perform one or more functions. By utilizing general-purpose blocks, an IVR system can be developed quickly and easily maintained. Additionally, in some embodiments, the IVR system can be updated during run-time, making it unnecessary to bring down the system to perform the update. Several embodiments of the invention are described below.

In one embodiment, the invention provides an interactive voice response system including multiple general-purpose blocks. Each general-purpose block is coupled to at least one other general-purpose block and plays a prompt. Additionally, each general-purpose block is configurable to send a first signal after playing the prompt or send a second signal according to received input after playing the prompt. Transfer blocks can be utilized to receive one of the first or second signals from a general-purpose block to transfer a call to a specified telephone number. In preferred embodiments, the general-purpose blocks receive dual tone multiple frequency (DTMF) input representing a key or a string of keys.

In another embodiment, the present invention provides a method of generating an interactive voice response application including providing multiple general-purpose blocks. Each general-purpose block is preconfigured to send signals to at least one other general-purpose block. A general-purpose block is selected and a prompt that the selected general-purpose block will play is specified. Additionally, it is specified whether the selected general purpose block will send a first signal after playing the prompt or send a second signal according to received input after playing the prompt. An error prompt can be specified so that the selected general-purpose blocks will play the error prompt if there is an error in the received input.

In another embodiment, the invention provides a method of modifying an interactive voice response system at run-time. The system, including multiple general-purpose blocks, is executed while the system continues running. A configuration of a selected general-purpose block is modified and the configuration of the selected general-purpose block is updated at run-time. In preferred embodiments, a configuration parameter is stored in a database, such as a WINDOWS registry.

Other features and advantages of the invention will become readily apparent upon review of the following description in association with the accompanying drawings.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

The following description is presented to enable one of ordinary skill in the art to make and use the invention. In this context, specific embodiments will be described that can be utilized to generate IVR applications. However, the invention is not limited to any particular language, computer architecture or specific implementation. Therefore, the description of the embodiments that follows is for purposes of illustration and not limitation.

Embodiments of the present invention utilize general-purpose blocks, which can be used in conjunction with function-specific blocks (e.g., transfer blocks) if desired. A “general purpose block” is a block that can be configured to perform one or more of multiple functions. In other words, the purpose or function of the general purpose block can change depending on how the block is configured. Although the below description is primarily discussed with respect to interactive voice response units, telephones, and DTMF tones, etc., it should be recognized that the present invention in other specific embodiments has application to automatic call distribution systems (ACDs), telephony devices such as telephony-enabled computers or H.323 phones used in telephony-over-LAN (ToL) systems.

FIG. 2Ashows a specific embodiment of a general-purpose block that can be utilized with the present invention. A general-purpose block201can receive a Start signal that directs the general-purpose block to begin executing. General-purpose block201begins execution by playing a prompt InitPlay203. The prompt is typically a voice message generated by the IVR application.

General-purpose block201can be configured to send a first signal after playing prompt203or send a second signal according to received input after playing prompt203. The configurability of general-purpose block201is shown utilizing boxes that can be empty to show that the path is valid or that can be closed (e.g., with an “X”) to show the path is not valid under the current configuration.

A box204indicates that a signal InitEnd can be sent after prompt203is played. The InitEnd will be sent if box204is configured as empty meaning that this path is configured as valid. As shown in this example, box204is closed, indicating that the valid path would proceed through a box206which is empty. In a preferred embodiment, boxes204and206are mutually exclusive such that the general-purpose block can be configured to play a prompt and then send a signal or play a prompt and process received input (and subsequently send a signal). When boxes204and206are configured to play the prompt and process received input, prompt203is typically a voice message. In other embodiments such as in ToL systems, a video message or an audiovisual message can be played for prompt203.

Prompt203will typically be a voice message that instructs the user what options are available and/or what types of input are valid. For example, prompt203can provide the user with a menu of choices and indicate that the user should select “1” if option 1 is desired, select “2” if option 2 is desired, and so forth. Additionally, prompt203can instruct the user to enter a string (e.g., a social security number) and may inform the user that a special character (e.g., “#”) indicates that input is complete.

A box GetDTMF208detects user input. IVR applications can receive input from users that includes voice messages and tones. The “tones” generated by a touch tone phone are dual tone multiple frequency (DTMF) tones. For simplicity, embodiments of the invention will be described as receiving DTMF tones as would be fairly typical for an IVR application. However, embodiments of the invention can also receive voice instructions that are interpreted utilizing voice recognition techniques that are known in the art. Still further embodiments, such as those in ToL systems, can receive typed-in characters/numbers that correspond to the name/extension of a user or selected icons that correspond to the address of a user.

Once input is received, the input is processed at a box ProcessDTMF210. Processing the input can include determining if there was an error with the input. For example, if prompt203provides a menu to the user in which only certain keys are valid, an error may be detected in the input if the user enters an invalid key. As another example, prompt203may tell the user to input a social security number and an error may be detected if a user enters less than 9 numbers.

If an error in the input is detected, a prompt ErrorPlay211can be played in order to notify the user that the input was invalid and general purpose block201proceeds to attempt to receive valid input. If after a predetermined amount of time no input is received, a prompt NoInputPlay214can be played to notify the user that no input was received. A signal NoInputEnd can then be sent.

If valid input is received, general-purpose block201sends a signal according to the received input. As shown, blocks212,214,216,218,220,222, and224are in a path to a signal corresponding to a key or string. If the boxes are empty, this indicates that the path is valid and a closed box indicates an invalid path as described above. As shown in this example, boxes216,218and220are empty, which indicates the valid input includes keys “1”, “2” and “3” as in a 3-item selection menu. The signals that general-purpose block201sends according to received input can correspond to the keys on a touch-tone phone as shown on the bottom ofFIG. 2Aand also include a string of keys for input that includes multiple keys. In other embodiments, the received input can correspond to typed-inFIG. 2Bshows another specific embodiment of a general-purpose block that can be utilized with the present invention. The same reference numerals are utilized to represent similar structures inFIGS. 2A and 2B. As described above in reference toFIG. 2A, prompt211(ErrorPlay) is played if an error is detected in the input. However, in the general-purpose block shown inFIG. 2B, after prompt211is played, prompt203is played. This arrangement can be beneficial, for example, because prompt211can inform the user of the error and prompt203can be replayed to provide the menu to the user.

In a preferred embodiment, the general-purpose blocks are implemented as objects in an object-oriented environment. Accordingly, the general-purpose blocks send or raise signals to other blocks as has been described. However, the invention is not limited to object-oriented environments and can be advantageously applied to other environments, including non-object-oriented environments. In non-object-oriented environments, for example, the general-purpose blocks can make a call to another block.

FIGS. 2A–2Bshow the overall functional structure of embodiments of a general-purpose block. It may be now beneficial to describe a process that a general-purpose block can execute.FIGS. 3A and 3Bshow a flow chart of a process that a general-purpose block can execute.

At a step301, the general-purpose block plays a prompt. The prompt may be played by accessing a file, e.g., a sound file, stored on a computer system as an example. Although step301indicates that a prompt is played, the prompt may also be null or undefined so that the prompt does not actually provide an audible message to the user.

After the prompt is played, the general purpose block determines if it should send a first signal at a step303. If it is determined that the general-purpose block should send the first signal, the block sends the signal at a step305. Otherwise, the general-purpose block receives input at a step307. The input can include individual keys or a string of keys, possibly delineated by a specific key. At a step309, it is determined whether input was received in a predetermined amount of time. If no input was received in the predetermined amount of time, the general-purpose block sends a no-input signal at a step311.

Once input has been received, the general-purpose block checks the input for any errors at a step313. At a step351, it is determined whether there is an error in the input. If there is an error, the general-purpose block plays an error prompt at a step353. Otherwise, the general-purpose block sends a second signal according to the received input at a step355.

FIGS. 2A–2Band3A–3B have been described in reference to a single general-purpose block. It may be beneficial now to describe how multiple general-purpose blocks can be interconnected to generate an IVR application. In some embodiments, an IVR application is generated solely with the use of general-purpose blocks. However, in a preferred embodiment, function-specific blocks including start blocks and transfer blocks are utilized as shown inFIG. 4.

FIG. 4shows multiple general-purpose blocks interconnected to form an IVR application400. A start block (SB)401performs the general initialization for the IVR application and waits for an incoming call. Once a call is received, SB401can send a signal to a general-purpose block (GPB)403to start the IVR operation.

GPB403can be a general-purpose block as described in reference toFIGS. 2A–2B. The InitEnd signal, if so configured, can be sent from GPB403to a transfer block (TB)405and the NoInputEnd signal can be sent from GPB403to a TB407. Transfer blocks are function-specific blocks that operate to transfer a call to a specified or configured telephone number and then to terminate the IVR operation. Accordingly, transfer blocks operate to transfer the telephone call. As a very simple example, assume one wanted to configure a general-purpose block to play a particular prompt and then transfer the phone call to another number, such as a voicemail box. For this example, the general-purpose block can be configured to play a prompt notifying the user that they are being transferred to another number (for example, the GPB would be configured such that box204inFIG. 2Awould be open and box206would be closed with an “X”) and the InitEnd signal can be sent to TB405, which would be configured to transfer the call to the desired telephone number. GPB403can send signals according to received input as described in reference toFIGS. 2A–2B. The signals sent according to the received input are sent to other general-purpose blocks as indicated inFIG. 4. Accordingly, GPB403and its associated transfer blocks405and407can be thought of as a first level (level 0). GPBs (and their associated transfer blocks) that receive signals from GPB403can be thought of as a second level (level 1). In any particular level, the GPBs can be identified by its level number and a node number. For example, the first GPB (far left side ofFIG. 4) in level 1 would be GPB(1, 1) and the last GPB (far right side ofFIG. 4) in level 1 would be GPB(1, n). GPBs (and their associated transfer blocks) that receive input from the general-purpose blocks of level 1 can be thought of as level 2, and so forth. Each GPB can be accordingly configured as discussed below as desired. In this way, an IVR application can be generated from general-purpose blocks that are interconnected and configured for the desired IVR application.

In particular,FIG. 5shows a flow chart of a process of generating an IVR application utilizing general-purpose blocks. At a step501, multiple general-purpose blocks are provided. The interconnected general-purpose blocks can be as described in reference toFIGS. 2A–2Band may be a preconstructed network of general-purpose blocks. The interconnected general-purpose blocks could be thought of as the framework that can be configured to build a desired IVR application. At a step503, a general-purpose block is selected. The general-purpose block that is selected is the block that the user desires to configure for this particular IVR application. At a step505, a prompt that the selected block will play is specified. As mentioned earlier, the prompt can be specified by the name of a sound file stored in memory or on disk. At a step507, it is specified whether the selected general-purpose block will send a first signal after the prompt is played or a second signal according to received input after the prompt is played.

As described,FIG. 5shows the configuration of a few parameters of a general-purpose block. It should be understood by those of skill in the art that the process may be repeated for multiple general-purpose blocks. Additionally, each general-purpose block can include more or less parameters. In a preferred embodiment, each general-purpose block can be configured according to the following parameters: InitPlay prompt, ErrorPlay prompt, and NoInputPlay prompt. These prompts may be configured or specified for each particular general-purpose block. Additionally, each general-purpose block can be configured to send the InitEnd prompt after playing the InitPlay prompt or sending a signal according to received input after the InitPlay prompt is played.

Each general-purpose block can be configured to process received input. In a preferred embodiment, the valid input for a general-purpose block is configured utilizing a table of input and corresponding valid output (i.e., signals generated according to the input). One way that a general-purpose block may be configured with these parameters, even during run-time, will be described in more detail in reference toFIG. 7. However, it may be first beneficial to describe a very simple example of an IVR application of the present invention.

FIG. 6shows a simple example of an IVR application. The IVR application simply answers a telephone call with a welcome greeting. The user then hears a prompt that provides a two option menu, which the user may select with either key “1” or a key “2.” Once the user has selected one of the menu options, the user hears a prompt that the telephone call will be transferred to the location specified and then the telephone call is transferred.

For simplicity,FIG. 6only shows the general purpose blocks and transfer blocks that have been configured to implement the above-described IVR application. A SB601performed the general initialization for the IVR application. A GPB603is configured such that the InitPlay prompt is the general greeting and provides a menu for the user. For example, the greeting can be “welcome to company XYZ.” GPB603can be configured so that it sends signals according to received input and the menu could be “press 1 for sales and press 2 to leave a message.” In this simple example, the valid input includes the keys “1” and “2.” However, if a user does not provide valid input in a predetermined amount of time (such as when the user is not utilizing a touch tone phone), GPB603can be configured with a NoInputPlay prompt that instructs the user that they will be transferred to a voice mail box. In this situation, GPB603may send a NoInputEnd signal to a TB605that transfers the telephone call to a voicemail box.

GPB603can process any received input and be configured to play an ErrorPlay prompt if the received input is not valid. GPB603can be configured to receive only keys “1” and “2” as valid input in accordance with the menu provided to the user.

Seen inFIG. 6, GPB607is a general-purpose block that receives a signal when the user inputs key “1” indicating that the user desires the first menu option, which in this example is for sales. GPB607can be configured to play an InitPlay prompt that tells the user that they are being transferred to sales. GPB607can then be configured to send an InitEnd signal to a TB609. TB609is configured to transfer the call to the telephone number for sales. In some embodiments, the transfer blocks have a default value for the telephone numbers to which they transfer calls. A GPB611and a TB613can be configured in a similar manner to transfer a telephone call into a general voice mail box which is indicated by the menu selection “2”. Although the IVR application described is very simple, it illustrates that very complex IVR applications can be generated by configuring preconnected general-purpose blocks.

An advantage of a preferred embodiment of the invention is that the general-purpose blocks can be configured during run-time.FIG. 7shows a block diagram of a system that allows the general-purpose blocks to be configured during run-time in an object-oriented environment. A web browser601is utilized by a user to access a web server603. Web server603allows the user to input the parameters for a specific general-purpose block. The specific general-purpose block can be identified by the level of the block (seeFIG. 4) and the location of the block within the level. Additionally, the parameters for the general-purpose block can be specified as described above.

Once the user specifies one or more parameters for a particular general-purpose block, web server603generates a servlet605. Servlet605takes the parameters for the particular general-purpose block and stores them in a database607. In a preferred embodiment, database607is a WINDOWS NT registry.

During execution, an IVR application609checks database607for new parameters for the general-purpose blocks. IVR application609can become aware of new parameters in a number of different ways. For example, an object can be created that continually monitors database607and sends a signal to IVR application609when the database has been modified. As another example, each general-purpose block of IVR application609can check the database before executing to determine if its parameters have been modified. By allowing a user to modify parameters of a general-purpose block during run-time, it is not necessary to terminate or bring down the IVR application in order to upgrade or maintain the IVR application.

FIG. 8illustrates an example of a computer system that can be used to execute the software of an embodiment of the invention.FIG. 8shows a computer system701that includes a display703, screen705, cabinet707, keyboard709, and mouse711. Mouse711can have one or more buttons for interacting with a graphical user interface. Cabinet707houses a CD-ROM drive713, system memory and a hard drive (seeFIG. 9) which can be utilized to store and retrieve software programs incorporating computer code that implements the invention, data for use with the invention, and the like. Although CD-ROM715is shown as an exemplary computer-readable storage medium, other computer-readable storage media including floppy disk, tape, flash memory, system memory, and hard drive can be utilized. Additionally, a data signal embodied in a carrier wave (e.g., in a network including the Internet) can be the computer-readable storage medium.

FIG. 9shows a system block diagram of computer system701used to execute the software of an embodiment of the invention. As inFIG. 8, computer system701includes monitor703and keyboard709, and mouse711. Computer system701further includes subsystems such as a central processor751, system memory753, fixed storage755(e.g., hard drive), removable storage57(e.g., CD-ROM drive), display adapter759, sound card761, speakers763, and network interface765. Other computer systems suitable for use with the invention can include additional or fewer subsystems. For example, another computer system could include more than one processor751(i.e., a multi-processor system) or a cache memory. The system bus architecture of computer system701is represented by arrows767. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems. For example, a local bus could be utilized to connect the central processor to the system memory and display adapter. Computer system701shown inFIG. 9is but an example of a computer system suitable for use with the invention. Other computer architectures having different configurations of subsystems can also be utilized.

While the above is a complete description of preferred embodiments of the invention, various alternatives, modifications and equivalents can be used. It should be evident that the invention is equally applicable by making appropriate modifications to the embodiments described above. Therefore, the above description should not be taken as limiting the scope of the invention that is defined by the following claims along with their full scope of equivalents.