JPH04248599A - Device and method of executing sound related application - Google Patents

Abstract

PURPOSE: To dynamically assemble a voice prompt from the vocabulary of a short prompt segment in a specific language by providing a means defining a rule depending on a language for transforming static voice information and dynamic voice information to other languages. CONSTITUTION: A voice application generating program(VAG) consists of an application manager, a voice application generating program, a prompt generating program and a state generating program. The VAG includes a state driving machine processing a prescribed state recorded in a state table and deciding next operation to execute between voice applications. In addition the VAG includes a voice application definition interface for interfacing with a voice application preparing person and this interface uses a state mechanical model with an instinctively meaningful state definition for the voice application preparing person.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention This invention relates to improvements in voice message processing and, more particularly, to dynamically assembling voice prompts from a vocabulary of short prompt segments in a particular language.

0002

BACKGROUND OF THE INVENTION Information handling systems with speech generation capabilities are currently utilized as answering machines, voice message systems, voice response devices, and generally as intelligent peripheral devices. The audio signal is
It may be prerecorded on audio tape, or it may be digitized and compressed before being recorded, for example, on a magnetic disk.

In a typical application, an information handling system is coupled to one or more telephone lines to detect the occurrence of a call signal and to answer the telephone. Standard prompt voice messages are often sent out over telephone lines. Depending on the type of system, the caller may press a button on a push-button dial telephone to inform the system about the particular type of treatment the user desires. For example, after listening to a message, the information processing system
It can access large databases, such as databases containing stock quotes. When the caller sends the data
The system can be instructed to access one or more quotes from the base, and then the system can convert the quotes into audio voice signals and output them to the caller's telephone line.

It will be appreciated that in such systems, the interaction between the caller and the system can be very complex. To take a relatively simple example, if a caller wishes to know whether there is a voice message stored for the caller, the system may ask "you have
three new voice messages
(There are 3 new voice messages for you)”
You can respond using an audio signal such as In generating this response, the number "three(3)" is a variable that is determined when the caller connects to the system.

Furthermore, the word "messages" is also a variable because if only one message is pending, the singular form "message" should be returned instead of the plural form. It can therefore be appreciated that the ability to accurately define a sequence of system responses to incoming calls is an important aspect of such voice response systems.

It would also be desirable for voice application writers to be able to generate and modify system responses in a relatively uncomplicated and time efficient manner. That is, system operators must be able to interact with the voice response system to create and modify voice responses without the need for direct assistance from the system provider or programming-skilled personnel.

Many business applications can be automated using voice processing techniques. Businesses can use voice processing devices to call customers and provide or request information. Additionally, a customer may call a company's voice processing device to obtain information, place an order, or forward the call to a service representative or other answering device. In other applications, voice processing devices may be utilized to exchange information with other call processing devices without human intervention.

[0008] In most cases, automatic call originating or forwarding equipment will, based on dynamic information entered by the user,
It must be possible to communicate information to the user. An example of a prior art call processing system that would benefit from incorporating the present invention is a voice editing data system that uses a display system for editing prerecorded speech, as disclosed in U.S. Patent Application No. 4,627,001. It is. Another audio data editing system is disclosed in US Patent Application No. 4,779,209. U.S. Patent Application No. 485
No. 3,952 discloses another text editing system for editing recorded audio signals. Another voice message processing system that includes voice prompts is disclosed in U.S. Patent Application No. 4,766,604. Finally, U.S. patent application Ser.
A file download system is disclosed.

[0009] All of the systems described above have a common drawback. They do not have dynamic voice prompt capabilities. The present invention overcomes this limitation by providing dynamic voice prompts.

0010

SUMMARY OF THE INVENTION In accordance with the present invention, a voice application generation program includes a state-driven machine that processes predetermined states recorded in a state table to determine the next action to take during a voice application. included. The voice application generator further includes a voice application definition interface for interfacing with voice application creators. This interface utilizes a state machine model with state definitions that are intuitively meaningful to application writers.

[0011] The invention further provides an apparatus for executing at least one audio-related application. The apparatus includes a state table memory that stores information representative of at least two states. Each state has
At a minimum, it includes identification of a state, identification of an action performed by execution of this state, and identification of at least one state to be executed next upon exit of this state. The apparatus further includes a state machine for reading information representative of a state from information related to the determined next state.

Memory means are also provided for storing static audio information and dynamic audio information. Additional memory is reserved for storing vocalization rules for audio information. The audio processing device dynamically assembles static audio information and dynamic audio information and converts them into audio using the audio information rules.

One aspect of the state machine is a prompt generator to provide guidance to the user in using the application. The voice prompt is
Consists of static and dynamic voice prompts assembled from a vocabulary of short prompt segments. These prompt segments can contain both statically generated words or phrases and variables. The resulting prompts sound like continuous speech to the user, but vary according to context, allowing system variables and temporary variables played as speech to be used with static speech segments. It becomes like this.

For example, a one-segment static prompt sounds like this: “Hello. Welco
me to the Global Bus Line
s Route System” A multi-segment dynamic prompt sounds like this: “You will
l be traveling from”＜Bos
ton> “to” <Chicago> In this case, the city name is a separate segment obtained from a database lookup. A difficult challenge in designing such dynamic prompting systems is how to accurately interpret the resulting data into speech. For example, numeric data can be changed to character data (“One”, “Two”, “Th”
ree”), numerical value (“One hundred t
three”) or monetary unit (“One
dollar and twenty three
cents”).

[0015] When supporting multiple languages, the system must change according to the grammatical syntax of the language when reproducing common data. For example, dates and monetary units are vocalized differently in various languages (e.g.
“123” is “One hundred twenty
three dollars” or “one hun
dred twenty three pounds”
).

[0016] This ability is achieved using self-defining variable data types that identify the permissible ways to reproduce variables. A graphical tool (voice application generator) is provided that allows a user (in this case an application developer) to construct prompts containing constants and variables from a segmented vocabulary.

[0017] This process is executed in the following manner. 1) The user starts the online application development tool (voice application generation program). During application development, users define prompts by selecting available segments from the segment menu (using the mouse). “play
If a segment with "as" attributes (such as date or time) is selected, a pop-up window appears and displays the "as" attribute (such as date or time).
play as” method (e.g. 12-hour or 2-hour
4-hour system). The user is also given the option of selecting the language configuration to use via a mouse-selectable dialog box. 2) During the prompt playback action, the session
The manager interprets prompt definitions by directly reproducing static variables and interpreting dynamic variables according to their current values, the user's selected options, and the language currently in use. Language rules are defined in tables that define how language-dependent data is played. These rules are comprised of phonetic segments, pauses, and translated primitives (eg, context-sensitive phrases such as "thousand", "tenth", etc.).

Prompts are constructed to suit a wide variety of applications using selected "play as" options and current data values under the control of a particular linguistic context. A user can develop an application in one language and run it in another language (assuming, of course, that there is a corresponding speech segment available in this second language).

The present invention thus provides a simple means of constructing composite voice prompts containing any mixture of static and variable data paired with language-dependent data vocalization rules.

[0020]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring to FIG.
System/6000 10, the system 10 includes:
It includes an AIX window 60, a voice application enabler (VAE) 70, and a database 50. Database 50 stores static and dynamic audio information and transfers it to the RISC System/6000's memory. The database 50 also includes means for storing vocalization rules for audio information. These rules are interpreted by a voice application generator (VAG) 80 and used to vocalize dynamic and static voice messages into appropriate user prompts.

Voice Application Enabler (VA
E) uses standard IBM hardware and operating systems, using the telephone as the interactive medium, to connect the caller to the application server and manage the session. The main elements of this system are:
Application Server Interface (ASI)
), a voice application generator (VAG), and a host, which is a host system that provides access and storage to the database.

VAE provides functionality and connectivity for customers to implement voice data applications. It connects to a customer premises or central office switch over a telephone line and recognizes dual-tone multi-frequency (DTMF) signals for the highest standards of voice compression and decompression. Make it. Customers can develop application scripts and voice prompts using an easy-to-use, high-level application-specific language or graphical interface and other development tools.

The operating system tools used to implement the invention are described in the following publications: "IBM Enhanced Interactive Executive for Personal System/2 (AIX PS/2) IBM A
IX operating system commands (IBM
Advanced Interactive Exec
Utive for Personal System
/2 (AIX PS/2) IBM AIX Open
rating system commands)”,
IBM document number SC23-2025-0, “IBM
AIX operating system, technical manual (IB
M AIX Operating System; T
”, SC23
-2032-0, “IBM AIX Operating System, Tools and Interfaces (IBM
AIX Operating System; Too
ls and Interfaces)”, SC23-
2029-0.

Voice Application Enabler (VA)
The prototype of E) is designed to support interactive transaction processing and integrate voice and data applications. This VAE
The main features are as follows.・Interfacing with telephone exchanges ・Advanced voice compression ・Using the telephone as an interactive medium ・Customer programmable at application level

Voice-data applications address two distinguishable environments.・Central office (CO) telephone company-enhanced service provision equipment ・Using a private branch exchange (PBX) or CO exchange,
Computer-aided telephone at customer premises

VAE provides functionality and connectivity for customers to implement voice data applications. VAE connects to an exchange using a telephone line and transmits DTM
Enables F exchange signal recognition and the highest level of voice compression/decompression. VAE also supports rotary telephones when voice recognition is enabled. Users can use an easy-to-use, high-level application-specific language or graphical interface and other development tools to
Can develop application scripts and voice prompts. Users can also use their telephones to conduct application sessions with host computers. Examples of such applications include voice message processing, voice information services, and database applications.

In a CO environment, generality of functionality, scalability, reliability, and support for multiple exchanges are critical requirements, whereas in a customer premises environment, cost of entry, broad functionality, and compatibility with multiple exchanges are critical requirements. Gender is the most important factor. Both environments utilize technologies such as multi-channel operation, real-time response, state-of-the-art voice compression, and telephone channel signal recognition and control.

VAE is compatible with a variety of line interface protocols, both domestic and international, ranging from a few analog voice channels to multiple T1 and Integrated Services Data Networks (ISDN). Customers can customize the VA to suit their applications.
E can be easily changed.

VAE is designed as a multilingual system. Only single-byte languages that are written from left to right are supported. Special treatment for other language requirements, such as right-to-left Hebrew and Arabic, and other single-byte or double-byte languages, will be made in the future. VAE enables language features and transformations, both hardware and software, for the transformation of customer and service information such as messages, help panels, documentation, terminology, etc.

Typical Scenario In a typical scenario, a user calls a telephone number and is connected to the VAE system by a CO switch. The voice system interacts with the user using dynamically assembled voice prompts and phrases, and the user interacts with the voice and
The DTMF button on the user's phone is used to interact with the voice system.

Using VAE, callers can interact with existing customer database applications and even switch to a human operator when necessary. For example, a voice messaging application may prompt the user to leave a message or search for it. Voice response applications can open the weather forecast, check your bank balance, and order pizza.

In all cases, the one-second response and uninterrupted audio flow allow the user to interact with the system as a single image, regardless of the call path. In this way, each customer can program the system individually, so that the system is user-friendly and able to interact with the user in a manner appropriate to the running application.

The T1/CEPT signal VAE needs to interface with various CO switches. Preferably, the media is T1-D4 in the United States and CEPT in Europe.

Telephone interface protocol line information is provided in a separate simplified message service in each implementation.
interface (SMSI) channel. This signal can also be obtained from call setup information from existing paid notification services such as SMSI.

Integrated Services Data Network (I
As SDN) develops and becomes widely used,
VAE is the preferred technology because its interface
protocols must be adopted. Some CO switches do not support the necessary interface protocol services for digital T1 services. In such a case, there is a strong possibility that it will not be possible to display a personalized greeting or a message waiting message. To be compatible with analog telephone systems, one channel bank is required to convert analog signals to digital signals.

Topology and scalability VAE is
Supports audio channels ranging from two or three to over a thousand channels. When redundancy and capacity requirements are lenient, the system is designed to run on a single standalone hardware platform. If your requirements are strict,
The design of this system allows for n+1 redundancy and distributed functionality, thus maintaining a single system image for the user despite very large configurations.

The design structure VAE is an application system, AIX
Works perfectly under version 3. VAE is IB
M RISC model (RISC system/6000)
works on. Users interact with the VAE using a high-level application language composed of preprogrammed primitives. Additionally, customers define and program application servers to complement the servers provided in the standard version.

Each VAE node supports up to 72 voice channels in the United States and up to 90 voice channels in Europe. The overall performance of the system depends on the application. Limited multi-language support is inherent in this design and will be included in future releases.

System Architecture The VAE system architecture is shown in FIG. This system consists of 3
It consists of two logical components.・Front end ASI90 ・Back end host database server 5
0 ・Operation console (VAG80, SAF, UAF and OAM)

In the most common form of system architecture, multiple ASIs and host servers are possible. In this general scheme, the ASI and host server components are linked using one or more local area networks or by a direct connection to a database host.

The hardware basis of the invention is based on the IBM
RISC System/6000 10. The operating system is a derivative of UNIX and has considerable real-time multitasking capabilities.
RISC/6000/AIX. The present invention utilizes a back-end database server 50 designed to utilize a set of sequential files accessed at the field level and indexed sequential files accessed at the field or record level. do. Field level access provides the functionality of a relational database management system. The database server functions include application scripts, system
retrieving and storing parameters, voice data and subscriber information.

Data base server 50 provides intelligent database services to ASI and VAG on demand. The functionality of this database server is
Runs on the same physical hardware platform as the ASI application. The systematic interface between ASI functions and database server functions is maintained common in composite and distributed configurations. This database functionality is provided by IBM. The custom server architecture allows customers to use the same database management services that VAE system servers use to
Customers will be able to define and develop features for their own designs. However, the specificities of the local server implementation are isolated from the ASI by the architectural interface.

