+

WO1995001024A1 - Procede et systeme de teleconference informatisee entre plusieurs ordinateurs - Google Patents

Procede et systeme de teleconference informatisee entre plusieurs ordinateurs Download PDF

Info

Publication number
WO1995001024A1
WO1995001024A1 PCT/US1994/006520 US9406520W WO9501024A1 WO 1995001024 A1 WO1995001024 A1 WO 1995001024A1 US 9406520 W US9406520 W US 9406520W WO 9501024 A1 WO9501024 A1 WO 9501024A1
Authority
WO
WIPO (PCT)
Prior art keywords
participant
message
module
input
messages
Prior art date
Application number
PCT/US1994/006520
Other languages
English (en)
Inventor
Nigel John Sidney Green
Original Assignee
Software Publishing Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Software Publishing Corporation filed Critical Software Publishing Corporation
Publication of WO1995001024A1 publication Critical patent/WO1995001024A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms

Definitions

  • 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.
  • 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.
  • presentation graphics programs that operate on computers.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 10 is a flowchart of the preferred method for sending messages to other participant systems.
  • 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.
  • the moderator couples with additional participant systems 12-15 as conference attendees.
  • the moderator designates one participant system 14 as a presenter, which receives control of conferencing resources such as a mouse and keyboard.
  • conferencing resources such as a mouse and keyboard
  • 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.
  • FIG. la 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the conferencing module 46 maintains a participant control structure 62-65 which interacts with the conference support services module 40.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • GR guaranteed receipt
  • 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.
  • 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.
  • NGR non-guaranteed receipt
  • 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.
  • attendee acknowledgment of each mouse movement could dramatically increase data transport traffic; mouse movements are therefore categorized as NGR 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.
  • 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.
  • NGR messages can be sent to one or more participant systems 10, 12-15 directly through network distribution.
  • 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.
  • 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.
  • the participant system 14 acting as the presenter will instruct its host application 50 instance to display the next slide.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the host application 50 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the presenter relinquishes control to the moderator, and the moderator may then terminate connections between participant systems 10, 12- 15 in step 95.
  • 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.
  • 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.
  • the conferencing module 40 and a participant control structure 62-65 are respectively initialized in like manner.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 152 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.
  • step 160 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.
  • 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.
  • 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.
  • step 188 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.
  • 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.
  • the incoming message buffer is cleared in step 202, while in a software implementation, the conference support services module 40 obtains a new buffer.
  • 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.
  • 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.
  • 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.
  • 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.
  • the conference support services module 40 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.
  • the conference support services module 40 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.
  • 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.
  • 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,.
  • 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.
  • 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.
  • GetNextQueued retrieves next message from incoming message Message queue and attempts to pre-process if possible. Returns message to host application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un système de téléconférence informatisée (11) entre plusieurs ordinateurs et un procédé qui permet de tenir une téléconférence informatisée indépendante du transfert de données et de la plate-forme matérielle à des endroits physiquement éloignés. Le système comprend une pluralité de systèmes participants (10, 12-15) couplés dans une architecture du type réseau en étoile. Un système participant sert de modérateur (10) au centre de l'architecture, un autre système sert de présentateur (14) et les systèmes participants restants servent d'assistants (12, 13, 15). Chaque système participant comprend un système informatique couplé à une unité de traitement de messages (30). L'unité de traitement de messages comprend un module de services support de conférences, un module de téléconférence (46), un module indépendant du transport (42) et un ou plusieurs modules dépendant du transport (44). Le procédé de la présente invention autorise une seule instance d'une application à partir de l'ordinateur principal afin de commander plusieurs instances d'applications à partir de l'ordinateur principal. Le transfert d'informations entre des systèmes participants nécessitant la connaissance du destinataire est acheminé vers le modérateur. Les activités de conférence procèdent indépendamment des vitesses d'exécution des assistants, et peuvent avoir lieu dans des systèmes de transfert de données à faible largeur de bande.
PCT/US1994/006520 1993-06-23 1994-06-08 Procede et systeme de teleconference informatisee entre plusieurs ordinateurs WO1995001024A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US8167593A 1993-06-23 1993-06-23
US08/081,675 1993-06-23

Publications (1)

Publication Number Publication Date
WO1995001024A1 true WO1995001024A1 (fr) 1995-01-05

Family

ID=22165664

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1994/006520 WO1995001024A1 (fr) 1993-06-23 1994-06-08 Procede et systeme de teleconference informatisee entre plusieurs ordinateurs

Country Status (1)

Country Link
WO (1) WO1995001024A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5729684A (en) * 1995-05-16 1998-03-17 Intel Corporation Method and apparatus for heterogeneous multimedia conferencing using multipoint references
WO2001067675A3 (fr) * 2000-03-03 2002-01-31 Qualcomm Inc Systeme et procede pour assurer des services de communication de groupe
EP2205039A1 (fr) * 2000-03-03 2010-07-07 Qualcomm Incorporated La méthode et l'appareil pour participer aux services de communication de groupe dans un système de communication existant
US8411594B2 (en) 2002-09-20 2013-04-02 Qualcomm Incorporated Communication manager for providing multimedia in a group communication network
US8521816B2 (en) 2010-03-19 2013-08-27 Microsoft Corporation Latency reduction in collaborative presentation sharing environment
US9668367B2 (en) 2014-02-04 2017-05-30 Microsoft Technology Licensing, Llc Wearable computing systems

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991003019A1 (fr) * 1989-08-15 1991-03-07 Group Technologies, Inc. Methode et appareillage pour la communication interactive entre ordinateurs
US5208912A (en) * 1989-11-15 1993-05-04 Hitachi, Ltd. Joint information processing system comprising a plurality of terminal apparatuses guaranteeing identicalness of data processing results

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991003019A1 (fr) * 1989-08-15 1991-03-07 Group Technologies, Inc. Methode et appareillage pour la communication interactive entre ordinateurs
US5208912A (en) * 1989-11-15 1993-05-04 Hitachi, Ltd. Joint information processing system comprising a plurality of terminal apparatuses guaranteeing identicalness of data processing results

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
H.TANIGAWA ET AL.: "MULTIPOINT COMMUNICATION CONTROL FOR DOCUMENT-ORIENTED TELECONFERENCING", 1988 INTERNATIONAL ZURICH SEMINAR ON DIGITAL COMMUNICATIONS, March 1988 (1988-03-01), ZURICH CH, pages 29 - 35 *
T.OHMORI ET AL.: "COOPERATIVE CONTROL FOR CHARING APPLICATIONS BASED ON DISTRIBUTED MULTIPARTY DESKTOP CONFERENCING SYSTEM: MERMAID", SUPERCOMM/ICC'92, vol. 2, June 1992 (1992-06-01), CHICAGO US, pages 1069 - 1075 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5729684A (en) * 1995-05-16 1998-03-17 Intel Corporation Method and apparatus for heterogeneous multimedia conferencing using multipoint references
WO2001067675A3 (fr) * 2000-03-03 2002-01-31 Qualcomm Inc Systeme et procede pour assurer des services de communication de groupe
US6477150B1 (en) 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
AU2001241951B2 (en) * 2000-03-03 2005-03-24 Qualcomm Incorporated System and method for providing group communication services
EP2205039A1 (fr) * 2000-03-03 2010-07-07 Qualcomm Incorporated La méthode et l'appareil pour participer aux services de communication de groupe dans un système de communication existant
US8077634B2 (en) 2000-03-03 2011-12-13 Qualcomm Incorporated System and method for providing group communication services
US9143484B2 (en) 2000-03-03 2015-09-22 Qualcomm Incorporated System for collecting billable information in a group communication network
US8411594B2 (en) 2002-09-20 2013-04-02 Qualcomm Incorporated Communication manager for providing multimedia in a group communication network
US8521816B2 (en) 2010-03-19 2013-08-27 Microsoft Corporation Latency reduction in collaborative presentation sharing environment
US9477383B2 (en) 2010-03-19 2016-10-25 Microsoft Technology Licensing, Llc Latency reduction in collaborative presentation sharing environment
US10509851B2 (en) 2010-03-19 2019-12-17 Microsoft Technology Licensing, Llc Latency reduction in collaborative presentation sharing environment
US9668367B2 (en) 2014-02-04 2017-05-30 Microsoft Technology Licensing, Llc Wearable computing systems

Similar Documents

Publication Publication Date Title
US5729687A (en) System for sending differences between joining meeting information and public meeting information between participants in computer conference upon comparing annotations of joining and public meeting information
EP0326263B1 (fr) Agencement de conférence de données
US5913920A (en) Indicating updates from a remote display
US5654726A (en) Screen display sharing system
US5452299A (en) Optimized transfer of large object data blocks in a teleconferencing system
US5408470A (en) Deferred synchronization of distributed objects
US7392286B2 (en) Accessories for teleconference component
US5857189A (en) File sharing in a teleconference application
US5623603A (en) Method of transferring data at adjustable levels of priorities to provide optimum response to user demands
JPH0546568A (ja) 分散アプリケーシヨン実行装置および方法
JPH0797365B2 (ja) 分散アプリケーション・プログラム実行方法
JPH05235956A (ja) データ処理システムによるメッセージの効率的な配布方法及びシステム
CN110769048B (zh) 本地与远程虚拟桌面的无缝衔接方法及系统
US7730417B2 (en) Terminal apparatus, network system, window display method, and computer program
US5163156A (en) Method for distributing messages through a mapping table which includes for each originating device a sequential list of corresponding destination devices
JPH03273352A (ja) オンライン情報処理装置
US7162699B1 (en) Mechanisms and artifacts to manage heterogeneous platform interfaces in a collaboration system
WO1995001024A1 (fr) Procede et systeme de teleconference informatisee entre plusieurs ordinateurs
US5664103A (en) System for using an independent mediator for monitoring control data and transferring selected control data to a remote computer for concurrent processing
USRE38457E1 (en) Deferred sychronization of distributed objects
EP0797796B1 (fr) Procede d'indication d'un processus de mise a jour en vue d'un affichage a distance
JPH0687556B2 (ja) データ通信方法
US20020080172A1 (en) Pointer control system
JPH07327219A (ja) 電子会議システム及び会議サーバ及び参加者コンピュータ
CN1614577B (zh) 一种基于远程直接存储访问的图形终端方法和系统

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载