Voice Response System With Programming Language Extension

1. Field of the Invention

The invention relates to telephony voice response systems, and more particularly, to the extension of database languages to handle telephony voice response functions.

2. Description of Related Art

An interactive voice response (IVR) system is a system which allows callers to use a telephone to interact with a remote computer and retrieve data from, or enter data into, one or more databases. Usually callers enter information and commands by pressing buttons on a tone-generating telephone. The telephone generates a DTMF-encoded (dual-tone multi-frequency) signal in response to such buttons, and transmits the tones to the voice response system. The voice response system decodes the tones to determine which buttons were pressed, and proceeds accordingly. In other systems, callers enter information and commands by speaking into the telephone. In such a situation, the voice response system recognizes the words spoken and proceeds accordingly. IVR systems can be as simple as ordinary voice mail systems, or can be highly complex, with multiple menus and caller-data-entry facilities. They can support either a single telephony channel or multiple simultaneously active telephony channels.

IVR systems are typically developed by programming a general purpose computer system that has telephony hardware installed. For example, IVR systems often include a DOS-based personal computer with a telephony expansion card installed, such as a TyIN 4000 Pro Personal Communication Assistant, available from National Semiconductor Corporation, Santa Clara, Calif., or a Model D/41 available from Dialogic Corporation, Parsippany, N.J.

IVR systems usually need to have a high degree of flexibility for customization by value-added resellers (VARs) and by the MIS departments of end-user customers. VARs will often customize an IVR system for the needs of a particular customer, and many customers need to be able to modify their IVR systems themselves to meet changing requirements for their callers.

In the past, many IVR systems were difficult to customize because they were programmed in an ordinary, general purpose program language, such as C or C++. In order to speed application development and customization, some IVR system suppliers have developed proprietary libraries of C-language procedures which could manage both the control of the telephony hardware and also the data that the caller is accessing. Other suppliers have developed proprietary scripting languages, and provide an interpreter program written in C (or another general purpose programming language). The interpreter follows a script prepared by the developer. Still other suppliers have developed form, table or graphical (GUI) programming environments for IVR system development or customization. VARs and enduser customers have found all of these mechanisms difficult to learn and use, however, and this has restricted the growth of the IVR market.

One of the problems with the above mechanisms for IVR system development is that while they may be well-suited to managing the telephony aspects of the system, they are not as well suited to managing the database aspects of the system. Database management is best performed by facilities which are designed for that purpose, namely database management systems. A database management system (DBMS) is a software package designed to operate on a collection of one or more computer-stored files, or what is referred to as a database. Its primary operation is to select database records that have user-specified common characteristics, and retrieve those records for further processing and display. The database management system also adds new records to the database, and modifies existing records as desired. A typical database management system can include a non-procedural user interface through which a user at a terminal can cause the DBMS to perform desired operations on the database. A typical DBMS also includes a high-level programming language (referred to herein as a database language or a DBMS language) that can be used procedurally to operate on the data in the database. Often both the non-procedural interface and the procedural interface call a common set of procedures, referred to herein as the database engine, to perform the desired operations on the database. The simple, high-level commands supported by DBMSs to manage a database, such as "seek", "replace", "sort", and so on, are quite powerful. However, DBMSs do not support telephony functions.

It is desirable to use DBMSs in IVR applications also because they inherently manage their databases in the "native format" of the DBMS. Unlike general purpose programming languages which provide enormous flexibility to programmers in the formation of data structures, database management systems organize their databases in a predefined format which users rarely, if ever, need to understand. The high-level commands of a DBMS obviate any necessity for the programmer to be concerned with the underlying format in which the data is actually stored.

Once the data is already maintained in the DBMS native format, a host of additional applications become possible. DBMS language programs can be written easily to operate on the data independently of the telephony connections. For example, a bank might create and manage all of its account information using a DBMS, and have an IVR system for customers to call to retrieve such information. Such an IVR system would need to be able to obtain the desired information from the database in the DBMS native format. As another example, an IVR system might be designed to obtain information from callers and place the information in a database; reports can then be easily generated from the data using the various user interfaces of the DBMS. Thus an IVR system which maintains its data in the native format of a DBMS can be much more tightly integrated with the remainder of the customer's business.

In one conventional attempt to integrate native format database management in IVR systems, the IVR system and a database management system were set up to operate independently on two separate computer systems. The IVR system communicated with the DBMS system via terminal emulation, in which the IVR system acted as a user terminal communicating and receiving individual characters from a non-procedural terminal interface of the DBMS. The software for the IVR system was written in a general purpose programming language, and the character stream to and from the DBMS system took place through an ordinary I/O port of the IVR system computer. As might be expected, the terminal emulation technique can be extremely slow, inflexible, and arcane.

Another way that IVR system developers have sought to operate on a database in a native DBMS format, as part of an IVR system, was to provide a procedure library, written in a general purpose programming language such as C, which could be compiled with or linked to the main program module of the IVR application, also written in C. However, this technique required a detailed understanding of the DBMS native format and, in large part, duplicated all of the effort that DBMS manufacturers had already expended in the development of their own database engines and tools. It is also rare for IVR system developers to have the expertise necessary to optimize database management software to run as efficiently as that available from the DBMS manufacturer.

Accordingly, as can be seen, prior attempts to integrate IVR systems with native format DBMS databases have left much to be desired. The present invention achieves such integration much more effectively.

Many existing DBMS languages can be extended using library extension modules. Thus a developer of a database language program can create a proprietary library for operating on the database or for performing other functions, and can then access the procedures of the library in the same manner as the ordinary procedures of the database engine are accessed. For example, the FoxPro.RTM. database management system, available from Microsoft.RTM., includes a "library construction kit" which allows developers to create external libraries of C-language routines that can be integrated into any FoxPro application through a predefined external FoxPro application programing interface (API). Once the library is installed, a FoxPro language program invokes an extension procedure merely by calling it in the same manner that it calls FoxPro built-in procedures. The FoxPro library construction kit is described in Microsoft, "FoxPro.RTM. Library Construction Kit, Developer's Guide" (1993), incorporated herein by reference.

Another example of a DBMS which allows language extensions is Informix 4GL. Extensions for this database language are described in Informix, "Informix-4GL Rapid Development System, Unix Products Installation Guide and Release Notes", Rev. A, pp. 1-59-1-76 (1988), incorporated herein by reference.

These DBMS systems can be thought of as being organized into three components: (1) a database language sequencer module, which follows a database language script (either as an interpreter or as compiled code); (2) a database engine module which contains the DBMS's built-in procedures for operating on the database; and (3) the extension library module, which contains the developer's extension library procedures. The database language sequencer traverses the script, and calls the procedures in either the database engine module or the extension module as required by the script. The interface to these procedures is the same for both the database engine module and the extension module, as set forth in the above-incorporated references.

