Scalable multiparty conferencing and collaboration system and method of dynamically allocating system resources and providing true color support in same Number:7,136,062 from the United States Patent and Trademark Office (PTO) owispatent A networking conferencing and collaboration tool utilizing an enhanced T.128 application sharing protocol. This enhanced protocol is based on a per-host model command, control, and communication structure. This per-host model reduces network traffic, allows greater scalability through dynamic system resource allocation, allows a single host to establish and maintain a share session with no other members present, and supports true color graphics. The per-host model allows private communication between the host and a remote with periodic broadcasts of updates by the host to the entire share group. This per-host model also allows the host to allow, revoke, pause, and invite control of the shared applications. Subsequent passing of control is provided, also with the hosts acceptance. The model contains no fixed limit on the number of participants, and dynamically allocates resources when needed to share or control a shared application. These resources are then freed when no longer needed. Calculation of minimum capabilities is conducted by the host as the membership of the share changes. The host then transmits these requirements to the share group.<H collaboration, conferencing, Scalable, multip, 7136062.html, Patent, pto, 7136062

Title: Scalable multiparty conferencing and collaboration system and method of dynamically allocating system resources and providing true color support in same

Abstract: A networking conferencing and collaboration tool utilizing an enhanced T.128 application sharing protocol. This enhanced protocol is based on a per-host model command, control, and communication structure. This per-host model reduces network traffic, allows greater scalability through dynamic system resource allocation, allows a single host to establish and maintain a share session with no other members present, and supports true color graphics. The per-host model allows private communication between the host and a remote with periodic broadcasts of updates by the host to the entire share group. This per-host model also allows the host to allow, revoke, pause, and invite control of the shared applications. Subsequent passing of control is provided, also with the hosts acceptance. The model contains no fixed limit on the number of participants, and dynamically allocates resources when needed to share or control a shared application. These resources are then freed when no longer needed. Calculation of minimum capabilities is conducted by the host as the membership of the share changes. The host then transmits these requirements to the share group.

Patent Number: 7,136,062 Issued on 11/14/2006 to Butler

Inventors: Butler; Laura J. (Seattle, WA)
Assignee: Microsoft Corporation (Redmond, WA)

Appl. No.: 09/395,480

Filed: September 14, 1999

Current U.S. Class: 345/422 ; 345/591; 345/597; 345/600; 345/605

Current International Class: G06T 15/40 (20060101)

Field of Search: 345/422,597,591,600,605

References Cited [Referenced By]

U.S. Patent Documents


5060054	October 1991	Murakami et al.
5467264	November 1995	Rauch et al.
5471318	November 1995	Ahuja et al.
5530795	June 1996	Wan
5717863	February 1998	Adamson et al.
5717879	February 1998	Moran et al.
5812534	September 1998	Davis et al.
5864711	January 1999	Mairs et al.
5870547	February 1999	Pommier et al.
5874960	February 1999	Mairs et al.
6288729	September 2001	Laksono et al.
6292166	September 2001	Palmer et al.

Foreign Patent Documents


38 18 087	Dec., 1989	DE

Other References

