Integrated data communication and data access system including the application data interface

Abstract

An integrated data communication and data access system includes a first cache memory operatively connected to a first application and a first conversion means operatively connected to the first cache memory and interfacing between a first operator of the first application and the first cache memory for receiving original data having a first format from the first operator and converting the original data having the first format into original data having a second format, the first application storing the original data having the second format in the first cache memory and in a database when the first application sets a persistant or a transient storage state. A second application independently inquires about the existance of the original data having the second format, independently of the first application, by querying the database for such original data, the second application expressing interest in such original data to the first application via a server, receiving any subsequently modified versions of such data having the second format directly from the first application, and storing the subsequently modified versions of such data having the second format in the second cache memory and in the database if the second application sets the persistant storage state.

Claims

We claim:

1. In an integrated data communication and data access system comprising a first client non-server application including a first cache memory, a second client non-server application including a second cache memory, a database interconnected between the first client non-server application and the second client non-server application, and a server interconnected between the first client non-server application and the second client non-server application, a method of communicating between client applications, comprising the steps of:

(a) generating, by said second client non-server application, an original set of data, said second client non-server application adapted to set a persistent storage state and a transient storage state and a memory storage state, said second client non-server application attempting to store said original set of data in said second cache memory and in said database after said second client non-server application sets said persistent storage state and said transient storage state and said memory storage state;

(b) storing, by said second client non-server application, said original set of data in said second cache memory when said second client non-server application sets said persistent storage state or said transient storage state or said memory storage state,

(c) storing, by said second client non-server application, said original set of data in said database when said second client non-server application sets said persistent storage state or said transient storage state, and not storing, by said second client non-server application, said original set of data in said database when said second client application sets said memory storage state;

(d) retrieving by said first client non-server application said original set of data from said database and storing the retrieved original data in said first cache memory of said first client non-server application;

(e) in response to said retrieved original data stored in said first cache memory of said first client non-server application, expressing interest by said first client non-server application in a subsequently modified version of said original set of data by transmitting an interest object associated with an event from said first client non-server application to said server;

(f) receiving said interest object in said server and retransmitting said interest object from said server to said second client non-server application;

(g) generating by said second client non-server application said subsequently modified version of said original set of data when the second client non-server application practices said event, said second client non-server application notifying said first client non-server application when the subsequently modified data is generated and attempting to store said subsequently modified version of said original set of data in said second cache memory and in said database;

(h) storing, by said second client non-server application, said subsequently modified version of said original set of data in said second cache memory when said second client non-server application sets either said persistent storage state or said transient storage state or said memory storage state;

(i) storing, by said second client non-server application, said subsequently modified version of said original set of data in said database when said second client non-server application sets said persistent storage state, and not storing the subsequently modified data in said database when said second client non-server application sets either said transient storage state or said memory storage state; and

(j) transmitting, by said second client non-server application, said subsequently modified version of said original set of data associated with said event from said second client non-server application directly to said first client non-server application without routing the subsequently modified data through said server.

2. The method of claim 1, further comprising:

(k) responding by said server to one or more revocation objects received from one or more client non-server applications; and

(l) responding by said server to additional interest objects received from other additional client applications.

3. The method of claim 2, wherein the responding step (l) comprises the steps of:

transmitting said interest object associated with said event from a third client non-server application to said server;

retransmitting said interest object from said server to said second client non-server application; and

transmitting said subsequently modified version of said original set of data associated with said event from said second client non-server application to said first client non-server application and to said third client non-server application without routing said subsequently modified version of said original set of data through said server when said second client non-server application practices said event.

4. The method of claim 2, further comprising the steps of:

(m) transmitting a revocation object from said first client non-server application to said server,

(n) in response thereto, transmitting said revocation object from said server to said second client non-server application; and

(o) in response to said revocation object, un-registering, within said second client non-server application, said interest object of said first client non-server application associated with said event and refraining, by said second client non-server application, from sending said event information associated with said event directly to said first client non-server application when said second client non-server application practices said event.

5. The method of claim 2, wherein said first client non-server application is adapted to terminate its execution, and wherein the responding step (l) comprises the steps of:

responding, by said server, to a revocation object received from said first client non-server application and transmitting said revocation object from said server to said second client non-server application when said first client non-server application terminates its execution; and

in response to said revocation object, un-registering, within said second client non-server application, said interest object of said first client non-server application corresponding to said event and refraining, by said second client non-server application, from transmitting said subsequently modified version of said original set of data associated with said event directly to said first client non-server application when said second client non-server application practices said event.

6. An integrated data communication and data access system adapted for intercommunicating between client applications, comprising:

a second client non-server application adapted to generate an original set of data, said second client non-server application including a second cache memory and adapted to set either a persistent storage state or a transient storage state or a memory storage state;

a database operatively connected to said second client non-server application,

said second client non-server application storing said original set of data in said second cache memory when said second client non-server application sets either said persistent storage state or said transient storage state or said memory storage state,

said second client non-server application storing said original set of data in said database when said second client non-server application sets either said persistent storage state or said transient storage state, and not storing said original set of data in said database when said second client non-server application sets said memory storage state;

a first client non-server application operatively connected to said database and to said second client non-server application, said first client non-server application retrieving said original set of data from said database and subsequently expressing interest in a subsequently modified version of said original set of data by generating and transmitting an interest object corresponding to an event;

a server operatively interposed between and connected to said first client non-server application and said second client non-server application,

said first client non-server application transmitting said interest object to said server,

said server re-transmitting said interest object to said second client non-server application,

said second client non-server application practicing said event and thereby generating a subsequently modified version of said original set of data in response to the practice of said event, said second client non-server application attempting to store said subsequently modified version of said original set of data in said second cache memory and in said database,

said second client non-server application storing said subsequently modified version of said original set of data in said second cache memory when said second client non-server application sets either said persistent storage state or said transient storage state or said memory storage state,

said second client non-server application storing said subsequently modified version of said original set of data in said database when said second client non-server application sets said persistent storage state, and not storing said subsequently modified version of said original set of data in said database when said second client non-server application sets either said transient storage state or said memory storage state,

said second client non-server application, responsive to said interest object, transmitting said subsequently modified version of said original set of data directly to said first client non-server application without routing the subsequently modified data through said server when said second client non-server application practices said event.

7. The integrated data communication and data access system of claim 6, wherein said server responds to a revocation object from said first client non-server application and transmits said revocation object to said second client non-server application when said first client non-server application terminates its execution, said second client non-server application not transmitting said subsequently modified version of said original set of data to said first client non-server application in response to said revocation object when said second client non-server application practices said event.

8. A data communication and data access system, comprising:

a first client application including,

a first application adapted to set a persistent storage state or a transient storage state or a memory storage state,

a first cache memory operatively connected to said first application and responsive to the storage state set by said first application,

first interface apparatus operatively interposed between said first application and said first cache memory adapted to coordinate a transfer of data between said first application and said first cache memory, and

first conversion apparatus operatively connected to said first cache memory and interfacing between a first operator of said first client application and said first cache memory adapted to receive data having a first format from said first operator and convert said data having said first format to data having a second format for storage in said first cache memory, said first conversion apparatus adapted to convert said data having said second format to said data having said first format for use by said first operator,

a second client application including,

a second application adapted to set a persistent storage state or a transient storage state or a memory storage state,

a second cache memory operatively connected to said second application and responsive to the storage state set by said second application,

second interface apparatus operatively interposed between said second application and said second cache memory adapted to coordinate a transfer of data between said second application and said second cache memory, and

second conversion apparatus operatively connected to said second cache memory and interfacing between a second operator of said second client application and said second cache memory adapted to receive data having a third format from said second operator and convert said data having said third format to said data having said second format for storage in said second cache memory, said second conversion apparatus converting said data having said second format to said data having said third format for use by said second operator;

a server operatively interconnected between the first application and the second application; and

a database operatively interconnected between the first cache memory and the second cache memory,

said first conversion apparatus receiving an original set of said data having said first format from said first operator and converting said original set of data having said first format into an original set of data having said second format,

said first application storing said original set of said data having said second format received from said first conversion apparatus into said first cache memory when said first application sets either said persistent storage state or said transient storage state or said memory storage state,

said first application storing storing said original set of said data having said second format received from said first conversion apparatus into said database when said first application sets either said persistent storage state or said transient storage state, said first application not storing said original set of said data having said second format into said database when said first application sets said memory storage state,

said second client application retrieving said original set of said data having said second format from said database and storing said original set of data having said second format in said second cache memory,

said second conversion apparatus converting said original set of data having said second format into an original set of data having a third format for use by said second operator,

said second operator expressing interest in a subsequently modified version of said original set of data having said third format by generating an interest object corresponding to an event,

said second application transmitting said interest object to said server,

said server re-transmitting said interest object to said first application,

said first application subsequently generating a subsequently modified version of said original set of data having a second format and attempting to store said subsequently modified version of said original set of data having said second format into said first cache memory and into said database,

said first application storing said subsequently modified version of said original set of data having a second format into said first cache memory when said first application sets either said persistent storage state or said transient storage state or said memory storage state,

said first application storing said subsequently modified version of said original set of data having a second format into said database when said first application sets said persistent storage state, but not storing said subsequently modified version of said original set of data having a second format into said database when said first application sets either said transient storage state or said memory storage state,

said first application responding to said interest object received from said server by transmitting said subsequently modified version of said original set of said data having said second format directly to said second application without routing said subsequently modified version of said original set of said data having said second format through said server,

said subsequently modified version of said original set of said data having said second format received by said second application being converted by said second conversion apparatus into a subsequently modified version of said original set of said data having a third format for viewing by said second operator.

9. The data communication and data access system of claim 8, wherein said subsequently modified version of said original set of data having said second format which is received by said second application is stored in said second cache memory when said first application or said second application sets either said memory storage state or said persistent storage state or said transient storage state, said second conversion apparatus converting said subsequently modified version of said original set of data having said second format into said subsequently modified version of said original set of data having said third format for viewing by said second operator.

10. In a data communication and data access system including a first client application which further includes a first application and a first cache memory and a first conversion unit, a second client application which further includes a second application and a second cache memory and a second conversion unit, a server operatively interconnected between the first application and the second application, and a database operatively interconnected between said first cache memory and said second cache memory, a method of data communication and data access, comprising the steps of:

(a) supplying, by a first operator, original data having a first format to said first conversion unit and converting, in said first conversion unit, said original data having said first format to original data having a second format, said first application and said second application adapted for setting a persistent storage state or a transient storage state or a memory storage state,

(b) storing, by said first application, said original data having said second format in said first cache memory when said first application sets either said persistent storage state or said transient storage state or said memory storage state;

(c) storing, by said first application, said original data having said second format in said database when the first application or the second application sets either the persistent storage state or the transient storage state but not storing said original data having said second format in said database when the first application or the second application sets the memory storage state;

(d) retrieving by said second application said original data having said second format from said database and converting, in said second conversion unit, said original data having said second format into original data having a third format for use by a second operator,

(e) in response to said original data having said third format, expressing interest in a modified version of said original data having said third format by transmitting an interest object from said second application to said server and then re-transmitting said interest object from said server to said first application;