Functional Features The basic functionality of the VAE system shown in FIG. Provide support for your application. Other operations are built on top of these basic functions or variations thereof.

Call Transaction A call transaction begins with the establishment of an active telephone connection with the CO on the ASI side. Identification of call information, such as the number of the called party, determines the selection of scripts to describe and control particular types of transactions. ASI can process all types of transactions for all subscribers and callers. No caller or transaction type is pre-bound to a particular server or trunk/channel.

The ASI call transaction control function follows a script during the duration of an active transaction. This script contains a list of actions to take, such as playing a prompt or receiving a number, and a conditional ordering of the actions within the list. The treatment library that resides within the ASI and within this script is customizable for each transaction or subscriber, but must be retrieved from the database via the host server. Common prompts are also cached within the ASI, but customized prompts and greetings reside within the database.

Compression and Decompression The audio signals are compressed and decompressed within the ASI immediately after being received from the CO and before being sent back to the CO. T1/C
EPT channel multiplexing and demultiplexing also occurs at this time. Therefore, the CO always perceives normal speech. DTMF detection functionality is built into the line hardware interface, allowing the user to interact with the system.

[0047] Numerical information is removed from the information by a control function. For message processing, compressed incoming messages are stored in a database in the form of segments at the time of recording. The recorded message is searched segment by segment and sent out after being decompressed, and consecutive segments are extracted so that the audio can be played smoothly. Prompts, greetings, and other audio responses are played as well.

[0048] The compressed speech segment is shared between the ASI and the host
Flows through links between servers. In this prototype,
The link between the ASI and the host is a logical construct designed to maintain compatibility and configuration flexibility in future releases. Functions within the host provide database access and other support necessary for ASI applications, such as updating user profile information. In addition to speech segments, control information is also transferred to the AS during this transaction.
I and the host server.

Application support from the host can complete this transaction and schedule subsequent activities, such as interpreting and passing the transaction to a remote database system. An interface located within the general purpose server allows customer applications to interact with the VAE. This interface receives transaction information from the ASI, activates functionality embedded in the application program, and sends the results to the ASI.
Return to.

Main Components FIG. 3 is a diagram showing the main components of the VAE system.・Application server interface 200
・Host 210 ・Operation, management, and maintenance (OAM) function 220 ・System administrator facility (SAF) 230 ・User management facility (UAF) 240 ・Voice application generation program (VAG) 250

This section briefly describes each of these components. The sections following the VAG section list and describe the actions of the VAG application.

Application Server Interface (ASI) The telephone system connects to the VAE through the Application Server Interface (ASI) 200 of FIG. This connection is a trunk channel that carries calls. Additionally, Simple Message Service Interface (SMSI) 205 is a separate signaling link through serial input/output ports that propagates call-related information such as source and destination identification. ASI 200 handles multiple calls at the same time, executes all logic, and maintains all state regarding each call. The number of message services deployed within an ASI system is a function of the number of connected trunks. Each ASI can be connected to at least one carrier, which is T1 with 24 channels in the US and CEPT with 30 channels in Europe.

Compression and decompression of voice traffic to and from trunk channels also occurs within ASI 200 . A
SI does not have disk storage for voice messages. Voice messages are sent to the host for storage and retrieved from host 210 upon request. Voice messages exchanged between the ASI and the host 210 are always compressed using silence compression at a compression ratio of 5:1. Clear channel mode (1)
Included in the VAE system.

ASI is built on RISC/6000, uses standard IBM components, and adds the necessary cards for switch connectivity and voice compression. ASI consists of the following elements: - Audio card set 260 - Audio driver 270 - Signal driver 280 - Cache manager 300 - Node manager 310 - State table manager 320 - Prompt directory manager 330
Data base interface manager 340

Voice Card Set The voice card set performs voice compression/decompression and signal management on multiplexed telephone channels. This consists of the following cards.

Voice Server Card (VSC) Performs voice signal processing and connects the RISC system/6000 host to AS
Interface to I. It includes a main signal processor (SPM or SP0) and five slave signal processors (SPS or SP1 to SP5). Three slave signal processors are on the daughter card.

Trunk Interface Card (TIC)
) is the daughter card of the VSC that implements the interface between the VSC and the multiplexed digital telephone line. There is a version for T1 and a version for CEPT. T.I.C.
uses an Intel 8751 microprocessor.

Voice Server Card Adapter (VSCA)
) is inserted into the Micro Channel bus and connects host 210 and V
Acts as an interface between SC260. VSC
A has no processor. This may be thought of as a translation mechanism between the Micro Channel bus and the VSC bus 260. The combination of VSC260 and TIC is VPACK
It is called. VPACKs (up to 6) are installed within the 7866 rack-mounted modem package.

Audio Driver The audio driver code is written as an AIX device driver. It operates synchronously with the voice card set, handling interrupts, and moving voice data and status information to and from the voice card set. The interrupt routine performs the following functions. - Read the status of each channel - Move raw audio data to and from the appropriate channels - Move encoded audio data to and from the appropriate channels - Play cached prompts Retrieve audio signals from cache ・ Receive and send signal information for each audio channel ・ Process signal information for each audio channel ・ VP
Read or write ACK card level status and commands Handle and notify alarm conditions

Signal Driver Signal driver 280 processes messages to and from the central office (CO).
This is the code that interfaces with 205. SMSI
is the telephone company's protocol for messages sent to and from the CO.

There are four types of messages sent to and from the CO:

CALL HISTORY Sent from CO to ASI. This is information that identifies a call when it enters the ASI 200 from the CO via the T1 line.

0063 MESSAGE WAITING I
NDICATOR (MWI) (Message Waiting Indicator)
Sent from ASI to CO. This signals the CO to turn on the message waiting light, initiate a stutter tone on the customer's phone, or turn off the message waiting light.

NEGATIVE MWI (Negative Message Waiting Indicator) A response from the CO to the ASI indicating that the CO is unable to process the corresponding MWI message.

UPDATE SWITCH Sent from CO to ASI. Requests that all outstanding MWI messages received from the ASI be transmitted.

Channel Processes Channel processes are the vehicle for ASI's application logic, with one active channel process for each active session. The session manager is the main execution element of the channel process and is responsible for interpreting user application scripts into script tables. Application scripts created using VAG consist of tables of actions, parameters, and conditional program flow parameters for various possible return codes or edges.

Examples of edges include key x being pressed, caller hanging up, and timeout. The state machine and code for all actions are reentrant and shared among all channel processes. Figure 4 shows part of a typical state table for bus schedules.
Shown below.

Internal State Table The first executed state table (internal state table) is hard coded into the state machine. This includes the following actions: IDLE ANSWERCALL to wait for notification from the node manager PLACECALL to get the user profile, get the state table, and answer the call
get profile, get state table,
Make an ENDCALL to ensure the line is on hook, reassign the line to a node manager, and perform any other necessary cleanup.

00
[69] At channel process startup, the state machine is called with a pointer to a hard-coded internal state table. The first entry executed is the Idle action. When receiving a notification, it moves from idle to awake state,
Checks whether the request is a response to a call or an outgoing call, then returns an appropriate return code to answer the incoming call.
Pass control to the werCall action. All subsequent actions depend on the return code. These return codes indicate that the action has completed or that some external event has occurred.

When the entire transaction is completed, Cl
The oseSession action is executed. This is the last action performed within a state table, at which time control is returned to the state machine's internal state table. The state machine then executes the EndCall procedure and once again executes the Idle procedure.

The state machine also supports nested state tables. Defining state tables allows users to develop libraries of commonly used functions and link them together to create larger and more sophisticated applications. This makes the state machine recursive and calls the CallState
This is accomplished by using the Table and ExitStateTable operations.

Cache Manager The Cache Manager controls memory storage and mapping for speech segments. Audio segments are stored in shared memory. The amount of cache required to store speech segments depends on the requirements of the customer application. You can adjust the amount of cache using the system configuration facility.

Cache storage is transparent. The requesting function is presented with a pointer to a list of audio segment pointers. If the audio segment is already in memory, the return is immediate. If the audio segment is not in memory, the first segment is retrieved from the host's database and a pointer to it is passed to the requesting function. The cache manager continues reading the remainder of this speech segment independently of the requesting function.

The cache manager stores audio data in a 4K buffer. The cache manager is 2
Contains two control blocks. The first control block is a directory containing a series of maps that describe the location in memory of each speech segment. The second control block is a short-term control block used to make a logical connection between the requested segment and the party that requested it.

[compress voice]
A dependent process called gments (speech segment compression) runs at predetermined time intervals to restore memory space that has become unavailable due to fragmentation.
Reorganize memory.

Node Manager The node manager, including the channel process,
It is considered the parent of other processes running within the SI. The node manager is responsible for loading and initializing the entire system, reading and interpreting parameters from system tables, and creating persistent speech segment and state tables and prompts.
Responsible for reading directories into memory. The node manager assigns channel processes to events when activity is indicated on an idle voice channel, and acts as a recipient of unsolicited requests coming from hosts. Exceptional conditions, such as alarms, are first handled by the node manager. The node manager also sets an inactive status for the selected channel for maintenance purposes.

The buffer pool managed by the node manager is a pool of 4K buffers available for allocation to other system managers and channel processes. Processes such as channel processes and system managers all request buffers through function calls. This process or manager then uses another function call to return the 4K buffer when it is no longer needed.

State Table Manager The State Table Manager provides access to the state table and maintains as many copies of the state table as necessary up to a predetermined limit. Channel processes access state tables to interact with callers. If a channel process requests a state table that is not currently in memory, the state table manager requests the state table from the database and, when it becomes available,
Notify channel process.

The state table manager continues reading state tables until a predetermined number of state tables have been read into memory. When this number is reached, the state table manager replaces inactive tables with new tables. If there are additional requests for state tables that are not in memory, the state table manager
If the least recently used state table is not currently in use, it is cleared and a new state table is requested to be read. The channel process is responsible for notifying the state table manager when a state table is no longer in use.

Other features of the state table manager include:
This includes handling state table invalidation requests, meaning that the state table has been updated by the VAG, and distinguishing between tables that are fixed in memory and those that are not.

Prompt Directory Manager The Prompt Directory Manager provides access to prompt directories and variable segment directories and maintains as many copies of prompt directories and variable segment directories as needed up to predetermined limits. The channel process accesses the prompt directory and the variable segment directory to play prompts for the caller.

When a channel process requests prompt and variable directories that are not currently in memory, the prompt directory manager requests them from the database and stores them when they are moved into place. Notify channel process. The prompt directory manager continues reading the predetermined number of prompt directories and variable segment directories until they have been read into memory. If there is an additional request for a prompt directory or variable segment directory that is not in memory, the prompt directory manager clears the least recently used directory if it is not currently in use and creates a new directory. request to read.

A channel process responds to certain prompts.
Responsible for notifying the prompt directory manager when directories and variable segment directories are no longer in use. The prompt directory manager is notified whenever the prompt directory is updated. If the prompt directory is in memory, the prompt directory manager flags it as invalid. When a channel subsequently requests this prompt directory, the prompt directory manager requests the updated prompt directory from the database.

[0084] The prompt directory is saved in a 4K buffer in memory. The number of 4K buffers required for a given prompt directory depends on the number of prompts in that prompt directory and the length of each prompt. There is no limit to the number of prompts contained in one prompt directory. One prompt
The number of 4K buffers that a directory can occupy is limited by the number of 4K buffers available.

[0085] Prompt directories are either permanent or temporary. Once loaded into memory, persistent prompt directories remain fixed in memory. A temporary prompt directory is used until the memory it occupies is needed to satisfy other prompt directory requests, or until the prompt directory manager
The K buffer remains in memory until notified by the node manager that it must be freed. In either case, only temporary prompt directories that are not currently in use are freed.

Data Base Interface Manager The Data Base Interface Manager is an AS
Provides an interface between I processes and database servers. A common protocol for processing all requests for database-based services and responses to these requests is called the Data Processing Request Block (DP
RB).

The DPRB's structural database interface manager maintains control tables to track outstanding requests that require a response from the database server. The information contained in this table includes: - Requester ID - DPRB number - Request time

[0088] Using the requester ID, the database
After the interface manager gets a response from the database server, the system can return the request. Requests and responses can be sent to a single DPRB or multiple DPRBs
Consists of RB. Using the request time, the system can accurately determine when a request times out. Some requests do not require a response from the database server. These requests are passed to the server without being recorded in the control table.

The amount of memory required by the database interface manager for control tables is
A function of the maximum number of requests that require a response and the maximum amount of time that the database interface manager must wait for a response before declaring a timeout and returning the request to the requestor. be.

Host system The host system consists of the following subcomponents: ・Data base management system ・Message routing program ・VAE database server ・Custom server

Data Base Management System The data base management system consists of a database service manager function, an indexed sequential file structure, and a sequential file structure. The database service manager or server receives DPRBs from the database interface manager and sends DPRBs to the database interface manager. The database server provides various database services to ASI and VAG. These services include retrieving, creating, deleting, and updating data in files, and performing various database backup and recovery functions.

[0092] a database service manager;
Indexed sequential files and sequential file access methods provide data access functions. Figure 5 shows the data
FIG. 2 is a diagram showing an overview of base files and the relationships between them.

Overview of Database Files Files can be accessed for service at the file level, record level, or field level, depending on the access method used to implement the file. can. For example, the indexed sequential access method is
Primarily used for record-level file access. Sequential access methods are used when record-level file access is not required. User profile files and mailbox files are accessed at the field level.

