WO1995001024A1

WO1995001024A1 - Multiple computer conferencing system and method

Info

Publication number: WO1995001024A1
Application number: PCT/US1994/006520
Authority: WO
Inventors: Nigel John Sidney Green
Original assignee: Software Publishing Corporation
Priority date: 1993-06-23
Filing date: 1994-06-08
Publication date: 1995-01-05

Abstract

A multiple computer conferencing system (11) and method enables hardware platform and data transport independent computer conferencing at physically remote locations. The system comprises a plurality of participant (10, 12-15) systems coupled in a hub-and-spoke architecture, where one participant system serves as a moderator (10) at the hub of the architecture, one serves as a presenter (14), and the remaining participant systems serve as attendees (12, 13, 15). Each participant system comprises a computer system coupled to a message processing unit (30). The message processing unit comprises a conference support services module (40), a conferencing module (46), a transport independent module (42), and one or more transport dependent modules (44). The method of the present invention allows a single instance of a host application to control multiple host application instances. Information transfer between participant systems requiring recipient acknowledgment is routed through the moderator. Conference activities proceed independently of attendee processing rates, and can occur on very low-bandwidth data transport systems.

Description

MULTIPLE COMPUTER CONFERENCING SYSTEM AND METHOD

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates generally to computer conferencing systems, and more particularly, to a system and method for simultaneous conferencing between multiple computers at physically remote locations. Still more particularly, the present invention relates to a conferencing system and method that is a hardware-platform and data-transport independent. 2. Description of the Background Art

As communication needs increase, people require a medium that provides frequent and convenient information exchange between remote locations. A telephone conference call is a common example, in which individuals exchange audio information. Video conferencing has expanded this information exchange to include information gathered using cameras at each site. Another important aspect of conferences is the use of slide presentations, overheads, and other presentation techniques. With the widespread acceptance of personal computers, increasing numbers of presentations utilize presentation graphics programs that operate on computers. Thus, a need has developed for a system and method of synchronizing the displays of computers that may be operated at a plurality of geographically separate locations. The need to exchange and examine data at remote locations requires a system and method allowing remote conferencing involving computers.

The prior art has attempted to satisfy these existing needs with computer conferencing systems. A computer conferencing system provides a conference¬ like situation in which a plurality of computers receive information from one computer acting as the presenter. The information supplied by the presenter typically consists of text, numerical data, or video information. Current systems that provide computer conferencing abilities transfer information from the presenter to the plurality of other locations through picture-to- picture transfer. In a picture-to-picture transfer, an image on the presenter's computer display is bit mapped and transferred to other participants. The large amount of data involved in picture-to-picture transfers requires large amounts of computer memory and a high-bandwidth data transport system. Information transfer in such a conferencing environment can be extremely slow, especially in situations involving many computers. Such systems are typically forced to function at the rate of the slowest computer exacerbating the problem. Computer conferencing using picture-to-picture transfer also requires participants to utilize displays having identical resolution capabilities. In general, a common data-transport system and a common computer hardware platform are also required in order to minimize the effects of the problems discussed above. Therefore, the instances when present-day computer conferencing can be used are very limited.

Another problem with current computer conferencing systems is that they are not contained within the framework of any specific application program, such as a spreadsheet or slide presentation. Thus, data interfacing between application programs and debugging issues can vary from one application to another. In addition, current computer conferencing systems do not allow a single instance of an application program to control operation of the applications concurrently running on other conference participants' computer systems. This feature is especially desirable in the context of presentations and conferencing because one user typically acts as the source of information to be distributed among all participants.

Therefore, there is a need for a multiple computer conferencing system that is integrated into an application program, and does not require transferring large blocks of data. There is also a need for a computer conferencing system that is hardware platform and data transport independent, and that operates independently of the processing rate of conference attendees.

SUMMARY OF THE INVENTION The present invention is a multiple computer conferencing system and method which is a portion of an integrated applications program framework and which functions independently of hardware platform and data transport system. The system of the present invention comprises a plurality of participant systems, interconnected in a hub-and-spoke architecture. The participant system at the hub of this architecture serves as the conference moderator. One participant system must also serve as the conference presenter.

Each participant system comprises a computer having a CPU; a specified amount of computer memory; one or more input devices such as a keyboard or a mouse; a display device; a means such as a modem or a link to a computer network for enabling data transport between other participant systems; and a message processing unit which controls a switch for enabling or disabling the participant system's input device. All elements within a participant system are coupled to a common data pathway in a Von Neumann architecture.

The message processing unit comprises a single function-call system of conference support services, a conferencing module, a transport independent layer, and a plurality of transport dependent layers. The conference support services provide a communication interface between the host application and the conferencing module, which facilitates message exchange with other participant systems. The conferencing module directs the actions of the transport independent module, which interfaces with each of the transport dependent modules. Within the conferencing module are participant control structures, each of which enables communication with a specific participant system connected to the conference; an incoming message buffer linked to each participant control structure; an incoming message queue containing messages which require processing; and an outgoing message queue containing messages directed to other participant systems.

The method of the present invention allows an instance of an application program running on one participant system to control a plurality of application instances running concurrently on other participant systems. One participant system begins a conference through initialization of its message processing unit. This participant system acts as the conference moderator, initially controlling conference resources such as a mouse or keyboard. The moderator directs the connection of additional participant systems to the conference, placing them in the role of attendees. The moderator further designates one attendee as the presenter, and transfers conference resources to the presenter. The presenter then directs the conference activities, such as mouse movement, slide progression, or group editing. The progression of conference activities occurs independently of the processing rate of any given attendee, and all information transferred comprises small blocks of data, thereby allowing use of very low bandwidth data transfer systems. Upon completion, the presenter relinquishes control of conference resources to the moderator. At this point, the moderator can continue the conference, or notify participant systems of conference termination and subsequent participant system disconnection. Throughout each phase of the conference, information requiring participant system acknowledgment of receipt is routed through the moderator. BRIEF DESCRIPTION OF THE DRAWINGS FIG. la is a simplified block diagram embodiment of the system of the present invention, showing a general connection architecture between a plurality of participant systems of the multiple computer conferencing system; FIG. lb is a block diagram of a second embodiment of the system of the present invention, showing the general connection architecture between two participant systems of the multiple computer conferencing system;

FIG. 2 is a block diagram of the preferred embodiment of each participant system coupled to the multiple computer conferencing system; FIG. 3a is a block diagram of the modules that comprise the message processing unit of each participant system and a host application;

FIG. 3b shows a preferred embodiment of the internal architecture for the message processing unit of each participant system;

