 |
Claims  |
|
|
We claim:
1. Telephony server apparatus, for use with a plurality of telephony
channels, comprising:
a processor structure;
channel control hardware coupled to said telephony channels and to said
processor structure; and
a memory structure having stored therein a plurality of channel programs
each associated with a respective one of said telephony channels,
multi-tasking operating system software instructions executable by said
processor structure, database engine software instructions executable by
said processor structure under a different task of said operating system
for each of said telephony channels, and a database,
said database engine software instructions including instructions which,
when executing under a given task of said operating system, interpret the
channel program associated with the telephony channel of said given task
and perform both database and telephony operations in response to such
channel program associated with the telephony channel of said given task,
said database operations including at least one operation from the group
consisting of reading data from and writing data to said database, and
said telephony operations including at least one operation from the group
consisting of speaking a predefined prompt onto the telephony channel
associated with the given task, receiving and storing DTMF-encoded input
from the telephony channel associated with the given task, and recording
audio input from the telephony channel associated with the given task.
2. Apparatus according to claim 1, wherein said processor structure
includes no more than one processor.
3. Apparatus according to claim 1, wherein said memory structure includes
both semiconductor memory and rotating memory.
4. Apparatus according to claim 1, wherein each of said tasks includes an
executable portion and a read-write data portion, the read-write data
portion being separate for each of said tasks, and the executable portion
being common to all of said tasks.
5. Apparatus acording to claim 4, wherein the read-write data portion of
the task associated with each particular one of said telephony channel
includes the channel program associated with said particular telephony
channel, and wherein all of said channel programs are the same.
6. Apparatus according to claim 1, wherein said database operations include
all operations from said group consisting of reading data from and writing
data to said database, and wherein said telephony operations include all
operations from said group consisting of speaking a predefined prompt onto
the telephony channel associated with the given task, receiving and
storing DTMF-encoded numerical input from the telephony channel associated
with the given task, and digitally recording audio input from the
telephony channel associated with the given task.
7. Apparatus according to claim 1, wherein said telephony operations
further include the operation of waiting for a ring signal from the
telephony channel associated with the given task.
8. Apparatus according to claim 1, wherein said telephony operations
further include the operation of answering a call from the telephony
channel associated with the given task.
9. Apparatus according to claim 1, wherein said telephony operations
further include the operation of hanging up a call on the telephony
channel associated with the given task.
10. Apparatus according to claim 1, wherein said telephony operations
further include the operation of dialing a call on the telephony channel
associated with the given task.
11. Telephony server apparatus, for use with a first telephony channel,
comprising:
a processor structure;
channel control hardware coupled to said first telephony channel; and
a memory structure having stored therein a database and software
instructions executable by said processor structure, said software
instructions including:
a database language sequencer;
a database control module having a plurality of procedures callable by said
database language Sequencer for performing at least one of the database
operations from the group consisting of reading selected data from and
writing specified data to said database; and
a telephony control module having a plurality of procedures callable by
said database language sequencer for performing at least one of the
telephony operations from the group consisting of speaking a predefined
prompt onto the first telephony channel, receiving and storing
DTMF-encoded input from the first telephony channel, and recording audio
input from the first telephony channel,
said database language sequencer calling said database control module
procedures and said telephony control module procedures in a sequence
defined by a program which satisfies predefined syntax rules of a
predefined database language.
12. Apparatus according to claim 11, wherein said database language
sequencer comprises:
said program; and
an interpreter which interprets said program to develop said sequence in
which said database language sequencer calls said database control module
procedures and said telephony control module procedures.
13. Apparatus according to claim 11, wherein said database language
sequencer comprises a product produced by the method comprising the steps
of:
providing said program; and
converting said program to software instructions executable by said
processor structure.
14. Apparatus according to claim 11, wherein said processor structure
includes no more than one processor.
15. Apparatus according to claim 11, wherein said memory structure includes
both semiconductor memory and rotating memory.
16. Apparatus according to claim 11, wherein said database operations
include all operations from said group consisting of reading data from and
writing data to said database, and wherein said telephony operations
include all operations from said group consisting of speaking a predefined
prompt onto said first telephony channel, receiving and storing
DTMF-encoded numerical input from said first telephony channel, and
digitally recording audio input from said first telephony channel.
17. Apparatus according to claim 11, wherein said telephony operations
further include the operation of waiting for a ring signal from said first
telephony channel.
18. Apparatus according to claim 11, wherein said telephony operations
further include the operation of answering a call from said first
telephony channel.
19. Apparatus according to claim 11, wherein said telephony operations
further include the operation of hanging up a call on said first telephony
channel.
20. Apparatus according to claim 11, wherein said telephony operations
further include the operation of dialing a call on said first telephony
channel.
21. Apparatus according to claim 11, for use further with a second
telephony channel, wherein said database language sequencer, said database
control module and said telephony control module comprise first
instantiations of said database language sequencer, said database control
module and said telephony control module, respectively, and wherein said
memory structure further has stored therein:
a second instantiation of each of said database language sequencer, said
database control module and said telephony control module,
the procedures of said second instantiation of said telephony control
module speaking a predefined prompt onto said second channel, receiving
and storing DTMF-encoded numerical input from said second channel, and
digitally recording audio input from said second channel.
22. Apparatus according to claim 21,
wherein said first and second instantiations of said database language
sequencer share a common set of software instructions and have different
instance data,
wherein said first and second instantiations of said database control
module share a common set of software instructions and have different
instance data,
and wherein said first and second instantiations of said telephony control
module share a common set of software instructions and have different
instance data, the instance data for said first instantiation of said
telephony control module identifying said first telephony channel and the
instance data for said second instantiation of said telephony control
module identifying said second telephony channel.
23. Apparatus according to claim 22,
wherein the common set of software instructions shared by said first and
second instantiations of said database language sequencer includes an
interpreter which interprets a database language program to develop said
sequence in which said database language sequencer calls said database
control module procedures and said telephony control module procedures,
wherein the instance data of said first instantiation of said database
language sequencer identifies a first program as the database language
program to interpret,
and wherein the instance data of said second instantiation of said database
language sequencer identifies a second program as the database language
program to interpret.
24. Apparatus according to claim 22, wherein said software instructions
stored in said memory structure further include:
a channel server common to both said first and second instantiations of
said telephony control module, said channel server performing said
telephony operations on said first telephony channel in response to
communications from said first instantiation of said telephony control
module, and performing said telephony operations on said second telephony
channel in response to communications from said second instantiation of
said telephony control module. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND
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.
SUMMARY OF THE INVENTION
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.
BRIEF DESCRIPTION OF THE DRAWINGS
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.
DETAILED DESCRIPTION
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 | | |