Kanellopoulos, D.N. et al. "The Comprehensive Approach of QoS and the Evolution of ACSE Protocols in Multimedia Communications" Electronics, Circuits and Systems, 1996, 'ONLINE! vol. 1, Oct. 13-16, 1996, pp. 323-326. cited by other .
Onmori T et al. "Cooperative Control for Sharing Applications Based on Distributed Multiparty Desktop Conferencing System: Mermaid" Proceedings of the International Conference on Communications, US, NewYork, IEEE, vol.-, Jun. 14, 1992, pp. 1069-1075. cited by other .
"Microsoft NetMeeting 3.0 Resource Kit," Microsoft Corporation, 1999. cite- d by other .
R. Schaphorst, "Chapter 7: ITU-T Recommendation H.323 Packet-Based Multimedia Communications Systems," Videoconferencing and Videotelephony: Technology and Standards, Boston, Massachusetts, 1999. cited by other .
"TAPI 3.0 and NetMeeting 2.0," Microsoft Developer's Network CD, Microsoft Corporation, Mar. 30, 1999. cited by other .
R. Schaphorst, "Chapter 10: Multipoint Graphic Communications (T.120)," Videoconferencing and Videotelephony: Technology and Standards, Boston, Massachusetts, 1999. cited by other .
"Understanding Proxy Server," Microsoft Developer's Network CD, Microsoft Corporation, 1998. cited by other .
"Video-Conference Program Allows More Private Face-To-Face Time," Chicago Tribune, May 24, 1999. cited by other .
"Exchanging Session Keys," Microsoft Developer's Network CD, Microsoft Corporation, 1999. cited by other .
"Chapter 4 Firewall Configuration," Microsoft Developer's Network CD, Microsoft Corporation, Apr. 30, 1998. cited by other .
"Chapter 6 Troubleshooting," Microsoft Developer's Network CD, Microsoft Corporation, Apr. 30, 1998. cited by other .
"Chapter 7 NetMeeting Architecture," Microsoft Developer's Network CD, Microsoft Corporation, Apr. 30, 1998. cited by other .
"Chapter 8 Conferencing Standards," Microsoft Developer's Network CD, Microsoft Corporation, Apr. 30, 1998. cited by other .
"Chapter 9 Product Interoperability," Microsoft Developer's Network CD, Microsoft Corporation, Apr. 30, 1998. cited by other .
A. Krassel et al., "Microsoft's NetMeeting 2.1 COM Interfaces: Understanding How They Work," Microsoft Corporation, [web page], Apr. 10, 1998. http://www.msdn.microsoft.com/workshop/messaging/netmtg/netmtgcom.a- sp. [Accessed May 18,1999]. cited by other .
"Text Figures," Microsoft Corporation, [web page], 1999. http://www.microsoft.com/mind/0199/netmeeting/netmeetingtextfigs.htm. [Accessed May 18, 1999]. cited by other .
Microsoft Corporation, "How to Establish NetMeeting Connections Through a Firewall," [web page], revised Oct. 23, 1998. http://support.microsoft.com/support/kb/ARTICLES/Q158/6/23.asp. [Accessed May 18, 1999]. cited by other .
Microsoft Corporation, "How to Create a NetMeeting Hyperlink on a Web Page," [web page], revised Oct. 22, 1998. http://support.microsoft.com/support/kb/ARTICLES/Q157/2/77.asp. [Accessed May 18, 1999]. cited by other .
Microsoft Corporation, "How to Share Programs with NetMeeting," [web page], revised Oct. 27,1998. http://support.microsoft.com/support/kb/ARTICLES/Q154/3/54.asp. [Accessed May 18, 1999]. cited by other .
Microsoft Corporation, "How to Make a Video Call with NetMeeting," [web page], revised Oct. 27, 1998. http://support.microsoft.com/support/kb/ARTICLES/Q167/7/78.asp. [Accessed May 18, 1999]. cited by other .
Microsoft Corporation, "How to Start NetMeeting Conference from a Command Line," [web page], revised Oct. 27, 1998. http://support.microsoft.com/support/kb/ARTICLES/Q167/0/97.asp. [Accessed May 18, 1999]. cited by other .
Microsoft Corporation, "How to Use Whiteboard in Microsoft NetMeeting," [web page], revised Oct. 27, 1998. http://support.microsoft.com/support/kb/ARTICLES/Q154/3/10.asp. [Accessed May 18, 1999]. cited by other .
White Pine, "CU-SeeMe Pro Will Improve Communication and Collaboration," [web page], 1999. http://www.wpine.com/Products/CU-SeeMe-Pro/cu-pro-business-features.html. [Accessed May 19, 1999]. cited by other .
White Pine, "All New CU-SeeMe Pro-Changing the Face of Communication!," [web page], 1999. http://www.wpine.com/Products/CU-SeeMe-Pro/index.html. [Accessed May 19, 1999]. cited by other .
DataBeam, "DataBeam Meeting Tools!," [web page], 1999. http://www.databeam.com/meetingtools/info.html. [Accessed May 19, 1999]. cited by other .
IMTC, "IMTC Search: H.245," [web page], 1999. http://www.imtc.org/cgi-bin/query.cgi. [Accessed May 11, 1999]. cited by other .
IMTC, "H.323 Overview," [web page], 1999. http://www.imtc.org/h323body.htm. [Accessed May 11, 1999]. cited by other .
IMTC, "Frequently Asked Questions," [web page], 1999. http://www.imtc.org/faqbody.htm. [Accessed May 11, 1999]. cited by other .
IMTC, "H.320 Overview," [web page], 1999. http://www.imtc.org/h320body.htm. [Accessed May 11, 1999]. cited by other .
IMTC, "T.120 Overview," [web page], 1999. http://www.imtc.org/t120body.htm. [Accessed Jun. 17, 1999]. cited by othe- r .
"NetMeeting 3 Beta," [web page], Updated Mar. 23, 1998. http://www.microsoft.com/netmeeting/Beta30.htm. [Accessed May 7, 1999]. cited by other .
A. Krassel et al., "Microsoft NetMeeting 2.1 COM Interfaces: Understanding How They Work," [web page], Microsoft Corporation, Apr. 10, 1998. http://msdn.microsoft.com/library/techart/msdn.sub.--netmtgcom.htm. [Accessed May 4, 1999]. cited by other .
Don Anderson, "Overview of the IEEE 1394 Architecture,"FireWire System Architecture: 2nd Edition, MindShare, Inc., Addison-Wesley: Reading, Massachusetts, pp. 19-34, (1999). cited by other .
"Secure Networking Using Microsoft Windows NT 5.0 Distributed Security Services," Microsoft Developer's Network CD, Microsoft Corporation, 1999. cited by other .
Microsoft Corporation, "Microsoft Certificate Server," [web page], Apr. 17, 1997. http://msdn.microsoft.com/workshop/security/client/certsvr.asp. [Accessed May 20, 1999]. cited by other .
Microsoft Corporation, "Windows NT E3/F-C2 Evaluations," [web page], Apr. 28, 1999. http://www.microsoft.com/security/issues/e3fc2summary.asp. [Accessed May 4, 2000]. cited by other .
Microsoft Corporation, "Secure Sockets Layer/Transport Layer Security," [web page], Oct. 8, 1998. http://www.microsoft.com/security/tech/ssl/default.asp. [Accessed May 21, 1999]. cited by other .
Microsoft Corporation, "How to Parse a Certificate Using Active Server Pages (ASP)," [web page], Updated Dec. 1996. http://msdn.microsoft.com/workshop/security/client/parse.asp. [Accessed May 20, 1999]. cited by other .
Microsoft Corporation, "Securing Data Transmissions with Secure Sockets Layer (SSL)," [web page ], Updated Dec. 1996. http://msdn.microsoft.com/workshop/security/client/iis.sub.--ssl.asp. [Accessed May 20, 1999]. cited by other .
Netscape Communications Corporation, "How SSL Works," [web page], 1999. http://developer.netscape.com/tech/security/ssl/howitworks.html. [Accessed Nov. 16, 1999]. cited by other .
VeriSign, Inc., "Encryption and Digital Certificates," [web page], 1999. http://www.verisign.com/whitepaper/enterprise/overview/page2.html. [Accessed Nov. 16, 1999]. cited by other .
Netscape, "How Digital Certificates Work," [web page], 1999. http://www.netscape.com/security/techbriefs/certificates/howcerts.html. [Accessed Nov. 16, 1999]. cited by other .
Netscape Communications Corporation, "Enterprise-Ready, Open Standards-Based Email Security," [web page], 1999. http://developer.netscape.com/tech/security/email/smime.html. [Accessed Nov. 16. 1999]. cited by other .
Netscape, "How Personal Certificates Work," [web page], 1999. http://www.netscape.com/security/techbriefs/personalcerts/how.html. [Accessed Nov. 16, 1999]. cited by other .
Netscape, "Personal Certificates," [web page], 1999. http://www.netscape.com/security/techbriefs/personalcerts/index.html. [Accessed Nov. 16, 1999]. cited by other .
Keith Brown, "Security Briefs," Microsoft Developer's Network CD, Microsoft Corporation, Feb. 1999. cited by other .
"PFX: Personal Information Exchange Syntax and Protocol Standard," Microsoft Developer's Network CD, Microsoft Corporation, Jan. 27, 1997. cited by other .
J. Benaloh et al., "The Private Communication Technology (PCT) Protocol," Microsoft Developer's Network CD, Internet Draft, Microsoft Corporation, Oct. 1995. cited by other .
"What's New in the NetMeeting Resource Kit Wizard," Microsoft Developer's Network CD: Microsoft NetMeeting, Microsoft Corporation, Apr. 1999. cited by other .
"First-Time Users," Microsoft Developer's Network CD: Microsoft NetMeeting, Microsoft Corporation, Apr. 1999. cited by other .
"Before the Meeting Starts," Microsoft Developer's Network CD: Microsoft NetMeeting, Microsoft Corporation Apr. 1999. cited by other .
"During the Meeting," Microsoft Developer's Network CD: Microsoft NetMeeting, Microsoft Corporation, Apr. 1999. cited by other .
"Troubleshooting Tips," Microsoft Developer's Network CD: Microsoft NetMeeting, Microsoft Corporation, Apr. 1999. cited by other .
"Glossary," Microsoft Developer's Network CD: Microsoft NetMeeting, Microsoft Corporation, Apr. 1999. cited by other .
"NetMeeting 2.1 Features," [web page], Microsoft Corporation, Update Jan. 5, 1998. http://www.microsoft.com/netmeeting/features/main.html. [Accessed May 4, 1999]. cited by other .
Microsoft Corporation, "Microsoft NetMeeting 2.0: Overview and Frequently Asked Questions," [web page], Updated Jul. 15, 1997. http://msdn.microsoft.com/library/backgrnd/html/msdn.sub.13 netmofaq.htm. [Accessed May 4, 1999]. cited by other .
"Microsoft NetMeeting 3.0 Resource Kit," Microsoft Corporation, 1999. cite- d by other .
DataBeam, "A Primer on the T.120 Series Standard," [web page], 1999. http://www.databeam.com/ccts/t120primer..html. [Accessed May 4, 1999]. cited by other.

