Method for and apparatus for controlling the execution of host computer application programs through a second computer

Abstract

A method of simultaneously executing one or more computer application programs in one or more host computer system under the control of a second computer system, where the second computer system performs operations on data and instructions and the host computer systems generates presentation information based on the application programs, involves establishing selected parameters in the host computer presentation information, interpreting selected portions of the host computer system's presentation information, providing the interpreted selected portions of the host computer system's presentation information as input to a computer program resident in the second computer system, examining the host computer system presentation information at the second computer system to detect the presence therein of one or more the selected parameters, continuing operation of the second computer system during the examining for the selected parameters, and generating an indication to the second computer system of the detection of one or more of the selected parameters in the host computer system presentation information.

Claims

We claim:

1. A method of simultaneously executing one or more computer application programs in one or more host computer systems under the control of a plurality of secondary computer systems where said computer application programs may be dissimilar to each other, and said host computer systems may be dissimilar to each other, said host computer systems generating presentation information based on said application programs, said method comprising the steps of:

establishing a plurality of relevant selected parameters in said host computer presentation information;

said relevant selected parameters having a variable time of occurrence and context in said presentation information;

interpreting selected portions of said host computer system's presentation information in said application programs being executed;

providing said interpreted selected portions of said host computer system's presentation information as input to one computer program resident in a selected one of said plurality of secondary computer systems;

examining said host information at said selected one of said secondary computer systems to detect the presence therein of one or more of said selected parameters;

said examination of said host computer system presentation information being dependent on the time of occurrence and the context of said selected parameters in said host computer presentation information;

continuing said operation of said selected one of said secondary computer systems and of the other of said secondary computer systems during examining for said selected parameters; and

generating an indication to said selected one of said secondary computer systems of the detection of one or more of said relevant selected parameters in said host computer system presentation information.

Description

BACKGROUND

1. Field of the Invention

This invention relates to the execution of computer programs, and relates more particularly to the execution of one or more computer application programs on one or more host computers under the control of a second computer.

2. Prior Art

There is a need in the data processing field for a single product configuration capable of addressing the following requirements in the computer industry:

1. The ability to develop and operate "user friendly" interfaces which, by providing added functional capability such as integration of data, result in computer systems which have a high degree of consistency and ease of operation through the use of techniques such as high function representations in the form of graphic icons and other graphics, and which are relatively easy for a user to learn, preferably in an intuitive way.

2. The ability for new computer systems to operate existing software packages, without modifications to those packages, and to retain the benefits currently found for those applications which run in a multiuser, multitasking, centralized computer which provides a high degree of storage capacity, processing capacity and information management services.

3. A method for transferring and exchanging data simultaneously among various different, often dissimilar, application programs and different, often dissimilar host computer systems under the control of another computer system.

Although there are various approaches which provide partial solutions to the above requirements, presently there is no set of products designed specifically to address all of these requirements. The current available approaches fall into two categories:

A. Move the application functionality to a cost effective, user-friendly, computer workstation environment which provides both the hardware and software tools and technology to add the functionality of a user-friendly interface to the application. For most business application uses, this computer workstation environment is obtained through the use of the class of microcomputers known as personal computers.

Although this approach has been used to effectively provide the benefit of the user-friendly interface, moving the application functionality involves various amounts of reengineering and rewriting in order to move, or "port", the application to this computer workstation environment. The costs of such reprogramming often makes this approach undesirable.

In addition, if the entire application software and data files are moved to this workstation environment, the workstation capacity, due in part to its cost effectiveness, often becomes a problem and the processing capacity required to provide the user-friendly interface functions plus the application processing is often beyond the capabilities of this workstation environment. In addition, the microprocessor technologies used in these workstations are often limited in the amount of storage which the workstation is capable of accessing. Even where the storage capacity is available in this workstation environment, the problems of distributed information management often outweigh the advantages obtained.

A hybrid approach allows the application software to operate in a secondary computer workstation but the data files remain in the multiuser, multitasking, centralized computer. The hybrid approach involves the use of an intelligent terminal or computer workstation in conjunction with the reprogramming of the central computer. In this approach, the application in the central computer is programmed to direct the workstation to perform many of the user-friendly functions at the appropriate time during the execution of the application. However, adding the user-friendly interface functionality involves various amounts of reengineering and rewriting of the application program, so that the costs of such reprogramming often make this approach undesirable. In addition, such an approach, to provide the maximum benefit, would obsolete the existing terminals used with the application.

This hybrid approach has the advantage of providing centralized information management services and the user-friendly interface while retaining the capacity of the multiuser, multitasking, central computer. Since this approach involves a secondary-to-host computer link, accessing data over that link often presents severe performance limitations. In addition, the processing capacity required to manage the user-friendly interface functions plus the application processing is often beyond the capabilities of the existing mainframe installation.

