Title of Invention	A SYSTEM AND METHOD FOR INCORPORATING AT LEAST ONE REMOTE WINDOW FROM A REMOTE DESKTOP ENVIRONMENT INTO A LOCAL DESKTOP ENVIRONMENT.
Abstract	A system for incorporating windows from remote desktop environments into a local desktop environment (14) comprises a local node, a local agent (40), a first remote node, and a first remote agent. The first remote agent provides a first remote desktop environment, and the first remote agent monitors thew first remote desktop environment for changes in the environment. The first remote node transmits messages to the local agent indicative of changes in the first remote desktop environment. The local agent receives the transmitted messages commands the local node to modify a representation of a first remote window that is part of local desktop environment. The local agent also monitors the local desktop and transmits messages to the remote agent indicative of a change in the local desktop. In some embodiments, the local node provides the local desktop environment. Local agents can be embodied on articles of manufacture.

Title of Invention

A SYSTEM AND METHOD FOR INCORPORATING AT LEAST ONE REMOTE WINDOW FROM A REMOTE DESKTOP ENVIRONMENT INTO A LOCAL DESKTOP ENVIRONMENT.

Abstract

A system for incorporating windows from remote desktop environments into a local desktop environment (14) comprises a local node, a local agent (40), a first remote node, and a first remote agent. The first remote agent provides a first remote desktop environment, and the first remote agent monitors thew first remote desktop environment for changes in the environment. The first remote node transmits messages to the local agent indicative of changes in the first remote desktop environment. The local agent receives the transmitted messages commands the local node to modify a representation of a first remote window that is part of local desktop environment. The local agent also monitors the local desktop and transmits messages to the remote agent indicative of a change in the local desktop. In some embodiments, the local node provides the local desktop environment. Local agents can be embodied on articles of manufacture.

