|Publication number||USRE40704 E1|
|Application number||US 10/857,798|
|Publication date||Apr 28, 2009|
|Filing date||May 28, 2004|
|Priority date||Feb 24, 1995|
|Also published as||US5854898, US5999977, USRE42442, USRE44306, USRE44395, USRE44441|
|Publication number||10857798, 857798, US RE40704 E1, US RE40704E1, US-E1-RE40704, USRE40704 E1, USRE40704E1|
|Inventors||Guy G. Riddle|
|Original Assignee||Apple Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (103), Non-Patent Citations (86), Referenced by (1), Classifications (29), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
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 (the present application), 10/857,799, 10/857,805, and 10/857,806.
This is a continuation application of U.S. Reissue Application No. 10/020,515, filed Dec. 7, 2001, 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.
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 where as a second system may employ an earlier generation processor, operate at a substanilly 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 participant 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 aslo 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.
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 transmission 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 acknowledgement 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.
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 acknowledgment. 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 endpoint 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 embodiment, the acknowledgment message includes a reasons 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.
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:
The present invention relates to networking systems, more specifically, the present invention describes a massaging 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 communication 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 vide 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
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 complied, linked, and then urn 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.
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 vide 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.
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
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:
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
The “joiner” mode flag indicates that all conference members are allowed to interact. This could 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 involve an API call “Listen for Call” (e.g. MTConferenceListen) which implements steps 708 and 710. At step 708, using the underling 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, alters 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 send 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.
As shown in
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 mutlipoint 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
Field Size Value type 1302 2 bytes ‘K’ delimiter 1304 1 byte newline capabilitiesList 1306 0-n bytes (alphanumeric) terminator 1308 1 byte NULL
The Capabilities message 1300 shown in
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
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. 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
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
The Call message 1500 shown in
The response message 1600 of
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
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
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
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 Join message 1800 allows a member to add an auxiliary data source to an exiting conference or to merge two existing conferences. The caller sends this message to members of the conference in response to a merger or join request instead of a call message.
The Merge message 1900 of
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
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 contracted by each new member.
A capabilities list such as shown in
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
Conference identifiers such as 2200 shown in
Field Size Value UniqueID 2202 1-n bytes (numeric) separator 2204 1 byte space name 2206 1-n bytes (alphanumeric)
A member list such as 1812 of
The Terminate message 2300 of
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
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
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 receipt 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.
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 are initiated using a “Merge” message (e.g., 1900 of
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.
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
An example session using the protocols described above is shown in
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 is 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 enables. 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 exiting connections. It will be appreciated that though the foregoing has been described especially with reference to
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3584142||Dec 13, 1968||Jun 8, 1971||Bell Telephone Labor Inc||Interactive computer graphics using video telephone|
|US4100377||Apr 28, 1977||Jul 11, 1978||Bell Telephone Laboratories, Incorporated||Packet transmission of speech|
|US4387271||Nov 18, 1980||Jun 7, 1983||Cselt Centro Studi E Laboratori Telecomunicazioni S.P.A.||Combined telephone and data-transfer system|
|US4506358||Jun 25, 1982||Mar 19, 1985||At&T Bell Laboratories||Time stamping for a packet switching system|
|US4507781||Sep 16, 1983||Mar 26, 1985||Ibm Corporation||Time domain multiple access broadcasting, multipoint, and conferencing communication apparatus and method|
|US4509167||Aug 5, 1983||Apr 2, 1985||At&T Bell Laboratories||Data conference arrangement|
|US4516156||Mar 15, 1982||May 7, 1985||Satellite Business Systems||Teleconferencing method and system|
|US4525779||Mar 30, 1983||Jun 25, 1985||Reuters Ltd.||Conversational video system|
|US4574374||Oct 25, 1983||Mar 4, 1986||At&T Bell Laboratories||Multilocation video conference terminal including rapid video switching|
|US4627052||Mar 11, 1985||Dec 2, 1986||International Computers Limited||Interconnection of communications networks|
|US4645872||May 6, 1986||Feb 24, 1987||John Hopkins University||Videophone network system|
|US4650929||Feb 28, 1985||Mar 17, 1987||Heinrich-Hertz-Institut Fur Nachrichtentechnik Berlin Gmbh||Communication system for videoconferencing|
|US4653090||Dec 16, 1985||Mar 24, 1987||American Telephone & Telegraph (At&T)||Graphics based call management|
|US4686698||Apr 8, 1985||Aug 11, 1987||Datapoint Corporation||Workstation for interfacing with a video conferencing network|
|US4691314||Oct 30, 1985||Sep 1, 1987||Microcom, Inc.||Method and apparatus for transmitting data in adjustable-sized packets|
|US4707831||Oct 23, 1985||Nov 17, 1987||Stc Plc||Packet switching system|
|US4710917||Apr 8, 1985||Dec 1, 1987||Datapoint Corporation||Video conferencing network|
|US4734765||Dec 1, 1978||Mar 29, 1988||Nippon Telegraph & Telephone Public Corp.||Video/audio information transmission system|
|US4748620||Feb 28, 1986||May 31, 1988||American Telephone And Telegraph Company, At&T Bell Laboratories||Time stamp and packet virtual sequence numbering for reconstructing information signals from packets|
|US4756019||Aug 27, 1986||Jul 5, 1988||Edmund Szybicki||Traffic routing and automatic network management system for telecommunication networks|
|US4760572||Dec 23, 1986||Jul 26, 1988||Kabushiki Kaisha Toshiba||Limited multicast communication method and communication network system realizing the method|
|US4763317||Dec 13, 1985||Aug 9, 1988||American Telephone And Telegraph Company, At&T Bell Laboratories||Digital communication network architecture for providing universal information services|
|US4785415||Aug 29, 1986||Nov 15, 1988||Hewlett-Packard Company||Digital data buffer and variable shift register|
|US4827339||Aug 15, 1986||May 2, 1989||Kokusai Denshin Denwa Co., Ltd.||Moving picture signal transmission system|
|US4847829||Nov 25, 1987||Jul 11, 1989||Datapoint Corporation||Video conferencing network|
|US4849811||Jul 6, 1988||Jul 18, 1989||Ben Kleinerman||Simultaneous audio and video transmission with restricted bandwidth|
|US4882743||Aug 1, 1988||Nov 21, 1989||American Telephone And Telegraph||Multi-location video conference system|
|US4888795||Jun 28, 1988||Dec 19, 1989||Nec Corporation||Videotelephone apparatus for transmitting high and low resolution video signals over telephone exchange lines|
|US4893326||May 4, 1987||Jan 9, 1990||Video Telecom Corp.||Video-telephone communications system|
|US4897866||Oct 19, 1988||Jan 30, 1990||American Telephone And Telegraph Company, At&T Bell Laboratories||Telecommunication system with subscriber controlled feature modification|
|US4905231||May 3, 1988||Feb 27, 1990||American Telephone And Telegraph Company, At&T Bell Laboratories||Multi-media virtual circuit|
|US4918718||Jun 28, 1988||Apr 17, 1990||Luma Telecom, Inc.||Quadrature amplitude modulation with line synchronization pulse for video telephone|
|US4924311||Apr 17, 1989||May 8, 1990||Nec Corporation||Dual-mode teleconferencing system|
|US4926415||Feb 4, 1988||May 15, 1990||Kabushiki Kaisha Toshiba||Local area network system for efficiently transferring messages of different sizes|
|US4932047||Sep 2, 1987||Jun 5, 1990||Luma Telecom, Inc.||Conversational video phone|
|US4935953||Apr 27, 1989||Jun 19, 1990||International Business Machines Corporation||Cyclic video region transmission for videoconferencing systems|
|US4937856||Jun 1, 1987||Jun 26, 1990||Natarajan T Raj||Digital voice conferencing bridge|
|US4942470||Jul 5, 1989||Jul 17, 1990||Nec Corporation||Real time processor for video signals|
|US4942540||Mar 2, 1987||Jul 17, 1990||Wang Laboratories, Inc.||Method an apparatus for specification of communication parameters|
|US4942569||Feb 24, 1989||Jul 17, 1990||Kabushiki Kaisha Toshiba||Congestion control method for packet switching apparatus|
|US4943994||Oct 28, 1988||Jul 24, 1990||Luma Telecom Incorporated||Still picture picturephone communications system|
|US4945410||Oct 24, 1988||Jul 31, 1990||Professional Satellite Imaging, Inc.||Satellite communications system for medical related images|
|US4949169||Oct 27, 1989||Aug 14, 1990||International Business Machines Corporation||Audio-video data interface for a high speed communication link in a video-graphics display window environment|
|US4953159||Jan 3, 1989||Aug 28, 1990||American Telephone And Telegraph Company||Audiographics conferencing arrangement|
|US4953196||May 11, 1988||Aug 28, 1990||Ricoh Company, Ltd.||Image transmission system|
|US4962521||Dec 16, 1988||Oct 9, 1990||Mitsubishi Denki Kabushiki Kaisha||Apparatus for still picture video telephone apparatus and methods for transmitting and displaying still picture image for use therein|
|US4965819||Sep 22, 1988||Oct 23, 1990||Docu-Vision, Inc.||Video conferencing system for courtroom and other applications|
|US4991169||Aug 2, 1988||Feb 5, 1991||International Business Machines Corporation||Real-time digital signal processing relative to multiple digital communication channels|
|US4991171||Sep 26, 1989||Feb 5, 1991||At&T Bell Laboratories||Broadcast packet switch network|
|US4995071||May 30, 1989||Feb 19, 1991||Telenorma Telefonbau Und Normalzeit Gmbh||Video conference installation|
|US4999766||Jun 13, 1988||Mar 12, 1991||International Business Machines Corporation||Managing host to workstation file transfer|
|US5003532||May 31, 1990||Mar 26, 1991||Fujitsu Limited||Multi-point conference system|
|US5014267||Apr 6, 1989||May 7, 1991||Datapoint Corporation||Video conferencing network|
|US5020023||Feb 23, 1989||May 28, 1991||International Business Machines Corporation||Automatic vernier synchronization of skewed data streams|
|US5034916||Oct 24, 1988||Jul 23, 1991||Reuters Limited||Fast contact conversational video system|
|US5042006||Feb 27, 1989||Aug 20, 1991||Alcatel N. V.||Method of and circuit arrangement for guiding a user of a communication or data terminal|
|US5042062||Oct 23, 1989||Aug 20, 1991||At&T Bell Laboratories||Method and apparatus for providing real-time switching of high bandwidth transmission channels|
|US5046079||Oct 13, 1989||Sep 3, 1991||Hashimoto Corporation||Telephone answering device with TV telephone|
|US5046080||May 29, 1990||Sep 3, 1991||Electronics And Telecommunications Research Institute||Video codec including pipelined processing elements|
|US5050166||Mar 17, 1988||Sep 17, 1991||Antonio Cantoni||Transfer of messages in a multiplexed system|
|US5056136||Mar 9, 1990||Oct 8, 1991||The United States Of America As Represented By The United States Department Of Energy||Secure video communications system|
|US5062136||Sep 12, 1990||Oct 29, 1991||The United States Of America As Represented By The Secretary Of The Navy||Telecommunications system and method|
|US5072442||Feb 28, 1990||Dec 10, 1991||Harris Corporation||Multiple clock rate teleconferencing network|
|US5077732||Jul 24, 1990||Dec 31, 1991||Datapoint Corporation||LAN with dynamically selectable multiple operational capabilities|
|US5079627||Jun 29, 1989||Jan 7, 1992||Optum Corporation||Videophone|
|US5083269||Jan 8, 1990||Jan 21, 1992||Kabushiki Kaisha Toshiba||Buffer device suitable for asynchronous transfer mode communication|
|US5099510||Jun 11, 1990||Mar 24, 1992||Communications Network Enhancement Inc.||Teleconferencing with bridge partitioning and other features|
|US5101451||Mar 26, 1990||Mar 31, 1992||At&T Bell Laboratories||Real-time network routing|
|US5132966||Mar 23, 1990||Jul 21, 1992||Nec Corporation||Call control with transmission priority in a packet communication network of an atm type|
|US5136581||Jul 2, 1990||Aug 4, 1992||At&T Bell Laboratories||Arrangement for reserving and allocating a plurality of competing demands for an ordered bus communication network|
|US5136692||Jul 24, 1991||Aug 4, 1992||International Business Machines Corporation||Memory disk buffer manager|
|US5140417||Jun 20, 1990||Aug 18, 1992||Matsushita Electric Co., Ltd.||Fast packet transmission system of video data|
|US5140584||Sep 23, 1991||Aug 18, 1992||Kabushiki Kaisha Toshiba||Packet communication system and method of controlling same|
|US5155594||May 10, 1991||Oct 13, 1992||Picturetel Corporation||Hierarchical encoding method and apparatus employing background references for efficiently communicating image sequences|
|US5157662||Feb 12, 1991||Oct 20, 1992||Hitachi, Ltd.||Data communication apparatus having communication-mode changeover function and method of data communication between data communication stations having the same|
|US5163045||Oct 1, 1990||Nov 10, 1992||At&T Bell Laboratories||Communications network arranged to transport connection oriented and connectionless messages|
|US5177604||Jun 3, 1988||Jan 5, 1993||Radio Telcom & Technology, Inc.||Interactive television and data transmission system|
|US5192999||Apr 25, 1991||Mar 9, 1993||Compuadd Corporation||Multipurpose computerized television|
|US5195086||Apr 12, 1990||Mar 16, 1993||At&T Bell Laboratories||Multiple call control method in a multimedia conferencing system|
|US5200951||Jun 30, 1992||Apr 6, 1993||Siemens-Albis Ag||Apparatus and method for transmitting messages between a plurality of subscriber stations|
|US5206934||Aug 15, 1989||Apr 27, 1993||Group Technologies, Inc.||Method and apparatus for interactive computer conferencing|
|US5210836||Oct 13, 1989||May 11, 1993||Texas Instruments Incorporated||Instruction generator architecture for a video signal processor controller|
|US5220653||Oct 26, 1990||Jun 15, 1993||International Business Machines Corporation||Scheduling input/output operations in multitasking systems|
|US5231492||Mar 16, 1990||Jul 27, 1993||Fujitsu Limited||Video and audio multiplex transmission system|
|US5241625||Nov 27, 1990||Aug 31, 1993||Farallon Computing, Inc.||Screen image sharing among heterogeneous computers|
|US5243596||Mar 18, 1992||Sep 7, 1993||Fischer & Porter Company||Network architecture suitable for multicasting and resource locking|
|US5247626||May 29, 1990||Sep 21, 1993||Advanced Micro Devices, Inc.||Fddi controller having flexible buffer management|
|US5253251||Jan 8, 1992||Oct 12, 1993||Nec Corporation||Switching system with time-stamped packet distribution input stage and packet sequencing output stage|
|US5276679||Feb 12, 1992||Jan 4, 1994||U.S. West Advanced Technologies, Inc.||Method for maintaining channels and a subscriber station for use in an ISDN system|
|US5283638||Apr 25, 1991||Feb 1, 1994||Compuadd Corporation||Multimedia computing and telecommunications workstation|
|US5289470||Dec 14, 1992||Feb 22, 1994||International Business Machines Corp.||Flexible scheme for buffer space allocation in networking devices|
|US5291492||Dec 18, 1991||Mar 1, 1994||Unifi Communications Corporation||Externally controlled call processing system|
|US5297143||Dec 3, 1990||Mar 22, 1994||Echelon Systems, Corp.||Network communication protocol including a reliable multicasting technique|
|US5307351||Aug 26, 1991||Apr 26, 1994||Universal Data Systems, Inc.||Data communication apparatus for adjusting frame length and method of operating same|
|US5309433||Jun 18, 1992||May 3, 1994||International Business Machines Corp.||Methods and apparatus for routing packets in packet transmission networks|
|US5311585||Apr 14, 1992||May 10, 1994||At&T Bell Laboratories||Carrier proportioned routing|
|US5313454||Apr 1, 1992||May 17, 1994||Stratacom, Inc.||Congestion control for cell networks|
|US5313455||Oct 14, 1992||May 17, 1994||Koninklijke Ptt Nederland N.V.||Transmission system with recording of untransmitted packets|
|US5315586||Jun 29, 1992||May 24, 1994||Nec Corporation||Resource reallocation for flow-enforced user traffic|
|US5729687 *||Dec 20, 1993||Mar 17, 1998||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|
|US20020029350 *||Feb 12, 2001||Mar 7, 2002||Cooper Robin Ross||Web based human services conferencing network|
|US20020073150 *||Oct 16, 2001||Jun 13, 2002||Lawrence Wilcock||Associating parties with communication sessions|
|US20020076025 *||Dec 18, 2000||Jun 20, 2002||Nortel Networks Limited And Bell Canada||Method and system for automatic handling of invitations to join communications sessions in a virtual team environment|
|1||"Adaptive Audio Playout Algorithm for Shared Networks," IBM Technical Disclosure Bulletin, Apr. 1993, pp. 255-257, vol. 36, No. 4, Armonk, NY.|
|2||"Apple Media Conference Guide," Apple Computer, Inc., screen shots, 14 pages.|
|3||"Apple QuickTime Conferencing Kit," Apple Computer, Inc., Aug. 1995, 2 pages.|
|4||"Apple QuickTime Conferencing," Apple Computer, Inc., Apple QuickTime Fact Sheet, Jan. 1995, 2 pages.|
|5||"Control of Video Telephony from a Data Conferencing System," IBM Technical Disclosure Bulletin, v. 37, Oct. 1994, pp. 327-332.|
|6||"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.|
|7||"Dynamic Conference Call Participation" IBM Technical Disclosure Bulletin, V. 28, Aug. 1995, pp. 1135-1138.|
|8||"Intelligent Packet Relay in Distributed Multimedia Systems," IBM Technical Disclosure Bulletin, v. 37, Jul. 1994, pp. 211-214.|
|9||"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.|
|10||"Output Throttle Mechanism," IBM Technical Disclosure Bulletin, Apr. 1990, pp. 274-279, vol. 32, No. 11.|
|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.|
|12||Aguilar, L., et al., "Architecture for a Multimedia Teleconferencing System," Proceedings of ACM Sigcomm'86, Aug. 1988, pp. 126-136.|
|13||Ahuja, S. R., et al., "The Rapport Multimedia System," Proceedings of Conference on Office Information Systems, Mar. 1988, pp. 1-8.|
|14||Baker, S., "Remote-Access Protocols," UNIX Review, May 1995, pp. 1-4.|
|15||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.|
|16||Bubenik, R., et al., "Multipoint Connection Management in High Speed Networks," IEEE Infocom '91, pp. 59-67 (1991).|
|17||Burton, J., "Standard Issue," Byte, Sep. 1995, pp. 1-10.|
|18||Carne, E. B., "Modern Telecommunication," Applications of Communications Theory, GTE Laboratories Incorporated, 1984, pp. 44-47.|
|19||Casner, S., et al., "First IETF Internet Audiocast," Reprinted from ACM Siigcomm Computer Communications Review, Jul. 1992, vol. 22, No. 3, ISI Reprint Series, ISI/RS-92-293, Jul., 1992, pp. 1-6.|
|20||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.|
|21||Chen, M.S., et al., "Designing a Distributed Collaborative Environment," Dec. 6-9, 1992, IEEE Global Telecommunications Conference, Orlando, FL. pp. 213-219.|
|22||Chong-Kwon, K., et al., "Performance of Call Splitting Algorithms for Multicast Traffic, " Infocom 1990, pp. 348-356.|
|23||Cohen, D., "Specifications for the Network Voice Protocol (NVP)," NWG/RFC 741, Nov. 1977.|
|24||Cohen, D., "Specifications for the Network Voice Protocol, " USC/Information Sciences Institute, Mar. 1976, ISI/RR-75-39, Available from DTIC (AD 190 A023506).|
|25||Comer, D., "Interworking with TCP/IP, vol. 1: Principles, Protocols, and Architecture," 2nd Edition, 1991, pp. 1-8, 337-346, 505, Prentice Hall, Englewood Cliffs, NJ.|
|26||Deering, S., "Host Extensions for IP Multicasting," RFC 1112, Internet Engineering Task Force, Aug. 1989.|
|27||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.|
|28||Eng, K. Y., et al., "Multicast and Broadcast Services in a Knockout Packet Switch," Proceedings of the IEEE Infocom'88, pp. 29-34.|
|29||European Search Report and Search Opinion, European Patent Application No. 07009590.6, Jul. 24, 2007.|
|30||European Search Report and Search Opinion, European Patent Application No. 07009591.4, Jul. 17, 2007.|
|31||European Search Report and Search Opinion, European Patent Application No. EP 07009592.2, Jul. 18, 2007.|
|32||Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, Internet Engineering Task Force, Nov. 1997.|
|33||Finnegan, J., "Building Windows NT-Based Client/Server Applications Using Remote Procedure Calls," Microsoft Systems Journal, Oct. 1994, pp. 1-17.|
|34||Forsdick, H., "Explorations into Real-Time Multimedia Conferencing," Proceedings of the 2nd International Symposium on Computer Message Systems, IFIP, Sep. 1985, pp. 331-347.|
|35||Gemmell, J. et al., "An Architecture for Multicast Telepresentations," Journal of Computing and Information Technology-CIT, pp. 255-272, vol. 6, No. 3.|
|36||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.|
|37||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.|
|38||Handley, M., et al., "The Conference Control Channel Protocol (CCCP): A scalable base for building conference control applications," ACM, Sigcomm, 1995, pp. 275-287.|
|39||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.|
|40||Jamsa, K., et al., "International Programming, " Jan. 1995, pp. 152-218.|
|41||Kalman, S., "CTI Systems: Now's the Time," Network VAR, Aug. 1995, pp. 1-5.|
|42||Kim, C., et al., "Performance of Call Splitting Algorithms for Multicast Traffic," Infocom '90, pp. 348, 356 (1990).|
|43||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.|
|44||Le Boudec, J., "The Asynchronous Transfer Mode: A Tutorial," Computer Networks and ISDN Systems, May 15, 1992, pp. 279-309, vol. 24, No. 4.|
|45||Lee, T. T., et al., "The Architecture of a Multicast Broadband Packet Switch," Proceedings of IEEE Infocom'88, pp. 1-8.|
|46||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.|
|47||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.|
|48||Leung, W.H., et al., "Multimedia Conferencing Capabilities in an Experimental Fast Packet Network," Proceedings of the International Switching Symposium, Oct. 25, 1992, Yokohama, Japan, pp. 258,262.|
|49||Levendel, Y., "Software Assembly Workbench: How to Construct Software like Hardware," IEEE, Feb. 1995, pp. 4-12.|
|50||Maeno, K., et al., "Distributed Desktop Conferencing System (Mermaid) Based on Group Communication Architecture," ICC '91, Jun. 28, 1991, pp. 0520-0525.|
|51||Magill, D. T., "Adaptive Speech Compression for Packet Communication Systems, " Conference Record of the IEEE National Telecommunications Conference.,1973, pp. 29D-129-D5.|
|52||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.|
|53||Mello, J. P., Jr., "Telephony's Killer App?," Byte, Sep. 1995, pp. 1-7.|
|54||Minzer, S. E., et al., "New Directions in Signaling for Broadband ISDN," IEEE, Communications Magazine, Feb. 1989, pp. 6-14.|
|55||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.|
|56||Musser, J. M., et al., "A Local Area Network as a Telephono 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.|
|57||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.|
|58||Nojima. S., et al., "High Speed Packet Switching Network for Multi-Media Information," Proceedings of IEEE 1986 Computer Networking Symposium, pp. 141-150.|
|59||Ott, J., et al., "Multicasting the ITU MCS: Integrating Point-to-Point & Multicast Transport," Singapore ICCS, 1994, pp. 1013-1017.|
|60||Palmer, L., et al., "Desktop Meeting," LAN Magazine, Nov. 1991, pp. 111-121, vol. 6, No. 11.|
|61||PCT International Search Report, PCT/US96/02459, Aug. 7, 1996.|
|62||Poggio, A., et al., "CCWS: A Computer-Based, Multimedia Information System," Computer, Oct. 1985, pp. 92-103.|
|63||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.|
|64||Schooler, E. M., "Case-Study: Multimedia Conference Control in a Packet-Switched Teleconferencing System," Reprinted from the Journal of Internetworking: Research and Experience, Jun. 1993, pp. 99-120, vol. 4, No. 2, ISI Reprint Series, ISI/RS-93-359, Aug. 1993, pp. 1-17.|
|65||Schooler, E. M., "Conferencing and Collaborative Computing," Multimedia Systems, 1996, pp. 210-225, vol. 4.|
|66||Schooler, E. M., "The Connection Control Protocol: Architecture Overview," USC/Information Sciences Institute, Version 1.0, Jan. 28, 1992, pp. 1-6.|
|67||Schooler, E. M., "The Connection Control Protocol: Specification," USC/Information Sciences Institute, Version 1.1, Jan. 29, 1992, pp. 1-6.|
|68||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.|
|69||Schooler, E. M., et al., "Multimedia Conferencing: Has it come of age?," IEEE Journal on Selected Areas in Communications, 1991, pp. 707-716.|
|70||Schooler, E., M., "A Packet-Switched Multimedia Conferencing System," Reprinted from ACM Sigois Bulletin, Jan. 1989, pp. 12-22, vol. 1, No. 1, University of Southern California, Information Sciences Institute.|
|71||Schulzrinne, H., "A Transport Protocol for Real-Time Applications," Audio-Video Transport WG, Internet Engineering Task Force, Internet Draft, draft-ieft-avt.rtp-00, Dec. 15, 1992, pp. 1-12.|
|72||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.|
|73||Shenker, S., et al., "Managing Shared Epherneral Teleconfercncing State: Policy and Mechanism, " Lecture Notes in Computer Science, 1994, vol. 882, 69.|
|74||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.|
|75||Shinjo, Y., et al., "The 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.|
|76||Turner, J. S., "Design of a Broadcast Packet Switching Network," IEEE Transactions on Communications, Jun. 1988, pp. 734-743, vol. 36, No. 6.|
|77||U.S. Appl. No. 10/020,515 filed Dec. 7, 2001, Riddle.|
|78||U.S. Appl. No. 10/857,798 filed May 28, 2004, Riddle.|
|79||U.S. Appl. No. 10/857,799 filed May 28, 2004, Riddle.|
|80||U.S. Appl. No. 10/857,805 filed May 28, 2004, Riddle.|
|81||U.S. Appl. No. 10/857,806, filed May 28, 2004, Riddle.|
|82||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.|
|83||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.|
|84||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.|
|85||Wong, W., "Welcome to Teleconferencing, " Stack, Jun. 1995, pp. 1-7.|
|86||Yukimatsu, K., "Multicast Communication Facilities in a High Speed Packet Switching Network," Proceedings of ICCC'88, pp. 276-281.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US20150109968 *||Oct 21, 2013||Apr 23, 2015||Vonage Network Llc||Method and system for automating conferencing in a communication session|
|U.S. Classification||709/227, 709/228, 709/204, 709/231, 709/237|
|International Classification||H04N7/15, H04L12/18, H04N7/14, H04M3/56, H04N7/24, G06F15/16|
|Cooperative Classification||H04L65/1089, H04L65/4046, H04L12/1863, H04L12/1827, H04M3/567, H04L65/607, H04L12/1886, H04M3/564, H04N7/147, H04M2203/5009, H04N7/15|
|European Classification||H04M3/56G2, H04N7/15, H04L12/18D3, H04N7/14A3, H04M3/56M, H04L29/06M2S4M2, H04L29/06M4C4|
|Jul 11, 2011||REMI||Maintenance fee reminder mailed|
|Sep 6, 2011||SULP||Surcharge for late payment|
Year of fee payment: 11
|Sep 6, 2011||FPAY||Fee payment|
Year of fee payment: 12