(f) supplying, by said first operator, modified data having a first format to said first conversion unit and converting, in said first conversion unit, said modified data having said first format into modified data having a second format;

(g) storing said modified data having said second format in said first cache memory when said first application or said second application sets said persistent storage state or said transient storage state or said memory storage state,

(h) storing said modified data having said second format in said database when the first application or the second application sets the persistent storage state but not storing said modified data having said second format in said database when the first application or the second application sets either the transient storage state or the memory storage state; and

(i) in response to said interest object retransmitted from said server to said first application during step (e), transmitting said modified data having said second format from said first application directly to said second application without routing said modified data having said second format through said server.

11. The method of claim 10, wherein the retrieving and converting step (d) further comprises the steps of:

(d1) reading said original data having said third format from said second conversion unit and supplying said interest object pertaining to said original data having said third format to said second application.

12. The method of claim 11, further comprising the steps of:

(j) storing, by said second application, said modified data having said second format, in said second cache memory when said first application or said second application sets either said persistent storage state or said transient storage state or said memory storage state; and

(k) converting, in said second conversion unit, said modified data having said second format to modified data having a third format for use by said second operator.

Description

BACKGROUND OF THE INVENTION

The subject matter of the present invention relates to an integrated data communication and data access system, and more particularly, to a data communication system adapted for practicing an event in a first application, creating a data object by the first application during the practice of the event, and communicating between the first application and a cache memory and a database following the practice of the event by independently storing the data object in the cache memory and in the database during a persistant or transient storage state; and to a data access system adapted for independently accessing the database by a second application to retrieve the data object, determining an interest by the second application in subsequently created ones of the data object, expressing the second application's interest in the data objects by transmitting an interest object from the second application to the first application via a server application, and transmitting the subsequently created ones of the data object directly from the first application to the second application.

The "Description of the Preferred Embodiment" is divided into two parts: (1) Part 1 (Distributed Framework for Intertask Communication Between Workstation Applications) which is set forth in prior pending application Ser. No. 08/758,833 filed Dec. 4, 1996 and entitled "Distributed Framework for Intertask Communication Between Workstation Applications" and in prior pending provisional application Ser. No. 60/023,945 filed Aug. 19, 1996 and entitled "Distributed Framework for Inter-Process Communication Between Workstation Applications", and (2) Part 2 (Integrated Data Communication and Data Access System including the Application Data Interface) which is set forth in prior pending provisional application Ser. No. 60/023,689 filed Aug. 15, 1996 and entitled "Application Data Interface (ADI)".

Computer progams that operate with a network often have multiple programs operating concurrently. It is frequently necessary for information, such as events, to be transferred from one program to another, either within a single workstation or across a network of interconnected computer workstations. An operator at one of the workstations may process information by using different programs operating concurrently in the workstation or across the network of workstations. The operator may also retrieve information by using a multiple number of computer programs executing concurrently in the single workstation or across the network of interconnected workstations. It is therefore important that information be quickly and easily transferred between the multiple number of programs operating in the one or more interconnected workstations.

Windowing software technology is applied where it is important for an operator to display and interact with multiple programs executing concurrently in a computer system comprising one or more interconnected workstations. A "window" is defined to be a portion of a display screen, such as a cathode ray tube (CRT). The window covers less than the entirety of the screen. As a result, there may be a multiple number of windows on the screen at one time. Typically, the user moves a cursor around the screen by use of an input device known as a mouse or by use of multiple keys on a keyboard. The cursor can be moved from one window to another on the screen, and, when the cursor is present within a particular window on the screen, the user/operator is placed in communication with the application program which generated that particular window on the screen. As a result, the operator may access a multiple number of different application programs thereby accomplishing multiple tasks without having to load a new program each time a new task must be performed.

However, when concurrently accessing a multiple number of different application programs executing in a workstation or across a network of workstations, is is often necessary for a user/operator to transfer information from one windowed program executing in a first workstation to another windowed program executing in either the first workstation or in a second, different workstation connected to the first workstation across the network. Transferring information between programs operating in a windowing environment is disclosed in this specification; however, such a windowing environment is not necessary in order to practice the invention of this specification as claimed.

There are at least three conventional techniques for transferring information between concurrently operating programs in a computer system.

The first conventional technique is called "cut and paste". This comprises pointing to and selecting information such as text or data in one window to highlight it and thereby separate it from the remaining information in the window. The user presses a special button or key which moves the selected information to an area of memory specially designated by the operating system and known as the "paste memory" or "clipboard". The user then moves the cursor to another window which is adapted to receive the information. A "paste button" or command is invoked by the user to retrieve the stored information from the designated memory area and place it at the location of the cursor. Note that all steps of this process are carried out by the user.

The second conventional technique establishes a programmed connection between two programs, each of which may display information in a window. Both programs must be designed to respond to a predetermined input command that causes information to be shifted from one program to another. This operation may also be entirely under the control of the user and requires a user input in order to function. Each communication path between pairs of programs must be programmed into the code of both programs, which creates an inflexible system. It is also difficult to add new communication paths or to change existing communication paths.

The third conventional technique is described in U.S. Pat. No. 5,448,738 to Good et al issued Sep. 5, 1995, and in European Patent Application number 0 380 211 published on Aug. 1, 1990 and entitled "Method for Information Communication between Concurrently Operating Computer Programs" to William E. Good et al (hereinafter called "the Good et al disclosure"), the disclosures of which are incorporated by reference into the specification of this application. In the Good et al disclosure, the user interfaces with application programs through one or more window displays and an input device on a computer workstation. One or more information codes and one or more corresponding application programs are registered with a dispatcher program (otherwise known as a "server"). As a result, a list is formed in the dispatcher program, the list including a plurality of information codes and a corresponding plurality of application program identifiers. Then, when a first application program wants to send event information to another concurrently executing second application program, a template, which includes event information and a corresponding information code, is generated by the first application program and the template is transmitted by the first application program to the dispatcher program. The information code in the template from the first application program is compared with the information code in the list registered with the dispatcher program. If a match between information codes is found, the event information associated with the information code in the template is transmitted to the application program that is associated with the information code in the list registered with the dispatcher program.

The Good et al disclosure is similar to other conventional, prior art tools for enabling inter-process communication between application programs, all of which are based on "client-server techniques". Examples of such conventional tools include the "X Window System" and Sun's "Tooltalk". In the Good et al disclosure and the other conventional tools, when using the prior art client-server techniques, all of the data to be communicated between concurrently executing computer program applications must be routed through a server program (the "server program" being similar to the "dispatcher program" in the Good et al disclosure). If many concurrently executing program applications exist in the network, the server or dispatcher may have too many event messages to transmit at any one time. This results in slower throughput as well as increased network traffic. In addition, when using the prior art client-server technique, the user operator executing a first application program can send only certain preselected event information messages to a second application program. That is, the user can send only a fixed set of predefined event information messages which are allowed by the system network; he cannot define or customize his own event information messages for transmission to the second application program. For example, if a font size was changed in one application, using the conventional client-server technique (where all event messages must be routed through the server), there was no way to communicate the changed font size, changed in one application, to any other application in the network because the "changed font size" was not among the fixed set of predefined event information messages allowed for transmission from one application to another application in the network. In addition, when using the conventional client-server technique, particular event information data must always be communicated from a first computer program application to a server program and from the server program to a second program application. Yet, that server program may not know if any other program applications are interested in receiving that particular event data. As a result, when the server receives the particular event information data from the first program application,(the server must then determine if any other applications are interested in receiving that particular event data. If no other applications are interested in receiving the particular event data, the server program wasted its resources in handling the particular event data because it will never be communicated to any other application.

Furthermore, data communicated while using the conventional tools are poorly structured (forming "globs") and provide no mechanism for checking for errors in the data communicated. It is the responsibility of the application programs to interpret the data in the correct manner and handle error conditions. Therefore, when using the conventional tools, the ability of the application programmer to inter-communicate complex data structures between concurrently executing computer program applications is very limited.

As noted earlier, the conventional tools do not provide a mechanism which would allow application programmers to selectively extend or customize the type of events and/or data which could be inter-communicated between concurrently executing applications executing in one or more computer workstations. As a result, the absence of a sufficiently high level of programming abstraction in these conventional tools requires application programmers to be concerned with low level issues, such as data formats on various platforms and communication rendevous (such as, a known property name of a known window, as in the prior art "X Window System").

Finally, these conventional tools provide no easy way for end-users of applications to control the flow of data and visualize the connectivity between applications.

In addition, the conventional tools had a different interface relative to the invention of this application in connection with methods for dealing with events and persistant storage. When data was written into an executing first application, the writer of that data was required to take specific steps, during the introduction of that data, toward the communication that data to another second application. When the data was introduced to the first application, that data was always communicated to the second application via the dispatcher application; and when the receiving second application received that data from the dispatcher application, the receiving second application did not possess a fine "granularity" with regard to the type of data received. That is, the receiving second application could, for example, receive "well data"; however, the receiving second application could not receive a specific subset or type of that well data.

Therefore, a "new framework" was needed that would allow fast communication and sharing of complex data, allow strong typing of data structures, and provide a degree of extensibility when using application-defined data types and events. In addition, that "new framework" should also allow end users of workstation applications to visualize the connectivity network between workstation applications by enabling the end users sitting at those workstations to control the inter-process data communication between computer program applications which are concurrently executing in one or more computer workstation environments.

The above referenced "new framework" is disclosed in a prior pending application Ser. No. 08/758,833 filed Dec. 4, 1996 entitled "Distributed Framework for Intertask Communication Between Workstation Applications", to Shamim Ahmed and Serge J. Dacic (hereinafter called the "ITC Application"), the disclosure of which is incorporated by reference into this specification.

Although not disclosed in the "ITC Application", the "new framework" utilizes an underlying apparatus called the "Application Data Interface" disclosed in this specification. When the "Application Data Interface" is embodied in the Integrated Data Communication and Data Access System of the present invention, a first application of that System is allowed to independently inquire about the existance of certain newly created data in a database, independently of a second or third application concurrently executing in that System, for the ultimate purpose of possibly expressing interest in and receiving any subsequently created and updated versions of that data which may be generated by the second or third application of that System.

However, conventional systems do not allow a first application in the system to inquire about the existance of certain stored data independently of any other applications concurrently executing in the system. For example, if a conventional system includes concurrently executing first and second applications, if the first application is interested in inquiring about the existance of certain data, it must do so by querying the second application. The first application cannot inquire about the existance of that certain data independently of the second application.

Accordingly, there is a need for an integrated data communication and data access system, including at least a first and a second concurrently executing application program, that will allow the second application to store certain data in a cache memory and a database when the second application sets persistant or a transient storage state thereby allowing the first application to independently inquire about the existance of such certain data, independently of the second application, by querying the database for such certain data for the ultimate purpose of expressing interest in and receiving any subsequently modified versions of such certain data.

SUMMARY OF THE INVENTION