Full Text	A SYSTEM AND METHOD FOR INCORPORATING AT LEAST ONE REMOTE WINDOW FROM A REMOTE DESKTOP ENVIRONMENT INTO A LOCAL DESKTOP ENVIRONMENT FIELD OF THE INVENTION The present invention relates to a a system and method for incorporating at least one remote window from a remote desktop environment into a local desktop environment and, in particular, to a system and method for combining display data received from various remote sources into a single, local display. Background of the Invention Client-server systems, in which a user of a client node is typically remote from a server which provides application processing or access to files and other resources, are both convenient and cost-effective. Client nodes are generally cheaper than servers, and since one server typically provides services to more than one client, overall system cost is reduced. Additionally, client-server systems allow an enterprise to make decisions regarding the location pf certain system resources (such as applications) on a situational basis. For example, certain applications may be resident solely on clients, solely on servers, solely on certain servers, or any combination of the above which, improves the overall efficiency of the systern. To date, however, efforts to combine output data from various sources into a single display have not met with success. For example, early attempts have been made to cause server- based applications to write directly into local windows. Although this method can display application output from various servers on a single display, it lacks the ability to arrange the windows on the client responsive to the z-axis ordering of the windows at each individual server. Thus, if a server brings a new window to the top of its desktop, no corresponding change appears to the user at the client Further, systems typically cannot support combining various sources of data into a single display without modification of the applications generating output data. This results because most enterprises desire to use off-the-shelf software to generate output data and such software does not support combination of output data. This represents a practical problem because re- writing such applications to support output combination is generally prohibited by the manufacturer of such software and, even if not prohibited, can be expensive. Summary of the Invention The present invention relates to a system in which multiple data displays can be represented as a cohesive, single, unitary display, without intervenrion on the pan of the user and without requiring modification of the applications generating displayed output data. The system allows a user to interact with displayed windows without knowledge of the source of those windows, and changes to the window, either locally or remotely, are reflected in the corresponding display on the server or client. In one aspect, the present invention relates to a system for incorporating windows from remote desktop environments into a local desktop environment. The system includes a local node, a local agent, a first remote node, and a first remote agent- The first remote node provides a first remote desktop environment, and the first remote agent monitors the fust remote desktop environment for changes in the environment The first remote node transmits messages to the local agent indicative of changes in the first remote desktop environment. The local agent receives the transmitted messages and commands the local node to modify a representation of a first remote window that is part of a local desktop environment. The local agent also monitors the local desktop and transmits messages to the remote agent indicative of a change in the local desktop. In some embodiments, the local node provides the local desktop environment In another aspect the present invention relates to a method for incorporating windows from remote desktop environmentsinto a local desktop environment. The method commandses the steps of: providing a local node hosting a local agent; receiving, by the local agent, a massage indicating a change to windows included in a remote desktop environment: commanding, by the local agent, the local node to effect a corresponding change in the local desktop environment; monitoring, by the local agent, the local desktop; and transmitting, by the local node, messages to the remote node indicative of a change in the local desktop environment The method may be embodied on an article of manufacture. In yet another aspect, the present invention relates to an agent which incorporates windows from remote desktop environments into a local desktop environment. The agent includes a message receiving process capable of receiving messages indicating a change has occurred in a remote desktop environment. A command process effects changes to the local desktop environment responsive to messages received by the message receiving process. A monitor process monitors local desktop events. A transmission process transmits messages indicating occurrence of the local desktop event. The agent may be embodied on an article of- manufacture. In a further aspect, the present invention relates to a system for incorporating windows from a remote desktop into a local desktop. The system comprises a local node and a remote node connected by a communications link. The communications link includes a first virtual channel and a second virtual channel. The nodes exchange desktop information such as window position, window sizt, and z-ordering of desktop windows, over the first virtual channel. The nodes exchange graphical information over the second virtual channel. In some embodiments, the first virtual channel and the second channel may be provided as a single virtual channel. Accordingly, the present invention provides a system for incorporating windows from remote desktop environments into a local desktop environment, the system comprising : a local node having a local desktop environment including a local window ; a local agent ; a first remote node having a first remote desktop environment including a first remote window ; a second remote node having a second remote desktop environment including a second remote window ; a first remote agent monitoring said first remote desktop environment and in communication with said local agent, said first remote agent transmitting a first message to said local agent indicative of one or more attributes of said first remote window relative to said first remote desktop environment; a second remote agent monitoring said second remote desktop environment and in communication with said local agent, said second remote agent transmitting a second message to said local agent indicative of one or more attributes of said second remote window relative to said second remote desktop environment; said local agent responding to said first message and said second message by commanding said local node to form a representation of said first remote window and said second remote window as part of said local desktop environment ; and a combined windows list located on said local node and based on said first and second messages, said combined windows list maintaining a z-order of said local window and said first and second remote windows, wherein a change in said z-order of any of said desktop environments is reflected in said local desktop environment. The present invention also provides a method for incorporating windows from remote desktop environments into a local desktop environment, the method comprising the steps of: (a) providing a local node hosting a local agent and a local desktop environment including a local window ; (b) providing a first remote node hosting a first remote agent and a first remote desktop environment including at least one first remote window ; (c) providing a second remote node hosting a second remote agent and a second remote desktop environment including at least one second remote window ; (d) monitoring, by the first remote agent, the first remote desktop environment and transmitting a first message to the local agent indicative of one or more attributes of the first remote window relative to the first remote desktop environment; (e) monitoring, by the second remote agent, the second remote desktop environment and transmitting a second message to the local agent indicativ of one or more attributes of the second remote window relative to the second remove desktop environment ; (f) commanding, by the local agent, the local node to form corresponding windows in the local desktop environment, the corresponding windows reflecting substantially similar attributes relative to the local desktop environment as the attributes of the windows in the remote desktop environments relative to the remote desktop environments ; and (g) maintaining a z-order corresponding to the local, first and second remote desktop environments in a combined windows list, wherein a change in the z-order of any one of the desktop environments is reflected in the local desktop environment. The present invention further provides a computer-readable article of manufacture containing a set of instructions adapted to cause a processor-based system having nodes and communication links, said set of instructions being capable of performing : a message receiving process capable of receiving messages indicative of a change in the attributes of the windows in the remote desktop environments ; a command process capable of effecting changes in corresponding windows of a local desktop environment responsive to the received messages, the corresponding windows reflecting substantially similar attributes relative to the local desktop environment as the attributes of the windows in the remote desktop environments relative to the remote desktop environments ; a combined windows list based on the received messages and maintaining a z-order for the windows in the local and remote desktop environments, wherein a change in the z-order of any of the desktop environments is reflected in the local desktop environment ; a monitor process capable of monitoring local desktop events ; and a transmission process capable of transmitting messages indicative of the desktop events. The present invention still further provides a system for incorporating windows from remote desktop environments into a local desktop environment each desktop environment including at least one window displaying graphical data, the system comprising : a communications link comprising a first virtual channel and a second virtual channel ; a local node ; a remote node ; said local node and said remote node exchanging window information over said first virtual channel of said communications link and said local node and said remote node exchanging graphical data over said second virtual channel of said communications link ; wherein said window information enables windows displayed on said local node to have substantially similar attributes relative to said local desktop environment as attributes of said windows displayed on said remote node relative to said remote desktop environment ; and a combined windows list maintaining a z-order of said local and remote desktop environments, wherein a change in said z-order of any of said desktop environments is reflected in said local desktop environment. Accordingly, the present invention provides a system for incorporating at least one remote window from a remote desktop environment into a local desktop environment, the system comprising : a first virtual channel coupled to the remote desktop environment and conveying graphical data associated with the remote window; a second virtual channel coupled to the remote desktop environment and conveying window attribute data associated with the remote window; and a local agent coupled to the remote desktop environment via the first and second virtual channels, the local agent directing the formation of a corresponding window in the local desktop environment, the corresponding window displaying the graphical data conveyed by the first virtual channel in accordance with the window attribute data conveyed by the second virtual channel. The present invention also provides a method incorporating at least one remote window from a remote desktop environment into a local desktop environment, the method comprising the step of : receiving graphical data associated with the remoted window via a first virtual channel coupled to the remote desktop environment; receiving window attribute data associated with the remote window via a second virtual channel coupled to the remote desktop environment; and forming a corresponding window in the local desktop environment, the corresponding window displaying the graphical data received from the first virtual channel in accordance with the window attribute data received from the second virtual channel. The present invention further provides a system for incorporating at least one remote window from a remote desktop environment into a local desktop environment, the system comprising : a first virtual channel coupled to the local desktop environment and conveying graphical data associated with the remote window; a second virtual channel coupled to the local desktop environment and conveying window attribute data associated with the remote window; and a remote agent associated with the remote desktop environment and coupled to the local desktop environment via the first and second virtual channels, the remote agent transmitting messages to the local desktop environment directing the formation of a corresponding window in the local desktop environment, the corresponding window displaying the graphical data conveyed by the first virtual channel in accordance with the window attribute data conveyed by the second virtual channel. The present invention still further provides a method of incorporating at least one remote window from a remote desktop environment into a local desktop environment, the method comprising the steps of : transmitting graphical data associated with the remote window via a first virtual channel coupled to the local desktop environment; transmitting window attribute data associated with the remote window via a second virtual channel coupled to the local desktop environment; and transmitting messages to the local desktop environment directing the formation of a corresponding window in the local desktop environment, the corresponding window displaying the graphical data transmitted via the first virtual channel in accordance with the window attribute data transmitted via the second virtual channel. Brief Description of the accompanying Drawings The invention is pointed out with particularity in the appended claims. The advantages of this invention described above, and further advantages, may be better understood by reference to the following description taken in conjunction with the accompanying drawings, in which: FIG. 1 is a functional block diagram of an embodiment of a client-server system; FIG. 2 is a functional block diagram of a client node connected to two separate server nodes; FIG. 3 is a flow diagram of the steps to be taken when a server agent detects a change in its associated desktop environment. IG. 4 is a flow diagram of the steps to be taken when a client agent detects a change in its associated desktop environment; FIG. 5 is a flow chart of the steps to be taken to open a virtual channel between a client agent and a server agent; and FIG. 6 is a functional block diagram of an agent. Detailed Description of the Invention Referring now to Fig. 1, a clienl-server-system is shown in which server node 20 provides services for one or more client nodes 10. Client nodes may communicate with server node 20 via any of a number of industry-standard data communications protocols including, but not limited to, TCP/IP. IPX/SPX, NetBEUI, or serial protocols. Alternatively, client nodes 10 may connect to server node 20 using a proprietary data communications protocol such as the ICA protocol manufactured by Citrix Systems, Inc. of Fort Lauderdale, Florida or the RDP protocol manufactured by Microsoft Corporation of Redmond. Washington. The actual connection between the client nodes 10 and the server node 20 may be physical cabling or it may be a wireless connection, such as infrared transmission. Fig. 1 depicts a system in which a single client node 10 is connected to more than one server node 20, 20'. As shown in Fig. 2, client node 10 has an associated display 12. The display 12 may be used to display one or more components of a graphical user interface, such as windows and pull-down menus. The collection of graphical user interface components displayed to a user by the display 12 is generally referred to as the "desktop." As shown in Fig. 2, the local node 10 displays a local desktop environment 14 to a user. Local node 10 may provide at least a part of the local desktop environment 14 or local node 10 may simply display various desktop components received from other sources such as server nodes 20. As shown in Fig, 2, each server node 20, 20' has an associated display 22, 22' which also displays a desktop environment 24, 24'. It should be noted that display 22, 22' need not be a video display monitor. For example, display 22, 22' may simply be a bank of video RAM to which applications write the output of graphical procedure calls. Fig. 2 depicts an embodiment of a system in which each server node display 22, 22' displays one graphical user interface window 26, 27'. Each server 20, 20' also includes at least one agent 30, 30'. In particular embodiments, each server 20, 20" includes one agent 30, 30' for each client 10 connected to the server 20, 20'. Client node 10 may also host an agent 40. In some embodiments, a client node 10 hosts a separate local agent 40 for each server to which the client node 10 is connected. In other embodiments, the client node 10 hosts a single agent 40 that manages connections to multiple server nodes 20. Each of the agents 30, 30', 40 may monitor their associated desktop environment 24, 24', 14 for windows which: change position; are opened; are closed; change size; are minimi2ed; are maximized; ot arc brought to the top of the desktop, i.e., windows which gain focus that do not previously have focus. Each agent 30, 30', 40 transmits messages indicative of changes in their associated desktop 24, 24', 14 to other agents. For example, local agent 40 may receive messages transmitted from server node agents 30, 30'. The local agent 40 commands the client 10 to modify the local desktop environment 14 in response to the messages received from server agents 30, 30', that is. the local agent 40 issues commands to the client node 10 to conform the local desktop environment 14 to the server desktop environment 24. In other embodiments, server node agents 30, 30' receive messages from a local agent 40 and command the server 20, 20' to modify the server desktop environment 24, 24' in response 10 messages received from the local agent 40. In one embodiment, the agents 30, 40 monitor changes to their associated desktop environment 24, 24' by periodically issuing one or more of a set of commands provided by the operating system that allow details of the graphical user interface desktop to be determined. For embodiments in which the agents 30, 40 reside on nodes that execute a version of the WINDOWS operating system, the agents 30, 40 may periodically issue the Enum Windows command to the WINDOWS operating system, which returns a list of all windows present on the desktop, together with information related to those windows. The agents 30, 40 can issue the Enum Windows command every 50 milliseconds, every 100 milliseconds, every 500 milliseconds, or at any period that allows the agent 30. 40 to rapidly determine when changes to its associated desktop environment have occurred without putting a significant computational burden on the node. In this embodiment, the agent 30, 40 maintains a data structure storing information about the desktop windows and compares the values returned by the EnumWindows command to the data structure to determine changes. Information determined and stored by the agent 30, 30' can include the title bar associated with each window, the location of each window in the desktop environment 24, 24', the size of each window, and the z-order positioning of each window in the desktop environment 24, 24'. In another embodiment the agent 30, 30', 40 monitors an intranode graphics message queue to determine changes to its associated desktop environment. Server agents 30, 30' monitor an intraserver message queue and local agent 40 monitors an intraclient message queue. In this embodiment, changes to the desktop environment 24, 24' are effected via messages, sent to a graphics subsystem from system applications or the operating system itself. Thus, an application executing an a server 20, 20' would send a message to a graphics engine residing on the server 20, 20' in order to change the server desktop environment 24, 24'. Other commands which return graphical user interface data are readily apparent to those of ordinary skill in the an. For embodiments in which the agents 30, 40 reside on nodes executing a version of the WINDOWS operating system, the agents 30, 40 monitor the Windows Message Queue for messages affecting the desktop environment associated with the node on which the agent resides. Examples of such messages include; WM_SETFOCUS, which indicates to which window focus will be given (i.e., brought to the "top" of the desktop); WM_CILLFOCUS, which removes focus from an indicated window; and WM_WINDOWPOSCHaNGING, which indicates a change in the position of a window. Other messages that can be posted to the Windows Message Queue are readily known to those of ordinary skill in the art. Referring now to Fig. 3 . the steps taken during a server-initiated event are shown. The server agent 30 senses a change in its associated desktop (step 302). The server agent 30 may do this by intercepting a window event on the server message queue, or the agent 30 may determine a change in the desktop by comparing the results returned from serially issued operating system commands, as described above. The server agent 30 sends a message to a client agent 40 indicating the change in the server desktop 24 (step 304). For example, if a new window has been given focus, the server agent 30 can transmit a message to a client agent 40 indicating the identity of the new "top" window. In one embodiment, the server agent 30 broadcasts its message to all client agents 40 that exist in the system. Alternatively, the server agent 30 may transmit its message only to a predetermined subset of client agents 40. For example, when a client 10 makes a connection to a server 20, the client agent 40 may register with the server agent 30. In this embodiment, the server agent 30 would transmit change messages only to those client agents that have registered with the server. The client agent 40 receives the transmitted message (step 306). In embodiments in which the server broadcasts commands, the client agent 40 must have some mechanism for determining whether a transmitted command affects its associated desktop 12. For example, the client agent 40 may maintain a list of servers to which it is connected. In these embodiments, the client agent 40 responds to messages broadcast by any server present in its list. For embodiments in which the server agent 30 does not broadcast messages, no such mechanism is necessary. The client agent 40 implements a change to its associated desktop 14 responsively to the received message (step 308). The client agent 40 may accomplish this by directly issuing graphics Application Programming Interface commands that cause the client 10 to change the display of its associated desktop 14. Alternatively, the client agent 40 may issue GDI commands to change its associated desktop 14. In still other embodiments, the client agem 40 issues commands directly to the system, whether implemented in hardware or software, responsible for displaying graphics on the client 10. Referring now to Fig. 4, the steps taken when a client initiates a desktop change are shown. The client agent 40 senses a change in its associated desktop 14 (step 402). As noted above, this may be done on an event-driven basis or by polling the operating system operating on the client 10. The client agent 40 determines to which server 20 the affected window belongs (siep 404). To facilitate this process, the client agent 40 may maintain a list that associates remote windows with a particular server 20. The client agent 40 then sends a message to the identified server 40 indicating the change in its desktop 14 (step 406). Alternatively, the client agem 40 may skip step 404 entirely and broadcast its change message to all servers 20. The server agent receives the transmitted message (step 408) and implements the change in its associated desktop (step 410), as described above. In one particular embodiment, a client node 10 and a server node 20 communicate using the ICA protocol and the client node 10 and the server node 20 execute a version of the WINDOWS operating system. Client node 10 hosts a local agent 40 that may be provided as a dynamically linked library module. The server node 20 hosts a server agent 30 that may be provided as a separate thread. In this embodiment, the local agent 40 and the server agent 30 exchange graphical data, i.e., the data actually displayed in each window on the desktop, via a first ICA virtual channel. Information about window positioning, window size, z-access ordering of window and other such information is communicated between the client node 10 and the server node 20 via a second ICA virtual channel. Throughout the description, when the client node 10 and the server node 20 are actively exchanging information via the second ICA virtual channel, the client will be referred to as being in "seamless windowing mode." Referring now to Fig. 5, the process for enabling seamless windowing mode between the local agent 40 and server agent 30 is shown. In this embodiment, all communication between a server agent and a client agent is packet-oriented and takes place over a dedicated ICA virtual channel, making the functioning of the agents 30, 40 independent from the underlying communication protocol. All packets start with packet type (1 byte), followed by packet data length (2 bytes, can be zero) and data (optional). Agents 20, 40 will uy to send as much data in a single network packet as possible, but it will always send complete packets. That is, the size of seamless window virtual packets never exceeds the allowable size of an ICA packet. Packet flow control and delivery confirmation is implemented by the transport level of the ICA protocol. Individual packets are executed immediately on reception. The client agent 40 waits for an initial packet from the server agent 30. After user logon 10 the server, a server agent 30 will be invoked (step 504). The server agent sends a TWI_PACKET_START packet to the client agent 40, which includes some essential information about the server desktop environment (desktop resolution, desktop size, version number of ICA protocol supported by the server, etc.) (step 506). This packet is sent by the server agent 30 on initial connection or on reconnect, and is used to: (1) detect seamless windowing capabilities of the client; and (2) requests basic client information. The client agent receives the TWI_PACKET_START packet (step 507) and responds with a TWI_PACKET_C2H_START_ACK packet, confirming TWI_PACKET_START and supplying client version/capabilities information (step 508). This packet is sent by the cliem agent 40 to confirm reception of TWI_PACKET_START packet and to send the requested basic client information to the server agent 30. If there is no response from the client agent 40 (step 509), the server agent 30 assumes that the client is unable to enter seamless windowing mode, and the seamless windowing virtual channel is not used by the server node 20 to communicate window information. In this case, the server node 20 continues to communicate graphical data to the client node 10 via another virtual channel, and the client desktop displays the server desktop without incorporating windows from other nodes. The client agent 40 uses the information sent by the server agent 30 in step 506 to determine if a seamless windowing session can be established between the server agent 30 and the client agent 40. In one embodiment. The client agent 40 compares information relating to the version of the virtual channel protocol supported by the server agent 30 to makes the determination If the client agent 40 determines that it is possible to enable seamless windowing mode (step 510), the client agent 40 sends a TWI_PACKET_C2H_OPEN packet to the server agent 30 (step 511). This packet requests that the server agent 30 enable seamless windowing mode. On reception of a TWI_PACKET_C2H_OPEN packet (step 512) the server agent 40 (I) resets its internal data structures, (ii) sends a TW1_PACKET_SYSINFO packet to the client agent 40 to communicate some general information regarding the window settings on the server node 20 to the client agenl 40. (iii) sends a TWI_PACKET_OPEN packet to the client agent 40 (step 514) indicating the establishment of seamless windowing mode, and (iv) enables its main polling loop (step 516) that will poll the operating system on the server node for desktop changes. If the client agent 40 and the server agent 30 do not support the same version of the seamless window protocol, the server agent 30 ignores the TWI_PACKET_C2H_OPEN packet. On reception of TWI_PACKET_OPEN packet (step 520), the client agent 40 resets its internal data structures (step 522) and seamless windowing mode between the client agent 40 and the server agent 30 is established. During a seamless windowing mode session, the server agent 30 will send window information such as window position, size, styles, window text, etc. for all top-level windows on the server node. Also, foreground window information is sent, i.e. which window on the server node desktop is the foreground window. In accordance with this information, the client agent 40 creates windows with the same size/position as the server node windows on the client node desktop. In some embodiments, window elements are transmitted as bitmaps from the server node.20. Examples of packets sent by the server agent 30 include : TWI_PACKET_CLOSE. which is sent to switch the client agent 40 out of seamless windowing mode and back to regular, or full screen, mode; that is, the client node 10 is switched back to displaying the server node desktop environment without incorporating windows from other desktop environments; TWI_PACKET_CREATEW, which is sent to create new windows on the client node 10; TWI_PACKET_DELETEW, which is sent to destroy a window on the client node 10; TWI_PACKET_CHANGEW, which is sent to change & window displayed by the local node 10; TWI_PACKET_SYSINFO, which is sent to report server node 20 system settings - normally it is sent only once, but the packet can be sent multiple times; TWI_PACKET_FOREGROUNDW, which is sent during normal seamless windowing mode operation to change the foreground window, TWI_PACKET_SETTOPW, which is sent during normal seamless windowing mode operation to change the top window, that is, to bring a new window to top; TWI_PACKET_SETFOCUS, which is sent during normal seamless windowing mode operation to change the focus window; TWI_PACKET_FOCUSACK, which is sent in response to TWI_PaCKET_C2H_SETFOCUS (see below), and reports me result of a SetFocus attempt; and' TWI_PACKET_SPA_STATUS, which is sent in response to TWI_P ACKET_C2H_START_PUBLICAPP (see below), and is used to report the result of the requested operation Examples of packets that can be sent by the client agent 40 to the server agent 30 include : TWI_PACKET_C2H_PAUSE, which is sent to suspend the server agent 30. that is, the server agent 30 will stop sending window information, clear its internal data structure and send a TWI_PACKET_CLOSE packet (see above); TWI_PACKET_C2H_RESUME, which is sent to resume the server agent 30 -- the server agent 30 will clear its internal data structure, and send a TWI_PACKET_OPEN packet (see above); TWI_PACKET_C2H_SETPOS, which is sent to report window size/position change on the client node; TW1_PACKET_C2H_SETFOCUS, which is sent to report a change in the focus window on the client node; TWI_PaCKET_C2H_RESTORE, which is sent to request restoration of a minimized window; TWI_PaCKET_C2H_TERMINATE, which is sent to request, termination of a program executing on the server node 20; TWI_PaCKET_C2H_STARTAPP, which is sent to start a new application on the server node 20; TWI_PACKET_C2H_LOGOUT. which is sent to end the current session: TWI_PaCKET_C2H_START_PUBLICaPP, which is sent to start a new published application on the server node; and TWI_PACKET_C2H_CLIENTINFO, which is sent to report client desktop settings to the server agent 30 — this packet is generally sent on startup, but can also be used during seamless windowing session. The client agent 40 will try to perform some operations (such as window move and resize) locally, sending update information back to the server node 40 afterwards. Proper window behavior is emulated by intercepting the WM_NCHITTEST message for the client- created windows. Foreground window changes can happen on both the client node and the server node, so the client and server will negotiate and balance actual foreground window changes. For example, if the server node 20 changes its foreground window, that change should be properly represented on the client desktop. The server agent 30 sends information regarding the new foreground window to the client agent 40 using the TWI_PACKET_FOREGROUNDW packet Similarly, if the client agent 40 detects a foreground window change on the cliem desktop, the client agent 40 sends information regarding the change to the server agent 30 and the server agent 30 implements the change on the server desktop. When focus is taken away from a window representing a server window and is given to a local client window, the client notifies the server of the change and the server gives focus to an invisible window. For embodiments in which the client node 10 is connected to two server nodes 20, and focus is shifted from a window representing a window from the first server and is given to a window representing a window from the second server, the client sends a packet informing the current server that its window no longer has focus. Once the server responds by giving focus to an invisible window, the client agent 40 instructs the other server that its window now has focus on the local desktop. In some embodiments, it is desirable to add some complexity to the agent's main polling loop to reduce network traffic. In these embodiments, the main polling loop includes a comparison between the current foreground window and the identity of the window last requested to be moved to the foreground. If the current foreground window matches the window identified in the most recent request, the agent does not need to send information acknowledging the change. This technique is useful in both server agent 30 and client agents 40. Window z-ordering on the client is a superset of the server node z-ordering (client will always have more windows than the host). Server node z-ordering is reproduced on the client by reproducing owner/owned relationship among windows and the TOPMOST flag in. the window style. Owner/owned relationships refer to windows which are children of other windows, such as dialog boxes associated with application windows. The dialog box is said to be owned by the application window, and the dialog box will always appear on top of its owner. The TOP_MOST flag indicates that a particular window should appear on "top" of the desktop, for example, the status bar in WINDOWS 95. When a user disconnects, the server agent 30 switches itself to suspended mode, and will not send information to the client agent 40. On a reconnect, the server agent 30 sends a TWI_PACKET_STaRT packet, reporting HostAgentState as "already running, reconnect" Based on the version number of the protocol supported by the server the client will decide whether it is possible to enable seamless windowing mode (from the client point of view). If it is possible to switch to seamless windowing mode, the client agent 40 will send a TWI_PACKET_C2H_OPEN packet, asking the server agent 30 to enable seamless windowing mode. Each agent responsible for monitoring an associated desktop may be implemented as a stand-alone software routine (such as an executable file on DOS-based systems), a dynamically linked library routine (DLL), or as an integral piece of the operating system. Referring now to FIG. 6, and in brief overview, each agent includes a message receiving facility 602. a command facility 604, a monitor facility 606. and a message transmission facility 608. Agent-agent communication is full-duplex, i.e., agents can transmit and receive messages simultaneously. Thus, each facility can be implemented as a separately functioning code segment that operates independently of the other facilities. For example, message receiving facility 602 and command facility 604 can be implemented as separate threads which communicate with each other via a named pipe or shared memory. Use of a common data allows the message receiving facility 602 and the message transmitting facility 608 to be synchronized. Message receiving facility 602 receives messages transmitted from other agents indicating changes in the desktop environments associated with those agents. Message receiving facility 602 may connect directly with the physical layer of the communications protocol the agents use to communicate, or the message receiving facility 602 may operate at a higher layer of the protocol by cooperating with one or more communications subsystems. For embodiments in which messages are broadcast by agents, the message receiving facility 602 has some mechanism for determining whether a broadcast message is intended for it For example, the message receiving facility 602 may store a list of the windows which its associated desktop displays. The message receiving facility 602 would compare the target of any received message to its list of windows to determine whether or not to take action on the received message. The message receiving facility may be implemented as a blocking function. Alternatively, the message receiving facility can be implemented a call-back function invoked by the ICA virtual channel Transport Once the message receiving facility 602 has determined that a received message is intended for its desktop, the command facility is invoked to effect the change indicated by the message to the associated desktop environment The command facility 604 may be passed the received message facility, or the message receiving facility 602 may process the received message before communicating with the command facility 604. The command facility 604 may implement the desktop change indicated by the received message by issuing GDI commands. In other embodiments, the command facility 604 may issue commands directly to an associated graphics subsystem or may issue other graphics API commands. During a seamless windowing session, a number of desktops are associated with a single- client node - one desktop on the client itself and one desktop per server node 20 to which the client node 10 is connected. The client agent 40, in conjunction with the server agent 30, 30 creates a combined window list representing the z-order of all desktops. All participating desktops are 'linked" together by the client agents 40 and the server agents 30, 30', and any z- order changes on any desktops will be propagated to other desktops. In one embodiment, each server has knowledge only of its own graphical desktop representation and the server desktops are individually represented within the client. The client display is updated by combining all server and client desktop images into a single display image based on the window information that has been obtained from each server node 20, 20' by the client agent 40. The resulting image is displayed at the client node 10. The combining process involves building a common window list based on the windows information exchanged by all agents. Using the combined window list, the graphical desktop data is clipped and merged for representation by the client node 10. The node takes care of "clipping" displayed windows resulting from the commands issued by the command facility 604. Such "clipping" functions are well-known to those of ordinary skill in the art. In some embodiments, however, the command facility 604 maintains a shadow bitmap of clipped windows. That is, the command facility 604 maintains a bit image of windows that are obscured by other windows. This allows the agent to change its associated desktop without requiring it to reload the window image of an obscured window from the appropriate source. In other embodiments, the node determines whether graphical data is obscured at the time it is received. If it is, the node ignores the received graphical data. If it is not, the node displays the data. The node makes a determination as to whether the graphical data is obscured by applying clipping functions. Monitoring facility 606 monitors the desktop associated with the agent. Monitoring facility 606 may monitor the desktop by periodically issuing commands provided by the operating system executing on the node which return information about the node's desktop. Alternatively, the monitoring facility 506 may watch for messages posted to an intranode message queue. As noted above, in one particular embodiment the monitoring facility 606 monitors the Windows Message Queue. Once a desktop change occurred, the message transmission facility 608 transmits a message indicating the change that has occurred. In some embodiments, the message transmission facility 608 broadcasts notification of the change. In one embodiment, message transmission facility 608 can be implemented in the form of non-blocking function, that can be called from any window procedure. If the function can not send a data packet immediately (for example, the communication subsystem has no buffer space), a timer will be set and retry attempts will be done until the send succeeds. The present invention may be provided as one or more computer-readable programs embodied on or in one or more articles of manufacture. The article of manufacture may be a floppy disk, a hard disk, a CD ROM. a flash memory card, a PROM, a RAM. a ROM, or a magnetic tape. In general, the computer-readable programs may be implemented in any programming language. Some examples of languages that can be used include C. C++, or JAVA. The software programs may be stored on or in one or more articles of manufacture as object code. Having described certain embodiments of the invention, it will now become apparent to one of skill in the art that other embodiments incorporating the concepts of the invention may be used. Therefore, the invention should not be limited to certain embodiments, but rather should be limited only by the spirit and scope of the following claims. WE CLAIM : 1. A system for incorporating at least one remote window from a remote desktop environment into a local desktop environment, the system comprising : a first virtual channel coupled to the remote desktop environment and conveying graphical data associated with the remote window; a second virtual channel coupled to the remote desktop environment and conveying window attribute data associated with the remote window; and a local agent coupled to the remote desktop environment via the first and second virtual channels, the local agent directing the formation of a corresponding window in the local desktop environment, the corresponding window displaying the graphical data conveyed by the first virtual channel in accordance with the window attribute data conveyed by the second virtual channel. 2. The system as claimed in claim 1, comprising a combined windows list being formed and maintained by the local agent, the combined windows list representing a modifiable z-order of the corresponding window in the local desktop environment. 3. The system as claimed in claim 1, wherein the window attribute data associated with the remote window and conveyed by the second virtual channel contains the size and z-order of the remote window. 4. The system as claimed in claim 1, comprising a local operating system forming the local desktop environment, the local agent periodically polling the local operating system to detect an attribute change in the corresponding window, wherein the local agent transmits a message to the remote desktop environment indicative of the attribute change. 5. The system as claimed in claim 1, wherein the corresponding window exhibits window attribute data substantially similar relative to the local desktop environment as the window attribute data of the remote window relative to the remote desktop environment. 6. The system as claimed in claim 1, comprising a plurality of communication links coupling the local desktop environment with a plurality of remote desktop environments, the communication links comprising first and second virtual channels conveying graphical and window attribute data associated with remote windows from the plurality of remote desktop environments to the local agent, wherein the local agent forms corresponding windows in the local desktop environment corresponding to each of the plurality of remote windows. 7. A method/incorporating at least one remote window from a remote desktop environment into a local desktop environment, the method comprising the step of: receiving graphical data associated with the remoted window via a first virtual channel coupled to the remote desktop environment; receiving window attribute data associated with the remote window via a second virtual channel coupled to the remote desktop environment; and forming a corresponding window in the local desktop environment, the corresponding window displaying the graphical data received from the first virtual channel in accordance with the window attribute data received from the second virtual channel. 8. The method as claimed in claim 7, comprising the step of forming a combined windows list storing at least some of the window attribute data. 9. The method as claimed in claim 7, comprising the steps of: polling a local operating system associated with the local desktop environment to detect an attribute change in the corresponding window; and transmitting a message to the remote desktop environment indicative of the detected attribute change. 10. The system as claimed in claim 7, wherein the corresponding window exhibits window attribute data substantially similar relative to the local desktop environment as the window attribute data of the remote window relative to the remote desktop environment. 11. A system for incorporating at least one remote window from a remote desktop environment into a local desktop environment, the system comprising : a first virtual channel coupled to the local desktop environment and conveying graphical data associated with the remote window; a second virtual channel coupled to the local desktop environment and conveying window attribute data associated with the remote window; and a remote agent associated with the remote desktop environment and coupled to the local desktop environment via the first and second virtual channels, the remote agent transmitting messages to the local desktop environment directing the formation of a corresponding window in the local desktop environment, the corresponding window displaying the graphical data conveyed by the first virtual channel in accordance with the window attribute data conveyed by the second virtual channel. 12. The system as claimed in claim 11, comprising a combined windows list formed in response to the messages transmitted by the remote agent and containing at least some of the window attribute information conveyed via the second virtual channel. 13. The system as claimed in claim 11, wherein the window attribute data associated with the remote window and conveyed by the second virtual channel contains the size and z-order of the remote window. 14. The system as claimed in claim 11, comprising a remote operating system forming the remote desktop environment, the remote agent periodically polling the remote operating system to detect an attribute change in the remote window, wherein the remote agent transmits a message to the local desktop environment indicative of the attribute change. 15. The system as claimed in claim 11, wherein the corresponding window exhibits window attribute data substantially similar relative to the local desktop environment as the window attribute data of the remote window relative to the remote desktop environment. 16. The system as claimed in claim 11, comprising a plurality of communication links coupling the remote desktop environment with a plurality of local desktop environments, the communication links comprising first and second virtual channels conveying graphical and window attribute data associated with the remote window from the remote desktop environment to the plurality of local desktop environments, wherein the local desktop environments from corresponding windows corresponding to the remote window. 17. A method of incorporating at least one remote window from a remote desktop environment into a local desktop environment, the method comprising the steps of: transmitting graphical data associated with the remote window via a first virtual channel coupled to the local desktop environment; transmitting window attribute data associated with the remote window via a second virtual channel coupled to the local desktop environment; and transmitting messages to the local desktop environment directing the formation of a corresponding window in the local desktop environment, the corresponding window displaying the graphical data transmitted via the first virtual channel in accordance with the window attribute data transmitted via the second virtual channel. 18. The system as claimed in claim 17, comprising the step of forming a combined windows list storing at least some of the window attribute data in response to the transmitted messages. 19. The system as claimed in claim 17, comprising the steps of: polling a remote operating system associated with the remote desktop environment to detect an attribute change in the remote window; and transmitting a message to the local desktop environment indicative of the detected attribute change. A system for incorporating windows from remote desktop environments into a local desktop environment (14) comprises a local node, a local agent (40), a first remote node, and a first remote agent. The first remote agent provides a first remote desktop environment, and the first remote agent monitors thew first remote desktop environment for changes in the environment. The first remote node transmits messages to the local agent indicative of changes in the first remote desktop environment. The local agent receives the transmitted messages commands the local node to modify a representation of a first remote window that is part of local desktop environment. The local agent also monitors the local desktop and transmits messages to the remote agent indicative of a change in the local desktop. In some embodiments, the local node provides the local desktop environment. Local agents can be embodied on articles of manufacture.