FIG. 4 is a flowchart showing an overview of the multiple computer conferencing method of the present invention;

FIG. 5 is a flowchart illustrating the preferred method for initializing a conference;

FIG. 6 is a flowchart illustrating the preferred method for participant system operation during a conference; FIG. 7 is a flowchart of the preferred method for terminating the conference;

FIG. 8 is a flowchart of the preferred method for executing an asynchronous process on a participant system;

FIG. 9 is a flowchart of the preferred method for receiving messages from other participant systems; and

FIG. 10 is a flowchart of the preferred method for sending messages to other participant systems.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring now to FIG. la, a first and preferred embodiment of the multiple computer conferencing system 11 of the present invention is shown. The first embodiment preferably comprises a plurality of participant systems 10, 12-15, coupled to one another through a hub-and-spoke architecture. Each coupling in this architecture is preferably implemented through a data transport means, such as a local-area or other network, or a modem, where the data transport means can vary from participant system to participant system. A first participant system 10 serves as a conference moderator. The moderator is responsible for beginning a conference, and the conference is initially controlled through the input device of the moderator. Upon initiating the conference, the moderator couples with additional participant systems 12-15 as conference attendees. The moderator then designates one participant system 14 as a presenter, which receives control of conferencing resources such as a mouse and keyboard. Thus, once a system 10, 12-15 is selected as presenter, the input devices of other non-selected participant systems are disabled.

The arrows shown in FIG. la are exemplary data paths for information transfer. Any participant system 10, 12-15 may transfer information to any one or several of the other participant systems 10, 12-15. Each participant system 10, 12-15 is preferably coupled to the moderator, which acts as a data hub for all information transfers requiring participant system 10, 12-15 acknowledgment of receipt. Information transfers which do not require receipt acknowledgment are sent to all participant systems 10, 12-15 simultaneously if the coupling means between participant systems 10, 12-15 allow this, otherwise such information transfers are routed through the moderator as well.

A mail message can be transferred from one participant system 15 to another participant system, as shown by the curved arrow, in which case the message is also routed through the moderator. This mail message feature is similar to E-mail systems, in that a participant system 10, 12-15 may designate that the mail message be delivered to any one or more participant systems 10, 12-15 connected to the conference.

The preferred embodiment of FIG. la is advantageous because it reduces conference attendee resource requirements. A conference attendee's participant system 12-15 maintains only one data coupling throughout the conference, which requires fewer computational resources than two or more couplings require. During a conference, the participants' roles may change; for example, the moderator may elect to become an attendee, allowing another participant system 12-15 to act as the moderator. Similarly, the presenter may be changed from one participant system 10, 12-15 to another participant system 10, 12-15.

FIG. lb shows a second embodiment of the multiple computer conferencing system 18 of the present invention, in which a single participant system 17 performs the role of moderator and the role of presenter. The system 18 also includes one additional participant system 19 that is connected to the moderator and acts as the only conference attendee. This represents the smallest conferencing situation, having only two participants systems 17, 19. The two-participant systems 17, 19 could also designate one participant system 17 as the moderator, and the other participant system 19 as the presenter. While the conferencing situation depicted in FIG. lb is functionally complete, the first embodiment of the conferencing system between more than two participant systems 10, 12-15 will be referenced below.

Referring now to FIG. 2, a block diagram of the preferred embodiment of each of the participant systems 10, 12-15 is shown. In the preferred embodiment, each of the participant systems 10, 12-15 have an identical configuration shown in FIG. 2. A single participant system 10 is described only by way of example. The participant system 10 comprises a CPU 20, an input device 22, a display device 24, a memory 26, a communication or data transport means such as a modem 28, and a message processing unit 30 which controls a switch 32 or other means to selectively enable or disable the participant system's 10 input. Each component of a participant system 10 is coupled to a common data bus 34. The CPU 20 processes instructions contained within a program, particularly a host application 50. These instructions are stored in the memory 26. The memory 26 also stores an operating system, basic input/output subroutines, and information received from the input 22 or from other participant systems 12-15. Processed information can be represented visually on the display 24. The modem 28 provides a means for data transfer with other participant systems 12-15. The preceding components are preferably implemented as an IBM or compatible personal computer having an Intel 80486 microprocessor as the CPU; several megabytes of RAM memory plus some ROM memory; a keyboard for character input and a mouse for cursor-position input; a 640 x 480 color CRT display; and a 1200 baud or higher modem coupled to a telephone line. If a participant system 10 is acting as the moderator, coupling to additional participant systems 12-15 can be implemented via a single network connection, or by a modem coupled to a unique telephone line routed to each attendee's participant system 12-15.

The message processing unit 30 enables conferencing processes on the participant system 10, and coordinates data transfers with other participant systems 12-15. All participant systems are architecturally equivalent; hence, each participant system 10, 12-15 is capable of assuming the role of moderator, attendee, or presenter.

Referring now to FIG. 3a, a preferred embodiment of the message processing unit 30 maintained by each participant system 10, 12-15 is shown. A conference support services module 40 serves as the participant system's 10 interface to a host application 50. The conference support services module 40 is coupled to a conferencing module 46, which comprises a set of buffers and queues which store messages directed to and received from other participant systems 12-15, and structures for storing status information pertaining to other participant systems 12-15. The conferencing module 46 is further coupled to a transport independent module 42, which is coupled to a plurality of transport dependent modules 44. Message transfer to and from another participant system 12-15 occurs through the conferencing module 46, the transport independent module 42, and one of the transport dependent modules 44.

The conference support services module 40 processes messages received from the host application, and generates a sequence of conferencing processes which will perform the required host application operation. The conference support services module 40 also receives messages from the conferencing module 46 and translates the message into commands for the host application 50. These conferencing processes include opening a conference, designating a participant system 10, 12-15 as the presenter, connecting a participant system 12-15 to the conference, or closing a conference. The conference support services module 40 also routes messages, manages queues, enables mail-message transfer, scales pixel dimensions relative to other participant systems' 12-15 display capabilities, and regularly determines the status of other participant systems 12-15. The moderator's conference support services module 40 also monitors information flow on attendee participant systems 12-15 in order to determine if an attendee lags behind the presenter to a greater extent than other attendees. In general, the conference support services module 40 determines which set of actions the conferencing module 46 must perform at any stage of a conference.