Accordingly, it is a primary object of the present invention to provide an integrated data communication and data access system which includes at least a first application and a second application concurrently executing in said system and which is adapted for allowing the second application to store certain data in a second cache memory and a database when the second application sets a persistant or a transient storage state thereby allowing the first application to independently inquire about the existance of such certain data, independently of the second application, by querying the database for such certain data for the ultimate purpose of expressing interest in and receiving any subsequently modified versions of such certain data.

It is a further object of the present invention to provide the above referenced integrated data communication and data access system which is additionally adapted for allowing the second application to store the certain data in the second cache memory but not in the database when the second application sets a memory storage state.

It is a further object of the present invention to provide the above referenced integrated data communication and data access system which further includes a first cache memory operatively connected to the first application and a first conversion means operatively connected to the first cache memory and interfacing between a first operator of the first application and the first cache memory for receiving data having a first format from the first operator and converting the data having the first format into data having a second format, the first application storing the data having the second format in the first cache memory and in the database when the first application sets the persistant or transient storage state, the second application independently inquiring about the existance of such data having the second format, independently of the first application, by querying the database for such data having the second format, expressing interest in such data having the second format, receiving any subsequently modified versions of such data having the second format, and storing the subsequently modified versions of such data having the second format in the second cache memory.

It is a further object of the present invention to provide the above referenced integrated data communication and data access system which further includes a second conversion means operatively connected to the second cache memory and interfacing between a second operator of the second application and the second cache memory for receiving such data having the second format from the second cache memory and converting such data having the second format into data having a third format, the data having the third format being presented to the second operator of said second application.

In accordance with these and other objects of the present invention, an integrated data communication and data access system in accordance with the present invention includes: a first application, a first cache memory operatively connected to the first application, and a first conversion unit operatively connected to the first cache memory and interfacing between a first operator of the first application and the first cache memory; a second application, a second cache memory operatively connected to the second application, and a second conversion unit operatively connected to the second cache memory and interfacing between a second operator of the second application and the second cache memory; a database operatively connected to the first cache memory and the second cache memory; and a server operatively connected to the first application and the second application.

In operation, the first operator practices an "event" and the practice of that "event" introduces data having a first format into the first conversion unit. The first conversion unit converts the data having the first format into other data having a second format. The first application receives the data having the second format and stores the data having the second format in the first cache memory and in the database when the first or second application sets a persistant or a transient storage state. On the other hand, the first application stores the data having the second format in the first cache memory but does not store such data in the database when a memory storage state is set. The second application queries the database for the data having the second format and the second conversion unit converts the data having the second format into other data having a third format, the data having the third format being presented to the second operator of the second application. The second operator introduces an interest object into said conversion unit thereby expressing interest in any "subsequently modified versions of the data" generated by the first application, but the interest object does not undergo conversion in the conversion unit. The second application transmits the interest object to the server and the server retransmits the interest object to the first application. The first conversion unit receives the interest object, but the interest object does not undergo conversion in the first conversion unit, and the interest object is presented to the first operator of the first application. The first operator repractices the same "event" and the repractice of that same "event" introduces the "subsequently modified versions of the data" having the first format into the first conversion unit. The conversion unit converts the "subsequently modified version of the data having the first format" into a "subsequently modified version of the data having the second format", and the Subsequently modified data of the second format is stored in the first cache memory. If the first application sets the persistant storage state, the "subsequently modified version of the data having the second format" will also be stored in the database. However, if the first application sets either the transient or the memory storage state, the "subsequently modified version of the data having the second format" will not be stored in the database.

The storage state rules are as follows: an original data set is stored in the cache memory and the database during the persistant or transient storage state, but any subsequently modified data, generated after the original data set is generated, will not be stored in the database during the transient storage state. In addition, both the original and the modified data will not be stored in the database during a memory storage state.

When the "subsequently modified version of the data having the asecond format" is stored in the first cache memory associated with the first application, that data will be transmitted directly from the first application to the second application without registering that data with the server. When the second application receives that data, the "subsequently modified version of the data having the second format" will be stored in the second cache memory, and such data having the second format will then be introduced into the second conversion unit. The second conversion unit will convert the "subsequently modified version of the data having the second format" into a "subsequently modified version of the data having a third format". As a result, the "subsequently modified version of the data having the third format" will be presented to the second operator of the second application for his consideration.

Further scope of applicability of the present invention will become apparent from the detailed description presented hereinafter. It should be understood, however, that the detailed description and the specific examples, while representing a preferred embodiment of the present invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become obvious to one skilled in the art from a reading of the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

A full understanding of the present invention will be obtained from the detailed description of the preferred embodiment presented hereinbelow, and the accompanying drawings, which are given by way of illustration only and are not intended to be limitative of the present invention, and wherein:

FIGS. 1 through 32 are presented in connection with the first part of this specification entitled the "Distributed Framework for Intertask Communication Between Workstation Applications", of which FIGS. 1-32 illustrate the following:

FIG. 1 illustrates a computer workstation having a display which includes one or more window displays representing the execution of one or more client application programs;

FIG. 2 illustrates a plurality of client application programs which display a corresponding plurality of window displays on one or a plurality of workstations similar to that shown in FIG. 1, each of the plurality of client applications being interconnected together by an intertask communication (ITC) apparatus which comprises a server program application and one or more individual client applications;

FIG. 3 illustrates a first workstation executing a first client application and a second workstation executing a second client application and also storing the server application software;

FIG. 4 illustrates a more detailed construction of the first client application (client 1 software) and the second client application (client 2 software) in the first and second workstations of FIG. 3;

FIG. 5 illustrates a more detailed construction of the ITC-Human Interface Code of FIG. 4;

FIGS. 6 through 13b illustrate a detailed construction and the functional operation of the ITC Framework (ITC Core) of FIG. 4;

FIGS. 14 through 25 illustrate a detailed construction of the Operator Interaction Display Software of FIG. 5,

FIG. 14 illustrating the status icons and the broadcast icon,

FIGS. 15a through 15e illustrating the event filter icon with its subwindow display, and

FIGS. 16-25 illustrate the use of these icons on a window display being displayed on a display screen of a workstation;

FIGS. 26 and 27 illustrate a detailed construction of the ITC HI Setup software of FIG. 5;

FIG. 26A illustrates a detailed construction of the "Build List of ITC Events" 80 which is illustrated in FIG. 26;

FIGS. 28 and 29 illustrate a detailed construction of the Send An Event Software of FIG. 5;

FIGS. 30 and 31 illustrate a detailed construction of the Receive An Event Software of FIG. 5;

FIG. 32 illustrates an Intertask Communication (ITC) Sessions Model referenced in the ITC Framework portion of the "Detailed Description of the Preferred Embodiment";

FIGS. 33 through 76 are presented in connection with the second part of this specification entitled the "Integrated Data Communication and Data Access System including the Application Data Interface", of which FIGS. 33-76 illustrate or include the following:

FIGS. 33 through 35 illustrate again the drawings of FIGS. 6, 8A, and 9A,

FIGS. 36 through 44 are presented for reference in conjunction with a general discussion of the concepts associated with the "Integrated Data Communication and Data Access System" of the present invention, and

FIGS. 45 through 76 are presented for reference in conjunction with a detailed discussion of the "Application Data Interface" which is embodied in the "Integrated Data Communication and Data Access System" of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

This specification is divided into two parts:

(1) a first part (Part 1) that reviews the structure and the functional operation of an invention entitled "Distributed Framework for Intertask Communication Between Workstation Applications" which is set forth in a prior pending application Ser. No. 08/758,833, filed Dec. 4, 1996 (hereinafter called the "ITC Application"), the disclosure of which is incorporated by reference into the specification of this application; the invention of the "ITC Application" describes how direct inter-task communications (ITC) are achieved between concurrently operating computer program applications executing in one or more computer workstations that provide a window display to an operator; and

(2) a second part (Part 2) in accordance with the present invention set forth below in this specification entitled "Integrated Data Communication and Data Access System including the Application Data Interface".

Part 1--a Distributed Framework for Intertask Communication Between Workstation Applications

The following description of the "Distributed Framework for Intertask Communication Between Workstation Applications" (hereinafter called the "ITC Application") is fully disclosed in the prior pending application Ser. No. 08/758,833, filed Dec. 4, 1996, already incorporated herein by reference.

Referring to FIG. 1, a computer workstation is illustrated which has a display that includes one or more window displays representing the execution of one or more client application programs.

In FIG. 1, a computer workstation 10 is illustrated. The workstation includes a monitor 12, a processor 14, a keyboard 16, and a mouse 18. The monitor 12 includes a cathode ray tube (CRT) that provides a display screen 12a. In FIG. 1, the display screen 12a has a plurality of windows 12b displayed thereon, each window 12b being displayed on the display screen 12a in response to the execution, within the workstation 10, of a separate client application program. As noted below in FIG. 2, each of the plurality of windows 12b provide a different display of wellbore-related data from which an operator can interpret whether or not underground deposits of hydrocarbons are present within an earth formation. An operator sitting at the workstation 10 will use the mouse 18 to select various ones of the windows 12b for viewing and/or manipulation or selection of the data in that window.

Referring to FIG. 2, a plurality of client application programs (hereinafter called "client applications") are illustrated which display a corresponding plurality of window displays on one of a plurality of workstations similar to the workstation 10 shown in FIG. 1 and which are interconnected together by an intertask communication (ITC) apparatus.

In FIG. 2, a plurality of client applications 20 are interconnected together by an intertask communication (ITC) apparatus 22. Recall that a "client application" is a computer program which is executing in the workstation 10 of FIG. 1 and which is responsible for displaying one of the windows 12b on the display screen 12a of the monitor 12 of the workstation 10 of FIG. 1. The ITC apparatus 22 of FIG. 2 allows each of the client applications 20 to communicate directly with one another. In general, as shown in FIG. 6, the ITC apparatus 22 is a generic term which includes a first client application and a second client application which are interconnected together in the manner shown in FIG. 6. The ITC apparatus 22 of FIG. 2 enables all of the client applications 20 to communicate directly and simultaneously with one another. As a result, events being practiced in one client application 20 can be viewed simultaneously in another client application 20. This functional capability will be discussed in more detail later in this specification.

Referring to FIG. 3, a system including a pair of interconnected workstations (each of which are similar to the workstation 10 of FIG. 1) is illustrated.

In FIG. 3, a first workstation 24 is interconnected to a second workstation 26. The first workstation 24 includes a processor 24a connected to a system bus 24d, a display 24b (similar to the display screen 12a of FIG. 1) connected to the system bus 24b, a memory 24c connected to the system bus 24d, and a user interface 24e (the mouse 18 and keyboard 16 of FIG. 1) connected to the system bus 24d. The second workstation 26 includes a processor 26a connected to a system bus 26d, a display 26b (similar to the display screen 12a of FIG. 1) connected to the system bus 26b, a memory 26c connected to the system bus 26d and a user interface 26e (the mouse 18 and keyboard 16 of FIG. 1) connected to the system bus 26d. The first workstation 24 is electrically or optically connected to the second workstation 26 via a communication link 28. The memory 24c of the first workstation 24 stores a first client application program called the "client 1 application software" 24c1, and the memory 26c of the second workstation 26 stores a second client application program called the "client 2 application software" 26c1. However, the memory 26c of the second workstation 26 also stores a server software 26c2. The server software 26c2 distributes interest objects between client applications. See the "dispatcher program" which is discussed in the Good et al disclosure (i.e.--in U.S. Pat. No. 5,448,738 entitled "Method for Information Communication between Concurrently Operating Computer Programs"), the disclosure of which has already been incorporated herein by reference. The client 1 application software 24c1, when executed by the processor 24a, generates a visual image on the display 24b which is similar to one of the client applications 20 shown in FIG. 2. Similarly, the client 2 application software 26c1, when executed by the processor 26a, generates a visual image on the display 26b which is similar to one of the other client applications 20 shown in FIG. 2. The function of the system shown in FIG. 3 will become apparent from a reading of the remaining parts of this specification.

