CA2135973A1 - Interactive voice response system - Google Patents

Abstract

An interactive voice response system for use in client-server architecture provides a interactive voice response shell or manager which includes a module for reading Request Forms prepared in Text or ASCII and transmitted by an IVR client to the shell and extracting commands and data therefrom and transmitting the data to the caller in the manner prescribed by the form; a module for converting text files to speech and transmitting speech signals to the caller; a module for converting pre-recorded voice clips stored in memory to sounds and transmitting the sounds to the caller; a module for faxing files to the caller user and a module for decoding input entered by the caller on a telephone keypad and transmitting appropriate requests and data to the client.

Description

:~13S973 The present invention generally relates to client-server systems and, more specifically, to "Integrated Voice Response" systems.

BACKGROUND OF THE INVENTION
Access to information and the ability to send and receive information objects has been the market force of many new innovative products, most of which have been high end database specific products. The information is stored on one or more computers, referred to as "servers". The servers may be at the same or different locations. At the other end are customers and/or users who wish to access the data on the servers. Some customers and/or users can access the information by means of computers, computer terminals, workstations and the like. The computers may be of many different types including, for example, mainframe workstations, personal computers, Maclntosh, operating on different platforms. The interface between a user and a server is handled by a "client". This is generally referred to as "client-server" architecture where the "client" handles the interface with the customers and the "server" handles any requests submitted to it by the client. A client may be a computer system which is physically remote from the server(s). Clients and servers communicate with one another according to a predetermined protocol. Clients and servers software written under the same protocol are capable of communicating with each other.
One of the problems which has plagued the industry is that it has not been possible to run "client" software on all workstation types from any server type. An attempt at a solution to this problem is a system called "Gopher"~ which works well for information dissemination, but which does not permit the sending of objects back to the server or between servers.
Some manufacturers have attempted high end solutions to several platforms, but the client and server software was out of reach of the general public, particularly to potential customers who do not have access to a computer or a workstation.

Another problem which the industry has faced is that of making information available to users who do not have access to a computer.
Attempts at resolving this problem have resulted in "Integrated Voice Response" systems which provide a standard method of automated access to information using the telephone--be it a voice or touchtone interface.
Integrated Voice Response systems, usually known as IVR systems, allow for input or output of data by way of a series of menus through which the customer may navigate.
IVR systems, as they have existed thus far, have relied on a script, that is a special program to guide the telephone customer through a particular application. The menus, instructions, and help information that is presented to the customer are built into the script itself. External modules may be used for accessing data or for other low-level functions, but the intelligence of the system is encapsulated within the IVR script. This reliance on a script has kept traditional IVR systems application-specific. As a result, IVR access has required a lengthy and expensive development effort, perhaps entailing three to 10 person-months of time and costing from $50,000 to $250,000 per application. This development was done using proprietary language and had to be redeveloped from application to application. While the concept of serving information to a process intended to interface with a user via a telephone is not new, inasmuch as proprietary IVR systems have existed for several years, the provision of an IVR client which is independent of platform and which does not require application specific code has not yet been achieved.
Thus, a still further problem has been the considerable cost of implementing a new application or database. That is to say that, even after all of the data, which is desired to be made available to customers, has been assembled, there is still the lengthy and costly effort mentioned above to develop the mechanism which will enable customers to access the data.

.

SUMMARY OF THE INVENTION
Thus, in contrast with traditional IVR development activities, the present invention abstracts the IVR interface from the logic of associated applications by providing an "IVR shell" to handle IVR specific logic in 5 combination with a "thin client" to interface with application servers to thereby enable applications to be developed independently of interactive voice response technology. Through the use of the present invention, applications may be open simultaneously to methods of access both inside and outside of interactive voice response.
One aspect of the present invention is to provide a client-server system which is independent of the platform a user may be using and, in fact, which is capable of providing, via "Integrated Voice Response", the same services to a user who does not have access to a computer as those rendered to a user having a computer. To provide the same information to 15 a telephone user with the present invention, the user would simply point his "client" to the appropriate Internet address. In the event that an information Entrepreneur wanted to offer a new service, he would build a server using a high level construct in four hours to four days. The present invention reduces IVR development costs from a low of $0 to a high of $1,500.
20 Clearly, the economic savings are significant.
The present invention provides a client-server architecture in which the intelligence of the system is no longer contained within an IVR
subsystem itself. Rather, the present invention provides an IVR subsystem, or shell, which is responsible only for handling input and output via the 25 telephone and fax and thus is an interface between the customer and an "IVR client". The existence of this shell means that the IVR system is capable of accessing data from any of a number of different servers, many of which may not have been designed with IVR in mind. The organization of the data and the structure of the presentation is based on the natural 30 organization of the servers' data as interpreted by the client. Thus, it is not necessary for menus to be statically represented within the IVR subsystem, nor is it necessary to statically maintain any pointers to the data. All that ~13~973 is necessary is that the generic IVR client have a pointer to at least one server or can receive such a pointer, from the telephone customer, via the IVR shell.
In order to develop IVR Systems using the generic IVR Client-Server Architecture of the present invention, the components required are Skeletal code, written in some IVR development language, capable of interfacing with the generic IVR client and meeting defined l/0 requirements, an IVR
client, and one or more servers compatible with the chosen client.
The skeleton code could either be purchased or quickly developed, as will be seen later, according to supplied specifications. The generic IVR
client would be supplied. Developing an IVR system or systems under this paradigm would essentially equate to developing servers appropriate to the application or applications. Server development would, in turn, equate to populating a server with data and embedding any logic that was both allowed by the server and required by the server application.
The IVR client could make use of the gopher~ protocol which is very popular over "Internet" along with Masque~ protocol which extends the standard gopher protocol to include other types of electronic objects. The Internet is a world-wide TCP/lP-based network which is fast becoming the de facto standard for inter-network communication. Access to information over the Internet has traditionally been through "visual" clients which may be run on a wide range of computer platforms. The idea of accessing Internet-based information over the telephone leads to a novel bridging of technologies .
In order to achieve compatibility across platforms, the client according to the present invention communicates with the server by way of "forms"
which are text or ASCII files. ASCII files can be easily transmitted between different platforms. The forms contain instructions and data for use by the client and/or server. The client and server are programmed to "read" the forms so as to extract instructions and data and then execute the instructions. The client communicates with the server by transmitting a "Query" form to the server. The server communicates with the client by 21~5973 transmitting a "Result" form. The client communicates with a user having computer access by displaying menus on the users computer screen and with a user, having telephone access, through "shell" which translates menus to speech signals and transmits the speech signals over the 5 telephone line to the user. The shell communicates with the client by way of a message-passing protocol.
Thus, generally, the present invention includes an interactive voice response client and an interactive voice response shell. The interactive voice response client receives data from servers and in response sends 10 directives to the interactive voice response shell. According to these directives, the interactive voice response shell may pass information on to the caller or request information from the caller as appropriate for the directive. Conversely, in response to information received from the interactive voice response shell, the interactive voice response client will 15 transmit data back to the appropriate servers.
Under the current implementation, the data objects transmitted between the servers and the interactive voice response client are those allowed under the UWI Masque protocol and include, for example, UWI
Masque Forms which are structured data objects prepare in Text or ASCII.