The conferencing module 46 coordinates message transfer between other participant systems 12-15. The transport independent module 42 ensures that data is sent to other participant systems 10, 12-15 in a manner consistent with data transport resources, and isolates the conference support services module 40 and the conferencing module 46 from details specific to communication with any particular data transport system. Such details are contained within the transport dependent modules 44, which facilitate information transfer between the transport independent module 42 and other participant systems 12-15. Each transport dependent module 44 typically comprises a unique architecture and communications protocol. A message directed to another participant system 12-15 generated as a result of the conference support services module 40 processing a host application 50 message is stored in the conferencing module 46, which instructs the transport independent module 42 to pass the message to the transport dependent modules 44. The transport independent module 42 communicates with a participant system 10, 12-15 in order to optimize data transfer efficiency, and selects the appropriate transport dependent module 44 based upon the message type, message destination, and capabilities of the data transport means its participant system 10, 12-15 maintains. In this manner, the message is sent to the intended participant system 12-15 in the proper format. Thus, the conference support services 40 module, the conferencing module 46, and the transport independent module 42 form the basis for conferencing capabilities between one host application 50 instance on one participant system 10 and other participant systems' 12-15 host application 50 instances, independent of the hardware platform or data transport details.

Fig. 3b shows a preferred embodiment of the message processing unit 30 of the multiple computer conferencing system 11 of the present invention. As discussed with reference to FIG. 3a, the host application 50 is coupled to the conference support services module 40, which is coupled to the conferencing module 46. The conferencing module 46 is also coupled to the transport independent module 42, and this module 42 in turn is coupled to a plurality of transport dependent modules 44.

The conferencing module 46 comprises a plurality of participant control structures 62-65, a miscellaneous control structures 70, a plurality of incoming message buffers 66-69, 71, an incoming message queue 60, and an outgoing message queue 56. The participant 62-65 and miscellaneous 70 control structures are coupled to the conference support services module 40 and are linked to a corresponding incoming message buffer 66-69, 71. The participant control structures 62-65, 70 are also linked to the outgoing message queue 56. The input of the incoming message queue 60 is coupled to each incoming message buffer 66-69, 71 through the conference support services module 40, and the output of the incoming message queue 60 is coupled to the conference support services module 40. The inputs of the incoming message buffers 66-69, 71 are also coupled to the transport independent module 42. The input of the outgoing message queue 56 is coupled to the conference support services module 40, while its output is coupled to the transport independent module 42.

A participant system's 10 host application 50 functions in a conferencing environment by routing control messages and information through the message processing unit 30. For each connected participant system 10, 12-15, the conferencing module 46 maintains a participant control structure 62-65 which interacts with the conference support services module 40. Thus, the participant system 10 acting as the moderator maintains a participant control structure 62-65 for every other participant system 12-15. Each attendee and the presenter likewise maintain one participant control structure corresponding to the physical connection to the moderator, as well as participant control structures 62-65 corresponding to all other participant systems 12-15. One or more miscellaneous control structures 70 also interface with the conferencing support services module 40. Each participant control structure 62-65 maintains the status of a respective participant system 12-15, as well as tracking pointers to. its incoming message buffer 66-69 and the outgoing message queue 56. Thus, the number of participant control structures 62-65 and incoming message buffers 66-69 varies according to the number of participant systems 12- 15 connected to the conference. A hardware implementation will therefore have a maximum number of participant control structures 62-65 which will limit the number of participant systems 12-15 that can connect to the conference. In a software implementation, participant control structures 62-65 and their corresponding incoming message buffers 66-69 can be created and destroyed in memory, thereby easing restrictions on the maximum number of participant systems 12-15 which can connect to the conference. A software implementation can specify the maximum number which are allowed. While a participant system 10, 12-15 requires only one miscellaneous control structure 70, more may be utilized for greater system efficiency. The conference support services module 40 places messages directed to other participant systems 12-15 into the outgoing message queue 56, which interfaces with the transport independent module 42. The transport independent module 42 sends messages in the outgoing message queue 56 to the appropriate transport dependent module 44, depending upon the platform on which the respective participant system 12-15 is running. Incoming messages from another participant system 12-15 are sent from a transport dependent module 44 to the transport independent module 42, and from the transport independent module 42 are placed into the incoming message buffer 66-69 linked to the respective participant control structure 62-65. The conference support services module 40 transfers these messages from the incoming message buffers 66-69 to the incoming message queue 60. After placement in the incoming message queue 60, the messages are processed by the conferencing support services module 40 to create commands to the host application 50. Messages transferred between participant systems 10, 12-15 comprise commands, notifications, replies, or data. A given message may also include information related to conference administration. For example, a message which, upon processing, will result in a mouse movement can comprise the mouse position and various flags to indicate a drawing mode. The message may additionally comprise the number of participant systems 10, 12-15 connected to the conference and the number of conference positions available for connecting new participants. The moderator receives messages for its own use, and also serves as the message distribution center for all participant systems 12-15 when a message requires participant system 12-15 acknowledgment upon receipt. Details specific to the data transport means between participant systems 12-15 may further require the moderator to route all information transferred between participant systems 12-15. Such details are determined by the transport independent module 42. Each participant system 10, 12-15 receives messages through use of its conference support services module 40, transport independent module 42, transport dependent modules 44; and incoming message buffers 66-69 and participant control structures 62-65 within the conferencing module 46. A given set of messages may be processed at varying rates and generate varying responses from participant system 10, 12- 15 to participant system 10, 12-15. This possible variation does not pose a problem since the conferencing module 46 interacts with each participant system 10, 12-15 individually in an asynchronous manner. Processes initiated by the presenter's conferencing module 46 in response to the host application 50 of the presenter will be the primary source of messages directed to other participants, namely conference attendees. Conference attendees may also send information to a plurality of participant systems 10, 12-15, including private mail messages. A message typically comprises less than 100 bytes of information, thereby allowing the message passing required for conferencing to be performed effectively and quickly on low-bandwidth data transport means such as modems.

The preferred embodiment of the present invention includes two message forms. The first message form is referred to as a guaranteed receipt (GR) message, which requires acknowledgment from the message recipient's participant system 10, 12-15. Depending upon the capabilities inherent in the data transport means, this acknowledgment is issued as a low-level handshaking message which is sent either by the data transport means or by the transport dependent module 44. Since low-level message receipt acknowledgment by the transport dependent module 44 is independent of the inherent capabilities of a given data transport means, such acknowledgment is referenced below. A high-level acknowledgment message may additionally be generated by the host application 50 depending upon the specific message. Such high-level acknowledgment messages typically indicate process completion. A GR message indicates to a participant system 10, 12-15 that performance of the conferencing process corresponding to the message is essential for maintaining the logical flow of information during the conference. A GR message placed into the outgoing message queue 56 is labeled as a GRO message, indicating the message is guaranteed receipt outgoing, while a guaranteed receipt incoming message is similarly labeled as a GRI message. Examples of GR messages include commands to advance to the next slide in a presentation, or to recalculate a portion of a spreadsheet, in which case the recipient's host application 50 instance generates a high-level GRO acknowledgment message in addition to the low-level handshaking message sent by the transport dependent module 44; and a GR mail message, in which case the recipient's transport dependent module 44 issues a handshaking acknowledgment message directed to the sender's participant system 10, 12-15. GR messages are routed through the moderator's participant system 10.