Full Text

A SYSTEM AND METHOD FOR INCORPORATING AT LEAST
ONE REMOTE WINDOW FROM A REMOTE DESKTOP
ENVIRONMENT INTO A LOCAL DESKTOP ENVIRONMENT
FIELD OF THE INVENTION
The present invention relates to a a system and method for incorporating at least
one remote window from a remote desktop environment into a local desktop environment
and, in particular, to a system and method for combining display data received from
various remote sources into a single, local display.
Background of the Invention
Client-server systems, in which a user of a client node is typically remote from a server
which provides application processing or access to files and other resources, are both convenient
and cost-effective. Client nodes are generally cheaper than servers, and since one server
typically provides services to more than one client, overall system cost is reduced. Additionally,
client-server systems allow an enterprise to make decisions regarding the location pf certain
system resources (such as applications) on a situational basis. For example, certain applications
may be resident solely on clients, solely on servers, solely on certain servers, or any combination
of the above which, improves the overall efficiency of the systern.
To date, however, efforts to combine output data from various sources into a single
display have not met with success. For example, early attempts have been made to cause server-
based applications to write directly into local windows. Although this method can display
application output from various servers on a single display, it lacks the ability to arrange the
windows on the client responsive to the z-axis ordering of the windows at each individual server.
Thus, if a server brings a new window to the top of its desktop, no corresponding change appears
to the user at the client
Further, systems typically cannot support combining various sources of data into a single
display without modification of the applications generating output data. This results because
most enterprises desire to use off-the-shelf software to generate output data and such software
does not support combination of output data. This represents a practical problem because re-
writing such applications to support output combination is generally prohibited by the
manufacturer of such software and, even if not prohibited, can be expensive.
Summary of the Invention
The present invention relates to a system in which multiple data displays can be
represented as a cohesive, single, unitary display, without intervenrion on the pan of the user and
without requiring modification of the applications generating displayed output data. The system
allows a user to interact with displayed windows without knowledge of the source of those
windows, and changes to the window, either locally or remotely, are reflected in the
corresponding display on the server or client.
In one aspect, the present invention relates to a system for incorporating windows from
remote desktop environments into a local desktop environment. The system includes a local
node, a local agent, a first remote node, and a first remote agent- The first remote node provides
a first remote desktop environment, and the first remote agent monitors the fust remote desktop
environment for changes in the environment The first remote node transmits messages to the
local agent indicative of changes in the first remote desktop environment. The local agent
receives the transmitted messages and commands the local node to modify a representation of a
first remote window that is part of a local desktop environment. The local agent also monitors
the local desktop and transmits messages to the remote agent indicative of a change in the local
desktop. In some embodiments, the local node provides the local desktop environment
In another aspect the present invention relates to a method for incorporating windows
from remote desktop environmentsinto a local desktop environment. The method commandses the
steps of: providing a local node hosting a local agent; receiving, by the local agent, a massage
indicating a change to windows included in a remote desktop environment: commanding, by the
local agent, the local node to effect a corresponding change in the local desktop environment;
monitoring, by the local agent, the local desktop; and transmitting, by the local node, messages
to the remote node indicative of a change in the local desktop environment The method may be
embodied on an article of manufacture.
In yet another aspect, the present invention relates to an agent which incorporates
windows from remote desktop environments into a local desktop environment. The agent
includes a message receiving process capable of receiving messages indicating a change has