Primary Examiner: Tung; Kee M.
Assistant Examiner: Tran; Tam
Attorney, Agent or Firm: Perkins Coie LLP

Claims

What is claimed is:

1. A method performed by a computing device for supporting true color graphics in a multipoint data conference having at least a conference server computing device and a conference participant computing device, comprising the steps of: examining by the conference server computing device color depth capabilities of all conference participant computing devices; and transmitting true color graphics if the examining indicates that all conference participant computing devices can support true color graphics.

2. The method of claim 1, further comprising the steps of: mapping true color graphics to closest equivalent in a color palette of a depth determined by the lowest color depth supported by any participant computing device; transmitting mapped graphics to all participant computing devices.

3. The method of claim 1, wherein true color is represented by at least twenty-four bits per pixel.

4. The method of claim 2, wherein the step of mapping comprises the step of mapping the true color graphics to a closest equivalent in a color palette that has fewer colors than true color.

5. The method of claim 1, further comprising the step of re-examining the color depth capabilities of conference participant computing devices upon addition and deletion of conference members.

6. The method of claim 5, further comprising the step of repainting shared information if the color depth capabilities change.

7. The method of claim 6, wherein the step of repainting shared information includes the step of transmitting true color graphics if all conference participant computing devices can support true color graphics.

8. The method of claim 6, wherein the step of repainting shared information includes the step of mapping true color graphics to closest equivalent in a color palette of a depth determined by the lowest color depth supported by any participant computing device.

9. The method of claim 8, wherein the step of mapping comprises the step of mapping the true color graphics to the closest equivalent in a color palette that has fewer colors than true color.

10. The method of claim 1, wherein the step of transmitting includes the step of specifying color depth in drawing order packets identifying the color depth for which these packets were generated.

11. The method of claim 1, wherein the step of transmitting includes the step of transmitting packets of less than 256 bytes in uncompressed format.

12. The method of claim 1, wherein the step of transmitting includes the step of persistently compressing packets to a size less than or equal to four kilobytes.

13. A method performed by a computing device for transmitting graphics in a multipoint data conference having at least a server computing device and a conference participant computing device, comprising the steps of: examining color depth capabilities of conference participant computing devices, the conference participant computing devices having differing color depth capabilities; identifying a minimum color depth supported by any conference participant computing device; and transmitting graphics at the minimum color depth supported by any conference participant computing device to all conference participant computing devices.