Message Routing Program The message routing program is implemented as an AIX queue to which messages are transferred from the database interface manager. Messages that are service requests from either ASI or VAG are formatted in either direct or indirect format. A direct format (or long format) is a format in which the input parameters are included in the message itself. Indirect format (or short format) is when the input parameter is D
This is the format included in the PRB.

In either case, the database server retrieves the request from the queue based on the type of message and receives it into the task space for processing.

Data Base Server There are the following four database servers in the VAE system. - State table and prompt directory -
Server/User Profile/Mailbox Server/SGAM Server/VAG Server

State Table and Prompt Directory Server The State Table and Prompt Directory Server retrieves state tables, prompt directories, or variable segment mapping files from the database and stores them through the database interface manager. and return this to ASI. The server uses a sequential file access method to accomplish this task.

[0098]User Profile/Mailbox/
Server The user profile server retrieves, updates, or deletes records in the user profile file for the ASI via the database interface manager. Records in the user profile file can be updated at the field level. For all functions other than search, the ASI can request the server to return an acknowledgment of completion. This server uses the unique user ID to search for records in the user profile file.

The mailbox server includes a mailbox database that provides a link between user profile files and message files. The mailbox database is the mailbox database.
An entry is a collection of message headers that describes each message arriving at the VAE. Related information contained in this message header includes the message ID
, sender ID, receiver ID, and message status code.

SGAM Server The Segment/Greeting/Spoken Name/Message (SGAM) server retrieves, generates, updates, and retrieves data units for the ASI through a database interface manager.
Delete, query, rename or copy. A data unit can be a segment, a greeting, a spoken name or a message. Each audio segment, greeting, audio name or message each contains a set of audio records and can be searched by a unique key. For example, a unique key for a speech segment consists of a segment ID and a sequence number.

[0101] Except for searches and queries, the ASI requires the SGAM server to return an acknowledgment of completion. This server uses an indexed sequential file access method to search for data units. Audio segments are stored in different files depending on the language code and compression ratio, greetings and phonetic names are stored in different files depending on the compression ratio, and messages are stored in different files depending on the recording date and compression ratio. be done.

VAG Server The VAG server searches for, creates, updates, or deletes records within a file or files. An example of a file is a state table or prompt directory. An example of a file record is an audio segment within an audio file or a record within a user profile. For all functions except search, the VAG requires the server to return an acknowledgment of completion. The server is
Primarily, a sequential access method is used for file access, and an indexed sequential access method is used for accessing records within the file.

Custom Server In addition to the standard VAE database server, the following two
Two specialized servers enable customer applications to connect to the VAE system.・3270 server・General-purpose server

3270 Server The IBM 3270 server supports existing host-based applications that use 3270-type displays and
It is a turnkey method to interface the AE. Other methods require the customer to develop custom interface routines. The VAE uses the AIX Host Connectivity Program (HCON) to connect the 3270
Supports various functions of the server. Communication with the host is A.
IX's Systems Network Architecture (SNA) services are provided by Token Ring and Synchronous Data Link Control (SDLC) links via RISC/6000 Token Ring and Multiprotocol Adapters.

[0105] Up to 26 concurrent sessions can
Supported by ring or SDLC link. Which 327 supported by AIX HCON
VAE can also be used with zero terminals or controllers. To generate the application, the customer must
to customize ASI interactions with 3270 servers. To accomplish this, customers use VAG features such as host session parameters, logon, expected host sequence, error handling, and data field locations and types. Generating VAE applications using a 3270 server does not require programming expertise or the use of a compiler.

General Purpose Server (GPS) The General Purpose Server (GPS) is a structure designed to provide open access to VAE facilities. This is used to support local and remote database access using custom servers. Generally, the customer is responsible for creating the required custom server using the custom server user interface in conjunction with the customer's own programming logic and VAE application generator.

The resulting custom server runs within the host or within the VAE's virtual host component. Server logic is COBOL, FORTRA
It is provided in the form of a customer specified source module or object module using a compatible programming language processor such as N, C or PASCAL. Any operating system services or facilities can be used, provided that the design must meet the performance requirements of the application.

Interaction with the VAE telephony environment is automatically provided using the created server's preprocessor stage. During a server development session, the customer's logic module is imported, host interactions are specified using front end scripts, and the combined specifications are passed to the creation process.

The design of GPS consists of two parts:
It can be explained separately into PS components and GPS system. This section briefly describes the components of GPS, followed by an overview of the GPS system. The components of GPS are as follows. - Application Program Interface (API) This interface module is part of the VAE system and is stored in a library within the VAE system database. - User application module group (UA
M) The interface modules are a collection of routines provided by the customer to provide access to existing customer application systems. - GPS Pre-Processing Program This is a parsing program for application specified files consisting of AWK programming files. - Application Specification File (ASF) This is a file that defines and specifies the parameters and information needed to create a custom server. This file is generated by the customer using a custom server user interface. - Application function/subfunction file group (AS
F), (AFF) These files contain the feature ID of the customer application system and information for calling the user application module. When creating a custom server, the customer is responsible for providing user application modules and generating application specification files. GPS provides the remaining elements and all processing necessary to create and implement a custom server.

The design system of GPS is shown in FIG. GPS is divided into the following four stages. - Developing a custom server - Script processing - Initial configuration of the VAE system - Runtime facilities Development of a custom server consists of generating an application specification file (ASF) and storing it in the VAE system database. . This is implemented using a custom server user interface. When an application specification file is generated, it is subjected to a BUILD process.

During the BUILD process, the GPS preprocessing program reads the application specification file (ASF) and generates the application function/subfunction files and the application control program. This application control program is compiled with a C compiler and linked with the user application module with the MAKE utility to create an executable file as a custom server.

Script processing consists of generating a script with the necessary action parameters to link the application with the custom server. The main treatment parameters are SendData treatment and ReceiveData treatment. Also, when generating a script, the script reads the application function/subfunction files and uses the custom server (bus scheduling) and subfunction names (get-city, get-schedule) to generate the script.

The application function/subfunction file instructs the script programmer to provide the required input parameters for the subfunction. During VAE initialization, the system sets up system parameters and allocates the resources necessary to implement the custom server. Finally, at runtime, the application executes the script table and sets the custom server number (function I
D) Send an RB (request block) containing the transaction number (subfunction ID) and parameter data to the custom server. The custom server then parses and converts the parameter data into input parameters and passes the input parameters to the customer application system.

[0114] When the customer application completes, the custom server passes the RB header to the VAE application and returns parameters.

Operations, Administration, and Maintenance Functions Operations, Administration, and Maintenance (OAM) functions for the VAE system include configuration management, performance management, and error management functions. OAM performs the following functions.・Providing a console interface for system operations and command execution ・Collecting statistics ・Reporting statistics ・Managing errors

Console Interface The OAM console interface provides an environment for system administrators to continuously monitor the status of the VAE system. The interface also allows system administrators to respond to alarms and warnings and take appropriate action. Status information is displayed graphically and refreshed at regular intervals. Context information includes: - Percentage of available buffer pool - Percentage of disk space in use - Number of active lines on each VSC and the status of each line - System performance statistics, such as audio segment cache memory requirements - System Configuration information

[0117] OAM console interface uses AI
Operates in the X Window (TM) environment. Screen controls and options are grouped by function and purpose and are activated by keyboard or mouse input. The main screen is divided into the following three areas. - Menu bar - System status display area - User selection status display area

[0118] A system administrator can execute administrative commands to change the configuration or operating characteristics of the system. Management commands include: - Starting, stopping or blocking channels - Starting or blocking the system - Controlling the use of system resources (buffer release requests)
・ Report requests ・ Change system parameters ・ Add user profiles and mailboxes,
Modification and deletion / Definition of service class / Change direction of console display to other devices

[0119]
Gathering Statistics Gathering statistics regarding system operation and resource utilization is accomplished by a process that is executed periodically. This process reads shared memory locations and interfaces with other processes such as the node manager and state table manager.

[0120] The data accessed by this process includes: - Buffer pool - Disk space - Speech segment cache completion rate - State table hit/miss rate - Prompt directory hit/miss rate -
Trunk line error performance

Reporting Statistics In addition to the error logging process described above, OAM records events in an event log. The event log includes call completion records, console events, and threshold violations.

Error Management VAE's error management system handles all errors detected within the system. Each hardware and software component is designed to identify error conditions. For example, the VSC constantly monitors trunk conditions and presents error conditions (in the form of alarms) to the VAE software. Similarly, each component of the VAE's software tests for invalid input, system-related failures, illegal requests, or resource availability issues. Using this scheme, the VAE provides the variable err as an interface to custom server writers.
_enroll, but the prototype does not allow customers to use this error recovery service.

VAE Software Error Recovery For VAE software failure conditions, the 10 identified
The goal is to cover 0%. That is, all identified error conditions are detected and recovery actions are assigned. All recovery procedures are broadly classified into the following five types of recovery procedures.・Logging ・Local process recovery ・Multiple process recovery ・Single process restart ・System restart

[0124] If a software module receives invalid input, the VAE can log the problem, ignore the transaction, and notify the requester about the error condition. Intermittent failures, such as failed database queries, can trigger process local recovery measures, in which case the requesting process can retry before communicating the problem to OAM. .

[0125] A shortage of shared buffers in the buffer pool may require multi-process recovery procedures. In this case, the requesting process notifies a system management process, such as a node manager, and the system management process requests other processes to free the unused buffer so that it can be used as part of the original request. Make the original available.

[0126] To recover from a VAE software failure caused by data loss, logic error, or specified bounds exceeded, the channel process is stopped and reinitialized if possible. This is an example of single process restart. The same applies to failures caused by event overflows or erroneous interrupts. The error management system typically can restart a VAE process other than the system management VAE process that has failed. Failure of a system management process requires restarting the entire system.

AIX and System Hardware Error Recovery The scope of addressing non-VAE issues is limited only to errors detected by AIX or hardware. AIX and system hardware errors may be recoverable or non-recoverable. Disk and controller failures, memory checks, bus checks, and other hard errors are almost always fatal. Fatal errors require human intervention. When an intermittent error occurs during normal software execution, the software can perform at least one retry before communicating the problem to OAM.

Failures caused by lack of resources may or may not be fatal. In recoverable conditions, such as a full disk condition, all attempts to record audio or update user profiles will fail. Under these conditions, when more 3270 emulation sessions are needed than currently enabled, a system busy announcement will be played and resources will be made available if specified in the customer script. Input is rejected until

Telephone line trunk line interface (VSC)
) are analyzed and a determination is made of a red alarm, yellow alarm, or alarm indication signal. When a red alarm occurs, the VAE system disconnects all calls on that device and keeps all channels on the calling end busy while the condition persists. V.A.
The E-system will automatically restore service after this alarm is cleared.

Certain conditions generate more errors than the logging device (or host) can handle. Means are provided for setting a threshold for error reporting. These threshold settings are variable and can be reset. The console operator is informed of the status of all channels and of any errors. The operator then diagnoses the error and initiates appropriate error recovery actions.

[0131] System Administrator Facility (SAF)
) SAF is a VAE application that enables system administrators to establish, maintain, and support the following system functions: - Application Profile - Administrator Profile - Language Support - Setup - System Configuration SAF is menu-driven and essentially a graphical workstation application that uses an AIX window as the basis for its design. Access to SAF is from the default main window for the VAE application.

Application Profiles Application profiles are used at call time to set up actions to be taken after a call is answered. The most important information stored in an application profile is the state table ID (the application to be executed) and the entry point within that state table. Application profiles are stored in the same file as user profiles. Unlike a user profile, this does not describe the user, but instead describes the application.

The application profile user interface consists of panels into which the system administrator enters profile data. This panel displays a list of existing application profiles and
Actions: ADD, DELETE
, MODIFY and SEARCH. To the right of this panel is a work area where application profile information is entered and displayed. The system administrator can select an existing application profile from the list and perform certain actions on it, and can add new profiles using the ADD action.

[0134] Each application profile includes:
Includes: - Phone number - Application name - Comment field - Language ID - State table used with the application - Release number of the state table - Entry point into the state table

013
5] National Language Support (NLS) Setup The VAE system processes applications in multiple languages simultaneously. To this end, a National Language Support (NLS) setup program is designed and implemented. N.L.S.
The setup program provides the system administrator with the option of duplicating the application in the new language and then updating the application with the new language. NLS is designed like other SAF programs using AIX windows.

[0136] When selecting NLS from the SAF menu,
A system administrator can modify screens for existing languages or generate screens for new languages. There are two parts to the NLS program. 1st
section allows the system administrator to change the language displayed within the panel fields of that application. Using the NEXT action on an NLS panel, the translatable panel fields are presented one by one. Examples of these fields are MODI
They are FY and DELETE.

The second part of the NLS program converts the application's text into the new language. The system administrator is presented with the application's panels one by one and can change the language of the text in each panel. Examples of text that is converted are status, purpose, treatment name, and edge name.

In addition to changing the language of the text for an application, the system administrator can also change the playback characteristics of audio information in the selected language.

System Configuration System Configuration is a menu option that allows the system administrator to edit configuration parameters. Configuration parameters are grouped by logical components. The default configuration groups are as follows. - VAE configuration - ASI configuration - VSC configuration - Language configuration The configuration panels are the same for all groups. On the left side of the screen there is a list of parameters to select from, and on the right side there is space to change the selected parameters.

VAE Configuration The VAE configuration consists of system parameters that define the operating characteristics of the VAE system. The VAE configuration program stores and displays these system parameters so that system administrators can access them when modifying the system configuration.