occurred in a remote desktop environment. A command process effects changes to the local
desktop environment responsive to messages received by the message receiving process. A
monitor process monitors local desktop events. A transmission process transmits messages
indicating occurrence of the local desktop event. The agent may be embodied on an article of-
manufacture.
In a further aspect, the present invention relates to a system for incorporating windows
from a remote desktop into a local desktop. The system comprises a local node and a remote
node connected by a communications link. The communications link includes a first virtual
channel and a second virtual channel. The nodes exchange desktop information such as window
position, window sizt, and z-ordering of desktop windows, over the first virtual channel. The
nodes exchange graphical information over the second virtual channel. In some embodiments,
the first virtual channel and the second channel may be provided as a single virtual channel.
Accordingly, the present invention provides a system for incorporating windows
from remote desktop environments into a local desktop environment, the system
comprising : a local node having a local desktop environment including a local window
; a local agent ; a first remote node having a first remote desktop environment
including a first remote window ; a second remote node having a second remote
desktop environment including a second remote window ; a first remote agent
monitoring said first remote desktop environment and in communication with said local
agent, said first remote agent transmitting a first message to said local agent indicative
of one or more attributes of said first remote window relative to said first remote
desktop environment; a second remote agent monitoring said second remote desktop
environment and in communication with said local agent, said second remote agent
transmitting a second message to said local agent indicative of one or more attributes
of said second remote window relative to said second remote desktop environment;
said local agent responding to said first message and said second message by
commanding said local node to form a representation of said first remote window and
said second remote window as part of said local desktop environment ; and a
combined windows list located on said local node and based on said first and second
messages, said combined windows list maintaining a z-order of said local window and
said first and second remote windows, wherein a change in said z-order of any of said
desktop environments is reflected in said local desktop environment.
The present invention also provides a method for incorporating windows from
remote desktop environments into a local desktop environment, the method
comprising the steps of: (a) providing a local node hosting a local agent and a local
desktop environment including a local window ; (b) providing a first remote node
hosting a first remote agent and a first remote desktop environment including at least
one first remote window ; (c) providing a second remote node hosting a second
remote agent and a second remote desktop environment including at least one
second remote window ; (d) monitoring, by the first remote agent, the first remote
desktop environment and transmitting a first message to the local agent indicative of
one or more attributes of the first remote window relative to the first remote desktop
environment; (e) monitoring, by the second remote agent, the second remote desktop
environment and transmitting a second message to the local agent indicativ of one or
more attributes of the second remote window relative to the second remove desktop
environment ; (f) commanding, by the local agent, the local node to form
corresponding windows in the local desktop environment, the corresponding windows
reflecting substantially similar attributes relative to the local desktop environment as
the attributes of the windows in the remote desktop environments relative to the
remote desktop environments ; and (g) maintaining a z-order corresponding to the
local, first and second remote desktop environments in a combined windows list,
wherein a change in the z-order of any one of the desktop environments is reflected in
the local desktop environment.
The present invention further provides a computer-readable article of
manufacture containing a set of instructions adapted to cause a processor-based
system having nodes and communication links, said set of instructions being capable
of performing : a message receiving process capable of receiving messages indicative
of a change in the attributes of the windows in the remote desktop environments ; a
command process capable of effecting changes in corresponding windows of a local
desktop environment responsive to the received messages, the corresponding
windows reflecting substantially similar attributes relative to the local desktop
environment as the attributes of the windows in the remote desktop environments
relative to the remote desktop environments ; a combined windows list based on the
received messages and maintaining a z-order for the windows in the local and remote
desktop environments, wherein a change in the z-order of any of the desktop
environments is reflected in the local desktop environment ; a monitor process
capable of monitoring local desktop events ; and a transmission process capable of
transmitting messages indicative of the desktop events.
The present invention still further provides a system for incorporating
windows from remote desktop environments into a local desktop environment each
desktop environment including at least one window displaying graphical data, the
system comprising : a communications link comprising a first virtual channel and a
second virtual channel ; a local node ; a remote node ; said local node and said
remote node exchanging window information over said first virtual channel of said
communications link and said local node and said remote node exchanging graphical
data over said second virtual channel of said communications link ; wherein said
window information enables windows displayed on said local node to have
substantially similar attributes relative to said local desktop environment as attributes
of said windows displayed on said remote node relative to said remote desktop
environment ; and a combined windows list maintaining a z-order of said local and
remote desktop environments, wherein a change in said z-order of any of said desktop
environments is reflected in said local desktop environment.
Accordingly, the present invention provides a system for incorporating at least one
remote window from a remote desktop environment into a local desktop environment, the
system comprising : a first virtual channel coupled to the remote desktop environment
and conveying graphical data associated with the remote window; a second virtual
channel coupled to the remote desktop environment and conveying window attribute
data associated with the remote window; and a local agent coupled to the remote
desktop environment via the first and second virtual channels, the local agent directing
the formation of a corresponding window in the local desktop environment, the
corresponding window displaying the graphical data conveyed by the first virtual channel
in accordance with the window attribute data conveyed by the second virtual channel.
The present invention also provides a method incorporating at least one remote
window from a remote desktop environment into a local desktop environment, the
method comprising the step of : receiving graphical data associated with the remoted
window via a first virtual channel coupled to the remote desktop environment; receiving
window attribute data associated with the remote window via a second virtual channel
coupled to the remote desktop environment; and forming a corresponding window in the
local desktop environment, the corresponding window displaying the graphical data
received from the first virtual channel in accordance with the window attribute data
received from the second virtual channel.
The present invention further provides a system for incorporating at least one
remote window from a remote desktop environment into a local desktop environment, the
system comprising : a first virtual channel coupled to the local desktop environment and
conveying graphical data associated with the remote window; a second virtual channel
coupled to the local desktop environment and conveying window attribute data
associated with the remote window; and a remote agent associated with the remote
desktop environment and coupled to the local desktop environment via the first and
second virtual channels, the remote agent transmitting messages to the local desktop
environment directing the formation of a corresponding window in the local desktop
environment, the corresponding window displaying the graphical data conveyed by the
first virtual channel in accordance with the window attribute data conveyed by the second
virtual channel.
The present invention still further provides a method of incorporating at least one
remote window from a remote desktop environment into a local desktop environment,
the method comprising the steps of : transmitting graphical data associated with the
remote window via a first virtual channel coupled to the local desktop environment;
transmitting window attribute data associated with the remote window via a second
virtual channel coupled to the local desktop environment; and transmitting messages to
the local desktop environment directing the formation of a corresponding window in the
local desktop environment, the corresponding window displaying the graphical data
transmitted via the first virtual channel in accordance with the window attribute data
transmitted via the second virtual channel.
Brief Description of the accompanying Drawings
The invention is pointed out with particularity in the appended claims. The advantages of
this invention described above, and further advantages, may be better understood by reference to
the following description taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a functional block diagram of an embodiment of a client-server system;
FIG. 2 is a functional block diagram of a client node connected to two separate server
nodes;
FIG. 3 is a flow diagram of the steps to be taken when a server agent detects a change in
its associated desktop environment.
IG. 4 is a flow diagram of the steps to be taken when a client agent detects a change in
its associated desktop environment;
FIG. 5 is a flow chart of the steps to be taken to open a virtual channel between a client
agent and a server agent; and
FIG. 6 is a functional block diagram of an agent.
Detailed Description of the Invention
Referring now to Fig. 1, a clienl-server-system is shown in which server node 20 provides
services for one or more client nodes 10. Client nodes may communicate with server node 20
via any of a number of industry-standard data communications protocols including, but not
limited to, TCP/IP. IPX/SPX, NetBEUI, or serial protocols. Alternatively, client nodes 10 may
connect to server node 20 using a proprietary data communications protocol such as the ICA
protocol manufactured by Citrix Systems, Inc. of Fort Lauderdale, Florida or the RDP protocol
manufactured by Microsoft Corporation of Redmond. Washington. The actual connection
between the client nodes 10 and the server node 20 may be physical cabling or it may be a
wireless connection, such as infrared transmission.
Fig. 1 depicts a system in which a single client node 10 is connected to more than one
server node 20, 20'. As shown in Fig. 2, client node 10 has an associated display 12. The
display 12 may be used to display one or more components of a graphical user interface, such as
windows and pull-down menus. The collection of graphical user interface components displayed
to a user by the display 12 is generally referred to as the "desktop." As shown in Fig. 2, the local
node 10 displays a local desktop environment 14 to a user. Local node 10 may provide at least a
part of the local desktop environment 14 or local node 10 may simply display various desktop
components received from other sources such as server nodes 20. As shown in Fig, 2, each
server node 20, 20' has an associated display 22, 22' which also displays a desktop environment
24, 24'. It should be noted that display 22, 22' need not be a video display monitor. For
example, display 22, 22' may simply be a bank of video RAM to which applications write the
output of graphical procedure calls. Fig. 2 depicts an embodiment of a system in which each
server node display 22, 22' displays one graphical user interface window 26, 27'.
Each server 20, 20' also includes at least one agent 30, 30'. In particular embodiments,
each server 20, 20" includes one agent 30, 30' for each client 10 connected to the server 20, 20'.
Client node 10 may also host an agent 40. In some embodiments, a client node 10 hosts a
separate local agent 40 for each server to which the client node 10 is connected. In other
embodiments, the client node 10 hosts a single agent 40 that manages connections to multiple
server nodes 20. Each of the agents 30, 30', 40 may monitor their associated desktop
environment 24, 24', 14 for windows which: change position; are opened; are closed; change
size; are minimi2ed; are maximized; ot arc brought to the top of the desktop, i.e., windows which
gain focus that do not previously have focus. Each agent 30, 30', 40 transmits messages
indicative of changes in their associated desktop 24, 24', 14 to other agents. For example, local
agent 40 may receive messages transmitted from server node agents 30, 30'. The local agent 40
commands the client 10 to modify the local desktop environment 14 in response to the messages
received from server agents 30, 30', that is. the local agent 40 issues commands to the client
node 10 to conform the local desktop environment 14 to the server desktop environment 24. In
other embodiments, server node agents 30, 30' receive messages from a local agent 40 and
command the server 20, 20' to modify the server desktop environment 24, 24' in response 10
messages received from the local agent 40.
In one embodiment, the agents 30, 40 monitor changes to their associated desktop
environment 24, 24' by periodically issuing one or more of a set of commands provided by the
operating system that allow details of the graphical user interface desktop to be determined. For
embodiments in which the agents 30, 40 reside on nodes that execute a version of the
WINDOWS operating system, the agents 30, 40 may periodically issue the Enum Windows
command to the WINDOWS operating system, which returns a list of all windows present on the
desktop, together with information related to those windows. The agents 30, 40 can issue the
Enum Windows command every 50 milliseconds, every 100 milliseconds, every 500
milliseconds, or at any period that allows the agent 30. 40 to rapidly determine when changes to
its associated desktop environment have occurred without putting a significant computational
burden on the node. In this embodiment, the agent 30, 40 maintains a data structure storing
information about the desktop windows and compares the values returned by the EnumWindows
command to the data structure to determine changes.
Information determined and stored by the agent 30, 30' can include the title bar
associated with each window, the location of each window in the desktop environment 24, 24',
the size of each window, and the z-order positioning of each window in the desktop environment
24, 24'. In another embodiment the agent 30, 30', 40 monitors an intranode graphics message
queue to determine changes to its associated desktop environment. Server agents 30, 30'
monitor an intraserver message queue and local agent 40 monitors an intraclient message queue.
In this embodiment, changes to the desktop environment 24, 24' are effected via messages, sent
to a graphics subsystem from system applications or the operating system itself. Thus, an
application executing an a server 20, 20' would send a message to a graphics engine residing on
the server 20, 20' in order to change the server desktop environment 24, 24'. Other commands
which return graphical user interface data are readily apparent to those of ordinary skill in the an.
For embodiments in which the agents 30, 40 reside on nodes executing a version of the
WINDOWS operating system, the agents 30, 40 monitor the Windows Message Queue for
messages affecting the desktop environment associated with the node on which the agent resides.
Examples of such messages include; WM_SETFOCUS, which indicates to which window focus
will be given (i.e., brought to the "top" of the desktop); WM_CILLFOCUS, which removes
focus from an indicated window; and WM_WINDOWPOSCHaNGING, which indicates a
change in the position of a window. Other messages that can be posted to the Windows Message
Queue are readily known to those of ordinary skill in the art.
Referring now to Fig. 3 . the steps taken during a server-initiated event are shown. The
server agent 30 senses a change in its associated desktop (step 302). The server agent 30 may do
this by intercepting a window event on the server message queue, or the agent 30 may determine
a change in the desktop by comparing the results returned from serially issued operating system
commands, as described above. The server agent 30 sends a message to a client agent 40
indicating the change in the server desktop 24 (step 304). For example, if a new window has
been given focus, the server agent 30 can transmit a message to a client agent 40 indicating the
identity of the new "top" window. In one embodiment, the server agent 30 broadcasts its
message to all client agents 40 that exist in the system. Alternatively, the server agent 30 may
transmit its message only to a predetermined subset of client agents 40. For example, when a
client 10 makes a connection to a server 20, the client agent 40 may register with the server agent
30. In this embodiment, the server agent 30 would transmit change messages only to those client
agents that have registered with the server.
The client agent 40 receives the transmitted message (step 306). In embodiments in
which the server broadcasts commands, the client agent 40 must have some mechanism for
determining whether a transmitted command affects its associated desktop 12. For example, the
client agent 40 may maintain a list of servers to which it is connected. In these embodiments, the
client agent 40 responds to messages broadcast by any server present in its list. For
embodiments in which the server agent 30 does not broadcast messages, no such mechanism is
necessary.
The client agent 40 implements a change to its associated desktop 14 responsively to the
received message (step 308). The client agent 40 may accomplish this by directly issuing
graphics Application Programming Interface commands that cause the client 10 to change the
display of its associated desktop 14. Alternatively, the client agent 40 may issue GDI commands
to change its associated desktop 14. In still other embodiments, the client agem 40 issues
commands directly to the system, whether implemented in hardware or software, responsible for
displaying graphics on the client 10.
Referring now to Fig. 4, the steps taken when a client initiates a desktop change are
shown. The client agent 40 senses a change in its associated desktop 14 (step 402). As noted
above, this may be done on an event-driven basis or by polling the operating system operating on
the client 10. The client agent 40 determines to which server 20 the affected window belongs
(siep 404). To facilitate this process, the client agent 40 may maintain a list that associates
remote windows with a particular server 20. The client agent 40 then sends a message to the
identified server 40 indicating the change in its desktop 14 (step 406). Alternatively, the client
agem 40 may skip step 404 entirely and broadcast its change message to all servers 20. The
server agent receives the transmitted message (step 408) and implements the change in its
associated desktop (step 410), as described above.
In one particular embodiment, a client node 10 and a server node 20 communicate using
the ICA protocol and the client node 10 and the server node 20 execute a version of the
WINDOWS operating system. Client node 10 hosts a local agent 40 that may be provided as a
dynamically linked library module. The server node 20 hosts a server agent 30 that may be
provided as a separate thread.
In this embodiment, the local agent 40 and the server agent 30 exchange graphical data,
i.e., the data actually displayed in each window on the desktop, via a first ICA virtual channel.
Information about window positioning, window size, z-access ordering of window and other
such information is communicated between the client node 10 and the server node 20 via a
second ICA virtual channel. Throughout the description, when the client node 10 and the server
node 20 are actively exchanging information via the second ICA virtual channel, the client will
be referred to as being in "seamless windowing mode."
Referring now to Fig. 5, the process for enabling seamless windowing mode between the
local agent 40 and server agent 30 is shown. In this embodiment, all communication between a
server agent and a client agent is packet-oriented and takes place over a dedicated ICA virtual
channel, making the functioning of the agents 30, 40 independent from the underlying
communication protocol. All packets start with packet type (1 byte), followed by packet data
length (2 bytes, can be zero) and data (optional). Agents 20, 40 will uy to send as much data in a
single network packet as possible, but it will always send complete packets. That is, the size of seamless window virtual packets never exceeds the allowable size of an ICA packet. Packet flow
control and delivery confirmation is implemented by the transport level of the ICA protocol.
Individual packets are executed immediately on reception.
The client agent 40 waits for an initial packet from the server agent 30. After user logon
10 the server, a server agent 30 will be invoked (step 504).
The server agent sends a TWI_PACKET_START packet to the client agent 40, which
includes some essential information about the server desktop environment (desktop resolution,
desktop size, version number of ICA protocol supported by the server, etc.) (step 506). This
packet is sent by the server agent 30 on initial connection or on reconnect, and is used to: (1)
detect seamless windowing capabilities of the client; and (2) requests basic client information.
The client agent receives the TWI_PACKET_START packet (step 507) and responds
with a TWI_PACKET_C2H_START_ACK packet, confirming TWI_PACKET_START and
supplying client version/capabilities information (step 508). This packet is sent by the cliem
agent 40 to confirm reception of TWI_PACKET_START packet and to send the requested basic
client information to the server agent 30.
If there is no response from the client agent 40 (step 509), the server agent 30 assumes
that the client is unable to enter seamless windowing mode, and the seamless windowing virtual
channel is not used by the server node 20 to communicate window information. In this case, the
server node 20 continues to communicate graphical data to the client node 10 via another virtual
channel, and the client desktop displays the server desktop without incorporating windows from
other nodes.
The client agent 40 uses the information sent by the server agent 30 in step 506 to
determine if a seamless windowing session can be established between the server agent 30 and
the client agent 40. In one embodiment. The client agent 40 compares information relating to the
version of the virtual channel protocol supported by the server agent 30 to makes the
determination If the client agent 40 determines that it is possible to enable seamless windowing
mode (step 510), the client agent 40 sends a TWI_PACKET_C2H_OPEN packet to the server
agent 30 (step 511). This packet requests that the server agent 30 enable seamless windowing
mode.
On reception of a TWI_PACKET_C2H_OPEN packet (step 512) the server agent 40 (I)
resets its internal data structures, (ii) sends a TW1_PACKET_SYSINFO packet to the client
agent 40 to communicate some general information regarding the window settings on the server
node 20 to the client agenl 40. (iii) sends a TWI_PACKET_OPEN packet to the client agent 40
(step 514) indicating the establishment of seamless windowing mode, and (iv) enables its main
polling loop (step 516) that will poll the operating system on the server node for desktop
changes. If the client agent 40 and the server agent 30 do not support the same version of the
seamless window protocol, the server agent 30 ignores the TWI_PACKET_C2H_OPEN packet.
On reception of TWI_PACKET_OPEN packet (step 520), the client agent 40 resets its
internal data structures (step 522) and seamless windowing mode between the client agent 40 and
the server agent 30 is established.
During a seamless windowing mode session, the server agent 30 will send window
information such as window position, size, styles, window text, etc. for all top-level windows on
the server node. Also, foreground window information is sent, i.e. which window on the server
node desktop is the foreground window. In accordance with this information, the client agent 40
creates windows with the same size/position as the server node windows on the client node
desktop. In some embodiments, window elements are transmitted as bitmaps from the server
node.20. Examples of packets sent by the server agent 30 include : TWI_PACKET_CLOSE.
which is sent to switch the client agent 40 out of seamless windowing mode and back to regular,
or full screen, mode; that is, the client node 10 is switched back to displaying the server node
desktop environment without incorporating windows from other desktop environments;
TWI_PACKET_CREATEW, which is sent to create new windows on the client node 10;
TWI_PACKET_DELETEW, which is sent to destroy a window on the client node 10;
TWI_PACKET_CHANGEW, which is sent to change & window displayed by the local node 10;
TWI_PACKET_SYSINFO, which is sent to report server node 20 system settings - normally it
is sent only once, but the packet can be sent multiple times; TWI_PACKET_FOREGROUNDW,
which is sent during normal seamless windowing mode operation to change the foreground
window, TWI_PACKET_SETTOPW, which is sent during normal seamless windowing mode
operation to change the top window, that is, to bring a new window to top;
TWI_PACKET_SETFOCUS, which is sent during normal seamless windowing mode operation
to change the focus window; TWI_PACKET_FOCUSACK, which is sent in response to
TWI_PaCKET_C2H_SETFOCUS (see below), and reports me result of a SetFocus attempt; and'
TWI_PACKET_SPA_STATUS, which is sent in response to
TWI_P ACKET_C2H_START_PUBLICAPP (see below), and is used to report the result of the
requested operation
Examples of packets that can be sent by the client agent 40 to the server agent 30 include
: TWI_PACKET_C2H_PAUSE, which is sent to suspend the server agent 30. that is, the server
agent 30 will stop sending window information, clear its internal data structure and send a
TWI_PACKET_CLOSE packet (see above); TWI_PACKET_C2H_RESUME, which is sent to
resume the server agent 30 -- the server agent 30 will clear its internal data structure, and send a
TWI_PACKET_OPEN packet (see above); TWI_PACKET_C2H_SETPOS, which is sent to
report window size/position change on the client node; TW1_PACKET_C2H_SETFOCUS,
which is sent to report a change in the focus window on the client node;
TWI_PaCKET_C2H_RESTORE, which is sent to request restoration of a minimized window;
TWI_PaCKET_C2H_TERMINATE, which is sent to request, termination of a program
executing on the server node 20; TWI_PaCKET_C2H_STARTAPP, which is sent to start a new
application on the server node 20; TWI_PACKET_C2H_LOGOUT. which is sent to end the
current session: TWI_PaCKET_C2H_START_PUBLICaPP, which is sent to start a new
published application on the server node; and TWI_PACKET_C2H_CLIENTINFO, which is
sent to report client desktop settings to the server agent 30 — this packet is generally sent on
startup, but can also be used during seamless windowing session.
The client agent 40 will try to perform some operations (such as window move and
resize) locally, sending update information back to the server node 40 afterwards. Proper
window behavior is emulated by intercepting the WM_NCHITTEST message for the client-
created windows.
Foreground window changes can happen on both the client node and the server node, so
the client and server will negotiate and balance actual foreground window changes. For
example, if the server node 20 changes its foreground window, that change should be properly
represented on the client desktop. The server agent 30 sends information regarding the new
foreground window to the client agent 40 using the TWI_PACKET_FOREGROUNDW packet
Similarly, if the client agent 40 detects a foreground window change on the cliem desktop, the
client agent 40 sends information regarding the change to the server agent 30 and the server
agent 30 implements the change on the server desktop.
When focus is taken away from a window representing a server window and is given to a
local client window, the client notifies the server of the change and the server gives focus to an
invisible window. For embodiments in which the client node 10 is connected to two server
nodes 20, and focus is shifted from a window representing a window from the first server and is
given to a window representing a window from the second server, the client sends a packet
informing the current server that its window no longer has focus. Once the server responds by
giving focus to an invisible window, the client agent 40 instructs the other server that its window
now has focus on the local desktop.
In some embodiments, it is desirable to add some complexity to the agent's main polling
loop to reduce network traffic. In these embodiments, the main polling loop includes a
comparison between the current foreground window and the identity of the window last
requested to be moved to the foreground. If the current foreground window matches the window
identified in the most recent request, the agent does not need to send information acknowledging
the change. This technique is useful in both server agent 30 and client agents 40.
Window z-ordering on the client is a superset of the server node z-ordering (client will
always have more windows than the host). Server node z-ordering is reproduced on the client by
reproducing owner/owned relationship among windows and the TOPMOST flag in. the window
style. Owner/owned relationships refer to windows which are children of other windows, such as
dialog boxes associated with application windows. The dialog box is said to be owned by the
application window, and the dialog box will always appear on top of its owner. The TOP_MOST
flag indicates that a particular window should appear on "top" of the desktop, for example, the
status bar in WINDOWS 95.
When a user disconnects, the server agent 30 switches itself to suspended mode, and will
not send information to the client agent 40. On a reconnect, the server agent 30 sends a
TWI_PACKET_STaRT packet, reporting HostAgentState as "already running, reconnect"
Based on the version number of the protocol supported by the server the client will decide
whether it is possible to enable seamless windowing mode (from the client point of view). If it is
possible to switch to seamless windowing mode, the client agent 40 will send a
TWI_PACKET_C2H_OPEN packet, asking the server agent 30 to enable seamless windowing
mode.
Each agent responsible for monitoring an associated desktop may be implemented as a
stand-alone software routine (such as an executable file on DOS-based systems), a dynamically
linked library routine (DLL), or as an integral piece of the operating system. Referring now to
FIG. 6, and in brief overview, each agent includes a message receiving facility 602. a command
facility 604, a monitor facility 606. and a message transmission facility 608. Agent-agent
communication is full-duplex, i.e., agents can transmit and receive messages simultaneously.
Thus, each facility can be implemented as a separately functioning code segment that operates
independently of the other facilities. For example, message receiving facility 602 and command
facility 604 can be implemented as separate threads which communicate with each other via a
named pipe or shared memory. Use of a common data allows the message receiving facility 602
and the message transmitting facility 608 to be synchronized.
Message receiving facility 602 receives messages transmitted from other agents
indicating changes in the desktop environments associated with those agents. Message receiving
facility 602 may connect directly with the physical layer of the communications protocol the
agents use to communicate, or the message receiving facility 602 may operate at a higher layer of
the protocol by cooperating with one or more communications subsystems. For embodiments in
which messages are broadcast by agents, the message receiving facility 602 has some mechanism
for determining whether a broadcast message is intended for it For example, the message
receiving facility 602 may store a list of the windows which its associated desktop displays. The
message receiving facility 602 would compare the target of any received message to its list of
windows to determine whether or not to take action on the received message. The message
receiving facility may be implemented as a blocking function. Alternatively, the message
receiving facility can be implemented a call-back function invoked by the ICA virtual channel
Transport
Once the message receiving facility 602 has determined that a received message is
intended for its desktop, the command facility is invoked to effect the change indicated by the
message to the associated desktop environment The command facility 604 may be passed the
received message facility, or the message receiving facility 602 may process the received
message before communicating with the command facility 604. The command facility 604 may
implement the desktop change indicated by the received message by issuing GDI commands. In
other embodiments, the command facility 604 may issue commands directly to an associated
graphics subsystem or may issue other graphics API commands.
During a seamless windowing session, a number of desktops are associated with a single-
client node - one desktop on the client itself and one desktop per server node 20 to which the
client node 10 is connected. The client agent 40, in conjunction with the server agent 30, 30
creates a combined window list representing the z-order of all desktops. All participating
desktops are 'linked" together by the client agents 40 and the server agents 30, 30', and any z-
order changes on any desktops will be propagated to other desktops.
In one embodiment, each server has knowledge only of its own graphical desktop
representation and the server desktops are individually represented within the client. The client
display is updated by combining all server and client desktop images into a single display image
based on the window information that has been obtained from each server node 20, 20' by the
client agent 40. The resulting image is displayed at the client node 10.
The combining process involves building a common window list based on the windows
information exchanged by all agents. Using the combined window list, the graphical desktop
data is clipped and merged for representation by the client node 10. The node takes care of
"clipping" displayed windows resulting from the commands issued by the command facility 604.
Such "clipping" functions are well-known to those of ordinary skill in the art. In some
embodiments, however, the command facility 604 maintains a shadow bitmap of clipped
windows. That is, the command facility 604 maintains a bit image of windows that are obscured
by other windows. This allows the agent to change its associated desktop without requiring it to
reload the window image of an obscured window from the appropriate source. In other
embodiments, the node determines whether graphical data is obscured at the time it is received.
If it is, the node ignores the received graphical data. If it is not, the node displays the data. The
node makes a determination as to whether the graphical data is obscured by applying clipping
functions.
Monitoring facility 606 monitors the desktop associated with the agent. Monitoring
facility 606 may monitor the desktop by periodically issuing commands provided by the
operating system executing on the node which return information about the node's desktop.
Alternatively, the monitoring facility 506 may watch for messages posted to an intranode
message queue. As noted above, in one particular embodiment the monitoring facility 606
monitors the Windows Message Queue. Once a desktop change occurred, the message
transmission facility 608 transmits a message indicating the change that has occurred. In some
embodiments, the message transmission facility 608 broadcasts notification of the change.
In one embodiment, message transmission facility 608 can be implemented in the form of
non-blocking function, that can be called from any window procedure. If the function can not
send a data packet immediately (for example, the communication subsystem has no buffer
space), a timer will be set and retry attempts will be done until the send succeeds.
The present invention may be provided as one or more computer-readable programs
embodied on or in one or more articles of manufacture. The article of manufacture may be a
floppy disk, a hard disk, a CD ROM. a flash memory card, a PROM, a RAM. a ROM, or a
magnetic tape. In general, the computer-readable programs may be implemented in any
programming language. Some examples of languages that can be used include C. C++, or
JAVA. The software programs may be stored on or in one or more articles of manufacture as
object code.
Having described certain embodiments of the invention, it will now become apparent to
one of skill in the art that other embodiments incorporating the concepts of the invention may be
used. Therefore, the invention should not be limited to certain embodiments, but rather should
be limited only by the spirit and scope of the following claims.
WE CLAIM :
1. A system for incorporating at least one remote window from a remote desktop
environment into a local desktop environment, the system comprising :
a first virtual channel coupled to the remote desktop environment and conveying
graphical data associated with the remote window;
a second virtual channel coupled to the remote desktop environment and
conveying window attribute data associated with the remote window; and
a local agent coupled to the remote desktop environment via the first and second
virtual channels, the local agent directing the formation of a corresponding window in the
local desktop environment, the corresponding window displaying the graphical data
conveyed by the first virtual channel in accordance with the window attribute data
conveyed by the second virtual channel.
2. The system as claimed in claim 1, comprising a combined windows list being
formed and maintained by the local agent, the combined windows list representing a
modifiable z-order of the corresponding window in the local desktop environment.
3. The system as claimed in claim 1, wherein the window attribute data associated
with the remote window and conveyed by the second virtual channel contains the size
and z-order of the remote window.
4. The system as claimed in claim 1, comprising a local operating system forming the
local desktop environment, the local agent periodically polling the local operating system
to detect an attribute change in the corresponding window, wherein the local agent
transmits a message to the remote desktop environment indicative of the attribute
change.
5. The system as claimed in claim 1, wherein the corresponding window exhibits
window attribute data substantially similar relative to the local desktop environment as
the window attribute data of the remote window relative to the remote desktop
environment.
6. The system as claimed in claim 1, comprising a plurality of communication links
coupling the local desktop environment with a plurality of remote desktop environments,
the communication links comprising first and second virtual channels conveying graphical
and window attribute data associated with remote windows from the plurality of remote
desktop environments to the local agent, wherein the local agent forms corresponding
windows in the local desktop environment corresponding to each of the plurality of
remote windows.
7. A method/incorporating at least one remote window from a remote desktop
environment into a local desktop environment, the method comprising the step of:
receiving graphical data associated with the remoted window via a first virtual
channel coupled to the remote desktop environment;
receiving window attribute data associated with the remote window via a second
virtual channel coupled to the remote desktop environment; and
forming a corresponding window in the local desktop environment, the
corresponding window displaying the graphical data received from the first virtual
channel in accordance with the window attribute data received from the second virtual
channel.
8. The method as claimed in claim 7, comprising the step of forming a combined
windows list storing at least some of the window attribute data.
9. The method as claimed in claim 7, comprising the steps of:
polling a local operating system associated with the local desktop environment to
detect an attribute change in the corresponding window; and
transmitting a message to the remote desktop environment indicative of the
detected attribute change.
10. The system as claimed in claim 7, wherein the corresponding window exhibits
window attribute data substantially similar relative to the local desktop environment as
the window attribute data of the remote window relative to the remote desktop
environment.
11. A system for incorporating at least one remote window from a remote desktop
environment into a local desktop environment, the system comprising :
a first virtual channel coupled to the local desktop environment and conveying
graphical data associated with the remote window;
a second virtual channel coupled to the local desktop environment and conveying
window attribute data associated with the remote window; and
a remote agent associated with the remote desktop environment and coupled to
the local desktop environment via the first and second virtual channels, the remote agent
transmitting messages to the local desktop environment directing the formation of a
corresponding window in the local desktop environment, the corresponding window
displaying the graphical data conveyed by the first virtual channel in accordance with the
window attribute data conveyed by the second virtual channel.
12. The system as claimed in claim 11, comprising a combined windows list formed in
response to the messages transmitted by the remote agent and containing at least some
of the window attribute information conveyed via the second virtual channel.
13. The system as claimed in claim 11, wherein the window attribute data associated
with the remote window and conveyed by the second virtual channel contains the size
and z-order of the remote window.
14. The system as claimed in claim 11, comprising a remote operating system
forming the remote desktop environment, the remote agent periodically polling the
remote operating system to detect an attribute change in the remote window, wherein the
remote agent transmits a message to the local desktop environment indicative of the
attribute change.
15. The system as claimed in claim 11, wherein the corresponding window exhibits
window attribute data substantially similar relative to the local desktop environment as
the window attribute data of the remote window relative to the remote desktop
environment.
16. The system as claimed in claim 11, comprising a plurality of communication links
coupling the remote desktop environment with a plurality of local desktop environments,
the communication links comprising first and second virtual channels conveying graphical
and window attribute data associated with the remote window from the remote desktop
environment to the plurality of local desktop environments, wherein the local desktop
environments from corresponding windows corresponding to the remote window.
17. A method of incorporating at least one remote window from a remote desktop
environment into a local desktop environment, the method comprising the steps of:
transmitting graphical data associated with the remote window via a first virtual
channel coupled to the local desktop environment;
transmitting window attribute data associated with the remote window via a
second virtual channel coupled to the local desktop environment; and
transmitting messages to the local desktop environment directing the formation of
a corresponding window in the local desktop environment, the corresponding window
displaying the graphical data transmitted via the first virtual channel in accordance with
the window attribute data transmitted via the second virtual channel.
18. The system as claimed in claim 17, comprising the step of forming a combined
windows list storing at least some of the window attribute data in response to the
transmitted messages.
19. The system as claimed in claim 17, comprising the steps of:
polling a remote operating system associated with the remote desktop
environment to detect an attribute change in the remote window; and
transmitting a message to the local desktop environment indicative of the detected
attribute change.
A system for incorporating windows from remote desktop environments into a
local desktop environment (14) comprises a local node, a local agent (40), a first
remote node, and a first remote agent. The first remote agent provides a first remote
desktop environment, and the first remote agent monitors thew first remote desktop
environment for changes in the environment. The first remote node transmits
messages to the local agent indicative of changes in the first remote desktop
environment. The local agent receives the transmitted messages commands the local
node to modify a representation of a first remote window that is part of local desktop
environment. The local agent also monitors the local desktop and transmits messages
to the remote agent indicative of a change in the local desktop. In some embodiments,
the local node provides the local desktop environment. Local agents can be embodied
on articles of manufacture.