14. The method of claim 13, wherein the step of transmitting graphics comprises the step of transmitting true color graphics if all conference participant computing devices can support true color graphics.

15. The method of claim 13, further comprising the step of mapping true color graphics to a closest equivalent in a color palette of a depth determined by the lowest color depth supported by any participant computing device performed prior to the step of transmitting.

16. The method of claim 15, wherein the step of mapping comprises the step of mapping the true color graphics to a closest equivalent in a color palette that has fewer colors than true color.

17. The method of claim 15, wherein true color is represented by at least twenty-four bits per pixel.

18. The method of claim 13, wherein the step of transmitting includes the step of specifying color depth in drawing order packets identifying the color depth for which these packets were generated.

19. The method of claim 13, wherein the step of transmitting includes the step of transmitting packets of less than 256 bytes in uncompressed format.

20. The method of claim 13, wherein the step of transmitting includes the step of persistently compressing packets less than or equal to four kilobytes.

Description

FIELD OF THE INVENTION

The instant invention relates to Internet and intranet multiparty conferencing and collaboration tools, and more particularly to a multiparty conferencing and collaboration tool providing enhanced scalability through the dynamic allocation of system resources which also provides true color 24 bpp support.

BACKGROUND OF THE INVENTION

Real time communication is vital to the success of any business. As businesses continue to grow and develop outside the typical four walls of an office or factory, with multiple divisions located around the country and around the world, with an increasing number of employees telecommuting, and even with employees located in different distant parts of the same building, tools facilitating real time communication are becoming essential, not just for businesses to succeed, but also for businesses to simply survive. While the widespread use of local area networks (LANs), wide area networks (WANs), and e-mail has increased the productivity of many companies and individuals, such structures and tools do not provide, by themselves, the ability for real time group collaboration so essential for the success of work groups and design teams which, in turn, drives the success of businesses.

In recognition of the changing way businesses need to function to survive and prosper in this distributed environment of the world-wide workplace, the assignee of the instant invention developed and released a network conferencing and collaboration tool called NetMeeting.TM. 2.0. This tool provides H.323 standards-based voice and video conferencing, T.120 multipoint data conferencing including application sharing, clipboard sharing, file transfer, whiteboard, and chat features. Application sharing is a feature of NetMeeting.TM. that allows a person in a conference running an application locally with local data (like Notepad.TM.) to send the graphics of the application to the other people in the conference. The remote people see what the local person does, the title bar, the client area, obscured areas, etc. The remotes can even control the shared application, the remote person in control's keyboard and mouse drive the keyboard and mouse of the person sharing the application. This results in appearance changes, like opening a new file would, and those will be transmitted back from the sharer to the others.

These features were immediately successful in aiding the real time communication and design activity of many businesses. As companies became more and more familiar with the advantages available through such a tool, their demand for increased usage of and capabilities from such a tool exceeded even the expectations of the assignee. However, at the same time that users were demanding increased usage, they were also demanding increased control, new features, and reduced network resource and time utilization from this tool.

One of the most desired feature enhancements of this tool was to increase the number of simultaneous users who could participate in an on-line conference. However, a 16-bit version of the application sharing code, NetMeeting.TM. 2.0, was built on the Win 9x platform which is interrupt based for mouse and keyboard inputs. As such, and because it was based off Win3.x technology, this platform required the up-front allocation of system memory for all users. This up-front allocation of system resources required that all resources which might ever be need by the users were allocated. This was quite wasteful since a good portion of the allocated resources needed for application sharing were allocated to many users who would never share or collaborate, and were only in the meeting to view. This could total three megabytes for each user, to represent their desktop and create the required object caches. Because of this memory allocation requirement and based on estimated typical system user resources, a maximum hard limit of 32 users was set in the system. While this was believed to be adequate for most meetings, the demand for more attendees based on the ease of communication flow soon pushed the limit beyond that which the system would allow.

Another problem which became apparent as the number of meeting participants grew relates to the network traffic generated between participants under the T.128 application sharing protocol. With increasing numbers of participants in a meeting, the number of message packets sent between these participants during operation and when a new person wanted to join the meeting increased to a point where the delay in communication and interruption of the meeting became excessive. In addition to the number of messages which were sent, the computational algorithms used were complex, adding proportionally to the amount of time needed for anything to happen. Depending on the particular connections between participants, e.g. the Internet, the delay in the meeting resulting from a new person joining could extend into the several minutes range. With this type of delay, people hang-up, lose their Internet connection, lose interest, etc.

The T.128 model utilized in this NetMeeting.TM. system was a global free-for-all model where all members were peers. Every person in the conference would maintain a global list, ordered from front to back of all of the shared applications of everybody in the conference, merged completely together. Each person had to be in lock-step with the others, so that the positions, order, and appearance of all shared applications were in sync. Any change in order, state, or position had to be transmitted to everyone in the meeting. This would frequently cause a Ping-Pong effect whereby the new global list would be sent, someone in the conference would decide it was out of date because their shared application had moved, and would transmit a new window list, and so forth. This problem was exacerbated by the collaboration model which also required that all members of the conference periodically broadcast his or her mouse position. This additional network traffic was necessitated by the toggle during collaboration whereby only one of the collaborators controlled all of the collaborators' mice and keyboards. Therefore, the host would periodically need to check where everyone's cursor is positioned.