The VAE configuration program allows system administrators to configure the system at initial startup and reconfigure the system when modifications are made. System configuration includes tasks for selecting the disk space used for logging messages and setting timeouts for timed actions. Like the other programs discussed in this section, VAE Configuration is a menu-driven program that uses a graphical panel user interface.

ASI Configuration The ASI configuration consists of parameters that define the operational characteristics of the ASI. The ASI configuration program remembers and displays these parameters so that system administrators can
These parameters become accessible when modifying the ASI configuration.

[0143] The ASI configuration program allows the system administrator to configure the ASI at initial startup and reconfigure the ASI when modifications are made. ASI configuration includes the tasks of specifying the size of the 4K buffer pool, determining the size of the cache,
and the task of selecting the number of voice cards. As with the other programs discussed in this section, the ASI configuration is
It is a menu-driven program that uses a graphical panel user interface.

[0144] VSC configuration By using the VSC configuration program, the system administrator can configure VSC at initial startup, and configure VSC when modifications are made.
It becomes possible to reconfigure the SC. VSC configuration includes tasks for setting information about telephone connections, such as compression format, number of lines per trunk, and type of trunk. Like the other programs discussed in this section, VSC Configuration is a menu-driven program that uses a graphical panel user interface.

Language Configuration Language configuration refers to a method of defining system configuration parameters for each language. English serves as the basic language. System administrators can use this language construct to
Describe how to play variables such as numbers, dates, times, currency units, and telephone numbers. For example, the audio format for data includes the portion of that variable that is played (day of the week, day of the week, month, year), as well as a modifier for that variable (whether the day is ordinal or cardinal). Additionally, variable mapping tables allow system administrators to define the smallest or "primitive" elements of a variable (such as month or day of the week).

Utility Module The utility module provides report printing of selected system data files, such as user profiles, application profiles, system administrator profiles, etc.

[0147] The user management facility UAF is created by the system administrator, and
It is an interactive program that allows you to maintain. - User profile - Sent message list - Received message list

User Profiles The User Profiles feature allows system administrators to create and maintain data that defines each user. This data is maintained within the user profile. Each user profile is
Uniquely identified by a user ID (phone number/extension) and one or more mailbox IDs (one user can have multiple mailboxes). Using the user profile feature, system administrators can: - Explore user profiles in the user profile list - Select a user profile from the user profile list - Specify the contents of a user profile's data fields - Add a user profile to the user profile list Add a user profile Modify an existing user profile in the user profile list Delete a user profile from the user profile list Select the mailbox retention feature

[0149]
The message sent from the mailbox is VAE
A mailbox maintenance function that lists messages sent by each user in the system. The Sent Messages list allows system administrators to search for messages within the list.

Messages Received in Mailbox This is a mailbox maintenance function that lists messages currently received by the user in a given mailbox. Using this feature, system administrators can: - Search for messages in a list - Delete selected messages from the mailbox - Delete all messages from the mailbox

Voice Application Generator The Voice Application Generator is a tool used to generate Voice Application Enabler (VAE) applications. This is typically a graphical workstation that application developers use to create, modify, and customize voice applications. The main functions of VAG are as follows. - Generation and modification of speech segments - Generation of prerecorded system messages, known as prompts - Generation of state tables that facilitate application flow and define edge and default states
Maintaining and testing voice applications Providing links between 3270 servers and other host-based applications Creating and implementing custom servers

Application developers use the VAG facility to generate original default scripts and prompts when first implementing a VAE system. This functionality allows the creation of applications that enable the VAE system to function as an answering machine, voice message processing system, and voice response device, among its many other application capabilities.

[0153] The VAG incorporates a SEARCH function and an online HELP system. The SEARCH function provides list search operations for all appropriate VAG routines. HELP(
The help) system provides the following: Menu-driven, context-sensitive help panels for each menu Item-level help screens for selected items on each menu Highlighting selected words in the help text Techniques are also provided. The help text displayed is
Depends on the language. VAG is multilingual, menu-driven, and consists of:・ Application manager ・ Voice generation program ・ Prompt generation program ・ Status generation program

Application Manager The Application Manager maintains the applications available within the VAE system. It also maintains state tables, prompt directories, and audio segments that define an application. The application generator allows the user to perform the following functions. - Select an application from the application list - Delete an existing application and all of its components - Delete the state table - Delete the prompt directory - Debug the state table - Custom server -
Provide an interface Save the complete application to a storage medium Restore the complete application from the storage medium

State Table Debugger A state table debugger allows system administrators to examine the functionality of a given state table and determine whether and where problems exist within a given state table. Provide functionality that allows you to do so.

Custom Server User Interface Custom Server User Interface (CSU
I) is a tool used to generate, create and maintain custom servers. This is typically a graphical workstation used by application developers to develop application specification files. This application specification file is a module that GPS uses to create custom servers. From the main screen of the custom server application, the application programmer can choose to scan or modify an existing custom server or create a new server.

[0157] Voice generation program The voice generation program generates/changes/changes basic units of voice.
Used for deletion. The basic units of speech are words, phrases, sentences, or collections of sentences, and are called speech segments. Speech segments have both textual and acoustic representations. A speech segment identifier is a link between a text speech segment and an audio speech segment.

The speech generator is an interactive program that allows application developers to: - Generation, modification, deletion and display of textual representations of words, phrases and sentences recorded as speech segments - Generation, modification, deletion and display of digitized speech segments Speech generation programs can be divided into two types: text editing and audio editing. Divided into two main parts. Text editing consists of the editing of audio segments in the form of text, and audio editing consists of the editing of audible audio segments in the form of digitized audio signals. The user interface of the speech generation program consists of two work panels into which textual and digitized speech data are input, respectively.

The first panel shown in FIG. 7 is the VAG Prompt Segment Editor. This display provides the user with a highly visual and user-friendly way to list and maintain textual representations of speech segments. Using a mouse and keyboard, the user can input and modify text representations of speech segments in a straightforward manner. The user then changes the cursor to MOD VOIC
Simply click the mouse button while on E.
It is possible to switch from a panel of textual representations of audio segments to a panel of digitized audio signals. In fact, the main feature of this audio generation program is that it is easy to move from a textual version of a speech segment to a digitized version and work on both versions simultaneously.

The second panel is a VAG digitized audio editor panel similar to the panel shown in FIG. It allows users to:・ Select and display one or two audio segments ・
Use the zoom procedure to display an entire audio segment or selected parts of a digitized audio signal magnified for close-up; generate new audio segments from existing audio segments;
Delete a selected part of a speech segment; Copy a selected part of a speech segment to another location within the speech segment; Copy a selected part of one speech segment to another; Switch between windows and
Edit two audio segments at the same time Play and record audio segments

Prompt Generation Program The prompt generation program is used to generate/modify/delete prompts. These prompts are recorded sentences or collections of sentences that are presented to subscribers when they communicate with the telephone system. The prompt generator is an interactive program that allows application developers to: - Generate, modify, delete, and display prompt directories - Generate, modify, delete, and display individual prompts

The prompt generator is divided into two main processes: defining the prompt directory and defining the prompts listed within the directory. The prompt generator's user interface consists of three main work panels into which the information necessary to define prompts and prompt directories is entered.

The first and second panels are the VAG Prompt Directory Editor panel and the VAG Prompt List Editor panel. These user interface panels provide the user with a highly visual and user-friendly way to list and maintain both the prompt directory and the prompts themselves. The user can enter and modify prompts and prompt directories in a straightforward manner using the mouse and keyboard.

The third panel is the prompt panel shown in FIG. This is essentially the work area where prompts are generated. This panel provides the application developer with a list 510 of speech segments for which prompt creation is to be performed, and tools for generating conditional decisions within the prompt. This panel also provides a list 500 of variables when variables must be played in the prompt. These tools are presented as interactive windows that display the necessary information. The user only has to select the required information from this dialog window. The design of this user interface is
Provides a very convenient and efficient way to create prompts from speech segments, variables, and conditional tests.

State Generation Program The state generation program is a tool used to create/modify/delete state tables and states. A state is one of the logical sequences of actions that make up a telephone application.
It is one stage or step. A state table is a table consisting of these states. The state table is
Provides the VAE with basic rules for executing applications with states, actions, parameters and edge values.

The state generation program is an interactive program that generates and updates state tables and states. It consists of a VAG State Table Editor panel and a VAG State Editor panel. The VAG state table editor panel is shown in FIG. These panels allow the user to: View the complete state table, including state number and purpose. Create, add, modify, or delete a state table. Select a state by number from the displayed list and view its details on the second panel. - Defaults such as preassigned edge values
Set options. - Display a complete list of actions and their rules, including required inputs, including parameters and required edges. - Modify an existing state - Delete an existing state - Create a new state

[0167] When modifying or adding a state, the user should:
A treatment can be selected by selecting from a displayed list of treatments or by entering the treatment in the field provided on the panel. In addition, if parameters are required, a list 600 displayed on the panel
Select it from. Then the state generator will do the following:
Prompts for the edges 610 required for the selected procedure.

[0168] When this application completes, ch
A feature called eck consistency is enabled. This feature monitors the following: - Validity of edges that refer to existing states - Validity and existence of parameters, if required. For each prompt, test in all defined languages to verify the prompt's existence. - Minimum logic necessary for a certain state, such as the existence of CloseSession processing

VAE Application Actions The following summarizes the actions used when defining state tables. - Idle (internal processing) - AnswerCall (internal processing) -
EndCall (end of call) (internal procedure)/Pla
yPrompt (prompt playback)/GetKey
(key acquisition) ・ GetData (data acquisition) ・ GetText (text acquisition) ・ GetF
indName (name search acquisition)/GetFind
Password (password search acquisition) ・ EvaluateData (data evaluation) ・
AssignData (data assignment)/Play
Voice (audio playback)/Record Voice
(Voice recording)・SaveVoice (Voice save)
・DeleteVoice (voice deletion)・Ch
eckStorage (Storage area check)・Check
Mailbox (mailbox inspection)/Upda
teMailbox (mailbox update) ・ UpdateUserProfile (user
Profile update) ・ SendData (data transmission) ・ Rece
iveData (data reception)/GetFindD
ata (data search acquisition)/CallStateT
able (call state table) - ExitStateTable (exit state table) - Disconnect (disconnect connection) - Clo
seSession (Session Close) Each of these actions is described in the following sections labeled with each action's name.

Idle (Internal Procedure) The Idle procedure is reserved for internal state tables only. This action is performed by the channel process when it has nothing to do. This action causes the process to sleep while waiting to be notified of the semaphore by the node manager. When notified, Idle determines whether the node manager is asking the process to answer the call or make the call, and then sends the appropriate edge. Return to state machine. Parameter None Edge 0=AnswerCall1=Pl
aceCall HUP=EndCall

AnswerCall (Internal Action) The AnswerCall action is reserved for internal state tables only. This action causes the channel process to
Initialize to handle incoming calls. This action searches for the called phone number in the user profile and
Search the state table defined within that user profile and search the prompt directory defined within that state table. The action then answers the phone and calls the state machine, passing the state table and starting edge defined in the user profile. Parameter None Edge EndCall

EndCall (end of call) (internal procedure) E
The ndCall action is reserved for internal state tables only. This action performs cleanup when a session completes. This action reallocates all lines used in this session in the line table and returns them to the node manager so that they are reset (on hook). Parameter None Edge Idle

[0173] PlayPrompt (prompt playback)
This action creates and plays the audio segments defined in the prompt directory. The prompt is played in the language specified in the application profile. The prompt consists of the following:・Prompt ID number. This number identifies the prompt and is used as a parameter of PlayPrompt. - Forced playback option. This number indicates whether a certain prompt is forced to play. -Timeout option. This number is
Specifies the number of seconds the user must respond on a Key or GetData action. -Repeat option. This specifies the number of times the prompt is repeated before the T2 timeout. A T2 timeout initiates a connection break. - List of segment IDs, system variables, and conditional judgments. Conditional decisions control which segments and variables are played for a particular prompt based on runtime conditions.

[0174] For example, PlayPrompt is used whenever the system interacts with a user to provide information and instructions, or to respond to a question. For example, in a voice message system, if the user specifies the LISTEN option, the prompt would be: "There are no new messages. There are 4 old messages. The oldest message is from 2 weeks ago." Parameter PROMPT NUMBER (prompt number)
There is no default for this. FORCE PLAY Force play means to play the prompt in its entirety even when interrupted by a keystroke. Force play is used when there is an important message, such as when the audio storage is full. In this case, the message is not interrupted. The force play flag exists in the prompt directory. In this case, the force play parameter overrides the flags set in the prompt directory. The default is to not force if a key on the phone pad is pressed. This means that if the user does not want to hear the entire prompt, they can interrupt the prompt by typing a key. The system then automatically advances to the next step of the application. Edge 0 = Prompt played completely unless it was interrupted by a keystroke. If interrupted, the prompt will not be played completely. 1 = Problem with voice channel HUP = Caller hung up

GetKey GetKey is used to receive key input from the caller when an option selection is given in a previous prompt. The previous prompt also provides GetKey with the number of seconds to wait before timing out and the maximum number of times this prompt will repeat before timing out. Ge
The tKey procedure recognizes only single keystrokes.

