Interpreter Program for Providing Commands to a Computer Application Program

U.S. patent application Ser. No. 786,913 for Hardware Resource Management, filed Oct. 11, 1985 and assigned to the same assignee as the present application is hereby incorporated by reference.

The present invention relates to the provision of extra functions for programming applications independent of the applications.

When functions were added to computer programming applications, extensive reprogramming of the applications was required to accommodate the functions. Some functions, such as musical tone generation were provided in the form of a subroutine, which could be called during the execution of a program written in a high level language. Adding these functions to a program already in existence required modification to the program to add a call to the subroutine. Most users are not capable of this reprogramming effort. In fact, many existing license agreements under which users are permitted to use the program do not let the user look at the actual programming. In these causes, implementation of the added function may be be possible, and is likely impossible by the average user.

One such function available today involves the use of voice with mail and calendar applications. This has been done by specific application programs for the specific voice to mail or voice to calendar function.

An interpreter program is provided which enables a user of a computer to add additional function to existing programming applications independent of the applications. The interpreter supervises the interaction between an operating system and the application program whereby the application program's operation can be modified to use an advanced function in the operating system. A profile for the interpreter allows the interpreter to be adapted to individual applications programs. Commands and their associated parameters in the profile are initialized into the interpreter program. The interpreter program then supervises the execution of the commands by the operating system or the application program whereby the application program operates as if it has an advanced function provided by the operating system.

For example, the interpreter program supervises the interaction between an advanced function, such as voice synthesis, and an application, such as an office calendar and mail system. The user defines the part of the application on which to apply the voice synthesis in a high level computer language. This definition can include transformation of touch tone pulses to commands for the application which would generally be entered by keyboard. The definition then applies the function as directed by the user entered touch tones to read the mail, or read the calendar, either by means of speaker coupled to the computer or over telephone lines to a remote user.

The high level language which is interpreted by the interpreter comprises commands such as Answer, for answering a telephone coupled to the computer. A Say command causes the voice synthesizer to speak what follows the Say command in delimiters (quotes). A Key command is used to enter keystrokes and to select and provide commands to the particular application. An Input variable is used to contain values of the touch tones received from a remote user.

With the above selected commands from the high level language, the use is able to write a program to interface between a telephone at a remote location and an application to be run on a computer. The user can receive voice communications from the computer independent of the application. Use of the voice function is extremely versatile and not limited by the applications chosen. The ability to provide unlimited commands to the application overcomes the limits imposed by prior systems which were hard coded or written into the application resulting in use of the function in a limited manner.

In the preferred embodiment, the language allows a user to indicate keystrokes needed to obtain a particular screen of an application and then initiate such key strokes by touch tone. A user preprograms several different series of keystrokes to perform different tasks in different applications, the particular task being chosen by predetermined touch tone. A speech synthesizer is then used to read a portion of the particular screen of the application identified by the keystrokes. The portion to be read is also identified by the high level language. Different portions can be read in response to preprogrammed touch tones.

In further preferred embodiments, other functions, such as voice command input, touch screen input, voice playback, etc., are provided merely by adding commands to the high level language representative of the functions. Since the high level language is executed on top of the applications to which such functions are designed to apply, the further functions are also independent of the applications.

FIG. 1 is a simplified functional block diagram of the signal processing system attached to a host processor using the present invention.

FIG. 2 is a block diagram of the hardware resources of the signal processing system.

FIG. 3 is a functional block diagram of the overall system using the present invention.

FIG. 4 is a simplified block diagram demonstrating the flow of commands from an application program across the application programming interface through the host processing system to the signal processing system.

FIG. 5 is a simplified block diagram indicating command and parameter flow between the interpreter program, the profile for the interpreter and the interfaces for the application program and the operating subsystem program.

FIG. 6 is a high level flow diagram of the interpreter program.

FIG. 7 is a flow diagram of the parse profile portion of the interpreter program of FIG. 6.

FIG. 8 is a flow diagram of the initialization portion of the interpreter program of FIG. 6.

FIG. 9 is a flow diagram of the supervise execution portion of the interpreter program of FIG. 6.

FIG. 10 is a flow diagram of the close down portion of the interpreter program of FIG. 6.

To understand the present invention in detail, it is first necessary to review the voice operating subsystem described as the signal processing system in a related application Ser. No. 786,913, filed Oct. 11, 1985 and entitled Hardware Resource Management. A reader wishing to skip this portion of the description and move directly to the functioning of the interpreter program should skip to the description starting with FIG. 5.