The second form of messages are non-guaranteed receipt (NGR) messages, corresponding to cases in which no receipt acknowledgment is required. Performance of a conferencing process corresponding to an NGR message does not significantly contribute to the information conveyed during a conference. For example, if the conference presenter performs a sequence of mouse movements to outline a region of spreadsheet data, the exact sequence of mouse movements is unimportant relative to the marking of the data. In addition, attendee acknowledgment of each mouse movement could dramatically increase data transport traffic; mouse movements are therefore categorized as NGR messages. In a manner analogous to GR messages, NGR messages can be further classified as non-guaranteed receipt outgoing (NGRO) or non-guaranteed receipt incoming (NGRI). NGR message processing occurs independently of GR message processing.

The transport independent module 42 communicates with other components within the participant system 10, 12-15 in order to determine the capabilities of the data transport means between participant systems 10, 12-15 and thereby optimize data transfer efficiency. NGR messages are sent to all participant systems 10, 12-15 simultaneously if the data transport means between participant systems 10, 12-15 allow this, otherwise such information transfers are routed through the moderator. For example, in a multiple computer conferencing system in which the data transport means between participant systems 10, 12-15 comprise modem connections to a telephone line, both GR and NGR message transfers are routed through the moderator. In a system in which the data transport means comprise a network, only GR messages are routed through the moderator; NGR messages can be sent to one or more participant systems 10, 12-15 directly through network distribution. If the host application 50 generates a message which other participants are to receive, the conferencing module 46 receives this message. The conference support services module processes this message by placing corresponding messages into the outgoing message queue 56. In the case of GRO messages, the conference support services module 40 interacts with one or more relevant participant control structures 62-65 in order to send the message. NGRO messages cause the conference support services module 40 to interact with one or more miscellaneous control structures 70. Each participant control structure 62-65 provides the basis for successful information exchange with its respective participant system 10, 12-15, by maintaining the mode and status of its corresponding participant system 12-15 as well as tracking various pointers to GR messages within its incoming message buffer 66-69 and the outgoing message queue 56. Each miscellaneous control structure 70 functions in a similar manner, attending to NGR messages.

A conference which includes a slide presentation provides an example of GR message flow. At some point during the conference, the participant system 14 acting as the presenter will instruct its host application 50 instance to display the next slide. In addition to executing this command, the host application 50 transfers a corresponding message to the conference support services module 40. The conference support services module 40 processes the host application 50 message, and determines that this action must be performed and thus generates a corresponding GRO message which it loads into the outgoing message queue 56. Each participant control structure 62-65 maintains a pointer to the message closest to the front of the outgoing message queue 56 which is directed to its corresponding participant system 10, 12, 13, 15. Since a GR message is routed through the moderator's participant system 10, the participant control structure 65 corresponding to the moderator will point to the GRO slide advancement message in the outgoing message queue 56 when no other message for the moderator is ahead of the slide advancement message in the queue. Once the GRO slide advancement message is pointed to, the conference support services module 40 instructs the transport independent layer 42 to send the message to the moderator via the appropriate transport dependent layer 44.

Within the moderator's participant system 10, the message passes through the transport dependent module 44 corresponding to the presenter's data transport system. The transport independent module 42 places the message in the incoming message buffer 66 linked to the presenter's participant control structure 62. The conference support services module 40 marks the message as having come from the presenter, and places the message into the incoming message queue 60 with a GRI designation. Once the message reaches the front of the incoming message queue 60, the conference services support module 40 processes the message, placing it in the outgoing message queue 56 with GRO designation. Each participant control structure 62- 65 maintains a pointer to the message closest to the front of the outgoing message queue 56 which is directed to its corresponding participant system 10, 12, 13, 15. A participant control structure 63-65 will therefore point to this GRO slide advancement message once no other messages directed to its corresponding participant system 12, 13, 14 are ahead of the GRO slide advancement message in the queue. Once the GRO slide advancement message is pointed to, the conference support services module 40 instructs the transport independent module 42 to send the message to the appropriate participant systems 12, 13, 15 via the transport dependent modules 44. The conference support services module 40 also transfers a corresponding message to the moderator's instance of the host application 50 in order to ensure that the next slide is selected on the moderator's participant system 10.

An attendee's participant system 12, 13, 15 receives the message sent from the moderator through the appropriate transport dependent module 44, after which the transport dependent module 44 sends a low-level handshaking message to the moderator acknowledging message receipt. The transport independent module 42 transfers the message into the incoming message buffer 69 linked to the participant control structure 65 corresponding to the moderator. The conference support services module 40 marks the message as having come from the moderator, and places it in the incoming message queue 60 with GRI designation. Upon reaching the front of the incoming message queue 60, the conference support services module 40 processes the message, transferring an attendant message to the attendee's host application instance.

After the host application instance 50 performs the operations corresponding to slide advancement, the host application 50 generates a high- level acknowledgment message. An attendee's conference support services module 40 receives this acknowledgment message, and generates a high-level GRO acknowledgment message which is transferred to the moderator's participant system 10 in a manner analogous to that described above. Most GR messages do not require high-level acknowledgment by the host application 50, in which case the low-level handshaking message issued by the transport dependent module 44 serves as the indication of message receipt.

The moderator's conference support services module 40 tracks which participant systems 12, 13, 15 have sent the high-level message to acknowledge process completion, and sends a message to the presenter's participant system 14 after receiving all such acknowledgments from the appropriate participant systems 12, 13, 15. This message indicates to the presenter that all attendees have processed the original slide advancement message sent. Although the presenter is not constrained to wait until receiving this message from the moderator before continuing conference activities, the presenter may elect to adjust the conference pace if desired.

Mouse movements on the presenter's participant system 14 are sent out as NGRO messages. The presenter's host application 50 instance receives cursor position information from the mouse, and updates the presenter's display 24 accordingly. In addition, the host application 50 sends a corresponding mouse position message to the conference support services module 40. The conference support services module 40 processes this message by placing an NGRO message in the outgoing message queue 56. In a manner similar to the participant control structures 62-65, the miscellaneous control structure 70 maintains a pointer to the NGRO message closest to the front of the outgoing message queue 56, and will thus point to this NGRO mouse movement message when no other NGRO messages are ahead of it in the queue. The conference support services module 40 instructs the transport independent module 42 to send the message. The transport independent module 42 sends the message via the appropriate transport dependent module 44 either to the moderator or to all attendees, depending upon the coupling means between participant systems 10, 12-15.