~135973 -BRIEF DESCRIPTION OF THE DRAWINGS
These and other features of the invention will become more apparent from the following description in which reference is made to the appended drawings wherein:
5 FIGURE 1 is a block diagram representation of an Interactive Voice Response client-server architecture showing a server, a plurality of clients and an IVR shell or manager according to a preferred embodiment of the present invention;
FIGURE 2 is a view of the components of the IVR shell (or manager) and 10their relationship to external entities;
FIGURE 3 is a view of a visual display analogy of a menu output over the telephone by the present invention;
~fIGURE 4a is a view of a visual display analogy of a text file output over the telephone by the present invention;
15FIGURE 4b is a view of a visual display analogy of a text file output over thetelephone by the present invention;
FIGURE 5 is a high-level flow-chart of the system which includes interactions between the server(s) and the IVR client and between the IVR client and the IVR shell;
20FIGURE 6a is a flow chart illustrating the operation of a Form Reading Module according to a preferred embodiment of the present invention;
FIGURE 6b is a flow chart illustrating the operation of a Text Field Handling utility according to a preferred embodiment of the present invention;
FIGURE 6c is a flow chart illustrating the operation of a List Handling utility 25according to a preferred embodiment of the present invention;
FIGURE 6d is a flow chart of the "Get Input" process referred to in FIGURE 6b and FIGURE 6c;
FIGURE 6e is a flow chart of the "Read Text" process referred to in FIGURE 6c;
30FIGURE 7 is a flow chart illustrating the operation of a Text Reading Module according to a preferred embodiment of the present invention;

21~973 FIGURE 8 is a flow chart illustrating the operation of a Fax ProcessingModule according to a preferred embodiment of the present invention;
FIGURE 9 is flow chart illustrating the operation of a Index Processing Module according to a preferred embodiment of the present invention;
5FIGURE 10a is flow chart illustrating a high-level view of the IVR client's interaction with the IVR manager when a data object is received from one of the servers;
FIGURES 10b and 10c are flow charts illustrating a simplified view of the processes described in FIGURE 10a. FIGURE 10c is a more detailed 10description of the "Process data object as appropriate" function presented in FIGURE 10b;
FIGURE 11 is a flow chart illustrating the operation of the IVR manager and its interactions with the caller and with the IVR client. The abbreviations "int" and "t.o." represent "interrupt" and "timeoutn, 1 5respectively;
FIGURES 12a and 12b illustrate a sample Query Form transmitted by a client to a server and is similar to a Request Form transmitted by a client to the shell;
FIGURE 12c is a graphical representation of the Query Form illustrated in 20FIGURES 12a and 12b;
FIGURE 13a illustrates a sample Query Result Form transmitted by a server to a client;
FIGURE 13b is a graphical representation of the Query Form illustrated in FIGURE 13a.

21~597~