A simplified functional block diagram of the signal processing system 50 is shown in FIG. 1. Signal processor 88 may be any commercially available signal processor such as the Texas Instruments TMS32010. Signal processor 88 is totally controlled by host processor 89, such as a IBM Personal Computer (hereinafter PC), and must have its central processing unit (CPU) instructions loaded before operation. Signal processor 88 uses instruction memory 21 as well as data memory 87. Both of these memories are accessible by host processor 89 although not at the same time as signal processor 88. Instructional memory 21 is accessible by host processor 89 only when signal processor 88 is turned off, i.e., reset. At that time, host processor 89 can load from instruction memory 21 and then switch to data memory 87 which is shared at all times dynamically with signal processor 88. Both signal processor 88 and host processor 89 have the capability to interrupt one another with interrupt masking under control of host processor 89.

The resources available to the signal processing system are shown in FIG. 2, Partitions 12, 13, and 14 are contained within instruction memory 21 (see FIG. 3). Partition 14 is loaded when the processing system is initialized and provides functions to manage the resources of the signal processing system. Partition 12 may contain either the telephony or line monitoring function sets. The telephony function set provides the capability to dial phone multiplexed through ports 15 and 17 which are in turn multiplexed to a single pair of A/D and D/A convertors. The A/D and D/A conversion does not form a part of this invention and will not be discussed further hereinafter. Ports 15 and 17 can be accessed by either partition 12 or 13. Additionally, both partitions 12 and 13 can access the same port.

In addition to the hardware resources previously mentioned, there are three interrupt resources which an application can use. The first two interrupt resources are ring-in interrupts on lines 34 and 35 respectively. The third interrupt resource is the telephone handset on/off cradle which is provided by line 32.

FIG. 3 shows in simplified functional block form the flow of commands and interrupts. Application 10 interacts across the programming interface 11 and driver 41, implementation code 42 and hardware interrupt router 43, each of which is located in host processing system 89. Hardware interface 44 forms the boundary between host processing system 89 and signal processing system 50. Application commands terminate in partition 24 of instruction memory 21, while interrupts originate in partition 24. Partition 24 contains the signal processor control program. This control program manages instruction memory 21 in partitions 12, 13, and 14 and allows the signal processing code in partitions 12, 13, and 14 to run concurrently, thereby sharing the resources of the signal processing system 50. The flow of commands and interrupts which define programming interface 11 will now be explained in more detail with reference to FIGS. 3 and 4.

FIG. 4 details the flow of commands from application 10 across interface 11 through host 89 and to signal processing system 50. The commands which are input from application 10 to interface 11 contain two types of identification. The first type of identification provided is the function set that is to be used and this identification selects the appropriate control block 51 which in turn accesses the implementation code 42. The second type of identification is of the particular command within a given function set. The driver 41 takes these commands and then passes them on to the appropriate locations in implementation code 42. The select control block information which is part of the command input to interface 11 and driver 41 identifies a particular control block 51. This control block 51 contains a pointer block 71 which points to the beginning of command vector block 52. The command code information contained in the command is output over line 72. Together with the pointer information from pointer block 71, the command code points or indexes to the particular location in command vector 52 to which this command is pertinent. After execution, command vector 52 points to a specific piece of implementation code in command processor 53. Having found the particular piece of code required, drive 41 then passes control to command processor 53 which contains required code. In effect, command vector 52 along with the command code issued over line 72 and pointer block 71 perform an addressing function. Command processor 53 then implements the particular command which has been output from application 10 to hardware system 50.

FIG. 5 Description

Additional description of application signal processing by host processor 89 and signal processor 88 is found in the above mentioned related patent application Ser. No. 786,913 filed Oct. 11, 1985, and titled Hardware Resource Management. The present invention can now be described in this environment as an interpreter that allows an application program working across the application program interface to interact with an operating system (signal processing system) to perform an advanced function without modification of the application program.

In the preferred embodiment, a voice operating subsystem program that performs text-to-speech synthesis operates with an IBM Enhanced 5250 Emulation application program. The program interaction is supervised through an interpreter to allow a remote user to interact by voice and tones over telephone lines with a System 36 through a PC used as an intelligent terminal (host processor 89) as if the user was at an IBM 5250 terminal on a System 36.

FIG. 5 shows how the interpreter fits into a program system consisting of the interpreter program 100, an application program (terminal emulator) interface 102, an operating subsystem (advanced function voice) interface 104, and a profile 106. The interpreter is a program, which runs in the intelligent terminal or workstation (a PC), and it ties together the terminal emulator interface 102 and an advanced function voice interface 104.