If the coupling means between participant systems is implemented via modem connections, the moderator's participant system 10 receives this message and processes it just as in the case of a GR message. The conference support services module 40 marks the message as having come from the presenter, and places the message in the incoming message buffer as an NGRI message. Upon reaching the front of the message queue, the conference support services module 40 processes the message, placing it in the outgoing message queue 56 as an NGRO message. Once this message is pointed to by a participant control structure 62-65 within the moderator's participant system 10, the message is sent to the corresponding attendee's participant system 12, 13, 15 through the transport independent module 42 and the transport dependent modules 44. This occurs on an individual basis for each participant control structure 62-65 and its corresponding participant system 12, 13, 15. Regardless of the coupling means between participant systems, a participant system 12, 13, 15 receives this message through the appropriate transport dependent module 44, after which the transport independent module 42 transfers the message into the incoming message buffer 71 linked to the miscellaneous control structure 70. The conference support services module marks the message with its source, and places it into the incoming message queue 60 with NGRI designation. Upon reaching the front of the incoming message queue 60, the conferencing support services module 40 processes the message, transferring an attendant message to the host application 50 instance running on the participant system 12, 13, 15.

Replies are not generated for NGR messages; moreover, if a participant system 10, 12, 13, 15 has a large message backlog in its incoming message buffer 60, the conference support services module 40 can discard any or all NGRI messages in order to ensure processing of GRI messages which may be present. This allows a participant system 10, 12, 13, 15 having a slow processing rate due to limited computational resources to process GR messages while possibly ignoring NGR messages, thus maintaining the logical flow of information during the conference.

FIG. 4 is a flowchart providing an overview of the operation of the preferred method of the present invention. The preferred process begins in step 90 with a first participant system 10 initializing its conferencing module 46 and assuming the roles of moderator and presenter. Next, in step 92, additional participant systems 12-15 join the conference as attendees, after which the moderator designates one participant system 10, 12-15 as the presenter in step 93. The presenter controls the conference activities on all participant systems 10, 12-15 throughout the presentation in step 94. Upon completion, the presenter relinquishes control to the moderator, and the moderator may then terminate connections between participant systems 10, 12- 15 in step 95.

Referring now to FIG. 5, a flowchart of the preferred method for initializing a conference is shown. In step 100, a user wishing to initialize a conference first turns on their participant system 10, 12-15, and in step 101 runs the host application 50 program. The user instructs the host application 50 to begin conferencing in step 102. In step 103, the conference support services module 40 initializes the transport independent 42 and transport dependent 44 modules. If any hardware such as buffers or control circuitry comprise the transport dependent 44 modules, this step is performed by loading this hardware with an initial set of values. For any software comprising the transport independent 42 or transport dependent modules, initialization is accomplished through allocating data structures and setting their contents to a known value or null. The initialization in step 103 may also cause the transport dependent module 44 to set values within hardware comprising the participant system's 10, 12-15 data transport means. In steps 104 and 105, the conferencing module 40 and a participant control structure 62-65 are respectively initialized in like manner. In step 106, the participant systems 10, 12-15 determine whether it is to be the moderator of the conference. Since the participant control structure 62-65 does not contain information related to any given participant system 10, 12-15 at this point, it is blank. If the user is acting as the moderator, the conference support services module 40 initiates a listen process through the transport independent module 42 in step 107, which directs the transport dependent module 44 in determining if another participant system 12-15 requires connection to the conference. If the user is not the moderator, the conference support services module 40 initiates a call moderator process through the transport independent module 42 in step 108. This process instructs the transport dependent module 44 as to how to reach the moderator to join the conference. For instance, if the participant system 12-15 will be coupled to the moderator through a modem connection, the transport independent module 42 will pass the moderator's telephone number and a call directive to the appropriate transport dependent module 44. After initiating either the listen process or the call moderator process, the conference support services module 40 returns to the host application 50.

FIG. 6 is a flowchart of the preferred monitoring process performed by the moderator during the conference. In step 110, the moderator investigates all participant control structures 62-65 and checks for status changes. Then in step 111, the preferred method checks for completion of tasks previously known to be in progress. Next, in step 112, the method tests or determines if a new participant system 12-15 has been connected. This can be determined by checking whether there is at least one blank or null participant control structure in the moderator's conferencing module 46. If the status of the blank participant control structure 62-65 indicates a new participant has been connected, the preferred method initiates a process to send conference data such as slides or spreadsheet numbers to the newly connected participant system in step 113. A replacement blank participant control structure 62-65 is created and added in step 114, and a process is initiated in step 115 to connect another new participant system 12-15 to the conference. If it is determined in step 112 that no new participants have been connected, the method proceeds directly to step 116. In step 116, the method processes any messages generated by the host application 50, after which the processed messages are sent to one or more participants in step 117. Any required notification messages are next sent to the host application 50 in step 118. The sequence of events in FIG. 6 may be initiated by a timer or by host application 50 polling, and is repeated continually during the conference at predetermined intervals. FIG. 7 shows the preferred method undertaken by the moderator to terminate the conference. First in step 130, the user inputs a command to terminate the conference. Then in step 131, the moderator completes all in- progress transactions, in which case the moderator's message processing unit 30 no longer accepts incoming messages and any messages remaining in the outgoing message queue 56 are processed. If the termination command in step 130 called for immediate termination action, these messages in the outgoing message queue are ignored. The moderator sends a termination notification message to all attendees' participant systems 12-15 in step 132, and closes conference processes such as message transfer in step 133. In the preferred method, the moderator's conference support services module 42 obtains low- level acknowledgment of the termination message receipt by the other participant systems 12-15, and then physically terminates the data transport connection. In step 134, the transport independent 42 and transport dependent 44 modules are deinstalled. If the transport independent 42 or transport dependent 44 modules comprise any hardware, this involves resetting any control circuitry and buffer contents to a set of values indicating they are no longer in use. For any software, memory used for each respective module's control software and data structures is released.