Although extension library capabilities have been available in DBMS languages for a long time, they have not heretofore been used for telephony operations. One possible reason for this is that those working in the telephony field developing IVR applications, are used to working in either general purpose programming languages such as C, or in specialized languages developed specifically for telephony operations only.

Accordingly, the invention involves the addition of a telephony library extension to a DBMS that has a programming language, with the resulting combination executing on computer hardware to form a telephony server. In one embodiment, telephony server apparatus includes a database and software instructions executable by a processor structure, the software instructions including a database language sequencer, a database control module having a plurality of procedures callable by the database language for performing at least one database operation, and a telephony control module having a plurality of procedures callable by the database language sequencer for performing at least one telephony operation. The database operations include at least the operations of reading and writing data to a database, and the telephony operations include at least the operations of speaking a predefined prompt onto a telephony channel, receiving and storing DTMF-encoded input from the telephony channel, and recording audio input from the telephony channel. The database language sequencer calls the database control module procedures and the telephony control module procedures in a sequence defined by a program prepared according to the rules of a database language. The database language sequencer can include either an interpreter or compiled code.

The telephony server apparatus can control multiple telephony channels by running a separate task for each such channel under a multitasking operating system. The above software can be instantiated separately for each task, or parts can be separated out and provided in a common task communicating with the individual channel tasks via inter-process communication (IPC), shared memory, or by another mechanism. In one embodiment, a common channel server task is provided which manages the resources of the telephony card for all of the individual channel tasks.

The invention will be described with respect to particular embodiments thereof, and reference will be made to the drawings, in which:

FIG. 1 is a symbolic block diagram of an IBM PC/AT-compatible personal computer incorporating features of the invention;

FIG. 2 is a block diagram of the software architecture used in the system of FIG. 1;

FIG. 3 is a detail of a sequencer of FIG. 2;

FIG. 4 is a flowchart illustrating the creation of a sequencer in FIG. 2; and

FIG. 5 is another block diagram of the software architecture used in the system of FIG. 1.

I. HARDWARE ARCHITECTURE

FIG. 1 is a symbolic block diagram of an IBM PC/AT-compatible personal computer incorporating features of the invention. It comprises a CPU 102, which may be an Intel 80486 compatible CPU or an Intel Pentium processor, for example. The CPU 102 has address, data and control lines which are connected to a CPU bus 104. The CPU bus 104 is also connected to a cache memory 106 and to DRAM memory 108, both of which are controlled by system control logic 110. The system control logic 110 is connected to the CPU bus 104 and also to control, address and data lines of an ISA bus 112. Connected to the ISA bus 112 is a ROM 114 containing the system BIOS, a disk controller 116 for floppy and hard-disk drives 118, and one or more telephony cards 120 connected to a plurality of telephony channels 122. The telephony card 120 is a model D/41, available from Dialogic Corporation, Parsippany, N.J. In another embodiment, the telephony card is a TyIN 4000 Pro, available from National Semiconductor, Santa Clara, Calif. The Dialogic board is described in Dialogic, "Voice Hardware Reference" (Dialogic Ref. No. OS-0147-002) (1994), incorporated by reference herein. The TyIN 4000 Pro is described in National Semiconductor, "TyIn 4000 Pro, Getting Started" (1994), incorporated herein by reference. The system of FIG. 1 illustrates only one platform which can run software according to the invention. Numerous other platforms can also suffice, such as Macintosh-based platforms available from Apple Computer, Inc., platforms with different local bus configurations, networked platforms, multi-processor platforms, and so on.

The telephony channels 122 represent separate analog phone lines for each channel. However, a wide variety of other implementations are possible. For example, the telephony channels 122 could represent separate logical channels all carried on one or more telephone-company-provided T1 connections or higher. As another example, the telephony channels 122 may be carried on one or more ISDN BRI or PRI links into the public switched telephone network. In either case, the telephony cards 120, together with any software drivers, are responsible for presenting the appearance of separate, individual channels (also referred to herein as telephony lines) to higher level software.

Because of the numerous types of hardware platforms which can run software according to the invention, the term "processor structure" as used herein will refer to the CPU or CPUs of single or multiple processor arrangements, whether located in a single box or distributed across a network. Similarly, due to the possibility of paging and overlay mechanisms of different operating systems and application programs as well as memory, disk and network caching, the term "memory structure" includes both volatile and non-volatile memory, mass storage and cache memories, whether these types of memory are all located in a single box or distributed across a network.

II. SOFTWARE ARCHITECTURE

FIG. 2 is a block diagram of the software architecture used in the present embodiment. The software runs under a multitasking operating system such as Microsoft Windows, Windows NT or UNIX. As used herein, the term "multitasking operating system" includes permissive multitasking operating systems as well as preemptive multitasking operating systems. Preferably, the operating system 202 in FIG. 2 is Microsoft Windows. All of the software and data illustrated in FIG. 2 is present in the memory structure of FIG. 1, although because of paging, memory caching and disk caching and other memory management mechanisms, different parts may at different times be located physically in one or more of the different components of the memory structure.

In the architecture of FIG. 2, each of the telephony channels is associated with a separate concurrent task (also called a concurrent process) running under the operating system 202. The term "concurrent task" does not require that their instructions be executing simultaneously, although this may be possible on a multi-processor system. In FIG. 2, N tasks are shown, 204-1, . . . 204-N (collectively, 204). In one embodiment, these tasks are all created upon initialization of the IVR system, whereas in another embodiment, the tasks are created only as their associated telephony channels become active.

In a multitasking operating system, a task (or process) can be thought of as being divided into two components: software instructions which are executable by the processor structure, and data. Data is further divisible into read-only data and read-write data. When two tasks are running the same software, the read-write data for each task is maintained in a separate region of the memory structure, whereas, depending on the operating system, there may either be a separate copy of the software instructions and read-only data for each task or the different tasks can share the same copy of the software instructions and read-only data. In the present embodiment, a single copy of the software instructions and read-only data is shared. See Pietrek, "Windows Internals," Addison-Wesley, pp. 216-218 (1993). The entire Pietrek text is incorporated by reference herein. Whether or not two tasks running the same program share their software instructions and read-only data, the program is considered herein to be separately "instantiated" for each of the tasks.

Each of the tasks in FIG. 2 can be thought of as including three modules 206-i, 208-i and 210-i. The module 206-i is a database language sequencer. The sequencer is the portion which the IVR system developer creates or modifies in order to define the caller's experience with the IVR system. Voice prompts are set up in the sequencer module, as are menu hierarchies, actions in response to caller input, and so on. In order to facilitate the extensive data manipulation and data access which sophisticated IVR systems usually require, the IVR system developer creates the sequencer 206-i using a feature-rich database language rather than with a minimal IVR language or general purpose programming language. Any database language can be used in different embodiments of the invention. The embodiment described herein uses FoxPro, but the languages of many other database systems can be used instead, such as dbase, Paradox, Oracle/SQL, Clipper, and so on.