DESCRIPTION OF. .~c~tnltL~ EMBODIMENT
FIGURE 1 diagrammatically illuslrates a client-serversystem according to a preferred embodiment 10 of the present invention. The system includes one of more servers 12, one or more IVR clients 14, and one or more IVR
5 managers or shells 16. A user communicates with the system, and more specifically with a server, by means of a conventional telephone unit 18 over telephone lines 20 through two layers--the IVR shell and the IVR client. The IVR shell provides bi-directional communication with an IVR client while the IVR client provides bi-directional communication with a server. In the 10 preferred embodiment of the present invention, the system is of the type known by the trademark "UWI Masque" developed jointly by BC Systems Corporation and UWI Unisoft Wares. Inc. of Victoria, B.C., Canada. As explained more fully later, a client and a server communicate with one another by transmitting "Query" and "Query Result" forms which are 15 electronic documents in Text or ASCII format. Similarly, the IVR client communicates with the IVR shell by transmitting forms to the IVR shell.
These forms are written using Masque protocol and may contain both commands and data. The Masque system and protocol do not themselves constitute the present invention and therefore are not and need not be 20 described in detail.
The Masque server stores information in a relatively simple data structure. Generally, each application database is stored in its own directory on the server hard disk (not shown) or other mass storage device. The data which an IVR user wishes to access is stored in one or more text or ASCII
25 files which the server transmits to a client upon receipt of an appropriate request from the client. The client, in turn, transmits the file to the shell with a command to convert the text file to speech and transmit it to the user over the telephone as explained more fully latter. Each directory on the server may include sub-directories in which additional text files may be 30 stored.
The Query and Query Results forms can be created by computers in different platforms and programs, such as, for example, IBM personal 213!~973 -g computers and compatibles, Macintosh, MS-Windows, UNIX and VM. The shell(s), client~s), and server~s) are programs which may reside on the same or different computers at the same or different physical locations.
The present invention is particularly concerned with the provision of 5 an interactive voice response interface system which dramatically facilitates the development, implementation and operation of IVR applications. This is achieved by the IVR shell described below.
The IVR shell is designed to allow the IVR client to be easily ported to a number of IVR systems. The purpose of IVR shell is to provide an 10 interface between a telephone user and an IVR client. The IVR shell has the ability to issue three directives: initialize, interrupt and terminate.
The Initialize command is a command transmitted by the shell to the client when the IVR shell is first contacted by the telephone user. The command establishes a connection with the client, which contacts the 15 default server and receives a listing of the root directory of the server. The client then relays the server information to the IVR shell, allowing the user to actually hear the directory listing. The Interrupt command is a command transmitted by the shell to the client whenever the caller presses a key on the telephone keypad during normal operation. The command is 20 accompanied by data which indicates what input has been received from the caller. The data consists of a series of numbers and/or other characters which may represent new selections, data, or special commands. The Terminate command is a command transmitted by the shell to the client when the telephone user hangs up or selects <*9> to end a call. The 25 command signals to the client to terminate the connection with the IVR
shell. The IVR shell then remains inactive until it is activated by the next telephone call. Thus, in any given session, there will be one "Initialize"
command, a series of "Interrupt" commands and one "Terminate" command.
The IVR shell will not normally be configured or modified by a system 30 administrator. It acts strictly as a conduit between the telephone user and the IVR client.

2~S9~3 The IVR client receives messages from both the IVR shell, as explained above, and the Masque server, processes the messages and directs a final output to the IVR shell. The IVR client is inactive until it receives an Initialize command from the IVR shell. Requests from the client 5 to the shell may include the following: (1 ) Speak Text; (2) Speak Voice Clip;(3) Set Input Mode; (4) Get Input; (5) Fax Item; (6) Check Fax Status. The system has the ability to fax out documents, menus, and forms.
Once the client has received the Initialize command, it establishes a connection to the server by transmitting a Query Form to the server.
FIGURES 12a and 12b illustrate a sample Query Form. FIGURE 12c illustrates a graphical analogy of the Query Form as it would be displayed on a computer monitor. In accordance with a program loaded into the server, the server reads the Query Form, retrieves the data requested in the Query Form and transmits to the client a Query Result Form together with, in the 15 case of the Initialize command, the server directory listing. FIGURES 13a and 13b illustrate sample Query Result Form and a graphical analogy thereof. The client, in turn, transmits a Form with the information to the IVR shell with an instruction to "speak" the directory listing to the telephone user. The IVR client has the ability to send and receive input from the IVR
20 shell (via the interrupt command, with information from the caller) and to send and receive information from the Masque Server. In addition, the IVR
client instructs the IVR shell how to process the information that it passes on. The IVR client behaves like other, computer based Masque clients on various existing computer platforms, except that it translates "forms" into 25 a set of selections and fields that can be listed over the telephone.
When there is a need for the IVR client to read numbers, text or other input, such as directory selections, through the telephone, the IVR client instructs the IVR shell how to interpret incoming touch-tone telephone key-punches. In different cases, the incoming key-punches may be 30 interpreted as numbers, as in a telephone number; as alphabetical input, as in a person's name; or as alpha-numerical input, as in a mailing address.
The incoming text may also be read as strictly a YES/NO response. Once -the IVR Shell knows what type of vocabulary to recognize, the IVR shell can appropriately translate the keys hit on the touch-pad by the user and transmit the user's response to the client.
Whenever the IVR client sends information, it determines what form 5 of output to use, such as for example, text-to-speech, recorded voice clips, and facsimile. "Speak Text" is perhaps the most often used output mode in the IVR system. Whenever a caller hears a directory listing, a form presentation, or a text file is read to the user, text-to-speech is being used.
The shell is provided with appropriate software for converting text to 10 speech. Such software is commercially available and, accordingly, need not be described in detail.
Recorded voice clips are used for text that does not change in the system. Error messages and instructions, and requests for information are presented through recorded voice clips. For example, when the user first 15 enters the IVR system, a "recorded voice clip" that welcomes the caller to the system. The voice clips are stored on the shell hard disk or other suitable storage device together with appropriate programs for retrieving and playing selected voice clips to the user. Methods and programs necessary for creating, retrieving and playing the voice clips are well known in the art 20 and, therefore, need not be described in detail herein.
If the user has selected a long document, he/she may not wish to spend much time listening to the document being spoken over the telephone. At any time, the user can interrupt the text to speech by pressing an appropriate key or key combination, such as " *4". In response 25 to such a press, the shell asks the user whether he/she wishes to cancel the call or fax the item. If the user chooses fax, the IVR system requests a fax number. Once entered, the file will be sent to the fax machine.
FIGURE 2 is a view of the components of an IVR shell 16 and its relationship with a caller and a client 14. Each of the shell and the client 30 include a message passing module 30 and 32, respectively, which permit the shell and client to communicate with one another in a generic manner allowing application developers to incorporate appropriate commands into 213~73 -their applications, as explained later, with the result that very little effort need be expended developing the IVR aspect of the applications. FIGURE 2 illustrates how a caller sends speech and keypad input to the IVR shell or manager, the Shell sends output in the form of speech, voice clips, and fax, 5 to the caller, how the Shell communicated bidirectionally with the IVR client,and that the client communicates bidirectionally with one or more servers, i.e the client makes requests of the servers and the servers serve the requests.
A typical IVR session will now be described to illustrate the types of 10 items that can be accessed from the IVR system. This will include a description of Universal keys and what they mean, calling the first time and what to expect, retrieving and playing a server directory listing to the caller to allow the operator to specify a subject of interest, retrieving and playing a text file to the caller and retrieving an index. The following will include the 15 opening messages, and instructions about how to navigate through the system. Also included are graphics taken from other Masque clients, so that a visual representation of the session is available for comparison.
A number of main-level keys are provided, in order to facilitate navigation through the system. These are:
* * Help Passes on a list of all available key-pushes for the users current location *7 Repeat All Repeats all the items in the directory listing *9 Cancel Cancel the current action /listing, form, itemJ also doubles as a go-up-level key-press *0 Repeat last Repeats the last entry Appendix A contains a complete set of keypad commands according to the preferred embodiment of the present invention.

213~973 .

When a caller first dials into the IVR system, the followin~ message which is transmitted to the caller by the text-to-speech converter and provides a list of entries that can be accessed:
"Welcome to Masque. Please select one of the following:
1) Atlantic On Line 2) Example Forms 3) Example Images 4) Example Sounds 5) Example Video 6) The Bible"
Please enter a number from the previous list now.
The items shown are for illustration purposes only. All of the items are the 15 names of directories on the server. The long directory names shown are stored on the server in accordance with a technique which forms part of the UWI Masque system but which forms no part of the present invention. To select an item, the caller simply presses the appropriate key on the telephone keypad. When the caller presses a key, the IVR shell uses 20 underlying IVR technology well known in the art to convert the input to digital form and then transmits an interrupt message to the IVR client including the caller's selection as accompanying data. In this case, the client would retrieve and transmit to the shell a directory listing of the selected directory. For example, selecting number < 6>, "The Biblen, will 25 could present the following verbal message to the caller:
Retrieving menu...
Please select one of the following:
1 ) Bible Index 2) 00.index 3) 01 .genesis 4) 02.exodus 5) "
and so on all through the list. A computer user, as opposed to an IVR user, 35 would show the selections as shown in FIGURE 3. Each item represents either another directory or a text file.

2135g73 ln order to access one of these files, the caller again simply enters on the telephone keypad the number assigned to the item of interest. For example, when the user hits the number < 3 > key on the telephone keypad, the system responds with the following verbal message:
"Retrieving document.. Press any key to interrupt."
and from the file, speaks the following text:
"Gen 1:1 In the beginning God created the heaven and the earth. Gen 1:2 And the earth was without form, and void,...
A user who has accessed the system from a computer would view the 10 screen illustrated in FIGURE 4a on the computer monitor. While the text is being spoken over the telephone, the following function keys are available to the caller:
** Get Current Help instructions *4 Fax the document *7 Start the document again *9 Stop reading Hitting any other key will interrupt the reading of the document and the user will hear the following message:
Please select one of the following:
1) Bible Index 2) OO.index 3) 01 .genesis 4) 02.exodus 5) ...
25 as the system returns to the previous menu.
Retrieving an Index is a mechanism for searching for specific text through the text files stored in the server and the results of the process is a listing of all of the files which contain a string of text of interest. In order to look at an index, the user selects option <1 > from the above list.
Selecting < 1 > from a computer terminal will present the user with the Graphical Search Criteria dialogue box shown in FIGURE 4b and on a telephone, the user will hear the following messages after having entered a word for which the user wishes to search:
"Retrieving. . .
Please enter the word or words to search for. Please enter the words using the keypad. Enter the next letter followed by the 213~973 pound key. Please enter the next letter followed by the pound key or press *~ for help."
The available help keys are:
*9 for cancel *0 to back up one letter When the index retrieval utility is in operation, the telephone keys are mapped with the letters on a touch-tone telephone with some additions as follows:
Telephone Pressed Twice Thrice Four Key Once Times In order to enter text, the user presses each key until its value is that of thedesired letter and then presses the pound key to signify that the character is correct. The shell echoes each character as it is entered via the keypad;
this helps the user enter the text properly. To finish entering text, the user selects the pound (#) key on its own to instruct the system that there is no more text to be entered and to proceed with the search. The shell then reads out the pronunciation and spelling of the word that was entered and prompts the user to confirm that it is correct before actually engaging in the search .
For example, to enter the word "Quest", the user would start by hitting the number <O>, then the pound key <#> to signal the letter <Q>; press the number <8> twice, followed by the pound key <#> to signal the letter <U>; and so on. The user would finally enter a single pound key <#> to signal that the caller has finished entering text. Thus, to search for the word "creation" in the Bible directory, the caller would 213~973 enter the word "Creation" via the touch-tone keypad bV hitting the following keys:
222# 77# 33# 2# 8# 444# 666# 66# #
C R E A T I 0 N #
5 After hitting the final ~ # > key, the IVR shell wil! respond with the message:
You entered creation, spelled C-R-E-A-T-I-O-N is this correct7 Please select one of the following: press 1 for yes or 2 for no If the user entered the word "creation" correctly, he would press ~1 > for 10 YES; otherwise, he would press < 2 > for N0 and re-enter the text. When the user presses < 1 >, the system responds with "searching . . . n then plays the following message in response to Index search for "creation":
Please select one of the following:
1) 41.mark (2 key words found) 2) 45.romans (2 key words found) 3) OO.index (1 key word found) 4) 61.2-peter (1 key word found) 5) 66.revelations (1 key word found) This list is a compilation of all the text files in the server directory which include the word "creation". Selecting entry number 4 will cause the following message to be spoken over the telephone:
Retrieving document... press any key to interrupt.
followed by reading of the document "61 .2-peter" over the telephone. The user can interrupt the read-through of the text file by selecting any key.
If, while the text is being read, the user wishes the document to be sent to a facsimile machine, the user press <*4>. The user will be prompted with the following messages:
Please enter your fax number, followed by the pound key.
The user enters his fax number, i.e. 1234567, followed by the <#> key and the system then responds with:
Your fax number is 1234567, is this correct? press 1 for yes or 2 for no ~ L3~ 973 -lf the number is correct, the user presses ~ 1 > on the telephone keypad to which the system responds with the following will be spoken message across the telephone:
Sending document to the Fax machine.. Document sent.
Selecting < *9> will present the user with the index list. Selecting < *9> again will ask the user:
Do you want to search again? press 1 for yes or 2 for no.
The user would press <2~ to return to previous menu level or select < *9> to go up one level to the "Bible Index" directory listing. To end a session, the user simply hangs up.
Reference will now be made to FIGURE 5 which is a high-level flow-chart of the system and includes interactions between the server(s) and the IVR client and between the IVR client and the IVR shell. As shown at 200, the system waits for a caller to dial in. Once a caller has dialled in, theIVR shell sends an initialization message to the IVR client as shown at 202.
The IVR client then connects at 204 to the appropriate server, as specified in the initialization command. The server returns data to the client at 206.
At 208, the client sends message(s) to the shell based on the data received from the server. The shell interacts with the caller at 210 based on message(s) received from the client and sends a message(s) to the client at 212. After input has been obtained from the caller or a timeout has occurred, one of two things happens. If the call is terminated at 214, both the client and the shell perform some clean-up activity (erasing temporary files, etc.) at 216. Otherwise, if more data is required as indicated at 218, the client sends a request for data to the appropriate server at 220. Steps 206-212 are then repeated.
FIGURES 6a, 6b and 6c is a flow chart illustrating the basic operation of Form Reader Module 34. As previously mentioned, module 34 retrieves a Request Form transmitted by the IVR client and processes or parses it to determine identify the client commands and data. The Request Form would be comparable to the forms illustrated in FIGURES 12 and 13. Generally, the module reads the each item at 50 in the Request Form, determines at 52 ` 2135~73 whether it is a text field or a list field or a list (i.e. Iist box, pop-up menu, or directory listing). Text fields are processed at 54 according to a utility illustrated in FIGURE 6b while list fields are processed at 56 according a utility illustrated in FIGURE 6c. After processing a text or list field, the 5 module determines at 58 whether the caller has pressed a key. If not, it determines at 60 whether the end of the Request Form has been reached.
If the end of the form has not been reached, the module retrieves at 62 the next item in the form and repeats the process starting at 52. If the end of the form has been reached, control is returned to the main program at 64 10 which waits for the caller to press a key. The program may include timing functions which remind the caller to press a key and to hang up in the event the caller does not respond after two or three warnings and a certain amount of time has elapsed. If, after processing a text or list field, the module determines at 58 that the caller pressed a function key, the module 15 determines at 64 whether the function key was < *9 > for cancel or < *4>
for fax. If cancel was pressed, control returns to the main program; if fax was selected, the fax module illustrated in FIGURE 8 is invoked and the module thereafter continues processing the Request form at 60.
FIGURE 6b illustrates text field processing utility 54. As can be seen, 20 the utility solicits input from the caller at 70, determines at 72 whether the input is data or a function key. If the input is a function key, then control returns to the calling program at 74 and the function key is processed as described above. Otherwise, the utility determines at 76 whether the key pressed signals the end of input. If so, control returns to the calling program 25 at 74, otherwise the utility gets further input from the caller at 70.
FIGURE 6c illustrates List Handling utility 56. A list includes directory listings, the results of index searches, and the like, stored in a text file. Ascan be seen, the first step at 80 is to retrieve the first element in the file and read it out to the user at 82 by means of the text-to-speech converter. The 30 utility determines at 84 whether the caller interrupted the transmission by pressing a key on the telephone keypad. If not, it retrieves the next item of the list at 86 and transmits it at 82. It repeats steps 82, 84 and 86 until the 213S97~

,9 list has been completed and then waits for caller input at 88. If the caller interrupted the transmission 84 or when the utility receives caller input at 88, the utility determines at 90 whether the keypress is data or a function key. If it is data, the utility determines at 92 whether a valid selection has 5 been made. If so, the selection is returned to the calling program at 94, otherwise the program returns to 82. When a function key is pressed, the program determines the identity of the function key at 96 and processes the request accordingly.
FIGURE 6d illustrates the "Get Input" function (70, 88) in grater 10 detail. As shown, the IVR client sends the IVR shell a "Get Input" request and the shell responds by sending a corresponding message to the caller and then waits for input from the caller. If the caller enters input, the shell sends that input to the client. If the caller takes too long in entering input, the shell sends a timeout error code to the client and, if there have been too 15 many timeouts, the client sends a "Hangup" message to the shell.
Otherwise, the client sends a "Read Text" message to the shell which prompts the caller to make a selection. The client then continues to wait for the shell to pass on some input from the caller.
FIGURE 6e illustrates the "Read Text" function 82 in greater detail.
20 As shown, the client sends the shell a "Read Text" request including the data to be read out to the caller. The shell responds by reading out the specified text. If the shell is interrupted by the caller, it stops reading, collects the user input, and sends the input to the client. If it is not interrupted, but experiences any other problems, it sends an error code to 25 the client. If the shell completes the reading successfully, it sends a message to the client signalling its successful completion and then waits for further activity.
FIGURE 7 illustrate the operation of text-to-speech converter module 36. When called by the main program, module 36 retrieves at 100 the first 30 sentence of the file and reads it at 102 and then retrieves each sentence of the file at 104 and reads it at 102 until either the end of the file has been reached as determined at 106 or the caller has pressed a key. The module ` 2135973 returns to the calling program at 108 when the end of the file has been reached. If interrupted during the reading of a file at 110, the module determines at 112 whether the keypress was a function key. If not, it ignores the keypress and continues reading the file at 104. If the keypress was a valid function key, then the module executes the appropriate commands as shown at 114, 116, 118, lZ0, 122 and 124. FIGURE 8 illustrates the module for transmitting a fax. This process was generally described earlier.
FIGURE 9 is a flow chart illustrating the procedure for specifying a search string which will be used to retrieve an index as generally explained earlier. It will be recalled that to enter a search string, such as the word "creation", the caller presses one or more keys followed by a <#> key in order to enter an alphabetic character and then pressing the < # > when all characters have been entered. The first step at 130 is to prompt the user to enter the desired data. To do so, the system employs the text field processing utility 54 illustrated in FIGURE 6b. Following each keypress, the utility determines at 132 whether the keypress is a function key and, if so, processes the key at 134 according to predetermined code. If the key is the cancel key, the program is aborted at 134 and control reverts to the calling program at 136 otherwise control returns to the text field processing utility at 130. If the keypress is not a function key, the utility prompts the user to confirm the text entry at 138 and waits for a response at 140. If the caller presses <2> at 142, the program returns to 130 where the user re-enters the search string. If the user presses < 1 >, the search string is stored at 144 and control returns to the calling program at 136. The calling program then transmits an appropriate interrupt signal to the client together with the search string information and waits for the search results.
FIGURE 10a is flow chart illustrating a high-level view of the IVR
client's interaction with the IVR manager when a data object is received from one of the servers. As shown, when the client receives a data object from the server, it processes that object according to its type. If the object is a list box, popup menu, or directory, it will invoke a procedure to handle lists. If the object is a form, it will invoke a procedure to handle forms. If the object is a text file, it will invoke a procedure to handle text files. If the object is a search object, the client will invoke a procedure to handle searches .
FIGURE 10b is a simplified view of how the client responds to a data object from the server while FIGURE 10c is a more detailed view of the process from the client's point of view. As shown, the client first sends a message to the shell and then receives a message, usually a response, from the shell. The client updates its internal data stores as appropriate. If the client is not done processing the object, it sends another message to the shell and the continues the process until the object has been fully processed.
FIGURE 11 is a flow chart illustrating the operation of the IVR
manager and its interactions with the caller and with the IVR client. The abbreviations "int" and "t.o." represent "interrupt" and "timeout in waiting for input from the callern, respectively. If the caller enters some input, whether or not it interrupts what the shell is doing, the shell processes the input, sends the input to client, and then ceases processing until another event, such as a client message or caller input, occurs. If the caller receives a message from the client, it determines the type of message and processes it accordingly. As shown, the message types are "Speak Text" in which the shell reads the specified text to the caller; "Speak Voice Clip" in which the shell plays specified voice clip to the caller; "Set Input Mode" in which the shell changes input options (timeout value, type of input expected, etc.) as specified within the message. Any of these three procedures can be interrupted by user input, in which case, the shell stops what it is doing and sends the input to the client. The message type also includes "Get Input"
in which the shell waits for input from the caller or until a timeout occurs;
"Fax Item" in which the shell sends the specified item to the caller via facsimile; "Check Fax Status" in which the shell sends the status of the specified fax job to the client.
Thus, in contrast with traditional IVR development activities, the present invention abstracts the IVR interface from the logic of associated ~l35973 applications by providing an "IVR shell" to handle IVR specific logic in combination with a "thin client" to interface with application servers to thereby enable applications to be developed independently of interactive voice response technology. Through the use of the present invention, 5 applications may be open simultaneously to methods of access both inside and outside of interactive voice response.
It will be seen from the foregoing that the present invention provides a very simple and effective mechanism for effecting an interactive voice response system. The mechanism is in the form of a shell or manager which 10 includes a module for interpreting messages transmitted by the IVR client to the shell and extracting commands and data therefrom and transmitting the data to the caller in the manner prescribed by the form; a module for converting text files to speech and transmitting speech signals to the caller;
a module for converting pre-recorded voice clips stored in memory to sounds 15 and transmitting the sounds to the caller; a module for faxing files to the user and a module for decoding input entered by the caller on a telephone keypad and transmitting appropriate requests and data to the IVR client. It will be understood that various modifications and alterations may be made to the preferred embodiment described herein without departing from the 20 spirit of the present invention. For example, it will be understood that while the preferred form of communication between the shell and client is by way of a particular message-passing protocol, the shell could be arranged to interpret messages in other formats. Further, while the preferred client-server protocol is the UWI Masque protocol ~mentioned earlier), any suitable 25 protocol may be used. All that is required is that the message interpreting module be capable of recognizing the commands and data contained in the requests transmitted by the IVR client. It will also be seen that the operation of the IVR shell/manager is independent of the server and the manner in which it operates and stores information. The IVR client 30 communicates with the server and therefore isolates the shell from the server. Setting up an IVR-fronted client-server system using this technology is particularly simple when the UWI Masque protocol is used for client-server -communications since there is already an IVR client available for this protocol; however, any client can be modified to communicate with the IVR
shell according to the defined message-passing protocol. See Appendix B
for a definition of the message-passing protocol.

APPENDIX A - USER INI'ERFACE
This appendix describes the interface presented to the user by the i~ ;Live voice response shell.

Overview Input Spoken letters Spoken words (possibly) Numerical keypresses Special-function keypresses Output Spoken text (recorded and/or synthesized).

User Interfaces (according to function) This section describes, for each function, any valid keypad entries and their co--esl)ol.di--g effects.
. , Proc~.s.~i..g a Button * 1 n/a *2 n/a *3 n/a *4 fax form *5 n/a *6 n/a *7 hear the current item again *8 n/a *9 cancel reading form *O n/a ** help [0-9, a-z] valid where applicable;
error message otherwise * n/a tab to next form item Proc~-c.~ing a Check Box see processing a Button.
Proc~c~ing a Directory see Processing a List.

Proc~ccin~ an Edit Field * 1 n/a *2 correction (backspacing delete key) *3 n/a *4 fax form *S n/a *6 r~a *7 hear the current item again *8 n/a *9 cancel form *O n/a ** help [0-9, a-z] character input: 0-9, a-z, <space:>, '.', '!', '@' * n/a # tab to next form item Proc~i"g a List * I root request *2 repeat previous list item *3 n/a *4 fax list *S n/a *6 rla *7 repeat reading entire list from beginning *8 n/a *9 cancel reading list *O n/a ** help [0-9, #, *] n/a [0-9 outside range, *, #] n/a Proc~.ccing a List Box see Processing a List.
Proc~c.cing a Popup Menu see Processing a List.
Proce.s.cing a Radio Button see Processing a List.

~l 35~73 ~,i.ctPnin~ to Text * 1 n/a *2 . page up *3 page down *4 fax text *5 find next keyword *6 n/a *7 start reading from top of document *8 n/a *9 stop reading *O n/a ** help [0-9, #, *] n/a -APPENDIX B - MESSAGE-PASSING PROTOCOL
This appendix describes the message passing protol employed between the interactive voice response client and the interactive voice response shell.

Constants Message Tags MESSAGE REQUEST TAG RESPONSE TAG
Tnili~li7P 1' 1' Hang Up 1'` 1'`
Interrupt 13 1:
Set Input Mode 14 14 Speak Text 15 15 Spe lk Tag 16 16 Fax.. tem 17 17 Get Fax Status 18 18 Terrninate 340 340 Return Codes RESULT - RETURN CODE

INTERRUPT see Message Codes TERMINATE see Message Codes FAIL ` - I
FAIL - No response -2 FAIL - Must connect -3 FAIL- Unknown vocabulary -4 FAIL - Un-eco~;.. i~d text -5 FAIL - Unknown item type -6 FAIL - Tag not found -7 FAIL - Hardware problem -8 FAIL - File not found -9 FAIL - Still in progress -10 FAIL - No answer possible -11 Text Type Codes TEXT TYPE CODE
Not Specified 30 Alpha-Numeric ' 1 Numeric -2 Alpha ~3 Date 34 Time 35 Fax Type Codes FAX ITEM TYPE CODE
Text 41 Vocabulary Codes VOCABULARY CODE
No Interrupt 50 Menu Pick 51 Text Entry 52 Form 53 Yes/No Prompt 54 Player 55 Number Entry 56 213~g73 w Messagc r;~il.g Two primary message types:
1. IVR Directives: - Sent by the IVR subsystem.
- Does not trigger any acknowledgement.
- Include: Initialize and Terminate.
2. Client Requests: - Sent by the IVR/Masque client.
- Trigger r~ s from the IVR subsystem.
- Include: Speak Text, Speak Tag, Fax Item, and Interrupt..

21~5~73 IVR Directive: Initialize Record Layouts Note: IVR HEADER is assumed to contain the reque;,L/,~ nse tag.

In-" ' Directive ¦ IVRHEADER ¦ C~ Filename (String, null t~"lnilla No Acknowledgement.

~13~973 IVR Directive: Interrupt Record Layouts Note: IVR HEADER is assumed to contain the reque~L/~ )se tag.