A single message generated by the host application 50 and to be sent may give rise to a plurality of processes occurring within the conference support services module 40, most of which are transparent to the host application 50. The preferred method for sending a host application message through the conference support services module 40 process is illustrated in the flowchart of FIG. 8. Beginning with step 140, the conference support services module 40 selects a first participant system 10, 12-15. In step 142, the conference support services module 40 initiates or verifies that this participant system 10, 12-15 is performing an operation. The conference support services module 40 determines whether an error occurred during this operation in step 144. In the presence of an error, error processing occurs in step 148. The conference support services module 40 next determines if the process can proceed on another participant system 10, 12-15 in step 150. If not, an error message is returned; otherwise, processing continues with the selection of another participant in step 152. In the absence of an operational error in step 144, the conference support services module 40 determines in step 154 if the process has been completed. If not, it updates control information in step 156, and then determines if more participants need to be considered in step 158. More participants result in the selection of another participant in step 152. After another participant system is selected, the method returns to step 142.

If the test in step 154 indicates process completion, the conference support services module 40 determines in step 160 if more processing is required. If so, the additional processing is performed in step 162. If not the method proceeds directly to step 164. Regardless of additional processing requirements, in step 164 the conference support services module 40 checks whether a notification message must be sent immediately to indicate process completion. Immediate notification results in returning with a status of "immediate success." in step 168. If immediate notification is not required, the conference support services module 40 proceeds at step 156 to update control information.

After all participants have been considered, the conference support services module 40 determines if any operations are still in progress in step 166. Any operations still in progress indicate at least one participant system 10, 12-15 has not completed a process which the conference support services module 40 initiated earlier. If operations are still in progress, a pending status is returned; otherwise, the status is set to done upon return. The actions performed in the flowchart of FIG. 8 are undertaken by each participant system's 10, 12-15 conference support services module 40 in order to process messages received from the host application 50 or other participant systems 10, 12-15, and to send messages to other participant systems 10, 12-15.

Referring now to the flowchart of FIG. 9, a preferred conference support services module 40 process for receiving a message from another participant system 10, 12-15 is shown. In step 180, the conference support services module 40 selects a first participant system 10, 12-15, after which it determines in step 182 if there is currently either a message in the incoming message buffer 66-69 linked to the participant control structure 62-65 corresponding to this participant system, or if an error occurred during message receipt. If no message is present and no error occurred, the conference support services module 40 next considers another participant system 10, 12-15 in step 184. The presence of a message or an error in step 182 causes the conference support services module 40 to determine in step 186 which case needs consideration. If an error occurred, it is processed in step 188, after which the conference support services module 40 checks whether processing can continue for another participant system 10, 12-15. If the processing must end, an error message is returned. Otherwise, the conference support services module 40 returns to step 184 to consider another participant system 10, 12-15. If no message receipt error was found in step 186, the conference support services module 40 determines if the process has completed. A process which is still in progress causes the conference support services module 40 to update control information in step 194, and to check if additional participant systems 10, 12-15 need to be considered in step 196. If so, the process returns to step 184 to select another participant system 10, 12-15. If the test performed in step 192 indicates that the process has completed, the conference support services module 40 marks the appropriate incoming message buffer 66-69 with the message source in step 198, and in step 200 places the contents of the buffer in the incoming message queue 60. In a hardware implementation, the incoming message buffer is cleared in step 202, while in a software implementation, the conference support services module 40 obtains a new buffer. In step 204, the conference support services module 40 issues a new receive message command to the transport independent layer 42. Processing subsequently proceeds from the control information update in step 194. When all participants have been considered, the conference support services module 40 determines whether any operations are still in progress in step 206. If operations are in progress, a pending status is returned, otherwise a done status is returned.

FIG. 10 shows a flowchart for a preferred conference support services module 40 process for sending a message to other participant systems 10, 12-15. In step 220, the conference support services module 40 selects a first participant system 10, 12-15, after which it investigates the participant control structure 62- 65 corresponding to this participant system 10, 12-15 in step 222 in order to determine if it had previously set the status of this participant system 10, 12-15 to sending. If not, the conference support services module 40 checks if the end of the outgoing message queue 56 has been reached in step 224. An end-of- queue situation results in a check for more participants in step 256, and if more participants are present, selection of another participant system in step 226. In the absence of an end-of-queue situation, the conference support services module 40 tests in step 228 whether the current queue message is meant to be sent to this participant system 10, 12-15. A message meant for another participant system 10, 12-15 results in an attempt to select the next message in step 230, after which the process continues with step 224. A message directed to the current participant system 10, 12-15 causes the conference support services module 40 to initiate the message send process via the transport independent layer 42 in step 232.

If the conference support services module 40 found that the participant system's 10, 12-15 status had been set to sending in step 222, it determines if the last send has been completed via a query of the transport independent module 42 in step 234. If the transport independent module has not completed the last send, processing continues with step 226 in the selection of another participant system 10, 12-15 and returns to step 222. Completion of the last send causes the conference support services module 40 to update control information in step 236, and to mark outgoing message queue 56 in step 238 as having sent the message to this participant system 10, 12-15. Processing proceeds with step 230 in order to select the next message in the queue, and continues in step 224 to test for the end of the queue.

After a message send process is initiated in step 232, the conference support services module 40 checks for an error in step 240. An error results in error processing in step 242, and a determination of whether processing can proceed in step 244. If processing can continue, it proceeds at step 226 with the selection of another participant system 10, 12-15; otherwise, an error message is returned. If no error was found in step 240, the conference support services module 40 tests if the current participant system 10, 12-15 has completed the process in step 246, in which case the conference support services module 40 marks the outgoing message queue in step 248 to indicate that the message has been sent to this participant system 10, 12-15, followed by moving a pointer to the next message in the queue 252. Regardless of the outcome of the process completion test in step 246, processing proceeds at step 252 with a control information update, after which the conference support services module 40 sets optimization flags in step 254. The optimization flags reflect a participant system's 10-12,15 status and most recent activities. Next, in step 256 the conference support services module 40 determines if additional participant systems require consideration, in which case processing is transferred to step 226 for selection of another participant system 10, 12-15. If no participant systems 10, 12-15 remain, the conference support services module 40 tests if any operations are still in progress. Operations in progress result in the return of a pending status, while completion of all operations results in return of a done status. The return status is reflected in the optimization flags. With reference to Figures 8, 9,. and 10, the return status is one mechanism which allows the multiple computer conferencing system and method to function independently of attendees' processing rates. A pending status returned from a given process indicates that operations are still in progress, and ensures that the conference support services module 40 will return to this process at a later time. Upon returning to the process, the conference support services module 40 updates participant system's 10, 12-15 status and possibly initiates the process again across a plurality of participant systems 10, 12-15.