B. Add the user-friendly interface functionality to a multiuser, multitasking, centralized computer which provides a high degree of storage capacity, processing capacity and information management services. However, attempts to program the centralized computer to perform the user-friendly functions are usually limited by a lack of hardware, software tools and technology to provide such functions.

The attempts to provide a solution to the overall needs may be broken into two classes, non-invasive and invasive, with respect to the host environment.

Non-invasive

The non-invasive class require no change to the host application and they thus acquire the associated benefits of lower cost and risk to the overall user community. These type of solutions range from custom software for a specific application through assorted telecommunications utility packages.

Custom solutions, while presumably attaining complete satisfaction for the specific requirements, require ground-up development and costly maintenance and have limited extensibility. Telecommunications utility packages such as MicroPhone, Crosstalk, SmartComan, etc., address the fundamentals of monitoring the host data stream, but are limited to line-by-line serially organized transactions. They focus on the automation of repetitive sequences on behalf of the user with little support of adding value to or enhancing the user interfaces and services.

Complexity of a Non-Invasive Intermediary

A non-invasive approach requires the added function to serve as an intermediary between the host environment and the end user. To function effectively, the intermediary must remain responsive both to the host application and to the end user; that is,

(a) it must be able to detect a new signal from either host or user, and

(b) it must be able to respond appropriately.

By one means or another, a responsive program must be able to navigate from each of the possible states it may be in to a desired successor state. For an interactive application, "state" is the current situation of the host and the client. A standard technique is:

(a) list the possible states or situations that may arise;

(b) build into the program a test that permits it to recognize which state is it in; and

(c) specify the action to be performed when each state is recognized.

This fundamental structure is embodied in the case statement of standard programming languages, which starts with a test and lists the action to be taken for each of a list of possible outcomes. The action takes the program from one state to another state. In each possible new state, the program requires a new list of possible states for which to test, and a new list of actions to take when one of them is detected.

In principle, if the interaction of host and user can be described by "n" states, and if each state may be followed by another, then the application would require n| (that is, n.times.(n-1).times.(n-2) . . . ) state-tests. In practice, the number of states that must be foreseen and tested is less than n| because some combinations are so unlikely that they can be safely neglected. Nevertheless, to maintain the responsiveness of the application, the number of program branches that must be provided is proportional to the factorial of the number of states.

This explains a major drawback in the development of effective non-invasive systems: while their prototypes are small, with a low number of distinct states, the programming task is manageable. However, the process of developing and refining the intermediary program requires identifying the responding to more and more states. Thus, the complexity of the application increases enormously with even fairly small increases in the number of states that the program must recognize. Simplified prototypes, recognizing a minimal number of states, can deal with them adequately, and may give the impression that the basic problem is solved and requires only polishing or refinement. This is misleading. Using the classical state-transition method, the amount of refinement necessary to bring the intermediary's responsiveness to a satisfactory level requires an enormous increase in the complexity of the program.

One of the features of the present invention is that it provides a new method for maintaining the responsiveness of an intermediary program which frees it from the enormous increase in complexity that has been required by existing methods.

Invasive

The invasive class involves changes to the host applications, producing a tightly coupled solution wherein the host application drives a graphic interface engine at the user workstation. This requires costly changes to the host environment and the associated problems of the maintenance of dual capabilities supporting users with old and new style interfaces. This approach is very sensitive to the data communications protocols in use with the host. Technologies available provide for complete transformation of the user interface such as with MacWorkstation from Apple Computer.

Personal Computers

A personal computer is not just a small version of a mainframe host computer. Despite the rapid development of ever more powerful small computers, the two still differ strikingly. Some such differences are:

Role of a host A host computer may have access to data that is:

(a) more voluminous than a PC could contain, and

(b) shared by a community of clients.

Examples are the inventory of a manufacturer, the reservations of an airline, the auto registrations of a state, and the letters exchanged by a variety of correspondents. All of these entail not just large volumes of data, but also continual input and update from many sources. A small computer devoted to the work of an individual is inherently unsuited to the custody of such an information resource.

Role of a PC. A personal computer can respond to its users with an immediacy and detail that is not practical for a mainframe host. It can track the motion of a mouse in real time, or update the details of a graphic display to produce the visual effect of motion, or synthesize vibrations that produce the effect of speech. This requires a continual transfer of immense amounts of information, but only between the PC's screen, speaker or keyboard and its processor a few inches away. A host computer could as easily perform the calculations, but a host could not transfer the information quickly or cheaply enough over the communications link to a remote terminal.

Consequences of the different roles of PC and host.

Certain kinds of tasks are better suited to large central facilities. This is partly because of the bulk of the data and the "horsepower" required to process it, but it is primarily because some data is inherently central and shared. On the other hand, "user friendly" interfaces consume a great deal of computation simply to make them visually attractive and speedily responsive. From a strictly logical point of view, computation that serves only to make an application "friendly" is irrelevant to the data-processing task. Nevertheless, it is essential to making applications attractive and easy to use. Such computation is more economically performed by the PC at the user's fingertips than at a central facility.