Both the terminal emulator interface and the advanced function voice interface are low level application program interfaces which allow very fine control of the operating subsystem and the terminal emulator. What the interpreter 100 does is convert a high level language description given in the profile 106 into these low level commands.

The interpreter program flow in FIG. 6 consists of four main steps. The first one is parse the profile. This sets up a standard structure for all the profile commands so that they can be processed by a supervise command execution step later on. It allows basically a free form of input including comments and sets up a structure for processing commands.

The second step initializes the emulator and voice interfaces. First the program makes sure that the interfaces are there, then it goes ahead and gets the interfaces set up to running all the commands needed.

The third step is supervising the execution of functions by the terminal emulator of the voice operating subsystem using commands created from the parsed profile. This step goes through the commands in sequence to supervise the execution of the required functions. An example would be if the command is KEY, it will send the appropriate series of keystrokes on to the terminal emulator interface.

FIG. 7 shows how the profile parsing works. The very first thing that is done is that the profile is opened using a standard operating system command. Step 108 then reads a word in the profile, a word that is delineated by spaces. If the program comes across the end of a file it just goes on to the next step in processing which is described under FIG. 8. It it is not the end of a file, decision 112 determines if the word that was found is the keyword. If this word is not a keyword step 114 displays and error an stops processing right there. If the work was a keyword, step 116 sets up a structure for the command represented by that keyword.

Once this structure is set up it continues to read through the file, step 118. If the program runs across an end of file while this is happening, it means that an error has occurred because the end of file should only occur between keywords. It should never occur while in the middle of processing a keyword.

Decision 122 checks to make sure that we are not at the end of the command. Commands for this particular profile language are delineated by semicolons. If it is not a semicolon it goes on and checks to make sure that there is a valid parameter at decision 124. If so, step 128 adds the parameter to the structure along with any descriptives for that parameter and control is passed to step 118. If the program comes across a parameter keyword that is not valid for the current command, step 126 displays an error and stops.

The initialization routine shown in FIG. 8 initializes the emulator application program and voice operating subsystem. Step 130 checks to make sure that the emulator is present. This is done by a command given in the emulator documentation. If the emulator is not present, decision 132 branches to step 134 to print an error message and stops the program. If the emulator is present, step 136 checks that the voice subsystem is present following documentation given for the voice interface. If it is not present the error message is printed and the program stops. If it is present, the step 140 opens the voice subsystem. While opening the voice subsystem, the subsystem may return an error code. If so, decision 142 stops the program at step 134. If the voice subsystem was opened without a return code, step 144 loads the voice functions and makes sure they they are ready to go. Decision 146 checks for the return code. If the return code indicates an error, step 134 prints an error message and stops, otherwise control goes on and step 148 connects the voice functions to the telephone line. Decision 150 checks the error return code one more time.

FIG. 9 is a flow diagram of the program for supervising execution of commands created by the parsed profile. First of all step 152 points to the first command in the list of command structures. Step 154 determines the command types. There are two basic types of commands distinguished by decision 156. A very simple one which consists of one function to be sent to either the terminal emulator or the voice interface subsystem. These commands are supervised by procedures represented by block 158. The other type of command is a multiple or more complex command which consists of multiple emulator and voice functions. The more complex commands have lists of parameters describing exactly which functions will be used and in what order to use them. These coplex commands are supervised by procedures represented by block 160.

After the appropriate emulator and voice commands have been sent, decision 162 determines if the control flow should be changed. Step 164 adjusts the control flow according to parameters in profile commands.

Next decision 166 determines if the command pointer has been changed. If not, step 168 increments the command pointer to the next instruction. The next comparison at decision 170 checks if the command pointer indicates the end of the file. If it does not, control is passed back to step 154. If the command pointer indicates that the program is at the end of the command list, control goes on to closing down program.

FIG. 10 shows closing down the flow of the interpreter program. First step 172 issues a close to the voice subsystem interface to free up all the hardware for the next program. Step 174 closes all the files that have been left open, if there have been any left open, and step 176 returns control to the operating system.