Interrupt Direc~ive IVR HEADER ¦ Text ¦ Status ¦ (String, null terrninated; max bytes: 127+1) l (int, 4 bytes) No Acknowledgement -IVR Directive: Termin~te Record Layouts Note: IVR HEADER is assumed to contain the request/-~spol)se tag.

Terminate Directive ¦ IVRHEADER ¦ Te. '-a, Code ¦ ExitCode ¦ FILLER
¦ (1 Byte) ¦ (I Byte) ¦ (2Bytes) No Acknowlegement.

Results Terminate - Client drops current Form or menu.
- Client perforrns cleanup.
- Client waits for the next Initialize Directive.

Client Request: Speak Text Record Layouts Note: IVR HEADER is assumed to contain the request/response tag.

Speak Text Request IVRHEADER ¦ Text ¦ TextTypeCode ¦ C~ ' '¦ (String,null-terminated;maxbytes:127+1) ¦ (Int,4bytes) ¦ (Int,4bytes) Notes: (I) Continuation Flag O - End of Message I - More to Come Speak Text Response IVR HEADER ¦ Return Code ¦ (Integer, 4 bytes) Results Read Text Return Code Result Reason SUCCEED Reads text to user FAIL - Unintelligible text INTERRUPT
TERMINATE

21~5973 Client Request: Speak Tag Record Layouts Note: IVR HEADER is assumed to contain the request/~s~nse tag.

Speak Ta~Request IVR HEADER ¦ Tag ¦ (String, null-terrninated; max chars: 127) Speak T~Response IVRHEADER ¦ Return Code l (Integer, 4 bytes) Results Read Text Return Code Result Reason SUCCEED
FAIL- Hardware problem FAIL - Tag not found INTERRUPT
TERMINATE

- 213~9~3 Client Request: Fax Item Record Layouts Note: IVR HEADER is assumed to contain the request/response tag.