Referring to FIG. 4, a more detailed construction of the client 1 application software 24c1 and the client 2 application software 26c1 of FIG. 3 is illustrated.

In FIG. 4, the client 1 application software 24c1 and the client 2 application software 26c1 each include: (1) a first set of software hereinafter known as the "ITC Human Interface Code" 32, and (2) a second set of software hereinafter known as the "ITC Framework (ITC Core) Code" 34. From a functional standpoint, an internal application code invokes the Human Interface Code 32, and the Human Interface Code 32 invokes the Framework Code 34. The ITC Human Interface code 32 and the ITC Framework Code 34 are discussed in greater detail later in this specification and the function of the Human Interface code 32 and the Framework Code 34 will become apparent from a reading of the remaining parts of this specification.

Referring to FIG. 5, a more detailed construction of the ITC Human Interface Code 32 of FIG. 4 is illustrated.

In FIG. 5, the Human Interface Code 32 of FIG. 4 is comprised of four parts: (1) an Operator Interaction Display Software 32d, (2) an ITC-HI Setup software 32a operatively connected to the Operator Interaction Display software 32d, (3) a Send An Event software 32b operatively connected to the ITC HI Setup software 32a, and (4) a Receive An Event Software 32c operatively connected to the ITC HI Setup software 32a. The ITC Framework (ITC Core) code 34 will be operatively connected to both the Send an Event software 32b and the Receive an Event software 32c. The Operator Interaction Display software 32d will generate displays of icons on the windows 12b of the display screen 12a, and it will also display, on the windows 12b, the "event information" which is requested from other client applications (this will be discussed later in this specification).

In operation, referring to FIG. 5, an operator at workstation 10 of FIG. 1, which is executing a particular client application, will view a variety of icons on a window display 12b on the display screen 12a of the FIG. 1 workstation for that particular client application. The operator will click "on" one or more of the icons thereby allowing an interest object in particular "event information" to be transmitted from the particular client application (e.g.--from the client 1 application 24c1 of FIG. 3) to other client applications (e.g.--client 2 application 26c1 of FIG. 3) via the server 26c2. The operator interaction display software 32d of FIG. 5 will display the window display 12b and the one or more icons in the window display 12b on the display screen 12a of the FIG. 1 workstation. When the operator clicks "on" the one or more icons in the window display 12b, the operator interaction display software 32d will inform the ITC-HI Setup Software 32a, and the ITC-HI Setup Software 32a will drive the Send An Event software 32b. The Send An Event Software 32b will instruct the ITC-Framework Code 34 of the particular client application (e.g.--client 1 application) to send the interest object in the particular event information to the other client applications (e.g.--client 2 application) via the server 26c2. When the other client applications generate the requested event information, the other client applications will send the requested event information directly to the ITC Framework Code 34 of the particular client application without passing through and registering with the server 26c2. When the requested event information is received by the particular client application (e.g.--client 1), the ITC Framework Code 34 of the particular client application will, in turn, inform the Receive An Event Software 32c of the particular client application. The Receive An Event Software 32c of the particular client application will inform the ITC-HI Setup Software 32a of the particular client application that the requested event information has been received from another client application. The ITC HI Setup Software 32a of the particular client application will, in turn, instruct the Operator Interation Display Software 32d of the particular client application to display the requested "event information" on the display screen 12a of the workstation 10 of FIG. 1.

Each of these four parts of the Human Interface Code 32 will be discussed later in this specification.

Referring to FIGS. 3, and 6 through 13b, a functional operation of the ITC Framework (ITC Core) Code 34 of each client application, such as the client 1 application 24c1 and the client 2 application 26c1, is illustrated.

Each client application includes the ITC Framework (ITC Core) Code 34. For example, the client 1 application software 24c1 and the client 2 application software 26c1 of FIG. 3 each include an ITC Framework Code 34. The ITC Framework code 34 associated with any particular client application interacts functionally with the server 26c2 and the ITC Framework code 34 associated with each other client application. For example, the ITC Framework code 34 of the client 1 application 24c1 in the first workstation 24 of FIG. 3 interacts functionally with the server software 26c2 and the ITC Framework code 34 of the client 2 application software 26c1 in the second workstation 26. The Framework code 34 of a first client application 24c1 will transmit interest objects to the server 26c2; it will transmit event information associated with an event "X" to the Framework code 34 of a second client application 26c1; and it will receive event information associated with an event "X" from the Framework code 34 of the second client application 26c1. This functional interaction between the Framework code 34 of one client application 24c1 and the server 26c2 and the Framework code 34 of other client applications 26c1 is discussed in further detail in the following paragraphs with reference to FIGS. 3 and 6 through 13b of the drawings.

In FIGS. 3 and 6, referring initially to FIG. 6, a high level schematic for distribution of events and interests is illustrated.

In FIG. 3, note the location of the client 1 application software 24c1 in the first workstation 24, and note the location of the client 2 application software 26c1 and the server software 26c2 in the second workstation 26.

In FIG. 6, a Client Application 1 24c1 (hereinafter called "Application 1") is interconnected to a Client Application 2 26c1 (hereinafter called "Application 2"), both Application 1 and Application 2 being connected to an ITC server 26c2. The "Client Application 1" 24c1 of FIG. 6 represents the client 1 application software 24c1 of FIG. 3, the "Client Application 2" 26c1 of FIG. 6 representing the client 2 application software 26c1 of FIG. 3, and the ITC server 26c2 of FIG. 6 representing the server software 26c2 of FIG. 3. When the Client Application 1 24c1 of FIG. 6 is executing in the first workstation 24 of FIG. 3, a window display (similar to one of the window displays 12b of FIG. 1) will appear on the display screen of the monitor of the first workstation 24. Similarly, when the Client Application 2 26c1 of FIG. 6 is executing in the second workstation 26 of FIG. 3, another window display (similar to one of the window displays 12b of FIG. 1) will appear on the display screen of the monitor of the second workstation 26. The window displays appearing on both monitors of the first and second workstations 24 and 26 could be any of those shown in FIG. 2.

In FIG. 6, assume that the Client Application 1 24c1 ("Application 1") is executing a first client application. In addition, assume that the Client Application 2 26c1 ("Application 2") is executing a second client application and, during the execution of the second client application by Application 2, certain "event information" will be generated by Application 2.

The term "event information" and/or the term "event" will be defined in the next three paragraphs by way of the following three examples.

For a first example, during the execution of the second client application by Application 2 at workstation 26, the operator sitting at the Workstation 26 may use the mouse 18 of FIG. 1 to place a cursor over one of the windows 12b of FIG. 1 and to thereby select certain information in that window 12b. The "selection" of certain information on that window 12b by Application 2 at workstation 26 may involve either dragging the cursor or deleting information or creating information. The "selection" of that certain information in that window 12b would be an "event" and that event would generate "event information". Application 1 may be interested in receiving that event information.

For a second example, Application 1 is being executed in France and it involves an examination of the geology of the earth. Application 2 is being executed in Houston and it involves a petrophysical application that is examining a pressure in a wellbore. There is nothing in common between Application 1 and Application 2 except for one one parameter: the pressure at a certain depth in the earth. The Application 1 may want to examine the pressure v. depth curve being generated in Application 2. Therefore, the pressure v. depth curve in Application 2 and any changes made thereto by an operator at the second workstation 26 would constitute "event information". Application 1 would be interested in receiving that event information.

For a third example, called "cursor tracking", Application 1, executing in the first workstation 24 of FIG. 3, is displaying a map having x, y, and z coordinates and an operator at the first workstation 24 can move a cursor across the map which would generate x, y, and z "event information". However, Application 2, executing the second workstation 26 of FIG. 3, is viewing a three-dimensional "cube" representation of an underground reservoir and Application 2 may be interested in receiving the x, y, and z "event information" from Application 1 whenever that event information is generated by Application 1. Therefore, when the operator at the first workstation 24 executing Application 1 moves the cursor across the map, the x, y, and z "event information" is generated from Application 1. If Application 2 previously expressed an interest in receiving that "event information" and when the event information is generated by Application 1, the Application 1 in the first workstation 24 would send that "event information" to Application 2 in the second workstation 26.

In FIG. 6, when Application 1 24c1 is executing the first client application, assume that Application 1 is interested in receiving certain "particular event information" from Application 2 26c1 when Application 2 generates that particular event information. In that case, Application 1 24c1 generates an "interest object" signal (which is propagated along line 36 in FIG. 6) from Application 1 24c1 to the ITC server 26c2. The server 26c2 informs Application 2 26c1 of the Application 1 interest in the particular event information by re-propagating the aforementioned "interest object" signal from the server 26c2 to the Application 2 26c1 (along line 38 in FIG. 6). The interest object signal from Application 1 contains an identifier which uniquely identifies Application 1. Therefore, when Application 2 receives the interest object signal (from line 38 in FIG. 6), Application 2 26c1 knows that Application 1 24c1 was interested in receiving the "particular event information" when the particular event information is generated by Application 2. As a result, when Application 2 generates the "particular event information" (i.e.--the operator at workstation 26 selects something by placing the mouse 18 in a window 12b and depressing a key on the mouse), since Application 2 knows that Application 1 is interested in receiving the particular event information, Application 2 will send that particular event information "directly" to Application 1 (via line 40). That is, the particular event information will not be sent from Application 2 26c1 to the server 26c2 (via line 38) and from the server 26c2 to Application 1 24c1 (via the line 36). Because the server 26c2 is not involved in the transfer of the particular event information from Application 2 to Application 1, valuable processing time is saved. As a result, the "Distributed Framework for Intertask Communication Between Workstation Applications" of the present invention is "extensible". That is, for any particular client application program executing in a workstation as represented by one of the windows 12b being displayed in FIG. 1, an application developer can define: (1) the type of events that the particular client application will receive from another concurrently executing client application, and (2) the type of data associated with those events that will be received from the other client application whenever those events are transmitted from the other client applications.

In FIG. 7, a flowchart of interest registration and distribution is illustrated. This flowchart discusses some of the concepts discussed above with reference to FIG. 6. In FIG. 7, when Client Application 1 24c1 wants to register an interest in an event (i.e.--Application 1 wants to register an interest in an event because it wants to receive information from one or more other client applications when the other client applications practice or execute the event), a number of process steps are practiced by Application 1 24c1, the server 26c2, and Application 2 26c1:

1. In FIG. 7, block 24c1(a), the Client Application 1 24c1 ("Application 1") includes two parts: (1) a first client application ("client application 1"), and (2) an Intertask Communication (ITC) client ("ITC client"). When Application 1 is executing the first client application and if the first client application requires information concerning an event which will hereinafter be called "event X", the first client application will register an interest in event X with the ITC client by sending an "interest object" to the ITC client. The interest object contains an "event token".

2. In FIG. 7, block 24c1(b), the ITC client stores certain event tokens. When the ITC client receives the interest object from the first client application, the ITC client will verify the event token present in the interest object by locating a match between the event token in the interest object with an event token catalogued in a database. When a match between event tokens is located, the ITC client will "register an application callback"; that is, the ITC will send an acknowledgement signal back to the first client application.

3. In FIG. 7, block 24c1(c), the ITC client will then send an "interest object" signal to the ITC server 26c2.

4. In FIG. 7, block 26c2(a), the ITC server will receive the interest object signal from the ITC client and, in response thereto, the ITC server will register within itself (i.e., the ITC server will store within itself) data or information regarding the interest in event X which the "first client application" of "Application 1" had previously generated. Recall that the first client application of Application 1 previously indicated (by sending the interest object signal to the ITC server) that it wants to receive certain information from the other client applications that is generated when the "event X" is executed or practiced by the other client applications.

5. In FIG. 7, block 26c2(b), when the ITC server registers within itself the information regarding the first client application's interest in receiving the event X information from other client applications pursuant to block 26c2(a), the ITC server will broadcast to all such other client applications such first client application's interest. As a result, all the other client applications (i.e.--all the other client application programs being executed in all of the workstations in the network of workstations) will know that the first client application of Application 1 24c1 is interested in receiving certain specific information from the other client applications, the specific information being generated from the other client applications only when the "event X" is executed or practiced by the other client applications.

6. In FIG. 7, blocks 24c1(a), 24c1(b), . . . , and 24c1(N), all of the other client applications ("client application 2" 26c1(a), "client application 3" 26c1(b), . . . , and "client application N" 26c1(N)) will register therein (that is, store therein) the first client application's interest in receiving information regarding "event X" whenever any one or all of client application 2, client application 3, . . . , or client application N practice or execute the "event X".

In FIGS. 8a-8b, another flowchart of interest registration and distribution (which will discuss concepts similar to the concepts discussed above in connection with the flowcharts of FIGS. 6 and 7) is illustrated. In the flowchart of FIGS. 8a-8b, the "client application 1" 24c1 ("Application 1") is shown to be communicating with the server 26c2 and the "client application 2" 26c1 ("Application 2") as previously illustrated in FIGS. 6 and 7. However, in addition, in FIGS. 8a-8b, two other client applications are illustrated: "client application 3" 42 ("Application 3") and "client application 4" 44 ("Application 4"). In operation, referring to FIGS. 8a-8b, assume for purposes of discussion that Application 1, Application 2, Application 3, and Application 4 represent client application programs which are executing in four (4) different workstations similar to the workstation of FIG. 1. Assume further that each of the four applications (Application 1 through Application 4) generate a window display at their respective workstations similar to the window display 12b shown in FIG. 1. Assume further that the Application 1 of FIG. 8a is represented by the "client 1 software" 24c1 in FIG. 3, the Application 2 of FIG. 8a is represented by the "client 2 software" 26c1 in FIG. 3, and the server 26c2 of FIG. 8a is represented by the "server software" 26c2 in FIG. 3. In FIGS. 8a-8b, Application 1 24c1 registers an interest in an ITC event called "event X" (the actual mechanics behind the registration of that interest will be better understood with reference to FIG. 14). An interest object is sent from Application 1 24c1 to the server 26c2 via line 46 in FIG. 8a. When the interest object is received by the server 26c2, the server 26c2 will register, within itself, the interest from Application 1 24c1 in event X. The server 26c2 will then re-distribute the interest object to: "Application 2" 26c1 via line 48, "Application 3" 42 via line 50, and "Application 4" 44 via line 52. When the server 26c2 re-distributes the interest object from Application 1 to the other client applications, Applications 2, 3, and 4, the other client applications (Applications 2, 3, and 4) will register within themselves Application 1's interest in the event X.

In FIGS. 9a-9b, a high level schematic of event propagation using peer to peer communication is illustrated. Recall from FIGS. 8a-8bthat Application 1 24c1 transmitted an interest object signal to the server 26c2 and the server 26c2 redistributed that interest object signal to Application 2 26c1. The interest object signal (which identifies Application 1 as being its originator) was registered in Application 2 as originating from Application 1 and it expressed an interest by Application 1 in certain specific information which would be generated by Application 2 when an "event X" is practiced or executed by Application 2. As a result, in FIGS. 9a-9b, since the interest object signal previously sent to Application 2 by the server 26c2 identified Application 1 as being the requestor of such specific information concerning "event X", when Application 2 26c1 practices or executes the "event X", the aforesaid certain specific information concerning the execution or practice of "event X" will be sent directly from "Application 2" 26c1 to "Application 1" 24c1 (that is, the aforesaid certain specific information will not be transmitted from Application 2 to the server 26c2 and from the server 26c2 to Application 1; the server 26c2 has been bypassed).

The transmission of the aforementioned certain specific information (concerning the practice by Application 2 of event X) directly from Application 2 to Application 1, without passing through and registering with the server, is an improvement over the Good et al disclosure of the prior art, referenced in the background section of this specification. Recall that, in the Good et al disclosure, all of the data to be communicated between concurrently executing computer program applications must be routed through an intervening server program or dispatcher program.

In FIGS. 10a-10b, a high level schematic depicting the multi-casting of event information from Application 2 to other multiple interested client applications is illustrated.

Referring briefly to FIGS. 8a-8b, recall that an interest object was sent from Application 1 24c1 to the server 26c2 via line 46 in FIG. 8a. Recall further that, when the interest object was received by the server 26c2, the server 26c2 registered, within itself, the interest from Application 1 24c1 in event X. The server 26c2 then re-distributed the interest object to: "Application 2" 26c1 via line 48, "Application 3" 42 via line 50, and "Application 4" 44 via line 52. However, now that the interest object, in "event X", was re-distributed from the server 26c2 to Applications 2, 3, and 4, if any one or all of Applications 2, 3, and/or 4 practice or execute the "event X", the responsible Application (2, 3, and/or 4) will transmit information concerning the "event X" directly back to the requestor, which is Application 1 24c1, without re-registering with or passing through the server 26c2 (the server 26c2 remains idle).

Therefore, in FIGS. 10a-10b, assume that the requestor of event X was both "Application 1" 24c1 and "Application 4" 44 (Application 1 and Application 4 both previously sent an interest object in "event X" to the server 26c2, and the server 26c2 redistributed that interest object in event X to Application 2). Therefore, Application 2 knows that Applications 1 and 4 are interested in receiving information concerning the practice of "event X". As a result, when "Application 2" 26c1 practices or executes the "event X", information concerning the execution of "event X" will be sent directly from Application 2 to both "Application 1" 24c1 and "Application 4" 44 (that information regarding the execution of event X will not re-register with or be routed through the server 26c2 and, as a result, the server 26c2 will be bypassed).

In figures 11a-11b, a high level schematic showing "interest revocation" is illustrated. Assume that Client Application 124c1 (Application 1) previously registered an interest in event X with the server 26c2 (by sending an interest object to the server), and then the server 26c2 redistributed that interest object in event X to Client Application 2 26c1 (Application 2), Client Application 3 42 (Application 3), and Client Application 444 (Application 4). Then, assume that Application 1 wants to revoke its interest in "event X". In order to revoke its interest in "event X", the Application 1 will send a "revocation object" to the server 26c2 (via line 46 in FIG. 11), the "revocation object" representing Application 1's indication to other client applications that is no longer wants to receive any information concerning the practice or execution, by other applications, of the "event X". In response to the receipt of the revocation object, the server 26c2 un-registers, within itself, Application 1's interest in receiving information regarding the execution, by other client applications, of "event X" when event X is practiced by other applications. Then, the server 26c2 re-distributes the revocation object, originating from Application 1, to all the other client applications; that is, in figure 11a, the server 26c2 re-distributes the revocation object to Application 2 (via line 48), Application 3 (via line 50) and Application 4 (via line 52). When the other client applications (Applications 2, 3, and 4) receive the "revocation object", the other client applications (Applications 2, 3, and 4) will un-register Application 1's interest in "event X". As a result, information concerning the practice or execution, by the other Client Applications 2, 3, or 4, of event X, will no longer be sent to Application 1.

In FIGS. 12a-12b, a high level schematic of implicit interest revocation for a terminated client is illustrated. Assume that Application 1 24c1 dies or terminates while it has active interests outstanding. Recall that Application 1 has active interests outstanding because Application 1 previously transmitted an interest object in "event X" (and perhaps other events) to the server 26c2 and the server 26c2 previously redistributed that interest object in event X, and other events, to the other client applications, "Application 2" 26c1, "Application 3" 42, and "Application 4" 44. In FIGS. 12a-12b, if Application 1 dies or terminates, the server 26c2 will notice Application 1's termination. When the server 26c2 notices the termination of Application 1 24c1 (the Application 1 program ceases to execute), the server 26c2 will un-register, within itself, all of the outstanding interests which Application 1 previously sent to the server 26c2 (via line 46). Then, the server 26c2 will distribute a "revocation object" corresponding to all of Application 1's outstanding interests in all events to all other client applications, that is, to "Application 2" 26c1, "Application 3" 42, and "Application 4" 44 in FIG. 12. When the other client applications (Applications 2, 3, and 4) receive the revocation object from the server 26c2 associated with all of Application 1's outstanding interests in all events, the other client applications (Applications 2, 3, and 4 in FIG. 12) will un-register all of the interests in all events which "Client Application 1" 24c1 had previously transmitted to Applications 2, 3, and 4 via the server 26c2.

In FIGS. 13a-13b, a high level schematic showing the distribution of outstanding interests in a new client application is illustrated. Assume now that a new client application, "Client Application 5" 50 ("Application 5"), in FIG. 13a, begins execution in a workstation in the network of workstations, similar to the workstation 10 of FIG. 1. When the Application 5 program executes, a window would be displayed on the workstation similar to the window displays 12b of FIG. 1. When Application 5 begins to execute, Application 5 will register itself with the server 26c2 in FIG. 13 by sending a "registration signal" (via line 52 in FIG. 13) from the "Application 5" 50 to the server 26c2. In response to the "registration signal", the server 26c2 will register, within itself, the existance of the new client application, "Application 5" 50. Assume now that "Application 2" 26c1, "Application 3" 42, and "Application 4" 44 in FIG. 13 previously sent to the server 26c2 an "interest object" in an event, called "event X", and perhaps other events. In that case, after the server 26c2 registers within itself the existance of the new client "Application 5", the server 26c2 will redistribute the interest objects originating from all the other client applications (Applications 2, 3, and 4) to the new client "Application 5" (via line 54 in FIG. 13a). In the example of FIG. 13a, the server 26c2 will redistribute to Application 5: (1) the Application 2's previously expressed interest in event X and other events, (2) the Application 3's previously expressed interest in event X and other events, and (3) the Application 4's previously expressed interest in event X and other events (hereinafter called "previously expressed interests"). When new client "Application 5" 50 receives the previously expressed interests (i.e.--the interest objects) in event X and other events (which originated from Application's 2, 3, and 4) from the server 26c2, the "Application 5" will register, within itself, the previously expressed interests. When such previously expressed interests (i.e.--the interest objects) from Applications 2, 3, and 4 are registered within Application 5, the Application 5 will know that Applications 2, 3 and 4 require certain specific information regarding the execution and/or practice of the "event X" and other events. As a result, when the event X or other events are executed by Application 5, the Application 5 will send that certain specific information directly to Applications 2, 3, and 4 (that certain specific information will not pass through and register with the server 26c2 like it did in the Good et al disclosure).