As a result of this global, chaotic model, the total network traffic could become excessive due to the amount of this circular traffic, even from members not sharing anything. All of the packets of information were broadcast, with one copy for each member of the conference. The delays resulting from this excessive network traffic caused cursor movements, especially when in control of a remote member's application, to be extremely jerky. This made it almost impossible to control a remote's application with any degree of confidence that the remote user's mouse was really where the controlling member thought it was. Further, under this model no one could do anything until all members were up to date, which further slowed the conference response time. In addition to the network traffic described above, to interpret data from a host, e.g. the drawings of an application, all members in the conference had to know about and interpret the capabilities of all other members of the conference. This drove the network traffic volume even higher, and slowed the system response still further.

Another problem which became apparent from the global collaboration model of NetMeeting.TM. 2.0 as the number of members in a conference grew was the control of applications which were being shared. This control/collaboration model in the T.128 application sharing protocol of NetMeeting.TM. 2.0 was global. Each member of the conference could start/stop collaborating. Exactly one of the members collaborating was considered to be in control. Her mouse/keyboard drove the mice and keyboards of the other members collaborating. Those other members were controlled, and their mice and keyboards were locked. However, if they were not sharing anything, the mouse and keyboard input from the person in control would go to nowhere, since the remote users were only allowed to control shared applications, and not unshared ones. This appeared to lock their mice and keyboards for no reason, which was very frustrating especially in the multitasking world of Windows.TM..

Additionally, anyone collaborating could become the person in control by a simple action such as a mouse click or key press. If several people took control around the same time, the last person to do so won, until the next person took control. There was no organization or order to the passing of control, it was a chaotic model. The users of the system soon termed this chaotic operation as "mouse wars." With a decent number of people in a conference, the telephone was the only way to keep things from getting out of hand. There was a lot of "OK, I am going to take control now, do not do anything anybody" discussion back and forth. Further, collaboration was a two-way street. A person might only want to control another's applications without exposing his own applications to another's control. Unfortunately, that was not possible in this model. Collaboration was all or nothing. Additionally, there was no way for a person to gracefully decline a control operation or even know that it was about to happen. Control would be yanked away without warning.

This global, chaotic collaboration model also added to the excessive network traffic described above. Each control change required some retransmitting of input state information, especially toggle keys, and discarding old accumulated input. The person in control broadcasted his input messages to everyone. All of the members collaborating played back these input messages, skipping ones that obviously would manipulate non-shared windows, and then if they ended up going to a window not shared, swallowed them at the last minute. That allowed the cursor to move, but the actual movement of the mouse notification to not get sent to the windows under the mouse if they are not shared. Further, there was required a lot of complicated token/sequence number/guessing/time stamp calculations performed to figure out who has control if several people try to take control at once, or if it is taking too long to hear back.

A further problem identified relates to the initiation of an application share for a conference. The T.128 protocol utilized in NetMeeting.TM. 2.0 requires two people to be in a conference before anybody could share an application. This requirement also meant that if the second-to-last person left the conference, sharing would stop if it were ongoing. This requirement existed because starting up application sharing was a call-response process. The person wanting to share an application would broadcast an "is it ok" packet, and then wait for a response saying "sure, go ahead" before beginning the share. This turned out to be a much worse than is may have first appeared. Users wanted to be able to organize a meeting whereby they could be the only person in the meeting for a while to allow them to set up attributes, applications, and files prior to having others join the meeting. Without this capability, much time is wasted by the other meeting participants while the host completes these activities with them present.

An additional problem relates to the prior T.128 protocol for NetMeeting.TM. having a limit of 256 colors, 8 bits per pixel (bpp). If a user shared applications on a screen that was running at a greater color depth than 256, information would be lost. The graphics would be constrained and colors would be mapped to the closest equivalent in a 256 color palette. Simple applications did not experience much of a problem, since not many applications make full use of the available colors. The system colors and other common ones are always available. However, a high end bitmap or a web page with photos, for example, would not look good when shared. They would look posterized on the remote users' monitors.

SUMMARY OF THE INVENTION

In view of the above identified and other problems existing in the art, the inventive concepts and teachings of the instant invention involve the application sharing protocol otherwise known as T.128, as preferably implemented in NetMeeting.TM. 3.0. These protocol changes are the result of a shift from a global collaboration model of prior versions of NetMeeting.TM. to the "per-host model" of NetMeeting.TM. 3.0 and later versions. The implementation of the per-host model vastly increases the functionality and ease of use of network conferencing tools by reducing network traffic, allowing greater scalability, providing better control and collaboration among users, allowing solitary members to begin a share without the necessity of a second or subsequent party, and supporting true color graphics.

By implementing a per-host model whereby communication with and control of the host takes place in a private fashion between the host and a remote with periodic broadcast updates by the host to the entire share group, the total number of network messages which are required to be transmitted between the members of the share group are greatly reduced. To contrast this per-host model, the prior versions of NetMeeting utilized a global model where each person in the conference would maintain a global list, ordering front to back, of all the shared applications of everybody in the conference, merged completely together. This resulted not only in a large number of messages being initially required to maintain the members of the conference in lockstep, but also had a ripple effect whereby each adjustment resulting from the reception of such a message would essentially be echoed back in a broadcast global fashion since a change had now occurred on that user's system.

In the per-host model, the network traffic almost always originates from the host only as opposed to being globally transmitted by each of the members of the conference. While multiple members of the conference may share an application, this per-host model allows each of those members who are sharing to act like a miniature server for the conference, i.e. a host of that shared application. Updates, therefore, instead of being globally transmitted by all members of the conference, simply now stream down from the host. This requires only that the members of the conference need the capabilities of that particular host. A performance improvement is particularly noticeable in the per-host model when a member of the conference is in control of the host. In the per-host model the controlling member transmits its keyboard and mouse move messages privately to the host who then periodically broadcasts the current cursor position to all members of the conference.