For example, the prompt might be ``Press 1 to record, 3 to listen, 8 to change personal options, 7 to exit the system, then press #
Please press. ”, then the above PlayPr
The logical state processed after the ompt operation is GetKe
y treatment. In this example, pressing key 1 activates the recording session, pressing key 3 activates the listening session, pressing key 8 activates the personal options session, and pressing key 7 activates the system. Get out. If you press any key other than these, a Pl that says "That command is not understood. Please try again."
ayPrompt is executed. Parameters BUFFER NAME Keystrokes are stored in this buffer for later use. The default is to use keys only for edge values. Edge 0 = User pressed key 0 1 = User pressed key 1 2 = User pressed key 2 3 = User pressed key 3 4 = User pressed key 4 5 = User pressed key 4 Key 5 pressed 6 = User pressed key 6 7 = User pressed key 7 8 = User pressed key 8 9 = User pressed key 9 * = User pressed key * # = User pressed key # T1 = Time out T2 = Last repeat HUP = Caller hung up

GetData (data acquisition) GetKe
Whereas the y treatment is used for a single keystroke, the Ge
The tData procedure allows an application to receive multiple keys in a single state step. The last key pressed upon completion of input must be the # key. This action accepts multiple keystrokes and stores them in one variable. Edges are returned that reflect the state of the input. The previous prompt also provides GetData with the number of seconds to wait before timing out and the maximum number of times this prompt will repeat before timing out.

[0178] For example, if the prompt is "Please enter a new password. Your password must be between 5 and 8 characters.
Must be character length. ”, then Ge
tData operations require keystrokes of a minimum of 5 characters and a maximum of 8 characters. The caller must press the # key after entering the 5-8 character password. Parameter PARM1 Buffer name P of the buffer that stores input
ARM2 The shortest length of the input if the buffer is a string, or the minimum value of the input if the buffer is a number. PARM3 The longest length of the input if the buffer is a string, or the maximum edge of the input if the buffer is a number 0 = Input length or value is correct 1
= Input too short or value too small 2 = Input too long or value too large 3 = Input incomplete, # key not pressed T1 = Timeout, nothing entered T2 = Last repeat HUP = Caller hung up

GetText (text acquisition) GetT
The ext procedure operates much like the GetData procedure. Using this procedure, an application can
It will be able to accept ASCII text data as input from the MF key pad. To specify a single ASCII character, the caller presses two DTMF keys. Upon completion of the input, the caller must press the # key.

[0180] The ASCII text entered during this procedure is stored in a string buffer. Edges are returned that reflect the status of the input: too short, too long, or timed out while waiting for input. Parameter PARM1 Buffer name P of the buffer that stores input
ARM2 Shortest length of input PARM3 Longest length of input Edge 0 = Input successful 1 = Input too short 2 = Input too long 3 = Incomplete, timeout occurs T1 = Timeout
Out, no input T2 = Last repeat HUP = Caller hung up

[0181] GetFindName (name search acquisition)
This procedure is used whenever a calling party or message recipient must be identified by a numeric name or extension. A numeric name is the representation of a user's last name as it is spelled using the phone's alphanumeric keypad. G
etFindName is used when a caller logs on to a system service or when a caller sends a message through a system service.

GetFindName performs identification by matching the caller's keystrokes (SMSI caller ID (00), numeric name, extension number) against a list of user IDs generated from the host. When an extension number or numeric name is entered, the channel process receives and accepts a minimum number of keystrokes for identification. The channel process uses its keystrokes to
Search the list of D from the host. The process then searches this list of user IDs for a unique match.

GetFindName requests the user profile stored in the database when the caller or destination has been identified. For example, the system
When logging on to the service, the caller is given the option of keying in # or his or her extension number or numeric name. GetFindName is the caller's #
When entering keystrokes, enter SMSI for identification.
If you use caller ID and the caller enters their name or extension, use their keystrokes.

In either case, when a keystroke is entered, GetFindName uses a host-provided list to identify the extension or numeric name. When a caller enters an extension number or numeric name as a destination when sending a message to another person, GetFindNa
me uses the list provided by the host to identify the recipients, so the message is routed to the correct destination. Parameter CALLERS' USER ID
(Caller's User ID) This parameter is
This means that FindName is used to identify the caller. DESTINATION USER ID This parameter means that GetFindName is used to identify the recipient. Edge 0 = found 1 = not found 2 = incomplete input, timeout occurred T1 = no input, timeout occurred T2 = final time
HUP with out call = caller hung up

GetFindPassword The GetFindPassword action compares the keyed-in password to the password defined in the user profile. The last key entered must be the # key. Parameter Unnecessary edge 0 = Password is correct 1 = Password is incorrect 2 = Incomplete input (timeout) * = Incorrect key input, if incorrect, the process is stopped T1 = Timeout T2 = Last repeat HUP = caller hung up

[0186] EvaluateData (data evaluation)
This procedure is used to test the value of a system variable against other variables or constants. The flow of the state table can then be changed based on the results of the evaluation. Parameter PARM1 Variable ID or constant PARM2 to test
Variable ID or Constant Edge 0 = PARM1 is less than PARM2 1 = PARM1 is equal to PARM2 2 = PARM1 is greater than PARM2 HUP = Caller hung up

AssignData This action can be used in state tables to perform simple arithmetic operations or string concatenation. This can be used to preset a variable to a particular value before using it in a procedure or as a counter in a state table.

For example, the AssignData procedure is
Can be used for loop processing. If there are three prompts for one password, after the first prompt, the AssignData action can be used to loop back to the first prompt. As
The signData action can also be used to preassign a given value to a variable before invoking another action. Parameter PARM1 operation (1 addition, 2 subtraction, 3
Multiplication, 4 Division, 5 Assignment only) PARM2 Buffer variable IDP to store the result
ARM3 First operand variable ID or constant, PARM1 is 5
If not, also use this parameter PARM4
Variable ID or constant edge 0 = Allocation complete 1 = HU whose buffer overflowed as a result of allocation
P = caller hung up

0189] PlayVoice (voice playback) Play
Like the Prompt procedure, this procedure plays the digitized data on the audio channel. This is used to play audio segments, audio names, user greetings, or user messages (voicemail) from the host database or the RecordVoice workspace area. This procedure is used after recording audio to allow the user to inspect the recording before saving it. This action is also used in the case of user messages before sending the message to the destination mailbox. Each user message is assigned an active message number. This is a pointer activated by the header of the current message under examination. Parameters PARM1 Audio type 1 Audio segment (PlayVoice can only be used by the administrator to record or play back audio segments) 2 Audio name 3 User greeting 4 User message (PlayVoice uses GetK
using the activity message number, which is the variable specified by ey)
The following parameters are required depending on the voice type. PARM2 for phonetic segments Name of the numeric buffer holding the phonetic segment ID PARM3 Name of the numeric buffer holding the language code PARM2 for phonetic names Name of the character buffer holding the user ID PARM2 for user greetings Name of the character buffer that holds the user ID PARM3 Name of the numeric buffer that holds the greeting entry number
Name Note: For any audio type, PARM 2 can provide a workspace area. A workspace area is an area where a user can play recently recorded audio data before making a record, save or delete decision. Edge 0 = Voice conversion complete 1 = Voice channel problem 2 = Voice record not found HUP = Caller hung up

[0190] RecordVoice (voice recording) This procedure records the voice as digitized voice data.
Used to record audio segments, audio names, user greetings, or user messages on the system disk.

