Source: {"pile_set_name": "USPTO Backgrounds"}

An Interactive Voice Response (IVR) system in its simplest form automates the process of directing calls to the appropriate individual. In recent years, however, IVR systems have evolved into very complex computerized voice applications that enable callers to order products, for example, over the telephone and without ever being connected to a human being. Such systems require tremendous human effort to develop and maintain due to a large number of interconnecting dialog states. A dialog state may be thought of in terms of the information between when a caller provides an input and when the system waits for the next input (e.g., pressing of a number on a telephone handset or a verbal command) from the caller in order to determine a next dialog state. For example, a caller to a pharmacy may be first instructed to “press 1 for English or press 2 for Spanish.” If the caller presses “1”, then the IVR system traverses to an English language dialog state where the user is prompted to “enter 1 to refill your prescription; 2 to speak with a pharmacist; or 3 to check the status of your refill order.”
IVR applications are constructed in a similar manner to standard computer applications and HTML web pages. In fact, VoiceXML (“VXML”) is a simple Extensional Markup Language standard created specifically for developing IVR applications. While the language standard may be simple, the IVR applications that are built off of it may be incredibly complex and thereby difficult to test. Traditionally, system testers take on the role of end users by calling the IVR system and interacting with the system as would be expected from an average end user. Therefore, it is easy to appreciate that testing very large and complex systems requires the expenditure of many man-hours and further requires attention and patience. Testing with large numbers of accounts and testing of all (or most) paths is usually impossible in the prior art. Testing, however, is vital to ensuring that all of the paths correctly link the various dialog states.
In recognition of the problems associated with creating, testing, and maintaining IVR applications, tools have been developed to assist in the testing process. Load testing tools include a call-processing unit that places a number of simultaneous and/or repeated calls to the IVR application. While these tools have the ability to detect deviations in application response (e.g., length of pause between inputs, length of audio cues, system hang-ups, etc), these tools do not provide insight into the actual behavior of the voice application. The test scripts used in such load testing, in the prior art, must be manually created and then later updated each time the application is changed.
Therefore, a need exists for a system that facilitates testing of IVR voice applications in a less time consuming manner, and facilitates reducing the time to develop a voice application. A need exists for a system that facilitates testing of a greater number of the call flow paths of a voice application. A need exists for a system that can discover the call flow paths of a voice application, and perform a complete voice application analysis through direct interaction with the voice application.