Referring to FIGS. 14 through 25, a detailed discussion and a functional operation of the Operator Interaction Display Software 32d of FIG. 5 is illustrated.

In the above paragraphs, the functional operation of the ITC Framework 34 in FIG. 4 was discussed in connection with the client 1 application software and the client 2 application software 24c1 and 26c1 stored in the workstations of FIG. 3. Recall that the ITC Framework 34 of the client application 1 24c1 in FIG. 6 sent any requests for event information (associated with "event X") to the server 26c2, whereupon the server 26c2 sent that request for event information to client application 2 26c1. However, when the client application 2 practices or executes the "event X", the event information associated with event X was sent directly from client application 2 to client application 1 (via line 40 in FIG. 6) without passing through or registering with the server 26c2.

However, the operator sitting at the second workstation 26 in FIG. 3 can decide how much, if any, of the event information associated with "event X" will be transmitted from the second workstation 26, and the operator sitting at the first workstation 24 in FIG. 3 can decide how much, if any, of the event information associated with "event X" will be received in the first workstation 24.

The operators can make that decision and act upon that decision by utilizing certain "icons" which appear within each window display (12b of FIG. 1) on the display screen (12a of FIG. 1) of their particular workstation (10 of FIG. 1). For example, the operator at a workstation can click on a first icon and enable the transmission or reception of all event information to and from his client application, or the operator can click on a second icon and completely disable the transmission or reception of all event information to or from his client application, or the operator can click on a third icon and selectively choose how much of what kind of event information will be transmitted from or received into his client application.

The following paragraphs will describe each icon and its function. The icons will appear at the bottom right hand corner of each window display (12b of FIG. 1) on the display screen (12a of FIG. 1) of the workstation 10. There are three main types of icons: the status icon 60, the broadcast icon 62, and the event filter icon 64. There are three types of status icon: the open state icon 60a, the closed state icon 60b, and the locked state icon 60c.

In FIG. 14, the status icons 60 and the broadcast icon 62 are illustrated. The status icons 60 include the open state status icon 60a, the closed state status icon 60b, and the locked state status icon 60c. Each of these icons will be discussed below.

Open State Status Icon 60a of FIG. 14

The open state status icon 60a is accessible to an operator and it will appear on the bottom right hand corner of a window display (similar to window display 12b of FIG. 1). The operator sitting at a workstation (like workstation 24 or 26 in FIG. 3) would locate a window display (12b of FIG. 1) on the display screen (12a of FIG. 1) and click on the open state status icon 60a which appears at the bottom right hand corner of the window display 12b. When the operator clicks on the open state status icon 60a of a window display 12b for a particular client application, that particular client application is open and it will receive all event information from other client applications; furthermore, that particular client application is open and it will transmit all event information to other client applications. For example, an operator may change a font size (which is an "event" that generates "event information"). If the open state status icon 60a is clicked "on" by the operator for a particular client application program, the font size change event information will be transmitted to all the other interested client applications that requested the font size change event information (via an interest object in the font size change event sent from the other client applications to the particular client application by way of the intervening server).

For example, if an operator sitting at the workstation 24 of FIG. 3 clicks on the open state status icon 60a on the window display 12b of FIG. 1 for the client 1 application 24c1 of FIG. 3, the client 1 application 24c1 will receive all requested event information from the client 2 application 26c1 of FIG. 3, and the client 1 application will transmit all requested event information to the client 2 application 26c1.

Closed State Status Icon 60b of FIG. 14

The closed state status icon 60b is accessible to an operator and it will appear on the bottom right hand corner of a window display (similar to window display 12b of FIG. 1). The operator sitting at a workstation (like workstation 24 or 26 in FIG. 3) can locate a window display (12b of FIG. 1) on the display screen (12a of FIG. 1) and click on the closed state status icon 60b which appears at the bottom right hand corner of the window display. When the operator clicks on the closed state status icon 60b of a window display 12b for a particular client application, that particular client application is closed and it will not receive any event information from other client applications, and that particular client application is closed and it will not transmit any event information to other client applications.

For example, if an operator sitting at the workstation 24 of FIG. 3 clicks on the closed state status icon 60b on the window display 12b of FIG. 1 for the client 1 application 24c1 of FIG. 3, the client 1 application 24c1 will not receive any requested event information from the client 2 application 26c1 of FIG. 3, and the client 1 application will not transmit any requested event information to the client 2 application 26c1.

Locked State Status Icon 60c

The locked state status icon 60c is accessible to both an operator and to the programmer of a particular client application. The locked state status icon 60c will appear at the bottom right hand corner of a window display (12b of FIG. 1) of the particular client application. In some cases, the operator at a workstation may click "on" the open state status icon 60a in a window display 12b for the particular client application. However, the application programmer may have previously decided that, for the aforementioned particular client application, absolutely no event information can be transmitted from or received in that particular client application. As a result, the application programmer, that programmed the particular client application, may have required (internally within the particular client application code) that the particular client application be closed (as if the closed state status icon 60b were clicked "on"). In that event, the locked state status icon 60c will appear to click "on", by itself, in response to the requirement to close the particular client application, which requirement would be placed inside the particular client application code. An unstable state could cause the locked state status icon 60c to automatically click "on".

However, the operator could also click "on" the locked state status icon 60c. When the locked state status icon 60c is clicked "on,", this is equivalent to clicking "on" the closed state status icon 60b. That is, when the locked state status icon 60c is clicked "on", event information will not be received by a particular client application from other client applications (via line 40 in FIG. 6), event information will not be sent from the particular client application to other client applications, and an interest object associated with a particular event will not be send by the particular client application to the server 26c2 (via line 36 in FIG. 6) for further transmission to other client applications (via line 38 in FIG. 6).

Broadcast Icon 62

The broadcast icon 62 will appear at the bottom right hand corner of a particular window display (12b of FIG. 1) which is generated by a particular client application program, such as client 1 or client 2 of FIG. 3, executing within a workstation (10 of FIG. 1). Assume that, for that particular client application program, the closed state status icon 60b has been clicked "on" for a period of time. A plurality of newly created events (such as, changes to font size, changes to color, or dashed lines) which were generated during that period of time will not be transmitted by the particular client application to other interested client applications executing in the subject workstation or other workstations in the network of workstations. However, when the broadcast icon 62 is clicked "on" within the window display (12b) by an operator sitting at the workstation (10 of FIG. 1) using the mouse (18 of FIG. 1), all of the plurality of newly created events in the particular client application (12b), which were generated by an operator at the workstation 10 during the aforementioned period of time when the closed state status icon 60b was clicked "on", will be transmitted simultaneously from the particular client application to all other "interested client applications" executing in the network of workstations (the words "interested client applications" indicating that "interest objects" in the newly created events were previously transmitted from the other client applications to the server 26c2 and from the server 26c2 to the particular client application).

In FIGS. 15a through 15e, the Event Filter icon 64 is illustrated. The event filter icon 64 will be discussed in the following paragraph.

Event Filter Icon 64

In FIG. 5, recall that each client application, such as the client 1 application 24c1 and the client 2 application 26c1 of FIG. 3, include an ITC-HI Setup software 32a (FIG. 5). The ITC-Setup software 32a includes a coded and stored "list of events" and a "list of functions" corresponding, respectively, to the "list of events" (this list of events and corresponding list of functions will be discussed in greater detail in this specification with reference to FIG. 26 of the drawings).

Therefore, when a particular client application (such as the client 1 or client 2 application of FIG. 3) sends an interest object in an "event X" to another client application via the server 26c2 for the purpose of receiving event information from the other client applications regarding the practice of that event X, the "event X" must, of necessity, be one of the events in the "list of events" (of FIG. 26) coded within the ITC Setup Software 32a of FIG. 5 for that particular client application.

Similarly, if a particular client application intends to send "event information" to other client applications that is associated with the practice by the particular client application of a "particular event", that "particular event" must be one of the events stored in the "list of events" (of FIG. 26) coded within the ITC Setup Software 32a of FIG. 5 for that particular client application.

Consequently, since each particular client application is said to be "interested" in receiving a plurality of "event information" associated with a plurality of events from other client applications, the plurality of events are stored in the "list of events" coded within the ITC Setup software 32a (see FIG. 26 for the "list of events") for said each particular client application. Similarly, since each particular client application will send "event information" associated with a plurality of events to other interested client applications, those plurality of events are stored in the "list of events" coded within the ITC Setup software 32a.

However, by using the "Event Filter" icon 64 of FIG. 15, an operator or user, monitoring the particular client application on a window display (12b of FIG. 1) at his workstation (10 of FIG. 1), can selectively decide how many of the plurality of events in the list of events coded within the ITC Setup software 32a he will transmit to other client applications via the server 26c2 and how many of the plurality of events in the list of events coded within the ITC Setup software 32a he will receive from the other client applications via the server 26c2.

In FIGS. 15a through 15e, the event filter icon 64 of FIGS. 15a and 15b will be located at the bottom right hand corner of each window display (12b) on the display screen (12a) of a workstation (10). As shown in FIG. 15b, when the operator at the workstation (10) uses the mouse 18 to click "on" the event filter 64 which appear on a window display 12b, a subwindow display 64a shown in FIGS. 15c will be presented to the operator on the display screen (12a).

In FIG. 15c, the subwindow display 64a (which appears on the display screen 12a of the workstation 10 when the event filter icon 64 in a window display 12b for a particular client application is clicked "on" by an operator) includes three columns: (1) the send column 64a1, (2) the receive column 64a2, and (3) the message or event column 64a3. A plurality of messages or events 64a3A are printed under the message column 64a3. These plurality of messages or events 64a3A represent a plurality of events for which: (1) a corresponding plurality of event information could be received from other client applications, and (2) a corresponding plurality of event information could be sent or transmitted to other client applications. A plurality of send boxes 64a1A appear under the send column 64a1, and a plurality of receive boxes 64a2A appear under the receive column 64a2. For each of the plurality of messages 64a3A, there is one send box 64a1A and one receive box 64a2A. An operator would use the mouse 18 of FIG. 1 to click within a send box and/or a receive box for each of the plurality of events 64a3A.