A great many powerful and effective application programs exist for host mainframes. In general, they were developed without benefit of the attractive human interface possible on a PC, largely because such an interface was (and remains) impractical to a terminal connected by a low-bandwidth link. They were also developed without benefit of common standards or conventions. Thus, despite the fact that they perform work of undoubted value, they remain difficult to learn, awkward to use, and almost impossible to integrate or coordinate. Their conventions are so varied that the user who at last becomes skilled in one finds that skill of little help (or even a hindrance) in starting to use another.

The business community using computer facilities needs:

1. To integrate the powers of separate computing systems in ways that permit a user to make joint use of more than one.

2. To broaden the base of employees who can make effective use of the existing computer resources.

3. To reduce and focus information presented to each class of user to what is relevant and meaningful in the user's context.

4. To reduce the time and cost required to train users to make effective use of computer applications related to their work.

5. To maximize the transfer of training between various applications by offering an integrated and consistent interface to a variety of systems.

6. To maintain the usefulness of large installed systems whose fundamental processing is valid but whose user interface is cumbersome and obsolete.

Faced with an urgent need to make better use of a large number of powerful yet hard-to-learn computer applications, the business community has been faced with a choice between unattractive alternatives: to embark on extensive training (in effect, to adapt their human users to complex and conflicting requirements of the various applications), or to rewrite and build a number of large and expensive application programs.

SUMMARY OF THE INVENTION

In order to meet the requirements stated above, the present invention uses a secondary computer communicating with one or more application programs in one or more multiuser, multitasking, high capacity, centralized computers to provide the tools and technology which allows the development and operation of adaptive, user-friendly interfaces to existing application software packages operating in the centralized computers. The invention allows the secondary computer to function as a distributed processor, operating in conjunction with the central computer or computers to perform the functions required to provide a user-friendly interface.

The invention also provides a machine-independent, information-exchange environment and subsequent method for transferring and exchanging data among applications and hosts. Furthermore, the invention provides the added functionality without requiring the application software in the centralized computer or computers to be changed in any way.

Utilizing this invention presents an environment which provides a standardized style and manner by which the user interacts with various, different application programs. The present invention distributes the functions of accessing and interacting with one or more host application programs and providing a user-friendly interface for each application, such that new or existing full-featured applications can run unencumbered in the more powerful host computer or computers, while the majority of the power of the secondary computer can be used to present the user with a user-friendly interface to the application or applications. Thus, many of the performance limitations of a secondary computer are avoided.

The secondary computer, which can be described as a very intelligent workstation, changes the user's environment from one in which a user must adapt to a fixed interface for each application and a fixed method of operating the secondary computer (or alternatively, a present-day computer terminal) to one in which the user defines the way he wishes to interface to the application even though the application interface in the actual host application remains fixed. As a result of this invention, there is no need to modify the vast libraries of business application software to provide such an interface. Transitions in conditions required to accomplish that interface are performed by the secondary computer through the architecture of this invention.

Since the application or applications remain in the host computer or computers and only a relatively small set of translation instructions, called an Application Interface Module (AIM), must be downloaded to be executed by the secondary computer, the problems associated with the relatively small memory of the secondary computer are overcome. Also, since only the AIM and data that has been used or changed by the user needs to be moved from or to the host system, performance delays typical of more conventional systems are overcome.

Additionally, since the environment created by the invention fully supports multiple sessions in support of applications running on a single host or on separate hosts, and since the environment translates all applications user interface operations such that, while being operated on by way of the secondary computer, they all have a common data and interaction form, interchange and integration of information between any application becomes a readily available facility to the user. In addition, data or graphic information derived from the host application but created in the secondary computer can be appended to the information that is a part of the application in the host system.

That is, the secondary computer presents the same familiar user-friendly interface to the user for a variety of application programs to be run, thus eliminating the need for the user to learn the often complicated details of interfacing with a variety of different application programs, while still making available to the user the benefits of these application programs. Additionally, this solution avoids the complexity and maintenance costs of distributed information management.

A multiuser multitasking host computer employing the present invention and using the secondary computer as a terminal can continue to be a node in a networking environment, should the user's needs require a network.

The "WHOOP"

The central component of the present invention is a unit called the WHOOP ("Watch Host Patterns"). The WHOOP notes, interprets and responds to communications arriving from the host program. It responds not to particular characters or sequences in the communication, but to the information that they convey. Based upon its review of the arriving information, the WHOOP notifies the AIM that it has detected a condition of interest to the AIM. Thus, the signal that the WHOOP transmits to the AIM is not a translation of what the host sent, but notice of a deduction that the WHOOP has made.

This may be clarified by an example. At the beginning of almost every session with a host, the host and the terminal transmit opening formalities such as an exchange of identifications and passwords. The end user and the AIM are indifferent to the specifics, but vitally concerned with the general outcome. The WHOOP need not pass on details of port number, log-on time, and system logo, or the various codes and messages that the host may send to indicate troubles. Instead, the WHOOP notifies the AIM which of several broad outcomes has transpired. The AIM may request signals for the following:

We have established normal communication and may now proceed;

We can't get through now, but may try later;

Our physical communication is OK, but we have been denied access;

We have encountered a situation that doesn't match anything we recognize.

This simple example illustrates two aspects:

The categories reported are established by the AIM, not by the host.

The notification the WHOOP sends does not repeat what the host said (although it could do so if desired), but notifies the AIM which of various contingencies has occurred.

The AIM in turn need never mention these details to the end user. When the process is proceeding normally, the AIM receives from the WHOOP the confirmation that the process is progressing as foreseen, and continues the work at hand.

The WHOOP's function is not to translate all it sees, but to review what it sees in the light and context of the AIM's current needs, and to notify the AIM when it concludes that it has identified a situation that the AIM has asked about.

Linearization of the State Transition Table

The earlier discussion described the explosion of complexity which results when there is a module of the intermediary program corresponding to each state of the host-user interaction, and each module must maintain its own table of events that signal a state change and actions required in response. The WHOOP of the present invention radically simplifies the transition table by providing a single table for the application as a whole, responsible for all responses and transitions. In principle, the size of the table is proportional to n (the number of distinct states) rather than to n|

Functional Components of the Invention

The invention consists of the design and realization of the WHOOP and its linkage to several essential services.

For each of the host programs with which it interacts, the secondary computer establishes what can be called a virtual device (or simply "device" for short). The services that comprise each device are as follows:

1. Link. The secondary computer manages the connectivity between it and each host. Since there may be multiple links, the software that maintains them must be prepared to operate with multiple different connectivity arrangements (e.g. SNA, ASYNC, etc).

2. Session. A session consists of all transactions between a specific host program and the secondary computer. Since there may be multiple sessions with one or more hosts, the software that maintains them must be prepared to multiplex and demultiplex communications according to the session for which it is appropriate.

3. Presentation space. For each session, the secondary computer maintains information about the state of the display that would exist if the host were communicating with a conventional terminal. The manager of the presentation space thus performs some or all of the functions of a terminal emulator optimized for the WHOOP, but does not necessarily display what is in its presentation space or transmit responses from the presentation space back to the host.

4. WHOOP. The WHOOP reviews the presentation space and responds to patterns that the AIM has asked it to look for. The functions of the WHOOP are described further below, and elaborated on in the body of this application.

5. Application program interface. A mechanism to pass information from the WHOOP to the AIM, to manage displays at the PC, and to accept input from the secondary computer.

Functions Of The WHOOP

In order to provide an encompassing solution for the varying host interface characteristics, the WHOOP is based on a unique technology designed for handling the data from the host application and decomposing it into identifiable and standardized transactions to be processed by the AIM. The end result is that the conversation between the AIM and the host is broken down into individual transactions even though the conversation may be serial in nature with no explicit transaction boundaries. The main functions performed by the WHOOP are:

1. Accumulation. The WHOOP accumulates device independent information from the device's presentation space. That is, it maintains an image of the presentation and the information from its space, but in general does not review it continuously, but waits until a trigger event prompts it to do so.

2. Trigger. The trigger mechanism indicates to the WHOOP when it is time to review the accumulated image of the presentation space. The WHOOP then examines the presentation space image to see whether a message of interest has arrived. Between trigger events, the WHOOP can ignore changes to the image by the device's presentation space. The trigger has the following abilities:

A trigger event may be keyed by something in the host transmission (for example, the end-of-line character sent by the host). Or it may be a change in the status of the communication link, the absence of activity for a certain amount of time, or the detection of an error condition, etc.

A trigger event may also be independent of the host, for example an event generated by the PC clock or by the AIM.

The trigger event is continuously redefinable. The AIM can thus control the determination of what events should trigger the WHOOP's review of the accumulated image in a continuous manner to reflect those appropriate to the current context of the AIM's communications with the host application.

Within this function, the WHOOP discriminates multiple concurrent trigger contexts. The process of managing a conversation with multiple topics requires the parallel discrimination of multiple trigger contexts, any of which may occur next in time.

3. Discrimination. When a trigger event occurs, the WHOOP examines the presentation space to determine which, if any, has occurred of a list of possible situations that the AIM has asked it to report. In this examination process, it must first decide whether sufficient information has been received to identify one of the target situations. A major component of the invention is the method of examining the presentation space to discriminate between situations.

4. Decision. When a target situation has been discriminated, the WHOOP selects an action to take by sending an appropriate notification to the AIM. This results in the generation of a standard message to the AIM.

5. Dynamically Reprogrammable. The target list of situations to be discriminated and actions to be taken is under dynamic control of the AIM. This permits the discrimination of target situations and/or the actions to be taken when each is detected to depend upon the context, as influenced both by transmissions received from the host application and input received from the human user. The AIM may at any time update the list of situations to be discriminated or signals to be sent, and their relative priority.

