US8615159B2 - Methods and systems for cataloging text in a recorded session - Google Patents

Methods and systems for cataloging text in a recorded session Download PDF

Info

Publication number
US8615159B2
US8615159B2 US13/237,047 US201113237047A US8615159B2 US 8615159 B2 US8615159 B2 US 8615159B2 US 201113237047 A US201113237047 A US 201113237047A US 8615159 B2 US8615159 B2 US 8615159B2
Authority
US
United States
Prior art keywords
packet
packets
protocol engine
protocol
playback
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US13/237,047
Other versions
US20130071085A1 (en
Inventor
Paul Ryman
Ricardo Fernando Feijoo
Anil Nagubadi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Citrix Systems Inc
Original Assignee
Citrix Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Citrix Systems Inc filed Critical Citrix Systems Inc
Priority to US13/237,047 priority Critical patent/US8615159B2/en
Assigned to CITRIX SYSTEMS, INC. reassignment CITRIX SYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NAGUBADI, ANIL, RYMAN, PAUL, FEIJOO, RICARDO FERNANDO
Publication of US20130071085A1 publication Critical patent/US20130071085A1/en
Application granted granted Critical
Publication of US8615159B2 publication Critical patent/US8615159B2/en
Assigned to WILMINGTON TRUST, NATIONAL ASSOCIATION reassignment WILMINGTON TRUST, NATIONAL ASSOCIATION SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CITRIX SYSTEMS, INC.
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: CITRIX SYSTEMS, INC., TIBCO SOFTWARE INC.
Assigned to GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT reassignment GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT SECOND LIEN PATENT SECURITY AGREEMENT Assignors: CITRIX SYSTEMS, INC., TIBCO SOFTWARE INC.
Assigned to WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT reassignment WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: CITRIX SYSTEMS, INC., TIBCO SOFTWARE INC.
Assigned to CITRIX SYSTEMS, INC., CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.) reassignment CITRIX SYSTEMS, INC. RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001) Assignors: GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT
Assigned to WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT reassignment WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: CITRIX SYSTEMS, INC., CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.)
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/78Television signal recording using magnetic recording
    • H04N5/782Television signal recording using magnetic recording on tape
    • H04N5/783Adaptations for reproducing at a rate different from the recording rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44008Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6587Control parameters, e.g. trick play commands, viewpoint selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/91Television signal processing therefor

Definitions

  • the present invention relates to methods and systems for playback of remote presentation protocols and, in particular, for capturing, replaying, highlighting and real-time seeking of text or characters entered in a recorded session during playback of remote presentation protocols.
  • Remote presentation protocols such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash., are inherently stateful. In order to view a particular point in a stream of recorded presentation protocol data, playback of the stream must begin from the very beginning of stream and must be played back sequentially until the desired point is encountered.
  • Keyframes are typically stored within the stream itself as synchronization points so that frames may be quickly reproduced on a screen.
  • Delta frames typically describe differences from previous frames to produce the visible video frame.
  • keyframes Since remote presentation protocols are typically compact due to their stateful nature, the additional storage of keyframes increases file size by several orders of magnitude. Even with modern digital video compression techniques, keyframes generally add several orders of magnitude to the storage required for a stream of recorded presentation protocol data. However, omitting keyframes results in a non-seekable protocol. A method for seekability without the overhead of oversized files caused by stored keyframes is desirable.
  • Server-side recording of remote presentation protocols is useful in authoring training material, providing helpdesk support, enabling tutorials, or for environments where distributing software to each client workstation is cumbersome.
  • many conventional methods for recording protocol data streams suffer from drawbacks such as inefficient and lossless encoding of computer screen activity. Recording and storing files solely on the server may create issues regarding the handling of large numbers of concurrent sessions. Many conventional systems typically suffer the drawbacks of recording significantly more data than will ever be reviewed, involving complex recording processes or generating large file sizes.
  • Some conventional methods for recording protocol data streams are not bound to the remote presentation protocol itself. Many of these solutions involve screen scraping/capture technologies or hooking of the client graphics engine and as a result suffer the drawback of requiring a processor-intensive encoding or transcoding process for playback. Furthermore, these conventional methods for recording protocol streams are not capable of detecting text included in video frame data at, seekability of the captured text using target words, or replaying a recorded stream of video data out of sequential order based on detected characters or text.
  • the present invention provides a method for recording as a stream remote presentation protocols such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash., as well as enabling playback of the recorded stream at a later time.
  • the present invention extends protocols initially designed for the live display of computer screen presentation into lossless real-time screen activity capture that can be recorded, without modification of the existing protocol definitions. Unlike traditional screen capture technology, recording does not need to take place on the client device or require any client-side components.
  • Server-side recording greatly simplifies deployment by allowing installation of recording software only on server machines instead of on many client devices.
  • the ratio of client devices to server machines is regularly higher than 100 to 1.
  • the present invention also makes remote presentation protocols, such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash., sequentially playable as a video format, and also permits random seeking/browsing without the use of stored keyframes based on text displayed on a computing device such as a client device. Text based seeking allows a user viewing the stream during playback to search through various frames using a target word search, skip to any position, forward or backward, in the stream and continue playback in a responsive fashion.
  • the present invention makes very fast seeking possible without recording or storing keyframes.
  • the present invention relates to a method for recording and replaying server-generated data.
  • the method includes the steps of storing a plurality of packets sent to a client device, rendering, by a protocol engine, at least one stored packet in the plurality of stored packets to a local video buffer and analyzing the at least one rendered packet with wherein analyzing includes at least scanning the at least one rendered packet with an optical character recognizer executing on the server.
  • the method described herein also discloses using the optical character recognizer to generate a word associated with the at least one packet, using a post processing component to generate identification data associated with the generated word associated with the at least one packet, and storing the generated word associated with the at least one packet and storing the identification data associated with the generated word.
  • the present invention relates to a system for recording and replaying server-generated data
  • a storage device configured to store, a plurality of packets sent to a client device, a protocol engine, configured to render at least one stored packet in the plurality of stored packets to a local video buffer and an optical character recognition device executing on the server configured to analyze the at least one rendered packet wherein analyzing includes at least scanning the at least one rendered packet to generate a word associated with the at least one packet.
  • the system further includes a post processing component configured to generate identification data associated with the generated word associated with the at least one packet and a database configured to store the generated word associated with the at least one packet and also configured to store the identification data associated with the generated word.
  • FIG. 1A is a block diagram depicting an embodiment of a network environment comprising client machines in communication with remote machines;
  • FIG. 1B and FIG. 1C are block diagrams depicting embodiments of computers useful in connection with the methods and systems described herein;
  • FIG. 2 is a block diagram depicting an embodiment of the network 200 in which the present invention may be performed;
  • FIG. 3 and FIG. 4 are block diagrams depicting alternate embodiments of placements for a recorder on the network 200 ;
  • FIG. 5 is a block diagram depicting one embodiment of a system for regenerating display data represented by a protocol data stream
  • FIG. 6A is a flow diagram depicting a method for recording and replaying server-generated data
  • FIG. 6B is a flow diagram depicting a method for retrieving specific server generated data
  • FIG. 7 is a block diagram depicting in greater detail a recorder in a system for recording display data represented by a protocol data stream;
  • FIG. 8 depicts one embodiment of a recording of a protocol data stream
  • FIG. 9 is a flow diagram depicting one embodiment of the steps taken in a method for real-time seeking during playback of stateful remote presentation protocols
  • FIG. 10 is a flow diagram depicting one embodiment of the steps taken to generate state-snapshots enabling real-time seeking during playback of remote presentation protocols
  • FIG. 11 is a block diagram depicting a system for real-time seeking during playback of stateful remote presentation protocols
  • FIG. 12 is a flow diagram depicting one embodiment of steps taken for adaptive generation of state-snapshots
  • FIG. 13 is a diagram depicting three types of seek probability distributions of one embodiment
  • FIG. 14 is a diagram depicting one embodiment of generating state-snapshots responsive to a determined seek probability distribution
  • FIG. 15 depicts one embodiment of a usage pattern for a user of a presentation of a protocol data stream
  • FIG. 16 is a block diagram depicting one embodiment of a system for adaptive generation of state-snapshots, including a background protocol engine, a foreground protocol engine, a protocol data stream, an activity profile, and a state-snapshot;
  • FIG. 17 is a block diagram depicting one embodiment of a system for rendering a recorded session
  • FIG. 18 a flow diagram depicts one embodiment of the steps taken to generate playback instructions for playback of a recorded computer session
  • FIG. 19 is a flow diagram depicting one embodiment of the steps taken in a method for playback of a recorded computer session
  • FIG. 20 is a flow diagram depicting one embodiment of the steps taken to generate playback instructions for rendering a recorded session
  • FIG. 21 depicts one embodiment of a regenerated recorded stream whose contents are rendered responsive to a playback data structure
  • FIG. 22 depicts one embodiment of certain packets in a recording stream having content representing meaningful user activity, in this embodiment a mouse input indicating an active mouse button state;
  • FIG. 23 is a flow diagram depicting one embodiment of the steps taken to eliminate periods with no meaningful activity in rendering a recorded session
  • FIG. 24 is a flow diagram depicting one embodiment of the steps taken to eliminate a graphics update in rendering a recorded session
  • FIG. 25 depicts one embodiment of rendering a regenerated recorded session responsive to whether the state of the screen region after a second graphics update varies from the state of the screen region after a first graphics update;
  • FIG. 26 is a flow diagram depicting one embodiment of the steps taken to eliminate interaction sequences in rendering a recorded session
  • FIG. 27 is a flow diagram depicting one embodiment of the steps taken in automatic time-warped playback in rendering a recorded computer session
  • FIG. 28 is a flow diagram depicting one embodiment of the steps taken for automatic time-warped playback responsive to an identified application in rendering a recorded computer session;
  • FIG. 29 is a block diagram depicting one embodiment of a system for automatic time-warped playback in rendering a recorded computer session
  • FIG. 30A is a block diagram depicting one embodiment of a system for recording and real-time playback of a presentation protocol layer data stream
  • FIGS. 30B , 30 C and 30 D are block diagrams depicting alternate embodiments of a system for recording and real-time playback of a presentation protocol layer data stream;
  • FIG. 31 is a flow diagram depicting one embodiment of the steps taken in a method for recording and real-time playback of a presentation protocol layer data stream;
  • FIG. 32 is a flow diagram depicting one embodiment of the steps taken in a method for real-time seeking during real-time playback of remote presentation layer protocol data;
  • FIG. 33 is a flow diagram depicting one embodiment of the steps taken in a method for generating state-snapshots enabling real-time seeking during real-time playback of a presentation layer protocol data stream;
  • FIG. 34 is a flow diagram depicting one embodiment of the steps taken in a method for adaptive generation of state-snapshots.
  • Methods and systems provide playback of recorded presentation layer protocol sessions capable of enhanced playback based on text or characters entered during the recorded presentation layer protocol sessions.
  • the technology builds on the methods and systems for recording and playback of presentation layer protocol sessions, which are also described herein.
  • Some embodiments of methods and playback of presentation layer protocol sessions provide functionality for playback after the completion of a recording and after creation of a recorded protocol data stream. In other embodiments, however, methods and systems provide functionality for playback of a protocol data stream during the recording of a protocol data stream. In one of these embodiments, the methods and systems also provide functionality for playback of a completed recording of a protocol data stream. In another of these embodiments, the methods and systems provide a range of playback controls, including, but not limited to the ability to watch a recording from the beginning, seek forward and backward, pause, fast forward, frame advance and so on. In some embodiments, optical character recognition can be used to recognize characters or text contained captured in the recording and the captured characters or texts can further be used to customize playback of the recording. In addition, the captured character or text can also be used in data analysis techniques such as determining which words are recorded most frequently across all or a subset of client devices. Data analysis may also include determining what characters or words are recorded at particular times.
  • the methods and systems described herein provide for time-shifted playback (or time-shifting), a term borrowed from the video industry.
  • DVRs Digital Video Recorders
  • TIVO brand time-shifting technology.
  • These products provide consumers significant advantages over the traditional VCR; including the ability to start watching a recorded TV program before it is over. This benefit is also provided for users of the methods and systems described herein.
  • the functionality greatly enhances the usability of these methods and systems as a surveillance and monitoring tool where response time to suspicious activity might be important. It is now possible to catch suspicious end users in the act of violating policies or other inappropriate use of computing or networking resources. Additionally, for embodiments in which the technology is used in a customer support scenario, the support technician now has the ability to watch exactly what the user did before they requested assistance and then instantly jump back “live” to watch what the user is about to do. This provides a significant opportunity in the support market as no existing session recording products provide this combined live and retrospective playback feature. Additional administrative benefits are provided since the methods and systems described herein have little, if any, impact on the performance, scalability, manageability or usability of the system.
  • the features provided by these methods and systems function in ways to similar to the ways in which the post-recording playback systems and methods described herein.
  • the network environment comprises one or more clients 102 a - 102 n (also generally referred to as local machine(s) 102 , or client(s) 102 ) in communication with one or more servers 106 a - 106 n (also generally referred to as server(s) 106 , or remote machine(s) 106 ) via one or more networks 104 .
  • clients 102 a - 102 n also generally referred to as local machine(s) 102 , or client(s) 102
  • servers 106 a - 106 n also generally referred to as server(s) 106 , or remote machine(s) 106
  • FIG. 1A shows a network 104 between the clients 102 and the servers 106
  • the network 104 can be a local-area network (LAN), such as a company Intranet, a metropolitan area network (MAN), or a wide area network (WAN), such as the Internet or the World Wide Web.
  • LAN local-area network
  • MAN metropolitan area network
  • WAN wide area network
  • a network 104 ′ may be a private network and a network 104 may be a public network.
  • a network 104 may be a private network and a network 104 ′ a public network.
  • networks 104 and 104 ′ may both be private networks.
  • the network 104 may be any type and/or form of network and may include any of the following: a point to point network, a broadcast network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an ATM (Asynchronous Transfer Mode) network, a SONET (Synchronous Optical Network) network, a SDH (Synchronous Digital Hierarchy) network, a wireless network and a wireline network.
  • the network 104 may comprise a wireless link, such as an infrared channel or satellite band.
  • the topology of the network 104 may be a bus, star, or ring network topology.
  • the network 104 and network topology may be of any such network or network topology as known to those ordinarily skilled in the art capable of supporting the operations described herein.
  • the network may comprise mobile telephone networks utilizing any protocol or protocols used to communicate among mobile devices, including AMPS, TDMA, CDMA, GSM, GPRS or UMTS.
  • AMPS AMPS
  • TDMA Time Division Multiple Access
  • CDMA Code Division Multiple Access
  • GSM Global System for Mobile communications
  • GPRS Global System for Mobile communications
  • UMTS Universal Mobile communications
  • the system may include multiple, logically-grouped servers 106 .
  • the logical group of servers may be referred to as a server farm 38 .
  • the servers 106 may be geographically dispersed.
  • a farm 38 may be administered as a single entity.
  • the server farm 38 comprises a plurality of server farms 38 .
  • the server farm executes one or more applications on behalf of one or more clients 102 .
  • the servers 106 within each farm 38 can be heterogeneous.
  • One or more of the servers 106 can operate according to one type of operating system platform (e.g., WINDOWS NT, Windows Server 2003, Windows Server 2008 or Windows 7, manufactured by Microsoft Corp. of Redmond, Wash.), while one or more of the other servers 106 can operate on according to another type of operating system platform (e.g., Unix or Linux).
  • the servers 106 of each farm 38 do not need to be physically proximate to another server 106 in the same farm 38 .
  • the group of servers 106 logically grouped as a farm 38 may be interconnected using a wide-area network (WAN) connection or a metropolitan-area network (MAN) connection.
  • WAN wide-area network
  • MAN metropolitan-area network
  • a farm 38 may include servers 106 physically located in different continents or different regions of a continent, country, state, city, campus, or room. Data transmission speeds between servers 106 in the farm 38 can be increased if the servers 106 are connected using a local-area network (LAN) connection or some form of direct connection.
  • LAN local-area network
  • Server 106 may be a file server, application server, web server, proxy server, appliance, network appliance, gateway, application gateway, gateway server, virtualization server, deployment server, SSL VPN server, or firewall.
  • a server 106 may have the capacity to function as either an application server or as a master application server.
  • a server 106 may include an Active Directory.
  • the remote machine 106 may be an application acceleration appliance.
  • the remote machine 106 may provide functionality including firewall functionality, application firewall functionality, or load balancing functionality.
  • the remote machine 106 comprises an appliance such as one of the line of appliances manufactured by the Citrix Application Networking Group, of San Jose, Calif., or Silver Peak Systems, Inc., of Mountain View, Calif., or of Riverbed Technology, Inc., of San Francisco, Calif., or of F5 Networks, Inc., of Seattle, Wash., or of Juniper Networks, Inc., of Sunnyvale, Calif.
  • the clients 102 may also be referred to as client nodes, client machines, endpoint nodes, or endpoints.
  • a client 102 has the capacity to function as both a client node seeking access to resources provided by a server and as a server providing access to hosted resources for other clients 102 a - 102 n.
  • the server 106 or a server farm 38 may be running one or more applications, such as an application providing a thin-client computing or remote display presentation application.
  • the server 106 or server farm 38 executes as an application, any portion of the Citrix Access SuiteTM by Citrix Systems, Inc., such as the XenDesktop and/or any of the MICROSOFT WINDOWS Remote Desktop Services manufactured by the Microsoft Corporation.
  • the application includes a Remote Desktop (RDP) client, developed by Microsoft Corporation of Redmond, Wash., or an X11 client, maintained by the open source X.org Foundation.
  • RDP Remote Desktop
  • the server 106 may run an application, which for example, may be an application server providing email services such as MICROSOFT EXCHANGE manufactured by the Microsoft Corporation of Redmond, Wash., a web or Internet server, or a desktop sharing server, or a collaboration server.
  • any of the applications may comprise any type of hosted service or products, such as GOTOMEETING provided by Citrix Online Division, Inc. of Santa Barbara, Calif., WEBEX provided by WebEx, Inc. of Santa Clara, Calif., or Microsoft Office LIVE MEETING provided by Microsoft Corporation of Redmond, Wash.
  • a client 102 may execute, operate or otherwise provide an application, which can be any type and/or form of software, program, or executable instructions such as any type and/or form of web browser, web-based client, client-server application, a thin-client computing client, an ActiveX control, or a Java applet, or any other type and/or form of executable instructions capable of executing on client 102 .
  • the application may be a server-based or a remote-based application executed on behalf of the client 102 on a server 106 .
  • the server 106 may display output to the client 102 using any thin-client or remote-display protocol, such as the Independent Computing Architecture (ICA) protocol manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla.
  • ICA Independent Computing Architecture
  • the application can use any type of protocol and it can be, for example, an HTTP client, an FTP client, an Oscar client, or a Telnet client.
  • the application comprises any type of software related to voice over internet protocol (VoIP) communications, such as a soft IP telephone.
  • VoIP voice over internet protocol
  • the application comprises any application related to real-time data communications, such as applications for streaming video and/or audio.
  • FIGS. 1B and 1C depict block diagrams of a computing device 100 useful for practicing an embodiment of the client 102 or a server 106 .
  • each computing device 100 includes a central processing unit 121 , and a main memory unit 122 .
  • a computing device 100 may include a visual display device 124 , a keyboard 126 and/or a pointing device 127 , such as a mouse.
  • each computing device 100 may also include additional optional elements, such as one or more input/output devices 130 a - 130 b (generally referred to using reference numeral 130 ), and a cache memory 140 in communication with the central processing unit 121 .
  • the central processing unit 121 is any logic circuitry that responds to and processes instructions fetched from the main memory unit 122 .
  • the central processing unit is provided by a microprocessor unit, such as: those manufactured by Intel Corporation of Mountain View, Calif.; those manufactured by Motorola Corporation of Schaumburg, Ill.; those manufactured by Transmeta Corporation of Santa Clara, Calif.; the RS/6000 processor, those manufactured by International Business Machines of White Plains, N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale, Calif.
  • the computing device 100 may be based on any of these processors, or any other processor capable of operating as described herein.
  • Main memory unit 122 may be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor 121 , such as Static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM).
  • SRAM Static random access memory
  • BSRAM SynchBurst SRAM
  • DRAM Dynamic random access memory
  • FPM DRAM Fast Page Mode DRAM
  • EDRAM Extended Data
  • the main memory 122 may be based on any of the above described memory chips, or any other available memory chips capable of operating as described herein.
  • the processor 121 communicates with main memory 122 via a system bus 150 (described in more detail below).
  • FIG. 1B depicts an embodiment of a computing device 100 in which the processor communicates directly with main memory 122 via a memory port 103 .
  • the main memory 122 may be DRDRAM.
  • FIG. 1C depicts an embodiment in which the main processor 121 communicates directly with cache memory 140 via a secondary bus, sometimes referred to as a backside bus.
  • the main processor 121 communicates with cache memory 140 using the system bus 150 .
  • Cache memory 140 typically has a faster response time than main memory 122 and is typically provided by SRAM, BSRAM, or EDRAM.
  • the processor 121 communicates with various I/O devices 130 via a local system bus 150 .
  • FIG. 1C depicts an embodiment of a computer 100 in which the main processor 121 communicates directly with I/O device 130 b via HyperTransport, Rapid I/O, or InfiniBand.
  • FIG. 1C also depicts an embodiment in which local busses and direct communication are mixed: the processor 121 communicates with I/O device 130 a using a local interconnect bus while communicating with I/O device 130 b directly.
  • the computing device 100 may support any suitable installation device 116 , such as a floppy disk drive for receiving floppy disks such as 3.5-inch, 5.25-inch disks or ZIP disks, a CD-ROM drive, a CD-R/RW drive, a DVD-ROM drive, tape drives of various formats, USB device, hard-drive or any other device suitable for installing software and programs such as any client agent 120 , or portion thereof.
  • the computing device 100 may further comprise a storage device 128 , such as one or more hard disk drives or redundant arrays of independent disks, for storing an operating system and other related software, and for storing application software programs such as any program related to the client agent 120 .
  • any of the installation devices 116 could also be used as the storage device.
  • the operating system and the software can be run from a bootable medium, for example, a bootable CD, such as KNOPPIX®, a bootable CD for GNU/Linux that is available as a GNU/Linux distribution from knoppix.net.
  • a bootable CD such as KNOPPIX®
  • KNOPPIX® a bootable CD for GNU/Linux that is available as a GNU/Linux distribution from knoppix.net.
  • the computing device 100 may include a network interface 118 to interface to a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25), broadband connections (e.g., ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above.
  • the network interface 118 may comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device 100 to any type of network capable of communication and performing the operations described herein.
  • I/O devices 130 a - 130 n may be present in the computing device 100 .
  • Input devices include keyboards, mice, trackpads, trackballs, microphones, and drawing tablets.
  • Output devices include video displays, speakers, inkjet printers, laser printers, and dye-sublimation printers.
  • the I/O devices may be controlled by an I/O controller 123 as shown in FIG. 1B .
  • the I/O controller may control one or more I/O devices such as a keyboard 126 and a pointing device 127 , e.g., a mouse or optical pen.
  • an I/O device may also provide storage and/or an installation medium 116 for the computing device 100 .
  • the computing device 100 may provide USB connections to receive handheld USB storage devices such as the USB Flash Drive line of devices manufactured by Twintech Industry, Inc. of Los Alamitos, Calif.
  • the computing device 100 may comprise or be connected to multiple display devices 124 a - 124 n , which each may be of the same or different type and/or form.
  • any of the I/O devices 130 a - 130 n and/or the I/O controller 123 may comprise any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable or provide for the connection and use of multiple display devices 124 a - 124 n by the computing device 100 .
  • the computing device 100 may include any type and/or form of video adapter, video card, driver, and/or library to interface, communicate, connect or otherwise use the display devices 124 a - 124 n .
  • a video adapter may comprise multiple connectors to interface to multiple display devices 124 a - 124 n .
  • the computing device 100 may include multiple video adapters, with each video adapter connected to one or more of the display devices 124 a - 124 n .
  • any portion of the operating system of the computing device 100 may be configured for using multiple displays 124 a - 124 n .
  • one or more of the display devices 124 a - 124 n may be provided by one or more other computing devices, such as computing devices 100 a and 100 b connected to the computing device 100 , for example, via a network.
  • These embodiments may include any type of software designed and constructed to use another computer's display device as a second display device 124 a for the computing device 100 .
  • a computing device 100 may be configured to have multiple display devices 124 a - 124 n.
  • an I/O device 130 may be a bridge 170 between the system bus 150 and an external communication bus, such as a USB bus, an Apple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a Super HIPPI bus, a SerialPlus bus, a SCI/LAMP bus, a FibreChannel bus, or a Serial Attached small computer system interface bus.
  • an external communication bus such as a USB bus, an Apple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a Super HIPPI bus, a SerialPlus bus, a SCI/LAMP bus, a FibreChannel bus, or
  • a computing device 100 of the sort depicted in FIGS. 1B and 1C typically operates under the control of operating systems, which control scheduling of tasks and access to system resources.
  • the computing device 100 can be running any operating system such as any of the versions of the MICROSOFT WINDOWS operating systems, the different releases of the Unix and Linux operating systems, any version of the MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described herein.
  • Typical operating systems include: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, Windows Server 2003, Windows Server 2008, Windows 7 and WINDOWS XP, all of which are manufactured by Microsoft Corporation of Redmond, Wash.; MAC OS, manufactured by Apple Computer of Cupertino, Calif.; OS/2, manufactured by International Business Machines of Armonk, N.Y.; and Linux, a freely-available operating system distributed by Caldera Corp. of Salt Lake City, Utah, or any type and/or form of a Unix operating system, among others.
  • the computing device 100 may have different processors, operating systems, and input devices consistent with the device.
  • the computing device 100 is a Treo 180, 270, 600, 650, 680, 700p or 700w smart phone manufactured by Palm, Inc.
  • the Treo smart phone is operated under the control of the PalmOS operating system and includes a stylus input device as well as a five-way navigator device.
  • the computing device 100 is a mobile device, such as a JAVA-enabled cellular telephone or personal digital assistant (PDA), such as the i55sr, i58sr, i85s, i88s, i90c, i95cl, or the im11000, all of which are manufactured by Motorola Corp. of Schaumburg, Ill., the 6035 or the 7135, manufactured by Kyocera of Kyoto, Japan, or the i300 or i330, manufactured by Samsung Electronics Co., Ltd., of Seoul, Korea.
  • PDA personal digital assistant
  • the computing device 100 is a Blackberry handheld or smart phone, such as the devices manufactured by Research In Motion Limited, including the Blackberry 7100 series, 8700 series, 7700 series, 7200 series, the Blackberry 7520, or the Blackberry Pearl 8100.
  • the computing device 100 is a smart phone, Pocket PC, Pocket PC Phone, or other handheld mobile device supporting Microsoft Windows Mobile Software.
  • the computing device 100 can be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile telephone, any other computer, or other form of computing or telecommunications device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described herein.
  • FIG. 2 a block diagram depicts an embodiment of the network 200 in which the invention may be performed, including a first device 202 , a remote presentation protocol server engine 204 , a recorder 206 , a protocol data stream 208 , a recorded protocol data stream 210 , a second device 212 , a remote presentation protocol client engine 214 , a display 216 , a storage element 218 , and a recorded protocol data stream 220 .
  • the first device 202 may be a server device, for example, and the second device 212 may be a client device, for example.
  • the recorder 206 intercepts a protocol data stream 224 transmitted from the second device 212 .
  • the intercepted protocol data stream 224 comprises a recorded client session which may include data associated with user input data.
  • the recorded client session may also include display data, such as pixel data, used to show information to a user at display 216 .
  • the protocol data stream 224 may comprise a virtual channel such as a virtual channel supporting thinwire data packets. The recorder 206 , then copies at least one packet from the protocol data stream 224 and creates a recording of the protocol data stream 224 using the at least one copied packet at recorder 206 according to one embodiment.
  • protocol data stream 222 delivers a computer program funning on first device 202 and being displayed remotely on display 216 for a user.
  • the user may interact with the computer program with I/O device 144 .
  • These user interactions such as mouse movements, keyboard screen updates and other display data may be transmitted back to the first device 202 and recorded at recorder 206 .
  • a first device 202 transmits a protocol data stream 208 to a second device 212 .
  • the first device 202 uses a remote presentation protocol server engine 204 to transmit the protocol data stream 208 to the second device 212 .
  • the second device 212 uses a remote presentation protocol client engine 214 to receive the protocol data stream 208 from the first device 202 .
  • the remote presentation protocols comprise a thin-client protocol such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash.
  • the protocol data stream 208 comprises a plurality of packets at least some of which represent display data.
  • the packets may comprise data packets transmitted on a thinwire virtual channel according to one exemplary embodiment.
  • the protocol data stream 208 comprises information about a recorded session.
  • the protocol data stream 208 comprises metadata.
  • the protocol data stream 208 comprises information about the user in a recorded session.
  • the protocol data stream 208 comprises information about the server generating the recorded data.
  • the protocol data stream 208 comprises a timestamp.
  • the display data includes pixel data corresponding to text or characters captured during a recorded session.
  • the protocol data stream 208 comprises multiple channels, such as virtual channels including a thinwire virtual channel, for example.
  • a channel comprises a peer-to-peer connection over which data is transferred.
  • the protocol data stream 208 comprises multiple virtual channels.
  • the second device 212 receives the protocol data stream 224 and, in some embodiments, uses a remote presentation protocol client engine 214 to display data sent from second device 212 on a display 216 . Processing the protocol data stream 224 allows the second device 212 to present a display to a user through display 216 .
  • first device 202 transmits a computer application to be displayed on display 216 for interaction with a user.
  • the user may interact with the protocol data stream 222 shown on display 216 with input/output (I/O) device 144 .
  • the I/O device 144 may be connected as shown by elements 123 , 130 a , or 130 b in FIGS. 1B and 1C .
  • the I/O device 144 may be a keyboard, mouse, touch screen, wireless device, or any other device capable of detecting user input.
  • the second device 212 may use the remote presentation protocol client engine 214 to process the display data.
  • the display includes, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these.
  • the recorder 206 intercepts the protocol data stream 224 sent from the first device 202 , server, to the second device 212 , such as a client device according to one exemplary embodiment.
  • the protocol data stream 224 may include display data including associated with a computer application or text displayed in response to a user input, for example.
  • Some examples of text included in display data may include text in application window titles, text in start menu items, text in desktop shortcut names, text in documents opened by a user, text displayed while browsing the internet using an internet browser application, or text that appears in videos that are rendered and displayed, for example.
  • text copied and pasted through a clipboard functionality by a user can also be recorded according to one embodiment.
  • text entered into password windows is not recorded since the display data interprets password information as * characters according to one exemplary embodiment. User initiated editing to text such as deleting, entering spaces, or using mouse commands can also be recorded.
  • the recorder 206 intercepts one or more channels of the protocol data stream 224 . In another embodiment, the recorder 206 intercepts the protocol data stream 224 by intercepting one or more virtual channels such as a thinwire virtual channel. In some embodiments, the recorder 206 monitors one or more virtual channels over which the first device 202 may transmit the protocol data stream 224 to the second device 212 . The recorder 206 copies at least one packet from the protocol data stream. In one embodiment, the recorder 206 determines to copy a particular packet of the protocol data stream responsive to a policy. In some embodiments, the policy defines the packets the recorder 206 records based upon the type of data contained within the packet.
  • the recorder 206 determines to copy a packet of the protocol data stream based upon a determination of whether the packet contains data. In some of these embodiments, the recorder 206 does not record empty packets while in others of these embodiments, the recorder 206 does record empty packets. In some embodiments, the recorder 206 records every packet in the protocol data stream 224 .
  • the recorder 206 creates a recorded protocol data stream 210 using the at least one copied packet.
  • the recorder 206 associates information with the at least one copied packet.
  • the recorder 206 associates a time stamp with the at least one copied packet.
  • the recorder 206 associates a data length indicator with the packet.
  • the recorder 206 may embed this information into the recorded protocol data stream 210 in addition to the packet or the recorder 206 may embed this information directly into the packet, or the recorder 206 may store the association in a location separate from the packet and the recorded protocol data stream 210 .
  • the recorder 206 may reside on the first device 202 . However, the location of the recorder may reside in any number of locations or devices.
  • FIG. 3 depicts an embodiment in which the recorder 206 resides on the second device, 212 .
  • FIG. 4 depicts an embodiment in which the recorder 206 resides on a third device 222 .
  • the devices on which the recorder 206 may reside include client computing systems, server computing systems, proxy server computing systems, network packet sniffing computing systems, protocol analyzer computing systems, and passthrough server computing systems.
  • the recorder 206 creates the recorded protocol data stream 210 by copying at least one packet and, in some embodiments, information associated with the at least one packet.
  • the recorder 206 stores the recording of the protocol data stream 210 after creating it.
  • the recorder 206 stores the recording of the protocol data stream 210 to a storage element 218 .
  • the storage element 218 may comprise persistent storage, such as a hard drive, floppy drive, CD-RW, DVD-RW, or any other device, which maintains data state when power is removed.
  • the storage element may comprise one or more volatile memory elements, such as Static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM).
  • SRAM Static random access memory
  • BSRAM SynchBurst SRAM
  • DRAM Dynamic random access memory
  • FPM DRAM Fast Page Mode DRAM
  • EDRAM Enhanced DRAM
  • EDO RAM Extended Data Output RAM
  • EDRAM Extended Data Output RAM
  • the storage element 218 comprises a network storage device.
  • the storage element 218 may reside on the first device 202 or on a second device 212 .
  • the storage element 218 resides on a third device, such as a proxy server computing device or a pass through server computing device.
  • the storage element 218 resides on a network and the recorder 206 accesses the storage element 218 over the network to store the recording of the protocol data stream 220 .
  • the recorder 206 stores the recording of the protocol data stream on the same device on which the recorder 206 resides.
  • a block diagram depicts a protocol engine 502 reading at least one copied packet from the recording of the protocol data stream 506 and using the information associated with the at least one copied packet to regenerate the display data represented by the protocol data stream 506 .
  • the protocol engine 502 receives the protocol data stream 506 .
  • the protocol engine 502 retrieves the protocol data stream 506 from a storage element 518 .
  • the protocol engine 502 retrieves the protocol data stream 506 from a recorder 206 .
  • the protocol engine 502 retrieves the protocol data stream 506 from another computing device.
  • the protocol engine 502 comprises a packet reader 508 and a display data regeneration element 510 .
  • Display data regeneration element 510 may include an OCR library 520 , storage device 524 , search engine 526 and video player 528 according to one exemplary embodiment.
  • the packet reader 508 reads at least one copied packet from the recording of the protocol data stream 506 .
  • the packet reader 508 reads the at least one copied packet sequentially from the recording of the protocol data stream 506 .
  • the protocol engine 502 processes the at least one copied packet and any information associated with the at least one copied packet.
  • the protocol engine 502 may render the contents of the at least one copied packet and output the rendered packets to a video buffer element 512 , in one exemplary embodiment.
  • protocol engine 502 renders an ICA packet or other virtual channel packets such as thinwire packets stored in an ICL file format.
  • the ICL packets are converted from an ICL file format into a local video buffer file format using existing thinwire player technology.
  • processing includes rendering in a perceptible manner the contents of the at least one copied packet.
  • the regenerated display may include, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these.
  • the protocol engine 502 resides on the first device 202 . In other embodiments, the protocol engine 502 resides on the second device 212 . In still other embodiments the protocol engine resides on a third device, such as a proxy server computing device or a pass through server computing device.
  • the local video buffer (LVB) files 540 corresponding to protocol data stream packets 506 are analyzed by a post recording software program that may be stored in memory at playback device 514 .
  • the post recording software program implements an optical character recognition library (OCR) 520 .
  • OCR 520 the LVB files are scanned by an post recording software program to generate characters or words.
  • the post recording software program can be any of several suitable OCR software programs including but not limited to open source OCR libraries such as Tesseract of Google OCRopus.
  • the OCR libraries may be able to recognize English text, non-English text or a combination of both.
  • Embodiments capable of generating words in multiple languages may be facilitated by capturing, storing and cataloging characters by representing them in the Unicode Standard, which represents text from different languages in a universal character set.
  • the OCR library may provide identification data such as spatial correspondence data indicating the spatial coordinates of the word with respect to a video frame the word is contained in.
  • the spatial correspondence data may be determined from bounding rectangle information such as position, width and height of the word in the recorded session.
  • the generated words 522 are also associated with other identification data such as timing data according to one exemplary embodiment.
  • the timing data may indicate when the generated word appeared in a sequential order of video frames as well as when the generated word ceased to appear in a subsequent video frame.
  • the generated words 522 are also associated with still other identification data such as particular recording file identifiers.
  • the recording file identifiers could be used in data analysis such as determining which words are recorded most frequently across all or a subset of client devices. Data analysis may also include determining what characters or words are recorded at particular times.
  • the generated words and identification data can be searched by search engine 526 .
  • a user such as an administrator may desire to play back a recorded session from a client device captured by recorder 206 using video player device 528 . However, the user may wish to play back only certain portions of the recorded session, such as portions of the recorded session that contains display data that includes specific words or target words. If the user desires to only see portions of the recorded session that includes a single target words or multiple target words, those words can be entered into video player 528 through an I/O device 144 .
  • video playback device 528 may automatically scan for target words without user input. Once a target word is selected at video playback device 528 , search engine 526 selects the target words and data associated with the target words from storage device 528 , according to one exemplary embodiment. Data associated with the target words may include video frames or data packets. Once these video frames or data packets are determined, video playback device may selectively display the video frames or data packets at display 530 such that a user may view the frames associated with target words consecutively rather than viewing the sequence of video frames in the sequence recorded in the recorded session.
  • video player 528 may also perform various post-processing functions on the video frames or data packets which are associated with targeted words.
  • the video player 528 may be commanded to highlight target words within each displayed video frame using the bounding rectangle information such as position, width and height according to user input through I/O device 144 .
  • the video player may highlight the words by graphically overlaying highlights over the words of interest or by manipulating the color of pixel data surrounding the target words, for example.
  • FIG. 7 a block diagram depicts in greater detail the recorder 702 , originally described as recorder 206 in FIG. 2 .
  • the recorder 702 records server-generated data through interception of a protocol data stream 710 and through the creation of a recording 712 of the protocol data stream 710 .
  • the recorder 702 includes, in one embodiment, a protocol data stream interceptor 704 , a packet copier 706 , and a recording generator 708 .
  • the recorder 702 uses the protocol data stream interceptor 704 to monitor the protocol data stream 710 .
  • the recorder 702 uses the protocol data stream interceptor 702 to intercept a protocol data stream 710 comprising a plurality of packets transmitted from a first device 202 to a second device 212 .
  • the packet copier 706 copies at least one packet of the protocol data stream.
  • the packet copier 706 determines whether or not to copy a packet in the protocol data stream. In some embodiments, the packet copier 706 makes this determination responsive to a policy. In these embodiments, the packet copier 706 may determine to copy a packet based on whether or not the packet contains any data or on the type of data contained within the packet.
  • the recorder 702 utilizes a recording generator 708 to create a recording of the protocol data stream using the at least one copied packet.
  • the recording generator assembles the at least one copied packet into a recording 712 of the protocol data stream 710 .
  • the recording generator 708 embeds information into the recording of the protocol data stream. This information may comprise, without limitation, time references indicating when to regenerate the display data represented by the data contained within the packet, data length indicators descriptive of the data contained within the packet, or other types of information used to regenerate the display data represented by the data contained within the protocol data stream 710 .
  • FIG. 8 depicts one embodiment of the recording 712 of the protocol data stream 710 .
  • the recording generator 708 has grouped at least one copied packet into remote presentation protocol data chunks.
  • the recording generator 708 associated a time reference and a data length with each remote presentation protocol data chunk and assembled the information and the packets together into the recording 712 of the protocol data stream 710 .
  • the recorder 702 stores the completed recording 712 of the protocol data stream 710 to a storage element 714 .
  • the storage element is located on a network and the recorder 702 transmits the recording 712 over a network to the storage element 714 .
  • the storage element is located on a proxy server computing device.
  • the storage element is located on a passthrough server computing device.
  • the storage element 714 resides on the same device as the recorder 702 .
  • a system for recording and playback of a protocol data stream comprises the recorder 702 as well as the playback device 514 discussed in FIG. 5 .
  • the playback device 514 includes the protocol engine 502 , which uses the packet reader 508 to receive and read at least one copied packet from the recording 712 of the packet data stream and uses the embedded information to regenerate the display data represented by the recording 712 of the protocol data stream.
  • the protocol engine 502 reads the packets sequentially in regenerating the display data.
  • a system for recording and replaying server-generated data comprises a recorder 702 , a storage element 714 , and a protocol engine 502 .
  • the recorder 702 generates a recording of a protocol data stream and stores the recording 712 in the storage element 714 .
  • the recorder copies at least one packet from the protocol data stream and associates information with the at least one packet, including but not limited to a time reference or a data length indicator describing a length of data in the packet.
  • the protocol engine 502 in communication with the storage element 714 , reads at least one packet from the recording of the protocol data stream and uses information associated with the at least one packet to regenerate the display data represented by the recording 712 of the protocol data stream 710 .
  • the recorder 702 , protocol engine 502 , or storage element 714 may be located, together or separately on the first device 202 . In other embodiments, they may be located, together or separately, on the second device 212 . In still other embodiments, they may reside, together or separately, on a third device, such as a proxy server computing device, a network packet sniffer, or a passthrough server computing device. In yet other embodiments, the storage element 714 may reside on a storage area network separately from the recorder 702 and the protocol engine 502 .
  • a flow diagram summarizes a method for recording and replaying server-generated data.
  • a recorder 206 intercepts a protocol data stream comprising a plurality of packets that are being transmitted, are going to be transmitted or have been transmitted from a second device, such as a client device, to a first device such as a server device.
  • the recorder 206 copies at least one packet from the protocol data stream 224 and creates a recording of the protocol data stream 224 at step 606 .
  • Protocol engine 502 later uses this recorded protocol data stream 210 to be played back for a user such as an administrator at a playback device 514 as shown in FIG. 5 as stated in steps 610 - 616 in FIG. 6A .
  • the previously recorded protocol data stream 210 or 220 is received at a packet reader 508 within protocol engine 502 .
  • the previously recorded protocol data stream may be in proximity to the device of initial recording 202 or may have been transmitted to another storage location 218 as shown in FIG. 2 .
  • the packet data files are rendered and sent to local video buffer 512 by protocol engine 502 in step 610 .
  • the rendered packet data is analyzed by a post recording software program with an optical character recognition library (OCR) 520 .
  • OCR 520 the LVB files are scanned by an OCR software program to generate characters or words.
  • the OCR software program can be any of several suitable OCR software programs including but not limited to open source OCR libraries such as Tesseract of Google OCRopus.
  • the OCR libraries may be able to recognize English text, non-English text or a combination of both.
  • Embodiments capable of generating words in multiple languages may be facilitated by capturing, storing and cataloging characters by representing them in the Unicode Standard, which represents text from different languages in a universal character set.
  • the characters or words generated at step 612 may optionally be processed to be converted to an optimal file format for storage at step 614 .
  • Post processing at step 614 may also create an association between the identification data or other additional packet data and a generated word prior to storing the generated word and additional packet data in storage device 524 so that when a stored word is searched by search engine 526 , the generated word as well as identification data may be uploaded to video player 528 .
  • the identification data may include spatial correspondence data such as the spatial coordinates of the word with respect to a video frame, bounding rectangle information such as position, width and height of the word, and timing data indicating when the generated word appeared in a sequential order of video frames or when the generated word ceased to appear in a subsequent video frame or a calculated duration of how long the word or character appeared in the recorded display data.
  • Timing data may be derived from the “Time Ref.” bit shown in the protocol data packet shown in FIG. 8 , according to one embodiment. This post processing may occur at the OCR library 520 or may alternatively occur at a separate module at playback device 514 .
  • FIG. 6B depicts a process for a user such as an administrator for real-time seeking during playback of stateful remote presentation protocols using target words.
  • a user such as an administrator for real-time seeking during playback of stateful remote presentation protocols using target words.
  • Step 620 may include a user entering a target word at I/O device 144 which is used by search engine 526 to query the contents of storage 524 for a match with the target word.
  • Search engine 526 may comprise a known look up table mechanism, a more sophisticated searching algorithm or any other searching mechanism known in the art.
  • the video playback device 528 regenerates display data by rendering the contents of a packet in the recording of a protocol data stream 506 that correspond to the target word to a viewer using the display 530 at steps 622 and 624 of FIG. 6 .
  • display data associated with the target word is sent to video playback device 528 at step 624 , the display data associated with the selected target word may be played at display 530 for a user such as an administrator.
  • the display data sent to display 530 may optionally be manipulated automatically or manually by user input via I/O device 144 at step 628 .
  • the video player 528 may be commanded to highlight the target words within each displayed video frame using the bounding rectangle information such as position, width and height according to user input through I/O device 144 .
  • the video player may highlight the words by graphically overlaying highlights over the words of interest or by manipulating the color of pixel data surrounding the target words according to one example.
  • FIG. 11 a block diagram depicts a system for real-time seeking during playback of stateful remote presentation protocols 1100 .
  • this figure depicts an embodiment of a playback device 514 (see FIG. 5 above) comprising two protocol engines 502 , a background protocol engine 1102 and a foreground protocol engine 1106 , as well as a state-snapshot 1104 and a display 1108 .
  • the background protocol engine 1102 receives a recording of a protocol data stream 1110 and reads the recording of the protocol data stream 1110 , which comprises a plurality of packets and represents display data.
  • the playback device 514 regenerates the display data by rendering the contents of at least one packet in the protocol data stream 1110 and displaying the results using the display 1108 .
  • the results include, without limitation, perceptible audio, visual, tactile, or olfactory presentations.
  • the background protocol engine 1102 enables a recipient of the rendered display data to seek for content in real-time during the presentation of a protocol data stream 1110 .
  • the background protocol engine 1102 generates at least one state-snapshot 1104 while reading at least one packet from the protocol data stream 1110 .
  • the background protocol engine 1102 renders the contents of the at least one packet to a buffer.
  • the buffer may comprise an off-screen buffer.
  • the background protocol engine 1102 generates at least one state-snapshot 1104 as it renders the contents of the at least one packet.
  • the background protocol engine 1102 makes the state-snapshot 1104 available to the foreground protocol engine 1106 .
  • the state-snapshot 1104 enables regeneration of display data because it stores a state of a protocol engine rendering the protocol data stream 1110 at a point in time when a recorder 206 copied at least one packet from the protocol data stream 208 into the recording of the protocol data stream 1110 .
  • the state-snapshot 1104 comprises a data structure describing a state of a screen at a point in time.
  • the state-snapshot 1104 represents all the variables, images and data components that make up the state of a protocol engine at a reference point in the protocol data stream 1110 .
  • the foreground protocol engine 1106 also receives the recording of the protocol data stream 1110 and renders the contents of the at least one packet in the protocol data stream 1110 by recreating the state of the protocol engine which originally rendered the protocol data stream 1110 . In one embodiment, the foreground protocol engine 1106 uses the contents of the state-snapshot 1104 to render the contents of the at least one packet.
  • the state-snapshot 1104 comprises a data structure. In other embodiments, the state-snapshot 1104 comprises a database. In one embodiment, the contents of the state-snapshot 1104 include display data regarding the state of a visible surface. In another embodiment, the contents of the state-snapshot 1104 include display data regarding the state of an off-screen surface. In yet another embodiment, the contents of the state-snapshot 1104 include display data regarding the state of a drawing object. In some embodiments, the contents of the state-snapshot 1104 include display data regarding the state of a color palette. In other embodiments, the contents of the state-snapshot 1104 include display data regarding the state of a cached object. In still other embodiments, the contents of the state-snapshot 1104 include display data regarding the state of a buffer.
  • the foreground protocol engine 1106 receives the recording of the protocol data stream 1110 and uses the state-snapshot 1104 to identify a packet containing the representation of the requested digital data and to render the packet. In some embodiments, the foreground protocol engine 1106 generates a real-time perceptible representation of the recording of the protocol data stream 1110 for presentation to a viewer using the display 1108 . In some embodiments, the foreground protocol engine 1106 generates the real-time perceptible representation by rendering the contents of at least one packet in the protocol data stream 1110 .
  • the perceptible representation may include, without limitation, separately or together, audio, visual, tactile, or olfactory presentations.
  • the foreground protocol engine 1106 renders the contents of at least one packet in the protocol data stream 1110 .
  • the foreground protocol engine 1106 initiates rendering the contents of at least one packet in the protocol data stream 1110 simultaneous to the rendering by the background protocol engine 1102 .
  • the background protocol engine 1102 renders only to a buffer and completes the rendering and the generation of the at least one state-snapshot 1104 prior to the completion of the real-time perceptible rendering initiated by the foreground protocol engine 1106 , which, in one embodiment, renders to both a buffer and in a perceptible manner.
  • the background protocol engine 1102 renders the protocol data stream 1110 at a maximum possible speed regardless of any timestamps associated with the recording which would otherwise specify a time for rendering. Therefore, at least one state-snapshot 1104 is available to the foreground protocol engine 1106 during its generation of a real-time perceptible representation of the recording of the protocol data stream 1110 .
  • the foreground protocol engine 1106 renders the contents of the plurality of packets within the recording of the protocol data stream 1110 in a sequential manner.
  • the display data rendered and presented to the user presents the display in the order in which it occurred at the time the protocol data stream was recorded.
  • the recording of the protocol data stream 1110 may include information, such as time stamps, for use by the foreground protocol engine 1106 in rendering the display data sequentially.
  • the foreground protocol engine 1106 renders the display data in real-time.
  • the foreground protocol engine 1106 When the foreground protocol engine 1106 receives a request to regenerate a particular display data represented by a particular packet in the recording of the protocol data stream 1110 , the foreground protocol engine 1106 renders the requested display data using the contents of the identified state-snapshot 1104 .
  • the background protocol engine 1102 and the foreground protocol engine 1106 reside on the same device. In other embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on separate devices.
  • a flow diagram depicts one embodiment of the steps taken in a method for real-time seeking during playback of stateful remote presentation protocols.
  • a request for rendering of data display represented by the contents of a packet in a recording of a protocol data stream (step 902 ).
  • the contents of the appropriate packet are rendered by first identifying a state-snapshot having an associated timestamp not later than a timestamp associated with the requested packet (step 904 ) and rendering the requested contents responsive to the identified state-snapshot (step 906 ).
  • the foreground protocol engine 1106 receives a request to render the contents of a packet in a recording of a protocol data stream 1110 .
  • the protocol data stream 1110 comprises a plurality of packets whose contents represent display data.
  • the request results when the foreground protocol engine 1106 regenerates display data by rendering the contents of a packet in a recording of a protocol data stream 1110 to a viewer using the display 1108 and the viewer wishes to seek for a particular display data.
  • the foreground protocol engine 1106 identifies a state-snapshot 1104 having an associated timestamp not later than a time stamp associated with the requested packet.
  • the foreground protocol engine 1106 displays the display data represented by the contents of the requested packet responsive to the identified state-snapshot 1104 .
  • the identified state-snapshot 1104 indicates the exact packet from the protocol data stream 1110 whose contents the foreground protocol engine 1106 may render to provide the user with the requested display data.
  • the identified state-snapshot 1104 comprises a state of a protocol engine rendering the protocol data stream at a point in time when a recorder copied a packet from the protocol data stream 1110 but the display data represented by the contents of the copied packet precede the display data requested by the viewer.
  • the foreground protocol engine 1106 renders the contents of the intermediate packet or packets only to an off-screen buffer. The foreground protocol engine 1106 then renders the packet whose contents represent the display data both to an off-screen buffer and to the user in a perceptible manner.
  • the foreground protocol engine 1106 presents the display data represented by the contents of the intermediate packets in a perceptible manner prior to the display data represented by the contents of the requested packet.
  • a flow diagram depicts one embodiment of the steps taken to generate state-snapshots enabling real-time seeking during playback of remote presentation protocols.
  • the background protocol engine 1102 receives a recording of a protocol data stream 1110 and while regenerating display data represented by the contents of the plurality of packets within the protocol data stream 1110 , generates at least one state-snapshot.
  • the background protocol engine 1102 receives a recording of a protocol data stream 1110 comprising a plurality of packets (step 1002 ).
  • the background protocol engine 1102 generates a representation of the recording of the protocol data stream.
  • the background protocol engine 1102 generates the representation by rendering the contents of the plurality of packets to a buffer.
  • the buffer is an off-screen buffer.
  • the foreground protocol engine 1106 also receives the recording of the protocol data stream 1110 .
  • the foreground protocol engine 1106 generates a human-perceptible representation of the recording of the protocol data stream, although, as discussed above, the foreground protocol engine 1106 renders both to an off-screen buffer and in a perceptible manner (step 1004 ).
  • the foreground protocol engine 1106 generates a human-perceptible representation of the recording of the protocol data stream 1110 by rendering the contents of the plurality of packets substantially simultaneously with the background protocol engine 1102 generating at least one state-snapshot during its reading of the recording of the protocol data stream.
  • the background protocol engine 1102 After the reading of the at least one packet in the recording of the protocol data stream 1110 , the background protocol engine 1102 generates at least one state-snapshot (step 1006 ). In one embodiment, the background protocol engine 1102 generates at least one state-snapshot during a sequential reading of the recording of the protocol data stream 1110 . In another embodiment, the background protocol engine 1102 reads the at least one packet in the recording of the protocol data stream 1110 substantially simultaneously with a rendering of the contents of the packet to a buffer. In one embodiment, the background protocol engine 1102 then stores the generated state-snapshot 1104 (step 1008 ).
  • the state-snapshots may act as markers throughout the recording of the protocol data stream 1110 , assisting in the location of a particular point in time in the protocol data stream 1110 and of the packets that come before or after the state-snapshot 1104 .
  • a flow diagram depicts one embodiment of steps taken for adaptive generation of state-snapshots.
  • the background protocol engine 1102 monitors an activity of a viewer and generates one or more state snapshots 1104 responsive to the level of activity of a viewer.
  • a background protocol engine 1102 monitors an activity of the user (step 1204 ).
  • the foreground protocol engine 1106 generates the representation of the recording of the protocol data stream 1110 and presents it to the user with the display 1108 .
  • the background protocol engine 1102 generates the representation.
  • a third device generates the representation.
  • the background protocol engine 1102 monitors an activity of the user during the presentation (step 1204 ). By monitoring the activity of the user, the background protocol engine 1102 develops an activity profile responsive to the monitoring of the activity (step 1206 ). The background protocol engine generates at least one state-snapshot 1104 responsive to the developed activity profile (step 1208 ).
  • the background protocol engine 1102 identifies a level of activity of the user. In some embodiments, the background protocol engine 1102 identifies a period of inactivity. In other embodiments, the background protocol engine 1102 identifies an area of interest to the user in the display data. The activity profile reflects these identifications.
  • the background protocol engine 1102 generates at least one state-snapshot responsive to the activity profile. In some embodiments, the background protocol engine 1102 determines to extend an interval between one or more state-snapshots. In other embodiments, the background protocol engine 1102 determines to reduce an interval between one or more state-snapshots. In still other embodiments, the background protocol engine 1102 determines to remove the at least one state-snapshot, responsive to the activity profile. In still other embodiments, the background protocol engine 1102 determines to add at least one state-snapshot, responsive to the activity profile.
  • the background protocol engine 1102 identifies a predicted statistical distribution of seek probabilities.
  • FIG. 13 is a diagram depicting three types of seek probability distributions of one embodiment.
  • the background protocol engine 1102 collects and stores data about the seek requests made by a user.
  • the data includes how regularly the user makes a seek request.
  • the data includes the range, of each seek request—the distance between the requested display data and the current display data presented to the user by rendering the contents of a packet in the recording of the protocol data stream 1110 .
  • the range may be described in units of time or relative to the length of the entire recording of the protocol data stream 1110 .
  • the timestamp at which the seek request was made is recorded.
  • FIG. 14 is a diagram depicting one embodiment of generating state-snapshots responsive to a determined seek probability distribution.
  • the background protocol engine 1102 uses the collected seek request data to generate a seek probability distribution graph centered on the currently presented display data.
  • the background protocol engine 1102 assigns each position in the stream a value indicating the estimated probability the user will request to seek to the display data associated with that position. With this data, the background protocol engine 1102 determines where to place generated state-snapshots 1104 and generates the at least one state-snapshot 1104 responsive to the statistical distribution of seek probabilities.
  • FIG. 15 depicts one embodiment of a usage pattern of the user.
  • the background protocol engine 1102 develops an activity profile for a user based upon a usage pattern of the user.
  • the usage pattern reflects identified seek probabilities. Areas of higher seek probability will be provided with a higher state-snapshot density and areas of lower seek probability will be provided with a lower state-snapshot density. In some embodiments, the distance between any pair of state-snapshot is inversely proportional to the average seek probability between them.
  • the background protocol engine 1102 expects the user to seek to higher probability areas, therefore the majority of seeks will be fast as the spacing between generated state-snapshots 1104 is relatively short.
  • the background protocol engine 1102 will impose an upper bound on the spacing of generated state-snapshots 1104 even when the seek probability is very low. Likewise, in another embodiment a lower bound prevents placing state-snapshots too close together in very high probability areas. In some embodiments, the amount of rendering between adjacent state-snapshots is considered when determining state-snapshot placement, to minimize latency.
  • the background protocol engine 1102 applies a default state-snapshot generation pattern. This pattern assumes most seeking will occur close to the current frame in either direction, but long range seek performance must only be at best satisfactory. The typical user will demand high performance when jogging back-and-forth around the current frame as many small seek steps can be achieved with jog wheel input device. Seeking long range is less common and noticeable delays may be an acceptable trade-off.
  • the background protocol engine 1102 adjusts the state-snapshot generation pattern during live playback without the user's knowledge.
  • the background protocol engine 1102 moves state-snapshot positions to adjust for the new usage pattern. For example, if a user that normally seeks in small steps with the mouse wheel begins seeking longer range, the background protocol engine 1102 reduces the number of state-snapshots around the current frame to free resources for adding state-snapshots within the areas at longer range.
  • FIG. 16 summarizes one embodiment of the method 1600 discussed above used in a system for adaptive generation of state-snapshots, including a background protocol engine 1602 , a foreground protocol engine 1608 , a protocol data stream 1612 , an activity profile 1604 , and a state-snapshot 1606 .
  • the foreground protocol engine 1608 presents a representation of a recording of a protocol data stream to a viewer, in some embodiments by a display 1610 .
  • the background protocol engine 1602 monitors an activity of the viewer during the presentation, develops an activity profile 1604 responsive to the monitoring and generates and maintains a state-snapshot 1606 responsive to the activity profile.
  • a protocol engine executing on a first device, receives a recorded session (step 1802 ).
  • the recorded stream comprises a plurality of packets representing display data generated by an application program executed on a second device.
  • the protocol engine determines for a packet in the recorded stream, to render the contents of the packet in a human-perceptible manner (step 1804 ).
  • the protocol engine stores the determination in a playback data structure (step 1806 ).
  • the protocol engine comprises a protocol engine 502 , as described in FIG. 5 above.
  • the protocol engine comprises a background protocol engine 1102 , as described in FIG. 11 .
  • the protocol engine comprises a foreground protocol engine 1106 , as described in FIG. 11 .
  • the protocol engine may cease performing a functionality of a background protocol engine 1102 and begin performing a functionality of a foreground protocol engine 1106 .
  • the protocol engine may cease performing a functionality of a foreground protocol engine 1106 and begin performing a functionality of a background protocol engine 1102 .
  • the protocol engine comprises both a protocol engine 1102 and a foreground protocol engine 1006 .
  • the background protocol engine 1102 and the foreground protocol engine 1106 reside on the same device. In other embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on separate devices.
  • the protocol engine determines for a packet in the recorded stream to display the packet in a human-perceptible manner (step 1804 ).
  • the display includes, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these.
  • the protocol engine determines to display a packet responsive to the contents of the packet.
  • the protocol engine makes the determination responsive to an indication of an application program having input focus.
  • the protocol engine makes the determination responsive to an evaluation of a type of user input stored in the packet.
  • the protocol engine makes the determination responsive to an evaluation of a type of graphics update stored by the packet.
  • the protocol engine makes the determination responsive to an evaluation of a type of interaction sequence stored by the packet.
  • the protocol engine stores the determination in a playback data structure ( 1806 ).
  • a playback data structure describes how to regenerate the display data contained within the recorded stream.
  • the instructions stored within the playback data structure control the process of rendering display data.
  • the playback data structure comprises a time for rendering the contents of a packet in the recorded stream. In this embodiment, the time contained in the playback data structure is used for rendering the contents of the packet and not a time of rendering associated with the packet in the recording, if any.
  • the playback data structure accepts user input in changing the time of rendering.
  • the playback data structure comprises metadata that describes how to perform one or more playbacks of a recorded session.
  • the playback data structure consists of a record for each packet in the recorded stream, indicating at what relative point in time the contents of that packet should be rendered during playback.
  • the metadata also contains the offset within the file of the start of the packet.
  • a block diagram depicts one embodiment of a system for rendering a recorded session 1700 , including a first device 1702 , a background protocol engine 1704 , a playback data structure 1706 , a foreground protocol engine 1708 , a display 1710 , a second device 1712 , and a recorded stream 1714 .
  • the background protocol engine 1704 executes on a first device 1702 and generates a playback data structure 1706 in response to receiving a recorded stream 1714 , said recorded stream 1714 representing display data generated by an application program executed on a second device 1712 or on a third device.
  • the foreground protocol engine 1708 receives the recorded stream 1714 and renders the recorded stream 1714 responsive to the playback data structure 1706 generated by the background protocol engine 1704 .
  • the background protocol engine 1704 and the foreground protocol engine 1708 each receive the recorded stream 1714 .
  • the background protocol engine 1704 generates the playback data structure substantially simultaneously with the foreground protocol engine 1708 rendering the recorded stream.
  • the foreground protocol engine 1708 resides on the first device 1702 . In another embodiment, shown in shadow in FIG. 17 , the foreground protocol engine 1708 resides neither on the first device 1702 nor on the second device 1712 . In still another embodiment, the foreground protocol engine 1708 resides on a third device. In some embodiments, the foreground protocol engine 1708 comprises a background protocol engine 1704 . In some of these embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on the same device. In others of these embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on separate devices.
  • the background protocol engine stores in the playback data structure at least one instruction for rendering at least one packet in the recorded stream.
  • the background protocol engine stores metadata in the playback data structure.
  • the background protocol engine stores in the playback data structure a record indicating a time to render at least one packet in the recorded session.
  • the foreground protocol engine 1708 renders at least one packet in the recorded session responsive to the playback data structure. In one embodiment, the foreground protocol engine renders at least one packet in the recorded session in a human-perceptible manner and to a buffer. In another embodiment, the foreground protocol engine renders at least one packet in the recorded session to a buffer.
  • a background protocol engine receives a recorded stream comprising a plurality of packets representing display data generated by an application program executing on a second device (step 1902 ).
  • the background protocol engine determines for at least one packet in the recorded stream, to render the packet in a human-perceptible manner (step 1904 ).
  • the background protocol engine stores the determination in a playback data structure (step 1906 ).
  • a foreground protocol engine retrieves at least one packet from the recorded stream (step 1908 ), access the playback data structure (step 1910 ), and renders the at least one packet responsive to the playback data structure (step 1912 ).
  • the protocol engine determines for a packet in the recorded stream to display the packet in a human-perceptible manner (step 1904 ).
  • the display includes, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these.
  • the protocol engine determines to display a packet based responsive to the contents of the packet.
  • the protocol engine makes the determination responsive to an indication of an application program having input focus.
  • the protocol engine makes the determination responsive to an evaluation of a type of user input stored in the packet.
  • the protocol engine makes the determination responsive to an evaluation of a type of graphics update stored by the packet.
  • the protocol engine makes the determination responsive to an evaluation of a type of interaction sequence stored by the packet.
  • the protocol engine stores the determination in a playback data structure ( 1906 ).
  • the foreground protocol engine receives the recorded session. In other embodiments, the foreground protocol engine retrieves the recorded session. In some of these embodiments, the foreground protocol engine retrieves the recorded session from a storage element.
  • the foreground protocol engine retrieves at least one packet from the recorded stream (step 1908 ). In this embodiment, the foreground protocol engine then accesses the playback data structure (step 1910 ) and renders the contents of the packet responsive to the playback data structure (step 1912 ). In some embodiments, the playback data structure contains an instruction to render the contents of the packet in a perceptible manner. In one of these embodiments, the foreground protocol engine renders the contents of the packet on-screen. In some embodiments, the foreground protocol engine always renders the contents of the at least one packet to a buffer. In many embodiments, when the foreground protocol engine renders the contents of a packet to a buffer, it is an off-screen buffer. In one of these embodiments, the foreground protocol engine renders the contents of the packet to an off-screen buffer and also renders the contents of the packet on-screen, as directed by the playback data structure.
  • the playback data structure comprises an instruction not to render the contents of the packet in a perceptible manner.
  • the foreground protocol upon accessing the playback data structure, does not render the contents of the packet in a perceptible manner but does render the contents of the packet to a buffer.
  • the foreground protocol engine renders the contents of a packet only to an off-screen buffer
  • the foreground protocol engine perceptibly regenerates display data differing from the recorded stream. This results, in one embodiment, in a presentation of display data shorter than the original recorded stream.
  • the rendered contents of the packets provide a streamlined regeneration of the original display data.
  • the rendered contents of the packets provide a customized version of the display data.
  • the determination to render the contents of the packet in a perceptible manner is responsive to a policy or user request.
  • FIG. 21 one embodiment is depicted of rendering a recorded session with perceptible intervals of time containing no activity eliminated.
  • black blocks represents a packet or packets containing user input and dotted blocks represents a packet or packets containing graphics commands.
  • the time intervals represented by white blocks in both the “User input” and “Graphics” rows have no packets and hence no activity at all.
  • One embodiment of a method to eliminate perceptible intervals of time with no activity is as follows.
  • a first packet in a recorded session is identified.
  • the recorded session comprises a plurality of packets representing display data.
  • the nearest previous packet to the first packet in the recorded session is identified as a second packet.
  • a first time interval is determined, the time interval occurring between said first packet and said second packet.
  • a determination is made that the first time interval exceeds a threshold.
  • the contents of the packets in the recorded session are rendered with a second time interval between said first packet and said second packet shorter than the first time interval.
  • a protocol engine makes the determinations.
  • the protocol engine stores the determinations in a playback data structure.
  • the same protocol engine renders the recorded session responsive to the playback data structure.
  • the protocol engine making the determinations comprises a background protocol engine and the protocol engine rendering the recorded session comprises a foreground protocol engine.
  • the protocol engine categorizes the time interval as a perceptible time interval.
  • a time interval is perceptible if a user of the regenerated recorded session can perceive that a period of time lacking activity has elapsed.
  • a policy determines the threshold.
  • the protocol engine is hard coded with a predefined threshold.
  • the protocol engine stores an instruction in the playback data structure to render a shorter time interval between the first and second packets instead of the original time interval.
  • the protocol engine determining that the time interval exceeds the threshold also renders the contents of the recorded session. In this embodiment, the protocol engine does not store the instruction to render the shorter time interval in the playback data structure. For a time interval not categorized as perceptible, no shortened time interval is needed and the original time interval is rendered between the first and second packets.
  • a flow diagram depicts one embodiment of the steps taken to generate playback instructions for rendering a recorded session.
  • a type of input stored by a packet in a recorded session is identified (step 2002 ) and the packet is marked responsive to the type of input (step 2004 ).
  • a destination for rendering the contents of the packet, responsive to the marking is stored in a playback data structure.
  • the type of input stored by a packet determines whether or not the packet will be rendered. In one embodiment, the packet contains no content. In some embodiments, at least one packet contains no content. In these embodiments, an interval of time comprised of at least one packet containing no content is identified. In some of these embodiments, the interval of time will not be rendered.
  • the type of input refers to input from certain types of input devices, including, without limitation, a keyboard, a mouse, a microphone, or a camera.
  • the step of identifying the type of input further comprises identifying the type of input as input from an input device.
  • the step of identifying the type of input further comprises identifying the type of input as keyboard input.
  • the type of input is not related to the input device. In one of these embodiments, the type of input is identified as a command.
  • the packet containing the input is marked responsive to the type of input it contains (step 2004 ).
  • the packet is marked responsive to a policy.
  • a policy determines the types of input which result in a packet being marked. In another embodiment, no marking is required.
  • a destination for rendering the packet is stored in a playback data structure responsive to the marking (step 2006 ).
  • the destination comprises a buffer.
  • an instruction is stored in the playback data structure, directing rendering of the packet to the buffer.
  • the buffer is an off-screen buffer and when the contents of the packet are rendered to the buffer they are not perceptible to a user of the rendering.
  • an instruction is stored in the playback data structure, directing rendering of the marked packet both in a perceptible manner and to a buffer.
  • the method eliminates perceptible intervals of time containing no meaningful activity.
  • a policy identifies a particular type of input as meaningful or as insignificant.
  • the policy may be hard coded into a protocol engine, in some embodiments. In other embodiments, an administrator configures the policy.
  • a protocol engine identifies a packet as insignificant if the packet contains no content.
  • the packet represents an interval of time in which the no user activity occurred to be recorded into the recorded stream 1714 .
  • the protocol engine stores in a playback data structure a destination for rendering each of the plurality of packets in the recorded stream in such a way that any insignificant packet does not render in a perceptible manner.
  • FIG. 22 depicts one embodiment of a regenerated recorded stream whose contents are rendered responsive to a playback data structure. Rendering responsive to the playback data structure, in this embodiment, allows elimination of intervals of time containing no meaningful activity (depicted by the white and striped blocks in FIG. 22 ), which includes intervals of time containing no activity at all. This rendering provides a more meaningful regeneration of the recorded session to a user, where a policy determines when content represents meaningful activity.
  • the content representing meaningful activity comprises types of user input.
  • the protocol engine identifies an input type responsive to previously defined input types comprising provably insignificant time.
  • insignificant time includes an interval of time in which no packet contains any content.
  • a policy defines the input types, which constitute insignificant time.
  • a definition of an input type comprising provably insignificant time is hard coded into the protocol engine.
  • the contents of a packet represent user activity but a policy identified the activity as insignificant activity.
  • the policy defines an insignificant activity as activity deemed to be of no interest to a user of the regenerated recorded session.
  • meaningful packets contain contents of interest to a user of the regenerated recorded session, as determined by the policy.
  • an insignificant packet has no content representing input meaningfully interacting with an application.
  • the device transmitting application data in the protocol data stream from which the recorded stream was created transmitted no meaningful screen updates.
  • the protocol engine determines for at least one packet in the recorded session whether the contents of the packet include types of input such as, without limitation, keyboard input, mouse input, or command messages. If the packet does contain a type of input such as keyboard input, the protocol engine marks the packet as a meaningful packet. If the packet does not contain that type of input, the protocol engine marks the packet as insignificant. In one embodiment, the packet is insignificant only if all of its contents are insignificant. In another embodiment, a packet contains more than one type of input each of which may be marked as meaningful or insignificant.
  • the protocol engine when the protocol engine marks a packet as insignificant, the protocol engine determines that the contents of the packet should not render in a perceptible manner. In some embodiments, the protocol engine determines instead that the contents of the packet should render to a buffer. In one of these embodiments, the buffer is an off-screen buffer. If the packet is marked as a meaningful packet, the protocol engine determines, in one embodiment, that the contents of the packet should render in a perceptible manner. In some embodiments, a perceptible manner comprises rendering on-screen. In one embodiment, the protocol engine determines that the packet should render both in a perceptible manner and to a buffer. In this embodiment, the contents of the packet render both to an on-screen display and to an off-screen buffer. The protocol engine stores the determination in the playback data structure.
  • certain packets in the recording stream have content representing meaningful user activity, in this embodiment a mouse input indicating an active mouse button state represented by the black blocks in FIG. 22 .
  • Other packets in the recording stream have content representing mouse input indicating an inactive mouse button state, represented by the striped blocks in FIG. 22 .
  • the protocol engine identifies at least one packet containing only insignificant activity, such as a mouse input indicating an inactive mouse button state, and stores in a playback data structure a determination that the contents of the packet should not render in a perceptible manner. By making this determination, a protocol engine rendering the contents of the recorded stream responsive to the playback data structure regenerates only the display data relevant to the user of the regenerated recorded session, where a policy defines relevance or where the protocol engine comprises a definition of relevant content.
  • a flow diagram depicts one embodiment of the steps taken to eliminate periods with no meaningful activity in rendering a recorded session.
  • a first time interval is determined, the time interval occurring between a marked packet and a nearest previous marked packet in a recorded session (step 2302 ).
  • the recorded session comprises a plurality of packets representing display data.
  • a determination is made that the first time interval exceeds a threshold (step 2304 ).
  • the contents of the packets in the recorded session are rendered with a second time interval between the marked packet and the nearest previous marked packet shorter than the first time interval (step 2306 ).
  • a protocol engine makes the determinations.
  • the protocol engine stores the determinations in a playback data structure.
  • the same protocol engine renders the recorded session responsive to the playback data structure.
  • the protocol engine making the determinations comprises a background protocol engine and the protocol engine rendering the recorded session comprises a foreground protocol engine.
  • the protocol engine makes the determination of the first time interval (step 2302 ) and whether or not the first time interval exceeds a threshold (step 2304 ) after a packet has been marked as a meaningful packet responsive to the type of input contained in the packet.
  • the type of output contained in the packet impacts the determination to mark the packet.
  • the protocol engine determines the time interval between the packet marked as meaningful and the nearest previous meaningful packet, or the start of the recording if there are no previous meaningful packets.
  • the protocol engine renders the contents of the recorded session with a second time interval between the marked packet and a previous packet said second time interval comprising a shorter time interval than the first time interval.
  • the protocol engine renders the contents of the recorded session with a second time interval between the marked packet and a packet following the marked packet, said second time interval comprising a shorter time interval than the first time interval.
  • the protocol engine categorizes the time interval as a perceptible time interval.
  • a time interval is perceptible if a user of the regenerated recorded session can perceive that a period of time lacking activity has elapsed.
  • a policy determines the threshold.
  • the protocol engine is hard coded with a predefined threshold.
  • the protocol engine stores an instruction in the playback data structure to render a shorter time interval between the two meaningful packets instead of the original time interval.
  • the protocol engine determining that the time interval exceeds the threshold also renders the contents of the recorded session. In this embodiment, the protocol engine does not store the instruction to render the shorter time interval in the playback data structure. For a time interval not categorized as perceptible, no shortened time interval is needed and the original time interval is rendered between the two meaningful packets.
  • contents of a packet in the recorded stream represent graphics updates affecting a screen region.
  • the graphics updates include, without limitation, flashing system tray icons, title bars or task bar entries, blinking text in web pages or applications, clock displays, system animations, application animations, and stock tickers and other periodically updated information displays.
  • graphics updates such as these are determined to be insignificant to a user of a regeneration of the recorded stream.
  • a protocol engine comprises this determination.
  • a policy defines at least one graphics update as insignificant.
  • an administrator generates the policy.
  • a user of the regeneration of the recorded stream generates the policy.
  • a flow diagram depicts one embodiment of the steps taken to eliminate a graphics update in rendering a recorded session.
  • a graphics update is identified (step 2402 ) and the screen region affected by the graphics update is determined (step 2404 ).
  • An indication of the location and state of the affected screen region is stored (step 2406 ) and a second graphics update affecting the state of the screen region is identified (step 2408 ).
  • a destination for rendering and a time interval for rendering are indicated, responsive to whether the second graphics update varies the region affected by the first graphics update (step 2410 and step 2412 ).
  • a protocol engine performs the steps depicted by FIG. 24 .
  • the protocol engine identifies a packet in a recorded session, said recorded session representing display data generated by an application program and said packet containing a first graphics update.
  • the protocol engine determines a screen region affected by the first graphics update.
  • the graphics update affects a screen region by changing the data displayed on that portion of the screen.
  • the protocol engine stores an indication of the state of the screen region after the first graphics update and the location of the screen region.
  • the protocol engine stores a copy of the updated screen region.
  • the protocol engine stores a hash of the updated screen region.
  • the protocol engine identifies a second graphics update affecting the screen region within a time interval.
  • a policy determines the length of the time interval.
  • the policy determines a time interval approximating the upper limit of human scale cyclic periods used by applications and operating systems.
  • the display when a region of the screen goes through a cyclic display, at a period designed to be viewed by the user (for example, a significant fraction of a second up to several seconds), the display comprises a human scale cyclic period.
  • the protocol engine comprises a definition of the length of the time interval.
  • the protocol engine determines whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update. If the screen region does not vary after the second graphics update, the second graphics update need not render in the regenerated recorded session.
  • a screen graphics update in this embodiment need not render since the protocol engine determined that the graphics update is performing a cycle of drawing commands at human-scale speeds, making the update observable to a user of the regenerated recorded session, but the graphics update carries insignificant information for the user.
  • the graphics update affects the screen region by drawing, without limitation, a caret flashing, a flashing taskbar icon, a network activity indicator, or scrolling text.
  • a policy determines that affecting a screen region with that type of graphics update does not constitute a meaningful activity and should not render in the regeneration of the recorded session for a user.
  • the protocol engine comprises this determination.
  • an indication of a destination for rendering the second packet containing the second graphic update affecting the screen region is stored in a playback data structure, responsive to whether the screen region varies after the second graphics update.
  • an indication of a time interval to render associated with the second packet containing the second graphic update affecting the screen region is stored in a playback data structure, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
  • FIG. 25 depicts one embodiment of rendering the regenerated recorded session responsive to indications stored in a playback data structure, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
  • the screen region affected by the first graphics update does not vary after the second graphics update.
  • an indication is stored in a playback data structure not to render the second graphics update in a perceptible manner.
  • not perceptibly rendering the second graphics update comprises rendering the second graphics update off-screen and not on-screen.
  • not perceptibly rendering the second graphics update comprises rendering the second graphics update to an off-screen buffer.
  • not perceptibly rendering the second graphics update comprises not rendering the second graphics update.
  • a determination not to render the second graphics update perceptibly comprises rendering a perceptible indication that the graphics update is not rendered.
  • a user of the regenerated recorded session may request that the second graphics update render perceptibly.
  • FIG. 25 depicts an embodiment in which a cyclic update is detected by determining that the state of the screen region after the second graphics update does not vary from the state of the screen region after the first graphics update and determining not to render the second graphics update responsive to the detection of the cyclic update.
  • a determination is made to render the contents of the packet in a perceptible manner and to a buffer.
  • the contents of a plurality of packets represent a graphics update.
  • a determination to render a graphics update in a perceptible manner is made responsive to the effects of more than two graphics updates on a screen region.
  • the determination of a destination for rendering a graphics update is responsive to the graphics update represented by the contents of each packet in the identified plurality of packets.
  • contents of a packet in the recorded stream represent an interaction sequence.
  • the interaction sequence comprises, without limitation, a logon sequence, a logoff sequence, or the entering of credentials.
  • interaction sequences such as these are determined to be insignificant to a user of a regeneration of the recorded stream.
  • a protocol engine comprises this determination.
  • a policy defines at least one interaction sequence as insignificant. In this embodiment, an administrator generates the policy. In another embodiment, a user of the regeneration of the recorded stream generates the policy.
  • a start of an interaction sequence of at least one packet is identified responsive to a policy (step 2602 ).
  • a playback data structure there is an indication that the interaction sequence should render to a buffer (step 2604 ).
  • a termination of the interaction sequence of at least one packet is identified (step 2606 ).
  • a first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified (step 2608 ).
  • a playback data structure contains an indication to render a second time interval shorter than the first time interval (step 2610 ).
  • a protocol engine makes the identifications and indications to eliminate an interaction sequence.
  • An identification of a start of an interaction sequence is made (step 2602 ).
  • the start of the interaction sequence is identified by identifying a visual marker.
  • a visual marker comprises a credentials window, displayed in the same way for all sessions.
  • a visual marker comprises a replacement of a credentials window by a blank screen and then by a desktop background.
  • a visual marker comprises the display of recognizable icons.
  • a start of an interaction sequence is identified by determining a start time of an interaction sequence.
  • a component detects the start time of an event in an interaction sequence.
  • the component detects the start time of a logon sequence.
  • the component detects the start time of a logoff sequence.
  • the identification of the start of the interaction sequence is responsive to identifying a window with an input focus.
  • the interaction sequence is rendered to a buffer. Rendering the interaction sequence to a buffer results in the interaction sequence being imperceptible to a user of the rendering. For embodiments where a policy or user categorized the interaction sequence as insignificant, this rendering results in the elimination of an insignificant interaction sequence.
  • An identification of a termination of an interaction sequence is also made (step 2606 ).
  • the termination of the interaction sequence is identified by identifying a visual marker.
  • a termination of an interaction sequence is identified by determining a termination time of the interaction sequence.
  • a component detects the termination time of an event in an interaction sequence.
  • the component detects the termination time of a logon sequence.
  • the component detects the termination time of a logoff sequence.
  • identifying the termination of the interaction sequence is responsive to identifying a window with an input focus.
  • an interaction sequence comprises use of an application.
  • a policy identifies interaction sequences comprising use of an application that should not render in a perceptible manner.
  • applications include, without limitation, word processing documents.
  • a start of an interaction sequence is identified by identifying an application having input focus.
  • the contents of a packet represent a window having focus
  • a determination is made as to the application responsible for the process that created the window.
  • the contents of the packet representing a window having focus include window notification messages indicating a change in input focus. If the responsible application identifies a start of an interaction sequence which should not render perceptibly, an indication is stored in a playback data structure to render the interaction sequence to a buffer.
  • a termination of an interaction sequence is identified by identifying the acquisition of focus by a window owned by a process not associated with the application of the interaction sequence.
  • a first time interval is associated with the interaction sequence. Perceptibly rendering the time interval associated with the interaction sequence in an embodiment where the interaction sequence itself does not render results in a period of time perceptible to a user of the rendering in which no display data renders and the user waits through the time interval before a rendering of the contents of a packet after the interaction sequence.
  • One embodiment eliminates the time interval associated with the interaction sequence by rendering a shorter time interval in place of the original time interval.
  • a first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified (step 2608 ).
  • a playback data structure contains an indication to render a second time interval shorter than the first time interval (step 2610 ).
  • a protocol engine renders the contents of a packet in a recorded session, providing to a user a regeneration of the recorded session.
  • the protocol engine automatically varies the time intervals between rendering the contents of at least one packet, resulting in context-sensitive time-warped playback.
  • rendering approximates the ability of the user to comprehend the display data presented to the user.
  • the time intervals between rendering contents of packets increase when the protocol engine determines the display data represented by the contents of the packets to have an increased level of complexity or importance, as defined by a policy.
  • the time intervals between rendering contents of packets decrease when the protocol engine determines the display data represented by the contents of the packets to have a decreased level of complexity or importance, as defined by a policy.
  • the protocol engine approximates the ability of the user to comprehend the display data and renders the contents either more slowly to give the user time to comprehend the rendering or renders the contents faster when a user requires less comprehension time.
  • a protocol engine receives a recorded session (step 2702 ), the recorded session comprising a plurality of packets and representing display data, and the protocol engine determining a measure of complexity represented by at least some of the plurality of packets in the recorded session (step 2704 ).
  • the protocol engine identifies an interval of time between the at least some of the plurality of packets in the recorded session (step 2706 ) and modifies the interval of time responsive to the measure of complexity represented by the at least some of the plurality of packets in the recorded session (step 2708 ).
  • the protocol engine stores in a playback data structure the modified interval of time (step 2710 ) and the recorded data stream is rendered responsive to the playback data structure (step 2712 ).
  • the protocol engine determining the measure of complexity, identifying the interval of time, modifying the interval of time and storing the modification is a background protocol engine.
  • the background protocol engine also renders the recorded stream.
  • a foreground protocol engine renders the recorded stream responsive to the playback data structure.
  • the background protocol engine and the foreground protocol engine reside on the same device. In other embodiments, the background protocol engine and the foreground protocol engine reside on separate devices.
  • the protocol engine determines a measure of complexity represented by at least some of a plurality of packets in the recorded session (step 2704 ). In some of these embodiments, the protocol engine determines the measure of complexity by identifying likely sequences of typing in keyboard input. In one embodiment, the protocol engine inspects at least one type of key involved to identify likely sequences of typing in keyboard input. In another embodiment, the protocol engine inspects a sequence of at least one glyph rendered to complete a heuristic approximation of likely sequences of typing in keyboard input.
  • the protocol engine stores classifications of keys determined by characteristics of the key. Key characteristics include, without limitation printable or non-printable characters, white space, navigation keys, or function keys, and include combinations of characteristics.
  • a protocol engine determines that sections of input comprising printable characters and occasional navigation keys constitute normal typing, while sections with mostly non-visible keys do not constitute normal typing.
  • the protocol engine determines a measure of complexity responsive to the amount of white space identified.
  • the protocol engine comprises a definition of word processing indicating that a white space key appears on average approximately every 5-8 characters in typical typing patterns.
  • the protocol engine uses the appearance of non-printable characters to determine the measure of complexity.
  • the protocol engine accesses the keystroke sequences to identify sequences of non-white space printable characters appearing close together in time.
  • the protocol engine comprises the capacity to compare the keystroke sequences to a dictionary to identify valid words and determine a measure of complexity relating to an ability of a user to comprehend valid words versus invalid words.
  • the protocol engine determines that the contents of the packet contain commands to render glyphs. In this embodiment, the protocol engine uses the glyphs to determine whether the display data represents a user activity of typing. In this embodiment, if a glyph rendering rate approximates the keyboard input rate with a small delay, it is likely that keystrokes are directly resulting in glyphs, thus making it quite likely the user is typing. In one embodiment, the protocol engine correlates the keys entered with the glyphs produced. In another embodiment, the protocol engine determines the spatial sequence (left-to-right, right-to-left, etc.) of the rendered glyphs to determine that a user is typing. In one embodiment, the protocol engine makes the determination of the measure of complexity responsive to the result of analyzing the contents of the plurality of packets and identifying patterns and activities represented by the contents.
  • the protocol engine makes the determination of the measure of complexity responsive to an identification of a type of mouse input. In one embodiment, the protocol engine determines that a mouse input representing a click of the mouse causes actions that may need a slower rendering rate to comprehend, especially if the clicks follow a sequence of typing. In another embodiment, the protocol engine determines that mouse input that does not represent a clicking of a mouse does not affect the ability of a user to comprehend display data, and thus does not affect the measure of complexity.
  • the protocol engine makes the determination of the measure of complexity responsive to identifying a heuristic approximation of complexity of a graphics update.
  • the protocol engine identifies a heuristic approximation of complexity of a graphics update based upon, without limitation, the size of region(s) being updated, the size of the area of the region changed by the graphics commands, a historical frequency of updates to individual regions, cyclic graphics commands, number of graphics commands, frequency of graphics commands, time interval between adjacent packets whose contents contain graphics command, or the type of graphics update.
  • the protocol engine determines a low measure of complexity for the graphics update.
  • the protocol engine determines a high measure of complexity represented by the packets containing the graphics updates.
  • the protocol engine identifies an interval of time between the at least some of the plurality of packets in the recorded session (step 2706 ). In this embodiment, the protocol engine modifies the interval of time responsive to the determined measure of complexity (step 2708 ). In an embodiment where at least some of the plurality of packets in the recorded session have content representing display data associated with a high measure of complexity, the protocol engine increases the interval of time between the packets to allow the user of the rendering increased time to comprehend the rendered display data. In another embodiment where at least some of the plurality of packets in the recorded session have content representing display data associated with a low measure of complexity, the protocol engine decreases the interval of time between the packets to reflect decreased amount of time the user requires to comprehend the rendered display data.
  • a user requires a different amount of time between the rendered contents of packets than the amount rendered by the protocol engine.
  • the user modifies the interval of time to reflect the amount of time the user requires to comprehend the rendered display data.
  • the protocol engine also identifies a time interval between the at least some of the plurality of packets and other packets in the plurality of packets, modifying the interval of time identified between those sets of packets.
  • the protocol engine identifies a first marker associated with a packet in the recorded session.
  • the packet comprises the marker.
  • the recorded session comprises the marker.
  • a user of the rendering of the display data defines the marker.
  • the protocol engine defines the marker.
  • the protocol engine modifies the interval of time responsive to the first marker.
  • the protocol engine increases the interval of time providing the user of the rendering of the display data additional time for comprehending the contents of the packet associated with the first marker.
  • the protocol engine identifies a second marker in a second packet.
  • the protocol engine modifies the interval of time responsive to the distance between the first marker and the second marker.
  • the protocol engine provides increased time for comprehension of display data represented by contents of packets marked and decreased time for comprehension of data represented by contents of unmarked packets.
  • a user defines markers for display data of interest to the user and the protocol engine renders additional time for the display data of interest to the user and decreases time of rendering for display data not of interest to the user, as determined by the markers.
  • the protocol engine identifies a first marker in the at least some of the plurality of packets in the recorded session, said marker indicating an initial packet in the at least some of the plurality of packets in the recorded session.
  • the protocol engine modifies the interval of time responsive to the first marker.
  • the protocol engine identifies a second marker in a second packet in the at least some of the plurality of packets in the recorded session, said second marker indicating a final packet in the at least some of the plurality of packets in the recorded session and modifying the interval of time responsive to the interval of time between the first marker and the second marker.
  • the protocol engine stores the modified interval of time in a playback data structure (step 2710 ) and the recorded stream is rendered responsive to the contents of the playback data structure (step 2712 ). In one embodiment, the protocol engine also renders the recorded stream responsive to the playback data structure instructions regarding modified time intervals. In another embodiment, a separate foreground protocol engine renders the recorded stream.
  • a determination is made that recorded interaction with an application requires increased time for rendering, to provide a user of the rendering increased time for comprehension of the rendered display data.
  • the determination is made that the application requiring increased time comprises a more important application than an application not requiring the increased time.
  • the user makes the determination.
  • a policy makes the determination.
  • the protocol engine comprises a definition of applications that require increased time.
  • a flow diagram depicts one embodiment of the steps taken for automatic time-warped playback responsive to an identified application in rendering a recorded computer session.
  • a recorded session comprising a plurality of packets and representing display data is received (step 2802 ).
  • a first packet having a content representing a window having focus is identified, said window indicating an application (step 2804 ).
  • a time interval is identified between a second packet whose contents render prior to the rendering of the content of the first packet and a third packet whose contents render after the rendering of the content of the first packet (step 2806 ).
  • the identified time interval is modified responsive to the indicated application (step 2808 ).
  • At least one packet in the recorded stream is rendered responsive to the modification (step 2810 ).
  • a protocol engine receives the recorded session (step 2802 ).
  • the protocol engine also identifies a first packet having a content representing a window having focus is identified, said window indicating an application (step 2804 ).
  • the contents of the packet representing a window having focus include window notification messages indicating a change in input focus.
  • a time interval is identified between a second packet whose contents render prior to the rendering of the content of the first packet and a third packet whose contents render after the rendering of the content of the first packet (step 2806 ).
  • the protocol engine identifies a packet whose contents render prior to the rendering of content representing an application window having focus, a packet whose contents represent the application window having focus, and a packet whose contents represent the application window no longer having focus.
  • the protocol engine modifies the time interval preceding the application having focus. In other embodiments, the protocol engine modifies the time interval following the application having focus. In one embodiment, the protocol engine then determines the interval of time in which the application window has focus and modifies that time interval responsive to the type of application. In one embodiment, the protocol engine increases the identified time interval. In this embodiment, the protocol engine provides the user of the rendering an increased amount of time to review the application. In another embodiment, the protocol engine decreases the identified time interval. In this embodiment, the protocol engine provides the user of the rendering a decreased amount of time to review the application, reflecting the decreased amount of interest in the application.
  • the protocol engine renders at least one packet in the recorded stream responsive to the modification. In one embodiment, the protocol engine renders the contents of the at least one packet in the recorded stream to a buffer. In one embodiment, rendering to a buffer does not render the contents of the packet in a perceptible manner. In another embodiment, the protocol engine renders the contents of the at least one packet in the recorded stream to a buffer and in a perceptible manner. In some embodiments, the protocol engine indicates the modified time interval in a playback data structure and a separate protocol engine renders the recorded session responsive to the information stored in the playback data structure.
  • a block diagram depicts one embodiment of a system for automatic time-warped playback in rendering a recorded computer session 2900 , including a protocol engine 2902 , a recorded stream 2910 , a playback data structure 2904 , and a display 2908 .
  • the protocol engine 2902 generates a playback data structure 2904 in response to receiving a recorded stream 2910 , said recorded stream 2910 comprising a plurality of packets, and said protocol engine 2902 rendering at least one packet in the recorded stream responsive to the generated playback data structure 2904 .
  • the protocol engine 2902 comprises a background protocol engine and a foreground protocol engine.
  • the background protocol engine receives the recorded stream 2910 and generates the playback data structure 2904 .
  • the foreground protocol engine receives the recorded stream 2910 and renders at least one packet in the recorded stream responsive to the generated playback data structure 2904 .
  • the background protocol engine and the foreground protocol engine reside on the same device.
  • the background protocol engine resides on a first device and the foreground protocol engine resides on a second device.
  • system comprises a single protocol engine 2902 generating the playback data structure 2904 and rendering at least one packet in the recorded stream responsive to the generated playback data structure 2904 .
  • the protocol engine 2902 stores in the playback data structure at least one instruction for rendering the recorded session.
  • the instruction comprises a modification of an identified time interval for rendering the contents of a packet in the recorded session.
  • the protocol engine stores metadata in the playback data structure.
  • the metadata comprises higher order instructions for rendering the contents of the packet.
  • the protocol engine renders the contents of at least one packet in the recorded session responsive to contents of a playback data structure. In one embodiment, the protocol engine renders the at least one packet in the recorded session in a perceptible manner and to a buffer. In another embodiment, the protocol engine renders the at least one packet in the recorded session to a buffer.
  • the rendered contents of the packets provide a streamlined regeneration of the original display data. In other embodiments, the rendered contents of the packets provide a customized version of the display data. In one embodiment, the determination to render the contents of the packet in a perceptible manner is responsive to a policy or user request. These embodiments provide users with control over the rendering of the recorded session.
  • the system includes a recorder 3010 , a distributor 3020 , and a protocol engine 502 .
  • the recorder 3010 intercepts a presentation layer protocol data stream 208 comprising a plurality of packets, during transmission of the presentation layer protocol data stream 208 from a first device 106 to a second device 102 , the presentation layer protocol data stream 208 representing display data.
  • the distributor 3020 transmits a copy of at least one packet of the presentation layer protocol data stream 208 .
  • the protocol engine 502 uses the information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet.
  • the recorder 3010 continues intercepting the presentation layer protocol data stream and the distributor continues transmitting copies of packets from the presentation layer protocol data stream until the first device completes transmission of the protocol data stream to the second device.
  • the recorder 3010 extracts data from a presentation layer protocol stack and buffers the data temporarily.
  • the third device 222 records data to disk and catalogs the data.
  • the playback device 514 displays session recordings, both complete and incomplete, to a user.
  • the recorder 3010 intercepts a presentation layer protocol data stream 208 comprising a plurality of packets, during transmission of the presentation layer protocol data stream 208 from a first device 106 to a second device 102 , the presentation layer protocol data stream 208 representing display data.
  • the first device 106 is a server 106 , such as an application server.
  • the second device 102 is a client 102 .
  • the first device 106 transmits the presentation layer protocol data stream 208 as described above in connection with FIG. 2 .
  • the presentation layer protocol data stream 208 is a protocol data stream 208 as described above in connection with FIG. 2 .
  • the recorder 3010 is a recorder 206 as described above in connection with FIG. 2 .
  • the presentation layer protocol data stream 208 comprises one or more virtual channels.
  • the recorder 3010 intercepts a virtual channel.
  • the recorder 3010 resides on the first device 106 . In another embodiment, the recorder 3010 resides on the second device 102 . In still another embodiment, the recorder 3010 resides on a third device 222 . In yet another embodiment, the recorder 3010 resides on a proxy server.
  • the recorder 3010 is located on a passthrough server. In another embodiment, the recorder 3010 is located on a network packet sniffer. In still another embodiment, the recorder 3010 is located on a network appliance, application gateway, application acceleration appliance or other appliance. In some embodiments, the recorder 3010 resides on the same device as the distributor 3020 .
  • the recorder intercepted the protocol data stream 208 and created a recorded protocol data stream 210 using copied packets.
  • the recorder comprises a means for copying at least one packet from the presentation layer protocol data stream.
  • the recorder comprises a means for intercepting a virtual channel.
  • the recorder comprises a means for intercepting the presentation layer protocol data stream at substantially the same time as the first device transmits the presentation layer protocol data stream to the second device.
  • the recorder comprises a buffer for storing the at least one packet.
  • the recorder comprises a recording generator for creating a recording of the presentation layer protocol data stream, or of a portion of the presentation layer protocol data stream.
  • the recorder 3010 intercepts a presentation layer protocol data stream 208 and copies packets from the presentation layer protocol data stream 208 during the transmission of additional packets in the presentation layer protocol data stream 208 from the server 106 to the client 102 .
  • the recorder 3010 intercepts the presentation layer protocol data stream 208 at substantially the same time as the server 106 transmits the presentation layer protocol data stream 208 to the server 102 .
  • the recorder 3010 receives an indication of a request for real-time playback of a presentation layer protocol data stream 208 .
  • the recorder 3010 copies a packet from the presentation layer protocol data stream 208 and forwards the packet before completing interception of the presentation layer protocol data stream 208 , responsive to the received indication of the request for real-time playback. In yet another of these embodiments, the recorder 3010 does not delay the transmission of an intercepted packet until the completion of the recording of the presentation layer protocol data stream 208 .
  • the recorder 3010 further comprises a means for storing a copy of at least one packet of the presentation layer protocol data stream 208 in a storage device. In some embodiments, the recorder 3010 transmits copied, intercepted packets to the distributor 3020 while continuing to intercept subsequent packets from the presentation layer protocol data stream 208 .
  • the recorder 3010 determines whether to copy a packet as described above in connection with FIG. 2 . In other embodiments, upon completion of the transmission of the presentation layer protocol data stream 208 from the server 106 to the client 102 , the recorder 3010 generates a recording of the presentation layer protocol data stream 208 as described above in connection with FIG. 2 .
  • the distributor 3020 transmits a copy of at least one packet of the presentation layer protocol data stream 208 .
  • the distributor further comprises a transceiver for retrieving a copy of the at least one packet.
  • the distributor further comprises a transceiver for transmitting a copy of the at least one packet to the protocol engine.
  • FIG. 30B a block diagram depicts one embodiment in which the recorder 3010 stores a plurality of packets 3030 on a storage device 218 .
  • the distributor 3020 retrieves the plurality of packets 3030 from the storage device 218 and forwards the plurality of packets 3030 to a protocol engine 502 on the playback device 514 .
  • a block diagram depicts one embodiment in which the recorder 3010 , in communication with the distributor 3020 , transmits the plurality of packets 3030 to the protocol engine 502 .
  • the recorder 3010 receives an indication from the distributor 3020 of a request for real-time playback of a presentation layer protocol data stream.
  • the recorder 3010 forwards the plurality of packets 3030 directly to the protocol engine 502 , responsive to the received indication of the request for real-time playback.
  • FIG. 30D a block diagram depicts one embodiment in which the recorder 3010 stores a plurality of packets 3030 on a storage device 218 .
  • the recorder 3010 retrieves the plurality of packets 3030 from the storage device 218 and forwards the plurality of packets 3030 to a protocol engine 502 on the playback device 514 .
  • the distributor 3020 resides on the first device 106 . In another embodiment, the distributor 3020 resides on the second device 102 . In still another embodiment, the distributor 3020 resides on a third device 222 . In yet another embodiment, the distributor 3020 resides on a proxy server.
  • the distributor 3020 is part of a remote presentation protocol server engine 204 , as described above in connection with FIG. 2 .
  • the distributor 3020 resides on a recording server, such as a third device 222 .
  • the distributor 3020 is in communication with the recorder 3010 .
  • the distributor 3020 is located on a passthrough server. In another embodiment, the distributor 3020 is located on a network packet sniffer. In still another embodiment, the distributor 3020 is located on a network appliance, application gateway, application acceleration appliance or other appliance. In some embodiments, the distributor 3020 resides on the same device as the recorder 3010 .
  • the system includes a third device 222 .
  • the third device 222 is referred to as a log server.
  • the distributor 3020 resides on the log server.
  • the log server stores pluralities of packets copied from intercepted presentation layer protocol data streams and recordings of presentation layer protocol data streams.
  • the log server provides functionality for coordinating the distribution of pluralities of packets copied from intercepted presentation layer protocol data streams and of recordings of presentation layer protocol data streams from the recorder 3010 to a playback device.
  • the system includes a playback device 514 , which provides the functionality of the playback device 514 described above in connection with FIG. 5 .
  • the playback device 514 and the protocol engine 502 provide the functionality described above in connection with FIG. 5 , and, in addition to regenerating display data from completed recordings of presentation layer protocol data streams, also provide the ability to regenerate display data associated with a plurality of packets and portions of incomplete presentation layer protocol data streams.
  • the distributor 3020 is in communication with the playback device 514 . In one of these embodiments, the distributor 3020 provides a catalog of presentation layer protocol data streams. In another of these embodiments, the distributor 3020 provides an enumeration of presentation layer protocol data streams available for viewing by the playback device 514 . In still another of these embodiments, the distributor 3020 provides searching functionality, allowing the playback device 514 to search for particular presentation layer protocol data streams. In yet another of these embodiments, the distributor 3020 transmits a recorded presentation layer protocol data stream to the playback device 514 .
  • a playback device 514 requests an enumeration of presentation layer protocol data streams available for displaying to a user of the playback device 514 .
  • the playback device 514 transmits the request to a distributor 3020 .
  • the playback device 514 transmits the request to a recording server, such as the third device 222 .
  • the playback device 514 comprises a protocol engine 502 .
  • the distributor 3020 consults a catalog of available presentation layer protocol data streams. In another embodiment, the distributor 3020 generates an enumeration of available presentation layer protocol data streams responsive to the received request. In still another embodiment, the distributor 3020 transmits an enumeration of available presentation layer protocol data streams to the playback device 514 .
  • the enumeration identifies completely recorded presentation layer protocol data streams. In other embodiments, the enumeration identifies presentation layer protocol data streams for which the recorder 3010 has not completed the recording process. For example, the recorder 3010 may not have completed the process of adding packets to the presentation layer protocol data stream at the time that the identification of the presentation layer protocol data stream is provided to the playback device 514 . In one of these embodiments, the recorder 3010 may add additional packets to the plurality of copied packets of the presentation layer protocol data stream after the playback device 514 accesses a packet already copied into the presentation layer protocol data stream. In still other embodiments, upon receiving the enumeration, the playback device 514 requests an enumerated presentation layer protocol data stream that is still in the process of being recorded.
  • the recorder 3010 intercepts a presentation layer protocol data stream comprising a plurality of packets.
  • the distributor 3020 transmits a copy of at least one intercepted packet from the presentation layer protocol data stream to the playback device 514 .
  • a protocol engine 502 on the playback device 514 uses information associated with the at least one copied packet to regenerate the display data represented by the presentation layer protocol data stream.
  • the recorder 3010 intercepts a second packet and the distributor 3020 transmits a copy of the second packet to the playback device 514 .
  • the playback device 514 uses information associated with the second copied packet to regenerate additional display data represented by the protocol data stream.
  • the steps of intercepting packets and transmitting copies of the intercepted packets for display by the playback device 514 continues until the playback device 514 receives all of the packets in the presentation layer protocol data stream.
  • the third device 222 writes many simultaneous presentation layer protocol session recordings to disk simultaneously, updates a catalogue database and serves files out for playback.
  • the recorder 3010 resides on the third device 222 .
  • the third device 222 receives copied packets from presentation layer protocol data streams that the recorder 3010 forwards to the third device 222 .
  • the third device 222 is referred to as a “log server” or a “recording server”.
  • the file format to support simultaneous recording and playback of any particular session file, the file format must support being played without being complete. In some embodiments, an incomplete file, possibly incomplete due to loss of data or because the session is still in progress, is always capable of being played. In one of these embodiments, however, the file does not contain a digital signature. In another of these embodiments, a digital signature is calculated by the third device 222 when the recording is complete. In still another of these embodiments, the file format is modified to support the use of the empty packet described below. In yet another embodiment, no file format modifications occur.
  • the third device 222 provides the ability to locate a file, based on data held in the catalogue database.
  • a database entry for each recording in the catalogue database is updated three times in order: when the file is created, when the session metadata becomes known (such as when the end user has successfully logged on) and when the recording ends.
  • a file is created when a presentation layer protocol data stream starts.
  • a file is created when a privileged third-party, such as an administrator, requests the initiation of a recording.
  • a first file containing a first portion of a recording of a presentation layer protocol data stream exceeds a threshold
  • the first file closes and a second file is created, the second file containing a second portion of the recording of the presentation layer protocol data stream.
  • the first file exceeds a size limit
  • the first file exceeds the threshold.
  • the first file stores a portion of a recording exceeding a limit on a length of time of the recording, the first file exceeds the threshold.
  • the process of closing a first file that stores a first portion of a recording and that exceeds a threshold and creating a second file to store a second portion of the recording is referred to as “rollover.”
  • the underlying session being recorded continues unaffected and no recorded data is lost in the transition of files.
  • a recording ends when a user whose session is being recorded disconnects. In other embodiments, a recording ends during the process of rollover. In still other embodiments, a recording ends when a privileged third-party, such as an administrator, requests the termination of a recording.
  • only database records that have had all three updates may be searched; the file has to be complete to be searched.
  • methods and systems allow searching of records that have less than all updates.
  • only the first two updates are required for a record to be searchable. This means the file is available for search and download early in the session recording when the metadata becomes known.
  • a recording is searchable when a file is created. In others of these embodiments, however, a determination is made that a file is not available before metadata is identified because the information about the recording only has value for a logged-on session.
  • the third device 222 tracks all live session recordings sent to playback devices 514 , and continues to stream data to playback devices 514 as more data becomes available. In another embodiment, the third device 222 provides a tracking functionality that also supports the “poll” message for informing the presentation servers of live players as discussed below.
  • functionality for transmitting a packet in a presentation layer protocol data stream prior to the completion of a process for adding packets to a recording of the presentation layer protocol data stream enables a user of the playback device 514 to view display data represented by the packet during the recording of a presentation layer protocol data stream.
  • this functionality enables a user to watch the display data live, while it is being created and recorded.
  • the delay is imperceptible to the viewer of the regenerated display data.
  • the transmission of intercepted packets prior to the completion of a transmission of the original presentation layer protocol data stream 208 enables a playback device to display the packets as they are generated. In one of these embodiments, this provides a viewer of regenerated intercepted packets with real-time viewing of the presentation layer protocol data stream.
  • a plurality of intercepted packets may be buffered prior to transmission. However, in some of these embodiments, although the plurality of packets is buffered, they are still transmitted to a playback device prior to the complete transmission of a presentation layer protocol data stream, providing the impression of real-time, or near-real-time playback.
  • the protocol engine 502 uses the information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet.
  • the recorder 3010 continues intercepting the presentation layer protocol data stream and the distributor continues transmitting copies of packets from the presentation layer protocol data stream until the first device completes transmission of the protocol data stream to the second device.
  • a recorder intercepts a presentation layer protocol data stream comprising a plurality of packets, during transmission of the presentation layer protocol data stream from a first device to a second device, the presentation layer protocol data stream representing display data (step 3102 ).
  • a distributor transmits a copy of at least one packet of the presentation layer protocol data stream (step 3104 ).
  • a protocol engine uses information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet (step 3106 ).
  • the steps of intercepting the presentation layer protocol data stream and of transmitting a copy of at least one packet of the presentation layer protocol data stream repeat until the first device completes transmission of the protocol data stream to the second device (step 3108 ).
  • a recorder intercepts a presentation layer protocol data stream comprising a plurality of packets, during transmission of the presentation layer protocol data stream from a first device to a second device, the presentation layer protocol data stream representing display data (step 3102 ).
  • the recorder 3010 intercepts the presentation layer protocol data stream at substantially the same time as the first device transmits the presentation layer protocol data stream to the second device.
  • the recorder intercepts a virtual channel.
  • the recorder 3010 determines whether to copy a packet as described above in connection with FIG. 2 . In other embodiments, upon completion of the transmission of the presentation layer protocol data stream 208 from the server 106 to the client 102 , the recorder 3010 generates a recording of the presentation layer protocol data stream 208 as described above in connection with FIG. 2 . In one of these embodiments the recorder 3010 stores a recording of the presentation layer protocol data stream. In still other embodiments, the recorder 3010 associates information with copied packets or embeds information into the copied portions of the presentation layer protocol data stream as described above in connection with FIG. 2 .
  • a recorder 3010 associated with, or residing on, a third device 222 may capture various data transmitted over virtual channels and presentation layer packets (including optimization and acceleration metadata and mouse and keyboard packets) from the presentation layer stack in kernel mode. To reduce the computing and network overhead of sending many small messages to the third device 222 , in some embodiments the recorder 3010 may buffer the data locally for each session. When the recorder 3010 captures sufficient data to form a large enough message, or when a timeout period expired (in the order of minutes), the recorder 3010 may forward the data to a storage component. The approach provides the system with excellent utilization of resources.
  • methods and systems supporting live or time-shifted playback needs to forward data to a playback device 514 immediately. If the data is held back for a length of time exceeding a threshold, the playback experience will suffer, as the stream is not continuous or up-to-date. Data may arrive at the playback device 514 at irregular and infrequent intervals. Some of the data received might be in the order of minutes old.
  • a system removes the buffering functionality for all recording sessions.
  • this approach may decrease performance and scalability and may be considerably more wasteful of resources, such as the utilization of available network bandwidth.
  • buffering functionality is provided for playback of previously recorded sessions and not for sessions that are actually being viewed live.
  • the recorder 3010 receives a notification of this event and switches off the buffering mechanism accordingly.
  • the recording of a subsequent session at the presentation server will be returned to normal buffering mode. This approach means scalability is only affected for the time the player is actually playing a recording. The impact will also only be on the presentation server hosting the session; other servers in the farm are not affected.
  • streaming of live sessions data may be slightly throttled. Instead of sending all received data immediately, the data is buffered, but only for a very short period of time. In one of these embodiments, the time is predetermined. In another of these embodiments, the buffering time period is less than one second. In still another of these embodiments, 500 milliseconds is selected, resulting in only transmission of only two network messages per second.
  • methods and systems described herein address a problem created by the asynchronous nature of a presentation layer protocol data session, and idle time within a session.
  • a session when a session is idle, no data is streamed from a server 106 to a client 102 , and therefore no data is intercepted, recorded, or forwarded for playback.
  • the playback device 514 without a regular stream of data, cannot determine if it can extend its timeline to reflect that this time has past.
  • One problem created by concluding that time has passed with no activity and reflecting that in an indication to a viewer of the data stream arises when session activity data for a time in the past arrives.
  • the playback device 514 receives no data, concludes that no activity occurred, indicates to the viewer that no activity occurred, and then displays data reflecting that activity did actually occur at a point in time in the past after indicating that no activity occurred at that time. Essentially, the playback device 514 has wrongly assumed that “nothing” has happened and has progressed the current player frame too far. This may lead to a viewer of the recorded session missing activity that occurred in the past or in confusion for the viewer of the recorded session.
  • the playback device 514 determines that session data has arrived for a point in time in the past, indicating this to a viewer, and forces the viewer to return to the point in time when the session activity occurred. In some embodiments, this solution creates additional problems, including usability issues if the section of the recording is lengthy, or if the type of session activity is not significant to the viewer.
  • a packet is transmitted to the playback device 514 indicating that at a particular point in time, no session activity occurred and there is no session data to transmit to the playback device 514 .
  • a packet type referred to as an “empty packet” is created and transmitted to the playback device 514 .
  • the empty packet holds a time stamp like all other packets but contains no payload. If a session being recorded has had no presentation layer protocol data received within its buffering time period (for example, a 500 millisecond interval mentioned earlier), the recorder 3010 will inject an empty packet into the stream. In some embodiments, as with the data buffering approach, empty packets will only be injected for as long as time-shifted playback is active.
  • the playback device 514 now receives a steady stream of empty packets and can safely extend its time line and allow playback into “known” idle periods.
  • the transmission of empty packets results in additional overhead, such as a slight increase in the recorded file size or some resource usage even when the session is idle.
  • an empty packet is between 4 and 6 bytes in length (typically 5 bytes) and only two are sent per second. Assuming 5 byte packets, this equates to an extra 36 KB per hour per session. In some embodiments, due to the infrequency of live playback and compared to the typical overall data rate of 2 MB per hour per session, this extra overhead may be deemed insignificant.
  • a recorder 3010 executes on a presentation server to intercept and record presentation layer protocol data.
  • the recorder 3010 receives an indication that user has requested time-shifted playback of a session the recorder 3010 is currently recording.
  • the receipt of the indication indicates to the recorder 3010 that it should use functionality required to provide time-shifting.
  • the recorder 3010 may buffer packets for transmission until it receives a notification of a live viewing, and then, upon receipt of the indication, switch to a mode where it decreases the amount of time for which it buffers the packet.
  • the recorder 3010 does not use the empty packets described above until it receives an indication that a user has requested time-shifted session playback.
  • various methods are available for notifying the recorder 3010 that a playback device 514 is playing a session for a viewer while the recorder 3010 records the session.
  • it may be considered inappropriate to open new network ports on each server on which a recording component resides to support this requirement.
  • the methods and systems implement a reverse poll mechanism.
  • Each presentation server will “poll” the third device 222 at uniform intervals for the list of sessions currently being played live. In some of these embodiments, this mechanism is preferred to others even though polling may have a greater overhead or be less responsive than asynchronous notification.
  • Polling requires no listening ports on the presentation server, but does raise the issue of how frequently to poll.
  • short intervals are used to ensure that the live session's buffering can be switched promptly although the interval may affect scalability.
  • long intervals have low resource impact but can lead to a lag in switching buffering modes.
  • a predetermined time interval is selected by an administrator.
  • a polling interval of 10 seconds provides compromise between a short interval and a long interval. In one of these embodiments, the impact of a polling interval is rarely perceptible since most recorded sessions already have existing data available for download and immediately playback.
  • having existing data available for immediate playback gives the user time to orientate themselves with what they are watching.
  • the polling interval has passed by the time the user has completed a viewing of the available data and requests more recently recorded content.
  • a short polling interval may be set, so that a user need wait only a few seconds. For example, in an embodiment with a polling interval is set to ten seconds, the user only need wait a maximum of 10 seconds (average 5 seconds) if they want to view the most recent few minutes of recording.
  • a system having 1000 presentation servers all actively recording equates to a single third device 222 having to process 100 poll messages per second.
  • this is feasible from a system scalability perspective.
  • the processing of each poll message does not involve any I/O, complex computations, thread context switches or inter-process communication.
  • increasing the poll interval via configuration is also possible if required.
  • the inclusion of the “poll” message has multiple purposes.
  • the poll message is also used as a “keep-alive” message for the third device 222 .
  • the third device 222 is now capable of tracking which presentation servers are actively recording and how many sessions are currently being recorded.
  • a distributor transmits a copy of at least one packet of the presentation layer protocol data stream (step 3104 ).
  • the recorder stores a copy of the at least one packet of the presentation layer protocol data stream 208 .
  • the recorder 3010 transmits at least one copied packet to the distributor 3020 .
  • the recorder 3010 stores the copy of the at least one packet in a buffer.
  • the recorder 3010 transmits a plurality of packets stored in the buffer to the distributor.
  • the distributor 3020 retrieves the copy of the at least one packet of the presentation layer protocol data stream from a storage device. In another embodiment, the distributor 3020 retrieves the packet from a storage device, such as a storage 218 described above in connection with FIG. 2 . In still another embodiment, the distributor receives the copy of the at least one packet from the recorder 3010 .
  • a protocol engine uses information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet (step 3106 ).
  • the at least one copied packet is used upon receipt by the protocol engine of the at least one copied packet.
  • the at least one packet is used upon receiving by the protocol engine a request to regenerate the display data represented by the at least one copied packet.
  • the steps of intercepting the presentation layer protocol data stream and of transmitting a copy of at least one packet of the presentation layer protocol data stream repeat until the first device completes transmission of the protocol data stream to the second device (step 3108 ).
  • the step of using information associated with the at least one packet repeats until the protocol engine has regenerated display data represented by each received copied packets.
  • the protocol engine only regenerates display data for packets which a user has explicitly requested.
  • the protocol engine starts and stops a regeneration of the display data upon receiving an indication of a request to start or to stop the regeneration.
  • methods and systems providing time-shifted playback features prevent any additional opportunities for detecting recording of a presentation layer protocol data stream.
  • playback of a presentation layer protocol session does not affect the running of a presentation layer protocol state machine.
  • the stream of presentation layer protocol data that the end user receives is the same under live playback. This also implies there will be no visual and otherwise perceptible artifacts in their recording.
  • no process or system object accessible indicates to the end user that they are being viewed live (or even being recorded).
  • the end user is also restricted from issuing his or her own “poll” message to the third device 222 for finding list of live playback sessions. Even for local administrator users, this would be difficult as the session IDs returned from this poll message are not terminal session identifiers. In one embodiment, this comprises security by obfuscation because mapping these internal session identifiers to terminal session identifiers would require specialized skills.
  • another method of detection includes observing periods of performance degradation. In one of these embodiments, however, even for a physical machine dedicated to a single user, this would difficult to perceive as the impact is so light. On a shared application server, this would be impossible. In these embodiments, the end user is denied access to viewing performance counters or similar performance related data.
  • methods and systems for time-shifted playback ensure that the only feasible means for an end user with normal user privileges to detect live playback is to perform a social engineering attack.
  • a playback device 514 transmits a search request to a third device 222 .
  • the playback device 514 component searches an enumeration of sessions available for displaying to a viewer.
  • the enumeration includes only sessions where completed recordings of the sessions are available.
  • the enumeration includes only sessions where incomplete recordings of the sessions are available.
  • the enumeration includes both sessions that are completely recorded and sessions that are incompletely recorded.
  • the playback device 514 includes functionality for distinguishing “live” recordings from “completed” recordings and makes this distinction apparent to the user in the search result list control.
  • the playback device 514 may periodically query the third device 222 for a status update of each live session listed.
  • the search list remains in a refreshed state without user intervention.
  • a user of a playback device 514 may select a stream of recorded data for viewing.
  • the stream of recorded data contains data associated with a session which the recorder 3010 is still recording packets from the presentation layer protocol data stream, a channel is created and left open for receiving additional recorded data as it becomes available from the recorder 3010 .
  • the third device 222 it will be forwarded to the playback device 514 for processing via the channel.
  • the recorder 3010 completes recording a session complete while the session is being played live, the playback device 514 will close the channel and playback will continue uninterrupted.
  • security-related concerns may arise from functionality providing live playback.
  • live session files cannot be encrypted to preserve digital rights management (DRM) and there is no digital signature verification.
  • DRM digital rights management
  • the playback device 514 will attempt to process live recordings from private memory only.
  • live recordings are not written to a local file cache and attempts are made to prevent data from being paged or otherwise written to a persistent storage device.
  • loss of data in transit is less of a concern when traffic between a playback device 514 and a third device 222 is SSL/TLS encrypted using strong encryption keys.
  • a warning message will be displayed to the user before playback commences that the source and contents of the file cannot be verified. If users wish to obtain this statement of authenticity, they can re-download the session recording when it is complete. In many embodiments, this provides a reasonable compromise as digital signatures provide legal or forensic value to the recordings.
  • playback device 514 features remain available, including a background processing engine that generates key-frames for fast seeking. Functionality for seeking around a live recording is provided.
  • a foreground protocol engine receives a request for rendering the contents of a packet in a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received (step 3202 ).
  • the foreground protocol engine identifies a state-snapshot having an associate timestamp previous to that of the requested packet (step 3204 ).
  • the foreground protocol engine displays, during transmission of the presentation layer protocol data stream from a first device to a second device, the requested packet responsive to the identified state-snapshot (step 3206 ).
  • the received request results when the foreground protocol engine 1106 regenerates display data by rendering the contents of a packet in a first plurality of packets to a viewer using the display 1108 and the viewer wishes to seek for a particular display data.
  • the foreground protocol engine renders to a buffer the contents of an intermediate packet between the state-snapshot and the requested packet.
  • a recipient of rendered display data may seek for content in real-time.
  • the recipient of the rendered data may seek for content in real-time during the presentation of a packet from a presentation layer protocol data stream which has not been completely recorded.
  • the foreground protocol engine comprises a foreground protocol engine 1106 and provides real-time seeking functionality as described in connection with FIG. 11 .
  • the foreground protocol engine 1106 also provides the above-described functionality for real-time seeking of portions of presentation layer protocol data streams, such as a first plurality of received packets, which comprise a subset of the presentation layer protocol data stream.
  • the foreground protocol engine 1106 generates, during transmission of the presentation layer protocol data stream from a first device to a second device, a real-time perceptible representation of a first plurality of packets received for presentation to a viewer using the display 1108 .
  • the foreground protocol engine 1106 generates the real-time perceptible representation by rendering the contents of at least one packet in the protocol data stream 1110 or in the plurality of received packets.
  • the perceptible representation may include, without limitation, separately or together, audio, visual, tactile, or olfactory presentations.
  • the foreground protocol engine 1106 provides the functionality for real-time seeking amongst the first plurality of packets similar to the functionality for real-time seeking in a recorded protocol stream, as described above in connection with FIG. 9 .
  • state-snapshots enable regeneration of display data by storing a state of a protocol engine rendering presentation layer protocol data at a point in time when a recorder 206 copied at least one packet from the presentation layer protocol data stream 208 .
  • the state-snapshot comprises a data structure describing a state of a screen at a point in time.
  • a flow diagram depicts one embodiment of the steps taken in a method for generating state-snapshots enabling real-time seeking during real-time playback of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine.
  • the background protocol engine receives a first plurality of packets during transmission of the presentation layer protocol data stream from a first device to a second device (step 3302 ).
  • the background protocol engine regenerates display data represented by the first plurality of packet (step 3304 ).
  • the background protocol engine generates at least one state-snapshot during a reading of at least one packet in the first plurality of packets (step 3306 ).
  • the background protocol engine stores the generated state-snapshot (step 3308 ).
  • the regeneration of the display data and the at least one state-snapshot are modified responsive to receiving at least one packet in the second plurality of packets (step 3310 ).
  • the background protocol engine receives a first plurality of packets during transmission of the presentation layer protocol data stream from a first device to a second device (step 3302 ).
  • the background protocol engine generates a representation of the first plurality of packets.
  • the background protocol engine 1102 generates a representation of the first plurality of packets by rendering the contents of the first plurality of packets to a buffer.
  • the buffer is an off-screen buffer.
  • the background protocol engine generates display data represented by the first plurality of packets (step 3304 ).
  • the background protocol generates display data by rendering the contents of the first plurality of packets to a buffer.
  • the buffer is an off-screen buffer.
  • the foreground protocol engine generates the display data.
  • the foreground protocol engine 1106 generates a human-perceptible representation of the first plurality of packets by rendering the contents of the first plurality of packets substantially simultaneously with the background protocol engine 1102 generating at least one state-snapshot during its reading of the first plurality of packets.
  • the background protocol engine generates at least one state-snapshot during a reading of at least one packet in the first plurality of packets (step 3306 ).
  • the generation of the at least one state-snapshot occurs substantially simultaneously with a presentation of the first plurality of packets.
  • the generation of the at least one state-snapshot occurs during a sequential reading of the first plurality of packets by the background protocol engine.
  • the background protocol engine stores the generated state-snapshot (step 3308 ).
  • the state-snapshots may act as markers throughout the first plurality of packets, assisting in the location of a particular point in time in the first plurality of packets and of the packets that come before or after the state-snapshot 1104 .
  • the generation of the display data and the at least one state-snapshot are modified, responsive to receiving at least one packet in the second plurality of packets (step 3310 ).
  • the background protocol engine receives a packet from the second plurality of packets—a previously un-received packet—and stores the packet from the second plurality of packets in the first plurality of packets.
  • the background protocol engine stores newly-received packets in a buffer with previously-received packets.
  • the modification to the first plurality of packets results in a modification or regeneration of the generated display data, or in the regeneration of additional display data.
  • the addition of the packet from the second plurality of packets to the first plurality of packets results in a modification of a state-snapshot, or in the generation of additional state-snapshots.
  • the background protocol engine generates the state-snapshots for the first plurality of packets using methods for generating state-snapshots for recorded protocol data streams described above. In other embodiments, the foreground protocol engine regenerates display data represented by the first plurality of packets using methods for regenerating display data represented by packets in recorded protocol data streams as described above.
  • system for real-time seeking during real-time playback of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine includes a background protocol engine 1102 , a state-snapshot 1104 , a foreground protocol engine 1106 , and a protocol data stream 1110 .
  • the background protocol engine receives the first plurality of packets during transmission of the presentation layer protocol data stream from a first device to a second device.
  • the state-snapshot generated by the background protocol engine, comprises a state of a protocol engine rendering the presentation layer protocol data stream at a point in time when a recorder, such as the recorder 3010 , copied a packet from the presentation layer protocol data stream into the first plurality of packets.
  • the foreground protocol engine receives the first plurality of packets, renders the contents of the first plurality of packets, receives a request to seek display data represented by a content in a packet in the first plurality of packets, and renders the content representing the requested display data using the state-snapshot.
  • the foreground protocol engine renders the requested display data during transmission of the presentation layer protocol data stream from a first device, such as a server 106 , to a second device, such as a client 102 .
  • the background protocol engine updates the state-snapshot responsive to receiving at least one packet in the second plurality of packets.
  • protocol data stream 1110 comprises a portion of a second protocol data stream.
  • the protocol data stream 1110 is a first plurality of packets representing display data and with which metadata has been associated and into which additional information has been embedded.
  • the background protocol engine adds those packets to the protocol data stream 1110 .
  • the system described in FIG. 11 the system described in FIG.
  • 11 provides functionality for real-time seeking during real-time playback by using a portion of a protocol data stream, such as the first plurality of packets, in a substantially similar manner to the ways in which the system provides functionality for real-time seeking during playback of a completely recorded protocol data stream.
  • a flow diagram depicts one embodiment of the steps taken in a method for adaptive generation of state-snapshots.
  • a user is presented with a representation of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine during transmission of the presentation layer protocol data stream from a first device to a second device (step 3402 ).
  • the background protocol engine monitors an activity of the user during the presentation (step 3404 ).
  • the background protocol engine develops an activity profile, responsive to the monitoring of the activity (step 3406 ).
  • the background protocol engine generates at least one state-snapshot, responsive to the activity profile (step 3408 ).
  • the background protocol engine modifies the at least one state-snapshot, responsive to receiving at least one packet in the second plurality of packets (step 3410 ).
  • the steps taken for adaptive generation of state-snapshots described above in connection with FIGS. 12 through 15 are used with a portion of a protocol data, such as the first plurality of packets.
  • a user is presented with a representation of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine during transmission of the presentation layer protocol data stream from a first device to a second device (step 3402 ).
  • the background protocol engine receives packets from the second plurality of packets, stores the newly-received packets in the first plurality of packets.
  • the background protocol engine continues to receive packets from the second plurality of packets until a server ceases transmission of a presentation layer protocol data stream to a client.
  • the background protocol engine monitors an activity of the user during the presentation (step 3404 ).
  • the foreground protocol engine 1106 generates the representation of the first plurality of packets and presents it to the user with the display 1108 .
  • the background protocol engine 1102 generates the representation.
  • a third device generates the representation.
  • the background protocol engine monitors an activity of a user during presentation of a portion of a session, such as during the presentation of regenerated display data represented by a first plurality of packets.
  • the background protocol engine develops an activity profile, responsive to the monitoring of the activity (step 3406 ).
  • the background protocol engine 1102 identifies a level of activity of the user.
  • the background protocol engine 1102 identifies a period of inactivity.
  • the background protocol engine 1102 identifies an area of interest to the user in the display data.
  • the activity profile may reflect these identifications.
  • the background protocol engine generates at least one state-snapshot, responsive to the activity profile (step 3408 ). In some embodiments, the background protocol engine 1102 determines to extend an interval between one or more state-snapshots. In other embodiments, the background protocol engine 1102 determines to reduce an interval between one or more state-snapshots. In still other embodiments, the background protocol engine 1102 determines to remove the at least one state-snapshot, responsive to the activity profile. In still other embodiments, the background protocol engine 1102 determines to add at least one state-snapshot, responsive to the activity profile.
  • the background protocol engine modifies the at least one state-snapshot, responsive to receiving at least one packet in the second plurality of packets (step 3410 ). In some embodiments, the background protocol engine revises an identification of an activity level responsive to receiving at least one packet in the second plurality of packets. In one of these embodiments, a viewer of a first portion of a presentation layer protocol data stream modifies his or her activity level when watching a different portion of the presentation layer protocol data stream. In another of these embodiments, the background protocol engine observes modifications in activity levels or and modifies, or regenerates, state-snapshots accordingly.
  • FIG. 16 summarizes one embodiment of the method 1600 discussed above used in a system for adaptive generation of state-snapshots, including a background protocol engine 1602 , a foreground protocol engine 1608 , a protocol data stream 1612 , an activity profile 1604 , and a state-snapshot 1606 .
  • the system described above also provides adaptive generation of state-snapshots during real-time playback of a presentation layer protocol data stream.
  • the foreground protocol engine presents, to a user, a representation of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine during transmission of the presentation layer protocol data stream from a first device to a second device.
  • the background protocol engine monitors an activity of the user during the presentation and generates a state-snapshot.
  • the background protocol engine determines an activity profile.
  • the background protocol engine modifies the state-snapshot and the activity profile responsive to receiving at least one packet in the second plurality of packets
  • the background protocol engine determines the activity profile responsive to the monitoring. In another embodiment, the background protocol engine maintains the state-snapshot responsive to the activity profile. In still another embodiment, the background protocol engine updates a state-snapshot responsive to an observed change in an activity profile.
  • the background protocol engine observes a modification to an activity profile.
  • an activity profile varies between the viewing of a first portion of a presentation layer protocol data stream and the viewing of a second portion of the presentation layer protocol data stream.
  • the background protocol engine maintains an updated activity profile and generates new state-snapshots, or modifies existing state-snapshots accordingly.
  • playback data structures may be used in playback of recorded protocol data streams. Additionally, in other embodiments, playback data structures may be used in real-time playback of presentation layer protocol data streams.
  • a method for generating playback instructions for playback of a presentation layer protocol data stream comprising a first plurality of packets already received by a protocol engine and a second plurality of packets yet to be received by the protocol engine during transmission of a presentation layer protocol data stream includes the step of receiving, by the protocol engine executing on a playback device, the first plurality of packets representing display data generated by an application program executed on a server.
  • the protocol engine determines, for a packet in the first plurality of packets, to render the contents of the packet in a human-perceptible manner.
  • the protocol engine stores the determination in a playback data structure.
  • the protocol engine determines to display a packet in the first plurality of packets responsive to the contents of the packet. In one of these embodiments, the protocol engine makes the determination responsive to an indication of an application program having input focus. In another of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of user input stored in the packet. In some of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of graphics update stored by the packet. In others of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of interaction sequence stored by the packet.
  • a playback data structure describes how to regenerate the display data contained within the first plurality of packets.
  • the instructions stored within the playback data structure control the process of rendering display data.
  • the playback data structure comprises a time for rendering the contents of a packet in the first plurality of packets.
  • the time contained in the playback data structure is used for rendering the contents of the packet and not a time of rendering associated with the packet in the first plurality of packets, if any.
  • the playback data structure accepts user input in changing the time of rendering.
  • the playback data structure comprises metadata that describes how to perform one or more playbacks of a first plurality of packets.
  • the playback data structure consists of a record for each packet in the first plurality of packets, indicating at what relative point in time the contents of that packet should be rendered during playback.
  • the metadata also contains the offset within the file of the start of the packet.
  • the background protocol engine As the background protocol engine receives additional packets in the presentation layer protocol data stream, the background protocol engine generates additional playback data structures or modifies existing playback data structures.
  • the background protocol engine executes on a playback device and generates a playback data structure in response to receiving a first plurality of packets, said first plurality of packets representing display data generated by an application program executed on a server.
  • the foreground protocol engine receives the first plurality of packets and renders the first plurality of packets responsive to the playback data structure generated by the background protocol engine substantially concurrently with the background protocol engine receiving at least one packet in the second plurality of packets and generating a playback data structure in response to the received at least one packet in the second plurality of packets.
  • the foreground protocol engine receives the first plurality of packets and renders the first plurality of packets responsive to the playback data structure generated by the background protocol engine substantially concurrently with the background protocol engine receiving a second in the first plurality of packets and generating a playback data structure in response to the received second packet in the first plurality of packets.
  • the background protocol engine and the foreground protocol engine each receive the first plurality of packets.
  • the background protocol engine generates the playback data structure substantially simultaneously with the foreground protocol engine rendering the first plurality of packets.
  • the background protocol engine stores in the playback data structure at least one instruction for rendering at least one packet in the first plurality of packets.
  • the background protocol engine stores metadata in the playback data structure.
  • the background protocol engine stores in the playback data structure a record indicating a time to render at least one packet in the first plurality of packets.
  • the foreground protocol engine renders at least one packet in the first plurality of packets responsive to the playback data structure. In one embodiment, the foreground protocol engine renders at least one packet in the first plurality of packets in a human-perceptible manner and to a buffer. In another embodiment, the foreground protocol engine renders at least one packet in the first plurality of packets to a buffer.
  • a background protocol engine receives a first plurality of packets representing display data generated by an application program executing on a server, during transmission, by the server, of the presentation layer protocol data stream to a client.
  • the background protocol engine determines for at least one packet in the first plurality of packets, to render the packet in a human-perceptible manner.
  • the background protocol engine stores the determination in a playback data structure.
  • a foreground protocol engine retrieves at least one packet from the first plurality of packets, access the playback data structure, and renders the at least one packet responsive to the playback data structure.
  • the background protocol engine determines to display a packet in a first plurality of packets and generates a corresponding playback data structure as described above in connection with FIG. 19 .
  • the foreground protocol engine renders the contents of a packet in the first plurality of packets responsive to the playback data structure as described above in connection with FIG. 19 .
  • presentation layer protocol data streams may be rendered without perceptible intervals of time containing no activity.
  • a completed recording of a presentation layer protocol data stream is rendered.
  • the methods described above may be used to render portions of incompletely recorded presentation layer protocol data streams.
  • a method of eliminating a period of inactivity in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a first packet in the first plurality of packets, said first plurality of packets representing display data.
  • a second packet in the first plurality of packets is identified, said second packet immediately preceding the first packet.
  • a first time interval between the first packet and the second packet is determined. It is determined that the first time interval exceeds a threshold.
  • the contents of the first plurality of packets with a second time interval between the first packet and the second packet are rendered, said second time interval comprising a shorter time interval than the first time interval. At least one packet in the second plurality of packets is received.
  • the at least one packet in the second plurality of packets is added to the first plurality of packets upon receipt.
  • the steps of identifying the first packet and a second packet preceding the first packet and determining whether a time interval between the two exceeds a threshold are repeated for the received at least one packet in the second plurality of packets.
  • the steps of identifying the first packet and a second packet preceding the first packet and determining whether a time interval between the two exceeds a threshold are repeated for a second packet in the first plurality of packets.
  • the methods described above in connection with FIG. 21 are used to eliminate perceptible intervals of time with no activity from portions of presentation layer protocol data streams, such as the first plurality of packets.
  • a method of generating playback instructions for rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a type of input stored by a packet in the first plurality of packets representing display data generated by an application program. The packet is marked responsive to the type of input.
  • a playback data structure stores a destination for rendering the contents of the packet responsive to the marking. At least one packet in the second plurality of packets is received. In one embodiment, the at least one packet in the second plurality of packets is added to the first plurality of packets upon receipt. A second packet in the first plurality of packets is received.
  • the steps of identifying a type of input stored by a packet, marking the packet responsive to the type of input, storing the rendering destination in the playback data structure, and receiving additional packets repeat as new packets are received until a server completes transmission of the presentation layer protocol data stream.
  • the type of input stored by a packet determines whether or not the packet will be rendered.
  • the packet contains no content.
  • at least one packet contains no content.
  • an interval of time comprised of at least one packet containing no content is identified. In some of these embodiments, the interval of time will not be rendered.
  • an empty packet type as described above in connection with FIGS. 30A-D and 31 is received and identified as a packet containing no data.
  • the type of input refers to input from certain types of input devices, including, without limitation, a keyboard, a mouse, a microphone, or a camera.
  • the step of identifying the type of input further comprises identifying the type of input as input from an input device.
  • the step of identifying the type of input further comprises identifying the type of input as keyboard input.
  • the type of input is not related to the input device. In one of these embodiments, the type of input is identified as a command.
  • the method eliminates perceptible intervals of time containing no meaningful activity.
  • a policy identifies a particular type of input as meaningful or as insignificant.
  • the policy may be hard coded into a protocol engine, in some embodiments. In other embodiments, an administrator configures the policy.
  • a protocol engine identifies a packet as insignificant if the packet contains no content.
  • the packet represents an interval of time in which the no user activity occurred to be recorded into a packet in the first plurality of packets.
  • the protocol engine stores in a playback data structure a destination for rendering each of the plurality of packets in the first plurality of packets in such a way that any insignificant packet does not render in a perceptible manner.
  • the protocol engine may generate an indication that time has passed without activity. For example, a timeline of the presentation layer protocol data stream presented to a viewer may be updated to reflect that time has passed although no display data has changed.
  • the protocol engine uses the empty packet type described above to identify a packet as insignificant.
  • methods described above for eliminating periods of time containing no meaningful activity in recorded presentation layer protocol data streams are also used to eliminate periods of time containing no meaningful activity in portions of the presentation layer protocol data stream, such as the first plurality of packets.
  • FIG. 22 which depicts one embodiment of a regenerated recorded stream whose contents are rendered responsive to a playback data structure
  • rendering portions of protocol data streams responsive to the playback data structure allows elimination of intervals of time containing no meaningful activity (depicted by the white and striped blocks in FIG. 22 ), which includes intervals of time containing no activity at all. This rendering provides a more meaningful regeneration of the first plurality of packets in the presentation layer protocol data stream to a user.
  • a method of eliminating a period containing no meaningful activity in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of determining a first time interval between a marked packet and a nearest previous marked packet in the first plurality of packets, said first plurality of packets representing display data. A determination is made that the first time interval exceeds a threshold.
  • the contents of the first plurality of packets are rendered with a second time interval between the marked packet and the nearest previous marked packet, said second time interval comprising a shorter time interval than the first time interval. At least one packet in the second plurality of packets may be received.
  • a second packet in the first plurality of packets may be received.
  • the newly received packets may be added to the first plurality of packets.
  • the steps of determining that the first time interval exceeds a threshold and rendering the contents of the first plurality of packets with the second time interval is repeated until the server completes transmission of the presentation layer protocol data stream.
  • the contents of the first plurality of packets are rendered with a second time interval between the marked packet and a previous packet said second time interval comprising a shorter time interval than the first time interval.
  • the contents of the first plurality of packets are rendered with a second time interval between the marked packet and a packet following the marked packet, said second time interval comprising a shorter time interval than the first time interval.
  • the contents of the first plurality of packets are rendered using the methods described above in connection with FIG. 28 .
  • Methods for eliminating graphics updates in rendering recorded sessions also eliminate graphics updates in rendering portions of sessions, for example, by removing graphics updates in a first plurality of packets comprising a subset of a presentation layer protocol data stream.
  • cyclic updates may be identified and a determination may be made not to render a cyclic update in a human-perceptible manner.
  • these methods may identify cyclic updates within portions of presentation layer protocol data streams.
  • a method of eliminating graphics updates in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a packet in the first plurality of packets, the first plurality of packets representing display data generated by an application program, the packet containing a first graphics update.
  • a screen region affected by the first graphics update is determined.
  • An indication of the state of the screen region after the first graphics update and the location of the screen region is stored.
  • a second graphics update affecting the screen region within a time interval is identified.
  • a playback data structure indicates a destination for rendering a second packet in the first plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
  • a playback data structure indicates a time interval to render associated with the second packet in the first plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
  • a graphics update contained within a plurality of packets is identified.
  • the screen region affected responsive to the graphics update stored by each packet in the identified plurality of packets is determined.
  • a copy of the screen region affected by the graphics update is stored.
  • a time interval is defined to approximate an upper limit of a human scale cyclic period.
  • a playback data structure indicates that the contents of the packet render in a perceptible manner and to a buffer.
  • a playback data structure indicates that the contents of the packet render to a buffer.
  • the background protocol engine stores these indications in the playback data structure.
  • Another method for eliminating graphics updates in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a packet in the first plurality of packets, the first plurality of packets representing display data generated by an application program, the packet containing a first graphics update.
  • a screen region affected by the first graphics update is determined.
  • An indication of the state of the screen region after the first graphics update and the location of the screen region is stored.
  • a second graphics update affecting the screen region within a time interval is identified.
  • a playback data structure indicates a destination for rendering a packet in the second plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
  • a playback data structure indicates a time interval to render associated with the packet in the second plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
  • a graphics update contained within a plurality of packets is identified.
  • the screen region affected responsive to the graphics update stored by each packet in the identified plurality of packets is determined.
  • a copy of the screen region affected by the graphics update is stored.
  • a time interval is defined to approximate an upper limit of a human scale cyclic period.
  • a playback data structure indicates that the contents of the packet render in a perceptible manner and to a buffer.
  • a playback data structure indicates that the contents of the packet render to a buffer.
  • the background protocol engine stores these indications in the playback data structure.
  • methods for eliminating interaction sequences may be used with presentation layer protocol data streams.
  • the methods are used with completed records of presentation layer protocol data streams.
  • the methods are used with portions of presentation layer protocol data streams, such as a first plurality of packets comprising a subset of packets in a presentation layer protocol data stream.
  • a method of eliminating interaction sequences in rendering presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying, responsive to a policy, a start of an interaction sequence represented by at least one packet in the first plurality of packets.
  • a playback data structure indicates that the interaction sequence should render to a buffer.
  • a termination of an interaction sequence is identified.
  • a first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified.
  • a playback data structure indicates a second time interval to render shorter than the first time interval.
  • Another method of eliminating interaction sequences in rendering presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying, responsive to a policy, a start of an interaction sequence represented by at least one packet in the first plurality of packets.
  • a playback data structure indicates that the interaction sequence should render to a buffer.
  • a packet in the second plurality of packets is received.
  • a termination of an interaction sequence represented by the received packet in the second plurality of packets is identified.
  • a first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified.
  • a playback data structure indicates a second time interval to render shorter than the first time interval.
  • the start of the interaction sequence is identified by identifying a visual marker.
  • a visual marker comprises a credentials window, displayed in the same way for all sessions.
  • a visual marker comprises a replacement of a credentials window by a blank screen and then by a desktop background.
  • a visual marker comprises the display of recognizable icons.
  • a start of an interaction sequence is identified by determining a start time of an interaction sequence.
  • a component detects the start time of an event in an interaction sequence.
  • the component detects the start time of a logon sequence.
  • the component detects the start time of a logoff sequence.
  • the identification of the start of the interaction sequence is responsive to identifying a window with an input focus.
  • the interaction sequence is rendered to a buffer. Rendering the interaction sequence to a buffer results in the interaction sequence being imperceptible to a user of the rendering. For embodiments where a policy or user categorized the interaction sequence as insignificant, this rendering results in the elimination of an insignificant interaction sequence.
  • the termination of the interaction sequence is identified by identifying a visual marker. In other embodiments, a termination of an interaction sequence is identified by determining a termination time of the interaction sequence. In one of these embodiments, a component detects the termination time of an event in an interaction sequence. In another of these embodiments, the component detects the termination time of a logon sequence. In still others of these embodiments, the component detects the termination time of a logoff sequence. In another embodiment, identifying the termination of the interaction sequence is responsive to identifying a window with an input focus.
  • an interaction sequence comprises use of an application.
  • a policy identifies interaction sequences comprising use of an application that should not render in a perceptible manner.
  • applications include, without limitation, word processing documents.
  • a start of an interaction sequence is identified by identifying an application having input focus.
  • the contents of a packet represent a window having focus
  • a determination is made as to the application responsible for the process that created the window.
  • the contents of the packet representing a window having focus include window notification messages indicating a change in input focus. If the responsible application identifies a start of an interaction sequence which should not render perceptibly, an indication is stored in a playback data structure to render the interaction sequence to a buffer.
  • a termination of an interaction sequence is identified by identifying the acquisition of focus by a window owned by a process not associated with the application of the interaction sequence.
  • a first time interval is associated with the interaction sequence. Perceptibly rendering the time interval associated with the interaction sequence in an embodiment where the interaction sequence itself does not render results in a period of time perceptible to a user of the rendering in which no display data renders and the user waits through the time interval before a rendering of the contents of a packet after the interaction sequence.
  • One embodiment eliminates the time interval associated with the interaction sequence by rendering a shorter time interval in place of the original time interval.
  • a protocol engine renders the contents of at least one packet in a first plurality of packets, providing to a user a regeneration of the first plurality of packets.
  • the protocol engine automatically varies the time intervals between rendering the contents of at least one packet, resulting in context-sensitive time-warped playback.
  • rendering approximates the ability of the user to comprehend the display data presented to the user.
  • the time intervals between rendering contents of packets increase when the protocol engine determines the display data represented by the contents of the packets to have an increased level of complexity or importance, as defined by a policy.
  • the time intervals between rendering contents of packets decrease when the protocol engine determines the display data represented by the contents of the packets to have a decreased level of complexity or importance, as defined by a policy.
  • the protocol engine approximates the ability of the user to comprehend the display data and renders the contents either more slowly to give the user time to comprehend the rendering or renders the contents faster when a user requires less comprehension time.
  • methods for rendering recorded computer sessions provide automatic time-warped playback. These methods may also provide automatic time-warped playback during rendering of real-time presentation layer protocol data streams, in which the recording of the session represented by the data stream is incomplete.
  • a method of automatic time-warped playback in real-time rendering a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine includes the step of receiving, by the background protocol engine, the first plurality of packets representing display data.
  • the background protocol engine determines a measure of complexity represented by at least some of the packets in the first plurality of packets.
  • the background protocol engine identifies an interval of time between the at least some of the packets in the first plurality of packets.
  • the background protocol engine modifies the interval of time responsive to the measure of complexity represented by the at least some of the packets in the first plurality of packets in the recorded session.
  • the background protocol engine stores, in a playback structure, the modified interval of time.
  • a foreground protocol engine renders, during transmission of the presentation layer protocol stream from a first device to a second device, the first plurality of packets responsive to the playback data structure.
  • the steps taken in the methods described in FIG. 27 are also taken to render, during transmission of the presentation layer protocol stream from a first device to a second device, the first plurality of packets, responsive to the playback data structure.
  • the protocol engine determines the measure of complexity by identifying likely sequences of typing in keyboard input. In one embodiment, the protocol engine inspects at least one type of key involved to identify likely sequences of typing in keyboard input. In another embodiment, the protocol engine inspects a sequence of at least one glyph rendered to complete a heuristic approximation of likely sequences of typing in keyboard input.
  • the protocol engine stores classifications of keys determined by characteristics of the key. Key characteristics include, without limitation printable or non-printable characters, white space, navigation keys, or function keys, and include combinations of characteristics.
  • a protocol engine determines that sections of input comprising printable characters and occasional navigation keys constitute normal typing, while sections with mostly non-visible keys do not constitute normal typing.
  • the protocol engine determines a measure of complexity responsive to the amount of white space identified.
  • the protocol engine comprises a definition of word processing indicating that a white space key appears on average approximately every 5-8 characters in typical typing patterns.
  • the protocol engine uses the appearance of non-printable characters to determine the measure of complexity.
  • the protocol engine accesses the keystroke sequences to identify sequences of non-white space printable characters appearing close together in time.
  • the protocol engine comprises the capacity to compare the keystroke sequences to a dictionary to identify valid words and determine a measure of complexity relating to an ability of a user to comprehend valid words versus invalid words.
  • the protocol engine determines that the contents of the packet contain commands to render glyphs. In this embodiment, the protocol engine uses the glyphs to determine whether the display data represents a user activity of typing. In this embodiment, if a glyph rendering rate approximates the keyboard input rate with a small delay, it is likely that keystrokes are directly resulting in glyphs, thus making it quite likely the user is typing. In one embodiment, the protocol engine correlates the keys entered with the glyphs produced. In another embodiment, the protocol engine determines the spatial sequence (left-to-right, right-to-left, etc.) of the rendered glyphs to determine that a user is typing. In one embodiment, the protocol engine makes the determination of the measure of complexity responsive to the result of analyzing the contents of the plurality of packets and identifying patterns and activities represented by the contents.
  • the protocol engine makes the determination of the measure of complexity responsive to an identification of a type of mouse input. In one embodiment, the protocol engine determines that a mouse input representing a click of the mouse causes actions that may need a slower rendering rate to comprehend, especially if the clicks follow a sequence of typing. In another embodiment, the protocol engine determines that mouse input that does not represent a clicking of a mouse does not affect the ability of a user to comprehend display data, and thus does not affect the measure of complexity.
  • the protocol engine makes the determination of the measure of complexity responsive to identifying a heuristic approximation of complexity of a graphics update.
  • the protocol engine identifies a heuristic approximation of complexity of a graphics update based upon, without limitation, the size of region(s) being updated, the size of the area of the region changed by the graphics commands, a historical frequency of updates to individual regions, cyclic graphics commands, number of graphics commands, frequency of graphics commands, time interval between adjacent packets whose contents contain graphics command, or the type of graphics update.
  • the protocol engine determines a low measure of complexity for the graphics update.
  • the protocol engine determines a high measure of complexity represented by the packets containing the graphics updates.
  • the protocol engine increases the interval of time between the packets to allow the user of the rendering increased time to comprehend the rendered display data. In another embodiment where at least some of the plurality of packets have content representing display data associated with a low measure of complexity, the protocol engine decreases the interval of time between the packets to reflect decreased amount of time the user requires to comprehend the rendered display data. In one embodiment, a user requires a different amount of time between the rendered contents of packets than the amount rendered by the protocol engine. In this embodiment, the user modifies the interval of time to reflect the amount of time the user requires to comprehend the rendered display data. In some embodiments, the protocol engine also identifies a time interval between the at least some of the plurality of packets and other packets in the plurality of packets, modifying the interval of time identified between those sets of packets.
  • the protocol engine identifies a first marker associated with a packet in the first plurality of packets.
  • the packet comprises the marker.
  • the recorded session comprises the marker.
  • a user of the rendering of the display data defines the marker.
  • the protocol engine defines the marker.
  • the protocol engine modifies the interval of time responsive to the first marker.
  • the protocol engine increases the interval of time providing the user of the rendering of the display data additional time for comprehending the contents of the packet associated with the first marker.
  • the protocol engine identifies a second marker in a second packet.
  • the protocol engine modifies the interval of time responsive to the distance between the first marker and the second marker.
  • the protocol engine provides increased time for comprehension of display data represented by contents of packets marked and decreased time for comprehension of data represented by contents of unmarked packets.
  • a user defines markers for display data of interest to the user and the protocol engine renders additional time for the display data of interest to the user and decreases time of rendering for display data not of interest to the user, as determined by the markers.
  • the protocol engine identifies a first marker in the at least some of the plurality of packets, said marker indicating an initial packet in the at least some of the plurality of packets.
  • the protocol engine modifies the interval of time responsive to the first marker.
  • the protocol engine identifies a second marker in a second packet in the at least some of the plurality of packets, said second marker indicating a final packet in the at least some of the plurality of packets and modifying the interval of time responsive to the interval of time between the first marker and the second marker.
  • the protocol engine also renders the plurality of packets responsive to the playback data structure instructions regarding modified time intervals. In another embodiment, a separate foreground protocol engine renders the plurality of packets.
  • a determination is made that recorded interaction with an application requires increased time for rendering, to provide a user of the rendering increased time for comprehension of the rendered display data.
  • the determination is made that the application requiring increased time comprises a more important application than an application not requiring the increased time.
  • the user makes the determination.
  • a policy makes the determination.
  • the protocol engine comprises a definition of applications that require increased time.
  • a method may provide automatic time-warped playback responsive to an identified application in rendering a recorded computer session. Similarly, the method provide automatic time-warped playback responsive to an identified application in rendering a portion of an incompletely recorded presentation layer protocol data session, or of a presentation layer protocol data session in the process of being recorded.
  • a method of automatic time-warped playback in real-time rendering of a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the steps of receiving the first plurality of packets representing display data.
  • a first packet in the first plurality of packets having a content representing a window having focus is identified, said window indicating an application.
  • a time interval between a second packet in the first plurality of packets whose contents render prior to the rendering of the content of the first packet and a third packet in the first plurality of packets whose contents render after the rendering of the content of the first packet is identified.
  • the identified time interval is modified responsive to the indicated application.
  • at least one packet in the first plurality of packets is rendered responsive to the modification.
  • the modification to the identified time interval includes an increase in the identified time interval. In another embodiment, the modification to the identified time interval includes a decrease to the identified time interval. In still another embodiment, the at least one packet in the first plurality of packets is rendered to a buffer. In yet another embodiment, the at least one packet in the first plurality of packets is rendered both to a buffer and in a perceptible manner.
  • systems may provide automatic time-warped playback in rendering recorded computer sessions. These systems may also provide automatic time-warped playback in rendering presentation layer protocol data streams comprising a first plurality of packets already received by a protocol engine and a second plurality of packets yet to be received by the protocol engine.
  • a protocol engine generating a playback data structure in response to receiving the first plurality of packets rendering, during transmission of the presentation layer protocol stream from a first device to a second device, at least one packet in the first plurality of packets responsive to the generated playback data structure.
  • the protocol engine stores in the playback data structure at least one instruction for rendering the first plurality of packets. In another embodiment, the protocol engine stores metadata in the playback data structure. In still another embodiment, the protocol engine renders the at least one packet in the first plurality of packets in a perceptible manner and to a buffer. In yet another embodiment, the protocol engine renders the at least one packet in the first plurality of packets to a buffer. In a further embodiment, a second protocol engine renders the at least one packet in the first plurality of packets responsive to the generated playback data structure.
  • a presentation refers to a server providing presentation layer protocol data to a client or to another server.
  • the server executes an application and provides generated application-output data to a client or another server.
  • the server provides access to presentation layer protocol data associated with, or created by, a resource, such as a plurality of applications, a desktop environment, or other computing environment.
  • the server provides presentation layer protocol data for a session (such as an execution of a resource), the session executing within a virtual machine executing in a hypervisor executing in a remote desktop session executing on the server.
  • a server executing a virtual machine providing access to a session transmits presentation layer protocol data to a second server executing a remote desktop session and forwarding the received data to a client.
  • the server provides presentation layer protocol data for a session executing within a virtual machine to a second server hosting a presentation layer protocol stack and forwarding the data to a client.
  • the ability to watch a presentation layer protocol session recording while it is still being recorded enhances systems and methods for playback of previously recorded sessions. It strengthens the position of such systems and methods as a market-leading monitoring and surveillance solution, and provides a significant gateway into the support/helpdesk market.
  • the systems and methods described above 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 compact disc, a digital versatile disc, a flash memory card, a PROM, a RAM, a ROM, or a magnetic tape.
  • the computer-readable programs may be implemented in any programming language. Some examples of languages that can be used include C, C++, C#, or JAVA.
  • the software programs may be stored on or in one or more articles of manufacture as object code.

Abstract

Systems and methods described herein disclose searching the content of a recorded presentation layer protocol session including the steps of storing, a plurality of packets sent to a client device, rendering, by a protocol engine, at least one stored packet in the plurality of stored packets to a local video buffer and analyzing the at least one rendered packet with wherein analyzing includes at least scanning the at least one rendered packet with an optical character recognizer executing on the server. The systems and methods described herein also disclose using the optical character recognizer to generate a word associated with the at least one packet, using a post processing component to generate identification data associated with the generated word associated with the at least one packet, and storing the generated word associated with the at least one packet and storing the identification data associated with the generated word.

Description

FIELD OF INVENTION
The present invention relates to methods and systems for playback of remote presentation protocols and, in particular, for capturing, replaying, highlighting and real-time seeking of text or characters entered in a recorded session during playback of remote presentation protocols.
BACKGROUND
Remote presentation protocols such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash., are inherently stateful. In order to view a particular point in a stream of recorded presentation protocol data, playback of the stream must begin from the very beginning of stream and must be played back sequentially until the desired point is encountered.
Conventional techniques for accessing a recorded stream of data out of sequential order typically involve the use of keyframes and delta frames. Keyframes are typically stored within the stream itself as synchronization points so that frames may be quickly reproduced on a screen. Delta frames typically describe differences from previous frames to produce the visible video frame.
Since remote presentation protocols are typically compact due to their stateful nature, the additional storage of keyframes increases file size by several orders of magnitude. Even with modern digital video compression techniques, keyframes generally add several orders of magnitude to the storage required for a stream of recorded presentation protocol data. However, omitting keyframes results in a non-seekable protocol. A method for seekability without the overhead of oversized files caused by stored keyframes is desirable.
Server-side recording of remote presentation protocols is useful in authoring training material, providing helpdesk support, enabling tutorials, or for environments where distributing software to each client workstation is cumbersome. However, many conventional methods for recording protocol data streams suffer from drawbacks such as inefficient and lossless encoding of computer screen activity. Recording and storing files solely on the server may create issues regarding the handling of large numbers of concurrent sessions. Many conventional systems typically suffer the drawbacks of recording significantly more data than will ever be reviewed, involving complex recording processes or generating large file sizes.
Some conventional methods for recording protocol data streams are not bound to the remote presentation protocol itself. Many of these solutions involve screen scraping/capture technologies or hooking of the client graphics engine and as a result suffer the drawback of requiring a processor-intensive encoding or transcoding process for playback. Furthermore, these conventional methods for recording protocol streams are not capable of detecting text included in video frame data at, seekability of the captured text using target words, or replaying a recorded stream of video data out of sequential order based on detected characters or text.
SUMMARY OF THE DISCLOSED EMBODIMENTS
The present invention provides a method for recording as a stream remote presentation protocols such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash., as well as enabling playback of the recorded stream at a later time. The present invention extends protocols initially designed for the live display of computer screen presentation into lossless real-time screen activity capture that can be recorded, without modification of the existing protocol definitions. Unlike traditional screen capture technology, recording does not need to take place on the client device or require any client-side components. Server-side recording provided by the present invention greatly simplifies deployment by allowing installation of recording software only on server machines instead of on many client devices. In an enterprise Citrix XenDesktop environment, for example, the ratio of client devices to server machines is regularly higher than 100 to 1.
The range of supported client devices further complicates the traditional client deployment problem. Citrix currently supports clients on Windows PCs, iPad, iPhone, Android based clients, UNIX, Linux, Java-based clients, DOS, a wide range of Windows CE and EPOC-based handheld devices as well as Macintosh. No platform-specific recording software or any other changes are required on any of these platforms for server-side recording to work. As remote presentation protocols are typically designed to work efficiently over relatively low speed networks by reducing bandwidth, the recording of such protocols is also inherently compact. As no transcoding to another video format ever takes place, the recording process is lightweight and the resulting stream is a true representation of what the user saw on their screen at record-time.
The present invention also makes remote presentation protocols, such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash., sequentially playable as a video format, and also permits random seeking/browsing without the use of stored keyframes based on text displayed on a computing device such as a client device. Text based seeking allows a user viewing the stream during playback to search through various frames using a target word search, skip to any position, forward or backward, in the stream and continue playback in a responsive fashion. The present invention makes very fast seeking possible without recording or storing keyframes.
In one aspect, the present invention relates to a method for recording and replaying server-generated data. According to one embodiment, the method includes the steps of storing a plurality of packets sent to a client device, rendering, by a protocol engine, at least one stored packet in the plurality of stored packets to a local video buffer and analyzing the at least one rendered packet with wherein analyzing includes at least scanning the at least one rendered packet with an optical character recognizer executing on the server. The method described herein also discloses using the optical character recognizer to generate a word associated with the at least one packet, using a post processing component to generate identification data associated with the generated word associated with the at least one packet, and storing the generated word associated with the at least one packet and storing the identification data associated with the generated word.
In another aspect, the present invention relates to a system for recording and replaying server-generated data includes a storage device configured to store, a plurality of packets sent to a client device, a protocol engine, configured to render at least one stored packet in the plurality of stored packets to a local video buffer and an optical character recognition device executing on the server configured to analyze the at least one rendered packet wherein analyzing includes at least scanning the at least one rendered packet to generate a word associated with the at least one packet. The system further includes a post processing component configured to generate identification data associated with the generated word associated with the at least one packet and a database configured to store the generated word associated with the at least one packet and also configured to store the identification data associated with the generated word.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other aspects of the invention will be readily apparent from the detailed description below and the appended drawings, which are meant to illustrate and not to limit the invention, and in which:
FIG. 1A is a block diagram depicting an embodiment of a network environment comprising client machines in communication with remote machines;
FIG. 1B and FIG. 1C are block diagrams depicting embodiments of computers useful in connection with the methods and systems described herein;
FIG. 2 is a block diagram depicting an embodiment of the network 200 in which the present invention may be performed;
FIG. 3 and FIG. 4 are block diagrams depicting alternate embodiments of placements for a recorder on the network 200;
FIG. 5 is a block diagram depicting one embodiment of a system for regenerating display data represented by a protocol data stream;
FIG. 6A is a flow diagram depicting a method for recording and replaying server-generated data;
FIG. 6B is a flow diagram depicting a method for retrieving specific server generated data;
FIG. 7 is a block diagram depicting in greater detail a recorder in a system for recording display data represented by a protocol data stream;
FIG. 8 depicts one embodiment of a recording of a protocol data stream;
FIG. 9 is a flow diagram depicting one embodiment of the steps taken in a method for real-time seeking during playback of stateful remote presentation protocols;
FIG. 10 is a flow diagram depicting one embodiment of the steps taken to generate state-snapshots enabling real-time seeking during playback of remote presentation protocols;
FIG. 11 is a block diagram depicting a system for real-time seeking during playback of stateful remote presentation protocols;
FIG. 12 is a flow diagram depicting one embodiment of steps taken for adaptive generation of state-snapshots;
FIG. 13 is a diagram depicting three types of seek probability distributions of one embodiment;
FIG. 14 is a diagram depicting one embodiment of generating state-snapshots responsive to a determined seek probability distribution;
FIG. 15 depicts one embodiment of a usage pattern for a user of a presentation of a protocol data stream;
FIG. 16 is a block diagram depicting one embodiment of a system for adaptive generation of state-snapshots, including a background protocol engine, a foreground protocol engine, a protocol data stream, an activity profile, and a state-snapshot;
FIG. 17 is a block diagram depicting one embodiment of a system for rendering a recorded session;
FIG. 18, a flow diagram depicts one embodiment of the steps taken to generate playback instructions for playback of a recorded computer session;
FIG. 19 is a flow diagram depicting one embodiment of the steps taken in a method for playback of a recorded computer session;
FIG. 20 is a flow diagram depicting one embodiment of the steps taken to generate playback instructions for rendering a recorded session;
FIG. 21 depicts one embodiment of a regenerated recorded stream whose contents are rendered responsive to a playback data structure;
FIG. 22 depicts one embodiment of certain packets in a recording stream having content representing meaningful user activity, in this embodiment a mouse input indicating an active mouse button state;
FIG. 23 is a flow diagram depicting one embodiment of the steps taken to eliminate periods with no meaningful activity in rendering a recorded session;
FIG. 24 is a flow diagram depicting one embodiment of the steps taken to eliminate a graphics update in rendering a recorded session;
FIG. 25 depicts one embodiment of rendering a regenerated recorded session responsive to whether the state of the screen region after a second graphics update varies from the state of the screen region after a first graphics update;
FIG. 26 is a flow diagram depicting one embodiment of the steps taken to eliminate interaction sequences in rendering a recorded session;
FIG. 27 is a flow diagram depicting one embodiment of the steps taken in automatic time-warped playback in rendering a recorded computer session;
FIG. 28 is a flow diagram depicting one embodiment of the steps taken for automatic time-warped playback responsive to an identified application in rendering a recorded computer session;
FIG. 29 is a block diagram depicting one embodiment of a system for automatic time-warped playback in rendering a recorded computer session;
FIG. 30A is a block diagram depicting one embodiment of a system for recording and real-time playback of a presentation protocol layer data stream;
FIGS. 30B, 30C and 30D are block diagrams depicting alternate embodiments of a system for recording and real-time playback of a presentation protocol layer data stream;
FIG. 31 is a flow diagram depicting one embodiment of the steps taken in a method for recording and real-time playback of a presentation protocol layer data stream;
FIG. 32 is a flow diagram depicting one embodiment of the steps taken in a method for real-time seeking during real-time playback of remote presentation layer protocol data;
FIG. 33 is a flow diagram depicting one embodiment of the steps taken in a method for generating state-snapshots enabling real-time seeking during real-time playback of a presentation layer protocol data stream; and
FIG. 34 is a flow diagram depicting one embodiment of the steps taken in a method for adaptive generation of state-snapshots.
DETAILED DESCRIPTION OF THE INVENTION
Methods and systems provide playback of recorded presentation layer protocol sessions capable of enhanced playback based on text or characters entered during the recorded presentation layer protocol sessions. In some embodiments, the technology builds on the methods and systems for recording and playback of presentation layer protocol sessions, which are also described herein.
Some embodiments of methods and playback of presentation layer protocol sessions provide functionality for playback after the completion of a recording and after creation of a recorded protocol data stream. In other embodiments, however, methods and systems provide functionality for playback of a protocol data stream during the recording of a protocol data stream. In one of these embodiments, the methods and systems also provide functionality for playback of a completed recording of a protocol data stream. In another of these embodiments, the methods and systems provide a range of playback controls, including, but not limited to the ability to watch a recording from the beginning, seek forward and backward, pause, fast forward, frame advance and so on. In some embodiments, optical character recognition can be used to recognize characters or text contained captured in the recording and the captured characters or texts can further be used to customize playback of the recording. In addition, the captured character or text can also be used in data analysis techniques such as determining which words are recorded most frequently across all or a subset of client devices. Data analysis may also include determining what characters or words are recorded at particular times.
In some embodiments, the methods and systems described herein provide for time-shifted playback (or time-shifting), a term borrowed from the video industry. Products called DVRs (Digital Video Recorders), such as the well-known TIVO brand, use time-shifting technology. These products provide consumers significant advantages over the traditional VCR; including the ability to start watching a recorded TV program before it is over. This benefit is also provided for users of the methods and systems described herein. Methods and systems for providing post-recording playback of presentation layer protocol data—functionality that was once a VCR for recorded presentation layer protocol data—may also provide playback during recording. This especially opens the system up to new use cases and new market opportunities. For embodiments in which the methods and systems are used for security purposes, the functionality greatly enhances the usability of these methods and systems as a surveillance and monitoring tool where response time to suspicious activity might be important. It is now possible to catch suspicious end users in the act of violating policies or other inappropriate use of computing or networking resources. Additionally, for embodiments in which the technology is used in a customer support scenario, the support technician now has the ability to watch exactly what the user did before they requested assistance and then instantly jump back “live” to watch what the user is about to do. This provides a significant opportunity in the support market as no existing session recording products provide this combined live and retrospective playback feature. Additional administrative benefits are provided since the methods and systems described herein have little, if any, impact on the performance, scalability, manageability or usability of the system.
In other embodiments, from an administrator perspective, the features provided by these methods and systems function in ways to similar to the ways in which the post-recording playback systems and methods described herein. In one of these embodiments, there are no additional installation or configuration options required to capture character or text elements of a recorded session. Recording policies and security features work as they do in the post-recording playback systems and methods.
Referring now to FIG. 1A, an embodiment of a network environment is depicted. In brief overview, the network environment comprises one or more clients 102 a-102 n (also generally referred to as local machine(s) 102, or client(s) 102) in communication with one or more servers 106 a-106 n (also generally referred to as server(s) 106, or remote machine(s) 106) via one or more networks 104.
Although FIG. 1A shows a network 104 between the clients 102 and the servers 106, the clients 102 and the servers 106 may be on the same network 104. The network 104 can be a local-area network (LAN), such as a company Intranet, a metropolitan area network (MAN), or a wide area network (WAN), such as the Internet or the World Wide Web. In some embodiments, there are multiple networks 104 between the clients 102 and the servers 106. In one of these embodiments, a network 104′ may be a private network and a network 104 may be a public network. In another of these embodiments, a network 104 may be a private network and a network 104′ a public network. In still another embodiment, networks 104 and 104′ may both be private networks.
The network 104 may be any type and/or form of network and may include any of the following: a point to point network, a broadcast network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an ATM (Asynchronous Transfer Mode) network, a SONET (Synchronous Optical Network) network, a SDH (Synchronous Digital Hierarchy) network, a wireless network and a wireline network. In some embodiments, the network 104 may comprise a wireless link, such as an infrared channel or satellite band. The topology of the network 104 may be a bus, star, or ring network topology. The network 104 and network topology may be of any such network or network topology as known to those ordinarily skilled in the art capable of supporting the operations described herein. The network may comprise mobile telephone networks utilizing any protocol or protocols used to communicate among mobile devices, including AMPS, TDMA, CDMA, GSM, GPRS or UMTS. In some embodiments, different types of data may be transmitted via different protocols. In other embodiments, the same types of data may be transmitted via different protocols.
In one embodiment, the system may include multiple, logically-grouped servers 106. In these embodiments, the logical group of servers may be referred to as a server farm 38. In some of these embodiments, the servers 106 may be geographically dispersed. In some cases, a farm 38 may be administered as a single entity. In other embodiments, the server farm 38 comprises a plurality of server farms 38. In one embodiment, the server farm executes one or more applications on behalf of one or more clients 102.
The servers 106 within each farm 38 can be heterogeneous. One or more of the servers 106 can operate according to one type of operating system platform (e.g., WINDOWS NT, Windows Server 2003, Windows Server 2008 or Windows 7, manufactured by Microsoft Corp. of Redmond, Wash.), while one or more of the other servers 106 can operate on according to another type of operating system platform (e.g., Unix or Linux). The servers 106 of each farm 38 do not need to be physically proximate to another server 106 in the same farm 38. Thus, the group of servers 106 logically grouped as a farm 38 may be interconnected using a wide-area network (WAN) connection or a metropolitan-area network (MAN) connection. For example, a farm 38 may include servers 106 physically located in different continents or different regions of a continent, country, state, city, campus, or room. Data transmission speeds between servers 106 in the farm 38 can be increased if the servers 106 are connected using a local-area network (LAN) connection or some form of direct connection.
Server 106 may be a file server, application server, web server, proxy server, appliance, network appliance, gateway, application gateway, gateway server, virtualization server, deployment server, SSL VPN server, or firewall. In some embodiments, a server 106 may have the capacity to function as either an application server or as a master application server. In one embodiment, a server 106 may include an Active Directory. The remote machine 106 may be an application acceleration appliance. For embodiments in which the remote machine 106 is an application acceleration appliance, the remote machine 106 may provide functionality including firewall functionality, application firewall functionality, or load balancing functionality. In some embodiments, the remote machine 106 comprises an appliance such as one of the line of appliances manufactured by the Citrix Application Networking Group, of San Jose, Calif., or Silver Peak Systems, Inc., of Mountain View, Calif., or of Riverbed Technology, Inc., of San Francisco, Calif., or of F5 Networks, Inc., of Seattle, Wash., or of Juniper Networks, Inc., of Sunnyvale, Calif.
The clients 102 may also be referred to as client nodes, client machines, endpoint nodes, or endpoints. In some embodiments, a client 102 has the capacity to function as both a client node seeking access to resources provided by a server and as a server providing access to hosted resources for other clients 102 a-102 n.
In some embodiments, the server 106 or a server farm 38 may be running one or more applications, such as an application providing a thin-client computing or remote display presentation application. In one embodiment, the server 106 or server farm 38 executes as an application, any portion of the Citrix Access Suite™ by Citrix Systems, Inc., such as the XenDesktop and/or any of the MICROSOFT WINDOWS Remote Desktop Services manufactured by the Microsoft Corporation. In another embodiment, the application includes a Remote Desktop (RDP) client, developed by Microsoft Corporation of Redmond, Wash., or an X11 client, maintained by the open source X.org Foundation. In still another embodiment, the server 106 may run an application, which for example, may be an application server providing email services such as MICROSOFT EXCHANGE manufactured by the Microsoft Corporation of Redmond, Wash., a web or Internet server, or a desktop sharing server, or a collaboration server. In yet another embodiment, any of the applications may comprise any type of hosted service or products, such as GOTOMEETING provided by Citrix Online Division, Inc. of Santa Barbara, Calif., WEBEX provided by WebEx, Inc. of Santa Clara, Calif., or Microsoft Office LIVE MEETING provided by Microsoft Corporation of Redmond, Wash.
A client 102 may execute, operate or otherwise provide an application, which can be any type and/or form of software, program, or executable instructions such as any type and/or form of web browser, web-based client, client-server application, a thin-client computing client, an ActiveX control, or a Java applet, or any other type and/or form of executable instructions capable of executing on client 102. In some embodiments, the application may be a server-based or a remote-based application executed on behalf of the client 102 on a server 106. In one embodiment, the server 106 may display output to the client 102 using any thin-client or remote-display protocol, such as the Independent Computing Architecture (ICA) protocol manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla. or the Remote Desktop Protocol (RDP) manufactured by the Microsoft Corporation of Redmond, Wash. The application can use any type of protocol and it can be, for example, an HTTP client, an FTP client, an Oscar client, or a Telnet client. In other embodiments, the application comprises any type of software related to voice over internet protocol (VoIP) communications, such as a soft IP telephone. In further embodiments, the application comprises any application related to real-time data communications, such as applications for streaming video and/or audio.
The client 102 and server 106 may be deployed as and/or executed on any type and form of computing device, such as a computer, network device or appliance capable of communicating on any type and form of network and performing the operations described herein. FIGS. 1B and 1C depict block diagrams of a computing device 100 useful for practicing an embodiment of the client 102 or a server 106. As shown in FIGS. 1B and 1C, each computing device 100 includes a central processing unit 121, and a main memory unit 122. As shown in FIG. 1B, a computing device 100 may include a visual display device 124, a keyboard 126 and/or a pointing device 127, such as a mouse. As shown in FIG. 1C, each computing device 100 may also include additional optional elements, such as one or more input/output devices 130 a-130 b (generally referred to using reference numeral 130), and a cache memory 140 in communication with the central processing unit 121.
The central processing unit 121 is any logic circuitry that responds to and processes instructions fetched from the main memory unit 122. In many embodiments, the central processing unit is provided by a microprocessor unit, such as: those manufactured by Intel Corporation of Mountain View, Calif.; those manufactured by Motorola Corporation of Schaumburg, Ill.; those manufactured by Transmeta Corporation of Santa Clara, Calif.; the RS/6000 processor, those manufactured by International Business Machines of White Plains, N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale, Calif. The computing device 100 may be based on any of these processors, or any other processor capable of operating as described herein.
Main memory unit 122 may be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor 121, such as Static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM). The main memory 122 may be based on any of the above described memory chips, or any other available memory chips capable of operating as described herein. In the embodiment shown in FIG. 1B, the processor 121 communicates with main memory 122 via a system bus 150 (described in more detail below). FIG. 1B depicts an embodiment of a computing device 100 in which the processor communicates directly with main memory 122 via a memory port 103. For example, in FIG. 1B the main memory 122 may be DRDRAM.
FIG. 1C depicts an embodiment in which the main processor 121 communicates directly with cache memory 140 via a secondary bus, sometimes referred to as a backside bus. In other embodiments, the main processor 121 communicates with cache memory 140 using the system bus 150. Cache memory 140 typically has a faster response time than main memory 122 and is typically provided by SRAM, BSRAM, or EDRAM. In the embodiment shown in FIG. 1C, the processor 121 communicates with various I/O devices 130 via a local system bus 150. Various buses may be used to connect the central processing unit 121 to any of the I/O devices 130, including a VESA VL bus, an ISA bus, an EISA bus, a MicroChannel Architecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or a NuBus. For embodiments in which the I/O device is a video display 124, the processor 121 may use an Advanced Graphics Port (AGP) to communicate with the display 124. FIG. 1C depicts an embodiment of a computer 100 in which the main processor 121 communicates directly with I/O device 130 b via HyperTransport, Rapid I/O, or InfiniBand. FIG. 1C also depicts an embodiment in which local busses and direct communication are mixed: the processor 121 communicates with I/O device 130 a using a local interconnect bus while communicating with I/O device 130 b directly.
The computing device 100 may support any suitable installation device 116, such as a floppy disk drive for receiving floppy disks such as 3.5-inch, 5.25-inch disks or ZIP disks, a CD-ROM drive, a CD-R/RW drive, a DVD-ROM drive, tape drives of various formats, USB device, hard-drive or any other device suitable for installing software and programs such as any client agent 120, or portion thereof. The computing device 100 may further comprise a storage device 128, such as one or more hard disk drives or redundant arrays of independent disks, for storing an operating system and other related software, and for storing application software programs such as any program related to the client agent 120. Optionally, any of the installation devices 116 could also be used as the storage device. Additionally, the operating system and the software can be run from a bootable medium, for example, a bootable CD, such as KNOPPIX®, a bootable CD for GNU/Linux that is available as a GNU/Linux distribution from knoppix.net.
Furthermore, the computing device 100 may include a network interface 118 to interface to a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25), broadband connections (e.g., ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above. The network interface 118 may comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device 100 to any type of network capable of communication and performing the operations described herein.
A wide variety of I/O devices 130 a-130 n may be present in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, and dye-sublimation printers. The I/O devices may be controlled by an I/O controller 123 as shown in FIG. 1B. The I/O controller may control one or more I/O devices such as a keyboard 126 and a pointing device 127, e.g., a mouse or optical pen. Furthermore, an I/O device may also provide storage and/or an installation medium 116 for the computing device 100. In still other embodiments, the computing device 100 may provide USB connections to receive handheld USB storage devices such as the USB Flash Drive line of devices manufactured by Twintech Industry, Inc. of Los Alamitos, Calif.
In some embodiments, the computing device 100 may comprise or be connected to multiple display devices 124 a-124 n, which each may be of the same or different type and/or form. As such, any of the I/O devices 130 a-130 n and/or the I/O controller 123 may comprise any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable or provide for the connection and use of multiple display devices 124 a-124 n by the computing device 100. For example, the computing device 100 may include any type and/or form of video adapter, video card, driver, and/or library to interface, communicate, connect or otherwise use the display devices 124 a-124 n. In one embodiment, a video adapter may comprise multiple connectors to interface to multiple display devices 124 a-124 n. In other embodiments, the computing device 100 may include multiple video adapters, with each video adapter connected to one or more of the display devices 124 a-124 n. In some embodiments, any portion of the operating system of the computing device 100 may be configured for using multiple displays 124 a-124 n. In other embodiments, one or more of the display devices 124 a-124 n may be provided by one or more other computing devices, such as computing devices 100 a and 100 b connected to the computing device 100, for example, via a network. These embodiments may include any type of software designed and constructed to use another computer's display device as a second display device 124 a for the computing device 100. One ordinarily skilled in the art will recognize and appreciate the various ways and embodiments that a computing device 100 may be configured to have multiple display devices 124 a-124 n.
In further embodiments, an I/O device 130 may be a bridge 170 between the system bus 150 and an external communication bus, such as a USB bus, an Apple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a Super HIPPI bus, a SerialPlus bus, a SCI/LAMP bus, a FibreChannel bus, or a Serial Attached small computer system interface bus.
A computing device 100 of the sort depicted in FIGS. 1B and 1C typically operates under the control of operating systems, which control scheduling of tasks and access to system resources. The computing device 100 can be running any operating system such as any of the versions of the MICROSOFT WINDOWS operating systems, the different releases of the Unix and Linux operating systems, any version of the MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described herein. Typical operating systems include: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, Windows Server 2003, Windows Server 2008, Windows 7 and WINDOWS XP, all of which are manufactured by Microsoft Corporation of Redmond, Wash.; MAC OS, manufactured by Apple Computer of Cupertino, Calif.; OS/2, manufactured by International Business Machines of Armonk, N.Y.; and Linux, a freely-available operating system distributed by Caldera Corp. of Salt Lake City, Utah, or any type and/or form of a Unix operating system, among others.
In some embodiments, the computing device 100 may have different processors, operating systems, and input devices consistent with the device. For example, in one embodiment the computing device 100 is a Treo 180, 270, 600, 650, 680, 700p or 700w smart phone manufactured by Palm, Inc. In some of these embodiments, the Treo smart phone is operated under the control of the PalmOS operating system and includes a stylus input device as well as a five-way navigator device.
In other embodiments the computing device 100 is a mobile device, such as a JAVA-enabled cellular telephone or personal digital assistant (PDA), such as the i55sr, i58sr, i85s, i88s, i90c, i95cl, or the im11000, all of which are manufactured by Motorola Corp. of Schaumburg, Ill., the 6035 or the 7135, manufactured by Kyocera of Kyoto, Japan, or the i300 or i330, manufactured by Samsung Electronics Co., Ltd., of Seoul, Korea. In still other embodiments, the computing device 100 is a Blackberry handheld or smart phone, such as the devices manufactured by Research In Motion Limited, including the Blackberry 7100 series, 8700 series, 7700 series, 7200 series, the Blackberry 7520, or the Blackberry Pearl 8100. In yet other embodiments, the computing device 100 is a smart phone, Pocket PC, Pocket PC Phone, or other handheld mobile device supporting Microsoft Windows Mobile Software. Moreover, the computing device 100 can be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile telephone, any other computer, or other form of computing or telecommunications device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described herein.
Referring now to FIG. 2, a block diagram depicts an embodiment of the network 200 in which the invention may be performed, including a first device 202, a remote presentation protocol server engine 204, a recorder 206, a protocol data stream 208, a recorded protocol data stream 210, a second device 212, a remote presentation protocol client engine 214, a display 216, a storage element 218, and a recorded protocol data stream 220. The first device 202, may be a server device, for example, and the second device 212 may be a client device, for example. In brief overview, the recorder 206 intercepts a protocol data stream 224 transmitted from the second device 212. In one exemplary embodiment, the intercepted protocol data stream 224 comprises a recorded client session which may include data associated with user input data. The recorded client session may also include display data, such as pixel data, used to show information to a user at display 216. In addition, the protocol data stream 224 may comprise a virtual channel such as a virtual channel supporting thinwire data packets. The recorder 206, then copies at least one packet from the protocol data stream 224 and creates a recording of the protocol data stream 224 using the at least one copied packet at recorder 206 according to one embodiment.
According to one embodiment, protocol data stream 222 delivers a computer program funning on first device 202 and being displayed remotely on display 216 for a user. The user may interact with the computer program with I/O device 144. These user interactions such as mouse movements, keyboard screen updates and other display data may be transmitted back to the first device 202 and recorded at recorder 206.
Referring now to FIG. 2 and in more detail, a first device 202 transmits a protocol data stream 208 to a second device 212. In one embodiment, the first device 202 uses a remote presentation protocol server engine 204 to transmit the protocol data stream 208 to the second device 212. In some embodiments, the second device 212 uses a remote presentation protocol client engine 214 to receive the protocol data stream 208 from the first device 202. In some embodiments, the remote presentation protocols comprise a thin-client protocol such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash.
The protocol data stream 208 comprises a plurality of packets at least some of which represent display data. The packets may comprise data packets transmitted on a thinwire virtual channel according to one exemplary embodiment. In some embodiments, the protocol data stream 208 comprises information about a recorded session. In one embodiment, the protocol data stream 208 comprises metadata. In another embodiment, the protocol data stream 208 comprises information about the user in a recorded session. In still another embodiment, the protocol data stream 208 comprises information about the server generating the recorded data. In yet another embodiment, the protocol data stream 208 comprises a timestamp. In one embodiment, the display data includes pixel data corresponding to text or characters captured during a recorded session.
In one embodiment, the protocol data stream 208 comprises multiple channels, such as virtual channels including a thinwire virtual channel, for example. In this embodiment, a channel comprises a peer-to-peer connection over which data is transferred. In another embodiment, the protocol data stream 208 comprises multiple virtual channels. The second device 212 receives the protocol data stream 224 and, in some embodiments, uses a remote presentation protocol client engine 214 to display data sent from second device 212 on a display 216. Processing the protocol data stream 224 allows the second device 212 to present a display to a user through display 216.
According to one embodiment, first device 202 transmits a computer application to be displayed on display 216 for interaction with a user. The user may interact with the protocol data stream 222 shown on display 216 with input/output (I/O) device 144. The I/O device 144 may be connected as shown by elements 123, 130 a, or 130 b in FIGS. 1B and 1C. The I/O device 144 may be a keyboard, mouse, touch screen, wireless device, or any other device capable of detecting user input. The second device 212 may use the remote presentation protocol client engine 214 to process the display data. The display includes, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these.
The recorder 206 intercepts the protocol data stream 224 sent from the first device 202, server, to the second device 212, such as a client device according to one exemplary embodiment. The protocol data stream 224 may include display data including associated with a computer application or text displayed in response to a user input, for example. Some examples of text included in display data may include text in application window titles, text in start menu items, text in desktop shortcut names, text in documents opened by a user, text displayed while browsing the internet using an internet browser application, or text that appears in videos that are rendered and displayed, for example. In addition, text copied and pasted through a clipboard functionality by a user can also be recorded according to one embodiment. Furthermore, text entered into password windows is not recorded since the display data interprets password information as * characters according to one exemplary embodiment. User initiated editing to text such as deleting, entering spaces, or using mouse commands can also be recorded.
In another embodiment, the recorder 206 intercepts one or more channels of the protocol data stream 224. In another embodiment, the recorder 206 intercepts the protocol data stream 224 by intercepting one or more virtual channels such as a thinwire virtual channel. In some embodiments, the recorder 206 monitors one or more virtual channels over which the first device 202 may transmit the protocol data stream 224 to the second device 212. The recorder 206 copies at least one packet from the protocol data stream. In one embodiment, the recorder 206 determines to copy a particular packet of the protocol data stream responsive to a policy. In some embodiments, the policy defines the packets the recorder 206 records based upon the type of data contained within the packet. In other embodiments, the recorder 206 determines to copy a packet of the protocol data stream based upon a determination of whether the packet contains data. In some of these embodiments, the recorder 206 does not record empty packets while in others of these embodiments, the recorder 206 does record empty packets. In some embodiments, the recorder 206 records every packet in the protocol data stream 224.
The recorder 206 creates a recorded protocol data stream 210 using the at least one copied packet. In one embodiment, the recorder 206 associates information with the at least one copied packet. In one embodiment, the recorder 206 associates a time stamp with the at least one copied packet. In another embodiment, the recorder 206 associates a data length indicator with the packet. For embodiments where the recorder 206 associates information with the at least one copied packet, for example time stamps or data length indicator, the recorder 206 may embed this information into the recorded protocol data stream 210 in addition to the packet or the recorder 206 may embed this information directly into the packet, or the recorder 206 may store the association in a location separate from the packet and the recorded protocol data stream 210.
As depicted in FIG. 2, the recorder 206 may reside on the first device 202. However, the location of the recorder may reside in any number of locations or devices. FIG. 3 depicts an embodiment in which the recorder 206 resides on the second device, 212. FIG. 4 depicts an embodiment in which the recorder 206 resides on a third device 222. The devices on which the recorder 206 may reside include client computing systems, server computing systems, proxy server computing systems, network packet sniffing computing systems, protocol analyzer computing systems, and passthrough server computing systems.
Referring to FIGS. 2-4, the recorder 206 creates the recorded protocol data stream 210 by copying at least one packet and, in some embodiments, information associated with the at least one packet. In some embodiments, the recorder 206 stores the recording of the protocol data stream 210 after creating it. In some of these embodiments, the recorder 206 stores the recording of the protocol data stream 210 to a storage element 218. The storage element 218 may comprise persistent storage, such as a hard drive, floppy drive, CD-RW, DVD-RW, or any other device, which maintains data state when power is removed. In other embodiments, the storage element may comprise one or more volatile memory elements, such as Static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM).
In one embodiment the storage element 218 comprises a network storage device. The storage element 218 may reside on the first device 202 or on a second device 212. In other embodiments, the storage element 218 resides on a third device, such as a proxy server computing device or a pass through server computing device. In still other embodiments, the storage element 218 resides on a network and the recorder 206 accesses the storage element 218 over the network to store the recording of the protocol data stream 220. In other embodiments, the recorder 206 stores the recording of the protocol data stream on the same device on which the recorder 206 resides.
Referring now to FIG. 5, a block diagram depicts a protocol engine 502 reading at least one copied packet from the recording of the protocol data stream 506 and using the information associated with the at least one copied packet to regenerate the display data represented by the protocol data stream 506. The protocol engine 502 receives the protocol data stream 506. In some embodiments, the protocol engine 502 retrieves the protocol data stream 506 from a storage element 518. In other embodiments, the protocol engine 502 retrieves the protocol data stream 506 from a recorder 206. In still other embodiments, the protocol engine 502 retrieves the protocol data stream 506 from another computing device.
In some embodiments, the protocol engine 502 comprises a packet reader 508 and a display data regeneration element 510. Display data regeneration element 510 may include an OCR library 520, storage device 524, search engine 526 and video player 528 according to one exemplary embodiment. In these embodiments, the packet reader 508 reads at least one copied packet from the recording of the protocol data stream 506. In some embodiments, the packet reader 508 reads the at least one copied packet sequentially from the recording of the protocol data stream 506.
The protocol engine 502 processes the at least one copied packet and any information associated with the at least one copied packet. The protocol engine 502 may render the contents of the at least one copied packet and output the rendered packets to a video buffer element 512, in one exemplary embodiment. In another specific embodiment, protocol engine 502 renders an ICA packet or other virtual channel packets such as thinwire packets stored in an ICL file format. In such an embodiment, the ICL packets are converted from an ICL file format into a local video buffer file format using existing thinwire player technology. In another embodiment, processing includes rendering in a perceptible manner the contents of the at least one copied packet. The regenerated display may include, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these. In some embodiments, the protocol engine 502 resides on the first device 202. In other embodiments, the protocol engine 502 resides on the second device 212. In still other embodiments the protocol engine resides on a third device, such as a proxy server computing device or a pass through server computing device.
Once the packets from protocol data stream 506 have been read, rendered and submitted to video buffer 512, the local video buffer (LVB) files 540 corresponding to protocol data stream packets 506 are analyzed by a post recording software program that may be stored in memory at playback device 514. In some embodiments, the post recording software program implements an optical character recognition library (OCR) 520. At OCR 520, the LVB files are scanned by an post recording software program to generate characters or words. The post recording software program can be any of several suitable OCR software programs including but not limited to open source OCR libraries such as Tesseract of Google OCRopus. The OCR libraries may be able to recognize English text, non-English text or a combination of both. Embodiments capable of generating words in multiple languages may be facilitated by capturing, storing and cataloging characters by representing them in the Unicode Standard, which represents text from different languages in a universal character set.
In addition to generating words, the OCR library may provide identification data such as spatial correspondence data indicating the spatial coordinates of the word with respect to a video frame the word is contained in. The spatial correspondence data may be determined from bounding rectangle information such as position, width and height of the word in the recorded session. Furthermore, the generated words 522 are also associated with other identification data such as timing data according to one exemplary embodiment. The timing data may indicate when the generated word appeared in a sequential order of video frames as well as when the generated word ceased to appear in a subsequent video frame. In addition, the generated words 522 are also associated with still other identification data such as particular recording file identifiers. The recording file identifiers could be used in data analysis such as determining which words are recorded most frequently across all or a subset of client devices. Data analysis may also include determining what characters or words are recorded at particular times.
Once the generated words along with identification data are stored in storage 524, the generated words and identification data can be searched by search engine 526. A user such as an administrator may desire to play back a recorded session from a client device captured by recorder 206 using video player device 528. However, the user may wish to play back only certain portions of the recorded session, such as portions of the recorded session that contains display data that includes specific words or target words. If the user desires to only see portions of the recorded session that includes a single target words or multiple target words, those words can be entered into video player 528 through an I/O device 144.
In an alternative embodiment, video playback device 528 may automatically scan for target words without user input. Once a target word is selected at video playback device 528, search engine 526 selects the target words and data associated with the target words from storage device 528, according to one exemplary embodiment. Data associated with the target words may include video frames or data packets. Once these video frames or data packets are determined, video playback device may selectively display the video frames or data packets at display 530 such that a user may view the frames associated with target words consecutively rather than viewing the sequence of video frames in the sequence recorded in the recorded session.
Additionally, video player 528 may also perform various post-processing functions on the video frames or data packets which are associated with targeted words. In one embodiment, the video player 528 may be commanded to highlight target words within each displayed video frame using the bounding rectangle information such as position, width and height according to user input through I/O device 144. The video player may highlight the words by graphically overlaying highlights over the words of interest or by manipulating the color of pixel data surrounding the target words, for example.
Referring ahead now to FIG. 7, a block diagram depicts in greater detail the recorder 702, originally described as recorder 206 in FIG. 2. In brief overview, the recorder 702 records server-generated data through interception of a protocol data stream 710 and through the creation of a recording 712 of the protocol data stream 710.
The recorder 702 includes, in one embodiment, a protocol data stream interceptor 704, a packet copier 706, and a recording generator 708. In one embodiment, the recorder 702 uses the protocol data stream interceptor 704 to monitor the protocol data stream 710. In another embodiment, the recorder 702 uses the protocol data stream interceptor 702 to intercept a protocol data stream 710 comprising a plurality of packets transmitted from a first device 202 to a second device 212. The packet copier 706 copies at least one packet of the protocol data stream. The packet copier 706 determines whether or not to copy a packet in the protocol data stream. In some embodiments, the packet copier 706 makes this determination responsive to a policy. In these embodiments, the packet copier 706 may determine to copy a packet based on whether or not the packet contains any data or on the type of data contained within the packet.
In one embodiment, the recorder 702 utilizes a recording generator 708 to create a recording of the protocol data stream using the at least one copied packet. The recording generator assembles the at least one copied packet into a recording 712 of the protocol data stream 710. In some embodiments, the recording generator 708 embeds information into the recording of the protocol data stream. This information may comprise, without limitation, time references indicating when to regenerate the display data represented by the data contained within the packet, data length indicators descriptive of the data contained within the packet, or other types of information used to regenerate the display data represented by the data contained within the protocol data stream 710.
FIG. 8 depicts one embodiment of the recording 712 of the protocol data stream 710. In the embodiment shown 800, the recording generator 708 has grouped at least one copied packet into remote presentation protocol data chunks. The recording generator 708 associated a time reference and a data length with each remote presentation protocol data chunk and assembled the information and the packets together into the recording 712 of the protocol data stream 710.
Referring back to FIG. 7, in one embodiment, the recorder 702 stores the completed recording 712 of the protocol data stream 710 to a storage element 714. In some embodiments, the storage element is located on a network and the recorder 702 transmits the recording 712 over a network to the storage element 714. In other embodiments, the storage element is located on a proxy server computing device. In still other embodiments, the storage element is located on a passthrough server computing device. In some embodiments, the storage element 714 resides on the same device as the recorder 702.
In one embodiment, depicted in shadow by FIG. 7, a system for recording and playback of a protocol data stream comprises the recorder 702 as well as the playback device 514 discussed in FIG. 5. The playback device 514 includes the protocol engine 502, which uses the packet reader 508 to receive and read at least one copied packet from the recording 712 of the packet data stream and uses the embedded information to regenerate the display data represented by the recording 712 of the protocol data stream. In some embodiments, the protocol engine 502 reads the packets sequentially in regenerating the display data.
In another embodiment depicted by FIG. 7, a system for recording and replaying server-generated data comprises a recorder 702, a storage element 714, and a protocol engine 502. The recorder 702 generates a recording of a protocol data stream and stores the recording 712 in the storage element 714. The recorder copies at least one packet from the protocol data stream and associates information with the at least one packet, including but not limited to a time reference or a data length indicator describing a length of data in the packet. The protocol engine 502, in communication with the storage element 714, reads at least one packet from the recording of the protocol data stream and uses information associated with the at least one packet to regenerate the display data represented by the recording 712 of the protocol data stream 710.
In one embodiment, the recorder 702, protocol engine 502, or storage element 714 may be located, together or separately on the first device 202. In other embodiments, they may be located, together or separately, on the second device 212. In still other embodiments, they may reside, together or separately, on a third device, such as a proxy server computing device, a network packet sniffer, or a passthrough server computing device. In yet other embodiments, the storage element 714 may reside on a storage area network separately from the recorder 702 and the protocol engine 502.
Referring now to FIG. 6A, a flow diagram summarizes a method for recording and replaying server-generated data. In brief overview, at step 602, a recorder 206 intercepts a protocol data stream comprising a plurality of packets that are being transmitted, are going to be transmitted or have been transmitted from a second device, such as a client device, to a first device such as a server device. At step 604, the recorder 206 copies at least one packet from the protocol data stream 224 and creates a recording of the protocol data stream 224 at step 606. Protocol engine 502 later uses this recorded protocol data stream 210 to be played back for a user such as an administrator at a playback device 514 as shown in FIG. 5 as stated in steps 610-616 in FIG. 6A.
At step 610, the previously recorded protocol data stream 210 or 220 is received at a packet reader 508 within protocol engine 502. The previously recorded protocol data stream may be in proximity to the device of initial recording 202 or may have been transmitted to another storage location 218 as shown in FIG. 2. In either case, once packet data from at least one packet has been read at packet reader 508, the packet data files are rendered and sent to local video buffer 512 by protocol engine 502 in step 610. Subsequently, in step 612, the rendered packet data is analyzed by a post recording software program with an optical character recognition library (OCR) 520. At OCR 520, the LVB files are scanned by an OCR software program to generate characters or words. The OCR software program can be any of several suitable OCR software programs including but not limited to open source OCR libraries such as Tesseract of Google OCRopus. The OCR libraries may be able to recognize English text, non-English text or a combination of both. Embodiments capable of generating words in multiple languages may be facilitated by capturing, storing and cataloging characters by representing them in the Unicode Standard, which represents text from different languages in a universal character set.
Prior to being sent to storage 514, the characters or words generated at step 612 may optionally be processed to be converted to an optimal file format for storage at step 614. Post processing at step 614 may also create an association between the identification data or other additional packet data and a generated word prior to storing the generated word and additional packet data in storage device 524 so that when a stored word is searched by search engine 526, the generated word as well as identification data may be uploaded to video player 528. The identification data may include spatial correspondence data such as the spatial coordinates of the word with respect to a video frame, bounding rectangle information such as position, width and height of the word, and timing data indicating when the generated word appeared in a sequential order of video frames or when the generated word ceased to appear in a subsequent video frame or a calculated duration of how long the word or character appeared in the recorded display data. Timing data may be derived from the “Time Ref.” bit shown in the protocol data packet shown in FIG. 8, according to one embodiment. This post processing may occur at the OCR library 520 or may alternatively occur at a separate module at playback device 514. Once the generated word and any associated packet data have been converted to a proper format at steps 612 and 614, the generated word and any associated packet data is stored in step 616 at storage element 524.
The process shown in FIG. 6B may occur after the process depicted in 6A has been completed according to one exemplary embodiment. FIG. 6B depicts a process for a user such as an administrator for real-time seeking during playback of stateful remote presentation protocols using target words. In brief overview, there is a request for rendering of recorded display data represented by the contents of a packet in a recording of a protocol data stream at step 620. Step 620 may include a user entering a target word at I/O device 144 which is used by search engine 526 to query the contents of storage 524 for a match with the target word. Search engine 526 may comprise a known look up table mechanism, a more sophisticated searching algorithm or any other searching mechanism known in the art. Once a target word and associated data such as timing data are found, the video playback device 528 regenerates display data by rendering the contents of a packet in the recording of a protocol data stream 506 that correspond to the target word to a viewer using the display 530 at steps 622 and 624 of FIG. 6. Once display data associated with the target word is sent to video playback device 528 at step 624, the display data associated with the selected target word may be played at display 530 for a user such as an administrator.
Furthermore, prior to, during, or after display data associated with the selected target word is played at display 530, the display data sent to display 530 may optionally be manipulated automatically or manually by user input via I/O device 144 at step 628. In one embodiment, the video player 528 may be commanded to highlight the target words within each displayed video frame using the bounding rectangle information such as position, width and height according to user input through I/O device 144. The video player may highlight the words by graphically overlaying highlights over the words of interest or by manipulating the color of pixel data surrounding the target words according to one example.
Referring ahead to FIG. 11, a block diagram depicts a system for real-time seeking during playback of stateful remote presentation protocols 1100. In brief overview, this figure depicts an embodiment of a playback device 514 (see FIG. 5 above) comprising two protocol engines 502, a background protocol engine 1102 and a foreground protocol engine 1106, as well as a state-snapshot 1104 and a display 1108. The background protocol engine 1102 receives a recording of a protocol data stream 1110 and reads the recording of the protocol data stream 1110, which comprises a plurality of packets and represents display data. In one embodiment, the playback device 514 regenerates the display data by rendering the contents of at least one packet in the protocol data stream 1110 and displaying the results using the display 1108. The results include, without limitation, perceptible audio, visual, tactile, or olfactory presentations.
Referring now to FIG. 11, and in greater detail, the background protocol engine 1102 enables a recipient of the rendered display data to seek for content in real-time during the presentation of a protocol data stream 1110. The background protocol engine 1102 generates at least one state-snapshot 1104 while reading at least one packet from the protocol data stream 1110. In one embodiment, the background protocol engine 1102 renders the contents of the at least one packet to a buffer. In this embodiment, the buffer may comprise an off-screen buffer. In this embodiment, the background protocol engine 1102 generates at least one state-snapshot 1104 as it renders the contents of the at least one packet. The background protocol engine 1102 makes the state-snapshot 1104 available to the foreground protocol engine 1106.
The state-snapshot 1104 enables regeneration of display data because it stores a state of a protocol engine rendering the protocol data stream 1110 at a point in time when a recorder 206 copied at least one packet from the protocol data stream 208 into the recording of the protocol data stream 1110. In one embodiment, the state-snapshot 1104 comprises a data structure describing a state of a screen at a point in time. In another embodiment, the state-snapshot 1104 represents all the variables, images and data components that make up the state of a protocol engine at a reference point in the protocol data stream 1110. The foreground protocol engine 1106 also receives the recording of the protocol data stream 1110 and renders the contents of the at least one packet in the protocol data stream 1110 by recreating the state of the protocol engine which originally rendered the protocol data stream 1110. In one embodiment, the foreground protocol engine 1106 uses the contents of the state-snapshot 1104 to render the contents of the at least one packet.
In one embodiment, the state-snapshot 1104 comprises a data structure. In other embodiments, the state-snapshot 1104 comprises a database. In one embodiment, the contents of the state-snapshot 1104 include display data regarding the state of a visible surface. In another embodiment, the contents of the state-snapshot 1104 include display data regarding the state of an off-screen surface. In yet another embodiment, the contents of the state-snapshot 1104 include display data regarding the state of a drawing object. In some embodiments, the contents of the state-snapshot 1104 include display data regarding the state of a color palette. In other embodiments, the contents of the state-snapshot 1104 include display data regarding the state of a cached object. In still other embodiments, the contents of the state-snapshot 1104 include display data regarding the state of a buffer.
The foreground protocol engine 1106 receives the recording of the protocol data stream 1110 and uses the state-snapshot 1104 to identify a packet containing the representation of the requested digital data and to render the packet. In some embodiments, the foreground protocol engine 1106 generates a real-time perceptible representation of the recording of the protocol data stream 1110 for presentation to a viewer using the display 1108. In some embodiments, the foreground protocol engine 1106 generates the real-time perceptible representation by rendering the contents of at least one packet in the protocol data stream 1110. The perceptible representation may include, without limitation, separately or together, audio, visual, tactile, or olfactory presentations.
In one of the embodiments in which the foreground protocol engine 1106 renders the contents of at least one packet in the protocol data stream 1110, the foreground protocol engine 1106 initiates rendering the contents of at least one packet in the protocol data stream 1110 simultaneous to the rendering by the background protocol engine 1102. However the background protocol engine 1102 renders only to a buffer and completes the rendering and the generation of the at least one state-snapshot 1104 prior to the completion of the real-time perceptible rendering initiated by the foreground protocol engine 1106, which, in one embodiment, renders to both a buffer and in a perceptible manner. In one embodiment, the background protocol engine 1102 renders the protocol data stream 1110 at a maximum possible speed regardless of any timestamps associated with the recording which would otherwise specify a time for rendering. Therefore, at least one state-snapshot 1104 is available to the foreground protocol engine 1106 during its generation of a real-time perceptible representation of the recording of the protocol data stream 1110.
In one embodiment, the foreground protocol engine 1106 renders the contents of the plurality of packets within the recording of the protocol data stream 1110 in a sequential manner. In this embodiment, the display data rendered and presented to the user presents the display in the order in which it occurred at the time the protocol data stream was recorded. The recording of the protocol data stream 1110 may include information, such as time stamps, for use by the foreground protocol engine 1106 in rendering the display data sequentially. In some embodiments, the foreground protocol engine 1106 renders the display data in real-time. When the foreground protocol engine 1106 receives a request to regenerate a particular display data represented by a particular packet in the recording of the protocol data stream 1110, the foreground protocol engine 1106 renders the requested display data using the contents of the identified state-snapshot 1104.
In some embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on the same device. In other embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on separate devices.
Referring back now to FIG. 9, a flow diagram depicts one embodiment of the steps taken in a method for real-time seeking during playback of stateful remote presentation protocols. In brief overview, there is a request for rendering of data display represented by the contents of a packet in a recording of a protocol data stream (step 902). The contents of the appropriate packet are rendered by first identifying a state-snapshot having an associated timestamp not later than a timestamp associated with the requested packet (step 904) and rendering the requested contents responsive to the identified state-snapshot (step 906).
In one embodiment, the foreground protocol engine 1106 receives a request to render the contents of a packet in a recording of a protocol data stream 1110. The protocol data stream 1110 comprises a plurality of packets whose contents represent display data. In some embodiments, the request results when the foreground protocol engine 1106 regenerates display data by rendering the contents of a packet in a recording of a protocol data stream 1110 to a viewer using the display 1108 and the viewer wishes to seek for a particular display data.
The foreground protocol engine 1106 identifies a state-snapshot 1104 having an associated timestamp not later than a time stamp associated with the requested packet. The foreground protocol engine 1106 displays the display data represented by the contents of the requested packet responsive to the identified state-snapshot 1104. In one embodiment, the identified state-snapshot 1104 indicates the exact packet from the protocol data stream 1110 whose contents the foreground protocol engine 1106 may render to provide the user with the requested display data.
In other embodiments, the identified state-snapshot 1104 comprises a state of a protocol engine rendering the protocol data stream at a point in time when a recorder copied a packet from the protocol data stream 1110 but the display data represented by the contents of the copied packet precede the display data requested by the viewer. In some of these embodiments, there are multiple packets between the state-snapshot and the packet containing the representation of the requested display data. In some of those embodiments, the foreground protocol engine 1106 renders the contents of the intermediate packet or packets only to an off-screen buffer. The foreground protocol engine 1106 then renders the packet whose contents represent the display data both to an off-screen buffer and to the user in a perceptible manner. In one embodiment, the foreground protocol engine 1106 presents the display data represented by the contents of the intermediate packets in a perceptible manner prior to the display data represented by the contents of the requested packet.
Referring now to FIG. 10, a flow diagram depicts one embodiment of the steps taken to generate state-snapshots enabling real-time seeking during playback of remote presentation protocols. In brief overview, the background protocol engine 1102 receives a recording of a protocol data stream 1110 and while regenerating display data represented by the contents of the plurality of packets within the protocol data stream 1110, generates at least one state-snapshot.
The background protocol engine 1102 receives a recording of a protocol data stream 1110 comprising a plurality of packets (step 1002). The background protocol engine 1102 generates a representation of the recording of the protocol data stream. In one embodiment, the background protocol engine 1102 generates the representation by rendering the contents of the plurality of packets to a buffer. In some embodiments, the buffer is an off-screen buffer.
In some embodiments, the foreground protocol engine 1106 also receives the recording of the protocol data stream 1110. In these embodiments, the foreground protocol engine 1106 generates a human-perceptible representation of the recording of the protocol data stream, although, as discussed above, the foreground protocol engine 1106 renders both to an off-screen buffer and in a perceptible manner (step 1004). In one of these embodiments, the foreground protocol engine 1106 generates a human-perceptible representation of the recording of the protocol data stream 1110 by rendering the contents of the plurality of packets substantially simultaneously with the background protocol engine 1102 generating at least one state-snapshot during its reading of the recording of the protocol data stream.
After the reading of the at least one packet in the recording of the protocol data stream 1110, the background protocol engine 1102 generates at least one state-snapshot (step 1006). In one embodiment, the background protocol engine 1102 generates at least one state-snapshot during a sequential reading of the recording of the protocol data stream 1110. In another embodiment, the background protocol engine 1102 reads the at least one packet in the recording of the protocol data stream 1110 substantially simultaneously with a rendering of the contents of the packet to a buffer. In one embodiment, the background protocol engine 1102 then stores the generated state-snapshot 1104 (step 1008). In embodiments where the background protocol engine 1102 generates multiple state-snapshots periodically, the state-snapshots may act as markers throughout the recording of the protocol data stream 1110, assisting in the location of a particular point in time in the protocol data stream 1110 and of the packets that come before or after the state-snapshot 1104.
Referring ahead to FIG. 12, a flow diagram depicts one embodiment of steps taken for adaptive generation of state-snapshots. In brief overview, the background protocol engine 1102 monitors an activity of a viewer and generates one or more state snapshots 1104 responsive to the level of activity of a viewer.
During a presentation of a representation of a recording of a protocol data stream 1110 to a user (step 1202), a background protocol engine 1102 monitors an activity of the user (step 1204). In one embodiment, the foreground protocol engine 1106 generates the representation of the recording of the protocol data stream 1110 and presents it to the user with the display 1108. In other embodiments, the background protocol engine 1102 generates the representation. In still other embodiments, a third device generates the representation.
The background protocol engine 1102 monitors an activity of the user during the presentation (step 1204). By monitoring the activity of the user, the background protocol engine 1102 develops an activity profile responsive to the monitoring of the activity (step 1206). The background protocol engine generates at least one state-snapshot 1104 responsive to the developed activity profile (step 1208).
In some embodiments, the background protocol engine 1102 identifies a level of activity of the user. In some embodiments, the background protocol engine 1102 identifies a period of inactivity. In other embodiments, the background protocol engine 1102 identifies an area of interest to the user in the display data. The activity profile reflects these identifications.
The background protocol engine 1102 generates at least one state-snapshot responsive to the activity profile. In some embodiments, the background protocol engine 1102 determines to extend an interval between one or more state-snapshots. In other embodiments, the background protocol engine 1102 determines to reduce an interval between one or more state-snapshots. In still other embodiments, the background protocol engine 1102 determines to remove the at least one state-snapshot, responsive to the activity profile. In still other embodiments, the background protocol engine 1102 determines to add at least one state-snapshot, responsive to the activity profile.
In one embodiment, the background protocol engine 1102 identifies a predicted statistical distribution of seek probabilities. FIG. 13 is a diagram depicting three types of seek probability distributions of one embodiment. In this embodiment, the background protocol engine 1102 collects and stores data about the seek requests made by a user. In one embodiment, the data includes how regularly the user makes a seek request. In one embodiment, the data includes the range, of each seek request—the distance between the requested display data and the current display data presented to the user by rendering the contents of a packet in the recording of the protocol data stream 1110. The range may be described in units of time or relative to the length of the entire recording of the protocol data stream 1110. In one embodiment, the timestamp at which the seek request was made is recorded.
FIG. 14 is a diagram depicting one embodiment of generating state-snapshots responsive to a determined seek probability distribution. The background protocol engine 1102 uses the collected seek request data to generate a seek probability distribution graph centered on the currently presented display data. The background protocol engine 1102 assigns each position in the stream a value indicating the estimated probability the user will request to seek to the display data associated with that position. With this data, the background protocol engine 1102 determines where to place generated state-snapshots 1104 and generates the at least one state-snapshot 1104 responsive to the statistical distribution of seek probabilities.
FIG. 15 depicts one embodiment of a usage pattern of the user. In one embodiment, the background protocol engine 1102 develops an activity profile for a user based upon a usage pattern of the user. The usage pattern reflects identified seek probabilities. Areas of higher seek probability will be provided with a higher state-snapshot density and areas of lower seek probability will be provided with a lower state-snapshot density. In some embodiments, the distance between any pair of state-snapshot is inversely proportional to the average seek probability between them. The background protocol engine 1102 expects the user to seek to higher probability areas, therefore the majority of seeks will be fast as the spacing between generated state-snapshots 1104 is relatively short. To ensure no individual seek request is excessively slow, in one embodiment the background protocol engine 1102 will impose an upper bound on the spacing of generated state-snapshots 1104 even when the seek probability is very low. Likewise, in another embodiment a lower bound prevents placing state-snapshots too close together in very high probability areas. In some embodiments, the amount of rendering between adjacent state-snapshots is considered when determining state-snapshot placement, to minimize latency.
For embodiments with new users or users without a distinguishable usage pattern, the background protocol engine 1102 applies a default state-snapshot generation pattern. This pattern assumes most seeking will occur close to the current frame in either direction, but long range seek performance must only be at best satisfactory. The typical user will demand high performance when jogging back-and-forth around the current frame as many small seek steps can be achieved with jog wheel input device. Seeking long range is less common and noticeable delays may be an acceptable trade-off.
If the user strays from their recognized usage pattern, the background protocol engine 1102 adjusts the state-snapshot generation pattern during live playback without the user's knowledge. The background protocol engine 1102 moves state-snapshot positions to adjust for the new usage pattern. For example, if a user that normally seeks in small steps with the mouse wheel begins seeking longer range, the background protocol engine 1102 reduces the number of state-snapshots around the current frame to free resources for adding state-snapshots within the areas at longer range.
FIG. 16 summarizes one embodiment of the method 1600 discussed above used in a system for adaptive generation of state-snapshots, including a background protocol engine 1602, a foreground protocol engine 1608, a protocol data stream 1612, an activity profile 1604, and a state-snapshot 1606. The foreground protocol engine 1608 presents a representation of a recording of a protocol data stream to a viewer, in some embodiments by a display 1610. The background protocol engine 1602 monitors an activity of the viewer during the presentation, develops an activity profile 1604 responsive to the monitoring and generates and maintains a state-snapshot 1606 responsive to the activity profile.
Referring ahead now to FIG. 18, a flow diagram depicts one embodiment of the steps taken to generate playback instructions for playback of a recorded computer session. In brief overview, a protocol engine, executing on a first device, receives a recorded session (step 1802). The recorded stream comprises a plurality of packets representing display data generated by an application program executed on a second device. The protocol engine determines for a packet in the recorded stream, to render the contents of the packet in a human-perceptible manner (step 1804). Then the protocol engine stores the determination in a playback data structure (step 1806).
In one embodiment, the protocol engine comprises a protocol engine 502, as described in FIG. 5 above. In other embodiments, the protocol engine comprises a background protocol engine 1102, as described in FIG. 11. In still other embodiments, the protocol engine comprises a foreground protocol engine 1106, as described in FIG. 11. In some embodiments, where the protocol engine comprises a background protocol engine 1102, the protocol engine may cease performing a functionality of a background protocol engine 1102 and begin performing a functionality of a foreground protocol engine 1106. In some embodiments, where the protocol engine comprises a foreground protocol engine 1106, the protocol engine may cease performing a functionality of a foreground protocol engine 1106 and begin performing a functionality of a background protocol engine 1102. In other embodiments, the protocol engine comprises both a protocol engine 1102 and a foreground protocol engine 1006. In some of these embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on the same device. In other embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on separate devices.
In one embodiment, the protocol engine determines for a packet in the recorded stream to display the packet in a human-perceptible manner (step 1804). The display includes, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these. In some embodiments, the protocol engine determines to display a packet responsive to the contents of the packet. In one of these embodiments, the protocol engine makes the determination responsive to an indication of an application program having input focus. In another of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of user input stored in the packet. In some of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of graphics update stored by the packet. In others of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of interaction sequence stored by the packet.
In one embodiment, the protocol engine stores the determination in a playback data structure (1806). In some embodiments, a playback data structure describes how to regenerate the display data contained within the recorded stream. In one embodiment, the instructions stored within the playback data structure control the process of rendering display data. In one embodiment, the playback data structure comprises a time for rendering the contents of a packet in the recorded stream. In this embodiment, the time contained in the playback data structure is used for rendering the contents of the packet and not a time of rendering associated with the packet in the recording, if any. In one embodiment, the playback data structure accepts user input in changing the time of rendering.
In some embodiments, the playback data structure comprises metadata that describes how to perform one or more playbacks of a recorded session. In one embodiment, the playback data structure consists of a record for each packet in the recorded stream, indicating at what relative point in time the contents of that packet should be rendered during playback. In some embodiments, the metadata also contains the offset within the file of the start of the packet.
Referring back to FIG. 17, a block diagram depicts one embodiment of a system for rendering a recorded session 1700, including a first device 1702, a background protocol engine 1704, a playback data structure 1706, a foreground protocol engine 1708, a display 1710, a second device 1712, and a recorded stream 1714. The background protocol engine 1704 executes on a first device 1702 and generates a playback data structure 1706 in response to receiving a recorded stream 1714, said recorded stream 1714 representing display data generated by an application program executed on a second device 1712 or on a third device. The foreground protocol engine 1708, receives the recorded stream 1714 and renders the recorded stream 1714 responsive to the playback data structure 1706 generated by the background protocol engine 1704.
In one embodiment, the background protocol engine 1704 and the foreground protocol engine 1708 each receive the recorded stream 1714. In this embodiment, the background protocol engine 1704 generates the playback data structure substantially simultaneously with the foreground protocol engine 1708 rendering the recorded stream.
In one embodiment, the foreground protocol engine 1708 resides on the first device 1702. In another embodiment, shown in shadow in FIG. 17, the foreground protocol engine 1708 resides neither on the first device 1702 nor on the second device 1712. In still another embodiment, the foreground protocol engine 1708 resides on a third device. In some embodiments, the foreground protocol engine 1708 comprises a background protocol engine 1704. In some of these embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on the same device. In others of these embodiments, the background protocol engine 1102 and the foreground protocol engine 1106 reside on separate devices.
In one embodiment, the background protocol engine stores in the playback data structure at least one instruction for rendering at least one packet in the recorded stream. In another embodiment, the background protocol engine stores metadata in the playback data structure. In yet another embodiment, the background protocol engine stores in the playback data structure a record indicating a time to render at least one packet in the recorded session.
The foreground protocol engine 1708 renders at least one packet in the recorded session responsive to the playback data structure. In one embodiment, the foreground protocol engine renders at least one packet in the recorded session in a human-perceptible manner and to a buffer. In another embodiment, the foreground protocol engine renders at least one packet in the recorded session to a buffer.
Referring ahead to FIG. 19, a flow diagram depicts one embodiment of the steps taken in a method for playback of a recorded computer session. In brief overview, a background protocol engine receives a recorded stream comprising a plurality of packets representing display data generated by an application program executing on a second device (step 1902). The background protocol engine determines for at least one packet in the recorded stream, to render the packet in a human-perceptible manner (step 1904). The background protocol engine stores the determination in a playback data structure (step 1906). A foreground protocol engine retrieves at least one packet from the recorded stream (step 1908), access the playback data structure (step 1910), and renders the at least one packet responsive to the playback data structure (step 1912).
In one embodiment, the protocol engine determines for a packet in the recorded stream to display the packet in a human-perceptible manner (step 1904). The display includes, without limitation, audio, visual, tactile, or olfactory presentations, or combinations of these. In some embodiments, the protocol engine determines to display a packet based responsive to the contents of the packet. In one of these embodiments, the protocol engine makes the determination responsive to an indication of an application program having input focus. In another of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of user input stored in the packet. In some of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of graphics update stored by the packet. In others of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of interaction sequence stored by the packet. In one embodiment, the protocol engine stores the determination in a playback data structure (1906).
In one embodiment, the foreground protocol engine receives the recorded session. In other embodiments, the foreground protocol engine retrieves the recorded session. In some of these embodiments, the foreground protocol engine retrieves the recorded session from a storage element.
In one embodiment, the foreground protocol engine retrieves at least one packet from the recorded stream (step 1908). In this embodiment, the foreground protocol engine then accesses the playback data structure (step 1910) and renders the contents of the packet responsive to the playback data structure (step 1912). In some embodiments, the playback data structure contains an instruction to render the contents of the packet in a perceptible manner. In one of these embodiments, the foreground protocol engine renders the contents of the packet on-screen. In some embodiments, the foreground protocol engine always renders the contents of the at least one packet to a buffer. In many embodiments, when the foreground protocol engine renders the contents of a packet to a buffer, it is an off-screen buffer. In one of these embodiments, the foreground protocol engine renders the contents of the packet to an off-screen buffer and also renders the contents of the packet on-screen, as directed by the playback data structure.
In other embodiments, the playback data structure comprises an instruction not to render the contents of the packet in a perceptible manner. In one of these embodiments, upon accessing the playback data structure, the foreground protocol does not render the contents of the packet in a perceptible manner but does render the contents of the packet to a buffer.
For embodiments in which the foreground protocol engine renders the contents of a packet only to an off-screen buffer, responsive to the playback data structure, the foreground protocol engine perceptibly regenerates display data differing from the recorded stream. This results, in one embodiment, in a presentation of display data shorter than the original recorded stream. In some embodiments, the rendered contents of the packets provide a streamlined regeneration of the original display data. In other embodiments, the rendered contents of the packets provide a customized version of the display data. In one embodiment, the determination to render the contents of the packet in a perceptible manner is responsive to a policy or user request. These embodiments provide users with control over the playback of the recorded session.
Referring ahead to FIG. 21, one embodiment is depicted of rendering a recorded session with perceptible intervals of time containing no activity eliminated. In this figure, black blocks represents a packet or packets containing user input and dotted blocks represents a packet or packets containing graphics commands. The time intervals represented by white blocks in both the “User input” and “Graphics” rows have no packets and hence no activity at all.
One embodiment of a method to eliminate perceptible intervals of time with no activity is as follows. A first packet in a recorded session is identified. The recorded session comprises a plurality of packets representing display data. The nearest previous packet to the first packet in the recorded session is identified as a second packet. A first time interval is determined, the time interval occurring between said first packet and said second packet. A determination is made that the first time interval exceeds a threshold. The contents of the packets in the recorded session are rendered with a second time interval between said first packet and said second packet shorter than the first time interval.
In one embodiment, a protocol engine makes the determinations. In some embodiments, the protocol engine stores the determinations in a playback data structure. In one embodiment, the same protocol engine renders the recorded session responsive to the playback data structure. In another embodiment, the protocol engine making the determinations comprises a background protocol engine and the protocol engine rendering the recorded session comprises a foreground protocol engine.
In one embodiment, when the protocol engine determines that the time interval exceeds the threshold, the protocol engine categorizes the time interval as a perceptible time interval. A time interval is perceptible if a user of the regenerated recorded session can perceive that a period of time lacking activity has elapsed. In some embodiments, a policy determines the threshold. In other embodiments, the protocol engine is hard coded with a predefined threshold. In this embodiment, the protocol engine stores an instruction in the playback data structure to render a shorter time interval between the first and second packets instead of the original time interval. In another embodiment, the protocol engine determining that the time interval exceeds the threshold also renders the contents of the recorded session. In this embodiment, the protocol engine does not store the instruction to render the shorter time interval in the playback data structure. For a time interval not categorized as perceptible, no shortened time interval is needed and the original time interval is rendered between the first and second packets.
Referring back to FIG. 20, a flow diagram depicts one embodiment of the steps taken to generate playback instructions for rendering a recorded session. In brief overview, a type of input stored by a packet in a recorded session is identified (step 2002) and the packet is marked responsive to the type of input (step 2004). Then a destination for rendering the contents of the packet, responsive to the marking, is stored in a playback data structure.
In one embodiment, the type of input stored by a packet determines whether or not the packet will be rendered. In one embodiment, the packet contains no content. In some embodiments, at least one packet contains no content. In these embodiments, an interval of time comprised of at least one packet containing no content is identified. In some of these embodiments, the interval of time will not be rendered.
In some embodiments, the type of input refers to input from certain types of input devices, including, without limitation, a keyboard, a mouse, a microphone, or a camera. In one embodiment the step of identifying the type of input further comprises identifying the type of input as input from an input device. In another embodiment, the step of identifying the type of input further comprises identifying the type of input as keyboard input. In other embodiments, the type of input is not related to the input device. In one of these embodiments, the type of input is identified as a command.
The packet containing the input is marked responsive to the type of input it contains (step 2004). In one embodiment, the packet is marked responsive to a policy. In this embodiment, a policy determines the types of input which result in a packet being marked. In another embodiment, no marking is required.
A destination for rendering the packet is stored in a playback data structure responsive to the marking (step 2006). In some embodiments, the destination comprises a buffer. In one embodiment, an instruction is stored in the playback data structure, directing rendering of the packet to the buffer. In one embodiment, the buffer is an off-screen buffer and when the contents of the packet are rendered to the buffer they are not perceptible to a user of the rendering. In one embodiment, an instruction is stored in the playback data structure, directing rendering of the marked packet both in a perceptible manner and to a buffer.
In one embodiment, the method eliminates perceptible intervals of time containing no meaningful activity. In this embodiment, a policy identifies a particular type of input as meaningful or as insignificant. The policy may be hard coded into a protocol engine, in some embodiments. In other embodiments, an administrator configures the policy.
In some embodiments, a protocol engine identifies a packet as insignificant if the packet contains no content. In some of those embodiments, the packet represents an interval of time in which the no user activity occurred to be recorded into the recorded stream 1714. In these embodiments, the protocol engine stores in a playback data structure a destination for rendering each of the plurality of packets in the recorded stream in such a way that any insignificant packet does not render in a perceptible manner. FIG. 22 depicts one embodiment of a regenerated recorded stream whose contents are rendered responsive to a playback data structure. Rendering responsive to the playback data structure, in this embodiment, allows elimination of intervals of time containing no meaningful activity (depicted by the white and striped blocks in FIG. 22), which includes intervals of time containing no activity at all. This rendering provides a more meaningful regeneration of the recorded session to a user, where a policy determines when content represents meaningful activity. In one embodiment, the content representing meaningful activity comprises types of user input.
In some embodiments, the protocol engine identifies an input type responsive to previously defined input types comprising provably insignificant time. In some embodiments, insignificant time includes an interval of time in which no packet contains any content. In other embodiments, a policy defines the input types, which constitute insignificant time. In still other embodiments, a definition of an input type comprising provably insignificant time is hard coded into the protocol engine.
In some embodiments, the contents of a packet represent user activity but a policy identified the activity as insignificant activity. In one of these embodiments, the policy defines an insignificant activity as activity deemed to be of no interest to a user of the regenerated recorded session. In another of these embodiments, meaningful packets contain contents of interest to a user of the regenerated recorded session, as determined by the policy. In one embodiment, an insignificant packet has no content representing input meaningfully interacting with an application. In another embodiment, the device transmitting application data in the protocol data stream from which the recorded stream was created transmitted no meaningful screen updates.
In one embodiment, the protocol engine determines for at least one packet in the recorded session whether the contents of the packet include types of input such as, without limitation, keyboard input, mouse input, or command messages. If the packet does contain a type of input such as keyboard input, the protocol engine marks the packet as a meaningful packet. If the packet does not contain that type of input, the protocol engine marks the packet as insignificant. In one embodiment, the packet is insignificant only if all of its contents are insignificant. In another embodiment, a packet contains more than one type of input each of which may be marked as meaningful or insignificant.
In one embodiment, when the protocol engine marks a packet as insignificant, the protocol engine determines that the contents of the packet should not render in a perceptible manner. In some embodiments, the protocol engine determines instead that the contents of the packet should render to a buffer. In one of these embodiments, the buffer is an off-screen buffer. If the packet is marked as a meaningful packet, the protocol engine determines, in one embodiment, that the contents of the packet should render in a perceptible manner. In some embodiments, a perceptible manner comprises rendering on-screen. In one embodiment, the protocol engine determines that the packet should render both in a perceptible manner and to a buffer. In this embodiment, the contents of the packet render both to an on-screen display and to an off-screen buffer. The protocol engine stores the determination in the playback data structure.
In one embodiment, depicted in FIG. 22, certain packets in the recording stream have content representing meaningful user activity, in this embodiment a mouse input indicating an active mouse button state represented by the black blocks in FIG. 22. Other packets in the recording stream have content representing mouse input indicating an inactive mouse button state, represented by the striped blocks in FIG. 22. The protocol engine identifies at least one packet containing only insignificant activity, such as a mouse input indicating an inactive mouse button state, and stores in a playback data structure a determination that the contents of the packet should not render in a perceptible manner. By making this determination, a protocol engine rendering the contents of the recorded stream responsive to the playback data structure regenerates only the display data relevant to the user of the regenerated recorded session, where a policy defines relevance or where the protocol engine comprises a definition of relevant content.
Referring now to FIG. 23, a flow diagram depicts one embodiment of the steps taken to eliminate periods with no meaningful activity in rendering a recorded session. A first time interval is determined, the time interval occurring between a marked packet and a nearest previous marked packet in a recorded session (step 2302). The recorded session comprises a plurality of packets representing display data. A determination is made that the first time interval exceeds a threshold (step 2304). The contents of the packets in the recorded session are rendered with a second time interval between the marked packet and the nearest previous marked packet shorter than the first time interval (step 2306).
In one embodiment, a protocol engine makes the determinations. In some embodiments, the protocol engine stores the determinations in a playback data structure. In one embodiment, the same protocol engine renders the recorded session responsive to the playback data structure. In another embodiment, the protocol engine making the determinations comprises a background protocol engine and the protocol engine rendering the recorded session comprises a foreground protocol engine.
In some embodiments, the protocol engine makes the determination of the first time interval (step 2302) and whether or not the first time interval exceeds a threshold (step 2304) after a packet has been marked as a meaningful packet responsive to the type of input contained in the packet. In one of these embodiments, the type of output contained in the packet impacts the determination to mark the packet. In one embodiment, the protocol engine determines the time interval between the packet marked as meaningful and the nearest previous meaningful packet, or the start of the recording if there are no previous meaningful packets. In another embodiment, the protocol engine renders the contents of the recorded session with a second time interval between the marked packet and a previous packet said second time interval comprising a shorter time interval than the first time interval. In another embodiment, the protocol engine renders the contents of the recorded session with a second time interval between the marked packet and a packet following the marked packet, said second time interval comprising a shorter time interval than the first time interval.
In one embodiment, when the protocol engine determines that the time interval exceeds the threshold (step 2304), the protocol engine categorizes the time interval as a perceptible time interval. A time interval is perceptible if a user of the regenerated recorded session can perceive that a period of time lacking activity has elapsed. In some embodiments, a policy determines the threshold. In other embodiments, the protocol engine is hard coded with a predefined threshold. In this embodiment, the protocol engine stores an instruction in the playback data structure to render a shorter time interval between the two meaningful packets instead of the original time interval. In another embodiment, the protocol engine determining that the time interval exceeds the threshold also renders the contents of the recorded session. In this embodiment, the protocol engine does not store the instruction to render the shorter time interval in the playback data structure. For a time interval not categorized as perceptible, no shortened time interval is needed and the original time interval is rendered between the two meaningful packets.
In some embodiments, contents of a packet in the recorded stream represent graphics updates affecting a screen region. In one embodiment, the graphics updates include, without limitation, flashing system tray icons, title bars or task bar entries, blinking text in web pages or applications, clock displays, system animations, application animations, and stock tickers and other periodically updated information displays. In some embodiments, graphics updates such as these are determined to be insignificant to a user of a regeneration of the recorded stream. In one of these embodiments, a protocol engine comprises this determination. In another of these embodiments, a policy defines at least one graphics update as insignificant. In this embodiment, an administrator generates the policy. In another embodiment, a user of the regeneration of the recorded stream generates the policy.
Referring now to FIG. 24, a flow diagram depicts one embodiment of the steps taken to eliminate a graphics update in rendering a recorded session. In brief overview, a graphics update is identified (step 2402) and the screen region affected by the graphics update is determined (step 2404). An indication of the location and state of the affected screen region is stored (step 2406) and a second graphics update affecting the state of the screen region is identified (step 2408). Then a destination for rendering and a time interval for rendering are indicated, responsive to whether the second graphics update varies the region affected by the first graphics update (step 2410 and step 2412).
In one embodiment, a protocol engine performs the steps depicted by FIG. 24. In this embodiment, the protocol engine identifies a packet in a recorded session, said recorded session representing display data generated by an application program and said packet containing a first graphics update. The protocol engine determines a screen region affected by the first graphics update. In one embodiment, the graphics update affects a screen region by changing the data displayed on that portion of the screen. The protocol engine stores an indication of the state of the screen region after the first graphics update and the location of the screen region. In one embodiment, the protocol engine stores a copy of the updated screen region. In another embodiment, the protocol engine stores a hash of the updated screen region.
In one embodiment, the protocol engine identifies a second graphics update affecting the screen region within a time interval. In some embodiments, a policy determines the length of the time interval. In one of these embodiments, the policy determines a time interval approximating the upper limit of human scale cyclic periods used by applications and operating systems. In one embodiment, when a region of the screen goes through a cyclic display, at a period designed to be viewed by the user (for example, a significant fraction of a second up to several seconds), the display comprises a human scale cyclic period. In some embodiments, the protocol engine comprises a definition of the length of the time interval.
In an embodiment where the protocol engine identifies a second graphics update affecting the screen region affected by the first graphics update, the protocol engine determines whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update. If the screen region does not vary after the second graphics update, the second graphics update need not render in the regenerated recorded session. A screen graphics update in this embodiment need not render since the protocol engine determined that the graphics update is performing a cycle of drawing commands at human-scale speeds, making the update observable to a user of the regenerated recorded session, but the graphics update carries insignificant information for the user. In some embodiments, the graphics update affects the screen region by drawing, without limitation, a caret flashing, a flashing taskbar icon, a network activity indicator, or scrolling text. In some embodiments, a policy determines that affecting a screen region with that type of graphics update does not constitute a meaningful activity and should not render in the regeneration of the recorded session for a user. In other embodiments, the protocol engine comprises this determination.
In one embodiment, an indication of a destination for rendering the second packet containing the second graphic update affecting the screen region is stored in a playback data structure, responsive to whether the screen region varies after the second graphics update. In another embodiment, an indication of a time interval to render associated with the second packet containing the second graphic update affecting the screen region is stored in a playback data structure, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
FIG. 25 depicts one embodiment of rendering the regenerated recorded session responsive to indications stored in a playback data structure, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update. In one embodiment, the screen region affected by the first graphics update does not vary after the second graphics update. In this embodiment, an indication is stored in a playback data structure not to render the second graphics update in a perceptible manner. In one embodiment, not perceptibly rendering the second graphics update comprises rendering the second graphics update off-screen and not on-screen. In some embodiments, not perceptibly rendering the second graphics update comprises rendering the second graphics update to an off-screen buffer. In one embodiment, not perceptibly rendering the second graphics update comprises not rendering the second graphics update. In some embodiments, a determination not to render the second graphics update perceptibly comprises rendering a perceptible indication that the graphics update is not rendered. In one of these embodiments, a user of the regenerated recorded session may request that the second graphics update render perceptibly.
FIG. 25 depicts an embodiment in which a cyclic update is detected by determining that the state of the screen region after the second graphics update does not vary from the state of the screen region after the first graphics update and determining not to render the second graphics update responsive to the detection of the cyclic update. In one embodiment where the state of the screen region affected by the second graphics update varies from the state of the screen region after the first graphics update, a determination is made to render the contents of the packet in a perceptible manner and to a buffer.
In some embodiments, the contents of a plurality of packets represent a graphics update. In one of these embodiments, a determination to render a graphics update in a perceptible manner is made responsive to the effects of more than two graphics updates on a screen region. In one embodiment, the determination of a destination for rendering a graphics update is responsive to the graphics update represented by the contents of each packet in the identified plurality of packets.
In some embodiments, contents of a packet in the recorded stream represent an interaction sequence. In one embodiment, the interaction sequence comprises, without limitation, a logon sequence, a logoff sequence, or the entering of credentials. In some embodiments, interaction sequences such as these are determined to be insignificant to a user of a regeneration of the recorded stream. In one of these embodiments, a protocol engine comprises this determination. In another of these embodiments, a policy defines at least one interaction sequence as insignificant. In this embodiment, an administrator generates the policy. In another embodiment, a user of the regeneration of the recorded stream generates the policy.
Referring now to FIG. 26, a flow diagram depicts one embodiment of the steps taken to eliminate interaction sequences in rendering a recorded session. A start of an interaction sequence of at least one packet is identified responsive to a policy (step 2602). In a playback data structure there is an indication that the interaction sequence should render to a buffer (step 2604). A termination of the interaction sequence of at least one packet is identified (step 2606). A first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified (step 2608). A playback data structure contains an indication to render a second time interval shorter than the first time interval (step 2610).
In one embodiment, a protocol engine makes the identifications and indications to eliminate an interaction sequence. An identification of a start of an interaction sequence is made (step 2602). In one embodiment, the start of the interaction sequence is identified by identifying a visual marker. In one embodiment, a visual marker comprises a credentials window, displayed in the same way for all sessions. In another embodiment, a visual marker comprises a replacement of a credentials window by a blank screen and then by a desktop background. In one embodiment, a visual marker comprises the display of recognizable icons.
In some embodiments, a start of an interaction sequence is identified by determining a start time of an interaction sequence. In one of these embodiments, a component detects the start time of an event in an interaction sequence. In another of these embodiments, the component detects the start time of a logon sequence. In still others of these embodiments, the component detects the start time of a logoff sequence. In one embodiment, the identification of the start of the interaction sequence is responsive to identifying a window with an input focus.
An indication is made in a playback data structure that an interaction sequence should render in a buffer (step 2604). In this embodiment, where an identified interaction sequence should not render perceptibly, the interaction sequence is rendered to a buffer. Rendering the interaction sequence to a buffer results in the interaction sequence being imperceptible to a user of the rendering. For embodiments where a policy or user categorized the interaction sequence as insignificant, this rendering results in the elimination of an insignificant interaction sequence.
An identification of a termination of an interaction sequence is also made (step 2606). In some embodiments, the termination of the interaction sequence is identified by identifying a visual marker. In other embodiments, a termination of an interaction sequence is identified by determining a termination time of the interaction sequence. In one of these embodiments, a component detects the termination time of an event in an interaction sequence. In another of these embodiments, the component detects the termination time of a logon sequence. In still others of these embodiments, the component detects the termination time of a logoff sequence. In another embodiment, identifying the termination of the interaction sequence is responsive to identifying a window with an input focus.
In some embodiments, an interaction sequence comprises use of an application. In one of these embodiments, a policy identifies interaction sequences comprising use of an application that should not render in a perceptible manner. In one embodiment, such applications include, without limitation, word processing documents.
In one of these embodiments, a start of an interaction sequence is identified by identifying an application having input focus. When the contents of a packet represent a window having focus, a determination is made as to the application responsible for the process that created the window. In one embodiment, the contents of the packet representing a window having focus include window notification messages indicating a change in input focus. If the responsible application identifies a start of an interaction sequence which should not render perceptibly, an indication is stored in a playback data structure to render the interaction sequence to a buffer. A termination of an interaction sequence is identified by identifying the acquisition of focus by a window owned by a process not associated with the application of the interaction sequence.
In one embodiment, a first time interval is associated with the interaction sequence. Perceptibly rendering the time interval associated with the interaction sequence in an embodiment where the interaction sequence itself does not render results in a period of time perceptible to a user of the rendering in which no display data renders and the user waits through the time interval before a rendering of the contents of a packet after the interaction sequence. One embodiment eliminates the time interval associated with the interaction sequence by rendering a shorter time interval in place of the original time interval. In this embodiment, a first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified (step 2608). A playback data structure contains an indication to render a second time interval shorter than the first time interval (step 2610).
In some embodiments, a protocol engine renders the contents of a packet in a recorded session, providing to a user a regeneration of the recorded session. In some of these embodiments, the protocol engine automatically varies the time intervals between rendering the contents of at least one packet, resulting in context-sensitive time-warped playback. In these embodiments, rendering approximates the ability of the user to comprehend the display data presented to the user. In one embodiment, the time intervals between rendering contents of packets increase when the protocol engine determines the display data represented by the contents of the packets to have an increased level of complexity or importance, as defined by a policy. In another embodiment, the time intervals between rendering contents of packets decrease when the protocol engine determines the display data represented by the contents of the packets to have a decreased level of complexity or importance, as defined by a policy. In these embodiments, the protocol engine approximates the ability of the user to comprehend the display data and renders the contents either more slowly to give the user time to comprehend the rendering or renders the contents faster when a user requires less comprehension time.
Referring now to FIG. 27, a flow diagram depicts one embodiment of the steps taken in automatic time-warped playback in rendering a recorded computer session. A protocol engine receives a recorded session (step 2702), the recorded session comprising a plurality of packets and representing display data, and the protocol engine determining a measure of complexity represented by at least some of the plurality of packets in the recorded session (step 2704). The protocol engine identifies an interval of time between the at least some of the plurality of packets in the recorded session (step 2706) and modifies the interval of time responsive to the measure of complexity represented by the at least some of the plurality of packets in the recorded session (step 2708). The protocol engine stores in a playback data structure the modified interval of time (step 2710) and the recorded data stream is rendered responsive to the playback data structure (step 2712).
In some embodiments, the protocol engine determining the measure of complexity, identifying the interval of time, modifying the interval of time and storing the modification is a background protocol engine. In one of these embodiments, the background protocol engine also renders the recorded stream. In another of these embodiments, a foreground protocol engine renders the recorded stream responsive to the playback data structure. In some embodiments, the background protocol engine and the foreground protocol engine reside on the same device. In other embodiments, the background protocol engine and the foreground protocol engine reside on separate devices.
In some embodiments, the protocol engine determines a measure of complexity represented by at least some of a plurality of packets in the recorded session (step 2704). In some of these embodiments, the protocol engine determines the measure of complexity by identifying likely sequences of typing in keyboard input. In one embodiment, the protocol engine inspects at least one type of key involved to identify likely sequences of typing in keyboard input. In another embodiment, the protocol engine inspects a sequence of at least one glyph rendered to complete a heuristic approximation of likely sequences of typing in keyboard input.
In some of these embodiments, the protocol engine stores classifications of keys determined by characteristics of the key. Key characteristics include, without limitation printable or non-printable characters, white space, navigation keys, or function keys, and include combinations of characteristics. In one embodiment, a protocol engine determines that sections of input comprising printable characters and occasional navigation keys constitute normal typing, while sections with mostly non-visible keys do not constitute normal typing. In one embodiment, the protocol engine determines a measure of complexity responsive to the amount of white space identified. In this embodiment, the protocol engine comprises a definition of word processing indicating that a white space key appears on average approximately every 5-8 characters in typical typing patterns.
In one embodiment, the protocol engine uses the appearance of non-printable characters to determine the measure of complexity. In another embodiment, the protocol engine accesses the keystroke sequences to identify sequences of non-white space printable characters appearing close together in time. In this embodiment, the protocol engine comprises the capacity to compare the keystroke sequences to a dictionary to identify valid words and determine a measure of complexity relating to an ability of a user to comprehend valid words versus invalid words.
In another embodiment, the protocol engine determines that the contents of the packet contain commands to render glyphs. In this embodiment, the protocol engine uses the glyphs to determine whether the display data represents a user activity of typing. In this embodiment, if a glyph rendering rate approximates the keyboard input rate with a small delay, it is likely that keystrokes are directly resulting in glyphs, thus making it quite likely the user is typing. In one embodiment, the protocol engine correlates the keys entered with the glyphs produced. In another embodiment, the protocol engine determines the spatial sequence (left-to-right, right-to-left, etc.) of the rendered glyphs to determine that a user is typing. In one embodiment, the protocol engine makes the determination of the measure of complexity responsive to the result of analyzing the contents of the plurality of packets and identifying patterns and activities represented by the contents.
In other embodiments, the protocol engine makes the determination of the measure of complexity responsive to an identification of a type of mouse input. In one embodiment, the protocol engine determines that a mouse input representing a click of the mouse causes actions that may need a slower rendering rate to comprehend, especially if the clicks follow a sequence of typing. In another embodiment, the protocol engine determines that mouse input that does not represent a clicking of a mouse does not affect the ability of a user to comprehend display data, and thus does not affect the measure of complexity.
In other embodiments, the protocol engine makes the determination of the measure of complexity responsive to identifying a heuristic approximation of complexity of a graphics update. In one embodiment, the protocol engine identifies a heuristic approximation of complexity of a graphics update based upon, without limitation, the size of region(s) being updated, the size of the area of the region changed by the graphics commands, a historical frequency of updates to individual regions, cyclic graphics commands, number of graphics commands, frequency of graphics commands, time interval between adjacent packets whose contents contain graphics command, or the type of graphics update. In an embodiment where the protocol engine identifies a low measure of complexity for the graphics update, the protocol engine determines a low measure of complexity represented by the packets containing the graphics updates. In an embodiment where the protocol engine identifies a high measure of complexity for the graphics update, the protocol engine determines a high measure of complexity represented by the packets containing the graphics updates.
In one embodiment, the protocol engine identifies an interval of time between the at least some of the plurality of packets in the recorded session (step 2706). In this embodiment, the protocol engine modifies the interval of time responsive to the determined measure of complexity (step 2708). In an embodiment where at least some of the plurality of packets in the recorded session have content representing display data associated with a high measure of complexity, the protocol engine increases the interval of time between the packets to allow the user of the rendering increased time to comprehend the rendered display data. In another embodiment where at least some of the plurality of packets in the recorded session have content representing display data associated with a low measure of complexity, the protocol engine decreases the interval of time between the packets to reflect decreased amount of time the user requires to comprehend the rendered display data. In one embodiment, a user requires a different amount of time between the rendered contents of packets than the amount rendered by the protocol engine. In this embodiment, the user modifies the interval of time to reflect the amount of time the user requires to comprehend the rendered display data. In some embodiments, the protocol engine also identifies a time interval between the at least some of the plurality of packets and other packets in the plurality of packets, modifying the interval of time identified between those sets of packets.
In some embodiments, the protocol engine identifies a first marker associated with a packet in the recorded session. In one embodiment, the packet comprises the marker. In another embodiment, the recorded session comprises the marker.
In one embodiment, a user of the rendering of the display data defines the marker. In another embodiment, the protocol engine defines the marker. In embodiments where the protocol engine identifies a marker, the protocol engine modifies the interval of time responsive to the first marker. In one embodiment, the protocol engine increases the interval of time providing the user of the rendering of the display data additional time for comprehending the contents of the packet associated with the first marker. In other embodiments, the protocol engine identifies a second marker in a second packet. In this embodiment, the protocol engine modifies the interval of time responsive to the distance between the first marker and the second marker. In this embodiment, the protocol engine provides increased time for comprehension of display data represented by contents of packets marked and decreased time for comprehension of data represented by contents of unmarked packets. In one embodiment, a user defines markers for display data of interest to the user and the protocol engine renders additional time for the display data of interest to the user and decreases time of rendering for display data not of interest to the user, as determined by the markers.
In one embodiment, the protocol engine identifies a first marker in the at least some of the plurality of packets in the recorded session, said marker indicating an initial packet in the at least some of the plurality of packets in the recorded session. The protocol engine modifies the interval of time responsive to the first marker. The protocol engine identifies a second marker in a second packet in the at least some of the plurality of packets in the recorded session, said second marker indicating a final packet in the at least some of the plurality of packets in the recorded session and modifying the interval of time responsive to the interval of time between the first marker and the second marker.
In one embodiment, the protocol engine stores the modified interval of time in a playback data structure (step 2710) and the recorded stream is rendered responsive to the contents of the playback data structure (step 2712). In one embodiment, the protocol engine also renders the recorded stream responsive to the playback data structure instructions regarding modified time intervals. In another embodiment, a separate foreground protocol engine renders the recorded stream.
In some embodiments, a determination is made that recorded interaction with an application requires increased time for rendering, to provide a user of the rendering increased time for comprehension of the rendered display data. In some of these embodiments, the determination is made that the application requiring increased time comprises a more important application than an application not requiring the increased time. In one of these embodiments, the user makes the determination. In another of these embodiments, a policy makes the determination. In still another of these embodiments, the protocol engine comprises a definition of applications that require increased time.
Referring now to FIG. 28, a flow diagram depicts one embodiment of the steps taken for automatic time-warped playback responsive to an identified application in rendering a recorded computer session. A recorded session comprising a plurality of packets and representing display data is received (step 2802). A first packet having a content representing a window having focus is identified, said window indicating an application (step 2804). A time interval is identified between a second packet whose contents render prior to the rendering of the content of the first packet and a third packet whose contents render after the rendering of the content of the first packet (step 2806). The identified time interval is modified responsive to the indicated application (step 2808). At least one packet in the recorded stream is rendered responsive to the modification (step 2810).
In one embodiment, a protocol engine receives the recorded session (step 2802). In this embodiment, the protocol engine also identifies a first packet having a content representing a window having focus is identified, said window indicating an application (step 2804). In one embodiment, the contents of the packet representing a window having focus include window notification messages indicating a change in input focus. In one embodiment, a time interval is identified between a second packet whose contents render prior to the rendering of the content of the first packet and a third packet whose contents render after the rendering of the content of the first packet (step 2806). In this embodiment, the protocol engine identifies a packet whose contents render prior to the rendering of content representing an application window having focus, a packet whose contents represent the application window having focus, and a packet whose contents represent the application window no longer having focus.
In some embodiments, the protocol engine modifies the time interval preceding the application having focus. In other embodiments, the protocol engine modifies the time interval following the application having focus. In one embodiment, the protocol engine then determines the interval of time in which the application window has focus and modifies that time interval responsive to the type of application. In one embodiment, the protocol engine increases the identified time interval. In this embodiment, the protocol engine provides the user of the rendering an increased amount of time to review the application. In another embodiment, the protocol engine decreases the identified time interval. In this embodiment, the protocol engine provides the user of the rendering a decreased amount of time to review the application, reflecting the decreased amount of interest in the application.
In one embodiment, the protocol engine renders at least one packet in the recorded stream responsive to the modification. In one embodiment, the protocol engine renders the contents of the at least one packet in the recorded stream to a buffer. In one embodiment, rendering to a buffer does not render the contents of the packet in a perceptible manner. In another embodiment, the protocol engine renders the contents of the at least one packet in the recorded stream to a buffer and in a perceptible manner. In some embodiments, the protocol engine indicates the modified time interval in a playback data structure and a separate protocol engine renders the recorded session responsive to the information stored in the playback data structure.
Referring now to FIG. 29, a block diagram depicts one embodiment of a system for automatic time-warped playback in rendering a recorded computer session 2900, including a protocol engine 2902, a recorded stream 2910, a playback data structure 2904, and a display 2908. In brief overview, the protocol engine 2902 generates a playback data structure 2904 in response to receiving a recorded stream 2910, said recorded stream 2910 comprising a plurality of packets, and said protocol engine 2902 rendering at least one packet in the recorded stream responsive to the generated playback data structure 2904.
In one embodiment, the protocol engine 2902 comprises a background protocol engine and a foreground protocol engine. In this embodiment, the background protocol engine receives the recorded stream 2910 and generates the playback data structure 2904. In this embodiment, the foreground protocol engine receives the recorded stream 2910 and renders at least one packet in the recorded stream responsive to the generated playback data structure 2904. In one embodiment, the background protocol engine and the foreground protocol engine reside on the same device. In another embodiment, the background protocol engine resides on a first device and the foreground protocol engine resides on a second device.
In another embodiment, the system comprises a single protocol engine 2902 generating the playback data structure 2904 and rendering at least one packet in the recorded stream responsive to the generated playback data structure 2904.
In one embodiment, the protocol engine 2902 stores in the playback data structure at least one instruction for rendering the recorded session. In one embodiment, the instruction comprises a modification of an identified time interval for rendering the contents of a packet in the recorded session. In another embodiment, the protocol engine stores metadata in the playback data structure. In this embodiment, the metadata comprises higher order instructions for rendering the contents of the packet.
In one embodiment, the protocol engine renders the contents of at least one packet in the recorded session responsive to contents of a playback data structure. In one embodiment, the protocol engine renders the at least one packet in the recorded session in a perceptible manner and to a buffer. In another embodiment, the protocol engine renders the at least one packet in the recorded session to a buffer.
In some embodiments, the rendered contents of the packets provide a streamlined regeneration of the original display data. In other embodiments, the rendered contents of the packets provide a customized version of the display data. In one embodiment, the determination to render the contents of the packet in a perceptible manner is responsive to a policy or user request. These embodiments provide users with control over the rendering of the recorded session.
Referring now to FIG. 30A, a block diagram depicts one embodiment of a system for recording and real-time playback of presentation layer protocol data. In brief overview, the system includes a recorder 3010, a distributor 3020, and a protocol engine 502. The recorder 3010 intercepts a presentation layer protocol data stream 208 comprising a plurality of packets, during transmission of the presentation layer protocol data stream 208 from a first device 106 to a second device 102, the presentation layer protocol data stream 208 representing display data. The distributor 3020 transmits a copy of at least one packet of the presentation layer protocol data stream 208. The protocol engine 502 uses the information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet. The recorder 3010 continues intercepting the presentation layer protocol data stream and the distributor continues transmitting copies of packets from the presentation layer protocol data stream until the first device completes transmission of the protocol data stream to the second device.
Referring now to FIG. 30A, and in greater detail, in one embodiment, the recorder 3010 extracts data from a presentation layer protocol stack and buffers the data temporarily. In another embodiment, the third device 222 records data to disk and catalogs the data. In still another embodiment, the playback device 514 displays session recordings, both complete and incomplete, to a user.
The recorder 3010 intercepts a presentation layer protocol data stream 208 comprising a plurality of packets, during transmission of the presentation layer protocol data stream 208 from a first device 106 to a second device 102, the presentation layer protocol data stream 208 representing display data. In one embodiment, the first device 106 is a server 106, such as an application server. In another embodiment, the second device 102 is a client 102. In still another embodiment, the first device 106 transmits the presentation layer protocol data stream 208 as described above in connection with FIG. 2. In yet another embodiment, the presentation layer protocol data stream 208 is a protocol data stream 208 as described above in connection with FIG. 2. In a further embodiment, the recorder 3010 is a recorder 206 as described above in connection with FIG. 2. In some embodiments, the presentation layer protocol data stream 208 comprises one or more virtual channels. In one of these embodiments, the recorder 3010 intercepts a virtual channel.
In one embodiment, the recorder 3010 resides on the first device 106. In another embodiment, the recorder 3010 resides on the second device 102. In still another embodiment, the recorder 3010 resides on a third device 222. In yet another embodiment, the recorder 3010 resides on a proxy server.
In one embodiment, the recorder 3010 is located on a passthrough server. In another embodiment, the recorder 3010 is located on a network packet sniffer. In still another embodiment, the recorder 3010 is located on a network appliance, application gateway, application acceleration appliance or other appliance. In some embodiments, the recorder 3010 resides on the same device as the distributor 3020.
In some embodiments of the recorder 206 described in connection with FIG. 2, the recorder intercepted the protocol data stream 208 and created a recorded protocol data stream 210 using copied packets. In one embodiment, the recorder comprises a means for copying at least one packet from the presentation layer protocol data stream. In another embodiment, the recorder comprises a means for intercepting a virtual channel. In still another embodiment, the recorder comprises a means for intercepting the presentation layer protocol data stream at substantially the same time as the first device transmits the presentation layer protocol data stream to the second device. In yet another embodiment, the recorder comprises a buffer for storing the at least one packet. In some embodiments, the recorder comprises a recording generator for creating a recording of the presentation layer protocol data stream, or of a portion of the presentation layer protocol data stream.
In other embodiments, as depicted in FIG. 30A, the recorder 3010 intercepts a presentation layer protocol data stream 208 and copies packets from the presentation layer protocol data stream 208 during the transmission of additional packets in the presentation layer protocol data stream 208 from the server 106 to the client 102. In one of these embodiments, the recorder 3010 intercepts the presentation layer protocol data stream 208 at substantially the same time as the server 106 transmits the presentation layer protocol data stream 208 to the server 102. In another of these embodiments, the recorder 3010 receives an indication of a request for real-time playback of a presentation layer protocol data stream 208. In still another of these embodiments, the recorder 3010 copies a packet from the presentation layer protocol data stream 208 and forwards the packet before completing interception of the presentation layer protocol data stream 208, responsive to the received indication of the request for real-time playback. In yet another of these embodiments, the recorder 3010 does not delay the transmission of an intercepted packet until the completion of the recording of the presentation layer protocol data stream 208.
In one embodiment, the recorder 3010 further comprises a means for storing a copy of at least one packet of the presentation layer protocol data stream 208 in a storage device. In some embodiments, the recorder 3010 transmits copied, intercepted packets to the distributor 3020 while continuing to intercept subsequent packets from the presentation layer protocol data stream 208.
In some embodiments, the recorder 3010 determines whether to copy a packet as described above in connection with FIG. 2. In other embodiments, upon completion of the transmission of the presentation layer protocol data stream 208 from the server 106 to the client 102, the recorder 3010 generates a recording of the presentation layer protocol data stream 208 as described above in connection with FIG. 2.
The distributor 3020 transmits a copy of at least one packet of the presentation layer protocol data stream 208. In one embodiment, the distributor further comprises a transceiver for retrieving a copy of the at least one packet. In another embodiment, the distributor further comprises a transceiver for transmitting a copy of the at least one packet to the protocol engine.
Referring now to FIG. 30B, a block diagram depicts one embodiment in which the recorder 3010 stores a plurality of packets 3030 on a storage device 218. In this embodiment, the distributor 3020 retrieves the plurality of packets 3030 from the storage device 218 and forwards the plurality of packets 3030 to a protocol engine 502 on the playback device 514.
Referring now to FIG. 30C, a block diagram depicts one embodiment in which the recorder 3010, in communication with the distributor 3020, transmits the plurality of packets 3030 to the protocol engine 502. In some embodiments, the recorder 3010 receives an indication from the distributor 3020 of a request for real-time playback of a presentation layer protocol data stream. In one of these embodiments, the recorder 3010 forwards the plurality of packets 3030 directly to the protocol engine 502, responsive to the received indication of the request for real-time playback.
Referring now to FIG. 30D, a block diagram depicts one embodiment in which the recorder 3010 stores a plurality of packets 3030 on a storage device 218. In this embodiment, the recorder 3010 retrieves the plurality of packets 3030 from the storage device 218 and forwards the plurality of packets 3030 to a protocol engine 502 on the playback device 514.
Referring back to FIG. 30A, and in one embodiment, the distributor 3020 resides on the first device 106. In another embodiment, the distributor 3020 resides on the second device 102. In still another embodiment, the distributor 3020 resides on a third device 222. In yet another embodiment, the distributor 3020 resides on a proxy server.
In one embodiment, the distributor 3020 is part of a remote presentation protocol server engine 204, as described above in connection with FIG. 2. In another embodiment, the distributor 3020 resides on a recording server, such as a third device 222. In still another embodiment, the distributor 3020 is in communication with the recorder 3010.
In one embodiment, the distributor 3020 is located on a passthrough server. In another embodiment, the distributor 3020 is located on a network packet sniffer. In still another embodiment, the distributor 3020 is located on a network appliance, application gateway, application acceleration appliance or other appliance. In some embodiments, the distributor 3020 resides on the same device as the recorder 3010.
In some embodiments, the system includes a third device 222. In one of these embodiments, the third device 222 is referred to as a log server. In another of these embodiments, the distributor 3020 resides on the log server. In still another of these embodiments, the log server stores pluralities of packets copied from intercepted presentation layer protocol data streams and recordings of presentation layer protocol data streams. In yet another of these embodiments, the log server provides functionality for coordinating the distribution of pluralities of packets copied from intercepted presentation layer protocol data streams and of recordings of presentation layer protocol data streams from the recorder 3010 to a playback device.
In some embodiments, the system includes a playback device 514, which provides the functionality of the playback device 514 described above in connection with FIG. 5. In other embodiments, the playback device 514 and the protocol engine 502 provide the functionality described above in connection with FIG. 5, and, in addition to regenerating display data from completed recordings of presentation layer protocol data streams, also provide the ability to regenerate display data associated with a plurality of packets and portions of incomplete presentation layer protocol data streams.
In some embodiments, the distributor 3020 is in communication with the playback device 514. In one of these embodiments, the distributor 3020 provides a catalog of presentation layer protocol data streams. In another of these embodiments, the distributor 3020 provides an enumeration of presentation layer protocol data streams available for viewing by the playback device 514. In still another of these embodiments, the distributor 3020 provides searching functionality, allowing the playback device 514 to search for particular presentation layer protocol data streams. In yet another of these embodiments, the distributor 3020 transmits a recorded presentation layer protocol data stream to the playback device 514.
In one embodiment, a playback device 514 requests an enumeration of presentation layer protocol data streams available for displaying to a user of the playback device 514. In another embodiment, the playback device 514 transmits the request to a distributor 3020. In still another embodiment, the playback device 514 transmits the request to a recording server, such as the third device 222. In yet another embodiment, the playback device 514 comprises a protocol engine 502.
In one embodiment, the distributor 3020 consults a catalog of available presentation layer protocol data streams. In another embodiment, the distributor 3020 generates an enumeration of available presentation layer protocol data streams responsive to the received request. In still another embodiment, the distributor 3020 transmits an enumeration of available presentation layer protocol data streams to the playback device 514.
In some embodiments, the enumeration identifies completely recorded presentation layer protocol data streams. In other embodiments, the enumeration identifies presentation layer protocol data streams for which the recorder 3010 has not completed the recording process. For example, the recorder 3010 may not have completed the process of adding packets to the presentation layer protocol data stream at the time that the identification of the presentation layer protocol data stream is provided to the playback device 514. In one of these embodiments, the recorder 3010 may add additional packets to the plurality of copied packets of the presentation layer protocol data stream after the playback device 514 accesses a packet already copied into the presentation layer protocol data stream. In still other embodiments, upon receiving the enumeration, the playback device 514 requests an enumerated presentation layer protocol data stream that is still in the process of being recorded.
In one embodiment, the recorder 3010 intercepts a presentation layer protocol data stream comprising a plurality of packets. In another embodiment, the distributor 3020 transmits a copy of at least one intercepted packet from the presentation layer protocol data stream to the playback device 514. In still another embodiment, a protocol engine 502 on the playback device 514 uses information associated with the at least one copied packet to regenerate the display data represented by the presentation layer protocol data stream. In yet another embodiment, the recorder 3010 intercepts a second packet and the distributor 3020 transmits a copy of the second packet to the playback device 514. In a further embodiment, the playback device 514 uses information associated with the second copied packet to regenerate additional display data represented by the protocol data stream. In some embodiments, the steps of intercepting packets and transmitting copies of the intercepted packets for display by the playback device 514 continues until the playback device 514 receives all of the packets in the presentation layer protocol data stream.
In one embodiment, the third device 222 writes many simultaneous presentation layer protocol session recordings to disk simultaneously, updates a catalogue database and serves files out for playback. In another embodiment, the recorder 3010 resides on the third device 222. In still another embodiment, the third device 222 receives copied packets from presentation layer protocol data streams that the recorder 3010 forwards to the third device 222. In some embodiments, the third device 222 is referred to as a “log server” or a “recording server”.
In one embodiment, to support simultaneous recording and playback of any particular session file, the file format must support being played without being complete. In some embodiments, an incomplete file, possibly incomplete due to loss of data or because the session is still in progress, is always capable of being played. In one of these embodiments, however, the file does not contain a digital signature. In another of these embodiments, a digital signature is calculated by the third device 222 when the recording is complete. In still another of these embodiments, the file format is modified to support the use of the empty packet described below. In yet another embodiment, no file format modifications occur.
In one embodiment, the third device 222 provides the ability to locate a file, based on data held in the catalogue database. In one embodiment, a database entry for each recording in the catalogue database is updated three times in order: when the file is created, when the session metadata becomes known (such as when the end user has successfully logged on) and when the recording ends.
In one embodiment, a file is created when a presentation layer protocol data stream starts. In another embodiment, a file is created when a privileged third-party, such as an administrator, requests the initiation of a recording. In some embodiments, when a first file containing a first portion of a recording of a presentation layer protocol data stream exceeds a threshold, the first file closes and a second file is created, the second file containing a second portion of the recording of the presentation layer protocol data stream. In one of these embodiments, when the first file exceeds a size limit, the first file exceeds the threshold. In another of these embodiments, when the first file stores a portion of a recording exceeding a limit on a length of time of the recording, the first file exceeds the threshold. In still another of these embodiments, the process of closing a first file that stores a first portion of a recording and that exceeds a threshold and creating a second file to store a second portion of the recording is referred to as “rollover.” In yet another of these embodiments, the underlying session being recorded continues unaffected and no recorded data is lost in the transition of files.
In some embodiments, a recording ends when a user whose session is being recorded disconnects. In other embodiments, a recording ends during the process of rollover. In still other embodiments, a recording ends when a privileged third-party, such as an administrator, requests the termination of a recording.
In some embodiments, only database records that have had all three updates may be searched; the file has to be complete to be searched. In other embodiments, methods and systems allow searching of records that have less than all updates. In one of these embodiments, only the first two updates are required for a record to be searchable. This means the file is available for search and download early in the session recording when the metadata becomes known. In some of these embodiments, a recording is searchable when a file is created. In others of these embodiments, however, a determination is made that a file is not available before metadata is identified because the information about the recording only has value for a logged-on session.
In one embodiment, the third device 222 tracks all live session recordings sent to playback devices 514, and continues to stream data to playback devices 514 as more data becomes available. In another embodiment, the third device 222 provides a tracking functionality that also supports the “poll” message for informing the presentation servers of live players as discussed below.
In some embodiments, functionality for transmitting a packet in a presentation layer protocol data stream prior to the completion of a process for adding packets to a recording of the presentation layer protocol data stream enables a user of the playback device 514 to view display data represented by the packet during the recording of a presentation layer protocol data stream. In one of these embodiments, this functionality enables a user to watch the display data live, while it is being created and recorded. In another of these embodiments, there may be a delay between the time of interception of a packet and a time of regeneration of display data represented by the packet. In still another of these embodiments, the delay is imperceptible to the viewer of the regenerated display data.
In some embodiments, the transmission of intercepted packets prior to the completion of a transmission of the original presentation layer protocol data stream 208 enables a playback device to display the packets as they are generated. In one of these embodiments, this provides a viewer of regenerated intercepted packets with real-time viewing of the presentation layer protocol data stream. In another of these embodiments, a plurality of intercepted packets may be buffered prior to transmission. However, in some of these embodiments, although the plurality of packets is buffered, they are still transmitted to a playback device prior to the complete transmission of a presentation layer protocol data stream, providing the impression of real-time, or near-real-time playback.
The protocol engine 502 uses the information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet. The recorder 3010 continues intercepting the presentation layer protocol data stream and the distributor continues transmitting copies of packets from the presentation layer protocol data stream until the first device completes transmission of the protocol data stream to the second device.
Referring now to FIG. 31, a flow diagram depicts one embodiment of the steps taken in a method for recording and real-time playback of presentation layer protocol data streams. In brief overview, a recorder intercepts a presentation layer protocol data stream comprising a plurality of packets, during transmission of the presentation layer protocol data stream from a first device to a second device, the presentation layer protocol data stream representing display data (step 3102). A distributor transmits a copy of at least one packet of the presentation layer protocol data stream (step 3104). A protocol engine uses information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet (step 3106). The steps of intercepting the presentation layer protocol data stream and of transmitting a copy of at least one packet of the presentation layer protocol data stream repeat until the first device completes transmission of the protocol data stream to the second device (step 3108).
Referring now to FIG. 31, and in greater detail, a recorder intercepts a presentation layer protocol data stream comprising a plurality of packets, during transmission of the presentation layer protocol data stream from a first device to a second device, the presentation layer protocol data stream representing display data (step 3102). In one embodiment, the recorder 3010 intercepts the presentation layer protocol data stream at substantially the same time as the first device transmits the presentation layer protocol data stream to the second device. In another embodiment, the recorder intercepts a virtual channel.
In some embodiments, the recorder 3010 determines whether to copy a packet as described above in connection with FIG. 2. In other embodiments, upon completion of the transmission of the presentation layer protocol data stream 208 from the server 106 to the client 102, the recorder 3010 generates a recording of the presentation layer protocol data stream 208 as described above in connection with FIG. 2. In one of these embodiments the recorder 3010 stores a recording of the presentation layer protocol data stream. In still other embodiments, the recorder 3010 associates information with copied packets or embeds information into the copied portions of the presentation layer protocol data stream as described above in connection with FIG. 2.
In one embodiment, a recorder 3010 associated with, or residing on, a third device 222 may capture various data transmitted over virtual channels and presentation layer packets (including optimization and acceleration metadata and mouse and keyboard packets) from the presentation layer stack in kernel mode. To reduce the computing and network overhead of sending many small messages to the third device 222, in some embodiments the recorder 3010 may buffer the data locally for each session. When the recorder 3010 captures sufficient data to form a large enough message, or when a timeout period expired (in the order of minutes), the recorder 3010 may forward the data to a storage component. The approach provides the system with excellent utilization of resources.
Although some embodiments provide the type of buffering described above, for the reasons described above, in one embodiment, methods and systems supporting live or time-shifted playback needs to forward data to a playback device 514 immediately. If the data is held back for a length of time exceeding a threshold, the playback experience will suffer, as the stream is not continuous or up-to-date. Data may arrive at the playback device 514 at irregular and infrequent intervals. Some of the data received might be in the order of minutes old.
In some embodiments, a system removes the buffering functionality for all recording sessions. However, for sessions that are not watched live or time-shifted, this approach may decrease performance and scalability and may be considerably more wasteful of resources, such as the utilization of available network bandwidth.
In other embodiments, buffering functionality is provided for playback of previously recorded sessions and not for sessions that are actually being viewed live. In one of these embodiments, when a playback device 514 starts playback of a live session, the recorder 3010 receives a notification of this event and switches off the buffering mechanism accordingly. In another of these embodiments, when playback is complete, the recording of a subsequent session at the presentation server will be returned to normal buffering mode. This approach means scalability is only affected for the time the player is actually playing a recording. The impact will also only be on the presentation server hosting the session; other servers in the farm are not affected.
To further protect scalability, in still other embodiments, streaming of live sessions data may be slightly throttled. Instead of sending all received data immediately, the data is buffered, but only for a very short period of time. In one of these embodiments, the time is predetermined. In another of these embodiments, the buffering time period is less than one second. In still another of these embodiments, 500 milliseconds is selected, resulting in only transmission of only two network messages per second.
In one embodiment, methods and systems described herein address a problem created by the asynchronous nature of a presentation layer protocol data session, and idle time within a session. In another embodiment, when a session is idle, no data is streamed from a server 106 to a client 102, and therefore no data is intercepted, recorded, or forwarded for playback. In still another embodiment, without a regular stream of data, the playback device 514 cannot determine if it can extend its timeline to reflect that this time has past. One problem created by concluding that time has passed with no activity and reflecting that in an indication to a viewer of the data stream arises when session activity data for a time in the past arrives. That is, the playback device 514 receives no data, concludes that no activity occurred, indicates to the viewer that no activity occurred, and then displays data reflecting that activity did actually occur at a point in time in the past after indicating that no activity occurred at that time. Essentially, the playback device 514 has wrongly assumed that “nothing” has happened and has progressed the current player frame too far. This may lead to a viewer of the recorded session missing activity that occurred in the past or in confusion for the viewer of the recorded session.
In one embodiment, the playback device 514 determines that session data has arrived for a point in time in the past, indicating this to a viewer, and forces the viewer to return to the point in time when the session activity occurred. In some embodiments, this solution creates additional problems, including usability issues if the section of the recording is lengthy, or if the type of session activity is not significant to the viewer.
In another embodiment, a packet is transmitted to the playback device 514 indicating that at a particular point in time, no session activity occurred and there is no session data to transmit to the playback device 514. In still another embodiment, a packet type referred to as an “empty packet” is created and transmitted to the playback device 514. In yet another embodiment, the empty packet holds a time stamp like all other packets but contains no payload. If a session being recorded has had no presentation layer protocol data received within its buffering time period (for example, a 500 millisecond interval mentioned earlier), the recorder 3010 will inject an empty packet into the stream. In some embodiments, as with the data buffering approach, empty packets will only be injected for as long as time-shifted playback is active.
In these embodiments, the playback device 514 now receives a steady stream of empty packets and can safely extend its time line and allow playback into “known” idle periods.
In some of these embodiments, the transmission of empty packets results in additional overhead, such as a slight increase in the recorded file size or some resource usage even when the session is idle. However, in one of these embodiments, an empty packet is between 4 and 6 bytes in length (typically 5 bytes) and only two are sent per second. Assuming 5 byte packets, this equates to an extra 36 KB per hour per session. In some embodiments, due to the infrequency of live playback and compared to the typical overall data rate of 2 MB per hour per session, this extra overhead may be deemed insignificant.
In one embodiment, a recorder 3010 executes on a presentation server to intercept and record presentation layer protocol data. In another embodiment, the recorder 3010 receives an indication that user has requested time-shifted playback of a session the recorder 3010 is currently recording. In still another embodiment, the receipt of the indication indicates to the recorder 3010 that it should use functionality required to provide time-shifting. For example, the recorder 3010 may buffer packets for transmission until it receives a notification of a live viewing, and then, upon receipt of the indication, switch to a mode where it decreases the amount of time for which it buffers the packet. In another example, the recorder 3010 does not use the empty packets described above until it receives an indication that a user has requested time-shifted session playback.
In some embodiments, various methods are available for notifying the recorder 3010 that a playback device 514 is playing a session for a viewer while the recorder 3010 records the session. In terms of supporting the notification of live playback sessions, it may be considered inappropriate to open new network ports on each server on which a recording component resides to support this requirement. Instead of the third device 222 (which is aware of all sessions being played live) notifying each presentation server directly, in some embodiments, the methods and systems implement a reverse poll mechanism. Each presentation server will “poll” the third device 222 at uniform intervals for the list of sessions currently being played live. In some of these embodiments, this mechanism is preferred to others even though polling may have a greater overhead or be less responsive than asynchronous notification.
Polling requires no listening ports on the presentation server, but does raise the issue of how frequently to poll. In some embodiments, short intervals are used to ensure that the live session's buffering can be switched promptly although the interval may affect scalability. In other embodiments, long intervals have low resource impact but can lead to a lag in switching buffering modes. In still other embodiments, a predetermined time interval is selected by an administrator. In yet other embodiments, a polling interval of 10 seconds provides compromise between a short interval and a long interval. In one of these embodiments, the impact of a polling interval is rarely perceptible since most recorded sessions already have existing data available for download and immediately playback. In one of these embodiments, having existing data available for immediate playback gives the user time to orientate themselves with what they are watching. In another of these embodiments, the polling interval has passed by the time the user has completed a viewing of the available data and requests more recently recorded content. In still another of these embodiments, where a user completes a viewing of available content prior to the completion of a polling interval, a short polling interval may be set, so that a user need wait only a few seconds. For example, in an embodiment with a polling interval is set to ten seconds, the user only need wait a maximum of 10 seconds (average 5 seconds) if they want to view the most recent few minutes of recording.
As an example, a system having 1000 presentation servers all actively recording equates to a single third device 222 having to process 100 poll messages per second. In such an embodiment, considering the small message size and low impact of processing each poll message, this is feasible from a system scalability perspective. In one embodiment, the processing of each poll message does not involve any I/O, complex computations, thread context switches or inter-process communication. In another embodiment, increasing the poll interval via configuration is also possible if required.
In some embodiments, the inclusion of the “poll” message has multiple purposes. In one of these embodiments, the poll message is also used as a “keep-alive” message for the third device 222. In another of these embodiments, the third device 222 is now capable of tracking which presentation servers are actively recording and how many sessions are currently being recorded.
A distributor transmits a copy of at least one packet of the presentation layer protocol data stream (step 3104). In one embodiment, the recorder stores a copy of the at least one packet of the presentation layer protocol data stream 208. In another embodiment, the recorder 3010 transmits at least one copied packet to the distributor 3020. In still another embodiment, the recorder 3010 stores the copy of the at least one packet in a buffer. In yet another embodiment, the recorder 3010 transmits a plurality of packets stored in the buffer to the distributor.
In one embodiment, the distributor 3020 retrieves the copy of the at least one packet of the presentation layer protocol data stream from a storage device. In another embodiment, the distributor 3020 retrieves the packet from a storage device, such as a storage 218 described above in connection with FIG. 2. In still another embodiment, the distributor receives the copy of the at least one packet from the recorder 3010.
A protocol engine uses information associated with the at least one copied packet to regenerate the display data represented by the at least one copied packet (step 3106). In one embodiment, the at least one copied packet is used upon receipt by the protocol engine of the at least one copied packet. In another embodiment, the at least one packet is used upon receiving by the protocol engine a request to regenerate the display data represented by the at least one copied packet.
The steps of intercepting the presentation layer protocol data stream and of transmitting a copy of at least one packet of the presentation layer protocol data stream repeat until the first device completes transmission of the protocol data stream to the second device (step 3108). In one embodiment, the step of using information associated with the at least one packet repeats until the protocol engine has regenerated display data represented by each received copied packets. In other embodiments, the protocol engine only regenerates display data for packets which a user has explicitly requested. In still other embodiments, the protocol engine starts and stops a regeneration of the display data upon receiving an indication of a request to start or to stop the regeneration.
In some embodiments, it is important to ensure that the end user is incapable of detecting that their session is being recorded or viewed live. In one embodiment, methods and systems providing time-shifted playback features prevent any additional opportunities for detecting recording of a presentation layer protocol data stream.
In one embodiment, playback of a presentation layer protocol session does not affect the running of a presentation layer protocol state machine. The stream of presentation layer protocol data that the end user receives is the same under live playback. This also implies there will be no visual and otherwise perceptible artifacts in their recording.
In another embodiment, where the end user does not have administrator rights on a server that is hosting their presentation session, no process or system object accessible indicates to the end user that they are being viewed live (or even being recorded). In still another embodiment, the end user is also restricted from issuing his or her own “poll” message to the third device 222 for finding list of live playback sessions. Even for local administrator users, this would be difficult as the session IDs returned from this poll message are not terminal session identifiers. In one embodiment, this comprises security by obfuscation because mapping these internal session identifiers to terminal session identifiers would require specialized skills.
In other embodiments, another method of detection includes observing periods of performance degradation. In one of these embodiments, however, even for a physical machine dedicated to a single user, this would difficult to perceive as the impact is so light. On a shared application server, this would be impossible. In these embodiments, the end user is denied access to viewing performance counters or similar performance related data.
In summary, in some embodiments, methods and systems for time-shifted playback ensure that the only feasible means for an end user with normal user privileges to detect live playback is to perform a social engineering attack.
In one embodiment, a playback device 514 transmits a search request to a third device 222. In another embodiment, the playback device 514 component searches an enumeration of sessions available for displaying to a viewer. In some embodiments, the enumeration includes only sessions where completed recordings of the sessions are available. In other embodiments, the enumeration includes only sessions where incomplete recordings of the sessions are available. In still other embodiments, the enumeration includes both sessions that are completely recorded and sessions that are incompletely recorded. In one of these embodiments, the playback device 514 includes functionality for distinguishing “live” recordings from “completed” recordings and makes this distinction apparent to the user in the search result list control. In another of these embodiments, as “live” recordings may become “complete”, the playback device 514 may periodically query the third device 222 for a status update of each live session listed. In still another embodiment, the search list remains in a refreshed state without user intervention.
In one embodiment, a user of a playback device 514 may select a stream of recorded data for viewing. In another embodiment, if the stream of recorded data contains data associated with a session which the recorder 3010 is still recording packets from the presentation layer protocol data stream, a channel is created and left open for receiving additional recorded data as it becomes available from the recorder 3010. In still another embodiment, as data is received by the third device 222 it will be forwarded to the playback device 514 for processing via the channel. In yet another embodiment, if the recorder 3010 completes recording a session complete while the session is being played live, the playback device 514 will close the channel and playback will continue uninterrupted.
In some embodiments, security-related concerns may arise from functionality providing live playback. For example, in some embodiments, live session files cannot be encrypted to preserve digital rights management (DRM) and there is no digital signature verification. To mitigate the DRM problem, in some of these embodiments, the playback device 514 will attempt to process live recordings from private memory only. In one of these embodiments, live recordings are not written to a local file cache and attempts are made to prevent data from being paged or otherwise written to a persistent storage device. In another of these embodiments, loss of data in transit is less of a concern when traffic between a playback device 514 and a third device 222 is SSL/TLS encrypted using strong encryption keys. To mitigate digital signature problems in others of these embodiments, a warning message will be displayed to the user before playback commences that the source and contents of the file cannot be verified. If users wish to obtain this statement of authenticity, they can re-download the session recording when it is complete. In many embodiments, this provides a reasonable compromise as digital signatures provide legal or forensic value to the recordings.
In one embodiment, when a player window is active, a seeker bar time-line will be extended when new data is received and this new content will be immediately available for viewing. In some embodiments, playback device 514 features remain available, including a background processing engine that generates key-frames for fast seeking. Functionality for seeking around a live recording is provided.
Referring now to FIG. 32, a flow diagram depicts one embodiment of the steps taken in a method for real-time seeking during real-time playback of remote presentation layer protocol data. In brief overview, a foreground protocol engine receives a request for rendering the contents of a packet in a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received (step 3202). The foreground protocol engine identifies a state-snapshot having an associate timestamp previous to that of the requested packet (step 3204). The foreground protocol engine displays, during transmission of the presentation layer protocol data stream from a first device to a second device, the requested packet responsive to the identified state-snapshot (step 3206).
In some embodiments, the received request results when the foreground protocol engine 1106 regenerates display data by rendering the contents of a packet in a first plurality of packets to a viewer using the display 1108 and the viewer wishes to seek for a particular display data. In other embodiments, the foreground protocol engine renders to a buffer the contents of an intermediate packet between the state-snapshot and the requested packet.
As described above in connection with FIG. 11, in some embodiments a recipient of rendered display data may seek for content in real-time. However, in some embodiments, as depicted by FIG. 32, the recipient of the rendered data may seek for content in real-time during the presentation of a packet from a presentation layer protocol data stream which has not been completely recorded. In one of these embodiments, the foreground protocol engine comprises a foreground protocol engine 1106 and provides real-time seeking functionality as described in connection with FIG. 11. In another of these embodiments, the foreground protocol engine 1106 also provides the above-described functionality for real-time seeking of portions of presentation layer protocol data streams, such as a first plurality of received packets, which comprise a subset of the presentation layer protocol data stream. In some embodiments, the foreground protocol engine 1106 generates, during transmission of the presentation layer protocol data stream from a first device to a second device, a real-time perceptible representation of a first plurality of packets received for presentation to a viewer using the display 1108. In other embodiments, the foreground protocol engine 1106 generates the real-time perceptible representation by rendering the contents of at least one packet in the protocol data stream 1110 or in the plurality of received packets. The perceptible representation may include, without limitation, separately or together, audio, visual, tactile, or olfactory presentations. In still other embodiments, the foreground protocol engine 1106 provides the functionality for real-time seeking amongst the first plurality of packets similar to the functionality for real-time seeking in a recorded protocol stream, as described above in connection with FIG. 9.
As described above in connection with FIG. 11, in some embodiments, state-snapshots enable regeneration of display data by storing a state of a protocol engine rendering presentation layer protocol data at a point in time when a recorder 206 copied at least one packet from the presentation layer protocol data stream 208. In one embodiment, the state-snapshot comprises a data structure describing a state of a screen at a point in time.
Referring now to FIG. 33, a flow diagram depicts one embodiment of the steps taken in a method for generating state-snapshots enabling real-time seeking during real-time playback of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine. The background protocol engine receives a first plurality of packets during transmission of the presentation layer protocol data stream from a first device to a second device (step 3302). The background protocol engine regenerates display data represented by the first plurality of packet (step 3304). The background protocol engine generates at least one state-snapshot during a reading of at least one packet in the first plurality of packets (step 3306). The background protocol engine stores the generated state-snapshot (step 3308). The regeneration of the display data and the at least one state-snapshot are modified responsive to receiving at least one packet in the second plurality of packets (step 3310).
The background protocol engine receives a first plurality of packets during transmission of the presentation layer protocol data stream from a first device to a second device (step 3302). The background protocol engine generates a representation of the first plurality of packets. In one embodiment, the background protocol engine 1102 generates a representation of the first plurality of packets by rendering the contents of the first plurality of packets to a buffer. In some embodiments, the buffer is an off-screen buffer.
The background protocol engine generates display data represented by the first plurality of packets (step 3304). In one embodiment, the background protocol generates display data by rendering the contents of the first plurality of packets to a buffer. In some embodiments, the buffer is an off-screen buffer.
In some embodiments, the foreground protocol engine generates the display data. In one of these embodiments, the foreground protocol engine 1106 generates a human-perceptible representation of the first plurality of packets by rendering the contents of the first plurality of packets substantially simultaneously with the background protocol engine 1102 generating at least one state-snapshot during its reading of the first plurality of packets.
The background protocol engine generates at least one state-snapshot during a reading of at least one packet in the first plurality of packets (step 3306). In one embodiment, the generation of the at least one state-snapshot occurs substantially simultaneously with a presentation of the first plurality of packets. In another embodiment, the generation of the at least one state-snapshot occurs during a sequential reading of the first plurality of packets by the background protocol engine.
The background protocol engine stores the generated state-snapshot (step 3308). In embodiments where the background protocol engine 1102 generates multiple state-snapshots periodically, the state-snapshots may act as markers throughout the first plurality of packets, assisting in the location of a particular point in time in the first plurality of packets and of the packets that come before or after the state-snapshot 1104.
The generation of the display data and the at least one state-snapshot are modified, responsive to receiving at least one packet in the second plurality of packets (step 3310). In some embodiments, the background protocol engine receives a packet from the second plurality of packets—a previously un-received packet—and stores the packet from the second plurality of packets in the first plurality of packets. In one of these embodiments, the background protocol engine stores newly-received packets in a buffer with previously-received packets. In another of these embodiments, the modification to the first plurality of packets results in a modification or regeneration of the generated display data, or in the regeneration of additional display data. In still another of these embodiments, the addition of the packet from the second plurality of packets to the first plurality of packets results in a modification of a state-snapshot, or in the generation of additional state-snapshots.
In some embodiments, the background protocol engine generates the state-snapshots for the first plurality of packets using methods for generating state-snapshots for recorded protocol data streams described above. In other embodiments, the foreground protocol engine regenerates display data represented by the first plurality of packets using methods for regenerating display data represented by packets in recorded protocol data streams as described above.
Referring again to FIG. 11, system for real-time seeking during real-time playback of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine includes a background protocol engine 1102, a state-snapshot 1104, a foreground protocol engine 1106, and a protocol data stream 1110.
The background protocol engine receives the first plurality of packets during transmission of the presentation layer protocol data stream from a first device to a second device. The state-snapshot, generated by the background protocol engine, comprises a state of a protocol engine rendering the presentation layer protocol data stream at a point in time when a recorder, such as the recorder 3010, copied a packet from the presentation layer protocol data stream into the first plurality of packets. The foreground protocol engine receives the first plurality of packets, renders the contents of the first plurality of packets, receives a request to seek display data represented by a content in a packet in the first plurality of packets, and renders the content representing the requested display data using the state-snapshot. In one embodiment, the foreground protocol engine renders the requested display data during transmission of the presentation layer protocol data stream from a first device, such as a server 106, to a second device, such as a client 102. The background protocol engine updates the state-snapshot responsive to receiving at least one packet in the second plurality of packets.
Although described in connection with FIG. 11 as a completely recorded protocol data stream, protocol data stream 1110, in some embodiments, comprises a portion of a second protocol data stream. In one of these embodiments, the protocol data stream 1110 is a first plurality of packets representing display data and with which metadata has been associated and into which additional information has been embedded. In another of these embodiments, as additional packets are received from the recorder 206, or the distributor 3020, the background protocol engine adds those packets to the protocol data stream 1110. In still another of these embodiments, the system described in FIG. 11 provides functionality for real-time seeking during real-time playback by using a portion of a protocol data stream, such as the first plurality of packets, in a substantially similar manner to the ways in which the system provides functionality for real-time seeking during playback of a completely recorded protocol data stream.
Referring now to FIG. 34, a flow diagram depicts one embodiment of the steps taken in a method for adaptive generation of state-snapshots. A user is presented with a representation of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine during transmission of the presentation layer protocol data stream from a first device to a second device (step 3402). The background protocol engine monitors an activity of the user during the presentation (step 3404). The background protocol engine develops an activity profile, responsive to the monitoring of the activity (step 3406). The background protocol engine generates at least one state-snapshot, responsive to the activity profile (step 3408). The background protocol engine modifies the at least one state-snapshot, responsive to receiving at least one packet in the second plurality of packets (step 3410).
In some embodiments, the steps taken for adaptive generation of state-snapshots described above in connection with FIGS. 12 through 15 are used with a portion of a protocol data, such as the first plurality of packets.
A user is presented with a representation of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine during transmission of the presentation layer protocol data stream from a first device to a second device (step 3402). In one embodiment, as the background protocol engine receives packets from the second plurality of packets, the background protocol engine stores the newly-received packets in the first plurality of packets. In another embodiment, the background protocol engine continues to receive packets from the second plurality of packets until a server ceases transmission of a presentation layer protocol data stream to a client.
The background protocol engine monitors an activity of the user during the presentation (step 3404). In one embodiment, the foreground protocol engine 1106 generates the representation of the first plurality of packets and presents it to the user with the display 1108. In other embodiments, the background protocol engine 1102 generates the representation. In still other embodiments, a third device generates the representation. In one embodiment, the background protocol engine monitors an activity of a user during presentation of a portion of a session, such as during the presentation of regenerated display data represented by a first plurality of packets.
The background protocol engine develops an activity profile, responsive to the monitoring of the activity (step 3406). In some embodiments, the background protocol engine 1102 identifies a level of activity of the user. In some embodiments, the background protocol engine 1102 identifies a period of inactivity. In other embodiments, the background protocol engine 1102 identifies an area of interest to the user in the display data. The activity profile may reflect these identifications.
The background protocol engine generates at least one state-snapshot, responsive to the activity profile (step 3408). In some embodiments, the background protocol engine 1102 determines to extend an interval between one or more state-snapshots. In other embodiments, the background protocol engine 1102 determines to reduce an interval between one or more state-snapshots. In still other embodiments, the background protocol engine 1102 determines to remove the at least one state-snapshot, responsive to the activity profile. In still other embodiments, the background protocol engine 1102 determines to add at least one state-snapshot, responsive to the activity profile.
The background protocol engine modifies the at least one state-snapshot, responsive to receiving at least one packet in the second plurality of packets (step 3410). In some embodiments, the background protocol engine revises an identification of an activity level responsive to receiving at least one packet in the second plurality of packets. In one of these embodiments, a viewer of a first portion of a presentation layer protocol data stream modifies his or her activity level when watching a different portion of the presentation layer protocol data stream. In another of these embodiments, the background protocol engine observes modifications in activity levels or and modifies, or regenerates, state-snapshots accordingly.
As described above, FIG. 16 summarizes one embodiment of the method 1600 discussed above used in a system for adaptive generation of state-snapshots, including a background protocol engine 1602, a foreground protocol engine 1608, a protocol data stream 1612, an activity profile 1604, and a state-snapshot 1606. In another embodiment, the system described above also provides adaptive generation of state-snapshots during real-time playback of a presentation layer protocol data stream.
The foreground protocol engine, presents, to a user, a representation of a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine during transmission of the presentation layer protocol data stream from a first device to a second device. The background protocol engine monitors an activity of the user during the presentation and generates a state-snapshot. The background protocol engine determines an activity profile. The background protocol engine modifies the state-snapshot and the activity profile responsive to receiving at least one packet in the second plurality of packets
In one embodiment, the background protocol engine determines the activity profile responsive to the monitoring. In another embodiment, the background protocol engine maintains the state-snapshot responsive to the activity profile. In still another embodiment, the background protocol engine updates a state-snapshot responsive to an observed change in an activity profile.
In some embodiments, the background protocol engine observes a modification to an activity profile. In one of these embodiments, an activity profile varies between the viewing of a first portion of a presentation layer protocol data stream and the viewing of a second portion of the presentation layer protocol data stream. In another of these embodiments, the background protocol engine maintains an updated activity profile and generates new state-snapshots, or modifies existing state-snapshots accordingly.
As described above in connection with FIGS. 17 and 18, in some embodiments, playback data structures may be used in playback of recorded protocol data streams. Additionally, in other embodiments, playback data structures may be used in real-time playback of presentation layer protocol data streams. A method for generating playback instructions for playback of a presentation layer protocol data stream comprising a first plurality of packets already received by a protocol engine and a second plurality of packets yet to be received by the protocol engine during transmission of a presentation layer protocol data stream includes the step of receiving, by the protocol engine executing on a playback device, the first plurality of packets representing display data generated by an application program executed on a server. The protocol engine determines, for a packet in the first plurality of packets, to render the contents of the packet in a human-perceptible manner. The protocol engine stores the determination in a playback data structure.
In some embodiments, the protocol engine determines to display a packet in the first plurality of packets responsive to the contents of the packet. In one of these embodiments, the protocol engine makes the determination responsive to an indication of an application program having input focus. In another of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of user input stored in the packet. In some of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of graphics update stored by the packet. In others of these embodiments, the protocol engine makes the determination responsive to an evaluation of a type of interaction sequence stored by the packet.
In some embodiments, a playback data structure describes how to regenerate the display data contained within the first plurality of packets. In one embodiment, the instructions stored within the playback data structure control the process of rendering display data. In one embodiment, the playback data structure comprises a time for rendering the contents of a packet in the first plurality of packets. In this embodiment, the time contained in the playback data structure is used for rendering the contents of the packet and not a time of rendering associated with the packet in the first plurality of packets, if any. In one embodiment, the playback data structure accepts user input in changing the time of rendering.
In other embodiments, the playback data structure comprises metadata that describes how to perform one or more playbacks of a first plurality of packets. In one embodiment, the playback data structure consists of a record for each packet in the first plurality of packets, indicating at what relative point in time the contents of that packet should be rendered during playback. In some embodiments, the metadata also contains the offset within the file of the start of the packet.
In some embodiments, as the background protocol engine receives additional packets in the presentation layer protocol data stream, the background protocol engine generates additional playback data structures or modifies existing playback data structures.
In one embodiment, the background protocol engine executes on a playback device and generates a playback data structure in response to receiving a first plurality of packets, said first plurality of packets representing display data generated by an application program executed on a server. The foreground protocol engine receives the first plurality of packets and renders the first plurality of packets responsive to the playback data structure generated by the background protocol engine substantially concurrently with the background protocol engine receiving at least one packet in the second plurality of packets and generating a playback data structure in response to the received at least one packet in the second plurality of packets. In another aspect, the foreground protocol engine receives the first plurality of packets and renders the first plurality of packets responsive to the playback data structure generated by the background protocol engine substantially concurrently with the background protocol engine receiving a second in the first plurality of packets and generating a playback data structure in response to the received second packet in the first plurality of packets.
In one embodiment, the background protocol engine and the foreground protocol engine each receive the first plurality of packets. In another embodiment, the background protocol engine generates the playback data structure substantially simultaneously with the foreground protocol engine rendering the first plurality of packets.
In one embodiment, the background protocol engine stores in the playback data structure at least one instruction for rendering at least one packet in the first plurality of packets. In another embodiment, the background protocol engine stores metadata in the playback data structure. In still another embodiment, the background protocol engine stores in the playback data structure a record indicating a time to render at least one packet in the first plurality of packets.
The foreground protocol engine renders at least one packet in the first plurality of packets responsive to the playback data structure. In one embodiment, the foreground protocol engine renders at least one packet in the first plurality of packets in a human-perceptible manner and to a buffer. In another embodiment, the foreground protocol engine renders at least one packet in the first plurality of packets to a buffer.
In one embodiment, a background protocol engine receives a first plurality of packets representing display data generated by an application program executing on a server, during transmission, by the server, of the presentation layer protocol data stream to a client. The background protocol engine determines for at least one packet in the first plurality of packets, to render the packet in a human-perceptible manner. The background protocol engine stores the determination in a playback data structure. A foreground protocol engine retrieves at least one packet from the first plurality of packets, access the playback data structure, and renders the at least one packet responsive to the playback data structure. These steps repeat until the server completes transmission of the presentation layer protocol data stream. In one embodiment, the steps server stops transmission of the presentation layer protocol data stream prior to the complete transmission of the presentation layer protocol data stream. In another embodiment, a first plurality of packets in the presentation layer protocol data stream are intercepted and real-time playback of the first plurality of packets occurs while a second plurality of packets in the presentation layer protocol data stream is generated and transmitted by the server.
In some embodiments, the background protocol engine determines to display a packet in a first plurality of packets and generates a corresponding playback data structure as described above in connection with FIG. 19. In other embodiments, the foreground protocol engine renders the contents of a packet in the first plurality of packets responsive to the playback data structure as described above in connection with FIG. 19.
Referring back to FIG. 21, presentation layer protocol data streams may be rendered without perceptible intervals of time containing no activity. In some embodiments, as described above in connection with FIG. 21, a completed recording of a presentation layer protocol data stream is rendered. In other embodiments, however, the methods described above may be used to render portions of incompletely recorded presentation layer protocol data streams.
A method of eliminating a period of inactivity in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a first packet in the first plurality of packets, said first plurality of packets representing display data. A second packet in the first plurality of packets is identified, said second packet immediately preceding the first packet. A first time interval between the first packet and the second packet is determined. It is determined that the first time interval exceeds a threshold. During transmission of the protocol data stream from a server to a client, the contents of the first plurality of packets with a second time interval between the first packet and the second packet are rendered, said second time interval comprising a shorter time interval than the first time interval. At least one packet in the second plurality of packets is received.
In one embodiment, the at least one packet in the second plurality of packets is added to the first plurality of packets upon receipt. The steps of identifying the first packet and a second packet preceding the first packet and determining whether a time interval between the two exceeds a threshold are repeated for the received at least one packet in the second plurality of packets. In another embodiment, the steps of identifying the first packet and a second packet preceding the first packet and determining whether a time interval between the two exceeds a threshold are repeated for a second packet in the first plurality of packets. In some embodiments, the methods described above in connection with FIG. 21 are used to eliminate perceptible intervals of time with no activity from portions of presentation layer protocol data streams, such as the first plurality of packets.
A method of generating playback instructions for rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a type of input stored by a packet in the first plurality of packets representing display data generated by an application program. The packet is marked responsive to the type of input. A playback data structure stores a destination for rendering the contents of the packet responsive to the marking. At least one packet in the second plurality of packets is received. In one embodiment, the at least one packet in the second plurality of packets is added to the first plurality of packets upon receipt. A second packet in the first plurality of packets is received. The steps of identifying a type of input stored by a packet, marking the packet responsive to the type of input, storing the rendering destination in the playback data structure, and receiving additional packets repeat as new packets are received until a server completes transmission of the presentation layer protocol data stream.
In one embodiment, the type of input stored by a packet determines whether or not the packet will be rendered. In one embodiment, the packet contains no content. In some embodiments, at least one packet contains no content. In these embodiments, an interval of time comprised of at least one packet containing no content is identified. In some of these embodiments, the interval of time will not be rendered. In one of these embodiments, an empty packet type as described above in connection with FIGS. 30A-D and 31 is received and identified as a packet containing no data.
In some embodiments, the type of input refers to input from certain types of input devices, including, without limitation, a keyboard, a mouse, a microphone, or a camera. In one embodiment the step of identifying the type of input further comprises identifying the type of input as input from an input device. In another embodiment, the step of identifying the type of input further comprises identifying the type of input as keyboard input. In other embodiments, the type of input is not related to the input device. In one of these embodiments, the type of input is identified as a command.
In one embodiment, the method eliminates perceptible intervals of time containing no meaningful activity. In this embodiment, a policy identifies a particular type of input as meaningful or as insignificant. The policy may be hard coded into a protocol engine, in some embodiments. In other embodiments, an administrator configures the policy.
In some embodiments, a protocol engine identifies a packet as insignificant if the packet contains no content. In some of those embodiments, the packet represents an interval of time in which the no user activity occurred to be recorded into a packet in the first plurality of packets. In one of these embodiments, the protocol engine stores in a playback data structure a destination for rendering each of the plurality of packets in the first plurality of packets in such a way that any insignificant packet does not render in a perceptible manner. In another of these embodiments, the protocol engine may generate an indication that time has passed without activity. For example, a timeline of the presentation layer protocol data stream presented to a viewer may be updated to reflect that time has passed although no display data has changed. In still another of these embodiments, the protocol engine uses the empty packet type described above to identify a packet as insignificant.
In some embodiments, methods described above for eliminating periods of time containing no meaningful activity in recorded presentation layer protocol data streams are also used to eliminate periods of time containing no meaningful activity in portions of the presentation layer protocol data stream, such as the first plurality of packets. As in FIG. 22, which depicts one embodiment of a regenerated recorded stream whose contents are rendered responsive to a playback data structure, rendering portions of protocol data streams responsive to the playback data structure, in this embodiment, allows elimination of intervals of time containing no meaningful activity (depicted by the white and striped blocks in FIG. 22), which includes intervals of time containing no activity at all. This rendering provides a more meaningful regeneration of the first plurality of packets in the presentation layer protocol data stream to a user.
A method of eliminating a period containing no meaningful activity in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of determining a first time interval between a marked packet and a nearest previous marked packet in the first plurality of packets, said first plurality of packets representing display data. A determination is made that the first time interval exceeds a threshold. During transmission of the protocol data stream from a server to a client, the contents of the first plurality of packets are rendered with a second time interval between the marked packet and the nearest previous marked packet, said second time interval comprising a shorter time interval than the first time interval. At least one packet in the second plurality of packets may be received. A second packet in the first plurality of packets may be received. The newly received packets may be added to the first plurality of packets. The steps of determining that the first time interval exceeds a threshold and rendering the contents of the first plurality of packets with the second time interval is repeated until the server completes transmission of the presentation layer protocol data stream.
In one embodiment, the contents of the first plurality of packets are rendered with a second time interval between the marked packet and a previous packet said second time interval comprising a shorter time interval than the first time interval. In another embodiment, the contents of the first plurality of packets are rendered with a second time interval between the marked packet and a packet following the marked packet, said second time interval comprising a shorter time interval than the first time interval. In some embodiments, the contents of the first plurality of packets are rendered using the methods described above in connection with FIG. 28.
Methods for eliminating graphics updates in rendering recorded sessions, as described above in connection with FIG. 24, also eliminate graphics updates in rendering portions of sessions, for example, by removing graphics updates in a first plurality of packets comprising a subset of a presentation layer protocol data stream. As described in connection with FIG. 25, cyclic updates may be identified and a determination may be made not to render a cyclic update in a human-perceptible manner. Similarly, these methods may identify cyclic updates within portions of presentation layer protocol data streams.
A method of eliminating graphics updates in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a packet in the first plurality of packets, the first plurality of packets representing display data generated by an application program, the packet containing a first graphics update. A screen region affected by the first graphics update is determined. An indication of the state of the screen region after the first graphics update and the location of the screen region is stored. A second graphics update affecting the screen region within a time interval is identified. A playback data structure indicates a destination for rendering a second packet in the first plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update. A playback data structure indicates a time interval to render associated with the second packet in the first plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
In one embodiment a graphics update contained within a plurality of packets is identified. In another embodiment, the screen region affected responsive to the graphics update stored by each packet in the identified plurality of packets is determined. In still another embodiment, a copy of the screen region affected by the graphics update is stored. In yet another embodiment, a time interval is defined to approximate an upper limit of a human scale cyclic period. In a further embodiment, a playback data structure indicates that the contents of the packet render in a perceptible manner and to a buffer. In even still another embodiment, a playback data structure indicates that the contents of the packet render to a buffer. In some embodiments, the background protocol engine stores these indications in the playback data structure.
Another method for eliminating graphics updates in rendering a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying a packet in the first plurality of packets, the first plurality of packets representing display data generated by an application program, the packet containing a first graphics update. A screen region affected by the first graphics update is determined. An indication of the state of the screen region after the first graphics update and the location of the screen region is stored. A second graphics update affecting the screen region within a time interval is identified. A playback data structure indicates a destination for rendering a packet in the second plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update. A playback data structure indicates a time interval to render associated with the packet in the second plurality of packets containing the second graphic update affecting the screen region, responsive to whether the state of the screen region after the second graphics update varies from the state of the screen region after the first graphics update.
In one embodiment a graphics update contained within a plurality of packets is identified. In another embodiment, the screen region affected responsive to the graphics update stored by each packet in the identified plurality of packets is determined. In still another embodiment, a copy of the screen region affected by the graphics update is stored. In yet another embodiment, a time interval is defined to approximate an upper limit of a human scale cyclic period. In a further embodiment, a playback data structure indicates that the contents of the packet render in a perceptible manner and to a buffer. In even still another embodiment, a playback data structure indicates that the contents of the packet render to a buffer. In some embodiments, the background protocol engine stores these indications in the playback data structure.
As described in FIG. 26, methods for eliminating interaction sequences may be used with presentation layer protocol data streams. In some embodiments, described above, the methods are used with completed records of presentation layer protocol data streams. In other embodiments, however, the methods are used with portions of presentation layer protocol data streams, such as a first plurality of packets comprising a subset of packets in a presentation layer protocol data stream.
A method of eliminating interaction sequences in rendering presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying, responsive to a policy, a start of an interaction sequence represented by at least one packet in the first plurality of packets. A playback data structure indicates that the interaction sequence should render to a buffer. A termination of an interaction sequence is identified. A first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified. A playback data structure indicates a second time interval to render shorter than the first time interval.
Another method of eliminating interaction sequences in rendering presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the step of identifying, responsive to a policy, a start of an interaction sequence represented by at least one packet in the first plurality of packets. A playback data structure indicates that the interaction sequence should render to a buffer. A packet in the second plurality of packets is received. A termination of an interaction sequence represented by the received packet in the second plurality of packets is identified. A first time interval between a packet preceding the identified start of the interaction sequence and a packet following the identified termination of the interaction sequence is identified. A playback data structure indicates a second time interval to render shorter than the first time interval.
In one embodiment, the start of the interaction sequence is identified by identifying a visual marker. In one embodiment, a visual marker comprises a credentials window, displayed in the same way for all sessions. In another embodiment, a visual marker comprises a replacement of a credentials window by a blank screen and then by a desktop background. In one embodiment, a visual marker comprises the display of recognizable icons.
In some embodiments, a start of an interaction sequence is identified by determining a start time of an interaction sequence. In one of these embodiments, a component detects the start time of an event in an interaction sequence. In another of these embodiments, the component detects the start time of a logon sequence. In still others of these embodiments, the component detects the start time of a logoff sequence. In one embodiment, the identification of the start of the interaction sequence is responsive to identifying a window with an input focus.
In one embodiment, where an identified interaction sequence should not render perceptibly, the interaction sequence is rendered to a buffer. Rendering the interaction sequence to a buffer results in the interaction sequence being imperceptible to a user of the rendering. For embodiments where a policy or user categorized the interaction sequence as insignificant, this rendering results in the elimination of an insignificant interaction sequence.
In some embodiments, the termination of the interaction sequence is identified by identifying a visual marker. In other embodiments, a termination of an interaction sequence is identified by determining a termination time of the interaction sequence. In one of these embodiments, a component detects the termination time of an event in an interaction sequence. In another of these embodiments, the component detects the termination time of a logon sequence. In still others of these embodiments, the component detects the termination time of a logoff sequence. In another embodiment, identifying the termination of the interaction sequence is responsive to identifying a window with an input focus.
In some embodiments, an interaction sequence comprises use of an application. In one of these embodiments, a policy identifies interaction sequences comprising use of an application that should not render in a perceptible manner. In one embodiment, such applications include, without limitation, word processing documents.
In one of these embodiments, a start of an interaction sequence is identified by identifying an application having input focus. When the contents of a packet represent a window having focus, a determination is made as to the application responsible for the process that created the window. In one embodiment, the contents of the packet representing a window having focus include window notification messages indicating a change in input focus. If the responsible application identifies a start of an interaction sequence which should not render perceptibly, an indication is stored in a playback data structure to render the interaction sequence to a buffer. A termination of an interaction sequence is identified by identifying the acquisition of focus by a window owned by a process not associated with the application of the interaction sequence.
In one embodiment, a first time interval is associated with the interaction sequence. Perceptibly rendering the time interval associated with the interaction sequence in an embodiment where the interaction sequence itself does not render results in a period of time perceptible to a user of the rendering in which no display data renders and the user waits through the time interval before a rendering of the contents of a packet after the interaction sequence. One embodiment eliminates the time interval associated with the interaction sequence by rendering a shorter time interval in place of the original time interval.
In some embodiments, a protocol engine renders the contents of at least one packet in a first plurality of packets, providing to a user a regeneration of the first plurality of packets. In some of these embodiments, the protocol engine automatically varies the time intervals between rendering the contents of at least one packet, resulting in context-sensitive time-warped playback. In these embodiments, rendering approximates the ability of the user to comprehend the display data presented to the user. In one embodiment, the time intervals between rendering contents of packets increase when the protocol engine determines the display data represented by the contents of the packets to have an increased level of complexity or importance, as defined by a policy. In another embodiment, the time intervals between rendering contents of packets decrease when the protocol engine determines the display data represented by the contents of the packets to have a decreased level of complexity or importance, as defined by a policy. In these embodiments, the protocol engine approximates the ability of the user to comprehend the display data and renders the contents either more slowly to give the user time to comprehend the rendering or renders the contents faster when a user requires less comprehension time.
In some embodiments, described above in connection with FIG. 27, methods for rendering recorded computer sessions provide automatic time-warped playback. These methods may also provide automatic time-warped playback during rendering of real-time presentation layer protocol data streams, in which the recording of the session represented by the data stream is incomplete.
A method of automatic time-warped playback in real-time rendering a presentation layer protocol data stream comprising a first plurality of packets already received by a background protocol engine and a second plurality of packets yet to be received by the background protocol engine includes the step of receiving, by the background protocol engine, the first plurality of packets representing display data. The background protocol engine determines a measure of complexity represented by at least some of the packets in the first plurality of packets. The background protocol engine identifies an interval of time between the at least some of the packets in the first plurality of packets. The background protocol engine modifies the interval of time responsive to the measure of complexity represented by the at least some of the packets in the first plurality of packets in the recorded session. The background protocol engine stores, in a playback structure, the modified interval of time. A foreground protocol engine renders, during transmission of the presentation layer protocol stream from a first device to a second device, the first plurality of packets responsive to the playback data structure.
In some embodiments, the steps taken in the methods described in FIG. 27 are also taken to render, during transmission of the presentation layer protocol stream from a first device to a second device, the first plurality of packets, responsive to the playback data structure.
In some of these embodiments, the protocol engine determines the measure of complexity by identifying likely sequences of typing in keyboard input. In one embodiment, the protocol engine inspects at least one type of key involved to identify likely sequences of typing in keyboard input. In another embodiment, the protocol engine inspects a sequence of at least one glyph rendered to complete a heuristic approximation of likely sequences of typing in keyboard input.
In some of these embodiments, the protocol engine stores classifications of keys determined by characteristics of the key. Key characteristics include, without limitation printable or non-printable characters, white space, navigation keys, or function keys, and include combinations of characteristics. In one embodiment, a protocol engine determines that sections of input comprising printable characters and occasional navigation keys constitute normal typing, while sections with mostly non-visible keys do not constitute normal typing. In one embodiment, the protocol engine determines a measure of complexity responsive to the amount of white space identified. In this embodiment, the protocol engine comprises a definition of word processing indicating that a white space key appears on average approximately every 5-8 characters in typical typing patterns.
In one embodiment, the protocol engine uses the appearance of non-printable characters to determine the measure of complexity. In another embodiment, the protocol engine accesses the keystroke sequences to identify sequences of non-white space printable characters appearing close together in time. In this embodiment, the protocol engine comprises the capacity to compare the keystroke sequences to a dictionary to identify valid words and determine a measure of complexity relating to an ability of a user to comprehend valid words versus invalid words.
In another embodiment, the protocol engine determines that the contents of the packet contain commands to render glyphs. In this embodiment, the protocol engine uses the glyphs to determine whether the display data represents a user activity of typing. In this embodiment, if a glyph rendering rate approximates the keyboard input rate with a small delay, it is likely that keystrokes are directly resulting in glyphs, thus making it quite likely the user is typing. In one embodiment, the protocol engine correlates the keys entered with the glyphs produced. In another embodiment, the protocol engine determines the spatial sequence (left-to-right, right-to-left, etc.) of the rendered glyphs to determine that a user is typing. In one embodiment, the protocol engine makes the determination of the measure of complexity responsive to the result of analyzing the contents of the plurality of packets and identifying patterns and activities represented by the contents.
In other embodiments, the protocol engine makes the determination of the measure of complexity responsive to an identification of a type of mouse input. In one embodiment, the protocol engine determines that a mouse input representing a click of the mouse causes actions that may need a slower rendering rate to comprehend, especially if the clicks follow a sequence of typing. In another embodiment, the protocol engine determines that mouse input that does not represent a clicking of a mouse does not affect the ability of a user to comprehend display data, and thus does not affect the measure of complexity.
In other embodiments, the protocol engine makes the determination of the measure of complexity responsive to identifying a heuristic approximation of complexity of a graphics update. In one embodiment, the protocol engine identifies a heuristic approximation of complexity of a graphics update based upon, without limitation, the size of region(s) being updated, the size of the area of the region changed by the graphics commands, a historical frequency of updates to individual regions, cyclic graphics commands, number of graphics commands, frequency of graphics commands, time interval between adjacent packets whose contents contain graphics command, or the type of graphics update. In an embodiment where the protocol engine identifies a low measure of complexity for the graphics update, the protocol engine determines a low measure of complexity represented by the packets containing the graphics updates. In an embodiment where the protocol engine identifies a high measure of complexity for the graphics update, the protocol engine determines a high measure of complexity represented by the packets containing the graphics updates.
In an embodiment where at least some of the plurality of packets have content representing display data associated with a high measure of complexity, the protocol engine increases the interval of time between the packets to allow the user of the rendering increased time to comprehend the rendered display data. In another embodiment where at least some of the plurality of packets have content representing display data associated with a low measure of complexity, the protocol engine decreases the interval of time between the packets to reflect decreased amount of time the user requires to comprehend the rendered display data. In one embodiment, a user requires a different amount of time between the rendered contents of packets than the amount rendered by the protocol engine. In this embodiment, the user modifies the interval of time to reflect the amount of time the user requires to comprehend the rendered display data. In some embodiments, the protocol engine also identifies a time interval between the at least some of the plurality of packets and other packets in the plurality of packets, modifying the interval of time identified between those sets of packets.
In some embodiments, the protocol engine identifies a first marker associated with a packet in the first plurality of packets. In one embodiment, the packet comprises the marker. In another embodiment, the recorded session comprises the marker.
In one embodiment, a user of the rendering of the display data defines the marker. In another embodiment, the protocol engine defines the marker. In embodiments where the protocol engine identifies a marker, the protocol engine modifies the interval of time responsive to the first marker. In one embodiment, the protocol engine increases the interval of time providing the user of the rendering of the display data additional time for comprehending the contents of the packet associated with the first marker. In other embodiments, the protocol engine identifies a second marker in a second packet. In this embodiment, the protocol engine modifies the interval of time responsive to the distance between the first marker and the second marker. In this embodiment, the protocol engine provides increased time for comprehension of display data represented by contents of packets marked and decreased time for comprehension of data represented by contents of unmarked packets. In one embodiment, a user defines markers for display data of interest to the user and the protocol engine renders additional time for the display data of interest to the user and decreases time of rendering for display data not of interest to the user, as determined by the markers.
In one embodiment, the protocol engine identifies a first marker in the at least some of the plurality of packets, said marker indicating an initial packet in the at least some of the plurality of packets. The protocol engine modifies the interval of time responsive to the first marker. The protocol engine identifies a second marker in a second packet in the at least some of the plurality of packets, said second marker indicating a final packet in the at least some of the plurality of packets and modifying the interval of time responsive to the interval of time between the first marker and the second marker.
In one embodiment, the protocol engine also renders the plurality of packets responsive to the playback data structure instructions regarding modified time intervals. In another embodiment, a separate foreground protocol engine renders the plurality of packets.
In some embodiments, a determination is made that recorded interaction with an application requires increased time for rendering, to provide a user of the rendering increased time for comprehension of the rendered display data. In some of these embodiments, the determination is made that the application requiring increased time comprises a more important application than an application not requiring the increased time. In one of these embodiments, the user makes the determination. In another of these embodiments, a policy makes the determination. In still another of these embodiments, the protocol engine comprises a definition of applications that require increased time.
As described in connection with FIG. 28, a method may provide automatic time-warped playback responsive to an identified application in rendering a recorded computer session. Similarly, the method provide automatic time-warped playback responsive to an identified application in rendering a portion of an incompletely recorded presentation layer protocol data session, or of a presentation layer protocol data session in the process of being recorded.
A method of automatic time-warped playback in real-time rendering of a presentation layer protocol data stream comprising a first plurality of packets already received and a second plurality of packets yet to be received includes the steps of receiving the first plurality of packets representing display data. A first packet in the first plurality of packets having a content representing a window having focus is identified, said window indicating an application. A time interval between a second packet in the first plurality of packets whose contents render prior to the rendering of the content of the first packet and a third packet in the first plurality of packets whose contents render after the rendering of the content of the first packet is identified. The identified time interval is modified responsive to the indicated application. During transmission of the presentation layer protocol stream from a first device to a second device, at least one packet in the first plurality of packets is rendered responsive to the modification.
In one embodiment, the modification to the identified time interval includes an increase in the identified time interval. In another embodiment, the modification to the identified time interval includes a decrease to the identified time interval. In still another embodiment, the at least one packet in the first plurality of packets is rendered to a buffer. In yet another embodiment, the at least one packet in the first plurality of packets is rendered both to a buffer and in a perceptible manner.
As described above in connection with FIG. 29, systems may provide automatic time-warped playback in rendering recorded computer sessions. These systems may also provide automatic time-warped playback in rendering presentation layer protocol data streams comprising a first plurality of packets already received by a protocol engine and a second plurality of packets yet to be received by the protocol engine. A protocol engine, generating a playback data structure in response to receiving the first plurality of packets rendering, during transmission of the presentation layer protocol stream from a first device to a second device, at least one packet in the first plurality of packets responsive to the generated playback data structure.
In one embodiment, the protocol engine stores in the playback data structure at least one instruction for rendering the first plurality of packets. In another embodiment, the protocol engine stores metadata in the playback data structure. In still another embodiment, the protocol engine renders the at least one packet in the first plurality of packets in a perceptible manner and to a buffer. In yet another embodiment, the protocol engine renders the at least one packet in the first plurality of packets to a buffer. In a further embodiment, a second protocol engine renders the at least one packet in the first plurality of packets responsive to the generated playback data structure.
In some embodiments, a presentation refers to a server providing presentation layer protocol data to a client or to another server. In one of these embodiments, the server executes an application and provides generated application-output data to a client or another server. In another of these embodiments, the server provides access to presentation layer protocol data associated with, or created by, a resource, such as a plurality of applications, a desktop environment, or other computing environment. In still another of these embodiments, the server provides presentation layer protocol data for a session (such as an execution of a resource), the session executing within a virtual machine executing in a hypervisor executing in a remote desktop session executing on the server. In still another of these embodiments, a server executing a virtual machine providing access to a session transmits presentation layer protocol data to a second server executing a remote desktop session and forwarding the received data to a client. In yet another of these embodiments, the server provides presentation layer protocol data for a session executing within a virtual machine to a second server hosting a presentation layer protocol stack and forwarding the data to a client.
The ability to watch a presentation layer protocol session recording while it is still being recorded enhances systems and methods for playback of previously recorded sessions. It strengthens the position of such systems and methods as a market-leading monitoring and surveillance solution, and provides a significant gateway into the support/helpdesk market.
The systems and methods described above 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 compact disc, a digital versatile disc, 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++, 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 methods and systems for recording and real-time playback of presentation layer protocol data, 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.

Claims (18)

What is claimed is:
1. A method for searching the content of a recorded presentation layer protocol session, the method comprising:
intercepting, by a recorder, a plurality of packets sent from a server device to a client device;
storing the plurality of intercepted packets;
rendering, by a protocol engine, at least one stored packet in the plurality of stored packets to a local video buffer;
analyzing the at least one rendered packet, wherein analyzing includes at least scanning the at least one rendered packet with an optical character recognizer executing on a server;
using the optical character recognizer to generate a word associated with the at least one packet;
using a post processing component to generate identification data associated with the generated word associated with the at least one packet, the identified data indicating a position of the generated word in the plurality of packets; and
storing the generated word associated with the at least one packet and storing the identification data associated with the generated word in a database, to provide an index to the generated word and identified data in the database.
2. The method of claim 1, further comprising identifying, by the protocol engine, the at least one stored packet of the plurality of packets to be rendered to a local video buffer.
3. The method of claim 1, wherein the identification data generated by the post-processing component includes bounding rectangle information for the generated word associated with the at least one stored packet of the plurality of stored packets.
4. The method of claim 3, wherein the position of the generated word includes a time position, and wherein the identification data generated by the post-processing component includes the time position of the word associated with the at least one packet.
5. The method of claim 4, wherein the time position of the word comprises an initial time position of the word as well as a time duration of the word.
6. The method of claim 4, further comprising highlighting, by a video playing device, the generated word using the time position, spatial position, width, and height data associated with the at least one stored packet of the plurality of stored packets.
7. The method of claim 1, further comprising querying the database using a search engine with a target word matching the generated word.
8. The method of claim 7, further comprising marking packets associated with generated words that match the target word.
9. The method of claim 8, further comprising selectively transmitting data contained in the marked packets to a display device by a video playing device.
10. A system for searching the content of a recorded presentation layer protocol session, the system comprising:
a recorder configured to intercept a plurality of packets sent to a client device;
a storage device configured to store the plurality of packets sent to the client device;
a protocol engine, configured to render at least one stored packet in the plurality of stored packets to a local video buffer;
an optical character recognizer executing on a server configured to analyze the at least one rendered packet wherein analyzing includes at least scanning the at least one rendered packet to generate a word associated with the at least one packet;
a post processing component configured to generate identification data associated with the generated word associated with the at least one packet, the identified data indicating a position of the generated word in the plurality of packets; and
a database configured to store the generated word associated with the at least one packet and also configured to store the identification data associated with the generated word, to provide an index to the generated word and identified data in the database.
11. The system of claim 10, further comprising the protocol engine configured to identify the at least one stored packet of the plurality of packets to be rendered to a local video buffer.
12. The system of claim 10, wherein the identification data generated by the post-processing component includes bounding rectangle information for the generated word associated with the at least one stored packet of the plurality of stored packets.
13. The system of claim 12, wherein the position of the generated word includes a time position, and wherein the identification data generated by the post-processing component includes the time position of the word associated with the at least one packet.
14. The system of claim 13, wherein the time position of the word comprises an initial time position of the word as well as a time duration of the word.
15. The system of claim 13, further comprising a video playing device configured to highlight the generated word using the time position, spatial position, width, and height information associated with the at least one packet of the plurality of packets.
16. The system of claim 10, further comprising a search engine configured to query the database with a target word matching the generated word.
17. The system of claim 16, further comprising a protocol engine configured to mark packets associated with generated words that match the target word.
18. The system of claim 17, further comprising a video playing device configured to selectively transmit data contained in the marked packets to a display device.
US13/237,047 2011-09-20 2011-09-20 Methods and systems for cataloging text in a recorded session Active 2031-11-29 US8615159B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/237,047 US8615159B2 (en) 2011-09-20 2011-09-20 Methods and systems for cataloging text in a recorded session

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/237,047 US8615159B2 (en) 2011-09-20 2011-09-20 Methods and systems for cataloging text in a recorded session

Publications (2)

Publication Number Publication Date
US20130071085A1 US20130071085A1 (en) 2013-03-21
US8615159B2 true US8615159B2 (en) 2013-12-24

Family

ID=47880743

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/237,047 Active 2031-11-29 US8615159B2 (en) 2011-09-20 2011-09-20 Methods and systems for cataloging text in a recorded session

Country Status (1)

Country Link
US (1) US8615159B2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130336158A1 (en) * 2012-06-14 2013-12-19 James D. Conniff Apparatus, methods, and systems for character set surveying of network traffic
CN106686428A (en) * 2016-12-30 2017-05-17 广东欧珀移动通信有限公司 Video playing method and device

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9444564B2 (en) 2012-05-10 2016-09-13 Qualcomm Incorporated Selectively directing media feeds to a set of target user equipments
US9277013B2 (en) * 2012-05-10 2016-03-01 Qualcomm Incorporated Storing local session data at a user equipment and selectively transmitting group session data to group session targets based on dynamic playback relevance information
KR102122002B1 (en) 2012-07-19 2020-06-12 글랜스 네트웍스, 인크 Integrating co-browsing with other forms of information sharing
CN104283729A (en) * 2013-07-03 2015-01-14 钟丹晔 Kinescope recording system and working method thereof
US10122804B1 (en) * 2013-11-06 2018-11-06 Stackup Llc Calculating and recording user interaction times with selected web sites or application programs
US9762585B2 (en) 2015-03-19 2017-09-12 Microsoft Technology Licensing, Llc Tenant lockbox
US10931682B2 (en) 2015-06-30 2021-02-23 Microsoft Technology Licensing, Llc Privileged identity management
US11409791B2 (en) 2016-06-10 2022-08-09 Disney Enterprises, Inc. Joint heterogeneous language-vision embeddings for video tagging and search
US11245520B2 (en) * 2018-02-14 2022-02-08 Lucid Circuit, Inc. Systems and methods for generating identifying information based on semiconductor manufacturing process variations
US10755201B2 (en) 2018-02-14 2020-08-25 Lucid Circuit, Inc. Systems and methods for data collection and analysis at the edge
JP2021536047A (en) 2018-06-11 2021-12-23 ルシード サーキット,インコーポレイテッド Autonomous Hardware Computation Resilience Systems and Methods
US10679065B2 (en) * 2018-07-03 2020-06-09 Hitachi, Ltd. Non-invasive data extraction from digital displays
US10558761B2 (en) * 2018-07-05 2020-02-11 Disney Enterprises, Inc. Alignment of video and textual sequences for metadata analysis

Citations (341)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4138719A (en) 1974-11-11 1979-02-06 Xerox Corporation Automatic writing systems and methods of word processing therefor
US4807029A (en) 1986-06-16 1989-02-21 Fuji Photo Film Co., Ltd. Method of reconstructing image from compression-processed image signals
US4928247A (en) 1987-08-13 1990-05-22 Digital Equipment Corporation Method and apparatus for the continuous and asynchronous traversal and processing of graphics data structures
US4937036A (en) 1986-04-28 1990-06-26 Xerox Corporation Concurrent display of data from two different display processors and user interface therefore
US4949248A (en) 1988-07-15 1990-08-14 Caro Marshall A System for shared remote access of multiple application programs executing in one or more computers
US4965819A (en) 1988-09-22 1990-10-23 Docu-Vision, Inc. Video conferencing system for courtroom and other applications
US4974173A (en) 1987-12-02 1990-11-27 Xerox Corporation Small-scale workspace representations indicating activities by other users
US5021949A (en) 1988-02-29 1991-06-04 International Business Machines Corporation Method and apparatus for linking an SNA host to a remote SNA host over a packet switched communications network
US5062060A (en) 1987-01-05 1991-10-29 Motorola Inc. Computer human interface comprising user-adjustable window for displaying or printing information
US5072412A (en) 1987-03-25 1991-12-10 Xerox Corporation User interface with multiple workspaces for sharing display system objects
US5083860A (en) 1990-08-31 1992-01-28 Institut For Personalized Information Environment Method for detecting change points in motion picture images
EP0475581A2 (en) 1990-08-30 1992-03-18 Hewlett-Packard Company Method and apparatus for window sharing between computer displays
US5103305A (en) 1989-09-27 1992-04-07 Kabushiki Kaisha Toshiba Moving object detecting system
US5121497A (en) 1986-03-10 1992-06-09 International Business Machines Corporation Automatic generation of executable computer code which commands another program to perform a task and operator modification of the generated executable computer code
EP0495612A2 (en) 1991-01-14 1992-07-22 Xerox Corporation A data access system
US5241625A (en) 1990-11-27 1993-08-31 Farallon Computing, Inc. Screen image sharing among heterogeneous computers
US5307456A (en) 1990-12-04 1994-04-26 Sony Electronics, Inc. Integrated multi-media production and authoring system
US5313581A (en) 1990-09-14 1994-05-17 Digital Equipment Corporation System and method for communication between windowing environments
US5317732A (en) 1991-04-26 1994-05-31 Commodore Electronics Limited System for relocating a multimedia presentation on a different platform by extracting a resource map in order to remap and relocate resources
US5359712A (en) 1991-05-06 1994-10-25 Apple Computer, Inc. Method and apparatus for transitioning between sequences of digital information
US5382972A (en) 1988-09-22 1995-01-17 Kannes; Deno Video conferencing system for courtroom and other applications
US5388197A (en) 1991-08-02 1995-02-07 The Grass Valley Group, Inc. Video editing system operator inter-face for visualization and interactive control of video material
US5392400A (en) 1992-07-02 1995-02-21 International Business Machines Corporation Collaborative computing system using pseudo server process to allow input from different server processes individually and sequence number map for maintaining received data sequence
US5392223A (en) 1992-07-29 1995-02-21 International Business Machines Corp. Audio/video communications processor
EP0645695A1 (en) 1993-09-28 1995-03-29 AT&T GLOBAL INFORMATION SOLUTIONS INTERNATIONAL INC. Replicating displays in a multiple computer system
US5404316A (en) 1992-08-03 1995-04-04 Spectra Group Ltd., Inc. Desktop digital video processing system
US5408655A (en) 1989-02-27 1995-04-18 Apple Computer, Inc. User interface system and method for traversing a database
US5432932A (en) 1992-10-23 1995-07-11 International Business Machines Corporation System and method for dynamically controlling remote processes from a performance monitor
US5437025A (en) 1993-01-26 1995-07-25 International Business Machines Corporation System and method for run time configuration of objects in an object oriented computing environment
US5461711A (en) 1993-12-22 1995-10-24 Interval Research Corporation Method and system for spatial accessing of time-based information
US5526259A (en) * 1990-01-30 1996-06-11 Hitachi, Ltd. Method and apparatus for inputting text
US5550965A (en) 1993-12-27 1996-08-27 Lucent Technologies Inc. Method and system for operating a data processor to index primary data in real time with iconic table of contents
US5572258A (en) 1993-09-28 1996-11-05 Nec Corporation Motion compensation estimating device and method achieving improved motion compensation
US5572643A (en) 1995-10-19 1996-11-05 Judson; David H. Web browser with dynamic display of information objects during linking
US5574845A (en) 1994-11-29 1996-11-12 Siemens Corporate Research, Inc. Method and apparatus video data management
US5577254A (en) 1993-06-29 1996-11-19 Bull Hn Information Systems Inc. Method and apparatus for capturing the presentation of an interactive user session, monitoring, replaying and joining sessions
US5577188A (en) 1994-05-31 1996-11-19 Future Labs, Inc. Method to provide for virtual screen overlay
US5619638A (en) 1989-07-31 1997-04-08 Hewlett-Packard Company Object based computer system having representation objects for providing interpretative views onto a data object
US5623603A (en) 1994-11-02 1997-04-22 Fls Acquistion Corporation Method of transferring data at adjustable levels of priorities to provide optimum response to user demands
US5657390A (en) 1995-08-25 1997-08-12 Netscape Communications Corporation Secure socket layer application program apparatus and method
US5717879A (en) 1995-11-03 1998-02-10 Xerox Corporation System for the capture and replay of temporal data representing collaborative activities
US5721827A (en) 1996-10-02 1998-02-24 James Logan System for electrically distributing personalized information
US5727950A (en) 1996-05-22 1998-03-17 Netsage Corporation Agent based instruction system and method
US5729689A (en) 1995-04-25 1998-03-17 Microsoft Corporation Network naming services proxy agent
US5732216A (en) 1996-10-02 1998-03-24 Internet Angles, Inc. Audio message exchange system
US5742797A (en) 1995-08-11 1998-04-21 International Business Machines Corporation Dynamic off-screen display memory manager
US5745759A (en) 1994-10-14 1998-04-28 Qnx Software Systems, Ltd. Window kernel
US5748499A (en) 1995-09-19 1998-05-05 Sony Corporation Computer graphics data recording and playback system with a VCR-based graphic user interface
US5751362A (en) 1995-04-29 1998-05-12 Daewoo Electronics, Co., Ltd. Apparatus for encoding a video signal using feature point based motion estimation
US5758110A (en) 1994-06-17 1998-05-26 Intel Corporation Apparatus and method for application sharing in a graphic user interface
US5761656A (en) 1995-06-26 1998-06-02 Netdynamics, Inc. Interaction between databases and graphical user interfaces
US5768614A (en) 1995-07-03 1998-06-16 Fujitsu Limited Monitored state display unit for monitoring state change of various events occurring on communication network
US5796566A (en) 1996-08-16 1998-08-18 Compaq Computer Corporation Printed circuit board having conductors which can be decoupled for isolating inactive integrated circuits connected thereto
US5802206A (en) 1995-01-13 1998-09-01 Carl Zeiss Jena Gmbh Method for determining edge positions
US5822436A (en) 1996-04-25 1998-10-13 Digimarc Corporation Photographic products and methods employing embedded information
US5832119A (en) 1993-11-18 1998-11-03 Digimarc Corporation Methods for controlling systems using control signals embedded in empirical data
US5835090A (en) 1996-10-16 1998-11-10 Etma, Inc. Desktop manager for graphical user interface based system with enhanced desktop
US5838300A (en) 1995-06-19 1998-11-17 Canon Kabushiki Kaisha Window sharing system
US5838458A (en) 1992-02-25 1998-11-17 Tsai; Irving Method and apparatus for linking designated portions of a received document image with an electronic address
US5838906A (en) 1994-10-17 1998-11-17 The Regents Of The University Of California Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document
US5841978A (en) 1993-11-18 1998-11-24 Digimarc Corporation Network linking method using steganographically embedded data objects
US5862260A (en) 1993-11-18 1999-01-19 Digimarc Corporation Methods for surveying dissemination of proprietary empirical data
GB2327836A (en) 1997-07-29 1999-02-03 Ibm User interface controls for a computer system
US5886707A (en) 1990-11-20 1999-03-23 Berg; David A. Method for real-time on-demand interactive graphic communication for computer networks
US5907704A (en) 1995-04-03 1999-05-25 Quark, Inc. Hierarchical encapsulation of instantiated objects in a multimedia authoring system including internet accessible objects
US5909559A (en) 1997-04-04 1999-06-01 Texas Instruments Incorporated Bus bridge device including data bus of first width for a first processor, memory controller, arbiter circuit and second processor having a different second data width
US5915001A (en) 1996-11-14 1999-06-22 Vois Corporation System and method for providing and using universally accessible voice and speech data files
US5923736A (en) 1996-04-02 1999-07-13 National Semiconductor Corporation Hypertext markup language based telephone apparatus
US5935212A (en) 1997-08-07 1999-08-10 I-Planet, Inc. Connection-oriented session emulation
US5968132A (en) 1996-02-21 1999-10-19 Fujitsu Limited Image data communicating apparatus and a communication data quantity adjusting method used in an image data communication system
US5983190A (en) 1997-05-19 1999-11-09 Microsoft Corporation Client server animation system for managing interactive user interface characters
US5990852A (en) 1996-10-31 1999-11-23 Fujitsu Limited Display screen duplication system and method
US6003030A (en) 1995-06-07 1999-12-14 Intervu, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
US6006242A (en) 1996-04-05 1999-12-21 Bankers Systems, Inc. Apparatus and method for dynamically creating a document
US6011537A (en) 1997-01-27 2000-01-04 Slotznick; Benjamin System for delivering and simultaneously displaying primary and secondary information, and for displaying only the secondary information during interstitial space
US6022315A (en) 1993-12-29 2000-02-08 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6052120A (en) 1996-10-01 2000-04-18 Diamond Multimedia Systems, Inc. Method of operating a portable interactive graphics display tablet and communications systems
US6119092A (en) * 1998-06-26 2000-09-12 Lsi Logic Corporation Audio decoder bypass module for communicating compressed audio to external components
US6122403A (en) 1995-07-27 2000-09-19 Digimarc Corporation Computer system linked by using information in data objects
US6134596A (en) 1997-09-18 2000-10-17 Microsoft Corporation Continuous media file server system and method for scheduling network resources to play multiple files having different data transmission rates
US6141699A (en) 1998-05-11 2000-10-31 International Business Machines Corporation Interactive display system for sequential retrieval and display of a plurality of interrelated data sets
US6167432A (en) 1996-02-29 2000-12-26 Webex Communications, Inc., Method for creating peer-to-peer connections over an interconnected network to facilitate conferencing among users
US6166729A (en) 1997-05-07 2000-12-26 Broadcloud Communications, Inc. Remote digital image viewing system and method
US6173316B1 (en) 1998-04-08 2001-01-09 Geoworks Corporation Wireless communication device with markup language based man-machine interface
US6181736B1 (en) 1997-03-25 2001-01-30 Nxi Communications, Inc. Network communication system
US6185625B1 (en) 1996-12-20 2001-02-06 Intel Corporation Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object
US6199076B1 (en) 1996-10-02 2001-03-06 James Logan Audio program player including a dynamic program selection controller
US6199753B1 (en) 1996-09-05 2001-03-13 Symbol Technologies, Inc. Method and system for presenting item information using a portable data terminal
US6206829B1 (en) 1996-07-12 2001-03-27 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6219786B1 (en) 1998-09-09 2001-04-17 Surfcontrol, Inc. Method and system for monitoring and controlling network access
US6233617B1 (en) 1997-02-26 2001-05-15 Siebel Systems, Inc. Determining the visibility to a remote database client
US6237138B1 (en) 1996-11-12 2001-05-22 International Business Machines Corp. Buffered screen capturing software tool for usability testing of computer applications
US6243375B1 (en) 1996-11-08 2001-06-05 Gregory J. Speicher Internet-audiotext electronic communications system with multimedia based matching
US6256773B1 (en) 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6263363B1 (en) 1999-01-28 2001-07-17 Skydesk, Inc. System and method for creating an internet-accessible working replica of a home computer on a host server controllable by a user operating a remote access client computer
US6278466B1 (en) 1998-06-11 2001-08-21 Presenter.Com, Inc. Creating animation from a video
US6286036B1 (en) 1995-07-27 2001-09-04 Digimarc Corporation Audio- and graphics-based linking to internet
US6286030B1 (en) 1998-07-10 2001-09-04 Sap Aktiengesellschaft Systems and methods for recording and visually recreating sessions in a client-server environment
US20010019630A1 (en) 1994-07-14 2001-09-06 America Online, Inc. Method for transferring and displaying compressed images
US6289382B1 (en) 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
US6289461B1 (en) 1998-06-09 2001-09-11 Placeware, Inc. Bi-directional process-to-process byte stream protocol
US6295340B1 (en) 1998-05-13 2001-09-25 Lucent Technologies Inc. Speech coding selection based on call related information
US6307550B1 (en) 1998-06-11 2001-10-23 Presenter.Com, Inc. Extracting photographic images from video
US6317761B1 (en) 1998-05-15 2001-11-13 Unicast Communications Corporation Technique for implementing browser-initiated user-transparent advertising and for interstitially displaying an advertisement, so distributed, through a web browser in response to a user click-stream
US6321252B1 (en) 1998-07-17 2001-11-20 International Business Machines Corporation System and method for data streaming and synchronization in multimedia groupware applications
US6324647B1 (en) 1999-08-31 2001-11-27 Michel K. Bowman-Amuah System, method and article of manufacture for security management in a development architecture framework
US6332163B1 (en) 1999-09-01 2001-12-18 Accenture, Llp Method for providing communication services over a computer network system
US6331855B1 (en) 1999-04-28 2001-12-18 Expertcity.Com, Inc. Method and apparatus for providing remote access, control of remote systems and updating of display information
US6338088B1 (en) 1995-11-02 2002-01-08 British Telecommunications Public Limited Company Service creation apparatus for a communications network
US6339832B1 (en) 1999-08-31 2002-01-15 Accenture Llp Exception response table in environment services patterns
US6345239B1 (en) 1999-08-31 2002-02-05 Accenture Llp Remote demonstration of business capabilities in an e-commerce environment
US6351777B1 (en) 1999-04-23 2002-02-26 The United States Of America As Represented By The Secretary Of The Navy Computer software for converting a general purpose computer network into an interactive communications system
US6356437B1 (en) 1999-03-29 2002-03-12 Siemens Dematic Postal Automation, L.P. System, apparatus and method for providing a portable customizable maintenance support instruction system
US20020032770A1 (en) 2000-05-26 2002-03-14 Pearl Software, Inc. Method of remotely monitoring an internet session
US20020035451A1 (en) 2000-09-18 2002-03-21 Todd Rothermel Spatail data enabled engineering, construction, and operations computer-aided design (CAD) project system, method and computer program product
US20020033844A1 (en) 1998-10-01 2002-03-21 Levy Kenneth L. Content sensitive connected content
US20020038388A1 (en) 2000-09-13 2002-03-28 Netter Zvi Itzhak System and method for capture and playback of user interaction with web browser content
US6366933B1 (en) 1995-10-27 2002-04-02 At&T Corp. Method and apparatus for tracking and viewing changes on the web
US20020039481A1 (en) 2000-09-30 2002-04-04 Lg Electronics, Inc. Intelligent video system
US6370573B1 (en) 1999-08-31 2002-04-09 Accenture Llp System, method and article of manufacture for managing an environment of a development architecture framework
US20020048450A1 (en) 2000-09-15 2002-04-25 International Business Machines Corporation System and method of processing MPEG streams for file index insertion
US6381341B1 (en) 1996-05-16 2002-04-30 Digimarc Corporation Watermark encoding method exploiting biases inherent in original signal
US20020052932A1 (en) 1998-06-11 2002-05-02 Placeware, Inc. Collaborative object architecture
US20020054750A1 (en) 2000-04-25 2002-05-09 Michael Ficco DVR functions status indicator
US20020057295A1 (en) 1998-05-29 2002-05-16 Anatoliy Panasyuk System and method for combining local and remote windows into a single desktop environment
US6400996B1 (en) 1999-02-01 2002-06-04 Steven M. Hoffberg Adaptive pattern recognition based control system and method
US6401118B1 (en) 1998-06-30 2002-06-04 Online Monitoring Services Method and computer program product for an online monitoring search engine
US6405364B1 (en) 1999-08-31 2002-06-11 Accenture Llp Building techniques in a development architecture framework
US6405252B1 (en) 1999-11-22 2002-06-11 Speedera Networks, Inc. Integrated point of presence server network
US6421726B1 (en) 1997-03-14 2002-07-16 Akamai Technologies, Inc. System and method for selection and retrieval of diverse types of video data on a computer network
US6427063B1 (en) 1997-05-22 2002-07-30 Finali Corporation Agent based instruction system and method
US6427132B1 (en) 1999-08-31 2002-07-30 Accenture Llp System, method and article of manufacture for demonstrating E-commerce capabilities via a simulation on a network
US6434628B1 (en) 1999-08-31 2002-08-13 Accenture Llp Common interface for handling exception interface name with additional prefix and suffix for handling exceptions in environment services patterns
US6434568B1 (en) 1999-08-31 2002-08-13 Accenture Llp Information services patterns in a netcentric environment
US6438594B1 (en) 1999-08-31 2002-08-20 Accenture Llp Delivering service to a client via a locally addressable interface
US6437818B1 (en) 1993-10-01 2002-08-20 Collaboration Properties, Inc. Video conferencing on existing UTP infrastructure
US6442748B1 (en) 1999-08-31 2002-08-27 Accenture Llp System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment
US20020126144A1 (en) 2000-07-07 2002-09-12 Erwann Chenede Apparatus and method for communicating graphical display data in a network-based windowing system
US6466654B1 (en) 2000-03-06 2002-10-15 Avaya Technology Corp. Personal virtual assistant with semantic tagging
US20020149617A1 (en) 2001-03-30 2002-10-17 Becker David F. Remote collaboration technology design and methodology
US6473794B1 (en) 1999-05-27 2002-10-29 Accenture Llp System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US6473745B2 (en) 1998-07-31 2002-10-29 Microsoft Corporation Intelligent advisor system and method
US6477665B1 (en) 1999-08-31 2002-11-05 Accenture Llp System, method, and article of manufacture for environment services patterns in a netcentic environment
US6477580B1 (en) 1999-08-31 2002-11-05 Accenture Llp Self-described stream in a communication services patterns environment
US20020165922A1 (en) 2001-04-13 2002-11-07 Songxiang Wei Application based screen sampling
US20020174181A1 (en) 2001-04-13 2002-11-21 Songxiang Wei Sharing OpenGL applications using application based screen sampling
US6496850B1 (en) 1999-08-31 2002-12-17 Accenture Llp Clean-up of orphaned server contexts
US20020194272A1 (en) 1997-11-18 2002-12-19 Min Zhu Method for establishing a communication connection between two or more users via a network of interconnected computers
US6498955B1 (en) 1999-03-19 2002-12-24 Accenture Llp Member preference control of an environment
US6502102B1 (en) 2000-03-27 2002-12-31 Accenture Llp System, method and article of manufacture for a table-driven automated scripting architecture
US6502213B1 (en) 1999-08-31 2002-12-31 Accenture Llp System, method, and article of manufacture for a polymorphic exception handler in environment services patterns
US6502131B1 (en) 1997-05-27 2002-12-31 Novell, Inc. Directory enabled policy management tool for intelligent traffic management
US20030018662A1 (en) 2001-07-19 2003-01-23 Sheng Li Synchronizing multimedia data
US6519571B1 (en) 1999-05-27 2003-02-11 Accenture Llp Dynamic customer profile management
US6523027B1 (en) 1999-07-30 2003-02-18 Accenture Llp Interfacing servers in a Java based e-commerce architecture
US6526335B1 (en) 2000-01-24 2003-02-25 G. Victor Treyz Automobile personal computer systems
US6529909B1 (en) 1999-08-31 2003-03-04 Accenture Llp Method for translating an object attribute converter in an information services patterns environment
US6529948B1 (en) 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US6536037B1 (en) 1999-05-27 2003-03-18 Accenture Llp Identification of redundancies and omissions among components of a web based architecture
US20030055896A1 (en) 2001-08-31 2003-03-20 Hui Hu On-line image processing and communication system
US6539429B2 (en) 1995-08-22 2003-03-25 Backweb Technologies Ltd. Method and apparatus for transmitting and displaying information between a remote network and a local computer
US6539336B1 (en) 1996-12-12 2003-03-25 Phatrat Technologies, Inc. Sport monitoring system for determining airtime, speed, power absorbed and other factors such as drop distance
US6539396B1 (en) 1999-08-31 2003-03-25 Accenture Llp Multi-object identifier system and method for information service pattern environment
US20030061355A1 (en) 2001-09-25 2003-03-27 Guanghong Yang Systems and methods for establishing quasi-persistent HTTP connections
US6550057B1 (en) 1999-08-31 2003-04-15 Accenture Llp Piecemeal retrieval in an information services patterns environment
US6549949B1 (en) 1999-08-31 2003-04-15 Accenture Llp Fixed format stream in a communication services patterns environment
US20030079224A1 (en) 2001-10-22 2003-04-24 Anton Komar System and method to provide additional information associated with selectable display areas
US20030084169A1 (en) 2001-10-31 2003-05-01 Min Zhu System and method for accessing a target computer from a remote location using a remote computer
US20030085922A1 (en) 2001-04-13 2003-05-08 Songxiang Wei Sharing DirectDraw applications using application based screen sampling
US6567813B1 (en) 2000-12-29 2003-05-20 Webex Communications, Inc. Quality of service maintenance for distributed collaborative computing
US6567533B1 (en) 1993-11-18 2003-05-20 Digimarc Corporation Method and apparatus for discerning image distortion by reference to encoded marker signals
US6571282B1 (en) 1999-08-31 2003-05-27 Accenture Llp Block-based communication in a communication services patterns environment
US6573907B1 (en) 1997-07-03 2003-06-03 Obvious Technology Network distribution and management of interactive video and multi-media containers
US6574672B1 (en) 1999-03-29 2003-06-03 Siemens Dematic Postal Automation, L.P. System, apparatus and method for providing a portable customizable maintenance support computer communications system
US6578068B1 (en) 1999-08-31 2003-06-10 Accenture Llp Load balancer in environment services patterns
US20030110266A1 (en) 2001-12-10 2003-06-12 Cysive, Inc. Apparatus and method of using session state data across sessions
US6580808B2 (en) 1995-09-25 2003-06-17 Digimarc Corporation Method and apparatus for discerning image distortion by reference to encoded marker signals
US6584493B1 (en) 1999-03-02 2003-06-24 Microsoft Corporation Multiparty conferencing and collaboration system utilizing a per-host model command, control and communication structure
US6584569B2 (en) 2000-03-03 2003-06-24 Sanctum Ltd. System for determining web application vulnerabilities
US20030135656A1 (en) 1997-08-22 2003-07-17 Apex Inc. Method and system for intellegently controlling a remotely located computer
US6597736B1 (en) 2000-03-29 2003-07-22 Cisco Technology, Inc. Throughput enhanced video communication
US6601234B1 (en) 1999-08-31 2003-07-29 Accenture Llp Attribute dictionary in a business logic services environment
US6601192B1 (en) 1999-08-31 2003-07-29 Accenture Llp Assertion component in environment services patterns
US6601233B1 (en) 1999-07-30 2003-07-29 Accenture Llp Business components framework
US6601087B1 (en) 1998-11-18 2003-07-29 Webex Communications, Inc. Instant document sharing
US6606660B1 (en) 1999-08-31 2003-08-12 Accenture Llp Stream-based communication in a communication services patterns environment
US6606744B1 (en) 1999-11-22 2003-08-12 Accenture, Llp Providing collaborative installation management in a network-based supply chain environment
US6609128B1 (en) 1999-07-30 2003-08-19 Accenture Llp Codes table framework design in an E-commerce architecture
US6611867B1 (en) 1999-08-31 2003-08-26 Accenture Llp System, method and article of manufacture for implementing a hybrid network
US20030163704A1 (en) 2002-02-25 2003-08-28 Dick Kevin Stewart System, method and computer program product for guaranteeing electronic transactions
US6615199B1 (en) 1999-08-31 2003-09-02 Accenture, Llp Abstraction factory in a base services pattern environment
US6615166B1 (en) 1999-05-27 2003-09-02 Accenture Llp Prioritizing components of a network framework required for implementation of technology
US6615253B1 (en) 1999-08-31 2003-09-02 Accenture Llp Efficient server side data retrieval for execution of client side applications
US20030167304A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed meeting management
US20030167301A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed network system architecture for collaborative computing
US20030167303A1 (en) 2000-12-29 2003-09-04 Min Zhu Fault-tolerant distributed system for collaborative computing
US20030167418A1 (en) 2000-12-29 2003-09-04 Min Zhu Fault-tolerant server for collaborative computing
US20030167293A1 (en) 2000-12-29 2003-09-04 Min Zhu Fault tolerant server architecture for collaborative computing
US20030167339A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed application sharing
US20030164853A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed document sharing
US20030167305A1 (en) 2000-12-29 2003-09-04 Min Zhu Secure communications system for collaborative computing
US20030167302A1 (en) 2000-12-29 2003-09-04 Min Zhu Scalable distributed network system for collaborative computing
US20030177172A1 (en) 2002-03-14 2003-09-18 Citrix Systems, Inc. Method and system for generating a graphical display for a remote terminal session
US20030182375A1 (en) 2002-03-21 2003-09-25 Webex Communications, Inc. Rich multi-media format for use in a collaborative computing system
US6629081B1 (en) 1999-12-22 2003-09-30 Accenture Llp Account settlement and financing in an e-commerce environment
US20030191799A1 (en) 2000-03-14 2003-10-09 Netilla Networks, Inc. Apparatus and accompanying methods for providing, through a centralized server site, a secure, cost-effective, web-enabled, integrated virtual office environment remotely accessible through a network-connected web browser
US6633878B1 (en) 1999-07-30 2003-10-14 Accenture Llp Initializing an ecommerce database framework
US6636242B2 (en) 1999-08-31 2003-10-21 Accenture Llp View configurer in a presentation services patterns environment
US6640238B1 (en) 1999-08-31 2003-10-28 Accenture Llp Activity component in a presentation services patterns environment
US6640249B1 (en) 1999-08-31 2003-10-28 Accenture Llp Presentation services patterns in a netcentric environment
US6640244B1 (en) 1999-08-31 2003-10-28 Accenture Llp Request batcher in a transaction services patterns environment
US20030208529A1 (en) 2002-05-03 2003-11-06 Sreenath Pendyala System for and method of real-time remote access and manipulation of data
US6647130B2 (en) 1993-11-18 2003-11-11 Digimarc Corporation Printable interfaces and digital linking with embedded codes
US6654032B1 (en) 1999-12-23 2003-11-25 Webex Communications, Inc. Instant sharing of documents on a remote server
US20030220973A1 (en) 2002-03-28 2003-11-27 Min Zhu Conference recording system
US6658464B2 (en) 1994-05-31 2003-12-02 Richard R. Reisman User station software that controls transport, storage, and presentation of content from a remote source
US20030226038A1 (en) 2001-12-31 2003-12-04 Gil Raanan Method and system for dynamic refinement of security policies
US6662357B1 (en) 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6671876B1 (en) 1999-10-28 2003-12-30 Lucent Technologies Inc. Monitoring of software operation for improving computer program performance
US6671818B1 (en) 1999-11-22 2003-12-30 Accenture Llp Problem isolation through translating and filtering events into a standard object format in a network based supply chain
US20040002048A1 (en) 2002-07-01 2004-01-01 Matthew Thurmaier Method and system for providing a virtual computer classroom
US6678864B1 (en) 1992-02-25 2004-01-13 Irving Tsai Method and apparatus for linking designated portions of a received document image with an electronic address
US20040017394A1 (en) 2002-04-04 2004-01-29 Keiji Adachi Image processing apparatus and method, and program for implementing the method
US6687745B1 (en) 1999-09-14 2004-02-03 Droplet, Inc System and method for delivering a graphical user interface of remote applications over a thin bandwidth connection
US20040031058A1 (en) 2002-05-10 2004-02-12 Richard Reisman Method and apparatus for browsing using alternative linkbases
US6697894B1 (en) 1999-03-29 2004-02-24 Siemens Dematic Postal Automation, L.P. System, apparatus and method for providing maintenance instructions to a user at a remote location
US6701514B1 (en) 2000-03-27 2004-03-02 Accenture Llp System, method, and article of manufacture for test maintenance in an automated scripting framework
US6701345B1 (en) 2000-04-13 2004-03-02 Accenture Llp Providing a notification when a plurality of users are altering similar data in a health care solution environment
US20040044521A1 (en) 2002-09-04 2004-03-04 Microsoft Corporation Unified lossy and lossless audio compression
US6704873B1 (en) 1999-07-30 2004-03-09 Accenture Llp Secure gateway interconnection in an e-commerce based environment
US6715145B1 (en) 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
US6718535B1 (en) 1999-07-30 2004-04-06 Accenture Llp System, method and article of manufacture for an activity framework design in an e-commerce based environment
US6721703B2 (en) 2001-03-02 2004-04-13 Jay M. Jackson Remote deposition system and method
US6721713B1 (en) 1999-05-27 2004-04-13 Andersen Consulting Llp Business alliance identification in a web architecture framework
US6742015B1 (en) 1999-08-31 2004-05-25 Accenture Llp Base services patterns in a netcentric environment
US20040103438A1 (en) 2002-11-27 2004-05-27 Yong Yan Methods and systems for transferring events including multimedia data
US6760463B2 (en) 1995-05-08 2004-07-06 Digimarc Corporation Watermarking methods and media
US6763501B1 (en) 2000-06-09 2004-07-13 Webex Communications, Inc. Remote document serving
US20040135974A1 (en) 2002-10-18 2004-07-15 Favalora Gregg E. System and architecture for displaying three dimensional data
US20040143602A1 (en) 2002-10-18 2004-07-22 Antonio Ruiz Apparatus, system and method for automated and adaptive digital image/video surveillance for events and configurations using a rich multimedia relational database
US6774926B1 (en) 1999-09-03 2004-08-10 United Video Properties, Inc. Personal television channel system
US6795506B1 (en) 1999-10-05 2004-09-21 Cisco Technology, Inc. Methods and apparatus for efficient scheduling and multiplexing
US6799221B1 (en) 1997-06-18 2004-09-28 Akamai Technologies, Inc. System and method for server-side optimization of data delivery on a distributed computer network
US6801927B1 (en) 1999-09-24 2004-10-05 Akamba Corporation Network adaptor card with reverse proxy and cache and method implemented therewith
USRE38609E1 (en) 2000-02-28 2004-10-05 Webex Communications, Inc. On-demand presentation graphical user interface
US6802041B1 (en) 1999-01-20 2004-10-05 Perfectnotes Corporation Multimedia word processor
US20040205213A1 (en) 1998-07-27 2004-10-14 Web Tv Networks, Inc.; Manipulating a compressed video stream
EP1469382A2 (en) 2003-04-08 2004-10-20 Microsoft Corporation Display source divider
US20040207723A1 (en) 2003-04-15 2004-10-21 Davis Jeffrey Alan UI remoting with synchronized out-of-band media
US6810488B2 (en) 2001-05-22 2004-10-26 Webex Communications, Inc. Adaptive selective retransmission of packets
US6813366B1 (en) 1995-05-08 2004-11-02 Digimarc Corporation Steganographic decoding with transform to spatial domain
US6816904B1 (en) 1997-11-04 2004-11-09 Collaboration Properties, Inc. Networked video multimedia storage server environment
US6824044B1 (en) 1999-06-30 2004-11-30 Silverbrook Research Pty Ltd Method and system for obtaining a video-related document
US20040240387A1 (en) 2003-05-28 2004-12-02 Lucent Technologies, Incorporated System and method for simulating traffic loads in packetized communication networks
US20040267820A1 (en) 1999-10-14 2004-12-30 Microsoft Corporation Method and system for recording and replaying internet transactions
US20040267952A1 (en) 2003-06-24 2004-12-30 He Li-Wei Variable play speed control for media streams
US6842906B1 (en) 1999-08-31 2005-01-11 Accenture Llp System and method for a refreshable proxy pool in a communication services patterns environment
US20050019014A1 (en) 2003-04-23 2005-01-27 Lg Electronics, Inc. Method and apparatus for synchronous reproduction of main contents recorded on an interactive recording medium and additional contents therefor
US6850252B1 (en) 1999-10-05 2005-02-01 Steven M. Hoffberg Intelligent electronic appliance system and method
US6870921B1 (en) 1999-11-12 2005-03-22 Metro One Telecommunications, Inc. Enhanced directory assistance service providing individual or group directories
US6877043B2 (en) 2000-04-07 2005-04-05 Broadcom Corporation Method for distributing sets of collision resolution parameters in a frame-based communications network
US6879701B1 (en) 1994-10-21 2005-04-12 Digimarc Corporation Tile-based digital watermarking techniques
US20050080850A1 (en) 1996-03-26 2005-04-14 Pixion, Inc. Real-time, multi-point, multi-speed, multi-stream scalable computer network communications system
US6907546B1 (en) 2000-03-27 2005-06-14 Accenture Llp Language-driven interface for an automated testing framework
US20050132417A1 (en) 2003-12-14 2005-06-16 Bobrovskiy Stanislav M. Method and apparatus for buffering streaming media
US6914519B2 (en) 2003-06-05 2005-07-05 Siemens Communications, Inc. System and method for muting alarms during a conference
US20050152683A1 (en) * 2003-11-28 2005-07-14 Lg Electronics Inc. Method and apparatus for repetitive playback of a video section based on subtitles
US6957186B1 (en) 1999-05-27 2005-10-18 Accenture Llp System method and article of manufacture for building, managing, and supporting various components of a system
US20050254775A1 (en) 2004-04-01 2005-11-17 Techsmith Corporation Automated system and method for conducting usability testing
US6968364B1 (en) 2000-03-30 2005-11-22 Microsoft Corporation System and method to facilitate selection and programming of an associated audio/visual system
US6968057B2 (en) 1994-03-17 2005-11-22 Digimarc Corporation Emulsion products and imagery employing steganography
US6988126B2 (en) 2000-10-17 2006-01-17 Hewlett-Packard Development Company, L.P. Contact center system and method for specifying different service specific behavior and offering range of corresponding customer services
US6996605B2 (en) 2000-10-17 2006-02-07 Hewlett-Packard Development Company L.P. Overview subsystem for information page server
US7000019B2 (en) 2000-10-17 2006-02-14 Hewlett-Packard/Development Company L.P. Establishment of a deferred network communication session
US7000180B2 (en) 2000-06-29 2006-02-14 Balthaser Online, Inc. Methods, systems, and processes for the design and creation of rich-media applications via the internet
US7006881B1 (en) 1991-12-23 2006-02-28 Steven Hoffberg Media recording device with remote graphic user interface
US7013323B1 (en) 2000-05-23 2006-03-14 Cyveillance, Inc. System and method for developing and interpreting e-commerce metrics by utilizing a list of rules wherein each rule contain at least one of entity-specific criteria
US20060064716A1 (en) 2000-07-24 2006-03-23 Vivcom, Inc. Techniques for navigating multiple video streams
US7023979B1 (en) 2002-03-07 2006-04-04 Wai Wu Telephony control system with intelligent call routing
US7024456B1 (en) 1999-04-23 2006-04-04 The United States Of America As Represented By The Secretary Of The Navy Method for facilitating collaborative development efforts between widely dispersed users
US7027055B2 (en) 2001-04-30 2006-04-11 The Commonwealth Of Australia Data view of a modelling system
US7032030B1 (en) 1999-03-11 2006-04-18 John David Codignotto Message publishing system and method
US7035907B1 (en) 2000-09-13 2006-04-25 Jibe Networks, Inc. Manipulating content objects to control their display
US7043669B2 (en) 2002-04-03 2006-05-09 International Business Machines Corporation Simple scenario builder
US7043529B1 (en) 1999-04-23 2006-05-09 The United States Of America As Represented By The Secretary Of The Navy Collaborative development network for widely dispersed users and methods therefor
US7047092B2 (en) 2003-04-08 2006-05-16 Coraccess Systems Home automation contextual user interface
US20060130124A1 (en) 2004-12-15 2006-06-15 Guard Insurance Group A Remote Communication System and Method Implementing a Session Server and One or More Object Servers
US7069332B2 (en) 2000-02-24 2006-06-27 Hitachi, Ltd. Video server for video distribution system
US7069234B1 (en) 1999-12-22 2006-06-27 Accenture Llp Initiating an agreement in an e-commerce environment
US7073189B2 (en) 2002-05-03 2006-07-04 Time Warner Interactive Video Group, Inc. Program guide and reservation system for network based digital information and entertainment storage and delivery system
US7073126B1 (en) 1999-11-18 2006-07-04 Instaknow.Com Inc. Method and system of deploying server-based applications
WO2006076389A2 (en) 2005-01-14 2006-07-20 Citrix Systems, Inc. Methods and systems for capture, replay and real-time seeking in remote presentation protocols
US20060161671A1 (en) 2005-01-14 2006-07-20 Citrix Systems, Inc. Method and systems for capture and replay of remote presentation protocol data
US20060161959A1 (en) 2005-01-14 2006-07-20 Citrix Systems, Inc. Method and system for real-time seeking during playback of remote presentation protocols
US7082572B2 (en) 2002-12-30 2006-07-25 The Board Of Trustees Of The Leland Stanford Junior University Methods and apparatus for interactive map-based analysis of digital video content
US7092370B2 (en) 2000-08-17 2006-08-15 Roamware, Inc. Method and system for wireless voice channel/data channel integration
US7100195B1 (en) 1999-07-30 2006-08-29 Accenture Llp Managing user information on an e-commerce system
US7103197B2 (en) 1993-11-18 2006-09-05 Digimarc Corporation Arrangement for embedding subliminal data in imaging
US7113596B2 (en) 1993-11-18 2006-09-26 Digimarc Corporation Embedding information related to a subject of an identification document in the identification document
US7116781B2 (en) 1993-11-18 2006-10-03 Digimarc Corporation Counteracting geometric distortions in watermarking
US7124175B1 (en) 2000-06-30 2006-10-17 Cisco Technology, Inc. IP web based messaging system for localized management of wireless messaging
US7124101B1 (en) 1999-11-22 2006-10-17 Accenture Llp Asset tracking in a network-based supply chain environment
US7130403B2 (en) 2002-12-11 2006-10-31 Siemens Communications, Inc. System and method for enhanced multimedia conference collaboration
US7130807B1 (en) 1999-11-22 2006-10-31 Accenture Llp Technology sharing during demand and supply planning in a network-based supply chain environment
US7133837B1 (en) 2000-06-29 2006-11-07 Barnes Jr Melvin L Method and apparatus for providing communication transmissions
US7133085B2 (en) 2000-08-10 2006-11-07 Pioneer Corporation Display control apparatus, display control method and information recording medium
US7139999B2 (en) 1999-08-31 2006-11-21 Accenture Llp Development architecture framework
US20060274828A1 (en) 2001-11-01 2006-12-07 A4S Security, Inc. High capacity surveillance system with fast search capability
US7149788B1 (en) 2002-01-28 2006-12-12 Witness Systems, Inc. Method and system for providing access to captured multimedia data from a multimedia player
US20070005795A1 (en) 1999-10-22 2007-01-04 Activesky, Inc. Object oriented video system
US7165041B1 (en) 1999-05-27 2007-01-16 Accenture, Llp Web-based architecture sales tool
US7167844B1 (en) 1999-12-22 2007-01-23 Accenture Llp Electronic menu document creator in a virtual financial environment
US20070022155A1 (en) 2002-08-22 2007-01-25 Owens David H Method and system for integrating enterprise software applications with desktop software applications
US7171174B2 (en) 2001-02-20 2007-01-30 Ellis Michael D Multiple radio signal processing and storing method and apparatus
US7174126B2 (en) 2002-05-03 2007-02-06 Time Warner Interactive Video Group Inc. Technique for effectively accessing programming listing information in an entertainment delivery system
US7185283B1 (en) 1999-02-24 2007-02-27 Sony Corporation Screen control method
US7184531B2 (en) 2003-06-05 2007-02-27 Siemens Communications, Inc. System and method for authorizing a party to join a conference
US20070057952A1 (en) 2005-09-14 2007-03-15 Microsoft Corporation Adaptive scheduling to maintain smooth frame rate
US7213211B1 (en) 2001-07-03 2007-05-01 Dynamic Knowledge Transfer, Llc System for knowledge transfer in a group setting
US20070106811A1 (en) * 2005-01-14 2007-05-10 Citrix Systems, Inc. Methods and systems for real-time seeking during real-time playback of a presentation layer protocol data stream
US20070106681A1 (en) 2000-06-28 2007-05-10 Mci, Llc. Method and system for providing a personal video recorder utilizing network-based digital media content
US7225130B2 (en) 2001-09-05 2007-05-29 Voice Signal Technologies, Inc. Methods, systems, and programming for performing speech recognition
US20070133524A1 (en) 2005-12-09 2007-06-14 Yahoo! Inc. Selectable replay of buffered conversation in a VOIP session
US20070214489A1 (en) * 2006-03-08 2007-09-13 Kwong Wah Y Media presentation operations on computing devices
US20070261097A1 (en) 2006-05-03 2007-11-08 Avocent Corporation Remote session recording apparatus and method
US20070276910A1 (en) 2006-05-23 2007-11-29 Scott Deboy Conferencing system with desktop sharing
US20070288640A1 (en) 2006-06-07 2007-12-13 Microsoft Corporation Remote rendering of multiple mouse cursors
US7313613B1 (en) 2002-01-03 2007-12-25 Microsoft Corporation System and method facilitating network diagnostics and self-healing
US20070300235A1 (en) * 2006-06-27 2007-12-27 Eliezer Dekel Reliable messaging using a message stream in a high speed, low latency data communications environment
US20080068289A1 (en) 2006-09-14 2008-03-20 Citrix Systems, Inc. System and method for multiple display support in remote access software
US20080106530A1 (en) * 2006-10-23 2008-05-08 Buxton Mark J Video composition optimization by the identification of transparent and opaque regions
US7398320B1 (en) 1999-08-09 2008-07-08 Fujitsu Limited Information distribution/reproduction control apparatus, information distribution/reproduction control method, and computer-readable recording medium recorded with information distribution/reproduction control program
US7401116B1 (en) 2002-03-29 2008-07-15 Silicon Graphics, Inc. System and method for allowing remote users to specify graphics application parameters for generation of interactive images
US7490166B2 (en) 2000-05-26 2009-02-10 Citrix Systems, Inc. Remote control of a client's off-screen surface
US20090097361A1 (en) 2006-12-28 2009-04-16 Sony Corporation Content display method, a content display apparatus, and a recording medium on which a content display program is recorded
US20090169183A1 (en) * 2004-12-02 2009-07-02 Sony Computer Entertainment Inc. Data recording device, data recording method, data processing device, data processing method, program, program recording medium, data recording medium, and data structure
US20090282444A1 (en) 2001-12-04 2009-11-12 Vixs Systems, Inc. System and method for managing the presentation of video
US7908325B1 (en) 2005-06-20 2011-03-15 Oracle America, Inc. System and method for event-based collaboration
US20110196982A1 (en) 2009-10-28 2011-08-11 Qualcomm Incorporated Streaming encoded video data
US8009966B2 (en) * 2002-11-01 2011-08-30 Synchro Arts Limited Methods and apparatus for use in sound replacement with automatic synchronization to images
US20110286721A1 (en) 2006-02-28 2011-11-24 Rovi Guides, Inc. Systems and methods for enhanced trick-play functions

Patent Citations (393)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4138719A (en) 1974-11-11 1979-02-06 Xerox Corporation Automatic writing systems and methods of word processing therefor
US5121497A (en) 1986-03-10 1992-06-09 International Business Machines Corporation Automatic generation of executable computer code which commands another program to perform a task and operator modification of the generated executable computer code
US4937036A (en) 1986-04-28 1990-06-26 Xerox Corporation Concurrent display of data from two different display processors and user interface therefore
US4807029A (en) 1986-06-16 1989-02-21 Fuji Photo Film Co., Ltd. Method of reconstructing image from compression-processed image signals
US5062060A (en) 1987-01-05 1991-10-29 Motorola Inc. Computer human interface comprising user-adjustable window for displaying or printing information
US5072412A (en) 1987-03-25 1991-12-10 Xerox Corporation User interface with multiple workspaces for sharing display system objects
US4928247A (en) 1987-08-13 1990-05-22 Digital Equipment Corporation Method and apparatus for the continuous and asynchronous traversal and processing of graphics data structures
US4974173A (en) 1987-12-02 1990-11-27 Xerox Corporation Small-scale workspace representations indicating activities by other users
US5021949A (en) 1988-02-29 1991-06-04 International Business Machines Corporation Method and apparatus for linking an SNA host to a remote SNA host over a packet switched communications network
US4949248A (en) 1988-07-15 1990-08-14 Caro Marshall A System for shared remote access of multiple application programs executing in one or more computers
US4965819A (en) 1988-09-22 1990-10-23 Docu-Vision, Inc. Video conferencing system for courtroom and other applications
US5382972A (en) 1988-09-22 1995-01-17 Kannes; Deno Video conferencing system for courtroom and other applications
US5408655A (en) 1989-02-27 1995-04-18 Apple Computer, Inc. User interface system and method for traversing a database
US5619638A (en) 1989-07-31 1997-04-08 Hewlett-Packard Company Object based computer system having representation objects for providing interpretative views onto a data object
US5103305A (en) 1989-09-27 1992-04-07 Kabushiki Kaisha Toshiba Moving object detecting system
US5526259A (en) * 1990-01-30 1996-06-11 Hitachi, Ltd. Method and apparatus for inputting text
EP0475581A2 (en) 1990-08-30 1992-03-18 Hewlett-Packard Company Method and apparatus for window sharing between computer displays
US5083860A (en) 1990-08-31 1992-01-28 Institut For Personalized Information Environment Method for detecting change points in motion picture images
US5313581A (en) 1990-09-14 1994-05-17 Digital Equipment Corporation System and method for communication between windowing environments
US5886707A (en) 1990-11-20 1999-03-23 Berg; David A. Method for real-time on-demand interactive graphic communication for computer networks
US5241625A (en) 1990-11-27 1993-08-31 Farallon Computing, Inc. Screen image sharing among heterogeneous computers
US5307456A (en) 1990-12-04 1994-04-26 Sony Electronics, Inc. Integrated multi-media production and authoring system
EP0495612A2 (en) 1991-01-14 1992-07-22 Xerox Corporation A data access system
US5317732A (en) 1991-04-26 1994-05-31 Commodore Electronics Limited System for relocating a multimedia presentation on a different platform by extracting a resource map in order to remap and relocate resources
US5359712A (en) 1991-05-06 1994-10-25 Apple Computer, Inc. Method and apparatus for transitioning between sequences of digital information
US5388197A (en) 1991-08-02 1995-02-07 The Grass Valley Group, Inc. Video editing system operator inter-face for visualization and interactive control of video material
US7006881B1 (en) 1991-12-23 2006-02-28 Steven Hoffberg Media recording device with remote graphic user interface
US6445468B1 (en) 1992-02-25 2002-09-03 Irving Tsai Method and apparatus for linking designated portions of a received document image with an electronic address
US5838458A (en) 1992-02-25 1998-11-17 Tsai; Irving Method and apparatus for linking designated portions of a received document image with an electronic address
US6678864B1 (en) 1992-02-25 2004-01-13 Irving Tsai Method and apparatus for linking designated portions of a received document image with an electronic address
US7089487B2 (en) 1992-02-25 2006-08-08 Mary Y. Y. Tsai Method and apparatus for linking designated portions of a received document image with an electronic address
US7016084B2 (en) 1992-02-25 2006-03-21 Irving Tsai Method and apparatus for linking designated portions of a received document image with an electronic address
US5392400A (en) 1992-07-02 1995-02-21 International Business Machines Corporation Collaborative computing system using pseudo server process to allow input from different server processes individually and sequence number map for maintaining received data sequence
US5392223A (en) 1992-07-29 1995-02-21 International Business Machines Corp. Audio/video communications processor
US5404316A (en) 1992-08-03 1995-04-04 Spectra Group Ltd., Inc. Desktop digital video processing system
US5432932A (en) 1992-10-23 1995-07-11 International Business Machines Corporation System and method for dynamically controlling remote processes from a performance monitor
US5437025A (en) 1993-01-26 1995-07-25 International Business Machines Corporation System and method for run time configuration of objects in an object oriented computing environment
US5577254A (en) 1993-06-29 1996-11-19 Bull Hn Information Systems Inc. Method and apparatus for capturing the presentation of an interactive user session, monitoring, replaying and joining sessions
US5572258A (en) 1993-09-28 1996-11-05 Nec Corporation Motion compensation estimating device and method achieving improved motion compensation
EP0645695A1 (en) 1993-09-28 1995-03-29 AT&T GLOBAL INFORMATION SOLUTIONS INTERNATIONAL INC. Replicating displays in a multiple computer system
US6437818B1 (en) 1993-10-01 2002-08-20 Collaboration Properties, Inc. Video conferencing on existing UTP infrastructure
US6700990B1 (en) 1993-11-18 2004-03-02 Digimarc Corporation Digital watermark decoding method
US6647128B1 (en) 1993-11-18 2003-11-11 Digimarc Corporation Method for monitoring internet dissemination of image, video, and/or audio files
US7035427B2 (en) 1993-11-18 2006-04-25 Digimarc Corporation Method and system for managing, accessing and paying for the use of copyrighted electronic media
US7103197B2 (en) 1993-11-18 2006-09-05 Digimarc Corporation Arrangement for embedding subliminal data in imaging
US7113614B2 (en) 1993-11-18 2006-09-26 Digimarc Corporation Embedding auxiliary signals with multiple components into media signals
US7113596B2 (en) 1993-11-18 2006-09-26 Digimarc Corporation Embedding information related to a subject of an identification document in the identification document
US7116781B2 (en) 1993-11-18 2006-10-03 Digimarc Corporation Counteracting geometric distortions in watermarking
US5832119C1 (en) 1993-11-18 2002-03-05 Digimarc Corp Methods for controlling systems using control signals embedded in empirical data
US7171016B1 (en) 1993-11-18 2007-01-30 Digimarc Corporation Method for monitoring internet dissemination of image, video and/or audio files
US6324573B1 (en) 1993-11-18 2001-11-27 Digimarc Corporation Linking of computers using information steganographically embedded in data objects
US6567533B1 (en) 1993-11-18 2003-05-20 Digimarc Corporation Method and apparatus for discerning image distortion by reference to encoded marker signals
US7054465B2 (en) 1993-11-18 2006-05-30 Digimarc Corporation Data hiding method and system for embedding and extracting information in signals
US5832119A (en) 1993-11-18 1998-11-03 Digimarc Corporation Methods for controlling systems using control signals embedded in empirical data
US5862260A (en) 1993-11-18 1999-01-19 Digimarc Corporation Methods for surveying dissemination of proprietary empirical data
US6681029B1 (en) 1993-11-18 2004-01-20 Digimarc Corporation Decoding steganographic messages embedded in media signals
US6590998B2 (en) 1993-11-18 2003-07-08 Digimarc Corporation Network linking method using information embedded in data objects that have inherent noise
US5841978A (en) 1993-11-18 1998-11-24 Digimarc Corporation Network linking method using steganographically embedded data objects
US6647130B2 (en) 1993-11-18 2003-11-11 Digimarc Corporation Printable interfaces and digital linking with embedded codes
US5461711A (en) 1993-12-22 1995-10-24 Interval Research Corporation Method and system for spatial accessing of time-based information
US5550965A (en) 1993-12-27 1996-08-27 Lucent Technologies Inc. Method and system for operating a data processor to index primary data in real time with iconic table of contents
US6022315A (en) 1993-12-29 2000-02-08 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6111954A (en) 1994-03-17 2000-08-29 Digimarc Corporation Steganographic methods and media for photography
US6438231B1 (en) 1994-03-17 2002-08-20 Digimarc Corporation Emulsion film media employing steganography
US6968057B2 (en) 1994-03-17 2005-11-22 Digimarc Corporation Emulsion products and imagery employing steganography
US5577188A (en) 1994-05-31 1996-11-19 Future Labs, Inc. Method to provide for virtual screen overlay
US6658464B2 (en) 1994-05-31 2003-12-02 Richard R. Reisman User station software that controls transport, storage, and presentation of content from a remote source
US5758110A (en) 1994-06-17 1998-05-26 Intel Corporation Apparatus and method for application sharing in a graphic user interface
US20010019630A1 (en) 1994-07-14 2001-09-06 America Online, Inc. Method for transferring and displaying compressed images
US5745759A (en) 1994-10-14 1998-04-28 Qnx Software Systems, Ltd. Window kernel
US5838906A (en) 1994-10-17 1998-11-17 The Regents Of The University Of California Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document
US6879701B1 (en) 1994-10-21 2005-04-12 Digimarc Corporation Tile-based digital watermarking techniques
US5623603A (en) 1994-11-02 1997-04-22 Fls Acquistion Corporation Method of transferring data at adjustable levels of priorities to provide optimum response to user demands
US5574845A (en) 1994-11-29 1996-11-12 Siemens Corporate Research, Inc. Method and apparatus video data management
US5802206A (en) 1995-01-13 1998-09-01 Carl Zeiss Jena Gmbh Method for determining edge positions
US5907704A (en) 1995-04-03 1999-05-25 Quark, Inc. Hierarchical encapsulation of instantiated objects in a multimedia authoring system including internet accessible objects
US5729689A (en) 1995-04-25 1998-03-17 Microsoft Corporation Network naming services proxy agent
US5751362A (en) 1995-04-29 1998-05-12 Daewoo Electronics, Co., Ltd. Apparatus for encoding a video signal using feature point based motion estimation
US6760463B2 (en) 1995-05-08 2004-07-06 Digimarc Corporation Watermarking methods and media
US6813366B1 (en) 1995-05-08 2004-11-02 Digimarc Corporation Steganographic decoding with transform to spatial domain
US6003030A (en) 1995-06-07 1999-12-14 Intervu, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
US6502125B1 (en) 1995-06-07 2002-12-31 Akamai Technologies, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
US6665706B2 (en) 1995-06-07 2003-12-16 Akamai Technologies, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
US5838300A (en) 1995-06-19 1998-11-17 Canon Kabushiki Kaisha Window sharing system
US5761656A (en) 1995-06-26 1998-06-02 Netdynamics, Inc. Interaction between databases and graphical user interfaces
US5768614A (en) 1995-07-03 1998-06-16 Fujitsu Limited Monitored state display unit for monitoring state change of various events occurring on communication network
US6122403A (en) 1995-07-27 2000-09-19 Digimarc Corporation Computer system linked by using information in data objects
US7058697B2 (en) 1995-07-27 2006-06-06 Digimarc Corporation Internet linking from image content
US6408331B1 (en) 1995-07-27 2002-06-18 Digimarc Corporation Computer linking methods using encoded graphics
US6286036B1 (en) 1995-07-27 2001-09-04 Digimarc Corporation Audio- and graphics-based linking to internet
US6553129B1 (en) 1995-07-27 2003-04-22 Digimarc Corporation Computer system linked by using information in data objects
US6775392B1 (en) 1995-07-27 2004-08-10 Digimarc Corporation Computer system linked by using information in data objects
US5742797A (en) 1995-08-11 1998-04-21 International Business Machines Corporation Dynamic off-screen display memory manager
US6539429B2 (en) 1995-08-22 2003-03-25 Backweb Technologies Ltd. Method and apparatus for transmitting and displaying information between a remote network and a local computer
US5657390A (en) 1995-08-25 1997-08-12 Netscape Communications Corporation Secure socket layer application program apparatus and method
US5748499A (en) 1995-09-19 1998-05-05 Sony Corporation Computer graphics data recording and playback system with a VCR-based graphic user interface
US5893053A (en) 1995-09-19 1999-04-06 Sony Corporation Computer graphics data recording and playback system with a VCR-based graphic user interface
US6580808B2 (en) 1995-09-25 2003-06-17 Digimarc Corporation Method and apparatus for discerning image distortion by reference to encoded marker signals
US5572643A (en) 1995-10-19 1996-11-05 Judson; David H. Web browser with dynamic display of information objects during linking
US6366933B1 (en) 1995-10-27 2002-04-02 At&T Corp. Method and apparatus for tracking and viewing changes on the web
US6338088B1 (en) 1995-11-02 2002-01-08 British Telecommunications Public Limited Company Service creation apparatus for a communications network
US5717879A (en) 1995-11-03 1998-02-10 Xerox Corporation System for the capture and replay of temporal data representing collaborative activities
US5968132A (en) 1996-02-21 1999-10-19 Fujitsu Limited Image data communicating apparatus and a communication data quantity adjusting method used in an image data communication system
US6167432A (en) 1996-02-29 2000-12-26 Webex Communications, Inc., Method for creating peer-to-peer connections over an interconnected network to facilitate conferencing among users
US20050080850A1 (en) 1996-03-26 2005-04-14 Pixion, Inc. Real-time, multi-point, multi-speed, multi-stream scalable computer network communications system
US5923736A (en) 1996-04-02 1999-07-13 National Semiconductor Corporation Hypertext markup language based telephone apparatus
US6006242A (en) 1996-04-05 1999-12-21 Bankers Systems, Inc. Apparatus and method for dynamically creating a document
US5822436A (en) 1996-04-25 1998-10-13 Digimarc Corporation Photographic products and methods employing embedded information
US6751320B2 (en) 1996-04-25 2004-06-15 Digimarc Corporation Method and system for preventing reproduction of professional photographs
US6381341B1 (en) 1996-05-16 2002-04-30 Digimarc Corporation Watermark encoding method exploiting biases inherent in original signal
US6606479B2 (en) 1996-05-22 2003-08-12 Finali Corporation Agent based instruction system and method
US5727950A (en) 1996-05-22 1998-03-17 Netsage Corporation Agent based instruction system and method
US6201948B1 (en) 1996-05-22 2001-03-13 Netsage Corporation Agent based instruction system and method
US6482156B2 (en) 1996-07-12 2002-11-19 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6849045B2 (en) 1996-07-12 2005-02-01 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6206829B1 (en) 1996-07-12 2001-03-27 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US5796566A (en) 1996-08-16 1998-08-18 Compaq Computer Corporation Printed circuit board having conductors which can be decoupled for isolating inactive integrated circuits connected thereto
US6199753B1 (en) 1996-09-05 2001-03-13 Symbol Technologies, Inc. Method and system for presenting item information using a portable data terminal
US6052120A (en) 1996-10-01 2000-04-18 Diamond Multimedia Systems, Inc. Method of operating a portable interactive graphics display tablet and communications systems
US5732216A (en) 1996-10-02 1998-03-24 Internet Angles, Inc. Audio message exchange system
US6199076B1 (en) 1996-10-02 2001-03-06 James Logan Audio program player including a dynamic program selection controller
US5721827A (en) 1996-10-02 1998-02-24 James Logan System for electrically distributing personalized information
US5835090A (en) 1996-10-16 1998-11-10 Etma, Inc. Desktop manager for graphical user interface based system with enhanced desktop
US5990852A (en) 1996-10-31 1999-11-23 Fujitsu Limited Display screen duplication system and method
US6243375B1 (en) 1996-11-08 2001-06-05 Gregory J. Speicher Internet-audiotext electronic communications system with multimedia based matching
US6237138B1 (en) 1996-11-12 2001-05-22 International Business Machines Corp. Buffered screen capturing software tool for usability testing of computer applications
US6400806B1 (en) 1996-11-14 2002-06-04 Vois Corporation System and method for providing and using universally accessible voice and speech data files
US5915001A (en) 1996-11-14 1999-06-22 Vois Corporation System and method for providing and using universally accessible voice and speech data files
US6885736B2 (en) 1996-11-14 2005-04-26 Nuance Communications System and method for providing and using universally accessible voice and speech data files
US6539336B1 (en) 1996-12-12 2003-03-25 Phatrat Technologies, Inc. Sport monitoring system for determining airtime, speed, power absorbed and other factors such as drop distance
US6185625B1 (en) 1996-12-20 2001-02-06 Intel Corporation Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object
US6011537A (en) 1997-01-27 2000-01-04 Slotznick; Benjamin System for delivering and simultaneously displaying primary and secondary information, and for displaying only the secondary information during interstitial space
US6233617B1 (en) 1997-02-26 2001-05-15 Siebel Systems, Inc. Determining the visibility to a remote database client
US6421726B1 (en) 1997-03-14 2002-07-16 Akamai Technologies, Inc. System and method for selection and retrieval of diverse types of video data on a computer network
US6181736B1 (en) 1997-03-25 2001-01-30 Nxi Communications, Inc. Network communication system
US6934376B1 (en) 1997-03-25 2005-08-23 Nxi Communications, Inc. Network communication system
US5909559A (en) 1997-04-04 1999-06-01 Texas Instruments Incorporated Bus bridge device including data bus of first width for a first processor, memory controller, arbiter circuit and second processor having a different second data width
US6166729A (en) 1997-05-07 2000-12-26 Broadcloud Communications, Inc. Remote digital image viewing system and method
US5983190A (en) 1997-05-19 1999-11-09 Microsoft Corporation Client server animation system for managing interactive user interface characters
US6427063B1 (en) 1997-05-22 2002-07-30 Finali Corporation Agent based instruction system and method
US6502131B1 (en) 1997-05-27 2002-12-31 Novell, Inc. Directory enabled policy management tool for intelligent traffic management
US6799221B1 (en) 1997-06-18 2004-09-28 Akamai Technologies, Inc. System and method for server-side optimization of data delivery on a distributed computer network
US6573907B1 (en) 1997-07-03 2003-06-03 Obvious Technology Network distribution and management of interactive video and multi-media containers
GB2327836A (en) 1997-07-29 1999-02-03 Ibm User interface controls for a computer system
US5935212A (en) 1997-08-07 1999-08-10 I-Planet, Inc. Connection-oriented session emulation
US20030135656A1 (en) 1997-08-22 2003-07-17 Apex Inc. Method and system for intellegently controlling a remotely located computer
US6134596A (en) 1997-09-18 2000-10-17 Microsoft Corporation Continuous media file server system and method for scheduling network resources to play multiple files having different data transmission rates
US6816904B1 (en) 1997-11-04 2004-11-09 Collaboration Properties, Inc. Networked video multimedia storage server environment
US20020194272A1 (en) 1997-11-18 2002-12-19 Min Zhu Method for establishing a communication connection between two or more users via a network of interconnected computers
US7228340B2 (en) 1998-04-08 2007-06-05 Access Co., Ltd Wireless communication device with markup language based man-machine interface
US6675204B2 (en) 1998-04-08 2004-01-06 Access Co., Ltd. Wireless communication device with markup language based man-machine interface
US6470381B2 (en) 1998-04-08 2002-10-22 Access Co., Ltd. Wireless communication device with markup language based man-machine interface
US6173316B1 (en) 1998-04-08 2001-01-09 Geoworks Corporation Wireless communication device with markup language based man-machine interface
US6317781B1 (en) 1998-04-08 2001-11-13 Geoworks Corporation Wireless communication device with markup language based man-machine interface
US6141699A (en) 1998-05-11 2000-10-31 International Business Machines Corporation Interactive display system for sequential retrieval and display of a plurality of interrelated data sets
US6295340B1 (en) 1998-05-13 2001-09-25 Lucent Technologies Inc. Speech coding selection based on call related information
US6317761B1 (en) 1998-05-15 2001-11-13 Unicast Communications Corporation Technique for implementing browser-initiated user-transparent advertising and for interstitially displaying an advertisement, so distributed, through a web browser in response to a user click-stream
US6880123B1 (en) 1998-05-15 2005-04-12 Unicast Communications Corporation Apparatus and accompanying methods for implementing a network distribution server for use in providing interstitial web advertisements to a client computer
US20020057295A1 (en) 1998-05-29 2002-05-16 Anatoliy Panasyuk System and method for combining local and remote windows into a single desktop environment
US6289461B1 (en) 1998-06-09 2001-09-11 Placeware, Inc. Bi-directional process-to-process byte stream protocol
US20010056547A1 (en) 1998-06-09 2001-12-27 Placeware, Inc. Bi-directional process-to-process byte stream protocol
US6307550B1 (en) 1998-06-11 2001-10-23 Presenter.Com, Inc. Extracting photographic images from video
US6278466B1 (en) 1998-06-11 2001-08-21 Presenter.Com, Inc. Creating animation from a video
US20020052932A1 (en) 1998-06-11 2002-05-02 Placeware, Inc. Collaborative object architecture
US6119092A (en) * 1998-06-26 2000-09-12 Lsi Logic Corporation Audio decoder bypass module for communicating compressed audio to external components
US6401118B1 (en) 1998-06-30 2002-06-04 Online Monitoring Services Method and computer program product for an online monitoring search engine
US6286030B1 (en) 1998-07-10 2001-09-04 Sap Aktiengesellschaft Systems and methods for recording and visually recreating sessions in a client-server environment
US6321252B1 (en) 1998-07-17 2001-11-20 International Business Machines Corporation System and method for data streaming and synchronization in multimedia groupware applications
US20040205213A1 (en) 1998-07-27 2004-10-14 Web Tv Networks, Inc.; Manipulating a compressed video stream
US6473745B2 (en) 1998-07-31 2002-10-29 Microsoft Corporation Intelligent advisor system and method
US6219786B1 (en) 1998-09-09 2001-04-17 Surfcontrol, Inc. Method and system for monitoring and controlling network access
US20020033844A1 (en) 1998-10-01 2002-03-21 Levy Kenneth L. Content sensitive connected content
US6601087B1 (en) 1998-11-18 2003-07-29 Webex Communications, Inc. Instant document sharing
US6691154B1 (en) 1998-11-18 2004-02-10 Webex Communications, Inc. Instantaneous remote control of an unattended server
US6802041B1 (en) 1999-01-20 2004-10-05 Perfectnotes Corporation Multimedia word processor
US6263363B1 (en) 1999-01-28 2001-07-17 Skydesk, Inc. System and method for creating an internet-accessible working replica of a home computer on a host server controllable by a user operating a remote access client computer
US6400996B1 (en) 1999-02-01 2002-06-04 Steven M. Hoffberg Adaptive pattern recognition based control system and method
US6640145B2 (en) 1999-02-01 2003-10-28 Steven Hoffberg Media recording device with packet data interface
US7185283B1 (en) 1999-02-24 2007-02-27 Sony Corporation Screen control method
US6584493B1 (en) 1999-03-02 2003-06-24 Microsoft Corporation Multiparty conferencing and collaboration system utilizing a per-host model command, control and communication structure
US7032030B1 (en) 1999-03-11 2006-04-18 John David Codignotto Message publishing system and method
US6498955B1 (en) 1999-03-19 2002-12-24 Accenture Llp Member preference control of an environment
US6574672B1 (en) 1999-03-29 2003-06-03 Siemens Dematic Postal Automation, L.P. System, apparatus and method for providing a portable customizable maintenance support computer communications system
US6697894B1 (en) 1999-03-29 2004-02-24 Siemens Dematic Postal Automation, L.P. System, apparatus and method for providing maintenance instructions to a user at a remote location
US6356437B1 (en) 1999-03-29 2002-03-12 Siemens Dematic Postal Automation, L.P. System, apparatus and method for providing a portable customizable maintenance support instruction system
US7043529B1 (en) 1999-04-23 2006-05-09 The United States Of America As Represented By The Secretary Of The Navy Collaborative development network for widely dispersed users and methods therefor
US7024456B1 (en) 1999-04-23 2006-04-04 The United States Of America As Represented By The Secretary Of The Navy Method for facilitating collaborative development efforts between widely dispersed users
US6351777B1 (en) 1999-04-23 2002-02-26 The United States Of America As Represented By The Secretary Of The Navy Computer software for converting a general purpose computer network into an interactive communications system
US6331855B1 (en) 1999-04-28 2001-12-18 Expertcity.Com, Inc. Method and apparatus for providing remote access, control of remote systems and updating of display information
US6519571B1 (en) 1999-05-27 2003-02-11 Accenture Llp Dynamic customer profile management
US6473794B1 (en) 1999-05-27 2002-10-29 Accenture Llp System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US6615166B1 (en) 1999-05-27 2003-09-02 Accenture Llp Prioritizing components of a network framework required for implementation of technology
US6721713B1 (en) 1999-05-27 2004-04-13 Andersen Consulting Llp Business alliance identification in a web architecture framework
US6957186B1 (en) 1999-05-27 2005-10-18 Accenture Llp System method and article of manufacture for building, managing, and supporting various components of a system
US7165041B1 (en) 1999-05-27 2007-01-16 Accenture, Llp Web-based architecture sales tool
US7149698B2 (en) 1999-05-27 2006-12-12 Accenture, Llp Business alliance identification in a web architecture Framework
US6536037B1 (en) 1999-05-27 2003-03-18 Accenture Llp Identification of redundancies and omissions among components of a web based architecture
US6986459B2 (en) 1999-06-30 2006-01-17 Silverbrook Research Pty Ltd System for providing a document associated with a video signal
US6824044B1 (en) 1999-06-30 2004-11-30 Silverbrook Research Pty Ltd Method and system for obtaining a video-related document
US7100195B1 (en) 1999-07-30 2006-08-29 Accenture Llp Managing user information on an e-commerce system
US6601233B1 (en) 1999-07-30 2003-07-29 Accenture Llp Business components framework
US6704873B1 (en) 1999-07-30 2004-03-09 Accenture Llp Secure gateway interconnection in an e-commerce based environment
US6523027B1 (en) 1999-07-30 2003-02-18 Accenture Llp Interfacing servers in a Java based e-commerce architecture
US6609128B1 (en) 1999-07-30 2003-08-19 Accenture Llp Codes table framework design in an E-commerce architecture
US6718535B1 (en) 1999-07-30 2004-04-06 Accenture Llp System, method and article of manufacture for an activity framework design in an e-commerce based environment
US6633878B1 (en) 1999-07-30 2003-10-14 Accenture Llp Initializing an ecommerce database framework
US7398320B1 (en) 1999-08-09 2008-07-08 Fujitsu Limited Information distribution/reproduction control apparatus, information distribution/reproduction control method, and computer-readable recording medium recorded with information distribution/reproduction control program
US6601234B1 (en) 1999-08-31 2003-07-29 Accenture Llp Attribute dictionary in a business logic services environment
US6496850B1 (en) 1999-08-31 2002-12-17 Accenture Llp Clean-up of orphaned server contexts
US6615253B1 (en) 1999-08-31 2003-09-02 Accenture Llp Efficient server side data retrieval for execution of client side applications
US6256773B1 (en) 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6289382B1 (en) 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
US6324647B1 (en) 1999-08-31 2001-11-27 Michel K. Bowman-Amuah System, method and article of manufacture for security management in a development architecture framework
US6529948B1 (en) 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US6550057B1 (en) 1999-08-31 2003-04-15 Accenture Llp Piecemeal retrieval in an information services patterns environment
US6339832B1 (en) 1999-08-31 2002-01-15 Accenture Llp Exception response table in environment services patterns
US6529909B1 (en) 1999-08-31 2003-03-04 Accenture Llp Method for translating an object attribute converter in an information services patterns environment
US6345239B1 (en) 1999-08-31 2002-02-05 Accenture Llp Remote demonstration of business capabilities in an e-commerce environment
US7139999B2 (en) 1999-08-31 2006-11-21 Accenture Llp Development architecture framework
US6742015B1 (en) 1999-08-31 2004-05-25 Accenture Llp Base services patterns in a netcentric environment
US6549949B1 (en) 1999-08-31 2003-04-15 Accenture Llp Fixed format stream in a communication services patterns environment
US6502213B1 (en) 1999-08-31 2002-12-31 Accenture Llp System, method, and article of manufacture for a polymorphic exception handler in environment services patterns
US6370573B1 (en) 1999-08-31 2002-04-09 Accenture Llp System, method and article of manufacture for managing an environment of a development architecture framework
US6715145B1 (en) 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
US6636242B2 (en) 1999-08-31 2003-10-21 Accenture Llp View configurer in a presentation services patterns environment
US6640238B1 (en) 1999-08-31 2003-10-28 Accenture Llp Activity component in a presentation services patterns environment
US6611867B1 (en) 1999-08-31 2003-08-26 Accenture Llp System, method and article of manufacture for implementing a hybrid network
US6640249B1 (en) 1999-08-31 2003-10-28 Accenture Llp Presentation services patterns in a netcentric environment
US6640244B1 (en) 1999-08-31 2003-10-28 Accenture Llp Request batcher in a transaction services patterns environment
US6615199B1 (en) 1999-08-31 2003-09-02 Accenture, Llp Abstraction factory in a base services pattern environment
US6842906B1 (en) 1999-08-31 2005-01-11 Accenture Llp System and method for a refreshable proxy pool in a communication services patterns environment
US6606660B1 (en) 1999-08-31 2003-08-12 Accenture Llp Stream-based communication in a communication services patterns environment
US6539396B1 (en) 1999-08-31 2003-03-25 Accenture Llp Multi-object identifier system and method for information service pattern environment
US6405364B1 (en) 1999-08-31 2002-06-11 Accenture Llp Building techniques in a development architecture framework
US6601192B1 (en) 1999-08-31 2003-07-29 Accenture Llp Assertion component in environment services patterns
US6477580B1 (en) 1999-08-31 2002-11-05 Accenture Llp Self-described stream in a communication services patterns environment
US6662357B1 (en) 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6427132B1 (en) 1999-08-31 2002-07-30 Accenture Llp System, method and article of manufacture for demonstrating E-commerce capabilities via a simulation on a network
US6477665B1 (en) 1999-08-31 2002-11-05 Accenture Llp System, method, and article of manufacture for environment services patterns in a netcentic environment
US6571282B1 (en) 1999-08-31 2003-05-27 Accenture Llp Block-based communication in a communication services patterns environment
US6434628B1 (en) 1999-08-31 2002-08-13 Accenture Llp Common interface for handling exception interface name with additional prefix and suffix for handling exceptions in environment services patterns
US6434568B1 (en) 1999-08-31 2002-08-13 Accenture Llp Information services patterns in a netcentric environment
US6438594B1 (en) 1999-08-31 2002-08-20 Accenture Llp Delivering service to a client via a locally addressable interface
US6578068B1 (en) 1999-08-31 2003-06-10 Accenture Llp Load balancer in environment services patterns
US6442748B1 (en) 1999-08-31 2002-08-27 Accenture Llp System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment
US6332163B1 (en) 1999-09-01 2001-12-18 Accenture, Llp Method for providing communication services over a computer network system
US6774926B1 (en) 1999-09-03 2004-08-10 United Video Properties, Inc. Personal television channel system
US6687745B1 (en) 1999-09-14 2004-02-03 Droplet, Inc System and method for delivering a graphical user interface of remote applications over a thin bandwidth connection
US6801927B1 (en) 1999-09-24 2004-10-05 Akamba Corporation Network adaptor card with reverse proxy and cache and method implemented therewith
US6795506B1 (en) 1999-10-05 2004-09-21 Cisco Technology, Inc. Methods and apparatus for efficient scheduling and multiplexing
US6850252B1 (en) 1999-10-05 2005-02-01 Steven M. Hoffberg Intelligent electronic appliance system and method
US20040267820A1 (en) 1999-10-14 2004-12-30 Microsoft Corporation Method and system for recording and replaying internet transactions
US20070005795A1 (en) 1999-10-22 2007-01-04 Activesky, Inc. Object oriented video system
US6671876B1 (en) 1999-10-28 2003-12-30 Lucent Technologies Inc. Monitoring of software operation for improving computer program performance
US6944279B2 (en) 1999-11-12 2005-09-13 Metro One Telecommunications, Inc. Enhanced directory assistance service providing individual or group directories
US6870921B1 (en) 1999-11-12 2005-03-22 Metro One Telecommunications, Inc. Enhanced directory assistance service providing individual or group directories
US7073126B1 (en) 1999-11-18 2006-07-04 Instaknow.Com Inc. Method and system of deploying server-based applications
US7124101B1 (en) 1999-11-22 2006-10-17 Accenture Llp Asset tracking in a network-based supply chain environment
US7130807B1 (en) 1999-11-22 2006-10-31 Accenture Llp Technology sharing during demand and supply planning in a network-based supply chain environment
US6606744B1 (en) 1999-11-22 2003-08-12 Accenture, Llp Providing collaborative installation management in a network-based supply chain environment
US6405252B1 (en) 1999-11-22 2002-06-11 Speedera Networks, Inc. Integrated point of presence server network
US6671818B1 (en) 1999-11-22 2003-12-30 Accenture Llp Problem isolation through translating and filtering events into a standard object format in a network based supply chain
US6629081B1 (en) 1999-12-22 2003-09-30 Accenture Llp Account settlement and financing in an e-commerce environment
US7069234B1 (en) 1999-12-22 2006-06-27 Accenture Llp Initiating an agreement in an e-commerce environment
US7167844B1 (en) 1999-12-22 2007-01-23 Accenture Llp Electronic menu document creator in a virtual financial environment
US6654032B1 (en) 1999-12-23 2003-11-25 Webex Communications, Inc. Instant sharing of documents on a remote server
US6711474B1 (en) 2000-01-24 2004-03-23 G. Victor Treyz Automobile personal computer systems
US6526335B1 (en) 2000-01-24 2003-02-25 G. Victor Treyz Automobile personal computer systems
US7069332B2 (en) 2000-02-24 2006-06-27 Hitachi, Ltd. Video server for video distribution system
USRE38609E1 (en) 2000-02-28 2004-10-05 Webex Communications, Inc. On-demand presentation graphical user interface
US6584569B2 (en) 2000-03-03 2003-06-24 Sanctum Ltd. System for determining web application vulnerabilities
US6466654B1 (en) 2000-03-06 2002-10-15 Avaya Technology Corp. Personal virtual assistant with semantic tagging
US20030191799A1 (en) 2000-03-14 2003-10-09 Netilla Networks, Inc. Apparatus and accompanying methods for providing, through a centralized server site, a secure, cost-effective, web-enabled, integrated virtual office environment remotely accessible through a network-connected web browser
US6502102B1 (en) 2000-03-27 2002-12-31 Accenture Llp System, method and article of manufacture for a table-driven automated scripting architecture
US6907546B1 (en) 2000-03-27 2005-06-14 Accenture Llp Language-driven interface for an automated testing framework
US6701514B1 (en) 2000-03-27 2004-03-02 Accenture Llp System, method, and article of manufacture for test maintenance in an automated scripting framework
US6597736B1 (en) 2000-03-29 2003-07-22 Cisco Technology, Inc. Throughput enhanced video communication
US6968364B1 (en) 2000-03-30 2005-11-22 Microsoft Corporation System and method to facilitate selection and programming of an associated audio/visual system
US7035285B2 (en) 2000-04-07 2006-04-25 Broadcom Corporation Transceiver method and signal therefor embodied in a carrier wave for a frame-based communications network
US6975655B2 (en) 2000-04-07 2005-12-13 Broadcom Corporation Method of controlling data sampling clocking of asynchronous network nodes in a frame-based communications network
US6891881B2 (en) 2000-04-07 2005-05-10 Broadcom Corporation Method of determining an end of a transmitted frame in a frame-based communications network
US6988236B2 (en) 2000-04-07 2006-01-17 Broadcom Corporation Method for selecting frame encoding parameters in a frame-based communications network
US6993101B2 (en) 2000-04-07 2006-01-31 Broadcom Corporation Method of determining a start of a transmitted frame in a frame-based communications network
US6954800B2 (en) 2000-04-07 2005-10-11 Broadcom Corporation Method of enhancing network transmission on a priority-enabled frame-based communications network
US6888844B2 (en) 2000-04-07 2005-05-03 Broadcom Corporation Method for selecting an operating mode for a frame-based communications network
US6877043B2 (en) 2000-04-07 2005-04-05 Broadcom Corporation Method for distributing sets of collision resolution parameters in a frame-based communications network
US7000031B2 (en) 2000-04-07 2006-02-14 Broadcom Corporation Method of providing synchronous transport of packets between asynchronous network nodes in a frame-based communications network
US6898204B2 (en) 2000-04-07 2005-05-24 Broadcom Corporation Method of determining a collision between a plurality of transmitting stations in a frame-based communications network
US6701345B1 (en) 2000-04-13 2004-03-02 Accenture Llp Providing a notification when a plurality of users are altering similar data in a health care solution environment
US20020054750A1 (en) 2000-04-25 2002-05-09 Michael Ficco DVR functions status indicator
US7013323B1 (en) 2000-05-23 2006-03-14 Cyveillance, Inc. System and method for developing and interpreting e-commerce metrics by utilizing a list of rules wherein each rule contain at least one of entity-specific criteria
US20020032770A1 (en) 2000-05-26 2002-03-14 Pearl Software, Inc. Method of remotely monitoring an internet session
US7490166B2 (en) 2000-05-26 2009-02-10 Citrix Systems, Inc. Remote control of a client's off-screen surface
US6763501B1 (en) 2000-06-09 2004-07-13 Webex Communications, Inc. Remote document serving
US20070106681A1 (en) 2000-06-28 2007-05-10 Mci, Llc. Method and system for providing a personal video recorder utilizing network-based digital media content
US7000180B2 (en) 2000-06-29 2006-02-14 Balthaser Online, Inc. Methods, systems, and processes for the design and creation of rich-media applications via the internet
US7133837B1 (en) 2000-06-29 2006-11-07 Barnes Jr Melvin L Method and apparatus for providing communication transmissions
US7124175B1 (en) 2000-06-30 2006-10-17 Cisco Technology, Inc. IP web based messaging system for localized management of wireless messaging
US20020126144A1 (en) 2000-07-07 2002-09-12 Erwann Chenede Apparatus and method for communicating graphical display data in a network-based windowing system
US20060064716A1 (en) 2000-07-24 2006-03-23 Vivcom, Inc. Techniques for navigating multiple video streams
US7133085B2 (en) 2000-08-10 2006-11-07 Pioneer Corporation Display control apparatus, display control method and information recording medium
US7092370B2 (en) 2000-08-17 2006-08-15 Roamware, Inc. Method and system for wireless voice channel/data channel integration
US20020038388A1 (en) 2000-09-13 2002-03-28 Netter Zvi Itzhak System and method for capture and playback of user interaction with web browser content
US7035907B1 (en) 2000-09-13 2006-04-25 Jibe Networks, Inc. Manipulating content objects to control their display
US20020048450A1 (en) 2000-09-15 2002-04-25 International Business Machines Corporation System and method of processing MPEG streams for file index insertion
US20020035451A1 (en) 2000-09-18 2002-03-21 Todd Rothermel Spatail data enabled engineering, construction, and operations computer-aided design (CAD) project system, method and computer program product
US20020039481A1 (en) 2000-09-30 2002-04-04 Lg Electronics, Inc. Intelligent video system
US6988126B2 (en) 2000-10-17 2006-01-17 Hewlett-Packard Development Company, L.P. Contact center system and method for specifying different service specific behavior and offering range of corresponding customer services
US6996605B2 (en) 2000-10-17 2006-02-07 Hewlett-Packard Development Company L.P. Overview subsystem for information page server
US7000019B2 (en) 2000-10-17 2006-02-14 Hewlett-Packard/Development Company L.P. Establishment of a deferred network communication session
US20030164853A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed document sharing
US20030167303A1 (en) 2000-12-29 2003-09-04 Min Zhu Fault-tolerant distributed system for collaborative computing
US20030167304A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed meeting management
US20030167339A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed application sharing
US20030167293A1 (en) 2000-12-29 2003-09-04 Min Zhu Fault tolerant server architecture for collaborative computing
US6567813B1 (en) 2000-12-29 2003-05-20 Webex Communications, Inc. Quality of service maintenance for distributed collaborative computing
US20030167305A1 (en) 2000-12-29 2003-09-04 Min Zhu Secure communications system for collaborative computing
US20030167418A1 (en) 2000-12-29 2003-09-04 Min Zhu Fault-tolerant server for collaborative computing
US20030167301A1 (en) 2000-12-29 2003-09-04 Min Zhu Distributed network system architecture for collaborative computing
US20030167302A1 (en) 2000-12-29 2003-09-04 Min Zhu Scalable distributed network system for collaborative computing
US7171174B2 (en) 2001-02-20 2007-01-30 Ellis Michael D Multiple radio signal processing and storing method and apparatus
US6721703B2 (en) 2001-03-02 2004-04-13 Jay M. Jackson Remote deposition system and method
US20020149617A1 (en) 2001-03-30 2002-10-17 Becker David F. Remote collaboration technology design and methodology
US20020174181A1 (en) 2001-04-13 2002-11-21 Songxiang Wei Sharing OpenGL applications using application based screen sampling
US20020165922A1 (en) 2001-04-13 2002-11-07 Songxiang Wei Application based screen sampling
US20030085922A1 (en) 2001-04-13 2003-05-08 Songxiang Wei Sharing DirectDraw applications using application based screen sampling
US7027055B2 (en) 2001-04-30 2006-04-11 The Commonwealth Of Australia Data view of a modelling system
US6810488B2 (en) 2001-05-22 2004-10-26 Webex Communications, Inc. Adaptive selective retransmission of packets
US7213211B1 (en) 2001-07-03 2007-05-01 Dynamic Knowledge Transfer, Llc System for knowledge transfer in a group setting
US20030018662A1 (en) 2001-07-19 2003-01-23 Sheng Li Synchronizing multimedia data
US20030055896A1 (en) 2001-08-31 2003-03-20 Hui Hu On-line image processing and communication system
US7225130B2 (en) 2001-09-05 2007-05-29 Voice Signal Technologies, Inc. Methods, systems, and programming for performing speech recognition
US20030061355A1 (en) 2001-09-25 2003-03-27 Guanghong Yang Systems and methods for establishing quasi-persistent HTTP connections
US20030079224A1 (en) 2001-10-22 2003-04-24 Anton Komar System and method to provide additional information associated with selectable display areas
US20030084169A1 (en) 2001-10-31 2003-05-01 Min Zhu System and method for accessing a target computer from a remote location using a remote computer
US20060274828A1 (en) 2001-11-01 2006-12-07 A4S Security, Inc. High capacity surveillance system with fast search capability
US20090282444A1 (en) 2001-12-04 2009-11-12 Vixs Systems, Inc. System and method for managing the presentation of video
US20030110266A1 (en) 2001-12-10 2003-06-12 Cysive, Inc. Apparatus and method of using session state data across sessions
US20030226038A1 (en) 2001-12-31 2003-12-04 Gil Raanan Method and system for dynamic refinement of security policies
US7313613B1 (en) 2002-01-03 2007-12-25 Microsoft Corporation System and method facilitating network diagnostics and self-healing
US7149788B1 (en) 2002-01-28 2006-12-12 Witness Systems, Inc. Method and system for providing access to captured multimedia data from a multimedia player
US20030163704A1 (en) 2002-02-25 2003-08-28 Dick Kevin Stewart System, method and computer program product for guaranteeing electronic transactions
US7023979B1 (en) 2002-03-07 2006-04-04 Wai Wu Telephony control system with intelligent call routing
US20030177172A1 (en) 2002-03-14 2003-09-18 Citrix Systems, Inc. Method and system for generating a graphical display for a remote terminal session
US20030182375A1 (en) 2002-03-21 2003-09-25 Webex Communications, Inc. Rich multi-media format for use in a collaborative computing system
US20030220973A1 (en) 2002-03-28 2003-11-27 Min Zhu Conference recording system
US7401116B1 (en) 2002-03-29 2008-07-15 Silicon Graphics, Inc. System and method for allowing remote users to specify graphics application parameters for generation of interactive images
US7043669B2 (en) 2002-04-03 2006-05-09 International Business Machines Corporation Simple scenario builder
US20040017394A1 (en) 2002-04-04 2004-01-29 Keiji Adachi Image processing apparatus and method, and program for implementing the method
US7174126B2 (en) 2002-05-03 2007-02-06 Time Warner Interactive Video Group Inc. Technique for effectively accessing programming listing information in an entertainment delivery system
US7073189B2 (en) 2002-05-03 2006-07-04 Time Warner Interactive Video Group, Inc. Program guide and reservation system for network based digital information and entertainment storage and delivery system
US20030208529A1 (en) 2002-05-03 2003-11-06 Sreenath Pendyala System for and method of real-time remote access and manipulation of data
US20040031058A1 (en) 2002-05-10 2004-02-12 Richard Reisman Method and apparatus for browsing using alternative linkbases
US20040002048A1 (en) 2002-07-01 2004-01-01 Matthew Thurmaier Method and system for providing a virtual computer classroom
US20070022155A1 (en) 2002-08-22 2007-01-25 Owens David H Method and system for integrating enterprise software applications with desktop software applications
US20040044521A1 (en) 2002-09-04 2004-03-04 Microsoft Corporation Unified lossy and lossless audio compression
US20040143602A1 (en) 2002-10-18 2004-07-22 Antonio Ruiz Apparatus, system and method for automated and adaptive digital image/video surveillance for events and configurations using a rich multimedia relational database
US20040135974A1 (en) 2002-10-18 2004-07-15 Favalora Gregg E. System and architecture for displaying three dimensional data
US8009966B2 (en) * 2002-11-01 2011-08-30 Synchro Arts Limited Methods and apparatus for use in sound replacement with automatic synchronization to images
US20040103438A1 (en) 2002-11-27 2004-05-27 Yong Yan Methods and systems for transferring events including multimedia data
US7130403B2 (en) 2002-12-11 2006-10-31 Siemens Communications, Inc. System and method for enhanced multimedia conference collaboration
US7082572B2 (en) 2002-12-30 2006-07-25 The Board Of Trustees Of The Leland Stanford Junior University Methods and apparatus for interactive map-based analysis of digital video content
EP1469382A2 (en) 2003-04-08 2004-10-20 Microsoft Corporation Display source divider
US7047092B2 (en) 2003-04-08 2006-05-16 Coraccess Systems Home automation contextual user interface
US20040207723A1 (en) 2003-04-15 2004-10-21 Davis Jeffrey Alan UI remoting with synchronized out-of-band media
US20050019014A1 (en) 2003-04-23 2005-01-27 Lg Electronics, Inc. Method and apparatus for synchronous reproduction of main contents recorded on an interactive recording medium and additional contents therefor
US20040240387A1 (en) 2003-05-28 2004-12-02 Lucent Technologies, Incorporated System and method for simulating traffic loads in packetized communication networks
US7184531B2 (en) 2003-06-05 2007-02-27 Siemens Communications, Inc. System and method for authorizing a party to join a conference
US6914519B2 (en) 2003-06-05 2005-07-05 Siemens Communications, Inc. System and method for muting alarms during a conference
US20040267952A1 (en) 2003-06-24 2004-12-30 He Li-Wei Variable play speed control for media streams
US20050152683A1 (en) * 2003-11-28 2005-07-14 Lg Electronics Inc. Method and apparatus for repetitive playback of a video section based on subtitles
US7558806B2 (en) 2003-12-14 2009-07-07 Realnetworks, Inc. Method and apparatus for buffering streaming media
US20050132417A1 (en) 2003-12-14 2005-06-16 Bobrovskiy Stanislav M. Method and apparatus for buffering streaming media
US20050254775A1 (en) 2004-04-01 2005-11-17 Techsmith Corporation Automated system and method for conducting usability testing
US20090169183A1 (en) * 2004-12-02 2009-07-02 Sony Computer Entertainment Inc. Data recording device, data recording method, data processing device, data processing method, program, program recording medium, data recording medium, and data structure
US20060130124A1 (en) 2004-12-15 2006-06-15 Guard Insurance Group A Remote Communication System and Method Implementing a Session Server and One or More Object Servers
US20060161959A1 (en) 2005-01-14 2006-07-20 Citrix Systems, Inc. Method and system for real-time seeking during playback of remote presentation protocols
US20060161671A1 (en) 2005-01-14 2006-07-20 Citrix Systems, Inc. Method and systems for capture and replay of remote presentation protocol data
US20070106811A1 (en) * 2005-01-14 2007-05-10 Citrix Systems, Inc. Methods and systems for real-time seeking during real-time playback of a presentation layer protocol data stream
WO2006076389A2 (en) 2005-01-14 2006-07-20 Citrix Systems, Inc. Methods and systems for capture, replay and real-time seeking in remote presentation protocols
US7908325B1 (en) 2005-06-20 2011-03-15 Oracle America, Inc. System and method for event-based collaboration
US20070057952A1 (en) 2005-09-14 2007-03-15 Microsoft Corporation Adaptive scheduling to maintain smooth frame rate
US20070133524A1 (en) 2005-12-09 2007-06-14 Yahoo! Inc. Selectable replay of buffered conversation in a VOIP session
US20110286721A1 (en) 2006-02-28 2011-11-24 Rovi Guides, Inc. Systems and methods for enhanced trick-play functions
US20070214489A1 (en) * 2006-03-08 2007-09-13 Kwong Wah Y Media presentation operations on computing devices
US20070261097A1 (en) 2006-05-03 2007-11-08 Avocent Corporation Remote session recording apparatus and method
US20070276910A1 (en) 2006-05-23 2007-11-29 Scott Deboy Conferencing system with desktop sharing
US20070288640A1 (en) 2006-06-07 2007-12-13 Microsoft Corporation Remote rendering of multiple mouse cursors
US20070300235A1 (en) * 2006-06-27 2007-12-27 Eliezer Dekel Reliable messaging using a message stream in a high speed, low latency data communications environment
US20080068289A1 (en) 2006-09-14 2008-03-20 Citrix Systems, Inc. System and method for multiple display support in remote access software
US20080106530A1 (en) * 2006-10-23 2008-05-08 Buxton Mark J Video composition optimization by the identification of transparent and opaque regions
US20090097361A1 (en) 2006-12-28 2009-04-16 Sony Corporation Content display method, a content display apparatus, and a recording medium on which a content display program is recorded
US20110196982A1 (en) 2009-10-28 2011-08-11 Qualcomm Incorporated Streaming encoded video data

Non-Patent Citations (80)

* Cited by examiner, † Cited by third party
Title
"Remote Desktop Environments Reflected in Local Windows" IBM Technical Disclosure Bulletin, Mar. 1993, vol. 36, Issue 3, pp. 421-426.
Adrian Nye, XLIB Programming Manual, Rel. 5, Third Edition, Jun. 30, 1994, O'Reilly Media, Inc., chapter 2.
Chinese Office Action on 200780047081.9 dated Aug. 21, 2012.
Chinese Office Action on 200780047081.9 dated May 14, 2012.
Chinese Office Action on 200780047081.9 dated Nov. 23, 2011.
Christiansen, B.O., Schauser, K.E., Munke, M.; "A Novel Codec for Thin Client Computing,"In Proceedings of the IEEE Data Compression Conference, Snowbird, UT, Mar. 28-30, 2000, pp. 1-10.
Christiansen, B.O., Schauser, K.E., Munke, M.; "Streaming Thin Client Compression," In Proceedings of the IEEE Data Compression Conference, Snowbird, UT, Mar. 27-29, 2001, pp. 1-10.
Communication pursuant to Article 94(3) EP Application No. 07119879.0-1525; Dated Jun. 20, 2008; 8 pages.
Communication pursuant to Article 94(3) EPC EP Application No. 07120005.9-1525; Dated Jun. 20, 2008; 9 pages.
Communication Pursuant to Article 94(3) EPC for EP Application No. 0711991.3-1525; Dated Jun. 20, 2008; 12 pages.
Communication pursuant to Article 96(2) EPC dated Oct. 24, 2007; EP Application No. 06718013.3-1525; 6 pages.
Communication pursuant to Article 96(2) EPC EP Application No. 06718012.5-1525; Dated Oct. 24, 2007; 5 pages.
Crusty, "The Un-Official XviD FAQ," Mar. 4, 2004, pp. 1-50.
Cruz, G. and Hill, R., "Capturing and Playing Multimedia Events with STREAMS", in Proceedings of ACM Multimedia '94, San Francisco, CA, Oct. 15-20, 1994, pp. 193-200.
Daniel S Washko: "Creating Animated Screenshots on Linux", Linux Gazette #102, May 1, 2004, pp. 1-8, XP055047283, Retrieved from the Internet: URL:http://linuxgazette.neV102/washko.html [retrieved on Dec. 10, 2012].
De Alwis, B., "Screen Capturing and Playback Using VNC," http://www.cs.ubc.ca/{bsd/vncrecording.html, Oct. 31, 2004.
Dennis Baker, Using Xinerama to Multihead XFree86 V.4.0 [Online], Nov. 15, 2002, XP002417796. Available at: http://www.tldp.org/HOWTO/Xinerama-HOWTO/.
European Exam Report for 06718012.5 dated May 27, 2011.
European Examination Report on 06718012.5 dated Dec. 19, 2012.
European Search Report EP Application No. 07119879 completed Jan. 16, 2008; 5 pages.
Extended European Search Report EP 0712005; Dated Dec. 14, 2007; 6 pages.
Extended European Search Report from EP Application No. 07119991.3-1525 completed Mar. 4, 2008; 9 pages.
Final Office Action dated Apr. 14, 2010, pertaining to U.S. Appl. No. 11/036,489, 24 pages.
Final Office Action dated Jan. 20, 2010, pertaining to U.S. Appl. No. 11/555,611, 19 pages.
Final Office Action dated Jan. 6, 2009, pertaining to U.S. Appl. No. 11/036,486, 46 pages.
Final Office Action dated Jul. 7, 2009, pertaining to U.S. Appl. No. 11/036,489, 16 pages.
Final Office Action dated Mar. 16, 2010, pertaining to U.S. Appl. No. 11/036,486, 41 pages.
Final Office Action dated Nov. 9, 2009, pertaining to U.S. Appl. No. 11/555,615, 30 pages.
Final Office Action dated Sep. 15, 2009, pertaining to U.S. Appl. No. 11/035,851, 13 pages.
International Search Report for corresponding International Application No. PCT/US2007/021098, mailed Feb. 22, 2008,4 pages.
International Search Report for PCT/US2006/038629. Mailing Date Feb. 23, 2007. 3 pages.
International Search Report, PCT/US2006/000887, Jul. 24, 2006.
International Search Report, PCT/US2006/000888, Aug. 31, 2006.
International Search Report, PCT/US2007/081751, Nov. 5, 2008.
Krishnakumar A. S. et al., "VLSI Implementations of Communication Protocols-A Survey" IEEE Journal on Selected Areas in Communications, IEEE Service Center, Piscataway, NJ, vol. 7, No. 7, Sep. 1, 1989, pp. 1082-1090.
Lamming, M.G., "Towards a Human Memory Prosthesis", Technical Report EPC-91-116, Copyright.RTM. Rank Xerox EuroPARC, Published in Proceedings of International Workshop Lecture Notes in Computer Science '91, Dagstuhl, Berlin, Jul. 1991.
Lamming, M.G., and Newman, W.M., "Activity-based Information Retrieval Technology in Support of Personal Memory," Technical Report EPC-91-103.1, Copyright.RTM. Rank Xerox EuroPARC 1991, pp. 1-16.
Non Final Office Action dated Apr. 14, 2009, pertaining to U.S. Appl. No. 11/035,851, 11 pages.
Non Final Office Action dated Apr. 29, 2008, pertaining to U.S. Appl. No. 11/036,486, 20 pages.
Non Final Office Action dated Aug. 3, 2009, pertaining to U.S. Appl. No. 11/036,486, 39 pages.
Non Final Office Action dated Dec. 10, 2008, pertaining to U.S. Appl. No. 11/036,489, 17 pages.
Non Final Office Action dated Jun. 3, 2009, pertaining to U.S. Appl. No. 11/555,611, 16 pages.
Non Final Office Action dated Mar. 30, 2009, pertaining to U.S. Appl. No. 11/555,615, 25 pages.
Non Final Office Action dated May 26, 2009, pertaining to U.S. Appl. No. 11/036,840, 11 pages.
Non Final Office Action dated Sep. 4, 2009, pertaining to U.S. Appl. No. 11/036,489, 21 pages.
Non-Final Office Action dated Dec. 23, 2009, pertaining to U.S. Appl. No. 11/035,511, 10 pages.
Non-Final Office Action dated Jan. 4, 2010, pertaining to U.S. Appl. No. 11/035,851, 14 pages.
Notice of Allowance on U.S. Appl. No. 11/035,511 dated Apr. 25, 2012.
Notice of Allowance on U.S. Appl. No. 11/035,851 dated Dec. 12, 2011.
Notice of Allowance on U.S. Appl. No. 11/036,489 dated Sep. 24, 2012.
Notice of Allowance on U.S. Appl. No. 12/609,684 dated Apr. 6, 2012.
Notice of Allowance on U.S. Appl. No. 12/609,731 dated Jul. 18, 2012.
Notice of Allowance on U.S. Appl. No. 12/685,507 dated Jan. 14, 2013.
Office Action for U.S. Appl. No. 11/035,511 dated Mar. 30, 2011.
Office Action for U.S. Appl. No. 11/035,851 dated Aug. 19, 2010.
Office Action for U.S. Appl. No. 11/036,489 dated Jun. 7, 2011.
Office Action for U.S. Appl. No. 11/555,611 dated Sep. 30, 2010.
Office Action on U.S. Appl. No. 11/035,511 dated Jan. 18, 2012.
Office Action on U.S. Appl. No. 11/036,489 dated Oct. 14, 2011.
Office Action on U.S. Appl. No. 12/609,615 dated Jun. 19, 2012.
Office Action on U.S. Appl. No. 12/609,615 dated Mar. 15, 2012.
Office Action on U.S. Appl. No. 12/609,615 dated Mar. 15, 2013.
Office Action on U.S. Appl. No. 12/609,615 dated Oct. 31, 2012.
Office Action on U.S. Appl. No. 12/685,507 dated Sep. 26, 2012.
Partial European Search Report completed on Dec. 14, 2007; EP Application No. EP07119991; 3 pages.
Pedersen, E.R., McCall, K., Moran, T.P., and Halasz, F.G., "Tivoli: An Electronic Whiteboard for Informal Workgroup Meetings," Interchi '93,Apr. 24-29, 1993, pp. 391-398.
Reilly, R., "Today's Linux Screen Capture Technology," Newsforge, http://software.newsforge.com/article.pl?sid=04/08/16/2128226, Aug. 17, 2004.
Rhyne, J.R., and Wolf, C.G., "Tools for Supporting the Collaborative Process," in Proceedings of the ACM Symposium on User Interface Software and Technology, Monterey, California, Nov. 15-18, 1992, pp. 161-170.
Sandklef H., "Testing Applications with Xnee," Linux Journal, vol. 2004, No. 117, 2004, pp. 1-6.
Sandklef, H., "Xnee Manual," Manual Version 1.08D, http://web.archive.org/web/20040627125613/www.gnu.org/software/xnee/www/m-anual/xnee.pdf, Oct. 3, 2003.
ScreenPlay User's Guide, Release 2.0, Copyright. 1991-1993, RAD Technologies, Inc., Palo Alto, California, pp. 1-4, 9, 12-14, 30-37, and 44-66.
Smith, Advanced Linux Networking, Jun. 11, 2002, Addison Wesley Professional, Chapter 14, Section 4.
Stanonik, R., "Recording/Playing Both Gaze Date and Computer Interaction," http://hci.ucsd.edu/eye/gaze.txt, Nov. 30, 2000.
Stanonik, R., "Reversing the VNC Record File," http://web.archive.org/web/20060703115503/http://hci.ucsd.edu/eye/reversi- ng.txt, Mar. 18, 2002.
Wolf, C.G., Rhyne, J.R., and Briggs, L.K., "Communication and Information Retrieval with a Pen-based Meeting Support Tool," CSCW 92 Proceedings, Nov. 1992, pp. 322-329.
Written Opinion of the International Searching Authority for PCT/US2006/038629 dated Jan. 31, 2007.
Written Opinion of the International Searching Authority to PCT/US2006/000887 (Jul. 4, 2006).
Written Opinion of the International Searching Authority to PCT/US2006/000888(Jul. 7, 2006).
X Desktop Group: "Extended window manager hints" [Online], May 13, 2003, Available at: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html.
Zeldovich, N. et al., "Interactive Performance Measurement with VNCPlay," USENIX 2005 Annual Technical Conference.

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130336158A1 (en) * 2012-06-14 2013-12-19 James D. Conniff Apparatus, methods, and systems for character set surveying of network traffic
US8953451B2 (en) * 2012-06-14 2015-02-10 The Boeing Company Apparatus, methods, and systems for character set surveying of network traffic
CN106686428A (en) * 2016-12-30 2017-05-17 广东欧珀移动通信有限公司 Video playing method and device

Also Published As

Publication number Publication date
US20130071085A1 (en) 2013-03-21

Similar Documents

Publication Publication Date Title
US7831728B2 (en) Methods and systems for real-time seeking during real-time playback of a presentation layer protocol data stream
US7996549B2 (en) Methods and systems for recording and real-time playback of presentation layer protocol data
US8615159B2 (en) Methods and systems for cataloging text in a recorded session
US8917978B2 (en) System and methods for automatic time-warped playback in rendering a recorded computer session
US8145777B2 (en) Method and system for real-time seeking during playback of remote presentation protocols
US8230096B2 (en) Methods and systems for generating playback instructions for playback of a recorded computer session
US8340130B2 (en) Methods and systems for generating playback instructions for rendering of a recorded computer session
US20060161671A1 (en) Method and systems for capture and replay of remote presentation protocol data
EP2074793B1 (en) Methods and systems for recording and real-time playback and seeking of a presentation layer protocol data stream
US20190146616A1 (en) Systems And Methods For Remote Tracking And Replay Of User Interaction With A Webpage
EP1836805B1 (en) Method and system for adaptive generation of state-snapshots of a remote presentation protocol
US10305964B2 (en) Generating content fragments for content distribution
US9088767B2 (en) Activities duplication via recorded video
US20140293296A1 (en) Printing frames of a video
EP1836804B1 (en) Method and system for playback of a recorded computer session

Legal Events

Date Code Title Description
AS Assignment

Owner name: CITRIX SYSTEMS, INC., FLORIDA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RYMAN, PAUL;FEIJOO, RICARDO FERNANDO;NAGUBADI, ANIL;SIGNING DATES FROM 20110913 TO 20110919;REEL/FRAME:027696/0011

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, DELAWARE

Free format text: SECURITY INTEREST;ASSIGNOR:CITRIX SYSTEMS, INC.;REEL/FRAME:062079/0001

Effective date: 20220930

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062112/0262

Effective date: 20220930

Owner name: GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT, NEW YORK

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062113/0001

Effective date: 20220930

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062113/0470

Effective date: 20220930

AS Assignment

Owner name: CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.), FLORIDA

Free format text: RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001);ASSIGNOR:GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT;REEL/FRAME:063339/0525

Effective date: 20230410

Owner name: CITRIX SYSTEMS, INC., FLORIDA

Free format text: RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001);ASSIGNOR:GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT;REEL/FRAME:063339/0525

Effective date: 20230410

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.);CITRIX SYSTEMS, INC.;REEL/FRAME:063340/0164

Effective date: 20230410