If the operator clicked within a send box 64a1A for a particular message or event (one of events 64a3A in FIG. 15c) for a particular client application, "event information" associated with that particular event will, in fact, be sent from the particular client application to the other client applications that registered an interest in the particular event with the particular client application; however, if the operator did not click within the send box 64a1A for that particular event 64a3A for that particular client application, "event information" associated with that particular event 64a3A will not be sent from the particular client application to the other client applications that registered an interest in the particular event with the particular client application.

In addition, If the operator clicked within a receive box 64a2A for a particular message or event 64a3A for a particular client application, "event information" associated with that particular event 64a3A will, in fact, be received from other client applications in response to the registry by the particular client application with the other client applications in that particular event; however, if the operator did not click within the receive box 64a2A for that particular event 64a3A for that particular client application, "event information" associated with that particular event 64a3A will not be received from the other client applications in response to the registry by the particular client application with the other client applications in that particular event.

In FIGS. 15d and 15e, consider the examples of the use of the event filter 64 and the subsequent use of the subwindow display 64a for that event filter 64 illustrated in FIGS. 15d and 15e.

In the example of FIG. 15d, four events appear under the events column 64a3 of the subwindow display 64a of the event filter 64 (appearing in a window display 12b on the display screen 12a of a workstation 10 for a particular client application): (1) change color, (2) change thickness, (3) change shape, and (4) cursor tracking. Note, for each of these events, whether the send boxes 64a1A and/or the receive boxes 64a2A are clicked "on" (by placing a black mark in the box).

In FIG. 15d, taking each event in order, for the "change color" event of FIG. 15d, the send box 1A1 is not clicked, and the receive box 2A1 is not clicked. As a result, for the "change color" event for the particular client application, event information for the "change color" event will not be transmitted to other client applications, and event information for the "change color" event will not be received from other client applications.

In FIG. 15d, for the "change thickness" event, the send box 1A2 is clicked, but the receive box 2A2 is not clicked. As a result, for the "change thickness" event for the particular client application, event information for the "change thickness" event will be transmitted to other client applications, but event information for the "change thickness" event will not be received from other client applications.

In FIG. 15d, for the "change shape" event, the send box 1A3 is not clicked, but the receive box 2A3 is clicked. As a result, for the "change shape" event for the particular client application, event information for the "change shape" event will be not transmitted to other client applications, but event information for the "change shape" event will be received from other client applications.

In FIG. 15d, for the "cursor tracking" event, the send box 1A4 is clicked, and the receive box 2A4 is clicked. As a result, for the "cursor tracking" event for the particular client application, event information for the "cursor tracking" event will be transmitted to other client applications, and event information for the "cursor tracking" event will be received from other client applications.

However, in the example of FIG. 15e, the same four events appear under the events column 64a3 of the subwindow display 64a of the event filter 64 (appearing in a window display 12b on the display screen 12a of a workstation 10 for a particular client application): (1) change color, (2) change thickness, (3) change shape, and (4) cursor tracking. The subwindow display 64a in FIG. 15e further includes an "all" box 64a4 under the "send" column 64a1 and another "all" box 64a5 under the "receive" column 64a2. When an "all" box is clicked "on", each of the individual (send or receive) boxes above the "all" box will be clicked "on"; however, if the "all" box is not clicked "on", each of the individual boxes above the "all" box must be individually clicked "on" or "off". For example, note that the "all" box 64a5 under the receive column 64a2 is clicked "on", but the "all" box 64a4 under the send column 64a1 is not clicked "on". Since the "all" box 64a5 under the receive column 64a2 is clicked "on", all of the receive boxes 2A1, 2A2, 2A3, and 2A4 in the subwindow display 64ain FIG. 15e are clicked "on". However, since the "all" box 64a4 under the "send" column 64a1 is not clicked "on", each of the individual boxes 1A1, 1A2, 1A3, and 1A4 must be individually clicked as either "on" or "off". As a result, in FIG. 15e, the "change color" event will not be sent from the particular client application to other client applications but it will be received by the particular client application from other client applications. In addition, the "change thickness" event will be sent from the particular client application to other client applications and it will be received by the particular client application from the other client applications. The "change shape" event will not be sent by the particular client application to other client applications, but it will be received by the particular client application from other client applications. The "cursor tracking" event will be sent by the particular client application to the other client applications and it will be received by the particular client application from the other client applications.

The functional operation of the event filter 64 and its subwindow 64a will be set forth again below in connection with a discussion of FIG. 26 and the functional operation of the present invention.

In FIGS. 16 through 23, examples of the use of all the icons of FIGS. 14 and 15a, including the open state icon 60a, the closed state icon 60b, the locked state icon 60c, the broadcast icon 62, and the event filter icon 64, are illustrated.

In FIG. 16, a window display, which could be one of the window displays 12b of FIG. 1, has a group of icons in the bottom right hand corner of the window display, the icons including a closed state status icon 60b, a broadcast icon 62, and an event filter 64.

In FIG. 17, another window display 12b has a closed state status icon 60b and a broadcast icon 62 in the bottom right hand corner of the window display 12b.

In FIG. 18, another window display 12b has an open state status icon 60a and a broadcast icon 62 in the bottom right hand corner of the window display 12b.

In FIG. 19, another window display 12b has a locked state status icon 60c and a broadcast icon 62 in the bottom right hand corner of the window display 12b.

In FIGS. 20 through 23, referring initially to FIG. 20, an operator will view a master window 12b1 on the display screen 12a of FIG. 1 and, by using the mouse 18 of FIG. 1, the operator can subsequently obtain a number of sub-windows shown in FIGS. 21, 22, and 23. For example, the master window 12b1 of FIG. 20 includes an open state status icon 60a and a broadcast icon 62 in the bottom right hand corner of the window. However, the master window 12b1 of FIG. 20 also includes a box 70. If the operator uses the mouse 18 to click on the box 70 in the master window 12b1 of FIG. 20, in addition to the master window 12b1, a first sub-window 12b2 shown in FIG. 21 will be presented to the operator on the display screen 12a of the workstation 10 of FIG. 1. The first sub-window 12b2 includes an open state status icon 60a and a broadcast icon 62 in the bottom right hand corner of the first sub-window 12b2. The first sub-window 12b2 includes a second box 72 and a third box 74. If the operator uses the mouse 18 to click on the second box 72 in the first sub-window 12b2 of FIG. 21, a second sub-window 12b3 shown in FIG. 22 will be presented to the operator on the display screen 12a of the workstation 10 of FIG. 1. The second sub-window 12b3 includes a locked state status icon 60c and a broadcast icon 62 in the bottom right hand corner of the second sub-window 12b3. If the operator uses the mouse 18 to click on the third box 74 in the first sub-window 12b2 of FIG. 21, a third sub-window 12b4 shown in FIG. 23 will be presented to the operator on the display screen 12a of the workstation 10 of FIG. 1. The third sub-window 12b4 includes a closed state status icon 60b and a broadcast icon 62 in the bottom right hand corner of the third sub-window 12b4.

The above paragraphs have discussed the structure and function of the status icons which includes the open state status 60a, the closed state status icon 60b, and the locked state status icon 60c, in addition to the broadcast icon 62 and the event filter icon 64. Each of these icons would appear on the bottom right hand corner of a window 12b of FIG. 1. However, there is one additional icon to be disclosed, called the "Raised Application Manager Event" icon, that would appear on the bottom left hand corner of the window display 12b of FIG. 1 (not the right hand corner where the other icons discussed above appear). The "Raised Application Manager Event" icon is discussed in detail, as follows.

Raised Application Manager Event Icon 76

In FIGS. 1, 24 and 25, each of the windows 12b of FIG. 1 include a "Raised Application Manager Event" icon 76 (of FIG. 24) which is located in the bottom left hand corner of the window 12b. For example, one of the windows 12b of FIG. 1 could include the window 12b5 of FIG. 24.

In FIG. 24, the window 12b5 includes the Raised Application Manager Event icon 76 in the bottom left hand corner of the window 12b5. Assume now that a multitude of windows 12b are being presented to the operator on the display screen 12a of the workstation 10 of FIG. 1. Assume further that the operator wants to access a particular client application from the workstation 10; however, the multitude of windows 12b on the display screen 12a is obscuring the display screen 12a and, as a result, it is very difficult for the operator to access the particular client application.

In FIGS. 1 and 24, order to access the particular client application, the operator will find the "Raised Application Manager Event" icon 76 in the bottom left hand corner of any window 12b on the display screen 12a of FIG. 1 One of the windows 12b of FIG. 1 could include the window 12b5 of FIG. 24. The window 12b5 of FIG. 24 includes the "Raised Application Manager Event" icon 76 in the bottom left hand corner and a locked state status icon 60c and a broadcast icon 62 in the bottom right hand corner of the window 12b5. Using the mouse 18, the operator clicks "on" the Raised Application Manager Event icon 76 of FIG. 24. In response, a main launch window 12b6, illustrated in FIG. 25, is displayed on the display screen 12a of the workstation 10 of FIG. 1.

In FIGS. 2 and 25, the main launch window 12b6 of FIG. 25 includes a plurality of different client application icons 78 representing a respective plurality of different client application programs. The workstation 10 of FIG. 1 will execute any particular one of the different client application programs if and when the operator at the workstation 10 of FIG. 1 uses the mouse 18 to click "on" the client application icon 78 of FIG. 25 which corresponds to that particular client application program. See, for example, the different client applications 20 shown in FIG. 2. Each of the plurality of different client applications 78 shown in FIG. 25 could represent one of the plurality of client applications 20 shown in FIG. 2.

Referring to FIGS. 26, 26A, and 27, a detailed construction and a functional operation of the ITC HI Setup software 32aof FIG. 5 is illustrated.

In FIG. 26, the ITC HI Setup Software 32a of FIG. 5 includes (but is not limited to) the following blocks of code:

(1) "Build List of ITC Events" 80,

(2) "Function 1 to call on reception of Event 1" 82,

(3) "Function 2 to call on reception of Event 2" 84,

(4) "Call to itc.sub.-- hi.sub.-- Filter And Session" 86,

(5) "Function to call on Broadcast" 88, and

(6) "Call to itc.sub.-- hi.sub.-- Delete" 90.

The "Build List of ITC Events" 80 block of FIG. 26 is illustrated in greater detail in FIG. 26A.

Each of these blocks of code is discussed below.

Build List of ITC Events 80

Function 1 to call on reception of Event 1 82

Function 2 to call on reception of Event 2 84

In FIGS. 3, 4, 5, and 6 recall from FIGS. 3 and 4 that the client 1 application 24c1 was stored in the memory 24c of the first workstation 24 of FIG. 3 and the client 2 application 26c1 was stored in the memory 26c of the second workstation 26 of FIG. 3. The client 1 application 24c1 and the client 2 application 26c1 each include: (1) the ITC Human Interface Code 32, and (2) the ITC Framework (ITC-Core) Code 34 of FIG. 4. The ITC Framework (ITC-Core) Code 34 was discussed above with reference to FIGS. 6 through 13. The ITC Human Interface Code 32 of FIG. 4 includes four parts: the ITC HI Setup software 32a of FIG. 5, the Send An Event software 32b of FIG. 5, the Receive An Event software 32c of FIG. 5, and the Operator Interaction Display Software 32d of FIG. 5.