The DBMS-language sequencer 206-i can include either a fully compiled version of the developer's DBMS language code, or can include the combination of the DBMS-language code in text form plus an interpreter. Other variations are also possible, such as the combination of a tokenized version of the developer's DBMS code plus a traverser for sequencing through the tokens. FIG. 3 illustrates the interpreter variation. As can be seen, the sequencer 206-i includes the FoxPro code 302 in text form as written by a developer, and a FoxPro language interpreter 304 which parses the FoxPro code 302 in order to determine which actions to take. In this variation, the interpreter 304 includes software instructions executable by the processor structure, which may be shared between tasks, while the FoxPro code 302 is considered read/write data and is not shared between the tasks. However, in another embodiment, the FoxPro code 302 may be shared between tasks. Note that it will typically be desired that most, if not all, of the telephony channels should present the same user experience to callers. In this case, if the FoxPro code 302 is not actually shared, it can at least be identical among all the channels that require the same handling.

FIG. 4 is a flowchart illustrating the creation of the sequencer 206-1 in the variation in which the sequencer constitutes compiled code. In a step 402, the developer prepares the FoxPro code in text form. This may be the same code as 302 in FIG. 3. In step 404, the FoxPro code is compiled using the FoxPro DBMS compiler in the FoxPro Distribution Kit, available from Microsoft Corporation, Redmond, Wash. This compiler is described in Microsoft, "FoxPro User's Guide" pp. U6-12-U6-15 (1993). (The entire User's Guide is incorporated herein by reference.) In step 406 the compiled sequencer 206-1 has been created.

Since each task 204-i in FIG. 2 corresponds to a separate telephony channel 122, the IVR system developer can prepare the FoxPro code used to create the sequencer 206-i, as if only one telephony channel was to be handled. The developer need not be concerned with any other telephony channel, or even with the possibility that more than one telephony channel may exist, since all consequences of these possibilities are handled by the multitasking operating system 202 and/or the channel server process 214 described below.

Returning to FIG. 2, the module 208-i represents a database engine for the particular DBMS in which the IVR system's developer's code was prepared. In the presently described embodiment, database engine 208-i is the FoxPro database engine, available from Microsoft Corporation and incorporated herein by reference.

All of the database engines 208-i contain a set of database management procedures which are callable by the sequencer 206-i in order to manage the data in a common database 212. The database 212 is stored in the memory structure of the computer system of FIG. 1, and for the most part on the disks 118 of such memory structure.

The module 210-i contains a library of telephony-related procedures callable by the sequencer 206-i. The module 210-i can be provided to the IVR system developer in compiled form, so the developer need not be concerned at all with its contents (except to know the identity of, and syntax for, the procedures which may be called from the FoxPro language code). In the situation where the DBMS language used is FoxPro, and the operating system 202 is Microsoft Windows, then the procedures of the module 210-i are preferably written in C and compiled and linked together to create an .FLL (FoxPro Linked Library). The procedures of FLL 210-i are described in more detail below.

The telephony modules 210, each instantiation of which is associated with a different telephony channel 122, communicate with a channel server process 214 which is charged with controlling the telephony cards 120 and allocating their resources in a manner which avoids conflicts among the different tasks 204. The channel server process 214 is described in more detail below as well.

FIG. 5 is another diagram of the software architecture used in the present embodiment. For simplicity, only one task 204 is illustrated, but greater detail is provided throughout the hierarchy. In addition, since the database engine modules 208 and the database 212 are conventional, they are omitted from FIG. 5.

As can be seen in FIG. 5, the software architecture of the present embodiment is organized into layers. It will be seen that by substituting one module at one layer, different database management systems can be accommodated. By substituting modules at two other layers, different operating systems can be accommodated. Finally, by substituting modules at two further layers, different telephony cards can be accommodated.

Referring to FIG. 5, the top two levels 302 and 304 together form the FoxPro language sequencer 206-1 (FIG. 2). The example of FIG. 3, specifically the combination of FoxPro code in text (layer 302) and a FoxPro language interpreter (layer 304) is illustrated. The FoxPro code in layer 302 is prepared by the IVR system developer, whereas the FoxPro language interpreter 304 is supplied by the DBMS manufacturer (Microsoft, in the case of FoxPro).

The telephony FLL module 210-1 (FIG. 2) comprises three layers: a DBMS interface layer 502, charged with the task of converting parameters between the form in which they are passed to and from the sequencer 206-1, and a generic form used by lower layers in the hierarchy. The layer 502 thus isolates lower layers from having to know which DBMS is running in the higher layers. The module 502 is specific to the particular DBMS used; other versions of this module can be substituted in order to support sequencers from other DBMSs.

Below the DBMS interface layer 502 in the telephony FLL 210-1 is a compute layer 504. Roughly, the compute layer 504 is charged with performing any computations that are both generic (not specific to a particular DBMS) and not appropriate for the channel server 214 to perform. For example, certain operations should not be performed by the channel server 214 because they may create a bottleneck; these operations are performed in the compute layer 504 instead. Examples of operations performed in the compute layer 504 include retrying an operation if no input is received before a time-out expires; converting a date value input parameter to a list of individual voice prompts to speak; and so on. Different versions of the compute layer 504 may be substituted to meet the needs of different market segments, for example to accommodate different human languages or the customs of different countries.

Below the compute layer 504 in telephony-FLL 210-1 is an IPC client layer 506. The IPC client layer 506 communicates with an IPC server layer 508 at the top of the channel server 214 using an inter-process communication (IPC) protocol or mechanism of the underlying operating system 202 (FIG. 2). In Windows implementations, the IPC mechanism can be Dynamic Data Exchange (DDE). Whereas there are N instantiations of the sequencer 206-i and the telephony FLL 210-i, including the IPC client layer 506, there is only one instantiation of the channel server 214, including an IPC server layer 508. The purpose of IPC client layer 506 is to perform the client side of the inter-process communication mechanism for the compute layer 504 in a manner which isolates the compute layer 504 from all details of the IPC communication mechanism. The layer 506 also isolates higher layers from having to know whether the IVR system is serving only a single channel, or multiple channels. The IPC server layer 508 performs the server side of the inter-process communication mechanism. Note that in systems that support only a single telephony channel, the IPC client layer 506 and the IPC server layer 508 can be combined into a single very simple layer.

Below the IPC server layer 508 in the channel server 214 is a test mode layer 509. When test mode is activated, this layer simulates the operation of the telephony hardware using user dialogs, so that an application can be tested without requiring actual use of telephony hardware. In normal operation, test mode is disabled and the test mode layer 509 simply becomes transparent.

Below the test mode layer 509 is a line driver interface layer 510. The layer 510 implements standard voice/telephony primitives for the particular telephony card(s) installed in the system. In some embodiments, the line driver interface 510 might also control a voice recognition card (not shown). The layer 510 implements such primitives as "answer incoming call", "hang up line", "get DTMF keys", and "play list of prompts". Since the line driver interface layer 510 isolates higher layers from having to know how to control the particular telephony card(s) installed in the system, different versions of the layer 510 may be substituted to handle different telephony cards.

Below the line driver interface layer 510 in the channel server 214 is the telephony card driver 512 supplied by the telephony card manufacturer. For the Dialogic D/41 card, the driver 512 is the D40Drv DOS TSR ("Terminate and Stay Resident") program, available from Dialogic. For the National Semiconductor TyIN 4000 Pro telephony card, the driver layer 512 is the TAPI service provider (TSP) program available from National Semiconductor. For the Rhetorex telephony card (Model RDSP 9432, available from Rhetorex, Inc., Campbell, Calif. ), the driver 512 is the RhetDrv DOS TSR program available from Rhetorex. All three of these driver programs are incorporated herein by reference in their entirety. Such drivers may also include a number of procedures to be compiled with the channel server 214, which properly call the TSR or TAPI routines.

III. EXAMPLE FOXPRO PROGRAM

Set forth in Appendix A is an example FoxPro program for layer 302 (FIG. 5). The programing language in which the FoxPro code in Appendix A is written, is described in Microsoft, "FoxPro Language Reference" (1993), incorporated herein by reference.

The example program in Appendix A represents the telephony component of an interactive voice response system which schedules part-time workers at a plant. It demonstrates a solution to the need for a large retail outlet to schedule temporary labor, and have temporary employees be able to call in and obtain their work schedule. The voice response system permits workers to enter their worker number, and be told which days of the current week, and which work shift (early or late) they should report to work. They have a chance to accept or reject each individual shift scheduled. As will be seen, the program uses ordinary FoxPro commands (verbs and procedure calls) to access the database. The telephony functions are available by way of new procedure calls, but the syntax for calling these procedures is the same as the ordinary FoxPro language syntax for calling database management procedures. In another embodiment, access to the telephony functions can be provided by way of newly defined verbs, instead of or in addition to newly defined procedure calls.

The program in Appendix A operates on two databases: a control database called BASEDATA and a working database called WORKERS. The control database contains only two values: a labor rate and an hours-per-shift value. The WORKERS database contains 100 rows, each for a respective temporary worker. The fields in each entry

In a portion of FoxPro code prior to that set forth in Appendix A, an initial work schedule was set up in a WORKERS database.

At line 10 of the program, a SET LIBRARY TO command is issued, which loads in a FoxPro linked library called voysaccs. This is the telephony FLL 210-1 (FIG. 5). When FoxPro loads a library, it also runs a start-up procedure of that library which, among other things, registers a procedure for the task 204-1 to handle events in substitution for the default FoxPro event handler.

In line 11, the program calls a telephony FLL function VSET to establish a directory in which application prompt files are to be found. In line 12, the program calls the same function to establish a directory in which recording files are to be found.

In lines 18-22, certain variables are loaded with base data from the BASEDATA database. In line 28, the actual working database table, WORKERS, is selected. The FoxPro command SET ORDER TO is then used to establish an index based on the field ID.

Lines 36-52 constitute a continuous loop which simply waits for the phone to ring, answers it after one ring, and then calls a procedure pt.sub.-- call. The function to wait for the phone to ring and answer it after one ring, is VWaitRing(), at line 42, and this is a procedure in the telephony FLL 210-1. The VWaitRing() procedure takes two arguments, both of which are optional. The first argument indicates the number of rings to wait before answering; the default is two. The second argument indicates the number of seconds to wait before timing out; the default is 0, indicating no time-out. Return values indicate success (answered a phone call), time-out, or invalid parameters.

The pt.sub.-- call function is described below. After pt.sub.-- call returns, the example program in Appendix A calls another telephony FLL procedure VChkHangup() to determine whether the call is still active (line 47) and, if not, it calls yet another telephony FLL procedure VSpeak() to speak a "good-bye" prompt over the telephony channel. The VSpeak() procedure allows a program to speak a sequence of prompts or values. It can take up to 10 arguments. These arguments can be values (numbers or character strings which contain dates or voice file names), or "speak modes" that regulate how numeric values should be spoken. Speak modes apply only to numeric values, and the default is a standard numeric format in which, for example, 432 is spoken as "flour hundred thirty-two". The speak mode DIGITS causes subsequent numbers to speak out the digits, for example "4 3 2". DOLLARS speaks the numbers as a dollar amount. For example, 432.54 would be spoken as "four hundred thirty-two dollars and fifty-four cents". DAY speaks numbers in the range 1-7 as days of the week; this speak mode is designed to work hand-in-hand with the FoxPro DOW() function. The speak mode specified in an argument list remains active for all subsequent numbers in the argument list until changed. Prompt names given as arguments are in the form of voice file names in the current "AppPrompts" directory, and are in one of several standard digitized audio file formats. The VSpeak() procedure returns codes indicating success or failure, or code indicating success but interrupted by DTMF key press.

In the case of the VSpeak() call on line 48 of the example program in Appendix A, only one argument is provided, specifically the name of a file which contains the prompt "Good-bye, and thank you for calling." In line 51, still another telephony FLL procedure VHangup() is called in order to disconnect the telephony channel.

The pt.sub.-- call procedure begins on line 62 of the example FoxPro program in Appendix A. In line 71, it calls the VSpeak procedure to speak the prompt in the data file pthello, specifically a hello prompt.

In lines 77-108, the pt.sub.-- call procedure enters a loop which attempts to obtain a valid 4-digit ID from the caller. The caller is given three tries. In line 78, the procedure calls the telephony FLL function VChkHangup() in order to determine whether the caller has hung up. If so, the procedure returns to line 44. A typical database language program using the telephony FLL will make frequent calls to VChkHangup() because a caller may hang up at any time.

At line 86, the pt.sub.-- call procedure calls the VSpeak() telephony FLL procedure to speak the prompt in file ptid, which asks the caller to enter a 4-digit worker ID. In line 87, the pt.sub.-- call procedure calls another telephony FLL function VGetTones(). The VGetTones() procedure allows the caller to provide information to the program, including menu choices, worker identifications, answers to questions, PIN numbers, and so on. The function takes up to four arguments, beginning with a character variable which upon return will contain the sequence of digits entered by the caller. The second argument is optional and indicates the number of digits to terminate on. The default is 1, and 0 accepts any number of digits. The third argument is optional and indicates a string containing a single character representing a key to terminate on (0-9, * or #). The default is "space", which indicates no key-specific termination. The fourth argument indicates an inter-digit time-out--the number of seconds to wait between digits before timing out. 0 indicates no inter-digit time-out and the default is 10 seconds. Thus, three different termination mechanisms are available: fixed number of digits, an end-of-input key, and an inter-digit time-out. If more than one mechanism is used, then the first to occur terminates the input. Additionally, VGetTones() will terminate upon a "first-digit time-out" if the caller has not pressed any keys at all within the first five seconds. The database language program can adjust the first-key time-out using a VSetTimeOut() telephony FLL procedure.

On successful termination, VGetTones() returns a value indicating whether termination occurred on inter-digit time-out, specified key, or number of digits. On failure, VGetTones() returns a value indicating whether termination occurred on first-key time-out, on hang up, or because of bad arguments.

In line 87, the arguments passed to VGetTones are @loc.sub.-- id, 4, "space" and 15. Thus, it will return after four digits have been entered or after an inter-digit time-out of 15 seconds. There is no key on which it will terminate. The number entered by the caller will be in the FoxPro variable loc.sub.-- id.

In line 94, the program uses the FoxPro SEEK verb to search the WORKERS database table for the worker ID in loc.sub.-- id, using the ORDER previously established at line 29. In line 95, the FoxPro function FOUND() is used to determine whether the worker ID entered by the caller exists in the database. If so, then at line 96, the program exits the FOR loop. If not, then at line 104, the program calls VSpeak() with the name of a file ptnoid containing a prompt such as "Sorry, I couldn't find that ID. Please try again." The program allows three attempts for the caller to enter a valid ID; after the third attempt, at line 106, pt.sub.-- call simply returns.

Once a valid worker ID has been entered, lines 115-183 check each shift individually and for each one, if the worker is scheduled to work, requests confirmation. A count of the number of shifts confirmed is maintained in a FoxPro variable var.sub.-- num.sub.-- shifts.

Referring to line 115, pt.sub.-- call first determines whether the worker is scheduled to work in the early shift on day 1 (es1). If so, then in line 116, pt.sub.-- call calls another FoxPro procedure query.sub.-- shift, passing in two parameters: .T. and date1. The first parameter for query.sub.-- shift indicates whether this is the early or late shift (.T. means TRUE and .F. means FALSE), and the second parameter is a date string in the form MM/DD/YY. Accordingly, the call in line 116 specifies to query.sub.-- shift that this is the early shift of the date indicated in datel. The query.sub.-- shift procedure uses the telephony FLL functions to ask the caller about working the specified shift, and returns true (.T.) or false (.F.) in a variable var.sub.-- confirm to indicate whether the caller has confirmed that shift. In line 117, the pt.sub.-- call procedure uses the FoxPro verb REPLACE to update esl with the Boolean value returned in var.sub.-- confirm . The procedure pt.sub.-- call performs this operation for each shift of each date in the week.

After all shifts have been queried, the program determines at line 188 whether or not the worker has agreed to work any shifts at all. If not, then in line 189, the program calls VSpeak() with the name of a file ptnoshft containing the prompt, "You are not scheduled to work any shifts in the next week."

Otherwise, at line 198, the program calls VSpeak() with a series of arguments which give the worker an earnings prediction for the coming week. The statement contains five arguments which together assemble the prompt as follows:

In step 203, pt.sub.-- call returns to line 44 of the main FoxPro code.

The query.sub.-- shift procedure used in pt.sub.-- call begins on line 210 of the example program in Appendix A. In lines 215-217, query.sub.-- shift first uses the VChkHangup() procedure to exit if the caller has hung up.

In line 224, if this is an early shift, query.sub.-- shift speaks a prompt by passing arguments to the VSpeak() procedure as follows:

In line 227, if the specified shift is a late shift, then the same prompt is spoken except that it begins with the language in the prompt file ptlate, which is "You are scheduled to work the late shift on . . . ".

In lines 234-268, the caller is given three attempts to enter 1 to confirm, or 2 to reject. Specifically, after checking for hangup (lines 235-237), query.sub.-- shift calls VSpeak() to speak the prompt "To confirm that you will be available for this shift, press 1. If you will not be available, press 2." In line 242, query.sub.-- shift calls VGetTones() with arguments indicating termination after one digit or a 15-second inter-digit time-out, with the caller's input to be placed in a variable loc.sub.-- confirm. In lines 247-251, if the caller pressed the numeral 1 key, then var.sub.-- confirm is set to .T. and var.sub.-- num-shifts is incremented. If not, then in lines 253-256, var.sub.-- confirm is set to .F. If the caller pressed a number that was neither 1 nor 2, then on the first two tries, query.sub.-- shift calls VSpeak() to speak the prompt, "Please press 1 or 2," (line 263) and the loop repeats. After the third attempt, query.sub.-- shift sets var.sub.-- confirm to .F. (line 265) and returns.

It can be seen that the availability of telephony function calls in a database programming language creates a powerful combination which permits interactive voice response system developers to easily allow callers to interact with a database in a very complex manner.

IV. TELEPHONY FLL

The telephony FLL 210 will now be described. For illustration purposes, one of the procedures of the telephony FLL 210 which are callable from the FoxPro language sequencer 206, specifically VSpeak(), will be followed all the way down to the telephony card driver layer 512. A number of additional telephony FLL procedures are described in Appendix B, and their internal operation can be gleaned from Appendices C-G hereto.

A. FoxPro Interface Layer Procedures

Initially, note that FoxPro requires a library extension module to include a structure which defines the entry points and various other characteristics of each procedure which is callable from the FoxPro language code. In the FoxPro interface layer 502 in telephony FLL 210-1, this structure is as follows:

Pertinent parts of the source code for the FoxPro interface layer are set forth in Appendix C. Pertinent parts of the VSpeak() procedure will now be described.

VSpeak() begins by obtaining a handle to the current task and passing it to a function FindSlot(). The FindSlot() function returns, in a specified pointer variable sp, a pointer to a DBMS interface layer telephony line status table line[ ]. The DBMS interface layer 502 and the compute layer 504 each maintain such a table for their own purposes, and the structure of an entry in the line [ ] table of the DBMS interface layer is as follows:

Each process 204-i maintains a copy of this table, but looks at only the data for itself.

The FindSlot() function merely loops through the above line table until it finds an entry whose hTask field matches the specified task number, and whose binUse field is true. A pointer to the resulting entry of line[ ] is returned in sp.

Returning to VSpeak(), a variable play.sub.-- type is then initialized to play numbers "as numbers". A FOR loop then loops through all of the arguments in the call to VSpeak(). FoxPro passes parameters to extension library procedures using a parameter block consisting of an integer that represents the number of parameter, immediately followed by an array of parameter unions. The first byte of each parameter union indicates that the parameter is passed by reference if it contains the character R, otherwise it is passed by value. If the parameter is passed by value, then the first byte contains a character indicating whether the parameter is a string (C), numeric (N), an integer (I), a date (D), a logical (L), or another type of data. The entire parameter has the following structure:

VSpeak() begins the parameter loop by determining whether the first parameter is a string. If so, then it copies the length of the string from the ev.sub.-- length field into a variable nCount, and copies the text of the string into the variable `text` from the array pointed to by the ev.sub.-- handle field of the parameter. The procedure then adds a terminating NULL character, trims any trailing blanks, and capitalizes the string.

If the parameter text is one of the predefined numeric format flags "digits" "dollars" or "day" then the VSpeak() procedure sets the flag play.sub.-- type to indicate how subsequent numeric parameters are to be spoken. It also turns off a play.sub.-- flag to indicate that the current parameter is not to be spoken.

If the first byte of the current parameter was not a C, but rather was an I, then VSpeak() converts the integer parameter is converted to a string and places it into the variable `text`. The flag play.sub.-- flag remains true.

If the first byte of the current parameter is N, then the number contained in the parameter is also converted to text and stored in the variable `text`.

If play.sub.-- flag is false with the current parameter, then the loop continues at this point with the next parameter (lines 180, 207). Otherwise, VSpeak() calls a procedure com.sub.-- Play() either to start a "play list" with the current parameter, or to add the current parameter to an existing play list. The procedure com.sub.-- Play and related procedures are part of the compute layer 504 and are described in more detail below. Briefly, however, com.sub.-- Play is called with five arguments: a task handle, which indicates the current Windows task; a call type, which can be either START.sub.-- PLAY.sub.-- LIST or ADD.sub.-- PLAY.sub.-- LIST or PLAY.sub.-- PLAY.sub.-- LIST; a string which can be either a string of digits or the name of an audio file; a play.sub.-- type, which indicates how numeric parameters are to be spoken; and an interrupt.sub.-- mode specifying whether to terminate the prompt if the caller presses a DTMF key.

After the entire parameter list has been parsed in the loop, VSpeak() calls com.sub.-- Play() one more time in line 213 with the call type PLAY.sub.-- PLAY.sub.-- LIST. VSpeak() then prepares a result parameter, which has the same format as an argument list parameter and returns it to the FoxPro sequencer 206.

B. Compute Layer Procedures

The compute layer 504 procedure com.sub.-- Play() will now be described, as will the compute layer procedures which are called by com.sub.-- Play(). Pertinent procedures of the compute layer source code are set forth in Appendix D.

1. com.sub.-- Play()

The com.sub.-- Play() procedure is as follows:

As can be seen, com.sub.-- Play() is relatively simple. It merely checks for parameter errors and then calls either init.sub.-- play.sub.-- list(), add.sub.-- to.sub.-- play.sub.-- list() or play.sub.-- play.sub.-- list(), depending on the call type. Additionally, if the call.sub.-- type was START.sub.-- PLAY.sub.-- LIST, then after calling init.sub.-- play.sub.-- list(), the routine also calls add.sub.-- to.sub.-- play.sub.-- list().

2. init.sub.-- play.sub.-- list()

The play list is not actually maintained in the compute layer, but rather it is maintained by the channel server process 214. The entire function init.sub.-- play.sub.-- list() is merely to assemble an IPC "command" and to pass it to an IPC client layer 506 procedure ipc.sub.-- Do.sub.-- Command().

At this point it will be useful to understand that inter-process communications are accomplished in the present embodiment by a client 210-i preparing a command data block and passing it down to the channel server process 214, or by the channel server 214 preparing an event data block and passing it back up to a client process 210-i. The procedure init.sub.-- play-list() uses only the command block, and this structure is defined as follows:

The different commands which can be sent to the lower layer using this command structure are as follows:

The structure pitem referred to in the definition of struct command is as follows:

Given the above, the init.sub.-- play.sub.-- list() procedure is self-explanatory and is as follows:

3. add.sub.-- to.sub.-- play.sub.-- list()

The compute layer 504 procedure add.sub.-- to.sub.-- play.sub.-- list() is as follows:

add.sub.-- to.sub.-- play.sub.-- list() can be called with either a number, a date or the name of a voice file to play in the field *voice.sub.-- file. The field play.sub.-- type applies only if *voice.sub.-- file is numeric, so add.sub.-- to.sub.-- play.sub.-- list() first checks to determine whether *voice.sub.-- file is numeric. If it is, then it calls one of the routines speak.sub.-- as.sub.-- number() , speak.sub.-- as.sub.-- digits() , speak.sub.-- as.sub.-- dollars() or speak.sub.-- as.sub.-- day(), depending on play.sub.-- type. These routines are discussed below.

If *voice.sub.-- file contains a date, recognized by the presence of the slash (/), add.sub.-- to.sub.-- play.sub.-- list() calls the routine speak.sub.-- as.sub.-- date(). Otherwise, *voice.sub.-- file is assumed to be the name of a voice file to play. The function add.sub.-- to.sub.-- play.sub.-- list() passes this on to yet another function, addu().

The compute layer function addu() is as follows:

As can be seen, the addu() routine merely creates an array of paths where the specified voice file might be found, and then calls yet another compute layer procedure add.sub.-- voice() . The routine add voice() is as follows:

This routine takes as arguments a pointer to the present task's slot in the line table, a pointer to the name of the voice file to be spoken, and an array of paths where the voice file might be found. It sets up a command block using this information and passes it on to ipc.sub.-- Do.sub.-- Command() .

The routines speak.sub.-- as.sub.-- number(), speak.sub.-- as.sub.-- digits(), speak.sub.-- as.sub.-- dollars() , speak.sub.-- as.sub.-- day() and speak.sub.-- as.sub.-- date, all essentially dissect the string of characters in *voice.sub.-- file into individual atomic prompts which are present in voice files in a system prompts directory. These routines all call another compute layer routine addp() with the voice file name for each of the atomic prompts, which merely prepends the path to the system prompts directory and passes the information on to add.sub.-- voice(). add.sub.-- voice() sets up the appropriate command block as described above, and passes the individual voice file names on to ipc.sub.-- Do.sub.-- Command(). The compute layer speak.sub.-- as.sub.--. . . () routines and addp() are set forth in Appendix D, together with any utility routines that they call.

4. play.sub.-- play.sub.-- list()

The play.sub.-- play.sub.-- list() compute layer procedure is as follows:

As can be seen, this routine merely sets up a command block with the command DVRC.sub.-- PLAY and various other parameters, and passes it on to ipc.sub.-- Do.sub.-- Command(). ipc.sub.-- Do.sub.-- Command() returns the event structure from the channel server 214 in `event`, which play.sub.-- play.sub.-- list() ignores since it contains no useful information.

C. IPC Client Layer Procedures

Pertinent procedures of the IPC client layer 506 are set forth in Appendix E. The layer includes initialization and termination functions, as well as procedures to handle commands being passed down from the IPC client layer to the IPC server layer 508, and events being passed up from the IPC server layer 508 to the IPC client layer 506.

As can be seen, the ipc.sub.-- Do.sub.-- Command() procedure first initializes an event data structure to values which indicate that no event has been received yet. It then obtains the current client task's slot in the telephony line table line[ ] for the IPC client layer 506, and calls the IPC client layer 506 send.sub.-- message() procedure with the command data structure cmd.

The send.sub.-- message() procedure merely calls another IPC client layer 506 procedure SendPoke(), which calls the Windows functions to send the command cmd via dynamic data exchange (DDE) in a conventional manner to the DDE window for the present client in server task 214. SendPoke() then awaits a Windows return message using the IPC client layer 506 procedure wait.sub.-- for.sub.-- wmessage(). Absent an error, the channel server 214 will always send a return acknowledge message (WM.sub.-- DDE.sub.-- ACK).

The wait.sub.-- for.sub.-- message() procedure uses conventional Windows functions to periodically poll the Windows event queue until a specified DDE message has been received for the current client task DDE window. It then returns to the calling routines, SendPoke(), send.sub.-- message(), and, ultimately, ipc.sub.-- Do.sub.-- Command().

In the present embodiment, after acknowledging a command, the channel server process 214 always responds to DDE commands with an event structure also sent by DDE. Accordingly, after returning from send.sub.-- message(), ipc.sub.-- Do.sub.-- Command() calls yet another IPC client layer 506 procedure get.sub.-- message() to wait for and obtain the returned event structure. get.sub.-- message() is set forth in Appendix E, and as can be seen, it calls wait.sub.-- for.sub.-- message() to await a WM.sub.-- DDE.sub.-- DATA message for this task. It then calls another IPC client layer 506 procedure ClientReceiveData(), which sends a WM.sub.-- DDE.sub.-- ACK acknowledge message back to the channel server process and places the event structure in the current task's event queue sp.fwdarw.eventq[ ]. ClientReceiveData() then returns to get.sub.-- message(), which returns to ipc.sub.-- Do.sub.-- Command(), which returns to the compute layer 504 routine which called it.

V. CHANNEL SERVER

As previously described, the channel server 214 is responsible for allocating the telephony and resources of the IVR system in a manner that avoids conflicts. To do this, the IPC server layer and the line driver interface layer of the channel server 214 each maintain a respective static line[ ] table which contains a large amount of status information about each telephony channel. Each entry in the table corresponds to a different channel. The structure of a single entry in line[ ] in the IPC server layer 508 is:

The structure of a single entry in line[ ] in the line driver interface layer 510 is:

A. IPC Server Layer Procedures

Pertinent routines of the IPC server layer 508 are set forth in Appendix F. The IPC server layer 508 runs a polling loop in the procedure WinMain(), and when a new message has been received, passes it on to either MainWndProc() or DDEWndProc() depending on the specified destination window. When each client starts up, it sends a WM.sub.-- DDE.sub.-- INITIATE message by DDE to the server process's main window. This message is received in the IPC server layer's polling loop. In response, the server calls ServerInitiate(), which opens up a hidden window for the particular client and establishes a "conversation" between server and client by placing a correspondence between the two windows in the next available entry of an array Conv[ ]. Eventually the polling loop will receive a WM.sub.-- DDE.sub.-- CONNECT command from the client, with the client requesting telephony line 0. If telephony line 0 is already assigned to a client, the server polling loop will return a "busy" event code. The client will then request connection to line 1, and so on until the first free line is found. When this occurs, the IPC server layer will update the specified entry of its line[ ] table with an identification of the client and server DDE windows now associated with the channel, and mark the channel as in-use. It then passes the WM.sub.-- DDE.sub.-- CONNECT command down to the tm.sub.-- Do.sub.-- Command() procedure of the test mode layer 509. Assuming the system is not in test mode, the test mode layer 509 simply passes the command on down to an ld.sub.-- Do.sub.-- Command() procedure of the line driver interface layer 510. (It is assumed herein that test mode is disabled, in which case all calls to the test mode layer are passed directly to the line driver layer. The procedure names are the same, except for a "tm.sub.-- " prefix for test mode layer procedures and as "ld.sub.-- " prefix for line driver layer procedures. The two versions of each procedure name are therefore used interchangeably hereinafter and in the appendices.)

If the polling loop receives a WM.sub.-- DDE.sub.-- POKE command from a client, then MainWndProc() or DDEWndProc() pass the command on to an IPC server layer routine ServerPoke(), which extracts the command from the message, checks for errors, and calls do.sub.-- command(). The do.sub.-- command() procedure begins by setting up a default event structure for return to the client, and then performs various preliminary procedures depending on the command. For the command DVRC.sub.-- ADDPLAY, do.sub.-- command() locates the specified voice file in the memory structure of FIG. 1 and assembles a complete path name to the file. It then places the command in the client's entry in the line[ ] array and sets a "command-in-progress" bit in that entry. The same happens for DVRC.sub.-- INITPLAY and DVRC.sub.-- PLAY. do.sub.-- command() then calls the ld.sub.-- Do.sub.-- Command() procedure in the line driver interface layer 510, passing the command structure and an event structure for return information. When ld.sub.-- Do.sub.-- Command() returns, do.sub.-- command() returns the event back to the client using the IPC server layer 508 send.sub.-- event() procedure. do.sub.-- command() then unsets the "command-in-progress" bit for the current client, and returns to ServerPoke() . ServerPoke() then sends a WM.sub.-- DDe.sub.-- ACK back to the client to acknowledge receipt of the command.

If the polling loop in WinMain() receives a time-out event, then it calls do.sub.-- polling(), which calls the line driver layer to see if any command currently in progress has completed. If so, then the return event structure is transmitted to the client and the command-in-progress flag for that client's entry in the IPC server layer's line [ ] array is cleared.

B. Line Driver Interface Layer Procedures

The line driver interface layer 510 has four procedures which are callable from the IPC server layer 508: ld.sub.-- Initialize() (called to start up the layer); ld.sub.-- Shutdown() (called to shut down the layer); ld.sub.-- Do.sub.-- Command() (execute a new command from a client or the next stage of a command already in progress); and ld.sub.-- Process.sub.-- Event() (handle an event that came from a telephony card driver using a Windows TAPI service provider). Pertinent ones of these procedures, as well as pertinent support procedures, are set forth in Appendix G.

1. ld.sub.-- Initialize()

Referring to Appendix G, when the ld.sub.-- Initialize() procedure is called by the IPC server layer 508, it starts up the Dialogic driver 512, finds out how many telephony channels exist, and initializes them. The Dialogic driver 512 includes a terminate-and-stay-resident (TSR) facility which has been pre-loaded into memory. It is initialized by calling a Dialogic procedure startsys(), which calls a Windows function to generate a software interrupt. The software interrupt vectors to the TSR facility which communicates with the telephony cards 120 via predefined system hardware address ports in a conventional manner. The startsys() function returns the number of telephony channels available. Initialization of the telephony channels takes place by initializing the line driver interface's array line[ ] of active line states to initial values.

2. ld.sub.-- Process Event()

The routine is pertinent only to certain kinds of telephony card driver software. Events generated by the Dialogic telephony card and driver are passed "up" from the driver layer 512 to the line driver interface layer 510 as described herein. Other kinds of telephony card driver software, however, such as those that use a Windows TAPI service provider, pass events "down" from the top of the server 214 into the IPC server layer 508. These events would be handled by ld.sub.-- Process.sub.-- Event(). The present embodiment uses the former technique, so ld.sub.-- Process.sub.-- Event() is never used.

3. ld.sub.-- Do.sub.-- Command()

This procedure first uses a routine Check.sub.-- For.sub.-- Event() to obtain all events which are waiting in the Dialogic event queue, and transfers them into the server 214's event queue for the appropriate channel numbers. All events pending in the Dialogic event queue are transferred, regardless of the channel number to which they pertain. The server 214's event queues are serviced by the periodic invocation of the IPC server layer 508 do.sub.-- polling() routine as previously described.

The ld.sub.-- Do.sub.-- Command() procedure can be called to start a new command or to perform the next stage of a staged command. The IPC server layer 508 indicates in the argument list to ld.sub.-- Do.sub.-- Command() whether the present invocation of the procedure is to start or continue a command, the current stage of a staged command being maintained by the line driver layer 510 in its own static line table. In the case of the new command, ld.sub.-- Do.sub.-- Command() copies the command into the current channel's entry in the line driver layer's static line table, sets the command stage to 0, and sets a flag for the entry to indicate that a command is now in progress. Whether or not this is a new command, the procedure then `switch`es on the command number.

If the command is DVRC.sub.-- CONNECT, then a DoConnectCommand() procedure is called which checks whether the specified channel is available, updates the line driver layer's line[ ] entry for the channel, and invokes the telephony card driver TSR routines to establish the connection.

If the command is DVRC.sub.-- INITPLAY, then the procedure merely initializes a play list in the line table entry for the current channel. Since this is a single-stage command, the routine then turns off the command-in-progress bit in the entry of the line table, copies an "EV.sub.-- INITPLAY" code into an event structure, and returns to the IPC server layer 508.

If the command is DVRC.sub.-- ADDPLAY, then the routine merely adds the provided voice file name to a play list within the line table entry for the current channel. Again, it turns off the command-in-progress flag in the entry, copies the code EV.sub.-- ADDPLAY into the return event structure, and returns to the IPC server layer 508.

The DVRC.sub.-- PLAY command is a multi-stage command. A number of different stages are set out in Appendix G, but only stages 0, 11 and 12 need be discussed herein. Stage 0 indicates the start of a command, and in this stage, the procedure calls another line driver interface layer 510 procedure, Play.sub.-- Playlist(). This is also a staged procedure, and ld.sub.-- Do.sub.-- Command sets the stage to 10 prior to calling Play.sub.-- Playlist(). Play.sub.-- Playlist() changes the command stage for the current channel to stage 11 as described hereinafter.

The first time Play.sub.-- Playlist() is called at the start of a command (command stage 10), it loops through all of the items on the play list in the current channel's entry in the static line table, opening each voice file, and determining the DOS file handle, the starting position in the file of the voice prompt, and the length of the voice prompt. Note that the starting position will not always be at the beginning of the file, since the line driver layer 510 supports the presence of multiple indexed prompts in a single file. Play.sub.-- Playlist() then sets up a table Files.sub.-- Index[ ] listing the DOS file handle, the starting position and the length, for each voice prompt in the play list. The format of this table is defined by Dialogic.

Play.sub.-- Playlist() then builds another Dialogic-defined structure, called a read/write block (My.sub.-- rwb). Specifically, a pointer to Files.sub.-- Index[ ] is written into My.sub.-- rwb, as are a number of other parameters and pointers, including certain flags which were set by the client in compute layer 504. Such flags include whether speaking should terminate if the caller presses a DTMF key, and if so, which key. Play.sub.-- Playlist() then passes My.sub.-- rwb and the current channel number to the Dialogic card TSR driver via the Dialogic xplayf() function. This function will return after the information is transmitted to the telephony cards 120 and will not wait for all of the speaking to complete. In the background, the telephony cards obtain the actual voice data from the voice files via interrupts to the TSR driver as needed. In the meantime, Play.sub.-- Playlist() sets the command stage in the current channel's entry in the static line table to stage 11 and returns to ld.sub.-- Do.sub.-- Command(), which merely returns to the IPC server layer 508. The Dialogic TSR will add an event to a Dialogic event queue when speaking has terminated.

As previously described, the IPC server layer 508 do.sub.-- polling() routine periodically calls ld.sub.-- Do.sub.-- Command() for each channel for which a command is in progress. In can be seen in Appendix G that if ld.sub.-- Do.sub.-- Command() is called before the Dialogic telephony card has sent an event indicating termination of speaking, then ld.sub.-- Do.sub.-- Command() simply returns to the polling routine.

If a Dialogic end-of-playing event has been placed in the event queue for the present channel during the pendency of a DVRC.sub.-- PLAY command, then the command stage will still be 11. ld.sub.-- Do.sub.-- Command() will again call Play.sub.-- Playlist() which, in stage 11, closes all files that contain only one prompt, and examines the Dialogic event to determine why speaking terminated. Assuming it terminated normally, the procedure sets the command stage to 12 in the current channel's entry in the static line table, sets a flag to indicate whether termination occurred because all prompts were spoken or because of appropriate entry of DTMF digits, and returns to ld.sub.-- Do.sub.-- Command(). ld.sub.-- Do.sub.-- Command() returns to the IPC server level do.sub.-- polling() which, because the command is now done, sends an event back to the client to indicate as much.

Accordingly, a telephony voice response system has been described which includes a database language sequencer, a database control module having a plurality of procedures callable by the database language for performing database operations, and a telephony control module having a plurality of procedures callable by the database language sequencer for performing telephony operations. The database operations in the embodiment include reading and writing data to a database. The telephony operations in the embodiment include speaking a predefined prompt onto a telephony channel, receiving and storing DTMF-encoded input from the telephony channel, and recording audio input from the telephony channel. The database language sequencer calls the database control module procedures and the telephony control module procedures in a sequence defined by a program prepared according to the rules of the database language. The telephony voice response system can control multiple telephony channels by running a separate task for each such channel under a multitasking operating system. A common channel server task is provided which manages the resources of the telephony card for all of the individual channel tasks.

The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents. ##SPC1##