The manner in which the conference support services module 40 treats participant processes also ensures that the conference proceeds independently of attendees' participant system 10, 12-15 processing rates. The conference support services module 40 initiates or enables a given asynchronous process directed to a participant system 10, 12-15. Without waiting for participant system 10, 12-15 response or process completion, it subsequently considers another participant system 10, 12-15 or proceeds with other activities, which may include initiation of other processes. For example, in a send-message process involving a GRO message, the conference support services module 40 initiates the send, and proceeds with other activities without waiting for the corresponding incoming message acknowledging participant system 10, 12-15 receipt. The incoming acknowledgment message will be processed at a later time, thereby preventing unnecessary delays in conference activities. While the present invention has been described with reference to certain preferred embodiments, those skilled in the art will recognize that various modifications may be provided. For example, modifications might include, but would not be limited to, the addition of other operations beyond those of appendix A. These and other variations upon and modifications to the preferred embodiment are provided for by the present invention which is limited only by the following claims. APPENDIX A A partial list of conference support services module processes is as follows:

Process Description

CheckListen Check status of existing listens for participant systems attempting to join the conference

IssueNewListen On completion of an existing listen, because a potential participant system has called

CancelCurrentListen Performed if resources are limited

CheckCall Checks status of an attempt to call moderator

CheckNewUsers On the moderator participant system, verifies attendee's attempt to join the conference via a series of handshaking messages

Checkjoin On attendee's participant system, check progress of handshaking process to join the conference

SendNextGR Sends next GR message in the outgoing message QueuedMessage queue

CheckGRSend Checks status of existing GR sends

SendNextNGR Send next NGR message in the outgoing message QueuedMessage queue

CheckNGRSend Checks status of existing NGR sends

CheckReceive Checks status of existing receives

GetNextQueued Retrieves next message from incoming message Message queue and attempts to pre-process if possible. Returns message to host application.

Claims

WHAT IS CLAIMED IS:

1. A computer conferencing system for displaying computer images at a plurality of remote locations, the computer conferencing system comprising: a first participant computer system having a first message processing unit and an input/output port, the first message processing unit for sending and receiving messages to and from the input/ output port, the first message processing unit controlling a program operating on the first participant computer system; and a second participant computer system having a second message processing unit, and an input/output port, the second message processing unit for sending and receiving messages to and from the input /output port of the second participant computer system, the second message processing unit controlling a second program operating on the second participant computer system, the input/output port of the second participant computer system coupled to the input/ output port of the first participant computer system.

2. The system of claim 1, wherein the first and second participant systems further comprise: a display device for converting a signal to an image and having an input for receiving a signal representing images to be displayed; an input device having an output for sending signals in response to user manipulation of the input device; a central processing unit (CPU) for processing and outputting data, said CPU having inputs and outputs for receiving and sending data respectively, an input of the CPU coupled to the output of the input device, an output of the

CPU coupled to the input of the display device; a memory means for storing data, the program and routines executable by the CPU, the memory means having inputs and outputs for sending and receiving data, the inputs and the outputs of the memory means coupled to the outputs and inputs of the CPU respectively; and wherein the first and second message processing units are coupled to their respective CPUs to control the operation of the CPU, memory and the display device.

3. The system of claim 2, wherein the first and second participant systems further comprise: a switch means having a data input, a data output, and a control input for selectively allowing data to pass between the data input and the data output, the switch means coupled between the input device and the CPU of the second participant system, the control input of the switch means coupled to receive a signal from the second message processing unit; and wherein the switch means selectively allows data to pass in response to a signal from the second message processing unit to deactivate the input device of the second participant computer system.

4. The system of claim 1, further comprising: a third participant computer system having a third message processing unit, and an input/output port, the third message processing unit for sending and receiving messages to and from the input/output port of the third participant computer system, the third message processing unit controlling a third program operating on the third participant computer system, the input/output port of the third participant computer system coupled to the input/output port of the first participant computer system; wherein the first participant computer system is a presenter and user input to the first participant computer system is received by the first message processing unit and sent to the second and third message processing units.

5. The system of claim 1, wherein the first and second message processing units each further comprise: a conference support services module for translating commands from a host application into messages and for translating messages into commands for the host application, the conference support services module having inputs and outputs, an input coupled to receive messages from the host application and an output coupled to send commands to the host application; a conferencing module for storing, sending and receiving messages, the conferencing module having inputs and outputs, an input of the conferencing module coupled to an output of the conference support services module, an output of the conferencing module coupled to an input of the conference support services module; and a transport module for converting messages for transmission on a communications line, the transport module coupled to the communications line for sending and receiving messages, the transport module having an input and an output, the input coupled to the output of the conferencing module, and the output coupled to the input of conferencing module.

6. The system of claim 5, wherein the transport module further comprises: a transport independent module having inputs and outputs for identifying and indicating the type of communications lines provided by the participant computer system and routing messages, an input of the transport independent module coupled to an output of the conferencing module for receiving messages, and an output of the transport independent module coupled to an input of the conferencing module for sending messages to the conferencing module; and a transport dependent module having inputs and outputs for preparing messages for transmission on a selected type of communications line and decoding messages received from the transmission line, the transport dependent module coupled to the communications line to send and receive messages, an input of the transport dependent module coupled to an output of the transport independent module for receiving messages and formatting instructions, and an output of the transport dependent module coupled to an input of the transport independent module for sending messages received on the communications line.

7. The system of claim 6, wherein the transport module further comprises: a second transport dependent module having inputs and an outputs for preparing messages for transmission on a second type of communications line and decoding messages received from the transmission line, the transport dependent module coupled to the second type of communications line to send and receive messages, an input of the transport dependent module coupled to an output of the transport independent module for receiving messages and formatting instructions, and an output of the transport dependent module coupled to an input of the transport independent module for sending messages received on the communications line; and wherein the selected type of communications line is different from the second type of communications line.

8. The system of claim 7, wherein the selected type of communications line is a phone line and the second type of communications line is a line of a wide area network.

9. The system of claim 5, wherein the conferencing module comprises: a outgoing message queue having an input and an output for storing messages to be sent out by the participant system in response to signals from the conference support services module, the input of the outgoing message queue coupled to a first output of the conference support services module, the output of the outgoing message queue coupled to an input of the transport module; an incoming message buffer having inputs and an output for storing messages received from other participant systems in response to a control signal, an input of the incoming message buffer coupled to the output of the transport module; an incoming message queue having an input and an output for storing messages received from other participant systems through the transport module, the input of the incoming message queue coupled to the output of the incoming message buffer and the output of the incoming message queue coupled to an input of the conference support services module; and a participant control structure having an input for monitoring the status of the incoming message buffer and the messages in the outgoing message queue, the input of the participant control structure coupled to a control output of the conference support services module.