Industry performance data has indicated that a reduction in network traffic of about 25% in a 5 person conference with one person sharing. This reduction increases as the number of people sharing increases, and as the number of people in the conference increases. The reduction in network traffic when someone is controlling the shared applications of another is approximately 50% or more. This reduction could be increased, however it was decided instead to increase the fidelity of the mouse moves to allow finer movements, etc. for better responsiveness. This means that many more mouse move packets are sent than prior versions to allow for this better performance. The reduction in network traffic to add a new person to the conference is approximately 90% or more when the number of existing people is 20 or greater. This reduction is truly an unexpected result which was originally met with skepticism from industry experts until confirmed with actual measurments.

At a detailed level, the following packet changes are implemented for NetMeeting.TM. 3.0: fewer and smaller Shared Window Lists (SWL) broadcast packets; fewer Active Window Coordinator (AWC) broadcast packets; fewer cursor broadcast packets; fewer Host Entity Tracker (HET) broadcast packets; fewer Synchronizing New Individuals (SNI) broadcast packets; fewer control arbitration (CA) packets; new control (CA30) packets; and fewer Input Manager (IM) packets. These revised and new packets, and the way that they are shared when a new member joins the conference, result in a significant reduction in traffic during application sharing just to get everyone in synchronism with the sharing application.

A further embodiment of the instant invention includes a new collaboration/control model for the application sharing protocol T.128 as implemented in the per-host model of NetMeeting.TM. 3.0. In the new T.128 application sharing protocol, the control/collaboration model is per-host. As such, the host is in control not only of her shared application, but also of when and to whom control is relinquished. This allows a host to share an application without worrying about inadvertently losing control of her shared application, and also allows a host to take control of another host without requiring that she give up control of her shared applications. This ability to designate a host's controllable status as well as the granting or denying of control to a member is effectuated through a simple process. Under this process a host may indicate that her applications are not controllable, in which case she has full control of her shared applications without further interaction or requirement on her part. Alternatively, the host may, at any time during the share, designate an application as being controllable, in which case control of her shared application may be passed to another member of the share. In this state the host may decide to pass control by her own initiation to another member of the share by offering control to that member. In this type of situation, the host invites a remote to assume control of the shared application at which point the remote then has the option to accept control or decline the offer. Until the remote has either accepted or declined the invitation to assume control of the shared application, the host has the power to revoke the invitation.

In addition to the host initiated invitation to assume control of the shared application, a remote may also request permission from the host to take control of her shared application. Under this condition the remote sends a request to assume control to the host who then has the option to either accept or decline the request for assumption of control. As with the invitation to assume control, the remote who has initiated the request has the power to cancel the request at any time prior to the host's acceptance or declination of granting control. Further, to ensure that requests and invitations do not go unanswered, the system also includes a time out function whereby a request or an invitation is only valid for a certain period of time after which the request or invitation is automatically declined. At any point during the remote control of the host's shared application, the host has the power to immediately terminate the remote's control. Further, the host also has the less intrusive option of simply pausing the remote's control temporarily while still maintaining that remote in actual control of the shared application. Once the host unpauses the control the remote then is able to pick up where she left off.

The control may also be passed from one remote to another in this preferred embodiment. However the per-host model ensures that the host of the shared application agree with the passing of control to a subsequent remote before actual control is passed to that remote. If the passing of control to a subsequent remote is agreeable with the host, control is passed to that subsequent remote. If the host disagrees with the subsequent passing of control to the subsequent remote, control stays with the initial remote user. As with requesting or inviting control from a host, a similar mechanism is utilized at the remote level for requesting or inviting control. However, the ultimate decision maker for the shared application control is the host who initiated the share.

In a preferred embodiment of the instant invention, the memory allocated to each member of the conference is now set dynamically such that each member is given a minimum allocation of memory which may be adjusted once that member begins to share. Further, since the memory allocation is now dynamic, the necessity for placing a maximum limit on the number of users of a conference is no longer required. Therefore, the system of the instant invention allows as many members in a conference as may be supported by the meeting or conference host's memory availability. As new members join a conference or as old members leave a conference, memory is dynamically allocated to or freed from that member without significant disruption to the overall operation of the system.

The new T.128 protocol of the instant invention also preferably allows a one person conference by not waiting for a response to the broadcast "is it okay" packet sent to establish a share. Instead, the new T.128 protocol assumes that sharing has succeeded if the person sharing is also the host of the meeting. This mechanism also resolves any conflict resolution problem by always working in favor of the meeting or conference host should two people attempt to share the first thing at about the same time. Further, the conflict resolution works in favor of the more senior conference or meeting member (the one who joined the meeting or conference earlier than the other) should the conflict not involve the meeting or conference host.

Additionally, a preferred embodiment of the instant invention utilizes the new T.128 protocol to support true color application sharing in a 24 bits per pixel, non-palettized, standard interchangeable format that maps directly to the video hardware. However, while 24 bits per pixel true color is supported, it will only be sent if everyone in the conference has the capability to view it and everybody has a 24 bpp or greater display. If not everyone has a 24 bpp or greater display, the information will not be accurately displayed on their machine and, since such true color support generates a lot more data, there is no need to send such high quality video information if it cannot be viewed accurately anyway. This additional data does not affect performance much if applications such as NotePad.TM. are being shared. However, if a graphically intensive application is shared there may be significant performance impact. This is because a fixed amount of memory is devoted to the cached bitmaps, and the 24 bpp bitmaps are three times the size of an 8 bpp bitmap. Therefore, only one-third as many fit in the cache. This results in fewer cache hits which then necessitates the sending of bitmap bits more often. Further, since application sharing has a maximum uncompressed packet size of 32,000 bytes, it holds less true color screen data or true color bitmap cache orders, resulting in the requirement for sending more packets for the same area painted.