When the client 1 application 24c1 wants to receive "event information" regarding "event X" from the client 2 application 26c1, the client 1 application 24c1 will send an "interest object" in event X to the server 26c2 in FIGS. 3 and 6. In response to the receipt by the server 26c2 of the "interest object" in event X from client 1, the server 26c2 will: (1) register within itself the client 1's interest in event X, and (2) redistribute that interest object in event X from the server 26c2 to the client 2 application 26c1. When the client 2 application 26c1 practices or executes the event X, the event information associated with the practice of event X in client 2 will be sent directly from client 2 to client 1 (via line 40 in FIG. 6) without passing through and registering with the server 26c2.

Similarly, the client 2 application 26c1 of FIG. 3 will send an interest object in event X to the server 26c2, and the server 26c2 will: (1) register within itself client 2's interest in the event information associated with event X, and (2) send the interest object in event X to the client 1 application 24c1. When the client 1 application 24c1 practices or executes the event X, the event information associated with the event X will be sent directly by client 1 24c1 to client 2 26c1 (via line 40 in FIG. 6) without passing through and registering with the server 26c2.

Therefore, each client application program, including the client 1 application 24c1 and the client 2 application 26c1 of FIG. 3, must record and store within itself the identity of all of the specific events (such as "event X"), as well as their interest objects and their functions, in which that particular client application is interested.

In FIG. 26, each particular client application program, including the client 1 application 24c1 and the client 2 application 26c1 of FIG. 3 which generated two of the window displays 12b of FIG. 1, stores within itself a "list of ITC events" 80, a "list of functions" 82, 84 corresponding, respectively, to the "list of ITC events" 80, and a "list of interest objects" corresponding, respectively, to the "list of functions" and the "list of ITC events" 80.

As a result, in FIG. 26, block 80 stores a list of events called "Build a list of ITC Events" wherein a plurality of events (i.e. , event 1, event 2, event 3, . . . , event N) are stored. Blocks 80, 84 will store a plurality of functions (i.e. , function 1, function 2, function 3, . . . , function N), which correspond, respectively, to the plurality of events of block 80, the plurality of functions being retrieved from memory and executed in response to the reception (by the ITC Framework 34 of FIG. 5 of a particular client application) of a respective plurality of events transmitted to the particular client application from the other client applications.

For example, a first function in FIG. 26 called "Function 1 to call on reception of Event 1" 82 represents the function associated with "event 1" in the block "Build a list of ITC Events" 80. A second function in FIG. 26 called "Function 2 to call on reception of Event 2" 84 represents the function associated with "event 2" in the block "Build a list of ITC Events" 80.

In addition, in FIG. 26A, the block 80 of FIG. 26 will also store a plurality of "interest objects" corresponding, respectively, to the plurality of "events". For example, in FIG. 26A, the block 80 of FIG. 26, which is called "Build List of ITC Events", will have at least two columns of stored information: (1) a first column 80a storing a plurality of events 80a, such as Event 1, Event 2, Event 3, . . . , and Event N; and (2) a second column 80b storing a plurality of interest objects 80b which correspond, respectively, to the plurality of events 80a, such as "Interest Object 1" associated with "Event 1", "Interest Object 2" associated with "Event 2", "Interest Object 3" associated with "Event 3", . . . , and "Interest Object N" associated with "Event N".

Therefore, when the particular client application program begins to execute, since the particular client application stored within itself a "list of ITC events" 80, the particular client application will send the interest object, associated with each of the events in the stored "list of ITC events" 80, from the particular client application to the other client applications via the server 26c2 as shown in FIG. 6.

In addition, if the a particular set of interest objects corresponding to a particular set of events are sent by the particular client application 24c1 to the other client applications 26c1 via the server 26c2, if the "Build a list of events" 80 in the other client applications 26c1 include the aforesaid particular set of events, and when the other client applications 26c1 practice or execute the particular set of events, the other client applications 26c1 will send a particular set of event information associated with the particular set of events directly to the particular client application (via line 40 in FIG. 6) without registering that event information with the server 26c2 and the particular client application will receive that particular set of event information.

In addition, when other client applications send an interest object in an event X to the particular client application via the server 26c2, since the particular client application stores within itself a "list of ITC events" 80 and a corresponding list of "interest objects" associated with the list of ITC events 80, the received interest object from the other client application is compared by the particular client application with the "list of interest objects" 80 of FIG. 26A stored in the particular client application, and, if a match if found, the event which corresponds to the matched interest object (i.e. , "event X") will be transmitted from the particular client application directly to the other client applications (directly via line 40 in FIG. 6).

In addition, for each particular client application wherein a "list of ITC events" 80 is stored, a corresponding "list of functions" 82, 84 must be stored corresponding, respectively, to the stored "list of ITC events" 80. As a result, when another client application practices or executes the requested "event X", the event information associated with that event X will be sent directly from that other client application to the particular client application (via line 40 in FIG. 6) without passing through and registering with the server. When the event information associated with event X is received by the particular client application, the received event information will be compared by the particular client application with the "list of ITC events" 80 and their corresponding "list of functions" 82, 84 stored in the particular client application. When a match is found, by the particular client application, between the event information received from the other client application and "one particular event" in the "list of ITC events" 80, the "particular function" 82, 84 which is associated with that "one particular event" will be automatically recalled from memory 24c, 26c, the "particular function" 82, 84 being executed by the processor 24a or 26a of FIG. 3 in the workstation 10 which is executing the particular client application. The Operator Interation Display Software 32d of FIG. 5 will ensure that the "particular function" (i.e, the received event information, such as depth change or color change or line thickness change) will be displayed on the display screen 12a of the workstation 10 of FIG. 1.

Call to itc hi Filter And Session 86

In FIG. 26, the "Call to itc hi Filter And Session" 86 is the portion of the ITC-HI Setup software 32a of FIG. 5 which performs the "human interface" function.

In FIG. 5, note the intermediate location of the ITC-HI Setup" 32a between the "Operator Interaction Display software" 32d, which displays the icons and the event information, and the "Send An Event" 32b and the "Receive An Event" 32c software which sends event information to and receives event information from other client applications.

In FIG. 26, since the "Call to itc Filter And Session" 86 is an integral part of the ITC-HI Setup software 32a, it is evident from the intermediate location of the ITC-HI Setup 32a software in FIG. 5 (between the "Operator Interaction Display software" 32d and the "Send An Event" 32b and the "Receive An Event" 32c software) that the "Call to itc hi Filter And Session" 86 portion of the ITC-HI Setup Software 32a in FIG. 26 will function as a coordinator located between two ends for receiving information from one end and, in response thereto, for instructing the other end.

For example, in FIGS. 5 and 26, the "Call to itc hi Filter And Session" 86 will receive event information from the "Receive An Event" software 32c (where the event information originated from another client application and is associated with an event X) and, in response thereto, will drive the "Operator Interaction Display" software 32d for displaying that event information associated with the event X on the display screen 12a of FIG. 1 for a particular client application.

In addition, in FIGS. 5 and 26, the "Call to itc hi Filter And Session" 86 will receive event information (e.g.--changed parameters, color, thickness, font size) from the "Operator Interaction Display" software 32d of a particular client application and, in response thereto, will drive the "Send An Event" software 32b which will further instruct the ITC Framework 34 to send the aforementioned event information to other interested client applications.

Therefore, the "Call to itc hi Filter And Session" 86 will make all the connections; that is: it will send all interest objects from the "Build list of ITC Events" 80 of a particular client application to the server 26c2 for further transmission to other client applications; it will associate event information received from other client applications with a particular function 82, 84 of FIG. 26 in a particular client application for executing that particular function in the particular client application; it will cause the Operator Interaction Display Software 32d to build the various icons (status icons 60, broadcast icon 62, event filter icon 64) for display in a particular client application on the display screen 12a; and it will notify the ITC Framework (ITC Core) 34 of FIG. 5 of a particular client application which will, in turn, notify the server 26c2 that the particular client application is interested in the plurality of events that are listed in its "Build list of ITC Events" 80 of FIG. 26.

Function to call on Broadcast 88

In FIG. 26, the "Function to call on Broadcast" 88 part of the ITC-HI Setup Software 32a of FIG. 5 is associated with the "Call to itc.sub.-- hi.sub.-- Filter And Session" 86. In order to explain the function of the "Function to call on Broadcast" 88, it is necessary to recall the function of the "Broadcast" Icon 62 of FIG. 14.

When the broadcast icon 62 for a particular client application 12b is clicked "on" by an operator at workstation 10 using the mouse 18, in most cases, all of a plurality of newly created events in the particular client application, which were generated by an operator at the workstation 10 during a period of time after the closed state status icon 60b was clicked "on", will be simultaneously transmitted from the particular client application to all other "interested client applications" executing in the network of workstations.

For example, for a particular client application where particular events consisting of color events, font size events, and line thickness events can be transmitted to and received from other client applications, when the operator of the particular client application clicks "on" the broadcast icon 62 after a period of time elapses following the clicking "on" of the closed state status icon 60b, in most cases, event information associated with all of the particular events will be transmitted to the other client applications.

However, the "Function to call on Broadcast" 88 will allow the particular client application developer to decide whether or not event information associated with "all" of the particular events will be transmitted to the other client applications when the broadcast icon 62 is clicked "on" by the operator. More particularly, using the "Function to call on Broadcast" 88, event information associated with "some" of the particular events (which were newly created in the particular client application after the closed state status icon was clicked "on" by the operator) will be transmitted to the other client applications when the broadcast icon 62 is clicked "on" by the operator.

In FIGS. 5 and 26, when the operator clicks "on" the broadcast icon 62 for a particular client application after a period of time elapsed following the clicking "on" of the closed state status icon 60b, the "Operator Interaction Display" software 32d in FIG. 5 for that particular client application will notify the ITC-HI Setup Software 32a in FIG. 5 that the operator clicked "on" the broadcast icon 62. In response, the "Call to itc.sub.-- hi.sub.-- Filter And Session" 86 portion of the ITC-HI Setup Software 32a in FIG. 26 will refer to and call up the "Function to call on Broadcast" 88 part of the ITC-HI Setup Software 32a.

Assume that a "plurality of newly created events" were practiced and executed by the particular client application between the time when the closed state status icon 60b was clicked "on" and the time when the broadcast icon 62 was clicked "on" by the operator executing the particular client application.

The "Function to call on Broadcast" 88 will determine whether "all" or "some" of the "plurality of newly created events" will be transmitted to the other client applications in response to the clicking "on" of the broadcast icon 62 by the operator executing the particular client application. The "Function to call on Broadcast" 88 will determine how many events of the "plurality of newly created events" (i.e.--some, all, or none) will be transmitted to the other client applications.

In FIGS. 5 and 26, using the above example, for a particular client application where particular events consisting of color events, font size events, and line thickness events can be transmitted to and received from other client applications, when the operator of the particular client application clicks "on" the broadcast