In describing the operation of this preferred embodiment command and function definitions will be helpful. The functions that define the interface protocol for the IBM Enhanced 5250 Emulator Program are in Appendix A of the User Guide Manual (#G570-2202-0) for that program. The commands for the interpreter profile are defined in Appendix A2 while a listing of a sample profile with comments is in Appendix A1. The functions that define the voice subsystem interface protocol are as follows:

Base Function Set:

OPEN

Allocates a Resource Control Block (RCB) and starts access to card. The card address is passed to this function and the RCB and Base and Connection Identifiers are returned.

CLOSE

Closes access to the voice operating subsystem. The RCB is passed to the function.

ESTINT

Establishes an interrput routine. The parameters passed to this function include the interrupt to be trapped and the address of the routine to handle the interrupt.

MASKINT

Enables the trapping of interrupts. The interrupts to be handled are passed to this function.

READSTAT

Reads the current status of the RCB. The RCB to be read is passed to this function and the values of interrupt which have had a status change since the last READSTAT are returned.

READCONN

Returns a list of the current function connections for the RCB. It also returns a list of any devices connected to the given RCB.

CLAIMHDW

Claims the devices specified in a list for the given RCB. This function returns a code which indicates if any of the devices had to be seized from another application.

OPTSET

Loads a specified function set from disk into memory. It returns a code indicating whether the function set could be loaded.

CONNFTOP

Connects a specified function set to a specified port. The port must be available for the function set to be connected.

DCONFFRP

Disconnects a specified function set from a specified port. This function frees the port for another function set.

CONNDTOP

Connects an already claimed device to a specified port. The device and port are specified when the function is called.

CONNDEVS

Connect devices together. The devices must have been claimed by the application previously.

DCONDEVS

Disconnects devices which are connected together. At least one of the devices must have been claimed by the application.

ONHOOK

Place the telephone line "On Hook". This function causes the specified line to be placed in a "Hung Up" state.

OFFHOOK

Place the telephone line "Off Hook".

Line Monitoring Function Set:

This function set uses the functions ESTINT, MASKINT, and READSTAT. These functions perform the same services as the base function calls of the same name on a set of line monitoring interrupts including detection of an incoming ring, busy signal, and dial tone. It can also set interrupts based on incoming Dual Tone Multiple Frequency (DTMF) signals.

Text-to-Speech Function Set:

INIT

Initializes the Text-to-Speech (TTS) function set. The function set must have been loaded and connected to a port prior to issuing this command.

FLUSH

Flushes the TTS buffer. This function is needed to remove any unspoken text from the buffer after the TTS function has been PAUSEd.

PAUSE

Stop the conversion of text to speech. This function allows voice production to be stopped by the controlling program.

SPEAK

Convert an ASCII text string to speech. The text string is passed to the function and speech is produced.

The operation of the interpreter will be briefly reviewed by examining the two types of commands that occur with the profile. In addition, the parsing of the profile will also be illustrated with the first example.

To illustrate the operation of parsing, the profile file is opened in FIG. 7 and step 108 is reading through until it finds a keyword such as SAY. Decision 112 branches to step 116 which sets up a place for the text string, a parameter in the SAY command. Step 118 reads the text string from the profile and step 128 adds this parameter (text string) to the command structure for execution by supervising portion of the program (FIG. 9).

This particular SAY command which is near the beginning in the profile listing (Appendix A1) says "Hello, this is telephone access PS36". It only has one parameter which is the quoted string. The semicolon at the end of the line indicates the end of the command and, once the program hits the semi-colon, it goes on to look for the next keyword.

The validity of the parameter was checked at step 124. It is valid because it consists of a quoted string, a string of characters with a double quote at each end. Other valid parameters for the SAY keyword include application display sceen areas which are indicated by square brackets enclosing the desired row, column and length.

When the parse has been completed for all commands in the profile, the entire list of command structures is stored away in the PC memory while the emulator program and the voice subsystem are initialized as illustrated in FIG. 8.

The SAY command is processed according to FIG. 9. When the command pointer is pointing toward the SAY command decision 156 determines that SAY is a simple type of command and sends the text string on to the voice subsystem interface using the SPEAK function. Step 168 increments the command pointer and decision 170 verifies that the command pointer does not indicate the end of the whole profile.

The WAIT command is an example of a more complex command. When the command type is determined by decision 156, step 160 can issue multiple emulator or voice function calls. The WAIT command labeled "1:" in the profile listing Appendix A1 has several options available to it. First, it issues a GETSCREEN function call to the emulator. It looks at the emulator screen using the emulator function, compares the value in the first row to the string "MAIN."If they match, the command pointer is adjusted in step 164 to go to command at label "5:" and control loops through 170, 154, 156 and back to block 160. The MENU command associated with the label is processed in block 160. This process repeats until a simple type command is encountered.

While the invention has been particularly described with a particular application program and operating subsystem in mind, it will be appreciated by one skilled in the art that the profile and the interpreter program could be altered to arrive at equivalent processes to modify other application programs with other operating systems. For example, a touch screen operating subsystem could be operated with existing application programs such as word processing and spread sheet processing by following the flow and structure of the interpreter program and generating a profile to be operated on by the interpreter program. The choices are almost endless.