Fax Item Request IVRHEADER ¦ Filename ¦ Type ¦ PhoneNumber ¦ (String, null te,~ ated; max bytes: 127+1) l (int, 4 bytes) ¦ (String, 47+1) Fax Item Response IVR HEADER ¦ Return Code ¦ Job ID
(Integer, 4 bytes) (Integer, 4 bytes) Fax Item Return Code Result Reason SUCCEED IVR has llall~ll~iU~d the fax.
Returns Fax Job ID.
FAIL - File not found Client will recreate file and try again File not found (up to n times).
FAIL - Hardware problem Client will inform user. Fax manager not running; No phone lin INTERUPr TERMINATE

Client Request: Set Input Mode Record Layouts Note: IVR HEADER is assumed to contain the request/ ~<n~se tag.

Set Input Mode Request IVR HEADER V~ '~ Code Initial Timeout Inter-Word ~ Word (Integer, 4 bytes) (Integer, 4 bytes) Timeout Count (Integer, 4 bytes) (Integer, 4 bytes) Set Input Mode Res~onse IVRHEADER ¦ ReturnCode ¦ (Int, 4) Results Set Input Mode ReturnCode Result Reason ~UCCEED Retrieves text EAIL rlmed out or Unrecognizable Input INTERRUPT
TERMINATE

2135~73 Client Request: Get Fax Status Record Layouts Note: The IVR HEADER is assumed to contain the request/l~l,onse tag.

Fax Item Request IVR HEADER ¦ Job ID
(Integer, 4 bytes) Fax Item Response IVRHEADER ¦ Return Code I (Integer, 4 bytes) Results Fax Item Retur~ Code Result Reason SUCCEED IVR has lla~ ed the fax.
Retums Fax Job ID.
FAIL - File not found - Client will recreate file and try again File not found (up to n times).
FAIL - Hardware problem Client will inform user. Fax manage;r not running; No phone li FAIL - Still in progress FAIL - No answer possible INTERUPT
TERMINATE

Claims (10)

1. An interactive voice response manager for interfacing a telephone user with an database application server, comprising:
means for connecting to a telephone line;
means for converting to speech text contained in a text- file;
means for storing one or more voice clips;
means responsive to a predetermined input signal for playing one of said voice clips to said telephone line;
means responsive to an incoming telephone call for transmitting an initialization command to an IVR client;
means for terminating a telephone call;
means responsive to a client command for activating one of said means for playing voice clips, means for converting text files and said means for transmitting; and means for transmitting a user input to said client.

2. An interactive voice response manager as defined in claim 1, further including means responsive to a user input signal for transmitting a text file by facsimile.

3. An interactive voice response manager as defined in claim 1, said means responsive to a client command including means for retrieving a text file transmitted by said client, reading in sequence from beginning to end each item in said text file and, for each item:
a) determining whether said item is a text field or a list box;
b) processing a text field according to a first method and processing a list box according to a second method;
c) determining whether a key has been pressed by the user and processing a key command.

4. An interactive voice response manager for interfacing a telephone user with an interactive voice response system having at least one database application server and one or more interactive voice response clients, each client being operable to communicate with said one or more servers for retrieving information stored therein, said manager comprising:
connector means for connecting to a telephone line for transmitting and receiving telephone signals and for digitizing received signals;
a text-to-speech convertor for converting words contained in an electronic file into speech signals and transmitting said speech signals to said connector means for transmission along said telephone line;
a voice clip processing module for retrieving pre-recorded voice clips and transmitting said voice clips to said connector means for transmission along said telephone line;
Form Reader means for parsing Request Forms received by said manager from one of said clients for extracting commands and data therefrom;
and controller means responsive to digitized signals received output by said connector means for communicating said signals to one of said clients and to receipt of Request Forms from one of said clients and causing said Form Reader means to extract commands and data therefrom and thereafter instructing one of said text-to-speech convertor and said voice clip processing module carry out said commands.

5. An interactive voice response system comprising:
interface means for receiving a telephone user input and transmitting an appropriate command;
at least one server for storing data in a predetermined format and responsive to a command representative of a request for information for retrieving and transmitting the request information; and at least one client responsive to a first interface means command by establishing a connection with one of said at least one servers, retrieving directory information from said at least one server and transmitting said directory information to said interface means with a first client command to output said directory information as a audible message to said user.

6. interactive voice response system as defined in claim 5, said interface means including:
connector means for connecting to a telephone line for transmitting and receiving telephone signals and for digitizing received signals;
a text-to-speech convertor for converting words contained in an electronic file into speech signals and transmitting said speech signals to said connector means for transmission along said telephone line;
a voice clip processing module for retrieving pre-recorded voice clips and transmitting said voice clips to said connector means for transmission along said telephone line;
Form Reader means for parsing Request Forms received by said manager from one of said clients for extracting commands and data therefrom;
and controller means responsive to digitized signals received output by said connector means for communicating said signals to one of said clients and to receipt of Request Forms from one of said clients and causing said Form Reader means to extract commands and data therefrom and thereafter instructing one of said text-to-speech convertor and said voice clip processing module carry out said commands.

7. An interactive voice response system as defined in claim 1, said client including means for translating "forms" into a set of selections and fields which can be listed over a telephone.

8. An interactive voice response system as defined in claim 1, said client further including means for instructing said manager how to interpret incoming key punches from a telephone.

9. An interactive voice response system as defined in claim 8, said instructing means being operable to instruct said interface means to interpret said key punches as numbers, alphabetical input, alphanumeric input or as a YES/NO response.

10. An interactive voice response system as defined in claim 1, said client further including means for determining the form of output to said telephone, said form of output including text-to-speech, recorded voice clips and fax.