The major task in developing an AIM is to identify and characterize the list of situations of interest and actions to be reported in response to the changing circumstances of the host and the changing requests of the human user.

The present invention brings all the benefits of the non-invasive class of solutions without the cost burden associated with the prior art non-invasive approaches discussed earlier, with the addition of the key element of a general purpose host interface communications approach. The present invention involves the interposing of agent process AIMs between the user and the host application or applications. The AIM deals with both the user interface and the host interface asynchronously and may thus provide the optimum user service independently of the host application cycle.

The present invention provides a technology for managing the host interface that relieves the AIM of dealing with non-significant changes while at the same time being prepared for any eventuality.

The present invention, coupled with an object oriented application building tool, such as Hypercard.TM., brings the ability to marry new user interfaces to existing mainframe applications with all of the benefits and none of the drawbacks of any of the prior art approaches.

The present invention provides an attractive approach by leaving both users and host programs as they are, but interposing a family of AIMs to act as mediators between them. This approach has the following advantages:

An attractive easy-to-use interface can be prepared for host applications that previously lacked it.

The user interface can apply common conventions and standards to a wide variety of applications. New users are thus shielded from the vagaries and inconsistencies of the host system. This

reduces the time required to train personnel

permits "seamless" migration for the user community across changes to the host system, applications and the host system application programs on the connectivity requirements between the host and the secondary computer.

It is unnecessary to rewrite existing host applications. The host can continue to serve its expert users in the established way while its new users take advantage of a radically revised interface without change or even without collaboration at the host. In this sense, the AIM and WHOOP are a non-invasive adjunct to the host.

The major thrust of the present invention is a method to:

Analyze transmissions received from various host programs.

Abstract from the information relevant to the user at the secondary computer.

Manage an independent display of the information it has abstracted from the various host programs.

Manage interaction with the human user at the secondary computer.

Generate and transmit commands to the various host programs that:

reflect the effect of the human user's wishes and decisions,

maintain the conventions that each host program expects,

do not require the human user to learn or even to be aware of the conventions and command language of the various host programs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of the overall configuration of the elements of the present invention;

FIG. 2 is the architectural building blocks involved in the present invention;

FIG. 3 shows the relationship among the elements of the invention and the different control, signal and data interfaces;

FIGS. 4-14 are flow charts showing functions of the different elements of FIG. 3;

FIG. 15 illustrates the operation of the invention in connection with the control of a modem; and

FIG. 16 is a diagram showing the functions of the recorder/player in the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Description of the features and operations of the present invention are given in the publications "Mitem View.TM. Manual", Beta Release 1.0621, September 1989, and "Mitem View Developers Toolkit for Creating an Online Enterprise", Reference Manual, Version 1.0A, March 1990, both by Mitem Development Corporation. Both of these publications are incorporated herein by reference.

FIGS. 1 and 2 illustrates some of the elements employed in this invention. They include a central event management element 11, a communications management element 12, a presentation management element 13 and a window management element 14. As shown in FIG. 2, these elements interact through WHOOP element 16 with AIM logic 17, workstation local services 18 and user interface management 19.

FIG. 3 illustrates the operation of the present invention in more detail. In FIG. 3, lines labeled "C" represent control lines, those labeled "S" are signal lines and those labeled "D" are data lines. The AIM module P1 supplies a normalization control on control line C1 to normalization portion P2. The functions performed by normalization portion P2 are as follows.

C1--Normalization Controls

These vary locally controlled characteristics of presentation personality such as auto-newline, 80/132 columns, etc. Examples of inputs on control input C1 are illustrated in the flow chart of FIG. 4 and include a group of Virtual Device Controls (line C1a) and a separate group of Window Controls (line C1b).

D1--Data Inputs

Typical operations performed in normalization P2 in FIG. 3 on data input D1 are illustrated in the flow chart of FIG. 5. The input functions on data input D1 can include Control Codes (line D1a) and Display Codes (line D1b). The Control Codes function to process control characters such as screen address information into changes to cursor location and/or changes to accumulated data such as erase field, etc., into normalized commands to accumulation P3. The Display Codes functions process non-control characters directly into normalized ASCII characters to be placed in the accumulation buffer. Data inputs on D1 also issue "activity" signal S2 for relevant host data and/or controls received.

D8--Virtual Key Input

These are exemplified in the flow chart of FIG. 6. The virtual key input D8 from AIM P1 is processed according to presentation type (terminal emulation). Control function keys (line D8a) are interpreted either locally (e.g. block mode 3278, etc.) or sent character by character to a remote host (e.g. as in full duplex VT100) in appropriate presentation form as output D9.

Display keys (line D8b) for block mode information is entered into a data field in a local buffer. Full duplex character-by-character information is sent to the host by way of the associated communications facility.

P3--Accumulation

Accumulation portion P3 in FIG. 3 receives a control input C2 from AIM P1. This controls processes such as buffer clear, scroll back and forward. Accumulation P3 also receives input on line D2 from normalization P2, representing normalized control and data. This results in processing data characters by placing them at the cursor location in the data buffer and advancing the cursor one position and applying appropriate line wrap rules.