These and other features of the invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram illustrating an exemplary operating environment suitable for application of the instant invention; and

FIGS. 2a c graphically illustrate in simplified bar chart form the dynamic memory allocation of an embodiment of the instant invention.

While the invention is susceptible of various modifications and alternative constructions, certain illustrative embodiments thereof have been shown in the drawings and will be described below in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions and equivalents falling within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 in the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, microprocessor systems, microprocessor-based or programmable computer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced and distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference to FIG. 1, an exemplary system for implementing the invention includes a general purposed computing device in the form of a conventional personal computer 20, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system 26 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 20, such as during startup, is stored in ROM 24. The personal computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other date for the personal computer 20. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by the computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read-only memories (ROMs), and the like, may also be used in the exemplary operating environment.

A number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system busy 23 via an interface, such as a video adapter 48. In addition to the monitor, personal computers typical include other peripheral output devices (not shown), such as speakers and printers.

The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN working environment, the personal computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the wide-area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing the communications link between the computers may be used, e.g. dial-up modems/xDSL/cable modems, etc.

Having now described both the problems existing in the art and a suitable environment into which the solution provided by the instant invention is preferably applied, the focus is now turned to a description of a preferred embodiment of the instant invention. As indicated above, one of the first problems identified by users of NetMeeting.TM. 2.0 was the scalability problems associated with the fixed limit of 32 conference members and the static allocation of system resources driven by the Win 9x platform. A preferred embodiment of the instant invention, therefore, removes the fixed limit of users (now number of members in a conference is limited only by the available memory of the host) and utilizes dynamic system resource allocation. As these problems were resolved as will be described below, an underlying problem of excessive network traffic as the number of conference members grew resulting from the prior T.128 protocol was revealed. Therefore, a preferred embodiment of the instant invention involves enhancements to the T.128 protocol to allow for the efficient scalability of the conferencing and collaboration tool. An embodiment of the instant invention incorporating the teachings below may be found in a new release of the assignee's tool, NetMeeting.TM. 3.0.

Before discussing the specifics of a preferred embodiment of the instant invention, a brief overview of the multimedia teleconferencing standards is appropriate to form a foundation for the following teachings. The ITU-T T.120, H.320, H.323, and H.324 standard comprise the core technologies for multimedia teleconferencing. The T.120 standards address Real Time Data Conferencing, the H.320 standards address ISDN Videoconferencing, the H.323 standard addresses Video (Audiovisual) communication on LANs, and the H.324 standard addresses video and audio communications over low bit rate connections such as POTS modem connections. H.323 is so widespread because TCP/IP is extremely common and available for LANs, WANs, dial-up, XDSL, and all sorts of Network devices/configurations. The teachings and content of these standards are herein incorporated in their entirety by reference thereto.

The T.120 family of standards cover the document conferencing and application sharing (sometimes called data conferencing) portion of a multimedia teleconference. The recommendations specify how to efficiently and reliably distribute files and graphical information in real-time during a multipoint multimedia meeting. The objective of the standards is to assure interoperability between terminals without either participant assuming prior knowledge of the other system; permit data sharing among participants in a multimedia teleconference, including white board image sharing, graphic display information and image exchange, application sharing; and specify infrastructure protocols for audiographic or audiovisual applications.

The T.120 series governs the audiographic portion of the H.320, H.323, and H.324 series and operates either within these or by itself. The T.120 suite consists of a series of recommendations, which are summarized as follows:

TABLE-US-00001 Recommendation Description T.120 Data protocols for multimedia conferencing: This provides an overview of the T.120 series. T.121 Generic Application Template: This provides a guide for development of T.120 application protocols. T.122 Multipoint Communication Service (MCS) Service Description: This describes the multi-point services available to developers. T.123 Protocol Stacks for audiographic and audiovisual teleconference applications: This specifies transport protocols for a range of networks. T.124 Generic Conference Control (GCC): This defines the application protocol supporting reservations and basic conference control services for multipoint teleconferences. T.125 Multipoint Communication Service (MCS) Protocol specification: This specifies the data transmission protocol for multipoint services. T.126 Multipoint still image and annotation protocol: This defines collaborative data sharing, including white board and image sharing, graphic display information, and image exchange in a multipoint conference. T.127 Multipoint Binary File Transfer Protocol: This defines a method for applications to transmit files in a multipoint conference. T.128 Multipoint application sharing protocol: This defines how participants in a T.120 conference can share local applications such that other conference participants can see the image of the shared application, and use the mouse and keyboard to take control of the shared application as if it were running locally. T.134 Text chat application entity: A T.121 APE definition for a text chat protocol. T.135 User-to-reservation system transactions within a T.120 conference: This defines conferencing reservation protocols in a T.120 environment, typically between a client application and a scheduling systems which reserves resources for multipoint control units (MCUs or "bridges"). T.136 How Remote Device Control and configuration may be performed using T.120 as the transport protocol. T.140 Protocol for multimedia application text conversation. The protocol for text chat within T.120, goes with T.134. T.VMR Virtual Meeting Room control. Contains some material from previous T.13x drafts, concentrates on audio + dataconferencing.

Of the above governing standards, a preferred embodiment of the instant invention provides enhancements specifically to the T.128 Multipoint Application Sharing Protocol to substantially improve scalability. As will be described more fully below, scalability is improved by eliminating a fixed limit on the number of users, by reducing the amount of additional memory needed to hold information for a new member/collaborator/sharer in a conference, by reducing the amount of additional total network traffic amongst the members of a conference required to complete the join/collaboration/share during a conference, and by reducing the computational complexity of the algorithms used, which is proportional to the amount of time required for anything to happen during a conference.

These enhancements are embodied in a new T.128 model. Unlike the global, chaotic model of NetMeeting.TM. 2.0, the T.128 model of the instant invention is a per-host model. In this model, each person hosting (sharing an application) acts like a miniature server for the conference. Network traffic almost always originates from hosts only, and wends its way down to the others viewing in the conference. Members have separate state information for each person who is sharing. The updates (shared application lists, the graphics of the shared applications, the current cursor position and shape) stream down from the host. To interpret packets coming from the host only requires the viewer to know the capabilities of the host. The network traffic from a viewer is not broadcast, but sent privately back to the host, when controlling. The rest of the members in the conference see the results (changes in appearance, movement of the cursor, etc.) which are broadcast by the host later. Since input, mouse and keyboard messages, are only sent privately from a controller to a host, the latency and responsiveness, especially of the mouse, is much improved. This is especially noticeable in large conferences since there is no performance penalty as more people participate.

Specific changes in the T.128 protocol contemplated herein which allow the realization of the advantages of the instant invention involve not sending ignored user name/capabilities in some control packets; removing/ignoring many capabilities; streamlining cache capabilities negotiation when a node starts to share, stops sharing, and when a new person joins the conference; creating caches; order encoding data each time a note starts to host, and freeing/cleanup when the node stops hosting; eliminating some packet broadcasts to everyone in the conference or replacing them with targeted sends to an individual; and a new control model and new control packets. Like file transfer (T.127), T.128 has distinct send side (hosting) and receive side (viewing) parts that compose the logical T.128 applet. In the instant invention, a node in a conference is a host when it is sharing applications or its desktop. The act of hosting or sharing is the process of trapping the graphics on the screen and transmitting the updates for the entities that are shared. There is an UI applet for hosting which basically is a dialog that lists all of the top level applications running along with the entire desktop. This UI shows what is shared, and allows a user to share/unshare items and to stop sharing everything. This applet also allows a user to change whether the shared applications/desktop are controllable, and has other options for 24-bit color sharing and automatic handling of control requests. A node in a conference is a viewer when a remote node is hosting and it has AS active (unless application sharing is prevented by system policy). The UI for viewing may be a frame window displaying the shared contents of the remote host.

A host in a conference is controllable when it has checked Allow Control in the Conf Tools menu (or if SDK code does it pragmatically). At this point, it is possible for remote viewers to take control of it. When a viewer takes control of a controllable host, it becomes the controller of the host. When a viewer of a host becomes its controller, the host's own keyboard and mouse are locked, and input comes from the controller instead. The act of controlling is the process of sending input and window activation back to the host to drive its shared entities.

When at least one node in a conference is a host, the nodes in the conference are in a share. A share is another name for an active T.128 session. T.128 is the least T.120-ized of the standard applet protocols, since it came from a non-T.120 two person only primitive world (R.11). As such, there is some redundancy. Some of the rich T.120 primitives, like getting into conferences, exchanging capabilities, and determining the roster, are found in a more primitive form in T.128. So a share gets created, joined, and ended just like a conference does. And members are added and deleted just like in a conference.

In an exemplary embodiment of the instant invention, there are four parts to the T.128 protocol: CMG, the T.120 wiring to find out about calls and activate AS sessions; S20, the share establishment/capabilities exchange/member join/leave/share termination part; CPC, the member capabilities data sent via S20 control packets; and DATA, the AS streaming part, for hosting and controlling, which accounts for the capabilities of the share members so it does not send data or packets that they cannot understand. The following description of an exemplary embodiment is included by way of example, and not by way of limitation, to enable one of ordinary skill in the art to practice an embodiment of the instant invention.

CMG is utilized to find out when calls start, when calls end, and when members are added/removed. When a new call is starting, AS receives a permit to enroll indication notification. It enrolls its application by filling in a GCC session key field with appropriate key types, capability structure, etc. as is standard. The enroll request is filled in and the application enroll method is called to enroll or unenroll in the conference starting/ending. When an enroll confirm notification is received, it looks for success or failure. If failure, it cleans up as though the call had ended. If success, it enrolls the new member and watches for the application roster report indication notifications that indicate change. Finally, CMG looks for the local node in the member list, the first time it is seen the member is considered finally to be in a T.120 call. It processes its own section, looking for new members so it can add them, and for old members now gone so it can remove them. These are GROUPWARE members only, application sharing (AS) member addition/removal comes independently through the S20 protocol. When AS finally believes itself to be in a T.120 call, it attaches to the MCS domain so it can send and receive data. When the domain attachment is confirmed, AS joins two MCS channels: its own MCS user channel; and the MCS AS broadcast channel. When both of the MCS channels are joined, the system is ready.

S20 begins where CMG leaves off. In this exemplary embodiment there are six control packets, then one for data which is used by the streaming part of sharing. All S20 packets have a header. The exemplary packet types are as follows:

TABLE-US-00002 S20_CREATE Control packet to create a new share S20_JOIN Control packet to join an existing share S20_RESPOND Control packet to respond to and S20_JOIN S20_DELETE Control packet to eject a member from the share S20_LEAVE Control packet to yourself leave an existing share S20_END Control packet to end an existing share S20_