Documents:

IN-PCT-2000-544-KOL-(30-04-2012)-FORM-27.pdf

in-pct-2000-544-kol-granted-abstract.pdf

in-pct-2000-544-kol-granted-assignment.pdf

in-pct-2000-544-kol-granted-claims.pdf

in-pct-2000-544-kol-granted-correspondence.pdf

in-pct-2000-544-kol-granted-description (complete).pdf

in-pct-2000-544-kol-granted-drawings.pdf

in-pct-2000-544-kol-granted-examination report.pdf

in-pct-2000-544-kol-granted-form 1.pdf

in-pct-2000-544-kol-granted-form 18.pdf

in-pct-2000-544-kol-granted-form 3.pdf

in-pct-2000-544-kol-granted-form 5.pdf

in-pct-2000-544-kol-granted-gpa.pdf

in-pct-2000-544-kol-granted-reply to examination report.pdf

in-pct-2000-544-kol-granted-specification.pdf

in-pct-2000-544-kol-granted-translated copy of priority document.pdf

« Previous Patent

Next Patent »

Patent Number

225224

Indian Patent Application Number

IN/PCT/2000/544/KOL

PG Journal Number

45/2008

Publication Date

07-Nov-2008

Grant Date

05-Nov-2008

Date of Filing

21-Nov-2000

Name of Patentee

CITRIX SYSTEMS INC.

Applicant Address

6400 N.W., 6TH WAY, FORT LAUDERDALE, FL

Inventors:

#	Inventor's Name	Inventor's Address
1	DUURSMA MARTIN	4 ORCHID PLACE WEST PENNANT HILLS, NSW 2125
2	PANASYUK ANATOLIY	6/34 FORSTER STREET WEST RYDE, NSW 2114

PCT International Classification Number

G06F 9/44, 9/46

PCT International Application Number

PCT/US1999/11534

PCT International Filing date

1999-05-25

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	09/086,898	1998-05-29	U.S.A.