P8--Extraction

This element in FIG. 3 receives a control input C5 from AIM P1 representing an extraction control request. As shown in FIG. 7, P8 operates to extract data from Accumulation P3 in either cursor relative locations (line C5a) or absolute locations (line C5b) by way of line D5 according to a mask in the applications data base, returning character string(s) to the user workspace by way of D6.

P4--Triggering--Control Inputs C3

This portion receives a trigger control input C3 from AIM P1. As shown in FIG. 8, this input sets up pattern check trigger conditions for current application needs. These include Communications States (line C3a) for Every Character, Empty Data Buffer and End Of Transmission. Also included are Character-by Character control (line C3b), cursor state (line C3c) and virtual device states (line C3d), the latter including keyboard unlock. The trigger conditions may be continuously changed to meet the current needs of the host application interface.

P4--Triggering--Data Input (D3) Normalized Host Presentation Data

This is shown in FIG. 9 representing the input D3 from normalization P2 to triggering P4. It includes a character-by-character operation (line D3a) having options of match or no match to the triggering condition. If a match is found, information is sent to analysis P5 by way of signal line S1.

This processes both commands and normalized display characters. Display characters are processed against the specific character trigger condition and also for the every-character trigger condition. Controls such as the normalized "newline" and keyboard unlock are checked against their unique trigger conditions. Buffer empty status is processed against its unique trigger condition. Signal S1 is generated for any valid match condition specified by the AIM developer by way of input C3 to triggering P4.

P4--Triggering--Signal Input (S7)

The signal input S7 to triggering P4 from normalization P2 conveys conditions as shown in FIG. 10. These include Every Character (line S7a), Cursor State (line S7b), Device State (line S7c) and Communication State (line S7d). In each line, in the situation of a triggering condition occurring, information is sent to analysis P5 by way of signal S1.

P5--Analysis Signal Inputs (S1, S3 & S4)

The signal inputs to analysis P5 are shown in FIG. 11. The input S1 is from triggering P4. This results in examining a list of current patterns in a last in/first out manner (LIFO) until one matches (line S1a) or the end of the list is reached with no match (line S1b), using pattern specifications from the user data base and the accumulated data supplied by way of D4 from accumulation P3. If the end of list is reached without a match, then no further action is taken. If a pattern match is obtained, idle timer P6 is started by way of control line C6 to provide a stable pattern check.

The input S3, Idle Timeout, to analysis P5 indicates that the pattern is stable. This generates signal S5 to message handling P9 indicating a pattern identification.

The input S4, Match Time-out, indicates that no pattern has matched during the specified time interval. This results in sending a time-out signal by way of S5.

P5--Analysis--Control Inputs (C4)

The control inputs to analysis P5 from AIM P1 by way of control C4 are shown in FIG. 12. These include add/remove pattern (line C4a), pattern state (line C4b) made up of enabled, disabled and one-shot, an analysis state (line C4c) and a timeout (line C4d).

P6--Settle Timer

The operation of settle timer P6 is shown in FIG. 13. This includes the operations of set timer duration (line C6a), start timer (line C6b) and stop timer (line C6c). FIG. 13 also shows the restarting of settle timer C6 by signal S2 (line S2a).

P7--Pattern Match Time-Out

Similarly, FIG. 14 shows the operation of pattern match timer C7, including the steps of setting timer duration (line C7a), start timer (line C7b), stop timer (line C7c) and the restarting of timer P7 by the signal on S2 (line S2b).

Pattern Match Timing Parameters

The following features of the invention provide for control of pattern match conditions.

1. One-shot (pattern automatically disabled after a match).

2. Exclusive pattern (matches only if it has not previously matched at the current location in the transaction data buffer).

3. The host session may be selectively frozen at the time of a match or permitted to continue processing for greater simultaneity.

4. Refinement of the end-point of the host application's response can be achieved by the application of a settle timer that is automatically restarted by host activity.

Pattern Match Locating Parameters

The requirements for pattern locating types are determined predominantly from the user interface device characteristics. Teletype, line-at-a-time style with a scroll-up feature utilize mainly cursor (data pointer) relative features, while block mode devices such as IBM 327x devices operate in a full screen mode and utilize absolute x,y addressing in the two dimensional data buffer. Examples are:

1. Cursor Relative--the pattern's origin within the data accumulation buffer is the x:y co-ordinates of the cursor (data pointer).

2. Absolute--the pattern's origin is absolute within the data accumulation buffer.

3. Combinations of absolute and floating x and y co-ordinates within the data accumulation buffer.

4. Experience with the user interface of various IBM mainframes systems as presented on standard character oriented visual display terminals has introduced an additional requirement for pattern processing. During certain phases of the application cycle the host may present fixed input information at the bottom of the screen, with its associated "key entry" cursor, while displaying responses to input as one or more lines scrolling down the screen.

