USRE44395E1 - System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint - Google Patents

System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint Download PDF

Info

Publication number
USRE44395E1
USRE44395E1 US10/857,805 US85780504A USRE44395E US RE44395 E1 USRE44395 E1 US RE44395E1 US 85780504 A US85780504 A US 85780504A US RE44395 E USRE44395 E US RE44395E
Authority
US
United States
Prior art keywords
conference
endpoints
data
message
endpoint
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Lifetime
Application number
US10/857,805
Inventor
Guy G. Riddle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
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 Apple Inc filed Critical Apple Inc
Priority to US10/857,805 priority Critical patent/USRE44395E1/en
Application granted granted Critical
Publication of USRE44395E1 publication Critical patent/USRE44395E1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1827Network arrangements for conference optimisation or adaptation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • H04L65/1089In-session procedures by adding media; by removing media
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4046Arrangements for multi-party communication, e.g. for conferences with distributed floor control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/563User guidance or feature selection
    • H04M3/564User guidance or feature selection whereby the feature is a sub-conference
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/567Multimedia conference systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2203/00Aspects of automatic or semi-automatic exchanges
    • H04M2203/50Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5009Adding a party to an existing conference

Definitions

  • the present invention relates to teleconferencing systems.
  • the present invention relates to the addition of a data stream, such as an auxiliary data stream to a teleconference.
  • Teleconferencing is increasingly becoming a popular application in personal computer systems. Such applications typically allow the transfer of audio and video data between users so that they can speak and otherwise communicate with one another. Such applications sometimes also include data sharing wherein various types of data such as documents, spreadsheets, graphic data, or other types of data, can be shared and manipulated by all participants in the teleconference. Different teleconference applications perhaps residing on different hardware platforms have different capabilities. Moreover, a wide variety of features has been implemented in different teleconference applications, and the proliferation of different types of computer systems with different capacities, and different networking media has created challenges for teleconferencing.
  • the sender and the receiver have certain minimum capabilities.
  • the first system may be a high performance workstation coupled to a high performance communication medium whereas a second system may employ an earlier generation processor, operate at a substantially slower clock rate, and/or be coupled to a lower capacity communication medium.
  • Certain network capabilities such as multicast or other optimization features, may not be present in certain networking media.
  • the participants in the conference can only operate at the fastest possible configuration provided by any minimum system which may participate in the teleconference. Of course, this results in certain inefficiencies, especially if both of the participants are capable of transmitting in a higher capacity than the system with the least possible capability.
  • Another issue in teleconference applications is the ability of certain stations to participate in more than one teleconference.
  • multiple individual conferences may be desired to be merged by a user according to operating circumstances.
  • certain circumstances may change. That is, that while a single station is merging more than one conference it is participating in, a second station at a remote location may further have other operating circumstances changing (e.g., participants leaving, entering, or otherwise joining an on-going teleconference), and thus, the management of such merging operations becomes unduly burdensome.
  • a source participant may desire to provide an additional data stream to other participants in a teleconference.
  • This additional source may include, but not be limited to, video, data, audio or any other type of data available to the source participant.
  • such an additional source may include other audio information for a receiver.
  • Other types of data may also be desired to be associated with an on-going teleconference, which may be accessible to other participant in the teleconference.
  • a method and apparatus for optimizing transmission of data to a plurality of second endpoints in a system wherein a first endpoint is providing data to the plurality of second endpoints each connected by point-to-point communication channels. This may be useful in teleconferencing applications with a plurality of participants (endpoints) or broadcast server applications.
  • the first endpoint activates a multicast communication channel having a first multicast address and commences broadcast of the data over the multicast communication channel.
  • the first endpoint transmits a request message to each of the plurality of second endpoints in order to query each of the second endpoints whether they can receive transmissions broadcast to the first multicast address.
  • Certain of the plurality of second endpoints transmit an acknowledgement message if they can receive transmissions broadcast to the first multicast address, and the first endpoint receives the acknowledgement message. Then, for each acknowledgement message received from certain of the plurality of second endpoints, the first endpoint deactivates the point-to-point communication channel and the certain of the plurality of second endpoints.
  • the broadcast of the data and the multicast communication channel is terminated if at least two of the plurality of second endpoints do not transmit the acknowledgement messages containing a positive acknowledgement.
  • communication channels are maintained as point-to-point.
  • the first endpoint can receive detach messages from certain of the plurality of second endpoints, and if at least two of the plurality of second endpoints are not receiving the data, then the first endpoint can terminate the broadcast of the data and the multicast communication channel. Communication of the data in this instance also reverts to point-to-point communication channels.
  • the acknowledgement message includes a response code which indicates whether the second endpoint can receive transmissions broadcast to the first multicast address. Also, in implemented embodiments, prior to the first endpoint activating the multicast communication channel having the first multicast address, it is determined whether the single communication medium supports broadcasting to the first multicast address, and if not, multicast cannot be activated.
  • FIG. 1 illustrates an example configuration in which various embodiments of the present invention may be implemented.
  • FIG. 2 shows a typical teleconferencing display which has both media and non-media sources displayed during the course of the teleconference.
  • FIG. 3 shows a single system in which embodiments of the present invention may be implemented.
  • FIG. 4 shows an example architecture of a system employing various embodiments of the present invention.
  • FIG. 5 shows a more detailed view of the conference component illustrated in FIG. 4 .
  • FIG. 6 shows a sequence of typical conference events in a conference component which are issued to an application.
  • FIGS. 8-10 show typical exchanges of messages for different operations.
  • FIG. 12 shows a sequence of steps performed in a second endpoint receiving the messages sent from a first endpoint during the establishment of a teleconference.
  • FIGS. 13-25 show details of the messages transmitted between endpoints during various teleconferencing applications.
  • FIGS. 27a and 27b show the conferences before and after a merge operation between teleconferences.
  • FIGS. 28a-b show a sequence of steps performed by the conference component during a merge operation.
  • FIG. 29 shows an example of a merged conferences table within a single participant.
  • FIGS. 33-34 show the details of a sequence of steps performed within a participant for adding an auxiliary source.
  • FIGS. 35a-35b show an example sequence of messages which are sent between a first endpoint and a plurality of other endpoints in a networking system, and showing various messages transmitted therebetween.
  • the present invention relates to networking systems, more specifically, the present invention describes a messaging protocol for establishing and maintaining teleconference connections between a plurality of participants in a networking system.
  • Applications for this include, transmitting application and/or system capabilities between participants or potential participants in a teleconference, notifying participants of a teleconference that more than one teleconference should be merged, and addition of an auxiliary data stream to an on-going teleconference.
  • a typical system configuration in which a teleconference may take place is illustrated as 100 in FIG. 1 .
  • a first workstation 150 may communicate via teleconference with a second workstation 155 , as illustrated.
  • System 150 may include a central processing unit 150 c which is coupled to a display 150 d a video input device 150 a, and a sound input device 150 b.
  • the system 150 may communicate with over system 155 over networking medium 170 via network connection module 160 .
  • 160 may include any number of network adapters commercially available such as using Ethernet, Token Ring, or any other networking standard commercially available. Note that network adapter 160 may also include a wireless network adapter which allows transmission of data between components without a medium 170 .
  • System 150 further has a keyboard 150 e and a pointing device 150 f, such as a mouse, track ball, or other device for allowing user selections and user input.
  • a keyboard 150 e and a pointing device 150 f, such as a mouse, track ball, or other device for allowing user selections and user input.
  • a teleconference display is shown at 200 at FIG. 2 .
  • a source window such as 201
  • other media windows such as 202 or 203 for each other user with which a participant is having communication.
  • each of the windows 201 - 203 provides media information, that is, real-time audio and/or video information for bi-directional teleconferencing.
  • non-media information such as 204 may also be displayed within the teleconferencing display.
  • messaging information may also be transmitted between stations.
  • an auxiliary media source e.g. audio or video information
  • a computer system such as a workstation, personal computer or other processing apparatus 150 c or 155 c as shown in FIG. 1 is illustrated in more detail in FIG. 3.
  • 150c comprises a bus or other communication means 301 for communicating information, and a processing means 302 coupled with bus 301 for processing information.
  • System 150 c further comprises a random access memory (RAM) or other volatile storage device 304 (referred to as main memory), coupled to bus 301 for storing information and instructions to be executed by processor 302 .
  • Main memory 304 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 302 . Included in memory 304 during run-time may be the conference component module which operates according to the communication protocols to be described below.
  • System 150 c also comprises a read only memory (ROM) and/or other static storage device 306 coupled to bus 301 for storing static information and instructions for processor 302 , and a data storage device 307 such as a magnetic disk or optical disk and its corresponding disk drive.
  • ROM read only memory
  • Data storage device 307 is coupled to bus 301 for storing information and instructions.
  • System 150 c may further be coupled to a display device adapter display 321 such as a cathode ray tube (CRT) or liquid crystal display (LCD) coupled to bus 301 for displaying information to a computer user.
  • a display 321 may further be coupled to bus 301 for the receipt of video or image information.
  • An alphanumeric input device 322 including alphanumeric and other keys may also be coupled to bus 301 for communicating information and command selections to processor 302 .
  • cursor control 323 such as a mouse, a trackball, stylus, or cursor direction keys, coupled to bus 301 for communicating direction information and command selections to processor 302 , and for controlling cursor movement on display 321 .
  • system 150 c may also have coupled to it a sound output device 324 , a video input device 325 , and sound input device 326 , along with the associated D/A (Digital-to-Analog) and A/D (Analog-to-Digital) converters for inputting or outputting media signal bitstreams.
  • System 150 c may further be coupled to communication device 327 which is coupled to network adapter 160 for communicating with other teleconferencing stations.
  • system 150 c any or all of the components of system 150 c and associated hardware may be used in various embodiments, however, it can be appreciated that any configuration of the system may be used for various purposes according to the particular implementation.
  • system 150 c is one of the Apple Computer® brand family of personal computers such as the Macintosh 8100 brand personal computer manufactured by Apple Computer, Inc. of Cupertino, Calif.
  • Processor 302 may be one of the PowerPC brand microprocessors manufactured by Motorola, Inc. of Schaumburg, Ill.
  • routines which are generated in a high-level programming language (e.g., the C or C++ programming language) and compiled, linked, and then run as object code in system 150 c during run-time within main memory 304 by processor 302 .
  • object code may be generated by the C++ Compiler available from Symantec, Inc. of Cupertino, Calif.
  • FIG. 4 illustrates a plurality of processes and/or apparatus which may be operative within system 150 c.
  • an application program 401 such as a teleconferencing application, an audio/video server, or a data server, communicates with conference component process 400 in the form of Application Program Interface (API) calls.
  • the conference component 400 allows the application to establish communications between two or more teleconference stations. Control information, and media information can be transmitted between the first participant system and a second participant system.
  • the conference component will be shown in more detail in FIG. 5 .
  • Conference component 400 communicates with the transport component 402 by sending MovieTalk messages for other teleconferencing stations which are encapsulated and placed into a form that the transport component 402 , the network component 403 , and the system network component 404 can packetize and transmit over networking medium 170 .
  • MovieTalk API calls and MovieTalk messages which are transmitted between conference components in a teleconferencing system will be described in more detail.
  • the transport component 402 and the networking component 403 provide the necessary operations for communication over the particular type of network adapter 160 and networking medium 170 according to implementation.
  • networking component 402 may provide the TCP or ADSP protcols and packetizing, according to those respective standards.
  • FIG. 5 A more detailed view of the conference component 400 is shown in FIG. 5 .
  • the conference component 400 is shown in two portions 400 a and 400 b which show input and output portions of the conference component.
  • each conference component in the system has both capabilities, so that full bi-directional communication between conference components in respective participant teleconference systems in a network may communicate with one another.
  • the input portion of the conference component 400 a receives video and sound information over media input channels 510 and 520 .
  • the video channel component and sound channel component 504 present media data at regular intervals to sequence grabber 502 .
  • the real-time sound and video data (hereinafter referred to as “media data”) are provided to a source stream director 500 from sequence grabber 502 which then provides the media messages to the transport component 402 .
  • Flow Control 501 then lets the video and sound data flow through at an implementation-dependent frequency.
  • the video channel component 503 , sound channel component 504 , and sequence grabber 502 all are implemented using prior art products such as those commercially available (e.g., the QuickTime video channel, sound channel components, and sequence grabbers, available from Apple Computer, Inc. of Cupertino, Calif.)
  • Flow control 501 may be implemented using known flow control apparatus and/or method as are commercially available, such as those which regulate flow based upon bandwidth, and other constraints in the source participant system.
  • the conference component further comprises a sink stream director 510 which comprises a portion of the component 400 b of the conference component for receipt of media data from transport component 402 .
  • a sink stream director 510 which comprises a portion of the component 400 b of the conference component for receipt of media data from transport component 402 .
  • Corresponding flow control 511 , video and sound stream players 512 and 513 , and compression and sound manager 514 and 515 , for output of video streams 530 and 540 also form part of the conference component for full bi-directional conferencing capabilities.
  • the conference component's main function is to establish and maintain a bi-directional connection between every member of a conference.
  • Conferencing applications use a pre-established control channel to exchange control data that is pertinent to the conference. This data might include user identification information or other information that is germane to the application's operation.
  • Conferencing applications (e.g., 401 ) define the format and content of these control messages by establishing their own control protocols.
  • the conferencing component further establishes communication channels between a first endpoint and a second endpoint, using the underlying transport component 402 .
  • the conference component uses the transport component 402 's media channel which is provided for transmission of media and non-media information.
  • endpoints a first and second participant
  • group of participants which may participate in a teleconference.
  • API Application Program Interface
  • the application program 401 controls the conference component 400 by the issuance of MovieTalk application API calls.
  • the conference component operates using an event-driven model wherein events pertinent to the application are issued to the application program.
  • the application program can then take appropriate action either by modifying internal data structures within (creating a source or sink), and/or issuance of appropriate messages over the network to other connected participants, or potential participants.
  • the conference component can take appropriate action according to messages received by the conference component, a current context and API calls from the application.
  • any members that are new to the conference are recognized as being ready by the receipt of MemberReady (e.g. mtMemberReady) events (e.g., 602 and 603 of FIG. 6 ).
  • MemberReady e.g. mtMemberReady
  • This establishes the media sinks such as b and c illustrated in FIG. 6 .
  • other events 604 may be issued and acted upon by the conference component. These may include message events, mode events, incoming call events, data transmission events, etc.
  • Members leaving the conference result in the issuance of MemberTerminated (e.g. mtMemberTerminatedEvent) events to the application program such as 605 or 606 .
  • a corresponding MemberTerminated (e.g. mtMemberTerminatedEvent) event prior to the end of the conference.
  • the auxiliary source and the conference itself is terminated via the Auxiliary Terminated (e.g. mtAuxiliaryTerminatedEvent) event 611 and the conference terminated event 607 as illustrated in 600 of FIG. 6 .
  • This notifies the application that the conference is terminated, and teleconference data should no longer be transmitted. Any additional clean up operations are then performed by the application, and the source may be discarded.
  • a typical application's initialization is shown as process 700 of FIG. 7 .
  • the application program makes a number of API calls in order to set various parameters associated with the member or potential participant.
  • an application may cause the conference component to set its capability at step 702 if it is different than the default.
  • the call to “MTConferenceSetMessageCapabilities” causes the conference component to recall in a store the specific application capabilities within the conference component for the specific conference which are later used during transmission of messages to alert recipients that the sender application has certain functional capabilities prior to the establishment of a connection between the sender and the receiver.
  • Each capability has associated with it a type, version, and “desire” of the capability.
  • Each desire for each capability type may be flagged as:
  • a member may set its operating mode at step 704 .
  • the mode will be contained within a mode mask value which is sent in the API call to the conference component, and moreover, is included in certain messages transmitted from the conference component in the sender to the conference component in the receiver.
  • the mode mask specifies the characteristics of a conference that the member makes available. Different capabilities, modes, and other initialization operations shown in FIG. 7 may be set for any number of conference types which are made available by the member. At any rate, the default mode includes the following values:
  • the “joiner” mode flag indicates that all conference members are allowed to interact. This would allow two-way transmission between each of the conference members. However, the setting of this flag to “off” (e.g., a numeric value ‘0’) results in broadcast type conferences wherein one member sends media data to other conference members, but the individual conference members do not exchange any media data among themselves. Each of these mode flags is transmitted at the beginning of a connection (e.g., contained within the “hello” message 1400 in FIG. 14 ).
  • the conference component establishes conferences that are fully two-way media data capable, shareable, and joinable. If different characteristics are desired, then the application must call “set mode” (e.g. MTConferenceSetMode) at step 704 , along with the appropriate flag(s) set.
  • Set mode e.g. MTConferenceSetMode
  • Conference mode settings are stored and associated with a particular conference ID in the sender's conference component so that when messages are created for that conference ID, the appropriate mode flags are transmitted along with the initialization or other messages sent before any other communications.
  • a time-out value associated with calls placed from the member may be set (e.g. using the API call MTConferenceSetTimeOut).
  • the time-out value is then included at the beginning of certain messages preceding a conference in order to enable a recipient to determine when the caller will stop listening for responses.
  • This allows certain features to be incorporated into participant conference components such as the smart triggering of events based upon context. For example, if the recipient is receiving a call, but a user does not wish to take the call at that time, the recipient's conference knows the time-out occurs and can take certain context-dependent action (e.g., forward the call, send a message, etc.).
  • the application can then invoke an API call “Listen for Call” (e.g. MTConferenceListen) which implements steps 708 and 710 .
  • MTConferenceListen an API call “Listen for Call”
  • steps 708 and 710 the conference component waits for incoming calls.
  • the conference component in the member enters an idle state wherein incoming messages, alerts for the transport component, API and calls will be detected and acted upon. Note that the capabilities, mode, and time-out values are all optional, and the default settings may be used by the member if none of these functions is required by the application.
  • the application In the call to the MTConferenceListen function, the application must specify the networks on which the member is willing to accept calls.
  • the conference component proceeds to register the member on those networks, doing whatever is appropriate in the various network contexts, and sends an mtListenerStatusEvent to the application to specify whether the registration attempt was successful. After listeners are operational, if another application desires to establish communication with the application, then an mtIncomingCallEvent is forwarded to the application.
  • FIGS. 8-10 show examples of the various message exchanges between two endpoints. Messages are generated by conference component 400 depending upon operating context, and application calls.
  • FIG. 8 shows an example of a calling sequence for setting up a conference between two endpoints. Upon the commencement of a call from a first endpoint such as 810 shown in FIG. 8 , and a second endpoint such as 820 shown in FIG. 8 , a “capabilities” message 802 is transmitted from the endpoint 810 to the endpoint 820 if they have been set by the caller.
  • the exchange of “capabilities” messages 802 and 812 between endpoint 1 810 and endpoint 2 820 are exchanged after a control channel has been opened on the transmission medium between the participants in an implementation-dependent manner (e.g. by invoking MTConferenceCall). This identifies the capabilities of each of the endpoints, if the capabilities of the application are desired to be transmitted. Once capabilities have been transmitted from each endpoint, each endpoint further transmits Hello messages 804 and 814 to identify themselves. The details of the capabilities, Hello, and other messages illustrated in the figure will be discussed below.
  • the Hello message is the first step in establishing a conference, and allows conference components in different systems to exchange basic identification and mode information.
  • the endpoint 1 810 wishing to establish the conference sends a call message 806 to endpoint 2 820 .
  • endpoint 820 desires to engage in the teleconference with endpoint 1 810 , it sends a response message 816 to endpoint 1 810 .
  • a teleconference is then established between endpoint 1 810 and endpoint 2 820 .
  • FIGS. 11 and 12 The details of the process steps performed within each endpoint are discussed with reference to FIGS. 11 and 12 .
  • FIG. 9 illustrates a “Join” protocol process. This is similar to the calling process, however, a “Join” message 906 is sent to the second endpoint instead of the “call” message 806 .
  • the details of a Join are discussed with reference to FIGS. 26a-26c below.
  • FIG. 10 illustrates the messages exchanged for a terminate message. As illustrated, an endpoint may issue a terminate message to terminate a teleconference. No response is required for any receivers.
  • FIG. 11 shows the process steps performed by a first participant (e.g., endpoint 1 810 ) wishing to establish communication with a second participant system (e.g., endpoint 2 820 ).
  • a first participant e.g., endpoint 1 810
  • a second participant system e.g., endpoint 2 820
  • the caller via implementation-dependent means, accesses the address of the party it wishes to call, either by reference to an internal store, referencing a server or other implementation-dependent manner.
  • the application invokes the API call MTConferenceCall in order to call the party at step 1104 .
  • a failed event 1106 (mtFailedEvent) is received by the caller, or a ringing event 1108 (mtPhoneRingingEvent) when the call message has been transmitted to the second participant.
  • the endpoint can then get the capabilities, mode and the name of the endpoint such as by examining the data contained in the Capabilities message 812 and/or the Hello message 814 . Any “required” communication between the caller and receiver may also be performed. Then, the first sender can appropriately configure itself for the second endpoint. Once any necessary message exchanges and/or configurations have been performed in the caller, then the caller will either receive a MemberRefused event 1112 (e.g.
  • mtRefusedEvent for example, if the calling member does not provide the necessary access control subsequent to the call message, or, a MemberReady event 1116 . Also, a failed event 1106 can be detected at any time, followed by a MemberTerminated event 1114 . In the case of a MemberRefused event 1112 , then the conference component will generate a MemberTerminated event 1114 , and a conference terminated event will then be issued indicating the end of the conference. Once capabilities have been obtained, any required capabilities are checked for at step 1113 (e.g. such as any actions that must be performed before the receiver accepts the call). Subsequent thereto, a ConferenceReadyEvent 1115 (e.g.
  • MTConfReadyEvent MTConfReadyEvent
  • a MemberReady event 1116 e.g. mtMemberReadyEvent
  • the endpoint can then engage in the exchange of messages typical during a conference, thus commencing the conference at step 1118 .
  • the receiver application will detect an incoming call event 1202 . Subsequent thereto, the receiver can then determine mode, capabilities, caller's name, conference name, and/or return address of the party wishing to engage in the conference. The mode can also be checked for at step 1206 . Once this has been done, then a time-out check, if any, at 1208 can be performed in the receiver. The time-out check may be performed, depending upon an application's implementation, by checking the time-out field shown at field 1504 in FIG. 15 , which indicates how long the transmitter will wait prior to timing out and generating a CallFailed event (e.g.
  • the receiver may do a variety of things, for example, issuing a busy signal to the transmitter, issuing a message to the caller or, taking some action, such as forwarding the call to another party.
  • the embedding of the time-out field 1504 within the initial connection message “Hello,” provides for certain intelligent features in the potential participants of a teleconference.
  • the reply may indicate either refusal to answer the call (e.g., due to access control, or the participant already engaging in another conference), or choose to respond to the call in the affirmative indicating that the teleconference may commence.
  • the MemberTerminated 1220 event (mtMemberTerminatedEvent) is issued to the application.
  • the MemberReady event 1218 (mtMemberReadyEvent) is issued indicating that the medium channel is open and the conference can commence.
  • Conference components exchange a number of messages in order to establish, maintain, and terminate conferences. Conference components also send messages that encapsulate user data, that is, the data that is exchanged by the programs that are using the conference.
  • a conference member may send either a Capabilities message 1300 or an Auxiliary message 1700 .
  • the member then sends a Hello message 1400 to identify itself, specifically its mode of operation (send media, receive media, shareable, or joiner) followed by a Call message 1500 (to set up a conference) or a Join message 1800 (to join to an ongoing conference).
  • the remote member sends a Response message 1600 in answer to the Call or a Join message 1800 .
  • a member can combine calls or conferences by sending a Merge message 1900 .
  • Conference members may send or receive a Terminate message 2300 to end a conference.
  • Connections initially are point-to-point between members of a conference. If the transport medium supports multicast addresses and more than one member is participating in a conference, a broadcast to a multicast address can be used as an optimization.
  • the conference component uses the BroadcastRequest and BroadcastAck messages 2400 and 2500 to negotiate the transition from point-to-point to multipoint connections using multicast addresses.
  • Capabilities message 1300 allows a potential member to tell other potential conference members what it can and cannot do in a conference. Each member sends this message before sending the “Hello” message ( 1400 of FIG. 14 ) if capabilities other than the default are supported.
  • Field Size Value type 1302 2 bytes ‘K’ delimiter 1304 1 byte newline capabilitiesList 1306 0-n bytes (alphanumeric) terminator 1308 1 byte NULL capabilitiesList 1306
  • the Capabilities message 1300 shown in FIG. 13 informs other potential conference participants about a member's capabilities. These capabilities relate directly to messages the member either supports or requires, one capability for each conferencing message type that the component supports.
  • the messages themselves are defined by the type of application the member is running. For example, video-phone applications and chat lines deliver different services, and use different messages to do so. As a result, the capabilities a member supports will change in light of the application that is participating in the conference. Entries in the capabilitiesList field may request information from the remote system.
  • mtNegotiationMessageCapabilities (‘N’)
  • a conference member can query for specific information (e.g. about a given component type, such as a codec, hardware/software features supported, etc.).
  • the type field can contain the component type value.
  • the remote member In response to a negotiation Capabilities message, the remote member formats a user data message, for example, containing available component subtypes. Note that this list may contain duplicate entries and entries with a value of NULL. To parse this array, a member must determine the array's size. After sending a Capabilities message 1300 , the member sends a Hello message 1400 to establish a conference.
  • a Hello message (e.g., 1400 of FIG. 14 ) is sent at the start of a conference by each endpoint.
  • the Hello message identifies basic capabilities of the sender and the mode in which it will overate. It contains the following:
  • Field Size Value type 1402 2 bytes ‘H’ MinimumVersion 1404 1-n bytes (numeric) delimiter 1406 1 byte colon maximumVersion 1408 1-n bytes (numeric) delimiter 1410 1 byte newline conferenceMode 1412 1-n bytes (numeric) delimiter 1414 1 byte newline name 1416 1-n bytes (alphanumeric) delimiter 1418 1 byte newline terminator 1420 1 byte NULL minimum Version 1404
  • the Hello message 1400 is the first step in establishing a conference. This message allows conference components on different systems to exchange basic identification and capability information.
  • a conference component may send either a Capabilities 1300 or an Auxiliary message 1700 .
  • the type of message sent depends upon the role the member anticipates playing in the conference. If the member is looking to join or start a conference, the conference component sends a Capabilities message. If the member is setting up an auxiliary media data source, the component sends an Auxiliary message 1700 . Following this message, the conference component can enter the call setup phase by sending the Call message 1500 . If the member wants to provide an auxiliary data source to an existing conference, or join an existing conference, the component sends the Join message 1800 .
  • Call message 1500 of FIG. 15 begins the process of establishing a conference connection between two possible participants. This is akin to dialing a number from a phone directory.
  • Field Size Value type 1502 2 bytes ‘C’ callTime-out 1504 1-n bytes (numeric) delimiter 1506 1 byte tab ConferenceName 1508 1-n bytes (alphanumeric) delimiter 1510 1 byte newline callingConfID 1512 1-n bytes (alphanumeric) delimiter 1514 1 byte newline terminator 1516 1 byte NULL callTime-out 1504
  • the Call message 1500 shown in FIG. 15 begins the process of establishing a conference between two participants.
  • This message can be used in two ways. First, this message can create a conference between two participants. In this scenario, the caller assigns a name to the conference, so that other possible participants may join later. Alternatively, this message can request to join a conference that is managed by a conference server on a network. For example, the server will allow incoming calls, but the function of the server is to merge the new conference due to the call with other ongoing conferences. In other words, the server acts exclusively as a “joiner” and does not supply media data. Once the call is set up, the caller can begin exchanging user data with other conference participants.
  • the response message 1600 of FIG. 16 is sent in response to Call or Join messages 1500 or 1800 .
  • Field Size Value type 1602 2 bytes ‘R’ callResponse 1604 1-n bytes (signednumeric) delimiter 1606 1 byte newline destinationConfID 1608 1-n bytes (alphanumeric) delimiter 1610 1 byte newline terminator 1612 1 byte NULL callResponse 1604
  • the auxiliary message 1700 allows one member to alert the other members of a conference that it is about to provide an auxiliary media data source (a source associated with an ongoing conference). This message may be used in place of the Capabilities message 1300 if a participant is being alerted about the presence of an auxiliary media source. The member sends this message before sending the Hello and Join Messages 1400 and 1800 , and then proceeds to adding an auxiliary data source to the conference.
  • Field Size Value type 1702 2 bytes ‘A’ parentConfID 1704 1-n bytes (alphanumeric) delimiter 1706 1 byte newline terminator 1708 1 byte NULL parentConfID 1704
  • the Auxiliary message 1700 informs other conference participants that a member is about to provide an auxiliary conference data source. For auxiliary data sources, this message replace the Capabilities message during early interactions. The member must send this message to each conference participant. The member then sends a Hello 1400 and a Join message 1800 to each participant. Other participants then accept the new data source by accommodating the Join request.
  • a Join message 1800 of FIG. 18 allows a member to join an existing conference, given that conference's identifier. This message is useful for adding auxiliary data sources to an existing conference, and for merging two existing conferences.
  • the Join message 1800 allows a member to add an auxiliary data source to an existing conference or to merge two existing conferences.
  • the caller sends this message to members of the conference in response to a merge or join request instead of a call message.
  • the Merge message 1900 of FIG. 19 combines two conferences. Recipients of this message connect with the listed members with whom they are not already connected.
  • Field Size Value type 1902 2 bytes ‘M’ conferenceName 1904 1-n bytes (alphanumeric) delimiter 1906 1 byte newline myConfID 1908 1-n bytes (alphanumeric) delimiter 1910 1 byte newline memberList 1912 0-n bytes (alphanumeric) terminator 1914 1 byte NULL conferenceName 1904
  • the Merge message causes the combination of two conferences. This is the mechanism for creating conferences with more than two participants.
  • the caller sends this message to each existing conference member, specifying the conference's name.
  • Each endpoint establishes communications with any new endpoints. By convention, the endpoint with the higher conference identifier value establishes the connection (to avoid duplicate or missed connections).
  • Members of the conference receive a Join message 1900 instead of a Call message 1500 when contacted by each new member.
  • a capabilities list such as shown in FIG. 20 contains information about the message supported by a conferencing application.
  • the list consists of zero or more lines of information; each line specifies a single capability and consists of the following fields.:
  • Field Size Value type 2002 4 bytes (alphanumeric) delimiter 2004 1 byte tab version 2006 1-n bytes (numeric) delimiter 2008 1 byte tab desires 2010 1 byte (alphanumeric) delimiter 2012 1 byte newline type 2002
  • Conference identifiers such as 2200 shown in FIG. 22 uniquely identify a conference endpoint. Each endpoint represent a data source or sink for the conference. Note that a single system may have more than one conference endpoint (e.g., an auxiliary) in a given conference, and may have more than one conference at a time.
  • a conference endpoint consists of the following fields:
  • a member list such as 1812 of FIG. 21 is an array of zero or more conference identifiers 2102 , 2110 , etc. Each entry in the array is delimited by a newline character.
  • Terminate message 2300 of FIG. 23 ends a conference, closing a member's communications with the participants to which it sends the message.
  • Terminate message 2300 is the last step in ending a member's participation in a conference. This message ends the member's conference communication with all participants to which it sends the message. If a member is leaving a conference altogether, it must send this message to each conference participant.
  • the BroadcastRequest message 2400 allows a member to find out if another conference member can accept broadcast (multicast) messages.
  • Field Size Value type 2402 2 bytes ‘B’ subtype 2406 1 byte ‘R’ delimiter 2408 1 byte tab multicastAddress 2410 1-n bytes (alphanumeric) delimiter 2412 1 byte newline terminator 2414 1 byte NULL subtype 2406
  • the BroadcastRequest message 2400 allows a member to determine whether another conference member can accept broadcast messages over a given multicast network address.
  • the recipient indicates its ability to support the broadcast messages by sending a BroadcastAck message 2500 (described below). If the recipient cannot support broadcast messaging or cannot access this particular broadcast transmission, the calling member should continue to send point-to-point messages to the recipient.
  • the BroadcastRequest message 2400 is typically uses as part of the negotiation process that follows merging two conferences or the joining of any new members to a conference. As an optimization, conference participants may choose to set up broadcast capabilities as a more-efficient alternative to maintaining several different point-to-point connections.
  • the BroadcastAck message 2500 allows a member to respond to a BroadcastRequest message 2400 .
  • Field Size Value type 2502 2 bytes ‘B’ subtype 2504 1 byte ‘A’ delimiter 2506 1 byte tab broadcastResponse 2508 1-n bytes (signed numeric) delimiter 2510 1 byte newline terminator 2512 1 byte NULL subtype 2504
  • the BroadcastAck message 2500 allows a member to indicate whether it can receive messages over a proposed multicast address.
  • Another conference participant proposes a multicast address by sending a BroadcastRequest message 2408 . If the recipient can support that address, it sets the broadcastResponse field 2508 to ‘0’. Otherwise, the broadcastResponse field 2580 contains an appropriate non-zero result code.
  • This message is typically used as part of the negotiation process that follows merging two conferences. As an optimization, conference participants may choose to set up broadcast capabilities as a more-efficient alternative to maintaining several different point-to-point connections.
  • FIGS. 26a-26c illustrate the process steps performed in a transmitter and receiver during join operations.
  • FIG. 26a shows a process 2600 which includes the process steps performed by a transmitter of a join message or any message containing a member list. This may occur, for example, responsive to an auxiliary or merge message.
  • the transmitter creates a join message at step 2602 .
  • the destination conference ID and calling conference ID's are added to the message at step 2603 .
  • a member is appended to the members list in the join message. This is shown in more detail in FIG. 26b .
  • a transport level connection with the member to receive the join is then performed at step 2605 . Subsequent thereto, the message is then sent to any recipients at step 2606 .
  • FIG. 26b illustrates the “append members” function 2604 shown in FIG. 26a for appending members to a member list.
  • the function starts at step 2610 which determines whether the member is a “joiner.” If so, then additional members can be appended to the join. If not, then the function ends and the join message with the single member is transmitted as shown on FIG. 26a .
  • the next member is retrieved according to the conference ID.
  • FIG. 26c shows the steps performed by a receiver of a join message.
  • the destination conference ID contained in the join message is looked up by the receiver in a locally-stored current conferences history table (e.g. 2900 of FIG. 29 ). This keeps track of previously used conference ID's for any currently active conferences. If the conference ID has changed, the member can then complete the join by referencing an old conference ID and the current conference ID in the member. This allows for conference merge and auxiliary messages from widely distributed members in a network. If the conference ID can't be found, as detected at step 2654 , then the connection is refused at step 2656 , by the issuance of an appropriate response message, and the join fails.
  • the connection is added to the list of participants for the conference.
  • a Response message that the join can be performed is sent to the sender of the join. Then, the membership of the members contained in the member list of the join can then be performed as shown in FIG. 26d .
  • the merge membership function 2664 is shown in more detail in FIG. 26d .
  • transport level connections are established. Once established, capabilities, if any, (or an auxiliary message, in the case of an auxiliary source), hello, and join messages are sent at step 2690 . The member then waits for a response to the join, and if received in the affirmative, the conference component issues MemberReady to the application. This process continues until all members in the member list have been processed.
  • Merge operations are initiated using a “Merge” message (e.g., 1900 of FIG. 19 ) which indicates to a participant that two existing conferences should be merged. This is according to the conference ID contained within the field 1908 of Message 1900 .
  • Each Merge message contains within it a memberList 1912 which allows the participating members to transmit Join messages to all the members which have been listed in the memberList. This further allows changing membership and conference ID during the course of a merge operation to be tracked so that correct conference ID's and conference membership may be maintained until after the merge.
  • a merge operation is graphically illustrated with reference to FIGS. 26a and 26b . For example, at a first time period as illustrated in FIG.
  • conference member ID may be engaging in two conferences denoted 1 and 2 with several other members, A, B, and C.
  • the member then proceeds to issue Merge messages to the members of conferences. That is, member D issues join messages to members A, B and C to Merge the conference 2 (denoted B 1 and C 1 ).
  • members A, B, C, and D all have point-to-point communication channels and the new conference ID is the same, (A 1 , B 1 , C 2 , D 1 , respectively in each of the members).
  • the mechanics of this operation are described briefly with reference to FIGS. 28a-28b . That is, the two separate conferences are now denoted by the same conference ID's in each of the members.
  • FIGS. 28a-28b show the steps taken during a merge operation by the conference component in the transmitter and receivers (if any) of a merge message.
  • FIG. 28a shows the process steps taken by a transmitter of a merge request.
  • the member first combines the conference ID's of the old and new conference in it's internal store at step 2802 .
  • the member creates the merge message and appends each of the members of the conference to the members list in the message via the append members routine 2604 (discussed above) in order to ensure full connectivity among all conference members.
  • the merge message is sent to all participants in the merge.
  • FIG. 28b shows process steps taken in a receiver receiving a merge message.
  • the merge recipient recalls in a local store for example, the conference name and the conference ID at step 2814 .
  • a merger of membership is performed (e.g. process 2664 ), and the process is thus complete at step 2816 .
  • each Merge and Join message contains a list of members of the conferences being merged or joined. These are included in the memberList fields 1812 or 1912 of messages 1800 or 1900 . For example, due to propagation delays in a networking system, old conference ID's may still exist in peripheral participants, and therefore during merging and or joining operations, conference ID's may become invalid due to members merging conferences, etc. . . . , or reference conference ID's which no longer exist.
  • a current conferences table such as 2900 shown in FIG. 29 .
  • the current conferences history table allows a member performing a merge or join operation to determine whether in fact conferences to be merged use old conference ID's.
  • the new conference ID may be used to transmit to the participants receiving the join messages, and/or be matched to the appropriate conference ID.
  • the member performing the merge operation can reference by way of the current conference ID 2901 contained within the merged conferences table, or other conference ID values 2902 , containing a variable length list of conference ID's, to which the current conference ID refers.
  • Conference entries are deleted at the end of a conference by the conference component. If a merge occurs at a peripheral location and a conference ID becomes invalid, then the list of conference ID's for an existing conference ID can be referenced by referencing the merged conferences history table.
  • FIGS. 30a and 30b illustrate a process which is performed as an optimization if multiple participants within a conference support multicast address broadcast capabilities.
  • a multicast address which may be used for the transport medium is retrieved at step 3012 .
  • Broadcast Requests are sent in substantially the format as shown in Message 2400 of FIG. 24 , to all the participants detected at step 3002 supporting multicast.
  • the process then awaits BroadcastAck (in the format 2500 shown in FIG. 25 ) in order to determine whether the multicast address is available for each at step 3016 . If so, then for each BroadcastAck determined to be received at step 3018 , and it is determined whether the BroadcastAck was positive (due to the response value contained in field 2508 of FIG. 25 ). At step 3022 , if the response was positive, then the point-to-point connection is deactivated.
  • step 3024 determines whether there was a Broadcast Ack received for each Broadcast Request message sent. If not, then the process is complete. If so, however, step 3026 determines whether there were any positive BroadcastAck for the multicast. If not, then multicast is deactivated, and point-to-point communication continues to be used for communication with the other members (this optimization cannot be performed). The process is thus complete.
  • An auxiliary media source can become part of an ongoing conference.
  • the media source is associated with an ongoing conference by a invoking reference to the main conference stored in each conference component (e.g. by the API call MTConferenceAttachAuxiliarySource), however, it is treated as a separate conference in each conference component.
  • a first conference referred to by conference ID 23 B in member B may be notified of an auxiliary source having conference ID 17 A from member A.
  • the Auxiliary message may be sent in place of a Capabilities message between a first endpoint and a second endpoint as illustrated in FIG. 32 .
  • the timing of the messages is illustrated with reference to FIG. 32 . Similar to the capability and call protocol illustrated with reference to FIG. 8 above, the Auxiliary message 3202 is received from the first endpoint 3210 , to notify endpoint 2 3220 that an auxiliary source is available from the parent conference ID, as specified in parentConfID field 1704 of Auxiliary message 1700 of FIG. 17 . Then, a Hello message 3204 is transmitted from endpoint 1 3210 to endpoint 2 3220 . Responsive thereto, endpoint 2 3220 transmits capabilities message 3222 and Hello message 3224 .
  • all messages from source A to recipient B as illustrated in FIG. 31 reference the same conference ID 23 B for the ongoing conference between A and B.
  • the “receive media” mode flag is set to not receive (!Receive) and furthermore, the mode of the auxiliary source is not joiner (!Joiner) since it is a receive-only media source.
  • the second endpoint 3220 sends a response message 3216 indicating that the auxiliary source has been successfully joined with the conference 23 B.
  • both media messages for the conference ID 23 B, and the auxiliary source having conference ID 17 A are treated as from the same source (A) by the application.
  • the details and mechanics of a member receiving an auxiliary source message are illustrated with reference to FIGS. 33 and 34 .
  • FIG. 33 shows the process steps performed within a source of an auxiliary source.
  • the next participant in the conference to which the auxiliary source will be attached is retrieved. It is determined, at step 3304 , whether there are any more participants in the conference to which the auxiliary source will be attached. If any, then, at step 3306 , auxiliary, hello and join messages are sent to the participant. If accepted via a positive response message (as shown in FIG. 32 ), the auxiliary then becomes available to the participant for the receiver of the message. The process continues until step 3304 determines that no additional participants in the conference should join in to monitoring of the auxiliary.
  • FIG. 34 shows the steps taken by a receiver upon receipt of the initial auxiliary message.
  • capabilities if any
  • hello are sent.
  • the auxiliary source media starts to be received, and the conf ID of the parent conference is saved in the conference component of the receiver at step 3406 . This allows the application to determine that the auxiliary is associated with the parent media source by storage in the conference component for later retrieval at step 3408 . If the auxiliary is received prior to the receipt of a join message, then the association of the auxiliary with the parent conf ID allows the later association of the two from the application's standpoint.
  • FIGS. 35a and 35b An example session using the protocols described above is shown in FIGS. 35a and 35b .
  • the figures illustrate the flow of messages, from the view of a first endpoint.
  • the originating station After establishment of the connection between the stations using the transport component, the originating station sends capabilities message 3502 , and hello message 3504 , specifying the calling station's name “James Watt” with the mode mask set to 15 (all bits set—send, receive, joiner, shareable).
  • Simultaneously with the establishment of the connect corresponding capabilities, hello, and response are sent from the station entitled “Hillary Rodham” as illustrated by packets 3508 - 3512 , having the same mode.
  • the endpoint then processes the merge, placing a call sending capabilities, and hello to a member of the old conference, and a join along with the member list as shown by messages 3516 , 3518 , and 3520 .
  • the endpoint attempts to use a multicast address by transmitting broadcast request messages 3530 and 3532 .
  • the other members respond with broadcast Acks 3534 and 3536 , allowing the use of multicast.
  • the conference can then be terminated at any time by any of the members via the transmission of terminate messages to all of the members, such as 3538 and 3540 .
  • connections between endpoints can be enabled. This includes, but is not limited to, the exchange of capabilities and notification of connections between endpoints, the addition of auxiliary data streams to such connections, and the merging of existing connections.

Abstract

A method and apparatus for optimizing transmission of data to a plurality of second endpoints in a system wherein a first endpoint is providing data to the plurality of second endpoints each connected by a point-to-point communication channels. This may be useful in teleconferencing applications with a plurality of participants (endpoints) or broadcast server applications. The first endpoint activates a multicast communication channel having a first multicast address and commences broadcast of the data over the multicast communication channel. The first endpoint transmits a request message to each of the plurality of second endpoints in order to query each of the second endpoints whether they can receive transmissions broadcast to the first multicast address. Certain of the plurality of second endpoints transmit an acknowledgment message if they can receive transmissions broadcast to the first multicast address, and the first endpoint receives the acknowledgment message. Then, for each acknowledgment message received from certain of the plurality of second endpoints, the first endpoint deactivates the point-to-point communication channel and the certain of the plurality of second endpoints.

Description

This is a divisional reissue application of U.S. Reissue application Ser. No. 10/020,515, filed Dec. 7, 2001 now U.S. Pat. No. Re. 42,442, which is a reissue application of U.S. Pat. No. 5,999,977, issued Dec. 7, 1999, which is a continuation of U.S. patent application Ser. No. 08/468,715, now abandoned, filed Jun. 5, 1995, which is a continuation of U.S. patent application Ser. No. 08/396,198, filed Feb. 24, 1995, now U.S. Pat. No. 5,854,898 issued Dec. 29, 1998. Notice: More than one reissue application has been filed for the reissue of U.S. Pat. No. 5,999,977. The reissue applications are application Ser. Nos. 10/020,515, 10/857,798 (now U.S. Pat. No. RE 40,704 issued Apr. 28, 2009), Ser. Nos. 10/857,799, 10/857,805 (the present application), Ser. Nos. 10/857,806, and 12/210,847.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to teleconferencing systems.
More specifically, the present invention relates to the addition of a data stream, such as an auxiliary data stream to a teleconference.
2. Background Information
Teleconferencing is increasingly becoming a popular application in personal computer systems. Such applications typically allow the transfer of audio and video data between users so that they can speak and otherwise communicate with one another. Such applications sometimes also include data sharing wherein various types of data such as documents, spreadsheets, graphic data, or other types of data, can be shared and manipulated by all participants in the teleconference. Different teleconference applications perhaps residing on different hardware platforms have different capabilities. Moreover, a wide variety of features has been implemented in different teleconference applications, and the proliferation of different types of computer systems with different capacities, and different networking media has created challenges for teleconferencing.
For example, for most teleconferencing applications, it is assumed that the sender and the receiver have certain minimum capabilities. However, with the wide diversity of systems having different computation capacities, and in addition, the wide variety of networking media, that certain systems may not have certain capabilities. For example, the first system may be a high performance workstation coupled to a high performance communication medium whereas a second system may employ an earlier generation processor, operate at a substantially slower clock rate, and/or be coupled to a lower capacity communication medium. Certain network capabilities such as multicast or other optimization features, may not be present in certain networking media. Thus, in order for some teleconference applications to function, the participants in the conference can only operate at the fastest possible configuration provided by any minimum system which may participate in the teleconference. Of course, this results in certain inefficiencies, especially if both of the participants are capable of transmitting in a higher capacity than the system with the least possible capability.
Another issue in teleconference applications is the ability of certain stations to participate in more than one teleconference. In fact, in certain circumstances, multiple individual conferences may be desired to be merged by a user according to operating circumstances. Due to the distributed nature of certain networks, during this merge operation, certain circumstances may change. That is, that while a single station is merging more than one conference it is participating in, a second station at a remote location may further have other operating circumstances changing (e.g., participants leaving, entering, or otherwise joining an on-going teleconference), and thus, the management of such merging operations becomes unduly burdensome.
Yet another shortcoming of certain prior art teleconference applications is the ability to associate an independent data stream with an on-going teleconference. For example, a source participant may desire to provide an additional data stream to other participants in a teleconference. This additional source may include, but not be limited to, video, data, audio or any other type of data available to the source participant. For example, such an additional source may include other audio information for a receiver. Other types of data may also be desired to be associated with an on-going teleconference, which may be accessible to other participant in the teleconference. Certain prior art teleconferencing applications lack these abilities.
SUMMARY
A method and apparatus for optimizing transmission of data to a plurality of second endpoints in a system wherein a first endpoint is providing data to the plurality of second endpoints each connected by point-to-point communication channels. This may be useful in teleconferencing applications with a plurality of participants (endpoints) or broadcast server applications. The first endpoint activates a multicast communication channel having a first multicast address and commences broadcast of the data over the multicast communication channel. The first endpoint transmits a request message to each of the plurality of second endpoints in order to query each of the second endpoints whether they can receive transmissions broadcast to the first multicast address. Certain of the plurality of second endpoints transmit an acknowledgement message if they can receive transmissions broadcast to the first multicast address, and the first endpoint receives the acknowledgement message. Then, for each acknowledgement message received from certain of the plurality of second endpoints, the first endpoint deactivates the point-to-point communication channel and the certain of the plurality of second endpoints.
The broadcast of the data and the multicast communication channel is terminated if at least two of the plurality of second endpoints do not transmit the acknowledgement messages containing a positive acknowledgement. In this instance, communication channels are maintained as point-to-point. Subsequent to commencing broadcast of the data to the multicast address, the first endpoint can receive detach messages from certain of the plurality of second endpoints, and if at least two of the plurality of second endpoints are not receiving the data, then the first endpoint can terminate the broadcast of the data and the multicast communication channel. Communication of the data in this instance also reverts to point-to-point communication channels.
In implemented embodiments, the acknowledgement message includes a response code which indicates whether the second endpoint can receive transmissions broadcast to the first multicast address. Also, in implemented embodiments, prior to the first endpoint activating the multicast communication channel having the first multicast address, it is determined whether the single communication medium supports broadcasting to the first multicast address, and if not, multicast cannot be activated.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompanying in which like references indicate similar elements and in which:
FIG. 1 illustrates an example configuration in which various embodiments of the present invention may be implemented.
FIG. 2 shows a typical teleconferencing display which has both media and non-media sources displayed during the course of the teleconference.
FIG. 3 shows a single system in which embodiments of the present invention may be implemented.
FIG. 4 shows an example architecture of a system employing various embodiments of the present invention.
FIG. 5 shows a more detailed view of the conference component illustrated in FIG. 4.
FIG. 6 shows a sequence of typical conference events in a conference component which are issued to an application.
FIG. 7 shows a typical sequence of steps performed for member initialization within the conference component.
FIGS. 8-10 show typical exchanges of messages for different operations.
FIG. 11 shows a detail of a first endpoint establishing a teleconference.
FIG. 12 shows a sequence of steps performed in a second endpoint receiving the messages sent from a first endpoint during the establishment of a teleconference.
FIGS. 13-25 show details of the messages transmitted between endpoints during various teleconferencing applications.
FIGS. 26a, 26b, 26c, and 26d show the steps taken for performing merge operations.
FIGS. 27a and 27b show the conferences before and after a merge operation between teleconferences.
FIGS. 28a-b show a sequence of steps performed by the conference component during a merge operation.
FIG. 29 shows an example of a merged conferences table within a single participant.
FIGS. 30a-30b shows a sequence of steps performed for converting point to point connections to multicast connections for a teleconference.
FIGS. 31 and 32 show the adding of an auxiliary source and the messages during the adding of the source to an existing teleconference.
FIGS. 33-34 show the details of a sequence of steps performed within a participant for adding an auxiliary source.
FIGS. 35a-35b show an example sequence of messages which are sent between a first endpoint and a plurality of other endpoints in a networking system, and showing various messages transmitted therebetween.
DETAILED DESCRIPTION
The present invention relates to networking systems, more specifically, the present invention describes a messaging protocol for establishing and maintaining teleconference connections between a plurality of participants in a networking system. Applications for this include, transmitting application and/or system capabilities between participants or potential participants in a teleconference, notifying participants of a teleconference that more than one teleconference should be merged, and addition of an auxiliary data stream to an on-going teleconference. Although the present invention will be described with reference to certain specific embodiments thereof, especially, with relation to certain hardware configurations, data structures, packets, method steps, and other specific details, these should not be viewed as limiting the present invention. Various modifications and other may be made by one skilled in the art, without departing from the overall spirit and scope of the present invention.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Copyright Apple Computer, Inc.
A typical system configuration in which a teleconference may take place is illustrated as 100 in FIG. 1. For example, a first workstation 150 may communicate via teleconference with a second workstation 155, as illustrated. System 150 may include a central processing unit 150c which is coupled to a display 150d a video input device 150a, and a sound input device 150b. The system 150 may communicate with over system 155 over networking medium 170 via network connection module 160. 160 may include any number of network adapters commercially available such as using Ethernet, Token Ring, or any other networking standard commercially available. Note that network adapter 160 may also include a wireless network adapter which allows transmission of data between components without a medium 170. Communication is thus provided via network adapter 165 coupled to system 155, and bi-directional communications may be established between two systems. System 150 further has a keyboard 150e and a pointing device 150f, such as a mouse, track ball, or other device for allowing user selections and user input.
A teleconference display is shown at 200 at FIG. 2. In implemented embodiments of the present invention, there is a source window, such as 201, showing a monitor of the local media source, and there are other media windows, such as 202 or 203 for each other user with which a participant is having communication. In the illustrated example, each of the windows 201-203 provides media information, that is, real-time audio and/or video information for bi-directional teleconferencing. In alternate embodiments of the present invention, non-media information such as 204 may also be displayed within the teleconferencing display. As will become apparent in the description below, in addition to media and non-media information, messaging information may also be transmitted between stations. In addition, an auxiliary media source (e.g. audio or video information) may be transmitted with a specified conference. The details of this will be discussed in more detail below.
In implemented embodiments of the present invention, a general purpose computer system is used for implementing the teleconferencing applications and associated processes to be described here. Although certain of the concepts to be described here will be discussed with reference to teleconferencing, it is apparent that the methods and associated apparatus can be implemented for other applications, such as file sharing, real time data acquisition, or other types of applications which sends data from a first participant to a second participant or set of participants. A computer system such as that used for implementing embodiments of the present invention will now be described.
A computer system, such as a workstation, personal computer or other processing apparatus 150c or 155c as shown in FIG. 1 is illustrated in more detail in FIG. 3. 150c comprises a bus or other communication means 301 for communicating information, and a processing means 302 coupled with bus 301 for processing information. System 150c further comprises a random access memory (RAM) or other volatile storage device 304 (referred to as main memory), coupled to bus 301 for storing information and instructions to be executed by processor 302. Main memory 304 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 302. Included in memory 304 during run-time may be the conference component module which operates according to the communication protocols to be described below. System 150c also comprises a read only memory (ROM) and/or other static storage device 306 coupled to bus 301 for storing static information and instructions for processor 302, and a data storage device 307 such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 307 is coupled to bus 301 for storing information and instructions.
System 150c may further be coupled to a display device adapter display 321 such as a cathode ray tube (CRT) or liquid crystal display (LCD) coupled to bus 301 for displaying information to a computer user. Such a display 321 may further be coupled to bus 301 for the receipt of video or image information. An alphanumeric input device 322, including alphanumeric and other keys may also be coupled to bus 301 for communicating information and command selections to processor 302. An additional user input device is cursor control 323, such as a mouse, a trackball, stylus, or cursor direction keys, coupled to bus 301 for communicating direction information and command selections to processor 302, and for controlling cursor movement on display 321. For teleconferencing applications, system 150c may also have coupled to it a sound output device 324, a video input device 325, and sound input device 326, along with the associated D/A (Digital-to-Analog) and A/D (Analog-to-Digital) converters for inputting or outputting media signal bitstreams. System 150c may further be coupled to communication device 327 which is coupled to network adapter 160 for communicating with other teleconferencing stations.
Note, also, that any or all of the components of system 150c and associated hardware may be used in various embodiments, however, it can be appreciated that any configuration of the system may be used for various purposes according to the particular implementation.
In one embodiment, system 150c is one of the Apple Computer® brand family of personal computers such as the Macintosh 8100 brand personal computer manufactured by Apple Computer, Inc. of Cupertino, Calif. Processor 302 may be one of the PowerPC brand microprocessors manufactured by Motorola, Inc. of Schaumburg, Ill.
Note that the following discussion of various embodiments discussed herein will refer specifically to a series of routines which are generated in a high-level programming language (e.g., the C or C++ programming language) and compiled, linked, and then run as object code in system 150c during run-time within main memory 304 by processor 302. For example the object code may be generated by the C++ Compiler available from Symantec, Inc. of Cupertino, Calif.
Although a general purpose computer system has been described, it can be appreciated by one skilled in the art, however, that the following methods and apparatus may be implemented in special purpose hardware devices, such as discrete logic devices, large scale integrated circuits (LSI's), application-specific integrated circuits (ASIC's), or other specialized hardware. The description here has equal application to apparatus having similar function.
FIG. 4 illustrates a plurality of processes and/or apparatus which may be operative within system 150c. At the highest level, for example, at the highest level in the ISO/OSI networking model, an application program 401, such as a teleconferencing application, an audio/video server, or a data server, communicates with conference component process 400 in the form of Application Program Interface (API) calls. The conference component 400 allows the application to establish communications between two or more teleconference stations. Control information, and media information can be transmitted between the first participant system and a second participant system. The conference component will be shown in more detail in FIG. 5. Conference component 400 communicates with the transport component 402 by sending MovieTalk messages for other teleconferencing stations which are encapsulated and placed into a form that the transport component 402, the network component 403, and the system network component 404 can packetize and transmit over networking medium 170. For the purposes of the remainder of this disclosure, certain of the MovieTalk API calls and MovieTalk messages which are transmitted between conference components in a teleconferencing system will be described in more detail.
The transport component 402 and the networking component 403 provide the necessary operations for communication over the particular type of network adapter 160 and networking medium 170 according to implementation. For example, networking component 402 may provide the TCP or ADSP protcols and packetizing, according to those respective standards.
A more detailed view of the conference component 400 is shown in FIG. 5. Specifically, the conference component 400 is shown in two portions 400a and 400b which show input and output portions of the conference component. Although illustrated as a separate transmitter and receiver, each conference component in the system has both capabilities, so that full bi-directional communication between conference components in respective participant teleconference systems in a network may communicate with one another. As illustrated, the input portion of the conference component 400a receives video and sound information over media input channels 510 and 520. The video channel component and sound channel component 504 present media data at regular intervals to sequence grabber 502. The real-time sound and video data (hereinafter referred to as “media data”) are provided to a source stream director 500 from sequence grabber 502 which then provides the media messages to the transport component 402. Flow Control 501 then lets the video and sound data flow through at an implementation-dependent frequency. The video channel component 503, sound channel component 504, and sequence grabber 502 all are implemented using prior art products such as those commercially available (e.g., the QuickTime video channel, sound channel components, and sequence grabbers, available from Apple Computer, Inc. of Cupertino, Calif.) Flow control 501 may be implemented using known flow control apparatus and/or method as are commercially available, such as those which regulate flow based upon bandwidth, and other constraints in the source participant system. The conference component further comprises a sink stream director 510 which comprises a portion of the component 400b of the conference component for receipt of media data from transport component 402. Corresponding flow control 511, video and sound stream players 512 and 513, and compression and sound manager 514 and 515, for output of video streams 530 and 540, also form part of the conference component for full bi-directional conferencing capabilities.
The conference component's main function is to establish and maintain a bi-directional connection between every member of a conference. Conferencing applications use a pre-established control channel to exchange control data that is pertinent to the conference. This data might include user identification information or other information that is germane to the application's operation. Conferencing applications (e.g., 401) define the format and content of these control messages by establishing their own control protocols. The conferencing component further establishes communication channels between a first endpoint and a second endpoint, using the underlying transport component 402. Thus, once a media channel has been established, the conference component uses the transport component 402's media channel which is provided for transmission of media and non-media information. For the remainder of this application, however, the focus will be on the establishment of communication between a first and second participant (referred to as endpoints) or group of participants which may participate in a teleconference.
Application Program Interface (API)
The application program 401 controls the conference component 400 by the issuance of MovieTalk application API calls. The conference component operates using an event-driven model wherein events pertinent to the application are issued to the application program. The application program can then take appropriate action either by modifying internal data structures within (creating a source or sink), and/or issuance of appropriate messages over the network to other connected participants, or potential participants. According to messages received by the conference component, a current context and API calls from the application, the conference component can take appropriate action.
A typical series of events which occur after the establishment of a teleconference by the conference component in an application is illustrated in FIG. 6 as 600. For example, upon an initial desire by an application to enter into a conference (as expressed by an API call) or a call from another participant, a conference-ready event 601 (e.g. mtConferenceReadyEvent) is generated. The application then creates a media source in the conference component (e.g., member A) which is to provide the conference information. Subsequent to that, any auxiliary media sources may also be attached to the main conference at step 610 for a second media source (e.g. by the call MTConferenceAttachAuxiliary Source). Then, any members that are new to the conference are recognized as being ready by the receipt of MemberReady (e.g. mtMemberReady) events (e.g., 602 and 603 of FIG. 6). This establishes the media sinks such as b and c illustrated in FIG. 6. Then, during the teleconference session, a variety of other events 604 may be issued and acted upon by the conference component. These may include message events, mode events, incoming call events, data transmission events, etc. Members leaving the conference result in the issuance of MemberTerminated (e.g. mtMemberTerminatedEvent) events to the application program such as 605 or 606. Thus, for every MemberReady event for any member participating in a conference, there is a corresponding MemberTerminated (e.g. mtMemberTerminatedEvent) event prior to the end of the conference. In addition, the auxiliary source and the conference itself is terminated via the Auxiliary Terminated (e.g. mtAuxiliaryTerminatedEvent) event 611 and the conference terminated event 607 as illustrated in 600 of FIG. 6. This notifies the application that the conference is terminated, and teleconference data should no longer be transmitted. Any additional clean up operations are then performed by the application, and the source may be discarded.
A typical application's initialization is shown as process 700 of FIG. 7. The application program makes a number of API calls in order to set various parameters associated with the member or potential participant. First, an application may cause the conference component to set its capability at step 702 if it is different than the default. The call to “MTConferenceSetMessageCapabilities” causes the conference component to recall in a store the specific application capabilities within the conference component for the specific conference which are later used during transmission of messages to alert recipients that the sender application has certain functional capabilities prior to the establishment of a connection between the sender and the receiver. Each capability has associated with it a type, version, and “desire” of the capability. Each desire for each capability type may be flagged as:
    • 1. optional;
    • 2. desired;
    • 3. required; or
    • 4. a negotiation message.
      These types of capabilities are included in a capabilities list which is transmitted to endpoints, as will be described below. An “optional” capability is a message which is not required to be exchanged before setting up a conference. A “desired” capability is one which is not required that it be exchanged before setting up a conference, however, it is preferred that it is. A “required” capability is one which requires that a message be exchanged before setting up a conference. This may include access control or other messages which are transferred prior to setting up a conference. An access control capability may include the transmission of a account number and password prior to the commencement of a teleconference. A “negotiation message” is a capability which indicates that the application wishes to query the receiving application. In the case of a negotiation message capability, the type field associated with the capability allows the requests of information about the applications prior to the establishment of a conference (e.g. about the type of software and hardware components the application is interested in, such as sound). Any other types of exchanges which require negotiated information between applications may be set.
Once all individual capabilities have been set by the issuance of “Set Capabilities” API calls (e.g. MTConferenceSetCapabilities) to the conference component at step 702, a member may set its operating mode at step 704. The mode will be contained within a mode mask value which is sent in the API call to the conference component, and moreover, is included in certain messages transmitted from the conference component in the sender to the conference component in the receiver. The mode mask specifies the characteristics of a conference that the member makes available. Different capabilities, modes, and other initialization operations shown in FIG. 7 may be set for any number of conference types which are made available by the member. At any rate, the default mode includes the following values:
    • 1. send media;
    • 2. receive media;
    • 3. shareable; and
    • 4. joiner.
      The “send media” mode flag indicates that the member intends to send media data in its conferences. Most members will want to send media, however, there will be instances where the member will be a receive-only member, thus the send media mode flag will not be set. The receive media mode flag indicates that the member intends to receive media in conferences. In the case of a send-only member (e.g., a server providing a real-time video and/or audio source), will have the receive media mode flag set to “off” (e.g., a numeric value ‘0’). The “shareable” mode flag indicates that the member is willing to share the conference media data with new conference members. Thus, in the instance of a send-only media server, the shareable mode flag would be set indicating that new members can receive the conference data.
The “joiner” mode flag indicates that all conference members are allowed to interact. This would allow two-way transmission between each of the conference members. However, the setting of this flag to “off” (e.g., a numeric value ‘0’) results in broadcast type conferences wherein one member sends media data to other conference members, but the individual conference members do not exchange any media data among themselves. Each of these mode flags is transmitted at the beginning of a connection (e.g., contained within the “hello” message 1400 in FIG. 14).
By default, the conference component establishes conferences that are fully two-way media data capable, shareable, and joinable. If different characteristics are desired, then the application must call “set mode” (e.g. MTConferenceSetMode) at step 704, along with the appropriate flag(s) set. Conference mode settings are stored and associated with a particular conference ID in the sender's conference component so that when messages are created for that conference ID, the appropriate mode flags are transmitted along with the initialization or other messages sent before any other communications.
In addition to the capabilities and mode settings at steps 702 and 704, a time-out value associated with calls placed from the member may be set (e.g. using the API call MTConferenceSetTimeOut). The time-out value is then included at the beginning of certain messages preceding a conference in order to enable a recipient to determine when the caller will stop listening for responses. This allows certain features to be incorporated into participant conference components such as the smart triggering of events based upon context. For example, if the recipient is receiving a call, but a user does not wish to take the call at that time, the recipient's conference knows the time-out occurs and can take certain context-dependent action (e.g., forward the call, send a message, etc.).
The application can then invoke an API call “Listen for Call” (e.g. MTConferenceListen) which implements steps 708 and 710. At step 708, using the underlying transport to which the system is connected, a high level address is registered and published. This then allows other potential participants in the system to call the member. The registration and publication of the address is implementation-dependent, depending upon the media to which the system is connected. Then, at step 710, the conference component waits for incoming calls.
The conference component in the member enters an idle state wherein incoming messages, alerts for the transport component, API and calls will be detected and acted upon. Note that the capabilities, mode, and time-out values are all optional, and the default settings may be used by the member if none of these functions is required by the application. In the call to the MTConferenceListen function, the application must specify the networks on which the member is willing to accept calls. The conference component proceeds to register the member on those networks, doing whatever is appropriate in the various network contexts, and sends an mtListenerStatusEvent to the application to specify whether the registration attempt was successful. After listeners are operational, if another application desires to establish communication with the application, then an mtIncomingCallEvent is forwarded to the application.
FIGS. 8-10 show examples of the various message exchanges between two endpoints. Messages are generated by conference component 400 depending upon operating context, and application calls. FIG. 8 shows an example of a calling sequence for setting up a conference between two endpoints. Upon the commencement of a call from a first endpoint such as 810 shown in FIG. 8, and a second endpoint such as 820 shown in FIG. 8, a “capabilities” message 802 is transmitted from the endpoint 810 to the endpoint 820 if they have been set by the caller. The exchange of “capabilities” messages 802 and 812 between endpoint 1 810 and endpoint 2 820 are exchanged after a control channel has been opened on the transmission medium between the participants in an implementation-dependent manner (e.g. by invoking MTConferenceCall). This identifies the capabilities of each of the endpoints, if the capabilities of the application are desired to be transmitted. Once capabilities have been transmitted from each endpoint, each endpoint further transmits Hello messages 804 and 814 to identify themselves. The details of the capabilities, Hello, and other messages illustrated in the figure will be discussed below. The Hello message is the first step in establishing a conference, and allows conference components in different systems to exchange basic identification and mode information. Subsequent to the exchange of Capabilities messages (if any), and the Hello messages 804 and 814, the endpoint 1 810 wishing to establish the conference sends a call message 806 to endpoint 2 820. Subsequent thereto, if endpoint 820 desires to engage in the teleconference with endpoint 1 810, it sends a response message 816 to endpoint 1 810. Then, upon the transmission of the call message 806 and the receipt of the response message 816, a teleconference is then established between endpoint 1 810 and endpoint 2 820. The details of the process steps performed within each endpoint are discussed with reference to FIGS. 11 and 12.
FIG. 9 illustrates a “Join” protocol process. This is similar to the calling process, however, a “Join” message 906 is sent to the second endpoint instead of the “call” message 806. The details of a Join are discussed with reference to FIGS. 26a-26c below.
FIG. 10 illustrates the messages exchanged for a terminate message. As illustrated, an endpoint may issue a terminate message to terminate a teleconference. No response is required for any receivers.
FIG. 11 shows the process steps performed by a first participant (e.g., endpoint 1 810) wishing to establish communication with a second participant system (e.g., endpoint 2 820). First, at step 1102, the caller via implementation-dependent means, accesses the address of the party it wishes to call, either by reference to an internal store, referencing a server or other implementation-dependent manner. Once this has been performed, the application invokes the API call MTConferenceCall in order to call the party at step 1104. Responsive thereto, either a failed event 1106 (mtFailedEvent) is received by the caller, or a ringing event 1108 (mtPhoneRingingEvent) when the call message has been transmitted to the second participant. In the event of a ringing event, the endpoint can then get the capabilities, mode and the name of the endpoint such as by examining the data contained in the Capabilities message 812 and/or the Hello message 814. Any “required” communication between the caller and receiver may also be performed. Then, the first sender can appropriately configure itself for the second endpoint. Once any necessary message exchanges and/or configurations have been performed in the caller, then the caller will either receive a MemberRefused event 1112 (e.g. mtRefusedEvent), for example, if the calling member does not provide the necessary access control subsequent to the call message, or, a MemberReady event 1116. Also, a failed event 1106 can be detected at any time, followed by a MemberTerminated event 1114. In the case of a MemberRefused event 1112, then the conference component will generate a MemberTerminated event 1114, and a conference terminated event will then be issued indicating the end of the conference. Once capabilities have been obtained, any required capabilities are checked for at step 1113 (e.g. such as any actions that must be performed before the receiver accepts the call). Subsequent thereto, a ConferenceReadyEvent1115 (e.g. MTConfReadyEvent) and a MemberReady event 1116 (e.g. mtMemberReadyEvent) can be received by the application, then the endpoint can then engage in the exchange of messages typical during a conference, thus commencing the conference at step 1118.
As shown in FIG. 12, the sequence of steps performed by the receiver is illustrated. For example, at step 1202, the receiver application will detect an incoming call event 1202. Subsequent thereto, the receiver can then determine mode, capabilities, caller's name, conference name, and/or return address of the party wishing to engage in the conference. The mode can also be checked for at step 1206. Once this has been done, then a time-out check, if any, at 1208 can be performed in the receiver. The time-out check may be performed, depending upon an application's implementation, by checking the time-out field shown at field 1504 in FIG. 15, which indicates how long the transmitter will wait prior to timing out and generating a CallFailed event (e.g. mtFailedEvent) in order to terminate the call. In this case, according to implementation, the receiver may do a variety of things, for example, issuing a busy signal to the transmitter, issuing a message to the caller or, taking some action, such as forwarding the call to another party. Thus, the embedding of the time-out field 1504, within the initial connection message “Hello,” provides for certain intelligent features in the potential participants of a teleconference. Once any mode checks, if any, have been performed at step 1206, then at step 1208 a time out check, if any, may be performed. Any user interaction may take place at step 1209. The receiver will then issue a reply at step 1210. The reply may indicate either refusal to answer the call (e.g., due to access control, or the participant already engaging in another conference), or choose to respond to the call in the affirmative indicating that the teleconference may commence. In the case of a refusal, the MemberTerminated 1220 event (mtMemberTerminatedEvent) is issued to the application. In the case of the member answering, the MemberReady event 1218 (mtMemberReadyEvent) is issued indicating that the medium channel is open and the conference can commence.
Conferencing Messages
Conference components exchange a number of messages in order to establish, maintain, and terminate conferences. Conference components also send messages that encapsulate user data, that is, the data that is exchanged by the programs that are using the conference.
After establishing a transport connection but prior to establishing a conference channel with a remote system, a conference member may send either a Capabilities message 1300 or an Auxiliary message 1700. The member then sends a Hello message 1400 to identify itself, specifically its mode of operation (send media, receive media, shareable, or joiner) followed by a Call message 1500 (to set up a conference) or a Join message 1800 (to join to an ongoing conference). The remote member sends a Response message 1600 in answer to the Call or a Join message 1800. Once a conference is established, a member can combine calls or conferences by sending a Merge message 1900. Conference members may send or receive a Terminate message 2300 to end a conference. Connections initially are point-to-point between members of a conference. If the transport medium supports multicast addresses and more than one member is participating in a conference, a broadcast to a multicast address can be used as an optimization. The conference component uses the BroadcastRequest and BroadcastAck messages 2400 and 2500 to negotiate the transition from point-to-point to multipoint connections using multicast addresses.
All messages supported in the conference messaging protocol are preceded by a 2-byte character identifying the message type. For example for a capabilities message shown in FIG. 13, field 1302 contains a ‘K’. All messages are further terminated by a NULL such as that shown in field 1308 of FIG. 13. The Capabilities message 1300 allows a potential member to tell other potential conference members what it can and cannot do in a conference. Each member sends this message before sending the “Hello” message (1400 of FIG. 14) if capabilities other than the default are supported.
Field Size Value
type
1302 2 bytes ‘K’
delimiter 1304 1 byte newline
capabilitiesList
1306 0-n bytes (alphanumeric)
terminator 1308 1 byte NULL

capabilitiesList 1306
    • The member's capabilities. This field is optional. If specified, it contains a list of the member's capablilities. An application specifies its capabilities by calling the conference component's MTConferenceSetMessageCapabilities function.
The Capabilities message 1300 shown in FIG. 13 informs other potential conference participants about a member's capabilities. These capabilities relate directly to messages the member either supports or requires, one capability for each conferencing message type that the component supports. The messages themselves are defined by the type of application the member is running. For example, video-phone applications and chat lines deliver different services, and use different messages to do so. As a result, the capabilities a member supports will change in light of the application that is participating in the conference. Entries in the capabilitiesList field may request information from the remote system. By setting an entry's “desires” field (2010 of FIG. 20) mtNegotiationMessageCapabilities (‘N’), a conference member can query for specific information (e.g. about a given component type, such as a codec, hardware/software features supported, etc.). The type field can contain the component type value.
In response to a negotiation Capabilities message, the remote member formats a user data message, for example, containing available component subtypes. Note that this list may contain duplicate entries and entries with a value of NULL. To parse this array, a member must determine the array's size. After sending a Capabilities message 1300, the member sends a Hello message 1400 to establish a conference.
A Hello message (e.g., 1400 of FIG. 14) is sent at the start of a conference by each endpoint. The Hello message identifies basic capabilities of the sender and the mode in which it will overate. It contains the following:
Field Size Value
type
1402 2 bytes ‘H’
MinimumVersion 1404 1-n bytes (numeric)
delimiter 1406 1 byte colon
maximumVersion
1408 1-n bytes (numeric)
delimiter 1410 1 byte newline
conferenceMode
1412 1-n bytes (numeric)
delimiter 1414 1 byte newline
name
1416 1-n bytes (alphanumeric)
delimiter 1418 1 byte newline
terminator
1420 1 byte NULL

minimum Version 1404
    • The oldest version of the conference protocol supported by the sending component
      maximum Version 1408
    • The newest version of the conference protocol supported by the sending component.
      conferenceMode 1412
    • The desired conference operating mode. This field contains a value that corresponds to the operating mode the sender desires for this conference. Applications specify their desired mode by a SetMode API call (e.g. MTConferenceSetMode discussed above).
      name 1416
    • The name of the prospective conference member. This name identifies the entity that wants to join the conference, and may represent either an auxiliary data source or a new user. Applications specify a user name by calling the MTConferenceListen API call. The auxiliary name is specified in a MTAttachAuxiliary API call.
The Hello message 1400 is the first step in establishing a conference. This message allows conference components on different systems to exchange basic identification and capability information. Before sending a Hello message 1400, a conference component may send either a Capabilities 1300 or an Auxiliary message 1700. The type of message sent depends upon the role the member anticipates playing in the conference. If the member is looking to join or start a conference, the conference component sends a Capabilities message. If the member is setting up an auxiliary media data source, the component sends an Auxiliary message 1700. Following this message, the conference component can enter the call setup phase by sending the Call message 1500. If the member wants to provide an auxiliary data source to an existing conference, or join an existing conference, the component sends the Join message 1800.
Call message 1500 of FIG. 15 begins the process of establishing a conference connection between two possible participants. This is akin to dialing a number from a phone directory.
Field Size Value
type
1502 2 bytes ‘C’
callTime-out 1504 1-n bytes (numeric)
delimiter 1506 1 byte tab
ConferenceName
1508 1-n bytes (alphanumeric)
delimiter 1510 1 byte newline
callingConfID
1512 1-n bytes (alphanumeric)
delimiter 1514 1 byte newline
terminator
1516 1 byte NULL

callTime-out 1504
    • The amount of time the calling component is willing to wait for an answer. This field specifies the number of ticks ( 1/60 of a second) the calling component will wait before deciding that the call has not been answered. Called components must respond within this time period. This value may be used by a potential responder for taking some automatic action if the user doesn't answer before the timeout.
      ConferenceName 1508
    • The conference name. If the caller is establishing a conference, this is the name the caller has assigned to the conference. If the caller is connecting to a conference server, the is the name of the server's conference. Applications set the conference name by calling the MTConferenceCall function.
      callingConfID 1512
    • The caller's unique conference identifier. This field uniquely identifies the caller's conference endpoint on the network. Conference components create conference identifiers on behalf of calling applications which are unique within the conference component. Call ID's are discussed with reference to 2200 of FIG. 22.
The Call message 1500 shown in FIG. 15 begins the process of establishing a conference between two participants. This message can be used in two ways. First, this message can create a conference between two participants. In this scenario, the caller assigns a name to the conference, so that other possible participants may join later. Alternatively, this message can request to join a conference that is managed by a conference server on a network. For example, the server will allow incoming calls, but the function of the server is to merge the new conference due to the call with other ongoing conferences. In other words, the server acts exclusively as a “joiner” and does not supply media data. Once the call is set up, the caller can begin exchanging user data with other conference participants.
The response message 1600 of FIG. 16 is sent in response to Call or Join messages 1500 or 1800.
Field Size Value
type
1602 2 bytes ‘R’
callResponse 1604 1-n bytes (signednumeric)
delimiter 1606 1 byte newline
destinationConfID
1608 1-n bytes (alphanumeric)
delimiter 1610 1 byte newline
terminator
1612 1 byte NULL

callResponse 1604
    • The result. This field indicates the result of the preceding Call request. This field is set to ‘0’ if the request was successful. Otherwise, it contains an appropriate result code.
      destinationConfID 1608
    • The other endpoint's unique identifier. This field identifies the other participant in the conference.
      The Response message 1600 allows the caller to determine the success of a Call or Join request. The Response message 1600 indicates how the user at the remote system reacted to the call (for example, whether the user answered the call). The callResponse field 1604 contains the request's result code. If non-zero, an error occurred and the request was not successful. Otherwise, the destinationConfID field 1608 identifies the endpoint with which the caller may now communicate.
The auxiliary message 1700 allows one member to alert the other members of a conference that it is about to provide an auxiliary media data source (a source associated with an ongoing conference). This message may be used in place of the Capabilities message 1300 if a participant is being alerted about the presence of an auxiliary media source. The member sends this message before sending the Hello and Join Messages 1400 and 1800, and then proceeds to adding an auxiliary data source to the conference.
Field Size Value
type
1702 2 bytes ‘A’
parentConfID 1704 1-n bytes (alphanumeric)
delimiter 1706 1 byte newline
terminator
1708 1 byte NULL

parentConfID 1704
    • The member's conference identifier. This field identifies the member's existing conference endpoint (the conference identifier the member supplied in the Call message when it first joined the conference). This allows other conference participants to identify the source of the auxiliary data within each participant.
The Auxiliary message 1700 informs other conference participants that a member is about to provide an auxiliary conference data source. For auxiliary data sources, this message replace the Capabilities message during early interactions. The member must send this message to each conference participant. The member then sends a Hello 1400 and a Join message 1800 to each participant. Other participants then accept the new data source by accommodating the Join request.
A Join message 1800 of FIG. 18 allows a member to join an existing conference, given that conference's identifier. This message is useful for adding auxiliary data sources to an existing conference, and for merging two existing conferences.
Field Size Value
type
1802 2 bytes ‘J’
destinationConfID 1804 1-n bytes (alphanumeric)
delimiter 1806 1 byte newline
callingConfID
1808 1-n bytes (alphanumeric)
delimiter 1810 1 byte newline
memberList
1812 0-n bytes (alphanumeric)
terminator 1814 1 byte NULL
destinationConf ID 1804
    • The remote endpoint's unique conference identifier. This field identifies the conference to join on.
      callingConfID 1808
    • Unique conference identifier. This field uniquely identifies the caller's conference endpoint on the network. Conference components create conference identifiers on behalf of calling applications. If the message is adding an auxiliary media data source, this is the auxiliary's identifier.
      memberList 1812
    • A list of other conference participants. This list identifies all other known conference participants that are willing to exchange data with new participants (that is, they have the Joiner Mode Mask [e.g. mtJoinerModeMask] set in their conference mode). The conference component can connect with each participant with whom it is not already connected. If the message is adding an auxiliary (via the issuance of an auxiliary message 1700), this list contains the endpoint identifier of each participant to which the caller is making the auxiliary available. It is up to each of them to respond.
    • This is a list of conference endpoint identifiers; each element in the list is followed by a newline character.
The Join message 1800 allows a member to add an auxiliary data source to an existing conference or to merge two existing conferences. The caller sends this message to members of the conference in response to a merge or join request instead of a call message.
The Merge message 1900 of FIG. 19 combines two conferences. Recipients of this message connect with the listed members with whom they are not already connected.
Field Size Value
type
1902 2 bytes ‘M’
conferenceName 1904 1-n bytes (alphanumeric)
delimiter 1906 1 byte newline
myConfID
1908 1-n bytes (alphanumeric)
delimiter 1910 1 byte newline
memberList
1912 0-n bytes (alphanumeric)
terminator 1914 1 byte NULL

conferenceName 1904
    • The new conference name resulting from the merge. This is the name that was assigned to the conference when the conference was established. Applications specify the conference name by calling the MTConferenceCall API function.
      myConfID 1908
    • Unique conference identifier. This field uniquely identifies the caller's conference endpoint in the target conference. Conference components create conference identifiers on behalf of calling applications.
      memberList 1912
    • A list of other conference participants. This list identifies other current conference participants. This list contains the endpoint identifier of each new participant. This is a list of conference endpoint identifiers; each element in the list is followed by a newline character.
The Merge message causes the combination of two conferences. This is the mechanism for creating conferences with more than two participants. The caller sends this message to each existing conference member, specifying the conference's name. Each endpoint establishes communications with any new endpoints. By convention, the endpoint with the higher conference identifier value establishes the connection (to avoid duplicate or missed connections). Members of the conference receive a Join message 1900 instead of a Call message 1500 when contacted by each new member.
Field Specifics
A capabilities list such as shown in FIG. 20 (e.g., field 1306) contains information about the message supported by a conferencing application. The list consists of zero or more lines of information; each line specifies a single capability and consists of the following fields.:
Field Size Value
type
2002 4 bytes (alphanumeric)
delimiter 2004 1 byte tab
version
2006 1-n bytes (numeric)
delimiter 2008 1 byte tab
desires 2010 1 byte (alphanumeric)
delimiter 2012 1 byte newline

type 2002
Identifies a message by reference to a unique type value.
version 2006
    • Message version number. Specifies the most-recent version of the message that the application supports.
      desires 2010
    • Support level. This field indicates the level of support required by the application. Possible values are:
      • mtMessageOptionalCapability
        • Optional. Indicates that the message is optional. The value corresponding to this option is ‘O’.
      • mtMessageDesiredCapability
        • Desired. While still optional, this value indicates that the application prefers to receive this message early in the call (e.g. prior to establishing a call, one member may request that the recipient send his business card for long-term storage). The value corresponding to this option is ‘D’.
      • mtMessageRequiredCapability
        • Required. The application must receive this message. The value corresponding to this option is ‘R’.
      • mtNegotiationMessageCapability
        • Negotiate. The application wants to learn about the recipient's facilities. The value corresponding to this option is ‘N’.
Conference identifiers such as 2200 shown in FIG. 22 uniquely identify a conference endpoint. Each endpoint represent a data source or sink for the conference. Note that a single system may have more than one conference endpoint (e.g., an auxiliary) in a given conference, and may have more than one conference at a time. A conference endpoint consists of the following fields:
Field Size Value
UniqueID
2202 1-n bytes (numeric)
separator 2204 1 byte space
name
2206 1-n bytes (alphanumeric)

UniqueID 2202
    • Unique numeric identifier. This field contains a unique numeric endpoint identifier. Each conference component assigns its own identifiers in order to guarantee uniqueness within the context of a given name specified in the name field 2206.
      name 2206
    • A unique name. Identifies the system on the network. The name is unique within the context of a given transport interface. It includes the type of the selected transport and network interface.
A member list such as 1812 of FIG. 21 is an array of zero or more conference identifiers 2102, 2110, etc. Each entry in the array is delimited by a newline character.
The Terminate message 2300 of FIG. 23 ends a conference, closing a member's communications with the participants to which it sends the message.
Field Size Value
type
2302 2 bytes ‘T’
delimiter 2304 1 byte newline
terminator
2306 1 byte NULL

The Terminate message 2300 is the last step in ending a member's participation in a conference. This message ends the member's conference communication with all participants to which it sends the message. If a member is leaving a conference altogether, it must send this message to each conference participant.
The BroadcastRequest message 2400 allows a member to find out if another conference member can accept broadcast (multicast) messages.
Field Size Value
type
2402 2 bytes ‘B’
subtype 2406 1 byte ‘R’
delimiter 2408 1 byte tab
multicastAddress
2410 1-n bytes (alphanumeric)
delimiter 2412 1 byte newline
terminator
2414 1 byte NULL

subtype 2406
    • The broadcast message subtype. This field must be set to ‘R’.
      multicastAddress 2410
    • The proposed multicast address. This field contains the multicast address on which the member proposes to send broadcast messages.
The BroadcastRequest message 2400 allows a member to determine whether another conference member can accept broadcast messages over a given multicast network address. The recipient indicates its ability to support the broadcast messages by sending a BroadcastAck message 2500 (described below). If the recipient cannot support broadcast messaging or cannot access this particular broadcast transmission, the calling member should continue to send point-to-point messages to the recipient.
The BroadcastRequest message 2400 is typically uses as part of the negotiation process that follows merging two conferences or the joining of any new members to a conference. As an optimization, conference participants may choose to set up broadcast capabilities as a more-efficient alternative to maintaining several different point-to-point connections.
The BroadcastAck message 2500 allows a member to respond to a BroadcastRequest message 2400.
Field Size Value
type
2502 2 bytes ‘B’
subtype 2504 1 byte ‘A’
delimiter 2506 1 byte tab
broadcastResponse 2508 1-n bytes (signed numeric)
delimiter 2510 1 byte newline
terminator 2512 1 byte NULL

subtype 2504
    • The broadcast message subtype. This field must be set to ‘A’.
      broadcastResponse 2508
    • The result. This field indicates whether the member can support the multicast address proposed in the BroadcastRequest message 2500.
The BroadcastAck message 2500 allows a member to indicate whether it can receive messages over a proposed multicast address. Another conference participant proposes a multicast address by sending a BroadcastRequest message 2408. If the recipient can support that address, it sets the broadcastResponse field 2508 to ‘0’. Otherwise, the broadcastResponse field 2580 contains an appropriate non-zero result code. This message is typically used as part of the negotiation process that follows merging two conferences. As an optimization, conference participants may choose to set up broadcast capabilities as a more-efficient alternative to maintaining several different point-to-point connections.
Join operations have the protocol illustrated in FIG. 9. FIGS. 26a-26c illustrate the process steps performed in a transmitter and receiver during join operations. FIG. 26a shows a process 2600 which includes the process steps performed by a transmitter of a join message or any message containing a member list. This may occur, for example, responsive to an auxiliary or merge message. First, the transmitter creates a join message at step 2602. The destination conference ID and calling conference ID's are added to the message at step 2603. Then, at step 2604, a member is appended to the members list in the join message. This is shown in more detail in FIG. 26b. A transport level connection with the member to receive the join is then performed at step 2605. Subsequent thereto, the message is then sent to any recipients at step 2606.
FIG. 26b illustrates the “append members” function 2604 shown in FIG. 26a for appending members to a member list. The function starts at step 2610 which determines whether the member is a “joiner.” If so, then additional members can be appended to the join. If not, then the function ends and the join message with the single member is transmitted as shown on FIG. 26a. At 2612, the next member is retrieved according to the conference ID. At step 2614 it is determined whether there are any more members in the specified conference ID. If not, the process is complete. If there are more members and the shareable mode flag is set, as detected at step 2616, then the member is added to the member list at step 2618. In this manner, during a merge operation, other participants receiving join messages can determine if conference membership has changed, requiring additional join messages to be transmitted by receiving members.
FIG. 26c shows the steps performed by a receiver of a join message. First, at step 2652, the destination conference ID contained in the join message is looked up by the receiver in a locally-stored current conferences history table (e.g. 2900 of FIG. 29). This keeps track of previously used conference ID's for any currently active conferences. If the conference ID has changed, the member can then complete the join by referencing an old conference ID and the current conference ID in the member. This allows for conference merge and auxiliary messages from widely distributed members in a network. If the conference ID can't be found, as detected at step 2654, then the connection is refused at step 2656, by the issuance of an appropriate response message, and the join fails. If the conference ID has been found, then, at step 2660, the connection is added to the list of participants for the conference. At step 2662, a Response message that the join can be performed is sent to the sender of the join. Then, the membership of the members contained in the member list of the join can then be performed as shown in FIG. 26d.
The merge membership function 2664 is shown in more detail in FIG. 26d. First, it is determined at step 2678 whether the member merging membership is shareable. If so, then at step 2680, it is determined whether there are any more members in the member list. If not, the function is complete. If so, the next member from the membership list is retrieved at step 2682. If the participant is already connected, is the member or is the member's own auxiliary source, as detected at step 2684 then the process returns to step 2680. It is determined, at step 2686, whether this party is going to initiate the join with this member in the member list. This prevents conflicting join messages from being received and acted upon in the network. This is accomplished by determining whether the recipient's conference ID is greater than the calling party's conference ID. In this case, this party will take action on the join (e.g. place the call to the other party to accomplish the join). Operations necessary to accomplish the join then take place starting at step 2688. At this step, transport level connections are established. Once established, capabilities, if any, (or an auxiliary message, in the case of an auxiliary source), hello, and join messages are sent at step 2690. The member then waits for a response to the join, and if received in the affirmative, the conference component issues MemberReady to the application. This process continues until all members in the member list have been processed.
Merge Operations
Merge operations are initiated using a “Merge” message (e.g., 1900 of FIG. 19) which indicates to a participant that two existing conferences should be merged. This is according to the conference ID contained within the field 1908 of Message 1900. Each Merge message contains within it a memberList 1912 which allows the participating members to transmit Join messages to all the members which have been listed in the memberList. This further allows changing membership and conference ID during the course of a merge operation to be tracked so that correct conference ID's and conference membership may be maintained until after the merge. A merge operation is graphically illustrated with reference to FIGS. 26a and 26b. For example, at a first time period as illustrated in FIG. 26a, conference member ID may be engaging in two conferences denoted 1 and 2 with several other members, A, B, and C. The member then proceeds to issue Merge messages to the members of conferences. That is, member D issues join messages to members A, B and C to Merge the conference 2 (denoted B1 and C1). At the end of the operation, members A, B, C, and D all have point-to-point communication channels and the new conference ID is the same, (A1, B1, C2, D1, respectively in each of the members). The mechanics of this operation are described briefly with reference to FIGS. 28a-28b. That is, the two separate conferences are now denoted by the same conference ID's in each of the members.
FIGS. 28a-28b show the steps taken during a merge operation by the conference component in the transmitter and receivers (if any) of a merge message. FIG. 28a shows the process steps taken by a transmitter of a merge request. The member first combines the conference ID's of the old and new conference in it's internal store at step 2802. Then, at step 2804, the member creates the merge message and appends each of the members of the conference to the members list in the message via the append members routine 2604 (discussed above) in order to ensure full connectivity among all conference members. Then, at step 2806, the merge message is sent to all participants in the merge.
FIG. 28b shows process steps taken in a receiver receiving a merge message. Once a merge message has been detected (step 2812), the merge recipient recalls in a local store for example, the conference name and the conference ID at step 2814. Then, as discussed with reference to FIG. 26d, above, a merger of membership is performed (e.g. process 2664), and the process is thus complete at step 2816.
In addition to using conference ID's for performing merge and subsequent join operations, contained within each Merge and Join message is a list of members of the conferences being merged or joined. These are included in the memberList fields 1812 or 1912 of messages 1800 or 1900. For example, due to propagation delays in a networking system, old conference ID's may still exist in peripheral participants, and therefore during merging and or joining operations, conference ID's may become invalid due to members merging conferences, etc. . . . , or reference conference ID's which no longer exist. Thus, contained within each conference component in a member is a current conferences table such as 2900 shown in FIG. 29. The current conferences history table allows a member performing a merge or join operation to determine whether in fact conferences to be merged use old conference ID's. If so, then the new conference ID may be used to transmit to the participants receiving the join messages, and/or be matched to the appropriate conference ID. Thus, the member performing the merge operation can reference by way of the current conference ID 2901 contained within the merged conferences table, or other conference ID values 2902, containing a variable length list of conference ID's, to which the current conference ID refers. Conference entries are deleted at the end of a conference by the conference component. If a merge occurs at a peripheral location and a conference ID becomes invalid, then the list of conference ID's for an existing conference ID can be referenced by referencing the merged conferences history table.
Multicast
FIGS. 30a and 30b illustrate a process which is performed as an optimization if multiple participants within a conference support multicast address broadcast capabilities. First, it is detected at step 3001 whether there are any more transport media to be examined. If so, then the next is retrieved at step 3002, and at step 3003 it is determined whether two or more participants are in the same conference and are on the same transport medium. If so, and the transport medium supports multicast at step 3004, then the multicast capabilities of the transport medium are activated at step 3006. If so, and the multicast capabilities are working at step 3008, then step 3008 proceeds to step 3012. If it is not working, as detected at step 3008, then the process is aborted at step 3010. At step 3012 a multicast address which may be used for the transport medium is retrieved at step 3012. Then, at 3014, Broadcast Requests are sent in substantially the format as shown in Message 2400 of FIG. 24, to all the participants detected at step 3002 supporting multicast. The process then awaits BroadcastAck (in the format 2500 shown in FIG. 25) in order to determine whether the multicast address is available for each at step 3016. If so, then for each BroadcastAck determined to be received at step 3018, and it is determined whether the BroadcastAck was positive (due to the response value contained in field 2508 of FIG. 25). At step 3022, if the response was positive, then the point-to-point connection is deactivated. Once all the Broadcast Acks have been received (or have timed-out), then it is determined at step 3024 whether there was a Broadcast Ack received for each Broadcast Request message sent. If not, then the process is complete. If so, however, step 3026 determines whether there were any positive BroadcastAck for the multicast. If not, then multicast is deactivated, and point-to-point communication continues to be used for communication with the other members (this optimization cannot be performed). The process is thus complete.
Auxiliary Operations
An auxiliary media source can become part of an ongoing conference. The media source is associated with an ongoing conference by a invoking reference to the main conference stored in each conference component (e.g. by the API call MTConferenceAttachAuxiliarySource), however, it is treated as a separate conference in each conference component. For example, as illustrated with reference to FIG. 31, a first conference referred to by conference ID 23B in member B, may be notified of an auxiliary source having conference ID 17A from member A. Note that similar to the protocol illustrated with reference to the Capabilities and Hello messages in FIGS. 8 and 9 above, the Auxiliary message may be sent in place of a Capabilities message between a first endpoint and a second endpoint as illustrated in FIG. 32. The timing of the messages is illustrated with reference to FIG. 32. Similar to the capability and call protocol illustrated with reference to FIG. 8 above, the Auxiliary message 3202 is received from the first endpoint 3210, to notify endpoint 2 3220 that an auxiliary source is available from the parent conference ID, as specified in parentConfID field 1704 of Auxiliary message 1700 of FIG. 17. Then, a Hello message 3204 is transmitted from endpoint 1 3210 to endpoint 2 3220. Responsive thereto, endpoint 2 3220 transmits capabilities message 3222 and Hello message 3224. Subsequent thereto, a Join message 3226 with the conference ID=23B is issued from the endpoint to 3220 with the conference ID of the source in order to indicate that the endpoint 3220 wishes to receive the auxiliary source AA, shown in FIG. 31. Subsequent thereto, all messages from source A to recipient B as illustrated in FIG. 31 reference the same conference ID 23B for the ongoing conference between A and B. As illustrated in FIG. 31, the “receive media” mode flag is set to not receive (!Receive) and furthermore, the mode of the auxiliary source is not joiner (!Joiner) since it is a receive-only media source. Subsequent thereto, the second endpoint 3220 sends a response message 3216 indicating that the auxiliary source has been successfully joined with the conference 23B. Subsequent thereto, both media messages for the conference ID 23B, and the auxiliary source having conference ID 17A are treated as from the same source (A) by the application. The details and mechanics of a member receiving an auxiliary source message are illustrated with reference to FIGS. 33 and 34.
FIG. 33 shows the process steps performed within a source of an auxiliary source. At step 3302, the next participant in the conference to which the auxiliary source will be attached is retrieved. It is determined, at step 3304, whether there are any more participants in the conference to which the auxiliary source will be attached. If any, then, at step 3306, auxiliary, hello and join messages are sent to the participant. If accepted via a positive response message (as shown in FIG. 32), the auxiliary then becomes available to the participant for the receiver of the message. The process continues until step 3304 determines that no additional participants in the conference should join in to monitoring of the auxiliary.
FIG. 34 shows the steps taken by a receiver upon receipt of the initial auxiliary message. At step 3402, capabilities (if any), and hello are sent. At step 3404, the auxiliary source media starts to be received, and the conf ID of the parent conference is saved in the conference component of the receiver at step 3406. This allows the application to determine that the auxiliary is associated with the parent media source by storage in the conference component for later retrieval at step 3408. If the auxiliary is received prior to the receipt of a join message, then the association of the auxiliary with the parent conf ID allows the later association of the two from the application's standpoint.
An Example Session (FIGS. 35a and 35b)
An example session using the protocols described above is shown in FIGS. 35a and 35b. The figures illustrate the flow of messages, from the view of a first endpoint. After establishment of the connection between the stations using the transport component, the originating station sends capabilities message 3502, and hello message 3504, specifying the calling station's name “James Watt” with the mode mask set to 15 (all bits set—send, receive, joiner, shareable). Then, a call message 3506 is transmitted to the receiver along with the timeout value=19392 confname=“some conference,” and the confID=“672 mtlkatlkJamesWatt: VideoPhone: VideoZone”. Simultaneously with the establishment of the connect, corresponding capabilities, hello, and response are sent from the station entitled “Hillary Rodham” as illustrated by packets 3508-3512, having the same mode.
Subsequent to the exchange of capabilities, hello, and call and response, a merge message 3514 is received by the first endpoint including the conference name “Some Conference”, a conf ID=137 “mtlkatlk Hillary Rodham: Video Phone: Video Zone” and a member list. The endpoint then processes the merge, placing a call sending capabilities, and hello to a member of the old conference, and a join along with the member list as shown by messages 3516, 3518, and 3520. Once the connection has been established, capabilities and hello messages 3524 and 3526 are received from the recipient. Responsive to the join the recipient sends a response message 3528 with the result=0 (request successful). Subsequent thereto, the endpoint then attempts to use a multicast address by transmitting broadcast request messages 3530 and 3532. The other members respond with broadcast Acks 3534 and 3536, allowing the use of multicast. The conference can then be terminated at any time by any of the members via the transmission of terminate messages to all of the members, such as 3538 and 3540.
Thus, by use of the foregoing, connections between endpoints, such as for teleconferences between teleconferencing systems, can be enabled. This includes, but is not limited to, the exchange of capabilities and notification of connections between endpoints, the addition of auxiliary data streams to such connections, and the merging of existing connections. It will be appreciated that though the foregoing has been described especially with reference to FIGS. 1-35b, that many modifications made be made, by one skilled in the art, without departing from the scope of the invention as described here. The invention is thus to be viewed as limited only by the appended claims which follow.

Claims (61)

What is claimed is:
1. In a system wherein a first endpoint is providing data to a plurality of second endpoints each connected by a point-to-point communication channel with said first endpoint, an automatic method for optimizing the transmission of said data to said plurality of second endpoints comprising the following steps:
a. said first endpoint activating a multicast communication channel having a first multicast address and commencing broadcast of said data over said multicast communication channel;
b. Said first endpoint transmitting a request message to each of said plurality of second endpoints in order to query each of said second endpoints whether they can receive transmissions broadcast to said first multicast address;
c. certain of said plurality of second endpoints transmitting an acknowledgment message and said first endpoint receiving said acknowledgment message;
d. for each said acknowledgment message received from said certain of said plurality of second endpoints which indicates that said certain of said plurality of second endpoints can receive transmissions broadcast to said first multicast address, deactivating said point-to-point communication channel with said first endpoint and said certain of said plurality of second endpoints; and
e. terminating said broadcast of said data and said multicast communication channel if at least two of said plurality of second endpoints do not transmit said acknowledgment messages containing a positive acknowledgment.
2. The method of claim 1 further comprising the step of receiving detach messages from certain of said plurality of second endpoints, and if at least two of said plurality of second endpoints are not receiving said data, then terminating said broadcast of said data and said multicast communication channel.
3. The method of claim 1 wherein said each acknowledgment message includes a response code.
4. The method of claim 3 wherein said response code indicates whether each said certain of said plurality of second endpoints can receive transmissions broadcast to said first multicast address.
5. The method of claim 1 wherein said data includes teleconference data.
6. The method of claim 1 further comprising, prior to said step of said first endpoint activating said multicast communication channel having a first multicast address, determining whether more than one of said plurality of second endpoints is coupled to said first endpoint on a single communication medium, and if not, aborting said method.
7. The method of claim 6 further comprising, prior to said first endpoint activating said multicast communication channel having said first multicast address, determining whether said single communication medium supports broadcasting to said first multicast address.
8. The method of claim 1 wherein said data includes teleconference data between said first endpoint and said plurality of second endpoints.
9. An apparatus in a first endpoint for transmitting data to a plurality of second endpoints receiving said data from said first endpoint on point-to-point communication channels comprising:
a. a circuit for activating a multicast communication channel having a first multicast address and commencing broadcast of said data over said multicast communication channel;
b. a circuit for transmitting a request message to each of said plurality of second endpoints in order to query each of said second endpoints whether they can receive transmissions broadcast to said first multicast address;
c. a circuit for receiving acknowledgment messages, if any, from certain of said plurality of second endpoints;
d. a circuit for deactivating each said point-to-point communication channel with said certain of said plurality of second endpoints responsive to receiving each said acknowledgment message; and
e. a circuit for terminating said broadcast of said data and said multicast communication channel if at least two of said acknowledgment messages containing a positive acknowledgment are not received.
10. The apparatus of claim 9 further comprising a circuit for receiving detach messages from others of said plurality of second endpoints, and if at least two of said plurality of second endpoints are not receiving said data, then terminating said broadcast of said data and said multicast communication channel.
11. The apparatus of claim 9 wherein said each acknowledgment message includes a response code.
12. The apparatus of claim 11 wherein said response code indicates whether each of said certain of said plurality of second endpoints can receive transmissions broadcast to said first multicast address.
13. The apparatus of claim 9 wherein said data includes teleconference data.
14. The apparatus of claim 9 further comprising a detection circuit operative prior to said first endpoint activating said multicast communication channel having said first multicast address for determining whether more than one of said plurality of second endpoints is coupled to said first endpoint on a single communication medium, and if not, not activating said circuits b and c.
15. The apparatus of claim 14 further comprising, prior to activation of said detection circuit a circuit for determining whether said single communication medium supports broadcasting to said first multicast address.
16. In a system wherein data is provided to a plurality of endpoints connected by a point-to-point communication channel, an automatic method for optimizing data transmission comprising:
querying at least a subset of the endpoints in order to determine whether they can receive transmissions broadcast to a first multicast address;
receiving, from at least one of said endpoints, an acknowledgment message;
for at least one received acknowledgment message indicating that an endpoint can receive transmissions broadcast to said first multicast address and where a multicast communication channel having the first multicast address has been activated, deactivating said point-to-point communication channel with the endpoint from which said message is received; and
terminating the multicast communication channel having the first multicast address if at least two of said endpoints do not transmit an acknowledgment message containing a positive acknowledgement.
17. The method of claim 16, further comprising:
responsive to receiving at least one acknowledgment message indicating that an endpoint can receive transmissions broadcast to said first multicast address, commencing multicasting.
18. The method of claim 16, further comprising:
responsive to failing to receive an acknowledgment message from each of the queried endpoints, terminating multicasting.
19. The method of claim 16, further comprising:
prior to querying, activating the multicast communication channel having the first multicast address and commencing broadcast of data over said multicast communication channel; and
terminating said broadcast of said data if at least two of said endpoints do not transmit an acknowledgment message containing a positive acknowledgement.
20. The method of claim 16, further comprising receiving detach messages from certain of said plurality of endpoints, and if at least one of said plurality of second endpoints are not receiving said data, then terminating multicasting.
21. The method of claim 16, wherein each acknowledgment message includes a response code.
22. The method of claim 21, wherein said response code indicates whether certain of said plurality of endpoints can receive transmissions broadcast to said first multicast address.
23. The method of claim 16, wherein said data includes teleconference data.
24. The method of claim 16, further comprising, prior to querying:
responsive to less than two of said plurality of endpoints being coupled on a single communication medium; aborting the method.
25. The method of claim 24, further comprising, prior to querying:
determining whether said single communication medium supports broadcasting to said first multicast address.
26. The method of claim 16, wherein said data includes teleconference data to said plurality of second endpoints.
27. In a system wherein data is provided to a plurality of endpoints connected by a point-to-point communication channel, an apparatus for optimizing data transmission comprising:
a circuit for querying at least a subset of the endpoints in order to determine whether they can receive transmissions broadcast to a first multicast address;
a circuit for receiving, from at least one of said endpoints, an acknowledgment message;
a circuit for, for at least one received acknowledgment message indicating that an endpoint can receive transmissions broadcast to said first multicast address and where a multicast communication channel having the first multicast address has been activated, deactivating said point-to-point communication channel with the endpoint from which the message is received; and
a circuit for terminating the multicast communication channel having the first multicast address if at least two of said endpoints do not transmit an acknowledgment message containing a positive acknowledgement.
28. The apparatus of claim 27, further comprising:
a circuit for, responsive to receiving at least one acknowledgment message indicating that an endpoint can receive transmissions broadcast to said first multicast address, commencing multicasting.
29. The apparatus of claim 27, further comprising:
a circuit for, responsive to failing to receive an acknowledgment message from each of the queried endpoints, terminating multicasting.
30. The apparatus of claim 27, further comprising a circuit for:
prior to querying, activating the multicast communication channel having the first multicast address and commencing broadcast of data over said multicast communication channel; and
terminating said broadcast of said data if at least two of said endpoints do not transmit an acknowledgment message containing a positive acknowledgement.
31. The apparatus of claim 27 further comprising a circuit for receiving detach messages from certain of said plurality of endpoints, and if at least one of said plurality of second endpoints are not receiving said data, then terminating multicasting.
32. The apparatus of claim 27 wherein each acknowledgment message includes a response code.
33. The apparatus of claim 32 wherein said response code indicates whether certain of said plurality of endpoints can receive transmissions broadcast to said first multicast address.
34. The apparatus of claim 27 wherein said data includes teleconference data.
35. The apparatus of claim 27 further comprising a circuit for, prior to querying:
responsive to less than two of said plurality of endpoints being coupled on a single communication medium; aborting the apparatus.
36. The apparatus of claim 35 further comprising a circuit for, prior to querying:
determining whether said single communication medium supports broadcasting to said first multicast address.
37. The apparatus of claim 27 wherein said data includes teleconference data to said plurality of second endpoints.
38. A method of adding at least two new members to a conference, the conference being associated with a list of participating members, the method comprising:
receiving a join message, wherein the join message includes a destination conference identifier and a calling conference identifier;
obtaining a list of at least two new members to be added to the conference;
merging the list of at least two new members with the list of participating members; and
establishing a media connection with the at least two new members.
39. The method of claim 38 wherein the conference comprises a teleconference.
40. The method of claim 38 wherein the conference comprises a video conference.
41. The method of claim 38, wherein the join message includes the list of at least two new members.
42. The method of claim 38, wherein the list of at least two new members comprises a subset of members of a second conference, wherein the subset comprises only members of the second conference that agree to share the conference media data with new conference members.
43. An apparatus for adding at least two new members to a conference, the conference being associated with a list of participating members, the method comprising:
a circuit for receiving a join message, wherein the join message includes a destination conference identifier and a calling conference identifier;
a circuit for obtaining a list of at least two new members to be added to the conference;
a circuit for merging the list of at least two new members with the list of participating members; and
a circuit for establishing a media connection with the at least two new members.
44. The apparatus of claim 43 wherein the conference comprises a teleconference.
45. The apparatus of claim 43 wherein the conference comprises a video conference.
46. A method of adding at least two new members to a conference, the conference being associated with a list of participating members, the method comprising:
transmitting a first message requesting to join the conference, wherein the first message includes a destination conference identifier and a calling conference identifier;
receiving an acknowledgement message;
receiving the list of participating members; and
transmitting a second message to establish media connections with the participating members.
47. The method of claim 46 wherein the conference comprises a teleconference.
48. The method of claim 46 wherein the conference comprises a video conference.
49. The method of claim 46, further comprising:
responsive to receiving at least one third message indicating that one or more participating members can receive multicast transmissions, causing a multicast transmission.
50. The method of claim 46, wherein the acknowledgment message includes a response code.
51. The method of claim 46, further comprising:
responsive to less than a requisite number of participating members receiving a multicast transmission, causing the multicast transmission to be terminated.
52. The method of claim 46, further comprising:
determining whether a single communication medium supports multicast transmissions to the participating members.
53. The method of claim 46, wherein the first message includes a list of at least two new members to be added to the conference.
54. The method of claim 53, wherein the list of at least two new members comprises a subset of members of a second conference, wherein the subset comprises only members of the second conference that agree to share the conference media data with new conference members.
55. An apparatus for adding at least two new members to a conference, the conference being associated with a list of participating members, the apparatus comprising:
a first circuit for transmitting a first message requesting to join the conference, wherein the first message includes a destination conference identifier and a calling conference identifier:
a second circuit for receiving an acknowledgement message;
a third circuit for receiving the list of participating members; and
a fourth circuit for transmitting a second message to establish media connections with the participating members.
56. The apparatus of claim 55 wherein the conference comprises a teleconference.
57. The apparatus of claim 55 wherein the conference comprises a video conference.
58. The apparatus of claim 55, wherein the second circuit is further configured to determine whether one or more participating members can receive multicast transmissions.
59. The apparatus of claim 55, wherein the acknowledgment message includes a response code.
60. The apparatus of claim 55, further comprising: a fifth circuit for transmitting a third message to terminate the media connections with the participating members, responsive to the list of participating members being less than a requisite number.
61. The apparatus of claim 55, further comprising: a fifth circuit for determining whether a single communication medium coupled to the participating members supports multicast transmissions.
US10/857,805 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint Expired - Lifetime USRE44395E1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/857,805 USRE44395E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US08/396,198 US5854898A (en) 1995-02-24 1995-02-24 System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US46871595A 1995-06-05 1995-06-05
US08/987,332 US5999977A (en) 1995-02-24 1997-12-09 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpont
US10/020,515 USRE42442E1 (en) 1995-02-24 2001-12-07 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US10/857,805 USRE44395E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/987,332 Reissue US5999977A (en) 1995-02-24 1997-12-09 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpont

Publications (1)

Publication Number Publication Date
USRE44395E1 true USRE44395E1 (en) 2013-07-23

Family

ID=23566262

Family Applications (7)

Application Number Title Priority Date Filing Date
US08/396,198 Expired - Lifetime US5854898A (en) 1995-02-24 1995-02-24 System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US08/987,332 Ceased US5999977A (en) 1995-02-24 1997-12-09 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpont
US10/020,515 Expired - Lifetime USRE42442E1 (en) 1995-02-24 2001-12-07 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US10/857,806 Expired - Lifetime USRE44441E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpoint
US10/857,805 Expired - Lifetime USRE44395E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US10/857,798 Expired - Lifetime USRE40704E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US12/210,847 Expired - Lifetime USRE44306E1 (en) 1995-02-24 2008-09-15 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint

Family Applications Before (4)

Application Number Title Priority Date Filing Date
US08/396,198 Expired - Lifetime US5854898A (en) 1995-02-24 1995-02-24 System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US08/987,332 Ceased US5999977A (en) 1995-02-24 1997-12-09 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpont
US10/020,515 Expired - Lifetime USRE42442E1 (en) 1995-02-24 2001-12-07 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US10/857,806 Expired - Lifetime USRE44441E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpoint

Family Applications After (2)

Application Number Title Priority Date Filing Date
US10/857,798 Expired - Lifetime USRE40704E1 (en) 1995-02-24 2004-05-28 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US12/210,847 Expired - Lifetime USRE44306E1 (en) 1995-02-24 2008-09-15 System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint

Country Status (1)

Country Link
US (7) US5854898A (en)

Families Citing this family (118)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5854898A (en) 1995-02-24 1998-12-29 Apple Computer, Inc. System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US6785709B1 (en) * 1995-04-28 2004-08-31 Intel Corporation Method and apparatus for building customized data and/or video conferencing applications utilizing prepackaged conference control objects
US6502126B1 (en) * 1995-04-28 2002-12-31 Intel Corporation Method and apparatus for running customized data and/or video conferencing applications employing prepackaged conference control objects utilizing a runtime synchronizer
US6751669B1 (en) * 1997-03-24 2004-06-15 Avaya Technology Corp. Multimedia multiparty communication system and method
US6189039B1 (en) * 1997-04-10 2001-02-13 International Business Machines Corporation Selective tunneling of streaming data
FR2762951B1 (en) * 1997-05-02 1999-07-23 Alsthom Cge Alcatel METHOD FOR TRANSMITTING A NOTIFICATION IN A NETWORK COMPRISING A NOTIFICATION SERVICE AND A NETWORK FOR IMPLEMENTING IT
US6006253A (en) * 1997-10-31 1999-12-21 Intel Corporation Method and apparatus to provide a backchannel for receiver terminals in a loosely-coupled conference
US6125115A (en) * 1998-02-12 2000-09-26 Qsound Labs, Inc. Teleconferencing method and apparatus with three-dimensional sound positioning
US6438111B1 (en) * 1998-05-22 2002-08-20 Avaya Technology Corp. Dynamically scaleable conference system
US6850985B1 (en) * 1999-03-02 2005-02-01 Microsoft Corporation Security and support for flexible conferencing topologies spanning proxies, firewalls and gateways
US6584493B1 (en) * 1999-03-02 2003-06-24 Microsoft Corporation Multiparty conferencing and collaboration system utilizing a per-host model command, control and communication structure
US7006616B1 (en) * 1999-05-21 2006-02-28 Terayon Communication Systems, Inc. Teleconferencing bridge with EdgePoint mixing
US7330875B1 (en) * 1999-06-15 2008-02-12 Microsoft Corporation System and method for recording a presentation for on-demand viewing over a computer network
DE19939388A1 (en) * 1999-08-19 2001-03-01 Siemens Ag Method and terminal for a communication network for setting up a conference call
AU7998600A (en) * 1999-10-07 2001-05-10 World Multicast.Com, Inc. Multiple buffered channel ip multicast
JP4357699B2 (en) * 1999-10-20 2009-11-04 富士通株式会社 Notification method and notification system for communication means
US6665726B1 (en) * 2000-01-06 2003-12-16 Akamai Technologies, Inc. Method and system for fault tolerant media streaming over the internet
US7379962B1 (en) * 2000-01-19 2008-05-27 Computer Associates Think, Inc. Spatialized audio in a three-dimensional computer-based scene
US6757450B1 (en) * 2000-03-30 2004-06-29 Microsoft Corporation Negotiated image data push processing
KR100803580B1 (en) * 2000-05-09 2008-02-15 삼성전자주식회사 Electronic music distribution service system and method using synchronous multimedia integration language format
US20060067500A1 (en) * 2000-05-15 2006-03-30 Christofferson Frank C Teleconferencing bridge with edgepoint mixing
US7571244B2 (en) * 2000-07-15 2009-08-04 Filippo Costanzo Audio-video data switching and viewing system
FI112307B (en) * 2000-08-02 2003-11-14 Nokia Corp communication Server
US6836804B1 (en) * 2000-10-30 2004-12-28 Cisco Technology, Inc. VoIP network
JP2002157206A (en) 2000-11-17 2002-05-31 Square Co Ltd Method and system for taking part in electronic conference
US7085842B2 (en) 2001-02-12 2006-08-01 Open Text Corporation Line navigation conferencing system
JP4612779B2 (en) * 2001-06-14 2011-01-12 キヤノン株式会社 COMMUNICATION DEVICE AND COMMUNICATION DEVICE VIDEO DISPLAY CONTROL METHOD
US20030056003A1 (en) * 2001-09-18 2003-03-20 Bryce Nakatani Internet broadcast and location tracking method and apparatus
US7493363B2 (en) * 2001-09-19 2009-02-17 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs
US20030078970A1 (en) * 2001-10-18 2003-04-24 Ronald Leaders Interactive web conferencing
TR200103599A1 (en) * 2001-12-12 2003-03-21 Telsi̇m Mobi̇l Telekomi̇ni̇kasyon Hi̇zmetleri̇ A.Ş. Conference chat service system and method
US8417827B2 (en) * 2001-12-12 2013-04-09 Nokia Corporation Synchronous media playback and messaging system
KR100433545B1 (en) * 2002-03-07 2004-05-31 삼성전자주식회사 Method for identifying that devices on the same network could support MCAP(Multicast Channel Allocation Protocol) and method for multicast thereof
US7454760B2 (en) 2002-04-22 2008-11-18 Rosebud Lms, Inc. Method and software for enabling n-way collaborative work over a network of computers
US6925357B2 (en) * 2002-07-25 2005-08-02 Intouch Health, Inc. Medical tele-robotic system
US20040162637A1 (en) 2002-07-25 2004-08-19 Yulun Wang Medical tele-robotic system with a master remote station with an arbitrator
JP2004133733A (en) * 2002-10-11 2004-04-30 Sony Corp Display device, display method, and program
US7613812B2 (en) 2002-12-04 2009-11-03 Microsoft Corporation Peer-to-peer identity management interfaces and methods
US20040121789A1 (en) * 2002-12-23 2004-06-24 Teddy Lindsey Method and apparatus for communicating information in a global distributed network
US7596625B2 (en) 2003-01-27 2009-09-29 Microsoft Corporation Peer-to-peer grouping interfaces and methods
EP1609075A4 (en) 2003-02-10 2006-11-02 Raindance Comm Inc Methods and apparatus for automatically adding a media component to an established multimedia collaboration session
US7558869B2 (en) * 2003-02-13 2009-07-07 Nokia Corporation Rate adaptation method and device in multimedia streaming
US8261062B2 (en) 2003-03-27 2012-09-04 Microsoft Corporation Non-cryptographic addressing
GB0319360D0 (en) * 2003-08-18 2003-09-17 Nokia Corp Setting up communication sessions
US7496648B2 (en) 2003-10-23 2009-02-24 Microsoft Corporation Managed peer name resolution protocol (PNRP) interfaces for peer to peer networking
US7246099B2 (en) 2003-10-23 2007-07-17 Feldhahn Jeffrey M Method and system for updating electronic business cards
US20100088105A1 (en) * 2003-10-23 2010-04-08 Feldhahn Jeffrey M Method and system for updating electronic business cards
US7949996B2 (en) 2003-10-23 2011-05-24 Microsoft Corporation Peer-to-peer identity management managed interfaces and methods
US7813836B2 (en) * 2003-12-09 2010-10-12 Intouch Technologies, Inc. Protocol for a remotely controlled videoconferencing robot
US7181170B2 (en) * 2003-12-22 2007-02-20 Motorola Inc. Apparatus and method for adaptive broadcast transmission
US8688803B2 (en) * 2004-03-26 2014-04-01 Microsoft Corporation Method for efficient content distribution using a peer-to-peer networking infrastructure
US7929689B2 (en) 2004-06-30 2011-04-19 Microsoft Corporation Call signs
US8077963B2 (en) 2004-07-13 2011-12-13 Yulun Wang Mobile robot with a head-based movement mapping scheme
US7620902B2 (en) * 2005-04-20 2009-11-17 Microsoft Corporation Collaboration spaces
US7571228B2 (en) 2005-04-22 2009-08-04 Microsoft Corporation Contact management in a serverless peer-to-peer system
US8036140B2 (en) 2005-04-22 2011-10-11 Microsoft Corporation Application programming interface for inviting participants in a serverless peer to peer network
US7752253B2 (en) * 2005-04-25 2010-07-06 Microsoft Corporation Collaborative invitation system and method
US7617281B2 (en) * 2005-04-25 2009-11-10 Microsoft Corporation System and method for collaboration with serverless presence
US7660851B2 (en) 2005-07-06 2010-02-09 Microsoft Corporation Meetings near me
US20070011232A1 (en) * 2005-07-06 2007-01-11 Microsoft Corporation User interface for starting presentations in a meeting
US9198728B2 (en) 2005-09-30 2015-12-01 Intouch Technologies, Inc. Multi-camera mobile teleconferencing platform
US7730192B2 (en) * 2006-03-20 2010-06-01 Microsoft Corporation Managing parallel requests in a communications environment supporting serial and parallel request handlers
US8069208B2 (en) 2006-04-21 2011-11-29 Microsoft Corporation Peer-to-peer buddy request and response
US8086842B2 (en) 2006-04-21 2011-12-27 Microsoft Corporation Peer-to-peer contact exchange
US20070291128A1 (en) * 2006-06-15 2007-12-20 Yulun Wang Mobile teleconferencing system that projects an image provided by a mobile robot
US8849679B2 (en) 2006-06-15 2014-09-30 Intouch Technologies, Inc. Remote controlled robot system that provides medical images
US7692041B2 (en) 2006-08-07 2010-04-06 The University Of Montana Method of oxidation using nitric acid
US20090250653A1 (en) 2006-08-07 2009-10-08 Kiely Donald E Hydroxycarboxylic Acids and Salts
US9160783B2 (en) 2007-05-09 2015-10-13 Intouch Technologies, Inc. Robot system that operates through a network firewall
AU2008322438B2 (en) 2007-11-15 2014-06-19 The University Of Montana Hydroxypolyamide gel forming agents
US8223851B2 (en) * 2007-11-23 2012-07-17 Samsung Electronics Co., Ltd. Method and an apparatus for embedding data in a media stream
EP2091189A1 (en) * 2008-02-13 2009-08-19 Nokia Siemens Networks Oy Re-activated group communication
US10875182B2 (en) 2008-03-20 2020-12-29 Teladoc Health, Inc. Remote presence system mounted to operating room hardware
US8179418B2 (en) 2008-04-14 2012-05-15 Intouch Technologies, Inc. Robotic based health care system
US8170241B2 (en) 2008-04-17 2012-05-01 Intouch Technologies, Inc. Mobile tele-presence system with a microphone system
US20090296608A1 (en) * 2008-05-29 2009-12-03 Microsoft Corporation Customized routing table for conferencing
US9193065B2 (en) 2008-07-10 2015-11-24 Intouch Technologies, Inc. Docking system for a tele-presence robot
US9842192B2 (en) 2008-07-11 2017-12-12 Intouch Technologies, Inc. Tele-presence robot system with multi-cast features
US8340819B2 (en) 2008-09-18 2012-12-25 Intouch Technologies, Inc. Mobile videoconferencing robot system with network adaptive driving
US8996165B2 (en) 2008-10-21 2015-03-31 Intouch Technologies, Inc. Telepresence robot with a camera boom
US9138891B2 (en) 2008-11-25 2015-09-22 Intouch Technologies, Inc. Server connectivity control for tele-presence robot
US8463435B2 (en) 2008-11-25 2013-06-11 Intouch Technologies, Inc. Server connectivity control for tele-presence robot
US8849680B2 (en) * 2009-01-29 2014-09-30 Intouch Technologies, Inc. Documentation through a remote presence robot
US8897920B2 (en) 2009-04-17 2014-11-25 Intouch Technologies, Inc. Tele-presence robot system with software modularity, projector and laser pointer
US8384755B2 (en) 2009-08-26 2013-02-26 Intouch Technologies, Inc. Portable remote presence robot
US11399153B2 (en) 2009-08-26 2022-07-26 Teladoc Health, Inc. Portable telepresence apparatus
US20110154222A1 (en) * 2009-12-18 2011-06-23 Microsoft Corporation Extensible mechanism for conveying feature capabilities in conversation systems
US11154981B2 (en) 2010-02-04 2021-10-26 Teladoc Health, Inc. Robot user interface for telepresence robot system
US8670017B2 (en) 2010-03-04 2014-03-11 Intouch Technologies, Inc. Remote presence system including a cart that supports a robot face and an overhead camera
US10343283B2 (en) 2010-05-24 2019-07-09 Intouch Technologies, Inc. Telepresence robot system that can be accessed by a cellular phone
US10808882B2 (en) 2010-05-26 2020-10-20 Intouch Technologies, Inc. Tele-robotic system with a robot face placed on a chair
JP5968898B2 (en) 2010-11-11 2016-08-10 リバートツプ・リニユーワブルズ Corrosion inhibiting composition
US9264664B2 (en) 2010-12-03 2016-02-16 Intouch Technologies, Inc. Systems and methods for dynamic bandwidth allocation
KR102018763B1 (en) 2011-01-28 2019-09-05 인터치 테크놀로지스 인코퍼레이티드 Interfacing with a mobile telepresence robot
US9323250B2 (en) 2011-01-28 2016-04-26 Intouch Technologies, Inc. Time-dependent navigation of telepresence robots
DK2699660T3 (en) 2011-04-21 2015-11-02 Rivertop Renewables Inc Calciumsekvesteringssammensætning
US10769739B2 (en) 2011-04-25 2020-09-08 Intouch Technologies, Inc. Systems and methods for management of information among medical providers and facilities
US20140139616A1 (en) 2012-01-27 2014-05-22 Intouch Technologies, Inc. Enhanced Diagnostics for a Telepresence Robot
US9098611B2 (en) 2012-11-26 2015-08-04 Intouch Technologies, Inc. Enhanced video interaction for a user interface of a telepresence network
US8836751B2 (en) 2011-11-08 2014-09-16 Intouch Technologies, Inc. Tele-presence system with a user interface that displays different communication links
US9584760B2 (en) 2012-02-16 2017-02-28 Covidien Lp Multifunctional conferencing systems and methods
US9251313B2 (en) 2012-04-11 2016-02-02 Intouch Technologies, Inc. Systems and methods for visualizing and managing telepresence devices in healthcare networks
US8902278B2 (en) 2012-04-11 2014-12-02 Intouch Technologies, Inc. Systems and methods for visualizing and managing telepresence devices in healthcare networks
WO2013176760A1 (en) 2012-05-22 2013-11-28 Intouch Technologies, Inc. Graphical user interfaces including touchpad driving interfaces for telemedicine devices
US9361021B2 (en) 2012-05-22 2016-06-07 Irobot Corporation Graphical user interfaces including touchpad driving interfaces for telemedicine devices
US10063596B2 (en) * 2012-10-10 2018-08-28 Sharp Laboratories Of America, Inc. Devices for managing data associated with an audio communication
WO2014085262A1 (en) 2012-11-28 2014-06-05 Rivertop Renewables Corrosion inhibiting, freezing point lowering compositions
CA2905808A1 (en) 2013-03-13 2014-10-02 Rivertop Renewables, Inc. Improved nitric acid oxidation processes
US9670124B2 (en) 2013-03-13 2017-06-06 Rivertop Renewables, Inc. Nitric acid oxidation process
US9346736B2 (en) 2013-03-13 2016-05-24 Rivertop Renewables, Inc. Oxidation process
US11627173B2 (en) 2013-03-14 2023-04-11 Comcast Cable Communications, Llc Custom content insertion for user groups
US20150109968A1 (en) * 2013-10-21 2015-04-23 Vonage Network Llc Method and system for automating conferencing in a communication session
US20150111553A1 (en) 2013-10-21 2015-04-23 Vonage Network Llc Method and system for automating conferencing in a communication session
US11095695B2 (en) 2016-07-26 2021-08-17 Hewlett-Packard Development Company, L.P. Teleconference transmission
US11862302B2 (en) 2017-04-24 2024-01-02 Teladoc Health, Inc. Automated transcription and documentation of tele-health encounters
US10483007B2 (en) 2017-07-25 2019-11-19 Intouch Technologies, Inc. Modular telehealth cart with thermal imaging and touch screen user interface
US11636944B2 (en) 2017-08-25 2023-04-25 Teladoc Health, Inc. Connectivity infrastructure for a telehealth platform
US10617299B2 (en) 2018-04-27 2020-04-14 Intouch Technologies, Inc. Telehealth cart that supports a removable tablet with seamless audio/video switching

Citations (229)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3584142A (en) 1968-12-13 1971-06-08 Bell Telephone Labor Inc Interactive computer graphics using video telephone
US4100377A (en) 1977-04-28 1978-07-11 Bell Telephone Laboratories, Incorporated Packet transmission of speech
US4387271A (en) 1979-11-19 1983-06-07 Cselt Centro Studi E Laboratori Telecomunicazioni S.P.A. Combined telephone and data-transfer system
US4506358A (en) 1982-06-25 1985-03-19 At&T Bell Laboratories Time stamping for a packet switching system
US4507781A (en) 1980-03-14 1985-03-26 Ibm Corporation Time domain multiple access broadcasting, multipoint, and conferencing communication apparatus and method
US4509167A (en) 1983-08-05 1985-04-02 At&T Bell Laboratories Data conference arrangement
US4516156A (en) 1982-03-15 1985-05-07 Satellite Business Systems Teleconferencing method and system
US4525779A (en) 1983-03-30 1985-06-25 Reuters Ltd. Conversational video system
US4574374A (en) 1983-10-25 1986-03-04 At&T Bell Laboratories Multilocation video conference terminal including rapid video switching
US4627052A (en) 1984-03-19 1986-12-02 International Computers Limited Interconnection of communications networks
US4645872A (en) 1982-04-01 1987-02-24 John Hopkins University Videophone network system
US4650929A (en) 1984-02-29 1987-03-17 Heinrich-Hertz-Institut Fur Nachrichtentechnik Berlin Gmbh Communication system for videoconferencing
US4653090A (en) 1985-12-16 1987-03-24 American Telephone & Telegraph (At&T) Graphics based call management
US4686698A (en) 1985-04-08 1987-08-11 Datapoint Corporation Workstation for interfacing with a video conferencing network
US4691314A (en) 1985-10-30 1987-09-01 Microcom, Inc. Method and apparatus for transmitting data in adjustable-sized packets
US4707831A (en) 1984-10-25 1987-11-17 Stc Plc Packet switching system
US4710917A (en) 1985-04-08 1987-12-01 Datapoint Corporation Video conferencing network
US4734765A (en) 1977-12-02 1988-03-29 Nippon Telegraph & Telephone Public Corp. Video/audio information transmission system
US4748620A (en) 1986-02-28 1988-05-31 American Telephone And Telegraph Company, At&T Bell Laboratories Time stamp and packet virtual sequence numbering for reconstructing information signals from packets
US4756019A (en) 1986-08-27 1988-07-05 Edmund Szybicki Traffic routing and automatic network management system for telecommunication networks
US4760572A (en) 1985-12-27 1988-07-26 Kabushiki Kaisha Toshiba Limited multicast communication method and communication network system realizing the method
US4763317A (en) 1985-12-13 1988-08-09 American Telephone And Telegraph Company, At&T Bell Laboratories Digital communication network architecture for providing universal information services
EP0279232A2 (en) 1987-02-13 1988-08-24 International Business Machines Corporation A system and method for version level negotiation
US4785415A (en) 1986-08-29 1988-11-15 Hewlett-Packard Company Digital data buffer and variable shift register
US4827339A (en) 1986-02-20 1989-05-02 Kokusai Denshin Denwa Co., Ltd. Moving picture signal transmission system
US4847829A (en) 1985-04-08 1989-07-11 Datapoint Corporation Video conferencing network
US4849811A (en) 1988-07-06 1989-07-18 Ben Kleinerman Simultaneous audio and video transmission with restricted bandwidth
US4882743A (en) 1988-08-01 1989-11-21 American Telephone And Telegraph Multi-location video conference system
US4888795A (en) 1987-06-30 1989-12-19 Nec Corporation Videotelephone apparatus for transmitting high and low resolution video signals over telephone exchange lines
US4893326A (en) 1987-05-04 1990-01-09 Video Telecom Corp. Video-telephone communications system
US4897866A (en) 1988-10-19 1990-01-30 American Telephone And Telegraph Company, At&T Bell Laboratories Telecommunication system with subscriber controlled feature modification
US4905231A (en) 1988-05-03 1990-02-27 American Telephone And Telegraph Company, At&T Bell Laboratories Multi-media virtual circuit
US4918718A (en) 1988-06-28 1990-04-17 Luma Telecom, Inc. Quadrature amplitude modulation with line synchronization pulse for video telephone
US4924311A (en) 1988-04-15 1990-05-08 Nec Corporation Dual-mode teleconferencing system
US4926415A (en) 1987-02-04 1990-05-15 Kabushiki Kaisha Toshiba Local area network system for efficiently transferring messages of different sizes
US4932047A (en) 1985-11-07 1990-06-05 Luma Telecom, Inc. Conversational video phone
US4935953A (en) 1989-04-27 1990-06-19 International Business Machines Corporation Cyclic video region transmission for videoconferencing systems
US4937856A (en) 1987-06-01 1990-06-26 Natarajan T Raj Digital voice conferencing bridge
US4942540A (en) 1987-03-02 1990-07-17 Wang Laboratories, Inc. Method an apparatus for specification of communication parameters
US4942470A (en) 1984-07-20 1990-07-17 Nec Corporation Real time processor for video signals
US4942569A (en) 1988-02-29 1990-07-17 Kabushiki Kaisha Toshiba Congestion control method for packet switching apparatus
US4943994A (en) 1987-10-30 1990-07-24 Luma Telecom Incorporated Still picture picturephone communications system
US4945410A (en) 1987-02-09 1990-07-31 Professional Satellite Imaging, Inc. Satellite communications system for medical related images
US4949169A (en) 1989-10-27 1990-08-14 International Business Machines Corporation Audio-video data interface for a high speed communication link in a video-graphics display window environment
US4953159A (en) 1989-01-03 1990-08-28 American Telephone And Telegraph Company Audiographics conferencing arrangement
US4953196A (en) 1987-05-13 1990-08-28 Ricoh Company, Ltd. Image transmission system
US4962521A (en) 1987-12-17 1990-10-09 Mitsubishi Denki Kabushiki Kaisha Apparatus for still picture video telephone apparatus and methods for transmitting and displaying still picture image for use therein
US4965819A (en) 1988-09-22 1990-10-23 Docu-Vision, Inc. Video conferencing system for courtroom and other applications
US4991171A (en) 1989-09-26 1991-02-05 At&T Bell Laboratories Broadcast packet switch network
US4991169A (en) 1988-08-02 1991-02-05 International Business Machines Corporation Real-time digital signal processing relative to multiple digital communication channels
US4995071A (en) 1988-07-08 1991-02-19 Telenorma Telefonbau Und Normalzeit Gmbh Video conference installation
US4999766A (en) 1988-06-13 1991-03-12 International Business Machines Corporation Managing host to workstation file transfer
US5003532A (en) 1989-06-02 1991-03-26 Fujitsu Limited Multi-point conference system
US5014267A (en) 1989-04-06 1991-05-07 Datapoint Corporation Video conferencing network
US5020023A (en) 1989-02-23 1991-05-28 International Business Machines Corporation Automatic vernier synchronization of skewed data streams
US5034916A (en) 1988-10-24 1991-07-23 Reuters Limited Fast contact conversational video system
US5042062A (en) 1989-10-23 1991-08-20 At&T Bell Laboratories Method and apparatus for providing real-time switching of high bandwidth transmission channels
US5042006A (en) 1988-02-27 1991-08-20 Alcatel N. V. Method of and circuit arrangement for guiding a user of a communication or data terminal
US5046080A (en) 1989-05-30 1991-09-03 Electronics And Telecommunications Research Institute Video codec including pipelined processing elements
US5046079A (en) 1988-10-14 1991-09-03 Hashimoto Corporation Telephone answering device with TV telephone
US5050166A (en) 1987-03-17 1991-09-17 Antonio Cantoni Transfer of messages in a multiplexed system
US5056136A (en) 1990-03-09 1991-10-08 The United States Of America As Represented By The United States Department Of Energy Secure video communications system
EP0453128A2 (en) 1990-04-12 1991-10-23 AT&T Corp. Multiple call control method in a multimedia conferencing system
US5062136A (en) 1990-09-12 1991-10-29 The United States Of America As Represented By The Secretary Of The Navy Telecommunications system and method
US5072442A (en) 1990-02-28 1991-12-10 Harris Corporation Multiple clock rate teleconferencing network
US5077732A (en) 1988-11-14 1991-12-31 Datapoint Corporation LAN with dynamically selectable multiple operational capabilities
US5079627A (en) 1988-06-15 1992-01-07 Optum Corporation Videophone
US5083269A (en) 1989-01-10 1992-01-21 Kabushiki Kaisha Toshiba Buffer device suitable for asynchronous transfer mode communication
US5099510A (en) 1990-06-11 1992-03-24 Communications Network Enhancement Inc. Teleconferencing with bridge partitioning and other features
US5101451A (en) 1988-12-29 1992-03-31 At&T Bell Laboratories Real-time network routing
US5109483A (en) 1987-06-15 1992-04-28 International Business Machines Corp. Node initiating xid exchanges over an activated link including an exchange of sets of binding signals between nodes for establishing sessions
US5132966A (en) 1989-03-23 1992-07-21 Nec Corporation Call control with transmission priority in a packet communication network of an atm type
US5136692A (en) 1987-02-13 1992-08-04 International Business Machines Corporation Memory disk buffer manager
US5136581A (en) 1990-07-02 1992-08-04 At&T Bell Laboratories Arrangement for reserving and allocating a plurality of competing demands for an ordered bus communication network
US5140417A (en) 1989-06-20 1992-08-18 Matsushita Electric Co., Ltd. Fast packet transmission system of video data
US5140584A (en) 1989-03-01 1992-08-18 Kabushiki Kaisha Toshiba Packet communication system and method of controlling same
US5155594A (en) 1990-05-11 1992-10-13 Picturetel Corporation Hierarchical encoding method and apparatus employing background references for efficiently communicating image sequences
US5157662A (en) 1990-02-13 1992-10-20 Hitachi, Ltd. Data communication apparatus having communication-mode changeover function and method of data communication between data communication stations having the same
US5163045A (en) 1990-10-01 1992-11-10 At&T Bell Laboratories Communications network arranged to transport connection oriented and connectionless messages
US5177604A (en) 1986-05-14 1993-01-05 Radio Telcom & Technology, Inc. Interactive television and data transmission system
US5192999A (en) 1991-04-25 1993-03-09 Compuadd Corporation Multipurpose computerized television
US5200951A (en) 1989-09-12 1993-04-06 Siemens-Albis Ag Apparatus and method for transmitting messages between a plurality of subscriber stations
US5206934A (en) 1989-08-15 1993-04-27 Group Technologies, Inc. Method and apparatus for interactive computer conferencing
US5210836A (en) 1989-10-13 1993-05-11 Texas Instruments Incorporated Instruction generator architecture for a video signal processor controller
US5220653A (en) 1990-10-26 1993-06-15 International Business Machines Corporation Scheduling input/output operations in multitasking systems
US5231492A (en) 1989-03-16 1993-07-27 Fujitsu Limited Video and audio multiplex transmission system
US5241625A (en) 1990-11-27 1993-08-31 Farallon Computing, Inc. Screen image sharing among heterogeneous computers
US5243596A (en) 1992-03-18 1993-09-07 Fischer & Porter Company Network architecture suitable for multicasting and resource locking
US5247626A (en) 1990-05-29 1993-09-21 Advanced Micro Devices, Inc. Fddi controller having flexible buffer management
US5253251A (en) 1991-01-08 1993-10-12 Nec Corporation Switching system with time-stamped packet distribution input stage and packet sequencing output stage
US5276679A (en) 1992-02-12 1994-01-04 U.S. West Advanced Technologies, Inc. Method for maintaining channels and a subscriber station for use in an ISDN system
US5283638A (en) 1991-04-25 1994-02-01 Compuadd Corporation Multimedia computing and telecommunications workstation
US5289470A (en) 1992-12-14 1994-02-22 International Business Machines Corp. Flexible scheme for buffer space allocation in networking devices
US5291492A (en) 1991-12-18 1994-03-01 Unifi Communications Corporation Externally controlled call processing system
US5297143A (en) 1990-12-03 1994-03-22 Echelon Systems, Corp. Network communication protocol including a reliable multicasting technique
CA2080530A1 (en) 1992-10-14 1994-04-15 Ho Kee Chiu Dynamic networking
US5307351A (en) 1991-08-26 1994-04-26 Universal Data Systems, Inc. Data communication apparatus for adjusting frame length and method of operating same
US5309433A (en) 1992-06-18 1994-05-03 International Business Machines Corp. Methods and apparatus for routing packets in packet transmission networks
US5311585A (en) 1992-04-14 1994-05-10 At&T Bell Laboratories Carrier proportioned routing
US5313455A (en) 1990-04-23 1994-05-17 Koninklijke Ptt Nederland N.V. Transmission system with recording of untransmitted packets
US5313454A (en) 1992-04-01 1994-05-17 Stratacom, Inc. Congestion control for cell networks
US5315586A (en) 1991-06-28 1994-05-24 Nec Corporation Resource reallocation for flow-enforced user traffic
US5323445A (en) 1991-03-07 1994-06-21 Mitsubishi Denki Kabushiki Kaisha Multi-location television conference system
US5333299A (en) 1991-12-31 1994-07-26 International Business Machines Corporation Synchronization techniques for multimedia data streams
US5333135A (en) 1993-02-01 1994-07-26 North American Philips Corporation Identification of a data stream transmitted as a sequence of packets
US5341374A (en) 1991-03-01 1994-08-23 Trilan Systems Corporation Communication network integrating voice data and video with distributed call processing
US5355371A (en) 1982-06-18 1994-10-11 International Business Machines Corp. Multicast communication tree creation and control method and apparatus
US5367637A (en) 1992-03-26 1994-11-22 International Business Machines Corporation Self-tuning virtual storage management for dedicated real-time computer system
US5371534A (en) 1992-07-23 1994-12-06 At&T Corp. ISDN-based system for making a video call
US5373549A (en) 1992-12-23 1994-12-13 At&T Corp. Multi-level conference management and notification
US5374952A (en) 1993-06-03 1994-12-20 Target Technologies, Inc. Videoconferencing system
US5375068A (en) 1992-06-03 1994-12-20 Digital Equipment Corporation Video teleconferencing for networked workstations
US5377196A (en) 1991-03-12 1994-12-27 Hewlett-Packard Company System and method of proactively and reactively diagnosing a data communication network
US5384770A (en) 1992-05-08 1995-01-24 Hayes Microcomputer Products, Inc. Packet assembler
US5392344A (en) 1991-10-03 1995-02-21 At&T Corp. Communications network class-of-service routing
US5402412A (en) 1993-10-15 1995-03-28 Dsc Communications Corporation System and method for monitoring a stream of events
US5422883A (en) 1992-10-16 1995-06-06 International Business Machines Corporation Call setup and channel allocation for a multi-media network bus
US5422942A (en) 1992-09-14 1995-06-06 Sony Corporation Incoming call transfer terminal
US5432525A (en) 1989-07-26 1995-07-11 Hitachi, Ltd. Multimedia telemeeting terminal device, terminal device system and manipulation method thereof
US5434860A (en) 1994-04-20 1995-07-18 Apple Computer, Inc. Flow control for real-time data streams
US5440624A (en) 1992-11-10 1995-08-08 Netmedia, Inc. Method and apparatus for providing adaptive administration and control of an electronic conference
US5442749A (en) 1991-08-22 1995-08-15 Sun Microsystems, Inc. Network video server system receiving requests from clients for specific formatted data through a default channel and establishing communication through separate control and data channels
US5444709A (en) 1993-09-30 1995-08-22 Apple Computer, Inc. Protocol for transporting real time data
US5453780A (en) 1994-04-28 1995-09-26 Bell Communications Research, Inc. Continous presence video signal combiner
US5455826A (en) 1994-06-28 1995-10-03 Oezveren; Cueneyt M. Method and apparatus for rate based flow control
US5455854A (en) 1993-10-26 1995-10-03 Taligent, Inc. Object-oriented telephony system
US5459725A (en) 1994-03-22 1995-10-17 International Business Machines Corporation Reliable multicasting over spanning trees in packet communications networks
GB2289149A (en) 1994-05-02 1995-11-08 Ubique Ltd Data retrieval system providing co-presence
US5473679A (en) 1993-12-09 1995-12-05 At&T Corp. Signaling system for broadband communications networks
US5475746A (en) 1993-09-22 1995-12-12 At&T Corp. Method for permitting subscribers to change call features in real time
US5477546A (en) 1991-07-15 1995-12-19 Hitachi, Ltd. Teleconference terminal equipment and teleconference module
US5483588A (en) 1994-12-23 1996-01-09 Latitute Communications Voice processing interface for a teleconference system
US5483587A (en) 1994-06-08 1996-01-09 Linkusa Corporation System and method for call conferencing
US5487167A (en) 1991-12-31 1996-01-23 International Business Machines Corporation Personal computer with generalized data streaming apparatus for multimedia devices
US5490247A (en) 1993-11-24 1996-02-06 Intel Corporation Video subsystem for computer-based conferencing system
US5491798A (en) 1993-09-25 1996-02-13 International Business Machines Corporation Method for network call management
US5502726A (en) 1992-01-31 1996-03-26 Nellcor Incorporated Serial layered medical network
US5506844A (en) 1994-05-20 1996-04-09 Compression Labs, Inc. Method for configuring a statistical multiplexer to dynamically allocate communication channel bandwidth
US5506954A (en) 1993-11-24 1996-04-09 Intel Corporation PC-based conferencing system
US5509010A (en) 1993-06-25 1996-04-16 At&T Corp. Communications signaling protocols
US5511168A (en) 1993-07-01 1996-04-23 Digital Equipment Corporation Virtual circuit manager for multicast messaging
US5515491A (en) 1992-12-31 1996-05-07 International Business Machines Corporation Method and system for managing communications within a collaborative data processing system
US5522073A (en) 1993-11-22 1996-05-28 Hewlett-Packard Company Method and apparatus for automating and controlling execution of software tools and tool sets via when/then relationships
US5524110A (en) 1993-11-24 1996-06-04 Intel Corporation Conferencing over multiple transports
US5526037A (en) 1993-10-20 1996-06-11 Videoconferencing Systems, Inc. Method for remotely controlling a peripheral device in a videoconferencing system
US5530808A (en) 1993-12-10 1996-06-25 International Business Machines Corporation System for transferring ownership of transmitted data packet from source node to destination node upon reception of echo packet at source node from destination node
US5530902A (en) 1993-06-14 1996-06-25 Motorola, Inc. Data packet switching system having DMA controller, service arbiter, buffer type managers, and buffer managers for managing data transfer to provide less processor intervention
US5532937A (en) 1994-01-31 1996-07-02 International Business Machines Corporation Switching of multiple multimedia data streams
US5537548A (en) 1991-08-08 1996-07-16 International Business Machines Corporation Method of computer conferencing by intercepting commands issued by application programs and redirecting to all stations for execution
US5541927A (en) 1994-08-24 1996-07-30 At&T Corp. Method of multicasting
US5544300A (en) 1993-11-12 1996-08-06 Intel Corporation User interface for dynamically converting between a single top level window and multiple top level windows
US5546395A (en) 1993-01-08 1996-08-13 Multi-Tech Systems, Inc. Dynamic selection of compression rate for a voice compression algorithm in a voice over data modem
US5550754A (en) 1994-05-13 1996-08-27 Videoptic Research Teleconferencing camcorder
US5557749A (en) 1992-10-15 1996-09-17 Intel Corporation System for automatically compressing and decompressing data for sender and receiver processes upon determination of a common compression/decompression method understood by both sender and receiver processes
US5557724A (en) 1993-10-12 1996-09-17 Intel Corporation User interface, method, and apparatus selecting and playing channels having video, audio, and/or text streams
US5566000A (en) 1993-11-15 1996-10-15 Qualcomm Incorporated System and method for reducing bottlenecks in low data rate networks processing facsimile data transmission
US5572232A (en) 1993-08-06 1996-11-05 Intel Corporation Method and apparatus for displaying an image using subsystem interrogation
US5572582A (en) 1995-02-24 1996-11-05 Apple Computer, Inc. Method and apparatus for establishing communication between two teleconferencing endpoints
US5574934A (en) 1993-11-24 1996-11-12 Intel Corporation Preemptive priority-based transmission of signals using virtual channels
US5577208A (en) 1991-06-25 1996-11-19 Alcatel Nv "Multimedia" intercommunication between workstations having auxiliary unit directly connected to output of workstation and input to display wherein local and remote image data are combined
US5587928A (en) 1994-05-13 1996-12-24 Vivo Software, Inc. Computer teleconferencing method and apparatus
US5594859A (en) 1992-06-03 1997-01-14 Digital Equipment Corporation Graphical user interface for video teleconferencing
US5600646A (en) 1995-01-27 1997-02-04 Videoserver, Inc. Video teleconferencing system with digital transcoding
US5600797A (en) 1993-11-24 1997-02-04 Intel Corporation System for identifying new client and allocating bandwidth thereto by monitoring transmission of message received periodically from client computers informing of their current status
US5604742A (en) 1995-05-31 1997-02-18 International Business Machines Corporation Communications system and method for efficient management of bandwidth in a FDDI station
US5612788A (en) 1993-07-30 1997-03-18 Sony Corporation Video data compression apparatus for recording and reproducing compressed video data at their various compressed data rates
US5617539A (en) 1993-10-01 1997-04-01 Vicor, Inc. Multimedia collaboration system with separate data network and A/V network controlled by information transmitting on the data network
US5621894A (en) 1993-11-05 1997-04-15 Microsoft Corporation System and method for exchanging computer data processing capabilites
US5623490A (en) 1993-06-09 1997-04-22 Intelligence-At-Large Method and apparatus for multiple media digital communication system
US5623483A (en) 1995-05-11 1997-04-22 Lucent Technologies Inc. Synchronization system for networked multimedia streams
US5623690A (en) 1992-06-03 1997-04-22 Digital Equipment Corporation Audio/video storage and retrieval for multimedia workstations by interleaving audio and video data in data file
US5625407A (en) 1994-07-08 1997-04-29 Lucent Technologies Inc. Seamless multimedia conferencing system using an enhanced multipoint control unit and enhanced endpoint devices
US5627978A (en) 1994-12-16 1997-05-06 Lucent Technologies Inc. Graphical user interface for multimedia call set-up and call handling in a virtual conference on a desktop computer conferencing system
US5632022A (en) 1991-11-13 1997-05-20 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Encyclopedia of software components
US5649105A (en) 1992-11-10 1997-07-15 Ibm Corp. Collaborative working in a network
US5652887A (en) 1994-06-22 1997-07-29 International Business Machines Corporation Dynamic Meta commands for peripheral devices
US5659692A (en) 1992-01-13 1997-08-19 Massachusetts Institute Of Technology Computer method and apparatus for video conferencing
US5664164A (en) 1995-02-24 1997-09-02 Apple Computer, Inc. Synchronization of one or more data streams
US5664126A (en) 1992-07-24 1997-09-02 Kabushiki Kaisha Toshiba Human interface system for communicating networked users
US5664226A (en) 1994-09-08 1997-09-02 International Business Machines Corporation System for merging plurality of atomic data elements into single synchronized file by assigning ouput rate to each channel in response to presentation time duration
US5671428A (en) 1991-08-28 1997-09-23 Kabushiki Kaisha Toshiba Collaborative document processing system with version and comment management
US5673393A (en) 1993-11-24 1997-09-30 Intel Corporation Managing bandwidth over a computer network having a management computer that allocates bandwidth to client computers upon request
US5674003A (en) 1995-04-28 1997-10-07 Andersen; David B. Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface
US5708697A (en) 1996-06-27 1998-01-13 Mci Communications Corporation Communication network call traffic manager
US5710591A (en) 1995-06-27 1998-01-20 At&T Method and apparatus for recording and indexing an audio and multimedia conference
US5717863A (en) 1995-09-27 1998-02-10 Intel Corporation Method and apparatus for managing pc conference connection addresses
US5721729A (en) 1996-01-24 1998-02-24 Klingman; Edwin E. Universal input call processing system
US5724508A (en) 1995-03-09 1998-03-03 Insoft, Inc. Apparatus for collaborative computing
US5724578A (en) 1994-12-07 1998-03-03 Fujitsu Limited File managing system for managing files shared with a plurality of users
US5729687A (en) 1993-12-20 1998-03-17 Intel Corporation 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
US5737599A (en) 1995-09-25 1998-04-07 Rowe; Edward R. Method and apparatus for downloading multi-page electronic documents with hint information
US5742773A (en) 1996-04-18 1998-04-21 Microsoft Corporation Method and system for audio compression negotiation for multiple channels
US5742670A (en) 1995-01-09 1998-04-21 Ncr Corporation Passive telephone monitor to control collaborative systems
US5754765A (en) 1993-11-24 1998-05-19 Intel Corporation Automatic transport detection by attempting to establish communication session using list of possible transports and corresponding media dependent modules
US5754306A (en) 1993-06-15 1998-05-19 Hewlett-Packard Company System and method for a communication system
US5760769A (en) 1995-12-22 1998-06-02 Intel Corporation Apparatus and method for identifying a shared application program in a computer during teleconferencing
US5764915A (en) 1996-03-08 1998-06-09 International Business Machines Corporation Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack
US5793365A (en) 1996-01-02 1998-08-11 Sun Microsystems, Inc. System and method providing a computer user interface enabling access to distributed workgroup members
US5799151A (en) 1994-04-04 1998-08-25 Hoffer; Steven M. Interactive electronic trade network and user interface
US5801700A (en) 1996-01-19 1998-09-01 Silicon Graphics Incorporated System and method for an iconic drag and drop interface for electronic file transfer
US5809237A (en) 1993-11-24 1998-09-15 Intel Corporation Registration of computer-based conferencing system
US5841763A (en) 1995-06-13 1998-11-24 Multilink, Inc. Audio-video conferencing system
US5841976A (en) 1996-03-29 1998-11-24 Intel Corporation Method and apparatus for supporting multipoint communications in a protocol-independent manner
US5848143A (en) 1995-03-02 1998-12-08 Geotel Communications Corp. Communications system using a central controller to control at least one network and agent system
US5854898A (en) 1995-02-24 1998-12-29 Apple Computer, Inc. System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US5857189A (en) 1996-05-08 1999-01-05 Apple Computer, Inc. File sharing in a teleconference application
US5864678A (en) 1996-05-08 1999-01-26 Apple Computer, Inc. System for detecting and reporting data flow imbalance between computers using grab rate outflow rate arrival rate and play rate
US5872923A (en) 1993-03-19 1999-02-16 Ncr Corporation Collaborative video conferencing system
US5887170A (en) 1995-02-13 1999-03-23 International Business Machines Corporation System for classifying and sending selective requests to different participants of a collaborative application thereby allowing concurrent execution of collaborative and non-collaborative applications
US5903754A (en) 1994-06-21 1999-05-11 Microsoft Corporation Dynamic layered protocol stack
US5907324A (en) 1995-06-07 1999-05-25 Intel Corporation Method for saving and accessing desktop conference characteristics with a persistent conference object
US5920732A (en) 1996-07-01 1999-07-06 Apple Computer, Inc. System for preallocating additional larger buffer sizes in accordance with packet sizes of discarded packets that can't be stored in existing preallocated buffer sizes
US5933597A (en) 1996-04-04 1999-08-03 Vtel Corporation Method and system for sharing objects between local and remote terminals
US5931961A (en) 1996-05-08 1999-08-03 Apple Computer, Inc. Discovery of acceptable packet size using ICMP echo
US5973724A (en) 1995-02-24 1999-10-26 Apple Computer, Inc. Merging multiple teleconferences
US5983261A (en) 1996-07-01 1999-11-09 Apple Computer, Inc. Method and apparatus for allocating bandwidth in teleconferencing applications using bandwidth control
US6008806A (en) 1994-12-13 1999-12-28 Microsoft Corporation Shell extensions for an operating system
US6151619A (en) 1996-11-26 2000-11-21 Apple Computer, Inc. Method and apparatus for maintaining configuration information of a teleconference and identification of endpoint during teleconference
US6175856B1 (en) 1996-09-30 2001-01-16 Apple Computer, Inc. Method and apparatus for dynamic selection of compression processing during teleconference call initiation
US6189034B1 (en) 1996-05-08 2001-02-13 Apple Computer, Inc. Method and apparatus for dynamic launching of a teleconferencing application upon receipt of a call
US6295549B1 (en) 1996-05-08 2001-09-25 Apple Computer, Inc. Method and apparatus for listening for incoming calls on multiple port/socket combinations
US20020029350A1 (en) 2000-02-11 2002-03-07 Cooper Robin Ross Web based human services conferencing network
US20020073150A1 (en) 2000-10-17 2002-06-13 Lawrence Wilcock Associating parties with communication sessions
US20020076025A1 (en) 2000-12-18 2002-06-20 Nortel Networks Limited And Bell Canada Method and system for automatic handling of invitations to join communications sessions in a virtual team environment
US6738357B1 (en) 1993-06-09 2004-05-18 Btg International Inc. Method and apparatus for multiple media digital communication system
US20040153510A1 (en) 1996-05-08 2004-08-05 Guy Riddle Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
WO2005104466A1 (en) 2004-04-21 2005-11-03 Koninklijke Philips Electronics, N.V. System and method for chat load management in a network chat environment
US7039019B2 (en) 2001-03-27 2006-05-02 Kabushiki Kaisha Toshiba Telephone exchanging apparatus and telephone system
EP1670197A2 (en) 2003-01-20 2006-06-14 Avaya Technology Corp. Messaging advice in presence-aware networks

Patent Citations (250)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3584142A (en) 1968-12-13 1971-06-08 Bell Telephone Labor Inc Interactive computer graphics using video telephone
US4100377A (en) 1977-04-28 1978-07-11 Bell Telephone Laboratories, Incorporated Packet transmission of speech
US4734765A (en) 1977-12-02 1988-03-29 Nippon Telegraph & Telephone Public Corp. Video/audio information transmission system
US4387271A (en) 1979-11-19 1983-06-07 Cselt Centro Studi E Laboratori Telecomunicazioni S.P.A. Combined telephone and data-transfer system
US4507781A (en) 1980-03-14 1985-03-26 Ibm Corporation Time domain multiple access broadcasting, multipoint, and conferencing communication apparatus and method
US4516156A (en) 1982-03-15 1985-05-07 Satellite Business Systems Teleconferencing method and system
US4645872A (en) 1982-04-01 1987-02-24 John Hopkins University Videophone network system
US5355371A (en) 1982-06-18 1994-10-11 International Business Machines Corp. Multicast communication tree creation and control method and apparatus
US4506358A (en) 1982-06-25 1985-03-19 At&T Bell Laboratories Time stamping for a packet switching system
US4525779A (en) 1983-03-30 1985-06-25 Reuters Ltd. Conversational video system
US4509167A (en) 1983-08-05 1985-04-02 At&T Bell Laboratories Data conference arrangement
US4574374A (en) 1983-10-25 1986-03-04 At&T Bell Laboratories Multilocation video conference terminal including rapid video switching
US4650929A (en) 1984-02-29 1987-03-17 Heinrich-Hertz-Institut Fur Nachrichtentechnik Berlin Gmbh Communication system for videoconferencing
US4627052A (en) 1984-03-19 1986-12-02 International Computers Limited Interconnection of communications networks
US4942470A (en) 1984-07-20 1990-07-17 Nec Corporation Real time processor for video signals
US4707831A (en) 1984-10-25 1987-11-17 Stc Plc Packet switching system
US4686698A (en) 1985-04-08 1987-08-11 Datapoint Corporation Workstation for interfacing with a video conferencing network
US4710917A (en) 1985-04-08 1987-12-01 Datapoint Corporation Video conferencing network
US4847829A (en) 1985-04-08 1989-07-11 Datapoint Corporation Video conferencing network
US4691314A (en) 1985-10-30 1987-09-01 Microcom, Inc. Method and apparatus for transmitting data in adjustable-sized packets
US4932047A (en) 1985-11-07 1990-06-05 Luma Telecom, Inc. Conversational video phone
US4763317A (en) 1985-12-13 1988-08-09 American Telephone And Telegraph Company, At&T Bell Laboratories Digital communication network architecture for providing universal information services
US4653090A (en) 1985-12-16 1987-03-24 American Telephone & Telegraph (At&T) Graphics based call management
US4760572A (en) 1985-12-27 1988-07-26 Kabushiki Kaisha Toshiba Limited multicast communication method and communication network system realizing the method
US4827339A (en) 1986-02-20 1989-05-02 Kokusai Denshin Denwa Co., Ltd. Moving picture signal transmission system
US4748620A (en) 1986-02-28 1988-05-31 American Telephone And Telegraph Company, At&T Bell Laboratories Time stamp and packet virtual sequence numbering for reconstructing information signals from packets
US5177604A (en) 1986-05-14 1993-01-05 Radio Telcom & Technology, Inc. Interactive television and data transmission system
US4756019A (en) 1986-08-27 1988-07-05 Edmund Szybicki Traffic routing and automatic network management system for telecommunication networks
US4785415A (en) 1986-08-29 1988-11-15 Hewlett-Packard Company Digital data buffer and variable shift register
US4926415A (en) 1987-02-04 1990-05-15 Kabushiki Kaisha Toshiba Local area network system for efficiently transferring messages of different sizes
US4945410A (en) 1987-02-09 1990-07-31 Professional Satellite Imaging, Inc. Satellite communications system for medical related images
US5136692A (en) 1987-02-13 1992-08-04 International Business Machines Corporation Memory disk buffer manager
EP0279232A2 (en) 1987-02-13 1988-08-24 International Business Machines Corporation A system and method for version level negotiation
US4942540A (en) 1987-03-02 1990-07-17 Wang Laboratories, Inc. Method an apparatus for specification of communication parameters
US5050166A (en) 1987-03-17 1991-09-17 Antonio Cantoni Transfer of messages in a multiplexed system
US4893326A (en) 1987-05-04 1990-01-09 Video Telecom Corp. Video-telephone communications system
US4953196A (en) 1987-05-13 1990-08-28 Ricoh Company, Ltd. Image transmission system
US4937856A (en) 1987-06-01 1990-06-26 Natarajan T Raj Digital voice conferencing bridge
US5109483A (en) 1987-06-15 1992-04-28 International Business Machines Corp. Node initiating xid exchanges over an activated link including an exchange of sets of binding signals between nodes for establishing sessions
US4888795A (en) 1987-06-30 1989-12-19 Nec Corporation Videotelephone apparatus for transmitting high and low resolution video signals over telephone exchange lines
US4943994A (en) 1987-10-30 1990-07-24 Luma Telecom Incorporated Still picture picturephone communications system
US4962521A (en) 1987-12-17 1990-10-09 Mitsubishi Denki Kabushiki Kaisha Apparatus for still picture video telephone apparatus and methods for transmitting and displaying still picture image for use therein
US5042006A (en) 1988-02-27 1991-08-20 Alcatel N. V. Method of and circuit arrangement for guiding a user of a communication or data terminal
US4942569A (en) 1988-02-29 1990-07-17 Kabushiki Kaisha Toshiba Congestion control method for packet switching apparatus
US4924311A (en) 1988-04-15 1990-05-08 Nec Corporation Dual-mode teleconferencing system
US4905231A (en) 1988-05-03 1990-02-27 American Telephone And Telegraph Company, At&T Bell Laboratories Multi-media virtual circuit
US4999766A (en) 1988-06-13 1991-03-12 International Business Machines Corporation Managing host to workstation file transfer
US5079627A (en) 1988-06-15 1992-01-07 Optum Corporation Videophone
US4918718A (en) 1988-06-28 1990-04-17 Luma Telecom, Inc. Quadrature amplitude modulation with line synchronization pulse for video telephone
US4849811A (en) 1988-07-06 1989-07-18 Ben Kleinerman Simultaneous audio and video transmission with restricted bandwidth
US4995071A (en) 1988-07-08 1991-02-19 Telenorma Telefonbau Und Normalzeit Gmbh Video conference installation
US4882743A (en) 1988-08-01 1989-11-21 American Telephone And Telegraph Multi-location video conference system
US4991169A (en) 1988-08-02 1991-02-05 International Business Machines Corporation Real-time digital signal processing relative to multiple digital communication channels
US4965819A (en) 1988-09-22 1990-10-23 Docu-Vision, Inc. Video conferencing system for courtroom and other applications
US5046079A (en) 1988-10-14 1991-09-03 Hashimoto Corporation Telephone answering device with TV telephone
US4897866A (en) 1988-10-19 1990-01-30 American Telephone And Telegraph Company, At&T Bell Laboratories Telecommunication system with subscriber controlled feature modification
US5034916A (en) 1988-10-24 1991-07-23 Reuters Limited Fast contact conversational video system
US5077732A (en) 1988-11-14 1991-12-31 Datapoint Corporation LAN with dynamically selectable multiple operational capabilities
US5077732C1 (en) 1988-11-14 2001-08-14 Datapoint Corp Lan with dynamically selectable multiple operational capabilities
US5101451A (en) 1988-12-29 1992-03-31 At&T Bell Laboratories Real-time network routing
US4953159A (en) 1989-01-03 1990-08-28 American Telephone And Telegraph Company Audiographics conferencing arrangement
US5083269A (en) 1989-01-10 1992-01-21 Kabushiki Kaisha Toshiba Buffer device suitable for asynchronous transfer mode communication
US5020023A (en) 1989-02-23 1991-05-28 International Business Machines Corporation Automatic vernier synchronization of skewed data streams
US5140584A (en) 1989-03-01 1992-08-18 Kabushiki Kaisha Toshiba Packet communication system and method of controlling same
US5231492A (en) 1989-03-16 1993-07-27 Fujitsu Limited Video and audio multiplex transmission system
US5132966A (en) 1989-03-23 1992-07-21 Nec Corporation Call control with transmission priority in a packet communication network of an atm type
US5014267A (en) 1989-04-06 1991-05-07 Datapoint Corporation Video conferencing network
US4935953A (en) 1989-04-27 1990-06-19 International Business Machines Corporation Cyclic video region transmission for videoconferencing systems
US5046080A (en) 1989-05-30 1991-09-03 Electronics And Telecommunications Research Institute Video codec including pipelined processing elements
US5003532A (en) 1989-06-02 1991-03-26 Fujitsu Limited Multi-point conference system
US5140417A (en) 1989-06-20 1992-08-18 Matsushita Electric Co., Ltd. Fast packet transmission system of video data
US5432525A (en) 1989-07-26 1995-07-11 Hitachi, Ltd. Multimedia telemeeting terminal device, terminal device system and manipulation method thereof
US5206934A (en) 1989-08-15 1993-04-27 Group Technologies, Inc. Method and apparatus for interactive computer conferencing
US5200951A (en) 1989-09-12 1993-04-06 Siemens-Albis Ag Apparatus and method for transmitting messages between a plurality of subscriber stations
US4991171A (en) 1989-09-26 1991-02-05 At&T Bell Laboratories Broadcast packet switch network
US5210836A (en) 1989-10-13 1993-05-11 Texas Instruments Incorporated Instruction generator architecture for a video signal processor controller
US5042062A (en) 1989-10-23 1991-08-20 At&T Bell Laboratories Method and apparatus for providing real-time switching of high bandwidth transmission channels
US4949169A (en) 1989-10-27 1990-08-14 International Business Machines Corporation Audio-video data interface for a high speed communication link in a video-graphics display window environment
US5157662A (en) 1990-02-13 1992-10-20 Hitachi, Ltd. Data communication apparatus having communication-mode changeover function and method of data communication between data communication stations having the same
US5072442A (en) 1990-02-28 1991-12-10 Harris Corporation Multiple clock rate teleconferencing network
US5056136A (en) 1990-03-09 1991-10-08 The United States Of America As Represented By The United States Department Of Energy Secure video communications system
EP0453128A2 (en) 1990-04-12 1991-10-23 AT&T Corp. Multiple call control method in a multimedia conferencing system
US5195086A (en) * 1990-04-12 1993-03-16 At&T Bell Laboratories Multiple call control method in a multimedia conferencing system
US5313455A (en) 1990-04-23 1994-05-17 Koninklijke Ptt Nederland N.V. Transmission system with recording of untransmitted packets
US5155594A (en) 1990-05-11 1992-10-13 Picturetel Corporation Hierarchical encoding method and apparatus employing background references for efficiently communicating image sequences
US5247626A (en) 1990-05-29 1993-09-21 Advanced Micro Devices, Inc. Fddi controller having flexible buffer management
US5099510A (en) 1990-06-11 1992-03-24 Communications Network Enhancement Inc. Teleconferencing with bridge partitioning and other features
US5136581A (en) 1990-07-02 1992-08-04 At&T Bell Laboratories Arrangement for reserving and allocating a plurality of competing demands for an ordered bus communication network
US5062136A (en) 1990-09-12 1991-10-29 The United States Of America As Represented By The Secretary Of The Navy Telecommunications system and method
US5163045A (en) 1990-10-01 1992-11-10 At&T Bell Laboratories Communications network arranged to transport connection oriented and connectionless messages
US5220653A (en) 1990-10-26 1993-06-15 International Business Machines Corporation Scheduling input/output operations in multitasking systems
US5241625A (en) 1990-11-27 1993-08-31 Farallon Computing, Inc. Screen image sharing among heterogeneous computers
US5297143A (en) 1990-12-03 1994-03-22 Echelon Systems, Corp. Network communication protocol including a reliable multicasting technique
US5253251A (en) 1991-01-08 1993-10-12 Nec Corporation Switching system with time-stamped packet distribution input stage and packet sequencing output stage
US5341374A (en) 1991-03-01 1994-08-23 Trilan Systems Corporation Communication network integrating voice data and video with distributed call processing
US5323445A (en) 1991-03-07 1994-06-21 Mitsubishi Denki Kabushiki Kaisha Multi-location television conference system
US5377196A (en) 1991-03-12 1994-12-27 Hewlett-Packard Company System and method of proactively and reactively diagnosing a data communication network
US5283638A (en) 1991-04-25 1994-02-01 Compuadd Corporation Multimedia computing and telecommunications workstation
US5192999A (en) 1991-04-25 1993-03-09 Compuadd Corporation Multipurpose computerized television
US5577208A (en) 1991-06-25 1996-11-19 Alcatel Nv "Multimedia" intercommunication between workstations having auxiliary unit directly connected to output of workstation and input to display wherein local and remote image data are combined
US5315586A (en) 1991-06-28 1994-05-24 Nec Corporation Resource reallocation for flow-enforced user traffic
US5606554A (en) 1991-07-15 1997-02-25 Hitachi, Ltd. Teleconference terminal equipment and teleconference module
US5477546A (en) 1991-07-15 1995-12-19 Hitachi, Ltd. Teleconference terminal equipment and teleconference module
US5537548A (en) 1991-08-08 1996-07-16 International Business Machines Corporation Method of computer conferencing by intercepting commands issued by application programs and redirecting to all stations for execution
US5442749A (en) 1991-08-22 1995-08-15 Sun Microsystems, Inc. Network video server system receiving requests from clients for specific formatted data through a default channel and establishing communication through separate control and data channels
US5307351A (en) 1991-08-26 1994-04-26 Universal Data Systems, Inc. Data communication apparatus for adjusting frame length and method of operating same
US5671428A (en) 1991-08-28 1997-09-23 Kabushiki Kaisha Toshiba Collaborative document processing system with version and comment management
US5392344A (en) 1991-10-03 1995-02-21 At&T Corp. Communications network class-of-service routing
US5632022A (en) 1991-11-13 1997-05-20 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Encyclopedia of software components
US5291492A (en) 1991-12-18 1994-03-01 Unifi Communications Corporation Externally controlled call processing system
US5487167A (en) 1991-12-31 1996-01-23 International Business Machines Corporation Personal computer with generalized data streaming apparatus for multimedia devices
US5333299A (en) 1991-12-31 1994-07-26 International Business Machines Corporation Synchronization techniques for multimedia data streams
US5659692A (en) 1992-01-13 1997-08-19 Massachusetts Institute Of Technology Computer method and apparatus for video conferencing
US5502726A (en) 1992-01-31 1996-03-26 Nellcor Incorporated Serial layered medical network
US5276679A (en) 1992-02-12 1994-01-04 U.S. West Advanced Technologies, Inc. Method for maintaining channels and a subscriber station for use in an ISDN system
US5243596A (en) 1992-03-18 1993-09-07 Fischer & Porter Company Network architecture suitable for multicasting and resource locking
US5367637A (en) 1992-03-26 1994-11-22 International Business Machines Corporation Self-tuning virtual storage management for dedicated real-time computer system
US5313454A (en) 1992-04-01 1994-05-17 Stratacom, Inc. Congestion control for cell networks
US5311585A (en) 1992-04-14 1994-05-10 At&T Bell Laboratories Carrier proportioned routing
US5384770A (en) 1992-05-08 1995-01-24 Hayes Microcomputer Products, Inc. Packet assembler
US5623690A (en) 1992-06-03 1997-04-22 Digital Equipment Corporation Audio/video storage and retrieval for multimedia workstations by interleaving audio and video data in data file
US5594859A (en) 1992-06-03 1997-01-14 Digital Equipment Corporation Graphical user interface for video teleconferencing
US5375068A (en) 1992-06-03 1994-12-20 Digital Equipment Corporation Video teleconferencing for networked workstations
US5608653A (en) 1992-06-03 1997-03-04 Digital Equipment Corporation Video teleconferencing for networked workstations
US5309433A (en) 1992-06-18 1994-05-03 International Business Machines Corp. Methods and apparatus for routing packets in packet transmission networks
US5371534A (en) 1992-07-23 1994-12-06 At&T Corp. ISDN-based system for making a video call
US5664126A (en) 1992-07-24 1997-09-02 Kabushiki Kaisha Toshiba Human interface system for communicating networked users
US5422942A (en) 1992-09-14 1995-06-06 Sony Corporation Incoming call transfer terminal
CA2080530A1 (en) 1992-10-14 1994-04-15 Ho Kee Chiu Dynamic networking
US5557749A (en) 1992-10-15 1996-09-17 Intel Corporation System for automatically compressing and decompressing data for sender and receiver processes upon determination of a common compression/decompression method understood by both sender and receiver processes
US5422883A (en) 1992-10-16 1995-06-06 International Business Machines Corporation Call setup and channel allocation for a multi-media network bus
US5649105A (en) 1992-11-10 1997-07-15 Ibm Corp. Collaborative working in a network
US5440624A (en) 1992-11-10 1995-08-08 Netmedia, Inc. Method and apparatus for providing adaptive administration and control of an electronic conference
US5289470A (en) 1992-12-14 1994-02-22 International Business Machines Corp. Flexible scheme for buffer space allocation in networking devices
US5373549A (en) 1992-12-23 1994-12-13 At&T Corp. Multi-level conference management and notification
US5515491A (en) 1992-12-31 1996-05-07 International Business Machines Corporation Method and system for managing communications within a collaborative data processing system
US5546395A (en) 1993-01-08 1996-08-13 Multi-Tech Systems, Inc. Dynamic selection of compression rate for a voice compression algorithm in a voice over data modem
US5333135A (en) 1993-02-01 1994-07-26 North American Philips Corporation Identification of a data stream transmitted as a sequence of packets
US5872923A (en) 1993-03-19 1999-02-16 Ncr Corporation Collaborative video conferencing system
US5374952A (en) 1993-06-03 1994-12-20 Target Technologies, Inc. Videoconferencing system
US6104706A (en) 1993-06-09 2000-08-15 Intelligence-At-Large, Inc. Method and apparatus for multiple media digital communication system
US6738357B1 (en) 1993-06-09 2004-05-18 Btg International Inc. Method and apparatus for multiple media digital communication system
US5623490A (en) 1993-06-09 1997-04-22 Intelligence-At-Large Method and apparatus for multiple media digital communication system
US7050425B2 (en) 1993-06-09 2006-05-23 Btg International Inc. Apparatus for multiple media digital communication
US5995491A (en) 1993-06-09 1999-11-30 Intelligence At Large, Inc. Method and apparatus for multiple media digital communication system
US7075924B2 (en) 1993-06-09 2006-07-11 Btg International Inc. Methods for multiple media digital communication
US5530902A (en) 1993-06-14 1996-06-25 Motorola, Inc. Data packet switching system having DMA controller, service arbiter, buffer type managers, and buffer managers for managing data transfer to provide less processor intervention
US5754306A (en) 1993-06-15 1998-05-19 Hewlett-Packard Company System and method for a communication system
US5509010A (en) 1993-06-25 1996-04-16 At&T Corp. Communications signaling protocols
US5511168A (en) 1993-07-01 1996-04-23 Digital Equipment Corporation Virtual circuit manager for multicast messaging
US5612788A (en) 1993-07-30 1997-03-18 Sony Corporation Video data compression apparatus for recording and reproducing compressed video data at their various compressed data rates
US5572232A (en) 1993-08-06 1996-11-05 Intel Corporation Method and apparatus for displaying an image using subsystem interrogation
US5475746A (en) 1993-09-22 1995-12-12 At&T Corp. Method for permitting subscribers to change call features in real time
US5491798A (en) 1993-09-25 1996-02-13 International Business Machines Corporation Method for network call management
US5444709A (en) 1993-09-30 1995-08-22 Apple Computer, Inc. Protocol for transporting real time data
US5617539A (en) 1993-10-01 1997-04-01 Vicor, Inc. Multimedia collaboration system with separate data network and A/V network controlled by information transmitting on the data network
US5758079A (en) 1993-10-01 1998-05-26 Vicor, Inc. Call control in video conferencing allowing acceptance and identification of participants in a new incoming call during an active teleconference
US5689641A (en) 1993-10-01 1997-11-18 Vicor, Inc. Multimedia collaboration system arrangement for routing compressed AV signal through a participant site without decompressing the AV signal
US5557724A (en) 1993-10-12 1996-09-17 Intel Corporation User interface, method, and apparatus selecting and playing channels having video, audio, and/or text streams
US5402412A (en) 1993-10-15 1995-03-28 Dsc Communications Corporation System and method for monitoring a stream of events
US5526037A (en) 1993-10-20 1996-06-11 Videoconferencing Systems, Inc. Method for remotely controlling a peripheral device in a videoconferencing system
US5455854A (en) 1993-10-26 1995-10-03 Taligent, Inc. Object-oriented telephony system
US5621894A (en) 1993-11-05 1997-04-15 Microsoft Corporation System and method for exchanging computer data processing capabilites
US5544300A (en) 1993-11-12 1996-08-06 Intel Corporation User interface for dynamically converting between a single top level window and multiple top level windows
US5566000A (en) 1993-11-15 1996-10-15 Qualcomm Incorporated System and method for reducing bottlenecks in low data rate networks processing facsimile data transmission
US5522073A (en) 1993-11-22 1996-05-28 Hewlett-Packard Company Method and apparatus for automating and controlling execution of software tools and tool sets via when/then relationships
US5524110A (en) 1993-11-24 1996-06-04 Intel Corporation Conferencing over multiple transports
US5673393A (en) 1993-11-24 1997-09-30 Intel Corporation Managing bandwidth over a computer network having a management computer that allocates bandwidth to client computers upon request
US5809237A (en) 1993-11-24 1998-09-15 Intel Corporation Registration of computer-based conferencing system
US5600797A (en) 1993-11-24 1997-02-04 Intel Corporation System for identifying new client and allocating bandwidth thereto by monitoring transmission of message received periodically from client computers informing of their current status
US5859979A (en) 1993-11-24 1999-01-12 Intel Corporation System for negotiating conferencing capabilities by selecting a subset of a non-unique set of conferencing capabilities to specify a unique set of conferencing capabilities
US5574934A (en) 1993-11-24 1996-11-12 Intel Corporation Preemptive priority-based transmission of signals using virtual channels
US5490247A (en) 1993-11-24 1996-02-06 Intel Corporation Video subsystem for computer-based conferencing system
US5913062A (en) 1993-11-24 1999-06-15 Intel Corporation Conference system having an audio manager using local and remote audio stream state machines for providing audio control functions during a conference session
US5506954A (en) 1993-11-24 1996-04-09 Intel Corporation PC-based conferencing system
US5754765A (en) 1993-11-24 1998-05-19 Intel Corporation Automatic transport detection by attempting to establish communication session using list of possible transports and corresponding media dependent modules
US5473679A (en) 1993-12-09 1995-12-05 At&T Corp. Signaling system for broadband communications networks
US5530808A (en) 1993-12-10 1996-06-25 International Business Machines Corporation System for transferring ownership of transmitted data packet from source node to destination node upon reception of echo packet at source node from destination node
US5729687A (en) 1993-12-20 1998-03-17 Intel Corporation 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
US5532937A (en) 1994-01-31 1996-07-02 International Business Machines Corporation Switching of multiple multimedia data streams
US5459725A (en) 1994-03-22 1995-10-17 International Business Machines Corporation Reliable multicasting over spanning trees in packet communications networks
US5799151A (en) 1994-04-04 1998-08-25 Hoffer; Steven M. Interactive electronic trade network and user interface
US5434860A (en) 1994-04-20 1995-07-18 Apple Computer, Inc. Flow control for real-time data streams
US5453780A (en) 1994-04-28 1995-09-26 Bell Communications Research, Inc. Continous presence video signal combiner
GB2289149A (en) 1994-05-02 1995-11-08 Ubique Ltd Data retrieval system providing co-presence
US5550754A (en) 1994-05-13 1996-08-27 Videoptic Research Teleconferencing camcorder
US5587928A (en) 1994-05-13 1996-12-24 Vivo Software, Inc. Computer teleconferencing method and apparatus
US5506844A (en) 1994-05-20 1996-04-09 Compression Labs, Inc. Method for configuring a statistical multiplexer to dynamically allocate communication channel bandwidth
US5483587A (en) 1994-06-08 1996-01-09 Linkusa Corporation System and method for call conferencing
US5903754A (en) 1994-06-21 1999-05-11 Microsoft Corporation Dynamic layered protocol stack
US5652887A (en) 1994-06-22 1997-07-29 International Business Machines Corporation Dynamic Meta commands for peripheral devices
US5455826A (en) 1994-06-28 1995-10-03 Oezveren; Cueneyt M. Method and apparatus for rate based flow control
US5625407A (en) 1994-07-08 1997-04-29 Lucent Technologies Inc. Seamless multimedia conferencing system using an enhanced multipoint control unit and enhanced endpoint devices
US5541927A (en) 1994-08-24 1996-07-30 At&T Corp. Method of multicasting
US5664226A (en) 1994-09-08 1997-09-02 International Business Machines Corporation System for merging plurality of atomic data elements into single synchronized file by assigning ouput rate to each channel in response to presentation time duration
US5724578A (en) 1994-12-07 1998-03-03 Fujitsu Limited File managing system for managing files shared with a plurality of users
US6008806A (en) 1994-12-13 1999-12-28 Microsoft Corporation Shell extensions for an operating system
US5627978A (en) 1994-12-16 1997-05-06 Lucent Technologies Inc. Graphical user interface for multimedia call set-up and call handling in a virtual conference on a desktop computer conferencing system
US5483588A (en) 1994-12-23 1996-01-09 Latitute Communications Voice processing interface for a teleconference system
US5742670A (en) 1995-01-09 1998-04-21 Ncr Corporation Passive telephone monitor to control collaborative systems
US5600646A (en) 1995-01-27 1997-02-04 Videoserver, Inc. Video teleconferencing system with digital transcoding
US5887170A (en) 1995-02-13 1999-03-23 International Business Machines Corporation System for classifying and sending selective requests to different participants of a collaborative application thereby allowing concurrent execution of collaborative and non-collaborative applications
US5572582A (en) 1995-02-24 1996-11-05 Apple Computer, Inc. Method and apparatus for establishing communication between two teleconferencing endpoints
EP1816786A2 (en) 1995-02-24 2007-08-08 Apple Computer, Inc. Identifying application capabilities for teleconference connections
US5973724A (en) 1995-02-24 1999-10-26 Apple Computer, Inc. Merging multiple teleconferences
US5664164A (en) 1995-02-24 1997-09-02 Apple Computer, Inc. Synchronization of one or more data streams
US5999977A (en) 1995-02-24 1999-12-07 Apple Computer, Inc. System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgment message to first endpont
US5854898A (en) 1995-02-24 1998-12-29 Apple Computer, Inc. System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween
US5848143A (en) 1995-03-02 1998-12-08 Geotel Communications Corp. Communications system using a central controller to control at least one network and agent system
US5724508A (en) 1995-03-09 1998-03-03 Insoft, Inc. Apparatus for collaborative computing
US5674003A (en) 1995-04-28 1997-10-07 Andersen; David B. Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface
US5623483A (en) 1995-05-11 1997-04-22 Lucent Technologies Inc. Synchronization system for networked multimedia streams
US5604742A (en) 1995-05-31 1997-02-18 International Business Machines Corporation Communications system and method for efficient management of bandwidth in a FDDI station
US5907324A (en) 1995-06-07 1999-05-25 Intel Corporation Method for saving and accessing desktop conference characteristics with a persistent conference object
US5841763A (en) 1995-06-13 1998-11-24 Multilink, Inc. Audio-video conferencing system
US5710591A (en) 1995-06-27 1998-01-20 At&T Method and apparatus for recording and indexing an audio and multimedia conference
US5737599A (en) 1995-09-25 1998-04-07 Rowe; Edward R. Method and apparatus for downloading multi-page electronic documents with hint information
US5717863A (en) 1995-09-27 1998-02-10 Intel Corporation Method and apparatus for managing pc conference connection addresses
US5760769A (en) 1995-12-22 1998-06-02 Intel Corporation Apparatus and method for identifying a shared application program in a computer during teleconferencing
US5793365A (en) 1996-01-02 1998-08-11 Sun Microsystems, Inc. System and method providing a computer user interface enabling access to distributed workgroup members
US5801700A (en) 1996-01-19 1998-09-01 Silicon Graphics Incorporated System and method for an iconic drag and drop interface for electronic file transfer
US5721729A (en) 1996-01-24 1998-02-24 Klingman; Edwin E. Universal input call processing system
US5764915A (en) 1996-03-08 1998-06-09 International Business Machines Corporation Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack
US5841976A (en) 1996-03-29 1998-11-24 Intel Corporation Method and apparatus for supporting multipoint communications in a protocol-independent manner
US5933597A (en) 1996-04-04 1999-08-03 Vtel Corporation Method and system for sharing objects between local and remote terminals
US5742773A (en) 1996-04-18 1998-04-21 Microsoft Corporation Method and system for audio compression negotiation for multiple channels
US20040210638A1 (en) 1996-05-08 2004-10-21 Guy Riddle Method and apparatus for listening for incoming calls on multiple port/socket combinations
US6505234B1 (en) 1996-05-08 2003-01-07 Apple Computer, Inc. Method and apparatus for listening for incoming calls on multiple port/socket combinations
US5931961A (en) 1996-05-08 1999-08-03 Apple Computer, Inc. Discovery of acceptable packet size using ICMP echo
US6189034B1 (en) 1996-05-08 2001-02-13 Apple Computer, Inc. Method and apparatus for dynamic launching of a teleconferencing application upon receipt of a call
US5857189A (en) 1996-05-08 1999-01-05 Apple Computer, Inc. File sharing in a teleconference application
US6295549B1 (en) 1996-05-08 2001-09-25 Apple Computer, Inc. Method and apparatus for listening for incoming calls on multiple port/socket combinations
US20060271628A1 (en) 1996-05-08 2006-11-30 Guy Riddle Accessories for teleconference component
US20040153510A1 (en) 1996-05-08 2004-08-05 Guy Riddle Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
US7167897B2 (en) 1996-05-08 2007-01-23 Apple Computer, Inc. Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
US6745228B2 (en) 1996-05-08 2004-06-01 Apple Computer, Inc. Method and apparatus for listening for incoming calls on multiple port/socket combinations
US20030135551A1 (en) 1996-05-08 2003-07-17 Guy Riddle Method and apparatus for listening for incoming calls on multiple port/socket combinations
US5864678A (en) 1996-05-08 1999-01-26 Apple Computer, Inc. System for detecting and reporting data flow imbalance between computers using grab rate outflow rate arrival rate and play rate
US5708697A (en) 1996-06-27 1998-01-13 Mci Communications Corporation Communication network call traffic manager
USRE39135E1 (en) 1996-07-01 2006-06-13 Apple Computer, Inc. Method and apparatus for allocating bandwidth in teleconferencing applications using bandwidth control
US5983261A (en) 1996-07-01 1999-11-09 Apple Computer, Inc. Method and apparatus for allocating bandwidth in teleconferencing applications using bandwidth control
US5920732A (en) 1996-07-01 1999-07-06 Apple Computer, Inc. System for preallocating additional larger buffer sizes in accordance with packet sizes of discarded packets that can't be stored in existing preallocated buffer sizes
US6175856B1 (en) 1996-09-30 2001-01-16 Apple Computer, Inc. Method and apparatus for dynamic selection of compression processing during teleconference call initiation
US6151619A (en) 1996-11-26 2000-11-21 Apple Computer, Inc. Method and apparatus for maintaining configuration information of a teleconference and identification of endpoint during teleconference
US20020029350A1 (en) 2000-02-11 2002-03-07 Cooper Robin Ross Web based human services conferencing network
US20020073150A1 (en) 2000-10-17 2002-06-13 Lawrence Wilcock Associating parties with communication sessions
US20020076025A1 (en) 2000-12-18 2002-06-20 Nortel Networks Limited And Bell Canada Method and system for automatic handling of invitations to join communications sessions in a virtual team environment
US7039019B2 (en) 2001-03-27 2006-05-02 Kabushiki Kaisha Toshiba Telephone exchanging apparatus and telephone system
EP1670197A2 (en) 2003-01-20 2006-06-14 Avaya Technology Corp. Messaging advice in presence-aware networks
WO2005104466A1 (en) 2004-04-21 2005-11-03 Koninklijke Philips Electronics, N.V. System and method for chat load management in a network chat environment

Non-Patent Citations (95)

* Cited by examiner, † Cited by third party
Title
"Adaptive Audio Playout Algorithm for Shared Packet Networks," IBM Technical Disclosure Bulletin, Apr. 1993, pp. 255-257, vol. 36, No. 4, Armonk, NY.
"Apple Media Conference Guide," Apple Computer, Inc., screen shots, 14 pages.
"Apple QuickTime Conferencing Kit," Apple Computer, Inc., Aug. 1995, 2 pages.
"Apple QuickTime Conferencing," Apple Computer, Inc., Apple QuickTime Fact Sheet, Jan. 1995, 2 pages.
"Control of Video Telephony from a Data Conferencing System," IBM Technical Disclosure Bulletin, v. 37, Oct. 1994, pp. 327-332.
"Draft ITU-T Recommendation H.245, Line Transmission of Non-Telephone Signals; Control Protocol for Multimedia Communication," International Telecommunication Union, Nov. 27, 1995, pp. 1-189.
"Dynamic Conference Call Participation" IBM Technical Disclosure Bulletin, V. 28, Aug. 1995, pp. 1135-1138.
"Intelligent Packet Relay in Distributed Multimedia Systems," IBM Technical Disclosure Bulletin, v. 37, Jul. 1994, pp. 211-214.
"OSF/Motif Programmer's Guide, Revision 1.1," Open Software Foundation, 1990, 1991, pp. i-xviii, 1-1-1-9, GL-1-GL-15, Index-1-Index-34, Prentice-Hall, Inc., Englewood Cliffs, NJ.
"Output Throttle Mechanism," IBM Technical Disclosure Bulletin, Apr. 1990, pp. 274-279, vol. 32, No. 11.
"ULTRIX Worksystem Software X Window System Protocol: X Version 11," ULTRIX Worksystem Software, Version 2.0, Digital Equipment Corporation, 1988, Order No. AA-MA98A-TE.
Aguilar, L., et al., "Architecture for a Multimedia Teleconferencing System," Proceedings of ACM SIGCOMM'86, Aug. 1986, pp. 126-136.
Ahuja, S. R., et al., "The Rapport Multimedia Conferencing System," Proceedings of Conference on Office Information Systems, Mar. 1988, pp. 1-8.
Baker, S., "Remote-Access Protocols," UNIX Review, May 1995, pp. 1-4.
Barberis, G., et al., "Coded Speech in Packet-Switched Networks: Models and Experiments," IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1028-1038, vol. SAC-1, No. 6.
Bubenik, R., et al., "Multipoint Connection Management in High Speed Networks," IEEE INFOCOM '91, pp. 59-67 (1991).
Burton, J., "Standard Issue," Byte, Sep. 1995, pp. 1-10.
C. Kim et al., "Performance of Call Splitting Algorithms for Multicast Traffic," INFOCOM '90, pp. 348-356 (1990).
Carne, E. B., "Modern Telecommunication," Applications of Communications Theory, GTE Laboratories Incorporated, 1984, pp. 44-47.
Casner, S., et al., "First IETF Internet Audiocast," Reprinted from ACM SIGCOMM Computer Communications Review, Jul. 1992, vol. 22, No. 3, ISI Reprint Series, ISI/RS-92-293, Jul. 1992, pp. 1-6.
Casner, S., et al., "N-Way Conferencing with Packet Video," Reprinted from the Proceedings of the Third International Workshop on Packet Video held Mar. 22-23, 1990 in Morristown, NJ, ISI Reprint Series, ISI/RS-90-252, Apr. 1990, pp. 1-6.
Chong-Kwon, K., et al., "Performance of Call Splitting Algorithms for Multicast Traffic," INFOCOM 1990, pp. 348-356.
Cohen, D., "Specifications for the Network Voice Protocol (NVP)," NWG/RFC 741, Nov. 1977.
Cohen, D., "Specifications for the Network Voice Protocol," USC/Information Sciences Institute, Mar. 1976, ISI/RR-75-39, Available from DTIC (AD # A023506).
Comer, D., "Internetworking with TCP/IP, vol. 1: Principles, Protocols, and Architecture," 2nd Edition, 1991, pp. 1-8, 337-346, 505, Prentice Hall, Englewood Cliffs, NJ.
Deering, S., "Host Extensions for IP Multicasting," RFC 1112, Internet Engineering Task Force, Aug. 1989.
Degan, J. J., et al., "Fast Packet Technology for Future Switches," AT&T Technical Journal, Mar./Apr. 1989, pp. 36-50, vol. 68, No. 2.
Donath, J., et al., "The Sociable Web," Proceedings of Second International WWW Conference, 1994, 7 pages, [Online] [Retrieved on Feb. 2, 2008] Retrieved from the internet .
Donath, J., et al., "The Sociable Web," Proceedings of Second International WWW Conference, 1994, 7 pages, [Online] [Retrieved on Feb. 2, 2008] Retrieved from the internet <URL: http://www.nicoladoering.de/Hogrefe/donath.htm>.
Eng, K. Y., et al., "Multicast and Broadcast Services in a Knockout Packet Switch," Proceedings of the IEEE INFOCOM'88, pp. 29-34.
European Search Report and Search Opinion, European Patent Application No. EP 07009590.6, Jul. 24, 2007.
European Search Report and Search Opinion, European Patent Application No. EP 07009591.4, Jul. 17, 2007.
European Search Report and Search Opinion, European Patent Application No. EP 07009592.2, Jul. 18, 2007.
European Search Report for European Patent Application No. EP 09000330.2, Sep. 13, 2010, 7 pages.
Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, Internet Engineering Task Force, Nov. 1997.
Finnegan, J., "Building Windows NT-Based Client/Server Applications Using Remote Procedure Calls," Microsoft Systems Journal, Oct. 1994, pp. 1-17.
Forsdick, H., "Explorations into Real-Time Multimedia Conferencing," Proceedings of the 2nd International Symposium on Computer Message Systems, IFIP, Sep. 1985, pp. 331-347.
Gemmell, J. et al., "An Architecture for Multicast Telepresentations," Journal of Computing and Information Technology-CIT, pp. 255-272, vol. 6, No. 3.
Gemmell, J., et al., "A Scalable Multicast Architecture for One-to-Many Telepresentations," Multimedia Computing and Systems, Proceedings, IEEE International Conference, 1998, pp. 128-139.
Ghafoor, A., et al., "An Efficient Communication Structure for Distributed Commit Protocols," IEEE Journal on Selected Areas in Communications, Apr. 1989, pp. 375-389, vol. 7, No. 3.
Handley, M., et al., "The Conference Control Channel Protocol (CCCP): A scalable base for building conference control applications," ACM, SIGCOMM, 1995, pp. 275-287.
Hoberecht, W. L., "A Layered Network Protocol for Packet Voice and Data Integration," IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1006-1013, vol. SAC-1, No. 6.
J. Ott et al., "Multicasting the ITU MCS: Integrating Point-to-Point abd Multicast Transport" Singapore ICCS, pp. 1013-1017 (1994).
Jamsa, K., et al., "Internet Programming," Jan. 1995, pp. 152-218.
Kalman, S., "CTI Systems: Now's the Time," Network VAR, Aug. 1995, pp. 1-5.
Lantz, K. A., "An Experiment in Integrated Multimedia Conferencing," Proceedings of the Conference on Computer-Supported Cooperative Work'86, Dec. 1986, pp. 533-552, Reading 19.
Le Boudec, J., "The Asynchronous Transfer Mode: A Tutorial," Computer Networks and ISDN Systems, May 15, 1992, pp. 279-309, vol. 24, No. 4.
Lee, T. T., et al., "The Architecture of a Multicast Broadband Packet Switch," Proceedings of IEEE INFOCOM'88, pp. 1-8.
Leung, W. F., et al., "A Software Architecture for Workstations Supporting Multimedia Conferencing in Packet Switching Networks," IEEE Journal on Selected Areas in Communications, Apr. 1990, pp. 380-390, vol. 8, No. 3.
Leung, W. H., et al., "A Set of Operating System Mechanisms to Support Multi-Media Applications," Proceedings of 1988 International Zurich Seminar on Digital Communications, Mar. 1988, pp. B4.1-B4.6.
Levendel, Y., "Software Assembly Workbench: How to Construct Software Like Hardware," IEEE, Feb. 1995, pp. 4-12.
Maeno, K., et al., "Distributed Desktop Conferencing System (Mermaid) Based on Group Communication Architecture," ICC '91, Jun. 28, 1991, pp. 0520-0525.
Magill, D. T., "Adaptive Speech Compression for Packet Communication Systems," Conference Record of the IEEE National Telecommunications Conference, 1973, pp. 29D-1-29-D5.
Mark, J. W., et al., "A Dual-Ring LAN for Integrated Voice/Video/Data Services," Department of Electrical and Computer Engineering and Computer Communications Networks Group, IEEE, 1990, pp. 850-857, University of Waterloo, Waterloo, Ontario, Canada.
Mello, J. P., Jr., "Telephony's Killer App?," Byte, Sep. 1995, pp. 1-7.
Minzer, S. E., et al., "New Directions in Signaling for Broadband ISDN," IEEE Communications Magazine, Feb. 1989, pp. 6-14.
Mon-Song Chen, et al., "Designing a Distributed Collaborative Environment," Communication for Global Users, including a Communications Theory Mini Conference, Orlando, Dec. 6-9, 1992, Institute of Electrical and Electronics Engineers, pp. 219-219.
Montgomery, W. A., "Techniques for Packet Voice Synchronization," IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1022-1028, vol. SAC-1, No. 6.
Musser, J. M., et al., "A Local Area Network as a Telephone Local Subscriber Loop," IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1046-1054, vol. SAC-1, No. 6.
Nicolaou, C., "An Architecture for Real-Time Multimedia Communication Systems," IEEE Journal on Selected Areas in Communications, Apr. 1990, pp. 391-400, vol. 8, No. 3.
Nojima, S., et al., "High Speed Packet Switching Network for Multi-Media Information," Proceedings of IEEE 1986 Computer Networking Symposium, pp. 141-150.
Office Action for U.S. Appl. No. 10/857,806, Jul. 27, 2009, 22 Pages.
Office Action for U.S. Appl. No. 12/210,847, May 12, 2010, 4 Pages.
Office Action for U.S. Appl. No. 12/210,847, Sep. 21, 2010, 7 Pages.
Office Action received for U.S. Appl. No. 12/210,847, Dec. 30, 2009, 5 Pages.
Oikarinen, J., et al., "Request for Comments: 1459: Internet Relay Chat Protocol," Internet Engineering Task Force, Network Working Group, May 1993, 65 pages.
Ott, J., et al., "Multicasting the ITU MCS: Integrating Point-to-Point & Multicast Transport," Singapore ICCS, 1994, pp. 1013-1017.
Palmer, L., et al., "Desktop Meeting," LAN Magazine, Nov. 1991, pp. 111-121, vol. 6, No. 11.
PCT International Search Report (PCT/US96/02459) Aug. 7, 1996.
Poggio, A., et al., "CCWS: A Computer-Based, Multimedia Information System," Computer, Oct. 1985, pp. 92-103.
Schooler, E. M., "A Distributed Architecture for Multimedia Conference Control," ISI Research Report, Nov. 1991, ISI/RR-91-289, 20 pages, University of Southern California, Information Sciences Institute.
Schooler, E. M., "Case Study: Multimedia Conference Control in a Packet-Switched Teleconferencing System," Reprinted from the Journal of Intemetworking: Research and Experience, Jun. 1993, pp. 99-120, vol. 4, No. 2, ISI Reprint Series, ISI/RS-93-359, Aug. 1993, pp. 1-17.
Schooler, E. M., "Conferencing and Collaborative Computing," Multimedia Systems, 1996, pp. 210-225, vol. 4.
Schooler, E. M., "The Connection Control Protocol: Architecture Overview," USC/Information Sciences Institute, Version 1.0, Jan. 28, 1992, pp. 1-6.
Schooler, E. M., "The Connection Control Protocol: Specification," USC/Information Sciences Institute, Version 1.1, Jan. 29, 1992, pp. 1-6.
Schooler, E. M., et al., "A Packet-Switched Multimedia Conferencing System," Reprinted from ACM SIGOIS Bulletin, Jan. 1989, pp. 12-22, vol. 1, No. 1, University of Southern Califomia, Information Sciences Institute.
Schooler, E. M., et al., "An Architecture for Multimedia Connection Management," Reprinted from the Proceedings of the IEEE 4th Comsoc International Workshop on Multimedia Communications, MM '92, Apr. 1992, pp. 271-274, Monterey, CA, ISI Reprint Series, ISI/RS-92-294, Aug. 1992, pp. 1-4.
Schooler, E. M., et al., "Multimedia Conferencing: Has it come of age?," IEEE Journal on Selected Areas in Communications, 1991, pp. 707-716.
Schulzrinne, H., "A Transport Protocol for Real-Time Applications," Audio-Video Transport WG, Internet Engineering Task Force, Internet Draft, draft-ietf-avt-rtp-00, Dec. 15, 1992, pp. 1-12.
Schulzrinne, H., et al. "A Transport Protocol for Real-Time Applications," Audio-Video Transport WG, Internet Engineering Task Force, Internet Draft, draft-ietf-avt-rtp-01, May 6, 1993, pp. 1-18.
Shenker, S., et al., "Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism," Lecture Notes in Computer Science, 1994, vol. 882, 69.
Shinjo, Y., et al., "Object-Stacking in the World-Wide Web," Fourth International Workshop on Object-Orientation in Operating Systems, IEEE, Aug. 1995, pp. 210-219.
Shinjo, Y., et al., "Object-Stacking Model for Structuring Object-Based Systems," International Workshop on Object-Orientation in Operating Systems, I-WOOOS '02, Sep. 1992, Paris, France, pp. 328-340.
Turner, J. S., "Design of a Broadcast Packet Switching Network," IEEE Transactions on Communications, Jun. 1988, pp. 734-743, vol. 36, No. 6.
U.S. Appl. No. 10/020,515, filed Dec. 7, 2001, Riddle.
U.S. Appl. No. 10/857,798, filed May 28, 2004, Riddle.
U.S. Appl. No. 10/857,799, filed May 28, 2004, Riddle.
U.S. Appl. No. 10/857,805, filed May 28, 2004, Riddle.
U.S. Appl. No. 10/857,806, filed May 28, 2004, Riddle.
Ueda, H., et al., "Evaluation of an Experimental Packetized Speech and Data Transmission System," IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1039-1045, vol. SAC-1, No. 6.
W.H. Leung, et al., "Multimedia Conferencing Capabilities in an Experimental Fast Packet Network," Proceedings of the International Switching Symposium, Yokohama, Oct. 25, 1992, Institute of Electronics, Information and Communication Engineers, pp. 258-262.
Watabe, K., et al., "Distributed Desktop Conferencing System with Multiuser Multimedia Interface," IEEE Journal on Selected Areas in Communications, May 1991, pp. 531-539, vol. 9, No. 4.
Weinstein, C. J., et al., "Experience with Speech Communication in Packet Networks," IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 963-980, vol. SAC-1, No. 6.
Wong, W., "Welcome to Teleconferencing," Stacks, Jun. 1995, pp. 1-7.
Yukimatsu, K., et al., "Multicast Communication Facilities in a High Speed Packet Switching Network," Proceedings of ICCC'86, pp. 276-281.

Also Published As

Publication number Publication date
USRE40704E1 (en) 2009-04-28
US5854898A (en) 1998-12-29
USRE42442E1 (en) 2011-06-07
US5999977A (en) 1999-12-07
USRE44306E1 (en) 2013-06-18
USRE44441E1 (en) 2013-08-13

Similar Documents

Publication Publication Date Title
USRE44395E1 (en) System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
US5973724A (en) Merging multiple teleconferences
EP0811283B1 (en) Identifying application capabilities for teleconference connections
US9537667B2 (en) Duplicating digital streams for digital conferencing using switching technologies
US9356976B2 (en) Real-time communications methods providing pause and resume and related devices
US8767733B2 (en) Method and apparatus for establishing multicast groups
US6175856B1 (en) Method and apparatus for dynamic selection of compression processing during teleconference call initiation
US7167897B2 (en) Accessories providing a telephone conference application one or more capabilities independent of the teleconference application
US6509925B1 (en) Conferencing system
US7894377B2 (en) Method and system for group communications
US7801134B2 (en) VoIP system, VoIP server and client, and multicast packet communication method
US20080005246A1 (en) Multipoint processing unit
US20030005054A1 (en) Distributed multipoint conferencing
JP5579660B2 (en) Multipoint video conferencing equipment
JPH11112957A (en) Electronic conference system

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY