The present invention relates generally to data sharing among different computers and in particular to a method and system for controlling graphical information from a host computer that is displayed on at least one remote client computer. The present invention also relates to a method and system for managing data transfer between computers sharing graphical information and to a method and system of providing feedback to a presenter relating to viewers of a presentation.
Networked computer systems including computers executing desktop sharing applications to permit the computers to share displayed information are widely known and used. In these computer systems, one computer (the host computer) transmits images of its desktop to a plurality of remote computers using such a desktop sharing application. The remote computers may use a variety of strategies to display the host computer desktop images depending on the operating environments of the remote computers.
Windows is a well-known operating environment for computers. In this operating environment, information to be presented to a user is displayed by a desktop graphical user interface in one or more windows. Some of these windows and the desktop graphical user interface itself can contain sensitive information that is not desired to be shared with other users. Further, some portions of the desktop graphical user interface and windows provide access to functionality that is not to be shared. Presently, desktop sharing applications typically share the entire desktop, providing remote users with access to the entire content of the host's desktop and, in some instances, its entire functionality.
In computer systems that share displayed information and operate in the Windows environment, when images of the host computer desktop are transmitted to the remote computers via a conferencing server, each remote computer displays the host computer desktop image within a window. Unfortunately, displaying the host desktop image in this manner can be problematic. Such desktop sharing requires a large, stable network connection between each of the personal computers and the conferencing server, especially where other applications, such as video conferencing, are run at the same time. Where one or more remote computers suffer inadequate network connection stability and bandwidth, the remote computers can lag behind in receiving and displaying graphical information from the host computer. Current desktop sharing applications provide no indication to the presenter of such a situation.
Desktop sharing applications are also typically run in corporate computing environments that often direct all communication, both inbound and outbound, through a firewall of some kind. Depending on the policy established for the firewall, the firewall may inhibit desktop sharing applications from communicating with remote computers located on the other side of the firewall.
As will be appreciated, improvements in graphical user interfaces in environments where computers share displayed information are desired. It is therefore an object of the present invention to provide a novel method and system for sharing displayed images from a host computer on at least one remote computer in such a manner that control over what is shared is provided to the host. It is also an object of the present invention to provide a novel desktop sharing application that is aware of the state of the desktop sharing on remote computers. Further, it is an object of the present invention to provide a novel desktop sharing application that is able to communicate through firewalls.
In one aspect of the invention, there is provided, in a distributed computer network where displayed information is shared between at least two computers, a method of displaying shared images comprising the steps of: identifying image data within a selected display region of one computer that is to be shared with at least one other computer; and displaying the identified image data at said at least one other computer.
In another aspect of the present invention, there is provided, In a distributed computer network where displayed information is shared between at least two computers, a method of displaying shared images comprising the steps of: dividing image data of one computer that is to be shared with at least one other computer into a plurality of tiles; examining the image data in the tiles to determine the nature thereof; compressing the image data in the tiles using a compression methodology selected based on the determined nature; and transmitting the compressed image data to said at least one other computer for display.
In a further aspect of the present invention, there is provided a distributed computer network where displayed information is shared between at least two computers, a method of displaying shared images comprising the steps of: identifying image data of one computer that is to be shared with at least one other computer during a presentation; transmitting the identified image data to said at least one other computer for display; and providing feedback at at least one of said one and other computers concerning the position of the at least one other computer within the presentation.
In a still further aspect of the present invention, there is provided, in a distributed computer network where displayed information is shared between at least two computers, a method of displaying shared images comprising the steps of: identifying image data of one computer that is to be shared with at least one other computer during a presentation; transmitting the identified image data to said at least one other computer for display; detecting other computers that fall behind in the presentation; and forcing other computers that fell behind in the presentation to catch up.
In yet another aspect of the present invention, there is provided, in a distributed computer network, a method of inviting a user to participate in an interactive session, comprising: sending a message with a URL to the user, said URL identifying the address of a conferencing application enabling participation in the interactive session; receiving a request from the user for the conferencing application; associating the request with the session; and transmitting the conferencing application and data identifying the session to the user.
In yet another aspect of the present invention, there is provided a method of providing version control in an application, comprising: executing an original version of the application, the original version residing in a permanent location; retrieving a desired version of an application and storing the desired version in a temporary location; executing the desired version in the temporary location; terminating the execution of the original version of the application; copying the desired version over the original version at the permanent location with the executing desired version; executing the desired version at the permanent location; and terminating execution of the desired version at the temporary location.
In yet another aspect of the present invention, there is provided a method of installing components dynamically on a computer, comprising: determining with an application that a component containing functionality required by the application is not available on the computer; retrieving the component containing the required functionality with the application; and accessing the required functionality with the application.
In yet another aspect of the present invention, there is provided, in a conferencing system operating over a distributed computer network, a method of transmitting streaming video to a client from a plurality of streaming video sources, the client presenting a plurality of frames, each of the plurality of frames displaying streaming video from a separate streaming video source, the method comprising: determining if a frame associated with streaming video has been hidden; and terminating the transmission of streaming video associated with said hidden frame.
In yet another aspect of the present invention, there is provided, in a conferencing system operating over a distributed computer network, a method of transmitting streaming video to a client from a plurality of streaming video sources, the client presenting a plurality of frames, each of the plurality of frames displaying streaming video from a separate streaming video source, the method comprising: transmitting streaming video to the client from each separate streaming video source at a frame rate at least partially dependent on the size of the frame in which each separate streaming video source is displayed.
In yet another aspect of the present invention, there is provided, in a conferencing application, a method of displaying streaming video from a plurality of streaming video sources, the method comprising: presenting each of said plurality of streaming video sources in a plurality of frames, one of said frames being larger than the other of said frames; detecting when a smaller frame has been selected; and switching the position and size of said one frame and said selected smaller frame.
In yet another aspect of the present invention, there is provided, in a distributed computer network where displayed information is shared between at least two computers, a method of displaying shared images comprising the steps of: enabling a first participant to generate annotations on a shared region of a desktop of one computer; and displaying the annotations on the shared region of the desktop on a second computer.
In yet another aspect of the present invention, there is provided, in a distributed computer network where displayed information is shared between at least two computers, a method of displaying a shared desktop comprising the steps of: sharing a region of a first computer's desktop with a second computer; and modifying the display of said region at said second computer to identify displayed controls unavailable to the second computer.
In yet another aspect of the present invention, there is provided, in a distributed computer network where displayed information is shared between at least two computers, a method of displaying a shared desktop comprising the steps of: sharing a region of a first computer's desktop with a second computer; and modifying the display of said region at said second computer to identify displayed applications unavailable to the second computer.
In yet another aspect of the present invention, there is provided a desktop sharing application, comprising: a shared display region; said desktop sharing application being dynamically conditionable between a host mode, wherein said shared display region displays a shared region of the desktop of a computer upon which the desktop sharing application is executing, and a client mode, wherein said shared display region displays a shared region of the desktop of another computer executing the desktop sharing application conditioned in host mode with which said desktop sharing application is in communication.
In still yet another aspect of the present invention, there is provided, in a distributed computer network where displayed information is shared between at least two computers, a method of displaying a shared desktop comprising the steps of: sharing a region of a desktop on a first computer with a second computer; receiving by the first computer a request from the second computer to share a region of the second computer's desktop; and sharing the region of the second computer's desktop with the first computer.
Embodiments of the present invention will now be described, by way of example only, with reference to the attached drawings in which:
Turning to
Each of the personal computers 24a and 24b operates in a Windows environment and includes a desktop. As used herein, “desktop” means the graphical user interface of an operating system and applications displayed on a monitor. This includes, but is not limited to, the “desktop” of an operating system, controls such as taskbars and scroll bars, any icons and application windows.
The desktop allows information to be presented to a user in windows. Each personal computer runs a desktop sharing application that permits the personal computers 24a and 24b to share displayed information. In this particular example, the personal computers 24a and 24b run SMART Bridgit Conferencing Software. This desktop sharing application allows a conference to be set up between personal computers with one personal computer being designated as a host computer and the remaining personal computers being designated as client computers. Images of the host computer desktop are transmitted to the client computers in the conference via the conferencing server 48 and are displayed on the monitors of the client computers full screen. In the environment of
Both the host and client computers are in communication with the conferencing server 48 via SSL connections to provide security for any sensitive information being transmitted.
The frame 120 of the GUI 100 can be adjusted as desired to select the initial shared region 116 of the desktop for the conference. In this manner, the host or presenter can control the portions of the host computer's desktop that are transmitted to client computers and presented to viewers. It can be desirable in some circumstances to manipulate the frame 120 to exclude sensitive controls from the shared region, thereby ensuring that other participants are not granted access to them. Only one of the pointer option button 132 and the drawing option button 136 can be selected at one time. In this example, the pointer option button 132 is selected, indicating that pointer input will be interpreted as mouse pointer events. When the drawing option button 136 is selected, pointer input is interpreted as drawing events. The participants list button 144 can be toggled to display or hide a list of participants in the conference. In this list, the presenter is identified with the word “presenter” appearing below his name.
The presenter can optionally select to hatch or entirely hide windows associated with particular programs. For example, where an instant messaging client is installed on the presenter's computer, it can be desirable to hide message windows as sensitive and/or personal information may be contained in these windows. Also, where an application provides a distracting or erratic interface, it can be desirable to hide the application's window. A further example of an application to be hidden is the task manager that can appear in a window on the desktop as the task manager generally provides administrative control over the computer. The presenter can select to open a dialog box (not shown) that presents a list of applications presently executing and select to hide specific applications by clicking on the application name. These settings for each application can be retained until the presenter elects to modify them. While this window may not contain sensitive information, it can be desirable to hatch the window in order to prevent providing viewers potentially with remote administrative privileges on the presenter's computer in situations where remote viewers are given remote control access.
Where a viewer has been given remote control access, the viewer can interact with the shared region of the presenter's desktop. The viewer's mouse events, including button clicking and movement, are handled as if they occurred on the presenter's computer. Such movement is limited to the shared region of the desktop. A rule set is provided to handle cases where two or more participants with remote control access are moving their mice. For example, where the presenter and a viewer with remote control access are simultaneously moving their mice, the viewer's mouse events are disregarded in favor of the mouse events of the presenter. Where two viewers with remote control access are simultaneously moving their mice, the viewer who was first to move his mouse is provided control of the pointer.
The viewers can elect to display the shared region 116 in a window or full screen. In either case, the shared region can be scaled accordingly or can be displayed in its original size. In this situation, scroll bars and other like navigational controls are provided to enable the viewers to view hidden portions of the shared region.
The color of the frame 120 of the GUI 100 changes for both the presenter and the viewers to reflect the control state of the presentation. When the presenter has selected to deny remote control access to viewers, the frame 120 appears in blue to the presenter and in green to the viewers. When the presenter has selected to grant remote control access to viewers, the frame 120 appears in red to the presenter and to the viewers.
The presenter can manually position the toolbar 124 at any point along the interior edge of the frame 120. When the presenter moves the toolbar 124, the toolbar 124 displayed to the viewers tracks the presenter's toolbar's movement. This allows the presenter to control what the viewers see to ensure that important information is not hidden.
Various balloon tips stemming from the toolbar 124 are provided during the course of a conference. The balloon tips announce when a participant has joined or left the conference as well as other important events. The participant has the option to turn off these balloon tips. In addition, audio cues can be optionally used in a similar manner, either alone or in conjunction with the balloon tips.
When an invitee receives an emailed invitation, in order to join the conference, the invitee, after opening the email, simply needs to click on the conference URL link 160 presented in the email message. The conference URL link 160 refers to a file that is to be accessed via HyperText Transport Protocol (“HTTP”). As a result, the default Web browser is launched on the invitee's computer to download the specified file. When the Web browser connects to the conferencing server specified by the fully-qualified address 164, the conferencing server retrieves a browser cookie from the invitee's computer and inserts into it the address of the conferencing server 48 and the conference ID 168. The name of the browser cookie itself corresponds to the Internet address, either a fully-qualified domain name or an IP address, of the conferencing server. If the invitee's computer has never visited the conferencing server, the conferencing server will not find a corresponding browser cookie. As a result, the conferencing server creates a browser cookie and inserts into it a header identifying the cookie as storing the conferencing server's address and the conference ID, along with the address of the presenter's computer. The conferencing server then returns the browser cookie to the invitee's computer for storage in a browser cookie directory.
In addition, the conferencing server 48 returns a small loader application. When the loader application has been received by the invitee's computer and executed, it determines if the desktop sharing application has been installed on the invitee's computer. When the desktop sharing application is downloaded to a computer, it is stored by the loader application in a specific system directory. If the desktop sharing application is not detected in this system directory by the loader application, the loader application downloads the desktop sharing application from the conferencing server 48 and saves it to the specific system directory.
Once the desktop sharing application is located in the system directory, the loader application searches the directory in which browser cookies are maintained by the Web browser for the browser cookie associated with the conferencing server. As more than one conferencing server can exist, and each conferencing server is associated with a unique Internet address that is not known a priori, the loader application examines the browser cookies in the browser cookie directory in descending date order based on the modified date field until a browser cookie having a header identifying it as storing the conferencing server's address and the conference ID is located. While a Web site with which a Web browser is communicating can only retrieve its own browser cookie from the browser cookie directory of a computer, the loader application is able to access all of the cookies as it is executed locally on the invitee's computer.
When the most recently modified browser cookie that contains the conferencing server's address and the conference ID is located, the loader application reads and registers this information.
The loader application then launches the desktop sharing application via a command line command that includes the conferencing server's address and the conference ID as parameters. The desktop sharing application then uses this information to immediately connect to the conference specified by the parameters. As a result, the conference is connected to without requiring user input, such as manual entry of the conferencing server name and selection of the conference.
As the conference ID 168 is unique to the conference for which it was generated, subsequent attempts to use the information stored in the browser cookie to connect to the conference results in the desktop sharing application simply being connected to the conferencing server specified.
In addition, in this example, both the presenter and the viewer have selected “Screen Pointer” from the “Tools” sub-menu of the main menu. As a result, a labeled arrowhead pointer 208 appears in the shared region 116, the position and orientation of which correspond to the position and last movement direction of the mouse pointer of the presenter. Also, a labeled arrowhead pointer 212 appears in the shared region 116, the position and orientation of which correspond to the position and last movement direction of the mouse pointer of the viewer. Any drawing made in the shared region is scaled accordingly if a participant is viewing the shared region in a reduced-size window.
The desktop sharing application allows the role of presenter to shift to another participant in the conference.
As network bandwidth is typically the most limited resource in the field of Internet conferencing, the desktop sharing application relies on a number of methods to reduce the amount of data transmitted to and from the conferencing server 48 by the computers 24a, 24b.
The principal method used by the desktop sharing application to reduce data transmissions is the division of the shared region into tiles, referred to hereinafter as tiling. Tiling generally reduces network resource utilization in two ways. First, only data for tiles of the shared region that change during successive shared region captures is transmitted. Second, by dividing the shared region into tiles, different compression techniques can be used to encode different sections of the shared region allowing compression techniques that are best suited to encode the data to be used.
The shared region is divided up into “tiles” of fixed size, in this example 84 pixels by 84 pixels. As the shared region is divided up into tiles from left to right and from top to bottom, some smaller tiles along the right and bottom edges can result.
Screen data is captured using one of two methods. In a first method, screen changes are detected using a dynamic link library (“DLL”) named Redraw Hooks. This DLL is dynamically downloaded from the conferencing server 48 when required and hooks into window calls to report what areas of the screen have been redrawn.
In a second method, a mirror driver can be downloaded and installed. The mirror driver is a device driver that is dynamically installed to overcome issues associated with hardware acceleration. The mirror driver hooks Graphical Device Interface (“GDI”) calls and reports screen changes.
In some circumstances, the first and second methods of capturing screen data are not available. In this case, the entire screen is analyzed to determine what areas have changed.
Using one of these three methods, the shared region is monitored to detect changes therein. Updated screen information is only transmitted from the host computer to the client computers via the conferencing server 48 for tiles that have changed.
In order to reduce the amount of information being transmitted across the network, the tile image data is compressed prior to transmission. Two types of compression are employed, namely JPEG and Camtasia Studio, hereinafter referred to as Camtasia. JPEG compression is lossy but compresses high color images better than Camtasia. As a result, JPEG compression is suitable for use with photographs or complex images having a high level of detail and/or a large number of colors. Using JPEG compression can provide a significant reduction in the amount of data with little perceived effect on the quality of the image. In contrast, Camtasia compression is lossless. As a result, Camtasia is suited for preserving sharp details in a geometric image while providing a high reduction in file size. As different areas of the shared region can have significantly different content, selection of a single compression type for the entire shared region can yield poor results in some circumstances, either due to less than desirable compression or due to image data loss. By addressing each tile separately, the compression can be fine-tuned for each area of the shared region.
In addition, Camtasia compression permits image data to be sent as an initial frame, or keyframe, or, alternatively, as a delta. A keyframe is a Camtasia image that provides an initial frame of image data, or “snapshot”, representing the shared region. In the present system, the keyframe is blacked out for tiles selected for jpeg compression and is also sometimes blacked out for unchanged regions. The delta is image data representing changes in the non-jpeg tiles in subsequent frames. While the keyframe can be assembled together with the tiles selected for jpeg compression to represent a frame, a delta is applied to the last keyframe and any intermediate deltas, along with any tiles selected for jpeg compression, in order to represent a frame.
The general method 300 of compressing, sending and reconstructing frames of the shared region is illustrated in
At 330, a keyframe or delta is generated and sent by the host computer. Next, at 340, jpeg images are generated and sent for those tiles identified for jpeg compression at 310. The current frame is then reconstructed by the client computers at 350.
If the tile has changed since the last frame, the method proceeds to 416, wherein it is determined whether jpeg compression is to be used for the tile. In order to determine which compression type is to be used, for each changed tile, pixels are randomly sampled from the tile and processed using an algorithm to determine which of the two image compression types would likely yield better compression without significantly affecting the quality of the image. In particular, 32 pixels are sampled from the tile to determine if more than 12 vary in color from each other. By determining the more appropriate compression type to be used based on a small random sample of pixels, rather than by comparing the size of the image compressed using both compression types, processor utilization is reduced. It has been found that by using a random sample size of 32 pixels, the selected compression type is correct in most typical circumstances for regular desktop application use.
If high color variation is present in the tile, it is assumed that the tile is better suited for jpeg compression. At 420, the tile is copied to a jpeg region for processing at a later time. The tile is also copied to a scratch buffer at 424. A scratch buffer is a temporary location in memory used as a work area. The tile is then blacked out in the current and previous frame buffers at 428. Then, at 432, it is determined whether there are any tiles from the current frame buffer that have not been analyzed.
If, instead, it is determined that jpeg compression is not to be used for the tile at 416, the method proceeds to 436, wherein it is determined whether jpeg compression was used for the tile in the previous frame. If the tile was previously processed using jpeg compression and it has been determined that jpeg compression will not be used for the tile in the current frame, a keyframe flag is set at 440, indicating that a keyframe is to be generated. As the tile in this case had been blacked out in the previous frame, the Camtasia delta for the current frame would generally need to contain data for the entire tile as the tile had been blacked out previously. The method then proceeds to 432, wherein it is determined whether there are any files from the current frame that have not been analyzed.
If, at 432, it is determined there are unanalyzed tiles, the method returns to 404, wherein another tile is selected for analysis. Otherwise, the method ends.
If, in fact, a tile was processed using jpeg compression in the previous frame and is identified for processing using Camtasia compression in the current frame, or if the current frame is the initial frame, a keyframe is generated.
If, at 504, the keyframe flag is set, the method 320 proceeds to 508, wherein an unanalyzed tile is selected from the current frame. At 512, it is determined whether the tile has changed using the same general approach as used at 412. If the tile has changed, the method proceeds to 516, where it is determined whether there are unanalyzed tiles in the current frame.
If the tile has not changed, the method proceeds to 520, wherein the tile is copied to the scratch buffer. Then, at 524, the tile is added to the region-to-preserve, a list of tiles that have not changed. At 528, the tile is blacked out of the current frame buffer. The method then proceeds to 516, where it is determined whether there are unanalyzed tiles in the current frame. If there are unanalyzed tiles in the current frame, the method returns to 508, where another tile is selected for analysis. If there are no other tiles for analysis in the current frame, the method 320 ends.
Once each tile of the current frame has been analyzed to determine the compression type to be used, a Camtasia keyframe or delta is generated and sent.
If, at 604, it is determined that the keyframe flag has not been set, the method 330 proceeds to 612, where a Camtasia delta is generated. It is then determined if the Camtasia delta is larger than a desired threshold at 616. The threshold is set equal to one-third of the total size of the shared region as a raw image multiplied by the portion of the shared region that the Camtasia delta represents, and is selected to approximate the “break-even” point for using jpeg compression. If it is determined that the size of the Camtasia delta is smaller than the threshold at 616, the method 330 proceeds to 620, where the frame is sent to region-to-preserve. Then, at 624, the Camtasia delta is sent by the host computer to the client computers, after which the method 330 ends.
If, instead, the Camtasia delta is determined to be larger than the threshold at 616, the method 330 proceeds to 628, where a tile is selected from the frame for analysis. At 632, it is determined whether the tile has changed since the previous frame, again using the same general approach discussed with respect to 408 above. If it is determined that the tile has changed, the method proceeds to 636, where it is determined whether there remain any unanalyzed tiles. If, instead, it is determined that the tile has not changed, the tile is copied to the jpeg region at 640. Then, at 644, the tile is copied to the scratch buffer, before determining whether there remain any unanalyzed tiles at 636. If it is determined at 636 that there are unanalyzed tiles in the current frame, the method returns to 628, where another tile is selected for analysis. If there are no further tiles in the frame, the method 330 ends.
Once all of the tiles that are processed using Camtasia compression have been sent, the tiles identified for jpeg compression are compressed and sent to the client computers at 340.
Once all of the data has been compressed and sent to the client computers, the client computers must reconstruct the frame from the transmitted data. The method 350 of reconstructing the frame is better illustrated with reference to
The method then proceeds to 824, where a tile is selected. At 828, it is determined whether the tile is in the region-to-preserve. If the tile is in the region-to-preserve, the tile is copied from the scratch buffer to the current frame buffer at 832. At 836, it is determined whether there are any unanalyzed tiles. If there are, the method returns to 824, where another tile is selected. If there are no other unanalyzed tiles, the method proceeds to 840, where a jpeg is selected. At 844, the jpeg is copied into the current frame buffer. Then, the jpeg is copied from the current frame buffer to the scratch buffer at 848. At 852, it is determined whether there are any jpegs remaining to be analyzed. If there are, the method returns to 840, where another jpeg is selected. If not, the method ends.
JPEG images corresponding to tiles are cached by the desktop sharing applications. As a result, for tiles for which JPEG compression is employed, the presenter's desktop sharing application simply directs the other desktop sharing applications to reuse the same JPEG for a particular tile.
The overall conferencing experience is further improved by controlling the amount of webcam video feed data in comparison to the amount of screen data transmitted to each participant. The principal way in which this is achieved is by controlling the maximum frame-rate of webcam video that is transmitted between the participants. Further, where a number of webcam video feeds are being presented via a frame and sub-frames, it can be desirable to reduce the frame-rate transmitted for the sub-frames in relation to the frame as motion in the smaller sub-frames can be less noticeable.
It can be desirable in some cases to permit the presenter and/or viewers to control the ratio of screen data to webcam video data. Where one or more participants have poor network connectivity, the frame-rate for these participants can be adjusted accordingly or webcam sharing can be turned off altogether for them.
While these techniques enhance the overall conference experience by reducing data to be transmitted between desktop sharing applications, situations can arise where the network resources are less than desirable, causing one or more participants to lag behind in the presentation or to be disconnected altogether. The desktop sharing application provides additional functionality to address these situations.
Where one or more participants have less than desirable network connections, they may fall behind in receiving the presentation. As some of the screen data sent is in Camtasia delta format, the screen data can only be interpreted in relation to the previous set of transmitted screen data. As a result, all of the transmitted screen data must be received and interpreted sequentially, which can cause delays where network resources are diminished. In order to make the presenter aware of this situation, if it occurs, an indicator is provided to the presenter.
When the desktop sharing application running on the host computer determines that a client computer is lagging by 30 seconds or more, the desktop sharing application triggers a Camtasia keyframe to be generated and forwarded to the lagging client computer by setting the keyframe flag. The keyframe is a complete screen data frame of absolute values. As the values are absolute, the desktop sharing applications can receive the keyframe and display it immediately without performing a sequential build of the screen. At the same time, JPEG images are transmitted for any tiles that have been selected for JPEG compression where necessary (i.e. if the images are not cached by the desktop sharing application). All other pending screen changes for the lagging client computer are purged.
In addition, where a participant's desktop sharing application has been disconnected from the conference intentionally, accidentally, or as a result of limited network resources, it is desirable to start the participant at the currently displayed screen data. Upon detecting that a participant has joined the conference, the desktop sharing application generates a Camtasia keyframe and JPEG image set and transmits this information to the new participant. Upon receiving the Camtasia keyframe and JPEG image set, the participant's desktop sharing application can display the current shared region and interpret any new Camtasia delta data transmitted.
In order to allow users to quickly download the desktop sharing application, various components are bundled as dynamic link libraries that are downloaded by the desktop sharing application as they are required. For example, the mirror driver used to capture screen data is an optional component that is downloaded by the desktop sharing application as needed.
Further, language packs can be installed on the fly. If the desktop sharing application detects that it does not have a language pack for the local language of the computer upon which it is executing, or for another language selected by a user, a language pack is downloaded to present all text for menus, help files, etc. into the desired language.
While firewalls are not generally associated with reduced network resources, they can pose a connectivity issue. The desktop sharing application uses HTTP tunneling via port 80 to bypass firewall security as port 80 is typically left open to allow Web browsing.
The conferencing server also supports differing port configurations, IPv6 and IP binding to provide a flexible and robust platform for conferencing.
The desktop sharing application provides multiple monitor support, wherein a participant can choose which monitor to share if there is more than one available.
The desktop sharing application permits users to create and launch a conference.
The exit option revealed by selecting the main menu button is selected when the conference is to be terminated. In this event, the host computer's desktop sharing application ceases transmission and reception of data. All viewers in the conference are then disconnected from the exiting presenter's desktop.
The desktop sharing application is designed to be temporarily or permanently installed on a computer. After having downloaded the desktop sharing application, executing it and terminating the application, the user is presented with a dialog box requesting if the user wishes to retain access to the program permanently (i.e. “install” it). If the user selects to “install” the desktop sharing application, a shortcut is created for it and placed on the user's desktop, otherwise the program simply terminates.
In addition, the desktop sharing application is also designed to ensure that it is using a version that is compatible with the conferencing server to which it is connecting. When the desktop sharing application connects to a conferencing server, it checks to see what version the server is expecting. If the desktop sharing application is a different version than desired, the application proceeds to download the correct version. While the server typically expects the same or a later version of the desktop sharing application, in some cases, the server can expect an earlier version. Regardless of whether the version to be downloaded is earlier or later than that presently executing, the desktop sharing application downloads the expected version of the application and saves it with a temporary name in the same directory. The original application then executes the downloaded application, and proceeds to terminate itself. The temporary-named application waits until the original application has terminated and then proceeds to copy itself over the original application. Once copied, the temporary-named application then launches the properly-named latest copy of the application with the appropriate parameters to connect to the conference, thereafter terminating itself. Once the properly-named latest copy of the application has launched, it waits for the temporary-named application to terminate and then deletes it. In this manner, the desktop sharing application updates itself to the expected or correct version, regardless of whether later or earlier.
While the selection of tile size has been described with some degree of specificity, a person skilled in the art would appreciate that other sizes of tiles can be selected without significantly affecting the working of the invention. For example, the tile size can be of a number of other dimensions that would be understood by those skilled in the art to not affect the efficiency of the method significantly. It would be appreciated that, by selecting a tile size that is very small, the benefit of compression is reduced. Further, by selecting a tile size that is very large, even a one pixel change within the tile would require that updated image data be sent for the entire tile.
The default tile size can be allowed to float to permit compensation for a number of factors. For example, if the presenter resizes the shared region, an end tile that is narrow can result from the fixed tile size, thereby reducing the efficiency of compression. It may be desirable, in such circumstances, to resize the tiles in order to ensure that no tile is less than a desired size. This can be achieved by reducing the default tile size in order to increase the size of the narrow end tile or by increasing the default size in order to make the narrow end tile disappear.
Alternatively, the default tile size can be set to be a generally fixed portion of the screen. For example, a shared region of 100 by 600 pixels can be divided into 100 evenly-sized tiles of 80 by 60 pixels. If the shared region is scaled, the tile size can be scaled correspondingly.
Additionally, the tile size can be adjusted tile by tile. For example, where a window in a shared region is frequently changing whereas the remainder of the shared region is generally static, those tiles that span both the window and the remainder of the shared region can be forced to update despite that only a portion of their content has changed. It can be desirable in such cases to adjust the tile sizes to force a set of tiles to cover the size of the window such that only those tiles need be regularly updated.
In some circumstances, it can be desirable to modify the threshold at which a delta is sent as a set of jpeg images. For example, the threshold can be dynamically modified to maintain a desired ratio of tiles in a delta that are compressed using Camtasia compression.
Those of skill in the art will appreciate that other types of image compression can be used, such as gif, png, tiff, etc. Different levels of the same compression type can be used, such as different levels of jpeg compression. Further, three or more types of compression can be used to compress the tiles using two thresholds or any other scheme that would occur to a person skilled in the art.
The loader application can be stored on a separate server from the conferencing server.
The conferencing server can be a cluster of servers located in a single, physical location or can be distributed across a network.
The above-described embodiments of the invention are intended to be examples of the present invention and alterations and modifications may be effected thereto, by those of skill in the art, without departing from the scope of the invention which is defined solely by the claims appended hereto.
Number | Date | Country | Kind |
---|---|---|---|
10353785.6-41 | Nov 2003 | DE | national |
This application is a continuation application of U.S. patent application Ser. No. 11/484,153filed Jul. 10, 2006 and entitled “DESKTOP SHARING METHOD AND SYSTEM”, which is hereby incorporated herein by reference, which is a continuation application of U.S. patent Ser. No. 11/292,940, filed Dec. 1, 2005, and entitled “DESKTOP SHARING METHOD AND SYSTEM,” which is hereby incorporated herein by reference, which is a continuation application of U.S. patent application Ser. No. 10/888,793, filed Jul. 9, 2004, and entitled “DESKTOP SHARING METHOD AND SYSTEM,” which is hereby incorporated herein by reference, and which claims the benefit of U.S. patent application Ser. No. 60/577,606, filed on Jun. 8, 2004.
Number | Date | Country | |
---|---|---|---|
60577606 | Jun 2004 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11484153 | Jul 2006 | US |
Child | 11712618 | Mar 2007 | US |
Parent | 11292940 | Dec 2005 | US |
Child | 11484153 | Jul 2006 | US |
Parent | 10888793 | Jul 2004 | US |
Child | 11292940 | Dec 2005 | US |