In these circumstances, the user enters responses in the field at the bottom of the screen and the host responds in the next available line down the screen. The host responses are neither cursor relative (have no predictable offset from the data entry cursor), nor screen absolute (the different lines may vary in number every connection). Users identify the current response from the host by locating the last information written in the non-entry area of the screen (i.e., not necessarily where keystrokes have been entered).

The present invention avoids areas of the screen that are not of interest by excluding them from the field of examination. This includes, firstly, the use of a mask to define an area of interest and, secondly, the use of an additional pivot or origin type for patterns and masks. This new pivot is the address of the Last Visible Character (LVC), excluding blanks/spaces, written to the screen within the area defined by the aforementioned area of interest mask.

During the development process the application of a mask defining the area of interest causes an additional pointer to appear in the terminal emulation window showing the location of the Last Visible Character (LVC) displayed. The developer may then optionally specify patterns and/or masks as being relative to the LVC in the same way as can be done for cursor relative operations.

Data from Host

The data communication protocol layer buffers information characters after stripping them of any enveloping protocol information. The communications layer delivers these buffered characters to the presentation layer either one at a time or in groups according to the characteristics (Time and/or protocol dependent) of the data communications protocol. The presentation layer then decodes the information and formatting codes and applies these as changes to the presentation (virtual device) buffer.

Trigger Conditions--"WHEN to check"

The requirements for trigger conditions are dominated by the differing characteristics of the user presentation devices (CRT/VDT/VDU) and the supporting data communications service. The objective is to define the conditions under which the host may be characterized as having completed a response to a previous input.

The WHOOP of the present invention monitors the state of the device buffer for valid conditions for checking patterns according to the previously established "When to check" criteria. These criteria include:

1. Every Character

2. Cursor moved to the start of the next line (Newline)

3. Cursor at a specific location in the data buffer

4. Specific character processed

5. Communications buffer empty

6. Visual Display Keyboard unlock

7. Communications session turn-around

The WHOOP steps through all enabled patterns, checking each in turn until one matches or until it has exhausted the list. In either case it then awaits a further valid "WHEN" condition before rechecking any patterns. If a valid "WHEN" condition is encountered, the WHOOP applies its pattern recognition process according to the previously supplied patterns against the accumulated virtual device buffer. These are applied in a LIFO manner. Disabled patterns are ignored whether as the result of explicit AIM action or as the result of a "one-shot" action.

The WHOOP reestablishes its point of reference in the data buffer for each pattern according to its respective origin mode. These different modes support operations with diverse host computer systems with conversational character-at-a-time interfaces to block mode, forms type interfaces. The origin mode of each pattern may be defined as:

Relative to cursor location

At an absolute location

Any row and/or any column

LVC

Patterns consist of one or more slits (single row deep) combined into a mask which are applied to the accumulated virtual device buffer to match a predefined string of data. The information selected by the slits in the mask is compared with the data string in a concatenated form to complete the pattern matching process. If a settle time was specified, then the reporting of the pattern match is delayed until the settle time has expired without any activity from the host. Host activity at any time restarts the whole process from the beginning.

If a pattern is matched in all of the above respects, the AIM is notified of its arrival. The reporting may be selectively synchronous or asynchronous with respect to the state of the host data buffer contents (preselected on a pattern by pattern basis). Synchronous reporting of pattern matches freezes the host data stream until the AIM has processed the event.

Asynchronous reporting provides for greater simultaneity by permitting the continued processing of the host data buffer. Asynchronous reporting of pattern matches is applicable when the contents of the data buffer does not need to be examined at the time of a pattern match. The pattern match is reported in the next convenient application processing time slot.

Patterns may be added or subtracted, enabled or disabled to provide refinement of the set of host messages that are being looked for at any time. Patterns themselves may be further refined by their mode of operation such as "one-shot" and "gamma". "One shot" patterns automatically disable themselves after a match has been signaled by the WHOOP. They may be explicitly re-enabled at any time. "Gamma" patterns, having been matched and signaled, will not rematch until they match at some other location in the virtual device buffer.

DATA FLOW EXAMPLE

Shown below as Example I is a simplified example of the operation of the present invention utilized in connection with the control of a Hayes modem.

These are two requirements for getting a Hayes modem under control. The first is to define the configuration of the communication facility involved. In Example I, it is assumed to be running at 1200 bits per second and seven bits per character, using X-on, X-off protocol, as shown in the right hand column in Section 1 of Example I, "Set-Up Communication Facility." The second requirement is selecting TTY for the normalization process. This defines the fact that for this particular communication session, ASYNC will be used and TTY emulation will be used for the normalization rules for interpreting commands and orders. This is the first time C1 is used to define the communication session. Additional sessions are handled in a similar fashion.

EXAMPLE I