Audio data is first recorded in a temporary workspace area. From this area, PlayVoic
Using e-procedures, audio data can be played back and inspected. Parameters PARM1 Voice type 1 Voice segment (RecordVoice can be used to record or play back voice segments only by the system administrator) 2 Voice name 3 User greeting 4 User message (RecordVoice is
Edge 0 = Recording complete 1 = Audio channel problem 2 = No audio recorded 3 = Disk full T1 = Time out, before maximum time is reached , xx seconds of recordable time remain, which is specified by the system administrator T2 = Maximum recording time reached HUP = Caller hangs up

SaveVoice This action saves previously recorded voice data in the specified format. When recording audio, the data must be
First, it is recorded in a temporary workspace. This action copies audio data from the workspace area to its destination (eg, audio segment ID, audio name, user greeting). Parameters PARM1 Voice type 1 Voice segment (SaveVoice can only be used by the system administrator to record or play back voice segments) 2 Voice name 3 User greeting 4 User message (SaveVoice can be used to record or play back voice segments)
The following parameters are required depending on the voice type: PARM2 for phonetic segments Name of the numeric buffer holding the phonetic segment ID PARM3 Name of the numeric buffer holding the language code PARM2 for phonetic names Name of the character buffer holding the user ID PARM2 for user greetings Name of the character buffer that holds the user ID PARM3 Name of the numeric buffer that holds the greeting entry number
Name For user messages PARM2 Name of the numeric buffer holding the recipient ID PARM3 Mailbox ID Edge 0 = Save Successful 1 = Save Failure HUP = Caller hung up

DeleteVoice This action deletes previously recorded audio data of the specified audio type. Parameter PARM1 Voice type 1 Voice segment (DeleteVoice can only be used by the system administrator to record or play back voice segments) 2 Voice name 3 User greeting 4 User message (DeleteVoice is
The following parameters are required depending on the voice type: For phonetic segments, PARM2 Name of the numeric buffer that holds the phonetic segment ID PARM3 Name of the numeric buffer that holds the language code For phonetic names, PARM2 Name of the character buffer For user greetings, PARM2 Holds the user ID Name of character buffer PARM3 Name of numeric buffer holding greeting entry number
Name Note: For any audio type, parameter 2 provides the workspace area. Edge 0 = Deletion Success 1 = Deletion Failed 2 = No voice record found HUP = Caller hung up

CheckStorage (Storage area check)
This action is used to check system resources in order to allow another flow through the application based on available resources. This action is typically used at application startup to determine if there is a storage problem. This procedure is also used to determine whether there is space available and whether the item already exists before recording. Parameters during a call PARM1 Status of the resource or item to be examined 1 Speech segment exists 2 Spoken name exists 3 User greeting exists 4 Mailbox space available 5 System disk storage space available Based on the conditions specified above, the following parameters are also required: For phonetic segments, PARM2 Name of the numeric buffer that holds the phonetic segment ID PARM3 Name of the numeric buffer that holds the language code For phonetic names, PARM2 Name of the character buffer that holds the user ID PARM3 Holds the language code Name of the numeric buffer holding the user greeting PARM2 Name of the character buffer holding the user ID PARM3 Name of the numeric buffer holding the entry number for the greeting in the application profile PARM2 For the mailbox space User ID ID of the character buffer holding the PARM3 1 Check space for new messages 2 Check space for saved messages
Edge to check 0 = Condition is true 1 = Condition is false HUP = Caller hung up

CheckMailbox (Mailbox Inspection) The CheckMailbox action checks the mailbox of the specified user ID for incoming or outgoing mail. This means, for example, that the message headers of messages stored in the database include
This is a check to see if message attributes are included, such as the sender's user ID, the date and time the message was sent, and the type and status of the message. When a user calls CheckMailbox for the first time, the active message number serves as a pointer to the current message header being checked. User CheckMail
When continuing to call the box, the active message number serves as a pointer to the next message header in the database. At this time, actually the parameter Check first defined in the state table
entry (inspecting the first entry) and Check
next entry is called, the newest message is played first,
Older messages follow. Parameter PARM1 1 Check first entry 2 Check next entry PARM2 (if parameter 1 = 1) 1 New incoming mail 2 Old incoming mail 3 New outgoing mail edge 0 = No message 1 = Message retrieved 2 = Mailbox in use HUP = Caller hung up

[0196] UpdateMailbox (mailbox update) This action is used to discard or save the received message, to send the message to another user ID,
or update the message header entry of the message to update attributes of the message. For example, using this action, a user can change the selection type (e.g., normal, urgent, urgent) of a given message, change the security level of a given message, or update the recipient ID. . Parameter PARM1 Attribute field to be updated. Contains the data to update this field. Edge 0 = Update completed 1 = Update failed HUP = Caller hung up

UpdateUserProfile This action is used to change the user profile. Some fields in the user profile are modifiable by the subscriber, such as password and language selection, and others cannot be modified, such as message name and number. UpdateUserProfile allows you to select the fields you want to update using parameter fields. Parameter PARM1 Field of the user profile to be updated PARM2 Name of the buffer holding the data to be updated Edge 0 = Update completed 1 = Update error

SendData This action sends data to the host application via the general purpose server.
Used to send data and/or commands. Parameter PARM1 Host application function IDP
ARM2 host application subfunction IDP
ARM3 Number of variables to be sent PARM4-N
List edge of ID of variable to be sent
0 = Transmission completed successfully 1 = Transmission error (ASI issue) HUP = Caller hung up

ReceiveData This action is used to parse data received from a host application via a general purpose server. Parameter PARM1 Host application function IDP
ARM2 host application subfunction IDP
ARM3 Timeout (seconds) PARM4 Number of variables to be received PARM5
-N List edge of ID of variable to be received
0 = Reception completed successfully 1 = Host problem 2 = No data returned T1 = Time out (no response) HUP = Caller hung up

GetFindData (Data Retrieval) This action is used to look up tables on the host system. The user is prompted for input by PlayPrompt, after which this action is called to accept the caller's input. When the specified number of keys are entered, a request is sent to the host for a list of table entries starting with this entry. After this list is returned, a search is performed within this list for a unique match. The caller can enter more keys and the search repeats until a unique match is found in the list. As soon as a unique match is found, the complete entry is placed into the buffer.

For example, Santa Cruz and Sa
For a list of city names that include nta Clara,
To obtain a unique match, the caller enters the first seven keys of these two city names. Once a unique match is found, the entire entry corresponding to that city name (Sant
In the case of a Cruz, there are 9 keys for the entire entry)
is placed in the buffer. Parameter PARM1 Host application function IDP
ARM2 ID of the host application subfunction used to retrieve the data list PARM3 ID of the variable that receives the data (GetD
(similar to ata) PARM4 Minimum length of input to accept before sending data request to host PARM5 Host timeout (seconds) waiting for response to data request Edge 0 = successful input, match found 1 = No match found 2 = Incomplete input, timed out waiting for DTMF input T1 = Timed out, no input T2 = Last repeat HUP = Caller hung up

CallStateTable This action is used to call from one state table to another. This second state table is
CloseSession action or ExitStat
Executes until the eTable procedure is called. Ca
llStateTable is used to perform a sequence of actions that span multiple state tables. For example, you can generate one state table containing a set of actions and then use CallStateTable to execute those actions from other application state tables.

[0203] The CallStateTable can also be used to implement a menu for the caller to select the application to run. In this case, each application can be described in its own state table and called from the menu's state table. Parameter PARM1 ID of the variable that holds the ID of the state table to be executed PARM2 ID of the variable that holds the release of the state table PARM3 ID of the variable that holds the edge of the state table entry Edge 0-12 = ExitStateTa
ble action returned 13=state table not found HUP=caller hung up

ExitStateTable This action is used to return from a nested state table to the state table that called it. The parameter for this action is the ID of the variable holding the edge value that the CallStateTable uses as its return edge. ExitStateTable terminates execution of the current level of a nested state table and returns it to the state table that called it. CloseSess
The ion operation terminates execution of all levels of the nested state table, closes the session, and returns the state machine to the Idle state. This ExitStateTab
If the le action is called from a non-nested state table, the CloseSession action is executed instead. Parameter PARM1 ID edge of variable holding return edge used in CallStateTable action None

Disconnect This action is used to disconnect from a calling party. Disconnect is only used for specific purposes since normal session termination occurs when the caller hangs up. This action can be followed by a CloseSession action or other actions. Parameter Unnecessary edge 0=Complete

[0206]CloseSession(Session/
Close) This action clears all buffers used by previous sessions. This is used as the last action for a session. Parameter Unnecessary edge 0 = completed 1 = impossible. This process will be deactivated.

Application Scenarios This section introduces application scenarios. Part 1 discusses the functional characteristics of application scenarios. Part 2 shows how to use these applications.

Functional Feature VPACK sends the ABCD signal bits to the voice card driver. The voice card driver converts these bits to the appropriate state based on the country-specific signal translation table and passes this state to the channel process or node manager. The out-of-band call information signal includes at least the called number. This call information arrives or
When the out condition occurs, the channel goes off hook and the session begins.

[0209] If no signaling information is available, for example if the information does not arrive within a predetermined time limit after the ringing begins, the call is answered and the default state is assumed. An example of this would be a customer trying to order supplies. The customer connects to a particular line group and then proceeds to a preliminary voice menu to select a particular VIS application to run. When a caller connects to his application, the application script presents a greeting and prompts for a password. This password is verified by querying the application database server, after which the script proceeds to a voice menu and prompts for a DTMF response.

[0210] Interaction with the host is performed by passing a fully coded DTMF response, except for the direction response, to the database server. A customer-created database server can process requests directly or
Requests and responses can also simply be passed to a remote database server. In this way, customers can choose to use existing database applications and interface protocols.

Application Examples The following sections discuss VIS applications, telephone service applications, and workstation applications as example application scenarios.

VIS Application (Bus Timetables and Fares) This scenario is an example of a voice-interactive database application. In this scenario, a consumer calls a listed phone number to receive bus timetable and fare services. Based on the identity of the called number,
The bus timetable script is loaded. In the system script response below, the words enclosed in <> are:
This is a variable generated from VAG.

“Hello, this is Glo
bal Bus Lines route and f
are system. You may back
up a step at any time by
pressing the start key on
your touch tone phone. (Hello, this is the Global Bus Route Fare System.Press the start key on your push-button telephone.
You can always go back one step. )""To
begin, please turn to pag
e THREE of your phone boo
k for the bus terminal lo
cation codes. (First, open page <3> of the telephone directory and look up the location code of the bus terminal.) "Using the touch
one keypad your telephone
ne, please enter the THRE
E-digit terminal code for
the city where your travel
l begins. (Use the pushbuttons on your telephone to enter the <3> digit terminal code for the city of departure.)" (Customer enters the 3 digit terminal code.) "You are traveling."
from BOSTON. (The starting point is <Boston>.)""Please enter the THRE
E-digit code for the location
ion where your travel will be
terminate. (Please enter the <3> digit code for your destination.)
Enter the code. ) “You will be tr.
avelling to ATLANTA. (The destination is <Atlanta>.)""Please enter
the day you wish to trav
el. One is Monday and se
ven is Sunday. (Please enter the day of the week you would like to travel. 1 is Monday and 7 is Sunday.)
(Customer enters a one-digit day of the week code.) “Yo
u will be traveling on T
UE SDAY. (I'm traveling on <Tuesday>.)""Wh
at time of the day do you
Want to leave BOSTON? P
lease enter up to four di
gits using the 24-hour cl
ock, followed by a # sign
．． (What time on that day will you depart from <Boston>? Please enter up to 4 digits in 24-hour format, followed by the # symbol.)" (Customer enters departure time.)"
Departure time from BOSTO
N is EIGHT HUNDRED hours.
Arrivaltime in ATLANTA i
s TWENTY FIFTEEN hours.
Fare is EIGHTY-FIVE dolla
rs and SIXTY-EIGHT cents. (
Departure time from <Boston> is <0><8>o'clock<00>
It's minutes. Arrival in <Atlanta> will be at <20>:00 and <15> minutes. The fare is <85> dollars <68> cents. )”“
Press the pound sign for
the next departure or the
star key to respecify yo
ur trip. If you need fur
the help, press zero the
n the # sign, and you'll
be transferred to a live
operator. (If you want to know the next departure flight, press the # symbol; if you want to change your travel preferences, press the start key; if you need more information, press 0 followed by the # symbol. (Switches to operator.)

Telephone Service Application FIG. 10 is a flow chart showing the progress of the Telephone Service Application. A customer wishes to request that their telephone service be temporarily suspended from a selection of customer settings options. Function block 70
After being welcomed by the system at 0, the customer is prompted at block 710 for a phone number and information related to the task they are requesting. At function block 720, this information is sent to the host for inspection and enforcement.

[0215] If invalid information is entered, the customer is prompted at function block 730 to re-enter the data or call a help number. If valid information is entered, at function block 740, the customer receives a message to suspend or restore telephone service.

[0216] After confirming that the customer's option is to suspend, the customer is prompted at block 750 to enter two telephone numbers and the date on which he or she wishes to suspend service. One number is the current calling number and the other number is the number that can call the customer in case of an emergency.

At block 760, this data is sent to the host for processing and storage. Thereafter, at function block 770, a message restating the customer's requirements is sent back to the customer with a request for confirmation. At this time, the customer can confirm the requirement for interruption or switch to the operator.

Workstation Applications This section describes examples of workstation applications for response and message retrieval, message retrieval, message logging, and message passing.

Answer and Retrieval of Messages In response and retrieval of messages forwarded to the VAE, the subscriber's greeting is sent to the caller, the message is logged and stored in the subscriber's mailbox, and the call is terminated. .

1 Depending on the profile, the script plays a standard greeting or a personalized greeting. In the case of personalization, this greeting must be retrieved from a database. The compressed greeting is retrieved in the form of segments, decompressed, and then consecutive segments are pipelined onto the outbound circuit.

2 After the greeting is played, the inbound circuit is opened to receive audio signals and simultaneously monitor on-hook and DTMF tones.

3 When the caller's spoken message arrives, it is compressed into segments and stored in the database. Each segment is assigned a unique identifier upon its completion.

[0223] When the 4 key is pressed, the number is
Extracted from the stream and processed against the script. This action may be ignored or performed depending on the spoken prompt.

5 If the caller hangs up or a predetermined time limit is reached, the script calls the ASI
to disconnect the telephone circuit. The last message segment is stored and the required indicators stored in the database are updated to reflect the addition of the message to the subscriber's mailbox.

6 If this subscriber's class of service indicates that notification is required for the arrival of this message, the ASI sends a control message requesting the application in the host to schedule a notification. send.

Retrieving Messages In the message retrieval application, a subscriber calls a service number to gain access to a mailbox service. The most commonly used service is retrieving messages from mailboxes.

1. An incoming call is received at the ASI along with the called number identifying the service. The appropriate script is selected and activated.

2 This script plays a prompt to the subscriber requesting a keyed-in identification and password.

[0229]3 The DTMF decoding function within the ASI extracts the digits, which the control function uses to ensure that the correct steps are followed and the relevant information is gathered. Correction prompts are played when necessary and on-hook tones are monitored.

4 When sufficient information has been gathered, the assumed profile is accessed from the database and the password is verified. During the check, a prompt is played giving options for the available services. The subscriber then selects mailbox search.

5 ASI requests messages from the database and creates a prompt giving the number of messages. This prompt is played to the subscriber along with the service options.

6 The subscriber's keyed response causes this message to be retrieved from the database. Subscribers can choose from two different options. The longer version allows you to listen to the entire message, and the shorter version lets you scan your mailbox for the message you want to hear. The flow of each option is as follows. - Play long version message header Play message Delete this message Go to next message - Play short version up to 4 message headers Select the message number of the message you want to hear or forward Skip to next four message headers

7. Retrieve, restore, and play message information in the form of segments. This search is scheduled well ahead of the playback speed so that the audio being played is not interrupted. During playback, the subscriber is given a wide range of functions for review and spacing, invoked by keys.

8. Processing prompts are provided after each message is played. Choices include delete, save and forward. A wide range of prompts are available for each option.

[0235] After retrieving a message, the subscriber can proceed to other options on the main menu by key-controlled direction. If this is done or a connection break occurs, the search transaction ends. The message database has been updated with relevant metrics and subscriber information.
Changed to reflect the action taken.

Record Message The record message transaction allows a subscriber to record a message to be placed in another subscriber's mailbox. Subscribers gain access to this service by calling the service access number.

1. Called number activates script. The subscriber logs on and uses the keypad to select the recording function from the spoken menu.

2 The steps used to receive, compress and store messages are the same as those used for forwarded calls. Review and editing functions can be invoked using the keypad. This action can be aborted at any time by keystroke selection or by disconnecting the line.

3 When the end of the message is reached, a prompt for the destination is played. This is keyed in as a single goal or a list of goals. The destination may be an explicit phone number or an alias that references a predetermined directory. Aliases are always used in lists. ASI
creates the required message metrics entry and
Allows the mail database to receive server updates.

4 This transaction is also terminated by proceeding to another menu option using the keypad or by the subscriber going on hook.

Message Delivery [0241] When a subscriber accesses a VAE in direct access mode, he or she can log messages. then,
The subscriber must specify when to send the message and to whom the message should be sent.

[0242] There are two types of VAE: immediate type and scheduled type.
There are different types of message passing. The default option for the immediate delivery type is that the message is delivered to the recipient's mailbox as soon as it is sent. For scheduled delivery types, the VAE provides an option to specify the date (time, day, month) to send the message. VAE allows two recipient types. The first type is a subscriber identified by user ID (phone number) or name. The second type is a distribution list containing a list of subscribers.

[0243] In the VAE system, message delivery to non-subscribers is possible. The system dynamically generates dummy user profiles and mailboxes to
Able to memorize information. The VAE can then pass this message on to the recipient using outcall capabilities that will be implemented in a future release. After message delivery, the VAE deletes the dummy information. This feature will be implemented in a future release.

Session Manager Design Session
The manager design includes the following features: - Channel process - Internal state machine including its own internal actions - Application actions - Japanese language support for PlayPrompt actions

[0245] This section provides design specifications for these functions. At system startup, the node manager FORK() (spawns a child process) a single channel process.
and EXEC() (execute child process). This first channel process functions as a session manager.

[0246] The session manager performs all of the initialization steps common to all channel processes;
These channel processes are then executed for the entire ASI system and then returned to the channel processes.

The purpose of the session manager is to reduce system startup time and provide a simple means to share code space among all channel processes. This is done by executing all of the initialization code that is common to all channel processes and then using the FORK( ) function to spawn the required number of processes.

Application Handling This section describes the session manager's application handling. These are as follows.・PlayPrompt ・GetKey ・GetData ・RecordVoice ・PlayVoice ・CheckStorage ・Disconnect ・CloseSession

ACTION_PLAY_PROMPT Routine This action creates and plays audio prompts defined in the prompt directory. The prompt is
It consists of the following items.・The user performs the following GETDATA action or GETKEY
Specify the time, in seconds, for an action to respond to a prompt,
Timeout - Number of times a prompt can be repeated before a GETDATA or GETKEY action returns a timeout - Segment I
D. List of system variables and conditional tests. Conditional tests allow you to control which segments and variables are played for a particular prompt based on runtime conditions.

Internal State Table The internal state table of the state machine is IDLE, ANSWE.
RCALL, PLACECALL and ENDCALL
Provide the state machine with ground rules for performing actions. This table is the basis of the state machine. All customer-defined state tables are ANSWERCALL and PL
Invoked by the ACECALL action. FIG. 11 shows the internal state table.

System Parameters The system parameters for the channel process are as follows. - Number of channels and processes running - Internal state table - Process control block - Blocking number of 4K buffer for audio input/output -
Number of timeout seconds before reaching time limit Voice message recording stop key DTMF key leading edge Number of records to be truncated at the end of recording

Error Recovery All errors are logged and/or notified to the node manager. The requested UP is not available and the SMS
Requests UP for information other than I cannot also be obtained. For a variety of miscellaneous errors, a state table could be defined to handle most error conditions, providing flexibility without the need for code changes.

National Language Support for PlayPrompt Actions A National Language Support (NLS) setup is a set of rules and programs that reproduce compound variables in a manner consistent with local customs. This means that compound variables can be reproduced in several different ways. Therefore, multiple languages and different language syntax are supported.

[0254] The format of data input and output depends on local customs. Such data includes number systems, currency,
Includes date format, time format and phone number format. NLS uses a table-driven design. This eliminates the need to write new programs for each new language or language construct that the system supports.

Using this approach, the code becomes language or syntax independent and only new tables are required. Below is an example of a compound variable.・Numbers・Ordinal numbers (first, second, etc.)・Date・Time・Currency・Telephone number

Method for Reproducing Composite Variables FIG. 12 shows a method for reproducing composite variables. Below are examples of different language syntax. In the case of numbers, 20 is <
20> or <2><10>. For dates, 6/6/90 is <6><19><90>, <Jun
e><90>, <6><June><1990>, <t
he><6th><of><June><19><90
>, <sound of the year><number of years in that year> or <ye
It is expressed as ar><6><month><6><day>. For time, in 12-hour clock or 24-hour clock currency, $5.25 is: <5><dollars><25><cents
＞・ <5><dollars><and><25>
<cents> ・ <5><yen><25><fen> For the phone number, 9861234 is: ・ <9><8><6><pause><1><2><3>
<4> ・ <98><61><234>

Dependencies on the NLS Rule Language syntax are based on a set of NLS rules. NLS rules are generated by the System Administrator Facility (SAF) and loaded into SYSPARM (System Parameters) by the Node Manager. NLS routines use these rules to
Decompose a compound variable into pieces that reproduce appropriate speech segments.

[0258] The general form of an NLS rule is <rule metacharacter>
<modifier><optional phonetic segment>. ．． ．． This is a character array. <Optional phonetic segment> may be used anywhere in the specified array except between a metacharacter and its modifier. Multiple <optional phonetic segments> can be used in sequence.

[0259] NLS rules are stored in SYSPARM and loaded by the node manager. One set is used for each language. FIG. 13 is a table showing NLS parameter numbers corresponding to the following rules.

[0260] Characters and modifiers of NLS rules: Date,
A basic element used in defining time, currency, or phone number formats. All general forms of NLS specifications are <rule metacharacter><modifier><phonetic segment ID>
．． ．． ．． It is. / - metacharacter 9 of the word representing the number of digits - <bi representing the value 1000,000,000
llion> 8 - 7 or 1 if there is a word representing 100,000,000 - Only if there is a word representing that value d - Day 1 - Play as PP_VARID_NUMBERS 2 - Play as PP_VARID_ORDINAL 3 - PP_VARID_DAYSOFMONT
Play as H - Month 1 - Play as PP_VARID_NUMBERS 2 - Play as PP_VARID_ORDINAL 3 - PP_VARID_MONTHNAMES
Play as y - Year 1 - Play as a single number 2 - Play in two-digit increments 3 - Play only the last two digits 4 - Use the year w - Day of the week, modifier is the same as d v<ULONG Segment Id > −
Play the segment with Segment Id h - Hour 1 - 24-hour system value 2 - 12-hour system (AM/PM) value M -
Minutes 1 - Play as PP_VARID_NUMBERS (numbers) 2 - Play as PP_VARID_ORDINAL (ordinal numbers) s - Seconds 1 - Play as PP_VARID_NUMBERS (numbers) 2 - Play as PP_VARID_ORDINAL (ordinals) Be sure to add the modifier '0' to the following metacharacters. wear. $ - Base currency (dollars) c - Subordinate currency (cents) D - Play phone number digit by digitg - Play phone number as a set of numbers

0
261 Variable Mapping Table As mentioned above, variables such as numbers, dates, telephone numbers, etc. are considered complex variables. These variables are broken down into smaller pieces based on the corresponding vocalization rules for playing as prompts. This processing is done using the PlayPrompt procedure. A variable mapping table is used to identify these primitive fragments.

All primitive variables are located using two keys: var_id and var_num. var_id is PP_VARID_NUMBE
RS, PP_VARID_MONTHNAMES, etc.
Define primary data types. var_num is usually
It is the value counted within that type. For example, January
The value of var_num of ary (January) is 1.

In order to apply this rule to all 256 possible languages, for each supported language, N
An LS variable mapping table is defined in the host's database. This table is organized with the following three columns.・Var_id PP_VARID_MON
THNAMES etc. (short) ・ Var_num January etc., sho
Count using rt type/segid phonetic segment ID

0264
]This table shows the prompts and prompts for the current language used.
As part of loading the directory, the channel
loaded by the process. All supported variable types are listed below. VARID Item content PP_
VARID_NUMBERS 1 to 20
, 30, 40, 50, 60, 70, 80,
90PP_VARI
D_HTMB hund. (100)th
ou. (1,000) mill. (million)bi
ll. (billion) PP_V
ARID_MONTHNAMES Jan. (January) Feb. (February) Mar. (March). ．． ．． PP_VA
RID_DAYSOFWEEK Sun. (Sunday)
Mon. (Monday) Tue. (Tuesday) Wed.
(Wednesday) Thu.
(Thursday) Fri. (Friday) Sat. (Saturday) PP_VARID_DAYSOFMONTH 1st
(1st), 2nd (2nd), 3rd (3rd), 4
th (4th)
、． ．． ．． 31st (31st) PP_VARID_TIM
EOFDAY am (morning), pm (afternoon), o
'clock (hour),
hours PP_VARID_
TIMEOFWEEK yesterday, today, t
omorrow (tomorrow) PP_V
ARID_ALPHABET A, B, C, D
、． ．． ．． PP_VARID_NOISF
Noise type PP_VARID_SYS_MSGS
Audio PP_V for system error messages
ARID_ORDINAL Ordinal number

0265
] NLS Design Assumptions and Limitations The characteristics of current NLS designs are listed below.・Numbers (American English example) ・The base is 10 (not 24 = 2 dozen as in base 12) ・Only valid entries in NUMSPEC are allowed (not 10) ・The primitive numbers are: Completed within the VARMAP table (0, 1,...19, 20, 30,..., 90, etc.) ・Date/time input is in UNIX format ・Currency input is a floating point number ・Telephone number must be a numeric value・VARMAP played as
Table - Expected by SAF to be complete - In American English there is no redundancy such as 10 in NUMSPEC, compared to <1000><million> in British English.
・The NLS rule table must not contain errors. ・There is no ordinal unit corresponding to <millionth> and <billionth>. VARMAP is <hundred
th> (100th) and <thousandth> (1000th)

[0266] There are two operations for decomposing numerical values so that they can be used as segments: division and subtraction. VAG is a channel
Generate numbers that allow the process to perform these actions. The format of the numbers assumes a base of 10 and the most significant digit on the left. The numerical value range is from 0 to 4294967295 (ULONG size), and there are a maximum of 10 significant digits. This internal data structure (
charnumspec(60);) is invisible to VAG users.

The basic elements used in defining the format of numbers are: / - word metacharacter representing the number of digits 9 representing <billion> 6 representing <million> 3 representing <million> 2 representing <thousand> v representing <hundred> - Example of a generated numspec followed by a 4-byte phonetic segment ID (1) American English/9v<billion>/6v<million>/
3v<thousand>/2v<hundred>(
2) British English/6v<million>/3v<thousand>
/2v<hundred>

[0268] This number system is
It can be applied to both cardinal and ordinal number systems. The only difference between these two systems is the use of var_id to indicate the location of a speech segment. There are two sets of structures: one for the radix system and one for the ordinal system.

Date Format The order of year, month, and day is given in this structure along with their audio segment IDs. The date specification is as follows. - datefmt Specifies the playback order of year, month, and day. When using the year, SYSPARM'nation
al_year' holds the Western calendar year of the first year. d - Day 1 - Play as PP_VARID_NUMBERS 2 - Play as PP_VARID_ORDINAL 3 - PP_VARID_DAYSOFMONT
Play as H - Month 1 - Play as PP_VARID_NUMBERS 2 - Play as PP_VARID_ORDINAL 3 - PP_VARID_MONTHNAMES
Play as y - Year 1 - Play as a single number 2 - 2
Play by separating each digit 3 - Play only the last two digits 4 - Use the year w - Day of the week The modifier is the same as d: v<ULONG
Segment Id> - Segment
t Play segment with Id

[0270] An example of how the date 6/6/90 is played is shown below. Specified playback sound m3
d2y2 <June
＞<6th><19><90>m3d2y3
<June><6th><90
>d2m3y1 <6
th><June><1990><the>d2<of
>m3y2 <the><6th><of
><June><19><90><nsv>y4<ye
ar>m1<month>d1<day> is <year>
<Number of years><year><6><month><6><d
ay>.

Time format The playback order in time units and its audio segment ID are given in this structure. Time specification char timefmt(2
0); specifies the order in which time elements are played
- Hour 1 - Number 2 for 24-hour system - Number M for 12-hour system (AM/PM) -
Minutes 1 - Play as PP_VARID_NUMBERS 2 - Play as PP_VARID_ORDINAL s - Seconds 1 - Play as PP_VARID_NUMBERS 2 - Play as PP_VARID_ORDINAL v - Need to insert audio between hours, minutes, and seconds If so, the following 4 bytes hold the ID of the audio segment.

[0272] An example of how the time 11:30:24 is played is shown below. Specified playback sound h1
M1<and>s1<second><11><
30><and><24><second>h2M1
<11><30>
<am>

Currency Specification Two currency units are available. This value is played as a number with audio segments of the currency units that make up the currency. Currency specification char moneyfmt (20); /* How to play dollars/cents */short dollar
r2cent; /* Conversion rate */- mone
yfmt This field defines the playback order of amounts and the voice of the currency unit $ Plays the dollar part 0 No modifier, always plays as a number c Plays the cent part 0 No modifier, always plays as a number v Insert audio in between. Followed by a 4-byte segment ID - dollar2cent Dollar to cent conversion rate. In America, 1 US$=100 cents, so this value is 100. This is SYSPARM

0
[274] Below is an example of how the amount $5.25 is played. Specified playback sound $<dollars>c<cents>
<5><dollars><25><cents
>$<dollars><and>c<cents>
<5><dollars><and><25><c
ents>$<yen>c<fen>
<5><yen><25><fen>Call sequence: short play_curren
A VAG that returns true if cy (float money) playback is successful provides all information except the audio segment ID that corresponds to dollars and cents. These two IDs are initialized by the channel processor.

[0275] A method for grouping designated telephone numbers for playback is provided in this structure. Within the group, phone numbers are played as numbers. char phonespec(20) = ”D0D
0D0 D0D0D0D0D0D0D0”;Call sequence short play_phone_numb
er (char *phone) - Used to specify rules for converting phone numbers into voices - phonespec
: D, g or vD - played as a single digit, followed by an additional D corresponding to 0 or additional digits; no modifier g - played all together, followed by an additional D corresponding to 0 or additional digits; 0 followed by g No modifier v - Insert audio during playback, must be followed by a 4-byte audio segment ID'' - Specified if given a phone number 4085546888 to be used as a separator
Playback sound D0D0
D0 D0D0D0 D0D0D0D0 <4><
0><8><5><5><4><6><8><8><8
>g0g0g0 g0g0g0 g0g0g0g0
<408><554><6888>

State Table Manager Design The purpose of the state table manager is to provide a state table to the session manager program for controlling the progress of a call. The state table manager receives messages from the request queue, sends a DPRB to the database interface manager to request a state table, receives notification that the state table has arrived, and notifies the requestor. Designed to inform. The program is designed to handle multiple requests simultaneously and is configured to handle invalid requests and unsearchable tables.

The state table manager program also responds to requests from the node manager to free 4K buffers and requests to invalidate state tables. This section explains the following:・ Performance considerations ・ Resources ・ Interfaces for state table requesters ・
Pseudocode that defines the design of the state table manager

State table manager and prompt
Directory managers share a common table structure and control table design. FIG. 14 is a block diagram showing the flow of data, including interfaces with other processes and control tables.

Designing Common Routines Because the structure of the control table is identical (with the exception of the entry control structure), much of the functionality required by both the state table manager and the prompt directory manager is provided by both managers. integrated into routines called from

The control table consists of a block of memory large enough to contain enough entries to accommodate a number of tables in memory at the same time, as determined at runtime. Memory for this table is allocated from the AIX memory pool during system initialization so that the table is contiguous memory. Use semaphore operations to prevent multiple processes from updating control tables at the same time.

[0281] Design specification of VAG components This section includes
Contains detailed design specifications for G internal components. Figure 2
These components and their design specifications include:
Includes:・ VAG performance considerations ・ VAG resources ・ VAG server interface specifications ・ VA
Using Motif and X Windows in G - VAG global data structures - VAG-specific global variables - Front end design - Prompt generator design - State generator design - Speech generator design - Application manager Design/VAG
System specifications/utilities

[0282] The performance of the VAG components is governed by the call processing capabilities of the system. Therefore, VAG components must operate at a lower priority than call processing tasks, limiting contention for system resources with the rest of the VAE system. VAG components are expected to operate during normal loads without degrading system performance.

[0283] VAG resources The total available RAM memory and CPU processing power are
Affects component performance. Most of the memory required is
Allocated for Motif and X Windows code and data structures. Motif and X Windows are both window interface managers for AIX. Future versions of these products are expected to provide shared libraries to reduce the memory requirements of each task.

[0284] Both Motif and X Window:
Make extensive use of allocated storage. Because of the design decision to transfer complete files to VAG components instead of accessing individual records, and because of Motif's scrollable list functionality, large amounts of memory are allocated dynamically by applications. The amount of memory allocated depends on the actual size of the database file being edited.

[0285] VAG programs are not expected to be locked like call processing tasks, but instead are
Operates as a standard demand paging virtual memory process. This places less demand on the system's RAM memory needed to run the VAG components. VAG components must free up resources shared with call processing, such as 4K buffer blocks, as quickly as possible.

[0286] Graphical displays are CPU intensive because the X Windows low-level graphics functions perform floating point calculations. Therefore, the floating point processing performance of the target platform has a significant impact on display speed.

Front End Design The purpose of the front end design is to enable or disable security access levels based on the user's ID and password. The front end design allows V
It is possible for the user to select only the password pop-up box from the AE's top level default screen.

[0288] The user enters his/her user ID and password in the password pop-up box to access the AP.
When PLY is selected, the front end design allows the user to access only the menus assigned to him within his administrator profile. The password is not displayed when the user enters it. Enabling or disabling security access levels is controlled by setting the sensitivity of particular menu buttons. This sensitivity also determines whether a keystroke or mouse action can invoke the function associated with that button.

Designing the Prompt Generator The purpose of the prompt generator is to allow system users to create, update, and delete prompts that are executed by channel processes. The prompt generator uses Motif to provide graphics to the user to accomplish these tasks. The prompt generator generates, updates, and deletes prompts through the DPRB interface with the database interface manager.

[0290] The prompt generator functions at three levels. The first level involves creating and updating prompt directories. Each prompt directory consists of a prompt directory parameter and a list of prompts. The second level involves the creation, updating, and deletion of individual prompts within a selected prompt directory. Each prompt consists of prompt parameters and a prompt body. The third level involves creating, updating, and deleting phonetic segment references, prompt variables, and conditional decisions that define the prompt body of a selected prompt.

Editing a Speech Segment To edit a speech segment, use function block 800 of FIG.
, the user selects the text editor panel of the audio editor. At function block 810, the user selects “vo”.
After selecting "Speech", the user is presented with a list of speech segments retrieved by the database function. At function block 810, the user locates the segment in question using search or scrolling, and then clicks the mouse to locate the segment in question. , click on the segment in question and, at function block 830, click on the selection area on the same panel.
Mod Voice”.

The audio application enabler performs the following steps in preparation for editing. a. Present the audio editor panel; b. Request to allocate two audio channels on the audio hardware; c. Place these channels in loopback mode. One is for decompression and the other is in "clear channel" (ie, uncompressed) mode. d Locate the compressed audio segment and write it to the audio channel in decompression mode and read from the wrapped channel in clear channel mode. Both compressed and decompressed speech segments are stored in memory (RA
M). e Display the waveform of the decompressed audio segment in the audio editor panel as it is received from the decompression process. f The number of seconds required to play the audio segment is calculated from its physical length and displayed on the editor panel.

At function block 850 of FIG. 16, the user uses the mouse to select "Set" (
Set) Select the treatment. Functional blocks 860 and 8
At 70, again using the mouse, the beginning and end points of the portion of the digitized speech segment to be modified are marked as highlighted. The physical locations of compressed and uncompressed speech segments are calculated and the marked parts are highlighted. These positions are always rounded to the nearest 20 ms boundary. The boundaries are 32 bytes and 160 bytes, respectively, in the current implementation. Thereafter, at blocks 880 and 890, the user can unmark the marked area, and at function blocks 900 and 910, the user can save the results.

[0294] Alternatively, the user can play the marked portion by selecting "Play" on the action bar of the editor panel. In this case, the audio is written to an audio hardware channel in clear channel mode and transferred from there to headphones or speakers. By playing the audio information, the user can verify that the correct part of the segment has been selected.

[0295] A marked part can be copied to another segment or deleted by selecting the appropriate action using the mouse. If you delete a marked part, the audio editor rewrites the internal buffers of the compressed and uncompressed audio segments, changes the length of the time axis to fit the panel, and rewrites the digitized waveform. Rewrite the panel.

[0296] If the user wishes to copy all or part of a speech segment to another segment, mark the first segment, switch to "Other Window" and copy the copied part. Insert at the marked position in the second segment. The segment is then rewritten to the appropriate buffer and the waveform panel is regenerated from the uncompressed data.

[0297] When the user completes editing the audio segment, the user:
Select "Save" from the action bar. This action saves the edited segment by writing it to a file, replacing the original segment. Editing is thus performed without successively decompressing and recompressing the stored audio data, and without consequentially continuously distorting the audio.

Playing a Voice Prompt Preparing a Prompt To prepare a voice prompt, in function block 1000 of FIG. Start the generation program (VAG). “States”, “Prompts” (
The user is presented with a pull-down menu containing three options: "Prompt" and "Voices." Next, at function block 1010, the user positions the cursor on "Prompts" and presses the mouse button to signal the selection of the function used to define the prompts desired for the voice application.

[0299] The user is presented with a prompt directory editor panel. The Prompt Directory Editor panel displays a list of all currently defined prompt directory entries. By selecting "Options," the user can choose to view or work with alternative versions of the prompt. This alternative version may be defined in other languages. Thereafter, at function block 1020, the user selects "Add" from the prompt editor panel. An input subpanel appears on the right side of the editor panel.

At function block 1030, the user clicks "Apply" after entering the prompt ID number and purpose on the input subpanel. The user is then presented with a list of available phonetic segments, an expanded prompt list to the right of that list, and a selection of the relational operators described above. At function block 1040, the user selects a speech segment or variable and optionally a condition test. Conditional tests allow you to conditionally play a referenced segment depending on the value of data contained in a defined variable (for example, the date or time of the day, or a value entered by the caller). Become. Complex logic IF. ．． THE
N. ．． ELSE statements are also supported.

[0301] If the selected segment is a variable, the method for vocalizing the data stored in that variable (i.e., PLA
YAS. ．． ) is presented. At function block 1050, the user selects how to vocalize the variable (eg, single digit, number, ordinal, currency, date, time, etc.). Variables used as prompt segments are stored as a combination of a pointer to the variable data and a code that defines how to play that data.

[0302] At function block 1060, the user can continue the process described above and string together prompt segments until this prompt is complete. Thereafter, at function blocks 1065 and 1075, the user
Click VE (Save) to save the prompt for use in your application.

Playing a Prompt with Complex Variables At function block 1080 of FIG. 18, an incoming call to the system invokes an application script. At function block 1090, the script references prompts defined during application development. Function block 1095 calls “PLAY” in this script.
When you perform the "Play Prompt" action, the VAE Session Manager traverses the list of segments defined by that prompt. Each type of segment (i.e., static voice or variable) is
By passing control to a function defined for the "ay As" type, playback is performed according to the "PLAY AS" specification. A flowchart of this process is shown in FIG.

The actual vocalization is performed using system-level segmentation primitives (eg, “hundr
ed”, “p. m. For example, currency and time are vocalized according to national conventions. These primitives are actually
The selection is made by parsing the values of the variables according to these rules. When one prompt completes, control passes to the next script action.

Language-independent voice application To define a new application in another language, see Figure 19.
At function block 1200, the system administrator selects NLS Editor from the main menu. An editor panel is presented with a list of currently defined languages. English is the base (default) language.

At function block 1220, the user selects “O
ptions - New Languages
” (Options - New Language), enter the name of the new language you are defining at block 1230, and click “OK.” The system then:
Copy English-based language files to a hidden database. Next, select “Keybo” on the NLS editor panel.
ards” (keyboard), the system remaps the display keyboard. A list of available keyboard mappings is displayed in the keyboard selection panel.
This list can be narrowed down by selecting ``er'' (filter) and a two-digit code specifying the language of the keyboard in question (eg, French).

[0307] The user then edits language-based file groups that affect the user (display) interface, as shown in function blocks 1255-1300. These file groups include: (a) Application developer standard interface terminology (b) Common VAE user interface terminology (c)
VAG Editor (d) Administrator Profile (e) Mailbox Terminology (f) User Profile

Next, the user edits the language configuration parameters (NLS rules) in the system configuration panel, as shown in function blocks 1310-1320. This parameter includes: (a) Variable mapping table (b) Number format (c) Phone number format (d) Currency format (e) Date format

To develop an application after the application development (VAG) language adjustment is complete, at function block 1335 of FIG. 20, the user selects "VAG" from the VAE sign-on panel. Thereafter, at function block 1345, the user selects one of the following three voice application development tools from the pull-down menu. (1) "State Generator" for defining application scripts; (2) "Prompt Generator" for defining prompts called by scripts; and (3) recording, playing, and editing audio segments used for prompts. "Speech generation program" for

At function block 1355, the user selects “Options” for the selected tool from the application development tools menu.
” (option), then function block 13
65, select “Language” in the pull-down menu.
” (language).The user then selects the drop-down
Select a language from the list of predefined languages in the menu. The language selected here will be used during this development session. At function block 1375, a user may develop an application including scripts, prompt definitions, and audio prompt segments using the user's selected language.

[0311] The NLS execution script is prepared using the VAG described above and invoked using the appropriate signal (ie, DID, SMSI, dedicated channel, etc.) interface. This script is executed using NLS prompt vocalization rules. This rule is table-driven and is defined in the System Configuration section above. There is one set of rules for each language. The set of rules used corresponds to the language that is active at the time the script is executed.

[0312] As explained in detail above, the general form of the NLS is: <rule metacharacter><modifier><optional phonetic segment>
．． ．． ．． It is. Conventional metacharacters and modifiers include (there are metacharacters for year, time, and currency):

[0313] Composite variables such as those described above can therefore be divided into smaller "primitives" according to NLS rules.
broken down into fragments and played back as individual words or phrases. These primitives are identified according to the variable mapping table. For example, variable ID variable value segment ID MONTHNAME 1
Pointer pointing to “January”

A flow diagram of the NLS execution logic is shown in FIG. At function block 1400, an incoming call is detected. This detection causes function block 1410 to call an appropriate script that generates audio prompt playback. To run this script, prompt definitions and NLS rules must be retrieved in function blocks 1420 and 1425. Functional blocks 1435 and 1440
And with this information, the prompt generator will:
The PLAY-AS specification can be decoded and the composite audio information can be decoded into primitives that can be played back to the caller.

Although the present invention has been described with respect to a preferred embodiment in a particular system environment, it may be modified to be used with other different hardware without departing from the spirit and scope of the claimed invention. Those skilled in the art will appreciate that the invention can be practiced within a software environment.

[Brief explanation of the drawing]

FIG. 1 is a system diagram of a voice application enabler device according to the present invention.

FIG. 2 is a system diagram of internal components of a voice application generation program according to the present invention.

FIG. 3 is a system diagram of internal components of a voice application enabler according to the present invention.

FIG. 4 is a block diagram of a state table according to the invention.

FIG. 5 is a block diagram of a database file according to the present invention.

FIG. 6 is a system diagram of a general-purpose server development process according to the present invention.

FIG. 7 shows a display screen of a prompt segment editor according to the present invention.

FIG. 8 illustrates a prompt editor panel according to the present invention.

FIG. 9 illustrates a state editor panel according to the present invention.

FIG. 10 is a block diagram of a telephone service application according to the present invention.

FIG. 11 is a diagram illustrating an internal state table according to the present invention.

FIG. 12 is a block diagram illustrating a method for regenerating a composite variable according to the present invention.

FIG. 13 is a block diagram of a national language support parameter number according to the present invention.

FIG. 14 is a block diagram of a state table manager in accordance with the present invention.

FIG. 15 is a flowchart of playback variables according to the present invention.

FIG. 16 is a flowchart of audio segment editing according to the present invention.

FIG. 17 is a flowchart of Japanese language support setup according to the present invention.

FIG. 18 is a flowchart of Japanese language support application development according to the present invention.

FIG. 19 is a flowchart of execution of Japanese language support according to the present invention.

FIG. 20 is a flowchart of preparation for complex variable regeneration according to the present invention.

FIG. 21 is a flowchart of complex variable regeneration according to the present invention.

[Explanation of symbols]

10 RISC System/6000 50 Database 60 AIX Windows 70 Voice Application Enabler (VAE)
80 Voice application generation program (VAG
) 90 Front End ASI 200 Application Server Interface (ASI) 205 Simple Message Service Interface (SMSI) 210 Host 220 Operations, Management, and Maintenance (OAM) Functions 230
System Administrator Facility (SAF) 240
User Administration Facility (UAF) 250 Voice Application Generator (VAG) 260 Voice Card Set 270 Audio Driver 280 Signal Driver 300 Cache Manager 310 Node Manager 320 State Table Manager 330 Prompt Directory Manager 340
database interface manager 50
0 List of variables 510 List of phonetic segments

Claims (7)

[Claims] Claim 1: (a) means for storing static audio information;
b) means for storing dynamic audio information; (c) means for storing vocalization rules for the audio information; and (d) a language for converting the static audio information and the dynamic audio information into another language. (e) means for dynamically assembling and vocalizing static audio information and dynamic audio information using the audio information conversion rules and vocalization rules; Audio-related application execution device. 2. The apparatus of claim 1, further comprising means for executing audio-related applications without decompressing the audio information. 3. The apparatus of claim 1, further comprising means for copying audio information into a new audio prompt. 4. The apparatus of claim 1, further comprising means for marking a portion of the audio information for later editing operations. 5. The apparatus of claim 1, further comprising means for reproducing selected portions of the audio information. 6. The apparatus of claim 1, further comprising means for storing audio information on a persistent medium. 7. (a) storing static audio information; (b) storing dynamic audio information; (c) storing a vocalization rule for audio information; and (d) storing static audio information. (e) defining language-dependent rules for converting digital audio information and dynamic audio information into another language;
A method for executing a voice-related application, the method comprising the steps of dynamically assembling static voice information and dynamic voice information and converting them into voice.