Source: http://www.google.com/patents/US20040103438?dq=oakley+5,387,949&ei=4yI4T8nkLYa80QG0xqnWAg
Timestamp: 2017-01-18 11:21:10
Document Index: 171182084

Matched Legal Cases: ['art 700', 'art 700', 'art 700', 'art 700', 'art 700', 'art 700', 'art 700']

Patent US20040103438 - Methods and systems for transferring events including multimedia data - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMethods and systems for transferring an event from a server to a remote client are described. An event is received from a driver. The event is dispatched into an event queue according to the event type. The event is processed according to the event type. The processing includes encoding the event when...http://www.google.com/patents/US20040103438?utm_source=gb-gplus-sharePatent US20040103438 - Methods and systems for transferring events including multimedia dataAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20040103438 A1Publication typeApplicationApplication numberUS 10/306,536Publication dateMay 27, 2004Filing dateNov 27, 2002Priority dateNov 27, 2002Also published asDE60309201D1, DE60309201T2, EP1566038A1, EP1566038B1, WO2004051962A1Publication number10306536, 306536, US 2004/0103438 A1, US 2004/103438 A1, US 20040103438 A1, US 20040103438A1, US 2004103438 A1, US 2004103438A1, US-A1-20040103438, US-A1-2004103438, US2004/0103438A1, US2004/103438A1, US20040103438 A1, US20040103438A1, US2004103438 A1, US2004103438A1InventorsYong Yan, Bo Shen, Sujoy Basu, Rajendra KumarOriginal AssigneeYong Yan, Bo Shen, Sujoy Basu, Rajendra KumarExport CitationBiBTeX, EndNote, RefManPatent Citations (4), Referenced by (83), Classifications (36), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetMethods and systems for transferring events including multimedia data
[0015] The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted. BEST MODE FOR CARRYING OUT THE INVENTION [0016] Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention. [0017] [0017]FIG. 1 is a block diagram of a server 101 and a client 102 coupled in a network 100 according to one embodiment of the present invention. It is appreciated that network 100 may include elements other than those shown. Network 100 may also include more than one of the various elements shown; for example, there may be multiple clients coupled to server 101, and there may be multiple servers. The functionality of server 101 and client 102 is discussed below (refer at least to FIGS. 2 and 6); however, it is appreciated that these elements may implement functionality other than that discussed. [0018] Communication may occur directly between server 101 and client 102 of FIG. 1, or indirectly through an intermediary device or node (not shown). Also, communication may be wired or wireless, or a combination of wired and wireless. In one embodiment, communication occurs over the World Wide Web (or Internet). [0019] In one embodiment, server 101 and client 102 are computer systems that provide processing capability and memory capacity. In addition, according to the embodiments of the present invention, server 101 implements a desktop streaming server 110, and client 102 implements a desktop streaming client 120. In this embodiment, desktop streaming server 110 and desktop streaming client 120 allow the server 101 to supply a display (e.g., a graphical user interface, and in particular, a “desktop” display) to the client 102. As will be seen, both server-side control and client-side control are allowed, either concurrently or exclusively. [0020] According to the embodiments of the present invention, “events” are transferred from server 101 to client 102, and vice versa, using desktop streaming server 110 and desktop streaming client 120, respectively. As used herein, an event is generally an output of a software driver, such as a keyboard driver, a mouse driver, a video driver or an audio driver. Thus, events include detectable actions or occurrences such as clicking a mouse button or pressing a key on a keyboard. Events can also refer to actions or occurrences that can cause a change in the display (graphical user interface) to be displayed by the client 102. For example, a change in the display caused by scrolling through a text (word processing) document, or by changing from one page to another page in the document, can constitute an event. A movement of a window in the display can also constitute an event. A moving video display can also constitute an event. An audio sample can also constitute an event. [0021] To summarize, as used herein, an event is an output of a driver used with either server 101 or client 102; an event may cause a change in the display on either server 101 or client 102, and/or may cause an audio output at the client 102. Events can be generally categorized as: control events, and data events. Control events carry control information to change the execution behaviors of other components, locally or remotely. Data events carry content data to inform other components of content changes. [0022] For simplicity of discussion, the term “mouse” is used herein; however, it is understood that other means of cursor control may be used instead of, or in combination with, a mouse. There is a myriad of cursor control mechanisms known in the art, and each of these may be used in accordance with the present invention. The term “keyboard” is also used herein. Again, there is a myriad of mechanisms known in the art that provide the functionality of a keyboard, including voice recognition systems, and each of these may be used in accordance with the present invention. Thus, although embodiments of the present invention are described for a mouse and keyboard, the present invention is not so limited. Instead, the focus should be on the term “event” and how that term is used herein, as described above. In that context, keyboard and mouse events are simply examples of events, while the embodiments of the present invention are well suited to use with virtually all types of events. [0023] In one embodiment, on the server side, the events received from the drivers are dispatched into event queues according to the event type. The events are then processed according to their event type; for example, a multimedia event may be encoded. The events are then transferred from server 101 to client 102 according to a protocol that corresponds to the event type. In one embodiment, events from keyboard and mouse drivers are transferred to client 102 using a protocol such as Transmission Control Protocol (TCP), while events from video and audio drivers are transferred to client 102 using a protocol such as Real Time Protocol (RTP). These processes are described in further detail in conjunction with FIG. 2, below. [0024] TCP and RTP are known in the art. TCP provides a highly reliable protocol, while RTP provides the timing capability useful for synchronizing the video and audio portions of a multimedia data object. Thus, TCP can be used to precisely transfer control events (e.g., keyboard and mouse events) as well as other high precision events, such as changes in graphics applications, and RTP can be used for streaming frame buffer (video buffer) and sound buffer updates. Other protocols that can provide these or similar capabilities may be used instead. [0025] On the client side, in one embodiment, events are received from keyboard and mouse drivers and transferred to server 101 of FIG. 1 using a protocol such as TCP. This process is described further in conjunction with FIG. 6, below. In the present embodiment, the relationship between server 101 and client 102 does not have the client sending events from audio and video drivers to the server; however, the present invention is not so limited. [0026] [0026]FIG. 2 is a block diagram of a desktop streaming server 110 in accordance with one embodiment of the present invention. Desktop streaming server 110 is implemented in server 101 of FIG. 1 as hardware, software, firmware, or a combination thereof. As illustrated by FIG. 2, desktop streaming server 110 includes a number of elements that are rendered separately for clarity of illustration and discussion; however, it is understood that these elements may not exist as separate entities within desktop streaming server 110. In general, according to the various embodiments of the present invention, desktop streaming server 110 provides the capability and functionality provided by the various elements of FIG. 2. In addition, desktop streaming server 110 may provide other capabilities and functionalities in addition to those described herein. [0027] In the present embodiment, a driver interface 210 receives input (events) from a number of drivers such as, but not limited to, keyboard driver 201, mouse driver 202, video driver 203, and/or audio driver 204. Thus, in addition to intercepting more conventional events such as window changes, keyboard input and cursor movement, driver interface 210 also samples video data from the video driver 203 and audio data from the audio driver 204. [0028] Generally, the drivers 201-204 are components of the underlying operating system. For example, the keyboard driver for a Windows environment may be different than the keyboard driver for a Linux environment. According to the present embodiment, driver interface 210 provides the capability to communicate with the various types of drivers while providing a fixed interface to the downstream portions of desktop streaming server 110 (e.g., a fixed interface to event filter 220). [0029] [0029]FIG. 3 is a block diagram of a driver interface 210 in accordance with one embodiment of the present invention. In this embodiment, driver interface 210 includes a number of interface modules, exemplified by interfaces 301 and 302, so that there is a module suitable for interfacing with each driver. This is not to say that there is an interface module per driver, although that may be the case. [0030] In the present embodiment, driver interface 210 also includes an application program interface (API) 305 that is common to the interfaces 301 and 302, etc. The API 305 provides a single interface to the remainder of desktop streaming server 110 despite the myriad of possible drivers, and thus insulates the desktop streaming server 110 from the underlying operating system. [0031] Returning to FIG. 2, in the present embodiment, the events from driver interface 210 are provided to (received by) event filter 220. In this embodiment, event filter 220 identifies the event according to event type, and dispatches the event into a respective event queue according to event type. The event queues are used to buffer similar types of events that can be transferred to the desktop streaming client 120 (FIG. 1) using a protocol appropriate to the event type (e.g., TCP or RTP) after processing (if any) appropriate to the event type. [0032] In the present embodiment, the event filter 220 of FIG. 2 categorizes events into the following types: 1) control events that are generated by keyboard input or cursor (e.g., mouse) movement, for example; 2) window movement events that are generated by window movements in which window content is unchanged; 3) window updates that are generated by a change in window content; and 4) audio samples that are captured from a change in the sound buffer of the audio driver 204. In this embodiment, control events are forwarded to the control event queue 231; window movements are forwarded to the window movement queue 232; window updates are forwarded to the windows update queue 233; and audio samples are forwarded to the audio sample queue 234. [0033] In the present embodiment, control events in the control event queue 231 record the coordinate changes of the mouse or cursor. For example, for a particular cursor movement, only the start and end coordinates of the movement may be transferred to the desktop streaming client 120 of FIG. 1. Control events can be further optimized by the desktop streaming engine 250. [0034] Continuing with reference to FIG. 2, in the present embodiment, the window movement queue 232 records the coordinate changes of a window that is being moved (without the content of the window being changed). In those cases in which the window content has been previously transferred to desktop streaming client 120 of FIG. 1, only the changes in the coordinates of the window may be transferred to the client. The client can then render the desktop display using the previously received window content and the new window coordinates. [0035] According to the present embodiment, the window updates queue 233 of FIG. 2 records the updates of window content. These updates can be captured from the video frame buffer. In one embodiment, in order to facilitate selection of an appropriate encoder and transfer protocol, window updates are categorized into three types: 1) graphics window updates; 2) video window updates; and 3) other window updates. Here, graphics is used to refer to relatively static images (e.g., images having relatively low update rates in comparison to video); video refers to moving images having a relatively high update rate; and other window updates refers to relatively static window content such as the text in a word processing document. Generally speaking, the window updates can be separated into categories according to the complexity of the image and the update frequency. [0036] [0036]FIG. 4 is a block diagram showing differentiation of window updates according to one embodiment of the present invention. In this embodiment, window updates differentiator 410 filters the windows into the aforementioned categories. The window updates differentiator 410 can accomplish this using information such as the display application type, and the coordinates and screen sizes of the windows. The display application type can be acquired from the driver interface 210 (FIG. 2) when, for example, a new window is created, a Uniform Resource Locator (URL) for a Web site is clicked, or an application is executed. The coordinates and screen sizes help to locate which part of an update to the video frame buffer belongs to which window. [0037] Graphics window updates are forwarded to the graphics window updates queue 421; video window updates are forwarded to the video window updates queue 422; and other window updates are forwarded to the other window updates queue 423. [0038] Returning to FIG. 2, in the present embodiment, the transfer of events from each of the queues 231-234 to the desktop streaming engine 250 is triggered by a respective regulator 241, 242, 243 and 244. Similarly, in the embodiment of FIG. 4, the queues 421-423 are under control of a respective regulator 431, 432 and 433. [0039] In one embodiment, the regulators 241-244 of FIG. 2 (and the regulators 431-433 of FIG. 4) trigger (impel) events from their respective queues based on a threshold being reached or a time interval having passed. The threshold is based on the number of events in a respective event queue. When the number of events in the queue reaches a predefined threshold, some portion of the events or all of the events can be transferred from the queue. The threshold mechanism provides the capability to handle a burst of events, in order to prevent the queue from accumulating too many events before the events are transferred in response to a time-out signal. The threshold may be different for each of the queues 231-234 and 421-423. The threshold may also be changed by the desktop streaming engine 250 based on monitoring of the channels to the desktop streaming client 120 (FIG. 1), or based on feedback from the desktop streaming client 120. [0040] Otherwise, according to the present embodiment, the transfer of events from a respective event queue will occur after a specified time interval has passed. Thus, in one embodiment, the regulators 241-244 of FIG. 2 and the regulators 431-433 of FIG. 4 can include a timer. The time interval may be different for each of the queues 231-234 (FIG. 2) and 421-423 (FIG. 4). The time interval may also be changed by the desktop streaming engine 250 (FIG. 2) based on monitoring of the channels to the desktop streaming client 120 (FIG. 1), or based on feedback from the desktop streaming client 120. This is described further in conjunction with FIGS. 5 and 6, below. [0041] [0041]FIG. 5 is a block diagram of a desktop streaming engine 250 according to one embodiment of the present invention. As illustrated by FIG. 5, desktop streaming engine 250 includes a number of elements that are rendered separately for clarity of illustration and discussion; however, it is understood that these elements may not exist as separate entities within desktop streaming engine 250. In general, according to the various embodiments of the present invention, desktop streaming engine 250 provides the capability and functionality provided by the various elements of FIG. 5. In addition, desktop streaming engine 250 may provide other capabilities and functionalities in addition to those described herein. [0042] In the present embodiment, scheduler 510 is coupled to the regulators 580 (e.g., regulators 241-244 and 431-433 of FIGS. 2 and 4, respectively), which in turn are coupled to the queues 590 (e.g., queues 231-234 and 421-423 of FIGS. 2 and 4, respectively). Scheduler 510 is also coupled to a monitor 530. In one embodiment, the monitor 530 periodically measures the available bandwidth of the channels 571, 572 and 573. Although only three channels are shown, it is appreciated that there may be some number of channels other than three. In another embodiment, the monitor 530 also collects information from desktop streaming client 120 (FIG. 1) with regard to the workload of the client as well as the attributes of the client device (e.g., the device's display capabilities such as screen size and resolution, the device's processing capabilities such as processor speed, the device's available memory capacity, and the like). Based on the information from monitor 530, scheduler 510 can set or adjust the trigger (e.g., the time interval, threshold or other mechanism) that is used to initiate the transfer of events from the various event queues. As mentioned above, different time intervals, thresholds, or the like can be specified for each of the queues. [0043] The schedule for transferring events in the control event queue 231 and the window movement queue 232 (FIG. 2) is relatively straightforward because these types of events require less communication overhead and therefore can be transferred almost if not immediately. The schedule for transferring events from the windows update queue 233 and the audio samples queue 234 can be adapted according to the information from monitor 530 (and also from monitor 630 of the client; see FIG. 6), so as to provide a satisfactory display at client 102 (FIG. 1). [0044] Continuing with reference to FIG. 5, and with reference also to FIGS. 2 and 4, transfer engine 540 forwards the events from event queues 590 to the appropriate channel based on the event type. For example, in one embodiment, events from control event queue 231, window movement queue 232, graphics window updates queue 421, and other window updates queue 423 can be forwarded to a TCP channel, while events from audio samples queue 234 and video window updates queue 422 can be forwarded to an RTP channel. [0045] With reference to FIG. 5, in the present embodiment, video and/or audio content may be encoded (compressed) using encoder 550. The degree of encoding is typically a function of the attributes of the client 102 (FIG. 1), but the degree of encoding may also be influenced by the bandwidth of the connection (channel) between the client 102 and the server 101 (FIG. 1). [0046] In the present embodiment, the synchronizer 560 of FIG. 5 synchronizes the audio with other related media parts. The media parts related to the audio can be text, graphics or video. In one embodiment, the audio and related portions are sent over separate channels (e.g., RTP channels). In that embodiment, synchronizer 560 requests scheduler 510 to obtain data from the corresponding samples queue (the audio samples queue 234, the window updates queue 233, and/or the window movement queue 232 of FIG. 2) in a synchronized fashion. For example, if one second's worth of audio packets is acquired, one second's worth of video packets should also be acquired. This type of approach helps ensure that the audio and video packets will arrive at the client 102 (FIG. 1) concurrently or within a short interval of each other. A small buffer may be utilized by client 102 to overcome any disparity in arrival times. [0047] In another embodiment, with reference to FIG. 5, the synchronization is done by encoder 550, regardless of whether or not the media parts (e.g, video data) are encoded. In this embodiment, encoder 550 can multiplex the audio and related media parts, and subsequently transfer the data to communication manager 570, which can then transfer the multiplexed packets over one channel (e.g., an RTP channel). A decoder on client 102 (FIG. 1; also see FIG. 6, below) can play the multiplexed data in a synchronized fashion. For example, within one second of actual time, the decoder can decode one second's worth of audio data, which can be place in an audio buffer. During the time remaining in the one second of actual time, the decoder can decode as many video frames as possible. In this manner, the desktop streaming server 110 of FIG. 2 is able to take advantage of resources available on the client side. [0048] Continuing with reference to FIG. 5, in the present embodiment, communication manager 570 manages the communication channels 571-573. Also in the present embodiment, client event receiver 520 is for receiving control events (e.g., keyboard and mouse events) from desktop streaming client 120 (FIG. 1). These events are forwarded by client event receiver 520 to driver interface 210 that, in one embodiment, forwards them to video driver 203 (FIG. 2). [0049] In summary, in one embodiment, the desktop streaming server 110 (FIG. 2) intercepts events from the various drivers, filters those events and dispatches the events to the appropriate event queue based on event type, optionally encodes selected video data and audio data and streams that data to a client over a channel such as an RTP channel, and reacts to events received from the client. [0050] [0050]FIG. 6 is a block diagram of a desktop streaming client 120 according to one embodiment of the present invention. As illustrated by FIG. 6, desktop streaming client 120 includes a number of elements that are rendered separately for clarity of illustration and discussion; however, it is understood that these elements may not exist as separate entities within desktop streaming client 120. In general, according to the various embodiments of the present invention, desktop streaming client 120 provides the capability and functionality provided by the various elements of FIG. 6. In addition, desktop streaming client 120 may provide other capabilities and functionalities in addition to those described herein. [0051] In the present embodiment, desktop streaming client 120 includes an agent 610 (which may also be referred to as a daemon). In this embodiment, the agent 610 establishes and maintains the channel connections with the server 101, specifically to the desktop streaming server 110 (FIG. 1). As mentioned, these channels may utilize the TCP and RTP protocols. Agent 610 also forwards data received over the channels to processing engine 620. Agent 610 can also respond to inquiries from the desktop streaming server 110 regarding available channel bandwidth. Furthermore, at the beginning of a session, agent 610 can inform desktop streaming server 110 of the client's decoding capabilities as well as other client attributes, such as processor speed, and display screen size and resolution. [0052] In the present embodiment, agent 610 of FIG. 6 is coupled to a monitor 630, and can provide information from monitor 630 to the desktop streaming server 110 of FIG. 1. In this embodiment, monitor 630 can monitor the workload of the client 102 (FIG. 1), and can also provide information regarding available memory capacity. Also, monitor 630 can provide feedback regarding the efficiency in which the display is generated based on the events received from the desktop streaming server 110, so that the streaming rate, for example, can be adjusted accordingly. Thus, for example, the information from monitor 630 (and also from agent 610) can be used by the scheduler 510 of FIG. 5 to set or adjust the trigger (e.g., the time interval, threshold or other mechanism) that is used to initiate the transfer of events from the various event queues of the desktop streaming server 110. [0053] With reference to FIG. 6, in the present embodiment, agent 610 is also coupled to processing engine 620. Events received by agent 610 are forwarded to processing engine 620. In one embodiment, processing engine 620 includes a decoder 622 for decoding (decompressing) data (events) if the data are encoded. The events from processing engine 620 are forwarded to driver interface 640, which functions in a manner similar to that described above for driver interface 210 (FIG. 2) to forward the events to video driver 663 and/or audio driver 664. [0054] In the present embodiment, driver interface 640 also receives events from keyboard driver 661 and mouse driver 662 of the client device. These events are forwarded to client event processor 650, which optimizes these events by eliminating non-critical events and then forwards the critical events to the desktop streaming server 110 (FIG. 2) via agent 610. That is, for example, for a particular cursor movement, client event processor 650 may eliminate intermediate coordinates associated with the cursor movement, identifying and keeping only the start and end coordinates of the movement for transfer to the desktop streaming server 110. [0055] Thus, in summary, in one embodiment, the desktop streaming client 120 (FIG. 6) decodes events transferred from the server (when the events are encoded), updates the display based on the events, provides audio playback when the events include audio samples, responds to inquiries from the desktop streaming server 110 (FIG. 2), periodically provides monitoring information to the desktop streaming server 110, and intercepts control events and sends them to the desktop streaming server 110. [0056] [0056]FIG. 7 is a flowchart 700 of a method for transferring an event from a server to a client according to one embodiment of the present invention. Although specific steps are disclosed in flowchart 700, such steps are exemplary. That is, embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in flowchart 700. It is appreciated that the steps in flowchart 700 may be performed in an order different than presented, and that not all of the steps in flowchart 700 may be performed. All of, or a portion of, the methods described by flowchart 700 may be implemented using computer-readable and computer-executable instructions which reside, for example, in computer-usable media of a computer system or like device. Generally, flowchart 700 is implemented by devices such as server 101 of FIG. 1. [0057] In step 710 of FIG. 7, in the present embodiment, an event is received from a driver. The event may be a keyboard event, a cursor control (e.g, mouse) event, a video event, or an audio event. [0058] In step 720, in the present embodiment, the event is dispatched to an event queue according to the event type. That is, events of the same type are forwarded to a particular queue. In one embodiment, the events are filtered to identify event type. [0059] In step 730, in the present embodiment, the event is processed according to the event type. For example, when the event includes multimedia data (e.g., video data and/or audio data), the event may be encoded. For cursor movement, the coordinates of the points between the start and end points may be eliminated, with only the coordinates of the start and end point retained. [0060] In step 740, in the present embodiment, the event is transferred to the client when triggered. The transfer to the client occurs according to a protocol that corresponds to the type of event. In one embodiment, event transfer is triggered by the passage of a specified time interval. In another embodiment, event transfer is triggered when the number of events in the event queue reaches a specified threshold. [0061] Embodiments of the present invention are thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the following claims. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6275871 *Jul 3, 1996Aug 14, 2001Siemens AktiengesellschaftAsynchronous transport optimizing observer-pattern-like system supporting several modes for an interface definition language-less communication subsystemUS6961750 *May 18, 2000Nov 1, 2005Microsoft Corp.Server-side control objects for processing client-side user interface elementsUS7024451 *Nov 5, 2001Apr 4, 2006Hewlett-Packard Development Company, L.P.System and method for maintaining consistent independent server-side state among collaborating serversUS20030105805 *Nov 5, 2001Jun 5, 2003Jorgenson Daniel ScottSystem and method for maintaining consistent independent server-side state among collaborating servers* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7657657 *Aug 11, 2005Feb 2, 2010Citrix Systems, Inc.Method for maintaining transaction integrity across multiple remote access serversUS7724657Jul 22, 2005May 25, 2010Citrix Systems, Inc.Systems and methods for communicating a lossy protocol via a lossless protocolUS7757074Jan 24, 2005Jul 13, 2010Citrix Application Networking, LlcSystem and method for establishing a virtual private networkUS7808906Jul 22, 2005Oct 5, 2010Citrix Systems, Inc.Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgementsUS7831728Nov 1, 2006Nov 9, 2010Citrix Systems, Inc.Methods and systems for real-time seeking during real-time playback of a presentation layer protocol data streamUS7849269Dec 30, 2005Dec 7, 2010Citrix Systems, Inc.System and method for performing entity tag and cache control of a dynamically generated object not identified as cacheable in a networkUS7849270Jul 16, 2010Dec 7, 2010Citrix Systems, Inc.System and method for performing entity tag and cache control of a dynamically generated object not identified as cacheable in a networkUS7921184Dec 30, 2005Apr 5, 2011Citrix Systems, Inc.System and method for performing flash crowd caching of dynamically generated objects in a data communication networkUS7978714Jul 22, 2005Jul 12, 2011Citrix Systems, Inc.Methods and systems for securing access to private networks using encryption and authentication technology built in to peripheral devicesUS7978716Dec 17, 2008Jul 12, 2011Citrix Systems, Inc.Systems and methods for providing a VPN solutionUS8014421Sep 15, 2009Sep 6, 2011Citrix Systems, Inc.Systems and methods for adjusting the maximum transmission unit by an intermediary deviceUS8019868Sep 10, 2009Sep 13, 2011Citrix Systems, Inc.Method and systems for routing packets from an endpoint to a gatewayUS8046830Jul 22, 2005Oct 25, 2011Citrix Systems, Inc.Systems and methods for network disruption shielding techniquesUS8077632Dec 12, 2005Dec 13, 2011Citrix Systems, Inc.Automatic LAN/WAN port detectionUS8145777Jan 14, 2005Mar 27, 2012Citrix Systems, Inc.Method and system for real-time seeking during playback of remote presentation protocolsUS8191008Oct 3, 2005May 29, 2012Citrix Systems, Inc.Simulating multi-monitor functionality in a single monitor environmentUS8200828Oct 30, 2009Jun 12, 2012Citrix Systems, Inc.Systems and methods for single stack shadowingUS8230096Jan 14, 2005Jul 24, 2012Citrix Systems, Inc.Methods and systems for generating playback instructions for playback of a recorded computer sessionUS8233392Jul 28, 2004Jul 31, 2012Citrix Systems, Inc.Transaction boundary detection for reduction in timeout penaltiesUS8238241Jul 28, 2004Aug 7, 2012Citrix Systems, Inc.Automatic detection and window virtualization for flow controlUS8255456Dec 30, 2005Aug 28, 2012Citrix Systems, Inc.System and method for performing flash caching of dynamically generated objects in a data communication networkUS8259729Sep 25, 2009Sep 4, 2012Citrix Systems, Inc.Wavefront detection and disambiguation of acknowledgementsUS8261057Jun 4, 2010Sep 4, 2012Citrix Systems, Inc.System and method for establishing a virtual private networkUS8270423Mar 12, 2007Sep 18, 2012Citrix Systems, Inc.Systems and methods of using packet boundaries for reduction in timeout preventionUS8291119Jul 22, 2005Oct 16, 2012Citrix Systems, Inc.Method and systems for securing remote access to private networksUS8296441Oct 30, 2009Oct 23, 2012Citrix Systems, Inc.Methods and systems for joining a real-time session of presentation layer protocol dataUS8301839Dec 30, 2005Oct 30, 2012Citrix Systems, Inc.System and method for performing granular invalidation of cached dynamically generated objects in a data communication networkUS8340130Jan 14, 2005Dec 25, 2012Citrix Systems, Inc.Methods and systems for generating playback instructions for rendering of a recorded computer sessionUS8351333Aug 30, 2010Jan 8, 2013Citrix Systems, Inc.Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgementsUS8411560Oct 28, 2009Apr 2, 2013Citrix Systems, Inc.TCP selection acknowledgements for communicating delivered and missing data packetsUS8422851Jan 11, 2010Apr 16, 2013Citrix Systems, Inc.System and methods for automatic time-warped playback in rendering a recorded computer sessionUS8432800Mar 12, 2007Apr 30, 2013Citrix Systems, Inc.Systems and methods for stochastic-based quality of serviceUS8437284Mar 12, 2007May 7, 2013Citrix Systems, Inc.Systems and methods for additional retransmissions of dropped packetsUS8462630May 21, 2010Jun 11, 2013Citrix Systems, Inc.Early generation of acknowledgements for flow controlUS8495305Dec 30, 2005Jul 23, 2013Citrix Systems, Inc.Method and device for performing caching of dynamically generated objects in a data communication networkUS8499057Feb 22, 2011Jul 30, 2013Citrix Systems, IncSystem and method for performing flash crowd caching of dynamically generated objects in a data communication networkUS8549149Dec 30, 2005Oct 1, 2013Citrix Systems, Inc.Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexingUS8553699Aug 31, 2012Oct 8, 2013Citrix Systems, Inc.Wavefront detection and disambiguation of acknowledgementsUS8559449May 31, 2011Oct 15, 2013Citrix Systems, Inc.Systems and methods for providing a VPN solutionUS8572162Dec 1, 2008Oct 29, 2013Novell, Inc.Adaptive screen painting to enhance user perception during remote management sessionsUS8615159Sep 20, 2011Dec 24, 2013Citrix Systems, Inc.Methods and systems for cataloging text in a recorded sessionUS8634420May 25, 2010Jan 21, 2014Citrix Systems, Inc.Systems and methods for communicating a lossy protocol via a lossless protocolUS8700695Dec 30, 2005Apr 15, 2014Citrix Systems, Inc.Systems and methods for providing client-side accelerated access to remote applications via TCP poolingUS8706877Dec 30, 2005Apr 22, 2014Citrix Systems, Inc.Systems and methods for providing client-side dynamic redirection to bypass an intermediaryUS8726006Aug 21, 2012May 13, 2014Citrix Systems, Inc.System and method for establishing a virtual private networkUS8739274Jun 29, 2005May 27, 2014Citrix Systems, Inc.Method and device for performing integrated caching in a data communication networkUS8788581Jan 18, 2013Jul 22, 2014Citrix Systems, Inc.Method and device for performing caching of dynamically generated objects in a data communication networkUS8824490Jun 14, 2012Sep 2, 2014Citrix Systems, Inc.Automatic detection and window virtualization for flow controlUS8848710Jul 25, 2012Sep 30, 2014Citrix Systems, Inc.System and method for performing flash caching of dynamically generated objects in a data communication networkUS8856777Sep 2, 2010Oct 7, 2014Citrix Systems, Inc.Systems and methods for automatic installation and execution of a client-side acceleration programUS8892778Sep 14, 2012Nov 18, 2014Citrix Systems, Inc.Method and systems for securing remote access to private networksUS8897299Jan 11, 2013Nov 25, 2014Citrix Systems, Inc.Method and systems for routing packets from a gateway to an endpointUS8914522Jul 22, 2005Dec 16, 2014Citrix Systems, Inc.Systems and methods for facilitating a peer to peer route via a gatewayUS8935316Oct 30, 2009Jan 13, 2015Citrix Systems, Inc.Methods and systems for in-session playback on a local machine of remotely-stored and real time presentation layer protocol dataUS8954595Dec 30, 2005Feb 10, 2015Citrix Systems, Inc.Systems and methods for providing client-side accelerated access to remote applications via TCP bufferingUS9008100Oct 3, 2013Apr 14, 2015Citrix Systems, Inc.Wavefront detection and disambiguation of acknowledgmentsUS9071543Apr 3, 2013Jun 30, 2015Citrix Systems, Inc.Systems and methods for additional retransmissions of dropped packetsUS9219579Jul 22, 2005Dec 22, 2015Citrix Systems, Inc.Systems and methods for client-side application-aware prioritization of network communicationsUS9496991Jul 9, 2012Nov 15, 2016Citrix Systems, Inc.Systems and methods of using packet boundaries for reduction in timeout preventionUS9514242Apr 17, 2012Dec 6, 2016Vmware, Inc.Presenting dynamically changing images in a limited rendering environmentUS20050074007 *Jul 28, 2004Apr 7, 2005Samuels Allen R.Transaction boundary detection for reduction in timeout penaltiesUS20050097288 *Oct 30, 2003May 5, 2005Richard HolzmannSystem and method for monitoring and non-disruptive backup of data in a solid state disk systemUS20060029062 *Jul 22, 2005Feb 9, 2006Citrix Systems, Inc.Methods and systems for securing access to private networks using encryption and authentication technology built in to peripheral devicesUS20060029064 *Jul 22, 2005Feb 9, 2006Citrix Systems, Inc.A method and systems for routing packets from an endpoint to a gatewayUS20060037072 *Jul 22, 2005Feb 16, 2006Citrix Systems, Inc.Systems and methods for network disruption shielding techniquesUS20060039355 *Jul 22, 2005Feb 23, 2006Citrix Systems, Inc.Systems and methods for communicating a lossy protocol via a lossless protocolUS20060047836 *Aug 11, 2005Mar 2, 2006Rao Goutham PA method for maintaining transaction integrity across multiple remote access serversUS20060159029 *Dec 12, 2005Jul 20, 2006Samuels Allen RAutomatic LAN/WAN port detectionUS20060161555 *Jan 14, 2005Jul 20, 2006Citrix Systems, Inc.Methods and systems for generating playback instructions for playback of a recorded computer sessionUS20060161959 *Jan 14, 2005Jul 20, 2006Citrix Systems, Inc.Method and system for real-time seeking during playback of remote presentation protocolsUS20060190719 *Jul 22, 2005Aug 24, 2006Citrix Systems, Inc.Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgementsUS20100138476 *Dec 1, 2008Jun 3, 2010Gokaraju Ravi KiranAdaptive screen painting to enhance user perception during remote management sessionsUS20110106881 *Apr 17, 2009May 5, 2011Hugo DouvilleMethod and system for virtually delivering software applications to remote clientsUS20120174003 *Nov 23, 2011Jul 5, 2012Hon Hai Precision Industry Co., Ltd.Application managment system and method using the sameUS20120236199 *Mar 6, 2012Sep 20, 2012Fujitsu LimitedInformation processing apparatus, image transmitting program, image transmitting method and image display methodUS20120300127 *Dec 31, 2010Nov 29, 2012Sagemcom Broadband SasSystem for managing detection of advertisements in an electronic device, for example in a digital tv decoderUS20120324358 *Jun 16, 2011Dec 20, 2012Vmware, Inc.Delivery of a user interface using hypertext transfer protocolUS20130031482 *Jul 28, 2011Jan 31, 2013Microsoft CorporationMulti-Touch RemotingUS20150046599 *Sep 27, 2011Feb 12, 2015Google Inc.Multichannel communication systems and methods of using the sameCN103765913A *Mar 28, 2012Apr 30, 2014Lg电子株式会社Mobile terminal, image display device mounted on vehicle and data processing method using sameEP1821490A1 *Feb 15, 2006Aug 22, 2007IBBT vzwMethod for transmitting graphical data to a thin clientEP2237526A1 *Mar 30, 2009Oct 6, 2010NEC CorporationMethod for optimizing the remote display transfer in thin client computing environmentWO2005029864A1 *Sep 13, 2004Mar 31, 2005Citrix Systems, Inc.Method and apparatus for generating graphical and media displays at a thin client* Cited by examinerClassifications U.S. Classification725/109, 725/111, 348/E05.006International ClassificationH04L29/08, H04N5/00, H04L29/06Cooperative ClassificationH04L65/4084, H04L65/604, H04L65/80, H04N21/4431, H04N21/6125, H04N21/2402, H04N21/6437, H04N21/25825, H04L67/38, H04L67/42, H04L67/08, H04L67/04, H04L69/329, H04L29/06027, H04L65/608European ClassificationH04N21/443A, H04N21/258C2, H04N21/24D, H04N21/6437, H04N21/61D3, H04L29/06C4, H04L29/06C2, H04L29/08N7, H04L29/08N3, H04L29/06C8, H04L29/08A7, H04L29/06M8, H04L29/06M6C4, H04L29/06M6P, H04L29/06M4S4Legal EventsDateCodeEventDescriptionFeb 13, 2003ASAssignmentOwner name: HEWLETT-PACKARD COMPANY, COLORADOFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YAN, YONG;SHEN, BO;BASU, SUJOY;AND OTHERS;REEL/FRAME:013428/0976Effective date: 20021126Jun 18, 2003ASAssignmentOwner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., COLORADFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928Effective date: 20030131Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.,COLORADOFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928Effective date: 20030131RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services