(Section 1) Set up communications facility

    ______________________________________
    Protocol: Async
                   i. Set up communications facility
                   X25
                   TCP/IP  Async  1200  7e
    X-OFF
                   etc
    Terminal: TTY
                       VT100
                       3278
    etc                        ii. Select TTY emulation in
                                Normalization P2 via
                                control C1
    ______________________________________

    ______________________________________
    .sub.-- -- -- -- -- -- -- ****
                     Cursor Relative mask from
    › !              cX+7,cY-1 to cX10,cY-1 where
                     cX,cY is the cursor
                     coordinates.
    ______________________________________

    ______________________________________
    openFitos    Makes the present invention available.
    closeFitos   Removes the present invention and
                 cleans up when the AIM is closed.
    fitos        Allows the present invention to pass
                 messages to the AIM.
    fitosVers    Returns the current present invention
                 version number.
    stackVers    Returns the version number of the
                 current stack.
    maxMemory    Returns amount of free memory.
    ______________________________________

    ______________________________________
    makeDevice   Creates a device, including its
                 session window and its WHOOP. Before
                 the device can communicate, the AIM
                 must make a device for each active
                 session.
    commandTo    Sends a command to one of the managers
                 associated with a device (for example,
                 to initialize the WHOOP).
    stateTo      Revise the state parameters of one of
                 the managers associated with a device
                 (for example, makes a device's window
                 visible or invisible or alters the
                 communications parameters).
    pfKey        Sends a sequence of characters
                 associated with a particular virtual
                 device's Function Keys.
    ______________________________________

    ______________________________________
    addPattern     Adds a previously defined
                   pattern to the list for a WHOOP.
                   addPattern also specifies the
                   name of the handler to which the
                   WHOOP must signal when the
                   pattern is found.
    rmvPattern     Removes a pattern from a
                   particular WHOOP's list.
    modifyPattern  Modifies the attributes of a
                   pattern already in the WHOOP. In
                   this way, the AIM may alter its
                   response to patterns as
                   circumstances change.
    addErrPattern  Adds an error pattern to a
                   device's WHOOP.
    modifyErrPattern
                   Change the state of an error
                   pattern that has already been
                   added to the WHOOP.
    rmvErrPattern  Removes the most recently added
                   error pattern from the WHOOP.
    timeOut        Tells the WHOOP how long to wait
                   for a response from the host
                   system before signaling an error
                   to the AIM.
    whenWHOOP      Instructs the WHOOP to modify its
                   rules about when to check
                   patterns.
    ______________________________________

    ______________________________________
    typeString   Writes a string of characters to a
                 device's session window and transmits
                 them to the host system.
    slitAttribute
                 Returns a string of attributes bytes
                 for a slit.
    slitString   Returns a text string taken from the
                 device's session window by looking
                 through a specific slit in a mask.
    allSlits     Returns the number of slits that a
                 mask contains, or indicates which
                 slits contain specified text.
    collectOn    Opens a buffer to receive a filtered
                 stream of characters arriving from the
                 host system. (The collected
                 characters are retrieved by the
                 function dataFrom.)
    collectOff   Terminates collectOn.
    dataFrom     Returns the characters collected in
                 the device's buffer. This is a step
                 in processing a block of data
                 transmitted from the host system.
    dataTo       Transfer data from a HyperCard
                 contained to the session window and to
                 the host system.
    dataOff      Terminates dataTo.
    fromMask     Transfers data from specific locations
                 on a device's session window
                 (specified by a mask) to one or more
                 HyperCard containers.
    toMask       Transfers data from one or more
                 HyperCard contains to locations on a
                 device's session window.
    ______________________________________

    ______________________________________
    fileFrom    Starts a file transfer from the host system
                to the Macintosh. Once started, sends
                progress reports as the transfer proceeds
                so the AIM can inform the user.
    fileTo      Starts a file transfer to the host system
                from the Macintosh. Once started, sends
                progress reports as the transfer proceeds
                so the AIM can inform the user.
    fileOff     Aborts a file transfer that has not yet
                completed.
    getFile     Opens a dialog that returns both the name
                of a file and the path to it.
    ______________________________________

    ______________________________________
    recorderOn   Captures the data stream arriving from
                 the host system and records it in a
                 file.
    recorderOff  Terminates a recording and closes the
                 file in which the data stream was
                 being recorded.
    playerOn     Takes the data recorded in a file and
                 presents it to the Communications
                 Manager as if it were being received
                 in a session with the host system.
    playerOff    Turns off the player.
    ______________________________________

• Inventors
  Kleinerman, Aurel; Carroll, David J.;
• Assignee
  Mitem Corporation (San Jose, CA)
• Published
  Mar-31-1998
• Current US Classes:
  719/320
• Application #
  542863
• International Classes
  G06F 015/00; G06F 013/00
• Field of Search
  395/800 395/500 364/DIG.
• Examiner
  An; Meng-Ai T.
• Agent
  Madden; Walter J.
• US Patent References:
  4142234
  4301513
  4455624
  4513373
  4559614
  4646261
  4806919
  4839828
  4862389
  5036484