10. The system of claim 9, wherein the conferencing module comprises a plurality of participant control structures each having an input for monitoring the status of the incoming message buffer and the messages in the outgoing message queue, the input of the participant control structure coupled to a control output of the conference support services module; and wherein each of the plurality of participant control structures corresponds to one of the participant systems in the computer conferencing system.

11. The system of claim 10, wherein the conferencing module comprises a plurality of incoming message buffers, each incoming message buffer having inputs and an output for storing messages received from other participant systems in response to a control signal, an input of each incoming message buffer coupled to the output of the transport module, and wherein each of the plurality of incoming message buffers correspond to one of the participant control structures.

12. The system of claim 9, further comprising a second control structure having an input for monitoring the status of an incoming message buffer and the messages in the outgoing message queue, the input of the second control structure coupled to a control output of the conference support services module; and wherein the system defines messages as guaranteed receipt and non- guaranteed receipt, the participant control structure monitoring the guaranteed receipt messages in the incoming message buffer and the second control structure monitoring the non-guaranteed receipt messages in the incoming message buffer.

13. A method for conferencing a first participant system and a plurality of additional participant computer systems to operate an application program, each of the participant computer systems having an input device, an output device, memory including a host application, a message processing unit, and a central processing unit, said method comprising the steps of: running the application program on a first participant computer system and initializing the message processing unit; running the application on at least one additional participant computer system and initializing the respective message processing unit of the additional participant; establishing a communication line between each additional participant computer systems and the first participant computer system; designating one from the group of the first participant computer system and the additional participant computer systems as the presenter; operating the first participant computer system and the additional participant computer systems using the input from the presenter; and terminating the conference by disconnecting the communication line between each additional participant computer systems and the first participant computer system.

14. The method of claim 13, wherein the message processing unit of the first participant computer system further comprises a transport module, a conferencing module, and participant control structures, and wherein the step of running the application program on a first participant computer system and initializing the message processing unit further comprise the steps of: receiving input to begin conferencing; initializing the transport module; initializing the conferencing module; initializing the participant control structure by creating a participant control structure; and initiating a listening process to await for request by the additional participant systems to join in the conference.

15. The method of claim 13, wherein the message processing unit of the additional participant computer system each further comprises a transport module, a conferencing module, and participant control structures, and wherein the step of running the application on at least one additional participant computer system and initializing the respective message processing unit of the additional participant further comprise the steps of: receiving input to begin conferencing; initializing the transport module; initializing the conferencing module; initializing the participant control structure by creating a participant control structure; and initiating a call process to contact the system acting as the moderator to join in the conference, if the additional participant system will not be the moderator.

16. The method of claim 13, wherein the step of operating the first participant computer system further comprises the steps of: checking the additional participant systems for status changes; checking the additional participant systems for task completion; determining whether any new participant computer systems are requesting to join the conference; creating an additional participant control structure and initiating the connection process for each new participant computer system requesting to join the conference; sending conference data to the new participant computer systems requesting to join the conference; processing host application messages for transmission to the additional participant systems; sending processed host application messages to the additional participant systems; and sending notification messages from the message processing unit to the host application for messages received from the additional participant systems.

17. The method of claim 13, wherein the step of operating the additional participant computer system further comprises the steps of: processing host application messages with the message processing unit of the respective participant system for transmission to the additional participant systems and the first participant system through the participant system; sending processed host application messages to the first participant system; and sending notification messages from the message processing unit to the host application for messages received by the additional participant system.

18. The method of claim 13, wherein the step of terminating the conference further comprises the steps of: receiving input from the user of the presenter system that the conference is complete; completing any message transactions that are in progress; the first system notifying the additional participant systems that the conference is closing; closing the conferences processes provided by the first participant computer system; and deinstalling the transport modules of each of the additional participant computer system and the first participant computer system;

19. The method of claim 13, wherein the step of operating the first participant computer system and the additional participant computer systems includes the steps of: selecting a participant system; initiating an operation to be performed by the conferencing module for the selected participant system; determining whether the operation is complete; performing additional processing if the process is complete; updating control information; and repeating the above steps for each additional participant.

20. The method of claim 13, wherein the step of operating the first participant computer system and the additional participant computer systems includes the steps of: sending a message from the first participant computer system; receiving a message by the first participant computer system; sending a message from the additional participant computer systems; and receiving a message by the additional participant computer system.

21. The method of claim 20, wherein the message processing unit further comprises an incoming message buffer, an incoming message queue, a participant control structure and an outgoing message queue; and wherein the step of receiving a message further comprises the sub-steps of: a) selecting a participant control structure corresponding to a participant system; b) determining whether there is a message in the incoming message buffer; c) returning to the selecting step (step a) if there is not a message in the incoming message buffer; d) determining whether the receive operation is complete; e) if the process is not complete, identifying the incoming message buffer with the message source; storing the contents of the incoming message buffer in the incoming message queue; clearing the incoming message buffer; issuing a receive message command to the message processing unit; f) updating control information; and g) repeating the above steps for each additional participant.

22. The method of claim 21, further comprising the steps of: determining whether the process of receiving messages is on-going; sending a status pending command to the message processing unit if the process of receiving messages is on-going; and sending a status done command to the message processing unit if the process of receiving messages is complete.

23. The method of claim 21, further comprising the steps of: determining whether an error occurred during the process of receiving a message; processing the error; determining whether the error requires that the receive process end; returning a message error if it is determined that the error requires the receive process end; and returning to the step of selecting if it is determined that the error does not require the receive process end.

24. The method of claim 20, wherein the message processing unit further comprises an incoming message buffer, an incoming message queue, a participant control structure and an outgoing message queue; and wherein the step of sending a message further comprises the sub-steps of: a) selecting a participant control structure corresponding to a participant system; b) determining from the participant control structure if the status of the corresponding participant system is sending; c) if the status is sending, determining whether the last send operation for the selected participant control system is completed; d) if the last send operation is not complete, returning to the step a; e) if the last send operation is complete then updating control information, marking a buffer storing the message as sent, and retrieving the next message in the outgoing message queue; f) determining whether the end of the outgoing message queue has been reached; g) returning to the selecting step (step a) if the end of the outgoing message queue has been reached; h) determining whether the message is for the selected participant system; i) retrieving the next message in the outgoing message queue and returning to step f if the message is not for the selected participant system; j) initiating the message sending process; k) determining whether the sending process is complete;

1) marking the buffer as sent, and moving a message pointer of the participant control structure to the next message if the sending process is complete; m) updating the local control information and setting the optimization flags of the message processing unit; and n) repeating the above steps for each additional participant.